The Open Optical Networking Blogs, part 4
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.
Another level of disaggregation is emerging: disaggregating the transponder itself. This trend started in the switch and router markets where “white box” based hardware from a vendor can be paired with software from a different vendor. The evolution of the personal computer (PC) can help shed light on this parallel trend in open optical networking.
Analogy from the Personal Computer Market
What is the typical decision process when someone purchases a PC these days? Leaving aside the Microsoft vs. Apple debate, the consumer is not typically concerned about the operating software. A PC will run Microsoft Windows and a set of typical applications.
Much of the decision process is linked to price, capability, size and functionality. In the end, we decide to purchase either a desktop, laptop or tablet with specific processing power, memory and hard drive size. Maybe we have some specific needs for graphic capability or gaming as well but most of the time, we do not really think about the operating system that much. The commonality of the operating system allows consumers to switch hardware brands without worrying about retraining themselves, purchasing new licenses or even ensuring that all of their files and documents will be readable by the new PC.
This is the open environment the white box industry brought to the switching and routing market, along with potentially lower costs due to greater economies of scale, and this trend is slowly developing for the optical transport industry.
Transponder Disaggregation
This approach to disaggregation entirely focuses on opening a single device – the transponder. But in fact, buying a disaggregated transponder involves three separate purchase decisions: the hardware, the software and the pluggable optical interfaces (see Figure 1).
Figure 1: Disaggregating the transponder into software, hardware, and pluggable optics
The Telecom Infra Project (TIP) is at the forefront of this emerging trend where in the last few years, they have launched a series of projects: Cassini, Voyager, Galileo and Phoenix. Each of these project names are associated to devices offering a specific feature set.
TIP-compliant hardware, software and pluggable optical interfaces are listed on the TIP marketplace where users are free to browse the catalog and be referred to the individual vendors. Individual customers make their component purchase decisions by transacting directly with the vendor.
TIP Phoenix – 400G Transponder & Muxponder
The latest of these TIP initiatives is Phoenix. This project defines a 400G coherent transponder and muxponder providing the capability to multiplex 100G clients into a wavelength operating at a rate between 100G and 400G.
From an implementation perspective, how does a hardware and software manufacturer separately design hardware and software intended in the end to be integrated and provide functionality similar to a conventional transponder?
The answer again lies in establishing a set of standards to be independently followed by these vendors.
ONIE & TAI
Two key standard agreements were put in place to provide the framework used by both hardware and software vendors: ONIE and TAI.
The Open Network Install Environment (ONIE) provides a system installation framework allowing operating systems and software to be loaded, activated (“boot”), initialized and managed over a generic hardware platform. ONIE by itself is not an operating system. It is a standardized thin layer separating the physical hardware from the software’s operating system (OS). The advantage of this approach is that the applications and OS remain unchanged when changing the underlying hardware. Only ONIE is specific to the hardware. But the set of features and services that ONIE presents to the OS does not change, regardless of the hardware, so porting the apps and OS to different hardware platforms is very easy and no coding is required.
Figure 2: System architecture for disaggregated transponder
The Transport Abstraction Interface (TAI) genericizes the software’s access to hardware by abstracting its access into a common agreed upon set of API and messages. Figure 2 provides a high-level architecture view.
The hardware vendor provides the TAI adaptors. These are low-level routines that provide direct access to the hardware and a standardized API to the application software.
The applications, along with its own operating system, are provided by the software vendor. This software uses the TAI adaptor APIs to access the hardware, but it has no knowledge of the actual access method and/or address location of the hardware’s status and control points.
This approach emulates the PC industry analogy I used at the beginning of this blog. The transponder software becomes completely portable between hardware platforms just like how your favorite web browser works across platforms with no apparent difference in functional behavior.
Fujitsu’s TIP Phoenix Participation
Fujitsu is contributing the 1FINITY™ T700 hardware, software and a pluggable optical interface, and is currently discussing opportunities to integrate these components with other TIP Phoenix participants.
The Fujitsu 1FINITY Transponder software is an ideally positioned software solution. This product is built on Fujitsu’s strong legacy of operationalizing optical transport equipment. It provides a complete suite of optical transport features and it is already integrated with the Fujitsu Virtuora multi-vendor SDN controller used for TIP’s CANDI initiative.
Advantages for the Service Provider and the Industry
One of the main benefits of this disaggregation approach is to standardize operation around a common transponder software product. Training, procedures, operations, monitoring are all streamlined around a single software suite even if the underlying hardware is sourced from multiple vendors. This, by itself can provide great benefit to a service provider.
Again, this is similar to the PC analogy mentioned previously. Consumers can change their computer hardware by simply moving their applications and files to the new PC without requiring any retraining.
Integration into a northbound SDN controller is also simplified. The common transponder software has to be integrated only once with the SDN Controller and the addition of any new hardware vendor does not require any additional SDN integration effort.
Service provider have always expressed reluctance to change hardware vendors. The main reason is the cost associated with testing, training, procedure development and integration of the new hardware onto their SDN controller. Most of this transition cost is eliminated using this common software approach. This allows service providers to be a lot more agile in approving new hardware vendors.
Finally, unbundling the software from the hardware can speed up the development of new innovative hardware. New software-based features can be implemented relatively quickly; once the software and hardware development schedules are decoupled, the release date of one no longer gates the release date of the other.
Disaggregated Transponder Challenges
This approach introduces potential challenges with integration, testing, warranty and support.
So far, service providers have purchased complete systems and very few of them have the resources or the willingness to perform hardware-software integration and testing themselves. Someone along the supply chain is required to integrate, test and validate the behavior of the final integrated product.
The second challenge is “Who do you call when something goes wrong?” Service providers want a direct line to the system vendor to quickly answer questions and resolve field issues. The system’s separation into a separate hardware and software can complicate support, create delays and yes, generate finger pointing between vendors.
In this regard, the router and switching market is well ahead of optical transmission. The “white box” hardware market running third party software is being commercially used in that market and standard rules of engagement will likely be established by the time this approach becomes more widely deployed in the optical transport market.
The Last Missing Piece: Optical Network Design
The next blog will focus on the last missing piece: How do you design an optical network and estimate the reachable optical distance in an open, disaggregated environment? This is a critical part of the evolution of optical networks from closed, single-vendor systems to open, multi-vendor networks. Fortunately more than one multi-vendor design tool is now available to meet this challenge, which I will address in my next blog.
