DiffServ: DSCP and TC

Theoretical foundations and architecture

Quality of Service (QoS) in MPLS backbones adheres to the DiffServ architecture (RFC 3270). Incoming customer IP packets present 6-bit DSCP (Differentiated Services Code Point) markings (e.g., Expedited Forwarding EF for VoIP, AF31 for ERP, CS0 for best effort). However, the 32-bit MPLS shim header allocates only 3 bits for QoS: the Traffic Class (TC, formerly EXP) field, offering exactly 8 traffic classes (0-7). The Ingress PE is tasked with mapping 64 IP DSCP values down to the 8 MPLS TC codepoints during label imposition (Push). Core transit P routers never inspect inner IP DSCP headers; their hardware schedulers and queues operate strictly on the 3-bit TC field of the top label. Two classification architectures exist: E-LSP (EXP-Inferred-PSC LSP), where QoS is signaled exclusively via TC bits, and L-LSP (Label-Only-Inferred-PSC LSP), where the label value itself dictates queuing behavior.

Three headers, three priority fields

The same packet carries priority in three different places. In the IP header it is the DS field (the former ToS): 6 DSCP bits per RFC 2474 and 2 ECN bits per RFC 3168. In an Ethernet 802.1Q header it is the 3 PCP bits (plus the DEI bit). In the MPLS shim header (RFC 3032) it is the 3 TC bits: 20 bits of label, 3 bits of TC, 1 bit S, 8 bits of TTL. The TC field used to be called EXP until RFC 5462 renamed it to TC (Traffic Class): it had long stopped being "experimental", and the name was easy to confuse with ECN. The scheduler on each node reads only the field it can parse at that step: the ingress PE looks at the customer DSCP, a transit P looks at the TC of the top label, the egress PE looks at the TC (Pipe) or at the DSCP (Short-Pipe). The whole of MPLS QoS is an agreement about who rewrites priority into which field, and where.

DSCP and PHB: the code and the behavior

DSCP is only a numeric code, while a PHB (Per-Hop Behavior) is what a node does when forwarding: which queue, which drop probability. The "code - PHB" mapping is local to each domain (RFC 2474); the standards only recommend values. Class Selector (CS0-CS7, format xxx000) is backward compatible with IP Precedence. EF (Expedited Forwarding, RFC 3246) is code 46 (101110): low loss, delay and jitter, with the departure rate of the aggregate no lower than the configured rate; EF must be rate-limited at the edge, otherwise it starves everything else. AF (Assured Forwarding, RFC 2597) is 4 independent classes with 3 Drop Precedence levels each; the code is 8*class + 2*drop: AF11=10, AF12=12, AF13=14, AF21=18 ... AF31=26, AF32=28, AF33=30, AF41=34, AF42=36, AF43=38. Packets inside an AF class are not reordered, and under congestion packets with higher Drop Precedence are discarded first. RFC 4594 recommends 12 service classes: Network Control CS6, Telephony EF, Signaling CS5, Multimedia Conferencing AF41-43, Real-Time Interactive CS4, Multimedia Streaming AF31-33, Broadcast Video CS3, Low-Latency Data AF21-23, OAM CS2, High-Throughput Data AF11-13, Standard DF, Low-Priority Data CS1.

From 64 values to 8: mapping DSCP to TC

TC has only 3 bits, that is 8 values. The default on most platforms is to copy the 3 most significant DSCP bits (that is, IP Precedence): TC = DSCP >> 3. For EF: 101110 -> 101 = 5; for AF41 (100010) it is 4, for AF31 it is 3. The resulting table:

Two losses are visible in the table. First: the Drop Precedence of AFx1/x2/x3 in one row is indistinguishable to a P router, so WRED inside TC 4 cannot discard AF43 before AF41. If the distinction matters, the operator splits the 8 values differently: for example, 4 AF classes with two Drop Precedence levels use all 8 values and leave no room for EF and CS6, so in practice either the third drop level or some classes are sacrificed. Second: CS5 and EF land in the same TC 5; if a customer marks all its traffic as CS5, it takes over the priority queue. Hence the rule: classification on the ingress PE is done on exact DSCPs/ACLs rather than on the "top three bits", and the mapping table is fixed in a document and applied identically on all platforms (vendor defaults differ).

E-LSP and L-LSP (RFC 3270)

RFC 3270 describes two ways to carry the PHB across an LSP. E-LSP (EXP-Inferred-PSC LSP): the PHB is derived from the TC field, one LSP carries up to 8 PHBs, and the TC-PHB mapping is either preconfigured identically across the network or signaled at LSP setup (RSVP-TE: DIFFSERV object; LDP: Diff-Serv TLV); signaling is optional for an E-LSP. L-LSP (Label-Only-Inferred-PSC LSP): the PSC (Per-Hop Scheduling Class, for example AF1 with all three Drop Precedence levels) is determined by the label itself, and TC carries only the Drop Precedence; the PSC must be signaled. An L-LSP is needed when there are more than 8 PHBs or the link layer cannot carry TC, but it costs one label per PSC: with EF, AF1-AF4, BE and CS6 that is 7 bindings instead of one per FEC, that is 7 times more LFIB and RSVP state. That is why real networks (and all platforms of this course) use E-LSP.

Where TC is set and what a P does with it

The ingress PE writes TC at push: on the transport label and on the VPN label (an L3VPN has two; on most platforms the value is the same). A transit P copies the TC of the incoming label into the outgoing one at swap unless policy says otherwise; a P may lower the TC (re-marking) for out-of-profile traffic. What happens when a label is removed (PHP, Uniform/Pipe) is covered in the next lesson; one consequence matters here: with PHP the last hop to the egress PE carries only the VPN label (or plain IP for IPv4-over-LDP without a VPN), so the egress queue of the penultimate P must classify on both TC and DSCP.