=Paper=
{{Paper
|id=Vol-1727/ssn16-final13
|storemode=property
|title=RAUflow: Building Virtual Private Networks with
MPLS and OpenFlow
|pdfUrl=https://ceur-ws.org/Vol-1727/ssn16-final13.pdf
|volume=Vol-1727
|authors=Santiago Vidal,Jorge Rodrigo Amaro,Emiliano Viotti,Martín Giachino,Eduardo Grampín
|dblpUrl=https://dblp.org/rec/conf/ssn/VidalAVGG16
}}
==RAUflow: Building Virtual Private Networks with
MPLS and OpenFlow==
https://ceur-ws.org/Vol-1727/ssn16-final13.pdf
RAUflow: Building Virtual Private Networks with
MPLS and OpenFlow
Santiago Vidal Jorge Rodrigo Amaro Emiliano Viotti
Martı́n Giachino Eduardo Grampı́n
{santiago.vidal, jorge.amaro, eviotti, giachino, grampin}@fing.edu.uy
Instituto de Computación (INCO)
Universidad de la República (UdelaR)
Montevideo, Uruguay
by ANTEL, the public telecommunications operator,
which also provides inter-domain connectivity with the
Abstract commercial Internet; RAU is part of RedCLARA1 , re-
sponsible for the implementation and management of
Control and Data Plane separation is a well the network infrastructure that interconnects the Na-
established networking paradigm, fuelled by tional Research and Education Networks (NRENs) of
the raising of Software Defined Networking Latin America, and provides connectivity with global
(SDN), which foresee the implementation of academic networks such as GÉANT in Europe and In-
complex, valuable network behaviour over ternet2 in USA. RAU is a multi-tenant infrastructure,
commodity hardware. The Academic Net- shared by universities, research centres and govern-
work of Uruguay (in spanish Red Académica ment institutions. Therefore, traffic isolation is a ma-
Uruguaya - RAU ) comprises several univer- jor requirement, which leads to the implementation of
sities, research centres and government insti- Virtual Private Networks (VPNs) and/or slicing.
tutions; RAU is planning a major upgrade, The rest of the paper is organized as follows: in next
and SDN is a candidate technology to tackle section 2 we review some related work, while provid-
present and future requirements. To test ing some insights about the RAUflow application in
the feasibility of this approach, we built a section 3. Scalability is analyzed in section 4, closing
RAU2 network prototype composed of NetF- with a discussion and some directions for future work.
PGA based routers over 10G optical links.
Over this infrastructure we developed RAU-
2 Related work
flow, a network control application on top
of the Ryu SDN controller, which combines MPLS is the basic building block for Layer 2 and Layer
OpenFlow and MPLS to implement network 3 VPNs; while MPLS data plane is quite simple, and
services conforming to RAU evolution require- open source implementations have been around for
ments. In this paper we analyze the deploy- more than 15 years2 , the control plane has become in-
ment and scalability of VPN services over creasingly complex, and therefore costly. The typical
RAU2 prototype. Label Switch Router (LSR), implements both forward-
ing and control plane in the box, which comprises dis-
1 Introduction tributed routing protocols such as OSPF or IS-IS for
routing information gathering and dissemination, dis-
RAU is planning a major upgrade, seeking for a boost tributed signaling and label distribution mechanisms
on coverage and capacity, focused on flexibility for the such as RSVP-TE and LDP, and also MP-BGP (Multi
deployment of new, evolved network services. RAU is Protocol BGP) for actual VPN routing implementa-
built over typical leased line infrastructure provided tion, as defined by well established IETF standards.
Copyright c by the paper’s authors. Copying permitted for 1
Online: http://www.redclara.net/
private and academic purposes. 2
Online: http://sourceforge.net/projects/mpls-
Spring School on Networks, Santiago, Chile, 21-11-2016, linux/, updated by https://github.com/i-maravic/
published at http://ceur-ws.org MPLS-Linux
Table 1: Comparison of RAUflow vs. legacy MPLS
Legacy RAUflow Comment
Traffic Classification Per-node FEC Global edge classification: Open Flow No header processing in core routers
matching fields (avoid CPU intensive process and
added delay). Compatibility be-
tween Open Flow and legacy net-
working
Path Computation Distributed Algorithm Distributed topology database acquisi- Centralized ad-hoc Traffic Engi-
(with TE extensions) tion, centralized SPF algorithm neering algorithms, possible delay
penalty
Label distribution Distributed signalling Centralized, per LSP assignment No need to implement signalling
and LSP signalling (LDP/RSVP-TE) in network nodes (avoid CPU and
memory intensive process)
Maintenance routine Dynamic trigger / dy- Dynamic trigger / centralized computa- Centralized re-optimization, possi-
namic computation and tion and label assignment ble delay penalty
signalling
OpenFlow, proposed by McKeown et al. [1] as an
standardized interface to add and remove flow entries
in a generic Ethernet switch with an internal flow-
table, established a foundation for the implementation
of the SDN idea: a vendor-independent protocol which
defines syntax and semantics for the programmability
of the switch by an external/third party controller.
In our previous work [2] we reviewed early efforts to
implement MPLS forwarding, which has been incorpo-
rated as part of OpenFlow specification since version
1.3.
Regarding VPN implementation, the model pro- Figure 1: Architecture of the RAUswitch
posed by Suzuki et al. [3] follows the IETF L3 VPN
specification, implementing the route dissemination in and built our own open-source switch-router, named
a per-customer, centralized BGP instance running in RAUswitch (Figure 1), made using a standard x86
the SDN controller using the Quagga routing suite; in motherboard with PCIe bus and NetFPGA4 10G net-
this proposal, the VPN tunnels are implemented us- working cards, running the Quagga routing suite over
ing VLAN tags, but the authors foresee to migrate to Linux OS, therefore supporting legacy routing pro-
MPLS. tocols such as OSPF, which provides dynamic topol-
The Community Connection (CoCo) project3 pro- ogy discovery and routing information dissemination,
poses an on-demand SDN-based Layer 3 VPN imple- which is gathered by the SDN controller to deploy L2
mentation [4], which follows the same approach: MP- and L3 VPNs5 , as described in [2].
BGP information is exchanged among external “Co- RAUflow is a network control application which
Co Agents”, while the forwarding is also implemented permits to define basic services based on MPLS, for in-
using VLAN tags. The deployment is targeted for stance Layer 2 Virtual Private Wire Service (VPWS),
sharing resources among the research community, and and Layer 3 VPN services. Besides MPLS forward-
therefore is particularly interesting for our use case; ing (label PUSH, POP and SWAP operations), the
the authors include some scalability evaluation which implementation of VPN services requires other fun-
partially inspired our work. damental functionalities, such as i) traffic classifica-
The OPEN proposal [5] centralizes all control plane tion, ii) a path computation mechanism, iii) MPLS
functionality in the SDN controller, and claims to elim- label distribution and Label Switched Path (LSP) sig-
inate the need of distributed protocols to implement nalling mechanisms, and iv) a maintenance routine
MPLS-based services. Our approach is similar, but we in response to network dynamics. In addition, MAC
maintain the IGP (OSPF) as a basic building block for ethertype transparency must be supported in L2 ser-
our solution. vices, while IP addressing overlapping and transparent
per-customer routing instances must be supported for
L3 VPN services.
3 RAUflow design and implementation Table 1 is a summary of the differences between
In light of RAU requirements, and considering our RAUflow and legacy MPLS. Note that RAUflow VPN
previous experience and related work, we designed
4
Online: http://netfpga.org/
3 5
Online: https://blog.surf.nl/en/coco-an- Updated code and documentation is freely available at:
exploration-of-software-defined-networking/ https://github.com/ProyectoRRAP
Table 2: Layer 2 VPN setup time in ms. Table 3: Layer 3 VPN setup time in ms.
Path Lenght Basic Small Medium Path Lenght Basic Small Medium
1 58.3 65.0 83.1 1 6.3 6.8 19.3
2 N/C 100.8 124.0 2 N/C 7.8 21.5
4 N/C 105.2 124.1 4 N/C 9.4 22.3
6 N/C 107.8 131.4 6 N/C 15.1 23.8
8 N/C 109.6 128.6 8 N/C 12.0 23.7
10 N/C N/C 139.8 10 N/C N/C 26.4
12 N/C N/C 133.4 12 N/C N/C 27.5
·105
implementation does not use MP-BGP, which is an ex-
tra advantage for three reasons: i) complex BGP con- 4
figuration is avoided, ii) CPU and memory usage are
Memory (in KB)
reduced, and iii) BGP messaging churn is completely 3
eliminated.
2
4 Proof of concept and scalability anal- 1
ysis
0
0 3,000 6,000 9,000 12,000 15,000
We successfully built and performed functional test- # of VPNs
ing of RAUflow over the RAU2 physical testbed, com-
posed by four RAUswitches connected by a full-mesh Figure 2: Memory consumption per cummulative
of 10Gbps optical links, also verifying the maintenance VPNs
procedure (i.e. re-routing after link failure). The test-
ing scenarios included i) multi-site L3 VPN (one cus- 1,000 Layer 2 VPN
tomer), ii) multi-site L3 VPN (two customers with Layer 3 VPN
800
Setup Time (in ms)
overlapping IP addresses), and iii) point to point L2
Pseudo Wire with VLAN support. 600
The physical testbed size prevents to run scalability
tests, and therefore we ported the complete environ- 400
ment6 over the well-known Mininet emulator [6].
200
In the emulated environment, we deployed three
representative topologies: i) a basic 4-node full mesh 0
topology, emulating the physical testbed, ii) a small 0 3,000 6,000 9,000 12,000 15,000
11-node topology and iii) a medium 45-node topology, # of VPNs
both taken from “The Internet Topology Zoo”7 . Over
these topologies, we first re-run the relevant functional Figure 3: Setup time per cummulative VPNs
tests, and then we explored the setup time for a new
VPN. The results are shown in Tables 2 and 3. In a
second series of tests, we configure new VPN services 5 Conclusion and Future Work
cummulatively, measuring both the RAM consumed We built a testbed using commodity hardware which
and the setup time. The results are shown in Figures suports MPLS-based network services using a central-
2 and 3. ized, SDN-based control plane. We completely ported
Presumably, the main factors which explain these the testbed to an emulated environment, which per-
results are the time consumed by the controller to com- mits to test scalability and facilitates the development
pute the shortest paths, and the time taken by the con- of new features. Our preliminar scalability assessment
figuration of every node in the chosen paths; further reveals an acceptable behaviour, supporting tens of
and finer grain experiments are needed to confirm such thousands of services whit linear growth of setup time
intuition, for instance measuring the breakdown of the and consumption of controller resources.
controller time across the above mentioned phases. A fair quantitative comparison against legacy
MPLS is difficult to execute, since open source MPLS
6
Updated code and documentation is freely available at:
implementations, which can be emulated under the
https://github.com/santiagovidal/P2015_44 same environment as RAUflow, are far less efficient
7
Online: http://www.topology-zoo.org/ than industrial ones. Meanwhile, further scalability
testing is being acomplished, while we explore new
services and features, emphasizing that SDN adoption
would definitively be hybrid and progressive, calling
for the emergence of new technical and business mod-
els to facilitate the transition, as stated by Vissicchio
et al. [7].
References
[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,
L. Peterson, J. Rexford, S. Shenker, and J. Turner. Open-
flow: Enabling innovation in campus networks. SIGCOMM
Comput. Commun. Rev., 38(2):69–74, Mar. 2008.
[2] E. Grampı́n, M. Giachino, J. R. Amaro, and E. Viotti. RAU2
testbed: A network prototype for evolved service experimen-
tation. In LANOMS 2015, pages 107–108, Oct 2015.
[3] K. H. SUZUKI Kazuya. An OpenFlow Controller for Reduc-
ing Operational Cost of IP-VPNs. NEC Technical Journal,
8(2):49–52, April 2014.
[4] R. van der Pol, B. Gijsen, P. Zuraniewski, D. F. C. Romão,
and M. Kaat. Assessment of SDN technology for an easy-
to-use VPN service. Future Generation Computer Systems,
56:295 – 302, 2016.
[5] S. Das, A. Sharafat, G. Parulkar, and N. McKeown. MPLS
with a simple open control plane. In Optical Fiber Commu-
nication Conference and Exposition (OFC/NFOEC), 2011,
pages 1–3, March 2011.
[6] B. Lantz, B. Heller, and N. McKeown. A network in a laptop:
Rapid prototyping for software-defined networks. In Proc.
of the 9th ACM SIGCOMM Workshop on Hot Topics in
Networks, Hotnets-IX, pages 19:1–19:6, New York, NY, USA,
2010. ACM.
[7] S. Vissicchio, L. Vanbever, and O. Bonaventure. Opportuni-
ties and research challenges of hybrid software defined net-
works. SIGCOMM Comput. Commun. Rev., 44(2):70–75,
Apr. 2014.