Software Defined Networking (COMS )

Software Defined Networking (COMS 6998-8)
Outline SDN Basics Concepts OpenFlow Controller OF-Config Mininet 9/10/13 Software Defined Networking (COMS )

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 L2 headers Controls where broadcast packets go Gives support for logical L2 networks Routers connect these logical L2 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,000s machines, 10,000s switches 1000s 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?

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
Be compatible with low-level hardware/software Need an abstraction for general forwarding model Make decisions based on entire network Need an abstraction for network state 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 OpenFlow is current proposal for 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 OpenFlow
Switches accept external control messages Not closed, proprietary boxes Standardized flow entry format So switches are interchangeable

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”

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

Abs#3: Specification Abstraction
Control mechanism expresses desired behavior Whether it be isolation, access control, or QoS 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
Abstract Network View A B A Global Network View B

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

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)

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

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

Changes Less vendor lock-in Changes are easier
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

Vertically integrated Closed, proprietary Slow innovation
Source: Nick Mckeown, Stanford App Specialized Applications Linux Mac OS Windows (OS) or Open Interface Specialized Operating System Microprocessor Open Interface Specialized Hardware The mainframe industry in the 1980s was vertical and closed: it consisted of specialized hardware, operating system and applications --- all from the same company. A revolution happened when open interfaces started to appear. The industry became horizontal. Innovation exploded. Vertically integrated Closed, proprietary Slow innovation Small industry Horizontal Open interfaces Rapid innovation Huge industry 9/10/13 Software Defined Networking (COMS )

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

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

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

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

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 )

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

Control Program Control program operates on view of network
Source: Nick Mckeown, Stanford 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 )

Forwarding Abstraction
Source: Nick Mckeown, Stanford 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 OpenFlow is an example of such an abstraction 9/10/13 Software Defined Networking (COMS )

By comparison: Programming
Source: Nick Mckeown, Stanford 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 )

Programming Analogy What if programmers had to:
Source: Nick Mckeown, Stanford 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 )

Specification Abstraction
Source: Nick Mckeown, Stanford 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 )

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

Outline Review of previous lecture SDN Basics Concepts OpenFlow Switches and Controllers OF-Config Mininet 9/10/13 Software Defined Networking (COMS )

OpenFlow Why OpenFlow? How does OpenFlow work? 9/10/13 Software Defined Networking (COMS )

Why OpenFlow? 9/10/13 Software Defined Networking (COMS )

Specialized Packet Forwarding Hardware
The Ossified Network Routing, management, mobility management, access control, VPNs, … Feature Feature Million of lines of source code 5400 RFCs Barrier to entry Operating System Specialized Packet Forwarding Hardware Billions of gates Bloated 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 ) 60 60

Research Stagnation Lots of deployed innovation in other areas OS: filesystems, schedulers, virtualization DS: CDNs, MapReduce Compilers: JITs, vectorization Networks are largely the same as years ago Ethernet, IP, WiFi Rate of change of the network seems slower in comparison Need better tools and abstractions to demonstrate and deploy In these other areas, you can real systems on top of high-quality, open platforms, and you don’t need to reinvent the wheel 9/10/13 Software Defined Networking (COMS )

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 )

OpenFlow: 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 )

How does OpenFlow work? 9/10/13 Software Defined Networking (COMS ) 64

Ethernet Switch 9/10/13 Software Defined Networking (COMS )

Control Path Control Path (Software) Data Path (Hardware) 9/10/13 Software Defined Networking (COMS )

OpenFlow Controller OpenFlow Protocol (SSL/TCP) Control Path OpenFlow Data Path (Hardware) 9/10/13 Software Defined Networking (COMS )

OpenFlow Example Controller PC OpenFlow Client Software Layer Flow Table MAC src dst IP Src Dst TCP sport dport Action Hardware Layer * port 1 port 1 port 2 port 3 port 4 9/10/13 Software Defined Networking (COMS )

OpenFlow Basics Flow Table Entries
Rule Action Stats Packet + byte counters Forward packet to zero or more ports Encapsulate and forward to controller Send to normal processing pipeline Modify Fields Any extensions you add! Now I’ll describe the API that tries to meet these goals. Switch Port VLAN ID VLAN pcp MAC src MAC dst Eth type IP Src IP Dst IP ToS IP Prot L4 sport L4 dport + mask what fields to match 9/10/13 Software Defined Networking (COMS )

Examples Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action * * 00:1f:.. * * * * * * * port6 Flow Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action port3 00:20.. 00:1f.. 0800 vlan1 4 17264 80 port6 Firewall Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action * * * * * * * * * 22 drop 9/10/13 Software Defined Networking (COMS )

Examples Routing Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action * * * * * * * * * port6 VLAN Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action port6, port7, port9 * * 00:1f.. * vlan1 * * * * * 9/10/13 Software Defined Networking (COMS )

Centralized vs Distributed Control Both models are possible with OpenFlow Centralized Control Distributed Control Controller Controller OpenFlow Switch OpenFlow Switch Controller OpenFlow Switch OpenFlow Switch Controller OpenFlow Switch OpenFlow Switch 9/10/13 Software Defined Networking (COMS )

Flow Routing vs. Aggregation Both models are possible with OpenFlow
Flow-Based 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 Aggregated 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 9/10/13 Software Defined Networking (COMS )

Reactive vs. Proactive (pre-populated) Both models are possible with OpenFlow Reactive 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 Proactive 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 9/10/13 Software Defined Networking (COMS )

