Summary

  • RFC 3474 proposed a CALL_ID that could remain constant for the life of an ASON Call and, in one form, be globally unique across operators and nodes.
  • That durable name identified a relationship. Its Connections, RSVP state, local labels, installed resources, physical continuity, traffic and delivered service still required separate evidence.

A record can outlive the thing people imagine it represents. In March 2003, RFC 3474 showed how this happens inside a network control plane.

The document was published as Informational, not as an Internet Standard. It proposed IANA assignments and extensions to GMPLS RSVP-TE for Automatically Switched Optical Network requirements. Its ambition was broad: soft permanent connections, a distinction between Calls and Connections, restart behavior, additional errors and ways to traverse boundaries where neighboring control domains did not share the same technology or policy.

The word “Call” was doing careful work. Existing GMPLS signaling could establish a Connection: a concrete association of resources that carried traffic. An ASON Call was instead a relationship between endpoints, managed by a Call controller. A Connection controller could create one or more Connections under that relationship. The administrative or commercial relationship and the resources used to realize it were not the same object.

RFC 3474 gave this upper-layer relationship a CALL_ID. It defined an operator-specific form and a globally unique form. The global construction combined an ISO country code, an ITU carrier code, an access-point code controlled by the organization, a source LSR address and a local identifier. The last component was 64 bits and was to remain constant for the life of the Call.

That construction sounds authoritative because it joins several namespaces. Yet every field answered an identity question, not an operational one. It could distinguish this Call from another Call. It could help two controllers refer to the same relationship. It did not reserve a wavelength, configure a cross-connect, illuminate a fiber, transmit a packet or satisfy a customer.

Even the scope of uniqueness required care. An operator-specific CALL_ID could become globally unique when its source LSR address was itself globally unique. The RFC immediately warned that this guarantee did not hold when an operator used an address meaningful only inside its own network. Syntax could express an intended scope; the allocation context still determined what the identifier could safely claim.

Assignment also had a visible authority boundary. An initial user could place zero in the CALL_ID. The first network node then assigned a value, or checked an already non-zero value. Intermediate nodes were expected to pass the object onward without alteration, including nodes that did not understand the ASON extension. The destination retained it as a reference for later actions. Continuity across Path, Resv, PathTear, PathErr and Notify messages made the relationship traceable. It did not make every message report the same Connection state.

In the basic separation model, a Call normally had one or more Connections. Zero Connections could occur transiently, notably during break-before-make restoration. The old Connection could be removed before the replacement came into existence, while the Call relationship and its CALL_ID persisted above that gap. An inventory system that equated the Call row with a working circuit would therefore display continuity precisely when the data-bearing layer had none.

RFC 3474 then described an optional, more complete separation through CALL_OPS. Here a Call could be established or synchronized without simultaneously creating a Connection. Its steady state could contain zero, one or many Connections. This was not a loophole in the architecture. It was the architecture stating directly that a relationship and connectivity have different lifecycles.

The distinction mattered at control boundaries. The Call controller decided whether to maintain the relationship, admit a party or synchronize state. The Connection controller handled resource-bearing Connections. One authority could accept a Call while another could refuse, delay, replace or tear down a Connection. Combining their decisions into a single “up” field would erase who decided what.

SPC_LABEL exposed a similar separation at the edge of a soft permanent connection. The object could associate a permanently provisioned ingress segment with a switched segment. But the association mechanism was local policy outside the proposal. Across non-GMPLS subnetworks, labels were local to a control-plane node and might be provisioned manually or discovered before signaling proceeded. The same Call could therefore span several local naming and resource regimes without any one label becoming an end-to-end proof.

Restart behavior added more possible sources of apparent continuity. A controller might reconstruct information from persistent Call or Connection storage, infer state from a neighbor, or receive an instruction from management. Each source had a different evidentiary strength. A recovered CALL_ID could show that the controller remembered a relationship. It could not by itself show that the neighbor agreed, the RSVP transaction completed, the hardware retained its programming or the physical signal survived.

Notifications did not collapse the layers either. CALL_ID could travel in Notify alongside sessions belonging to the Call, and one Notify could contain sessions associated with several Calls. The message envelope, the Call identity and each Connection state remained separate. A notification about one layer did not automatically certify another.

The standards lineage requires disciplined chronology. RFC 4139 later documented ASON applicability and requirements. RFC 4974, published on the Standards Track in 2007, specified fuller Call signaling and stated explicitly that a Call did not itself provide traffic connectivity; it could have zero, one or many Connections. RFC 6004 later built further UNI extensions around those procedures. These documents show refinement and continued need. They do not retroactively turn RFC 3474 into a standard or prove that a named carrier deployed its proposal.

This is where Heng Lu’s distinction among symbols, decisions and operational reality becomes practical. A globally unique identifier is a powerful coordination symbol. A Call controller’s admission is a decision. A Connection controller’s successful signaling is another decision. Installed resources, physical continuity, directional traffic and application delivery are observations. They may be joined, but none can inherit the authority of the next layer merely because the database uses one key.

A defensible record therefore begins with separate timelines. Preserve who assigned CALL_ID, which form and uniqueness scope it used, the source LSR address context, and when the Call began and ended. Record Call-controller policy and admission separately. Give every Connection its own identity, association interval, RSVP messages, label mappings, resource programming and teardown evidence. Then attach physical-signal, traffic and service observations to the Connection they actually measured.

That model can represent a Call with no Connection without calling it an outage by mistake. It can represent two replacement Connections under one Call without calling them the same circuit. It can show that an identifier remained stable while the resource path changed. Most importantly, it can answer the operational question RFC 3474 did not pretend to answer: not merely what relationship the controllers named, but what connectivity existed at a particular time.

Sources