After the latest work on Heat support for Netfloc service chaining, the SDN team used the summer’s quiet month of August to update some of the features in Netfloc and Netflogi.
A new extension to the API set is the functionality to retrieve the current service chains created in Netfloc. This has been made possible with the improvement of the Netfloc service yang definition and the persistent data record from Netfloc into the MD-SAL repository. Using this APIs the providers of a Netfloc service can now issue RPC requests to the datastore inventory and retrieve the current data and state of the service. This improves the resilience by keeping the network state and the chain aligned and consistent in case of Netfloc restart.
The Model-Driven SAL (MD-SAL) of the OpenDaylight controller provides generic support for developers to create applications and plugins using the API of their choice: Java generated APIs for consumers and producers, DOM APIs, REST APIs. The later is based on the IETF RESTCONF draft, an extension to NETCONF, that includes a mapping specification of YANG models to REST-ful interfaces. The reason for using RESTCONF in OpenDaylight is due to YANG being the choice for a modeling language of the MD-SAL.
YANG is an IETF standard for modeling network element configuration. In OpenDaylight, YANG describes the resource data and message patterns of the services. Moreover, there is a dedicated project for yang tools development, including a repository with a large set of yang models defined by the OpenDaylight community. The following describes the way the MD-SAL and YANG talk to each other:
- The providers define an abstraction for their service by specifying the wiring configuration in the yang descriptor file. This file is parsed in the controller to provide the system dependencies and YANG-to-Java code mapping. Finally the provider object should be instantiated and the service is ready to be consumed.
- The consumers use RESTCONF to provide access to RPC and MD-SAL data stores by invoking POST operations to a RESTCONF URL.
The data is organized in tree representation format and each subtree element can be accessed via instance identifier. The data published by the provider’s services is stored in the Operational Data Tree, wheres the data related to the system’s state can be found in the Configuration Data Tree. For further info please take a look at the Basic Operations Guide slide deck.
The Netfloc’s List chains API is an RPC call to the Operational data store. It returns the information about the Chain Owner and the Connection points of the chained Virtual Network Functions (VNFs). This call and the respective chains data is shown in Figure 1. Following the new model definition, Delete chain API was also modified to keep the chain data aligned to the operational data store.
Netfloc currently supports both, Restonf based APIs – Figure 1, and Java-from-yang generated APIs – Figure 2. These can be accessed and invoked using Postman or the OpenDaylight specific apidoc repository:
[Neftloc-URL]/apidoc/explorer/index.html#!/netfloc(2015-01-05)
Figure 1: Service Chains List API based on RESTCONF RPC
Figure 2: Service Chains List API based on YANG
Further advances are related to the Statistics Management module in OpenDaylight using the Lithium version of the OpenFlow plugin. The idea is to provide a detailed information of the Netfloc’s managed network state. RESTCONF access to the network topology could be queried using the current set of APIs that the Statistic Management component includes, in order to provide individual and aggregate statistics for: nodes, tables, flows, meters etc. The APIs to access the topology inventory data is the following:
[Neftloc-URL]/restconf/operational/opendaylight-inventory:nodes
With the objective to improve Netflogi – the GUI of Netfloc and provide a representation of the SDN topology, we implemented initial views based on: (1) the new APIs for service chain representation and (2) the statistics collection from the statistics management module.
We enclose here some snapshots of the data currently included. Figure 3 depicts the openflow port mapping and address info.
Figure 3: Netflogi’s Port information data for specific Netfloc node
Figure 4 shows all the flows related to a port, the respective IDs (Broadcast, Network path, Chaining flow, LLDP flow etc.), and the priority info along with the Match Fields and Instructions details.
Figure 4: Netflogi’s Flow details for specific port and its match conditions
The shown data is part of what can be currently retrieved as SDN info. The upcoming work will focus on model definitions for more diverse data retrieval and representation in order to support a consumer-generated monitoring service in Netfloc. Moreover Netfloc will continue improving the model definitions in order to provide more resilient and scalable services. Of course, we will also work on the user experience in Netflogi and extend the existing set of features.