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
LSP
Click on the red underlined text to get to the source
... specification of extensions to RSVP for establishing label switched
paths (LSPs) in MPLS networks.
...
... particular, the extended RSVP protocol supports the instantiation of
explicitly routed LSPs, with or without resource reservations. It
also supports smooth rerouting ...
... resource reservations. It
also supports smooth rerouting of LSPs, preemption, and loop
detection.
...
... traffic trunk are distinct though closely related concepts. For
example, two LSPs between the same source and destination could be
load shared to carry a single traffic trunk ...
... traffic trunk. Conversely several
traffic trunks could be carried in the same LSP if, for instance, the
LSP were capable of carrying several service classes ...
... traffic trunks could be carried in the same LSP if, for instance, the
LSP were capable of carrying several service classes. The
applicability of these extensions is discussed further in [10 ...
... label-switched path is defined
by the label applied at the ingress node of the LSP, these paths can
be treated as tunnels, tunneling ...
... IP routing and
filtering mechanisms. When an LSP is used in this way we refer to it
as an LSP tunnel.
...
... filtering mechanisms. When an LSP is used in this way we refer to it
as an LSP tunnel.
LSP tunnels ...
... LSP tunnel.
LSP tunnels allow the implementation of a variety of policies related
to network performance ...
... to network performance optimization. For example, LSP tunnels can be
automatically or manually routed away from network failures,
...
... network failures,
congestion, and bottlenecks. Furthermore, multiple parallel LSP
tunnels can be established between two nodes, and traffic between the
...
... traffic between the
two nodes can be mapped onto the LSP tunnels according to local
policy. Although traffic engineering (that is, performance ...
... The purpose of this document is to describe the use of RSVP to
establish LSP tunnels. The intent is to fully describe all the
objects, packet formats, and procedures required to realize
...
... interoperable implementations. A few new objects are also defined
that enhance management and diagnostics of LSP tunnels.
The document also describes a means of rapid node ...
... flow can be made more
flexible. Once a label switched path (LSP) is established, the
traffic through the path is defined by the label applied at the
...
... traffic through the path is defined by the label applied at the
ingress node of the LSP. The mapping of label to traffic can be
accomplished using a number of different criteria. The set of
...
... traffic is mapped
onto a label-switched path in this way, we call the LSP an "LSP
Tunnel". When labels are associated with traffic flows, it becomes
...
... onto a label-switched path in this way, we call the LSP an "LSP
Tunnel". When labels are associated with traffic flows, it becomes
possible for a router ...
... signaling protocol model uses downstream-on-demand label
distribution. A request to bind labels to a specific LSP tunnel is
initiated by an ingress node through the RSVP ...
... routing is traffic engineering.
Using explicitly routed LSPs, a node at the ingress edge of an MPLS ...
... opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
contains only one physical ...
... physical node. Using this concept of abstraction,
an explicitly routed LSP can be specified as a sequence of IP
prefixes ...
...
An advantage of using RSVP to establish LSP tunnels is that it
enables the allocation of resources along the path. For example,
bandwidth ...
... 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 ...
... While resource reservations are useful, they are not mandatory.
Indeed, an LSP can be instantiated without any resource reservations
whatsoever. Such LSPs ...
... LSP can be instantiated without any resource reservations
whatsoever. Such LSPs without resource reservations can be used, for
example, to carry best effort traffic ...
... opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
contains only one physical ...
... flows aggregated by their service class and then placed
on an LSP or set of LSPs called a traffic engineered tunnel ...
... service class and then placed
on an LSP or set of LSPs called a traffic engineered tunnel. For
...
... session can be defined with
greater flexibility and generality. The ingress node of an LSP can
use a variety of means to determine which packets are assigned a
particular label ...
... particular label. Once a label is assigned to a set of packets, the
label effectively defines the "flow" through the LSP. We refer to
such an LSP as an "LSP tunnel ...
... flow" through the LSP. We refer to
such an LSP as an "LSP tunnel" because the traffic through it is
...
... TUNNEL_IPv6 have been defined to support the
LSP tunnel feature. The semantics of these objects, from the
perspective of a node ...
... label switched path, is that traffic
belonging to the LSP tunnel is identified solely on the basis of
packets arriving from the PHOP or "previous hop" (see [1]) with the
...
... TUNNEL.
In some applications it is useful to associate sets of LSP tunnels.
This can be useful during reroute operations or to spread a traffic
trunk over multiple paths. In the traffic engineering ...
... tunnels). To
enable the identification and association of such LSP tunnels, two
identifiers are carried. A tunnel ID ...
... Operation of LSP Tunnels ...
... This section summarizes some of the features supported by RSVP as
extended by this document related to the operation of LSP tunnels.
These include: (1) the capability to establish LSP tunnels with or
...
... extended by this document related to the operation of LSP tunnels.
These include: (1) the capability to establish LSP tunnels with or
without QoS requirements ...
... QoS requirements, (2) the capability to dynamically reroute
an established LSP tunnel, (3) the capability to observe the actual
route traversed by an established LSP tunnel ...
... LSP tunnel, (3) the capability to observe the actual
route traversed by an established LSP tunnel, (4) the capability to
identify and diagnose LSP tunnels, (5) the capability to preempt an
...
... route traversed by an established LSP tunnel, (4) the capability to
identify and diagnose LSP tunnels, (5) the capability to preempt an
established LSP tunnel under administrative policy control ...
... identify and diagnose LSP tunnels, (5) the capability to preempt an
established LSP tunnel under administrative policy control, and (6)
the capability to perform downstream ...
... network layer
protocol that is to be carried over this path. The reason for this
is that the network layer protocol sent down an LSP cannot be assumed
to be IP and cannot be deduced from the L2 header ...
... node
can receive information about the actual route that the LSP tunnel
traverses. The sender node ...
... Resv message containing a LABEL object uses
that label for outgoing traffic associated with this LSP tunnel. If
the node is not the sender ...
... node will use to identify incoming
traffic associated with this LSP tunnel. This label also serves as
shorthand for the Filter Spec. The node ...
... assigned to each sender. This can result in a point-to-point LSP
between every sender/receiver ...
... session. If there is only
one sender, the LSP looks like a normal point-to-point connection.
When multiple senders ...
... SE style reservations can be provided using multipoint-to-point
label-switched-path or LSP per sender. Multipoint-to-point LSPs ...
... LSP per sender. Multipoint-to-point LSPs may
be used when path messages do not carry the EXPLICIT_ROUTE object ...
... Path messages have differing
EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object
must be established.
...
... rerouting requirement
necessitates establishing a new LSP tunnel and transferring traffic
from the old LSP tunnel ...
... LSP tunnel and transferring traffic
from the old LSP tunnel onto it before tearing down the old LSP
tunnel. This concept is called "make-before-break." A problem can
...
... traffic
from the old LSP tunnel onto it before tearing down the old LSP
tunnel. This concept is called "make-before-break." A problem can
arise because the old and new LSP tunnels ...
... LSP
tunnel. This concept is called "make-before-break." A problem can
arise because the old and new LSP tunnels might compete with each
other for resources on network segments ...
... Depending on availability of resources, this competition can cause
Admission Control to prevent the new LSP tunnel from being
established. An advantage of using RSVP to establish LSP tunnels ...
... LSP tunnel from being
established. An advantage of using RSVP to establish LSP tunnels is
that it solves this problem very elegantly.
...
... make-before-break in a smooth fashion, it is necessary
that on links that are common to the old and new LSPs, resources used
by the old LSP tunnel should not be released before traffic ...
... links that are common to the old and new LSPs, resources used
by the old LSP tunnel should not be released before traffic is
transitioned to the new LSP tunnel ...
... LSP tunnel should not be released before traffic is
transitioned to the new LSP tunnel, and reservations should not be
counted twice because this might cause Admission Control to reject
...
... counted twice because this might cause Admission Control to reject
the new LSP tunnel.
A similar situation can arise when one wants to increase the
...
... bandwidth and routing. The idea is that the old and new LSP tunnels
share resources along links which they have in common. The
...
... share resources along links which they have in common. The
LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP ...
... RSVP session.
This is achieved by the inclusion of the "LSP ID", which is carried
in the SENDER_TEMPLATE and FILTER ...
...
To effect a reroute, the ingress node picks a new LSP ID and forms a
new SENDER_TEMPLATE. The ingress node ...
... SENDER_TEMPLATE and
ERO. It continues to use the old LSP and refresh the old Path
message. On links ...
... links that are not held in common, the new Path message
is treated as a conventional new LSP tunnel setup. On links held in
common, the shared SESSION ...
... common, the shared SESSION object and SE style allow the LSP to be
established sharing resources with the old LSP. Once the ingress
...
... SE style allow the LSP to be
established sharing resources with the old LSP. Once the ingress
node receives a Resv message ...
... node receives a Resv message for the new LSP, it can transition
traffic to it and tear down the old LSP ...
... To effect a bandwidth-increase, a new Path Message with a new LSP_ID
can be used to attempt a larger bandwidth reservation ...
... bandwidth reservation while the
current LSP_ID continues to be refreshed to ensure that the
reservation is not lost if the larger reservation ...
... sender and the receiver. This path
MTU identification capability is also provided for LSPs established
via RSVP.
...
... unreachable message. This path MTU related handling is also required
for LSPs established via RSVP.
...
... LSP Tunnel related Message Formats ...
... LSP Tunnel related Objects ...
... This permits non-IP network layer protocols to be sent down an LSP.
This information can also be useful in actual label allocation,
because some reserved labels are protocol specific, see [5 ...
... setup to fail. The sender should notify management that a LSP cannot
be established and possibly take action to continue the reservation
...
... sender should
notify management that a LSP cannot be established and possibly take
action to continue the reservation without the EXPLICIT_ROUTE ...
... address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
... Tunnel_ID. It also forms a SENDER_TEMPLATE and assigns
a LSP_ID. Tunnel setup then proceeds according to the normal
procedure.
...
... Tunnel_ID
are unchanged. The ingress node picks a new LSP_ID to form a new
SENDER_TEMPLATE. It creates ...
... of an incoming label. For this reason an administration may wish to
limit the domain over which LSP tunnels can be established. This can
be accomplished by setting filters on various ports ...
... Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001. ...