Summary

  • An upstream-assigned MPLS label must be looked up in a context-specific space. For an MPLS tunnel, labels above it identify the tunnel and its root; RFC 5331 therefore requires PHP to be disabled when popping would erase that context.
  • The same numeric label can legitimately name different FECs in different spaces. Tunnel-root identity, assigner identity, ingress interface and LAN context label are part of the lookup key, not descriptive metadata.

The optimization removed the selector, not the payload

Consider a packet whose inner label is upstream-assigned. At the downstream router, that number is not looked up in the ordinary per-platform table. It belongs to the label space of the upstream tunnel root.

The labels above it do two jobs. They carry the packet across the tunnel and tell the receiver which context-specific table will make the inner number meaningful. If a penultimate hop removes the outer tunnel label, the packet can arrive with its data intact and its inner label unchanged while the table selector is gone.

RFC 5331 turns that dependency into an explicit rule: if the tunnel is MPLS and the receiver needs the tunnel to determine context, PHP must be disabled. This is not a claim that PHP is generally unsafe. It is a reminder that an optimization is safe only after every semantic use of the removed state is accounted for.

A packet capture after the pop cannot reconstruct the missing tunnel identity from the inner label. The same number may exist in the per-platform table, another upstream neighbor's table or a downstream-assigned space with a different FEC. Choosing any one by fallback is a new decision, not recovery of the lost fact.

A label value can be correct twice

RFC 5331 requires no coordination between upstream- and downstream-assigned values. One number may be upstream-assigned to one FEC and downstream-assigned to another. Even among upstream spaces, different roots can reuse values without conflict.

The lookup key is therefore closer to (assignment direction, context mechanism, root identity, ingress interface, table generation, label) than to label. A log line that records only label=42 has preserved the least discriminating coordinate.

This is materially different from the later common-label bargain in RFC 9573. That work asks how multiple devices keep a shared service assignment synchronized. RFC 5331's narrower problem comes first: the receiver must retain enough envelope and root evidence to choose any correct table at all.

Root identity must agree across protocols

When an upstream router uses IP or MPLS tunnels, the downstream router maintains a separate Upstream Neighbor Label Space for each unique root. The root is represented by the tunnel head-end IP address. Different head-end addresses require different spaces even when they belong to the same chassis.

Two tunnels may share one upstream label space only under a complete set of conditions. Their setup must identify the same root IP, the same router must be the assigner, and the packets must use upstream-assigned labels under the stated procedure. The text uses an if-and-only-if boundary because a partial match is not enough.

The label-distribution protocol must identify the assigner with the same IP address that the tunnel-setup protocol uses for the root. This matters precisely when the two protocols are different. Each control-plane record can be internally valid while their identity join is wrong.

Operations should preserve both claims and the match result. Silently canonicalizing several IP addresses to one device may collapse tables the RFC requires to remain separate. Refusing to join aliases may split a space intended to be shared. Chassis identity is not automatically tunnel-root identity.

GRE makes the source address an authority input

Some tunnels have signaling that names a root. Others are configured. A GRE tunnel can arise simply by encapsulating and sending. In that case RFC 5331 treats the IP source address as the root.

That address is not merely network-layer decoration. It selects the upstream neighbor label space. Source-address changes, NAT-like rewriting, asymmetric termination or an inventory alias can therefore alter the table used for an unchanged inner label.

This does not make an observed source address proof of authorization. It is the protocol coordinate used for lookup. Authenticity of tunnel setup, label distribution and the relationship between address and operator authority sit in separate security evidence.

EtherType answers only the first question on a LAN

On multi-access media, RFC 5332 can use a distinct EtherType to indicate upstream label assignment. RFC 5331 says that is not sufficient to determine context. Several upstream neighbors share the LAN, and the downstream router still needs to know whose label space applies.

The solution is a one-hop MPLS tunnel. The top label is a context label assigned by the upstream LSR; the label immediately below is the upstream-assigned service label. The receiver looks up the context label together with the LAN interface, selects the neighbor space, and only then interprets the second label.

Capture pipelines that strip EtherType, top label or ingress interface at different stages can each leave a plausible fragment. None alone reconstructs the full decision. The evidence receipt must preserve their order and the table-selection result.

The same context number can collide or coexist

A context label must be unique among all context labels used by LSRs on the same LAN. RFC 5331 offers provisioning and a constrained auto-generation method based on the host part of an IPv4 address.

The method assumes unique low-order bits on that LAN, avoids reserved label values, and cannot serve IPv6-only interfaces. If two LSR interfaces on the same LAN share the relevant low 20 bits, other LSRs are likely to misroute packets.

The same numeric context label on different LAN interfaces is not ambiguous. The ingress interface is part of lookup context. A global inventory that drops the interface can report a false collision; a LAN-local allocator that drops the interface scope can create a real one.

Both errors come from flattening scope. A uniqueness check needs the same key as the forwarding lookup. Global uniqueness may waste space and still fail to detect a same-LAN collision if the observation has already lost interface provenance.

Installed capability is not known peer support

Upstream assignment is optional. RFC 5331 prohibits its use unless the downstream LSR is known to support it, yet leaves the mechanism for establishing that knowledge to the application and label-distribution procedures.

Finding code, a configuration knob or an IANA number proves capability at most. It does not prove that this peer, tunnel and application agreed to use upstream assignment. The choice between upstream and downstream assignment also belongs to the application; adjacent routers must not use both directions for the same binding relation.

Record how support was learned, its scope and lifetime, and which application selected the mode. A stale capability cache can send valid upstream labels to a receiver that uses only a per-platform downstream table.

Sources and evidence boundary

These sources establish protocol rules, publication history and registry state. They do not establish a present implementation, tunnel, PHP setting, root address, context table, collision, misroute, multicast tree, forwarding result or delivery outcome.