Network Working Group K. El Malki, Ed.
Request for Comments: 4881 Athonet
Category: Experimental June 2007
Network Working Group K. El Malki, Ed.
Request for Comments: 4881 Athonet
Category: Experimental June 2007
Low-Latency Handoffs in Mobile IPv4
移动IPv4中的低延迟切换
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.
移动IPv4描述移动节点如何在由不同外部代理服务的子网之间执行IPv4层切换。在某些情况下，这些切换涉及的延迟可能高于支持延迟敏感或实时服务所需的阈值。本文档的目的是介绍两种实现低延迟移动IPv4切换的方法。此外，还描述了这两种方法的组合。所描述的技术通过最小化移动节点由于移动IPv4注册过程中的延迟而无法发送或接收IPv4分组的时间段，允许对移动IPv4网络上的实时服务的更大支持。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. The Techniques .............................................5
1.3. L2 Triggers ................................................7
1.4. Requirements Language ......................................9
2. Requirements ....................................................9
3. The PRE-REGISTRATION Handoff Method ............................10
3.1. Operation .................................................11
3.2. Network-Initiated Handoff .................................13
3.3. Mobile-Initiated Handoff ..................................15
3.4. Obtaining and Proxying nFA Advertisements .................17
3.4.1. Inter-FA Solicitation ..............................17
3.4.2. Tunneled nFA Advertisements ........................18
3.5. Caching Router Advertisements .............................19
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. The Techniques .............................................5
1.3. L2 Triggers ................................................7
1.4. Requirements Language ......................................9
2. Requirements ....................................................9
3. The PRE-REGISTRATION Handoff Method ............................10
3.1. Operation .................................................11
3.2. Network-Initiated Handoff .................................13
3.3. Mobile-Initiated Handoff ..................................15
3.4. Obtaining and Proxying nFA Advertisements .................17
3.4.1. Inter-FA Solicitation ..............................17
3.4.2. Tunneled nFA Advertisements ........................18
3.5. Caching Router Advertisements .............................19
3.6. Movement Detection, MN, and FA Considerations .............19
3.7. L2 Address Considerations .................................21
3.8. Applicability of PRE-REGISTRATION Handoff .................21
4. The POST-REGISTRATION Handoff Method ...........................23
4.1. Two-Party Handoff .........................................24
4.2. Three-Party Handoff .......................................28
4.3. Renewal or Termination of Tunneling Service ...............34
4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
4.5. Handoff Request (HRqst) Message Format ....................36
4.6. Handoff Reply (HRply) Message Format ......................38
4.7. Handoff to Third (HTT) Message Format .....................40
4.8. Applicability of POST-REGISTRATION Handoff Method .........40
5. Combined Handoff Method ........................................41
6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
7. Reverse Tunneling Support ......................................42
8. Handoff Signaling Failure Recovery .............................43
8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
8.1.1. Failure of PrRtSol and PrRtAdv .....................43
8.1.2. Failure of Inter-FA Solicitation and
Advertisement ......................................44
8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
8.2.1. HRqst Message Dropped ..............................44
8.2.2. HRply Message Dropped ..............................45
9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
9.1. 3GPP2 IMSI Link Layer Address and Connection ID
Extension .................................................47
9.2. 3GPP IMSI Link Layer Address Extension ....................48
9.3. Ethernet Link Layer Address Extension .....................49
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
9.5. Solicited IPv4 Address Extension ..........................51
9.6. Access Point Identifier Extension .........................52
9.7. FA IPv4 Address Extension .................................53
10. IANA Considerations ...........................................53
10.1. New Extension Values .....................................53
10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
10.3. New Message Type and Code ................................54
11. Security Considerations .......................................55
12. Acknowledgements ..............................................57
13. References ....................................................57
13.1. Normative References .....................................57
13.2. Informative References ...................................58
Appendix A - Gateway Foreign Agents................................59
Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
Appendix C - PRE_REGISTRATION Message Summary......................61
3.6. Movement Detection, MN, and FA Considerations .............19
3.7. L2 Address Considerations .................................21
3.8. Applicability of PRE-REGISTRATION Handoff .................21
4. The POST-REGISTRATION Handoff Method ...........................23
4.1. Two-Party Handoff .........................................24
4.2. Three-Party Handoff .......................................28
4.3. Renewal or Termination of Tunneling Service ...............34
4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
4.5. Handoff Request (HRqst) Message Format ....................36
4.6. Handoff Reply (HRply) Message Format ......................38
4.7. Handoff to Third (HTT) Message Format .....................40
4.8. Applicability of POST-REGISTRATION Handoff Method .........40
5. Combined Handoff Method ........................................41
6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
7. Reverse Tunneling Support ......................................42
8. Handoff Signaling Failure Recovery .............................43
8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
8.1.1. Failure of PrRtSol and PrRtAdv .....................43
8.1.2. Failure of Inter-FA Solicitation and
Advertisement ......................................44
8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
8.2.1. HRqst Message Dropped ..............................44
8.2.2. HRply Message Dropped ..............................45
9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
9.1. 3GPP2 IMSI Link Layer Address and Connection ID
Extension .................................................47
9.2. 3GPP IMSI Link Layer Address Extension ....................48
9.3. Ethernet Link Layer Address Extension .....................49
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
9.5. Solicited IPv4 Address Extension ..........................51
9.6. Access Point Identifier Extension .........................52
9.7. FA IPv4 Address Extension .................................53
10. IANA Considerations ...........................................53
10.1. New Extension Values .....................................53
10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
10.3. New Message Type and Code ................................54
11. Security Considerations .......................................55
12. Acknowledgements ..............................................57
13. References ....................................................57
13.1. Normative References .....................................57
13.2. Informative References ...................................58
Appendix A - Gateway Foreign Agents................................59
Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
Appendix C - PRE_REGISTRATION Message Summary......................61
Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4- layer handoff between subnets served by different Foreign Agents (FAs). In certain cases, the latency involved in handoff can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two techniques to achieve low-latency Mobile IPv4 handoff during movement between FAs. A further combination of these two techniques is also described. The presented techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time during which an MN is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. One or more of these techniques may be required to achieve fast Mobile IPv4 handoffs over different wireless technologies (e.g., WLAN, Cellular, WiMAX, Flash-OFDM, etc.). Each wireless technology has different layer 2 handoff procedures, and the best low-latency technique for each scenario should be used to optimize the handoff performance. Further deployment and experimentation are required to determine which technique is best suited to the wireless technologies in terms of implementation and performance. Therefore, the authors encourage further performance measurements and work on low-latency-over-foo specifications in collaboration with the appropriate wireless technology fora to describe the applicability to different wireless layer 2s.
移动IPv4[1]描述了移动节点（MN）如何在由不同外部代理（FAs）服务的子网之间执行IPv4层切换。在某些情况下，切换所涉及的延迟可能高于支持延迟敏感或实时服务所需的阈值。本文档的目的是介绍两种在FAs之间移动期间实现低延迟移动IPv4切换的技术。还描述了这两种技术的进一步组合。所提出的技术通过最小化MN由于移动IPv4注册过程中的延迟而无法发送或接收IPv4分组的时间段，允许对移动IPv4网络上的实时服务的更大支持。可能需要这些技术中的一个或多个来通过不同的无线技术（例如，WLAN、蜂窝、WiMAX、Flash-OFDM等）实现快速移动IPv4切换。每种无线技术都有不同的第2层切换过程，应使用每种场景的最佳低延迟技术来优化切换性能。需要进一步的部署和实验来确定哪种技术在实现和性能方面最适合无线技术。因此，作者鼓励在低延迟无线技术上与FOO2进行合作，并鼓励在低延迟无线技术上进一步合作。
In the rest of this section, terminology used throughout the document is presented, the handoff techniques are briefly described, and the use of link-layer information is outlined. In Section 2, a brief description of requirements is presented. Section 3 describes the details of the PRE-REGISTRATION handoff technique, and Section 4 describes the details of the POST-REGISTRATION handoff technique. In Section 5, a combined method using the two handoff techniques together is presented. Section 6 discusses layer 2 and layer 3 handoff timing considerations. Section 7 discusses reverse tunneling support, Section 8 describes mechanisms to recover from message failures, and Section 9 describes protocol extensions required by the handoff techniques. Sections 10 and 11 discuss IANA and security considerations. Finally, the three appendices discuss additional material related to the handoff techniques. Appendix A gives a short introduction to Regional Registrations [11], which can be used together with low-latency handoffs. Appendix B discusses low-latency handoff when an MN has multiple wireless L2 interfaces, in which case the techniques in this document may not be necessary. Appendix C provides a summary of the messages used in PRE-REGISTRATION.
在本节的其余部分，将介绍整个文档中使用的术语，简要描述切换技术，并概述链路层信息的使用。第2节简要介绍了需求。第3节描述了注册前切换技术的细节，第4节描述了注册后切换技术的细节。在第5节中，介绍了一种将两种切换技术结合使用的组合方法。第6节讨论了第2层和第3层切换定时注意事项。第7节讨论反向隧道支持，第8节描述从消息失败中恢复的机制，第9节描述切换技术所需的协议扩展。第10节和第11节讨论IANA和安全注意事项。最后，三个附录讨论了与切换技术相关的其他材料。附录A简要介绍了区域注册[11]，可与低延迟切换一起使用。附录B讨论了当MN具有多个无线L2接口时的低延迟切换，在这种情况下，可能不需要本文档中的技术。附录C提供了预注册中使用的信息摘要。
This section presents a few terms used throughout the document.
本节介绍了本文件中使用的几个术语。
oFA - old Foreign Agent (FA), the FA involved in handling the care-of address (CoA) of a Mobile Node (MN) prior to a layer 3 (L3) handoff.
oFA-旧外部代理（FA），在第3层（L3）切换之前处理移动节点（MN）的转交地址（CoA）的FA。
nFA - new Foreign Agent, the FA anticipated to be handling an MN's care-of address after completion of an L3 handoff.
nFA-新的外国代理，FA预计在完成L3切换后将处理MN的转交地址。
aFA - anchor Foreign Agent, the FA that is currently handling the network end of the tunnel in POST-REGISTRATION.
aFA-anchor Foreign Agent，目前正在处理隧道网络端注册的FA。
L2 handoff - Movement of an MN's point of layer 2 (L2) connection from one wireless access point to another.
L2切换-MN的第2层（L2）连接点从一个无线接入点移动到另一个无线接入点。
L3 handoff - Movement of an MN between FAs that involves changing the care-of address at Layer 3 (L3).
L3切换-在FAs之间移动MN，涉及更改第3层（L3）的转交地址。
L2 trigger - Information from L2 that informs L3 of particular events before and after L2 handoff. The descriptions of L2 triggers in this document are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols.
L2触发器—来自L2的信息，在L2切换前后通知L3特定事件。本文档中对二级触发器的描述并不特定于任何特定的二级，而是对各种二级协议中可用的二级信息的概括。
L2-MT - An L2 trigger that occurs at the MN, informing of movement to a certain nFA (Mobile Trigger).
L2-MT-发生在MN的L2触发器，通知移动到某个nFA（移动触发器）。
L2-ST or source trigger - An L2 trigger that occurs at oFA, informing the oFA that L2 handoff is about to occur.
L2-ST或源触发器-在oFA处发生的二级触发器，通知oFA二级切换即将发生。
L2-TT or target trigger - An L2 trigger that occurs at nFA, informing the nFA that an MN is about to be handed off to nFA.
L2-TT或目标触发器-发生在nFA处的L2触发器，通知nFA MN即将移交给nFA。
L2-LU - An L2 trigger that occurs at the MN or nFA, informing that the L2 link between MN and nFA is established.
L2-LU-发生在MN或nFA的L2触发器，通知MN和nFA之间的L2链路已建立。
L2-LD - An L2 trigger that occurs at the oFA, informing the oFA that the L2 link between MN and oFA is lost.
L2-LD-发生在oFA处的L2触发器，通知oFA MN和oFA之间的L2链路丢失。
low-latency handoff - L3 handoff in which the period of time during which the MN is unable to receive packets is minimized.
低延迟切换-L3切换，其中MN无法接收数据包的时间段最小化。
low-loss handoff - L3 handoff in which the number of packets dropped or delayed is minimized. Low-loss handoff is often called smooth handoff.
低损耗切换-L3切换，其中丢弃或延迟的数据包数量最小化。低损耗切换通常称为平滑切换。
seamless handoff - L3 handoff that is both low latency and low loss.
无缝切换-低延迟和低丢失的L3切换。
bidirectional edge tunnel (BET) - A bidirectional tunnel established between two FAs for purposes of temporarily routing an MN's traffic to/from it on a new subnet without requiring the MN to change CoA.
双向边缘隧道（BET）-在两个FA之间建立的双向隧道，用于在新子网上临时路由MN的通信量，而无需MN更改CoA。
ping-pong - Rapid back-and-forth movement between two wireless access points often due to failure of L2 handoff. Ping-pong can occur if radio conditions for both the old and new access points are about equivalent and less than optimal for establishing a good, low-error L2 connection.
乒乓球-两个无线接入点之间的快速来回移动，通常是由于L2切换失败。如果旧接入点和新接入点的无线电条件大致相同，并且对于建立良好的、低错误的L2连接来说不是最佳条件，则可能发生乒乓球。
network-initiated handoff - L3 handoff in which oFA or nFA initiates the handoff.
网络发起的切换-三级切换，其中oFA或nFA发起切换。
mobile-initiated handoff - L3 handoff in which the MN initiates the handoff.
移动发起的切换-L3切换，其中MN发起切换。
MN or FA identifier - An IPv4 address of an MN or FA, or an L2 identifier that can be resolved to the IPv4 address of an MN or FA. If the identifier is an L2 identifier, it may be specific to the L2 technology.
MN或FA标识符—MN或FA的IPv4地址，或可解析为MN或FA的IPv4地址的L2标识符。如果标识符是L2标识符，则它可能特定于L2技术。
Mobile IPv4 was originally designed without any assumptions about the underlying link layers over which it would operate so that it could have the widest possible applicability. This approach has the advantage of facilitating a clean separation between L2 and L3 of the protocol stack, but it has negative consequences for handoff latency. The strict separation between L2 and L3 results in the following built-in sources of delay:
移动IPv4最初的设计没有对其运行的底层链路层进行任何假设，因此它可以具有尽可能广泛的适用性。这种方法的优点是便于在协议栈的L2和L3之间进行清晰的分离，但它会对切换延迟产生负面影响。L2和L3之间的严格分离导致以下内置延迟源：
- The MN may only communicate with a directly connected FA. This implies that an MN may only begin the registration process after an L2 handoff to nFA (new FA) has completed.
- MN只能与直接连接的FA通信。这意味着MN只能在L2向nFA（新FA）的切换完成后开始注册过程。
- The registration process takes some non-zero time to complete as the Registration Requests propagate through the network. During this period of time, the MN is not able to send or receive IPv4 packets.
- 当注册请求通过网络传播时，注册过程需要一些非零时间来完成。在此期间，MN无法发送或接收IPv4数据包。
This document presents techniques for reducing these built-in delay components of Mobile IPv4. The techniques can be divided into two general categories, depending on which of the above problems they are attempting to address:
本文档介绍了减少移动IPv4内置延迟组件的技术。这些技术可分为两大类，具体取决于它们试图解决的上述问题：
- Allow the MN to communicate with the nFA while still connected to the oFA.
- 允许MN在仍然连接到oFA时与nFA通信。
- Provide for data delivery to the MN at the nFA even before the formal registration process has completed.
- 即使在正式注册流程完成之前，也应在nFA向MN提供数据。
The first category of techniques allows the MN to "pre-build" its registration state on the nFA prior to an underlying L2 handoff. The second category of techniques allows for service to continue uninterrupted while the handoff is being processed by the network without requiring the MN's involvement.
第一类技术允许MN在底层L2切换之前在nFA上“预构建”其注册状态。第二类技术允许服务在网络处理切换时不间断地继续，而不需要MN的参与。
Three methods are presented in this document to achieve low-latency L3 handoff, one for each category described above and one as a combination of the two:
本文档中介绍了三种实现低延迟L3切换的方法，一种用于上述每个类别，另一种作为两种方法的组合：
- PRE-REGISTRATION handoff method,
- 预注册切换方法，
- POST-REGISTRATION handoff method, and
- 注册后切换方法，以及
- combined handoff method.
- 组合切换方法。
The PRE-REGISTRATION handoff method allows the MN to be involved in an anticipated IPv4-layer handoff. The MN is assisted by the network in performing an L3 handoff before it completes the L2 handoff. The L3 handoff can be either network-initiated or mobile-initiated. Accordingly, L2 triggers are used both in the MN and in the FA to trigger particular L3 handoff events. The PRE-REGISTRATION method coupled with L2 mobility helps to achieve seamless handoffs between FAs. The basic Mobile IPv4 concept involving advertisement followed by registration is supported, and the PRE-REGISTRATION handoff method relies on Mobile IPv4 security. No new messages are proposed, except for an extension to the Agent Solicitation message in the mobile-initiated case.
预注册切换方法允许MN参与预期的IPv4层切换。MN在完成L2切换之前由网络协助执行L3切换。L3切换可以是网络启动的，也可以是移动启动的。因此，在MN和FA中使用L2触发器来触发特定的L3切换事件。预注册方法与L2移动性相结合，有助于实现FAs之间的无缝切换。支持包含广告和注册的基本移动IPv4概念，并且预注册切换方法依赖于移动IPv4安全。除了在移动发起的情况下对代理请求消息的扩展之外，没有提出任何新消息。
The POST-REGISTRATION handoff method proposes extensions to the Mobile IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to utilize L2 triggers to set up a bidirectional tunnel between oFA and nFA that allows the MN to continue using its oFA while on nFA's subnet. This enables a rapid establishment of service at the new point of attachment, which minimizes the impact on real-time applications. The MN must eventually perform a formal Mobile IPv4 Registration after L2 communication with the new FA is established, but this can be delayed as required by the MN or FA. Until the MN performs registration, the FAs will set up and move bidirectional tunnels as required to give the MN continued connectivity.
注册后切换方法建议对移动IPv4协议进行扩展，以允许oFA（旧FA）和nFA（新FA）利用L2触发器在oFA和nFA之间建立双向隧道，从而允许MN在nFA的子网上继续使用其oFA。这使得能够在新的连接点快速建立服务，从而将对实时应用程序的影响降至最低。MN最终必须在与新FA建立L2通信后执行正式的移动IPv4注册，但这可以根据MN或FA的要求延迟。在MN执行注册之前，FAs将根据需要设置和移动双向隧道，以使MN继续连接。
The combined method involves running a PRE-REGISTRATION and a POST-REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can be performed before the L2 handoff completes, the combined method resolves to a PRE-REGISTRATION handoff. However, if the PRE-REGISTRATION handoff does not complete within an access technology dependent time period, the oFA starts forwarding traffic for the MN to the nFA as specified in the POST-REGISTRATION handoff method. This provides for a useful backup mechanism when completion of a PRE-REGISTRATION handoff cannot always be guaranteed before the L2 handoff completion.
组合方法包括并行运行预注册和注册后切换。如果可以在L2切换完成之前执行预注册切换，则组合方法解析为预注册切换。然而，如果预注册切换没有在接入技术相关的时间段内完成，则oFA开始按照注册后切换方法中的规定将MN的业务转发到nFA。这提供了一种有用的备份机制，当无法始终保证在L2切换完成之前完成预注册切换时。
It should be noted that the methods described in this document may be applied to MNs having a single interface (e.g., Wireless LAN interface) or multiple interfaces (e.g., one WLAN and one cellular interface). However, the case of multiply-interfaced MNs needs special consideration, since the handoff methods described in this document may not be required in all cases (see Appendix B).
应注意，本文档中描述的方法可应用于具有单个接口（例如，无线LAN接口）或多个接口（例如，一个WLAN和一个蜂窝接口）的mn。但是，多接口MNs的情况需要特别考虑，因为并非所有情况下都需要本文件中描述的切换方法（见附录B）。
An L2 trigger is a signal of an L2 event. In this document, the L2 events relate to the L2 handoff process. One possible event is early notice of an upcoming change in the L2 point of attachment of the mobile node to the access network. Another possible event is the completion of relocation of the mobile node's L2 point of attachment to a new L2 access point. This information may come explicitly from L2 in a solicited or unsolicited manner, or it may be derived from L2 messages. Although the protocols outlined in this document make use of specific L2 information, Mobile IPv4 should be kept independent of any specific L2. L2 triggers are an abstraction mechanism for a technology-specific trigger. Therefore, an L2 trigger that is made available to the Mobile IPv4 stack is assumed to be generic and technology independent. The precise format of these triggers is not covered in this document, but the information required to be contained in the L2 triggers for low-latency handoffs is specified.
二级触发器是二级事件的信号。在本文档中，二级事件与二级切换过程有关。一个可能的事件是提前通知移动节点到接入网络的L2连接点中即将发生的变化。另一个可能的事件是移动节点的L2连接点重新定位到新的L2接入点的完成。该信息可能以请求或非请求的方式明确来自第二语言，也可能来自第二语言消息。尽管本文档中概述的协议使用了特定的L2信息，但移动IPv4应该独立于任何特定的L2。L2触发器是特定于技术的触发器的抽象机制。因此，移动IPv4堆栈可用的L2触发器被认为是通用的和技术无关的。这些触发器的精确格式不在本文档中介绍，但指定了低延迟切换的L2触发器中需要包含的信息。
In order to properly abstract from the L2, it is assumed that one of the three entities -- the MN, oFA, or nFA -- is made aware of the need for an L2 handoff and that the nFA or MN can optionally also be made aware that an L2 handoff has completed. A specific L2 will often dictate when a trigger is received and which entity will receive it. Certain L2s provide advance triggers on the network side, while others provide advance triggers on the MN. Also, the particular timing of the trigger with respect to the actual L2 handoff may differ from technology to technology. For example, some wireless links may provide such a trigger well in advance of the actual handoff. In contrast, other L2s may provide little or no information in anticipation of the L2 handoff.
为了正确地从L2抽象，假设三个实体之一——MN、oFA或nFA——知道L2切换的需要，并且nFA或MN也可以选择性地知道L2切换已经完成。特定的L2通常会指定何时接收触发器以及哪个实体将接收触发器。某些L2在网络端提供高级触发器，而其他L2在MN端提供高级触发器。此外，关于实际L2切换的触发的特定定时可能因技术而异。例如，一些无线链路可以在实际切换之前提供这样的触发。相反，其他L2可能在L2切换的预期中提供很少或没有信息。
An L2 trigger may be categorized according to whether it is received by the MN, oFA, or nFA. Table 1 gives such a categorization along with information contained in the trigger. The methods presented in this document operate based on different types of L2 triggers as shown in Table 1. Once the L2 trigger is received, the handoff processes described hereafter are initiated. The three triggers, L2-ST, L2-TT, and L2-MT, are independent of each other and are not expected to occur together since each will trigger a different type of handoff behaviour.
L2触发器可以根据它是由MN、oFA还是nFA接收来分类。表1给出了此类分类以及触发器中包含的信息。本文介绍的方法基于表1所示的不同类型的L2触发器进行操作。一旦接收到L2触发，将启动下文描述的切换过程。这三个触发器（L2-ST、L2-TT和L2-MT）彼此独立，并且不会同时发生，因为每个触发器都会触发不同类型的切换行为。
+-------------+----------------------+------------------------------+
| L2 Trigger | Mobile | Source |
| | Trigger | Trigger |
| | (L2-MT) | (L2-ST) |
+-------------+----------------------+------------------------------+
| Recipient | MN | oFA |
+-------------+----------------------+--------------+---------------+
| Method | PRE | PRE | POST |
| | mobile-initiated | network- | source |
| | | initiated | trigger |
+-------------+----------------------+--------------+---------------+
| When? | sufficiently before | sufficiently | sufficiently |
| | the L2 handoff | before L2 | before L2 |
| | so that MN can | handoff for | handoff for |
| | solicit PrRtAdv | FA to send | oFA & nFA to |
| | from oFA | PrRtAdv | exchange |
| | | to MN | HRqst/HRply |
+-------------+----------------------+--------------+---------------+
| Parameters | nFA identifier | nFA identifier, MN identifier|
+-------------+----------------------+------------------------------+
+-------------+----------------------+------------------------------+
| L2 Trigger | Mobile | Source |
| | Trigger | Trigger |
| | (L2-MT) | (L2-ST) |
+-------------+----------------------+------------------------------+
| Recipient | MN | oFA |
+-------------+----------------------+--------------+---------------+
| Method | PRE | PRE | POST |
| | mobile-initiated | network- | source |
| | | initiated | trigger |
+-------------+----------------------+--------------+---------------+
| When? | sufficiently before | sufficiently | sufficiently |
| | the L2 handoff | before L2 | before L2 |
| | so that MN can | handoff for | handoff for |
| | solicit PrRtAdv | FA to send | oFA & nFA to |
| | from oFA | PrRtAdv | exchange |
| | | to MN | HRqst/HRply |
+-------------+----------------------+--------------+---------------+
| Parameters | nFA identifier | nFA identifier, MN identifier|
+-------------+----------------------+------------------------------+
Table 1 - L2 Trigger (continued on next page)
表1-L2触发器（下页续）
+------------+----------------------+---------------+---------------+
| L2 Trigger | Target | Link-Up | Link-Down |
| | Trigger | (L2-LU) | (L2-LD) |
| | (L2-TT) | | |
|------------+----------------------+---------------+---------------+
| Recipient | nFA | MN or nFA | oFA |
|------------+-----------+----------+---------------+---------------+
| Method | PRE | POST | PRE & POST | POST |
| | network- | target | | |
| | initiated | trigger | | |
|------------+----------------------+---------------+---------------+
| When? | | when radio | when radio |
| | same as | link between | link between |
| | source trigger | MN & nFA is | MN and oFA |
| | | established | is lost |
|------------+----------------------+---------------+---------------+
| Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier |
| | MN identifier | or L2 addr. | |
| | | @nFA: MN IPv4 | |
| | | or L2 addr. | |
+------------+----------------------+---------------+---------------+
+------------+----------------------+---------------+---------------+
| L2 Trigger | Target | Link-Up | Link-Down |
| | Trigger | (L2-LU) | (L2-LD) |
| | (L2-TT) | | |
|------------+----------------------+---------------+---------------+
| Recipient | nFA | MN or nFA | oFA |
|------------+-----------+----------+---------------+---------------+
| Method | PRE | POST | PRE & POST | POST |
| | network- | target | | |
| | initiated | trigger | | |
|------------+----------------------+---------------+---------------+
| When? | | when radio | when radio |
| | same as | link between | link between |
| | source trigger | MN & nFA is | MN and oFA |
| | | established | is lost |
|------------+----------------------+---------------+---------------+
| Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier |
| | MN identifier | or L2 addr. | |
| | | @nFA: MN IPv4 | |
| | | or L2 addr. | |
+------------+----------------------+---------------+---------------+
Table 1 - L2 Trigger
表1-L2触发器
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[2]所述。
The following requirements are applicable to low-latency handoff techniques and are supported by the methods in this document:
以下要求适用于低延迟切换技术，并由本文件中的方法支持：
- to provide low-latency and low-loss handoff for real-time services,
- 为实时服务提供低延迟和低损耗切换，
- to have no dependence on a wireless L2 technology,
- 不依赖无线L2技术，
- to support inter- and intra-access technology handoffs, and
- 支持接入间和接入内技术切换，以及
- to limit wireless bandwidth usage.
- 限制无线带宽的使用。
The PRE-REGISTRATION handoff method is based on the normal Mobile IPv4 handoff procedure specified in [1], according to which:
预注册切换方法基于[1]中规定的正常移动IPv4切换过程，根据该过程：
- an advertisement for an FA is received by an MN,
- MN收到FA的广告，
- the advertisement allows the MN to perform movement detection, and
- 广告允许MN执行移动检测，以及
- the MN registers with the FA.
- MN向FA注册。
The basic messages specified in [1] are extended to carry information required to achieve fast handoffs. The PRE-REGISTRATION method allows both the MN and FA to initiate the layer 3 handoff and it can make use of L2 triggers on either the FA or MN side, depending on whether network-initiated or mobile-initiated handoff occurs.
[1]中规定的基本消息被扩展以携带实现快速切换所需的信息。预注册方法允许MN和FA发起第3层切换，并且它可以利用FA或MN侧的L2触发器，这取决于是发生网络发起的切换还是发生移动发起的切换。
PRE-REGISTRATION supports the normal Mobile IPv4 model [1] and optionally also the Regional Registration model [11]. There can be advantages in implementing [11] together with low-latency handoff mechanisms, in particular in cases where the Home Agent (HA) is at a distance (in terms of delay) from the nFA. The time required for the handoff procedure to complete can be reduced by using a closer local HA, called Gateway Foreign Agent (GFA) in [11]. However, implementation of [11] is not required by PRE-REGISTRATION. PRE-REGISTRATION also supports movement where a new Authentication, Authorization, and Accounting (AAA) transaction must occur to authenticate the MN with a new domain.
预注册支持普通移动IPv4模式[1]，还可以选择支持区域注册模式[11]。与低延迟切换机制一起实现[11]可能具有优势，特别是在归属代理（HA）与nFA保持一定距离（就延迟而言）的情况下。通过使用更紧密的本地HA（在[11]中称为网关外部代理（GFA）），可以减少完成切换过程所需的时间。然而，预注册并不要求实施[11]。预注册还支持移动，其中必须发生新的身份验证、授权和记帐（AAA）事务才能使用新域对MN进行身份验证。
The PRE-REGISTRATION handoff mechanism is summarized in Figure 1.
图1总结了预注册切换机制。
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. PrRtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. PrRtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. PrRtSol)| | 2b |
| | PrRtAdv | 3. (Reg)RegReq
| | |
| v --------------------+
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. PrRtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. PrRtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. PrRtSol)| | 2b |
| | PrRtAdv | 3. (Reg)RegReq
| | |
| v --------------------+
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
Figure 1 - PRE-REGISTRATION Handoff Protocol
图1-预注册切换协议
The following steps provide more detail on the protocol:
以下步骤提供了有关协议的更多详细信息：
1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol) from oFA to nFA. It is a Mobile IP agent solicitation containing an identifier for the nFA (i.e., IP address or L2 address) in a Generalized Link Layer and IP Address Extension (see Section 9). When message 1a is received by the nFA containing nFA's correct identifier in the LLA extension, the nFA MUST return the Proxy Router Advertisement (Agent Advertisement) in message 1b. Message 1b is simply nFA's Agent Advertisement containing the nFA layer 2 address in a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). Messages 1a and 1b SHOULD occur in advance of the PRE-REGISTRATION handoff in order not to delay the handoff. For this to occur, oFA SHOULD solicit and cache advertisements from neighboring nFAs using messages 1a and 1b, thus decoupling the timing of this exchange from the rest of the PRE-REGISTRATION handoff. When the L3 handoff is initiated by a target L2 trigger at nFA (L2-TT), message 1b equals message 2b and is sent unsolicited directly to MN (tunneled by nFA to MN through oFA) instead of being relayed by oFA.
1. 消息1a是从oFA到nFA的代理路由器（代理）请求（PrRtSol）。它是一种移动IP代理请求，包含通用链路层和IP地址扩展中nFA（即IP地址或L2地址）的标识符（见第9节）。当nFA在LLA扩展中接收到包含nFA的正确标识符的消息1a时，nFA必须在消息1b中返回代理路由器广告（代理广告）。消息1b只是nFA的代理广告，包含通用链路层中的nFA第2层地址和IP地址（LLA）扩展（见第9.3节）。消息1a和1b应在预注册切换之前出现，以避免延迟切换。为了实现这一点，oFA应该使用消息1a和1b从相邻nfa请求和缓存广告，从而将此交换的定时与其余的预注册切换分离。当L3切换由nFA（L2-TT）处的目标L2触发器启动时，消息1b等于消息2b，并被非请求地直接发送到MN（由nFA通过oFA隧道到MN），而不是由oFA中继。
2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN to oFA. It is different from a normal Router (Agent) Solicitation since it is soliciting an advertisement from a router different from the one receiving this message. It is a Mobile IP Agent Solicitation containing an identifier for the nFA (i.e., IP address or L2 address) in a Generalized Link Layer and IP Address Extension (see Section 9). The presence of message 2a indicates that the handoff is mobile-initiated and its absence means that the handoff is network-initiated. In mobile-initiated handoff, message 2a occurs if there is an L2 trigger in the MN to solicit for a Proxy Router Advertisement (PrRtAdv). When message 2a is received by the oFA, it MUST return the Proxy Router Advertisement (Agent Advertisement) in message 2b. This is simply nFA's Agent Advertisement containing the nFA layer 2 address in a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). In network-initiated source-triggered handoff, the L2 trigger occurs at oFA, and oFA MUST relay the Agent Advertisement in message 2b without the need for the MN to solicit. Note that it is also possible for nFA to advertise directly to the MN in the network-initiated target-triggered case (see Section 3.2).
2. 消息2a是从MN到oFA的代理路由器请求（PrRtSol）。它不同于普通路由器（代理）请求，因为它从不同于接收此消息的路由器的路由器请求广告。它是一种移动IP代理请求，包含通用链路层和IP地址扩展中nFA（即IP地址或L2地址）的标识符（见第9节）。消息2a的存在表示切换是移动发起的，其不存在表示切换是网络发起的。在移动发起的切换中，如果MN中存在请求代理路由器广告（PrRtAdv）的L2触发器，则发生消息2a。当oFA接收到消息2a时，它必须返回消息2b中的代理路由器广告（代理广告）。这只是nFA的代理广告，包含通用链路层中的nFA第2层地址和IP地址（LLA）扩展（见第9.3节）。在网络发起的源触发切换中，L2触发发生在oFA处，oFA必须在消息2b中中继代理播发，而不需要MN请求。注意，在网络启动目标触发的情况下，nFA也可以直接向MN发布广告（参见第3.2节）。
3. The MN performs movement detection upon receipt of a solicited or unsolicited Agent Advertisement and, if required, it sends a Registration Request (RegReq) message [1] in message 3 to nFA. When a local Gateway Foreign Agent (GFA) is present, this message can optionally be a Regional Registration Request (RegRegReq) [11]. Message 3 is routed through oFA since the MN is not directly connected to nFA prior to the L2 handoff.
3. MN在接收到请求的或未经请求的代理广告时执行移动检测，并且如果需要，它向nFA发送消息3中的注册请求（RegReq）消息[1]。当存在本地网关外部代理（GFA）时，该消息可以是区域注册请求（RegRegReq）[11]。消息3通过oFA路由，因为MN在L2切换之前未直接连接到nFA。
4. Messages 4 and 5 complete the standard Mobile IPv4 Registration [1] or optionally Regional Registration [11] initiated with message 3. The Registration Request MUST contain the MN's layer 2 address in a Generalized Link Layer and IP Address Extension (see Sections 3.7 and 9). This identifier may be a plain Ethernet address or an identifier specific to the wireless technology. If the MN is not already connected to nFA, the Registration Reply in message 5 MUST be buffered by the nFA and unicast to the MN on-link as soon as the MN connects to nFA (i.e., L2-LU trigger at nFA, which can be implemented by the MN sending an Agent Solicitation or optionally using special layer 2 techniques, which are outside the scope of this document). This is necessary since the MN may have to detach from oFA, due to the wireless L2 connection, before it receives the reply. The MN's L2 address is obtained using the extensions in Section 9, as described in Section 3.7. Figures 2 and 3 illustrate this procedure.
4. 消息4和5完成标准移动IPv4注册[1]，或者可选地完成使用消息3启动的区域注册[11]。注册请求必须包含MN在通用链路层中的第2层地址和IP地址扩展（见第3.7和9节）。该标识符可以是普通以太网地址或特定于无线技术的标识符。如果MN尚未连接到nFA，则消息5中的注册回复必须由nFA缓冲，并在MN连接到nFA后立即单播到MN on链路（即，nFA处的L2-LU触发器，可通过MN发送代理请求或可选地使用特殊的第2层技术来实现，不在本文档的范围内）。这是必要的，因为由于无线L2连接，MN可能必须在收到回复之前从oFA分离。MN的L2地址是使用第9节中的扩展获得的，如第3.7节所述。图2和图3说明了此过程。
5. If the registration is successful, packets for the MN are tunneled from the HA (or GFA) to the nFA and then to the MN.
5. 如果注册成功，则MN的数据包从HA（或GFA）隧道传输到nFA，然后再传输到MN。
PRE-REGISTRATION is not dependent on [11]. However, if the HA is at a distance (in terms of delay) from the nFA, the use of a local GFA may reduce the time required for the handoff procedure to complete.
预注册不依赖于[11]。然而，如果HA与nFA的距离（就延迟而言），则使用本地GFA可以减少完成切换过程所需的时间。
The time at which the L2 trigger is received by the oFA or MN, thereby triggering the PRE-REGISTRATION handoff, compared to the time at which the actual L2 handoff occurs is important for the optimal performance of the low-latency handoff. That is, in the optimal case, the L2 trigger will be received and the four messaging steps of PRE-REGISTRATION described above will be completed (i.e., up to when the Registration Request is processed by HA or GFA) before the MN moves. Optimally, the Registration Reply and the first packet redirected by the HA (or GFA) to nFA will reach the MN at the moment in which the MN's L2 link to nFA is fully established. The MN would therefore not suffer any disruption due to the L3 handoff. This cannot always be guaranteed unless particular implementation techniques are used. To alleviate a part of this timing problem, the MN MAY set the S bit [1] in low-latency Registration Requests sent by the MN. This allows the MN to receive packets at both oFA and nFA during the short layer 2 handoff time. Other techniques may be required, such as L2 techniques or buffering, but these are outside the scope of this document. In addition, further handoff smoothing considerations may be required to prevent the loss of packets in-flight between HA (or GFA) and oFA while the MN performs a PRE-REGISTRATION handoff. These are also outside the scope of this document.
oFA或MN接收到L2触发器从而触发预注册切换的时间，与实际L2切换发生的时间相比，对于低延迟切换的最佳性能是重要的。也就是说，在最佳情况下，将在MN移动之前接收L2触发器并且完成上述预注册的四个消息传递步骤（即，直到注册请求由HA或GFA处理为止）。最理想的情况是，注册应答和由HA（或GFA）重定向到nFA的第一个分组将在MN到nFA的L2链路完全建立的时刻到达MN。因此，MN不会因L3切换而受到任何干扰。除非使用特定的实现技术，否则无法始终保证这一点。为了缓解该定时问题的一部分，MN可以在由MN发送的低延迟注册请求中设置S比特[1]。这允许MN在短的第2层切换时间内在oFA和nFA处接收分组。可能需要其他技术，如L2技术或缓冲，但这些不在本文档的范围内。此外，可能需要进一步的切换平滑考虑，以防止在MN执行预注册切换时HA（或GFA）和oFA之间的分组在飞行中丢失。这些也不在本文件的范围内。
Figures 2, 3, and 4 contain message timing diagrams for the network-initiated and mobile-initiated PRE-REGISTRATION handoff procedures.
图2、3和4包含网络启动和移动启动预注册切换过程的消息时序图。
As described in Table 1, a PRE-REGISTRATION handoff can be initiated at oFA by a source trigger or at nFA by a target trigger. Figures 2 and 3 contain message timing diagrams for PRE-REGISTRATION network-initiated handoff for source and target triggers.
如表1所述，预注册切换可由源触发器在oFA处启动，或由目标触发器在nFA处启动。图2和图3包含源和目标触发器的预注册网络启动切换的消息时序图。
A source-triggered, network-initiated handoff occurs when an L2 trigger is received at the oFA informing it of a certain MN's upcoming movement from oFA to nFA. The L2 trigger contains information including the MN's identifier (i.e., the IPv4 address itself or an identifier that can be resolved to the IPv4 address) and the nFA's identifier. An identifier may be an IPv4 address or something specific to the wireless technology (e.g., Base Station or Access Point Identifier). A target-triggered, network-initiated
当oFA接收到L2触发器，通知其某个MN即将从oFA移动到nFA时，就会发生源触发的、网络发起的切换。L2触发器包含的信息包括MN的标识符（即IPv4地址本身或可解析为IPv4地址的标识符）和nFA的标识符。标识符可以是IPv4地址或特定于无线技术的某物（例如，基站或接入点标识符）。目标触发，网络启动
handoff occurs when an L2 trigger is received at the nFA informing it of a certain MN's upcoming movement from oFA. This type of trigger is also shown in Table 1 and contains information including the MN's and the oFA's identifier.
当nFA接收到L2触发器，通知其某个MN即将从oFA移动时，发生切换。这种类型的触发器也显示在表1中，包含包括MN和oFA标识符的信息。
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram (Network-Initiated, Source Trigger)
图2-注册前切换消息时序图（网络启动，源触发）
In a source-triggered handoff, when oFA receives the trigger (L2-ST), it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to the MN. The PrRtAdv is nFA's Agent Advertisement [1] with one of the link-layer extensions described in Section 9. The use of the contents of this extension is described in Section 3.7. Messages 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is received (see Section 3.4.1). Message 2a is not used.
在源触发的切换中，当oFA接收到触发器（L2-ST）时，它必须向MN发送消息2b，即代理路由器公告（PrRtAdv）。PrRtAdv是nFA的代理广告[1]，具有第9节中描述的链路层扩展之一。第3.7节描述了本扩展内容的使用。在收到L2触发器之前，oFA和nFA应交换消息1a和1b（见第3.4.1节）。未使用消息2a。
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| |...................| |
|<--------------------------------------- | |
| (PrRtAdv) |...................| |
| | Tunneled Agent Advertisement |
| | | |
|---------------------------------------->| |
| RegReq. or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| |...................| |
|<--------------------------------------- | |
| (PrRtAdv) |...................| |
| | Tunneled Agent Advertisement |
| | | |
|---------------------------------------->| |
| RegReq. or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram (Network-Initiated, Target Trigger)
图3-注册前切换消息时序图（网络启动，目标触发）
In a target-triggered handoff, when nFA receives the trigger (L2-TT), it MUST tunnel an Agent Advertisement to the MN through oFA to initiate the L3 handoff. The inner advertisement is unicast by nFA to MN, thus nFA treats the target trigger as a Router (Agent) Solicitation. This advertisement is tunneled to oFA, which functions as a normal router, decapsulating the advertisement and forwarding it to the MN. This message MUST be authenticated to prevent attacks (see Section 3.4.2).
在目标触发的切换中，当nFA接收到触发器（L2-TT）时，它必须通过oFA将代理播发隧道到MN以启动L3切换。内部广告由nFA单播到MN，因此nFA将目标触发器视为路由器（代理）请求。此广告通过隧道传输到oFA，oFA起到普通路由器的作用，将广告解封并转发到MN。必须对该消息进行身份验证以防止攻击（见第3.4.2节）。
As shown in Table 1, a mobile-initiated handoff occurs when an L2 trigger is received at the MN informing that it will shortly move to nFA. The L2 trigger contains information such as the nFA's identifier (i.e., nFA's IPv4 address or an identifier that can be resolved to the nFA's IPv4 address). As an example, a Wireless LAN MN may perform a scan to obtain the Base Station Identifier (BSSID) of the access point that is a potential handoff target (i.e., its signal is becoming stronger). The message timing diagram is shown in Figure 4.
如表1所示，当MN接收到L2触发器通知它将很快移动到nFA时，移动发起的切换发生。L2触发器包含nFA的标识符（即nFA的IPv4地址或可解析为nFA的IPv4地址的标识符）等信息。例如，无线LAN MN可以执行扫描以获得作为潜在切换目标（即，其信号变得更强）的接入点的基站标识符（BSSID）。消息时序图如图4所示。
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| PrRtSol | | |
| | | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| PrRtSol | | |
| | | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram (Mobile-Initiated)
图4-注册前切换消息时序图（移动启动）
As a consequence of the L2 trigger (L2-MT), the MN MUST send message 1a, the Proxy Router Solicitation (PrRtSol). This message is a unicast Agent Solicitation to oFA for a Proxy Router Advertisement (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The Proxy Router Advertisement Solicitation unicast to oFA is an Agent Solicitation with a special extension. The solicitation MUST have an extension containing an FA identifier (i.e., IPv4 address or L2 address contained in an LLA extension, see Section 9) because the MN is soliciting another specific FA's advertisement from the oFA. This specific FA will be the MN's nFA. The identifier is the IPv4 address of the nFA or another identifier that can be used by the oFA to resolve to nFA's IPv4 address. If the identifier is not an IPv4 address, it MAY be specific to the underlying wireless technology, for example, an access point or Base Station Identifier (e.g., WLAN BSSID) that can be mapped by oFA to the nFA IPv4 address as described in Section 3.4.1. The extension containing the identifier is a sub-type of the Generalized Link Layer Address Extension described in Section 9.
作为L2触发器（L2-MT）的结果，MN必须发送消息1a，即代理路由器请求（PrRtSol）。此消息是向oFA请求代理路由器播发（PrRtAdv）的单播代理请求。如[1]中所述，此征集必须具有TTL=1。代理路由器广告请求单播到oFA是具有特殊扩展的代理请求。因为FA（i.9.）必须包含来自请求的另一个FA-MN扩展的标识符，所以必须具有来自请求的另一个FA-MN节的标识符。该特定FA将是MN的nFA。标识符是nFA的IPv4地址或oFA可用于解析为nFA的IPv4地址的另一个标识符。如果标识符不是IPv4地址，则它可能特定于底层无线技术，例如，可由oFA映射到nFA IPv4地址的接入点或基站标识符（例如，WLAN BSSID），如第3.4.1节所述。包含标识符的扩展是第9节中描述的通用链路层地址扩展的子类型。
Two extension sub-types have been defined to contain the nFA's IPv4 address and an access point identifier. They are called the Solicited Agent IPv4 Address Extension and the Access Point
已定义了两个扩展子类型，以包含nFA的IPv4地址和接入点标识符。它们被称为请求代理IPv4地址扩展和访问点
Identifier Extension, and are described in Sections 9.5 and 9.6. These two extensions SHOULD NOT be present in the same PrRtSol message.
标识符扩展，并在第9.5节和第9.6节中描述。这两个扩展不应出现在同一PrRtSol消息中。
When oFA receives the PrRtSol message, it MUST reply to the MN with the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is simply the Agent Advertisement for the requested nFA, proxied by oFA. In order to expedite the handoff, the actual nFA advertisement SHOULD be cached by the oFA following a previous exchange with nFA, shown in messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message MUST contain the nFA's L2 address (using the LLA extension in Section 9.3). This is further described in Section 3.7.
当oFA收到PrRtSol消息时，它必须用代理路由器公告（PrRtAdv，消息2b）回复MN。PrRtAdv只是由oFA代理的请求nFA的代理广告。为了加快切换，按照第3.5节的规定，oFA应在与nFA的先前交换后缓存实际的nFA广告，如消息1a和1b所示。PrRtAdv消息必须包含nFA的L2地址（使用第9.3节中的LLA扩展）。第3.7节对此作了进一步说明。
Since L2 triggers are involved in initiating PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged such that a full L3 PRE-REGISTRATION handoff can complete before the L2 handoff process completes. That is, the L2 handoff should be completed after the MN's registration with the nFA is performed (message 3 in Figure 1). The registration MAY be transmitted in more than one copy (default recommendation: 2) to reduce the probability that it is lost due to errors on the wireless link. This would not apply to reliable wireless links where retransmissions are performed at layer 2 in case of error to guarantee packet delivery.
由于L2触发器参与启动预注册切换，因此应安排触发器定时，以便在L2切换过程完成之前完成完整的L3预注册切换。也就是说，L2切换应该在MN向nFA注册后完成（图1中的消息3）。注册可以在多个副本中传输（默认建议：2），以减少由于无线链路上的错误而丢失的概率。这不适用于可靠的无线链路，其中在发生错误时在第2层执行重传以保证数据包交付。
A PRE-REGISTRATION handoff in this case requires the MN to receive an Agent Advertisement from the nFA through the old wireless access point. How to achieve this is discussed in the following subsections. Messages exchanged between FAs MUST be authenticated to prevent impersonation attacks. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1] (see the Security Considerations of this document).
在这种情况下，预注册切换要求MN通过旧的无线接入点从nFA接收代理广告。如何实现这一点将在以下小节中讨论。FAs之间交换的消息必须经过身份验证，以防止模拟攻击。最低要求是，参与低延迟切换的所有FA必须支持手动预配置与其他相邻FA的安全关联，包括共享密钥和[1]的默认算法（参见本文档的安全注意事项）。
This applies to the network-initiated source-triggered (L2-ST) and mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes that oFA has access to the IPv4 address of the nFA. The IPv4 address of nFA is obtained by means of an L2 trigger at oFA in the network-initiated case (see Section 3.2) or by means of the extension to the Proxy Router Solicitation (PrRtSol) from the MN in the mobile-initiated case (see Section 3.3). This extension to the PrRtSol may contain an IPv4 address or another identifier, for example, an identifier of a Wireless Base Station such as the WLAN BSSID. In the latter case, the oFA must implement a mechanism to resolve the Base
这仅适用于网络启动源触发（L2-ST）和移动启动（L2-MT）情况。FA间请求假定oFA可以访问nFA的IPv4地址。nFA的IPv4地址在网络发起的情况下通过oFA的L2触发器获得（参见第3.2节），或者在移动发起的情况下通过从MN扩展到代理路由器请求（PrRtSol）获得（参见第3.3节）。PrRtSol的该扩展可以包含IPv4地址或另一标识符，例如，诸如WLAN BSSID的无线基站的标识符。在后一种情况下，oFA必须实现一种机制来解析基
Station Identifier to an IPv4 address. The default mechanism is to use a configured table of neighboring Base Station Identifiers (e.g., BSSID) to FA IPv4 address mappings in each FA. Other automated discovery mechanisms may also be used.
IPv4地址的站点标识符。默认机制是使用相邻基站标识符（例如，BSSID）的配置表来映射每个FA中的FA IPv4地址。还可以使用其他自动发现机制。
If oFA does not cache advertisements (see Section 3.5) once it receives an L2 trigger and obtains the address of the nFA for a specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to nFA. The nFA replies to the oFA by unicasting an Agent Advertisement with appropriate extensions (PrRtAdv). This method removes the TTL limitation of [1] for Mobile IPv4 messages (i.e., TTL=1 is not applicable here). The TTL limitation cannot be applied since oFA and nFA may be more than one hop away and since it is unnecessary for a secured unicast message. The ICMP solicitations and advertisements MUST be authenticated and integrity protected. These messages MUST be protected using Encapsulating Security Payload (ESP) [10] to prevent attacks (see the Security Considerations section of this document). An FA MUST NOT accept ICMP solicitations or advertisements from sources that are not authenticated.
如果oFA在收到L2触发器并获得特定MN的nFA地址后不缓存广告（参见第3.5节），则必须向nFA发送单播代理请求（PrRtSol）。nFA通过单播具有适当扩展的代理广告（PrRtAdv）来回复oFA。此方法消除了移动IPv4消息的TTL限制[1]（即TTL=1在此处不适用）。TTL限制不能应用，因为oFA和nFA可能距离超过一跳，并且对于安全的单播消息来说它是不必要的。ICMP征集和广告必须经过身份验证和完整性保护。必须使用封装安全有效负载（ESP）[10]保护这些消息，以防止攻击（请参阅本文档的安全注意事项部分）。FA不得接受来自未经认证来源的ICMP请求或广告。
As a practical matter, oFA SHOULD pre-solicit and cache advertisements from known neighboring FAs (see section 3.5) to avoid performing the solicitation during an actual handoff procedure.
实际上，oFA应该预先请求并缓存来自已知相邻FA的广告（参见第3.5节），以避免在实际切换过程中执行请求。
This applies to the network-initiated target-triggered (L2-TT) case only. Following a target trigger (L2-TT) the nFA MUST send a tunneled Agent Advertisement to the MN through oFA. Tunneling nFA advertisements assumes that the nFA is aware of the IPv4 address for oFA and the MN. These IPv4 addresses are obtained by means of the FA and MN identifiers contained in an L2 trigger received at nFA in the network-initiated case (see Section 3.2). However, in [1] the TTL must be 1 on Agent Advertisements from the nFA. Therefore, tunneling advertisements is applicable if the TTL limitation of [1] is relaxed. For this purpose, a pre-established security association between oFA and nFA MUST be in place to authenticate this message and relax the TTL limitation. If the implementation requires this, a tunnel SHOULD be configured when the inter-FA security association is established. The tunneled ICMP advertisement MUST be secured using tunnel mode ESP [10] between nFA and oFA. An FA MUST NOT accept tunneled ICMP packets destined to it from sources that are not authenticated.
这仅适用于网络启动目标触发（L2-TT）情况。在目标触发器（L2-TT）之后，nFA必须通过oFA向MN发送隧道代理播发。隧道nFA播发假定nFA知道oFA和MN的IPv4地址。这些IPv4地址是通过网络启动情况下nFA接收的L2触发器中包含的FA和MN标识符获得的（见第3.2节）。然而，在[1]中，nFA代理广告的TTL必须为1。因此，如果放宽[1]的TTL限制，则隧道广告是适用的。为此，必须在oFA和nFA之间建立预先建立的安全关联，以验证此消息并放宽TTL限制。如果实现需要这样做，则应在建立FA间安全关联时配置隧道。必须使用nFA和oFA之间的隧道模式ESP[10]保护隧道ICMP播发。FA不得接受未经身份验证的源发送给它的隧道ICMP数据包。
In the mobile-initiated (L2-MT) case and the network-initiated source-triggered (L2-ST) case, the message exchange 1 in Figure 1 could impose an additional latency on the L3 handoff process if done as part of the handoff procedure. In order to remove this source of latency, the inter-FA Router (Agent) Solicitation and Advertisement exchange SHOULD be performed in advance of handoff. A process SHOULD be in place at the oFA to solicit its neighboring nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT be set too small to avoid unnecessary consumption of network bandwidth and nFA processing resources. The minimum value of MIN_SOLICITATION_INTERVAL is 1 second. If the FA Challenge/Response mechanism in [7] is used, then the MIN_SOLICITATION_INTERVAL MUST be set to a value smaller then the window of time in which a challenge remains valid so that the nFA challenge does not expire before the MN issues the Registration Request. Therefore, the recommended default value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's CHALLENGE_WINDOW * nFA's Agent Advertisement interval). The CHALLENGE_WINDOW and Agent Advertisement interval are defined in [7] and [1] respectively. The minimum requirement is that the MIN_SOLICITATION_INTERVAL MUST be manually configurable, while possible autoconfiguration mechanisms are outside the scope of this document. To allow advertisement caching in certain implementations and in cases where the nFA advertisement interval is very small, it MAY be necessary for the implementation in nFA to allow different CHALLENGE_WINDOW and Agent Advertisement interval settings for its nFA-oFA interface.
在移动启动（L2-MT）和网络启动源触发（L2-ST）情况下，图1中的消息交换1如果作为切换过程的一部分进行，则可能会对L3切换过程施加额外的延迟。为了消除此延迟源，应在切换之前执行FA路由器（代理）间请求和广告交换。应在oFA处设置一个流程，以在预定义的时间间隔（最小请求间隔）请求其相邻NFA。此间隔不应设置得太小，以避免不必要地消耗网络带宽和nFA处理资源。最小请求间隔的最小值为1秒。如果使用[7]中的FA质询/响应机制，则最小请求间隔必须设置为小于质询保持有效的时间窗口的值，以便nFA质询不会在MN发出注册请求之前过期。因此，oFA中最小请求间隔的推荐默认值为（0.5*nFA的质询窗口*nFA的代理广告间隔）。[7]和[1]中分别定义了质询_窗口和代理播发间隔。最低要求是必须手动配置最小请求间隔，而可能的自动配置机制不在本文档范围内。为了在某些实现中以及在nFA播发间隔非常小的情况下允许播发缓存，nFA中的实现可能需要为其nFA oFA接口允许不同的质询窗口和代理播发间隔设置。
The oFA SHOULD cache the most recent advertisement from its neighboring nFAs. This advertisement MUST be sent to the MN in message 2b with a TTL=1. The oFA SHOULD also have a mechanism in place to create a list of neighboring nFAs. The minimum requirement for each FA is that it SHOULD allow manual configuration of a list of nFA addresses that an MN could possibly perform an L3 handoff to. The FA addresses in this list will depend on deployment and radio coverage. It is also possible to specify another protocol to achieve nFA discovery, but this is outside the scope of this document.
oFA应该缓存来自其相邻NFA的最新广告。该广告必须以TTL＝1的方式发送到消息2b中的MN。oFA还应该有一个机制来创建相邻NFA的列表。每个FA的最低要求是，它应该允许手动配置MN可能执行L3切换的nFA地址列表。此列表中的FA地址将取决于部署和无线电覆盖范围。也可以指定另一个协议来实现nFA发现，但这超出了本文档的范围。
When the MN receives an Agent Advertisement with a Mobility Agent extension, it performs actions according to the following movement detection mechanism: the MN SHOULD be "Eager" to perform new bindings. This means that the MN SHOULD perform registrations with any new FA from which it receives an advertisement (i.e., MN is Eager), as long as there are no locally-defined policies in the MN that discourage the use of the discovered FA. For example, the MN
当MN接收到带有移动代理扩展的代理播发时，它根据以下移动检测机制执行操作：MN应该“渴望”执行新绑定。这意味着，只要MN中没有阻止使用发现的FA的本地定义策略，MN就应该向其接收广告的任何新FA执行注册（即，MN渴望）。例如，MN
could have a policy based on the cost of service. The method by which the MN determines whether the FA is a new FA is described in [1] and MAY use an FA-NAI extension [11]. By being "Eager" to perform registrations, the MN reduces latency times.
可以有一个基于服务成本的政策。MN确定FA是否为新FA的方法在[1]中描述，并且可以使用FA-NAI扩展[11]。通过“渴望”执行注册，MN减少了延迟时间。
The MN also needs to change its default router from oFA to nFA. The MN MUST change its default router to nFA as soon as the PRE-REGISTRATION procedure has completed (i.e., Registration Reply is received by MN) as described in [1].
MN还需要将其默认路由器从oFA更改为nFA。如[1]所述，一旦预注册过程完成（即，MN收到注册回复），MN必须将其默认路由器更改为nFA。
Overall, the MN behaves as described in [1] with the following changes: the specified movement detection mechanism mentioned above and the ability to use the L2-MT to initiate an Agent Solicitation with a special extension (PrRtSol). Also, when the MN receives an L2-LU trigger (i.e., new interface or link is up), it MUST immediately send an Agent Solicitation [1] on that interface. An nFA that receives an Agent Solicitation [1] will use it as an L2-LU trigger event, and according to [1] it will record the MN's IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP) entry). At that point, the nFA starts delivering data to the MN including the previously buffered Registration Reply. The nFA MAY also use other L2 mechanisms to detect earlier that the MN has attached to the new link and to start forwarding data to it. The MN SHOULD NOT attempt to retransmit a low-latency Registration Request (i.e., Registration Request containing an LLA extension described in Section 9.) when it does not receive the Registration Reply.
总的来说，MN的行为如[1]中所述，具有以下变化：上述指定的移动检测机制以及使用L2-MT启动具有特殊扩展（PrRtSol）的代理请求的能力。此外，当MN接收到L2-LU触发器（即，新接口或链路启动）时，它必须立即在该接口上发送代理请求[1]。接收代理请求[1]的nFA将其用作L2-LU触发事件，并根据[1]记录MN的IPv4/第2层地址（即地址解析协议（ARP）条目）。此时，nFA开始向MN传送数据，包括先前缓冲的注册应答。nFA还可以使用其他L2机制来更早地检测MN已连接到新链路并开始向其转发数据。当MN没有收到注册回复时，不应尝试重新传输低延迟注册请求（即，包含第9节中描述的LLA扩展的注册请求）。
When moving from a PRE-REGISTRATION network to a normal Mobile IPv4 [1] network, the MN will no longer receive PrRtAdv messages (i.e., Agent Advertisements with the LLA extension). If the MN still receives L2-MTs, it will attempt to send PrRtSol messages. The normal FA will reply with a normal Agent Advertisement [1]. If the MN does not receive a PrRtAdv in reply to its PrRtSol, it MAY retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds and then for another PRE_SOL_ATTEMPTS times with exponential backoff of the transmission interval. If a PrRtAdv is not received within PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST stop sending PrRtSol messages until after a registration with a new FA is performed. The default value for PRE_SOL_ATTEMPTS is 2, and for PRE_SOL_INTERVAL, it is 1 second. It should be noted that the performance of the movement detection mechanism mandated in PRE-REGISTRATION (i.e., eager to register) may have sub-optimal behaviour in a standard Mobile IPv4 [1] network. Therefore, standard movement detection mechanisms [1] should be used in plain Mobile IPv4 networks. Instead, when the MN moves from a normal Mobile IPv4 [1] network to a PRE-REGISTRATION network, the MN starts receiving L2-MT triggers or PrRtAdv messages. When the MN receives L2-MT triggers or PrRtAdv messages, it SHOULD follow the PRE-REGISTRATION procedure.
当从预注册网络移动到普通移动IPv4[1]网络时，MN将不再接收PrRtAdv消息（即，具有LLA扩展的代理广告）。如果MN仍然接收L2 MT，它将尝试发送PrRtSol消息。普通FA将回复普通代理广告[1]。如果MN没有接收到对其PrRtSol的回复的PrRtAdv，则它可以在PRE_SOL_间隔秒之后重新传输PrRtSol消息一次，然后在传输间隔的指数退避下进行另一次PRE_SOL_尝试次数。如果在最后一次PrRtSol尝试后的PRE_SOL_间隔秒内未接收到PrRtAdv，则MN必须停止发送PrRtSol消息，直到执行了与新FA的注册。PRE_SOL_尝试的默认值为2，PRE_SOL_INTERVAL的默认值为1秒。应注意，在标准移动IPv4[1]网络中，预注册（即，急于注册）中强制要求的移动检测机制的性能可能具有次优行为。因此，在普通移动IPv4网络中应使用标准移动检测机制[1]。相反，当MN从普通移动IPv4[1]网络移动到预注册网络时，MN开始接收L2-MT触发器或PrRtAdv消息。当MN接收到L2-MT触发器或PrRtAdv消息时，应遵循预注册过程。
If there is uncertainty as to which mode to choose (e.g., MN receives messages from both PRE-REGISTRATION and normal FAs), the MN decides based on its registration status with the current FA. If the MN already has a valid normal Mobile IPv4 Registration [1] with the advertising FA, it SHOULD give priority to the PRE-REGISTRATION procedure. Otherwise it SHOULD give priority to normal Mobile IPv4 [1] Registration procedure. The MN SHOULD NOT attempt to perform PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in parallel.
如果选择哪种模式存在不确定性（例如，MN接收来自预注册和正常FA的消息），MN将根据其与当前FA的注册状态来决定。如果MN已经向广告FA进行了有效的正常移动IPv4注册[1]，则应优先考虑预注册程序。否则，它应该优先考虑正常的移动IPv4[1]注册过程。MN不应尝试并行执行预注册和标准移动IPv4[1]注册。
Some special considerations should be taken with respect to the wireless system on which this handoff method is being implemented. Consider an Ethernet-like system such as IEEE 802.11, for example. In PRE-REGISTRATION, the MN is registering with an FA (nFA) that is not its current first-hop router; therefore, the L2 address of the Ethernet frame containing the MN's Registration Request reaching the nFA is not the MN's address. Therefore, the FA MUST NOT use the Ethernet address of the incoming Registration Request as the MN's L2 address as specified in [1]. This applies to the cases where the wireless access points are bridges or routers and independently of whether the FA is implemented in the wireless access points themselves. In this case, the MN's Registration Request (or Regional Registration Request) MUST use an L2 address extension to the registration message. Such an L2 address is either the same L2 address that remains constant as the MN moves, or it is the MN's L2 address at nFA. To communicate its L2 address, the MN includes a Generalized Link Layer and IP Address Extension (see Section 9) with its Registration Request (or Regional Registration Request) message. If this extension is present, the FA MUST use the L2 address contained in the extension to communicate with the MN. If a particular wireless L2 technology has defined a special interface to the wireless network that allows the FA to resolve the mapping between an MN's IPv4 address and its L2 address without the need to use the extension, the L2 address extension contents may be discarded. For the same reasons above, the MN MUST NOT use the source L2 address of the Agent Advertisement message (PrRtAdv) as its default router's L2 address. Therefore, the nFA MUST include a Generalized Link Layer and IP Address Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv) messages.
对于正在实施该切换方法的无线系统，应采取一些特殊的考虑。例如，考虑一个类似以太网的系统，例如IEEE 802.11。在预注册中，MN向不是其当前第一跳路由器的FA（nFA）注册；因此，包含到达nFA的MN的注册请求的以太网帧的L2地址不是MN的地址。因此，FA不得使用传入注册请求的以太网地址作为[1]中指定的MN的L2地址。这适用于无线接入点是网桥或路由器并且独立于FA是否在无线接入点本身中实现的情况。在这种情况下，MN的注册请求（或区域注册请求）必须使用注册消息的L2地址扩展。这样的L2地址要么是MN移动时保持不变的相同L2地址，要么是nFA中MN的L2地址。为了传递其L2地址，MN包括通用链路层和IP地址扩展（参见第9节）及其注册请求（或区域注册请求）消息。如果存在此扩展，FA必须使用扩展中包含的L2地址与MN通信。如果特定的无线L2技术定义了无线网络的特殊接口，该接口允许FA在不需要使用扩展的情况下解析MN的IPv4地址与其L2地址之间的映射，则L2地址扩展内容可能被丢弃。出于上述相同原因，MN不得使用代理播发消息（PrRtAdv）的源L2地址作为其默认路由器的L2地址。因此，nFA必须包括通用链路层和IP地址扩展（见第9.3节）及其代理广告（PrRtAdv）消息。
The PRE-REGISTRATION handoff method is applicable to scenarios where a period of service disruption due to layer 3 is not acceptable, for example, when performing real-time communications, and therefore where an anticipation of the layer 3 handoff is required. Security
预注册切换方法适用于例如在执行实时通信时由于第3层而导致的服务中断周期不可接受的场景，因此需要对第3层切换进行预期。安全
for the PRE-REGISTRATION handoff method is based on the same security model as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION is that the FA or MN is able to obtain an L2 trigger informing it of a pending L2 handoff procedure. The target of the L2 handoff is another access point or radio network that is in the coverage area of a new FA. The L2 trigger information may be in the form of identifiers that need to be resolved to IPv4 addresses using methods that may be specific to the wireless network and are not considered here. If, for example, the oFA or MN determines that the IPv4 address of the new FA matches oFA's address, then the PRE-REGISTRATION handoff SHOULD NOT be initiated.
因为预注册切换方法基于与[1]相同的安全模型，包括使用AAA。预注册的一个先决条件是FA或MN能够获得二级触发器，通知其等待的二级切换过程。L2切换的目标是位于新FA覆盖区域内的另一个接入点或无线网络。L2触发信息可以是标识符的形式，需要使用特定于无线网络的方法将其解析为IPv4地址，这里不考虑这些方法。例如，如果oFA或MN确定新FA的IPv4地址与oFA的地址匹配，则不应启动预注册切换。
The L2 trigger must allow enough time for the PRE-REGISTRATION handoff procedure to be performed. In many wireless L2 technologies, the L2 handoff procedure involves a number of message exchanges before the effective L2 handoff is performed. For such technologies, PRE-REGISTRATION handoff can be initiated at the beginning of the L2 handoff procedure and completed before the L2 handoff is completed. It is efficient to engineer the network such that this succession of events is ensured.
L2触发器必须留出足够的时间来执行预注册切换过程。在许多无线L2技术中，L2切换过程涉及在执行有效的L2切换之前的许多消息交换。对于此类技术，预注册切换可以在二级切换过程开始时启动，并在二级切换完成之前完成。设计网络以确保事件的连续性是有效的。
The PRE-REGISTRATION handoff method is applicable in the following cases:
预注册切换方法适用于以下情况：
- when the MN has locally defined policies that determine a preference for one access over another, for example, due to service cost within the same or different technology, and therefore where it is necessary to allow the MN to select the appropriate FA with which to connect.
- 例如，由于相同或不同技术内的服务成本，当MN具有本地定义的策略来确定对一种访问的偏好时，因此有必要允许MN选择与之连接的适当FA。
- when L2 security between the MN and the FA is either not present or cannot be relied upon to provide adequate security.
- 当MN和FA之间的L2安全性不存在或无法提供足够的安全性时。
- when the trigger to initiate the handoff is received at the MN.
- 当在MN处接收到发起切换的触发器时。
In the first case, it is necessary to involve eventual local MN policies in the movement detection procedure as described in Section 3.6.
在第一种情况下，如第3.6节所述，有必要在移动检测程序中加入最终的本地MN策略。
The POST-REGISTRATION handoff method uses bidirectional edge tunnels (BETs) or unidirectional tunnels to perform low-latency change in the L2 point of attachment for the MN without requiring any involvement by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff.
注册后切换方法使用双向边缘隧道（BETs）或单向隧道来执行MN的L2连接点的低延迟改变，而不需要MN的任何参与。图5说明了基本的注册后切换。
+------+
| CN |
+------+
|
...
|
+------+ BET +------+
| aFA |==========| nFA |
+------+ +------+
| wireless link
|
movement +------+
---------> | MN |
+------+
+------+
| CN |
+------+
|
...
|
+------+ BET +------+
| aFA |==========| nFA |
+------+ +------+
| wireless link
|
movement +------+
---------> | MN |
+------+
Figure 5 - POST-REGISTRATION Concept
图5-注册后概念
Following a successful Mobile IPv4 Registration between MN and oFA, the oFA becomes the mobility anchor point for the MN, called the anchor FA (aFA). When the MN moves from oFA to nFA, rather than performing signaling over the wireless link to register with the nFA, the MN can defer the L3 handoff and continue to use its aFA (i.e., oFA in this case). If the MN moves to a third FA before registering with the nFA, in certain cases described later, the third FA signals aFA to move the wireless link end of the BET from nFA to it. The network end of the BET remains anchored at aFA until the MN performs the Mobile IPv4 Registration.
在MN和oFA之间成功注册移动IPv4之后，oFA成为MN的移动锚点，称为锚点FA（aFA）。当MN从oFA移动到nFA时，而不是通过无线链路执行信令以向nFA注册，MN可以延迟L3切换并继续使用其aFA（即，在这种情况下为oFA）。如果MN在向nFA注册之前移动到第三FA，则在稍后描述的某些情况下，第三FA向aFA发送信号以将赌注的无线链路端从nFA移动到它。BET的网络端保持锚定在aFA，直到MN执行移动IPv4注册。
Messages between oFA/aFA and nFA MUST be authenticated. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1]. POST-REGISTRATION FAs MUST implement the inter-FA authentication extension (FA-FA authentication extension) specified in [11] and MAY additionally use other security mechanisms.
oFA/aFA和nFA之间的消息必须经过身份验证。最低要求是，参与低延迟切换的所有FA必须支持手动预配置与其他相邻FA的安全关联，包括共享密钥和[1]的默认算法。注册后的FAs必须实现[11]中规定的FA间认证扩展（FA-FA认证扩展），并且还可以使用其他安全机制。
Two-party handoff occurs when the MN moves from oFA to nFA. Normally, this movement would result in a new Mobile IPv4 Registration at nFA. However, in POST-REGISTRATION, the MN and nFA MAY delay this but maintain connectivity using the BET (or alternatively unidirectional tunnel) between oFA and nFA. The protocol is shown in Figure 6.
当MN从oFA移动到nFA时，发生两方切换。通常情况下，此移动将导致在nFA进行新的移动IPv4注册。然而，在后注册中，MN和nFA可以延迟这一点，但是使用oFA和nFA之间的BET（或者单向隧道）保持连接。协议如图6所示。
1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c) L2-LU ---> | MN | --------->
+------+
1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c) L2-LU ---> | MN | --------->
+------+
Figure 6 - Two-Party Handoff (POST-REGISTRATION)
图6-双方切换（注册后）
The following describes the progress of a two-party handoff. The numbered items refer to steps in Figure 6. The source-triggered HRqst/HRply message for tunnel creation, the target-triggered HRqst/HRply message for tunnel creation, and the HRqst/HRply to extend or terminate a BET (or unidirectional tunnel) are identified using the suffixes (s), (t), and (r), respectively.
以下描述了双方切换的进度。编号项目参考图6中的步骤。用于隧道创建的源触发HRqst/HRply消息、用于隧道创建的目标触发HRqst/HRply消息以及用于扩展或终止BET（或单向隧道）的HRqst/HRply分别使用后缀（s）、（t）和（r）进行标识。
1) Either the oFA or nFA receives an L2 trigger informing it that a certain MN is about to move from oFA to nFA. The two cases are:
1) oFA或nFA接收L2触发器，通知其某个MN即将从oFA移动到nFA。这两个案例是：
a) The L2 trigger is a source trigger (L2-ST) at oFA. The trigger contains the MN's L2 address and an identifier for the nFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the nFA).
a) L2触发器是oFA处的源触发器（L2-ST）。触发器包含MN的L2地址和nFA的标识符（IPv4地址本身或可解析为nFA的IPv4地址的L2地址）。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The trigger contains the MN's L2 address and an identifier for the oFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the oFA).
b) L2触发器是nFA的目标触发器（L2-TT）。触发器包含MN的L2地址和oFA的标识符（IPv4地址本身或可解析为oFA的IPv4地址的L2地址）。
2) The FA receiving the trigger sends a Handoff Request (HRqst) to the other FA. There are two cases:
2) 接收触发器的FA向另一个FA发送切换请求（HRqst）。有两种情况：
a) If oFA is sending the HRqst, the H bit is set and the N bit is unset, indicating it is an HRqst(s). The HRqst(s) contains the lifetime of the tunnel the oFA is willing to support, the MN's IPv4 home address, the MN's HA address, and an LLA option with the MN's L2 address. If the lifetime is zero and the T bit is not set, the oFA is not willing to tunnel any packets for MN. A positive lifetime and a set T bit indicate that the oFA is willing to tunnel for the indicated time. Section 4.5 describes the HRqst(s) and Section 9 describes the LLA option.
a) 如果oFA正在发送HRqst，则设置H位，而未设置N位，表示它是HRqst。HRqst包含oFA愿意支持的隧道的生存期、MN的IPv4主地址、MN的HA地址以及带有MN的L2地址的LLA选项。如果生存期为零且未设置T位，则oFA不愿意为MN隧道任何数据包。正寿命和设置的T位表示oFA愿意在指定的时间内进行隧道。第4.5节描述了HRqst，第9节描述了LLA选项。
b) If nFA is sending the HRqst, the N bit is set and the H bit is unset, indicating that it is an HRqst(t). If the T bit is set, nFA has requested a reverse tunnel and the HRqst(t) contains the lifetime of the tunnel the nFA is requesting. The HRqst(t) also contains an LLA option with the MN's L2 address. The MN's IPv4 home address and HA address are not sent, unless they are discovered by some means outside the scope of this document (for example, as part of the L2-TT). Section 4.5 describes the HRqst(t).
b) 如果nFA正在发送HRqst，则N位被设置，H位被取消设置，表明它是HRqst（t）。如果设置了T位，则nFA已请求反向隧道，并且HRqst（T）包含nFA请求的隧道的生存期。HRqst（t）还包含一个带有MN的L2地址的LLA选项。MN的IPv4家庭地址和HA地址不会被发送，除非它们是通过本文档范围之外的某种方式发现的（例如，作为L2-TT的一部分）。第4.5节描述了HRqst（t）。
3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the other FA. There are two cases:
3) 接收HRqst的FA向另一FA发送切换应答（HRply）。有两种情况：
a) If oFA is sending the HRply, the N bit is set and the H and R bits are unset, indicating that the reply is in response to a HRqst(t), i.e., it is an HRply(t). If the T bit is set, the HRply(t) contains the tunnel lifetime the oFA is willing to provide; otherwise, the tunnel lifetime is set to zero indicating that the oFA is not willing to provide tunnel service. If both HRply(t) and HRqst(t) have the T bit set and non-zero lifetime, a BET is established. The HRply(t) also contains the MN's home subnet IPv4 address, the MN's HA address, and an LLA option containing the MN's L2 address. Section 4.6 describes the HRply(t).
a) 如果oFA正在发送HRply，则设置N位并且未设置H和R位，指示应答响应于HRqst（t），即，它是HRply（t）。如果设置了T位，则HRply（T）包含oFA愿意提供的隧道寿命；否则，隧道寿命设置为零，表示oFA不愿意提供隧道服务。如果HRply（t）和HRqst（t）都设置了t位且寿命非零，则建立下注。HRply（t）还包含MN的主子网IPv4地址、MN的HA地址和包含MN的L2地址的LLA选项。第4.6节描述了HRply（t）。
b) If nFA sends the HRply, the H bit is set and the N and R bits are unset, indicating that this is a response to HRqst(s), i.e., it is an HRply(s). If the T bit is set, the nFA indicates that it requests a reverse tunnel, and the lifetime field is set with the requested tunnel lifetime. The T bit can be set in HRply only if the oFA had set the T bit in the corresponding HRqst or if the nFA is required to reverse tunnel incoming packets to oFA because ingress filtering is enabled on its network. This establishes a BET. The tunnel lifetime requested by the nFA must be less than or equal to the tunnel lifetime offered by oFA in the HRqst(s). Section 4.6 describes the HRply(s).
b) 如果nFA发送HRply，则设置H位，并且N和R位未设置，这表示这是对HRqst的响应，即，它是HRply。如果设置了T位，则nFA指示它请求反向隧道，并且使用请求的隧道生存期设置生存期字段。只有当oFA在相应的HRqst中设置了T位，或者由于其网络上启用了入口过滤，nFA需要将传入数据包反向隧道到oFA时，才能在HRply中设置T位。这就建立了一个赌注。nFA请求的隧道寿命必须小于或等于oFA在HRqst中提供的隧道寿命。第4.6节描述了HRply。
4) The point during the L2 handoff in which the MN is no longer connected on a given link is signaled by an L2-LD trigger at oFA and MN. Completion of L2 handoff is signaled by an L2-LU trigger at nFA and MN. The trigger is handled as follows:
4) 在L2切换期间，MN不再连接在给定链路上的点由oFA和MN处的L2-LD触发器发出信号。nFA和MN处的L2-LU触发器发出L2切换完成的信号。触发器的处理方式如下：
a) When oFA receives the L2-LD trigger, it begins forwarding MN-bound packets through the forward tunnel to nFA.
a) 当oFA接收到L2-LD触发器时，它开始通过转发隧道将MN绑定的数据包转发给nFA。
b) When the nFA receives the L2-LU trigger, it begins delivering packets tunneled from oFA to MN and forwards outbound packets from MN using normal routing mechanisms or through a reverse tunnel to oFA or HA. The nFA at this point may not yet be the default router of the MN (see Section 4.4); therefore, to receive all outbound packets from the MN the nFA must send a unicast proxy ARP message (used in [1]) to the MN upon receiving an L2-LU trigger. This proxy ARP message is an ARP Reply [5] sent by the nFA on behalf of oFA, therefore supplying the nFA link-layer address in the Sender Hardware Address field and the oFA IPv4 address in the Target Protocol Address field.
b) 当nFA接收到L2-LU触发器时，它开始传送从oFA到MN的隧道数据包，并使用正常路由机制或通过反向隧道将来自MN的出站数据包转发到oFA或HA。此时nFA可能还不是MN的默认路由器（参见第4.4节）；因此，为了从MN接收所有出站数据包，nFA必须在接收到L2-LU触发器时向MN发送单播代理ARP消息（在[1]中使用）。此代理ARP消息是nFA代表oFA发送的ARP回复[5]，因此在发送方硬件地址字段中提供nFA链路层地址，在目标协议地址字段中提供oFA IPv4地址。
c) When the MN receives the L2-LU, it MAY initiate the Mobile IPv4 Registration process by soliciting an Agent Advertisement as described in [1]. If the registration is successful, the nFA takes over the role of anchor FA (aFA) from the oFA. Alternatively, the MN MAY defer the Mobile IPv4 Registration (see Section 4.4).
c) 当MN接收到L2-LU时，它可以通过请求如[1]中所述的代理广告来启动移动IPv4注册过程。如果注册成功，nFA将从oFA接管锚定FA（aFA）的角色。或者，MN可以推迟移动IPv4注册（参见第4.4节）。
5) The oFA becomes an aFA if the MN moves to a third FA before having performed a Mobile IPv4 Registration with nFA.
5) 如果MN在向nFA执行移动IPv4注册之前移动到第三FA，则oFA成为aFA。
6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a ping-pong situation arise, the oFA may be able to determine this case through the trigger mechanism (i.e., FA sees successive L2-ST/L2-TT followed by L2-LD and then L2-LU). The FA that originated the HRqst can in this case cancel the tunnel by sending an HRqst(r) to the other FA with lifetime zero. It will then simply continue delivering packets to MN exactly as if no handoff had been pending. Section 4.5 describes the HRqst(r).
6) 如果L2切换在步骤4中失败（由于L2原因），并且出现乒乓情况，oFA可以通过触发机制确定这种情况（即，FA看到连续的L2-ST/L2-TT，然后是L2-LD和L2-LU）。在这种情况下，发起HRqst的FA可以通过向另一个寿命为零的FA发送HRqst（r）来取消隧道。然后，它将继续向MN发送数据包，就像没有等待切换一样。第4.5节描述了HRqst（r）。
If the oFA sets the B bit in HRqst/HRply and the nFA has not requested a reverse tunnel by setting the T bit, the nFA SHOULD tunnel outgoing packets from the MN to the HA because the MN has requested this service from the oFA. The nFA SHOULD offer this service only if no security between the nFA and the MN's HA is required, or if there is an existing nFA-HA security association.
如果oFA在HRqst/HRply中设置了B位，并且nFA没有通过设置T位请求反向隧道，则nFA应该将传出数据包从MN隧道传输到HA，因为MN已经从oFA请求了此服务。只有在nFA和MN的HA之间不需要安全性，或者存在现有nFA HA安全关联的情况下，nFA才应提供此服务。
The actual timing of BET or unidirectional tunnel placement depends on the available L2 triggers. The forward tunnel from oFA to nFA is constructed using one of the tunneling procedures described in [1] for the HA to FA tunnel with the difference that the ends of the tunnel are at the oFA and nFA, respectively. The reverse tunnel from nFA to oFA is constructed as described in [3] with the difference that the network end of the tunnel is at the oFA instead of the HA. If both forward and reverse tunnels are established, then a BET has been established. With optimal L2 trigger information, as described above, the FAs can set up the BET immediately when the L2 handoff is initiated, start tunneling MN-bound data when the link to the MN goes down, and the nFA can use the link-up trigger to start delivering packets. In the absence of optimal L2 trigger information, the HRply can act as the trigger to start tunneling MN-bound data, but in this case, the period of packet delivery disruption to the MN could still be present and additional measures may be required to provide uninterrupted service. Particular implementation and deployment scenarios could require techniques to smooth the handoff by providing a means to convey packets arriving during the L2 handoff. The exact techniques are outside the scope of this document.
下注或单向隧道放置的实际时间取决于可用的L2触发器。从oFA到nFA的前向隧道是使用[1]中描述的HA到FA隧道的隧道程序之一建造的，不同之处在于隧道端部分别位于oFA和nFA处。从nFA到oFA的反向隧道如[3]所述构造，不同之处在于隧道的网络端位于oFA而不是HA。如果同时建立正向和反向隧道，则已建立下注。如上所述，利用最优的L2触发信息，FAs可以在L2切换启动时立即设置下注，在到MN的链路断开时开始隧道MN绑定的数据，并且nFA可以使用链路上触发来开始传送分组。在缺乏最优L2触发信息的情况下，HRply可以充当开始隧道MN绑定数据的触发，但是在这种情况下，对MN的分组传送中断的周期仍然存在，并且可能需要额外的措施来提供不间断的服务。特定的实现和部署场景可能需要通过提供一种传输在二级切换期间到达的数据包的方法来平滑切换的技术。具体技术不在本文件范围内。
Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two-party handoffs, respectively.
图7和图8分别显示了源触发器（L2-ST）和目标触发器（L2-TT）双方切换的时序图。
MN nFA oFA
| | |
| | HRqst(s) |<~~~ L2-ST
| |<------------------|
| | HRply(s) |
| |------------------>|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
MN nFA oFA
| | |
| | HRqst(s) |<~~~ L2-ST
| |<------------------|
| | HRply(s) |
| |------------------>|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 7 - Two-Party Source Trigger Handoff Timing
图7-双方源触发切换定时
MN nFA oFA
| | |
| L2-TT ~~~>| HRqst(t) |
| |------------------>|
| | HRply(t) |
| |<------------------|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
MN nFA oFA
| | |
| L2-TT ~~~>| HRqst(t) |
| |------------------>|
| | HRply(t) |
| |<------------------|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 8 - Two-Party Target Trigger Handoff Timing
图8-双方目标触发切换定时
Once the tunnel between aFA and the current FA is in place, it is torn down by one of the following events:
一旦aFA和当前FA之间的隧道就位，它将被以下事件之一拆除：
1) The aFA decides to stop tunneling because the lifetime it sent expires and was not renewed, or the aFA or current FA decide to terminate tunnel service prematurely for some other reason (refer to Section 4.3).
1) aFA决定停止隧道服务，因为其发送的生存期到期且未续期，或者aFA或当前FA决定因其他原因提前终止隧道服务（参考第4.3节）。
2) The MN completes the process by performing a Mobile IPv4 Registration with the current FA. This may be initiated by the FA that sends an Agent Advertisement or by the MN that solicits for an Agent Advertisement as in [1].
2) MN通过向当前FA执行移动IPv4注册来完成该过程。这可以由发送代理广告的FA发起，也可以由请求代理广告的MN发起，如[1]所示。
3) The MN moves to a third FA (see Section 4.2)
3) MN移动到第三个FA（见第4.2节）
Three-party handoff is applicable when an MN, which has already established an aFA and is receiving tunneled packets through its current FA, moves to a new FA without performing a Mobile IPv4 Registration.
当已经建立aFA并且正在通过其当前FA接收隧道数据包的MN在不执行移动IPv4注册的情况下移动到新FA时，三方切换适用。
The need for the three-party handoff function depends on the wireless system in which POST-REGISTRATION is being implemented. For radio L2 protocols in which it is possible for the MN to move so rapidly from one FA to another such that a probability exists that the Mobile IPv4 Registration with nFA will not complete before the MN moves on, HTT (Handoff to Third) SHOULD be implemented. Certain wireless systems and implementations do not allow such fast movement between FAs and may force the Mobile IPv4 Registration to occur soon after L2 handoff, in which case three-party handoff is not applicable. If this three-party handoff feature is not implemented, the FA SHOULD
三方切换功能的需要取决于正在实施后注册的无线系统。对于无线L2协议，其中MN可以如此快速地从一个FA移动到另一个FA，从而存在在MN移动之前无法完成nFA的移动IPv4注册的可能性，应实施HTT（切换到第三个FA）。某些无线系统和实现不允许FAs之间的这种快速移动，并且可能会迫使移动IPv4注册在L2切换后不久发生，在这种情况下，三方切换不适用。如果未实施此三方切换功能，FA应
send an Agent Advertisement to the MN after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement after L2 handoff (L2-LU at MN).
在L2切换完成后（nFA处的L2-LU）向MN发送代理播发，和/或MN应在L2切换后（MN处的L2-LU）请求代理播发。
+------+
+--->| aFA |<---+
| +------+ |
4b) HRqst(r) | | 3) HRqst(t)
HRply(r) | | HRply(t)
| |
v 2a) HRqst v
1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU
^ HRply ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b) L2-LU ~~~> | MN | --------->
+------+
+------+
+--->| aFA |<---+
| +------+ |
4b) HRqst(r) | | 3) HRqst(t)
HRply(r) | | HRply(t)
| |
v 2a) HRqst v
1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU
^ HRply ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b) L2-LU ~~~> | MN | --------->
+------+
Figure 9 - Three-Party Handoff
图9-三方切换
The L3 handoff can be deferred either because of a decision by the MN/FA (i.e., MN does not send Agent Solicitations and FA does not send Agent Advertisements), or it may result from rapid movement between oFA and nFA that does not allow enough time for the registration to complete. This scenario is shown in Figure 9. In this case, oFA must inform nFA (i.e., the third FA) to contact aFA about moving the radio end of the tunnel. This is performed with the HTT message. The general idea behind the three-party handoff procedure is that the oFA supplies nFA with the same information it would have obtained via an L2-TT if handoff had occurred from aFA to nFA; then, the nFA performs an HRqst(t)/HRply(t) sequence with aFA in order to move the BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to aFA to terminate the previous BET.
L3切换可能由于MN/FA的决定而延迟（即，MN不发送代理请求，FA不发送代理广告），也可能由于oFA和nFA之间的快速移动导致注册没有足够的时间完成。此场景如图9所示。在这种情况下，oFA必须通知nFA（即第三个FA）联系aFA移动隧道的无线电端。这是通过HTT消息执行的。三方切换程序背后的总体思想是，如果从aFA切换到nFA，oFA向nFA提供通过L2-TT获得的相同信息；然后，nFA使用aFA执行HRqst（t）/HRply（t）序列，以便将赌注移动到nFA。当L2切换完成时，oFA向aFA发送HRqst（r）以终止上一次下注。
The following describes the progress of a three-party handoff. The numbered items refer to steps in Figure 9.
以下描述三方切换的进度。编号项目参考图9中的步骤。
1) Either the oFA or nFA receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are:
1) oFA或nFA接收L2触发器，通知其某个MN即将被移动。这两个案例是：
a) The L2 trigger is a source trigger (L2-ST) at oFA. The trigger contains the MN's L2 address and an identifier for the nFA (the IPv4 address itself or an L2 address that can be mapped to the IPv4 address of the nFA).
a) L2触发器是oFA处的源触发器（L2-ST）。触发器包含MN的L2地址和nFA的标识符（IPv4地址本身或可映射到nFA的IPv4地址的L2地址）。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The trigger contains the MN's L2 address and an identifier for the oFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the oFA).
b) L2触发器是nFA的目标触发器（L2-TT）。触发器包含MN的L2地址和oFA的标识符（IPv4地址本身或可解析为oFA的IPv4地址的L2地址）。
2) The oFA and nFA exchange an HTT/HRply or HRqst/HTT pair. HTT is indicated by setting both the H and N bits in the HRqst or HRply. The HTT message MUST NOT have any tunnel flag bits set, because the tunnel is negotiated between the aFA and nFA, not oFA and nFA. There are two cases:
2) oFA和nFA交换HTT/HRply或HRqst/HTT对。通过设置HRqst或HRply中的H和N位来指示HTT。HTT消息不得设置任何隧道标志位，因为隧道是在aFA和nFA之间协商的，而不是oFA和nFA之间协商的。有两种情况：
a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA containing the MN's home IPv4 address, the MN's HA address, an LLA containing the aFA's IPv4 address, and an LLA containing the L2 address of the MN. This is enough information for nFA to perform a target-triggered handoff with aFA. The nFA responds with an HRply(s). Section 4.7 describes the HTT.
a) L2触发器是L2-ST。oFA向nFA发送HTT，其中包含MN的主IPv4地址、MN的HA地址、包含aFA的IPv4地址的LLA以及包含MN的L2地址的LLA。这对于nFA使用aFA执行目标触发的切换来说已经足够了。nFA以HRply响应。第4.7节描述了HTT。
b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA, exactly as if a two-party handoff were occurring. The oFA responds with HTT containing the same information as in a) above. This is enough information for nFA to perform a target-triggered handoff with aFA.
b) L2触发器是L2-TT。nFA向oFA发送HRqst（t），就好像双方正在进行切换一样。oFA用HTT响应，其中包含与上述a）中相同的信息。这对于nFA使用aFA执行目标触发的切换来说已经足够了。
3) Upon receipt of the HTT, the nFA first checks its Visitor Cache to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nFA performs a target-triggered handoff with aFA, exactly as in Section 4.1, exchanging an HRqst(t)/HRply(t) pair. Because aFA receives no L2 trigger indicating when L2 handoff starts, it may start tunneling to nFA upon transmission of the HRply(t).
3) 在收到HTT后，nFA首先检查其访问者缓存，以查看它是否已经在为MN进行隧道传输。如果是，则执行步骤6。如果没有，nFA将与aFA执行目标触发的切换，完全如第4.1节所述，交换HRqst（t）/HRply（t）对。因为aFA并没有接收到指示L2切换何时开始的L2触发器，所以它可以在传输HRply（t）时开始隧道传输到nFA。
4) Once the L2 handoff is under way and the MN gets disconnected at L2, aFA and oFA exchange messages canceling tunnel service between aFA and oFA and allowing aFA to start the tunnel with nFA.
4) 一旦L2切换正在进行且MN在L2断开连接，aFA和oFA交换消息，取消aFA和oFA之间的隧道服务，并允许aFA使用nFA启动隧道。
a) The point in the L2 handoff process where the MN gets disconnected from oFA is signaled at oFA by L2-LD.
a) L2切换过程中MN与oFA断开连接的点由L2-LD在oFA发出信号。
b) The oFA exchanges an HRqst(r)/HRply(r) pair having lifetime zero with aFA. This cancels tunnel service between oFA and aFA. If aFA has not already established a tunnel to nFA, it must do so immediately upon receipt of the HRqst(r). The aFA provides tunneling service exactly as described in Section 4.1, Step 4a.
b) oFA与aFA交换寿命为零的HRqst（r）/HRply（r）对。这将取消oFA和aFA之间的隧道服务。如果aFA尚未建立通往nFA的隧道，则必须在收到HRqst（r）后立即建立隧道。aFA完全按照第4.1节步骤4a所述提供隧道服务。
5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA and/or MN. The nFA and MN handle the trigger as follows:
5) nFA和/或MN处的L2-LU触发器发出L2切换完成的信号。nFA和MN按如下方式处理触发器：
a) The nFA provides packet delivery service to the MN exactly as described in Section 4.1, Step 4b.
a) nFA完全按照第4.1节步骤4b中的描述向MN提供分组递送服务。
b) The MN either defers or initiates Mobile IPv4 Registration when it receives the L2-LU, as in Section 4.1.
b) MN在收到L2-LU时延迟或启动移动IPv4注册，如第4.1节所述。
6) In the special case where nFA and aFA are the same (i.e., the MN is moving back to the original anchor FA), aFA recognizes that it is tunneling to oFA when it checks its Visitor Cache in Step 3. In this case, there is no need for aFA to send the HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger on handoff completion, the aFA begins routing packets to MN and the tunnel to nFA is torn down. The oFA still exchanges the HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a priori that aFA and nFA are the same, but they are redundant.
6) 在nFA和aFA相同的特殊情况下（即，MN正在移回原始锚FA），aFA在步骤3中检查其访问者缓存时识别出它正在隧道传输到oFA。在这种情况下，aFA不需要在步骤3中发送HRqst（t）/HRply（t）。在切换完成时收到L2-LU触发器后，aFA开始将数据包路由到MN，并且nFA的隧道被拆除。在步骤4b中，oFA仍然与aFA交换HRqst（r）/HRply（r），因为oFA无法先验地知道aFA和nFA是相同的，但它们是冗余的。
Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three-party handoff, respectively.
图10和图11分别显示了源触发器（L2-ST）和目标触发器（L2-TT）三方切换的时序图。
MN nFA oFA aFA
| | L2-ST ~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HRply(s) | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
MN nFA oFA aFA
| | L2-ST ~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HRply(s) | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 10 - Three-Party Source Trigger Handoff Timing
图10-三方源触发切换定时
MN nFA oFA aFA
| | | |
| |<~~~ L2-TT | |
| |------------->| |
| | HRqst(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
MN nFA oFA aFA
| | | |
| |<~~~ L2-TT | |
| |------------->| |
| | HRqst(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 11 - Three-Party Target Trigger Handoff Timing
图11-三方目标触发切换定时
Unlike two-party handoff, the timing of BET establishment between aFA and nFA cannot fully depend on the availability of L2 trigger information because aFA does not receive an L2 trigger signaling L2 handoff. The two timing extremes at which aFA can place the BET with nFA are:
与双方切换不同，aFA和nFA之间的BET建立时间不能完全取决于L2触发信息的可用性，因为aFA没有接收L2触发信令L2切换。aFA可以与nFA下注的两个极端时机是：
1) At the earliest, aFA MAY start tunneling packets using the BET to nFA after sending the HRply(t) to nFA in response to the request for target-triggered handoff.
1) 最早，aFA可以在响应于目标触发切换的请求而将HRply（t）发送到nFA之后，使用BET开始隧道分组到nFA。
2) At the latest, aFA MAY start tunneling packets using the BET to nFA and tear down the BET with oFA when receiving the HRqst(r) from oFA indicating that the MN has disconnected.
2) 最晚，aFA可以开始使用BET到nFA的隧道包，并在从oFA接收到指示MN已断开连接的HRqst（r）时使用oFA撕毁BET。
In addition, aFA MAY continue tunneling to oFA if 1) is selected, until the HRqst(r) is received. In this case, the result may be duplicated packets at the MN because the MN will receive packets through oFA on the old L2 until it disconnects (L2-LD). If 2) is selected, the additional latency will add to the MN's L3 service disruption period. Of course, aFA can choose to place the BET sometime between 1) and 2) if reliable bounds are available on the duration of time between L2-ST/L2-TT and the MN's disconnection (L2- LD). The exact selection of when to establish the BET is likely to
此外，如果选择了HRqst（r），则aFA可以继续隧道至oFA，直到接收到HRqst（r）。在这种情况下，结果可能是MN处的重复分组，因为MN将通过旧L2上的oFA接收分组，直到其断开连接（L2-LD）。如果选择2），则额外的延迟将增加到MN的L3服务中断期。当然，如果L2-ST/L2-TT和MN断开（L2-LD）之间的持续时间存在可靠界限，aFA可以选择在1）和2）之间的某个时间进行下注。确定下注时间的确切选择很可能
be influenced by network engineering and implementation considerations, including whether a handoff smoothing solution is used, and is beyond the scope of this specification.
受网络工程和实施考虑因素的影响，包括是否使用切换平滑解决方案，并且超出本规范的范围。
To prevent a BET from expiring when its lifetime runs out, the MN's current FA signals the aFA to either renew or terminate the BET. This may be the case when the MN defers Mobile IPv4 Registration. If no such signal is received, the aFA will terminate the BET when the lifetime expires. In addition, the current FA or aFA may need to terminate the BET prior to the lifetime expiring. In order to avoid error conditions in which tunnels do not expire even though the MN to which they apply is no longer reachable, FAs SHOULD set the tunnel lifetime field to some value other that 0xffff, which indicates "good until canceled".
为了防止投注在其生命周期结束时过期，MN的当前FA向aFA发出信号，要求其续订或终止投注。当MN延迟移动IPv4注册时可能会出现这种情况。如果未收到此类信号，aFA将在生命周期到期时终止下注。此外，当前FA或aFA可能需要在寿命到期之前终止下注。为了避免错误情况，即即使应用的MN不再可访问，隧道也不会过期，FAs应将隧道寿命字段设置为0xffff以外的某个值，该值表示“取消前良好”。
Figure 12 illustrates the message exchange that occurs between the FA needing to terminate or extend the tunnel (designated FA(1) in the figure) and the other FA (designated FA(2) in the figure). The HRqst(r)/HRply(r) is indicated by setting the R bit in the HRqst/HRply messages. If the HRqst(r) is renewing a BET, then it contains a non-zero lifetime; otherwise, if the lifetime is set to zero, it indicates tunnel termination. The aFA has complete control over whether a tunnel is extended or terminated, and it MAY reply to a request for extension with a shorter lifetime than was requested.
图12说明了需要终止或扩展隧道的FA（图中指定的FA（1））和另一个FA（图中指定的FA（2））之间发生的消息交换。通过在HRqst/HRply消息中设置r位来指示HRqst（r）/HRply（r）。如果HRqst（r）正在更新赌注，则它包含非零生存期；否则，如果生存期设置为零，则表示隧道终止。aFA可以完全控制隧道是延长还是终止，并且它可以用比请求更短的生存期来响应延长请求。
HRqst(r)
+------+ <-------- +------+
| FA(2)| ---------> | FA(1)|
+------+ HRply(r) +------+
HRqst(r)
+------+ <-------- +------+
| FA(2)| ---------> | FA(1)|
+------+ HRply(r) +------+
Figure 12 - BET Renewal or Termination
图12-赌注续约或终止
The MN/FA have control over when to perform the Mobile IPv4 Registration. Although the MN/FA may decide to defer Mobile IPv4 Registration for a certain period, three possible events can lead to the need to terminate tunneling service. If this occurs, the MN MUST perform the Mobile IPv4 Registration. These events are:
MN/FA可以控制何时执行移动IPv4注册。尽管MN/FA可能决定将移动IPv4注册延迟一段时间，但有三个可能的事件可能导致需要终止隧道服务。如果发生这种情况，MN必须执行移动IPv4注册。这些活动包括：
1) The end of life for the BET is pending and a request by the current FA to aFA for renewal has been denied, or alternatively the current FA or aFA needs to terminate the BET prematurely. The FA in this case MUST initiate the Mobile IPv4 Registration by sending an Agent Advertisement to the MN as in [1].
1) 下注的结束时间待定，当前FA向aFA提出的续约请求已被拒绝，或者当前FA或aFA需要提前终止下注。在此情况下，FA必须通过向MN发送代理播发来启动移动IPv4注册，如[1]所示。
2) The MN itself decides to perform a Mobile IPv4 Registration and initiates it by sending an Agent Solicitation as in [1].
2) MN本身决定执行移动IPv4注册，并通过发送代理请求（如[1]所示）来启动该注册。
3) During a source-triggered handoff, the oFA attempts to perform BET handoff but nFA is not capable of performing it. The FA in this case MUST initiate the Mobile IPv4 Registration by sending the MN an Agent Advertisement as in [1]. Note that this situation will never arise during target-triggered handoff because an HRqst(t) will not be sent to oFA by an nFA that doesn't support POST-REGISTRATION.
3) 在源触发切换期间，oFA尝试执行下注切换，但nFA无法执行。在这种情况下，FA必须通过向MN发送代理广告来启动移动IPv4注册，如[1]所示。请注意，在目标触发的切换过程中不会出现这种情况，因为不支持后注册的nFA不会向oFA发送HRqst（t）。
Some detailed scenarios relating to case 2) will be described hereafter. According to [1], when using an FA care-of address, the MN MAY use the FA as its default router. Otherwise, it MUST choose its default router from those advertised in the ICMP Router Advertisement portion of the Agent Advertisement. Here we assume that the FA router is also the MN's default router. In POST-REGISTRATION, when a tunnel is established between oFA and nFA and the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements to the MN. In this case, it is possible that the MN will not receive Agent Advertisements for extended periods of time. According to [8], hosts will remove default router entries if the lifetime of the Router Advertisement expires and no further advertisements are received. Note that the ICMP Router Advertisement lifetime is not related to the Registration Lifetime in the Mobility Agent Advertisement extension [1]. To avoid this disruption, the MN MUST solicit the default router (i.e., FA) before the lifetime of its active default router entry runs out, or alternatively, the FA MUST advertise as soon as the MN-nFA link is up (L2-LU). This effectively means that the MN will at most be able to defer Mobile IPv4 Registration for as long as the remaining lifetime of the active default router, as configured in the ICMP Router Advertisements. The MN MUST perform a Mobile IPv4 Registration [1] when it receives an Agent Advertisement following a POST-REGISTRATION handoff.
下文将描述与案例2）相关的一些详细场景。根据[1]，当使用FA转交地址时，MN可以使用FA作为其默认路由器。否则，它必须从代理播发的ICMP路由器播发部分中选择其默认路由器。这里我们假设FA路由器也是MN的默认路由器。在注册后，当在oFA和nFA之间建立隧道并且MN已经移动到nFA时，oFA不得向MN发送代理广告。在这种情况下，MN可能在延长的时间段内不接收代理广告。根据[8]，如果路由器播发的生存期到期并且没有收到进一步的播发，主机将删除默认路由器条目。请注意，ICMP路由器播发生存期与移动代理播发扩展[1]中的注册生存期无关。为了避免这种中断，MN必须在其活动的默认路由器条目的生存期结束之前请求默认路由器（即FA），或者，FA必须在MN-nFA链路接通（L2-LU）后立即公告。这实际上意味着MN最多能够将移动IPv4注册延迟到活动默认路由器的剩余生存期，如ICMP路由器公告中配置的那样。MN在注册后切换后收到代理播发时，必须执行移动IPv4注册[1]。
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
这是UDP（目标端口434）[1]上承载的新移动IPv4消息。UDP头后面跟着下面的字段。
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 |H|N|R|M|G|T|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 |H|N|R|M|G|T|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 16 (Handoff Request)
类型16（切换请求）
H Source-triggered handoff request. When set and the N bit is unset, indicates that the request was the result of an L2-ST at oFA.
H源触发的切换请求。当设置且N位未设置时，表示请求是oFA处L2-ST的结果。
N Target triggered handoff request. When set and the H bit is unset, indicates that the request was the result of an L2-TT at nFA.
N目标触发的切换请求。当设置且H位未设置时，表示请求是nFA的L2-TT的结果。
R Set if the request is an HRqst(r) (i.e., a request to renew the tunnel, H and N bits must be unset).
如果请求是HRqst（R）（即，更新隧道的请求，H和N位必须取消设置），则设置R。
M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.
M发布HRqst的FA将使用[1,5]中定义的隧道最小封装。
G The FA issuing the HRqst will use Generic Routing Encapsulation (GRE) [4] as defined in [1,5] for the tunnel. Extensions of HRqst containing GRE type and key Fields are outside the scope of this document.
G发布HRqst的FA将使用[1,5]中为隧道定义的通用路由封装（GRE）[4]。包含GRE类型和关键字段的HRqst扩展不在本文档范围内。
T For an HRqst(s), indicates that the oFA is willing to support both forward and reverse tunnel service. For an HRqst(t), indicates that the nFA is requesting reverse tunnel service.
对于HRqst（s），表示oFA愿意支持正向和反向隧道服务。对于HRqst（t），表示nFA正在请求反向隧道服务。
B When sent in an HRqst(s), indicates that the MN has requested a reverse tunnel to the HA and that the nFA SHOULD use a reverse tunnel to the HA if it will not be reverse tunneling to the oFA.
B当以HRqst发送时，表示MN已请求到HA的反向隧道，并且nFA应使用到HA的反向隧道，如果它不会是到oFA的反向隧道。
Lifetime The lifetime of the tunnel in seconds. If this is an HRqst(t), then the lifetime represents a request by nFA for a reverse tunnel. If this is an HRqst(s), then the lifetime represents the maximum amount of time that oFA is willing to maintain both forward and reverse tunnels. If this is an HRqst(r), then the lifetime represents a request for the amount of time to renew the tunnel's lifetime. A value of 0 on an HRqst(s) indicates that the oFA is unwilling to grant tunnel service. A value of 0 on an HRqst(t) indicates that the nFA does not require reverse tunnel service. A value of 0 on an HRqst(r) indicates that the tunnel should be terminated. A value of 0xffff indicates infinity.
寿命隧道的寿命（以秒为单位）。如果这是HRqst（t），那么生存期表示nFA对反向隧道的请求。如果这是HRqst，则寿命表示oFA愿意维持正向和反向隧道的最大时间量。如果这是一个HRqst（r），则生存期表示对隧道生存期延长时间的请求。HRqst上的值为0表示oFA不愿意授予隧道服务。HRqst（t）上的值为0表示nFA不需要反向隧道服务。HRqst（r）上的值为0表示隧道应终止。0xffff值表示无穷大。
MN Home Address For HRqst(s), the home address of the MN.
HRqst的MN家庭地址，MN的家庭地址。
HA Addr For HRqst(s), the HA address of the mobile node.
HRqst的HA地址，移动节点的HA地址。
Identification As defined in [1].
[1]中定义的标识。
Extensions The message MUST include an LLA (see Section 9) containing the MN's L2 address and an L2 address that can be mapped to an IPv4 address for the FA. This message MUST contain the FA-FA Authentication Extension [11] that is used to secure the HRqst message.
扩展消息必须包括一个LLA（见第9节），其中包含MN的L2地址和一个可以映射到FA IPv4地址的L2地址。此消息必须包含用于保护HRqst消息的FA-FA身份验证扩展[11]。
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
这是UDP（目标端口434）[1]上承载的新移动IPv4消息。UDP头后面跟着下面的字段。
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 |H|N|R|M|G|T|B| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 |H|N|R|M|G|T|B| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 17 (Handoff Reply)
类型17（切换回复）
Code A value indicating the result of the Handoff Request. Only two codes are currently supported, 0, indicating success, and 1, indicating that the handoff cannot be performed. The remaining values are for future use.
编码一个指示切换请求结果的值。当前只支持两个代码，0表示成功，1表示无法执行切换。其余值供将来使用。
Lifetime The lifetime, in seconds, for which the bidirectional tunnel for the MN will be maintained. If this is an HRply(s), then the lifetime represents a request by nFA, and it can be any value up to the maximum value sent in the HRqst(s). Larger values are assumed to default to oFA's maximum. If this is an HRply(t), then the lifetime represents the maximum amount of time that the oFA will grant to the nFA. If this is an HRply(r), then the lifetime represents the amount of time by which the tunnel life will be extended. If the Code field indicates that handoff failed, the Lifetime field will be ignored and SHOULD be set to zero. A value of 0 on an HRply(t) indicates that the oFA is unwilling to grant service. A value of 0 on an HRply(s) indicates that the nFA does not
生存期将维持MN的双向隧道的生存期，以秒为单位。如果这是一个HRply，那么生存期代表nFA的一个请求，它可以是HRqst中发送的最大值之前的任何值。假定较大的值默认为oFA的最大值。如果这是HRply（t），则寿命表示oFA将授予nFA的最大时间量。如果这是HRply（r），则寿命表示隧道寿命将延长的时间量。如果代码字段指示切换失败，则寿命字段将被忽略，并应设置为零。HRply（t）上的值为0表示oFA不愿意授予服务。HRply上的值为0表示nFA没有
require service. A value of 0 on an HRply(r) indicates that the tunnel lifetime will be terminated. A value of 0xffff indicates an infinite lifetime.
需要服务。HRply（r）上的值为0表示隧道寿命将终止。0xffff值表示无限寿命。
H Source-triggered handoff reply. When set and the N bit is unset, indicates that the reply is in response to an HRqst(s).
H源触发的切换应答。当设置且N位未设置时，表示应答是对HRqst的响应。
N Target-triggered handoff reply. When set and the H bit is unset, indicates that the reply is in response to an HRqst(t).
N目标触发的切换应答。当设置且H位未设置时，表示应答响应HRqst（t）。
R Set if the reply is an HRply(r). Neither the H nor the N bit are set.
如果应答是HRply（R），则设置R。既不设置H位也不设置N位。
M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.
M发布HRqst的FA将使用[1,5]中定义的隧道最小封装。
G The FA issuing the HRqst will use GRE [4] Encapsulation as defined in [1,5] for the tunnel. When this flag bit is set, the HRply may require extensions containing the GRE type and key fields, but they are outside the scope of this document.
G发布HRqst的FA将使用[1,5]中为隧道定义的GRE[4]封装。设置此标志位时，HRply可能需要包含GRE类型和键字段的扩展，但它们不在本文档的范围内。
T For an HRply(s), indicates that the nFA is requesting to reverse tunnel service. For an HRply(t), indicates that the oFA is willing to provide both forward and reverse tunnel service.
T表示HRply，表示nFA正在请求反向隧道服务。对于HRply（t），表示oFA愿意提供正向和反向隧道服务。
B When sent in an HRply(t), indicates that the MN has requested a reverse tunnel to the HA and that the nFA SHOULD use a reverse tunnel to the HA if it will not be reverse tunneling to the oFA. It can be set in HRply(t) only if the T bit was unset in the corresponding HRqst(t).
B当以HRply（t）发送时，表示MN已请求到HA的反向隧道，并且如果nFA将不使用到oFA的反向隧道，则nFA应使用到HA的反向隧道。只有在相应HRqst（t）中未设置t位时，才能在HRply（t）中设置。
MN Home Address For HRply(t), the home IPv4 address of the MN.
HRply（t）的MN主地址，MN的主IPv4地址。
HA Addr For HRply(t), the HA IPv4 address of the MN.
HRply（t）的HA地址，MN的HA IPv4地址。
Identification As defined in [1].
[1]中定义的标识。
Extensions This Message MUST contain the FA-FA Authentication Extension [11] that is used to secure the HRply message.
扩展此消息必须包含用于保护HRply消息的FA-FA身份验证扩展[11]。
The Handoff to Third message has the same format as the Handoff Request and Handoff Reply messages, except both the H and N bits are set. If the HTT message is in response to an L2-ST and is sent to initiate a handoff, then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRqst(s). If the HTT message is sent in response to an HRqst(t), then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRply(t). The tunnel bits MUST NOT be set in the HTT message because BET construction is not negotiated between oFA and nFA; it is negotiated between nFA and aFA in the ensuing HRqst(t)/HRply(t).
切换到第三条消息的格式与切换请求和切换回复消息的格式相同，但设置了H和N位。如果HTT消息响应L2-ST并被发送以发起切换，则除了H和N位之外，该消息具有与HRqst相同的字段集并包括相同的扩展名。如果发送HTT消息以响应HRqst（t），则除了H和N位之外，该消息具有与HRply（t）相同的字段集并包括相同的扩展名。不能在HTT消息中设置隧道位，因为oFA和nFA之间未协商BET构造；nFA和aFA在随后的HRqst（t）/HRply（t）中协商。
In addition, the HTT MUST contain the following extensions in the specified order:
此外，HTT必须按指定顺序包含以下扩展：
Solicited IPv4 Address Option: containing aFA's Address
请求的IPv4地址选项：包含aFA的地址
LLA Option: containing the L2 address of the MN.
LLA选项：包含MN的L2地址。
The POST-REGISTRATION handoff approach allows FAs to communicate directly about a pending handoff, and does not require any IPv4-layer messages to be sent to or from an MN prior to the L2 handoff event. Therefore, it eliminates a possible source of handoff latency. This may be required when the link layer imposes hard deadlines on the time at which a handoff must occur, such as when an MN is rapidly moving out of a radio coverage area. Consequently, POST-REGISTRATION is primarily of interest in handoff between FAs that support the same radio access technology. Handoff between heterogeneous radio technologies will, of necessity, require interaction between the MN and the network, and so is not a domain of applicability for POST-REGISTRATION.
注册后切换方法允许FAs直接就挂起的切换进行通信，并且不需要在L2切换事件之前向MN发送或从MN发送任何IPv4层消息。因此，它消除了切换延迟的可能来源。当链路层对必须发生切换的时间施加硬截止日期时，例如当MN快速移出无线电覆盖区域时，这可能是必需的。因此，后注册主要关注支持相同无线接入技术的FAs之间的切换。异构无线电技术之间的切换必然需要MN和网络之间的交互，因此不是注册后的适用范围。
Because a POST-REGISTRATION handoff is triggered by an unspecified mechanism that informs the oFA or nFA that an L2 handoff is pending, the POST-REGISTRATION approach is only applicable to networks where such a mechanism is available. For example, an L2 may provide indications of radio signal quality that cause the oFA or nFA to send the POST-REGISTRATION handoff messages. Any such indications must also provide each FA involved in the handoff with the identity of the other, so that messages can be sent to the right place. This may involve mapping L2 information onto FA IPv4 addresses. Also, the FAs involved in a handoff must have pre-provisioned security arrangements so that the POST-REGISTRATION messages can be authenticated. If a handoff is to be completed as a result of the POST-REGISTRATION
由于注册后切换由通知oFA或nFA二级切换待定的未指定机制触发，因此注册后方法仅适用于存在此类机制的网络。例如，L2可以提供导致oFA或nFA发送注册后切换消息的无线电信号质量的指示。任何此类指示还必须向参与切换的每个FA提供另一个FA的身份，以便将消息发送到正确的位置。这可能涉及将L2信息映射到FA IPv4地址。此外，切换中涉及的FAs必须具有预先设置的安全安排，以便可以对注册后消息进行身份验证。如果由于后注册而要完成切换
messaging, any L2 handoff indications must also be securely authenticated so that traffic to the old point of attachment is not improperly halted.
消息传递时，任何L2切换指示也必须安全地进行身份验证，以便到旧连接点的通信不会不正确地停止。
POST-REGISTRATION handoff is appropriate in the following cases:
在以下情况下，注册后移交是合适的：
- L2 triggers are available on the network to indicate that L2 handoff is pending.
- 二级触发器在网络上可用，以指示二级切换处于挂起状态。
- Pre-provisioned security mechanisms are in place to allow fast and secure messaging between the FAs and between the MN and an FA.
- 预先配置的安全机制已就位，以允许FAs之间以及MN和FA之间的快速安全消息传递。
- Access point choice by the MN is not a concern or the choice requires user intervention and therefore is not on the critical path for handoff.
- MN选择接入点不是一个问题，或者该选择需要用户干预，因此不在切换的关键路径上。
The combined method uses both PRE-REGISTRATION and POST-REGISTRATION handoff. If PRE-REGISTRATION does not complete prior to the expiration of a timer on the nFA, the POST-REGISTRATION mechanism is used to create the tunnel between oFA and nFA. This protects the MN from delays caused by errors such as loss of the Mobile IPv4 Registration Reply message involved in PRE-REGISTRATION for the mobile-initiated and network-initiated source-triggered cases. It also protects the MN from delays caused by errors or the loss of any of the Mobile IPv4 messages involved in PRE-REGISTRATION for the network-initiated target-triggered case.
该组合方法同时使用注册前和注册后切换。如果预注册未在nFA上的计时器到期之前完成，则使用后注册机制在oFA和nFA之间创建隧道。这可以保护MN免受由错误引起的延迟，例如在移动启动和网络启动的源触发案例的预注册中涉及的移动IPv4注册回复消息丢失。它还可以防止MN因网络启动的目标触发案例的预注册所涉及的任何移动IPv4消息的错误或丢失而导致的延迟。
When the nFA receives a target trigger, it will follow the PRE-REGISTRATION procedure. When the combined method is used, the nFA MUST also start a timer when it receives a target trigger. The timer should be set to a small value (default for target trigger case: 1 second).
当nFA收到目标触发器时，它将遵循预注册程序。当使用组合方法时，nFA还必须在收到目标触发器时启动计时器。定时器应设置为一个小值（目标触发情况的默认值：1秒）。
According to PRE-REGISTRATION, the nFA will receive the Registration Request from the MN. When the combined method is used, this Registration Request sent by the MN MUST contain the IPv4 address of the oFA in an FA IPv4 address LLA extension (see Section 9.7). This same Registration Request message will contain multiple LLA extensions, since it will also contain the MN's layer 2 address in an LLA extension as described for PRE-REGISTRATION (see Sections 3.7 and 9). When the nFA has not started the handoff procedure using a target trigger (i.e., mobile-initiated or network-initiated target-triggered cases), the nFA MUST start a timer as soon as it receives the low-latency Registration Request from the MN. This timer should be set to a small value (default: 1 second).
根据预注册，nFA将收到MN的注册请求。使用组合方法时，MN发送的此注册请求必须包含FA IPv4地址LLA扩展中oFA的IPv4地址（请参阅第9.7节）。同一个注册请求消息将包含多个LLA扩展，因为它还将在LLA扩展中包含MN的第2层地址，如预注册所述（参见第3.7节和第9节）。当nFA没有使用目标触发器（即，移动启动或网络启动的目标触发情况）启动切换过程时，nFA必须在收到来自MN的低延迟注册请求后立即启动计时器。此计时器应设置为较小的值（默认值：1秒）。
In all cases, the timer MUST be reset when the Registration Reply message is received by nFA. If the timer expires before the Registration Reply is received, the nFA MUST initiate the POST-REGISTRATION procedure. The nFA utilizes the oFA IPv4 address (previously received in the extension to the Registration Request message) as the destination of the POST-REGISTRATION HRqst message to create the tunnel between nFA and oFA. The nFA MAY tear down this tunnel when it receives and forwards a successful Registration Reply for that MN.
在所有情况下，当nFA收到注册回复消息时，必须重置计时器。如果计时器在收到注册回复之前过期，nFA必须启动注册后程序。nFA利用oFA IPv4地址（先前在注册请求消息的扩展中接收）作为注册后HRqst消息的目的地来创建nFA和oFA之间的隧道。当nFA接收并转发该MN的成功注册回复时，nFA可以拆除该隧道。
In the optimal cases considered in the PRE-REGISTRATION and POST-REGISTRATION handoffs, it was assumed that a timely L2 trigger would be received in such a way that packets could be delivered to the MN via its nFA immediately upon connection. In this way, the MN does not suffer disruption due to the L3 handoff. However, such precise timing of the L2 trigger and handoff mechanism with respect to the actual L2 handoff event will not be possible in all wireless systems and may depend on particular implementation techniques. Therefore, some uncertainty may exist at L3 as to exactly when the L2 connection between the MN and the nFA becomes fully established and can be used for L3 traffic. It is possible that in certain implementations traffic will be re-routed too early or too late with respect to the moment when the connection between the MN and the nFA becomes fully established. The techniques that may solve this problem and allow the MN to receive traffic independently of the timing of the L2 handoff event include buffering and simultaneous bindings (i.e., bicasting: setting the S bit [1] in Registration Requests). However, these are optional and are not mandated.
在注册前和注册后切换中考虑的最佳情况下，假设及时的L2触发器将以这样的方式接收，即分组可以在连接后立即通过其nFA传送到MN。这样，MN不会因L3切换而受到干扰。然而，对于实际的二级切换事件，二级触发和切换机制的这种精确定时在所有无线系统中都是不可能的，并且可能取决于特定的实现技术。因此，关于MN和nFA之间的L2连接何时完全建立并可用于L3业务，在L3处可能存在一些不确定性。在某些实现中，相对于MN和nFA之间的连接完全建立的时刻，业务将被重新路由得太早或太迟是可能的。可以解决该问题并允许MN独立于L2切换事件的定时接收业务的技术包括缓冲和同时绑定（即，双播：在注册请求中设置S比特[1]）。但是，这些是可选的，不是强制性的。
The handoff methods all support reverse tunneling. The MN may request reverse tunneling [3] by setting the T bit in its Registration Request. In the case of POST-REGISTRATION, if the MN had requested reverse tunneling previously at oFA, the handoff message from oFA (see Section 4) includes the T bit enabled to inform nFA to establish a BET for the visitor entry. Typically, the T bit will always be set to ensure that any delays in the MN receiving its new care-of address do not result in any delay in uplink packet transmission from the MN, but local policies and particular L2 technologies may allow the reverse tunnel to be turned off.
切换方法都支持反向隧道。MN可以通过在其注册请求中设置T位来请求反向隧道[3]。在后注册的情况下，如果MN先前在oFA处请求反向隧道，则来自oFA的切换消息（参见第4节）包括T位，该T位被启用以通知nFA为访客进入建立赌注。通常，T比特将始终被设置为确保MN中接收其新转交地址的任何延迟不会导致来自MN的上行链路分组传输中的任何延迟，但是本地策略和特定L2技术可允许关闭反向隧道。
In general and to a greater extent in wireless networks, packets carrying handoff signaling may be dropped or lost due to errors on the link. In this section, we consider mechanisms for recovery from handoff signaling failures.
通常，在无线网络中，由于链路上的错误，承载切换信令的分组可能会被丢弃或丢失。在本节中，我们考虑从切换信令失败中恢复的机制。
Failure of PRE-REGISTRATION signaling breaks down into three cases:
预注册信号失败分为三种情况：
1) Loss of messages PrRtSol and PrRtAdv on the air link.
1) 空中链路上的消息PrRtSol和PrRtAdv丢失。
2) Loss of the solicitation by an FA to obtain another neighboring FA's Advertisement or loss of the neighboring FA's advertisement.
2) 一个FA为获取另一个相邻FA的广告而进行的招揽失败或相邻FA的广告失败。
3) Failure of the standard Mobile IPv4 Registration.
3) 标准移动IPv4注册失败。
Of these, case 3) is handled by standard Mobile IPv4 mechanisms described in [1]. Case 2) is expected to be a rare event because spontaneous packet drop rates on the fixed network are caused by congestion or router failure. Since bit error rates on wireless links are higher than on fixed links, case 1) is more likely to occur. In the following subsections, cases 1) and 2) are considered.
其中，情况3）由[1]中描述的标准移动IPv4机制处理。案例2）预计将是一个罕见的事件，因为固定网络上的自发丢包率是由拥塞或路由器故障引起的。由于无线链路上的误码率高于固定链路上的误码率，因此情况1）更可能发生。在以下小节中，将考虑情况1）和2）。
PRE-REGISTRATION handoff can fail in network-initiated handoff when the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or the advertisement sent by nFA in response to the target trigger (L2- TT) fails to reach the MN. PRE-REGISTRATION handoff can also fail in mobile-initiated handoff when either the PrRtSol sent from the MN or return PrRtAdv sent from the oFA is dropped. To reduce the probability that PrRtAdv and PrRtSol are lost, the MN and FA MAY transmit multiple copies of these messages. Should these messages fail anyway, in both cases the MN connects to the nFA without having received any prior signaling. In this case, the MN solicits an FA Advertisement when it connects to nFA at L2 (L2-LU), as described in Section 3.6, and performs a standard Mobile IPv4 Registration with the nFA as specified in [1].
当oFA为响应源触发器（L2-ST）而发送的PrRtAdv或nFA为响应目标触发器（L2-TT）而发送的广告未能到达MN时，在网络发起的切换中，预注册切换可能失败。当从MN发送的PrRtSol或从oFA发送的返回PrRtAdv被丢弃时，在移动发起的切换中，预注册切换也可能失败。为了降低PrRtAdv和PrRtSol丢失的概率，MN和FA可以发送这些消息的多个副本。如果这些消息无论如何都失败了，在这两种情况下，MN连接到nFA而没有接收到任何先前的信令。在这种情况下，如第3.6节所述，MN在L2（L2-LU）连接到nFA时请求FA广告，并按照[1]中的规定向nFA执行标准移动IPv4注册。
The solicitation from an FA to another neighboring FA may fail or the corresponding advertisement from the neighboring FA may be lost. To reduce the probability that these messages are lost, the FAs MAY transmit multiple copies of these messages. If a failure occurs anyway, the FA soliciting the Agent Advertisement is unable to send a PrRtAdv in response to a source trigger or to a mobile-initiated PrRtSol. In these cases, when the MN does not receive a notification or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a standard Mobile IPv4 Registration as soon as it connects to the nFA (L2-LU) as described in Section 8.1.1.
从一个FA到另一个相邻FA的请求可能失败，或者来自相邻FA的相应广告可能丢失。为了降低这些消息丢失的可能性，FAs可以传输这些消息的多个副本。如果仍然发生故障，请求代理广告的FA无法发送PrRtAdv以响应源触发器或移动启动的PrRtSol。在这些情况下，当MN没有收到预注册切换的通知或确认时，MN必须在连接到nFA（L2-LU）后立即执行标准移动IPv4注册，如第8.1.1节所述。
Failure occurs in POST-REGISTRATION when either the HRqst or HRply message is dropped. The effects of the failure and the recovery procedure depend on which message is dropped, and whether the handoff is source or target triggered. Since all of the POST-REGISTRATION signaling is going over the fixed network, it can be expected that spontaneous dropping of packets in the absence of congestion and router failure should be a relatively rare event. Nevertheless, failure recovery mechanisms SHOULD be implemented.
当删除HRqst或HRply消息时，在注册后发生故障。故障的影响和恢复过程取决于丢弃的消息，以及切换是源触发还是目标触发。由于所有注册后信令都是通过固定网络进行的，因此可以预期，在没有拥塞和路由器故障的情况下，数据包的自发丢弃应该是一种相对罕见的事件。然而，应实施故障恢复机制。
If the HRqst message is dropped, the effect is the same for both source- and target-triggered handoffs. In either case, the FA to which the HRqst was destined will never respond with an HRply message. If the handoff is source triggered, then the nFA never learns of the handoff, and the oFA never receives confirmation. If the handoff is target-triggered, then the oFA never learns of the handoff, and the nFA never receives confirmation.
如果删除HRqst消息，则源触发切换和目标触发切换的效果相同。在任何一种情况下，HRqst的目的地FA都不会以HRply消息进行响应。如果切换是源触发的，那么nFA永远不会知道切换，oFA也永远不会收到确认。如果切换是目标触发的，则oFA永远不会知道切换，nFA永远不会收到确认。
The recovery procedure in this case is as follows: the oFA MUST NOT construct a forward tunnel when the MN moves off-link (L2-LD) if the handoff is source-triggered, and the nFA MUST NOT construct a reverse tunnel if the handoff is target triggered. If the nFA was not informed of the handoff by an HRqst message (corresponding to failure of source-triggered handoff) or if the handoff was not confirmed by an HRply message (corresponding to failure of target-triggered handoff), the nFA MUST unicast an Agent Advertisement to the MN as soon as its L2 connection is established (L2-LU at nFA).
这种情况下的恢复过程如下：如果切换是源触发的，则当MN脱离链路（L2-LD）时，oFA不得构建前向隧道；如果切换是目标触发的，则nFA不得构建反向隧道。如果nFA没有通过HRqst消息（对应于源触发的切换失败）通知切换，或者如果切换没有通过HRply消息（对应于目标触发的切换失败）确认，则nFA必须在其L2连接建立后（nFA处的L2-LU）立即向MN单播代理播发。
If the HRply message is dropped, the FA sending the HRply will assume that the handoff has been confirmed, but the FA that is expecting to receive the HRply does not receive confirmation. In this case, the failure recovery procedure is different for source-triggered and target-triggered handoffs.
如果HRply消息被丢弃，则发送HRply的FA将假定切换已被确认，但是期望接收HRply的FA没有接收到确认。在这种情况下，源触发切换和目标触发切换的故障恢复过程不同。
In a target-triggered handoff, the oFA assumes that the handoff is confirmed because it has sent the HRply, but the nFA has not received it so it does not have confirmation. The oFA starts tunneling packets to the nFA when the MN moves from its link (L2-LD). The nFA MUST send an FA Advertisement to the MN as soon as its L2 link is up (L2-LU at nFA) and MAY drop the tunneled packets. The nFA SHOULD send an ICMP Destination Unreachable [9] message to the oFA. When the oFA receives this message, it will terminate the tunnel and stop forwarding packets. If reverse tunneling was requested, the nFA MUST NOT reverse tunnel because it has not received handoff confirmation.
在目标触发的切换中，oFA假设切换已确认，因为它已发送HRply，但nFA尚未收到它，因此它没有确认。当MN从其链路（L2-LD）移动时，oFA开始将数据包隧道传输到nFA。nFA必须在其L2链路接通时（nFA处的L2-LU）立即向MN发送FA广告，并且可以丢弃隧道包。nFA应向oFA发送ICMP目的地不可到达[9]消息。当oFA收到此消息时，它将终止隧道并停止转发数据包。如果请求反向隧道，nFA不得反向隧道，因为它没有收到切换确认。
In source-triggered handoff, the nFA assumes that the handoff is confirmed because it has sent the HRply, but the oFA has not received it so it does not have confirmation. Without failure recovery, the MN could move to the nFA without the oFA being able to start the forward tunnel for the MN's packets, and the MN would not be able to initiate a Mobile IPv4 Registration because it does not know that the handoff has failed. In this situation, the oFA MUST send out an HRqst message to the nFA with lifetime zero as soon as the MN leaves its link (L2-LD). The oFA SHOULD continue to retransmit the HRqst message, with exponential backoff for CONFIG-HFAIL seconds or until it receives an HRply acknowledging the request to cancel the tunnel. The default value for CONFIG-HFAIL is 10 seconds. When the nFA receives the HRqst, it MUST immediately send an Agent Advertisement to the MN, as is the case whenever a tunnel is canceled. In addition, the oFA MUST also drop any packets received through the reverse tunnel from the nFA. The oFA SHOULD NOT send the ICMP Destination Unreachable message to the nFA because the nFA has been informed by the HRqst message to cancel the tunnel. However, if the nFA receives an ICMP Destination Unreachable message for the tunnel prior to receiving the HRqst canceling the tunnel, it MUST send an FA Advertisement to the MN and cancel the tunnel.
在源触发切换中，nFA假设切换已确认，因为它已发送HRply，但oFA未接收到它，因此它没有确认。如果没有故障恢复，MN可以移动到nFA，而oFA无法启动MN分组的转发隧道，并且MN将无法启动移动IPv4注册，因为它不知道切换失败。在这种情况下，一旦MN离开其链路（L2-LD），oFA必须向nFA发送生存期为零的HRqst消息。oFA应继续重新传输HRqst消息，指数退避CONFIG-HFAIL秒，或直到收到确认取消隧道请求的HRply。CONFIG-HFAIL的默认值为10秒。当nFA收到HRqst时，它必须立即向MN发送代理广告，就像取消隧道一样。此外，oFA还必须丢弃通过反向隧道从nFA接收的任何数据包。oFA不应向nFA发送ICMP目的地不可到达消息，因为HRqst消息已通知nFA取消隧道。然而，如果nFA在接收取消隧道的HRqst之前接收到隧道的ICMP目的地不可到达消息，则它必须向MN发送FA广告并取消隧道。
This section defines the Generalized Link Layer and IPv4 Address (LLA) Extension, used by any node that needs to communicate link layer and IPv4 addresses. The format of the extension relies on sub-types, where each sub-type defines its own sub-structure. This document defines six sub-types. Future RFCs should allocate their own sub-type and define their own address formats.
本节定义了通用链路层和IPv4地址（LLA）扩展，供需要通信链路层和IPv4地址的任何节点使用。扩展的格式依赖于子类型，其中每个子类型定义自己的子结构。本文档定义了六个子类型。未来的RFC应该分配自己的子类型并定义自己的地址格式。
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 | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
138 (skippable) [1] - when used in Registration Requests 140 (skippable) [1] - when used in Agent Advertisements
138（可跳过）[1]-当用于注册请求时140（可跳过）[1]-当用于代理播发时
Length
长
The length of the Link Layer Address + the one-octet Sub-Type field
链路层地址的长度+一个八位组子类型字段
Sub-Type
子类型
This field contains the Link Layer sub-type identifier
此字段包含链接层子类型标识符
LLA
拉拉
Contains the Link Layer Address
包含链接层地址
In this document, seven sub-types are defined:
在本文件中，定义了七个子类型：
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
The following subsections describe the extensions.
以下小节描述了这些扩展。
The IMSI Link Layer Address Extension contains the International Mobile Station Identity (IMSI).
IMSI链路层地址扩展包含国际移动台标识（IMSI）。
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
1 (skippable) [1]
1（可跳过）[1]
Length
长
The length of the IMSI field + the one-octet Sub-Type field
IMSI字段的长度+一个八位组子类型字段
Sub-Type
子类型
1
1.
IMSI
IMSI
Contains the IMSI, in the form: <IMSI>:<Connection Id> Where the <IMSI> is an ASCII-based representation of the International Mobile Station Identity, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same mobile device.
包含IMSI，格式为：<IMSI>：<Connection Id>，其中<IMSI>是基于ASCII的国际移动台标识表示，最高有效位在前，“：”是ASCII 0x3a，连接Id是小的，十进制数字，用于区分同一移动设备的不同链路层连接。
The IMSI Link Layer Address Extension contains the International Mobile Station Identity.
IMSI链路层地址扩展包含国际移动站标识。
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
2 (skippable) [1]
2（可跳过）[1]
Length
长
The length of the IMSI field + the one-octet Sub-Type field
IMSI字段的长度+一个八位组子类型字段
Sub-Type
子类型
2
2.
IMSI
IMSI
Contains the IMSI, a number composed of 15 digits or less, coded as described in [15].
包含IMSI，一个由15位或更少数字组成的数字，编码如[15]所述。
The Ethernet Link Layer Address Extension contains the 48-bit Ethernet MAC Address, as defined in [5].
以太网链路层地址扩展包含[5]中定义的48位以太网MAC地址。
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
3 (skippable) [1]
3（可跳过）[1]
Length
长
7 (includes the Sub-Type field)
7（包括子类型字段）
Sub-Type
子类型
3
3.
MAC
雨衣
Contains the 48-bit Ethernet MAC Address.
包含48位以太网MAC地址。
The 64-bit Global Identifier (EUI-64) Address Extension contains the 64-bit address, as defined in [6].
64位全局标识符（EUI-64）地址扩展包含[6]中定义的64位地址。
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
4 (skippable) [1]
4（可跳过）[1]
Length
长
9 (includes the Sub-Type field)
9（包括子类型字段）
Sub-Type
子类型
4
4.
MAC
雨衣
Contains the 64-bit Global Identifier Address.
包含64位全局标识符地址。
The 32-bit Solicited IPv4 Address Extension contains the IPv4 address of the agent (FA) being solicited. This extension MAY be present in an ICMP Agent Solicitation as explained in Section 3.3.
32位请求的IPv4地址扩展包含请求的代理（FA）的IPv4地址。如第3.3节所述，此扩展可能出现在ICMP代理请求中。
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
5 (skippable) [1]
5（可跳过）[1]
Length
长
5 (includes the Sub-Type field)
5（包括子类型字段）
Sub-Type
子类型
5
5.
IPv4 Address
IPv4地址
Contains the 32-bit IPv4 Address of the solicited node.
包含请求节点的32位IPv4地址。
The 32-bit Access Point Identifier Extension contains an identifier of the access point to which the MN will move. This may be a wireless L2 identifier. The MN is able to solicit an advertisement from the FA servicing a certain access point by using this extension with Agent Solicitations as explained in Section 3.3.
32位接入点标识符扩展包含MN将移动到的接入点的标识符。这可能是无线L2标识符。如第3.3节所述，MN可以通过使用此扩展和代理请求，从为特定接入点提供服务的FA处请求广告。
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 | Sub-Type | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
6 (skippable) [1]
6（可跳过）[1]
Length
长
5 (includes the Sub-Type field)
5（包括子类型字段）
Sub-Type
子类型
6
6.
AP ID
AP ID
Contains the 32-bit Access Point Identifier.
包含32位访问点标识符。
The 32-bit FA IPv4 Address Extension contains the IPv4 address of the agent (FA). This extension MAY be present in a Registration Request message to identify the oFA as explained in Section 5.
32位FA IPv4地址扩展包含代理（FA）的IPv4地址。如第5节所述，该扩展可以出现在注册请求消息中，以识别oFA。
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
7 (skippable) [1]
7（可跳过）[1]
Length
长
5 (includes the Sub-Type field)
5（包括子类型字段）
Sub-Type
子类型
7
7.
IPv4 Address
IPv4地址
Contains the 32-bit IPv4 Address of the FA node.
包含FA节点的32位IPv4地址。
This document defines one new extension to Mobile IPv4 Control messages and one new extension to Mobile IPv4 Router Discovery messages already maintained by IANA. This document also defines a new Mobile IPv4 Control message type to be used between FAs. To ensure correct interoperation based on this specification, IANA must reserve values in the Mobile IPv4 number space for two new extensions and one new message type. IANA must also manage the numbering spaces created by the two new extensions, the message type, and its associated Code field.
本文档定义了移动IPv4控制消息的一个新扩展和IANA已维护的移动IPv4路由器发现消息的一个新扩展。本文档还定义了FAs之间要使用的新移动IPv4控制消息类型。为了确保基于此规范的正确互操作，IANA必须在移动IPv4号码空间中为两个新扩展名和一个新消息类型保留值。IANA还必须管理由两个新扩展名、消息类型及其关联的代码字段创建的编号空间。
Section 9 introduces two extensions.
第9节介绍了两个扩展。
Generalized Link Layer and IPv4 Address (LLA) Extension for Router Discovery messages: A new Mobile IPv4 extension that follows after Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent Advertisements). The type value of this extension belongs to the
路由器发现消息的通用链路层和IPv4地址（LLA）扩展：在移动IPv4 ICMP路由器发现消息（例如，移动IP代理播发）之后的新移动IPv4扩展。此扩展的类型值属于
Mobile IPv4 number space for Router Discovery messages maintained by IANA. The value assigned by IANA is 140. This new extension uses the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
IANA维护的路由器发现消息的移动IPv4号码空间。IANA分配的值为140。此新扩展使用需要IANA管理的链路层和IPv4地址标识符（LLA）子类型编号空间（请参阅第10.2节）。
Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP Control messages: A new Mobile IPv4 extension appended to Mobile IP Control messages (e.g., Registration Request). The type value of this extension belongs to the Mobile IPv4 number space for extensions to Mobile IPv4 Control messages maintained by IANA. It MUST be in the skippable (128-255) range as defined in [1]. The value assigned is 138 by IANA. This new extension uses the Link Layer and IP Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
移动IP控制消息的通用链路层和IPv4地址（LLA）扩展：附加到移动IP控制消息（例如，注册请求）的新移动IPv4扩展。此IPv4移动扩展的IPv4值所属的移动控制空间类型的IPv4扩展属于。它必须在[1]中定义的可跳过（128-255）范围内。IANA分配的值为138。此新扩展使用需要IANA管理的链路层和IP地址标识符（LLA）子类型编号空间（见第10.2节）。
10.2. Generalized Link Layer and IP Address Identifier (LLA) Sub-type Values
10.2. 通用链路层和IP地址标识符（LLA）子类型值
This section describes the sub-type values that are applicable to both the Generalized LLA Extensions for Mobile IP Control and Router Discovery messages. This specification makes use of the sub-type values 1-7, and all other values other than zero (reserved) are available for assignment via IETF consensus [14]. The seven sub-type values defined in this specification are:
本节介绍适用于移动IP控制和路由器发现消息的通用LLA扩展的子类型值。本规范使用子类型值1-7，除零（保留）外的所有其他值可通过IETF协商一致[14]分配。本规范中定义的七个子类型值为：
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
Sections 4.5 and 4.6 define two new Mobile IPv4 message types: Handoff Request and Handoff Reply. These require two type numbers to be assigned by IANA from the Mobile IPv4 Control message type address space. The Handoff Reply message also introduces its own Code field that requires IANA to manage a new Code address space. This specification makes use of the Code values 0-1, where 0 identifies a successful handoff and 1 defines a generic handoff failure. All other values are available for assignment via IETF consensus [14].
第4.5节和第4.6节定义了两种新的移动IPv4消息类型：切换请求和切换回复。这些要求IANA从移动IPv4控制消息类型地址空间分配两个类型号。切换回复消息还引入了自己的代码字段，要求IANA管理新的代码地址空间。本规范使用代码值0-1，其中0表示成功切换，1表示一般切换失败。所有其他值可通过IETF协商一致意见分配[14]。
Code Values for Mobile IP Handoff Reply Messages
移动IP切换回复消息的代码值
0 Successful Handoff 1 Generic Handoff Failure 2-255 Unallocated
0成功切换1一般切换失败2-255未分配
For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA and nFA MUST share a security association to authenticate and integrity protect messages transported between them. In addition, oFA must be authorized to solicit nFA based on the security association. The minimal requirement to establish a security association between FAs is that both FAs support manual pre-configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The inter-FA ICMP messages (solicitations and advertisements) MUST be authenticated and integrity protected using ESP [10]. The default ESP authentication algorithm for use in this specification is HMAC-SHA1-96 [12]. The absence of this security would allow denial-of-service attacks from malicious nodes at any distance from the FA. To secure Registration Request and Reply messages, PRE-REGISTRATION uses the security mechanisms already described in [1] and optionally [11].
对于预注册方法，如第3.8节所述，oFA和nFA必须共享一个安全关联，以对它们之间传输的消息进行身份验证和完整性保护。此外，必须授权oFA根据安全协会征集nFA。在FAs之间建立安全关联的最低要求是两个FAs都支持手动预配置涉及共享密钥的安全关联。还可以使用基于共享秘密或公钥的使用IKE[16]建立安全关联的其他机制。必须使用ESP对FA间ICMP消息（请求和公告）进行身份验证和完整性保护[10]。本规范中使用的默认ESP认证算法为HMAC-SHA1-96[12]。缺乏这种安全性将允许来自距离FA任意距离的恶意节点的拒绝服务攻击。为了保护注册请求和回复消息的安全，预注册使用[1]和[11]中已经描述的安全机制。
POST-REGISTRATION introduces a new change to Mobile IPv4, which is the possibility that an MN may receive packets from an FA with which it has not yet performed a Mobile IPv4 Registration. It is not recommended that the MN drop packets from unknown FAs since it would effectively eliminate the advantages of POST-REGISTRATION. From a security viewpoint, dropping packets from unknown FAs would not provide significant protection for an MN from any attack. This is because any malicious host may use the MN's home address to send packets to the MN through its current known FA; therefore, processing packets received from unknown FAs would not provide worse security than with normal Mobile IPv4.
注册后对移动IPv4进行了新的更改，即MN可能从尚未执行移动IPv4注册的FA接收数据包。不建议MN从未知FAs丢弃数据包，因为这将有效地消除注册后的优势。从安全角度来看，从未知FA丢弃数据包不会为MN提供任何攻击的重要保护。这是因为任何恶意主机都可能使用MN的主地址通过其当前已知FA向MN发送数据包；因此，处理从未知FAs接收的数据包不会提供比普通移动IPv4更差的安全性。
In a similar way to PRE-REGISTRATION, in POST-REGISTRATION, oFA and nFA MUST share a security association required to protect the Handoff Request and Reply messages. The minimal requirement to establish a security association between FAs is that the FAs support manual pre-configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The Handoff Request and Reply messages MUST be authenticated using the FA-FA authentication extension [11] that uses the default algorithm specified in [7]. The absence of this security would allow impersonation attacks and denial-of-service attacks.
与预注册类似，在注册后，oFA和nFA必须共享保护切换请求和回复消息所需的安全关联。在FAs之间建立安全关联的最低要求是FAs支持手动预配置涉及共享密钥的安全关联。还可以使用基于共享秘密或公钥的使用IKE[16]建立安全关联的其他机制。切换请求和应答消息必须使用FA-FA身份验证扩展[11]进行身份验证，该扩展使用[7]中指定的默认算法。缺少此安全性将允许模拟攻击和拒绝服务攻击。
The minimal requirement is that all FAs involved in low latency handoffs MUST support manual pre-configuration of peer-to-peer security associations with neighboring FAs, involving shared secrets and are already required to support the default algorithms of [1]. Other mechanisms to establish security associations using IKE [16] based on shared or public keys may also be used.
最低要求是，参与低延迟切换的所有FA必须支持手动预配置与相邻FA的对等安全关联，涉及共享机密，并且已经需要支持[1]的默认算法。还可以使用基于共享密钥或公钥的使用IKE[16]建立安全关联的其他机制。
Since the techniques outlined in this document depend on particular L2 information (triggers) to optimize performance, some level of L2 security is assumed. Both PRE- and POST-REGISTRATION techniques depend on L2 triggers, but the L2 security implications are different for the two techniques.
由于本文档中概述的技术依赖于特定的二级信息（触发器）来优化性能，因此假定具有一定级别的二级安全性。预注册和后注册技术都依赖于L2触发器，但这两种技术的L2安全含义不同。
In particular, in POST-REGISTRATION, the L2 triggers initiate the establishment of tunnels that route IPv4 packets for the MN to its new location. Therefore, the L2 triggers MUST be secured against any tampering by malicious nodes, either mobile or within the wired network. The L2 addresses or IPv4 addresses for the MN and the FAs that appear in the L2 triggers MUST correspond to the actual nodes that are participating in the handoff. If there is any possibility that tampering may occur, the recipient of an L2 trigger MUST have some way of authenticating the L2 information. Wireless networks that do not provide such features will be subject to impersonation attacks, where malicious nodes could cause FAs to believe that an MN has moved to other service areas or to allow a bogus MN to obtain unauthorized service from an FA prior to performing a Mobile IPv4 Registration. In POST-REGISTRATION, the L2 triggers would typically be sent between a wireless base station and the FA. No standard protocol exists at this time to communicate the L2 trigger information, but it is important that any future protocol used for this purpose provides adequate security. If the wireless base station and FA were integrated, then this security threat would not apply. Also the layer 2 control messages on the wireless link must be secured appropriately to prevent a malicious node from running impersonation attacks and causing unwanted L2 triggers to be generated. Integrity and replay protection would be required to avoid impersonation threats and resource consumption threats where a malicious node replays old messages to cause resource consumption. This depends on the type of L2 security of the wireless link. For example, in cellular technologies, the control messages are secured, although the type of security varies depending on the cellular standard, but this is not typically the case in WLAN IEEE 802.11 networks.
特别是，在注册后，L2触发器启动建立隧道，将MN的IPv4数据包路由到其新位置。因此，L2触发器必须受到保护，以防恶意节点（移动或有线网络内）的任何篡改。L2触发器中出现的MN和FAs的L2地址或IPv4地址必须对应于参与切换的实际节点。如果有可能发生篡改，L2触发器的接收者必须有某种方式来验证L2信息。不提供此类功能的无线网络将受到模拟攻击，其中恶意节点可能导致FAs相信MN已移动到其他服务区域，或允许虚假MN在执行移动IPv4注册之前从FA获得未经授权的服务。在后注册中，L2触发器通常在无线基站和FA之间发送。目前还没有标准的协议来传递L2触发器信息，但重要的是，用于此目的的任何未来协议都应提供足够的安全性。如果无线基站和FA是集成的，那么这种安全威胁将不适用。此外，必须适当保护无线链路上的第2层控制消息，以防止恶意节点运行模拟攻击并导致生成不需要的L2触发器。需要完整性和重播保护，以避免恶意节点重播旧消息以导致资源消耗的模拟威胁和资源消耗威胁。这取决于无线链路的L2安全类型。例如，在蜂窝技术中，控制消息是安全的，尽管安全类型根据蜂窝标准而变化，但在WLAN-IEEE 802.11网络中通常不是这种情况。
In PRE-REGISTRATION, the security of L2 triggers has different implications. The PRE-REGISTRATION technique depends on Mobile IPv4 security between MN and FA, so the same security considerations in [1] apply. Should malicious nodes be able to generate or modify L2
在预注册中，L2触发器的安全性具有不同的含义。预注册技术取决于MN和FA之间的移动IPv4安全，因此[1]中的安全注意事项同样适用。恶意节点是否能够生成或修改L2
trigger information (i.e., L2-ST or L2-TT), this would cause advertisements to be sent to the MN. They would consume wireless resources and processing in the MN, but would not allow an impersonation attack. In order to prevent such denial-of-service attacks, there should be a limit on the number of advertisements that an FA (oFA) will relay to the MN as a result of the reception of L2 triggers. This number will depend on the L2 technology, and the default limit is 10 per second.
触发信息（即，L2-ST或L2-TT），这将导致向MN发送广告。它们将消耗MN中的无线资源和处理，但不允许模拟攻击。为了防止此类拒绝服务攻击，应限制FA（oFA）由于接收L2触发器而中继到MN的播发数量。此数字将取决于L2技术，默认限制为每秒10次。
The authors want to thank Lennart Bang, Bryan Hartwell, Joel Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments and suggestions on the whole document. The authors also thank the Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their input.
作者要感谢Lennart Bang、Bryan Hartwell、Joel Hortelius、Gianluca Verin和Jonathan Wood对整个文档的宝贵意见和建议。作者还感谢移动IPv4工作组主席Phil Roberts和Basavaraj Patil的投入。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins，C.，编辑，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[3] 黑山，G.，编辑，“移动IP反向隧道，修订版”，RFC 3024，2001年1月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[4] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[5] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[5] Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
[6] IEEE，“64位全局标识符（EUI-64）注册机构指南”，http://standards.ieee.org/regauth/oui/tutorials/EUI64.html，1997年3月。
[7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[7] Perkins，C.，Calhoun，P.，和J.Bharatia，“移动IPv4挑战/响应扩展（修订版）”，RFC 47212007年1月。
[8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[8] Deering，S.，编辑，“ICMP路由器发现消息”，RFC 1256，1991年9月。
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9] Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[10] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007.
[11] Fogelstroem，E.，Jonsson，A.，和C.Perkins，“移动IPv4区域注册”，RFC 4857，2007年6月。
[12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[12] Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[13] TIA/EIA/IS-2000.
[13] TIA/EIA/IS-2000。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[14] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[15] 3GPP TS 23.003 (www.3gpp.org).
[15] 3GPP TS 23.003（www.3GPP.org）。
[16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[16] Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
Appendix A - Gateway Foreign Agents
附录A-网关外国代理
The Mobile IPv4 Regional Registration specification [11] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two FAs providing service to an MN have in common. Figure A.1 provides an example of an MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets sent to the MN will be delivered to the GFA, which in turn will forward the packets to the FA servicing the MN.
移动IPv4区域注册规范[11]引入了网关外部代理（GFA），作为向MN提供服务的两个FA的共同移动代理。图A.1提供了MN通过GFA进行初始注册的示例。如果这是第一条注册消息，则必须将该消息转发给HA。发送到MN的所有数据包都将被发送到GFA，GFA反过来将数据包转发给为MN提供服务的FA。
RegReq +-----+ RegReq
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ RegReq +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
RegReq +-----+ RegReq
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ RegReq +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
+-----+
| nFA |
+-----+
Figure A.1 - Initial Registrations through GFA
图A.1-通过GFA的初始注册
If the MN moves to an nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process.
如果MN移动到由oFA共用的GFA服务的nFA，MN可发出区域注册请求（见图a.2）。区域注册信息不需要转发给医管局，因为MN的流量仍然可以发送到相同的GFA。这种优化的方法有效地减少了注册过程中的延迟。
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
RegRegReq +-----+ RegRegReq
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
RegRegReq +-----+ RegRegReq
Figure A.2 - Regional Registration through GFA
图A.2-通过GFA的区域注册
Note that the GFA may also be the MN's first-hop router.
注意，GFA也可能是MN的第一跳路由器。
Appendix B - Low-Latency Handoffs for Multiple-Interface MNs
附录B-多接口MN的低延迟切换
For MNs that have two wireless network interfaces, either on the same wireless network or on wireless networks having different wireless L2 technologies, the techniques discussed in this document may be unnecessary if the Mobile IPv4 stack on the MN allows switching an IPv4 address binding between interfaces. This Appendix discusses how multiple wireless interfaces can aid low-latency handoff.
对于在同一无线网络上或在具有不同无线L2技术的无线网络上具有两个无线网络接口的MN，如果MN上的移动IPv4堆栈允许在接口之间切换IPv4地址绑定，则可能不需要本文档中讨论的技术。本附录讨论了多个无线接口如何帮助低延迟切换。
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
Figure B.1 - Network Model for Mobile IPv4 with Multi-Access
图B.1-多址移动IPv4的网络模型
Figure B.1 illustrates the normal and hierarchical MIPv4 models. As shown in the figure, assume that the MN is connected to Radio Network 1 (RN1) and is registered with oFA through which it is receiving traffic. Suppose MN enters the coverage area of RN2 and nFA and that it prefers connectivity to this network for reasons beyond the scope of this document (e.g., user preferences, cost, QoS available, etc.). The MN activates the interface to RN2 but continues communicating through RN1. The MN may solicit advertisements from nFA through the interface connected to RN1 to speed up the handoff process, provided there is no TTL restriction, or it can solicit advertisements through the interface connected to RN2 if it has been configured for IPv4 traffic.
图B.1说明了正常和分层MIPv4模型。如图所示，假设MN连接到无线网络1（RN1），并向oFA注册，通过该oFA接收通信量。假设MN进入RN2和nFA的覆盖区域，并且出于超出本文档范围的原因（例如，用户偏好、成本、可用QoS等），它更愿意连接到此网络。MN激活与RN2的接口，但继续通过RN1进行通信。MN可以通过连接到RN1的接口从nFA请求广告，以加速切换过程，前提是没有TTL限制，或者如果已经为IPv4流量配置了连接到RN2的接口，MN可以通过该接口请求广告。
Once the MN is registered with nFA and is successfully receiving and transmitting through the new network, it tears down the interface to RN1. If the MN has enough time to complete this procedure without incurring degraded service or disconnection, the MN would experience a seamless multi-access handoff, but it may not be possible in all
一旦MN向nFA注册并通过新网络成功接收和发送，它就会断开与RN1的接口。如果MN有足够的时间来完成此过程而不导致服务降级或断开连接，则MN将经历无缝多址切换，但这可能根本不可能
cases, due to network coverage or for other reasons. Should multiple interface handoff be possible, then the low-latency methods described in this document are not necessary.
由于网络覆盖或其他原因导致的情况。如果可以进行多接口切换，则不需要本文档中描述的低延迟方法。
In order to support the possible failure of the connectivity with the new network (RN2/nFA) in the short period following handoff, the MN may use the S bit in its Mobile IPv4 Registration Request to maintain simultaneous bindings with both its existing (HA or GFA) binding with oFA and a new binding with nFA.
为了支持在切换后的短时间内与新网络（RN2/nFA）的连接可能失败，MN可以在其移动IPv4注册请求中使用S比特来维持与其现有（HA或GFA）与oFA的绑定以及与nFA的新绑定的同时绑定。
Appendix C - PRE-REGISTRATION Message Summary
附录C-预注册信息摘要
This appendix contains a quick reference for IPv4 and layer 2 addresses to be used in PRE-REGISTRATION messages.
本附录包含在预注册消息中使用的IPv4和第2层地址的快速参考。
Proxy Router Advertisement (PrRtAdv) This is a standard Router/Agent Advertisement [1] with the following characteristics:
代理路由器广告（PrRtAdv）这是标准路由器/代理广告[1]，具有以下特征：
Source IPv4 Address: nFA IPv4 Address Source Layer 2 Address: oFA L2 Address Destination IPv4 Address: MN IPv4 Address (from PrRtSol) Destination Layer 2 Address: MN L2 Address (from PrRtSol) LLA Extension (defined in this spec): containing nFA Layer 2 Address.
源IPv4地址：nFA IPv4地址源层2地址：oFA L2地址目标IPv4地址：MN IPv4地址（来自PrRtSol）目标层2地址：MN L2地址（来自PrRtSol）LLA扩展（在此规范中定义）：包含nFA层2地址。
Proxy Router Solicitation (PrRtSol) This is a standard Router/Agent Solicitation [1] with the following characteristics:
代理路由器请求（PrRtSol）这是一种标准的路由器/代理请求[1]，具有以下特征：
Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv) Destination Layer 2 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv LLA) LLA Extension (defined in this spec): depends on the layer 2 technology (e.g., typically for WLAN, this would be the BSSID of the new WLAN Access Point)
源IPv4地址：MN地址源层2地址：MN地址目标IPv4地址：oFA地址（来自上一个路由器公告或PrRtAdv的源地址）目标层2地址：oFA地址（来自上一个路由器公告或PrRtAdv LLA的源地址）LLA扩展（在本规范中定义）：取决于第2层技术（例如，通常对于WLAN，这将是新WLAN接入点的BSSID）
Registration Request (as seen on MN-oFA link) This is a Mobile IPv4 Registration Request message [1] with the following characteristics:
注册请求（如MN oFA链路上所示）这是一条移动IPv4注册请求消息[1]，具有以下特征：
Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: nFA Address (from source addr of PrRtAdv)
源IPv4地址：MN地址源层2地址：MN地址目标IPv4地址：nFA地址（来自PrRtAdv的源地址）
Destination Layer 2 Address: Default Router (i.e., oFA Address) LLA Extension (defined in this spec): containing the MN's L2 address that must be used by nFA. This will typically be an Ethernet MAC address but other types can be used as specified in Section 9 of this document.
目的层2地址：默认路由器（即oFA地址）LLA扩展（在本规范中定义）：包含nFA必须使用的MN的L2地址。这通常是一个以太网MAC地址，但也可以按照本文件第9节的规定使用其他类型。
Although this is not mandated, an MN implementation may set the S bit (see Section 6) in Registration Request messages to improve the handoff and avoid problems due to failed layer 2 handoffs and layer 2 ping-pong effects between two base stations.
尽管这不是强制性的，但是MN实现可以在注册请求消息中设置S比特（参见第6节），以改进切换并避免由于两个基站之间的失败的第2层切换和第2层乒乓效应而引起的问题。
Registration Reply (as seen on oFA-MN link) This is a Mobile IPv4 Registration Reply message [1] with the following characteristics:
注册回复（如MN链路上所示）这是一条移动IPv4注册回复消息[1]，具有以下特征：
Source IPv4 Address: nFA Address Source Layer 2 Address: oFA Address Destination IPv4 Address: MN Address (from source of Registration Request) Destination Layer 2 Address: MN Address (from source of Registration Request)
源IPv4地址：nFA地址源第2层地址：oFA地址目标IPv4地址：MN地址（来自注册请求源）目标第2层地址：MN地址（来自注册请求源）
Contributing Authors
撰稿人
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com
Pat Calhoun Cisco Systems电子邮件：pcalhoun@cisco.com
Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com
汤姆·希勒·朗讯科技电子邮件：汤姆。hiller@lucent.com
James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com
James Kempf NTT DoCoMo美国实验室电子邮件：kempf@docomolabs-美国网
Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com
Peter J.McCann摩托罗拉实验室电子邮件：pete。mccann@motorola.com
Ajoy Singh Motorola EMail: asingh1@email.mot.com
Ajoy Singh摩托罗拉电子邮件：asingh1@email.mot.com
Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com
Hesham Soliman Elevate Technologies电子邮件：Hesham@elevatemobile.com
Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.com
Sebastian Thalanany美国手机电子邮件：Sebastian。thalanany@uscellular.com
Editor's Address
编辑地址
Karim El Malki Athonet EMail: karim@athonet.com
Karim El-Malki Athonet电子邮件：karim@athonet.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。