What is OpenDaylight Controller:MD-SAL:Architecture ?

Updated -

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.

alt text

MD-SAL currently provides infrastructure services for:

  • Data Store
  • RPC / Service routing
  • Notification subscription and publish services

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.
  • Modeling 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.

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
Infrastructure and Infrastructural Components

Binding-Aware SAL
This uses code generated both at development time and at runtime. It comprises the following sections:

Disclaimer: Links contained herein to the external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

  • Component
  • SDN

Comments