ACINO: Report on the design of programmability elements for in-operation network control

This ACINO deliverable presents the work performed in task “Design of the programmability
elements for in-operation network control” to design the northbound interface of the ACINO orchestrator.

The document begins with a review of the requirements of the northbound interface, derived from previous work done related to use cases and application requirements and the expected properties of the ACINO framework (see report "ACINO: The framework for the application-centric network orchestrator").

The northbound interface of the orchestrator uses the intent paradigm: applications request what they want (in term of service properties), not how the requested services should be set up. This paradigm makes the interface potentially independent of the orchestrator, as it does not rely on the technical implementation of the control plane. Adopting an Intent-based interface as a standard for the orchestrator could make Software-Defined Networks much more popular, as applications communicating with them would 1) be easier to write (no knowledge of network technology required) and 2) not be tied to a specific orchestrator implementation. A review of the state of the art on the subject is presented in chapter 3.

The document defines two northbound interfaces: the Dynamic Intent-driven Service Management Interface or DISMI, which allows applications to request network services, and the Multi-Layer Topology and Planning Interface or MLTPI, which is an interface used for management purposes (e.g. interfacing with Network Management Systems (NMS)).

The network primitives exposed to applications through the DISMI are defined. Using the provided grammar, applications can combine them to build intents. The main types of primitives are:

• Actions, which describe the type of connection requested: point-to-point, point-to-multipoint or multipoint-to-multipoint, uni- or bi-directional;
• Nouns, which describe the network end points;
• Constraints, which specify the properties of the requested network service (bandwidth, delay, encryption, ...);
• Selectors, which allow discriminating traffic at the network end points and routing it over application-specific services.

Required properties for the DISMI, such as support for the standard CRUD operations (Create, Remove, Update, Delete), are discussed. Various ways to implement the intent grammar are presented. The DISMI is defined as a RESTful HTTP API, with JavaScript Object Notation (JSON) as data objects, and JSON schema to implement the grammar.

The possibility for an application to negotiate the network service properties after the initial intent request is discussed, and the steps to implement such functionality at the northbound interface are presented.

The architecture of the intent framework is presented. As defined, the DISMI is independent of ONOS, and the framework itself could be implemented as a component separate from ONOS. It is however integrated to the orchestrator to provide a full orchestrator implementation. The framework implements:

• The DISMI module, which performs the intent resolution: all the parameters and primitives of the intent are checked and validated;
• The various intent compilers (one per intent) that decompose intents and find a way to install them as sets of network requirements, then send them to ONOS for actual installation.

The network primitives exposed to applications through the MLTPI are defined. Network Management Systems can use them to pose questions, such as what-if questions (“what if this link fails?”) or re-optimization questions (“what is the benefit of a re-optimization with regard to energy usage?”). The result of such re-optimizations can be applied to the network or discarded.

The MLTPI is an extension of the DISMI: it adds a set of primitives and methods to the DISMI, that are only visible to privileged applications. Some of these primitives are to send questions; others provide the answers from the framework. Similarly to the DISMI, a RESTful HTTP API is defined for the MLTPI.

Finally, summarizing the design work presented in this report, four areas are identified in the network controller used as the base for the ACINO orchestrator, where programmability elements need to be modified or introduced to implement the functionalities described in this document.