1. CSci5221: Introduction to SDN1 Introduction to Software-Defined Networking Overview –What is SDN and Why SDN? SDN Control Plane Abstractions OpenFlow Switch and OpenFlow APIs -- Based partially on the presentations of Prof. Scott Shenker of UC Berkeley “The Future of Networking, and the Past of Protocols”  Please watch the YouTube video of Shenker’s talk Readings: please do required! and optional readings if interested

2. Two Key Definitions Data Plane: processing and delivery of packets –Based on state in routers and endpoints –E.g., IP, TCP, Ethernet, etc. –Fast timescales (per-packet) Control Plane: establishing the state in routers –Determines how and where packets are forwarded –Routing, traffic engineering, firewall state, … –Slow time-scales (per control event) These different planes require different abstractions Some literature also separates the notion of management plane (router configuration, policy specs, …) from control plane

3. What is a Software Defined Network (SDN)? A network in which the control plane is physically separate from the forwarding plane and A single control plane controls several forwarding devices --- wikipedia So what is all the big buzz about SDN?

4. Key to Internet Success: Layers Applications …built on… Reliable (or unreliable) transport Best-effort global packet delivery Best-effort local packet delivery Physical transfer of bits

5. Why Is Layering So Important? Decomposed delivery into fundamental components Independent but compatible innovation at each layer A practical success of unprecedented proportions…

6. Internet “Hourglass” Layered Architecture Internet “hourglass” layered architecture is primarily an abstraction for network data plane! –hide various details of physical/data link layer technologies, e.g., Ethernet, WiFi –while accommodate & integrate them via a “virtualized” IP layer on top (an overlay) –two simple services, TCP/UDP, on top of IP –enable a huge diversity of applications “dumb” networks, “smart” end systems –based on “end-to-end” principles Tremendous success: a lot of innovations!

7. Network Control/Management Plane A very different story! There are no general principles or abstractions guiding the design of network control/management plane –in contrast, e.g., to distributed systems or database systems Control plane is basically composed of various distributed “control” protocols –For each new feature/functionality needed, a new protocol is designed  new software run by “flimsy” CPU in routers Worse, network boxes are “closed” equipment –(mostly proprietary) software bundled with hardware –vendor-specific interfaces; –slow protocol standardization – often years! Few people can innovate: new ideas/features can’t be quickly incorporated into networks! vendors vs. service providers!

8. “The Power of Abstraction” “ Modularity based on abstraction is the way things get done” − Barbara Liskov Abstractions  Interfaces  Modularity What abstractions do we have in networking?

9. Networking vs. Other System Fields Other fields in “systems”: OS, Database, Distributed Systems, etc. –Many abstractions: e.g., virtual memory, processes and threads, file systems, concurrency, consistency models, ACID, atomic transactions, schemas and relational databases, query languages, etc. –Are easily managed –Continue to evolve Networking: –Big bag of protocols –Notoriously difficult to manage –Evolves very slowly

10. Old ways to configure a network Limitations of Current Networks Specialized Packet Forwarding Hardware App Specialized Packet Forwarding Hardware App Specialized Packet Forwarding Hardware App Specialized Packet Forwarding Hardware App Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System App

11. Managing Networks … Networks used to be simple: Ethernet, IP, TCP…. New control requirements led to great complexity –Isolation  VLANs, ACLs –Traffic engineering  MPLS, ECMP, Weights –Packet processing  Firewalls, NATs, middleboxes –Payload analysis  Deep packet inspection (DPI) –….. Mechanisms designed and deployed independently –Complicated “control plane” design, primitive functionality –Stark contrast to the elegantly modular “data plane”

12. A Typical Enterprise Network 12 http://www.excitingip.net/27/a-basic-enterprise-lan-network-architecture-block-diagram-and-components/ Switches

13. Limitations of Current Networks 13 Million of lines of source code Billions of gates Many complex functions baked into infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, … Specialized Packet Forwarding Hardware Operating System Operating System Feature Cannot dynamically change according to network conditions

14. Limitations of Current Networks Enterprise networks are difficult to manage “New control requirements have arisen”: –Greater scale –Migration of VMS How to easily configure huge networks? 14

15. Infrastructure Still Works! Only because of “our” ability to master complexity This ability to master complexity is both a blessing… –…and a curse!

16. No control plane abstraction for the whole network! It’s like old times – when there was no OS… Limitations of Current Networks Wilkes with the EDSAC, 1949

17. Idea: An OS for Networks Simple Packet Forwarding Hardware Network Operating System Control Programs

