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.
RSVP-TE State Refresh and Reliability
RSVP-TE employs refresh messages to synchronize state between neighbors and to
recover from lost RSVP-TE messages of other types. RSVP-TE by default does not provide
for reliable transmission. Each node is responsible for the transmission of RSVP-TE
messages to its neighbors and relies on periodic state refreshes to recover from lost
messages.
RSVP-TE refresh reduction provides a means to increase reliability while reducing message
handling and synchronization overhead. Issuing the mpls rsvp refresh-reduction
command enables the following features:
•
The message ID object is included in RSVP-TE messages to provide a unique message
ID on a per-hop basis. In refresh messages, it indicates to the receiving node that the
message is a refresh message, eliminating the need for the node to completely analyze
the message and thus reducing the processing overhead at the receiver.
•
RSVP-TE uses a message acknowledgment mechanism to support reliable message
delivery on a per-hop basis. Messages that include the message ID object also include
a request for acknowledgment. Upon receipt, the receiving node returns a message
ack object, enabling the sending node to determine whether a message was lost and
triggering a retransmission as necessary.
•
Summary refresh (srefresh) messages refresh the state previously advertised in path
or resv messages that included message ID objects. The srefresh message carries the
unique message ID as state identifier, eliminating the need to send whole refresh
messages and reducing the overhead needed to maintain RSVP-TE state
synchronization. This method maintains RSVP-TE's ability to indicate when the state
is lost and to adjust to changes in routing. The srefresh message can carry message
IDs for multiple RSVP-TE sessions.
Issuing the mpls rsvp message-bundling command enables RSVP-TE to use bundle
messages, each of which includes multiple standard RSVP-TE messages, to reduce the
overall message processing overhead.
BGP Signaling
You can use BGP as a label distribution protocol both for IP routes and for VPN routes.
When BGP distributes a particular IP route, it can also distribute an MPLS label that has
been mapped to that route, as described in RFC 3107. The MP-BGP extensions (RFC
2858) enable the BGP update message to carry both the route and the label mapping
information for the route. The label is encoded into the NLRI field of the attribute, and
the SAFI field is set to 4 to indicate that the NLRI contains a label. A BGP speaker can
use BGP to send labels to a particular BGP peer only if that peer advertised the capability
to process update messages with SAFI 4. BGP speakers advertise this capability only to
peers for which the neighbor send-label command has been configured.
241Copyright © 2010, Juniper Networks, Inc.
Chapter 3: MPLS Overview
To Next Page
Loading...
Need help?
General
