Searching for 'Friends and Family' in OSS

For a sector to flourish, it needs some feathers in its cap. Where the OSS sector is concerned, let’s just say Yankee Doodle’s on his pony, but the only thing stuck in his hat is a price tag. Although the billing sectorhas paraded MCI’s “Friends and Family” campaign around for years as the poster child for what billing systems can do for the front end of the business, OSS vendors haven’t had the same kind of success story to tell. One golden ring everyone’s been reaching for is flow-through provisioning. But very few service providers are willing to tell success stories about OSS, because the functional and architectural achievements that can be so critical to competitive differentiation are so closely held.

What provisioning is, and when it can in fact flow through, are questions that lead to either confusion or disagreement (see, “What is Provisioning, After All?”). The industry doesn’t always agree on what makes provisioning provisioning. When we look at service providers such as Telseon and the advanced capabilities it has developed, we may be seeing the OSS world’s “Friends and Family”—even though Telseon chose to build everything in-house.

Flow-Through Telseon Style

Telseon’s achievement must be kept in perspective, because the company was able to start from scratch with its technology base. It never faced a legacy network challenge, nor does it deal with circuit infrastructure or local loops. Telseon owns DWDM rings in metropolitan areas and offers wavelength, Gigabit Ethernet and IP services to enterprises, or other major service providers that offer services over Telseon’s metro rings. According to Telseon, it chooses network technologies that could provide high-performance services for a relatively low cost from vendors such as Riverstone Networks and ONI, which embrace openness and aren’t catering specifically to the old guard.

In Telseon’s words, it wanted to “break the bandwidth bottleneck.” This basically means it wanted to create a bandwidth service that takes advantage of network intelligence, allows users to create virtual connections dynamically and does so in a minimal amount of time without human intervention. Telseon knew that a strong OSS suite was going to be critical to its business goals: creating a new market for bandwidth services by improving service delivery and simplifying the underlying network, all of which would in turn reduce its cost base.

But keep in mind that this was three years ago, prior to the Gigabit Ethernet bandwagon, when the OSS market was mostly focused on provisioning voice, ATM and Frame Relay services for various kinds of LECs. When Telseon looked to the OSS vendor community, it found them “focused on the wrong audience,” says Jay Gill, director of product management for Telseon’s IP service. “We didn’t have any confidence that a third party could really get us where we wanted to go. Plus we were small in the beginning, so it was hard to get anyone’s attention.”

So Telseon developed a flow-through provisioning platform with its internal staff, which comprised telco, IT and data world veterans—with more than 50 patents among them—and its software engineers, many of whom had learned the ropes at 3Com.

An Architecture for Flow-Through

Telseon’s folks emerged two years later with the capability to achieve flow-through provisioning. To achieve this, they recognized early on that a completely accurate view of network inventory resources was necessary. They started with a SQL database to represent the network topology, configuration and specific customers’ service parameters to derive a complete view of the network and service offerings as they relate to each other. Telseon calls this component its Service Manager. Integrated with the Service Manager database is what Telseon calls the Capacity Analysis and Tracking (CAT) application, which handles provisioning and capacity management rules and performs capacity tracking and analysis for auto-designing and assigning connections. The Service Manager and CAT are in turn integrated with a distributed activation component, built on COM and DCOM, which communicates with software agents built into the network elements. (see “Riverstone and Element Management,”).

The User Perspective

Telseon’s flow-through functionality is exposed through a simple, wizard-style Web interface geared toward an everyday user, not a network engineer. It walks the user through the provisioning process, prompting the user to enter a location, select bandwidth and any special QoS requirements, and assign ports. With the entire network modeled accurately in the inventory database, extending access to users becomes a matter of setting permissions that make sense so the user can only choose from the set of options that work for his location and his level of access, or permitted level of control over the service set. Permissions range from full administrative capability to basic ordering of connections to specified locations.

The wizard breaks down the provisioning process into several steps. First the user names the connection he or she is creating, then selects a metro ring from a drop-down box of options. Naturally the user sees only those rings to which his company has access, or a subset based on the specific permission structure. Once the ring is selected, the user can click a check box to note the connection type, including point-to-point, point-to-multipoint or even multipoint to multipoint,
if the network infrastructure and user permissions allow it. The user then uses a drop-down menu to select the “line rate” for the logical wire being created, and another drop-down to select the specific service locations on the ring where the wire can terminate.

