ODTN Paves the Way toward Disaggregated Optical Networks

A lack of interoperability between optical components has been a problem plaguing the telecom industry for more than 30 years, driving up costs and complexity for telecom carriers. The Open Networking Foundation (ONF), along with its operator leadership and vendor partners, are continuously seeking new opportunities to drive innovation in computer networks through open standards, open source software, and collaboration. In particular, with interest from NTT Communications and Telefónica, ONF is actively pursuing optical disaggregation for data center interconnect (DCI) deployments. The service providers’ and members’ requirements, a use case overview, and implementation details such as application programmable interfaces (APIs) are described in ONF’s Open Disaggregated Transport Network (ODTN) Reference Design.

ONF and partner service providers’ view on disaggregation in optical networks

With very low margins on the networks themselves and the bulk of revenue transitioning to services, service providers are looking for more cost-effective ways to build their networks. As a result, the drive for optical disaggregation in DCI now comes in many forms, not only to drive capex and opex reduction but also, and maybe more importantly, in rapid cycles for introduction of innovations and new technologies, such as the ONF’s CORD technology that supports edge cloud applications.

Disaggregation of the different optical components and of hardware from software enables a better life-cycle cost approach (LCCA) since optical components can be interchanged at the end of their lifespan without the need to completely modify the network architecture. At the same time, suppliers can more narrowly focus on a specialty component (e.g., a transponder) without having to build a complete solution themselves. Optical network disaggregation shifts a deployment from a vertically integrated, single-vendor system managed by proprietary software to a disaggregated, multivendor environment (Figure 1).

How SDN with open APIs makes disaggregation possible

The shift to disaggregated network components creates the challenge of bringing the deployment back with the need for control and management in a multi-vendor environment. The shift is enabled first by exposing visibility and control of the optical domain to the upper levels of control. ONF and its service provider and vendor partners seek an improved disaggregation solution using open APIs and an open source controller while at the same time offering the cohesive control that operators desire.

In the disaggregated scenario, ONF is building the open source controller that understands the semantics of both the open and standard APIs and the open common data models. By exposing these open APIs and models, devices from any possible vendor become “plug and play” within the system, opening the door for best-of-breed product selection and a more optimal LCCA approach.

To build such a disaggregated network ONF, in collaboration with NTT Communications, Telefónica, Telecom Italia, and many vendors and supply chain partners, launched ODTN.

ODTN solution overview

The first step for optical disaggregation in a DCI point-to-point deployment is called a “partially disaggregated” optical network. The transponders are disaggregated from the line system that aggregates and controls other optical equipment, such as amplifiers, ROADMs, etc.

An optical domain controller is introduced to manage the end-to-end optical connection by managing the two transponders and the line system controller through APIs. In this partially disaggregated scenario the optical domain controller sees the open line system (OLS) as a “big switch” with many input and output ports to which the transponders are connected.

ONF and its collaborators are building ODTN using the Open Network Operating System (ONOS) as the open source controller, the OpenConfig Models as the transponder’s API, and the Transport API (TAPI) to manage the line system, which becomes an OLS. ONOS also offers the means to program the whole optical domain as one entity by exposing the same TAPI models northbound for an OSS/BSS to use (Figure 2).

ONOS initiates channels with the different elements by using the communication channels NETCONF or gNMI with the transponders and REST/RESTCONF with the OLS controller. Once device discovery is complete, ONOS requests device information, such as ports through the OpenConfig models for the transponders and TAPI for the OLS. Upon receiving device-specific information, ONOS builds a graph model of topology and exposes it through TAPI to the northbound interface.

To turn up a connection, ONOS receives a request from the upper layers to provision connectivity from a client port of a transponder to a client port of another, book-ended transponder. Upon receiving the request, ONOS stores it internally and then starts the negotiation for obtaining the end-to-end path. First it asks, through TAPI, the OLS for connectivity between the ports facing the two transponders. The OLS does internal path computation, wavelength assignment, and power computation, based on the power capability of the receiving transponders. Once the OLS returns a viable wavelength for the path, ONOS computes the required output power and provisions the wavelength and the power value to the transponders through Openconfig. ONOS treats the connectivity request always as bidirectional to enable traffic to flow in both directions.

The configuration is stored in ONOS and replicated across its controller instances. Such replication among a configurable number of ONOS instances enables the network to both scale up as needed and handle controller failures since ONOS instances can distribute loads and back each other up for carrier-grade resiliency. ONOS also is capable of handling data plane failures by recomputing paths across the network when such a failure occurs.

One step further: optical disaggregated white boxes

The ODTN deployment and workflow can work with various transponders and open line systems from many different vendors as long as they support the OpenConfig and TAPI models. Internally these devices run proprietary software and leverage integrated pluggable optical modules. Thanks to its partnership with the Telecom Infra Project (TIP) and Edgecore, ODTN is also working actively to integrate with the CASSINI optical white-box packet-optical transponder.

Cassini introduces, though TIP’s Transponder Abstraction Interface (TAI), the possibility of having plug-and-play transceivers on the line side by providing a common abstraction to the operating system running on the packet-optical transponder system. This type of abstraction enables a white box with merchant silicon to be built to provide Layer 2/3 functionality (Figure 3). ONF is building on this white box in collaboration by also collaborating with many transceiver vendors.

Current status and development

ONF is currently developing a disaggregated DCI solution in collaboration with our partners and collaborators. The development builds on top of what was described above to include even more configurable parameters, such as modulation, and to gather more data and alarms for a better view of the state of the optical system.

ONF, in parallel with the partially disaggregated scenario based on transponders and OLSs, is also working on a ROADM-based solution. Here, the ODTN system will have the same role of provisioning the optical domain but on a mesh or ring ROADM topology. ONOS drivers compliant with OpenROADM 2.2 are being used to program wavelength, power, and port state to OpenROADM 2.2 compliant boxes. Thanks to the many layers of abstraction, ONOS provides the same TAPI interface northbound and internally reuses all the constructs of the OLS-based deployment, with changes happening only at the device driver layer.

Operator Trials

ONF and TIP have also shown the capability of ODTN with the white box CASSINI device in multiple demos and are on track to deploy in the TIP community labs around the world, such as in London and Menlo Park, to give the community a testbed to continuously develop and test the platform with new hardware and software enhancements. The integration of ODTN has also been shown with other vendors such as NEC, Fujitsu transponders and Lumentum ROADMs.

These trials with different operators show the value of ODTN as a complete solution for controlling disaggregated optical networks, reaping the benefits of disaggregation while not having to compromise on the abstractions to the upper layer or introduce complexity in the deployment.

Thanks to the great progress we’ve been seeing, ONF expects to see growing engagement and field trials of ODTN in the upcoming months and next year.

Andrea Campanella is ODTN project leader within Open Networking Foundation.