TE581-Software Defined Networking-2019aaaaaaaaaaaaaaaa.pptx

Engineering

1. TE581: Computer Networks & Protocols Software Defined Networking

2. Two Key Network-Layer Functions Forwarding when a packet arrives at a router’s input link the router must move the packet to the appropriate output link It is a router-local action of transferring a packet from an input link interface to the appropriate output link interface refers to the way a packet is delivered to the next node 1 2 3 0111 values in arriving packet header

3. Two Key Network-Layer Functions Routing there are more than one route from the source to the destination the network layer is responsible for determining the ‘best’ route or path taken by packets as they flow from a sender to a receiver It is a network-wide process that determines the end-to-end paths that packets take from sender to receive routing algorithms refers to the way routing tables are created to help in forwarding

4. 1 2 3 0111 value in arriving packet’s header routing algorithm local forwarding table header value output link 0100 0101 0111 1001 3 2 2 1 Interplay between routing and forwarding

5. Network layer: data plane Data plane (Part of the network that carries user traffic) local, per-router function determines how datagram arriving on router input port is forwarded to router output port forwarding function 1 2 3 0111 values in arriving packet header

6. Network layer: control plane Control plane (make decisions about where traffic is sent) Part of the network that carries signaling traffic and is responsible for routing (configuration, management and exchange of routing table information) network-wide logic determines how datagram is routed among routers along end-end path from source host to destination host

7. N etwork -layer functions forwarding: move packets from router ’ s input to appropriate router output data plane control plane two network-layer functions: routing: determine route taken by packets from source to destination

8. Network Design Philosophy Networks and networking devices have been designed to overcome RARE but severe challenges The philosophy is survivability

9. Traditional Networking The data and control planes baked into one box

10. Traditional Switches & Routers

11. Networks design not based on formal principles Networks used to be simple Basic Ethernet/IP straightforward, easy to manage For every issue a protocol is developed New control requirements have led to complexity ACLs, VLANs, TE, Middleboxes , DPI,… The infrastructure still works... Only because of our great ability to master complexity Focus is on mastering complexity Ability to master complexity both blessing and curse 11

12. Simplicity To make systems easy to use and understand The focus must be on extracting simplicity The ability to master complexity is not the same as the ability to extract simplicity Extracting simplicity builds intellectual foundations Necessary for creating a discipline …. Abstraction is key to extracting simplicity What abstractions do we have in networking? Abstraction Is the act of representing essential features without including the background details or explanations

13. Data Plane Abstractions: Layers Applications …built on… Reliable (or unreliable) transport …built on… Best-effort global packet delivery …built on… Best-effort local packet delivery …built on… Local physical transfer of bits 13

14. Control Plane Abstractions 14

15. Control Plane Abstractions How do we find these abstractions? Define our problem, and then decompose it

16. The Control Plane Problem What is the control plane problem?

17. 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 swtiches what to do (configure forwarding state) What components do we want to reuse? Determining the topology information 3. Configuring forwarding state on routers/switches

18. Two Control Plane Abstractions Abstraction: global network view Provides information about current network Abstraction: forwarding model Provides standard way of defining forwarding state

19. SDN: 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 This is OpenFlow Specification of <match,action> flow entries

20. SDN Basic Concept Separate Control plane and Data plane entities Network intelligence and state are logically centralized. The underlying network infrastructure is abstracted from the applications . Execute or run Control plane software on general purpose hardware Decouple from specific networking hardware Use commodity servers and switches Have programmable data planes Maintain, control and program data plane state from a central entity An architecture to control not just a networking device but an entire network

21. Software Defined Networking (SDN) API to the data plane (e.g., OpenFlow) Logically-centralized control Switches Smart, slow Dumb, fast

22. Software-Defined Network with key Abstractions Network Operating System Routing Traffic Engineering Other Applications Well-defined API Network Map Abstraction Forwarding Forwarding Forwarding Forwarding Separation of Data and Control Plane Network Virtualization Security Data Plane Control Plane Application Plane I nstructions I nstructions I nstructions I nstructions

23. 23 Specification Abstraction Control program must express desired behavior Whether it be isolation, access control, or QoS It should not be responsible for implementing that behavior on physical network infrastructure Requires configuring the forwarding tables in each switch Proposed abstraction: Virtual Topology of network Virtual Topology models only enough detail to specify goals

24. 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 24

25. SDN

26. 26 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  G lobal Network V iew N etwork OS: G lobal Network V iew  physical switches Gathers information for global network view Conveys configurations from control program to switches Router/switches: merely follow orders from NOS

27. The Architecture of SDN

28. Software defined networking (SDN) data plane control plane Remote Controller CA CA CA CA CA 1: generalized“ flow-based” forwarding (e.g., OpenFlow) 2. control, data plane separation 3. control plane functions external to data-plane switches … 4. programmable control applications routing access control load balance

29. SDN perspective: data plane switches Data plane switches fast, simple, commodity switches implementing generalized data-plane forwarding in hardware switch flow table computed, installed by controller API for table-based switch control (e.g., OpenFlow) defines what is controllable and what is not protocol for communicating with controller (e.g., OpenFlow) data plane control plane SDN Controller (network operating system) … routing access control load balance southbound API northbound API SDN-controlled switches network-control applications

30. SDN perspective: SDN controller SDN controller (network OS): maintain network state information interacts with network control applications “above” via northbound API interacts with network switches “below” via southbound API implemented as distributed system for performance, scalability, fault-tolerance, robustness data plane control plane SDN Controller (network operating system) … routing access control load balance southbound API northbound API SDN-controlled switches network-control applications

