HP 12500 Series Configuration Manual page 54

PathErr messages: sent upstream to report Path message processing errors to senders. They do not
•
affect the state of the nodes along the path.
ResvErr messages: sent downstream to notify the downstream nodes that error occurs during Resv
•
message processing or reservation error occurs as the result of preemption.
ResvConf messages: sent to receivers to confirm Resv messages.
•
Hello messages: sent between any two directly connected RSVP neighbors to set up and maintain
•
the neighbor relationship that has local significance on the link.
The TE extension to RSVP adds new objects to the Path message and the Resv message. These objects
carry not only label bindings but also routing constraints, supporting CR-LSP and FRR.
New objects added to the Path message include LABEL_REQUEST, EXPLICIT_ROUTE,
•
RECORD_ROUTE, and SESSION_ATTRIBUTE.
• New objects added to the Resv message include LABEL and RECORD_ROUTE
The LABEL_REQUEST object in the Path message requests the label bindings for an LSP. It is also saved
in the path state block. The node receiving LABEL_REQUEST advertises the label binding using the LABEL
object in the Resv message to the upstream node, accomplishing label advertisement and transmission.
Setting up an LSP tunnel
Figure 16 shows how to set up a LSP tunnel with RSVP:
Figure 16 Setting up an LSP tunnel
Ingress
Sender
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
The ingress LSR sends a Path message that carries the label request information, and then forwards
1.
the message along the path calculated by CSPF hop-by-hop towards the egress LSR.
After receiving the Path message, the egress generates a Resv message carrying the reservation
2.
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.
When the ingress LSR receives the Resv message, LSP is established.
3.
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 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 to address the problems:
Path
Resv
Egress
Path
Resv
Receiver
46