[要約] 要約： RFC 7161は、Proxy Mobile IPv6（PMIPv6）マルチキャストハンドオーバーオプティマイゼーションに関する技術仕様であり、LMAを介した購読情報の取得（SIAL）を提供します。目的： このRFCの目的は、PMIPv6ネットワークでのマルチキャストハンドオーバーの最適化を実現するために、購読情報の効率的な取得方法を提供することです。
Internet Engineering Task Force (IETF) LM. Contreras
Request for Comments: 7161 Telefonica I+D
Category: Experimental CJ. Bernardos
ISSN: 2070-1721 I. Soto
UC3M
March 2014
Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)
LMA（SIAL）を介したサブスクリプション情報取得によるプロキシモバイルIPv6（PMIPv6）マルチキャストハンドオーバの最適化
Abstract
概要
This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).
このドキュメントでは、プロキシモバイルIPv6（PMIPv6）の実験的なマルチキャストハンドオーバ最適化メカニズムを指定して、ハンドオーバ後のモバイルノードへのマルチキャストトラフィックの配信を加速します。 LMA（SIAL）によるサブスクリプション情報取得と呼ばれるメカニズムは、モバイルアクセスゲートウェイによるモバイルノードのマルチキャストコンテキストの取得の高速化に基づいています。そのために、現在のPMIPv6プロトコルの拡張が提案されています。これらの拡張機能は、プロキシモバイルIPv6でのマルチキャストサポートの基本ソリューションに適用できるだけでなく、トンネル収束の問題を回避するために開発された他のソリューションにも適用できます。さらに、これらの拡張機能は、マルチキャストネットワーク内のモバイルアクセスゲートウェイが果たす役割（マルチキャストリスナー検出プロキシまたはマルチキャストルーターとして機能）からも独立しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7161.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7161で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Handover Optimization
Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proxy Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 8
4.1. Active Multicast Subscription Mobility Option . . . . . . 8
4.1.1. Option Application Rules . . . . . . . . . . . . . . 8
4.1.2. Option Format . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Backward Compatibility with MLDv1 . . . . . . . . . . 9
4.2. Multicast Signaling Flag on PBU/PBA Message Headers . . . 10
4.2.1. Flag Application Rules . . . . . . . . . . . . . . . 10
4.2.1.1. Registration Process . . . . . . . . . . . . . . 11
4.2.1.2. De-registration Process . . . . . . . . . . . . . 12
4.2.2. New Format of Conventional PBU/PBA Messages . . . . . 12
4.2.2.1. Proxy Binding Update Message . . . . . . . . . . 12
4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13
4.3. Messages for Active Multicast Subscription Query . . . . 13
4.3.1. Subscription Query Message . . . . . . . . . . . . . 13
4.3.1.1. Message Application Rules . . . . . . . . . . . . 13
4.3.1.2. Message Format . . . . . . . . . . . . . . . . . 14
4.3.2. Subscription Response Message . . . . . . . . . . . . 15
4.3.2.1. Message Application Rules . . . . . . . . . . . . 15
4.3.2.2. Message Format . . . . . . . . . . . . . . . . . 15
4.4. New PBA Timer in the LMA . . . . . . . . . . . . . . . . 16
5. Handover Signaling Procedures . . . . . . . . . . . . . . . . 17
5.1. Handover of Proactive Type . . . . . . . . . . . . . . . 17
5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Message Flow Description . . . . . . . . . . . . . . 18
5.2. Handover of Reactive Type . . . . . . . . . . . . . . . . 20
5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Message Flow Description . . . . . . . . . . . . . . 21
5.2.3. Further Considerations for the Reactive Handover
Signaling . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Prevention of Large Delays of the Binding
Acknowledgement for Unicast Traffic . . . . . . . . . . . 23
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26
6.2. Signaling Procedures for IPv4 Support . . . . . . . . . . 27
6.3. Binding Cache Extensions for IPv4 Support . . . . . . . . 28
7. Coexistence with PMIPv6 Multicast Architectural
Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Performance Comparison with Base Solution . . . . . 34
A.1. Delay Characterization of the Base Solution . . . . . . . 34
A.2. Delay Characterization of SIAL . . . . . . . . . . . . . 35
A.3. Performance Comparison . . . . . . . . . . . . . . . . . 35
The base solution for providing continuous multicast service delivery in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]. It specifies the basic functionality needed in the Proxy Mobile IPv6 [RFC5213] entities to provide a multicast service, so continuous delivery of multicast traffic is supported by obtaining, after each handover, the ongoing multicast subscription information directly from the Mobile Node (MN). When a mobile node attaches to a new Mobile Access Gateway (MAG), the mobile node is queried by the mobile access gateway through a Multicast Listener Discovery (MLD) General Query, which is sent just after any new link is set up, to learn of any existing subscription, as specified in [RFC2710] and [RFC3810].
Proxy Mobile IPv6（PMIPv6）ドメインで継続的なマルチキャストサービス配信を提供するための基本ソリューションは、[RFC6224]で説明されています。これは、マルチキャストモバイルIPv6 [RFC5213]エンティティがマルチキャストサービスを提供するために必要な基本機能を指定します。そのため、各ハンドオーバーの後に、モバイルノード（MN）から直接進行中のマルチキャストサブスクリプション情報を取得することで、マルチキャストトラフィックの継続的な配信がサポートされます。モバイルノードが新しいモバイルアクセスゲートウェイ（MAG）に接続すると、モバイルノードは、新しいリンクが設定された直後に送信されるマルチキャストリスナーディスカバリ（MLD）一般クエリを介してモバイルアクセスゲートウェイによって照会されます。 [RFC2710]および[RFC3810]で指定されている既存のサブスクリプションの。
However, the base solution needs to be improved to meet some performance requirements, especially those referring to the user-perceived service quality, which is seriously affected by the disruption of multicast content forwarding to the mobile node during handovers.
ただし、ベースソリューションは、一部のパフォーマンス要件、特にユーザーが認識したサービス品質に関連する要件を満たすように改善する必要があります。これは、ハンドオーバー中のモバイルノードへのマルチキャストコンテンツ転送の中断によって深刻な影響を受けます。
A mobile node with an active multicast subscription, moving from one point of attachment to another within a Proxy Mobile IPv6 domain, experiences a certain delay until it resumes receiving again the multicast content that it was receiving at the previous location.
プロキシモバイルIPv6ドメイン内のある接続点から別の接続点に移動する、アクティブなマルチキャストサブスクリプションを持つモバイルノードは、以前の場所で受信していたマルチキャストコンテンツの受信を再開するまで、一定の遅延を経験します。
Such delay causes a gap in the content reception. Two different actions can help mitigate such reception gap. One of them is to buffer at the previous mobile access gateway a copy of the multicast traffic destined to the mobile node and forward it to the new mobile access gateway, in order to deliver that traffic to the mobile node. The other possible (complementary) action is to reduce the time needed by the new mobile access gateway to learn of the active multicast subscription of the mobile node (i.e., the multicast context), so the new mobile access gateway can subscribe to the multicast group(s) on behalf of the mobile node as soon as possible.
このような遅延により、コンテンツの受信にギャップが生じます。 2つの異なるアクションは、このような受信ギャップを緩和するのに役立ちます。それらの1つは、以前のモバイルアクセスゲートウェイで、モバイルノード宛のマルチキャストトラフィックのコピーをバッファリングし、それを新しいモバイルアクセスゲートウェイに転送して、そのトラフィックをモバイルノードに配信することです。もう1つの可能な（補足）アクションは、新しいモバイルアクセスゲートウェイがモバイルノードのアクティブなマルチキャストサブスクリプション（マルチキャストコンテキスト）を知るために必要な時間を短縮することです。これにより、新しいモバイルアクセスゲートウェイはマルチキャストグループにサブスクライブできます。 （s）できるだけ早くモバイルノードに代わって。
While the first mechanism could potentially be accomplished by using some adaptation of [RFC5949] to multicast traffic (despite being only applicable in the case the underlying radio access technology supports Layer 2 (L2) triggers, thus requiring additional support on the mobile node), there is no generic standard solution for the accelerated acquisition of the ongoing multicast subscription of the mobile node.
最初のメカニズムは、マルチキャストトラフィックへの[RFC5949]のいくつかの適応を使用することによって潜在的に達成できます（ただし、基盤となる無線アクセステクノロジーがレイヤー2（L2）トリガーをサポートし、モバイルノードでの追加のサポートが必要な場合にのみ適用されます）。モバイルノードの進行中のマルチキャストサブスクリプションの取得を加速するための一般的な標準ソリューションはありません。
The approach followed by the base solution [RFC6224] to learn of an existing multicast subscription relies on the behavior of the IGMP/ MLD protocols. Both protocols send multicast membership query messages when a new link is up. The response to such a message reports any existing multicast subscriptions by the mobile node. While this is a straightforward approach, the mobile access gateway can incur in a non-negligible delay in receiving the corresponding MLD Report message. This delay is caused by the time needed for the detection of the attachment in the new link and the re-establishment of the data plane after the handover, the radio transfer delays associated with the signaling to the mobile node, and the MLD query response interval time required by this procedure (whose default value is 10 seconds as defined in [RFC2710] and [RFC3810], or between 5 and 10 seconds as considered in the best case wireless link scenario in [RFC6636]).
既存のマルチキャストサブスクリプションを学習するためのベースソリューション[RFC6224]によるアプローチは、IGMP / MLDプロトコルの動作に依存しています。どちらのプロトコルも、新しいリンクがアップしたときにマルチキャストメンバーシップクエリメッセージを送信します。このようなメッセージへの応答は、モバイルノードによる既存のマルチキャストサブスクリプションを報告します。これは簡単なアプローチですが、モバイルアクセスゲートウェイは、対応するMLDレポートメッセージの受信で無視できない遅延を招く可能性があります。この遅延は、新しいリンクでのアタッチメントの検出と、ハンドオーバー後のデータプレーンの再確立に必要な時間、モバイルノードへのシグナリングに関連する無線転送遅延、およびMLDクエリ応答間隔によって発生します。この手順に必要な時間（[RFC2710]と[RFC3810]で定義されているデフォルト値は10秒、または[RFC6636]の最良の無線リンクシナリオで考慮されている5〜10秒）。
This document extends the Proxy Mobile IPv6 signaling protocol defined in the base protocol [RFC5213] by including a new multicast information option to update Proxy Mobile IPv6 entities during the registration and de-registration processes, and new messages to trigger the transfer of multicast information. No extension is required in any of the multicast-related protocols in use (IGMP/MLD or PIM protocols). Furthermore, this specification does not substitute the standard procedures defined in [RFC6224] (e.g., the mobile access gateway continues sending an MLD Query to the entering mobile node as soon as the point-to-point link is set up), but complements them for accelerating the acquisition of the multicast content by the mobile access gateway associated to the new point-of-attachment.
このドキュメントは、ベースプロトコル[RFC5213]で定義されているプロキシモバイルIPv6シグナリングプロトコルを拡張し、登録および登録解除プロセス中にプロキシモバイルIPv6エンティティを更新する新しいマルチキャスト情報オプションと、マルチキャスト情報の転送をトリガーする新しいメッセージを含めます。使用中のマルチキャスト関連プロトコル（IGMP / MLDまたはPIMプロトコル）では、拡張は必要ありません。さらに、この仕様は[RFC6224]で定義されている標準手順に代わるものではありません（たとえば、モバイルアクセスゲートウェイは、ポイントツーポイントリンクが設定されるとすぐに、MLDクエリを入力モバイルノードに送信し続けます）。新しい接続点に関連付けられたモバイルアクセスゲートウェイによるマルチキャストコンテンツの取得を加速します。
This document provides a signaling method internal to the network to speed up the subscription information acquisition by the mobile access gateway, in order to accelerate the multicast delivery to the mobile node after having completed a handover. By doing so, the knowledge by the mobile access gateway of the currently active multicast subscription becomes independent of the underlying radio technology dynamics and relaxes the requirement of a rapid response from the mobile node in processing IGMP/MLD control messages. Issues like radio framing, radio access contention, channel reliability, MN's capabilities (i.e., L2 triggering support), IGMP/MLD timers optimization for wireless environments, etc., will not impact the observed multicast performance during handovers.
このドキュメントは、ハンドオーバーの完了後にモバイルノードへのマルチキャスト配信を加速するために、モバイルアクセスゲートウェイによるサブスクリプション情報取得を高速化するためのネットワーク内部のシグナリング方法を提供します。そうすることで、現在アクティブなマルチキャストサブスクリプションのモバイルアクセスゲートウェイによる知識は、基盤となる無線技術のダイナミクスから独立し、IGMP / MLD制御メッセージの処理におけるモバイルノードからの迅速な応答の要件を緩和します。無線フレーミング、無線アクセス競合、チャネル信頼性、MNの機能（つまり、L2トリガーサポート）、無線環境用のIGMP / MLDタイマーの最適化などの問題は、ハンドオーバー中に観察されるマルチキャストパフォーマンスに影響しません。
The mechanisms described in this document can also be applied to the solutions defined in [RFC7028]. Furthermore, it is also independent of the role played by the mobile access gateway within the multicast network (acting as either MLD proxy or multicast router).
このドキュメントで説明されているメカニズムは、[RFC7028]で定義されているソリューションにも適用できます。さらに、マルチキャストネットワーク（MLDプロキシまたはマルチキャストルーターとして機能）内のモバイルアクセスゲートウェイが果たす役割からも独立しています。
A basic solution for providing support of multicast in a network-based mobility management environment has been specified in [RFC6224] without introducing changes on the original PMIPv6 specification [RFC5213]. The focus of the present document is on improving the efficiency of the base solution regarding handover performance.
ネットワークベースのモビリティ管理環境でマルチキャストのサポートを提供するための基本的なソリューションは、元のPMIPv6仕様[RFC5213]に変更を導入することなく[RFC6224]で指定されています。このドキュメントの焦点は、ハンドオーバーパフォーマンスに関する基本ソリューションの効率を改善することです。
One of the critical aspects of the base solution is the expected delay incurred by the mobile access gateway (where the mobile node is being attached to) to be informed about the ongoing multicast subscription of the entering MN, mainly due to the fact that the mechanisms provided in the base solution relay on the original MLD procedures, with long timing interactions not conceived for mobile environments. Then, the requirements to be covered by a handover optimization solution can be established in the following manner:
基本ソリューションの重要な側面の1つは、モバイルアクセスゲートウェイ（モバイルノードが接続されている場所）が被る予期される遅延であり、主にメカニズムが原因で、MNの進行中のマルチキャストサブスクリプションについて通知されます。元のMLDプロシージャのベースソリューションリレーで提供され、モバイル環境では考えられない長いタイミングの相互作用があります。次に、次の方法で、ハンドオーバー最適化ソリューションがカバーする要件を確立できます。
o The solution MUST be applicable to any kind of MN (that is, not requiring any particular functionality such as, for example, L2 trigger capabilities), in such a way that any type of mobile node in a PMIPv6 domain being served with multicast traffic can benefit from the optimized solution.
o ソリューションは、あらゆる種類のMN（つまり、L2トリガー機能などの特定の機能を必要としない）に適用可能でなければならず、マルチキャストトラフィックでサービスされるPMIPv6ドメイン内の任意のタイプのモバイルノードが、最適化されたソリューションのメリット。
o The solution MUST NOT impact existing multicast protocols.
o ソリューションは、既存のマルチキャストプロトコルに影響を与えてはなりません。
o The solution MUST optimize the handover performance with respect to the performance achieved with the base solution for any kind of handover process (i.e., for proactive and reactive handovers).
o ソリューションは、あらゆる種類のハンドオーバープロセス（つまり、プロアクティブおよびリアクティブハンドオーバー）の基本ソリューションで達成されるパフォーマンスに関して、ハンドオーバーパフォーマンスを最適化する必要があります。
o The solution SHOULD minimize the number and extent of additional support (i.e., capabilities) required in the network, aiming at an easier deployment.
o このソリューションは、ネットワークで必要な追加のサポート（機能など）の数と範囲を最小限に抑えて、展開を容易にすることを目的としています（SHOULD）。
o The solution MUST NOT impact deployments of legacy implementations of [RFC5213] and [RFC6224].
o このソリューションは、[RFC5213]および[RFC6224]のレガシー実装のデプロイメントに影響を与えてはなりません（MUST NOT）。
The present specification addresses all these requirements, as described in the following sections.
この仕様は、次のセクションで説明するように、これらすべての要件に対応しています。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the terminology referring to PMIPv6 components as defined in [RFC5213].
このドキュメントでは、[RFC5213]で定義されているPMIPv6コンポーネントを指す用語を使用しています。
Additionally, the following terms are defined and used in this document.
さらに、このドキュメントでは次の用語が定義され使用されています。
pMAG: The previous MAG or pMAG is the mobile access gateway where the MN was initially registered before a handover event.
pMAG：以前のMAGまたはpMAGは、MNがハンドオーバーイベントの前に最初に登録されたモバイルアクセスゲートウェイです。
nMAG: The new MAG or nMAG is the mobile access gateway where the MN is registered at the end of the handover event.
nMAG：新しいMAGまたはnMAGは、MNがハンドオーバーイベントの最後に登録されるモバイルアクセスゲートウェイです。
Reactive Handover: A reactive handover is a handover event in which the Local Mobility Anchor (LMA) receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG.
リアクティブハンドオーバー：リアクティブハンドオーバーは、ローカルモビリティアンカー（LMA）がpMAGから以前にMN登録解除を受信していなくても、nMAGからモバイルノード登録を受信するハンドオーバーイベントです。
Proactive Handover: A proactive handover is a handover event where the mobile node is firstly de-registered on the local mobility anchor by the pMAG, and later on it is registered by the nMAG as a consequence of changing the point of attachment.
プロアクティブハンドオーバー：プロアクティブハンドオーバーは、モバイルノードが最初にローカルモビリティアンカーでpMAGによって登録解除され、その後、接続ポイントの変更の結果としてnMAGによって登録されるハンドオーバーイベントです。
Multicast Membership Context: In this document, multicast membership context makes reference to the information relative to the currently active multicast subscription of an MN in a handover event that is transferred between the PMIPv6 entities to support the handover optimization.
マルチキャストメンバーシップコンテキスト：このドキュメントでは、マルチキャストメンバーシップコンテキストは、ハンドオーバー最適化をサポートするためにPMIPv6エンティティ間で転送される、ハンドオーバーイベントにおけるMNの現在アクティブなマルチキャストサブスクリプションに関連する情報を参照します。
The local mobility anchor is a key element within the PMIPv6 infrastructure, which traces the mobile node reachability along the PMIPv6 domain. Therefore, the LMA is the best element to keep the MNs' multicast subscription information up-to-date and to forward it to the rest of PMIPv6 entities (i.e., to the mobile access gateways) as needed when MNs move within the domain. The LMA has timely knowledge of the MNs' locations, especially during handover events, and it is therefore able to quickly provide information to the new point of attachment (e.g., by querying the previous one). Figure 1 summarizes the main idea of the optimization.
ローカルモビリティアンカーは、PMIPv6インフラストラクチャ内の重要な要素であり、PMIPv6ドメインに沿ったモバイルノードの到達可能性を追跡します。したがって、LMAは、MNがドメイン内を移動するときに、MNのマルチキャストサブスクリプション情報を最新の状態に保ち、必要に応じてそれを残りのPMIPv6エンティティ（つまり、モバイルアクセスゲートウェイ）に転送するための最良の要素です。 LMAは、特にハンドオーバーイベント中に、MNの場所をタイムリーに認識しているため、新しいアタッチメントポイントに情報をすばやく提供できます（たとえば、以前のアタッチメントポイントをクエリすることにより）。図1は、最適化の主な考え方をまとめたものです。
+------+
| pMAG | |
+------+ |
/ |
/ |
/ |
/ |
-*-*-*-*- / (MN)
( ) / |
( ) +-----+ +------+ |
( Internet )--| LMA |------| nMAG | v
( ) +-----+ +------+
( )
-*-*-*-*- Registration
<--------------
Registration Ack
& Multicast Context
-------------->
Figure 1: High-Level Description of the Solution
図1：ソリューションの概要
The local mobility anchor only obtains the detailed subscription information or multicast context during a handover event. There is no need for continuously informing the LMA about MNs' multicast state while the mobile nodes remain attached to the same mobile access gateway. Such a continuous updating procedure would significantly increase the signaling load within the PMIPv6 domain without a clear benefit. The multicast context is only critical during handovers: neither after nor before. Indicating the active subscription while the handover is ongoing guarantees that such information will be up to date and ready to be transferred to the new MAG where the mobile node has just attached. Therefore, this solution defines the Subscription Information Acquisition through the LMA (SIAL) as the procedure to inform the new MAG about the multicast subscriptions maintained by the entering MN.
ローカルモビリティアンカーは、ハンドオーバーイベント中にのみ詳細なサブスクリプション情報またはマルチキャストコンテキストを取得します。モバイルノードが同じモバイルアクセスゲートウェイに接続されている間、LMAにMNのマルチキャスト状態を継続的に通知する必要はありません。このような継続的な更新手順は、明確な利点なしにPMIPv6ドメイン内のシグナリング負荷を大幅に増加させます。マルチキャストコンテキストは、ハンドオーバー中のみに重要です。ハンドオーバーの進行中にアクティブなサブスクリプションを示すことにより、そのような情報が最新であり、モバイルノードが接続されたばかりの新しいMAGに転送する準備ができていることが保証されます。したがって、このソリューションでは、LMN（SIAL）を介したサブスクリプション情報取得を、参入MNによって維持されているマルチキャストサブスクリプションについて新しいMAGに通知する手順として定義します。
To be able to transfer the multicast subscription information between PMIPv6 entities during a handover, this document extends the PMIPv6 protocol in several ways. First of all, a new mobility option is defined to carry the multicast context of the current subscription. Furthermore, additional messages are defined to manage the interchange of the multicast information among PMIPv6 entities. Finally, some flags are defined to govern the process.
ハンドオーバー中にPMIPv6エンティティ間でマルチキャストサブスクリプション情報を転送できるようにするために、このドキュメントではPMIPv6プロトコルをいくつかの方法で拡張しています。まず、現在のサブスクリプションのマルチキャストコンテキストを伝送するための新しいモビリティオプションが定義されています。さらに、PMIPv6エンティティ間のマルチキャスト情報の交換を管理するために、追加のメッセージが定義されています。最後に、プロセスを管理するためにいくつかのフラグが定義されています。
This section outlines the extensions proposed to the PMIPv6 protocol specified in [RFC5213].
このセクションは[RFC5213]で指定されたPMIPv6プロトコルに提案された拡張を概説します。
A new TLV-encoded mobility option, Active Multicast Subscription option is defined for use with the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages exchanged between a local mobility anchor and a mobility access gateway to transfer the multicast subscription information. This option is used for exchanging the multicast membership context. This information is carried by directly using the format defined in the original MLD specifications. There can be multiple Active Multicast Subscription options present in the message, one for each active subscription maintained by the mobile node when the handover is taking place (i.e., one per multicast membership context).
新しいTLVエンコードモビリティオプションであるアクティブマルチキャストサブスクリプションオプションは、ローカルモビリティアンカーとモビリティアクセスゲートウェイの間で交換されるプロキシバインディングアップデート（PBU）およびプロキシバインディングアクノレッジメント（PBA）メッセージで使用するために定義され、マルチキャストサブスクリプション情報を転送します。このオプションは、マルチキャストメンバーシップコンテキストを交換するために使用されます。この情報は、元のMLD仕様で定義されたフォーマットを直接使用して伝達されます。メッセージには複数のアクティブマルチキャストサブスクリプションオプションが存在する可能性があります。1つは、ハンドオーバーが発生したときにモバイルノードによって維持されるアクティブサブスクリプションごとに1つです（つまり、マルチキャストメンバーシップコンテキストごとに1つ）。
This new option is also used for the same purposes by the new Subscription Response message defined later in this document.
この新しいオプションは、このドキュメントの後半で定義される新しいサブスクリプション応答メッセージでも同じ目的で使用されます。
MLDv2 [RFC3810] is the primary objective for the definition of the option format. MLDv1 [RFC2710] is also considered for backward compatibility.
MLDv2 [RFC3810]は、オプション形式の定義の主要な目的です。 MLDv1 [RFC2710]も下位互換性のために考慮されています。
The format of this new option is as follows:
この新しいオプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MLD Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirement of this option is 8n+1.
このオプションの配置要件は8n + 1です。
Type:
タイプ：
57, which indicates the Active Multicast Subscription IPv6 option.
57。アクティブマルチキャストサブスクリプションIPv6オプションを示します。
Length:
長さ：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
タイプおよび長さフィールドを除く、オクテットでオプションの長さを示す8ビットの符号なし整数。
MLD type:
MLDタイプ：
Field used to identify the IPv6 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original MLD specifications for the Report message. For MLDv2, the MLD Type value is 143, as specified in [RFC3810].
使用中のIPv6マルチキャストメンバーシッププロトコルを識別するために使用されるフィールド、および次のマルチキャストメンバーシップコンテキスト情報フィールドの対応する形式。このフィールドは、レポートメッセージの元のMLD仕様で使用されているタイプコード化をマップします。 MLDv2の場合、MLDタイプの値は[RFC3810]で指定されている143です。
Multicast Membership Context:
マルチキャストメンバーシップコンテキスト：
Multicast subscription information corresponding to a single subscribed multicast address. For MLDv2, the format of this field follows the Multicast Address Record format as defined in [RFC3810].
サブスクライブされた単一のマルチキャストアドレスに対応するマルチキャストサブスクリプション情報。 MLDv2の場合、このフィールドの形式は、[RFC3810]で定義されているマルチキャストアドレスレコード形式に従います。
The following values are adopted when MLDv1 is used.
MLDv1を使用する場合、以下の値が採用されます。
MLD type:
MLDタイプ：
For MLDv1, the MLD Type value is 131, as specified in [RFC2710].
MLDv1の場合、MLCタイプの値は[RFC2710]で指定されている131です。
Multicast Membership Context:
マルチキャストメンバーシップコンテキスト：
For MLDv1, the relevant information for multicast context is simply given, according to [RFC2710], by the multicast address of the subscribed content.
MLDv1の場合、[RFC2710]によれば、マルチキャストコンテキストの関連情報は、サブスクライブされたコンテンツのマルチキャストアドレスによって簡単に提供されます。
In consequence, the Multicast Membership Context is defined as a 4-octet reserved field and the Multicast Address of the subscribed content as in [RFC2710], as shown next.
その結果、マルチキャストメンバーシップコンテキストは、次に示すように、[RFC2710]のように、4オクテットの予約フィールドとサブスクライブされたコンテンツのマルチキャストアドレスとして定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new flag S has been added in both the PBU and PBA message headers to advertise the mobile access gateway and the local mobility anchor capabilities of processing multicast-related signaling for the MN that caused the message.
PBUメッセージヘッダーとPBAメッセージヘッダーの両方に新しいフラグSが追加され、モバイルアクセスゲートウェイと、メッセージの原因となったMNのマルチキャスト関連シグナリングを処理するローカルモビリティアンカー機能をアドバタイズします。
This flag governs the multicast-related signaling between the LMA and the MAG. As a general rule, the value of the flag in the PBA message is a copy of the value received in the PBU message. Specific rules are described in next subsections.
このフラグは、LMAとMAG間のマルチキャスト関連のシグナリングを管理します。原則として、PBAメッセージのフラグの値は、PBUメッセージで受信した値のコピーです。特定のルールについては、次のサブセクションで説明します。
During handover, the entities involved in this process are the nMAG and the LMA. These rules also apply for the initial binding registration process.
ハンドオーバー中、このプロセスに関与するエンティティはnMAGとLMAです。これらのルールは、最初のバインディング登録プロセスにも適用されます。
o PBU message
o PBUメッセージ
* S=0 indicates that the MAG sending the PBU message does not accept multicast-related signaling for the MN being attached. This can be used to discriminate PMIPv6 nodes that are not multicast enabled, for backward compatibility reasons.
* S = 0は、PBUメッセージを送信するMAGが、接続されているMNのマルチキャスト関連シグナリングを受け入れないことを示します。これは、下位互換性の理由から、マルチキャスト対応ではないPMIPv6ノードを区別するために使用できます。
* S=1 indicates that the MAG sending the PBU message accepts multicast-related signaling for the MN being attached. Depending on the type of handover (reactive or proactive) the LMA takes some actions, described later in this document.
* S = 1は、PBUメッセージを送信するMAGが、接続されているMNのマルチキャスト関連シグナリングを受け入れることを示します。ハンドオーバーのタイプ（リアクティブまたはプロアクティブ）に応じて、LMAはこのドキュメントで後述するいくつかのアクションを実行します。
o PBA message
o PBAメッセージ
* If S=0 in the corresponding PBU message, the value of the flag in the PBA message MUST be a copy of the value received in the PBU message (thus S=0), without any further meaning.
* 対応するPBUメッセージでS = 0の場合、PBAメッセージのフラグの値は、PBUメッセージで受信された値のコピー（したがってS = 0）でなければならず、それ以上の意味はありません。
* If S=1 in the corresponding PBU message, two subcases are possible:
* 対応するPBUメッセージでS = 1の場合、2つのサブケースが考えられます。
+ S=1 and Active Multicast Subscription mobility option in the PBA message. When the MN maintains an active multicast session, if the LMA is able to provide the multicast subscription information during registration, the PBA message MUST include the Active Multicast Subscription mobility option. If the LMA is not able to provide such information during registration, the PBA message MUST NOT include the Active Multicast Subscription mobility option. This case is useful to decouple unicast and multicast signaling for an MN being registered at nMAG. A way for obtaining later active multicast-subscription information is described later in this document.
+ PBAメッセージのS = 1およびアクティブマルチキャストサブスクリプションモビリティオプション。 MNがアクティブなマルチキャストセッションを維持しているときに、LMAが登録中にマルチキャストサブスクリプション情報を提供できる場合、PBAメッセージにはアクティブマルチキャストサブスクリプションモビリティオプションを含める必要があります。登録時にLMAがそのような情報を提供できない場合、PBAメッセージにアクティブマルチキャストサブスクリプションモビリティオプションを含めてはなりません（MUST NOT）。このケースは、nMAGに登録されているMNのユニキャストおよびマルチキャストシグナリングを分離するのに役立ちます。後でアクティブなマルチキャストサブスクリプション情報を取得する方法については、このドキュメントの後半で説明します。
+ S=0 in the PBA message if the MN does not maintain an active multicast subscription (note that for backward compatibility reasons, an LMA not supporting multicast related signaling would always send S=0).
+ MNがアクティブなマルチキャストサブスクリプションを維持しない場合、PBAメッセージのS = 0（下位互換性の理由から、マルチキャスト関連のシグナリングをサポートしないLMAは常にS = 0を送信することに注意してください）。
During handover, the entities involved in this process are the pMAG and the LMA. These rules apply for the binding de-registration process.
ハンドオーバー中、このプロセスに関与するエンティティは、pMAGとLMAです。これらのルールは、バインディングの登録解除プロセスに適用されます。
o PBU message
o PBUメッセージ
* S=0 indicates that the MN has no active multicast session (note that for backward compatibility reasons, a pMAG not supporting multicast related signaling would always send S=0).
* S = 0は、MNにアクティブなマルチキャストセッションがないことを示します（下位互換性の理由から、マルチキャスト関連のシグナリングをサポートしないpMAGは常にS = 0を送信することに注意してください）。
* S=1 indicates that the MN has an active multicast session, and the multicast context MUST be transported in the Active Multicast Subscription mobility option.
* S = 1は、MNにアクティブなマルチキャストセッションがあり、マルチキャストコンテキストがアクティブマルチキャストサブスクリプションモビリティオプションでトランスポートされる必要があることを示します。
o PBA message
o PBAメッセージ
* The value of the flag in the PBA message SHOULD be 0, without any further meaning (note that for backward compatibility reasons, an LMA not supporting multicast related signaling would always send S=0).
* PBAメッセージのフラグの値は0であり、それ以上の意味はありません（下位互換性の理由から、マルチキャスト関連のシグナリングをサポートしないLMAは常にS = 0を送信することに注意してください）。
As result of the new defined flag, the PBU message format is updated as follows:
新しく定義されたフラグの結果、PBUメッセージ形式は次のように更新されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As result of the new defined flag, the PBA message format is updated as follows:
新しく定義されたフラグの結果として、PBAメッセージ形式は次のように更新されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new pair of messages is defined for querying entities about the active multicast subscription of the MN when the handover is of reactive type.
ハンドオーバーがリアクティブタイプである場合、MNのアクティブなマルチキャストサブスクリプションについてエンティティにクエリを実行するために、新しいメッセージのペアが定義されます。
These messages are sent using the Mobility Header as defined in [RFC6275].
これらのメッセージは、[RFC6275]で定義されているモビリティヘッダーを使用して送信されます。
The Subscription Query message (value 22) is sent by the LMA towards the pMAG to query it about any existing multicast subscriptions of the MN that is being registered by the nMAG. This message is generated in case the handover is of reactive type.
サブスクリプションクエリメッセージ（値22）は、LMAからpMAGに向けて送信され、nMAGによって登録されているMNの既存のマルチキャストサブスクリプションについてクエリします。このメッセージは、ハンドオーバーがリアクティブタイプの場合に生成されます。
Additionally, this message is sent by the nMAG towards the LMA to query it about the existing multicast subscriptions of the MN when the LMA acknowledges the PBU sent by the nMAG but the multicast context is not provided (namely, when the PBU message has set the flag S to 1, and the PBA message has set the flag S to 1 but the multicast context is missing).
さらに、LMAがnMAGから送信されたPBUを確認したが、マルチキャストコンテキストが提供されなかった場合（つまり、PBUメッセージがフラグSが1になり、PBAメッセージがフラグSを1に設定しましたが、マルチキャストコンテキストがありません）。
The Subscription Query message has the following format.
Subscription Queryメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
シーケンス番号：
The Sequence Number field establishes the order of the messages sent in the Subscription Query / Subscription Response dialogue between the LMA and the MAG for a certain MN. The initial Sequence Number MUST be determined by the entity that creates the message (either LMA or MAG, depending on the scenario), which is responsible for managing this counter.
シーケンス番号フィールドは、特定のMNのLMAとMAGの間のサブスクリプションクエリ/サブスクリプション応答ダイアログで送信されるメッセージの順序を確立します。最初のシーケンス番号は、メッセージを作成するエンティティ（シナリオに応じてLMAまたはMAGのいずれか）が決定する必要があります。このエンティティは、このカウンターの管理を担当します。
This Sequence Number comparison MUST be performed modulo 2**8, i.e., the number is a free-running counter represented modulo 256. A Sequence Number in a received Subscription Query message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 128 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 143 through 255, would be considered less than or equal.
このシーケンス番号の比較は、2 ** 8を法として実行する必要があります。つまり、数値は256を法とするフリーランニングカウンターです。受信したサブスクリプションクエリメッセージのシーケンス番号は、その値が最後の受信した番号以下であると見なされます。最後に受信した数値とその前の128個の値の範囲内にあります。たとえば、最後に受信したシーケンス番号が15の場合、シーケンス番号0〜15、および143〜255のメッセージは、以下であると見なされます。
Reserved:
予約済み：
This field is unused for now. The value MUST be initialized to 0.
このフィールドは現在使用されていません。値は0に初期化する必要があります。
Mobility options:
モビリティオプション：
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following:
このメッセージには、TLVでエンコードされた1つ以上のモビリティオプションが含まれます。このメッセージの有効なモビリティオプションは次のとおりです。
* Mobile Node Identifier option [RFC4283] (mandatory).
* モバイルノード識別子オプション[RFC4283]（必須）。
* Home Network Prefix option [RFC5213] (optional).
* ホームネットワークプレフィックスオプション[RFC5213]（オプション）。
There can be one or more instances of the Home Network Prefix option, but only one instance of the Mobile Node Identifier option.
ホームネットワークプレフィックスオプションのインスタンスは1つ以上存在できますが、モバイルノード識別子オプションのインスタンスは1つだけです。
The Subscription Response message (value 23) is sent by the pMAG towards the LMA, or by the LMA towards the nMAG, to answer a previously received Subscription Query message, as described above.
サブスクリプション応答メッセージ（値23）は、pMAGからLMAに向けて、またはLMAからnMAGに向けて送信され、前述のように、以前に受信したサブスクリプションクエリメッセージに応答します。
The Subscription Response message has the following format.
Subscription Responseメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
シーケンス番号：
The value of the Sequence Number field in the Subscriber Response message MUST be a copy of the Sequence Number received in the Subscription Query message.
サブスクライバー応答メッセージのシーケンス番号フィールドの値は、サブスクリプションクエリメッセージで受信したシーケンス番号のコピーである必要があります。
Multicast Information (I):
マルチキャスト情報（I）：
The multicast Information flag I specifies whether or not there is multicast subscription information available for the MN. The meaning is the following:
マルチキャスト情報フラグIは、MNで利用可能なマルチキャストサブスクリプション情報があるかどうかを指定します。意味は次のとおりです。
I=0: there is no multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message.
I = 0：このメッセージのモバイルノード識別子オプションで識別されるMNで利用可能なマルチキャストサブスクリプション情報はありません。
I=1: there is multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message. The multicast subscription information MUST be carried on one or more instances of the Active Multicast Subscription option in this message (one instance for each active subscription).
I = 1：このメッセージのモバイルノード識別子オプションで識別されるMNで利用可能なマルチキャストサブスクリプション情報があります。マルチキャストサブスクリプション情報は、このメッセージのアクティブマルチキャストサブスクリプションオプションの1つまたは複数のインスタンスで伝送する必要があります（アクティブなサブスクリプションごとに1つのインスタンス）。
Reserved:
予約済み：
This field is unused for now. The value MUST be initialized to 0.
このフィールドは現在使用されていません。値は0に初期化する必要があります。
Mobility options:
モビリティオプション：
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following:
このメッセージには、TLVでエンコードされた1つ以上のモビリティオプションが含まれます。このメッセージの有効なモビリティオプションは次のとおりです。
* Mobile Node Identifier option [RFC4283] (mandatory).
* モバイルノード識別子オプション[RFC4283]（必須）。
* Active Multicast Subscription option (mandatory) only when flag I=1; it MUST NOT be present in any other case.
* フラグI = 1の場合にのみアクティブマルチキャストサブスクリプションオプション（必須）。それ以外の場合には存在してはなりません。
* Home Network Prefix option [RFC5213] (optional).
* ホームネットワークプレフィックスオプション[RFC5213]（オプション）。
There can be one or more instances of the Home Network Prefix option (in all cases) and the Active Multicast Subscription option (only when I=1), but only one instance of the Mobile Node Identifier option.
ホームネットワークプレフィックスオプション（すべての場合）およびアクティブマルチキャストサブスクリプションオプション（I = 1の場合のみ）のインスタンスは1つ以上存在できますが、モバイルノード識別子オプションのインスタンスは1つだけです。
A new timer named "PBA timer" is used in the LMA to define the maximum waiting time before the PBA message is sent to the nMAG in case the multicast subscription information relative to the MN is not yet available. The aim of this timer is to prevent potential large delays in the forwarding of unicast traffic towards the MN being registered at the nMAG. This timer allows decoupling the unicast signaling from the multicast one in the SIAL solution.
「PBAタイマー」という新しいタイマーはLMNで使用され、MNに関するマルチキャストサブスクリプション情報がまだ利用できない場合に、PBAメッセージがnMAGに送信されるまでの最大待機時間を定義します。このタイマーの目的は、nMAGに登録されているMNへのユニキャストトラフィックの転送で大きな遅延が発生する可能性を防ぐことです。このタイマーにより、SIALソリューションでマルチキャストユニキャストシグナリングからユニキャストシグナリングを分離できます。
This timer SHOULD be upper bounded by the constant defined in [RFC6275] INITIAL_BINDACK_TIMEOUT, whose default value is 1 s. This constant sets the time when the nMAG will retry the MN registration by sending again the PBU message. The "PBA timer" has to be set to a value that ensures that the nMAG does not enter the retry mode. Operational experience is needed on how to set up the PBA timer, and therefore it is RECOMMENDED to set the "PBA timer" to zero, except for experimental purposes.
このタイマーは、[RFC6275] INITIAL_BINDACK_TIMEOUTで定義されている定数によって上限が設定されている必要があります（SHOULD）。デフォルト値は1秒です。この定数は、nMAGがPBUメッセージを再送信してMN登録を再試行する時間を設定します。 「PBAタイマー」は、nMAGがリトライモードに入らないようにする値に設定する必要があります。 PBAタイマーの設定方法には運用経験が必要です。したがって、実験的な目的を除いて、「PBAタイマー」をゼロに設定することをお勧めします。
As the MN moves from one access gateway to another, the mobility-related signaling due to the handover event is carried out independently by the pMAG and the nMAG. That signaling process is not synchronized; thus, two scenarios need to be considered depending on the order in which the LMA receives notification of the MN registration and de-registration in the nMAG and the pMAG, respectively.
MNがあるアクセスゲートウェイから別のアクセスゲートウェイに移動すると、ハンドオーバーイベントに起因するモビリティ関連のシグナリングは、pMAGとnMAGによって独立して実行されます。そのシグナリングプロセスは同期されません。したがって、LMAがnMAGおよびpMAGでそれぞれMN登録および登録解除の通知を受信する順序に応じて、2つのシナリオを検討する必要があります。
In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG as a consequence of changing the point of attachment.
プロアクティブな場合、MNは最初にpMAGによって登録解除され、その後、接続ポイントの変更の結果としてnMAGによって登録されます。
Only for those MNs that maintain an active multicast subscription, the pMAG includes the Active Multicast Subscription mobility option carrying the multicast context of the MN at that moment as part of the PBU message (with flag S set to 1).
アクティブなマルチキャストサブスクリプションを維持するMNの場合のみ、pMAGには、その時点でのMNのマルチキャストコンテキストをPBUメッセージの一部として（フラグSを1に設定して）運ぶアクティブマルチキャストサブスクリプションモビリティオプションが含まれています。
The local mobility anchor stores that information in the corresponding binding cache. If later on the MN attaches to an nMAG, this information is sent (using the same TLV option) to the nMAG as part of the PBA confirmation of the registration process (if the PBU message sent by the nMAG has the flag S set to 1). On the other hand, if no further registration happens, the multicast information is removed together with the rest of binding database for that MN.
ローカルモビリティアンカーは、その情報を対応するバインディングキャッシュに格納します。後でMNがnMAGに接続する場合、この情報は（同じTLVオプションを使用して）登録プロセスのPBA確認の一部として（同じTLVオプションを使用して）nMAGに送信されます（nMAGによって送信されたPBUメッセージのフラグSが1に設定されている場合） ）。一方、それ以上の登録が行われない場合、マルチキャスト情報はそのMNの残りのバインディングデータベースとともに削除されます。
After receiving the multicast context, the nMAG can subscribe to the multicast flow(s) on behalf of the MN in case there is no other MN already receiving it at the nMAG. The multicast status can also be set in advance for the point-to-point link towards the MN.
マルチキャストコンテキストを受信した後、nMAGですでに受信している他のMNがない場合、nMAGはMNに代わってマルチキャストフローにサブスクライブできます。マルチキャストステータスは、MNへのポイントツーポイントリンクに対して事前に設定することもできます。
Note that the SIAL solution described here does not prevent benefiting from extended support in the mobile node / network that facilitates the proactive mode operation of the solution, e.g., based on L2 capabilities.
ここで説明するSIALソリューションは、モバイルノード/ネットワークでの拡張サポートのメリットを妨げるものではないことに注意してください。たとえば、L2機能に基づいて、ソリューションのプロアクティブモードの運用を容易にします。
Figure 2 summarizes this process.
図2は、このプロセスを要約したものです。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| |==Bi-Dir Tunnel=| |
| Multicast Data | | |
|<---------------| | |
| | | |
1) MN Detached | | |
| MN Detached Event | |
| | | |
| |Ext'd DeReg PBU | |
2) | |--------------->| |
| | | |
3) | | Accept PBU |
| |(Multicast Subscription info stored)
| | | |
| | PBA | |
4) | |<---------------| |
| | | |
5) MN Attached | | |
| | | MN Attached Event
| | | |
| | | PBU |
6) | | |<---------------|
| | | |
| | | Ext'd PBA |
7) | | |--------------->|
| | | |
8) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Multicast Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 2: Proactive Handover
図2：プロアクティブなハンドオーバー
The message flow is as follows:
メッセージの流れは次のとおりです。
1. A registered MN is receiving a multicast content that has been previously subscribed to by sending a standard MLD report from the mobile node to the currently serving mobile access gateway, pMAG. The pMAG keeps the multicast state of the point-to-point link with the MN.
1. 登録されたMNは、標準のMLDレポートをモバイルノードから現在サービスを提供しているモバイルアクセスゲートウェイであるpMAGに送信することにより、以前にサブスクライブされたマルチキャストコンテンツを受信しています。 pMAGは、MNとのポイントツーポイントリンクのマルチキャスト状態を維持します。
2. The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. As a consequence, pMAG determines a detachment event corresponding to this mobile node, and updates the attachment status of this MN to the local mobility anchor by sending an extended Proxy Binding Update message, including the Active Multicast Subscription, which contains the multicast context of the active multicast subscriptions in the moment of handover.
2. ＭＮは、新しいＭＡＧによって制御される無線アクセスを介して（例えば、より良い無線状態のために）ハンドオーバープロセスを開始する。結果として、pMAGはこのモバイルノードに対応するデタッチイベントを決定し、アクティブマルチキャストサブスクリプションを含む拡張プロキシバインディング更新メッセージを送信することにより、このMNのローカルモビリティアンカーへの接続ステータスを更新します。ハンドオーバー時にアクティブなマルチキャストサブスクリプション。
3. The LMA processes the PBU message. Additionally, the LMA stores in the binding cache the information regarding the ongoing multicast subscription(s) when the detachment is initiated. This information is kept until a new registration of the MN is completed by another MAG, or until the binding cache expiration, according to [RFC5213].
3. LMAはPBUメッセージを処理します。さらに、デタッチが開始されると、LMAはバインディングキャッシュに進行中のマルチキャストサブスクリプションに関する情報を格納します。この情報は、[RFC5213]に従って、MNの新しい登録が別のMAGによって完了するまで、またはバインディングキャッシュの有効期限まで保持されます。
4. The local mobility anchor acknowledges to the pMAG the previous PBU message.
4. ローカルモビリティアンカーは、前のPBUメッセージをpMAGに確認します。
5. As a result of the handover process, the mobile node attaches to another mobility access gateway, called nMAG.
5. ハンドオーバープロセスの結果として、モバイルノードはnMAGと呼ばれる別のモビリティアクセスゲートウェイに接続します。
6. The nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor.
6. nMAGは、PBUメッセージ（フラグSを1に設定）をローカルモビリティアンカーに送信して、登録プロセスをトリガーします。
7. After the analysis of the PBU message, the LMA sends an extended PBA including the Active Multicast Subscription option, which contains the multicast context of the active subscriptions in the moment of handover.
7. PBUメッセージの分析後、LMAは、アクティブなマルチキャストサブスクリプションオプションを含む拡張PBAを送信します。これには、ハンドオーバーの瞬間のアクティブなサブスクリプションのマルチキャストコンテキストが含まれます。
8. The nMAG processes the PBA message following all the standard procedures described in [RFC5213]. Additionally, with the new information relative to multicast subscription, the nMAG sets up the multicast status of the point-to-point link between the nMAG and the MN, and joins the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content due to a previous subscription ordered by another MN attached to it. From that instant, the multicast content is served to the MN.
8. nMAGは、[RFC5213]で説明されているすべての標準手順に従ってPBAメッセージを処理します。さらに、マルチキャストサブスクリプションに関する新しい情報を使用して、nMAGはnMAGとMN間のポイントツーポイントリンクのマルチキャストステータスを設定し、（S、G）で識別されるコンテンツにMNの代わりに参加しますアタッチされている別のMNによって注文された以前のサブスクリプションが原因で、nMAGがそのようなコンテンツをまだ受信していない場合。その瞬間から、マルチキャストコンテンツはMNに提供されます。
In the reactive case, the LMA receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG.
事後対応の場合、LMAは、以前にpMAGからMN登録解除を受信していなくても、nMAGからモバイルノード登録を受信します。
As the nMAG is not aware of any active multicast subscription of the mobile node, the nMAG starts a conventional registration process, by sending a normal PBU message (with flag S set to 1) towards the local mobility anchor.
nMAGはモバイルノードのアクティブなマルチキャストサブスクリプションを認識していないため、nMAGは通常のPBUメッセージ（フラグSを1に設定）をローカルモビリティアンカーに向けて送信することで、従来の登録プロセスを開始します。
In the reactive handover case, after MN registration at the nMAG, the local mobility anchor SHOULD generically query the pMAG to retrieve the multicast context of the ongoing multicast subscription of the mobile node. However, the LMA may know in advance if the pMAG supports multicast signaling based on the value of the flag S received during the MN registration in pMAG. Specifically, in case the pMAG does not support multicast signaling (e.g., the S flag value received from pMAG at the time of registering the mobile node was 0), the LMA MAY decide not to query pMAG even in the case of receiving an nMAG indication of supporting multicast signaling.
リアクティブハンドオーバーの場合、nMAGでのMN登録後、ローカルモビリティアンカーは一般にpMAGにクエリを送信して、モバイルノードの進行中のマルチキャストサブスクリプションのマルチキャストコンテキストを取得する必要があります。しかしながら、ＬＭＡは、ｐＭＡＧにおけるＭＮ登録中に受信されたフラグＳの値に基づいてｐＭＡＧがマルチキャストシグナリングをサポートするかどうかを事前に知ることができる。具体的には、pMAGがマルチキャストシグナリングをサポートしていない場合（たとえば、モバイルノードの登録時にpMAGから受信したSフラグ値が0であった場合）、LMAは、nMAG通知を受信した場合でもpMAGを照会しないことを決定できます（MAY）。マルチキャストシグナリングのサポート。
Once the multicast subscription information is retrieved from the pMAG, the LMA encapsulates it in the PBA message by using the TLV option Active Multicast Subscription and forwards the PBA message to the nMAG. Then, the nMAG can subscribe the multicast flow on behalf of the MN, if there is no other mobile node receiving it already at the nMAG. The multicast status can be also set in advance for the point-to-point link towards the mobile node.
マルチキャストサブスクリプション情報がpMAGから取得されると、LMAはTLVオプションのActive Multicast Subscriptionを使用してPBAメッセージにカプセル化し、PBAメッセージをnMAGに転送します。次に、nMAGでマルチキャストフローをすでに受信しているモバイルノードが他にない場合、nMAGはMNの代わりにマルチキャストフローをサブスクライブできます。マルチキャストステータスは、モバイルノードへのポイントツーポイントリンクに対して事前に設定することもできます。
Figure 3 summarizes this process.
図3は、このプロセスを要約したものです。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| | | MN Attached Event
| | | |
| | | PBU |
1) | | |<---------------|
| | | |
| | Subscr Query | |
2) | |<---------------| |
| | | |
| | Subscr Resp | |
3) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Ext'd PBA |
4) | | |--------------->|
| | | |
5) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | (S,G) Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 3: Reactive Handover
図3：リアクティブハンドオーバー
We next take as starting point the situation where an MN is attached to the pMAG, being multicast enabled and maintaining an active multicast subscription at this moment.
次に、MNがpMAGに接続され、マルチキャストが有効になり、現時点でアクティブなマルチキャストサブスクリプションを維持している状況を開始点とします。
The sequence of messages for the handover of the mobile node is the following (as depicted in Figure 3):
モバイルノードのハンドオーバーに関するメッセージのシーケンスは次のとおりです（図3を参照）。
1. At a certain time, the MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. Then, the nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process.
１．ある時間に、ＭＮは、（例えば、より良い無線状態のために）新しいＭＡＧによって制御される無線アクセスを介してハンドオーバープロセスを開始する。次に、nMAGはPBUメッセージ（フラグSを1に設定）をローカルモビリティアンカーに送信して、登録プロセスをトリガーします。これは反応的なケースであるため、pMAGは分離プロセスを認識しません。
2. Prior to acknowledging the received PBU message, the LMA queries the pMAG about if there is any active multicast subscription for the MN, by sending a Subscription Query message.
2. 受信したPBUメッセージを確認する前に、LMAはサブスクリプションクエリメッセージを送信することにより、MNにアクティブなマルチキャストサブスクリプションがあるかどうかについてpMAGにクエリします。
3. The pMAG answers the LMA with a Subscription Response message including the multicast context of the existing subscriptions.
3. pMAGは、既存のサブスクリプションのマルチキャストコンテキストを含むサブスクリプション応答メッセージでLMAに応答します。
4. After processing the pMAG answer, the LMA acknowledges (with flag S set to 1) the PBU message, including the multicast subscription information within the Active Multicast Subscription option. The nMAG then processes the extended PBA message.
4. pMAGの回答を処理した後、LMAはアクティブマルチキャストサブスクリプションオプション内のマルチキャストサブスクリプション情報を含むPBUメッセージを確認します（フラグSを1に設定）。次にnMAGは拡張PBAメッセージを処理します。
5. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up between the nMAG and the local mobility anchor if it has not been established before by another MN connection. At this moment, the multicast content can be served to the MN. The unicast traffic for the mobile node can be forwarded as well.
5. nMAGはPBAメッセージを処理し、nMAGとモバイルノード間のポイントツーポイントリンクのマルチキャストステータスを設定し、MNに代わって（S、G）で識別されるコンテンツに参加します。 nMAGがそのようなコンテンツをまだ受け取っていない場合。双方向トンネルは、別のMN接続によって以前に確立されていない場合、nMAGとローカルモビリティアンカーの間にセットアップされます。この時点で、マルチキャストコンテンツをMNに提供できます。モバイルノードのユニキャストトラフィックも転送できます。
A handover event is managed independently by the pMAG and nMAG. It is not a synchronized process. In a reactive handover, the LMA receives a registration PBU from nMAG before a de-registration PBU is received from pMAG.
ハンドオーバーイベントは、pMAGとnMAGによって独立して管理されます。同期プロセスではありません。リアクティブハンドオーバーでは、LMAは、登録解除PBUがpMAGから受信される前に、nMAGから登録PBUを受信します。
In the message flows detailed above, it could be the case that the LMA receives a de-registration PBU from pMAG just after sending the Subscription Query message, but before receiving the Subscription Response message. That de-registration PBU message from pMAG carries the multicast subscription information required to assist the MN in the handover, so such valuable information SHOULD be kept by the LMA. Furthermore, it is possible that once the Subscription Query message arrives to pMAG, the pMAG could have already removed the multicast related information for the MN.
上記のメッセージフローでは、LMAがサブスクリプションクエリメッセージを送信した直後、サブスクリプション応答メッセージを受信する前に、pMAGから登録解除PBUを受信する場合があります。 pMAGからの登録解除PBUメッセージは、MNをハンドオーバーで支援するために必要なマルチキャストサブスクリプション情報を運ぶため、LMAはそのような貴重な情報を保持する必要があります。さらに、サブスクリプションクエリメッセージがpMAGに到着すると、pMAGはすでにMNのマルチキャスト関連情報を削除している可能性があります。
In order to avoid losing the multicast subscription information sent in the de-registration PBU message, the local mobility anchor SHOULD store it, and SHOULD include it in the PBA message towards the nMAG in case the Subscription Response message from the pMAG does not contain multicast subscription information for the mobile node.
登録解除PBUメッセージで送信されたマルチキャストサブスクリプション情報が失われないようにするために、ローカルモビリティアンカーはそれを格納する必要があり（SHOULD）、pMAGからのサブスクリプション応答メッセージにマルチキャストが含まれていない場合に、nMAGへのPBAメッセージに含める必要があります（SHOULD）。モバイルノードのサブスクリプション情報。
5.3. Prevention of Large Delays of the Binding Acknowledgement for Unicast Traffic
5.3. ユニキャストトラフィックのバインディング確認の大幅な遅延の防止
According to the message sequences described for the reactive handover case, in case the LMA has to request the multicast subscription information from the pMAG, the binding request sent by the nMAG is maintained on-hold until the local mobility anchor receives, processes and includes the multicast subscription information into the extended PBA message. As a consequence, the unicast traffic may then suffer an extra delay motivated by the multicast-related signaling. During that time, the unicast traffic with destination the MN being registered by the nMAG MAY be buffered by the local mobility anchor.
LMAがpMAGからマルチキャストサブスクリプション情報を要求する必要がある場合、リアクティブハンドオーバーの場合について説明したメッセージシーケンスによれば、nMAGによって送信されたバインディング要求は、ローカルモビリティアンカーが受信して処理し、含めるまで保留されます。サブスクリプション情報を拡張PBAメッセージにマルチキャストします。その結果、ユニキャストトラフィックは、マルチキャスト関連のシグナリングによって動機付けされた余分な遅延を受ける可能性があります。その間、nMAGによって登録されているMNを宛先とするユニキャストトラフィックは、ローカルモビリティアンカーによってバッファリングされる場合があります。
In order to avoid any potential large delay in the forwarding of unicast traffic arriving at the LMA towards the MN, a mechanism SHOULD be implemented to decouple multicast from unicast traffic reception by the MN. Figure 4 shows this mechanism.
MNに向けてLMAに到着するユニキャストトラフィックの転送で大きな遅延が発生する可能性を回避するために、MNによるユニキャストトラフィックの受信からマルチキャストを切り離すメカニズムを実装する必要があります（SHOULD）。図4は、このメカニズムを示しています。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
1) | |==Bi-Dir Tunnel=| |
| unicast data | | |
|<-v-v-v-v-v-v-v-| | |
| | | |
| Multicast Data | | |
|<---------------| | |
| | | MN Attached Event
| | | PBU |
2) | | |<---------------|
| | Subscr Query | |
3) | |<---------------| |
| | | |
4) | | <PBA timer starts> |
| | /// |
| | /// |
5) | | <PBA timer expires> |
| | | |
| | | Ext'd PBA |
| | |--------------->|
| | | |
| | | Accept PBA
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Unicast Data |
|<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-|
| | | |
| | | Subscr Query |
6) | | |<---------------|
| | Subscr Resp | |
7) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Subscr Resp |
8) | | |--------------->|
| | | |
| | | Multicast Group join
| | | and P-t-P status setup
| | Multicast Data | |
|<-------------------------------------------------|
| | | |
Figure 4: Decoupling of Unicast and Multicast Signaling
図4：ユニキャストシグナリングとマルチキャストシグナリングの分離
The sequence of messages is the following:
メッセージのシーケンスは次のとおりです。
1. An MN is attached to the pMAG. The MN is a multicast-enabled node, and it is receiving both unicast and multicast traffic simultaneously.
1. MNはpMAGに接続されます。 MNはマルチキャスト対応ノードであり、ユニキャストトラフィックとマルチキャストトラフィックの両方を同時に受信しています。
2. Some time later, The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new mobile access gateway. Then, the nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process.
2. しばらくして、MNは、新しいモバイルアクセスゲートウェイによって制御される無線アクセスを介して、（たとえば、無線状態が良好なため）ハンドオーバープロセスを開始します。次に、nMAGはPBUメッセージ（フラグSを1に設定）をローカルモビリティアンカーに送信して、登録プロセスをトリガーします。これは反応的なケースであるため、pMAGは分離プロセスを認識しません。
3. Prior to acknowledging the received PBU message, the LMA decides to query the pMAG about if there is any active multicast subscription for the mobile node, by sending a Subscription Query message.
3. 受信したPBUメッセージを確認する前に、LMAは、サブスクリプションクエリメッセージを送信して、モバイルノードにアクティブなマルチキャストサブスクリプションがあるかどうかについてpMAGにクエリすることを決定します。
4. Immediately after sending the Subscription Query message, the LMA starts the timer "PBA timer", which determines the maximum waiting time before the PBA is sent to avoid any potential large delay in the forwarding of unicast traffic towards the MN.
4. サブスクリプションクエリメッセージを送信した直後に、LMAはタイマー「PBAタイマー」を開始します。これにより、PBAが送信されるまでの最大待機時間が決まり、MNへのユニキャストトラフィックの転送で大きな遅延が発生する可能性がなくなります。
5. In case the "PBA timer" expires, the LMA acknowledges the PBU message, by sending the PBA message with flag S=1, without the multicast context information. The nMAG then processes the extended PBA message. Such acknowledgement allows the mobile node to receive the unicast traffic from that time on. The bidirectional tunnel is also set up between the nMAG and the LMA if it has not been established before.
5. 「PBAタイマー」の期限が切れた場合、LMAは、マルチキャストコンテキスト情報なしで、フラグS = 1のPBAメッセージを送信することにより、PBUメッセージを確認します。次にnMAGは拡張PBAメッセージを処理します。このような確認応答により、モバイルノードはその時点からユニキャストトラフィックを受信できます。 nMAGとLMAの間にまだ確立されていない場合は、双方向トンネルも設定されます。
6. In parallel, the nMAG sends a Subscription Query message to the LMA requesting the multicast-subscription details yet unknown for the mobile node.
6. 並行して、nMAGは、サブスクリプションクエリメッセージをLMAに送信して、マルチキャストサブスクリプションの詳細を要求しますが、モバイルノードには不明です。
7. The pMAG answers the Subscription Query message originally sent by the local mobility anchor, including the multicast context.
7. pMAGは、ローカルのモビリティアンカーによって最初に送信されたサブスクリプションクエリメッセージに、マルチキャストコンテキストを含めて応答します。
8. After processing the pMAG answer, the LMA sends a Subscription Response message to the nMAG, including the multicast subscription information within the Active Multicast Subscription option. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up between the nMAG and the LMA if it has not been established before. At this moment, the multicast content can also be served to the mobile node.
8. pMAGの回答を処理した後、LMAはアクティブマルチキャストサブスクリプションオプション内のマルチキャストサブスクリプション情報を含むサブスクリプション応答メッセージをnMAGに送信します。 nMAGはPBAメッセージを処理し、nMAGとモバイルノード間のポイントツーポイントリンクのマルチキャストステータスを設定し、MNに代わって（S、G）で識別されるコンテンツに参加します。 nMAGがそのようなコンテンツをまだ受け取っていない場合。 nMAGとLMAの間にまだ確立されていない場合は、双方向トンネルも設定されます。この時点で、マルチキャストコンテンツをモバイルノードに提供することもできます。
The "PBA timer" in the LMA determines if the signaling flow follows Figure 3 or Figure 4 in a reactive handover. A value of 0 for the "PBA timer" guarantees that the unicast traffic does not suffer any delay (according to the Figure 4 signaling flow), because the PBA is sent immediately after the LMA receives the PBU from the nMAG. A small non-zero "PBA timer" value MAY be used to reduce the signaling load in the LMA and MAGs (as shown in the signaling flow of Figure 3 if the Subscription Response message from the pMAG is received at the LMA before the "PBA timer" expires), but this has to be carefully balanced against added delay to the unicast traffic.
LMAの「PBAタイマー」は、リアクティブハンドオーバーでシグナリングフローが図3と図4のどちらに従うかを決定します。 「PBAタイマー」の値が0の場合、LMAがnMAGからPBUを受信した直後にPBAが送信されるため、ユニキャストトラフィックが遅延しないことが保証されます（図4のシグナリングフローによる）。ゼロ以外の小さな「PBAタイマー」値を使用して、LMAおよびMAGのシグナリング負荷を減らすことができます（図3のシグナリングフローに示すように、「PBAの前にpMAGからのサブスクリプション応答メッセージがLMAで受信された場合タイマーが期限切れになります）。ただし、これは、ユニキャストトラフィックに追加される遅延に対して慎重にバランスを取る必要があります。
IPv4-based mobile nodes (being either IPv4/IPv6 dual-stack or IPv4-only enabled) can be supported in a PMIPv6 domain according to [RFC5844]. When referring to multicast membership protocols and procedures, this means that IGMP functionality has to be also supported between the PMIPv6 entities, as documented in [RFC6224], to allow the mobile access gateway requesting multicast contents to the mobility anchor on behalf of the mobile nodes attached to it.
IPv4ベースのモバイルノード（IPv4 / IPv6デュアルスタックまたはIPv4のみが有効）は、[RFC5844]に従ってPMIPv6ドメインでサポートできます。マルチキャストメンバーシップのプロトコルと手順に言及するとき、これは、[RFC6224]に記載されているように、モバイルノードに代わってモバイルアクセスゲートウェイがモビリティアンカーにマルチキャストコンテンツを要求できるように、PMIPv6エンティティ間でもIGMP機能をサポートする必要があることを意味します。それに添付されています。
The Active Multicast Subscription option defined in Section 4.1, which transports the multicast membership context of the mobile node during handover, should be compatible with IGMP-based formats. Specifically, the option format is defined for IPv4-based MNs as follows:
セクション4.1で定義されているアクティブマルチキャストサブスクリプションオプションは、ハンドオーバー中にモバイルノードのマルチキャストメンバーシップコンテキストを転送し、IGMPベースのフォーマットと互換性がある必要があります。具体的には、オプション形式はIPv4ベースのMNに対して次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IGMP Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGMPv3 is the primary objective for the definition of the option format. IGMPv1 and IGMPv2 are also considered for backward compatibility. The alignment requirement of this option is 4n+1.
IGMPv3は、オプション形式の定義の主要な目的です。 IGMPv1とIGMPv2も下位互換性のために考慮されています。このオプションの配置要件は4n + 1です。
Type:
タイプ：
56, which indicates the Active Multicast Subscription IPv4 option.
56。アクティブマルチキャストサブスクリプションIPv4オプションを示します。
Length:
長さ：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
タイプおよび長さフィールドを除く、オクテットでオプションの長さを示す8ビットの符号なし整数。
IGMP type:
IGMPタイプ：
Field used to identify the IPv4 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original IGMP specifications for the Report message.
使用中のIPv4マルチキャストメンバーシッププロトコルを識別するために使用されるフィールド、および次のマルチキャストメンバーシップコンテキスト情報フィールドの対応する形式。このフィールドは、レポートメッセージの元のIGMP仕様で使用されているタイプコード化をマップします。
0x12: Use of IGMPv1 multicast membership protocol.
0x12：IGMPv1マルチキャストメンバーシッププロトコルの使用。
0x16: Use of IGMPv2 multicast membership protocol.
0x16：IGMPv2マルチキャストメンバーシッププロトコルの使用。
0x22: Use of IGMPv3 multicast membership protocol.
0x22：IGMPv3マルチキャストメンバーシッププロトコルの使用。
Multicast Membership Context:
マルチキャストメンバーシップコンテキスト：
Multicast subscription information corresponding to a single subscribed multicast address. Depending on the IGMP version being used by the mobile node, the format of the Multicast Membership Context could follow the following formats:
サブスクライブされた単一のマルチキャストアドレスに対応するマルチキャストサブスクリプション情報。モバイルノードで使用されているIGMPバージョンに応じて、マルチキャストメンバーシップコンテキストのフォーマットは次のフォーマットに従うことができます。
* For IGMPv1, the Group Address format as defined in [RFC1112].
* IGMPv1の場合、[RFC1112]で定義されているグループアドレス形式。
* For IGMPv2, the Group Address format as defined in [RFC2236].
* IGMPv2の場合、[RFC2236]で定義されているグループアドレス形式。
* For IGMPv3, the Group Record format as defined in [RFC3376].
* IGMPv3の場合、[RFC3376]で定義されているグループレコード形式。
Generic signaling procedures for the support of IPv4 in PMIPv6 domains have been already specified in [RFC5844]. In order to prevent errors while signaling the ongoing multicast subscription for a mobile node during the handover process, the following extensions have to be considered in SIAL.
PMIPv6ドメインでIPv4をサポートするための一般的なシグナリング手順は、[RFC5844]ですでに指定されています。ハンドオーバープロセス中にモバイルノードの進行中のマルチキャストサブスクリプションを通知する際のエラーを防ぐために、SIALでは次の拡張を考慮する必要があります。
o If the registration/de-registration process in a handover is for an IPv6-only MN, and the type of the received Active Multicast Subscription option indicates IPv4, then the multicast membership context received MUST be silently discarded.
o ハンドオーバーでの登録/登録解除プロセスがIPv6のみのMN用であり、受信したアクティブマルチキャストサブスクリプションオプションのタイプがIPv4を示している場合、受信したマルチキャストメンバーシップコンテキストは通知なく破棄されなければなりません（MUST）。
o If the registration/de-registration process in a handover is for an IPv4-only MN, and the type of the received Active Multicast Subscription option indicates IPv6, then the multicast membership context received MUST be silently discarded.
o ハンドオーバーでの登録/登録解除プロセスがIPv4のみのMN用であり、受信したアクティブマルチキャストサブスクリプションオプションのタイプがIPv6を示している場合、受信したマルチキャストメンバーシップコンテキストは通知なく破棄されなければなりません（MUST）。
o If the registration/de-registration process in a handover is for a dual stack MN, the received Active Multicast Subscription option (or options) MUST be accepted independently of the type indication.
o ハンドオーバーでの登録/登録解除プロセスがデュアルスタックMN用である場合、受信したアクティブマルチキャストサブスクリプションオプション（またはオプション）は、タイプの表示とは無関係に受け入れられる必要があります。
Additionally, since the multicast membership information is temporally stored in the mobility anchor under some circumstances (e.g., proactive handover), the binding cache entry for an IPv4-based multicast-enabled MN should be extended for storing the IGMP-based context formats mentioned above, including the IGMP version indicator.
さらに、マルチキャストメンバーシップ情報は特定の状況（プロアクティブハンドオーバーなど）で一時的にモビリティアンカーに保存されるため、IPv4ベースのマルチキャスト対応MNのバインディングキャッシュエントリは、上記のIGMPベースのコンテキスト形式を保存するために拡張する必要があります。 、IGMPバージョンインジケーターを含む。
Throughout this document, the base solution for multicast support in Proxy Mobile IPv6, described in [RFC6224], has been implicitly considered, i.e., both unicast and multicast traffic addressing a mobile node is delivered via the standard PMIPv6 bidirectional tunnel between LMA and MAG. While here all multicast traffic is assumed to be delivered via the local mobility anchor, the SIAL approach described in this document can be also applied to other solutions in which the multicast content is served from other entities in the PMIPv6 domain, as described in [RFC7028] to solve the tunnel convergence problem.
このドキュメント全体を通して、[RFC6224]で説明されている、プロキシモバイルIPv6でのマルチキャストサポートの基本ソリューションが暗黙的に検討されています。つまり、モバイルノードをアドレス指定するユニキャストトラフィックとマルチキャストトラフィックの両方が、LMAとMAGの間の標準のPMIPv6双方向トンネルを介して配信されます。ここではすべてのマルチキャストトラフィックがローカルモビリティアンカー経由で配信されることを想定していますが、このドキュメントで説明されているSIALアプローチは、[RFC7028で説明されているように、PMIPv6ドメイン内の他のエンティティからマルチキャストコンテンツが提供される他のソリューションにも適用できます。 ]トンネル収束問題を解決します。
In this case, the transfer of the multicast context would also pass through the local mobility anchor, as described here. However, the nMAG subscribes to the multicast content through the node in charge of distributing multicast according to the adopted solution for multicast distribution in the PMIPv6 domain.
この場合、ここで説明するように、マルチキャストコンテキストの転送もローカルモビリティアンカーを通過します。ただし、nIPvは、PMIPv6ドメインでのマルチキャスト配信に採用されているソリューションに従って、マルチキャスト配信を担当するノードを介してマルチキャストコンテンツにサブスクライブします。
This proposal does not pose any additional security threats to those already identified in [RFC5213]. All the security considerations in [RFC5213] are directly applicable to this protocol. The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement (extended with the new options defined in this document), the Subscription Query Message, and the Subscription Response Message exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
この提案は、[RFC5213]ですでに特定されている脅威に追加のセキュリティ上の脅威をもたらすことはありません。 [RFC5213]のセキュリティに関する考慮事項はすべて、このプロトコルに直接適用できます。モバイルアクセスゲートウェイとローカルモビリティアンカーの間で交換されるシグナリングメッセージ、プロキシバインディング更新、およびプロキシバインディング確認（このドキュメントで定義されている新しいオプションで拡張）、サブスクリプションクエリメッセージ、およびサブスクリプション応答メッセージは、整合性とデータ発信元認証を提供するエンドツーエンドのセキュリティアソシエーション。
The mobile access gateway and the local mobility anchor MUST implement the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document. In the following, we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect the new signaling introduced by this specification (Subscription Query Message and Subscription Response Message). We use the same format used by [RFC4877]. The SPD and SAD entries are only example configurations. A particular mobile access gateway implementation and a local mobility anchor home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the signaling messages.
モバイルアクセスゲートウェイとローカルモビリティアンカーは、このドキュメントで説明されているシグナリングを保護するために、プロキシモバイルIPv6 [RFC5213]で義務付けられているIPsecセキュリティメカニズムを実装する必要があります。以下では、この仕様（サブスクリプションクエリメッセージとサブスクリプション応答メッセージ）によって導入された新しいシグナリングを保護するために必要なセキュリティポリシーデータベース（SPD）およびセキュリティアソシエーションデータベース（SAD）エントリについて説明します。 [RFC4877]で使用されているものと同じ形式を使用します。 SPDおよびSADエントリーは、構成例にすぎません。特定のモバイルアクセスゲートウェイの実装とローカルモビリティアンカーホームエージェントの実装では、シグナリングメッセージに必要なセキュリティを提供する限り、異なるSPDエントリとSADエントリを構成できます。
For the examples described in this document, a mobile access gateway with address "mag_address_1", and a local mobility anchor with address "lma_address_1" are assumed.
このドキュメントで説明する例では、アドレス「mag_address_1」のモバイルアクセスゲートウェイ、およびアドレス「lma_address_1」のローカルモビリティアンカーが想定されています。
mobile access gateway SPD-S: - IF local_address = mag_address_1 & remote_address = lma_address_1 & proto = MH & (remote_mh_type = Subscription Query | local_mh_type = Subscription Response | remote_mh_type = Multicast Activity Indication Ack.| local_mh_type = Multicast Activity Indication) Then use SA1 (OUT) and SA2 (IN)
モバイルアクセスゲートウェイSPD-S：-IF local_address = mag_address_1＆remote_address = lma_address_1＆proto = MH＆（remote_mh_type = Subscription Query | local_mh_type = Subscription Response | remote_mh_type = Multicast Activity Indication Ack。| local_mh_type = Multicast Activity Indication）次にSA1（ OUT）およびSA2（IN）
mobile access gateway SAD:
- SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
- SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
local mobility anchor SPD-S: - IF local_address = lma_address_1 & remote_address =mag_address_1 & proto = MH & (remote_mh_type = Subscription Response | local_mh_type = Subscription Query | remote_mh_type = Multicast Activity Indication | local_mh_type = Multicast Activity Indication Ack.) Then use SA2 (OUT) and SA1 (IN)
ローカルモビリティアンカーSPD-S：-IF local_address = lma_address_1＆remote_address = mag_address_1＆proto = MH＆（remote_mh_type = Subscription Response | local_mh_type = Subscription Query | remote_mh_type = Multicast Activity Indication | local_mh_type = Multicast Activity Indication Ack。）次に、SA2を使用します（ OUT）およびSA1（IN）
local mobility anchor SAD:
- SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
- SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
While in the base solution the LMA has learned of the subscribed multicast groups per MAG, in this specification the LMA is aware (during a handover process) of the multicast groups to which an MN visiting the PMIP domain is subscribed.
基本ソリューションでは、LMAはMAGごとにサブスクライブされたマルチキャストグループを学習しましたが、この仕様では、LMAは（ハンドオーバープロセス中に）PMIPドメインにアクセスするMNがサブスクライブしているマルチキャストグループを認識しています。
This document establishes new assignments to the IANA mobility parameters registry.
このドキュメントは、IANAモビリティパラメータレジストリへの新しい割り当てを確立します。
o Mobility Header types: the Subscription Query (22) and Subscription Response (23) mobility header types. The Type value for these Headers has been assigned from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry defined in <http://www.iana.org/assignments/mobility-parameters>.
o モビリティヘッダータイプ：Subscription Query（22）およびSubscription Response（23）モビリティヘッダータイプ。これらのヘッダーのタイプ値は、<http://www.iana.org/assignments/mobility-parameters>で定義されている「モビリティヘッダータイプ-モビリティヘッダーのMHタイプフィールド用」レジストリから割り当てられています。
o Mobility options: the Active Multicast Subscription mobility option for both IPv4 (56) and IPv6 (57) modes of operation. The Type value for these Mobility options has been assigned from the "Mobility Options" registry defined in <http://www.iana.org/ assignments/mobility-parameters>.
o モビリティオプション：IPv4（56）およびIPv6（57）の両方の動作モードのアクティブマルチキャストサブスクリプションモビリティオプション。これらのモビリティオプションのタイプ値は、<http://www.iana.org/assignments/mobility-parameters>で定義されている「モビリティオプション」レジストリから割り当てられています。
o Flags: this document reserves a new multicast Signaling flag (S). This flag has been reserved as value 0x0020 in the "Binding Update Flags" registry and value 0x04 in the "Binding Acknowledgment Flags" registry. These registries appear on <http://www.iana.org/ assignments/mobility-parameters>.
o フラグ：このドキュメントでは、新しいマルチキャストシグナリングフラグ（S）を予約しています。このフラグは、 "Binding Update Flags"レジストリの値0x0020および "Binding Acknowledgement Flags"レジストリの値0x04として予約されています。これらのレジストリは、<http://www.iana.org/assignments/mobility-parameters>にあります。
Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von-Hugo@telekom.de) extensively contributed to this document.
Dirk Von Hugo（Telekom Innovation Laboratories、Dirk.von-Hugo @ telekom.de）は、このドキュメントに広く貢献しました。
The authors would like to thank (in alphabetical order) Hitoshi Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt, and Stig Venaas for their valuable comments and discussions on the MULTIMOB mailing list. The authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet Sarikaya, and Stig Venaas for their reviews of this document.
著者は、MULTIMOBメーリングリストに関する貴重なコメントとディスカッションについて、浅江田仁、セルジオフィゲイレド、ゲオルギオスカラギアニス、マルコリープシュ、ベーチェットサリカヤ、トーマスC.シュミット、スティグベナスに感謝します。著者は、このドキュメントのレビューについて、浅枝仁志、アクバルラーマン、ベーチェットサリカヤ、スティグヴェナースにも感謝しています。
The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project), being also partially supported by the Ministry of Science and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 13992-C02-01).
これらの結果につながるカルロスJ.ベルナルドスの研究は、欧州連合の第7フレームワークプログラム（FP7-ICT-2009-5）から助成金契約nの下で資金を受け取りました。 258053（MEDIEVALプロジェクト）。これは、QUARTETプロジェクト（TIN2009-13992-C02-01）の下でスペインの科学革新省（MICINN）によって部分的にサポートされています。
The research of Ignacio Soto has also received funding from the Spanish MICINN through the I-MOVING project (TEC2010-18907).
Ignacio Sotoの研究は、I-MOVINGプロジェクト（TEC2010-18907）を通じてスペインのMICINNからも資金提供を受けています。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[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月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「Mobile IPv6（MIPv6）のMobile Node Identifier Option」、RFC 4283、2005年11月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V。およびF. Dupont、「Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture」、RFC 4877、2007年4月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[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月。
[Papagiannaki] Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and C. Diot, "Measurement and Analysis of Single-Hop Delay on an IP Backbone Network", IEEE Journal on Selected Areas in Communications, vol. 21, no. 6, August 2003.
[Papagiannaki] Papagiannaki、K.、Moon、S.、Fraliegh、C.、Thiran、P.、and C. Diot、 "Measurement and Analysis of Single-Hop Delay on a IP Backbone Network"、IEEE Journal on Selected Areas inコミュニケーション、vol。 21、いいえ。 2003年8月6日。
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010.
[RFC5949]横田浩司、チョウドリーK.、クードリR.、パティルB.、およびF.シア、「プロキシモバイルIPv6の高速ハンドオーバー」、RFC 5949、2010年9月。
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6224] Schmidt、T.、Wahehlisch、M。、およびS. Krishnan、「プロキシモバイルIPv6（PMIPv6）ドメインでのマルチキャストリスナーサポートの基本展開」、RFC 6224、2011年4月。
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012.
[RFC6636] Asaeda、H.、Liu、H。、およびQ. Wu、「インターネットグループ管理プロトコル（IGMP）の動作のチューニングとモバイルおよびワイヤレスネットワークのルーター用マルチキャストリスナーディスカバリ（MLD）」、RFC 6636、 2012年5月。
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013.
[RFC7028] Zuniga、JC。、Contreras、LM。、Bernardos、CJ。、Jeon、S。、およびY. Kim、「プロキシモバイルIPv6のマルチキャストモビリティルーティングの最適化」、RFC 7028、2013年9月。
[Verizon] Verizon, "LTE: The Future of Mobile Broadband Technology", Verizon White Paper, 2010, <http://opennetwork.verizonwireless.com/pdfs/ VZW_LTE_White_Paper_12-10.pdf>.
[Verizon] Verizon、「LTE：モバイルブロードバンドテクノロジーの未来」、Verizonホワイトペーパー、2010年、<http://opennetwork.verizonwireless.com/pdfs/ VZW_LTE_White_Paper_12-10.pdf>。
[Y.1541] ITU-T, "Network performance objectives for IP-based services", ITU-T Recommendation Y.1541, December 2011.
[Y.1541] ITU-T、「IPベースのサービスのネットワークパフォーマンス目標」、ITU-T勧告Y.1541、2011年12月。
This informative annex briefly analyzes and compares the performance improvement provided by the fast handover extensions specified in this document with the base multicast solution defined in [RFC6224]. The main aim is to determine the potential delay reduction in the acquisition of the multicast subscription information by the nMAG during the MN handover. To do that, the analysis focuses on the delay additional to the unicast handover due to the multicast operation in both cases.
この有益な附属書は、このドキュメントで指定されている高速ハンドオーバ拡張によって提供されるパフォーマンスの改善を簡単に分析し、[RFC6224]で定義されている基本マルチキャストソリューションと比較します。主な目的は、MNハンドオーバー中のnMAGによるマルチキャストサブスクリプション情報の取得における潜在的な遅延の削減を決定することです。それを行うために、分析は、どちらの場合もマルチキャスト操作によるユニキャストハンドオーバーに追加される遅延に焦点を当てています。
Different delay components have to be taken into account for this comparison. Since the interaction between the actors during the handover process (MN, pMAG, nMAG, LMA) is different for each of the solutions, different sources of delay can be expected for each of them.
この比較では、さまざまな遅延コンポーネントを考慮する必要があります。ハンドオーバープロセス中のアクター（MN、pMAG、nMAG、LMA）間の相互作用はソリューションごとに異なるため、ソリューションごとに異なる遅延の原因が予想されます。
The base solution relies on the standard MLD procedures to obtain the multicast subscription information directly from the MN. Once the nMAG completes the configuration of point-to-point link to the attaching MN (the configuration of this link as downstream interface of an MLD proxy instance can run in parallel), it immediately sends an MLD General Query towards the MN for learning of any active multicast subscription by the MN. When the MN receives the MLD Query, the MN provides information about the active memberships it maintains in the form of an MLD Report message. After successful transmission of this information via the wireless point of attachment to nMAG, the corresponding MLD proxy instance at the nMAG sets up the multicast status of the downstream interface. According to this process, the delay is originated on the MAG-MN communication.
基本ソリューションは、標準のMLD手順に依存して、MNから直接マルチキャストサブスクリプション情報を取得します。 nMAGは、接続しているMNへのポイントツーポイントリンクの構成を完了すると（MLDプロキシインスタンスのダウンストリームインターフェイスとしてのこのリンクの構成を並行して実行できます）、すぐにMLD一般クエリをMNに送信して、 MNによるアクティブなマルチキャストサブスクリプション。 MNがMLDクエリを受信すると、MNはMLDレポートメッセージの形式で維持するアクティブなメンバーシップに関する情報を提供します。 nMAGへのワイヤレス接続点を介してこの情報が正常に送信された後、nMAGの対応するMLDプロキシインスタンスは、ダウンストリームインターフェイスのマルチキャストステータスを設定します。このプロセスによれば、遅延はMAG-MN通信で発生します。
The delay components to be considered for the base solution are the following:
基本ソリューションで考慮される遅延コンポーネントは次のとおりです。
o D_bh, which is the unidirectional (one-way) delay encountered in the transmission path between the nMAG and the wireless point of attachment.
o D_bh。これは、nMAGとワイヤレス接続ポイントの間の伝送パスで発生する一方向（一方向）の遅延です。
o D_radio, which is the unidirectional delay due to the transfer of MLD control messages over the radio channel (user plane) between the wireless point of attachment and the MN, for the MLD Query and Report messages.
o D_radio。これは、MLDクエリおよびレポートメッセージの無線接続ポイントとMNの間の無線チャネル（ユーザープレーン）を介したMLD制御メッセージの転送による一方向の遅延です。
o D_mld, which is the delay incurred by the MN to answer the MLD Query.
o D_mld。これは、MLDクエリに応答するためにMNが被る遅延です。
The total observed delay can be then formulated as:
観測された遅延の合計は、次のように定式化できます。
D_base = 2 x (D_bh + D_radio) + D_mld
As described in this document, it is possible to distinguish two scenarios depending on the order in which the LMA receives the notifications of the MN registration and de-registration in the nMAG and the pMAG, respectively.
このドキュメントで説明するように、LMAがnMAGおよびpMAGでそれぞれMN登録および登録解除の通知を受信する順序に応じて、2つのシナリオを区別することができます。
In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG. As specified in this document, the LMA stores the multicast subscription information, which is provided to the nMAG during the MN registration process. Since the registration process necessarily happens before the MLD Query and Report process described in the base solution, the proactive case is inherently faster than the base solution. In fact, since the multicast subscription information is acquired properly during the registration process, the delay incurred is null.
プロアクティブなケースでは、MNは最初にpMAGによって登録解除され、後でnMAGによって登録されます。このドキュメントで指定されているように、LMAはマルチキャストサブスクリプション情報を格納します。これは、MN登録プロセス中にnMAGに提供されます。登録プロセスは、ベースソリューションで説明されているMLDクエリおよびレポートプロセスの前に必ず発生するため、プロアクティブなケースは、ベースソリューションよりも本質的に高速です。実際、マルチキャストサブスクリプション情報は登録プロセス中に適切に取得されるため、発生する遅延はゼロです。
In the reactive case, the LMA receives the MN registration from the nMAG without having previously received the MN de-registration from the pMAG. In case the MN maintains an active subscription, the LMA queries the pMAG to retrieve the multicast subscription information, which is forwarded to the nMAG. According to this process, the delay is originated on the MAG-LMA communication.
事後対応の場合、LMAは、以前にpMAGからのMN登録解除を受信していなくても、nMAGからMN登録を受信します。 MNがアクティブなサブスクリプションを維持している場合、LMAはpMAGに照会してマルチキャストサブスクリプション情報を取得し、nMAGに転送されます。このプロセスによれば、遅延はMAG-LMA通信で発生します。
The delay components to be considered for the base solution are the following:
基本ソリューションで考慮される遅延コンポーネントは次のとおりです。
o D_net, which is the unidirectional delay found in the network path between the LMA and the MAG.
o D_net。これは、LMAとMAGの間のネットワークパスに見られる単方向遅延です。
The total observed delay can be then formulated as:
観測された遅延の合計は、次のように定式化できます。
D_sial = 2 x D_net
The performance of the base solution is highly dependent on the radio technology used by the MN to attach to the PMIPv6 domain. Different radio technologies have distinct properties in terms of radio framing, radio access contention or collision avoidance, channel reliability, etc.
基本ソリューションのパフォーマンスは、MNがPMIPv6ドメインに接続するために使用する無線テクノロジーに大きく依存します。異なる無線技術には、無線フレーミング、無線アクセスの競合または衝突回避、チャネルの信頼性などに関して、異なる特性があります。
New radio access technologies, such as the one specified in new Long Term Evolution (LTE) standards intend to reduce the latency in order to provide high-speed communications. Even though, typical one-way latencies in the LTE radio access will stay around 15 ms [Verizon].
新しいLong Term Evolution（LTE）標準で指定されているものなどの新しい無線アクセステクノロジーは、高速通信を提供するためにレイテンシを削減することを目的としています。ただし、LTE無線アクセスの一般的な一方向の遅延は15ミリ秒程度です[Verizon]。
The backhaul delay characterization becomes problematic. In a real network, there are several solutions for the backhaul connection in terms of network topology (ring, star, point-to-point, etc.) and technology (optical fiber, microwave transmission, xDSL-based accesses, etc.), all of them having distinct properties in terms of performance, reliability, and delay. These solutions commonly coexist in a real mobile network, in such a way that an MN changing the point of attachment can pass smoothly from one solution to another. A value of D_bh = 5 ms can be established as the typical value for the backhaul latency in modern networks.
バックホール遅延の特性評価が問題になります。実際のネットワークでは、ネットワークトポロジ（リング、スター、ポイントツーポイントなど）と技術（光ファイバー、マイクロ波伝送、xDSLベースのアクセスなど）の観点から、バックホール接続にいくつかのソリューションがあります。それらのすべては、パフォーマンス、信頼性、および遅延の点で異なる特性を持っています。これらのソリューションは通常、実際のモバイルネットワークで共存します。つまり、接続点を変更するMNがソリューション間をスムーズに移動できるようにします。 D_bh = 5 msの値は、最新のネットワークのバックホール遅延の標準的な値として確立できます。
Finally, the MLD induced delay is intrinsic to the MLD protocol specification. A host receiving an MLD Query message waits a random time in the range (0, Maximum Response Delay) to send the MLD Report message. The default value of the Maximum Response Delay (configurable through the Query Response Interval in MLD) is 10 s in [RFC2710] and [RFC3810]. In [RFC6636] the effect of tuning the value of the Query Response Interval is analyzed and 5 s is the smallest value recommended (best case). Then, on average, a potential delay of 5 s or 2.5 s, default and best case respectively, can be expected.
最後に、MLDによって引き起こされる遅延は、MLDプロトコル仕様に固有のものです。 MLDクエリメッセージを受信するホストは、範囲（0、最大応答遅延）のランダムな時間待機して、MLDレポートメッセージを送信します。 [RFC2710]および[RFC3810]では、最大応答遅延のデフォルト値（MLDのクエリ応答間隔で構成可能）は10秒です。 [RFC6636]では、クエリ応答間隔の値を調整する効果が分析され、5秒が推奨される最小値です（最良の場合）。その後、平均して、それぞれ5秒または2.5秒の潜在的な遅延が発生します。デフォルトはそれぞれ、ベストケースです。
As we have seen, D_base is, on average, greater than 2.5 s with the best case of the values of Query Response Interval in MLD that are recommended in [RFC6636]. That means that the handover delay of the base solution is on the order of seconds, while in the solution presented in this specification it is on the order of milliseconds (as shown below). To improve the performance of the base solution, we could further reduce the value of Query Response Interval, but the implications of doing so would need to be carefully analyzed. Even if we assume that Query Response Interval is 0 s, D_base would be around 2 x (5 ms + 15 ms) = 40 ms for last-generation systems. Note that this calculation does not take into account the necessary time to re-establish the data plane after the handover to make possible the MLD Query reception. The expected delay will get much worse for older generation systems (e.g., 3G-based radio systems can suffer radio delays in the order of hundreds of ms).
これまで見てきたように、D_baseは平均で2.5秒を超えており、[RFC6636]で推奨されているMLDのクエリ応答間隔の値の最良のケースです。つまり、ベースソリューションのハンドオーバー遅延は秒単位ですが、この仕様で提示されているソリューションではミリ秒単位です（下図参照）。基本ソリューションのパフォーマンスを向上させるために、クエリ応答間隔の値をさらに減らすことができますが、その影響を慎重に分析する必要があります。クエリの応答間隔が0秒であると仮定しても、最終世代のシステムでは、D_baseは約2 x（5 ms + 15 ms）= 40 msになります。この計算では、MLDクエリの受信を可能にするために、ハンドオーバー後にデータプレーンを再確立するために必要な時間を考慮していないことに注意してください。予想される遅延は、古い世代のシステムではさらに悪化します（たとえば、3Gベースの無線システムでは、数百ms程度の無線遅延が発生する可能性があります）。
For the SIAL case, the delay in the MAG-LMA communication will be derived from the network diameter (i.e., the number of hops found between the MAG and the LMA in the PMIPv6 domain). This is largely influenced by the internal network planning. An administrative domain can typically have in the order of five hops from access to the interconnection gateway providing connectivity to other networks.
SIALの場合、MAG-LMA通信の遅延は、ネットワークの直径（つまり、MAGとPMIPv6ドメイン内のLMAの間にあるホップ数）から導き出されます。これは、内部ネットワークの計画に大きく影響されます。通常、管理ドメインは、他のネットワークへの接続を提供する相互接続ゲートウェイへのアクセスから5ホップのオーダーを持つことができます。
Even if the LMA plays a central role topologically in the PMIPv6 domain, such number of hops seems reasonable in a common nation-wide network. Each hop in the path between MAG and LMA will add a certain delay, which can be estimated to be around 1 ms in the best case [Papagiannaki] and 3 ms in the worst case [Y.1541]. With this in mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can be expected in the worst case.
LMAがトポロジー的にPMIPv6ドメインで中心的な役割を果たす場合でも、このようなホップ数は、一般的な全国規模のネットワークでは妥当なようです。 MAGとLMA間のパスの各ホップは、特定の遅延を追加します。これは、最良の場合[Papagiannaki]で約1 ms、最悪の場合[Y.1541]で3 msと推定できます。これを念頭に置いて、最悪の場合、約2 x 5 x 3 ms = 30 msの合計遅延D_sialが予想されます。
Then, in conclusion, in a typical deployment, it can be stated that the SIAL proposal, even for the worst-case consideration, will perform better than the best-case situation for the base solution, which consists of the last-generation radio technology, LTE. For any other radio technology, the base solution will show even larger deviations from the delay achievable with the SIAL solution.
次に、結論として、一般的な展開では、最悪の場合でも、SIALの提案は、最終世代の無線技術で構成されるベースソリューションのベストケースの状況よりもパフォーマンスが優れていると言えます。 、LTE。その他の無線技術の場合、基本ソリューションは、SIALソリューションで達成可能な遅延からの偏差がさらに大きくなります。
Authors' Addresses
著者のアドレス
Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain
Luis M. Contreras Telefonica I + D Ronda de la Comunicacion、s / n Sur-3ビルディング、3階マドリード28050スペイン
EMail: lmcm@tid.es
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドスカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
イグナシオソトカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
EMail: isoto@it.uc3m.es