The Open Optical Networking Blogs, part 2
In this blog series, Fujitsu’s Francois Moore explores the key issues and current developments in open optical networking. The topics addressed include Adding Alien Wavelengths, Controlling Multi-Vendor Optical Networks, Opening the ROADM network, Disaggregating the Transponder, and Planning with Multi-Vendor Optical Design Tools.
My previous blog, Adding Alien Wavelengths, identified the potential challenges of managing a multi-vendor network. Historically, networks were deployed as a closed system wherein a single vendor provides the ROADMs, transponders and management platform required to manage the entire network.
Turning back the clock: The Challenge of Multi-Vendor Management
American telephone companies derived from the AT&T monopoly used a multi-vendor management platform called Telcordia OSMINE. This platform was conceived as a multi-vendor environment but in reality, the implementation was heavily customized to each equipment vendor. Integrating support to the OSMINE suite was expensive, slow and controlled by a single network management vendor. Multi-vendor functionality? Yes. Open? No. The times have changed. Today, multi-vendor management is predicated on open-source code, standard protocols, and open interfaces.
Current initiatives are focusing on the definition of standardized interfaces between the SDN management controller and the vendor’s equipment. The goal is to agree on a common model to represent the equipment, control commands as well as status information. A standardized message set is also defined to exchange this information between the controller and the equipment.
This blog focuses on some of the recent initiatives helping define these models as well as protocols between SDN controllers and equipment vendors.
Reference Model
Various reference models have been proposed and while the details may differ, conceptually they are all similar and represented by the one shown below.
Figure 1: Reference model for multi-vendor optical network management
Compared to the reference network diagram in my previous blog, this model adds a Multi-Vendor SDN controller overseeing the complete network. This single controller manages the ROADM network, transponders from different vendors, as well as other ROADM networks from different vendors operated by the service provider. It is multi-vendor and multi-domain.
Standard Interfaces: T-API and OpenConfig
Most of the industry effort on open initiatives has been focused on the definition of two set of interfaces: T-API and OpenConfig.
The T-API specification is led by the Open Networking Forum (ONF). The goal of this interface is to define a model to represent and manage the ROADM network. One important aspect is the assumption that the ROADM network as well as its local controller remain a closed system. The multi-vendor SDN controller uses T-API as a common language to control and monitor the ROADM network but it is not required to have a “deep knowledge” of the inner working of the ROADM network.
The OpenConfig interface is a lightweight set of models and interfaces to control and monitor the transponders. This standard was developed by a consortium of network operators operating data centers, wireline, and as well as wireless networks.
As SDN controller and equipment vendors increasingly support T-API and OpenConfig, it offers the possibility of deploying true multi-vendor SDN controllers in a simpler, faster, and more cost-effective fashion.
Value for the Service Provider
The value of a multi-vendor SDN controller is easy to understand: a single management platform that spans the entire network can bring consistency and operational efficiencies to core processes from service activation to fault management and most functions throughout the product/service lifecycle. In the case of alien wavelengths, integrated control of the transponders and the ROADM network makes management as seamless as managing a single-vendor network with only native wavelengths.
Another layer of management adds value but also adds complexity and costs. Thus, an important question to ask is this: Is it absolutely necessary?
The answer is not always. While some have implemented alien wavelengths using only CLI or a separate management system, more elegant yet simple solutions exist. If your SDN controller supports OpenConfig or can be modified to do so, you can add support for alien transponders so long as the transponder supports an OpenConfig northbound interface. Such is the case with the Fujitsu Virtuora Network Controller. This architecture is shown in Figure 2 below.
Figure 2: Multi-vendor optical network management with the Virtuora Network Controller
Telecom Infra Project (TIP) CANDI Proof of Concept
Fujitsu is an active participant in the Converged Architectures for Network Disaggregation & Integration (CANDI) proof of concept within the TIP (Telecom Infra Project) Open Optical and Packet Transport (OOPT) project group. This effort seeks to demonstrate control of a multi-vendor optical network with a multi-vendor SDN controller as per figure 3.
Figure 3: TIP CANDI Proof of Concept open optical architecture
The multi-vendor SDN controller used for this demonstration is the Fujitsu Virtuora® Network Controller (NC). The controller supports both a standard T-API interface for the ROADM network as well as an OpenConfig interface for the transponders. ADVA is providing their Ensemble Controller for control of the ROADM nodes, while the transponders being used are the Fujitsu 1FINITY™ T600 and TIP Cassini compliant devices.
This POC brings together network operators and equipment vendors to implement an actual end-to-end system using these new standard models and protocols. This allows the participants to test drive the T-API and OpenConfig standards and identify gaps and shortcomings.
As a result of this implementation and testing, the Fujitsu Virtuora Network Controller has taken a leadership position in the commercialization of a true multi-vendor SDN controller.
The next step in open optical networks
We have so far carefully tread down the path of openness and disaggregation by targeting only a subset of the network. Transponders are separated from the ROADM network and they are book-ended to avoid interoperability issues. We have introduced a multi-vendor SDN controller but the details of the ROADM network are still managed as a closed system supported by a vendor-specific controller.
The next blog will discuss a bolder approach to open optical networks: Open ROADM. This initiative goes one step further and provides support for a multi-vendor ROADM network as well as wavelength services deployed without the need to use the same transponder vendor at both ends of the circuit.
