Summary

  • RFC 3034 treated a run of Frame Relay label switches as a non-TTL segment: the core swapped DLCI labels without decrementing MPLS TTL, so a boundary had to account for the hidden hops.
  • LDP could propagate a segment Hop Count to the ingress, which subtracted the length before unicast entry; the mapping and count remained control-plane claims rather than observed packet-path receipts.

The old switch could do the operation that made it useful and not the operation that made a routed loop expire. It could look up an incoming Frame Relay DLCI, replace it with an outgoing DLCI and send the frame onward. Its hardware generally could not decrement a packet's TTL. Once that switch became an MPLS Label Switching Router, the missing subtraction became a protocol problem.

RFC 3034, published in January 2001 as a Proposed Standard, solved that problem by changing where the accounting occurred. A sequence of same-level Frame Relay LSRs did not decrement MPLS TTL at every switch. The RFC called it a “non-TTL segment”. For unicast, the entrance to that segment could subtract the segment's entire advertised length before the packet entered.

The current label lived in the DLCI

Frame Relay hardware already switched on the Data Link Connection Identifier in its link-layer header. RFC 3034 placed the current MPLS label there. Other labels and the remaining current stack fields used generic MPLS encapsulation. At a core FR-LSR, the device looked up the DLCI, substituted the output DLCI and forwarded the frame.

This produced a split representation. The DLCI carried the label value on which the switch acted. The top stack entry still carried current TTL and other fields, but not the operative label value. At a boundary to another encapsulation, an LSR had to decode the logical stack, perform the MPLS operation and encode it for the next link. A heterogeneous LSP could therefore represent the same logical label stack differently on successive hops.

At egress, if the popped label was the last, the stack contained no explicit network-layer protocol identifier. The protocol had to be inferred from the label association. A label binding consequently carried parsing consequences as well as a forwarding choice. It did not authenticate the packet, authorize the route or prove that a frame had travelled the expected circuit.

Hidden hops still had to consume scope

MPLS TTL served two purposes in the document: suppress loops and limit packet scope. A labelled packet was supposed to emerge with the value it would have after the equivalent sequence of routers. Letting five Frame Relay switches count as zero forever would break that model even if every DLCI swap was locally correct.

RFC 3034 expressed the boundary calculation as output TTL = input TTL - d. The decrement depended on input, forwarding and output encapsulations. A same-level Frame Relay core operation used zero because the charge was moved elsewhere. A generic MPLS forwarding hop normally used one. Entry into a non-TTL Frame Relay segment could use the number of hops in that segment.

For unicast, a meaningful length was propagated to the ingress. It subtracted that value before forwarding the packet into the segment. For multicast, the length was propagated to the egress, which performed the boundary accounting there. The location of the debit differed because the forwarding cases differed; the invariant was that hidden switch hops should not vanish from scope control.

The ingress could refuse entry before expiry

Prepayment made one decision possible before the first DLCI swap. If subtracting the unicast segment length showed that TTL would expire before egress, the ingress was forbidden to label-switch the packet into the non-TTL segment. It instead followed the label-stack rules in an attempt to return an ICMP error or forwarded the packet unlabeled with TTL reflecting network-layer forwarding. With an incoming TTL of one, only the error path applied.

That language defines actions, not outcomes. “Attempt to return ICMP” is not evidence that the source received the message. “Forward unlabeled” is not evidence that another path delivered the packet. The useful receipt is narrower: the ingress made a boundary decision from an input TTL and a segment-length value.

LDP supplied a count, not telemetry

The segment length could come from the LDP Hop Count object associated with a label binding. An egress began with one. Each known upstream step incremented the downstream count. If a value exceeded the maximum, the FR-LSR could not pass the binding farther upstream and had to signal an error.

Ordered control waited for a downstream mapping before replying upstream, making an incremented count available with the binding. Independent control could advertise earlier with Hop Count marked unknown, then send the correct value later. If LDP supplied no count or an unknown value, RFC 3034 used a default of one for the calculation it described.

That default did not discover a one-hop path. It supplied a bounded behaviour when the control plane lacked a meaningful length. The distinction is central: a Hop Count object is a claim assembled during label distribution. It is not per-packet observation, traceroute, proof that every switch is live or proof that the next packet follows the same route.

Route changes made freshness part of safety

The count could change after an upstream binding already existed. Independent control might replace unknown with a known value. A route calculation might select a new next hop and obtain a mapping with a different length. RFC 3034 required that change to propagate toward ingress. If a new count exceeded the maximum, bindings for the forwarding equivalence class had to be withdrawn upstream so that loop detection was not built on an impossible number.

Failure also removed authority. If a downstream request could not be satisfied, a provisional binding should be destroyed and withdrawn. Losing an LDP session required learned binding information from that connection to be discarded. Liberal retention allowed reuse only under the document's matching route and Hop Count condition.

A stored label therefore had a lifecycle. Its existence in a Label Information Base did not prove that its downstream dependency still existed, that its Hop Count was current or that data-plane traffic succeeded.

Adapting hardware did not erase layers

RFC 3034 let a Frame Relay switch participate in network-layer routing and label distribution while continuing to use the hardware field it could switch efficiently. Traditional Frame Relay control and label-switching control could even run independently on the same device and interfaces, sharing only bounded resources such as divisions of DLCI space. The combined operation was outside the RFC's scope.

This was not a claim that symbolic control had replaced running behaviour. It was an engineering bargain: where the core could not decrement, the boundary would account for the segment. The bargain remained credible only if route, binding, Hop Count, ingress subtraction, actual path and egress value stayed separately observable. The ingress paid up front. Reality still had to deliver the journey it was charged for.

Sources

Lu Heng did not author or endorse RFC 3034 or the related standards. His essays are used here as disclosed analytical lenses.