1 / 85

Software Defined Networking COMS 6998-10, Fall 2014

Software Defined Networking COMS 6998-10, Fall 2014. Instructor: Li Erran Li ( lierranli@cs.columbia.edu ) http://www.cs.columbia.edu/ ~lierranli/coms6998-10SDNFall2014/ 9 /29/2014: SDN Programming Language. Outline. Announcements Homework 2 will be posted on Thursday, due in 18 days

schuyler
Télécharger la présentation

Software Defined Networking COMS 6998-10, Fall 2014

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. Software Defined NetworkingCOMS 6998-10, Fall 2014 Instructor: Li Erran Li (lierranli@cs.columbia.edu) http://www.cs.columbia.edu/~lierranli/coms6998-10SDNFall2014/ 9/29/2014: SDN Programming Language

  2. Outline • Announcements • Homework 2 will be posted on Thursday, due in 18 days • Review of previous lecture • Project ideas on scalable controller for cellular WAN • SDN programming language • Maple: generic programming language syntax such as Java, Python • NetKAT: domain specific programming language Software Defined Networking (COMS 6998-10)

  3. Review of Previous Lecture • How do we design scalable software defined networks? • Design scalable controllers • Offload control plane processing to switches • How do we design scalable controllers? • Flat structure multiple controllers • Recursive controller design • Hierarchical controller design Software Defined Networking (COMS 6998-10)

  4. Review of Previous Lecture (Cont’d) • How to offload control plane processing to switches? • Offload to switch control plane • Controller proactively generates the rules and distributes them to authority switches • Authority switches keeppackets always in the data plane and ingress switches reactively cache rules • Offload to switch data plane • Try to stay in data-plane, by default • Provide enough visibility: for significant flows & sec-sensitive flows; Otherwise, aggregate or approximate statistics Software Defined Networking (COMS 6998-10)

  5. Review of Previous Lecture (Cont’d) How do wedividetasksamongcontrollerinstances? • Partition • Controller instances with different computations tasks • Controller instances have only subsets of the NIB • Switches connect to a subset of controller instances • Aggregation • Reduce fidelity of information Software Defined Networking (COMS 6998-10)

  6. Review of Previous Lecture (Cont’d) • How to maintain network information base (NIB)? • Replicated transactions (SQL) storage for strong consistency (more static information) • One-hop memory-based DHT for weak consistency (more dynamic information) Software Defined Networking (COMS 6998-10)

  7. Review of Previous Lecture (Cont’d) Authority Switch Feedback: Cache rules Ingress Switch Forward Egress Switch Redirect First packet Following packets Hit cached rules and forward Offload to switch control plane Software Defined Networking (COMS 6998-10) Source: Minlan Yu

  8. Review of Previous Lecture (Cont’d) • Rule cloning • ASICclones a wildcard rule as an exact match rule for new microflows • Timeout or output port by probability Software Defined Networking (COMS 6998-10)

  9. Review of Previous Lecture (Cont’d) • Rule cloning • ASIC clones a wildcard rule as an exact match rule for new microflows • Timeout or output port by probability Software Defined Networking (COMS 6998-10)

  10. Review of Previous Lecture (Cont’d) • Rule cloning • ASIC clones a wildcard rule as an exact match rule for new microflows • Timeout or output port by probability Software Defined Networking (COMS 6998-10)

  11. Review of Previous Lecture (Cont’d) • Local actions • Rapid re-routing: fallback paths predefinedRecover almost immediately • Multipath support: based on probability dist.Adjusted by link capacity or loads Software Defined Networking (COMS 6998-10)

  12. Outline • Announcements • Homework 2 will be posted on Thursday, due in 18 days • Review of previous lecture • Project ideas on scalable controller for cellular WAN • SDN programming language • Maple: generic programming language syntax such as Java, Python • Frenetic: domain specific programming language Software Defined Networking (COMS 6998-10)

  13. LTE Cellular Network Architecture Base Station (BS) Serving Gateway Packet Data Network Gateway Serving Gateway Internet User Equipment (UE) access core Software Defined Networking (COMS 6998-10)

  14. Current Mobile WANs Two Regions • Organized into rigid and very large regions • Minimal interactions among regions • Centralized policy enforcement at PGWs Software Defined Networking (COMS 6998-10)

  15. Mobile WANs Problems • Suboptimal routing in large carriers • Lack of sufficiently close PGW is a major cause of path inflation • Scalability and reliability • The sheer amount of traffic and centralized policy enforcement • Ill-suited to adapt to the rise of new applications • E.g., machine-to-machine • All users’ outgoing traffic traverses a PGW to the Internet, even for reaching a user served by a close base station in a neighbor region Software Defined Networking (COMS 6998-10)

  16. SoftMoW Motivation Question: How to make the packet core scalable, simple, and flexible for hundreds of thousands of base stations and hundreds of millions of mobile users? • Mobile networks should have fully connected core topology, small logical regions, and more egress points • Operators should leverage SDN to manage the whole network with a logically-centralized controller: • Directs traffic through efficient network paths that might cross region boundaries • Handles high amount of intra-region signaling load from mobile users • Supports seamless inter-region mobility and optimizes its performance • Performs network-wide application-based such as region optimization Software Defined Networking (COMS 6998-10)

  17. SoftMoW Solution Union of Coverage Sum of capacities Latency Matrix VBS GS VMB Policy Core Net RadioAccess Network • Hierarchically builds up a network-wide control plane • Lies in the family of recursive SDN designs (e.g. XBAR, ONS’13) • In each level, abstracts both control and data planes and exposes a set of “dynamically-defined” logical components to the control plane of the level above. • Virtual Base stations (VBS), Gigantic Switches (GS), and Virtual Middleboxes (VMB) Software Defined Networking (COMS 6998-10)

  18. SoftMoW Solution Merge/Split Move and Split • New Dynamic Feature: In each level, the control logic can modify its logical components for optimization purposes • E.g., merge/spilt and move operations Software Defined Networking (COMS 6998-10)

  19. First Level-SoftMoW Architecture Bootstrapping phase: based on location and processing capabilities of child controllers Replace inflexible and expensive hardware devices (i.e., PGW, SGW) with SDN switches Perform distributed policy enforcement using middle-box instances Partition the network into independent and dynamic logical regions A child controller manages the data plane of each regions Software Defined Networking (COMS 6998-10)

  20. Second Level-SoftMoW Architecture • A parent runs a global link discovery protocol • Inter-region links are not detected by BDDP and LLDP • A parent participates in the inter-domain routing protocol • A parent builds virtual middleboxchains and egress-point policies, and dictates to GSs Software Defined Networking (COMS 6998-10)

  21. Hierarchical Traffic Engineering • A parent pushes a global label into each traffic group • Child controllers perform label swapping • Ingress point: pop the global label and push some local labels for intra-region paths • Egress point: pop the local labels and push back the global label Push W Web Voice Pop W2 Push W Pop W1 GS Rules Latency (P1,E2)=300 Latency (P1,E4)=100 Push W Push W2 Pop W Pop W Push W1 Software Defined Networking (COMS 6998-10)

  22. Time-of-day Handover Optimization Abstraction update Handover graph coordination GS Rule: Move Border VBS1 Q: How can an operator reduce inter-region handovers in peak hours? Software Defined Networking (COMS 6998-10)

  23. Project Ideas • Implement a G-switch driver/agent: acts as a shim to allow a G-switch to act like an actual OF switch. • This driver helps to connect any OF controller as a G-switch to its parent OF controller. In this way, installing rule-actions into G-switches and setting up paths on abstract topology becomes like the physical topology. • Driver should translate the messages or states received from the parent OF controller to the underlying topology and periodically pulls states from the local NIB to expose to the parent. • Implement HazelCast on a single controller • Show performance improvement on various applications such as traffic engineering, routing, and failure recovery over the standard in-memory data structures for a single controller. Software Defined Networking (COMS 6998-10)

  24. Project Ideas (Cont’d) • Implement recursive link discovery protocol and the necessary translations in the shim. • Implement RamCloud on a single controller • Show performance improvement on various applications such as traffic engineering, routing, and failure recovery compared with the standard NIB. • Implement an orchestration layer to provide global network view • Use ZooKeeper to dynamically assign controllers to data plane switches as the network becomes larger on top of a single/flat controller. • Implement the hierarchical control plane Software Defined Networking (COMS 6998-10)

  25. Outline • Announcements • Homework 2 will be posted on Thursday, due in 18 days • Review of previous lecture • Project ideas on scalable controller for cellular WAN • SDN programming language • Maple: generic programming language syntax such as Java, Python • Frenetic: domain specific programming language Software Defined Networking (COMS 6998-10)

  26. construct and install OF rules so that similar packets are processed at switches with same action. Step 1 Step 2 examine p and decide what to do with p. A Key Source of Complexity in Openflow Controllers • onPacketIn(p): Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  27. insert rule with “exact match” for p, i.e. match on ALL attributes, with action determined above. Step 1 Step 2 examine p and decide what to do with p. Simple, generic solution using exact matches • onPacketIn(p): Every flow incurs flow setup delay. Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  28. Step 1 Step 2 drop match:{TcpDst=22} action:drop priority:HIGH yes p.TcpDst=22? tcpDst!=22 send to next hop for p.EthDst match:{EthDst=p.EthDst} action:nextHop(p) priority:LOW no Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  29. EthDst:A, TcpDst:80 Switch EthDst:A, TcpDst:22 Controller If p.TcpDst=22: insert rule {prio:HIGH, match:{TcpDst=22}, action:drop } Else: insert rule {prio:LOW, match:{EthDst=p.EthDst},action:nextHop(p.EthDst) Software Defined Networking (COMS 6998-10)

  30. Step 1. Make Decisions User Level Step 2. Generate Rules OF Controller Library Under the hood OF Switches Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  31. Algorithmic Policy Step 1. Make Decisions User Level Step 2. Generate Rules OF Controller Library Under the hood OF Switches Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  32. Algorithmic Policies • Function in a general purpose language that describes how a packet should be routed, not how flow tables are configured. • Conceptually invoked on every packet entering the network; may also access network environment state; hence it has the form: • Written in a familiar language such as Java, Python, or Haskell Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  33. Example Algorithmic Policy in Java Does not specify flow table configutation Route f(Packet p, Env e) { if (p.tcpDstIs(22)) returnnull(); else { Locationsloc = e.location(p.ethSrc()); Locationdloc = e.location(p.ethDst()); Path path = shortestPath(e.links(), sloc,dloc); if (p.ethDstIs(2) return null(); elsereturnunicast(sloc,dloc,path); } } Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  34. How to implement algorithmic policies? • Naive solutions -- process every packet at controller or use only exact match rules -- perform poorly • Static analysis to determine layout of flow tables is possible, but has drawbacks: • Static analysis of program in general-purpose language is hard and is typically conservative • System becomes source-language dependent Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  35. Maple’s approach: runtime tracing 1. Maple observes the dependency of f on packet data. 2. Build a trace tree (TT), a partial decision tree for f. 3. Compile flow tables (FTs) from a trace tree. Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  36. Policy EthDest:1, TcpDst:80 Assert(TcpDst,22) Route f(Packet p, Env e) { if (p.tcpDstIs(22)) returnnull(); else { Locationdloc = e.location(p.ethDst()); Locationsloc = e.location(p.ethSrc()); Path path = shortestPath( e.links(),sloc,dloc); if (p.ethDstIs(2) returnnull(); else returnunicast(sloc,dloc,path); } } false Read(EthDst) 4 Read(EthSrc) 6 path1 Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  37. EthDst:1, TcpDst:22 Trace Tree Policy Assert(TcpDst,22) Route f(Packet p, Env e) { if (p.tcpDstIs(22)) returnnull(); else{ Locationdloc = e.location(p.ethDst()); Locationsloc = e.location(p.ethSrc()); Path path = shortestPath( e.links(),sloc,dloc); if (p.ethDstIs(2) return null(); else returnunicast(sloc,dloc,path); } } Assert(TcpDst,22) true null true false Read(EthDst) ? 4 Read(EthSrc) 6 path1 Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  38. Compile recorded executions into flow table tcpDst==22 3 1 True False 2 ethDst drop 4 2 ethSrc drop 6 port 30 barrier rule: match:{ethDst:4,ethSrc:6} action:[port 30] match:{tcpDst==22} action:ToController Priority Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  39. Basic compilation: in-order traversal & barrier rules tcpDst==22 Priority := 0 Priority := 2 Priority := 1 Priority := 3 accumulated match: {} False True ethDst null {tcpDst:22} {} 4 2 ethSrc null {ethDst:2} (prio:3,{tcpDst:22},action:drop) {ethDst:4} 6 {ethDst:4, ethSrc:6} port 30 (prio:2,{tcpDst:22},action:ToController) barrier rule: (prio:1,{ethDst:2},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  40. Can use priority 0 No effect Basic compilation example result • Trace tree method converts arbitrary algorithmic policies into correct forwarding tables that effectively use wildcard rules. • Deficiencies: • More priorities levels than necessary • More rules than necessary • Annotate TT nodes with extra information to improve compilation (prio:3,{tcpDst:22},action:drop) (prio:2,{tcpDst:22},action:ToController) (prio:1,{ethDst:2},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  41. Optimization 1: Annotate TT nodes with completeness tcpDst==22 {} False True no barrier ethDst drop {tcpDst:22} {} complete 4 2 complete ethSrc drop {ethDst:2} {ethDst:4} (prio:2,{tcpDst:22},action:drop) 6 complete port 30 {ethDst:4, ethSrc:6} (prio:1,{ethDst:2},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  42. Optimization 2: Annotate nodes with priority dependencies tcpDst==22 {} False True 1 ethDst drop {tcpDst:22} {} 4 2 ethSrc drop {ethDst:2} {ethDst:4} (prio:1,{tcpDst:22},action:drop) 6 port 30 {ethDst:4, ethSrc:6} (prio:0,{ethDst:2},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  43. Improved compilation result (prio:1,{tcpDst:22},action:drop) (prio:0,{ethDst:2},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  44. Maple Status • Maple has been implemented in Haskell using the McNettleOpenflow controller, which implements Openflow 1.0. • The implementation includes several other features: • Incremental TT compilation, to avoid full recompilation on every update. • Trace reduction, to ensure traces and trace trees do not contain redundant nodes. • Automatic and user-specified invalidation, to support removing and updating TT and FT when network state changes. Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  45. Summary: Contributions • Algorithmic policies provide a simple, expressive programming model for SDN, eliminating a key source of errors and performance problems. • Maple provides a scalable implementation of algorithmic policies through several novel techniques, including: • runtime tracing of algorithmic policies, • maintaining a trace tree and compiling TT to flow tables to distribute processing to switches; • using TT annotations to implement compiler optimizations such as rule and priority reductions. Software Defined Networking (COMS 6998-10) Source: Andreas Voellmy, Yale

  46. Outline • Announcements • Homework 2 posted due in 18 days • Next lecture: first half by Josh Reich from Princeton on Pyretic • Review of previous lecture • SDN programming language • Maple: generic programming language syntax such as Java, Python • Frenetic: domain specific programming language Software Defined Networking (COMS 6998-10)

  47. Key questions: • What are the right abstractions for programming software-defined networks? • How can we engineer trustworthy implementations that provide assurance? Software Defined Networking (COMS 6998-10) Source: Nate Foster, Cornell

  48. Modular Abstractions Software Defined Networking (COMS 6998-10) Source: Nate Foster, Cornell

  49. Combining Functionality • One monolithic • application Monitor + Route + Load Balance + Firewall Controller Platform • Challenges: • Writing, testing, and debugging programs • Reusing code across applications • Porting applications to new platforms Software Defined Networking (COMS 6998-10) Source: Nate Foster, Cornell

  50. Route Monitor + Route + Monitor Software Defined Networking (COMS 6998-10) Source: Nate Foster, Cornell

More Related