Current & Future Use-Cases of OpenDaylight
- 1. OpenDaylight Current and Future Use Cases Abhijit Kumbhare OpenDaylight Technical Steering Committee (TSC) Chair Principal Architect / System Manager, Ericsson
- 2. Agenda • OpenDaylight Overview and Architecture • OpenDaylight Use Cases (Partial List) I. Network Abstraction II. ONAP III. Network Virtualization IV. AI/ML with OpenDaylight V. ODL in OSS • OpenDaylight: Getting Involved • Acknowledgements • Q & A
- 3. OpenDaylight Overview and Architecture
- 4. Past Two Days … • Dinner Discussion with Phil Robb, VP of Operations, Networking & orchestration, Linux Foundation • Topic: our first OpenDaylight Meetings • November 2012 Nostalgic post by Dave Meyer, first ODL TSC chair on Facebook about first release Hydrogen in Jan 2014
- 5. Realization: We’re a bit old … • As far as open source communities go – 6 years is like 60 dog years!!! • But that’s great!! • We’ve got old timers AND • We’ve always been adding new developers
- 6. OpenDaylight Project Goals • Code: To create a robust, extensible, open source code base that covers the major common components required to build an SDN solution and create a solid foundation for Network Functions Virtualization (NFV) • Acceptance: To get broad industry acceptance amongst vendors and users • Community: To have a thriving and growing technical community contributing to the code base, using the code in commercial products, and adding value above and around.
- 7. OpenDaylight Now • Mature, Open Governance • 900 Contributors • Over 100 deployments • Multiple use cases • Dozens of ODL-based solutions • Mature code base – continued robust contributions even after 5+ years • Focus on performance, scale and extensibility https://opendaylight.biterg.io/
- 8. 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 that Openflow, NETCONF, OVSDB, PCEP, BGP, SNMP, or whatever. • How to achieve the goal? • Use an abstraction layer – or what is called by OpenDaylight as Service Abstraction Layer or SAL
- 9. API Driven SAL (AD-SAL) • Initial attempt at abstraction • API-Driven SAL, for communicating more directly with devices, using protocol(s) associated with the specific API. • However abstraction difficult to realize in practice than it was in theory • AD-SAL became a collection of independent and discrete APIs, with one set of APIs for each and every southbound protocol • AD-SAL was soon deprecated in OpenDaylight. SDN Application AD-SAL OpenFlow NetConf Network Devices
- 10. Model So how to achieve true abstraction? • Alternatives • Build a better SAL • Take the existing APIs for the different plugins, and attempt to come up with an API abstraction that meets all of their needs • Use models • Implement a model layer within the SAL which has SDN applications dealing with software models of network devices, rather than directly with the devices themselves. • This was the approach taken by OpenDaylight – to develop a Model Driven SAL or the MD-SAL built around Yang models SDN Application AD-SAL OpenFlow NetConf Network Devices
- 11. • Data modeling language that is also the preferred configuration language for NETCONF protocol • Further reads: • YANG introductory tutorial • RFC 6020 - YANG - A data modeling language for NETCONF • RFC 7950 – The YANG 1.1 Data Modeling Language YANG module model1 { namespace "urn:model1"; prefix model1; yang-version 1; revision 2015-04-06 { description "Initial revision"; } grouping A { list B { key id; leaf id { type uint32; } leaf D { type uint32; } } } container C { uses A; } }
- 12. • Data • RPCs: • Perform procedure call with input/output, without worrying about actual provider for that procedure • Notifications: • Publish one or more notifications to registered listeners What can YANG model?
- 13. › Applications built defining models › YANG used for defining models › Compilation results in the skeleton of application: model, RESTCONF API, etc. MD-SAL Application Creation Process › Elements in red color above is the app skeleton › The model implementation (green) is where you will write code to do whatever it is that your application or the model within your application does
- 14. • Generates Java code from Yang • Provides ‘Codecs’ to convert • Generated Java classes to Document Object Model (DOM) • DOM to various formats • XML • JSON • Etc • ‘Codecs’ make possible automatic: • RESTCONF • Netconf • Other bindings Yangtools – What does Yangtools do? Java code xml json
- 15. • Consistent Data Transfer Objects (DTOs) everywhere • Automated Bindings: • restconf • netconf • Consistent: reduce learning curve Yang to Java benefits • Immutable: to avoid thread contention • Improvable – generation can be improved and all DTOs get those improvements immediately system wide
- 16. Module model1 Namespace “urn:model1” MD-SAL › Model-driven SAL is the kernel of the OpenDaylight controller › It manages the contracts and state exchanges between every application. It does this adaptation by managing centralized state › Takes in the YANG model at runtime and constructs the tree in the data store C B id=1 Leaf D Val=9 Leaf D Val=16 Leaf D Val=2 B id=2 B id=3 /restconf/config/model1:C /restconf/config/model1:C/B/3
- 17. Model-Driven Service Abstraction Layer (MD-SAL) OpenDaylight Architecture - Simplified View Notifications RPCs YANG Models Data App/ Service App/ Service Plugin Plugin Controllers in a Cluster
- 18. An Aspect of the architecture: ODL is a µ-services platform Model-Driven SAL (MD-SAL) Netconf Client Network DevicesNetwork DevicesNetwork Devices Protocol Plugin ...Netconf Server RESTCONF ApplicationApplication REST ApplicationsApplicationsOSS/BSS, External Apps Data Store Messaging “Kernel” Microservices Namespace YANG-m odeled interfaces YANG-modeled interfaces
- 19. OpenDaylight Platform Data Plane Elements (Virtual Switches, Physical Devices) Interfaces & Protocol Plugins Platform Services OpenDaylight APIs Network Services And Applications Data Store (Config & Operational) OpenDaylight Architecture - Operational View Messaging (Notifications / RPCs) Third Party Applications (Orchestration, Control Plane, UI, etc.) Protocol Plugin Model API Application (Processing) API Model
- 20. OpenDaylight Platform (Yangtools, MD-SAL) OpenDaylight Fluorine Release OVSDBNETCONFLISP PCEP SNMPOpenFlow OpenDaylight APIs (REST/RESTCONF/NETCONF) Data Store (Config & Operational) Messaging (Notifications / RPCs) Orchestration Applications BGP Network Services And ApplicationsPlatform Services • Authentication, Authorization and Accounting • Data Export Import • Infrastructure Utilities • JSON-RPC Extension • Time Series Data Repository • Container Orchestration Engine • Genius Framework • Honeycomb/Virtual Bridge Domain • LISP Flow Mapping Service • NEMO ** • Network Virtualization SXP Southbound Interfaces & Protocol Plugins Controller Services/Applications Northbound API Platform • Neutron Service • Service Function Chaining • Transport PCE* • Unified Secure Channel Manager ** • User Network Interface Manager Third Party AppsControl Plane Applications Other Applications (e.g. Vendor UI) Data Plane Elements (Virtual Switches, Physical Device Interfaces) BMP * First release for the project ** Not included in Fluorine distribution - separate download
- 21. OpenDaylight Architecture: Key Takeaway • OpenDaylight architecture is amenable to be applied to a variety of use cases as: • Not tied to a particular protocol • Modular, Extensible • Has built-in tools to simplify application development
- 22. OpenDaylight Use Cases (Partial List)
- 23. Note • OpenDaylight architecture has been used in many use cases – not all covered here
- 24. Use Case I Network Abstraction Management Interfaces (Netconf, REST, OVSDB) White Box Device Traditional Network device Control Interfaces (OpenFlow, BGP, PCEP) OpenDaylight Orchestration/OSS/Cloud plugin Network Services API (Path, Tunnel, L2/L3/L4 Service, Service Assurance, etc) Provides Network Services API for Network Automation in a Multi Vendor Network
- 25. Use Case II ONAP Project SDN-C & App-C based on OpenDaylight code
- 26. Use Case III Network Virtualization • A set of projects working in tandem to provide network virtualization (overlay connectivity) inside and between data centers for Cloud SDN use 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
- 27. Network Virtualization: OpenDaylight Components OF NSFs ELAN Service OpenDaylight NB APIs (REST) OVSDB Model-Driven service abstraction layer ( MD-SAL) (plug-in mgr., capability abstractions, …) Forwarding Rules Mgr ODL Platform Neutron NB Network NSFs FIB Manager VPN Mgr NetVirt Services BGP Protocol Engine (Quagga) MP-BGP Interface HWVTEP Notification broker YANG tools MD-SAL datastore ODL InfrastructureLegend ODL Netvirt External module Internal Transport Manager ID Manager Interface Manager Lock Manager Liveness Manager GENIUS ACL service DHCP Service NAT Service IPv6 control service L2GW Handler ODL GENIUS OF 1.3 ODL Clustering Inventory Mgr Cardinal (SNMP) AAA Misc Services DAEXIM QoS Service
- 28. One Application / Service Interconnect Interconnect Acommoncontrollerplatform Virtual Network Functions Hardware AppliancesContainerized Network Functions DCGW Fabric Fabric NMSCNI Neutron Plugin Plugin BGPVPN EVPN OVSDB Uniform service capabilities Common dashboard Simplified troubleshooting Simplified interworking Reduced training And validation
- 29. Infra Kubernetes (bare metal) Openstack (containerized) VNF VNF VNF CNF CNF CNF OpenDaylightmulti-instancecontroller CNF CNF Tenant K8s (VM’s) Tenant K8s (VM’s) Tenant K8s (VM’s) Kuryr CNI CNF CNF CNF CNF Neutron Opendaylight driver OpenDaylight CNI Openstack VM’s Containerized applications on per tenant hosted K8s CNF on bare metal K8’s Kuryr CNI Kuryr CNI
- 30. OpenDaylight Container Orchestration Engine • Current Status • Hybrid scenario: • Openstack and Kubernetes side by side • Integration with ODL via Openstack Kuryr • Supports Multinode environment • Supports container in a VM scenario • Baremetal scenario • Kubernetes only • Tight integration with ODL NetVirt • Supports Pod 2 Pod networking L2/L3 • Future Scenarios • Support for non-OF southbound • NetConf • Testing with L3VPN for multi- tenant scenarios • Scale testing & improvement
- 31. Use Case IV (future) AI/ML with OpenDaylight Smart SDN Controller • Network status awareness Ø Rely on time series data collected from the network • Traffic Control Policy Change decision making Ø Based on the advanced analytics and machine learning. • Dynamic change of Control policies Ø Automatically change the traffic control policies based on the analytics results. Time Series Data Collection Advanced Analytics & Machine Learning Automated Traffic Control
- 32. 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 traffic classification and traffic shaping. • To dynamically change the policies according to the analytics results. • AI / MI can be used to establish normalized profiles and dynamically update the profiles based on a set of predetermined or dynamically learned rules.
- 33. Ø Traffic Control and Routing Optimization • Congestion Control • Traffic Pattern Prediction • Routing Optimization ØResource optimization • Networking resource allocation optimization • Cloud resource management optimization Use Cases of a smart and intelligent SDN controller ØSecurity and Anomaly Detection • DDoS attack detection and mitigation Ø Troubleshooting and Self-healing
- 34. AI/ML Example Use Case – Traffic congestion prediction with automated control
- 35. Prediction using Weka leveraging data collected in TSDR
- 36. ODL AI/MLframeworkintheODLecosystem • Enable AI/ML on both historical and real-time data paths. • Many use cases would require both offline and online ML on the time series data. • External events could be additional input for accurate machine learning results. • Feed back the results to SDN control path for automatic traffic steering and policy placement. • Well-defined interface among the components towards future standardization of advanced analytics in SDN.
- 37. ODL AI/ML framework PoC Architecture • PoC of both historical offline machine learning and real-time online machine learning Ø Collect the time series data Ø Persist into scalable data storage Ø Publish to high performance data bus • Integrate with external machine learning libraries Ø Spark MLlib Ø DeepLearning4J • Collect OpenFlow Stats and apply machine learning algorithms Ø k-means clustering
- 38. Use Case V OpenDaylight in OSS (future) WAN Transport Orchestrator (WAN-O) • Based on ACTN (Abstraction of Control of Traffic Engineered Network) IETF Standard for realizing hierarchical SDN architecture • Yang Based (NetConf/RESTCONF) Models
- 39. › Coordination of resources across multiple independent networks and multiple technology layers to provide end-to-end services › Layered operational model: – Customer: issuing a service request from catalog – Service Provider: dealing w/ Customer and providing the service (may or may not own the network(s) as such) – Network Provider: infrastructure providers owning the physical network(s) and building the infrastructure SDN Hierarchical architecture based on ACTN CNC - Customer Network Controller MDSC - Multi Domain Service Coordinator PNC - Provisioning Network Controller CMI - CNC-MDSC Interface MPI - MDSC-PNC Interface SBI - South Bound Interface
- 40. MDSC NBI: – CMI: CNC to MDSC interface – YANG based (Netconf/Restconf) – End to end Virtual Network concept – Unified end to end topology MDSC SBI: – MPI: MDSC to PNC interface – YANG based (Netconf/Restconf) – Per domain TE-Tunnels – White or Black Domain topology WAN-O as MDSC, interfaces CNC - Customer Network Controller MDSC - Multi Domain Service Coordinator PNC - Provisioning Network Controller CMI - CNC-MDSC Interface MPI - MDSC-PNC Interface SBI - South Bound Interface
- 41. SDNc Operator 1 Service Orchestration (Operator 1) Transport Network architecture WAN-O AP1 SDNc Operator 1SDNc Operator 2 SDNc Operator 3 ASBR ASBR ASBR ASBR ASBR ASBR ASBR ASBR AP2 ASBR Inter domain link White topology domain Black topology domain AP3 - IETF ACTN MPI - White topology - IETF ACTN MPI - Black topology
- 42. WAN Ctrl – PNC 1 WAN Ctrl – PNC n WAN Ctrl – Microwave Mini-Link, R6000 …. …. PE 3rd pp IP/Optical BSS Service (L2/L3 VPN) WAN Transport (Intra domain RSVP / SR, inter domain BGP LU LSP) 1 2 CPE 1. Service Orchestration 2. WAN Transport SDN (Underlay) END to END service orchestration Connectivity services e2e Orchestrator NFV-O WAN-O Transport Orchestrator Service Orchestration
- 43. WAN Ctrl – PNC 1 WAN Ctrl – PNC n WAN Ctrl – Microwave Mini-Link, R6000 …. …. PE DC GW VM vSwitch OF / Netconf VIM (Virtual Infra Mgr) DC Ctrl Net Virt 3rd pp IP/Optical (MP)-BGP peering Telco DC ACTN MPI Service (L2/L3 VPN) WAN Transport (Intra domain RSVP / SR, inter domain BGP LU LSP) DC Overlay transport (VXLAN, GRE) 3 CPE 1. Service Orchestration 2. WAN Transport SDN (Underlay) 3. Network Virtualization (Overlay) Nf-Vi NFVi END to END service orchestration VNF services 1 2 e2e Orchestrator NFV-O BSS Service Orchestration WAN-O Transport Orchestrator
- 45. Avenues for getting involved • OpenDaylight Wiki: https://wiki.opendaylight.org • Mailing Lists: • Central / Cross Project: https://wiki.opendaylight.org/view/Mailing_Lists • Complete List including individual projects: https://lists.opendaylight.org/mailman/listinfo • Chat with developers via IRC: https://wiki.opendaylight.org/view/IRC • Meetings: • Technical Steering Committee: https://wiki.opendaylight.org/view/TSC:Meeting • Technical Work Stream: https://wiki.opendaylight.org/view/Tech_Work_Stream:Main • Complete List including individual projects: https://wiki.opendaylight.org/view/Meetings
- 46. Areas to getting involved in • OpenDaylight Documentation Project • Project of your interest • https://wiki.opendaylight.org/view/Project_list • Code Reviews • Bug Fixing • MD-SAL & Clustering (Distributed Systems) • Experts • Enthusiasts: Improve your skills in these hot & in-demand area • Scale & Performance • Testing • Architecture Improvements • Example: Scalable and Robust Data Replication using etcd.
- 47. Acknowledgements
- 48. • Contributors to slides • Antonio De Gregorio • Colin Dixon • Daniele Ceccarelli • Dayavanti Kamath • Francois Lemarchand • Frederick Kautz • Jan Medved • Luis Gomez • Prem Sankar Gopanan • Scott Melton • Srini Seetharaman • YuLing Chen • Reference • https://github.com/BRCDcomm/BVC/wiki/MD-SAL
- 49. Q & A