Label or Tag Switching | QoS

We now move to label switching or, as called by some implementations, tag switching, which is standardized by the IETF. The technology was initially developed for the purpose of interworking between the IP-based and ATM and frame relay networks, and it was later developed to apply to any network layer protocol (hence the multi- designation). The ATM (B-ISDN) switches follow the PSTN model in establishing and maintaining virtual circuits and virtual paths. The B-ISDN access protocol specifies the QoS, which is then guaranteed by the network.

To get an idea of MPLS, try to answer the following question: If the ATM and IP networks are to interwork, what should the router on the border of the ATM and IP networks do? The most straightforward answer is try to maintain the virtual circuits and virtual paths. To do so, the first router in a chain would need to “understand” the “ATM language” and act (that is, route the packet) based on the connection identifier established by the ATM switch. The next router on the path to the destination does not necessarily have to “understand” the same “ATM language,” but then it needs to understand whatever means the first router uses to identify a connection. The same applies for the rest of the routers on the path to the destination.

This is precisely how the MPLS routers work. They make forwarding decisions based on a fixed-length string called a label to decide how to forward the packet. The labels are meaningful only to the pair of routers sharing a link, and only in one direction—from a sender to the receiver. The receiver, however, chooses the label and negotiates its semantics with the sender by means of the Label Distribution Protocol (LDP). The label can indicate not only where to forward the packet (that is, which port to use), but also the QoS characteristics of the packet that specify its priority and suggest an appropriate treatment.

This approach is very different from the traditional (that is, non-MPLS routing) approach, where a router makes forwarding decisions based on the IP header. In the traditional approach, the routing table must be searched, which takes more time and processing power than a lookup in a label table, which the label-based forwarding requires. Furthermore, the routers that are not capable of analyzing the network layer packet can still perform the label lookup and replacement (a much simpler operation). Another advantage of MPLS is that using the labels (that is, in a sense, maintaining the history of the path) allows the forwarding decisions to be made based on the identity of the router at which the packet enters the network—packets entering the network via different routers are likely to be assigned different labels. Finally, when a packet is to be forced to follow a particular explicit route (rather than be left to the mercy of routing algorithms), the MPLS label can be used to represent the route. RSVP can be extended to complement MPLS by associating labeled paths with the flows. With that, resource reservations associated with an explicit route can be made to guarantee QoS.

We should mention one more important MPLS application: MPLS provides an excellent mechanism for tunneling by stacking the labels and thus supporting nested routing decision making. One important potential application of combining RSVP and MPLS is that the resulting tunnels can be routed away from the points of network failure or congestion. We highly recommend the work of Armitage (2000) as a comprehensive review of the subject.

Another means for ensuring QoS is network-wide enforcement policies, which are rules for control of the network resources and services. In describing these, we follow Kozik et al. (1998). Quality of service is only one aspect of policy-based networks; others are security, authorization, and accounting. These aspects are often inseparable—the accounting function, for example, may determine whether the present level of use has been paid for (by keeping track of the use of the resource). If use has not been paid for, policies can restrict access to the resource or affect QoS by downgrading the level of use.

The architecture of policy-based networks—sometimes also called directory-enabled networks. The architecture actually repeats the IN conceptual pattern in both the way that the policies are stored and the way that they are accessed by network elements (for example, routers, access servers, or telephony gateways). The policies are stored centrally in a policy database by a policy management system. When a network element detects an event that requires policy access (such as a request to provide bandwidth in order to establish an IP telephony call), the network element queries a policy server, which in turn consults the policy database and then either denies the request or carries it through by instructing all concerned entities to perform the actions that would enforce the policy.

Figure 1: The architecture of policy-based networks.

The IETF is addressing the subject of policy-based networks in the Policy Framework (policy) working group.