18. Idea: An OS for Networks Simple Packet Forwarding Hardware Network Operating System Control Programs

19. Idea: An OS for Networks “NOX: Towards an Operating System for Networks” Global Network View Protocols Control via forwarding interface Network Operating System Control Programs Software-Defined Networking (SDN) The Future of Networking, and the Past of Protocols, Scott Shenker, with Martin Casado, Teemu Koponen, Nick McKeown 19

20. A Better Example: Programming Machine languages: no abstractions –Mastering complexity was crucial Higher-level languages: OS and other abstractions –File system, virtual memory, abstract data types,... Modern languages: even more abstractions –Object orientation, garbage collection,… Abstractions key to extracting simplicity

21. Software Defined Networking No longer designing distributed control protocols Much easier to write, verify, maintain, … –an interface for programming Network OS (NOS) serves as fundamental control block –with a global view of network 21

22. “The Power of Abstraction” “ Modularity based on abstraction is the way things get done” − Barbara Liskov Abstractions  Interfaces  Modularity What abstractions should we have in network control plane?

23. Abstractions  Problem Decomposition  Decompose problem into basic components (tasks)  Define an abstraction for each component  Implementation of abstraction can focus on one task  If tasks still too hard to implement, return to step 1

24. Layers are Great Abstractions Layers only deal with the data plane We have no powerful control plane abstractions! How do we find those control plane abstractions? Two steps: define problem, and then decompose it.

25. The Network Control Problem How does classical (IP-based) distributed network control plane operate today? Compute the configuration of each physical device –e.g., routing/forwarding tables, ACLs,… Operate without communication guarantees Operate within given network-level protocol Only people who love complexity would find this a reasonable request

26. Traditional Control Mechanisms Network of switches and/or routers Distributed algorithm running between neighbors

27. Programming Analogy What if programmers had to: –Specify where each bit was stored –Explicitly deal with all internal communication errors –Within a programming language with limited expressability Programmers would redefine problem: –Define a higher level abstraction for memory –Build on reliable communication abstractions –Use a more general language Abstractions divide problem into tractable pieces –and make programmer’s task easier

28. From Requirements to Abstractions 1.Operate without communication guarantees Need an abstraction for distributed state 2.Compute the configuration of each physical device Need an abstraction that simplifies configuration 3.Operate within given network-level protocol Need an abstraction for general forwarding model Once these abstractions are in place, control mechanism has a much easier job!

29. Control Plane Abstractions 1.Need an abstraction for general (data plane) packet forwarding 2.Need an abstraction for distributed state 3.Need an abstraction that simplifies configuration of each single device Once these abstractions are in place, control mechanism has a much easier job!

30. Traditional Control Mechanisms Network of switches and/or routers Distributed algorithm running between neighbors

31. Software Defined Networking Network of switches and/or routers Network OS Global Network View Control Program e.g. routing, access control

32. Specialized Packet Forwarding Hardware Feature Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Network OS Feature Restructured Network

33. Feature Network OS 1.Open interface to packet forwarding 3. Well-defined open API 2. At least one Network OS probably many. Open- and closed-source Software-Defined Network Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding

34. 1. 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 is such a data plane forwarding abstraction OpenFlow protocol (or API): –Control switch by inserting entries –Essentially gives NOS remote access to forwarding table –Instantiated in OpenvSwitch

35. What is OpenFlow Protocol/API?  SDN is not OpenFlow OpenFlow is just one of many possible data plane forwarding abstraction (others: e.g., POF, P4, …)  OpenFlow is an open API that provides a standard interface for programming the data plane switches  Openflow standardization Version 1.0: Most widely used version Version 1.1: Released in February 2011 OpenFlow transferred to ONF in March 2011 Version 1.5.0 Dec 19, 2014

36. OpenFlow Protocol/API Data Path (Hardware) Control Path OpenFlo w Controller (Server Software) App OpenFlow Switch & OpenFlow API

37. OpenFlow Switching Controller server Hardware Layer Software Layer OpenFlow Table MAC src MAC dst IP Src IP Dst TCP sport TCP dport Action OpenFlow Client **5.6.7.8***port 1 port 4port 3 port 2 port 1 1.2.3.45.6.7.8

38. 1. Separate Control from Datapath SDN Controller: Making Control Plane Decisions, e.g., routing

39. 2. Install/Cache Flow Decisions in Datapath “If header = x, send to port 4” “If header = ?, send to me” “If header = y, overwrite header with z, send to ports 5,6” Flow Table Flow Table

