Network Transformation is in the offing: Does disaggregation model help?

One of the fascinating aspects in my job is understanding how some of world’s largest networks will deploy Open networking platforms. It is this continuous learning that keeps me passionate about what I do.  When I first use “open networking” term, people wondered what it may entails.  Some thought of it is all about using “open source” software and the other thought of it as another connotation of confusing technical term that simply add to plethora of jargons.  Interestingly, open networking is none of the said. It is about disaggregating hardware and software in a way that allows relatively easier integration of each sub systems. In doing so, the model innately provides three distinct benefits to customers:

  1. Eliminates Vendor lock-in: There is no need to be enchained by vendor or vendors. With state of the art merchant silicon available off the shelf, benefits of technology can be realized without being locked into a specific vendor device.
  2. Cost Reduction: As more and more vendors join the marketplace, price of hardware and software becomes suddenly more affordable. This innately reduces CAPEX and OPEX for customers.
  3. Choice of HW and Software: The disaggregation model in which open networking conception is born innately provides a choice for customers on hardware and software.

 

Figure 1‑1. Open Networking: Disaggregation model.

Central to open networking is the disaggregation model that allows hardware and software vendors to deliver their capability on what they do best. For example, hardware vendor can bring best breed of technology from modularization of their platform to make use of state of the art market silicons and on the other hand, software vendors to offer best NOS (Network Operating Systems) or software means for data plane and control plane separation.  In doing so, the marketplace has created an apparently robust eco-chain. Some will disagree here but the fact remains that the eco-chain is improving and some parts of it is more realistic now then perhaps a year before. To be more specific, I have elaborated the eco-chain in the figure below. Rather than referring it to open networking eco-chain, I denoted it as “SDN eco-chain” since the central to this initiative is about making network more programmable and service aware.

 

Figure 1‑2. Typical SDN Eco-chain.

The programmability is the core element of SDN (Software Defined Networking) for which pundits advocated the decoupling of control and data plane. However, programmability can be done in many ways: through ZTP (Zero touch provisioning), APIs (e.g. Netconf) and OpenFlow protocol (a more conventional notion of decoupling).

To my experience, majority of network deployments thus far refrained from purely decoupling model but there are exceptions and distinct differences in deployment. For example, FBOSS that runs as agent daemon uses thrift API instead of openflow to communicate route information with controller. Details of this opensource decoupling software is available at https://github.com/facebook/fboss .

Service Providers are more interested about CAPEX and OPEX reduction with choice and flexibility that open networking offers. For example, a provider edge switch that offers flexibility of advance MPLS networks with APIs for model based network configuration and monitoring could best fit their immediate need of transforming networks as oppose to overhauling the network in one go using decoupling of data and control plane. It is in this phased transformation, open networking offers best value but it is not confined by the said as it is encompassing to traditional networks and decoupling of data and control plane.

I conjectured even a bigger picture for “Open networking” as it is the fundamental conduit of future network transformation. For it, disaggregation model is paving the way for a more sophisticated network transformation to occur. A vision towards that end would be “Intelligent Networks” one that is provisionable in click, intent-based and self-healed, to name few attributions.

Figure 1‑3. Networking Technology Trend.

Affordability, openness and choices are big factors in network transformation especially for service providers since disaggregation model is giving them ability to deliver more service at a fraction of cost that would otherwise be. Moreover, open networking is offering best of both world, the “traditional” and “NextGen”. For example, in a given network deployment scenario customer may prefer to choose their own NOS depending upon southbound API requirements and L2/L3 switching products. A NOS that combines both APIs and decoupling protocols such OpenFlow is known hybrid NOS. The goal here would be two folds, first allow traditional network protocols such BGP to be run at NOS level forming traditional routing architecture and secondly, network topology is passed to Openstack for visibility, orchestration and management. The following picture depicts how such nextgen network abstraction can coexist with traditional networks.

Figure 1‑4. Cloudification of Network.

Telemetry at each network device can be obtained through Broadview™, an opensource software contributed by Broadcom®. Such deployment not only allows physical networks to be virtualized and cloudified, it is done so without compromising backward compatibility of physical network and the traditional network routing architecture therein. The depiction herein is forward looking and implementation of such network is at the discretion of its designer and availability of suitable hybrid NOS. However, this notion of network cloudification is possible only due to advances in open networking and the eco-chain that supports it.