Usage examples Alice’s code: Simple learning switch Per Flow switching Network access control/firewall Static “VLANs” Her own new routing protocol: unicast, multicast, multipath Home network manager Packet processor (in controller) IPvAlice VM migration Server Load balancing Mobility manager Power management Network monitoring and visualization Network debugging Network slicing What is possible in the controller? Anything that needs intelligent routing of a flow At Stanford, we have even shown how OpenFlow may be used for: VM migration Power management Load balancing Network monitoring and debugging Easier network visualization … and much more you can create! 9/10/13 Software Defined Networking (COMS ) 75 75

Switches and Controllers
OpenFlow switches and vendors Controllers Floodlight Beacon Nox/pox …. 9/10/13 Software Defined Networking (COMS )

OpenFlow building blocks
Monitoring/ debugging tools oftrace oflops openseer Stanford Provided ENVI (GUI) LAVI n-Casting Expedient Applications NOX Beacon Helios Maestro SNAC Controller Slicing Software FlowVisor Console FlowVisor There are components at different levels that work together in making it work The commercial switch details will follow in next slide There are a plethora of applications possible. I only list those available at Stanford Commercial Switches Stanford Provided Software Ref. Switch NetFPGA Broadcom Ref. Switch HP, NEC, Pronto, Juniper.. and many more OpenFlow Switches OpenWRT PCEngine WiFi AP OpenVSwitch 9/10/13 Software Defined Networking (COMS ) 78

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

Commercial Switch Vendors
Model Virtualize Notes HP Procurve 5400zl or 6600 1 OF instance per VLAN LACP, VLAN and STP processing before OpenFlow Wildcard rules or non-IP pkts processed in s/w Header rewriting in s/w CPU protects mgmt during loop NEC IP8800 OpenFlow takes precedence Most actions processed in hardware MAC header rewriting in h/w Pronto 3240 or 3290 with Pica8 or Indigo firmware 1 OF instance per switch No legacy protocols (like VLAN and STP) All support ver 1.0 All have approx 1500 flow table entry limit 9/10/13 Software Defined Networking (COMS ) 80

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

Floodlight Architecture
Source: Big Switch Networks Overview FloodlightProvider (IFloodlightProviderService) Floodlight is a collection of modules Some modules (not all) export services All modules in Java Rich, extensible REST API TopologyManager (ITopologyManagerService) LinkDiscovery (ILinkDiscoveryService) Forwarding DeviceManager (IDeviceService) StorageSource (IStorageSourceService) Our topology, device manager know about host attachment points and make it possible to deal with integrating openflow and non openflow networks. RestServer (IRestApiService) StaticFlowPusher (IStaticFlowPusherService) VirtualNetworkFilter (IVirtualNetworkFilterService) Software Defined Networking (COMS )

Floodlight Architecture
Source: Big Switch Networks Module descriptions FloodlightProvider (IFloodlightProviderService) Translates OF messages to Floodlight events Managing connections to switches via Netty TopologyManager (ITopologyManagerService) Computes shortest path using Dijsktra Keeps switch to cluster mappings LinkDiscovery (ILinkDiscoveryService) Maintains state of links in network Sends out LLDPs Forwarding Installs flow mods for end-to-end routing Handles island routing DeviceManager (IDeviceService) Tracks hosts on the network MAC -> switch,port, MAC->IP, IP->MAC StorageSource (IStorageSourceService) DB style storage (queries, etc) Modules can access all data and subscribe to changes Our topology, device manager know about host attachment points and make it possible to deal with integrating openflow and non openflow networks. RestServer (IRestApiService) Implements via Restlets (restlet.org) Modules export RestletRoutable StaticFlowPusher (IStaticFlowPusherService) Supports the insertion and removal of static flows REST-based API VirtualNetworkFilter (IVirtualNetworkFilterService) Create layer 2 domain defined by MAC address Used for OpenStack / Quantum 83 Software Defined Networking (COMS )

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

REST API Reference A moving target…but… Floodlight Controller Switch
Source: Big Switch Networks A moving target…but… Network State List Hosts List Links List Switches GetStats (DPID) GetCounters (OFType…) Static Flows Add Flow Delete Flow List Flows RemoveAll Flows Virtual Network Create Network Delete Network Add Host Remove Host User Extensions … Floodlight Controller Switch Switch Switch vSwitch Software Defined Networking (COMS )

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 )

Programming Floodlight
Source: Big Switch Networks Creating a module Handle OpenFlow messages directly (ie. PacketIn) Expose services to other modules Add new REST APIs Software Defined Networking (COMS )

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

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

OF-CONFIG Scope and Releases WG established in Sep 2011 OF-CONFIG 1.0 (Jan 2012) based on OpenFlow 1.2 assigning controllers to logical switches retrieving assignment of resources to logical switches configuring some properties of ports and queues OF-CONFIG 1.1 (Apr 2012) based on OpenFlow 1.3 added controller certificates and resource type "table" retrieving logical switch capabilities signaled to controller configuring of tunnel endpoints OF-CONFIG (Aug 2012) based on OpenFlow 1.3.1 consolidation of version 1.1, fixing small inconsistencies OF-CONFIG 1.2 (early 2013) based on OpenFlow 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 9/10/13 Software Defined Networking (COMS )

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 OpenFlow network is the obvious first thing to do 9/10/13 Software Defined Networking (COMS )

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 ( 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 )

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 )

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 )

Questions? 9/10/13 Software Defined Networking (COMS )

Software Defined Networking (COMS )

Similar presentations

Presentation on theme: "Software Defined Networking (COMS )"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Defined Networking (COMS )

Similar presentations

Presentation on theme: "Software Defined Networking (COMS )"— Presentation transcript:

Similar presentations

About project

Feedback