OpenFlow Traffic Engineering

MPLS is the de facto technology for service provider WAN networks. It’s scalable architecture moves complexity and decision-making to the edges of the network, leaving the core to efficiently label switch packets. The PE nodes sit at the edge and perform path calculation and encapsulations. The P nodes sit in the core and label switch packets. They only perform MPLS switching and have no visibility of customer routes. Edge MPLS routers map incoming packets into forwarding equivalence classes (FEC), and use a different Label Switched Path (LSP) for each of the forwarding classes. Keeping the network core simple enables scalable network designs. Many of today’s control planes encompass a distributed architecture and can make forwarding decisions independently. MPLS control plane still needs a distributed IGP (OSPF and ISIS) to run in the core and a distributed label allocation protocol (LDP) to label packets but it shifted the way we think of control planes and distributed architectures. MPLS reduced the challenges of some early control plane approaches but by not having central visibility, especially for traffic engineering (TE), proposes challenges.

MPLS was very successful and large service provider networks could support many customers by employing MPLS-style architecture. End-to-end Label Switch Paths (LSP) are extended to interconnect multiple MPLS service providers, route reflectors, and BGP confederations are used for large-scale deployments and complexity reduction. However, no matter how scalable the MPLS architecture could be, you couldn’t get away from the fact that Inter-DC circuit upgrades are time-consuming and expensive. To help alleviate this, MPLS providers introduced MPLS Traffic engineering (TE). TE moves traffic to other parts of the network, to sections that are underutilized. While simple TE can be done with IGP metrics, they don’t satisfy unique traffic class requirements. Provider networks commonly deployed MPLS RSVP/ TE. This type of TE is an enhancement over IGP metric tuning, allowing engineers to forward core traffic over non-shortest paths in the network. The non-shorted path is used to avoid network “hot spots”. Since the traffic is now moved to other underutilized parts of the network, it prevents the lengthy process of upgrading congested core links. MPLS TE distributes traffic optimally across a network.




“MPLS RSVP/ TE is widely adopted and well-defined technology. Can SDN and OpenFlow do a better job?”


Holistic Visibility – Controller-Based Networking

MPLS/TE is a distributed architecture. There is no real-time global view of the end-to-end network path. The lack of global view may induce incorrect traffic engineering decisions, lack of predictability and deterministic scheduling of LSP’s. There are tools available that work in conjunction with MPLS TE to create a holistic view but they are usually expensive and do not offer a “real-time” picture. They often create an offline topology. They also don’t change the fact that MPLS is a distributed architectureThe big advantage of a centralized SDN and OpenFlow framework is that you have a holistic view of the network; controller-based networking. The centralized software sits on the controllers analyzing and controlling the production network forwarding paths. It has a real-time view of the network and gains insights into various network analytics about link congestion, delay, latency, drops and other performance metrics.




If a controller has full end-to-end network insight, can it make better TE decision?


OpenFlow can certainly be used to push down rules to the nodes on a per flow basis, offering a granular approach to TE. Per flow TE state is challenging to achieve with traditional TE mechanism. The finer granularity that OpenFlow offers is also evident with service insertion use cases. OpenFlow 1.4 supports better statistics that give you visibility into application performance. This type of metric, coupled with central viewpoint can only enhance traffic engineering decisions. Let’s face it, MPLS RSVP/TE, while widely deployed, involves a number of control plane protocols. All these protocol need to interact and work together.


Network State Vs Centralized End-To-End Visibility

RSVP requires that some state is stored on the Label Switch Router (LSR). State is always bad for a network and imposes control plane scalability concerns. Network state is also a target for attack. To combat the state problem, Hierarchical RSVP was established but in my opinion it adds to network complexity. All these kludges become an operational nightmare and require skilled staff to design, implement and troubleshoot. Removing MPLS signaling protocols from the network and the state they need to maintain, eliminates some of the scale concerns with MPLE TE. Distributed control planes must maintain many tables and neighbor relationships (LSDB and TED). They all add to network complexity.

The use of SDN and OpenFlow for traffic engineering provides a more predictable and deterministic TE solution. Informing the OpenFlow controller that you want the traffic redirected toward a specific MAC address, and the necessary forwarding entries are programmed and automatically appear all across the path. There are possibilities with NETCONF and MPLS-TP but operationally cause problems and don’t alleviate the distributed signaling protocols. Have a central controller view the contents of the network allows for singular network touch points. New features are implemented in software and pushed down to the individuality nodes. Similar to all SDN architectures, there are less network touch points, increasing network agility. The box-by-box and manual culture is slowly disappearing. 




About Matt Conran

Matt Conran has created 156 entries.

Leave a Reply