As per Relevance of the word extension, we have this rfc below:
Network Working Group L.
Request for Comments: 2961 LabN Consulting,
Category: Standards Track D.
Juniper Networks, Inc
G.
Cisco Systems, Inc
P.
Juniper Networks, Inc
F.
S. University of
April 2001
The reliability and latency problem occurs when a non-refresh
message is lost in transmission. Standard RSVP [RFC2205]
from a lost message via RSVP refresh messages. In the face transmission loss of RSVP messages, the end-to-end latency of signaling is tied to the refresh interval of the node(s)
the loss. When end-to-end signaling is limited by the interval, the delay incurred in the establishment or the change of reservation may be beyond the range of what is acceptable for applications
One way to address the refresh volume problem is to increase
refresh period, "R" as defined in Section 3.7 of [RFC2205]. Increasing the value of R provides linear improvement on overhead, but at the cost of increasing the time it takes
synchronize state
An additional issue is the time to deallocate resources after a
message is lost. RSVP does not retransmit ResvTear or messages. If the sole tear message transmitted is lost,
resources will only be deallocated once the "cleanup timer"
has passed. This may result in resources being allocated for
unnecessary period of time. Note that even when the refresh
is adjusted, the "cleanup timer" must still expire since messages are not retransmitted
The extensions defined in this document address both the
volume and the reliability issues with mechanisms other
adjusting refresh rate. The extensions are collectively referred
as the "Refresh Overhead Reduction" or the "Refresh Reduction extensions. A Bundle message is defined to reduce overall handling load. A MESSAGE_ID object is defined to reduce
message processing by allowing the receiver to more readily
an unchanged message. A MESSAGE_ACK object is defined which can
used to detect message loss and support reliable RSVP
delivery on a per hop basis. A summary refresh message is defined
enable refreshing state without the transmission of whole messages, while maintaining RSVP's ability to indicate when state
lost and to adjust to changes in routing
When set, indicates that this node is willing and capable receiving all the messages and objects described in document. This includes the Bundle message described
Section 3, the MESSAGE_ID objects and Ack messages
in Section 4, and the MESSAGE_ID LIST objects and
message described in Section 5. This bit is meaningful
between RSVP neighbors
Nodes supporting the refresh overhead reduction extensions must
take care to recognize when a next hop stops sending RSVP
with the Refresh-Reduction-Capable bit set. To cover this case
nodes supporting the refresh overhead reduction extensions
examine the flags field of each received RSVP message. If the
changes from indicating support to indicating non-support then
unless configured otherwise, Srefreshmessages (described in
5) MUST NOT be used for subsequent state refreshes to that
and Bundle messages (Section 3) MUST NOT be sent to that neighbor
Note, a node that supportsreliable RSVP message delivery (Section 4)
but not Bundle and Srefreshmessages, will not set the Refresh
Reduction-Capable bit
RSVP Bundle messages can only be sent to RSVP neighbors that bundling. Methods for discovering such information include: (1)
manual configuration and (2) observing the Refresh-Reduction-
bit (see Section 2) in the received RSVP messages. RSVP messages MUST NOT be used if the RSVP neighbor does not support
Bundle messages
RSVP Bundle messages are sent hop by hop between RSVP-capable
as "raw" IP datagrams with protocol number 46. The IP source
is an address local to the system that originated the Bundle message
The IP destination address is the RSVP neighbor for which the sub messages are intended
RSVP Bundle messages SHOULD NOT be sent with the Router Alert
option in their IP headers. This is because Bundle messages addressed directly to RSVP neighbors
Each RSVP Bundle message MUST occupy exactly one IP datagram,
is approximately 64K bytes. If it exceeds the MTU, the datagram
fragmented by IP and reassembled at the recipient node
Implementations may choose to limit each RSVP Bundle message to
MTU size of the outgoing link, e.g., 1500 bytes.
SHOULD also limit the amount of time that a message is delayed
order to be bundled. Different limits may be used for trigger
standard refresh messages. Trigger messages SHOULD be delayed
minimal amount of time. Refresh messages may be delayed up to
refresh interval. Note that messages related to the same Resv
Path state should not be delayed at different intervals in order
preserve ordering
If the RSVP neighbor is not known or changes in next hops cannot
identified via routing, Bundle messages MUST NOT be used. Note
when the routing next hop is not RSVP capable it will typically
be possible to identify changes in next hop
Any message that will be handled by the RSVP neighborindicated in
Bundle Message's destination address may be included in the
message. This includes all RSVP messages that would be sent out
point-to-point link. It includes any message, such as a Resv addressed to the same destination address. It also includes Path
PathTear messages when the next hop is known to be the
and changes in next hops can be detected. Path and PathTear
for multicastsessions MUST NOT be sent in Bundle messages when outgoing link is not a point-to-point link or when the next hop
not support the refresh overhead reduction extensions
If the local system does not recognize or does not wish to accept
Bundle message, the receivedmessages shall be discarded
further analysis
The receiver next compares the Send_TTL with which a Bundle
is sent to the IP TTL with which it is received. If a non-RSVP
is detected, the number of non-RSVP hops is recorded. It is
later in processing of sub-messages
Next, the receiver verifies the version number and checksum of
RSVP Bundle message and discards the message if any mismatch
found
The receiver then starts decapsulating individual sub-messages.
sub-message has its own complete message length and information. With the exception of using the Send_TTL from
header of the Bundle message, each sub-message is processed as if
was received individually
4. MESSAGE_ID
Three new objects are defined as part of the MESSAGE_ID extension
The objects are the MESSAGE_ID object, the MESSAGE_ID_ACK object,
the MESSAGE_ID_NACK objects. The first two objects are used
support acknowledgments and reliable RSVP message delivery. The
object is used to support the summary refresh extensiondescribed
Section 5. The MESSAGE_ID object can also be used to simply
a shorthand indication of when the message carrying the object is
refresh message. Such information can be used by the receiving
to reduce refresh processingrequirements
Message identification and acknowledgment is done on a per hop basis
All types of MESSAGE_ID objects contain a message identifier. identifier MUST be unique on a per object generator's IP
basis. No more than one MESSAGE_ID object may be included in an
message. Each message containing a MESSAGE_ID object may
acknowledged via a MESSAGE_ID_ACK object, when so indicated
MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggy-
in unrelated RSVP messages or in RSVP Ack messages. RSVP
carrying any of the three object types may be included in a
message. When included, each object is treated as if it
contained in a standard, non-bundled, RSVP message
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may included in the standard RSVP messages, as defined in [RFC2205].
When included, one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK
MUST immediately follow the INTEGRITY object. When no
object is present, the MESSAGE_ID_ACK or MESSAGE_ID_NACK objects immediately follow the message or sub-message header. Only
MESSAGE_ID object MAY be included in a message or sub-message and
MUST follow any present MESSAGE_ID_ACK or MESSAGE_ID_NACK objects
When no MESSAGE_ID_ACK or MESSAGE_ID_NACK objects are present,
MESSAGE_ID object MUST immediately follow the INTEGRITY object.
no INTEGRITY object is present, the MESSAGE_ID object immediately follow the message or sub-message header
A value that indicates when the Message_Identifiersequence
reset. SHOULD be randomlygenerated each time a node
or the RSVP agent is restarted. The value SHOULD NOT be
same as was used when the node was last operational.
value MUST NOT be changed during normal operation
When combined with the message generator's IP address,
Message_Identifier field uniquely identifies a message.
values placed in this field change incrementally and
decrease when the Epoch changes or when the value wraps
The Message_Identifier field copied from the message
acknowledged
MESSAGE_ID_NACK
Class = MESSAGE_ID_ACK Class, C_Type = 2
Definition is the same as the MESSAGE_ID_ACK object
4.4. Ack Message
Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_
objects. They MUST NOT contain any MESSAGE_ID objects. Ack
are sent between neighboring RSVP nodes. The IP destination
of an Ack message is the unicast address of the node that
the message(s) being acknowledged. For messages with RSVP_
objects, such as Path and Resv messages, the address is found in
RSVP_HOP object. For other messages, such as ResvConf, associated IP address is the source address in the IP header. The
source address is an address of the node that sends the Ack message
For Ack messages, the Msg Type field of the Common Header MUST
set to 13.
Section 4.6 provides guidance on when an Ack message should be
and when MESSAGE_ID objects should be sent piggy-backed in
RSVP messages
4.5. MESSAGE_ID Object
The MESSAGE_ID object may be included in any RSVP message other
the Ack and Bundle messages. The MESSAGE_ID object is generated and processed over a single hop between RSVP neighbors
The IP address of the object generator, i.e., the node that
the object, is represented in a per RSVP message type
fashion. For messages with RSVP_HOP objects, such as Path and messages, the generator's IP address is found in the RSVP_HOP object
For other messages, such as ResvConf message, the generator's
address is the source address in the IP header. Note that MESSAGE_
objects can only be used in a Bundle sub-messages, but not in
Bundle message. As is always the case with the Bundle message,
sub-message is processed as if it was received individually.
includes processing of MESSAGE_ID objects
The Epoch field contains a generator selected value. The value
used to indicate when the sender resets the values used in
Message_Identifier field. On startup, a node SHOULD randomly
a value to be used in the Epoch field. The node SHOULD ensure
the selected value is not the same as was used when the node was operational. The value MUST NOT be changed unless the node or
RSVP agent is restarted
The Message_Identifier field contains a generator selected value
This value, when combined with the generator's IP address,
a particular RSVP message and the specific state information represents. The combination of Message_Identifier and Epoch can
be used to detect out of order messages. When a node is sending
refresh message with a MESSAGE_ID object, it SHOULD use the
Message_Identifier value that was used in the RSVP message that
advertised the state being refreshed. When a node is sending
trigger message, the Message_Identifier value MUST have a value
is greater than any other value previously used with the same
field value. A value is considered to have been used when it
been sent in any message using the associated IP address with
same Epoch field value
The ACK_Desired flag is set when the MESSAGE_ID object
wants a MESSAGE_ID_ACK object sent in response to the message. information can be used to ensure reliabledelivery of RSVP
in the face of network loss. Nodes setting the ACK_Desired
SHOULD retransmitunacknowledgedmessages at a more rapid
than the standard refresh period until the message is acknowledged
until a "rapid" retry limit is reached. Rapid retransmission
MUST be based on the exponential exponential back-off
defined in section 6. The ACK_Desired flag will typically be
only in trigger messages. The ACK_Desired flag MAY be set in messages. Issues relate to multicastsessions are covered in a
section
Nodes processingincoming MESSAGE_ID objects SHOULD check to see if
newly received message is out of order and can be ignored. Out
order messages SHOULD be ignored, i.e., silently dropped. Out
order messages can be identified by examining the values in the
and Message_Identifier fields. To determineordering, the
Epoch value must match the value previously received from the
sender. If the values differ then the receiver MUST NOT treat
message as out of order. When the Epoch values match and
Message_Identifier value is less than the largest value received from the sender, then the receiver SHOULD check the
previously received for the state associated with the message.
check should be performed for any message that installs or
state. (Includes at least: Path, Resv, PathTear, ResvTear,
and ResvErr.) If no local state information can be associated
the message, the receiver MUST NOT treat the message as out of order
If local state can be associated with the message and the
Message_Identifier value is less than the most recently
value associated with the state, the message SHOULD be treated
being out of order
Note that the 32-bit Message_Identifier value MAY wrap. To cover
wrap case, the followingexpression may be used to test if a received Message_Identifier value is less than a previously
value
if ((int) old_id - (int) new_id > 0) {
new value is less than old value
}
MESSAGE_ID objects of messages that are not out of order SHOULD
used to aid in determining if the message represents new state or
state refresh. Note that state is only refreshed in Path and
messages. If the received Epoch values differs from the
previously received from the message sender, the message is a
message and the receiver MUST fully process the message. If a
or Resv message contains the same Message_Identifier value that
used in the most recently received message for the same session and
for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat
message as a state refresh. If the Message_Identifier value
greater than the most recently received value, the receiver
fully processes the message. When fully processing a Path or
message, the receiver MUST store the received Message_
value as part of the local Path or Resv state for future reference
Nodes receiving a non-out of order message containing a MESSAGE_
object with the ACK_Desired flag set, SHOULD respond with
MESSAGE_ID_ACK object. Note that MESSAGE_ID objects received messagescontaining errors, i.e., are not syntactically valid,
NOT be acknowledged. PathErr and ResvErr messages SHOULD be
as implicit acknowledgments
4.6. MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object
The MESSAGE_ID_ACK object is used to acknowledge receipt of containing MESSAGE_ID objects that were sent with the ACK_
flag set. A MESSAGE_ID_ACK object MUST NOT be generated in
to a received MESSAGE_ID object when the ACK_Desired flag is not set
The MESSAGE_ID_NACK object is used as part of the summary extension. The generation and processing of MESSAGE_ID_NACK
is described in further detail in Section 5.4.
MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any
message that has an IP destination address matching the generator
the associated MESSAGE_ID object. This means that the objects
not typically be included in the non hop-by-hop Path, PathTear
ResvConf messages. When no appropriate message is available, one
more objects SHOULD be sent in an Ack message.
SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in
RSVP messages when possible
Implementations SHOULD limit the amount of time that an object
delayed in order to be piggy-backed or sent in an Ack message Different limits may be used for MESSAGE_ID_ACK and MESSAGE_ID_
objects. MESSAGE_ID_ACK objects are used to detect link
losses. If an ACK object is delayed too long, the
message will be retransmitted. To avoid such retransmission,
objects SHOULD be delayed a minimal amount of time. A delay
equal to the link transit time MAY be used. MESSAGE_ID_NACK
may be delayed an independent and longer time, although
There are a number of issues to be addressed including ACK implosion
number of acknowledgments to be expected and handling of
receivers
ACK implosion occurs when each receiverresponds to the MESSAGE_
object at approximately the same time. This can lead to
potentially large number of MESSAGE_ID_ACK objects
simultaneously delivered to the message generator. To address
case, the receiver MUST wait a random interval prior to
a MESSAGE_ID object received in a message destined to a
address. The random interval SHOULD be between zero (0) and configured maximum time. The configured maximum SHOULD be set
proportion to the refresh and "rapid" retransmissioninterval, i.e
such that the maximum time before sending an acknowledgment does
result in retransmission. It should be noted that ACK implosion
being addressed by spreading acknowledgments out in time, not by
suppression
A more fundamental issue is the number of acknowledgments that upstream node, i.e., the message generator, should expect.
number of acknowledgments that should be expected is the same as
number of RSVP next hops. In the router-to-router case, the
of next hops can often be obtained from routing. When hosts
either the upstream node or the next hops, the number of next
will typically not be readily available. Another case where
number of RSVP next hops will typically not be known is when
are non-RSVP routers between the message generator and the RSVP
hops
When the number of next hops is not known, the message
SHOULD only expect a single response. The result of this
will be special retransmissionhandling until the message
delivered to at least one next hop, then followed by standard
refreshes. Refresh messages will synchronize state with any
hops that don't receive the original message
All nodes sending messages with the Refresh-Reduction-Capable bit
will support the MESSAGE_ID Extension. There are no
compatibility issues raised by the MESSAGE_ID Class with nodes
do not set the Refresh-Reduction-Capable bit. The MESSAGE_ID
has an assigned value whose form is 0bbbbbbb. Per RSVP [RFC2205],
classes with values of this form must be rejected with an "
Object Class" error by nodes not supporting the class. When receiver of a MESSAGE_ID object does not support the class, corresponding error message will be generated. The generator of
MESSAGE_ID object will see the error and then MUST re-send original message without the MESSAGE_ID object. In this case,
message generator MAY still choose to retransmitmessages at
"rapid" retransmissioninterval. Lastly, since the MESSAGE_ID_
class can only be issued in response to the MESSAGE_ID object,
are no possible issues with this class or Ack messages. A node
support the MESSAGE_ID Extension without supporting the other overhead reduction extensions
The summary refresh extension builds on the previously
MESSAGE_ID extension. Only state that was previously advertised
Path and Resv messagescontaining MESSAGE_ID objects can be
via the summary refresh extension
The summary refresh extension uses the objects and the ACK
previously defined as part of the MESSAGE_ID extension, and a Srefresh message. The new message carries a list
Message_Identifier fields corresponding to the Path and Resv messages that established the state. The Message_Identifier
are carried in one of three Srefresh related objects. The
objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_
object, and the MESSAGE_ID MCAST_LIST object
The MESSAGE_ID LIST object is used to refresh all Resv state,
Path state of unicast sessions. It is made up of a list
Message_Identifier fields that were originally advertised
MESSAGE_ID objects. The other two objects are used to refresh
state of multicastsessions. A node receiving a summary refresh multicast path state will at times need source and group information
These two objects provide this information. The objects differ
the information they contain and how they are sent. Both
Message_Identifier fields and corresponding source IP addresses.
MESSAGE_ID SRC_LIST is sent in messagesaddressed to the session' multicast IP address. The MESSAGE_ID MCAST_LIST object adds
group address and is sent in messagesaddressed to the RSVP next hop
The MESSAGE_ID MCAST_LIST is normally used on point-to-point links
An RSVP node receiving an Srefresh message, matches each
Message_Identifier field with installed Path or Resv state. matching state is updated as if a normal RSVP refresh message
been received. If matching state cannot be found, then the
message sender is notified via a refresh NACK
A refresh NACK is sent via the MESSAGE_ID_NACK object. As
in the previous section, the rules for sending a MESSAGE_ID_
object are the same as for sending a MESSAGE_ID_ACK object.
includes sending MESSAGE_ID_NACK object both piggy-backed
unrelated RSVP messages or in RSVP ACK messages
The Message_Identifier field from the MESSAGE_ID corresponding to the trigger message that advertised the
being refreshed. One or more Message_Identifiers may included
The Message_Identifier field from the MESSAGE_ID corresponding to the trigger message that advertised the
state being refreshed. One or more Message_Identifiers may included. Each Message_Identifier MUST be followed by
source IP address corresponding to the sender described in
Path state being refreshed
Source_IP_
The IP address corresponding to the sender of the Path
being refreshed
The Message_Identifier field from the MESSAGE_ID corresponding to the trigger message that advertised the
state being refreshed. One or more Message_Identifiers may included. Each Message_Identifier MUST be followed by
source IP address corresponding to the sender of the Path
being refreshed, and the destination IP address of the session
Source_IP_
The IP address corresponding to the sender of the Path
being refreshed
Srefreshmessages carry one or more MESSAGE_ID LIST, MESSAGE_
SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST
MESSAGE_ID MCAST_LIST objects MAY be carried in the same
message. MESSAGE_ID SRC_LIST can not be combined in messages with the other objects. A single Srefresh message
refresh both Path and Resv state
Srefreshmessages sent to a multicast session's destination
address, MUST contain MESSAGE_ID SRC_LIST objects and MUST
include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects Srefreshmessages sent to the RSVP next hop MAY contain either
both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST
include any MESSAGE_ID SRC_LIST objects
The source IP address of an Srefresh message is an address of
node that generates the message. The source IP address MUST
the address associate with the MESSAGE_ID objects when they included in a standard RSVP message. As previously mentioned,
source address associated with a MESSAGE_ID object is represented
a per RSVP message type specific fashion. For messages with RSVP_
objects, such as Path and Resv messages, the address is found in
RSVP_HOP object. For other messages, such as ResvConf message, associated IP address is the source address in the IP header
Srefreshmessages that are addressed to a session's destination
address MUST be sent with the Router Alert IP option in their
headers. Srefreshmessagesaddressed directly to RSVP
SHOULD NOT be sent with the Router Alert IP option in their
headers
messages can carry a list of Message_Identifier fields within
single object. Implementations may choose to limit each
message to the MTU size of the outgoing link, e.g., 1500 bytes
When generating an Srefresh message, a node SHOULD refresh as
Path and Resv state as is possible by including the information
as many MESSAGE_ID objects in the same Srefresh message. Only information from MESSAGE_ID objects that meet the source destination IP address restrictions, as described in Sections 5.2,
may be included in the same Srefresh message. Identifying Resv
that can be refreshed using the same Srefresh message is
straightforward. Identifying which Path state may be included is
little more complex
Only state that was previously advertised in Path and Resv containing MESSAGE_ID objects can be refreshed via an
message. Srefresh message based refreshes must preserve the synchronization properties of Path or Resv message based refreshes
Specifically, the use of Srefreshmessages MUST NOT result in
being timed-out at the RSVP next hop. The period at which state
refreshed when using Srefreshmessages MAY be shorter than the
that would be used when using Path or Resv message based refreshes
but it MUST NOT be longer
When generating an Srefresh message, there are two methods
identifying which Path state may be refreshed in a specific message
In both cases, the previously mentioned refresh interval and
IP address restrictions must be followed. The primary method is
include only those sessions that share the same destination
address in the same Srefresh message
The secondary method for identifying which Path state may
refreshed within a single Srefresh message is an optimization.
method MAY be used when the next hop is known to support RSVP
when either (a) the session is unicast or (b) the outgoing
is a point-to-point link. This method MUST NOT be used when the
hop is not known to support RSVP or when the outgoinginterface is
a multi-access network and the session is to a multicast address
The use of this method MAY be administratively configured.
using this method, the destination address in the IP header of Srefresh message is usually the next hop's address. When the use
this method is administratively configured, the destination
should be the well known group address 224.0.0.14. When the interface is a point-to-point link, all Path state associated sessions advertised out the interface SHOULD be included in the Srefresh message. When the outgoinginterface is not a point-to
point link, all unicast session Path state SHOULD be included in
same Srefresh message
Identifying which Resv state may be refreshed within a Srefresh message is based simply on the source and destination addresses. Any state that was previously advertised in Resv
with the same IP addresses as an Srefresh message MAY be included
After identifying the Path and Resv state that can be included in particularSrefresh message, the message generator adds to
message MESSAGE_ID informationmatching each identified state'
previously used object. For all Resv state and for Path state
unicast sessions, the information is added to the message in
MESSAGE_ID LIST object that has a matching Epoch value. (Note
one Epoch value will be in use during normal operation.) If matching object exists, then a new MESSAGE_ID LIST object is created
Path state of multicastsessions may be added to the same
when the destination address of the Srefresh message is the RSVP
hop and the outgoinginterface is a point-to-point link. In
case the information is added to the message in a MESSAGE_
MCAST_LIST object that has a matching Epoch value. If no
object exists, then a new MESSAGE_ID MCAST_LIST object is created
When the destination address of the message is a multicast address
then identified information is added to the message in a MESSAGE_
SRC_LIST object that has a matching Epoch value. If no
object exists, then a new MESSAGE_ID SRC_LIST object is created
Once the Srefresh message is composed, the message
transmits the message out the proper interface
An additional check must be performed to determine if a NACK
be generated for unmatched Message_Identifier fields associated
Path state of multicastsessions, i.e., fields that were carried
MESSAGE_ID SRC_LIST or MCAST_LIST objects. The receiving node
check to see if the node would forward data packets originated
the source corresponding to the unmatched field. This check
commonly known as an RPF check, is performed based on the source
group information carried in the MESSAGE_ID SRC_LIST and MCAST_
objects. In both objects the IP address of the source is immediately after the corresponding Message_Identifier field.
group address is listed immediately after the source IP address
MESSAGE_ID MCAST_LIST objects. The group address is the message' destination IP address when MESSAGE_ID SRC_LIST objects are used
The receiving node only generates an Srefresh NACK when the
would forward packets to the identified group from the listed sender
If the node would forward multicast data packets from a listed
and there is a corresponding unmatched Message_Identifier field,
an appropriateSrefresh NACK MUST be generated. If the node
not forward packets to the identified group from a listed sender, corresponding unmatched Message_Identifier field is silently ignored
Srefresh NACKs are used to indicate that a
Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST,
MCAST_LIST object does not match any installed state. This may
for a number of reasons including, for example, a route change. Srefresh NACK is encoded in a MESSAGE_ID_NACK object.
generating an Srefresh NACK, the epoch and Message_Identifier
of the MESSAGE_ID_NACK object MUST have the same value as received. MESSAGE_ID_NACK objects are transmitted as described
Section 4.6.
As discussed in [RFC2205], RSVP uses soft state to address a
class of potential errors. RSVP does this by periodically sending
full representation of installed state in Resv and Path messages Srefreshmessages are used in place of the periodic sending standard Path and Resv refresh messages. While this provides
benefits and protects against common network events such as
loss or routing change, it does not provide exactly the same recovery properties. An example error that could potentially
recovered from via standardmessages but not with
