Summary

  • Uniform propagates hop-limit state across the label boundary, keeping tunnel LSRs visible to traffic outside the LSP.
  • Pipe is intended to make the tunnel appear as one hop; Short Pipe differs at the egress, where the carried packet is treated as crossing an ordinary forwarding hop.
  • RFC 3443 defines no model-signaling mechanism. The operator selects the model through configuration or a management interface, and ordinary decrement and drop checks still constrain forwarding.

The mechanism starts with a local decision, not with signaling between peers. At ingress, a label push follows the selected model. Transit LSRs swap labels and process the relevant TTL state. At the exit, a pop—possibly a penultimate-hop pop (PHP)—must leave the packet with the treatment specified for the model. RFC 3032 supplies the label-stack encoding context, while RFC 3270 is relevant operational context for MPLS treatment of differentiated services; neither turns TTL behavior into route authorization or peer authentication.

In Uniform mode, the MPLS and carried-packet TTL state are propagated across the label boundary. As a result, intermediate LSRs remain visible to traffic outside the tunnel. This supports a path view that includes the tunnel interior, subject to correct implementation and the actual path.

Pipe takes the opposite abstraction. A tunnel is intended to look like one hop to traffic outside it, regardless of how many LSRs it crosses. A Pipe or Short Pipe push uses an operator-configured TTL for the new label rather than copying the TTL from the header below. RFC 3443 notes that many implementations used 255 at the time of publication, but 255 is a historical implementation tendency, not a universal mandate.

Short Pipe changes the exit treatment. The carried packet header is handled as though the tunnel egress were an ordinary forwarding hop, including the specified decrement. The RFC describes equivalent end-to-end decrement behavior with and without PHP when the procedures are applied correctly. The common rule remains important: outgoing TTL is normally incoming TTL minus one, and a packet is not forwarded when the outgoing TTL check fails.

The correctness hazard is at boundaries. A PHP implementation may remove the top label before the next device performs the operation expected by the selected model. A hierarchical label stack adds further boundaries: inner and outer labels must each receive the appropriate push, swap or pop treatment. A partial or inconsistent implementation can therefore produce surprising expiry, visibility or traceroute results without changing the intended configuration. An omitted tunnel hop does not by itself prove Pipe or Short Pipe, identify the path, or show that every device implemented the model consistently.

A concrete verification fixture should compare the same controlled flow under each configured model, record the initial pushed-label TTL, inspect label-stack depth and operation at ingress, transit and egress, and observe the carried packet TTL before and after PHP. Include a low-TTL probe that should fail at the expected check, a multi-label fixture for hierarchical-stack behavior, and a path comparison with PHP enabled and disabled where the platform permits that test. These are verification fixtures, not mandatory thresholds or vendor commands.

The operator decision path is: first define whether tunnel-internal visibility is required for operations; then select Uniform, Pipe or Short Pipe; record the configured initial TTL without assuming 255; verify push, swap, pop and PHP behavior at every relevant boundary; test expiry and multi-label cases; and document what external observers should infer. The model controls visibility and hop-limit propagation only. It does not establish an LSP, authorize a route, authenticate an endpoint or peer, grant access, override forwarding policy, encrypt traffic or create a security perimeter.

The RFCs do not establish current deployment prevalence, a universal vendor default, a measured incident-reduction rate or a universal policy for hiding versus exposing hops. RFC 3443 also says its clarification introduces no new security issues beyond the MPLS specifications it references.

Sources