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
node
Click on the red underlined text to get to the source
... flows along a label-switched path is defined
by the label applied at the ingress node of the LSP, these paths can
be treated as tunnels ...
... congestion, and bottlenecks. Furthermore, multiple parallel LSP
tunnels can be established between two nodes, and traffic between the
two nodes ...
... nodes, and traffic between the
two nodes can be mapped onto the LSP tunnels according to local
policy. Although traffic engineering ...
... LSP tunnels.
The document also describes a means of rapid node failure detection
via a new HELLO message ...
... with respect to RSVP. This document discusses what happens when an
object described here is not supported by a node.
Throughout this document, the discussion ...
... 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
...
... traffic can be
accomplished using a number of different criteria. The set of
packets that are assigned the same label value by a specific node are
said to belong to the same forwarding equivalence class (FEC ...
... label
distribution. A request to bind labels to a specific LSP tunnel is
initiated by an ingress node through the RSVP Path message. For this
...
... traffic traverses from
itself, through the MPLS network, to an egress node. Explicit
routing can be used to optimize the utilization of network ...
... The concept of explicitly routed label switched paths can be
generalized through the notion of abstract nodes. An abstract node
is a group ...
... label switched paths can be
generalized through the notion of abstract nodes. An abstract node
is a group of nodes ...
... topology is opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
...
... node of the LSP. An abstract node is said to be simple if it
contains only one physical node ...
... node is said to be simple if it
contains only one physical node. Using this concept of abstraction,
an explicitly routed LSP can be specified as a sequence of IP ...
... signaling protocol model supports the specification of an
explicit path as a sequence of strict and loose routes. The
combination of abstract nodes, and strict and loose routes
significantly enhances the flexibility of path definitions.
...
... topology is opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
...
... node of the LSP. An abstract node is said to be simple if it
contains only one physical node ...
... switched hops, allowing a packet to be forwarded by swapping
labels from an MPLS node to another MPLS node. For a more precise
...
... flow or 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
...
... LSP tunnel feature. The semantics of these objects, from the
perspective of a node along the label switched path, is that traffic
...
... node on the path -- that is,
the sender node with respect to the path -- creates an RSVP Path
message ...
... of network resources, or that satisfies some policy criteria, the
node can decide to use the route for some or all of its sessions. To
...
... session has been successfully established, the sender
node discovers a better route, the sender can dynamically reroute the
...
... ROUTE object to the Path message, the sender node
can receive information about the actual route that the LSP tunnel ...
... destination along a path specified by the ERO.
Each node along the path records the ERO in its path state block.
...
... ERO in its path state block.
Nodes may also modify the ERO before forwarding the Path message. In
...
... nodes to provide a label binding for the session. If a node is
incapable of providing a label binding, it sends a PathErr message ...
... object class" error. If the LABEL_REQUEST object is
not supported end to end, the sender node will be notified by the
first node which does not provide this support.
...
... sender node will be notified by the
first node which does not provide this support.
The destination ...
...
The destination node of a label-switched path responds to a
LABEL_REQUEST by including a LABEL object in its response RSVP ...
... ERO.
Each node that receives a Resv message containing a LABEL object uses
that label for outgoing traffic ...
... traffic associated with this LSP tunnel. If
the node is not the sender, it allocates a new label and places that
label in the corresponding LABEL object of the Resv message ...
... upstream to the PHOP. The label sent upstream in the LABEL
object is the label which this node will use to identify incoming
traffic associated with this LSP tunnel ...
... LSP tunnel. This label also serves as
shorthand for the Filter Spec. The node can now update its "Incoming
Label Map" (ILM ...
... Resv message propagates upstream to the sender node, a
label-switched path is effectively established.
...
...
The receiver node can select from among a set of possible reservation
styles for each session ...
... reservation among several sender
nodes. The following sections discuss the different reservation
styles and their advantages and disadvantages. A more detailed
...
... bandwidth. If policy is being applied to
PATH messages by intermediate nodes, then a PATH message requesting
too much bandwidth ...
... TE tunnel, we use the combination of the destination IP
address (an address of the node which is the egress of the tunnel), a
Tunnel ID ...
... Tunnel ID, and the tunnel ingress node's IP address, which is placed
in the Extended Tunnel ID ...
... C-Types are assigned.
To effect a reroute, the ingress node picks a new LSP ID and forms a
new SENDER ...
... creates a new ERO to
define the new path. Thereafter the node sends a new Path Message
using the original SESSION ...
... established sharing resources with the old LSP. Once the ingress
node receives a Resv message for the new LSP, it can transition
...
... algorithm applies to all unlabeled IP datagrams and to
any labeled packets which the node knows to be IP datagrams, to which
labels need to be added before forwarding. For labeled packets the
...
... 1. Let N be the number of bytes in the label stack (i.e, 4 times the
number of label stack entries) including labels to be added by
this node.
2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram ...
...
In MPLS a node may support multiple label spaces, perhaps associating
a unique space with each incoming interface. For the purposes of the
...
... label request, the label MUST
be drawn from that range. If no label is available the node sends a
PathErr message with an error code ...
... error
value of "label allocation failure".
If a node receives a Resv message that has assigned the same label
value to multiple senders ...
... Resv message that has assigned the same label
value to multiple senders, then that node MAY also assign a single
value to those same senders or to any subset of those senders ...
... In the case of ATM, one further condition applies. Some ATM nodes
are not capable of merging streams. These nodes MAY indicate this by
...
... ATM nodes
are not capable of merging streams. These nodes MAY indicate this by
setting a bit in the label request ...
... range,
serves this purpose. The M-bit SHOULD be set by nodes which are
merge capable. If for any senders the M-bit ...
... senders.
Once a label is allocated, the node formats a new LABEL object. The
node then sends the new LABEL object as part of the Resv message ...
... Once a label is allocated, the node formats a new LABEL object. The
node then sends the new LABEL object as part of the Resv message to
the previous hop. The node ...
... node then sends the new LABEL object as part of the Resv message to
the previous hop. The node SHOULD be prepared to forward packets
carrying the assigned label prior to sending the Resv message. The
...
...
A node uses the label carried in the LABEL object as the outgoing
label associated with the sender. The router ...
... Several circumstance can lead to an unacceptable label.
1. the node is a merge incapable ATM switch but the downstream ...
... senders
2. The implicit null label was assigned, but the node is not
capable of doing a penultimate pop for the associated L3PID
...
... range
In any of these events the node send a ResvErr message with an error
code of "routing problem" and an error value ...
...
Under normal circumstances, a node should never receive a LABEL
object in a Resv message unless it had included a LABEL_REQUEST
...
... Resv messages pertaining to that Path
message. If a LABEL_REQUEST object was not present in the Path
message, a node MUST NOT include a LABEL object in a Resv message for
that Path message ...
... session and PHOP.
A node that sends a LABEL_REQUEST object MUST be ready to accept and
correctly process a LABEL object in the corresponding Resv messages.
...
... Resv messages.
A node that recognizes a LABEL_REQUEST object, but that is unable to
support it (possibly because of a failure to allocate labels) SHOULD
send a PathErr ...
... range.
A node which receives and forwards a Path message each with a
LABEL_REQUEST object, MUST copy the L3PID from the received
...
... network topology.
Typically, the explicit route is determined by a node, with the
intent of directing traffic along that path.
...
... An explicit route is described as a list of groups of nodes along the
explicit route. In addition to the ability to identify specific
...
... explicit route. In addition to the ability to identify specific
nodes along the path, an explicit route can identify a group of nodes ...
... nodes along the path, an explicit route can identify a group of nodes
that must be traversed along the path. This capability allows the
routing system ...
... an EXPLICIT_ROUTE object. Each subobject identifies a group of nodes
in the explicit route. An explicit route ...
... explicit route is thus a specification of
groups of nodes to be traversed.
To formalize the discussion ...
... To formalize the discussion, we call each group of nodes an abstract
node. Thus, we say that an explicit route ...
... group of nodes an abstract
node. Thus, we say that an explicit route is a specification of a
set of abstract nodes ...
... node. Thus, we say that an explicit route is a specification of a
set of abstract nodes to be traversed. If an abstract node consists
of only one node ...
... explicit route is a specification of a
set of abstract nodes to be traversed. If an abstract node consists
of only one node, we refer to it as a simple abstract node ...
... nodes to be traversed. If an abstract node consists
of only one node, we refer to it as a simple abstract node.
...
... node consists
of only one node, we refer to it as a simple abstract node.
As an example of the concept of abstract nodes ...
... node.
As an example of the concept of abstract nodes, consider an explicit
route that consists solely of Autonomous System number subobjects.
...
... topology. In this case, each Autonomous System is an abstract node,
and the explicit route is a path that includes each of the specified
...
... value of the subobject attribute is 'loose' then it is a 'loose
subobject.' Otherwise, it's a 'strict subobject.' Further, we say
that the abstract node of a strict or loose subobject is a strict or
a loose node, respectively. Loose and strict nodes ...
... that the abstract node of a strict or loose subobject is a strict or
a loose node, respectively. Loose and strict nodes are always
interpreted relative to their prior abstract nodes ...
... node of a strict or loose subobject is a strict or
a loose node, respectively. Loose and strict nodes are always
interpreted relative to their prior abstract nodes.
...
... node, respectively. Loose and strict nodes are always
interpreted relative to their prior abstract nodes.
The path between a strict node ...
... node MAY include
other network nodes that are not part of the strict node or its
preceding abstract node ...
... IPv4 address,
a 1-octet prefix length, and a 1-octet pad. The abstract node
represented by this subobject is the set of nodes that have an IP
address ...
... prefix length, and a 1-octet pad. The abstract node
represented by this subobject is the set of nodes that have an IP
address which lies within this prefix. Note that a prefix length ...
... IPv6 address,
a 1-octet prefix length, and a 1-octet pad. The abstract node
represented by this subobject is the set of nodes that have an IP
address ...
... prefix length, and a 1-octet pad. The abstract node
represented by this subobject is the set of nodes that have an IP
address which lies within this prefix. Note that a prefix length ...
... AS) number subobject are a 2-
octet AS number. The abstract node represented by this subobject is
the set of nodes belonging to the autonomous system ...
... AS number. The abstract node represented by this subobject is
the set of nodes belonging to the autonomous system.
...
... must determine the next hop for this path. This is necessary because
the next abstract node along the explicit route might be an IP subnet
...
... dependent and can also be impacted by local policy, and is beyond the
scope of this specification. However, it is assumed that each node
will make a best effort attempt to determine a loop-free path. Note
...
... receiving the RSVP message MUST first evaluate the first
subobject. If the node is not part of the abstract node described
by the first subobject, it has received the message in error and
...
... RSVP message MUST first evaluate the first
subobject. If the node is not part of the abstract node described
by the first subobject, it has received the message in error and
SHOULD return a "Bad initial subobject" error. If there is no
...
... removed from
the Path message. This node may or may not be the end of the
path. Processing continues with section 4.3.4.2, where a new
EXPLICIT_ROUTE object ...
... Path message.
3) Next, the node evaluates the second subobject. If the node is
also a part of the abstract node ...
...
3) Next, the node evaluates the second subobject. If the node is
also a part of the abstract node described by the second
...
... node evaluates the second subobject. If the node is
also a part of the abstract node described by the second
subobject, then the node deletes ...
... also a part of the abstract node described by the second
subobject, then the node deletes the first subobject and continues
processing with step 2, above. Note that this makes the second
...
... processing with step 2, above. Note that this makes the second
subobject into the first subobject of the next iteration and
allows the node to identify the next abstract node on the path of
the message after possible repeated application(s) of steps 2 and
...
... subobject into the first subobject of the next iteration and
allows the node to identify the next abstract node on the path of
the message after possible repeated application(s) of steps 2 and
3.
...
... 3.
4) Abstract Node Border Case: The node determines whether it is
topologically adjacent to the abstract node ...
...
4) Abstract Node Border Case: The node determines whether it is
topologically adjacent to the abstract node described by the
...
... Node Border Case: The node determines whether it is
topologically adjacent to the abstract node described by the
second subobject. If so, the node selects a particular next hop ...
... topologically adjacent to the abstract node described by the
second subobject. If so, the node selects a particular next hop
which is a member of the abstract node ...
... node selects a particular next hop
which is a member of the abstract node. The node then deletes the
...
... next hop
which is a member of the abstract node. The node then deletes the
first subobject and continues processing with section 4.3.4.2.
...
... first subobject and continues processing with section 4.3.4.2.
5) Interior of the Abstract Node Case: Otherwise, the node selects a
next hop ...
...
5) Interior of the Abstract Node Case: Otherwise, the node selects a
next hop within the abstract node ...
... node selects a
next hop within the abstract node of the first subobject (which
the node belongs to) that is along the path to the abstract node ...
... next hop within the abstract node of the first subobject (which
the node belongs to) that is along the path to the abstract node
of the second subobject (which is the next abstract node ...
... node of the first subobject (which
the node belongs to) that is along the path to the abstract node
of the second subobject (which is the next abstract node). If no
...
... node belongs to) that is along the path to the abstract node
of the second subobject (which is the next abstract node). If no
such path exists then there are two cases:
...
...
5a) If the second subobject is a strict subobject, there is an error
and the node SHOULD return a "Bad strict node" error.
...
... 5a) If the second subobject is a strict subobject, there is an error
and the node SHOULD return a "Bad strict node" error.
5b) Otherwise, if the second subobject is a loose subobject, the node ...
... Bad strict node" error.
5b) Otherwise, if the second subobject is a loose subobject, the node
selects any next hop that is along the path to the next abstract
...
... selects any next hop that is along the path to the next abstract
node. If no path exists, there is an error, and the node SHOULD
return a "Bad loose node ...
... next hop that is along the path to the next abstract
node. If no path exists, there is an error, and the node SHOULD
return a "Bad loose node" error.
...
... node. If no path exists, there is an error, and the node SHOULD
return a "Bad loose node" error.
6) Finally, the node ...
... node" error.
6) Finally, the node replaces the first subobject with any subobject
that denotes an abstract node containing the next hop ...
... 6) Finally, the node replaces the first subobject with any subobject
that denotes an abstract node containing the next hop. This is
necessary so that when the explicit route ...
... ROUTE object.
Otherwise, if the node is a member of the abstract node for the first
subobject, a series of subobjects MAY be inserted before the first
...
...
Otherwise, if the node is a member of the abstract node for the first
subobject, a series of subobjects MAY be inserted before the first
subobject or MAY replace the first subobject. Each subobject in this
...
... subobject, a series of subobjects MAY be inserted before the first
subobject or MAY replace the first subobject. Each subobject in this
series MUST denote an abstract node that is a subset of the current
abstract node.
...
... series MUST denote an abstract node that is a subset of the current
abstract node.
Alternately, if the first subobject is a loose subobject, an
...
... While the EXPLICIT_ROUTE object is of finite length, the existence of
loose nodes implies that it is possible to construct forwarding loops
during transients in the underlying routing protocol. This can be
...
...
It is anticipated that new subobjects may be defined over time. A
node which encounters an unrecognized subobject during its normal ERO
processing sends a PathErr ...
... ROUTE object is included, truncated (on the left) to the
offending subobject. The presence of an unrecognized subobject which
is not encountered in a node's ERO processing SHOULD be ignored. It
is passed forward along with the rest of the remaining ERO ...
... Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection ...
... Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection ...
... sender's IP addresses. If the node also desires label recording, it
sets the Label_Recording flag in the SESSION_ATTRIBUTE object ...
... When the Label_Recording flag is set in the SESSION_ATTRIBUTE object,
nodes doing route recording SHOULD include a Label Record subobject.
If the node ...
... nodes doing route recording SHOULD include a Label Record subobject.
If the node is using a global label space, then it SHOULD set the
Global Label flag.
...
... The Label Record subobject is pushed onto the RECORD_ROUTE object
prior to pushing on the node's IP address. A node MUST NOT push on a
...
... prior to pushing on the node's IP address. A node MUST NOT push on a
Label Record subobject without also pushing on an IPv4 or IPv6 ...
...
Note that on receipt of the initial Path message, a node is unlikely
to have a label to include. Once a label is obtained, the node
...
... Path message, a node is unlikely
to have a label to include. Once a label is obtained, the node
SHOULD include the label in the RRO in the next Path refresh ...
... Path message.
Nodes SHOULD resend the above PathErr or ResvErr message each n
seconds where n is the greater of 15 and the refresh interval ...
... refresh interval for the
associated Path or RESV message. The node MAY apply limits and/or
back-off timers to limit the number of messages sent.
...
... records the path information in the reverse direction.
Note that each node along the path will now have the complete route
from source to destination ...
... RRO will have the route from
the source to this node; the Resv RRO will have the route from this
...
... RRO will have the route from this
node to the destination. This is useful for network management.
...
... Path message without an RRO indicates that the sender node
no longer needs route recording. Subsequent Resv messages ...
... nodes receive Path
messages or upstream nodes receive Resv messages with no routing
loops detected in the contained RRO ...
... configuration.
The action performed by a node on receipt of an RRO depends on the
message type ...
... unrecognized subobjects SHOULD be ignored and passed on. When
processing an RRO for loop detection, a node SHOULD parse over any
unrecognized objects. Loop detection works by detecting subobjects
which were inserted by the node ...
... node SHOULD parse over any
unrecognized objects. Loop detection works by detecting subobjects
which were inserted by the node itself on an earlier pass of the
object. This ensures that the subobjects necessary for loop
detection are always understood.
...
... Bad strict node
3 Bad loose node
4 Bad initial subobject
...
... over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address ...
... over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv6 address ...
... bandwidth. In the initial Path message, the ingress node forms a
SESSION object, assigns a Tunnel ...
...
On receipt of the Path message, the egress node sends a Resv message
with the STYLE Shared Explicit toward the ingress node ...
... node sends a Resv message
with the STYLE Shared Explicit toward the ingress node.
When an ingress node ...
... node.
When an ingress node with an established path wants to change that
path, it forms a new Path message as follows. The existing SESSION ...
... Tunnel_ID and Extended_Tunnel_ID
are unchanged. The ingress node picks a new LSP_ID to form a new
SENDER ...
... route. The new Path message is sent. The ingress node refreshes
both the old and new path messages ...
... FILTER_SPEC and LABEL_OBJECT.)
When the ingress node receives the Resv Message(s), it may begin
using the new route ...
...
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
...
... tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message ...
...
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
...
... tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message ...
...
The support of setup and holding priorities is OPTIONAL. A node can
recognize this information but be unable to perform the requested
operation. The node ...
... node can
recognize this information but be unable to perform the requested
operation. The node SHOULD pass the information downstream
unchanged.
...
... senders.
The support of local-protection is OPTIONAL. A node may recognize
the local-protection Flag but may be unable to perform the requested
operation. In this case, the node ...
... node may recognize
the local-protection Flag but may be unable to perform the requested
operation. In this case, the node SHOULD pass the information
downstream unchanged.
...
... resource classes of that link. When a node is choosing links in
order to extend a loose node ...
... no acceptable links can be found to extend the ERO, the node SHOULD
send a PathErr message with an error code ...
... For a link to be acceptable, all three tests MUST pass. If the test
fails, the node SHOULD send a PathErr message with an error code of
...
...
The RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node ...
... RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node to
node ...
... RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node to
node failure detection ...
... node is not reachable. The mechanism provides node to
node failure detection. When such a failure is detected it is
handled much the same as a link layer ...
... failure detection mechanisms provided by the link layer are not
sufficient for timely node failure detection.
...
... neighbors. The IP
source address is the IP address of the sending node. The IP
destination address ...
... destination address is the IP address of the neighbor node.
The HELLO mechanism is intended for use between immediate neighbors ...
... neighbor representation/value. This
value MUST change when the sender is reset, when the node reboots,
or when communication is lost to the neighboring node and
...
... sender is reset, when the node reboots,
or when communication is lost to the neighboring node and
otherwise remains the same. This field MUST NOT be set to zero
...
... The Hello Message is completely OPTIONAL. All messages may be
ignored by nodes which do not wish to participate in Hello message
processing. The balance of this section is written assuming that the
...
... use of MUST and SHOULD with respect to the receiver applies only to a
node that supports Hello message processing.
...
... Hello message processing.
A node periodically generates a Hello message containing a HELLO
REQUEST object for each neighbor ...
... Neighbor_Src_Instance. If no value has ever been received
from the neighbor or this node considers communication to the
neighbor to have been lost, the Neighbor ...
... (0). The generation of a message SHOULD be suppressed when a HELLO
REQUEST object was received from the destination node within the
prior hello_interval interval.
...
... Neighbor_Src_Instance is updated with the new value. If the value
differs or the Src_Instance field is zero, then the node MUST treat
the neighbor as if communication has been lost.
...
... neighbor continues to advertise a wrong non-zero value after a
configured number of intervals, then the node MUST treat the neighbor
as if communication has been lost.
...
... Neighbor_Src_Instance is updated
with the new value. If the value differs or the Src_Instance field
is zero, then the node MUST treat the neighbor as if communication
has been lost.
...
... receiver's Instance value. If the neighbor
advertises a wrong value in the Dst_Instance field, then a node MUST
treat the neighbor as if communication has been lost.
...
... objects, from a neighbor within a configured number of
hello_intervals, then a node MUST presume that it cannot communicate
with the neighbor. The default for this number is 3.5.
...
...
When communication is lost or presumed to be lost as described above,
a node MAY re-initiate HELLOs. If a node does re-initiate it MUST
use a Src_Instance value different than the one advertised in the
...
... When communication is lost or presumed to be lost as described above,
a node MAY re-initiate HELLOs. If a node does re-initiate it MUST
use a Src_Instance value different than the one advertised in the
previous HELLO message ...
... occurs, or until another communication failure is detected. If a new
instance value has not been received from the neighbor, then the node
MUST advertise zero in the Dst_instance value field.
...
...
As previously noted, the Hello extension is targeted at detecting
node failures not per link failures. When there is only one link
...
... link failures. When there is only one link
between neighboring nodes or when all links between a pair of nodes
...
... between neighboring nodes or when all links between a pair of nodes
fail, the distinction between node and link ...
... links between a pair of nodes
fail, the distinction between node and link failures is not really
meaningful and handling of such failures has already been covered.
...
... link failure detection MUST be
provided by some means other than Hellos. Each node SHOULD use a
single Hello exchange with the neighbor. The case where all links ...
... 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
declared sooner than it would have been. RSVP response to that
...