In current generation where all people are obsessed with mobile device and having mentality of “always stay connected”,SDN plays a major role.
OpenFlow based SDN technologies enable IT to address the some important aspects like high bandwidth, flexible QoS ,policy information, dynamic nature of today's applications, adaption of new network approaches to ever-changing business needs, and significantly reduce operations & management complexities. A network can have multiple SDN domains,each controlled by individual SDN controller.In today’s generation where networks are moving rapidly towards cloud architecture (data centers) ,SDN plays one of the key enabler of this.To utilize the resources efficiently ,SDN controllers need to communicate with each other which is the main discuss point in this seminar.
3. Introduction
❖ SDN is a new and increasingly
popular network architecture
❖ Main aim is to decoupling control
plane and data plane
❖ OpenFlow is a preferred protocol
SDN network
❖ Control Plane
❖ Data Plane
❖ Application layer for management
and services
(Ref:
http://www.tcs.com/SiteCollectionDocuments/White%20Papers/Inter-SDN- Controller
-Communication-Border-Gateway-Protocol-0314-
1.pdf)
4. Motivation
❖ Scalability issue
A single controller might not be enough to service all nodes in the network. It would become a
bottleneck in terms of processing power, memory, or input/output bandwidth.
❖ Bandwidth
❖ single point failure
5. Architecture-1
Vertical Approach :
❖ Proposed by Deepankar Gupta and
Rafat Jahan -Working @TCS
❖ IDEA : Master controller over the individual
network controllers
❖ master controller, interfaces with the underlying
controllers using RESTFul APIs.
❖ Though this approach can work for data centers,
problems may arise if this model is to be scaled up in
an enterprise spread across different locations and
geographies. (Vertical Approach to Inter-SDN Controller Communication)
(Ref:http://www.tcs.com/SiteCollectionDocuments/White%20Papers/Inter-SDN-Controller-Communication-Border-Gateway-Protocol-0314-
1.pdf)
6. Architecture-1 Continue...
Horizontal Approach :
SDN east-west interface:Each controller can request for information or connections from its peers,
that is, SDN controllers from other domains in the network.
7. Architecture-1 Continue ...
❖ The SDN east-west interface should
be able to coordinate the path setup
requirement across multiple SDN
domains
❖ Controllers need to exchange
information such as:
❖ Reachability update
❖ Flow setup, tear-down, and
update
❖ requests
❖ Capability Update
8. Protocols:
❖ A session needs to be established between the two controllers by using either BGP2 or Session
Initiation Protocol (SIP) over Transmission Control Protocol (TCP) to exchange information.
❖ Recommended Approach :BGP
9. Architecture-2
Disco Architecture :
❖ DISCO is a distributed multi-domain
SDN control plane which enables the delivery of
end-to-end network services.
❖ DISCO controller is in charge of a network
domain and communicates with neighbor
domains.
❖ composed of two parts
➢ Intra-domain
➢ Inter-domain
10. Architecture-2 Continue...
Intra-domain :
❖ Monitor the network and manage the flow prioritization which help controller to compute the
route of priority flows.
❖ dynamically react to network issues (broken link, high latency, bandwidth cap exceeded, . . . )
by redirecting and/or stopping traffic according to the criticality of the flow.
Inter-Domain :
A DISCO controller communicates with neighbor domain controllers to exchange aggregated network-
wide information.
11. Protocols :
SDN controllers provide OpenFlow driver to implement the OpenFlow protocol, a switch manager and
host manager to keep track of the different network elements, and link discovery implementing LLDP
(Link Layer Discovery Protocol).
Messenger :
❖ implements a unique control channel between neighboring domains.
❖ Messenger provides an open communication bus on top of which any agents can be plugged
dynamically. It can subscribe to topics published by other agents and start publishing on any
topic.
❖ Advanced Message Queuing Protocol (AMQP) as a base for the implementation of Messenger.
12. AMQP Protocol
❖ open standard and a thin application layer protocol for message-oriented middleware.
❖ offers built-in features for message orientation, queuing with priority, routing (including point-to-
point and publish-and-subscribe), reliable delivery and security.
Advantage :
Being lightweight, highly controllable and software-oriented ,can be used for cloud management.
used in OpenStack for loosely coupled communication between the different components.
Disadvantage :
it makes the implementation of Messenger more complex.
13. Architecture-2 Continue...
Agents :
support QoS routing and reservation functionalities
4 Main agents
Connectivity agent :
❖ charge of sharing with all the other domains the presence of peering links with neighboring
domains.
❖ sends information only if a new domain is discovered or a peering link changes.
❖ Store information in extended database.
Reachability agent :takes care, like RSVP, of inter-domain flow setup, teardown and update
request including application capability requirement such as QoS, bandwidth, latency, etc.
14. Architecture-3
DevoFlow:
Motivation :
❖ SDN / OpenFlow can enable per-flow management… However…• What are the costs and
limitations?
❖ always collecting all flows’ stat.s?
❖ what about controller’s scalability ?
Proposal :
❖ DevoFlow to enable scalable flow mgmt by balancing
➢ Network control
➢ Statistics collection
➢ Overheads
➢ Switch functions and controller loads
❖ DevoFlow uses 10–53 times fewer flow table entries at an average switch, and uses 10–42
times fewer control messages
15. Architecture-3 Continue..
❖ The controller maintains control over only targeted significant flows and has visibility over only
these flows and packet samples.
❖ DevoFlow is designed for simple and cost-effective hardware implementation
Our design principles are:
❖ Keep flows in the data-plane as much as possible. Involving the control-plane in all flow setups
creates too many overheads in the controller, network, and switches.
❖ Maintain enough visibility over network flows for effective centralized flow management, but
otherwise provide only aggregated flow statistics.
❖ Simplify the design and implementation of fast switches while retaining network
programmability.
16. Architecture-3 Continue..
Rule Cloning :
❖ Under the standard OpenFlow mechanism for wildcard rules, all packets matching a given rule
are treated as one flow.
❖ “action” part of a wildcard rule with a boolean CLONE flag.
❖ If the flag is clear, the switch follows the standard wildcard behavior. Otherwise, the switch
locally “clones” the wildcard rule to create a new rule in which all of the wildcarded fields are
replaced by values matching this microflow, and all other aspects of the original rule are
inherited.
❖ Subsequent packets for the microflow match the microflow-specific rule, and thus
contribute to microflow-specific counters.
17. Architecture-3 Continue..
Local actions:
❖ Certain flow-setup decisions might require decisions intermediate between the heavyweight
“invoke the controller” and the lightweight “forward via this specific port” choices offered by
standard OpenFlow.
❖ “local routing actions” that a switch can take without paying the costs of invoking the controller.
18. Advantages/Disadvantages
Advantages :
❖ Bandwidth on Demand
❖ Content Delivery Networks :Source SDN controller will need to communicate with the other
SDN controllers within the network to negotiate a path to the best possible CDN server that can
meet the customer's QoS needs.
❖ Scalability. A single controller might not be enough to service all nodes in the network. It would
become a bottleneck in terms of processing power, memory, or input/output bandwidth.
❖ Fault tolerance.
❖ minimize overhead
Disadvantages:
❖ issues in security and trust mechanism
19. Reference
[1] Distributed Multi-domain SDN Controllers (http://arxiv.org/pdf/1308.6138.pdf)
[2] Inter-SDN Controller Communication: Using Border Gateway Protocol (
http://www.tcs.com/SiteCollectionDocuments/White%20Papers/Inter-SDN-Controller-Communication-Border-Gateway-Pro
tocol-0314-
1.pdf)
[3] DevoFlow: Scaling Flow Management for High-Performance Networks (
http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p254.pdf)