ANR-13-INFR-013 ANR DISCO

Transcription

1 DIstributed SDN COntrollers for rich and elastic services ANR-13-INFR-013 ANR DISCO DIstributed SDN COntrollers for rich and elastic services Mathieu Communications & Security 1

2 Project s Profile DISCO: DIstributed SDN COntrollers for rich and elastic services ANR INFRA 2013 Industrial project Starting date: 1st January 2014 Duration: 42 months Partners: Thales Communications & Security (coordinator) INRIA Sophia Antipolis (DIANA research team, previously Planète) ENS Lyon (DANTE research team) 6WIND

3 DISCO s use case and Next generation SDN Use cases Telco offers Video on Demand (VoD), medical data sharing system Deployment context Heterogeneous and Time-varying resources (resources / cost/ / failures) Paris Datacenter Enterprise WAN Mission Critical WAN Private Operated WAN London Datacenter Micro Datacenter New York Datacenter

4 DISCO s Challenges App. User App. Network as a Service Efficient content distribution mechanism leveraging dynamic resource allocation A NaaS API to allow network applications to benefit from dynamic core and network appliance allocation and extended monitoring capabilities Controller instance Cipher Controller instance Controller instance Load balancer Controller instance Cache Controller instance DPI SDN Control Plane Resilient control plane for more robustness, scalability and flexibility Network-wide distributed and multiclass admission control Extensions of the controlling capabilities both for monitoring and configuration of the data plane Switch Next generation data plane New scalable appliances for DPI and caching Dynamic allocation of cores between applications and network services Optimization of the dynamic placement of network appliances in SDN-based infrastructures

5 DISCO Methodology Preliminary Experiments (State of the art and partner background integration, functional analysis of existing modules ) Advanced Experiments (Distributed control plane, virtual network functions, performance evaluations.) Requirements and Architecture (Analysis of SDN architectures, new services, challenges, architecture ) Research Studies (Distributed SDN controllers, Network-wide distributed admission control, resource allocation, virtual net functions placement, NaaS APIs ) Experiment and application driven methodology 1st axis: Management of critical applications 2 nd axis: Content distribution service

6 Preliminary works 1. Survey of SDN 2. Distributed SDN Controllers 6

