MPLS proposal to aid service levels

Multi-protocol Label Switching is gaining momentum within the service provider community.

In addition to being well-suited to handle the traffic engineering and scaling issues associated with large carrier backbone networks, MPLS will enable service providers to offer enterprise customers new value-added services.

Many applications important to corporations have quality-of-service requirements that are different from one another. Current MPLS standards do not support different service classes, but a new set of extensions to MPLS has been developed that should fix the problem.

MPLS also has been enhanced from its original design to support traffic engineering through the implementation of several MPLS traffic-engineering extension Internet Engineering Task Force (IETF) drafts. This traffic-engineering capability enables service providers to use network resources more efficiently by explicitly mapping how traffic flows through their networks.

In the traffic-engineering scenario, the MPLS forwarding device (label switch router [LSR]) located at the ingress to the MPLS domain is responsible for establishing a path through the MPLS network (called a label switched path) when it receives a request to do so.To create this path, the ingress LSR must know the current state of the network. In particular, the LSR must have some knowledge of the bandwidth available on each link in the network.

Existing IP link-state protocols, such as Open Shortest Path First and IS-IS, have been extended to propagate this information throughout the network. Once the ingress LSR has a complete picture of the bandwidth availability in the network, it can establish a path that meets the demands of the request.

But the traffic-engineering extensions are only part of the answer. Although they provide a mechanism to determine a path through an MPLS network that meets certain constraints, they are unable to associate bandwidth availability with different service classes. The ingress LSR sees aggregate bandwidths associated with each link in the network, but can't associate slices of bandwidth on each link with different classes of traffic.

Not many telecommunications customers would be willing to accept a service whereby the service provider is unable to differentiate and service different traffic types in different ways. For example, companies paying a premium for a real-time voice service would not be willing to accept the performance associated with an e-mail application.

For this reason, a new set of extensions to MPLS has been developed that enables bandwidth to be reserved in the appropriate class of service, ensuring its availability when high-priority traffic needs to be delivered.

The IETF drafts propose four service classes that align closely with the four major traffic types in service provider networks:

? A deterministic traffic class that emulates private-line and time-division multiplexing services.

? A real-time traffic class for time-sensitive traffic, such as packetized voice or video or storage-area network apps.

? An assured traffic class for business-critical applications.

? A best-effort traffic class that offers no guarantees on performance and parallels the service offered by 'Net.

These four service classes will let service providers quickly provision value-added services with class-of-service guarantees with a high degree of service fidelity across an MPLS packet-based core network. In turn, enterprise customers can expect increased service offerings with predictable service levels and reduced lead times from service providers deploying this technology.

Burmeister is a product manager at Tenor Networks. He can be reached at nigel_burmeister@tenornetworks.com.