draft-ietf-mpls-ldp-ft-02.txt   draft-ietf-mpls-ldp-ft-03.txt 
MPLS WG Adrian Farrel MPLS Working Group Adrian Farrel
Internet Draft Movaz Networks, Inc. Internet Draft Movaz Networks, Inc.
Document: draft-ietf-mpls-ldp-ft-02.txt Document: draft-ietf-mpls-ldp-ft-03.txt
Expiration Date: October 2001 Paul Brittain Expiration Date: December 2002 Paul Brittain
MetaSwitch Ltd Data Connection Ltd.
Philip Matthews Philip Matthews
Nortel Hyperchip
Eric Gray Eric Gray
Sandburst Sandburst
May 2001 Toby Smith
Laurel Networks
Andy Malis
Jack Shaio
Vivace Networks
June 2002
Fault Tolerance for LDP and CR-LDP Fault Tolerance for LDP and CR-LDP
draft-ietf-mpls-ldp-ft-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full
all provisions of Section 10 of RFC2026 [1]. conformance with all provisions of Section 10 of RFC2026
[1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute
Drafts. Internet-Drafts are draft documents valid for a maximum of working documents as Internet-Drafts. Internet-Drafts are
six months and may be updated, replaced, or obsoleted by other draft documents valid for a maximum of six months and may
documents at any time. It is inappropriate to use Internet- Drafts be updated, replaced, or obsoleted by other documents at
as reference material or to cite them other than as "work in any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be
http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
NOTE: The new TLV type numbers, bit values for flags specified in NOTE: The new TLV type numbers, bit values for flags
this draft, and new LDP status code values are preliminary suggested specified in this draft, and new LDP status code values
values and have yet to be approved by IANA or the MPLS WG. See the are preliminary suggested values and have yet to be
section "IANA Considerations" for further details. approved by IANA or the MPLS WG. See the section "IANA
Considerations" for further details.
Abstract Abstract
MPLS systems will be used in core networks where system downtime MPLS systems will be used in core networks where system
must be kept to an absolute minimum. Many MPLS LSRs may, therefore, downtime must be kept to an absolute minimum. Many MPLS
exploit Fault Tolerant (FT) hardware or software to provide LSRs may, therefore, exploit Fault Tolerant (FT) hardware
high availability of the core networks. or software to provide high availability of the core
networks.
The details of how FT is achieved for the various components of an FT The details of how FT is achieved for the various
LSR, including LDP, CR-LDP, the switching hardware and TCP, are components of an FT LSR, including LDP, CR-LDP, the
implementation specific. This document identifies issues in the switching hardware and TCP, are implementation specific.
CR-LDP specification [2] and the LDP specification [4] that make it This document identifies issues in the CR-LDP
difficult to implement an FT LSR using the current LDP and CR-LDP specification [2] and the LDP specification [4] that make
protocols, and proposes enhancements to the LDP specification to ease it difficult to implement an FT LSR using the current LDP
such FT LSR implementations. and CR-LDP protocols, and proposes enhancements to the
LDP specification to ease such FT LSR implementations.
The extensions described here are equally applicable to CR-LDP. The extensions described here are equally applicable to
CR-LDP.
Contents Contents
0. Changes from Previous Version...................................3 1. Conventions and Terminology used in this document 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.......................................4 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.................................6 3.1. Establishing an FT LDP Session 8
3.1 Establishing an FT LDP Session.................................7 3.1.1 Interoperation with Non-FT LSRs 9
3.1.1 Interoperation with Non-FT LSRs.............................7 3.2. TCP Connection Failure 9
3.2 TCP Connection Failure.........................................7 3.2.1 Detecting TCP Connection Failures 9
3.2.1 Detecting TCP Connection Failures............................7 3.2.2 LDP Processing after Connection Failure 10
3.2.2 LDP Processing after Connection Failure......................8 3.3. Data Forwarding During TCP Connection Failure 10
3.3 Data Forwarding During TCP Connection Failure..................8 3.4. FT LDP Session Reconnection 11
3.4 FT LDP Session Reconnection....................................8 3.5. Operations on FT Labels 12
3.5 Operations on FT Labels........................................9 3.6. Check-Pointing 12
3.6 Label Space Depletion and Replenishment........................9 3.6.1 Graceful Termination 13
4. FT Operations..................................................10 3.7. Label Space Depletion and Replenishment 13
4.1 FT LDP Messages...............................................10 4. FT Operations 14
4.1.1 FT Label Messages...........................................10 4.1. FT LDP Messages 14
4.1.1.1 Scope of FT Labels........................................10 4.1.1 FT Label Messages 14
4.1.2 FT Address Messages........................................11 4.1.2 FT Address Messages 15
4.1.3 FT Label Resources Available Notification Messages..........11 4.1.3 FT Label Resources Available Notification Messages 16
4.2 FT Operation ACKs.............................................12 4.2. FT Operation ACKs 17
4.3 Preservation of FT State......................................12 4.3. Preservation of FT State 18
4.4 FT Procedure After TCP Failure................................14 4.4. FT Procedure After TCP Failure 19
4.4.1 FT LDP Operations During TCP Failure........................15 4.4.1 FT LDP Operations During TCP Failure 20
4.5 FT Procedure After TCP Re-connection..........................16 4.5. FT Procedure After TCP Re-connection 21
4.5.1 Re-Issuing FT Messages......................................16 4.5.1 Re-Issuing FT Messages 22
4.5.2 Interaction with CR-LDP LSP Modification....................17 4.5.2 Interaction with CR-LDP LSP Modification 23
5. Changes to Existing Messages...................................17 5. Checkpointing Procedures 23
5.1 LDP Initialization Message....................................17 5.1. Checkpointing with the Keepalive Message 24
5.2 LDP Keepalive Message.........................................18 5.2. Quiesce and Keepalive 24
5.3 All Other LDP Session Messages................................18 6. Changes to Existing Messages 25
6. New Fields and Values..........................................18 6.1. LDP Initialization Message 25
6.1 Status Codes..................................................18 6.2. LDP Keepalive Messages 25
6.2 FT Session TLV................................................19 6.3. All Other LDP Session Messages 26
6.3 FT Protection TLV.............................................20 7. New Fields and Values 26
6.4 FT ACK TLV....................................................22 7.1. Status Codes 26
7. Example Use....................................................23 7.2. FT Session TLV 27
7.1 Session Failure and Recovery..................................24 7.3. FT Protection TLV 29
7.2 Temporary Shutdown............................................26 7.4. FT ACK TLV 32
8. Security Considerations........................................27 7.5. FT Cork TLV 33
9. Implementation Notes...........................................28 8. Example Use 34
9.1 FT Recovery Support on Non-FT LSRs............................28 8.1. Session Failure and Recovery - FT Procedures 35
9.2 ACK generation logic..........................................28 8.2. Use of Check-Pointing With FT Procedures 37
10. Acknowledgements..............................................29 8.3. Temporary Shutdown With FT Procedures 39
11. Intellectual Property Consideration...........................29 8.4. Temporary Shutdown With FT Procedures and Check-Pointing 41
12. Full Copyright Statement......................................29 8.5. Checkpointing Without FT Procedures 43
13. IANA Considerations...........................................30 8.6. Graceful Shutdown With Checkpointing But No FT Procedures 45
13.1 FT Session TLV...............................................30 9. Security Considerations 46
13.2 FT Protection TLV............................................30 10. Implementation Notes 47
13.3 FT ACK TLV...................................................31 10.1. FT Recovery Support on Non-FT LSRs 47
13.4 Status Codes.................................................31 10.2. ACK Generation Logic 48
14. Authors' Addresses............................................31 10.2.1 Ack Generation Logic When Using Check-Pointing 48
15. References....................................................31 11. Acknowledgments 49
0. Changes From Version 1 to Version 2 12. Intellectual Property Consideration 49
13. Full Copyright Statement 49
14. IANA Considerations 50
14.1. FT Session TLV 50
14.2. FT Protection TLV 50
14.3. FT ACK TLV 51
14.4. FT Cork TLV 51
14.5. Status Codes 51
15. Authors' Addresses 51
16. Normative References 52
17. Informative References 52
0. Changes From Version 2 to Version 3
This section to be removed before final publication. This section to be removed before final publication.
2.2 Add paragraph discussing use of this draft for recovery in non- 2.2 Add notes about graceful shutdown and check-pointing.
FT systems.
3.2.2 Clarify selection of FT Reconnect Timeout value. 3 Allow sequence number on Keepalive to facilitate check-
pointing.
3.4 Explain procedure when FT Reconnect flag is 'unexpectedly' set. 3.6 New section to describe the use of check-pointing
4.1.1.1 Explain re-use of labels from the per platform label space. 3.6.1 New sub-section to describe the use of check-
pointing for graceful restart
4.3 Clarify that the Reconnection Timeout provides an upper limit on 3.7 and 4.1.3 Make acknowledgement and request for
the preservation of state, but that other events may cause state acknowledgement of Notification messages carrying 'Label
to be released sooner. Resources Available' optional.
4.4.1 Describe behavior if an LDP peer is unwilling or unable to 4.1.1 Explicitly state it is allowable to make all labels
queue operations during TCP failure. FT labels.
4.5 Describe behavior if an LDP peer is unwilling or unable to 5. Add section to describe Checkpointing procedures.
queue operations during TCP failure.
8. Text to expose security risks concerned with reuse of labels. 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 CR-LDP are Definitions of key words and terms applicable to LDP and
inherited from [2] and [4]. CR-LDP are inherited from [2] and [4].
The term "FT label" is introduced in this document to The term "FT label" is introduced in this document to
indicated a label for which fault tolerant operation is used. A indicated a label for which fault tolerant operation is
"non-FT label" is not fault tolerant and is handled as specified in used. A "non-FT label" is not fault tolerant and is
[2] and [4]. handled as specified in [2] and [4].
The extensions to LDP specified in this document are collectively The extensions to LDP specified in this document are
referred to as the "LDP FT enhancements". collectively referred to as the "LDP FT enhancements".
Within the context of this draft, "Checkpointing" refers
to a process of messages exchanges that confirm receipt
and processing (or secure storage) of specific protocol
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", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
this document are to be interpreted as described in RFC-2119 [3]. "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [3].
2. Introduction 2. Introduction
High Availability (HA) is typically claimed by equipment vendors High Availability (HA) is typically claimed by equipment
when their hardware achieves availability levels of at least 99.999% vendors when their hardware achieves availability levels
(five 9s). To implement this, the equipment must be capable of of at least 99.999% (five 9s). To implement this, the
recovering from local hardware and software failures through a equipment must be capable of recovering from local
process known as fault tolerance (FT). hardware and software failures through a process known as
fault tolerance (FT).
The usual approach to FT involves provisioning backup copies of The usual approach to FT involves provisioning backup
hardware and/or software. When a primary copy fails, processing is copies of hardware and/or software. When a primary copy
switched to the backup copy. This process, called failover, should fails, processing is switched to the backup copy. This
result in minimal disruption to the Data Plane. process, called failover, should result in minimal
disruption to the Data Plane.
In an FT system, backup resources are sometimes provisioned on a In an FT system, backup resources are sometimes
one-to-one basis (1:1), sometimes as many-to-one (1:n), and provisioned on a one-to-one basis (1:1), sometimes as
occasionally as many-to-many (m:n). Whatever backup provisioning is many-to-one (1:n), and occasionally as many-to-many
made, the system must switch to the backup automatically on failure (m:n). Whatever backup provisioning is made, the system
of the primary, and the software and hardware state in the backup must switch to the backup automatically on failure of the
must be set to replicate the state in the primary at the point primary, and the software and hardware state in the
of failure. backup must be set to replicate the state in the primary
at the point of failure.
2.1 Fault Tolerance for MPLS 2.1. Fault Tolerance for MPLS
MPLS will be used in core networks where system downtime must be kept MPLS will be used in core networks where system downtime
to an absolute minimum. Many MPLS LSRs may, therefore, exploit FT must be kept to an absolute minimum. Many MPLS LSRs may,
hardware or software to provide high availability of core networks. therefore, exploit FT hardware or software to provide
high availability of core networks.
In order to provide HA, an MPLS system needs to be able
to survive a variety of faults with minimal disruption to
the Data Plane, including the following fault types:
In order to provide HA, an MPLS system needs to be able to survive
a variety of faults with minimal disruption to the Data Plane,
including the following fault types:
- failure/hot-swap of a physical connection between LSRs - failure/hot-swap of a physical connection between LSRs
- failure/hot-swap of the switching fabric in the LSR - failure/hot-swap of the switching fabric in the LSR
- failure of the TCP or LDP stack in an LSR - failure of the TCP or LDP stack in an LSR
- software upgrade to the TCP or LDP stacks. - software upgrade to the TCP or LDP stacks.
The first two examples of faults listed above are confined to the The first two examples of faults listed above are
Data Plane. Such faults can be handled by providing redundancy in confined to the Data Plane. Such faults can be handled
the Data Plane which is transparent to LDP operating in the Control by providing redundancy in the Data Plane which is
Plane. The last two example types of fault require action in transparent to LDP operating in the Control Plane. The
the Control Plane to recover from the fault without disrupting last two example types of fault require action in the
traffic in the Data Plane. This is possible because many recent Control Plane to recover from the fault without
router architectures separate the Control and Data Planes such that disrupting traffic in the Data Plane. This is possible
forwarding can continue unaffected by recovery action in the Control because many recent router architectures separate the
Plane. Control and Data Planes such that forwarding can continue
unaffected by recovery action in the Control Plane.
2.2 Issues with LDP and CR-LDP 2.2. Issues with LDP and CR-LDP
LDP and CR-LDP use TCP to provide reliable connections between LSRs LDP and CR-LDP use TCP to provide reliable connections
over which to exchange protocol messages to distribute labels and to between LSRs over which to exchange protocol messages to
set up LSPs. A pair of LSRs that have such a connection are referred distribute labels and to set up LSPs. A pair of LSRs that
to as LDP peers. have such a connection are referred to as LDP peers.
TCP enables LDP and CR-LDP to assume reliable transfer of protocol TCP enables LDP and CR-LDP to assume reliable transfer of
messages. This means that some of the messages do not need to be protocol messages. This means that some of the messages
acknowledged (for example, Label Release). do not need to be acknowledged (for example, Label
Release).
LDP and CR-LDP are defined such that if the TCP connection fails, the LDP and CR-LDP are defined such that if the TCP
LSR should immediately tear down the LSPs associated with the session connection fails, the LSR should immediately tear down
between the LDP peers, and release any labels and resources assigned the LSPs associated with the session between the LDP
to those LSPs. peers, and release any labels and resources assigned to
those LSPs.
It is notoriously hard to provide a Fault Tolerant implementation of It is notoriously hard to provide a Fault Tolerant
TCP. To do so might involve making copies of all data sent and implementation of TCP. To do so might involve making
received. This is an issue familiar to implementers of other TCP copies of all data sent and received. This is an issue
applications such as BGP. familiar to implementers of other TCP applications such
as BGP.
During failover affecting the TCP or LDP stacks, therefore, the TCP During failover affecting the TCP or LDP stacks,
connection may be lost. Recovery from this position is made worse by therefore, the TCP connection may be lost. Recovery from
the fact that LDP or CR-LDP control messages may have been lost this position is made worse by the fact that LDP or CR-
during the connection failure. Since these messages are unconfirmed, LDP control messages may have been lost during the
it is possible that LSP or label state information will be lost. connection failure. Since these messages are
unconfirmed, it is possible that LSP or label state
information will be lost.
This draft describes a solution which involves This draft describes a solution which involves
- negotiation between LDP peers of the intent to support extensions
to LDP that facilitate recovery from failover without loss of LSPs - negotiation between LDP peers of the intent to support
extensions to LDP that facilitate recovery from failover
without loss of LSPs
- selection of FT survival on a per LSP/label basis - selection of FT survival on a per LSP/label basis
- acknowledgement of LDP messages to ensure that a full handshake is
performed on those messages - acknowledgement of LDP messages to ensure that a full
- re-issuing lost messages after failover to ensure that LSP/label handshake is performed on those messages either frequently
state is correctly recovered after reconnection of the LDP session. (such as per message) or less frequently as in check-
pointing
- solicitation of up-to-date acknowledgement
(checkpointing) of previous LDP messages to ensure the
current state is flushed to disk/NVRAM, with an additional
option that allows an LDP partner to request that state is
flushed in both directions if graceful shutdown is required.
- re-issuing lost messages after failover to ensure that
LSP/label state is correctly recovered after reconnection of
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 these
proposals - offer back-compatibility with LSRs that do not implement
- preserve existing protocol rules described in [2] and [4] for these proposals
handling unexpected duplicate messages and for processing
unexpected messages referring to unknown LSPs/labels - preserve existing protocol rules described in [2] and [4]
for handling unexpected duplicate messages and for
processing unexpected messages referring to unknown
LSPs/labels
- integrate with the LSP modification function described in [5] - integrate with the LSP modification function described in [5]
- avoid full state refresh solutions (such as those present in RSVP:
see [6], [7] and [8]) whether they be full-time, or limited to
post-failover recovery.
Note that this draft concentrates on the preservation of label state - avoid full state refresh solutions (such as those present
for labels exchanged between a pair of adjacent LSRs when the TCP in RSVP: see [6], [7], [8] and [12]) whether they be full-
connection between those LSRs is lost. This is a requirement for time, or limited to post-failover recovery.
Fault Tolerant operation of LSPs, but a full implementation of end-
to-end protection for LSPs requires that this is combined with other
techniques that are outside the scope of this draft.
In particular, this draft does not attempt to describe how to modify Note that this draft concentrates on the preservation of
the routing of an LSP or the resources allocated to a label or LSP, label state for labels exchanged between a pair of
which is covered by [5]. This draft also does not address how to adjacent LSRs when the TCP connection between those LSRs
provide automatic layer 2/3 protection switching for a label or LSP, is lost. This is a requirement for Fault Tolerant
which is a separate area for study. operation of LSPs, but a full implementation of end-to-
end protection for LSPs requires that this is combined
with other techniques that are outside the scope of this
draft.
This specification does not preclude an implementation from In particular, this draft does not attempt to describe
attempting (or require it to attempt) to use the FT behavior how to modify the routing of an LSP or the resources
described here to recover from a preemptive failure of a connection allocated to a label or LSP, which is covered by [5].
on a non-FT system due to, for example, a partial system crash. This draft also does not address how to provide automatic
Note, however, that there are potential issues too numerous to list layer 2/3 protection switching for a label or LSP, which
here - not least the likelihood that the same crash will immediately is a separate area for study.
occur when processing the restored data.
This specification does not preclude an implementation
from attempting (or require it to attempt) to use the FT
behavior described here to recover from a preemptive
failure of a connection on a non-FT system due to, for
example, a partial system crash. Note, however, that
there are potential issues too numerous to list here -
not least the likelihood that the same crash will
immediately occur when processing the restored data.
3. Overview of LDP FT Enhancements 3. Overview of LDP FT Enhancements
The LDP FT enhancements consist of the following main elements, which The LDP FT enhancements consist of the following main
are described in more detail in the sections that follow. elements, which are described in more detail in the
sections that follow.
- The presence of an FT Session TLV on the LDP Initialization - The presence of an FT Session TLV on the LDP
message indicates that an LSR supports the LDP FT enhancements on Initialization message indicates that an LSR supports some
this session. form of protection or recovery from session failure. A flag
bit within this TLV (the S bit) indicates that the LSR
supports the LDP FT enhancements on this session. Another
flag (the C bit) indicates that the checkpointing procedures
are to be used.
- An FT Reconnect Flag in the FT Session TLV indicates whether an - An FT Reconnect Flag in the FT Session TLV indicates
LSR has preserved FT label state across a failure of the TCP whether an LSR has preserved FT label state across a failure
of the TCP connection.
- An FT Reconnection Timeout, exchanged on the LDP
Initialization message, that indicates the maximum time peer
LSRs will preserve FT label state after a failure of the TCP
connection. connection.
- An FT Reconnection Timeout, exchanged on the LDP Initialization - An FT Protection TLV used to identify operations that
message, that indicates the maximum time peer LSRs will preserve affect LDP labels. All LDP messages carrying the FT
FT label state after a failure of the TCP connection. Protection TLV need to be secured (e.g. to NVRAM) and ACKed
to the sending LDP peer in order that the state for FT
labels can be correctly recovered after LDP session
reconnection.
- An FT Protection TLV used to identify operations that affect LDP Note that the implementation within an FT system is left
labels. All LDP messages carrying the FT Protection TLV need to open by this draft. An implementation could choose to
be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in secure entire messages relating to FT labels, or it could
order that the state for FT labels can be correctly recovered secure only the relevant state information.
after LDP session reconnection.
Note that the implementation within an FT system is left open by - Address advertisement may also be secured by use of the
this draft. An implementation could choose to secure entire FT Protection TLV. This enables recovery after LDP session
messages relating to FT labels, or it could secure only the reconnection without the need to re-advertise what may be a
relevant state information. very large number of addresses.
- Address advertisement is also secured by use of the FT Protection - The FT Protection TLV may also be used on the Keepalive
TLV. This enables recovery after LDP session reconnection without message to flush acknowledgement of all previous FT
the need to re-advertise what may be a very large number of operations. This enables a check-point for future recovery,
addresses. either in mid-session or prior to graceful shutdown of an
LDP session. This procedure may also be used to checkpoint
all (that is both FT and non-FT) operations for future
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] described in In order that the extensions to LDP [4] and CR-LDP [2]
this draft can be used successfully on an LDP session between a pair described in this draft can be used successfully on an
of LDP peers, they MUST negotiate that the LDP FT enhancements LDP session between a pair of LDP peers, they MUST
are to be used on the LDP session. negotiate that the LDP FT enhancements are to be used on
the LDP session.
This is done on the LDP Initialization message exchange using a new This is done on the LDP Initialization message exchange
FT Session TLV. Presence of this TLV indicates that the peer wants using a new FT Session TLV. Presence of this TLV
to support the LDP FT enhancements on this LDP session. indicates that the peer wants to support some form of
protection or recovery processing. The S bit within this
TLV indicates that the peer wants to support the LDP FT
enhancements on this LDP session. The C bit indicates
that the peer wants to support the checkpointing
functions described in this draft. The S and C bits may
be set independently.
The LDP FT enhancements MUST be supported on an LDP session if both The relevant LDP FT enhancements MUST be supported on an
LDP peers include an FT Session TLV on the LDP Initialization LDP session if both LDP peers include an FT Session TLV
message. on the LDP Initialization message and have the same
setting of the S or C bit.
If either LDP Peer does not include the FT Session TLV on the LDP If either LDP Peer does not include the FT Session TLV
Initialization message, the LDP FT enhancements MUST NOT be used LDP Initialization message or if there is no match of S
during this LDP session. Use of LDP FT enhancements by a sending and C bits between the peers, the LDP FT enhancements
LDP peer MUST be interpreted by the receiving LDP peer as a serious MUST NOT be used during this LDP session. Use of LDP FT
protocol error causing the session to be terminated. enhancements by a sending LDP peer MUST be interpreted by
the receiving LDP peer as a serious protocol error
causing the session to be terminated.
An LSR MAY present different FT/non-FT behavior on different TCP An LSR MAY present different FT/non-FT behavior on
connections, even if those connections are successive instantiations different TCP connections, even if those connections are
of the LDP session between the same LDP peers. successive instantiations of the LDP session between the
same LDP peers.
3.1.1 Interoperation with Non-FT LSRs 3.1.1 Interoperation with Non-FT LSRs
The FT Session TLV on the LDP Initialization message carries the The FT Session TLV on the LDP Initialization message
U-bit. If an LSR does not support the LDP FT enhancements, it will carries the U-bit. If an LSR does not support any
ignore this TLV. Since such partners also do not include the FT protection or recovery mechanisms , it will ignore this
Session TLV, all LDP sessions to such LSRs will not use the LDP FT TLV. Since such partners also do not include the FT
enhancements. Session TLV, all LDP sessions to such LSRs will not use
the LDP FT enhancements.
The rest of this draft assumes that the LDP sessions under discussion The rest of this draft assumes that the LDP sessions
are between LSRs that do support the LDP FT enhancements, except under discussion are between LSRs that do support the LDP
where explicitly stated otherwise. FT enhancements, except where explicitly stated
otherwise.
3.2 TCP Connection Failure 3.2. TCP Connection Failure
3.2.1 Detecting TCP Connection Failures 3.2.1 Detecting TCP Connection Failures
TCP connection failures may be detected and reported to the LDP TCP connection failures may be detected and reported to the
component in a variety of ways. These should all be treated in the LDP component in a variety of ways. These should all be
same way by the LDP component. treated in the same way by the LDP component.
- Indication from the management component that a TCP
connection or underlying resource is no longer active.
- Notification from a hardware management component of an
interface failure.
- Indication from the management component that a TCP connection or
underlying resource is no longer active.
- Notification from a hardware management component of an interface
failure.
- Sockets keepalive timeout. - Sockets keepalive timeout.
- 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 session, the If the LDP FT enhancements are not in use on an LDP
action of the LDP peers on failure of the TCP connection is as session, the action of the LDP peers on failure of the
specified in [2] and [4]. TCP connection is as specified in [2] and [4].
All state information and resources associated with non-FT labels All state information and resources associated with non-
MUST be released on the failure of the TCP connection, including FT labels MUST be released on the failure of the TCP
deprogramming the non-FT label from the switching hardware. This is connection, including deprogramming the non-FT label from
equivalent to the behavior specified in [4]. the switching hardware. This is equivalent to the
behavior specified in [4].
If the LDP FT enhancements are in use on an LDP session, both LDP If the LDP FT enhancements are in use on an LDP session,
peers SHOULD preserve state information and resources associated with both LDP peers SHOULD preserve state information and
FT labels exchanged on the LDP session. Both LDP peers SHOULD use a resources associated with FT labels exchanged on the LDP
timer to release the preserved state information and resources session. Both LDP peers SHOULD use a timer to release
associated with FT-labels if the TCP connection is not restored the preserved state information and resources associated
within a reasonable period. The behavior when this timer expires is with FT-labels if the TCP connection is not restored
equivalent to the LDP session failure behavior described in [4]. within a reasonable period. The behavior when this timer
expires is equivalent to the LDP session failure behavior
described in [4].
The FT Reconnection Timeout each LDP peer intends to apply to the LDP The FT Reconnection Timeout each LDP peer intends to
session is carried in the FT Session TLV on the LDP Initialization apply to the LDP session is carried in the FT Session TLV
messages. Both LDP peers MUST use the value that corresponds to the on the LDP Initialization messages. Both LDP peers MUST
lesser timeout interval of the two proposed timeout values from the use the value that corresponds to the lesser timeout
LDP Initialization exchange, where a value of zero is treated as interval of the two proposed timeout values from the LDP
positive infinity. Initialization exchange, where a value of zero is treated
as positive infinity.
3.3 Data Forwarding During TCP Connection Failure 3.3. Data Forwarding During TCP Connection Failure
An LSR that implements the LDP FT enhancements SHOULD preserve the An LSR that implements the LDP FT enhancements SHOULD
programming of the switching hardware across a failover. This preserve the programming of the switching hardware across
ensures that data forwarding is unaffected by the state of the TCP a failover. This ensures that data forwarding is
connection between LSRs. unaffected by the state of the TCP connection between
LSRs.
It is an integral part of FT failover processing in some hardware It is an integral part of FT failover processing in some
configurations that some data packets might be lost. If data loss is hardware configurations that some data packets might be
not acceptable to the applications using the MPLS network, the LDP FT lost. If data loss is not acceptable to the applications
enhancements described in this draft SHOULD NOT be used. using the MPLS network, the LDP FT enhancements described
in this draft SHOULD NOT be used.
3.4 FT LDP Session Reconnection 3.4. FT LDP Session Reconnection
When a new TCP connection is established, the LDP peers MUST exchange When a new TCP connection is established, the LDP peers
LDP Initialization messages. When a new TCP connection is MUST exchange LDP Initialization messages. When a new
established after failure, the LDP peers MUST re-exchange LDP TCP connection is established after failure, the LDP
Initialization messages. peers MUST re-exchange LDP Initialization messages.
If an LDP peer includes the FT Session TLV in the LDP Initialization If an LDP peer includes the FT Session TLV with the S bit
message for the new instantiation of the LDP session, it MUST also set in the LDP Initialization message for the new
set the FT Reconnect Flag according to whether it has been able to instantiation of the LDP session, it MUST also set the FT
preserve label state. The FT Reconnect Flag is carried in the FT Reconnect Flag according to whether it has been able to
Session TLV. preserve label state. The FT Reconnect Flag is carried
in the FT Session TLV.
If an LDP peer has preserved all state information for previous If an LDP peer has preserved all state information for
instantiations of the LDP session, then it SHOULD set the FT previous instantiations of the LDP session, then it
Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the SHOULD set the FT Reconnect Flag to 1 in the FT Session
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 omits the FT If either LDP peer sets the FT Reconnect Flag to 0, or
Session TLV, both LDP peers MUST release any state information and omits the FT Session TLV, both LDP peers MUST release any
resources associated with the previous instantiation of the LDP state information and resources associated with the
session between the same LDP peers, including FT label state and previous instantiation of the LDP session between the
Addresses. This ensures that network resources are not permanently same LDP peers, including FT label state and Addresses.
lost by one LSR if its LDP peer is forced to undergo a cold start. This ensures that network resources are not permanently
lost by one LSR if its LDP peer is forced to undergo a
cold start.
If an LDP peer changes any session parameters (for example, the label If an LDP peer changes any session parameters (for
space bounds) from the previous instantiation the nature of any example, the label space bounds) from the previous
preserved labels may have changed. In particular, previously instantiation the nature of any preserved labels may have
allocated labels may now be out of range. For this reason, session changed. In particular, previously allocated labels may
reconnection MUST use the same parameters as were in use on the now be out of range. For this reason, session
session before the failure. If an LDP peer notices that the reconnection MUST use the same parameters as were in use
parameters have been changed by the other peer it SHOULD send a on the session before the failure. If an LDP peer
Notification message with the 'FT Session parameters changed' status notices that the parameters have been changed by the
code. other peer it SHOULD send a Notification message with the
'FT Session parameters changed' status code.
If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST If both LDP peers set the FT Reconnect Flag to 1, both
use the FT label operation procedures indicated in this draft to LDP peers MUST use the FT label operation procedures
complete any label operations on FT labels that were interrupted by indicated in this draft to complete any label operations
the LDP session failure. on FT labels that were interrupted by the LDP session
failure.
If an LDP peer receives an LDP Initialization message with the FT If an LDP peer receives an LDP Initialization message
Reconnect Flag set before it sends its own Initialization message, with the FT Reconnect Flag set before it sends its own
but has retained no information about the previous version of the Initialization message, but has retained no information
session, it MUST respond with an Initialization message with the FT about the previous version of the session, it MUST
Reconnect Flag clear. If an LDP peer receives an LDP Initialization respond with an Initialization message with the FT
message with the FT Reconnect Flag set in response to an Reconnect Flag clear. If an LDP peer receives an LDP
Initialization message that it has sent with the FT Reconnect Flag Initialization message with the FT Reconnect Flag set in
clear it MUST act as if no state was retained by either peer on the response to an Initialization message that it has sent
session. with the FT Reconnect Flag clear it MUST act as if no
state was retained by either peer on the session.
3.5 Operations on FT Labels 3.5. Operations on FT Labels
Label operations on FT labels are made Fault Tolerant by providing Label operations on FT labels are made Fault Tolerant by
acknowledgement of all LDP messages that affect FT labels. providing acknowledgement of all LDP messages that affect
Acknowledgements are achieved by means of sequence numbers on these FT labels.Acknowledgements are achieved by means of
LDP messages. sequence numbers on these LDP messages.
The message exchanges used to achieve acknowledgement of label The message exchanges used to achieve acknowledgement of
operations and the procedures used to complete interrupted label label operations and the procedures used to complete
operations are detailed in the section "FT Operations". interrupted label operations are detailed in the section
"FT Operations".
Using these acknowledgements and procedures, it is not necessary for Using these acknowledgements and procedures, it is not
LDP peers to perform a complete re-synchronization of state for all necessary for LDP peers to perform a complete re-
FT labels, either on re-connection of the LDP session between the LDP synchronization of state for all FT labels, either on re-
peers or on a timed basis. connection of the LDP session between the LDP peers or on
a timed basis.
3.6 Label Space Depletion and Replenishment 3.6. Check-Pointing
When an LDP peer is unable to satisfy a Label Request message because Check-pointing is a useful feature that allows nodes to
it has no more available labels, it sends a Notification message reduce the amount of processing that they need to do to
carrying the status code 'No label resources'. This warns the acknowledge LDP messages. The C bit in the FT Session
requesting LDP peer that subsequent Label Request messages are also TLV is used to indicate that checkpointing is supported.
likely to fail for the same reason. This message does not need to be
acknowledged for FT purposes since Label Request messages sent after
session recovery will receive the same response.
However, the LDP peer that receives a 'No label resources' Under the normal operation on FT labels, acknowledgments
Notification stops sending Label Request messages until it receives a may be deferred during normal processing and only sent
'Label resources available' Notification message. Since this periodically. Check-pointing may be used to flush
unsolicited Notification might get lost during session failure, it acknowledgement from a peer by including a sequence
must be protected using the procedures described in this draft. number on a Keepalive message requesting acknowledgement
of that message and all previous messages.
If the S bit is not agreed upon, checkpointing may still
be used. In this case it is used to acknowledge all
messages exchanged between the peers.
This offers an approach where acknowledgements need not
be sent to every message or even frequently, but are only
sent as check-points in response to requests carried on
Keepalive messages. Such an approach may be considered
optimal in systems that do not show a high degree of
change over time (such as targeted LDP session or CR-LDP
systems) and that are prepared to risk loss of state for
the most recent LDP exchanges. More dynamic systems
(such as LDP discovery sessions) are more likely to want
to acknowledge state changes more frequently so that the
maximum amount of state can be preserved over a failure.
Note that an important consideration of this draft is
that nodes acknowledging messages on a one-for-one basis,
nodes deferring acknowledgements, and nodes relying on
check-pointing should all interoperate seamlessly and
without protocol negotiation beyond session
initialization.
Further discussion of this feature is provided in the
section "FT Operations".
3.6.1 Graceful Termination
A feature that builds on check-pointing is graceful
termination.
In some cases, such as controlled failover or software
upgrade, it is possible for a node to know in advance
that it is going to terminate its session with a peer.
In these cases the node that intends terminating the
session can flush acknowledgement using a check-point
request as described above. The sender SHOULD not send
further label or address-related messages after
requesting shutdown check-pointing in order to preserve
the integrity of its saved state.
This, however, only provides for acknowledgement in one
direction, and the node that is terminating also requires
to know that it has secured all state sent by its peer.
This is achieved by a three-way hand shake of the check-
point which is requested by an additional TLV (the Cork
TLV) in the Keepalive message.
Further discussion of this feature is provided in the
section "FT Operations".
3.7. Label Space Depletion and Replenishment
When an LDP peer is unable to satisfy a Label Request
message because it has no more available labels, it sends
a Notification message carrying the status code 'No label
resources'. This warns the requesting LDP peer that
subsequent Label Request messages are also likely to fail
for the same reason. This message does not need to be
acknowledged for FT purposes since Label Request messages
sent after session recovery will receive the same
response. However, the LDP peer that receives a 'No
label resources' Notification stops sending Label Request
messages until it receives a 'Label resources available'
Notification message. Since this unsolicited
Notification might get lost during session failure, it
may be protected using the procedures described in this
draft.
An alternative approach allows that an implementation may
always assume that labels are available when a session is
re-established. In this case, it is possible that it may
throw away the 'No label resources' information from the
previous incarnation of the session and may send a batch
of LDP messages on session re-establishment that will
fail and that it could have known would fail.
Note that the sender of a 'Label resources available'
Notification message may choose whether to add a sequence
number requesting acknowledgement. Conversely, the
receiver of 'Label resources available' Notification
message may choose to acknowledge the message without
actually saving any state.
This is an implementation choice made possible by making
the FT parameters on the Notification message optional.
Implementations will interoperate fully if they take
opposite approaches, but additional LDP messages may be
sent unnecessarily on session recovery.
4. FT Operations 4. FT Operations
Once an FT LDP session has been established, using the procedures Once an FT LDP session has been established, using the S
described in the section "Establishing an FT LDP Session", both LDP bit in the FT Session TLV on the Session Initialization
peers MUST apply the procedures described in this section for FT LDP message as described in the section "Establishing an FT
message exchanges. LDP Session", both LDP peers MUST apply the procedures
described in this section for FT LDP message exchanges.
If the LDP session has been negotiated to not use the LDP FT If the LDP session has been negotiated to not use the LDP
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 FT Label Messages
A label is identified as being an FT label if the initial Label A label is identified as being an FT label if the initial
Request or Label Mapping message relating to that label carries the Label Request or Label Mapping message relating to that
FT Protection TLV. label carries the FT Protection TLV.
If a label is an FT label, all LDP messages affecting that label MUST It is a valid implementation option to flag all labels as
carry the FT Protection TLV in order that the state of the label can FT labels. Indeed this may be a preferred option for
be recovered after a failure of the LDP session. implementations wishing to use Keepalive messages
carrying the FT Protection TLV to achieve periodic saves
of the complete label forwarding state.
4.1.1.1 Scope of FT Labels 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.
The scope of the FT/non-FT status of a label is limited to the A valid option is for no labels on an FT session to be FT
LDP message exchanges between a pair of LDP peers. labels.
In Ordered Control, when the message is forwarded downstream or The checkpointing mechanism (see section 5) is an integral
upstream, the TLV may be present or absent according to the part of the FT procedures and is available whenever the FT
requirements of the LSR sending the message. procedures are selected. When the FT procedures are in use
checkpointing applies only to FT labels. If no labels on
the session are FT labels but the use of the FT procedures
has been negotiated, checkpointing will not secure any
message exchanges.
If a platform-wide label space is used for FT labels, an FT label If the FT procedures are not in use, checkpointing using the
value MUST NOT be reused until all LDP FT peers to which the label Keepalive message applies to all messages exchanged on the
was passed have acknowledged the withdrawal of the FT label, either
by an explicit LABEL WITHDRAW/LABEL RELEASE exchange or implicitly if
the LDP session is reconnected after failure but without the FT
Reconnect Flag set. In the event that a session is not re-
established within the Reconnection Timeout, a label MAY become
available for re-use if it is not still in use on some other
session. session.
4.1.1.1 Scope of FT Labels
The scope of the FT/non-FT status of a label is limited
to the LDP message exchanges between a pair of LDP peers.
In Ordered Control, when the message is forwarded
downstream or upstream, the TLV may be present or absent
according to the requirements of the LSR sending the
message.
If a platform-wide label space is used for FT labels, an
FT label value MUST NOT be reused until all LDP FT peers
to which the label was passed have acknowledged the
withdrawal of the FT label, either by an explicit LABEL
WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP
session is reconnected after failure but without the FT
Reconnect Flag set. In the event that a session is not
re-established within the Reconnection Timeout, a label
MAY become available for re-use if it is not still in use
on some other session.
4.1.2 FT Address Messages 4.1.2 FT Address Messages
If an LDP session uses the LDP FT enhancements, both LDP peers If an LDP session uses the LDP FT enhancements, both LDP
MUST secure Address and Address Withdraw messages using FT Operation peers MUST secure Address and Address Withdraw messages
ACKs, as described below. This avoids any ambiguity over whether using FT Operation ACKs, as described below. This avoids
an Address is still valid after the LDP session is reconnected. any ambiguity over whether an Address is still valid
after the LDP session is reconnected.
If an LSR determines that an Address message that it sent on a If an LSR determines that an Address message that it sent
previous instantiation of a recovered LDP session is no longer valid, on a previous instantiation of a recovered LDP session is
it MUST explicitly issue an Address Withdraw for that address when no longer valid, it MUST explicitly issue an Address
the session is reconnected. Withdraw for that address when the session is
reconnected.
If the FT Reconnect Flag is not set by both LDP peers on reconnection If the FT Reconnect Flag is not set by both LDP peers on
of an LDP session (i.e. state has not been preserved), both LDP reconnection of an LDP session (i.e. state has not been
peers MUST consider all Addresses to have been withdrawn. The LDP preserved), both LDP peers MUST consider all Addresses to
peers SHOULD issue new Address messages for all their valid addresses have been withdrawn. The LDP peers SHOULD issue new
as specified in [4]. Address messages for all their valid addresses as
specified in [4].
4.1.3 FT Label Resources Available Notification Messages 4.1.3 FT Label Resources Available Notification Messages
In LDP, it is possible that a downstream LSR may not have labels In LDP, it is possible that a downstream LSR may not have
available to respond to a Label Request. In this case, as specified labels available to respond to a Label Request. In this
in RFC3036, the downstream LSR must respond with a Notification - No case, as specified in RFC3036, the downstream LSR must
Label Resources message. The upstream LSR then suspends asking for respond with a Notification - No Label Resources message.
new labels until it receives a Notification - Label Resources The upstream LSR then suspends asking for new labels
until it receives a Notification - Label Resources
Available message from the downstream LSR. Available message from the downstream LSR.
When the FT extensions are used on a session: When the FT extensions are used on a session
1. The downstream LSR must preserve the label availability state implementations may choose whether to secure the label
across a failover so that it remembers to send Notification - resource state of their peer or not. This choice impacts
Label Resources Available when the resources become available. the number of LDP messages that will be incorrectly
2. The upstream LSR must recall the label availability state across routed to a peer with depleted resources on session re-
failover so that it can optimize not sending Label Requests when establishment, but does not otherwise impact
it recovers. interoperability.
3. The downstream LSR must use sequence numbers on Notification -
Label Resources Available so that it can check that LSR A has
received the message and clear its secured state, or resend the
message if LSR A recovers without having received it.
If the FT Reconnect Flag is not set by both LDP peers on reconnection For full preservation of state:
of an LDP session (i.e. state has not been preserved), both LDP
peers MUST consider the label availability state to have been reset
as if the session had been set up for the first time.
4.2 FT Operation ACKs - The downstream LSR must preserve the label availability
state across a failover so that it remembers to send
Notification - Label Resources Available when the resources
become available.
Handshaking of FT LDP messages is achieved by use of ACKs. - The upstream LSR must recall the label availability state
Correlation between the original message and the ACK is by means of across failover so that it can optimize not sending Label
the FT Sequence Number contained in the FT Protection TLV, and passed Requests when it recovers.
back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP
message that is sent on the TCP connection between LDP peers.
An LDP peer maintains a separate FT sequence number for each LDP - The downstream LSR must use sequence numbers on
session it participates in. The FT Sequence number is incremented by Notification - Label Resources Available so that it can
one for each FT LDP message (i.e. containing the FT Protection TLV) check that LSR A has received the message and clear its
issued by this LSR on the FT LDP session with which the FT sequence secured state, or resend the message if LSR A recovers
without having received it.
However, the following options also exist:
- The downstream LSR may choose to not include a sequence
number on Notification - Label Resources Available. This
means that on session re-establishment it does not know what
its peer thinks the LSR's resource state is, because the
Notification may or may not have been delivered. Such an
implementation MUST begin recovered sessions by sending an
additional Notification - Label Resources Available to reset
its peer.
- The upstream node may choose not to secure information
about its peer's resource state. It would acknowledge a
Notification - Label Resources Available, but would not save
the information. Such an implementation MUST assume that
its peer's resource satte has been reset to Label Resources
Available when the session is re-established.
If the FT Reconnect Flag is not set by both LDP peers on
reconnection of an LDP session (i.e. state has not been
preserved), both LDP peers MUST consider the label
availability state to have been reset as if the session
had been set up for the first time.
4.2. FT Operation ACKs
Handshaking of FT LDP messages is achieved by use of
ACKs. Correlation between the original message and the
ACK is by means of the FT Sequence Number contained in
the FT Protection TLV, and passed back in the FT ACK TLV.
The FT ACK TLV may be carried on any LDP message that is
sent on the TCP connection between LDP peers.
An LDP peer maintains a separate FT sequence number for
each LDP session it participates in. The FT Sequence
number is incremented by one for each FT LDP message
(i.e. containing the FT Protection TLV) issued by this
LSR on the FT LDP session with which the FT sequence
number is associated. number is associated.
When an LDP peer receives a message containing the FT Protection TLV, When an LDP peer receives a message containing the FT
it MUST take steps to secure this message (or the state information Protection TLV, it MUST take steps to secure this message
derived from processing the message). Once the message is secured, (or the state information derived from processing the
it MUST be ACKed. However, there is no requirement on the LSR to message). Once the message is secured, it MUST be ACKed.
send this ACK immediately. However, there is no requirement on the LSR to send this
ACK immediately.
ACKs may be accumulated to reduce the message flow between LDP peers. ACKs may be accumulated to reduce the message flow
For example, if an LSR received FT LDP messages with sequence numbers between LDP peers. For example, if an LSR received FT
1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK LDP messages with sequence numbers 1, 2, 3, 4, it could
receipt and securing of all these messages. send a single ACK with sequence number 4 to ACK receipt
and securing of all these messages. There is no protocol
reason why the number of ACKs accumulated or the time for
which an ACK is deferred should not be allowed to become
relatively large.
ACKs MUST NOT be sent out of sequence, as this is incompatible with ACKs MUST NOT be sent out of sequence, as this is
the use of accumulated ACKs. Duplicate ACKs (that is two successive incompatible with the use of accumulated ACKs. Duplicate
messages that acknowledge the same sequence number) are acceptable. ACKs (that is two successive messages that acknowledge
the same sequence number) are acceptable.
If an LDP peer discovers that its sequence number space for a If an LDP peer discovers that its sequence number space
specific session is full of un-acknowledged sequence numbers (because for a specific session is full of un-acknowledged
its partner on the session has not acknowledged them in a timely way) sequence numbers (because its partner on the session has
it cannot allocate a new sequence number for any further FT LPD not acknowledged them in a timely way) it cannot allocate
message. It SHOULD send a Notification message with the status code a new sequence number for any further FT LPD message. It
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, each LDP If the LDP FT enhancements are in use on an LDP session,
peer SHOULD NOT release the state information and resources each LDP peer SHOULD NOT release the state information
associated with FT labels exchanged on that LDP session when the TCP and resources associated with FT labels exchanged on that
connection fails. This is contrary to [2] and [4], but allows label LDP session when the TCP connection fails. This is
operations on FT labels to be completed after re-connection of the contrary to [2] and [4], but allows label operations on
TCP connection. FT labels to be completed after re-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 resources they enhancements SHOULD preserve the state information and
hold for that LDP session as described below. resources they hold for that LDP session as described
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 an FT label when it
initiates a Label Release or Label Abort message for the label. initiates a Label Release or Label Abort message for the
The upstream LDP peer MUST preserve state information for label. The upstream LDP peer MUST preserve state
the label, even if it releases the resources associated with the information for the label, even if it releases the resources
label, as it may need to reissue the label operation if the associated with the label, as it may need to reissue the
TCP connection is interrupted. 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 an and resources associated with an FT label when it receives
acknowledgement to a Label Release or Label Abort message that it an acknowledgement to a Label Release or Label Abort message
sent for the label, or when it sends a Label Release that it sent for the label, or when it sends a Label Release
message in response to a Label Withdraw message received from the message in response to a Label Withdraw message received
downstream LDP peer. 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 message associated with an FT label when it sends a Label Withdraw
for the label as it has not yet received confirmation that the message for the label as it has not yet received
upstream LDP peer has ceased to send data using the label. The confirmation that the upstream LDP peer has ceased to send
downstream LDP peer MUST NOT release the state information it data using the label. The downstream LDP peer MUST NOT
holds for the label as it may yet have to reissue the label release the state information it holds for the label as it
operation if the TCP connection is interrupted. may yet have to reissue the label operation if the TCP
connection is interrupted.
- A downstream LDP peer MUST release the resources and state - A downstream LDP peer MUST release the resources and
information associated with an FT label when it receives an state information associated with an FT label when it
acknowledgement to a Label Withdraw message for the label. receives an acknowledgement to a Label Withdraw message for
the label.
- When the FT Reconnection Timeout expires, an LSR SHOULD release - When the FT Reconnection Timeout expires, an LSR SHOULD
all state information and resources from previous instantiations release all state information and resources from previous
of the (permanently) failed LDP session. instantiations of the (permanently) failed LDP session.
- Either LDP peer MAY elect to release state information based on - Either LDP peer MAY elect to release state information
its internal knowledge of the loss of integrity of the state based on its internal knowledge of the loss of integrity of
information or an inability to pend (or queue) LDP operations the state information or an inability to pend (or queue) LDP
(as described in section 4.4.1) during a TCP failure. That is, operations (as described in section 4.4.1) during a TCP
the peer is not required to wait for the duration of the FT failure. That is, the peer is not required to wait for the
Reconnection Timeout before releasing state; the timeout provides duration of the FT Reconnection Timeout before releasing
an upper limit on the persistence of state. However, In the event state; the timeout provides an upper limit on the
that a peer releases state before the expiration of the persistence of state. However, in the event that a peer
Reconnection Timeout it MUST NOT re-use any label that was in use releases state before the expiration of the Reconnection
on the session until the Reconnection Timeout has expired. Timeout it MUST NOT re-use any label that was in use on the
session until the Reconnection Timeout has expired.
- When an LSR receives a Status TLV with the E-bit set in - When an LSR receives a Status TLV with the E-bit set in
the status code, which causes it to close the TCP connection, the the status code, which causes it to close the TCP
LSR MUST release all state information and resources associated connection, the LSR MUST release all state information and
with the session. This behavior is mandated because it is resources associated with the session. This behavior is
impossible for the LSR to predict the precise state and future mandated because it is impossible for the LSR to predict the
behavior of the partner LSR that set the E-bit without knowledge precise state and future behavior of the partner LSR that
of the implementation of that partner LSR. set the E-bit without knowledge of the implementation of
that partner LSR.
Note that the "Temporary Shutdown" status code does not have the
E-bit set, and MAY be used during maintenance or upgrade
operations to indicate that the LSR intends to preserve state
across a closure and re-establishment of the TCP session.
- If an LSR determines that it must release state for any single FT Note that the "Temporary Shutdown" status code does not have
label during a failure of the TCP connection on which that label the E-bit set, and MAY be used during maintenance or upgrade
was exchanged, it MUST release all state for all labels on the LDP operations to indicate that the LSR intends to preserve
state across a closure and re-establishment of the TCP
session. session.
The release of state information and resources associated with non-FT - If an LSR determines that it must release state for any
labels is as described in [2] and [4]. single FT label during a failure of the TCP connection on
which that label was exchanged, it MUST release all state
for all labels on the LDP session.
Note that a Label Release and the acknowledgement to a Label Withdraw The release of state information and resources associated
may be received by a downstream LSR in any order. The downstream LSR with non-FT labels is as described in [2] and [4].
MAY release its resources on receipt of the first message and MUST
release its resources on receipt of the second message.
4.4 FT Procedure After TCP Failure Note that a Label Release and the acknowledgement to a
Label Withdraw may be received by a downstream LSR in any
order. The downstream LSR MAY release its resources on
receipt of the first message and MUST release its
resources on receipt of the second message.
When an LSR discovers or is notified of a TCP connection failure it 4.4. FT Procedure After TCP Failure
SHOULD start an FT Reconnection Timer to allow a period for
re-connection of the TCP connection between the LDP peers.
The RECOMMENDED default value for this timer is 5 seconds. During When an LSR discovers or is notified of a TCP connection
this time, failure must be detected and reported, new hardware may failure it SHOULD start an FT Reconnection Timer to allow
need to be activated, software state must be audited, and a new TCP a period for re-connection of the TCP connection between
session must be set up. the LDP peers.
Once the TCP connection between LDP peers has failed, the active LSR The RECOMMENDED default value for this timer is 5
SHOULD attempt to re-establish the TCP connection. The mechanisms, seconds. During this time, failure must be detected and
timers and retry counts to re-establish the TCP connection are an reported, new hardware may need to be activated, software
implementation choice. It is RECOMMENDED that any attempt to state must be audited, and a new TCP session must be set
re-establish the connection take account of the failover processing up.
necessary on the peer LSR, the nature of the network between the
LDP peers, and the FT Reconnection Timeout chosen on the previous
instantiation of the TCP connection (if any).
If the TCP connection cannot be re-established within the FT Once the TCP connection between LDP peers has failed, the
Reconnection Timeout period, the LSR detecting this timeout SHOULD active LSR SHOULD attempt to re-establish the TCP
release all state preserved for the failed LDP session. If the TCP connection. The mechanisms, timers and retry counts to re-
connection is subsequently re-established (for example, after a establish the TCP connection are an implementation
further Hello exchange to set up a new LDP session), the LSR MUST set choice. It is RECOMMENDED that any attempt to re-
the FT Reconnect Flag to 0 if it released the preserved state establish the connection take account of the failover
processing necessary on the peer LSR, the nature of the
network between the LDP peers, and the FT Reconnection
Timeout chosen on the previous instantiation of the TCP
connection (if any).
If the TCP connection cannot be re-established within the
FT Reconnection Timeout period, the LSR detecting this
timeout SHOULD release all state preserved for the failed
LDP session. If the TCP connection is subsequently re-
established (for example, after a further Hello exchange
to set up a new LDP session), the LSR MUST set the FT
Reconnect Flag to 0 if it released the preserved state
information on this timeout event. information on this timeout event.
If the TCP connection is successfully re-established within the FT If the TCP connection is successfully re-established
Reconnection Timeout, both peers MUST re-issue LDP operations that within the FT Reconnection Timeout, both peers MUST re-
were interrupted by (that is, un-acknowledged as a result of) the TCP issue LDP operations that were interrupted by (that is,
connection failure. This procedure is described in section "FT un-acknowledged as a result of) the TCP connection
failure. This procedure is described in section "FT
Procedure After TCP Re-connection". Procedure After TCP Re-connection".
The Hold Timer for an FT LDP Session (see [4] section 2.5.5) SHOULD The Hold Timer for an FT LDP Session (see [4] section
be ignored while the FT Reconnection Timer is running. The hold 2.5.5) SHOULD be ignored while the FT Reconnection Timer
timer SHOULD be restarted when the TCP connection is re-established. is running. The hold timer SHOULD be restarted when the
TCP connection is re-established.
4.4.1 FT LDP Operations During TCP Failure 4.4.1 FT LDP Operations During TCP Failure
When the LDP FT enhancements are in use for an LDP session, it is When the LDP FT enhancements are in use for an LDP
possible that an LSR may determine that it needs to send an LDP session, it is possible that an LSR may determine that it
message to an LDP peer but that the TCP connection to that peer is needs to send an LDP message to an LDP peer but that the
currently down. These label operations affect the state of FT labels TCP connection to that peer is currently down. These
preserved for the failed TCP connection, so it is important that the label operations affect the state of FT labels preserved
state changes are passed to the LDP peer when the TCP connection is for the failed TCP connection, so it is important that
restored. the state changes are passed to the LDP peer when the TCP
connection is restored.
If an LSR determines that it needs to issue a new FT LDP operation to If an LSR determines that it needs to issue a new FT LDP
an LDP peer to which the TCP connection is currently failed, it MUST operation to an LDP peer to which the TCP connection is
pend the operation (e.g. on a queue) and complete that operation currently failed, it MUST pend the operation (e.g. on a
with the LDP peer when the TCP connection is restored, unless the queue) and complete that operation with the LDP peer when
label operation is overridden by a subsequent additional operation the TCP connection is restored, unless the label
during the TCP connection failure (see section "FT Procedure After operation is overridden by a subsequent additional
TCP Re-connection"). operation during the TCP connection failure (see section
"FT Procedure After TCP Re-connection").
If, during TCP Failure, an LSR determines that it cannot pend an If, during TCP Failure, an LSR determines that it cannot
operation which it cannot simply fail (for example a Label Withdraw, pend an operation which it cannot simply fail (for
Release, or Abort operation), it MUST NOT attempt to re-establish example a Label Withdraw, Release, or Abort operation),
the previous LDP session. The LSR MUST behave as if the Reconnection it MUST NOT attempt to re-establish the previous LDP
Timer expired and release all state information with respect to the session. The LSR MUST behave as if the Reconnection
LDP peer. An LSR may be unable (or unwilling) to pend operations; Timer expired and release all state information with
for instance, if a major routing transition occurred while TCP was respect to the LDP peer. An LSR may be unable (or
inoperable between LDP peers it might result in excessively large unwilling) to pend operations; for instance, if a major
numbers of FT LDP Operations. An LSR that releases state before the routing transition occurred while TCP was inoperable
expiration of the Reconnection Timeout MUST NOT re-use any label that between LDP peers it might result in excessively large
was in use on the session until the Reconnection Timeout has expired. numbers of FT LDP Operations. An LSR that releases state
before the expiration of the Reconnection Timeout MUST
NOT re-use any label that was in use on the session until
the Reconnection Timeout has expired.
In ordered operation, received FT LDP operations that cannot be In ordered operation, received FT LDP operations that
correctly forwarded because of a TCP connection failure MAY be cannot be correctly forwarded because of a TCP connection
processed immediately (provided sufficient state is kept to forward failure MAY be processed immediately (provided sufficient
the label operation) or pended for processing when the onward TCP state is kept to forward the label operation) or pended
connection is restored and the operation can be correctly forwarded for processing when the onward TCP connection is restored
upstream or downstream. Operations on existing FT labels SHOULD NOT and the operation can be correctly forwarded upstream or
downstream. Operations on existing FT labels SHOULD NOT
be failed during TCP session failure. be failed during TCP session failure.
It is RECOMMENDED that Label Request operations for new FT labels are It is RECOMMENDED that Label Request operations for new
not pended awaiting the re-establishment of TCP connection that is FT labels are not pended awaiting the re-establishment of
awaiting recovery at the time the LSR determines that it needs to TCP connection that is awaiting recovery at the time the
issue the Label Request message. Instead, such Label Request LSR determines that it needs to issue the Label Request
operations SHOULD be failed and, if necessary, a notification message message. Instead, such Label Request operations SHOULD
containing the "No LDP Session" status code sent upstream. be failed and, if necessary, a notification message
containing the "No LDP Session" status code sent
upstream.
Label Requests for new non-FT labels MUST be rejected during TCP Label Requests for new non-FT labels MUST be rejected
connection failure, as specified in [2] and [4]. during TCP connection failure, as specified in [2] and
[4].
4.5 FT Procedure After TCP Re-connection 4.5. FT Procedure After TCP Re-connection
The FT operation handshaking described above means that all state The FT operation handshaking described above means that
changes for FT labels and Address messages are confirmed or all state changes for FT labels and Address messages are
reproducible at each LSR. confirmed or reproducible at each LSR.
If the TCP connection between LDP peers fails but is re-connected If the TCP connection between LDP peers fails but is re-
within the FT Reconnection Timeout, and both LSRs have indicated connected within the FT Reconnection Timeout, and both
they will be re-establishing the previous LDP session, both LDP LSRs have indicated they will be re-establishing the
peers on the connection MUST complete any label operations for FT previous LDP session, both LDP peers on the connection
labels that were interrupted by the failure and re-connection of MUST complete any label operations for FT labels that
the TCP connection. were interrupted by the failure and re-connection of the
TCP connection.
The procedures for FT Reconnection Timeout MAY have been invoked as The procedures for FT Reconnection Timeout MAY have been
a result of either LDP peer being unable (or unwilling) to pend invoked as a result of either LDP peer being unable (or
operations which occurred during the TCP Failure (as described in unwilling) to pend operations which occurred during the
section 4.4.1). TCP Failure (as described in section 4.4.1).
If, for any reason, an LSR has been unable to pend operations with If, for any reason, an LSR has been unable to pend
respect to an LDP peer, as described in section 4.4.1, the LSR MUST operations with respect to an LDP peer, as described in
set the FT Reconnect Flag to 0 on re-connection to that LDP peer section 4.4.1, the LSR MUST set the FT Reconnect Flag to
indicating that no FT state has been preserved. 0 on re-connection to that LDP peer indicating that no FT
state has been preserved.
Label operations are completed using the procedure described below. Label operations are completed using the procedure
described below.
4.5.1 Re-Issuing FT Messages 4.5.1 Re-Issuing FT Messages
On restoration of the TCP connection between LDP peers, any FT On restoration of the TCP connection between LDP peers,
LDP messages that were lost because of the TCP connection any FT LDP messages that were lost because of the TCP
failure are re-issued. The LDP peer that receives a re-issued message connection failure are re-issued. The LDP peer that
processes the message as if received for the first time. receives a re-issued message processes the message as if
received for the first time.
"Net-zero" combinations of messages need not be re-issued after "Net-zero" combinations of messages need not be re-issued
re-establishment of the TCP connection between LDP peers. This leads after re-establishment of the TCP connection between LDP
to the following rules for re-issuing messages that are not ACKed by peers. This leads to the following rules for re-issuing
the LDP peer on the LDP Initialization message exchange after messages that are not ACKed by the LDP peer on the LDP
re-connection of the TCP session. Initialization message exchange after re-connection of
the TCP session.
- A Label Request message MUST be re-issued unless a Label Abort - A Label Request message MUST be re-issued unless a Label
would be re-issued for the same FT label. Abort would be re-issued for the same FT label.
- A Label Mapping message MUST be re-issued unless a Label Withdraw - A Label Mapping message MUST be re-issued unless a Label
message would be re-issued for the same FT label. Withdraw message would be re-issued for the same FT label.
- All other messages on the LDP session that carried the FT - All other messages on the LDP session that carried the FT
Protection TLV MUST be re-issued if an acknowledgement had not Protection TLV MUST be re-issued if an acknowledgement had
previously been received. not previously been received.
Any FT label operations that were pended (see section "FT Label Any FT label operations that were pended (see section "FT
Operations During TCP Failure") during the TCP connection failure Label Operations During TCP Failure") during the TCP
MUST also be issued on re-establishment of the LDP session, except connection failure MUST also be issued on re-
where they form part of a "net-zero" combination of messages establishment of the LDP session, except where they form
according to the above rules. part of a "net-zero" combination of messages according to
the above rules.
The determination of "net-zero" FT label operations according to the The determination of "net-zero" FT label operations
above rules MAY be performed on pended messages prior to the according to the above rules MAY be performed on pended
re-establishment of the TCP connection in order to optimize the use messages prior to the re-establishment of the TCP
of queue resources. Messages that were sent to the LDP peer before connection in order to optimize the use of queue
the TCP connection failure, or pended messages that are paired with resources. Messages that were sent to the LDP peer
them, MUST NOT be subject to such optimization until an FT ACK TLV is before the TCP connection failure, or pended messages
received from the LDP peer. This ACK allows the LSR to identify that are paired with them, MUST NOT be subject to such
which messages were received by the LDP peer prior to the TCP optimization until an FT ACK TLV is received from the LDP
connection failure. peer. This ACK allows the LSR to identify which messages
were received by the LDP peer prior to the TCP connection
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 the use of Re-issuing LDP messages for FT operation is orthogonal to
duplicate messages marked with the Modify ActFlg, as specified in the use of duplicate messages marked with the Modify
[5]. Each time an LSR uses the modification procedure for an FT LSP ActFlg, as specified in [5]. Each time an LSR uses the
to issue a new Label Request message, the FT label operation modification procedure for an FT LSP to issue a new Label
procedures MUST be separately applied to the new Label Request Request message, the FT label operation procedures MUST
message. be separately applied to the new Label Request message.
5. Changes to Existing Messages 5. Checkpointing Procedures
5.1 LDP Initialization Message Checkpointing can be selected independently from the FT
procedures described above by using the C bit in the FT
Session TLV on the Session Initialization message. Note,
however, that checkpointing is an integral part of the FT
procedures. Setting the S and the C bit will achieve the
same function as setting just the S bit.
The LDP FT enhancements add the following optional parameters to a If the C bit is set, but the S bit is not set, no label
LDP Initialization message is an FT label. Checkpointing is used to synchronize all
labels exchanges for labels requested or distributed by
the LDP peer requesting the exchange up to the time of
requesting the checkpoint. No message apart from the
checkpoint request and acknowledgement carries an active
sequence number. (Note that the Session Initialization
message may carry a sequence number to confirm that the
checkpoint is still in place).
It is an implementation matter to decide the ordering of
received messages and checkpoint requests to ensure that
checkpoint acknowledgements are secured.
If the S and C bits are both set, or only the S bit is
set, checkpointing applies only to FT labels and to
address messages.
The set of all messages that are checkpointed in this way
is called the Checkpointable Messages.
5.1 Checkpointing with the Keepalive Message
If an LSR receives a FT Protection TLV on a Keepalive
message, this is a request to flush the acknowledgements
for all previously received Checkpointable Messages on
the session.
As soon as the LSR has completed securing the
Checkpointable Messages (or state changes consequent on
those messages) received before the Keepalive, it MUST
send an acknowledgement to the sequence number of the
Keepalive message.
In the case where the FT procedures are in use and
acknowledgements have been stored up, this may be
immediately on receipt of the Keepalive.
An example message flow showing this use of the Keepalive
message to perform a periodic check-point of state is
shown in section 8.
An example message flow showing the use of checkpointing
without the FT procedures is shown in section 8.
5.2 Quiesce and Keepalive
If the Keepalive Message also contains the FT Cork TLV,
this indicates that the peer LSR wishes to quiesce the
session prior to a graceful restart.
It is RECOMMENDED that on receiving a Keepalive with the
FT CORK TLV, an LSR should cease to send any further
label or address related messages on the session until it
has been disconnected and reconnected, other than any
messages generated while processing and securing any
previously unacknowledged messages received from the peer
requesting the quiesce. It should also attempt to
complete this processing and return a Keepalive with the
FT ACK TLV as soon as possible in order to allow the
session to be quiesced.
An example message flow showing this use of the FT Cork
TLV to achieves three-way handshake of state
synchronization between two LDP peers is given in section 8.
6. Changes to Existing Messages
6.1. LDP Initialization Message
The LDP FT enhancements add the following optional
parameters to a LDP Initialization message
Optional Parameter Length Value Optional Parameter Length Value
FT Session TLV 4 See below FT Session TLV 4 See below
FT ACK TLV 4 See below FT ACK TLV 4 See below
The encoding for these TLVs is found in Section "New Fields and The encoding for these TLVs is found in Section "New
Values". Fields and Values".
FT Session FT Session
If present, specifies the FT behavior of the LDP session. If present, specifies the FT behavior of
the LDP session.
FT ACK TLV FT ACK TLV
If present, specifies the last FT message that the sending LDP If present, specifies the last FT message
peer was able to secure prior to the failure of the previous that the sending LDP peer was able to
instantiation of the LDP session. This TLV is only present if secure prior to the failure of the previous
the FT Reconnect flag is set in the FT Session TLV, in which instantiation of the LDP session. This TLV
case this TLV MUST be present. is only present if the FT Reconnect flag is
set in the FT Session TLV, in which case
this TLV MUST be present.
5.2 LDP Keepalive Messages 6.2. LDP Keepalive Messages
The LDP FT enhancements add the following optional parameter to a The LDP FT enhancements add the following optional
LDP Keepalive message parameters to a LDP Keepalive message
Optional Parameter Length Value Optional Parameter Length Value
FT Protection TLV 4 See below
FT Cork TLV 0 See below
FT ACK TLV 4 See below FT ACK TLV 4 See below
The encoding for FT ACK TLV is found in Section "FT ACK TLV". The encoding for these TLVs is found in Section "New
Fields and Values".
FT Protection
If present, specifies FT Sequence Number
for the LDP message. When present on a
Keepalive message, this indicates a
solicited flush of the acknowledgements to
all previous LDP messages containing
sequence numbers and issued by the sender
of the Keepalive on the same session.
FT Cork
Only permitted if the FT Protection TLV is
also present. Indicates that the remote
LSR wishes to quiesce the LDP session. See
section 4.2 for the recommended action in
such cases.
FT ACK TLV FT ACK TLV
If present, specifies the most recent FT message that the If present, specifies the most recent FT
sending LDP peer has been able to secure. message that the sending LDP peer has been
able to secure.
5.3 All Other LDP Session Messages 6.3. All Other LDP Session Messages
The LDP FT enhancements add the following optional parameters to all The LDP FT enhancements add the following optional
other message types that flow on an LDP session after the LDP parameters to all other message types that flow on an LDP
Initialization message session after the LDP Initialization message
Optional Parameter Length Value Optional Parameter Length Value
FT Protection TLV 4 See below FT Protection TLV 4 See below
FT ACK TLV 4 See below FT ACK TLV 4 See below
The encoding for these TLVs is found in the section "New Fields and The encoding for these TLVs is found in the section "New
Values". Fields and Values".
FT Protection FT Protection
If present, specifies FT Sequence Number for the LDP message. If present, specifies FT Sequence Number
for the LDP message.
FT ACK FT ACK
If present, identifies the most recent FT LDP message If present, identifies the most recent FT
ACKed by the sending LDP peer. LDP message ACKed by the sending LDP peer.
6. New Fields and Values 7. New Fields and Values
6.1 Status Codes 7.1. Status Codes
The following new status codes are defined to indicate various The following new status codes are defined to indicate
conditions specific to the LDP FT enhancements. These status codes various conditions specific to the LDP FT enhancements.
are carried in the Status TLV of a Notification message. These status codes are carried in the Status TLV of a
Notification message.
The "E" column is the required setting of the Status Code E-bit; the The "E" column is the required setting of the Status Code
"Status Data" column is the value of the 30-bit Status Data field in E-bit; the "Status Data" column is the value of the 30-
the Status Code TLV. bit Status Data field in the Status Code TLV.
Note that the setting of the Status Code F-bit is at the discretion Note that the setting of the Status Code F-bit is at the
of the LSR originating the Status TLV. However, it is RECOMMENDED discretion of the LSR originating the Status TLV.
that the F-bit is not set on Notification messages containing However, it is RECOMMENDED that the F-bit is not set on
status codes except "No LDP Session" because the duplication of Notification messages containing status codes except "No
messages SHOULD be restricted to being a per-hop behavior. LDP Session" because the duplication of messages SHOULD
be restricted to being a per-hop behavior.
Status Code E Status Data Status Code E Status Data
No LDP Session 0 0x000000xx No LDP Session 0 0x000000xx
Zero FT seqnum 1 0x000000xx Zero FT seqnum 1 0x000000xx
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x000000xx
Session Not FT Session Not FT
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x000000xx
Label Not FT Label Not FT
Missing FT Protection TLV 1 0x000000xx Missing FT Protection TLV 1 0x000000xx
FT ACK sequence error 1 0x000000xx FT ACK sequence error 1 0x000000xx
Temporary Shutdown 0 0x000000xx Temporary Shutdown 0 0x000000xx
FT Seq Numbers Exhausted 1 0x000000xx FT Seq Numbers Exhausted 1 0x000000xx
FT Session parameters / 1 0x000000xx FT Session parameters / 1 0x000000xx
changed changed
Unexpected FT Cork TLV 1 0x000000xx
The Temporary Shutdown status code SHOULD be used in place of The Temporary Shutdown status code SHOULD be used in
the Shutdown status code (which has the E-bit set) if the LSR that is place of the Shutdown status code (which has the E-bit
shutting down wishes to inform its LDP peer that it expects to be set) if the LSR that is shutting down wishes to inform
able to preserve FT label state and to return to service before the its LDP peer that it expects to be able to preserve FT
FT Reconnection Timer expires. label state and to return to service before the FT
Reconnection Timer expires.
6.2 FT Session TLV 7.2. FT Session TLV
LDP peers can negotiate whether the LDP session between them supports LDP peers can negotiate whether the LDP session between
FT extensions by using a new OPTIONAL parameter, the FT Session them supports FT extensions by using a new OPTIONAL
TLV, on LDP Initialization Messages. parameter, the FT Session TLV, on LDP Initialization
Messages.
The FT Session TLV is encoded as follows. The FT Session 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FT Session TLV (0x0503) | Length (= 4) | |1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | FT Reconnection Timeout | | FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags FT Flags
FT Flags: A 16 bit field that indicates various attributes the FT Flags: A 16 bit field that indicates various
FT support on this LDP session. This fields is formatted as attributes the FT support on this LDP session.
follows: 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 | |R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag. R: FT Reconnect Flag.
Set to 1 if the sending LSR has preserved state and
resources for all FT-labels since the previous LDP
session between the same LDP peers, and set to 0
otherwise. See the section "FT LDP Session
Reconnection" for details of how this flag is used.
If the FT Reconnect Flag is set, the sending LSR must Set to 1 if the sending LSR has
include an FT ACK TLV on the LDP Initialization message. preserved state and resources for all
FT-labels since the previous LDP
session between the same LDP peers,
and set to 0 otherwise. See the
section "FT LDP Session Reconnection"
for details of how this flag is used.
All other bits in this field are currently reserved and SHOULD If the FT Reconnect Flag is set, the
be set to zero on transmission and ignored on receipt. sending LSR MUST include an FT ACK TLV
on the LDP Initialization message.
S: Save State Flag.
Set to 1 if the use of the FT
Protection TLV is supported on
messages other than the KeepAlive
message used for chekpointing (see the
C bit)
A: All-Label Protection Required
Set to 1 if all labels on the session
MUST be treated as FT Labels. This
removes from a node the option of
treating some labels as FT labels and
some labels as non-FT labels.
Passing this information may be
considered helpful to a peer since it
may allow it to make optimizations in
its processing.
The A bit only has meaning if the S
bit is set.
C: Checkpointing Flag.
Set to 1 to indicate that the
checkpointing procedures in this draft
are in use.
If the S bit is also set to 1 then the
C bit indicates that checkpointing is
applied only to those message
exchanges that carry the FT Protection
TLV.
If the S bit is set to 0 (zero) then
the C bit indicates that checkpointing
applies to all message exchanges on
the session.
L: Learn From Network Flag.
Set to 1 if the Fault Recovery
procedures of [12] are to be 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 both the L and either the S or C bits
to be set to 1.
FT Reconnection Timeout FT Reconnection Timeout
The period of time the sending LSR will preserve state and If the S bit or C bit in the FT Flags field
resources for FT labels exchanged on the previous instantiation of is set this indicates the period of time
an FT LDP session that has currently failed. The timeout is the sending LSR will preserve state and
encoded as a 16-bit unsigned integer number of seconds. resources for FT labels exchanged on the
previous instantiation of an FT LDP session
that has currently failed. The timeout is
encoded as a 32-bit unsigned integer number
of milliseconds.
A value of zero in this field means that the sending LSR will A value of zero in this field means that
preserve state and resources indefinitely. the sending LSR will preserve state and
resources indefinitely.
See the section "FT Procedure After TCP Failure" for details of how See the section "FT Procedure After TCP
this field is used. Failure" for details of how this field is
used.
6.3 FT Protection TLV If the L bit is set to 1 in the FT Flags
field, the meaning of this field is defined
in [12].
LDP peers use the FT Protection TLV to indicate that an LDP message Recovery Time
contains an FT label operation. The Recovery Time only has meaning if the L
bit is set in the FT Flags. The meaning is
defined in [12].
The FT Protection TLV MUST NOT be used in messages flowing on an LDP 7.3. FT Protection TLV
session that does not support the LDP FT enhancements. Its presence
in such messages SHALL be treated as a protocol error by the LDP peers use the FT Protection TLV to indicate that an
receiving LDP peer which SHOULD send a Notification message with the LDP message contains an FT label operation.
The FT Protection TLV MUST NOT be used in messages
flowing on an LDP session that does not support the LDP
FT enhancements. Its presence in such messages SHALL be
treated as a protocol error by the receiving LDP peer
which SHOULD send a Notification message with the
'Unexpected TLV Session Not FT' status code. 'Unexpected TLV Session Not FT' status code.
The FT Protection TLV MAY be carried on an LDP message transported on The FT Protection TLV MAY be carried on an LDP message
the LDP session after the initial exchange of LDP Initialization transported on the LDP session after the initial exchange
messages. In particular, this TLV MAY optionally be present on the of LDP Initialization messages. In particular, this TLV
following messages: MAY optionally be present on the following messages:
- Label Request Messages in downstream on-demand distribution mode - Label Request Messages in downstream on-demand
- Label Mapping messages in downstream unsolicited mode. distribution mode
- Label Mapping messages in downstream unsolicited mode
- Keepalive messages used to request flushing of
acknowledgement of all previous messages that contained this
TLV.
If a label is to be an FT label, then the Protection TLV
MUST be present:
If a label is to be an FT label, then 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 any message Here 'subsequent messages concerning this label' means
whose Label TLV specifies this label or whose Label Request Message any message whose Label TLV specifies this label or whose
ID TLV specifies the initial Label Request message. Label Request Message ID TLV specifies the initial Label
Request message.
If a label is not to be an FT label, then the Protection TLV If a label is not to be an FT label, then the Protection
MUST NOT be present on any of these messages. The presence of the FT TLV MUST NOT be present on any of these messages. The
TLV on a message relating to a non-FT label SHALL be treated as a presence of the FT TLV on a message relating to a non-FT
protocol error by the receiving LDP peer which SHOULD send a label SHALL be treated as a protocol error by the
notification message with the 'Unexpected TLV Label Not FT' status receiving LDP peer which SHOULD send a notification
message with the 'Unexpected TLV Label Not FT' status
code. code.
Where a Label Withdraw or Label Release message contains only a FEC Where a Label Withdraw or Label Release message contains
TLV and does not identify a single specific label, the FT TLV should only a FEC TLV and does not identify a single specific
be included in the message if any label affected by the message is an label, the FT TLV should be included in the message if
FT label. If there is any doubt as to whether an FT TLV should be any label affected by the message is an FT label. If
there is any doubt as to whether an FT TLV should be
present, it is RECOMMENDED that the sender add the TLV. present, it is RECOMMENDED that the sender add the TLV.
When an LDP peer receives a Label Withdraw Message or Label Release When an LDP peer receives a Label Withdraw Message or
message that contains only a FEC, it SHALL accept the FT TLV if it is Label Release message that contains only a FEC, it SHALL
present regardless of the FT status of the labels which it affects. accept the FT TLV if it is present regardless of the FT
status of the labels which it affects.
If an LDP session is an FT session as determined by the presence of If an LDP session is an FT session as determined by the
the FT Session TLV on the LDP Initialization messages, the FT presence of the FT Session TLV with the S bit set on the
Protection TLV MUST be present: LDP Initialization messages, the FT Protection TLV MUST
- on all Address messages on the session be present on all Address messages on the session.
- on all Notification messages on the session that have the status
code 'Label Resources Available'. If the session is an FT session, the FT Protection TLV
may also optionally be present
- on Notification messages on the session that have the
status code 'Label Resources Available'
- on Keepalive messages.
The FT Protection TLV is encoded as follows. The FT Protection TLV is encoded as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) | |0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number | | FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number FT Sequence Number
The sequence number for this FT label operation. The The sequence number for this FT label
sequence number is encoded as a 32-bit unsigned integer. The operation. The sequence number is encoded
initial value for this field on a new LDP session is 0x00000001 and as a 32-bit unsigned integer. The initial
is incremented by one for each FT LDP message issued by the sending value for this field on a new LDP session
LSR on this LDP session. This field may wrap from 0xFFFFFFFF to is 0x00000001 and is incremented by one for
0x00000001. each FT LDP message 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 either LDP peer does not This field MUST be reset to 0x00000001 if
set the FT Reconnect Flag on re-establishment of the TCP either LDP peer does not set the FT
connection. Reconnect Flag on re-establishment of the
TCP connection.
See the section "FT Operation Acks" for details of how this field See the section "FT Operation Acks" for
is used. details of how this field is used.
The special use of 0x00000000 is discussed in the section "FT ACK The special use of 0x00000000 is discussed
TLV" below. in the section "FT ACK TLV" below.
If an LSR receives an FT Protection TLV on a session that does not If an LSR receives an FT Protection TLV on a session that
support the FT LDP enhancements, it SHOULD send a Notification does not support the FT LDP enhancements, it SHOULD send
message to its LDP peer containing the "Unexpected TLV, Session Not a Notification message to its LDP peer containing the
FT" status code. "Unexpected TLV, Session Not FT" status code.
If an LSR receives an FT Protection TLV on an operation affecting a If an LSR receives an FT Protection TLV on an operation
label that it believes is a non-FT label, it SHOULD send a affecting a label that it believes is a non-FT label, it
Notification message to its LDP peer containing the "Unexpected TLV, SHOULD send a Notification message to its LDP peer
Label Not FT" status code. containing the "Unexpected TLV, Label Not FT" status
code.
If an LSR receives a message without the FT Protection TLV affecting If an LSR receives a message without the FT Protection
a label that it believes is an FT label, it SHOULD send a TLV affecting a label that it believes is an FT label, it
Notification message to its LDP peer containing the "Missing FT SHOULD send a Notification message to its LDP peer
Protection TLV" status code. containing the "Missing FT Protection TLV" status code.
If an LSR receives an FT Protection TLV containing a zero FT If an LSR receives an FT Protection TLV containing a zero
Sequence Number, it SHOULD send a Notification message to its LDP FT Sequence Number, it SHOULD send a Notification message
peer containing the "Zero FT Seqnum" status code. to its LDP peer containing the "Zero FT Seqnum" status
code.
6.4 FT ACK TLV 7.4. FT ACK TLV
LDP peers use the FT ACK TLV to acknowledge FT label operations. LDP peers use the FT ACK TLV to acknowledge FT label
operations.
The FT ACK TLV MUST NOT be used in messages flowing on an LDP session The FT ACK TLV MUST NOT be used in messages flowing on an
that does not support the LDP FT enhancements. Its presence on such LDP session that does not support the LDP FT
messages SHALL be treated as a protocol error by the receiving LDP enhancements. Its presence on such messages SHALL be
peer. treated as a protocol error by the receiving LDP peer.
The FT ACK TLV MAY be present on any LDP message exchanged on an The FT ACK TLV MAY be present on any LDP message
LDP session after the initial LDP Initialization messages. It is exchanged on an LDP session after the initial LDP
RECOMMENDED that the FT ACK TLV is included on all FT Initialization messages. It is RECOMMENDED that the FT
Keepalive messages in order to ensure that the LDP peers do not ACK TLV is included on all FT Keepalive messages in order
build up a large backlog of unacknowledged state information. to ensure that the LDP peers do not build up a large
backlog of unacknowledged state information.
The FT ACK TLV is encoded as follows. The FT ACK TLV is encoded as follows.
0 1 2 3 0 1 2 3
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 label message The sequence number for this most recent FT
that the sending LDP peer has received from the receiving LDP label message that the sending LDP peer has
peer and secured against failure of the LDP session. It is not received from the receiving LDP peer and
necessary for the sending peer to have fully processed the message secured against failure of the LDP session.
before ACKing it. For example, an LSR MAY ACK a Label Request It is not necessary for the sending peer to
message as soon as it has securely recorded the message, without have fully processed the message before
waiting until it can send the Label Mapping message in response. ACKing it. For example, an LSR MAY ACK a
Label Request message as soon as it has
securely recorded the message, without
waiting until it can send the Label Mapping
message in response.
ACKs are cumulative. Receipt of an LDP message containing an FT ACKs are cumulative. Receipt of an LDP
ACK TLV with an FT ACK Sequence Number of 12 is treated as the message containing an FT ACK TLV with an FT
acknowledgement of all messages from 1 to 12 inclusive (assuming ACK Sequence Number of 12 is treated as the
the LDP session started with a sequence number of 1). acknowledgement of all messages from 1 to
12 inclusive (assuming the LDP session
started with a sequence number of 1).
This field MUST be set to 0 if the LSR sending the FT ACK TLV has This field MUST be set to 0 if the LSR
not received any FT label operations on this LDP session. This sending the FT ACK TLV has not received any
would apply to LDP sessions to new LDP peers or after an LSR FT label operations on this LDP session.
determines that it must drop all state for a failed TCP connection. This would apply to LDP sessions to new LDP
peers or after an LSR determines that it
must drop all state for a failed TCP
connection.
See the section "FT Operation Acks" for details of how this field See the section "FT Operation Acks" for
is used. details of how this field is used.
If an LSR receives a message affecting a label that it believes is an If an LSR receives a message affecting a label that it
FT label and that message does not contain the FT Protection TLV, it believes is an FT label and that message does not contain
SHOULD send a Notification message to its LDP peer containing the the FT Protection TLV, it SHOULD send a Notification
"Missing FT Protection TLV" status code. message to its LDP peer containing the "Missing FT
Protection TLV" status code.
If an LSR receives an FT ACK TLV that contains an FT ACK Sequence If an LSR receives an FT ACK TLV that contains an FT ACK
Number that is less than the previously received FT ACK Sequence Sequence Number that is less than the previously received
Number (remembering to take account of wrapping), it SHOULD send a FT ACK Sequence Number (remembering to take account of
Notification message to its LDP peer containing the "FT ACK wrapping), it SHOULD send a Notification message to its
Sequence Error" status code. LDP peer containing the "FT ACK Sequence Error" status
code.
7. Example Use 7.5. FT Cork TLV
Consider two LDP peers, P1 and P2, implementing LDP over a TCP LDP peers use the FT Cork TLV on FT Keepalive messages to
connection that connects them, and the message flow shown below. indicate that they wish to quiesce the LDP session prior
to a controlled shutdown and restart, for example during
control-plane software upgrade.
The parameters shown on each message shown below are as follows: The FT Cork TLV is encoded as follows.
message (label, senders FT sequence number, FT ACK number) 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|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A "-" for FT ACK number means that the FT ACK TLV is not included On receipt of a Keepalive message with the FT Cork TLV
on that message. "n/a" means that the parameter in question is not and the FT Protection TLV, an LSR SHOULD perform the
applicable to that type of message. following actions
In the diagrams below, time flows from top to bottom. The relative - Process and secure any messages from the peer LSR that
position of each message shows when it is transmitted. See the notes have sequence numbers less than (accounting for wrap) that
for a description of when each message is received, secured for FT or contained in the FT Protection TLV on the Keepalive message.
processed.
7.1 Session Failure and Recovery - Send a Keepalive message back to the peer containing the
FT Cork TLV and the FT ACK TLV specifying the FT ACK
sequence number equal to that in the original Keepalive
message (i.e. ACKing all messages up to that point).
- If this LSR has not yet received an FT ACK to all the
messages it has sent containing the FT Protection TLV, then
also include an FT Protection TLV on the Keepalive sent to
the peer LSR. This tells the remote peer that the local LSR
has saved state prior to quiesce but is still awaiting
confirmation that the remote peer has saved state.
- Cease sending any further state changing messages on this
LDP session until it has been disconnected and recovered.
On receipt of a Keepalive message with the FT Cork TLV
and the FT ACK TLV (but NOT the FT Protection TLV), an
LSR knows that 3-way handshake it initiated is complete
and it 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
is given in section 8.
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
message without one of the FT Protection or FT ACK TLVs
present, , it SHOULD send a Notification message to its
LDP peer containing the "Unexpected FR Cork TLV" status
code.
8. Example Use
Consider two LDP peers, P1 and P2, implementing LDP over
a TCP connection that connects them, and the message flow
shown below.
The parameters shown on each message shown below are as
follows:
message (label, senders FT sequence number, FT ACK
number)
A "-" for FT ACK number means that the FT ACK TLV is
not included on that message. "n/a" means that the
parameter in question is not applicable to that type
of message.
In the diagrams below, time flows from top to bottom.
The relative position of each message shows when it is
transmitted. See the notes for a description of when
each message is received, secured for FT or processed.
8.1. Session Failure and Recovery - FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1,27,-) (1) Label Request(L1,27,-)
---------------------------> --------------------------->
Label Request(L2,28,-) Label Request(L2,28,-)
---------------------------> --------------------------->
(2) Label Request(L3,93,27) (2) Label Request(L3,93,27)
<--------------------------- <---------------------------
(3) Label Request(L1,123,-) (3) Label Request(L1,123,-)
skipping to change at page 24, line 31 skipping to change at page 35, line 31
Label Mapping(L1,94,28) Label Mapping(L1,94,28)
<--------------------------- <---------------------------
(5) Label Mapping(L2,58,-) (5) Label Mapping(L2,58,-)
<-------------------------- <--------------------------
Label Mapping(L2,95,-) Label Mapping(L2,95,-)
<--------------------------- <---------------------------
(6) Address(n/a,29,-) (6) Address(n/a,29,-)
---------------------------> --------------------------->
(7) Label Request(L4,30,-) (7) Label Request(L4,30,-)
---------------------------> --------------------------->
(8) Keepalive(n/a,na/,94) (8) Keepalive(n/a,-,94)
---------------------------> --------------------------->
(9) Label Abort(L3,96,-) (9) Label Abort(L3,96,-)
<--------------------------- <---------------------------
(10) ===== TCP Session lost ===== (10) ===== TCP Session lost =====
: :
(11) : Label Withdraw(L1,59,-) (11) : Label Withdraw(L1,59,-)
: <-------------------------- : <--------------------------
: :
(12) === TCP Session restored === (12) === TCP Session restored ===
skipping to change at page 26, line 5 skipping to change at page 37, line 5
to the failure. to the failure.
(13) From the LDP Init exchange, P1 determines that it needs to (13) From the LDP Init exchange, P1 determines that it needs to
re-issue the Label request for L4. re-issue the Label request for L4.
(14) Similarly, P2 determines that it needs to re-issue the Label (14) Similarly, P2 determines that it needs to re-issue the Label
Mapping for L2 and the Label Abort. Mapping for L2 and the Label Abort.
(15) P2 issues the queued Label Withdraw to P1. (15) P2 issues the queued Label Withdraw to P1.
7.2 Temporary Shutdown 8.2. Use of Check-Pointing With FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,-)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,31,-)
--------------------------->
(9) Keepalive(n/a,-,31)
<---------------------------
(10) Keepalive(n/a,59,124)
<---------------------------
(11) Keepalive(n/a,-,59)
--------------------------->
Notes:
======
Notes (1) through (7) are as in the previous example
except note that no acknowledgements are piggy-backed on
reverse direction messages. This means that at note (8)
there are deferred acknowledgements in both directions on
both links.
(8) P1 wishes to synchronize state with P2. It sends a Keepalive
message containing a FT Protection TLV with sequence number 31.
Since it is not interested in P2's perception of the state that
it has stored, it does not include an FT ACK TLV.
(9) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive. This tells P1 that P2 has
preserved all state/messages previously received on this
session.
(10) P3 wishes to synchronize state with P2. It sends a Keepalive
message containing a FT Protection TLV with sequence number 59.
P3 also takes this opportunity to get up to date with its
acknowledgements to P2 by including an FT ACK TLV acknowledging
up to sequence number 124.
(11) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive.
8.3. Temporary Shutdown With FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1,27,-) (1) Label Request(L1,27,-)
---------------------------> --------------------------->
Label Request(L2,28,-) Label Request(L2,28,-)
---------------------------> --------------------------->
(2) Label Request(L3,93,27) (2) Label Request(L3,93,27)
<--------------------------- <---------------------------
(3) Label Request(L1,123,-) (3) Label Request(L1,123,-)
skipping to change at page 26, line 31 skipping to change at page 39, line 31
Label Mapping(L1,94,28) Label Mapping(L1,94,28)
<--------------------------- <---------------------------
(5) Label Mapping(L2,58,-) (5) Label Mapping(L2,58,-)
<-------------------------- <--------------------------
Label Mapping(L2,95,-) Label Mapping(L2,95,-)
<--------------------------- <---------------------------
(6) Address(n/a,29,-) (6) Address(n/a,29,-)
---------------------------> --------------------------->
(7) Label Request(L4,30,-) (7) Label Request(L4,30,-)
---------------------------> --------------------------->
(8) Keepalive(n/a,na/,94) (8) Keepalive(n/a,-,94)
---------------------------> --------------------------->
(9) Label Abort(L3,96,-) (9) Label Abort(L3,96,-)
<--------------------------- <---------------------------
(10) Notification(Temporary shutdown) (10) Notification(Temporary shutdown)
---------------------------> --------------------------->
===== TCP Session shutdown =====
: :
(11) : Label Withdraw(L1,59,-) (11) : Label Withdraw(L1,59,-)
: <-------------------------- : <--------------------------
: :
===== TCP Session restored =====
(12) LDP Init(n/a,n/a,94) (12) LDP Init(n/a,n/a,94)
---------------------------> --------------------------->
LDP Init(n/a,n/a,29) LDP Init(n/a,n/a,29)
<--------------------------- <---------------------------
(13) Label Request(L4,30,-) (13) Label Request(L4,30,-)
---------------------------> --------------------------->
(14) Label Mapping(L2,95,-) (14) Label Mapping(L2,95,-)
<--------------------------- <---------------------------
Label Abort(L3,96,30) Label Abort(L3,96,30)
<--------------------------- <---------------------------
skipping to change at page 27, line 18 skipping to change at page 41, line 5
(10) P1 needs to upgrade the software or hardware that it is running. (10) P1 needs to upgrade the software or hardware that it is running.
It issues a Notification message to terminate the LDP session, It issues a Notification message to terminate the LDP session,
but sets the status code as 'Temporary shutdown' to inform P2 but sets the status code as 'Temporary shutdown' to inform P2
that this is not a fatal error, and P2 should maintain FT state. that this is not a fatal error, and P2 should maintain FT state.
The TCP connection may also fail during the period that the LDP The TCP connection may also fail during the period that the LDP
session is down (in which case it will need to be session is down (in which case it will need to be
re-established), but it is also possible that the TCP connection re-established), but it is also possible that the TCP connection
will be preserved. will be preserved.
8. Security Considerations 8.4. Temporary Shutdown With FT Procedures and Check-Pointing
The LDP FT enhancements inherit similar security considerations to notes P1 P2
those discussed in [2] and [4]. ===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
Label Mapping(L1,57,-)
<--------------------------
(3) Label Mapping(L1,94,-)
<---------------------------
Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(4) Address(n/a,29,-)
--------------------------->
(5) Label Request(L4,30,-)
--------------------------->
(6) Keepalive(n/a,31,95) * with FT Cork TLV *
--------------------------->
(7) Label Abort(L3,96,-)
<---------------------------
(8) Keepalive(n/a,97,31) * with FT Cork TLV *
<---------------------------
(9) Keepalive(n/a,-,97) * with FT Cork TLV *
--------------------------->
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
: Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96)
--------------------------->
LDP Init(n/a,n/a,31)
<---------------------------
Label Withdraw(L1,97,-)
<---------------------------
Notes:
The LDP FT enhancements allow the re-establishment of a TCP This example operates much as the previous one. However,
connection between LDP peers without a full re-exchange of the at (1), (2), (3), (4) and (5) no acknowledgements are
attributes of established labels, which renders LSRs that implement made.
the extensions specified in this draft vulnerable to additional
denial-of-service attacks as follows:
- An intruder may impersonate an LDP peer in order to force a At (6), P1 determines that graceful shutdown is required
failure and reconnection of the TCP connection, but where the and sends a Keepalive acknowledging all previously
intruder does not set the FT Reconnect Flag on re-connection. received messages and itself containing a FT Protection
This forces all FT labels to be released. TLV number and the FT Cork TLV.
The Label abort at (7) crosses with this Keepalive, so at
(8) P2 sends a Keepalive that acknowledges all messages
received so far, but also including the FT Protection and
FT Cork TLVs to indicate that there are still messages
outstanding to be acknowledged.
P1 is then able to complete the 3-way handshake at (9)
and close the TCP session at (10).
Upon recovery at (11) there are no messages to be re-sent
because the Keepalives flushed the acknowledgements. The
only messages sent after recovery is the Label Withdraw
that was pended during the TCP session failure.
8.5. Checkpointing Without FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,-)
--------------------------->
(5) Label Request(L3)
--------------------------->
(6) Keepalive(n/a,-,12)
<---------------------------
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(7) Label Mapping(L3)
<---------------------------
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(8) LDP Init(n/a,n/a,23)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(9) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
Label Mapping(L3)
<---------------------------
(10) Label Request(L2)
<---------------------------
Notes:
(1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of
the checkpoint request.
(5) P1 immediately starts a new label distribution request.
(6) P2 confirms that it has secured all previous transactions.
(7) The subsequent (un-acknowledged) label distribution completes.
(8) The session fails and is restarted. Initialization messages
confirm the sequence numbers of the secured checkpoints.
(9) P1 recommences the unacknowledged label distribution request.
(10) P2 recommences an unacknowledged label distribution request.
8.6. Graceful Shutdown With Checkpointing But No FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,23) * With FT Cork TLV *
--------------------------->
(5) :
:
:
(6) Keepalive(n/a,24,12) * With FT Cork TLV *
<---------------------------
(7) Keepalive(n/a,-,24) * With FT Cork TLV *
--------------------------->
(8) Notification(Temporary shutdown)
--------------------------->
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(10) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
Label Mapping(L3)
<---------------------------
(11) Label Mapping(L2)
--------------------------->
Notes:
(1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of
the checkpoint request and a Cork TLV.
(5) P1 has sent a Cork TLV so quieces.
(6) P2 confirms the checkpoint and continues the three-way handshake
by including a Cork TLV itself.
(7) P1 completes the three-way handshake. All operations have now
been checkpointed and the session is quiesced.
(8) The session is gracefully shut down.
(9) The session recovers and the peers exchange the sequence numbers
of the last secured checkpoints.
(10) P1 starts a new label distribution request.
(11) P1 continues processing a previously received label distribution
request.
9. Security Considerations
The LDP FT enhancements inherit similar security
considerations to those discussed in [2] and [4].
The LDP FT enhancements allow the re-establishment of a
TCP connection between LDP peers without a full re-
exchange of the attributes of established labels, which
renders LSRs that implement the extensions specified in
this draft vulnerable to additional denial-of-service
attacks as follows:
- An intruder may impersonate an LDP peer in order to force
a failure and reconnection of the TCP connection, but where
the intruder does not set the FT Reconnect Flag on re-
connection. This forces all FT labels to be released.
- 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 state re-establishment of the TCP session without preserving the
and resources for FT labels. state and resources for FT labels.
- An intruder could intercept the traffic between LDP peers and - An intruder could intercept the traffic between LDP peers
override the setting of the FT Label Flag to be set to 0 for and override the setting of the FT Label Flag to be set to 0
all labels. for all labels.
All of these attacks may be countered by use of an authentication All of these attacks may be countered by use of an
scheme between LDP peers, such as the MD5-based scheme outlined in authentication scheme between LDP peers, such as the MD5-
[4]. based scheme outlined in [4].
Alternative authentication schemes for LDP peers are outside the Alternative authentication schemes for LDP peers are
scope of this draft, but could be deployed to provide enhanced outside the scope of this draft, but could be deployed to
security to implementations of LDP, CR-LDP and the LDP FT provide enhanced security to implementations of LDP, CR-
enhancements. LDP and the LDP FT enhancements.
As with LDP and CR-LDP, a security issue may exist if an LDP As with LDP and CR-LDP, a security issue may exist if an
implementation continues to use labels after expiration of the LDP implementation continues to use labels after
session that first caused them to be used. This may arise if the expiration of the session that first caused them to be
upstream LSR detects the session failure after the downstream LSR used. This may arise if the upstream LSR detects the
has released and re-used the label. The problem is most obvious session failure after the downstream LSR has released and
with the platform-wide label space and could result in mis-routing re-used the label. The problem is most obvious with the
of data to other than intended destinations and it is conceivable platform-wide label space and could result in mis-routing
that these behaviors may be deliberately exploited to either obtain of data to other than intended destinations and it is
services without authorization or to deny services to others. conceivable that these behaviors may be deliberately
exploited to either obtain services without authorization
or to deny services to others.
In this draft, the validity of the session may be extended by the FT In this draft, the validity of the session may be
Reconnection Timeout, and the session may be re-established in this extended by the FT Reconnection Timeout, and the session
period. After the expiry of the Reconnection Timeout the session may be re-established in this period. After the expiry
must be considered to have failed and the same security issue applies of the Reconnection Timeout the session must be
as described above. considered to have failed and the same security issue
applies as described above.
However, the downstream LSR may declare the session as failed before However, the downstream LSR may declare the session as
the expiration of its Reconnection Timeout. This increases the failed before the expiration of its Reconnection Timeout.
period during which the downstream LSR might reallocate the label This increases the period during which the downstream LSR
while the upstream LSR continues to transmit data using the old usage might reallocate the label while the upstream LSR
of the label. To reduce this issue, this draft requires that labels continues to transmit data using the old usage of the
are not re-used until the Reconnection Timeout has expired. label. To reduce this issue, this draft requires that
labels are not re-used until the Reconnection Timeout has
expired.
A further issue might apply if labels were re-used prior to the A further issue might apply if labels were re-used prior
expiration of the FT Reconnection Timeout, but this is forbidden by to the expiration of the FT Reconnection Timeout, but
this draft. this is forbidden by this draft.
9. Implementation Notes 10. Implementation Notes
9.1 FT Recovery Support on Non-FT LSRs 10.1. FT Recovery Support on Non-FT LSRs
In order to take full advantage of the FT capabilities of LSRs in the In order to take full advantage of the FT capabilities of
network, it may be that an LSR that does not itself contain the LSRs in the network, it may be that an LSR that does not
ability to recover from local hardware or software faults still needs itself contain the ability to recover from local hardware
to support the LDP FT enhancements described in this draft. or software faults still needs to support the LDP FT
enhancements described in this draft.
Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant Consider an LSR, P1, that is an LDP peer of a fully Fault
LSR, P2. If P2 experiences a fault in the hardware or software that Tolerant LSR, P2. If P2 experiences a fault in the
serves an LDP session between P1 and P2, it may fail the TCP hardware or software that serves an LDP session between
connection between the peers. When the connection is recovered, the P1 and P2, it may fail the TCP connection between the
LSPs/labels between P1 and P2 can only be recovered if both LSRs were peers. When the connection is recovered, the LSPs/labels
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.
9.2 ACK generation logic 10.2. ACK Generation Logic
FT ACKs SHOULD be returned to the sending LSR as soon as is FT ACKs SHOULD be returned to the sending LSR as soon as
practicable in order to avoid building up a large quantity of is practicable in order to avoid building up a large
unacknowledged state changes at the LSR. However, immediate quantity of unacknowledged state changes at the LSR.
one-for-one acknowledgements would waste bandwidth unnecessarily. However, immediate one-for-one acknowledgements would
waste bandwidth unnecessarily.
A possible implementation strategy for sending ACKs to FT LDP A possible implementation strategy for sending ACKs to FT
messages is as follows: LDP messages is as follows:
- An LSR secures received messages in order and tracks the sequence
number of the most recently secured message, Sr.
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK
TLV listing Sr
- Optionally, the LSR may attach an FT ACK TLV to any other LDP
message sent between Keepalive messages if, for example, Sr has
increased by more than a threshold value since the last ACK sent.
This implementation combines the bandwidth benefits of accumulating - An LSR secures received messages in order and tracks the
ACKs while still providing timely ACKs. sequence number of the most recently secured message, Sr.
10. Acknowledgments - On each LDP KeepAlive that the LSR sends, it attaches an
FT ACK TLV listing Sr
The work in this draft is based on the LDP and CR-LDP ideas - Optionally, the LSR may attach an FT ACK TLV to any other
expressed by the authors of [2] and [4]. LDP message sent between Keepalive messages if, for example,
Sr has increased by more than a threshold value since the
last ACK sent.
The ACK scheme used in this draft was inspired by the proposal by This implementation combines the bandwidth benefits of
David Ward and John Scudder for restarting BGP sessions now included accumulating ACKs while still providing timely ACKs.
in [9].
The authors would also like to acknowledge the careful review and 10.2.1 Ack Generation Logic When Using Check-Pointing
comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and
Alan Davey.
11. Intellectual Property Consideration If check-pointing is in use, the LSRs need not be
concerned to send ACKs in such a timely manner.
The IETF has been notified of intellectual property rights claimed in Check-points are solicitations for acknowledgement
regard to some or all of the specification contained in this conveyed as a sequence number in an FT Protection TLV on
document. For more information, consult the online list of claimed a Keepalive message. Such check-point requests could be
rights. issued on a timer, after a significant amount of change,
or before controlled shutdown of a session.
12. Full Copyright Statement The use of check-pointing may considerably simplify an
implementation since it does not need to track the
sequence numbers of all received LDP messages. It must,
however, still ensure that all received messages (or the
consequent state changes) are secured before
acknowledging the sequence number on the Keepalive.
Copyright (c) The Internet Society (2000, 2001). All Rights Reserved. This approach may be considered optimal in systems that
This document and translations of it may be copied and furnished to do not show a high degree of change over time (such as
others, and derivative works that comment on or otherwise explain it targeted LDP session or CR-LDP systems) and that are
or assist in its implementation may be prepared, copied, published prepared to risk loss of state for the most recent LDP
and distributed, in whole or in part, without restriction of any exchanges. More dynamic systems (such as LDP discovery
kind, provided that the above copyright notice and this paragraph sessions) are more likely to want to acknowledge state
are included on all such copies and derivative works. However, this changes more frequently so that the maximum amount of
document itself may not be modified in any way, such as by removing state can be preserved over a failure.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be 11. Acknowledgments
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an The work in this draft is based on the LDP and CR-LDP
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ideas expressed by the authors of [2] and [4].
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION The ACK scheme used in this draft was inspired by the
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF proposal by David Ward and John Scudder for restarting
BGP sessions now included in [9].
The authors would also like to acknowledge the careful
review and comments of Nick Weeds, Piers Finlayson, Tim
Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas,
S.Manikantan, Adam Sheppard and Alan Davey.
12. Intellectual Property Consideration
The IETF has been notified of intellectual property
rights claimed in regard to some or all of the
specification contained in this document. For more
information, consult the online list of claimed rights.
13. Full Copyright Statement
Copyright (c) The Internet Society (2000, 2001). All
Rights Reserved. This document and translations of it may
be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose
of developing Internet standards in which case the
procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. IANA Considerations 14. IANA Considerations
This draft requires the use of a number of new TLVs and status codes This draft requires the use of a number of new TLVs and
from the number spaces within the LDP protocol. This section status codes from the number spaces within the LDP
explains the logic used by the authors to choose the most appropriate protocol. This section explains the logic used by the
number space for each new entity, and is intended to assist in the authors to choose the most appropriate number space for
determination of any final values assigned by IANA or the MPLS WG in each new entity, and is intended to assist in the
the event that the MPLS WG chooses to advance this draft on the determination of any final values assigned by IANA or the
standards track. MPLS WG in the event that the MPLS WG chooses to advance
this draft on the standards track.
This section will be removed when the TLV and status code values have This section will be removed when the TLV and status code
been agreed with IANA. values have been agreed with IANA.
13.1 FT Session TLV 14.1. FT Session TLV
The FT Session TLV carries attributes that affect the entire LDP The FT Session TLV carries attributes that affect the
session between LDP peers. It is suggested that the type for this entire LDP session between LDP peers. It is suggested
TLV should be chosen from the 0x05xx range for TLVs that is used in that the type for this TLV should be chosen from the
[4] by other TLVs carrying session-wide attributes. At the time of 0x05xx range for TLVs that is used in [4] by other TLVs
this writing, the next available number in this range is 0x0503. carrying session-wide attributes. At the time of this
writing, the next available number in this range is
0x0503.
13.2 FT Protection TLV 14.2. FT Protection TLV
The FT Protection TLV carries attributes that affect a single label The FT Protection TLV carries attributes that affect a
exchanged between LDP peers. It is suggested that the type for this single label exchanged between LDP peers. It is
TLV should be chosen from the 0x02xx range for TLVs that is used in suggested that the type for this TLV should be chosen
[4] by other TLVs carrying label attributes. At the time of this from the 0x02xx range for TLVs that is used in [4] by
writing, the next available number in this range is 0x0203. 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 instead of Consideration was given to using the message number field
a new FT Sequence Number field. However, the authors felt this instead of a new FT Sequence Number field. However, the
placed unacceptable implementation constraints on the use of message authors felt this placed unacceptable implementation
number (e.g. it could no longer be used to reference a control constraints on the use of message number (e.g. it could
block). no longer be used to reference a control block).
13.3 FT ACK TLV 14.3. FT ACK TLV
The FT Protection TLV may ACK many label operations at once The FT Protection TLV may ACK many label operations at
if cumulative ACKS are used. It is suggested that the type for this once if cumulative ACKS are used. It is suggested that
TLV should be chosen from the 0x05xx range for TLVs that is used in the type for this TLV should be chosen from the 0x05xx
[4] by other TLVs carrying session-wide attributes. At the time of range for TLVs that is used in [4] by other TLVs carrying
this writing, the next available number in this range is 0x0504. 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 the FT Consideration was given to carrying the FT ACK Number in
Protection TLV, but the authors felt this would be inappropriate as the FT Protection TLV, but the authors felt this would be
many implementations may wish to carry the ACKs on Keepalive inappropriate as many implementations may wish to carry
messages. the ACKs on Keepalive messages.
13.4 Status Codes 14.4. FT Cork TLV
The authors' current understanding is that MPLS status codes are not The FT Cork TLV carries attributes that affect a single
sub-divided into specific ranges for different types of error. label exchanged between LDP peers. It is suggested that
Hence, the numeric status code values assigned for this draft should the type for this TLV should be chosen from the 0x05xx
simply be the next available values at the time of writing and may be 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
The authors' current understanding is that MPLS status
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. substituted for other numeric values.
See section "Status Codes" for details of the status codes defined in See section "Status Codes" for details of the status
this draft. codes defined in this draft.
14. 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
Voice: +1 703-847-1719 CH1 1DF, UK Phone: +1 703-847-1867 CH1 1DF, UK
Email: afarrel@movaz.com Phone: +44-(0)-1244-313440 Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177
Fax: +44-(0)-1244-312422
Email: pjb@dataconnection.com Email: pjb@dataconnection.com
Philip Matthews Eric Gray Philip Matthews Eric Gray
Nortel Networks Corp. Sandburst Corporation Hyperchip Sandburst Corporation
P.O. Box 3511 Station C, 600 Federal Street 1800 Rene-Levesque Blvd W 600 Federal Street
Ottawa, ON K1Y 4H7 Andover, MA 01810 Montreal, Quebec H3H 2H2 Andover, MA 01810
Canada Phone: +1 978-689-1600 Canada Phone: +1 978-689-1600
Phone: +1 613-768-3262 eric.gray@sandburst.com Phone: +1 514-906-4965 Email:eric.gray@sandburst.com
philipma@nortelnetworks.com Email: pmatthews@hyperchip.com
Jack Shaio Toby Smith
Vivace Networks Laurel Networks, Inc.
2730 Orchard Parkway 1300 Omega Drive
San Jose, CA 95134 Pittsburgh, PA 15205
Phone: +1 408 432 7623 Email: tob@laurelnetworks.com
Email: jack.shaio@vivacenetworks.com
15. References Andy Malis
Vivace Networks
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
andy.malis@vivacenetworks.com
16. Normative References
4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
17. Informative References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
draft-ietf-mpls-cr-ldp-05.txt, February 2001, (work in progress). draft-ietf-mpls-cr-ldp-06.txt, November 2001, (work in progress).
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls- 5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-
crlsp-modify-03.txt, March 2001 (work in progress). crlsp-modify-03.txt, March 2001 (work in progress).
6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- 6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification, RFC 2205, September 1997. Version 1, Functional Specification, RFC 2205, September 1997.
7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft- 7 Berger, L., et al., RSVP Refresh Reduction Extensions, RFC 2961
ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress). April 2001.
8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft- 8 Awduche, D., et al,. Extensions to RSVP for LSP Tunnels, RFC 3209,
ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2000 (work in December 2001.
progress).
9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP, 9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP,
draft-ietf-idr-restart-00.txt, December 2000 (work in progress) draft-ietf-idr-restart-00.txt, December 2000 (work in progress).
10 Stewart, R., et al., Stream Control Transmission Protocol, 10 Stewart, R., et al., Stream Control Transmission Protocol,
RFC 2906, October 2000. RFC 2906, October 2000.
11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart- 11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart-
00.txt, February 2001 (work in progress) 00.txt, February 2001 (work in progress).
12 Leelanivas, M., et al., Graceful Restart Mechanism for LDP, draft-
ietf-ldp-restart-00.txt, January 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/