Extending optical switching control to the legacy network
By JEFFREY G. VANZWOL, Elematics Inc. -- To extend interoperability to both legacy and next-generation equipment, an independent GMPLS control plane is needed as a proxy for legacy equipment as well as to bridge technological and operational differences with other systems.
To extend interoperability to both legacy and next-generation equipment, an independent GMPLS control plane is needed as a proxy for legacy equipment as well as to bridge technological and operational differences with other systems.
By JEFFREY G. VANZWOL
Recent articles1 have profiled the first two evolutionary stages of optical networking equipment. The first stage, spanning 1988-1995, saw the introduction and deployment of SONET/SDH equipment in carrier networks. The second stage began around 1995 with the advent of WDM. It's now common in the telecommunications industry to refer to such network equipment as "legacy" or "established." While these established networks remain useful and reliable, they are constrained by some significant limitations.
• The lack of automated interfaces to inventory management systems creates a reliance upon manually entered records, which can be outdated and full of errors.
• Provisioning an end-to-end connection through the coordination of multiple vendor-specific management systems is a manual, operationally expensive, and-error prone process--typically taking weeks or months.
• Protection schemes--such as linear and ring--are static, must be determined during network design and circuit assignments, and reserve high volumes of network capacity for protection.
• All configuration changes flow through Network Management Systems (NMS), which limit the scalability and manageability of the network, increase repair times by complicating alarms correlation and root cause analysis, and create synchronization issues between the transport infrastructure and Operation Support System (OSS) applications.
During the telecom boom of the late 1990s and continuing to the present day, a new generation of optical products have come to market. These next-generation products typically feature:
• High-density next-generation optical network systems comprised of optical switches (with combined add/drop multiplexing and digital cross-connect functionality) and WDM systems.
• Advanced signaling and routing intelligence delivers streamlined management, auto-discovers network elements and topology, simplifies network configuration, optimizes routing and path selection, provisions dynamically within seconds, implements mesh restoration techniques, and automatically reconfigures and restores circuits upon network failure. Standards bodies are making great progress in this area, but current implementations are still specific to each vendor.
The challenge: Integrating established and next-generation equipment
While next-generation optical equipment delivers unquestioned improvements in bandwidth availability and manageability, it's estimated that legacy equipment accounts for 95% of all deployed equipment in carrier networks today. The challenge for carriers--who are unlikely to replace all their existing equipment anytime soon--is to integrate next-generation equipment with their existing resources and bring everything under common management.
Typical network architectures that initially utilized next-generation equipment have an established access and edge network aggregating traffic onto a next-generation core network. As presented in Figure 1, a core optical network operating an embedded optical control plane only provides those benefits within the core network domain. The challenge for carriers is to extend the benefits of an optical control plane across all elements of their transport network, even when the established equipment may be a simple network element unaware of its placement in the surrounding network topology.
Additional challenges exist with propagating configuration changes (initiated by the control plane) up to the overlying OSS applications. Once an optical control plane is integrated with the OSS applications and operates (network-wide) over both the established and next-generation domains, the carrier receives the full benefits of an optical control plane.
Independent control planes to the rescue
An independent control plane is the distributed software solution that unifies control over resources and services across multiple network domains and multiple vendor products. An independent control plane adds intelligence to the transport network, providing dynamic control of dissimilar optical and transport network elements for automated, real-time provisioning. This includes a common signaling and control mechanism across photonic, optical, and established network elements in a multi-vendor environment. Carriers can deploy independent control planes in parallel with existing OSS applications and operator interfaces. By providing a mediation layer that brings dissimilar network domains into common management, the independent control planes can simplify equipment and OSS integration.
In the context of enabling a control plane over legacy equipment, independent control planes support optical signaling standards (i.e. the Optical Internetworking Forum's (OIF) User-to-Network Interface (UNI) and the Internet Engineering Task Force's (IETF) Generalized Multi-protocol Label Switching (GMPLS)) for its internal routing, signaling, and link management functions. Multiple levels of circuit protection for underlying network elements include unprotected, partially protected M:N mesh, and full 1:1 or 1+1 protection schemes. Open Shortest Path First (OSPF) routing, which computes the most efficient route for actions such as path selection, restoration, and protection, can be applied to any network topology.
When used to manage an established network domain, independent control planes provide uniform control to both established and next-generation hardware elements. Independent control planes are specifically designed to integrate network elements from multiple vendors. This enables consistent, advanced, network-wide control plane functionality within a multi-vendor network without disrupting existing operations or requiring forklift upgrades of legacy network elements.
Uniform OSS integration with network elements is provided, dramatically reducing the complexity of OSS integration while leveraging the advanced, real-time capabilities of the control plane for day-to-day operations. This uniform OSS integration can be applied to traditional functions such as Fault, Configuration, Accounting, Performance, and Security (FCAPS). One of the most compelling aspects of independent control planes is that OSS applications, supporting FCAPS functions, receive instant and accurate network state information. Deploying an independent control plane delivers immediate access to and control over resources and services across these multiple network domains.
Integrating the established and next-generation network domains
One of the most notable capabilities of the independent control plane is the ability to peer with adjacent next-generation network domains utilizing the OIF Network-to-Network Interface (NNI) interface. An independent control plane can peer with an OIF-compliant network and extend the control plane functionality (and it's operational benefits) over network elements under control of the independent control plane. The independent control plane is pre-integrated with established network elements that do not support automated control plane functions. The independent control plane utilizes traditional management protocols (i.e. TL-1, CORBA) to receive equipment status and provide instruction with the established equipment. Utilizing these protocols, the independent control plane manages the physical topology of the underlying network elements. Carriers can apply link attribute characteristics (such as cost, length, delay, and quality) to physical links. When provisioning new or restoring existing circuits, the independent control plane references these attributes, ensuring the application of the carrier's pre-defined circuit engineering rules.
Figure 2 shows the complete range of signaling mediation that could be supported with the carriers established and next-generation network domains. The following summary explains how each signaling interface is utilized by the independent control plane within a carrier network.
OIF UNI 1.0/2.0 Interface--The UNI interface allows UNI-enabled customer premise equipment to request and accept connections/bandwidth across both the established and next-generation domains of the network. As an example, a UNI-enabled router can signal a connection request to the independent control plane, and the independent control plane ensures that capacity is available across the established domain of the network. Once confirmed, the independent control plane will signal via the OIF NNI interface to the optical core network for capacity to complete the circuit. If end-to-end capacity exists, the independent control plane provisions the circuit across the entire network.
OIF NNI Interface 1.0--The NNI interface enables the signaling exchange between the independent control plane and an OIF-compliant core network to request the required capacity across either the established or next-generation domains of the network. The next-generation domain of the network could utilize GMPLS signaling with its network domain; however, it is not mandatory as long as the external NNI interface is complaint with OIF standards.
TL-1 or CORBA Equipment Interfaces--The TL-1 or CORBA interface is used to manage the established (non-signaled) equipment. Using this interface, the independent control plane queries the equipment for switch, facility, port, and time-slots status. Based on the information collected regarding the state of the equipment, the independent control plane uses this information to compute optimal routing and path selection. If a circuit needs to traverse a specific piece of equipment, then the independent control plane provisions the circuit by building cross-connects through all the affiliated equipment.
OSS Management Interface--The OSS management interface enables the independent control plane to receive provisioning and activation commands from overlying OSS applications. Additionally, other management information can be passed to OSS applications utilizing interfaces such as CORBA, TMF-814, or XML. This information could include physical and logical inventory, network topology, performance, and alarm/fault data.
The capabilities of independent control planes extend beyond typical provisioning and restoration functions offered by embedded control planes. Many of the functions supported by an independent control plane facilitate the unification of all equipment domains and integration of the overlying OSS applications. These functions include: multi-vendor interoperability, peering established equipment with next-generation equipment domains, overlaying control plane functions with established equipment, and vertical integration with OSS applications.
When carriers assess next-generation optical switches with embedded optical control planes, they should look beyond the basic selection of an optimal switching solution. They should expand the scope of their assessment to include a solution that applies all the efficiencies of an optical control plane to their entire network. Addressing the larger problem not only increases the success of the optical core deployment, but improves the operational and economic efficiencies across the entire network. Rather than implementing an optical control plane to achieve a 50% efficiency improvement in 5% of their network, the carrier should strive for a 50% improvement in 100% of their network. An independent control plane enables a carrier to extend the benefits experienced in the next-generation optical core across their entire network.
Jeffrey G. VanZwol is marketing manager at Elematics, headquartered in Beaverton, OR. He may be reached via the company's Web site at www.elematics.com.
1See "The Intelligent Optical Network: The New Foundation for Competitive Networks", by Jim Archuleta, CIENA Corp.