Network Working Group Emily. Chen Internet Draft Huawei Technologies Co., Ltd. Expires: October 2007 June 2007 Explicit Notification for LDP-IGP Synchronization draft-chen-mpls-ldpigp-syn-accurate-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Trust (2007). Abstract A fundamental concept in Label Distribution Protocol - Interior Gateway Protocol (LDP-IGP) Synchronization is that LDP is fully established before the IGP path is switched for IP forwarding. This document proposes a mechanism to affirm the switching time accurately Emily Expires October 2007 [Page 1] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 by propagating a explicit notification from downstream. The interoperability with other Label Switched Routers (LSRs), which may not support the mechanism, is also considered. Conventions used in this document 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 [i]. Table of Contents 1. Introduction.................................................2 1.1. Background..............................................2 1.2. Problem Statement.......................................3 1.3. Overview of Proposed Solution...........................4 2. Operation of Explicit Notification...........................4 2.1. Procedure for the Sender of Explicit Notification.......4 2.2. Procedure for the Receiver of Explicit Notification.....5 3. Specification of Proposed Solution...........................5 3.1. Introduction............................................5 3.2. Determine Whether LDP is Fully Established..............6 3.3. Solution 1: Extension to Notification Message...........6 3.4. Solution 2: Extension to Label Mapping Message..........7 4. Interoperability.............................................8 5. Security Considerations......................................8 6. IANA Considerations..........................................8 7. Acknowledgments..............................................8 8. References...................................................9 8.1. Normative References....................................9 8.2. Informative References..................................9 Author's Addresses.............................................10 Intellectual Property Statement................................10 Disclaimer of Validity.........................................10 Copyright Statement............................................11 1. Introduction 1.1. Background Label Distribution Protocol (LDP) [RFC 3036] defines a set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping Emily Expires October 2007 [Page 2] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 network-layer routing information directly to data-link layer switched path. In Downstream Unsolicited advertisement mode, label mapping advertisements for all routers may be received from all LDP peers. When using liberal label retention, every label mappings received from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping. If two LSRs rely on the availability of a complete MPLS forwarding path to each other, such as in a L2VPN or L3VPN scenario, along the IP shortest path from one PE router to the other, all the links need to have operational LDP sessions and the necessary label binding must have been exchanged over those sessions. LDP-IGP synchronization should be used to make sure that LDP is fully operational before the IGP path is switched for IP forwarding . When LSPs are not all ready on a certain link, IGP will advertise the link with maximum cost to prevent any traffic transmission over it. In this case, LDP will setup session and advertise label mapping message to all LDP peers for all routes over the certain link. After LDP session is established and labels are exchanged, all the liberal LSPs will be setup, then IGP will re-advertise the link, and MPLS forwarding will be implemented over it. 1.2. Problem Statement In a MPLS L2VPN or L3VPN scenario, all the VPN traffic is forwarded through the LDP LSPs in public network. In this case, MPLS forwarding in public network should not be interrupted; otherwise all the VPN traffic would be interrupted too, which would lead to serious telecommunication problem. Thus, for the sake of maintaining MPLS forwarding capability, IGP path must not be used for IP forwarding before LDP is fully operational and all LSPs are created. In the normal solution of LDP-IGP synchronization, this can be implemented by IGP to delay some specified time to inform LDP about route change. But the delayed time is not sure, that may still result that LDP-IGP is not synchronized on time and mpls forwarding is interrupted, such as, the time to exchange label binding for two many LSPs is longer than the delayed time. Even if the delayed time is enough, it can not be expected to switch MPLS forwarding to the preferable path and avoid long occupation on not best path. Thus the switching time for LDP-IGP synchronization should be affirmed accurately to prevent any traffic from being discarded, and avoid the important traffic from being forwarded through a non- optimal path in long time even if the optimal path is operational. Emily Expires October 2007 [Page 3] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 1.3. Overview of Proposed Solution This document aims to propose a mechanism to affirm the switching time accurately. When all the labels are exchanged, the downstream LSR will propagate a explicit notification to upstream, which indicates that LDP is ready for mpls forwarding. Note that this explicit notification can be extension to some messages defined in LDP Specification [RFC 3036], such as label mapping message, notification message, etc. To interact with other LSRs which may not support the mechanism, the behavior of sending explicit notification MUST be restricted by configuration. 2. Operation of Explicit Notification When LDP is fully established and all LSPs are exchanged, a explicit notification will be propagated from downstream LSR to upstream. This section defines the operation of explicit notification in the following case: - Sender/receiver of explicit notification ; - Capability of sending/responding explicit notification . 2.1. Procedure for the Sender of Explicit Notification After LDP session is established and labels are all exchanged, a downstream LSR should check whether it has the capability of sending explicit notification , which is restricted by configuration. If a downstream LSR is configured the capability of sending explicit notification, it is responsible to determine whether LDP is fully established. The method of validation here depends on the category of explicit notification . Once the LSR confirms that all the labels are exchanged, it will construct a explicit notification and send to the upstream LSR actively. If a downstream LSR is NOT configured the capability of sending explicit notification , it does not need to determine whether LDP is fully established, nor send a explicit notification . In this case, it can be considered as a normal LSR, which only complies with the fundamental of LDP. Emily Expires October 2007 [Page 4] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 2.2. Procedure for the Receiver of Explicit Notification An upstream LSR will receive the explicit notification passively, without reference to the capability of proposed mechanism. But the procedure of dealing with the explicit notification depends on its capability of response, which is restricted by configuration. The configuration ability is recommend but not required. If an upstream LSR is configured the capability of responding explicit notification, it is responsible to switch IGP path immediately when it receives the message. To avoid the influence of missing explicit notification, maintaining a hold timer with each IGP path is recommended. The hold timer, which expires in a configured time, should be created at the beginning of LDP establishment. If a explicit notification is received, the hold timer should be deleted after responding the message successfully. If the timer expires without receipt of a explicit notification, the upstream LSR will also switch the IGP path. Note that a upstream LSR can not respond explicit notification any more after the hold timer expires, otherwise IGP path will be switched twice, which is not reasonable. If an upstream LSR is NOT configured the capability of responding explicit notification, it does not need to switch IGP path when receiving a explicit notification. To prevent MPLS forwarding from being interrupted for too long, maintaining a hold timer with each IGP path is recommend. The hold timer, which expires in a configured time, should be created at the beginning of LDP establishment. IGP path will be switched when the hold timer expires. The disadvantage of maintaining a hold timer without responding explicit notification is that, the interval of hold timer is difficult to determine, and the switching time of IGP path can not be affirmed accurately. 3. Specification of Proposed Solution As described in previous sections, a explicit notification can be extension to some messages, such as label mapping message, notification message, etc. This document specifies the solution with extending notification message , and another alternative solution with label mapping message, the above both message are defined in LDP Specification [RFC 3036]. 3.1. Introduction When establishing LSPs, an LSR will send a label mapping message to an LDP peer to advertise FEC-label bindings. After all the labels are Emily Expires October 2007 [Page 5] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 exchanged, the LSR will send a special explicit notification, which can prompt the LDP peer to switch IGP path. 3.2. Determine Whether LDP is Fully Established As the sender of explicit notification, it is responsible to determine whether LDP is fully established. The proposed solution defines two methods for validation: - All FECs have been advertised; - Maintain a Check Timer for Sending Label Mapping Messages. When establishing LSPs, an LSR will send label mapping messages according to the FECs. If the last of FECs has been advertised, it is reasonable to consider that all the FEC elements have been advertised and LDP is fully operational. If there is any FEC to be advertised, an LSR will send label mapping messages continuously. Once the LSR maintains a check timer, which expires in a configured time, it will restart the timer when sending a label mapping message. In this case, expiration of the check timer indicates that the LSR has not sent a label mapping message in a certain while. Thus it is reasonable to consider that all the FECs have been advertised when the check timer expires. 3.3. Solution 1: Extension to Notification Message LDP Specification [RFC 3036] prescribes that an LSR sends a Notification message to inform an LDP peer of a significant event. To inform the event that LDP is fully established, the Notification Message can be adopted as the explicit notification with the Status TLV defined as follows: The encoding for the Status TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Status (0x0300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Emily Expires October 2007 [Page 6] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following are the Status Code defined: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Status Data (Fully Established) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status Data: the 30-bit unsigned integer specifies the status that LDP is fully established for the explicit notification , this code point is required to be assigned by IANA. 3.4. Solution 2: Extension to Label Mapping Message As the sender of explicit notification , it is responsible to construct the message. The proposed solution defines the method to extend label mapping message, which does not go against LDP Specification [RFC 3036]: LDP Specification [RFC 3036] prescribes that FEC TLV is indispensable for a label mapping message. The FEC element encoded in the label mapping message is corresponding with the FEC to be advertised. For the reason of that the special label mapping message is not used to advertise any FEC, it does not have any FEC to correspond with. Therefore, if the receiver of the special label mapping message recognizes that FEC element is cleared, it can distinguish this message from the normal messages. The encoding for the special label mapping message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | Emily Expires October 2007 [Page 7] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the elements are the same as LDP Specification [RFC 3036], except that FEC TLV is encoded as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| FEC (0x0100) | Length (0x0020) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Interoperability To interoperate with other LSRs which do not support this mechanism, an LSR supporting this mechanism should not be configured the capability of sending a explicit notification. In this case, all the routers will act as normal LSRs, complying with the fundamentals. The configuration can prevent the communication system from any error brought by the explicit notification. 5. Security Considerations Once LDP service is destroyed over a link, the proposed mechanism will not take any effect. But in working order, this mechanism does not introduce any new weaknesses in LDP nor IGP. In fact, it is beneficial to prevent MPLS traffic from being interrupted. It can be considered as an informational extension of LDP Specification [RFC 3036] and LDP-IGP Synchronization. 6. IANA Considerations This document specifies the following which require code points assigned by IANA: - LDP Status Code code point for the status that LDP is fully established. The authors request Status Code 0x00000031. 7. Acknowledgments Thanks to Ru Liang and Mach Chen for technical contributions. Emily Expires October 2007 [Page 8] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 8. References 8.1. Normative References [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", RFC 3031, Cisco Systems, Inc., Force10 Networks, Inc., Juniper Networks, Inc., January 2001. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, " LDP Specification", RFC 3036, Nortel Networks Inc., Ennovate Networks, IBM Corp, PhotonEx Corp, Cisco Systems, Inc., January 2001. 8.2. Informative References [1] M. Jork, A. Atlas, L. Fang, "LDP IGP Synchronization", Reef Point, Google, AT&T, June 2006. [RFC3906] N. Shen, H. Smit, P., " Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, Redback Networks, October 2004. Emily Expires October 2007 [Page 9] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 Author's Addresses Emily Chen Huawei Technologies Co., Ltd. NO.5 Streat, Shangdi Information Haidian Beijing China Phone: 86-010-8283-6980 Email: chenying220@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Emily Expires October 2007 [Page 10] Internet-Draft Explicit Notification for LDP-IGP SYN June 2007 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.