MPLS-TE and MPLS VPNS with openflow

Abstract

We demonstrate MPLS Traffic Engineering (MPLS-TE) and MPLS-based Virtual Private Networks (MPLS VPNs) using OpenFlow [1] and NOX [6]. The demonstration is the outcome of an engineering experiment to answer the following questions: How hard is it to implement a complex control plane on top of a network controller such as NOX? Does the global vantage point in NOX make the implementation easier than the traditional method of implementing it on every switch, embedded in the data plane?We implemented every major feature of MPLS-TE and MPLS-VPN in just 2,000 lines of code, compared to much larger lines of code in the more traditional approach, such as Quagga-MPLS. Because NOX maintains a consistent, up-to-date topology map, the MPLS control plane features are quite simple to implement. And its simplicity makes it easy to extend: We have easily added several new features; something a network operator could do to customize their network to meet their customers' needs.The demo consists of two parts: MPLS-TE services and then MPLS VPN driven by a GUI. Categories and Subject SCIENTIFIC RATIONALEWe claim that while the MPLS data plane is fairly simple, the control planes associated with MPLS-TE and MPLS VPNs are rather complicated. For instance, in a typical traffic engineered MPLS network, one needs to run OSPF, LDP, RSVP-TE, I-BGP, and MP-BGP to name a few protocols. The distributed nature of these protocols results in excessive traffic of update messages when there are frequent changes in the network. This, in turn causes the routers to spend a lot of CPU time recalculating routing information. Hence, CPU message queues may get filled leading to incoming hello messages getting dropped. This leads to false link-state information being distributed throughout the network. The described vicious cycle causes large convergence times for the above protocols, meaning excessive control traffic on the network and stale information on the routers.In SDN, the Network Operating System (NOS) is responsible for constructing and presenting a logically centralized map of the network. Instead of a set of distributed protocols implemented on each router, we implement these functionalities as simple software modules that work on the network map in NOS. Implementation of these functions on a logical map of the network is very simple. Hence, by pushing the control plane functionality to NOS, we benefit from not only simplicity of implementation, but also the fact that maintaining and updating applications are easy as well. This is because new features are no longer tied to multiple protocols that would normally have to be changed. In fact, with the controller in charge of the control plane, there is no need for any distributed protocol running in the routers as the NOS has complete knowledge of the network. ARCHITECTUREThe architecture of our system is given in Figure 1. Our test-bed consists of several software and physical switches. The software switches are instances of Open vSwitch [2] which are hosted within the Mininet environm...

Network Innovation using OpenFlow: A Survey

“…This technology was first proposed to control Ethernet switches. However, OpenFlow has also been used in routing ( [75], [84], [95], [96]), IP address validation ( [44]) and MPLS control ( [66], [67], [68], [69], [70], [71], [72], [73]). This shows that OpenFlow can be used at multiple layers.…”

“…They show how an MPLS node can play multiple roles for different MPLS domains, which provides greater flexibility to the nodes. Sharafat et al [73] implement MPLS-TE and MPLS-VPN using an OpenFlow controller to show that centralized control makes the implementation easier. Table VII compares the different applications that use OpenFlow to virtualize networks using MPLS and GMPLS.…”

A Declarative and Expressive Approach to Control Forwarding Paths in Carrier-Grade Networks

“…To configure the optimization layer, it has to push specific SR configurations to routers. The control channel between DEFO and network routers can be implemented in several ways, including OpenFlow [31] and slight modifications of configuration protocols, like Netconf [32] or Flowspec [33]. For compatibility with current routers, we prefer to rely on the PCEP extension for SR [34].…”

Cost-aware request routing in multi-geography cloud data centres using software-defined networking

“…Many existing traffic engineering approaches adopt multiple independent routing protocols including internal border gateway protocol (Cittadini, Vissicchio, and Donnet 2014) and multiprotocol label switching (Sharafat et al 2011). In these protocols, each CDC independently specifies routing paths for different types of requests with no centralised control and coordination.…”