ONOS-Controlled Disaggregated Optical Networks

State-of-art, potentials and limitations of the ONOS controller applied to disaggregated optical networks are reported. Focus is on the on-going ODTN project. Results of experimental demonstrations are reported to prove the feasibility of proposed approach.


ONOS potentials, performance, limitations
ONOS has been originally designed to operate on traditional SDN networks composed of electronic devices (i.e., layer-2 switches) mainly utilizing the OpenFlow protocol. However, with respect to other SDN controllers, ONOS natively addressed the most common weak points of the SDN architecture featuring a centralized controller, i.e., reliability and scalability. Therefore, it is one of the best candidates for the control of optical networks.
From the reliability point of view, ONOS is designed to run in a logically centralized but physically distributed fashion, where the controller functionalities are spread on a number of synchronized instances running on different physical machines [4]. This approach, together with an advanced multi-thread software architecture, strongly improves the system scalability because the mastership of devices can be balanced among the several instances [5]. Those reliability and scalability properties have been widely tested in emulated scenarios [4] [5], but also in the deployment of real networks such as a commercial deployment by China Unicom, and a worldwide deployment on a federation of research networks (e.g., Internet2, GÉANT, etc.). However, the multi-instance architecture is designed in such a way the controller instances should be located within the same LAN (due to stringent bandwidth and latency requirements). For this reason, several projects and exemplar platforms using ONOS are planning to use a hierarchy of (multi-instance) controllers where each controller is devoted to geographically distributed or different technological domains (e.g., electronic and optical). For instance, the E-CORD project (i.e., Enterprise CORD), that is in advanced phase of investigation by many worldwide operators including TIM, is using two different ONOS controllers at each CO, and a distinct ONOS controller for the network interconnecting the COs. All those controllers are coordinated by a parent ONOS interfaced with the network orchestrator (i.e., XOS in the CORD project). Another example is the control plane architecture selected within the METRO-HAUL project [1], where there is an ONOS controller at each metro node, an ONOS controller for the optical metro/regional disaggregated optical network connecting the nodes and a parent controller exposing the overall network view to the orchestrator.

ODTN working group
Most of the aforementioned use cases and deployments are focused on the utilization of electronic devices and OpenFlow protocol, while the utilization of ONOS as a controller of an optical network is still in the development phase and in course of experimentation in research environments [1]. The first attempt to enable ONOS to control an optical network has been made through extension of the OpenFlow protocol [6] [7]. However the OpenFlow protocol has been demonstrated to be not enough flexible to encompass all the configurations required on the optical plane.
In the meanwhile, several modeling initiatives started using YANG for the complete characterization of optical devices and configuration procedures. With this kind of modeling language, the natural protocol to control and monitor the network became the NETCONF protocol [8]. In this scenario, the ODTN working group has been created almost one year ago to enable ONOS to control, configure and monitor disaggregated optical networks based on NETCONF/YANG [2]. The ODTN work is planned in three main phases. In phase 1.0 the ONOS controller will be extended on both the NorthBound (NBI) and the SouthBound (SBI) interfaces. On the NBI, an ODTN app will accept properly formatted optical connectivity requests; on the SBI, a set of ODTN drivers will configure a transponder pairs. In phase 1.5 an OLS will be included within each pair of transponders so that the controller can start to be used in real networks, thus the implementation of a driver for configuration of the OLS will be required. In phase 2.0 the support of ROADMs will be introduced so that a meshed network topology can be correctly configured by the controller, in this phase all the accessory functionalities already provided by ONOS (e.g., routing) should be correctly upgraded to work in the optical domain. In phase 3.0 the ROADMs will be further disaggregated in more elementary devices such as, node degrees, filters, optical amplifiers, etc. However, since complete disaggregation could overload the controller without providing great benefit in terms of efficient use of resources, it is still unclear up to which levels of disaggregation phase 3.0 will lead.

