Tom Nadeau - SDN & Open Daylight

© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION

Tom NadeauChief Architect, Open SourceDistinguished Engineer, BrocadeSome content from: Colin Dixon, David Meyer, Neela Jaques, and Kevin Woods

A Brief Introduction to SDN and OpenDaylight

Traditional SDN (OpenFlow)The separation of the control and data planes

• Modern switches– Control/data plane both on switch– Data plane: fast, reads tables– Control plane: slow, writes tables

• SDN– Decouple control/data planes– Data plane on the switch– Control plane elsewhere, e.g., an

x86 server, can do fancier things

© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 2

dst port0E 6dst port0E 60A 1

dst port0E 60A 10C 4

Ports, 1-6

SDN Controller

This gets smaller, turns into

controller to switch chip

translator

Most featuresgo here Table miss,

send to controller

Install table entry, send

packet

0C->4

Switch Chip

Control Plane CPU

0A->0E0A->0E0A->0C

Modern, Inclusive SDN


LogicallyCentralized

SDN Controller

Northbound API

Industry StandardControl/Management Protocols

• Network-wide operation• Open control, management and

orchestration using open control protocols/modeling langs

• Independent innovation at each layer of the stack

• Device-by-device operation• Proprietary, vendor-specific vertical stacks

for control, management and orchestration• Limited innovation in individual silos

control

mgmt

Vendor A Vendor B

control

mgmt

Vendor C

control

mgmt

Vendor A

control

mgmt

Vendor B

control

mgmt

Vendor C

control

mgmtStandardModelingLanguage

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 solution

Code

To get broad industry acceptance amongst vendors and users:• Using it directly or through

vendor products• Vendors using OpenDaylight

in commercial products

Acceptance

To 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.

Community

OpenDaylight Releases

Hydrogen (first release)

February 201413 projects, 1.3m lines of code


LiHeH

Helium (most recent release)

October 201425 projects, 2.1m lines of code

Lithium (upcoming release)

Planned June 201540+ projects, 2.3m lines of code

OpenDaylight


Base Network Service Functions

VTN Coordinator

DDoS Protection

SDNIWrapper

DLUX Web-based GUI

Custom Basic AuthN Filter AAA AuthN Filter Neutron AuthN

AD-SAL REST APIs MD-SAL RESTCONF (REST) APIs Neutron APIs

Topology Manager

Stats Manager

Switch Manager

Host Tracker

OpenStack(via Neutron)

OpenStack Neutron Service

OVSDB VTN Plugin2OC

Model-Driven Service Abstraction Layer (MD-SAL)API-Driven Service Abstraction Layer (AD-SAL) Clustering

Fwdng Rules Mgr

DOCSIS Service

LISPService

SDNI Aggregator

GBPService

Service Flow Chaining

L2Switch

SNBIOVSDB SNMP BGP PCEP NETCONF Plugin2OCOpenFlowPCMM/COPS LISP 1.0 1.3 TTP

OpenFlow1.0

Shared Data Models

RPCs and Notifications

AAA: Authentication, Authorization & AccountingAuthN: AuthenticationBGP: Border Gateway ProtocolCOPS: Common Open Policy ServiceDLUX: OpenDaylight User ExperienceDDoS: Distributed Denial Of Service

DOCSIS: Data Over Cable Service Interface SpecificationGBP: Group Based PolicyLISP: Locator/Identifier Separation ProtocolOVSDB: Open vSwitch DataBase ProtocolPCEP: Path Computation Element Communication ProtocolPCMM: Packet Cable MultiMedia

Plugin2OC: Plugin To OpenContrailSDNI: SDN Interface (Cross-Controller Federation)SNBI: Secure Network Bootstrapping InfrastructureSNMP: Simple Network Management ProtocolTTP: Table Type PatternsVTN: Virtual Tenant Network“Helium”

Core service wiring and dependencies

App/service-specific wiring and dependencies

Abstraction Layers

Controller Platform and Services

Southbound Interfaces and Protocol Plugins

Northbound/RESTAPIs

Authentication

Applications and Orchestration

ServicesLegend

Model-Driven Service Abstraction Layer (MD-SAL)

Core Architecture


Notifications

RPCsData

App/Service App/Service

Plugin Plugin

YANG Models

Controllers in a Cluster

Yang Models

Network TopologyList of NodesList of LinksLinks and Nodes can be “augmented” later

Can have multiple topologiesOverlay/underlayDisjointPeered


container network-topology {

...

list node {

description "...";

key "node-id";

uses node-attributes;

}

list link {

description "...";

key "link-id";

uses link-attributes;

}

}

Who Is OpenDaylight?

© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 9HTTPS://WWW.OPENHUB.NET/P/OPENDAYLIGHT

