Getting to VoIP with MPLS-based VPNs

In the past 18 months, MPLS-based IP VPNs have become the hottest product in the business space. Not until VoIP became a reality did carriers see a reason to shift from TDM networks, or to migrate from ATM and frame to IP core networks. The key to that reality is the fact that MPLS uses label switching and tagging of packets to enable class of service (CoS) differentiation over one pipe. This allows packets to be tagged for routing priority, rather than moving by "luck of the draw" routing, so that IP video, or CRM or ERP traffic can be separated and tagged for differentiated services for which carriers can charge premiums.

Besides facilitating next-gen services, MPLS backbones offer a mesh network, which fosters any-to-any connectivity-thus enabling greater economies of scale than were possible in the layer-one and -two, hub-and-spoke packet WANs of the past.

Even greater economies of scale will be possible once carriers expand their softswitch footprint, or partner with third parties, to obtain worldwide connections. "Right now, everyone is jumping through hoops to tie MPLS IP VPNs to their frame and ATM networks; they need more connectivity and more trust in the encryption and security of the Internet before substantial savings are realized," observes Leslie Turkson, senior manager at Cap Gemini.

Consequently, most operators are getting their feet wet with some form of MPLS-based VPN. Most have rolled out network-based IP VPNs provisioned over the carrier's MPLS network. Carriers are either offering it as a feature on ATM or frame services, with IP-enabled connections tied into the MPLS VPN, or providing CPE-based VPNs over the Internet. Although a few, such as Equant were able to leapfrog ahead because they do not have ATM or frame relay investments to protect.

Whether leveraging the Internet or their own networks, the main driver for linking up remote offices is cost reduction.

"In the past, we'd have to provision permanent virtual circuits [PVCs] among all locations to enable end-users to talk to data centers or headquarters," says AT&T's Rose Klimovich, vice president of VPN and advanced network services. Klimovich notes that MPLS has put AT&T on a path to convergence, bolstering its "concept of one," which promotes convergence on such products as its eVPN, a network-based IP VPN. "Having MPLS fosters convergence on one platform so systems, services and networks all come together," she says. "That is something that cannot be ignored, regardless of the initial costs to change out networks and systems."

Those costs revolve around migrating from TDM to VoIP, which requires a move from class four and class five switches to a softswitch environment with an IP core.

Because many large companies already put voice traffic over WANs when connecting branch offices, MPLS is expected to advance a natural evolution toward VoIP.

"Everyone knows they will get there, but how is the question," says Mark Kaish, vice president of next-generation solutions at BellSouth, which has approximately 450 customers on its network-based (layer three) VPN. Although upgrades to VoIP can cost end users $600 to $1,000 per station-for the VoIP phone, the LAN, QoS on the LAN, additional equipment and bandwidth-"everyone is asking about it," he says. BellSouth is about 70 percent finished with expanding its footprint of softswitches in preparation for VoIP.

"We are dying to 'pull the trigger' on four classes of service," says Kaish, but the holdup is the equipment: "Despite the hype, the router vendors don't have the code yet." In the meantime, BellSouth is creating submodules in its OSS to handle new pricing rules, so that features can be plugged into routers, and new tags and packets (flows) can be recognized. Kaish expects to roll out the CoS premium offers in the next six months to a year.

He says BellSouth, as it expands its footprint, will benefit from the fact MPLS IP VPNs are access-agnostic. "Because IETF standards dictate they be cross-platform in nature, we will be able to mix and match access based on the requirements of each of our customer sites-meaning some locations can be frame, some private line, others metro Ethernet or even DSL," says Kaish. That mixing and matching of access types will help BellSouth and its customers to gain economies of scale when linking up disparate sites.

That's a big change from the past, when frame sites had to talk to frame sites, and ATM to ATM. With MPLS IP VPNs, enterprises hope to mitigate the inter-networking headaches of linking up private lines. Though Kaish thinks the capabilities are there, "customers sometimes don't size their LANs right or put enough QoS on the LAN. "Because you are higher up the OSI stack, there is retraining that has to take place. In frame and ATM networks, there was just physical and logical connectivity through the switches, but in IP, the carriers control the IP plane for the customer," says Kaish.

To do so successfully, carriers have to proactively monitor the capacity in the core of the network as services are added on. Provisioning and configuration has to happen at the edge, which requires visibility into the traffic, as paths and bandwidth can no longer be allocated on a service-by-service basis.

