Software Defined Networking (SDN) T Computer Networks II Hannu Flinck

Transcription

1 Software Defined Networking (SDN) T Computer Networks II Hannu Flinck

2 What is Software Defined Network (SDN)? The aim of SDN is to provide open interfaces that enable the development of software that can control the connectivity provided by a set of network resources and the flow of network traffic though them. Basic characteristics: Decoupling of control and data planes Logically centralized control New abstraction for networking Exposure of abstract network resources and their state to external applications Interface between controller and the data plane defined by OpenFlow protociol. Pairs with Open vswitch (OVS) that provides data plane to be controlled by SDN

3 What is the problem SDN is solving? Server virtualization has led to dynamic workloads: Server consolidation through virtualization=> VM migration => dynamic workloads => networking challenges Traffic patterns in the (enterprise and data centers) networks changing dynamically New challenges: scalability (1000s of VMs), isolation of tenants, short SW life cycles Networks are hard to manage heavily depend on manually intensive management systems, prone to misconfiguration and errors, troubleshooting being lengthy and tiresome provisioning a service/virtual server is of oder of 60 min, provisioning connectivity for the service is days or weeks Networks are hard to evolve (compared to other SW systems)

4 Server Virtualization brought the Virtual Switches Virtual switch: A virtual switch is a software program that allows one virtual machine (VM) to communicate with another. Some vendors embed them into their virtualization software, and others include virtual switches in a server's hardware as part of its firmware. We will look into Open Virtual Switch (OVS) as one practical example that supports SDN.

5 Server Virtualization brought the Virtual Switches (cont.)

6 Limitations of Current Networks Old ways to configure a network App App App Operating System Specialized Packet Forwarding Hardware App App App Operating System App App App Operating System Specialized Packet Forwarding Hardware App App App Operating System Specialized Packet Forwarding Hardware App App App Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware 6 Ref. OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

7 Limitations of Current Networks (cont.) Feature Operating System Feature Specialized Packet Forwarding Hardware Million of lines of source code Billions of gates Many complex functions baked into infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, Cannot change dynamically to follow changing network conditions Ref. OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

8 Current Network Abstractions are not meeting the new needs Current network abstractions: no common abstractions for the control plan for routing: distributed algorithms that opeate on network graphs, RIB/FIB but they are vendor specific for isolation: Access Control Lists, VLANs, firewall rules for traffic engeering: adjusting weights, MPLS-TE etc.. There is a need for new common abstractions for forwarding state and network topology state abstractions (e.g. information and data models, and API that operate on those models)

9 Forwarding Abstraction Purpose: Abstract away forwarding hardware while still be able to express how and where to forward a packet Flexible Forwarding behavior specified by control plane Built from basic set of forwarding primitives Minimal Streamlined for speed and low-power Open and not vendor-specific OpenFlow is an example of such an abstraction Ref. Software Defined Networking (COMS ) Source: Nick Mckeown, Stanford 9

10 The big picture of SDN 3. North Bound API: Consistent, up-to-date global network view Application Application 2. At least one Network OS probably many. Open- and closed-source Network OS/SDN Controllers Packet Forwarding 1. South Bound API: Open interface to packet forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Based on Ref. Software Defined Networking (COMS ) 10

11 Network OS Network OS: distributed system of controllers that creates a consistent, upto-date network wide(logically centralized) view for its applications SDN controllers run on commodity x86-servers Floodlight, ODL, POX, Pyretic, Nettle ONIX, Beacon, + more Uses forwarding abstraction at the South Bound Interface: Get state information from forwarding elements Give control directives to forwarding elements Typically Open Flow used to provide commands and get state information Offers a Noth Bound Interface to applications: Example applications: MAC learning switch, Routing daemon, FW etc No standard NBI API, typically REST

12 FloodlightProvider Example of a SDN controller: Floodlight TopologyManager LinkDiscovery Forwarding All modules in Java New modules can be added as need Main module is FloodlightProvider Manages I/O to switches Multi-threaded via Netty library (all modules must be thread-safe) DeviceManager StorageSource RestServer REST API as North Bound API to SDN applications Controller translates application level requests into OpenFlow messages Selects the path for a flow StaticFlowPusher Based on material from Big Switch Inc

13 OpenFlow is the dominant SDN protocol at the moment Developes OpenFlow protocol specfications Short introduction to OpenFlow

14 Introduction to OpenFlow OpenFlow enables SDN controllers to determine the path of network packets through the network of switches OpenFlow is a protocol and API, not a product Standardized interface between control and forwarding plane(s) OpenFlow is used to populate forwarding tables of switches Flow entries programmed through OF Switch performs lookups in flow table Switch needs to be OpenFlow enabled

15 Alternatives to OpenFlow OpenFlow originated SDN but now also other southbound protocols and tools are being discussed and implemented by the industry: XMPP, Netconf, ForCES, PCE, etc. How do they compare against OpenFlow? OpenFlow is a very-low level abstraction/api (L2, L3, and a bit of L4) Could probably implement XMP, ForCES, PCE, etc. using OpenFlow Could not implement OpenFlow using XMP, ForCES, PCE, etc Reduced complexity from feature interaction

