3Com MSR 50 Series Configuration Manual page 1352

1352 C 77: MPLS TE C
HAPTER ONFIGURATION
Hell 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, thus accomplishing label advertisement and transmission.
Setting up an LSP tunnel
Figure 386 shows how to set up a LSP tunnel with RSVP:
Figure 386 Set up an LSP tunnel
Ingress
Path
Resv
Sender
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
1 The ingress LSR sends a Path message towards the egress LSR.
2 After receiving the Path message, the egress LSR sends back a Resv message
towards the ingress LSR. The LSRs that the Resv message traverses along the path
reserves 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
Egress
Path
Resv
Receiver