Outline SDN Basics Concepts Open Flow Controller OFConfig

Outline • SDN Basics – Concepts – Open. Flow – Controller – OF-Config – Mininet 9/10/13 Software Defined Networking (COMS 6998 -8) 1

SDN • For now: a new paradigm for network management • SDN widely accepted as “future of networking” – ~1000 engineers at latest Open Networking Summit – Commercialized, in production use (few places) • E. g. , controls Google’s WAN; NTT moving to deploy – Much more acceptance in industry than in academia

Building an Artifact, Not a Discipline • Other fields in “systems”: OS, DB, etc. – Teach basic principles – Are easily managed – Continue to evolve • Networking: – – Study of an artifact: the Internet Teach (mostly) big bag of protocols Notoriously difficult to manage Evolves very slowly • Networks are much more primitive and less understood than other computer systems

What is Network Management? • Recall the two “planes” • Data plane: forwarding packets – Based on local forwarding state • Control plane: computing that forwarding state – Involves coordination with rest of system • Broad definition of “network management”: – Everything having to do with the control plane

Original goals for the control plane • Basic connectivity: route packets to destination – Local state computed by routing protocols – Globally distributed algorithms • Interdomain policy: find policy-compliant paths – Done by fully distributed BGP • For long time, these were the only relevant goals! – What other goals are there in running a network?

Also • • Isolation Access Control Traffic Engineering …

Isolation • Want multiple LANs on single physical network • Packets on LAN don’t pass through routers – But routers used to impose various controls (later) • Use VLANs (virtual LANs) tags in L 2 headers – Controls where broadcast packets go – Gives support for logical L 2 networks – Routers connect these logical L 2 networks • No universal method for setting VLAN state

Access Control • Operators want to limit access to various hosts – Don’t let laptops access backend database machines • This can be imposed by routers using ACLs – ACL: Access control list • Example entry in ACL: <header template; drop>

Summarizing • Network management has many goals • Achieving these goals is job of the control plane… • …which currently involves many mechanisms

Control Plane Mechanisms • Many different control plane mechanisms • Designed from scratch for specific goal • Variety of implementations – Globally distributed: routing algorithms – Manual/scripted configuration: ACLs, VLANs – Centralized computation: Traffic engineering

How Have We Managed To Survive? • Net. admins miraculously master this complexity – Understand all aspects of networks – Must keep numerus details in mind • This ability to master complexity is both a blessing – …and a curse!

Mastering Complexity versus Extracting Simplicity • The ability to master complexity is valuable – But not the same as the ability to extract simplicity • Each has its role: – When first getting systems to work, master complexity – When making system easy to use, extract simplicity • You will never succeed in extracting simplicity – If you don’t recognize it is a different skill set than mastering complexity

Mastering Complexity versus Extracting Simplicity • Networking has never made the distinction… – And therefore has never made the transition from mastering complexity to extracting simplicity • Still focused on mastering complexity – Networking “experts” are those that know all the details • Extracting simplicity lays intellectual foundations – This is why networking has weak foundation – We are still building the artifact, not the discipline

Why make the transition • Complexity has increased to “unmanageable” levels • Consider datacenters: – 100, 000 s machines, 10, 000 s switches – 1000 s of customers • Each with their own logical networks: ACLs, VLANs, etc • Way beyond what we can handle – Leads to brittle, ossify (harden) configurations – Probably inefficient too

An Example Transition: Programming • Machine languages: no abstractions – Had to deal with low-level details – Mastering complexity was crucial • Higher-level languages: OS and other abstractions – File system, virtual memory, abstract data types, . . . • Modern languages: even more abstractions – Object orientation, garbage collection, . . . Abstractions key to extracting simplicity

“The Power of Abstraction” “Modularity based on abstraction is the way things get done” Barbara Liskov Abstractions Interfaces Modularity −

What About Networking Abstractions? • Consider the data and control planes separately • Different tasks, so naturally different abstractions

