Service Providers

SDN Flow-Based MPLS Traffic Engineering

by pmoyer on ‎08-26-2016 09:11 AM (1,035 Views)

I wrote a blog several years ago titled: “Is MPLS Dead?” I was not actually implying that MPLS was dead or that it was going away anytime soon, although the title of the blog was intentionally provocative. MPLS continues to be the WAN technology of choice amongst global service providers and large enterprises. Even with all the SDN hype of the last few years, MPLS continues to dominate and also evolve. There are some interesting developments with MPLS that are worth calling out.


Two interesting developments with MPLS inside the IETF are Path Computation Element Protocol (PCEP, RFC 5540) and Segment Routing (SR, ID). Those will be topics of future blogs. In this blog, I’d like to discuss another interesting development with MPLS; that being, the ability to tie together SDN/OpenFlow and MPLS/RSVP-TE to provide an innovative service offering.


This capability does not change the signaling or traffic-engineering capability of RSVP-TE networks; it enhances it. This also does not touch LDP based networks, as they are inherently not “traffic-engineered” since the LDP tunnels follow the IGP paths.


There has long been a need to classify certain types of traffic into different RSVP-TE tunnels. One such mechanism is documented in RFC 3564, Diff-Serv Aware MPLS TE (DS-TE). The basic premise is that high priority traffic that is marked with a high DSCP value gets mapped into a high priority traffic-engineered tunnel. This tunnel is given the appropriate bandwidth, prioritization and re-route capabilities such that this traffic is protected at the highest level. Consider this the “GOLD” standard, as it’s the most important traffic in the network. Traffic that is considered medium priority that is marked with a medium DSCP value gets mapped into a medium priority traffic-engineered tunnel. Consider this traffic the “SILVER” standard. Best effort traffic gets mapped into a best effort tunnel and this can be considered the “BRONZE” standard. You get the idea…


While this is a cool capability, it does have limitations. One glaring limitation is that the traffic needs to be appropriately marked with the proper DSCP value at some point along the path before entering the Ingress PE router that performs the DS-TE functionality. Does the customer or application mark the traffic and if so, is it done properly? Can those markings be trusted by the service provider? Or do the network devices themselves mark the traffic? Or both? These types of QoS/CoS configs in networking devices can be quite tedious to configure and properly maintain. What if one device along the path changes the DSCP markings? And how do you ensure that each application is given its appropriate DSCP class? These are just a few of the questions that must be addressed in a DS-TE architecture.


What if it were possible to classify the different traffic types on the Ingress PE router into their appropriate RSVP-TE tunnels without having to honor the DSCP markings? If that were possible, all those DSCP marking questions and issues go away. Well, it is possible! OpenFlow provides a very granular 12-tuple classification capability.


The Brocade Flow Optimizer R1.2 application supports a new feature that enables a very innovative solution for advanced traffic-engineering functionality in MPLS networks. This R1.2 feature is tied to the Brocade MLXe NI R6.0 feature for MPLS/RSVP logical ports. These features work together in this use case; which effectively enables a very unique “per-flow” RSVP-TE solution.

With the MLXe R6.0 release, RSVP-signaled MPLS LSPs can be represented as logical interfaces. The Flow Optimizer application can now discover these logical interfaces in the same manner as it currently discovers the existence of physical interfaces on the MLXe. The MPLS LSPs are now represented in the Flow Optimizer application as OpenFlow logical interfaces, based on the OpenFlow v1.3 specification.


The Flow Optimizer application already supports the ability to configure a custom profile that provides a flow matching capability based on the 12-tuple matching fields of OpenFlow. One action of this match condition can be to redirect the flow to a specific egress interface; in this use case, that egress interface is an RSVP-TE logical interface. This SDN flow-based traffic-engineering solution provides a very granular, centralized and dynamic capability to determine which types of flows get mapped into specific RSVP-signaled LSPs. This solves a significant operational problem in an elegant and innovative manner.


The common use case for this capability is when a customer desires to have multiple LSPs between sites or DCs; where, different types of traffic get treated differently depending on which LSP the traffic is being forwarded by. As previously described, assume a customer has multiple types of traffic and has built three different LSP classes; Gold, Silver, and Bronze. Each of these three LSPs have different traffic-engineering parameters and constraints associated to them to ensure the Gold LSP traffic receives the highest level of service, the Silver LSP traffic receives the next highest level of service, and the Bronze LSP gets a best effort level of service. The different traffic classes can be “per-application” in an Inter-DC deployment or can be based on “per-tenant” in an SP deployment.




Once the OpenFlow 12-tuple matching criteria is met, the OpenFlow action is a simple redirect rule to forward those flows into the specified LSP. It is also possible to meter (eg. rate-limit) traffic before forwarding the traffic into the specific LSP. This metering capability at the ingress of an LSP is also a known operational problem that did not have a clear solution; but now OpenFlow provides the admission control function along with the redirection. The application traffic profiles are populated in the Flow Optimizer application so they are easily available by the operations staff to enable, disable or modify in real-time. All the flow-based TE policies are now centrally stored and easily managed.


This type of granular traffic matching capability has been desired in the marketplace for many years, but has not been available. The current mode-of-operation for classifying coarse levels of traffic into RSVP-signaled LSPs is not very effective and is tedious and manually configured. By leveraging the 12-tuple matching capability of OpenFlow, a very granular classification capability is now available with the Brocade Flow Optimizer application.


I hope this blog provides an overview of this innovative SDN + MPLS solution. As usual, please ask questions or provide comments in the comment section of this blog. If you’d like to hear more about a specific SDN use case, please let me know in the comment section and I will do my best to oblige. And stay tuned for further updates in subsequent blogs!