The Optical Provisioning Paradox

Comments
Print

The limitless amounts of bandwidth afforded by optical technology are curtailed by the difficulties of provisioning for it.

Providers need to be able to roll out and differentiate new services in a matter of days, rather than weeks or months, if they are to increase their profit margins with value-added services.

That ability has been hindered by bottlenecks in provisioning for voice, video and data-marred by the sheer number of network elements that reside in traditional circuit-switched networks. With overlays of multiple optical transport equipment-whether add-drop multiplexers (ADMs), dense wavelength division multiplexing (DWDM) systems, or digital cross system (DCS) switching equipment-provisioning can take weeks, if not months to complete. As a result, operators and providers have incurred high operational costs, exacerbated by manual processes and ensuing high error rates.

One of the main problems with traditional networks has been the exhausting and costly number of steps necessary in establishing end-to-end TDM circuits for SONET networks. "First, carriers have to ensure network capacity by evaluating inventory; then they establish and manage connections to activate the service; after which time they set up backup routes to meet QoS found in SLAs; and then they must test connections, and monitor circuit and network performance," says Robert Haim, senior product marketing manager at Polaris Networks, which specializes in multiservice optical networks.

Each of the aforementioned steps can take up to a week or more to complete. "Before activation, operators at each network segment must assess network capacity and reserve the required bandwidth for the new service," says Haim. He notes that determining end-to-end routes is a manual process encumbered by faxing, phone calls and written work orders that require copious amounts of supporting documentation. "Even after paths are defined, operators must provision each piece of equipment within each segment, and each ADM, access device, and each piece of switching equipment is configured individually," he says.

"The first metro hub operator had to provision its ADMs and DCSs by carving out an STS-x [synchronous transport signal] or other denomination to transport user traffic," Haim says. That step is repeated at each segment until the local central office for the enterprise completes provisioning. "Once the path has been provisioned," he explains, "it has to be tested to verify its operational state."

Until such provisioning headaches are resolved, service providers will not be able to charge effectively for bandwidth, a commodity unless SLAs are applied to differentiate services with superior service. That will require provisioning and reassigning bandwidth on the fly.

Enter Intelligent Optical Switching

Intelligent optical switching networks hold the promise of addressing the problem of end-to-end bandwidth provisioning at the optical layer. "These networks combine the functionality of SONET/SDH, the capacity creation of DWDM, and the ubiquity of IP and intelligence in the network to facilitate the same levels of service as SONET/SDH networks," according to Vaikunth Gupta, CEO and president of Wisor Telecom, which offers systems software for ordering, provisioning, interconnection and service ordering management.

By automating service activation and inventory management, switched-mesh optical networks-which run on top of intelligent optical switching technologies and distribute intelligent networking and management software-enable rapid provisioning, rerouting and automatic restoration of light paths without having to convert optical signals to electrical impulses and then back. The hope is that such networks will enable streamlined infrastructure from the edge through the core.

"The meshed network provides greater restoration path alternatives, leading to higher availability of the network," says Gupta. This capability is extremely important in the event of multiple failures. "In a meshed network," he says, "every element is connected to every other element through an intelligent software-based network operating system. Nodes communicate through multiple routes, broadening the range of services and applications delivered."

Despite the possible advantages, there are many complexities to provisioning for optical networks that affect service levels and the possibility of meeting SLAs and QoS expectations. "It's a paradox, in that optical technology opens up a world of opportunity with limitless bandwidth; yet provisioning for it is so difficult that service providers are burdened to turn service on within 90 days," says Julie Wingerter, vice president of strategy for NetCracker, which offers Web-based inventory management and provisioning.

OSS Minefield

While choosing an optical meshed network over a traditional architecture is a natural choice for a greenfield carrier, it may not be for incumbents and Tier 1 providers (see "Case Study: Looking Glass Networks").

"Optical meshed networks are manageable and realizable when you walk into a greenfield carrier that's starting fresh with a clean slate," says Stephen T. Parker, president and CEO of Eftia OSS Solutions, a service management provider. "However, when you sit on the other side of the fence, managing more than 1,600 OSSs, it's a different story."

