Summary

  • RFC 3473 let an RSVP-TE fault Notify reach a recorded non-adjacent node directly and use RFC 2961 acknowledgement machinery to confirm receipt.
  • The document also said Notify did not replace PathErr or ResvErr, so an ACK was evidence that an alarm arrived—not that state converged, protection switched, traffic returned or the application recovered.

An alarm can outrun the repair it describes. RFC 3473 made that distinction visible in protocol form.

Published in January 2003, the document encoded GMPLS functions in RSVP-TE. It carried much of RFC 3471’s generalized-label model into Path and Resv messages: labels for packet, time-slot, wavelength and port switching; bidirectional setup; label constraints; protection attributes; separated control channels; administrative state; and restart recovery. Its closest sibling, RFC 3472, performed the same job for CR-LDP.

One RSVP-TE addition solved a specific problem. Ordinary PathErr and ResvErr messages followed RSVP state hop by hop. The node that most needed to react to an explicitly routed LSP failure might be several hops away. Waiting for the ordinary error route could delay a decision at the ingress or another designated controller of the path.

RFC 3473 therefore defined a Notify Request object. A Path message could request upstream notification; a Resv message could request downstream notification. The object named an IPv4 or IPv6 Notify Node. Each receiver should store that address with the relevant state, and a transit node should carry a request onward.

This was not a permanent end-to-end identity. Local policy could change the outgoing Notify Node address. If a message carried several Notify Request objects, only the first was meaningful; the rest could be ignored and should not propagate. Most importantly, carrying the request did not guarantee that a Notify would ever be generated.

When a qualifying error occurred, the detecting node could send a Notify to the recorded non-adjacent destination. Intermediate non-target nodes forwarded it unchanged, or the sender could encapsulate it in a new IP header addressed directly to the target. The message omitted the router-alert option. The fault report had acquired a route distinct from the hop-by-hop path of the failure it described.

The Notify contained an ERROR_SPEC and session information. The ERROR_SPEC identified the error and the detecting node or failed link. Sender or flow descriptors bounded the affected RSVP session. One physical event could produce notices in both directions, but the node was forbidden to invent them unless the appropriate prior request existed.

RFC 2961 supplied reliable-delivery machinery. Message identifiers made a Notify distinguishable, and the receiving Notify Node should return an Ack. That exchange answered a valuable question: did this RSVP message reach this destination?

It did not answer the questions operators are often tempted to attach to an acknowledgement. The Ack did not say the ERROR_SPEC was physically correct. It did not say every intermediate RSVP state had been removed or refreshed. It did not say an alternate path had capacity, a protection switch had happened, an optical cross-connect had moved, packets were flowing, or the application had resumed.

RFC 3473 made the boundary explicit: Notify did not replace existing error messages. A failure that triggered PathErr or ResvErr could also trigger Notify. The rapid message was a supplemental evidence path, not a commit record for the ordinary RSVP state machine.

The distinction appears again in the Path_State_Removed flag. Traditional PathErr forwarding did not necessarily make intermediate nodes act. RFC 3473 allowed a node to report that it had actually discarded the associated Path state. A received Notify and a PathErr carrying state-removal evidence were therefore different receipts. Neither one alone described every hop.

Notification aggregation introduced another layer. A node should try to combine notices bound for the same Notify Node and sharing the same ERROR_SPEC. The grouping method was implementation-dependent: event-driven, timer-driven or something else. A timer-based implementation had a default interval of one millisecond. This could lower control load during a serious outage, but it meant message time was not automatically event time, and one envelope could summarize several sessions without making their recoveries atomic.

Administrative status showed why receipt required follow-up. An intermediate or egress node could send a Notify carrying Down state. The sender then had to verify that a corresponding Path message with Down returned within a configurable period, thirty seconds by default. If that confirming state failed to appear, the node should tear down downstream state and send a tear or error upstream. The protocol did not mistake its first alarm for completion.

Control-channel faults added a subtler example. During a restart wait, a neighbor could preserve existing RSVP and forwarding state as though refreshes continued. It might notify upstream nodes that the control channel was degraded and later active. A degradation notice did not mean the data plane had failed; an active notice did not mean all state had been reconciled. The same word “recovered” could refer to communication, RSVP state, label programming, physical signal or delivered traffic.

The direct route also changed security assumptions. RSVP’s ordinary integrity model was hop by hop. A non-hop-by-hop Notify could bypass that chain, so RFC 3473 pointed to IPsec for equivalent end-to-end integrity and authentication, or allowed direct Notify to be disabled. Even an authenticated, acknowledged alarm proved bounded facts: a holder of the relevant key sent a particular message, and a particular receiver obtained it. It did not authenticate the underlying photon, packet or business outcome.

Later documents made recovery more explicit. RFC 4090 described fast reroute; RFC 4872 treated end-to-end recovery; RFC 4873 treated segment recovery. Those standards supplied additional control actions and scopes. They did not collapse notification, selection, switching and observed restoration into one fact.

Heng Lu’s running-code principle places the line cleanly. The received Notify is symbolic evidence until the intended state transition is observed in the systems that must enact it. Minimum specification explains why RFC 3473 could standardize the alarm grammar while leaving aggregation and policy local. Reality layers prevent a successful ACK from borrowing the authority of a repaired service.

An honest incident record should preserve the Path or Resv that installed the request, the effective destination after any policy rewrite, the detector and ERROR_SPEC, every session descriptor, Message ID, send time, receipt and Ack. It should separately retain PathErr or ResvErr progress, state-removal evidence, protection or teardown decisions, programmed hardware, physical signal, directional traffic and the application result. Only the last joins can justify “recovered.” The ACK belongs much earlier in the story.

Sources