Abstractions for Data Plane: Layers Applications …built on… Reliable (or unreliable) transport …built on… Best-effort global packet delivery …built on… Best-effort local packet delivery …built on… Physical transfer of bits

The Importance of Layering • Decomposed delivery into basic components • Independent, compatible innovation at each layer – Clean “separation of concerns” – Leaving each layer to solve a tractable problem • Responsible for the success of the Internet! – Rich ecosystem of independent innovation

Finding Control Plane Abstractions

How do you find abstractions? • You first decompose the problem…. • …and define abstractions for each subproblem • So what is the control plane problem? 21

Task: Compute forwarding state: • Consistent with low-level hardware/software – Which might depend on particular vendor • Based on entire network topology – Because many control decisions depend on topology • For all routers/switches in network – Every router/switch needs forwarding state

current approach • Design one-off mechanisms that solve all three – A sign of how much we love complexity • No other field would deal with such a problem! • They would define abstractions for each subtask • …and so should we!

Separate Concerns with Abstractions 1. Be compatible with low-level hardware/software Need an abstraction for general forwarding model 2. Make decisions based on entire network Need an abstraction for network state 1. Compute configuration of each physical device Need an abstraction that simplifies configuration

Abs#1: Forwarding Abstraction • Express intent independent of implementation – Don’t want to deal with proprietary HW and SW • Open. Flow is current proposal forwarding – Standardized interface to switch – Configuration in terms of flow entries: <header, action> • Design details concern exact nature of: – Header matching – Allowed actions

Two Important Facets to Open. Flow • Switches accept external control messages – Not closed, proprietary boxes • Standardized flow entry format – So switches are interchangeable 26

Abs#2: Network State Abstraction • Abstraction: global network view – Annotated network graph provided through an API • Implementation: “Network Operating System” – Runs on servers in network (“controllers”) – Replicated for reliability • Information flows both ways – Information from routers/switches to form “view” – Configurations to routers/switches to control forwarding

Network Operating System • Think of it as a centralized link-state algorithm • Switches send connectivity info to controller • Controller computes forwarding state – Some control program that uses the topology as input • Controller sends forwarding state to switches • Controller is replicated for resilience – System is only “logically centralized” 28

Network of Switches and/or Routers

Traditional Control Mechanisms Distributed algorithm running between neighbors Complicated task-specific distributed algorithm

Software Defined Network (SDN) routing, access control, etc. Control Program Global Network View Network OS

Major Change in Paradigm • Control program: – Configuration = Function(view) • Control mechanism now program using NOS API • Not a distributed protocol, just a graph algorithm 32

Abs#3: Specification Abstraction • Control mechanism expresses desired behavior – Whether it be isolation, access control, or Qo. S • It should not be responsible for implementing that behavior on physical network infrastructure – Requires configuring the forwarding tables in each switch • Proposed abstraction: abstract view of network – Abstract view models only enough detail to specify goals – Will depend on task semantics

Simple Example: Access Control A B Abstract Network View A Global Network View B

Routing • Look at graph of network • Compute routes • Give to SDN platform, which passes on to switches 35

Access Control • Control program decides who can talk to who • Pass this information to SDN platform • Appropriate ACL flow entries are added to network – In the right places (based on the topology) 36

Software Defined Network Abstract Network View Virtualization Layer Control Program Global Network View Network OS

Clean Separation of Concerns • Control program: express goals on abstract view – Driven by Operator Requirements • Virtualization Layer: abstract view global view – Driven by Specification Abstraction for particular task • NOS: global view physical switches – API: driven by Network State Abstraction – Switch interface: driven by Forwarding Abstraction 38

SDN: Layers for the Control Plane Control Program Abstract Network View Network Virtualization Global Network View Network OS

Abstractions for Control Plane Expression of Intent …built on… Abstract Network View …built on… Global Network View …built on… Physical Topology

Abstractions Don’t Remove Complexity • NOS, Virtualization are complicated pieces of code • SDN merely localizes the complexity: – Simplifies interface for control program (user-specific) – Pushes complexity into reusable code (SDN platform) • This is the big payoff of SDN: modularity! – The core distribution mechanisms can be reused – Control programs only deal with their specific function • Note that SDN separates control and data planes – SDN platform does control plane, switches do data plane

