CIDC - An East-West interface for distributed SDN control plane
1. CIDC: AN EAST-WEST
INTERFACE FOR
DISTRIBUTED SDN
CONTROL PLANE
Sina Ebrahimi
Advisor: Saeed Jalili, PhD
Distributed Systems
2. OUTLINE
• Introduction
• Related Work
• Network model and description of CIDC
• Some implemented services in CIDC interface
• Experiments description
• Evaluation analysis
• Conclusion
1/21
3. INTRODUCTION
• What is SDN?
• Main idea: To remove the control plane (decisional part) from network
devices and shift it to a single controlling point.
2/21
Application
Plane
Control
Plane
Data Plane
4. INTRODUCTION
• Centralization of control provides an abstract topology view of the
underlying infrastructure to our network applications.
• Results: Simplification of network management and the development
of new services.
• Some challenges appear when the size of network grows:
• Scalability
• Performance
• Capacity of the controller to handle lots of requests
• Ability to scale geographically
3/21
5. INTRODUCTION
• Two main propositions of control plane design to tackle those latter
issues:
• Logically centralized design:
• Distributes the load between controllers and uses a shared database to unify
decisions
• Requires extensive synchronization between controllers
• Suitable for intra-domain network architecture
• Logically distributed design:
• Proposed to extend SDN for large distributed networks
• Each controller can manage its domain and distribute necessary data to other
controllers
• Usable in large data centers and WAN networks that suffer from high cost and
latency
• Suitable for inter-domain network architecture
4/21
6. INTRODUCTION
• Primary importance in logically distributed control planes:
• Communication between controllers
• This paper’s contribution:
• Providing an east-west interface called Communication Interface for Distributed
Control Plane (CIDC)
• CIDC provides:
• Communication modes (Notification, Service, and Full)
• New mechanism based on policy sharing to support distributed services such as
DFS or DLBS
5/21
7. RELATED WORK
• Many controllers use the logically centralized control approach
• Like ONIX, HyperFlow, and OpenDayLight
• ODL forms a cluster to support multiple controllers
• Not feasible for logically distributed architecture where each controller has its
own database
• Cluster consumes more resources to build information trees
6/21
8. RELATED WORK
• Some controllers use the logically distributed architecture
• Like SDNi, and East-West (EW) Bridge
• EW Bridge is designed to support different controllers with various local network
view storage systems (no shared db between controllers)
• EW Bridge uses Publish/Subscribe model to synchronize data
• Some challenges should be solved:
• Scalability under high load
• Sharing various services between controllers
• Security
7/21
9. NETWORK MODEL OF CIDC
• CIDC interface uses an event-driven paradigm
• When a modification is observed in data plane, new events are sent to the
controller and the interface starts sharing these events to other controllers.
8/21
10. NETWORK MODEL OF CIDC
• CIDC interface is used by each controller to synchronize its stats and
services with neighboring controllers
• Each controller plays the role of a Consumer for external events and a
Producer for internal events.
• 4 essential modules of CIDC :
• Producer
• Consumer
• DataUpdater
• DataCollector
9/21
12. NETWORK MODEL OF CIDC
• 3 Communication modes that will customize the role of each controller
in the network, and add (if necessary) fine-grained control of sensitive
domain.
11/21
13. IMPLEMENTED SERVICES IN CIDC INTERFACE
• Distributed Firewall Service
• Only Controller is able to inspect packets
• Forwarding device can be programmed to behave as a firewall
• Admin could apply his rules one time and the controller does the rest by
automatically exchanging these rules with other controllers (if necessary).
• Distributed Load Balancer Service
• DLBS shares LB rules to other domains using CIDC interface, allowing clients to
request for remotely available services.
12/21
Two
Approaches
15. EXPERIMENTS DESCRIPTION
• The experiment is a comparison of:
• OpenDayLight (Hydrogen Release)
• Uses cluster mode to build a logically centralized control plane
• FloodLight (with CIDC interface)
• Supports logically distributed control plane using CIDC
• Establishes full mesh connections between controllers
14/21
19. EVALUATION ANALYSIS
• Memory consumption
• Number of exchanging events in CIDC is optimized, and each controller
sends just its local events.
18/21
Memory Consumption in Claranet_4
topology
20. EVALUATION ANALYSIS
• Inter-controller communication overload
• ICO: Total rate of bidirectional traffic exchanged between controllers
• ODL replicates all data trees to all members to keep network consistent
• CIDC shares data based on configured mode, which reduces the amount of
data that the controller must distribute
19/21
21. CONCLUSION
• CIDC could synchronize notification and services without performance
penalty, and provide fine-grained control of events between controllers
• The vast majority of state changes and services could be synchronized lightly
and quickly
• The simulations showed good results of CIDC in terms of delay, overhead and
system consumption
20/21
22. REFERENCE PAPER
• An East-West interface for distributed SDN control plane
• Published in:
• Elsevier Journal:
• Computers and Electrical Engineering, Volume 57 Issue C
• January 2017
• Authors:
• (From University of Rabat, Morocco)
• Fouad Benamrane
• Moad Ben Memoun
• Redouane Benaini
21/21
Centralized Not suitable for large and highly distributed networks
In distributed: each domain is managed by its controller and can share only some useful info with other controllers to achieve some services such as topology view
Communication modes to exchange msg s between controllers and customize the desired behavior of each controller in network.
Pub/sub model originally addresses the problem of multicast or group messaging, it is used for SDN because it is more scalable than client-server model, and uses parallel operation and message caching to publish the message to the queue.
DataCollector sends network status to all connected Consumers for two reasons. First, to notify remote controllers that a local status has changed. Second, to synchronize data between controllers for distributed services.
Notification, the Producer notifies all remote Controllers when new changes occur in its domain.
Service, the Producer will share any activated services (SSL, Firewall, or Load Balancer).
Full mode is engaged, it shares all events and services.
Listeners in DataCollector…
Rule exists
Network Time protocol
Each domain is emulated in a VM
Each VM contains the local network composed by some Open vSwitches, several virtual hosts and a SDN controller.
Bandwidth between switches and hosts was 1 Gbps with 30ms one-way delay.
All VMs use NTP for clock synchronization to compute the performance metric
Generic Routing Encapsulation
Use of communication modes allows us to compromise between performance and fine-grained control for each domain
‘Bootstrapping’ phase it is where the controllers start and recognize their neighbors. In such case, ODL controllers form a cluster and share their database, and FL controllers use CIDC to establish full mesh connections.
‘Switch events’ phase is where each controller shares its switches with the others after it discovers a new switch.
‘Waiting interval’, and it is sometimes fixed to avoid pressure to the controller.
‘Hosts and flow_mod events’, is where each controller synchronizes its known hosts and flows with neighboring controllers.
Use of fine-grained control mechanism based on communication modes