H3C Technologies H3C S7500E Series Switches - Manual (Page 90)

3-8
direction of the path along which the Path message travels. The LSRs that the Resv message
traverses along the path reserve resources as required.
3) When the ingress LSR receives the Resv message, LSP is established.
As resources are reserved on the LSRs along the path for the LSP established using RSVP-TE,
services transmitted on the LSP are guaranteed.
RSVP refresh mechanism
RSVP maintains path and reservation state by periodically retransmitting two types of messages: Path
and Resv. These periodically retransmitted Path and Resv messages are called refresh messages.
They are sent along the path that the last Path or Resv message travels to synchronize state between
RSVP neighbors and recover lost RSVP messages.
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 as follows 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, thus improving transmission
reliability.
On an interface enabled with the Message_ID mechanism, you may configure RSVP message
retransmission. After the interface sends an RSVP message, it waits for acknowledgement. If no ACK
is received before the initial retransmission interval (Rf seconds for example) expires, the interface
resends the message. After that, the interface resends the message at an exponentially increased
retransmission interval equivalent to (1 + Delta) × Rf seconds.
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.
You may sometimes want to store the resource reservation state for a reservation request that does
not pass the admission control on some node. This however should not prevent the resources
reserved for the request from being used by other requests. To handle this situation, 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 state in the BSB is removed.