At On.lab we are moving fast toward real deployment of SDN technologies.
ONOS aims to be a reliable platform to program networks. In order to unleash the full potential of SDN, developers should be able to develop network programs regardless of the hardware used. This means the operating system should provide an abstraction that is just right, in a way that developers can take full advantage of the existing hardware while still being flexible enough to write software once and have it executed on anything.
That’s not an easy task, in order to achieve such a goal several subsystems and layers of abstractions are constantly being developed on ONOS. Today, I will approach the FlowObjective Service.
The FlowObjective service provides an interface between Openflow devices and ONOS. The need for it arose with OpenFlow 1.3 as vendors were allowed to diversify the implementation of multi-table forwarding pipelines in order to be more efficient. The diversification of pipelines is great for performance matters, but it is not so great for developers who have to either choose one specific vendor to write software for or rewrite the software for each hardware device.
The FlowObjective service abstracts that complexity by means of OpenFlow drivers. Using the Flow Objective forwarding elements, you only have to write code for the application once, and someone only has to implement each driver once as well. Still, someone has to be the first to write the drivers.
The Bgp router app and the Segment Routing app currently use the Flow Objective service. In that manner, the OpenFlow drivers were built to support those applications and still may not be able to support some other applications.
We believe that the development of more applications will enrich the current OpenFlow driver, and the results achieved with those drivers will aggregate innate value to new applications. Wouldn’t it be great to write an app that just works in a well known set of hardware?
Well we are working for that!
Leave a Comment