What is SDN Special Topic Software Defined Networks

What is SDN Special Topic: Software Defined Networks Rudra Dutta Computer Science, NCSU

SDN • What is it? – Does the name make sense? • • • Views Usecases Architecture Precursors Technology Copyright Spring 2017, Rudra Dutta, NCSU 2

Open. Flow • http: //www. openflow. org/ • Open standard that attempts – Virtualization – Flow routing • Main idea: separate switching (forwarding) functionality from control logic/policy – Use any box with forwarding mechanism to execute custom networking logic – Basic isolation: OF traffic and regular traffic – For OF, provide custom logic as flow definitions – Also may attempt to detect flows Copyright Spring 2017, Rudra Dutta, NCSU 3

Open. Flow • Open. Flow is an API – off a Stanford project • Control how packets are forwarded • Implemented on hardware switch Open. Flow Firmware Software Layer Open. Flow Switch Hardware Layer Controller MAC src * port 1 Flow Table MAC dst * IP Src * port 2 IP Dst 5. 6. 7. 8 TCP sport dport * * port 3 Action OF Protocol following 1 st packets routing port 1 port 4 PKT 5. 6. 7. 8 Copyright Spring 2017, Rudra Dutta, NCSU 1. 2. 3. 4 P C IP dst: 5. 6. 7. 8 4

Discussion • What was “new”/“different” in this picture? – From “traditional” picture of Internet boxes • Which of those could be done some other way? • Can we derive “software” and “defined” from it? – Are we sure it is “networking”? • Let’s go re-view the “traditional” picture Copyright Spring 2017, Rudra Dutta, NCSU 5

Peer Processes DLC Copyright Spring 2017, Rudra Dutta, NCSU DLC Phy End Node DLC Phy Phy Intermediate Node End Node 6

Layers in a Router/Switch A R D NET NET DLC DLC PHY Copyright Spring 2017, Rudra Dutta, NCSU DLC PHY PHY 7

Inter-Protocol Operation • Some of L 2 and all of L 3 protocols could be software processes – Exchange of data requires IPC, and blocking • Or if hardware, true concurrence; ? ? l Buffering may be employed between layers – Copyright Spring 2017, Rudra Dutta, NCSU Almost certainly at higher than the bitpipe layer 8

Buffering at L 3 • Operation of L 3 itself may require buffering data – Store-and-forward Store-and-process-and-store-and-forward • Input-buffer-process-buffer-output cycle – May fall behind • Discard data loss A R D NET NET DLC DLC PHY Copyright Spring 2017, Rudra Dutta, NCSU DLC PHY PHY 9

Internet Structure • From one to multiple backbones (ISPs) – Exchange points connect backbones • CAIDA MAPNET Link Copyright Spring 2017, Rudra Dutta, NCSU 10

Forwarding Decision • Made by each forwarding (intermediate) node (“router”) for the next hop only – (Why just the next hop, just ”one-hop” forwarding? ) ? Copyright Spring 2017, Rudra Dutta, NCSU

Forwarding Decision • Made by each forwarding (intermediate) node (“router”) for the next hop only – (Why just the next hop, just ”one-hop” forwarding? ) Needs to be sent to … Wants to go to … Copyright Spring 2017, Rudra Dutta, NCSU 12

Forwarding Information Base • Network (topology) information has to come to exist in the router somehow • Configured in statically or dynamically Copyright Spring 2017, Rudra Dutta, NCSU 13

Forwarding Algorithm • Rules (program) to combine network information and packet information for all rules in FIB if next rule match() forward; break endfor drop Needs to be sent to … Wants to go to … Copyright Spring 2017, Rudra Dutta, NCSU 14

Action-at-a-distance • Networking (or any distributed processing, or distributed system) is an exercise in coordination – Local actions much coordinate to produce global effect – Agreement on global effect desired is essential standardized protocols • Local actions are constrained to produce same global effect • Changing global effect agreement requires: – Agreement, if multi-owner – Changing local action globally across system Copyright Spring 2017, Rudra Dutta, NCSU 15

