OpenFlow Switch as MPLS PE-Router

Software Defined Networking (SDN) using OpenFlow (OF) allows control of traffic in an SDN controlled network based on header fields of the packets. If packets are moving to the SDN controller for analysis traffic could even be managed because of the packet’s content. In an ideal world, networks can be built from scratch. In such an environment SDN technology can be used for controlling the whole network. However, in real life, existing infrastructures and SDN networks need to co-exist and interwork.

Currently, OpenFlow is not considered as an appropriate base technology to build future-proof Software Defined Networks for telecommunications operators. This project is an attempt to prove this perception wrong. Given the fact, that progress was made by some vendors to develop specialized data plane products with performance optimized hardware that show potential to suit very well for these types of applications. Our project aimed to build an OpenFlow underlay network which can deploy some essential value-added carrier services (i.e., different flavors of VPNs: L2VPNs, L3VPNs, etc.) on top of it. Therefore, we have developed a virtual testbed approach with a virtual network which proves to be promising for the next generation of dynamic networks.

 

Our virtual setup

To integrate with the classical infrastructure, the OpenDaylight (ODL) controller is used to learn the topology of the network and based on that the controller pushes the flow definitions to OF switches so that packets can enter the Multi-Protocol Label Switching (MPLS) network with the right labels attached to them. This virtual network was designed with 4 Juniper vMX routers to form the MPLS core along with 2 Open Virtual Switches (OVS) sitting at the edge of the network. As Figure 1 shows, H1 and H4 are the hosts connected to respective OVSs.

Figure 1: Network Topology

Well-known Multi-Protocol Label Switching

MPLS is a well-established technology in carrier networks to create label switched paths (LSP) across various routers while keeping the forwarding tables less complicated allowing for faster forwarding of the packets. The management of these paths can be manual or by using signaling protocols like Label Distribution Protocol (LDP) or Resource Reservation Protocol-Traffic Engineering (RSVP-TE).

 

SPRING – Segment Routing

Along with MPLS, Segment routing also known as SPRING (Source Packet Routing in Networking) is a new technique slightly similar to MPLS but independent of LDP and RSVP because the IGP (IS-IS or OSPF) implements SPRING. In the context of Segment Routing, a segment does precisely the same job as that of a label in MPLS. In SPRING, as the name suggests, Source router is responsible for pushing right labels/segments on the packet. It decides about the complete path across the MPLS network, unlike conventional MPLS where intermediate router SWAP the labels according to the network requirements. Nevertheless, in SPRING, depending on the stack of labels pushed at the origin, intermediate routers only need to POP labels and forward the packet to next router depending on the label information making it faster and reducing the number of protocols running in the network.

Figure 2: PCE to PCC Communication

 

A centralized entity for a global view

The MPLS paths in both cases, i.e., RSVP-TE and SPRING, can be computed using Path Computation Element (PCE) within a domain or across multiple domains. When a node in the network, also called as Path Computation Client (PCC) or PE router in MPLS world, requires an LSP it sends a request to PCE (Ref. Fig [2]) using the Path Computation Element Protocol (PCEP). The PCE then calculates the LSP on behalf of the router and sends the LSP to the PCC which is then provisioned across the network. In our project, the ODL controller does the job of a PCE. Shifting the role of a head-end router to a centralized entity provides a global view of the topology, helps in improving the performance and adds more flexibility to the network.

 

Traffic Engineering Database (TED)

To calculate LSPs at the centralized controller, it needs to have a Traffic Engineering Database (TED) which stores topology information used for computing the path. This can be achieved via the extension to the existing Border Gateway Protocol (BGP), which is called BGP-LS (Border Gateway protocol Link-State), to distribute the link-state information to the ODL controller (Refer Fig. [3]).

The TED contains “local and remote IP addresses/interface identifiers, link metric and TE metric, link bandwidth, reservable bandwidth, per CoS class reservation state, pre-emption and Shared Risk Link Groups (SRLG)” (See RFC7752). Depending on the IGP, it also shows a Router ID, NET or the hostname. This TED Information is distributed into BGP with the help of policies on Juniper routers. This way link-state and traffic engineering information can be extracted and shared with the ODL controller.

OpenFlow switch as a PE router

In our project, the task of PE router is undertaken by OF switch. The switch is responsible for pushing right labels on the packet with the help of the Open Flow protocol. The original intent was to use the link-state information gathered from BGP-LS to provision LSPs across MPLS network with the conventional RSVP-TE protocol. But integrating RSVP into OpenFlow was not possible, as an OF switch does not support RSVP and packets coming with RSVP labels from OF switches were not accepted in the core MPLS network consisting routers. Thus, provisioning LSPs with a centralized controller was not feasible.

 

An alternative solution via SPRING

SPRING was an alternative to solve this problem as SPRING segments can be pushed on a packet with the help of the OpenFlow protocol. Intermediate routers do not care if these segments are coming from an OF switch or a router. As long as the right stack of labels is pushed on the packet, the router performs a lookup followed by a ‘’POP’’ operation. After completing this “POP” operation, the packet is then directed over the decided path. Global and Adjacent segments help router in determining which path to take in the network. Each router and each link gets its segment identifier (SID). These Segments can be either Global segments like 10, 20, etc. (Refer to Fig. [4]) or Local Segments which are associated only with the link.

 

SDN Controller: brain of the network

While the OF switch does not understand any of IGP protocol logic, the controller has all information from BGP-LS, and it uses this information to define flows. The task of an OF switch is just to follow the commands sent by the controller, the brain of the network. The following diagram (Fig. [5]) gives you an idea of how it works practically:

Explanation of packet flow

When a packet arrives at PE1, it has three labels in the stack pushed by OVS1. PE1 looks at the packet and forwards it to P1 because PE1 knows the topmost label (800040) represent the Global SID for PE2, so it forwards in the direction of PE2. Even P1 and P2 are aware of this segment, so it is removed at P2 with the concept of Penultimate-Hop-Popping (PHP). P2 identifies 2nd segment (1000123) as local to the link between P2 and PE2. Thus P2 removes the inner segment again with the same logic of PHP. Finally, PE2 forwards the packet to OVS2 with only one label which designates the VPN service. OVS2 then removes the last label with the help of flow definitions set by the controller.

For the return traffic, OVS2 becomes the ingress router and pushes the right stack of labels with packet arriving at OVS1 consisting of one label. In both the directions, initial PUSH or the final POP operation is performed with the help of the OpenFlow protocol and not with RSVP or LDP. A PE router usually does this in a conventional MPLS network, but it was achieved by the OF switch in this case.

Also, the decision about which label to PUSH or POP from the controller can be made with the help of the topology information gathered by BGP-LS extension for Segment Routing. This also indicates Node-SIDs and Adjacent SIDs used by routers in the MPLS core. Once this is known to a PCE server, PCE can initiate LSP creation and provision LSPs, or router can start an LSP creation and delegate control to PCE. However, the BGP-LS extension for SPRING has not been implemented within our project.

Results

Our project examines the feasibility of using an OpenFlow Switch and an SDN controller to fulfill the functionality of a PE router. Starting with static paths and then integrating with the routing protocols for the network to create flows that manipulate the labels like a PE-Router was based on the information learned from the traditional network. This deployment is one way to achieve integration with conventional networks. It provides benefits of inter-domain routing and adaptive path computation. All in all, it also gives a better way to utilize the current network resources.