Taxonomy of SDN. Vara Varavithya 17 January 2018

Transcription

1 Taxonomy of SDN Vara Varavithya 17 January 2018

2 Modern Data Center Environmentally protected warehouses Large number of computers for compute and storage Blades Computer- Top-of-Rack (TOR) Switches

3 Full Blown Data Center 120,000 Physical Servers, 20 VMs per Physical Servers Provide connection to 2.4 million hosts The legacy Internet is too complex to operate in the complex Data Center with reliable high bandwidth links. East-West Traffic: packet sent by one host in a data center t another host in the same data center North-South Traffic: traffic entering and leaving the data center from/to the outside world. Majority of the traffic is East-West Current IP protocol spend 30% of CPU cycles to rediscovering and recalculating routes.

4 Data Center Needs Automation-Agility Scalability- Limitation of MAC address Table Size and VLANs, Broadcast Problems Multi-pathing Multi-tenancy Network Virtualization

5 Human Based Switches

6 Software Switches

7 Hardware Switches

8 vswitches and Hardware Switches

9 SDN Arguments Array of control protocols was necessary for autonomous switches. These conditions do not exist in modern data center. Stable topology, centralized, consistent set of forwarding table Network management nightmare Fine Grain Control of PacketsQoS: Data, Voice, Video Policy-Based Routing based on FLOW, set of application traffic between two end points.

10 SDN Characteristics Address weaknesses of the current network paradigm. Remedy weakness of distributed control, better for mega-scale data centers Centralized network architecture, Highly scalable, Program the switches Ability to perform fine-grained traffic forwarding decisions

11 SDN is defined as Plane separation Centralized Controller Simplified device Program forwarding tables Centralized Control Network Automation and virtualization Openness

12 Network Plane Data plane: buffering, packet scheduling, header modification and forwarding SNMP Management Plane Control plane: maintain forwarding table, process protocols, manage active topology Management plane: configure and monitoring Policy Statistics Forwarding Table Configuration Routing Protocols Unknown Incoming packets Program Forwarding Tables Control Plane Data Plane

13 Plane Separation Separate forwarding and control planes Forwarding plane investigate MAC, IP, VLAN ID and perform forwarding logic, consult with forwarding table. Actions: forward, drop, consume, or replicate It may also transform the packet in some manner

14 Actions Forwarding-look up the output ports from the address table in the hardware ASIC Drop-due to buffer overflow or due to packet filtering resulting from QoS or security. Consume-Send to control or management plane Replicate-multicast, replicated before forwarding to different output ports.

15 Forwarding Logic and Table Intelligence Logic and algorithm reside in the control plane. Some require global knowledge of the network. Control plane determines all details of forwarding table and logic in the data plane Primary task of control plane is loop prevention and run routing and switching protocol to synchronize

16 Simple Device and Centralized Control Legacy devices have hundreds of thousands of lines of code to run the protocol. Software is removed from the device and placed in a centralized controller. Controller provides primitives instructions to the simplified devices This allow fast decision about how to deal with incoming packets.

17 Network Automation and Virtualization Simplifying abstractions-network abstractions Abstraction: Distributed state, forwarding, and configuration Configuration abstraction-so called specification abstraction Network virtualization at the most basic level

18 Openness Interface should remain standard and well documented and not proprietary API should give software sufficient control. Keep open both the northbound and south bound interface Easy experiment with and test new ideas

19 Forerunner of SDN

20 OpenFlow a protocol between a controller and switches Basic Operations Controller populates the switch with flow table entries Switch examine headers for flow matching-l2- L3-L4 If no match found, send to controllers

21 OpenFlow Design OpenFlow Controller OpenFlow OpenFlow OpenFlow Forwarding Table Switch Fabrics OpenFlow Switch Forwarding Table Switch Fabrics OpenFlow Switch Forwarding Table Switch Fabrics OpenFlow Switch

22 Open Network Foundation

23 SDN Operation Forwarding Table Data Forwarding Forwarding Table Data Forwarding Forwarding Table Data Forwarding Forwarding Table Data Forwarding Forwarding Table Data Forwarding APP APP APP APP Northbound API Global Network Views Southbound API Controller Forwarding Table Data Forwarding Forwarding Table Data Forwarding Table Data Forwarding Forwarding Table Data Forwarding Forwarding Forwarding Table Data Forwarding

24 SDN Devices SDN Devices-Data and flow with forwarding hardware Flow-a set of packet between two end points- IPs-Ports/IPd-Portd VLAN endpoints Layer-3 Tunnel endpoints Input port

25 Flow Table Resides on the network device Consists of a series of flow entries and actions Perform packet matching when flow arrive at the device When match, takes the appropriate action If not match, pass to the controller or drop To speed up the packet forwarding at the line-rate, we need simple digested form, in our case the flow entry

26 SDN Controller responsible for abstracting the network of SDN devices Presenting an abstraction of network resources to SDN applications Allow SDN application to respond to the define flows maintains a view of the entire network that it controls Optimal solutions is possible. Controller is much more powerful compared to the router. 6-core 2G vs single core 1G

27 SDN Application SDN application is not the layer 7th in the OSI model. It just layer 2-3. Set proactive flows on the device at the start of devices Receive the packet from the controller proactive flow can be static or adaptive based on traffic load Reactive flow-incoming packets is forwarded to the controller and the controller establish new flows

28 Flow Tables Flow table is the fundamental data structures Device evaluate packets and consult flow table A packet is evaluated based on certain fields Depending on that evaluation, actions are taken Actions: forward, drop, flood