Separation of Control/Data Plane • Today, routers implement both – They forward packets – And run the control plane software • SDN networks – Data plane implemented by switches • Switches act on local forwarding state – Control plane implemented by controllers • All forwarding state computed by SDN platform • This is a technical change, with broad implications 42

Changes • Less vendor lock-in – Can buy HW/SF from different vendors • Changes are easier – Can test components separately • HW has to forward • Can simulate controller • Can do verification on logical policy – Can change topology and policy independently – Can move from private net to cloud and back! – Greater rate of innovation

Source: Nick Mckeown, Stanford App Specialized Applications Specialized Operating System Specialized Hardware Vertically integrated Closed, proprietary Slow innovation 9/10/13 Small industry Open Interface Windows (OS) or Linux or Mac OS Open Interface Microprocessor Horizontal Open interfaces Rapid innovation Software Defined Networking (COMS 6998 -8) Huge industry 44

Source: Nick Mckeown, Stanford App Specialized Features Specialized Control Plane Open Interface Control Plane 9/10/13 Control Plane or Control Plane Open Interface Merchant Switching Chips Specialized Hardware Vertically integrated Closed, proprietary Slow innovation or Horizontal Open interfaces Rapid innovation Software Defined Networking (COMS 6998 -8) 45

Source: Nick Mckeown, Stanford Routing, management, mobility management, access control, VPNs, … Feature OS Custom Hardware Million of lines of source code 6, 000 RFCs Billions of gates Bloated Power Hungry • Vertically integrated, complex, closed, proprietary • Networking industry with “mainframe” mind-set 9/10/13 Software Defined Networking (COMS 6998 -8) 46

Source: Nick Mckeown, Stanford The network is changing Feature Network OS Feature OS Feature Custom Hardware Feature OS Feature Custom Hardware OS 9/10/13 Custom Hardware Software Defined Networking (COMS 6998 -8) 47

Source: Nick Mckeown, Stanford Software Defined Network (SDN) 3. Consistent, up-to-date global network view Feature 2. At least one Network OS probably many. Open- and closed-source Network OS 1. Open interface to packet forwarding Packet Forwarding Packet Forwarding 9/10/13 Software Defined Networking (COMS 6998 -8) 48

Network OS Source: Nick Mckeown, Stanford Network OS: distributed system that creates a consistent, up-to-date network view – Runs on servers (controllers) in the network – Floodlight, POX, Pyretic, Nettle ONIX, Beacon, … + more Uses forwarding abstraction to: – Get state information from forwarding elements – Give control directives to forwarding elements 9/10/13 Software Defined Networking (COMS 6998 -8) 49

Source: Nick Mckeown, Stanford Software Defined Network (SDN) Control Program A Control Program B Network OS Packet Forwarding Packet Forwarding 9/10/13 Software Defined Networking (COMS 6998 -8) 50

Source: Nick Mckeown, Stanford Control Program Control program operates on view of network – Input: global network view (graph/database) – Output: configuration of each network device Control program is not a distributed system – Abstraction hides details of distributed state 9/10/13 Software Defined Networking (COMS 6998 -8) 51

Source: Nick Mckeown, Stanford Forwarding Abstraction Purpose: Abstract away forwarding hardware Flexible – Behavior specified by control plane – Built from basic set of forwarding primitives Minimal – Streamlined for speed and low-power – Control program not vendor-specific Open. Flow is an example of such an abstraction 9/10/13 Software Defined Networking (COMS 6998 -8) 52

Source: Nick Mckeown, Stanford By comparison: Programming Machine languages: no abstractions – Had to deal with low-level details Higher-level languages: OS and other abstractions – File system, virtual memory, abstract data types, . . . Modern languages: even more abstractions – Object orientation, garbage collection, … 9/10/13 Software Defined Networking (COMS 6998 -8) 53

