1 / 70

Software Defined Networking (SDN )

Software Defined Networking (SDN ). CS 401/601 Computer Network Systems Mehmet Gunes. Modified from: Jim Kurose, Keith Ross, William Stallings, Mohammad Alizadeh and Haitham Hassanieh. Quality of Service (QoS). The measurable end-to-end performance properties of a network service

vrichard
Download Presentation

Software Defined Networking (SDN )

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. Software Defined Networking (SDN) CS 401/601 Computer Network Systems Mehmet Gunes Modified from: Jim Kurose, Keith Ross, William Stallings, Mohammad Alizadehand HaithamHassanieh

  2. Quality of Service (QoS) • The measurable end-to-end performance properties of a network service • which can be guaranteed in advance by a service level agreement (SLA) between a user and a service provider • so as to satisfy specific customer application requirements

  3. Quality of Experience (QoE) • A subjective measure of performance as reported by the user; relies on human opinion • Is important particularly when dealing with multimedia applications and multimedia content delivery • QoS processes by themselves are not sufficient in that they do not take into account the user’s perception of network performance and service quality • Categories of factors and features that can be included in QoE are: • Perceptual • Psychological • Interactive

  4. Routing Characteristics • The primary function of an internet is to accept packets from a source station and deliver them to a destination station • To accomplish this, a path or route through the network must be determined • Generally, more than one route is possible; therefore, a routing function must be performed • Selection of a route is generally based on some performance criterion • Simplest criterion is to choose the minimum-hop route (one that passes through the least number of nodes) through the network • A generalization of the minimum-hop criterion is least-cost routing; in this case, a cost is associated with each link, and, for any pair of attached stations, the route through the network that accumulates the least cost is sought

  5. Routing Protocols • Routers are responsible for receiving and forwarding packets through the interconnected set of networks • Each router makes routing decisions based on knowledge of the topology and traffic/delay conditions of the internet • A degree of dynamic cooperation is needed among the routers • The router must avoid portions of the network that have failed and should avoid portions of the network that are congested

  6. Routing Protocols • There are essentially two categories of routing protocols which are based on the concept of an autonomous system (AS) • An AS exhibits the following characteristics: • An AS is a set of routers and networks managed by a single organization • An AS consists of a group of routers exchanging information via a common routing protocol • Except in times of failure, an AS is connected (in a graph-theoretic sense) • An interior router protocol (IRP) is a shared routing protocol that passes routing information between routers within an AS

  7. Evolving Network Requirements • A number of trends are driving network providers and users to reevaluate traditional approaches to network architecture • Demand is increasing • Cloud computing • Big data • Mobile traffic • The Internet of Things (IoT) • Supply is increasing • Traffic

  8. Traditional Network Architectures are Inadequate • As QoS and QoE requirements imposed on the network are expanded, • the traffic load must be handled in an increasingly sophisticated and agile fashion • The traditional internetworking approach is based on the TCP/IP protocol architecture; characteristics of this approach are: • Two-level end system addressing • Routing based on destination • Distributed, autonomous control

  9. The Networking “Planes” • Data plane: processing and delivery of packets with local forwarding state • Forwarding state + packet header forwarding decision • Filtering, buffering, scheduling • Control plane: computing the forwarding state in routers • Determines how and where packets are forwarded • Routing, traffic engineering, failure detection/recovery, … • Management plane: configuring and tuning the network • Traffic engineering, ACL config, device provisioning, …

  10. Timescales

  11. Data and Control Planes Processor control plane data plane Switching Fabric Line card Line card Line card Line card Line card Line card

  12. Data Plane • Streaming algorithms on packets • Matching on some header bits • Perform some actions • Example: IP Forwarding 1.2.3.4 1.2.3.7 1.2.3.156 5.6.7.8 5.6.7.9 ... ... host host host host host host LAN 2 LAN 1 router router router WAN WAN 1.2.3.0/24 5.6.7.0/24 forwarding table

  13. Control Plane • Compute paths the packets will follow • Populate forwarding tables • Traditionally, a distributed protocol • Example: Link-state routing (OSPF, IS-IS) • Flood the entire topology to all nodes • Each node computes shortest paths • Dijkstra’s algorithm

  14. Management Plane • Traffic Engineering: setting the weights • Inversely proportional to link capacity? • Proportional to propagation delay? • Network-wide optimization based on traffic? 2 1 3 1 3 2 3 1 5 4 3

  15. Challenges (Too) many task-specific control mechanisms • No modularity, limited functionality Indirect control • Must invert protocol behavior, “coax” it to do what you want • Ex. Changing weights instead of paths for TE Uncoordinated control • Cannot control which router updates first Interacting protocols and mechanisms • Routing, addressing, access control, QoS • The network is • Hard to reason about • Hard to evolve • Expensive

  16. Example 1: Inter-domain Routing • Today’s inter-domain routing protocol, BGP, artificially constrains routes • Routing only on destination IP address blocks • Can only influence immediate neighbors • Very difficult to incorporate other information • Application-specific peering • Route video traffic one way, and non-video another • Blocking denial-of-service traffic • Dropping unwanted traffic further upstream • Inbound traffic engineering • Splitting incoming traffic over multiple peering links

  17. Traffic engineering: difficult traditional routing 5 w z u v y x 3 5 2 2 1 3 1 2 1 Q: what if network operator wants u-to-z traffic to flow along uvwz, x-to-z traffic to flow xwyz? A: need to define link weights so traffic routing algorithm computes routes accordingly (or need a new routing algorithm)!

  18. Traffic engineering: difficult 5 w z u v y x 3 5 2 2 1 3 1 2 1 Q: what if network operator wants to split u-to-z traffic along uvwzanduxyz (load balancing)? A: can’t do it (or need a new routing algorithm)

  19. z x w y v Traffic engineering: difficult 5 3 5 2 2 1 3 1 2 1 w v u y x z Q: what if w wants to route blue and red traffic differently? A: can’t do it (with destination based forwarding, and LS, DV routing)

  20. Software defined networking (SDN) • Internet network layer: historically has been implemented via distributed, per-router approach • monolithic router contains switching hardware, runs proprietary implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF, BGP) in proprietary router OS (e.g., Cisco IOS) • different “middleboxes” for different network layer functions: • firewalls, load balancers, NAT boxes, .. • ~2005: renewed interest in rethinking network control plane

  21. Recall: per-router control plane Routing Algorithm Individual routing algorithm components in each and every router interact with each other in control plane to compute forwarding tables control plane data plane

  22. Logically centralized control plane A distinct(typically remote) controller interacts with local control agents (CAs) in routers to compute forwarding tables Remote Controller CA control plane data plane CA CA CA CA

  23. Software defined networking (SDN) Whyalogically centralized control plane? • easier network management: avoid router misconfigurations, greater flexibility of traffic flows • table-based forwarding allows “programming” routers • centralized “programming” easier: compute tables centrally and distribute • distributed “programming: more difficult: compute tables as result of distributed algorithm (protocol) implemented in each and every router • open (non-proprietary) implementation of control plane

  24. Analogy: mainframe to PC evolution* App App App App App App App App App App App Specialized Applications Windows (OS) Linux Mac OS Specialized Operating System or or Open Interface Open Interface Specialized Hardware Microprocessor Vertically integrated Closed, proprietary Slow innovation Small industry Horizontal Open interfaces Rapid innovation Huge industry * Slide courtesy: N. McKeown

  25. Network OS Network OS: distributed system that creates a consistent, up-to-date network view • Runs on servers (controllers) in the network • NOX, ONIX, Floodlight, Trema,OpenDaylight, HyperFlow, Kandoo, Beehive, Beacon, Maestro, … + more Uses forwarding abstraction to: • Get state information from forwarding elements • Give control directives to forwarding elements

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

  27. Generalized Forwarding and SDN Each router contains a flow table that is computed and distributed by a logically centralized routing controller logically-centralized routing controller local flow table headers counters actions control plane data plane 1 0100 1101 2 3 values in arriving packet’s header

  28. OpenFlow data plane abstraction • flow: defined by header fields • generalized forwarding: simple packet-handling rules • Pattern: match values in packet header fields • Actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller • Priority: disambiguate overlapping patterns • Counters: #bytes and #packets Flow table in a router (computed and distributed by controller) define router’s match+action rules

  29. OpenFlow data plane abstraction • flow: defined by header fields • generalized forwarding: simple packet-handling rules • Pattern: match values in packet header fields • Actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller • Priority: disambiguate overlapping patterns • Counters: #bytes and #packets * : wildcard • src=1.2.*.*, dest=3.4.5.*  drop • src = *.*.*.*, dest=3.4.*.*  forward(2) • 3. src=10.1.2.3, dest=*.*.*.*  send to controller

  30. OpenFlow: Flow Table Entries Rule Action Stats Packet + byte counters • Forward packet to port(s) • Encapsulate and forward to controller • Drop packet • Send to normal processing pipeline • Modify Fields Eth type Switch Port IP Src IP Dst IP Prot TCP sport TCP dport VLAN ID MAC src MAC dst Transport layer Network layer Link layer

  31. Examples Switch Port Switch Port Switch Port MAC src MAC src MAC src MAC dst MAC dst MAC dst Eth type Eth type Eth type VLAN ID VLAN ID VLAN ID IP Src IP Src IP Src IP Dst IP Dst IP Dst IP Prot IP Prot IP Prot TCP sport TCP sport TCP sport TCP dport TCP dport TCP dport Action Action Action Destination-based forwarding: 51.6.0.8 * * * * * * * * * port6 IP datagrams destined to IP address 51.6.0.8 should be forwarded to router output port 6 Firewall: * * * * * * * * * 22 drop do not forward (block) all datagrams destined to TCP port 22 drop 128.119.1.1 * * * * * * * * * do not forward (block) all datagrams sent by host 128.119.1.1

  32. Examples Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action Destination-based layer 2 (switch) forwarding: 22:A7:23: 11:E1:02 * * * * * * * * * port3 layer 2 frames from MAC address 22:A7:23:11:E1:02 should be forwarded to output port 6

  33. OpenFlow abstraction • match+action: unifies different kinds of devices • Router • match: longest destination IP prefix • action: forward out a link • Switch • match: destination MAC address • action: forward or flood • Firewall • match: IP addresses and TCP/UDP port numbers • action: permit or deny • NAT • match: IP address and port • action: rewrite address and port

  34. Example: datagrams from hosts h5 and h6 should be sent to h3 or h4, via s1 and from there to s2 OpenFlow example Host h6 10.3.0.6 controller s3 1 2 4 3 Host h5 10.3.0.5 s1 s2 1 match match match action action action 1 Host h4 10.2.0.4 2 ingress port = 2 IP Dst = 10.2.0.3 ingress port = 2 IP Dst = 10.2.0.4 ingress port = 1 IP Src = 10.3.*.* IP Dst = 10.2.*.* IP Src = 10.3.*.* IP Dst = 10.2.*.* 4 4 2 forward(3) forward(3) Host h1 10.1.0.1 forward(4) 3 3 Host h2 10.1.0.2 forward(4) Host h3 10.2.0.3

  35. SDN perspective: data plane switches network-control applications load balance … routing 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) access control control plane northbound API SDN Controller (network operating system) southbound API data plane SDN-controlled switches

  36. SDN perspective: SDN controller load balance 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 routing network-control applications … access control control plane SDN Controller (network operating system) northbound API southbound API data plane SDN-controlled switches

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

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

  39. OpenFlow protocol • operates between controller and switch • TCP to exchange messages • optional encryption • three classes of OpenFlow messages: • controller-to-switch • asynchronous • switch to controller • symmetric • misc OpenFlow Controller

  40. OpenFlow: controller-to-switch messages OpenFlow Controller 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

  41. OpenFlow: switch-to-controller messages OpenFlow Controller 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

More Related