The main challenge in automating provisioning for optical meshed networks, Parker says, is that it takes time and energy to get the service management piece, the element and basic network piece, the billing piece and CRM all glued together.

In traditional networks, operators could patch the problem with additional hardware, such as probes that monitor and analyze data transmitting problems with new edge routers or Layer 2 switches. However, advanced management technology does not yet exist for optical networks to possess automatic recognition when querying networks.

"Although the hardware guys have begun to embed sniffer-based technology, it's difficult to sniff optical fiber," according to Richard Whitehead, vice president of strategic technologies at service assurance vendor Micromuse.

Whether a service provider or a service assurance company integrating with inventory management or service activation companies, the challenge is the same: How to dip into everyone's databases, when everyone wants to retain their own inventory and databases. Service providers have to integrate both service activation and inventory systems to get the full picture for flow-through provisioning in optical networks. That big picture is difficult to realize in mesh networks, as there is an OSS minefield to negotiate.

"You lose a lot of functionality for redundancy and service-level metrics when you are trying to monitor a cloud," Whitehead says. "You can have a packet switch cloud that enables a provider to use optical technology at the core, and traditional technologies at the edge, with protocols running at the edge making it all transparent to the core and vice versa. But that becomes a big challenge for provisioning systems."

Multiple Management Systems

As networks become intelligent, element management systems (EMSs)-also called network management systems-have become the means for accessing managed network elements, as they allow for the ability to inquire about the state of the elements they manage. The EMSs sit at the element management layer (EML), above which is the network management layer (NML). Because providers have to deal with multiple technologies at the NML, they must be able to interoperate. In an IP VPN, for example, operators have to provision sub-networks, access networks and core, for such services as MPLS (multiprotocol label switching), optical and Frame Relay.

Each EMS understands its own domain, making it difficult for OSS vendors to abstract data and normalize that data, because of proprietary parameters and metrics monitored in each equipment vendors' signaling system.

Switch vendors have made an unprecedented push to unify the northbound interfaces of the EMSs, as evidenced in the TMF's MTNM (Multi Technology Network Management) Catalyst project. That effort will offer standardized interfaces among EMSs.

"Every time you have to create an interface between signaling technologies, you build a barrier to flow-through information," says Whitehead. "The QoS parameters for one domain are difficult to translate across a signaling technology, because by definition they are always slightly different."

In shared models, each vendor maps its own domain, so unifying proprietary functions end-to-end in a mixed network remains a challenge. "If you are figuring out how to have a hot standby router protocol over a meshed network, you usually need an overlay of a third-party management system," Whitehead explains.

"Often there is access technology and sub-networks technology, and then a core network technology, like DSL at the access level-or ATM at the sub-network level, not to mention the optical component in the core to provision all that end-to-end," notes Bruno V. Codispoti, repeatable solutions group practice leader with BusinessEdge.

Its NetEdge practice focuses on network management, activation and data collection for performance and multiple different network devices. The organization is implementing EMSs with Cisco, Lucent, Nortel, Ciena and others. "You have multitudes of EMSs due to different components, like metro optical rings and core optical rings," Codispoti says. "Even if they are from the same vendor, there may be different versions of EMSs."

As a result, companies increasingly are creating adapters that analyze the EMSs and networking equipment. "We get new cards off that EMS and implement that into our adapters so we can support new capabilities, which are rolled up into the provisioning interface we provide," says Ron Roposh, director of product management for optical with Syndesis, a provider of service creation and activation software.

"That means as soon as equipment is shipped, the customer can download information on updated message sets," says Whitehead, noting that this convenience offers a "profound value," in that network managers can understand code sets without having to grapple with thick manuals. "The more OSS understands data codes, the less unrecognized messages there are in existence."

Marrying Provisioning and Element Management

