One document matched: draft-thubert-rtgwg-arc-vs-mrt-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="info" docName="draft-thubert-rtgwg-arc-vs-mrt-00" ipr="trust200902">
<front>
<title abbrev="ARC">Available Routing Constructs</title>
<author fullname="Pascal Thubert" initials="P" role="editor"
surname="Thubert">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="Gábor Sándor Enyedi" initials="G"
surname="Enyedi">
<organization abbrev="Ericsson">Ericsson</organization>
</author>
<author fullname="Srinivasan Ramasubramanian" initials="S"
surname="Ramasubramanian">
<organization abbrev="UA">University of Arizona</organization>
<address>
<postal>
<street>1230 E. Speedway Blvd.</street>
<city>Tucson, AZ</city>
<code>85721</code>
<country>USA</country>
</postal>
<phone>+1 520 621 4521</phone>
<email>srini@ece.arizona.edu</email>
</address>
</author>
<date />
<area>Routing Area</area>
<workgroup>RTGWG</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
<!--
Existing fast-reroute approaches enable an alternate route for most
unique breakages but cannot guarantee loopless traffic continuity
in case of multiple breakages, nor easily segragate the impacted
area.
-->
This draft compares the capabilities offered by the
Available Routing Construct (ARC) and the Maximally Redundant Trees (MRT)
techniques in order to support applicability statements.
<!--
In particular, a single breakage in an ARC on the way to a preferred end
is recovered with no routing recomputation using the other end , so
an ARC-based routing topology is resilient to multiple breakages,
one per ARC.-->
</t>
</abstract>
<note title="Requirements Language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Important Notice">
<t>
This document compares
MRT and ARCs based on <xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>,
<xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> and
<xref target="I-D.thubert-rtgwg-arc"/> as they are on 10/12/2012. Both solutions
are about to change, which may make this document outdated.
</t>
</section>
<section title="Introduction">
<t>
Traditional routing and forwarding uses the concept of path as the
basic routing paradigm to get a packet from a source to a destination.
A path is represented as an ordered sequence of nodes.
This paradigm is greedy in that it requires that the next node
represent a progress towards the destination. Greediness is maximized
by Shortest Path First (SPF) techniques which optimize for a cost that relates to
the amount of forwarding effort and latency, at the expense of network capacity
and reliability. In particular, a path is broken as soon as a single link or
a single node fails, and getting around a breakage can require path recomputation,
network reconvergence, and incur delays and/or microloops till service is restored.
</t>
<t>Maximally Redundant Trees <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>
<xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/> (MRT),
on the other hand, favors reliability over shorter path. MRT provides two spanning
trees rooted at a destination, referred to as red and blue trees. The trees have
the property that the red and blue paths from any node to the destination (root of
the tree) are maximally-disjoint. The red and blue paths may not be the shortest
path. Thus, a node may employ shortest path tree for forwarding under normal
circumstances. Thus, every node may have up to three FIB entries for a destination,
one for red tree, one for blue tree, and a third for the shortest path tree.
Under normal circumstances, the idea is to forward the packets along
the shortest path until the packet encounters a failure. If the failed link
is red (blue), then the packet is forwarded along the blue (red) path.
Once a packet is rerouted along the red or blue tree, it continues to be forwarded
along the chosen tree until it reaches the destination. If the packet encounters
another failure, then it is dropped. Thus, MRT is guaranteed to recovery from
only only failure.
</t>
<t> The maximally redundant trees are constructed using a technique called path
augmentation. The approach works as follows: (1) For a given destination node,
a cycle traversing the node and two other nodes are computed. (2) One direction
of the cycle is termed as red, while the other direction is termed as blue. (3)
A cycle or path is computed that starts and ends at a node that has been already
added to the trees. On this cycle/path, one direction is treated as red and the other
direction is treated as blue. The direction of the red and blue trees is computed
based on a partial order, which ensures that the red and blue assignments would
result in disjoint paths along the red and blue trees. The last step is repeated
until all the nodes in the network are considered. For a more detailed description
of the construction, refer to <xref target="Jayavelu.2009.Maintaining"/>.
</t>
<t>MRT constructs trees that are maximally-disjoint. Thus, if the network provided
two node-disjoint paths between a node and destination, MRT would provide
node-disjoint paths as well. If the network does not provide node-disjoint
paths, but provides link-disjoint paths between a node and destination, then
MRT would provide link-disjoint paths as well.
</t>
<t>
<xref target="I-D.thubert-rtgwg-arc"> Available Routing Construct </xref> (ARC)
defines a routing construct made of a bidirectional sequence of nodes and links
with 2 outgoing edges, so that, upon a single breakage, each lively node in
along ARC can still reach one of the outgoing edges. The bi-directional sequence of
nodes and links are similar to the paths/cycles used in the path augmentation technique
in constructing MRT.
The routing graph to reach a certain destination is expressed as a cascade of ARCs,
each ARC providing its own independent domain of fault isolation and recovery.
Unicast traffic may enter an ARC via any node but it may only leave the ARC through
one of its two edges. One node along the ARC is designated as the cursor.
In normal unicast operations, the traffic inside an ARC flows away from the cursor
towards an edge. Upon a failure, packets may bounce on the breakage point and flow
the other way along the ARC to take the other exit. <xref target="I-D.thubert-rtgwg-arc"/>
calculates ARCs within the shortest path computation, and both sides of an ARC
as delineated by the cursor actually represent the shortest path to the destination.
</t>
<!-- need to add stuff to position EARS -->
<t>This drafts compares the properties of the ARC an MRT techniques in a number of
example situations that are crafted to highlight their particular behaviors with
an educational purpose in mind, as opposed to represent the most classical real-world
cases. It must be noted that though the draft focuses on differences, ARCs
and MRT have a lot in common, in particular both provide maximally redundant solutions,
and represent roughly the same amount of labels and states in the packets.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t> The draft uses terminology from <xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>
and <xref target="I-D.thubert-rtgwg-arc"/>.
</t>
</section>
<section anchor="reftopo" title="Reference Topology">
<t> This draft uses a simple reference topology, made of eight nodes A to H and ten
links with costs of either 1 or 2 as represented below:
<figure anchor="grv" title="Reference Topology">
<artwork>
<![CDATA[
A--- 2 ---E A E
| | v
1 1 v
| | v
B--- 1 ---F B >>>>>>> F
| | v v
1 1 v v
| | v v
C--- 1 ---G C >>>>>>> G
| | v
1 1 v
| | v
D--- 1 ---H D H
Topology SPF A to H
]]>
</artwork>
</figure>
In the following examples we will be interested in traffic flowing from A to H.
The shortest path for that flow is via B, then through an equal cost multipath
via F or C, and then G to finally reach H.
</t>
<t> The oLAF algorithm forms three ARCs and MRT forms two trees:
<figure anchor="manda" title="ARC set and MRT Trees">
<artwork>
<![CDATA[
A=========E 5 ------> 4 A <rrrrrr E A bbbbbb> E
| | ^ | r b
| | | | r b
| | | V v v
B=========F 6 ------> 3 B <rrrrrr F B bbbbbb> F
| | ^ | r b
| | | | r b
| | | V v v
C=========G 7 ------> 2 C <rrrrrr G C bbbbbb> G
|| | ^ | r ^ b
|| | | | r b b
|| | | V v b v
D---------H 8 <------ 1 D rrrrrr> H D H
MRT MRT MRT
ARC set GADAG graph Red Tree BLUE Tree
]]>
</artwork>
</figure>
Bidirectional links along the ARCs are represented as doubled lines.
The cursors end up on A, B and C for their respective ARCs.
</t>
</section>
<section anchor="normop" title="Normal Operation">
<t> In normal operations MRT trees are not used so the MRT case is identical to the SPF case.
For ARCs, the cursors A B and C may send traffic on either side but favor shortest. For A that
means sending to B and for C sending to G. B sees an equal cost so it may distribute its traffic.
<figure anchor="noop" title="Normal Operation">
<artwork>
<![CDATA[
A E A E A E
v v v
v v v
v v v
B >>>>>>> F B >>>>>>> F B >>>>>>> F
v v v v v v
v v v v v v
v v v v v v
C >>>>>>> G C >>>>>>> G C >>>>>>> G
v v v
v v v
v v v
D H D H D H
ARC SPF MRT
]]>
</artwork>
</figure>
All in all, the three approaches end up with an identical result.
</t>
</section>
<section anchor="oneB" title="One breakage">
<t>
Upon a first breakage, SPF cannot make a greedy progress so a packet that follows the broken path is dropped.
MRT converts to the packet to blue or red, and then packet is placed in the associated tree till the destination.
Because blue and red have to be non-congruent to the end, the detour that MRT generates tends to route the
packet away from shortest path.
ARCs returns the packet along the current ARC so it exits on the other edge.
As soon as the cursor in the current ARC is passed, the packet is again on shortest path.
<figure anchor="onb" title="ARC closer to shortest path">
<artwork>
<![CDATA[
A E A E A E
v v v
v v v
v v v
B >>>>>>> F B >>>>>>> F B >>>>>>> F
v <<<<<<< v v r <rrrrrr v
v \/ \/ r \/
v /\ /\ v /\
C >>>>>>> G C G C G
v r
v r
v v
D H D H D rrrrrr> H
ARC SPF MRT
]]>
</artwork>
</figure>
Both MRT and ARCs enable fast reroute. MRT will generally incur a larger detour.
In the example above, the ARC path after B is shortest, whereas the red path
selected by MRT is not.
</t>
<t>
Because the blue and red paths of MRT are link-disjoint from any node to the destination,
the recovery path does not visit a broken link again.
ARCs achieve a shorter path by being more greedy. It results that in some situations,
a broken node might be visited twice, once from the above, that is from an incoming ARC,
and then from the side, that is from inside its own ARC. This is illustrated below
though it would take an intermediate node between C and broken G to actually create the
undesired bouncing that is discussed here.
<figure anchor="onb2" title="ARCs may revisit broken node">
<artwork>
<![CDATA[
A E A E A E
v v v
v v v
v v v
B >>>>>>> F B >>>>>>> F B >>>>>>> F
v <<<<<<< v v r <rrrrrr v
v v v r v
v v v v v
C >>>>>>> \/ C \/ C \/
v <<<<<<< /\ /\ r /\
v r
v v
D >>>>>>> H D H D rrrrrr> H
ARC SPF MRT
]]>
</artwork>
</figure>
Note: In the particular case where a broken node is visited twice,
the end to end path that ARC uses may still be shorter than the blue
or red path that MRT computes, though it is not the case in the
particular example above.
</t>
<t>MRT recovers from node failure similar to that of link failure. Note that
the paths provided by MRT are maximally disjoint. Thus at a node, if a link
is unavailable (whether due to a link failure or node failure), the recovery
path is taken. As the paths are maximally disjoint, MRT guarantees that a
failed node would never be visited again.
</t>
</section>
<section anchor="twoB" title="Second breakage">
<t>
Upon a first breakage, SPF cannot make a greedy progress so a packet that follows the broken path is dropped.
Upon a first breakage, MRT selects either blue or red. If that selected path is broken down the road, the packet is dropped.
In the data plane, ARCs protect against one breakage per ARC. Once a packet leaves an ARC to cascade in the next,
stigmata from a previous breakage are removed. So a break on the next ARC can be resolved as well.
<figure anchor="tob" title="Each ARC its own recovery domain">
<artwork>
<![CDATA[
A >>>>>>> E A E A bbbbbb> E
v v v v b
\/ v \/ \/ b
/\ v /\ /\ v
B <<<<<<< F B F B F
v v v
v \/ \/
v /\ /\
C >>>>>>> G C G C G
v
v
v
D H D H D H
ARC SPF MRT
]]>
</artwork>
</figure>
It can be noted that if C to G,G or G to H is broken, ARCs will
find the C, D, H path and thus fix a third breakage as well.
</t>
</section>
<section title="Summary of differences">
<t>In sumary:
<figure anchor="compar" title="Comparison summary">
<artwork>
<![CDATA[
MRT ARC
1. Limited complexity - can be even O(e) Complexity inherited from SPF
2. Detour, unrelated to Shortest Path Short detour then Shortest Path
again
3. Smaller chance to avoid unrelated Higher chance to avoid unrelated
failures failures
-> may address SRLG cases
4. Single failure: reroute at most Single failure may incur double
once reroute
5. Load balancing with traditional Non-equal Cost Load Balancing
ECMP capabilities
6. Unrelated "topologies" exists Detours are strongly bound to
-> reconfiguration after the default paths
failure is simple -> reconfiguration techniques are
difficult
7. Non-Congruent bicasting is not Shorter Path bicasting with
addressed collision avoidance
8. Source-centric computation Destination-centric computation
-> easier to distribute -> allows for complex destinations
]]>
</artwork>
</figure>
</t>
<section title="Differences between ARCs and MRT">
<t>
In this section, we elaborate on the differences listed above.
</t>
<t>
1.
</t>
<t>
ARC is a destination based technology, i.e. it compute a set of ARCs to all the
destinations in the network. Constructing one such set needs several shortest
path computations. This may cause a minor problem: since detours and default paths
are bound, computing the new default paths after a failure may be delayed due to this
slower computation.
</t>
<t>
In contrast, MRT used the traditional shortest paths in a failure-free state,
thus detours can be computed separately, when all the shortest paths are up and
running. Moreover, although MRT offers multiple ways to construct detours
(keep in mind that MRT is only for detours, default paths are computed with SPF),
even the slowest one is as fast as computing one set of
ARCs for a single destination; the fastest algorithm takes only O(e)
time, so it is linear with the number of links in the network.
</t>
<t>
2.
</t>
<t>
In MRT, the paths from any node to the destination on the red and blue trees are
link-disjoint, while in ARC, it is not. Thus, in MRT, neither the red nor the
blue tree is guaranteed to provide shortest path for a node. However, in ARC,
packet is forwarded along the shortest path after a short detour. Naturally,
when there is no failure, both algorithms use the shortest paths, thus this
difference can only be observed after a failure.
</t>
<t>
3.
</t>
<t>
MRT uses separated default paths and detours. As a consequence, one needs to
have three FIB entries one for shortest path forwarding (default), one for red
tree forwarding, and one for blue tree forwarding. When a failure happens, MRT
puts the packet onto a detour, which is not removed until it reaches the destination
(egress router, area border router, etc..). Thus, packet is bound to either the
red path, or the blue path. When the packet encounters a second failure, the packet
is dropped.
</t>
<t>
Although the MRT draft <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> does not
discuss about recovering from multiple failures, the MRT framework allows the
network to recover from multiple link failures, as long as no more than one failure
is seen on a path/cycle that's used for augmentation. Thus, when a packet is
forwarded from one path/cycle to another, the packet can handle one more link failure.
This technique has been shown in <xref target="Erlebach.2009.Path-Splicing"/>.
</t>
<t>
In contrast, ARC partitions the network in delimited protection areas, i.e. it puts packets back to
shortest path when they leave the current ARC. Putting packets back to the
shortest path as soon as they leave the ARC makes it possible to reroute again
at another failure. Moreover, theoretically ARC
needs only two labels/addresses per destination, one describing the shortest path,
and the other describing the other direction in the ARC. However, this approach
would result loops, if there are more than one failure in the same ARC, thus
current version of ARC use at least three labels/addresses per destination.
</t>
<t>
ARC can protect against multiple link failures as long as the only one link failure
occurs on an ARC.
</t>
<t> Since there is
always a reconfiguration after a failure, and FRR is in charge only for a short
amount of time while this reconfiguration takes place, one may think that preparing for
more than one failure is not important. However, there are the "Shared
Risk Link Groups" (SRLG), groups of links sharing the same fate due to some hidden
common property (e.g. they are using the same optical cable), which may cause
multiple failures at the same time. Even if both MRT and ARC can deal with the
most common types of SRLGs (failure of links of the same linecard, and the failure
of some ethernet network under the level of IP; namely the "LAN failure"), it
is better to protect as many resources as possible.
</t>
<t>
4.
</t>
<t>
For the price of having only one reroute, MRT can guarantee that the same
failure will never be visited again. In contrast, since the same node can be an exit
point for multiple ARCs, and since ARC puts packets back to shortest path after
a failure, it is possible that a single failed node will be visited
multiple times. It is very important that ARCs will properly handle this
case with multiple rerouting, so sooner or later the destination will be
reached. Moreover, the probability of such situation seems to be low.
</t>
<t>
5.
</t>
<t>
ARC can provide load balancing for the traffic with the "cursor node",
since ARC gives not only a backup, but a new way for default routing as well.
In contrast, since MRT only provide the detours, load balancing is
not in the focus of MRT, but it is done with traditional ECMP. However, it
is possible that a node have multiple blue or red next-hops with MRT, and in
this case load balancing is possible even for packets on detours.
</t>
<t>
6.
</t>
<t>
IPFRR techniques are for designed for protection, i.e. they are used immediately after a
failure happens. Typically after a failure, traditional
routing protocols like OSPF reexplore the topology and
reconfigure the forwarding entries based on the new topology. Packets start using
the new shortest paths, and the network prepares to protect against a new
failure. Normally, the reconfiguration after a failure may cause transient
forwarding anomalies like micro-loops, but these are not acceptable for IPFRR.
</t>
<t>
Thus, several loop-preventing techniques were proposed in
<xref target="RFC5715"/>. Since MRT provides two independent routing, i.e.
the default shortest paths and the detours, it can use even Farside tunnels,
which does not need protocol extension (basically, MRT can use one routing,
while it reconfigures the other). Although, ARC is capable for loopfree
convergence with centralized loop routing, it is not clear, which technique ARC
could use in a distributed environment.
</t>
<t>
7.
</t>
<t>
Since MRT is an FRR technique, bicasting is out of its scope. However,
bicasting is theoretically possible, if we use the blue and the red next-hops;
naturally, these paths will be node- and link-disjoint. In contrast, ARC was
designed for not only FRR but bicasting, even if it cannot automatically
provide disjoint paths. The advantage is that those paths can be shorter.
For further details consult <xref target="I-D.thubert-rtgwg-arc"/>.
</t>
</section>
<section title="Similarities between ARC and MRT">
<t>
MRT uses a helper graph called GADAG, and detour computation is based on
that graph. This helper graph is basically a set of ARCs with some extra
direction information for the GADAG root as a destination. Thanks to
this common point, computation algorithm and detours are very similar.
</t>
</section>
</section>
<section anchor="stuff" title="ARC specific properties">
<t>
ARC is not only for FRR, but a complex forwarding technique, which can
help in load balancing and speed up reconfiguration. Since MRT is
an only for IPFRR, it cannot change routing in any way in a failure-free
state, and the following properties do not exist.
</t>
<t>
However, it is important to note that for the advantages below we need
to introduce the "cursor" node. Using the concept of a cursor needs some
protocol extension, and it replaces traditional shortest path routing in
some sense.
</t>
<section anchor="mulB" title="Multiple related breakages">
<t>
In control plane, ARCs can find an exit if one exists and in principle,
can be used to solve the Shared Risk Link Group (SRLG) problem. An ARC
set is a Directed Acyclic Graph of ARCs, thus link reversal techniques
can be applied to recover from complex breakages. Upon a second breakage
in a same ARC, a segment is isolated. In control plane, it is possible
to return all the incoming links in that segment. This may recurse if
incoming ARCs become isolated as well. If the process recurses, a link
may be returned a number of times and this must be stopped by some
infinity count. Once the local recovery settles, the exit path stands out.
<figure anchor="tob2" title="SRLG case">
<artwork>
<![CDATA[
A E A E A >>>>>>> E
v ^ v
v | v
v | v
B >>\/ F B \/ F B \/ F
v /\ /\ /\ v
\/ \/ \/ v
/\ /\ /\ v
C G C G C G
v
v
v
D H D H D H
Double Control plane Exit path
breakage Link reversal stands out
]]>
</artwork>
</figure>
This example illustrates that the ARC segment around B is no
more isolated by returning the A -> B edge into a B-> A link.
</t>
<t>
Recovery from multiple failures may also be performed using a variant
of redundant trees, called independent directed acyclic graphs,
which aims to utilize all the links in the network
<xref target="Cho.2012.Independent-DAG" />. With this approach,
every node has one or more forwarding edges in the red/blue trees.
Upon failure of all the red forwarding edges, the packet is transferred
to the blue tree.
</t>
</section>
<section title="Multiple Destination and Load Balancing">
<t>The MRT and ARC techniques may be used for routing to redundant
destination nodes. Given two nodes R1 and R2, MRT can construct
two trees, tree T1 rooted at R1 and tree T2 rooted at R2.
The path from any node to R1 on T1 and to R2 on T2 are still
maximally-disjoint <xref target="Jayavelu.2009.Maintaining"/>.
Similarly, the oLAF algorithm used for constructing ARCs
is destination-oriented, in that it
forms ARCs from the standpoint of the destination.
This makes ARCs more complex to compute in a distributed fashion,
but on the other hand enables to group a set of nodes. </t>
<t>One example of employing multiple destinations is to employ
multiple border routers between one area and another. Thus, the
routing in one area may exit to the other area through one of the
border routers.
</t>
<t>With multiple destinations, it is possible not only to allow high availability
but also to dynamically load balance between the member nodes. In an ARC,
the node that has the logical responsibility of cursor is the only node that
may send packets towards both edges in normal conditions. It is possible
to create a control loop between a congestion point on one side and the cursor,
in order to balance more traffic towards the other edge. If the cursor sends
all its traffic towards the other edge, then the cursor responsibility may be
transferred to the next node towards the congested edge to balance more traffic.
If both edges are congested, then the congestion indication can be recursively
injected in incoming ARCs.
</t>
<t>
An ARC based control loop does not need to involve metric changes or other routing advertisements,
so it can be kept separate from the routing protocol. A simple control loop protocol
can be used, that can be kept from oscillating with appropriate periods and adaptive filters.
<figure anchor="complex" title="Complex Destination and Load Balancing">
<artwork>
<![CDATA[
A<==cur==>E A<==cur==>E A<==cur==>E
| | | | | |
| | | | | |
v v v v v v
B<==cur==>F B<==cur==>F B<==cur F
| | | | | |
| | | | | con
v v v v v gest
C<==cur==>G C<==cur G C<=======cur
| | | | | |
| | | con | con
v v v gest v gest
D OMEGA H D OMEGA H D OMEGA H
Destination is control loop recursing
both A and H to cursor control loop
]]>
</artwork>
</figure>
</t>
</section>
<section title="Hierarchical Routing">
<t>In a hierarchical network, routing happens within cells and then between cells.
The collection of border routers between this cell and the next cell forms a complex destination
for which an ARC set can be formed within this cell. This can be done as soon as the cells are formed,
before any end-to-end route between cell is computed and whatever the routing protocol between cells is.
This model applies in particular for such cells as areas, autonomous systems and optical rings.
</t>
</section>
<section title="Recovery from Node Failures">
<t>
ARCS may be used to achieve fast recovery from node failures as well. The construction of ARC is similar
to the construction of backup forwarding arcs forwarding arcs, as discussed in
<xref target="Xi.2007.Fast-Reroute"/>. The placement of cursors may still be performed once the backup
paths (forwarding edges) are computed after failing each node.
</t>
<t>
</t>
</section>
</section>
<section title="Manageability">
<t>This specification describes a generic model. Protocols and management will come later</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification does not require IANA action.</t>
</section>
<section anchor="Sec" title="Security Considerations">
<t>This specification is not found to introduce new security threat.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wishes to thank Alia Atlas, Patrice Bellagamba, Stewart Bryant, Robert Kebler, and András Császár
for their participation to this particular work, and Dirk Anteunis, IJsbrand Wijnands, George Swallow, Eric Osborne,
Clarence Filsfils and Eric Levy-Abegnoli for their continuous support to components of the work presented here.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5715"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5921"?>
<?rfc include='reference.I-D.enyedi-rtgwg-mrt-frr-algorithm.xml'?>
<?rfc include='reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml'?>
<?rfc include='reference.I-D.thubert-rtgwg-arc.xml'?>
</references>
<references>
<reference anchor="Erlebach.2009.Path-Splicing"
target="http://dx.doi.org/10.1109/INFCOM.2005.1498553">
<front>
<title>Path splicing with guaranteed fault tolerance</title>
<author initials="T." surname="Erlebach" fullname="Thomas Erlebach">
<organization>University of Leicester</organization>
</author>
<author initials="A." surname="Mereu" fullname="Anna Mereu">
<organization>University of Cagliari</organization>
</author>
<date month="November-December" year="2009" />
</front>
<seriesInfo name="Proceedings of IEEE GLOBECOM" value=""/>
</reference>
<reference anchor="Xi.2007.Fast-Reroute"
target="http://eeweb.poly.edu/~chao/docs/public/ipfrr_single1.pdf">
<front>
<title>IP fast rerouting for single-link/node failure recovery</title>
<author initials="K." surname="Xi" fullname="Kang Xi">
<organization>Polytechnic University</organization>
</author>
<author initials="H. J." surname="Chao" fullname="H. Jonathan">
<organization>Polytechnic University</organization>
</author>
<date month="September" year="2007" />
</front>
<seriesInfo name="Proceedings of IEEE BROADNETS" value=""/>
</reference>
<reference anchor="Cho.2012.Independent-DAG"
target="http://dx.doi.org/10.1109/TNET.2011.2161329">
<front>
<title>Independent Directed Acyclic Graphs for Resilient Multipath Routing</title>
<author initials="S." surname="Cho" fullname="Sangman Cho">
<organization>University of Arizona</organization>
</author>
<author initials="T." surname="Elhourani" fullname="Theodore Elhourani">
<organization>University of Arizona</organization>
</author>
<author initials="S." surname="Ramasubramanian" fullname="Srinivasan Ramasubramanian">
<organization>University of Arizona</organization>
</author>
<date month="February" year="2012" />
</front>
<seriesInfo name="IEEE/ACM Transactions on Networking, vol. 20, no. 1" value=""/>
</reference>
<reference anchor="Jayavelu.2009.Maintaining"
target="http://dx.doi.org/10.1109/TNET.2008.919323">
<front>
<title>Maintaining colored trees for disjoint multipath routing under node failures</title>
<author initials="G." surname="Jayavelu" fullname="Giridhar Jayavelu">
<organization>VMware Inc.</organization>
</author>
<author initials="S." surname="Ramasubramanian" fullname="Srinivasan Ramasubramanian">
<organization>University of Arizona</organization>
</author>
<author initials="O." surname="Younis" fullname="Ossame Younis">
<organization>University of Arizona</organization>
</author>
<date month="February" year="2009" />
</front>
<seriesInfo name="IEEE/ACM Transactions on Networking, vol. 17, no. 1" value=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:27:13 |