DEMYSTIFYING ROUTING SERVICES IN SOFTWAREDEFINED NETWORKING

DEMYSTIFYING ROUTING SERVICES IN STWAREDEFINED NETWORKING GAUTAM KHETRAPAL Engineering Project Manager, Aricent SAURABH KUMAR SHARMA Principal Systems Engineer, Technology, Aricent

DEMYSTIFYING ROUTING SERVICES IN STWARE-DEFINED NETWORKING Software-Defined Networking (SDN) decouples the control and data planes, enabling limitless possibilities for implementing services and applications on top of the network abstraction layer. The centralized controller provides a real-time, holistic view of the entire underlying network infrastructure. Management of the agile network becomes more simplified with this architecture. The purpose of this paper is to discuss the Application service in the context of /SDN, and the idea of having the centralized routing control plane separated from forwarding elements for more flexible, intelligent, and traffic-engineered route control and eliminating the inefficiencies and complexities of traditional routing protocols. This paper also looks at potential use cases for the application in an SDN environment and identifies the network topologies for deployment in and non- networks. Introduction Software-Defined Networking (SDN) is rapidly emerging at the forefront of next-generation networking. By decoupling the control and data planes in network switches and routers, SDN enables the rapid innovation and optimization of routing and switching equipment. SDN greatly simplifies network management by offering administrators network-wide visibility and direct control over the underlying switches from a centralized controller. SDN follows a tiered architecture with a southbound interface defined by the protocol that enables the interaction between the control and data planes, and a northbound API that presents a network abstraction interface to the applications and management systems residing at the top. The decision making lies with the centralized controller. SDN applications are built on top of the controller. The tiered SDN architecture enables the implementation of intelligent applications and services, to which the network resources can be allocated on the fly. Northbound APIs enable basic network functions such as network monitoring, traffic steering, and route optimization. This paper attempts to discuss the concept of having centralized routing control plane separated from forwarding elements for more flexible, intelligent and traffic engineered route control. The paper talks about the application in the context of /SDN. Design Details ARCHITECTURE OVERVIEW is an intelligent application based on architecture. It takes an -based SDN approach to creating a logically centralized control plane that s separated from the forwarding switches in order to focus on the required routing decision process and routing control from a large service provider s perspective. Demystifying s in Software-Defined Networking 1

With this centralized control, the application is capable of building a global view of the topology of all the switches connected to the same controller in an Island. An Island is defined as a group of strongly connected switches under the same controller. This data store-centric design helps in the implementation of optimized routing services, such as calculating the shortest path based on a consistent view of network state and application-aware routing. This implementation reduces complexity and controls interactions in order to distribute routes within a domain, as compared to traditional routing protocols like ibgp, which requires route reflection to distribute ebgp routes between routers of the same AS. Figure 1 below depicts the design components of the proposed Application service The application has contains three modules: > Link Discovery > Topology Manager > Virtual Engine Link Discovery The Link Discovery module is responsible for discovering and maintaining the status of physical links in the network. There are two types of link discovery: > Link Discovery between Nodes The links connecting the nodes ( switches) are discovered using traditional Link Layer Discovery Protocol, LLDP (802.1AB). The status of physically operational links between any two nodes of an Island is discovered and maintained by the Link Discovery module. > Link Discovery between Edge Node and Host This is responsible for deriving the connectivity to any host from the edge node in the Island. This procedure is triggered by the controller when any unknown traffic enters the Island. The controller may use some broadcast Request and ACK mechanism like ARP to determine the reachability to the target host. The information collated by the Link Discovery module is used to build the neighbor database in the controller, capturing all the neighbors of a given node in that Island. Topology Manager The Topology Manager builds and maintains the topology information in the controller and calculates the routes in the network. This module uses the neighbor database to compute the network topologies based on information received from the Link Discovery module. Controllers Link Discovery Topology Manager Virtual Engine (traditional routing protocols: BGP/OSPF) Rest API Controller (FloodLight, TREMA, NOX, POX) Data Path Host 1 (A) Client Flow Table (B) Client Flow Table Host 2 Host 3 (C) Client Flow Table (D) Client Flow Table Host 4 Figure 1: Architecture of application in based SDN Demystifying s in Software-Defined Networking 2