Visibility in a dynamic network will require an evolution in the management of the physical network elements, the management of the VPNs themselves, and management of control plane, which correlates equipment failures with events taking place in the control plane.

From Static to Dynamic

As carriers move to a dynamic environment, the entire OSS layer above the network has to become dynamic as well.

Before IP VPNs emerged, the service, the network topology and the elements existed as one entity. "Most of the network was ATM or TDM, and network technologies were unified end-to-end, as elements came from a single vendor for technology and service," notes Sharon Barkai, Sheer Networks co-founder and CTO. "That meant 1:1:1 correspondence among services, technologies and elements."

"That 1:1:1 of paradigm made it simple to reflect 'static' configurations from one point to the next, since every hop of the path of a SONET or TDM network was recorded," adds Miki Zevadi, vice president for marketing and business development at Sheer Networks.

Since each hop generated information about what equipment was needed for a customer order, there usually existed a large inventory system with recorded configurations of every circuit in the network.

"The difficulty with IP is that the network will dynamically adjust to changes in traffic flows, or congestion or router difficulties, so paths are not known between end points," says Andy Fraley, CTO and co-founder of Comanage.

In an IP network, operational mistakes can stem from differences in the "as is" state of a network as compared to the "as intended" state, explains Fraley: "If you activate a three-leg IP VPN and one leg of the activation fails because an IP router is temporarily offline, then there could become a difference between the three-legged VPN the carrier 'meant' to provision and the two-legged VPN in the network."

That means carriers must have inventory systems that track the "as intended" state so that it is never lost even if there is an activation fallout or a network failure.

While there are fewer configuration points to manage at the edge of an IP network, troubleshooting requires tracking traffic through a certain path, but in IP, that path changes hour to hour," notes Hugh Kelly, CEO of West Ridge Networks, whose systems are supposed to create a common system that links together the customer- and service-level interfaces and tools so carriers can drill down into the label switch path to see the path of physical connections. "With integration and correlation of customer-facing systems and the network, you know what is happening to determine if SLAs are being met," says Kelly.

The ability to validate an MPLS IP VPN is particularly important in terms of pinpointing a failure, whether it is a problem with customer premise equipment, core equipment at the service provider, or even leased lines.

"From a management perspective, it is important to do more than just re-route the VPNs and get LSPs running. If the quality suffers, there needs to be a way to move up a level and monitor not only the control plane, but the data plane [forwarding plane] as well, so that there is some indication of what the customer experience has been," notes Matt Ellis, director of network technologies for Micromuse, which is evolving its service assurance and fault management capabilities to accommodate the unique challenges of MPLS.

Of course, if a failure is not detected, the CoS and QoS capabilities won't exist as they are supposed to in a VPN. "If the LDP fails, there won't be label switching and tagging of packets-and that, after all, is what MPLS is all about," says Ellis.

"Similarly, if there is an OSPF failure in the core, the network-though operational-will not advertise packet routes across the network."

In other words, it may appear to traditional management systems that the network is operating, but the customer traffic will not be entering and transitioning the core.

Therefore, it is paramount that carriers be able to not only re-route the traffic, but measure the quality of service at the same time. "If a customer claims there is a protocol failure causing their label switch to be re-routed to the core, which then causes congestion in that part of the network, the carrier has to know where LSPs run across the network, and where there is degradation in QoS in the VoIP service," adds Ellis.

To see which devices are operating in customer VPNs or running on the carrier's core network requires visualization through GUIs that depict what devices are supporting what VPNs.

"We've just recently gotten a patent for tracking topology and changes within networks when validating VPNs with our Precision solution. That topology is then related back to information from Micromuse's OMNIbus solutions, thus enabling carriers to correlate physical failures to root cause analysis," says Ellis. Additionally, Micromuse is creating a single interface for integration with troubleshooting tools in OEM products, intended to enable carriers to log on at any moment to see directly into the routers and switches.

In addition to managing the physical elements of the physical network, there needs to be a way to assess to which MPLS control plane events equipment failures can be attributed. That means an emphasis on the management of the control plane, in addition to that of the physical elements, if carriers are to correlate failures at the physical level with the events taking place in the control plane. That is challenging because of the sheer amount of protocols used to establish MPLS IP VPNs, such as ISIS, OSPF [open shortest path first], BGP, LDP (label distribution protocol), RSVP-all of which exist above that physical layer.

