Tag: Data Center

I begin with an assumption that you are somewhat familiar with “whitebox” term as it relates to networking gears and cognizant of its trend. For those needing a brush up, please read my earlier article https://www.linkedin.com/pulse/bare-metalwhite-box-solutions-open-hyperscale-data-center-chowdhury/ .

The term “whitebox” and “open networking” to some extent synonymous, both innately suggest networking gears that are “open” meaning adheres to “open” standards and ecosystems. The former is a byproduct of open networking concept and refers to the disaggregation model in which hardware and software are separated. This decoupling of hardware and software created opportunities for a software ecosystem to flourish: well, almost!

As with any technologies advents, early days are little bumpy. It is no different for whitebox and open networking ecosystems. There are few constraints but it has come long way since its introduction in 2011. Yet, some are cautious and doubtful of its reliability: perhaps confused by choices, constraints and complexities.

In this article, I will simplify and explain fact behind the myth of “whitebox”. This article is educational in nature and intended to help readership make right decision choosing whitebox in their network transformation.

Let’s be candid! Choices are always good if we are prudent. During my presentation at Amsterdam OCP summit, someone asked me a question referring to the often confusing software ecosystems and choices thereof; as to what method one can take to make right choice for hardware and software?

Responding to this question outright in few sentences may be difficult but the method of whitebox selection could be simple: first, determine your network transformation needs and develop a checklist. It should include mandatory, good to have and nice to have feature lists. Secondly, match this checklist against hardware and software features of given whitebox solutions.

Figure 1. Whitebox product choices.

