MD SAL
Welcome to the Brocade SDN Controller wiki page(s) relating to MD-SAL. In this page we will dive into the background of MD-SAL, its benefits, and how it actually works.
You are probably aware that with the first SDN controllers - starting as far back as 2008 - the controller APIs were all strongly tied to Openflow. Thus the applications developed were aligned directly with the specific southbound protocol - Openflow in this case.
With the introduction of OpenDaylight, and specifically with ODL's Service Abstraction Layer (SAL), one of the goals was to disassociate the application API from the southbound protocol plugins - be that Openflow, NETCONF, OVSDB, PCEP, BGP, SNMP, or whatever.
In actuality, this abstraction proved to be more difficult to realize in practice than it was in theory. In spite of all of its good intentions, the initial attempt at an abstraction layer - SAL - became a collection of independent and discrete APIs, with one set of APIs for each and every southbound protocol.
Note that for the most part, these APIs dealt directly with devices - calling an API resulted in a direct call to the southbound protocol plugin, and thence to the device.
Given that an SDN application could possibly desire to control devices using multiple control-plane protocols, such as those listed above, how could this be accomplished?
Two alternatives presented themselves:
| Alternative | Description |
|---|---|
| Build a better SAL | Take the existing APIs for the different plugins, and attempt to come up with an API abstraction that meets all of their needs |
| Use models | Implement a model layer within the SAL which has SDN applications dealing with software models of network devices, rather than directly with the devices themselves. |
The conclusion of the ODL designers was to create a new type of SAL, which would be based on SDN applications interacting with models, rather than directly with devices. As a result, historically, there were two different types of service abstraction, as shown below:
- AD-SAL: API-Driven SAL, for communicating more directly with devices, using protocol(s) associated with the specific API. Now deprecated in OpenDaylight.
- MD-SAL: Model-Driven SAL, for communicating with model objects, which then have responsibility for communicating with devices in the manner which is most appropriate. The chosen SAL for OpenDaylight.
Consider the following figure:
A few things of note in the figure above:
- Model: Note that in truth, "models" exist in all controllers - controllers discover devices, topology, hosts, etc., and then make that inventory information available to applications. The difference is that with AD-SAL, this inventory "model" only provides this information to the application. But with MD-SAL, in addition to providing information, the model is importantly the mechanism for performing all operations on devices.
- API-Plugin Relationship: With AD-SAL, there is one API library, but with multiple sets of APIs which interact directly with their respective plugins. With MD-SAL, the API provided interacts with the more abstract model rather than with plugins, thus disassociating the API from the actual protocol plugin being used.
This is the theory of MD-SAL communication, and how it proposes to insulate your SDN applications from the nuances of devices and device communication protocols.
Along the lines of "model-driven" being such a great idea, you may be asking yourself, "If it is such a great idea, why hasn't anybody thought of doing it before?" The answer to that question is - they have. Consider the following diagram:
As it turns out, folks have been building "model-driven" systems for quite a while in various places, particularly those related to network management. With the advent of object-oriented design and object-oriented programming languages, network management systems have been building models of the network, and using those models as a means of abstracting the details of actual network devices, and presenting that abstracted view to the applications above.
Thus, this model-driven design would shield applications and application developers from requiring intimate knowledge of the nuances and idiosyncrasies of each network device type. As seen in the figure above, the many and varied CLI commands, different across each manufacturer and device type, are hidden from the application.
In a sense you may consider MD-SAL as an evolutionary step forward from this object-oriented design of network management systems. Previously, traditional network management did a fine job of reading and displaying device status and traffic statistics, and in doing some amount of configuration and firmware management. But those systems were never able to achieve the more dynamic and robust network control that is promised by software defined networking.
Note: It is important to remember, however, that SDN controllers are not attempting to displace network management systems. Network management systems will continue to discover and map networks, monitor devices, track firmware and configuration changes, create trouble tickets, etc., into the foreseeable future.
So SDN builds on the model-driven approach of previous systems and adds fine-tuned device control and network agility to the solution.
Let's examine a couple other reasons for MD-SAL.
Consider the following figure:
In the figure, AD-SAL on the left has an SDN application communicating with another set of independent application modules. If those application modules within the AD-SAL domain wish to communicate with each other, they must create some type of method of doing so, such as utilizing OSGi services, or even a message bus. But those applications need to define and implement those communication interfaces manually.
With the MD-SAL example on the right however, each application is actually a model. And by definition, each model produces an API to which other application models can communicate. This produces an community of models, some of which can be both producers, and consumers, of the implemented services. This allows for organized distribution of responsibilities, and even layering of functionality.
As an example of this, the Topology Manager application of the Brocade SDN Controller is layered on top of device and topology models inside the controller, so that responsibility for application functionality is shared among these modules.
You may be familiar with the distinction between the "declarative" versus "imperative" methods of configuring systems. These concepts are present in the context of programming and programming languages as well. The general idea of these methods is as follows:
- Declarative: In this method you tell the software or the system what you want it to do.
- Imperative: In this method you tell the software or the system how you want to do it.
Quite often the goal in software, and with network control systems in general, is that you want to be able to tell the system what you want it to do, and you allow the system to decide how to do it.
MD-SAL attempts to accomplish this at a couple levels. Consider the following figure:
In the figure you can see the following movements towards creating a declarative environment:
- Device Level: Because applications and modules communicate with the model, they are able to tell it what to do; and the model can make the determination regarding how to do it (e.g. via Openflow, NETCONF, or another protocol plugin).
- Policy Level: Because modules built with MD-SAL are able to be service producers and consumers, it is possible to build policy layers into the controller infrastructure. By successfully doing this, declarative policy-based operations are possible.
If we are honest, we realize that today, MD-SAL application development can be a bit challenging. In fact it can be very difficult to create all of the pieces and parts that are required in order to get your MD-SAL application off the ground.
But there is good news: automatic application creation scripts have been built to simplify this application development startup process. This section provides an overview of the process.
For the following discussion, consult the following diagram:
Remember that with MD-SAL, applications are built using models. You will be creating a model or models; and you will be interfacing with a model or models. So if you want to implement an MD-SAL application, you will be creating one or more models, which may then become services accessible to other applications running on the controller.
In the figure above, "Model" shows up in multiple places:
- Define Model: You will use YANG to define your model.
- Compile Model: Once your model is defined, you will use YANG tools to compile your model.
- Model Artifacts: Once your model is compiled, there will be a number of artifacts created, which includes a model, a RESTCONF API, provider and consumer code: basically the skeleton for your application.
In the figure above, notice the references to YANG in the definition phase of your SDN application creation.
MD-SAL uses YANG as the data modeling language of choice for your application. Thus you will use YANG to define the model or models which constitute your application. As mentioned above, YANG tools will compile your YANG model into the appropriate folders, files and build instructions that will be used in constructing and compiling your MD-SAL application.
This wiki has a page on YANG for your reference, and there are many YANG tutorials and even ODL YANG examples listed in that YANG page. Please consult those pages for further YANG information and instruction.
In the figure above, the module in green represents the portion of the created application code that you will be modifying. This is your provider implementation; here you will write code to do whatever it is that your application or the model within your application does. The elements in red within the MD-SAL box are created automatically for you by the YANG tools that created the application.
If you are not familiar with Maven archetypes, they are templates for creating things that are of a particular type or pattern. For MD-SAL there is a Maven archetype which generates the framework of your project, going through the steps shown in the diagram above.
Some quick links to Maven Archetype information:
| Link | Information Provided |
|---|---|
| Maven Archetypes | General discussion of Maven Archetypes |
| Maven Archetype - Generate | Description of the specific Maven Archetype called "Generate" |
| MD-SAL Archetype | OpenDaylight tutorial on creating an MD-SAL application using Maven's Generate Archetype. |
To summarize the steps you will follow in order to create your application:
- Change directory to the location for your MD-SAL application.
- Run the Maven archetype:generate command specifying the appropriate opendaylight group-id and artifact-id.
- Provide answers regarding your application's group-id, artifact-id, version, packet prefix, etc.
- Run the MD-SAL application generator to create your application files, folders, and build instructions.
- Build your application.
As a result of this process, the application generator will automatically create the following:
| Auto-generated Item | Description |
|---|---|
| Karaf features directory | Includes list of sample features to enable provider, consumer, and web applications |
| YANG model | Simple YANG model which can be modified to specify the attributes of your model |
| Provider | Sample provider application which implements the RPC service defined in your YANG model |
| Consumer | Sample consumer application which can be extended to consume other model implementations within MD-SAL |
| Web | Sample implementation of a custom REST interface (note that this is in addition to the REST interfaces automatically generated for your application) |
Note: It is possible to remove unneeded projects if they are deemed unnecessary.
MD-SAL tutorials can be found in many places. Here are a few worth checking out:
| Source | Link |
|---|---|
| SDN Hub | ODL tutorial with MD-SAL section Note: remember to head to the end of the tutorial for the MD-SAL information |
| SDN Tutorials | Many detailed MD-SAL code snippets |
In this section we have discussed MD-SAL - why MD-SAL was created, what makes it appealing and useful, and how to automatically generate a simple MD-SAL application. With this MD-SAL background, access to MD-SAL tools, and other sources of MD-SAL information, hopefully you will be on your way to creating SDN MD-SAL applications on the Brocade SDN Controller.