29 Match fields Can have wildcards Examples Match IP address or subnet Match only MAC Address Match only UDP/TCP Port Wildcards is irrelevant information in the header.

30 Challenges How to translate from flow entries to hardware entries? Which flow entries to handle in hardware? Which one will fall back to software? How to deal with action limitation? How to track statistics?

31 Existing SDN Device Implementations Open vswitch, Nicira-Software Indigo, big switch-software Cisco, HP, NEC, Juniper, and extreme-add openflow support. White box switches use OvS or Indigo for the Openflow logic

32 SDN Controller From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

33 SDN Controller Northbound and southbound APIs OpenFlow for Southbound API Cisco CLI/SNMP also considered as southbound interface REST/JSON for northbound APIs OpenFlow s Companion protocol-of-config and Nicira s Open vswitch Database Management Protocol

34 SDN Controller Core Modules Controller abstracts controller-to-device protocol with following core features End-User Device Discovery Network Device Discovery Network Device Topology Management Flow Management Maintain local database for topology and statistics. Tracking devices Maintain flow cache.

35 SDN Controller Interface From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

36 Existing SDN Controller NOX-C-Language Implementations Beacon-Floodlight-JAVA Trema-Ruby OpenDayLight ONOS (Open Network Operating System) Vendor based Controller-NEC, IBM, HP

37 Alternate SDN Methods Open SDN-Original Definition of SDN Support research community and large data center such as Google and Yahoo Other two alternatives SDN via APIs SDN via Hypervisor-Based Overlay

38 SDN via APIs Employ functions that exist on networking devices Functions can be invoked remotely Using CLI, SNMP, or NETCONF Idea is top move control functionality from devices to a centralized controller Improvements are programmability and centralized control

39 SDN via Device APIs From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

40 IETF Interface to Routing System (I2RS) Interface between routing protocol and routing information systems Need interface that is programmatic, synchronous Access to routing information and state Ability for network management Facilitate extensibility to provide standard data model

41 SDN via APIs Juniper s JunPS SDK-provides a rich set of network device programmability. No controller. SDN via Existing APIs Legacy APIs: SNMP, MIB, CLI, RADIUS, Transaction Language 1 (TL1), TR-069 CPE WAN Management Protocol APIs that scale well as SDN APIs: NETCONF, the BGP-LS/PCE-P Plugin, REST API

42 NETCONF/YANG Network Configuration Protocol (NETCONF) Southbound APIs Use XML for passing data and commands to and from the networking devices. Use secure channel to operate Separate configuration and operational data

43 NETCONF Announcement of capabilities The first exchange between a NETCONF server on the device For the device that support YANG YANG-a formal language for expressing the device s capabilities. Operations: NETCONF uses RPC PRO-Backward compatibility to legacy devices-supported by Juniper and Cisco CON- YANG Model has limited capabilities, SNMP and MIB were developed in very early days.

44 BGP-LS/PCE-P Plugin Gathering topology information Setting paths and routes SDN controller uses BGP to gather route topology and BGP link state to retrieve routing And Path Computation Element Protocol to acquire topology information related to MPLS. Similarly use BGP and PCE to insert routes and paths to devices

45 Examples of SDN via APIs Cisco- Cisco onepk consists of a broad set of APIs in the devices with Cisco Extensible Network Controller Cisco has Application Policy Infrastructure Controller OpenDaylight-Open source project support NETCONF and BGP-LS/PCE Juniper-Contrial support NETCONF Arista

46 SDN via Controller APIs Controller level APIs as a Platform to build SDN applications Southbound API is OpenFlow for OpenSDN For SDN via Controller API, Southbound consists of one or more protocols Provide a level of abstraction between devices and the application

47 SDN via Controller APIs From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

48 Controller APIs Abstraction of legacy protocols BGP BGP-LS (Link State) PCE-P Path Computation Element Protocol Light Processing- NETCONF, YANG, RESTCONF

49 OpenDaylight controller APIs From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

50 SDN via Hypervisor-Based Overlay Creates a completely new virtual network infrastructure over the underlying network. Each VM can be a member of a separate virtual network. Virtual Switch at each server manage traffics. Using IP addressing tunnels Virtual tunnel endpoints (VTEPs)

51 Hypervisor-Based Leave networking devices and configuration unchanged. Create hypervisor-based virtualized networks Using tunneling Tunnel Endpoint or Virtual Tunnel Endpoint (VTEP)

52 Virtualized Networks VM1 VM2 VM3 VM4 (VSS) VSphere Standard Switch vnic vport vswitch Host A VM1 VM2 VM3 VM4 PG-A PG-B (VSS) Port Group (PG) Host A vmnic or pnic VLAN tagged traffic From vsphere Standard Switch and vsphere Distributed Switch

53 Virtualized Networks vcenter VM1 dvpg-a VDS (local component) dvuplink-pg VM2 dvpg-a dvpg-b VDS (local component) dvuplink-pg VM3 VDS (local component) dvuplink-pg vcenter representation of the data center Physical data center Host A Host B Host C From vsphere Standard Switch and vsphere Distributed Switch

54 Technology Report Card From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

55 Drawbacks of SDN Too much change, too quickly The expense of new equipment Too risky Too revolutionary Controller is a single point of failure

56 Controller Cluster From Software Defined Networks: A Comprehensive Approach 1st Edition by Paul Goransson and Chuck Black

57 Conclusions SDN TAXONOMY PURE SDN NETCONF OVERLAY NETWORK