Source: Fujitsu

While computer technology in a wider sense has advanced rapidly and dramatically over the past three decades, networking has remained virtually unchanged since the 1990s. One of the main problems facing providers around the world is that the numerous multivendor legacy systems still in service don’t support fast, accurate remote identification, troubleshooting and fault resolution. The lack of remote fault resolution capabilities is compounded by the complex, closed, and proprietary nature of legacy systems, as well as the proliferation of protocols at the Southbound end. As a result, networks are difficult to optimize, troubleshoot, automate, and customize. SDN (Software-Defined Networking) is set to solve these issues by decoupling the control plane, plus bringing the benefits of cost reduction, overhead reduction, virtual network management, virtual packet forwarding, extensibility, better network management, faster service activation, reduced downtime, ease of use and open standards.

Why Multilayer SDN is Needed

One of the issues facing network operators is that there is no SDN controller with a streamlined topology view of both optical transport and packet layers. That’s why coordination between transport and IP/MPLS layer management is one of the most promising approaches to optimized, simplified multilayer network architecture. However, this coordination brings significant technical challenge, since it involves interoperation between very different technologies on each of the network layers, each with its own protocols, approach and legacy for network control and management.

Traditionally, transport networks have relied on centralized network management through a Network Management System or Element Management System (NMS/EMS), whereas the IP/MPLS layer uses a distributed control plane to build highly robust and dynamic network topologies. These fundamentally different approaches to network control have been a significant challenge over the years when the industry has tried to realize a closer integration between both network layers.

Although there has been a lot of R&D in this area (one example would be OpenFlow adding optical transport extensions on version 1.3 onwards), there are few, if any, successful implementations of multilayer orchestration through SDN.

It’s important to mention a common misconception about SDN, which is the assumption that SDN goes hand-in-hand with the OpenFlow protocol. OpenFlow (which is an evolution of Ethane protocol) is just a means to an end, namely separation of the control and data plane. OpenFlow is a communication protocol that gives access to the forwarding plane of a network element (switch, router, optical equipment, etc.). SDN isn’t dependent on Openflow specifically; it can also be implemented using other protocols for southbound communication, such as Netconf/Yang, BGP, XMPP, etc.

A Multilayer, Multivendor SDN Proof of Concept

To address the issues outlined above, CENGN (Canada’s Centre of Excellence in Next Generation Networks), in collaboration with Juniper Networks, Fujitsu, Telus and cenX, initiated a PoC to demonstrate true end-to-end multilayer SDN orchestration of an MPLS-based WAN over optical infrastructure.

In the PoC, the CENX Cortx Service Orchestrator serves as a higher layer orchestrator that optimally synchronizes the MPLS and Optical layers. The MPLS layer uses Juniper’s NorthStar SDN controller for Layer 2–3 devices and the Optical transport layer uses Fujitsu Virtuora® Network Controller. All northbound integration is through a REST API and upon notification of failures or policy violations this API dynamically adjusts the optical or packet layers via the SDN controllers, ensuring optimal routing and policy conformance.

Scenarios

The proof of concept consists of the following scenarios:

STEP 1: FAILURE IN OPTICAL DOMAIN

• Optical link failure (via cable pull or manual port failure).
• Cortx Orchestrator gets link failure alarms from Virtuora, stores them and updates path info.

STEP 2: PACKET REROUTE

• Cortx Service Orchestrator receives link failure alarms from Juniper MPLS, stores alarm.
• Cortx Service Orchestrator receives updated topology information from SDN controllers.
• Juniper MPLS automatically re-routes blue label-switched path and notifies Cortx Service Orchestrator of link state changes.

STEP 3: CORTX SRLG NOTIFICATION

• Cortx Service Orchestrator processes new topology and raises alert of network policy. violation, which remains in effect until the situation is corrected.
• Cortx Service Orchestrator notifies the operations user of policy violation.

STEP 4: PACKET DOMAIN ADJUSTMENTS

• Virtuora turns up optical links and alerts Cortx Service Orchestrator of topology change
• Policy violation is cleared when condition corrected
• LSP is rerouted through new provisioned optical paths

Conclusion

This is an excellent model of how a collaborative, multivendor, multilayer approach based on open standards can drive the industry towards the network of the future. By providing a functional example of real-time operations across multivendor platforms, this project has shown that multilayer data connectivity orchestration—and the benefits it offers—is feasible in a realistic situation. Other proofs of concept at the CENGN laboratories will continue to advance SDN and NFV technologies, helping to refine functionality and move towards production systems.

View the original article here

About the Author

CENGN, Canada’s Centre of Excellence in Next Generation Networks, drives technology innovation and industry growth through our testbed, technical expertise, talent development, and partner ecosystem. Through our projects, CENGN enables small and medium Canadian Enterprises to test and validate promising technologies, removing barriers to product commercialization and accelerating market growth.

More by CENGN