Control and Data Plane separation is a well established networking paradigm, fuelled by the raising of Software De ned Networking (SDN), which foresee the implementation of complex, valuable network behaviour over commodity hardware. The Academic Network of Uruguay (in spanish Red Academica Uruguaya - RAU ) comprises several universities, research centres and government institutions; RAU is planning a major upgrade, and SDN is a candidate technology to tackle present and future requirements. To test the feasibility of this approach, we built a RAU2 network prototype composed of NetFPGA based routers over 10G optical links. Over this infrastructure we developed RAUow, a network control application on top of the Ryu SDN controller, which combines OpenFlow and MPLS to implement network services conforming to RAU evolution requirements. In this paper we analyze the deployment and scalability of VPN services over RAU2 prototype.
RAU is planning a major upgrade, seeking for a boost on coverage and capacity, focused on exibility for the deployment of new, evolved network services. RAU is built over typical leased line infrastructure provided Copyright c by the paper's authors. Copying permitted for private and academic purposes.
Spring School on Networks, Santiago, Chile, 21-11-2016, published at http://ceur-ws.org by ANTEL, the public telecommunications operator, which also provides inter-domain connectivity with the commercial Internet; RAU is part of RedCLARA1, responsible for the implementation and management of the network infrastructure that interconnects the National Research and Education Networks (NRENs) of Latin America, and provides connectivity with global academic networks such as GEANT in Europe and Internet2 in USA. RAU is a multi-tenant infrastructure, shared by universities, research centres and government institutions. Therefore, tra c isolation is a major requirement, which leads to the implementation of Virtual Private Networks (VPNs) and/or slicing.
The rest of the paper is organized as follows: in next section 2 we review some related work, while providing some insights about the RAU ow application in section 3. Scalability is analyzed in section 4, closing with a discussion and some directions for future work. 2
Related work MPLS is the basic building block for Layer 2 and Layer 3 VPNs; while MPLS data plane is quite simple, and open source implementations have been around for more than 15 years2, the control plane has become increasingly complex, and therefore costly. The typical Label Switch Router (LSR), implements both forwarding and control plane in the box, which comprises distributed routing protocols such as OSPF or IS-IS for routing information gathering and dissemination, distributed signaling and label distribution mechanisms such as RSVP-TE and LDP, and also MP-BGP (Multi Protocol BGP) for actual VPN routing implementation, as de ned by well established IETF standards.
2Online: http://sourceforge.net/projects/mplslinux/, updated by https://github.com/i-maravic/ MPLS-Linux
Per-node FEC
OpenFlow, proposed by McKeown et al. [
Regarding VPN implementation, the model
proposed by Suzuki et al. [
The Community Connection (CoCo) project3
proposes an on-demand SDN-based Layer 3 VPN
implementation [
The OPEN proposal [
RAU ow design and implementation
In light of RAU requirements, and considering our
previous experience and related work, we designed
3Online:
https://blog.surf.nl/en/coco-anexploration-of-software-defined-networking/
and built our own open-source switch-router, named
RAUswitch (Figure 1), made using a standard x86
motherboard with PCIe bus and NetFPGA4 10G
networking cards, running the Quagga routing suite over
Linux OS, therefore supporting legacy routing
protocols such as OSPF, which provides dynamic
topology discovery and routing information dissemination,
which is gathered by the SDN controller to deploy L2
and L3 VPNs5, as described in [
RAU ow is a network control application which permits to de ne basic services based on MPLS, for instance Layer 2 Virtual Private Wire Service (VPWS), and Layer 3 VPN services. Besides MPLS forwarding (label PUSH, POP and SWAP operations), the implementation of VPN services requires other fundamental functionalities, such as i) tra c classi cation, ii) a path computation mechanism, iii) MPLS label distribution and Label Switched Path (LSP) signalling mechanisms, and iv) a maintenance routine in response to network dynamics. In addition, MAC ethertype transparency must be supported in L2 services, while IP addressing overlapping and transparent per-customer routing instances must be supported for L3 VPN services.
Table 1 is a summary of the di erences between RAU ow and legacy MPLS. Note that RAU ow VPN
5Updated code and documentation is freely available at: https://github.com/ProyectoRRAP implementation does not use MP-BGP, which is an extra advantage for three reasons: i) complex BGP conguration is avoided, ii) CPU and memory usage are reduced, and iii) BGP messaging churn is completely eliminated. 4
Proof of concept and scalability analysis We successfully built and performed functional testing of RAU ow over the RAU2 physical testbed, composed by four RAUswitches connected by a full-mesh of 10Gbps optical links, also verifying the maintenance procedure (i.e. re-routing after link failure). The testing scenarios included i) multi-site L3 VPN (one customer), ii) multi-site L3 VPN (two customers with overlapping IP addresses), and iii) point to point L2 Pseudo Wire with VLAN support.
The physical testbed size prevents to run scalability
tests, and therefore we ported the complete
environment6 over the well-known Mininet emulator [
In the emulated environment, we deployed three representative topologies: i) a basic 4-node full mesh topology, emulating the physical testbed, ii) a small 11-node topology and iii) a medium 45-node topology, both taken from \The Internet Topology Zoo"7. Over these topologies, we rst re-run the relevant functional 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 con gure new VPN services cummulatively, measuring both the RAM consumed and the setup time. The results are shown in Figures 2 and 3.
Presumably, the main factors which explain these results are the time consumed by the controller to compute the shortest paths, and the time taken by the conguration of every node in the chosen paths; further and ner grain experiments are needed to con rm such intuition, for instance measuring the breakdown of the controller time across the above mentioned phases.
6Updated code and documentation is freely available at: https://github.com/santiagovidal/P2015_44 7Online: http://www.topology-zoo.org/ )B 3 K n i ( roy 2 m e M 1 4 0 1;000 )s 800 m i(n 600 e m iT 400 p u t eS 200 0 105
Layer 2 VPN
Layer 3 VPN 0 3;000 6;000 9;000 12;000 15;000
# of VPNs We built a testbed using commodity hardware which suports MPLS-based network services using a centralized, SDN-based control plane. We completely ported the testbed to an emulated environment, which permits to test scalability and facilitates the development of new features. Our preliminar scalability assessment reveals an acceptable behaviour, supporting tens of thousands of services whit linear growth of setup time and consumption of controller resources.
A fair quantitative comparison against legacy
MPLS is di cult to execute, since open source MPLS
implementations, which can be emulated under the
same environment as RAU ow, are far less e cient
than industrial ones. Meanwhile, further scalability
testing is being acomplished, while we explore new
services and features, emphasizing that SDN adoption
would de nitively be hybrid and progressive, calling
for the emergence of new technical and business
models to facilitate the transition, as stated by Vissicchio
et al. [