Uses and Interfaces • Any device/tool/object/system has: – Intended use (that it is designed for), and – Interfaces to allow such use to be made of the device • Let us review a (comparatively) simple device, ONLY in terms of use and interface (not internal operation or design) – We will leave out motive power for the moment – Let us consider computing as well as no— computing devices, and local as well as distributed Copyright Spring 2017, Rudra Dutta, NCSU 16

A Simple Local Computer • A thermostat for home HVAC system • What is the main use? – Interface for that use? • Does it need anything else to do its job? – What interface? • Can you “program” it? Copyright Spring 2017, Rudra Dutta, NCSU 17

What is “Program”? • Input - Output • Remember what the basic program flow primitives are: control flow – – Sequence (IP – first-then) Loop Conditional “Let me tell you what to do if/when you see…” • “Follow a program of. . . ” policy • Programming is setting policy – But within the “identity” of the device – A static program ends up providing identity to device Copyright Spring 2017, Rudra Dutta, NCSU 18

A Simple Local Computer • A thermostat for home HVAC system • What is the main use? – Interface for that use? • Does it need anything else to do its job? – What interface? • Can you “program” it? Copyright Spring 2017, Rudra Dutta, NCSU 19

Three Distinct Interfaces • Primary use – Whatever the device/system is designed to do • Settings / configurations / auxiliary data – Necessary to enable primary use – Comparatively static • Programming / policy specification – Optional, value-addition – Comparatively dynamic • Caution: any analogy pushed far enough turns useless Copyright Spring 2017, Rudra Dutta, NCSU 20

Programming needs Computer? • Is there a meaningful “setting policy” possible for a device that is not a (von Neumann) computer? • Consider a rather simple tool – Use? Settings? – Policy? • Observation: Line between setting configuration and setting policy is blurred – Depends on perception of ”normally expected” settings or configurability Copyright Spring 2017, Rudra Dutta, NCSU 21

How About a Computer? • • What is “primary use”? What “settings / configuration”? What ”programming”? Usual interfaces for each? • Remote (human-scale) interface access? – Feasible for which uses? Copyright Spring 2017, Rudra Dutta, NCSU 22

Which computer? • “Operating System” – Creates (changes) programmer’s view of computer • (That is, identity) – “Abstracts” underlying capabilities – Does it add, or hide, functionality? • Emulation • Virtualization Copyright Spring 2017, Rudra Dutta, NCSU 23

Back to Networking • A network is a distributed system • Main complexity / variety comes from “boxes” – Routers, switches, bridges, gateways, … – Links are communications devices rather than networking • A network “box” is a special purpose computer – Use: forward data packets – But need to configure, and possibly program – May be static Copyright Spring 2017, Rudra Dutta, NCSU 24

Architecture – What is it • Underlying structure that bridges intent and design – What something needs to do and how to do it – Actual design is distinct from architecture • Typically same architecture can be realized by many designs • Entities and interactions – Potentially at multiple levels • Entities are separated by jurisdiction/policy • Interactions define entity capabilities/functions – Must be standardized protocols – Define what, not how Copyright Fall 2016, Rudra

Network Operation • Much of network operation comes from what routers (forwarding engines) do – “They forward packets” • What routers are asked to do – Architectural question: affects many entities • How routers do what they do – Implementation question: vendor-specific smarts, black-box solutions • To have an impact on performance, must change either the How or the What – And trying to change the What will require changing/re-doing/reexamining the How also Copyright Fall, 2016, Rudra Dutta, NCSU

Ethernet – Example of Why/How • Originally a wrapper around CSMA/CD • A station does not transmit on busy carrier – Uninterrupted packet transmissions can occur, even with high traffic arrival rate • A station stops transmission on sensing collision – Time wasted in contention is reduced Copyright Fall, 2016, Rudra Dutta, NCSU

