WIXLIB

OpenDaylightCurrent and Future Use CasesAbhijit KumbhareOpenDaylight Technical Steering Committee (TSC) ChairPrincipal Architect / System Manager, Ericsson

Agenda› OpenDaylight Overview and Architecture› OpenDaylight Use Cases (Partial List)I.II.III.IV.V.Network AbstractionONAPAI/ML with OpenDaylightNetwork VirtualizationODL in OSS› OpenDaylight: Getting Involved› Acknowledgements› Q&A

OpenDaylight Overview and Architecture

A month ago Dinner Discussion with Phil Robb,VP of Operations, Networking &orchestration, Linux Foundation atthe ONS Europe– Topic: our first OpenDaylight Meetings November 2012Nostalgic post by Dave Meyer, first ODL TSC chair on Facebookabout first release Hydrogen in Jan 2014

Realization: We’re a bit old › As far as open sourcecommunities go – 6 years islike 60 dog years!!!› But Code: To create a robust,extensible, open source codebase that covers the majorcommon components requiredto buildgreat!!an SDN solution andthat’screate a solid foundation forNetwork FunctionsVirtualization (NFV)– We’ve got old timers Acceptance: To get broadindustry acceptance amongstAND vendors and users Community: To have a thrivingandgrowingtechnical– We’vealwaysbeenadding newcommunity contributing to thedeveloperscode base, using the code incommercial products, andadding value above andaround.

OpenDaylight Now Mature, Open Governance900 ContributorsOver 100 deploymentsMultiple use casesDozens of ODL-based solutionsMature code base – continued robustcontributions even after 5 years Focus on performance, scale and extensibilityhttps://opendaylight.biterg.io/

Service Abstraction Layer Initial SDN controllers– Controller application APIs strongly tied to OpenFlow– Hence applications developed limited to a single southbound protocol OpenDaylight Goal– Decouple the application API from the southbound protocol plugins - be thatOpenflow, NETCONF, OVSDB, PCEP, BGP, SNMP, or whatever. How to achieve the goal?– Use an abstraction layer – or what is called by OpenDaylight as ServiceAbstraction Layer or SAL

API Driven SAL (AD-SAL) Initial attempt at abstraction– API-Driven SAL, for communicating moredirectly with devices, using protocol(s)associated with the specific API.However abstraction difficult to realize inpractice than it was in theorySDN ApplicationAD-SAL AD-SAL became a collection ofindependent and discrete APIs, withone set of APIs for each and everysouthbound protocol AD-SAL was soon deprecated inOpenDaylight.OpenFlowNetConfNetwork Devices

So how to achieve true abstraction? Alternatives––Build a better SAL Take the existing APIs for the differentplugins, and attempt to come up with anAPI abstraction that meets all of theirneedsUse models Implement a model layer within the SALwhich has SDN applications dealing withsoftware models of network devices,rather than directly with the devicesthemselves. This was the approach taken byOpenDaylight – to develop a ModelDriven SAL or the MD-SAL built aroundYang modelsSDN ApplicationAD-SALModelOpenFlowNetConfNetwork Devices

YANG module model1 {Data modeling language that is alsothe preferred configuration languagefor NETCONF protocolnamespace "urn:model1";prefix model1;yang-version 1;revision 2015-04-06 {description "Initial revision";}Further reads:– YANG introductory tutorial– RFC 6020 - YANG - A datamodeling language for NETCONF– RFC 7950 – The YANG 1.1 DataModeling Languagegrouping A {list B {key id;leaf id {type uint32;}leaf D {type uint32;}}}container C {uses A;}}

What can YANG model? Data–– Config dataOperationalRPCs:– Perform procedure call withinput/output,without worrying about actual providerfor that procedure Notifications:– Publish one or more notifications toregistered listeners

MD-SAL Application Creation Process› Applications built defining models› YANG used for defining models› Compilation results in the skeleton ofapplication: model, RESTCONF API, etc.› Elements in red color above is the appskeleton› The model implementation (green) iswhere you will write code to do whateverit is that your application or the modelwithin your application does

