HP HSR6800 Configuration Manual page 51

Setting up an LSP tunnel
Figure 16 Setting up an LSP tunnel
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
1. The ingress LSR sends a Path message that carries the label request information, and then
forwards the message along the path calculated by CSPF hop-by-hop towards the egress LSR.
2. After receiving the Path message, the egress generates a Resv message carrying the
reservation information and label and then forwards the message towards the ingress along the
reverse 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
the state between RSVP neighbors and to 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. Because 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.
•
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.
•
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.
43