Network Control and Orchestration in SDM and WDM Optical Networks

We present the first SDN-enabled multi-domain multi-layer (WDM/SDM) control architecture for partially disaggregated optical networks with multiple WDM and SDM OLS domains and transponders to provision end-to-end TAPI connectivity services involving spatial and optical channels.


Introduction
Network operators are facing a critical issue on their optical transport networks to deploy 5G+ and IoT services. They need to address the capacity increase by a factor of 10 [1], while keeping a similar cost per user. Over the last years, network operators are working on the optical disaggregated approach with great interest for achieving the required efficiency and cost reduction. In general, two optical disaggregation models are considered; partially or fully disaggregated. In the first model, the transponders (know as Terminal System) are provided by multiple vendors with open APIs to interface with the Transport SDN controller, whilst the transport system (ROADMs, amplifiers, etc.), known as Open Line System (OLS), remains a single-vendor system. The OLS controller is provided by the OLS vendor with open APIs to interface with the network operator's control system. In the second model, all optical network elements can be provided by different vendors with standard APIs to the network operator's control system.
On the other hand, Spatial Division Multiplexing (SDM) has been proposed as the key technology to overcome the capacity crunch that the optical standard single-mode fibers are facing to support the forecasted 10x growth. The combination of SDM and flexi-grid wavelength division multiplexing (WDM) enables to exploit the spectral and spatial (i.e., cores and modes) dimensions and, together with high-spectral-efficiency optical modulation formats, is key for meeting the capacity requirements. Spatial switching is gaining interest because it enables to deploy spatial switched optical networks (or spatial channel networks) to bypass the overloaded WDM networks, by provisioning spatial switched paths (or spatial channels) between WDM nodes as proposed in [2]. In this paper we address for the first time an SDN-enabled multi-domain multi-layer (WDM/SDM) control architecture for partial disaggregated optical networks.
2. SDN-controlled partially disaggregated multi-domain multi-layer network architecture Each domain is composed of one OLS and one or several transponders. The considered SDN control system relies on a hierarchical control architecture with a Transport SDN orchestrator (acting as a parent controller) and multiple OLS controllers (acting as child controllers) as well as transponder (TP) agents, one for each transponder, as depicted in Fig.1.b. The purpose of the TP agent is to provide a common API to the Transport SDN orchestrator for the configuration and monitoring of the WDM and SDM super-channels.In [3], we presented and experimentally validated the first SDN-enabled sliceable spatial-spectral transceiver architecture to support SDM and WDM super-channels controlled with YANG/NETCONF.

SDM OLS
(spatial switching)  Fig.1.b. The interface between the OLS controllers and the Transport SDN orchestrator is based on the Transport API (TAPI). TAPI defines a common YANG data model for control services (e.g., context topology, connectivity, and path computation), regardless of the specific implementation of the OLS controller. In general, the Transport SDN orchestrator gets a TAPI context from an OLS controller. A TAPI contenxt is defined by a set of service interface points (SIPs), which enables the Transport SDN orchestrator to request connectivity services between any pair of SIPs. Additionally, OLS controllers may expose an abstract topology within a TAPI context. Similarly, the Transport SDN orchestrator can generate TAPI contexts from its internal topology and expose them to its customers (e.g, NFV orchestrators).

SDM OLS
The TAPI context topology is expressed in terms of nodes and links. Nodes aggregate node edge points (NEPs) acting as node ports. Links interconnect two nodes and terminate on NEPs, which are mapped to SIPs at edge of the network. The topology information is updated for each connectivity service. In particular, the NEPs are updated with a list of connection end points (CEPs). CEPs encapsulate information related to a connection at the ingress/egress NEPs associated to the source/destination SIPs, or at every node that the connection traverses in a topology. WDM OLS controllers use TAPI with extensions for photonic media channels (i.e., optical channels), that are already included in the official release. In [4], we have defined a novel SDM data model for TAPI (tapisdm.yang) for spatial channels in the SDM networks.