Yangtools – What does Yangtools do? Generates Java code from YangProvides ‘Codecs’ to convert– Generated Java classes to Document ObjectModel (DOM)– DOM to various formats XML JSON Etc Javacodexml‘Codecs’ make possible automatic:– RESTCONF– Netconf– Other bindingsjson

Yang to Java benefits– Consistent Data Transfer Objects(DTOs) everywhere Automated Bindings:– restconf– netconf Consistent:– reduce learning curve Immutable: to avoidthread contention Improvable – generationcan be improved and allDTOs get thoseimprovements immediatelysystem wide

MD-SAL Model-driven SAL is the kernel of the OpenDaylight controller It manages the contracts and state exchanges between every application. It does thisadaptation by managing centralized state Takes in the YANG model at runtime and constructs the tree in the data storeModule model1Namespace “urn:model1”/restconf/config/model1:CCBid 1Leaf DVal 9Bid 2Bid 3Leaf DLeaf DVal 16Val 2/restconf/config/model1:C/B/3

OpenDaylight Architecture - Simplified ViewControllers ina ClusterApp/ServiceApp/ServiceModel-Driven ServiceAbstraction Layer (MD-SAL)PluginNotificationsDataRPCsPluginYANG Models

An Aspect of the architecture: ODL is a µ-services platformApplicationsApplicationsOSS/BSS,External onModel-Driven es“Kernel”Data StoreNamespace

OpenDaylight Architecture - Operational ViewThird Party Applications (Orchestration, Control Plane, UI, etc.)OpenDaylight APIsPlatform ServicesNetwork Services And ApplicationsApplication(Processing)APIData Store (Config & Operational)OpenDaylight PlatformMessaging (Notifications / RPCs)APIProtocolPluginModelInterfaces & Protocol PluginsData Plane Elements (Virtual Switches, Physical Devices)Model

