Demystifying Routing Services in Software-Deﬁned Networking · . Demystifying Routing Services in...

Demystifying Routing Servicesin Software-Defined NetworkingGAUTAM KHETRAPALEngineering Project Manager, Aricent

SAURABH KUMAR SHARMA Principal Systems Engineer, Technology, Aricent

www.aricent.com

1Demystifying Routing Services in Software-Defined Networking

DEMYSTIFYING ROUTING SERVICES IN SOFTWARE-DEFINED NETWORKINGSoftware-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 Routing Application service in the context of OpenFlow/SDN, and the idea of having the centralized routing control plane separated from forwarding elements for more flexible, intelligent, and traffic-engineered route controland eliminating the inefficiencies and complexities of traditional routing protocols. This paper also looks at potential use cases for the Routing Service application in an SDN environment and identifies the network topologies for deployment in OpenFlow and non-OpenFlow networks.

IntroductionSoftware-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 OpenFlow 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 Routing Service application in the

context of OpenFlow/SDN.

Design Details

ARCHITECTURE OVERVIEW

Routing Service is an intelligent application based on OpenFlow

architecture. It takes an OpenFlow-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.


> Link Discovery between OpenFlow Nodes – The links

connecting the OpenFlow nodes (OpenFlow switches) are

discovered using traditional Link Layer Discovery Protocol,

LLDP (802.1AB). The status of physically operational links

between any two nodes of an OpenFlow Island is discovered

and maintained by the Link Discovery module.

> Link Discovery between Edge OpenFlow Node and Host –

This is responsible for deriving the connectivity to any host

from the edge OpenFlow node in the OpenFlow Island.

This procedure is triggered by the controller when any

unknown traffic enters the OpenFlow 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

OpenFlow neighbors of a given OpenFlow 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.

With this centralized control, the application is capable of

building a global view of the topology of all the OpenFlow

switches connected to the same OpenFlow controller in an

OpenFlow Island. An OpenFlow Island is defined as a group of

strongly connected OpenFlow switches under the same

OpenFlow 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

Routing Application service

The Routing Service application has contains three modules:

> Link Discovery

> Topology Manager

> Virtual Routing 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:

Figure 1: Architecture of Routing Service application in OpenFlow based SDN

Routing Service

Controllers

Rest API

OpenFlow

OpenFlow ClientOFSwitch

(A) Flow Table


(B) Flow TableData Path

Link Discovery

Topology Manager

Virtual Routing Engine(traditional routing

protocols: BGP/OSPF)

DB

Controller (FloodLight, TREMA, NOX, POX)

Host 1

Host 3

Host 2

Host 4OpenFlow ClientOF

Switch(C) Flow Table


(D) Flow Table


The Discovery Process

In an OpenFlow network, the Routing Service 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 Routing Service 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 OpenFlow 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 Routing Service application can

push down different flow entries for each switch, depending

upon the traffic application.

The Topology Manager creates the logical OpenFlow Islands,

determining the shortest path between two OpenFlow nodes

or between OpenFlow node and host. It also builds the global

Topology Database at the controller, which contains the shortest

(and alternate) path information to any OpenFlow node or host.

Virtual Routing Engine

The function of the Virtual Routing 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 OSPF/BGP. It determines the route adjacencies/

neighbors in non-OpenFlow (traditional routing) networks. It

also defines the Edge Router of a traditional network as the

NextHop to the OpenFlow Island. This module updates the

Topology Database to store shortest/alternate paths from

OpenFlow Island to NextHop.

Route Calculation within an OpenFlow IslandThis section describes route calculation within an OpenFlow

Island comprising strongly connected OpenFlow hardware

switches controlled by the same OpenFlow controller. The

subsections below list the functions for building the shortest

routes between any two OpenFlow data paths in an OpenFlow

Island.

Figure 2: Discovery Process

OpenFlow Controllers

OFPT_PACKET_OUTwith LLDP

OFPT_PACKET_OUT:OpenFlow Protocol Packet_Out Message

OFPT_PACKET_IN:OpenFlow Protocol Packet_In Message

OFPT_PACKET_OUTwith LLDP

Packet_in OFPT_PACKET_IN

LLDP LLDPS2

Host 1 Host 2

S1 S3

OpenFlow Switch

LLDP

OpenFlow Control Path Data Path

1 2

3

1 1

22

3

BGH34267

Highlight

Arrow on grey dotted should be from S3 to controller


