draft-ietf-rtgwg-ipfrr-spec-base-01.txt   draft-ietf-rtgwg-ipfrr-spec-base-02.txt 
Internet Draft Alia Atlas, Ed (Avici Systems) Network Working Group A. Atlas, Ed.
Expires: March 2005 Internet-Draft Avici Systems, Inc.
Expires: July 22, 2005 January 21, 2005
Basic Specification for IP Fast-Reroute: Loop-free Alternates Basic Specification for IP Fast-Reroute: Loop-free Alternates
draft-ietf-rtgwg-ipfrr-spec-base-02
draft-ietf-rtgwg-ipfrr-spec-base-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
By submitting this Internet-Draft, I certify that any applicable which he or she is aware have been or will be disclosed, and any of
patent or other IPR claims of which I am aware have been disclosed, which he or she become aware will be disclosed, in accordance with
or will be disclosed, and any of which I become aware will be RFC 3668.
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html" http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the use of loop-free alternates to provide This document describes the use of loop-free alternates to provide
local protection for IP unicast and/or LDP traffic in the event of a local protection for IP unicast and/or LDP traffic in the event of a
single link or node failure. When a topology change occurs, a router single failure, whether link, node or shared risk link group (SRLG).
S determines for each prefix an alternate next-hop which can be used The goal of this technology is to reduce the micro-looping that and
if the primary next-hop fails. An acceptable alternate next-hop must packet loss that happens while routers converge after a topology
be a loop-free alternate, which goes to a neighbor whose shortest change due to a failure. When a topology change occurs, a router S
path to the prefix does not go back through the router S. determines for each prefix an alternate next-hop which can be used if
the primary next-hop fails. An acceptable alternate next-hop must be
a loop-free alternate, which goes to a neighbor whose shortest path
to the prefix does not go back through the router S.
Contents Table of Contents
1 Introduction ................................................. 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Failure Scenarios ......................................... 4 1.1 Failure Scenarios . . . . . . . . . . . . . . . . . . . . 4
2 Alternate Next-Hop Calcuation ................................ 6 2. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 6
2.1 Basic Loop-Free Condition ................................ 6 2.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 7
2.2 Node-Protecting Alternate Next-Hops ..................... 6 2.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 7
2.3 Broadcast and NBMA Links ................................. 6 2.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 7
2.4 Interactions wtih ISIS Overload, RFC 3137 2.4 Interactions with ISIS Overload, RFC 3137 and Costed
and Costed Out Links ..................................... 7 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Selection Procedure ...................................... 8 2.5 Selection Procedure . . . . . . . . . . . . . . . . . . . 9
3 Using an Alternate ........................................... 9 3. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Terminating Use of Alternate ............................. 9 3.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 10
4 Requirements on LDP Mode ..................................... 11 4. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 12
5 Routing Aspects .............................................. 11 5. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Multiple-Region Routing .................................... 12 5.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 12
5.1.1 Inheriting Alternate Next-Hops with One Primary Neighbor . 14 5.2 OSPF External Routing . . . . . . . . . . . . . . . . . . 13
5.1.2 OSPF Inter-Area Routes ................................... 14 5.3 OSPF Virtual Links . . . . . . . . . . . . . . . . . . . . 14
5.1.3 OSPF Inter-Area Routes ................................... 15 5.4 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 14
5.1.4 ISIS Multi-Level Routing ................................. 15 5.5 Multicast Considerations . . . . . . . . . . . . . . . . . 14
5.2 OSPF Virtual Links ......................................... 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.3 BGP Next-Hop Synchronization ............................... 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Multicast Considerations ................................... 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
6 Security Considerations ...................................... 16 Intellectual Property and Copyright Statements . . . . . . . . 17
7 Full Copyright Statement ..................................... 16
8 References ................................................... 17
9 Authors Information .......................................... 17
10 Editor's Information ......................................... 18
1. Introduction 1. Introduction
Applications for interactive multimedia services such as VoIP and Applications for interactive multimedia services such as VoIP and
pseudo-wires can be very sensitive to traffic loss, such as occurs pseudo-wires can be very sensitive to traffic loss, such as occurs
when a link or router in the network fails. A router's convergence when a link or router in the network fails. A router's convergence
time is generally on the order of seconds; the application traffic time is generally on the order of seconds; the application traffic
may be sensitive to losses greater than 10s of milliseconds. may be sensitive to losses greater than 10s of milliseconds.
As discussed in [FRAMEWORK], minimizing traffic loss requires a As discussed in [FRAMEWORK], minimizing traffic loss requires a
mechanism for the router adjacent to a failure rapidly invoke a mechanism for the router adjacent to a failure to rapidly invoke a
repair path, which is minimally affected by any subsequent re- repair path, which is minimally affected by any subsequent
convergence. This specification describes such a mechanism which re-convergence. This specification describes such a mechanism which
allows a router whose local link has failed to forward traffic to a allows a router whose local link has failed to forward traffic to a
pre-computed alternate until the router installs the new primary pre-computed alternate until the router installs the new primary
next-hops based upon the changed network topology. The terminology next-hops based upon the changed network topology. The terminology
used in this specification is given in [FRAMEWORK]. used in this specification is given in [FRAMEWORK].
When a local link fails, a router currently must signal the event to When a local link fails, a router currently must signal the event to
its neighbors via the IGP, recompute new primary next-hops for all its neighbors via the IGP, recompute new primary next-hops for all
affected prefixes, and only then install those new primary next-hops affected prefixes, and only then install those new primary next-hops
into the forwarding plane. Until the new primary next-hops are into the forwarding plane. Until the new primary next-hops are
installed, traffic directed towards the affected prefixes is installed, traffic directed towards the affected prefixes is
skipping to change at page 3, line 32 skipping to change at page 3, line 48
\ / \ /
\ \ 4 3 / / \ \ 4 3 / /
\| \ / |/ \| \ / |/
-+ \ +-----+ / +- -+ \ +-----+ / +-
\---| D |---/ \---| D |---/
+-----+ +-----+
Figure 1: Basic Topology Figure 1: Basic Topology
The goal of IP Fast-Reroute is to reduce that traffic convergence The goal of IP Fast-Reroute is to reduce that traffic convergence
time to 10s of milliseconds by using a pre-computed alternate next- time to 10s of milliseconds by using a pre-computed alternate
hop, in the event that the currently selected primary next-hop fails, next-hop, in the event that the currently selected primary next-hop
so that the alternate can be rapidly used when the failure is fails, so that the alternate can be rapidly used when the failure is
detected. detected. A network with this feature experiences less traffic loss
and less micro-looping of packets than a network without IPFRR.
There are cases where micro-looping is still a possibility since
IPFRR coverage varies but in the worst possible situation a network
with IPFRR is equivalent with respect traffic convergence to a
network without IPFRR.
To clarify the behavior of IP Fast-Reroute, consider the simple To clarify the behavior of IP Fast-Reroute, consider the simple
topology in Figure 1. When router S computes its shortest path to topology in Figure 1. When router S computes its shortest path to
router D, router S determines to use the link to router E as its router D, router S determines to use the link to router E as its
primary next-hop. Without IP Fast-Reroute, that link is the only primary next-hop. Without IP Fast-Reroute, that link is the only
next-hop that router S computes to reach D. With IP Fast-Reroute, S next-hop that router S computes to reach D. With IP Fast-Reroute, S
also looks for an alternate next-hop to use. In this example, S also looks for an alternate next-hop to use. In this example, S
would determine that it could send traffic destined to D by using the would determine that it could send traffic destined to D by using the
link to router N_1 and therefore S would install the link to N_1 as link to router N_1 and therefore S would install the link to N_1 as
its alternate next-hop. At some later time, the link between router its alternate next-hop. At some later time, the link between router
skipping to change at page 4, line 30 skipping to change at page 4, line 51
A sub-set of loop-free alternate are downstream paths which must meet A sub-set of loop-free alternate are downstream paths which must meet
the more restrictive condition of the more restrictive condition of
Distance_opt(N, D) < Distance_opt(S, D) Distance_opt(N, D) < Distance_opt(S, D)
Equation 2: Downstream Path Criterion Equation 2: Downstream Path Criterion
1.1 Failure Scenarios 1.1 Failure Scenarios
The alternate next-hop can protect against a single link failure, a The alternate next-hop can protect against a single link failure, a
single node failure, or both. single node failure, one or more shared risk link group failure, or a
combination of these. Whenever a failure occurs that is more
extensive than what the alternate was intended to protect, there is
the possibility of looping traffic. The example where a node fails
when the alternate provided only link protection is illustrated
below. If unexpected simultaneous failures occur, then micro-looping
may occur since the alternates are not pre-computed to avoid the set
of failed links.
If only link protection is provided and the node fails, it is If only link protection is provided and the node fails, it is
possible for traffic using the alternates to loop. This issue is possible for traffic using the alternates to experience
illustrated in Figure 2. If Link(S->E) fails, then the link- micro-looping. This issue is illustrated in Figure 2. If Link(S->E)
protecting alternate via N will work correctly. However, if router E fails, then the link-protecting alternate via N will work correctly.
fails, then both S and N will detect a failure and switch to their However, if router E fails, then both S and N will detect a failure
alternates. In this example, that would cause S to redirect the and switch to their alternates. In this example, that would cause S
traffic to N and N to redirect the traffic to S and thus causing a to redirect the traffic to N and N to redirect the traffic to S and
forwarding loop. Such a scenario can arise because the key thus causing a forwarding loop. Such a scenario can arise because
assumption, that all other routers in the network are forwarding the key assumption, that all other routers in the network are
based upon the shortest path, is violated because of a second forwarding based upon the shortest path, is violated because of a
simultaneous correlated failure - another link connected to the same second simultaneous correlated failure - another link connected to
primary neighbor. the same primary neighbor. If there are not other protection
mechanisms a node failure is still a concern when only using link
Such a scenario may be a concern if node failure is not otherwise protection.
protected against. Selection of only downstream paths as alternates
will ensure this does not occur, but such a restriction can severely
limit the coverage of alternates.
<@@@ <@@@
@@@> @@@>
+-----+ +-----+ +-----+ +-----+
| S |-------| N | | S |-------| N |
+-+---+ 5 +-----+ +-+---+ 5 +-----+
| | | |
| 5 5 | | | 5 4 | |
| | | \|/ | | | \|/
\|/ | | \|/ | |
| +-----+ | | +-----+ |
+----| E |---+ +----| E |---+
+--+--+ +--+--+
| |
| |
| 10 | 10
| |
+--+--+ +--+--+
| D | | D |
+-----+ +-----+
Figure 2: Link-Protecting Alternates Causing Loop on Node Failure Figure 2: Link-Protecting Alternates Causing Loop on Node Failure
It may be desirable to find an alternate which can protect against Micro-looping of traffic via the alternates caused when a more
extensive failure than planned for can be prevented via selection of
only downstream paths as alternates. In Figure 2, S would be able to
use N as an alternate, but N could not use S; therefore N would have
no alternate and would discard the traffic, thus avoiding the
micro-loop. A micro-loop due to the use of alternates can be avoided
by using downstream paths because each router in the path to the
destination must be closer to the destination (according to the
topology prior to the failures). Although use of downstream paths
ensures that the micro-looping via alternates does not occur, such a
restriction can severely limit the coverage of alternates.
It may be desirable to find an alternate that can protect against
other correlated failures (of which node failure is a specific other correlated failures (of which node failure is a specific
instance). In the general case, these are handled by shared risk instance). In the general case, these are handled by shared risk
link groups (SRLGs) where any links in the network can belong to the link groups (SRLGs) where any links in the network can belong to the
SRLG. General SRLGs may add unacceptably to the computational SRLG. General SRLGs may add unacceptably to the computational
complexity of finding a loop-free alternate. complexity of finding a loop-free alternate.
However, a sub-category of SRLGs is of interest and can be applied However, a sub-category of SRLGs is of interest and can be applied
only during the selection of an acceptable alternate. This sub- only during the selection of an acceptable alternate. This
category is to express correlated failures of links which are sub-category is to express correlated failures of links that are
connected to the same router. For example, if there are multiple connected to the same router. For example, if there are multiple
logical sub-interfaces on the same physical interface, such as VLANs logical sub-interfaces on the same physical interface, such as VLANs
on an Ethernet interface, if multiple interfaces use the same on an Ethernet interface, if multiple interfaces use the same
physical port because of channelization, or if multiple interfaces physical port because of channelization, or if multiple interfaces
share a correlated failure because they are on the same line-card. share a correlated failure because they are on the same line-card.
This sub-category of SRLGs will be referred to as local-SRLGs. A This sub-category of SRLGs will be referred to as local-SRLGs. A
local-SRLG has all of its member links with one end connected to the local-SRLG has all of its member links with one end connected to the
same router. Thus, router S could select a loop-free alternate which same router. Thus, router S could select a loop-free alternate which
does not use a link in the same local-SRLG as the primary next-hop. does not use a link in the same local-SRLG as the primary next-hop.
The local-SRLGs belonging to E can be protected against via node- The local-SRLGs belonging to E can be protected against via
protection; i.e. picking a loop-free node-protecting alternate. node-protection; i.e. picking a loop-free node-protecting alternate.
2. Alternate Next-Hop Calculation 2. Alternate Next-Hop Calculation
To support IP Fast-Reroute, a router must be able to determine if a To support IP Fast-Reroute, a router must be able to determine if a
next-hop will provide a loop-free alternate before the router next-hop will provide a loop-free alternate before the router
installs that next-hop as an alternate. That next-hop must go to a installs that next-hop as an alternate. That next-hop must go to a
loop-free neighbor. loop-free neighbor.
To do this computation, a router could run an SPF from the To do this computation, a router could run an SPF from the
perspective of each of its neighbors as well as from its own perspective of each of its neighbors as well as from its own
perspective. This provides the router with all the information perspective. This provides the router with all the information
necessary to test the equations given is this specification. necessary to test the equations given is this specification.
To determine SRLG protection, the set of SRLGs that include at least
one link from the computing router could be determined. Then when
the SPF is run from the perspective of a router's neighbor, the SRLGs
traversed on each shortest path can be tracked.
2.1 Basic Loop-free Condition 2.1 Basic Loop-free Condition
Alternate next hops used by implementations following this Alternate next hops used by implementations following this
specification MUST conform to at least the loop-freeness condition specification MUST conform to at least the loop-freeness condition
stated above in Equation 1. Further conditions may be applied when stated above in Equation 1. Further conditions may be applied when
determining link-protecting and/or node-protecting alternate next- determining link-protecting and/or node-protecting alternate
hops as described in Sections 2.2 and 2.3. next-hops as described in Sections Section 2.2 and Section 2.3.
2.2 Node-Protecting Alternate Next-Hops 2.2 Node-Protecting Alternate Next-Hops
For an alternate next-hop to protect against node failure, the For an alternate next-hop to protect against node failure, the
alternate next-hop MUST be loop-free with respect to the primary alternate next-hop MUST be loop-free with respect to the primary
neighbor E and the destination. neighbor E and the destination.
An alternate will be node-protecting if it doesn't go through the An alternate will be node-protecting if it doesn't go through the
same primary neighbor as the primary next-hop. This is the case if same primary neighbor as the primary next-hop. This is the case if
Equation 3 is true, where N is the neighbor providing a loop-free Equation 3 is true, where N is the neighbor providing a loop-free
skipping to change at page 7, line 11 skipping to change at page 8, line 6
2.3 Broadcast and NBMA Links 2.3 Broadcast and NBMA Links
The computation for link-protection is a bit more complicated for The computation for link-protection is a bit more complicated for
broadcast links. In an SPF computation, a broadcast links is broadcast links. In an SPF computation, a broadcast links is
represented as a pseudo-node with links of 0 cost exiting the represented as a pseudo-node with links of 0 cost exiting the
pseudo-node. For an alternate to be considered link-protecting, it pseudo-node. For an alternate to be considered link-protecting, it
must be loop-free with regard to the pseudo-node. Consider the must be loop-free with regard to the pseudo-node. Consider the
example in Figure 3. example in Figure 3.
+-----+ 15 +-----+ 15
| S |------- | S |--------
+-----+ | +-----+ |
| 5 | | 5 |
/----\ 5 +-----+
| PN |----| N |
\----/ +-----+
| |
| 5 | 2
| | | |
| 0 |
/----\ 0 5 +-----+
| PN |-----| N |
\----/ +-----+
| 0 |
| | 8
| 5 |
+-----+ 5 +-----+ +-----+ 5 +-----+
| E |----| D | | E |----| D |
+-----+ +-----+ +-----+ +-----+
Figure 3: Loop-Free Alternate that isn't Link-Protecting
Figure 3: Loop-Free Alternate that is Link-Protecting
In Figure 3, N offers a loop-free alternate which is link-protecting. In Figure 3, N offers a loop-free alternate which is link-protecting.
If the primary next-hop uses a broadcast link, then an alternate must If the primary next-hop uses a broadcast link, then an alternate must
be loop-free with respect to that link's pseudo-node to provide link be loop-free with respect to that link's pseudo-node to provide link
protection. This requirement is described in Equation 4 below. protection. This requirement is described in Equation 4 below.
Distance_opt(N, D) < Distance_opt(N, pseudo) + Distance_opt(pseudo, D) D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D)
Equation 4: Loop-Free Link-Protecting Criterion for Broadcast Links Equation 4: Loop-Free Link-Protecting Criterion for Broadcast Links
Because the shortest path from the pseudo-node goes through E, if a Because the shortest path from the pseudo-node goes through E, if a
loop-free alternate from a neighbor N is node-protecting, the loop-free alternate from a neighbor N is node-protecting, the
alternate will also be link-protecting unless the router S can only alternate will also be link-protecting unless the router S can only
reach the neighbor N via the same pseudo-node. This can occur reach the neighbor N via the same pseudo-node. This can occur
because S will direct traffic away from the shortest path to use an because S will direct traffic away from the shortest path to use an
alternate. alternate. Therefore link protection must be considered during the
alternate selection.
2.4 Interactions with ISIS Overload, RFC 3137 and Costed Out Links 2.4 Interactions with ISIS Overload, RFC 3137 and Costed Out Links
As described in RFC 3137, there are cases where it is desirable not As described in [RFC3137], there are cases where it is desirable not
to have a router used as a transit node. For those cases, it is also to have a router used as a transit node. For those cases, it is also
desirable not to have the router used on an alternate path. desirable not to have the router used on an alternate path.
For computing an alternate, a router MUST not consider diverting from For computing an alternate, a router MUST not consider diverting from
the SPF tree along a link whose reverse cost is LSInfinity (for OSPF) the SPF tree along a link whose cost or reverse cost is LSInfinity
or whose router has the overload bit set (for ISIS). (for OSPF) or the maximum cost (for ISIS) or whose next-hop router
has the overload bit set (for ISIS).
In the case of OSPF, if all links from router S to a neighbor N_i In the case of OSPF, if all links from router S to a neighbor N_i
have a reverse cost of LSInfinity, then router S MUST NOT consider have a reverse cost of LSInfinity, then router S MUST NOT consider
using N_i as an alternate. using N_i as an alternate.
Similarly in the case of ISIS, if N_i has the overload bit set, then Similarly in the case of ISIS, if N_i has the overload bit set, then
S MUST NOT consider using N_i as an alternate. S MUST NOT consider using N_i as an alternate.
This preserves the desired behavior of diverting traffic away from a This preserves the desired behavior of diverting traffic away from a
router which is following RFC 3137 and it also preserves the desired router which is following [RFC3137] and it also preserves the desired
behavior when an operator sets the cost of a link to LSInfinity for behavior when an operator sets the cost of a link to LSInfinity for
maintenance which is not permitting traffic across that link unless maintenance which is not permitting traffic across that link unless
there is no other path. there is no other path.
If a link or router which is costed out was the only possible If a link or router which is costed out was the only possible
alternate to protect traffic from a particular router S to a alternate to protect traffic from a particular router S to a
particular destination, then there will be no alternate provided for particular destination, then there will be no alternate provided for
protection. protection.
2.5 Selection Procedure 2.5 Selection Procedure
A router supporting this specification SHOULD select a loop-free A router supporting this specification SHOULD select a loop-free
alternate next-hop for each primary next-hop used for a given prefix. alternate next-hop for each primary next-hop used for a given prefix.
A router MAY decide to not use an available loop-free alternate A router MAY decide to not use an available loop-free alternate
next-hop. A reason for such a decision might be that the loop-free next-hop. A reason for such a decision might be that the loop-free
alternate next-hop does not provide protection for the failure alternate next-hop does not provide protection for the failure
scenario of interest. scenario of interest.
The selection should maximize the failure cases which can be The alternate selection should maximize the coverage of the failure
protected against. cases.
The selection procedure depends on whether S has a single primary
neighbor or multiple primary neighbors. A node S is defined to have
a single primary neighbor only if there are no equal cost paths that
go through any other neighbor; i.e., a node S cannot be considered to
have a single primary neighbor simply because S does not support
ECMP.
If S has a single primary neighbor, then S SHOULD select a loop-free
node-protecting alternate next-hop, if one is available. If S has a
choice between a loop-free link-protecting node-protecting alternate
and a loop-free node-protecting alternate which is not link-
protecting, S SHOULD select a loop-free node-protecting alternate
which is also link-protecting. This can occur as explained in
Section 2.3. If no loop-free node-protecting alternate is available,
then S MAY select a loop-free link-protecting alternate.
If S has multiple primary neighbors, then S SHOULD select as a loop- S SHOULD select a loop-free node-protecting alternate next-hop, if
free alternate either one of the other primary next-hops or a loop- one is available. If S has a choice between a loop-free
free node-protecting alternate. S MAY select a loop-free link- link-protecting node-protecting alternate and a loop-free
protecting alternate. node-protecting alternate which is not link-protecting, S SHOULD
select a loop-free node-protecting alternate which is also
link-protecting. This can occur as explained in Section 2.3. If S
has multiple primary next-hops, then S SHOULD select as a loop-free
alternate either one of the other primary next-hops or a loop-free
node-protecting alternate. If no loop-free node-protecting alternate
is available, then S MAY select a loop-free link-protecting
alternate.
Each next-hop can be categorized as to the type of alternate it can Each next-hop can be categorized as to the type of alternate it can
provide to a particular destination D from router S for a particular provide to a particular destination D from router S for a particular
primary next-hop which goes to a neighbor E. A next-hop may provide primary next-hop which goes to a neighbor E. A next-hop may provide
one of the following types of paths: one of the following types of paths:
Primary Path - This is the primary next-hop. Primary Path - This is the primary next-hop.
Loop-Free Node-Protecting Alternate - This next-hop satisfies Loop-Free Node-Protecting Alternate - This next-hop satisfies
Equations 1 and 3. The path avoids S, S's primary neighbor E, Equation 1 and Equation 3. The path avoids S, S's primary
and the link from S to E. neighbor E, and the link from S to E.
Loop-Free Link-Protecting Alternate - This next-hop satisfies Loop-Free Link-Protecting Alternate - This next-hop satisfies
Equation 1 but not Equation 3. If the primary next-hop uses a Equation 1 but not Equation 3. If the primary next-hop uses a
broadcast link, then this next-hop satisfies Equation 4. broadcast link, then this next-hop satisfies Equation 4.
Unavailable - This may be because the path goes through S to Unavailable - This may be because the path goes through S to reach
reach D, because the link is costed out, etc. D, because the link is costed out, etc.
An alternate path may also provide none, some or complete SRLG
protection as well as node and link or link protection. For
instance, a link may belong to two SRLGs G1 and G2. The alternate
path might avoid other links in G1 but not G2, in which case the
alternate would only provide partial SRLG protection.
3. Using an Alternate 3. Using an Alternate
If an alternate next-hop is available, the router SHOULD redirect If an alternate next-hop is available, the router SHOULD redirect
traffic to the alternate next-hop when the primary next-hop has traffic to the alternate next-hop when the primary next-hop has
failed. failed.
When a local interface failure is detected, traffic that was destined When a local interface failure is detected, traffic that was destined
to go out the failed interface must be redirected to the appropriate to go out the failed interface must be redirected to the appropriate
alternate next-hops. Other failure detection mechanisms which detect alternate next-hops. Other failure detection mechanisms which detect
skipping to change at page 9, line 51 skipping to change at page 10, line 47
The alternate next-hop MUST be used only for traffic types which are The alternate next-hop MUST be used only for traffic types which are
routed according to the shortest path. Multicast traffic is routed according to the shortest path. Multicast traffic is
specifically out of scope for this specification. specifically out of scope for this specification.
3.1 Terminating Use of Alternate 3.1 Terminating Use of Alternate
A router MUST limit the amount of time an alternate next-hop is used A router MUST limit the amount of time an alternate next-hop is used
after the primary next-hop has become unavailable. This ensures that after the primary next-hop has become unavailable. This ensures that
the router will start using the new primary next-hops. It ensures the router will start using the new primary next-hops. It ensures
that all possible transient conditions are remvoed and the network that all possible transient conditions are removed and the network
converges according to the deployed routing protocol. converges according to the deployed routing protocol.
It is desirable to avoid micro-forwarding loops involving S. An It is desirable to avoid micro-forwarding loops involving S. An
example illustrating the problem is given in Figure 4. If the link example illustrating the problem is given in Figure 4. If the link
from S to E fails, S will use N1 as an alternate and S will compute from S to E fails, S will use N1 as an alternate and S will compute
N2 as the new primary next-hop to reach D. If S starts using N2 as N2 as the new primary next-hop to reach D. If S starts using N2 as
soon as S can compute and install its new primary, it is probable soon as S can compute and install its new primary, it is probable
that N2 will not have yet installed its new primary next-hop. This that N2 will not have yet installed its new primary next-hop. This
would cause traffic to loop and be dropped until N2 has installed the would cause traffic to loop and be dropped until N2 has installed the
new topology. This can be avoided by S delaying its installation and new topology. This can be avoided by S delaying its installation and
skipping to change at page 10, line 47 skipping to change at page 11, line 42
This is an example of a case where the new primary is not a loop-free This is an example of a case where the new primary is not a loop-free
alternate before the failure and therefore may have been forwarding alternate before the failure and therefore may have been forwarding
traffic through S. This will occur when the path via a previously traffic through S. This will occur when the path via a previously
upstream node is shorter than the the path via a loop-free alternate upstream node is shorter than the the path via a loop-free alternate
neighbor. In these cases, it is useful to give sufficient time to neighbor. In these cases, it is useful to give sufficient time to
ensure that the new primary neighbor and other nodes on the new ensure that the new primary neighbor and other nodes on the new
primary path have switched to the new route. primary path have switched to the new route.
If the newly selected primary was loop-free before the failure, then If the newly selected primary was loop-free before the failure, then
it is safe to switch to that new primary immediately; the new it is safe to switch to that new primary immediately; the new primary
primary wasn't dependent on the failure and therefore its path will wasn't dependent on the failure and therefore its path will not have
not have changed. changed.
Given that there is an alternate providing appropriate protection and Given that there is an alternate providing appropriate protection and
while the assumption of a single failure holds, it is safe to delay while the assumption of a single failure holds, it is safe to delay
the installation of the new primaries; this will not create the installation of the new primaries; this will not create
forwarding loops because the alternate's path to the destination is forwarding loops because the alternate's path to the destination is
known to not go via S or the failed element and will therefore not be known to not go via S or the failed element and will therefore not be
affected by the failure. affected by the failure.
An implementation SHOULD continue to use the alternate next-hops for An implementation SHOULD continue to use the alternate next-hops for
packet forwarding even after the new routing information is available packet forwarding even after the new routing information is available
based on the new network topology. The use of the alternate next- based on the new network topology. The use of the alternate
hops for packet forwarding SHOULD terminate next-hops for packet forwarding SHOULD terminate:
a) if the new primary next-hop was loop-free prior to the topology a. if the new primary next-hop was loop-free prior to the topology
change, or change, or
b) if a configured hold-down, which represents a worst-case bound b. if a configured hold-down, which represents a worst-case bound on
on the length of the network convergence transition, has expired, the length of the network convergence transition, has expired, or
or
c) if notification of an unrelated topological change in the c. if notification of an unrelated topological change in the network
network is received. is received.
4. Requirements on LDP Mode 4. Requirements on LDP Mode
Since LDP traffic will follow the path specified by the IGP, it is Since LDP traffic will follow the path specified by the IGP, it is
also possible for the LDP traffic to follow the loop-free alternates also possible for the LDP traffic to follow the loop-free alternates
indicated by the IGP. To do so, it is necessary for LDP to have the indicated by the IGP. To do so, it is necessary for LDP to have the
appropriate labels available for the alternate so that the appropriate labels available for the alternate so that the
appropriate out-segments can be installed in the forwarding plane appropriate out-segments can be installed in the forwarding plane
before the failure occurs. before the failure occurs.
skipping to change at page 12, line 4 skipping to change at page 12, line 42
that the labels which correspond to neighbors that aren't currently that the labels which correspond to neighbors that aren't currently
the primary neighbor are stored. Similarly, LDP should be in the primary neighbor are stored. Similarly, LDP should be in
downstream unsolicited mode, so that the labels for the FEC are downstream unsolicited mode, so that the labels for the FEC are
distributed other than along the SPT. distributed other than along the SPT.
If these requirements are met, then LDP can use the loop-free If these requirements are met, then LDP can use the loop-free
alternates without requiring any targeted sessions or signaling alternates without requiring any targeted sessions or signaling
extensions for this purpose. extensions for this purpose.
5. Routing Aspects 5. Routing Aspects
An SPF-like computation is run for each topology, which corresponds
to a particular OSPF area or ISIS level. The IGP needs to determine
the inheritance of loop-free alternates, as determined for singly
advertised routes, to multiply advertised routes, for protocols such
as BGP and LDP and for inter-area or inter-level routes. These
alternates are provided to LDP and BGP for forwarding purposes only;
the alternates are not redistributed in any fashion into other
protocols.
The alternate next-hop inheritance is described in the context of
inter-area routes, but applies equally well to BGP routes and to
routes which are advertised by multiple routers in the IGP area.
5.1 Multiple-Region Routing
Routes in different regions inherit their primary next-hops from the
border routers (area border routers (ABRs) or level boundary routers)
which offer the shortest path to the destination(s) announcing the
route. Similarly, routes must inherit their alternate next-hop and
will do so from the same border routers. The shortest path to an
inter-region route may be learned from a single border router. In
that case, both the primary and the alternate next-hops can be
inherited from that border router. Figure 5 illustrates this case
where D is reached via ABR1; the primary next-hop for ABR1 is E and
the loop-free node-protecting alternate is A1.
.............
...... ......
... ...
.. ..
.. 10 +-----+ 5 +-----+ 5 ..
. +------| A1 +---------| R1 |-----+ .
.. | +-----+ +-----+ | .
. | +-----+ 10
. | +--------------| ABR1|---------+
. | | 5 +-----+ |
. +-----+ 5 +---+-+ . |
. | S |-----------| E |------------+ . +-----+
. +-----+ +-----+ 10 | . | D |
. | | . +-----+
. | | . |
.. | +-----+ +-----+ 20 |
. +-----| A2 |------------------| ABR2|------------+
. 10 +-----+ 5 +-----+
... ...
... ...
.........................
Figure 5: Inter-Region Destination via One Border Router
The shortest path to an inter-region route may be learned from
multiple border routers with at least 2 different primary neighbors,
as is illustrated in Figure 6. D is reached via ABR1 and ABR2 with
equal cost from S. The primary neighbor to reach ABR1 is E1 and the
alternate is A1. The primary neighbor to reach ABR2 is E2 and the
alternate is A2. In this case, there are equal-cost primary next-
hops to reach D and they can protect each other. In this example,
the primary next-hops would be to E1 and E2; if the link to E2
failed, then E1 could be used as an alternate and vice-versa. Thus
the alternates can be obtained from the primary next-hops.
..........
...... ......
... ...
.. ..
.. 10 +-----+ 5 +-----+ ..
. +------| A1 +---------| R1 |-----+
.. | +-----+ +-----+ |.
. | +-----+ +-----+ 10
. | +-----------| E1 |------------| ABR1|---------+
. | | 5 +-----+ 5 +-----+ |
. +-----+ . |
. | S |---+ 5 +-----+ 10 . +-----+
. +-----+ +-------| E2 |------------+ . | D |
. | +-----+ | . +-----+
. | | . |
.. | +-----+ +-----+ 20 |
. +-----| A2 |------------------| ABR2|------------+
. 10 +-----+ 5 +-----+
... ...
... ...
...... ......
..........
Figure 6: Inter-Region Destination via
Multiple Border Routers and Multiple Primary Neighbors
In the third case, the shortest path to an inter-region route
may be learned from multiple border routers but with a single
primary neighbor. This is shown in Figure 7, where D can be
equally reached from S via ABR1 and ABR2. The alternate next-
hop to reach ABR1 is A1 while the alternate to reach ABR2 is A2.
It is necessary to select one of the alternates to be inherited.
.............
...... ......
... ...
.. ..
.. 5 +-----+ 15 +-----+ 20 ..
. +------| A1 +---------| R1 |-----+ .
.. | +-----+ +-----+ | .
. | +-----+ 10
. | +--------------| ABR1|---------+
. | | 15 +-----+ |
. +-----+ 5 +---+-+ . |
. | S |-----------| E |------------+ . +-----+
. +-----+ +-----+ 5 | . | D |
. | | . +-----+
. | | . |
.. | +-----+ +-----+ 20 |
. +-----| A2 |------------------| ABR2|------------+
. 10 +-----+ 15 +-----+
... ...
... ...
...... ......
.............
Figure 7: Inter-Region Destination via 5.1 Multi-Homed Prefixes
Multiple Border Routers but One Primary Neighbor
5.1.1 Inheriting Alternate Next-Hops with One Primary Neighbor An SPF-like computation is run for each topology, which corresponds
to a particular OSPF area or ISIS level. The IGP needs to determine
loop-free alternates to multi-homed routes. Multi-homed routes occur
for routes obtained from outside the routing domain by multiple
routers, for subnets on links where the subnet is announced from
multiple ends of the link, and for routes advertised by multiple
routers to provide resiliency.
The main question when deciding whether an alternate can be inherited Figure 5 demonstrates such a topology. In this example, the shortest
is whether or not that alternate will continue to provide the path to reach the prefix p is via E. The prefix p will have the link
necessary protection. I.e., will the alternate continue to be usable to E as its primary next-hop. If the alternate next-hop for the
as an alternate and provide the same link or node protection with prefix p is simply inherited from the router advertising it on the
respect to the destination that was provided with respect to the shortest path to p, then the prefix p's alternate next-hop would be
border router. It can be proved that the alternate will be usable as the link to C. This would provide link protection, but not the node
an alternate and provide at least the same link or node protection protection that is possible via A.
that was provided with respect to the border router. The alternate
next-hop inheritance procedure SHOULD select a loop-free node-
protecting alternate, if one is available.
5.1.2 OSPF Inter-Area Routes 5 +---+ 4 +---+ 5 +---+
------| S |------| A |-----| B |
| +---+ +---+ +---+
| | |
| 5 | 5 |
| | |
+---+ 5 +---+ 5 7 +---+
| C |---| E |------ p -------| F |
+---+ +---+ +---+
In OSPF, each area's links are summarized into a summary LSA, which Figure 5: Multi-homed prefix
is announced into an area by an Area Border Router. ABRs announce
summary LSAs into the backbone area and inject summary LSAs of the
backbone area into other non-backbone areas. A route can be learned
via summary LSA from one or more ABRs; such a route will be referred
to as a summary route.
The alternate next-hop inheritance for summary routes is as described To determine the best protection possible, the prefix p can be
in Section 5.1.1 treated in the SPF computations as a node with uni-directional links
to it from those routers that have advertised the prefix. Such a
node need never have its links explored, as it has no out-going
links.
5.1.3 OSPF External Routing If there exist multiple multi-homed prefixes exist that share the
same connectivity and the difference in metrics to those routers,
then a single node can be used to represent the set. For instance,
if in Figure 5 there were another prefix X that was connected to E
with a metric of 1 and to F with a metric of 3, then that prefix X
could use the same alternate next-hop as was computed for prefix p.
Rules of inheritance of alternate next-hops for external routes is A router SHOULD compute the alternate next-hop for an IGP multi-homed
the same as for inter-area destinations. The additional complication prefix by considering alternate paths via all routers that have
comes from forwarding addresses, where an ASBR uses a forwarding announced that prefix.
address to indicate to all routers in the Autonomous System to use
the specified address instead of going through the ASBR. When a
forwarding address has been indicated, all routers in the topology
calculate the shortest path to the link specified in the external
LSA. In this case, the alternate next-hop of the forwarding link
should be used, in conjunction with the primary next-hop of the
forwarding link, instead of those associated with the ASBR.
5.1.4 ISIS Multi-Level Routing 5.2 OSPF External Routing
ISIS maintains separate databases for each level with which it is An additional complication comes from forwarding addresses, where an
dealing. Nodes in one level do not have any information about state ASBR uses a forwarding address to indicate to all routers in the
of nodes and edges of the other level. ISIS level boundary points , Autonomous System to use the specified address instead of going
also known as ISIS level boundary routers, are attached to both through the ASBR. When a forwarding address has been indicated, all
levels. ISIS level boundary routers summarize the destinations in routers in the topology calculate the shortest path to the link
each, level. ISIS inter-level route computation is very similar to specified in the external LSA. In this case, the alternate next-hop
OSPF inter area routing. Rules for alternate next-hop inheritance is should be computed by selecting among the alternate paths to the
the same as described in Section 5.1.1 forwarding link(s) instead of among alternate paths to the ASBR.
5.2 OSPF Virtual Links 5.3 OSPF Virtual Links
OSPF virtual links are used to connect two disjoint backbone areas OSPF virtual links are used to connect two disjoint backbone areas
using a transit area. A virtual link is configured at the border using a transit area. A virtual link is configured at the border
routers of the disjoint area. There are two scenarios, depending routers of the disjoint area. If router S is itself an ABR or one of
upon the position of the root, router S. the endpoints of the disjoint area, then router S must resolve its
paths to the destination on the other side of the disjoint area by
If router S is itself an ABR or one of the endpoints of the disjoint using the summary links in the transit area and using the closest ABR
area, then router S must resolve its paths to the destination on the summarizing them into the transit area. This means that the data
other side of the disjoint area by using the summary links in the path may diverge from the virtual neighbor's control path. An ABR's
transit area and using the closest ABR summarizing them into the primary and alternate next-hops are calculated by S on the transit
transit area. This means that the data path may diverge from the area.
virtual neighbor's control path. An ABR's primary and alternate
next-hops are calculated by S on the transit area.
The primary next-hops to use are determined based upon the closest
set of equidistant ABRs; the same rules described in Section 5.1.1
for inter-area destinations must be followed for OSPF virtual links
to determine the alternate next-hop. The same ECMP cases apply.
If router S is not an ABR, then all the destinations on the other
side of the disjoint area will inherit the virtual link's endpoint,
the transit ABR. The same OSPF inter-area rules described in Section
5.1.1 must be followed here as well.
A virtual link cannot be used as an alternate next-hop. A virtual link MUST NOT be used as an alternate next-hop.
5.3 BGP Next-Hop Synchronization 5.4 BGP Next-Hop Synchronization
Typically BGP prefixes are advertised with AS exit routers router-id, Typically BGP prefixes are advertised with AS exit routers router-id,
and AS exit routers are reached by means of IGP routes. BGP resolves and AS exit routers are reached by means of IGP routes. BGP resolves
its advertised next-hop to the immediate next-hop by potential its advertised next-hop to the immediate next-hop by potential
recursive lookups in the routing database. IP Fast-Reroute computes recursive lookups in the routing database. IP Fast-Reroute computes
the alternate next-hops to the all the IGP destinations, which the alternate next-hops to all IGP destinations, which include
includes alternate next-hops to the AS exit router's router-id. BGP alternate next-hops to the AS exit router's router-id. BGP simply
simply inherits the alternate next-hop from IGP. The BGP decision inherits the alternate next-hop from IGP. The BGP decision process
process is unaltered; BGP continue to use the IGP optimal distance to is unaltered; BGP continues to use the IGP optimal distance to find
find the nearest exit router. MBGP routes do not need to copy the the nearest exit router. MBGP routes do not need to copy the
alternate next hops. alternate next hops.
5.4 Multicast Considerations It is possible to provide ASBR protection if BGP selected a set of
IGP next-hops and allowed the IGP to determine the primary and
alternate next-hops as if the BGP route were a multi-homed prefix.
This is for future study.
Multicast traffic is out of scope for this specification of IP Fast- 5.5 Multicast Considerations
Reroute. The alternate next-hops SHOULD not used for multi-cast RPF
checks. Multicast traffic is out of scope for this specification of IP
Fast-Reroute. The alternate next-hops SHOULD not used for multi-cast
RPF checks.
6. Security Considerations 6. Security Considerations
This document does not introduce any new security issues. The This document does not introduce any new security issues. The
mechanisms described in this document depend upon the network mechanisms described in this document depend upon the network
topology distributed via an IGP, such as OSPF or ISIS. It is topology distributed via an IGP, such as OSPF or ISIS. It is
dependent upon the security associated with those protocols. dependent upon the security associated with those protocols.
7. Full Copyright Statement 7 References
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References
[FRAMEWORK] M. Shand, "IP Fast Reroute Framework", draft-ietf-rtgwg-
ipfrr-framework-01.txt, June 2004
[LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
"LDP Specification", RFC 3036, January 2001
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001
[RSVP-TE FRR] P. Pan, D. Gan, G. Swallow, JP Vasseur, D. Cooper, A.
Atlas, and M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", work-in-progress draft-ietf-mpls-rsvp-lsp-fastreroute-
07.txt, June 2004
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and [FRAMEWORK]
McPherson, D., "OSPF Stub Router Advertisement", RFC 3137, June 2001 Shand, M., "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-02.txt (work in
progress), October 2004.
[RFC3277] D. McPherson, "Intermediate System to Intermediate System [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
(IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002 B. Thomas, "LDP Specification", RFC 3036, January 2001.
[ISIS] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A. and D.
Environments", RFC 1195, December 1990 McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[RFC2966] T. Li, T. Przygienda, H. Smit, "Domain-wide Prefix [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
Distribution with Two-Level IS-IS", RFC 2966, October 2000 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[OSPF] J. Moy, "OSPF Version 2", RFC 2328, April 1998 Authors' Addresses
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option", RFC 2370, July Alia K. Atlas (editor)
1998 Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862
USA
9. Authors Information Phone: +1 978 964 2070
EMail: aatlas@avici.com
Raveendra Torvi Raveendra Torvi
Avici Systems Avici Systems, Inc.
101 Billerica Avenue 101 Billerica Avenue
N. Billerica, MA 01862 N. Billerica, MA 01862
USA USA
email: rtorvi@avici.com
phone: +1 978 964 2026
Phone: +1 978 964 2026
EMail: rtorvi@avici.com
Gagan Choudhury Gagan Choudhury
AT&T AT&T
Room D5-3C21 200 Laurel Avenue, Room D5-3C21
200 Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
email: gchoudhury@att.com
phone: +1 732 420-3721 Phone: +1 732 420-3721
EMail: gchoudhury@att.com
Christian Martin Christian Martin
Verizon Verizon
1880 Campus Commons Drive 1880 Campus Commons Drive
Reston, VA 20191 Reston, VA 20191
email: cmartin@verizon.com USA
Brent Imhoff Brent Imhoff
WilTel Communications LightCore
3180 Rider Trail South 14567 North Outer Forty Rd.
Bridgeton, MO 63045 Chesterfield, MO 63017
USA USA
email: brent.imhoff@wcg.com
phone: +1 314 595 6853 Phone: +1 314 880 1851
EMail: brent@lightcore.net
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park 600 Technology Park
Billerica, MA 01821 Billerica, MA 01821
email: dwfedyk@nortelnetworks.com USA
phone: +1 978 288 3041
10. Editor's Information Phone: +1 978 288 3041
EMail: dwfedyk@nortelnetworks.com
Alia Atlas Intellectual Property Statement
Avici Systems
101 Billerica Avenue The IETF takes no position regarding the validity or scope of any
N. Billerica, MA 01862 Intellectual Property Rights or other rights that might be claimed to
USA pertain to the implementation or use of the technology described in
email: aatlas@avici.com this document or the extent to which any license under such rights
phone: +1 978 964 2070 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/