Colin Dixon Technical Steering Committee Chair OpenDaylight Senior Principal Engineer Brocade Some content from David Meyer Neela Jaques and Kevin Woods Outline State of networking and SDN ID: 394829
Download Presentation The PPT/PDF document "OpenDaylight and the Rise of Open Source..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
OpenDaylight and the Rise of Open Source, Software Networking
Colin Dixon
Technical Steering Committee Chair,
OpenDaylight
Senior Principal
Engineer,
Brocade
Some content from: David Meyer,
Neela
Jaques
, and Kevin
WoodsSlide2
Outline
State of networking and SDN
Overview of open source (networking)
Introduction to OpenDaylight
Who’s using OpenDaylight and for what
Open Research QuestionsSlide3
Networks have not adapted to demands
Last 20 years
radically shifting network demands
massively increased scale (# of endpoints, switches, bytes, flows, etc.)
static endpoints (weeks–months)
dynamic endpoints (hours–days)
mostly north-south traffic
mostly east-west traffic
By contrast, networks haven’t changed much
Link speeds have gone up, but…
Still largely manage networks device-by-device via the CLI
If you’re lucky, orchestration at the granularity of a few
devicesSlide4
Things need to change
Device-by-device
Network-wide
Open Standards Open Standards + Open Source
Proprietary Software Open Source
Networking, Storage, Compute Converged IT
Hardware Software
To a large extent,
this is the rise of open source
networkingSlide5
dst
port
0E
6
dst
port
0E
6
0A
1
dstport0E60A10C4
Traditional SDN (OpenFlow)The separation of the control and data planes
Modern switchesControl/data plane both on switchData plane: fast, reads tablesControl plane: slow, writes tablesSDNDecouple control/data planesData plane on the switchControl plane elsewhere, e.g., an x86 server, can do fancier things
Switch Chip
Control Plane CPU
Ports, 1-6
SDN Controller
This gets smaller, turns into controller to switch chip translator
Most features
go here
0A->0E
0A->0E
0A->0C
Table miss, send to controller
Install table entry, send packet
0C-
>
4Slide6
Disaggregation & Open Source Software
Modern
, Inclusive SDN
control
mgmt
control
mgmt
control
mgmt
Vendor A
Vendor B
Vendor C
Logically
Centralized
SDN Controller
Northbound API
Industry Standard
Control/Management Protocols
Standard
Modeling
Language
Device-by-device operation
Proprietary, vendor-specific vertical stacks for control, management and orchestration
Limited innovation in individual silos
Network-wide operation
Open control, management and orchestration using
open control protocols
/modeling
langs
Independent innovation at each layer of the
stack
Vendor A
control
mgmt
control
mgmt
Vendor B
Vendor C
control
mgmtSlide7
Open SourceSlide8
Open Source Projects of Note
OpenStack
:
IT-wide orch. (Neutron for networks)
[orchestration]
OpenDaylight:
industry-wide SDN controller
[control/
mgmt plane]Open vSwitch: programmable s/w in the Linux kernel [data plane]Many, many others: Open Network Linux, ONOS, CloudRouter, Quagga, OVN, ONIE, Open Compute, Prescriptive Topology Manager, SocketPlane, Weave, Akanda, MidoNet,
OpenContrail
http://www.jedelman.com/home/open-source-networkingSlide9
Why Open Source?
Avoid
vendor lock-in
Have a seat at the
table
Faster Innovation
Interop
& Integration
9You’ll note I didn’t say cost
build itbuy it
open sourcecostease of use
f
lexibilityMy Thesis: This is reallymore
important than the
SDN technology itselfSlide10
Defining “Open” in Open Source
10
http://www.opendaylight.org/blogs/2014/03/degrees-open
http://www.networkcomputing.com/50-shades-of-open-sdn/a/d-id/1234771
Who can contribute?
Who does contribute?
How are decisions made? W
ho
can
comment? Who can vote?What license does it use?
As about ProjectsDoes it integrate with other solutions from other vendors?Does it have an API?Does it follow open standards?Is it based on open source components?
Does it upstream to open source
projects?Ask about Products
“Simply stated,
OpenDaylight
is as open as open gets.”Slide11
Open Source vs. Open Standards
Open Standards
define
interfaces well
in human-readable documents
define behavior with some ambiguity
usually move slowly
leave interoperability testing to others, e.g., users, integrators
sometimes provide open source implementationsOpen Sourcedefine interfaces wellin codedefine behavior in code so it can be tested and understoodmove and adapt quicklycan do interoperability testing as part of development
often implement open standardsSlide12
Open Source Opportunities
SDN in production is now using the same tools that researchers and academics can use
Same is Linux and other examples
Potential for significant real-world impact
Also lots of challenges
Real code means real complexity
Navigating getting code accepted “upstream” is hard
Sustained contributions work better, but are higher costSlide13
OpenDaylightSlide14
What is OpenDaylight
OpenDaylight is an
Open Source Software
project under the
Linux Foundation
with the goal of furthering the adoption and innovation of
Software Defined Networking (SDN)
through the creation of a common industry supported platform
.
To create a robust, extensible, open source code base that covers the major common components required to build an SDN solutionCodeTo get broad industry acceptance amongst vendors and
users:• Using it directly or through vendor products• Vendors using OpenDaylight
in commercial products
AcceptanceTo have a thriving and growing technical community contributing to the code base, using the code in commercial products, and adding value above, below and around.
CommunitySlide15
OpenDaylight Releases
Hydrogen
(first release)
February 2014
13 projects,
1.3m
lines of
code
Helium (second release)October 201425 projects, 2.1m lines of codeLithium (latest release)June 201540+ projects, 2.3m lines of codeSlide16
Model-Driven Service
Abstraction Layer (MD-SAL)
Core Architecture
Notifications
RPCs
YANG Models
Data
App/Service
App/Service
Plugin
Plugin
Controllers in a ClusterSlide17
OpenDaylight Lithium ArchitectureSlide18
OpenDaylight CommunitySlide19
OpenDaylight Community
Like any Open Source Project,
OpenDaylight
primarily consists of those who show up to do the work
.
Running
around
250 commits
per week over 12 months, trending up30 Days: ~625 commits, ~100 contributors (7/13/15–8
/12/15; during a release)Spikes to ~2x this near releases12 Months: ~13,250 commits, ~365 contributors (8/12/14–8/12/15)Strong integration and testing communityThis stuff really matters
Source:
https://www.openhub.net/p/opendaylightSlide20
What do people use it for?Slide21
Who’s using OpenDaylight and Why
Survey Respondents
31%
Telcos
/Service Providers
24% Research/Academia
20% Enterprises
10% Services/Consulting
9% Software/Hardware
6% OtherSlide22
In Production
AT&T
Telstra
CERN/LHC
TencentSlide23
Network Virtualization
Single
OpenStack
Neutron service proxy
Handles most of the bookkeeping
Choose your implementation
Group-based Policy
LISP
OVSDBVPN Service (only for VPNaaS)VTNCheck it out (see the links for instructions)
http://
www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.htmlhttp://www.flaviof.com/blog/work/how-to-odl-with-openstack-part2.html
http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part3.htmlhttp://go.linuxfoundation.org
/l/6342/2015-06-29/2lgcdr/6342/128166/openstack_20150629.pdfSlide24
Network-wide Security Policy
Historically, policy is mostly
Rigidly enforced by the physical topology, e.g., firewall at the gateway
Configured “dynamically” via box-by-box Access Control Lists (ACLs)
New policy efforts are changing this
Network Function Virtualization (NFV) and Service Function Chaining (SFC)
Automatically generated ACLs based on network-wide policy
OpenDaylight is a proving ground for at least 3 policy-oriented projects
Service Function Chaining, Group-Based Policy, and Network Intent CompositionSlide25
Programmable EMS and/or NMS
Huge number of southbound protocol drivers
OpenFlow
, NETCONF, OVSDB, SNMP, BGP, PCEP, PCMM/COPS, etc.
With a little bit of effort, you can write “shell scripts” for your network to either gather information or automate tasks
Automate triggering activities based on network events, e.g., quarantine a host with L2 ACLs based on information from an IDSSlide26
Analysts See Momentum
26
“OpenDaylight is quickly evolving into something formidable with good potential for mainstream relevancy.”
–
Andrew Lerner,
Gartner
“OpenDaylight may be the third center of gravity”
–
Andrew Lerner, Gartner
An open source approach to software-defined networking (SDN) moved several steps closer this week to becoming a de facto standard.
– Mike
Vizard, IT Business Edge
“OpenDaylight has become the Linux of network stacks: the foundation upon which both network vendors and users build the next generation of products and services.
” – Kurt Marko, ForbesSlide27
Ways to get involved
IRC:
#
opendaylight
on
freenode
:
http://webchat.freenode.net/Mailing lists: http://lists.opendaylight.org/Wiki: http://wiki.opendaylight.org/Documentation:
https://www.opendaylight.org/downloadsOn github: https://github.com/opendaylight/docs/Git/Gerrit: http://git.opendaylight.org/Create an account: https://identity.opendaylight.org/carbon/user-registration/user-registration.jspProjects: https://wiki.opendaylight.org/view/Project_listIndividual pages have links to meeting times, code, bugs, IRC channels, etc.Meetings:
https://wiki.opendaylight.org/view/MeetingsSlide28
Open Research QuestionsSlide29
How to get there from here
How do we deploy SDN when it’s not green field
Because pretty much nothing is actually green field
Hybrid switches, hybrid networks, legacy protocols for interoperability, etc.
OpenDaylight supports
SNMP, BGP, LISP,
NETCONF, etc.
Trust and stability
Current networks build on 40 years of code/experienceHow can SDN compete with that?Borrow good code/ideas from legacy codeProvide better visibility, debugging, etc.Model checking, verification, etc.
29Slide30
Centralized vs. Distributed
(Consistency, Clustering and Federation)
SDN promises a (logically) centralized control plane
In practice, we have a distributed cluster of
controllers, rather than just one so that
we can tolerate faults
we
can scale out our
performancein network partitions there are controllers on both sidesProviding consistency, federation, scale-out, dealing with CAP trade-offs, etc. is HARD
http://events.linuxfoundation.org/sites/events/files/slides/sdn-consistency-ods2014.pdf
https://www.youtube.com/watch?v=XQ-lnB3x30gSlide31
Hardware Diversity
OpenFlow
1.0 provided a lowest common denominator API
Real hardware is much more diverse
and has many more capabilities
Exposing this diversity without burdening developers with per-device programming is hard
Some Attempts
P4: Programming
Protocol-Independent Packet ProcessorsTTPs from the ONF’s FAWGProtocol Oblivious Forwarding (Huawei)
31
https://www.youtube.com/watch?v=bcaBS6w_k_ohttp://events.linuxfoundation.org/sites/events/files/slides/TTPs%20and%20NBIs%20for%20ods2014-final_0.pdfhttp://arxiv.org/pdf/1312.1719v1.pdf
This is really about providing
portable abstractionsSlide32
Application Composition
How can we let multiple SDN apps share the network?
PC
OSes
partition and allocate resources
You can’t easily partition the network
It’s value comes from the fact that it spans everything
You can in some cases, e.g., by address space (
FlowVisor)Some ideasMost apps should be middleboxes, i.e., NFVSimply chain them together in the right orderThere’s more to it than this, but linear chaining is powerfulOther apps are concerned only with the physical pathThere is hope that conflicts here can be sanely managed
32