draft-ietf-mpls-ldp-restart-03.txt   draft-ietf-mpls-ldp-restart-04.txt 
Network Working Group Manoj Leelanivas (Juniper Networks) Network Working Group Manoj Leelanivas (Juniper Networks)
Internet Draft Yakov Rekhter(Juniper Networks) Internet Draft Yakov Rekhter(Juniper Networks)
Expiration Date: January 2003 Rahul Aggarwal (Redback Networks) Expiration Date: March 2003 Rahul Aggarwal (Redback Networks)
Graceful Restart Mechanism for LDP Graceful Restart Mechanism for LDP
draft-ietf-mpls-ldp-restart-03.txt draft-ietf-mpls-ldp-restart-04.txt
1. Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026, except that the right to all provisions of Section 10 of RFC2026, except that the right to
produce derivative works is not granted. produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document describes a mechanism that helps to minimize the This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by Label Switch Router's negative effects on MPLS traffic caused by Label Switching Router's
(LSR's) control plane restart, and specifically by the restart of its (LSR's) control plane restart, and specifically by the restart of its
Label Distribution Protocol (LDP) component, on LSRs that are capable Label Distribution Protocol (LDP) component, on LSRs that are capable
of preserving the MPLS forwarding component across the restart. of preserving the MPLS forwarding component across the restart.
The mechanism described in this document is applicable to all LSRs, The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during LDP both those with the ability to preserve forwarding state during LDP
restart and those without (although the latter need to implement only restart and those without (although the latter need to implement only
a subset of the mechanism described in this document). a subset of the mechanism described in this document). Supporting (a
subset of) the mechanism described here by the LSRs that can not
preserve their MPLS forwarding state across the restart would not
reduce the negative impact on MPLS traffic caused by their control
plane restart, but it would minimize the impact if their neighbor(s)
are capable of preserving the forwarding state across the restart of
their control plane and implement the mechanism described here.
The mechanism makes minimalistic assumptions on what has to be The mechanism makes minimalistic assumptions on what has to be
preserved across restart - the mechanism assumes that only the actual preserved across restart - the mechanism assumes that only the actual
MPLS forwarding state has to be preserved; the mechanism does not MPLS forwarding state has to be preserved; the mechanism does not
require any of the LDP-related state to be preserved across the require any of the LDP-related state to be preserved across the
restart. restart.
The procedures described in this document apply to downstream The procedures described in this document apply to downstream
unsolicited label distribution. Extending these procedures to unsolicited label distribution. Extending these procedures to
downstream on demand label distribution is for further study. downstream on demand label distribution is for further study.
3. Summary for Sub-IP Area Specification of Requirements
3.1. Summary The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Summary for Sub-IP Area
Summary
This document describes a mechanism that helps to minimize the This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by LSR's control plane negative effects on MPLS traffic caused by LSR's control plane
restart, and specifically by the restart of its LDP component, on restart, and specifically by the restart of its LDP component, on
LSRs that are capable of preserving the MPLS forwarding component LSRs that are capable of preserving the MPLS forwarding component
across the restart. across the restart.
3.2. Related documents Related documents
See the Reference Section See the Reference Section
3.3. Where does it fit in the Picture of the Sub-IP Work Where does it fit in the Picture of the Sub-IP Work
This work fits squarely in MPLS box. This work fits squarely in MPLS box.
3.4. Why is it Targeted at this WG Why is it Targeted at this WG
The LDP is a product of the MPLS WG. This document specifies The LDP is a product of the MPLS WG. This document specifies
procedures to minimize the negative effects caused by the restart of procedures to minimize the negative effects caused by the restart of
the control plane LDP module. Since the procedures described in this the control plane LDP module. Since the procedures described in this
document are directly related to LDP, it would be logical to target document are directly related to LDP, it would be logical to target
this document at the MPLS WG. this document at the MPLS WG.
3.5. Justification Justification
The WG should consider this document, as it allows to minimize the The WG should consider this document, as it allows to minimize the
negative effects caused by the restart of the control plane LDP negative effects caused by the restart of the control plane LDP
module. module.
4. Motivation 1. Motivation
In the case where an LSR could preserve its MPLS forwarding state For the sake of brevity in the context of this document by "the
across restart of its control plane, and specifically its LDP control plane" we mean "the LDP component of the control plane".
component [LDP], it may be desirable not to perturb the LSPs going
through that LSR (and specifically, the LSPs established by LDP). In For the sake of brevity in the context of this document by "MPLS
this document, we describe a mechanism, termed "LDP Graceful forwarding state" we mean either <incoming label -> (outgoing label,
Restart", that allows to accomplish this goal. next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)>
(ingress case) mapping.
In the case where a Label Switching Router (LSR) could preserve its
MPLS forwarding state across restart of its control plane, and
specifically its LDP component [LDP], it is desirable not to perturb
the LSPs going through that LSR (and specifically, the LSPs
established by LDP). In this document, we describe a mechanism,
termed "LDP Graceful Restart", that allows to accomplish this goal.
The mechanism described in this document is applicable to all LSRs, The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during LDP both those with the ability to preserve forwarding state during LDP
restart and those without (although the latter need to implement only restart and those without (although the latter need to implement only
a subset of the mechanism described in this document). a subset of the mechanism described in this document). Supporting (a
subset of) the mechanism described here by the LSRs that can not
preserve their MPLS forwarding state across the restart would not
reduce the negative impact on MPLS traffic caused by their control
plane restart, but it would minimize the impact if their neighbor(s)
are capable of preserving the forwarding state across the restart of
their control plane and implement the mechanism described here.
The mechanism makes minimalistic assumptions on what has to be The mechanism makes minimalistic assumptions on what has to be
preserved across restart - the mechanism assumes that only the actual preserved across restart - the mechanism assumes that only the actual
MPLS forwarding state has to be preserved. Clearly this is the MPLS forwarding state has to be preserved. Clearly this is the
minimum amount of state that has to be preserved across the restart minimum amount of state that has to be preserved across the restart
in order not to perturb the LSPs traversing a restarting LSR. The in order not to perturb the LSPs traversing a restarting LSR. The
mechanism does not require any of the LDP-related state to be mechanism does not require any of the LDP-related state to be
preserved across the restart. preserved across the restart.
The procedures described in this document apply to downstream The procedures described in this document apply to downstream
unsolicited label distribution. Extending these procedures to unsolicited label distribution. Extending these procedures to
downstream on demand label distribution is for further study. downstream on demand label distribution is for further study.
5. LDP Extension 2. LDP Extension
An LSR indicates that it is capable of supporting LDP Graceful An LSR indicates that it is capable of supporting LDP Graceful
Restart, as defined in this document, by including the Fault Tolerant Restart, as defined in this document, by including the Fault Tolerant
(FT) Session TLV as an Optional Parameter in the LDP Initialization (FT) Session TLV as an Optional Parameter in the LDP Initialization
message. The format of the FT Session TLV is defined in [FT-LDP]. message. The format of the FT Session TLV is defined in [FT-LDP].
The L flag has to be set to 1. The rest of the FT flags are set to 0 The L (Learn from Network) flag MUST be set to 1, which indicates
by a sender and ignored on receipt. that the procedures in this document are used. The rest of the FT
flags are set to 0 by a sender and ignored on receipt.
The value field of the FT Session TLV contains two components that The value field of the FT Session TLV contains two components that
are used by the mechanisms defined in this document: FT Reconnect are used by the mechanisms defined in this document: FT Reconnect
Timeout, and Recovery Time. Timeout, and Recovery Time.
The FT Reconnect Timeout is the time (in milliseconds) that the The FT Reconnect Timeout is the time (in milliseconds) that the
sender of the TLV would like the receiver of that TLV to wait after sender of the TLV would like the receiver of that TLV to wait after
the receiver detects the failure of LDP communication with the the receiver detects the failure of LDP communication with the
sender. While waiting, the receiver should retain the LDP and MPLS sender. While waiting, the receiver SHOULD retain the MPLS
forwarding state for the (already established) LSPs that traverse a forwarding state for the (already established) LSPs that traverse a
link between the sender and the receiver. The FT Reconnect Timeout link between the sender and the receiver. The FT Reconnect Timeout
should be long enough to allow the restart of the control plane of should be long enough to allow the restart of the control plane of
the sender of the TLV, and specifically its LDP component to bring it the sender of the TLV, and specifically its LDP component to bring it
to the state where the sender could exchange LDP messages with its to the state where the sender could exchange LDP messages with its
neighbors. neighbors.
Setting the FT Reconnect Timeout to 0 indicates that the sender of Setting the FT Reconnect Timeout to 0 indicates that the sender of
the TLV will not preserve its forwarding state across the restart, the TLV will not preserve its forwarding state across the restart,
yet the sender supports the procedures defined in Section 6.3 of this yet the sender supports the procedures defined in Section "Restart of
document, and therefore could take advantage if its neighbor can LDP communication with a neighbor LSR" of this document, and
preserve its forwarding state across the restart. therefore could take advantage if its neighbor can preserve its
forwarding state across the restart.
For a restarting LSR the Recovery Time carries the time (in For a restarting LSR the Recovery Time carries the time (in
milliseconds) the LSR is willing to retain its MPLS forwarding state milliseconds) the LSR is willing to retain its MPLS forwarding state
that it preserved across the restart. The time is from the moment the that it preserved across the restart. The time is from the moment the
LSR sends the Initialization message that carries the FT Session TLV LSR sends the Initialization message that carries the FT Session TLV
after restart. Setting this time to 0 indicates that the MPLS after restart. Setting this time to 0 indicates that the MPLS
forwarding state wasn't preserved across the restart (or even if it forwarding state wasn't preserved across the restart (or even if it
was preserved, is no longer available). was preserved, is no longer available).
The Recovery Time should be long enough to allow the neighboring The Recovery Time SHOULD be long enough to allow the neighboring
LSR's to re-sync all the LSP's in a graceful manner, without creating LSR's to re-sync all the LSP's in a graceful manner, without creating
congestion in the LDP control plane. congestion in the LDP control plane.
6. Operations 3. Operations
For the sake of brevity in the context of this document by "the
control plane" we mean "the LDP component of the control plane".
An LSR that supports functionality described in this document should An LSR that supports functionality described in this document
advertise this to its LDP neighbors by carrying the FT Session TLV in advertises this to its LDP neighbors by carrying the FT Session TLV
the LDP Initialization message. in the LDP Initialization message.
This document assumes that in certain situations, as specified in This document assumes that in certain situations, as specified in
section "Egress LSR", in addition to the MPLS forwarding state, an section "Egress LSR", in addition to the MPLS forwarding state, an
LSR can also preserve its IP forwarding state across the restart. LSR can also preserve its IP forwarding state across the restart.
Procedures for preserving IP forwarding state across the restart are Procedures for preserving IP forwarding state across the restart are
defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-RESTART]. defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-RESTART].
6.1. Procedures for the restarting LSR 3.1. Procedures for the restarting LSR
For the sake of brevity in the context of this document by "MPLS
forwarding state" we mean either <incoming label -> (outgoing label,
next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)>
(ingress case) mapping.
After an LSR restarts its control plane, the LSR should check whether After an LSR restarts its control plane, the LSR MUST check whether
it was able to preserve its MPLS forwarding state from prior to the it was able to preserve its MPLS forwarding state from prior to the
restart. If no, then the LSR must set the Recovery Time to 0 in the restart. If no, then the LSR sets the Recovery Time to 0 in the FT
FT Session TLV the LSR sends to its neighbors. Session TLV the LSR sends to its neighbors.
If the forwarding state has been preserved, then the LSR starts its If the forwarding state has been preserved, then the LSR starts its
internal timer, called MPLS Forwarding State Holding timer (the value internal timer, called MPLS Forwarding State Holding timer (the value
of that timer should be configurable), and marks all the MPLS of that timer SHOULD be configurable), and marks all the MPLS
forwarding state entries as "stale". At the expiration of the timer, forwarding state entries as "stale". At the expiration of the timer,
all the entries still marked as stale should be deleted. The value of all the entries still marked as stale SHOULD be deleted. The value of
the Recovery Time advertised in the FT Session TLV should be set to the Recovery Time advertised in the FT Session TLV is set to the
the (current) value of the timer at the point when the Initialization (current) value of the timer at the point when the Initialization
message carrying the FT Session TLV is sent. message carrying the FT Session TLV is sent.
We say that an LSR is in the process of restarting when the MPLS We say that an LSR is in the process of restarting when the MPLS
Forwarding State Holding timer is not expired. Once the timer Forwarding State Holding timer is not expired. Once the timer
expires, we say that the LSR completed its restart. expires, we say that the LSR completed its restart.
The following procedures apply when an LSR is in the process of The following procedures apply when an LSR is in the process of
restarting. restarting.
6.1.1. Non-egress LSR 3.1.1. Non-egress LSR
If the label carried in the newly received Mapping message is not an If the label carried in the newly received Mapping message is not an
Implicit NULL, the LSR searches its MPLS forwarding table for an Implicit NULL, the LSR searches its MPLS forwarding state for an
entry with the outgoing label equal to the label carried in the entry with the outgoing label equal to the label carried in the
message, and the next hop equal to one of the addresses (next hops) message, and the next hop equal to one of the addresses (next hops)
received in the Address message from the peer. If such an entry is received in the Address message from the peer. If such an entry is
found, the LSR no longer marks the entry as stale. In addition, if found, the LSR no longer marks the entry as stale. In addition, if
the entry is of type <incoming label, (outgoing label, next hop)> the entry is of type <incoming label, (outgoing label, next hop)>
(rather than <FEC, (outgoing label, next hop)>), the LSR associates (rather than <FEC, (outgoing label, next hop)>), the LSR associates
the incoming label from that entry with the FEC received in the Label the incoming label from that entry with the FEC received in the Label
Mapping message, and advertises (via LDP) <incoming label, FEC> to Mapping message, and advertises (via LDP) <incoming label, FEC> to
its neighbors. If the found entry has no incoming label, or if no its neighbors. If the found entry has no incoming label, or if no
entry is found, the LSR follows the normal LDP procedures. (Note that entry is found, the LSR follows the normal LDP procedures. (Note
this paragraph describes the scenario where the restarting LSR is that this paragraph describes the scenario where the restarting LSR
neither the egress, nor the penultimate hop that uses penultimate hop is neither the egress, nor the penultimate hop that uses penultimate
popping for a particular LSP. Note also that this paragraph covers hop popping for a particular LSP. Note also that this paragraph
the case where the restarting LSR is the ingress.) covers the case where the restarting LSR is the ingress.)
If the label carried in the Mapping message is an Implicit NULL If the label carried in the Mapping message is an Implicit NULL
label, the LSR searches its MPLS forwarding table for an entry that label, the LSR searches its MPLS forwarding state for an entry that
indicates Label pop (means no outgoing label), and the next hop equal indicates Label pop (means no outgoing label), and the next hop equal
to one of the addresses (next hops) received in the Address message to one of the addresses (next hops) received in the Address message
from the peer. If such an entry is found, the LSR no longer marks the from the peer. If such an entry is found, the LSR no longer marks the
entry as stale, the LSR associates the incoming label from that entry entry as stale, the LSR associates the incoming label from that entry
with the FEC received in the Label Mapping message from the neighbor, with the FEC received in the Label Mapping message from the neighbor,
and advertises (via LDP) <incoming label, FEC> to its neighbors. If and advertises (via LDP) <incoming label, FEC> to its neighbors. If
the found entry has no incoming label, or if no entry is found, the the found entry has no incoming label, or if no entry is found, the
LSR follows the normal LDP procedures. (Note that this paragraph LSR follows the normal LDP procedures. (Note that this paragraph
describes the scenario where the restarting LSR is a penultimate hop describes the scenario where the restarting LSR is a penultimate hop
for a particular LSP, and this LSP uses penultimate hop popping.) for a particular LSP, and this LSP uses penultimate hop popping.)
The description in the above paragraph assumes that the restarting The description in the above paragraph assumes that the restarting
LSR generates the same label for all the LSPs that terminate on the LSR generates the same label for all the LSPs that terminate on the
same LSR (different from the restarting LSR), and for which the same LSR (different from the restarting LSR), and for which the
restarting LSR is a penultimate hop. If this is not the case, and the restarting LSR is a penultimate hop. If this is not the case, and the
restarting LSR generates a unique label per each such LSP, then the restarting LSR generates a unique label per each such LSP, then the
LSR needs to preserve across the restart not just <incoming label, LSR needs to preserve across the restart not just <incoming label,
(outgoing label, next hop)> mapping, but also the FEC associated with (outgoing label, next hop)> mapping, but also the FEC associated with
this mapping. In such case the LSR would search its MPLS forwarding this mapping. In such case the LSR searches its MPLS forwarding state
state for an entry that (a) indicates Label pop (means no outgoing for an entry that (a) indicates Label pop (means no outgoing label),
label), (b) the next hop equal to one of the addresses (next hops) (b) the next hop equal to one of the addresses (next hops) received
received in the Address message from the peer, and (c) has the same in the Address message from the peer, and (c) has the same FEC as the
FEC as the one received in the Label Mapping message. If such an one received in the Label Mapping message. If such an entry is found,
entry is found, the LSR no longer marks the entry as stale, the LSR the LSR no longer marks the entry as stale, the LSR associates the
associates the incoming label from that entry with the FEC received incoming label from that entry with the FEC received in the Label
in the Label Mapping message from the neighbor, and advertises (via Mapping message from the neighbor, and advertises (via LDP) <incoming
LDP) <incoming label, FEC> to its neighbors. If the found entry has label, FEC> to its neighbors. If the found entry has no incoming
no incoming label, or if no entry is found, the LSR follows the label, or if no entry is found, the LSR follows the normal LDP
normal LDP procedures. procedures.
6.1.2. Egress LSR 3.1.2. Egress LSR
If an LSR determines that it is an egress for a particular FEC, the If an LSR determines that it is an egress for a particular FEC, the
LSR is configured to generate a non-NULL label for that FEC, and the LSR is configured to generate a non-NULL label for that FEC, and the
LSR is configured to generate the same (non-NULL) label for all the LSR is configured to generate the same (non-NULL) label for all the
FECs that share the same next hop and for which the LSR is an egress, FECs that share the same next hop and for which the LSR is an egress,
the LSR searches its MPLS forwarding table for an entry that the LSR searches its MPLS forwarding state for an entry that
indicates Label pop (means no outgoing label), and the next hop equal indicates Label pop (means no outgoing label), and the next hop equal
to the next hop for that FEC. (Determining the next hop for the FEC to the next hop for that FEC. (Determining the next hop for the FEC
depends on the type of the FEC. For example, when the FEC is an IP depends on the type of the FEC. For example, when the FEC is an IP
address prefix, the next hop for that FEC is determined from the IP address prefix, the next hop for that FEC is determined from the IP
forwarding table.) If such an entry is found, the LSR no longer marks forwarding table.) If such an entry is found, the LSR no longer marks
this entry as stale, the LSR associates the incoming label from that this entry as stale, the LSR associates the incoming label from that
entry with the FEC, and advertises (via LDP) <incoming label, FEC> to entry with the FEC, and advertises (via LDP) <incoming label, FEC> to
its neighbors. If the found entry has no incoming label, or if no its neighbors. If the found entry has no incoming label, or if no
entry is found, the LSR follows the normal LDP procedures. entry is found, the LSR follows the normal LDP procedures.
skipping to change at page 7, line 18 skipping to change at page 8, line 5
this entry as stale, the LSR associates the incoming label from that this entry as stale, the LSR associates the incoming label from that
entry with the FEC, and advertises (via LDP) <incoming label, FEC> to entry with the FEC, and advertises (via LDP) <incoming label, FEC> to
its neighbors. If the found entry has no incoming label, or if no its neighbors. If the found entry has no incoming label, or if no
entry is found, the LSR follows the normal LDP procedures. entry is found, the LSR follows the normal LDP procedures.
If an LSR determines that it is an egress for a particular FEC, and If an LSR determines that it is an egress for a particular FEC, and
the LSR is configured to generate a NULL (either Explicit or the LSR is configured to generate a NULL (either Explicit or
Implicit) label for that FEC, the LSR just advertises (via LDP) such Implicit) label for that FEC, the LSR just advertises (via LDP) such
label (together with the FEC) to its neighbors. label (together with the FEC) to its neighbors.
6.2. Alternative procedures for the restarting LSR 3.2. Alternative procedures for the restarting LSR
In this section we describe an alternative to the procedures In this section we describe an alternative to the procedures
described in Section 6.1. described in Section "Procedures for the restarting LSR".
The procedures described in this section assumes that the restarting The procedures described in this section assumes that the restarting
LSR has (at least) as many unallocated as allocated labels. The LSR has (at least) as many unallocated as allocated labels. The
latter form the MPLS forwarding state that the LSR managed to latter form the MPLS forwarding state that the LSR managed to
preserve across the restart. preserve across the restart.
After an LSR restarts its control plane, the LSR should check whether After an LSR restarts its control plane, the LSR MUST check whether
it was able to preserve its MPLS forwarding state from prior to the it was able to preserve its MPLS forwarding state from prior to the
restart. If no, then the LSR must set the Recovery Time to 0 in the restart. If no, then the LSR sets the Recovery Time to 0 in the FT
FT Session TLV the LSR sends to its neighbors. Session TLV the LSR sends to its neighbors.
If the forwarding state has been preserved, then the LSR starts its If the forwarding state has been preserved, then the LSR starts its
internal timer, called MPLS Forwarding State Holding timer (the value internal timer, called MPLS Forwarding State Holding timer (the value
of that timer should be configurable), and marks all the MPLS of that timer SHOULD be configurable), and marks all the MPLS
forwarding state entries as "stale". At the expiration of the timer, forwarding state entries as "stale". At the expiration of the timer,
all the entries still marked as stale should be deleted. The value of all the entries still marked as stale SHOULD be deleted. The value of
the Recovery Time advertised in the FT Session TLV should be set to the Recovery Time advertised in the FT Session TLV is set to the
the (current) value of the timer at the point when the Initialization (current) value of the timer at the point when the Initialization
message carrying the FT Session TLV is sent. message carrying the FT Session TLV is sent.
We say that an LSR is in the process of restarting when the MPLS We say that an LSR is in the process of restarting when the MPLS
Forwarding State Holding timer is not expired. Once the timer Forwarding State Holding timer is not expired. Once the timer
expires, we say that the LSR completed its restart. expires, we say that the LSR completed its restart.
While an LSR is in the process of restarting, the LSR creates local While an LSR is in the process of restarting, the LSR creates local
label binding by following the normal LDP procedures. label binding by following the normal LDP procedures.
Note that while an LSR is in the process of restarting, the LSR may Note that while an LSR is in the process of restarting, the LSR may
have not one, but two local label bindings for a given FEC - one that have not one, but two local label bindings for a given FEC - one that
was retained from prior to restart, and another that was created was retained from prior to restart, and another that was created
after the restart. Once the LSR completes its restart, the former after the restart. Once the LSR completes its restart, the former
will be deleted. Both of these bindings though would have the same will be deleted. Both of these bindings though would have the same
outgoing label (and the same next hop). outgoing label (and the same next hop).
6.3. Restart of LDP communication with a neighbor LSR 3.3. Restart of LDP communication with a neighbor LSR
When an LSR detects that its LDP session with a neighbor went down, When an LSR detects that its LDP session with a neighbor went down,
and the LSR knows that the neighbor is capable of preserving its MPLS and the LSR knows that the neighbor is capable of preserving its MPLS
forwarding state across the restart (as was indicated by the FT forwarding state across the restart (as was indicated by the FT
Session TLV in the Initialization message received from the Session TLV in the Initialization message received from the
neighbor), the LSR should retain the label-FEC bindings received via neighbor), the LSR retains the label-FEC bindings received via that
that session (rather than discarding the bindings), but should mark session (rather than discarding the bindings), but marks them as
them as "stale". "stale".
After detecting that the LDP session with the neighbor went down, the After detecting that the LDP session with the neighbor went down, the
LSR should try to re-establish LDP communication with the neighbor LSR tries to re-establish LDP communication with the neighbor
following the usual LDP procedures. following the usual LDP procedures.
The amount of time the LSR should keep its stale label-FEC bindings The amount of time the LSR keeps its stale label-FEC bindings is set
is set to the lesser of the FT Reconnect Timeout, as was advertised to the lesser of the FT Reconnect Timeout, as was advertised by the
by the neighbor, and a local timer, called the Neighbor Liveness neighbor, and a local timer, called the Neighbor Liveness Timer. If
Timer. If within that time the LSR still doesn't establish an LDP within that time the LSR still doesn't establish an LDP session with
session with the neighbor, all the stale bindings should be deleted. the neighbor, all the stale bindings SHOULD be deleted. The Neighbor
The Neighbor Liveness Timer is started when the LSR detects that its Liveness Timer is started when the LSR detects that its LDP session
LDP session with the neighbor went down. The value of the Neighbor with the neighbor went down. The value of the Neighbor Liveness timer
Liveness timer should be configurable. SHOULD be configurable.
If the LSR re-establishes an LDP session with the neighbor within the If the LSR re-establishes an LDP session with the neighbor within the
lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer, lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer,
and the LSR determines that the neighbor was not able to preserve its and the LSR determines that the neighbor was not able to preserve its
MPLS forwarding state, the LSR should immediately delete all the MPLS forwarding state, the LSR SHOULD immediately delete all the
stale label-FEC bindings received from that neighbor. If the LSR stale label-FEC bindings received from that neighbor. If the LSR
determines that the neighbor was able to preserve its MPLS forwarding determines that the neighbor was able to preserve its MPLS forwarding
state (as was indicated by the non-zero Recovery Time advertised by state (as was indicated by the non-zero Recovery Time advertised by
the neighbor), the LSR should further keep the stale label-FEC the neighbor), the LSR SHOULD further keep the stale label-FEC
bindings received from the neighbor for as long as the lesser of the bindings received from the neighbor for as long as the lesser of the
Recovery Time, advertised by the neighbor, and a local configurable Recovery Time, advertised by the neighbor, and a local configurable
value, called Maximum Recovery Time. value, called Maximum Recovery Time.
The LSR should try to complete the exchange of its label mapping The LSR SHOULD try to complete the exchange of its label mapping
information with the neighbor within 1/2 of the Recovery Time, as information with the neighbor within 1/2 of the Recovery Time, as
specified in the FT Session TLV received from the neighbor. specified in the FT Session TLV received from the neighbor.
The LSR should handle the Label Mapping messages received from the The LSR handles the Label Mapping messages received from the neighbor
neighbor by following the normal LDP procedures, except that (a) it by following the normal LDP procedures, except that (a) it treats the
should treat the stale entries in its Label Information Base (LIB), stale entries in its Label Information Base (LIB), as if these
as if these entries have been received over the (newly established) entries have been received over the (newly established) session, (b)
session, (b) if the label-FEC binding carried in the message is the if the label-FEC binding carried in the message is the same as the
same as the one that is present in the LIB, but is marked as stale, one that is present in the LIB, but is marked as stale, the LIB entry
the LIB entry should no longer be marked as stale, and (c) if for the no longer is marked as stale, and (c) if for the FEC in the label-FEC
FEC in the label-FEC binding carried in the message there is already binding carried in the message there is already a label-FEC binding
a label-FEC binding in the LIB that is marked as stale, and the label in the LIB that is marked as stale, and the label in the LIB binding
in the LIB binding is different from the label carried in the is different from the label carried in the message, the LSR just
message, the LSR should just update the LIB entry with the new label. updates the LIB entry with the new label.
An LSR, once it creates a <label, FEC> binding, should keep the value An LSR, once it creates a <label, FEC> binding, SHOULD keep the value
of the label in this binding for as long as the LSR has a route to of the label in this binding for as long as the LSR has a route to
the FEC in the binding. If the route to the FEC disappears, and then the FEC in the binding. If the route to the FEC disappears, and then
re-appears again later, then this may result in using a different re-appears again later, then this may result in using a different
label value, as when the route re-appears, the LSR would create a new label value, as when the route re-appears, the LSR would create a new
<label, FEC> binding. <label, FEC> binding.
To minimize the potential mis-routing caused by the label change, To minimize the potential mis-routing caused by the label change,
when creating a new <label, FEC> binding the LSR should pick up the when creating a new <label, FEC> binding the LSR SHOULD pick up the
least recently used label. Once an LSR releases a label, the LSR least recently used label. Once an LSR releases a label, the LSR
should not re-use this label for advertising a <label, FEC> binding SHOULD NOT re-use this label for advertising a <label, FEC> binding
to a neighbor that supports graceful restart for at least the sum of to a neighbor that supports graceful restart for at least the sum of
FT Reconnect Timeout plus Recovery Time, as advertised by the FT Reconnect Timeout plus Recovery Time, as advertised by the
neighbor to the LSR. neighbor to the LSR.
7. Security Consideration 4. Security Consideration
This document does not introduce new security issues. The security The security considerations pertaining to the original LDP protocol
considerations pertaining to the original LDP protocol remain [RFC3036] remain relevant.
relevant.
8. Intellectual Property Considerations In addition, the mechanism described here renders LSRs that implement
it 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 sets the Recovery Time to 0 on reconnection. This forces
all labels received from the peer to be released.
An intruder could intercept the traffic between LDP peers and
override the setting of the Recovery Time to be set to 0. This
forces all labels received from the peer to be released.
All of these attacks may be countered by use of an authentication
scheme between LDP peers, such as the MD5- based scheme outlined in
[LDP].
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-routing 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
Reconnect 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 are not re-used until for at least the sum of Reconnect
Timeout plus Recovery Time.
5. Intellectual Property Considerations
Juniper Networks, Inc. is seeking patent protection on some or all of Juniper Networks, Inc. is seeking patent protection on some or all of
the technology described in this Internet-Draft. If technology in the technology described in this Internet-Draft. If technology in
this document is adopted as a standard, Juniper Networks agrees to this document is adopted as a standard, Juniper Networks agrees to
license, on reasonable and non-discriminatory terms, any patent license, on reasonable and non-discriminatory terms, any patent
rights it obtains covering such technology to the extent necessary to rights it obtains covering such technology to the extent necessary to
comply with the standard. comply with the standard.
Redback Networks, Inc. is seeking patent protection on some of the Redback Networks, Inc. is seeking patent protection on some of the
technology described in this Internet-Draft. If technology in this technology described in this Internet-Draft. If technology in this
document is adopted as a standard, Redback Networks agrees to document is adopted as a standard, Redback Networks agrees to
license, on reasonable and non-discriminatory terms, any patent license, on reasonable and non-discriminatory terms, any patent
rights it obtains covering such technology to the extent necessary to rights it obtains covering such technology to the extent necessary to
comply with the standard. comply with the standard.
9. Acknowledgments 6. Acknowledgments
We would like to thank Chaitanya Kodeboyina, Ina Minei, Nischal We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina
Sheth, Enke Chen, and Adrian Farrel for their contributions to this Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their
document. contributions to this document.
10. Normative References 7. Normative References
[LDP] "Label Distribution Protocol", RFC3036 [LDP] "Label Distribution Protocol", RFC3036
[FT-LDP] "Fault Tolerance for LDP and CR-LDP", work in progress [FT-LDP] "Fault Tolerance for LDP and CR-LDP", work in progress
11. Non-normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Non-normative References
[OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless- [OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless-
restart-01.txt restart-01.txt
[ISIS-RESTART] "Restart signaling for ISIS", draft-ietf-isis- [ISIS-RESTART] "Restart signaling for ISIS", draft-ietf-isis-
restart-01.txt restart-01.txt
[BGP-RESTART] "Graceful Restart Mechanism for BGP", draft-ietf-idr- [BGP-RESTART] "Graceful Restart Mechanism for BGP", draft-ietf-idr-
restart-03.txt restart-03.txt
12. Author Information 9. Author Information
Manoj Leelanivas Manoj Leelanivas
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: manoj@juniper.net e-mail: manoj@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
 End of changes. 

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