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/ |