 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |
RSVP is described in RFC 2205. Multiple RFCs enable extensions to RSVP for traffic engineering. The router supports the extended version of RSVP, referred to as RSVP-TE.
RSVP-TE is “ unreliable” because it does not use TCP to exchange messages. In contrast to LDP—a hard-state protocol—RSVP-TE is a soft-state protocol, meaning that much of the session information is embedded in a state machine on each LSR. The state machine must be refreshed periodically to avoid session termination. LSRs send path messages to downstream peers to create and refresh local path states. LSRs send resv messages to upstream peers in response to path messages to create and refresh local resv states. A session is ended if the state machine is not refreshed within the RSVP tunnel timeout period, which is determined as follows:
For example, for the default values,
RSVP-TE messages carry objects consisting of type-length-values (TLVs). The label request object instructs the endpoint LSR to return an resv message to establish the LSP. The resv message contains the label object, the label used for the FEC. Both the path and resv messages carry the record route object, which records the route traversed by the message.
An upstream LSR sends a pathtear message when its path state times out as a result of not being refreshed. The pathtear message removes the path and resv states in each LSR as it proceeds downstream. Downstream LSRs similarly send the resvtear message when their resv state times out to remove the resv states in upstream LSRs.
If a downstream LSR determines that it received an erroneous path message, it sends a patherr message to the sender. If a reservation (label) request fails, the request initiator sends a resverr message to the downstream LSRs. Both of these messages are advisory and do not alter path or resv state.
| Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |