Internet DRAFT - draft-zheng-ccamp-lmp-keepalive-overhead-reduce

draft-zheng-ccamp-lmp-keepalive-overhead-reduce










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]