Composition of the Transport SDN orchestrator's internal TAPI context
The Transport SDN orchestrator has to invoke several TAPI operations to compose the internal multi-domain multi-layer (WDM/SDM) TAPI context, as shown in Fig.2.a. More specifically, the Transport SDN orchestrator first gets the information of the involved OLS controllers (e.g., IP address, port) and the transponder agents associated to each OLS. Then, for each OLS controller, the Transport SDN orchestrator requests the TAPI context, and augments its internal TAPI context. OLS controllers provide abstract topologies associated to their OLS TAPI context. Then, for all TP agents associated to each OLS domain, the Transport SDN orchestrator gets the transceiver capabilities and generates a new SIP for the transponder that is associated to the SIP from the OLS (e.g, T1.1 and W1.1 in Fig,3) . After that, the internal TAPI context is augmented with the new SIP. It involves defining new TAPI data models for the WDM/SDM transceivers in order to define the capabilities and the configured parameters of the transceivers. The next action performed by the Transport SDN orchestrator is to augment the internal TAPI context with the inter-domain links between OLS domains. First, the Transport SDN gets the static information of the interdomain links (e.g., OLS domains and NEPs), and then, it adds the new links between the pairs of edge NEPs in the internal TAPI context. The final step is to augment the internal TAPI context with the SIPs from the customer TAPI contexts. It is performed by the Transport SDN orchestrator by getting the SIPs associated to all customer TAPI contexts and associating them to the transponder SIPs. At this point, the Transport SDN orchestrator has a complete view of the multi-domain multi-layer TAPI context as shown in Fig.3 2.b shows the workflow required to provision an end-to-end connectivity service between two transponders, involving several WDM and SDM OLS domains. First, the Transport SDN orchestrator receives a TAPI connectivity service request from a customer, specifying the source and destination SIPs (C1 and C2), as well as the capacity (in Gb/s). Then, the Transport SDN orchestrator computes an end-to-end path using the internal TAPI context topology. The Transport SDN orchestrator only performs domain selection, and the actual intra-domain path computation is delegated to the respective OLS controller. Once the Transport SDN orchestrator has computed the end-to-end path, it is segmented into OLS domain segments. In our example, an SDM domain is involved, since there is no direct connectivity between the WDM domains. Then, the Transport SDN orchestrator requests the provisioning of a spatial channel to the SDM OLS controller (i.e, S1.2-S1.3) using the TAPI connectivity service. Once provisioned, the Transport SDN orchestrator requests the new TAPI context to the SDM OLS controller and updates its internal TAPI context. After that, the Transport SDN orchestrator augments the internal TAPI context with a new inter-domain link between the NEPs of the WDM nodes associated to the provisioned spatial channel. Next, the Transport SDN orchestrator computes the spectrum required (in GHz) to serve the requested capacity between the pair of transponders associated to the customer SIPs. A main limitation is to satisfy the end-to-end spectrum continuity constraint. To this end, the Transport SDN orchestrator requests to each OLS controller the computation of the intra-domain path. We have also extended the TAPI path computation service in order to also provide the available spectrum along the computed path. It is used to compute a common frequency slot that meets the spectrum needs and is available across all WDM domains. After that, the Transport SDN orchestrator requests the provisioning of the optical channel on each WDM OLS domain through the TAPI connectivity service (i.e. W1.1-W1.2 and W3.2-W3.1), specifying the frequency slot. Once provisioned, the Transport SDN orchestrator requests the updated TAPI context to the WDM OLS controllers and updates the internal TAPI context. The last step performed by the Transport SDN orchestrator is to configure the transponders associated to the customer SIPs (T1.1 and T3.1) The Transport SDN orchestrator sends NETCONF messages specifying the configurable parameters to the TP agents. Once configured, the Transport SDN orchestrator updates the transponders SIPs in the internal TAPI context with the configured parameters. Fig.3.b shows the final internal TAPI context.

Conclusions
This paper has presented the first SDN-controlled disaggregated multi-OLS WDM/SDM optical network architecture with WDM and SDM transceivers.