One document matched: draft-enyedi-rtgwg-mrt-local-detour-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml">
<!ENTITY I-D.enyedi-rtgwg-mrt-frr-algorithm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.enyedi-rtgwg-mrt-frr-algorithm.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-enyedi-rtgwg-mrt-local-detour-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Artificial MRT Islands for Keeping Detours Local</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Gábor Sándor Enyedi" initials="G." surname="Enyedi" role="editor">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kalman krt 11</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>Gabor.Sandor.Enyedi@ericsson.com</email>
</address>
</author>
<date month="October" day="21" year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPFRR, MRT-FRR</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>IP and LDP Fast ReRoute using Maximally Redundant trees was defined in <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. In this document we add a simple extension to that technique, which can guarantee to keep detours in the part of the network, where the failure happened.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In the case of failure, Fast ReRoute using Maximally Redundant Trees (MRT-FRR) <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> use detours defined by two maximally redundant trees, which are not related to shortest paths at all. Although there are heuristics for decreasing path lengths, which are sufficient in almost all situations, there is no strict guarantee to keep failure handling local. This means that detours may cause temporal congestion even in those parts of the network, which are far from the original failure.</t>
<t>This document defines a possible solution by using multiple pairs of maximally redundant trees in an IGP area. Our solution introduce artificial "subareas", each having its own recovery, and use them to provide the best possible protection. If both the Point of Local Repair (PLR) and the destination are in the same subarea, the detour can simply use one of the trees of that subarea, in this way never leaving the surroundings of the failure.</t>
</section>
<section title="Terminology and Definitions">
<t><list style="hanging">
<t hangText="Maximally Redundant Trees (MRT): ">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-node. Any shared links
are cut-links.</t>
<t hangText="2-connected: ">A graph that has no cut-nodes.
This is a graph that requires at least two nodes to be removed before gets partitioned.</t>
<t hangText="block: ">Either a maximally 2-connected (induced) subgraph, a cut-link with with its endpoints, or an isolated node.</t>
<t hangText="DAG: ">Directed Acyclic Graph - a digraph containing
no directed cycle.</t>
<t hangText="ADAG: ">Almost Directed Acyclic Graph - a digraph
that can be transformed into a DAG whith removing a single node
(the root node).</t>
<t hangText="GADAG: ">Generalized ADAG - a digraph, which has only
ADAGs as all of its blocks.</t>
<t hangText="PLR: ">Point of Local Repair - the node neighboring the
failed resource (which can be a node or a link), and which do the
rerouting.</t>
<t hangText="Cut-node: ">A node is a cut-node, if removing it partitions the network.</t>
<t hangText="Cut-link: ">A link is a cut-link, if removing it partitions the network.</t>
</list></t>
</section>
<section title="Problem Description">
<t>Consider the network and GADAG depicted in <xref target="fig_network"/> (for GADAG computation and finding FRR paths using a GADAG consult <xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>). Suppose that node H wants to send some packets to node I, but the link between them went down. Since node H is definitely lesser than node I, the detour must be the one that goes through R, i.e. H->G->C->B->A->R->F->E->J->I, even if there was a much shorter one through node D. The problem here is not that such path is long, but that the traffic may get far away from the failure, thus congestion may occur in any part of the network.</t>
<figure align="center" anchor="fig_network">
<artwork align="left"><![CDATA[
----F J---- ----F J<---
| | | | | ^ | |
| | | | V | | |
R --E-- I R --E<-- I
| | | | ^ ^
| | | | | |
| D | | D |
| | | | ^ |
| | | V | |
A --C-- H A ->C-- H
| | | | | | | ^
| | | | | | V |
----B G---- --->B G-----
A network The GADAG rooted at R
]]></artwork>
<postamble>Network with GADAG rooted at R.</postamble>
</figure>
<t>There are already possibilities to mitigate the problem presented above. First, there are heuristics that can be applied in order to decrease path lengths, thus paths in real networks are usually using detours not much longer than the shortest paths. Even when heuristics cannot help (like in the network above), there is still some room for optimization by selecting the GADAG root better. E.g. in the previous example selecting node D as a GADAG root can solve the problem (however it cannot solve anything if we add one more ring connected to A and R). Finally, note that congestion can be caused only while IGP is doing the recovery, which is quite fast in most of the cases, in this way reducing the severity of this situation.</t>
<t>This document describes a mechanism to give strict guarantees that detour does not get far from the failure. This can be applied for special situations, when detours would be too long otherwise or in networks, where bandwidth guarantees are needed to be fulfilled in all cases.</t>
</section>
<section title="Artificial Islands">
<t>MRT-FRR capable routers can handle multiple MRT profiles. MRT profiles was introduced for handling routers with different capabilities, even those, which do not support MRT-FRR at all. Routers supporting the same profile create an MRT-FRR island in the IGP area.</t>
<t>Each such island has its GADAG and its own redundant trees, which are only valid in that island. If a packet gets out from an island, it gets back to the shortest path. If the destination (or the area/AS border router) is inside the island where the failure happened, it is guaranteed that packet will never leave the island. Basically islands are subareas with their own protection.</t>
<t>Currently, islands are there only for handling capability differences between routers. In this document, we introduce artificial islands, which are limiting packet detours to a part of the network. In order to define such an island, operator needs only to configure routers in the desired subarea to advertise one more profile, which is is not supported by any other router in the network. Naturally, this profile does not need to describe new capabilities, but it can differ from other profiles just in some extra ID field. Therefore profile descriptor must be extended with such ID field.</t>
<t>Operators may define islands arbitrary; the only restriction is that such islands must be connected, otherwise they would be considered as multiple connected islands. Similarly, if an island is split into disjunct parts due to some failure, such parts can be handled as disjunct islands. As an example, operators can define one island containing the whole IGP area, and some smaller ones for keeping up local failure handled when needed. When a failure can be handled locally, a "small" island is used, while there is still the "big" island containing the whole area for the remaining cases.</t>
<t>As an example of this scheme, consider the the previous network, and define artificial islands in it in order to keep packets inside the ring where the failure has happened. The network and the two islands defined are depicted below. Note that there should be a third island that contains all the nodes to handle failures that cannot be handled locally; this third island is not depicted in <xref target="fig_simp_islands"/>. Also note that having this third island is not mandatory, it can be not configured, if operator wants to disable global protection for some reason.</t>
<figure align="center" anchor="fig_simp_islands">
<artwork align="left"><![CDATA[
************ ************
* * * *
* ----F * * J---- *
* | | * | | *
* | | * * | | *
* R -------E------- I *
* | * | * | *
* | * | * | *
* | * D * | *
* | * | * | *
* | * | * | *
* A -------C------- H *
* | | * * | | *
* | | * | | *
* ----B * * G---- *
* * * *
* Island1 * * Island2 *
* * * *
************* *************
]]></artwork>
<postamble>A network made up by two islands</postamble>
</figure>
<t>Observe that Island1 and Island2 are not disjunct, instead both of them are containing node C, D and E, in this way making both islands 2-connected. This overlapping is the main difference compared to the situation when an area is split into two using MRT-ineligible links; if we would only disable the MRT capability for some links in this network, at least one of the resulting "subareas" (islands) would be not 2-connected, thus protection would be impossible in at least one of them. Moreover thanks to overlapping, it is possible to define the third island and use it to provide protection when the PLR and the destination are not in the same ring (i.e. there is no local detour).</t>
<t>Although it is useful for protection, note that operator do not always need to find 2-connected artificial islands, if there are considerations other than maximum protection. Consider <xref target="fig_ext_islands"/> and suppose that in this network link L-F is not wanted to be used for local protection for some reason. In this case, the two artificial islands for local protection are selected as depicted below. If node M is going down, Island2 is split into two, so no local protection is possible in this case. (Naturally, selecting Island2 is not pointless, if any link or any other node than M is going down, there is still local protection.)</t>
<figure align="center" anchor="fig_ext_islands">
<artwork align="left"><![CDATA[
************
--------------L--K *
| * | / *
*******|**** * M *
* | * * | *
* ----F * * J---- *
* | | * | | *
* | | * * | | *
* R -------E------- I *
* | * | * | *
* | * | * | *
* | * D * | *
* | * | * | *
* | * | * | *
* A -------C------- H *
* | | * * | | *
* | | * | | *
* ----B * * G---- *
* * * *
* Island1 * * Island2 *
* * * *
************* *************
]]></artwork>
<postamble>A network made up by two islands and a cut-node</postamble>
</figure>
<t>If a router is in multiple islands, selecting one for a concrete failure case is a local decision of the node and not defined in this document. Vendors may make it possible to assign priority at each router for the artificial islands created. Moreover, routers may take other differences into consideration as well, e.g. if there is node protecting path in one island but only link protecting in another one.</t>
<t>Selecting the endpoint of detour is a local decision of MRT-FRR capable routers, it is not needed to select always the destination/border router as the endpoint, especially when not all the routers are supporting MRT-FRR and islands are formed (for details see <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>). If there are artificial islands the only difference is that a router may belong to multiple islands, so it may take into consideration all of those islands and select the best for that failure with respect to arbitrary local preference.</t>
<t>For MRT-FRR, each router must have two extra addresses/labels per profile it supports. The situation is the same if there are artificial islands applied, since a router in multiple islands must compute the MRTs for each of those islands, and it must be able to decide which of these trees is used.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This architecture is not currently believed to introduce new security concerns.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&I-D.ietf-rtgwg-mrt-frr-architecture;
&I-D.enyedi-rtgwg-mrt-frr-algorithm;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
</references>
<!-- Change Log
v00 2013-10-10 EGS Initial version
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 15:56:10 |