draft-ietf-mpls-ldp-ft-01.txt   draft-ietf-mpls-ldp-ft-02.txt 
MPLS WG Adrian Farrel MPLS WG Adrian Farrel
Internet Draft Paul Brittain Internet Draft Movaz Networks, Inc.
Document: draft-ietf-mpls-ldp-ft-01.txt Data Connection Ltd Document: draft-ietf-mpls-ldp-ft-02.txt
Expiration Date: August 2001 Expiration Date: October 2001 Paul Brittain
MetaSwitch Ltd
Philip Matthews Philip Matthews
Nortel Nortel
Eric Gray Eric Gray
Sandburst Sandburst
February 2001
May 2001
Fault Tolerance for LDP and CR-LDP Fault Tolerance for LDP and CR-LDP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 13 skipping to change at page 2, line 13
The extensions described here are equally applicable to CR-LDP. The extensions described here are equally applicable to CR-LDP.
Contents Contents
0. Changes from Previous Version...................................3 0. Changes from Previous Version...................................3
1. Conventions and Terminology used in this document...............3 1. Conventions and Terminology used in this document...............3
2. Introduction....................................................4 2. Introduction....................................................4
2.1 Fault Tolerance for MPLS.......................................4 2.1 Fault Tolerance for MPLS.......................................4
2.2 Issues with LDP and CR-LDP.....................................5 2.2 Issues with LDP and CR-LDP.....................................5
3. Overview of LDP FT Enhancements.................................6 3. Overview of LDP FT Enhancements.................................6
3.1 Establishing an FT LDP Session.................................6 3.1 Establishing an FT LDP Session.................................7
3.1.1 Interoperation with Non-FT LSRs.............................7 3.1.1 Interoperation with Non-FT LSRs.............................7
3.2 TCP Connection Failure.........................................7 3.2 TCP Connection Failure.........................................7
3.2.1 Detecting TCP Connection Failures............................7 3.2.1 Detecting TCP Connection Failures............................7
3.2.2 LDP Processing after Connection Failure......................7 3.2.2 LDP Processing after Connection Failure......................8
3.3 Data Forwarding During TCP Connection Failure..................8 3.3 Data Forwarding During TCP Connection Failure..................8
3.4 FT LDP Session Reconnection....................................8 3.4 FT LDP Session Reconnection....................................8
3.5 Operations on FT Labels........................................9 3.5 Operations on FT Labels........................................9
3.6 Label Space Depletion and Replenishment........................9 3.6 Label Space Depletion and Replenishment........................9
4. FT Operations..................................................10 4. FT Operations..................................................10
4.1 FT LDP Messages...............................................10 4.1 FT LDP Messages...............................................10
4.1.1 FT Label Messages...........................................10 4.1.1 FT Label Messages...........................................10
4.1.1.1 Scope of FT Labels........................................10 4.1.1.1 Scope of FT Labels........................................10
4.1.2 FT Address Messages........................................10 4.1.2 FT Address Messages........................................11
4.1.3 FT Label Resources Available Notification Messages..........11 4.1.3 FT Label Resources Available Notification Messages..........11
4.2 FT Operation ACKs.............................................11 4.2 FT Operation ACKs.............................................12
4.3 Preservation of FT State......................................12 4.3 Preservation of FT State......................................12
4.4 FT Procedure After TCP Failure................................13 4.4 FT Procedure After TCP Failure................................14
4.4.1 FT LDP Operations During TCP Failure........................14 4.4.1 FT LDP Operations During TCP Failure........................15
4.5 FT Procedure After TCP Re-connection..........................15 4.5 FT Procedure After TCP Re-connection..........................16
4.5.1 Re-Issuing FT Messages......................................15 4.5.1 Re-Issuing FT Messages......................................16
4.5.2 Interaction with CR-LDP LSP Modification....................16 4.5.2 Interaction with CR-LDP LSP Modification....................17
5. Changes to Existing Messages...................................16 5. Changes to Existing Messages...................................17
5.1 LDP Initialization Message....................................16 5.1 LDP Initialization Message....................................17
5.2 LDP Keepalive Message.........................................16 5.2 LDP Keepalive Message.........................................18
5.3 All Other LDP Session Messages................................17 5.3 All Other LDP Session Messages................................18
6. New Fields and Values..........................................17 6. New Fields and Values..........................................18
6.1 Status Codes..................................................17 6.1 Status Codes..................................................18
6.2 FT Session TLV................................................18 6.2 FT Session TLV................................................19
6.3 FT Protection TLV.............................................19 6.3 FT Protection TLV.............................................20
6.4 FT ACK TLV....................................................21 6.4 FT ACK TLV....................................................22
7. Example Use....................................................22 7. Example Use....................................................23
7.1 Session Failure and Recovery..................................23 7.1 Session Failure and Recovery..................................24
7.2 Temporary Shutdown............................................25 7.2 Temporary Shutdown............................................26
8. Security Considerations........................................26 8. Security Considerations........................................27
9. Implementation Notes...........................................27 9. Implementation Notes...........................................28
9.1 FT Recovery Support on Non-FT LSRs............................27 9.1 FT Recovery Support on Non-FT LSRs............................28
9.2 ACK generation logic..........................................27 9.2 ACK generation logic..........................................28
10. Acknowledgements..............................................27 10. Acknowledgements..............................................29
11. Intellectual Property Consideration...........................28 11. Intellectual Property Consideration...........................29
12. Full Copyright Statement......................................28 12. Full Copyright Statement......................................29
13. IANA Considerations...........................................28 13. IANA Considerations...........................................30
13.1 FT Session TLV...............................................29 13.1 FT Session TLV...............................................30
13.2 FT Protection TLV............................................29 13.2 FT Protection TLV............................................30
13.3 FT ACK TLV...................................................29 13.3 FT ACK TLV...................................................31
13.4 Status Codes.................................................29 13.4 Status Codes.................................................31
14. Authors' Addresses............................................29 14. Authors' Addresses............................................31
15. References....................................................30 15. References....................................................31
0. Changes From Version 1 to Version 2
0.Changes From Version 0 to Version 1
This section will be removed from the final version of the draft.
The following substantive changes have been made since version 0.
Referenced section numbers apply to version 1 of the draft.
3.2.1 Add brief note on processes for detecting TCP connection
Failures
3.4 Session reconnection must use the same session parameters as were
in use on the failed session.
3.6 Add a section on label space depletion and replenishment. This section to be removed before final publication.
4.1.3 Describe FT procedures for Label Resources Available 2.2 Add paragraph discussing use of this draft for recovery in non-
Notification Messages FT systems.
4.2 Explain use of "FT Seq Numbers Exhausted" status code. 3.2.2 Clarify selection of FT Reconnect Timeout value.
4.4 Recommend default value for FT Reconnection Timeout. 3.4 Explain procedure when FT Reconnect flag is 'unexpectedly' set.
6.2 Define meaning of FT Reconnection Timeout with value 0. 4.1.1.1 Explain re-use of labels from the per platform label space.
6.3 Describe how to handle a message that describes a FEC that may 4.3 Clarify that the Reconnection Timeout provides an upper limit on
have wider coverage than a single label. the preservation of state, but that other events may cause state
to be released sooner.
6.3 The sequence number 0x00000000 is invalid under all 4.4.1 Describe behavior if an LDP peer is unwilling or unable to
circumstances. Sequence numbers wrap from 0xFFFFFFFF to 0x00000001. queue operations during TCP failure.
7.1 Correct sequence numbers in example. 4.5 Describe behavior if an LDP peer is unwilling or unable to
queue operations during TCP failure.
7.2 Add example for Temporary Shutdown. 8. Text to expose security risks concerned with reuse of labels.
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
Definitions of key words and terms applicable to LDP and CR-LDP are Definitions of key words and terms applicable to LDP and CR-LDP are
inherited from [2] and [4]. inherited from [2] and [4].
The term "FT label" is introduced in this document to The term "FT label" is introduced in this document to
indicated a label for which fault tolerant operation is used. A indicated a label for which fault tolerant operation is used. A
"non-FT label" is not fault tolerant and is handled as specified in "non-FT label" is not fault tolerant and is handled as specified in
[2] and [4]. [2] and [4].
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2. Introduction 2. Introduction
High Availability (HA) is typically claimed by equipment vendors High Availability (HA) is typically claimed by equipment vendors
when their hardware achieves availability levels of at least 99.999% when their hardware achieves availability levels of at least 99.999%
(five 9s). To implement this, the equipment must be capable of (five 9s). To implement this, the equipment must be capable of
recovering from local hardware and software failures through a recovering from local hardware and software failures through a
process known as fault tolerance (FT). process known as fault tolerance (FT).
The usual approach to FT involves provisioning backup copies of The usual approach to FT involves provisioning backup copies of
hardware and software. When a primary copy fails, processing is hardware and/or software. When a primary copy fails, processing is
switched to the backup copy. This process, called failover, should switched to the backup copy. This process, called failover, should
result in minimal disruption to the Data Plane. result in minimal disruption to the Data Plane.
In an FT system, backup resources are sometimes provisioned on a In an FT system, backup resources are sometimes provisioned on a
one-to-one basis (1:1), sometimes as many-to-one (1:n), and one-to-one basis (1:1), sometimes as many-to-one (1:n), and
occasionally as many-to-many (m:n). Whatever backup provisioning is occasionally as many-to-many (m:n). Whatever backup provisioning is
made, the system must switch to the backup automatically on failure made, the system must switch to the backup automatically on failure
of the primary, and the software and hardware state in the backup of the primary, and the software and hardware state in the backup
must be set to replicate the state in the primary at the point must be set to replicate the state in the primary at the point
of failure. of failure.
skipping to change at page 5, line 54 skipping to change at page 5, line 54
- preserve existing protocol rules described in [2] and [4] for - preserve existing protocol rules described in [2] and [4] 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
- integrate with the LSP modification function described in [5] - integrate with the LSP modification function described in [5]
- avoid full state refresh solutions (such as those present in RSVP: - avoid full state refresh solutions (such as those present in RSVP:
see [6], [7] and [8]) whether they be full-time, or limited to see [6], [7] and [8]) whether they be full-time, or limited to
post-failover recovery. post-failover recovery.
Note that this draft concentrates on the preservation of label state Note that this draft concentrates on the preservation of label state
for labels exchanged between a pair of adjacent LSRs when the TCP for labels exchanged between a pair of adjacent LSRs when the TCP
connection between those LSRs is lost. The is a requirement for connection between those LSRs is lost. This is a requirement for
Fault Tolerant operation of LSPs, but a full implementation of end- Fault Tolerant operation of LSPs, but a full implementation of end-
to-end protection for LSPs requires that this is combined with other to-end protection for LSPs requires that this is combined with other
techniques that are outside the scope of this draft. techniques that are outside the scope of this draft.
In particular, this draft does not attempt to describe how to modify In particular, this draft does not attempt to describe how to modify
the routing of an LSP or the resources allocated to a label or LSP, the routing of an LSP or the resources allocated to a label or LSP,
which is covered by [5]. This draft also does not address how to which is covered by [5]. This draft also does not address how to
provide automatic layer 2/3 protection switching for a label or LSP, provide automatic layer 2/3 protection switching for a label or LSP,
which is a separate area for study. which is a separate area for study.
This specification does not preclude an implementation from
attempting (or require it to attempt) to use the FT behavior
described here to recover from a preemptive failure of a connection
on a non-FT system due to, for example, a partial system crash.
Note, however, that there are potential issues too numerous to list
here - not least the likelihood that the same crash will immediately
occur when processing the restored data.
3. Overview of LDP FT Enhancements 3. Overview of LDP FT Enhancements
The LDP FT enhancements consist of the following main elements, which The LDP FT enhancements consist of the following main elements, which
are described in more detail in the sections that follow. are described in more detail in the sections that follow.
- The presence of an FT Session TLV on the LDP Initialization - The presence of an FT Session TLV on the LDP Initialization
message indicates that an LSR supports the LDP FT enhancements on message indicates that an LSR supports the LDP FT enhancements on
this session. this session.
- An FT Reconnect Flag in the FT Session TLV indicates whether an - An FT Reconnect Flag in the FT Session TLV indicates whether an
skipping to change at page 7, line 6 skipping to change at page 7, line 21
This is done on the LDP Initialization message exchange using a new This is done on the LDP Initialization message exchange using a new
FT Session TLV. Presence of this TLV indicates that the peer wants FT Session TLV. Presence of this TLV indicates that the peer wants
to support the LDP FT enhancements on this LDP session. to support the LDP FT enhancements on this LDP session.
The LDP FT enhancements MUST be supported on an LDP session if both The LDP FT enhancements MUST be supported on an LDP session if both
LDP peers include an FT Session TLV on the LDP Initialization LDP peers include an FT Session TLV on the LDP Initialization
message. message.
If either LDP Peer does not include the FT Session TLV on the LDP If either LDP Peer does not include the FT Session TLV on the LDP
Initialization message, the LDP FT enhancements MUST NOT be Initialization message, the LDP FT enhancements MUST NOT be used
the receiving LDP peer as a serious protocol error causing the during this LDP session. Use of LDP FT enhancements by a sending
session to be torn down. LDP peer MUST be interpreted by the receiving LDP peer as a serious
protocol error causing the session to be terminated.
An LSR MAY present different FT/non-FT behavior on different TCP An LSR MAY present different FT/non-FT behavior on different TCP
connections, even if those connections are successive instantiations connections, even if those connections are successive instantiations
of the LDP session between the same LDP peers. of the LDP session between the same LDP peers.
3.1.1 Interoperation with Non-FT LSRs 3.1.1 Interoperation with Non-FT LSRs
The FT Session TLV on the LDP Initialization message carries the The FT Session TLV on the LDP Initialization message carries the
U-bit. If an LSR does not support the LDP FT enhancements, it will U-bit. If an LSR does not support the LDP FT enhancements, it will
ignore this TLV. Since such partners also do not include the FT ignore this TLV. Since such partners also do not include the FT
skipping to change at page 8, line 15 skipping to change at page 8, line 26
If the LDP FT enhancements are in use on an LDP session, both LDP If the LDP FT enhancements are in use on an LDP session, both LDP
peers SHOULD preserve state information and resources associated with peers SHOULD preserve state information and resources associated with
FT labels exchanged on the LDP session. Both LDP peers SHOULD use a FT labels exchanged on the LDP session. Both LDP peers SHOULD use a
timer to release the preserved state information and resources timer to release the preserved state information and resources
associated with FT-labels if the TCP connection is not restored associated with FT-labels if the TCP connection is not restored
within a reasonable period. The behavior when this timer expires is within a reasonable period. The behavior when this timer expires is
equivalent to the LDP session failure behavior described in [4]. equivalent to the LDP session failure behavior described in [4].
The FT Reconnection Timeout each LDP peer intends to apply to the LDP The FT Reconnection Timeout each LDP peer intends to apply to the LDP
session is carried in the FT Session TLV on the LDP Initialization session is carried in the FT Session TLV on the LDP Initialization
messages. It is RECOMMENDED that both LDP peers use the lower messages. Both LDP peers MUST use the value that corresponds to the
timeout value from the LDP Initialization exchange when setting their lesser timeout interval of the two proposed timeout values from the
reconnection timer after a TCP connection failure. LDP Initialization exchange, where a value of zero is treated as
positive infinity.
3.3 Data Forwarding During TCP Connection Failure 3.3 Data Forwarding During TCP Connection Failure
An LSR that implements the LDP FT enhancements SHOULD preserve the An LSR that implements the LDP FT enhancements SHOULD preserve the
programming of the switching hardware across a failover. This programming of the switching hardware across a failover. This
ensures that data forwarding is unaffected by the state of the TCP ensures that data forwarding is unaffected by the state of the TCP
connection between LSRs. connection between LSRs.
It is an integral part of FT failover processing in some hardware It is an integral part of FT failover processing in some hardware
configurations that some data packets might be lost. If data loss is configurations that some data packets might be lost. If data loss is
skipping to change at page 9, line 20 skipping to change at page 9, line 32
session before the failure. If an LDP peer notices that the session before the failure. If an LDP peer notices that the
parameters have been changed by the other peer it SHOULD send a parameters have been changed by the other peer it SHOULD send a
Notification message with the 'FT Session parameters changed' status Notification message with the 'FT Session parameters changed' status
code. code.
If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST
use the FT label operation procedures indicated in this draft to use the FT label operation procedures indicated in this draft to
complete any label operations on FT labels that were interrupted by complete any label operations on FT labels that were interrupted by
the LDP session failure. the LDP session failure.
If an LDP peer receives an LDP Initialization message with the FT
Reconnect Flag set before it sends its own Initialization message,
but has retained no information about the previous version of the
session, it MUST respond with an Initialization message with the FT
Reconnect Flag clear. If an LDP peer receives an LDP Initialization
message with the FT Reconnect Flag set in response to an
Initialization message that it has sent with the FT Reconnect Flag
clear it MUST act as if no state was retained by either peer on the
session.
3.5 Operations on FT Labels 3.5 Operations on FT Labels
Label operations on FT labels are made Fault Tolerant by providing Label operations on FT labels are made Fault Tolerant by providing
acknowledgement of all LDP messages that affect FT labels. acknowledgement of all LDP messages that affect FT labels.
Acknowledgements are achieved by means of sequence numbers on these Acknowledgements are achieved by means of sequence numbers on these
LDP messages. LDP messages.
The message exchanges used to achieve acknowledgement of label The message exchanges used to achieve acknowledgement of label
operations and the procedures used to complete interrupted label operations and the procedures used to complete interrupted label
operations are detailed in the section "FT Operations". operations are detailed in the section "FT Operations".
skipping to change at page 10, line 36 skipping to change at page 11, line 5
4.1.1.1 Scope of FT Labels 4.1.1.1 Scope of FT Labels
The scope of the FT/non-FT status of a label is limited to the The scope of the FT/non-FT status of a label is limited to the
LDP message exchanges between a pair of LDP peers. LDP message exchanges between a pair of LDP peers.
In Ordered Control, when the message is forwarded downstream or In Ordered Control, when the message is forwarded downstream or
upstream, the TLV may be present or absent according to the upstream, the TLV may be present or absent according to the
requirements of the LSR sending the message. requirements of the LSR sending the message.
If a platform-wide label space is used for FT labels, an FT label
value MUST NOT be reused until all LDP FT peers to which the label
was passed have acknowledged the withdrawal of the FT label, either
by an explicit LABEL WITHDRAW/LABEL RELEASE exchange or implicitly if
the LDP session is reconnected after failure but without the FT
Reconnect Flag set. In the event that a session is not re-
established within the Reconnection Timeout, a label MAY become
available for re-use if it is not still in use on some other
session.
4.1.2 FT Address Messages 4.1.2 FT Address Messages
If an LDP session uses the LDP FT enhancements, both LDP peers If an LDP session uses the LDP FT enhancements, both LDP peers
MUST secure Address and Address Withdraw messages using FT Operation MUST secure Address and Address Withdraw messages using FT Operation
ACKs, as described below. This avoids any ambiguity over whether ACKs, as described below. This avoids any ambiguity over whether
an Address is still valid after the LDP session is reconnected. an Address is still valid after the LDP session is reconnected.
If an LSR determines that an Address message that it sent on a If an LSR determines that an Address message that it sent on a
previous instantiation of a recovered LDP session is no longer valid, previous instantiation of a recovered LDP session is no longer valid,
it MUST explicitly issue an Address Withdraw for that address when it MUST explicitly issue an Address Withdraw for that address when
skipping to change at page 11, line 14 skipping to change at page 11, line 42
4.1.3 FT Label Resources Available Notification Messages 4.1.3 FT Label Resources Available Notification Messages
In LDP, it is possible that a downstream LSR may not have labels In LDP, it is possible that a downstream LSR may not have labels
available to respond to a Label Request. In this case, as specified available to respond to a Label Request. In this case, as specified
in RFC3036, the downstream LSR must respond with a Notification - No in RFC3036, the downstream LSR must respond with a Notification - No
Label Resources message. The upstream LSR then suspends asking for Label Resources message. The upstream LSR then suspends asking for
new labels until it receives a Notification - Label Resources new labels until it receives a Notification - Label Resources
Available message from the downstream LSR. Available message from the downstream LSR.
When the FT extensions are used on a sesssion: When the FT extensions are used on a session:
1. The downstream LSR must preserve the label availability state 1. The downstream LSR must preserve the label availability state
across a failover so that it remembers to send Notification - across a failover so that it remembers to send Notification -
Label Resources Available when the resources become available. Label Resources Available when the resources become available.
2. The upstream LSR must recall the label availability state across 2. The upstream LSR must recall the label availability state across
failover so that it can optimize not sending Label Requests when failover so that it can optimize not sending Label Requests when
it recovers. it recovers.
3. The downstream LSR must use sequence numbers on Notification - 3. The downstream LSR must use sequence numbers on Notification -
Label Resources Available so that it can check that LSR A has Label Resources Available so that it can check that LSR A has
received the message and clear its secured state, or resend the received the message and clear its secured state, or resend the
message if LSR A recovers without having received it. message if LSR A recovers without having received it.
skipping to change at page 13, line 5 skipping to change at page 13, line 36
operation if the TCP connection is interrupted. operation if the TCP connection is interrupted.
- A downstream LDP peer MUST release the resources and state - A downstream LDP peer MUST release the resources and state
information associated with an FT label when it receives an information associated with an FT label when it receives an
acknowledgement to a Label Withdraw message for the label. acknowledgement to a Label Withdraw message for the label.
- When the FT Reconnection Timeout expires, an LSR SHOULD release - When the FT Reconnection Timeout expires, an LSR SHOULD release
all state information and resources from previous instantiations all state information and resources from previous instantiations
of the (permanently) failed LDP session. of the (permanently) failed LDP session.
- Either LDP peer MAY elect to release state information based on
its internal knowledge of the loss of integrity of the state
information or an inability to pend (or queue) LDP operations
(as described in section 4.4.1) during a TCP failure. That is,
the peer is not required to wait for the duration of the FT
Reconnection Timeout before releasing state; the timeout provides
an upper limit on the persistence of state. However, In the event
that a peer releases state before the expiration of the
Reconnection Timeout it MUST NOT re-use any label that was in use
on the session until the Reconnection Timeout has expired.
- When an LSR receives a Status TLV with the E-bit set in - When an LSR receives a Status TLV with the E-bit set in
the status code, which causes it to close the TCP connection, the the status code, which causes it to close the TCP connection, the
LSR MUST release all state information and resources associated LSR MUST release all state information and resources associated
with the session. This behavior is mandated because it is with the session. This behavior is mandated because it is
impossible for the LSR to predict the precise state and future impossible for the LSR to predict the precise state and future
behavior of the partner LSR that set the E-bit without knowledge behavior of the partner LSR that set the E-bit without knowledge
of the implementation of that partner LSR. of the implementation of that partner LSR.
Note that the "Temporary Shutdown" status code does not have the Note that the "Temporary Shutdown" status code does not have the
E-bit set, and MAY be used during maintenance or upgrade E-bit set, and MAY be used during maintenance or upgrade
skipping to change at page 14, line 31 skipping to change at page 15, line 21
preserved for the failed TCP connection, so it is important that the preserved for the failed TCP connection, so it is important that the
state changes are passed to the LDP peer when the TCP connection is state changes are passed to the LDP peer when the TCP connection is
restored. restored.
If an LSR determines that it needs to issue a new FT LDP operation to If an LSR determines that it needs to issue a new FT LDP operation to
an LDP peer to which the TCP connection is currently failed, it MUST an LDP peer to which the TCP connection is currently failed, it MUST
pend the operation (e.g. on a queue) and complete that operation pend the operation (e.g. on a queue) and complete that operation
with the LDP peer when the TCP connection is restored, unless the with the LDP peer when the TCP connection is restored, unless the
label operation is overridden by a subsequent additional operation label operation is overridden by a subsequent additional operation
during the TCP connection failure (see section "FT Procedure After during the TCP connection failure (see section "FT Procedure After
TCP Re-connection") TCP Re-connection").
If, during TCP Failure, an LSR determines that it cannot pend an
operation which it cannot simply fail (for example a Label Withdraw,
Release, or Abort operation), it MUST NOT attempt to re-establish
the previous LDP session. The LSR MUST behave as if the Reconnection
Timer expired and release all state information with respect to the
LDP peer. An LSR may be unable (or unwilling) to pend operations;
for instance, if a major routing transition occurred while TCP was
inoperable between LDP peers it might result in excessively large
numbers of FT LDP Operations. An LSR that releases state before the
expiration of the Reconnection Timeout MUST NOT re-use any label that
was in use on the session until the Reconnection Timeout has expired.
In ordered operation, received FT LDP operations that cannot be In ordered operation, received FT LDP operations that cannot be
correctly forwarded because of a TCP connection failure MAY be correctly forwarded because of a TCP connection failure MAY be
processed immediately (provided sufficient state is kept to forward processed immediately (provided sufficient state is kept to forward
the label operation) or pended for processing when the onward TCP the label operation) or pended for processing when the onward TCP
connection is restored and the operation can be correctly forwarded connection is restored and the operation can be correctly forwarded
upstream or downstream. Operations on existing FT labels SHOULD NOT upstream or downstream. Operations on existing FT labels SHOULD NOT
be failed during TCP session failure. be failed during TCP session failure.
It is RECOMMENDED that Label Request operations for new FT labels are It is RECOMMENDED that Label Request operations for new FT labels are
skipping to change at page 15, line 12 skipping to change at page 16, line 12
Label Requests for new non-FT labels MUST be rejected during TCP Label Requests for new non-FT labels MUST be rejected during TCP
connection failure, as specified in [2] and [4]. connection failure, as specified in [2] and [4].
4.5 FT Procedure After TCP Re-connection 4.5 FT Procedure After TCP Re-connection
The FT operation handshaking described above means that all state The FT operation handshaking described above means that all state
changes for FT labels and Address messages are confirmed or changes for FT labels and Address messages are confirmed or
reproducible at each LSR. reproducible at each LSR.
If the TCP connection between LDP peers fails but is re-connected If the TCP connection between LDP peers fails but is re-connected
within the FT Reconnection Timeout, both LDP peers on the connection within the FT Reconnection Timeout, and both LSRs have indicated
MUST complete any label operations for FT labels that were they will be re-establishing the previous LDP session, both LDP
interrupted by the failure and re-connection of the TCP connection. peers on the connection MUST complete any label operations for FT
Label operation are completed using the procedure described below. labels that were interrupted by the failure and re-connection of
the TCP connection.
The procedures for FT Reconnection Timeout MAY have been invoked as
a result of either LDP peer being unable (or unwilling) to pend
operations which occurred during the TCP Failure (as described in
section 4.4.1).
If, for any reason, an LSR has been unable to pend operations with
respect to an LDP peer, as described in section 4.4.1, the LSR MUST
set the FT Reconnect Flag to 0 on re-connection to that LDP peer
indicating that no FT state has been preserved.
Label operations are completed using the procedure described below.
4.5.1 Re-Issuing FT Messages 4.5.1 Re-Issuing FT Messages
On restoration of the TCP connection between LDP peers, any FT On restoration of the TCP connection between LDP peers, any FT
LDP messages that were lost because of the TCP connection LDP messages that were lost because of the TCP connection
failure are re-issued. The LDP peer that receives a re-issued message failure are re-issued. The LDP peer that receives a re-issued message
processes the message as if received for the first time. processes the message as if received for the first time.
"Net-zero" combinations of messages need not be re-issued after "Net-zero" combinations of messages need not be re-issued after
re-establishment of the TCP connection between LDP peers. This leads re-establishment of the TCP connection between LDP peers. This leads
skipping to change at page 27, line 5 skipping to change at page 28, line 5
All of these attacks may be countered by use of an authentication All of these attacks may be countered by use of an authentication
scheme between LDP peers, such as the MD5-based scheme outlined in scheme between LDP peers, such as the MD5-based scheme outlined in
[4]. [4].
Alternative authentication schemes for LDP peers are outside the Alternative authentication schemes for LDP peers are outside the
scope of this draft, but could be deployed to provide enhanced scope of this draft, but could be deployed to provide enhanced
security to implementations of LDP, CR-LDP and the LDP FT security to implementations of LDP, CR-LDP and the LDP FT
enhancements. enhancements.
As with LDP and CR-LDP, a security issue may exist if an LDP
implementation continues to use labels after expiration of the
session that first caused them to be used. This may arise if the
upstream LSR detects the session failure after the downstream LSR
has released and re-used the label. The problem is most obvious
with the platform-wide label space and could result in mis-routing
of data to other than intended destinations and it is conceivable
that these behaviors may be deliberately exploited to either obtain
services without authorization or to deny services to others.
In this draft, the validity of the session may be extended by the FT
Reconnection Timeout, and the session may be re-established in this
period. After the expiry of the Reconnection Timeout the session
must be considered to have failed and the same security issue applies
as described above.
However, the downstream LSR may declare the session as failed before
the expiration of its Reconnection Timeout. This increases the
period during which the downstream LSR might reallocate the label
while the upstream LSR continues to transmit data using the old usage
of the label. To reduce this issue, this draft requires that labels
are not re-used until the Reconnection Timeout has expired.
A further issue might apply if labels were re-used prior to the
expiration of the FT Reconnection Timeout, but this is forbidden by
this draft.
9. Implementation Notes 9. Implementation Notes
9.1 FT Recovery Support on Non-FT LSRs 9.1 FT Recovery Support on Non-FT LSRs
In order to take full advantage of the FT capabilities of LSRs in the In order to take full advantage of the FT capabilities of LSRs in the
network, it may be that an LSR that does not itself contain the network, it may be that an LSR that does not itself contain the
ability to recover from local hardware or software faults still needs ability to recover from local hardware or software faults still needs
to support the LDP FT enhancements described in this draft. to support the LDP FT enhancements described in this draft.
Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant
skipping to change at page 27, line 47 skipping to change at page 29, line 24
This implementation combines the bandwidth benefits of accumulating This implementation combines the bandwidth benefits of accumulating
ACKs while still providing timely ACKs. ACKs while still providing timely ACKs.
10. Acknowledgments 10. Acknowledgments
The work in this draft is based on the LDP and CR-LDP ideas The work in this draft is based on the LDP and CR-LDP ideas
expressed by the authors of [2] and [4]. expressed by the authors of [2] and [4].
The ACK scheme used in this draft was inspired by the proposal by The ACK scheme used in this draft was inspired by the proposal by
David Ward and John Scudder for restarting BGP sessions [9]. David Ward and John Scudder for restarting BGP sessions now included
in [9].
The authors would also like to acknowledge the careful review and The authors would also like to acknowledge the careful review and
comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer, comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and
Alan Davey. Alan Davey.
11. Intellectual Property Consideration 11. Intellectual Property Consideration
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
skipping to change at page 30, line 8 skipping to change at page 31, line 32
Hence, the numeric status code values assigned for this draft should Hence, the numeric status code values assigned for this draft should
simply be the next available values at the time of writing and may be simply be the next available values at the time of writing and may be
substituted for other numeric values. substituted for other numeric values.
See section "Status Codes" for details of the status codes defined in See section "Status Codes" for details of the status codes defined in
this draft. this draft.
14. Authors' Addresses 14. Authors' Addresses
Adrian Farrel (editor) Paul Brittain Adrian Farrel (editor) Paul Brittain
Data Connection Ltd. Data Connection Ltd. Movaz Networks, Inc. Data Connection Ltd.
Windsor House Windsor House 7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,
Pepper Street Pepper Street McLean, VA 22102 Chester, Cheshire
Chester Chester Voice: +1 703-847-1719 CH1 1DF, UK
Cheshire Cheshire Email: afarrel@movaz.com Phone: +44-(0)-1244-313440
CH1 1DF CH1 1DF Fax: +44-(0)-1244-312422
UK UK Email: pjb@dataconnection.com
Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440
Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422
Email: af@dataconnection.com Email: pjb@dataconnection.com
Philip Matthews Eric Gray Philip Matthews Eric Gray
Nortel Networks Corp. Sandburst Corporation Nortel Networks Corp. Sandburst Corporation
P.O. Box 3511 Station C, 600 Federal Street P.O. Box 3511 Station C, 600 Federal Street
Ottawa, ON K1Y 4H7 Andover, MA 01810 Ottawa, ON K1Y 4H7 Andover, MA 01810
Canada Phone: +1 978-689-1600 Canada Phone: +1 978-689-1600
Phone: +1 613-768-3262 eric.gray@sandburst.com Phone: +1 613-768-3262 eric.gray@sandburst.com
philipma@nortelnetworks.com philipma@nortelnetworks.com
15. References 15. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
draft-ietf-mpls-cr-ldp-04.txt, July 2000, (work in progress). draft-ietf-mpls-cr-ldp-05.txt, February 2001, (work in progress).
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001. 4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls- 5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-
crlsp-modify-02.txt, October 2000 (work in progress). crlsp-modify-03.txt, March 2001 (work in progress).
6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- 6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification, RFC 2205, September 1997. Version 1, Functional Specification, RFC 2205, September 1997.
7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft- 7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft-
ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress). ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress).
8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft- 8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft-
ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000 (work in progress). ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2000 (work in
progress).
9 Ward, D, et al., BGP Notification Cease: I'll Be Back, 9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP,
draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress) draft-ietf-idr-restart-00.txt, December 2000 (work in progress)
10 Stewart, R, et al., Stream Control Transmission Protocol, 10 Stewart, R., et al., Stream Control Transmission Protocol,
RFC 2906, October 2000. RFC 2906, October 2000.
11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart-
00.txt, February 2001 (work in progress)
 End of changes. 

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