Understanding MPLS Explicit and Implicit Null Labels

In the previous post, discussing the role of the FEC in MPLS networks, I used in one of my examples a particular label value; I was hoping someone would ask about it, which would give me a nice segue to this post. Well no one did, but I’m going to tell you about it anyway.

The label, used between the next-to-last LSR (called the penultimate LSR) and LSR on which an LSP terminates (called the egress LSR), is called the IPv4 Explicit Null label, and has value of 0. (There is also an IPv6 Explicit Null label, with a value of 2.)

Figure 1 (click here for Figure 1) shows the use of the explicit null label. When an LSR receives an MPLS header in which the label is set to 0, it always POPs the header – that is, it removes the label. The use of the explicit null is in keeping with the concept of a packet’s FEC being determined only at the ingress to an LSP, and no where else along the path. The reserved label value of 0 prevents the egress LSR from  either having to keep some sort of state designating a set of its allocated labels as POP labels, or having to look to the encapsulated payload to determine what LSP it belongs to.

There’s something to notice about the switching and forwarding procedure depicted in Figure 1: Once R3, the penultimate LSR, has switched the packet out its interface IF2 toward R4, the label has no further relevance except to tell R4 to POP the header; that is, no further MPLS switching is performed. So in fact once R3 has determined what interface to switch the packet out, it could go ahead and POP the label there and save a step at R4.

This procedure – with the wonderful name Penultimate Hop Popping – is depicted in Figure 2 (click here for Figure 2).  R3’s MPLS switching table indicates, for the incoming label of 17, an outgoing label of 3. But then this label value – called the Implicit Null – resides in the table as an outgoing label, an LSR does not perform a SWAP; instead it performs a POP and forwards the packet out the referenced interface (in this example, R3’s IF2).

The value of penultimate hop popping is that it saves a small step at the egress router of having to first consult its MPLS switching table, POP the header, and then examine the decapsulated payload to determine the proper next step. Instead, in Figure 2, R4 just sees an incoming IP packet and takes the appropriate action for generic IP routing.

The question arises, then: If implicit null is more efficient, why do we need explicit null at all?

The answer is Class of Service.

When a packet or Ethernet frame is encapsulated in MPLS, you have the option of copying the IP precedence or 802.1p bits to the three CoS bits of the MPLS header (unfortunately called the Experimental or EXP bits), so that the MPLS LSP provides the same CoS behavior, or you can set the EXP bits independently, so that the LSP CoS behavior has a designated CoS behavior that is independent of any encapsulated payload.

In this second case, you would want to use the explicit null label between the penultimate and egress LSRs. If a POP is performed at the penultimate LSR, as in Figure 2, the EXP bits in the MPLS header are no longer available as a reference for queuing and the packet is queued on the outgoing interface according to the CoS behavior of the underlying payload. An explicit null, on the other hand, leaves the MPLS header in place until it reaches the egress, preserving the LSP CoS behavior across the entire LSP.