Source-linked AI summary
DISCO: Distributed Multi-domain SDN Controllers
Kévin Phemius, Mathieu Bouet, Jérémie Leguay
TL;DR
Multi-domain SDN networks need control planes that remain resilient and scalable across heterogeneous domains without relying on a single point of failure. DISCO distributes controllers by domain and connects them through a lightweight agent-based channel for aggregated information exchange and end-to-end services. The evaluation demonstrates adaptation to disruptions and heterogeneous topologies across topology disruption, priority service, and virtual-machine migration use cases.
Problem
Distributed SDN control planes avoid single points of failure but were designed for datacenters, leaving multi-domain networks with heterogeneous inter-domain links insufficiently addressed.
Method
DISCO assigns one controller to each SDN domain and uses a lightweight, manageable AMQP-based control channel with dynamically pluggable agents.
Results
DISCO dynamically adapts to heterogeneous topologies, survives disruptions and attacks, and supports endpoint migration and network-wide traffic engineering across three evaluated use cases.
Takeaways & Limitations
Aggregated inter-domain information enables DISCO controllers to provide end-to-end network services across heterogeneous multi-domain networks.
Abstract
from arXiv · showhide
Modern multi-domain networks now span over datacenter networks, enterprise networks, customer sites and mobile entities. Such networks are critical and, thus, must be resilient, scalable and easily extensible. The emergence of Software-Defined Networking (SDN) protocols, which enables to decouple the data plane from the control plane and dynamically program the network, opens up new ways to architect such networks. In this paper, we propose DISCO, an open and extensible DIstributed SDN COntrol plane able to cope with the distributed and heterogeneous nature of modern overlay networks and wide area networks. DISCO controllers manage their own network domain and communicate with each others to provide end-to-end network services. This communication is based on a unique lightweight and highly manageable control channel used by agents to self-adaptively share aggregated network-wide information. We implemented DISCO on top of the Floodlight OpenFlow controller and the AMQP protocol. We demonstrated how DISCO's control plane dynamically adapts to heterogeneous network topologies while being resilient enough to survive to disruptions and attacks and providing classic functionalities such as end-point migration and network-wide traffic engineering. The experimentation results we present are organized around three use cases: inter-domain topology disruption, end-to-end priority service request and virtual machine migration.
I. INTRODUCTION
DISCO addresses the vulnerability and scalability limits of centralized or datacenter-oriented distributed SDN control planes in heterogeneous multi-domain networks. It organizes controllers per domain and connects them through a lightweight, extensible channel to exchange aggregated information and provide end-to-end services.
- Motivation: Multi-domain networks interconnect datacenters, enterprises, customer sites, and mobile entities, creating requirements for resilient, scalable, and extensible control.SDN separates software from physical layers, centralizes control information, and enables network programmability.
- Research gap: Existing distributed SDN control planes avoid a single point of failure and share controller load but were designed for datacenters requiring extensive information exchange.The paper targets multi-domain networks where inter-domain links can be heterogeneous.
- DISCO proposal: DISCO assigns each controller responsibility for one SDN domain and uses a unique lightweight, manageable channel with dynamically pluggable agents.Agents exchange aggregated network-wide information to support end-to-end services.
- Capabilities: DISCO adapts to heterogeneous topologies, supports endpoint migration and network-wide traffic engineering, and is designed to survive disruptions and attacks.It distinguishes high-capacity MPLS tunnels from SATCOM links with poor bandwidth and latency.
- Evaluation: The implementation uses Floodlight and AMQP, and evaluation covers inter-domain topology disruption, end-to-end priority service requests, and virtual machine migration.The related-work context includes open-source controllers and approaches that offload work toward the data plane.
III. DISCO ARCHITECTURE
DISCO separates intra-domain control functions from inter-domain communication while exposing interfaces for network elements and management systems. Controllers exchange aggregated network-wide information to support end-to-end flow management.
- Overall architecture: Each DISCO controller manages one network domain and communicates with neighboring domains to exchange aggregated information for end-to-end flow management.The architecture divides controller functionality into intra-domain and inter-domain parts.
- Overall architecture: The intra-domain part provides controller functionality, while the inter-domain part manages reservations, topology-state changes, and disruptions.A Core component starts, stops, updates, and connects the controller modules through a communication bus.
- Interfaces: Southbound SDN interfaces push policies to network elements and retrieve status, while the northbound interface accepts management policies, manages SLAs, and reports service status.The northbound interface can carry service and user priorities.
B. Intra-domain functionalities
DISCO combines intra-domain monitoring and flow control with inter-domain information exchange over a shared communication channel. Its modules and agents use stored topology, monitoring, and flow knowledge to compute routes and react to network conditions.
- B. Intra-domain functionalities: Intra-domain modules monitor networks and prioritize flows so routes can be computed from network-parameter state.They can react to broken links, high latency, or exceeded bandwidth caps by redirecting or stopping traffic according to flow criticality.
- B. Intra-domain functionalities: The Extended Database stores intra-domain and inter-domain knowledge about topology, monitoring, and ongoing flows for modules and agents to use when taking flow actions.The Monitor Manager collects switch throughput and measures one-way latency and packet loss on intra-domain links.
- C. Inter-domain functionalities: Neighboring controllers exchange aggregated network-wide information through a Messenger module and agents using a distributed publish/subscribe channel.Path Computation can use this information to identify the neighboring domain through which a host should be reached.
- C. Inter-domain functionalities: Messenger supports group and direct communication for status exchange and requested actions, including link-state updates, host presence, and reservations.AMQP provides queuing with priority, routing, reliable delivery, and security features for this channel.
- C. Inter-domain functionalities: The current federation-based Messenger implementation can route multiple copies of messages through different paths, increasing network footprint in large interconnected networks.The authors plan more efficient broadcast capabilities, such as a spanning tree.
- C. Inter-domain functionalities: Agents support inter-domain connectivity, QoS routing, and reservation by sharing peering-link presence and other network-wide information.The Connectivity agent sends updates when domains or peering links change.
D. Interoperability issues
DISCO can interoperate with non-SDN domains through classical IETF technologies while remaining agnostic to the SDN protocol and switch types. The current implementation is OpenFlow-based but is described as integrable with other equipment-management technologies.
- Interoperability: Border nodes may use BGP to exchange connectivity information with domains using classical IETF technologies.An additional BGP agent would manage this interoperability in the architecture.
- Interoperability: DISCO is agnostic to the SDN protocol and switches, although its current implementation uses OpenFlow and could be integrated with OnePK for Cisco equipment.The protocol-driver components are therefore the implementation-specific boundary described here.
IV. DISCO IMPLEMENTATION
DISCO’s implementation extends Floodlight with Messenger, a publish/subscribe inter-domain channel that discovers neighboring controllers, exchanges agent information, and detects failures.
- DISCO adds Java software modules to Floodlight, while its SDN protocol drivers remain empty for intra-domain and inter-domain management.
- Messenger uses RabbitMQ with AMQP federation and activates configurable agents that handle inter-domain exchanges.
- Messenger-LLDP extends LLDP to discover neighboring domain controllers and advertise controller, switch, port, and messaging-server information.
- The publish/subscribe channel supports direct controller topics, federation-wide topics, subscriptions, neighbor pairing, and message sending.
- Keep-alive messages run every 500ms, and three consecutive missing responses trigger controller-failure mitigation.
B. Agents implementation
DISCO agents exchange aggregated information between neighboring domains and store it for local modules to support network-wide decisions.
- Agents use Messenger to exchange information with neighboring domains, with four implemented agents: Monitoring, Reachability, Connectivity, and Reservation.
- Agents publish domain information on specific topics, such as remaining bandwidth advertised by a Monitoring agent.
- Received information from neighboring agents is stored in the extended Floodlight database for use by local decision-making modules.
V. EVALUATION
The evaluation tests DISCO’s classic network functions and resilience to control-plane and data-plane disruptions in a controlled multi-domain testbed.
- The evaluation covers QoS routing, reservation, pre-emption, and resilience to controller, inter-controller communication, and inter-domain link failures.
- The performance topology contains three domains, A, B, and C, each managed by a local DISCO controller coordinating with neighboring controllers.
- The testbed represents enterprise sites interconnected by different WANs, with user terminals or virtual machines attached to the domains.
- Mininet, Open vSwitch, separate controller virtual machines, and Linux tc provide an emulated topology with controlled link latencies and bandwidths.
B. Use Case 1: Adaptive information exchange
DISCO’s agents adapt inter-domain information exchange to congestion and link failure by rerouting monitoring traffic and reducing its frequency over weak links.
- Agents reduce control-plane network footprint by identifying alternative routes and lowering message frequency when no alternative exists.
- Monitoring normally sends information every 2s, but the period increases to 10s for weak interconnections.
- When the B–C link fails, monitoring traffic uses the weak A → C link at a lower frequency.
- During monitoring adaptation, traffic is shut down over the congested C ↔ A link while increasing elsewhere; after failure, traffic over B → A decreases because B ↔ C information is unnecessary.
- Controller failure handling severs unreachable control-plane links and can reconnect domains through another available path.
C. Use Case 2: Resource reservation and pre-emption
DISCO handles high-priority service reservations by rerouting an existing lower-priority flow, then reserving the released direct-link resources. The procedure completes quickly but temporarily increases the rerouted flow’s latency.
- At t = 25s, a higher-priority 8 Mbits/s flow requests reservation with a strict maximum latency constraint of 15 ms.
- Controllers currently exchange JSON messages for ease of development and integration, with compression planned for future releases.
- DISCO reroutes the established lower-priority flow through domain B so the direct A ↔C link can serve the priority flow.The direct link is the only suitable inter-domain path for the priority request.
- The reservation procedure took less than 500ms.
- After rerouting, the lower-priority flow’s latency significantly increases because it uses a longer route.
D. Use Case 3: Virtual Machine migration
DISCO supports virtual-machine migration across domains by updating reachability and host-to-domain mappings, enabling controllers to reroute ongoing flows. In the experiment, migration caused a brief interruption with limited packet loss and reduced latency afterward.
- When a migrated VM appears in a new domain, Reachability agents announce the change and controllers update host-to-domain mappings for path computation.
- 117ms average switching time and 1.26% average packet loss were measured across ten migration experiments.The switch was not instantaneous, but the flow was dynamically rerouted to the VM’s new location.
- After migration from C to B, the flow used the lower-latency A ↔B link and its latency dropped when the path changed.
VI. CONCLUSIONS AND PERSPECTIVES
The paper concludes that DISCO provides an open, distributed control plane for multi-domain networks, adapting across heterogeneous links while supporting resilience and end-to-end services. It identifies clustering and stronger recovery mechanisms as future directions.
- DISCO organizes one controller per SDN domain and uses a lightweight, manageable channel for agents to share aggregated network-wide information.
- The evaluation covered inter-domain topology disruption, end-to-end priority service requests, and virtual-machine migration.
- DISCO discriminates heterogeneous inter-domain links, including high-capacity MPLS tunnels and SATCOM interconnections.
- Future work includes dynamically regrouping controllers into coherent clusters and adding recovery mechanisms for taking control of switches in a failed neighboring domain.