Summary

  • RFC 3475 required a processed Call Release to trigger release of every Connection associated with the Call.
  • Each Connection still used ordinary Label Withdraw and Label Release procedures, so a Call-level confirmation could not prove atomic signaling, resource cleanup, traffic cessation or service closure across the whole set.

One instruction can open many unfinished operations. RFC 3475 put that problem inside the control plane of an Automatically Switched Optical Network.

Published in March 2003, the document was Informational, not an Internet Standard. Its stated purpose was to document IANA code-point assignments for CR-LDP extensions selected by ITU-T ASON work. It explicitly left the rules for using those extensions to ITU-T documents. The distinction matters: this was a record of proposed protocol machinery, not evidence of universal deployment.

ASON separated a Call from its Connections. The Call described a relationship between parties. One or more Connections could realize that relationship with network resources. Under complete separation, a Call could even exist without a Connection. RFC 3475 introduced Call Setup and Call Release messages for operations on that upper object.

Call Release carried Source ID, Destination ID and CALL_ID. Any network entity could send it to terminate an established Call. A Notification with an appropriate status code reported Call release to the initiator. At first glance that looks like a single transaction with a single receipt.

The next sentence broke the illusion. Reception and processing of Call Release had to trigger release of all Connections associated with the Call. Those releases followed the normal CR-LDP procedure using Label Release and Label Withdraw messages. One upper-layer operation therefore expanded into a set of lower-layer state transitions.

RFC 3036 shows why the branches mattered. A downstream LSR used Label Withdraw to revoke a mapping, and the receiver had to answer with Label Release. An upstream LSR also sent Label Release when it no longer needed a mapping. These messages acted on peer, FEC and label state. They were not one global “everything is gone” bit.

If a Call had three Connections, each could be at a different point: one fully released, one waiting for a peer exchange, and one still retaining local state. RFC 3475 required all three to be released. It did not create an atomic receipt proving they completed simultaneously. A successful Call-level Notification and a complete Connection-level teardown ledger answered different questions.

Association timing was therefore evidence. The system needed a snapshot of every Connection belonging to the Call when release became effective. Reading an empty association list later was insufficient: it could not show how many branches existed, which finished first, which retried or whether one disappeared from inventory before its physical resources were cleared.

CALL_ID helped correlate the fan-out, but identity did not supply completion. The same identifier could bind the release request and the affected relationships. It could not testify that each peer processed Label Withdraw, that each label mapping vanished, that a cross-connect returned capacity, that optical signal ceased or that traffic and billing stopped.

Soft permanent connections added another boundary. Their user-to-network segments were provisioned while the network segment was established by the control plane. Releasing the controlled network Connection did not automatically describe what happened to permanent edge segments. A Call closure could therefore coexist with deliberately retained infrastructure.

Crankback, another RFC 3475 extension, reinforced the logic from the failure side. A Notification could carry an ER-HOP identifying where resource shortage blocked a Label Request, allowing the initiator to compute a route around it. The location of the blockage was useful evidence; it was not proof that the next request found resources or established a path. Location, decision and outcome stayed separate.

The security section said the document added no concerns beyond RFC 3036 and RFC 3212. That sentence should not be enlarged into an assurance claim. A valid status message did not authenticate physical resource state, commercial authority or service outcome beyond the security properties of the underlying session and implementation.

Later ASON documents refined the architecture, while RFC 4974 standardized RSVP-TE Call procedures. They cannot be projected backward to give RFC 3475 stronger status or different completion semantics. Nor do they prove that a named operator used its CR-LDP messages.

Heng Lu’s reality-layer discipline supplies the operational record. Call Release is an instruction at one symbolic layer. Processing it creates a decision. Each Label Withdraw and Label Release is a protocol receipt with limited scope. Local state deletion, hardware reprogramming, physical signal change, traffic observation and service closure occupy further layers. A shared CALL_ID can join the records; it cannot let the first receipt impersonate the last.

A defensible teardown ledger should freeze the associated Connection set at release time. It should retain sender, CALL_ID, Message ID, status Notification and processing node. For every Connection it should record peer, FEC and label scope, Withdraw and Release times, retries, state deletion and resource actions. Physical, traffic and customer observations follow separately. Only when every required branch has a bounded result may the system say the whole Call is closed.

Sources