When configuring an O-UNI LSP, the RSVP session is bidirectional. The exchange of data between a pair of
machines actually constitutes a single RSVP session. The RSVP session is established using an Out-Of-Band
(OOB) IP Control Channel (IPCC) with the neighbor. The RSVP messages are transported over an interface
other than the data interface.
RSVP supports extensions according to OIF2000.125.7 requirements, including:
•
Generalized Label Request
•
Generalized UNI Attribute
•
UNI Session
•
New Error Spec sub-codes
RSVP is automatically enabled on interfaces on which MPLS-TE is configured. For MPLS-TE LSPs with
nonzero bandwidth, the RSVP bandwidth has to be configured on the interfaces. There is no need to configure
RSVP, if all MPLS-TE LSPs have zero bandwidth . For O-UNI, there is no need for any RSVP configuration
.
RSVP Refresh Reduction, defined in RFC 2961, includes support for reliable messages and summary refresh
messages. Reliable messages are retransmitted rapidly if the message is lost. Because each summary refresh
message contains information to refresh multiple states, this greatly reduces the amount of messaging needed
to refresh states. For refresh reduction to be used between two routers, it must be enabled on both routers.
Refresh Reduction is enabled by default.
Message rate limiting for RSVP allows you to set a maximum threshold on the rate at which RSVP messages
are sent on an interface. Message rate limiting is disabled by default.
The process that implements RSVP is restartable. A software upgrade, process placement or process failure
of RSVP or any of its collaborators, has been designed to ensure Nonstop Forwarding (NSF) of the data plane.
RSVP supports graceful restart, which is compliant with RFC 3473. It follows the procedures that apply when
the node reestablishes communication with the neighbor’s control plane within a configured restart time.
It is important to note that RSVP is not a routing protocol. RSVP works in conjunction with routing protocols
and installs the equivalent of dynamic access lists along the routes that routing protocols calculate. Because
of this, implementing RSVP in an existing network does not require migration to a new routing protocol.
Related Topics
Configuring RSVP Packet Dropping, on page 127
Set DSCP for RSVP Packets: Example, on page 149
Verifying RSVP Configuration, on page 129
LSP Setup
LSP setup is initiated when the LSP head node sends path messages to the tail node (see the RSVP Operation
figure ).
This figure illustrates an LSP setup for non-O-UNI applications. In the case of an O-UNI application, the
RSVP signaling messages are exchanged on a control channel, and the corresponding data channel to be used
is acquired from the LMP Manager module based on the control channel. Also the O-UNI LSP’s are by default
bidirectional while the MPLS-TE LSP’s are uni-directional.
Cisco IOS XR MPLS Configuration Guide for the Cisco CRS Router, Release 5.1.x
113
Implementing RSVP for MPLS-TE and MPLS O-UNI
LSP Setup
To Next Page
Loading...
Need help?
General