Source: Nick Mckeown, Stanford Programming Analogy What if programmers had to: – Specify where each bit was stored – Explicitly deal with internal communication errors – Within a programming language with limited expressability Programmers would redefine problem by: – Defining higher level abstractions for memory – Building on reliable communication primitives – Using a more general language 9/10/13 Software Defined Networking (COMS 6998 -8) 54

Source: Nick Mckeown, Stanford Specification Abstraction Network OS eases implementation Next step is to ease specification Provide abstract view of network map Control program operates on abstract view Develop means to simplify specification 9/10/13 Software Defined Networking (COMS 6998 -8) 55

Source: Nick Mckeown, Stanford Software Defined Network (SDN) Abstract Network View Virtualization Control Program B Control Program A Global Network View Network OS Packet Forwarding 9/10/13 Packet Forwarding Packet Software Defined Networking (COMS 6998 -8) Forwarding 56

Outline • Review of previous lecture • SDN Basics – Concepts – Open. Flow – Switches and Controllers – OF-Config – Mininet 9/10/13 Software Defined Networking (COMS 6998 -8) 57

Open. Flow • Why Open. Flow? • How does Open. Flow work? 9/10/13 Software Defined Networking (COMS 6998 -8) 58

Why Open. Flow? 9/10/13 Software Defined Networking (COMS 6998 -8) 59

The Ossified Network Routing, management, mobility management, access control, VPNs, … Feature Operating System Specialized Packet Forwarding Hardware Million of lines of source code 5400 RFCs Billions of gates Bloated Barrier to entry Power Hungry Many complex functions baked into the infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … An industry with a “mainframe-mentality”, reluctant to change 9/10/13 Software Defined Networking (COMS 6998 -8) 60

Research Stagnation • Lots of deployed innovation in other areas – OS: filesystems, schedulers, virtualization – DS: CDNs, Map. Reduce – Compilers: JITs, vectorization • Networks are largely the same as years ago – Ethernet, IP, Wi. Fi • Rate of change of the network seems slower in comparison – Need better tools and abstractions to demonstrate and deploy 9/10/13 Software Defined Networking (COMS 6998 -8) 61

Closed Systems (Vendor Hardware) • • Stuck with interfaces (CLI, SNMP, etc) Hard to meaningfully collaborate Vendors starting to open up, but not usefully Need a fully open system – a Linux equivalent 9/10/13 Software Defined Networking (COMS 6998 -8) 62

Open. Flow: a pragmatic compromise • + Speed, scale, fidelity of vendor hardware • + Flexibility and control of software and simulation • Vendors don’t need to expose implementation • Leverages hardware inside most switches today (ACL tables) 9/10/13 Software Defined Networking (COMS 6998 -8) 63

How does Open. Flow work? 9/10/13 Software Defined Networking (COMS 6998 -8) 64

Ethernet Switch 9/10/13 Software Defined Networking (COMS 6998 -8) 65

Control Path (Software) Control Path Data Path (Hardware) 9/10/13 Software Defined Networking (COMS 6998 -8) 66

Open. Flow Controller Open. Flow Protocol (SSL/TCP) Control Path Open. Flow Data Path (Hardware) 9/10/13 Software Defined Networking (COMS 6998 -8) 67

Open. Flow Example Controller PC Open. Flow Client Software Layer Flow Table Hardware Layer MAC src MAC IP dst Src IP Dst TCP Action sport dport * * 5. 6. 7. 8 * port 1 5. 6. 7. 8 9/10/13 * port 2 * port 3 port 1 port 4 1. 2. 3. 4 Software Defined Networking (COMS 6998 -8) 68

Open. Flow Basics Flow Table Entries Rule Action Stats Packet + byte counters 1. 2. 3. 4. 5. Switch VLAN Port ID Forward packet to zero or more ports Encapsulate and forward to controller Send to normal processing pipeline Modify Fields Any extensions you add! VLAN MAC pcp src MAC dst Eth type IP Src IP Dst IP L 4 IP To. S Prot sport L 4 dport + mask what fields to match 9/10/13 Software Defined Networking (COMS 6998 -8) 69

