DEMYSTIFYING ROUTING

SERVICES IN SOFTWARE-
DEFINED NETWORKING
SAURABH KUMAR SHARMA
Principal Systems Engineer, Technology, Aricent
GAUTAM KHETRAPAL
Engineering Project Manager, Aricent
1 Demystifying Routing Services in Software-Dened Networking
DEMYSTIFYING ROUTING SERVICES IN
SOFTWARE-DEFINED NETWORKING
Software-Dened 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
simplied 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 exible, intelligent, and trafc-engineered route control
and eliminating the inefciencies 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.
Introduction
Software-Dened 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 ofering administrators network-wide visibility
and 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 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, trafc steering,
and route optimization.
This paper attempts to discuss the concept of having centralized
routing control plane separated from forwarding elements for
more exible, intelligent and trafc 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 thats separated
from the forwarding switches in order to focus on the required
routing decision process and routing controlfrom a large
service providers perspective.
2 Demystifying Routing Services in Software-Dened Networking
> 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 trafc 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 dened 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 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. 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 Client OF
Switch
(A)
Flow Table
OpenFlow Client OF
Switch
(B)
Flow Table
Data 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 4
OpenFlow Client OF
Switch
(C)
Flow Table
OpenFlow Client OF
Switch
(D)
Flow Table
3 Demystifying Routing Services in Software-Dened Networking
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
ow lookup. Since the switch doesnt have a ow 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 diferent ow entries for each switch, depending
upon the trafc 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 Island
This 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_OUT
with LLDP
OFPT_PACKET_OUT:
OpenFlow Protocol Packet_Out Message
OFPT_PACKET_IN:
OpenFlow Protocol Packet_In Message
OFPT_PACKET_OUT
with 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
2 2
3
4 Demystifying Routing Services in Software-Dened Networking
> 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 Dijkstras 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 Dijkstras 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]
S1 S3 Cost=1, Link [src=MAC_S1, outPort=2, dst=MAC_S3, inPort=2]
S2
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
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
In Figure 2, when the host H1 starts sending the trafc 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 nd the MAC address
of the destination host:
> Host H1 sends data packet with destination IP of host H2.
> Since the switch S1 has no ow congured 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 dened as per the software
by having a single control unit. The centralized control unit
makes signaling scalable management.
Sample Data ow
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 ow entry in ow table; initially no ow
entry is congured in the ow table for any specic host
5 Demystifying Routing Services in Software-Dened Networking
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 simplies
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 simplies 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 congures corresponding ow entry in the ow
tables of each OpenFlow hardware switch
> All subsequent trafc 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
OpenFlow Client OF
Switch
(A)
HW Table
OpenFlow Client OF
Switch
(B)
HW Table
Data 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 4
OpenFlow Client OF
Switch
(C)
HW Table
OpenFlow Client OF
Switch
(D)
HW Table
4
2
3
5
6
1
MAC
DA
MAC
SA
Len ... Src IP
H1
Dst IP
H4
Data...
6 Demystifying Routing Services in Software-Dened Networking
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
Aggregated
OSPF/BGP
Aggregated
OSPF/BGP
OF Controller
One Aggregated
OSPF/BGP instance
for the complete
OpenFlow Island
OpenFlow
OpenFlow N/W
OpenFlow
OpenFlow
OpenFlow
Switches
OpenFlow
Switches
IF3
IF1 IF2
IF6
IF4 IF7
IF5 IF8
DB
Routing
Service
OF Controller
DB
Routing
Service
OF Controller
DB
Routing
Service
One Aggregated
OSPF/BGP instance
for the complete
OpenFlow Island
OpenFlow
OpenFlow
Switches
OF Controller
DB
Routing
Service
Non-OpenFlow N/W Island running traditional routing protocols: BGP/OSPF
Non-OpenFlow N/W Island running traditional routing protocols: BGP/OSPF
Autonomous System 1/Area 1
OpenFlow N/W Island
OpenFlow N/W Island
Autonomous System 4/Area 4
Autonomous
System 2/Area 2
Aggregated
OSPF/BGP
OpenFlow
OpenFlow
Switches
OSPF/BGP OSPF/BGP
OSPF/BGP
OSPF/BGP OSPF/BGP
IF4 IF3
IF1 IF7
IF2 IF8
OF Controller
DB
Routing
Service
Autonomous
System 3/Area 3
OSPF/BGP OSPF/BGP
OSPF/BGP
OSPF/BGP OSPF/BGP
IF6 IF5
7 Demystifying Routing Services in Software-Dened Networking
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 Trafc Shaping and rate-limiting based on trafc
dynamics. This reduces/eliminates the need for static
conguration 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 le
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 Routing
Path Adjustment
Pre-calculating
Alternate Routes
Automatic Route
Reconguration
Automatic Trafc
Shaping
Application-Aware
Routing
Virtual Machine
Movement
Use Cases
The routing Service application implemented as a centralized
routing element can provide better controlled, advanced
routing capabilities while reducing operational expenses,
inefciencies, 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
trafc 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 reectors so the re-convergence
processing time is dependent on protocol-specific update
advertisements and best-path re-calculations. This is a side
efect of using route reectors, 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.
8 Demystifying Routing Services in Software-Dened Networking
Aggregated
OSPF/BGP
Aggregated OSPF/BGP Autonomous System 1/Area 1
OF Controller
DB
Routing
Service
Autonomous System
1/Area 1
Traditional N/W
OpenFlow N/W
IF1 IF2
IF1 IF2
OSPF/BGP IF6
IF7 IF4
IF8 IF5
IF3 OSPF/BGP
OSPF/BGP
Autonomous System
3/Area 3
Autonomous System
2/Area 2
One Aggregated
OSPF/BGP instance
for the complete
OpenFlow Island
IF3 IF6
IF4 IF7
IF5 IF8
OF Controller
DB
Routing
Service
Autonomous System
2/Area 2
Autonomous System
3/Area 3
OF Controller
DB
Routing
Service
Load balancing by routing
service on the basis of
dynamic attributes like
line trafc 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
9 Demystifying Routing Services in Software-Dened Networking
Aggregated OSPF/BGP Aggregated OSPF/BGP
Aggregated
OSPF/BGP
Autonomous System
1/Area 1
OF Controller
DB
Routing
Service
Autonomous System
1/Area 1
Best route as per routing protocol Traditional N/W
OpenFlow N/W
IF1 IF2
IF1 IF2
OSPF/BGP IF6
IF7 IF4
IF8 IF5
IF3 OSPF/BGP
OSPF/BGP
Autonomous System
3/Area 3
Autonomous System
2/Area 2
Site/NextHop down would
be learnt with delay and
alternate path shall be
calculated after next hop
down
IF3 IF6
IF4 IF7
IF5 IF8
OF Controller
DB
Routing
Service
Autonomous System
2/Area 2
Autonomous System
3/Area 3
OF Controller
DB
Routing
Service
OAM techniques can be
used to detect routing-path
failure and immediately
switch to an alternate path
pre-calculated beforehand
to minimize trafc
convergence
Figure 7: Pre-calculation of Alternate Path: Traditional vs. OpenFlow N/W
10 Demystifying Routing Services in Software-Dened Networking
Aricents SDN Expertise
Aricents 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. Aricents 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 efort of having to
integrate across diferent platforms.
Aricents 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. Aricents 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-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 over
11 years of experience across
multiple technologies, including
Datacom and Datacenter
Technologies, Carrier/Enterprise/
Metro Ethernet & VoIP.
saurabh.sharma@aricent.com
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.
gautam.khetrapal@aricent.com
aricent.com 2013 Aricent Group. All rights reserved.
All Aricent brand and product names are service marks, trademarks, or
registered marks of Aricent Inc. in the United States and other countries.