1 - 3 - 4 - 7 - 8 - A - B - C - D - E - F - G - H - I - L - M - N - O - P - Q - R - S - T - U - V - W
RSVP
Click on the red underlined text to get to the source
... assume a single label distribution protocol. This document is a
specification of extensions to RSVP for establishing label switched
paths (LSPs) in MPLS networks ...
... MPLS (see [3]). In
particular, the extended RSVP protocol supports the instantiation of
explicitly routed LSPs, with or without resource reservations ...
... optimization of operational networks) is expected to be an important
application of this specification, the extended RSVP protocol can be
used in a much wider context.
...
... context.
The purpose of this document is to describe the use of RSVP to
establish LSP tunnels. The intent is to fully describe all the
...
...
All objects and messages described in this specification are optional
with respect to RSVP. This document discusses what happens when an
object described here is not supported by a node.
...
... 1] and Multi-Protocol Label
Switching [2] can associate labels with RSVP flows. When MPLS and
...
... flows. When MPLS and
RSVP are combined, the definition of a flow can be made more
flexible. Once a label switched path ...
... LSP tunnel is
initiated by an ingress node through the RSVP Path message. For this
purpose, the RSVP ...
... RSVP Path message. For this
purpose, the RSVP Path message is augmented with a LABEL_REQUEST
object. Labels are allocated downstream ...
... downstream and distributed (propagated
upstream) by means of the RSVP Resv message. For this purpose, the
RSVP ...
... RSVP Resv message. For this purpose, the
RSVP Resv message is extended with a special LABEL object. The
procedures for label allocation, distribution, binding ...
... capability. This is accomplished by incorporating a simple
EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE
object encapsulates ...
... concatenation of hops which constitutes the
explicitly routed path. Using this object, the paths taken by
label-switched RSVP-MPLS flows can be pre-determined, independent of
...
... significantly enhances the flexibility of path definitions.
An advantage of using RSVP to establish LSP tunnels is that it
enables the allocation of resources along the path. For example,
...
... bandwidth can be allocated to an LSP tunnel using standard RSVP
reservations and Integrated Services service classes ...
... destination and transport-layer protocol." However, when
RSVP and MPLS are combined, a flow or session ...
...
This section summarizes some of the features supported by RSVP as
extended by this document related to the operation of LSP tunnels.
...
... sender node with respect to the path -- creates an RSVP Path
message with a session type of LSP ...
... sender node adds an EXPLICIT_ROUTE object to the RSVP
Path message. The EXPLICIT_ROUTE object ...
... node of a label-switched path responds to a
LABEL_REQUEST by including a LABEL object in its response RSVP Resv
message. The LABEL object is inserted in the filter spec list
...
... reservation
styles for each session, and each RSVP session must have a particular
style. Senders ...
... Admission Control to prevent the new LSP tunnel from being
established. An advantage of using RSVP to establish LSP tunnels is
that it solves this problem very elegantly.
...
... LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP
session to the particular TE tunnel ...
... tunnel
ingress needs to appear as two different senders to the RSVP session.
This is achieved by the inclusion of the "LSP ...
... path MTU related handling is also required
for LSPs established via RSVP.
The following algorithm ...
... Five new objects are defined in this section:
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
...
...
Detailed descriptions of the new objects are given in later sections.
All new objects are OPTIONAL with respect to RSVP. An implementation
can choose to support a subset of objects. However, the
LABEL_REQUEST and LABEL objects are mandatory with respect to this
...
... Resv message unless it had included a LABEL_REQUEST
object in the corresponding Path message. However, an RSVP router
that does not recognize the LABEL object sends a ResvErr with the
...
... Routing problem" and the error value
"Unsupported L3PID." This causes the RSVP session to fail.
...
... object class" toward the
sender. An RSVP router that recognizes the LABEL_REQUEST object but
does not recognize the C_Type sends a PathErr ...
... without the LABEL_REQUEST.
RSVP is designed to cope gracefully with non-RSVP routers anywhere
...
... between senders and receivers. However, obviously, non-RSVP routers
cannot convey labels via RSVP ...
... router has a
neighbor that is known to not be RSVP capable, the router MUST NOT
advertise the LABEL_REQUEST object when sending messages that pass
...
... router MUST NOT
advertise the LABEL_REQUEST object when sending messages that pass
through the non-RSVP routers. The router SHOULD send a PathErr ...
... Routing problem" and the error
value "MPLS being negotiated, but a non-RSVP capable router stands in
the path." This same message SHOULD be sent, if a router ...
... the path." This same message SHOULD be sent, if a router receives a
LABEL_REQUEST object in a message from a non-RSVP capable router.
See [1 ...
... routers along
the explicit route support RSVP and the EXPLICIT_ROUTE object. The
EXPLICIT_ROUTE object ...
... ROUTE object is assigned a class value of the form 0bbbbbbb.
RSVP routers that do not support the object will therefore respond
with an "Unknown Object Class ...
... 1) The node receiving the RSVP message MUST first evaluate the first
subobject. If the node is not part of the abstract node ...
...
There are three possible uses of RRO in RSVP. First, an RRO can
function as a loop detection mechanism to discover L3 ...
... Second, an RRO collects up-to-date detailed path information hop-by-
hop about RSVP sessions, providing valuable information to the sender
...
... timers to limit the number of messages sent.
An RSVP router can decide to send Path messages before its refresh ...
... determines that it is already in the list, a forwarding loop exists.
An RSVP session is loop-free if downstream ...
... RRO object is to be used only when all routers along the path
support RSVP and the RRO object. The RRO object is assigned a class ...
... RRO object is assigned a class
value of the form 0bbbbbbb. RSVP routers that do not support the
object will therefore respond with an "Unknown Object Class ...
... routing protocols. Resource class affinities are used
by RSVP in two ways. In order to be validated a link MUST pass the
...
... SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
All RSVP routers, whether they support the SESSION_ATTRIBUTE object
...
... SESSION_ATTRIBUTE object
or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers ...
...
The RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node ...
...
Hello Messages are always sent between two RSVP neighbors. The IP
source address is the IP address ...
...
The Hello extension does not affect the processing of any other RSVP
message. The only effect is to allow a link (node) down event to be
...
... link (node) down event to be
declared sooner than it would have been. RSVP response to that
condition is unchanged.
...
...
In principle these extensions to RSVP pose no security exposures over
and above RFC 2205prop ...
... trust model. Traffic sent on a normal RSVP session can be filtered
according to source and destination addresses ...
... filters on various ports to deny action on
a RSVP path message with a SESSION object of type LSP ...
...
IANA assigns values to RSVP protocol parameters. Within the current
document an EXPLICIT_ROUTE object and a ROUTE ...
... Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205prop ...
... Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210 ...