Controlling and Monitoring Optical Network Equipment in Optical SDN Networks

This paper presents an overview of current trends in network protocols for control and management of optical networks and optical network equipment. The paper explores the usage of these protocols in open source optical networking projects.


Introduction
With the introduction of Software Defined Network (SDN), there exists an architecture for dynamic control of optical networks, through the definition of Optical OpenFlow [1] . SDN proposes the logical decoupling of control and data planes. Thus, SDN and traditional architectures share some concepts, such as: standardized management interfaces, standardized architecture, and partly open interfaces and use cases.
The introduction of SDN in optical network control has introduced a new way of thinking, where applications take control over the service. It is in this sense, that SDN-enabled applications are being developed on top of open source based SDN controllers that are responsible for the logically centralized control of the optical network. These optical SDN controllers provide the necessary network simplification through abstraction and virtualization. These are provided using multiple services, which are depicted in Fig.1.Examples of the exposed services from the optical SDN controller are: topology, provisioning, path computation, virtualization, and inter-domain connectivity.  Figure 1 also shows the proposed protocols and standards for optical network control and monitoring. It can be observed that two domains are addressed: network control and network equipment. Regarding network control, this paper will present the interfaces and protocols presented by Internet Engineering Task Force (IETF) and Open Networking Foundation (ONF). Both interfaces rely on YANG data modelling language [2] , which is used to describe the necessary data models in both cases. IETF proposed interfaces based on TEAS models [3] . Later, NET-CONF [4] or RESTconf [5] protocols are provided to control the network with the described data models.
With regard to control and management of network equipment, two different data models have been proposed in optical community: Open-ROADM [6] and OpenConfig [7] . OpenROADM is a multi-source agreement between multiple manufacturers to make reconfigurable optical add/drop multiplexers (ROADMs) compatible across vendors. It addresses three network interfaces: common single-wave interface between transponders, common multi-wave interface between ROADMs, and common YANG models for all components. On the other hand, OpenConfig is an informal working group of network operators adopting SDN principles such as model-driven management.
Telemetry refers to the streaming of monitoring data in the context of network operations. It helps network monitoring and troubleshooting. Several novel protocols have appeared in the last years that claim lower protocol overhead in comparison with Simple Network Management Protocol (SNMP), both in synchronous and asynchronous monitoring. YANG PUSH [8] , gRPC and gNMI [9] are trying to fill this requirement.
This paper presents an overview of the necessary protocols for network control and monitoring. It will provide clear examples where the protocols have been applied, as well as it will provide guidance of the protocol to select depending on the desired use case and requirements.

YANG-based optical network control
In this section, models are presented for optical network control that serves as a NorthBound interface of an optical SDN controller.
IETF working group Traffic Engineering Architecture and Signaling (TEAS) has proposed the YANG Data Model for Traffic Engineering (TE) Topologies [3] and for Traffic Engineering Tunnels and Interfaces [10] . This can be easily extended with optical parameters, such as in WSON or FlexiGrid models. It has also proposed the Abstraction and Control of TE Networks (ACTN). ACTN presents high-level abstractions that are a valid and recursive solution for several scenarios, including multi-technology and multi-domain transport network services. A demonstration of its applicability is proposed in Cross Stratum Orchestration (CSO) as a feasible solution for NFV points of presence interconnection [11] . The demo architecture and the interfaces/APIs were aligned with IETF ACTN.
In parallel, ONF proposed the set of functional requirements and information model for the Transport API (T-API) [12] . ONF T-API was first demonstrated in [13] , proposing it as a feasible solution for multi-vendor SDN in transport networks. Topology and connectivity services were demonstrated and provided a clear proof of how standard interfaces benefit multi-vendor interoperability. Several papers have presented T-API extensions to support multiple novel technologies, such as Space Division Multiplexing (SDM). In the paper [14] , the authors demonstrated an experimental NFV MANO framework for the control of SDM/WDM-enabled fronthaul and packet-based transport networks by extending the T-API.
T-API usage in SDN controller is spreading due to several facts: a) it is a well known API; b) it is extensible and Open Source; c) it has been tested and deployed; d) it provides proper abstractions; e) it covers a multitude of use cases, such as multi-layer; and f) it is supported by a great community of vendors. The current opensource projects proposing an implementation of T-API models are: Open and Disaggregated Transport Network (ODTN) [15] , an ONF led project based on the ONOS framework; and Transport-PCE [16] , an OpenDaylight (ODL) project. ODTN has demonstrated the recursive usage of Transport API, acting as a network orchestrator at the ONOS NBI level as well as acting as a client of the Optical Line System (OLS) at the SBI level. Moreover, ODTN also has demonstrated support for Ethernet (connectivity service establishment between client ports) and photonic layers (between transceiver line ports). On the other hand, Trans-portPCE is included in OpenDayLight and it targets the photonic and OTN layers, including the ability to configure OTN crossconnections and interfaces. It includes a partial implementation of ONF T-API to support the export of an abstracted view of the topology to an SDN controller.

