SDN Applications
###So you think you want to write an SDN application?
If you believe you want to write an SDN application, you've come to the right place. In these pages we will define the different types of SDN applications, help you to understand how to design those types of applications, help you to actually get started writing those applications, and show you the ways in which the Brocade SDN Controller is a great choice for helping you to do so.
So whether you are here of your own accord, or if your boss just told you "I want you to start writing SDN applications", this page (and the others on this wiki) should help you get started.
You may be asking why it is necessary to define the term "SDN", let alone "SDN Applications". Software Defined Networking has been around for a while - haven't we gotten past the definition part?
But the fact is that there are actually multiple definitions of SDN. In order to truly understand what type of application you are building, it would be wise to understand what these different definitions are. So for the sake of discussion and to help us understand the SDN landscape just a little bit better, let us group SDN into three general categories:
| SDN Type | SDN Definition |
|---|---|
| Open SDN | This type of SDN is based on the Openflow protocol, allowing applications to be built for devices from a heterogeneous set of vendors, as long as their devices support Openflow |
| SDN via Open APIs | This type of SDN features open APIs allowing application developers to create solutions using the provided APIs. Note that these APIs can exist on devices, on an SDN controller, or at policy-level APIs provided by applications running on top the SDN controller. |
| SDN via Overlays | This type of SDN is popular in data centers and attempts to solve a number of networking issues related to scale and automation |
Why is this important? It is important to understand these definitions because one positive aspect about OpenDaylight, and hence about the Brocade SDN Controller, is that with it, you can build any of the above types of SDN applications. Your application is not limited to Openflow, and it isn't limited to only working in Overlay environments. The APIs provided by the controller allow for a wide and flexible range of application types.
Us software developers often tend to want to jump right into writing software. Sometimes, especially in Agile development environments, this is acceptable. However, in other environments - and SDN is one - jumping into code immediately is not always a good idea. SDN applications need to be designed before they can be developed.
We classify two types of SDN applications:
| SDN Application Class | Definition |
|---|---|
| Reactive | Depends on packets periodically being forwarded to the controller, in order to set transient forwarding rules on the device |
| Proactive | Packets are not forwarded to the controller, but rather forwarding rules are set based on initial configuration and on external change events |
Important Note: Both of these classes of SDN application are dynamic - they must be, since that is the whole point behind the agility and automation which is a fundamental part of SDN. However, reactive applications are extremely dynamic, and flows or configurations on a device are changing all of the time. Proactive applications will set flows dynamically, but only as a result of external stimuli such as traffic load changes, failed links, or modification to prioritization requirements.
Why is this important? Understanding whether your application is going to be reactive or proactive sets the groundwork for your entire SDN application design. But it also helps you to understand the environment in which your SDN application will be running:
- Programming Language: If you are writing a reactive application, you will need to develop your application in the native language of the controller since you will be using native-language APIs and callback mechanisms. With the Brocade SDN Controller, that language will be Java. On the other hand, proactive applications often use RESTful APIs, which allows for development to be done in any language you choose - even scripting languages.
- Runtime Environment: If you are writing a reactive application, you will be running inside the runtime environment of the controller. In our case that would be inside the Karaf OSGi container. Therefore your application will be co-resident on the same system as the controller. If you are writing a proactive application, your code can run anywhere you want - on a remote system, on the same system, in a different container, or in the same container.
Note: Be aware that it is possible to develop SDN applications which have some reactive parts - subject to the constraints above - and some proactive parts. The distinctions above are provided to help developers to understand general SDN application types and the development restrictions placed on each.
SDN applications can be deployed into a couple of different execution environments: Internal and External.
- Internal Applications: Applications that are deployed internally run inside the container that is hosting the rest of the OpenDaylight controller software.
- External Applications: Applications that are deployed externally run outside the container that is hosting the rest of the OpenDaylight controller software.
The following diagram shows Internal applications (on the left), and External applications (on the right).
Notice how internal applications are running inside the OSGi container which also holds the main controller code. And external applications are independent of that container, and communicate with the controller (and other controller-based services) using the RESTful APIs provided.
The execution environment for your application will dictate a number of things regarding your SDN code. Some of these restrictions and capabilities are listed below.
- Internal SDN applications must be written in the native language of the controller, which for ODL will be Java.
- Internal SDN applications must adhere to the design and execution constraints of the controller, which for the Brocade SDN Controller means that they must be MD-SAL applications.
- Internal SDN applications must execute in the same Java Virtual Machine (OSGi container) as the controller, which means that these types of applications must run locally with the controller.
- Internal SDN applications can access the Java APIs of the controller and of other MD-SAL applications running inside the controller's OSGi container.
As a result of running inside the OSGi container of the controller, internal SDN applications will generally run faster and with less latency than an external application. For example, if you are building a reactive SDN solution, you will want it to be an internal application.
However, internal SDN applications can implement either reactive or proactive SDN solutions. There is no requirement one way or the other for internal applications.
Note: Although internal SDN applications may use Java APIs for communication with other components running on the controller, it is not required that they do so. For example, during a proof of concept phase, it may be quicker to access other services using their REST APIs, and refactor your code to use the internal Java APIs once the project is well underway.
- External SDN applications can be written in any language, even scripting languages such as Bash.
- External SDN applications can be run remotely, i.e. on a different host than the controller.
- External SDN applications will use the REST API provided by the controller or by other applications providing RESTful access to their services.
As a result of using the REST API for communication, external SDN applications are well-suited for operating as a proactive type of solution. In fact it is generally ill-advised to attempt to create a reactive type of SDN solution which is also an external application.
Note: Since we are only talking about software here, there is nothing to prohibit you from creating an SDN solution which utilizes application components which are both internal and external, if needs demand such a solution.
Developing your application on an SDN controller will ultimately come down to the APIs that are available to you for tasks such as learning about devices, topology, statistics, meters, flows, configurations, etc. As a developer there are two major groups of APIs, which have correlation to the design choices described above:
| Type of API | API |
|---|---|
| REST | OpenDaylight RESTCONF API Explorer and [[Brocade Wiki RESTCONF Developer Resources |
| Java | OpenDaylight Java API Javadocs* |
(*) Note that OpenDaylight Javadocs can be hard to pin down since all links point to the "latest build", which can sometimes fail.
Because of the Service Abstraction Layer functionality (explained in more detail elsewhere, applications can be written which interact with devices using different southbound protocols, such as Openflow, NETCONF, or others. This abstraction is provided by OpenDaylight and hence the Brocade SDN Controller, and allows you to write any of the different types of SDN applications listed at the beginning of this article.
This concludes our discussion on developing SDN applications. You have learned about:
- SDN application types: openflow-based, open APIs, overlays
- Reactive versus proactive SDN applications
- SDN application programming languages and runtime ramifications
- SDN controller APIs
For more information on other topics, return to the wiki home page and follow the links listed there.