Summary

  • A summary refresh names Path or Resv state that has already been advertised in full. It renews a known description; it cannot introduce a new or changed reservation merely by repeating an old identifier.
  • An unknown identifier can prompt a request for the missing description. A recognised identifier attached to corrupted state can escape that test, a limitation RFC 2961 explicitly acknowledged.
  • Occasional full refreshes, restart-recovery procedures and later adjacency-failure detection preserved work that repetition had performed. Reducing maintenance traffic did not make that work unnecessary.

Everything on the list was found

Imagine a router receiving a list of identifiers. It recognises every one, finds the associated reservation state and extends the entries' lifetimes. No missing-state response is needed. The maintenance operation appears uneventful.

Now suppose one retained description is wrong internally, although its identifier remains recognisable. The short incoming message has not repeated that description. Its successful lookup does not necessarily reveal the error. The record can survive the operation without its contents having been presented again.

This is a thought experiment, not a reconstructed outage. Its basis is unusually explicit: section 5.5 of RFC 2961, published in April 2001, identifies internal state corruption as a possible gap between RSVP's summary refresh and its ordinary full refresh. The document does not pretend that a cheaper maintenance operation observes everything the more expensive operation did.

That qualification is the interesting part of the history. The change was not simply that a protocol had found a shorter way to say the same thing. It had separated saying “continue to retain this” from repeating what “this” contained.

Repetition had been doing two jobs

The original RSVP specification, RFC 2205 of September 1997, maintained Path and Resv state through periodic refreshes. Without refreshes for long enough, that soft state expired. Explicit teardown could release it sooner, but losing a teardown message was not supposed to leave an everlasting reservation.

The periodic full description also supplied recovery. Information lost or missed on an earlier exchange could arrive again. When routing changed, the appropriate signaling state had to be established along the new path. Repetition made the protocol less dependent on every individual transition being communicated perfectly the first time.

Those two jobs shared a cost. Many maintained states meant many descriptions to send and process. A longer interval reduced recurring work but could make repair and cleanup slower; a shorter interval bought more frequent opportunities at greater expense. Not all the repeated information was functionless duplication.

RFC 2961 drew a careful distinction between a trigger and a refresh. A new or changed state description required a trigger message. Even a change to a policy or ADSPEC object counted; an unchanged bandwidth figure did not necessarily mean that the whole description was unchanged. A refresh repeated existing information rather than quietly introducing a different decision under an old reference.

This constrained what could be abbreviated. Before a sender could refer to state in a summary, it had to advertise that state in a full Path or Resv carrying MESSAGE_ID. The later reference depended on an earlier description; it was not an instruction to infer a new one.

A shorter description, not yet a longer silence

Srefresh could list identifiers of previously advertised Path and Resv state. A receiver locating the corresponding state could refresh it without receiving every object again. For the state being summarised, ordinary repeated full messages could be suppressed.

The 2001 design did not, however, permit summary refreshes to be less frequent than the full refreshes they replaced. The immediate saving was in the description carried on each occasion. Treating this as simply an increase in the timer interval would import a later design into the earlier one.

The identifiers had a deliberately bounded meaning. MESSAGE_ID included an epoch as well as an identifier, and the generating address supplied its scope. For the original Path and Resv messages, that address came from RSVP_HOP, not necessarily the outer packet's IP source. A restart could introduce a different epoch rather than allowing an old execution history to be mistaken for the new one.

None of this made an identifier a digest of the retained content. It was not a global reservation title or an authentication code. It helped select a previously advertised state in the relevant context. Selection and verification of all the selected fields remained different operations.

Other extensions in the same document addressed other costs. Bundle put complete RSVP messages into one datagram; it did not merge their resource demands into one approved reservation. Acknowledgements and rapid retransmission improved delivery of individual messages. Packing, delivering and admitting were not interchangeable meanings of success.

An absence could request a description

When an appropriate receiver could not find the state cited by a summary, MESSAGE_ID_NACK identified the missing reference. A sender that still possessed the corresponding state had to transmit it in an ordinary Path or Resv. If it no longer had matching state, there was no description for the identifier alone to recreate.

This negative acknowledgement did not mean that a bandwidth request had been refused. It meant that a state reference could not be resolved. Conflating those meanings would turn a synchronization problem into a capacity diagnosis. Conversely, successful delivery of the replacement description would not by itself prove an end-to-end reservation had been admitted.

Multicast required another qualification. Not every receiver of a summary was supposed to hold every represented state. Source and group information, together with reverse-path checks, determined which recipients should participate. A node unrelated to the represented flow should not demand repair simply because it lacked a record it had never needed.

