CCAMP Working Group Hewen Zheng Internet Draft Jixiong Dong Huawei Expires: December 2006 June 15, 2006 LMP Keep-alive Overhead Reduction Extensions draft-zheng-ccamp-lmp-keepalive-overhead-reduce-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 This Internet-Draft will expire on December 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract The Link Management Protocol (LMP) introduces one fast keep-alive mechanism. This document describes a mechanism that can be used to reduce processing overhead requirements of messages with keep-alive information, avoid that normal control messages are flooded by large numbers of Hello messages or Hello messages are flooded by large numbers of retransmitted control messages. Zheng Expires October 15, 2006 [Page 1] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 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. Table of Contents 1. Introduction.................................................2 2. Control Channel FSM Consideration............................3 3. Timers Events Extension......................................3 4. Compatibility................................................3 4.1. Capability Indicator....................................4 4.2. Capability Negotiation..................................5 5. Security Considerations......................................5 6. IANA Considerations..........................................6 7. Acknowledgments..............................................6 8. References...................................................6 8.1. Normative References....................................6 8.2. Informative References..................................6 9. Author's Addresses...........................................7 10. Intellectual Property Statement.............................7 Disclaimer of Validity..........................................7 Copyright Statement.............................................8 Acknowledgment..................................................8 1. Introduction The LMP introduces one fast keep-alive mechanism. The fast keep-alive mechanism requires updating the timer HelloDeadInterval only when receiving the Hello message from the peer and updating the timer HelloInterval in setting interval, hence the values for the HelloInterval and HelloDeadInterval should be selected carefully to provide rapid response time to control channel failures without causing congestion. When the control channel is implemented over a directly connected link, the suggested default values for the HelloInterval is 150 ms and for the HelloDeadInterval is 500 ms. As the LMP is widely applied with GMPLS is adopted, some types of control messages are introduced into the LMP [RFC4207, RFC4209], and more types of control messages will be introduced into the LMP as applications become popular. Then threats appear, large numbers of Hello messages embitter the burden of processor, those Hello messages may flood other control messages so as to those lost control messages will have to be retransmitted, on the other hand large numbers of Zheng Expires December 15, 2006 [Page 2] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 retransmitted control messages may flood Hello messages so as to the control channel is disconnected unexpectedly. Since Hello messages and other control messages (excluding Test, Config, ConfigAck and ConfigNack messages) are sent when one control channel is under Active and Up states, those other control messages can carry keep-alive information. When the LMP nodes send or receive those other control messages, it seems that the control channel is available and alive. The purpose of this document is to extend LMP to reduce keep-alive overhead through carrying keep-alive information in all control messages (except Test, Config, ConfigAck and ConfigNack messages) over one control channel, i.e., LMP node will update its timer HelloDeadInterval once it receives any control message (except Test, Config, ConfigAck, ConfigNack) from the peer, on the other hand LMP node will update its timer HelloInterval once it sends any control message (except Test, Config, ConfigAck, ConfigNack) to the peer. This mechanism will obviously reduce the amount of Hello messages that each LMP node sends and receives. 2. Control Channel FSM Consideration Though the extension in this document requires that HelloDeadInterval timer is updated upon receipt of any control message (except Test, Config, ConfigAck and ConfigNack) from LMP peer and HelloInterval timer is updated upon transmission of those control messages, the control channel FSM in RFC4204 remains unchanged because the extension does not change the state of the control channel. 3. Timers Events Extension The introduced mechanism in this document requires updating the timer HelloDeadInterval upon receiving any control message when the control channel state is Active or Up, certainly those control messages should not include Config or ConfigNack messages. At the same time, the mechanism to reduce keep-alive overhead requires updating the timer HelloInterval after sending any control message when the control channel state is Active or Up, control messages types are not limited herein. 4. Compatibility When the mechanism to reduce keep-alive overhead is adopted, the backward compatibility needs to be considered. The capability to reduce keep-alive should be negotiated. The CONFIG Class Object is Zheng Expires December 15, 2006 [Page 3] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 extended to carry the capability indicator; the extended CONFIG Class Object may appear in Config and ConfigAck messages. 4.1. Capability Indicator One sub-object is introduced into the CONFIG Class Object to indicate the capability to reduce keep-alive overhead. The extended CONFIG Class Object format is shown as below. Class = 6. o C-Type = 1, HelloConfig 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | HelloDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloInterval: 16 bits. Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms). HelloDeadInterval: 16 bits. If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. o C-Type = 2, capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: 1 bit. If R bit is set to 1 in received LMP Config message, it means Zheng Expires December 15, 2006 [Page 4] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 that the sender support and enable the capability to reduce keep- alive overhead. If R bit is reset to 0, it means that the sender does not support or enable the capability. If the fast keep-alive mechanism of LMP is not used, this sub-object should not appear. Any received message with this sub-object should be discarded silently when the fast keep-alive mechanism is not enabled. 4.2. Capability Negotiation To keep backward compatible, the capability to reduce keep-alive overhead should be not mandatory but optional. The capability is active only when both LMP peer nodes enable it. During establishing LMP relation between two nodes, if one node tells the other that it does enable the capability in the Config message, the other should ignore the capability negotiation when it does not support or enable the capability, otherwise the other should agree the capability negotiation in the positive acknowledging ConfigAck message when it does support and enable the capabilities. One CONFIG Class Object including the capability sub-object with setting R bit to indicate to support the capability should be included in the acknowledging ConfigAck message if the Config message receiver agrees the capability negotiation. During establishing LMP relation between two nodes, if one node tells the other that it does not support or enable the capability, the other should ignore the capability negotiation in the acknowledging ConfigAck message. 5. Security Considerations This document introduces no other new security considerations not covered in [RFC4204]. Zheng Expires December 15, 2006 [Page 5] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 6. IANA Considerations The document proposes one new optional sub-object in the LDP CONFIG Class Object, the type of the sub-object need to be assigned by IANA. 7. Acknowledgments The author would like to acknowledge the constructive feedback from Don Fedyk, Jonathan Lang. 8. References 8.1. Normative References [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC4204, October 2005. [RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005. [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005. 8.2. Informative References [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. Zheng Expires December 15, 2006 [Page 6] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 9. Author's Addresses Hewen Zhang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: hwzheng@huawei.com Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com 10. 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Zheng Expires December 15, 2006 [Page 7] draft-zheng-ccamp-lmp-keepalive-overhead-reduce-00.txt June 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zheng Expires December 15, 2006 [Page 8]