NetLMM Working Group J.-H. Lee
Internet-Draft Sungkyunkwan University
Expires: September 3, 2008 H.-J. Lim
Korea Financial Security Agency
T.-M. Chung
Sungkyunkwan University
March 2, 2008
Heartbeat Mechanism for Local Mobility Anchors in Proxy Mobile IPv6
draft-jhlee-netlmm-heartbeatlma-01.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 September 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
Lee, et al. Expires September 3, 2008 [Page 1]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
connected with its MAGs causes the communication failure of MNs
attached to the MAGs. Thus, the early failure detection of LMA is
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. Reachability Check . . . . . . . . . . . . . . . . . . . . 5
4. Applicable Scenarios . . . . . . . . . . . . . . . . . . . . . 5
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Configuration Variables . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Lee, et al. Expires September 3, 2008 [Page 2]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
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 September 3, 2008 [Page 3]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
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 5.
Lee, et al. Expires September 3, 2008 [Page 4]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
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. Reachability Check
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. Applicable Scenarios
Several applicable scenarios are exposed where LMAs need to detect
the current reachability between them.
o Intra-reachability check: In a single PMIPv6-Domain, a number of
intra-connected LMAs are deployed for severval reasons such as
load balancing, high availability, and LMA switching. For
instance, as an LMA becomes to be exceeded its system resource
usage or tis capacity, the LMA need to take over its mobility
service for MNs to another LMA.
o Inter-reachability check: Inter-connected LMAs need to check their
reachability to provide the route optimization procedure defined
in [2] and the chaining PMIPv6-Domains. For instance, an MN can
move from one PMIPv6-Domain to other PMIPv6-Domain. In this case,
the LMA in the previous PMIPv6-Domain needs to communicate with
the LMA in the current PMIPv6-Domain to forward data packets for
Lee, et al. Expires September 3, 2008 [Page 5]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
the MN.
5. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Lee, et al. Expires September 3, 2008 [Page 6]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
6. Configuration Variables
o HEARTBEAT_LMA_INTERVAL : 30 seconds (Default)
o MISSING_HEARTBEATS_LMA_ALLOWED : 3 retransmissions (Default)
7. 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.
8. IANA Considerations
The Heartbeat message format defined in Section 5 MUST have the type
value allocated from the same space as the 'MH Type' field in the
Mobility Header defined in [6].
9. 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).
10. References
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11
(work in progress), February 2008.
[2] Liebsch, M., Le, L., and J. Abeille, "Route Optimization for
Proxy Mobile IPv6", draft-abeille-netlmm-proxymip6ro-01 (work in
progress), November 2007.
Lee, et al. Expires September 3, 2008 [Page 7]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
[3] Devarapalli, V., Lim, H., Kant, N., and S. Krishnan, "Heartbeat
Mechanism for Proxy Mobile IPv6",
draft-devarapalli-netlmm-pmipv6-heartbeat-01 (work in progress),
February 2008.
[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.
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
Korea Financial Security Agency
15F, 36-1, Yoido-dong, Youngdeungpo-gu
Seoul, 150-886
Korea
Phone: +82 02 6919 9156
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 September 3, 2008 [Page 8]
Internet-Draft Heartbeat Mechanism for LMAs March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 September 3, 2008 [Page 9]