7 Survey of SDN B. Astuto et al., `A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks to appear in IEEE Com. Surveys & Tutorial, History of SDN Open Signaling, Active Networking, DCAN, 4D, NETCONF, Ethan Main current Architecture OpenFlow, ForCES Forwarding Forwarding table Rules installation Controllers Centralized vs distributed Multi level (e.g., region, proxies ) Granularity and reactivity vs proactivity Code verification and debugging API Southbound communication Northbound communication SDN Development Tools (emulation vs simulations vs software switches (see table I) vs hardware switches) SDN Applications Enterprise Networks, Data Centers, Infrastructure-based Wireless Access Networks, Optical Networks, Home & Small Business) Research Challenges Controller & switch design, Internetworking/heterogeneous networks, ICN 7

8 DISCO: Distributed Multi-domain SDN Controllers K. Phemius, M. Bouet and J. Leguay, DISCO: Distributed Multidomain SDN Controllers, in Proceedings of IEEE NOMS 2014, May 2014 Thales Communications & Security

9 Classic SDN architecture SDN Controller Physically & logically centralized OpenFlow Protocol Control Plane Data Plane What about resilience? WAN SATCOM WAN WAN

10 Specified OpenFlow architecture for multiple controllers OpenFlow Specification v1.4 master Sync. SDN SDN Controller slave Controller Control Plane OpenFlow Protocol OpenFlow enables Controllers to manage their role: Master, Equal, Slave OpenFlow enables to manage role transition (generation_id) Many solutions exist to manage: Master election Synchronization between controllers (e.g. Cassandra distributed database) Use cases: fail over, load balancing

11 Logically Centralized? State Distribution Tradeoffs in Software Defined Networks Trade-offs Strongly consistent Imposes overhead and delay, and limits responsiveness, can lead to sub-optimality Eventually consistent Presents a temporarily inconsistent view, may cause incorrect behavior Trade-offs Performance (optimality) vs. state distribution overhead (staleness) Application complexity vs. robustness to inconsistency in states Dan Levin, Andreas Wundsam, Brandon Heller, Nikhil Handigol, and Anja Feldmann Logically centralized?: state distribution trade-offs in software defined networks. In Proceedings of the first workshop on Hot topics in software defined networks (HotSDN '12).

12 Distribution of SDN Control Plane State of the art Data plane extension (for scalability) DIFANE (2010) Partly offload forwarding decisions from the controller to special switches, called authority switches. DevoFlow (2011) Use of rule cloning, multipath and triggers to alleviate elephant flows. This solution necessitate a small modification of the switches control plane. Fully distributed Controllers HyperFlow (2010) Use Pub/Sub on a distributed file system. Each Controller still has exclusive access to its nodes. Applications needs to be aware of the partitioning. Onix (2010) Use a Network Information Base (NIB) and Distributed Hash tables (DHT) to share the global view of the network between controllers. Devolved Controllers (2011) Nodes are controlled by at least two controllers and all possible paths between all pairs of nodes are pre-computed. Hierarchical Controllers Kandoo (2012) Propose a hierarchical distribution of the controllers based on two layers of controllers: (i) controllers with local views and (ii) logically centralized controller that maintains the network-wide state B4 (2013) Use of Onix on each site cluster with Paxos and use of a central TE.

13 DISCO: Distributed SDN Controllers SDN SDN Controller Controller SDN SDN Controller Controller SDN SDN Controller Controller SDN SDN Controller OpenFlow Protocol / OnePK Control Plane Data Plane WAN SDN domain SATCOM SDN domain WAN SDN domain WAN SDN domain

14 DISCO: Distributed SDN Controllers SDN SDN Controller Controller Control Plane Data Plane SDN SDN Controller Controller The inter-controller mechanism is agnostic to OpenFlow and vendor specific APIs SDN SDN Controller SDN SDN Controller Controller OpenFlow Protocol / OnePK Resilient SDN architecture: no single point of failure, increase responsiveness and reliability, scalable, adaptable to heterogeneous/asymetric deployments (e.g. SATCOM link) Hypothesis: a mechanism enables to manage Master/Slave controllers in a domain

15 East/West = Pub/Sub Reduced complexity, assured interoperability while scaling efficiently and being resilient Use of a Distributed Message Broker Architecture SDN Controller Broker SDN Controller Client Broker Client SDN Controller Broker Client

16 Message Queuing Messenger uses drivers to communicate with the implementation of AMQP running on the machine. Each AMQP driver must support the following set of functions: 1) pair (neighbor controller ID) and unpair (neighbor controller ID): create and delete an inter-domain control channel with a neighbor controller. This function tunes the subscriptions so that a node receives or not information from this neighbor controller. 2) subscribe (topic) and unsubscribe topic (topic): add and delete a topic from the topic list that the node is interested to receive. 3) send (topic, message) and receive(topic, message): send/receive a message on a specific topic. SDN Controller Broker Client SDN Controller Broker Client Topics: Reachability.1s Reachability.10s Reachability.30s

17 DISCO architecture

18 Evaluation

19 Testbed Emulation: Mininet v2.0 Open vswitch with OpenFlow 1.0 DISCO implementation based on Floodlight v0.90 Virtual machines Linux Tc command AMQP: RabbitMQ

20 Demonstrator 3 distributed controllers to evaluate: Adaptive information exchange User/VM mobility

21 Use case 1: Adaptive information exchange Scenario

22 Use case 1: Adaptive information exchange t=9s: end of discovery and setup; t=33s: link B-C is down A->B B->A Discovery Link down A->C C->A B->C C->B

23 Use case 2: Host migration Scenario: a VM is migrated from Domain C to Domain B; the communication (10Mbits/s in UDP) between the host in Domain A and the VM is maintained. Results: Interruption: 117ms Loss: 1.26%

24 Conclusion for this ongoing work Multi-domain SDN controllers AMQP-based inter-controller mechanism agnostic to OpenFlow and vendor specific APIs no single point of failure increased responsiveness and reliability scalable adaptable to heterogeneous/asymetric deployments (e.g. SATCOM link) K. Phemius, M. Bouet and J. Leguay: DISCO: Distributed Multi-domain SDN Controllers, in Proceedings of IEEE NOMS 2014, May 2014.

25 Conclusion A great adventure has started with highly interesting preliminary results, objectives and challenges! Visit us at

26 Current Functionalities Functionality End-to-end Routing (Path Computation Element) Host mobility Adaptive Controller-to-Controller communications OpenFlow driver Monitoring (latency, jitter, used bandwidth) Link discovery Device management Firewalling Multicast SLA management Exploratory OnePK integration OpenStack Plugin Tenant Management (Addressing, ARP proxy) Status Done Done Done Done Done Done Done Done Done Ongoing Ongoing Ongoing Ongoing

27 Topology 3 network domains, each controlled by an active SDN controller

28 Work Package interactions WP0 Project Management WP1 Requirements & System Architecture WP2 Resilient and Scalable SDN Control Plane WP3 Rich and Elastic Network Services WP4 End-applications & Experimentations