40. Plumbing Primitives: Match arbitrary bits in headers: –Match on any header, or new header –Allows any flow granularity Action –Forward to port(s), drop, send to controller –Overwrite header with mask, push or pop –Forward at specific bit-rate 40 Header Data Match: 1000x01xx0101001x

41. OpenFlow Table Entry Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport RuleActionStats + mask Packet + byte counters 1.Forward packet to port(s) 2.Encapsulate and forward to controller 3.Drop packet 4.Send to normal processing pipeline 5.…

42. OpenFlow Examples Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * 00:1f:.. *******port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ********22drop Routing * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action *****5.6.7.8***port6

43. OpenFlow Usage Controller PC OpenFlow Switch Alice’s code Decision? OpenFlow Protocol Alice’s Rule 43 OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center » Alice’s code: ˃ Simple learning switch ˃ Per Flow switching ˃ Network access control/firewall ˃ Static “VLANs” ˃ Her own new routing protocol: unicast, multicast, multipath ˃ Home network manager ˃ Packet processor (in controller) ˃ IPvAlice

44. Optional Material: OpenFlow Protocol/API: Some Specifics OpenFlow Switch Components OpenFlow Ports OpenFlow Tables –Match-Action Semantics –OpenFlow Pipeline Processing –OpenFlow Group Tables OpenFlow Actions

45. OpenFlow Switch: Components

46. Ports Network interfaces for passing packets between Openflow Processing and the rest of the Network Openflow switches connected through Openflow ports Types: –Physical Ports Switch defined ports correspond to a hardware interface (e.g., map one-to-one to the Ethernet interfaces) –Logical Ports Switch defined ports that do not correspond to a hardware switch interface (e.g. Tunnel-ID) –Reserved Ports Defined by ONF 1.4.0, specify generic forwarding actions such as sending to the controller, flooding and forwarding using non-openflow methods, such as normal switch processing

47. Ports - Reserved Port Types (Required) ALL –represents all ports the switch can use for forwarding a specific packets –Can be used only as output interface CONTROLLER –Represents the control channel with the OpenFlow controller –Can be used as an ingress port or as an output port TABLE –Represents the start of the OpenFlow pipeline –Submits the packet to the first flow table IN_PORT –Represents the packet ingress port –Can be used only as an output port ANY –Special value used in some OpenFlow commands when no port is specified –Can neither be used as an ingress port nor as an output port

48. Ports - Reserved Port Types (Optional) LOCAL –Represents the switch’s local networking stack and its management stack –Can be used as an ingress port or as an output port NORMAL –Represents the traditional non-OpenFlow pipeline of the switch –Can be used only as an output port and processes the packet using the normal pipeline FLOOD –Represents flooding using the normal pipeline –Can be used only as an output port –Send the packet out on all ports except the incoming port and the ports that are in blocked state

49. OpenFlow Table Every OpenFlow switch contains multiple flow tables Each glow table contains multiple flow entries The OpenFlow pipeline processing defines how packets interact with these flow tables An OpenFlow switch is required to have at least one flow table The flow tables of an OpenFlow switch are sequentially numbered, starting at 0 Pipeline Processing –Start at the first flow table –Other flow tables may be used depending on the outcome of the match in the first table –Go only in forward direction not backward –If packet is not redirected to another flow table, then pipeline processing stops and the packet is processed with the associated action set

50. Pipeline Processing

51. Flow Entry Match fields: consist of the ingress port, packet headers, and optionally metadata specified by a previous table Priority: matching precedence of the flow entry Counters: updated when packets are matched Instructions: to modify the action set or pipeline processing Timeouts: maximum amount of time or idle time before flow is expired Cookie: used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets

52. Matching

53. Table-Miss & Flow Removal Table-miss –Flow entry added by the controller –Priority is 0 (lowest) –Actions Send packets to the controller Drop packets Direct packets to a subsequent table Flow Removal –Requested by the controller –Time expiry (hard timeout, idle timeout) –Optional switch eviction mechanism

54. Group Table Additional method for forwarding to a group of entries (select, all) Main components: –Group ID, Group Type, Counters, Action buckets ( each action bucket contains a set of actions to be executed)

55. Group Table - Group Type All –Execute all buckets in a group –Used mainly for multicast and broadcast – fwd a pkt on all the ports Select (optional) –Execute one bucket in a Group –Implemented for load sharing and redundancy Indirect –Execute one defined bucket in this Group –Supports only a single bucket ( Eg. multiple routes are pointing to same next hop) Fast failover (optional) –Execute the first live bucket –Eg. There is a primary path and secondary path – pass the traffic on primary path and if it fails use the secondary one

