OIF looks to solidify Transport SDN APIs

Having demonstrated the potential of several application programming interfaces (APIs) for Transport Software-Defined Networks (SDNs) alongside the Open Networking Foundation (ONF; see "OIF and ONF enjoy joint Transport SDN demonstration success") the Optical Internetworking Forum (OIF) now hopes to create implementation agreements (IAs) around them. The IAs will use the Service Request and Topology APIs prototyped in the demonstration as foundations.

The effort will see IAs created for Service Request, Path Computation, Topology, and Link Resource Manager interfaces identified as part of the OIF's upcoming SDN Framework document. The APIs will be based on REST and JSON principles.

In a read out of the joint demonstration in October, OIF sources said they were impressed with the ease of use REST provided. However, the demonstration also uncovered a few loose ends that need to be tied up.

"The prototype Transport SDN demonstration revealed a lack of definition for how user applications interact with transport network applications and resource functions," explained Coriant’s Jonathan Sadler, the OIF technical committee's vice chair, via a press statement. "The programmability of Transport SDN requires some of the internal interfaces used by ASON to become open."

The OIF will seek to define a common Service API that will enable applications to request connectivity services from the network, including in an environment with multiple domains with potentially different underlying control methods. For example, in the joint demonstration, different domains supported a variety of south-bound interfaces (SBIs) with the domain controller; these included vendor-specific, standard OpenFlow version 1.3, and OpenFlow with optical extensions examples. The prototype common Service API used in the demonstration enabled the same application to be tested across such heterogeneous domains.

Meanwhile, the Topology API will enable applications to "understand" the connectivity available in the network. Again, a common Topology API should enable multiple applications to access network topology information to enable support for new constraints and service criteria.

In the joint demonstration, a prototype Topology API enabled different domains to export their topology information. This ability enabled path computation to be performed outside of the controller. The paths could then be requested using the Service API. The prototype Service API responses referenced links and nodes in the topology, which enabled the activated path to be shown as well.

For more information on packet transport systems and suppliers, visit the Lightwave Buyer's Guide.