Summary

  • RFC 3477 gave RSVP-TE a way to specify and record point-to-point unnumbered links by pairing a stable Router ID with an endpoint-local Interface ID.
  • The two ends could choose unrelated numbers for the same link, while ERO intent, IF_ID resolution, RRO observation and forwarding reality remained separate receipts.

The phrase “unnumbered link” invites the wrong picture. It sounds like an absence: a connection that somehow escaped identity. RFC 3477 described almost the opposite. The point-to-point link had names, but neither endpoint's name was sovereign outside the machine that assigned it.

At one end, an LSR chose a non-zero 32-bit identifier. The LSR at the other end chose another. Each value had to be unique only within its assigning LSR. The specification was explicit that there was no prior relationship between them. The same wire could therefore be locally known as one number from A and a different number from B. Reverse the viewpoint and “local” and “remote” reversed too.

That modest rule carries a larger historical lesson. The Internet often scales by preserving narrow scopes rather than abolishing them. A local identifier is cheap to allocate and easy for one system to govern. It becomes meaningful to another system only when its scope travels with it. RFC 3477 supplied that scope with a stable Router ID, normally a loopback-style address intended to remain reachable whenever any route to the LSR remained.

The useful name was not the Interface ID alone. It was the tuple: the identity of the assigning router plus the value it assigned. That made two identical 32-bit values on different routers harmless, and two different values at opposite ends of one link legitimate. It also prevented a local administrative choice from masquerading as a global asset number.

The endpoints still needed to learn each other's choices. RFC 3477 allowed several paths for that knowledge: configuration, the Link Management Protocol, RSVP or CR-LDP when a forwarding adjacency was involved, and extensions to IS-IS or OSPF. If an IGP supported traffic engineering, its module and RSVP on the same LSR had to agree on the identifiers. The tuple was useful only if the joins behind it were maintained.

The first signaling receipt was route intent. RFC 3477 added an Unnumbered Interface ID subobject to the Explicit Route Object. Type 4, length 12, it carried the Router ID and the Interface ID assigned by that router. In an ERO, the tuple told a node which unnumbered link the path was meant to use. It was an instruction in the proposed route, not evidence that the link had been traversed.

The next receipt was local resolution. When a node selected an unnumbered outgoing link, it placed its Router ID and its own local identifier into an IF_ID RSVP_HOP object. The receiving LSR needed a table of the identifiers assigned by its neighbors. It matched the tuple from the message against that knowledge to determine the link on which label allocation belonged. If it could not match the tuple, RFC 3477 recommended an IF_ID error: code 24, value 16, “Unknown Interface Index.”

The error is important because it locates a failure without inventing a larger conclusion. It says that this receiver could not resolve this claimed neighbor-scoped name under its current knowledge. It does not, by itself, prove that the physical circuit was absent, that the sender lied, that an IGP was wrong, or that no alternate path existed. The mapping source and its time must be preserved.

RFC 3477 then created a parallel subobject for the Record Route Object. It used the same Type 4 and length 12 tuple, but performed a different evidentiary job. An ERO expressed where signaling intended to go. An RRO recorded the RSVP path state accumulated as the Path message progressed. Reusing the same encoding did not merge those acts.

The RRO flags sharpened the separation further. One bit meant local protection was available downstream. Another meant local protection was in use, usually because repair was maintaining the tunnel after an outage. Capacity to protect and activation of protection were different facts. A monitoring system that flattens both into “protected” discards the event that matters most.

Forwarding Adjacencies showed that the model was not limited to a bare physical port. An LSP advertised as an unnumbered forwarding adjacency also acquired one identifier at its head end and another at its tail end. The optional LSP_TUNNEL_INTERFACE_ID object, class 193 and C-Type 1, carried the forward identity in Path or the reverse identity in Resv. A constructed link still had two administrative viewpoints.

Later work placed these ideas inside a wider GMPLS and traffic-engineering architecture. OSPF and IS-IS extensions advertised local and remote identifiers; link bundling applied the scheme to component links; RFC 6107 later updated RFC 3477 for Path Key handling. Those documents help explain the lineage, but they cannot be projected backward as evidence of what a January 2003 implementation supported.

The discipline from Heng Lu's reality-layer notes is exact here: do not let a record borrow authority from the layer below it. A Router ID scopes a number; it does not prove current reachability. An ERO names intent; it does not prove traversal. An RRO records signaling state; it is not independent physical telemetry. A label allocation is not forwarding. A programmed interface is not traffic delivery.

An audit should therefore retain the raw RSVP message, session, direction, sender and time. Preserve ERO order, IF_ID tuple, neighbor mapping source, match result, Path and Resv state, label operation, RRO order and flags. Only then join those records to interface inventory, adjacency state, forwarding tables, alarms and traffic counters. Every join needs its own timestamp and provenance.

Most importantly, never detach the Interface ID from the router that assigned it. The 32-bit value is not a little global link address. Nor should the two endpoint values be normalized into an invented canonical number. Their difference is not database dirt; it is the architecture's record of who had the power to name what.

RFC 3477 belongs in Internet history because it turned a seeming absence into a disciplined form of plurality. The unnumbered link did not need one universal name. It needed both local names, their scopes, and a protocol careful enough to say which viewpoint it meant. That is a stronger design than pretending every useful identity must begin globally.

Sources