Examples Switching Switch MAC Port src * MAC Eth dst type 00: 1 f: . . * * VLAN IP ID Src IP Dst IP Prot TCP Action sport dport * * port 6 Flow Switching Switch MAC Port src MAC Eth dst type port 3 00: 20. . 00: 1 f. . 0800 VLAN IP ID Src vlan 1 1. 2. 3. 4 5. 6. 7. 8 4 17264 80 port 6 Firewall Switch MAC Port src * 9/10/13 * MAC Eth dst type * * VLAN IP ID Src IP Dst IP Prot TCP Action sport dport * * * Software Defined Networking (COMS 6998 -8) 22 drop 70

Examples Routing Switch MAC Port src * * MAC Eth dst type * * VLAN IP ID Src IP Dst * 5. 6. 7. 8 * * VLAN IP ID Src IP Dst IP Prot vlan 1 * * * TCP Action sport dport 6, port 7, * * port 9 * IP Prot TCP Action sport dport * port 6 VLAN Switching Switch MAC Port src * 9/10/13 * MAC Eth dst type 00: 1 f. . * Software Defined Networking (COMS 6998 -8) 71

Centralized vs Distributed Control Both models are possible with Open. Flow Centralized Controller Open. Flow Switch Distributed Controller Open. Flow Switch 9/10/13 Controller Open. Flow Switch Software Defined Networking (COMS 6998 -8) 72

Flow Routing vs. Aggregation Both models are possible with Open. Flow-Based Aggregated • • • Every flow is individually set up by controller Exact-match flow entries Flow table contains one entry per flow Good for fine grain control, e. g. campus networks 9/10/13 • • • One flow entry covers large groups of flows Wildcard flow entries Flow table contains one entry per category of flows Good for large number of flows, e. g. backbone Software Defined Networking (COMS 6998 -8) 73

Reactive vs. Proactive (pre-populated) Both models are possible with Open. Flow Reactive Proactive • • • First packet of flow triggers controller to insert flow entries Efficient use of flow table Every flow incurs small additional flow setup time If control connection lost, switch has limited utility 9/10/13 • • • Controller pre-populates flow table in switch Zero additional flow setup time Loss of control connection does not disrupt traffic Essentially requires aggregated (wildcard) rules Software Defined Networking (COMS 6998 -8) 74

Usage examples • Alice’s code: – Simple learning switch – Per Flow switching – Network access control/firewall – Static “VLANs” – Her own new routing protocol: unicast, multipath – Home network manager – Packet processor (in controller) – IPv. Alice VM migration Server Load balancing Mobility manager Power management Network monitoring and visualization – Network debugging – Network slicing – – – … and much more you can create! 9/10/13 Software Defined Networking (COMS 6998 -8) 75

Outline • Review of previous lecture • SDN Basics – Concepts – Open. Flow – Switches and Controllers – OF-Config – Mininet 9/10/13 Software Defined Networking (COMS 6998 -8) 76

Switches and Controllers • Open. Flow switches and vendors • Controllers – Floodlight – Beacon – Nox/pox – …. 9/10/13 Software Defined Networking (COMS 6998 -8) 77

Open. Flow building blocks oftrace oflops Monitoring/ debugging tools openseer Stanford Provided ENVI (GUI) NOX LAVI Beacon Flow. Visor Console Commercial Switches HP, NEC, Pronto, Juniper. . and many more 9/10/13 n-Casting Helios Expedient Applications SNAC Controller Maestro Slicing Software Flow. Visor Stanford Provided Software Ref. Switch Net. FPGA Broadcom Ref. Switch Open. WRT PCEngine Wi. Fi AP Open. VSwitch Software Defined Networking (COMS 6998 -8) Open. Flow Switches 78 78

Current SDN hardware Juniper MX-series NEC IP 8800 Wi. Max (NEC) HP Procurve 5400 Netgear 7324 PC Engines Pronto 3240/3290 Ciena Coredirector More coming soon. . . 9/10/13 Software Defined Networking (COMS 6998 -8) 79

Commercial Switch Vendors Model Virtualize HP Procurve 5400 zl or 6600 1 OF -LACP, VLAN and STP processing instance per before Open. Flow VLAN -Wildcard rules or non-IP pkts processed in s/w -Header rewriting in s/w -CPU protects mgmt during loop NEC IP 8800 1 OF -Open. Flow takes precedence instance per -Most actions processed in VLAN hardware -MAC header rewriting in h/w Pronto 3240 or 3290 with Pica 8 or Indigo firmware 1 OF -No legacy protocols (like VLAN instance per and STP) switch -Most actions processed in hardware -MAC header rewriting in h/w Software Defined Networking (COMS 6998 - 9/10/13 Notes 8) 80

Controller Vendors Vendor Notes Nicira’s NOX • Open-source GPL • C++ and Python • Researcher friendly Stanford’s Beacon • Open-source • Researcher friendly • Java-based Nicira’s ONIX • Closed-source • Datacenter networks Big. Switch controller • Ha open source version • Based on Beacon • Enterprise network SNAC • Open-source GPL • Code based on NOX 0. 4 • Enterprise network • C++, Python and Javascript • Currently used by campuses Maestro (from Rice Univ) • Open-source • Based on Java Frenetic or Nettle • Open-source • Written in functional programming languages 9/10/13 Software Defined Networking (COMS 6998 -8) 81

Floodlight Architecture Source: Big Switch Networks Overview Floodlight. Provider (IFloodlight. Provider. Service) Topology. Manager (ITopology. Manager. Service) Link. Discovery (ILink. Discovery. Service) – Floodlight is a collection of modules – Some modules (not all) export services Forwarding Device. Manager (IDevice. Service) Storage. Source (IStorage. Source. Service) – All modules in Java – Rich, extensible REST API Rest. Server (IRest. Api. Service) Static. Flow. Pusher (IStatic. Flow. Pusher. Service) Virtual. Network. Filter (IVirtual. Network. Filter. Service) 82 Software Defined Networking (COMS 6998 -8)

Floodlight Architecture Source: Big Switch Networks Module descriptions Floodlight. Provider (IFloodlight. Provider. Service) Translates OF messages to Floodlight events Managing connections to switches via Netty Topology. Manager (ITopology. Manager. Service) • • Link. Discovery (ILink. Discovery. Service) Forwarding Device. Manager (IDevice. Service) Storage. Source (IStorage. Source. Service) Rest. Server (IRest. Api. Service) Static. Flow. Pusher (IStatic. Flow. Pusher. Service) Virtual. Network. Filter (IVirtual. Network. Filter. Service) Computes shortest path using Dijsktra Keeps switch to cluster mappings Maintains state of links in network Sends out LLDPs Installs flow mods for end-to-end routing Handles island routing Tracks hosts on the network MAC -> switch, port, MAC->IP, IP->MAC DB style storage (queries, etc) Modules can access all data and subscribe to changes Implements via Restlets (restlet. org) Modules export Restlet. Routable Supports the insertion and removal of static flows REST-based API Create layer 2 domain defined by MAC address Used for Open. Stack / Quantum 8383 Software Defined Networking (COMS 6998 -8)

Floodlight Programming Model Northbound APIs IFloodlight. Module Java module that runs as part of Floodlight External Application Consumes services and events exported by other modules Open. Flow (ie. Packet-in) Switch add / remove Device add /remove / move REST IFloodlight. Module Link discovery Floodlight Controller External Application Communicates with Floodlight via REST Quantum / Virtual networks Normalized network state Static flows Software Defined Networking (COMS 6998 -8) Switch v. Switch 84

REST API Reference Source: Big Switch Networks A moving target…but… Network State Static Flows Virtual Network User Extensions List Hosts Add Flow Create Network … List Links Delete Flow Delete Network List Switches List Flows Add Host Get. Stats (DPID) Remove. All Flows Remove Host Get. Counters (OFType…) Floodlight Controller Switch v. Switch Software Defined Networking (COMS 6998 -8) 85

