draft-ietf-mpls-ldp-ft-06.txt   rfc3479.txt 
MPLS Working Group Editor
Internet Draft Adrian Farrel
Document: draft-ietf-mpls-ldp-ft-06.txt Movaz Networks, Inc.
Expiration Date: March 2003 September 2002
Fault Tolerance for the Label Distribution Protocol (LDP) Network Working Group A. Farrel, Ed.
Request for Comments: 3479 Movaz Networks, Inc.
Category: Standards Track February 2003
draft-ietf-mpls-ldp-ft-06.txt Fault Tolerance for the Label Distribution Protocol (LDP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document specifies an Internet standards track protocol for the
conformance with all provisions of Section 10 of RFC2026 Internet community, and requests discussion and suggestions for
[RFC2026]. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Copyright Notice
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are
draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be IESG Note
accessed at http://www.ietf.org/shadow.html.
NOTE: The new TLV type numbers, bit values for flags This specification includes procedures for failure detection and
specified in this draft, and new LDP status code values failover for a TCP connection carrying MPLS LDP control traffic, so
are preliminary suggested values and have yet to be that it can be switched to a new TCP connection. It does not provide
approved by IANA or the MPLS WG. See the section "IANA a general approach to using multiple TCP connections to provide this
Considerations" for further details. kind of fault tolerance. The specification lacks adequate guidance
for the timer and retry value choices related to the TCP connection
fault tolerance procedures. The specification should not serve as a
model for TCP connection fault tolerance design for any future
document, and users are advised to test configurations based on this
specification very carefully for problems such as premature
failovers.
Abstract Abstract
Multiprotocol Label Switching (MPLS) systems will be used Multiprotocol Label Switching (MPLS) systems will be used in core
in core networks where system downtime must be kept to an networks where system downtime must be kept to an absolute minimum.
absolute minimum. Many MPLS Label Switching Routers Many MPLS Label Switching Routers (LSRs) may, therefore, exploit
(LSRs) may, therefore, exploit Fault Tolerant (FT) Fault Tolerant (FT) hardware or software to provide high availability
hardware or software to provide high availability of the of the core networks.
core networks.
The details of how FT is achieved for the various
components of an FT LSR, including Label Distribution
Protocol (LDP), the switching hardware and TCP, are
implementation specific. This document identifies issues
in the LDP specification in RFC 3036 "LDP Specification"
that make it difficult to implement an FT LSR using the
current LDP protocols, and proposes enhancements to the
LDP specification to ease such FT LSR implementations.
The issues and extensions described here are equally The details of how FT is achieved for the various components of an FT
applicable to RFC 3212, "Constraint-Based LSP Setup Using LSR, including Label Distribution Protocol (LDP), the switching
LDP" (CR-LDP). hardware and TCP, are implementation specific. This document
identifies issues in the LDP specification in RFC 3036, "LDP
Specification", that make it difficult to implement an FT LSR using
the current LDP protocols, and defines enhancements to the LDP
specification to ease such FT LSR implementations.
Contents The issues and extensions described here are equally applicable to
RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
1. Conventions and Terminology used in this document 3 Table of Contents
2. Contributing Authors 4
3. Introduction 4
3.1. Fault Tolerance for MPLS 4
3.2. Issues with LDP 5
4. Overview of LDP FT Enhancements 7
4.1. Establishing an FT LDP Session 8
4.1.1 Interoperation with Non-FT LSRs 8
4.2. TCP Connection Failure 9
4.2.1 Detecting TCP Connection Failures 9
4.2.2 LDP Processing after Connection Failure 9
4.3. Data Forwarding During TCP Connection Failure 10
4.4. FT LDP Session Reconnection 10
4.5. Operations on FT Labels 11
4.6. Check-Pointing 11
4.6.1 Graceful Termination 12
4.7. Label Space Depletion and Replenishment 13
4.8. Tunneled LSPs 13
5. FT Operations 14
5.1. FT LDP Messages 14
5.1.1 Sequence Numbered FT Label Messages 14
5.1.2 FT Address Messages 15
5.1.3 Label Resources Available Notifications 15
5.2. FT Operation ACKs 17
5.3. Preservation of FT State 17
5.4. FT Procedure After TCP Failure 19
5.4.1 FT LDP Operations During TCP Failure 20
5.5. FT Procedure After TCP Re-connection 21
5.5.1 Re-Issuing FT Messages 22
6. Checkpointing Procedures 22
6.1 Checkpointing with the Keepalive Message 23
6.1 Quiesce and Keepalive 23
7. Changes to Existing Messages 24
7.1. LDP Initialization Message 24
7.2. LDP Keepalive Messages 24
7.3. All Other LDP Session Messages 25
8. New Fields and Values 25
8.1. Status Codes 25
8.2. FT Session TLV 26
8.3. FT Protection TLV 29
8.4. FT ACK TLV 31
8.5. FT Cork TLV 33
9. Example Use 34
9.1. Session Failure and Recovery - FT Procedures 35
9.2. Use of Check-Pointing With FT Procedures 37
9.3. Temporary Shutdown With FT Procedures 39
9.4. Temporary Shutdown With FT Procedures and Check-Pointing 41
9.5. Checkpointing Without FT Procedures 43
9.6. Graceful Shutdown With Checkpointing But No FT Procedures 45
10. Security Considerations 46
11. Implementation Notes 48
11.1. FT Recovery Support on Non-FT LSRs 48
11.2. ACK generation logic 48
11.2.1 Ack Generation Logic When Using Check-Pointing 48
11.3 Interactions With Other Label Distribution Mechanisms 49
12. Acknowledgments 49 1. Conventions and Terminology used in this document..........3
13. Intellectual Property Consideration 50 2. Contributing Authors.......................................4
14. Full Copyright Statement 50 3. Introduction...............................................4
15. IANA Considerations 50 3.1. Fault Tolerance for MPLS..............................4
15.1. New TLVs 51 3.2. Issues with LDP.......................................5
15.2. New Status Codes 51 4. Overview of LDP FT Enhancements............................7
16. Authors' Addresses 52 4.1. Establishing an FT LDP Session........................8
17. References 52 4.1.1 Interoperation with Non-FT LSRs.................8
17.1. Normative References 52 4.2. TCP Connection Failure................................9
17.2. Informative References 53 4.2.1 Detecting TCP Connection Failures...............9
4.2.2 LDP Processing after Connection Failure.........9
4.3. Data Forwarding During TCP Connection Failure........10
4.4. FT LDP Session Reconnection..........................10
4.5. Operations on FT Labels..............................11
4.6. Check-Pointing.......................................11
4.6.1 Graceful Termination...........................12
4.7. Label Space Depletion and Replenishment..............13
4.8. Tunneled LSPs........................................13
5. FT Operations.............................................14
5.1. FT LDP Messages......................................14
5.1.1 Sequence Numbered FT Label Messages............14
5.1.2 FT Address Messages............................15
5.1.3 Label Resources Available Notifications........15
5.2. FT Operation ACKs....................................17
5.3. Preservation of FT State.............................17
5.4. FT Procedure After TCP Failure.......................19
5.4.1 FT LDP Operations During TCP Failure...........20
5.5. FT Procedure After TCP Re-connection.................21
5.5.1 Re-Issuing FT Messages.........................22
6. Check-Pointing Procedures.................................22
6.1 Check-Pointing with the Keepalive Message.............23
6.2 Quiesce and Keepalive.................................23
7. Changes to Existing Messages..............................24
7.1. LDP Initialization Message...........................24
7.2. LDP Keepalive Messages...............................25
7.3. All Other LDP Session Messages.......................25
8. New Fields and Values.....................................26
8.1. Status Codes.........................................26
8.2. FT Session TLV.......................................27
8.3. FT Protection TLV....................................29
8.4. FT ACK TLV...........................................32
8.5. FT Cork TLV..........................................33
9. Example Use...............................................34
9.1. Session Failure and Recovery - FT Procedures.........34
9.2. Use of Check-Pointing With FT Procedures.............37
9.3. Temporary Shutdown With FT Procedures................38
9.4. Temporary Shutdown With FT Procedures
and Check-Pointing...................................40
9.5. Check-Pointing Without FT Procedures.................42
9.6. Graceful Shutdown With Check-Pointing
But No FT Procedures.................................44
10. Security Considerations..................................45
11. Implementation Notes.....................................47
11.1. FT Recovery Support on Non-FT LSRs..................47
11.2. ACK generation logic................................47
11.2.1 Ack Generation Logic When Using
Check-Pointing...............................47
11.3 Interactions With Other Label Distribution
Mechanisms...........................................48
12. Acknowledgments..........................................48
13. Intellectual Property Consideration......................49
14. References...............................................49
14.1. Normative References................................49
14.2. Informative References..............................50
15. Authors' Addresses.......................................50
16. Full Copyright Statement.................................52
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
Definitions of key words and terms applicable to LDP and Definitions of key words and terms applicable to LDP and CR-LDP are
CR-LDP are inherited from [RFC3212] and [RFC3036]. inherited from [RFC3212] and [RFC3036].
The term "FT Label" is introduced in this document to The term "FT Label" is introduced in this document to indicate a
indicated a label for which some fault tolerant operation label for which some fault tolerant operation is used. A "non-FT
is used. A "non-FT Label" is not fault tolerant and is Label" is not fault tolerant and is handled as specified in
handled as specified in [RFC3036]. [RFC3036].
The term "Sequence Numbered FT Label" is used to indicate The term "Sequence Numbered FT Label" is used to indicate an FT label
an FT label which is secured using the sequence number in which is secured using the sequence number in the FT Protection TLV
the FT Protection TLV described in this document. described in this document.
The term "Checkpointable FT Label" is used to indicate an The term "Check-Pointable FT Label" is used to indicate an FT label
FT label which is secured by using the checkpointing which is secured by using the check-pointing techniques described in
techniques described in this document. this document.
The extensions to LDP specified in this document are The extensions to LDP specified in this document are collectively
collectively referred to as the "LDP FT enhancements". referred to as the "LDP FT enhancements".
Within the context of this draft, "Checkpointing" refers Within the context of this document, "Check-Pointing" refers to a
to a process of messages exchanges that confirm receipt process of message exchanges that confirm receipt and processing (or
and processing (or secure storage) of specific protocol secure storage) of specific protocol messages.
messages.
When talking about the individual bits in the 16-bit FT When talking about the individual bits in the 16-bit FT Flag Field,
Flag Field, the words "bit" and "flag" is used the words "bit" and "flag" are used interchangeably.
interchangeably.
In the examples quoted, the following notation is used: In the examples quoted, the following notation is used: Ln : An LSP.
Ln : An LSP. For example L1. For example L1. Pn : An LDP peer. For example P1.
Pn : An LDP peer. For example P1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"MAY", and "OPTIONAL" in this document are to be document are to be interpreted as described in BCP 14, RFC 2119
interpreted as described in RFC-2119 [RFC2119]. [RFC2119].
2. Contributing Authors 2. Contributing Authors
This document was the collective work of several This document was the collective work of several individuals over a
individuals over a period of several years. The text and period of several years. The text and content of this document was
content of this document was contributed by the editor contributed by the editor and the co-authors listed in section 15,
and the co-authors listed in section 16. "Authors' Addresses".
3. Introduction 3. Introduction
High Availability (HA) is typically claimed by equipment High Availability (HA) is typically claimed by equipment vendors when
vendors when their hardware achieves availability levels their hardware achieves availability levels of at least 99.999% (five
of at least 99.999% (five 9s). To implement this, the 9s). To implement this, the equipment must be capable of recovering
equipment must be capable of recovering from local from local hardware and software failures through a process known as
hardware and software failures through a process known as
fault tolerance (FT). fault tolerance (FT).
The usual approach to FT involves provisioning backup The usual approach to FT involves provisioning backup copies of
copies of hardware and/or software. When a primary copy hardware and/or software. When a primary copy fails, processing is
fails, processing is switched to the backup copy. This switched to the backup copy. This process, called failover, should
process, called failover, should result in minimal result in minimal disruption to the Data Plane.
disruption to the Data Plane.
In an FT system, backup resources are sometimes In an FT system, backup resources are sometimes provisioned on a
provisioned on a one-to-one basis (1:1), sometimes as one- one-to-one basis (1:1), sometimes as one-to-many (1:n), and
to-many (1:n), and occasionally as many-to-many (m:n). occasionally as many-to-many (m:n). Whatever backup provisioning is
Whatever backup provisioning is made, the system must made, the system must switch to the backup automatically on failure
switch to the backup automatically on failure of the of the primary, and the software and hardware state in the backup
primary, and the software and hardware state in the must be set to replicate the state in the primary at the point of
backup must be set to replicate the state in the primary failure.
at the point of failure.
3.1. Fault Tolerance for MPLS 3.1. Fault Tolerance for MPLS
MPLS is a technology that will be used in core networks MPLS is a technology that will be used in core networks where system
where system downtime must be kept to an absolute downtime must be kept to an absolute minimum. Many MPLS LSRs may,
minimum. Many MPLS LSRs may, therefore, exploit FT therefore, exploit FT hardware or software to provide high
hardware or software to provide high availability of core availability of core networks.
networks.
In order to provide HA, an MPLS system needs to be able In order to provide HA, an MPLS system needs to be able to survive a
to survive a variety of faults with minimal disruption to variety of faults with minimal disruption to the Data Plane,
the Data Plane, including the following fault types: 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 an LSR - failure/hot-swap of the switching fabric in an 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 in an LSR. - software upgrade to the TCP or LDP stacks in an LSR.
The first two examples of faults listed above are The first two examples of faults listed above are confined to the
confined to the Data Plane. Such faults can be handled Data Plane. Such faults can be handled by providing redundancy in
by providing redundancy in the Data Plane which is the Data Plane which is transparent to LDP operating in the Control
transparent to LDP operating in the Control Plane. The Plane. The last two example types of fault require action in the
last two example types of fault require action in the Control Plane to recover from the fault without disrupting traffic in
Control Plane to recover from the fault without the Data Plane. This is possible because many recent router
disrupting traffic in the Data Plane. This is possible architectures separate the Control and Data Planes such that
because many recent router architectures separate the forwarding can continue unaffected by recovery action in the Control
Control and Data Planes such that forwarding can continue Plane.
unaffected by recovery action in the Control Plane.
3.2. Issues with LDP 3.2. Issues with LDP
LDP uses TCP to provide reliable connections between LSRs LDP uses TCP to provide reliable connections between LSRs over which
over which to exchange protocol messages to distribute they exchange protocol messages to distribute labels and set up LSPs.
labels and to set up LSPs. A pair of LSRs that have such A pair of LSRs that have such a connection are referred to as LDP
a connection are referred to as LDP peers. peers.
TCP enables LDP to assume reliable transfer of protocol TCP enables LDP to assume reliable transfer of protocol messages.
messages. This means that some of the messages do not This means that some of the messages do not need to be acknowledged
need to be acknowledged (for example, Label Release). (for example, Label Release).
LDP is defined such that if the TCP connection fails, the LDP is defined such that if the TCP connection fails, the LSR should
LSR should immediately tear down the LSPs associated with immediately tear down the LSPs associated with the session between
the session between the LDP peers, and release any labels the LDP peers, and release any labels and resources assigned to those
and resources assigned to those LSPs. LSPs.
It is notoriously hard to provide a Fault Tolerant It is notoriously hard to provide a Fault Tolerant implementation of
implementation of TCP. To do so might involve making TCP. To do so might involve making copies of all data sent and
copies of all data sent and received. This is an issue received. This is an issue familiar to implementers of other TCP
familiar to implementers of other TCP applications such applications such as BGP.
as BGP.
During failover affecting the TCP or LDP stacks, During failover affecting the TCP or LDP stacks, the TCP connection
therefore, the TCP connection may be lost. Recovery from may be lost. Recovery from this position is made worse by the fact
this position is made worse by the fact that LDP control that LDP control messages may have been lost during the connection
messages may have been lost during the connection failure. Since these messages are unconfirmed, it is possible that
failure. Since these messages are unconfirmed, it is LSP or label state information will be lost.
possible that LSP or label state information will be
lost.
This draft describes a solution which involves This document describes a solution which involves:
- negotiation between LDP peers of the intent to support - negotiation between LDP peers of the intent to support extensions
extensions to LDP that facilitate recovery from failover to LDP that facilitate recovery from failover without loss of
without loss of LSPs 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 - acknowledgement of LDP messages to ensure that a full handshake is
handshake is performed on those messages either frequently performed on those messages either frequently (such as per
(such as per message) or less frequently as in check- message) or less frequently as in check-pointing.
pointing
- solicitation of up-to-date acknowledgement - solicitation of up-to-date acknowledgement (check-pointing) of
(checkpointing) of previous LDP messages to ensure the previous LDP messages to ensure the current state is flushed to
current state is flushed to disk/NVRAM, with an additional disk/NVRAM, with an additional option that allows an LDP partner
option that allows an LDP partner to request that state is to request that state is flushed in both directions if graceful
flushed in both directions if graceful shutdown is required. shutdown is required.
- re-issuing lost messages after failover to ensure that - re-issuing lost messages after failover to ensure that LSP/label
LSP/label state is correctly recovered after reconnection of state is correctly recovered after reconnection of the LDP
the LDP session. session.
The issues and objectives described above are equally The issues and objectives described above are equally applicable to
applicable to CR-LDP. CR-LDP.
Other objectives of this draft are to Other objectives of this document are to:
- offer backward-compatibility with LSRs that do not - offer backward-compatibility with LSRs that do not implement these
implement these extensions to LDP extensions to LDP.
- preserve existing protocol rules described in [RFC3036] - preserve existing protocol rules described in [RFC3036] for
for handling unexpected duplicate messages and for handling unexpected duplicate messages and for processing
processing unexpected messages referring to unknown unexpected messages referring to unknown LSPs/labels.
LSPs/labels
- avoid full state refresh solutions (such as those present - avoid full state refresh solutions (such as those present in RSVP:
in RSVP: see [RFC2205], [RFC2961], [RFC3209] and [LDP- see [RFC2205], [RFC2961], [RFC3209] and [RFC3478]) whether they be
RESTART]) whether they be continual, or limited to post- continual, or limited to post-failover recovery.
failover recovery.
Note that this draft concentrates on the preservation of Note that this document concentrates on the preservation of label
label state for labels exchanged between a pair of state for labels exchanged between a pair of adjacent LSRs when the
adjacent LSRs when the TCP connection between those LSRs TCP connection between those LSRs is lost. This is a requirement for
is lost. This is a requirement for Fault Tolerant Fault Tolerant operation of LSPs, but a full implementation of end-
operation of LSPs, but a full implementation of end-to- to-end protection for LSPs requires that this be combined with other
end protection for LSPs requires that this is combined techniques that are outside the scope of this document.
with other techniques that are outside the scope of this
draft.
In particular, this draft does not attempt to describe In particular, this document does not attempt to describe how to
how to modify the routing of an LSP or the resources modify the routing of an LSP or the resources allocated to a label or
allocated to a label or LSP, which is covered by LSP, which is covered by [RFC3214]. This document also does not
[RFC3214]. This draft also does not address how to address how to provide automatic layer 2 or layer 3 protection
provide automatic layer 2 or layer 3 protection switching switching for a label or LSP, which is a separate area for study.
for a label or LSP, which is a separate area for study.
This specification does not preclude an implementation This specification does not preclude an implementation from
from attempting (or require it to attempt) to use the FT attempting (or require it to attempt) to use the FT behavior
behavior described here to recover from a preemptive described here to recover from a preemptive failure of a connection
failure of a connection on a non-FT system due to, for on a non-FT system due to, for example, a partial system crash.
example, a partial system crash. Note, however, that Note, however, that there are potential issues too numerous to list
there are potential issues too numerous to list here - here - not least the likelihood that the same crash will immediately
not least the likelihood that the same crash will occur when processing the restored data.
immediately occur when processing the restored data.
4. Overview of LDP FT Enhancements 4. Overview of LDP FT Enhancements
The LDP FT enhancements consist of the following main The LDP FT enhancements consist of the following main elements, which
elements, which are described in more detail in the are described in more detail in the sections that follow.
sections that follow.
- The presence of an FT Session TLV on the LDP - The presence of an FT Session TLV on the LDP Initialization
Initialization message indicates that an LSR supports some message indicates that an LSR supports some form of protection or
form of protection or recovery from session failure. A flag recovery from session failure. A flag bit within this TLV (the S
bit within this TLV (the S bit) indicates that the LSR bit) indicates that the LSR supports the LDP FT enhancements on
supports the LDP FT enhancements on this session. Another this session. Another flag (the C bit) indicates that the check-
flag (the C bit) indicates that the checkpointing procedures pointing procedures are to be used.
are to be used.
- An FT Reconnect Flag in the FT Session TLV (the R bit) - An FT Reconnect Flag in the FT Session TLV (the R bit) indicates
indicates whether an LSR has preserved FT Label state across whether an LSR has preserved FT Label state across a failure of
a failure of the TCP connection. the TCP connection.
- An FT Reconnection Timeout, exchanged on the LDP - An FT Reconnection Timeout, exchanged on the LDP Initialization
Initialization message, that indicates the maximum time peer message, that indicates the maximum time peer LSRs will preserve
LSRs will preserve FT Label state after a failure of the TCP FT Label state after a failure of the TCP connection.
connection.
- An FT Protection TLV used to identify operations that - An FT Protection TLV used to identify operations that affect LDP
affect LDP labels. All LDP messages carrying the FT labels. All LDP messages carrying the FT Protection TLV need to
Protection TLV need to be secured (e.g. to NVRAM) and ACKed be secured (e.g. to NVRAM) and ACKed to the sending LDP peer so
to the sending LDP peer in order that the state for Sequence that the state for Sequence Numbered FT Labels can be correctly
Numbered FT Labels can be correctly recovered after LDP recovered after LDP session reconnection.
session reconnection.
Note that the implementation within an FT system is left Note that the implementation within an FT system is left open by
open by this draft. An implementation could choose to this document. An implementation could choose to secure entire
secure entire messages relating to Sequence Numbered FT messages relating to Sequence Numbered FT Labels, or it could
Labels, or it could secure only the relevant state secure only the relevant state information.
information.
- Address advertisement may also be secured by use of the - Address advertisement may also be secured by use of the FT
FT Protection TLV. This enables recovery after LDP session Protection TLV. This enables recovery after LDP session
reconnection without the need to re-advertise what may be a reconnection without the need to re-advertise what may be a very
very large number of addresses. large number of addresses.
- The FT Protection TLV may also be used on the Keepalive - The FT Protection TLV may also be used on the Keepalive message to
message to flush acknowledgement of all previous FT flush acknowledgement of all previous FT operations. This enables
operations. This enables a check-point for future recovery, a check-point for future recovery, either in mid-session or prior
either in mid-session or prior to graceful shutdown of an to graceful shutdown of an LDP session. This procedure may also
LDP session. This procedure may also be used to checkpoint be used to check-point all (that is both FT and non-FT) operations
all (that is both FT and non-FT) operations for future for future recovery.
recovery.
4.1. Establishing an FT LDP Session 4.1. Establishing an FT LDP Session
In order that the extensions to LDP [RFC3036] described In order that the extensions to LDP [RFC3036] described in this
in this draft can be used successfully on an LDP session document can be used successfully on an LDP session between a pair of
between a pair of LDP peers, they MUST negotiate that the LDP peers, they MUST negotiate that the LDP FT enhancements are to be
LDP FT enhancements are to be used on the LDP session. used on the LDP session.
This is done on the LDP Initialization message exchange This is done on the LDP Initialization message exchange using a new
using a new FT Session TLV. Presence of this TLV FT Session TLV. Presence of this TLV indicates that the peer wants
indicates that the peer wants to support some form of to support some form of protection or recovery processing. The S bit
protection or recovery processing. The S bit within this within this TLV indicates that the peer wants to support the LDP FT
TLV indicates that the peer wants to support the LDP FT enhancements on this LDP session. The C bit indicates that the peer
enhancements on this LDP session. The C bit indicates wants to support the check-pointing functions described in this
that the peer wants to support the checkpointing document. The S and C bits may be set independently.
functions described in this draft. The S and C bits may
be set independently.
The relevant LDP FT enhancements MUST be supported on an The relevant LDP FT enhancements MUST be supported on an LDP session
LDP session if both LDP peers include an FT Session TLV if both LDP peers include an FT Session TLV on the LDP Initialization
on the LDP Initialization message and have the same message and have the same setting of the S or C bit.
setting of the S or C bit.
If either LDP Peer does not include the FT Session TLV If either LDP Peer does not include the FT Session TLV LDP
LDP Initialization message or if there is no match of S Initialization message, or if there is no match of S and C bits
and C bits between the peers, the LDP FT enhancements between the peers, the LDP FT enhancements MUST NOT be used during
MUST NOT be used during this LDP session. Use of LDP FT this LDP session. Use of LDP FT enhancements by a sending LDP peer
enhancements by a sending LDP peer MUST be interpreted by in these cases MUST be interpreted by the receiving LDP peer as a
the receiving LDP peer as a serious protocol error serious protocol error causing the session to be terminated.
causing the session to be terminated.
An LSR MAY present different FT/non-FT behavior on An LSR MAY present different FT/non-FT behavior on different TCP
different TCP connections, even if those connections are connections, even if those connections are successive instantiations
successive instantiations of the LDP session between the of the LDP session between the same LDP peers.
same LDP peers.
4.1.1 Interoperation with Non-FT LSRs 4.1.1 Interoperation with Non-FT LSRs
The FT Session TLV on the LDP Initialization message The FT Session TLV on the LDP Initialization message carries the U-
carries the U-bit. If an LSR does not support any bit. If an LSR does not support any protection or recovery
protection or recovery mechanisms , it will ignore this mechanisms, it will ignore this TLV. Since such partners also do not
TLV. Since such partners also do not include the FT include the FT Session TLV, all LDP sessions to such LSRs will not
Session TLV, all LDP sessions to such LSRs will not use use the LDP FT enhancements.
the LDP FT enhancements.
The rest of this draft assumes that the LDP sessions The rest of this document assumes that the LDP sessions under
under discussion are between LSRs that do support the LDP discussion are between LSRs that support the LDP FT enhancements,
FT enhancements, except where explicitly stated except where explicitly stated otherwise.
otherwise.
4.2. TCP Connection Failure 4.2. TCP Connection Failure
4.2.1 Detecting TCP Connection Failures 4.2.1 Detecting TCP Connection Failures
TCP connection failures may be detected and reported to the TCP connection failures may be detected and reported to the LDP
LDP component in a variety of ways. These should all be component in a variety of ways. These should all be treated in the
treated in the same way by the LDP component. same way by the LDP component.
- Indication from the management component that a TCP - Indication from the management component that a TCP connection or
connection or underlying resource is no longer active. underlying resource is no longer active.
- Notification from a hardware management component of an - Notification from a hardware management component of an interface
interface failure. 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.
4.2.2 LDP Processing after Connection Failure 4.2.2 LDP Processing after Connection Failure
If the LDP FT enhancements are not in use on an LDP If the LDP FT enhancements are not in use on an LDP session, the
session, the action of the LDP peers on failure of the action of the LDP peers on failure of the TCP connection is as
TCP connection is as specified in [RFC3036]. specified in [RFC3036].
All state information and resources associated with non- All state information and resources associated with non-FT Labels
FT Labels MUST be released on the failure of the TCP MUST be released on the failure of the TCP connection, including
connection, including deprogramming the non-FT Label from deprogramming the non-FT Label from the switching hardware. This is
the switching hardware. This is equivalent to the equivalent to the behavior specified in [RFC3036].
behavior specified in [RFC3036].
If the LDP FT enhancements are in use on an LDP session, If the LDP FT enhancements are in use on an LDP session, both LDP
both LDP peers SHOULD preserve state information and peers SHOULD preserve state information and resources associated with
resources associated with FT Labels exchanged on the LDP FT Labels exchanged on the LDP session. Both LDP peers SHOULD use a
session. Both LDP peers SHOULD use a timer to release timer to release the preserved state information and resources
the preserved state information and resources associated associated with FT-labels if the TCP connection is not restored
with FT-labels if the TCP connection is not restored within a reasonable period. The behavior when this timer expires is
within a reasonable period. The behavior when this timer equivalent to the LDP session failure behavior described in
expires is equivalent to the LDP session failure behavior [RFC3036].
described in [RFC3036].
The FT Reconnection Timeout each LDP peer intends to The FT Reconnection Timeout each LDP peer intends to apply to the LDP
apply to the LDP session is carried in the FT Session TLV session is carried in the FT Session TLV on the LDP Initialization
on the LDP Initialization messages. Both LDP peers MUST messages. Both LDP peers MUST use the value that corresponds to the
use the value that corresponds to the lesser timeout lesser timeout interval of the two proposed timeout values from the
interval of the two proposed timeout values from the LDP LDP Initialization exchange, where a value of zero is treated as
Initialization exchange, where a value of zero is treated positive infinity.
as positive infinity.
4.3. Data Forwarding During TCP Connection Failure 4.3. Data Forwarding During TCP Connection Failure
An LSR that implements the LDP FT enhancements SHOULD An LSR that implements the LDP FT enhancements SHOULD preserve the
preserve the programming of the switching hardware across programming of the switching hardware across a failover. This
a failover. This ensures that data forwarding is ensures that data forwarding is unaffected by the state of the TCP
unaffected by the state of the TCP connection between connection between LSRs.
LSRs.
It is an integral part of FT failover processing in some It is an integral part of FT failover processing in some hardware
hardware configurations that some data packets might be configurations that some data packets might be lost. If data loss is
lost. If data loss is not acceptable to the applications not acceptable to the applications using the MPLS network, the LDP FT
using the MPLS network, the LDP FT enhancements described enhancements described in this document SHOULD NOT be used.
in this draft SHOULD NOT be used.
4.4. FT LDP Session Reconnection 4.4. FT LDP Session Reconnection
When a new TCP connection is established, the LDP peers When a new TCP connection is established, the LDP peers MUST exchange
MUST exchange LDP Initialization messages. When a new LDP Initialization messages. When a new TCP connection is
TCP connection is established after failure, the LDP established after failure, the LDP peers MUST re-exchange LDP
peers MUST re-exchange LDP Initialization messages. Initialization messages.
If an LDP peer includes the FT Session TLV with the S bit If an LDP peer includes the FT Session TLV with the S bit set in the
set in the LDP Initialization message for the new LDP Initialization message for the new instantiation of the LDP
instantiation of the LDP session, it MUST also set the FT session, it MUST also set the FT Reconnect Flag according to whether
Reconnect Flag according to whether it has been able to it has been able to preserve label state. The FT Reconnect Flag is
preserve label state. The FT Reconnect Flag is carried carried in the FT Session TLV.
in the FT Session TLV.
If an LDP peer has preserved all state information for If an LDP peer has preserved all state information for previous
previous instantiations of the LDP session, then it instantiations of the LDP session, then it SHOULD set the FT
SHOULD set the FT Reconnect Flag to 1 in the FT Session Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set
TLV. Otherwise, it MUST set the FT Reconnect Flag to 0. the FT Reconnect Flag to 0.
If either LDP peer sets the FT Reconnect Flag to 0, or If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
omits the FT Session TLV, both LDP peers MUST release any Session TLV, both LDP peers MUST release any state information and
state information and resources associated with the resources associated with the previous instantiation of the LDP
previous instantiation of the LDP session between the session between the same LDP peers, including FT Label state and
same LDP peers, including FT Label state and Addresses. Addresses. This ensures that network resources are not permanently
This ensures that network resources are not permanently lost by one LSR if its LDP peer is forced to undergo a cold start.
lost by one LSR if its LDP peer is forced to undergo a
cold start.
If an LDP peer changes any session parameters (for If an LDP peer changes any session parameters (for example, the label
example, the label space bounds) from the previous space bounds) from the previous instantiation, the nature of any
instantiation the nature of any preserved labels may have preserved labels may have changed. In particular, previously
changed. In particular, previously allocated labels may allocated labels may now be out of range. For this reason, session
now be out of range. For this reason, session reconnection MUST use the same parameters as were in use on the
reconnection MUST use the same parameters as were in use session before the failure. If an LDP peer notices that the
on the session before the failure. If an LDP peer parameters have been changed by the other peer, it SHOULD send a
notices that the parameters have been changed by the Notification message with the 'FT Session parameters changed' status
other peer it SHOULD send a Notification message with the code.
'FT Session parameters changed' status code.
If both LDP peers set the FT Reconnect Flag to 1, both If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST
LDP peers MUST use the procedures indicated in this draft use the procedures indicated in this document to complete any label
to complete any label operations on Sequence Numbered FT operations on Sequence Numbered FT Labels that were interrupted by
Labels that were interrupted by the LDP session failure. the LDP session failure.
If an LDP peer receives an LDP Initialization message If an LDP peer receives an LDP Initialization message with the FT
with the FT Reconnect Flag set before it sends its own Reconnect Flag set before it sends its own Initialization message,
Initialization message, but has retained no information but has retained no information about the previous version of the
about the previous version of the session, it MUST session, it MUST respond with an Initialization message with the FT
respond with an Initialization message with the FT Reconnect Flag clear. If an LDP peer receives an LDP Initialization
Reconnect Flag clear. If an LDP peer receives an LDP message with the FT Reconnect Flag set in response to an
Initialization message with the FT Reconnect Flag set in Initialization message that it has sent with the FT Reconnect Flag
response to an Initialization message that it has sent clear, it MUST act as if no state was retained by either peer on the
with the FT Reconnect Flag clear it MUST act as if no session.
state was retained by either peer on the session.
4.5. Operations on FT Labels 4.5. Operations on FT Labels
Label operations on Sequence Numbered FT Labels are made Label operations on Sequence Numbered FT Labels are made Fault
Fault Tolerant by providing acknowledgement of all LDP Tolerant by providing acknowledgement of all LDP messages that affect
messages that affect Sequence Numbered FT Labels. Sequence Numbered FT Labels. Acknowledgements are achieved by means
Acknowledgements are achieved by means of sequence of sequence numbers on these LDP messages.
numbers on these LDP messages.
The message exchanges used to achieve acknowledgement of The message exchanges used to achieve acknowledgement of label
label operations and the procedures used to complete operations and the procedures used to complete interrupted label
interrupted label operations are detailed in the section operations are detailed in section 5, "FT Operations".
"FT Operations".
Using these acknowledgements and procedures, it is not Using these acknowledgements and procedures, it is not necessary for
necessary for LDP peers to perform a complete re- LDP peers to perform a complete re-synchronization of state for all
synchronization of state for all Sequence Numbered FT Sequence Numbered FT Labels, either on re-connection of the LDP
Labels, either on re-connection of the LDP session session between the LDP peers or on a timed basis.
between the LDP peers or on a timed basis.
4.6. Check-Pointing 4.6. Check-Pointing
Check-pointing is a useful feature that allows nodes to Check-pointing is a useful feature that allows nodes to reduce the
reduce the amount of processing that they need to do to amount of processing that they need to do to acknowledge LDP
acknowledge LDP messages. The C bit in the FT Session messages. The C bit in the FT Session TLV is used to indicate that
TLV is used to indicate that checkpointing is supported. check-pointing is supported.
Under the normal operation on Sequence Numbered FT Under the normal operation on Sequence Numbered FT Labels,
Labels, acknowledgments may be deferred during normal acknowledgments may be deferred during normal processing and only
processing and only sent periodically. Check-pointing sent periodically. Check-pointing may be used to flush
may be used to flush acknowledgement from a peer by acknowledgement from a peer by including a sequence number on a
including a sequence number on a Keepalive message Keepalive message requesting acknowledgement of that message and all
requesting acknowledgement of that message and all previous messages. In this case, all Sequence Numbered FT Labels are
previous messages. In this case, all Sequence Numbered Check-Pointable FT Labels.
FT Labels are Checkpointable FT Labels.
If the S bit is not agreed upon, checkpointing may still If the S bit is not agreed upon, check-pointing may still be used.
be used. In this case it is used to acknowledge all In this case it is used to acknowledge all messages exchanged between
messages exchanged between the peers, and all labels are the peers, and all labels are Check-Pointable FT Labels.
Checkpointable FT Labels.
This offers an approach where acknowledgements need not This offers an approach where acknowledgements need not be sent to
be sent to every message or even frequently, but are only every message or even frequently, but are only sent as check-points
sent as check-points in response to requests carried on in response to requests carried on Keepalive messages. Such an
Keepalive messages. Such an approach may be considered approach may be considered optimal in systems that do not show a high
optimal in systems that do not show a high degree of degree of change over time (such as targeted LDP sessions) and that
change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges.
are prepared to risk loss of state for the most recent More dynamic systems (such as LDP discovery sessions) are more likely
LDP exchanges. More dynamic systems (such as LDP to want to acknowledge state changes more frequently so that the
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. maximum amount of state can be preserved over a failure.
Note that an important consideration of this draft is Note that an important consideration of this document is that nodes
that nodes acknowledging messages on a one-for-one basis, acknowledging messages on a one-for-one basis, nodes deferring
nodes deferring acknowledgements, and nodes relying on acknowledgements, and nodes relying on check-pointing, should all
check-pointing should all interoperate seamlessly and interoperate seamlessly and without protocol negotiation beyond
without protocol negotiation beyond session session initialization.
initialization.
Further discussion of this feature is provided in the Further discussion of this feature is provided in section 5, "FT
section "FT Operations". Operations".
4.6.1 Graceful Termination 4.6.1 Graceful Termination
A feature that builds on check-pointing is graceful A feature that builds on check-pointing is graceful termination.
termination.
In some cases, such as controlled failover or software In some cases, such as controlled failover or software upgrade, it is
upgrade, it is possible for a node to know in advance possible for a node to know in advance that it is going to terminate
that it is going to terminate its session with a peer. its session with a peer.
In these cases the node that intends terminating the In these cases the node that intends terminating the session can
session can flush acknowledgement using a check-point flush acknowledgement using a check-point request as described above.
request as described above. The sender SHOULD not send The sender SHOULD not send further label or address-related messages
further label or address-related messages after after requesting shutdown check-pointing in order to preserve the
requesting shutdown check-pointing in order to preserve integrity of its saved state.
the integrity of its saved state.
This, however, only provides for acknowledgement in one This, however, only provides for acknowledgement in one direction,
direction, and the node that is terminating also requires and the node that is being terminated also requires verification that
to know that it has secured all state sent by its peer. it has secured all state sent by its peer. This is achieved by a
This is achieved by a three-way hand shake of the check- three-way hand shake of the check-point which is requested by an
point which is requested by an additional TLV (the Cork additional TLV (the Cork TLV) in the Keepalive message.
TLV) in the Keepalive message.
Further discussion of this feature is provided in the Further discussion of this feature is provided in section 5, "FT
section "FT Operations". Operations".
4.7. Label Space Depletion and Replenishment 4.7. Label Space Depletion and Replenishment
When an LDP peer is unable to satisfy a Label Request When an LDP peer is unable to satisfy a Label Request message because
message because it has no more available labels, it sends it has no more available labels, it sends a Notification message
a Notification message carrying the status code 'No label carrying the status code 'No label resources'. This warns the
resources'. This warns the requesting LDP peer that requesting LDP peer that subsequent Label Request messages are also
subsequent Label Request messages are also likely to fail likely to fail for the same reason. This message does not need to be
for the same reason. This message does not need to be acknowledged for FT purposes since Label Request messages sent after
acknowledged for FT purposes since Label Request messages session recovery will receive the same response. However, the LDP
sent after session recovery will receive the same peer that receives a 'No label resources' Notification stops sending
response. However, the LDP peer that receives a 'No Label Request messages until it receives a 'Label resources
label resources' Notification stops sending Label Request available' Notification message. Since this unsolicited Notification
messages until it receives a 'Label resources available' might get lost during session failure, it may be protected using the
Notification message. Since this unsolicited procedures described in this document.
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 An alternative approach allows that an implementation may always
always assume that labels are available when a session is assume that labels are available when a session is re-established.
re-established. In this case, it is possible that it may In this case, it is possible that it may throw away the 'No label
throw away the 'No label resources' information from the resources' information from the previous incarnation of the session
previous incarnation of the session and may send a batch and may send a batch of LDP messages on session re-establishment that
of LDP messages on session re-establishment that will will fail and that it could have known would fail.
fail and that it could have known would fail.
Note that the sender of a 'Label resources available' Note that the sender of a 'Label resources available' Notification
Notification message may choose whether to add a sequence message may choose whether to add a sequence number requesting
number requesting acknowledgement. Conversely, the acknowledgement. Conversely, the receiver of 'Label resources
receiver of 'Label resources available' Notification available' Notification message may choose to acknowledge the message
message may choose to acknowledge the message without without actually saving any state.
actually saving any state.
This is an implementation choice made possible by making This is an implementation choice made possible by making the FT
the FT parameters on the Notification message optional. parameters on the Notification message optional. Implementations
Implementations will interoperate fully if they take will interoperate fully if they take opposite approaches, but
opposite approaches, but additional LDP messages may be additional LDP messages may be sent unnecessarily on session
sent unnecessarily on session recovery. recovery.
4.8. Tunneled LSPs 4.8. Tunneled LSPs
The procedures described in this document can be applied The procedures described in this document can be applied to LSPs that
to LSPs that are tunneled and to LSPs that are carried by are tunnels and to LSPs that are carried by tunnels. Recall that
tunnels. Recall that tunneled LSPs are managed by a tunneled LSPs are managed by a single LDP session that runs end to
single LDP session that runs end to end while the tunnel end, while the tunnel is managed by a different LDP session for each
is managed by a different LDP session for each hop along hop along the path. Nevertheless, a break in one of the sessions
the path. Nevertheless, a break in one of the sessions that manages the tunnel is likely to correspond with a break in the
that manages the tunnel is likely to correspond with a session that manages the tunneled LSP. This is certainly the case
break in the session that manages the tunneled LSP. This when the LDP exchanges share a failed link, but need not be the case
is certainly the case when the LDP exchanges share a if the LDP messages have been routed along a path that is different
failed link, but need not be the case if the LDP messages from that of the tunnel, or if the failure in the tunnel is caused by
have been routed along a path that is different from that an LDP software failure at a transit LSR.
of the tunnel, or if the failure in the tunnel is caused
by an LDP software failure at a transit LSR.
In order that the forwarding path of a tunneled LSP be In order that the forwarding path of a tunneled LSP be preserved, the
preserved, the forwarding path of the tunnel itself must forwarding path of the tunnel itself must be preserved. This means
be preserved. This means that the tunnel must not be torn that the tunnel must not be torn down if there is any session failure
down if there is any session failure along its path. To along its path. To achieve this, the label exchanges between each
achieve this the label exchanges between each pair of LDP pair of LDP peers along the path of the tunnel must use one of the
peers along the path of the tunnel must use one of the procedures in this document or in [RFC3478].
procedures in this document or in [LDP-RESTART].
It is perfectly acceptable to mix the restart procedures It is perfectly acceptable to mix the restart procedures used for the
used for the tunnel and the tunneled LSP. For example, tunnel and the tunneled LSP. For example, the tunnel could be set up
the tunnel could be set up using just check-pointing using just check-pointing because it is a stable LSP, but the
because it is a stable LSP, but the tunneled LSPs might tunneled LSPs might use full FT procedures so that they can recover
use full FT procedures so that they can recover active active state.
state.
Lastly, it is permissible to carry tunneled LSPs that do Lastly, it is permissible to carry tunneled LSPs that do not have FT
not have FT protection on an LSP that does have FT protection in an LSP that has FT protection.
protection.
5. FT Operations 5. FT Operations
Once an FT LDP session has been established, using the S Once an FT LDP session has been established, using the S bit in the
bit in the FT Session TLV on the Session Initialization FT Session TLV on the Session Initialization message as described in
message as described in the section "Establishing an FT section 4.1, "Establishing an FT LDP Session", both LDP peers MUST
LDP Session", both LDP peers MUST apply the procedures apply the procedures described in this section for FT LDP message
described in this section for FT LDP message exchanges. exchanges.
If the LDP session has been negotiated to not use the LDP If the LDP session has been negotiated to not use the LDP FT
FT enhancements, these procedures MUST NOT be used. enhancements, these procedures MUST NOT be used.
5.1. FT LDP Messages 5.1. FT LDP Messages
5.1.1 Sequence Numbered FT Label Messages 5.1.1 Sequence Numbered FT Label Messages
A label is identified as being a Sequence Numbered FT A label is identified as being a Sequence Numbered FT Label if the
Label if the initial Label Request or Label Mapping initial Label Request or Label Mapping message relating to that label
message relating to that label carries the FT Protection carries the FT Protection TLV.
TLV.
It is a valid implementation option to flag all labels as It is a valid implementation option to flag all labels as Sequence
Sequence Numbered FT Labels. Indeed this may be a Numbered FT Labels. Indeed this may be a preferred option for
preferred option for implementations wishing to use implementations wishing to use Keepalive messages carrying the FT
Keepalive messages carrying the FT Protection TLV to Protection TLV to achieve periodic saves of the complete label
achieve periodic saves of the complete label forwarding forwarding state.
state.
If a label is a Sequence Numbered FT Label, all LDP If a label is a Sequence Numbered FT Label, all LDP messages
messages affecting that label MUST carry the FT affecting that label MUST carry the FT Protection TLV so that the
Protection TLV in order that the state of the label can state of the label can be recovered after a failure of the LDP
be recovered after a failure of the LDP session. session.
A valid option is for no labels to be Sequence Numbered A further valid option is for no labels to be Sequence Numbered FT
FT Labels. In this case checkpointing using the Labels. In this case, check-pointing using the Keepalive message
Keepalive message applies to all messages exchanged on applies to all messages exchanged on the session.
the session.
5.1.1.1 Scope of FT Labels 5.1.1.1 Scope of FT Labels
The scope of the FT/non-FT status of a label is limited The scope of the FT/non-FT status of a label is limited to the LDP
to the LDP message exchanges between a pair of LDP peers. message exchanges between a pair of LDP peers.
In Ordered Control, when the message is forwarded In Ordered Control, when the message is forwarded downstream or
downstream or upstream, the TLV may be present or absent upstream, the TLV may be present or absent according to the
according to the requirements of the LSR sending the requirements of the LSR sending the message.
message.
If a platform-wide label space is used for FT Labels, an If a platform-wide label space is used for FT Labels, an FT Label
FT Label value MUST NOT be reused until all LDP FT peers value MUST NOT be reused until all LDP FT peers to which the label
to which the label was passed have acknowledged the was passed have acknowledged the withdrawal of the FT Label, either
withdrawal of the FT Label, either by an explicit LABEL by an explicit LABEL WITHDRAW/LABEL RELEASE, exchange or implicitly
WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP if the LDP session is reconnected after failure but without the FT
session is reconnected after failure but without the FT Reconnect Flag set. In the event that a session is not re-
Reconnect Flag set. In the event that a session is not established within the Reconnection Timeout, a label MAY become
re-established within the Reconnection Timeout, a label available for re-use if it is not still in use on some other session.
MAY become available for re-use if it is not still in use
on some other session.
5.1.2 FT Address Messages 5.1.2 FT Address Messages
If an LDP session uses the LDP FT enhancements, both LDP If an LDP session uses the LDP FT enhancements, both LDP peers MUST
peers MUST secure Address and Address Withdraw messages secure Address and Address Withdraw messages using FT Operation ACKs,
using FT Operation ACKs, as described below. This avoids as described below. This avoids any ambiguity over whether an
any ambiguity over whether an Address is still valid Address is still valid after the LDP session is reconnected.
after the LDP session is reconnected.
If an LSR determines that an Address message that it sent If an LSR determines that an Address message it sent on a previous
on a previous instantiation of a recovered LDP session is instantiation of a recovered LDP session is no longer valid, it MUST
no longer valid, it MUST explicitly issue an Address explicitly issue an Address Withdraw for that address when the
Withdraw for that address when the session is session is reconnected.
reconnected.
If the FT Reconnect Flag is not set by both LDP peers on If the FT Reconnect Flag is not set by both LDP peers upon
reconnection of an LDP session (i.e. state has not been reconnection of an LDP session (i.e. state has not been preserved),
preserved), both LDP peers MUST consider all Addresses to both LDP peers MUST consider all Addresses to have been withdrawn.
have been withdrawn. The LDP peers SHOULD issue new The LDP peers SHOULD issue new Address messages for all their valid
Address messages for all their valid addresses as addresses, as specified in [RFC3036].
specified in [RFC3036].
5.1.3 Label Resources Available Notifications 5.1.3 Label Resources Available Notifications
In LDP, it is possible that a downstream LSR may not have In LDP, it is possible that a downstream LSR may not have labels
labels available to respond to a Label Request. In this available to respond to a Label Request. In this case, as specified
case, as specified in RFC3036, the downstream LSR must in RFC 3036, the downstream LSR must respond with a Notification - No
respond with a Notification - No Label Resources message. Label Resources message. The upstream LSR then suspends asking for
The upstream LSR then suspends asking for new labels new labels until it receives a Notification - Label Resources
until it receives a Notification - Label Resources
Available message from the downstream LSR. Available message from the downstream LSR.
When the FT extensions are used on a session, When the FT extensions are used on a session, implementations may
implementations may choose whether to secure the label choose whether or not to secure the label resource state of their
resource state of their peer or not. This choice impacts peer. This choice impacts the number of LDP messages that will be
the number of LDP messages that will be incorrectly incorrectly routed to a peer with depleted resources on session re-
routed to a peer with depleted resources on session re- establishment, but does not otherwise impact interoperability.
establishment, but does not otherwise impact
interoperability.
For full preservation of state: For full preservation of state:
- The downstream LSR must preserve the label availability - The downstream LSR must preserve the label availability state
state across a failover so that it remembers to send across a failover so that it remembers to send Notification -
Notification - Label Resources Available when the resources Label Resources Available when the resources become available.
become available.
- The upstream LSR must recall the label availability state - The upstream LSR must recall the label availability state across
across failover so that it can optimize not sending Label failover so that it can optimize not sending Label Requests when
Requests when it recovers. it recovers.
- The downstream LSR must use sequence numbers on - The downstream LSR must use sequence numbers on Notification -
Notification - Label Resources Available so that it can Label Resources Available so that it can check that LSR A has
check that LSR A has received the message and clear its received the message and clear its secured state, or resend the
secured state, or resend the message if LSR A recovers message if LSR A recovers without having received it.
without having received it.
However, the following options also exist: However, the following options also exist:
- The downstream LSR may choose to not include a sequence - The downstream LSR may choose to not include a sequence number on
number on Notification - Label Resources Available. This Notification - Label Resources Available. This means that on
means that on session re-establishment it does not know what session re-establishment it does not know what its peer thinks the
its peer thinks the LSR's resource state is, because the LSR's resource state is, because the Notification may or may not
Notification may or may not have been delivered. Such an have been delivered. Such an implementation MUST begin recovered
implementation MUST begin recovered sessions by sending an sessions by sending an additional Notification - Label Resources
additional Notification - Label Resources Available to reset Available to reset its peer.
its peer.
- The upstream node may choose not to secure information - The upstream node may choose not to secure information about its
about its peer's resource state. It would acknowledge a peer's resource state. It would acknowledge a Notification -
Notification - Label Resources Available, but would not save Label Resources Available, but would not save the information.
the information. Such an implementation MUST assume that Such an implementation MUST assume that its peer's resource state
its peer's resource state has been reset to Label Resources has been reset to Label Resources Available when the session is
Available when the session is re-established. re-established.
If the FT Reconnect Flag is not set by both LDP peers on If the FT Reconnect Flag is not set by both LDP peers upon
reconnection of an LDP session (i.e. state has not been reconnection of an LDP session (i.e. state has not been preserved),
preserved), both LDP peers MUST consider the label both LDP peers MUST consider the label availability state to have
availability state to have been reset as if the session been reset as if the session had been set up for the first time.
had been set up for the first time.
5.2. FT Operation ACKs 5.2. FT Operation ACKs
Handshaking of FT LDP messages is achieved by use of Handshaking of FT LDP messages is achieved by use of ACKs.
ACKs. Correlation between the original message and the Correlation between the original message and the ACK is by means of
ACK is by means of the FT Sequence Number contained in the FT Sequence Number contained in the FT Protection TLV, and passed
the FT Protection TLV, and passed back in the FT ACK TLV. back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP
The FT ACK TLV may be carried on any LDP message that is message that is sent on the TCP connection between LDP peers.
sent on the TCP connection between LDP peers.
An LDP peer maintains a separate FT sequence number for An LDP peer maintains a separate FT sequence number for each LDP
each LDP session it participates in. The FT Sequence session in which it participates. The FT Sequence number is
number is incremented by one for each FT LDP message incremented by one for each FT LDP message (i.e. containing the FT
(i.e. containing the FT Protection TLV) issued by this Protection TLV) issued by this LSR on the FT LDP session with which
LSR on the FT LDP session with which the FT sequence the FT sequence number is associated.
number is associated.
When an LDP peer receives a message containing the FT When an LDP peer receives a message containing the FT Protection TLV,
Protection TLV, it MUST take steps to secure this message it MUST take steps to secure this message (or the state information
(or the state information derived from processing the derived from processing the message). Once the message is secured,
message). Once the message is secured, it MUST be ACKed. it MUST be ACKed. However, there is no requirement on the LSR to
However, there is no requirement on the LSR to send this send this ACK immediately.
ACK immediately.
ACKs may be accumulated to reduce the message flow ACKs may be accumulated to reduce the message flow between LDP peers.
between LDP peers. For example, if an LSR received FT For example, if an LSR received FT LDP messages with sequence numbers
LDP messages with sequence numbers 1, 2, 3, 4, it could 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK
send a single ACK with sequence number 4 to ACK receipt receipt, securing of all these messages. There is no protocol reason
and securing of all these messages. There is no protocol why the number of ACKs accumulated, or the time for which an ACK is
reason why the number of ACKs accumulated or the time for deferred, should not be allowed to become relatively large.
which an ACK is deferred should not be allowed to become
relatively large.
ACKs MUST NOT be sent out of sequence, as this is ACKs MUST NOT be sent out of sequence, as this is incompatible with
incompatible with the use of accumulated ACKs. Duplicate the use of accumulated ACKs. Duplicate ACKs (that is two successive
ACKs (that is two successive messages that acknowledge messages that acknowledge the same sequence number) are acceptable.
the same sequence number) are acceptable.
If an LDP peer discovers that its sequence number space If an LDP peer discovers that its sequence number space for a
for a specific session is full of un-acknowledged specific session is full of un-acknowledged sequence numbers (because
sequence numbers (because its partner on the session has its partner on the session has not acknowledged them in a timely
not acknowledged them in a timely way) it cannot allocate way), it cannot allocate a new sequence number for any further FT LPD
a new sequence number for any further FT LPD message. It message. It SHOULD send a Notification message with the status code
SHOULD send a Notification message with the status code 'FT Seq Numbers Exhausted'.
"FT Seq Numbers Exhausted".
5.3. Preservation of FT State 5.3. Preservation of FT State
If the LDP FT enhancements are in use on an LDP session, If the LDP FT enhancements are in use on an LDP session, each LDP
each LDP peer SHOULD NOT release the state information peer SHOULD NOT release the state information and resources
and resources associated with FT Labels exchanged on that associated with FT Labels exchanged on that LDP session when the TCP
LDP session when the TCP connection fails. This is connection fails. This is contrary to [RFC3036], but allows label
contrary to [RFC3036], but allows label operations on FT operations on FT Labels to be completed after re-connection of the
Labels to be completed after re-connection of the TCP TCP connection.
connection.
Both LDP peers on an LDP session that is using the LDP FT Both LDP peers on an LDP session that is using the LDP FT
enhancements SHOULD preserve the state information and enhancements SHOULD preserve the state information and resources they
resources they hold for that LDP session as described hold for that LDP session as described below.
below.
- An upstream LDP peer SHOULD release the resources (in - An upstream LDP peer SHOULD release the resources (in particular
particular bandwidth) associated with a Sequence Numbered FT bandwidth) associated with a Sequence Numbered FT Label when it
Label when it initiates a Label Release or Label Abort initiates a Label Release or Label Abort message for the label.
message for the label. The upstream LDP peer MUST preserve The upstream LDP peer MUST preserve state information for the
state information for the Sequence Numbered FT Label, even Sequence Numbered FT Label, even if it releases the resources
if it releases the resources associated with the label, as associated with the label, as it may need to reissue the label
it may need to reissue the label operation if the TCP operation if the TCP connection is interrupted.
connection is interrupted.
- An upstream LDP peer MUST release the state information - An upstream LDP peer MUST release the state information and
and resources associated with a Sequence Numbered FT Label resources associated with a Sequence Numbered FT Label when it
when it receives an acknowledgement to a Label Release or receives an acknowledgement to a Label Release or Label Abort
Label Abort message that it sent for the label, or when it message that it sent for the label, or when it sends a Label
sends a Label Release message in response to a Label Release message in response to a Label Withdraw message received
Withdraw message received from the 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
associated with a Sequence Numbered FT Label when it sends a with a Sequence Numbered FT Label when it sends a Label Withdraw
Label Withdraw message for the label as it has not yet message for the label as it has not yet received confirmation that
received confirmation that the upstream LDP peer has ceased the upstream LDP peer has ceased to send data using the label.
to send data using the label. The downstream LDP peer MUST The downstream LDP peer MUST NOT release the state information it
NOT release the state information it holds for the label as holds for the label as it may yet have to reissue the label
it may yet have to reissue the label operation if the TCP operation if the TCP connection is interrupted.
connection is interrupted.
- A downstream LDP peer MUST release the resources and - A downstream LDP peer MUST release the resources and state
state information associated with a Sequence Numbered FT information associated with a Sequence Numbered FT Label when it
Label when it receives an acknowledgement to a Label receives an acknowledgement to a Label Withdraw message for the
Withdraw message for the label. label.
- When the FT Reconnection Timeout expires, an LSR SHOULD - When the FT Reconnection Timeout expires, an LSR SHOULD release
release all state information and resources from previous all state information and resources from previous instantiations
instantiations of the (permanently) failed LDP session. of the (permanently) failed LDP session.
- Either LDP peer MAY elect to release state information - Either LDP peer MAY elect to release state information based on
based on its internal knowledge of the loss of integrity of its internal knowledge of the loss of integrity of the state
the state information or an inability to pend (or queue) LDP information or an inability to pend (or queue) LDP operations (as
operations (as described in section 4.4.1) during a TCP described in section 5.4.1, "LDP Operations During TCP Failure")
failure. That is, the peer is not required to wait for the during a TCP failure. That is, the peer is not required to wait
duration of the FT Reconnection Timeout before releasing for the duration of the FT Reconnection Timeout before releasing
state; the timeout provides an upper limit on the state; the timeout provides an upper limit on the persistence of
persistence of state. However, in the event that a peer state. However, in the event that a peer releases state before
releases state before the expiration of the Reconnection the expiration of the Reconnection Timeout, it MUST NOT re-use any
Timeout it MUST NOT re-use any label that was in use on the label that was in use on the session until the Reconnection
session until the Reconnection Timeout has expired. 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
- When an LSR receives a Status TLV with the E-bit set in code, which causes it to close the TCP connection, the LSR MUST
the status code, which causes it to close the TCP release all state information and resources associated with the
connection, the LSR MUST release all state information and session. This behavior is mandated because it is impossible for
resources associated with the session. This behavior is the LSR to predict the precise state and future behavior of the
mandated because it is impossible for the LSR to predict the partner LSR that set the E-bit without knowledge of the
precise state and future behavior of the partner LSR that 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 Note that the 'Temporary Shutdown' status code does not have the
the E-bit set, and MAY be used during maintenance or upgrade E-bit set, and MAY be used during maintenance or upgrade
operations to indicate that the LSR intends to preserve operations to indicate that the LSR intends to preserve state
state across a closure and re-establishment of the TCP across a closure and re-establishment of the TCP session.
session.
- If an LSR determines that it must release state for any - If an LSR determines that it must release state for any single FT
single FT Label during a failure of the TCP connection on Label during a failure of the TCP connection on which that label
which that label was exchanged, it MUST release all state was exchanged, it MUST release all state for all labels on the LDP
for all labels on the LDP session. session.
The release of state information and resources associated The release of state information and resources associated with non-FT
with non-FT labels is as described in [RFC3036]. labels is as described in [RFC3036].
Note that a Label Release and the acknowledgement to a Note that a Label Release and the acknowledgement to a Label Withdraw
Label Withdraw may be received by a downstream LSR in any may be received by a downstream LSR in any order. The downstream LSR
order. The downstream LSR MAY release its resources on MAY release its resources upon receipt of the first message and MUST
receipt of the first message and MUST release its release its resources upon receipt of the second message.
resources on receipt of the second message.
5.4. FT Procedure After TCP Failure 5.4. FT Procedure After TCP Failure
When an LSR discovers or is notified of a TCP connection When an LSR discovers or is notified of a TCP connection failure it
failure it SHOULD start an FT Reconnection Timer to allow SHOULD start an FT Reconnection Timer to allow a period for re-
a period for re-connection of the TCP connection between connection of the TCP connection between the LDP peers.
the LDP peers.
The RECOMMENDED default value for this timer is 5 The RECOMMENDED default value for this timer is 5 seconds. During
seconds. During this time, failure must be detected and this time, failure must be detected and reported, new hardware may
reported, new hardware may need to be activated, software need to be activated, software state must be audited, and a new TCP
state must be audited, and a new TCP session must be set session must be set up.
up.
Once the TCP connection between LDP peers has failed, the Once the TCP connection between LDP peers has failed, the active LSR
active LSR SHOULD attempt to re-establish the TCP SHOULD attempt to re-establish the TCP connection. The mechanisms,
connection. The mechanisms, timers and retry counts to re- timers and retry counts to re-establish the TCP connection are an
establish the TCP connection are an implementation implementation choice. It is RECOMMENDED that any attempt to re-
choice. It is RECOMMENDED that any attempt to re- establish the connection should take into account the failover
establish the connection take account of the failover processing necessary on the peer LSR, the nature of the network
processing necessary on the peer LSR, the nature of the between the LDP peers, and the FT Reconnection Timeout chosen on the
network between the LDP peers, and the FT Reconnection previous instantiation of the TCP connection (if any).
Timeout chosen on the previous instantiation of the TCP
connection (if any).
If the TCP connection cannot be re-established within the If the TCP connection cannot be re-established within the FT
FT Reconnection Timeout period, the LSR detecting this Reconnection Timeout period, the LSR detecting this timeout SHOULD
timeout SHOULD release all state preserved for the failed release all state preserved for the failed LDP session. If the TCP
LDP session. If the TCP connection is subsequently re- connection is subsequently re-established (for example, after a
established (for example, after a further Hello exchange further Hello exchange to set up a new LDP session), the LSR MUST set
to set up a new LDP session), the LSR MUST set the FT the FT Reconnect Flag to 0 if it released the preserved state
Reconnect Flag to 0 if it released the preserved state
information on this timeout event. information on this timeout event.
If the TCP connection is successfully re-established If the TCP connection is successfully re-established within the FT
within the FT Reconnection Timeout, both peers MUST re- Reconnection Timeout, both peers MUST re-issue LDP operations that
issue LDP operations that were interrupted by (that is, were interrupted by (that is, un-acknowledged as a result of) the TCP
un-acknowledged as a result of) the TCP connection connection failure. This procedure is described in section 5.5, "FT
failure. This procedure is described in section "FT
Procedure After TCP Re-connection". Procedure After TCP Re-connection".
The Hold Timer for an FT LDP Session (see [RFC3036] The Hold Timer for an FT LDP Session (see [RFC3036] section 2.5.5)
section 2.5.5) SHOULD be ignored while the FT SHOULD be ignored while the FT Reconnection Timer is running. The
Reconnection Timer is running. The hold timer SHOULD be hold timer SHOULD be restarted when the TCP connection is re-
restarted when the TCP connection is re-established. established.
5.4.1 FT LDP Operations During TCP Failure 5.4.1 FT LDP Operations During TCP Failure
When the LDP FT enhancements are in use for an LDP When the LDP FT enhancements are in use for an LDP session, it is
session, it is possible that an LSR may determine that it possible for an LSR to determine that it needs to send an LDP message
needs to send an LDP message to an LDP peer but that the to an LDP peer, but that the TCP connection to that peer is currently
TCP connection to that peer is currently down. These down. These label operations affect the state of FT Labels preserved
label operations affect the state of FT Labels preserved for the failed TCP connection, so it is important that the state
for the failed TCP connection, so it is important that changes are passed to the LDP peer when the TCP connection is
the state changes are passed to the LDP peer when the TCP restored.
connection is restored.
If an LSR determines that it needs to issue a new FT LDP If an LSR determines that it needs to issue a new FT LDP operation to
operation to an LDP peer to which the TCP connection is an LDP peer to which the TCP connection is currently failed, it MUST
currently failed, it MUST pend the operation (e.g. on a pend the operation (e.g. on a queue) and complete that operation with
queue) and complete that operation with the LDP peer when the LDP peer when the TCP connection is restored, unless the label
the TCP connection is restored, unless the label operation is overridden by a subsequent additional operation during
operation is overridden by a subsequent additional the TCP connection failure (see section 5.5, "FT Procedure After TCP
operation during the TCP connection failure (see section Re-connection").
"FT Procedure After TCP Re-connection").
If, during TCP Failure, an LSR determines that it cannot If, during TCP Failure, an LSR determines that it cannot pend an
pend an operation which it cannot simply fail (for operation which it cannot simply fail (for example, a Label Withdraw,
example, a Label Withdraw, Release or Abort operation), Release or Abort operation), it MUST NOT attempt to re-establish the
it MUST NOT attempt to re-establish the previous LDP previous LDP session. The LSR MUST behave as if the Reconnection
session. The LSR MUST behave as if the Reconnection Timer expired and release all state information with respect to the
Timer expired and release all state information with LDP peer. An LSR may be unable (or unwilling) to pend operations;
respect to the LDP peer. An LSR may be unable (or for instance, if a major routing transition occurred while TCP was
unwilling) to pend operations; for instance, if a major inoperable between LDP peers, it might result in excessively large
routing transition occurred while TCP was inoperable numbers of FT LDP Operations. An LSR that releases state before the
between LDP peers it might result in excessively large expiration of the Reconnection Timeout MUST NOT re-use any label that
numbers of FT LDP Operations. An LSR that releases state was in use on the session until the Reconnection Timeout has expired.
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 In ordered operation, received FT LDP operations that cannot be
cannot be correctly forwarded because of a TCP connection correctly forwarded because of a TCP connection failure MAY be
failure MAY be processed immediately (provided sufficient processed immediately (provided sufficient state is kept to forward
state is kept to forward the label operation) or pended the label operation) or pended for processing when the onward TCP
for processing when the onward TCP connection is restored connection is restored and the operation can be correctly forwarded
and the operation can be correctly forwarded upstream or upstream or downstream. Operations on existing FT Labels SHOULD NOT
downstream. Operations on existing FT Labels SHOULD NOT
be failed during TCP session failure. be failed during TCP session failure.
It is RECOMMENDED that Label Request operations for new It is RECOMMENDED that Label Request operations for new FT Labels not
FT Labels are not pended awaiting the re-establishment of be pended awaiting the re-establishment of TCP connection that is
TCP connection that is awaiting recovery at the time the awaiting recovery at the time the LSR determines that it needs to
LSR determines that it needs to issue the Label Request issue the Label Request message. Instead, such Label Request
message. Instead, such Label Request operations SHOULD operations SHOULD be failed and, if necessary, a notification message
be failed and, if necessary, a notification message containing the 'No LDP Session' status code sent upstream.
containing the "No LDP Session" status code sent
upstream.
Label Requests for new non-FT Labels MUST be rejected Label Requests for new non-FT Labels MUST be rejected during TCP
during TCP connection failure, as specified in [RFC3036]. connection failure, as specified in [RFC3036].
5.5. FT Procedure After TCP Re-connection 5.5. FT Procedure After TCP Re-connection
The FT operation handshaking described above means that The FT operation handshaking described above means that all state
all state changes for Sequence Numbered FT Labels and changes for Sequence Numbered FT Labels and Address messages are
Address messages are confirmed or reproducible at each confirmed or reproducible at each LSR.
LSR.
If the TCP connection between LDP peers fails but is re- If the TCP connection between LDP peers fails but is re-connected
connected within the FT Reconnection Timeout, and both within the FT Reconnection Timeout, and both LSRs have indicated they
LSRs have indicated they will be re-establishing the will be re-establishing the previous LDP session, both LDP peers on
previous LDP session, both LDP peers on the connection the connection MUST complete any label operations for Sequence
MUST complete any label operations for Sequence Numbered Numbered FT Labels that were interrupted by the failure and re-
FT Labels that were interrupted by the failure and re-
connection of the TCP connection. connection of the TCP connection.
The procedures for FT Reconnection Timeout MAY have been The procedures for FT Reconnection Timeout MAY have been invoked as a
invoked as a result of either LDP peer being unable (or result of either LDP peer being unable (or unwilling) to pend
unwilling) to pend operations which occurred during the operations which occurred during the TCP Failure (as described in
TCP Failure (as described in section 4.4.1). section 5.4.1, "LDP Operations During TCP Failure").
If, for any reason, an LSR has been unable to pend If, for any reason, an LSR has been unable to pend operations with
operations with respect to an LDP peer, as described in respect to an LDP peer, as described in section 5.4.1, "LDP
section 4.4.1, the LSR MUST set the FT Reconnect Flag to Operations During TCP Failure", the LSR MUST set the FT Reconnect
0 on re-connection to that LDP peer indicating that no FT Flag to 0 on re-connection to that LDP peer indicating that no FT
state has been preserved. state has been preserved.
Label operations are completed using the procedure Label operations are completed using the following procedure.
described below.
5.5.1 Re-Issuing FT Messages 5.5.1 Re-Issuing FT Messages
On restoration of the TCP connection between LDP peers, Upon restoration of the TCP connection between LDP peers, any LDP
any LDP messages for Sequence Numbered FT Labels that messages for Sequence Numbered FT Labels that were lost because of
were lost because of the TCP connection failure are re- the TCP connection failure are re-issued. The LDP peer that receives
issued. The LDP peer that receives a re-issued message a re-issued message processes the message as if received for the
processes the message as if received for the first time. first time.
"Net-zero" combinations of messages need not be re-issued "Net-zero" combinations of messages need not be re-issued after re-
after re-establishment of the TCP connection between LDP establishment of the TCP connection between LDP peers. This leads to
peers. This leads to the following rules for re-issuing the following rules for re-issuing messages that are not ACKed by the
messages that are not ACKed by the LDP peer on the LDP LDP peer on the LDP Initialization message exchange after re-
Initialization message exchange after re-connection of connection of the TCP session.
the TCP session.
- A Label Request message MUST be re-issued unless a Label - A Label Request message MUST be re-issued unless a Label Abort
Abort would be re-issued for the same Sequence Numbered FT would be re-issued for the same Sequence Numbered FT Label.
Label.
- A Label Mapping message MUST be re-issued unless a Label - A Label Mapping message MUST be re-issued unless a Label Withdraw
Withdraw message would be re-issued for the same Sequence message would be re-issued for the same Sequence Numbered FT
Numbered FT Label. Label.
- All other messages on the LDP session that carried the FT - All other messages on the LDP session that were sent and carried
Protection TLV MUST be re-issued if an acknowledgement had the FT Protection TLV MUST be re-issued if an acknowledgement was
not previously been received. not previously been received.
Any FT Label operations that were pended (see section Any FT Label operations that were pended (see section 5.4.1, "LDP
4.4.1) during the TCP connection failure MUST also be Operations During TCP Failure") during the TCP connection failure
issued on re-establishment of the LDP session, except MUST also be issued upon re-establishment of the LDP session, except
where they form part of a "net-zero" combination of where they form part of a "net-zero" combination of messages
messages according to the above rules. according to the above rules.
The determination of "net-zero" FT Label operations The determination of "net-zero" FT Label operations according to the
according to the above rules MAY be performed on pended above rules MAY be performed on pended messages prior to the re-
messages prior to the re-establishment of the TCP establishment of the TCP connection in order to optimize the use of
connection in order to optimize the use of queue queue resources. Messages that were sent to the LDP peer before the
resources. Messages that were sent to the LDP peer TCP connection failure, or pended messages that were paired with
before the TCP connection failure, or pended messages them, MUST NOT be subject to such optimization until an FT ACK TLV is
that are paired with them, MUST NOT be subject to such received from the LDP peer. This ACK allows the LSR to identify
optimization until an FT ACK TLV is received from the LDP which messages were received by the LDP peer prior to the TCP
peer. This ACK allows the LSR to identify which messages connection failure.
were received by the LDP peer prior to the TCP connection
failure.
6. Checkpointing Procedures 6. Check-Pointing Procedures
Checkpointing can be selected independently from the FT Check-Pointing can be selected independently from the FT procedures
procedures described above by using the C bit in the FT described above by using the C bit in the FT Session TLV on the
Session TLV on the Session Initialization message. Note, Session Initialization message. Note, however, that check-pointing
however, that checkpointing is an integral part of the FT is an integral part of the FT procedures. Setting the S and the C
procedures. Setting the S and the C bit will achieve the bit will achieve the same function as setting just the S bit.
same function as setting just the S bit.
If the C bit is set, but the S bit is not set, no label If the C bit is set, but the S bit is not set, no label is a Sequence
is a Sequence Numbered FT Label. Instead, all labels are Numbered FT Label. Instead, all labels are Check-Pointable FT
Checkpointable FT Labels. Checkpointing is used to Labels. Check-Pointing is used to synchronize all label exchanges.
synchronize all labels exchanges. No message apart from No message, apart from the check-point request and acknowledgement,
the checkpoint request and acknowledgement carries an carries an active sequence number. (Note that the Session
active sequence number. (Note that the Session Initialization message may carry a sequence number to confirm that
Initialization message may carry a sequence number to the check-point is still in place).
confirm that the checkpoint is still in place).
It is an implementation matter to decide the ordering of It is an implementation matter to decide the ordering of received
received messages and checkpoint requests to ensure that messages and check-point requests to ensure that check-point
checkpoint acknowledgements are secured. acknowledgements are secured.
If the S and C bits are both set, or only the S bit is If the S and C bits are both set, or only the S bit is set, check-
set, checkpointing applies only to Sequence Numbered FT pointing applies only to Sequence Numbered FT Labels and to address
Labels and to address messages. messages.
The set of all messages that are checkpointed in this way The set of all messages check-pointed in this way is called the
is called the Checkpointable Messages. Check-Pointable Messages.
6.1 Checkpointing with the Keepalive Message 6.1 Check-Pointing with the Keepalive Message
If an LSR receives a FT Protection TLV on a Keepalive If an LSR receives a FT Protection TLV on a Keepalive message, this
message, this is a request to flush the acknowledgements is a request to flush the acknowledgements for all previously
for all previously received Checkpointable Messages on received Check-Pointable Messages on the session.
the session.
As soon as the LSR has completed securing the As soon as the LSR has completed securing the Check-Pointable
Checkpointable Messages (or state changes consequent on Messages (or state changes consequent on those messages) received
those messages) received before the Keepalive, it MUST before the Keepalive, it MUST send an acknowledgement to the sequence
send an acknowledgement to the sequence number of the number of the Keepalive message.
Keepalive message.
In the case where the FT procedures are in use and In the case where the FT procedures are in use and acknowledgements
acknowledgements have been stored up, this may be have been stored up, this may occur immediately upon receipt of the
immediately on receipt of the Keepalive. Keepalive.
An example message flow showing this use of the Keepalive An example message flow showing this use of the Keepalive message to
message to perform a periodic check-point of state is perform a periodic check-point of state is shown in section 9.2, "Use
shown in section 8. of Check-Pointing With FT Procedures".
An example message flow showing the use of checkpointing An example message flow showing the use of check-pointing without the
without the FT procedures is shown in section 8. FT procedures is shown in section 9.5, "Check-Pointing Without FT
Procedures".
6.2 Quiesce and Keepalive 6.2 Quiesce and Keepalive
If the Keepalive Message also contains the FT Cork TLV, If the Keepalive Message also contains the FT Cork TLV, this
this indicates that the peer LSR wishes to quiesce the indicates that the peer LSR wishes to quiesce the session prior to a
session prior to a graceful restart. graceful restart.
It is RECOMMENDED that on receiving a Keepalive with the It is RECOMMENDED that upon receiving a Keepalive with the FT CORK
FT CORK TLV, an LSR should cease to send any further TLV, an LSR should cease to send any further label or address related
label or address related messages on the session until it messages on the session until it has been disconnected and
has been disconnected and reconnected, other than any reconnected, other than messages generated while processing and
messages generated while processing and securing any securing previously unacknowledged messages received from the peer
previously unacknowledged messages received from the peer requesting the quiesce. It should also attempt to complete this
requesting the quiesce. It should also attempt to processing and return a Keepalive with the FT ACK TLV as soon as
complete this processing and return a Keepalive with the possible in order to allow the session to be quiesced.
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 An example message flow showing this use of the FT Cork TLV to
TLV to achieves three-way handshake of state achieve a three-way handshake of state synchronization between two
synchronization between two LDP peers is given in section 8. LDP peers is given in section 9.4, "Temporary Shutdown With FT
Procedures and Check-Pointing".
7. Changes to Existing Messages 7. Changes to Existing Messages
7.1. LDP Initialization Message 7.1. LDP Initialization Message
The LDP FT enhancements add the following optional The LDP FT enhancements add the following optional parameters to a
parameters to a LDP Initialization message 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 The encoding for these TLVs is found in Section 8, "New Fields and
Fields and Values". Values".
FT Session TLV FT Session TLV
If present, specifies the FT behavior of If present, specifies the FT behavior of the LDP session.
the LDP session.
FT ACK TLV FT ACK TLV
If present, specifies the last FT message If present, specifies the last FT message that the sending LDP
that the sending LDP peer was able to peer was able to secure prior to the failure of the previous
secure prior to the failure of the previous instantiation of the LDP session. This TLV is only present if the
instantiation of the LDP session. This TLV FT Reconnect flag is set in the FT Session TLV, in which case this
is only present if the FT Reconnect flag is TLV MUST be present.
set in the FT Session TLV, in which case
this TLV MUST be present.
7.2. LDP Keepalive Messages 7.2. LDP Keepalive Messages
The LDP FT enhancements add the following optional The LDP FT enhancements add the following optional parameters to a
parameters to a LDP Keepalive message LDP Keepalive message:
Optional Parameter Length Value Optional Parameter Length Value
FT Protection TLV 4 See below FT Protection TLV 4 See below
FT Cork TLV 0 See below FT Cork TLV 0 See below
FT ACK TLV 4 See below FT ACK TLV 4 See below
The encoding for these TLVs is found in Section "New The encoding for these TLVs is found in Section 8, "New Fields and
Fields and Values". Values".
FT Protection TLV FT Protection TLV
If present, specifies FT Sequence Number If present, specifies the FT Sequence Number for the LDP message.
for the LDP message. When present on a When present on a Keepalive message, this indicates a solicited
Keepalive message, this indicates a flush of the acknowledgements to all previous LDP messages
solicited flush of the acknowledgements to containing sequence numbers and issued by the sender of the
all previous LDP messages containing Keepalive on the same session.
sequence numbers and issued by the sender
of the Keepalive on the same session.
FT Cork TLV FT Cork TLV
Indicates that the remote LSR wishes to Indicates that the remote LSR wishes to quiesce the LDP session.
quiesce the LDP session. See section 5 for See section 5, "FT Operations", for the recommended action in such
the recommended action in such cases. cases.
FT ACK TLV FT ACK TLV
If present, specifies the most recent FT If present, specifies the most recent FT message that the sending
message that the sending LDP peer has been LDP peer has been able to secure.
able to secure.
7.3. All Other LDP Session Messages 7.3. All Other LDP Session Messages
The LDP FT enhancements add the following optional The LDP FT enhancements add the following optional parameters to all
parameters to all other message types that flow on an LDP other message types that flow on an LDP session after the LDP
session after the LDP Initialization message 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 The encoding for these TLVs is found in section 8, "New Fields and
Fields and Values". Values".
FT Protection TLV FT Protection TLV
If present, specifies FT Sequence Number If present, specifies the FT Sequence Number for the LDP message.
for the LDP message.
FT ACK TLV FT ACK TLV
If present, identifies the most recent FT If present, identifies the most recent FT LDP message ACKed by the
LDP message ACKed by the sending LDP peer. sending LDP peer.
8. New Fields and Values 8. New Fields and Values
8.1. Status Codes 8.1. Status Codes
The following new status codes are defined to indicate The following new status codes are defined to indicate various
various conditions specific to the LDP FT enhancements. conditions specific to the LDP FT enhancements. These status codes
These status codes are carried in the Status TLV of a are carried in the Status TLV of a Notification message.
Notification message.
The "E" column is the required setting of the Status Code The "E" column is the required setting of the Status Code E-bit; the
E-bit; the "Status Data" column is the value of the 30- "Status Data" column is the value of the 30-bit Status Data field in
bit Status Data field in the Status Code TLV. the Status Code TLV.
Note that the setting of the Status Code F-bit is at the Note that the setting of the Status Code F-bit is at the discretion
discretion of the LSR originating the Status TLV. of the LSR originating the Status TLV. However, it is RECOMMENDED
However, it is RECOMMENDED that the F-bit is not set on that the F-bit is not set on Notification messages containing status
Notification messages containing status codes except "No codes except 'No LDP Session' because the duplication of messages
LDP Session" because the duplication of messages SHOULD SHOULD be restricted to being a per-hop behavior.
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 0x0000001A
Zero FT seqnum 1 0x000000xx Zero FT seqnum 1 0x0000001B
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x0000001C
Session Not FT Session Not FT
Unexpected TLV / 1 0x000000xx Unexpected TLV / 1 0x0000001D
Label Not FT Label Not FT
Missing FT Protection TLV 1 0x000000xx Missing FT Protection TLV 1 0x0000001E
FT ACK sequence error 1 0x000000xx FT ACK sequence error 1 0x0000001F
Temporary Shutdown 0 0x000000xx Temporary Shutdown 0 0x00000020
FT Seq Numbers Exhausted 1 0x000000xx FT Seq Numbers Exhausted 1 0x00000021
FT Session parameters / 1 0x000000xx FT Session parameters / 1 0x00000022
changed changed
Unexpected FT Cork TLV 1 0x000000xx Unexpected FT Cork TLV 1 0x00000023
The Temporary Shutdown status code SHOULD be used in The 'Temporary Shutdown' status code SHOULD be used in place of the
place of the Shutdown status code (which has the E-bit 'Shutdown' status code (which has the E-bit set) if the LSR that is
set) if the LSR that is shutting down wishes to inform shutting down wishes to inform its LDP peer that it expects to be
its LDP peer that it expects to be able to preserve FT able to preserve FT Label state and return to service before the FT
Label state and to return to service before the FT
Reconnection Timer expires. Reconnection Timer expires.
8.2. FT Session TLV 8.2. FT Session TLV
LDP peers can negotiate whether the LDP session between LDP peers can negotiate whether the LDP session between them supports
them supports FT extensions by using a new OPTIONAL FT extensions by using a new OPTIONAL parameter, the FT Session TLV,
parameter, the FT Session TLV, on LDP Initialization on LDP Initialization Messages.
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 (= 12) | |1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved | | FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 4 skipping to change at page 27, line 24
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 (= 12) | |1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved | | FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) | | FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) | | Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags FT Flags
FT Flags: A 16 bit field that indicates FT Flags: A 16 bit field that indicates various attributes the FT
various attributes the FT support on this support on this LDP session. This field is formatted as follows:
LDP session. This fields is formatted as
follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L| |R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag. R: FT Reconnect Flag.
Set to 1 if the sending LSR has Set to 1 if the sending LSR has preserved state and resources for
preserved state and resources for all all FT-labels since the previous LDP session between the same LDP
FT-labels since the previous LDP peers, and is otherwise set to 0. See section 5.4, "FT Procedures
session between the same LDP peers, After TCP Failure", for details of how this flag is used.
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 If the FT Reconnect Flag is set, the sending LSR MUST include an
sending LSR MUST include an FT ACK TLV FT ACK TLV on the LDP Initialization message.
on the LDP Initialization message.
S: Save State Flag. S: Save State Flag.
Set to 1 if the use of the FT Set to 1 if the use of the FT Protection TLV is supported on
Protection TLV is supported on messages other than the KeepAlive message used for check-pointing
messages other than the KeepAlive (see the C bit). I.e., the S bit indicates that some label on the
message used for chekpointing (see the session may be a Sequence Numbered FT Label.
C bit). I.e., the S bit indicates
that some label on the session may be
a Sequence Numbered FT Label.
A: All-Label Protection Required A: All-Label Protection Required
Set to 1 if all labels on the session Set to 1 if all labels on the session MUST be treated as Sequence
MUST be treated as Sequence Numbered Numbered FT Labels. This removes from a node the option of
FT Labels. This removes from a node treating some labels as FT Labels and some labels as non-FT
the option of treating some labels as Labels.
FT Labels and some labels as non-FT
Labels.
Passing this information may be Passing this information may be considered helpful to a peer since
considered helpful to a peer since it it may allow it to make optimizations in its processing.
may allow it to make optimizations in
its processing.
The A bit only has meaning if the S The A bit only has meaning if the S bit is set.
bit is set.
C: Checkpointing Flag. C: Check-Pointing Flag.
Set to 1 to indicate that the Set to 1 to indicate that the check-Pointing procedures in this
checkpointing procedures in this draft document are in use.
are in use.
If the S bit is also set to 1 then the If the S bit is also set to 1 then the C bit indicates that
C bit indicates that checkpointing is check-pointing is applied only to Sequence Numbered FT Labels.
applied only to Sequence Numbered FT
Labels.
If the S bit is set to 0 (zero) then If the S bit is set to 0 (zero) then the C bit indicates that
the C bit indicates that checkpointing check-pointing applies to all labels - all labels are Check-
applies to all labels - all labels are Pointable FT Labels.
Checkpointable FT Labels.
L: Learn From Network Flag. L: Learn From Network Flag.
Set to 1 if the Fault Recovery Set to 1 if the Fault Recovery procedures of [RFC3478] are to be
procedures of [LDP-RESTART] are to be used to re-learn state from the network.
used to re-learn state from the
network.
It is not valid for all of the S, C and L It is not valid for all of the S, C and L bits to be zero.
bits to be zero.
It is not valid for both the L and either It is not valid for both the L and either the S or C bits to be
the S or C bits to be set to 1. set to 1.
All other bits in this field are currently All other bits in this field are currently reserved and SHOULD be
reserved and SHOULD be set to zero on set to zero on transmission and ignored upon receipt.
transmission and ignored on receipt.
The following table summarizes the settings The following table summarizes the settings of these bits.
of these bits.
S A C L Comments S A C L Comments
========================= =========================
0 x 0 0 Invalid 0 x 0 0 Invalid
0 0 0 1 See [LDP-RESTART] 0 0 0 1 See [RFC3478]
0 1 0 1 Invalid 0 1 0 1 Invalid
0 x 1 0 Checkpointing of all labels 0 x 1 0 Check-Pointing of all labels
0 x 1 1 Invalid 0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels 1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels 1 1 0 0 Full FT on all labels
1 x 0 1 Invalid 1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0) 1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid. 1 x 1 1 Invalid.
FT Reconnection Timeout FT Reconnection Timeout
If the S bit or C bit in the FT Flags field If the S bit or C bit in the FT Flags field is set, this indicates
is set this indicates the period of time the period of time the sending LSR will preserve state and
the sending LSR will preserve state and resources for FT Labels exchanged on the previous instantiation of
resources for FT Labels exchanged on the an FT LDP session that has recently failed. The timeout is
previous instantiation of an FT LDP session encoded as a 32-bit unsigned integer number of milliseconds.
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 A value of zero in this field means that the sending LSR will
the sending LSR will preserve state and preserve state and resources indefinitely.
resources indefinitely.
See section 4.4 for details of how this See section 4.4 for details of how this field is used.
field is used.
If the L bit is set to 1 in the FT Flags If the L bit is set to 1 in the FT Flags field, the meaning of
field, the meaning of this field is defined this field is defined in [RFC3478].
in [LDP-RESTART].
Recovery Time Recovery Time
The Recovery Time only has meaning if the L The Recovery Time only has meaning if the L bit is set in the FT
bit is set in the FT Flags. The meaning is Flags. The meaning is defined in [RFC3478].
defined in [LDP-RESTART].
8.3. FT Protection TLV 8.3. FT Protection TLV
LDP peers use the FT Protection TLV to indicate that an LDP peers use the FT Protection TLV to indicate that an LDP message
LDP message contains an FT label operation. contains an FT label operation.
The FT Protection TLV MUST NOT be used in messages The FT Protection TLV MUST NOT be used in messages flowing on an LDP
flowing on an LDP session that does not support the LDP session that does not support the LDP FT enhancements. Its presence
FT enhancements. Its presence in such messages SHALL be in such messages SHALL be treated as a protocol error by the
treated as a protocol error by the receiving LDP peer receiving LDP peer which SHOULD send a Notification message with the
which SHOULD send a Notification message with the 'Unexpected TLV Session Not FT' status code. LSRs that do not
'Unexpected TLV Session Not FT' status code. LSRs that recognize this TLV SHOULD respond with a Notification message with
do not recognize this TLV SHOULD respond with a the 'Unknown TLV' status code.
Notification message with the 'Unknown TLV' status code.
The FT Protection TLV MAY be carried on an LDP message The FT Protection TLV MAY be carried on an LDP message transported on
transported on the LDP session after the initial exchange the LDP session after the initial exchange of LDP Initialization
of LDP Initialization messages. In particular, this TLV messages. In particular, this TLV MAY optionally be present on the
MAY optionally be present on the following messages: following messages:
- Label Request Messages in downstream on-demand - Label Request Messages in downstream on-demand distribution mode.
distribution mode
- Label Mapping messages in downstream unsolicited mode - Label Mapping messages in downstream unsolicited mode.
- Keepalive messages used to request flushing of - Keepalive messages used to request flushing of acknowledgement of
acknowledgement of all previous messages that contained this all previous messages that contained this TLV.
TLV.
If a label is to be a Sequence Numbered FT Label, then If a label is to be a Sequence Numbered FT Label, then the Protection
the Protection TLV MUST be present: TLV MUST be present:
- on the Label Request message in DoD mode - on the Label Request message in downstream on-demand distribution
mode.
- on the Label Mapping message in DU mode - on the Label Mapping message in in downstream unsolicited
distribution mode.
- on all subsequent messages concerning this label. - on all subsequent messages concerning this label.
Here 'subsequent messages concerning this label' means Here 'subsequent messages concerning this label' means any message
any message whose Label TLV specifies this label or whose whose Label TLV specifies this label or whose Label Request Message
Label Request Message ID TLV specifies the initial Label ID TLV specifies the initial Label Request message.
Request message.
If a label is not to be a Sequence Numbered FT Label, If a label is not to be a Sequence Numbered FT Label, then the
then the Protection TLV MUST NOT be present on any of Protection TLV MUST NOT be present on any of these messages that
these messages that relate to the label. The presence of relate to the label. The presence of the FT TLV on a message
the FT TLV on a message relating to a non-FT Label SHALL relating to a non-FT Label SHALL be treated as a protocol error by
be treated as a protocol error by the receiving LDP peer the receiving LDP peer which SHOULD send a notification message with
which SHOULD send a notification message with the the 'Unexpected TLV Label Not FT' status code.
'Unexpected TLV Label Not FT' status code.
Where a Label Withdraw or Label Release message contains Where a Label Withdraw or Label Release message contains only an FEC
only a FEC TLV and does not identify a single specific TLV and does not identify a single specific label, the FT TLV should
label, the FT TLV should be included in the message if any be included in the message if any label affected by the message is a
label affected by the message is a Sequence Numbered FT Sequence Numbered FT Label. If there is any doubt as to whether an
Label. If there is any doubt as to whether an FT TLVshould FT TLV should be present, it is RECOMMENDED that the sender add the
be present, it is RECOMMENDED that the sender add the TLV. TLV.
When an LDP peer receives a Label Withdraw Message or When an LDP peer receives a Label Withdraw Message or Label Release
Label Release message that contains only a FEC, it SHALL message that contains only a FEC, it SHALL accept the FT TLV if it is
accept the FT TLV if it is present regardless of the FT present regardless of the FT status of the labels that it affects.
status of the labels which it affects.
If an LDP session is an FT session as determined by the If an LDP session is an FT session as determined by the presence of
presence of the FT Session TLV with the S bit set on the the FT Session TLV, with the S bit set on the LDP Initialization
LDP Initialization messages, the FT Protection TLV MUST messages, the FT Protection TLV MUST be present on all Address
be present on all Address messages on the session. messages on the session.
If the session is an FT session, the FT Protection TLV If the session is an FT session, the FT Protection TLV may also
may also optionally be present optionally be present:
- on Notification messages on the session that have the - on Notification messages on the session that have the status code
status code 'Label Resources Available' 'Label Resources Available'.
- on Keepalive messages. - 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 Sequence Numbered The sequence number for this Sequence Numbered FT Label operation.
FT Label operation. The sequence number is The sequence number is encoded as a 32-bit unsigned integer. The
encoded as a 32-bit unsigned integer. The initial value for this field on a new LDP session is 0x00000001
initial value for this field on a new LDP and is incremented by one for each FT LDP message issued by the
session is 0x00000001 and is incremented by sending LSR on this LDP session. This field may wrap from
one for each FT LDP message issued by the 0xFFFFFFFF to 0x00000001.
sending LSR on this LDP session. This field
may wrap from 0xFFFFFFFF to 0x00000001.
This field MUST be reset to 0x00000001 if This field MUST be reset to 0x00000001 if either LDP peer does not
either LDP peer does not set the FT set the FT Reconnect Flag upon re-establishment of the TCP
Reconnect Flag on re-establishment of the connection.
TCP connection.
See the section "FT Operation Acks" for See section 5.2, "FT Operation Acks" for details of how this field
details of how this field is used. is used.
The special use of 0x00000000 is discussed The special use of 0x00000000 is discussed in the section 8.4, "FT
in the section "FT ACK TLV" below. ACK TLV" below.
If an LSR receives an FT Protection TLV on a session that If an LSR receives an FT Protection TLV on a session that does not
does not support the FT LDP enhancements, it SHOULD send support the FT LDP enhancements, it SHOULD send a Notification
a Notification message to its LDP peer containing the message to its LDP peer containing the 'Unexpected TLV, Session Not
"Unexpected TLV, Session Not FT" status code. LSRs that FT' status code. LSRs that do not recognize this TLV SHOULD respond
do not recognize this TLV SHOULD respond with a with a Notification message with the 'Unknown TLV' status code.
Notification message with the 'Unknown TLV' status code.
If an LSR receives an FT Protection TLV on an operation If an LSR receives an FT Protection TLV on an operation affecting a
affecting a label that it believes is a non-FT Label, it label that it believes is a non-FT Label, it SHOULD send a
SHOULD send a Notification message to its LDP peer Notification message to its LDP peer containing the 'Unexpected TLV,
containing the "Unexpected TLV, Label Not FT" status Label Not FT' status code.
code.
If an LSR receives a message without the FT Protection If an LSR receives a message without the FT Protection TLV affecting
TLV affecting a label that it believes is a Sequence a label that it believes is a Sequence Numbered FT Label, it SHOULD
Numbered FT Label, it SHOULD send a Notification message send a Notification message to its LDP peer containing the 'Missing
to its LDP peer containing the "Missing FT Protection FT Protection TLV' status code.
TLV" status code.
If an LSR receives an FT Protection TLV containing a zero If an LSR receives an FT Protection TLV containing a zero FT Sequence
FT Sequence Number, it SHOULD send a Notification message Number, it SHOULD send a Notification message to its LDP peer
to its LDP peer containing the "Zero FT Seqnum" status containing the 'Zero FT Seqnum' status code.
code.
8.4. FT ACK TLV 8.4. FT ACK TLV
LDP peers use the FT ACK TLV to acknowledge FT Label LDP peers use the FT ACK TLV to acknowledge FT Label operations.
operations.
The FT ACK TLV MUST NOT be used in messages flowing on an The FT ACK TLV MUST NOT be used in messages flowing on an LDP session
LDP session that does not support the LDP FT that does not support the LDP FT enhancements. Its presence on such
enhancements. Its presence on such messages SHALL be messages SHALL be treated as a protocol error by the receiving LDP
treated as a protocol error by the receiving LDP peer. peer.
The FT ACK TLV MAY be present on any LDP message The FT ACK TLV MAY be present on any LDP message exchanged on an LDP
exchanged on an LDP session after the initial LDP session after the initial LDP Initialization messages. It is
Initialization messages. It is RECOMMENDED that the FT RECOMMENDED that the FT ACK TLV be included in all FT Keepalive
ACK TLV is included on all FT Keepalive messages in order messages in order to ensure that the LDP peers do not build up a
to ensure that the LDP peers do not build up a large large backlog of unacknowledged state information.
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 the most recent FT The sequence number for the most recent FT label message that the
label message that the sending LDP peer has sending LDP peer has received from the receiving LDP peer and
received from the receiving LDP peer and secured against failure of the LDP session. It is not necessary
secured against failure of the LDP session. for the sending peer to have fully processed the message before
It is not necessary for the sending peer to ACKing it. For example, an LSR MAY ACK a Label Request message as
have fully processed the message before soon as it has securely recorded the message, without waiting
ACKing it. For example, an LSR MAY ACK a until it can send the Label Mapping message in response.
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 ACK TLV with an FT
ACK Sequence Number of 12 is treated as the
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 ACKs are cumulative. Receipt of an LDP message containing an FT
sending the FT ACK TLV has not received any ACK TLV with an FT ACK Sequence Number of 12 is treated as the
FT label operations on this LDP session. acknowledgement of all messages from 1 to 12 inclusive (assuming
This would apply to LDP sessions to new LDP the LDP session started with a sequence number of 1).
peers or after an LSR determines that it
must drop all state for a failed TCP
connection.
See the section "FT Operation Acks" for This field MUST be set to 0 if the LSR sending the FT ACK TLV has
details of how this field is used. not received any FT label operations on this LDP session. This
applies to LDP sessions, to new LDP peers or after an LSR
determines that it must drop all state for a failed TCP
connection.
If an LSR receives a message affecting a label that it See section 5.2, "FT Operation Acks" for details of how this field
believes is a Sequence Numbered FT Label and that message is used.
does not contain the FT Protection TLV, it SHOULD send a
Notification 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 If an LSR receives an FT ACK TLV that contains an FT ACK Sequence
Sequence Number that is less than the previously received Number that is less than the previously received FT ACK Sequence
FT ACK Sequence Number (remembering to take account of Number (remembering to take account of wrapping), it SHOULD send a
wrapping), it SHOULD send a Notification message to its Notification message to its LDP peer containing the 'FT ACK Sequence
LDP peer containing the "FT ACK Sequence Error" status Error' status code.
code.
8.5. FT Cork TLV 8.5. FT Cork TLV
LDP peers use the FT Cork TLV on FT Keepalive messages to LDP peers use the FT Cork TLV on FT Keepalive messages to indicate
indicate that they wish to quiesce the LDP session prior that they wish to quiesce the LDP session prior to a controlled
to a controlled shutdown and restart, for example during shutdown and restart, for example during control-plane software
control-plane software upgrade. upgrade.
The FT Cork TLV is encoded as follows. The FT Cork TLV is encoded as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Cork (0x0505) | Length (= 0) | |0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On receipt of a Keepalive message with the FT Cork TLV Upon receipt of a Keepalive message with the FT Cork TLV and the FT
and the FT Protection TLV, an LSR SHOULD perform the Protection TLV, an LSR SHOULD perform the following actions:
following actions
- Process and secure any messages from the peer LSR that - Process and secure any messages from the peer LSR that have
have sequence numbers less than (accounting for wrap) that sequence numbers less than (accounting for wrap) that contained in
contained in the FT Protection TLV on the Keepalive message. the FT Protection TLV on the Keepalive message.
- Send a Keepalive message back to the peer containing the - Send a Keepalive message back to the peer containing the FT Cork
FT Cork TLV and the FT ACK TLV specifying the FT ACK TLV and the FT ACK TLV specifying the FT ACK sequence number
sequence number equal to that in the original Keepalive equal to that in the original Keepalive message (i.e. ACKing all
message (i.e. ACKing all messages up to that point). messages up to that point).
- If this LSR has not yet received an FT ACK to all the - If this LSR has not yet received an FT ACK to all the messages it
messages it has sent containing the FT Protection TLV, then has sent containing the FT Protection TLV, then also include an FT
also include an FT Protection TLV on the Keepalive sent to Protection TLV on the Keepalive sent to the peer LSR. This tells
the peer LSR. This tells the remote peer that the local LSR the remote peer that the local LSR has saved state prior to
has saved state prior to quiesce but is still awaiting quiesce but is still awaiting confirmation that the remote peer
confirmation that the remote peer has saved state. has saved state.
- Cease sending any further state changing messages on this - Cease sending any further state changing messages on this LDP
LDP session until it has been disconnected and recovered. session until it has been disconnected and recovered.
On receipt of a Keepalive message with the FT Cork TLV On receipt of a Keepalive message with the FT Cork TLV and an FT ACK
and an FT ACK TLV that acknowledges the previously sent TLV that acknowledges the previously sent Keepalive that carried the
Keepalive that carried the FT Cork TLV, an LSR knows that FT Cork TLV, an LSR knows that quiesce is complete. If the received
quiesce is complete. If the received Keepalive also Keepalive also carries the FT Protection TLV, the LSR must respond
carries the FT Protection TLV, the LSR must respond with with a further Keepalive to complete the 3-way handshake. It SHOULD
a further Keepalive to complete the 3-way handshake. It now send a "Temporary Shutdown" Notification message, disconnect the
SHOULD now send a "Temporary Shutdown" Notification TCP session and perform whatever control plane actions required this
message, disconnect the TCP session and perform whatever session shutdown.
control plane actions required this session shutdown.
An example such 3-way handshake for controlled shutdown An example of such a 3-way handshake for controlled shutdown is given
is given in section 8. in section section 9.4, "Temporary Shutdown With FT Procedures and
Check-Pointing".
If an LSR receives a message that should not carry the FT If an LSR receives a message that should not carry the FT Cork TLV,
Cork TLV, or if the FT Cork TLV is used on a Keepalive or if the FT Cork TLV is used on a Keepalive message without one of
message without one of the FT Protection or FT ACK TLVs the FT Protection or FT ACK TLVs present, it SHOULD send a
present, , it SHOULD send a Notification message to its Notification message to its LDP peer containing the 'Unexpected FT
LDP peer containing the "Unexpected FR Cork TLV" status code. Cork TLV' status code.
9. Example Use 9. Example Use
Consider two LDP peers, P1 and P2, implementing LDP over Consider two LDP peers, P1 and P2, implementing LDP over a TCP
a TCP connection that connects them, and the message flow connection that connects them, and the message flow shown below.
shown below.
The parameters shown on each message shown below are as The parameters shown on each message below are as follows:
follows:
message (label, senders FT sequence number, FT ACK message (label, senders FT sequence number, FT ACK number)
number)
A "-" for FT ACK number means that the FT ACK TLV is A "-" for FT ACK number means that the FT ACK TLV is not included
not included on that message. "n/a" means that the on that message. "n/a" means that the parameter in question is
parameter in question is not applicable to that type not applicable to that type of message.
of message.
In the diagrams below, time flows from top to bottom. In the diagrams below, time flows from top to bottom. The relative
The relative position of each message shows when it is position of each message shows when it is transmitted. See the notes
transmitted. See the notes for a description of when for a description of when each message is received, secured for FT or
each message is received, secured for FT or processed. processed.
9.1. Session Failure and Recovery - FT Procedures 9.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)
skipping to change at page 36, line 8 skipping to change at page 35, line 44
(14) Label Mapping(L2,95,-) (14) Label Mapping(L2,95,-)
<--------------------------- <---------------------------
Label Abort(L3,96,30) Label Abort(L3,96,30)
<--------------------------- <---------------------------
(15) Label Withdraw(L1,97,-) (15) Label Withdraw(L1,97,-)
<--------------------------- <---------------------------
Notes: Notes:
====== ======
(1) Assume that the LDP session has already been initialized. (1) Assume that the LDP session has already been initialized. P1
P1 issues 2 new Label Requests using the next sequence numbers. issues 2 new Label Requests using the next sequence numbers.
(2) P2 issues a third Label request to P1. At the time of sending (2) P2 issues a Label Request to P1. At the time of sending this
this request, P2 has secured the receipt of the label request request, P2 has secured the receipt of the label request for L1
for L1 from P1, so it includes an ACK for that message. from P1, so it includes an ACK for that message.
(3) P2 Processes the Label Requests for L1 and L2 and forwards them (3) P2 processes the Label Requests for L1 and L2 and forwards them
downstream. Details of downstream processing are not shown in downstream. Details of downstream processing are not shown in
the diagram above. the diagram above.
(4) P2 receives a Label Mapping from downstream for L1, which it (4) P2 receives a Label Mapping from downstream for L1, which it
forwards to P1. It includes an ACK to the Label Request for L2, forwards to P1. It includes an ACK to the Label Request for L2,
as that message has now been secured and processed. as that message has now been secured and processed.
(5) P2 receives the Label Mapping for L2, which it forwards to P1. (5) P2 receives the Label Mapping for L2, which it forwards to P1.
This time it does not include an ACK as it has not received any This time it does not include an ACK as it has not received any
further messages from P1. further messages from P1.
(6) Meanwhile, P1 sends a new Address Message to P2 . (6) Meanwhile, P1 sends a new Address Message to P2.
(7) P1 also sends a fourth Label Request to P2 (7) P1 also sends a fourth Label Request to P2
(8) P1 sends a Keepalive message to P2, on which it includes an ACK (8) P1 sends a Keepalive message to P2, on which it includes an ACK
for the Label Mapping for L1, which is the latest message P1 has for the Label Mapping for L1, which is the latest message P1 has
received and secured at the time the Keepalive is sent. received and secured at the time the Keepalive is sent.
(9) P2 issues a Label Abort for L3. (9) P2 issues a Label Abort for L3.
(10) At this point, the TCP session goes down. (10) At this point, the TCP session goes down.
(11) While the TCP session is down, P2 receives a Label Withdraw (11) While the TCP session is down, P2 receives a Label Withdraw
Message for L1, which it queues. Message for L1, which it queues.
(12) The TCP session is reconnected and P1 and P2 exchange LDP (12) The TCP session is reconnected and P1 and P2 exchange LDP
Initialization messages on the recovered session, which include Initialization messages on the recovered session, which include
ACKS for the last message each peer received and secured prior ACKS for the last message each peer received and secured prior
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-
re-issue the Label request for L4. 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.
9.2. Use of Check-Pointing With FT Procedures 9.2. Use of Check-Pointing With FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
skipping to change at page 38, line 4 skipping to change at page 37, line 39
(7) Label Request(L4,30,-) (7) Label Request(L4,30,-)
---------------------------> --------------------------->
(8) Keepalive(n/a,31,-) (8) Keepalive(n/a,31,-)
---------------------------> --------------------------->
(9) Keepalive(n/a,-,31) (9) Keepalive(n/a,-,31)
<--------------------------- <---------------------------
(10) Keepalive(n/a,59,124) (10) Keepalive(n/a,59,124)
<--------------------------- <---------------------------
(11) Keepalive(n/a,-,59) (11) Keepalive(n/a,-,59)
---------------------------> --------------------------->
Notes: Notes:
====== ======
Notes (1) through (7) are as in the previous example Notes (1) through (7) are as in the previous example except note that
except note that no acknowledgements are piggy-backed on no acknowledgements are piggy-backed on reverse direction messages.
reverse direction messages. This means that at note (8) This means that at note (8) there are deferred acknowledgements in
there are deferred acknowledgements in both directions on both directions on both links.
both links.
(8) P1 wishes to synchronize state with P2. It sends a Keepalive (8) P1 wishes to synchronize state with P2. It sends a Keepalive
message containing a FT Protection TLV with sequence number 31. message containing an FT Protection TLV with sequence number 31.
Since it is not interested in P2's perception of the state that Since it is not interested in P2's perception of the state that
it has stored, it does not include an FT ACK TLV. it has stored, it does not include an FT ACK TLV.
(9) P2 responds at once with a Keepalive acknowledging the sequence (9) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive. This tells P1 that P2 has number on the received Keepalive. This tells P1 that P2 has
preserved all state/messages previously received on this preserved all state/messages previously received on this
session. session.
(10) P3 wishes to synchronize state with P2. It sends a Keepalive (10) The downstream node wishes to synchronize state with P2. It
message containing a FT Protection TLV with sequence number 59. sends a Keepalive message containing an FT Protection TLV with
P3 also takes this opportunity to get up to date with its sequence number 59. P3 also takes this opportunity to get up to
acknowledgements to P2 by including an FT ACK TLV acknowledging date with its acknowledgements to P2 by including an FT ACK TLV
up to sequence number 124. acknowledging up to sequence number 124.
(11) P2 responds at once with a Keepalive acknowledging the sequence (11) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive. number on the received Keepalive.
9.3. Temporary Shutdown With FT Procedures 9.3. Temporary Shutdown With FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1,27,-) (1) Label Request(L1,27,-)
---------------------------> --------------------------->
skipping to change at page 40, line 15 skipping to change at page 39, line 36
Notes: Notes:
====== ======
Notes are as in the previous example except as follows. Notes are as in the previous example except as follows.
(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-
re-established), but it is also possible that the TCP connection established), but it is also possible that the TCP connection
will be preserved. will be preserved.
9.4. Temporary Shutdown With FT Procedures and Check-Pointing 9.4. Temporary Shutdown With FT Procedures and Check-Pointing
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1,27,-) (1) Label Request(L1,27,-)
---------------------------> --------------------------->
Label Request(L2,28,-) Label Request(L2,28,-)
---------------------------> --------------------------->
skipping to change at page 42, line 8 skipping to change at page 41, line 8
(11) LDP Init(n/a,n/a,96) (11) LDP Init(n/a,n/a,96)
---------------------------> --------------------------->
LDP Init(n/a,n/a,31) LDP Init(n/a,n/a,31)
<--------------------------- <---------------------------
Label Withdraw(L1,97,-) Label Withdraw(L1,97,-)
<--------------------------- <---------------------------
Notes: Notes:
====== ======
This example operates much as the previous one. However, This example operates much as the previous one. However, at (1),
at (1), (2), (3), (4) and (5) no acknowledgements are (2), (3), (4) and (5), no acknowledgements are made.
made.
At (6), P1 determines that graceful shutdown is required At (6), P1 determines that graceful shutdown is required and sends a
and sends a Keepalive acknowledging all previously Keepalive acknowledging all previously received messages and itself
received messages and itself containing a FT Protection containing an FT Protection TLV number and the FT Cork TLV.
TLV number and the FT Cork TLV.
The Label abort at (7) crosses with this Keepalive, so at The Label abort at (7) crosses with this Keepalive, so at (8) P2
(8) P2 sends a Keepalive that acknowledges all messages sends a Keepalive that acknowledges all messages received so far, but
received so far, but also including the FT Protection and also includes the FT Protection and FT Cork TLVs to indicate that
FT Cork TLVs to indicate that there are still messages there are still messages outstanding to be acknowledged.
outstanding to be acknowledged.
P1 is then able to complete the 3-way handshake at (9) P1 is then able to complete the 3-way handshake at (9) and close the
and close the TCP session at (10). TCP session at (10).
Upon recovery at (11) there are no messages to be re-sent Upon recovery at (11), there are no messages to be re-sent because
because the KeepAlives flushed the acknowledgements. The the KeepAlives flushed the acknowledgements. The only messages sent
only messages sent after recovery is the Label Withdraw after recovery is the Label Withdraw that was pended during the TCP
that was pended during the TCP session failure. session failure.
9.5. Checkpointing Without FT Procedures 9.5. Check-Pointing Without FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1) (1) Label Request(L1)
---------------------------> --------------------------->
(2) Label Request(L2) (2) Label Request(L2)
<--------------------------- <---------------------------
Label Request(L1) Label Request(L1)
--------------------------> -------------------------->
Label Mapping(L1) Label Mapping(L1)
skipping to change at page 44, line 10 skipping to change at page 43, line 10
(10) Label Mapping(L3) (10) Label Mapping(L3)
<--------------------------- <---------------------------
(11) Label Request(L2) (11) Label Request(L2)
<--------------------------- <---------------------------
Notes: Notes:
====== ======
(1), (2) and (3) show label distribution without FT sequence numbers. (1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of (4) A check-Point request from P1. It carries the sequence number
the checkpoint request. of the check-point request.
(5) P1 immediately starts a new label distribution request. (5) P1 immediately starts a new label distribution request.
(6) P2 confirms that it has secured all previous transactions. (6) P2 confirms that it has secured all previous transactions.
(7) The subsequent (un-acknowledged) label distribution completes. (7) The subsequent (un-acknowledged) label distribution completes.
(8) The session fails and is restarted. Initialization messages (8) The session fails and is restarted. Initialization messages
confirm the sequence numbers of the secured checkpoints. confirm the sequence numbers of the secured check-points.
(9) P1 recommences the unacknowledged label distribution request. (9) P1 recommences the unacknowledged label distribution request.
(10) P2 recommences an unacknowledged label distribution request. (10) P2 recommences an unacknowledged label distribution request.
9.6. Graceful Shutdown With Checkpointing But No FT Procedures 9.6. Graceful Shutdown With Check-Pointing But No FT Procedures
notes P1 P2 notes P1 P2
===== == == ===== == ==
(1) Label Request(L1) (1) Label Request(L1)
---------------------------> --------------------------->
(2) Label Request(L2) (2) Label Request(L2)
<--------------------------- <---------------------------
Label Request(L1) Label Request(L1)
--------------------------> -------------------------->
Label Mapping(L1) Label Mapping(L1)
skipping to change at page 46, line 10 skipping to change at page 45, line 10
(11) Label Mapping(L3) (11) Label Mapping(L3)
<--------------------------- <---------------------------
(12) Label Mapping(L2) (12) Label Mapping(L2)
---------------------------> --------------------------->
Notes: Notes:
====== ======
(1), (2) and (3) show label distribution without FT sequence numbers. (1), (2) and (3) show label distribution without FT sequence numbers.
(4) A checkpoint request from P1. It carries the sequence number of (4) A check-point request from P1. It carries the sequence number
the checkpoint request and a Cork TLV. of the check-point request and a Cork TLV.
(5) P1 has sent a Cork TLV so quieces. (5) P1 has sent a Cork TLV so quieces.
(6) P2 confirms the checkpoint and continues the three-way handshake (6) P2 confirms the check-point and continues the three-way
by including a Cork TLV itself. handshake by including a Cork TLV itself.
(7) P1 completes the three-way handshake. All operations have now (7) P1 completes the three-way handshake. All operations have now
been checkpointed and the session is quiesced. been check-pointed and the session is quiesced.
(8) The session is gracefully shut down. (8) The session is gracefully shut down.
(9) The session recovers and the peers exchange the sequence numbers (9) The session recovers and the peers exchange the sequence numbers
of the last secured checkpoints. of the last secured check-points.
(10) P1 starts a new label distribution request. (10) P1 starts a new label distribution request.
(11) P1 continues processing a previously received label distribution (11) P1 continues processing a previously received label distribution
request. request.
10. Security Considerations 10. Security Considerations
The LDP FT enhancements inherit similar security The LDP FT enhancements inherit similar security considerations to
considerations to those discussed in [RFC3036]. those discussed in [RFC3036].
The LDP FT enhancements allow the re-establishment of a The LDP FT enhancements allow the re-establishment of a TCP
TCP connection between LDP peers without a full re- connection between LDP peers without a full re-exchange of the
exchange of the attributes of established labels, which attributes of established labels, which renders LSRs that implement
renders LSRs that implement the extensions specified in the extensions specified in this document vulnerable to additional
this draft vulnerable to additional denial-of-service denial-of-service attacks as follows:
attacks as follows:
- An intruder may impersonate an LDP peer in order to force - An intruder may impersonate an LDP peer in order to force a
a failure and reconnection of the TCP connection, but where failure and reconnection of the TCP connection, but where the
the intruder does not set the FT Reconnect Flag on re- intruder does not set the FT Reconnect Flag upon re-connection.
connection. This forces all FT labels to be released. 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-
re-establishment of the TCP session without preserving the establishment of the TCP session without preserving the state and
state and resources for FT labels. resources for FT labels.
- An intruder could intercept the traffic between LDP peers - An intruder could intercept the traffic between LDP peers and
and override the setting of the FT Label Flag to be set to 0 override the setting of the FT Label Flag to be set to 0 for all
for all labels. labels.
All of these attacks may be countered by use of an All of these attacks may be countered by use of an authentication
authentication scheme between LDP peers, such as the MD5- scheme between LDP peers, such as the MD5-based scheme outlined in
based scheme outlined in [RFC3036]. [RFC3036].
Alternative authentication schemes for LDP peers are Alternative authentication schemes for LDP peers are outside the
outside the scope of this draft, but could be deployed to scope of this document, but could be deployed to provide enhanced
provide enhanced security to implementations of LDP and security to implementations of LDP and the LDP FT enhancements.
the LDP FT enhancements.
As with LDP, a security issue may exist if an LDP As with LDP, a security issue may exist if an LDP implementation
implementation continues to use labels after expiration continues to use labels after expiration of the session that first
of the session that first caused them to be used. This caused them to be used. This may arise if the upstream LSR detects
may arise if the upstream LSR detects the session failure the session failure after the downstream LSR has released and re-used
after the downstream LSR has released and re-used the the label. The problem is most obvious with the platform-wide label
label. The problem is most obvious with the platform- space and could result in mis-forwarding of data to other than
wide label space and could result in mis-forwarding of data intended destinations and it is conceivable that these behaviors may
to other than intended destinations and it is conceivable be deliberately exploited to either obtain services without
that these behaviors may be deliberately exploited to authorization or to deny services to others.
either obtain services without authorization or to deny
services to others.
In this draft, the validity of the session may be In this document, the validity of the session may be extended by the
extended by the FT Reconnection Timeout, and the session FT Reconnection Timeout, and the session may be re-established in
may be re-established in this period. After the expiry this period. After the expiry of the Reconnection Timeout, the
of the Reconnection Timeout the session must be session must be considered to have failed and the same security issue
considered to have failed and the same security issue
applies as described above. applies as described above.
However, the downstream LSR may declare the session as However, the downstream LSR may declare the session as failed before
failed before the expiration of its Reconnection Timeout. the expiration of its Reconnection Timeout. This increases the
This increases the period during which the downstream LSR period during which the downstream LSR might reallocate the label
might reallocate the label while the upstream LSR while the upstream LSR continues to transmit data using the old usage
continues to transmit data using the old usage of the of the label. To reduce this issue, this document requires that
label. To reduce this issue, this draft requires that labels not be re-used until the Reconnection Timeout has expired.
labels are not re-used until the Reconnection Timeout has
expired.
A further issue might apply if labels were re-used prior A further issue might apply if labels were re-used prior to the
to the expiration of the FT Reconnection Timeout, but expiration of the FT Reconnection Timeout, but this is forbidden by
this is forbidden by this draft. this document.
The issue of re-use of labels extends to labels managed through The issue of re-use of labels extends to labels managed through other
other mechanisms including direct configuration through management mechanisms including direct configuration through management
applications and distribution through other label distribution applications and distribution through other label distribution
protocols. Avoiding this problem may be contrued as an protocols. Avoiding this problem may be construed as an
implementation issue (see below) but failure to acknowledge it could implementation issue (see below), but failure to acknowledge it could
result in mis-forwarding of data between LSPs established using result in the mis-forwarding of data between LSPs established using
some other mechanism and those recovered using the methods some other mechanism and those recovered using the methods described
described in this document. in this document.
11. Implementation Notes 11. Implementation Notes
11.1. FT Recovery Support on Non-FT LSRs 11.1. FT Recovery Support on Non-FT LSRs
In order to take full advantage of the FT capabilities of In order to take full advantage of the FT capabilities of LSRs in the
LSRs in the network, it may be that an LSR that does not network, it may be that an LSR that does not itself contain the
itself contain the ability to recover from local hardware ability to recover from local hardware or software faults still needs
or software faults still needs to support the LDP FT to support the LDP FT enhancements described in this document.
enhancements described in this draft.
Consider an LSR, P1, that is an LDP peer of a fully Fault Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant
Tolerant LSR, P2. If P2 experiences a fault in the LSR, P2. If P2 experiences a fault in the hardware or software that
hardware or software that serves an LDP session between serves an LDP session between P1 and P2, it may fail the TCP
P1 and P2, it may fail the TCP connection between the connection between the peers. When the connection is recovered, the
peers. When the connection is recovered, the LSPs/labels LSPs/labels between P1 and P2 can only be recovered if both LSRs were
between P1 and P2 can only be recovered if both LSRs were
applying the FT recovery procedures to the LDP session. applying the FT recovery procedures to the LDP session.
11.2. ACK generation logic 11.2. ACK generation logic
FT ACKs SHOULD be returned to the sending LSR as soon as FT ACKs SHOULD be returned to the sending LSR as soon as is
is practicable in order to avoid building up a large practicable in order to avoid building up a large quantity of
quantity of unacknowledged state changes at the LSR. unacknowledged state changes at the LSR. However, immediate one-
However, immediate one-for-one acknowledgements would for-one acknowledgements would waste bandwidth unnecessarily.
waste bandwidth unnecessarily.
A possible implementation strategy for sending ACKs to FT A possible implementation strategy for sending ACKs to FT LDP
LDP messages is as follows: messages is as follows:
- An LSR secures received messages in order and tracks the - An LSR secures received messages in order and tracks the sequence
sequence number of the most recently secured message, Sr. number of the most recently secured message, Sr.
- On each LDP KeepAlive that the LSR sends, it attaches an - On each LDP KeepAlive that the LSR sends, it attaches an FT ACK
FT ACK TLV listing Sr TLV listing Sr.
- Optionally, the LSR may attach an FT ACK TLV to any other - Optionally, the LSR may attach an FT ACK TLV to any other LDP
LDP message sent between Keepalive messages if, for example, message sent between Keepalive messages if, for example, Sr has
Sr has increased by more than a threshold value since the increased by more than a threshold value since the last ACK sent.
last ACK sent.
This implementation combines the bandwidth benefits of This implementation combines the bandwidth benefits of accumulating
accumulating ACKs while still providing timely ACKs. ACKs while still providing timely ACKs.
11.2.1 Ack Generation Logic When Using Check-Pointing 11.2.1 Ack Generation Logic When Using Check-Pointing
If check-pointing is in use, the LSRs need not be If check-pointing is in use, the LSRs need not be concerned with
concerned to send ACKs in such a timely manner. sending ACKs in such a timely manner.
Check-points are solicitations for acknowledgement Check-points are solicitations for acknowledgements conveyed as a
conveyed as a sequence number in an FT Protection TLV on sequence number in an FT Protection TLV on a Keepalive message. Such
a Keepalive message. Such check-point requests could be check-point requests could be issued on a timer, after a significant
issued on a timer, after a significant amount of change, amount of change, or before controlled shutdown of a session.
or before controlled shutdown of a session.
The use of check-pointing may considerably simplify an The use of check-pointing may considerably simplify an implementation
implementation since it does not need to track the since it does not need to track the sequence numbers of all received
sequence numbers of all received LDP messages. It must, LDP messages. It must, however, still ensure that all received
however, still ensure that all received messages (or the messages (or the consequent state changes) are secured before
consequent state changes) are secured before
acknowledging the sequence number on the Keepalive. acknowledging the sequence number on the Keepalive.
This approach may be considered optimal in systems that This approach may be considered optimal in systems that do not show a
do not show a high degree of change over time (such as high degree of change over time (such as targeted LDP sessions) and
targeted LDP sessions) and that are prepared to risk loss that are prepared to risk loss of state for the most recent LDP
of state for the most recent LDP exchanges. More dynamic exchanges. More dynamic systems (such as LDP discovery sessions) are
systems (such as LDP discovery sessions) are more likely more likely to want to acknowledge state changes more frequently so
to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
that the maximum amount of state can be preserved over a
failure.
11.3 Interactions With Other Label Distribution Mechanisms 11.3 Interactions With Other Label Distribution Mechanisms
Many LDP LSRs also run other label distribution mechanisms. These Many LDP LSRs also run other label distribution mechanisms. These
include management interfaces for configuration of static label include management interfaces for configuration of static label
mappings, other distinct instances of LDP, and other label mappings, other distinct instances of LDP, and other label
distribution protocols. The last example includes traffic engineering distribution protocols. The last example includes the traffic
label distribution protocol that are used to construct tunnels engineering label distribution protocol that is used to construct
through which LDP LSPs are established. tunnels through which LDP LSPs are established.
As with re-use of individual labels by LDP within a restarting LDP As with re-use of individual labels by LDP within a restarting LDP
system, care must be taken to prevent labels that need to be retained system, care must be taken to prevent labels that need to be retained
by a restarting LDP session or protocol component from being used by by a restarting LDP session or protocol component from being used by
another label distribution mechanism since that might compromise another label distribution mechanism since that might compromise data
data security amongst other things. security amongst other things.
It is a matter for implementations to avoid this issue through the It is a matter for implementations to avoid this issue through the
use of techniques such as a common label management component or use of techniques such as a common label management component or
segmented label spaces. segmented label spaces.
12. Acknowledgments 12. Acknowledgments
The work in this draft is based on the LDP ideas The work in this document is based on the LDP ideas expressed by the
expressed by the authors of [RFC3036]. authors of [RFC3036].
The ACK scheme used in this draft was inspired by the The ACK scheme used in this document was inspired by the proposal by
proposal by David Ward and John Scudder for restarting David Ward and John Scudder for restarting BGP sessions now included
BGP sessions now included in [BGP-RESTART]. in [BGP-RESTART].
The authors would also like to acknowledge the careful The authors would also like to acknowledge the careful review and
review and comments of Nick Weeds, Piers Finlayson, Tim comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas, Peter Ashwood-Smith, Bob Thomas, S. Manikantan, Adam Sheppard,
S.Manikantan, Adam Sheppard, Alan Davey, Iftekhar Hussain Alan Davey, Iftekhar Hussain and Loa Andersson.
and Loa Andersson.
13. Intellectual Property Consideration 13. Intellectual Property Consideration
The IETF has been notified of intellectual property The IETF takes no position regarding the validity or scope of any
rights claimed in regard to some or all of the intellectual property or other rights that might be claimed to
specification contained in this document. For more pertain to the implementation or use of the technology described in
information, consult the online list of claimed rights. this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
14. Full Copyright Statement The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright (c) The Internet Society (2000, 2001, 2002). The IETF has been notified of intellectual property rights claimed in
All Rights Reserved. This document and translations of it regard to some or all of the specification contained in this
may be copied and furnished to others, and derivative document. For more information, consult the online list of claimed
works that comment on or otherwise explain it or assist rights.
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 14. References
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is 14.1. Normative References
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.
15. IANA Considerations [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
This draft requires the use of a number of new TLVs and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
status codes from the number spaces within the LDP Requirement Levels", BCP 14, RFC 2119, March 1997.
protocol. This section explains the logic used by the
authors to choose the most appropriate number space for
each new entity, and is intended to assist in the
determination of any final values assigned by IANA or the
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 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
values have been agreed with IANA. and B. Thomas, "LDP Specification, RFC 3036, January
2001.
15.1. New TLVs [RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful
Restart Mechanism for Label Distribution Protocol",
RFC 3478, February 2003.
The FT Protection TLV carries attributes that affect a 14.2. Informative References
single label exchanged between LDP peers. It is taken
from the 0x02xx range for TLVs that is used in [RFC3036]
by other TLVs carrying label attributes. The next
available value in this range is 0x0203.
The FT Session TLV carries attributes that affect the [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
entire LDP session between LDP peers. It is taken from Jamin, "Resource ReSerVation Protocol (RSVP) --
the 0x05xx range for TLVs that is used in [RFC3036] by Version 1, Functional Specification", RFC 2205,
other TLVs carrying session-wide attributes. The next September 1997.
available value in this range is 0x0503.
The FT Protection TLV may ACK many label operations at [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tomassi, F.
once if cumulative ACKS are used. It is taken from the and S. Molendini, "RSVP Refresh Reduction Extensions",
0x05xx range for TLVs that is used in [RFC3036] by other RFC 2961, April 2001.
TLVs carrying session-wide attributes. The next
available value in this range is 0x0504.
The FT Cork TLV carries attributes that apply to all labels [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
exchanged between LDP peers. It is taken from the 0x05xx range V. and G. Swallow, "Extensions to RSVP for LSP
for TLVs that is used in [RFC3036] by other TLVs carrying label Tunnels", RFC 3209, December 2001.
attributes. The next available value in this range is 0x0505.
In summary: [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002.
FT Protection TLV 0x0203 [RFC3214] Ash, G., Lee, Y., Ashwood-Smith, P., Jamoussi, B.,
FT Session TLV 0x0503 Fedyk, D., Skalecki, D. and L. Li, "LSP Modification
FT Ack TLV 0x0504 Using CR-LDP", RFC 3214, January 2001.
FT Cork TLV 0x0505
15.2. New Status Codes [BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism for
BGP, Work in Progress.
LDP status codes are not sub-divided into specific ranges 15. Authors' Addresses
for different types of error. Hence, the numeric status
code values are selected as the next available.
Section 7.1 lists the new status codes required by this document and Adrian Farrel (editor)
gives interpretative information. The new codes are as follows. Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Status Code E Status Data Phone: +1 703-847-1867
EMail: afarrel@movaz.com
No LDP Session 0 0x0000001A Paul Brittain
Zero FT seqnum 1 0x0000001B Data Connection Ltd.
Unexpected TLV / 1 0x0000001C Windsor House, Pepper Street,
Session Not FT Chester, Cheshire
Unexpected TLV / 1 0x0000001D CH1 1DF, UK
Label Not FT
Missing FT Protection TLV 1 0x0000001E
FT ACK sequence error 1 0x0000001F
Temporary Shutdown 0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021
FT Session parameters / 1 0x00000022
changed
Unexpected FT Cork TLV 1 0x00000023
16. Authors' Addresses Phone: +44-(0)20-8366-1177
EMail: pjb@dataconnection.com
Philip Matthews
Hyperchip
1800 Rene-Levesque Blvd W
Montreal, Quebec H3H 2H2
Canada
Adrian Farrel (editor) Paul Brittain Phone: +1 514-906-4965
Movaz Networks, Inc. Data Connection Ltd. EMail: pmatthews@hyperchip.com
7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,
McLean, VA 22102 Chester, Cheshire
Phone: +1 703-847-1867 CH1 1DF, UK
Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177
Email: pjb@dataconnection.com
Philip Matthews Eric Gray Eric Gray
Hyperchip Celox Networks, Inc.
1800 Rene-Levesque Blvd W 2 Park Central Drive,
Montreal, Quebec H3H 2H2 Southborough, MA 01772
Canada Phone: +1 508 305 7214
Phone: +1 514-906-4965 Email: egray@celoxnetworks.com
Email: pmatthews@hyperchip.com
Jack Shaio Toby Smith EMail: ewgray@GraIyMage.com
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
Andrew G. Malis Jack Shaio
Vivace Networks Vivace Networks
2730 Orchard Parkway 2730 Orchard Parkway
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 383 7223
andy.malis@vivacenetworks.com
17. References
17.1. Normative References Phone: +1 408 432 7623
EMail: jack.shaio@vivacenetworks.com
[RFC2026] Bradner, S., "The Internet Standards Process -- Toby Smith
Revision 3", BCP 9, RFC 2026, October 1996. Laurel Networks, Inc.
1300 Omega Drive
Pittsburgh, PA 15205
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate EMail: tob@laurelnetworks.com
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036, Andrew G. Malis
January 2001. Vivace Networks
2730 Orchard Parkway
San Jose, CA 95134
[LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for Phone: +1 408 383 7223
LDP, draft-ietf-ldp-restart-05.txt, September 2002, EMail: andy.malis@vivacenetworks.com
work in progress.
17.2. Informative References 16. Full Copyright Statement
[RFC2205] Braden, R., et al., Resource ReSerVation Protocol Copyright (C) The Internet Society (2003). All Rights Reserved.
(RSVP) -- Version 1, Functional Specification, RFC
2205, September 1997.
[RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions, This document and translations of it may be copied and furnished to
RFC 2961, April 2001. 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.
[RFC3209] Awduche, D., et al,. Extensions to RSVP for LSP The limited permissions granted above are perpetual and will not be
Tunnels, RFC 3209, December 2001. revoked by the Internet Society or its successors or assigns.
[RFC3212] Jamoussi, B., et. al., Constraint-Based LSP Setup This document and the information contained herein is provided on an
using LDP, RFC 3212, January 2002. "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.
[RFC3214] Ash, G., et al., LSP Modification Using CR-LDP, RFC Acknowledgement
3214, January 2001.
[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism Funding for the RFC Editor function is currently provided by the
for BGP, draft-ietf-idr-restart-05.txt, June 2002 Internet Society.
(work in progress).
 End of changes. 371 change blocks. 
1641 lines changed or deleted 1403 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/