Why Brocade?
We all have the opportunity to build SDN applications on different versions of the OpenDaylight controller, either getting the controller from the ODL project itself, or as a pre-packaged version from a networking vendor. And so the question arises: Which controller should I use? Or does it even matter?
I believe that the controller choice matters. In the following sections I hope to explain why.
When MD-SAL first poked its nose over the horizon, us SDN developers were required to build everything from scratch - creating directories and files for our model and provider, and creating feature and pom xml files for defining the components and dependencies of our application. Then thankfully the ODL MD-SAL development community threw us a bone by creating a Maven archetype for building MD-SAL applications, which would handle all of this for us. That was a major leap forward.
However, not all archetypes are created equal. The best evidence of this fact is that ODL itself has made multiple attempts at providing a good archetype. Some were too complicated for any but the most advanced MD-SAL insider. Others are so simple and bland as to not provide enough of the framework, such that doing things like connecting to the Data Broker or handling RPCs required building that functionality from scratch.
The Brocade archetype, IMO, provides just the right balance of simplicity and functionality. The necessary pieces are there for creating a useful MD-SAL application; and the complexity is absent, such as to make creating MD-SAL applications a much more achievable goal.
Another issue with the ODL MD-SAL archetypes is that both the archetypes, and the ODL which they use, are regularly changing. These archetypes tend to be built against the latest build of ODL. Consequently, when ODL makes a significant change of some type, the archetype will break. This can obviously be a problem, as you don't know at any point in time if the archetype is actually going to work or not.
In contrast, using the Brocade repository for ODL guarantees a fixed version of both the ODL components and the archetypes. Consequently consistency is guaranteed and builds will work throughout the lifetime of the version of the Brocade SDN Controller that you are using. And when you move to a newer version, you know that that archetype will work with the associated Brocade version of ODL as well.
One of the issues related to building against OpenDaylight is choosing which build of ODL to use.
-
The latest? How much testing has been done on the latest? Sometimes, things get broken on daily builds, as changes are made for supporting a newer version of this or that dependency. When ODL builds are broken, disruptions to your own development cycle will occur as well.
-
The latest stable version? This is certainly safer. But how stable is this version? How much testing has it undergone?
These are the common questions related to open source projects, and is often why organizations tend to favor versions that have gone through the extra testing required for release by a major vendor. Brocade performs extra testing on versions of ODL against which it will release the Brocade SDN controller, while still keeping pace with the regular release cycles of ODL. Meaning that you get a version of the software that is both up-to-date, and thoroughly tested. Tools (such as the archetypes) will just work - no issues related to version or dependency changes making your code no longer work. And no fear of daily builds breaking your environment.
And to clarify - this is not a slam on open source projects in general, or on OpenDaylight in particular. There is nothing inherently wrong with the fluid and dynamic nature of open source projects. We developers are used to living in this environment and accepting it, and even welcome it because it gets us features and capabilities much faster than would otherwise be possible. However at some point, there is value in having a solid, stable, unmoving foundation; and this is what the Brocade SDN Controller provides.
One of the major 'selling points', if you will, of ODL and its use of MD-SAL technology at its core, is the idea that this technology makes it easier to build layers of functionality on top of each other. Of course this has always been possible. But MD-SAL provides a structure and a standard way of doing this. But be aware - MD-SAL doesn't provide this itself; rather it enables layers and even encourages it. But providing those layers is not done by MD-SAL itself - these layers must be built and added as features to ODL.
An example of such a layer is the Path Explorer application, provided by Brocade. For developers interested in developing applications on top of an Openflow network, this application provides connectivity between two hosts in the network, allowing the application developer to focus on the functions that are important to its own solution, rather than having to worry about the low-level details of the underlying networking devices and protocols.
The figure above shows the Path Explorer providing host-to-host connectivity using Openflow on devices in the network. Notice that your application - and other applications as well - need not worry about details regarding topology, paths, etc. - that capability is provided by the Path Explorer application. And the applications above can utilize that functionality, rather than having to implement it themselves. This is the value of layering.
Another example of this layering is the Flow Optimizer application. The flow optimizer allows an administrator to create profiles that cause traffic to be dropped, redirected, metered, and marked for prioritization. The application allows layering by providing a REST API for creating these profiles. Consequently, the application developer can create policy-based applications at a high level of abstraction, and allow the Flow Optimizer application to handle the details of setting these traffic parameters on the devices themselves.
The above diagram shows an application which is able to concentrate on its core value - providing a robust and innovative policy-based solution - by making use of the Flow Optimizer layer below, which takes care of the details of device communication.
On that topic of the details of device communication...
If you or your organization is focusing on building an SDN application that provides some intelligent type of policy-based functionality, you don't want to waste your time and resources on the details of plumbing the network to perform rudimentary tasks. In fact, the whole point of being 'software-defined' is that you can leverage other components to do the dirty work for you - the nitty gritty details.
Consider what it took to build software in the past: functionality that everybody used, such as hash tables, linked lists, database access layers, networking protocols. These details had to be developed over and over again.
But not so today. Today in software we have libraries or JARs that implement these details for us, and we use these pre-existing components every time we develop software.
The same is true with the handling of the networking details, when writing applications on Brocade's SDN controller. Applications such as Path Explorer, Element Management System, and Flow Optimizer provide implementation details of each device, which means that we SDN application developers don't need to.
In the image above, Path Explorer takes care of the details of:
- Flows: Setting Openflow flow modifications in networking devices in the path between two hosts.
- Versions: Setting Openflow flows appropriate for devices, whether they support Openflow version 1.0 or Openflow version 1.3.
Note in the figure that we have placed a device supporting NETCONF into the mix. You can see that the Path Explorer has an asterisk(*) next to the name, because this functionality is not supported today. But in theory, it is conceivable that an application such as Path Explorer could support the creation of paths across devices that supported NETCONF. For example, a NETCONF router in the path between the two hosts could have a static route set to enable communication between devices, if that route did not already exist.
The point of the figure and of this discussion, however, is that the application writer is able to ignore the details of device communication - the "how" - and concentrate instead on the purpose and intentions of the application itself.
Speaking of intentions...
In the domain of SDN controllers and technology, conversation often turns to the topic of 'intents':
- ONF NBI WG: The north-bound interface (NBI) working group in the Open Networking Foundation (ONF) is focused on defining "intents" for use in APIs for SDN controllers.
- ONOS: The ONOS controller has specific "intents" APIs for use by SDN application developers.
- Vendors: Many vendors are supporting "intents"-based functionality and APIs in their proprietary controllers.
So where does the Brocade SDN controller stand regarding this idea of "intents"? As it turns out, the applications added to the ODL controller by Brocade provide APIs which are functionally equivalent to many of the "intents" mentioned by the organizations listed above. When you use an application such as the Path Explorer, and request that the controller create a path between two end node IP addresses, you are really specifying a host-level intent. And the Path Explorer provides that host intent level of functionality.
In the same way, when you use the Flow Optimizer, you are specifying "intents" for QoS and other characteristics related to desired traffic shaping behavior in the network.
Your application can specify the intentions, and the network turns those intentions into network reality.
The figure above shows the 'intent' level of API provided by the Path Explorer and the Flow Optimizer. So although the Brocade SDN controller doesn't specify them by the name "intents", it is actually implementing exactly that.
The concept of 'intents' points us in the direction of creating software applications that are 'declarative' in nature, which leads to the following topic...
Most of us are familiar with the idea of 'declarative' programming languages. The idea of declarative languages is that the developer specifies 'what' result is desired; and the system is responsible for determining 'how' that desired result is to be accomplished.
This is fundamentally what is true with an intents-based interface. You specify the desired result - e.g. connectivity between two hosts - and the system (in this case, the Path Explorer and Brocade SDN Controller) makes that goal happen. In the case above, it does so by setting flow table entries on the switches in the shortest path between the two hosts.
One of the main complaints lodged against SDN, and against Openflow in particular, is that the controller provides only a very low-level interface between specific devices and the application programmer. This situation causes the SDN application developer to specify precisely how the device is to behave. In many cases, this required focus on the 'how' details has made it difficult for SDN application developers to make significant progress towards creating newer and better networking solutions.
One of the goals of MD-SAL is to enable applications to operate in a more declarative manner, through the use of models of devices in the MD-SAL data store. Unfortunately today, ODL by itself does not elevate the level of device interaction to a more abstract, declarative level.
Thankfully the Brocade SDN Controller, with the declarative interfaces of the Path Explorer and Flow Optimizer, has made it possible for SDN application developers to focus on turning their innovative SDN ideas into real-world solutions, without having to worry about the details of devices or the imperative nature of other SDN APIs today.
We have provided some information regarding why the Brocade SDN Controller may be the right choice for you. The controller presents to application developers:
- Helpful archetypes
- A stable development environment
- Effective layering of functionality
- Handling of device details
- Intents-based APIs
- Promotion of declarative functionality
Of course you are free to chose whatever ODL distribution you desire, and they are all good options. But if any of the items listed above are important to you, you would be wise to consider the Brocade SDN Controller.