Presentation is loading. Please wait.

Presentation is loading. Please wait.

Www.opendaylight.org Proposal: Model-Driven SAL for the OpenDaylight Controller April 29, 2013 Tony Tkacik Jan Medved.

Similar presentations


Presentation on theme: "Www.opendaylight.org Proposal: Model-Driven SAL for the OpenDaylight Controller April 29, 2013 Tony Tkacik Jan Medved."— Presentation transcript:

1 Proposal: Model-Driven SAL for the OpenDaylight Controller April 29, 2013 Tony Tkacik Jan Medved

2 Background & Motivation: Controller Architecture Existing SAL Moving to Model-Driven SAL Model-Driven SAL Overview: Binding Independent Service Adaptation Layer (SAL) Programmatic SAL Architecture Components Programatic SAL Examples: Notification example Method call (RPC) example Contents

3 Key Controller architecture requirements: Runtime Modularity and Extensibility Multiprotocol Southbound Open Extensible Norhtbound API Deployable in different environments (SP, enterprise, cloud) Achieved by utilizing: OSGI Service Abstraction Layer (SAL) Also known as Software Adaptation Layer SAL itself must be run-time modular & extensible => Model-driven approach Background & Motivation

4 OpenDaylight Controller Architecture 4 Network Elements OpenFlow SB Proto Libraries PCEP Libraries OpenFlow Libraries Abstraction Layer SB Protocol PCEP OF x.y API Network Service Functions Network Orchestration Functions Service Management Functions Java native function calls or RPCREST/HTTP Slicing Manager Slicing Manager Switch Manager Switch Manager Topology Manager Topology Manager Fwdg. Manager Host Tracker Host Tracker … …

5 Current SAL 5 OF Plugin Plugin Manager Device Capability based Feature to Plugin mapping Database Services Manager Service to Feature Registry Service Abstraction Layer OF-Config Plugin SB Plugin SB Plugin Slicing Manager Slicing Manager Switch Manager Switch Manager Topology Manager Topology Manager Forwarding Manager Host Tracker Host Tracker Statistics Manager Statistics Manager Feature Request Abstracted Plugin Response Controller Business Logic Service Requests 1.Business logic modules interact with Abstraction layer through Generic Service Requests & Responses. 2.Services Manager manages generic services such as Device, Discovery, etc… 3.Services are constructed using individual features exposed by Plugin Manager (based on Plugin availability and Device capability). 4.Plugins are chosen dynamically by the Plugin-Manager based on the feature request on a given Device or set of Devices. 5.Each Plugin work independently of one another and are loosely coupled with the Services manager. 6.Service Abstraction Layer (specifically Plugin manager) is the only place plugin details are exposed. Hence NO Cross-Contamination across Plugins (or) no Contamination in Business-logic layers

6 Moving to Model-Driven SAL Network Elements Abstraction Layer SB Protocol PCEP OF x.y API – Presentation Layer Java native function calls or RPCREST/HTTP … Libs Network Topology LinksNodes Paths NE … SystemFlows Table … … Flow ConfigStats Tunnels … NE BGP-LS Libs OF-Config Libs Verifier Plugin Notifier Plugin Plugin … Config Stats … Table … Flow Applications

7 Moving to Model-Driven SAL (Cont.) Network Elements Applications Abstraction Layer SB Protocol PCEP OF x.y Network Model REST /NETCONF Network Model REST /NETCONF Libs Network Topology LinksNodesPaths NE … SystemFlows RIB Table … … Flow ConfigStats Tunnels … NE BGP-LS Libs OF-Config Libs REST API API ALTO Verifier Plugin Notifier Plugin Plugin …

8 Moving to Model-Driven SAL (Cont.) Network Elements Applications Abstraction Layer SB Protocol PCEP OF x.y Libs Network Topology LinksNodesPaths NE … SystemFlows RIB Table … … Flow ConfigStats Tunnels … NE BGP-LS Libs OF-Config Libs Plugin (Service) Plugin (Service) Service API – Presentation Layer Java native function calls or RPCREST/HTTP

9 SAL is model driven, SAL is modeled by YANG SAL supports two formats Binding-independent format: Data and functions calls independent of generated Java language bindings Data and functions calls expressed in neutral DOM- like model Programmatic (Binding-aware) format: APIs generated from YANG models APIs represented in Java as generated classes Model-Driven SAL Overview

10 Does not uses generated bindings Data and calls represented in DataDOM form (XML with separation of schema versions) Ideal for components which should work with any YANG model Configuration Store Runtime State Repository OFConfig Support Netconf Protocol Plugin Any controller or external component / plugin which needs access to models / data which were unknown at compile time Binding-Independent SAL

11 The binding-aware SAL Generated from YANG models describing the providers Generated code consists of: Compile-time API – Java Interfaces Runtime bindings – classes generated at runtime map between the compile-time APIs and the binding- independent data formats Best for Application Developers Controller plugin development which provides access to other protocols (e.g. FlowPusher, Programmatic OFConfig APIs) Programmatic SAL

12 Architecture Binding-Aware Core Binding Independent Core Data Repository Transient Repository (MI Data Repository) Providers Binding-Aware Providers Binding-Aware Consumers Applications Controller SAL Core Providers Binding Generator Binding-Independent Consumers Schema Repository Binding-Independent Providers

13 Binding-independent core The Core component of the controller SAL. Routes RPCs, notifications and data changes between various providers and applications. Binding-aware core Most useful component for application and provider development Provides programmatic APIs and Java language support for binding-independent broker. Binding-independent data repository A binding-independent provider responsible for storage of configuration state and runtime data Schema Repository Stores parsed YANG models Specifications of YANG–Java relationships and mapping between language-binding APIs to binding-independent API calls. Components

14 Binding Generator Component responsible for generation of proxies, Transfer Object builders, mappers to binding-independent form. Provider A component that exposes functionality to north-bound applications and other providers (plugins) A provider can be a consumer of other providers. Binding-independent – functionality exposed in a neutral Data DOM format Binding-aware –functionality is exposed in a format compiled against generated binding interfaces Consumer A component that consumes functionality provided by one or more providers Binding-Independent –functionality is consumed in A neutral Data DOM format Binding-aware –functionality is consumed via generated binding interfaces Components

15 Programmatic SAL generation Binding Aware Core User Input Automated YANG Model Java Binding Generator Binding specification (Java Interfaces) DevelopmentDeployment Runtime Binding Generator Client code uses generated proxies Generated Mapper Binding Independent Broker Providers call return Client code requests service Model Schema Repository

16 Programatic SAL examples

17 Notification example Binding-aware Provider Binding-Independent Provider Binding-aware Broker Application Consumers Controller SAL Providers 2. onNotifation(ExampleNotification) 3. onNotification(example) Binding-independent Broker 1. notify(new ExampleNotification()) 2. notify(example)

18 BA-to-BA Call Example Binding-aware Provider Binding-aware Broker Application Consumers Controller SAL Providers 1. ExampleModel.example() return 2. ExampleModelImpl.example() Generated Proxy

19 BA-to-BI Call Example BI Provider Binding-aware Broker Application Consumers Controller SAL Providers 1. ExampleModel.example() 3. rpc(example) return Binding-independent Broker 2. rpc(example) return Generated Proxy


Download ppt "Www.opendaylight.org Proposal: Model-Driven SAL for the OpenDaylight Controller April 29, 2013 Tony Tkacik Jan Medved."

Similar presentations


Ads by Google