Summary

  • RFC 3429 assigned reserved MPLS label value 14 to identify user-plane OAM packets, while leaving their detailed functions to ITU-T Recommendation Y.1711.
  • With penultimate-hop popping, the OAM label and payload could reach an OAM-capable MPLS egress after the ordinary top label was removed; a non-MPLS endpoint was a different case, explicitly left outside the then-current Y.1711 scope.
  • The surviving TTSI helped identify the ingress LSR. It did not prove that the LSP was healthy, that customer packets arrived, or that an operator acted on an alarm.

The last router in an MPLS path might be asked to do less precisely because it was the last router. If the egress could not perform two label lookups at line rate, it could request penultimate-hop popping (PHP): the upstream router removed the top label before forwarding. For ordinary traffic, that meant the egress had one less label to process. For operations and maintenance, it raised a more exact question: what would distinguish a diagnostic packet from user traffic after that outer label disappeared?

RFC 3429’s answer was not a new monitoring system. It was a reserved codepoint. The document assigned label value 14, one of the values reserved by RFC 3032, to the “OAM Alert Label.” A packet carrying that label could be recognized as an MPLS OAM packet. The assignment was narrow: it identified packet class at the MPLS layer; it did not define every payload function, mandate an implementation, or certify a path.

Why the label had to remain

The design linked three different jobs. ITU-T Y.1711 specified user-plane MPLS OAM functions and their payload context. RFC 3031 supplied the MPLS architecture, including PHP. RFC 3429 assigned the label value that let an OAM packet remain recognizable in that architecture.

The control-plane value used to request PHP was implicit-null, label 3. That value was distributed in signaling but never appeared in the packet itself: it told the penultimate LSR to pop rather than replace the top label. The OAM Alert Label was different. It was an actual in-band label on the OAM packet. RFC 3429’s case 1 therefore did not ask PHP to carry the removed forwarding label onward. The penultimate LSR removed that top label and forwarded the OAM Alert Label and OAM payload intact.

At the egress, the remaining top label mattered. If the ultimate node was an MPLS LSR that supported OAM, it could recognize the arriving packet as OAM even though the original top label was gone. The packet’s TTSI—the Trail Termination Source Identifier—gave that endpoint the ingress LSR that originated it. Identity had moved from an outer forwarding label that PHP removed to an identifier carried inside the diagnostic packet.

That is a useful but limited continuity. The TTSI identifies the source specified by the OAM mechanism; it does not, by itself, certify that every intermediate hop forwarded correctly, that a customer’s data followed the same conditions, or that the remote application received anything. Nor does label 14 mean that the receiver has processed a CV, FDI, BDI or other Y.1711 function. The label is a recognition boundary, not an outcome receipt.

Two meanings of “the destination asked for PHP”

RFC 3429 separated two cases that could look alike in a label-distribution exchange. In the first, the ultimate node was still an MPLS LSR with control and data planes. It requested PHP because it could not make two lookups at line rate. It remained capable of reading the OAM label and payload after the penultimate LSR popped the ordinary top label. Y.1711 OAM could operate in this case.

In the second, the ultimate node had no MPLS label lookup or processing and did not recognize labeled packets at all. It too could request implicit-null/PHP, but that did not turn it into an OAM endpoint. RFC 3429 said the then-current Y.1711 functions applied only to the first case; application to the second needed further study. The RFC also left carrier-supporting-carrier scenarios for future study. A common control-plane request therefore did not imply a common data-plane capability.

The distinction is operationally consequential. If a diagnostic stops at an incapable endpoint, an operator cannot safely reinterpret that silence as a healthy path or as proof that PHP itself failed. The specification says an ultimate LSR without MPLS OAM support discards the packet. RFC 3031’s invalid-label rule also resists casually removing an unknown label and forwarding the result as plain IP: that can change the packet’s meaning or expose traffic. A visible drop may be safer than an invented interpretation, but it still leaves an evidence gap.

A registry entry is not an installed capability

The IANA MPLS Label Values registry still records value 14 as OAM Alert Label and points to RFC 3429. That continuity lets protocol documents refer to a stable meaning. It says nothing about which routers today implement the label, which OAM profiles are enabled, whether PHP is used on a particular LSP, or how a live device reports a discard.

RFC 3429 is an Informational RFC from November 2002, not a deployment report. Its historical significance is the division of labor: ITU-T defined an OAM mechanism; the IETF reserved an MPLS label to identify its packets; and the text spelled out a PHP boundary where the endpoint had to remain MPLS/OAM-aware. The standardization result was a shared vocabulary for a packet, not an assurance service for a network.

To assess an actual path, an operator would need separate evidence for the signaled label operation, the stack before and after PHP, support at the egress, reception and parsing of the OAM payload, interpretation of the TTSI, and the relevant OAM function’s result. Data-plane service evidence would remain separate again. Without those joins, “OAM enabled,” “label 14 registered,” and “LSP up” are three statements at different layers—not three interchangeable ways to say that customer traffic arrived.

Sources