node
Click on the red underlined text to get to the source
... GMPLS extensions [RFC3473]
allow abstract nodes and resources to be explicitly included in a
path setup, using the Explicit Route Object (ERO ...
...
In some systems, it may be useful to specify and signal abstract
nodes and resources that are to be explicitly excluded from routes.
This may be because loose hops or abstract nodes need to be prevented
...
... nodes and resources that are to be explicitly excluded from routes.
This may be because loose hops or abstract nodes need to be prevented
from selecting a route through a specific resource. This is a
...
... Two types of exclusions are required:
1. Exclusion of certain abstract nodes or resources on the whole
path. This set of abstract nodes is referred to as the Exclude
...
... 1. Exclusion of certain abstract nodes or resources on the whole
path. This set of abstract nodes is referred to as the Exclude
Route list.
...
... Route list.
2. Exclusion of certain abstract nodes or resources between a
specific pair of abstract nodes present in an ERO ...
... 2. Exclusion of certain abstract nodes or resources between a
specific pair of abstract nodes present in an ERO. Such specific
exclusions are referred to as Explicit Exclusion Route ...
... Explicit Exclusion
Route Subobject (EXRS) is introduced to indicate an exclusion
between a pair of included abstract nodes.
The knowledge of SRLGs, as defined in [RFC4216 ...
... groups of resources that should be excluded on the
whole path or between two abstract nodes specified in an explicit
path.
...
... This document does not preclude a route exclusion from listing
arbitrary nodes or network elements to avoid. The intent is,
however, to indicate only the minimal number of subobjects to be
...
... of the choices to exclude at each hop, but rather to constrain the
normal route selection process where loose hops or abstract nodes are
to be expanded by listing certain elements to be avoided.
...
... path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
- Xn denotes a node in domain X, and
...
... Note that Ingress is a node in domain A, and Egress is a node in
domain C. This is shown in Figure 1 where the domains ...
... IGP Areas
Consider the establishment of a node-diverse protection path in the
example above. The protection path must avoid all nodes on the
...
... Consider the establishment of a node-diverse protection path in the
example above. The protection path must avoid all nodes on the
primary path. The exclusions for area A are handled during
Constrained Shortest Path First (CSPF ...
...
The exclude route identifies a list of abstract nodes that should not
be traversed along the path of the LSP being established. It is
...
... RECOMMENDED that the size of the exclude route list be limited to a
value local to the node originating the exclude route list.
...
... ERO subobjects in [RFC3209], is
reused here to indicate that an abstract node MUST be excluded (value
0) or SHOULD be avoided (value 1). The distinction is that the path
...
... 0) or SHOULD be avoided (value 1). The distinction is that the path
of an LSP must not traverse an abstract node listed in the XRO with
the L bit ...
... the L bit clear, but may traverse one with the L bit set. A node
responsible for routing an LSP ...
... routing an LSP (for example, for expanding a loose
hop) should attempt to minimize the number of abstract nodes listed
in the XRO with the L bit ...
... L bit set that are traversed by the LSP according
to local policy. A node generating XRO subobjects with the L bit set
...
... must be prepared to accept an LSP that traverses one, some, or all of
the corresponding abstract nodes.
Subobjects 1, 2, and 4 refer to an interface ...
... An Attribute octet is introduced in these subobjects to indicate the
attribute (e.g., interface, node, SRLG) associated with the
interfaces ...
... interfaces that should be excluded from the path. For instance, the
attribute node allows a whole node to be excluded from the path by
specifying an interface ...
... interfaces that should be excluded from the path. For instance, the
attribute node allows a whole node to be excluded from the path by
specifying an interface of that node ...
... node to be excluded from the path by
specifying an interface of that node in the XRO subobject, in
contrast to the attribute interface ...
... interface (or multiple interfaces) to be excluded from the path
without excluding the whole node. The attribute SRLG allows all
SRLGs associated with an interface ...
... Node attribute value
1 indicates that the node or set of nodes associated with
the IPv4 prefix ...
... Node attribute value
1 indicates that the node or set of nodes associated with
the IPv6 prefix ...
... Node attribute value
1 indicates that the node or set of nodes associated with
the IPv6 prefix should be excluded or avoided.
...
... Node attribute value
1 indicates that the node with the Router ID should be
excluded or avoided (this can be achieved using an IPv4 ...
... The meaning of the L bit is as follows:
0 indicates that the abstract node specified MUST be excluded.
1 indicates that the abstract node specified SHOULD be avoided.
...
... 0 indicates that the abstract node specified MUST be excluded.
1 indicates that the abstract node specified SHOULD be avoided.
The rest of the fields are as defined in [RFC3209 ...
... in an EXCLUDE_ROUTE object. Each subobject identifies an abstract
node in the exclude route list.
...
... node may be a precisely specified IP address belonging
to a node, or an IP address with prefix identifying interfaces ...
...
1. When a Path message is received at a node, the node MUST check
that it is not a member of any of the abstract nodes ...
... 1. When a Path message is received at a node, the node MUST check
that it is not a member of any of the abstract nodes in the XRO ...
... node, the node MUST check
that it is not a member of any of the abstract nodes in the XRO if
it is present in the Path message ...
... XRO if
it is present in the Path message. If the node is a member of any
of the abstract nodes in the XRO ...
... Path message. If the node is a member of any
of the abstract nodes in the XRO with the L-flag set to "exclude",
it SHOULD return a PathErr ...
... Routing Problem"
and error value of "Local node in Exclude Route". If there are
SRLGs in the XRO ...
... Route". If there are
SRLGs in the XRO, the node SHOULD check that the resources the
node uses are not part of any SRLG ...
... XRO, the node SHOULD check that the resources the
node uses are not part of any SRLG with the L-flag set to
"exclude" that is specified in the XRO ...
...
2. Each subobject MUST be consistent. If a subobject is not
consistent then the node SHOULD return a PathErr with error code
...
... Prefix subobject
containing the IP address of a node and the attribute field is set
to "interface" or "SRLG ...
... next hop or expanding an explicit route to include
additional subobjects, a node:
a. MUST NOT introduce an explicit node ...
... node:
a. MUST NOT introduce an explicit node or an abstract node that
equals or is a member of any abstract node ...
...
a. MUST NOT introduce an explicit node or an abstract node that
equals or is a member of any abstract node that is specified in
...
... node or an abstract node that
equals or is a member of any abstract node that is specified in
the EXCLUDE_ROUTE object with the L-flag set to "exclude". The
...
... the EXCLUDE_ROUTE object with the L-flag set to "exclude". The
number of introduced explicit nodes or abstract nodes with the
L flag set to "avoid", which indicates that it is not mandatory
...
... EXCLUDE_ROUTE object with the L-flag set to "exclude". The
number of introduced explicit nodes or abstract nodes with the
L flag set to "avoid", which indicates that it is not mandatory
to be excluded but that it is less preferred, SHOULD be
...
...
b. MUST NOT introduce links, nodes, or resources identified by the
SRLG Id specified in the SRLG ...
... If these rules preclude further forwarding of the Path message,
the node SHOULD return a PathErr with the error code "Routing
Problem ...
... message if the XRO is too large or complicated for the local
implementation or the rules of local policy. In this case, the node
MUST send a PathErr message with the error code ...
... The XRO Class-Num is of the form 11bbbbbb so that nodes that do not
support the XRO forward it uninspected and do not apply the
...
...
Record Route may be used to allow computing nodes to observe
violations of route exclusion and attempt to re-route ...
... accordingly.
If a node supports the XRO, but not a particular subobject or part of
that subobject, then that particular subobject is ignored. Examples
...
... field.
When a node forwards a Path message, it can do the following three
operations related to XRO ...
... remove the XRO if it is sure that
the next nodes do not need this information anymore. An example
is where a node can expand the ERO ...
... the next nodes do not need this information anymore. An example
is where a node can expand the ERO to a full strict path towards
the destination ...
... AB2 is stripping off some subobjects.
In any case, a node MUST NOT introduce any explicit or abstract node
in the XRO ...
...
In any case, a node MUST NOT introduce any explicit or abstract node
in the XRO (irrespective of the value of the L flag) that it also has
...
...
The Explicit Exclusion Route defines abstract nodes or resources
(such as links, unnumbered interfaces ...
... links, unnumbered interfaces, or labels) that must not or
should not be used on the path between two inclusive abstract nodes
or resources in the explicit route.
...
... EXRS subobjects
An EXRS subobject indicates the abstract node or resource to be
excluded. The format of an EXRS subobject is exactly the same
...
... The scope of the exclusion is the step between the previous ERO
subobject that identifies an abstract node, and the subsequent ERO
subobject that identifies an abstract node ...
... node, and the subsequent ERO
subobject that identifies an abstract node. The processing rules of
the EXRS ...
... XRO within this
scope. Multiple exclusions may be present between any pair of
abstract nodes.
Exclusions may indicate explicit nodes ...
... nodes.
Exclusions may indicate explicit nodes, abstract nodes, or Autonomous
Systems that must not be traversed on the path to the next abstract
...
...
Exclusions may indicate explicit nodes, abstract nodes, or Autonomous
Systems that must not be traversed on the path to the next abstract
node ...
... nodes, or Autonomous
Systems that must not be traversed on the path to the next abstract
node indicated in the ERO.
...
... unnumbered
interfaces, link ids, and labels) that must not be used on the path
to the next abstract node indicated in the ERO.
...
...
SRLGs may also be indicated for exclusion from the path to the next
abstract node in the ERO by the inclusion of an EXRS containing an
...
... L bit in the SRLG subobject is zero, the
resources (nodes, links, etc.) identified by the SRLG MUST NOT be
...
... links, etc.) identified by the SRLG MUST NOT be
used on the path to the next abstract node indicated in the ERO. If
the L bit ...
... avoided.
If a node is called upon to process an EXRS and does not support
handling of exclusions it will behave as described in [RFC3209 ...
... an unrecognized ERO subobject is encountered. This means that this
node will return a PathErr with error code "Routing ...
... If the presence of EXRS precludes further forwarding of the Path
message, the node SHOULD return a PathErr with the error code
...
... EXRS is too large or
complicated for the local implementation or as governed by local
policy. In this case, the node MUST send a PathErr message with the
error code ...
... Path
message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes,
links, and resources listed in both places. Where some elements ...
... appear in both lists, it MUST be handled according to the stricter
exclusion request. That is, if one list says that an SRLG, node,
link, or resource must be excluded, and the other says only that it
...
... prefix length
of 32, and an attribute value of "interface" and "node". Other
prefix values and attribute values MAY be supported.
...
... prefix length
of 128, and an attribute value of "interface" and "node". Other
prefix values and attribute values MAY be supported.
...
... ERO processing MUST be rejected as an unknown ERO subobject
as described in Section 4.2. Note that a node SHOULD NOT parse
ahead into an ERO, and if it does, it MUST NOT reject the ERO ...
... be introduced as a form of denial-of-service attack since its
presence will potentially cause additional processing at each node on
the path of the LSP. It should be noted that such an attack ...
... Route Subobject Type
65 = Inconsistent Subobject
66 = Local Node in Exclude Route
67 = Route ...
... fulfilled. In the example of Figure A.1, an LSP has to be
established from node A in area 1 to node C in area 2. If no loose
hops are configured, then the computed ERO ...
... LSP has to be
established from node A in area 1 to node C in area 2. If no loose
hops are configured, then the computed ERO at A could look as
...
... ABR. For the
backup LSP, all nodes of the primary LSP in the next areas have to be
put in the XRO ...
... put in the XRO (with the exception of the destination node if node
protection and no link protection is required). When an ABR ...
... XRO (with the exception of the destination node if node
protection and no link protection is required). When an ABR computes
...
... path segment, i.e., the path over the next area, it may
remove the nodes from the XRO that are located in that area with the
exception of the ABR ...
... XRO, it may remove
the nodes in area 0 from the XRO but not ABR3. Note that not doing
this would not cause harm in this example because there is no path
...
... Discussion on the length of the XRO: When link or node protection is
requested, the length of the XRO is bounded by the length of the RRO ...
... of the primary LSP. It can be made shorter by removing nodes by the
ingress node and the ABRs ...
... primary LSP contains 8 subobjects, while the maximum XRO length can
be bounded by 6 subobjects (nodes A1 and A2 do not have to be in the
XRO). For SRLG ...
... LSP to
provide link or node protection) is established, the same method as
for the inter-area ...
...
(but with different ASBRs -- at least in case of node protection), it
is similar to the inter-area case: ASBRs ...
... When an edge-node wants to establish an LSP towards another edge-node
over an optical core network as described in [RFC4208 ...
... Figure A.2
A first application is where an edge-node wants to establish multiple
LSPs towards the same destination ...
... LSPs towards the same destination edge-node, and these LSPs need to
have few or no SRLGs in common. In this case EN1 could establish an
...
... links.
Another application is where the edge-node wants to set up a backup
LSP that is also protecting the links ...
... LSP that is also protecting the links between the edge-nodes and
core-nodes. For instance, when EN2 establishes an LSP ...
... links between the edge-nodes and
core-nodes. For instance, when EN2 establishes an LSP to EN4, it
sends a Path message ...
... properties (e.g., a path going over CN2 and CN3, and then to EN4).
It is clear that in these examples, the core-node may not alter the
RRO in a Resv message ...
... RRO in a Resv message to make its only contents be the subobjects
from the egress core-node through the egress edge-node.
...
... Resv message to make its only contents be the subobjects
from the egress core-node through the egress edge-node.
...
... RFC3630]
and [RFC3784] are not used. Hence, each node has to select a next-
hop and possibly crankback [CRANKBACK ...
... XRO can be put in the Path message to exclude the links, nodes, or
SRLGs of the primary LSP. An alternative way to provide this
...
... primary LSP and which type of protection is
required. This latter solution would work for link and node
protection, but not for SRLG protection.
...
... TE extensions of the IGPs are not
used in this example. Hence, a node cannot translate any link IP
address located in that area to its SRLGs.
...