draft-ietf-mpls-ldp-restart-02.txt   draft-ietf-mpls-ldp-restart-03.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: December 2002 Rahul Aggarwal (Redback Networks) Expiration Date: January 2003 Rahul Aggarwal (Redback Networks)
Graceful Restart Mechanism for LDP Graceful Restart Mechanism for LDP
draft-ietf-mpls-ldp-restart-02.txt draft-ietf-mpls-ldp-restart-03.txt
1. Status of this Memo 1. 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.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
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).
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
unsolicited label distribution. Extending these procedures to
downstream on demand label distribution is for further study.
3. Summary for Sub-IP Area 3. Summary for Sub-IP Area
3.1. Summary 3.1. 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.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
a subset of the mechanism described in this document). a subset of the mechanism described in this document).
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
unsolicited label distribution. Extending these procedures to
downstream on demand label distribution is for further study.
5. LDP Extension 5. 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 flag has to be set to 1. The rest of the FT flags are set to 0
by a sender and ignored on receipt. 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
skipping to change at page 4, line 30 skipping to change at page 4, line 34
6. Operations 6. Operations
For the sake of brevity in the context of this document by "the For the sake of brevity in the context of this document by "the
control plane" we mean "the LDP component of the control plane". 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 should
advertise this to its LDP neighbors by carrying the FT Session TLV in advertise this to its LDP neighbors by carrying the FT Session TLV in
the LDP Initialization message. the LDP Initialization message.
The procedures described in this document apply to downstream This document assumes that in certain situations, as specified in
unsolicited label distribution. Extending these procedures to section "Egress LSR", in addition to the MPLS forwarding state, an
downstream on demand label distribution is for further study. LSR can also preserve its IP forwarding state across the restart.
This document assumes that in addition to the MPLS forwarding state,
an 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 6.1. Procedures for the restarting LSR
For the sake of brevity in the context of this document by "MPLS For the sake of brevity in the context of this document by "MPLS
forwarding state" we mean either <incoming label -> (outgoing label, forwarding state" we mean either <incoming label -> (outgoing label,
next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)> next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)>
(ingress case) mapping. (ingress case) mapping.
skipping to change at page 5, line 23 skipping to change at page 5, line 24
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 6.1.1. Non-egress LSR
If the label carried in the Mapping message is not an Implicit NULL, If the label carried in the newly received Mapping message is not an
the LSR searches its MPLS forwarding table for an entry with the Implicit NULL, the LSR searches its MPLS forwarding table for an
outgoing label equal to the label carried in the message, and the entry with the outgoing label equal to the label carried in the
next hop equal to one of the addresses (next hops) received in the message, and the next hop equal to one of the addresses (next hops)
Address message from the peer. If such an entry is found, the LSR no received in the Address message from the peer. If such an entry is
longer marks the entry as stale. In addition, if the entry is of type found, the LSR no longer marks the entry as stale. In addition, if
<incoming label, (outgoing label, next hop)> (rather than <FEC, the entry is of type <incoming label, (outgoing label, next hop)>
(outgoing label, next hop)>), the LSR associates the incoming label (rather than <FEC, (outgoing label, next hop)>), the LSR associates
from that entry with the FEC received in the Label Mapping message, the incoming label from that entry with the FEC received in the Label
and advertises (via LDP) <incoming label, FEC> to its neighbors. If Mapping message, and advertises (via LDP) <incoming label, FEC> to
the found entry has no incoming label, or if no entry is found, the its neighbors. If the found entry has no incoming label, or if no
LSR follows the normal LDP procedures. (Note that this paragraph entry is found, the LSR follows the normal LDP procedures. (Note that
describes the scenario where the restarting LSR is neither the this paragraph describes the scenario where the restarting LSR is
egress, nor the penultimate hop that uses penultimate hop popping for neither the egress, nor the penultimate hop that uses penultimate hop
a particular LSP. Note also that this paragraph covers the case where popping for a particular LSP. Note also that this paragraph covers
the restarting LSR is the ingress.) 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 table 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
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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 9. Acknowledgments
We would like to thank Chaitanya Kodeboyina, Ina Minei, Nischal We would like to thank Chaitanya Kodeboyina, Ina Minei, Nischal
Sheth, and Enke Chen for their contributions to this document. Sheth, Enke Chen, and Adrian Farrel for their contributions to this
document.
10. Normative References 10. 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 11. Non-normative References
[OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless- [OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless-
 End of changes. 

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