Once the service location is selected, users don’t need to wander through lists of ports: they are presented with a list of only those ports that are available for assignment and can support the requested service. Further, the system can enforce its own load rules—there could be a port available, but assigning it could violate a capacity threshold or network diversity rule, and thus it would not be presented to the user as an available resource. Telseon allows its customers to select their own ports in order to accommodate their own redundancy and route diversity concerns (many customers are either large users such as enterprises, or large resellers).

Once the ports are selected, the user clicks a button and the connection is generally created in about 10 seconds. Connections can be completely reconfigured and reassigned in the same amount of time. The whole process—from naming the connection to activation, even for a user who’s only minimally familiar with the interface—can take less than a minute, depending on how fast the person works, not how fast the application or the network responds.

Behind the scenes, when the user submits the port request, the CAT application communicates with the activator and the Service Manager to create connections, establish fail-over paths and configure QoS. The CAT looks at the changes to the network the user has requested through the Web interface. It discovers the best path for the virtual wire being created and also allocates a full reserve path to provide seamless failover. It then tells the activator to communicate with the network elements to create the virtual wire and its backup. As the network changes are made, the service manager is updated to reflect the change in available resources and network configuration. When the user is finished with the virtual wire, if he didn’t set a time limit during the initial provisioning process, he can go back into the Web interface, click into the connection’s home page from a menu, and disconnect it with one click. This will tell the activator to disconnect the virtual wire and will restore the network resources to an available state in the service manager database.

This is an example of simple but capable technologies that provide robust, automated services upon the customer’s request. Nothing is proprietary or esoteric, and there isn’t a 43+ megabit difference between a large bandwidth pipe and a small one—Telseon customers can order basically as little or as much bandwidth as their specific network permissions allow. The slowest part of Telseon’s provisioning process is getting a customer on-net initially. If the customer already has a local connection to a Telseon collocation, the customer can be on-net within hours with a simple cross-connect. Otherwise, the Telseon customer will have to order a local access pipe from a LEC and wait.

Do-It-Yourself OSS

At the time Telseon rolled out its homemade OSS suite, it found it agreed philosophically with what vendors had begun to bring to market. The suite, as mentioned, starts and ends with an accurate inventory store that uses an open object model to store and correlate information. Provisioning tasks are driven and validated through that store before being sent to the network. Customers, services and physical network elements are all correlated to provide better information for trouble management, customer care and sales. Users, whether end users with basic permissions or full-permission customer care or provisioning staff, see a Web interface that intelligently presents only the processes, data and options that apply to the specific user for the specific task being performed.

In a highly abstract sense, the process lives in the OSS suite. Only those aspects of the process that require a human to make a choice are exposed through the user interface. These are the same kinds of ideas and designs that are coming out of the vendor market. The biggest difference comes in the technologies used to bring the philosophies to life. Most inventory and provisioning vendors are using Java 2 Enterprise Edition (J2EE) specifications and Enterprise Java Beans (EJB) technologies, as well as Oracle databases, Oracle 8i being the current big dog. Telseon uses similar concepts, but isn’t specifically a J2EE or Oracle shop.

The question is why there aren’t more stories like this one coming out of the service provider market. More importantly, why aren’t there more stories like this coming from vendors?

First, there’s the issue of legacy systems and networks. Telseon had the luxury of building to a greenfield environment, and showed that efficient provisioning
is possible in a modern network. Most service providers are dealing with legacy systems and a copper network infrastructure that requires manual attention, so they may be years away from being ready to pursue flow-through provisioning.