The repair channel therefore made a particular kind of absence visible. Its silence was not an unlimited statement about everything that remained present. A list could resolve cleanly while a retained description contained an error the list did not expose.

The specification kept the uncomfortable distinction

Section 5.5 explains that summary refresh deals with common events such as packet loss and routing changes without providing precisely the same recovery properties as full refresh. Internal corruption is its example of a problem that an ordinary description could potentially help repair while a summary might not.

The document offers two supplementary methods, and their differences matter. The first stores a checksum or another computed value over internal state when sending a trigger, then recomputes it later. It can reveal a state change that should have generated a message but did not. The text expressly says this method does not protect against internal state corruption. It covers a missed trigger, not every possible wrong memory value.

The second method is to continue sending complete Path and Resv refreshes occasionally. Their interval is longer than the summary interval, retaining the benefit of abbreviated routine exchanges while restoring the ordinary refresh's class of recovery opportunities. A full refresh need not be accompanied by a redundant summary of the same state in the same period. The relative frequency can be configured.

Combining these suggestions into a claim that “checksums verify the neighbour's state” would erase the qualification. Detecting an unannounced local change and returning a complete description to the exchange are different interventions. Neither certifies every aspect of a router's correctness.

The resulting arrangement is more subtle than an optimization abandoned in favour of the old behavior. Frequent maintenance can be cheap, while less frequent full descriptions renew the information available for repair. The price of that choice is that the two schedules no longer provide identical observations.

A genuine message could still omit the answer

Authentication does not make omitted content reappear. RFC 2747 treats RSVP message integrity and authenticated neighbours under its key assumptions. MESSAGE_ID is not that integrity mechanism, and integrity protection is not encryption for confidentiality.

Even a genuine summary from the expected neighbour remains a summary. Establishing who sent it does not establish that every locally retained field it references is correct. This is a historical distinction between protocol functions, not a recommendation to deploy the document's old cryptographic choices today.

An acknowledgement has a similar boundary. Invalid syntax must not be acknowledged, but a valid delivery response still does not measure the resulting data service. Resource and policy processing retain their own meaning. The protocol can improve confidence that a message arrived without issuing a certificate for everything the message describes.

Recovery could borrow memory, not invent forwarding

The October 2007 RFC 5063 extended GMPLS RSVP graceful restart with a revealing use of summaries. A downstream neighbour could help a restarted upstream controller by naming Path messages it had previously received. That reverses the ordinary summary's perspective: the neighbour was reporting old received information, not simply renewing what it had previously sent.

Recognisable references could reduce the amount of full recovery description required. A missing match could lead to the fuller RecoveryPath exchange. Capability indications and a recovery flag distinguished this procedure from routine refresh.

The downstream recollection nevertheless could not, by itself, create missing forwarding state. Recovery had to associate signaling with retained forwarding state. Creating a new forwarding arrangement required the appropriate separate upstream Path or ingress management instruction and applicable policy, not merely a convincing memory from below.

The security discussion also kept authentication separate from a correct mapping between pre-restart and post-restart information. A trusted neighbour could be identified without its reconstruction thereby being proved right. Recovering control-plane information was not the same observation as seeing traffic use the intended path.

Later designs reassigned the failure detector

The scaling analysis in RFC 5439, published in 2009, considers per-state memory and processing as well as signaling traffic. A long list still requires work on many identifiers. Reducing packet count does not make the individual reservations disappear, and the historical analysis supplies no universal capacity figure for current routers.

In May 2018, RFC 8370 coupled much longer refresh intervals with reliable message delivery, separate shorter treatment for unacknowledged Path and Resv messages, and explicit signaling-adjacency failure detection. When an adjacency fails, state learned through it is treated as expired.

That is not merely a larger value in a timer. Some of the work previously associated with periodic refresh has been assigned to a different mechanism. The stronger acknowledgement requirements belong to implementations of the new techniques; they cannot be retrospectively assumed of every older RFC 2961 node. A peer without the required capability retains traditional behavior.

The IANA RSVP parameter registry records the common message values, object classes and capability bits. Those allocations let implementations agree on meanings. They do not prove that a particular neighbour has enabled the feature. Support must be observed in operation, and its disappearance cannot be replaced by a memory that it was once present.

These documents establish designs and conditions, not universal adoption of every extension. Their history is one of separating duties more precisely. Keeping state alive, obtaining a missing description, detecting a failed neighbour and establishing a working reservation were related jobs. A shorter message became useful without becoming an answer to all of them.