Ethernet Ether. Type/ Length 1010 (7 times) Dest. address Preamble FCS . . . SFD Source address 10101011 . . Payload 46 ≤ ≤ 1500 • Classic Ethernet • Type/Length duality – Value ≤ 1500 payload length (bytes) – Value ≥ 1536 protocol encapsulated • Organizationally Unique Identifier in addresses (first 3 octets) – For globally unique addresses (bitflag in OUI part) • • Maximum and minimum wire lengths Binary exponential backoff Reception by noting destination address 12 octet interframe gap Copyright Fall, 2016, Rudra Dutta, NCSU

Ethernet Hub • Instead of long distributed medium and short tap-offs, a short localized “medium”-in-a-box, and long “tap-off”s – Convenience in installation – But a major philosophical shift • Standard defines how stations send and transmit on medium, not how “medium” behaves – Assumption: like a wire – but not required for compliance Copyright Fall, 2016, Rudra Dutta, NCSU

Switched Ethernet • “Hub” contracted long wire into a box • “Switch” replaces short wire in box with a switchable network – No collisions – no MAC! • Supports simultaneous transmissions – But needs buffering Copyright Fall, 2016, Rudra Dutta, NCSU

Infinite Diversity Allowed • “… while SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, ATM AAL 5 or X. 25, in rough order of desirability” (RFC 2458) • RFC 1149: A Standard for the Transmission of IP Datagrams on Avian Carriers – “Avian carriers can provide high delay, low throughput, and low altitude service” Architectural change? Copyright Fall 2016, Rudra

Architectural Change • When the scope of the system, or entity within system changes • Either way, requires new protocols – Old protocols may exist unchanged, require change, or become unnecessary • Usual drivers – System scope change • The need/desire for more automation • In turn driven by the need for speed (or other desirable metric), or reducing ennui – Entity separation or re-factoring • Economics Copyright Fall 2016, Rudra

Example: IP Address Configuration • Originally static, and manual – Independently at each host that needs to connect • Desire to automate – Reducing ennui for admin (and ensuing errors) – Diskless workstations – Scale • BUT: different authority for configuring different sets of hosts – Solution must be scoped for that authority – Possibly replicated, possibly with variations, in other scope • RARP BOOTP DHCP Copyright Fall 2016, Rudra

DHCP: Dynamic Host Configuration Protocol DHCP overview: Goal: dynamically obtain an IP address from network server • • • Allows reuse of addresses Support for mobile users Critical for ISPs Relay agent on every LAN – host broadcasts “DHCP discover” msg – DHCP server responds with “DHCP offer” msg – host requests IP address: “DHCP request” msg – DHCP server sends address: “DHCP ack” msg DHCP request Copyright Fall 2016, Rudra Dutta, CSC, NCSU

Architectural Evolution • Interactions represent constraints on entities – Entities must present correct interface for other entities to be able to inter-operate • “Constrain to de-constrain” (John Doyle, Caltech) – Defining what an entity must do allows freedom in how to do it – Can create new entities and interactions that would have had no place in earlier architecture Copyright Fall 2016, Rudra

Back to Interfaces • Consider a distributed system – Three interfaces? – Each box? • Remote operation? – Only one of the three can not be remote (which? ) • What does remote operation require? – A structured standardized interface (“API”) • What does remote operation enable? – (Other than basic job of saving human travel) – Put a computer on the job – eliminate human • Issue: for remote access, need a (the) network Copyright Spring 2017, Rudra Dutta, NCSU 36

Network Box • Data Plane – The connectivity that allows each box (and network as a whole) to perform primary use – Distributed for network, local for box • Control / Signaling Plane – Settings and configurations not changing policy – Either assumes policy in place, or policy-agnostic – Usually implies automated (to/from other boxes) • Management / Knowledge Plane – Configuring policy e. g. traffic engineering Copyright Spring 2017, Rudra Dutta, NCSU 37

Networking Stack Transport Service Copyright Rudra Dutta & Magreth Mushi, NCSU, Fall,