b) required protocol interactions between the ONOS controller and the optical data plane (b); current protocol interactions between the ONOS controller and the optical data plane.
At the time of writing, the work in ODTN group is between phases 1.0 and 1.5. The NBI is already well-defined adopting the Transport-API (TAPI 2.0) models for receiving connectivity service requests and managing the network topology [9]. Within the current ONOS implementation TAPI is supported through RESTCONF protocol [10]. Thus, with reference to solid lines in Fig.1(a), users request the creation of lightpaths using the TAPI connectivity YANG model, (1). Upon reception of a connectivity request, the ODTN app maps the TAPI service interface points to ONOS ports at the transponder level and forwards the connectivity request to the ONOS core in the form of an Optical Intent, (2). Specifically, the utilization of the intent-based approach, has been recently decided within the ODTN project since it facilitates the re-utilization of a set of available functionalities within the current version of ONOS, such as (elementary) routing and spectrum assignment (RSA) algorithms, procedures to compile intents in a set of Flow Rules (typically including input/output ports and optical channel specification), and the main components of the device drivers. Then, once the intent has been compiled, the device drivers are used to forward the configurations toward the data plane, (3). For this last purpose, several drivers based on the NETCONF protocol are in phase of development. A different driver will be necessary for each type of devices (e.g., transponders, ROADMs) and for each considered YANG model. As an example, the driver for OpenConfig transponders is already partially included in the current distribution, while drivers for ROADMs based on OpenROADMs models are in phase of development, but already tested within the research community [11].

Open points and experimental demonstration
Apart from the on-going development of the aforementioned software components, the extension of ONOS to the optical disaggregated networks poses also other important points to be addressed: • A typical requirement of optical networks, where devices are characterized by a significant configuration time, is the ability of the controller to know when a lightpath has been completely configured on the data plane. At this regard, the utilization of NETCONF protocol is a good starting point because a confirmation message is sent for each configuration request. Specifically, the desired behavior is depicted in Fig.1(b): the controller replies to the orchestrator request only when data plane is totally configured, the intent should be set as installed in the controller only when all the flow rules are in the ADDED state at the controller. Finally, each flow rule is set in the ADDED state immediately after the reception of the NETCONF confirmation message from the device.
Conversely, in the current implementation, see Fig.1(c), the controller does not provide a feedback to the orchestrator when the lightpath is established, and the flow rules are not turned in the ADDED state up to the next monitoring cycle (i.e., typically every 10-15 seconds). • Another important requirement is to facilitate the integration with external tools for network planning and accurate evaluation of optical physical impairments. Indeed, almost all network vendors and operators would continue to use their own tools to plan and provision the optical network (e.g., advanced routing algorithms). In addition, there are some well-established open-source initiatives implementing this kind of tools [12]. To this extend, we propose the modular integration model depicted with dashed lines in Fig.1(a), where the app on the NBI is extended so that, after utilization of some ONOS features, step 1a, (e.g., for the retrieval of some physical plane parameters) but before submitting the optical intent to the ONOS core, an external tool can be utilized through NETCONF or RESTCONF protocol, steps 1b and 1c. The approach described above has been tested and demonstrated in an experimental environment. Specifically, we have developed NETCONF agents implementing OpenConfig YANG models for the terminal devices and OpenROADM YANG models for ROADMs. Virtual agents have been implemented using ConfD and Net2Peer tools running as NETCONF server. The agents have been utilized to control both emulated and real optical devices, such as a ROADM prototype with a three-degrees and one add-drop module, provided by TIM [11]. In all the experiments the whole control cycle to establish optical intents (i.e., steps 1, 1a, 1b, 1c, 2, 3 in Fig.1) has been executed in about 100 ms, plus the time needed by the external tool (e.g., we have implemented an external tool estimating the effect introduced by cascade of optical filters that requires about one second per path).

Conclusions
This paper provided an overview of the ONOS potentials, performance and limitations to control disaggregated optical networks, with specific focus on the on-going work within ODTN. A pair of experimental demonstration are briefly reported, to clarify the kind of work that is required to extend ONOS to control optical networks.