draft-ietf-rtgwg-ipfrr-framework-09.txt   draft-ietf-rtgwg-ipfrr-framework-10.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: May 3, 2009 October 30, 2008 Expires: August 31, 2009 February 27, 2009
IP Fast Reroute Framework IP Fast Reroute Framework
draft-ietf-rtgwg-ipfrr-framework-09 draft-ietf-rtgwg-ipfrr-framework-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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 Internet-
Drafts. 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 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 May 3, 2009. This Internet-Draft will expire on August 31, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document provides a framework for the development of IP fast- This document provides a framework for the development of IP fast-
reroute mechanisms which provide protection against link or router reroute mechanisms which provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS failure by invoking locally determined repair paths. Unlike MPLS
Fast-reroute, the mechanisms are applicable to a network employing fast-reroute, the mechanisms are applicable to a network employing
conventional IP routing and forwarding. An essential part of such conventional IP routing and forwarding.
mechanisms is the prevention of packet loss caused by the loops which
normally occur during the re-convergence of the network following a
failure.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mechanisms for IP Fast-reroute . . . . . . . . . . . . . . . . 7 4. Mechanisms for IP Fast-reroute . . . . . . . . . . . . . . . . 7
4.1. Mechanisms for fast failure detection . . . . . . . . . . 7 4.1. Mechanisms for fast failure detection . . . . . . . . . . 7
4.2. Mechanisms for repair paths . . . . . . . . . . . . . . . 8 4.2. Mechanisms for repair paths . . . . . . . . . . . . . . . 8
4.2.1. Scope of repair paths . . . . . . . . . . . . . . . . 9 4.2.1. Scope of repair paths . . . . . . . . . . . . . . . . 9
4.2.2. Analysis of repair coverage . . . . . . . . . . . . . 9 4.2.2. Analysis of repair coverage . . . . . . . . . . . . . 9
4.2.3. Link or node repair . . . . . . . . . . . . . . . . . 10 4.2.3. Link or node repair . . . . . . . . . . . . . . . . . 10
4.2.4. Maintenance of Repair paths . . . . . . . . . . . . . 11 4.2.4. Maintenance of Repair paths . . . . . . . . . . . . . 11
4.2.5. Multiple failures and Shared Risk Link Groups . . . . 11 4.2.5. Multiple failures and Shared Risk Link Groups . . . . 11
4.3. Local Area Networks . . . . . . . . . . . . . . . . . . . 12 4.3. Local Area Networks . . . . . . . . . . . . . . . . . . . 12
4.4. Mechanisms for micro-loop prevention . . . . . . . . . . . 12 4.4. Mechanisms for micro-loop prevention . . . . . . . . . . . 12
5. Management Considerations . . . . . . . . . . . . . . . . . . 12 5. Management Considerations . . . . . . . . . . . . . . . . . . 12
6. Scope and applicability . . . . . . . . . . . . . . . . . . . 13 6. Scope and applicability . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14 10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Terminology 1. Terminology
This section defines words and acronyms used in this draft and other This section defines words and acronyms used in this draft and other
drafts discussing IP Fast-reroute. drafts discussing IP fast-reroute.
D Used to denote the destination router under D Used to denote the destination router under
discussion. discussion.
Distance_opt(A,B) The distance of the shortest path from A to B. Distance_opt(A,B) The distance of the shortest path from A to B.
Downstream Path This is a subset of the loop-free alternates Downstream Path This is a subset of the loop-free alternates
where the neighbor N meet the following where the neighbor N meets the following
condition:- condition:-
Distance_opt(N, D) < Distance_opt(S,D) Distance_opt(N, D) < Distance_opt(S,D)
E Used to denote the router which is the primary E Used to denote the router which is the primary
next-hop neighbor to get from S to the next-hop neighbor to get from S to the
destination D. Where there is an ECMP set for the destination D. Where there is an ECMP set for the
shortest path from S to D, these are referred to shortest path from S to D, these are referred to
as E_1, E_2, etc. as E_1, E_2, etc.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
RPF Reverse Path Forwarding. I.e. checking that a RPF Reverse Path Forwarding. I.e. checking that a
packet is received over the interface which would packet is received over the interface which would
be used to send packets addressed to the source be used to send packets addressed to the source
address of the packet. address of the packet.
S Used to denote a router that is the source of a S Used to denote a router that is the source of a
repair that is computed in anticipation of the repair that is computed in anticipation of the
failure of a neighboring router denoted as E, or failure of a neighboring router denoted as E, or
of the link between S and E. It is the viewpoint of the link between S and E. It is the viewpoint
from which IP Fast-Reroute is described. from which IP fast-reroute is described.
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.
SPF Shortest Path First, e.g. Dijkstra's algorithm. SPF Shortest Path First, e.g. Dijkstra's algorithm.
SPT Shortest path tree SPT Shortest path tree
Upstream Forwarding Loop Upstream Forwarding Loop
This is a forwarding loop which involves a set of This is a forwarding loop which involves a set of
routers, none of which are directly connected to routers, none of which are directly connected to
the link which has caused the topology change the link which has caused the topology change
that triggered a new SPF in any of the routers. that triggered a new SPF in any of the routers.
skipping to change at page 5, line 42 skipping to change at page 5, line 40
Addressing these issues is difficult because the distributed nature Addressing these issues is difficult because the distributed nature
of the network imposes an intrinsic limit on the minimum convergence of the network imposes an intrinsic limit on the minimum convergence
time which can be achieved. time which can be achieved.
However, there is an alternative approach, which is to compute backup However, there is an alternative approach, which is to compute backup
routes that allow the failure to be repaired locally by the router(s) routes that allow the failure to be repaired locally by the router(s)
detecting the failure without the immediate need to inform other detecting the failure without the immediate need to inform other
routers of the failure. In this case, the disruption time can be routers of the failure. In this case, the disruption time can be
limited to the small time taken to detect the adjacent failure and limited to the small time taken to detect the adjacent failure and
invoke the backup routes. This is analogous to the technique invoke the backup routes. This is analogous to the technique
employed by MPLS Fast-Reroute [RFC4090], but the mechanisms employed employed by MPLS fast-reroute [RFC4090], but the mechanisms employed
for the backup routes in pure IP networks are necessarily very for the backup routes in pure IP networks are necessarily very
different. different.
This document provides a framework for the development of this This document provides a framework for the development of this
approach. approach.
3. Problem Analysis 3. Problem Analysis
The duration of the packet delivery disruption caused by a The duration of the packet delivery disruption caused by a
conventional routing transition is determined by a number of factors: conventional routing transition is determined by a number of factors:
1. The time taken to detect the failure. This may be of the order 1. 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 of a few milliseconds when it can be detected at the physical
several tens of seconds when a routing protocol hello is layer, up to several tens of seconds when a routing protocol
employed. During this period packets will be unavoidably lost. hello is employed. During this period packets will be
unavoidably lost.
2. The time taken for the local router to react to the failure. 2. The time taken for the local router to react to the failure.
This will typically involve generating and flooding new routing This will typically involve generating and flooding new routing
updates, perhaps after some hold-down delay, and re-computing the updates, perhaps after some hold-down delay, and re-computing the
router's FIB. router's FIB.
3. The time taken to pass the information about the failure to other 3. The time taken to pass the information about the failure to other
routers in the network. In the absence of routing protocol routers in the network. In the absence of routing protocol
packet loss, this is typically between 10mS and 100mS per hop. packet loss, this is typically between 10 milliseconds and 100
milliseconds per hop.
4. The time taken to re-compute the forwarding tables. This is 4. The time taken to re-compute the forwarding tables. This is
typically a few mS for a link state protocol using Dijkstra's typically a few milliseconds for a link state protocol using
algorithm. Dijkstra's algorithm.
5. The time taken to load the revised forwarding tables into the 5. The time taken to load the revised forwarding tables into the
forwarding hardware. This time is very implementation dependant forwarding hardware. This time is very implementation dependant
and also depends on the number of prefixes affected by the and also depends on the number of prefixes affected by the
failure, but may be several hundred mS. failure, but may be several hundred milliseconds.
The disruption will last until the routers adjacent to the failure 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 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 whose paths are affected by the failure have completed the remaining
steps. steps.
The initial packet loss is caused by the router(s) adjacent to the The initial packet loss is caused by the router(s) adjacent to the
failure continuing to attempt to transmit packets across the failure failure continuing to attempt to transmit packets across the failure
until it is detected. This loss is unavoidable, but the detection until it is detected. This loss is unavoidable, but the detection
time can be reduced to a few tens of mS as described in Section 4.1. time can be reduced to a few tens of milliseconds as described in
Section 4.1.
Subsequent packet loss is caused by the "micro-loops" which form In some topologies subsequent packet loss may be caused by the
because of temporary inconsistencies between routers' forwarding "micro-loops" which may form as a result of temporary inconsistencies
tables. These occur as a result of the different times at which between routers' forwarding tables[I-D.ietf-rtgwg-lf-conv-frmwk].
routers update their forwarding tables to reflect the failure. These When micro-loops occur, this is as a result of the different times at
variable delays are caused by steps 3, 4 and 5 above and in many which routers update their forwarding tables to reflect the failure.
routers it is step 5 which is both the largest factor and which has These variable delays are caused by steps 3, 4 and 5 above and in
the greatest variance between routers. The large variance arises 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 from implementation differences and from the differing impact that a
failure has on each individual router. For example, the number of failure has on each individual router. For example, the number of
prefixes affected by the failure may vary dramatically from one prefixes affected by the failure may vary dramatically from one
router to another. router to another.
In order to achieve packet disruption times which are commensurate In order to achieve packet disruption times which are commensurate
with the failure detection times it is necessary to perform two with the failure detection times two factors must be considered:-
distinct tasks:
1. Provide a mechanism for the router(s) adjacent to the failure to 1. The provision of a mechanism for the router(s) adjacent to the
rapidly invoke a repair path, which is unaffected by any failure to rapidly invoke a repair path, which is unaffected by
subsequent re-convergence. any subsequent re-convergence.
2. Provide a mechanism to prevent the effects of micro-loops during 2. In topologies that are susceptible to micro-loops, the provision
of a mechanism to prevent the effects of any micro-loops during
subsequent re-convergence. subsequent re-convergence.
Performing the first task without the second will result in the Performing the first task without the second may result in the repair
repair path being starved of traffic and hence being redundant. path being starved of traffic and hence being redundant. Performing
Performing the second without the first will result in traffic being the second without the first will result in traffic being discarded
discarded by the router(s) adjacent to the failure. Both tasks are by the router(s) adjacent to the failure.
necessary for an effective solution to the problem.
However, repair paths can be used in isolation where the failure is Repair paths may always be used in isolation where the failure is
short-lived. The repair paths can be kept in place until the failure short-lived. In this case, the repair paths can be kept in place
is repaired and there is no need to advertise the failure to other until the failure is repaired in which case there is no need to
routers. advertise the failure to other routers.
Similarly, micro-loop avoidance can be used in isolation to prevent Similarly, micro-loop avoidance may be used in isolation to prevent
loops arising from pre-planned management action, because the link or loops arising from pre-planned management action. In which case the
node being shut down can remain in service for a short time after its link or node being shut down can remain in service for a short time
removal has been announced into the network, and hence it can after its removal has been announced into the network, and hence it
function as its own "repair path". can function as its own "repair path".
Note that micro-loops can also occur when a link or node is restored Note that micro-loops may also occur when a link or node is restored
to service and thus a micro-loop avoidance mechanism is required for to service and thus a micro-loop avoidance mechanism may be required
both link up and link down cases. for both link up and link down cases.
4. Mechanisms for IP Fast-reroute 4. Mechanisms for IP Fast-reroute
The set of mechanisms required for an effective solution to the The set of mechanisms required for an effective solution to the
problem can be broken down into the following sub-problems. problem can be broken down into the sub-problems described in this
section.
4.1. Mechanisms for fast failure detection 4.1. Mechanisms for fast failure detection
It is critical that the failure detection time is minimized. A It is critical that the failure detection time is minimized. A
number of approaches are possible, such as: number of well documented approaches are possible, such as:
1. Physical detection; for example, loss of light. 1. Physical detection; for example, loss of light.
2. Routing protocol independent protocol detection; for example, The 2. Routing protocol independent protocol detection; for example, The
Bidirectional Failure Detection protocol [I-D.ietf-bfd-base]. Bidirectional Failure Detection protocol [I-D.ietf-bfd-base].
3. Routing protocol detection; for example, use of "fast hellos". 3. Routing protocol detection; for example, use of "fast hellos".
4.2. Mechanisms for repair paths 4.2. Mechanisms for repair paths
skipping to change at page 12, line 14 skipping to change at page 12, line 14
4.3. Local Area Networks 4.3. Local Area Networks
Protection against partial or complete failure of LANs is more Protection against partial or complete failure of LANs is more
complex than the point to point case. In general there is a tradeoff complex than the point to point case. In general there is a tradeoff
between the simplicity of the repair and the ability to provide between the simplicity of the repair and the ability to provide
complete and optimal repair coverage. complete and optimal repair coverage.
4.4. Mechanisms for micro-loop prevention 4.4. Mechanisms for micro-loop prevention
Control of micro-loops is important not only because they can cause Ensuring the absence of micro-loops is important not only because
packet loss in traffic which is affected by the failure, but because they can cause packet loss in traffic which is affected by the
by saturating a link with looping packets they can also cause failure, but because by saturating a link with looping packets they
congestion loss of traffic flowing over that link which would can also cause congestion loss of traffic flowing over that link
otherwise be unaffected by the failure. which would otherwise be unaffected by the failure.
A number of solutions to the problem of micro-loop formation have A number of solutions to the problem of micro-loop formation have
been proposed and are summarized in [I-D.ietf-rtgwg-lf-conv-frmwk]. been proposed and are summarized in [I-D.ietf-rtgwg-lf-conv-frmwk].
The following factors are significant in their classification: The following factors are significant in their classification:
1. Partial or complete protection against micro-loops. 1. Partial or complete protection against micro-loops.
2. Delay imposed upon convergence. 2. Delay imposed upon convergence.
3. Tolerance of multiple failures (from node failures, and in 3. Tolerance of multiple failures (from node failures, and in
general). general).
4. Computational complexity (pre-computed or real time). 4. Computational complexity (pre-computed or real time).
5. Applicability to scheduled events. 5. Applicability to scheduled events.
6. Applicability to link/node reinstatement. 6. Applicability to link/node reinstatement.
7. Topological constraints.
5. Management Considerations 5. Management Considerations
While many of the management requirements will be specific to While many of the management requirements will be specific to
particular IPFRR solutions, the following general aspects need to be particular IPFRR solutions, the following general aspects need to be
addressed: addressed:
1. Configuration 1. Configuration
A. Enabling/disabling IPFRR support. A. Enabling/disabling IPFRR support.
B. Enabling/disabling protection on a per link/node basis. B. Enabling/disabling protection on a per link/node basis.
C. Expressing preferences regarding the links/nodes used for C. Expressing preferences regarding the links/nodes used for
repair paths. repair paths.
D. Configuration of failure detection mechanisms. D. Configuration of failure detection mechanisms.
E. Configuration of loop avoidance strategies E. Configuration of loop avoidance strategies
2. Monitoring 2. Monitoring and operational support
A. Notification of links/nodes/destinations which cannot be A. Notification of links/nodes/destinations which cannot be
protected. protected.
B. Notification of pre-computed repair paths, and anticipated B. Notification of pre-computed repair paths, and anticipated
traffic patterns. traffic patterns.
C. Counts of failure detections, protection invocations and C. Counts of failure detections, protection invocations and
packets forwarded over repair paths. packets forwarded over repair paths.
D. Testing repairs.
6. Scope and applicability 6. Scope and applicability
The initial scope of this work is in the context of link state IGPs. The initial scope of this work is in the context of link state IGPs.
Link state protocols provide ubiquitous topology information, which Link state protocols provide ubiquitous topology information, which
facilitates the computation of repairs paths. facilitates the computation of repairs paths.
Provision of similar facilities in non-link state IGPs and BGP is a Provision of similar facilities in non-link state IGPs and BGP is a
matter for further study, but the correct operation of the repair matter for further study, but the correct operation of the repair
mechanisms for traffic with a destination outside the IGP domain is mechanisms for traffic with a destination outside the IGP domain is
an important consideration for solutions based on this framework an important consideration for solutions based on this framework
skipping to change at page 14, line 23 skipping to change at page 14, line 29
draft-atlas-ip-local-protect-uturn-03 (work in progress), draft-atlas-ip-local-protect-uturn-03 (work in progress),
March 2006. March 2006.
[I-D.bryant-ipfrr-tunnels] [I-D.bryant-ipfrr-tunnels]
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
(work in progress), November 2007. (work in progress), November 2007.
[I-D.ietf-bfd-base] [I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-08 (work in progress), Detection", draft-ietf-bfd-base-09 (work in progress),
March 2008. February 2009.
[I-D.ietf-rtgwg-ipfrr-notvia-addresses] [I-D.ietf-rtgwg-ipfrr-notvia-addresses]
Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute
Using Not-via Addresses", Using Not-via Addresses",
draft-ietf-rtgwg-ipfrr-notvia-addresses-02 (work in draft-ietf-rtgwg-ipfrr-notvia-addresses-03 (work in
progress), February 2008. progress), October 2008.
[I-D.ietf-rtgwg-lf-conv-frmwk] [I-D.ietf-rtgwg-lf-conv-frmwk]
Shand, M. and S. Bryant, "A Framework for Loop-free Shand, M. and S. Bryant, "A Framework for Loop-free
Convergence", draft-ietf-rtgwg-lf-conv-frmwk-02 (work in Convergence", draft-ietf-rtgwg-lf-conv-frmwk-03 (work in
progress), February 2008. progress), October 2008.
[I-D.tian-frr-alt-shortest-path] [I-D.tian-frr-alt-shortest-path]
Tian, A., "Fast Reroute using Alternative Shortest Paths", Tian, A., "Fast Reroute using Alternative Shortest Paths",
draft-tian-frr-alt-shortest-path-01 (work in progress), draft-tian-frr-alt-shortest-path-01 (work in progress),
July 2004. July 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
skipping to change at page 16, line 4 skipping to change at line 653
Email: mshand@cisco.com Email: mshand@cisco.com
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
250, Longwater Avenue. 250, Longwater Avenue.
Reading, Berks RG2 6GB Reading, Berks RG2 6GB
UK UK
Email: stbryant@cisco.com Email: stbryant@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
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.
 End of changes. 35 change blocks. 
75 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/