Summary Bullets:
- Network element disaggregation drives an immediate need for open operating systems for the separate elements.
- The SDN control needs to focus on the end-to-end network rather than the multiple network elements at a site.
In a blog last month (Hardware Disaggregation: Truly SDN-Optimized Network Elements?), I observed that software-defined networking (SDN) can orchestrate the separate traffic forwarding functions – wavelength switching, TDM (SONET/SDH/OTN) switching, packet switching and optical transport – allowing disaggregation of functions previously performed in a single packet-optical switching platform. After noting in a blog earlier this month that demand for this disaggregation exists beyond the theoretical (Hardware Disaggregation: Demand Extending Beyond Expectations), it is now time to consider what is required to provide network element disaggregation (or, in the rest of this blog, simply disaggregation).
Of course, the principal requirement for successful disaggregation of network elements is the SDN orchestration that allows disaggregation in the first place. The initial impression of this orchestration is that its purpose is to integrate the virtualized functions of the disaggregated element (as per the following figure).
At the left of the figure, the processing of the network connections at their various layers – optical networking (optical to electrical conversion, wavelength switching, optical amplification and optical transmit/receive), TDM switching and packet switching – Layers 0, 1 and 2, respectively, takes place within a single chassis under the control of an element management system (EMS). Within the chassis, network capacity is scaled by employing multiple modules for each network layer. Layer 3 IP routing also belongs in this model, but is omitted from this example for simplicity. To the right, the network elements are physically separated from the chassis, scaled in stacks of these modules and integrated under an SDN controller. A vital aspect of leveraging network elements as commodity “components” is having element operating systems (OSs) that are open, probably Linux-based. Whereas the EMS integrated these elements when they were in a single chassis, employing best-of-breed elements implies that multiple suppliers will be used. The disaggregated elements are likely to have lightweight OSs, not the complex EMSs of the past. For simplicity, the operator will need to be able maintain all of the elements at the site under an umbrella system, thus requiring open OSs for the individual elements.
However, the purpose of a network element is to support connections across the network, connections that are virtually or physically (in the case of optical) made with adjacent network elements of the same layer; optical elements are connected to optical elements, TDM elements to TDM elements and packet elements to packet elements. Thus, the network elements need to be orchestrated on an end-to-end basis, as depicted in the following figure.
The SDN controller needs to orchestrate the connections at various layers across the network, optimizing the multi-layer network by placing service connections on the appropriate network layers, site-to-site, across the network. The requirements for this multi-layer orchestration function fall on the SDN controller. Another requirement is that it needs to scale significantly. Many networks are made up of hundreds if not thousands of sites, and it is providing a complex optimization of multiple layers at each site, resulting in seemingly countless potential multi-layer connections. A further requirement is that the controller must account for, and optimize, the lower-layer connections. Many vendors offer SDN controllers that address the upper layers (Layer 2 and higher) of the network, but to a large degree, only transport equipment vendors offer SDN controllers that address the lower layers (particularly optical).
Of the vendors that offer transport-capable SDN controllers, most have recognized that the optical network formed from each vendor’s optical networking platform is best (or can only be) managed as a distinct SDN domain. This segregation of the control of optical networks into their own domains has given rise to the following network configuration.
In this figure, each optical domain (one domain in this figure) is controlled by a vendor-specific optical/domain controller, while another SDN controller directs all of the other network elements, regardless of vendor. These two (or more, in the case of multiple optical domains) controllers, and the various network layers they control, are orchestrated at a higher layer.
As we have seen, network element disaggregation results in a significantly different management of the network. This difference drives several network and equipment requirements, which include:
- An SDN controller to orchestrate the various network layers;
- An open OS for each vendor’s element to allow single glass pane management;
- An SDN controller scaled to control multiple sites and network layers; and
- An SDN controller/orchestrator (likely a separate application) to orchestrate multiple network domains.