Programming Floodlight Using the REST API • Fine-grained ability to push flows over REST • Access to normalized topology and device state • Extensible access to add new APIs Software Defined Networking (COMS 6998 -8) 86

Programming Floodlight Source: Big Switch Networks Creating a module • Handle Open. Flow messages directly (ie. Packet. In) • Expose services to other modules • Add new REST APIs Software Defined Networking (COMS 6998 -8) 87

Outline • Review of previous lecture • SDN Basics – Concepts – Open. Flow – Switches and Controllers – OF-Config – Mininet 9/10/13 Software Defined Networking (COMS 6998 -8) 88

Open. Flow configuration and Management Protocol • Bootstrap Open. Flow network • Switch connects to controller • Controller(s) to connect to must be configured at switches controller • Allocate resources within switches • Ports • Queues • . . . switch 89 9/10/13 Software Defined Networking (COMS 6998 -8)

Open. Flow configuration and Management Protocol: Reference Model • Configuration Point • Source of switch configuration • Open. Flow Capable Switch • Hosts one or more logical switches Configuration Point OF-CONFIG • Open. Flow Controller • Open. Flow Logical Switch • instance of an Open. Flow Switch Configuration Open. Flow Point Controller using IETF Netconf & Open. Flow XML data models Open. Flow Capable Switch OF Logical Switch resources (ports, queues) 90 9/10/13 Software Defined Networking (COMS 6998 -8) OF Logical Switch

OF-CONFIG Scope and Releases • OF-CONFIG 1. 0 (Jan 2012) based on Open. Flow 1. 2 • assigning controllers to logical switches • retrieving assignment of resources to logical switches • configuring some properties of ports and queues WG established in Sep 2011 • OF-CONFIG 1. 1 (Apr 2012) based on Open. Flow 1. 3 • added controller certificates and resource type "table" • retrieving logical switch capabilities signaled to controller • configuring of tunnel endpoints • OF-CONFIG 1. 1. 1 (Aug 2012) based on Open. Flow 1. 3. 1 • consolidation of version 1. 1, fixing small inconsistencies • OF-CONFIG 1. 2 (early 2013) based on Open. Flow 1. 3. 1 • features still under discussion, candidates include • retrieving capable switch capabilities, configuring logical switch capab. • assigning resources to logical switches • simple topology detection • event notification 91 9/10/13 Software Defined Networking (COMS 6998 -8)

Use of Netconf and Yang • Netconf was chosen as management protocol • not necessarily accepted as ideal solution • still discussing alternatives • XML schema was chosen as modeling language • So far, the focus has been on configuration • bootstrap of an Open. Flow network is the obvious first thing to do 92 9/10/13 Software Defined Networking (COMS 6998 -8)

Mininet • Machine-local virtual network – great dev/testing tool • Uses linux virtual network features – Cheaper than VMs • Arbitrary topologies, nodes

Mininet (Cont’d) • Rapidly prototype, develop and test – Interestingly-sized networks (16 -100 nodes) start up in seconds – No lengthy lab reconfiguration or rebooting required – Always-accessible network resources, in any topology, at essentially no cost – Designs that work on Mininet transfer seamlessly to hardware for full speed operation 9/10/13 Software Defined Networking (COMS 6998 -8) 94

Mininet (Cont’d) • Repeatably test, analyze, and predict network behavior – Easy replication of experimental and test results – Examine effects of code or network changes before testing/deploying on hardware – Allows automated system-level tests and experiments – Recreate real-world network and test cases for a variety of topologies and configurations 9/10/13 Software Defined Networking (COMS 6998 -8) 95

Mininet (Cont’d) • Quickly get up and running – Free and permissively licensed (BSD) – Minimal hardware requirements – Accessible to novices thanks to simple CLI – Smooth learning curve thanks to walkthrough, tutorial, examples and API documentation – Strong users and support community 9/10/13 Software Defined Networking (COMS 6998 -8) 96

Questions? 9/10/13 Software Defined Networking (COMS 6998 -8) 97