Rsvp-Te State Refresh And Reliability; Bgp Signaling - Juniper BGP - CONFIGURATION GUIDE V 11.1.X Configuration Manual

JUNOSe 11.1.x BGP and MPLS Configuration Guide
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:
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
232
MPLS Label Distribution Protocols
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.