The document discusses tools and platforms for OpenFlow/SDN developed by the Open Networking Lab, including Mininet for emulating OpenFlow networks, Flowvisor for sharing OpenFlow switches, and Open Network OS as an SDN controller. It then discusses some specific problems like inter-datacenter WAN traffic engineering and potential solutions using an SDN approach with open source software and hardware components. Key components discussed include Open Compute switches running an OpenFlow agent and interfacing with an SDN controller like ONOS, as well as routing between SDN and IP networks using the SDN-IP application.
2. About Open Networking Lab
Non-profit lab founded in 2012
Mission to develop, distribute, support open-source tools and
platforms for SDN
Projects:
Mininet: emulate an OpenFlow network on your laptop/EC2
Flowvisor: share OpenFlow switches
Open Network OS: distributed SDN controller
OpenvirteX: network hypervisor
OpenCloud: unified service orchestration in a cloud
3. Early SDN Activities
Platform
Development
2007 – Ethane
2008 – OpenFlow
2009 –
FlowVisor, Mininet,
NOX
2010 – Beacon
2009 – Stanford
2010 – GENI started
and grew to 20
universities
2013 – 20 more
campuses to be
added
Deployments
Demonstrations
2008-2011 – SIGCOMM
2011 – Open
Networking
Summit, Interop
2012 –Define
SDN research
agenda for the
coming years
And Beyond
Invention
2007 – Creation
of SDN Concept
6. Inter-Datacenter WAN Traffic Engineering
Inter-site traffic is huge and growing.
Critical for search, video, cloud computing, enterprise applications
Think Amazon, Facebook, Google, Microsoft
Multiple $100M annualized cost
Poor utilization of inter-DC WAN links
30-40% per Google B4 paper
30-50% per Microsoft SWAN paper
Existing solutions (MPLS-TE) do not work for these end-users
Poor coordination with applications
Distributed resource allocation is not optimal
8. Approaches to build this solution
Google built an OpenFlow WAN called B4 to solve this
Let us see if a solution is possible with open source software and
hardware
Integrates work from:
Open Compute Project
Open Networking Foundation
Goal is to show you how pieces fit into an SDN solution
10. Central TE Server
Open Compute Switch
OpenFlow AgentSDN Controller
SDN apps: TE, Routing, Flow
OpenFlow
Linux OS
Commodity Server
Linux OS
Datacenter Site
Controller cluster DC Gateway switches
A Disaggregated Solution
Northbound API
21. SDN-IP implementated as an ONOS App
Proactive Flow
Installer
Prepopulate flows
based on BGP
updates
ZebOS
BGPd
RIB
RIB
pusher
External BGP
peers
Prefix, Nexthop,
Attributes
BGP Route
RIB
RIB
Syncer
ONOS
Path
Computation
Discovery
Openflo
w
22. REANNZ Deployment
eth0
(management
interface)
SDN-IP + ONOS (VM)
Pronto 3780
DPID 0x01
eth1
192.168.1.10/2
4
eth0
192.168.1.2/24
Pronto 3290
DPID 0x02
eth0
192.168.1.3/24
eth2
1
WIX
Route
servers
202.7.0.2
202.7.0.3
2
202.7.0.119/2348
45
REANNZ
PROD
192.188.37.1
0
REANNZ
CORP
163.7.136.2
46
163.7.136.1/30
47
192.188.37.9/30
Control plane
Data plane
To REANNZ CORP
Demonstrate that Openflow/SDN can peer with production IP networks
Scale: 20K routes (100K routes future)
OpenFlow 1.0 (OpenFlow 1.3 future)
23. Central TE Server
Open Compute Switch
OpenFlow Agent
SDN apps: TE, Routing, Flow
OpenFlow
Linux OS
Commodity Server
Linux OS
Datacenter Site
Controller cluster DC Gateway switches
OpenFlow Driver
Northbound API
SDN Controller
24. OpenFlow Drivers
Extensive support for OF 1.0
Current OpenFlow standard: 1.3.2
Software switches:
Openvswitch: experimental support for 1.1, 1.2, 1.3
LINC: OF 1.2, 1.3, written in Erlang
Indigo virtual switch: OF 1.0 + extensions + ??
Controllers:
Ryu: OF 1.0, 1.2, 1.3
Hardware switches:
Some claim OF 1.3 support
25. OpenFlow 1.3 Driver Competition
Run by ONF
Demonstrate compliance
with OpenFlow 1.3.1
Bindings to
C/C++, Java, Python, Ruby
Integrate into controller and
OpenFlow switch agent
Winning entry will be licensed
under Apache 2.0 and GPL
26. Central TE Server
Open Compute Switch
OpenFlow AgentSDN Controller
SDN apps: TE, Routing, Flow
OpenFlow
Linux OS
Commodity Server
Linux OS
Datacenter Site
Controller cluster DC Gateway switches
Open Compute Switch
Northbound API
27. Open Compute Switch
Run by Open Compute Project
Specification and reference box for a top-of-rack or edge switch
Fit in 19” telco rack and Open Rack, Depth 24-26”. Height 1-2RU
2 AC PSU choices: 80VAC – 240VAC, 200-305VAC
2 DC PSU choices: 48VDC, isolated 12V to 12V
Front to back airflow
Power: TBD
Management processor: ARM, IPMI support (temp, fan speed, reset)
Control processor: PowerPC, x86 (AMD, Intel)
Ports:
48-port 10G (SFP+, Cu below 10G) + 4x40G or 1x100G uplink
Software:
ONIE boot to any OS
SDK to switching ASIC: needed for OpenFlow agent
29. Open Compute Switch
OpenFlow AgentSDN Controller
SDN apps
OpenFlow
Linux OS
Commodity Server
Linux OS
Site (DC, Campus, POP)
Controller cluster
The Road Ahead
Northbound API
OpenFlow Switch
Notes de l'éditeur
Two of them have to do with logical centralization of the control plane and design of Network OS. Number 1, will the Network OS become a performance bottleneck? Or can we scale the Network OS horizontally as we need more horse power? Number 2, will the Network OS become a single point of failure? Or can we make the Network OS and the control plane fault tolerant? The third question has to do with Northbound API. What is the best abstraction the Network OS can offer to application writers that enables reusable and pluggable network control and management applications? ONOS attempts to address exactly these issues…