Carrier boundaries challenge MPLS VPNs

Need for an MPLS interconnect arises to ensure service reach, consistency.

Enterprise customers looking to utilize multiple carriers to provide global reach for their MPLS VPNs might find themselves thrown for a loop.

Differences in the way carriers assign QoS attributes to separate MPLS paths can result in service inconsistency. And because no single carrier has a footprint in every possible locale an organization might have to reach, each has to establish MPLS interconnect agreements with other carriers that might have configured VPN QoS profiles much differently.

“Not every carrier can have a point of presence in every single possible location,” says Andy Malis, chairman of the MFA Forum, which is defining specifications to resolve the MPLS interconnect issue between carriers. “And at this point, the interconnections that are happening are basically for best effort [service] only.”

The MFA Forum began work late last year on an MPLS cross-boundary interconnect to enable QoS, privacy and security, Malis says. The forum expects its initial specification to be published in the first half of 2006.

“We recognize in the standards community that there are deficiencies in the standard to be able to have a full-service MPLS interconnect in between carriers,” Malis says.

Vendors are also attempting to tackle the problem in associations such as the new IPSphere Forum, which spawned from Juniper’s Infranet Initiative Council, and with single-vendor products such as Cisco’s MPLS inter-provider features for its routers .

The forum is looking to extend work done by the IETF to define up to eight service classes in an MPLS header, using Differentiated Service (Diff-Serv) code point markings, in a single carrier’s network. The MFA is looking to broaden this specification so it works on an inter-provider basis, as well, Malis says.

“The hard part is going to be on the carrier’s part to have some amount of alignment on what the meanings are of the Diff-Serv markings in the headers,” he says.

There’s a possibility, Malis says, that two carriers don’t use the Diff-Serv markings to mean the same thing. In that case, the carriers will have to figure out how to resolve this by re-marking packets at a router at the boundary of the network.

Malis says there is text in the IETF’s RFC 2547bis specification (PDF ) for MPLS-based Layer 3 VPNs that states how to establish such interconnections. But that is for best-effort Layer 3 VPNs only.

So the forum is working on a template to function as a guide for mapping a subset of services between different service providers not only for Layer 3 MPLS VPNs, but for all MPLS services: Layer 2 virtual private LAN Services (VPLS), point-to-point pseudo-wires, traffic-engineered label switched path intercarrier trunks and VoIP among them.

The need for a VPLS network-to-network interface to extend switched Layer 2 VPN services came up at the recent Supercomm 2005 conference in Chicago.

“There’s a lot more going on than just the Layer 3 VPNs, so we really need a more general MPLS-based interconnect,” Malis says.

After the initial phase is released in the first half of next year, the forum hopes to release updates – or subsequent phases – every six to nine months thereafter.

In the meantime, some carriers have established their own MPLS interconnect services in which they hammer out specific wholesale peering arrangements with other carriers to ensure service consistency and global reach. BT Infonet, for example, rolled out its service four years ago to extend the reach and service capabilities for multinational corporations via global class-of-service (CoS) data services across multiple IP VPN backbones.

BtNAccess, a retail and wholesale carrier in Reston, Va., has MPLS interconnect agreements with 15 other carriers in North and South America, Asia, Europe and the Middle East for end-to- end VPN connectivity to 35 countries. And Global Crossing last fall unveiled its iMPLS service, which allows MPLS-based service providers to essentially resell Global Crossing’s IP VPN service beyond their own regions with guaranteed QoS.

“You can expect feature and CoS and QoS transparency consistent with RFC 2547 standards, provided the implementation is done properly,” says Anthony Christie, chief marketing officer and executive vice president at Global Crossing. “Because [iMPLS] is a product of the wholesale side of the house, it behooves us to make sure that there is feature transparency, QoS, CoS and [service-level agreements] between networks. It’s not just a way for us to provide an extended-reach capability to our enterprise customers.”

Christie says Global Crossing has about 20 partners for iMPLS.

Carriers say MPLS interconnect is more of a challenge for carriers than it is for corporations. Billing, settlement and customer SLA assurance are all matters carriers have to agree on, while the customer usually deals with only one carrier for service and support.

If a customer doesn’t receive contracted SLAs, some carrier within the chain won’t get paid.

“All these [reach and QoS] things are addressed as you’re going through the opportunity itself,” says Alessandro Bucelli, MPLS VPN product manager at BtNAccess. “Usually companies that are considering MPLS VPNs are intelligent enough to realize that one company can’t provide you connectivity to the whole world. They understand the whole partnership model.”

Some analysts say MPLS VPNs are still too new to users for them to be concerned about inter-carrier service consistency. They also try to deal with only one or two carriers, not several.

“Most enterprises are still kind of going, ‘What’s MPLS again, and how is it going to help me?'” says Johna Till Johnson, president of Nemertes Research and a Network World columnist. “Inter-carrier MPLS is sort of like, ‘Wow, that would be really cool if I could figure out why I needed it.’ There’s no absolutely earth-shattering business driver for multi-carrier MPLS from an enterprise standpoint.”