ONOS’s Northbound APIs, the REST API

[Damien Lu]

Hi everyone,

I have been reading for a while about the ONOS controller architecture and more specifically about ONOS’s northbound APIs.In the old versions of ONOS, i read that the REST API has been used for the interaction between the SDN control plane (ONOS’s controllers) and the SDN application plane (ONOS’s applications). Lately, I have read that the recent versions of ONOS support other northbound APIs like FlowRule, FlowObjective, gNMI, gNOI, Topology ...and there was no mention of using the REST API. Do ONOS applications (internal applications like forwarding (fwd) sitting in the “apps” folder of ONOS’s source code) use  the above northbound APIs to interact with the controller? Are there some internal applications in ONOS that still use the REST API ? Or, is the REST API only used for applications that are external to ONOS applications that can be developed using the following command: “onos-create-app rest org.foo foo-app 1.0-SNAPSHOT org.foo.app” ? Are there ongoing works about the standardization of the northbound API in ONOS?

Thank you in advance.

Best regards.

[Eder Ollora]

Hi,

I hope I can answer you to the best of my knowledge. So please, anyone that sees any error is welcome to answer. I will try to first comment on some of the things you said and then answer the questions.

The REST API (let's consider that the REST API as the one based on HTTP/1.1) is always been part of the controller and exposes some functionalities to applications that generally work as an external 3rd party entity. I think it is still a relevant interface and it has not been changed as far as ONOS 2.5 (Velociraptor). With micro ONOS this might seem to change (see next Figure). I don't see any reference to the same type of REST API available in the current ONOS but it might still exist in micro ONOS, we'll see. Developers might only focus on using gRPC. You can check more here.

Following with the REST interface, you can have a controller placed at a server and an application working from your own computer that periodically requests the flows installed in a particular switch. That is the typical use case I have in mind (but there are more). Your application, via the REST API, can also install flows in a switch. Since you can develop your own internal Java applications, your application can additionally implement a REST API with your own REST API resources and can expose any functionality that you want. So in principle "anything" can be done via the REST API. Ideally, you could even have an external fwd app (ReactiveForwarding) that does the same as the one that is internal to ONOS and uses the REST API. However, this is probably not a good idea if you plan to fast-react to network events. It is also not a very cost-efficient way of dealing with switches.

The Flow Objective concept, as far as I can remember, is an abstraction used to program flow rules in a pipeline-independent way, that gets ultimately translated to FlowRules. These abstractions generally used by applications running within the controller, like the fwd app you mentioned. From ONF slides:

In terms of gNMI gNOI, P4Runtime protocols (and others), I think the following captures can make some sense. Those ones are mostly related to programmable data planes and cover different functionalities. P4Runtime covers, to some extent what OpenFlow does. gNMI and gNOI (part of OpenConfig) deal with other functions like administration, configuration, and operation (maybe what OF-Config was expected to do? Maybe NetConfg/RESTConf?). All these concepts make more sense with the Stratum OS switch.

Now answering your questions:

Do ONOS applications (internal applications like forwarding (fwd) sitting in the “apps” folder of ONOS’s source code) use the above northbound APIs to interact with the controller? 

As far as I can see, fwd uses ForwardingObjectives (part of flow objectives) to interact with the controller, when it comes to install flow rules. These objectives are then translated to lower-level abstractions like a set of Flow rules. And then to OpenFlow messages or P4Runtime messages. At first, the description of a Northbound interface was confusing to me because the fwd app and an external app are both probably entities belonging to the application layer. But, physically, are most likely placed at different "places" in the network (in-controller app vs external controller). Also, they use different APIs to first interact with the controllers.

Are there some internal applications in ONOS that still use the REST API?

That is a very good question and I don't know of any. But considering that the REST API is a further abstraction of internal APIs (because any internal data has to be finally converted into an HTTP message and payload), then why use the REST API? Any information available via the REST API can probably be acquired first using other Java APIs.

Or, is the REST API only used for applications that are external to ONOS applications that can be developed using the following command: “onos-create-app rest org.foo foo-app 1.0-SNAPSHOT org.foo.app”? 

Unless I am wrong in this, I would say the REST API is mostly used by external applications. And yes one can create a REST API for their application with the command you typed.

Are there ongoing works about the standardization of the northbound API in ONOS?

I don't know how to answer this question. Now if you talk about standardizing the abstractions like a FlowObjetive, an Intent, or anything similar I am not sure if that can be done or is generally done. I think these abstractions belong to the ecosystem of each controller and depend on how developers have abstracted lower-level functions and concepts into higher-level entities. I think using the HTTP protocol for a REST interface is probably available in most of the controllers but the (REST) API could be different. For instance, using a GET /devices (to get the list of available devices) might be consistent or not across controllers. There could be other methods or resource URIs to achieve the same thing. Also, other controllers also offer Java/Go/Python APIs for their internal applications, and the way that developers abstracted a concept like a set of Flow Rules into a high-level abstract concept will likely vary from controller to controller. Therefore, ONOS, OpenDaylight, Ryu, HP Van, Juniper Contrail or Huawei Agile might use similar high-level abstractions to represent one or a set of  FlowRules and expose an interface via an internal API to program the switch tables and other tasks, but that does not mean that the abstractions are the same, or that one can expect that an application is portable across controllers (which would be nice).

I hope it helps.

Cheers,

[Damien Lu]

Hi Eder, 

Thanks a lot for your detailed reply.

That really helps !

Best regards,