1 / 17

SDN 101 May 29 th 2013 www.noviflow.com

SDN 101 May 29 th 2013 www.noviflow.com. The Problem Networks are at an Inflection Point. Network Challenges: Networks have become too complex after 40+ years of internet evolution: Then: L2=Ethernet and L3=IP

nantai
Download Presentation

SDN 101 May 29 th 2013 www.noviflow.com

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SDN 101 May 29th 2013 www.noviflow.com

  2. The ProblemNetworks are at an Inflection Point • Network Challenges: • Networks have become too complex after 40+ years of internet evolution: • Then: L2=Ethernet and L3=IP • Now: ACLs, VLANs, VPN, DiffServ, IPSec, IPv6, NAT, Firewall, MPLS, middle boxes and much more… • Networks need to be more deterministic: • Allow more efficient use of network resources • Networks are too hard to manage: • Manual and error prone CLI based configuration of network elements • No economies of scale • Network Operators faced with flat revenues coupled with massive traffic growth and more complex applications: • IP traffic will quadruple by 20161 • Only 17% of Data Center traffic goes to users1 • Proliferation of virtualization, connected devices and cloud computing • Networks cannot continue on the same path • More and more expensive to build and operate • Slower and slower to evolve • … a new protocol for every problem is NOT the solution Source: Cisco Global Cloud Index 2012 Note 1: Cisco Global Cloud Index, 2012

  3. The SolutionSDN and OpenFlow

  4. The OpenFlow StandardArchitecture OpenFlow Protocol: Controller Maintains comm. channel Distribute flows (rules) Maintains local state graph Distributed switching pSwitches vSwitches

  5. The OpenFlow StandardFlow Tables – Pipeline Processing

  6. The OpenFlow Standard Flow Tables & Flows Table j Flow Composition: Match Fields: To match against packets. These consist of the ingress port and packet headers, and optionally metadata specified by the previous table. Priority: Matching precedence of the flow entry. Counters: To update for matching packets. Instructions: To modify the action set or pipeline processing Timeouts: Maximum amount of time or idle time before flow is expired by the switch. Cookie: Opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion, not used when processing packets.

  7. The OpenFlow StandardFlow & Packet Processing Samples Switching Flow Switching Firewall

  8. The OpenFlow StandardFlow & Packet Processing Samples Routing VLAN Switching

  9. The OpenFlow StandardMessages • Asynchronous (Switch initiated): • Packet-In: No match or match with send to controller action • Flow-Removed: Idle timeout or hard timeout • Port-Status: Switch port changed status • Error: Switch notifies controller of problems • Symmetric: • Hello: Exchanged between switch and controller upon initial connection • Echo: Initiated by either the switch or controller • Vendor: Vendor specific messages to support vendor specific functionality • Controller-to-Switch • Feature Request: Query the switch about what features it supports • Configuration Request: Configure the switch • Modify-State: Add/delete/modify flows and set port properties • Read-State: Collect statistics • Send-Packet: Send enclosed packet through a specific port • Barrier: Request/reply messages for operation completion

  10. The OpenFlow StandardMessages • Controller-to-Switch • Feature Request: Query the switch about what features it supports • Configuration Request: Configure the switch • Modify-State: Add/delete/modify flows and set port properties • Read-State: Collect statistics • Send-Packet: Send enclosed packet through a specific port • Barrier: Request/reply messages for operation completion • Asynchronous (Switch initiated): • Packet-In: No match or match with send to controller action • Flow-Removed: Idle timeout or hard timeout • Port-Status: Switch port changed status • Error: Switch notifies controller of problems • Symmetric: • Hello: Exchanged between switch and controller upon initial connection • Echo: Initiated by either the switch or controller • Vendor: Vendor specific messages to support vendor specific functionality

  11. The OpenFlow StandardReleases

  12. Sample OpenFlow ControllerFloodlight Architecture ---------------- OpenFlow Interface ---------------- • Floodlight Controller: • OpenFlow Controller • Apache-Licensed Open source • Java-based: 85 kLOC • Used by Big Switch Networks • OpenFlow interface: • Currently supports OF 1.0 • Plans for OF 1.2/1.3 in March 2013 • REST API: • Northbound interface towards OpenFlow applications • Java API: • High bandwidth interface towards OpenFlow applications

  13. Sample OpenFlow ControllerFloodlight Modules FloodlightProvider: Handles connections to switches and turns OpenFlow messages into Floodlight events. Transmits messages to switches on behalf of modules. Decides the order in which specific incoming OpenFlow messages (i.e. PacketIn, FlowRemoved, PortStatus, etc.) are dispatched to the modules that listen for the messages. TopologyManager: Maintains the network topology information. Computes shortest path using Dijkstra’s algorithm – a graph search algorithm used by link-state routing protocols such as OSPF and IS-IS. LinkDiscoveryManager: Responsible for discovering and maintaining the status of links in the OpenFlow network. Sends out Link Layer Discovery Protocol (LLDP) messages. Forwarding: Installs flow mods for end to end routing. Handles island routing. DeviceManager: Tracks hosts on the network: MAC to switch port, MAC to IP, IP to MAC mapping. Defines the destination device for a new flow. MemoryStorageSource: An in-memory NoSQL data base accessible by the modules. Supports change notifications. RestApiServer: Allows modules to expose REST APIs over HTTP. ThreadPool: Schedules tasks to run at specific times or periodically. FlowCache: Maintains a record of all active flows in all switches. [Not implemented but needed.] PacketStreamer: Selectively streams OpenFlow messages exchanged between any switch and the controller to an observer. Testing Modules: Codes for validating the functionality of the various modules of the controller (14 kLOC)

  14. Sample OpenFlow ControllerFloodlight Northbound REST API • Representational State Transfer Application Protocol Interface (REST API) • Exposes resources that may be read and/or manipulated by applications • Common stateless Client-Server protocol used on the WWW: • HTTP GET, POST, PUT, DELETE Methods • Calls consists of a “Base URI” & “JSON media type” • Sample JSON media type: {"src-ip": "10.0.0.4/32", "dl-type":"ARP"} • Examples of Floodlight REST API calls: • List all devices tracked by the controller: Curl http://localhost:8080/wm/device/ • Retrieve aggregate port statistics across all switches: Curl http://localhost:8080/wm/core/switch/all/port/json • Retrieve per switch traffic counter: Curl http://localhost:8080/wm/core/counter/switchID/statType/json • List all inter-switch links: Curl http://localhost:8080/wm/topology/links/json

  15. Sample OpenFlow ApplicationStaticFlowEntryPusher Application • Functionality: • Allows the user to manipulate flows entries in switches through an exposed REST API • Implemented as a Java module: 1,553 LOC • Examples of REST API calls: • List all flows for a switch: Curl http://localhost:8080/wm/staticflowentrypusher/list/switchID/json • Clear all flows for a switch: Curl http://localhost:8080/wm/staticflowentrypusher/clear/switchID/json • Add a flow to a switch: Curl -X POST -d '{“switch": “00:00:00:00:00:00:00:01", “name":“flow_mod_1", “priority”:”32768”, “ingress-port”:”1”, “active”:”true”, “actions”:”output=2” }' http://localhost:8080/wm/staticflow entrypusher/json • Delete a flow from a switch: Curl -X DELETE -d '{“name": “flow_mod_1" }' http://localhost:8080/wm/staticflowentrypusher/json

  16. Sample OpenFlow Application CircuitPusher Application • Functionality: • Creates a bi-directional circuit with two IP end points • Implemented as Python module: 200 LOC • Examples how to use it: • List all flows for a switch: Curl http://localhost:8080/wm/staticflowentrypusher/list/switchID/json • Clear all flows for a switch: Curl http://localhost:8080/wm/staticflowentrypusher/clear/switchID/json • Add a flow to a switch: Curl -X POST -d '{“switch": “00:00:00:00:00:00:00:01", “name":“flow_mod_1", “priority”:”32768”, “ingress-port”:”1”, “active”:”true”, “actions”:”output=2” }' http://localhost:8080/wm/staticflow entrypusher/json

  17. Sample OpenFlow Application Firewall Application • Functionality: • Create firewall rules: switch_id, src/dst-MAC, src/dst-IP, network protocol (TCP, UDP, ICMP), TCP/UDP port-src/dst, dl-type (ARP, IPv4), priority, and action (ALLOW or DENY) • Implemented as Java module: 1,576 LOC • Using REST API calls, enable/disable firewall and create/delete firewall rules that are pushed to the identified OpenFlow switch • Examples of Firewall REST API calls: • Check Firewall status: Curl http://localhost:8080/wm/firewall/module/status/json • Enable Firewall: Curl http://localhost:8080/wm/firewall/module/enable/json • Add rule to Firewall: • Curl -X POST -d '{"src-ip": "10.0.0.4/32", "nw-proto":"UDP", "tp-src":"5010", "action":"DENY" }' http://localhost:8080/wm/firewall/rules/json

More Related