1 / 19

Proposal: Model-Driven SAL for the OpenDaylight Controller

Proposal: Model-Driven SAL for the OpenDaylight Controller. April 29 , 2013 Tony Tkacik Jan Medved. Contents. Background & Motivation: Controller Architecture Existing SAL Moving to Model-Driven SAL Model-Driven SAL Overview: Binding Independent Service Adaptation Layer (SAL)

tivona
Download Presentation

Proposal: Model-Driven SAL for the OpenDaylight Controller

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Contents • 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

  3. Background & Motivation • 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

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

  5. Current SAL Controller Business Logic • Business logic modules interact with Abstraction layer through Generic Service Requests & Responses. • Services Manager manages generic services such as Device, Discovery, etc… • Services are constructed using individual features exposed by Plugin Manager (based on Plugin availability and Device capability). Statistics Manager Host Tracker Switch Manager Slicing Manager Topology Manager Forwarding Manager Service Requests Feature Request Services Manager Plugin Manager Service to Feature Registry Device Capability based Feature to Plugin mapping Database Abstracted Plugin Response Service Abstraction Layer Plugins are chosen dynamically by the Plugin-Manager based on the feature request on a given Device or set of Devices. Each Plugin work independently of one another and are loosely coupled with the Services manager. 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 OF-Config Plugin SB Plugin SB Plugin OF Plugin

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

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

  8. Moving to Model-Driven SAL (Cont.) Applications API – Presentation Layer Java native function calls or RPC REST/HTTP Network Service … Topology Plugin (Service) NE NE NE NE System Flows RIB … Tunnels Paths Nodes Links … Table Table Table Config Stats … Abstraction Layer Flow Flow Flow SB Protocol OF-Config OF x.y PCEP BGP-LS Libs Libs Libs Libs Libs Network Elements

  9. Model-Driven SAL Overview • 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

  10. Binding-Independent SAL • 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

  11. Programmatic SAL • 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 • ApplicationDevelopers • Controller plugin development which provides access to other protocols (e.g. FlowPusher, Programmatic OFConfig APIs)

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

  13. Components • 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.

  14. Components • 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 neutralData 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

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

  16. Programatic SAL examples

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

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

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

More Related