draft-ietf-rtgwg-ipfrr-spec-base-04.txt   draft-ietf-rtgwg-ipfrr-spec-base-05.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Google Inc. Internet-Draft Google, Inc.
Expires: January 16, 2006 A. Zinin, Ed. Expires: August 5, 2006 A. Zinin, Ed.
Alcatel Alcatel
July 15, 2005 February 2006
Basic Specification for IP Fast-Reroute: Loop-free Alternates Basic Specification for IP Fast-Reroute: Loop-free Alternates
draft-ietf-rtgwg-ipfrr-spec-base-04 draft-ietf-rtgwg-ipfrr-spec-base-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 as "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/ietf/1id-abstracts.txt. 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 January 16, 2006. This Internet-Draft will expire on August 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 unicast traffic in pure IP and MPLS/LDP networks local protection for unicast traffic in pure IP and MPLS/LDP networks
in the event of a single failure, whether link, node or shared risk in the event of a single failure, whether link, node or shared risk
link group (SRLG). The goal of this technology is to reduce the link group (SRLG). The goal of this technology is to reduce the
micro-looping and packet loss that happens while routers converge micro-looping and packet loss that happens while routers converge
after a topology change due to a failure. Rapid failure repair is after a topology change due to a failure. Rapid failure repair is
achieved through use of precalculated backup next-hops that are loop- achieved through use of precalculated backup next-hops that are loop-
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5 1.1 Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5
2. Applicability of Described Mechanisms . . . . . . . . . . . . 6 2. Applicability of Described Mechanisms . . . . . . . . . . . . 6
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 7 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 7
3.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 8 3.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 8
3.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9 3.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9
3.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 9 3.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 9
3.4 ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11 3.4 ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11
3.5 Interactions with ISIS Overload, RFC 3137 and Costed 3.5 Interactions with ISIS Overload, RFC 3137 and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 11 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Interactions with ISIS Link Attributes . . . . . . . . 12
3.6 Selection Procedure . . . . . . . . . . . . . . . . . . . 12 3.6 Selection Procedure . . . . . . . . . . . . . . . . . . . 12
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 16 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 16 4.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 17
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 18 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 18
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 18 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 19
6.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 19 6.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 19
6.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.1 OSPF External Routing . . . . . . . . . . . . . . . . 20 6.2.1 OSPF External Routing . . . . . . . . . . . . . . . . 20
6.3 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 20 6.3 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 21
6.4 Multicast Considerations . . . . . . . . . . . . . . . . . 21 6.4 Multicast Considerations . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22
9.2 Informative References . . . . . . . . . . . . . . . . . . 22 9.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
A. OSPF Example Where LFA Based on Local Area Topology is A. OSPF Example Where LFA Based on Local Area Topology is
Insufficient . . . . . . . . . . . . . . . . . . . . . . . . . 24 Insufficient . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 26
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 [I-D.ietf-rtgwg-ipfrr-framework], minimizing traffic
mechanism for the router adjacent to a failure to rapidly invoke a loss requires a mechanism for the router adjacent to a failure to
repair path, which is minimally affected by any subsequent re- rapidly invoke a repair path, which is minimally affected by any
convergence. This specification describes such a mechanism which subsequent re-convergence. This specification describes such a
allows a router whose local link has failed to forward traffic to a mechanism which allows a router whose local link has failed to
pre-computed alternate until the router installs the new primary forward traffic to a pre-computed alternate until the router installs
next-hops based upon the changed network topology. The terminology the new primary next-hops based upon the changed network topology.
used in this specification is given in [FRAMEWORK]. The described The terminology used in this specification is given in [I-D.ietf-
mechanism assumes that routing in the network is performed using a rtgwg-ipfrr-framework]. The described mechanism assumes that routing
link-state routing protocol-- OSPF[RFC2328] or ISIS [RFC1195] in the network is performed using a link-state routing protocol--
[RFC2966]. OSPF[RFC2328] or ISIS [RFC1195] [RFC2966].
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
discarded. This process can take seconds. discarded. This process can take seconds.
<-- <--
+-----+ +-----+
skipping to change at page 8, line 26 skipping to change at page 8, line 26
Distance_opt(N, D) and Distance_opt(N, S) can be obtained by Distance_opt(N, D) and Distance_opt(N, S) can be obtained by
performing additional SPF calculations from the perspective of performing additional SPF calculations from the perspective of
each IGP neighbor (i.e. considering the neighbor's vertex as the each IGP neighbor (i.e. considering the neighbor's vertex as the
root of the SPT--called SPT(N) hereafter--rather than the root of the SPT--called SPT(N) hereafter--rather than the
calculating router's one, called SPT(S)). calculating router's one, called SPT(S)).
This specification defines a form of SRLG protection limited to those This specification defines a form of SRLG protection limited to those
SRLGs that include a link that the calculating router is directly SRLGs that include a link that the calculating router is directly
connected to. Information about local link SRLG membership is connected to. Information about local link SRLG membership is
manually configured. Information about remote link SRLG membership manually configured. Information about remote link SRLG membership
is dynamically obtained using [ISIS-SRLG] or [OSPF-SRLG]. In order is dynamically obtained using [RFC4205] or [RFC4203]. In order to
to choose among all available LFAs that provide required SRLG choose among all available LFAs that provide required SRLG protection
protection for a given destination, the calculating router needs to for a given destination, the calculating router needs to track the
track the set of SRLGs that the path through a specific IGP neighbor set of SRLGs that the path through a specific IGP neighbor involves.
involves. To do so, each node D in the network topology is To do so, each node D in the network topology is associated with
associated with SRLG_set(N, D), which is the set of SRLGs that would SRLG_set(N, D), which is the set of SRLGs that would be crossed if
be crossed if traffic to D was forwarded through N. To calculate this traffic to D was forwarded through N. To calculate this set, the
set, the router initializes SRLG_set(N, N) for each of its IGP router initializes SRLG_set(N, N) for each of its IGP neighbors to be
neighbors to be empty. During the SPT(N) calculation, when a new empty. During the SPT(N) calculation, when a new vertex V is added
vertex V is added to the SPT, its SRLG_set(N, V) is set to the union to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets
of SRLG sets associated with its parents, and the SRLG sets associated with its parents, and the SRLG sets associated with the
associated with the links from V's parents to V. The union of the set links from V's parents to V. The union of the set of SRLG associated
of SRLG associated with a candidate alternate next-hop and the with a candidate alternate next-hop and the SRLG_set(N, D) for the
SRLG_set(N, D) for the neighbor reached via that candidate next-hop neighbor reached via that candidate next-hop is used to determine
is used to determine SRLG protection. SRLG protection.
The following sections provide information required for calculation The following sections provide information required for calculation
of LFAs. Sections Section 3.1 through Section 3.4 define different of LFAs. Sections Section 3.1 through Section 3.4 define different
types of LFA conditions. Section 3.5 describes constrains imposed by types of LFA conditions. Section 3.5 describes constrains imposed by
the IS-IS overload and OSPF stub router functionality. Section 3.6 the IS-IS overload and OSPF stub router functionality. Section 3.6
defines the summarized algorithm for LFA calculation using the defines the summarized algorithm for LFA calculation using the
definitions in the previous sections. definitions in the previous sections.
3.1 Basic Loop-free Condition 3.1 Basic Loop-free Condition
skipping to change at page 12, line 33 skipping to change at page 12, line 33
router which is following [RFC3137] 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 should be no alternate provided particular destination, then there should be no alternate provided
for protection. for protection.
3.5.1 Interactions with ISIS Link Attributes
[I-D.ietf-isis-link-attr] describes several flags whose interactions
with LFAs needs to be defined. A router SHOULD NOT specify the
"local protection available" flag as a result of having LFAs. A
router SHOULD NOT use an alternate next-hop that is along a link for
which the link has been advertised with the attribute "link excluded
from local protection path" or with the attribute "local mainenance
required".
3.6 Selection Procedure 3.6 Selection Procedure
A router supporting this specification SHOULD attempt to select at A router supporting this specification SHOULD attempt to select at
least one loop-free alternate next-hop for each primary next-hop used least one loop-free alternate next-hop for each primary next-hop used
for a given prefix. A router MAY decide to not use an available for a given prefix. A router MAY decide to not use an available
loop-free alternate next-hop. A reason for such a decision might be loop-free alternate next-hop. A reason for such a decision might be
that the loop-free alternate next-hop does not provide protection for that the loop-free alternate next-hop does not provide protection for
the failure scenario of interest. the failure scenario of interest.
The alternate selection should maximize the coverage of the failure The alternate selection should maximize the coverage of the failure
skipping to change at page 16, line 48 skipping to change at page 17, line 11
Note that the router MAY remove other next-hops if it believes (via Note that the router MAY remove other next-hops if it believes (via
SRLG analysis) that they may have been affected by the same failure, SRLG analysis) that they may have been affected by the same failure,
even if it is not visible at the time of failure detection. even if it is not visible at the time of failure detection.
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.
4.1 Terminating Use of Alternate 4.1 Terminating Use of Alternate
NOTE: this section may be replaced with a reference to [ULOOP].
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 removed 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.
A router that implements [I-D.ietf-rtgwg-microloop-analysis] SHOULD
follow the rules given there for terminating the use of an alternate.
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 5. If the link example illustrating the problem is given in Figure 5. 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
leaving traffic on the alternate next-hop. leaving traffic on the alternate next-hop.
skipping to change at page 22, line 7 skipping to change at page 22, line 17
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
9.2 Informative References 9.2 Informative References
[FRAMEWORK] [I-D.ietf-isis-link-attr]
Shand, M., "IP Fast Reroute Framework", Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
draft-ietf-rtgwg-ipfrr-framework-03.txt (work in Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in
progress), June 2005. progress), May 2005.
[ISIS-SRLG] [I-D.ietf-rtgwg-ipfrr-framework]
Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support Shand, M. and S. Bryant, "IP Fast Reroute Framework",
of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19 draft-ietf-rtgwg-ipfrr-framework-05 (work in progress),
(work in progress), October 2003. March 2006.
[OSPF-SRLG] [I-D.ietf-rtgwg-microloop-analysis]
Kompella, K. and Y. Rekhter, "OSPF Extensions in Support Zinin, A., "Analysis and Minimization of Microloops in
of Generalized Multi-Protocol Label Switching", Link-state Routing Protocols",
draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in draft-ietf-rtgwg-microloop-analysis-01 (work in progress),
progress), October 2003. October 2005.
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, Distribution with Two-Level IS-IS", RFC 2966,
October 2000. October 2000.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001. June 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative [RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative
Implementations of OSPF Area Border Routers", RFC 3509, Implementations of OSPF Area Border Routers", RFC 3509,
April 2003. April 2003.
[ULOOP] Zinin, A., "Analysis and Minimization of Microloops in [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Link-state Routing Protocols", of Generalized Multi-Protocol Label Switching (GMPLS)",
draft-zinin-microloop-analysis-01.txt (work in progress), RFC 4203, October 2005.
May 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
Authors' Addresses Authors' Addresses
Alia K. Atlas (editor) Alia K. Atlas (editor)
Google Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: akatlas@alum.mit.edu Email: akatlas@alum.mit.edu
Alex Zinin (editor) Alex Zinin (editor)
Alcatel Alcatel
701 E Middlefield Rd. 701 E Middlefield Rd.
Mountain View, CA 94043 Mountain View, CA 94043
skipping to change at page 23, line 40 skipping to change at page 24, line 4
Email: rtorvi@avici.com Email: rtorvi@avici.com
Gagan Choudhury Gagan Choudhury
AT&T AT&T
200 Laurel Avenue, Room D5-3C21 200 Laurel Avenue, Room D5-3C21
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420-3721 Phone: +1 732 420-3721
Email: gchoudhury@att.com Email: gchoudhury@att.com
Christian Martin Christian Martin
Verizon iPath Technologies
1880 Campus Commons Drive
Reston, VA 20191 Email: chris@ipath.net
USA
Brent Imhoff Brent Imhoff
LightCore Juniper Networks
14567 North Outer Forty Rd. 1194 North Mathilda
Chesterfield, MO 63017 Sunnyvale, CA 94089
USA USA
Phone: +1 314 880 1851 Phone: +1 314 378 2571
Email: brent@lightcore.net Email: bimhoff@planetspork.com
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park 600 Technology Park
Billerica, MA 01821 Billerica, MA 01821
USA USA
Phone: +1 978 288 3041 Phone: +1 978 288 3041
Email: dwfedyk@nortelnetworks.com Email: dwfedyk@nortelnetworks.com
skipping to change at page 26, line 41 skipping to change at page 26, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 25 change blocks. 
68 lines changed or deleted 83 lines changed or added

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