Transport API Extensions for the Interconnection of Multiple NFV Infrastructure Points of Presence

We present the provisioning of constrained connectivity services and protection/restoration scenarios using Transport API for the interconnection of multiple NFV infrastructure points of presence, which is needed for the uptake of NFV at telecom operators.

shows the experimental setup at Telefónica Labs during 2018 OIF interop demonstration. It consisted on several vendor-specific network control domains, each controlled by an Optical SDN Controller (acting as a WIM), which exposed T-API. SONATA Service Platform is able to deploy network services, which may be located in different VIMs, supported by NFVI-PoPs. These network services are composed of interconnected virtual network functions (VNF) that are connected through the multiple network domains. The topology service is required to explore a set of connectivity end points (in T-API terminology service-interfacepoints) whose requirements may be specified from OSS/BSS and/or NFV-O (e.g., affinity group, location constraint). The topology service can also be used to collect WAN QoS parameters (e.g. capacity, latency, cost, etc.) that shall satisfy the network service QoS requirements as imposed by the OSS/BSS and/or NFV-O. It also allows to recover the network topology information, in order to request specific domain provisioning.

Figure 1 NFVI-PoP interconnection scenario
In order to interconnect the VNFs and to provide the network service, two or more end points given by the NFV-O are then interconnected with the connectivity service including capacity and layer information, among others. Figure  2.d shows an example of demonstrated connectivity service request. The NFV-O might include several constraints to the requested connectivity service, which are demonstrated in next sections.

Constrained Provisioning
One finding of the OIF 2016 interop was that the initial T-API 1.0 did not provide detailed enough information for computing connectivity service path across nodes, especially any port-to-port connectivity constraints or metrics associated with a node. In this use case, T-API 2.0 has been extended with include/exclude link and node constraints, which ease the constrained provisioning. Another explored topic (not solved in T-API 2.0), but expected to be incorporated in new revisions is the necessity of requesting specific transport labels from the NFV-O perspective. This has been previously explored in [6]. Figure 2.a shows the most significant introduced extensions in order to provide constrained connectivity services, with the objective to set up a connection across the optical domain subject to various constraints. Some of the available constraints are for example: a) diversity among other connectivity services (including a list of references to the connectivity services), b) exclude/include link/node (providing a list of link/node references), c) Shared Risk Link Groups (SRLGs) (by specifying the risk-diversity-characteristic), and/or d) to avoid infeasible paths or paths that do not comply to the constraints (by providing a reference to a path). The workflow is as follows. A connectivity service request is issued from SONATA Service Platform towards a WIM including service constrains. The WIM computes an optimal path for the request that complies with the constraints. Finally, if there is a feasible path, WIM creates the necessary connections.

Resiliency scenarios
The resilience model focuses on the switch construct which represents the forwarding selector and which enables changes of forwarding to achieve resilience. The model also represents the control element of the resilience control loop that monitors behavior, assesses that behavior identifying necessary configuration changes and applies those configuration changes to make the required adjustments to forwarding to achieve the intended resilience. Workflows are different for protection and restoration resiliency scenarios. Figure 2.b and 2.c show the extensions of T-API for supporting resilience, focused on restoration-policy (per domain or end to end restoration) and protection-type (no protection).

Optical protection
This demonstration evaluates the capabilities of T-API 2.0 to support the request and automation of a protected connectivity service, and include the necessary control-plane configuration parameters, such as: a) reversion-mode, which indicates if the protection scheme is revertive or non-revertive; b) wait-to-revert-time; and/or c) hold-off-time, which indicates the time between declaration of signal degrade or signal fail and the initialization of the protection switching algorithm. The workflow specifies the need for the creation of a second connection for protection purposes. Both connections (working/nominal, protection) are created by the WIM. Nominal and protection paths must be disjoint. After creation of protected service via VIM, notification about nominal and protection path is sent to SONATA service platform. In case a failure affects the nominal path, service traffic is switched to protection connection and WIM will notify SONATA about switching between nominal and protected connection. Traffic recovery is done in the hardware layer and is typically taking place in a short time period of less than 50ms.

Optical restoration in single domain
The objective of this section is to evaluate the T-API management of connectivity services with restoration capabilities in a single domain autonomously. This allows the evaluation of the optical channel restoration life cycle, which includes events notifications, T-API topology updates, and T-API Connectivity-Service Updates. There is no need to provision resources for a restoration path upfront. Restoration is done in software layer via WIM. Restoration can be configured in two ways -revertible or not. Without reversion the workflow is described as follows. A connectivity service is created with resilience-type and restoration-policy. When a failure occurs in the domain network, topology update notification is sent to the SONATA service platform. WIM attempts to restore autonomously. In case effective restoration, notification is sent to SONATA about Connectivity Service path update and nominal path is removed. In case restoration is not possible, a notification is sent to SONATA about Connectivity Service path SLA Failure. Workflow is different in reversion case. After a successful restoration, when nominal path will be fixed, service can be reverted automatically (with control plane algorithm) or manually on request from SONATA service platform. We do not provide restoration time for the demonstrated scenarios, due to the fact, that restoration time from control plane perspective is negligible in comparison with each domain internal restoration time. This time depends on the optical path length and number of optical components to be equalized.

Conclusions
The testing successfully demonstrated that T-API enables real-time orchestration of on-demand connectivity setup, control and monitoring across diverse multi-layer, multi-vendor, multi-carrier networks. The introduction of T-API for NFVI-PoP interconnection enables novel scenarios and use cases where connectivity constraints or protection/recovery mechanisms are needed. These network architectures enable operational improvements, service innovation, and establish the foundations for autonomous networking.