Getting more involved with the internals of the OpenDaylight (ODL) Project can help network engineers better understand...
how the OpenDaylight Project controller works and how its various pieces fit together. But to learn how developers interface with ODL, engineers first need to get comfortable with some new tools.
First off, the OpenDaylight Project makes extensive use of Maven archetypes to ensure consistency of any new projects or applications that engineers wish to build on top of the platform. Maven archetypes allow users to build the basic skeletons for new projects, including some of the default build files, the directory structures and some base Java classes. Users wanting to build an application should start with the provided Maven archetypes to get off the ground. The developer guide illustrates some example workflows leveraging the Maven archetypes, using the mvn CLI utility.
Moving to a different topic, we shall illustrate some examples of YANG to show how to get simple applications up and running. YANG is a data modeling language that engineers may use to model configuration, operational state, remote procedure calls (RPCs) or notifications on the platform or even network devices. There are a number of reasons for performing this sort of task. One example is that by producing a YANG module -- which, for simplicity, we may think of as a single file of YANG -- engineers may then leverage built-in YANG tools to automatically generate code for API bindings or Java classes that adhere to the project's standards and best practices. The developer guide illustrates the following example of a YANG module that an engineer may produce using an IDE to define a Hello World RPC that may be issued against the controller.
For those new to YANG, here are some relevant details to help you understand the YANG module above:
- The hello.yang module shown defines an RPC operation as indicated by the RPC statement, which is reserved by the YANG RFC.
- The input sub-statement is also reserved via the YANG specification and, in this example, defines an input parameter for the hello-world RPC operation.
- The input tree has a leaf -- identified as name -- that expects a string data type.
- The output substatement is also reserved via the YANG specification and defines the output from the hello-world RPC operation.
- The output tree has a leaf -- identified as greeting -- that returns a string datatype.
After creating the YANG module above, users may use Maven to build the Hello World example. In doing so, the engineer may expose a RESTCONF interface, allowing users to issue RPCs using our sample application.
Recall that by developing the model of our Hello World RPC in YANG, YANG tools may then be used to automatically expose various APIs. RESTCONF is an example of API binding that is produced in this manner. To provide some history on why RESTCONF exists, recall that YANG was initially created to be the data modeling language for the NETCONF protocol, which primarily uses Secure Shell for transport and XML for encoding. To ensure proper mapping of YANG-modeled applications to a REST-like interface, the RESTCONF specification was created.
Now we shall illustrate how to consume the RESTCONF API for our modeled Hello World RPC. The figure below illustrates an example using Google Chrome's Postman to generate a RESTCONF API call. Note that the developer guide details some additional required changes to various Java classes to get the result shown below. The main goal of the figure below is to see how the YANG model affects the exposed RESTCONF API.
For those new to RESTCONF, here are some relevant details to help you understand the RESTCONF API call illustrated above:
- Since we leveraged the RPC statement in the hello.yang module, the resulting API uses a POST operation to the /RESTCONF/operations resource. The RESTCONF RFC provides more detail on the mapping of the RPC YANG statement to RESTCONF.
- The remaining portion of the URI string is derived from the YANG module name, hello, and the RPC identifier, hello-world.
- The input and output JSON formatting in the RESTCONF API call are also a direct result of the modeling performed in the hello.yang module.
In summary, familiarizing yourself with the internals of the OpenDaylight Project requires a commitment to learning some new tools. With a little effort, however, network engineers can start to understand the basic inner-workings of the controller and how developers interface with the OpenDaylight Project. Special thanks to Ed Warnicke for leading a tutorial highlighting some of these details.
Learn more about OpenDaylight training
Which vendors offer OpenDaylight controllers?
ONOS, ODL may collaborate on SDN controller