The historical context around how optical networks have been designed and deployed provides much appreciation for why new requirements (for example, efficient and timely provisioning and management) and services (for example, on-demand services, CoS, communities of interest) are prevailing challenges today. New network requirements invalidate the assumptions upon which legacy networks were founded. Indeed, the communications networks that exist today were designed primarily for private-line and voice service using circuit switching. Capacity was portioned out in 64-kbps pieces (the size of an uncompressed voice channel) using multiple layers of hierarchy. Typically these networks required several months to deploy a service. This time frame met requirements then because the traffic demand was quite predictable and assumed to remain static for years at a time. As the business case for providing data services became attractive, service providers retrofitted their network typically by yet another layering of protocols to support multiple data-service interfaces and networks, including ATM, Frame Relay, and IP.

Layering became an issue as data services became the predominant service relative to voice and private-line services. The unpredictable nature of data traffic as well as its flow-direction uncertainty and continual changes invalidated initial assumptions for voice networks. Procedures to provision services, reserve new bandwidth, or change network parameters to address growing traffic volumes or meet customer demands across the network over multiple protocol layers are time consuming, administratively difficult, and workforce intensive. Overlay networks require management of their different layers, such as the IP and ATM layers, as though they are separate networks. Intelligence can be implemented for some layers but is limited to the specific layers where it is implemented. Layers do not communicate with each other, so management and scalability of the network are compromised. Disparate technology layers also limit the ability to engineer traffic to maximize network and resource efficiency and avoid points of congestion. Functions are often duplicated, and network management and control algorithms can even work against each other in a layered protocol network, creating conflicts and oscillations. And restoration, performed in varying time scales across multiple layers, is uncoordinated and in most cases resource inefficient. Additionally, complications of tunneling the protocols of one technology over another results in inefficiencies due to framing and packet overhead, multiple instances of sometimes-conflicting functions, and the inability to optimize based on desired service granularity.

Obviously, a more dynamic and cost-effective network model that provides on-demand set-up of a wide range of differentiated Cisco COMET services and the ability for each class of traffic to be defined and treated appropriately is needed. To help service providers sustain profitability though automated provisioning and optimized delivery of optical services, Cisco UCP technology offers a means to address this overarching need for a more dynamic and cost-effective network-control model. UCP can help carriers to increase profitability by specifically addressing the operational expenditures (OPEX) associated with the deployment and management of services over multiple technology networks. Not only will UCP technologies help carriers reduce their OPEX cost, but UCP will also enhance profitability for high-capacity traffic transport by enabling carriers to deploy new, value-added Cisco COMET services and do so very quickly to market. The new UCP–enabled optical network needs to provide the foundation for delivering an emerging, yet-to-be-defined portfolio of optical services.

On the transport side of providers, UCP is seen initially as a means to tie together multivendor domains through the use of O–UNI. Desired here is one method of access to provision across the entire optical transport network, despite having multiple domains of different vendor equipment. Figure 7 illustrates this concept of provisioning across multiple-vendor domains within the transport network. Longer-term, transport architects realize that UCP has a broader and more significant meaning to service providers.

Here, GMPLS represents a standard protocol for optical transport network elements. Providers welcome the move from proprietary protocols to open, standards-based protocols. Standards-based protocols will allow providers substantial cost savings by enabling them to introduce any vendor equipment into any given domain. A best-of-breed strategy traditionally has not been available and has been denied by those trying to "lock in" the provider in using its equipment at great cost to the provider. GMPLS is also sought in the transport because of its IP–like features, such as self-discovery and dynamic optimization and provisioning. Transport providers see the combination of the O–UNI and GMPLS protocols as a way to facilitate a seamless evolution to next-generation technologies without having to upgrade or replace network equipment. Service providers understand that GMPLS may not exist in all Cisco SONET/SDH products from the start. They are, however, interested in seeing the path toward GMPLS, because this represents to them Cisco's commitment toward standards-based technologies.

Figure 7. Provisioning Across OTN with Multiple Vendor Domains