The opex and capex benefits of software-defined networking (SDN) realized from facilitating the separation of the data, control and management planes (to allow for the orchestration and management of network resources from a central location) are widely accepted. All of us as subscribers stand to benefit from this transformation as this centralized view of network resources will create a manageable, easy-to-automate, flexible platform allowing Carriers to allocate on-demand resources and define services in real-time to keep up with our ever-changing approach of adding and using content from the Internet. One of the major hurdles to achieving these, however, is that current SDN standards, including the industry favored OpenFlow, have not yet been augmented to specify carrier-grade functionalities.

The road ahead for OpenFlow is not unprecedented. As an industry, we transformed Ethernet from the LAN to being a WAN technology and created Carrier-Grade Ethernet. For OpenFlow to be adopted by carriers, it must also go through a similar transformation of becoming “carrier grade.” To get there, several extensions need to be made to the specification, such as traffic, various types of OAMs (Ethernet, MPLS, BFD), protection switching with fast re-route times under 50 msec, timing and synchronization, L2/L3 VPN, and detailed statistics collection, to name just a few.

In our industry, transformational changes like this make for an exciting chapter ahead that will be marked by significant industry-wide collaboration and an infusion of creativity and innovations to arrive at carrier grade SDN / OpenFlow that will go live into carrier networks worldwide.

Here, however, is the dilemma: there is tremendous interest and pent-up demand to start this network transformation, though clearly the ecosystem and the supply chain are not in place. How do we minimize risk in R&D investments made in an environment where changes will emerge as standards solidify while enabling the industry to innovate? Given that the end goal is to enable a software controlled network, we should start with flexible and programmable data path hardware architectures that can be upgraded in field via software. This strategy will allow carriers to start system deployments before the standard is finalized, and to add new functionality through software upgrades as requirements and implementation models inevitably evolve.

Let’s take a deeper look at MPLS-TP OAM and the new extensions needed to OpenFlow as we pave the way to carrier grade SDNs. MPLS-TP has explicit requirements for fault monitoring and protection switching, while OpenFlow currently has no explicit support for fault monitoring or failure recovery.

Fault Monitoring

Fault monitoring is performed in the NNI to UNI direction. OAM packets will be extracted from the MPLS-TP traffic streams and redirected to monitoring entities at the appropriate level, e.g. section, LSP and PW. Fault monitoring with Y.1731 makes use of entities called RMEPs (Remote MEPs or Maintenance Endpoints). RMEPs monitor the ‘liveness’ of a connection between a MEP and its peer MEP by terminating and processing the continuity check messages (CCMs) being transmitted by the remote end. Extensions needed to the OpenFlow specification are:

1. The OXM MATCH fields need to be extended to allow appropriate matching on OAM-specific fields in the OAM packet; for example, in CFM, MA_ID, MEP ID and MD levels.
2. A new ACTION type would need to indicate that OAM processing is required. This new ACTION type would be contained in the ActionSet for the bucket of the INDIRECT group representing the RMEP. The new ACTION type would be specific to the OAM processing required; therefore, there would be several ACTION types, (e.g., MPLS_OAM_CCM, MPLS_OAM_DMM).

The figure below outlines the fault monitoring function, and illustrates both real-time and non-real-time scenarios. CCM in the real-time scenario shows how the fault monitoring function is represented by a group, which is the watch group for the corresponding worker or protector entity.

MPLS-TP OAM Fault Monitoring

 

 

Monitoring Packet Generation

Packet generation is performed in the UNI to NNI direction. OAM packets will be generated at a particular frequency and inserted into the appropriate MPLS-TP path. Y.1731 requires that monitoring packet generation must support 3.3ms intervals. It is clear this cannot be achieved using the normal OpenFlow method. Enhancements to the OpenFlow controller (to make it capable of instructing the switch to generate these messages autonomously and allow the packet generation capability to be linked to the group bucket entities with attributes such as state, frequency, etc., for the working and protection flows) need to be considered.

Protection Switching

Due to the real-time requirements of protection switching as specified by linear protection G.8131 and RFC 6378, the protection switch must be performed autonomously by the switch without interaction with the controller. Extensions to the OpenFlow protocol would be needed to facilitate the controller specifying the protection switching capabilities of a particular protection entity. The linear protection (LP) stack would need to indicate that the switch is to perform protection switching automatically upon signal failure (notified by CCM failure). This would be achieved by extending the attributes of the bucket to contain an attribute that specifies whether automatic switching is permitted based on the bucket watch group.

Protection Switching and Fault Monitoring UNI to NNI

Bringing it all Together

The MPLS-TP example illustrates that there are some significant challenges to implementing SDN in carrier networks via OpenFlow. In addition to MPLS-TP OAM, numerous other critical requirements, such as timing and synchronization, traffic management, etc., also drive similar augmentations to OpenFlow in order to address the needs of carrier networks.

The way to overcome them is to leverage a programmable data path architecture. A programmable data path also needs to be complemented by software developed to meet strict real-time Carrier Ethernet requirements, in addition to providing the flexibility and ease of use needed to quickly add new features as standards evolve.

CONTRIBUTED ARTICLE DISCLAIMER:

Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.

While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral cannot guarantee that inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed through this site.

The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDNCentral’s endorsement or association. The copyright and any other intellectual property right any third party content belongs to the author and/or other applicable third party.