Aricent Demystifying Routing Services SDN Whitepaper

8/11/2019 Aricent Demystifying Routing Services SDN Whitepaper

http://slidepdf.com/reader/full/aricent-demystifying-routing-services-sdn-whitepaper 1/12



1Demystifying Routing Services in Software-Dened Networking

DEMYSTIFYING ROUTING SERVICES IN SOFTWARE-DEFINED NETWORKING

Software-Dened Networking (SDN) decouples the control and data planes, enablinglimitless possibilities for implementing services and applications on top of the networkabstraction layer. The centralized controller provides a real-time, holistic view of the entireunderlying network infrastructure. Management of the agile network becomes moresimplied with this architecture.

The purpose of this paper is to discuss the Routing Application service in the context ofOpenFlow/SDN, and the idea of having the centralized routing control plane separatedfrom forwarding elements for more exible, 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 SDNenvironment and identifies the network topologies for deployment in OpenFlow andnon-OpenFlow networks.

IntroductionSoftware-Dened Networking (SDN) is rapidly emerging at the

forefront of next-generation networking. By decoupling thecontrol 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 visibilityand direct control over the underlying switches from a

centralized controller.

SDN follows a tiered architecture with a southbound interface

dened 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 applicationsand 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 basicnetwork functions such as network monitoring, traffic steering,

and route optimization.

This paper attempts to discuss the concept of having centralizedrouting control plane separated from forwarding elements for

more exible, intelligent and traffic engineered route control.

The paper talks about the Routing Service application in thecontext 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 requiredrouting 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 discoveredand 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 anyunknown 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 thenetwork. 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 anOpenFlow Island. An OpenFlow Island is dened as a group of

strongly connected OpenFlow switches under the sameOpenFlow controller. This data store-centric design helps in

the implementation of optimized routing services, such ascalculating the shortest path based on a consistent view of

network state and application-aware routing. This implementation

reduces complexity and controls interactions in order todistribute routes within a domain, as compared to traditional

routing protocols like iBGP, which requires route reection 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. Thereare 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 ProcessIn 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 hasspecial 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, asshown 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 overall its ports to other connected devices.

If the neighbor device is an OpenFlow switch, it performs a

ow lookup. Since the switch doesn’t have a ow entry for thisLLDP 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 ow 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 virtualnetworking topology consisting of virtual machines that run

traditional routing protocol. This module allows interoperability

between SDN controller and existing networks consisting oftraditional routers/switches running traditional routing protocols

such as OSPF/BGP. It determines the route adjacencies/

neighbors in non-OpenFlow (traditional routing) networks. Italso 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 anOpenFlow IslandThis section describes route calculation within an OpenFlow

Island comprising strongly connected OpenFlow hardware

switches controlled by the same OpenFlow controller. Thesubsections 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 LLDP

S2

Host 1 Host 2

S1 S3

OpenFlow Switch

LLDP

OpenFlow Control Path Data Path

1 2

3

1 1

22

3




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

Mapping multiple switches to a single virtual instance simplies

the network as the neighboring devices or domains treat theaggregated 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 makessignaling scalable and simplies management.

Heterogeneous Network Topology with OpenFlow and

Non-OpenFlow IslandsThe routing Service application proposes use of one virtual

routing entity aggregated for an OpenFlow Island comprising

OpenFlow switches under the same instance of OpenFlowcontroller. The virtual routing entity runs t raditional 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 addressindicating 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 applicationvia 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 areupdated 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 congures corresponding ow entry in the owtables 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

u onomous ys em rea

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

ggrega eOSPF/BGP

AggregatedOSPF/BGP

OF Controller

One AggregatedOSPF/BGP instance

for the completeOpenFlow Island

OpenFlow

OpenFlow N/W

OpenFlow

OpenFlow OpenFlowSwitchesOpenFlow

Switches

IF3

IF1 IF2

IF6IF4 IF7

IF5 IF8

DBRoutingService

OF Controller DBRoutingService




OpenFlow

OpenFlowSwitches


on- pen ow s an runn ng ra ona rou ng pro oco s :

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

Autonomous System 1/Area 1

OpenFlow N/W IslandOpenFlow N/W Island

Autonomous System 4/Area 4

AutonomousSystem 2/Area 2

AggregatedOSPF/BGP

OpenFlow

OpenFlowSwitches

OSPF/BGP OSPF/BGP

OSPF/BGP

OSPF/BGPOSPF/BGPIF4IF3

IF1 IF7

IF2 IF8


AutonomousSystem 3/Area 3

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 ofdestinations. In case there are several routes to the same

destination that have the same degree of preference, thetiebreaking 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 staticconguration 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 onL4-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 leis 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 theresource consumption and improve the user experience.

The subsections below describe some of the use casesmentioned above, in detail, and present a comparative study

with traditional non-OpenFlow networks.

Dynamic RoutingPath Adjustment

Pre-calculatingAlternate Routes

Automatic RouteReconguration

Automatic TrafficShaping

Application-AwareRouting

Virtual MachineMovement

Use CasesThe routing Service application implemented as a centralizedrouting 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 destinationand enable load balancing among these multiple routes chosen

for the same destination, as shown in Figure 6. Load balancingcan be achieved based on dynamic attributes, such as line

traffic load, link quality, etc. Multipath routing also increasesthe probability of having at least one working path.

Pre-Calculation of Alternate Path: Traditional vs.

OpenFlow NetworkIn traditional routing protocols such as BGP, the alternate paths

are not advertised by route reectors so the re-convergence

processing time is dependent on protocol-specific updateadvertisements and best-path re-calculations. This is a side

effect of using route reectors, as they hide alternate paths.

With the software-defined Routing Service application inOpenFlow 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 availablewith 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 andrepair in traditional routing protocols.




AggregatedOSPF/BGP

Aggregated OSPF/BGPAutonomous System 1/Area 1

OF ControllerDB

Routing

Service

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 ofdynamic attributes likeline traffic load, link quality

Best path route calculatedby conventional routingprotocol based on certainstatic 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 wouldbe learnt with delay andalternate path shall becalculated after next hopdown

IF3 IF6

IF4 IF7

IF5 IF8





OAM techniques can beused to detect routing-pathfailure and immediatelyswitch to an alternate pathpre-calculated beforehandto minimize trafficconvergence

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 likeoperations, 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 multiplecontrollers to save our customers the effort of having to

integrate across different platforms.

Aricent’s OpenFlow client is a portable implementation of theOpenFlow 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 thepower of our award-winning L2/ L3 Intelligent Switching

Solution (ISS) framework to provide OpenFlow capabilities.

Our client framework is compatible with hybrid and pureOpenFlow switches and can be easily integrated into enterprise,

transport, and data center networks.

www.aricent.com/software/software-dened-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-Dened Networking

REFERENCES

(1) Open Networking Foundation

(2) OpenStack Foundation

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

(4) OpenFlow Switch Specication

(5) IEEE 802.1AD Specications for LLDP

(6) Floodlight Controller open source project

SAURABH KUMAR SHARMA

is Principal Systems Engineer,

Technology at Aricent. He has over11 years of experience across

multiple technologies, including

Datacom and DatacenterTechnologies, Carrier/Enterprise/

Metro Ethernet & VoIP.

[email protected]

GAUTAM KHETRAPAL

is Engineering Project Manager at

Aricent. He has over 9 years ofdevelopment experience in the

Datacom domain and has workedon product development lifecycleof Enterprise Routers and Switches

and MSPP platforms.

[email protected]

Aricent Demystifying Routing Services SDN Whitepaper

Documents

Transcript of Aricent Demystifying Routing Services SDN Whitepaper