Control and Management of Optical Network Equipment
This section focuses on describing the most extended YANG data models for control and management of optical network equipment, which have been adopted in disaggregated optical networks: OpenROADM and OpenConfig.
OpenROADM objective is to move away network operators from propietary control and data plane of ROADMs [16] . In [17] , it is presented one of the first OpenROADM demonstrations. It shows end-to-end carrier Ethernet circuits orchestration in a hierarchical control plane of ONOS SDN controllers. To this end, ONOS includes new device drivers to enable to directly configure ROADMs using NETCONF and YANG models defined by the OpenROADM project. Last release of Open-ROADM is demonstrated in [18] , which includes novel functionalities for multi-layer use cases using TransportPCE project of OpenDayLight.
OpenConfig describes vendor-neutral YANG data models for a variety of network elements, from routers to optical switches. If we focus on optical-transport, it provides a configuration and state model for: a) terminal optical devices within a DWDM system, including both client-and lineside parameters; b) wavelength router; c) optical amplifier; d) channel monitor; and e) protection switch. Extensions have been demonstrated to enable dynamic selection of transmission parameters of 100G/400G transmitters with coherent reception in a filterless metro network [19] . Another example is the demonstration in [20] , which augments OpenConfig data model of optical-wavelength-router to demonstrate network disaggregation, including various operations on both degrees and media channels.

Novel Telemetry mechanisms in Optical Networks
Telemetry has been a powerful tool for optical network management, being historically deployed using SNMP. Several types of data are exposed and consumed, such as network state indicators, network statistics, and critical infrastructure information. Novel protocols such as YANG-PUSH [8] , gRPC [21] and gNMI [22] provide novel features that support system update: a) ability to do bulk retrievals; b) support of multi-tenancy of the monitored device (e.g., through multiple NMS); and c) introduction of highly efficient protocol buffers (protobuf). Apart from periodic telemetry, novel subscription types are defined, with the introduction of conditional telemetry, which refers to the establishment of a push connection and forward targeted telemetry data to a targeted recipient when certain criteria are met.
YANG-PUSH is a novel mechanism that allows applications to subscribe to a customized stream of updates from any available YANG datastore. This provides lower resource consumption and ease of system integration. The work presented in [23] demonstrated for the first time the implementation of YANG push notifications on an Open Terminal based on OpenConfig models.
gRPC Remote Procedure Calls [21] is based on HTTP/2 as a transport protocol and uses protobuf encodings for transported messages. As it is based on HTTP/2 transport protocol and uses byte-oriented encoding, it introduces low latency. The first experimental demonstration of gRPCbased SDN control and telemetry architecture for spectral/spatial super-channels with SDM/WDM transceivers monitored the BER to detect softfailures over an 11-km 6-mode 19-core fiber [24] . gRPC Network Management Interface (gNMI) [22] is a protocol for configuration manipulation and state retrieval. It is built on top of gRPC and it is described using protobuf and uses binary or JSON encoding for payload. YANG data models can be operated using gNMI. gNMI telemetry makes use of the SubscribeRequest. From the "user" perspective, the collector just dials in to the publisher and specifies the sensor path it wants to monitor, and the conditional telemetry to subscribe. An OpenConfig NET-CONF Agent implementation enhanced with gRPC telemetry has been demonstrated to assess and retrieve transmission performance and rapidly determine the most suitable operational mode [25] .

From Optical Monitoring to Optical Zero Touch Networking
In this paper, we have focused on obtaining the necessary telemetry in order to execute proper control actions. It is important to understand the processes that close the loop . From understanding the proper monitoring data, automated troubleshooting can be implemented. This will lead to a repair action, which requires automated control of the optical network. Finally, the repairment will be verified as monitoring will follow the new state. This mechanism is known as Optical Zero Touch Networking [21] . It addresses two core areas: a) how to cost effectively sustain rapid network growth; and b) how to minimize human errors and associated outages.

Conclusions
In Figure 2, NETCONF, RESTconf, gRPC and gNMI are compared. These protocols are compared using: a) data modelling language; b) the transport layer behind; c) the different data encoding formats; d) capability exchange in order to provide auto-discovery mechanisms; e) ability to handle multiple datastores; and f) data store locking capacities. This paper has justified the need for data models and protocols in order to control and monitor optical networks and optical network elements. The authors have reviewed the current state of the art with significant contributions to each of the proposed solutions. Finally, a comparison of the proposed solutions is provided in order to better adapt them to the necessary optical use cases and scenarios.