Rsvp And Rsvp-Te; Rsvp-Te Overview - Nokia 7705 SAR-W Series Manual

MPLS and RSVP-TE

3.3 RSVP and RSVP-TE

The Resource Reservation Protocol (RSVP) is a network control protocol used by a
host to request specific qualities of service from the network for particular application
data streams or flows. RSVP is also used by routers to deliver quality of service
(QoS) requests to all nodes along the paths of the flows and to establish and
maintain operational state to provide the requested service. In general, RSVP
requests result in resources reserved in each node along the data path.
The Resource Reservation Protocol for Traffic Engineering (RSVP-TE) is an
extended version of RSVP for MPLS. RSVP-TE uses traffic engineering extensions
to support automatic signaling of LSPs. MPLS uses RSVP-TE to set up traffic-
engineered LSPs. See

3.3.1 RSVP-TE Overview

RSVP-TE requests resources for simplex (unidirectional) flows. Therefore, RSVP-TE
treats a sender as logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time. Duplex flows
require two LSPs, to carry traffic in each direction.
RSVP-TE is a signaling protocol, not a routing protocol. RSVP-TE operates with
unicast and multicast routing protocols. Routing protocols determine where packets
are forwarded. RSVP-TE consults local routing tables to relay RSVP-TE messages.
RSVP-TE uses two message types to set up LSPs, PATH and RESV.
depicts the process to establish an LSP.
36
RSVP-TE Extensions for MPLS
• The sender (the ingress LER (iLER)) sends PATH messages toward the
receiver, (the egress LER (eLER)) to indicate the forwarding equivalence class
(FEC) for which label bindings are desired. PATH messages are used to signal
and request the label bindings required to establish the LSP from ingress to
egress. Each router along the path observes the traffic type.
• PATH messages facilitate the routers along the path to make the necessary
bandwidth reservations and distribute the label binding to the router upstream.
• The eLER sends label binding information in the RESV messages in response
to PATH messages received.
• The LSP is considered operational when the iLER receives the label binding
information.
Use subject to Terms available at: www.nokia.com
© 2022 Nokia.
MPLS Guide
for more information.
Figure 4
3HE 18686 AAAB TQZZA