Challenges of SDN in Carrier Networks Part 2

November 6, 2014

Author: Babak Samimi

For the first post in this series, please click here.

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

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

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.

Programmable Data Path

PMC’s WinPath® family of processors was designed to support future protocols that are not yet defined.  WinPath’s programmable data path and flexible accelerators have a field-proven ability to evolve with the network by supporting a wide range of protocols as they are defined.   SDN is no exception; WinPath is uniquely suited to implement an efficient and flexible OpenFlow switch. PMC’s ecosystem partner, Asidua, offers a WanStaX software stack that supports both the OpenFlow 1.3.2 specification and OAM capabilities via the CFM ITU-T Y.1731 stack.

WinPath’s technical advantages and programmable data path not only address the carrier’s need to deploy SDN for CAPEX and OPEX advantages, but also allow for real-time service modifications to adapt to customers’ needs. It allows for real-time modification of complex parameters to implement dynamic SLAs and gives carriers the ability to control traffic parameters through OpenFlow. In addition to enabling carrier-grade functions, it also allows carriers to anticipate and respond to their customers’ needs in real time via remote control, further enabling them to customize their services and maximize revenue.

This post was also published on SDN Central.

facebooklinkedinmail



Leave a Reply

Your email address will not be published. Required fields are marked *


eight × 8 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>