1 / 30

Distributed SDN controllers

Distributed SDN controllers. Marco Canini. Network Policy Specification. Centralized Network Policy. Routing. Monitoring. Waypoint. Load Balancing. Access Control. Controller Platform. Network Policy Specification. Centralized Network Policy. Routing. Monitoring. Waypoint.

arion
Télécharger la présentation

Distributed SDN controllers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed SDN controllers Marco Canini

  2. Network Policy Specification Centralized Network Policy Routing Monitoring Waypoint Load Balancing Access Control Controller Platform

  3. Network Policy Specification Centralized Network Policy Routing Monitoring Waypoint Load Balancing Access Control forward from X to Y Controller Platform X Y • <Match, Action> • <Match, Action> • <Match, Action> • <Match, Action> • <Match, Action> • … • …

  4. Network Policy Specification Centralized Network Policy Routing Monitoring Waypoint Load Balancing Access Control Composition Controller Platform X Y Policy composition assembles data plane updates as a semantically sound set of rules

  5. Policy Composition Review Foster ‘11, Monsanto ‘13: Modular, parallel and sequential composition • Ferguson ‘12, ‘13: Policy trees for multi-authorship SrvLoad Balancing Routing Monitoring >> U Composition Routing Waypoint Reitblatt ‘12: Consistent network updates

  6. Composing Policies Routing Monitoring dport = 80  count dst = H  fwd(H) Composition • dst= H∧dport = 80 count; fwd(H) • dst= H fwd(H) • dport= 80  count H What to do with packet dst = H and dport = 80? Can Routing and Monitoring compose?

  7. Ordering Policies Routing Waypoint Waypoint src = S  fwd(IDS) dst = H  fwd(H) Precedence src = S fwd(IDS) src != S ∧dst= H fwd(H) H What to do with packet dst = H and src = S? Does Waypoint have precedence over Routing?

  8. Conflicting Policies Routing Load Balancing dst = H  fwd(Y) dst = H  fwd(X) Conflict X != Y • In the general case, policies might conflict • Examples: • Overlapping domains and same precedence • Scarce flowtable resources • Must avoid conflicting policies • Pick one and reject the other?

  9. Centralized Network Control? Centralized Network Policy Routing Monitoring Waypoint Load Balancing Access Control Controller Platform Fully centralized  Inadequate availability, scalability and responsiveness

  10. Distributed Network Control Centralized Network Policy Routing Monitoring Waypoint Load Balancing Access Control Controller Platform Composition? Consistency and concurrency Faults and asynchronous communication

  11. Now, consider policy compositionin the distributed control plane... Policy Policy Routing Monitoring Waypoint Routing Monitoring Waypoint • Controller Platform Controller Platform Control Logic Factorization State Distribution Model Switch Reader-Writer Model

  12. Why should the programmer care? • We believe she should not! • Enter Software Transactional Networking • Let a dedicated component implement a general solution to all hard-to-solve, low-level concurrency and fault tolerance issues apply(π) ack /nack(reason) Transactional Interface

  13. Consistency: Linearizabilityof updates apply(π1) ack apply(π1) ack p1 p1 apply(π2) ack apply(π2) ack p2 p2 apply(π3) nack p3 p3 sw1 sw1 sw2 sw2 sw3 sw3 Manipulate the network as though there is no concurrency We don’t control traffic! Original history Sequential equivalent

  14. Can we realize a general distributed policy composition interface that is agnostic to control logic, state distribution and reader-writer model?

  15. Studied Two Underlying Problems • Consistent and Concurrent Policy Composition • Exploit optimistic concurrency [HotSDN’13] • Consistent and Robust Policy Composition • In face of controller failures [INFOCOM’15]

  16. Software Transactional Networking v1 HotSDN’13 Routing Monitoring Waypoint apply(π1) ack • apply(π2) nack(reason) STN Interface All-or-nothing semantics Optimistic concurrency for policy composition Non conflicting policies eventually installed Per-packet consistent updates

  17. Conceptualizing STN Routing Monitoring Waypoint apply(π) ack STN STN STN Policy π unique tag τ 1. Internal ports match on tag τ 2. Ingress ports apply tag τ

  18. STN v1 Details • Explore design with no explicit communication between STN nodes • Avoid concurrency issues via an atomic read-modify-write primitive at switch ports • Problems with our simple algo: • # tags grows exponentially with # (conc.) policies • Requires a cleaner to garbage collect unused rules • No fault tolerance

  19. Software Transactional Networking v2:Consistent Policy Composition INFOCOM’15 Routing Monitoring Waypoint apply(π1) ack • apply(π2) nack(reason) Require robustness but not efficiency CPC Interface All-or-nothing semantics Tolerate up to f controller crash failures Non conflicting policies eventually installed andat least one policy commits (among conflicting ones) Ensure updates affect traffic as a sequential composition of their policies Per-packet consistency

  20. Conceptualizing CPC Routing Monitoring Waypoint CPC CPC Atomic Read-Modify- Write Reliable but asynchronous channel Every controller receives and installs every policy Lock Lock Lock Lock Lock Lock Lock

  21. CPC implementation: model v1 • Controllers access switch ports with read and writeoperations • Controllers can communicate via asynchronous message-passing • Controllers may fail by crashing • No synchrony assumptions • Restrict policies to forwarding • Compose if domains are disjoint or related by precedence • Reject otherwise

  22. Asynchronous read-write CPC Theorem: 1-resilient read-write CPC is impossible Proof sketch: • Two ingress ports 1 and 2 initially forward all to the internal ports (π0) • π1 installed by p1and π2 installed by p2, π2refines π1 (higher precedence, same domain) • π1and π2 propose different paths • p1 changes port 1 and is just about to change 2 (with a composition of π0 andπ1), p2 takes no steps • p2 wakes up and installs of π0 π1 π2, p1 takes no steps • p1 changes port 2 with π0π1:π2 is forgotten! 1 2 ? π0 π1 π2 π0 π1 p1 p2

  23. CPC implementation: model v2 • Controllers access ports with atomic read-modify-write ops RMW(f,g,v): • read the state v’ • write f(v,v’) • return g(v,v’) • Intuition: do not update if conflicts with currently installed policy Controller g(v,v’) RMW(f,g,v)

  24. Upper bound: FixTag algorithm Operation: • Unique tag per path • Broadcast policy π to all other controllers • Update ingress ports in predefined order • … add rule to tag all packets matching dom(π) with the tag corresponding to the path π(i) for ingress port i Upsides: wait-free (tolerates all failure patterns) • Controllers only synchronize through the data plane Downsides: overhead can be huge • Super-exponential in the size of the network

  25. Can we do better? • No, if we get no feedback from the network • Tag t cannot be reused if a packet tagged with t is still “in flight” • Suppose, we can correctly evaluate the set of active tags • Correct (but asynchronous) oracle • Single-controller scenario: one bit is enough! • Upon policy update πi wait until (i mod 2)-traffic is over, and use tag imod 2 • Two or more controllers: inherent price of concurrency? • Between constant and super-exponential? • Yes, if controllers coordinate use of tags

  26. ReuseTag: linear complexity • Proportional to the level of resilience: • Up to f failures: f+2 tags needed (proved optimal) • Controllers use consensus instances (eventual synchrony or « eventual leader ») • Replicated state machine that imposes a global order on the policy updates and ensure coordinated use and reuse of tags • All requests are serialized • Even non-conflicting ones • Can we do better?

  27. Summary • Framework for concurrent and consistent policy composition in distributed SDN • Transactional interface to manipulate the network as though there is no concurrency • Policies compose or conflict (and abort)

  28. Acknowledgements PetrKuznetsov Dan Levin Stefan Schmid Supported by ARC grant 13/18-054 from Communautéfrançaisede Belgique, andEuropean Union’s Horizon 2020 ENDEAVOUR project (grant agreement 644960)

  29. References Software Transactional Networking: Concurrent and Consistent Policy Composition HotSDN’13 STN: A Robust and Distributed SDN Control Plane ONS’14 A Distributed and Robust SDN Control Plane for Transactional Network Updates INFOCOM’15

  30. NetPL’15 – Call for Participation • Workshop co-located with ECOOP’15 • Organizers: Robert Soulé& Marco Canini • Prague, July 5th or 6th 2015 • “to bring together researchers and practitioners from the fields of programming languages, formal methods, and networking” • Program: speakers from academia and industry • ShriramKrishnamurthi, Hitesh Ballani, Colin Dixson, Roger Wattenhofer, FontaDimitropoulos, Antonio Capone, Anil Madhavapeddy, Xia Yinben, ...

More Related