connection of the TCP connection.
The procedures for FT Reconnection Timeout MAY have been invoked as a
result of either LDP peer being unable (or unwilling) to pend
operations which occurred during the TCP Failure (as described in
section 5.4.1, "LDP Operations During TCP Failure").
If, for any reason, an LSR has been unable to pend operations with
respect to an LDP peer, as described in section 5.4.1, "LDP
Operations During TCP Failure", the LSR MUST set the FT Reconnect
Flag to 0 on re-connection to that LDP peer indicating that no FT
state has been preserved.
Label operations are completed using the following procedure.
5.5.1 Re-Issuing FT Messages
Upon restoration of the TCP connection between LDP peers, any LDP
messages for Sequence Numbered FT Labels that were lost because of
the TCP connection failure are re-issued. The LDP peer that receives
a re-issued message processes the message as if received for the
first time.
"Net-zero" combinations of messages need not be re-issued after re-
establishment of the TCP connection between LDP peers. This leads to
the following rules for re-issuing messages that are not ACKed by the
LDP peer on the LDP Initialization message exchange after re-
connection of the TCP session.
- A Label Request message MUST be re-issued unless a Label Abort
would be re-issued for the same Sequence Numbered FT Label.
- A Label Mapping message MUST be re-issued unless a Label Withdraw
message would be re-issued for the same Sequence Numbered FT
Label.
- All other messages on the LDP session that were sent and carried
the FT Protection TLV MUST be re-issued if an acknowledgement was
not previously been received.
Any FT Label operations that were pended (see section 5.4.1, "LDP
Operations During TCP Failure") during the TCP connection failure
MUST also be issued upon re-establishment of the LDP session, except
where they form part of a "net-zero" combination of messages
according to the above rules.
The determination of "net-zero" FT Label operations according to the
above rules MAY be performed on pended messages prior to the re-
establishment of the TCP connection in order to optimize the use of
queue resources. Messages that were sent to the LDP peer before the
TCP connection failure, or pended messages that were paired with
them, MUST NOT be subject to such optimization until an FT ACK TLV is
received from the LDP peer. This ACK allows the LSR to identify
which messages were received by the LDP peer prior to the TCP
connection failure.
6. Check-Pointing Procedures
Check-Pointing can be selected independently from the FT procedures
described above by using the C bit in the FT Session TLV on the
Session Initialization message. Note, however, that check-pointing
is an integral part of the FT procedures. Setting the S and the C
bit will achieve the same function as setting just the S bit.
If the C bit is set, but the S bit is not set, no label is a Sequence
Numbered FT Label. Instead, all labels are Check-Pointable FT
Labels. Check-Pointing is used to synchronize all label exchanges.
No message, apart from the check-point request and acknowledgement,
carries an active sequence number. (Note that the Session
Initialization message may carry a sequence number to confirm that
the check-point is still in place).
It is an implementation matter to decide the ordering of received
messages and check-point requests to ensure that check-point
acknowledgements are secured.
If the S and C bits are both set, or only the S bit is set, check-
pointing applies only to Sequence Numbered FT Labels and to address
messages.
The set of all messages check-pointed in this way is called the
Check-Pointable Messages.
6.1 Check-Pointing with the Keepalive Message
If an LSR receives a FT Protection TLV on a Keepalive message, this
is a request to flush the acknowledgements for all previously
received Check-Pointable Messages on the session.
As soon as the LSR has completed securing the Check-Pointable
Messages (or state changes consequent on those messages) received
before the Keepalive, it MUST send an acknowledgement to the sequence
number of the Keepalive message.
In the case where the FT procedures are in use and acknowledgements
have been stored up, this may occur immediately upon receipt of the
Keepalive.
An example message flow showing this use of the Keepalive message to
perform a periodic check-point of state is shown in section 9.2, "Use
of Check-Pointing With FT Procedures".
An example message flow showing the use of check-pointing without the
FT procedures is shown in section 9.5, "Check-Pointing Without FT
Procedures".
6.2 Quiesce and Keepalive
If the Keepalive Message also contains the FT Cork TLV, this
indicates that the peer LSR wishes to quiesce the session prior to a
graceful restart.
It is RECOMMENDED that upon receiving a Keepalive with the FT CORK
TLV, an LSR should cease to send any further label or address related
messages on the session until it has been disconnected and
reconnected, other than messages generated while processing and
securing previously unacknowledged messages received from the peer
requesting the quiesce. It should also attempt to complete this
processing and return a Keepalive with the FT ACK TLV as soon as
possible in order to allow the session to be quiesced.
An example message flow showing this use of the FT Cork TLV to
achieve a three-way handshake of state synchronization between two
LDP peers is given in section 9.4, "Temporary Shutdown With FT
Procedures and Check-Pointing".
7. Changes to Existing Messages
7.1. LDP Initialization Message
The LDP FT enhancements add the following optional parameters to a
LDP Initialization message:
Optional Parameter Length Value
FT Session TLV 4 See Below
FT ACK TLV 4 See Below
The encoding for these TLVs is found in Section 8, "New Fields and
Values".
FT Session TLV
If present, specifies the FT behavior of the LDP session.
FT ACK TLV
If present, specifies the last FT message that the sending LDP
peer was able to secure prior to the failure of the previous
instantiation of the LDP session. This TLV is only present if the
FT Reconnect flag is set in the FT Session TLV, in which case this
TLV MUST be present.
7.2. LDP Keepalive Messages
The LDP FT enhancements add the following optional parameters to a
LDP Keepalive message:
Optional Parameter Length Value
FT Protection TLV 4 See below
FT Cork TLV 0 See below
FT ACK TLV 4 See below
The encoding for these TLVs is found in Section 8, "New Fields and
Values".
FT Protection TLV
If present, specifies the FT Sequence Number for the LDP message.
When present on a Keepalive message, this indicates a solicited
flush of the acknowledgements to all previous LDP messages
containing sequence numbers and issued by the sender of the
Keepalive on the same session.
FT Cork TLV
Indicates that the remote LSR wishes to quiesce the LDP session.
See section 5, "FT Operations", for the recommended action in such
cases.
FT ACK TLV
If present, specifies the most recent FT message that the sending
LDP peer has been able to secure.
7.3. All Other LDP Session Messages
The LDP FT enhancements add the following optional parameters to all
other message types that flow on an LDP session after the LDP
Initialization message
Optional Parameter Length Value
FT Protection TLV 4 See below
FT ACK TLV 4 See below
The encoding for these TLVs is found in section 8, "New Fields and
Values".
FT Protection TLV
If present, specifies the FT Sequence Number for the LDP message.
FT ACK TLV
If present, identifies the most recent FT LDP message ACKed by the
sending LDP peer.
8. New Fields and Values
8.1. Status Codes
The following new status codes are defined to indicate various
conditions specific to the LDP FT enhancements. These status codes
are carried in the Status TLV of a Notification message.
The "E" column is the required setting of the Status Code E-bit; the
"Status Data" column is the value of the 30-bit Status Data field in
the Status Code TLV.
Note that the setting of the Status Code F-bit is at the discretion
of the LSR originating the Status TLV. However, it is RECOMMENDED
that the F-bit is not set on Notification messages containing status
codes except 'No LDP Session' because the duplication of messages
SHOULD be restricted to being a per-hop behavior.
Status Code E Status Data
No LDP Session 0 0x0000001A
Zero FT seqnum 1 0x0000001B
Unexpected TLV / 1 0x0000001C
Session Not FT
Unexpected TLV / 1 0x0000001D
Label Not FT
Missing FT Protection TLV 1 0x0000001E
FT ACK sequence error 1 0x0000001F
Temporary Shutdown 0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021
FT Session parameters / 1 0x00000022
changed
Unexpected FT Cork TLV 1 0x00000023
The 'Temporary Shutdown' status code SHOULD be used in place of the
'Shutdown' status code (which has the E-bit set) if the LSR that is
shutting down wishes to inform its LDP peer that it expects to be
able to preserve FT Label state and return to service before the FT
Reconnection Timer expires.
8.2. FT Session TLV
LDP peers can negotiate whether the LDP session between them supports
FT extensions by using a new OPTIONAL parameter, the FT Session TLV,
on LDP Initialization Messages.
The FT Session TLV is encoded as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags
FT Flags: A 16 bit field that indicates various attributes the FT
support on this LDP session. This field is formatted as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag.
Set to 1 if the sending LSR has preserved state and resources for
all FT-labels since the previous LDP session between the same LDP
peers, and is otherwise set to 0. See section 5.4, "FT Procedures
After TCP Failure", for details of how this flag is used.
If the FT Reconnect Flag is set, the sending LSR MUST include an
FT ACK TLV on the LDP Initialization message.
S: Save State Flag.
Set to 1 if the use of the FT Protection TLV is supported on
messages other than the KeepAlive message used for check-pointing
(see the 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
Set to 1 if all labels on the session MUST be treated as Sequence
Numbered FT Labels. This removes from a node the option of
treating some labels as FT Labels and some labels as non-FT
Labels.
Passing this information may be considered helpful to a peer since
it may allow it to make optimizations in its processing.
The A bit only has meaning if the S bit is set.
C: Check-Pointing Flag.
Set to 1 to indicate that the check-Pointing procedures in this
document are in use.
If the S bit is also set to 1 then the C bit indicates that
check-pointing is applied only to Sequence Numbered FT Labels.
If the S bit is set to 0 (zero) then the C bit indicates that
check-pointing applies to all labels - all labels are Check-
Pointable FT Labels.
L: Learn From Network Flag.
Set to 1 if the Fault Recovery procedures of [RFC3478] are to be
used to re-learn state from the network.
It is not valid for all of the S, C and L bits to be zero.
It is not valid for both the L and either the S or C bits to be
set to 1.
All other bits in this field are currently reserved and SHOULD be
set to zero on transmission and ignored upon receipt.
The following table summarizes the settings of these bits.
S A C L Comments
=========================
0 x 0 0 Invalid
0 0 0 1 See [RFC3478]
0 1 0 1 Invalid
0 x 1 0 Check-Pointing of all labels
0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels
1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid.
FT Reconnection Timeout
If the S bit or C bit in the FT Flags field is set, this indicates
the period of time the sending LSR will preserve state and
resources for FT Labels exchanged on the previous instantiation of
an FT LDP session that has recently failed. The timeout is
encoded as a 32-bit unsigned integer number of milliseconds.
A value of zero in this field means that the sending LSR will
preserve state and resources indefinitely.
See section 4.4 for details of how this field is used.
If the L bit is set to 1 in the FT Flags field, the meaning of
this field is defined in [RFC3478].
Recovery Time
The Recovery Time only has meaning if the L bit is set in the FT
Flags. The meaning is defined in [RFC3478].
8.3. FT Protection TLV
LDP peers use the FT Protection TLV to indicate that an LDP message
contains an FT label operation.
The FT Protection TLV MUST NOT be used in messages flowing on an LDP
session that does not support the LDP FT enhancements. Its presence
in such messages SHALL be treated as a protocol error by the
receiving LDP peer which SHOULD send a Notification message with the
'Unexpected TLV Session Not FT' status code. LSRs that do not
recognize this TLV SHOULD respond with a Notification message with
the 'Unknown TLV' status code.
The FT Protection TLV MAY be carried on an LDP message transported on
the LDP session after the initial exchange of LDP Initialization
messages. In particular, this TLV MAY optionally be present on the
following messages:
- Label Request Messages in downstream on-demand distribution mode.
- Label Mapping messages in downstream unsolicited mode.
- Keepalive messages used to request flushing of acknowledgement of
all previous messages that contained this TLV.
If a label is to be a Sequence Numbered FT Label, then the Protection
TLV MUST be present:
- on the Label Request message in downstream on-demand distribution
mode.
- on the Label Mapping message in in downstream unsolicited
distribution mode.
- on all subsequent messages concerning this label.
Here 'subsequent messages concerning this label' means any message
whose Label TLV specifies this label or whose Label Request Message
ID TLV specifies the initial Label Request message.
If a label is not to be a Sequence Numbered FT Label, then the
Protection TLV MUST NOT be present on any of these messages that
relate to the label. The presence of the FT TLV on a message
relating to a non-FT Label SHALL be treated as a protocol error by
the receiving LDP peer which SHOULD send a notification message with
the 'Unexpected TLV Label Not FT' status code.
Where a Label Withdraw or Label Release message contains only an FEC
TLV and does not identify a single specific label, the FT TLV should
be included in the message if any label affected by the message is a
Sequence Numbered FT Label. If there is any doubt as to whether an
FT TLV should be present, it is RECOMMENDED that the sender add the
TLV.
When an LDP peer receives a Label Withdraw Message or Label Release
message that contains only a FEC, it SHALL accept the FT TLV if it is
present regardless of the FT status of the labels that it affects.
If an LDP session is an FT session as determined by the presence of
the FT Session TLV, with the S bit set on the LDP Initialization
messages, the FT Protection TLV MUST be present on all Address
messages on the session.
If the session is an FT session, the FT Protection TLV may also
optionally be present:
- on Notification messages on the session that have the status code
'Label Resources Available'.
- on Keepalive messages.
The FT Protection TLV is encoded as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number
The sequence number for this Sequence Numbered FT Label operation.
The sequence number is encoded as a 32-bit unsigned integer. The
initial value for this field on a new LDP session is 0x00000001
and is incremented by one for each FT LDP message issued by the
sending LSR on this LDP session. This field may wrap from
0xFFFFFFFF to 0x00000001.
This field MUST be reset to 0x00000001 if either LDP peer does not
set the FT Reconnect Flag upon re-establishment of the TCP
connection.
See section 5.2, "FT Operation Acks" for details of how this field
is used.
The special use of 0x00000000 is discussed in the section 8.4, "FT
ACK TLV" below.
If an LSR receives an FT Protection TLV on a session that does not
support the FT LDP enhancements, it SHOULD send a Notification
message to its LDP peer containing the 'Unexpected TLV, Session Not
FT' status code. LSRs that do not recognize this TLV SHOULD respond
with a Notification message with the 'Unknown TLV' status code.
If an LSR receives an FT Protection TLV on an operation affecting a
label that it believes is a non-FT Label, it SHOULD send a
Notification message to its LDP peer containing the 'Unexpected TLV,
Label Not FT' status code.
If an LSR receives a message without the FT Protection TLV affecting
a label that it believes is a Sequence Numbered FT Label, it SHOULD
send a Notification message to its LDP peer containing the 'Missing
FT Protection TLV' status code.
If an LSR receives an FT Protection TLV containing a zero FT Sequence
Number, it SHOULD send a Notification message to its LDP peer
containing the 'Zero FT Seqnum' status code.
8.4. FT ACK TLV
LDP peers use the FT ACK TLV to acknowledge FT Label operations.
The FT ACK TLV MUST NOT be used in messages flowing on an LDP session
that does not support the LDP FT enhancements. Its presence on such
messages SHALL be treated as a protocol error by the receiving LDP
peer.
The FT ACK TLV MAY be present on any LDP message exchanged on an LDP
session after the initial LDP Initialization messages. It is
RECOMMENDED that the FT ACK TLV be included in all FT Keepalive
messages in order to ensure that the LDP peers do not build up a
large backlog of unacknowledged state information.
The FT ACK TLV is encoded as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT ACK (0x0504) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT ACK Sequence Number
The sequence number for the most recent FT label message that the
sending LDP peer has received from the receiving LDP peer and
secured against failure of the LDP session. It is not necessary
for the sending peer to have fully processed the message before
ACKing it. For example, an LSR MAY ACK a Label Request message as
soon as it has securely recorded the message, without waiting
until it can send the Label Mapping message in response.
ACKs are cumulative. Receipt of an LDP message containing an FT
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 sending the FT ACK TLV has
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.
See section 5.2, "FT Operation Acks" for details of how this field
is used.
If an LSR receives an FT ACK TLV that contains an FT ACK Sequence
Number that is less than the previously received FT ACK Sequence
Number (remembering to take account of wrapping), it SHOULD send a
Notification message to its LDP peer containing the 'FT ACK Sequence
Error' status code.
8.5. FT Cork TLV
LDP peers use the FT Cork TLV on FT Keepalive messages to indicate
that they wish to quiesce the LDP session prior to a controlled
shutdown and restart, for example during control-plane software
upgrade.
The FT Cork TLV is encoded as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upon receipt of a Keepalive message with the FT Cork TLV and the FT
Protection TLV, an LSR SHOULD perform the following actions:
- Process and secure any messages from the peer LSR that have
sequence numbers less than (accounting for wrap) that contained in
the FT Protection TLV on the Keepalive message.
- Send a Keepalive message back to the peer containing the FT Cork
TLV and the FT ACK TLV specifying the FT ACK sequence number
equal to that in the original Keepalive message (i.e. ACKing all
messages up to that point).
- If this LSR has not yet received an FT ACK to all the messages it
has sent containing the FT Protection TLV, then also include an FT
Protection TLV on the Keepalive sent to the peer LSR. This tells
the remote peer that the local LSR has saved state prior to
quiesce but is still awaiting confirmation that the remote peer
has saved state.
- Cease sending any further state changing messages on this LDP
session until it has been disconnected and recovered.
On receipt of a Keepalive message with the FT Cork TLV and an FT ACK
TLV that acknowledges the previously sent Keepalive that carried the
FT Cork TLV, an LSR knows that quiesce is complete. If the received
Keepalive also carries the FT Protection TLV, the LSR must respond
with a further Keepalive to complete the 3-way handshake. It SHOULD
now send a "Temporary Shutdown" Notification message, disconnect the
TCP session and perform whatever control plane actions required this
session shutdown.
An example of such a 3-way handshake for controlled shutdown is given
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 Cork TLV,
or if the FT Cork TLV is used on a Keepalive message without one of
the FT Protection or FT ACK TLVs present, it SHOULD send a
Notification message to its LDP peer containing the 'Unexpected FT
Cork TLV' status code.
9. Example Use
Consider two LDP peers, P1 and P2, implementing LDP over a TCP
connection that connects them, and the message flow shown below.
The parameters shown on each message below are as follows:
message (label, senders FT sequence number, FT ACK number)
A "-" for FT ACK number means that the FT ACK TLV is not included
on that message. "n/a" means that the parameter in question is
not applicable to that type of message.
In the diagrams below, time flows from top to bottom. The relative
position of each message shows when it is transmitted. See the notes
for a description of when each message is received, secured for FT or
processed.
9.1. Session Failure and Recovery - FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) ===== TCP Session lost =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) === TCP Session restored ===
LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
(1) Assume that the LDP session has already been initialized. P1
issues 2 new Label Requests using the next sequence numbers.
(2) P2 issues a Label Request to P1. At the time of sending this
request, P2 has secured the receipt of the label request for L1
from P1, so it includes an ACK for that message.
(3) P2 processes the Label Requests for L1 and L2 and forwards them
downstream. Details of downstream processing are not shown in
the diagram above.
(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,
as that message has now been secured and processed.
(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
further messages from P1.
(6) Meanwhile, P1 sends a new Address Message 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
for the Label Mapping for L1, which is the latest message P1 has
received and secured at the time the Keepalive is sent.
(9) P2 issues a Label Abort for L3.
(10) At this point, the TCP session goes down.
(11) While the TCP session is down, P2 receives a Label Withdraw
Message for L1, which it queues.
(12) The TCP session is reconnected and P1 and P2 exchange LDP
Initialization messages on the recovered session, which include
ACKS for the last message each peer received and secured prior
to the failure.
(13) From the LDP Init exchange, P1 determines that it needs to re-
issue the Label request for L4.
(14) Similarly, P2 determines that it needs to re-issue the Label
Mapping for L2 and the Label Abort.
(15) P2 issues the queued Label Withdraw to P1.
9.2. Use of Check-Pointing With FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,-)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,31,-)
--------------------------->
(9) Keepalive(n/a,-,31)
<---------------------------
(10) Keepalive(n/a,59,124)
<---------------------------
(11) Keepalive(n/a,-,59)
--------------------------->
Notes:
======
Notes (1) through (7) are as in the previous example except note that
no acknowledgements are piggy-backed on reverse direction messages.
This means that at note (8) there are deferred acknowledgements in
both directions on both links.
(8) P1 wishes to synchronize state with P2. It sends a Keepalive
message containing an FT Protection TLV with sequence number 31.
Since it is not interested in P2's perception of the state that
it has stored, it does not include an FT ACK TLV.
(9) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive. This tells P1 that P2 has
preserved all state/messages previously received on this
session.
(10) The downstream node wishes to synchronize state with P2. It
sends a Keepalive message containing an FT Protection TLV with
sequence number 59. P3 also takes this opportunity to get up to
date with its acknowledgements to P2 by including an FT ACK TLV
acknowledging up to sequence number 124.
(11) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive.
9.3. Temporary Shutdown With FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(12) LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
Notes are as in the previous example except as follows.
(10) P1 needs to upgrade the software or hardware that it is running.
It issues a Notification message to terminate the LDP session,
but sets the status code as 'Temporary shutdown' to inform P2
that this is not a fatal error, and P2 should maintain FT state.
The TCP connection may also fail during the period that the LDP
session is down (in which case it will need to be re-
established), but it is also possible that the TCP connection
will be preserved.
9.4. Temporary Shutdown With FT Procedures and Check-Pointing
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
Label Mapping(L1,57,-)
<--------------------------
(3) Label Mapping(L1,94,-)
<---------------------------
Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(4) Address(n/a,29,-)
--------------------------->
(5) Label Request(L4,30,-)
--------------------------->
(6) Keepalive(n/a,31,95) * with FT Cork TLV *
--------------------------->
(7) Label Abort(L3,96,-)
<---------------------------
(8) Keepalive(n/a,97,31) * with FT Cork TLV *
<---------------------------
(9) Keepalive(n/a,-,97) * with FT Cork TLV *
--------------------------->
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
: Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96)
--------------------------->
LDP Init(n/a,n/a,31)
<---------------------------
Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
This example operates much as the previous one. However, at (1),
(2), (3), (4) and (5), no acknowledgements are made.
At (6), P1 determines that graceful shutdown is required and sends a
Keepalive acknowledging all previously received messages and itself
containing an FT Protection TLV number and the FT Cork TLV.
The Label abort at (7) crosses with this Keepalive, so at (8) P2
sends a Keepalive that acknowledges all messages received so far, but
also includes the FT Protection and FT Cork TLVs to indicate that
there are still messages outstanding to be acknowledged.
P1 is then able to complete the 3-way handshake at (9) and close the
TCP session at (10).
Upon recovery at (11), there are no messages to be re-sent because
the KeepAlives flushed the acknowledgements. The only messages sent
after recovery is the Label Withdraw that was pended during the TCP
session failure.
9.5. Check-Pointing Without FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,-)
--------------------------->
(5) Label Request(L3)
--------------------------->
(6) Keepalive(n/a,-,12)
<---------------------------
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(7) Label Mapping(L3)
<---------------------------
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(8) LDP Init(n/a,n/a,23)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(9) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(10) Label Mapping(L3)
<---------------------------
(11) Label Request(L2)
<---------------------------
Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers.
(4) A check-Point request from P1. It carries the sequence number
of the check-point request.
(5) P1 immediately starts a new label distribution request.
(6) P2 confirms that it has secured all previous transactions.
(7) The subsequent (un-acknowledged) label distribution completes.
(8) The session fails and is restarted. Initialization messages
confirm the sequence numbers of the secured check-points.
(9) P1 recommences the unacknowledged label distribution request.
(10) P2 recommences an unacknowledged label distribution request.
9.6. Graceful Shutdown With Check-Pointing But No FT Procedures
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,23) * With Cork TLV *
--------------------------->
(5) :
:
:
(6) Keepalive(n/a,24,12) * With Cork TLV *
<---------------------------
(7) Keepalive(n/a,-,24) * With Cork TLV *
--------------------------->
(8) Notification(Temporary shutdown)
--------------------------->
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(10) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(11) Label Mapping(L3)
<---------------------------
(12) Label Mapping(L2)
--------------------------->
Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers.
(4) A check-point request from P1. It carries the sequence number
of the check-point request and a Cork TLV.
(5) P1 has sent a Cork TLV so quieces.
(6) P2 confirms the check-point and continues the three-way
handshake by including a Cork TLV itself.
(7) P1 completes the three-way handshake. All operations have now
been check-pointed and the session is quiesced.
(8) The session is gracefully shut down.
(9) The session recovers and the peers exchange the sequence numbers
of the last secured check-points.
(10) P1 starts a new label distribution request.
(11) P1 continues processing a previously received label distribution
request.
10. Security Considerations
The LDP FT enhancements inherit similar security considerations to
those discussed in [RFC3036].
The LDP FT enhancements allow the re-establishment of a TCP
connection between LDP peers without a full re-exchange of the
attributes of established labels, which renders LSRs that implement
the extensions specified in this document vulnerable to additional
denial-of-service attacks as follows:
- An intruder may impersonate an LDP peer in order to force a
failure and reconnection of the TCP connection, but where the
intruder does not set the FT Reconnect Flag upon re-connection.
This forces all FT labels to be released.
- Similarly, an intruder could set the FT Reconnect Flag on re-
establishment of the TCP session without preserving the state and
resources for FT labels.
- An intruder could intercept the traffic between LDP peers and
override the setting of the FT Label Flag to be set to 0 for all
labels.
All of these attacks may be countered by use of an authentication
scheme between LDP peers, such as the MD5-based scheme outlined in
[RFC3036].
Alternative authentication schemes for LDP peers are outside the
scope of this document, but could be deployed to provide enhanced
security to implementations of LDP and the LDP FT enhancements.
As with LDP, a security issue may exist if an LDP implementation
continues to use labels after expiration of the session that first
caused them to be used. This may arise if the upstream LSR detects
the session failure after the downstream LSR has released and re-used
the label. The problem is most obvious with the platform-wide label
space and could result in mis-forwarding of data to other than
intended destinations and it is conceivable that these behaviors may
be deliberately exploited to either obtain services without
authorization or to deny services to others.
In this document, the validity of the session may be extended by the
FT Reconnection Timeout, and the session may be re-established in
this period. After the expiry of the Reconnection Timeout, the
session must be considered to have failed and the same security issue
applies as described above.
However, the downstream LSR may declare the session as failed before
the expiration of its Reconnection Timeout. This increases the
period during which the downstream LSR might reallocate the label
while the upstream LSR continues to transmit data using the old usage
of the label. To reduce this issue, this document requires that
labels not be re-used until the Reconnection Timeout has expired.
A further issue might apply if labels were re-used prior to the
expiration of the FT Reconnection Timeout, but this is forbidden by
this document.
The issue of re-use of labels extends to labels managed through other
mechanisms including direct configuration through management
applications and distribution through other label distribution
protocols. Avoiding this problem may be construed as an
implementation issue (see below), but failure to acknowledge it could
result in the mis-forwarding of data between LSPs established using
some other mechanism and those recovered using the methods described
in this document.
11. Implementation Notes
11.1. FT Recovery Support on Non-FT LSRs
In order to take full advantage of the FT capabilities of LSRs in the
network, it may be that an LSR that does not itself contain the
ability to recover from local hardware or software faults still needs
to support the LDP FT enhancements described in this document.
Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant
LSR, P2. If P2 experiences a fault in the hardware or software that
serves an LDP session between P1 and P2, it may fail the TCP
connection between the peers. When the connection is recovered, the
LSPs/labels between P1 and P2 can only be recovered if both LSRs were
applying the FT recovery procedures to the LDP session.
11.2. ACK generation logic
FT ACKs SHOULD be returned to the sending LSR as soon as is
practicable in order to avoid building up a large quantity of
unacknowledged state changes at the LSR. However, immediate one-
for-one acknowledgements would waste bandwidth unnecessarily.
A possible implementation strategy for sending ACKs to FT LDP
messages is as follows:
- An LSR secures received messages in order and tracks the sequence
number of the most recently secured message, Sr.
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK
TLV listing Sr.
- Optionally, the LSR may attach an FT ACK TLV to any other LDP
message sent between Keepalive messages if, for example, Sr has
increased by more than a threshold value since the last ACK sent.
This implementation combines the bandwidth benefits of accumulating
ACKs while still providing timely ACKs.
11.2.1 Ack Generation Logic When Using Check-Pointing
If check-pointing is in use, the LSRs need not be concerned with
sending ACKs in such a timely manner.
Check-points are solicitations for acknowledgements conveyed as a
sequence number in an FT Protection TLV on a Keepalive message. Such
check-point requests could be issued on a timer, after a significant
amount of change, or before controlled shutdown of a session.
The use of check-pointing may considerably simplify an implementation
since it does not need to track the sequence numbers of all received
LDP messages. It must, however, still ensure that all received
messages (or the consequent state changes) are secured before
acknowledging the sequence number on the Keepalive.
This approach may be considered optimal in systems that do not show a
high degree of change over time (such as targeted LDP sessions) and
that are prepared to risk loss of state for the most recent LDP
exchanges. More dynamic systems (such as LDP discovery sessions) are
more likely to want to acknowledge state changes more frequently so
that the maximum amount of state can be preserved over a failure.
11.3 Interactions With Other Label Distribution Mechanisms
Many LDP LSRs also run other label distribution mechanisms. These
include management interfaces for configuration of static label
mappings, other distinct instances of LDP, and other label
distribution protocols. The last example includes the traffic
engineering label distribution protocol that is used to construct
tunnels through which LDP LSPs are established.
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
by a restarting LDP session or protocol component from being used by
another label distribution mechanism since that might compromise data
security amongst other things.
It is a matter for implementations to avoid this issue through the
use of techniques such as a common label management component or
segmented label spaces.
12. Acknowledgments
The work in this document is based on the LDP ideas expressed by the
authors of [RFC3036].
The ACK scheme used in this document was inspired by the proposal by
David Ward and John Scudder for restarting BGP sessions now included
in [BGP-RESTART].
The authors would also like to acknowledge the careful review and
comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
Peter Ashwood-Smith, Bob Thomas, S. Manikantan, Adam Sheppard,
Alan Davey, Iftekhar Hussain and Loa Andersson.
13. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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.
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information, consult the online list of claimed
rights.
14. References
14.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification, RFC3036, January
2001.
[RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful
Restart Mechanism for Label Distribution Protocol",
RFC3478, February 2003.