The MPLS standards are being developed by the IETF Multiprotocol Label Switching (mpls) working group (www.ietf.org/html.charters/mpls-charter.html ). The term multiprotocol has been chosen to stress that the method applies to all network layer protocols, not only IP. In fact, the method was brought to life by integrating the ATM, B-ISDN network layer with IP.
The MPLS architecture is described in [IETF MPLS WG, Rosen et al. (1999)]. We examine this document by first introducing a forwarding equivalence class (FEC). An FEC is a set of packets associated with a path starting at a given router, so that all packets in the FEC follow this path. (In reality, there are cases of multipath routing; in these cases, an FEC corresponds to a set of paths, and the packets that belong to the FEC then follow a path out of this set.) The job of the router is first to classify the incoming packets into FECs and, once this is done, to forward all packets within each FEC without making any further distinction.
Non-MPLS routing, each packet is typically forwarded based on its IP destination address. The packets are considered equivalent (and thus belong to the same FEC) if the router’s table contains an address prefix that is the longest match for each packet’s destination address. Each router reclassifies the packets.
In contrast, with MPLS forwarding, each packet is assigned to an FEC only when it enters the network, at which point the FEC value (encoded as a fixed-length string called a label) is sent along with the packet. The routers traversed by such a packet ignore the IP header and instead use the label as an index into a table that specifies the next router to which the packet is to be sent and a new label, which replaces the old label. In other words, labels have, in general, only local significance. The forwarding operation itself (which includes looking up an incoming label; determining the outgoing label, outgoing port and other information; and replacing the incoming label with the outgoing label) is called a label swap. As far as the location of the label within a packet is concerned, it could reside within a specific encapsulation header or be placed within an existing data link or network layer header.
Diffserv and intserv approaches support the prioritization of packets. Such prioritization defines the precedence (or class of service) of each packet so as to choose the pertinent discard threshold or scheduling. This prioritization can be preserved with MPLS: In this case, the label represents a combination of an FEC and the precedence or class of service. In fact, a label can be assigned to a union (aggregate) of FECs with similar properties rather than one FEC.
An MPLS-capable router is called a label-switching router (LSR). A hop (that is, link) between two routers, on which a labeled packet is forwarded, is called a label-switched hop (LSH). Different labels arriving at an LSR are replaced with one label through a procedure called label merging. A merge point is the node at which the label merging is performed. When this procedure involves framed media, it is called frame merge.
A contiguous set of LSRs in the same routing or administrative domain form an MPLS domain. A router that connects an MPLS domain with the node outside the domain is called an MPLS edge node. An MPLS edge is called an MPLS ingress node when it handles the traffic entering an MPLS domain; it is called an MPLS egress node when it handles the traffic exiting an MPLS domain. (These last two definitions refer to a role the same physical router plays in respect to the direction of the traffic that passes through it.)
The agreement between two LSRs on a forwarding path to use a given label for a given FEC is called label binding. The responsibility of ensuring that the binding is unique lies with each LSR receiving a packet. With respect to a given label, the LSR that sends the packet that contains it is called an upstream LSR, and the LSR that receives such a packet is called a downstream LSR (as depicted in Figure 1). These definitions are important because, in the MPLS architecture, the decision to bind a label to an FEC is made by the LSR that is downstream with respect to that binding. (The downstream LSR informs the upstream LSR of the binding.) Thus, labels are downstream assigned, and the binding is distributed in the upstream direction.
At this point, we can define the key concept and product of MPLS—the Label Distribution Protocol (LDP), a set of procedures by which one (downstream) LSR informs another (upstream) LSR of the label-to-FEC bindings it has made. The Label Distribution Protocol also includes the negotiations in which these LSRs (called label distribution peers) may engage in order to learn of each other’s MPLS capabilities. There is no plan for a single LDP—several such protocols are being standardized (like MPLS-LDP and MPLS constraint-based LDP). The existing protocols that can be used for label distribution include RSVP and BGP.
One ingenious feature of MPLS is that it helps implement a network layer tunnel without using encapsulation. Because the traffic that flows along the label-switched path (LSP) is defined by the label received at the first LSP node, this path can be treated as a tunnel (called an LSP tunnel). By definition, such LSP tunnels are unicast. Tunneling for IP VPNs can be achieved by using a stack (that is, first-in-last-out data structure) of labels rather than a single label. Although forwarding is performed by an LSR always on a single label, the MPLS architecture provides that the labels may be stacked, with the stack carried in an IP packet. The set of packets to be sent through the LSP tunnel constitutes an FEC, and each LSR in the tunnel must assign a label to that FEC (that is, must assign a label to the tunnel). To put a packet into an LSP tunnel, the transmit tunnel endpoint pushes a label for the tunnel onto the label stack and sends the labeled packet to the next hop in the tunnel. The label stack is then popped by the penultimate LSR in the tunnel.
RSVP is being extended to establish unicast LSP tunnels in MPLS networks (with or without resource reservation). IP hosts and routers that support both RSVP and MPLS can associate labels with RSVP flows. (In this case, the flow corresponds to the LSP.) One important application of combining the RSVP and MPLS is that the LSP tunnels can be routed away from the points of network failure or congestion. Finally, we should note that the mpls working group has decided to define capability sets (similar to the ITU-T practice). All such capability sets [so far, 10 have been defined in IETF MPLS WG (Andersson et al., 1999)] support basic LDP; they differ in particular features and interwork with other protocols (for example, BGP).
No comments:
Post a Comment