--- 1/draft-ietf-mpls-ldp-ft-05.txt 2006-02-05 00:40:14.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-ft-06.txt 2006-02-05 00:40:14.000000000 +0100 @@ -1,18 +1,18 @@ MPLS Working Group Editor Internet Draft Adrian Farrel -Document: draft-ietf-mpls-ldp-ft-05.txt Movaz Networks, Inc. +Document: draft-ietf-mpls-ldp-ft-06.txt Movaz Networks, Inc. Expiration Date: March 2003 September 2002 Fault Tolerance for the Label Distribution Protocol (LDP) - draft-ietf-mpls-ldp-ft-05.txt + draft-ietf-mpls-ldp-ft-06.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute @@ -102,34 +102,35 @@ 8.4. FT ACK TLV 31 8.5. FT Cork TLV 33 9. Example Use 34 9.1. Session Failure and Recovery - FT Procedures 35 9.2. Use of Check-Pointing With FT Procedures 37 9.3. Temporary Shutdown With FT Procedures 39 9.4. Temporary Shutdown With FT Procedures and Check-Pointing 41 9.5. Checkpointing Without FT Procedures 43 9.6. Graceful Shutdown With Checkpointing But No FT Procedures 45 10. Security Considerations 46 - 11. Implementation Notes 47 - 11.1. FT Recovery Support on Non-FT LSRs 47 + 11. Implementation Notes 48 + 11.1. FT Recovery Support on Non-FT LSRs 48 11.2. ACK generation logic 48 11.2.1 Ack Generation Logic When Using Check-Pointing 48 + 11.3 Interactions With Other Label Distribution Mechanisms 49 12. Acknowledgments 49 - 13. Intellectual Property Consideration 49 - 14. Full Copyright Statement 49 + 13. Intellectual Property Consideration 50 + 14. Full Copyright Statement 50 15. IANA Considerations 50 - 15.1. New TLVs 50 + 15.1. New TLVs 51 15.2. New Status Codes 51 - 16. Authors' Addresses 51 + 16. Authors' Addresses 52 17. References 52 17.1. Normative References 52 - 17.2. Informative References 52 + 17.2. Informative References 53 1. Conventions and Terminology used in this document Definitions of key words and terms applicable to LDP and CR-LDP are inherited from [RFC3212] and [RFC3036]. The term "FT Label" is introduced in this document to indicated a label for which some fault tolerant operation is used. A "non-FT Label" is not fault tolerant and is handled as specified in [RFC3036]. @@ -2242,21 +2243,21 @@ outside the scope of this draft, 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-routing of data + 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 draft, 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 @@ -2268,20 +2269,29 @@ might reallocate the label while the upstream LSR continues to transmit data using the old usage of the label. To reduce this issue, this draft requires that labels are not 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 draft. + 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 contrued as an + implementation issue (see below) but failure to acknowledge it could + result in 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 draft. @@ -2338,20 +2348,39 @@ 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 traffic engineering + label distribution protocol that are 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 draft is based on the LDP ideas expressed by the authors of [RFC3036]. The ACK scheme used in this draft 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 @@ -2425,42 +2454,40 @@ the 0x05xx range for TLVs that is used in [RFC3036] by other TLVs carrying session-wide attributes. The next available value in this range is 0x0503. The FT Protection TLV may ACK many label operations at once if cumulative ACKS are used. It is taken from the 0x05xx range for TLVs that is used in [RFC3036] by other TLVs carrying session-wide attributes. The next available value in this range is 0x0504. - The FT Cork TLV carries attributes that apply to all - labels exchanged between LDP peers. It is taken from the - 0x05xx range for TLVs that is used in [RFC3036] by other - TLVs carrying label attributes. The next available value - in this range is 0x0505. + The FT Cork TLV carries attributes that apply to all labels + exchanged between LDP peers. It is taken from the 0x05xx range + for TLVs that is used in [RFC3036] by other TLVs carrying label + attributes. The next available value in this range is 0x0505. In summary: FT Protection TLV 0x0203 FT Session TLV 0x0503 FT Ack TLV 0x0504 FT Cork TLV 0x0505 15.2. New Status Codes LDP status codes are not sub-divided into specific ranges for different types of error. Hence, the numeric status code values are selected as the next available. - Section 7.1 lists the new status codes required by this - draft and gives interpretative information. The new - codes are as follows. + Section 7.1 lists the new status codes required by this document and + gives interpretative information. The new codes are as follows. 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 @@ -2510,22 +2537,22 @@ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036, January 2001. [LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for - LDP, draft-ietf-ldp-restart-02.txt, June 2002, work in - progress. + LDP, draft-ietf-ldp-restart-05.txt, September 2002, + work in progress. 17.2. Informative References [RFC2205] Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification, RFC 2205, September 1997. [RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions, RFC 2961, April 2001.