Ever since the first voice conversation took place over a data line, good end-to-end quality of service (QoS) has been an aim. Voice and data convergence, or voice over IP (VoIP), occupies many network managers' thoughts  although not necessarily their budgets  but many are unclear about their QoS strategy.
There are two reasons for this. In metropolitan area networks (MANs), the explosion of Gigabit Ethernet and the imminence of the 10 Gigabit Ethernet standard have all but removed the need for QoS strategies. Cheap, plentiful bandwidth means quality is good without the need for complex solutions. Additionally, the use of VoIP has not been as widespread as some forecasted, partly due to the problems of converging voice and data and partly due to lower-than-expected cost savings.
The typical wide area network (WAN), however, does not have as much spare bandwidth as a MAN. In fact, QoS solutions owe their existence to this fact. Service providers need to make the most efficient use of bandwidth on their WANs, to provide their corporate customers with promised service levels and to cram as many customers as possible onto the smallest amount of bandwidth in order to remain competitive.
Common approach
Multiprotocol Label Switching (MPLS) is an emerging technology that promises a common approach to QoS across various Layer 2 transports and Layer 3 protocols  hence the 'multiprotocol' title. It is an evolution of proprietary label or tag switching solutions, most significantly IBM's Aggregate Route-based IP Switching (Aris) and Cisco's Tag Distribution Protocol. The Internet Engineering Task Force (IETF) has formed an MPLS Working Group that has produced a plethora of requests for comments (RFCs) for MPLS and is developing the standard. As the nature of MPLS makes it equally relevant to wide area technologies, it is also the subject of standards work by the Optical Internetworking Forum, the ATM Forum and the Frame Relay Forum.
The defining feature of MPLS is the use of 'labels' instead of Layer 3 routing tables or Layer 2 virtual circuit (VC) identifiers to make packet-forwarding decisions. The label is carried inside the data packet in two ways: as a 32bit label inserted between Layer 2 and Layer 3 headers of a packet; or in the VC identifier field of an ATM cell or Frame Relay packet. The former is used for MPLS on local area network (LAN) media, such as Fiber Distributed Data Interface (FDDI), token ring or Ethernet.
All routers or switches that support MPLS exist in an MPLS domain and are known as label switch routers (LSRs). When a packet enters an MPLS domain, the ingress LSR, or label edge router, will assign it to a Forward Equivalency Class (FEC). Each class is associated with a label that is just an arbitrary tag  it carries no information relating to Layer 3 network addresses. The edge router inserts the label into the packet and forwards it into the MPLS domain. Each subsequent LSR only needs to maintain associations between the label numbers and a next hop LSR.
This means that each LSR in the MPLS domain only has to examine the contents of the label to make its routing decision, update the label and forward the packet.
The route a packet takes through an MPLS domain is known as the label switch path (LSP). This is pre-defined according to QoS and traffic engineering (TE) or constraint routing requirements, but is able to dynamically adjust according to prevailing conditions such as hardware failure and traffic profile changes. QoS is achieved in conjunction with standard forwarding mechanisms such as Weighted Random Early Detection (WRED) and class-based weighted fair queuing.
TE can be defined through a number of parameters and requirements  for example, all Web traffic bound for a particular server may be assigned to a particular FEC, while all traffic from a client or server is assigned to another class. Each FEC is then associated with a label so that the traffic will be routed in a particular direction through the MPLS network. For this to work, next hop associations within label switch paths must be communicated to all label switch routers. TE can also be based on the ingress router, so packets from the same destination could take different routes to different exit points according to the point at which they enter the MPLS network. Additionally, IP precedence values carried into an MPLS network can be mapped directly into FECs.
The MPLS architecture defines the use of label distribution protocols (LDPs) to disseminate label information. There are a number of these, some being extensions of existing protocols such as MPLS-BGP or RSVP-TE, while others, such as CR-LDP, have been designed exclusively for MPLS.
The most common protocols are RSVP-TE and CR-LDP. Firms such as Cisco, Juniper and Ironbridge use RSVP-TE, while Nortel and Ericsson, among others, support CR-LDP. It is worth noting, however, that most now include RSVP-TE functionality, so this appears to be the industry's preferred technology.
Virtual private networks
It may seem that MPLS resembles Frame Relay or ATM virtual circuits. In many ways it does and this often obscures the benefits of MPLS. However, existing carrier technologies, although able to provide QoS, can only really do so within their own networks  for example, through the Frame Relay Committed Information Rate (CIR) mechanism in Frame Relay networks. MPLS provides the capability for end-to-end QoS and improves on TE by providing a common, feature-rich approach to traffic routing. It can be thought of as a kind of all-terrain QoS.
Another commonly cited benefit of MPLS is its ability to create virtual private networks (VPNs) without tunnels or encryption. Because LSRs only examine the label in an MPLS packet, they never need to see the packet's Layer 3 information and so do not need to maintain end-to-end protocol routing tables. As long as they can reach the next MPLS hop  the next MPLS router in their LSP routing will work. In this sense, a VPN has been created, with end-to-end routing without reference to the networks at either end. However, network address information is still carried in the Layer 3 header, so anyone able to capture the packet could infiltrate the system. No encryption has yet been specified for the MPLS standard, so any VPN implementation will be significantly less secure than a traditionally encrypted, tunnel VPN. Of course, in a private network, this is not always a big concern.
It is unlikely that MPLS will be widely used in corporate networks for some time, except for end-to-end requirements that reach from the WAN into MANs or LANs. However, it is being used in some WANs already. Most ISPs have some form of MPLS, although it is probably not obvious to the end users. The same applies to corporate WAN providers. One of the biggest was BT and AT&T's now defunct Concert service, although rather than masking the underlying technology, the firms made no secret of their use of MPLS.
At the moment MPLS must run over existing Layer 2 infrastructures. This is fine at the MAN level, but in the WAN it usually means running over ATM or Frame Relay. Given that MPLS is supposed to improve on ATM and Frame Relay, the obvious next step is their removal.
Generalised MPLS (GMPLS) is an extension to MPLS that will allow it to run over non-packet-based networks such as those using Sonet/SDH services. It will allow MPLS not only to carry user traffic, but also to function as the control plane for path selection, a function carried out by ATM and Frame Relay.
Whether this will lead to mainstream use is open to debate as the proponents of Ethernet are still fighting for it to control the WAN but, thanks to its early adoption on traditional networks, MPLS looks set to become the QoS solution of choice.
