Summary

  • RFC 3038 addressed a mismatch: ATM's local VPI/VCI labels could be rewritten along a path, while an LDP mapping between neighboring ATM-LSRs needed one value both ends could associate with the same VC.
  • Its inband point-to-point procedure did not trust an unacknowledged proposal: PROPOSE, matching ACK and LDP REQUEST completed a three-way exchange before the downstream mapping carried the VCID.

One circuit, several local names

In January 2001, the MPLS standards set was trying to make ATM switches act as label-switching routers. That fit hardware which already forwarded cells by looking at VPI and VCI fields. But the field that moved a cell through one ATM link was not necessarily a name that survived the next switch. In the general case, each switch could replace the label with a new local value. An LDP peer receiving a label-mapping message therefore could not use a single VPI/VCI value as an end-to-end identifier for the virtual circuit.

RFC 3038 inserted a second name beside the local one: the Virtual Connection Identifier, or VCID. Its defining property was modest and precise. The same VCID value would be associated with the VC at both ends. It did not replace every ATM label in the data plane. It let adjacent ATM-LSRs say which local incoming or outgoing label referred to the VC they were coordinating, then carry that identifier in LDP's label information.

That distinction matters because the VC and its labels were not created by this notification. The document begins after a VC has been established, either through signaling or management. The notification then joins the two peers' local label state. Only after that association can LDP request and return a mapping using the VCID. A setup message, a local VPI/VCI, the shared VCID, an LDP mapping and packets actually crossing a path are different pieces of evidence.

The acknowledgement was not the last word

For an inband point-to-point VC, the upstream node selected a VCID and sent a VCID PROPOSE message with a message ID through the newly established circuit. Each end associated the proposed ID with its own local label. The downstream node then returned an ACK containing the VCID and message ID it had received. The upstream checked that pair; if the expected acknowledgement did not arrive, it retransmitted the proposal.

The surprising step came after the ACK. The upstream sent an LDP REQUEST carrying the proposal's message ID. The downstream treated that request as evidence that the upstream had received the ACK. RFC 3038 explicitly says the three-message exchange is needed because the PROPOSE transmission is unreliable. Without the final return leg, the downstream could know it had sent an acknowledgement without knowing whether the initiator had heard it. Until the REQUEST arrived, the downstream discarded packets on the VC other than the VCID PROPOSE itself.

Once the exchange completed, LDP Mapping could carry the VCID in its label TLV. The handshake was therefore not an application-level success receipt. It established a specific control-plane association between two neighboring nodes and closed a delivery ambiguity in the negotiation. It did not show that the VC carried user traffic, that every switch along a larger path agreed, or that an application received data.

Not every ATM connection needed the same ceremony

RFC 3038 did not impose one procedure on every link. A transparent direct point-to-point link, where both ends already used the same VPI/VCI, needed no notification. A virtual path could use inband notification or a VPID procedure; in a narrow single-VP case the shared VCI could serve directly. A permanent virtual circuit used inband notification. A switched virtual circuit could carry the VCID in a signaling field large enough for it, use a smaller temporary field, or fall back to an inband message.

Direction also mattered. The upstream end initiated notification. A bidirectional label-switched VC required one procedure in each direction; a unidirectional one required only the permitted direction. The standard thus treated “same circuit” as a relation that had to be established across each relevant pair of peers, not as a universal label magically visible throughout the ATM cloud.

The small-field option makes the difference between temporary correlation and durable association especially visible. In ATM signaling, the BLLI user-specific field could temporarily identify a circuit while a full VCID was exchanged. It had to remain unused by another incomplete transaction with that peer, but once the VCID association completed the BLLI value could be reused. In a multipoint case, BLLI was unique at the sender, not globally unique at the receiver; the receiver also needed the sender ATM address to disambiguate it. A scarce temporary token was safe to recycle only after the more durable mapping had been established.

The RFC also defined VPID notification for a virtual path. After that procedure, a VCID could be formed from the VPID and VCI, allowing LDP to use the constructed identifier without a separate VCID exchange for each VC. These are alternate ways to align control-plane identity with link structure, not evidence that every network deployed each option.

A useful historical boundary

RFC 3033, published in the same month, assigned typed identifiers used in ATM call signalling for sessions and resources. RFC 3038 solved a different problem: reconciling local ATM labels between neighboring LDP peers after a VC existed. RFC 3036's FEC definitions and the broader MPLS label architecture are different again. Keeping these mechanisms separate avoids making “identifier” a catch-all for setup, packet classification, local forwarding and delivery.

RFC 3038 described point-to-multipoint notification as future use while stating that the then-current LDP specification did not support multicast. It also warned that a non-VC-merge switch might have to split an active LSP temporarily to send an inband message when a leaf was added, with potential performance and QoS problems. Those passages describe design constraints, not a field measurement or proof that the procedure was deployed.

The RFC Editor currently lists RFC 3038 as a Proposed Standard and notes that RFC 7274 updates it. That later document addresses the allocation and retirement of special-purpose MPLS labels and updates older use of the term “reserved label”; it should be included when reading label terminology, not inflated into evidence that RFC 3038's VCID handshake was withdrawn. Neither document names a deployed implementation, reports interoperability tests or counts use.

The historically defensible result is narrower: when the ATM label could be local to a hop, MPLS control needed a shared peer-level identity, and the specification made its agreement observable through a small, explicit exchange.

Sources

The Heng Lu essays are disclosed analytical frames only; Lu did not author or endorse RFC 3038.