See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221164224

MPLS-TE and MPLS VPNS with openflow

Conference Paper in ACM SIGCOMM Computer Communication Review · October 2011

DOI: 10.1145/2018436.2018516 · Source: DBLP

CITATIONS READS
55 1,104

4 authors, including:

Saurav Das Guru Parulkar

Khulna University of Engineering and Technology Stanford University
20 PUBLICATIONS 614 CITATIONS 139 PUBLICATIONS 15,823 CITATIONS

SEE PROFILE SEE PROFILE

Nick McKeown
Stanford University
298 PUBLICATIONS 45,146 CITATIONS

SEE PROFILE

All content following this page was uploaded by Nick McKeown on 27 September 2018.

The user has requested enhancement of the downloaded file.

 MPLS-TE and MPLS VPNs with OpenFlow
Ali Reza Sharafat, Saurav Das, Guru Parulkar, and Nick McKeown
Department of Electrical Engineering, Stanford University, Stanford, California 94305, USA
sharafat, sd2, parulkar, nickm@stanford.edu

ABSTRACT features are no longer tied to multiple protocols that would normally
We demonstrate MPLS Traffic Engineering (MPLS-TE) and have to be changed. In fact, with the controller in charge of the control
MPLS-based Virtual Private Networks (MPLS VPNs) using plane, there is no need for any distributed protocol running in the
OpenFlow [1] and NOX [6]. The demonstration is the outcome of routers as the NOS has complete knowledge of the network.
an engineering experiment to answer the following questions:
How hard is it to implement a complex control plane on top of a
2. ARCHITECTURE
network controller such as NOX? Does the global vantage point in The architecture of our system is given in Figure 1. Our test-bed
NOX make the implementation easier than the traditional method consists of several software and physical switches. The software
of implementing it on every switch, embedded in the data plane? switches are instances of Open vSwitch [2] which are hosted within
the Mininet environment [3]. These switches are connected to a
We implemented every major feature of MPLS-TE and MPLS- network of physical switches. Both software and physical switches
VPN in just 2,000 lines of code, compared to much larger lines of support the OpenFlow 1.0 specifications [4] as well as the MPLS
code in the more traditional approach, such as Quagga-MPLS. related section of the OpenFlow 1.1 specifications [5]. The switches
Because NOX maintains a consistent, up-to-date topology map, are designed so that they handle the data plane, and not the control
the MPLS control plane features are quite simple to implement. plane functionality of MPLS.
And its simplicity makes it easy to extend: We have easily added
several new features; something a network operator could do to With the abovementioned network, we emulate a wide area
customize their network to meet their customers’ needs. network for the purpose of our demonstration. All switches are
controlled by a single instance of the NOX [6] controller. The
The demo consists of two parts: MPLS-TE services and then MPLS-TE and VPN services are managed via an application that
MPLS VPN driven by a GUI. runs in NOX. The control plane and the MPLS features are
exclusively handled by NOX. The data plane simply supports the
Categories and Subject Descriptors: C.2.1 – push swap and pop actions. When changes are needed in the data
Computer Systems Organization [Computer-Communication plane, NOX modifies the flow tables in the appropriate switches.
Networks]: Network Architecture and Design
We use multiple GUIs to show the workings of the network and to
General Terms: Management, Design, Experimentation dynamically interact and modify the TE-LSPs and/or VPNs.
Keywords: MPLS, MPLS-TE, VPN, Traffic Engineering,
OpenFlow 3. DEMO SCENARIOS
The demonstration consists of two parts, the first pertaining to
1. SCIENTIFIC RATIONALE MPLS-TE [7] and the second pertaining to MPLS VPNs.
We claim that while the MPLS data plane is fairly simple, the control
planes associated with MPLS-TE and MPLS VPNs are rather 3.1. MPLS-TE
complicated. For instance, in a typical traffic engineered MPLS The first part of the demo is visualized via two GUIs, both
network, one needs to run OSPF, LDP, RSVP-TE, I-BGP, and MP- showing the topology of the entire physical network. The first
BGP to name a few protocols. The distributed nature of these protocols GUI displays the IP flows in the network and the second GUI
results in excessive traffic of update messages when there are frequent displays the LSPs and the flows routed through them. All the
changes in the network. This, in turn causes the routers to spend a lot of flows and LSPs are color-coded to distinguish between various
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 MPLS‐TE VPN
throughout the network. The described vicious cycle causes large GUI
convergence times for the above protocols, meaning excessive control
traffic on the network and stale information on the routers.
MPLS API GUI API
GUI
In SDN, the Network Operating System (NOS) is responsible for
constructing and presenting a logically centralized map of the NOX
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 Software Software Software Physical Physical
only simplicity of implementation, but also the fact that maintaining Switch Switch Switch Switch Switch
and updating applications are easy as well. This is because new
mininet
Copyright is held by the author/owner(s).
SIGCOMM’11, August 15–19, 2011, Toronto, Ontario, Canada. Figure 1. The architecture of the physical network and the
ACM 978-1-4503-0797-0/11/08. controller used in our demonstration.

