H3C Technologies H3C S10500 Series Switches - Manual (Page 103)

92
When many RSVP sessions are present, periodically sent refresh messages become a network burden. In
addition, for some delay sensitive applications, the refreshing delay they must wait for recovering lost
RSVP messages may be unbearable. As tuning refresh intervals is not adequate to address the two
problems, the refreshing mechanism was extended in RFC 2961 RSVP Refresh Overhead Reduction
Extensions to address the problems:
1. Message_ID extension
RSVP itself uses Raw IP to send messages. The Message_ID extension mechanism defined in RFC 2961
adds objects that can be carried in RSVP messages. Of them, the Message_ID object and the
Message_ID_ACK object are used to acknowledge RSVP messages, improving transmission reliability.
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 for 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.