View
9
Download
0
Category
Preview:
Citation preview
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.
2Demystifying Routing Services in Software-Defined 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 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
OpenFlow ClientOFSwitch
(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
OpenFlow ClientOFSwitch
(D) Flow Table
3Demystifying Routing Services in Software-Defined 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
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
4Demystifying Routing Services in Software-Defined 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 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]
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 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
5Demystifying Routing Services in Software-Defined 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 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
OpenFlow ClientOFSwitch
(A) HW Table
OpenFlow ClientOFSwitch
(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
OpenFlow ClientOFSwitch
(D) HW Table
4
2 3
5
6
1
MACDA
MACSA
Len ... Src IPH1
Dst IPH4
Data...
6Demystifying Routing Services in Software-Defined 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
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
OF Controller DBRoutingService
One AggregatedOSPF/BGP instance
for the completeOpenFlow Island
OpenFlow
OpenFlowSwitches
OF Controller DBRoutingService
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 IslandOpenFlow N/W Island
Autonomous System 4/Area 4
Autonomous System 2/Area 2
AggregatedOSPF/BGP
OpenFlow
OpenFlowSwitches
OSPF/BGP OSPF/BGP
OSPF/BGP
OSPF/BGPOSPF/BGPIF4IF3
IF1 IF7
IF2 IF8
OF Controller DBRoutingService
Autonomous System 3/Area 3
OSPF/BGP OSPF/BGP
OSPF/BGP
OSPF/BGPOSPF/BGPIF6IF5
7Demystifying Routing Services in Software-Defined 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 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.
8Demystifying Routing Services in Software-Defined Networking
AggregatedOSPF/BGP
Aggregated OSPF/BGPAutonomous System 1/Area 1
OF Controller DBRoutingService
Autonomous System1/Area 1
Traditional N/W
OpenFlow N/W
IF1 IF2
IF1 IF2
OSPF/BGPIF6
IF7IF4
IF8IF5
IF3OSPF/BGP
OSPF/BGP
Autonomous System3/Area 3
Autonomous System2/Area 2
One AggregatedOSPF/BGP instance
for the completeOpenFlow Island
IF3 IF6
IF4 IF7
IF5 IF8
OF Controller DBRoutingService
Autonomous System2/Area 2
Autonomous System3/Area 3
OF Controller DBRoutingService
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
9Demystifying Routing Services in Software-Defined Networking
Aggregated OSPF/BGPAggregated OSPF/BGP
AggregatedOSPF/BGP
Autonomous System1/Area 1
OF Controller DBRoutingService
Autonomous System1/Area 1
Best route as per routing protocolTraditional N/W
OpenFlow N/W
IF1 IF2
IF1 IF2
OSPF/BGPIF6
IF7IF4
IF8IF5
IF3OSPF/BGP
OSPF/BGP
Autonomous System3/Area 3
Autonomous System2/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 DBRoutingService
Autonomous System2/Area 2
Autonomous System3/Area 3
OF Controller DBRoutingService
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
10Demystifying Routing Services in Software-Defined Networking
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.
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 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.
info@aricent.com
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.
Recommended