"A lot of companies claim to have 'end-to-end management' of their devices, but the devices are no longer the whole story," says David Kirsch, manager of applications consulting with Cisco. Rather, he says, there are two levels: network provisioning and service provisioning. "You have to explicitly marry your provisioning center to the element management center in managing optical equipment. Only then can providers take the process from upper-level order management systems and manage SONET private-line services." Cisco and other manufacturers are developing an optical strategy for enabling service providers to turn up new high-bandwidth, high-margin services quickly. The goal is to have fiber-optic networks that integrate IP and optical technologies.

An integral part of that strategy is support for MPLS and GMPLS (generalized multiprotocol label switching). As standards, they hold the promise of signaling unification, so optical switches can signal from one technology to the other, enabling interfacing to multiple element management systems. The multifarious nature of EMSs, coupled with the physical issues of cutting and splicing fiber, are making OSS vendors more reliant on equipment manufacturers.

In relation to IP routing, MPLS is being extended to offer a standardized common control plane for interoperability among optical networks. The goal is to simplify operations and management and offer a wide range of deployment scenarios ranging from overlay to peer, where the overlay model is realized by using just a subset of the functionality provided by the peer model. MPLS can be used with routers, legacy equipment (SONET, ADMs), and newer devices like optical switches. Some are hoping that MPLS will help equipment vendors unify signaling and work in conjunction with OSS.

GMPLS is supposed to offer enhancements to MPLS for routing and link management protocols. GMPLS is expected to bridge the gap between the traditional transport infrastructure and IP layers, making rapid service deployment possible.

Many OSS players are wondering what the Ciscos and Nortels of the world are going to decide in terms of MPLS and GMPLS adoption, since the protocols will weigh heavily on the interoperability and scalability of IP and traditional infrastructure. Many in the industry are waiting to see if GMPLS will be the key to enabling large volumes of traffic to move efficiently and cost-effectively.

Cisco, which developed "tag switching" (now known as MPLS), has driven the standard thus far. Its next release of its VPN Solutions Center will include support for provisioning MPLS, and it has begun working with U.S.-based WAN providers to build networks that will support GMPLS as well. "We will merge all functions under a single control point," says Kirsch. That will benefit VPNs and metro Ethernet providers that use SONET networks. First-generation SONET equipment is not built to deal with reconfigurations.

Kirsch says Cisco now has template-based configuration management that addresses issues for end-to-end optical provisioning. "With GMPLS creation, we've already demonstrated universal control and interoperability with competitors on optical equipment," he says. "Integration enables simpler, direct interoperability of routers when compared to the complex, traditional approach of layering IP on top of optical transport."

Whether GMPLS will be the final answer is yet to be seen. Kirsch and others believe it will be a year or so before GMPLS standards bring lower provisioning costs. "It first must happen in the transmission equipment," Kirsch believes, "because it has very discreet segments in which to test the technology. Then you have to migrate from prior technology to the more flexible IP-type technologies."

"Which one will they back? If they give the same answer, that will make a big difference to us," says Micromuse's Whitehead. "What standards, if any, and whether it will stop in the element management system in some proprietary format will be important in flow-through provisioning."

Increasing Reliance on Equipment Manufacturers

In the meantime, OSS players will have to become more heavily reliant on equipment vendors to provide that information. "There are so many assumptions to be made in trying to get performance data out of optical networks," Whitehead says. "It is up to [equipment manufacturers] to come up with the goods. They have a greater obligation to provide the data."

It seems that the optical switch community is stepping up to the plate, however, as it has been forthcoming and proactive-much more so than its IP routing brethren-in working with OSS vendors to streamline processes and get necessary data into OSS applications.

"The equipment manufacturers have been very accommodating with translation tables that help devices or EMSs report data about functions not normally found in messages. They are defining message sets before their devices go into production," says Mark Nicholson, CTO and vice president of product management at Syndesis. "In working with us, equipment vendors help us reduce lag times, since OSSs usually lag behind equipment vendors, because adapters have to be built at customer sites every time a vendor changes a technology or interface."

Such changes usually add multiple objects to the interface before an EMS ships to the customer. "Usually an operator has to pay an SI to manage the NMS [network management system] and change the adaptation layer to work with the box," Nicholson says.