At the core of the control plane are the forwarding tables, which reside on premise equipment routers. New equipment has to handle a "new notion" of a forwarding table, which hold the destinations that can be reached on a VPN. They are loaded into all edge routers in carriers' networks, creating yet another element that carriers have to manage. But if you choose switches that provide instrumentation for forwarding table control, carriers can gain an understanding of what goes in and out of their networks without adding complexity.

Equipment routers will, therefore, have to possess dynamic interfaces for changing and manipulating tables which determine the destinations of various types of traffic.

To enable carriers to drill down into the network to see the status of various VPNs over their backbones, and to ensure the label switch path is up and running, there is now intelligence being implemented into network elements from newer players, such as Laurel Networks.

"Rather than put in static connections and building IP networks on top, carriers need to 'participate' in the IP topology to enable enterprise flexibility and less management overhead for end-to-end connectivity," says Steve Vogelsang, vice president of marketing for Laurel Networks. He notes that the first generation of routers required highly trained engineers to use the command line interfaces (CLI) for service provisioning. "Now, there are innovative routers possessing built-in element management systems, which eliminates the need for carriers to rely on a CLI."

Laurel uses CORBA interfaces so that element management systems talk to the routers for better control of the service aspects of the router. "It's important that OEM functions be put into routers, because service provisioning and management will rely on the ability to handle a multi-point construct," adds Vogelsang.

Indeed, it seems OEM capabilities are increasingly important in solid performance management and traffic management. "If you want to bring performance guarantees up to a point where there is the same quality as was the norm in TDM, you need to manage multiple services from one network management system," says Pam Dodge, director of technical marketing for Hammerhead Systems, which offers a layer-two switch that provides "service interworking," where ATM and frame traffic can be translated transparently into Ethernet through its Provisioning Gateway. "It's intended as an interim solution for plugging into back-office systems without displacing entire networks," notes Dodge.

Standardization Woes

Management of the physical infrastructure also can be complicated when each vendor creates its own flavor of element management systems to control its switches and consolidate the view of elements to the OSS. For carriers with multiple operations environments and many data centers-each with its own management systems, the process of getting activation and mediation to talk to other network elements can become arduous. "Manufacturers are building devices that do talk to others because of MPLS, but a broader view across all devices will be necessary," says Vogelsang.

Many believe that standards will have to emerge to define how network elements, such as the softswitches activating services for IP backbones, will craft CDRs. "The network should not be a limiting factor to what carriers can offer," says Keith Wolters, senior director of product marketing at Convergys, which has adopted MPLS-based routing for QoS in its Infinys product. "Somehow, the equipment vendors, such as Cisco, Juniper and Nortel, will have to work with governing bodies like the IETF or IEEE to determine a standard way for embodying characteristics of what transactions require to distinguish premium-rated calls from standard calls."

Interoperability already is becoming an issue because all vendors have their own QoS standards. "QoS at layer three will become complicated," admits Syndesis' Mark Nicholson, CTO and senior vice president of product development. "The sheer number of different edge routers means differing levels of support and capabilities," he says, and "that makes for inconsistent QoS."

In order for billing to reflect the QoS the customer actually experienced, characteristics, such as QoS and CoS, jitter, will have to be supported by mediation and activation. "If carriers are going to charge differently for a video stream than a voice call, activation and mediation must capture CDRs possessing QoS parameters and rate on that," according to Wolters.

The first step is to define QoS and abstract it up to a business level. "You don't need provisioning people to know a lot about QoS; you just need it attached to a VPN once a contract is completed," says Syndesis' Patrick Rhude, director of product line management for IP. "There has to be an awareness of the dynamic nature in traffic patterns, which cause QoS characteristics to change." That, he contends, requires periodic evaluations and re-adjustments of the QoS on the network. "If you monitor peak bursts or throughput over a month, you should make sure service is in line with original settings of the SLA," Nicholson says. He also warns there should be significant disaster recovery-type planning: "If a customer uses an MPLS IP VPN for transport of VoIP, as well as for data, there had better be back-ups to data centers, because on a converged network, more and more traffic will come together onto the IP backbone, so you have to make sure the IP VPN can handle the traffic and SLAs by type of traffic." He notes that SLAs for voice will be more structured than one for Internet access, or another for disaster recovery.

SLAs guarantees will be germane to attracting and retaining customers. For that reason, management of the physical elements and control plane in a dynamic environment will require a new breed of management capabilities that help carriers to fully understand the end-to-end customer experience.