Brocade Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide (Supporting R05.6.00) - Manual (Page 133)

Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide 109
53-1003031-02
RSVP refresh reduction
1
Brocade(config-mpls-if-e1000-3/13)# rsvp-reliable-messaging
The previous commands enable RSVP reliable messaging on interface 3/13 with all parameters
set to their defaults (or to settings previously configured on this interface, if any).
Syntax: [no] rsvp-reliable-messaging [rapid-retrans-interval milliseconds] [rapid-retry-limit
number][rapid-retrans-decay percentage]
The rapid-retrans-interval option allows the user to specify the interval in milliseconds that the
device waits before a message is first resent when no acknowledgement is received. The range is
from 100 through 30000 milliseconds, and the default is 500.
The rapid-retry-limit option allows the user to specify the maximum number of times a message is
to be resent when no acknowledgement is received. The range is from one through 16, and the
default is two (2). When set to the default value, a message is sent a total of three times when no
acknowledgement is received.
The rapid-retrans-decay option allows the user to specify the percentage increase in the interval
between successive retransmissions of an unacknowledged RSVP message. The range is from zero
through 100 percent, and the default value is 100 percent. A value of zero percent provides a
constant retransmission rate with each interval being equal to the rapid-retrans-interval value. A
value of 100 percent doubles the retransmission interval after each retry.
RSVP refresh reduction
RSVP control traffic (Path and Resv messages) is initially propagated to establish an RSVP session
and reserve resources along the path, or to signal a change of state (trigger messages). However,
because it is a soft-state protocol, RSVP also requires periodic refreshing to prevent reserved
resources from aging out. The original RSVP as defined in RFC 2205 achieves this by resending
identical Path and Resv messages (refresh messages) at regular intervals along the reserved path
as long as the RSVP session remains unchanged. The bandwidth and processing time required to
support these refresh messages increases linearly as more RSVP sessions are established, which
can result in scaling problems.
RFC 2961 establishes extensions to RSVP which can help reduce the overhead caused by refresh
messages: bundle messages, which allows multiple RSVP messages to be aggregated into a single
PDU, and summary refresh messages, which replace identical RSVP message retransmissions with
a list of the IDs of all Path and Resv states to be refreshed. Both extensions are available at the
interface configuration level on the Brocade NetIron XMR, Brocade MLX series, Brocade NetIron
CER and Brocade NetIron CES platforms, and each extension can be configured separately.
When the user enables either of the refresh reduction extensions on an interface, outgoing RSVP
packets sent on that interface sets the refresh reduction capability bit in the common RSVP header
to indicate that the Brocade device is capable of receiving and processing refresh reduction
messages and related objects.
Configuring RSVP bundle messages
When RSVP bundle messages are enabled on an interface, the device attempts to combine
multiple outgoing RSVP messages on that interface into bundles to reduce overhead.