OpenDaylight Fluorine ReleaseOrchestration ApplicationsControl Plane ApplicationsOther Applications (e.g. Vendor UI)OpenDaylight APIs (REST/RESTCONF/NETCONF)Northbound APINetwork Services And ApplicationsPlatform Services Authentication, Authorization and Accounting Container Orchestration Engine Neutron Service Data Export Import Genius Framework Service Function Chaining Infrastructure Utilities Honeycomb/Virtual Bridge Domain Transport PCE* JSON-RPC Extension LISP Flow Mapping Service Unified Secure Channel Manager ** Time Series Data Repository NEMO ** User Network Interface Manager Network VirtualizationData Store (Config & Operational)BGPBMPThird Party AppsOpenDaylight Platform (Yangtools, MD-SAL)LISPNETCONFOpenFlowOVSDBPCEPMessaging (Notifications / mSouthbound Interfaces &Protocol PluginsData Plane Elements(Virtual Switches, PhysicalDevice Interfaces)* First release for the project** Not included in Fluorine distribution - separate download

OpenDaylight Architecture: Key Takeaway OpenDaylight architecture is amenable to be applied to avariety of use cases as:– Not tied to a particular protocol– Modular, Extensible– Has built-in tools to simplify application development

OpenDaylight Use Cases (Partial List)

NoteOpenDaylight architecture has been used in many use cases –not all covered here

Use Case INetwork AbstractionOrchestration/OSS/Cloud pluginNetwork Services API(Path, Tunnel, L2/L3/L4 Service, Service Assurance, etc)OpenDaylightManagement Interfaces(Netconf, REST, OVSDB)Control Interfaces(OpenFlow, BGP, PCEP)White BoxDeviceTraditionalNetwork deviceProvides Network ServicesAPI for NetworkAutomationin a Multi Vendor Network

Use Case IIONAP ProjectSDN-C & App-C based onOpenDaylight code

Use Case III (future)AI/ML with OpenDaylightSmart SDN Controller Network status awareness Rely on time series datacollected from the networkAdvanced Analytics& Machine LearningAutomated TrafficControlTime Series DataCollection Traffic Control Policy Changedecision making Based on the advanced analyticsand machine learning. Dynamic change of Control policies Automatically change the trafficcontrol policies based on theanalytics results.

Why we need Machine Learning in SDN Software Defined Networks needs to be intelligent.– To be aware of the runtime status of the network.– To make the right decisions that adjust the policies for trafficclassification and traffic shaping.– To dynamically change the policies according to the analyticsresults. AI / MI can be used to establish normalized profiles anddynamically update the profiles based on a set ofpredetermined or dynamically learned rules.

Use Cases of a smart and intelligent SDN controller Traffic Control and RoutingOptimization– Congestion Control– Traffic Pattern Prediction– Routing Optimization Resource optimization– Networking resource allocationoptimization– Cloud resource managementoptimization Security and Anomaly Detection– DDoS attack detection andmitigation Troubleshooting and Selfhealing

AI/ML Example Use CaseTraffic congestion prediction with automated control

ODL AI/ML framework in the ODL ecosystem Enable AI/ML on both historicaland real-time data paths. Many use cases would requireboth offline and online ML onthe time series data. External events could beadditional input for accuratemachine learning results. Feed back the results to SDNcontrol path for automatic trafficsteering and policy placement. Well-defined interface amongthe components towards futurestandardization of advancedanalytics in SDN.

ODL AI/ML framework PoC Architecture PoC of both historicaloffline machine learningand real-time onlinemachine learning Collect the time seriesdata Persist into scalable datastorage Publish to highperformance data bus Integrate with externalmachine learning libraries Spark MLlib DeepLearning4J Future: TensorFlow? Collect OpenFlow Statsand apply machinelearning algorithms k-means clustering

Prediction using Weka leveraging data collected in TSDR

Use Case IVNetwork Virtualization A set of projects working in tandem to provide network virtualization(overlay connectivity) inside and between data centers for Cloud SDNuse case– VxLAN within the data center– L3 VPN across data centers Integration with OpenStack Neutron and Kubernetes (in-progress)Uses Open vSwitch and hardware VTEPs (ToR) as the datapath

Network Virtualization: OpenDaylight ComponentsODLOpenDaylight NB APIs (REST)OF NSFsNetwork NSFsNetVirt ServicesGENIUSMP-BGP InterfaceELAN ServiceNeutron NBForwardingRules MgrL2GW HandlerVPN gerLivenessManagerMD-SAL datastoreQoS ServiceNAT ServiceIPv6 control serviceODL NetvirtODL PlatformClusteringDHCP ServiceNotification brokerModel-Driven service abstraction layer ( MD-SAL) (plug-in mgr., capability abstractions, )ODL GENIUSLock ManagerYANG toolsAAALegendID ManagerACL serviceFIB ManagerOF 1.3InterfaceManagerOVSDBODL InfrastructureHWVTEPMisc ServicesExternal moduleDAEXIMBGP Protocol Engine(Quagga)

A common controller platformOne Application / ServiceContainerized Network FunctionsVirtual Network ginUniform dware AppliancesReduced trainingAnd gFabric NMSOVSDBCommondashboard

OpenDaylight multi-instance controllerContainerized applications on per tenant hosted K8sCNFOpenstack VM’sVNFVNFVNFCNFTenant K8s(VM’s)Kuryr CNICNFCNFTenant K8s(VM’s)Kuryr CNICNFCNFTenant K8s(VM’s)Kuryr CNICNF on bare metal K8’sNeutron Opendaylight driverCNFCNFOpenstack (containerized)OpenDaylight CNIInfra Kubernetes (bare metal)CNF

OpenDaylight Container Orchestration Engine Current Status– Hybrid scenario: Openstack and Kubernetes side by side–Integration with ODL via Openstack Kuryr––Supports Multinode environmentSupports container in a VM scenario– Baremetal scenario Kubernetes only––Tight integration with ODL NetVirtSupports Pod 2 Pod networking L2/L3 Future Scenarios Support for non-OFsouthbound NetConf Testing with L3VPN for multitenant scenarios Scale testing & improvement