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
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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割り当ては、プロキシ・バインディング更新（PBU）とモバイルアクセスゲートウェイ（MAG）とLMAとの間の確認応答（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）または認証、許可、およびモバイル・ノード（MN）が固定されているためにLMAの割り当てに関する会計（AAA）インフラストラクチャに依存しません。すべてのMAGとのLMA（rfLMAsまたはr2LMAsのいずれか、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.
複数のIPアドレスを持つのLMA（O）のLMA又はブレードアーキテクチャLMAのクラスタは、別個のユニキャストIPアドレスを持つ複数のLMAとしてルーティングシステムに表示されてもよいです。 MAGは、最初に、例えば、DNS-及びAAAベースのソリューションを使用して、サービングLMAとしてのLMAのいずれかを選択することができます。しかし、MAGの最初の選択は、ビューと即時実行時の割り当てのLMA点から必要とされるであろう、「適切なLMA」に次善のかもしれません。 LMAは、[RFC5142]ベースのアプローチを使用することができるが、バックエンドサポートシステム相互作用、MAGとLMAとの間の追加のシグナリングに関連してそれが「間違った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からの可能な個々LMA又はLMAブレードIPアドレスを隠蔽こうしてMAGにさらされることになります。すべてのトラフィックは常にロードバランサを経由しなければならない場合は、それはすぐにボトルネックになります。したがって、初期の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を使用して、LMA負荷状態と最新のMAGを維持することは、キャッシュおよび予測不可能なゾーン更新遅延[RFC6097]に、例えば、ハードディスクです。一般的に、のLMAは、常にマスターDNSサーバーと追加のバックグラウンドシグナル伝達に対する負荷の増加に伴う大規模なPMIPv6ドメインで実行可能ではないかもしれない[RFC2136]ゾーンのマスターDNSサーバーを更新します。さらに、の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ベースのソリューションは、DNSインフラストラクチャ[RFC5779]に初期LMA選択をオフロードすることも一般的です。 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.
[RFC4291]をIPv6アドレスエニーキャスト用Oサポート：現在の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を選択するために使用することができません。したがって、この仕様はMAGに知られているIPアドレスは、実行時に選択した最高のLMAない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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In addition to the terminology defined in [RFC5213], the following terminology is also used: rfLMA
[RFC5213]で定義された用語に加えて、以下の用語も使用される。rfLMAを
An LMA that receives a PBU from a MAG and decides to assign an IP mobility session with a new target LMA (r2LMA).
MAGからPBUを受信して、新しいターゲットLMA（r2LMA）とIPモビリティセッションを割り当てることを決定LMA。
r2LMA
r2LMA
The LMA assigned to a MAG as a result of the runtime LMA assignment.
LMAは、ランタイムLMAの割り当ての結果として、MAGに割り当てられています。
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および1つまたは複数のr2LMAs（全てが同じPMIPv6ドメインの一部である）から成るのLMAのグループ。 rfLMAは、同じ実行時の割り当てドメインに属しているだけr2LMAsとのMAGを割り当てることが許可されています。 rfLMAおよび1つまたは複数のr2LMAsは、単一のネットワーク要素、複数の物理ネットワーク要素、または地理的に分散した複数の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）を事前に確立を必要としていると想定されます。 SAの動的ネゴシエーション使用は、例えば、のIKEv2 [RFC5996]は、サポートされているが、この明細書の範囲外であることべきです。
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でゼロまたは1リダイレクト機能のモビリティオプションが存在する場合があります。リダイレクト-能力モビリティオプションのフォーマットを以下に示します。
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オプションタイプ：46に設定し、8ビットの識別子。
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.
リダイレクト機能オプションは、それが実装され、実行時のLMAの割り当て機能を有効にしていることをLMAに通知するために、MAGによって使用されます。
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にはゼロまたは1つリダイレクトモビリティオプションが存在する場合があります。リダイレクトモビリティオプションは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Mobility Option
モビリティオプションをリダイレクト
o Option Type: 8-bit identifier set to 47.
Oオプションタイプ：47に設定し、8ビットの識別子。
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」未設定である場合は「K」フラグが設定されていない場合、長さは18でなければなりませんし、「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」フラグ：このビットが設定されている（1）「オプションのIPv6 r2LMAアドレスが」モビリティオプションに含まれている場合。そうでなければ、ビットが設定されていない（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」フラグ：このビットが設定されている（1）「オプションのIPv4 r2LMAアドレスが」モビリティオプションに含まれている場合。そうでなければ、ビットが設定されていない（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は、モビリティセッションのためのそのバインディング更新リストエントリ（BULE）を更新する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Load Information Mobility Option
ロードインフォメーションモビリティオプション
o Option Type: 8-bit identifier set to 48.
Oオプションタイプ：48に設定し、8ビットの識別子。
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 FQDN、ドメイン名、又は領域によって決定される、例えば、同じ管理下のLMAのグループのうち意味を持ちます。
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.
秒あたりのキロバイトLMAの使用帯域幅/スループット容量を表す32ビットの符号なし整数：Oキャパシティを使用しました。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alternate IPv4 Care-of Address Mobility Option
代替のIPv4気付アドレスモビリティオプション
o Option Type: 8-bit identifier set to 49.
Oオプションの種類：49に設定する8ビットの識別子。
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気付アドレス：[RFC6275]代替気付IPv6のアドレスオプションの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気付アドレスのオプションを含むかもしれません。受信して返信PBAに戻っMAGへのようなオプションをエコーしなければならない代替のIPv4気付アドレスのオプションを実装してLMA。
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はrfLMAアドレスから、PBUが送信されたとLMAアドレス、すなわちから返されます。ランタイムLMA割り当てた後、全てのPMIPv6通信はMAGとrfLMAをバイパスr2LMA間で直接続けます。全体的なランタイム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.
| | |
Figure 1: Runtime LMA Assignment from rfLMA to r2LMA and Setting Up a Mobility Session in the r2LMA within a Runtime Assignment Domain
図1：r2LMAへrfLMAからランタイム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:
rfLMAはMAGとのインターフェースを担当しているが、図1に示す信号フロー工程1）における仮定は、モビリティセッションがr2LMAで作成されることです。 rfLMAとに応じr2LMA相互作用、例えば、rfLMAとr2LMAのコロケーションプロパティのいくつかの可能な解決策があります。この仕様は2について説明します。
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「LMAのrfLMA側は」エニーキャストアドレス又はLMAのループバックアドレスを介して到達可能であるrfLMAとr2LMA機能を、共存。詳細は、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.
rfLMAがr2LMAに非透過「プロキシMAG」として働くO独立rfLMAとr2LMA機能、。詳細については、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を送信します。 MAGに送り返さこれはLMAにバインディングキャッシュエントリ（BCE）の生成をもたらすとLMAはPBAを送信します。順番にMAGは、対応するバインディング更新リストエントリ（BULE）を作成します。この仕様は、ランタイム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の割り当てをサポートしており、機能も有効になっている場合（すなわち、ハンドオフIndicatorオプション、そしてMAGは新しいモビリティセッションを確立PBUにおけるリダイレクト-能力モビリティオプションが含まれ（第7節でEnableLMARedirectFunction構成変数を参照してください） PBU中）1の値を有します。 PBUでリダイレクト-能力モビリティオプションは、MAGは、ランタイムLMAの割り当て機能をサポートし、異なるLMAに割り当てられるように準備されていることもLMAへの指示です。一度に実行時のLMA割り当ての懸念は常に1つのモビリティセッション。
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が最初対応PBUにおけるリダイレクト機能モビリティオプションを含めずにリダイレクトモビリティオプションが含まれているPBAを受信した場合、その後、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におけるリダイレクト機能モビリティオプションが含まれていた場合、MAGは、通常、[RFC5213] PBA処理に加えて、以下の手順を実行する必要があります
o The MAG updates its BULE to contain the r2LMA address included in the received Redirect mobility option.
O MAGは受信リダイレクトモビリティオプションに含まr2LMAアドレスを含むようにそのBULEを更新します。
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.
MAGとr2LMA間にSAが存在しない場合は、RFC 5213のセクション4に記載されるように動的SAの作成に失敗した場合は、O、MAGは、MAGとr2LMA間のSAの動的生成を開始すべき、MAGは、ログインする必要がありイベント。 MAGは、SAを動的に作成を再試行することができ、それらはまた失敗した場合、新しく作成されたBULE（とも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は、後続のバインディング更新のPBUを送信しなければならない（例えば、長寿命化、ハンドオフ、等）r2LMAアドレスへ。 MAGとr2LMAユニキャストアドレスとの間に既存のトンネルが存在しない場合は[RFC5213]のセクション6.9.1.2に記載されるように、次いで、MAGは、作成されます。
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'.
以下のセクション内のテキストは、それがrfLMAとr2LMAの組み合わせを意味する「LMA」、すなわち、ランタイム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が、LMAの割り当て中（第7節でEnableLMARedirectFunction構成変数を参照してください）、およびrfLMAはとして機能するように喜んで（またはサービス提供ができない）ではありませんMAGに対する通常の[RFC5213] LMAは、次にrfLMAはPBUを拒絶し、130（不十分なリソース）に設定された状態値のエラーコードでPBAを返送しなければなりません。 rfLMAがr2LMAへの割り当てを行うことが可能である場合は、以下に定義されるように、それはリダイレクトモビリティオプションとPBAを返します。そうでなければ、rfLMAは、通常、[RFC5213]のように作用しなければならない - または[RFC5844] MAGためLMAを-defined。
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はSAを持って知っているとか、MAGが動的にSAを確立することができます知っていると新しいr2LMAにMAGを割り当てる必要があります。 rfLMAはrfLMAとr2LMAは、事前の合意およびランタイムLMAの割り当てのために確立された信頼関係を持っていないことr2LMAでMAGを割り当ててはなりません。これらのSAに関連する知識の問題との信頼関係は、PMIPv6ドメイン内および実行時の割り当てドメイン内の特定の展開であり、この仕様の範囲外。 rfLMAとr2LMA間の可能なコンテキスト転送およびその他の調整管理が再び実行時の割り当てドメイン内のLMAの展開固有のものです。 rfLMAは、ランタイムLMAの割り当ての際に使用されるトランスポートの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のステータス値のRedirectモビリティオプションを含まなければなりません。
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の割り当てのための2つの展開と実装モデルを記述する。 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構成は、1つの可能性です。
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ユニキャストアドレスとの間に既存のトンネルが存在しない場合は[RFC5213]のセクション5.3で説明したように、その後r2LMAが作成されます。 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ユニキャストアドレス（IPv4またはIPv6）を含まなければなりません。
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.
PBUがr2LMAユニキャストアドレスで受信された場合には、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).
PBUはrfLMAアドレスに受信され、PBUにはリダイレクト-能力モビリティオプションがない場合は、「同じ場所に配置LMAは、」（rfLMAアドレスはエニーキャストアドレスではないと仮定）MAGのためのLMAであることを選ぶかもしれ。それ以外の場合は、rfLMAはPBUを拒否し、130（リソースが不足）に設定するステータス値とrfLMAの役割にPBAを送り返し、エラーコード（第5.3節で述べたように）しなければなりません。
[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は、2つの分離機能があり、さらには物理的に別個のネットワークノードであってもよいです。 IPv6トランスポートを使用する場合、本明細書のいずれかの知識を持っていないか、[RFC5844]に準拠LMA - r2LMAは任意[RFC5213]であることができます。 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に向けてこの仕様を実現LMAとして表示非透過「プロキシMAG」であり、そして塩基として[RFC5213] r2LMAに準拠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は、SAの考慮が十分に適用MAGとrfLMA、及び[RFC5213]の間です。 MAGは、「プロキシMAG'-r2LMA SAの知識を持ちません。 [RFC5213]「プロキシMAG」とr2LMA間SAについての考察は十分当てはまります。プロキシMAG'-r2LMAセキュリティがレイヤ2 VPNを使用して、例えば、IPsecの以外の手段を使用して配置されることも可能です。
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はMAGにr2LMAを割り当てます。
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と、元のMAGの気付アドレスプロキシを含む代替気付アドレス（ACOA）オプションからすべての非セキュリティ関連のモビリティオプションを含む新しいPBU」を作成します。元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）オプションを使用し、IPv4プロキシ元のMAGの気付アドレスを含んでいなければなりません。
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はプロキシMAG 『のIPv6又はIPv4のプロキシ気付アドレス「はから供給』及び（IPv4トランスポートの場合、またはRFC 5844）RFC 5213に記載の手順を用いてr2LMAアドレス宛ての新しいPBUを送信します。
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は、IPv4輸送の場合にはRFC 5213またはRFC 5844.に記載された手順を使用して、受信したPBU」を処理し、r2LMAは、IPv4プロキシトンネル設定および作成のための代替のIPv4気付アドレスのオプションから気付アドレスを使用しBCEの。応答PBAは、気付アドレス 『プロキシMAG』、即ち、「受信したPBUのソース・アドレスに宛てなければなりません」。
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（IPv4またはIPv6）プロキシ気付アドレスを宛先としています。 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),
（IPv4トランスポートを使用している場合）PBA O「それは、対応する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は新しいr2LMAにMAGを割り当て、新しいr2LMAのために先に説明したPBU「を送信するための手順を再実行する必要があります。 r2LMA再割り当て試行の数および順序は、ローカルポリシーとrfLMAにおける既知r2LMAsの量によって制御されます。 「プロキシ-MAGの役割でrfLMAがr2LMA（S）で失敗しましたモビリティセッションの作成を終了すると130（リソースが不足）の最新の連絡PBA」ステータス値から、あるいは、受け取ったとして、rfLMAはPBAのStatus値を設定する必要がありますrfLMAsから無応答の場合、およびMAGに返信PBAを送信します。 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がMAGに返信PBAを送信した後は、プロキシの状態を削除することができます。 MAGとr2LMA間の後続のトラフィックは（r2LMAに成功したモビリティ・セッションの作成を想定）rfLMAをバイパスします。
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を受信した場合、PBUは、すなわち、セクション5.3で説明したように、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, .. |
| | |
Figure 3: Separate rfLMA and r2LMA ('proxy-MAG') Example
図3：個別rfLMAとr2LMA（ 'プロキシ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は、1つのLMAと1つのモビリティセッションを確立していたら、同じ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割り当て機能を制御する2つのコンフィギュレーション変数を定義します。
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.
それはrfLMAの役割であるとき、セクション9.1と[RFC5213]の9.2からMAGとLMA構成変数は、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または持っていないとMAGとのSAを持っていないであろう他のLMAに不要なランタイムLMAの割り当ての試みを引き起こす可能性があります。その結果、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との間のSAは手動で（セクション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は、送信元と送信先のIPアドレスまたはカプセル化IPパケットの他のフィールドは、セキュリティ・メカニズムを変更することで、例えばどのような方法でPBU / PBAを変更する必要があることを必要とする場合そのような可能な認証オプションなど）PBU / PBAが変更される可能性がありますそれらの部分の外側のIPパケットをカバーしてはならない保護するために使用します。あるいは、PBU / PBAに必要なすべてのセキュリティ処理を行うことができrfLMA、及び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:
PMIPv6で使用する新しいモビリティオプションは、[RFC6275]「モビリティオプション」レジストリで定義されています。モビリティオプションは、セクション4で定義されています。
Redirect-Capability Mobility Option 46
Redirect Mobility Option 47
Load Information Mobility Option 48
Alternate IPv4 Care-of Address 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パティル、Domagoj Premec、アフマドMuhanna、ビジェイDevarapalli、ラジーブKoodli、Yungui王、ピートマッキャン、および秦呉に感謝したいと思います。プロトコルの詳細について彼女の詳細なフィードバックのための銭リーに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年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.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年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.、Frystyk、H.、Masinter、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[RFC5142]ヘイリー、B.、Devarapalli、V.、鄧小平、H.、およびJ.ケンプ、 "モビリティヘッダホーム・エージェント・スイッチ・メッセージ"、RFC 5142、2008年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.、チョードリ、K.、Muhanna、A.、およびU.マイヤー、 "直径プロキシモバイル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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年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、 "ローカル・モビリティ・アンカー（LMA）プロキシモバイルIPv6の検出"、RFC 6097、2011年2月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 FI-02600エスポー、フィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
スリGundavelliシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: sgundave@cisco.com
メールアドレス：sgundave@cisco.com
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
ひでとし よこた Ｋっぢ ぁｂ ２ー１ー１５ おはら、 ふじみの さいたま ３５６ー８５０２ じゃぱん
EMail: yokota@kddilabs.jp
メールアドレス：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
銅IH UAを供給することによりξGはHU Aは156は、北京100095 IグリーンRD。Z-公園、市-C黄色-ke-J I市-ファン元H愛-Dイアン地区のない、構築された技術でありますPR中国
EMail: Xiangsong.Cui@huawei.com
メールアドレス：Xiangsong.Cui@huawei.com