NetLMM Working Group J.-H. Lee Internet-Draft H.-J. Lim Expires: March 3, 2008 T.-M. Chung Sungkyunkwan University August 31, 2007 Heartbeat Mechanism for Local Mobility Anchors in Proxy Mobile IPv6 draft-jhlee-netlmm-heartbeatlma-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 March 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Proxy Mobile IPv6 (PMIPv6) introduces new mobility entities: the local mobility anchor (LMA) and the mobile access gateway (MAG). The LMA and MAG manage bi-directional tunnels between themselves to provide a network-based mobility service to mobile nodes (MNs) within a Proxy Mobile IPv6 Domain (PMIPv6-Domain). The failure of LMA connected with its MAGs causes the communication failure of MNs attached to the MAGs. Thus, the early failure detection of LMA is Lee, et al. Expires March 3, 2008 [Page 1] Internet-Draft Heartbeat Mechanism for LMAs August 2007 desirable for appropriate countermeasures. This document specifies a heartbeat mechanism for LMAs to detect the current reachability between the LMAs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Heartbeat Mechanism for Local Mobility Anchors . . . . . . . . 4 3.1. Sending the Heartbeat message . . . . . . . . . . . . . . . 4 3.2. Receiving the Heartbeat message . . . . . . . . . . . . . . 5 3.3. Failure Detection . . . . . . . . . . . . . . . . . . . . . 5 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Configuration Variables . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Lee, et al. Expires March 3, 2008 [Page 2] Internet-Draft Heartbeat Mechanism for LMAs August 2007 1. Introduction PMIPv6 provides a network-based mobility service for MNs without any mobility support stacks [1]. The introduced LMA and MAG maintain bi- directional tunnels between them. All traffic from/to an MN attached to the MAG is forwarded via the LMA because the LMA is the topological anchor point for the MN in a PMIPv6-Domain. Also, the LMA acts as the home agent (HA) for the MN. For such reasons, multiple LMAs are deployed in a single PMIPv6-Domain in order to provide the mobility service continuously even though one of LMAs becomes a failure of serving the network-based mobility service. There are a number of reasons for which an LMA will be failed or crashed. For instance, if an LMA has exceeded its system resource usage or its capacity, then the LMA is failed or crashed. In such cases, the task of crashed LMA should be taken over or changed to another LMA existing in the same PMIPv6-Domain as soon as possible. In addition, the reachability check for LMAs existing in the different PMIPv6-Domains is also desirable for the route optimization procedure defined in [2]. Note that the reachability check mechanism for the LMA and the MAGs is defined in [3]. This document specifies a heartbeat mechanism for LMAs to detect the current reachability between them. The proposed heartbeat mechanism defines the Heartbeat messages, which are exchanged between the LMAs periodically, and the operations. 2. Conventions & Terminology 2.1. 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 [4]. 2.2. Terminology o Intra-connected LMAs: The connected LMAs in the same PMIPv6- Domain. o Inter-connected LMAs: The connected LMAs in the different PMIPv6- Domains. o Inquiring LMA: The LMA sending the Heartbeat Request message to detect the current reachability of other LMAs. Lee, et al. Expires March 3, 2008 [Page 3] Internet-Draft Heartbeat Mechanism for LMAs August 2007 o Corresponding LMA: The LMA sending the Heartbeat Response message to the inquiring LMA to inform its current reachability. 3. Heartbeat Mechanism for Local Mobility Anchors The heartbeat mechanism for LMAs is used to detect the current reachability between them. To check the reachability, the Heartbeat messages, which are consisted of Heartbeat Request message and Heartbeat Response message, are periodically exchanged between the LMAs. The Heartbeat messages are sent every HEARTBEAT_LMA_INTERVAL seconds and MISSING_HEARTBEATS_LMA_ALLOWED is used to detect the unreachability or failure. For instance, if an inquiring LMA does not receive the Heartbeat message more than MISSING_HEARTBEATS_LMA_ALLOWED times from a corresponding LMA, the inquiring LMA concludes that the corresponding LMA is not reachable. 3.1. Sending the Heartbeat message An inquiring LMA sends a Heartbeat Request message to the other LMAs listed its LMA list. The Heartbeat Request message includes the Sequence Number field and the Heartbeat Interval field. The inquiring LMA always records the sequence number and the heartbeat interval value included in the Heartbeat Request message when it sends the Heartbeat Request message. The sequence number is used for matching the request to the response. If the inquiring LMA receives the unmatched response from the corresponding LMA, the inquiring LMA ignores the response. The heartbeat interval value indicates how often the inquiring LMA sends the Heartbeat Request message to the corresponding LMA. If the corresponding LMA sends the modified heartbeat interval value in the Heartbeat Response message to the inquiring LMA, the inquiring LMA modifies the HEARTBEAT_LMA_INTERVAL for the corresponding LMA. The Heartbeat Request message should be constructed as shown below. IPv6 header (src=LMA-1, dst=LMA-2) Mobility Header -Heartbeat The address of inquiring LMA (LMA-1) is presented in the source address field and the address of corresponding LMA (LMA-2) is presented in the destination address field in the IPv6 header, respectively. The detail Heartbeat message format is described in Section 4. Lee, et al. Expires March 3, 2008 [Page 4] Internet-Draft Heartbeat Mechanism for LMAs August 2007 3.2. Receiving the Heartbeat message As a response of the Heartbeat Request message, the corresponding LMA sends a Heartbeat Response message. When the corresponding LMA sends the Heartbeat Response message to the inquiring LMA, the sequence number and the heartbeat interval value are copied from the Heartbeat Request message. The heartbeat interval value in the Heartbeat Response message MAY be adjusted for several management reasons. The Heartbeat Response message should be constructed as shown below. IPv6 header (src=LMA-2, dst=LMA-1) Mobility Header -Heartbeat The address of inquiring LMA (LMA-1) is presented in the destination address field and the address of corresponding LMA (LMA-2) is presented in the source address field in the IPv6 header, respectively. 3.3. Failure Detection The inquiring LMA expects that the corresponding LMA responds by sending the Heartbeat Response message in the HEARTBEAT_LMA_INTERVAL seconds. If the inquiring LMA cannot receive more than MISSING_HEARTBEATS_LMA_ALLOWED times from the corresponding LMA, the inquiring LMA is convinced that the corresponding LMA cannot be reachable. 4. Message Format The following message format is the Heartbeat Mobility Header. The 'MH Type' field in the format indicates that it is a Heartbeat message used for LMAs to detect the current reachability between them. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires March 3, 2008 [Page 5] Internet-Draft Heartbeat Mechanism for LMAs August 2007 Type A 8-bit field that indicates whether the message is a request or a response. A value of '1' indicates that it is a request for Intra-connected LMAs. A value of '2' indicates that it is a response for Intra-connected LMAs. A value of '3' indicates that it is a request for Inter-connected LMAs. A value of '4' indicates that it is a response for Inter-connected LMAs. Reserved A 8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Sequence Number A 32-bit sequence number used for matching the request to the response. Heartbeat Interval A 32-bit value indicating the interval in seconds between two consecutive Heartbeat messages. 5. Configuration Variables o HEARTBEAT_LMA_INTERVAL : 30 seconds (Default) o MISSING_HEARTBEATS_LMA_ALLOWED : 3 retransmissions (Default) 6. Security Considerations Similar to [3], the Heartbeat messages for LMAs do not carry sensitive information for eavesdroppers on the communication path. However, to guarantee the integrity of Heartbeat messages, the integrity protection by IPsec MUST be supported on the communication path [5]. The use of encryption is optional. In particular, the communication path for inter-LMAs is recommended to support confidentiality protection by IPsec. 7. IANA Considerations The Heartbeat message format defined in Section 4 MUST have the type value allocated from the same space as the 'MH Type' field in the Lee, et al. Expires March 3, 2008 [Page 6] Internet-Draft Heartbeat Mechanism for LMAs August 2007 Mobility Header defined in [6]. 8. Acknowledgment This document includes lots of text from [3]. Thus, the authors are acknowledged. We would like to specially thank Vijay Devarapalli, Joong-Hee Lee, and Byung-Jin Han for their valuable review and comments of this document. Comments are solicited and should be addressed to NetLMM working group's mailing list at netlmm@ietf.org and/or the authors. This study was supported by a grant of the Korea Health 21 R&D Project, Ministry of Health & Welfare, Republic of Korea (02-PJ3-PG6- EV08-0001). 9. References [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-01 (work in progress), June 2007. [2] Abeille, J. and M. Liebsch, "Route Optimization for Proxy Mobile IPv6", draft-abeille-netlmm-proxymip6ro-00 (work in progress), May 2007. [3] Devarapalli, V., "Heartbeat Mechanism for Proxy Mobile IPv6", draft-devarapalli-netlmm-pmipv6-heartbeat-00 (work in progress), August 2007. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Lee, et al. Expires March 3, 2008 [Page 7] Internet-Draft Heartbeat Mechanism for LMAs August 2007 Authors' Addresses Jong-Hyouk Lee Sungkyunkwan University 26316, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7222 Email: jhlee@imtl.skku.ac.kr; jonghyouk@gmail.com Hyung-Jin Lim Sungkyunkwan University 27302, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7222 Email: hjlim@imtl.skku.ac.kr Tai-Myoung Chung Sungkyunkwan University 27328, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7131 Email: tmchung@ece.skku.ac.kr Lee, et al. Expires March 3, 2008 [Page 8] Internet-Draft Heartbeat Mechanism for LMAs August 2007 Full 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. 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 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires March 3, 2008 [Page 9]