Summary

  • RFC 3472 encoded GMPLS functions in CR-LDP REQUEST, MAPPING and notification procedures; a bidirectional setup could make the upstream direction usable before the downstream mapping returned.
  • A forwarded request, valid Upstream Label or first directional traffic was therefore a partial receipt, not proof that both directions, the physical circuit or the application service had completed.

A bidirectional path sounds like one object with one birth. RFC 3472 described something more interesting: a path whose two directions could become real at different moments.

The document, published on the Standards Track in January 2003, translated RFC 3471's protocol-independent GMPLS functions into CR-LDP messages and TLVs. It defined concrete forms for generalized label requests, labels, wavebands, suggestions, label sets, protection, administrative status and interface identity. Its closest contemporary alternative was RFC 3473's RSVP-TE encoding.

The asymmetry began in the REQUEST. To ask for a bidirectional LSP, the initiator included an Upstream Label. That label had to be valid for forwarding when the request was sent. Each receiving node checked whether it could accept the label. Before forwarding the REQUEST, an intermediate node had to allocate an outgoing upstream label and establish the internal data path joining the local segments.

This was not merely a promise to configure later. The request advanced only after every traversed node had made its local upstream portion usable. When the REQUEST reached the terminator, that node could immediately transmit traffic upstream toward the initiator using the supplied label.

The other direction followed a different chronology. Generalized downstream labels travelled back toward the initiator in MAPPING messages. Every recipient verified whether the mapped value was acceptable. An unacceptable value caused a notification and could include an Acceptable Label Set. The downstream direction therefore still depended on a successful return wave of selection, validation and installation while upstream traffic might already exist.

That partial state was legitimate protocol behavior, not automatically a fault. But it made the evidence language important. “Bidirectional request accepted” could mean that the request reached the far end and the upstream chain was usable. It did not necessarily mean that the last MAPPING had returned, that every downstream label had been installed, or that a two-way application exchange had succeeded.

RFC 3472 supplied other examples of state that looked stronger than it was. A Generalized Label Request carried LSP Encoding Type, Switching Type and G-PID. Ingress set the request; transit normally passed it; Switching Type could change hop by hop. Every node checked the incoming interface, itself and the outgoing interface or tunnel. Local policy decided whether a forwarding-adjacency tunnel could be used or created. No single forwarded REQUEST represented one identical check everywhere.

G-PID was normally examined at egress, with a penultimate-hop exception for packet switching and PHP. Absence of an error at an earlier transit node did not mean the payload type had already passed its decisive test.

Suggested Label was weaker still. Errors in the suggestion were ignored. If downstream returned another label, upstream had to reconfigure or reject the result. Most tellingly, ingress should not transmit data using the suggested label until a corresponding label came back from downstream. A head start for slow hardware was not allocation authority.

Label Set processing made physical meaning explicit. A TLV could add or exclude individual labels or ranges. No Label Set meant all labels were acceptable, not that all were available. Each node intersected the received set with resources on its downstream interface. An empty intersection terminated the request. A conversion-capable node could remove the set before forwarding.

Logical values also differed across links. The intersection had to be based on physical wavelengths or bands; a node either mapped logical values to a consistent physical meaning or discarded them. A trace containing only the surviving logical set could therefore omit earlier constraints and conversions.

Wavebands added a particularly physical transformation. A switch could mirror the wavelengths around a centre frequency. In that case it swapped the start and end labels so the far side knew that one end of the band emerged as the other. Bidirectional waveband tunnels required the operation in both directions. Matching interval sizes did not prove matching wavelength association.

Explicit Label Control bound a label ER-Hop to a preceding address or interface identifier. Wrong order, direction bits or duplicate direction entries produced route errors. The binding mattered because the label's meaning was not detachable from the interface. Yet the method by which the head end obtained the information remained outside the document.

Control and data separation created one more non-equivalence. IF_ID TLVs named data channels when signaling used another channel and returned in MAPPING. A control-session failure should not disturb existing optical connections, while recovery procedures were expected to preserve connection integrity. Thus a restored CR-LDP session did not prove the old cross-connect was correct, and a lost session did not prove the light had stopped.

Failure behavior exposed a design difference with RSVP-TE. CR-LDP had no equivalent of RFC 3473's rapid failure notification. RELEASE and WITHDRAW propagated outward and released resources; feedback could report actual resources. A teardown receipt mattered because RFC 3472 made both upstream and downstream labels invalid when the bidirectional LSP was removed. Hardware that continued forwarding afterward would be stale, not authorized continuation.

RFC 3468 later recorded the IETF decision to stop standards-track development of CR-LDP in favor of RSVP-TE. That institutional choice is part of Internet history, but it does not erase RFC 3472's engineering lesson or prove that every implementation vanished at once.

Heng Lu's running-code principle places the boundary correctly. A REQUEST, TLV or MAPPING is a symbolic coordination record until programmed paths and directional traffic confirm its effect. Minimum specification explains why local tunnel policy and technology details remained outside the common message grammar. Reality layers keep admission, allocation, internal cross-connect, mapping, traffic and application result from becoming one status.

An honest operator should record the request identity and route, every node's admission, each upstream allocation and internal connection, the terminator's first permitted transmission, every returning downstream mapping, both directions of observed traffic and the eventual removal. Only after both directions and the service boundary agree should “bidirectional” describe an accomplished service rather than the intention carried in the first REQUEST.

Sources