Internet Engineering Task Force (IETF) V. Devarapalli, Ed.
Request for Comments: 5847 WiChorus
Category: Standards Track R. Koodli, Ed.
ISSN: 2070-1721 Cisco Systems
H. Lim
N. Kant
Stoke
S. Krishnan
J. Laganier
Qualcomm Inc.
June 2010
Internet Engineering Task Force (IETF) V. Devarapalli, Ed.
Request for Comments: 5847 WiChorus
Category: Standards Track R. Koodli, Ed.
ISSN: 2070-1721 Cisco Systems
H. Lim
N. Kant
Stoke
S. Krishnan
J. Laganier
Qualcomm Inc.
June 2010
Heartbeat Mechanism for Proxy Mobile IPv6
代理移动IPv6的心跳机制
Abstract
摘要
Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action.
代理移动IPv6（PMIPv6）是一种基于网络的移动性管理协议。代理移动IPv6协议中涉及的移动实体、移动接入网关（MAG）和本地移动锚（LMA）动态设置隧道，以管理代理移动IPv6域中移动节点的移动。本文档描述了MAG和LMA之间的心跳机制，以检测故障，在节点故障恢复时快速通知对等方，并允许对等方采取适当的行动。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5847.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5847.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . . . 3
3.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 4
3.2. Restart Detection . . . . . . . . . . . . . . . . . . . . 5
3.3. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 6
3.4. Restart Counter Mobility Option . . . . . . . . . . . . . 7
4. Exchanging Heartbeat Messages over an IPv4 Transport
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Configuration Variables . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . . . 3
3.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 4
3.2. Restart Detection . . . . . . . . . . . . . . . . . . . . 5
3.3. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 6
3.4. Restart Counter Mobility Option . . . . . . . . . . . . . 7
4. Exchanging Heartbeat Messages over an IPv4 Transport
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Configuration Variables . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Proxy Mobile IPv6 (PMIPv6) [RFC5213] enables network-based mobility for IPv6 hosts that do not implement any mobility protocols. The protocol is described in detail in [RFC5213]. In order to facilitate the network-based mobility, the PMIPv6 protocol defines a mobile access gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC3775] signaling, and the local mobility anchor (LMA), which acts similar to a home agent, anchoring a mobile node's sessions within a PMIPv6 domain. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the mobile nodes.
代理移动IPv6（PMIPv6）[RFC5213]为未实施任何移动协议的IPv6主机启用基于网络的移动。[RFC5213]中详细描述了该协议。为了促进基于网络的移动性，PMIPv6协议定义了移动接入网关（MAG），其充当移动IPv6[RFC3775]信令的代理，以及本地移动性锚（LMA），其作用类似于归属代理，在PMIPv6域内锚定移动节点的会话。LMA和MAG建立用于转发属于移动节点的所有数据业务的双向隧道。
In a distributed environment such as a PMIPv6 domain consisting of LMAs and MAGs, it is necessary for the nodes to 1) have a consistent state about each other's reachability, and 2) quickly inform peers in the event of recovery from node failures. So, when the LMA restarts after a failure, the MAG should (quickly) learn about the restart so that it can take appropriate actions (such as releasing any resources). When there are no failures, a MAG should know about the LMA's reachability (and vice versa) so that the path can be assumed to be functioning.
在分布式环境（如由LMA和MAG组成的PMIPv6域）中，节点有必要1）具有关于彼此可达性的一致状态，2）在从节点故障恢复时快速通知对等方。因此，当LMA在故障后重新启动时，MAG应该（快速）了解重新启动的情况，以便采取适当的措施（例如释放任何资源）。当没有故障时，MAG应该知道LMA的可达性（反之亦然），以便可以假定路径正常工作。
This document specifies a heartbeat mechanism between the MAG and the LMA to detect the status of reachability between them. This document also specifies a mechanism to indicate node restarts; the mechanism could be used to quickly inform peers of such restarts. The Heartbeat message is a Mobility Header message (protocol type 135) that is periodically exchanged at a configurable threshold of time or sent unsolicited soon after a node restart. This document does not specify the specific actions (such as releasing resources) that a node takes as a response to processing the Heartbeat messages.
本文件规定了MAG和LMA之间的心跳机制，以检测它们之间的可达性状态。本文件还规定了指示节点重新启动的机制；该机制可用于快速通知对等方此类重启。心跳消息是移动报头消息（协议类型135），该消息以可配置的时间阈值周期性地交换，或者在节点重新启动后不久未经请求地发送。本文档未指定节点作为处理心跳消息的响应而采取的特定操作（例如释放资源）。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The MAG and the LMA exchange Heartbeat messages every HEARTBEAT_INTERVAL seconds to detect the current status of reachability between them. The MAG initiates the heartbeat exchange to test if the LMA is reachable by sending a Heartbeat Request message to the LMA. Each Heartbeat Request contains a sequence number that is incremented monotonically. The sequence number on the last Heartbeat Request message is always recorded by the MAG, and is used to match the corresponding Heartbeat Response. Similarly, the
MAG和LMA每隔几秒钟交换一次心跳信息，以检测它们之间的当前可达性状态。MAG通过向LMA发送心跳请求消息来启动心跳交换，以测试LMA是否可访问。每个心跳请求都包含一个单调递增的序列号。最后一条心跳请求消息上的序列号始终由MAG记录，并用于匹配相应的心跳响应。同样地
LMA also initiates a heartbeat exchange with the MAG, by sending a Heartbeat Request message, to check if the MAG is reachable. The format of the Heartbeat message is described in Section 3.3.
LMA还通过发送心跳请求消息来启动与MAG的心跳交换，以检查MAG是否可访问。第3.3节描述了心跳消息的格式。
A Heartbeat Request message can be sent only if the MAG has at least one proxy Binding Cache entry at the LMA for a mobile node attached to the MAG. If there are no proxy Binding Cache entries at the LMA for any of the mobile nodes attached to the MAG, then the Heartbeat message SHOULD NOT be sent. Similarly, the LMA SHOULD NOT send a Heartbeat Request message to a MAG if there is no active Binding Cache entry created by the MAG. A PMIPv6 node MUST respond to a Heartbeat Request message with a Heartbeat Response message, irrespective of whether there is an active Binding Cache entry.
只有当MAG在LMA上至少有一个用于连接到MAG的移动节点的代理绑定缓存项时，才能发送心跳请求消息。如果LMA上没有用于连接到MAG的任何移动节点的代理绑定缓存项，则不应发送心跳消息。类似地，如果没有由MAG创建的活动绑定缓存项，LMA不应向MAG发送心跳请求消息。PMIPv6节点必须使用心跳响应消息响应心跳请求消息，而不管是否存在活动绑定缓存项。
The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than 30 seconds. Deployments should be careful in setting the value for the HEARTBEAT_INTERVAL. Sending Heartbeat messages too often may become an overhead on the path between the MAG and the LMA. It could also create congestion in the network and negatively affect network performance. The HEARTBEAT_INTERVAL can be set to a much larger value on the MAG and the LMA, if required, to reduce the burden of sending periodic Heartbeat messages.
心跳间隔不应配置为小于30秒的值。部署在设置心跳间隔值时应小心。过于频繁地发送心跳消息可能成为MAG和LMA之间路径上的开销。它还可能造成网络拥塞，并对网络性能产生负面影响。如果需要，可以在MAG和LMA上将心跳间隔设置为更大的值，以减少发送周期性心跳消息的负担。
If the LMA or the MAG do not support the Heartbeat messages, they respond with a Binding Error message with status set to 2 (unrecognized mobility header (MH) type value) as described in [RFC3775]. When the Binding Error message with status set to 2 is received in response to a Heartbeat Request message, the initiating MAG or the LMA MUST NOT use Heartbeat messages with the other end again.
如果LMA或MAG不支持心跳消息，它们会响应绑定错误消息，状态设置为2（无法识别的移动头（MH）类型值），如[RFC3775]中所述。当收到状态设置为2的绑定错误消息以响应心跳请求消息时，启动MAG或LMA不得再次使用另一端的心跳消息。
If a PMIPv6 node has detected that a peer PMIPv6 node has failed or restarted without retaining the PMIPv6 session state, it should mark the corresponding binding update list or binding cache entries as invalid. The PMIPv6 node may also take other actions, which are outside the scope of this document.
如果PMIPv6节点检测到对等PMIPv6节点发生故障或重新启动而未保留PMIPv6会话状态，则应将相应的绑定更新列表或绑定缓存项标记为无效。PMIPv6节点还可以采取本文档范围之外的其他操作。
The detection of failure and restart events may be signaled to network operators by using asynchronous notifications. Future work may define such notifications in a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module.
故障和重启事件的检测可通过使用异步通知通知网络运营商。未来的工作可能会在管理信息版本2（SMIv2）管理信息库（MIB）模块的结构中定义此类通知。
A PMIPv6 node (MAG or LMA) matches every received Heartbeat Response to the Heartbeat Request sent using the sequence number. Before sending the next Heartbeat Request, it increments a local variable
PMIPv6节点（MAG或LMA）将每个接收到的心跳响应与使用序列号发送的心跳请求相匹配。在发送下一个Heartbeat请求之前，它会增加一个局部变量
MISSING_HEARTBEAT if it has not received a Heartbeat Response for the previous request. When this local variable MISSING_HEARTBEAT exceeds a configurable parameter MISSING_HEARTBEATS_ALLOWED, the PMIPv6 node concludes that the peer PMIPv6 node is not reachable. If a Heartbeat Response message is received, the MISSING_HEARTBEATS counter is reset.
如果未收到上一个请求的心跳响应，则缺少\u心跳。当此局部变量MISSING_HEARTBEATS超过允许的可配置参数MISSING_HEARTBEATS_时，PMIPv6节点认为对等PMIPv6节点不可访问。如果收到心跳响应消息，将重置丢失的\u心跳计数器。
The section describes a mechanism for detecting failure recovery without session persistence. In the case that the LMA or the MAG crashes and reboots and loses all state with respect to the PMIPv6 sessions, it would be beneficial for the peer PMIPv6 node to discover the failure and the loss of session state and establish the sessions again.
本节描述了一种在没有会话持久性的情况下检测故障恢复的机制。在LMA或MAG崩溃、重新启动并丢失关于PMIPv6会话的所有状态的情况下，对等PMIPv6节点发现故障和会话状态丢失并再次建立会话将是有益的。
Each PMIPv6 node (both the MAG and LMA) MUST maintain a monotonically increasing Restart Counter that is incremented every time the node reboots and loses PMIPv6 session state. The counter MUST NOT be incremented if the recovery happens without losing state for the PMIPv6 sessions active at the time of failure. This counter MUST be treated as state that is preserved across reboots. A PMIPv6 node includes a Restart Counter mobility option, described in Section 3.4, in a Heartbeat Response message to indicate the current value of the Restart Counter. Each PMIPv6 node MUST also store the Restart Counter for all the peer PMIPv6 nodes with which it currently has sessions. Stored Restart Counter values for peer PMIPv6 nodes do not need to be preserved across reboots.
每个PMIPv6节点（MAG和LMA）必须保持一个单调递增的重启计数器，该计数器在节点每次重启和丢失PMIPv6会话状态时递增。如果发生故障时活动的PMIPv6会话的恢复状态未丢失，则计数器不得增加。必须将此计数器视为在重新启动期间保留的状态。PMIPv6节点在心跳响应消息中包含重启计数器移动选项，如第3.4节所述，以指示重启计数器的当前值。每个PMIPv6节点还必须为其当前具有会话的所有对等PMIPv6节点存储重启计数器。对等PMIPv6节点存储的重启计数器值不需要在重启期间保留。
The PMIPv6 node that receives the Heartbeat Response message compares the Restart Counter value with the previously received value. If the value is different, the receiving node assumes that the peer PMIPv6 node had crashed and recovered. If the Restart Counter value changes or if there was no previously stored value, the new value is stored by the receiving PMIPv6 node.
接收心跳响应消息的PMIPv6节点将重新启动计数器值与以前接收到的值进行比较。如果值不同，则接收节点假定对等PMIPv6节点已崩溃并恢复。如果重新启动计数器值发生更改或之前没有存储值，则接收PMIPv6节点将存储新值。
If a PMIPv6 node restarts and loses PMIPv6 session state, it SHOULD send an unsolicited Heartbeat Response message with an incremented Restart Counter to all the PMIPv6 nodes that had previously established PMIPv6 sessions. Note that this is possible only when the PMIPv6 node is capable of storing information about the peers across reboots. The unsolicited Heartbeat Response message allows the peer PMIPv6 nodes to quickly discover the restart. The sequence number field in the unsolicited Heartbeat Response is ignored and no response is necessary; the nodes will synchronize during the next request and response exchange.
如果PMIPv6节点重新启动并丢失PMIPv6会话状态，则它应向先前已建立PMIPv6会话的所有PMIPv6节点发送一条未经请求的心跳响应消息，该消息带有递增的重新启动计数器。请注意，只有当PMIPv6节点能够在重新启动时存储关于对等方的信息时，这才是可能的。未经请求的心跳响应消息允许对等PMIPv6节点快速发现重启。未经请求的心跳响应中的序列号字段被忽略，不需要响应；节点将在下一次请求和响应交换期间同步。
The Heartbeat message is based on the Mobility Header defined in Section 6.1 of [RFC3775]. The MH Type field in the Mobility Header indicates that it is a Heartbeat message. The value MUST be set to 13. This document does not make any other changes to the Mobility Header message. Please refer to [RFC3775] for a description of the fields in the Mobility Header message.
心跳消息基于[RFC3775]第6.1节中定义的移动报头。Mobility报头中的MH Type字段表示它是心跳消息。该值必须设置为13。本文档不对移动头消息进行任何其他更改。请参阅[RFC3775]了解移动标头消息中字段的说明。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Mobility Header Message Format
图1：移动头消息格式
The Heartbeat message follows the Checksum field in the above message. The following illustrates the message format for the Heartbeat Mobility Header message.
Heartbeat消息位于上述消息中的校验和字段之后。以下说明了心跳移动头消息的消息格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Heartbeat Message Format
图2：心跳消息格式
Reserved
含蓄的
Set to 0 and ignored by the receiver.
设置为0并被接收器忽略。
'U'
“你”
Set to 1 in Unsolicited Heartbeat Response. Otherwise, set to 0.
在未经请求的心跳响应中设置为1。否则，设置为0。
'R'
“R”
A 1-bit flag that indicates whether the message is a request or a response. When the 'R' flag is set to 0, it indicates that the Heartbeat message is a request. When the 'R' flag is set to 1, it indicates that the Heartbeat message is a response.
指示消息是请求还是响应的1位标志。当“R”标志设置为0时，表示心跳消息是一个请求。当“R”标志设置为1时，表示心跳消息是一个响应。
Sequence Number
序列号
A 32-bit sequence number used for matching the request to the reply.
用于将请求与应答匹配的32位序列号。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer that is a multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. At the time of writing this document, the Restart Counter mobility option, described in Section 3.4, is the only valid option in this message.
可变长度字段，其长度应确保完整移动报头为8个八位字节长的倍数的整数。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。在编写本文件时，第3.4节所述的重启计数器移动性选项是本信息中唯一有效的选项。
The following shows the message format for a new mobility option for carrying the Restart Counter value in the Heartbeat message. The Restart Counter mobility option is only valid in a Heartbeat Response message. It has an alignment requirement of 4n+2.
下面显示了用于在心跳消息中携带重启计数器值的新移动选项的消息格式。重启计数器移动性选项仅在心跳响应消息中有效。其对准要求为4n+2。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Restart Counter Mobility Option
图3：重启计数器移动性选项
Type
类型
An 8-bit field that indicates that it is a Restart Counter mobility option. It MUST be set to 28.
一个8位字段，指示它是一个重启计数器移动性选项。它必须设置为28。
Length
长
An 8-bit field that indicates the length of the option in octets excluding the Type and Length fields. It is set to 4.
一个8位字段，以八位字节表示选项的长度，不包括类型和长度字段。设置为4。
Restart Counter
重新启动计数器
A 32-bit field that indicates the current Restart Counter value.
指示当前重启计数器值的32位字段。
In some deployments, the network between the MAG and the LMA may be IPv4-only and not capable of routing IPv6 packets. In this case, the Mobility Header containing the Heartbeat message is carried as specified in Section 4 of [RFC5844], i.e., the Mobility Header is part of the UDP payload inside an IPv4 packet (IPv4-UDP-MH).
在某些部署中，MAG和LMA之间的网络可能仅为IPv4，不能路由IPv6数据包。在这种情况下，按照[RFC5844]第4节的规定携带包含心跳消息的移动报头，即，移动报头是IPv4数据包（IPv4 UDP MH）内UDP有效载荷的一部分。
The LMA and the MAG must allow the following variables to be configurable.
LMA和MAG必须允许配置以下变量。
HEARTBEAT_INTERVAL
心跳间隔
This variable is used to set the time interval in seconds between two consecutive Heartbeat Request messages. The default value is 60 seconds. It SHOULD NOT be set to less than 30 seconds or more than 3600 seconds.
此变量用于设置两条连续心跳请求消息之间的时间间隔（以秒为单位）。默认值为60秒。它不应设置为小于30秒或大于3600秒。
MISSING_HEARTBEATS_ALLOWED
允许缺少心跳
This variable indicates the maximum number of consecutive Heartbeat Request messages for which a PMIPv6 node did not receive a response before concluding that the peer PMIPv6 node is not reachable. The default value for this variable is 3.
此变量表示PMIPv6节点在断定对等PMIPv6节点不可访问之前未收到响应的连续心跳请求消息的最大数量。此变量的默认值为3。
The Heartbeat messages are just used for checking reachability between the MAG and the LMA. They do not carry information that is useful for eavesdroppers on the path. Therefore, confidentiality protection is not required. Integrity protection using IPsec [RFC4301] for the Heartbeat messages MUST be supported on the MAG and the LMA. RFC 5213 [RFC5213] describes how to protect the Proxy Binding Update and Acknowledgement signaling messages with IPsec. The Heartbeat message defined in this specification is merely another subtype of the same Mobility Header protocol that is already being protected by IPsec. Therefore, protecting this additional message is
心跳消息仅用于检查MAG和LMA之间的可达性。它们不携带对路径上的窃听者有用的信息。因此，不需要保密保护。MAG和LMA上必须支持对心跳消息使用IPsec[RFC4301]的完整性保护。RFC 5213[RFC5213]描述了如何使用IPsec保护代理绑定更新和确认信令消息。本规范中定义的心跳消息仅仅是同一移动报头协议的另一个子类型，该协议已经受到IPsec的保护。因此，保护此附加消息是非常必要的
possible using the mechanisms and security policy models from these RFCs. The security policy database entries should use the new MH Type, the Heartbeat message, for the MH Type selector.
可能使用这些RFC中的机制和安全策略模型。安全策略数据库条目应使用新的MH类型（心跳消息）作为MH类型选择器。
If dynamic key negotiation between the MAG and the LMA is required, Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] should be used.
如果MAG和LMA之间需要动态密钥协商，则应使用互联网密钥交换协议版本2（IKEv2）[RFC4306]。
The Heartbeat message defined in Section 3.3 must have the type value allocated from the same space as the 'MH Type' name space in the Mobility Header defined in RFC 3775 [RFC3775].
第3.3节中定义的心跳消息的类型值必须从与RFC 3775[RFC3775]中定义的移动报头中的“MH类型”名称空间相同的空间分配。
The Restart Counter mobility option defined in Section 3.4 must have the type value allocated from the same name space as the mobility options defined in RFC 3775 [RFC3775].
第3.4节中定义的重启计数器移动性选项必须具有从与RFC 3775[RFC3775]中定义的移动性选项相同的名称空间分配的类型值。
A heartbeat mechanism for a network-based mobility management protocol was first described in [NETLMM]. The authors would like to thank the members of a NETLMM design team that produced that document. The mechanism described in this document also derives from the path management mechanism described in [GTP].
基于网络的移动性管理协议的心跳机制首次在[NETLMM]中描述。作者要感谢制作该文档的NETLMM设计团队的成员。本文档中描述的机制也源自[GTP]中描述的路径管理机制。
We would like to thank Alessio Casati for first suggesting a fault handling mechanism for Proxy Mobile IPv6.
我们要感谢Alessio Casati首先提出了代理移动IPv6的故障处理机制。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[NETLMM] Levkowetz, H., Ed., Giaretta, G., Leung, K., Liebsch, M., Roberts, P., Nishida, K., Yokota, H., and M. Parthasarathy, "The NetLMM Protocol", Work in Progress, October 2006.
[NETLMM]Levkowetz，H.，Ed.，Giaretta，G.，Leung，K.，Liebsch，M.，Roberts，P.，Nishida，K.，Yokota，H.，和M.Parthasarathy，“NETLMM协议”，正在进行的工作，2006年10月。
[GTP] 3rd Generation Partnership Project, "3GPP Technical Specification 29.060 V7.6.0: "Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 7)"", July 2007.
[GTP]第三代合作伙伴项目，“3GPP技术规范29.060 V7.6.0:“技术规范组核心网络和终端”；通用分组无线业务（GPRS）；通过Gn和Gp接口的GPRS隧道协议（GTP）（第7版）”，2007年7月。
Authors' Addresses
作者地址
Vijay Devarapalli (editor) WiChorus 3950 North First Street San Jose, CA 95134 USA
Vijay Devarapalli（编辑）美国加利福尼亚州圣何塞市北第一街3950号，邮编95134
EMail: vijay@wichorus.com
EMail: vijay@wichorus.com
Rajeev Koodli (editor) Cisco Systems USA
Rajeev Koodli（编辑）美国思科系统公司
EMail: rkoodli@cisco.com
EMail: rkoodli@cisco.com
Heeseon Lim Stoke 5403 Betsy Ross Drive Santa Clara, CA 95054 USA
美国加利福尼亚州圣克拉拉市贝齐罗斯大道5403号希森林斯托克，邮编95054
EMail: hlim@stoke.com
EMail: hlim@stoke.com
Nishi Kant Stoke 5403 Betsy Ross Drive Santa Clara, CA 95054 USA
美国加利福尼亚州圣克拉拉市西坎特斯托克5403贝琪罗斯大道95054号
EMail: nishi@stoke.com
EMail: nishi@stoke.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com
Julien Laganier Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
Julien Laganier高通公司美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
EMail: julienl@qualcomm.com
EMail: julienl@qualcomm.com