Jump to: navigation, search

OpenDaylight Controller:MD-SAL:Architecture

SAL Guide Contents
Model-Driven Controller SAL
SAL:Infrastructure and Interfaces
SAL:Architecture Overview
SAL:YANG Schema
SAL:BI Data Format
SAL:BI Components
SAL:Binding-Aware SAL
SAL:Binding Model
SAL:BA Components
SAL:Example Workflows and Diagrams
Programmer Guide Top Level
Top Level Contents

Introduction

Model-driven Service Abstraction Layer (MD-SAL), the Model-driven approach to service abstraction presents an opportunity to unify both northbound and southbound APIs and the data structures used in various services and components of an SDN Controller.

In order to describe the structure of data provided by controller components, a domain-specific language, YANG, is proposed as the modeling language for service and data abstractions. Such language allows:

  • Modeling the structure of XML data and functionality provided by controller components.
  • Defining semantic elements and their relationships.
  • Modelling all the components as a single system.

The XML nature of YANG data model presents an opportunity for self-describing data, which controller components and applications using the controller’s northbound APIs can consume in a raw format, along with the data’s schema.

Utilizing a schema language simplifies development of controller components and applications. A developer of a module that provides some functionality (a service, data, functions/procedure) can define a schema and thus create simpler, statically typed APIs for the provided functionality, and thereby lower the risk of incorrect interpretation of data structures exposed through the Service Abstraction Layer.

Scope

This content defines the architecture of a model-driven Service Abstraction Layer (SAL), binding-independent data formats used in the SAL, and infrastructure components that comprise the SAL.

Definitions and Acronyms

  • Binding: Java interfaces, classes and contracts generated from a YANG schema describing functionality.
  • Binding-Aware: A component or functionality which uses a generated Binding for data and APIs.
  • BI, Binding-independent: A component or functionality which uses a neutral data DOM format for data and API calls, which is independent of generated Java language bindings.
  • Binding-independent type identifier: An identifier for a data structure or an RPC method in a QName-like format[1].
  • Consumer: A component (e.g. an application) which uses the model and/or APIs provided (implemented) by another Providers.
  • Data operation: An operation on top of data subset describing the state of the system as a whole (configuration, running data).
  • DTO, Data Transfer Object: a simple object used to transfer data between Binding-Aware components. DTOs are part of binding.
  • Infrastructure Component: A component which is neither a Provider or a Consumer, but exposes or extends the SAL functionality.
  • Provider: A component which provides functionality to applications through either model-specific APIs or in a binding-independent format
  • SAL: Service Abstraction Layer.
  • NSF: Network Service Function (e.g. TopologyManager, ForwardingRulesManager).

Content Structure

This content is organized into three main parts:

AD-SAL Transition Plan

MD-SAL to AD-SAL Compatibility

References