> 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 OpenFlow Island, the Routing Service application can

discover connectivity between OpenFlow switches through the

link discovery protocol and build a global view of the topology

for the shortest-path route calculation. This way, intra-domain

If the neighbor device is a non-OpenFlow 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 OpenFlow 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

OpenFlow switches to transmit broadcast packets that will

eventually be received on an OpenFlow 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

OpenFlow controller.

The Route Calculation process

The Topology Manager module computes the shortest path

forwarding within the OpenFlow 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 destination-

rooted trees to identify the shortest path between any two

OpenFlow switches (as shown in Table 1).

Table 1: Destination-Rooted Trees

Root Node Src Dest. Path

S1

S1 S1 Cost=0, Link=NULL

S1 S2 Cost=1, Link [src=MAC_S1, outPort=3, dst=MAC_S2, inPort=1]


S2




S3




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 OpenFlow 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 OpenFlow switch (A)

> Packet is forwarded from Switch (A) to the OpenFlow

controller as there is no flow entry in flow table; initially no flow

entry is configured in the flow table for any specific host


The following sections discuss the topologies in homogenous

and heterogeneous networks.

Homogeneous Network Topology with pure OpenFlow Island

In this scenario, there can be a single aggregated Routing

instance of BGP or OSPF representing the whole bundle of

OpenFlow switches within an OpenFlow Island. This eliminates

the need for a routing instance for each of the OpenFlow 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 OpenFlow and

Non-OpenFlow Islands

The routing Service application proposes use of one virtual

routing entity aggregated for an OpenFlow Island comprising

OpenFlow switches under the same instance of OpenFlow

controller. The virtual routing entity runs traditional routing

protocol such as, BGP, or OSPF to interoperate with non-

OpenFlow networks running traditional routing protocols.

> The OpenFlow controller initiates ARP request to resolve

the MAC address corresponding to the destination IP.

OpenFlow Switch (D) responds back with its MAC address

indicating that the destination IP is reachable through itself

> Path reachability of destination Host 4 IP through OpenFlow

switch (D) is passed on to the Routing Service application

via REST API interface. Routing service application processes

this information and computes the shortest path to reach

OpenFlow 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

> Routing Service application informs the OpenFlow

controller to configure the best path route in all the

OpenFlow switches using the REST APIs. OpenFlow

controller configures corresponding flow entry in the flow

tables of each OpenFlow hardware switch

> All subsequent traffic is routed through the OpenFlow switch

For inter-domain route distribution to other OpenFlow or non-

OpenFlow Islands, the Routing Service application can leverage

and extend traditional routing protocols such as BGP and OSPF.

Figure 3: Data Flow Using Routing Service Application

Routing Service

Controllers

Rest API

Pkt 1 OUT

OpenFlow


(A) HW Table


(B) HW TableData Paths

Link Discovery

Topology Manager

Virtual Routing Engine(traditional routing

protocols: BGP/OSPF)

Pkt 1 IN

DB

Controller (FloodLight, TREMA, NOX, POX...)

Host 1

Host 3

Host 2

Host 4OpenFlow ClientOF

Switch(C) HW Table


(D) HW Table

4

2 3

5

6

1

MACDA

MACSA

Len ... Src IPH1

Dst IPH4

Data...


Figure 4: Homogeneous Network Topology with pure OpenFlow Island

Figure 5: Heterogeneous Network Topology with OpenFlow and Non-OpenFlow Islands

Autonomous System 1/Area 1

Autonomous System 2/Area 2 Autonomous System 3/Area 3

AggregatedOSPF/BGP

AggregatedOSPF/BGP

OF Controller

One AggregatedOSPF/BGP instance

for the completeOpenFlow Island

OpenFlow

OpenFlow N/W

OpenFlow

OpenFlow OpenFlowSwitchesOpenFlow

Switches

IF3

IF1 IF2

IF6

IF4 IF7

IF5 IF8

DBRoutingService

OF Controller DBRoutingService




OpenFlow

OpenFlowSwitches


Non-OpenFlow N/W Island running traditional routing protocols: BGP/OSPF

Non-OpenFlow N/W Island running traditional routing protocols: BGP/OSPF


OpenFlow N/W IslandOpenFlow N/W Island



AggregatedOSPF/BGP

OpenFlow

OpenFlowSwitches

OSPF/BGP OSPF/BGP

OSPF/BGP

OSPF/BGPOSPF/BGPIF4IF3

IF1 IF7

IF2 IF8