Beyond legacy challenges, however, lies a much greater issue: confidentiality. If vendors succeed in deploying flow-though provisioning for a service provider, they often can’t talk about it. OSS is critical to competitive differentiation, so off-the-shelf purchases remain confidential, because they are repeatable. When service providers pull off IT miracles, the sagas go largely unsung. Telseon can afford to voice its accomplishments, because it succeeded with a massive in-house effort that can’t be duplicated easily. OSS vendors have made an effort to make their products and preintegrations simpler to deploy and more repeatable. While service providers benefit from repeatability in terms of cost, the prospect of competition frightens them—especially Bell veterans who remember the days when everything was proprietary and monopolistic. It’s likely that OSS has had or will have its own “Friends and Family,” but whoever pulls it off is likely to do so under non-disclosure.

What Is Provisioning, After All? The confusion and disagreement start with the fact that provisioning, activation and flow-through provisioning conflict in nomenclature. But all of them have some relationship to turning a collection of complex boxes into a network that delivers services, so it’s a matter of deciding which name goes with which set of functions. There are two general ways to look at provisioning. There’s provisioning for now and provisioning for the future. Provisioning for the future is mostly related to network design. This is where the underlying network—the backhaul and facility circuits over which services run—are recorded in the network inventory database. Provisioning in this case refers to representing that physical build in the network database, a process which never really stops as long as a network continues to grow and add capacity and subscribers. Provisioning for now means activating services over the infrastructure to deliver service to customers. A good example would be an IP service activated over an ATM backbone, or even an ATM service activated over a SONET backbone. From an OSS user perspective, the difference is whether one is designing network infrastructure into the database, or looking at the network resources available and changing their state to reflect a service that will be delivered to a specific customer. In this case, a mid-level provisioning technician might be creating simple IP VPN connections over an ATM backbone, whereas only a few, high-level network engineers would be performing the infrastructure design tasks that put the ATM backbone in the network inventory in the first place. What all provisioning, according to this definition, has in common is that it involves the processes by which changes to the network state are represented in the inventory database. Activation can be defined as actually making the changes already in the inventory database on the network itself. During provisioning, all of the steps necessary to deliver a service are identified. Many of them involve coordinating the activation of synchronized network resources—ports must be activated, multiplexers told which channel to carry certain traffic on, IP addresses assigned and so on. Activation means sending commands to individual pieces of equipment on the network to perform specific functions that will collectively exist as a service. In short: this is when you actually flip the switch. Flow-through provisioning has come to describe a scenario where provisioning and activation have been engineered to such a high level of automation that all the steps necessary to deliver service can happen automatically after minimal user input. Ideally the user should enter an address, select from a list of services and have the rest take care of itself. In many cases true flow-through is impossible, because physical connections must be made, such as actually connecting a jumper for a cross-connect, or connecting a copper pair to a distribution frame. In newer networks that employ more automated gear, such as DWDM, Ethernet and IP networks, flow-through has been achieved with some impressive success.

Riverstone and Element Management Riverstone Networks is a publicly traded mid-cap that has managed to thrive despite the dot-com disappearance. It is one of a new breed of data-world network element vendors that’s bringing added intelligence to the table with its network gear. Riverstone provides Telseon with a “hardware-based router optimized for metro-environments, similar to what Juniper is doing in the core,” explains Steve Garrison, Riverstone’s director of corporate marketing. Its routers provide both the Gigabit Ethernet and IP services for Telseon’s network, all of which rides on a DWDM backbone built on gear supplied by ONI. Riverstone’s metro router is delivered with a C-code layer, an API that sits on top of its hardware hooks that Telseon has integrated directly to its activator application. According to Garrison, Riverstone’s API is bolstered by a software developer’s kit (SDK) it has maintained for more than two years. Much of the initial work to develop this SDK and the APIs was done with Telseon and has since been expanded. Garrison says that although the en vogue thing is to have an XML interface, service provider shops have C skills in-house and are comfortable building interfaces to C applications. Another feature Riverstone provides is an increased ability to collect and move data related to router traffic and usage without slowing down the gear. Riverstone distributes small data collectors on every point and line card, and uses a special protocol to send data from those collectors to other servers, such as billing systems. The protocol uses TCP for reliability, as opposed to NetFlow applications that use UDP. The latter does not support error correction or retransmission and is arguably not reliable enough for delivering revenue-critical usage data. Riverstone relies on Xacct for billing mediation functionality to turn its usage data into NetFlow or other records.