diff options
Diffstat (limited to 'doc/rfc/rfc3478.txt')
| -rw-r--r-- | doc/rfc/rfc3478.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3478.txt b/doc/rfc/rfc3478.txt new file mode 100644 index 0000000..7551012 --- /dev/null +++ b/doc/rfc/rfc3478.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group M. Leelanivas +Request for Comments: 3478 Y. Rekhter +Category: Standards Track Juniper Networks + R. Aggarwal + Redback Networks + February 2003 + + + Graceful Restart Mechanism for Label Distribution Protocol + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a mechanism that helps to minimize the + negative effects on MPLS traffic caused by Label Switching Router's + (LSR's) control plane restart, specifically by the restart of its + Label Distribution Protocol (LDP) component, on LSRs that are capable + of preserving the MPLS forwarding component across the restart. + + The mechanism described in this document is applicable to all LSRs, + both those with the ability to preserve forwarding state during LDP + restart and those without (although the latter needs to implement + only 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 + preserved across restart - the mechanism assumes that only the actual + MPLS forwarding state has to be preserved; the mechanism does not + require any of the LDP-related states to be preserved across the + restart. + + + + +Leelanivas, et al. Standards Track [Page 1] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + 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. + +Specification of Requirements + + 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 BCP 14, RFC 2119 + [RFC2119]. + +1. Motivation + + For the sake of brevity in the context of this document, by "the + control plane" we mean "the LDP component of the control plane". + + 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. + + In the case where a Label Switching Router (LSR) could preserve its + MPLS forwarding state across restart of its control plane, + specifically its LDP component [LDP], it is desirable not to perturb + the LSPs going through that LSR (specifically, the LSPs established + by LDP). In this document, we describe a mechanism, termed "LDP + Graceful Restart", that allows the accomplishment of this goal. + + The mechanism described in this document is applicable to all LSRs, + both those with the ability to preserve forwarding state during LDP + restart and those without (although the latter need to implement only + 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 + preserved across restart - the mechanism assumes that only the actual + MPLS forwarding state has to be preserved. Clearly this is the + minimum amount of state that has to be preserved across the restart + in order not to perturb the LSPs traversing a restarting LSR. The + mechanism does not require any of the LDP-related states to be + preserved across the restart. + + + + + +Leelanivas, et al. Standards Track [Page 2] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + In the scenario where label binding on an LSR is created/maintained + not just by the LDP component of the control plane, but by other + protocol components as well (e.g., BGP, RSVP-TE), and the LSR + supports restart of the individual components of the control plane + that create/maintain label binding (e.g., restart of LDP, but no + restart of BGP), the LSR needs to preserve across the restart the + information about which protocol has assigned which labels. + + 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. + +2. LDP Extension + + An LSR indicates that it is capable of supporting LDP Graceful + Restart, as defined in this document, by including the Fault Tolerant + (FT) Session TLV as an Optional Parameter in the LDP Initialization + message. The format of the FT Session TLV is defined in [FT-LDP]. + The L (Learn from Network) flag MUST be set to 1, which indicates + 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 + are used by the mechanisms defined in this document: FT Reconnect + Timeout, and Recovery Time. + + 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 + the receiver detects the failure of LDP communication with the + sender. While waiting, the receiver SHOULD retain the MPLS + forwarding state for the (already established) LSPs that traverse a + link between the sender and the receiver. The FT Reconnect Timeout + 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 + to the state where the sender could exchange LDP messages with its + neighbors. + + Setting the FT Reconnect Timeout to 0 indicates that the sender of + the TLV will not preserve its forwarding state across the restart, + yet the sender supports the procedures, defined in Section 3.3, + "Restart of LDP communication with a neighbor LSR" of this document, + and therefore could take advantage if its neighbor to preserve its + forwarding state across the restart. + + For a restarting LSR, the Recovery Time carries the time (in + milliseconds) the LSR is willing to retain its MPLS forwarding state + that it preserved across the restart. The time is from the moment + the LSR sends the Initialization message that carries the FT Session + + + +Leelanivas, et al. Standards Track [Page 3] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + TLV after restart. Setting this time to 0 indicates that the MPLS + forwarding state was not preserved across the restart (or even if it + was preserved, is no longer available). + + 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 + congestion in the LDP control plane. + +3. Operations + + An LSR that supports functionality described in this document + advertises this to its LDP neighbors by carrying the FT Session TLV + in the LDP Initialization message. + + This document assumes that in certain situations, as specified in + section 3.1.2, "Egress LSR", in addition to the MPLS forwarding + state, an LSR can also preserve its IP forwarding state across the + restart. Procedures for preserving an IP forwarding state across the + restart are defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP- + RESTART]. + +3.1. Procedures for the restarting LSR + + 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 + restart. If not, then the LSR sets the Recovery Time to 0 in the FT + Session TLV the LSR sends to its neighbors. + + If the forwarding state has been preserved, then the LSR starts its + internal timer, called MPLS Forwarding State Holding timer (the value + of that timer SHOULD be configurable), and marks all the MPLS + forwarding state entries as "stale". At the expiration of the timer, + all the entries still marked as stale SHOULD be deleted. The value + of the Recovery Time advertised in the FT Session TLV is set to the + (current) value of the timer at the point in which the Initialization + message carrying the FT Session TLV is sent. + + We say that an LSR is in the process of restarting when the MPLS + Forwarding State Holding timer is not expired. Once the timer + expires, we say that the LSR completed its restart. + + The following procedures apply when an LSR is in the process of + restarting. + +3.1.1. Non-egress LSR + + If the label carried in the newly received Mapping message is not an + Implicit NULL, the LSR searches its MPLS forwarding state for an + + + +Leelanivas, et al. Standards Track [Page 4] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + 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) + 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 + the entry is of type <incoming label, (outgoing label, next hop)> + (rather than <FEC, (outgoing label, next hop)>), the LSR associates + the incoming label from that entry with the FEC received in the Label + Mapping message, 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 LSR follows the normal LDP procedures. (Note + that this paragraph describes the scenario where the restarting LSR + is neither the egress, nor the penultimate hop that uses penultimate + hop popping for a particular LSP. Note also that this paragraph + covers the case where the restarting LSR is the ingress.) + + If the label carried in the Mapping message is an Implicit NULL + label, the LSR searches its MPLS forwarding state for an entry that + indicates Label pop (means no outgoing label), 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 found, the LSR no longer marks + the entry as stale, the LSR associates the incoming label from that + entry with the FEC received in the Label Mapping message from the + neighbor, 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 LSR follows the normal LDP procedures. (Note that this + paragraph describes the scenario where the restarting LSR is a + penultimate hop for a particular LSP, and this LSP uses penultimate + hop popping.) + + The description in the above paragraph assumes that the restarting + LSR generates the same label for all the LSPs that terminate on 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 generates a unique label per each such LSP, then + the LSR needs to preserve across the restart, not just the <incoming + label, (outgoing label, next hop)> mapping, but also the FEC + associated with this mapping. In such case, the LSR searches its + MPLS forwarding state for an entry that (a) indicates Label pop + (means no outgoing label), (b) indicates the next hop equal to one of + the addresses (next hops) received in the Address message from the + peer, and (c) has the same FEC as the one received in the Label + Mapping message. If such an entry is found, the LSR no longer marks + the entry as stale, the LSR associates the incoming label from that + entry with the FEC received in the Label Mapping message from the + neighbor, 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 LSR follows the normal LDP procedures. + + + + +Leelanivas, et al. Standards Track [Page 5] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + +3.1.2. Egress LSR + + 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 that + 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, the LSR searches its MPLS forwarding state for an entry that + 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 + 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 + 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 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 entry is found, the LSR follows the normal LDP procedures. + + 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 that + the LSR is configured to generate a unique label for each such FEC, + then the LSR needs to preserve across the restart, not just the + <incoming label, (outgoing label, next hop)> mapping, but also the + FEC associated with this mapping. In such case, the LSR would search + its MPLS forwarding state for an entry that indicates Label pop + (means no outgoing label), and the next hop equal to the next hop for + that FEC associated with the entry (Determining the next hop for the + FEC 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 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 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 entry is found, the LSR follows the normal LDP procedures. + + 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 + Implicit) label for that FEC, the LSR just advertises (via LDP) such + label (together with the FEC) to its neighbors. + +3.2. Alternative procedures for the restarting LSR + + In this section we describe an alternative to the procedures + described in Section 3.1, "Procedures for the restarting LSR". + + The procedures described in this section assumes that the restarting + LSR has (at least) as many unallocated as allocated labels. The + latter form the MPLS forwarding state that the LSR managed to + preserve across the restart. + + + +Leelanivas, et al. Standards Track [Page 6] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + 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 + restart. If no, then the LSR sets the Recovery Time to 0 in the FT + Session TLV the LSR sends to its neighbors. + + If the forwarding state has been preserved, then the LSR starts its + internal timer, called MPLS Forwarding State Holding timer (the value + of that timer SHOULD be configurable), and marks all the MPLS + forwarding state entries as "stale". At the expiration of the timer, + all the entries still marked as stale SHOULD be deleted. The value + of the Recovery Time advertised in the FT Session TLV is set to the + (current) value of the timer at the point when the Initialization + message carrying the FT Session TLV is sent. + + We say that an LSR is in the process of restarting when the MPLS + Forwarding State Holding timer is not expired. Once the timer + expires, we say that the LSR completed its restart. + + While an LSR is in the process of restarting, the LSR creates local + label binding by following the normal LDP procedures. + + 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 + was retained from prior to restart, and another that was created + after the restart. Once the LSR completes its restart, the former + will be deleted. Both of these bindings though would have the same + outgoing label (and the same next hop). + +3.3. Restart of LDP communication with a neighbor LSR + + 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 + forwarding state across the restart (as was indicated by the FT + Session TLV in the Initialization message received from the + neighbor), the LSR retains the label-FEC bindings received via that + session (rather than discarding the bindings), but marks them as + "stale". + + After detecting that the LDP session with the neighbor went down, the + LSR tries to re-establish LDP communication with the neighbor + following the usual LDP procedures. + + The amount of time the LSR keeps its stale label-FEC bindings is set + to the lesser of the FT Reconnect Timeout, as was advertised by the + neighbor, and a local timer, called the Neighbor Liveness Timer. If + within that time the LSR still does not establish an LDP session with + the neighbor, all the stale bindings SHOULD be deleted. The Neighbor + + + + +Leelanivas, et al. Standards Track [Page 7] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + Liveness Timer is started when the LSR detects that its LDP session + with the neighbor went down. The value of the Neighbor Liveness + timer SHOULD be configurable. + + If the LSR re-establishes an LDP session with the neighbor within the + lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer, + and the LSR determines that the neighbor was not able to preserve its + MPLS forwarding state, the LSR SHOULD immediately delete all the + stale label-FEC bindings received from that neighbor. If the LSR + determines that the neighbor was able to preserve its MPLS forwarding + state (as was indicated by the non-zero Recovery Time advertised by + the neighbor), the LSR SHOULD further keep the stale label-FEC + bindings, received from the neighbor, for as long as the lesser of + the Recovery Time advertised by the neighbor, and a local + configurable value, called Maximum Recovery Time, allows. + + The LSR SHOULD try to complete the exchange of its label mapping + information with the neighbor within 1/2 of the Recovery Time, as + specified in the FT Session TLV received from the neighbor. + + The LSR handles the Label Mapping messages received from the neighbor + by following the normal LDP procedures, except that (a) it treats the + stale entries in its Label Information Base (LIB) as if these entries + have been received over the (newly established) session, (b) if the + label-FEC binding carried in the message is the same as the one that + is present in the LIB, but is marked as stale, the LIB entry is no + longer marked as stale, and (c) if for the FEC in the label-FEC + binding carried in the message there is already a label-FEC binding + in the LIB that is marked as stale, and the label in the LIB binding + is different from the label carried in the message, the LSR just + updates the LIB entry with the new label. + + 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 + the FEC in the binding. If the route to the FEC disappears, and then + re-appears again later, this may result in using a different label + value, as when the route re-appears, the LSR would create a new + <label, FEC> binding. + + To minimize the potential mis-routing caused by the label change 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 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 the + FT Reconnect Timeout plus Recovery Time, as advertised by the + neighbor to the LSR. + + + + + +Leelanivas, et al. Standards Track [Page 8] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + +4. Security Consideration + + The security considerations pertaining to the original LDP protocol + [RFC3036] remain relevant. + + In addition, LSRs that implement the mechanism described here are + subject to 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 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 not be re-used until at least the sum of Reconnect Timeout + plus Recovery Time. + + + + + + + +Leelanivas, et al. Standards Track [Page 9] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + +5. Intellectual Property Considerations + + This section is taken from Section 10.4 of [RFC2026]. + + 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. + +6. Acknowledgments + + We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina + Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their + contributions to this document. + +7. Normative References + + [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. + and B. Thomas, "Label Distribution Protocol", RFC + 3036, January 2001. + + [FT-LDP] Farrel, A., "Fault Tolerance for the Label + Distribution Protocol (LDP)", RFC 3479, February 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Leelanivas, et al. Standards Track [Page 10] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + +8. Informative References + + [OSPF-RESTART] "Hitless OSPF Restart", Work in Progress. + + [ISIS-RESTART] "Restart signaling for ISIS", Work in Progress. + + [BGP-RESTART] "Graceful Restart Mechanism for BGP", Work in + Progress. + +9. Authors' Addresses + + Manoj Leelanivas + Juniper Networks + 1194 N. Mathilda Ave + Sunnyvale, CA 94089 + + EMail: manoj@juniper.net + + Yakov Rekhter + Juniper Networks + 1194 N. Mathilda Ave + Sunnyvale, CA 94089 + + EMail: yakov@juniper.net + + Rahul Aggarwal + Redback Networks + 350 Holger Way + San Jose, CA 95134 + + EMail: rahul@redback.com + + + + + + + + + + + + + + + + + +Leelanivas, et al. Standards Track [Page 11] + +RFC 3478 Graceful Restart Mechanism for LDP February 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Leelanivas, et al. Standards Track [Page 12] + |