Networking Stack Transport Service rol nt Co rol t on C Copyright Rudra Dutta & Magreth Mushi, NCSU, Fall,

Networking Stack ol ntr Control Co Copyright Rudra Dutta & Magreth Mushi, NCSU, Fall,

Networking Stack Performance Qo. S Continuity Security Policy/Mgmt/Knowledge ol ntr Control Control Co ol ntr Control Co l tro ontrol C n Control Co Copyright Rudra Dutta & Magreth Mushi, NCSU, Fall,

Policy versus Settings • Line seems to be thin – In particular, can program system (set network-level policy) by adjusting settings of components (coordinated configuration of boxlevel settings) • Common management tasks - “F C A P S” – – – Configuration Management Fault Management Performance Management Security Management Account Management • What is common to all these? – As opposed to accepting/sending OSPF “Hello”/”Reply” packets? Copyright Rudra Dutta & Magreth Mushi, NCSU, Fall, 2016

OSPF • What “plane” is that? – Clearly, not data plane (assuming network’s primary use is carrying user’s data traffic) • Creates FIB – signaling? • What does it do (on each router)? – Exchange LSAs and allow each router to build complete network graph (signaling) – Execute Dijkstra’s algorithm to find paths, extract next hop for this router, set RIB (policy) • Essential difference between the two? Copyright Spring 2017, Rudra Dutta, NCSU 43

Switch/Router Architecture Copyright Fall, 2016, Rudra Dutta, NCSU

Back to SDN • On the face of it, a simple idea – Create open, standardized, remote access interfaces to box’s settings that did not previously have such interfaces – Can use software (agile) to access these interfaces – Forwarding engine can perform standard forwarding functionality efficiently (perhaps hardware) – Separation of policy and mechanism (into boxes) • Implications very different depending on actual interfaces, and who you ask Copyright Spring 2017, Rudra Dutta, NCSU 45

Controller – Policy Box SDN Agent Flow Table SDN Agent Flow Table • Embodiment of policy box – Forwarding policy (routing), security policy, energy policy, economic policy, … – Realized in hardware or software – Or generic platform running software “policy programs” 46 Rudra Dutta, IEEE ANTS 2013

Controller Federation SDN Agent Flow Table • Different boxes belong to different entities – Controlled by different controllers • Flows route through multiple domains – Controllers must coordinate among themselves – Possibly exchange limited privileges on datapaths 47 Rudra Dutta, IEEE ANTS 2013 SDN Agent Flow Table

Many Possible SDNs • Which boxes? – Edge? Core? Network appliance? All? • Which interfaces? – What about boxes with varying capabilities? How deep? – (Ignoring heterogeneity of capabilities is not turning out well) • How open/standardized? – Southbound only? Northbound only? East-west only? – (Ignoring heterogeneity of capabilities is not turning out well) • Usable by whom? – Who has the authority/right to use each plane? Who has access? – Who owns the box/facility? Who rents/loans the facility? • For whose benefit? – Network global performance optimization? Revenue? – Network neutrality? Copyright Spring 2017, Rudra Dutta, NCSU 48

Many Faces of SDN • Flow routing? – And other traffic engineering – Coordination of network boxes (in a jurisdiction) – Policy – puts the “defined” in SDN • Control plane or Management plane separation? – At least (new) control signaling between policy box and mechanism box, at least some policy • Virtualization? – Not all capabilities of a switch may be useful for every purpose / to every controller • Programming? – Depends on how deep exposed functionality is – Implications of changing mechanism box functionality? • Network OS? – Any value added “tools” enabled (and implemented) by the policy boxes Copyright Spring 2017, Rudra Dutta, NCSU 49

Summary • SDN is an interesting new development – That may not be very new – But newest incarnation brings together a large number and variety of ideas – Causing some disruptions - probably continue – Like everything else, may suffer from silos • Worth taking a broad view – Remain open for future innovations Copyright Spring 2017, Rudra Dutta, NCSU 50