In figure 1, I depicted a diagrammatical representation of various choices available in a given hardware: herein, Agema products from Delta (http://www.agemasystems.com ). It shows four different choices for customers: bare metal (1), whitebox (2), bare metal with open source ONL/ONLP (3) and bare metal with OFDPA (4). If you do not have software resources and not planning to have experimental undertaking, please stick with whitebox. The “baremetal” switch is generally good for NOS (Network Operating Systems) vendors those who provide protocol stack software solutions e.g. IPV4, BGP, MPLS etc. If you have source code from particular NOS vendor and like to qualify this on a hardware platform go with bare metal. Those who are more incline towards experimental undertaking may go for Opensource route: 3 & 4 (refer to figure 1). The bare metal switch with support for ONL (Open Network Linux) is ideal for those who likes to work with ONL ecosystems. Please visit https://opennetlinux.org/ for more details. The OFDPA (Open Flow Data Plane Abstraction) option is good for people who prefers decoupling of data plane and control plane. This software is a contribution from Broadcom® and may not be fully supported in some of their silicons. Please visit https://github.com/Broadcom-Switch/of-dpa for further details and consult with hardware vendors for specific platform qualification in OFDPA.

One thing you can be sure of that hardware are stable and reliable if you are buying from the vendor known for quality products. The same goes for software as well. More importantly, networking hardware that are available in whitebox disaggregation model now offer some of the “state of the art” silicons. To some extents, these hardware are more advanced than those available from typical networking vendors. For example, you may now able to purchase 100GbE platform that includes programmable chips. Not that it is important for your consideration when comes to traditional network transformation but those interested in experimental use of HW level APIs may find it tempting. Additionally, whitebox networking gears also offer performance and scalability choices.

Let consider the diagram below: the figure depicts choices of whitebox hardware from 1GbE to 30Tbps.

Figure 2. Whitebox Networking hardware choices.

Products are now available in standalone and chassis format. More importantly, some of these networking gears are versatile depending upon NOS availability. For example, you could use profile based deployments of a “Top-of-Rack” switch in many network scenarios including data centers and Service provider networks with ability to perform traffic engineering if so is desired. However, there is a caveat to it, not all hardware capabilities are utilized by NOS vendors. Hence, be prudent with your selection.

The term “NOS” (Network Operating Systems) refers to networking software solutions that offers many networking protocols and application. Some NOS are more generic type having more emphasis on traditional networking protocols while others are focused on flow based or API based software solutions. Being prudent of choosing a NOS is thus important: if you are confused, ask respective hardware vendor as to which NOS best suits their platform. For example, if you are looking for a platform that should support let’s say 1 Million IPV4 route, ensure that the hardware are consideration comes with TCAMs and NOS vendor are capable of supporting the routes without performance compromise. Similarly, if you are having microburst scenarios in your data center and are looking for ways to minimize application performance issues, you may need deep buffer switch. The same goes for service providers. Therefore, understanding your networking needs andt jotting them down may help you make the right selection. Always, keep your mandatory checklist ready and use it as reference to match against hardware and software capabilities.

If you are not considering to decouple the forwarding (e.g. packet forwarding) and control plane (e.g. flow controls and/or flow based forwarding decisions), stick with traditional protocol suits. This is not to suggest that you do not need APIs/protocols for programmability and easier provisioning. You definitely do, but ensure what benefit it derives. I suggest that you always look for ZTP (Zero Touch Provisioning) capabilities in software irrespective of which NOS you choose. The ZTP will help you provision many switches at once reducing time and overhead cost associated with manpower.

 Figure 3. Network Operating System (NOS).

In the figure above shows typical NOS availability in a given whtiebox platform but there are more vendors available than those depicted above. Some are startups while others are well-known networking giant. Best way to find out is to contact respective hardware vendor.

Let’s be real! Transforming networks begins with few essentials: CAPEX/OPEX, Bandwidth consideration and business problem you are trying to solve. First, clear your mind of buzzwords, go to basics. Let’s consider you are building a data center network infrastructure or augmenting thereof. The important question is what fundamental architecture you are following and protocol suits you are looking for. Let’s say, you are building the data center network based on BGP and wanted to keep each cluster separated. I am depicting a typical setup considering the above deployment scenarios in figure 4 below. The physical network setup is based on spine/leaf architecture (known as “clos” named after Charles Clos). You may able to redesign such architecture to a five-stage folded clos to accommodate future demand.

The diagram shows Compute, Storage and Machine Learning Clusters are separated.  It so done to help you easily visualize the product needs in each area. For example, you may be planning to use separate switch for WAN and DCI leaving DC setup isolated from abnormalities of WAN or DCI routers.

Figure 4. Data center Spine/Leaf Architecture.

Similarly, you may want to keep your machine learning cluster in separate set of deep buffer switches minimizing application performance degradation due to micro burst. Whatever the network transformation decision you make, please ensure that you are choosing right networking gears considering specific deployment scenarios. As such, you cannot go wrong with your selection of whitebox solutions.

Same goes other network scenarios, whether service provider and/or enterprise.

I have thus far kept this article focused on traditional network transformation without referring to the possibilities of programmability, service orientation and artificial intelligence (AI) use cases in network transformation. While these discrete technological advents are having different triggers and origins, whitebox are making it easier to realize such technological bonanza. This can be a forward looking statement but such assertion is not without basis. For example, Open Networking paved the way for whitebox to be realized and at the same time it created the possibility of network programmability. Since whitebox products support open standards/ecosystems and are affordable, many researchers and startups are working to bring the programmability, service orientation and AI to networks. Considering such developments in the marketplace, I have created a timeline and presented herein below. The diagram depicts how each technological advents are connected and potential timeline for each advent to be realized.

Figure 5. Whitebox to cognitive networks timeline.

For example, Open Networking model created whitebox and helped developed software ecosystems. Such works made it easier to realize programmability and decoupling of forwarding/control plane (SDN) in whitebox platforms. Overtime, the ensuing software ecosystems and works thereof paved the way for further development works towards intent-based Network. This service oriented networking concept is still premature and the works are piecemeal at best, nonetheless, it is a near term possibility.

Similarly, Self-organized networks and Cognitive networks are some of the other new possibilities that may come to the fore by 2020. One potential is that Whitebox software ecosystem may soon offer deep learning agent at switches and AI engine at controller making the network more state aware. Hence, possibilities are endless with open systems though limitation may plague some deployment if end user is not careful. The bottom-line, if an end-user is prudent in their selection of whitebox, it will offer great potential in their network transformation.