31. SDN perspective: control applications network-control apps: “brains” of control: implement control functions using lower-level services, API provided by SND controller unbundled: can be provided by 3 rd party: distinct from routing vendor, or SDN controller data plane control plane SDN Controller (network operating system) … routing access control load balance southbound API northbound API SDN-controlled switches network-control applications

32. Network-wide distributed, robust state management Communication to/from controlled devices Link-state info switch info host info statistics flow tables … … OpenFlow SNMP … network graph intent RESTful API … Interface, abstractions for network control apps SDN controller routing access control load balance Components of SDN controller communication layer : communicate between SDN controller and controlled switches Network-wide state management layer : state of networks links, switches, services: a distributed database Interface layer to network control apps: abstractions API

33. SDN Operation

34. OpenFlow protocol operates between controller, switch TCP used to exchange messages optional encryption three classes of OpenFlow messages: controller-to-switch asynchronous (switch to controller) symmetric ( misc ) OpenFlow Controller

35. OpenFlow: controller-to-switch messages Key controller-to-switch messages features: controller queries switch features, switch replies configure: controller queries/sets switch configuration parameters modify-state: add, delete, modify flow entries in the OpenFlow tables packet-out: controller can send this packet out of specific switch port OpenFlow Controller

36. OpenFlow: switch-to-controller messages Key switch-to-controller messages packet-in: transfer packet (and its control) to controller. See packet-out message from controller flow-removed: flow table entry deleted at switch port status: inform controller of a change on a port. Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller OpenFlow Controller

37. Link-state info switch info host info statistics flow tables … … OpenFlow SNMP … network graph intent RESTful API … 1 2 3 4 6 5 Dijkstra’s link-state Routing s1 s2 s3 s4 SDN: control/data plane interaction example S1, experiencing link failure using OpenFlow port status message to notify controller 1 SDN controller receives OpenFlow message, updates link status info 2 Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called. 3 Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes 4

38. Link-state info switch info host info statistics flow tables … … OpenFlow SNMP … network graph intent RESTful API … 1 2 3 4 6 5 Dijkstra’s link-state Routing s1 s2 s3 s4 SDN: control/data plane interaction example link state routing app interacts with flow-table-computation component in SDN controller, which computes new flow tables needed 5 Controller uses OpenFlow to install new tables in switches that need updating 6

39. What is OpenFlow

40. OpenFlow protocol operates between controller, switch TCP used to exchange messages optional encryption three classes of OpenFlow messages: controller-to-switch asynchronous (switch to controller) symmetric ( misc ) OpenFlow Controller

41. OpenFlow: controller-to-switch messages Key controller-to-switch messages features: controller queries switch features, switch replies configure: controller queries/sets switch configuration parameters modify-state: add, delete, modify flow entries in the OpenFlow tables packet-out: controller can send this packet out of specific switch port OpenFlow Controller

42. OpenFlow: switch-to-controller messages Key switch-to-controller messages packet-in: transfer packet (and its control) to controller. See packet-out message from controller flow-removed: flow table entry deleted at switch port status: inform controller of a change on a port. Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller OpenFlow Controller

43. Link-state info switch info host info statistics flow tables … … OpenFlow SNMP … network graph intent RESTful API … 1 2 3 4 6 5 Dijkstra’s link-state Routing s1 s2 s3 s4 SDN: control/data plane interaction example S1, experiencing link failure using OpenFlow port status message to notify controller 1 SDN controller receives OpenFlow message, updates link status info 2 Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called. 3 Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes 4

44. Link-state info switch info host info statistics flow tables … … OpenFlow SNMP … network graph intent RESTful API … 1 2 3 4 6 5 Dijkstra’s link-state Routing s1 s2 s3 s4 SDN: control/data plane interaction example link state routing app interacts with flow-table-computation component in SDN controller, which computes new flow tables needed 5 Controller uses OpenFlow to install new tables in switches that need updating 6

45. How Does OpenFlow Work? OpenFlow Switch and Tables General purpose PC, Server OpenFlow protocol Data Path, H/W Control Path OpenFlow Controller ( Server Software) App App App Ethernet Switch

46. What is OpenFlow ? Allow separation of control and data planes. Centralization of control. Flow based control. Takes advantage routing tables in Ethernet switches and routers. SDN is not O penFlow . SDN is a concept of the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices. OpenFlow is communication interface between the control and data plane of an SDN architecture . A llows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual. Think of as a protocol used in switching devices and controllers interface.

47. Research Problems Scalability: Control plane bottleneck . Single controller is not sufficient to manage large scale network. How many controllers are needed to support large scale network? When to scale down? Multi Controllers. Each controller is responsible to a subset of the network. Concern with synchronization and communication between controllers. How to slice the resources among controllers? Latency between controllers and switches. Less accurate decision?

48. Research Challenges in SDN Research Issues in SDN 1 Controller Design Traffic Engineering 2 3 Debugging, Testing Security 4 5 Failover

49. Four Crucial Points SDN is me r e l y se t of a b stra c t i ons for cont r ol p l a n e N o t a spec i fic set o f mechan i sms OpenF l ow is l e ast i n teres t i n g asp e ct of S D N , techn i ca l ly SDN i nvo lv es c om put i ng a fu n c t i o n…. NOS han d l e s distributi o n of state …on an a b s t r act n etwo r k C a n i g nore actual phys i cal i n f r astructure Netwo r k v i rtu a l iz at i on is t h e “k i ll e r a p p ” A l ready virtual i zed compute, storage; network is ne x t

50. Conclusion Key ideas of SDN: Dynamic programmability in forwarding packets. Decoupling control and data plane. Global view network by logical centralization in control plane. Applications can be implemented on top of the control plane. SDN is a concept to manage network that leverages OpenFlow protocols .