This article is provided herein for educational purpose only implying the importance of “Open Networking” and how disaggregation model helps in realizing NextGen network transformation.

Network Virtualization 101: SDN APIs and Protocols

This article is part of my SDN/network virtualization series “Network Virtualization 101”. To view other articles in this series and/or learn more about SDN and network virtualization, please visithttps://www.linkedin.com/today/author/0_1J4WrxUu5ZhIszQwsUUcg_?trk=prof-sm or http://www.dhimanchowdhury.blogspot.com .
From the simplistic purview, SDN (Software Defined Networking) provides the means of dynamism in “networking infrastructure” solutions by facilitating programmable network control, centralized management and orchestration. For network control, it decouples control plane (think of it in terms of a set of conventional applications/protocol suits e.g. Firewall, NAT, load balancer and BGP etc) from data plane (in other words, networking equipment having only packet forwarding mechanism without conventional protocol suits) and allows centralized control over networking infrastructure. There are few variations to this approach, for example, a networking equipment with hybrid NOS (network operating system) may choose to implement both control plane protocols (conventional protocols suits) and SDN APIs/protocols in the same platform. On the other hand, some networking equipment may only implement agent such as “Indigo” allowing the device to solely depend on SDN controller for flow instructions. We will discuss such implementation later in this article.
Figure 1. Typical SDN (software Defined Networking) setup.
An SDN controller connects to Switch/routers or similar networking equipment through downstream communication interface using either API or protocol such as “OpenFlow” and “OVSDB”. This downstream communication interface (a shared boundary between two computing endpoints) is known as southbound Interface. Similar to southbound Interface, upstream communication from the controller to other server base tools such as “OpenStack” are realized through Northbound Interface. For example, “Neutron” server elements of OpenStack can be connected to “OpenDaylight” SDN controller using RESTful API as shown in the figure below. Let’s not get overwhelm by this, just keep the concept in mind as we explore SDN APIs and protocols in the subsequent sections. A detailed discussion on OpenStack and OpenDaylight connectivity will be presented in succeeding articles of this series.
Figure 2. OpenDaylight controller uses RESTful API to connect OpenStack Neutron server at Northbound Interface. 
We discussed that both northbound and southbound interfaces use either API and/or protocols. A simplistic purview is that both are abstractions: API is top-down while protocol is bottom-up. An API (Application Programming Interface) is more suitable for client/server setup where API acts as the messenger between the two entities while tightly binding them together. We could further understand API by applying the analogy of restaurant order processing where “waitress” is a go-between customer and the kitchen to process the order and serve food.  Here, API is synonymous to “Waitress” function from the operational perspective. Conversely, the protocol is a set of rules that governs communication between to networking end points. In order to establish a successful communication, both endpoints must speak the same language. 
While some protocols and APIs may be newly introduced for SDN purposes, many other protocols/APIs referred are implemented or in use elsewhere. For example, OpenFlow, OVSDB and ForCES are new sets of protocols for the southbound interface (SBI) whereas BGP and XMPP are not new. BGP for example, a de-facto standard for how various routers within the internet “network mesh” communicate with each other.
The following table attempts to simplify the understanding of various SDN APIs/protocols and their intended use. Readership will find this table useful for SDN controller connectivity with network endpoint devices.

Table 1. Typical examples of SDN protocols and APIs.

[Please note, though I have listed Opencontrail and OpenVirtex as SDN controllers, those are more of a network hypervisor or network-level virtualization controller. We will explore further on the network hypervisor type controllers and other NOS type SDN controllers in the later part of this series.]
Among the typical SDN controllers listed in table 1, OpenDaylight provides a wide range of SBI protocols/plugins including LISP, SNMP and other Wireless Access point and IOT (Internet of Things) protocols. As of writing this article, there has been proposal or talks MP-BGP EVPN as standard control plane protocol for VxLAN. If MP-BGP EVPN considered a standard interface for VxLAN configuration, it may find its to some of the typical controllers as SBI protocol.
In the next article, I will discuss various SDN protocols and APIs starting with ForCES (Forwarding Control Element Separation) framework that was proposed by IETF as an alternative to OpenFlow. Some of the largest telecom service providers in the world are exploring the potential of deploying ForCES master-slave protocol framework. Find out why… please stay tuned for next articles.