While Software Defined Networking (SDN) and Virtualisation are becoming more and more popular amongst both academia and industry, there are still many challenges unsolved. One of these challenges that our client faced was demonstrating Traffic Engineering (TE) using a Segment Routing method on Software Defined Networking Wide Area Networks (SDN-WAN).
The Challenge
Segment Routing emerged in 2013 and this technology made its way to service providers and large enterprises as it contributes to network simplification by removing protocols and simplifying network operations.
Segment Routing provides network simplicity as it eliminates protocol and network operations becomes easier. It also differentiates network services over the same path. This can improve end-user experience by applying priority to different types of network traffic.
However, this technology is new and successful implementation requires experts that have studied in these fields. So, our experts in Software Defined Networking and Service Orchestration as well as Cloud engineers have collaborated to present a solution for this problem.
The Aptira Solution
To solve this challenge, Aptira believed that Multiprotocol Label Switching (MPLS) labels were the right technology to solve this problem. We set out to identify components that supported MPLS labels so we could design the solution. Segment routing using MPLS required that the selected OpenFlow/SDN switches and the SDN controller must support MPLS labels.
We identified OVS as a virtual OpenFlow switch, NoviFlow as a hardware OpenFlow switch and OpenDayLight (ODL) as the SDN controller to utilise for this solution as all components support MPLS labels. The solution also needed a Service Orchestrator (SO) to automate the segment routing process. Cloudify was chosen as the SO.
Aptira designed and implemented a set of TOSCA blueprints to implement segment routing, based on the following high-level logic:
- The first switch in the path pushes the MPLS labels to a packet that will decide the path
- Other switches pop the outermost MPLS labels and pass the packet to the next hop
- The Penultimate node, pop the last MPLS label and send it to the destination of the path
The below diagram details how segment routing works in SDN-WAN:
The blue tables indicate the rules installed on the switches in forwarding direction as follows:
- A packet originated from VM 1 comes through input port 2 to OVS1. This switch checks if the packet coming through port 2 is the IP packet (in the match part of the flow rule) and then pushes 3 MPLS labels to the packet, respectively 103,102,101, and then sends the packet out via port 1.
- OVS2 receives the packet on port 2 and matches the packet against its input port and the outermost MPLS label which is 101. In the action part, it pops the MPLS label 101 and sends the packet out via port 1.
- OVS3 receives the packet on port 2, matches the packet against its input port (i.e. port 2) and the outermost MPLS label 102, pops the MPLS label 102 as the actions set and sends it out via port 1.
- OVS4 receives the packet on port 2, matches it against the input port and the last MPLS label which is 103 and pop the MPLS label and sends it out via output port1 to VM 2.
The orange tables indicate the rule installed on the switches in the reverse direction. This time OVS4 pushes all MPLS labels to the packets and other switches pop them out until it reaches the destination.
The Result
The segment routing solution using MPLS labeling has been successfully implemented and configured into the evaluation network. The implementation of Segment Routing over SDN-WAN provided a flexible control mechanism for traffic paths. The customer was able to set up end-to-end policies across the WAN network and its data centers. Moreover, They could simply direct the traffic on the appropriate path in the network by observing any changes in the network.
Segment routing is simple in concept but challenging to implement, and more so when you have to simulate a production network. Aptira’s world class networking skills enabled us to configure and demonstrate 4 key use cases: PCE, lifecycle, SO creating new services and TE.
