97
On an interface enabled with the Message_ID mechanism, you can configure RSVP message
retransmission. If a node sends a message carrying the Message_ID object, and the ACK_Desired
flag in the object is set, the node expects a response that carries the Message_ID_ACK object
during the initial retransmission interval (Rf). If the node does not receive the response within the Rf
interval, it resends the message and sets the retransmission interval to (1+Delta)
×
Rf. The node
repeats such retransmissions until it receives the corresponding response within the retransmission
time or the number of retransmission attempts reaches the limit.
2.
Summary refresh extension
Send summary refreshes (Srefreshes) rather than retransmit standard Path or Resv messages to
refresh related RSVP state. This reduces refresh traffic and allows nodes to make faster processing.
To use summary refresh, you must use the Message_ID extension. Only states advertised using
MESSAGE_ID included Path and Resv messages can be refreshed using summary refreshes.
PSB, RSB and BSB timeouts
To create an LSP tunnel, the sender sends a Path message with a LABEL_REQUEST object. After receiving
this Path message, the receiver assigns a label to the path and puts the label binding in the LABEL object
in the returned Resv message.
The LABEL_REQUEST object is stored in the path state block (PSB) on the upstream nodes, while the
LABEL object is stored in the reservation state block (RSB) on the downstream nodes. The state stored in
the PSB or RSB object times out and is removed after the number of consecutive non-refreshing times
exceeds the PSB or RSB timeout keep-multiplier.
Sometimes, although a reservation request does not pass admission control on some node, you may
want to store the resource reservation state for it while allowing other requests to use the resources
reserved for the request. In this case, the node transits to the blockade state and a blockade state block
(BSB) is created on each downstream node. When the number of non-refreshing times exceeds the
blockade multiplier, the blockade state is removed.
RSVP-TE GR
RSVP-TE Graceful Restart (GR) preserves the soft state and label forwarding information when the
signaling protocol or control plane fails, so that LSRs can still forward packets according to forwarding
entries, ensuring continuous data transmission.
A device that participates in an RSVP-TE GR process plays either of the following two roles:
•
GR restarter, the router that gracefully restarts due to a manually configured command or a fault. It
must be GR-capable.
•
GR helper, neighbor of the GR restarter. A GR helper maintains the neighbor relationship with the
GR restarter and helps the GR restarter restore its LFIB information. A GR helper must be
GR-capable.
The RSVP-TE GR function depends on the extended hello capability of RSVP-TE. A GR-capable device
advertises its GR capability and relevant time parameters to its neighbors by extended RSVP hello
packets. If a device and all its neighbors have the RSVP GR capability and have exchanged GR
parameters, each of them can function as the GR helper of another device, allowing data to be
forwarded without interruption when the GR restarter is rebooting.
A GR helper considers that a GR restarter is rebooting when it receives no Hello packets from the
restarter in a specific period of time. When a GR restarter is rebooting, the GR helpers retain soft state
information about the GR restarter and keep sending Hello packets periodically to the GR restarter until
the restart timer expires.