16 OpenFlow is between SDN controller and switch(es) North Bound API Controller OpenFlow Protocol (SSL/TCP) Control Path OpenFlow Data Path (Hardware) 16 OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

17 OpenFlow Switch & Flow Tables North Bound API SDN controller South Bound: OpenFlow Secure channel Group Table Flow Table Flow Table Flow Table Match Fields Counters Instructions Pipeline Flow Table OpenFlow Switch, e.g. OVS Match field: a field against which a packet is matched Counters: to update for matching packets Instructions: to modify the action set or pipeline processing

18 Packet flow through pipeline Source: OpenFlow Switch Specification, Version Implemented ( Wire Protocol 0x02 )

19 Pipeline processing Packet received Set tbl 0 Go through tbl N Any matches Table miss entry No No Y Y Update counters, update action set, update metadata Y Go tbl N+1 No Execute Action Set Drop packet

20 Actions Forward to Port (Physical or Virtual): All: to all interfaces except incoming interface Controller: encapsulate and send to controller Local: send to its local networking stack Table: Perform actions in the flow table In_port: Send back to input port Normal: Forward using traditional Ethernet Flood: Send along minimum spanning tree except the incoming interface Enqueue: To a particular queue in the port QoS Drop Modify Field: e.g., add/remove VLAN tags, ToS bits, Change TTL Source:

21 OpenFlow 1.2: Extensible Match Structure Field is defined to match specific protocol field: eth_dst, eth_src, vlan_pcp, Ipv4_src, tcp_src, udp_src etc. Actions are applied to matching packets OpenFlow Extensible Match (OXM) is a structure that matches a particular protocol field. A complicated match rule is defined as a sequence of OXMs, which all must match. OXM's are segregated by class, and then field. For OP1.2 there is only one class: OpenFlowBasic. Fields are defined to handle very specific protocol matching: eth_dst, eth_src, vlan_pcp, Ipv4_src, tcp_src, udp_src etc.

22 OpenFlow Examples Switching Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * Routing * 00:1f:.. * * * * * * * port6 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * * port6 Firewall Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * * 22 drop 22 OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

23 Reactive vs. Proactive modes Reactive mode Packet with no matching flow entry is sent to the controller Controller insert matching flows to the switch Efficient use of flow table Every new flow adds load to the controller If the connection between the controller and switch is lost, switch fails to serve new flows Proactive (pre-populated mode) Controller pre-polulates flow tables Zero additional flow setup time Loss of control connection doesn t disrupt traffic Benefits from wildcard (aggregated) rules

24 Selected Use cases 1. Network Virtualization Isolation 2. Virtual Machine Management and Migration 3. Network Function Chaining

25 Use Case: Network Virtualization - Isolation Alice Bob Cathy FlowVisor Isolation Policy Scalable isolation domains and network slicing. Ref. Fllodlight tutorial by Big Switch s

26 Use case: Virtual Machine Management and Migration Flexible migration of virtual machines Ref. Fllodlight tutorial by Big Switch s

27 Use Case: Network Function Chaining Network Policy: Web Firewall IDS Applications Applications SDN Controller WEB Firewall IDS Source: CPS 590: Software Defined Networking, Theophilus Benson

28 How is SDN shaping Industry? Open Networking Foundation (ONF) New non-profit standards organization (Mar 2011) Defining standards for SDN, starting with OpenFlow 39 Member Companies Cisco, VMware, IBM, Juniper, HP, Broadcom, Citrix, NTT, Intel, Ericsson, Dell, Huawei, OpenDaylight (ODL) Led by IBM and Cisco Mission is to develop open source SDN platform Provides ODL SDN controller among others Ref. Software Defined Networking (COMS ) 28

29 What about SDNv2? Will target carrier networks (that have a lot of lecagy) Will take better into account Layers 4-7, virtual switching and network function virtualization Tenets of SDNv2 1. Software goes to the edge; the core stays dumb. 2. Middleboxes get included in SDN; layer 4-7 appliances 3. The network is opened up to third-party services. 4. Closed interfaces are not allowed.

30 Conclusion Software Defined Networking addressess the challenges stemming from server and network virtualization Defines new forwarding abstratctions Encompasses: controller-openflow-switch SDN controller has two APIs: North Bound and Shouth Bound (OpenFlow) OpenFlow is the dominant SDN protocol at the moment, but not the only one Use cases start from enterprise and data centers but extend to wide area networks

31 About the assigment Topic: Data center network with software-defined network Use of Mininet to set up the network, useful youtube video about how to set mininet topologies: Add hosts and switches: lefthost = self.addhost( 'h1' ), leftswitch = self.addswitch( 's11' ) Add links self.addlink( lefthost, leftswitch ) Attach a controller (there is its own ref. controller with Mininet install, but POX maybe better) Create an application that uses the controller: a forwarding algorithm