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]
