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