The Topology Manager creates the logical Islands, determining the shortest path between two nodes or between node and host. It also builds the global Topology Database at the controller, which contains the shortest (and alternate) path information to any node or host. Virtual Engine The function of the Virtual Engine is to generate a virtual networking topology consisting of virtual machines that run traditional routing protocol. This module allows interoperability between SDN controller and existing networks consisting of traditional routers/switches running traditional routing protocols such as. It determines the route adjacencies/ neighbors in non- (traditional routing) networks. It also defines the Edge Router of a traditional network as the NextHop to the Island. This module updates the Topology Database to store shortest/alternate paths from Island to NextHop. Route Calculation within an Island This section describes route calculation within an Island comprising strongly connected hardware switches controlled by the same controller. The subsections below list the functions for building the shortest routes between any two data paths in an Island. The Discovery Process In an network, the application can perform the network discovery using Link Layer Discovery Protocol (LLDP), which is used by network devices to advertise their identity, capabilities, and neighbors. An LLDP frame has special multicast destination MAC and Ethertype identified by the network as an LLDP packet. The Link Discovery module of the application can initiate the network discovery. It sends the LLDP packet to all the connected switches via a packet_out message, as shown in Figure 2. This message instructs the switch to send the LLDP packet out to all of its ports. Once a switch receives the packet_out message, it sends the LLDP packets out over all its ports to other connected devices. If the neighbor device is an switch, it performs a flow lookup. Since the switch doesn t have a flow entry for this LLDP message, it sends the packet to the controller via a packet_in message. When the controller receives the packet_ in, it analyzes the packet and creates a connection in its discovery table for the two switches. All the remaining switches in the network also send a packet_in to the controller, thus creating a complete network topology. Based on this topology, the application can push down different flow entries for each switch, depending upon the traffic application. Controllers PT_PACKET_OUT with LLDP PT_PACKET_OUT with LLDP Packet_in PT_PACKET_IN 1 2 LLDP LLDP 3 3 S2 2 2 S1 LLDP S3 1 1 Host 1 Host 2 Control Path Data Path PT_PACKET_OUT: Protocol Packet_Out Message PT_PACKET_IN: Protocol Packet_In Message Figure 2: Discovery Process Demystifying s in Software-Defined Networking 3

If the neighbor device is a non- switch that is not under the control of the controller, link discovery can be performed using a broadcast packet mechanism. In this case, the traditional L2 switch consumes the LLDP packet coming from the switch and therefore does not trigger any corresponding packet_in message toward the controller. In order to cater to this scenario, the controller can instruct switches to transmit broadcast packets that will eventually be received on an switch and sent to controller via a packet_in message. Thus, a broadcast link can be established between two ports under the control of one controller. The Route Calculation process The Topology Manager module computes the shortest path forwarding within the network. This module develops routes based on the network topology using the information received from the discovery process. Using Dijkstra s algorithm, the module calculates the destinationrooted trees to identify the shortest path between any two switches (as shown in Table 1). > Once the controller knows the location of both sender and receiver on the network, it calculates the end-to-end path from the destination-rooted trees information and subsequently configures the same at all switches along the path. Based on the ARP resolution, the Topology Manager module keeps a track of the MAC addresses and the switch ports they are bound to. For each packet in which the destination MAC address has been discovered, a point-to-point route is calculated and a flow entry is added to each switch along the shortest path, as computed using Dijkstra s algorithm. Deployment Topologies OPENFLOW ISLAND Within an Island, the application can discover connectivity between switches through the link discovery protocol and build a global view of the topology for the shortest-path route calculation. This way, intra-domain Root Node Src Dest. Path S1 S1 Cost=0, Link=NULL S1 S1 S2 Cost=1, Link [src=mac_s1, outport=3, dst=mac_s2, inport=1] S1 S3 Cost=1, Link [src=mac_s1, outport=2, dst=mac_s3, inport=2] S2 S3 S2 S1 Cost=1, Link [src=mac_s2, outport=1, dst=mac_s1, inport=3] S2 S2 Cost=0, Link=NULL S2 S3 Cost=1, Link [src=mac_s2, outport=2, dst=mac_s3, inport=3] S3 S1 Cost=1, Link [src=mac_s3, outport=2, dst=mac_s1, inport=2] S3 S2 Cost=1, Link [src=mac_s3, outport=3, dst=mac_s2, inport=2] S3 S3 Cost=0, Link=NULL Table 1: Destination-Rooted Trees In Figure 2, when the host H1 starts sending the traffic to host H2, the MAC address of the destination host is unknown. This can be resolved using the ARP protocol. The steps below illustrate the ARP resolution process to find the MAC address of the destination host: > Host H1 sends data packet with destination IP of host H2. > Since the switch S1 has no flow configured for the destination IP, the switch wraps the frame into an packet and sends it to the controller for the forwarding decision. > The controller instructs the switch S1 to send ARP packet to host H2 in order to resolve its MAC address. > Host H2 responds back with its MAC address and the response is sent to controller. routing can be independently defined as per the software by having a single control unit. The centralized control unit makes signaling scalable management. Sample Data flow Figure 3 depicts the sample data forwarding path from Host 1 to Host 4. > Packet originated from Host 1, and destined for Host 4, enters switch (A) > Packet is forwarded from (A) to the controller as there is no flow entry in flow table; initially no flow entry is configured in the flow table for any specific host Demystifying s in Software-Defined Networking 4