Interconnecting with other ISPs or adding new equipment will depend in part on how much traction SONET, Frame Relay and SDH gain among optical vendors looking to come up with CORBA-based systems.

Whether it's CORBA or Java object models, the standards resolve interface problems. "But that is not the issue in slowing provisioning," according to Syndesis' Nicholson. "It's the way the boxes [network management systems] model various technologies that is important to the OSS managing them." He says that CORBA defines a way to talk to a box, but notes that the OSS has to understand the objects and functions within the box as well. "CORBA doesn't make that easier; it manages only 20 percent of the problem, as every box has different models and SLA parameters, or cross-connects, or bandwidth." While CORBA solves the problem of "hacking around in screens to provision a box," Nicholson says, providers still have to understand SLAs and map SLA information into the OSS. All of that has to be programmed into the OSS, which is where the bottleneck is, he says.

Accomplishing that will be easier for newer, greenfield companies than for incumbents heavily rooted in legacy systems.

Case Study: Looking Glass Networks

Looking Glass Networks is an emerging facilities-based metro fiber optic network service provider that offers SONET-based services, Gigabit Ethernet, and wavelength services, as well as flexible, fixed-cost dark fiber and carrier-neutral colocation. So far, Looking Glass has managed to turn up DWDM support in a little over 30 days.

Currently, the organization is in the midst of a six-month deployment of an OSS suite that includes an Internet-based self-care portal. The portal is designed to enable customers to place orders, see status and validate all activities that comprise service delivery through billing and invoicing, referencing accounts and issuing trouble tickets. The portal will also be integrated into customer and inventory databases.

According to Harold Teets, CIO and vice president, maintaining inventory is a high priority within the company. Teets suspects the greatest problem with accurate inventory will involve intelligent and non-intelligent network elements. In particular, elements that can't provide a status (such as fiber distribution panels, cables, manholes) will end up causing the most trouble in service turn-ups if they are not kept up to date.

Looking Glass selected Netcracker for its Web-based inventory management. Basically, this will allow field technicians to complete installations and repairs quickly, note inventory discrepancies and make rapid changes especially related to non-intelligent devices.

Teets also has developed a network element synchronization application that periodically or on demand inspects both the network elements and inventory configurations and provides alerts to any differences. Required changes can then be automatically made to the inventory system to ensure that the synchronization process is completed.

In addition to using Netcracker, the service delivery piece includes Cygent's order and task management solutions and Acterna's activation gateway and element managers to manage network components (primarily Cisco SONET gear).

Since the 30-day roll-out of DWDM did not include the fully automated design portion, these partners are working with Teets to devise configuration rules with the engineering team.

Other than systems and inventory, he says the keys to success will be strong operational and internal policies so that they can easily support network topology changes and add elements as marketing and engineering teams define new services.

Thinking Out the SLA

Currently, Teets is concentrating on integrating SLA information into the entire service delivery and service fulfillment pieces. That will be driven by events emitted through the network and service delivery task management. "In terms of SLAs, most agreements we have with our customers have a QoS measure relating to integrity of the network and the ability to deliver service."

He is keeping a watchful eye on MPLS and GMPLS, "which will affect us in QoS and policy-based routing." His stance is to utilize the protocols available within the element management domain and make use of the elements' 'path finding' capabilities. In cases where that is not possible, he and his team will build that capability into the higher-level OSS.

In addition to SLAs for network performance and capacity, the company also based them on how to turn up services in the agreed-upon intervals. However, as a growing network provider, there is a need to use type 2 (partially off of the network) services from other providers, "and there, we are dependent on some form of carrier or trading partner meeting its commitment."

"We deal with incumbents that have older technologies and information that is out of synch with their inventory; therefore, we are at the mercy of the CLECs and ILECs, and their ability to deliver on their agreements," contends Teets.

Teets wants to maintain the control and the ability to alter quickly." If we have to change a bandwidth rate, we don't want the difficulties of going through another provider," says Teets.

"We can work with trading partners and establish levels of interaction for turning up service with ILECs and others, but maintaining inventory for internal use and use with external partners transparently is of paramount importance," he says.

Comments