The NFV approach does enable speed for innovation, but it may not be able to meet the high-performance requirements in some parts of the network. Even so, the ideas of openness and disaggregation are still valuable. As before, we can break up a closed networking device into hardware and software. Now the new hardware is a standard switch rather than a server, though. We can pick the generic switch that best meets our needs, and load onto it a best-of-breed network operating system for high-level features like routing, encryption, or management. We can later change the software without changing the hardware, or vice versa. We’ve opened the networking devices and set the stage for agility.
The optical network is another area that is ripe for disaggregation. Traditional optical networks have been implemented as closed end-to-end systems delivered by a single supplier. Now we’re seeing disaggregation, but it’s a little different from the previous cases where we separated the hardware from the software. In the optical domain we’re separating the two main building blocks: the terminal equipment and the open line system, or OLS. The terminal equipment includes transponders, muxponders, and wavelengths from devices such as routers. And the OLS includes components such as optical multiplexers and amplifiers. In this disaggregated model, enterprises and operators can buy the OLS from a separate supplier than they select for the terminal equipment. This approach has some of the same advantages as listed above, such as being able to work with multiple suppliers. There is another big advantage, however, that is specific to the optical domain: the rate of change of the terminals versus the OLS.
Optical terminals are evolving rapidly to provide higher connection speeds, better reach, and lower cost. The OLS evolves much more slowly, though, and often has a useful life of ten years or more. With disaggregation, we enable agility in the terminals without requiring changes in the OLS. This is important, because changing the OLS is expensive and affects service.
We’ve seen from the examples above that openness and agility are strongly coupled for networking infrastructure. How do we achieve agility in the corresponding software applications?
Once again, the cloud provides a useful model. In fact, one of the essential aspects of cloud-centric development has agility in its name: agile development.
We sometimes refer to traditional development as a waterfall model. This name comes from the appearance of the tasks in a Gantt-style chart. Each task is followed by its dependent task, which is placed below it and to the right. Stepping back a bit we see that the series of tasks looks like a waterfall.
The problem with waterfall development is that we define everything before we do anything. We build everything before we test anything. Then we test everything before we try anything in the field. And we try everything in the field before we show anything to the end user. All of this takes a long time. In the case of telcos, the development cycle could be years.