One document matched: draft-thubert-rtgwg-arc-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="std" docName="draft-thubert-rtgwg-arc-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="Patrice Bellagamba" initials="P"
surname="Bellagamba">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street>214 Avenue des fleurs</street>
<city>Saint-Raphaël</city>
<code>83700</code>
<country>FRANCE</country>
</postal>
<phone>+33.6.1998.4346</phone>
<email>pbellaga@cisco.com</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 introduces the concept of ARC, a two-edged routing
construct that forms its own fault isolation and recovery domain.
The new paradigm can be leveraged to improve the network utilization
and resiliency for unicast and multicast traffic in multiple environments.
<!--
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="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
by following an ordered sequence of arrows between intermediate nodes.
In this serial design, a path is broken as soon as a single arrow is,
<!--that is as soon as a node or a link along the path ceases to operate
appropriately;--> and getting around a breakage can require path recomputation,
network reconvergence, and incur delays to till service is restored.
</t>
<t>
Multiple paths can be bound together for instance to form a Directed Acyclic Graph (DAG) to a destination,
but that technique can be difficult to balance and cannot provide a full path redundancy even
in the case of a biconnected graph. For instance, if the node that is closest to the DAG
destination has only one link to that destination, then it does not have a alternate path
to get to that destination.
</t>
<t>
It is also possible to compute an alternate routing topology for fast
rerouting to a given destination, in which case some signalling, tagging
or labelling can be put in place to indicate whether a packet follows the
normal path or was rerouted over an alternate topology. Once a packet
is rerouted, it is bound to the alternate topology so only one breakage
can be handled with looplessness guarantees in most practical situations.
</t>
<t>
This draft introduces the concept of an Available Routing Construct (ARC)
as a routing construct made of a 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. As a result, an ARC is this resilient to one breakage as
opposed to an arrow that has only one outgoing edge, and an ARC topology is resilient
to one breakage per ARC.
</t>
<t>
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.
<!--and the traffic circulates towards the destination by cascading from ARC to ARC. -->
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.
</t>
<t>
Aa a result an ARC is resilient to any single failure, and the recovery
can be driven either from the data plane or the control plane.
A second failure occurring within a same ARC will isolate an ARC segment.
This can be further corrected from the control plane by reversing all
the incoming Edges in a process that might recurse till an exit is found.
When ARC reversal is applied, an ARC topology is resilient to some cases
of Shared Risk Link Group (SRLG) failures.
</t>
<t>This draft presents the concept and provides an intuition of how ARCs can simplify
the operation and improve the network utilization and resiliency for all sorts of
traffic in multiple environments, but defers to further documents to elaborate
on the algorithms and optimizations in the different application domains.
</t>
<t><!--
For instance, ARCs can be used in the context <xref target="RFC6550"/> in order to improve
the reliability of multihop transmissions over Low Power and Lossy Networks.-->
For instance, ARCs can also be used in datacenters for the purpose of fast-reroute, or within
a service provider network to simplify load balancing operations or leverage optimally the
ring topologies <xref target="RFC5921"/>. An ARC topology can be flooded
over itself and serve as a backbone for <!--bicasting and --> reliable multicasting operations.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t> The draft uses the following terminology:
<list style="hanging">
<t hangText="ARC:"> Available Routing Construct. An ARC is a loopless ordered set of nodes
and links whereby traffic may enter via any node in the ARC but may only leave the ARC through either one of the ARC edges.
</t>
<t hangText="Comb:"> An ARC generalization: a Comb is a n-edged loopless
set of nodes and links with n >= 2; traffic may enter via any node in the Comb
but may only exit the Comb through one of its n edges.
A Comb comes with a walk operation that enables to attempt to exit via every edge
and to discover when all have been tried.
</t>
<t hangText="Cursor:"> A virtual point along an ARC that can be located on a node or
on a link between 2 nodes. In normal operations, the traffic along the ARC flows away
from its Cursor. If the cursor is a node, then traffic can be distributed on both sides.
The Cursor may be moved to change the way traffic is load balanced along an ARC.
It may also be placed at the location of a failure to direct traffic away from that point.
</t>
<t hangText="ARC Node:"> A Node that belongs to an ARC.
</t>
<t hangText="Edge ARC Node:"> An ARC Node at an edge of its ARC.
An Edge ARC Node is a node via wich traffic can exit the ARC.
</t>
<t hangText="Edge Link:"> A directed link outgoing from an Edge ARC Node.
Traffic can only exit from an ARC via an Edge Link. An Edge Link does not accept
traffic into an ARC.
</t>
<t hangText="Intermediate ARC Node:"> A node that is not at an edge of an ARC.
A Intermediate ARC Node node that can receive traffic and forward traffic
between its adjacent nodes.
</t>
<t hangText="Intermediate Link:"> A link between two Intermediate ARC Nodes.
An Intermediate Link is reversible, meaning that traffic is allowed in both directions
though an individual packet is constrained in the way its direction is reversed.
For stable links such as wired links, the typical constraint is that the direction of a
packet may be reversed at most once along a given ARC.
</t>
<t hangText="Collapsed ARC:"> An ARC that is formed of a single node. This node is altogether
the cursor and both Edge Nodes. This implies that the node has at least 2 outgoing links to
2 different Safe Nodes.
<figure anchor="C-ARC" title="Collapsed ARC">
<artwork>
<![CDATA[
|
|
V
C+EAN
/|\
/ | \
| V |
V V
E: Edge ARC Node -| collapsed in a single node
C: Cursor -|
]]>
</artwork>
</figure>
</t>
<t hangText="Infrastructure ARC:"> An ARC that is formed of more than one node, which also
means that the Edge Nodes are different nodes.
<figure anchor="I-ARC" title="Infrastructure ARC">
<artwork>
<![CDATA[
| \ | |
| \ | | |
V V V |
_->IAN<---->IAN<---->IAN<---->IAN<-_ |
/ + C \ |
/ \|
V V
EAN EAN
| /|\
| / | \
| | V |
V V V
IAN: Intermediate ARC Node -|
EAN: Edge ARC Node |- All are Safe Nodes
C: Cursor -|
]]>
</artwork>
</figure>
</t>
<t hangText="DAG:"> Directed Acyclic Graph.
</t>
<t hangText="ARC Set (or Cascade):"> A DAG with ARCs as vertices. In the DAG, an edge between
ARC A and ARC B corresponds to a link from an Edge ARC Node in ARC A and an arbitrary
ARC Node in ARC B. Note that by definition, an ARC has at least 2 outgoing Edge Links,
one per Edge Node, and maybe more if an Edge Node has multiple outgoing Edge Links.
All vertices in the DAG have 2 forwarding solutions, even the ARC closest to the
destination.
</t>
<t hangText="Omega:"> the abstract destination (== root) of an ARC Set.
</t>
<t hangText="ARC Height:"> An arbitrary distance from Omega that is associated to an ARC.
The Height of an ARC must be more than the Height of any of the ARCs it terminates into. The order
of ARC formation by a given algorithm can be used as a Height whereby an ARC is always
strictly higher or lower than another.
</t>
<t hangText="Buttressing ARC:"> A split ARC that is merged into another ARC at
one edge. An ARC and one or more Buttressing ARCs form a Comb construct that is
resilient to additional breakages.
A Buttressing ARC may be applied to an ARC or a Comb iff traffic outgoing
the Buttressing ARC Edge always reaches in an ARC that is lower than this ARC,
or Omega.
<figure anchor="B-ARC" title="Comb with Buttressing ARC">
<artwork>
<![CDATA[
| \ | |
| \ | | |
V V V |
_->IAN<---->IAN<---->IAN<---->IAN<-_----->IAN<-_
/ + C \ | \
/ \| \
V V V
EAN EAN EAN
| /|\ |
| / | \ |
| | V | |
V V V V
]]>
</artwork>
</figure>
</t>
<t hangText="Safe Node:"> A node is Safe if there is no single point of failure
- apart from the node itself - on its way to Omega. From this definition, a node is
Safe if it has at least two non-congruent paths to two different other Safe Nodes.
It results that a Safe node that is not Omega has at least two completely disjunct paths to Omega. When an ARC has been successfully constructed, all its nodes become
safe with respect to the Omega for which the ARC was constructed.
By extension for a collapsed path Omega is deemed to be Safe, that is any node that
pertains in Omega is a Safe Node.
</t>
<t hangText="?-S:"> A node N is deemed dependent on a node S or S-dependent
(denoted as ?-S) if S is the last single point of failure along N's shortest
path to Omega.
</t>
</list>
</t>
</section>
<section anchor="Models" title="ARC Set representations">
<t>
An ARC Set can be represented in a number of fashions:
<vspace blankLines="100" />
<list style="hanging">
<t hangText="Graph View:">
<figure anchor="grv" title="Routing Graph View">
<artwork>
<![CDATA[
H2<==>H<==>H1<---I--->J1<==>J--->K1<===>K
| | | | |
| | | | |
V V V V V
D1<==>D<==>D3 E1<==>E F1<==>F<==>F2 G
| | | | | | / \
| | | | | | / \
V V V V V V V V
B1<==>B2<==>B3<==>B--->A<==>A1<------C2<==>C<==>C4
| | | |
| | | |
| V V |
+--------------------> Omega <-------------------+
]]>
</artwork>
</figure>
This representation is similar to a classical routing graph
with the pecularity that some Links are marked reversible. An ARC is represented as a
sequence of reversible links. The node that holds the cursor is also indicated somehow.
<vspace blankLines="100" />
</t>
<t hangText="ARC View:">
<figure anchor="ARCRep" title="ARC Representation">
<artwork>
<![CDATA[
+========I========+
| |
| +====J====+
| | |
+====H====+ | +=====K=====+
| | | | |
+====D====+ +====E====+ +====F====+ +====G====+
| | | | | | | |
+=========B=========+ | | +=========C=========+
| | | | | |
| +======A=======+ |
| | | |
------------------------------------------------------------------Omega
]]>
</artwork>
</figure>
This representation is similar to a classical routing graph
with the pecularity that some Links are marked reversible. An ARC is represented as a
sequence of reversible links.
<vspace blankLines="100" />
</t>
<t hangText="Collapsed DAG view:" >
<figure anchor="ARCDAG" title="ARC DAG">
<artwork>
<![CDATA[
+====+ +====+ +====+ +====+
| H | <--- | I | ---> | J | ---> | K |
| \__ | ___/ |
| \ | / |
V _| V |_ V
+====+ +====+ +====+ +====+
| D | | E | | F | <--- | G |
\ \ __/ \__ __/ \__ / /
\ \ / \ / \ / /
_| _| |_ _| |_ _| |_ |_
+====+ +====+ +====+
| B | ---> | A | <--- | C |
| | | |
V V V V
------------------------------------------------------------------Omega
]]>
</artwork>
</figure>
A DAG representation whereby an ARC is abstracted as a vertice
and links between ARCs are shown as directed edges. This way, the reversible links are
omitted and the graph is simplified. It can be noted that even the vertice closest to
Omega has 2 non-congruent forwarding solutions, that is Heir Links to Omega.
<vspace blankLines="100" />
</t>
</list>
</t>
</section>
<section title="Applicability">
<t>This section has to be refined. ARCs probbaly apply to both unicast and multicast
and the authors expect further documents to explain how that is done. The examples below are
provided as an indication but is not limiting the field of applications.
</t>
<section title="Load Balancing">
<t>In normal conditions, only the cursor may distribute its traffic between the two Edge Nodes.
If an Edge Node is still congested after the cursor forwards all its traffic towards the other
Edge Node, then the cursor can be moved towards the congested Edge in order to derive even more
traffic towards the other Edge.
If both Edges are congested, then a backpressure can be applied on the incoming ARCs
so that they move their own traffic towards their own alternate Edge. The process may recurse.
</t>
<section title="Routing Hierarchies">
<t>
The ARC methods may be used to build and/or leverage routing hierarchies,
allowing high availability at multiple hierarchical levels.
In one hand, the view of an ARC Set can be simplified by abstracting an ARC as
a node in a DAG. The view of the routing topology is thus simplified, as illustrated in
<xref target="ARCDAG"/>.
In the other hand, ARCs may be used inside a subtopology, such as a ring,
to enable forwarding inside a ring towards a next ring.
Then, abstracting a full ring as a node, ARCs can be applied to a graph of rings,
providing another level of redundancy and an abstract end to end path computation
that is represented as a cascade of ARCs of rings.
</t>
</section>
</section>
</section>
<section title="Lowest ARC First">
<t>The open Lowest ARC First(oLAF) algorithm is presented below in such a way
as to help the reader figure how an ARC Set can be obtained but not in a
computer-optimized fashion that is left to be determined.
oLAF is based on Dijkstra's algorithm for Shortest Path First (SPF) computation,
and is designed in such a fashion that the reverse SPF tree towards a destination
is conserved and preferred for forwarding along the resulting ARC Set.
</t>
<t>
We make the computation on behalf of Omega, that is an abstraction, but could
represent the node or the set of nodes that we want to reach with an ARC Set.
If Omega is instantiated as an actual destination node, then that node may be
a fine location for an ARC Computing Engine.
</t>
<section title="Init">
<t>
So we start with an proverbial Initial Set of Nodes that are interconnected by Links,
and Omega that is the destination that we want to reach with an ARC Set.
</t>
<t>If there is no Heir, we're done. If there is a single Heir then the graph is monoconnected,
so we restart the computation taking that Heir off the Set of Nodes and making it Omega.
</t>
<t>
Else, if Omega is a single Node, or if Omega is composed of multiple nodes but we are willing to
accept that both ends of an ARC terminate in a same node in Omega, then we create virtual Omega
nodes, a minimum of two and at most one per Heir, and we make them the new Omega.
Note: we need at least two destinations because both ends of an ARC cannot terminate in a same node.
</t>
<t>Now we can start building an ARC Set towards the resulting Omega.
</t>
<t>
In this process, we create so-called Dependent Sets of nodes, each owned by a Safe Node S, DSet(S).
DSet(S) contains nodes that are not determined to be Safe at the current stage of the computation
and for which S, the owner Safe Node, is the last single point of failure on the shortest path tree
to Omega. It results that a given node can be at most in one DSet, and that a Safe Node belongs to
its own DSet.
</t>
<t>
For each node S in Omega we create a DSet(S) in which we place S.
</t>
</section>
<section anchor="gt" title="Growing Trees">
<t>
And then the process goes like this:
</t>
<t>
We select the node in the Set of Nodes that is closest to Omega using the cost towards Omega
as if we were building a traditional reverse SPF tree and we place the selected node in the
same Dependent Set as its parent in the reverse SPF tree. Note that for a Heir, the parent
might be a real node in Omega, or a virtual Omega node.
</t>
<t>
If we kept it at that, we would be building subtrees that are hanging off a Safe Node and
together would represent the reverse shortest path tree towards Omega, each subtree
being grown separately inside DSet(S) where S is the (virtual) Safe node that is the root
of the subtree.
</t>
</section>
<section title="Being Safe">
<t>
But once we have placed the selected node in a DSet, we consider its neighbors one by one.
If at least one of the neighbors is already in a different DSet than this node,
we select the neighbor that provides the shortest alternate path to Omega
for the selected node.
</t>
<t> Doing so, we have isolated two paths:
<list style="symbols">
<t>
one along its own shortest path that is contained within its own Dependent Set and
that leads to the owner Safe Node of this set.
</t>
<t> and one via the selected neighbor, along its own shortest path within the selected neighbor's
Dependent Set and that leads to the owner Safe Node of that other set.
</t>
</list>
Because the two sets are different and have no intersection, these paths are non-congruent.
And because the two non-congruent paths lead to two different Safe Nodes, this node is Safe.
</t>
<t>
It might happen that:
<list style="symbols">
<t> the selected node's parent is already a Safe Node, in which case
the selected node is the Edge AN on its shortest path side.
</t>
<t>
It might also happen that the selected neighbor is already a Safe Node, in which case
selected node is the Edge AN on its alternate side.
</t>
</list>
If both conditions are met for a same AN, then that AN forms a collapsed ARC by itself.
</t>
</section>
<section title="Bending An ARC">
<t>
Now we form an ARC as follows:
<list style="symbols">
<t>A height is attributed to this ARC that must be strictly more than that of
the ARCs it terminates into, if any. The order in which the ARCs are built may be used
in some cases.
</t>
<t>
The ARC terminates in the two Safe Nodes that are the owners of the two DSets.
The normal behaviour is to make a Edge Link the link to the Safe Node.
</t>
<t>
If the Safe Node at one end forms a collapsed ARC by itself, it may be absorbed in the ARC
in order to build a multi-edged ARC.
</t>
<t>If one of the two Safe Nodes pertains in a ARC or a Comb construct that is higher than the other end,
then this ARC may be merged at the Safe Node with its original ARC, in order to form a Comb construct
whereby this ARC is a Buttressing ARC of the Comb.
The resulting Comb conserves the height on the original ARC or Comb that it extends.
</t>
<t>
The ARC is built by adjoining the two non-congruent paths that we isolated for the selected node.
</t>
<t>
The selected node is the node farthest from Omega in the resulting ARC, so we make it the cursor.
</t>
<t>
The link between the selected node and the selected neighbor would not have been used in a classical
reverse SPF tree. Here, we have determined that this link is in fact critical to connect 2 zones of
the network (the DSets) that can act as a back up for one another in case of the failure of
their respective single points of failure (the Safe Nodes).
</t>
<t>Because the ARC can be used in both directions, each AN along the ARC
has two non-congruent paths to the Safe Nodes that the ARC terminates into.
So it is a Safe Node.
We create individual DSets for each AN and we move the AN to its own DSet.
</t>
</list>
</t>
</section>
<section title="Orienting Links">
<t>
For each ARC Node along the ARC:
<list style="symbols">
<t>
any link (there can be zero for a collapsed ARC, one for an Edge AN or two of them
for a Intermediate AN) between this AN and a next AN along this ARC is made an
Intermediate Link, that is, reversible. The normal direction, away from the cursor,
preserves the shortest path.
</t>
<t>
If this AN is an Edge AN for this ARC, than all links off this node that terminate
in a Safe Node are made Edge Links, that is, outgoing but not reversible.
</t>
<t>All the other links left undertermined.
</t>
</list>
</t>
<t>
The nodes left in the Dependent Sets but the owner Safe Node are still not Safe.
They are moved back to the original Set of Nodes to enable forming additional ARCs
which might depend on this ARC in the ARC Set.
</t>
</section>
<section title="Looping or recursing">
<t>
We are done processing the particular node we had picked in the original Set of Nodes.
If the Set of Nodes as it stands now is not empty, we continue from <xref target="gt"/>.
</t>
<t>
If the Set of Nodes went empty, we are done with this pass and we consider the Dependent
Sets that we have put together. In a biconnected graph, there should be one set per node
and one node per set, denoting that every node is a Safe Node.
</t>
<t>
If some portion of the graph is monoconnected, then each monoconnected portion forms
the Dependent Set of the Safe Node that is its single point of
failure. In order to be maximally redundant, we need to form the
ARCs again, within the Dependent Set.
</t>
<t>
To do so, we remove the Safe Node from the Dependent set and make it Omega.
We make the resulting DSet our Set of Nodes and run the algorithm again.
</t>
<t>
This may recurse a number of times if the graph has monoconnected
zones within others.
</t>
</section>
</section>
<section title="Forwarding Along An ARC Set">
<t>Under normal conditions, the traffic flows away from the cursor
of the current ARC and cascades into the next ARC on that side of the cursor,
with the Height of the current ARC decreasing monotonically from ARC
to ARC till Omega is reached.
</t>
<t>
The same goes for a generic Comb construct.
When Buttressing ARCs are applied on a main ARC or other Buttressing ARCs,
the final construct assumes the shape of a tree.
The tree may be walked in different manners but the shortest path requires
to start going down the current ARC or Buttressing ARC to its Edge.
</t>
<t>
In case of Label forwarding, the same recursivity is applied and a multiple ARC
label path is constructed. Each ARC has is own set of label path per Omega, each
ARC Set label path being merged into the lower ARC label set, thus at the
interconnection point. At minimum, ARC label path should be built from the
cursor toward each edge, but this would require label path recompilation upon
cursor move, the proposed approach is then to build for the normal flow to an
Omega one pair of label path from edge to edge.
</t>
<t>
As this label construct maps the ARC topology with local significant label,
the Label Distribution Protocol (LDP) could be reused to announce label association
to neighbors on the ARC.
</t>
<t>
Upon a breakage inside an ARC, until a corrective action takes place,
some traffic will be lost. The corrective action might be either
operated at the control plane or the data plane, if immediate action
and near-zero packet loss is required.
</t>
<section title="Control Plane Recovery">
<t>Upon a first breakage in an ARC, the cursor is moved to the breakage
point, either a node or a link, so that traffic flows away from the cursor
again.
</t>
<t>Upon a second breakage within a same ARC, a segment of the ARC is
now isolated. Both breakage points become sinks till an additional
corrective action, such as modifying the ARC Set, takes place.
All incoming links in the isolated segment are blocked ,
causing the traffic to exit at the other end of the incoming ARCs.
</t>
<t>
Blocking an Edge Link in the incoming ARC may create an isolated
segment in the incoming ARC as well if it is a second breakage there
too, or if both edges of the incoming ARC tterminate in the broken
segment. In that case the process recurses and the broken zone can
be determined as the collection of the isolated segments.
</t>
<t>If a segment of an ARC is getting isolated by a dual failure but
that ARC segment has incoming Edges then the ARC can be reversed.
This reversal is done by reversing of all the incoming Edges, which
become outgoing. The segment that was isolated now benefits from
multiple exits in a loop free fashion. This process might in turn
isolate a segment of an ARC that was incoming and the process recurses
and some links flap. If a real exit exits the process will stabilize,
but a count to infinity must be put in place to avoid a permanent
flapping when a whole ARC Subset is physically isolated. One
may consider that this process is in fact the classical link reversal
technique, as applied to the DAG of ARCs.</t>
</section>
<section title="Data Plane Recovery">
<t>Upon a breakage inside an ARC, it is possible in the data plane
to reverse the direction of -to turn- a given packet once along
the ARC so the packets exits over the other Edge Link.
But in order to avoid loops, it is undesirable to reverse the
direction of a given packet a second time.
</t>
<t>Note that once a given packet leaves an ARC to enter the next, it
is free to bounce again in the next ARC. In other Words, the domain
that is impacted by a turn is limited to the current ARC itself;
the ARC forms the event horizon wherein the notion that a turn
happened may cause a loop.
</t>
<t>So a local strategy must be put in place inside an ARC to allow
a given packet to bounce once upon a breakage, and get dropped upon
a second breakage.
</t>
<t>
In the case of IP packet forwarding, a packet can be tagged when it
bounces inside an ARC, or when it passes the cursor, for instance by
reserving a TOS bit for that purpose. When the packet bounces, the
bit is set and when the packet leaves the ARC, the bit is reset and
may be used again in the next ARC. In the generic case of a Comb,
a strategy must be put in place to walk the structure and drop
a packet that tries all the Edges.
it attempts to pass the cursor twice in a same direction, meaning
that more than a full walk was already accomplished.
</t>
<t>
In the case of MPLS forwarding, the same result can be achieved with either
3 or 4 Labels Switched Paths (LSPs) along the ARC.
<list style="hanging">
<t hangText="3-Labels method:">
In this case we lay a primary LSP from the cursoo to the Edge in each direction,
and a backup LSP Edge to Edge in each direction. So a node along the way has
three labels, one primary and two backup, one in each direction. Should the
primary path fail, the packet can be placed along the backup LSP in the other direction.
We'll note that this method contrains the location of the cursor.
Should the cursor move, The primary LSPs have to be recomputed, at a minimum between
the old and the new location of the cursor where the direction is reversed.
</t>
<t hangText="4-Labels method:">In this case we have two primary and two backup
LSPs Edge to Edge in each direction. The labels are independent of the location of the
cursor, so the cursor can be moved in control plane with no impact on labels.
</t>
</list>
</t>
</section>
</section>
<!--
<section title="Topological considerations">
<section title="Looplessness">
</section>
<section title="Shortest path">
</section>
<section title="Spanning">
</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 Dirk Anteunis, Stewart Bryant, IJsbrand Wijnands, George Swallow,
Eric Osborne, Clarence Filsfils and Eric Levy-Abegnoli for their participation and continuous
support to the work presented here.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.4291"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4541"?>
<?rfc include="reference.RFC.5865"?>
<?rfc include="reference.RFC.5213"?>
<?rfc include="reference.RFC.5415"?>
<?rfc include="reference.RFC.5921"?>
<?rfc include="reference.RFC.6275"?>
<?rfc include="reference.RFC.6550"?>
<?rfc include='reference.I-D.thubert-lowpan-backbone-router.xml'?>
<?rfc include='reference.I-D.phinney-roll-rpl-industrial-applicability.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:49:56 |