Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6463 Nokia Siemens Networks
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
H. Yokota
KDDI Lab
X. Cui
Huawei Technologies
February 2012
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6463 Nokia Siemens Networks
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
H. Yokota
KDDI Lab
X. Cui
Huawei Technologies
February 2012
Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6
代理移动IPv6的运行时本地移动锚（LMA）分配支持
Abstract
摘要
This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load-balancing purposes.
本文档描述了代理移动IPv6的运行时本地移动锚分配功能和相应的移动选项。在移动接入网关和本地移动锚之间的代理绑定更新和代理绑定确认消息交换期间发生运行时本地移动锚分配。本规范中定义的运行时本地移动锚分配功能可用于负载平衡等目的。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6463.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6463.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 5
4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 5
4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 6
4.3. Load Information Mobility Option . . . . . . . . . . . . . 7
4.4. Alternate IPv4 Care-of Address Mobility Option . . . . . . 9
5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 9
5.1. General Operation . . . . . . . . . . . . . . . . . . . . 9
5.2. Mobile Access Gateway Operation . . . . . . . . . . . . . 10
5.3. Local Mobility Anchor Operation . . . . . . . . . . . . . 12
5.3.1. Co-Located rfLMA and r2LMA Functions . . . . . . . . . 13
5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 14
6. Handoff and Multi-Homing Considerations . . . . . . . . . . . 18
7. Protocol Configuration Variables . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 5
4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 5
4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 6
4.3. Load Information Mobility Option . . . . . . . . . . . . . 7
4.4. Alternate IPv4 Care-of Address Mobility Option . . . . . . 9
5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 9
5.1. General Operation . . . . . . . . . . . . . . . . . . . . 9
5.2. Mobile Access Gateway Operation . . . . . . . . . . . . . 10
5.3. Local Mobility Anchor Operation . . . . . . . . . . . . . 12
5.3.1. Co-Located rfLMA and r2LMA Functions . . . . . . . . . 13
5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 14
6. Handoff and Multi-Homing Considerations . . . . . . . . . . . 18
7. Protocol Configuration Variables . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
This specification describes a runtime assignment of a local mobility anchor (LMA) for the Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol. The runtime LMA assignment takes place during a Proxy Binding Update (PBU) and a Proxy Binding Acknowledgement (PBA) message exchange between a mobile access gateway (MAG) and a LMA. The runtime LMA assignment functionality defined in this specification can be used, for example, for load-balancing purposes. MAGs and LMAs can also implement other load-balancing mechanisms that are completely transparent at the PMIPv6 protocol level and do not depend on the functionality defined in this specification.
本规范描述了代理移动IPv6（PMIPv6）[RFC5213]协议的本地移动锚（LMA）的运行时分配。运行时LMA分配发生在移动接入网关（MAG）和LMA之间的代理绑定更新（PBU）和代理绑定确认（PBA）消息交换期间。本规范中定义的运行时LMA分配功能可用于负载平衡等目的。MAG和LMA还可以实现其他负载平衡机制，这些机制在PMIPv6协议级别上完全透明，不依赖于本规范中定义的功能。
The runtime LMA assignment functionality does not depend on the Domain Name System (DNS) or the Authentication, Authorization, and Accounting (AAA) infrastructure for the assignment of the LMA to which the mobile node (MN) is anchored. All MAGs and LMAs (either rfLMAs or r2LMAs; see Section 2.2) have to belong to the same PMIPv6 domain.
运行时LMA分配功能不依赖于域名系统（DNS）或认证、授权和计费（AAA）基础设施来分配移动节点（MN）所锚定的LMA。所有MAG和LMA（RFLMA或R2LMA；见第2.2节）必须属于同一PMIPv6域。
There are a number of reasons why the runtime LMA assignment is a useful addition to the PMIPv6 protocol. A few are identified below:
运行时LMA分配是PMIPv6协议的一个有用的补充，原因有很多。以下列出了一些：
o LMAs with multiple IP addresses: a cluster of LMAs or a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses. A MAG can initially select any of the LMAs as the serving LMA using, for example, DNS- and AAA-based solutions. However, MAG's initial selection may be suboptimal from the LMA point of view and immediate runtime assignment to a "proper LMA" would be needed. The LMA could use a [RFC5142]-based approach, but that would imply unnecessary setting up of a mobility session in a "wrong LMA" with associated back-end support system interactions, additional signaling between the MAG and the LMA, and re-establishing a mobility session to the new LMA again with associated signaling.
o 具有多个IP地址的LMA：LMA集群或刀片架构LMA在路由系统看来可能是具有单独单播IP地址的多个LMA。MAG可以使用例如基于DNS和AAA的解决方案最初选择任何LMA作为服务LMA。然而，从LMA的角度来看，MAG的初始选择可能是次优的，需要立即将运行时分配给“适当的LMA”。LMA可以使用基于[RFC5142]的方法，但这将意味着在具有相关后端支持系统交互的“错误LMA”中不必要地设置移动性会话，MAG和LMA之间的附加信令，以及再次利用相关信令重新建立到新LMA的移动性会话。
o Bypassing a load-balancer: a cluster of LMAs or a blade architecture LMA may have a load-balancer in front of them or integrated in one of the LMAs. The load-balancer would represent multiple LMAs during the LMA discovery phase and only its IP address would be exposed to the MAG thus hiding possible individual LMA or LMA blade IP addresses from the MAG. However, if all traffic must always go through the load-balancer, it quickly becomes a bottleneck. Therefore, a PMIPv6 protocol-level support for bypassing the load-balancer after the initial PBU/PBA exchange would greatly help scalability. Also, bypassing the load-balancer as soon as possible allows implementing load-balancers that do not maintain any MN-specific state information.
o 绕过负载平衡器：LMA集群或刀片架构LMA前面可能有负载平衡器，或者集成在其中一个LMA中。在LMA发现阶段，负载平衡器将代表多个LMA，并且只有其IP地址将向MAG公开，从而对MAG隐藏可能的单个LMA或LMA刀片IP地址。但是，如果所有流量必须始终通过负载平衡器，它将很快成为瓶颈。因此，在初始PBU/PBA交换之后，对绕过负载平衡器的PMIPv6协议级支持将极大地提高可伸缩性。此外，尽快绕过负载平衡器允许实现不维护任何特定于MN的状态信息的负载平衡器。
o Independence from DNS: DNS-based load-balancing is a common practice. However, keeping MAGs up to date with LMA load status using DNS is hard, e.g., due to caching and unpredictable zone update delays [RFC6097]. Generally, LMAs constantly updating the [RFC2136] zone's master DNS server might not feasible in a large PMIPv6 domain due to increased load on the master DNS server and additional background signaling. Furthermore, MAGs may perform (LMA) destination address selection decisions that are not in line with what the DNS administrator actually wanted [RFC3484].
o 独立于DNS：基于DNS的负载平衡是一种常见做法。然而，使用DNS使MAG与LMA负载状态保持最新是很困难的，例如，由于缓存和不可预测的区域更新延迟[RFC6097]。通常，由于主DNS服务器上的负载增加和额外的后台信令，LMA不断更新[RFC2136]区域的主DNS服务器在大型PMIPv6域中可能不可行。此外，MAG可能会执行与DNS管理员实际需要的不一致的（LMA）目标地址选择决策[RFC3484]。
o Independence from AAA: AAA-based solutions have basically the same arguments as DNS-based solutions above. It is also typical that AAA-based solutions offload the initial LMA selection to the DNS infrastructure [RFC5779]. The AAA infrastructure does not return an IP address or a Fully Qualified domain Name (FQDN) to a single LMA; rather, it returns a FQDN representing a group of LMAs.
o 独立于AAA：基于AAA的解决方案与上面基于DNS的解决方案的论点基本相同。基于AAA的解决方案通常会将初始LMA选择转移到DNS基础设施[RFC5779]。AAA基础设施不会向单个LMA返回IP地址或完全限定域名（FQDN）；相反，它返回表示一组LMA的FQDN。
o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. For example, a blade architecture LMA may have a unique unicast IP address for each blade and a single anycast address for all blades. A MAG could then initially send a PBU to an anycast LMA address and receive a PBA from an anycast LMA address. Once the MAG receives the unicast address of the runtime-assigned LMA blade through the initial PBU/PBA exchange, the subsequent communication continues using the unicast address.
o 支持IPv6选播寻址[RFC4291]：当前的PMIPv6规范没有规定PMIPv6协议应如何处理分配给移动代理的选播地址。例如，刀片体系结构LMA可以具有用于每个刀片的唯一单播IP地址和用于所有刀片的单个选播地址。然后，MAG可以首先向选播LMA地址发送PBU，并从选播LMA地址接收PBA。一旦MAG通过初始PBU/PBA交换接收到运行时分配的LMA刀片的单播地址，随后的通信将继续使用单播地址。
As a summary, the DNS/AAA-based approaches cannot be used to select an "appropriate" LMA at runtime. Therefore, this specification defines a solution that is applicable for LMA implementations where the IP address known to the MAG is not the best LMA of choice at runtime.
总之，基于DNS/AAA的方法不能用于在运行时选择“适当的”LMA。因此，本规范定义了适用于LMA实现的解决方案，其中MAG已知的IP地址在运行时不是最佳LMA选择。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition to the terminology defined in [RFC5213], the following terminology is also used:
除[RFC5213]中定义的术语外，还使用以下术语：
rfLMA
rfLMA
An LMA that receives a PBU from a MAG and decides to assign an IP mobility session with a new target LMA (r2LMA).
一种LMA，从MAG接收PBU，并决定分配一个具有新目标LMA（r2LMA）的IP移动性会话。
r2LMA
r2LMA
The LMA assigned to a MAG as a result of the runtime LMA assignment.
作为运行时LMA分配的结果而分配给MAG的LMA。
Runtime Assignment Domain
运行时分配域
A group of LMAs that consists of at least one rfLMA and one or more r2LMAs (all are part of the same PMIPv6 domain). A rfLMA is allowed to assign MAGs only with r2LMAs that belong to the same runtime assignment domain. The rfLMA and one or more r2LMAs may consist of multiple blades in a single network element, multiple physical network elements, or multiple LMAs distributed geographically.
由至少一个rfLMA和一个或多个R2LMA组成的一组LMA（均为同一PMIPv6域的一部分）。rfLMA仅允许使用属于同一运行时分配域的R2LMA分配MAG。rfLMA和一个或多个R2LMA可以由单个网元中的多个刀片、多个物理网元或地理上分布的多个LMA组成。
The runtime LMA assignment functionality has few assumptions within the PMIPv6 domain.
运行时LMA分配功能在PMIPv6域中几乎没有假设。
Each LMA in a runtime assignment domain MUST be reachable at a unicast IP address. The rfLMA and the r2LMA MUST have a prior agreement, adequate means to secure their inter-LMA communication, and an established trust relationship to perform the runtime LMA assignment.
运行时分配域中的每个LMA必须在单播IP地址处可访问。rfLMA和r2LMA必须具有事先协议、确保其LMA间通信安全的适当手段以及执行运行时LMA分配的已建立信任关系。
Each LMA and MAG participating in the runtime LMA assignment is assumed to have required Security Associations (SAs) pre-established. Dynamic negotiation of the SAs using, e.g., IKEv2 [RFC5996], SHOULD be supported but is out of scope of this specification.
假设参与运行时LMA分配的每个LMA和MAG都预先建立了所需的安全关联（SA）。应支持使用IKEv2[RFC5996]等对SAs进行动态协商，但不在本规范的范围内。
In the following sections, all presented values, bit fields, and addresses are in network byte order.
在以下各节中，所有显示的值、位字段和地址均按网络字节顺序排列。
The Redirect-Capability mobility option has the alignment requirement of 4n. There can be zero or one Redirect-Capability mobility option in the PBU. The format of the Redirect-Capability mobility option is shown below:
重定向能力移动选项的对准要求为4n。PBU中可以有零个或一个重定向能力移动选项。重定向能力移动选项的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect-Capability Mobility Option
重定向能力移动选项
o Option Type: 8-bit identifier set to 46.
o 选项类型：8位标识符设置为46。
o Option Length: 8-bit unsigned integer, representing the length of the Redirect-Capability mobility option in octets, excluding the Option Type and Length fields. The Option Length MUST be set to 2.
o 选项长度：8位无符号整数，表示重定向功能移动选项的长度（以八位字节为单位），不包括选项类型和长度字段。选项长度必须设置为2。
o Reserved: This field is reserved for future use. This field MUST be set to zero by the sender and ignored by the receiver.
o 保留：此字段保留供将来使用。发送方必须将此字段设置为零，接收方必须忽略此字段。
The Redirect-Capability option is used by the MAG to inform the LMA that it implements and has enabled the runtime LMA assignment functionality.
MAG使用重定向功能选项通知LMA其实现并启用了运行时LMA分配功能。
The Redirect mobility option in the PBA MUST contain an unicast address of the r2LMA and the address family MUST be the same as the currently used transport between the MAG and the rfLMA. There can be zero or one Redirect mobility option in the PBA. The Redirect mobility option has the alignment requirement of 4n. The format of the Redirect mobility option is shown below:
PBA中的重定向移动选项必须包含r2LMA的单播地址，并且地址族必须与MAG和rfLMA之间当前使用的传输相同。PBA中可以有零个或一个重定向移动性选项。重定向移动选项的对齐要求为4n。重定向移动选项的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |K|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional IPv6 r2LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 r2LMA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |K|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional IPv6 r2LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 r2LMA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Mobility Option
重定向移动选项
o Option Type: 8-bit identifier set to 47.
o 选项类型：8位标识符设置为47。
o Option Length: 8-bit unsigned integer, representing the length of the Redirect mobility option in octets, excluding the Option Type and Length fields. If the 'K' flag is set and 'N' is unset, then the length MUST be 18. If the 'K' flag is unset and 'N' is set, then the length MUST be 6. Both the 'K' and 'N' flags cannot be set or unset simultaneously.
o 选项长度：8位无符号整数，以八位字节表示重定向移动选项的长度，不包括选项类型和长度字段。如果设置了“K”标志且未设置“N”，则长度必须为18。如果“K”标志未设置且设置了“N”，则长度必须为6。不能同时设置或取消设置“K”和“N”标志。
o 'K' flag: This bit is set (1) if the 'Optional IPv6 r2LMA Address' is included in the mobility option. Otherwise, the bit is unset (0).
o “K”标志：如果“可选IPv6 r2LMA地址”包含在移动选项中，则设置该位（1）。否则，该位未设置（0）。
o 'N' flag: This bit is set (1) if the 'Optional IPv4 r2LMA Address' is included in the mobility option. Otherwise, the bit is unset (0).
o “N”标志：如果“可选IPv4 r2LMA地址”包含在移动选项中，则设置（1）此位。否则，该位未设置（0）。
o Reserved: This field is reserved for future use. MUST be set to zero by the sender and ignored by the receiver.
o 保留：此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略。
o Optional IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. This value is present when the corresponding PBU was sourced from an IPv6 address.
o 可选IPv6 r2LMA地址：r2LMA的单播IPv6地址。当相应的PBU源于IPv6地址时，此值存在。
o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This value is present when the corresponding PBU was sourced from an IPv4 address (for IPv4 transport, see [RFC5844]).
o 可选IPv4 r2LMA地址：r2LMA的IPv4地址。当对应的PBU来自IPv4地址时，此值存在（对于IPv4传输，请参阅[RFC5844]）。
The Redirect option is used by the LMA to inform the MAG that the runtime LMA assignment took place and the MAG has to update its Binding Update List Entry (BULE) for the mobility session.
LMA使用重定向选项通知MAG运行时LMA分配已发生，并且MAG必须为移动会话更新其绑定更新列表条目（BLE）。
The Load Information mobility option can be included in any PBA and is used to report priority and key load information of a LMA to a MAG (or to a 'proxy-MAG'). The Load Information mobility option has the alignment requirement of 4n. The format of the mobility option is shown below:
负载信息移动选项可以包括在任何PBA中，并用于向MAG（或“代理MAG”）报告LMA的优先级和关键负载信息。负载信息移动选项的对齐要求为4n。移动选项的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sessions in Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Used Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sessions in Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Used Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Load Information Mobility Option
负载信息移动选项
o Option Type: 8-bit identifier set to 48.
o 选项类型：8位标识符设置为48。
o Option Length: 8-bit unsigned integer, representing the length of the Load Information mobility option in octets, excluding the Option Type and Length fields. The length is set to 18.
o 选项长度：8位无符号整数，以八位字节表示负载信息移动选项的长度，不包括选项类型和长度字段。长度设置为18。
o Priority: 16-bit unsigned integer, representing the priority of an LMA. The lower value, the higher the priority. The priority only has meaning among a group of LMAs under the same administration, for example, determined by a common LMA FQDN, a domain name, or a realm.
o 优先级：16位无符号整数，表示LMA的优先级。值越小，优先级越高。优先级仅在同一管理下的一组LMA中具有意义，例如，由公共LMA FQDN、域名或领域确定。
o Sessions in Use: 32-bit unsigned integer, representing the number of parallel mobility sessions the LMA has in use.
o 正在使用的会话：32位无符号整数，表示LMA正在使用的并行移动会话数。
o Maximum Sessions: 32-bit unsigned integer, representing the maximum number of parallel mobility sessions the LMA is willing to accept.
o 最大会话数：32位无符号整数，表示LMA愿意接受的最大并行移动会话数。
o Used Capacity: 32-bit unsigned integer, representing the used bandwidth/throughput capacity of the LMA in kilobytes per second.
o 已用容量：32位无符号整数，表示LMA的已用带宽/吞吐量容量，单位为每秒千字节。
o Maximum Capacity: 32-bit unsigned integer, representing the maximum bandwidth/throughput capacity in kilobytes per second the LMA is willing to accept.
o 最大容量：32位无符号整数，表示LMA愿意接受的最大带宽/吞吐量容量，单位为每秒千字节。
The session and capacity information can easily be used to calculate different load factors of the LMA. A MAG (or a 'proxy-MAG') MAY use the priority and load information to internally maintain priority ordering of LMAs.
会话和容量信息可以很容易地用于计算LMA的不同负载系数。MAG（或“代理MAG”）可以使用优先级和负载信息在内部维护LMA的优先级顺序。
The Alternate IPv4 Care-of Address (A4CoA) mobility option has the alignment requirement of 4n+2. The format of the mobility option is shown below:
备用IPv4转交地址（A4CoA）移动选项的对齐要求为4n+2。移动选项的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternate IPv4 Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternate IPv4 Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alternate IPv4 Care-of Address Mobility Option
替代IPv4转交地址移动选项
o Option Type: 8-bit identifier set to 49.
o 选项类型：8位标识符设置为49。
o Option Length: 8-bit unsigned integer, representing the length of the Load Information mobility option in octets, excluding the Option Type and Length fields. The length is set to 4.
o 选项长度：8位无符号整数，以八位字节表示负载信息移动选项的长度，不包括选项类型和长度字段。长度设置为4。
o Alternate IPv4 Care-of Address: an IPv4 equivalent of the [RFC6275] Alternate Care-of Address option for IPv6. In the context of PMIPv6, its semantic is equivalent to the Alternate Care-of Address option for IPv6.
o 备用IPv4转交地址：IPv6的[RFC6275]备用转交地址选项的IPv4等价物。在PMIPv6的上下文中，其语义相当于IPv6的替代转交地址选项。
A MAG MAY include the Alternate IPv4 Care-of Address option in a PBU. An LMA that receives and implements the Alternate IPv4 Care-of Address option MUST echo the option as such back to the MAG in a reply PBA.
MAG可以在PBU中包括备用IPv4转交地址选项。接收并实现备用IPv4转交地址选项的LMA必须在应答PBA中将该选项回显给MAG。
During the runtime LMA assignment, the PBA is returned from the LMA Address to which the PBU was sent, i.e., from the rfLMA address. After the runtime LMA assignment, all PMIPv6 communication continues directly between the MAG and the r2LMA bypassing the rfLMA. The overall runtime LMA assignment flow sequence is shown in Figure 1.
在运行时LMA分配期间，PBA从PBU发送到的LMA地址返回，即从rfLMA地址返回。在运行时LMA分配之后，所有PMIPv6通信直接在MAG和r2LMA之间继续，绕过rfLMA。整个运行时LMA分配流序列如图1所示。
[MAG] [rfLMA] [r2LMA]
| | |
1) |--PBU-->| | LMA assignment takes place in rfLMA.
| | |
2) | | ~ ~ ~ >|\
| | | + BCE gets created in r2LMA.
3) | |<~ ~ ~ ~|/
| | |
4) |<--PBA--| | PBA contains r2LMA information.
| | |
|<=====data======>|
| | |
5) |-------PBU------>| Lifetime extension,
6) |<------PBA-------| de-registration, etc.
| | |
[MAG] [rfLMA] [r2LMA]
| | |
1) |--PBU-->| | LMA assignment takes place in rfLMA.
| | |
2) | | ~ ~ ~ >|\
| | | + BCE gets created in r2LMA.
3) | |<~ ~ ~ ~|/
| | |
4) |<--PBA--| | PBA contains r2LMA information.
| | |
|<=====data======>|
| | |
5) |-------PBU------>| Lifetime extension,
6) |<------PBA-------| de-registration, etc.
| | |
Figure 1: Runtime LMA Assignment from rfLMA to r2LMA and Setting Up a Mobility Session in the r2LMA within a Runtime Assignment Domain
图1：从rfLMA到r2LMA的运行时LMA分配，以及在运行时分配域内的r2LMA中设置移动会话
The assumption in the signaling flow step 1) shown in Figure 1 is that the mobility session gets created in the r2LMA, although the rfLMA is responsible for interfacing with the MAG. There are several possible solutions for the rfLMA and the r2LMA interaction depending on, e.g., the co-location properties of the rfLMA and the r2LMA. This specification describes two:
图1中所示的信令流步骤1）中的假设是在r2LMA中创建移动性会话，尽管rfLMA负责与MAG接口。rfLMA和r2LMA交互有几种可能的解决方案，这取决于例如rfLMA和r2LMA的共址属性。本规范描述了两个方面：
o Co-located rfLMA and r2LMA functions, where the 'rfLMA side of the LMA' is reachable via an anycast address or the loopback address of the LMA. See Section 5.3.1 for further details.
o 位于同一位置的rfLMA和r2LMA功能，其中“LMA的rfLMA侧”可通过LMA的选播地址或环回地址到达。详见第5.3.1节。
o Separate rfLMA and r2LMA functions, where the rfLMA acts as a non-transparent 'proxy-MAG' to a r2LMA. See Section 5.3.2 for further details.
o 单独的rfLMA和r2LMA功能，其中rfLMA充当r2LMA的不透明“代理MAG”。详见第5.3.2节。
There are other possible implementations of the rfLMA and the r2LMA. At the end, as long as the protocol between the MAG and the rfLMA follows this specification , the co-location or inter-communication properties of the rfLMA and the r2LMA do not matter.
rfLMA和r2LMA还有其他可能的实现。最后，只要MAG和rfLMA之间的协议遵循该规范，rfLMA和r2LMA的同址或相互通信特性就无关紧要。
In the base PMIPv6 protocol [RFC5213], a MAG sends a PBU to an LMA; this results in creation of a Binding Cache Entry (BCE) at the LMA and the LMA sending a PBA sent back to the MAG. The MAG in turn creates a corresponding Binding Update List Entry (BULE). This specification extends the base protocol with the runtime LMA assignment functionality.
在基本PMIPv6协议[RFC5213]中，MAG向LMA发送PBU；这导致在LMA处创建绑定缓存项（BCE），LMA将PBA发送回MAG。MAG反过来创建相应的绑定更新列表项（BLE）。本规范通过运行时LMA分配功能扩展了基本协议。
If the MAG supports the runtime LMA assignment and the functionality is also enabled (see the EnableLMARedirectFunction configuration variable in Section 7), then the MAG includes the Redirect-Capability mobility option in a PBU that establishes a new mobility session (i.e., Handoff Indicator Option in the PBU has the value of 1). The Redirect-Capability mobility option in the PBU is also an indication to an LMA that the MAG supports the runtime LMA assignment functionality and is prepared to be assigned with a different LMA. The runtime LMA assignment concerns always one mobility session at a time.
如果MAG支持运行时LMA分配并且功能也被启用（参见第7节中的EnableLMARedirectFunction配置变量），则MAG在PBU中包括重定向能力移动选项，该PBU建立新的移动会话（即，PBU中的切换指示符选项的值为1）。PBU中的重定向能力移动性选项也向LMA指示MAG支持运行时LMA分配功能并且准备被分配不同的LMA。运行时LMA分配始终涉及一次一个移动会话。
If the MAG receives a PBA that contains the Redirect mobility option without first including the Redirect-Capability mobility option in the corresponding PBU, then the MAG MUST ignore the option and process the PBA as described in RFC 5213.
如果MAG接收到包含重定向移动性选项的PBA而未首先在相应PBU中包括重定向能力移动性选项，则MAG必须忽略该选项并按照RFC 5213中所述处理PBA。
If the MAG receives a PBA that contains the Redirect mobility option and the MAG had included the Redirect-Capability mobility option in the corresponding PBU, then the MAG MUST perform the following steps in addition to the normal [RFC5213] PBA processing:
如果MAG接收到包含重定向移动性选项的PBA，并且MAG已在相应的PBU中包含重定向能力移动性选项，则除正常[RFC5213]PBA处理外，MAG必须执行以下步骤：
o The MAG updates its BULE to contain the r2LMA address included in the received Redirect mobility option.
o MAG更新其BLE以包含接收到的重定向移动性选项中包含的r2LMA地址。
o If there is no SA between the MAG and the r2LMA, the MAG SHOULD initiate a dynamic creation of the SA between the MAG and the r2LMA as described in Section 4 of RFC 5213. If the dynamic SA creation fails, the MAG SHOULD log the event. The MAG MAY retry the dynamic creation of the SA, and if those also fail, the newly created BULE (and also the BUL in the r2LMA) will eventually timeout. If the failure is persistent, it can be regarded as a system-level configuration error.
o 如果MAG和r2LMA之间没有SA，MAG应按照RFC 5213第4节中的说明，在MAG和r2LMA之间启动SA的动态创建。如果动态SA创建失败，MAG应记录事件。MAG可能会重试SA的动态创建，如果这些也失败，新创建的BUL（以及r2LMA中的BUL）最终将超时。如果故障持续存在，则可将其视为系统级配置错误。
The MAG is not required to send a fresh PBU to the r2LMA after a successful runtime assignment. The mobility session has already been established in the r2LMA. The MAG MUST send all user traffic to the r2LMA address. The MAG MUST send subsequent binding refresh PBUs (e.g., lifetime extension, handoff, etc.) to the r2LMA address. If there is no existing tunnel between the MAG and the r2LMA unicast address, then the MAG creates one as described in Section 6.9.1.2 of [RFC5213].
运行时分配成功后，MAG无需向r2LMA发送新的PBU。r2LMA中已经建立了移动会话。MAG必须将所有用户通信发送到r2LMA地址。MAG必须向r2LMA地址发送后续绑定刷新PBU（例如，生存期延长、切换等）。如果MAG和r2LMA单播地址之间没有现有隧道，则MAG将按照[RFC5213]第6.9.1.2节中的说明创建一个隧道。
The text in the following sections refers to an 'LMA' when it means the combination of the rfLMA and the r2LMA, i.e., the entity where runtime LMA assignment is possible. When the text points to a specific LMA role during the runtime assignment, it uses either the 'rfLMA' or the 'r2LMA'.
以下章节中的文本指的是“LMA”，指的是rfLMA和r2LMA的组合，即可以进行运行时LMA分配的实体。当文本在运行时分配期间指向特定的LMA角色时，它使用“rfLMA”或“r2LMA”。
If the runtime assignment functionality is enabled (see the EnableLMARedirectFunction configuration variable in Section 7) in the rfLMA but the LMA assignment is not going to take place for some reason, and the rfLMA is not willing to serve (or not capable of serving) as a normal [RFC5213] LMA for the MAG, then the rfLMA MUST reject the PBU and send back a PBA with Status Value set to 130 (Insufficient resources) error code. If the rfLMA is able to make the assignment to an r2LMA, it returns a PBA with the Redirect mobility option as defined below. Otherwise, the rfLMA MUST act as a normal [RFC5213]- or [RFC5844]-defined LMA for the MAG.
如果在rfLMA中启用了运行时分配功能（请参阅第7节中的EnableLMARedirectFunction配置变量），但由于某种原因LMA分配不会发生，并且rfLMA不愿意（或不能）作为MAG的正常[RFC5213]LMA使用，然后rfLMA必须拒绝PBU并发回状态值设置为130（资源不足）的PBA错误代码。如果rfLMA能够向r2LMA进行分配，它将返回一个带有重定向移动性选项的PBA，如下所述。否则，rfLMA必须充当MAG的正常[RFC5213]或[RFC5844]定义的LMA。
The rfLMA MUST only assign the MAG to a new r2LMA with which it knows the MAG has an SA or with which it knows the MAG can establish an SA dynamically. The rfLMA MUST NOT assign the MAG with a r2LMA that the rfLMA and the r2LMA do not have a prior agreement and an established trust relationship for the runtime LMA assignment. These SA-related knowledge issues and trust relationships are deployment specific in a PMIPv6 domain and in a runtime assignment domain, and out of scope of this specification. Possible context transfer and other coordination management between the rfLMA and the r2LMA are again deployment specific for LMAs in a runtime assignment domain. The rfLMA MUST NOT change the used transport IP address family during the runtime LMA assignment.
rfLMA必须仅将MAG分配给其知道MAG具有SA或知道MAG可以动态建立SA的新r2LMA。rfLMA不得向MAG分配r2LMA，因为rfLMA和r2LMA没有事先协议，也没有建立运行时LMA分配的信任关系。这些与SA相关的知识问题和信任关系在PMIPv6域和运行时分配域中是特定于部署的，超出了本规范的范围。rfLMA和r2LMA之间可能的上下文传输和其他协调管理也是特定于运行时分配域中LMA的部署。在运行时LMA分配期间，rfLMA不得更改使用的传输IP地址系列。
As a result of a successful runtime LMA assignment, the PBA MUST contain the Redirect mobility option with a valid r2LMA unicast address and the PBA Status Value indicating success.
作为运行时LMA分配成功的结果，PBA必须包含重定向移动选项，该选项具有有效的r2LMA单播地址和指示成功的PBA状态值。
Next, we describe two deployment and implementation models for the runtime LMA assignment. In Section 5.3.1, we describe a model where the rfLMA and r2LMA are co-located. In Section 5.3.2 we describe a model where the rfLMA acts as a non-transparent 'proxy-MAG', and where the rfLMA and the r2LMA are separate. There can be even more implementation options depending on the rfLMA and the r2LMA co-location properties, and how the inter-LMA communication is arranged.
接下来，我们将描述运行时LMA分配的两个部署和实现模型。在第5.3.1节中，我们描述了rfLMA和r2LMA共存的模型。在第5.3.2节中，我们描述了一个模型，其中rfLMA充当不透明的“代理MAG”，并且rfLMA和r2LMA是分开的。根据rfLMA和r2LMA共定位属性以及LMA间通信的安排方式，可以有更多的实现选项。
In this solution approach, the rfLMA and the r2LMA are part of the same 'co-located LMA', and may even be using the same physical network interface. The rfLMA is reachable via an anycast or a loopback address of the LMA. Each r2LMA is reachable via its unicast address. Figure 2 illustrates example signaling flows for the solution.
在该解决方案方法中，rfLMA和r2LMA是同一“同一位置LMA”的一部分，并且甚至可以使用相同的物理网络接口。rfLMA可通过LMA的选播或环回地址访问。每个r2LMA都可以通过其单播地址访问。图2说明了解决方案的示例信令流。
The MAG-LMA SA is between the MAG and the rfLMA (i.e., the anycast or the loopback address of the LMA). How this SA has been set up is out of scope of this specification, but a manual SA configuration is one possibility.
MAG-LMA SA位于MAG和rfLMA之间（即，LMA的选播或环回地址）。该SA的设置方式超出了本规范的范围，但手动SA配置是一种可能性。
The rfLMA becomes active when the runtime LMA assignment functionality is enabled (see the EnableLMARedirectFunction configuration variable in Section 7). When the rfLMA receives a PBU destined to it, and the PBU contains the Redirect-Capability mobility option, then the 'co-located LMA' MUST create a mobility session in a r2LMA role using the procedures described in [RFC5213]. If there is no existing tunnel between the MAG and the r2LMA unicast address, then the r2LMA creates one as described in Section 5.3 of [RFC5213]. The r2LMA used for accepting and anchoring the mobility session MUST also have the runtime LMA assignment functionality enabled (see the EnableLMARedirectAcceptFunction configuration variable in Section 7).
当运行时LMA分配功能启用时，rfLMA将激活（请参阅第7节中的EnableLMARedirectFunction配置变量）。当rfLMA接收到一个目的地为其的PBU，且PBU包含重定向能力移动选项时，“同一位置的LMA”必须使用[RFC5213]中所述的程序在r2LMA角色中创建移动会话。如果MAG和r2LMA单播地址之间没有现有隧道，则r2LMA将按照[RFC5213]第5.3节中的说明创建一个隧道。用于接受和锚定移动会话的r2LMA还必须启用运行时LMA分配功能（请参阅第7节中的EnableLMARedirectAcceptFunction配置变量）。
If the mobility session creation succeeded, then the 'co-located LMA' in the rfLMA role sends a PBA to the MAG. The PBA is sourced using the rfLMA (anycast or loopback) address. The PBA MUST contain the r2LMA unicast address (IPv6 or IPv4) in the Redirect mobility option.
如果移动会话创建成功，则rfLMA角色中的“共址LMA”向MAG发送PBA。PBA使用rfLMA（选播或环回）地址来源。PBA必须在重定向移动选项中包含r2LMA单播地址（IPv6或IPv4）。
If the PBU is received on the r2LMA unicast address, then the PBU is processed as described in RFC 5213 and the response PBA MUST NOT contain the Redirect mobility option.
如果在r2LMA单播地址上接收到PBU，则按照RFC 5213中所述处理PBU，并且响应PBA不得包含重定向移动性选项。
If the PBU is received on the rfLMA address and there is no Redirect-Capability mobility option in the PBU, then the 'co-located LMA' MAY choose to be a LMA for the MAG (assuming the rfLMA address is not an anycast address). Otherwise, the rfLMA MUST reject the PBU and send back a PBA in a rfLMA role with Status Value set to 130 (Insufficient resources) error code (as mentioned in Section 5.3).
如果在rfLMA地址上接收PBU，并且PBU中没有重定向能力移动性选项，则“同址LMA”可以选择为MAG的LMA（假设rfLMA地址不是选播地址）。否则，rfLMA必须拒绝PBU，并将状态值设置为130（资源不足）错误代码（如第5.3节所述）的rfLMA角色中的PBA发回。
[MAG] [rfLMA /r2LMA_1/r2LMA_2/r2LMA_3]
| | | | |
MAG discovers rfLMA | | | |
BULE for rfLMA | | | |
| | | | |
|-- PBU --------------------->| | | |
| src=MAG_Proxy-CoA, | | | |
| dst=rfLMA, | | | |
| Redirect-Capability, .. | r2LMA gets selected |
| BCE is created in r2LMA_2
| |Tunnel setup in r2LMA_2|
| | | | |
|<- PBA ----------------------| | | |
| src=rfLMA, | | | |
| dst=MAG_Proxy-CoA, | | | |
| Redirect=r2LMA_2_address, | | | |
| Load Info, .. | | | |
| | | | |
BULE updated to r2LMA_2 | | | |
Tunnel setup | | | |
| | | | |
|<=========== MAG-r2LMA_2 tunnel ============>| |
| | | | |
Lifetime extension, etc. | | | |
| | | | |
|-- PBU ------------------------------------->| |
| src=MAG_Proxy-CoA, | | | |
| dst=r2LMA_2, .. | | | |
| | | | |
|<- PBA --------------------------------------| |
| src=r2LMA_2, | | | |
| dst=MAG_Proxy-CoA, | | | |
| Load Info, .. | | | |
| | | | |
[MAG] [rfLMA /r2LMA_1/r2LMA_2/r2LMA_3]
| | | | |
MAG discovers rfLMA | | | |
BULE for rfLMA | | | |
| | | | |
|-- PBU --------------------->| | | |
| src=MAG_Proxy-CoA, | | | |
| dst=rfLMA, | | | |
| Redirect-Capability, .. | r2LMA gets selected |
| BCE is created in r2LMA_2
| |Tunnel setup in r2LMA_2|
| | | | |
|<- PBA ----------------------| | | |
| src=rfLMA, | | | |
| dst=MAG_Proxy-CoA, | | | |
| Redirect=r2LMA_2_address, | | | |
| Load Info, .. | | | |
| | | | |
BULE updated to r2LMA_2 | | | |
Tunnel setup | | | |
| | | | |
|<=========== MAG-r2LMA_2 tunnel ============>| |
| | | | |
Lifetime extension, etc. | | | |
| | | | |
|-- PBU ------------------------------------->| |
| src=MAG_Proxy-CoA, | | | |
| dst=r2LMA_2, .. | | | |
| | | | |
|<- PBA --------------------------------------| |
| src=r2LMA_2, | | | |
| dst=MAG_Proxy-CoA, | | | |
| Load Info, .. | | | |
| | | | |
Figure 2: Co-Located rfLMA and r2LMA Example
图2：位于同一位置的rfLMA和r2LMA示例
In this solution approach, the rfLMA and the r2LMA are two isolated functions, and may even be physically separate networking nodes. The r2LMA can be any [RFC5213]- or [RFC5844]-compliant LMA that doesn't have any knowledge of this specification when IPv6 transport is used. In case of IPv4 transport, the [RFC5844]-compliant LMA MUST also implement the Alternate IPv4 Care-of Address option (see Section 4.4). Figure 3 illustrates example signaling flows for the solution.
在该解决方案方法中，rfLMA和r2LMA是两个独立的功能，甚至可以是物理上独立的网络节点。r2LMA可以是在使用IPv6传输时不了解本规范的任何[RFC5213]或[RFC5844]兼容LMA。在IPv4传输的情况下，[RFC5844]兼容LMA还必须实现备用IPv4转交地址选项（参见第4.4节）。图3说明了解决方案的示例信令流。
The rfLMA is actually a non-transparent 'proxy-MAG' that shows up as an LMA implementing this specification towards the MAG, and as a base [RFC5213]-compliant MAG to the r2LMA. (See [RFC2616] for a generic definition of a non-transparent proxy; although it's for HTTP, the idea also applies here.) This type of operation is also referred to as 'chaining' in other contexts. The protocol between the 'proxy-MAG' and the r2LMA is the base [RFC5213] PMIPv6 protocol.
rfLMA实际上是一个不透明的“代理MAG”，它显示为一个针对MAG实现本规范的LMA，以及一个与r2LMA兼容的基本[RFC5213]MAG。（有关非透明代理的一般定义，请参见[RFC2616]；尽管它是针对HTTP的，但这一想法也适用于此处。）这种类型的操作在其他上下文中也称为“链接”。“代理MAG”和r2LMA之间的协议是基本[RFC5213]PMIPv6协议。
The MAG-LMA SA is between the MAG and the rfLMA, and [RFC5213] SA considerations apply fully. The MAG has no knowledge of the 'proxy-MAG'-r2LMA SA. [RFC5213] considerations regarding the SA between the 'proxy-MAG' and the r2LMA apply fully. It is also possible that 'proxy-MAG'-r2LMA security is arranged using other means than IPsec, for example, using layer-2 VPNs.
MAG-LMA SA介于MAG和rfLMA之间，且[RFC5213]SA注意事项完全适用。MAG不了解“代理MAG”-r2LMA SA。[RFC5213]关于“代理MAG”和r2LMA之间SA的注意事项完全适用。“代理MAG”-r2LMA安全性也可能使用IPsec以外的其他方式进行安排，例如，使用第2层VPN。
When the rfLMA receives a PBU, and the PBU contains the Redirect-Capability mobility option, then the rfLMA in a 'proxy-MAG' role:
当rfLMA接收到PBU，且PBU包含重定向能力移动选项时，则处于“代理MAG”角色的rfLMA：
o Processes the PBU using the procedures described in RFC 5213 except that no mobility session gets created. Instead, the rfLMA creates a proxy state based on the received PBU.
o 使用RFC 5213中描述的程序处理PBU，但不创建移动性会话。相反，rfLMA基于接收到的PBU创建代理状态。
o Assigns a r2LMA to the MAG.
o 将r2LMA分配给MAG。
o Creates a new PBU', which includes all non-security related mobility options from the original PBU and an Alternate Care-of Address (ACoA) option containing the Proxy Care-of Address of the original MAG. If the original PBU already included an ACoA option, then the content of the ACoA option in the PBU' MUST be the same as in the original PBU.
o 创建一个新的PBU'，其中包括来自原始PBU的所有非安全相关移动选项和包含原始MAG代理转交地址的备用转交地址（ACoA）选项。如果原始PBU已经包括ACoA选项，则PBU中ACoA选项的内容必须与原始PBU中的内容相同。
Note, in case of IPv4 transport [RFC5844], the Alternate IPv4 Care-of Address (A4CoA) option MUST be used and contain the IPv4 Proxy Care-of Address of the original MAG.
注意，对于IPv4传输[RFC5844]，必须使用备用IPv4转交地址（A4CoA）选项，并包含原始MAG的IPv4代理转交地址。
o Sends the new PBU' sourced from its 'proxy-MAG' IPv6 or IPv4 Proxy Care-of Address and destined to the r2LMA address using the procedures described in RFC 5213 (or RFC 5844 in case of IPv4 transport).
o 使用RFC 5213（或RFC 5844，在IPv4传输的情况下）中描述的过程，从其“代理MAG”IPv6或IPv4代理转交地址发送新PBU，并发送到r2LMA地址。
The r2LMA processes the received PBU' using the procedures described in RFC 5213 or RFC 5844. In case of IPv4 transport, the r2LMA uses the IPv4 Proxy Care-of Address from the Alternate IPv4 Care-of Address option for the tunnel setup and the creation of the BCE. The reply PBA' MUST be destined to the source address of the received PBU', i.e., the Care-of Address the 'proxy-MAG'.
r2LMA使用RFC 5213或RFC 5844中描述的程序处理接收到的PBU’。在IPv4传输的情况下，r2LMA使用备用IPv4转交地址选项中的IPv4代理转交地址进行隧道设置和BCE的创建。回复PBA“必须发送到接收到的PBU的源地址”，即“代理MAG”的转交地址。
Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the r2LMA and the mobility session creation succeeded in the r2LMA, the rfLMA sends a PBA to the original MAG. The PBA is sourced from the rfLMA address and destined to the MAG (IPv6 or IPv4) Proxy Care-of Address. The PBA MUST contain the r2LMA (IPv6 or IPv4) unicast address in the Redirect mobility option. Other non-security-related mobility options (including the Load Information option) are copied from the PBA' to the PBA as such.
一旦“代理MAG”角色的rfLMA收到来自r2LMA的“回复PBA”，并且r2LMA中的移动会话创建成功，rfLMA将向原始MAG发送PBA。PBA来源于rfLMA地址，目的地为MAG（IPv6或IPv4）代理转交地址。PBA必须在重定向移动选项中包含r2LMA（IPv6或IPv4）单播地址。其他非安全相关的移动选项（包括负载信息选项）从PBA复制到PBA。
If one of these errors occurs:
如果出现以下错误之一：
o the PBA' Status Value indicates that the mobility session creation failed in the r2LMA. For example, the Status Value in the PBA' is set to 130 (Insufficient resources), or
o PBA的状态值表示r2LMA中的移动会话创建失败。例如，PBA'中的状态值设置为130（资源不足），或
o there was no PBA' response from the r2LMA, or
o r2LMA没有PBA的回应，或者
o the PBA' did not include the Alternate IPv4 Care-of Address option although it was included in the corresponding PBU' (when using IPv4 transport),
o PBA“未包括备用IPv4转交地址选项，尽管它包含在相应的PBU中”（使用IPv4传输时），
then the rfLMA SHOULD assign the MAG to a new r2LMA and rerun the procedure for sending the PBU' described earlier for the new r2LMA. The number and order of r2LMA reassignment attempts is controlled by the local policy and the amount of known r2LMAs in the rfLMA. When the rfLMA in a 'proxy-MAG' role concludes the mobility session creation failed with r2LMA(s), the rfLMA MUST set the Status Value in the PBA as received from the latest contacted PBA' Status Value or to 130 (Insufficient resources) in case of no responses from rfLMAs, and send the reply PBA to the MAG. The PBA is sourced from the rfLMA address and destined to the MAG Proxy Care-of Address. Other possible non-security-related mobility options (including the Load Information option) are copied from the PBA' to the PBA as such.
然后，rfLMA应将MAG分配给新的r2LMA，并重新运行前面为新r2LMA描述的发送PBU'的过程。r2LMA重新分配尝试的次数和顺序由本地策略和rfLMA中已知r2LMA的数量控制。当“代理MAG”角色中的rfLMA断定移动会话创建失败且使用r2LMA时，rfLMA必须将PBA中的状态值设置为从最新联系的PBA状态值接收到的状态值，或者在rfLMA没有响应的情况下设置为130（资源不足），并将回复PBA发送至MAG。PBA来源于rfLMA地址，目的地为MAG代理托管地址。其他可能的非安全相关移动选项（包括负载信息选项）从PBA复制到PBA。
Once the rfLMA has sent the reply PBA to the MAG, it can remove the proxy state. Subsequent traffic between the MAG and the r2LMA will bypass the rfLMA (assuming the mobility session creation succeeded in the r2LMA).
一旦rfLMA将应答PBA发送给MAG，它就可以删除代理状态。MAG和r2LMA之间的后续流量将绕过rfLMA（假设在r2LMA中移动会话创建成功）。
If the rfLMA receives a PBU with no Redirect-Capability mobility option in the PBU, then the PBU is processed as described in Section 5.3, i.e., the rfLMA may or may not act as an [RFC5213] or [RFC5844] LMA to the MAG.
如果rfLMA接收到PBU中没有重定向能力移动选项的PBU，则按照第5.3节所述处理PBU，即rfLMA可以或不可以充当MAG的[RFC5213]或[RFC5844]LMA。
[MAG] [rfLMA] [r2LMA]
| | |
MAG discovers rfLMA | |
BULE for rfLMA | |
| | |
|-- PBU --------------------->| rfLMA assigns a r2LMA and |
| src=MAG_Proxy-CoA, | creates a proxy state |
| dst=rfLMA, | |
| Redirect-Capability, .. | |
| |-- PBU' -------------------->|
| | src=proxy-MAG_Proxy-CoA, |
| | dst=r2LMA, |
| | ACoA/A4CoA=MAG_Proxy-CoA, |
| | .. |
| | BCE created in r2LMA
| | Tunnel setup
| | Proxy-CoA is MAG's address
| | |
| rfLMA removes the |<- PBA' ---------------------|
| proxy state | src=r2LMA, |
| | dst=proxy-MAG_Proxy-CoA, |
| | Load Info, .. |
|<- PBA ----------------------| |
| src=rfLMA, | |
| dst=MAG_Proxy-CoA, | |
| Redirect=r2LMA_address, | |
| Load Info, .. | |
| | |
BULE updated to r2LMA | |
Tunnel setup | |
| | |
|<===================== MAG-r2LMA tunnel ==================>|
| | |
Lifetime extension, etc. | |
| | |
|-- PBU --------------------------------------------------->|
| src=MAG_Proxy-CoA, dst=r2LMA, .. |
| | |
|<- PBA ----------------------------------------------------|
| src=r2LMA, dst=MAG_Proxy-CoA, Load Info, .. |
| | |
[MAG] [rfLMA] [r2LMA]
| | |
MAG discovers rfLMA | |
BULE for rfLMA | |
| | |
|-- PBU --------------------->| rfLMA assigns a r2LMA and |
| src=MAG_Proxy-CoA, | creates a proxy state |
| dst=rfLMA, | |
| Redirect-Capability, .. | |
| |-- PBU' -------------------->|
| | src=proxy-MAG_Proxy-CoA, |
| | dst=r2LMA, |
| | ACoA/A4CoA=MAG_Proxy-CoA, |
| | .. |
| | BCE created in r2LMA
| | Tunnel setup
| | Proxy-CoA is MAG's address
| | |
| rfLMA removes the |<- PBA' ---------------------|
| proxy state | src=r2LMA, |
| | dst=proxy-MAG_Proxy-CoA, |
| | Load Info, .. |
|<- PBA ----------------------| |
| src=rfLMA, | |
| dst=MAG_Proxy-CoA, | |
| Redirect=r2LMA_address, | |
| Load Info, .. | |
| | |
BULE updated to r2LMA | |
Tunnel setup | |
| | |
|<===================== MAG-r2LMA tunnel ==================>|
| | |
Lifetime extension, etc. | |
| | |
|-- PBU --------------------------------------------------->|
| src=MAG_Proxy-CoA, dst=r2LMA, .. |
| | |
|<- PBA ----------------------------------------------------|
| src=r2LMA, dst=MAG_Proxy-CoA, Load Info, .. |
| | |
Figure 3: Separate rfLMA and r2LMA ('proxy-MAG') Example
图3：单独的rfLMA和r2LMA（“proxy-MAG”）示例
A MN can be multi-homed, i.e., have network connectivity over multiple interfaces connected to one or more accesses. If PMIPv6- based handovers between multiple interfaces or accesses are desired, then a single LMA should have a control over all possible multi-homed mobility sessions the MN has. Once the MN has established one mobility session with one LMA, the subsequent mobility sessions of the same MN would be anchored to the LMA that was initially assigned. If each mobility session over a different interface (and possibly a MAG) has no requirements for PMIPv6-based handovers between accesses or interfaces, then the rest of the considerations in this section do not apply.
MN可以是多宿的，即通过连接到一个或多个访问的多个接口具有网络连接。如果需要在多个接口或访问之间进行基于PMIPv6的切换，那么单个LMA应该能够控制MN拥有的所有可能的多宿移动会话。一旦MN与一个LMA建立了一个移动会话，相同MN的后续移动会话将锚定到最初分配的LMA。如果不同接口（可能还有MAG）上的每个移动会话对访问或接口之间基于PMIPv6的切换没有要求，则本节中的其余注意事项不适用。
One possible solution already supported by this specification is applying the runtime LMA assignment only for the very first initial attach a multi-homed MN does towards a PMIPv6 domain. After the initial attach, the assigned r2LMA address has been stored in the policy profile. For the subsequent mobility sessions of the multi-homed MN, the same assigned r2LMA address would be used and there is no need to contact the rfLMA. Ensuring the discovery of the same r2LMA each time relies on the MN having an identity that can always point to the same policy profile, independent of the access that is used.
本规范已经支持的一个可能的解决方案是，仅将运行时LMA分配应用于多宿主MN对PMIPv6域进行的第一次初始连接。初始附加后，分配的r2LMA地址已存储在策略配置文件中。对于多宿MN的后续移动会话，将使用相同的分配r2LMA地址，并且无需联系rfLMA。确保每次发现相同的r2LMA依赖于MN具有始终可以指向相同策略配置文件的标识，而与所使用的访问无关。
MAGs have a control over selectively enabling and disabling the runtime assignment of the LMA. If the multi-homed MN is attached to a PMIPv6 domain via multiple MAGs, the assigned r2LMA address should be stored in the remote policy store and downloaded as a part of the policy profile download to a MAG. Alternatively, MAGs can share policy profile information using other means. In both cases, the actual implementation of the policy profile information sharing is specific to a PMIPv6 deployment and out of scope of this specification.
MAG可以控制选择性地启用和禁用LMA的运行时分配。如果多宿MN通过多个MAG连接到PMIPv6域，则分配的r2LMA地址应存储在远程策略存储中，并作为策略配置文件下载到MAG的一部分进行下载。或者，MAG可以使用其他方式共享策略配置文件信息。在这两种情况下，策略配置文件信息共享的实际实现都特定于PMIPv6部署，超出了本规范的范围。
This specification defines two configuration variables that control the runtime LMA assignment functionality within a PMIPv6 domain.
本规范定义了两个配置变量，用于控制PMIPv6域内的运行时LMA分配功能。
EnableLMARedirectFunction
EnableLMARedirectFunction
This configuration variable is available in both a MAG and in a rfLMA. When set to TRUE (i.e., enabled), the PMIPv6 node enables the runtime LMA assignment functionality. The default value is FALSE (i.e., disabled).
该配置变量在MAG和rfLMA中都可用。当设置为TRUE（即启用）时，PMIPv6节点启用运行时LMA分配功能。默认值为FALSE（即禁用）。
EnableLMARedirectAcceptFunction
EnableLMARedirectAcceptFunction
This configuration variable is available in a r2LMA. When set to TRUE (i.e., enabled), the r2LMA is able to accept runtime LMA assignment mobility sessions from a rfLMA. The default value is FALSE (i.e., disabled).
此配置变量在r2LMA中可用。当设置为TRUE（即启用）时，r2LMA能够接受来自rfLMA的运行时LMA分配移动会话。默认值为FALSE（即禁用）。
Note that the MAG and LMA configuration variables from Sections 9.1 and 9.2 of [RFC5213] do not apply for an LMA when it is in an rfLMA role.
请注意，[RFC5213]第9.1节和第9.2节中的MAG和LMA配置变量不适用于处于rfLMA角色的LMA。
The security considerations of PMIPv6 signaling described in RFC 5213 apply to this document. An incorrectly configured LMA may cause unwanted runtime LMA assignment attempts to non-existing LMAs or to other LMAs that do not have and will not have an SA with the MAG. Consequently, the MAG will experience failed binding updates or unsuccessful creation of mobility sessions. An incorrectly configured LMA may also cause biased load distribution within a PMIPv6 domain. This document also assumes that the LMAs that participate in runtime LMA assignment have adequate prior agreement and trust relationships between each other.
RFC 5213中描述的PMIPv6信令的安全注意事项适用于本文件。配置不正确的LMA可能会导致不存在的LMA或其他LMA尝试进行不必要的运行时LMA分配，这些LMA没有也不会有与MAG的SA。因此，MAG将经历绑定更新失败或移动会话创建失败。配置不正确的LMA也可能导致PMIPv6域内的负载分布有偏。本文档还假设参与运行时LMA分配的LMA彼此之间具有充分的事先协议和信任关系。
If the SAs between MAGs and LMAs are manually keyed (as may be needed by the scenario described in Section 5), then the anti-replay service of ESP-protected PMIPv6 traffic cannot typically be provided. This is, however, deployment specific to a PMIPv6 domain.
如果MAG和LMA之间的SAs为手动键控（如第5节所述场景可能需要），则通常无法提供ESP保护的PMIPv6通信量的防重放服务。然而，这是特定于PMIPv6域的部署。
If a PMIPv6 domain deployment with a runtime LMA assignment requires that a rfLMA has to modify a PBU/PBA in any way, e.g., by changing the source and destination IP address or any other field of the encapsulating IP packet, then the security mechanism (such as possible authentication options) used to protect the PBU/PBA MUST NOT cover the outer IP packet on those parts that might get modified. Alternatively, the rfLMA can do all required security processing on the PBU/PBA, and the communication between the rfLMA and the r2LMA would be unprotected at the PMIPv6 protocol level. In this case, the runtime assignment domain MUST implement an adequate level of security using other means, such as layer-2 VPNs.
如果具有运行时LMA分配的PMIPv6域部署要求rfLMA必须以任何方式修改PBU/PBA，例如，通过更改源和目标IP地址或封装IP数据包的任何其他字段，则安全机制（如可能的身份验证选项）用于保护PBU/PBA不得覆盖可能被修改部分上的外部IP数据包。或者，rfLMA可以在PBU/PBA上执行所有必需的安全处理，并且rfLMA和r2LMA之间的通信将在PMIPv6协议级别上不受保护。在这种情况下，运行时分配域必须使用其他方法（如第2层VPN）实现适当的安全级别。
New mobility options for use with PMIPv6 are defined in the [RFC6275] "Mobility Options" registry. The mobility options are defined in Section 4:
[RFC6275]“移动选项”注册表中定义了用于PMIPv6的新移动选项。第4节中定义了移动选项：
Redirect-Capability Mobility Option 46 Redirect Mobility Option 47 Load Information Mobility Option 48 Alternate IPv4 Care-of Address 49
重定向功能移动选项46重定向移动选项47加载信息移动选项48备用IPv4转交地址49
The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang, Pete McCann, and Qin Wu for their discussion of this document. A special thanks to Qian Li for her detailed feedback on the protocol details.
作者感谢Basavaraj Patil、Domagoj Premec、Ahmad Muhanna、Vijay Devarapalli、Rajeev Koodli、Yungui Wang、Pete McCann和秦武对本文件的讨论。特别感谢钱丽对协议细节的详细反馈。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[RFC5142]Haley，B.，Devarapalli，V.，Deng，H.，和J.Kempf，“移动头归属代理切换消息”，RFC 51422008年1月。
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
[RFC5779]Korhonen，J.，Bournelle，J.，Chowdhury，K.，Muhanna，A.，和U.Meyer，“Diameter代理移动IPv6：移动接入网关和本地移动锚与Diameter服务器的交互”，RFC 5779，2010年2月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 2011.
[RFC6097]Korhonen，J.和V.Devarapalli，“代理移动IPv6的本地移动锚（LMA）发现”，RFC 60972011年2月。
Authors' Addresses
作者地址
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland
Jouni Korhonen（编辑）诺基亚西门子网络公司Linnoitustie 6 FI-02600 Espoo芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
横田英寿KDDI实验室2-1-15 Ohara，Fujimino Saitama 356-8502日本
EMail: yokota@kddilabs.jp
EMail: yokota@kddilabs.jp
Xiangsong Cui Huawei Technologies Huawei Building, No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan Hai-Dian District, Beijing 100095 P.R. China
中国北京市海淀区石创科技园区北青路Z-park 156号三星科技华为大厦，邮编100095
EMail: Xiangsong.Cui@huawei.com
EMail: Xiangsong.Cui@huawei.com