56. Meter Table Consists of meter entries and defining per-flow meters Per-flow meters enable OF to implement QoS operations (rate-limiting), can be combined with per-port queues for complex QoS operations Meters measures the rate of packets assigned to it and enable controlling the rate of those packets Meters are attached directly to flow entries

57. Meter Table Components of Meter table: –Meter ID, Meter Band, Counters Meter band: unordered list of meter bands, where each meter band specifies the rate of the band and the way to process packet Components of Meter band: –Band Type, Rate, Counters, Type specific arguments –Band Type : defined how to process a packet (drop/ dscp remark)

58. Instructions Instructions are executed when a packet matches entry Instruction result: Change the packet, Action set, Pipeline processing Supported instruction Types:  Meter ID  Direct a packet to the meter id. It may be droped because of metering.  Apply-Actions  Apply a specific action immediately here packets are modified between 2 flow tables  Clear-Actions  clear all the actions in the action set immediately  Write-Actions  add a new action into the existing action set. if same action exists then overwrite it.  Write-Metadata  write the masked meta data value  Goto-Table  Indicate the next table in the processing pipeline

59. Action Set  Action set is associated with each packet  FE modify the action set using write-action/ clear-action  Actions in the action-set will be executed when pipeline is stopped  Action set contains maximum of one action of each type  If multiple actions of the same type need to be added then use “Apply-Actions”  Need to follow the order below to execute action  Different Types of Action Set:  Copy TTL inwards – apply copy inward actions to the packet  Pop – apply all tag pop actions to the packet  Push MPLS – apply MPLS tag push action to the packet  Push PBB – apply PBB tag push action to the packet  Push VLAN: apply VLAN tag push action to the packet  Copy TTL outwards  Decrement TTL  Set – apply set field actions to the packet  QoS  Group – apply group actions  Output – forward a packet on the port specified by the output action

60. Action List “Apply-action”, “packet-out” messages include action list Execute an action immediately Actions are executed sequentially in the order they have been specified If action list contains an output action, a copy of the packet is forwarded in its current state to the desired port Action-set shouldn’t be changed because of action-list

61. Actions  What to do with the packet when match criteria matches with the packet  Some of the Action Type:  Output  Fwd a pkt to the specified open flow port (physical/ logical/reserved)  Set Queue  Set Queue-id of the port : determines which queue should be used for scheduling and forwarding packet  Drop  Packets which doesn’t have output action should be dropped  Group  Process the packet through specified group  Push-Tag/ Pop-Tag  Insert VLAN, MPLS tag  Set-Field  Rewriting a field in the packet header  Change TTL  Decrement TTL

62. 2. 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

63. 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)

64. 3. 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”

65. Simple Example: Access Control Global Network View Abstract Network Model How What

66. Network OS Global Network View Abstract Network Model Control Program Network Virtualization Software Defined Network: Take 2

67. What Does This Picture Mean? Write a simple program to configure a simple model –Configuration merely a way to specify what you want 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 Virtualization layer “compiles” these requirements –Produces suitable configuration of actual network devices NOS then transmits these settings to physical boxes

68. Network OS Global Network View Abstract Network Model Control Program Network Virtualization Software Defined Network: Take 2 Specifies behavior Compiles to topology Transmits to switches

69. Two Examples 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

70. SDN Controller: Network OS Questions: –How to obtain global information? –What are the configurations? –How to implement? –How is the scalability? –How does it really work? There are a number of SDN controllers out there –Single Machine: NOX, POX, Ryu, Floodlight, … –Multi-Machine (Distributed): OpenDaylight, ONOS,... 70

71. 71 SDN Controller Design How to design a Network Operating System?  What features or “abstractions” should be provided by this “Network Operating System”?  In particular, what should be the “global network view” & “programmatic interfaces” provided to control apps?  or what “low-level” details should be handled by Network OS?  And what is the granularity of control allowed to “apps”? Analogies (& possible differences?):  computer OS and (high-level) programming models  computer architecture: instruction sets, CPU, memory, disks, I/O devices,...  (high-level) programming language constructs: statements, data types, functions, …  OS: (virtual) memory, processes, I/O and drivers, system calls, …  (distributed) file systems (or databases or data stores)  files, directories & permissions, transactions, relations & schemas; vs. disks, ….

72. 72 SDN Controller Design Questions Some Key Questions & Issues:  How to obtain global (network-wide) information?  How to perform distributed state management?  time scales of state change dynamics? consistency issues?  What are the configurations? Abstractions & APIs?  How to implement such a Network OS?  And will it really work? E.g., response time & other performance issues?  How to program control apps? E.g., a SDN programming language?  Will it scale?  Not only in terms of network size, but also # flows, control apps, etc.?  What about reliability & security issues?  … (e.g., inter-operability, evolvability) Are there some fundamental design principles we can adopt & apply?

