draft-ietf-mpls-ldp-ft-00.txt   draft-ietf-mpls-ldp-ft-01.txt 
MPLS WG Adrian Farrel MPLS WG Adrian Farrel
Internet Draft Paul Brittain Internet Draft Paul Brittain
Document: draft-ietf-mpls-ldp-ft-00.txt Data Connection Ltd Document: draft-ietf-mpls-ldp-ft-01.txt Data Connection Ltd
Expiration Date: March 2001 Expiration Date: August 2001
Philip Matthews Philip Matthews
Nortel Nortel
Eric Gray Eric Gray
Zaffire Sandburst
October 2000 February 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 7 skipping to change at page 2, line 7
implementation specific. This document identifies issues in the implementation specific. This document identifies issues in the
CR-LDP specification [2] and the LDP specification [4] that make it CR-LDP specification [2] and the LDP specification [4] that make it
difficult to implement an FT LSR using the current LDP and CR-LDP difficult to implement an FT LSR using the current LDP and CR-LDP
protocols, and proposes enhancements to the LDP specification to ease protocols, and proposes enhancements to the LDP specification to ease
such FT LSR implementations. such FT LSR implementations.
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
1. Conventions and Terminology used in this document...............3 1. Conventions and Terminology used in this document...............3
2. Introduction....................................................3 2. Introduction....................................................4
2.1 Fault Tolerance for MPLS.......................................3 2.1 Fault Tolerance for MPLS.......................................4
2.2 Issues with LDP and CR-LDP.....................................4 2.2 Issues with LDP and CR-LDP.....................................5
3. Overview of LDP FT Enhancements.................................5 3. Overview of LDP FT Enhancements.................................6
3.1 Establishing an FT LDP Session.................................6 3.1 Establishing an FT LDP Session.................................6
3.1.1 Interoperation with Non-FT LSRs.............................6 3.1.1 Interoperation with Non-FT LSRs.............................7
3.2 TCP Connection Failure.........................................6 3.2 TCP Connection Failure.........................................7
3.3 Data Forwarding During TCP Connection Failure..................7 3.2.1 Detecting TCP Connection Failures............................7
3.4 FT LDP Session Reconnection....................................7 3.2.2 LDP Processing after Connection Failure......................7
3.5 Operations on FT Labels........................................8 3.3 Data Forwarding During TCP Connection Failure..................8
4. FT Operations...................................................8 3.4 FT LDP Session Reconnection....................................8
4.1 FT LDP Messages................................................8 3.5 Operations on FT Labels........................................9
4.1.1 FT Label Messages............................................8 3.6 Label Space Depletion and Replenishment........................9
4.1.1.1 Scope of FT Labels.........................................9 4. FT Operations..................................................10
4.1.2 FT Address Messages.........................................9 4.1 FT LDP Messages...............................................10
4.2 FT Operation ACKs..............................................9 4.1.1 FT Label Messages...........................................10
4.3 Preservation of FT State......................................10 4.1.1.1 Scope of FT Labels........................................10
4.4 FT Procedure After TCP Failure................................11 4.1.2 FT Address Messages........................................10
4.4.1 FT LDP Operations During TCP Failure........................12 4.1.3 FT Label Resources Available Notification Messages..........11
4.5 FT Procedure After TCP Re-connection..........................12 4.2 FT Operation ACKs.............................................11
4.5.1 Re-Issuing FT Messages......................................13 4.3 Preservation of FT State......................................12
4.5.2 Interaction with CR-LDP LSP Modification....................14 4.4 FT Procedure After TCP Failure................................13
5. Changes to Existing Messages...................................14 4.4.1 FT LDP Operations During TCP Failure........................14
5.1 LDP Initialization Message....................................14 4.5 FT Procedure After TCP Re-connection..........................15
5.2 LDP Keepalive Message.........................................14 4.5.1 Re-Issuing FT Messages......................................15
5.3 All Other LDP Session Messages................................15 4.5.2 Interaction with CR-LDP LSP Modification....................16
6. New Fields and Values..........................................15 5. Changes to Existing Messages...................................16
6.1 Status Codes..................................................15 5.1 LDP Initialization Message....................................16
6.2 FT Session TLV................................................16 5.2 LDP Keepalive Message.........................................16
6.3 FT Protection TLV.............................................17 5.3 All Other LDP Session Messages................................17
6.4 FT ACK TLV....................................................18 6. New Fields and Values..........................................17
7. Example Use....................................................19 6.1 Status Codes..................................................17
8. Security Considerations........................................23 6.2 FT Session TLV................................................18
9. Implementation Notes...........................................23 6.3 FT Protection TLV.............................................19
9.1 FT Recovery Support on Non-FT LSRs............................23 6.4 FT ACK TLV....................................................21
9.2 ACK generation logic..........................................24 7. Example Use....................................................22
10. Acknowledgements..............................................24 7.1 Session Failure and Recovery..................................23
11. Intellectual Property Consideration...........................24 7.2 Temporary Shutdown............................................25
12. Full Copyright Statement......................................25 8. Security Considerations........................................26
13. IANA Considerations...........................................25 9. Implementation Notes...........................................27
13.1 FT Session TLV...............................................25 9.1 FT Recovery Support on Non-FT LSRs............................27
13.2 FT Protection TLV............................................26 9.2 ACK generation logic..........................................27
13.3 FT ACK TLV...................................................26 10. Acknowledgements..............................................27
13.4 Status Codes.................................................26 11. Intellectual Property Consideration...........................28
14. Authors' Addresses............................................27 12. Full Copyright Statement......................................28
15. References....................................................27 13. IANA Considerations...........................................28
13.1 FT Session TLV...............................................29
13.2 FT Protection TLV............................................29
13.3 FT ACK TLV...................................................29
13.4 Status Codes.................................................29
14. Authors' Addresses............................................29
15. References....................................................30
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.
4.1.3 Describe FT procedures for Label Resources Available
Notification Messages
4.2 Explain use of "FT Seq Numbers Exhausted" status code.
4.4 Recommend default value for FT Reconnection Timeout.
6.2 Define meaning of FT Reconnection Timeout with value 0.
6.3 Describe how to handle a message that describes a FEC that may
have wider coverage than a single label.
6.3 The sequence number 0x00000000 is invalid under all
circumstances. Sequence numbers wrap from 0xFFFFFFFF to 0x00000001.
7.1 Correct sequence numbers in example.
7.2 Add example for Temporary Shutdown.
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 6, line 11 skipping to change at page 6, line 34
- An FT Reconnection Timeout, exchanged on the LDP Initialization - An FT Reconnection Timeout, exchanged on the LDP Initialization
message, that indicates the maximum time peer LSRs will preserve message, that indicates the maximum time peer LSRs will preserve
FT label state after a failure of the TCP connection. FT label state after a failure of the TCP connection.
- An FT Protection TLV used to identify operations that affect LDP - An FT Protection TLV used to identify operations that affect LDP
labels. All LDP messages carrying the FT Protection TLV need to labels. All LDP messages carrying the FT Protection TLV need to
be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in
order that the state for FT labels can be correctly recovered order that the state for FT labels can be correctly recovered
after LDP session reconnection. after LDP session reconnection.
Note that the implementation within an FT system is left open by
this draft. An implementation could choose to secure entire
messages relating to FT labels, or it could secure only the
relevant state information.
- Address advertisement is also secured by use of the FT Protection
TLV. This enables recovery after LDP session reconnection without
the need to re-advertise what may be a very large number of
addresses.
3.1 Establishing an FT LDP Session 3.1 Establishing an FT LDP Session
In order that the extensions to LDP [4] and CR-LDP [2] described in In order that the extensions to LDP [4] and CR-LDP [2] described in
this draft can be used successfully on an LDP session between a pair this draft can be used successfully on an LDP session between a pair
of LDP peers, they MUST negotiate that the LDP FT enhancements of LDP peers, they MUST negotiate that the LDP FT enhancements
are to be used on the LDP session. are to be used on the LDP session.
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 FT Session TLV. Presence of this TLV indicates that the peer wants
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 on the LDP session. the receiving LDP peer as a serious protocol error causing the
session to be torn down.
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
Session TLV, all LDP sessions to such LSRs will not use the LDP FT Session TLV, all LDP sessions to such LSRs will not use the LDP FT
enhancements. enhancements.
The rest of this draft assumes that the LDP sessions under discussion The rest of this draft assumes that the LDP sessions under discussion
are between LSRs that do support the LDP FT enhancements, except are between LSRs that do support the LDP FT enhancements, except
where explicitly stated otherwise. where explicitly stated otherwise.
3.2 TCP Connection Failure 3.2 TCP Connection Failure
3.2.1 Detecting TCP Connection Failures
TCP connection failures may be detected and reported to the LDP
component in a variety of ways. These should all be treated in the
same way by the LDP component.
- Indication from the management component that a TCP connection or
underlying resource is no longer active.
- Notification from a hardware management component of an interface
failure.
- Sockets keepalive timeout.
- Sockets send failure.
- New (incoming) Socket opened.
- LDP protocol timeout.
3.2.2 LDP Processing after Connection Failure
If the LDP FT enhancements are not in use on an LDP session, the If the LDP FT enhancements are not in use on an LDP session, the
action of the LDP peers on failure of the TCP connection is as action of the LDP peers on failure of the TCP connection is as
specified in [2] and [4]. specified in [2] and [4].
All state information and resources associated with non-FT labels All state information and resources associated with non-FT labels
MUST be released on the failure of the TCP connection, including MUST be released on the failure of the TCP connection, including
deprogramming the non-FT label from the switching hardware. This is deprogramming the non-FT label from the switching hardware. This is
equivalent to the behavior specified in [4]. equivalent to the behavior specified in [4].
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
skipping to change at page 8, line 12 skipping to change at page 9, line 5
Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the
FT Reconnect Flag to 0. FT Reconnect Flag to 0.
If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
Session TLV, both LDP peers MUST release any state information and Session TLV, both LDP peers MUST release any state information and
resources associated with the previous instantiation of the LDP resources associated with the previous instantiation of the LDP
session between the same LDP peers, including FT label state and session between the same LDP peers, including FT label state and
Addresses. This ensures that network resources are not permanently Addresses. This ensures that network resources are not permanently
lost by one LSR if its LDP peer is forced to undergo a cold start. lost by one LSR if its LDP peer is forced to undergo a cold start.
If an LDP peer changes any session parameters (for example, the label
space bounds) from the previous instantiation the nature of any
preserved labels may have changed. In particular, previously
allocated labels may now be out of range. For this reason, session
reconnection MUST use the same parameters as were in use on the
session before the failure. If an LDP peer notices that the
parameters have been changed by the other peer it SHOULD send a
Notification message with the 'FT Session parameters changed' status
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.
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
skipping to change at page 8, line 33 skipping to change at page 9, line 36
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".
Using these acknowledgements and procedures, it is not necessary for Using these acknowledgements and procedures, it is not necessary for
LDP peers to perform a complete re-synchronization of state for all LDP peers to perform a complete re-synchronization of state for all
FT labels, either on re-connection of the LDP session between the LDP FT labels, either on re-connection of the LDP session between the LDP
peers or on a timed basis. peers or on a timed basis.
3.6 Label Space Depletion and Replenishment
When an LDP peer is unable to satisfy a Label Request message because
it has no more available labels, it sends a Notification message
carrying the status code 'No label resources'. This warns the
requesting LDP peer that subsequent Label Request messages are also
likely to fail for the same reason. This message does not need to be
acknowledged for FT purposes since Label Request messages sent after
session recovery will receive the same response.
However, the LDP peer that receives a 'No label resources'
Notification stops sending Label Request messages until it receives a
'Label resources available' Notification message. Since this
unsolicited Notification might get lost during session failure, it
must be protected using the procedures described in this draft.
4. FT Operations 4. FT Operations
Once an FT LDP session has been established, using the procedures Once an FT LDP session has been established, using the procedures
described in the section "Establishing an FT LDP Session", both LDP described in the section "Establishing an FT LDP Session", both LDP
peers MUST apply the procedures described in this section for FT LDP peers MUST apply the procedures described in this section for FT LDP
message exchanges. message exchanges.
If the LDP session has been negotiated to not use the LDP FT If the LDP session has been negotiated to not use the LDP FT
enhancements, these procedures MUST NOT be used. enhancements, these procedures MUST NOT be used.
skipping to change at page 9, line 32 skipping to change at page 11, line 5
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
the session is reconnected. the session is reconnected.
If the FT Reconnect Flag is not set by both LDP peers on reconnection If the FT Reconnect Flag is not set by both LDP peers on reconnection
of an LDP session (i.e. state has not been preserved), both LDP of an LDP session (i.e. state has not been preserved), both LDP
peers MUST consider all Addresses to have been withdrawn. The LDP peers MUST consider all Addresses to have been withdrawn. The LDP
peers SHOULD issue new Address messages for all their valid addresses peers SHOULD issue new Address messages for all their valid addresses
as specified in [4]. as specified in [4].
4.1.3 FT Label Resources Available Notification Messages
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
in RFC3036, the downstream LSR must respond with a Notification - No
Label Resources message. The upstream LSR then suspends asking for
new labels until it receives a Notification - Label Resources
Available message from the downstream LSR.
When the FT extensions are used on a sesssion:
1. The downstream LSR must preserve the label availability state
across a failover so that it remembers to send Notification -
Label Resources Available when the resources become available.
2. The upstream LSR must recall the label availability state across
failover so that it can optimize not sending Label Requests when
it recovers.
3. The downstream LSR must use sequence numbers on Notification -
Label Resources Available so that it can check that LSR A has
received the message and clear its secured state, or resend the
message if LSR A recovers without having received it.
If the FT Reconnect Flag is not set by both LDP peers on reconnection
of an LDP session (i.e. state has not been preserved), both LDP
peers MUST consider the label availability state to have been reset
as if the session had been set up for the first time.
4.2 FT Operation ACKs 4.2 FT Operation ACKs
Handshaking of FT LDP messages is achieved by use of ACKs. Handshaking of FT LDP messages is achieved by use of ACKs.
Correlation between the original message and the ACK is by means of Correlation between the original message and the ACK is by means of
the FT Sequence Number contained in the FT Protection TLV, and passed the FT Sequence Number contained in the FT Protection TLV, and passed
back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP
message that is sent on the TCP connection between LDP peers. message that is sent on the TCP connection between LDP peers.
An LDP peer maintains a separate FT sequence number for each LDP An LDP peer maintains a separate FT sequence number for each LDP
session it participates in. The FT Sequence number is incremented by session it participates in. The FT Sequence number is incremented by
one for each FT LDP message (i.e. containing the FT Protection TLV) one for each FT LDP message (i.e. containing the FT Protection TLV)
issued by this LSR on the FT LDP session with which the FT sequence issued by this LSR on the FT LDP session with which the FT sequence
number is associated. number is associated.
When an LDP Peer receives a message containing the FT Protection TLV, When an LDP peer receives a message containing the FT Protection TLV,
it MUST take steps to secure this message (or the state information it MUST take steps to secure this message (or the state information
derived from processing the message). Once the message is secured, derived from processing the message). Once the message is secured,
it MUST be ACKed. However, there is no requirement on the LSR to it MUST be ACKed. However, there is no requirement on the LSR to
send this ACK immediately. send this ACK immediately.
ACKs may be accumulated to reduce the message flow between LDP peers. ACKs may be accumulated to reduce the message flow between LDP peers.
For example, if an LSR received FT LDP messages with sequence numbers For example, if an LSR received FT LDP messages with sequence numbers
1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK
receipt and securing of all these messages. receipt and securing of all these messages.
ACKs MUST NOT be sent out of sequence, as this is incompatible with ACKs MUST NOT be sent out of sequence, as this is incompatible with
the use of accumulated ACKs . the use of accumulated ACKs. Duplicate ACKs (that is two successive
messages that acknowledge the same sequence number) are acceptable.
If an LDP peer discovers that its sequence number space for a
specific session is full of un-acknowledged sequence numbers (because
its partner on the session has not acknowledged them in a timely way)
it cannot allocate a new sequence number for any further FT LPD
message. It SHOULD send a Notification message with the status code
"FT Seq Numbers Exhausted".
4.3 Preservation of FT State 4.3 Preservation of FT State
If the LDP FT enhancements are in use on an LDP session, each LDP If the LDP FT enhancements are in use on an LDP session, each LDP
peer SHOULD NOT release the state information and resources peer SHOULD NOT release the state information and resources
associated with FT labels exchanged on that LDP session when the TCP associated with FT labels exchanged on that LDP session when the TCP
connection fails. This is contrary to [2] and [4], but allows label connection fails. This is contrary to [2] and [4], but allows label
operations on FT labels to be completed after re-connection of the operations on FT labels to be completed after re-connection of the
TCP connection. TCP connection.
skipping to change at page 11, line 26 skipping to change at page 13, line 26
across a closure and re-establishment of the TCP session. across a closure and re-establishment of the TCP session.
- If an LSR determines that it must release state for any single FT - If an LSR determines that it must release state for any single FT
label during a failure of the TCP connection on which that label label during a failure of the TCP connection on which that label
was exchanged, it MUST release all state for all labels on the LDP was exchanged, it MUST release all state for all labels on the LDP
session. session.
The release of state information and resources associated with non-FT The release of state information and resources associated with non-FT
labels is as described in [2] and [4]. labels is as described in [2] and [4].
Note that a Label Release and the acknowledgemet to a Label Withdraw Note that a Label Release and the acknowledgement to a Label Withdraw
may be received by a downstream LSR in any order. The downstream LSR may be received by a downstream LSR in any order. The downstream LSR
MAY release its resources on receipt of the first message and MUST MAY release its resources on receipt of the first message and MUST
release its resources on receipt of the second message. release its resources on receipt of the second message.
4.4 FT Procedure After TCP Failure 4.4 FT Procedure After TCP Failure
When an LSR discovers or is notified of a TCP connection failure it When an LSR discovers or is notified of a TCP connection failure it
SHOULD start an FT Reconnection Timer to allow a period for SHOULD start an FT Reconnection Timer to allow a period for
re-connection of the TCP connection between the LDP peers. re-connection of the TCP connection between the LDP peers.
The RECOMMENDED default value for this timer is 5 seconds. During
this time, failure must be detected and reported, new hardware may
need to be activated, software state must be audited, and a new TCP
session must be set up.
Once the TCP connection between LDP peers has failed, the active LSR Once the TCP connection between LDP peers has failed, the active LSR
SHOULD attempt to re-establish the TCP connection. The mechanisms, SHOULD attempt to re-establish the TCP connection. The mechanisms,
timers and retry counts to re-establish the TCP connection are an timers and retry counts to re-establish the TCP connection are an
implementation choice. It is RECOMMENDED that any attempt to implementation choice. It is RECOMMENDED that any attempt to
re-establish the connection take account of the failover processing re-establish the connection take account of the failover processing
necessary on the peer LSR, the nature of the network between the necessary on the peer LSR, the nature of the network between the
LDP peers, and the FT Reconnection Timeout chosen on the previous LDP peers, and the FT Reconnection Timeout chosen on the previous
instantiation of the TCP connection (if any). instantiation of the TCP connection (if any).
If the TCP connection cannot be re-established within the FT If the TCP connection cannot be re-established within the FT
skipping to change at page 12, line 11 skipping to change at page 14, line 11
further Hello exchange to set up a new LDP session), the LSR MUST set further Hello exchange to set up a new LDP session), the LSR MUST set
the FT Reconnect Flag to 0 if it released the preserved state the FT Reconnect Flag to 0 if it released the preserved state
information on this timeout event. information on this timeout event.
If the TCP connection is successfully re-established within the FT If the TCP connection is successfully re-established within the FT
Reconnection Timeout, both peers MUST re-issue LDP operations that Reconnection Timeout, both peers MUST re-issue LDP operations that
were interrupted by (that is, un-acknowledged as a result of) the TCP were interrupted by (that is, un-acknowledged as a result of) the TCP
connection failure. This procedure is described in section "FT connection failure. This procedure is described in section "FT
Procedure After TCP Re-connection". Procedure After TCP Re-connection".
The Hold Timer for an FT LDP Session SHOULD be ignored while the FT The Hold Timer for an FT LDP Session (see [4] section 2.5.5) SHOULD
Reconnection Timer is running. The hold timer SHOULD be restarted be ignored while the FT Reconnection Timer is running. The hold
when the TCP connection is re-established. timer SHOULD be restarted when the TCP connection is re-established.
4.4.1 FT LDP Operations During TCP Failure 4.4.1 FT LDP Operations During TCP Failure
When the LDP FT enhancements are in use for an LDP session, it is When the LDP FT enhancements are in use for an LDP session, it is
possible that an LSR may determine that it needs to send an LDP possible that an LSR may determine that it needs to send an LDP
message to an LDP peer but that the TCP connection to that peer is message to an LDP peer but that the TCP connection to that peer is
currently down. These label operations affect the state of FT labels currently down. These label operations affect the state of FT labels
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.
skipping to change at page 12, line 46 skipping to change at page 14, line 46
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
not pended awaiting the re-establishment of TCP connection that is not pended awaiting the re-establishment of TCP connection that is
awaiting recovery at the time the LSR determines that it needs to awaiting recovery at the time the LSR determines that it needs to
issue the Label Request message. Instead, such Label Request issue the Label Request message. Instead, such Label Request
operations SHOULD be failed and, if necessary, a notification message operations SHOULD be failed and, if necessary, a notification message
containing the "No LDP Connection" status code sent upstream. containing the "No LDP Session" status code sent upstream.
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.
skipping to change at page 13, line 25 skipping to change at page 15, line 31
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
to the following rules for re-issuing messages that are not ACKed by to the following rules for re-issuing messages that are not ACKed by
the LDP peer on the LDP Initialization message exchange after the LDP peer on the LDP Initialization message exchange after
re-connection of the TCP session. re-connection of the TCP session.
- A Label Request message MUST be re-issued unless a Label Abort - A Label Request message MUST be re-issued unless a Label Abort
would be re-issued for the same Label Request or the Label Request would be re-issued for the same FT label.
or if the requested label is no longer required.
- A Label Mapping message MUST be re-issued unless a Label Withdraw - A Label Mapping message MUST be re-issued unless a Label Withdraw
message would be re-issued for the same FT label. message would be re-issued for the same FT label.
- All other messages on the LDP session that carried the FT - All other messages on the LDP session that carried the FT
Protection TLV MUST be re-issued if an acknowledgement had not Protection TLV MUST be re-issued if an acknowledgement had not
previously been received. previously been received.
Any FT label operations that were pended (see section "FT Label Any FT label operations that were pended (see section "FT Label
Operations During TCP Failure") during the TCP connection failure Operations During TCP Failure") during the TCP connection failure
skipping to change at page 16, line 4 skipping to change at page 17, line 56
No LDP Session 0 0x000000xx No LDP Session 0 0x000000xx
Zero FT seqnum 1 0x000000xx Zero FT seqnum 1 0x000000xx
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x000000xx
Session Not FT Session Not FT
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x000000xx
Label Not FT Label Not FT
Missing FT Protection TLV 1 0x000000xx Missing FT Protection TLV 1 0x000000xx
FT ACK sequence error 1 0x000000xx FT ACK sequence error 1 0x000000xx
Temporary Shutdown 0 0x000000xx Temporary Shutdown 0 0x000000xx
FT Seq Numbers Exhausted 1 0x000000xx FT Seq Numbers Exhausted 1 0x000000xx
FT Session parameters / 1 0x000000xx
changed
The Temporary Shutdown status code SHOULD be used in place of The Temporary Shutdown status code SHOULD be used in place of
the Shutdown status code (which has the E-bit set) if the LSR that is the Shutdown status code (which has the E-bit set) if the LSR that is
shutting down wishes to inform its LDP peer that it expects to be shutting down wishes to inform its LDP peer that it expects to be
able to preserve FT label state and to return to service before the able to preserve FT label state and to return to service before the
FT Reconnection Timer expires. FT Reconnection Timer expires.
6.2 FT Session TLV 6.2 FT Session TLV
LDP peers can negotiate whether the LDP session between them supports LDP peers can negotiate whether the LDP session between them supports
FT extensions by using a new OPTIONAL parameter, the FT Session FT extensions by using a new OPTIONAL parameter, the FT Session
skipping to change at page 17, line 11 skipping to change at page 19, line 5
All other bits in this field are currently reserved and SHOULD All other bits in this field are currently reserved and SHOULD
be set to zero on transmission and ignored on receipt. be set to zero on transmission and ignored on receipt.
FT Reconnection Timeout FT Reconnection Timeout
The period of time the sending LSR will preserve state and The period of time the sending LSR will preserve state and
resources for FT labels exchanged on the previous instantiation of resources for FT labels exchanged on the previous instantiation of
an FT LDP session that has currently failed. The timeout is an FT LDP session that has currently failed. The timeout is
encoded as a 16-bit unsigned integer number of seconds. encoded as a 16-bit unsigned integer number of seconds.
The value of 0 for this field is reserved and MUST NOT be used. A value of zero in this field means that the sending LSR will
preserve state and resources indefinitely.
See the section "LDP Session Failure" for details of how this field See the section "FT Procedure After TCP Failure" for details of how
is used. this field is used.
6.3 FT Protection TLV 6.3 FT Protection TLV
LDP peers use the FT Protection TLV to indicate that an LDP message LDP peers use the FT Protection TLV to indicate that an LDP message
contains an FT label operation. contains an FT label operation.
The FT Protection TLV MUST NOT be used in messages flowing on an LDP The FT Protection TLV MUST NOT be used in messages flowing on an LDP
session that does not support the LDP FT enhancements. session that does not support the LDP FT enhancements. Its presence
in such messages SHALL be treated as a protocol error by the
receiving LDP peer which SHOULD send a Notification message with the
'Unexpected TLV Session Not FT' status code.
The FT Protection TLV MAY be carried on an LDP message transported on The FT Protection TLV MAY be carried on an LDP message transported on
the LDP session after the initial exchange of LDP Initialization the LDP session after the initial exchange of LDP Initialization
messages. In particular, this TLV MAY optionally be present on the messages. In particular, this TLV MAY optionally be present on the
following messages: following messages:
- Label Request Messages in downstream on-demand distribution mode - Label Request Messages in downstream on-demand distribution mode
- Label Mapping messages in downstream unsolicited mode. - Label Mapping messages in downstream unsolicited mode.
If a label is to be an FT label, then the Protection TLV MUST be If a label is to be an FT label, then the Protection TLV MUST be
present: present:
- on the Label Request message in DoD mode - on the Label Request message in DoD mode
- on the Label Mapping message in DU mode - on the Label Mapping message in DU mode
- on all subsequent messages concerning this label. - on all subsequent messages concerning this label.
Here 'subsequent messages concerning this label' means any message Here 'subsequent messages concerning this label' means any message
whose Label TLV specifies this label or whose Label Request Message whose Label TLV specifies this label or whose Label Request Message
ID TLV specifies the initial Label Request message. ID TLV specifies the initial Label Request message.
If a label is not to be an FT label, then the Protection TLV If a label is not to be an FT label, then the Protection TLV
MUST NOT be present on any of these messages. MUST NOT be present on any of these messages. The presence of the FT
TLV on a message relating to a non-FT label SHALL be treated as a
protocol error by the receiving LDP peer which SHOULD send a
notification message with the 'Unexpected TLV Label Not FT' status
code.
Where a Label Withdraw or Label Release message contains only a FEC
TLV and does not identify a single specific label, the FT TLV should
be included in the message if any label affected by the message is an
FT label. If there is any doubt as to whether an FT TLV should be
present, it is RECOMMENDED that the sender add the TLV.
When an LDP peer receives a Label Withdraw Message or Label Release
message that contains only a FEC, it SHALL accept the FT TLV if it is
present regardless of the FT status of the labels which it affects.
If an LDP session is an FT session as determined by the presence of
the FT Session TLV on the LDP Initialization messages, the FT
Protection TLV MUST be present:
- on all Address messages on the session
- on all Notification messages on the session that have the status
code 'Label Resources Available'.
The FT Protection TLV is encoded as follows. The FT Protection TLV is encoded as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) | |0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number | | FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 4 skipping to change at page 20, line 21
The FT Protection TLV is encoded as follows. The FT Protection TLV is encoded as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) | |0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number | | FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number FT Sequence Number
The sequence number for this FT label operation. The The sequence number for this FT label operation. The
sequence number is encoded as a 32-bit unsigned integer. The sequence number is encoded as a 32-bit unsigned integer. The
initial value for this field on a new LDP session is x00000001 and initial value for this field on a new LDP session is 0x00000001 and
is incremented by one for each FT LDP message issued by the sending is incremented by one for each FT LDP message issued by the sending
LSR on this LDP session. This field may wrap from xFFFFFFFF to LSR on this LDP session. This field may wrap from 0xFFFFFFFF to
x00000000. 0x00000001.
This field MUST be reset to x00000001 if either LDP peer does not This field MUST be reset to 0x00000001 if either LDP peer does not
set the FT Reconnect Flag on re-establishment of the TCP set the FT Reconnect Flag on re-establishment of the TCP
connection. connection.
See the section "FT Operation Acks" for details of how this field See the section "FT Operation Acks" for details of how this field
is used. is used.
The special use of 0x00000000 is discussed in the section "FT ACK
TLV" below.
If an LSR receives an FT Protection TLV on a session that does not If an LSR receives an FT Protection TLV on a session that does not
support the FT LFP enhancements, it SHOULD send a Notification support the FT LDP enhancements, it SHOULD send a Notification
message to its LDP peer containing the "Unexpected TLV, Session Not message to its LDP peer containing the "Unexpected TLV, Session Not
FT" status code. FT" status code.
If an LSR receives an FT Protection TLV on an operation affecting a If an LSR receives an FT Protection TLV on an operation affecting a
label that it believes is a non-FT label, it SHOULD send a label that it believes is a non-FT label, it SHOULD send a
Notification message to its LDP peer containing the "Unexpected TLV, Notification message to its LDP peer containing the "Unexpected TLV,
Label Not FT" status code. Label Not FT" status code.
If an LSR receives a message without the FT Protection TLV affecting If an LSR receives a message without the FT Protection TLV affecting
a label that it believes is an FT label, it SHOULD send a a label that it believes is an FT label, it SHOULD send a
Notification message to its LDP peer containing the "Missing FT Notification message to its LDP peer containing the "Missing FT
Protection TLV" status code. Protection TLV" status code.
If an LSR receives an FT Protection TLV containing a zero FT If an LSR receives an FT Protection TLV containing a zero FT
Sequence Number, it SHOULD send a Notification message to its LDP Sequence Number, it SHOULD send a Notification message to its LDP
peer containing the "Zero FT Seqnum" status code. peer containing the "Zero FT Seqnum" status code.
6.4 FT ACK TLV 6.4 FT ACK TLV
LDP peers use the FT ACK TLV to acknowledge FT LDP peers use the FT ACK TLV to acknowledge FT label operations.
label operations.
The FT ACK TLV MUST NOT be used in messages flowing on an The FT ACK TLV MUST NOT be used in messages flowing on an LDP session
LDP session that does not support the LDP FT enhancements. that does not support the LDP FT enhancements. Its presence on such
messages SHALL be treated as a protocol error by the receiving LDP
peer.
The FT ACK TLV MAY be present on any LDP message exchanged on an The FT ACK TLV MAY be present on any LDP message exchanged on an
LDP session after the initial LDP Initialization messages. It is LDP session after the initial LDP Initialization messages. It is
RECOMMENDED that the FT ACK TLV is included on all FT RECOMMENDED that the FT ACK TLV is included on all FT
Keepalive messages in order to ensure that the LDP peers do not Keepalive messages in order to ensure that the LDP peers do not
build up a large backlog of unacknowledged state information. build up a large backlog of unacknowledged state information.
The FT ACK TLV is encoded as follows. The FT ACK TLV is encoded as follows.
0 1 2 3 0 1 2 3
skipping to change at page 19, line 55 skipping to change at page 22, line 18
Notification message to its LDP peer containing the "FT ACK Notification message to its LDP peer containing the "FT ACK
Sequence Error" status code. Sequence Error" status code.
7. Example Use 7. Example Use
Consider two LDP peers, P1 and P2, implementing LDP over a TCP Consider two LDP peers, P1 and P2, implementing LDP over a TCP
connection that connects them, and the message flow shown below. connection that connects them, and the message flow shown below.
The parameters shown on each message shown below are as follows: The parameters shown on each message shown below are as follows:
message (label, senders FT sequence #, FT ACK #) message (label, senders FT sequence number, FT ACK number)
A "-" for FT ACK # means that the FT ACK TLV is not included on
that message. "n/a" means that the parameter in question is not A "-" for FT ACK number means that the FT ACK TLV is not included
on that message. "n/a" means that the parameter in question is not
applicable to that type of message. applicable to that type of message.
In the diagram below, time flows from top to bottom. The relative In the diagrams below, time flows from top to bottom. The relative
position of each message shows when it is transmitted. See the notes position of each message shows when it is transmitted. See the notes
for a description of when each message is received, secured for FT or for a description of when each message is received, secured for FT or
processed. processed.
7.1 Session Failure and Recovery
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1,27,-) (1) Label Request(L1,27,-)
---------------------------> --------------------------->
Label Request(L2,28,-) Label Request(L2,28,-)
---------------------------> --------------------------->
(2) Label Request(L3,93,27) (2) Label Request(L3,93,27)
<--------------------------- <---------------------------
(3) Label Request(L1,123,-) (3) Label Request(L1,123,-)
--------------------------> -------------------------->
skipping to change at page 21, line 34 skipping to change at page 23, line 36
<--------------------------- <---------------------------
(6) Address(n/a,29,-) (6) Address(n/a,29,-)
---------------------------> --------------------------->
(7) Label Request(L4,30,-) (7) Label Request(L4,30,-)
---------------------------> --------------------------->
(8) Keepalive(n/a,na/,94) (8) Keepalive(n/a,na/,94)
---------------------------> --------------------------->
(9) Label Abort(L3,96,-) (9) Label Abort(L3,96,-)
<--------------------------- <---------------------------
(10) ===== TCP Session lost ===== (10) ===== TCP Session lost =====
:
(11) Label Withdraw(L1,59,-) (11) : Label Withdraw(L1,59,-)
<-------------------------- : <--------------------------
:
(12) === TCP Session restored === (12) === TCP Session restored ===
LDP Init(n/a,n/a,95) LDP Init(n/a,n/a,94)
---------------------------> --------------------------->
LDP Init(n/a,n/a,29) LDP Init(n/a,n/a,29)
<--------------------------- <---------------------------
(13) Label Request(L4,30,-) (13) Label Request(L4,30,-)
---------------------------> --------------------------->
(14) Label Mapping(L2,95,-) (14) Label Mapping(L2,95,-)
<--------------------------- <---------------------------
Label Abort(L3,96,30) Label Abort(L3,96,30)
<--------------------------- <---------------------------
(15) Label Withdraw(L1,97,-) (15) Label Withdraw(L1,97,-)
skipping to change at page 23, line 5 skipping to change at page 25, line 5
to the failure. to the failure.
(13) From the LDP Init exchange, P1 determines that it needs to (13) From the LDP Init exchange, P1 determines that it needs to
re-issue the Label request for L4. re-issue the Label request for L4.
(14) Similarly, P2 determines that it needs to re-issue the Label (14) Similarly, P2 determines that it needs to re-issue the Label
Mapping for L2 and the Label Abort. Mapping for L2 and the Label Abort.
(15) P2 issues the queued Label Withdraw to P1. (15) P2 issues the queued Label Withdraw to P1.
7.2 Temporary Shutdown
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,na/,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) Notification(Temporary shutdown)
--------------------------->
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
Notes are as in the previous example except as follows.
(10) P1 needs to upgrade the software or hardware that it is running.
It issues a Notification message to terminate the LDP session,
but sets the status code as 'Temporary shutdown' to inform P2
that this is not a fatal error, and P2 should maintain FT state.
The TCP connection may also fail during the period that the LDP
session is down (in which case it will need to be
re-established), but it is also possible that the TCP connection
will be preserved.
8. Security Considerations 8. Security Considerations
The LDP FT enhancements inherit similar security considerations to The LDP FT enhancements inherit similar security considerations to
those discussed in [2] and [4]. those discussed in [2] and [4].
The LDP FT enhancements allow the re-establishment of a TCP The LDP FT enhancements allow the re-establishment of a TCP
connection between LDP peers without a full re-exchange of the connection between LDP peers without a full re-exchange of the
attributes of established labels, which renders LSRs that implement attributes of established labels, which renders LSRs that implement
the extensions specified in this draft vulnerable to additional the extensions specified in this draft vulnerable to additional
denial-of-service attacks as follows: denial-of-service attacks as follows:
skipping to change at page 24, line 34 skipping to change at page 27, line 50
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 [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 and Duncan comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
Archer at Data Connection Ltd, Peter Ashwood-Smith of Nortel and Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and
Bon Thomas of Cisco. 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
document. For more information, consult the online list of claimed document. For more information, consult the online list of claimed
rights. rights.
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved. This Copyright (c) The Internet Society (2000, 2001). All Rights Reserved.
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 kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are 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
skipping to change at page 27, line 20 skipping to change at page 30, line 20
Pepper Street Pepper Street Pepper Street Pepper Street
Chester Chester Chester Chester
Cheshire Cheshire Cheshire Cheshire
CH1 1DF CH1 1DF CH1 1DF CH1 1DF
UK UK UK UK
Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440
Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422
Email: af@dataconnection.com Email: pjb@dataconnection.com Email: af@dataconnection.com Email: pjb@dataconnection.com
Philip Matthews Eric Gray Philip Matthews Eric Gray
Nortel Networks Corp. Zaffire, Inc. Nortel Networks Corp. Sandburst Corporation
P.O. Box 3511 Station C, 2630 Orchard Parkway, P.O. Box 3511 Station C, 600 Federal Street
Ottawa, ON K1Y 4H7 San Jose, CA - 95134-2020 Ottawa, ON K1Y 4H7 Andover, MA 01810
Canada Phone: (408) 894-7362 Canada Phone: +1 978-689-1600
Phone: +1 613-768-3262 egray@zaffire.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-04.txt, July 2000, (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, draft-ietf-mpls-ldp- 4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
11.txt, August 2000 (work in progress).
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-01.txt, February 2000 (work in progress). crlsp-modify-02.txt, October 2000 (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-07.txt, August 2000 (work in progress).
9 Ward, D, et al., BGP Notification Cease: I'll Be Back, 9 Ward, D, et al., BGP Notification Cease: I'll Be Back,
draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress) draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress)
10 Stewart, R, et al., Simple Control Transmission Protocol,
draft-ietf-sigtran-sctp-07.txt, March 2000 (work in progress) 10 Stewart, R, et al., Stream Control Transmission Protocol,
RFC 2906, October 2000.
 End of changes. 

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