How open standards in optical networks lead to desired business outcomes
For years, IP networks have used open standards that have been successfully adopted by multiple vendors and deployed at massive scale by network providers worldwide. On the other hand, optical networks have largely been single-vendor, since many of the core capabilities of a photonic line system including planning, performance and basic telemetry were dependent on vendor-specific software control architectures. In addition, the management interface for both the transponder and the line system was delivered as a single integrated system together with the planning tools, making it difficult to introduce another vendor into the overall solution.
That is changing.
Two fundamental developments have occurred which have now opened optical networks up to multi-vendor deployments:
- Domain controllers are using open APIs to enable single-pane-of-glass optical service planning and management across multi-vendor infrastructure, with new levels of automation.
- Standards-based deployment models have driven greater flexibility in open transponder and open line system network architectures.
Identifying business goals
The introduction of open standards, and the ability to deploy multiple vendors within a common optical infrastructure, is the starting point for the ultimate question: ‘How can I use this openness in optical networks to achieve the strategic and business goals of the company?’ Every reader of this blog will immediately provide an answer that fits their corporate objective. Responses will likely include some, or all, of the following:
- Hardware cost reduction by introducing multiple vendors that compete for the business, especially the transponders which are the volume components contributing most cost
- Immediate access to the latest optical innovations
- An open platform for multi-layer integration, ensuring longevity of the multi-layer software investment
- Business continuity through supply chain diversity for DWDM transponders
There are many variants on the above responses but if you look at each in turn, they have one common element – the introduction of multiple vendors will require more software integration testing by the service provider (and higher costs in this area) than in a single-vendor solution that has been fully verified by the vendor. Fortunately, architectural tools are available that can help right-size the required amount of pre-deployment testing of a multi-vendor solution with a well-defined business objective.
The need to balance openness with cost of interoperability
None of the business objectives identified above were ‘Our plan is to introduce an open interface for each specific part of my network and then make huge investments in time and money trying to integrate all those open APIs into a deployable solution’. That would be counter-productive!
There is an important difference between an architecture which defines all possible dimensions of openness and an implementation which is aligned to business objectives enabled by an open strategy. The following axiom is useful to remember when implementing an open solution: ‘The more open interfaces you have, the slower and less agile your implementation’.
The more open interfaces you have, the slower and less agile your implementation.
No amount of standardization will replace network interoperability implementation testing. Every network operator has unique requirements for geo-redundancy testing, feature and functionality testing, security testing, etc. In addition, no networking standard is truly ‘plug and play’ – although certifications do help. Fundamentally, the more points of integration introduced into a solution, the more testing, release alignment, user training and other ancillary tasks must be performed prior to deployment. Each time a new release is to be deployed, the full cycle of testing must be repeated, further driving costs, and slowing deployment velocity.
This does not mean open networking cannot be deployed; however, it does mean that a focus on business objectives to guide the implementation will pay back hugely when moving from the lab to production.
Assessing the trade-offs
Let’s use an example from our previous goals to illustrate the point.
- Business goal: Business continuity through supply chain diversity for DWDM transponders
- Technical requirement: Introduce another vendor’s transponder over an existing Open Line System (OLS)
Figure 1 shows two potential open optical implementations which are equally capable of achieving the business and technical objectives. The choice of the implementation will drive the cost and velocity of deploying the solution.
Figure 1: Trade-Offs of Different Open Optical Deployment Models
The open deployment in ‘Model 1’ has four open interfaces from the Optical Domain Controller, one to each of two transponder vendors, one to the Open Line System (OLS) controller and one to the open planning tool. This model will provide all the dimensions of open interoperability required by the business objective. The alternative shown in ‘Model 2’ is much simpler and focuses on the open interfaces required by the key business goal (open transponder deployment) and leaves the remainder of the architecture as a vendor integrated solution. Both models meet the business and technical objectives. The trade-offs are obvious – one model has significant systems integration costs and timeline challenges whereas the other model opens up key dimensions of the network, while controlling timelines and costs.
Intelligent network control pulls it together
Software control architectures have evolved to the point that multi-vendor infrastructure elements can be controlled cohesively, with increased automation. This has broadened implementation options while maintaining a unified management interface. Both models above require an Optical Domain Controller with open APIs to automate multi-vendor lifecycle operations. Yet the functionality of the Domain Controller in Model 2 is much more expansive, eliminating the need for time-consuming and costly interoperability testing. Such capabilities build on Software Defined Networking (SDN) industry standards with additional advancements for integrated planning and analytics, bringing intelligent network control to optical operations.
Open standards in optical networks are essential for continued progress as service providers seek to satisfy market demands while meeting business goals. There is no single solution which will satisfy every deployment; however, asking the right questions up front will ensure the delivered business outcomes are the ones you want.
