]>
Algorithms for computing Maximally Redundant Trees for IP/LDP Fast-RerouteEricssonKonyves Kalman krt 11BudapestHungary1097Gabor.Sandor.Enyedi@ericsson.comEricssonKonyves Kalman krt 11BudapestHungary1097Andras.Csaszar@ericsson.comJuniper Networks10 Technology Park DriveWestfordMA01886USAakatlas@juniper.netJuniper Networks1194 N. Mathilda Ave.SunnyvaleCA94089USAcbowers@juniper.netUniversity of Arizona1230 E Speedway Blvd.TucsonUSA85721AZabishek@ece.arizona.edu
Routing
Routing Area Working GroupA complete solution for IP and LDP Fast-Reroute using Maximally
Redundant Trees is presented in
[I-D.ietf-rtgwg-mrt-frr-architecture]. This document defines the
associated MRT Lowpoint algorithm that is used in the default MRT
profile to compute both the necessary Maximally Redundant Trees
with their associated next-hops and the alternates to select for
MRT-FRR.MRT Fast-Reroute requires that packets can be forwarded not only
on the shortest-path tree, but also on two Maximally Redundant Trees
(MRTs), referred to as the MRT-Blue and the MRT-Red. A router which
experiences a local failure must also have pre-determined which
alternate to use. This document defines how to compute these three
things for use in MRT-FRR and describes the algorithm design
decisions and rationale. The algorithm is based on those presented
in and expanded in . The MRT Lowpoint algorithm is required for
implementation when the default MRT profile is implemented.Just as packets routed on a hop-by-hop basis require that each
router compute a shortest-path tree which is consistent, it is
necessary for each router to compute the MRT-Blue next-hops and
MRT-Red next-hops in a consistent fashion. This document defines
the MRT Lowpoint algorithm to be used as a standard in the default MRT profile for MRT-FRR.As now, a router's FIB will contain primary next-hops for the
current shortest-path tree for forwarding traffic. In addition, a
router's FIB will contain primary next-hops for the MRT-Blue for
forwarding received traffic on the MRT-Blue and primary next-hops
for the MRT-Red for forwarding received traffic on the MRT-Red.What alternate next-hops a point-of-local-repair (PLR) selects
need not be consistent - but loops must be prevented. To reduce
congestion, it is possible for multiple alternate next-hops to be
selected; in the context of MRT alternates, each of those alternate
next-hops would be equal-cost paths.This document defines an algorithm for selecting an appropriate
MRT alternate for consideration. Other alternates, e.g. LFAs that
are downstream paths, may be prefered when available and that
policy-based alternate selection process is
not captured in this document.Algorithms for computing MRTs can handle arbitrary network
topologies where the whole network graph is not 2-connected, as in
, as well as the
easier case where the network graph is 2-connected (). Each MRT is a spanning
tree. The pair of MRTs provide two paths from every node X to the
root of the MRTs. Those paths share the minimum number of nodes and
the minimum number of links. Each such shared node is a cut-vertex.
Any shared links are cut-links.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in A graph that reflects the network
topology where all links connect exactly two nodes and broadcast
links have been transformed into a pseudo-node representation
(e.g. in OSPF, viewing a Network LSA as representing a
pseudo-noe). A pair of trees where the
path from any node X to the root R on the first tree is
node-disjoint with the path from the same node X to the root
along the second tree. These can be computed in 2-connected
graphs.A pair of trees
where the path from any node X to the root R along the first tree
and the path from the same node X to the root along the second
tree share the minimum number of nodes and the minimum number of
links. Each such shared node is a cut-vertex. Any shared links
are cut-links. Any RT is an MRT but many MRTs are not RTs. From the computing router, the set of
routers that support a particular MRT profile and are
connected. MRT-Red is used to describe one of the
two MRTs; it is used to describe the associated forwarding
topology and MT-ID. Specifically, MRT-Red is the decreasing MRT
where links in the GADAG are taken in the direction from a higher
topologically ordered node to a lower one. MRT-Blue is used to describe one of the
two MRTs; it is used to describe the associated forwarding
topology and MT-ID. Specifically, MRT-Blue is the increasing MRT
where links in the GADAG are taken in the direction from a lower
topologically ordered node to a higher one.A vertex whose removal partitions the
network.A link whose removal partitions the
network. A cut-link by definition must be connected between two
cut-vertices. If there are multiple parallel links, then they
are referred to as cut-links in this document if removing the set
of parallel links would partition the network. A graph that has no cut-vertices.
This is a graph that requires two nodes to be removed before the
network is partitioned.A tree containing links that
connects all nodes in the network graph.In the context of a spanning tree
computed via a depth-first search, a back-edge is a link that
connects a descendant of a node x with an ancestor of x.A maximal set of nodes that
are 2-connected. In a network graph with at least one
cut-vertex, there will be multiple 2-connected clusters.Either a 2-connected cluster, a cut-link,
or an isolated vertex.Directed Acyclic Graph - a digraph containing
no directed cycle.Almost Directed Acyclic Graph - a digraph
that can be transformed into a DAG with removing a single node
(the root node).A subset of an ADAG that doesn't yet
contain all the nodes in the block. A partial ADAG is created
during the MRT algorithm and then expanded until all nodes in the
block are included and it is an ADAG.Generalized ADAG - a digraph, which has only
ADAGs as all of its blocks. The root of such a block is the node
closest to the global root (e.g. with uniform link costs).Depth-First SearchA node n is a DFS ancestor of x if n
is on the DFS-tree path from the DFS root to x.A node n is a DFS descendant of x if x
is on the DFS-tree path from the DFS root to n.A path along not-yet-included-in-the-GADAG
nodes that starts at a node that is already-included-in-the-GADAG
and that ends at a node that is already-included-in-the-GADAG.
The starting and ending nodes may be the same node if it is a
cut-vertex.Indicates the
relationship between X and Y in a partial order, such as found in
a GADAG. X >> Y means that X is higher in the partial
order than Y. Y << X means that Y is lower in the partial
order than X. Indicates the relationship
between X and Y in the total order, such as found via a
topological sort. X > Y means that X is higher in the total
order than Y. Y < X means that Y is lower in the total order than X.A node added to the network graph to
represent a multi-homed prefix or routers outside the local
MRT-fast-reroute-supporting island of routers. The key property
of proxy-nodes is that traffic cannot transit them.In the GADAG, each link is marked as
OUTGOING, INCOMING or both. Until the directionality of the link
is determined, the link is marked as UNDIRECTED to indicate that
its direction hasn't been determined.In the GADAG, each link is marked as
OUTGOING, INCOMING or both. A link marked as OUTGOING has
direction from the interface's router to the remote end.In the GADAG, each link is marked as
OUTGOING, INCOMING or both. A link marked as INCOMING has
direction from the remote end to the interface's router.There are five key concepts that are critical for understanding the
MRT Lowpoint algorithm and other algorithms for computing MRTs. The
first is the idea of partially ordering the nodes in a network graph
with regard to each other and to the GADAG root. The second is the
idea of finding an ear of nodes and adding them in the correct
direction. The third is the idea of a Low-Point value and how it can
be used to identify cut-vertices and to find a second path towards the
root. The fourth is the idea that a non-2-connected graph is made up
of blocks, where a block is a 2-connected cluster, a cut-link or an
isolated node. The fifth is the idea of a local-root for each node;
this is used to compute ADAGs in each block.Given any two nodes X and Y in a graph, a particular total order
means that either X < Y or X > Y in that total order. An
example would be a graph where the nodes are ranked based upon their
unique IP loopback addresses. In a partial order, there may be some
nodes for which it can't be determined whether X << Y or X
>> Y. A partial order can be captured in a directed graph, as
shown in . In a graphical
representation, a link directed from X to Y indicates that X is a
neighbor of Y in the network graph and X << Y.To compute MRTs, the root of the MRTs is at both the very bottom
and the very top of the partial ordering. This means that from any
node X, one can pick nodes higher in the order until the root is
reached. Similarly, from any node X, one can pick nodes lower in the
order until the root is reached. For instance, in , from G the higher nodes picked can be traced by
following the directed links and are H, D, E and R. Similarly, from G
the lower nodes picked can be traced by reversing the directed links
and are F, B, A, and R. A graph that represents this modified partial
order is no longer a DAG; it is termed an Almost DAG (ADAG) because if
the links directed to the root were removed, it would be a DAG.Most importantly, if a node Y >> X, then Y can only appear on
the increasing path from X to the root and never on the decreasing
path. Similarly, if a node Z << X, then Z can only appear on
the decreasing path from X to the root and never on the inceasing
path.When following the increasing paths, it is possible to pick
multiple higher nodes and still have the certainty that those paths
will be disjoint from the decreasing paths. E.g. in the previous
example node B has multiple possibilities to forward packets along an
increasing path: it can either forward packets to C or F.For simplicity, the basic idea of creating a GADAG by adding ears
is described assuming that the network graph is a single 2-connected
cluster so that an ADAG is sufficient. Generalizing to multiple
blocks is done by considering the block-roots instead of the GADAG
root - and the actual algorithm is given in .In order to understand the basic idea of finding an ADAG, first
suppose that we have already a partial ADAG, which doesn't contain all
the nodes in the block yet, and we want to extend it to cover all the
nodes. Suppose that we find a path from a node X to Y such that X and
Y are already contained by our partial ADAG, but all the remaining
nodes along the path are not added to the ADAG yet. We refer to such a
path as an ear.Recall that our ADAG is closely related to a partial order, more
precisely, if we remove root R, the remaining DAG describes a partial
order of the nodes. If we suppose that neither X nor Y is the root, we
may be able to compare them. If one of them is definitely lesser with
respect to our partial order (say X<<Y), we can add the new path
to the ADAG in a direction from X to Y. As an example consider .In this partial ADAG, node C is not yet included. However, we can
find path B-C-D, where both endpoints are contained by this partial
ADAG (we say those nodes are *ready* in the sequel), and the remaining
node (node C) is not contained yet. If we remove R, the remaining DAG
defines a partial order, and with respect to this partial order we can
say that B<<D, so we can add the path to the ADAG in the
direction from B to D (arcs B->C and C->D are added). If B
>> D, we would add the same path in reverse direction.If in the partial order where an ear's two ends are X and Y, X
<< Y, then there must already be a directed path from X to Y in
the ADAG. The ear must be added in a direction such that it doesn't
create a cycle; therefore the ear must go from X to Y.In the case, when X and Y are not ordered with each other, we can
select either direction for the ear. We have no restriction since
neither of the directions can result in a cycle. In the corner case
when one of the endpoints of an ear, say X, is the root (recall that
the two endpoints must be different), we could use both directions
again for the ear because the root can be considered both as smaller
and as greater than Y. However, we strictly pick that direction in
which the root is lower than Y. The logic for this decision is
explained in A partial ADAG is started by finding a cycle from the root R back
to itself. This can be done by selecting a non-ready neighbor N of R
and then finding a path from N to R that doesn't use any links between
R and N. The direction of the cycle can be assigned either way since
it is starting the ordering.Once a partial ADAG is already present, it will always have a node
that is not the root R in it. As a brief proof that a partial ADAG
can always have ears added to it: just select a non-ready neighbor N
of a ready node Q, such that Q is not the root R, find a path from N
to the root R in the graph with Q removed. This path is an ear where
the first node of the ear is Q, the next is N, then the path until the
first ready node the path reached (that second ready node is the other
endpoint of the path). Since the graph is 2-connected, there must be a
path from N to R without Q.It is always possible to select a non-ready neighbor N of a ready
node Q so that Q is not the root R. Because the network is
2-connected, N must be connected to two different nodes and only one
can be R. Because the initial cycle has already been added to the
ADAG, there are ready nodes that are not R. Since the graph is
2-connected, while there are non-ready nodes, there must be a
non-ready neighbor N of a ready node that is not R.Algorithm merely requires that a
cycle or ear be selected without specifying how. Regardless of the
way of selecting the path, we will get an ADAG. The method used for
finding and selecting the ears is important; shorter ears result in
shorter paths along the MRTs. The MRT Lowpoint algorithm's method
using Low-Point Inheritance is defined in . Other methods are described in the
Appendices ( and ).As an example, consider
again. First, we select the shortest cycle containing R, which can be
R-A-B-F-D-E (uniform link costs were assumed), so we get to the
situation depicted in (b). Finally, we
find a node next to a ready node; that must be node C and assume we
reached it from ready node B. We search a path from C to R without B
in the original graph. The first ready node along this is node D, so
the open ear is B-C-D. Since B<<D, we add arc B->C and
C->D to the ADAG. Since all the nodes are ready, we stop at this
point.A basic way of computing a spanning tree on a network graph is to
run a depth-first-search, such as given in . This tree has the important property that if
there is a link (x, n), then either n is a DFS ancestor of x or n is a
DFS descendant of x. In other words, either n is on the path from the
root to x or x is on the path from the root to n.Given a node x, one can compute the minimal DFS number of the
neighbours of x, i.e. min( D(w) if (x,w) is a link). This gives the
highest attachment point neighbouring x. What is interesting, though,
is what is the highest attachment point from x and x's descendants.
This is what is determined by computing the Low-Point value, as given
in Algorithm and illustrated on a
graph in .From the low-point value and lowpoint parent, there are three very
useful things which motivate our computation.First, if there is a child c of x such that L(c) >= D(x), then
there are no paths in the network graph that go from c or its
descendants to an ancestor of x - and therefore x is a cut-vertex. In
, this can be seen by
looking at the DFS children of C. C has two children - D and F and
L(F) = 3 = D(C) so it is clear that C is a cut-vertex and F is in a
block where C is the block's root. L(D) = 0 > 3 = D(C) so D has a
path to the ancestors of C; in this case, D can go via E to reach R.
Comparing the low-point values of all a node's DFS-children with the
node's DFS-value is very useful because it allows identification of
the cut-vertices and thus the blocks.Second, by repeatedly following the path given by lowpoint_parent,
there is a path from x back to an ancestor of x that does not use the
link [x, x.dfs_parent] in either direction. The full path need not be
taken, but this gives a way of finding an initial cycle and then
ears. Third, as seen in ,
even if L(x) < D(x), there may be a block that contains both the
root and a DFS-child of a node while other DFS-children might be in
different blocks. In this example, C's child D is in the same block
as R while F is not. It is important to realize that the root of a
block may also be the root of another block. A key idea for an MRT algorithm is that any non-2-connected graph
is made up by blocks (e.g. 2-connected clusters, cut-links, and/or
isolated nodes). To compute GADAGs and thus MRTs, computation is done
in each block to compute ADAGs or Redundant Trees and
then those ADAGs or Redundant Trees are combined into a GADAG or
MRT.Consider the example depicted in (a). In this figure, a special
graph is presented, showing us all the ways 2-connected clusters can
be connected. It has four blocks: block 1 contains R, A, B, C, D, E,
block 2 contains C, F, G, H, I, J, block 3 contains K, L, M, N, O, P,
and block 4 is a cut-link containing H and K. As can be observed, the
first two blocks have one common node (node C) and blocks 2 and 3 do
not have any common node, but they are connected through a cut-link
that is block 4. No two blocks can have more than one common node,
since two blocks with at least 2 common nodes would qualify as a
single 2-connected cluster.Moreover, observe that if we want to get from one block to another,
we must use a cut-vertex (the cut-vertices in this graph are C, H, K),
regardless of the path selected, so we can say that all the paths from
block 3 along the MRTs rooted at R will cross K first. This
observation means that if we want to find a pair of MRTs rooted at R,
then we need to build up a pair of RTs in block 3 with K as a
root. Similarly, we need to find another pair of RTs in block 2 with C
as a root, and finally, we need the last pair of RTs in block 1 with R
as a root. When all the trees are selected, we can simply combine
them; when a block is a cut-link (as in block 4), that cut-link is
added in the same direction to both of the trees. The resulting trees
are depicted in (b) and
(c).Similarly, to create a GADAG it is sufficient to compute ADAGs in
each block and connect them.It is necessary, therefore, to identify the cut-vertices, the
blocks and identify the appropriate local-root to use for each
block.Each node in a network graph has a local-root, which is the
cut-vertex (or root) in the same block that is closest to the root.
The local-root is used to determine whether two nodes share a common
block. There are two different ways of computing the local-root for each
node. The stand-alone method is given in and better illustrates the concept;
it is used by the MRT algorithms given in the Appendices and . The
MRT Lowpoint algorithm computes the local-root for a block as part of
computing the GADAG using lowpoint inheritance; the essence of this
computation is given in .
Once the local-roots are known, two nodes X and Y are in a common
block if and only if one of the following three conditions apply.Y's local-root is X's local-root : They are in the same block and
neither is the cut-vertex closest to the root.Y's local-root is X: X is the cut-vertex closest to the root for
Y's blockY is X's local-root: Y is the cut-vertex closest to the root for
X's blockOnce we have computed the local-root for each node in the network
graph, we can assign for each node, a block id that represents the
block in which the node is present. This computation is
shown in . This algorithm computes one GADAG that is then used by a router to
determine its MRT-Blue and MRT-Red next-hops to all destinations.
Finally, based upon that information, alternates are selected for each
next-hop to each destination. The different parts of this algorithm
are described below. These work on a network graph after its
interfaces have been ordered as per .Compute the local MRT Island for the particular MRT Profile. [See .]Select the root to use for the GADAG. [See .]Initialize all interfaces to UNDIRECTED. [See .]Compute the DFS value,e.g. D(x), and lowpoint value, L(x). [See
.]Construct the GADAG. [See ]Assign directions to all interfaces that are still UNDIRECTED. [See
.]From the computing router x, compute the next-hops for the MRT-Blue
and MRT-Red. [See .]Identify alternates for each next-hop to each destination
by determining which one of the blue MRT and the red MRT the computing
router x should select. [See .]To ensure consistency in computation, all routers MUST order
interfaces identically down to the set of links with the same metric
to the same neighboring node. This is necessary for the DFS, where
the selection order of the interfaces to explore results in different
trees, and for computing the GADAG, where the selection order of the
interfaces to use to form ears can result in different GADAGs. The
required ordering between two interfaces from the same router x is
given in .The local MRT Island for a particular MRT profile can be determined
by starting from the computing router in the network graph and doing a
breadth-first-search (BFS), exploring only links that aren't
MRT-ineligible.In Section 7 of ,
the GADAG Root Selection is described for the MRT default profile. In
and , a mechanism is given for routers to
advertise the GADAG Root Selection Priority and consistently select a
GADAG Root inside the local MRT Island. The MRT Lowpoint algorithm
simply requires that all routers in the MRT Island MUST select the
same GADAG Root; the mechanism can vary based upon the MRT profile
description. Before beginning computation, the network graph is
reduced to contain only the set of routers that support the specific
MRT profile whose MRTs are being computed.Analysis has shown that the centrality of a router can have a
significant impact on the lengths of the alternate paths computed.
Therefore, it is RECOMMENDED that off-line analysis that considers the
centrality of a router be used to help determine how good a choice a
particular router is for the role of GADAG root.Before running the algorithm, there is the standard type of
initialization to be done, such as clearing any computed DFS-values,
lowpoint-values, DFS-parents, lowpoint-parents, any MRT-computed
next-hops, and flags associated with algorithm.It is assumed that a regular SPF computation has been run so that
the primary next-hops from the computing router to each destination
are known. This is required for determining alternates at the last
step.Initially, all interfaces MUST be initialized to UNDIRECTED.
Whether they are OUTGOING, INCOMING or both is determined when the
GADAG is constructed and augmented.Due to manageability consideration , overload, or a transient
cause such as , it is possible that some links
and nodes will be marked as unusable. This constraint must be
consistently flooded via the IGP so that links are clearly known to be
MRT-ineligible and not explored or used in the MRT algorithm. In the
algorithm description, it is assumed that such links and nodes will
not be explored or used and no more discussion is given of this
restriction.As discussed in , it is necessary to find
ears from a node x that is already in the GADAG (known as IN_GADAG).
Two different methods are used to find ears in the algorithm. The
first is by going to a not IN_GADAG DFS-child and then following the
chain of low-point parents until an IN_GADAG node is found. The
second is by going to a not IN_GADAG neighbor and then following the
chain of DFS parents until an IN_GADAG node is found. As an ear is
found, the associated interfaces are marked based on the direction
taken. The nodes in the ear are marked as IN_GADAG. In the
algorithm, first the ears via DFS-children are found and then the ears
via DFS-neighbors are found.By adding both types of ears when an IN_GADAG node is processed,
all ears that connect to that node are found. The order in which the
IN_GADAG nodes is processed is, of course, key to the algorithm. The
order is a stack of ears so the most recent ear is found at the top of
the stack. Of course, the stack stores nodes and not ears, so an
ordered list of nodes, from the first node in the ear to the last node
in the ear, is created as the ear is explored and then that list is
pushed onto the stack.Each ear represents a partial order (see ) and processing the nodes in order along each
ear ensures that all ears connecting to a node are found before a node
higher in the partial order has its ears explored. This means that
the direction of the links in the ear is always from the node x being
processed towards the other end of the ear. Additionally, by using a
stack of ears, this means that any unprocessed nodes in previous ears
can only be ordered higher than nodes in the ears below it on the
stack.In this algorithm that depends upon Low-Point inheritance, it is
necessary that every node have a low-point parent that is not itself.
If a node is a cut-vertex, that may not yet be the case. Therefore,
any nodes without a low-point parent will have their low-point parent
set to their DFS parent and their low-point value set to the DFS-value
of their parent. This assignment also properly allows an ear between
two cut-vertices.Finally, the algorithm simultaneously computes each node's
local-root, as described in .
This is further elaborated as follows. The local-root can be
inherited from the node at the end of the ear unless the end of the ear
is x itself, in which case the local-root for all the nodes in the ear
would be x. This is because whenever the first cycle is found in a block,
or an ear involving a bridge is computed, the cut-vertex closest to the
root would be x itself. In all other scenarios, the properties of
lowpoint/dfs parents ensure that the end of the ear will be in the same block,
and thus inheriting its local-root would be the correct local-root for all
newly added nodes. The pseudo-code for the GADAG algorithm (assuming that the
adjustment of lowpoint for cut-vertices has been made) is shown in
.The GADAG, regardless of the algorithm used to construct it, at
this point could be used to find MRTs but the topology does not
include all links in the network graph. That has two impacts. First,
there might be shorter paths that respect the GADAG partial ordering
and so the alternate paths would not be as short as possible. Second,
there may be additional paths between a router x and the root that are
not included in the GADAG. Including those provides potentially more
bandwidth to traffic flowing on the alternates and may reduce
congestion compared to just using the GADAG as currently
constructed.The goal is thus to assign direction to every remaining link marked
as UNDIRECTED to improve the paths and number of paths found when the
MRTs are computed.To do this, we need to establish a total order that respects the
partial order described by the GADAG. This can be done using Kahn's
topological sort which essentially
assigns a number to a node x only after all nodes before it (e.g. with
a link incoming to x) have had their numbers assigned. The only issue
with the topological sort is that it works on DAGs and not ADAGs or
GADAGs.To convert a GADAG to a DAG, it is necessary to remove all links
that point to a root of block from within that block. That provides
the necessary conversion to a DAG and then a topological sort can be
done. Finally, all UNDIRECTED links are assigned a direction based
upon the partial ordering. Any UNDIRECTED links that connect to a
root of a block from within that block are assigned a direction
INCOMING to that root. The exact details of this whole process are
captured in Proxy-nodes do not need to be added to the network graph. They
cannot be transited and do not affect the MRTs that are computed. The
details of how the MRT-Blue and MRT-Red next-hops are computed and how
the appropriate alternate next-hops are selected is given in .As was discussed in , once a ADAG
is found, it is straightforward to find the next-hops from any node X
to the ADAG root. However, in this algorithm, we want to reuse the
common GADAG and find not only the one pair of MRTs rooted at the
GADAG root with it, but find a pair rooted at each node. This is
useful since it is significantly faster to compute. It may also
provide easier troubleshooting of the MRT-Red and MRT-Blue.The method for computing differently rooted MRTs from the common
GADAG is based on two ideas. First, if two nodes X and Y are ordered
with respect to each other in the partial order, then an SPF along
OUTGOING links (an increasing-SPF) and an SPF along INCOMING links (a
decreasing-SPF) can be used to find the increasing and decreasing paths.
Second, if two nodes X and Y aren't ordered with respect to each other
in the partial order, then intermediary nodes can be used to create
the paths by increasing/decreasing to the intermediary and then
decreasing/increasing to reach Y.As usual, the two basic ideas will be discussed assuming the
network is two-connected. The generalization to multiple blocks is
discussed in . The
full algorithm is given in .To find two node-disjoint paths from the computing router X to any
node Y, depends upon whether Y >> X or Y << X. As shown
in , if Y >> X, then there is an
increasing path that goes from X to Y without crossing R; this
contains nodes in the interval [X,Y]. There is also a decreasing path
that decreases towards R and then decreases from R to Y; this contains
nodes in the interval [X,R-small] or [R-great,Y]. The two paths
cannot have common nodes other than X and Y.Similar logic applies if Y << X, as shown in . In this case, the increasing path from X
increases to R and then increases from R to Y to use nodes in the
intervals [X,R-great] and [R-small, Y]. The decreasing path from X
reaches Y without crossing R and uses nodes in the interval [Y,X].When X and Y are not ordered, the first path should increase until
we get to a node G, where G >> Y. At G, we need to decrease to
Y. The other path should be just the opposite: we must decrease until
we get to a node H, where H << Y, and then increase. Since R is
smaller and greater than Y, such G and H must exist. It is also easy
to see that these two paths must be node disjoint: the first path
contains nodes in interval [X,G] and [Y,G], while the second path
contains nodes in interval [H,X] and [H,Y]. This is illustrated in
. It is necessary to decrease and
then increase for the MRT-Blue and increase and then decrease for the
MRT-Red; if one simply increased for one and decreased for the other,
then both paths would go through the root R.This gives disjoint paths as long as G and H are not the same node.
Since G >> Y and H << Y, if G and H could be the same
node, that would have to be the root R. This is not possible because
there is only one incoming interface to the root R which is created
when the initial cycle is found. Recall from that whenever an ear was found to have an
end that was the root R, the ear was directed from R so that the
associated interface on R is outgoing and not incoming. Therefore,
there must be exactly one node M which is the largest one before R, so
the MRT-Red path will never reach R; it will turn at M and decrease
to Y.The basic ideas for computing RT next-hops in a 2-connected graph
were given in and . Given these two ideas, how can we
find the trees?If some node X only wants to find the next-hops (which is usually
the case for IP networks), it is enough to find which nodes are
greater and less than X, and which are not ordered; this can be done
by running an increasing-SPF and a decreasing-SPF rooted at X and not
exploring any links from the ADAG root. ( Traversal algorithms other
than SPF could safely be used instead where one traversal takes the
links in their given directions and the other reverses the links'
directions.)An increasing-SPF rooted at X and not exploring links from the root
will find the increasing next-hops to all Y >> X. Those
increasing next-hops are X's next-hops on the MRT-Blue to reach Y. An
decreasing-SPF rooted at X and not exploring links from the root will
find the decreasing next-hops to all Z << X. Those decreasing
next-hops are X's next-hops on the MRT-Red to reach Z. Since the root
R is both greater than and less than X, after this increasing-SPF and
decreasing-SPF, X's next-hops on the MRT-Blue and on the MRT-Red to
reach R are known. For every node Y >> X, X's next-hops on the
MRT-Red to reach Y are set to those on the MRT-Red to reach R. For
every node Z << X, X's next-hops on the MRT-Blue to reach Z are
set to those on the MRT-Blue to reach R.For those nodes, which were not reached, we have the next-hops as
well. The increasing MRT-Blue next-hop for a node, which is not
ordered, is the next-hop along the decreasing MRT-Red towards R and
the decreasing MRT-Red next-hop is the next-hop along the increasing
MRT-Blue towards R. Naturally, since R is ordered with respect to all
the nodes, there will always be an increasing and a decreasing path
towards it. This algorithm does not provide the complete specific
path taken but just the appropriate next-hops to use. The identity of
G and H is not determined.The final case to considered is when the root R computes its own
next-hops. Since the root R is << all other nodes, running an
increasing-SPF rooted at R will reach all other nodes; the MRT-Blue
next-hops are those found with this increasing-SPF. Similarly, since
the root R is >> all other nodes, running a decreasing-SPF rooted
at R will reach all other nodes; the MRT-Red next-hops are those found
with this decreasing-SPF.As an example consider the situation depicted in . There node C runs an increasing-SPF
and a decreasing-SPF The increasing-SPF reaches D, E and R and the
decreasing-SPF reaches B, A and R. So towards E the increasing next-hop
is D (it was reached though D), and the decreasing next-hop is B
(since R was reached though B). Since both D and B, A and R will
compute the next hops similarly, the packets will reach E.We have the next-hops towards F as well: since F is not ordered
with respect to C, the MRT-Blue next-hop is the decreasing one towards
R (which is B) and the MRT-Red next-hop is the increasing one towards
R (which is D). Since B is ordered with F, it will find, for its
MRT-Blue, a real increasing next-hop, so packet forwarded to B will
get to F on path C-B-F. Similarly, D will have, for its MRT-Red, a
real decreasing next-hop, and the packet will use path C-D-F.If a graph isn't 2-connected, then the basic approach given in
needs some extensions to
determine the appropriate MRT next-hops to use for destinations
outside the computing router X's blocks. In order to find a pair of
maximally redundant trees in that graph we need to find a pair of RTs
in each of the blocks (the root of these trees will be discussed
later), and combine them.When computing the MRT next-hops from a router X, there are three
basic differences:Only nodes in a common block with X should be explored in the increasing-SPF
and decreasing-SPF.Instead of using the GADAG root, X's local-root should be used.
This has the following implications:
The links from X's local-root should not be explored. If a node is explored in the outgoing SPF so Y >> X, then X's
MRT-Red next-hops to reach Y uses X's MRT-Red next-hops to reach X's
local-root and if Z << X, then X's MRT-Blue next-hops to reach Z
uses X's MRT-Blue next-hops to reach X's local-root.If a node W in a common block with X was not reached in the
increasing-SPF or decreasing-SPF, then W is unordered with respect to X.
X's MRT-Blue next-hops to W are X's decreasing aka MRT-Red next-hops
to X's local-root. X's MRT-Red next-hops to W are X's increasing aka
Blue MRT next-hops to X's local-root.For nodes in different blocks, the next-hops must be inherited
via the relevant cut-vertex.These are all captured in the detailed algorithm given in .The complete algorithm to compute MRT Next-Hops for a particular
router X is given in . In
addition to computing the MRT-Blue next-hops and MRT-Red next-hops
used by X to reach each node Y, the algorithm also stores an
"order_proxy", which is the proper cut-vertex to reach Y if it is
outside the block, and which is used later in deciding whether the
MRT-Blue or the MRT-Red can provide an acceptable alternate for a
particular primary next-hop. At this point, a computing router S knows its MRT-Blue next-hops
and MRT-Red next-hops for each destination in the MRT Island. The
primary next-hops along the SPT are also known. It remains to
determine for each primary next-hop to a destination D, which of the
MRTs avoids the primary next-hop node F. This computation depends upon
data set in Compute_MRT_NextHops such as each node y's
y.blue_next_hops, y.red_next_hops, y.order_proxy, y.higher, y.lower
and topo_orders. Recall that any router knows only which are the
nodes greater and lesser than itself, but it cannot decide the
relation between any two given nodes easily; that is why we need
topological ordering.For each primary next-hop node F to each destination D, S can call
Select_Alternates(S, D, F, primary_intf) to determine whether to use
the MRT-Blue next-hops as the alternate next-hop(s) for that primary next
hop or to use the MRT-Red next-hops. The algorithm is given in and discussed afterwards.If either D>>S>>F or D<<S<<F holds true, the
situation is simple: in the first case we should choose the increasing Blue
next-hop, in the second case, the decreasing Red next-hop is the right
choice.However, when both D and F are greater than S the situation is not so
simple, there can be three possibilities: (i) F>>D (ii) F<<D or
(iii) F and D are not ordered. In the first case, we should choose the
path towards D along the Blue tree. In contrast, in case (ii) the
Red path towards the root and then to D would be the solution.
Finally, in case (iii) both paths would be acceptable. However,
observe that if e.g. F.topo_order>D.topo_order, either case (i) or
case (iii) holds true, which means that selecting the Blue next-hop
is safe. Similarly, if F.topo_order<D.topo_order, we should select
the Red next-hop. The situation is almost the same if both F and D
are less than S. Recall that we have added each link to the GADAG in some direction,
so it is impossible that S and F are not ordered. But it is
possible that S and D are not ordered, so we need to deal with this
case as well. If F<<S, we can use the Red next-hop, because that
path is first increasing until a node definitely greater than D is
reached, than decreasing; this path must avoid using F. Similarly, if
F>>S, we should use the Blue next-hop.Additionally, the cases where either F or D is ordered both higher
and lower must be considered; this can happen when one is a block-
root or its order_proxy is. If D is both higher and lower than S,
then the MRT to use is the one that avoids F so if F is higher, then
the MRT-Red should be used and if F is lower, then the MRT-Blue should
be used; F and S must be ordered because they are neighbors. If F is
both higher and lower, then if D is lower, using the MRT-Red to
decrease reaches D and if D is higher, using the Blue MRT to increase
reaches D; if D is unordered compared to S, then the situation is a
bit more complicated.
In the case where F<<S<<F and D and S are unordered, the
direction of the link in the GADAG between S and F should be
examined. If the link is directed S -> F, then use the MRT-Blue
(decrease to avoid that link and then increase). If the link is
directed S <- F, then use the MRT-Red (increase to avoid that link
and then decrease). If the link is S <--> F, then the link must be
a cut-link and there is no node-protecting alternate. If there are
multiple links between S and F, then they can protect against each
other; of course, in this situation, they are probably already ECMP.
Finally, there is the case where D is also F. In this case, only link
protection is possible. The MRT that doesn't use the indicated
primary next-hop is used. If both MRTs use the primary next-hop,
then the primary next-hop must be a cut-link so either MRT could be
used but the set of MRT next-hops must be pruned to avoid that
primary next-hop. To indicate this case, Select_Alternates returns
AVOID_LINK_ON_BLUE.As an example, consider the ADAG depicted in
and first suppose that G is the
source, D is the destination and H is the failed next-hop.
Since D>>G, we need to compare H.topo_order and D.topo_order.
Since D.topo_order>H.topo_order, D must be not smaller than H, so
we should select the decreasing path towards the root. If, however, the
destination were instead J, we must find that H.topo_order>J.topo_order,
so we must choose the increasing Blue next-hop to J, which is I.
In the case, when instead the destination is C, we find that we need
to first decrease to avoid using H, so the Blue, first decreasing then
increasing, path is selected.As discussed in Section 10.2 of , it is necessary to
find MRT-Blue and MRT-Red next-hops and MRT-FRR alternates for a named
proxy-nodes. An example case is for a router that is not part of that
local MRT Island, when there is only partial MRT support in the
domain.A first incorrect and naive approach to handling proxy-nodes, which
cannot be transited, is to simply add these proxy-nodes to the graph
of the network and connect it to the routers through which the new
proxy-node can be reached. Unfortunately, this can introduce some new
ordering between the border routers connected to the new node which
could result in routing MRT paths through the proxy-node. Thus, this
naive approach would need to recompute GADAGs and redo SPTs for each
proxy-node.Instead of adding the proxy-node to the original network graph,
each individual proxy-node can be individually added to the GADAG.
The proxy-node is connected to at most two nodes in the GADAG.
Section 10.2 of
defines how the proxy-node attachments MUST be determined. The
degenerate case where the proxy-node is attached to only one node in
the GADAG is trivial as all needed information can be derived from
that attachment node; if there are different interfaces, then some can
be assigned to MRT-Red and others to MRT_Blue.Now, consider the proxy-node that is attached to exactly two nodes
in the GADAG. Let the order_proxies of these nodes be A and B. Let
the current node, where next-hop is just being calculated, be S. If
one of these two nodes A and B is the local root of S, let
A=S.local_root and the other one be B. Otherwise, let A.topo_order
< B.topo_order. A valid GADAG was constructed. Instead doing an increasing-SPF and
a decreasing-SPF to find ordering for the proxy-nodes, the following
simple rules, providing the same result, can be used independently for
each different proxy-node. For the following rules, let
X=A.local_root, and if A is the local root, let that be strictly lower
than any other node. Always take the first rule that matches.
These rules are realized in the following pseudocode where P is the
proxy-node, X and Y are the nodes that P is attached to, and S is the
computing router:
After finding the the red and the blue next-hops, it is necessary to
know which one of these to use in the case of failure. This can be
done by Select_Alternates_Inner(). In order to use
Select_Alternates_Internal(), we need to know if P is greater, less or
unordered with S, and P.topo_order. P.lower = B.lower, P.higher =
A.higher, and any value is OK for P.topo_order, until
A.topo_order<=P.topo_order<=B.topo_order and P.topo_order is not
equal to the topo_order of the failed node. So for simplicity let
P.topo_order=A.topo_order when the next-hop is not A, and
P.topo_order=B.topo_order otherwise. This gives the following pseudo-code:
This specification defines the MRT Lowpoint Algorithm, which
include the construction of a common GADAG and the computation of
MRT-Red and MRT-Blue next-hops to each node in the graph. An
implementation MAY select any subset of next-hops for MRT-Red and
MRT-Blue that respect the available nodes that are described in for each of the MRT-Red and
MRT-Blue and the selected next-hops are further along in the interval
of allowed nodes towards the destination. For example, the MRT-Blue next-hops used when the destination Y
>> S, the computing router, MUST be one or more nodes, T, whose
topo_order is in the interval [X.topo_order, Y.topo_order] and where Y
>> T or Y is T. Similarly, the MRT-Red next-hops MUST be have a
topo_order in the interval [R-small.topo_order, X.topo_order] or
[Y.topo_order, R-big.topo_order].Implementations SHOULD implement the Select_Alternates() function
to pick an MRT-FRR alternate.In a future version, this section will include pseudo-code
describing the full code path through the pseudo-code given earlier in
the draft.This specification defines the MRT Lowpoint Algorithm, which is one
option among several possible MRT algorithms. Other alternatives are
described in the appendices.In addition, it is possible to calculate Destination-Rooted GADAG,
where for each destination, a GADAG rooted at that destination is
computed. Then a router can compute the blue MRT and red MRT
next-hops to that destination. Building GADAGs per destination is
computationally more expensive, but may give somewhat shorter
alternate paths. It may be useful for live-live multicast along
MRTs.The MRT Lowpoint algorithm is the lowest computation of the MRT
algorithms. Two other MRT algorithms are provided in and . When
analyzed on service provider network topologies, they did not provide
significant differences in the path lenghts for the alternatives.
This section does not focus on that analysis or the decision to use
the MRT Lowpoint algorithm as the default MRT algorithm; it has the
lowest computational and storage requirements and gave comparable
results.Since this document defines the MRT Lowpoint algorithm for use in
fast-reroute applications, it is useful to compare MRT and Remote LFA
. This section compares MRT
and remote LFA for IP Fast Reroute in 19 service provider network
topologies, focusing on coverage and alternate path length. shows the node-protecting
coverage provided by local LFA (LLFA), remote LFA (RLFA), and MRT
against different failure scenarios in these topologies. The coverage
values are calculated as the percentage of source-destination pairs
protected by the given IPFRR method relative to those protectable by
optimal routing, against the same failure modes. More details on
alternate selection policies used for this analysis are described
later in this section.
For the topologies analyzed here, LLFA is able to provide
node-protecting coverage ranging from 37% to 95% of the
source-destination pairs, as seen in the column labeled NP_LLFA. The
use of RLFA in addition to LLFA is generally able to increase the
node-protecting coverage. The percentage of node-protecting coverage
with RLFA is provided in the column labeled NP_RLFA, ranges from 59%
to 98% for these topologies. The node-protecting coverage provided by
MRT is 100% since MRT is able to provide protection for any
source-destination pair for which a path still exists after the
failure.
We would also like to measure the quality of the alternate paths
produced by these different IPFRR methods. An obvious approach is to
take an average of the alternate path costs over all
source-destination pairs and failure modes. However, this presents a
problem, which we will illustrate by presenting an example of results
for one topology using this approach ( ). In this table, the average
relative path length is the alternate path length for the IPFRR method
divided by the optimal alternate path length, averaged over all
source-destination pairs and failure modes. The first three columns
of data in the table give the path length calculated from the sum of
IGP metrics of the links in the path. The results for topology T208
show that the metric-based path lengths for NP_LLFA and NP_RLFA
alternates are on average 78 and 66 times longer than the path lengths
for optimal alternates. The metric-based path lengths for MRT
alternates are on average 14 times longer than for optimal alternates.
The network topology represented by T208 uses values of 10, 100, and
1000 as IGP costs, so small deviations from the optimal alternate path
can result in large differences in relative path length. LLFA, RLFA,
and MRT all allow for at least one hop in the alterate path to be
chosen independent of the cost of the link. This can easily result in
an alternate using a link with cost 1000, which introduces noise into
the path length measurement. In the case of T208, the adverse effects
of using metric-based path lengths is obvious. However, we have
observed that the metric-based path length introduces noise into
alternate path length measurements in several other topologies as
well. For this reason, we have opted to measure the alternate path
length using hopcount. While IGP metrics may be adjusted by the
network operator for a number of reasons (e.g. traffic engineering),
the hopcount is a fairly stable measurement of path length. As shown
in the last three columns of ,
the hopcount-based alternate path lengths for topology T208 are fairly
well-behaved.
, , , and present the hopcount-based path
length results for the 19 topologies examined. The topologies in the
four tables are grouped based on the size of the topologies, as
measured by the number of nodes, with having the smallest topologies
and having the largest
topologies. Instead of trying to represent the path lengths of a
large set of alternates with a single number, we have chosen to
present a histogram of the path lengths for each IPFRR method and
alternate selection policy studied. The first eight colums of data
represent the percentage of failure scenarios protected by an
alternate N hops longer than the primary path, with the first column
representing an alternate 0 or 1 hops longer than the primary path,
all the way up through the eighth column respresenting an alternate 14
or 15 hops longer than the primary path. The last column in the table
gives the percentage of failure scenarios for which there is no
alternate less than 16 hops longer than the primary path. In the case
of LLFA and RLFA, this category includes failure scenarios for which
no alternate was found.
For each topology, the first row (labeled OPTIMAL) is the distribution
of the number of hops in excess of the primary path hopcount for
optimally routed alternates. (The optimal routing was done with
respect to IGP metrics, as opposed to hopcount.) The second
row(labeled NP_LLFA) is the distribution of the extra hops for
node-protecting LLFA. The third row (labeled NP_LLFA_THEN_NP_RLFA) is
the hopcount distribution when one adds node-protecting RLFA to
increase the coverage. The alternate selection policy used here first
tries to find a node-protecting LLFA. If that does not exist, then it
tries to find an RLFA, and checks if it is node-protecting. Comparing
the hopcount distribution for RLFA and LLFA across these topologies,
one can see how the coverage is increased at the expense of using
longer alternates. It is also worth noting that while superficially
LLFA and RLFA appear to have better hopcount distributions than
OPTIMAL, the presence of entries in the last column (no alternate <
16) mainly represent failure scenarios that are not protected, for
which the hopcount is effectively infinite.
The fourth and fifth rows of each topology show the hopcount
distributions for two alternate selection policies using MRT
alternates. The policy represented by the label
NP_LLFA_THEN_MRT_LOWPOINT will first use a node-protecting LLFA. If a
node-protecting LLFA does not exist, then it will use an MRT
alternate. The policy represented by the label MRT_LOWPOINT instead
will use the MRT alternate even if a node-protecting LLFA exists. One
can see from the data that combining node-protecting LLFA with MRT
results in a significant shortening of the alternate hopcount
distribution.
In the preceding analysis, the following procedure for selecting
an RLFA was used. Nodes were ordered with respect to distance from the
source and checked for membership in Q and P-space. The first node to
satisfy this condition was selected as the RLFA. More sophisticated
methods to select node-protecting RLFAs is an area of active research.
The analysis presented above uses the MRT Lowpoint Algorithm
defined in this specification with a common GADAG root. The
particular choice of a common GADAG root is expected to affect the
quality of the MRT alternate paths, with a more central common GADAG
root resulting in shorter MRT alternate path lengths. For the
analysis above, the GADAG root was chosen for each topology by
calculating node centrality as the sum of costs of all shortest paths
to and from a given node. The node with the lowest sum was chosen as
the common GADAG root. In actual deployments, the common GADAG root
would be chosen based on the GADAG Root Selection Priority advertised
by each router, the values of which would be determined off-line.
In order to measure how sensitive the MRT alternate path lengths are
to the choice of common GADAG root, we performed the same analysis
using different choices of GADAG root. All of the nodes in the
network were ordered with respect to the node centrality as computed
above. Nodes were chosen at the 0th, 25th, and 50th percentile with
respect to the centrality ordering, with 0th percentile being the most
central node. The distribution of alternate path lengths for those
three choices of GADAG root are shown in for a subset of
the 19 topologies (chosen arbitrarily). The third row for each
topology (labeled MRT_LOWPOINT ( 0 percentile) ) reproduces the
results presented above for MRT_LOWPOINT_ONLY. The fourth and fifth
rows show the alternate path length distibution for the 25th and 50th
percentile choice for GADAG root. One can see some impact on the path
length distribution with the less central choice of GADAG root
resulting in longer path lenghths.
We also looked at the impact of MRT algorithm variant on the alternate
path lengths. The first two rows for each topology present results of
the same alternate path length distribution analysis for the SPF and
Hybrid methods for computing the GADAG. These two methods are
described in and . For three of the topologies in this
subset (T201, T206, and T211), the use of SPF or Hybrid methods does
not appear to provide a significant advantage over the Lowpoint method
with respect to path length. Instead, the choice of GADAG root
appears to have more impact on the path length. However, for two of
the topologies in this subset(T216 and T219) and for this particular
choice of GAGAG root, the use of the SPF method results in noticeably
shorter alternate path lengths than the use of the Lowpoint or Hybrid
methods. It remains to be determined if this effect applies generally
across more topologies or is sensitive to choice of GADAG root.
The algorithm assumes that
broadcast interfaces are already represented as pseudo-nodes in the
network graph. Given maximal redundancy, one of the MRT will try to
avoid both the pseudo-node and the next hop. The exact rules need to be
fully specified.This doument includes no request to IANA.This architecture is not currently believed to introduce new security concerns.
&I-D.ietf-rtgwg-mrt-frr-architecture;
&RFC2119;
&RFC3137;
&RFC5286;
&RFC5714;
&I-D.ietf-rtgwg-ipfrr-notvia-addresses;
&I-D.ietf-rtgwg-remote-lfa;
&I-D.ietf-rtgwg-lfa-manageability;
&I-D.atlas-ospf-mrt;
&I-D.li-isis-mrt;
&I-D.atlas-mpls-ldp-mrt;
Topological sorting of large networksNovel Algorithms for IP Fast Reroute
&RFC6571;
IP Fast ReRoute: Lightweight Not-Via without Additional AddressesIP Fast ReRoute: Loop Free Alternates RevisitedOn Finding Maximally Redundant Trees in Strictly Linear TimeThe basic idea in this option is to use slightly-modified SPF
computations to find ears. In every block, an SPF
computation is first done to find a cycle from the local root and then
SPF computations in that block find ears until there are no more interfaces
to be explored. The used result from the SPF computation is the path of
interfaces indicated by following the previous hops from the mininized
IN_GADAG node back to the SPF root.To do this, first all cut-vertices must be identified and local-roots
assigned as specified in .The slight modifications to the SPF are as follows. The root of the
block is referred to as the block-root; it is either the GADAG root or
a cut-vertex.The SPF is rooted at a neighbor x of an IN_GADAG node y. All links
between y and x are marked as TEMP_UNUSABLE. They should not be used
during the SPF computation.If y is not the block-root, then it is marked TEMP_UNUSABLE. It
should not be used during the SPF computation. This prevents ears
from starting and ending at the same node and avoids cycles; the
exception is because cycles to/from the block-root are acceptable
and expected.Do not explore links to nodes whose local-root is not the block-root.
This keeps the SPF confined to the particular block.Terminate when the first IN_GADAG node z is minimized.Respect the existing directions (e.g. INCOMING, OUTGOING,
UNDIRECTED) already specified for each interface.Assume that an ear is found by going from y to x and then running
an SPF that terminates by minimizing z
(e.g. y<->x...q<->z). Now it is necessary to determine
the direction of the ear; if y << z, then the path should be
y->x...q->z but if y >> z, then the path should be
y<-x...q<-z. In , the same
problem was handled by finding all ears that started at a node before
looking at ears starting at nodes higher in the partial order. In
this algorithm, using that approach could mean that new ears aren't
added in order of their total cost since all ears connected to a node
would need to be found before additional nodes could be found.The alternative is to track the order relationship of each node
with respect to every other node. This can be accomplished by
maintaining two sets of nodes at each node. The first set,
Higher_Nodes, contains all nodes that are known to be ordered above
the node. The second set, Lower_Nodes, contains all nodes that are
known to be ordered below the node. This is the approach used in this
algorithm.A goal of the algorithm is to find the shortest cycles and ears.
An ear is started by going to a neighbor x of an IN_GADAG node y. The
path from x to an IN_GADAG node is minimal, since it is computed via
SPF. Since a shortest path is made of shortest paths, to find the
shortest ears requires reaching from the set of IN_GADAG nodes to the
closest node that isn't IN_GADAG. Therefore, an ordered tree is
maintained of interfaces that could be explored from the IN_GADAG
nodes. The interfaces are ordered by their characteristics of metric,
local loopback address, remote loopback address, and ifindex, as in
the algorithm previously described in .The algorithm ignores interfaces picked from the ordered tree that belong
to the block root if the block in which the interface is present already has
an ear that has been computed. This is necessary since we allow at most one
incoming interface to a block root in each block. This requirement stems from
the way next-hops are computed as will be seen in
. After any ear gets computed, we
traverse the newly added nodes to the GADAG and insert interfaces whose far
end is not yet on the GADAG to the ordered tree for later processing.Finally, cut-links are a special case because there is no point in
doing an SPF on a block of 2 nodes. The algorithm identifies
cut-links simply as links where both ends of the link are
cut-vertices. Cut-links can simply be added to the GADAG with both
OUTGOING and INCOMING specified on their interfaces.In this option, the idea is to combine the salient features of the above
two options. To this end, we process nodes as they get added to the GADAG just
like in the lowpoint inheritance by maintaining a stack of nodes. This
ensures that we do not need to maintain lower and higher sets at each node
to ascertain ear directions since the ears will always be directed from the
node being processed towards the end of the ear. To compute the ear however,
we resort to an SPF to have the possibility of better ears (path lentghs) thus
giving more flexibility than the restricted use of lowpoint/dfs parents.Regarding ears involving a block root, unlike the SPF method which ignored
interfaces of the block root after the first ear, in the hybrid method we
would have to process all interfaces of the block root before moving on to
other nodes in the block since the direction of an ear is pre-determined.
Thus, whenever the block already has an ear computed, and we are processing an
interface of the block root, we mark the block root as unusable before the SPF
run that computes the ear. This ensures that the SPF terminates at some node
other than the block-root. This in turn guarantees that the block-root has
only one incoming interface in each block, which is necessary for correctly
computing the next-hops on the GADAG. As in the SPF gadag, bridge ears are handled as a special case.The entire algorithm is shown below in