draft-ietf-mpls-ldp-restart-applic-01.txt   rfc3612.txt 
Network Working Group Adrian Farrel
Internet Draft Movaz Networks
Category: Informational
Expiration Date: November 2003 June 2003
Applicability Statement for Restart Mechanisms for the Network Working Group A. Farrel
Label Distribution Protocol Request for Comments: 3612 Old Dog Consulting
Category: Informational September 2003
draft-ietf-mpls-ldp-restart-applic-01.txt Applicability Statement for Restart Mechanisms
for the Label Distribution Protocol (LDP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026 [RFC2026]. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright (C) The Internet Society (2003). All Rights Reserved.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document provides guidance on when it is advisable to implement
http://www.ietf.org/shadow.html. some form of Label Distribution Protocol (LDP) restart mechanism and
which approach might be more suitable. The issues and extensions
described in this document are equally applicable to RFC 3212,
"Constraint-Based LSP Setup Using LDP".
Abstract 1. Introduction
Multiprotocol Label Switching (MPLS) systems will be used in core Multiprotocol Label Switching (MPLS) systems are used in core
networks where system downtime must be kept to a minimum. Similarly, networks where system downtime must be kept to a minimum. Similarly,
where MPLS is at the network edges (for example, in Provider Edge where MPLS is at the network edges (e.g., in Provider Edge (PE)
routers) system downtime must also be kept as small as possible. routers) [RFC2547], system downtime must also be kept to a minimum.
Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Many MPLS Label Switching Routers (LSRs) may, therefore, exploit
Fault Tolerant (FT) hardware or software to provide high availability Fault Tolerant (FT) hardware or software to provide high availability
of the core networks. of the core networks.
The details of how FT is achieved for the various components of an The details of how FT is achieved for the various components of an FT
FT LSR, including the switching hardware and the TCP stack are LSR, including the switching hardware and the TCP stack, are
implementation specific. How the software module itself chooses to implementation specific. How the software module itself chooses to
implement FT for the state created by the Label Distribution Protocol implement FT for the state created by the LDP is also implementation
(LDP) is also implementation specific but there are several issues in specific. However, there are several issues in the LDP specification
the LDP specification in RFC 3036 "LDP Specification" that make it [RFC3036] that make it difficult to implement an FT LSR using the LDP
difficult to implement an FT LSR using the LDP protocols without some protocols without some extensions to those protocols.
extensions to those protocols.
Proposals have been made in RFC 3479 "Fault Tolerance for the Label
Distribution Protocol (LDP)" and RFC 3478 "Graceful Restart Mechanism
for LDP" to address these issues.
This document gives guidance on when it is advisable to implement
some form of LDP restart mechanism and which approach might be more
suitable. The issues and extensions described here are equally
applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP"
(CR-LDP).
1. Requirements of an LDP FT System
MPLS is a technology that will be used in core networks where system Proposals have been made in [RFC3478] and [RFC3479] to address these
downtime must be kept to an absolute minimum. Similarly, where MPLS issues.
is at the network edges (for example, in PE routers in RFC2547)
system downtime must also be kept as small as possible.
Many MPLS LSRs may, therefore, exploit FT hardware or software to 2. Requirements of an LDP FT System
provide high availability (HA) of core networks.
In order to provide HA, an MPLS system needs to be able to survive a Many MPLS LSRs may exploit FT hardware or software to provide high
variety of faults with minimal disruption to the Data Plane, availability (HA) of core networks. In order to provide HA, an MPLS
including the following fault types: system needs to be able to survive a variety of faults with minimal
disruption to the Data Plane, including the following fault types:
- failure/hot-swap of the switching fabric in an LSR - failure/hot-swap of the switching fabric in an LSR,
- failure/hot-swap of a physical connection between LSRs - failure/hot-swap of a physical connection between LSRs,
- failure of the TCP or LDP stack in an LSR - failure of the TCP or LDP stack in an LSR,
- software upgrade to the TCP or LDP stacks in an LSR. - software upgrade to the TCP or LDP stacks in an LSR.
The first two examples of faults listed above may be confined to the The first two examples of faults listed above may be confined to the
Data Plane in which case such faults can be handled by providing Data Plane. Such faults can be handled by providing redundancy in
redundancy in the Data Plane which is transparent to LDP operating in the Data Plane which is transparent to LDP operating in the Control
the Control Plane. However, the failure of the switching fabric or a Plane. However, the failure of the switching fabric or a physical
physical link may have repercussions in the Control Plane since link may have repercussions in the Control Plane since signaling may
signaling may be disrupted. be disrupted.
The third example may be caused by a variety of events including The third example may be caused by a variety of events including
processor or other hardware failure, and software failure. processor or other hardware failure, and software failure.
Any of the last three examples may impact the Control Plane and will Any of the last three examples may impact the Control Plane and will
require action in the Control Plane to recover. Such action should require action in the Control Plane to recover. Such action should
be designed to avoid disrupting traffic in the Data Plane. This is be designed to avoid disrupting traffic in the Data Plane. Since
possible because many recent router architectures separate the many recent router architectures can separate the Control and Data
Control and Data Planes such that forwarding can continue unaffected Planes, it is possible that forwarding can continue unaffected by
by recovery action in the Control Plane. recovery action in the Control Plane.
In other scenarios, the Data and Control Planes may be impacted by a In other scenarios, the Data and Control Planes may be impacted by a
fault but the needs of HA require the coordinated recovery of the fault, but the needs of HA require the coordinated recovery of the
Data and Control Planes to state that existed before the fault. Data and Control Planes to a state that existed before the fault.
The provision of protection paths for MPLS LSP and the protection of The provision of protection paths for MPLS LSP and the protection of
links, IP routes or tunnels through the use of protection LSPs is links, IP routes or tunnels through the use of protection LSPs is
outside the scope of this document. See [MPLS-RECOV] for further outside the scope of this document. See [RFC3469] for further
information on this subject. information.
2. General Considerations 3. General Considerations
In order that the Data and Control Plane states may be successfully In order for the Data and Control Plane states to be successfully
recovered after a fault, procedures are required to ensure that the recovered after a fault, procedures are required to ensure that the
state held on a pair of LDP peers (at least one of which was affected state held on a pair of LDP peers (at least one of which was affected
directly by the fault) are synchronized. Such procedures must be directly by the fault) are synchronized. Such procedures must be
implemented in the Control Plane software modules on the peers using implemented in the Control Plane software modules on the peers using
Control Plane protocols. Control Plane protocols.
The required actions may be operate fully after the failure The required actions may operate fully after the failure (reactive
(reactive recovery) or may contain elements that operate before the recovery) or may contain elements that operate before the fault in
fault in order to minimize the actions taken after the fault order to minimize the actions taken after the fault (proactive
(proactive recovery). It is rarely feasible to implement actions that recovery). It is rare to implement actions that operate solely in
operate solely in advance of the failure and do not require any advance of the failure and do not require any further processing
further processing after the failure (preventive recovery) - this is after the failure (preventive recovery) - this is because of the
because of the dynamic nature of signaling protocols and the dynamic nature of signaling protocols and the unpredictability of
unpredictability of fault timing. fault timing.
Reactive recovery actions may include full re-signaling of state, Reactive recovery actions may include full re-signaling of state and
re-synchronization of state between peers and synchronization based on re-synchronization of state between peers and synchronization based
checkpointing. on checkpointing.
Proactive recovery actions may include hand-shaking state transitions Proactive recovery actions may include hand-shaking state transitions
and checkpointing. and checkpointing.
3. Specific Issues with the LDP Protocol 4. Specific Issues with the LDP Protocol
LDP uses TCP to provide reliable connections between LSRs over which LDP uses TCP to provide reliable connections between LSRs to exchange
to exchange protocol messages to distribute labels and to set up protocol messages to distribute labels and to set up LSPs. A pair of
LSPs. A pair of LSRs that have such a connection are referred to as LSRs that have such a connection are referred to as LDP peers.
LDP peers.
TCP enables LDP to assume reliable transfer of protocol messages. TCP enables LDP to assume reliable transfer of protocol messages.
This means that some of the messages do not need to be acknowledged This means that some of the messages do not need to be acknowledged
(for example, Label Release). (e.g., Label Release).
LDP is defined such that if the TCP connection fails, the LSR should LDP is defined such that if the TCP connection fails, the LSR should
immediately tear down the LSPs associated with the session between immediately tear down the LSPs associated with the session between
the LDP peers, and release any labels and resources assigned to those the LDP peers, and release any labels and resources assigned to those
LSPs. LSPs.
It is notoriously hard to provide a Fault Tolerant implementation of It is notoriously difficult to provide a Fault Tolerant
TCP. To do so might involve making copies of all data sent and implementation of TCP. To do so might involve making copies of all
received. This is an issue familiar to implementers of other TCP data sent and received. This is an issue familiar to implementers of
applications such as BGP. other TCP applications, such as BGP.
During failover affecting the TCP or LDP stacks, therefore, the TCP During failover affecting the TCP or LDP stacks, therefore, the TCP
connection may be lost. Recovery from this position is made worse by connection may be lost. Recovery from this position is made worse by
the fact that LDP control messages may have been lost during the the fact that LDP control messages may have been lost during the
connection failure. Since these messages are unconfirmed, it is connection failure. Since these messages are unconfirmed, it is
possible that LSP or label state information will be lost. possible that LSP or label state information will be lost.
The solution to this problem must at the very least include a change At the very least, the solution to this problem must include a change
to the basic requirements of LDP so that the failure of an LDP to the basic requirements of LDP so that the failure of an LDP
session does not require that associated LDP or forwarding state be session does not require that associated LDP or forwarding state be
torn down. torn down.
Any changes made to LDP in support of recovery processing must meet Any changes made to LDP in support of recovery processing must meet
the following requirements: the following requirements:
- offer backward-compatibility with LSRs that do not implement the - offer backward-compatibility with LSRs that do not implement the
extensions to LDP extensions to LDP,
- preserve existing protocol rules described in [RFC3036] for - preserve existing protocol rules described in [RFC3036] for
handling unexpected duplicate messages and for processing handling unexpected duplicate messages and for processing
unexpected messages referring to unknown LSPs/labels. unexpected messages referring to unknown LSPs/labels.
Ideally, any solution applicable to LDP should be equally applicable Ideally, any solution applicable to LDP should be equally applicable
to CR-LDP. to CR-LDP.
4. Summary of the Features of LDP FT 5. Summary of the Features of LDP FT
LDP Fault Tolerance extensions are described in [RFC3479]. This LDP Fault Tolerance extensions are described in [RFC3479]. This
approach involves: approach involves:
- negotiation between LDP peers of the intent to support extensions - negotiation between LDP peers of the intent to support extensions
to LDP that facilitate recovery from failover without loss of LSPs to LDP that facilitate recovery from failover without loss of
LSPs,
- selection of FT survival on a per LSP/label basis or for all labels - selection of FT survival on a per LSP/label basis or for all
on a session labels on a session,
- sequence numbering of LDP messages to facilitate acknowledgement - sequence numbering of LDP messages to facilitate acknowledgement
and checkpointing and checkpointing,
- acknowledgement of LDP messages to ensure that a full handshake is - acknowledgement of LDP messages to ensure that a full handshake is
performed on those messages either frequently (such as per message) performed on those messages either frequently (such as per
or less frequently as in checkpointing message) or less frequently as in checkpointing,
- solicitation of up-to-date acknowledgement (checkpointing) of - solicitation of up-to-date acknowledgement (checkpointing) of
previous LDP messages to ensure the current state is secured, with previous LDP messages to ensure the current state is secured, with
an additional option that allows an LDP partner to request that an additional option that allows an LDP partner to request that
state is flushed in both directions if graceful shutdown is state is flushed in both directions if graceful shutdown is
required required,
- a timer to control for how long LDP and forwarding state should
be retained after LDP session failure before being discarded if
LDP communications are not re-established
- a timer to control how long LDP and forwarding state should be
retained after the LDP session failure, but before being discarded
if LDP communications are not re-established,
- exchange of checkpointing information on LDP session recovery to - exchange of checkpointing information on LDP session recovery to
establish what state has been retained by recovering LDP peers establish what state has been retained by recovering LDP peers,
- re-issuing lost messages after failover to ensure that LSP/label - re-issuing lost messages after failover to ensure that LSP/label
state is correctly recovered after reconnection of the LDP session. state is correctly recovered after reconnection of the LDP
session.
The FT procedures in [RFC3479] concentrate on the preservation of The FT procedures in [RFC3479] concentrate on the preservation of
label state for labels exchanged between a pair of adjacent LSRs when label state for labels exchanged between a pair of adjacent LSRs when
the TCP connection between those LSRs is lost. There is no intention the TCP connection between those LSRs is lost. There is no intention
within these procedures to support end-to-end protection for LSPs. within these procedures to support end-to-end protection for LSPs.
5. Summary of the Features of LDP Graceful Restart 6. Summary of the Features of LDP Graceful Restart
LDP graceful restart extensions are defined in [RFC3478]. This LDP graceful restart extensions are defined in [RFC3478]. This
approach involves: approach involves:
- negotiation between LDP peers of the intent to support extensions - negotiation between LDP peers of the intent to support extensions
to LDP that facilitate recovery from failover without loss of LSPs to LDP that facilitate recovery from failover without loss of
LSPs,
- a mechanism whereby an LSR that restarts can relearn LDP state - a mechanism whereby an LSR that restarts can relearn LDP state by
by resynchronization with its peers resynchronization with its peers,
- use of the same mechanism to allow LSRs recovering from an LDP - use of the same mechanism to allow LSRs recovering from an LDP
session failure to resynchronize LDP state with their peers session failure to resynchronize LDP state with their peers
provided that at least one of the LSRs has retained state across provided that at least one of the LSRs has retained state across
the failure or has itself resynchronized state with its peers the failure or has itself resynchronized state with its peers,
- a timer to control for how long LDP and forwarding state should - a timer to control how long LDP and forwarding state should be
be retained after LDP session failure before being discarded if retained after the LDP session failure, but before being discarded
LDP communications are not re-established if LDP communications are not re-established,
- a timer to control the length of the period during which - a timer to control the length of the resynchronization period
resynchronization of state between adjacent peers should be between adjacent peers should be completed.
completed
The procedures in [RFC3478] are applicable to all LSRs, both The procedures in [RFC3478] are applicable to all LSRs, both those
those with the ability to preserve forwarding state during LDP with the ability to preserve forwarding state during LDP restart and
restart and those without. An LSRs that can not preserve its MPLS those without. LSRs that can not preserve their MPLS forwarding
forwarding state across the LDP restart would impact MPLS traffic state across the LDP restart would impact MPLS traffic during
during restart, but by implementing a subset of the mechanisms in restart. However, by implementing a subset of the mechanisms in
[RFC3478] it can minimize the impact if their neighbor(s) are [RFC3478] they can minimize the impact if their neighbor(s) are
capable of preserving their forwarding state across the restart of capable of preserving their forwarding state across the restart of
their LDP sessions or control planes by implementing the mechanism their LDP sessions or control planes by implementing the mechanism in
in [RFC3478]. [RFC3478].
6. Applicability Considerations 7. Applicability Considerations
This section considers the applicability of fault tolerance schemes This section considers the applicability of fault tolerance schemes
within LDP networks and considers issues that might lead to the within LDP networks and considers issues that might lead to the
choice of one method or another. Many of the points raised below choice of one method or another. Many of the points raised below
should be viewed as implementation issues rather than specific should be viewed as implementation issues rather than specific
drawbacks of either solution. drawbacks of either solution.
6.1 General Applicability 7.1. General Applicability
The procedures described in [RFC3479] and [RFC3478] are intended The procedures described in [RFC3478] and [RFC3479] are intended to
to cover two distinct scenarios. In Session Failure the LDP peers at cover two distinct scenarios. In Session Failure, the LDP peers at
the ends of a session remain active, but the session fails and is the ends of a session remain active, but the session fails and is
restarted. Note that session failure does not imply failure of the restarted. Note that session failure does not imply failure of the
data channel even when using an in-band control channel. In Node data channel even when using an in-band control channel. In Node
Failure the session fails because one of the peers has been restarted Failure, the session fails because one of the peers has been
(or at least, the LDP component of the node has been restarted). restarted (or at least, the LDP component of the node has been
These two scenarios have different implications for the ease of restarted). These two scenarios have different implications for the
retention of LDP state within an individual LSR, and are described in ease of retention of LDP state within an individual LSR, and are
sections below. described in sections below.
These techniques are only applicable in LDP networks where at least These techniques are only applicable in LDP networks where at least
one LSR has the capability to retain LDP signaling state and the one LSR has the capability to retain LDP signaling state and the
associated forwarding state across LDP session failure and recovery. associated forwarding state across LDP session failure and recovery.
In [RFC3478] the LSRs retaining state do not need to be adjacent In [RFC3478], the LSRs retaining state do not need to be adjacent to
to the failed LSR or session. the failed LSR or session.
If traffic is not to be impacted, both LSRs at the ends of an LDP If traffic is not to be impacted, both LSRs at the ends of an LDP
session must at least preserve forwarding state. Preserving LDP state session must at least preserve forwarding state. Preserving LDP
is not a requirement to preserve traffic. state is not a requirement to preserve traffic.
[RFC3479] requires that the LSRs at both ends of the session implement [RFC3479] requires that the LSRs at both ends of the session
the procedures that is describes. Thus, either traffic is preserved implement the procedures that it describes. Thus, either traffic is
and recovery resynchronizes state, or no traffic is preserved and the preserved and recovery resynchronizes state, or no traffic is
LSP fails. preserved and the LSP fails.
Further, to use the procedures of [RFC3479] to recover state on a Further, to use the procedures of [RFC3479] to recover state on a
session both LSRs must have a mechanism for maintaining some session, both LSRs must have a mechanism for maintaining some session
session state and a way of auditing the forwarding state and the state and a way of auditing the forwarding state and the
resynhcronized control state. resynhcronized control state.
[RFC3478] is scoped to support preservation of traffic if both [RFC3478] is scoped to support preservation of traffic if both LSRs
LSRs implement the procedures that it describes. Additionally, it implement the procedures that it describes. Additionally, it
functions if only one LSR on the failed session supports retention of functions if only one LSR on the failed session supports retention of
forwarding state, and implements the mechanisms in the document - in forwarding state, and implements the mechanisms in the document. In
this case traffic will be impacted by the session failure, but the this case, traffic will be impacted by the session failure, but the
forwarding state will be recovered on session recovery. Further, in forwarding state will be recovered on session recovery. Further, in
the event of simultaneous failures, [RFC3478] is capable of the event of simultaneous failures, [RFC3478] is capable of
relearning and redistributing state across multiple LSRs by combining relearning and redistributing state across multiple LSRs by combining
its mechanisms with the usual LDP message exchanges of [RFC 3036]. its mechanisms with the usual LDP message exchanges of [RFC 3036].
6.2 Session Failure 7.2. Session Failure
In Session Failure an LDP session between two peers fails and is In Session Failure, an LDP session between two peers fails and is
restarted. There is no restart of the LSRs at either end of the restarted. There is no restart of the LSRs at either end of the
session and LDP continues to function on those nodes. session and LDP continues to function on those nodes.
In these cases, it is simple for LDP implementations to retain LDP In these cases, it is simple for LDP implementations to retain the
state associated with the failed session and to associate the state LDP state associated with the failed session and to associate the
with the new session when it is established. Housekeeping may be state with the new session when it is established. Housekeeping may
applied to determine that the failed session is not returning and to be applied to determine that the failed session is not returning and
release the old LDP state. Both [RFC3479] and [RFC3478] handle to release the old LDP state. Both [RFC3478] and [RFC3479] handle
this case. this case.
Applicability of [RFC3479] and [RFC3478] to the Session Failure Applicability of [RFC3478] and [RFC3479] to the Session Failure
scenario should be considered with respect to the availability of the scenario should be considered with respect to the availability of the
data plane. data plane.
In some cases the failure of the LDP session may be independent of In some cases the failure of the LDP session may be independent of
any failure of the physical (or virtual) link(s) between adjacent any failure of the physical (or virtual) link(s) between adjacent
peers; for example, it might represent a failure of the TCP/IP stack. peers; for example, it might represent a failure of the TCP/IP stack.
In these cases the data plane is not impacted and both [RFC3479] and In these cases, the data plane is not impacted and both [RFC3478] and
[RFC3478] are applicable to preserve or restore LDP state. [RFC3479] are applicable to preserve or restore LDP state.
LDP signaling may also operate out of band; that is, it may use LDP signaling may also operate out of band; that is, it may use
different links from the data plane. In this case, a failure of the different links from the data plane. In this case, a failure of the
LDP session may be a result of a failure of the control channel, but LDP session may be a result of a failure of the control channel, but
there is no implied failure of the data plane. For this scenario there is no implied failure of the data plane. For this scenario
[RFC3479] and [RFC3478] are both applicable to preserve or restore [RFC3478] and [RFC3479] are both applicable to preserve or restore
LDP state. LDP state.
In the case where the failure of the LDP session also implies the In the case where the failure of the LDP session also implies the
failure of the data plane it may be an implementation decision failure of the data plane, it may be an implementation decision
whether LDP peers retain forwarding state, and for how long. In such whether LDP peers retain forwarding state, and for how long. In such
situations, if forwarding state is retained, and if the LDP session situations, if forwarding state is retained, and if the LDP session
is re-established, both [RFC3479] and [RFC3478] are applicable to is re-established, both [RFC3478] and [RFC3479] are applicable to
preserve or restore LDP state. preserve or restore LDP state.
When the data plane has been disrupted an objective of a recovery When the data plane has been disrupted an objective of a recovery
implementation might be to restore data traffic as quickly as implementation might be to restore data traffic as quickly as
possible. possible.
6.3 Controlled Session Failure 7.3. Controlled Session Failure
In some circumstances the LSRs may know in advance that an LDP In some circumstances, the LSRs may know in advance that an LDP
session is going fail - perhaps a link is going to be taken out of session is going fail (e.g., perhaps a link is going to be taken out
service. of service).
[RFC 3036] includes provision for controlled shutdown of a session. [RFC 3036] includes provision for controlled shutdown of a session.
[RFC3479] and [RFC3478] allow resynchronization of LDP state upon [RFC3478] and [RFC3479] allow resynchronization of LDP state upon
re-establishment of the session. re-establishment of the session.
[RFC3479] offers the facility to both checkpoint all state before the [RFC3479] offers the facility to both checkpoint all LDP states
shut-down, and to quiesce the session so that no new state changes before the shut-down, and to quiesce the session so that no new state
are attempted between the checkpoint and the shut-down. This means changes are attempted between the checkpoint and the shut-down. This
that on recovery, resynchronization is simple and fast. means that on recovery, resynchronization is simple and fast.
[RFC3478] resynchronizes all state on recovery regardless of the [RFC3478] resynchronizes all state on recovery regardless of the
nature of the shut-down. nature of the shut-down.
6.4 Node Failure 7.4. Node Failure
Node Failure describes events where a whole node is restarted or Node Failure describes events where a whole node is restarted or
where the component responsible for LDP signaling is restarted. Such where the component responsible for LDP signaling is restarted. Such
an event will be perceived by the LSR's peers as session failure, but an event will be perceived by the LSR's peers as session failure, but
the restarting node sees the restart as full re-initialization. the restarting node sees the restart as full re-initialization.
The basic requirement is that forwarding state is retained otherwise The basic requirement is that the forwarding state is retained,
the data plane will necessarily be interrupted. If forwarding state otherwise the data plane will necessarily be interrupted. If
is not retained, it may be relearned from saved control state in forwarding state is not retained, it may be relearned from the saved
[RFC3479]. [RFC3478] does not utilize or expect saved control control state in [RFC3479]. [RFC3478] does not utilize or expect a
state, and if a node restarts without preserved forwarding state it saved control state. If a node restarts without preserved forwarding
informs its neighbors which immediately delete all label-FEC bindings state it informs its neighbors, which immediately delete all label-
previously received from the restarted node. FEC bindings previously received from the restarted node.
The ways to retain forwarding and control state are numerous and The ways to retain a forwarding and control state are numerous and
implementation specific, and it is not the purpose of this document implementation specific. It is not the purpose of this document to
to espouse one mechanism or another nor even to suggest how this espouse one mechanism or another, nor even to suggest how this might
might be done. If state has been preserved across the restart, be done. If state has been preserved across the restart,
synchronization with peers can be carried out as though recovering synchronization with peers can be carried out as though recovering
from Session Failure as in the previous section. Both [RFC3479] and from Session Failure as in the previous section. Both [RFC3478] and
[RFC3478] support this case. [RFC3479] support this case.
How much control state is retained is largely an implementation How much control state is retained is largely an implementation
choice, but [RFC3479] requires that at least small amount of per- choice, but [RFC3479] requires that at least small amount of per-
session control state be retained. [RFC3478] does not require session control state be retained. [RFC3478] does not require or
or expect control state to be retained. expect control state to be retained.
It is also possible that the restarting LSR has not preserved any It is also possible that the restarting LSR has not preserved any
state. In this case [RFC3479] is of no help. [RFC3478] however state. In this case, [RFC3479] is of no help. [RFC3478] however,
allows the restarting LSR to relearn state from each adjacent peer allows the restarting LSR to relearn state from each adjacent peer
through the processes for resynchronizing after Session Failure. through the processes for resynchronizing after Session Failure.
Further, in the event of simultaneous failure of multiple adjacent Further, in the event of simultaneous failure of multiple adjacent
nodes, the nodes at the edge of the failure zone can recover state nodes, the nodes at the edge of the failure zone can recover state
from their active neighbors and distribute it to the other recovering from their active neighbors and distribute it to the other recovering
LSRs without any failed LSR having to have saved state. LSRs without any failed LSR having to have saved state.
6.5 Controlled Node Failure 7.5. Controlled Node Failure
In some cases (hardware repair, software upgrade, etc.) node failure In some cases (hardware repair, software upgrade, etc.), node failure
may be predictable. In these cases all sessions with peers may be may be predictable. In these cases all sessions with peers may be
shutdown and existing state retention may be enhanced by special shutdown and existing state retention may be enhanced by special
actions. actions.
[RFC3479] checkpointing and quiesce may be applied to all sessions [RFC3479] checkpointing and quiesce may be applied to all sessions so
so that state is up-to-date. that state is up-to-date.
As above, [RFC3478] does not require that state is retained by As above, [RFC3478] does not require that state is retained by the
the restarting node, but can utilize it if it is. restarting node, but can utilize it if it is.
6.6 Speed of Recovery 7.6. Speed of Recovery
Speed of recovery is impacted by the amount of signaling required. Speed of recovery is impacted by the amount of signaling required.
If forwarding state is preserved on both LSRs on the failed session If forwarding state is preserved on both LSRs on the failed session,
then the recovery time is constrained by the time to resynchronize then the recovery time is constrained by the time to resynchronize
the state between the two LSRs. the state between the two LSRs.
[RFC3479] may resynchronize very quickly. In a stable network this [RFC3479] may resynchronize very quickly. In a stable network, this
resolves to a handshake of a checkpoint. At the most, resolves to a handshake of a checkpoint. At the most,
resynchronization involves this handshake plus an exchange of resynchronization involves this handshake plus an exchange of
messages to handle state changes since the checkpoint was taken. messages to handle state changes since the checkpoint was taken.
Implementations that support only the periodic checkpointing subset Implementations that support only the periodic checkpointing subset
of [RFC3479] are more likely to have additional state to of [RFC3479] are more likely to have additional state to
resynchronize. resynchronize.
[RFC3478] must resynchronize state for all label mappings that [RFC3478] must resynchronize state for all label mappings that have
have been retained. At the same time, resources that have be retained been retained. At the same time, resources that have been retained
by a restarting upstream LSR but are not actually required because by a restarting upstream LSR but are not actually required, because
they have been released by the downstream LSR (perhaps because it was they have been released by the downstream LSR (perhaps because it was
in the process of releasing the state) must be held for the full in the process of releasing the state), they must be held for the
resynchronization time to ensure that they are not needed. full resynchronization time to ensure that they are not needed.
The impact of recovery time will vary according to the use of the The impact of recovery time will vary according to the use of the
network. Both [RFC3479] and [RFC3478] allow advertisement of new network. Both [RFC3478] and [RFC3479] allow advertisement of new
labels while resynchronization is in progress. Issues to consider are labels while resynchronization is in progress. Issues to consider
re-availability of falsely retained resources and conflict between are re-availability of falsely retained resources and conflict
retained label mappings and newly advertised ones since this may between retained label mappings and newly advertised ones. This may
cause incorrect forwarding of data - since labels are advertised cause incorrect forwarding of data (since labels are advertised from
from downstream, an LSR upstream of a failure may continue to downstream), an LSR upstream of a failure may continue to forward
forward data for one FEC on an old label while the recovering data for one FEC on an old label while the recovering downstream LSR
downstream LSR might re-assign that label to another FEC and might re-assign that label to another FEC and advertise it. For this
advertise it. For this reason, restarting LSRs may choose to not reason, restarting LSRs may choose to not advertise new labels until
advertise new labels until resynchronization with their peers has resynchronization with their peers has completed, or may decide to
completed, or may decide to use special techniques to cover the short use special techniques to cover the short period of overlap between
period of overlap between resynchronization and new LSP setup. resynchronization and new LSP setup.
6.7 Scalability 7.7. Scalability
Scalability is largely the same issue as speed of recovery and is Scalability is largely the same issue as speed of recovery and is
governed by the number of LSPs managed through the failed session(s). governed by the number of LSPs managed through the failed session(s).
Note that there are limits to how small the resynchronization time in Note that there are limits to how small the resynchronization time in
[RFC3478] may be made given the capabilities of the LSRs, the [RFC3478] may be made given the capabilities of the LSRs, the
throughput on the link between them, and the number of labels that throughput on the link between them, and the number of labels that
must be resynchronized. must be resynchronized.
Impact on normal operation should also be considered. Impact on normal operation should also be considered.
[RFC3479] requires acknowledgement of all messages. These [RFC3479] requires acknowledgement of all messages. These
acknowledgements may be deferred as for checkpointing described in acknowledgements may be deferred as for checkpointing described in
section 6.4, or may be frequent. Although acknowledgements can be section 4, or may be frequent. Although acknowledgements can be
piggy-backed on other state messages, an option for frequent piggy-backed on other state messages, an option for frequent
acknowledgement is to send a message solely for the purpose of acknowledgement is to send a message solely for the purpose of
acknowledging a state change message. Such an implementation would acknowledging a state change message. Such an implementation would
clearly be unwise in a busy network. clearly be unwise in a busy network.
[RFC3478] has no impact on normal operations. [RFC3478] has no impact on normal operations.
6.8 Rate of Change of LDP State 7.8. Rate of Change of LDP State
Some networks do not show a high degree of change over time, such as Some networks do not show a high degree of change over time, such as
those using targeted LDP sessions; others change the LDP forwarding those using targeted LDP sessions; others change the LDP forwarding
state frequently, perhaps reacting to changes in routing information state frequently, perhaps reacting to changes in routing information
on LDP discovery sessions. on LDP discovery sessions.
Rate of change of LDP state exchanged over an LDP session depends Rate of change of LDP state exchanged over an LDP session depends on
on the application for which the LDP session is being used. LDP the application for which the LDP session is being used. LDP
sessions used for exchanging <FEC, label> bindings for establishing sessions used for exchanging <FEC, label> bindings for establishing
hop by hop LSPs will typically exchange state reacting to IGP hop by hop LSPs will typically exchange state reacting to IGP
changes. Such exchanges could be frequent. On the other hand changes. Such exchanges could be frequent. On the other hand, LDP
LDP sessions established for exchanging MPLS Layer 2 VPN FECs sessions established for exchanging MPLS Layer 2 VPN FECs will
will typically exhibit a smaller rate of state exchange. typically exhibit a smaller rate of state exchange.
In [RFC3479] two options exist. The first uses a frequent (up to per- In [RFC3479], two options exist. The first uses a frequent (up to
message) acknowledgement system which is most likely to be applicable per-message) acknowledgement system which is most likely to be
in a more dynamic system where it is desirable to preserve the applicable in a more dynamic system where it is desirable to preserve
maximum amount of state over a failure to reduce the level of the maximum amount of state over a failure to reduce the level of
resynchronization required and to speed the recovery time. resynchronization required and to speed the recovery time.
The second option in [RFC3479] uses a less-frequent acknowledgement The second option in [RFC3479] uses a less-frequent acknowledgement
scheme known as checkpointing. This is particularly suitable to scheme known as checkpointing. This is particularly suitable to
networks where changes are infrequent or bursty. networks where changes are infrequent or bursty.
[RFC3478] resynchronizes all state on recovery regardless of the [RFC3478] resynchronizes all state on recovery regardless of the rate
rate of change of the network before the failure. This consideration of change of the network before the failure. This consideration is
is thus not relevant to the choice of [RFC3478]. thus not relevant to the choice of [RFC3478].
6.9 Label Distribution Modes 7.9. Label Distribution Modes
Both [RFC3479] and [RFC3478] are suitable for use with Downstream Both [RFC3478] and [RFC3479] are suitable for use with Downstream
Unsolicited label distribution. Unsolicited label distribution.
[RFC3478] describes Downstream-On-Demand as an area for future [RFC3478] describes Downstream-On-Demand as an area for future study
study and is therefore not applicable for a network in which this and is therefore not applicable for a network in which this label
label distribution mode is used. It is possible that future distribution mode is used. It is possible that future examination of
examination of this issue will reveal that once a label has been this issue will reveal that once a label has been distributed in
distributed in either distribution mode, it can be redistributed either distribution mode, it can be redistributed by [RFC3478] upon
by [RFC3478] upon session recovery. session recovery.
[RFC3479] is suitable for use in a network that uses Downstream-On- [RFC3479] is suitable for use in a network that uses Downstream-On-
Demand label distribution. Demand label distribution.
In theory, and according to [RFC3036], even in networks configured to In theory, and according to [RFC3036], even in networks configured to
utilize Downstream Unsolicited label distribution, there may be utilize Downstream Unsolicited label distribution, there may be
occasions when the use of Downstream-On-Deman distribution is occasions when the use of Downstream-On-Deman distribution is
desirable. The use of the Label Request message is not prohibited in desirable. The use of the Label Request message is not prohibited in
a Downstream Unsolicited label distribution LDP network. a Downstream Unsolicited label distribution LDP network.
Opinion varies as to whether there is a practical requirement for the Opinion varies as to whether there is a practical requirement for the
use of the Label Request message in a Downstream Unsolicited label use of the Label Request message in a Downstream Unsolicited label
distribution LDP netowrk. Current deployment experience suggests that distribution LDP network. Current deployment experience suggests
there is no requirement. that there is no requirement.
6.10 Implementation Complexity 7.10. Implementation Complexity
Implementation complexity has consequences for the implementer and Implementation complexity has consequences for the implementer and
also for the deployer since complex software is more error prone and also for the deployer since complex software is more error prone and
harder to manage. harder to manage.
[RFC3479] is a more complex solution than [RFC3478]. In [RFC3479] is a more complex solution than [RFC3478]. In particular,
particular, [RFC3478] does not require any modification to the [RFC3478] does not require any modification to the normal signaling
normal signaling and processing of LDP state changing messages. and processing of LDP state changing messages.
[RFC3479] implementations may be simplified by implementing only [RFC3479] implementations may be simplified by implementing only the
the checkpointing subest of the functionality. checkpointing subset of the functionality.
6.11 Implementation Robustness 7.11. Implementation Robustness
In addition to the implication for robustness associated with In addition to the implication for robustness associated with
complexity of the solutions, consideration should be given to the complexity of the solutions, consideration should be given to the
effects of state preservation on robustness. effects of state preservation on robustness.
If state has become incorrect for whatever reason then state If state has become incorrect for whatever reason, then state
preservation may retain incorrect state. In extreme cases it may be preservation may retain incorrect state. In extreme cases, it may be
that the incorrect state is the cause of the failure in which case that the incorrect state is the cause of the failure in which case
preserving that state would be bad. preserving that state would be inappropriate.
When state is preserved, the precise amount that is retained is an When state is preserved, the precise amount that is retained is an
implementation issue. The basic requirement is that forwarding state implementation issue. The basic requirement is that forwarding state
is retained (to preserve the data path) and that that state can be is retained (to preserve the data path) and that that state can be
accessed by the LDP software component. accessed by the LDP software component.
In both solutions, if the forwarding state is incorrect and is In both solutions, if the forwarding state is incorrect and is
retained, it will continue to be incorrect. Both solutions have a retained, it will continue to be incorrect. Both solutions have a
mechanism to housekeep and free unwanted state after mechanism to housekeep and free the unwanted state after
resynchronization is complete. [RFC3478] may be better at resynchronization is complete. [RFC3478] may be better at
eradicating incorrect forwarding state because it replays all eradicating incorrect forwarding state, because it replays all
messages exchanges that caused the state to be populated. message exchanges that caused the state to be populated.
In [RFC3478] no more data than the forwarding state needs to have In [RFC3478], no more data than the forwarding state needs to have
been saved by the recovering node. All LDP state may be relearned by been saved by the recovering node. All LDP state may be relearned by
message exchanges with peers. Whether those exchanges may cause the message exchanges with peers. Whether those exchanges may cause the
same incorrect state to arise on the recovering node is an obvious same incorrect state to arise on the recovering node is an obvious
concern. concern.
In [RFC3479] the forwarding state must be supplemented by a small In [RFC3479], the forwarding state must be supplemented by a small
amount of state specific to the protocol extensions. LDP state may amount of state specific to the protocol extensions. LDP state may
be retained directly or reconstructed from the forwarding state. The be retained directly or reconstructed from the forwarding state. The
same issues apply when reconstructing state but are mitigated by the same issues apply when reconstructing state but are mitigated by the
fact that this is likely a different code path. Errors in the fact that this is likely a different code path. Errors in the
retained state specific to the protocol extensions will persist. retained state specific to the protocol extensions will persist.
6.12 Interoperability and Backward Compatibility 7.12. Interoperability and Backward Compatibility
It is important that new additions to LDP interoperate with existing It is important that new additions to LDP interoperate with existing
implementations at least in provision of the existing levels of implementations at least in provision of the existing levels of
function. function.
Both [RFC3479] and [RFC3478] do this through rules for handling Both [RFC3478] and [RFC3479] do this through rules for handling the
the absence of the FT optional negotiation object during session absence of the FT optional negotiation object during session
initialization. initialization.
Additionally, [RFC3478] is able to perform limited recovery (that Additionally, [RFC3478] is able to perform limited recovery (i.e.,
is, redistribution of state) even when only one of the participating redistribution of state) even when only one of the participating LSRs
LSRs supports the procedures. This may offer considerable advantages supports the procedures. This may offer considerable advantages in
in interoperation with legacy implementations. interoperation with legacy implementations.
6.13 Interaction With Other Label Distribution Mechanisms 7.13. Interaction With Other Label Distribution Mechanisms
Many LDP LSRs also run other label distribution mechanisms. These Many LDP LSRs also run other label distribution mechanisms. These
include management interfaces for configuration of static label include management interfaces for configuration of static label
mappings, other distinct instances of LDP, and other label mappings, other distinct instances of LDP, and other label
distribution protocols. The last example includes traffic engineering distribution protocols. The last example includes traffic
label distribution protocol that are used to construct tunnels engineering label distribution protocol that are used to construct
through which LDP LSPs are established. tunnels through which LDP LSPs are established.
As with re-use of individual labels by LDP within a restarting LDP As with re-use of individual labels by LDP within a restarting LDP
system, care must be taken to prevent labels that need to be retained system, care must be taken to prevent labels that need to be retained
by a restarting LDP session or protocol component from being used by by a restarting LDP session or protocol component from being used by
another label distribution mechanism since that might compromise another label distribution mechanism. This might compromise data
data security amongst other things. security, amongst other things.
It is a matter for implementations to avoid this issue through the It is a matter for implementations to avoid this issue through the
use of techniques such as a common label management component or use of techniques, such as a common label management component or
segmented label spaces. segmented label spaces.
6.14 Applicability to CR-LDP 7.14. Applicability to CR-LDP
CR-LDP [RFC 3212] utilizes Downstream-On-Demand label distribution. CR-LDP [RFC 3212] utilizes Downstream-On-Demand label distribution.
[RFC3478] describes Downstream-On-Demand as an area for future [RFC3478] describes Downstream-On-Demand as an area for future study
study and is therefore not applicable for CR-LDP. [RFC3479] is and is therefore not applicable for CR-LDP. [RFC3479] is suitable
suitable for use in a network entirely based on CR-LDP or in one for use in a network entirely based on CR-LDP or in one that is mixed
that is mixed between LDP and CR-LDP. between LDP and CR-LDP.
7. Security Considerations 8. Security Considerations
This document is informational and introduces no new security This document is informational and introduces no new security
concerns. concerns.
The security considerations pertaining to the original LDP protocol The security considerations pertaining to the original LDP protocol
[RFC3036] remain relevant. [RFC3036] remain relevant.
[RFC3478] introduces the possibility of additional denial-of- [RFC3478] introduces the possibility of additional denial-of- service
service attacks. All of these attacks may be countered by use of an attacks. All of these attacks may be countered by use of an
authentication scheme between LDP peers, such as the MD5-based scheme authentication scheme between LDP peers, such as the MD5-based scheme
outlined in [LDP]. outlined in [LDP].
In MPLS, a data mis-delivery security issue can arise if an LSR In MPLS, a data mis-delivery security issue can arise if an LSR
continues to use labels after expiration of the session that first continues to use labels after expiration of the session that first
caused them to be used. Both [RFC3479] and [RFC3478] are open to caused them to be used. Both [RFC3478] and [RFC3479] are open to
this issue. this issue.
8. Intellectual Property Considerations 9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 13, line 27 skipping to change at page 14, line 32
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
9. References 10. References
9.1 Normative References 10.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Revision 3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036, [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3478] Leelanivas, M., et al., Graceful Restart Mechanism for [RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful
LDP, RFC 3478, February 2003. Restart Mechanism for LDP", RFC 3478, February 2003.
[RFC3479] Farrel, A., et al., Fault Tolerance for the Label [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label
Distribution Protocol (LDP), RFC 3479, February 2003. Distribution Protocol (LDP)", RFC 3479, February 2003.
9.2 Informational References 10.2. Informative References
[MPLS-RECOV] Sharma, Hellstrand, et al., Framework for MPLS-based [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
Recovery, draft-ietf-mpls-recovery-frmwrk-07.txt, March 1999.
September 2002, work in progress.
[RFC3212] Jamoussi, B., et. al., Constraint-Based LSP Setup [RFC3212] Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu,
using LDP, RFC 3212, January 2002. R., Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty,
T. and A. Malis, "Constraint-Based LSP Setup using LDP",
RFC 3212, January 2002.
10. Acknowledgements [RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for
Multi-Protocol Label Switching (MPLS)-based Recovery",
RFC 3469, February 2003.
The author would like to thank the authors of [RFC3479] and 11. Acknowledgements
[RFC3478] for their work on fault tolerance of LDP.
Many thanks to Yakov Rekhter, Rahul Aggarwal, Manoj Leelanivas
and Andrew Malis for their considered input to this applicability
statement.
11. Author Information The author would like to thank the authors of [RFC3478] and [RFC3479]
for their work on fault tolerance of LDP. Many thanks to Yakov
Rekhter, Rahul Aggarwal, Manoj Leelanivas and Andrew Malis for their
considered input to this applicability statement.
12. Author's Address
Adrian Farrel Adrian Farrel
Movaz Networks, Inc. Old Dog Consulting
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Phone: +1 703-847-1867
Email: afarrel@movaz.com
12. Full Copyright Statement Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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