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.