Summary

  • RFC 2129’s PROPOSE and PROPOSE ACK established a neighbour-local VCID and tested a Dedicated-VC; only a subsequent OFFER and READY associated a particular source–destination IPv4 flow with that circuit.
  • The mapping needed refresh and could be refused or removed. Neither receipt proved an end-to-end route, a continuing capacity reservation, delivered packets or a QoS result.

Two answers from one neighbour

Imagine the upstream router has already set aside a virtual circuit. That is a physical or logical opportunity, not yet a forwarding instruction. It sends PROPOSE down that Dedicated-VC with a virtual-connection identifier, or VCID, and the downstream router’s target IP address. The neighbour answers on the ordinary Default-VC. Its PROPOSE ACK says the two ends can identify the same local circuit; the procedure also probes whether that circuit and the neighbour are operating. It says nothing about which packet flow should occupy the circuit.

Only then does the upstream router send an OFFER on the Default-VC, naming both VCID and flow-ID. A READY reply indicates that the downstream neighbour accepted the offer and can receive that flow on the Dedicated-VC. This is the consequential separation in RFC 2129: the first receipt is about a circuit between neighbours, the second about one flow’s use of it. Sending the offer is not receiving readiness; even readiness is not proof that packets crossed the rest of a route.

The memo was Informational, not an Internet Standard, and described FANP as a protocol between adjacent nodes. Its example of three routers repeats the negotiation independently on the next hop. A local success cannot be promoted into a single Internet-wide path guarantee. The Default-VC remains available for conventional hop-by-hop forwarding, while the Dedicated-VC lets a compatible cell-switch router bypass ordinary IP-header processing for the selected stream. The purpose was speed at a particular forwarding point, not a new source of routing authority.

The cost of being ready

Before either exchange, a local trigger could make the upstream node seek a Dedicated-VC. The memo discussed TCP/UDP port identifiers under local policy as possible triggers, typically for long-lived or voluminous sessions. It offered two ways to obtain the circuit: take one from a pool established in advance, or establish one through ATM signalling when needed. A prepared pool shortened activation time while consuming more VC resources; on-demand setup conserved idle circuits but incurred setup work. That was a node’s resource-versus-responsiveness choice, not an economic benefit demonstrated for a deployed network.

The identifiers were narrower than their names may suggest. The defined flow-ID held source and destination IPv4 addresses; the RFC explicitly distinguished it from an IPv6 flow label. The VCID identified a datalink connection between two neighbours even when local VPI/VCI values differed at the endpoints. Neither identifier authenticated an origin or described every router on a path. The memo left aggregate flows, multicast, IP-level QoS signalling and IPv6 support for future work. Calling FANP an IPv6 or RSVP guarantee would reverse the status of its own open questions.

A shortcut on a lease

Both receipts could fail. The downstream side could refuse a proposal by policy or reject an unknown VCID type; mapping resources could be unavailable. The offer could fail for an unknown VCID or flow-ID type, local policy, an unsupported refresh interval or insufficient resources. The upstream side retried unanswered exchanges; after the recommended five retransmissions without the expected reply, it released the selected circuit. No ACK or READY should be silently inferred from a transmitted request.

Readiness was not permanent either. While receiving packets on the Dedicated-VC, the downstream neighbour was to send periodic READY refreshes; without packets it did not send them. The upstream node removed the flow-to-VCID mapping after a dead interval without refresh. The downstream node could remove its mapping after a longer period with no incoming packets, covering a silent upstream failure. The RFC’s example of two-, six- and twenty-minute intervals was a recommendation with an ordering constraint, not a universal service promise. Explicit REMOVE/REMOVE ACK or ATM connection release offered other exit paths, depending on circuit type.

The historical insight is an evidentiary one. A trigger shows interest; an existing VC shows capacity selected locally; PROPOSE ACK shows a circuit-and-neighbour receipt; READY shows a flow-specific acceptance at that hop; a later refresh shows that a condition was still observed for a time. Those states are distinct from authenticated origin, consistent agreements at every hop, delivery to the endpoint, enduring capacity, QoS or measurable savings. RFC 2098 described the neighbouring bypass architecture. RFC 2129 exposed the continuing neighbour-to-neighbour reconciliation that such a shortcut needs. It did not make the shortcut self-validating.

Sources