Difference Between AD-SAL & MD-SAL

The SAL (MD or AD) is nothing more than a crossbar connecting the protocol plugins to the Network Function Modules (FRM, Topology Manager, Switch Manager … etc).  The SAL APIs are the contracts to which the protocol plugins and the NFS modules adhere in order to be able to speak to each other.

The table below lists differences between API-Driven SAL and Model-Driven SAL.



API-Driven SAL Model-Driven SAL
The SAL APIs, request routing between consumers and providers, and data adaptations are all statically defined at compile/build time. The SAL APIs, request routing between consumers and providers are defined from models, and data adaptations are provided by ‘internal’ adaptation plugins.
The AD-SAL typically has both NB and SB APIs even for functions/services that are mapped 1:1 between SB Plugins and NB Plugins The MD-SAL allows both the NB plugins and SB plugins to use the same API generated from a model. One plugin becomes an API (service) provider; the other becomes an API (service) Consumer.
In AD-SAL there is a “dedicated” REST API for each northbound/southbound plugin. MD-SAL provides a “common” REST API to access data and functions defined in models
The AD-SAL provides request routing (selects an SB plugin based on service type) and optionally provides service adaptation, if an NB (Service, abstract) API is different from its corresponding SB (protocol) API. The MD-SAL provides request routing and the infrastructure to support service adaptation, but it does not provide service adaptation itself; service adaptation is provided by plugins
Request routing is based on plugin type: the SAL knows which node instance is served by which plugin, and when an NB Plugin requests an operation on a given node, the request is routed to the appropriate plugin which then routes the request to the appropriate node. Request Routing in the MD-SAL is done on both protocol type and node instances, since node instance data is exported from the plugin into the SAL
AD-SAL is stateless MD-SAL can store data for models defined by plugins: provider and consumer plugins can exchange data through the MD-SAL storage
Limited to flow-capable device and service models only Model agnostic. It can support any device and/or service models and is not limited to flow-capable device and service models only
AD-SAL services usually provide both asynchronous and synchronous versions of the same API method. In MD-SAL, Service model APIs only provide asynchronous APIs, but they return a ‘java.concurrent.Future’ object, which allows a caller to block until the call is processed and a result object is available. Same API can be used for both synchronous and asynchronous approach. Thus MD-SAL encourages asynchronous approach to application design but does not preclude synchronous applications.


  • https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:FAQ
  • https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Application_Migration_Guide
  • https://lists.opendaylight.org/pipermail/controller-dev/2013-October/001614.html

Leave a Reply

Your email address will not be published. Required fields are marked *