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

2. Contents Background & Motivation: Model-Driven SAL Overview:
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
SB Proto Libraries
PCEP Libraries
OpenFlow Libraries …
OpenFlow
Network Elements

5. Current SAL Controller Business Logic Service Requests Plugin Manager
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).
Controller Business Logic
Switch
Manager
Host
Tracker
Statistics
Manager
Slicing
Manager
Topology
Manager
Forwarding Manager
Service Requests
Plugin Manager
Feature
Request
Services Manager
Device Capability based
Feature to Plugin mapping Database
Service to
Feature
Registry
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
Plugin
OF-Config
Plugin SB
Plugin SB
Plugin

6. Moving to Model-Driven SAL
Applications
API –
Presentation Layer
Java native function calls or RPC
REST/HTTP
Abstraction Layer
Network …
Topology
Verifier Plugin NE NE NE
Tunnels
Notifier Plugin
System
Flows … …
Nodes
Links
Table
Table …
Table …
Config
Stats
Plugin
Stats
Config
Table
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
Service
Network …
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
Application Developers
Controller plugin development which provides access to other protocols (e.g. FlowPusher, Programmatic OFConfig APIs)

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
Binding Generator
Binding-Independent Consumers
Schema Repository
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 Provider Consumer
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

15. Programmatic SAL generation
Binding Aware Core
User Input
Automated
YANG Model
Java Binding Generator 
Binding specification (Java Interfaces) 
Development
Deployment
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. Binding-aware Provider Binding-independent Broker
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. Binding-aware Provider
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. Binding-independent Broker
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“)
Generated Proxy