draft-ietf-mpls-ldp-ft-03.txt   draft-ietf-mpls-ldp-ft-04.txt 
MPLS Working Group Adrian Farrel MPLS Working Group Adrian Farrel
Internet Draft Movaz Networks, Inc. Internet Draft Movaz Networks, Inc.
Document: draft-ietf-mpls-ldp-ft-03.txt Document: draft-ietf-mpls-ldp-ft-04.txt
Expiration Date: December 2002 Paul Brittain Expiration Date: January 2003 Paul Brittain
Data Connection Ltd. Data Connection Ltd.
Philip Matthews Philip Matthews
Hyperchip Hyperchip
Eric Gray Eric Gray
Sandburst Celox Networks
Toby Smith Toby Smith
Laurel Networks Laurel Networks
Andy Malis Andrew G. Malis
Jack Shaio Jack Shaio
Vivace Networks Vivace Networks
June 2002 July 2002
Fault Tolerance for LDP and CR-LDP Fault Tolerance for the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-ft-03.txt draft-ietf-mpls-ldp-ft-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026 conformance with all provisions of Section 10 of RFC2026
[1]. [RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents as Internet-Drafts. Internet-Drafts are
draft documents valid for a maximum of six months and may draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in reference material or to cite them other than as "work in
progress." progress."
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Abstract Abstract
MPLS systems will be used in core networks where system MPLS systems will be used in core networks where system
downtime must be kept to an absolute minimum. Many MPLS downtime must be kept to an absolute minimum. Many MPLS
LSRs may, therefore, exploit Fault Tolerant (FT) hardware LSRs may, therefore, exploit Fault Tolerant (FT) hardware
or software to provide high availability of the core or software to provide high availability of the core
networks. networks.
The details of how FT is achieved for the various The details of how FT is achieved for the various
components of an FT LSR, including LDP, CR-LDP, the components of an FT LSR, including LDP, the switching
switching hardware and TCP, are implementation specific. hardware and TCP, are implementation specific. This
This document identifies issues in the CR-LDP document identifies issues in the LDP specification
specification [2] and the LDP specification [4] that make [RFC3036] that make it difficult to implement an FT LSR
it difficult to implement an FT LSR using the current LDP using the current LDP protocols, and proposes
and CR-LDP protocols, and proposes enhancements to the enhancements to the LDP specification to ease such FT LSR
LDP specification to ease such FT LSR implementations. implementations.
The extensions described here are equally applicable to The issues and extensions described here are equally
CR-LDP. applicable to CR-LDP [RFC3212].
Contents Contents
1. Conventions and Terminology used in this document 4 1. Conventions and Terminology used in this document 3
2. Introduction 5 2. Introduction 4
2.1. Fault Tolerance for MPLS 5 2.1. Fault Tolerance for MPLS 5
2.2. Issues with LDP and CR-LDP 6 2.2. Issues with LDP and CR-LDP 5
3. Overview of LDP FT Enhancements 7 3. Overview of LDP FT Enhancements 7
3.1. Establishing an FT LDP Session 8 3.1. Establishing an FT LDP Session 8
3.1.1 Interoperation with Non-FT LSRs 9 3.1.1 Interoperation with Non-FT LSRs 8
3.2. TCP Connection Failure 9 3.2. TCP Connection Failure 9
3.2.1 Detecting TCP Connection Failures 9 3.2.1 Detecting TCP Connection Failures 9
3.2.2 LDP Processing after Connection Failure 10 3.2.2 LDP Processing after Connection Failure 9
3.3. Data Forwarding During TCP Connection Failure 10 3.3. Data Forwarding During TCP Connection Failure 10
3.4. FT LDP Session Reconnection 11 3.4. FT LDP Session Reconnection 10
3.5. Operations on FT Labels 12 3.5. Operations on FT Labels 11
3.6. Check-Pointing 12 3.6. Check-Pointing 12
3.6.1 Graceful Termination 13 3.6.1 Graceful Termination 13
3.7. Label Space Depletion and Replenishment 13 3.7. Label Space Depletion and Replenishment 13
4. FT Operations 14 4. FT Operations 14
4.1. FT LDP Messages 14 4.1. FT LDP Messages 14
4.1.1 FT Label Messages 14 4.1.1 Sequence Numbered FT Label Messages 14
4.1.2 FT Address Messages 15 4.1.2 FT Address Messages 15
4.1.3 FT Label Resources Available Notification Messages 16 4.1.3 Label Resources Available Notifications 15
4.2. FT Operation ACKs 17 4.2. FT Operation ACKs 17
4.3. Preservation of FT State 18 4.3. Preservation of FT State 17
4.4. FT Procedure After TCP Failure 19 4.4. FT Procedure After TCP Failure 19
4.4.1 FT LDP Operations During TCP Failure 20 4.4.1 FT LDP Operations During TCP Failure 20
4.5. FT Procedure After TCP Re-connection 21 4.5. FT Procedure After TCP Re-connection 21
4.5.1 Re-Issuing FT Messages 22 4.5.1 Re-Issuing FT Messages 22
4.5.2 Interaction with CR-LDP LSP Modification 23 4.5.2 Interaction with CR-LDP LSP Modification 22
5. Checkpointing Procedures 23 5. Checkpointing Procedures 23
5.1. Checkpointing with the Keepalive Message 24 5.1. Checkpointing with the Keepalive Message 23
5.2. Quiesce and Keepalive 24 5.2. Quiesce and Keepalive 24
6. Changes to Existing Messages 25 6. Changes to Existing Messages 24
6.1. LDP Initialization Message 25 6.1. LDP Initialization Message 24
6.2. LDP Keepalive Messages 25 6.2. LDP Keepalive Messages 25
6.3. All Other LDP Session Messages 26 6.3. All Other LDP Session Messages 25
7. New Fields and Values 26 7. New Fields and Values 26
7.1. Status Codes 26 7.1. Status Codes 26
7.2. FT Session TLV 27 7.2. FT Session TLV 27
7.3. FT Protection TLV 29 7.3. FT Protection TLV 30
7.4. FT ACK TLV 32 7.4. FT ACK TLV 32
7.5. FT Cork TLV 33 7.5. FT Cork TLV 34
8. Example Use 34 8. Example Use 35
8.1. Session Failure and Recovery - FT Procedures 35 8.1. Session Failure and Recovery - FT Procedures 36
8.2. Use of Check-Pointing With FT Procedures 37 8.2. Use of Check-Pointing With FT Procedures 38
8.3. Temporary Shutdown With FT Procedures 39 8.3. Temporary Shutdown With FT Procedures 40
8.4. Temporary Shutdown With FT Procedures and Check-Pointing 41 8.4. Temporary Shutdown With FT Procedures and Check-Pointing 42
8.5. Checkpointing Without FT Procedures 43 8.5. Checkpointing Without FT Procedures 44
8.6. Graceful Shutdown With Checkpointing But No FT Procedures 45 8.6. Graceful Shutdown With Checkpointing But No FT Procedures 46
9. Security Considerations 46 9. Security Considerations 47
10. Implementation Notes 47 10. Implementation Notes 49
10.1. FT Recovery Support on Non-FT LSRs 47 10.1. FT Recovery Support on Non-FT LSRs 49
10.2. ACK Generation Logic 48 10.2. ACK generation logic 49
10.2.1 Ack Generation Logic When Using Check-Pointing 48 10.2.1 Ack Generation Logic When Using Check-Pointing 49
11. Acknowledgments 49 11. Acknowledgments 50
12. Intellectual Property Consideration 49 12. Intellectual Property Consideration 50
13. Full Copyright Statement 49 13. Full Copyright Statement 51
14. IANA Considerations 50 14. IANA Considerations 51
14.1. FT Session TLV 50 14.1. New TLVs 52
14.2. FT Protection TLV 50 14.2. New Status Codes 52
14.3. FT ACK TLV 51 15. Authors' Addresses 53
14.4. FT Cork TLV 51 16. References 53
14.5. Status Codes 51 16.1. Normative References 53
15. Authors' Addresses 51 16.2. Informative References 53
16. Normative References 52
17. Informative References 52
0. Changes From Version 2 to Version 3
This section to be removed before final publication.
2.2 Add notes about graceful shutdown and check-pointing.
3 Allow sequence number on Keepalive to facilitate check-
pointing.
3.6 New section to describe the use of check-pointing
3.6.1 New sub-section to describe the use of check-
pointing for graceful restart
3.7 and 4.1.3 Make acknowledgement and request for
acknowledgement of Notification messages carrying 'Label
Resources Available' optional.
4.1.1 Explicitly state it is allowable to make all labels
FT labels.
5. Add section to describe Checkpointing procedures.
6.2 Allow FT Protection TLV on Keepalive message.
7.1 Add Unexpected FT Cork TLV status code
7.2 Define bits in the FT Session TLV to define which FT
processes are in use.
7.3 Allow FT Protection TLV on Keepalive message.
7.5 Add FT Cork TLV
8. Add examples of further message flows.
10.2.1 Add description of Ack generation logic when using
check-pointing
14.4 Add FT Cork TLV
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 Definitions of key words and terms applicable to LDP and
CR-LDP are inherited from [2] and [4]. CR-LDP are inherited from [RFC3212] and [RFC3036].
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 indicated a label for which some fault tolerant operation
used. A "non-FT label" is not fault tolerant and is is used. A "non-FT Label" is not fault tolerant and is
handled as specified in [2] and [4]. handled as specified in [RFC3212] and [RFC3036].
The term "Sequence Numbered FT Label" is used to indicate
an FT label which is secured using the sequence number in
the FT Protection TLV described in this document.
The term "Checkpointable FT Label" is used to indicate an
FT label which is secured by using the checkpointing
techniques described in this document.
The extensions to LDP specified in this document are The extensions to LDP specified in this document are
collectively referred to as the "LDP FT enhancements". collectively referred to as the "LDP FT enhancements".
Within the context of this draft, "Checkpointing" refers Within the context of this draft, "Checkpointing" refers
to a process of messages exchanges that confirm receipt to a process of messages exchanges that confirm receipt
and processing (or secure storage) of specific protocol and processing (or secure storage) of specific protocol
messages. messages.
In the examples quoted, the following notation is used. In the examples quoted, the following notation is used:
Ln : An LSP. For example L1. Ln : An LSP. For example L1.
Pn : An LDP peer. For example P1. Pn : An LDP peer. For example P1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [3]. interpreted as described in RFC-2119 [RFC2119].
2. Introduction 2. Introduction
High Availability (HA) is typically claimed by equipment High Availability (HA) is typically claimed by equipment
vendors when their hardware achieves availability levels vendors when their hardware achieves availability levels
of at least 99.999% (five 9s). To implement this, the of at least 99.999% (five 9s). To implement this, the
equipment must be capable of recovering from local equipment must be capable of recovering from local
hardware and software failures through a process known as hardware and software failures through a process known as
fault tolerance (FT). fault tolerance (FT).
skipping to change at page 7, line 10 skipping to change at page 6, line 41
- re-issuing lost messages after failover to ensure that - re-issuing lost messages after failover to ensure that
LSP/label state is correctly recovered after reconnection of LSP/label state is correctly recovered after reconnection of
the LDP session. the LDP session.
Other objectives of this draft are to Other objectives of this draft are to
- offer back-compatibility with LSRs that do not implement - offer back-compatibility with LSRs that do not implement
these proposals these proposals
- preserve existing protocol rules described in [2] and [4] - preserve existing protocol rules described in [RFC3212]
for handling unexpected duplicate messages and for and [RFC3036] for handling unexpected duplicate messages and
processing unexpected messages referring to unknown for processing unexpected messages referring to unknown
LSPs/labels LSPs/labels
- integrate with the LSP modification function described in [5] - integrate with the LSP modification function described in
[RFC3214]
- avoid full state refresh solutions (such as those present - avoid full state refresh solutions (such as those present
in RSVP: see [6], [7], [8] and [12]) whether they be full- in RSVP: see [RFC2205], [RFC2961], [RFC3209] and [LDP-
time, or limited to post-failover recovery. RESTART]) whether they be full-time, or limited to post-
failover recovery.
Note that this draft concentrates on the preservation of Note that this draft concentrates on the preservation of
label state for labels exchanged between a pair of label state for labels exchanged between a pair of
adjacent LSRs when the TCP connection between those LSRs adjacent LSRs when the TCP connection between those LSRs
is lost. This is a requirement for Fault Tolerant is lost. This is a requirement for Fault Tolerant
operation of LSPs, but a full implementation of end-to- operation of LSPs, but a full implementation of end-to-
end protection for LSPs requires that this is combined end protection for LSPs requires that this is combined
with other techniques that are outside the scope of this with other techniques that are outside the scope of this
draft. draft.
In particular, this draft does not attempt to describe In particular, this draft does not attempt to describe
how to modify the routing of an LSP or the resources how to modify the routing of an LSP or the resources
allocated to a label or LSP, which is covered by [5]. allocated to a label or LSP, which is covered by
This draft also does not address how to provide automatic [RFC3214]. This draft also does not address how to
layer 2/3 protection switching for a label or LSP, which provide automatic layer 2/3 protection switching for a
is a separate area for study. label or LSP, which is a separate area for study.
This specification does not preclude an implementation This specification does not preclude an implementation
from attempting (or require it to attempt) to use the FT from attempting (or require it to attempt) to use the FT
behavior described here to recover from a preemptive behavior described here to recover from a preemptive
failure of a connection on a non-FT system due to, for failure of a connection on a non-FT system due to, for
example, a partial system crash. Note, however, that example, a partial system crash. Note, however, that
there are potential issues too numerous to list here - there are potential issues too numerous to list here -
not least the likelihood that the same crash will not least the likelihood that the same crash will
immediately occur when processing the restored data. immediately occur when processing the restored data.
skipping to change at page 8, line 6 skipping to change at page 7, line 45
- The presence of an FT Session TLV on the LDP - The presence of an FT Session TLV on the LDP
Initialization message indicates that an LSR supports some Initialization message indicates that an LSR supports some
form of protection or recovery from session failure. A flag form of protection or recovery from session failure. A flag
bit within this TLV (the S bit) indicates that the LSR bit within this TLV (the S bit) indicates that the LSR
supports the LDP FT enhancements on this session. Another supports the LDP FT enhancements on this session. Another
flag (the C bit) indicates that the checkpointing procedures flag (the C bit) indicates that the checkpointing procedures
are to be used. are to be used.
- An FT Reconnect Flag in the FT Session TLV indicates - An FT Reconnect Flag in the FT Session TLV indicates
whether an LSR has preserved FT label state across a failure whether an LSR has preserved FT Label state across a failure
of the TCP connection. of the TCP connection.
- An FT Reconnection Timeout, exchanged on the LDP - An FT Reconnection Timeout, exchanged on the LDP
Initialization message, that indicates the maximum time peer Initialization message, that indicates the maximum time peer
LSRs will preserve FT label state after a failure of the TCP LSRs will preserve FT Label state after a failure of the TCP
connection. connection.
- An FT Protection TLV used to identify operations that - An FT Protection TLV used to identify operations that
affect LDP labels. All LDP messages carrying the FT affect LDP labels. All LDP messages carrying the FT
Protection TLV need to be secured (e.g. to NVRAM) and ACKed Protection TLV need to be secured (e.g. to NVRAM) and ACKed
to the sending LDP peer in order that the state for FT to the sending LDP peer in order that the state for Sequence
labels can be correctly recovered after LDP session Numbered FT Labels can be correctly recovered after LDP
reconnection. session reconnection.
Note that the implementation within an FT system is left Note that the implementation within an FT system is left
open by this draft. An implementation could choose to open by this draft. An implementation could choose to
secure entire messages relating to FT labels, or it could secure entire messages relating to Sequence Numbered FT
secure only the relevant state information. Labels, or it could secure only the relevant state
information.
- Address advertisement may also be secured by use of the - Address advertisement may also be secured by use of the
FT Protection TLV. This enables recovery after LDP session FT Protection TLV. This enables recovery after LDP session
reconnection without the need to re-advertise what may be a reconnection without the need to re-advertise what may be a
very large number of addresses. very large number of addresses.
- The FT Protection TLV may also be used on the Keepalive - The FT Protection TLV may also be used on the Keepalive
message to flush acknowledgement of all previous FT message to flush acknowledgement of all previous FT
operations. This enables a check-point for future recovery, operations. This enables a check-point for future recovery,
either in mid-session or prior to graceful shutdown of an either in mid-session or prior to graceful shutdown of an
LDP session. This procedure may also be used to checkpoint LDP session. This procedure may also be used to checkpoint
all (that is both FT and non-FT) operations for future all (that is both FT and non-FT) operations for future
recovery. recovery.
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] In order that the extensions to LDP [RFC3036] and CR-LDP
described in this draft can be used successfully on an [RFC3212] described in this draft can be used
LDP session between a pair of LDP peers, they MUST successfully on an LDP session between a pair of LDP
negotiate that the LDP FT enhancements are to be used on peers, they MUST negotiate that the LDP FT enhancements
the LDP session. are to be used on the LDP session.
This is done on the LDP Initialization message exchange This is done on the LDP Initialization message exchange
using a new FT Session TLV. Presence of this TLV using a new FT Session TLV. Presence of this TLV
indicates that the peer wants to support some form of indicates that the peer wants to support some form of
protection or recovery processing. The S bit within this protection or recovery processing. The S bit within this
TLV indicates that the peer wants to support the LDP FT TLV indicates that the peer wants to support the LDP FT
enhancements on this LDP session. The C bit indicates enhancements on this LDP session. The C bit indicates
that the peer wants to support the checkpointing that the peer wants to support the checkpointing
functions described in this draft. The S and C bits may functions described in this draft. The S and C bits may
be set independently. be set independently.
skipping to change at page 10, line 9 skipping to change at page 9, line 45
- Sockets send failure. - Sockets send failure.
- New (incoming) Socket opened. - New (incoming) Socket opened.
- LDP protocol timeout. - LDP protocol timeout.
3.2.2 LDP Processing after Connection Failure 3.2.2 LDP Processing after Connection Failure
If the LDP FT enhancements are not in use on an LDP If the LDP FT enhancements are not in use on an LDP
session, the action of the LDP peers on failure of the session, the action of the LDP peers on failure of the
TCP connection is as specified in [2] and [4]. TCP connection is as specified in [RFC3212] and
[RFC3036].
All state information and resources associated with non- All state information and resources associated with non-
FT labels MUST be released on the failure of the TCP FT Labels MUST be released on the failure of the TCP
connection, including deprogramming the non-FT label from connection, including deprogramming the non-FT Label from
the switching hardware. This is equivalent to the the switching hardware. This is equivalent to the
behavior specified in [4]. behavior specified in [RFC3036].
If the LDP FT enhancements are in use on an LDP session, If the LDP FT enhancements are in use on an LDP session,
both LDP peers SHOULD preserve state information and both LDP peers SHOULD preserve state information and
resources associated with FT labels exchanged on the LDP resources associated with FT Labels exchanged on the LDP
session. Both LDP peers SHOULD use a timer to release session. Both LDP peers SHOULD use a timer to release
the preserved state information and resources associated the preserved state information and resources associated
with FT-labels if the TCP connection is not restored with FT-labels if the TCP connection is not restored
within a reasonable period. The behavior when this timer within a reasonable period. The behavior when this timer
expires is equivalent to the LDP session failure behavior expires is equivalent to the LDP session failure behavior
described in [4]. described in [RFC3036].
The FT Reconnection Timeout each LDP peer intends to The FT Reconnection Timeout each LDP peer intends to
apply to the LDP session is carried in the FT Session TLV apply to the LDP session is carried in the FT Session TLV
on the LDP Initialization messages. Both LDP peers MUST on the LDP Initialization messages. Both LDP peers MUST
use the value that corresponds to the lesser timeout use the value that corresponds to the lesser timeout
interval of the two proposed timeout values from the LDP interval of the two proposed timeout values from the LDP
Initialization exchange, where a value of zero is treated Initialization exchange, where a value of zero is treated
as positive infinity. as positive infinity.
3.3. Data Forwarding During TCP Connection Failure 3.3. Data Forwarding During TCP Connection Failure
skipping to change at page 11, line 28 skipping to change at page 11, line 9
If an LDP peer has preserved all state information for If an LDP peer has preserved all state information for
previous instantiations of the LDP session, then it previous instantiations of the LDP session, then it
SHOULD set the FT Reconnect Flag to 1 in the FT Session SHOULD set the FT Reconnect Flag to 1 in the FT Session
TLV. Otherwise, it MUST set the FT Reconnect Flag to 0. TLV. Otherwise, it MUST set the FT Reconnect Flag to 0.
If either LDP peer sets the FT Reconnect Flag to 0, or If either LDP peer sets the FT Reconnect Flag to 0, or
omits the FT Session TLV, both LDP peers MUST release any omits the FT Session TLV, both LDP peers MUST release any
state information and resources associated with the state information and resources associated with the
previous instantiation of the LDP session between the previous instantiation of the LDP session between the
same LDP peers, including FT label state and Addresses. same LDP peers, including FT Label state and Addresses.
This ensures that network resources are not permanently This ensures that network resources are not permanently
lost by one LSR if its LDP peer is forced to undergo a lost by one LSR if its LDP peer is forced to undergo a
cold start. cold start.
If an LDP peer changes any session parameters (for If an LDP peer changes any session parameters (for
example, the label space bounds) from the previous example, the label space bounds) from the previous
instantiation the nature of any preserved labels may have instantiation the nature of any preserved labels may have
changed. In particular, previously allocated labels may changed. In particular, previously allocated labels may
now be out of range. For this reason, session now be out of range. For this reason, session
reconnection MUST use the same parameters as were in use reconnection MUST use the same parameters as were in use
on the session before the failure. If an LDP peer on the session before the failure. If an LDP peer
notices that the parameters have been changed by the notices that the parameters have been changed by the
other peer it SHOULD send a Notification message with the other peer it SHOULD send a Notification message with the
'FT Session parameters changed' status code. 'FT Session parameters changed' status code.
If both LDP peers set the FT Reconnect Flag to 1, both If both LDP peers set the FT Reconnect Flag to 1, both
LDP peers MUST use the FT label operation procedures LDP peers MUST use the procedures indicated in this draft
indicated in this draft to complete any label operations to complete any label operations on Sequence Numbered FT
on FT labels that were interrupted by the LDP session Labels that were interrupted by the LDP session failure.
failure.
If an LDP peer receives an LDP Initialization message If an LDP peer receives an LDP Initialization message
with the FT Reconnect Flag set before it sends its own with the FT Reconnect Flag set before it sends its own
Initialization message, but has retained no information Initialization message, but has retained no information
about the previous version of the session, it MUST about the previous version of the session, it MUST
respond with an Initialization message with the FT respond with an Initialization message with the FT
Reconnect Flag clear. If an LDP peer receives an LDP Reconnect Flag clear. If an LDP peer receives an LDP
Initialization message with the FT Reconnect Flag set in Initialization message with the FT Reconnect Flag set in
response to an Initialization message that it has sent response to an Initialization message that it has sent
with the FT Reconnect Flag clear it MUST act as if no with the FT Reconnect Flag clear it MUST act as if no
state was retained by either peer on the session. 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 Label operations on Sequence Numbered FT Labels are made
providing acknowledgement of all LDP messages that affect Fault Tolerant by providing acknowledgement of all LDP
FT labels.Acknowledgements are achieved by means of messages that affect Sequence Numbered FT Labels.
sequence numbers on these LDP messages. Acknowledgements are achieved by means of sequence
numbers on these LDP messages.
The message exchanges used to achieve acknowledgement of The message exchanges used to achieve acknowledgement of
label operations and the procedures used to complete label operations and the procedures used to complete
interrupted label operations are detailed in the section interrupted label operations are detailed in the section
"FT Operations". "FT Operations".
Using these acknowledgements and procedures, it is not Using these acknowledgements and procedures, it is not
necessary for LDP peers to perform a complete re- necessary for LDP peers to perform a complete re-
synchronization of state for all FT labels, either on re- synchronization of state for all Sequence Numbered FT
connection of the LDP session between the LDP peers or on Labels, either on re-connection of the LDP session
a timed basis. between the LDP peers or on a timed basis.
3.6. Check-Pointing 3.6. Check-Pointing
Check-pointing is a useful feature that allows nodes to Check-pointing is a useful feature that allows nodes to
reduce the amount of processing that they need to do to reduce the amount of processing that they need to do to
acknowledge LDP messages. The C bit in the FT Session acknowledge LDP messages. The C bit in the FT Session
TLV is used to indicate that checkpointing is supported. TLV is used to indicate that checkpointing is supported.
Under the normal operation on FT labels, acknowledgments Under the normal operation on Sequence Numbered FT
may be deferred during normal processing and only sent Labels, acknowledgments may be deferred during normal
periodically. Check-pointing may be used to flush processing and only sent periodically. Check-pointing
acknowledgement from a peer by including a sequence may be used to flush acknowledgement from a peer by
number on a Keepalive message requesting acknowledgement including a sequence number on a Keepalive message
of that message and all previous messages. requesting acknowledgement of that message and all
previous messages. In this case, all Sequence Numbered
FT Labels are Checkpointable FT Labels.
If the S bit is not agreed upon, checkpointing may still If the S bit is not agreed upon, checkpointing may still
be used. In this case it is used to acknowledge all be used. In this case it is used to acknowledge all
messages exchanged between the peers. messages exchanged between the peers, and all labels are
Checkpointable FT Labels.
This offers an approach where acknowledgements need not This offers an approach where acknowledgements need not
be sent to every message or even frequently, but are only be sent to every message or even frequently, but are only
sent as check-points in response to requests carried on sent as check-points in response to requests carried on
Keepalive messages. Such an approach may be considered Keepalive messages. Such an approach may be considered
optimal in systems that do not show a high degree of optimal in systems that do not show a high degree of
change over time (such as targeted LDP session or CR-LDP change over time (such as targeted LDP session or CR-LDP
systems) and that are prepared to risk loss of state for systems) and that are prepared to risk loss of state for
the most recent LDP exchanges. More dynamic systems the most recent LDP exchanges. More dynamic systems
(such as LDP discovery sessions) are more likely to want (such as LDP discovery sessions) are more likely to want
skipping to change at page 14, line 39 skipping to change at page 14, line 31
bit in the FT Session TLV on the Session Initialization bit in the FT Session TLV on the Session Initialization
message as described in the section "Establishing an FT message as described in the section "Establishing an FT
LDP Session", both LDP peers MUST apply the procedures LDP Session", both LDP peers MUST apply the procedures
described in this section for FT LDP message exchanges. described in this section for FT LDP message exchanges.
If the LDP session has been negotiated to not use the LDP If the LDP session has been negotiated to not use the LDP
FT enhancements, these procedures MUST NOT be used. FT enhancements, these procedures MUST NOT be used.
4.1. FT LDP Messages 4.1. FT LDP Messages
4.1.1 FT Label Messages 4.1.1 Sequence Numbered FT Label Messages
A label is identified as being an FT label if the initial A label is identified as being a Sequence Numbered FT
Label Request or Label Mapping message relating to that Label if the initial Label Request or Label Mapping
label carries the FT Protection TLV. message relating to that label carries the FT Protection
TLV.
It is a valid implementation option to flag all labels as It is a valid implementation option to flag all labels as
FT labels. Indeed this may be a preferred option for Sequence Numbered FT Labels. Indeed this may be a
implementations wishing to use Keepalive messages preferred option for implementations wishing to use
carrying the FT Protection TLV to achieve periodic saves Keepalive messages carrying the FT Protection TLV to
of the complete label forwarding state. achieve periodic saves of the complete label forwarding
state.
If a label is an FT label, all LDP messages affecting
that label MUST carry the FT Protection TLV in order that
the state of the label can be recovered after a failure
of the LDP session.
A valid option is for no labels on an FT session to be FT
labels.
The checkpointing mechanism (see section 5) is an integral If a label is a Sequence Numbered FT Label, all LDP
part of the FT procedures and is available whenever the FT messages affecting that label MUST carry the FT
procedures are selected. When the FT procedures are in use Protection TLV in order that the state of the label can
checkpointing applies only to FT labels. If no labels on be recovered after a failure of the LDP session.
the session are FT labels but the use of the FT procedures
has been negotiated, checkpointing will not secure any
message exchanges.
If the FT procedures are not in use, checkpointing using the A valid option is for no labels to be Sequence Numbered
Keepalive message applies to all messages exchanged on the FT Labels. In this case checkpointing using the
session. Keepalive message applies to all messages exchanged on
the session.
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 The scope of the FT/non-FT status of a label is limited
to the LDP message exchanges between a pair of LDP peers. to the LDP message exchanges between a pair of LDP peers.
In Ordered Control, when the message is forwarded In Ordered Control, when the message is forwarded
downstream or upstream, the TLV may be present or absent downstream or upstream, the TLV may be present or absent
according to the requirements of the LSR sending the according to the requirements of the LSR sending the
message. message.
If a platform-wide label space is used for FT labels, an If a platform-wide label space is used for FT Labels, an
FT label value MUST NOT be reused until all LDP FT peers FT Label value MUST NOT be reused until all LDP FT peers
to which the label was passed have acknowledged the to which the label was passed have acknowledged the
withdrawal of the FT label, either by an explicit LABEL withdrawal of the FT Label, either by an explicit LABEL
WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP
session is reconnected after failure but without the FT session is reconnected after failure but without the FT
Reconnect Flag set. In the event that a session is not Reconnect Flag set. In the event that a session is not
re-established within the Reconnection Timeout, a label re-established within the Reconnection Timeout, a label
MAY become available for re-use if it is not still in use MAY become available for re-use if it is not still in use
on some other session. 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 If an LDP session uses the LDP FT enhancements, both LDP
skipping to change at page 15, line 57 skipping to change at page 15, line 45
on a previous instantiation of a recovered LDP session is on a previous instantiation of a recovered LDP session is
no longer valid, it MUST explicitly issue an Address no longer valid, it MUST explicitly issue an Address
Withdraw for that address when the session is Withdraw for that address when the session is
reconnected. reconnected.
If the FT Reconnect Flag is not set by both LDP peers on If the FT Reconnect Flag is not set by both LDP peers on
reconnection of an LDP session (i.e. state has not been reconnection of an LDP session (i.e. state has not been
preserved), both LDP peers MUST consider all Addresses to preserved), both LDP peers MUST consider all Addresses to
have been withdrawn. The LDP peers SHOULD issue new have been withdrawn. The LDP peers SHOULD issue new
Address messages for all their valid addresses as Address messages for all their valid addresses as
specified in [4]. specified in [RFC3036].
4.1.3 FT Label Resources Available Notification Messages 4.1.3 Label Resources Available Notifications
In LDP, it is possible that a downstream LSR may not have In LDP, it is possible that a downstream LSR may not have
labels available to respond to a Label Request. In this labels available to respond to a Label Request. In this
case, as specified in RFC3036, the downstream LSR must case, as specified in RFC3036, the downstream LSR must
respond with a Notification - No Label Resources message. respond with a Notification - No Label Resources message.
The upstream LSR then suspends asking for new labels The upstream LSR then suspends asking for new labels
until it receives a Notification - Label Resources 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 session When the FT extensions are used on a session,
implementations may choose whether to secure the label implementations may choose whether to secure the label
resource state of their peer or not. This choice impacts resource state of their peer or not. This choice impacts
the number of LDP messages that will be incorrectly the number of LDP messages that will be incorrectly
routed to a peer with depleted resources on session re- routed to a peer with depleted resources on session re-
establishment, but does not otherwise impact establishment, but does not otherwise impact
interoperability. interoperability.
For full preservation of state: For full preservation of state:
- The downstream LSR must preserve the label availability - The downstream LSR must preserve the label availability
skipping to change at page 18, line 9 skipping to change at page 17, line 54
sequence numbers (because its partner on the session has sequence numbers (because its partner on the session has
not acknowledged them in a timely way) it cannot allocate not acknowledged them in a timely way) it cannot allocate
a new sequence number for any further FT LPD message. It a new sequence number for any further FT LPD message. It
SHOULD send a Notification message with the status code SHOULD send a Notification message with the status code
"FT Seq Numbers Exhausted". "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, If the LDP FT enhancements are in use on an LDP session,
each LDP peer SHOULD NOT release the state information each LDP peer SHOULD NOT release the state information
and resources associated with FT labels exchanged on that and resources associated with FT Labels exchanged on that
LDP session when the TCP connection fails. This is LDP session when the TCP connection fails. This is
contrary to [2] and [4], but allows label operations on contrary to [RFC3212] and [RFC3036], but allows label
FT labels to be completed after re-connection of the TCP operations on FT Labels to be completed after re-
connection. connection of the TCP connection.
Both LDP peers on an LDP session that is using the LDP FT Both LDP peers on an LDP session that is using the LDP FT
enhancements SHOULD preserve the state information and enhancements SHOULD preserve the state information and
resources they hold for that LDP session as described resources they hold for that LDP session as described
below. below.
- An upstream LDP peer SHOULD release the resources (in - An upstream LDP peer SHOULD release the resources (in
particular bandwidth) associated with an FT label when it particular bandwidth) associated with a Sequence Numbered FT
initiates a Label Release or Label Abort message for the Label when it initiates a Label Release or Label Abort
label. The upstream LDP peer MUST preserve state message for the label. The upstream LDP peer MUST preserve
information for the label, even if it releases the resources state information for the Sequence Numbered FT Label, even
associated with the label, as it may need to reissue the if it releases the resources associated with the label, as
label operation if the TCP connection is interrupted. it may need to reissue the label operation if the TCP
connection is interrupted.
- An upstream LDP peer MUST release the state information - An upstream LDP peer MUST release the state information
and resources associated with an FT label when it receives and resources associated with a Sequence Numbered FT Label
an acknowledgement to a Label Release or Label Abort message when it receives an acknowledgement to a Label Release or
that it sent for the label, or when it sends a Label Release Label Abort message that it sent for the label, or when it
message in response to a Label Withdraw message received sends a Label Release message in response to a Label
from the downstream LDP peer. Withdraw message received from the downstream LDP peer.
- A downstream LDP peer SHOULD NOT release the resources - A downstream LDP peer SHOULD NOT release the resources
associated with an FT label when it sends a Label Withdraw associated with a Sequence Numbered FT Label when it sends a
message for the label as it has not yet received Label Withdraw message for the label as it has not yet
confirmation that the upstream LDP peer has ceased to send received confirmation that the upstream LDP peer has ceased
data using the label. The downstream LDP peer MUST NOT to send data using the label. The downstream LDP peer MUST
release the state information it holds for the label as it NOT release the state information it holds for the label as
may yet have to reissue the label operation if the TCP it may yet have to reissue the label operation if the TCP
connection is interrupted. connection is interrupted.
- A downstream LDP peer MUST release the resources and - A downstream LDP peer MUST release the resources and
state information associated with an FT label when it state information associated with a Sequence Numbered FT
receives an acknowledgement to a Label Withdraw message for Label when it receives an acknowledgement to a Label
the label. Withdraw message for the label.
- When the FT Reconnection Timeout expires, an LSR SHOULD - When the FT Reconnection Timeout expires, an LSR SHOULD
release all state information and resources from previous release all state information and resources from previous
instantiations of the (permanently) failed LDP session. instantiations of the (permanently) failed LDP session.
- Either LDP peer MAY elect to release state information - Either LDP peer MAY elect to release state information
based on its internal knowledge of the loss of integrity of based on its internal knowledge of the loss of integrity of
the state information or an inability to pend (or queue) LDP the state information or an inability to pend (or queue) LDP
operations (as described in section 4.4.1) during a TCP operations (as described in section 4.4.1) during a TCP
failure. That is, the peer is not required to wait for the failure. That is, the peer is not required to wait for the
skipping to change at page 19, line 33 skipping to change at page 19, line 21
set the E-bit without knowledge of the implementation of set the E-bit without knowledge of the implementation of
that partner LSR. that partner LSR.
Note that the "Temporary Shutdown" status code does not have Note that the "Temporary Shutdown" status code does not have
the E-bit set, and MAY be used during maintenance or upgrade the E-bit set, and MAY be used during maintenance or upgrade
operations to indicate that the LSR intends to preserve operations to indicate that the LSR intends to preserve
state across a closure and re-establishment of the TCP state across a closure and re-establishment of the TCP
session. session.
- If an LSR determines that it must release state for any - If an LSR determines that it must release state for any
single FT label during a failure of the TCP connection on single FT Label during a failure of the TCP connection on
which that label was exchanged, it MUST release all state which that label was exchanged, it MUST release all state
for all labels on the LDP session. for all labels on the LDP session.
The release of state information and resources associated The release of state information and resources associated
with non-FT labels is as described in [2] and [4]. with non-FT labels is as described in [RFC3212] and
[RFC3036].
Note that a Label Release and the acknowledgement to a Note that a Label Release and the acknowledgement to a
Label Withdraw may be received by a downstream LSR in any Label Withdraw may be received by a downstream LSR in any
order. The downstream LSR MAY release its resources on order. The downstream LSR MAY release its resources on
receipt of the first message and MUST release its receipt of the first message and MUST release its
resources on receipt of the second message. 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 When an LSR discovers or is notified of a TCP connection
skipping to change at page 20, line 32 skipping to change at page 20, line 21
Reconnect Flag to 0 if it released the preserved state 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 If the TCP connection is successfully re-established
within the FT Reconnection Timeout, both peers MUST re- within the FT Reconnection Timeout, both peers MUST re-
issue LDP operations that were interrupted by (that is, issue LDP operations that were interrupted by (that is,
un-acknowledged as a result of) the TCP connection un-acknowledged as a result of) the TCP connection
failure. This procedure is described in section "FT 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 (see [4] section The Hold Timer for an FT LDP Session (see [RFC3036]
2.5.5) SHOULD be ignored while the FT Reconnection Timer section 2.5.5) SHOULD be ignored while the FT
is running. The hold timer SHOULD be restarted when the Reconnection Timer is running. The hold timer SHOULD be
TCP connection is re-established. 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 When the LDP FT enhancements are in use for an LDP
session, it is possible that an LSR may determine that it session, it is possible that an LSR may determine that it
needs to send an LDP message to an LDP peer but that the needs to send an LDP message to an LDP peer but that the
TCP connection to that peer is currently down. These TCP connection to that peer is currently down. These
label operations affect the state of FT labels preserved label operations affect the state of FT Labels preserved
for the failed TCP connection, so it is important that for the failed TCP connection, so it is important that
the state changes are passed to the LDP peer when the TCP the state changes are passed to the LDP peer when the TCP
connection is restored. connection is restored.
If an LSR determines that it needs to issue a new FT LDP If an LSR determines that it needs to issue a new FT LDP
operation to an LDP peer to which the TCP connection is operation to an LDP peer to which the TCP connection is
currently failed, it MUST pend the operation (e.g. on a currently failed, it MUST pend the operation (e.g. on a
queue) and complete that operation with the LDP peer when queue) and complete that operation with the LDP peer when
the TCP connection is restored, unless the label the TCP connection is restored, unless the label
operation is overridden by a subsequent additional operation is overridden by a subsequent additional
operation during the TCP connection failure (see section operation during the TCP connection failure (see section
"FT Procedure After TCP Re-connection"). "FT Procedure After TCP Re-connection").
If, during TCP Failure, an LSR determines that it cannot If, during TCP Failure, an LSR determines that it cannot
pend an operation which it cannot simply fail (for pend an operation which it cannot simply fail (for
example a Label Withdraw, Release, or Abort operation), example, a Label Withdraw, Release or Abort operation),
it MUST NOT attempt to re-establish the previous LDP it MUST NOT attempt to re-establish the previous LDP
session. The LSR MUST behave as if the Reconnection session. The LSR MUST behave as if the Reconnection
Timer expired and release all state information with Timer expired and release all state information with
respect to the LDP peer. An LSR may be unable (or respect to the LDP peer. An LSR may be unable (or
unwilling) to pend operations; for instance, if a major unwilling) to pend operations; for instance, if a major
routing transition occurred while TCP was inoperable routing transition occurred while TCP was inoperable
between LDP peers it might result in excessively large between LDP peers it might result in excessively large
numbers of FT LDP Operations. An LSR that releases state numbers of FT LDP Operations. An LSR that releases state
before the expiration of the Reconnection Timeout MUST before the expiration of the Reconnection Timeout MUST
NOT re-use any label that was in use on the session until NOT re-use any label that was in use on the session until
the Reconnection Timeout has expired. the Reconnection Timeout has expired.
In ordered operation, received FT LDP operations that In ordered operation, received FT LDP operations that
cannot be correctly forwarded because of a TCP connection cannot be correctly forwarded because of a TCP connection
failure MAY be processed immediately (provided sufficient failure MAY be processed immediately (provided sufficient
state is kept to forward the label operation) or pended state is kept to forward the label operation) or pended
for processing when the onward TCP connection is restored for processing when the onward TCP connection is restored
and the operation can be correctly forwarded upstream or and the operation can be correctly forwarded upstream or
downstream. Operations on existing FT labels SHOULD NOT 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 It is RECOMMENDED that Label Request operations for new
FT labels are not pended awaiting the re-establishment of FT Labels are not pended awaiting the re-establishment of
TCP connection that is awaiting recovery at the time the TCP connection that is awaiting recovery at the time the
LSR determines that it needs to issue the Label Request LSR determines that it needs to issue the Label Request
message. Instead, such Label Request operations SHOULD message. Instead, such Label Request operations SHOULD
be failed and, if necessary, a notification message be failed and, if necessary, a notification message
containing the "No LDP Session" status code sent containing the "No LDP Session" status code sent
upstream. upstream.
Label Requests for new non-FT labels MUST be rejected Label Requests for new non-FT Labels MUST be rejected
during TCP connection failure, as specified in [2] and during TCP connection failure, as specified in [RFC3212]
[4]. and [RFC3036].
4.5. FT Procedure After TCP Re-connection 4.5. FT Procedure After TCP Re-connection
The FT operation handshaking described above means that The FT operation handshaking described above means that
all state changes for FT labels and Address messages are all state changes for Sequence Numbered FT Labels and
confirmed or reproducible at each LSR. Address messages are confirmed or reproducible at each LSR.
If the TCP connection between LDP peers fails but is re- If the TCP connection between LDP peers fails but is re-
connected within the FT Reconnection Timeout, and both connected within the FT Reconnection Timeout, and both
LSRs have indicated they will be re-establishing the LSRs have indicated they will be re-establishing the
previous LDP session, both LDP peers on the connection previous LDP session, both LDP peers on the connection
MUST complete any label operations for FT labels that MUST complete any label operations for Sequence Numbered
were interrupted by the failure and re-connection of the FT Labels that were interrupted by the failure and re-
TCP connection. connection of the TCP connection.
The procedures for FT Reconnection Timeout MAY have been The procedures for FT Reconnection Timeout MAY have been
invoked as a result of either LDP peer being unable (or invoked as a result of either LDP peer being unable (or
unwilling) to pend operations which occurred during the unwilling) to pend operations which occurred during the
TCP Failure (as described in section 4.4.1). TCP Failure (as described in section 4.4.1).
If, for any reason, an LSR has been unable to pend If, for any reason, an LSR has been unable to pend operations
operations with respect to an LDP peer, as described in with respect to an LDP peer, as described in section 4.4.1, the
section 4.4.1, the LSR MUST set the FT Reconnect Flag to LSR MUST set the FT Reconnect Flag to 0 on re-connection to that
0 on re-connection to that LDP peer indicating that no FT LDP peer indicating that no FT state has been preserved.
state has been preserved.
Label operations are completed using the procedure Label operations are completed using the procedure described below.
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, On restoration of the TCP connection between LDP peers,
any FT LDP messages that were lost because of the TCP any LDP messages for Sequence Numbered FT Labels that
connection failure are re-issued. The LDP peer that were lost because of the TCP connection failure are re-
receives a re-issued message processes the message as if issued. The LDP peer that receives a re-issued message
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 "Net-zero" combinations of messages need not be re-issued
after re-establishment of the TCP connection between LDP after re-establishment of the TCP connection between LDP
peers. This leads to the following rules for re-issuing peers. This leads to the following rules for re-issuing
messages that are not ACKed by the LDP peer on the LDP messages that are not ACKed by the LDP peer on the LDP
Initialization message exchange after re-connection of Initialization message exchange after re-connection of
the TCP session. the TCP session.
- A Label Request message MUST be re-issued unless a Label - A Label Request message MUST be re-issued unless a Label Abort
Abort would be re-issued for the same FT label. would be re-issued for the same Sequence Numbered FT Label.
- A Label Mapping message MUST be re-issued unless a Label - A Label Mapping message MUST be re-issued unless a Label
Withdraw message would be re-issued for the same FT label. Withdraw message would be re-issued for the same Sequence
Numbered 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 Protection TLV MUST be re-issued if an acknowledgement had
not previously been received. not previously been received.
Any FT label operations that were pended (see section "FT Any FT Label operations that were pended (see section
Label Operations During TCP Failure") during the TCP 4.4.1) during the TCP connection failure MUST also be
connection failure MUST also be issued on re- issued on re-establishment of the LDP session, except
establishment of the LDP session, except where they form where they form part of a "net-zero" combination of
part of a "net-zero" combination of messages according to messages according to the above rules.
the above rules.
The determination of "net-zero" FT label operations The determination of "net-zero" FT Label operations
according to the above rules MAY be performed on pended according to the above rules MAY be performed on pended
messages prior to the re-establishment of the TCP messages prior to the re-establishment of the TCP
connection in order to optimize the use of queue connection in order to optimize the use of queue
resources. Messages that were sent to the LDP peer resources. Messages that were sent to the LDP peer
before the TCP connection failure, or pended messages before the TCP connection failure, or pended messages
that are paired with them, MUST NOT be subject to such that are paired with them, MUST NOT be subject to such
optimization until an FT ACK TLV is received from the LDP optimization until an FT ACK TLV is received from the LDP
peer. This ACK allows the LSR to identify which messages peer. This ACK allows the LSR to identify which messages
were received by the LDP peer prior to the TCP connection were received by the LDP peer prior to the TCP connection
failure. failure.
4.5.2 Interaction with CR-LDP LSP Modification 4.5.2 Interaction with CR-LDP LSP Modification
Re-issuing LDP messages for FT operation is orthogonal to Re-issuing LDP messages for FT operation is orthogonal to
the use of duplicate messages marked with the Modify the use of duplicate messages marked with the Modify
ActFlg, as specified in [5]. Each time an LSR uses the ActFlg, as specified in [RFC3214]. Each time an LSR uses
modification procedure for an FT LSP to issue a new Label the modification procedure for an FT LSP to issue a new
Request message, the FT label operation procedures MUST Label Request message, the FT label operation procedures
be separately applied to the new Label Request message. MUST be separately applied to the new Label Request
message to the same degree that they were applied to the
original Label Request.
5. Checkpointing Procedures 5. Checkpointing Procedures
Checkpointing can be selected independently from the FT Checkpointing can be selected independently from the FT
procedures described above by using the C bit in the FT procedures described above by using the C bit in the FT
Session TLV on the Session Initialization message. Note, Session TLV on the Session Initialization message. Note,
however, that checkpointing is an integral part of the FT however, that checkpointing is an integral part of the FT
procedures. Setting the S and the C bit will achieve the procedures. Setting the S and the C bit will achieve the
same function as setting just the S bit. same function as setting just the S bit.
If the C bit is set, but the S bit is not set, no label If the C bit is set, but the S bit is not set, no label
is an FT label. Checkpointing is used to synchronize all is aSequence Numbered FT Label. Instead, all labels are
labels exchanges for labels requested or distributed by Checkpointable FT Labels. Checkpointing is used to
the LDP peer requesting the exchange up to the time of synchronize all labels exchanges. No message apart from
requesting the checkpoint. No message apart from the the checkpoint request and acknowledgement carries an
checkpoint request and acknowledgement carries an active active sequence number. (Note that the Session
sequence number. (Note that the Session Initialization Initialization message may carry a sequence number to
message may carry a sequence number to confirm that the confirm that the checkpoint is still in place).
checkpoint is still in place).
It is an implementation matter to decide the ordering of It is an implementation matter to decide the ordering of
received messages and checkpoint requests to ensure that received messages and checkpoint requests to ensure that
checkpoint acknowledgements are secured. checkpoint acknowledgements are secured.
If the S and C bits are both set, or only the S bit is If the S and C bits are both set, or only the S bit is
set, checkpointing applies only to FT labels and to set, checkpointing applies only to Sequence Numbered FT
address messages. Labels and to address messages.
The set of all messages that are checkpointed in this way The set of all messages that are checkpointed in this way
is called the Checkpointable Messages. is called the Checkpointable Messages.
5.1 Checkpointing with the Keepalive Message 5.1. Checkpointing with the Keepalive Message
If an LSR receives a FT Protection TLV on a Keepalive If an LSR receives a FT Protection TLV on a Keepalive
message, this is a request to flush the acknowledgements message, this is a request to flush the acknowledgements
for all previously received Checkpointable Messages on for all previously received Checkpointable Messages on
the session. the session.
As soon as the LSR has completed securing the As soon as the LSR has completed securing the
Checkpointable Messages (or state changes consequent on Checkpointable Messages (or state changes consequent on
those messages) received before the Keepalive, it MUST those messages) received before the Keepalive, it MUST
send an acknowledgement to the sequence number of the send an acknowledgement to the sequence number of the
skipping to change at page 24, line 29 skipping to change at page 24, line 5
acknowledgements have been stored up, this may be acknowledgements have been stored up, this may be
immediately on receipt of the Keepalive. immediately on receipt of the Keepalive.
An example message flow showing this use of the Keepalive An example message flow showing this use of the Keepalive
message to perform a periodic check-point of state is message to perform a periodic check-point of state is
shown in section 8. shown in section 8.
An example message flow showing the use of checkpointing An example message flow showing the use of checkpointing
without the FT procedures is shown in section 8. without the FT procedures is shown in section 8.
5.2 Quiesce and Keepalive 5.2. Quiesce and Keepalive
If the Keepalive Message also contains the FT Cork TLV, If the Keepalive Message also contains the FT Cork TLV,
this indicates that the peer LSR wishes to quiesce the this indicates that the peer LSR wishes to quiesce the
session prior to a graceful restart. session prior to a graceful restart.
It is RECOMMENDED that on receiving a Keepalive with the It is RECOMMENDED that on receiving a Keepalive with the
FT CORK TLV, an LSR should cease to send any further FT CORK TLV, an LSR should cease to send any further
label or address related messages on the session until it label or address related messages on the session until it
has been disconnected and reconnected, other than any has been disconnected and reconnected, other than any
messages generated while processing and securing any messages generated while processing and securing any
skipping to change at page 26, line 6 skipping to change at page 25, line 29
FT Protection FT Protection
If present, specifies FT Sequence Number If present, specifies FT Sequence Number
for the LDP message. When present on a for the LDP message. When present on a
Keepalive message, this indicates a Keepalive message, this indicates a
solicited flush of the acknowledgements to solicited flush of the acknowledgements to
all previous LDP messages containing all previous LDP messages containing
sequence numbers and issued by the sender sequence numbers and issued by the sender
of the Keepalive on the same session. of the Keepalive on the same session.
FT Cork FT Cork
Only permitted if the FT Protection TLV is Indicates that the remote LSR wishes to
also present. Indicates that the remote quiesce the LDP session. See section 5 for
LSR wishes to quiesce the LDP session. See the recommended action in such cases.
section 4.2 for the recommended action in
such cases.
FT ACK TLV FT ACK TLV
If present, specifies the most recent FT If present, specifies the most recent FT
message that the sending LDP peer has been message that the sending LDP peer has been
able to secure. able to secure.
6.3. All Other LDP Session Messages 6.3. All Other LDP Session Messages
The LDP FT enhancements add the following optional The LDP FT enhancements add the following optional
parameters to all other message types that flow on an LDP parameters to all other message types that flow on an LDP
skipping to change at page 27, line 25 skipping to change at page 26, line 45
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 FT Session parameters / 1 0x000000xx
changed changed
Unexpected FT Cork TLV 1 0x000000xx Unexpected FT Cork TLV 1 0x000000xx
The Temporary Shutdown status code SHOULD be used in The Temporary Shutdown status code SHOULD be used in
place of the Shutdown status code (which has the E-bit place of the Shutdown status code (which has the E-bit
set) if the LSR that is shutting down wishes to inform set) if the LSR that is shutting down wishes to inform
its LDP peer that it expects to be able to preserve FT its LDP peer that it expects to be able to preserve FT
label state and to return to service before the FT Label state and to return to service before the FT
Reconnection Timer expires. Reconnection Timer expires.
7.2. FT Session TLV 7.2. FT Session TLV
LDP peers can negotiate whether the LDP session between LDP peers can negotiate whether the LDP session between
them supports FT extensions by using a new OPTIONAL them supports FT extensions by using a new OPTIONAL
parameter, the FT Session TLV, on LDP Initialization parameter, the FT Session TLV, on LDP Initialization
Messages. Messages.
The FT Session TLV is encoded as follows. The FT Session TLV is encoded as follows.
skipping to change at page 27, line 50 skipping to change at page 27, line 27
|1|0| FT Session TLV (0x0503) | Length (= 12) | |1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved | | FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) | | FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) | | Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags FT Flags
FT Flags: A 16 bit field that indicates various
attributes the FT support on this LDP session. FT Flags: A 16 bit field that indicates
This fields is formatted as follows: various attributes the FT support on this
LDP session. This fields is formatted as
follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L| |R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag. R: FT Reconnect Flag.
Set to 1 if the sending LSR has Set to 1 if the sending LSR has
preserved state and resources for all preserved state and resources for all
FT-labels since the previous LDP FT-labels since the previous LDP
session between the same LDP peers, session between the same LDP peers,
and set to 0 otherwise. See the and set to 0 otherwise. See the
section "FT LDP Session Reconnection" section "FT LDP Session Reconnection"
for details of how this flag is used. for details of how this flag is used.
skipping to change at page 28, line 24 skipping to change at page 28, line 11
If the FT Reconnect Flag is set, the If the FT Reconnect Flag is set, the
sending LSR MUST include an FT ACK TLV sending LSR MUST include an FT ACK TLV
on the LDP Initialization message. on the LDP Initialization message.
S: Save State Flag. S: Save State Flag.
Set to 1 if the use of the FT Set to 1 if the use of the FT
Protection TLV is supported on Protection TLV is supported on
messages other than the KeepAlive messages other than the KeepAlive
message used for chekpointing (see the message used for chekpointing (see the
C bit) C bit). I.e., the S bit indicates hat
some label on the session may be a
Sequence Numbered FT Label.
A: All-Label Protection Required A: All-Label Protection Required
Set to 1 if all labels on the session Set to 1 if all labels on the session
MUST be treated as FT Labels. This MUST be treated as Sequence Numbered
removes from a node the option of FT Labels. This removes from a node
treating some labels as FT labels and the option of treating some labels as
some labels as non-FT labels. FT Labels and some labels as non-FT
Labels.
Passing this information may be Passing this information may be
considered helpful to a peer since it considered helpful to a peer since it
may allow it to make optimizations in may allow it to make optimizations in
its processing. its processing.
The A bit only has meaning if the S The A bit only has meaning if the S
bit is set. bit is set.
C: Checkpointing Flag. C: Checkpointing Flag.
Set to 1 to indicate that the Set to 1 to indicate that the
checkpointing procedures in this draft checkpointing procedures in this draft
are in use. are in use.
If the S bit is also set to 1 then the If the S bit is also set to 1 then the
C bit indicates that checkpointing is C bit indicates that checkpointing is
applied only to those message applied only to Sequence Numbered FT
exchanges that carry the FT Protection Labels.
TLV.
If the S bit is set to 0 (zero) then If the S bit is set to 0 (zero) then
the C bit indicates that checkpointing the C bit indicates that checkpointing
applies to all message exchanges on applies to all labels - all labels are
the session. Checkpointable FT Labels.
L: Learn From Network Flag. L: Learn From Network Flag.
Set to 1 if the Fault Recovery Set to 1 if the Fault Recovery
procedures of [12] are to be used to procedures of [LDP-RESTART] are to be
re-learn state from the network. used to re-learn state from the
network.
It is not valid for all of the S, C and L bits to be zero. It is not valid for all of the S, C and L
bits to be zero.
It is not valid for both the L and either the S or C bits It is not valid for both the L and either
to be set to 1. the S or C bits to be set to 1.
All other bits in this field are currently
reserved and SHOULD be set to zero on
transmission and ignored on receipt.
The following table summarizes the settings
of these bits.
S A C L Comments
=========================
0 x 0 0 Invalid
0 x 0 1 See [LDP-RESTART]
0 x 1 0 Checkpointing of all labels
0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels
1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid.
FT Reconnection Timeout FT Reconnection Timeout
If the S bit or C bit in the FT Flags field If the S bit or C bit in the FT Flags field
is set this indicates the period of time is set this indicates the period of time
the sending LSR will preserve state and the sending LSR will preserve state and
resources for FT labels exchanged on the resources for FT Labels exchanged on the
previous instantiation of an FT LDP session previous instantiation of an FT LDP session
that has currently failed. The timeout is that has currently failed. The timeout is
encoded as a 32-bit unsigned integer number encoded as a 32-bit unsigned integer number
of milliseconds. of milliseconds.
A value of zero in this field means that A value of zero in this field means that
the sending LSR will preserve state and the sending LSR will preserve state and
resources indefinitely. resources indefinitely.
See the section "FT Procedure After TCP See section 4.4 for details of how this
Failure" for details of how this field is field is used.
used.
If the L bit is set to 1 in the FT Flags If the L bit is set to 1 in the FT Flags
field, the meaning of this field is defined field, the meaning of this field is defined
in [12]. in [LDP-RESTART].
Recovery Time Recovery Time
The Recovery Time only has meaning if the L The Recovery Time only has meaning if the L
bit is set in the FT Flags. The meaning is bit is set in the FT Flags. The meaning is
defined in [12]. defined in [LDP-RESTART].
7.3. FT Protection TLV 7.3. FT Protection TLV
LDP peers use the FT Protection TLV to indicate that an LDP peers use the FT Protection TLV to indicate that an
LDP message contains an FT label operation. LDP message contains an FT label operation.
The FT Protection TLV MUST NOT be used in messages The FT Protection TLV MUST NOT be used in messages
flowing on an LDP session that does not support the LDP flowing on an LDP session that does not support the LDP
FT enhancements. Its presence in such messages SHALL be FT enhancements. Its presence in such messages SHALL be
treated as a protocol error by the receiving LDP peer treated as a protocol error by the receiving LDP peer
which SHOULD send a Notification message with the which SHOULD send a Notification message with the
'Unexpected TLV Session Not FT' status code. 'Unexpected TLV Session Not FT' status code. LSRs that
do not recognize this TLV SHOULD respond with a
Notification message with the 'Unknown TLV' status code.
The FT Protection TLV MAY be carried on an LDP message The FT Protection TLV MAY be carried on an LDP message
transported on the LDP session after the initial exchange transported on the LDP session after the initial exchange
of LDP Initialization messages. In particular, this TLV of LDP Initialization messages. In particular, this TLV
MAY optionally be present on the following messages: MAY optionally be present on the following messages:
- Label Request Messages in downstream on-demand - Label Request Messages in downstream on-demand
distribution mode distribution mode
- Label Mapping messages in downstream unsolicited mode - Label Mapping messages in downstream unsolicited mode
- Keepalive messages used to request flushing of - Keepalive messages used to request flushing of
acknowledgement of all previous messages that contained this acknowledgement of all previous messages that contained this
TLV. TLV.
If a label is to be an FT label, then the Protection TLV If a label is to be a Sequence Numbered FT Label, then
MUST be present: the Protection TLV MUST be 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 Here 'subsequent messages concerning this label' means
any message whose Label TLV specifies this label or whose any message whose Label TLV specifies this label or whose
Label Request Message ID TLV specifies the initial Label Label Request Message ID TLV specifies the initial Label
Request message. Request message.
If a label is not to be an FT label, then the Protection If a label is not to be a Sequence Numbered FT Label,
TLV MUST NOT be present on any of these messages. The then the Protection TLV MUST NOT be present on any of
presence of the FT TLV on a message relating to a non-FT these messages that relate to the label. The presence of
label SHALL be treated as a protocol error by the the FT TLV on a message relating to a non-FT Label SHALL
receiving LDP peer which SHOULD send a notification be treated as a protocol error by the receiving LDP peer
message with the 'Unexpected TLV Label Not FT' status which SHOULD send a notification message with the
code. 'Unexpected TLV Label Not FT' status code.
Where a Label Withdraw or Label Release message contains Where a Label Withdraw or Label Release message contains
only a FEC TLV and does not identify a single specific only a FEC TLV and does not identify a single specific
label, the FT TLV should be included in the message if label, the FT TLV should be included in the message if
any label affected by the message is an FT label. If any label affected by the message is a Sequence Numbered
there is any doubt as to whether an FT TLV should be FT Label. If there is any doubt as to whether an FT TLV
present, it is RECOMMENDED that the sender add the TLV. should be present, it is RECOMMENDED that the sender add
the TLV.
When an LDP peer receives a Label Withdraw Message or When an LDP peer receives a Label Withdraw Message or
Label Release message that contains only a FEC, it SHALL Label Release message that contains only a FEC, it SHALL
accept the FT TLV if it is present regardless of the FT accept the FT TLV if it is present regardless of the FT
status of the labels which it affects. status of the labels which it affects.
If an LDP session is an FT session as determined by the If an LDP session is an FT session as determined by the
presence of the FT Session TLV with the S bit set on the presence of the FT Session TLV with the S bit set on the
LDP Initialization messages, the FT Protection TLV MUST LDP Initialization messages, the FT Protection TLV MUST
be present on all Address messages on the session. be present on all Address messages on the session.
skipping to change at page 31, line 24 skipping to change at page 31, line 42
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 sequence number is encoded The sequence number for this Sequence
as a 32-bit unsigned integer. The initial Numbered FT Label operation. The sequence
value for this field on a new LDP session number is encoded as a 32-bit unsigned
is 0x00000001 and is incremented by one for integer. The initial value for this field
each FT LDP message issued by the sending on a new LDP session is 0x00000001 and is
LSR on this LDP session. This field may incremented by one for each FT LDP message
wrap from 0xFFFFFFFF to 0x00000001. issued by the sending LSR on this LDP
session. This field may wrap from
0xFFFFFFFF to 0x00000001.
This field MUST be reset to 0x00000001 if This field MUST be reset to 0x00000001 if
either LDP peer does not set the FT either LDP peer does not set the FT
Reconnect Flag on re-establishment of the Reconnect Flag on re-establishment of the
TCP connection. TCP connection.
See the section "FT Operation Acks" for See the section "FT Operation Acks" for
details of how this field is used. details of how this field is used.
The special use of 0x00000000 is discussed The special use of 0x00000000 is discussed
in the section "FT ACK TLV" below. in the section "FT ACK TLV" below.
If an LSR receives an FT Protection TLV on a session that If an LSR receives an FT Protection TLV on a session that
does not support the FT LDP enhancements, it SHOULD send does not support the FT LDP enhancements, it SHOULD send
a Notification message to its LDP peer containing the a Notification message to its LDP peer containing the
"Unexpected TLV, Session Not FT" status code. "Unexpected TLV, Session Not FT" status code. LSRs that
do not recognize this TLV SHOULD respond with a
Notification message with the 'Unknown TLV' status code.
If an LSR receives an FT Protection TLV on an operation If an LSR receives an FT Protection TLV on an operation
affecting a label that it believes is a non-FT label, it affecting a label that it believes is a non-FT Label, it
SHOULD send a Notification message to its LDP peer SHOULD send a Notification message to its LDP peer
containing the "Unexpected TLV, Label Not FT" status containing the "Unexpected TLV, Label Not FT" status
code. code.
If an LSR receives a message without the FT Protection If an LSR receives a message without the FT Protection
TLV affecting a label that it believes is an FT label, it TLV affecting a label that it believes is a Sequence
SHOULD send a Notification message to its LDP peer Numbered FT Label, it SHOULD send a Notification message
containing the "Missing FT Protection TLV" status code. to its LDP peer containing the "Missing FT Protection
TLV" status code.
If an LSR receives an FT Protection TLV containing a zero If an LSR receives an FT Protection TLV containing a zero
FT Sequence Number, it SHOULD send a Notification message FT Sequence Number, it SHOULD send a Notification message
to its LDP peer containing the "Zero FT Seqnum" status to its LDP peer containing the "Zero FT Seqnum" status
code. code.
7.4. FT ACK TLV 7.4. FT ACK TLV
LDP peers use the FT ACK TLV to acknowledge FT label LDP peers use the FT ACK TLV to acknowledge FT Label
operations. 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 that does not support the LDP FT LDP session that does not support the LDP FT
enhancements. Its presence on such messages SHALL be enhancements. Its presence on such messages SHALL be
treated as a protocol error by the receiving LDP peer. treated as a protocol error by the receiving LDP peer.
The FT ACK TLV MAY be present on any LDP message The FT ACK TLV MAY be present on any LDP message
exchanged on an LDP session after the initial LDP exchanged on an LDP session after the initial LDP
Initialization messages. It is RECOMMENDED that the FT Initialization messages. It is RECOMMENDED that the FT
skipping to change at page 32, line 41 skipping to change at page 33, line 4
The FT ACK TLV is encoded as follows. The FT ACK 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 ACK (0x0504) | Length (= 4) | |0|0| FT ACK (0x0504) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number | | FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT ACK Sequence Number FT ACK Sequence Number
The sequence number for this most recent FT
The sequence number for the most recent FT
label message that the sending LDP peer has label message that the sending LDP peer has
received from the receiving LDP peer and received from the receiving LDP peer and
secured against failure of the LDP session. secured against failure of the LDP session.
It is not necessary for the sending peer to It is not necessary for the sending peer to
have fully processed the message before have fully processed the message before
ACKing it. For example, an LSR MAY ACK a ACKing it. For example, an LSR MAY ACK a
Label Request message as soon as it has Label Request message as soon as it has
securely recorded the message, without securely recorded the message, without
waiting until it can send the Label Mapping waiting until it can send the Label Mapping
message in response. message in response.
skipping to change at page 33, line 24 skipping to change at page 33, line 37
FT label operations on this LDP session. FT label operations on this LDP session.
This would apply to LDP sessions to new LDP This would apply to LDP sessions to new LDP
peers or after an LSR determines that it peers or after an LSR determines that it
must drop all state for a failed TCP must drop all state for a failed TCP
connection. connection.
See the section "FT Operation Acks" for See the section "FT Operation Acks" for
details of how this field is used. details of how this field is used.
If an LSR receives a message affecting a label that it If an LSR receives a message affecting a label that it
believes is an FT label and that message does not contain believes is a Sequence Numbered FT Label and that message
the FT Protection TLV, it SHOULD send a Notification does not contain the FT Protection TLV, it SHOULD send a
message to its LDP peer containing the "Missing FT Notification message to its LDP peer containing the
Protection TLV" status code. "Missing FT Protection TLV" status code.
If an LSR receives an FT ACK TLV that contains an FT ACK If an LSR receives an FT ACK TLV that contains an FT ACK
Sequence Number that is less than the previously received Sequence Number that is less than the previously received
FT ACK Sequence Number (remembering to take account of FT ACK Sequence Number (remembering to take account of
wrapping), it SHOULD send a Notification message to its wrapping), it SHOULD send a Notification message to its
LDP peer containing the "FT ACK Sequence Error" status LDP peer containing the "FT ACK Sequence Error" status
code. code.
7.5. FT Cork TLV 7.5. FT Cork TLV
skipping to change at page 33, line 51 skipping to change at page 34, line 20
control-plane software upgrade. control-plane software upgrade.
The FT Cork TLV is encoded as follows. The FT Cork 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 Cork (0x0505) | Length (= 0) | |0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On receipt of a Keepalive message with the FT Cork TLV On receipt of a Keepalive message with the FT Cork TLV and the FT
and the FT Protection TLV, an LSR SHOULD perform the Protection TLV, an LSR SHOULD perform the following actions.
following actions
- Process and secure any messages from the peer LSR that - Process and secure any messages from the peer LSR that
have sequence numbers less than (accounting for wrap) that have sequence numbers less than (accounting for wrap) that
contained in the FT Protection TLV on the Keepalive message. contained in the FT Protection TLV on the Keepalive message.
- Send a Keepalive message back to the peer containing the - Send a Keepalive message back to the peer containing the
FT Cork TLV and the FT ACK TLV specifying the FT ACK FT Cork TLV and the FT ACK TLV specifying the FT ACK
sequence number equal to that in the original Keepalive sequence number equal to that in the original Keepalive
message (i.e. ACKing all messages up to that point). message (i.e. ACKing all messages up to that point).
skipping to change at page 34, line 21 skipping to change at page 34, line 43
messages it has sent containing the FT Protection TLV, then messages it has sent containing the FT Protection TLV, then
also include an FT Protection TLV on the Keepalive sent to also include an FT Protection TLV on the Keepalive sent to
the peer LSR. This tells the remote peer that the local LSR the peer LSR. This tells the remote peer that the local LSR
has saved state prior to quiesce but is still awaiting has saved state prior to quiesce but is still awaiting
confirmation that the remote peer has saved state. confirmation that the remote peer has saved state.
- Cease sending any further state changing messages on this - Cease sending any further state changing messages on this
LDP session until it has been disconnected and recovered. LDP session until it has been disconnected and recovered.
On receipt of a Keepalive message with the FT Cork TLV On receipt of a Keepalive message with the FT Cork TLV
and the FT ACK TLV (but NOT the FT Protection TLV), an and an FT ACK TLV that acknowledges the previously sent
LSR knows that 3-way handshake it initiated is complete Keepalive that carried the FT Cork TLV, an LSR knows that
and it SHOULD now send a "Temporary Shutdown" quiesce is complete. If the received Keepalive also
Notification message, disconnect the TCP session and carries the FT Protection TLV, the LSR must respond with
perform whatever control plane actions required this a further Keepalive to complete the 3-way handshake. It
session shutdown. SHOULD now send a "Temporary Shutdown" Notification
message, disconnect the TCP session and perform whatever
control plane actions required this session shutdown.
An example such 3-way handshake for controlled shutdown An example such 3-way handshake for controlled shutdown
is given in section 8. is given in section 8.
If an LSR receives a message that should not carry the FT If an LSR receives a message that should not carry the FT
Cork TLV, or if the FT Cork TLV is used on a Keepalive Cork TLV, or if the FT Cork TLV is used on a Keepalive
message without one of the FT Protection or FT ACK TLVs message without one of the FT Protection or FT ACK TLVs
present, , it SHOULD send a Notification message to its present, , it SHOULD send a Notification message to its
LDP peer containing the "Unexpected FR Cork TLV" status LDP peer containing the "Unexpected FR Cork TLV" status code.
code.
8. Example Use 8. Example Use
Consider two LDP peers, P1 and P2, implementing LDP over Consider two LDP peers, P1 and P2, implementing LDP over
a TCP connection that connects them, and the message flow a TCP connection that connects them, and the message flow
shown below. shown below.
The parameters shown on each message shown below are as The parameters shown on each message shown below are as
follows: follows:
skipping to change at page 42, line 5 skipping to change at page 43, line 5
: <-------------------------- : <--------------------------
: :
===== TCP Session restored ===== ===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96) (11) LDP Init(n/a,n/a,96)
---------------------------> --------------------------->
LDP Init(n/a,n/a,31) LDP Init(n/a,n/a,31)
<--------------------------- <---------------------------
Label Withdraw(L1,97,-) Label Withdraw(L1,97,-)
<--------------------------- <---------------------------
Notes: Notes:
======
This example operates much as the previous one. However, This example operates much as the previous one. However,
at (1), (2), (3), (4) and (5) no acknowledgements are at (1), (2), (3), (4) and (5) no acknowledgements are
made. made.
At (6), P1 determines that graceful shutdown is required At (6), P1 determines that graceful shutdown is required
and sends a Keepalive acknowledging all previously and sends a Keepalive acknowledging all previously
received messages and itself containing a FT Protection received messages and itself containing a FT Protection
TLV number and the FT Cork TLV. TLV number and the FT Cork TLV.
skipping to change at page 43, line 46 skipping to change at page 44, line 46
(8) LDP Init(n/a,n/a,23) (8) LDP Init(n/a,n/a,23)
---------------------------> --------------------------->
LDP Init(n/a,n/a,12) LDP Init(n/a,n/a,12)
<--------------------------- <---------------------------
(9) Label Request(L3) (9) Label Request(L3)
---------------------------> --------------------------->
Label Request(L3) Label Request(L3)
--------------------------> -------------------------->
Label Mapping(L3) Label Mapping(L3)
<-------------------------- <--------------------------
Label Mapping(L3) (10) Label Mapping(L3)
<--------------------------- <---------------------------
(10) Label Request(L2) (11) Label Request(L2)
<--------------------------- <---------------------------
Notes: Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers. (1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of (4) A checkpoint request from P1. It carries the sequence number of
the checkpoint request. the checkpoint request.
(5) P1 immediately starts a new label distribution request. (5) P1 immediately starts a new label distribution request.
(6) P2 confirms that it has secured all previous transactions. (6) P2 confirms that it has secured all previous transactions.
skipping to change at page 45, line 19 skipping to change at page 46, line 19
(1) Label Request(L1) (1) Label Request(L1)
---------------------------> --------------------------->
(2) Label Request(L2) (2) Label Request(L2)
<--------------------------- <---------------------------
Label Request(L1) Label Request(L1)
--------------------------> -------------------------->
Label Mapping(L1) Label Mapping(L1)
<-------------------------- <--------------------------
(3) Label Mapping(L1) (3) Label Mapping(L1)
<--------------------------- <---------------------------
(4) Keepalive(n/a,12,23) * With FT Cork TLV * (4) Keepalive(n/a,12,23) * With Cork TLV
---------------------------> --------------------------->
(5) : (5) :
: :
: :
(6) Keepalive(n/a,24,12) * With FT Cork TLV * (6) Keepalive(n/a,24,12) * With Cork TLV
<--------------------------- <---------------------------
(7) Keepalive(n/a,-,24) * With FT Cork TLV * (7) Keepalive(n/a,-,24) * With Cork TLV
---------------------------> --------------------------->
(8) Notification(Temporary shutdown) (8) Notification(Temporary shutdown)
---------------------------> --------------------------->
===== TCP Session failure ===== ===== TCP Session failure =====
: :
: :
: :
===== TCP Session restored ===== ===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24) (9) LDP Init(n/a,n/a,24)
---------------------------> --------------------------->
LDP Init(n/a,n/a,12) LDP Init(n/a,n/a,12)
<--------------------------- <---------------------------
(10) Label Request(L3) (10) Label Request(L3)
---------------------------> --------------------------->
Label Request(L3) Label Request(L3)
--------------------------> -------------------------->
Label Mapping(L3) Label Mapping(L3)
<-------------------------- <--------------------------
Label Mapping(L3) (11) Label Mapping(L3)
<--------------------------- <---------------------------
(11) Label Mapping(L2) (12) Label Mapping(L2)
---------------------------> --------------------------->
Notes: Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers. (1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of (4) A checkpoint request from P1. It carries the sequence number of
the checkpoint request and a Cork TLV. the checkpoint request and a Cork TLV.
(5) P1 has sent a Cork TLV so quieces. (5) P1 has sent a Cork TLV so quieces.
(6) P2 confirms the checkpoint and continues the three-way handshake (6) P2 confirms the checkpoint and continues the three-way handshake
by including a Cork TLV itself. by including a Cork TLV itself.
skipping to change at page 46, line 32 skipping to change at page 47, line 33
of the last secured checkpoints. of the last secured checkpoints.
(10) P1 starts a new label distribution request. (10) P1 starts a new label distribution request.
(11) P1 continues processing a previously received label distribution (11) P1 continues processing a previously received label distribution
request. request.
9. Security Considerations 9. Security Considerations
The LDP FT enhancements inherit similar security The LDP FT enhancements inherit similar security
considerations to those discussed in [2] and [4]. considerations to those discussed in [RFC3212] and
[RFC3036].
The LDP FT enhancements allow the re-establishment of a The LDP FT enhancements allow the re-establishment of a
TCP connection between LDP peers without a full re- TCP connection between LDP peers without a full re-
exchange of the attributes of established labels, which exchange of the attributes of established labels, which
renders LSRs that implement the extensions specified in renders LSRs that implement the extensions specified in
this draft vulnerable to additional denial-of-service this draft vulnerable to additional denial-of-service
attacks as follows: attacks as follows:
- An intruder may impersonate an LDP peer in order to force - An intruder may impersonate an LDP peer in order to force
a failure and reconnection of the TCP connection, but where a failure and reconnection of the TCP connection, but where
skipping to change at page 47, line 7 skipping to change at page 48, line 7
- Similarly, an intruder could set the FT Reconnect Flag on - Similarly, an intruder could set the FT Reconnect Flag on
re-establishment of the TCP session without preserving the re-establishment of the TCP session without preserving the
state and resources for FT labels. state and resources for FT labels.
- An intruder could intercept the traffic between LDP peers - An intruder could intercept the traffic between LDP peers
and override the setting of the FT Label Flag to be set to 0 and override the setting of the FT Label Flag to be set to 0
for all labels. for all labels.
All of these attacks may be countered by use of an All of these attacks may be countered by use of an
authentication scheme between LDP peers, such as the MD5- authentication scheme between LDP peers, such as the MD5-
based scheme outlined in [4]. based scheme outlined in [RFC3036].
Alternative authentication schemes for LDP peers are Alternative authentication schemes for LDP peers are
outside the scope of this draft, but could be deployed to outside the scope of this draft, but could be deployed to
provide enhanced security to implementations of LDP, CR- provide enhanced security to implementations of LDP, CR-
LDP and the LDP FT enhancements. LDP and the LDP FT enhancements.
As with LDP and CR-LDP, a security issue may exist if an As with LDP and CR-LDP, a security issue may exist if an
LDP implementation continues to use labels after LDP implementation continues to use labels after
expiration of the session that first caused them to be expiration of the session that first caused them to be
used. This may arise if the upstream LSR detects the used. This may arise if the upstream LSR detects the
skipping to change at page 48, line 13 skipping to change at page 49, line 23
enhancements described in this draft. enhancements described in this draft.
Consider an LSR, P1, that is an LDP peer of a fully Fault Consider an LSR, P1, that is an LDP peer of a fully Fault
Tolerant LSR, P2. If P2 experiences a fault in the Tolerant LSR, P2. If P2 experiences a fault in the
hardware or software that serves an LDP session between hardware or software that serves an LDP session between
P1 and P2, it may fail the TCP connection between the P1 and P2, it may fail the TCP connection between the
peers. When the connection is recovered, the LSPs/labels peers. When the connection is recovered, the LSPs/labels
between P1 and P2 can only be recovered if both LSRs were between P1 and P2 can only be recovered if both LSRs were
applying the FT recovery procedures to the LDP session. applying the FT recovery procedures to the LDP session.
10.2. ACK Generation Logic 10.2. ACK generation logic
FT ACKs SHOULD be returned to the sending LSR as soon as FT ACKs SHOULD be returned to the sending LSR as soon as
is practicable in order to avoid building up a large is practicable in order to avoid building up a large
quantity of unacknowledged state changes at the LSR. quantity of unacknowledged state changes at the LSR.
However, immediate one-for-one acknowledgements would However, immediate one-for-one acknowledgements would
waste bandwidth unnecessarily. waste bandwidth unnecessarily.
A possible implementation strategy for sending ACKs to FT A possible implementation strategy for sending ACKs to FT
LDP messages is as follows: LDP messages is as follows:
skipping to change at page 49, line 17 skipping to change at page 50, line 24
targeted LDP session or CR-LDP systems) and that are targeted LDP session or CR-LDP systems) and that are
prepared to risk loss of state for the most recent LDP prepared to risk loss of state for the most recent LDP
exchanges. More dynamic systems (such as LDP discovery exchanges. More dynamic systems (such as LDP discovery
sessions) are more likely to want to acknowledge state sessions) are more likely to want to acknowledge state
changes more frequently so that the maximum amount of changes more frequently so that the maximum amount of
state can be preserved over a failure. state can be preserved over a failure.
11. Acknowledgments 11. Acknowledgments
The work in this draft is based on the LDP and CR-LDP The work in this draft is based on the LDP and CR-LDP
ideas expressed by the authors of [2] and [4]. ideas expressed by the authors of [RFC3212] and [].
The ACK scheme used in this draft was inspired by the The ACK scheme used in this draft was inspired by the
proposal by David Ward and John Scudder for restarting proposal by David Ward and John Scudder for restarting
BGP sessions now included in [9]. BGP sessions now included in [BGP-RESTART].
The authors would also like to acknowledge the careful The authors would also like to acknowledge the careful
review and comments of Nick Weeds, Piers Finlayson, Tim review and comments of Nick Weeds, Piers Finlayson, Tim
Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas, Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas,
S.Manikantan, Adam Sheppard and Alan Davey. S.Manikantan, Adam Sheppard, Alan Davey and Iftekhar
Hussain.
12. Intellectual Property Consideration 12. Intellectual Property Consideration
The IETF has been notified of intellectual property The IETF has been notified of intellectual property
rights claimed in regard to some or all of the rights claimed in regard to some or all of the
specification contained in this document. For more specification contained in this document. For more
information, consult the online list of claimed rights. information, consult the online list of claimed rights.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (c) The Internet Society (2000, 2001). All Copyright (c) The Internet Society (2000, 2001, 2002). All
Rights Reserved. This document and translations of it may Rights Reserved. This document and translations of it may
be copied and furnished to others, and derivative works be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and any kind, provided that the above copyright notice and
this paragraph are included on all such copies and this paragraph are included on all such copies and
derivative works. However, this document itself may not derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other notice or references to the Internet Society or other
skipping to change at page 50, line 27 skipping to change at page 52, line 5
protocol. This section explains the logic used by the protocol. This section explains the logic used by the
authors to choose the most appropriate number space for authors to choose the most appropriate number space for
each new entity, and is intended to assist in the each new entity, and is intended to assist in the
determination of any final values assigned by IANA or the determination of any final values assigned by IANA or the
MPLS WG in the event that the MPLS WG chooses to advance MPLS WG in the event that the MPLS WG chooses to advance
this draft on the standards track. this draft on the standards track.
This section will be removed when the TLV and status code This section will be removed when the TLV and status code
values have been agreed with IANA. values have been agreed with IANA.
14.1. FT Session TLV 14.1. New TLVs
The FT Session TLV carries attributes that affect the
entire LDP session between LDP peers. It is suggested
that the type for this TLV should be chosen from the
0x05xx range for TLVs that is used in [4] by other TLVs
carrying session-wide attributes. At the time of this
writing, the next available number in this range is
0x0503.
14.2. FT Protection TLV The FT Protection TLV carries attributes that affect a single label
exchanged between LDP peers. It is taken from the 0x02xx range for
TLVs that is used in [RFC3036] by other TLVs carrying label
attributes. The next available value in this range is 0x0203.
The FT Protection TLV carries attributes that affect a The FT Session TLV carries attributes that affect the entire LDP
single label exchanged between LDP peers. It is session between LDP peers. It is taken from the 0x05xx range for
suggested that the type for this TLV should be chosen TLVs that is used in [RFC3036] by other TLVs carrying session-wide
from the 0x02xx range for TLVs that is used in [4] by attributes. The next available value in this range is 0x0503.
other TLVs carrying label attributes. At the time of
this writing, the next available number in this range is
0x0203.
Consideration was given to using the message number field The FT Protection TLV may ACK many label operations at once if
instead of a new FT Sequence Number field. However, the cumulative ACKS are used. It is taken from the 0x05xx range for
authors felt this placed unacceptable implementation TLVs that is used in [RFC3036] by other TLVs carrying session-wide
constraints on the use of message number (e.g. it could attributes. The next available value in this range is 0x0504.
no longer be used to reference a control block).
14.3. FT ACK TLV The FT Cork TLV carries attributes that apply to all labels exchanged
between LDP peers. It is taken from the 0x05xx range for TLVs that
is used in [RFC3036] by other TLVs carrying label attributes. The
next available value in this range is 0x0505.
The FT Protection TLV may ACK many label operations at In summary:
once if cumulative ACKS are used. It is suggested that
the type for this TLV should be chosen from the 0x05xx
range for TLVs that is used in [4] by other TLVs carrying
session-wide attributes. At the time of this writing,
the next available number in this range is 0x0504.
Consideration was given to carrying the FT ACK Number in FT Protection TLV 0x0203
the FT Protection TLV, but the authors felt this would be FT Session TLV 0x0503
inappropriate as many implementations may wish to carry FT Ack TLV 0x0504
the ACKs on Keepalive messages. FT Cork TLV 0x0505
14.4. FT Cork TLV 14.2. New Status Codes
The FT Cork TLV carries attributes that affect a single LDP status codes are not sub-divided into specific ranges
label exchanged between LDP peers. It is suggested that for different types of error. Hence, the numeric status
the type for this TLV should be chosen from the 0x05xx code values are selected as the next available.
range for TLVs that is used in [4] by other TLVs carrying
label attributes. At the time of this writing, the next
available number in this range is 0x0505.
14.5. Status Codes Section 7.1 lists the new status codes required by this
draft and gives interpretative information. The new
codes are as follows.
The authors' current understanding is that MPLS status Status Code E Status Data
codes are not sub-divided into specific ranges for
different types of error. 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
substituted for other numeric values.
See section "Status Codes" for details of the status No LDP Session 0 0x0000001A
codes defined in this draft. Zero FT seqnum 1 0x0000001B
Unexpected TLV / 1 0x0000001C
Session Not FT
Unexpected TLV / 1 0x0000001D
Label Not FT
Missing FT Protection TLV 1 0x0000001E
FT ACK sequence error 1 0x0000001F
Temporary Shutdown 0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021
FT Session parameters / 1 0x00000022
changed
Unexpected FT Cork TLV 1 0x00000023
15. Authors' Addresses 15. Authors' Addresses
Adrian Farrel (editor) Paul Brittain Adrian Farrel (editor) Paul Brittain
Movaz Networks, Inc. Data Connection Ltd. Movaz Networks, Inc. Data Connection Ltd.
7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street, 7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,
McLean, VA 22102 Chester, Cheshire McLean, VA 22102 Chester, Cheshire
Phone: +1 703-847-1867 CH1 1DF, UK Phone: +1 703-847-1867 CH1 1DF, UK
Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177 Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177
Email: pjb@dataconnection.com Email: pjb@dataconnection.com
Philip Matthews Eric Gray Philip Matthews Eric Gray
Hyperchip Sandburst Corporation Hyperchip Celox Networks, Inc.
1800 Rene-Levesque Blvd W 600 Federal Street 1800 Rene-Levesque Blvd W 2 Park Central Drive,
Montreal, Quebec H3H 2H2 Andover, MA 01810 Montreal, Quebec H3H 2H2 Southborough, MA 01772
Canada Phone: +1 978-689-1600 Canada Phone: +1 508-305-7214
Phone: +1 514-906-4965 Email:eric.gray@sandburst.com Phone: +1 514-906-4965 Email: egray@celoxnetworks.com
Email: pmatthews@hyperchip.com Email: pmatthews@hyperchip.com
Jack Shaio Toby Smith Jack Shaio Toby Smith
Vivace Networks Laurel Networks, Inc. Vivace Networks Laurel Networks, Inc.
2730 Orchard Parkway 1300 Omega Drive 2730 Orchard Parkway 1300 Omega Drive
San Jose, CA 95134 Pittsburgh, PA 15205 San Jose, CA 95134 Pittsburgh, PA 15205
Phone: +1 408 432 7623 Email: tob@laurelnetworks.com Phone: +1 408 432 7623 Email: tob@laurelnetworks.com
Email: jack.shaio@vivacenetworks.com Email: jack.shaio@vivacenetworks.com
Andy Malis Andrew G. Malis
Vivace Networks Vivace Networks
2730 Orchard Parkway 2730 Orchard Parkway
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 383 7223 Phone: +1 408 383 7223
andy.malis@vivacenetworks.com andy.malis@vivacenetworks.com
16. Normative References 16. References
4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
17. Informative References 16.1. Normative References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP [RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036,
9, RFC 2026, October 1996. January 2001.
2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, [RFC3212] Jamoussi, B., et. al., Constraint-Based LSP Setup
draft-ietf-mpls-cr-ldp-06.txt, November 2001, (work in progress). using LDP, RFC 3212, January 2002.
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 16.2. Informative References
Levels", BCP 14, RFC 2119, March 1997.
5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls- [RFC2026] Bradner, S., "The Internet Standards Process --
crlsp-modify-03.txt, March 2001 (work in progress). Revision 3", BCP 9, RFC 2026, October 1996.
6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Version 1, Functional Specification, RFC 2205, September 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7 Berger, L., et al., RSVP Refresh Reduction Extensions, RFC 2961 [RFC2205] Braden, R., et al., Resource ReSerVation Protocol
April 2001. (RSVP) -- Version 1, Functional Specification, RFC
2205, September 1997.
8 Awduche, D., et al,. Extensions to RSVP for LSP Tunnels, RFC 3209, [RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions,
December 2001. RFC 2961, April 2001.
9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP, [RFC3209] Awduche, D., et al,. Extensions to RSVP for LSP
draft-ietf-idr-restart-00.txt, December 2000 (work in progress). Tunnels, RFC 3209, December 2001.
10 Stewart, R., et al., Stream Control Transmission Protocol, [RFC3214] Ash, G., et al., LSP Modification Using CR-LDP, RFC
RFC 2906, October 2000. 3214, January 2001.
11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart- [BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism
00.txt, February 2001 (work in progress). for BGP, draft-ietf-idr-restart-05.txt, June 2002
(work in progress).
12 Leelanivas, M., et al., Graceful Restart Mechanism for LDP, draft- [LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for
ietf-ldp-restart-00.txt, January 2002, work in progress. LDP, draft-ietf-ldp-restart-02.txt, June 2002, work in
progress.
 End of changes. 

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