One document matched: draft-ietf-rtgwg-ipfrr-framework-08.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 BASE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-spec-base.xml">
<!ENTITY ALT-SP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tian-frr-alt-shortest-path.xml">
<!ENTITY BFD SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-base.xml">
<!ENTITY MPLSFRR SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY MICROLOOP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-lf-conv-frmwk.xml">
<!ENTITY NOTVIA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-notvia-addresses.xml">
<!ENTITY TUNNELS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryant-ipfrr-tunnels.xml">
<!ENTITY U-TURNS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-ip-local-protect-uturn.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="info" docName="draft-ietf-rtgwg-ipfrr-framework-08.txt"
ipr="full3978" updates="">
<!-- 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>IP Fast Reroute Framework</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Mike Shand" initials="M." surname="Shand">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Avenue.</street>
<!-- Reorder these if your country does things differently -->
<city>Reading</city>
<region>Berks</region>
<code>RG2 6GB</code>
<country>UK</country>
</postal>
<email>mshand@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Avenue.</street>
<city>Reading</city>
<region>Berks</region>
<code>RG2 6GB</code>
<country>UK</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<date year="2008" />
<!-- 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 -->
<!-- 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. -->
<!-- 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>This document provides a framework for the development of IP
fast-reroute mechanisms which provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS
Fast-reroute, the mechanisms are applicable to a network employing
conventional IP routing and forwarding. An essential part of such
mechanisms is the prevention of packet loss caused by the loops which
normally occur during the re-convergence of the network following a
failure.</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>This section defines words and acronyms used in this draft and other
drafts discussing IP Fast-reroute.</t>
<t><list hangIndent="20" style="hanging">
<t hangText="D">Used to denote the destination router under
discussion.</t>
<t hangText="Distance_opt(A,B)">The distance of the shortest path
from A to B.</t>
<t hangText="Downstream Path">This is a subset of the loop-free
alternates where the neighbor N meet the following condition:-
<vspace blankLines="1" />Distance_opt(N, D) <
Distance_opt(S,D)</t>
<t hangText="E">Used to denote the router which is the primary
next-hop neighbor to get from S to the destination D. Where there is
an ECMP set for the shortest path from S to D, these are referred to
as E_1, E_2, etc.</t>
<t hangText="ECMP">Equal cost multi-path: Where, for a particular
destination D, multiple primary next-hops are used to forward
traffic because there exist multiple shortest paths from S via
different output layer-3 interfaces.</t>
<t hangText="FIB">Forwarding Information Base. The database used by
the packet forwarder to determine what actions to perform on a
packet.</t>
<t hangText="IPFRR">IP fast-reroute.</t>
<t hangText="Link(A->B)">A link connecting router A to router
B.</t>
<t hangText="LFA">Loop Free Alternate. This is a neighbor N, that is
not a primary next-hop neighbor E, whose shortest path to the
destination D does not go back through the router S. The neighbor N
must meet the following condition:- <vspace
blankLines="1" />Distance_opt(N, D) < Distance_opt(N, S) +
Distance_opt(S, D)</t>
<t hangText="Loop Free Neighbor">A neighbor N_i, which is not the
particular primary neighbor E_k under discussion, and whose shortest
path to D does not traverse S. For example, if there are two primary
neighbors E_1 and E_2, E_1 is a loop-free neighbor with regard to
E_2 and vice versa.</t>
<t hangText="Loop Free Link Protecting Alternate"><vspace
blankLines="0" />This is a path via a Loop-Free Neighbor N_i which
does not go through the particular link of S which is being
protected to reach the destination D.</t>
<t hangText="Loop Free Node-protecting Alternate"><vspace
blankLines="0" />This is a path via a Loop-Free Neighbor N_i which
does not go through the particular primary neighbor of S which is
being protected to reach the destination D.</t>
<t hangText="N_i">The ith neighbor of S.</t>
<t hangText="Primary Neighbor">A neighbor N_i of S which is one of
the next hops for destination D in S's FIB prior to any failure.</t>
<t hangText="R_i_j">The jth neighbor of N_i.</t>
<t hangText="Routing Transition">The process whereby routers
converge on a new topology. In conventional networks this process
frequently causes some disruption to packet delivery.</t>
<t hangText="RPF">Reverse Path Forwarding. I.e. checking that a
packet is received over the interface which would be used to send
packets addressed to the source address of the packet.</t>
<t hangText="S">Used to denote a router that is the source of a
repair that is computed in anticipation of the failure of a
neighboring router denoted as E, or of the link between S and E. It
is the viewpoint from which IP Fast-Reroute is described.</t>
<t hangText="S_i">The set of neighbors of E, in addition to S, which
will independently take the role of S for the traffic they
carry.</t>
<t hangText="SPF">Shortest Path First, e.g. Dijkstra's
algorithm.</t>
<t hangText="SPT">Shortest path tree</t>
<t hangText="Upstream Forwarding Loop"><vspace blankLines="0" />This
is a forwarding loop which involves a set of routers, none of which
are directly connected to the link which has caused the topology
change that triggered a new SPF in any of the routers.</t>
</list></t>
</section>
<section title="Introduction">
<t>When a link or node failure occurs in a routed network, there is
inevitably a period of disruption to the delivery of traffic until the
network re-converges on the new topology. Packets for destinations which
were previously reached by traversing the failed component may be
dropped or may suffer looping. Traditionally such disruptions have
lasted for periods of at least several seconds, and most applications
have been constructed to tolerate such a quality of service.</t>
<t>Recent advances in routers have reduced this interval to under a
second for carefully configured networks using link state IGPs. However,
new Internet services are emerging which may be sensitive to periods of
traffic loss which are orders of magnitude shorter than this.</t>
<t>Addressing these issues is difficult because the distributed nature
of the network imposes an intrinsic limit on the minimum convergence
time which can be achieved.</t>
<t>However, there is an alternative approach, which is to compute backup
routes that allow the failure to be repaired locally by the router(s)
detecting the failure without the immediate need to inform other routers
of the failure. In this case, the disruption time can be limited to the
small time taken to detect the adjacent failure and invoke the backup
routes. This is analogous to the technique employed by MPLS Fast-Reroute
<xref target="RFC4090"></xref>, but the mechanisms employed for the
backup routes in pure IP networks are necessarily very different.</t>
<t>This document provides a framework for the development of this
approach.</t>
</section>
<section title="Problem Analysis">
<t>The duration of the packet delivery disruption caused by a
conventional routing transition is determined by a number of factors:
<list style="numbers">
<t>The time taken to detect the failure. This may be of the order of
a few mS when it can be detected at the physical layer, up to
several tens of seconds when a routing protocol hello is employed.
During this period packets will be unavoidably lost.</t>
<t>The time taken for the local router to react to the failure. This
will typically involve generating and flooding new routing updates,
perhaps after some hold-down delay, and re-computing the router's
FIB.</t>
<t>The time taken to pass the information about the failure to other
routers in the network. In the absence of routing protocol packet
loss, this is typically between 10mS and 100mS per hop.</t>
<t>The time taken to re-compute the forwarding tables. This is
typically a few mS for a link state protocol using Dijkstra's
algorithm.</t>
<t>The time taken to load the revised forwarding tables into the
forwarding hardware. This time is very implementation dependant and
also depends on the number of prefixes affected by the failure, but
may be several hundred mS.</t>
</list>The disruption will last until the routers adjacent to the
failure have completed steps 1 and 2, and then all the routers in the
network whose paths are affected by the failure have completed the
remaining steps.</t>
<t>The initial packet loss is caused by the router(s) adjacent to the
failure continuing to attempt to transmit packets across the failure
until it is detected. This loss is unavoidable, but the detection time
can be reduced to a few tens of mS as described in <xref
target="fast-failure-detect"></xref>.</t>
<t>Subsequent packet loss is caused by the "micro-loops" which form
because of temporary inconsistencies between routers' forwarding tables.
These occur as a result of the different times at which routers update
their forwarding tables to reflect the failure. These variable delays
are caused by steps 3, 4 and 5 above and in many routers it is step 5
which is both the largest factor and which has the greatest variance
between routers. The large variance arises from implementation
differences and from the differing impact that a failure has on each
individual router. For example, the number of prefixes affected by the
failure may vary dramatically from one router to another.</t>
<t>In order to achieve packet disruption times which are commensurate
with the failure detection times it is necessary to perform two distinct
tasks:</t>
<t><list style="numbers">
<t>Provide a mechanism for the router(s) adjacent to the failure to
rapidly invoke a repair path, which is unaffected by any subsequent
re-convergence.</t>
<t>Provide a mechanism to prevent the effects of micro-loops during
subsequent re-convergence.</t>
</list></t>
<t></t>
<t>Performing the first task without the second will result in the
repair path being starved of traffic and hence being redundant.
Performing the second without the first will result in traffic being
discarded by the router(s) adjacent to the failure. Both tasks are
necessary for an effective solution to the problem.</t>
<t>However, repair paths can be used in isolation where the failure is
short-lived. The repair paths can be kept in place until the failure is
repaired and there is no need to advertise the failure to other
routers.</t>
<t>Similarly, micro-loop avoidance can be used in isolation to prevent
loops arising from pre-planned management action, because the link or
node being shut down can remain in service for a short time after its
removal has been announced into the network, and hence it can function
as its own "repair path".</t>
<t>Note that micro-loops can also occur when a link or node is restored
to service and thus a micro-loop avoidance mechanism is required for
both link up and link down cases.</t>
</section>
<section title="Mechanisms for IP Fast-reroute ">
<t>The set of mechanisms required for an effective solution to the
problem can be broken down into the following sub-problems.</t>
<section anchor="fast-failure-detect"
title="Mechanisms for fast failure detection ">
<t>It is critical that the failure detection time is minimized. A
number of approaches are possible, such as: <list style="numbers">
<t>Physical detection; for example, loss of light.</t>
<t>Routing protocol independent protocol detection; for example,
The Bidirectional Failure Detection protocol <xref
target="I-D.ietf-bfd-base"></xref>.</t>
<t>Routing protocol detection; for example, use of "fast
hellos".</t>
</list></t>
</section>
<section title="Mechanisms for repair paths">
<t>Once a failure has been detected by one of the above mechanisms,
traffic which previously traversed the failure is transmitted over one
or more repair paths. The design of the repair paths should be such
that they can be pre-calculated in anticipation of each local failure
and made available for invocation with minimal delay. There are three
basic categories of repair paths:</t>
<t><list style="numbers">
<t>Equal cost multi-paths (ECMP). Where such paths exist, and one
or more of the alternate paths do not traverse the failure, they
may trivially be used as repair paths.</t>
<t>Loop free alternate paths. Such a path exists when a direct
neighbor of the router adjacent to the failure has a path to the
destination which can be guaranteed not to traverse the
failure.</t>
<t>Multi-hop repair paths. When there is no feasible loop free
alternate path it may still be possible to locate a router, which
is more than one hop away from the router adjacent to the failure,
from which traffic will be forwarded to the destination without
traversing the failure.</t>
</list></t>
<t>ECMP and loop free alternate paths (as described in <xref
target="I-D.ietf-rtgwg-ipfrr-spec-base"></xref>) offer the simplest
repair paths and would normally be used when they are available. It is
anticipated that around 80% of failures (see <xref
target="coverage"></xref>) can be repaired using these basic methods
alone.</t>
<t>Multi-hop repair paths are more complex, both in the computations
required to determine their existence, and in the mechanisms required
to invoke them. They can be further classified as:<list
style="numbers">
<t>Mechanisms where one or more alternate FIBs are pre-computed in
all routers and the repaired packet is instructed to be forwarded
using a "repair FIB" by some method of per packet signaling such
as detecting a "U-turn" <xref
target="I-D.atlas-ip-local-protect-uturn"></xref> , <xref
target="FIFR"></xref> or by marking the packet <xref
target="SIMULA"></xref>.</t>
<t>Mechanisms functionally equivalent to a loose source route
which is invoked using the normal FIB. These include tunnels <xref
target="I-D.bryant-ipfrr-tunnels"></xref>, alternative shortest
paths <xref target="I-D.tian-frr-alt-shortest-path"></xref> and
label based mechanisms.</t>
<t>Mechanisms employing special addresses or labels which are
installed in the FIBs of all routers with routes pre-computed to
avoid certain components of the network. For example <xref
target="I-D.ietf-rtgwg-ipfrr-notvia-addresses"></xref>.</t>
</list>In many cases a repair path which reaches two hops away from
the router detecting the failure will suffice, and it is anticipated
that around 98% of failures (see <xref target="coverage"></xref>) can
be repaired by this method. However, to provide complete repair
coverage some use of longer multi-hop repair paths is generally
necessary.</t>
<section title="Scope of repair paths ">
<t></t>
<t>A particular repair path may be valid for all destinations which
require repair or may only be valid for a subset of destinations. If
a repair path is valid for a node immediately downstream of the
failure, then it will be valid for all destinations previously
reachable by traversing the failure. However, in cases where such a
repair path is difficult to achieve because it requires a high order
multi-hop repair path, it may still be possible to identify lower
order repair paths (possibly even loop free alternate paths) which
allow the majority of destinations to be repaired. When IPFRR is
unable to provide complete repair, it is desirable that the extent
of the repair coverage can be determined and reported via network
management.</t>
<t>There is a tradeoff to be achieved between minimizing the number
of repair paths to be computed, and minimizing the overheads
incurred in using higher order multi-hop repair paths for
destinations for which they are not strictly necessary. However, the
computational cost of determining repair paths on an individual
destination basis can be very high.</t>
<t>It will frequently be the case that the majority of destinations
may be repaired using only the "basic" repair mechanism, leaving a
smaller subset of the destinations to be repaired using one of the
more complex multi-hop methods. Such a hybrid approach may go some
way to resolving the conflict between completeness and
complexity.</t>
<t>The use of repair paths may result in excessive traffic passing
over a link, resulting in congestion discard. This reduces the
effectiveness of IPFRR. Mechanisms to influence the distribution of
repaired traffic to minimize this effect are therefore
desirable.</t>
</section>
<section anchor="coverage" title="Analysis of repair coverage ">
<t>In some cases the repair strategy will permit the repair of all
single link or node failures in the network for all possible
destinations. This can be defined as 100% coverage. However, where
the coverage is less than 100% it is important for the purposes of
comparisons between different proposed repair strategies to define
what is meant by such a percentage. There are four possibilities:
<list style="numbers">
<t>The percentage of links (or nodes) which can be fully
protected for all destinations. This is appropriate where the
requirement is to protect all traffic, but some percentage of
the possible failures may be identified as being
un-protectable.</t>
<t>The percentage of destinations which can be fully protected
for all link (or node) failures. This is appropriate where the
requirement is to protect against all possible failures, but
some percentage of destinations may be identified as being
un-protectable.</t>
<t>For all destinations (d) and for all failures (f), the
percentage of the total potential failure cases (d*f) which are
protected. This is appropriate where the requirement is an
overall "best effort" protection.</t>
<t>The percentage of packets normally passing though the network
that will continue to reach their destination. This requires a
traffic matrix for the network as part of the analysis.</t>
</list>The coverage obtained is dependent on the repair strategy
and highly dependent on the detailed topology and metrics. Any
figures quoted in this document are for illustrative purposes
only.</t>
</section>
<section title="Link or node repair ">
<t>A repair path may be computed to protect against failure of an
adjacent link, or failure of an adjacent node. In general, link
protection is simpler to achieve. A repair which protects against
node failure will also protect against link failure for all
destinations except those for which the adjacent node is a single
point of failure.</t>
<t>In some cases it may be necessary to distinguish between a link
or node failure in order that the optimal repair strategy is
invoked. Methods for link/node failure determination may be based on
techniques such as BFD<xref target="I-D.ietf-bfd-base"></xref>. This
determination may be made prior to invoking any repairs, but this
will increase the period of packet loss following a failure unless
the determination can be performed as part of the failure detection
mechanism itself. Alternatively, a subsequent determination can be
used to optimise an already invoked default strategy.</t>
</section>
<section title="Maintenance of Repair paths ">
<t></t>
<t>In order to meet the response time goals, it is expected (though
not required) that repair paths, and their associated FIB entries,
will be pre-computed and installed ready for invocation when a
failure is detected. Following invocation the repair paths remain in
effect until they are no longer required. This will normally be when
the routing protocol has re-converged on the new topology taking
into account the failure, and traffic will no longer be using the
repair paths.</t>
<t>The repair paths have the property that they are unaffected by
any topology changes resulting from the failure which caused their
instantiation. Therefore there is no need to re-compute them during
the convergence period. They may be affected by an unrelated
simultaneous topology change, but such events are out of scope of
this work (see <xref target="SRLG"></xref>).</t>
<t>Once the routing protocol has re-converged it is necessary for
all repair paths to take account of the new topology. Various
optimizations may permit the efficient identification of repair
paths which are unaffected by the change, and hence do not require
full re-computation. Since the new repair paths will not be required
until the next failure occurs, the re-computation may be performed
as a background task and be subject to a hold-down, but excessive
delay in completing this operation will increase the risk of a new
failure occurring before the repair paths are in place.</t>
</section>
<section anchor="SRLG"
title="Multiple failures and Shared Risk Link Groups ">
<t></t>
<t>Complete protection against multiple unrelated failures is out of
scope of this work. However, it is important that the occurrence of
a second failure while one failure is undergoing repair should not
result in a level of service which is significantly worse than that
which would have been achieved in the absence of any repair
strategy.</t>
<t>Shared Risk Link Groups are an example of multiple related
failures, and the more complex aspects of their protection is a
matter for further study.</t>
<t>One specific example of an SRLG which is clearly within the scope
of this work is a node failure. This causes the simultaneous failure
of multiple links, but their closely defined topological
relationship makes the problem more tractable.</t>
</section>
</section>
<section title="Local Area Networks ">
<t>Protection against partial or complete failure of LANs is more
complex than the point to point case. In general there is a tradeoff
between the simplicity of the repair and the ability to provide
complete and optimal repair coverage.</t>
</section>
<section title="Mechanisms for micro-loop prevention ">
<t></t>
<t>Control of micro-loops is important not only because they can cause
packet loss in traffic which is affected by the failure, but because
by saturating a link with looping packets they can also cause
congestion loss of traffic flowing over that link which would
otherwise be unaffected by the failure.</t>
<t>A number of solutions to the problem of micro-loop formation have
been proposed and are summarized in <xref
target="I-D.ietf-rtgwg-lf-conv-frmwk"></xref>. The following factors
are significant in their classification:<list style="numbers">
<t>Partial or complete protection against micro-loops.</t>
<t>Delay imposed upon convergence.</t>
<t>Tolerance of multiple failures (from node failures, and in
general).</t>
<t>Computational complexity (pre-computed or real time).</t>
<t>Applicability to scheduled events.</t>
<t>Applicability to link/node reinstatement.</t>
</list></t>
</section>
</section>
<section title="Management Considerations ">
<t>While many of the management requirements will be specific to
particular IPFRR solutions, the following general aspects need to be
addressed: <list style="numbers">
<t>Configuration <list style="letters">
<t>Enabling/disabling IPFRR support.</t>
<t>Enabling/disabling protection on a per link/node basis.</t>
<t>Expressing preferences regarding the links/nodes used for
repair paths.</t>
<t>Configuration of failure detection mechanisms.</t>
<t>Configuration of loop avoidance strategies</t>
</list></t>
<t>Monitoring<list style="letters">
<t>Notification of links/nodes/destinations which cannot be
protected.</t>
<t>Notification of pre-computed repair paths, and anticipated
traffic patterns.</t>
<t>Counts of failure detections, protection invocations and
packets forwarded over repair paths.</t>
</list></t>
</list></t>
</section>
<section title="Scope and applicability ">
<t></t>
<t>The initial scope of this work is in the context of link state IGPs.
Link state protocols provide ubiquitous topology information, which
facilitates the computation of repairs paths.</t>
<t>Provision of similar facilities in non-link state IGPs and BGP is a
matter for further study, but the correct operation of the repair
mechanisms for traffic with a destination outside the IGP domain is an
important consideration for solutions based on this framework</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations that arise from this framework
document.</t>
</section>
<section title="Security Considerations">
<t>This framework document does not itself introduce any security
issues, but attention must be paid to the security implications of any
proposed solutions to the problem.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge contributions made by Alia
Atlas, Clarence Filsfils, Pierre Francois, Joel Halpern, Stefano Previdi
and Alex Zinin.</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="Informative References">
&BASE;
&ALT-SP;
&BFD;
&MPLSFRR;
&MICROLOOP;
&NOTVIA;
&TUNNELS;
&U-TURNS;
<reference anchor="FIFR">
<front>
<title>Fast local rerouting for handling transient link
failures."</title>
<author initials="S." surname="Nelakuditi">
<organization abbrev="USC">University of South
Carolina</organization>
</author>
<author initials="S." surname="Lee">
<organization abbrev="USC">University of South
Carolina</organization>
</author>
<author initials="Y." surname="Lu">
<organization abbrev="USC">University of South
Carolina</organization>
</author>
<author initials="Z. L." surname="Zhang">
<organization abbrev="USC">University of South
Carolina</organization>
</author>
<author initials="C. N." surname="Chuah">
<organization abbrev="USC">University of South
Carolina</organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="Tech. Rep." value="TR-2004-004" />
</reference>
<reference anchor="SIMULA"
target="http://folk.uio.no/amundk/infocom06.pdf">
<front>
<title>Fast IP Network Recovery using Multiple Routing
Configurations."</title>
<author initials="O." surname="Lysne">
<organization abbrev="SIMULA">SIMULA Research
Laboratory</organization>
</author>
<author initials="A." surname="Kvalbein">
<organization abbrev="SIMULA">SIMULA Research
Laboratory</organization>
</author>
<author initials="T." surname="Cicic">
<organization abbrev="SIMULA">SIMULA Research
Laboratory</organization>
</author>
<author initials="S." surname="Gjessing">
<organization abbrev="SIMULA">SIMULA Research
Laboratory</organization>
</author>
<author initials="A." surname="Hansen">
<organization abbrev="SIMULA">SIMULA Research
Laboratory</organization>
</author>
<date year="2006" />
</front>
<seriesInfo name="Infocom" value="10.1109/INFOCOM.2006.227" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:04:22 |