Controllers Link Discovery Topology Manager Virtual Engine (traditional routing protocols: BGP/OSPF) 4 Rest API Controller (FloodLight, TREMA, NOX, POX...) 2 3 5 Data Paths Host 1 Pkt 1 IN 1 (A) Client HW Table (B) Client HW Table Host 2 MAC DA MAC SA Len... Src IP Dst IP H1 H4 Data... 6 Host 3 (C) Client HW Table (D) Client HW Table Host 4 Pkt 1 OUT Figure 3: Data Flow Using Application > The controller initiates ARP request to resolve the MAC address corresponding to the destination IP. (D) responds back with its MAC address indicating that the destination IP is reachable through itself > Path reachability of destination Host 4 IP through switch (D) is passed on to the application via REST API interface. service application processes this information and computes the shortest path to reach switch (D) for any packet destined to Host 4 IP. The centralized neighbor and topology databases are updated with corresponding information on link and shortest path to the Host 4 > application informs the controller to configure the best path route in all the switches using the REST APIs. controller configures corresponding flow entry in the flow tables of each hardware switch > All subsequent traffic is routed through the switch For inter-domain route distribution to other or non- Islands, the application can leverage and extend traditional routing protocols such as BGP and OSPF. The following sections discuss the topologies in homogenous and heterogeneous networks. Homogeneous Network Topology with pure Island In this scenario, there can be a single aggregated instance of BGP or OSPF representing the whole bundle of switches within an Island. This eliminates the need for a routing instance for each of the switches. Mapping multiple switches to a single virtual instance simplifies the network as the neighboring devices or domains treat the aggregated virtual instance as a single network element. This allows inter-domain or inter-zone routing to be converged into a centralized single unit. The centralized control unit makes signaling scalable and simplifies management. Heterogeneous Network Topology with and Non- Islands The routing application proposes use of one virtual routing entity aggregated for an Island comprising switches under the same instance of controller. The virtual routing entity runs traditional routing protocol such as, BGP, or OSPF to interoperate with non- networks running traditional routing protocols. Demystifying s in Software-Defined Networking 5

1/Area 1 Aggregated One Aggregated instance for the complete Island Aggregated IF1 IF2 es IF5 IF4 IF3 IF6 IF7 IF8 es 2/Area 2 3/Area 3 N/W Figure 4: Homogeneous Network Topology with pure Island Non- N/W Island running traditional routing protocols: BGP/OSPF Autonomous System 2/Area 2 One Aggregated instance for the complete Island N/W Island IF3 IF4 N/W Island Aggregated IF1 IF7 es IF2 Autonomous System 3/Area 3 IF8 es 1/Area 1 4/Area 4 IF5 IF6 Non- N/W Island running traditional routing protocols: BGP/OSPF Figure 5: Heterogeneous Network Topology with and Non- Islands Demystifying s in Software-Defined Networking 6

