Description

As part of RFC2961 , RSVP reliable messaging include an ACK, and a NACK message.
This document explains how the ACK, and NACK messages work.

Symptoms

To explain the meaning of RSVP ACK, and NACK messages - a part of reliable RSVP messaging.

Solution

Below are helpful snippets from RFC2961 :

Srefresh NACK

Srefresh NACKs are used to indicate that a received Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or MCAST_LIST object does not match any installed state. This may occur for a number of reasons including, for example, a route change. An Srefresh NACK is encoded in a MESSAGE_ID_NACK object. When generating an Srefresh NACK, the epoch and Message_Identifier fields of the MESSAGE_ID_NACK object MUST have the same value as was received.

MESSAGE_ID_NACK objects are transmitted as described in Section 4.6.

Received MESSAGE_ID_NACK objects indicate that the object generator does not have any installed state matching the object. Upon receiving a MESSAGE_ID_NACK object, the receiver performs an installed Path or Resv state lookup based on the Epoch and Message_Identifier values contained in the object. If matching state is found, then the receiver MUST transmit the matching state via a standard Path or Resv message. If the receiver cannot identify any installed state, then no action is required.


Example

 RRB                   RRB
{1,2,3} {1,3}
A -> SRefresh{1,2,3) -> B
<-- NACK{2.EN_US} <----
A -> Full Refresh {2.EN_US} -> B

Node A is aware of RSVP Sessions, corresponding to Message ID 1, 2, and 3. However, B only knows about states of Message ID 1, and 3.

When A sends a Summary Refresh with Message ID 1, 2, and 3 to B, B sends a NACK with Message ID 2 to A, as an indication that B needs information of RSVP session corresponding to that of Message ID 2.

After A receives the NACK message from B, A replies to B by sending a "Full Refresh" of an RSVP session corresponding to Message ID 2 to B.

Related Information