[要約] RFC 6463は、Proxy Mobile IPv6におけるランタイムローカルモビリティアンカー（LMA）の割り当てサポートに関する規格です。このRFCの目的は、モバイルノードの移動中にLMAの割り当てを効率的に行うための手法を提供することです。
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
ランタイムローカルモビリティアンカー（LMA）プロキシモバイル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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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割り当て機能は、たとえば、負荷分散の目的で使用できます。MAGSと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割り当て機能は、モバイルノード（MN）が固定されているLMAの割り当てのためのドメイン名システム（DNS）または認証、承認、および会計（AAA）インフラストラクチャに依存しません。すべてのMAGSと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.
o 複数のIPアドレスを備えたLMA：LMAまたはブレードアーキテクチャのクラスターLMAは、ルーティングシステムに別々のユニキャストIPアドレスを持つ複数のLMAとして表示される場合があります。MAGは、最初に、DNSおよびAAAベースのソリューションなど、LMAを使用して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の1つに統合されている場合があります。負荷バランサーは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を使用したLMA負荷状態でMAGSを最新に保つことは困難です。たとえば、キャッシングと予測不可能なゾーン更新の遅延[RFC6097]のためです。一般的に、[RFC2136]ゾーンのマスターDNSサーバーを常に更新するLMAは、マスターDNSサーバーの負荷が増加し、バックグラウンドシグナル伝達が追加されているため、大きなPMIPV6ドメインでは実現できない可能性があります。さらに、MAGSは、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インフラストラクチャは、IPアドレスまたは完全資格のドメイン名（FQDN）を単一のLMAに返しません。むしろ、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 Anycastアドレス指定[RFC4291]のサポート：現在のPMIPv6仕様は、PMIPv6プロトコルがモビリティエージェントに割り当てられたAnycastアドレスをどのように扱うかを指定していません。たとえば、ブレードアーキテクチャLMAには、ブレードごとに一意のユニキャストIPアドレスがあり、すべてのブレードに1つのAnycastアドレスがある場合があります。その後、MAGは最初にANYCAST LMAアドレスにPBUを送信し、Anycast 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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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).
MAGからPBUを受け取り、新しいターゲットLMA（R2LMA）でIPモビリティセッションを割り当てることを決定するLMA。
r2LMA
R2LMA
The LMA assigned to a MAG as a result of the runtime LMA assignment.
ランタイムLMA割り当ての結果として雑誌に割り当てられた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.
少なくとも1つのRFLMAと1つ以上のR2LMA（すべて同じPMIPV6ドメインの一部）で構成されるLMAのグループ。RFLMAは、同じランタイム割り当てドメインに属するR2LMAでのみMAGを割り当てることができます。RFLMAおよび1つ以上の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は、事前に確立されたセキュリティ協会（SAS）が必要とされていると想定されています。たとえば、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には、ゼロまたは1つのリダイレクトキャピールモビリティオプションがあります。Redirect-Capabilityモビリティオプションの形式を以下に示します。
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.
Redirect-Capabilityオプションは、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には、ゼロまたは1つのリダイレクトモビリティオプションがあります。リダイレクトモビリティオプションには、4Nのアライメント要件があります。Redirect Mobilityオプションの形式を以下に示します。
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」が設定されている場合、長さは18でなければなりません。「k」フラグが設定されていて、「n」が設定されている場合、長さは6でなければなりません。'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' flag：このビットは設定されています（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に含めることができ、LMAの優先順位と主要な負荷情報をMAG（または「プロキシマグ」）に報告するために使用できます。負荷情報モビリティオプションには、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 優先度：LMAの優先度を表す16ビットの署名整数。値が低いほど、優先度が高くなります。優先度は、たとえば、一般的なLMA FQDN、ドメイン名、または領域によって決定される、同じ投与の下でのLMAのグループ間でのみ意味があります。
o Sessions in Use: 32-bit unsigned integer, representing the number of parallel mobility sessions the LMA has in use.
o 使用中のセッション：LMAが使用している並列モビリティセッションの数を表す32ビットの非署名整数。
o Maximum Sessions: 32-bit unsigned integer, representing the maximum number of parallel mobility sessions the LMA is willing to accept.
o 最大セッション：LMAが受け入れる意思がある並列モビリティセッションの最大数を表す32ビットの非署名整数。
o Used Capacity: 32-bit unsigned integer, representing the used bandwidth/throughput capacity of the LMA in kilobytes per second.
o 使用容量：32ビットの署名されていない整数。1秒あたりのキロバイトでの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ビットの署名されていない整数。1秒あたりのキロバイトの最大帯域幅/スループット容量を表します。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（または「プロキシマグ」）は、優先順位とロード情報を使用して、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 Care-of Address（A4COA）モビリティオプションには、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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]に相当するIPv4 IPv6の代替ケアオブアドレスオプション。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の雑誌にそのようなオプションをエコーする必要があります。
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と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：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に示されていることです。RFLMAはMAGとのインターフェースに責任を負うが、モビリティセッションがR2LMAで作成されることです。RFLMAとR2LMAの相互作用には、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側」がanycastアドレスまたは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はRFLMAとR2LMA機能を分離し、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がPBUをLMAに送信します。これにより、LMAとLMAでバインディングキャッシュエントリ（BCE）が作成され、MAGに送信された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の割り当てをサポートし、機能も有効になっている場合（セクション7のenablelMaredirectFunction構成変数を参照）、MAGには新しいモビリティセッションを確立するPBUのリダイレクト容量モビリティオプションが含まれます（つまり、ハンドオフインジケーターオプションオプションが含まれます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アドレスを含むように、そのブールを更新します。
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の動的な作成を開始する必要があります。。MAGはSAの動的な作成を再試行する可能性があり、それらも失敗した場合、新しく作成されたブール（および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].
マグは、ランタイムの割り当てが成功した後、R2LMAに新鮮なPBUを送信する必要はありません。モビリティセッションはすでにR2LMAで確立されています。MAGは、すべてのユーザートラフィックをR2LMAアドレスに送信する必要があります。MAGは、後続のバインディングリフルディングPBU（寿命延長、ハンドオフなど）をR2LMAアドレスに送信する必要があります。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'.
次のセクションのテキストは、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の割り当ては何らかの理由で行われず、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を新しいR2LMAにのみ割り当てる必要があります。このR2LMAには、MAGがSAを持っているか、MAGがSAを動的に確立できることを知っています。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ステータス値が成功を示すリダイレクトモビリティオプションを含める必要があります。
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が非透明な「プロキシマグ」として機能するモデルと、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のAnycastまたはループバックアドレスを介して到達可能です。各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のAnycastまたはLoopbackアドレス）の間です。この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).
RFLMAは、ランタイムLMA割り当て機能が有効になるとアクティブになります（セクション7のenablelMaredirectFunction構成変数を参照）。RFLMAがそれに向けられたPBUを受信し、PBUにリダイレクト能力モビリティオプションが含まれている場合、[RFC5213]で説明されている手順を使用して、「共同配置LMA」はR2LMA役割でモビリティセッションを作成する必要があります。MAGとR2LMAユニキャストアドレスの間に既存のトンネルがない場合、R2LMAは[RFC5213]のセクション5.3で説明されているように作成します。
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（AnycastまたはLoopback）アドレスを使用して調達されます。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.
PBUがR2LMAユニキャストアドレスで受信された場合、PBUはRFC 5213で説明されているように処理され、応答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にリダイレクト能力モビリティオプションがない場合、「Co-located LMA」はMAGのLMAになることを選択できます（RFLMAアドレスがAnyCastアドレスではないと仮定します）。それ以外の場合、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つの単離された関数であり、物理的に個別のネットワークノードである場合もあります。R2LMAは[RFC5213] - または[RFC5844]を使用する任意の[RFC5213] - または[RFC5844] - IPv6トランスポートを使用したときにこの仕様の知識がないことができます。IPv4トランスポートの場合、[RFC5844] -compliant 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として、また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」-R2LMA SAの知識はありません。[RFC5213]「プロキシマグ」とR2LMAの間のSAに関する考慮事項は完全に適用されます。また、 'Proxy-Mag'-R2LMAセキュリティは、たとえばLayer-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にリダイレクト能力モビリティオプションが含まれている場合、「プロキシマグ」の役割で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を雑誌に割り当てます。
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）オプションを使用し、元の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（またはIPv4トランスポートの場合にRFC 5844）で説明されている手順を使用して、「プロキシ-Mag」IPv6またはIPv4プロキシケアオブアドレスから供給され、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は、RFC 5213またはRFC 5844で説明されている手順を使用して受信したPBU 'を処理します。IPv4輸送の場合、R2LMAは、トンネルセットアップと作成の代替IPv4ケアオプションオプションからIPv4プロキシケアオブアドレスを使用します。BCEの。返信PBA 'は、受信した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.
「プロキシマグ」の役割のRFLMAがR2LMAからReply PBAを受信し、モビリティセッションの作成がR2LMAで成功すると、RFLMAはPBAを元のMAGに送信します。PBAはRFLMAアドレスから供給され、MAG（IPv6またはIPv4）プロキシケアオブアドレスに運命づけられています。PBAには、リダイレクトモビリティオプションにR2LMA（IPv6またはIPv4）ユニキャストアドレスが含まれている必要があります。その他の非セキュリティ関連のモビリティオプション（負荷情報オプションを含む）は、PBA 'からPBAにコピーされます。
If one of these errors occurs:
これらのエラーの1つが発生した場合：
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 'には、対応するPBU'（IPv4輸送を使用する場合）に含まれていましたが、代替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の量によって制御されます。「プロキシマグ」の役割のRFLMAがR2LMAで失敗したモビリティセッションの作成が結論付ける場合、RFLMAは最新の連絡先のPBAのステータス値または130（リソースが不十分）から受信したPBAのステータス値を設定する必要があります。RFLMASからの応答がない場合、Reply 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がReply 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を受信した場合、PBUはセクション5.3で説明されているように処理されます。。
[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はマルチホームにすることができます。つまり、1つ以上のアクセスに接続された複数のインターフェイス上のネットワーク接続を備えています。複数のインターフェイスまたはアクセスの間の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.
この仕様ですでにサポートされている可能なソリューションの1つは、マルチホームMNがPMIPv6ドメインに向けて行う最初の初期添付に対してのみランタイムLMA割り当てを適用することです。最初の添付後、割り当てられたR2LMAアドレスがポリシープロファイルに保存されました。マルチホームMNのその後のモビリティセッションでは、同じ割り当てられたR2LMAアドレスが使用され、RFLMAに連絡する必要はありません。毎回同じR2LMAの発見を確保することは、使用されているアクセスとは無関係に、同じポリシープロファイルを常に指すことができるIDを持つ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.
[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またはMAGのSAを持っていない他の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.
MAGSと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:
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 Patil、Domagoj Premec、Ahmad Muhanna、Vijay Devarapalli、Rajeev Koodli、Yungui Wang、Pete McCann、Qin Wuに感謝したいと思います。プロトコルの詳細に関する詳細なフィードバックについて、Qian Liに感謝します。
[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、「Proxy Mobile 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 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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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 4291、2006年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、「Mobility Header Home Agent Switch Message」、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.、Chowdhury、K.、Muhanna、A。、およびU. Meyer、 "Diameter Proxy Mobile IPv6：モバイルアクセスゲートウェイと直径サーバーとのローカルモビリティアンカー相互作用"、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、「Proxy Mobile 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、「Internet Key Exchange Protocolバージョン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（編集者）Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland
EMail: jouni.nospam@gmail.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
Hidetoshi Yokota Kddi Lab 2-1-15 Ohara、Fujimino Saitama 356-8502 Japan
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
Xiangsong Cui Huawei Technologies Huawei Building、No。156Beiqing Rd。Z-Park、Shi-chuang-ke-ji-ji-shi-fan-yuan hai-dian地区、北京100095 P.R.中国
EMail: Xiangsong.Cui@huawei.com