Use Cases The routing application implemented as a centralized routing element can provide better controlled, advanced routing capabilities while reducing operational expenses, inefficiencies, and complexities of traditional routing protocols. Some use cases for the based intelligent routing service application include: Load Balancing: Traditional vs. Network In traditional routing protocols, the decision process for route selection identifies a single best route to a specified set of destinations. In case there are several routes to the same destination that have the same degree of preference, the tiebreaking algorithm selects only one of these routes for inclusion in RIB. Dynamic Path Adjustment Pre-calculating Alternate Routes Automatic Route Reconfiguration Automatic Traffic Shaping Application-Aware Virtual Machine Movement > Dynamic Path Adjustment based on network load/ congestion or path quality. > Pre-calculating the alternate path and assigning priority to it based on quality of link and cost involved. This would be facilitated by the centralized route database with route/ neighbor information of all the routers in the network. > Automatic route reconfiguration when the physical link connection fails. During the link failure, the pre-calculated alternate paths on the dumb router nodes will be used, resulting in very fast switch-over. > Automatic Traffic Shaping and rate-limiting based on traffic dynamics. This reduces/eliminates the need for static configuration of QoS shaping/rate-limiting policies at each hop > Application-Aware routing that involves redirection of users content requests to the nearest content server, based on L4-L7 attributes such as protocol, port, IP address, etc. For example, a user requesting an on-demand video can be redirected/routed to the nearest data center where the file is hosted. > Movement of a virtual machine instance from one geographical location to another based on time zone and geographical location. This movement is done to optimize the resource consumption and improve the user experience. In contrast, the -based application can intelligently have multiple routes to the same destination and enable load balancing among these multiple routes chosen for the same destination, as shown in Figure 6. Load balancing can be achieved based on dynamic attributes, such as line traffic load, link quality, etc. Multipath routing also increases the probability of having at least one working path. Pre-Calculation of Alternate Path: Traditional vs. Network In traditional routing protocols such as BGP, the alternate paths are not advertised by route reflectors so the re-convergence processing time is dependent on protocol-specific update advertisements and best-path re-calculations. This is a side effect of using route reflectors, as they hide alternate paths. With the software-defined application in architecture, there is a provision to maintain alternate paths across domains/areas because each of the Islands has a global view of all the interconnections available with neighboring AS, as shown in Figure 7. The pre-calculated alternate path helps in accelerating re-convergence, enabling far better reaction times compared to failure detection and repair in traditional routing protocols. The subsections below describe some of the use cases mentioned above, in detail, and present a comparative study with traditional non- networks. Demystifying s in Software-Defined Networking 7

Traditional N/W 1/Area 1 Best path route calculated by conventional routing protocol based on certain static attributes IF1 IF2 IF3 IF6 IF4 IF7 2/Area 2 IF5 IF8 3/Area 3 1/Area 1 Aggregated One Aggregated instance for the complete Island IF1 IF2 Load balancing by routing service on the basis of dynamic attributes like line traffic load, link quality N/W Aggregated IF3 IF6 IF4 IF7 IF5 IF8 2/Area 2 3/Area 3 Figure 6: Load Balancing: Traditional vs. N/W Demystifying s in Software-Defined Networking 8

Traditional N/W 1/Area 1 Best route as per routing protocol Site/NextHop down would be learnt with delay and alternate path shall be calculated after next hop down IF1 IF2 IF3 IF6 IF4 IF5 IF7 IF8 2/Area 2 3/Area 3 N/W OAM techniques can be used to detect routing-path failure and immediately switch to an alternate path pre-calculated beforehand to minimize traffic convergence 1/Area 1 IF1 Aggregated IF2 Aggregated Aggregated IF3 IF6 IF4 IF7 IF5 IF8 2/Area 2 3/Area 3 Figure 7: Pre-calculation of Alternate Path: Traditional vs. N/W Demystifying s in Software-Defined Networking 9

Aricent s SDN Expertise Aricent s SDN expertise covers the gamut of SDN technologies, including and Application APIs. Our comprehensive controller suite includes support for critical functions like operations, administration, maintenance, lawful intercept, and optimized mobile backhaul. Aricent s SDN applications are built on top of the leading commercial SDN controllers. We are committed to supporting the applications on multiple controllers to save our customers the effort of having to integrate across different platforms. Aricent s client is a portable implementation of the client functionality and is compliant with version 1.3.0 of the Specification. Our client can be deployed in both pure and hybrid network environments. Aricent s Client extends the power of our award-winning L2/ L3 Intelligent ing Solution (ISS) framework to provide capabilities. Our client framework is compatible with hybrid and pure switches and can be easily integrated into enterprise, transport, and data center networks. GAUTAM KHETRAPAL is Engineering Project Manager at Aricent. He has over 9 years of development experience in the Datacom domain and has worked on product development lifecycle of Enterprise Routers and es and MSPP platforms. gautam.khetrapal@aricent.com SAURABH KUMAR SHARMA is Principal Systems Engineer, Technology at Aricent. He has over 11 years of experience across multiple technologies, including Datacom and Datacenter Technologies, Carrier/Enterprise/ Metro Ethernet & VoIP. saurabh.sharma@aricent.com www.aricent.com/software/software-defined-networking.html REFERENCES ACRONYMS (1) Open Networking Foundation API ARP AS ebgp ibgp ISS LLDP OSPF QoS RIB SDN Application Programming Interface Address Resolution Protocol external Border Gateway Protocol internal Border Gateway Protocol Intelligent ing Software Link Layer Discovery Protocol Open Shortest Path First Quality of Information Base Software-Defined Networking (2) OpenStack Foundation (3) Software-Defined Networking: The New Norm for Networks (4) Specification (5) IEEE 802.1AD Specifications for LLDP (6) Floodlight Controller open source project Demystifying s in Software-Defined Networking 10