452
 (a) (b)
Figure 2. Sample GUIs corresponding to the MPLS VPN demonstration. Two VPNs with their corresponding flows and LSPs are
shown in (a) and (b)
types. The demonstration starts with all the flows in the IP plane, Isolation of VPNs We demonstrate that multiple VPNs can coexist in a
and as we step through the demo, we create TE-LSPs and reroute single backbone network where different VPNs may have
some of the IP flows through the LSPs. By creating TE-LSPs of overlapping address spaces. The flows associated with different
different characteristics, we demonstrate the following features: VPNs are routed through their respective LSPs and do not
aggregate with each other.
Constrained Shortest Path First (CSPF) The CSPF algorithm
allows us to find the shortest path for a TE-LSP that satisfy its Custom Topologies The logical topology of each VPN can be specified
bandwidth and priority requirements. by the customer. The topology can be anything from the traditional
hub-and-spokes to full-mesh.
Auto-route When a TE-LSP is created, we automatically reroute
any flow whose path goes through the head-end and the tail- TE Services Since the backbone network is MPLS-TE enabled, we can
end router of the created LSP onto the LSP. readily offer TE services to the customers. We demonstrate the
Priority and Auto-bandwidth features of TE. This allows for a high
Traffic Aware LSPs We can create TE-LSPs that carry a specific priority VPN to force others to reroute when it requires more
type of traffic. These can include VOIP, HTTP, etc. bandwidth along its LSPs.
Priority LSPs can have different levels of priority. When the Interactive Management Users can create a new VPN by specifying
reservable bandwidth of a link is fully allocated, we reroute the connection between the customer and provider routers as well
LSPs of lower priority to alternative paths. as the topology and other characteristics of the network. After the
Auto-bandwidth The auto-bandwidth feature allows for the specifications are given, we create the desired VPN network and
bandwidth reservation of a TE-LSP to dynamically adjust to display the results in the GUI.
its actual bandwidth usage (as opposed to the bandwidth
being statically set at the creation of the LSP). 4. REFERENCES
[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L.
Interactive Management Users can create custom TE-LSPs from Peterson, J. Rexford, S. Shenker, and J. Turner. OpenFlow:
the GUI. That is, the user specifies the head-end and tail-end enabling innovation in campus networks. ACM SIGCOMM
routers and the characteristics of the desired TE-LSP, which Computer Communication Review, 38(2):69–74, April 2008.
is then created in the network and shown in the GUI.
[2] Open vSwitch [Online]. Available: http://openvswitch.org/
3.2. MPLS VPNs [3] B. Lantz, B. Heller, and N. McKeown. A Network in a Laptop:
The second part of the demo is visualized using multiple GUIs as Rapid Prototyping for Software-Defined Networks. In ACM
well. In this case, all GUIs show the physical network, and each SIGCOMM HotNets Workshop, 2010.
GUI pertains to a VPN and its associated flows and LSPs.
[4] OpenFlow Switch Specification: Version 1.0.0 [Online]. Available:
Screenshots of working versions of this part of the demo are given
http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf
in Figure 2. Our MPLS-VPN network has a simpler backbone
topology compared to the previous section, but with some [5] OpenFlow Switch Specification: Version 1.1.0 Implemented
customer nodes added to the edge of the backbone network. [Online]. Available:
http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf
The backbone network is MPLS-TE enabled and so when LSPs
are created to support a VPN, they are accompanied with all the [6] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown,
TE features mentioned in Section 3.1. and S. Shenker. NOX: Towards and operating system for networks.
In ACM SIGCOMM Computer Communication Review, July 2008.
We configure multiple VPNs with overlapping private IP address
[7] S. Das, A. R. Sharafat, G. Parulkar, and N. McKeown MPLS with a
spaces. Each VPN comes with different characteristics which
Simple OPEN Control Plane. In Optical Fiber Communication
enables us to demonstrate the following:
Conference, March 2011.

453

View publication stats