Logical separation via VPN tunnels as LERs determinate the MPLS label MPLS support in Linux ... port and MAC after event) or proactive manner (pre-programmed). ... Controller uses Fail Secure (packets dropped after time-out) and/or Fail Standalone (Hybrid Switch uses .... traffic for the explicit path to the tunnel endpoint.
A COMPARISON OF MULTIPROTOCOL LABEL SWITCHING (MPLS) AND OPENFLOW COMMUNICATION PROTOCOLS Dariusz Terefenko X00088029
INTRODUCTION (1) 1. IT Technology Limitations: • QoS • TE
2. MPLS: Operates in Layer 2.5. Combines advantages of Data Link (performance) and Network (scalability) layers. Rich set of TE tools. IP routing replaced by label switching mechanism (LER, LSR, LSP, FEC). Logical separation via VPN tunnels as LERs determinate the MPLS label MPLS support in Linux kernel 4.1 from 2015. • Cisco and other proprietary vendors use MPLS widely (interoperability). • • • • •
INTRODUCTION (2) 3.
OpenFlow:
• Open Source, OF spec. 1.0.0 in 2009 and OF spec. 1.5.1 in 2015, Layer 2 (Data Link). • Switch (Mininet, OVS, HW) – flow tables and Communication Channel (TLS) to connect to Controller, can have up to 254 Flow Tables with goto-table instructions (matching from Flow Table 0 with Priorities, table-miss entry with Priority 0 used if no match). • Flow Tables – Header Fields created from the packet, counters with statistical information based on Matching Rules (Port-In, Port-Out in OF15, Eth Src/Dst/Type, VLAN Id/Priority, IP Src/Dst/Proto/ToS, TCP/UDP Src Port/Dst Port), Action Fields which specify the Instructions (Controller, Normal). • Controller – decoupled from switch in control plane to add/update/delete flow entries in reactive (learns port and MAC after event) or proactive manner (pre-programmed). • Switch Ports – Logical/Virtual or HW (1to1 with logical port), logical can be ingress or egress (OF15), Normal Port represents traditional routing, Reserved Port represent forwarding action (to Controller, Flooding Out, Forwarding to traditional pipeline). • Pure Switch/OF-only supports Normal and Flood Ports and relies on intelligence of the Controller. • Hybrid Switch supports OF pipeline and traditional pipeline (L2 switching, L3 routing, ACLs, VLANs, QoS). • In OF pipeline decisions are made by the centralized Controller(s) where in traditional pipeline they are made locally on the switch, it’s possible to use OF for normal forwarding and Normal Port for traditional routing and switching. • Controller uses Fail Secure (packets dropped after time-out) and/or Fail Standalone (Hybrid Switch uses Normal Port) mechanisms to protect against network failures. • Many vendors offer firmware upgrades (Cisco, HP) or we can use OVS and Mininet in core access layer in conjunction with traditional routing and forwarding mechanism. • Messages – Controller to Switch (Features Request, Configuration, Modify-State, Read-State, Packet-Out, Barrier, Role-Request or Asynchronous Configuration), asynchronous messages initiated by Switch (Packet-In, Flow-Removed, Port-Status, Error), symmetric communication initiated by both sides (Hello, Echo, Experimenter).
INTRODUCTION (3) 4.
SDN:
• According to ONF (2017) it’s separation of control plane from forwarding plane where devices are controller by controller in control plane, e.g. via OF protocol used in the SBI to communicate with the controller and switches where switches are in the infrastructure layer. • NBI – communication between hardware controllers and applications as well as higher layer systems. • It separates control plane from data plane and provides APIs for centralized management. • NFV – ability to virtualize physical HW with SW running in a virtual environment to implement specific functions such as router, firewall or switch. • Controllers – open source (OpenDaylight, Floodlight, ONOS, POX, Ryu), commercial (HPE Aruba VAN). • White-box switching allows for use of NOS with set of tools such as Quagga or FRRoute on traditional router or Linux OS acting as SW router. • Implementations – WAN (SD-WAN) to control MPLS traffic with PBR to send low latency apps via MPLS and other packets via Internet to dynamically forward packets across different network segments (Nuage Networks, 2015), CORD where NFV used to re-architecture the Datacentre approach for traditional office with VAs in the cloud (OpenCORD, 2017). • Advantages – centralized control plane simplifies approach, reduction of Opex and Capex • Disadvantages – issue with high scalability in real apps, potential security risks, overload with propagation of millions of the flow entries with multiple network failures and the need for new DPs, delay in packet forwarding, SDN uses UDP for GRE VPN tunnels which can be dynamically turned off and on what results in lack of transparency of network traffic and difficulties in the troubleshooting of network problems. • Deployment Approaches – hybrid with distributed control plane with local failover mechanism responsible for provision of new flows, multiple SDN controllers closer to the devices to minimise the delays, with use of different protocols (BGP, NETCONF, OVSDB, CLI, SNMP). • Security Risks – DoS to destabilize the network elements, use of underlying protocols to add new entries to flow tables for bypassing traffic control mechanisms (FW) to capture network traffic and preform MITM, eavesdropping of traffic between controller and devices to see type of allowed traffic, vulnerabilities in the API’s and programming language used, prevent with TLS to authenticate and encrypt communications between network devices and the controller.
HYPOTHESIS & TEST BEDS Comparing the effectiveness of MPLS in Linux and Cisco vs OpenFlow protocols to proof that SDN is capable to be used with various real-life scenarios resulting in higher performance, while adhering to interoperability of mechanisms responsible for network key factors such as: scalability, QoS, TE and Failover. TEST BEDS: Hybrid Approach: SW Routers (Linux/FRR/CSR), HW Routers (Cisco), SW Switches (Mininet/OVS) OS: Windows Server 2016 Datacenter, Ubuntu 16.04.2 LTS “Xenial Xerus” Desktop X64 (Linux kernel 4.12), Ubuntu 14.04.5 LTS “Trusty Tahr” Server X64 (SDN Controllers) Virtual Environments: Hyper-V, Mininet 2.2.2 (OVS 2.5.2 & 2.8.1 – QoS) HW: 8-core CPU & 32 GB of RAM & 4x 1GBit NICs, 3x Cisco 2801 (15.1.4M12a Advanced Enterprise Services) SW: IPRoute2 4.12, FFR 3.1, CSR 3.12.2S SDN Controllers: ODL Carbon SR2 + Cisco OFM, Floodlight 1.2, HPE Aruba VAN 2.8.8.0366 + Flow Maker 1.1.1, ONOS Magpie 1.12, POX Eel 0.5, Ryu 4.2 Tools: MGEN5, iPerf 2 & 3, Wireshark2, DPCtl, HPing3, vsFTP3, Apache2, Nmap7
PERFORMANCE AND COMPATIBILITY TESTS 1. Interoperability of MPLS in Linux and Cisco. 2. Performance of MPLS vs OpenFlow: throughput, delay, packet loss, RTT – Round Trip Time (P2P, IP Forwarding, MPLS in Linux, Cisco MPLS and OpenFlow). 3. Scalability: end-clients to mixture: CSR, FRR, Cisco HW nodes and Mininet OVS. 4. QoS: end-clients to MP-BGP VPN with CSRs and Cisco HW, MPLS-TE tunnels with FRR and Cisco HW, QoS with OF13 and Ryu controller – per flow and class with DSCP, with Meter Table and OFSoftSwitch13. 5. TE: MPLS-TE tunnels and explicit paths with FRR, OF13 flow DPs with Floodlight and HPE Aruba VAN controllers. 6. Failover: link failover protection in MPLS and OpenFlow with HPE controller.
1. INTEROPERABILITY
Linux kernel not able to pop out outgoing label for LSP forwarding to reach VM1.
2. PERFORMANCE Summary of Results: Throughput – OpenFlow provides higher throughput than P2P link between two VMs. Delay – clear advantage of OpenFlow. Packet Loss – 50B packet size resulted in Cisco MPLS advantage over OpenFlow and P2P. RTT – Smallest delay with OpenFlow.
3. SCALABILITY Summary of Results: From the RTT tests we can make a succinct conclusion that OpenFlow outperformed all other IP technologies, while LDP implemented together with OSPF and FFR on Linux provided better results than MPLS on Cisco routers. This also has proven that all tested technologies can be easily scaled-up within the “test-bed” no matter of what routing method has been used.
4. QOS WITH MPLS Summary of Results: Cisco MPLS (VPN/GRE Tunnels): Mapping between DSCP to EXP worked (FTP max. 1024 Kbps, HTTP min. 1024 Kbps), FTP data used EXP 5 in the MPLS domain which was mapped to DSCP EF, MPLS EXP 4 label mapping to DSCP AF41 is correct while making a request to Web server from VM1. MPLS in Linux (MPLS-TE Tunnels): RSVP bandwidth parameter for TE doesn’t work the same way as the bandwidth limit on the interface, bandwidth set on the tunnel resulted in expected values which were not less than 1024 Kbps, bottom of the label stack were used for local MPLS domain traffic for the explicit path to the tunnel endpoint rather than transport labels.
4. QOS WITH OF
Summary of Results: Tests allowed to proof that OF QoS is possible to achieve with use of traffic classification and DSCP markings. Experiments on the Meter Table also have proven that it’s possible to use the external controller to remark the traffic until some other app running on the NBI will take care of forwarding, while OF13 will be responsible for QoS rules injection via REST API and OFSoftSwitch13 will take over the role of remarking our DSCP classes bound to specific meters.
5. TE WITH MPLS Summary of Results: Test case topology on mixture of real HW and virtual routers with MPLS we have proven that it’s possible to effectively use Linux and FRR together with Cisco equipment, which uses PBR to perform MPLS TE with LDP and RSVP to route traffic via tunnels depending on the protocol type.
5. TE WITH OF Summary of Results: HPE performed better than Floodlight as both scenarios with and without TE resulted in a lower mean and StDev for the jitter parameter. HPE controller without TE appeared to be 7 % faster and 29 % more efficient with TE in comparison to Floodlight controller with a difference of one hop between the client and server. This could be caused because HPE is a commercial controller, however, this explains how different SDN implementations can impact the network performance on a larger scale.
5. FAILOVER Summary of Results: In MPLS on Cisco routers with Linux FRR nodes data was transferred across via backup link on Tunnel1 and no packets were matched against policy routing.
In OF ICMP requests were successful and no major delay was identified, but reaction time depends fully on the controllers’ capabilities to learn the DPID or the amount of manually entered flow entries in the flow tables as well as their priorities. In the case of Cisco devices checking for the connection, the status is entirely the responsibility of the IOS system.
SUMMARY OF TESTS MPLS: The experiments uncovered that Linux nodes implemented with MPLS acting as LSR cannot pop an outgoing label on the LSP, their throughput was the lowest between LERs, packet loss was high for small files as well as a delay for large packets. Linux and FRR with the mixed approach of using Cisco nodes resulted in lower response times in comparison to pure hardware, and it was also fully compatible while creating QoS policies when acting as LERs and during TE tests. The deployed Cisco HW without MPLS in Linux nodes were obviously fully compatible between each other while exchanging label information, throughput and delay were lower than in OF, but the number of packets lost was lower, while the response times were still a lot higher for small packets than with OF. Interoperability of the protocol, QoS and TE were easily achievable after long and complex configuration of nodes which requires wide knowledge from the network administrator. OpenFlow: Resulted in lower throughputs even than a P2P link with slightly higher delays, but it outperformed all remaining tested technologies. It did perform worse when tested with large volumes of data during packet loss, but it achieved the smallest response times for small and large packet sizes. Scalable topology has proven that it’s possible to scale-up network resources with minimal configuration, while QoS experiments with the Ryu controller provided an insight into per-flow policies, mapping of QoS classes to DSCP values and traffic remarking with the Meter Table. TE in OF tested with Floodlight and HPE Aruba VAN controllers on scaled-up topology has proven that SDN caters for centralized management to program the flow of data while it also has a mechanism for link failover which will respond rapidly after detecting that DPID is no longer available.
CONCLUSIONS & FUTURE WORK There is a possibility to provide internet services using a heterogeneous network using both routers based on MPLS in Linux and Cisco hardware routers. Cisco devices had no issues during testing when they acted as LER or LSR and thus makes them fully interoperable with MPLS. OF flow table operations are much faster than lookup of the routing table when deciding to send the packet to the next node on the route. The total delay using MPLS in Linux and Cisco is, however, lower than in the case of IP forwarding because the time gained during the transition through the LSR is lost at the LER nodes. The operation of adding and removing the MPLS label takes longer than selecting the route based on the routing table. OF also appeared far easier to scale than MPLS as adding additional nodes only involved in altering the script when controller takes over the flow processing, while this process for MPLS requires all the configurations on each node individually. LDP on both Cisco and FRR Linux nodes were functioning correctly, but Linux implementation resulted in lower delays, while OF was irrespectively the fastest. It was possible to use traffic classification and DSCP markings for both technologies to provide QoS, but only OF has a mechanism which can be used to limit the bandwidth with use of Linux HTBs and port numbers to move packets into different queues. Major identified TE benefits in OF come from centralization of management which minimises all that administrator’s burden while setting up the tunnel end-points, while in OF simply flow paths are programmed on the controller with flow entries to specific ports on each switch. In terms of link failure both solutions were effective, but it seems to be better when using OF than Cisco or Linux nodes, because the failure detection takes place in the centralized external SDN controller. The administrator is required only to properly configure the backup flow entries or to simply use the learning capabilities of the developed controller and the apps running on it. Issue with compatibility of the used software traffic generators (hardware traffic generator developed by Open Source Network Tester). Explore the possibility to create ecosystems with SDN network infrastructure and cloud computing which the main purpose would be to automatically control the transmission of data obtained in IoT systems to meet the QoS requirements of endusers.