OSPF/BGP OSPF/BGP

OSPF/BGP

OSPF/BGPOSPF/BGPIF6IF5


Load Balancing: Traditional vs. OpenFlow 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 Routing 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.

The subsections below describe some of the use cases

mentioned above, in detail, and present a comparative study

with traditional non-OpenFlow networks.

Dynamic RoutingPath Adjustment

Pre-calculatingAlternate Routes

Automatic RouteReconfiguration

Automatic Tra�cShaping

Application-AwareRouting

Virtual MachineMovement

Use CasesThe routing Service 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 OpenFlow based intelligent routing

service application include:

In contrast, the OpenFlow-based Routing Service 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.

OpenFlow 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 Routing Service application in

OpenFlow architecture, there is a provision to maintain alternate

paths across domains/areas because each of the OpenFlow

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.


AggregatedOSPF/BGP

Aggregated OSPF/BGPAutonomous System 1/Area 1


Autonomous System1/Area 1

Traditional N/W

OpenFlow N/W

IF1 IF2

IF1 IF2

OSPF/BGPIF6

IF7IF4

IF8IF5

IF3OSPF/BGP

OSPF/BGP





IF3 IF6

IF4 IF7

IF5 IF8





Load balancing by routing service on the basis of dynamic attributes like line tra�c load, link quality

Best path route calculated by conventional routing protocol based on certain static attributes

Figure 6: Load Balancing: Traditional vs. OpenFlow N/W


Aggregated OSPF/BGPAggregated OSPF/BGP

AggregatedOSPF/BGP




Best route as per routing protocolTraditional N/W

OpenFlow N/W

IF1 IF2

IF1 IF2

OSPF/BGPIF6

IF7IF4

IF8IF5

IF3OSPF/BGP

OSPF/BGP



Site/NextHop down would be learnt with delay and alternate path shall be calculated after next hop down

IF3 IF6

IF4 IF7

IF5 IF8





OAM techniques can be used to detect routing-path failure and immediately switch to an alternate path pre-calculated beforehand to minimize tra�c convergence

Figure 7: Pre-calculation of Alternate Path: Traditional vs. OpenFlow N/W


Aricent’s SDN ExpertiseAricent’s SDN expertise covers the gamut of SDN technologies,

including OpenFlow 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 OpenFlow client is a portable implementation of the

OpenFlow client functionality and is compliant with version

1.3.0 of the OpenFlow Switch Specification. Our OpenFlow

client can be deployed in both pure and hybrid OpenFlow

network environments. Aricent’s OpenFlow Client extends the

power of our award-winning L2/ L3 Intelligent Switching

Solution (ISS) framework to provide OpenFlow capabilities.

Our client framework is compatible with hybrid and pure

OpenFlow switches and can be easily integrated into enterprise,

transport, and data center networks.

www.aricent.com/software/software-defined-networking.html

ACRONYMS

API Application Programming Interface

ARP Address Resolution Protocol

AS Autonomous System

eBGP external Border Gateway Protocol

iBGP internal Border Gateway Protocol

ISS Intelligent Switching Software

LLDP Link Layer Discovery Protocol

OSPF Open Shortest Path First

QoS Quality of Service

RIB Routing Information Base

SDN Software-Defined Networking

REFERENCES

(1) Open Networking Foundation

(2) OpenStack Foundation

(3) Software-Defined Networking: The New Norm for Networks

(4) OpenFlow Switch Specification

(5) IEEE 802.1AD Specifications for LLDP

(6) Floodlight Controller open source project

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.

[email protected]

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 Switches

and MSPP platforms.

[email protected]

©

Aricent is the world’s #1 pure-play product engineering services and software firm. The

company has 20-plus years experience co-creating ambitious products with the leading

networking, telecom, software, semiconductor, Internet and industrial companies. The

firm's 10,000-plus engineers focus exclusively on software-powered innovation for the

connected world.

frog, the global leader in innovation and design, based in San Francisco is part of Aricent.

The company’s key investors are Kohlberg Kravis Roberts & Co. and Sequoia Capital.

[email protected]

Engineering excellence.Sourced

2014 Aricent. All rights reserved.

All Aricent brand and product names are service marks, trademarks, or registered marks of Aricent in the United States and other countries.

Demystifying Routing Services in Software-Deﬁned Networking · . Demystifying Routing Services in...

Documents

Transcript of Demystifying Routing Services in Software-Deﬁned Networking · . Demystifying Routing Services in...