73. 73 NOX Case Study 1 st open-source network OS implemented in C++ by Stanford  Components:  NOX controller on PC server  network view (database)  control app processes  Network View:  switch-level topology  locations of users, hosts, middle- boxes & other network elements  services offered (e.g., web, NFS)  bindings between names & addresses  but NOT current state of network traffic  Control granularity  flow-level (as opposed to packet-level, or network-prefix level)  control exerted on flow initiation: e.g., 1 st packet of a flow (following packets treated same)

74. 74 Time Scales & Control Granularity  “Events” & control granularity  Packet arrivals: millions of arrivals per sec (on a 10G link)  Flow initiations: one or more orders less than packet arrivals (notion of “flows” is more “persistent” than Netflow)  Changes in the “network views”: order of 10s of events per second for a network of thousands of hosts  Scaling? network view vs. per-flow vs. per-packet states?  Time scales (in conventional networks)

75. 75 Programmatic Interface  Event-based:  Events: flow arrives, users come/go, links up/down, etc Some events are directly generated by Openflow switches, e.g., switch join/leave, packet received, switch stats received Others by other services/applications: e.g., user authenticated  NOX applications use a set of event handlers to register for execution when a particular event happens  Event handlers are executed in the order of their priority specified during handler registration (but how to determine priority?)  Network View and Namespaces  NOX includes a “base” applications to construct network view and maintain a high-level namespace used by other applications e.g., various “name-address” bindings  Applications can be written in a “topology-independent” manner, then “compiled” against network view to produce low-level “look-up” functions to be enforced per-packet  Also include “high-level” services (“system libraries”)

76. 76 Example I: User-Based VLAN Tagging

77. 77 Example II: Simple Scan Detection

78. 78 Example II: Simple Scan Detection

79. ONOS: Architecture Tiers Northbound - Application Intent Framework (policy enforcement, conflict resolution) OpenFlowNetConf... Apps Distributed Core (scalability, availability, performance, persistence ) Southbound (discover, observe, program, configure) Northbound Abstraction: - network graph - application intents Core: - distributed - protocol independent Southbound Abstraction: - generalized OpenFlow - pluggable & extensible

80. ONOS: Distributed Architecture for Fault Tolerance NB Core API Distributed Core (state management, notifications, high-availability & scale-out) SB Core API Protocols Adapters Protocols Adapters Protocols Adapters Protocols Adapters Apps

81. SDN Summary  General forwarding model (data plane abstraction)  Currently based on Openflow (flow-level) forwarding model prioritized rules [header: counters, actions]: match  actions  assume forwarding elements provide (standardized) APIs install and manipulate forwarding tables, perform match and actions, & collect stats, etc.  Logically centralized control plane (a “network OS”)  serve as a “network operating system” provide distributed state management, map control logic to data plane actions, etc.  provide a “global network view” to (high-level) “control apps” enable “higher-level” abstractions to hide “lower-level” details  Control apps operate on higher-level abstractions  control apps focus on “control logic” using network OS APIs Hopefully, much easier to write, verify and maintain!

82. Does SDN Work? Is it scalable?Yes Is it less responsive?No Does it create a single point of failure?No Is it inherently less secure?No Is it incrementally deployable?Yes

83. SDN: Clean Separation of Concerns Control prgm: specify behavior on abstract model –Driven by Operator Requirements Net Virt’n: map abstract model to global view –Driven by Specification Abstraction NOS: map global view to physical switches –API: driven by Distributed State Abstraction –Switch/fabric interface: driven by Forwarding Abstraction

84. SDN Architecture Overview (ONF v1.0)

85. A Short History of SDN  ~2004: Research on new management paradigms RCP, 4D [Princeton, CMU,….] SANE, Ethane [Stanford/Berkeley]  2008: Software-Defined Networking (SDN)  NOX Network Operating System [Nicira]  OpenFlow switch interface [Stanford/Nicira]  2011: Open Networking Foundation (~69 members) Board: Google, Yahoo, Verizon, DT, Msoft, F’book, NTT Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,…..  2012: Latest Open Networking Summit Almost 1000 attendees, Google: SDN used for their WAN Commercialized, in production use (few places)

86. Useful References OpenFlow Wiki OpenFlow Specification 1.3.0 OpenFlow Specification 1.5.0 Old Versions of OpenFlow Mininet OpenVSwitch