The SDN/OpenFlow Metro Ethernet Network based on RunOS Controller Ruslan Smeliansky, Alexander Shalimov, Vyacheslav Vasin, Danila Morkovnik, Timofey Smeliansky ARCCN, RunSDN [email protected] The goal of this demo is to show that OpenFlow network is ready for production for modern Telecom operators. The OpenFlow network consists of pure OpenFlow 1.3 software/hardware switches, RunOS controller (incl. BSS/OSS), and applications for metro ethernet services. The list of applications includes all L2 connectivity services: pseudo wires/VPNs (inc/ VPLS), paths reservation, load balancing, hierarchical QoS, multicast, high availability, troubleshooting (wireshark, mirroring), etc.

Figure 1. Typical Metro Ethernet Segment

The typical SDN/OpenFlow Metro Ethernet segment consists of the following components (Fig. 1):  The two controllers manage the network segment and operate in Active-Standby mode. If the master controller shuts down, the second one detects failure and becomes the new master controller.  The network elements divides on two types: o AR (OpenFlow Aggregation switches) – processing connections and traffic from end users. ARs are located in different geographical places (city, town, and village). o DR (OpenFlow Distribution switches) – the core switches (usually, two devices) with higher bandwidth that connect AR with services in a telco cloud platform and backbone  Telco cloud is the place where network services are resides. RunOS is OpenFlow Controller developed by ARCCN [1]. It is written on C++11/14/17, has high performance (i/o rate is 8M events per second) and low latency (50us basic i/o time). The services developed as the applications for RunOS are listed below: 1

    

      

Network control through arbitrary AR-DR topology. «Out of band» management for DR and «in band» for AR. High availability of the controller based on Active/Standby mode. B2C services: high available services for end customers (QinQ based customer separation): Internet, etc. B2B services: high available services for business customers ((QinQ based customer separation): Internet, multipoint and point to point connectivity. Our original techniques used on shadow macs do not require an additional encapsulation: encoding necessary routing information in the destination mac address. Advanced path protection: main and backup pathes, protection against link down and switch down, triggers on increasing number of errors or load on channel (if trigger happens, switch to another route), flapping. Multi-objectives path computation: hops, speed, load (dynamically computed), latency (statically added). Multicast/IPTV: IGMP snooping, multicasts protection tree. QoS: management, real time monitoring, policies QoS visualization. Link aggregation: between AR-DR (LAG) and between AR and tradition networks (LACP). Troubleshooting: display flows, group buckets, meter, searching flow related to current services, mirroring SPAN/RSPAN, dumping packets on the controller itself. Extensive Web based GUI allowing easily setup all mentioned above services. For example, in a matter of seconds you are able to install VPLS services that requires at least couple hours in traditional networks. It consists of two main components: BSS - monitoring and control, OSS - long life storage of statistics - per switch, port, and even per each client (VLAN based).

We currently tested wide range of OpenFlow switches: Centec, Pica8 EdgeCore, NEC, Huawei, Noviflow, Eltex (OFDPA based), EZChip NP5 based platform, software switches based on OVS, Lagopus. The list of OpenFlow switches that correctly support OpenFlow and fits our requirement for Metro Ethernet Network are: 1. AR: Huawei S5320, Noviflow (ex, 1132), ARCCN TSAR software switch (x86 based), Eltex NES5448 (OFDPA 2.0.1) 2. DR: Huawei S12700, Noviflow (ex,1248, 2128), ARCCN EzChip NP5. Comparison with ONOS and OpenDaylight shows that they both support some of required services: Multicast, Virtual Private LAN Service (vpls), Carrier Ethernet Adoption (point to point, multipoint-tomultipoint). But they mainly rely on the SDN-IP use case leveraging traditional protocols like BGP, BGP-LS, PCEP, Netconf. Our solution is completely pure OpenFlow using all power of SDN programming, abstraction, automation. We actively use open source projects listed below: Open vSwitch, Lagopus, Intel DPDK, ONF Libfluid, Boost, Cpp-netlib. As well as using these projects we also send our feedback and the changes back to the communities. We also host our own open source version of RunOS OpenFlow controller http://arccn.github.io/runos/. Within the demo we will discuss challenges, recommendations, and pros/cons of using SDN/OpenFlow comparing with traditional paradigm. The demo addresses to the people from service providers, telecom operators, network architectures, network engineers, DC operators, developers of network applications. We expect to get feedback about proposed SDN network architecture, about network services, and about ways we implemented them using SDN/OpenFlow paradigm.

2

The demo shows: 1. The WAN segments consists of two DRs (200Gbps) connected with 3x ARs (40Gbps). This scheme is typical topology for Metro Ethernet Regions. 2. Connections of B2C user via PPPoE to the BRAS, access to the Internet via the CG-NAT. BRAS and CGNAT are virtual services. 3. Network services management portal. Creating services in the GUI with proactive set of PW tunnels. B2C and B2B can co-existence in the same switches and ports 4. Inband (AR) and Out of band (DR) management 5. Multicast with different IGMP snooping strategies 6. Services fast failover procedure (including flapping, dynamic reroute based on different criterias). Using VoIP Phone with conference video session. 7. Controller Failover - Active-Standby 8. Featured QoS: Priority Queuing, WRR, Rate-Policy, the queues on the interface. 9. Integration with traditional network – LAG/LACP 10. ARCCN vSwitch (DPDK based, metering, qos support) 11. Real life demo on RunOS BSS and OSS systems

1. 2. 3. 4.

The demo discusses: OpenFlow pipeline and requirements to OpenFlow devices: 6 OpenFlow tables, required actions, match fields, etc. Possible equipment options for DR: network processors EZ chip based, OFDPA switches, Huawei, NoviFlow, etc. Current issues (pros and cons) of using x86 servers as AR equipment. Description of Current PoC and state of deployment of our solutions.

Figure 2. ARCCN SDN-TN portal.

ARCCN (Applied Research Center For Computer Networks, www.arccn.ru) has developed the RunOS OpenFlow Controller (www.runsdn.com), the EzChip NP5 based hardware switch, and the x86 based software switch. RunSDN has developed the applications on top of the RunOS OpenFlow Controller that implement required Metro Ethernet services for Telecom Operators. [1] A. Shalimov, S. Nizovtsev, D. Morkovnik, R. Smeliansky, "The RunOS OpenFlow Controller", Proceedings of the 4th European Workshop on Software Defined Networks. — IEEE, Bilbao, Spain, 2015 3