Multiprotocol Label Switching (MPLS) is a mechanism for packet routing that is widely used in high-performance computer networks. In an MPLS network, data packets are assigned labels, and packet-forwarding decisions are made solely on the contents of the labels, without the need to examine the network address of the packet itself. The MPLS architecture and label structure were originally defined by Rosen et al. in Requests for Comments (RFCs) 3031 and 3032 of the Internet Engineering Task Force (IETF) Network Working Group (2001), which are incorporated herein by reference.
MPLS is a network-layer protocol (Layer 3 in the Open Systems Interconnection [OSI] model), which is implemented by routers in place of or in addition to address-based routing. At the ingress to an MPLS network, a prefix is appended to the packet header, containing one or more MPLS labels. This prefix is called a label stack. According to RFC 3032, each label in the label stack contains four fields:                A 20-bit label value (commonly referred to as the label identifier or “label ID”).        A 3-bit traffic class field for QoS (quality of service) priority and ECN (explicit congestion notification) signaling (also referred to as the “EXP” or traffic class—“TC”—field).        A 1-bit bottom-of-stack flag, which is set to indicate that the current label is the last in the stack.        An 8-bit TTL (time to live) field.        
A router that routes packets based on these labels is called a label-switched router (LSR). According to RFC 3031, when an LSR receives a packet, it uses the label at the top of the stack in the packet header as an index to an Incoming Label Map (ILM). The ILM maps each incoming label to a set of one or more entries in a Next Hop Label Forwarding Entry (NHLFE) table. Alternatively, when packets arrive at the LSR unlabeled, a “FEC-to-NHLFE” function (FTN) maps each “Forwarding Equivalence Class” (FEC) to a set of one or more NHLFE table entries. In either case, each NHLFE indicates the next hop for the packet and an operation to be performed on the label stack. These operations may include replacing the label at the top of the stack with a new label, popping the label stack, and/or pushing one or more new labels onto the stack. After performing the required label stack operations, the LSR forwards the packet through the egress interface indicated by the NHLFE.
In Internet Protocol (IP) networks that support Differentiated Service (“Diff-Serv”), packet IP headers may contain a “Diff-Serv Code Point” (DSCP) value, which classifies packets according to different quality of service (QoS) levels. As a packet passes through the network, each transit node selects the scheduling treatment, and possibly the drop probability, for the packet depending on its DSCP value. This Diff-Serv architecture was defined initially by Blake et al., in IETF RFC 2475 (1998), which is incorporated herein by reference.
Le Faucheur et al. defined a framework for MPLS support of Diff-Serv functionality in IETF RFC 3270 (2002), which is also incorporated herein by reference. In this context, the EXP field in the MPLS label is generally used to indicate the scheduling class. In particular, in MPLS tunnels (as described in section 2.6 of RFC 3270), the EXP field of the outer packet label indicates the scheduling class along the entire length of the tunnel, and LSRs along the tunnel consider only this external label. In the “Pipe Model,” described in subsection 2.6.2, intermediate nodes along the tunnel consider only “LSP Diff-Serv Information,” which is carried in the outer MPLS label and is meaningful only within the tunnel. Diff-Serv information that is meaningful beyond the tunnel egress, such as an EXP value in an inner MPLS label or the DSCP value in the IP header that is encapsulated behind the outer MPLS label, is referred to as “Tunneled Diff-Serv Information” and is ignored by the LSPs along the tunnel.
Subsection 2.6.2.1 of RFC 3270 describes a variant on the MPLS Pipe Model, referred to as the “Short Pipe Model.” In this case, the Diff-Serv forwarding treatment at the egress LSR from the tunnel is applied based on the Tunneled Diff-Serv Information. Because the egress LSR does not use the LSP Diff-Serv Information in forwarding the packet onward, the Short Pipe Model can operate with Penultimate Hop Popping (PHP), in which the next-to-last (penultimate) LSR in the tunnel pops and discards the outer MPLS label containing the LSP Diff-Serv Information. PHP is thus useful in reducing the label-processing burden on the egress LSR.
A label-switched path (LSP) is also referred to as an MPLS tunnel. Formally, an LSP defined as a sequence of LSRs, beginning with an ingress LSR and ending with an egress LSR, which forward packets along the LSP based on the outer packet labels, which are at a certain level of the label hierarchy within the network (i.e., the outer label is at the top of a label stack that maintains the same depth throughout the tunnel). The term “pipe” is used specifically, in the present description and in the claims, to refer to an MPLS LSP that applies LSP Diff-Serv Information in forwarding packets through the LSP, as defined above.
Protocols for differentiated service levels also exist in Layer 2 networks. For example, in Ethernet networks, the IEEE 802.1Q standard defines a 3-bit field known as the Priority Code Point (PCP) in the frame header, which can be used to differentiate traffic into eight levels of priority for purposes of quality of service (QoS). The IEEE 802.1Qbb project authorization request (PAR) provides priority-based flow control (PFC) as an enhancement to the traditional Ethernet pause mechanism for flow control on a physical link. PFC creates eight separate virtual links on a given physical link and allows the receiver to pause and restart the virtual links independently. PFC thus enables the operator to implement differentiated quality of service (QoS) policies for the eight virtual links.
The references cited above use various different terms and parameters in defining QoS levels, such as “Diff-Serv information” and DSCP, EXP, TC, and PCP values, for example. The term “quality of service” (abbreviated as “QoS”) is used in the present description and in the claims to refer to and include all of these various terms and parameters, unless stated otherwise or required by the context of usage.