PPJ-03

PPJ-03 SDN Abstractions
http://eueung.github.io/EL5244/
Software Defined Networking

1. PPJ #3 Virtualization & Software Defined Networking http://eueung.github.io/EL5244/ Dr.-Ing. Eueung Mulyana | 2015H2
2. This material is mainly a derivative and remix work. Most of the texts and illustrations are taken from the talks/lectures given by the referenced networking professors/gurus/ninjas (Credits at the end of the Slide).
3. SDN Abstractions
4. Previous Story … • Key to Internet Success: Layers • Why Is Layering So Important? • Built an Artifact, Not a Discipline • Why Does Networking Lag Behind? • Infrastructure Still Works! • What Is the Problem? • The Need for (Essential) Network Abstractions • Abstractions for Network Control
5. SDN Abstractions Interfaces Modularity • The Power of Abstraction • Modularity based on abstraction is the way things get done – Barbara Liskov (via. Shenker)
6. What abstractions should we apply to the control plane?
7. The Control Plane Problem Control plane must compute forwarding state. To accomplish its task, the control plane must: • Figure-out what network looks like (topology) • Figure out how to accomplish goal on given topology • Tell the switches what to do (configure forwarding state) We view this as a natural set of requirements.... And we require each new protocol to solve all three
8. The Control Plane Problem • What components do we want to reuse? – Determining the topology information – Configuring forwarding state on routers/switches
9. The Network Control Problem 1. Operate within given network-level protocol 2. Operate without communication guarantees 3. Compute the configuration of each physical device – E.g., Forwarding tables, ACLs,…
10. Two Control Plane Abstractions Abstraction: global network view • Provides information about current network • Implementation: “Network Operating System” • Runs on servers in network (replicated for reliability) Abstraction: forwarding model • Provides standard way of defining forwarding state • OpenFlow is an example • Specification of <match,action> flow entries
11. Specification Abstraction • Control Program must express desired behavior • Whether it be: isolation, access control, or QoS • CP should not be responsible for implementing that behavior on physical network infrastructure • CP should not be responsible for configuring the forwarding tables in each switch Proposed abstraction: Virtual Topology of network • Virtual Topology models only enough detail to specify goals • Will depend on task semantics
12. From Reqs. to Abstractions • #1 – Need an abstraction for general forwarding model • #2 – Need an abstraction for distributed state • #3 – Need an abstraction that simplifies configuration Once these abstractions are in place, control mechanism (CP) has a much easier job!
13. #1 Forwarding Abstraction
14. Forwarding Abstraction • Switches have two “brains” – Management CPU (smart but slow) – Forwarding ASIC (fast but dumb) • Need a forwarding abstraction for both – CPU abstraction can be almost anything • ASIC abstraction is much more subtle: OpenFlow • OpenFlow: – Control switch by inserting <header;action> entries – Essentially gives NOS remote access to forwarding table – Instantiated in OpenvSwitch
15. Forwarding Abstraction Purpose: Abstract away forwarding hardware Flexible – Behavior specified by control plane – Built from basic set of forwarding primitives Minimal – Streamlined for speed and low-power – Control program not vendor-specific OpenFlow is an example of such an abstraction
16. General Forwarding Abstraction Small set of primitives “Forwarding instruction set” Protocol independent Backward compatible Switches, routers, WiFi APs, basestations, TDM/WDM
17. #2 Distributed State Abstraction
18. Distributed State Abstraction • Shield control mechanisms from state distribution – While allowing access to this state • Natural abstraction: global network view – Annotated network graph provided through an API • Implemented with “Network Operating System” • Control mechanism is now program using API – No longer a distributed protocol, now just a graph algorithm – E.g. Use Dijkstra rather than Bellman-Ford
19. Network of Switches and/or Routers Traditional Control Mechanisms Distributed algorithm running between neighbors Complicated task-specific distributed algorithm
20. SDN Network OS Forwarding Model
21. Network OS Control Program Global Network View e.g. routing, access control Forwarding Model
22. Major Change in Paradigm • No longer designing distributed control protocols – Design one distributed system (NOS) – Use for all control functions • Now just defining a centralized control function •  configuration = Function(view)
23. Example: Routing
24. Network OS Network OS: distributed system that creates a consistent, up-to-date network view – Runs on servers (controllers) in the network – NOX, ONIX, Trema, Beacon, Maestro, … + more Uses forwarding abstraction to: – Get state information from forwarding elements – Give control directives to forwarding elements
25. Control Program Control Program operates on view of network – Input: global network view (graph/database) – Output: configuration of each network device Control program is not a distributed system – Abstraction hides details of distributed state
26. #3 Specification Abstraction
27. Specification Abstraction Network OS eases implementation Next step is to ease specification Provide abstract view of network map Control program operates on abstract view Develop means to simplify specification
28. Specification Abstraction • Control program should express desired behavior • It should not be responsible for implementing that behavior on physical network infrastructure • Natural abstraction: simplified model of network – Simple model with only enough detail to specify goals • Requires a new shared control layer: – Map abstract configuration to physical configuration • This is “network virtualization”
29. Simple Example: Access Control • Operator’s goal: prevent A’s packets from reaching B • Control program does so with access control entries: – Control program must respond to topology/routing changes – It makes hard to write correct control program A B AB drop AB drop
30. Network Virtualization • Introduce new abstraction and new SDN layer • Abstraction: Virtual Topology – Allows operator to express requirements and policies – Via a set of logical switches and their configurations • Layer: Network Hypervisor – Translates those requirements into switch configurations – “Compiler” for virtual topologies
31. Simple Example: Access Control Global Network View Abstract Network Model How What
32. Virtualization Simplifies Control Program A B AB drop AB drop AB drop Hypervisor then inserts flow entries as needed
33. Network OS Global Network View Abstract Network Model Control Program Network Virtualization
34. This Means … • Write a simple program to configure a simple model – Configuration merely a way to specify what you want • Virtualization layer “compiles” these requirements – Produces suitable configuration of actual network devices • NOS then transmits these settings to physical boxes • Examples – ACLs: who can talk to who – Isolation: who can hear my broadcasts – Routing: only specify routing to the degree you care • Some flows over satellite, others over landline – TE: specify in terms of quality of service, not routes
35. Network OS Global Network View Abstract Network Model Control Program Specifies behavior Compiles to topology Transmits to switches Network Virtualization
36. Two Example-Uses • Scale-out router: – Abstract view is single router – Physical network is collection of interconnected switches – Allows routers to “scale out, not up” – Use standard routing protocols on top • Multi-tenant networks: – Each tenant has control over their “private” network – Network virtualization layer compiles all of these individual control requests into a single physical configuration • Hard to do without SDN, easy (in principle) with SDN
37. Notes …
38. Abstractions Don’t Eliminate Complexity • Every component of system is tractable – NOS, Virtualization are still complicated pieces of code • SDN main achievements: – Simplifies interface for control program (user- specific) – Pushes complexity into reusable code (SDN platform) Just like compilers…. SDN: Layers for the Control Plane
39. Clean Separation of Concerns • Control Program: express goals on Virtual Topology – Operator Requirements – Configuration = Function(view) – Not a distributed protocol, now just a graph algorithm • Network Hypervisor: Virtual Topology  Global Network View • Network OS: Global Network View  physical switches – Gathers information for global network view – Conveys configurations from control program to switches • Router/switches: merely follow orders from NOS
40. Clean Separation of Concerns Clean separation of control and data planes: • Not packaged together in proprietary boxes • Enables use of commodity hardware, 3rd party software • Easier to write, maintain, verify, reason about, …
41. Recap: SDN, Abstractions & Models
42. SDN – Background Data Plane Control Plane Control Programs (Apps) Layers Abstraction N/A New control reqs led to great complexity A new protocol per problem A layer  a box e.g. Routing, Access Control, etc.
43. SDN – Background • Mastering Complexity vs. Extracting Simplicity • Getting systems to work vs. making systems easy to use and understand • Extracting Simplicity builds intellectual foundations necessary for creating a discipline • Abstractions key to extracting simplicity
44. SDN – Basic Concept Data Plane Control Plane Apps SBI NBI Specification Abstraction State Dist. Abstraction Forwarding Abstraction Control Logics Control Programs Control Platform
45. SDN – Basic Concept Data Plane Apps NOS events DP cfg/cmd global view cfg/cmd Controller+ Agents State Dist. Abstraction Forwarding Abstraction
46. SDN – Basic Concept Data Plane Apps NOS events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Controller Nypervisor (NH) Specification Abstraction State Dist. A. Forwarding A.
47. SDN – Basic Concept Data Plane Apps Just enough NOS/Mapper events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Controller Nypervisor (NH) Specification Abstraction State Dist. A. Forwarding A. controller cfg/cmd
48. SDN – Shenker • SDN can be “derived” from decomposing network control • SDN: clean separation of concerns • Future of networking lies in finding right abstractions
49. SDN – Clean Separation of Concerns Data Plane Apps NOS events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. Control Program: specify behavior on abstract model (driven by Operator Requirements)
50. SDN – Clean Separation of Concerns Data Plane Apps NOS events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. NV: map abstract model to global view (driven by Specification Abstraction)
51. SDN – Clean Separation of Concerns Data Plane Apps NOS events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. NOS: map global view to physical switches API: driven by Distributed State Abstraction Switch/fabric interface: driven by Forwarding Abstraction
52. We Have Achieved Modularity! • Modularity enables independent innovation – Gives rise to a thriving ecosystem • Innovation is the true value proposition of SDN – SDN doesn’t allow you to do the impossible – It just allows you to do the possible much more easily • This is why SDN is the future of networking…
53. An Analogy (w.r.t Computing) Vertically integrated Closed, proprietary Slow innovation Small industry Specialized Operating System Specialized Hardware Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p App Specialized Applications Horizontal Open interfaces Rapid innovation Huge industry Microprocessor Open Interface Linux Mac OS Windows (OS) or or Open Interface
54. An Analogy (w.r.t Computing) Million of lines of source code 6,000 RFCs Billions of gates Bloated Power Hungry Custom Hardware OS Routing, management, mobility management, access control, VPNs, … Feature Feature • Vertically integrated, complex, closed, proprietary • Networking industry with “mainframe” mind-set
55. An Analogy (w.r.t Computing) Vertically integrated Closed, proprietary Slow innovation Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p App Horizontal Open interfaces Rapid innovation Control Plane Control Plane Control Plane or or Open Interface Specialized Control Plane Specialized Hardware Specialized Features Merchant Switching Chips Open Interface
56. SDN – Background Data Plane Control Plane Control Programs (Apps) Layers Abstraction SDN New control reqs led to great complexity A new protocol per problem A layer  a box e.g. Routing, Access Control, etc.
57. Notes
58. Notes Networks becoming • More programmatic • Defined by owners and operators, not vendors • Faster changing, to meet operator needs • Lower opex, capex and power Abstractions • Will shield programmers from complexity • Make behavior more provable • Will take us places we can’t yet imagine
59. Credit • Scott Shenker, The Future of Networking and the Past of Protocols • Nick McKeown, Stanford University, Many Talks/Articles • Jennifer Rexford, COS 597E, Princeton University • Mike Freedman, COS 461, Princeton University • Nick Feamster, https://www.coursera.org/course/sdn • Li Erran Li, COMS 6998-10, Univ. of Columbia • Marco Cello, SDN Talk @ CNR, Univ. Genova • Guido Appenzeller, Network Virtualization in Multi- tenant Datacenters, VMware