SILVERPLATINUM

GOLD

Who Is OpenDaylight? (Really)


Who Is OpenDaylight? (Really)

• Like any Open Source Project, OpenDaylight primarily consists of those who show up to do the work.

• Running around 300 commits per week over 12 months, trending up– 30 Days: ~3200 commits, ~150 contributors

(4/1/15–5/1/15; during a release)– 12 Months: ~16,000 commits, ~325 contributors

(5/1/14–5/1/15)

• Strong integration and testing community– This stuff really matters

© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 11SOURCE: HTTPS://WWW.OPENHUB.NET/P/OPENDAYLIGHT

Why Open Source?

• Avoid vendor lock-in

© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 12HTTPS://18F.GSA.GOV/2014/11/26/HOW-TO-USE-MORE-OPEN-SOURCE/

“It's important that every Federal CIO, CTO, Architect, and Program Manager seeking to build or procure new IT projects understand that open source exists, that it can be of high quality and highly reusable, and how to use it securely.”

• Have a seat at the table

• Faster innovation

• Easier integration

Security

• In general, open source is considered to be more secure than closed source software– “Given enough eyeballs, all bugs

are shallow” –Linus• Very strong security response process

– Fixed critical vulnerabilities and shipped a new release in <4 days

• Device/user interfaces can be secured– OF over SSL, NETCONF over SSH, RESTCONF over HTTPS w/auth

• Starting with Lithium, releases will be cryptographically signed



Great!What Can I Do with It?

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 Composition

OpenDaylight

OpenStack Neutron

OpenStack Neutron Integration


• OpenDaylight has a common Neutron “northbound” provider– 3 implementations in Helium– 4+ planned in Lithium

• Supports network virt. and– Distributed L3 forwarding– Security Groups– {LB,VPN}aaS

OpenContrailProvider

VTN Provider

Neutron Service

OVSDBProvider

Neutron ML2 MechanismDriver

OpenDaylight APIs (REST)

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 IDS


How Can I Get It?

• OpenDaylight: http://www.opendaylight.org/software/downloads

• Also commercialized, supported versions from– Brocade, Ciena, Cisco, Inocybe, and others– Understand the difference between “uses” and “based on” OpenDaylight– Policy on “upstreaming” changes and compatibility with other products

• The Brocade Vyatta Controller is based on unmodified OpenDaylight and upstreams all changes to OpenDaylight– Get it here: https://tinyurl.com/BrcdVytaCntrlr


SDN Grand Challenges


Centralized vs. Distributed

Migration to SDN

Application Composition

Hardware Diversity

• RAFT distributed consensus algorithm in Helium

• Continued work on clustering in Lithium and beyond

• Support SNMP, BGP, LISP, NETCONF “legacy” protocols

• Support for declarative, intent-based policy

• Unified models for inventory, topology, and more

• Support for Table Type Patterns

• Device Driver Framework will provide adaptation in Lithium

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/experience– How can SDN compete

with that?• Borrow good code/ideas from

legacy code• Provide better visibility, debugging, etc.• Model checking, verification, etc.

SDN Is Here; It’s Time to Use It


• SDN-based architectures can rapidly deliver new features even in multi-vendor networks• OpenDaylight is a broadly-supported open

source SDN controller• Commercialized versions are available and

production ready with support


Thank you


Backup Slides

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 performance– in network partitions there are controllers on both sides

• Providing consistency, federation, scale-out, dealing with CAP trade-offs, etc. is HARD

HTTP: / / EVENTS. LI NUXFO UNDATI O N. O RG / SI TES/ EVENTS/ FI LES/ SLI D ES/ SD N- CO NSI S TEN CY- O DS2 014. PDF

HTTPS: / / WWW. YO UTUBE. CO M / WATCH?V=XQ - LNB3X30G © 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION 24

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– Programming Protocol-Independent Packet Processors– TTPs from the ONF’s FAWG


HTTPS: / / WWW. YO UTUBE. CO M / WATCH?V=BCABS6W_K_O

HTTP: / / EVENTS. LI NUXFO UNDATI O N. O RG / SI TES/ EVENTS/ FI LES/ SLI D ES/ TTP S%20A ND%20 NBI S%20FO R%20O D S2014- FI NAL _0. PDF

HTTP: / / ARXI V. O RG / PDF/ 1312. 1719V1. PDF

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 ideas– Most apps should be middleboxes, i.e., NFV• Simply chain them together in the right order• There’s more to it than this, but linear chaining is powerful

– Other apps are concerned only with the physical path• There is hope that conflicts here can be sanely managed


Tom Nadeau - SDN & Open Daylight

Government & Nonprofit

Transcript of Tom Nadeau - SDN & Open Daylight