[要約] RFC 7411は、MIPv6およびPMIPv6の高速ハンドオーバーに対するマルチキャストリスナー拡張の要約です。このRFCの目的は、モバイルネットワークでの高速ハンドオーバー時にマルチキャストトラフィックを効率的に処理するための拡張を提供することです。
Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7411 HAW Hamburg
Updates: 5568 M. Waehlisch
Category: Experimental link-lab & FU Berlin
ISSN: 2070-1721 R. Koodli
Intel
G. Fairhurst
University of Aberdeen
D. Liu
China Mobile
November 2014
Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
モバイルIPv6（MIPv6）およびプロキシモバイルIPv6（PMIPv6）高速ハンドオーバー用のマルチキャストリスナー拡張
Abstract
概要
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.
モバイルIPv6（MIPv6）およびプロキシモバイルIPv6（PMIPv6）の高速ハンドオーバープロトコルは、ハンドオーバーレイテンシを削減したユニキャスト通信をサポートするモビリティ管理手順を定義します。高速なハンドオーバーの基本操作はマルチキャスト通信に影響を与えないため、ネイティブマルチキャストリスナーのハンドオーバー管理を加速しません。ただし、IPTVや会議などの多くのマルチキャストアプリケーションは、遅延の影響を受けやすいリアルタイムトラフィックで構成されており、ハンドオーバーの完了が速いというメリットがあります。このドキュメントでは、モバイルIPv6高速ハンドオーバー（FMIPv6）およびプロキシモバイルIPv6の高速ハンドオーバー（PFMIPv6）プロトコルの拡張を指定して、高速ハンドオーバー操作にマルチキャストトラフィック管理を含めます。このマルチキャストサポートは、最初にアクセスルーター間の迅速なコンテキスト転送の管理によってコントロールプレーンで提供され、次にバッファリングを含むオプションの高速トラフィック転送によってデータプレーンで提供されます。 FMIPv6アクセスルーターは、更新されたプロキシルーターアドバタイズメントメッセージ形式を使用したマルチキャストのサポートを示します。
This document updates RFC 5568, "Mobile IPv6 Fast Handovers".
このドキュメントは、RFC 5568「Mobile IPv6 Fast Handovers」を更新します。
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/rfc7411.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7411で入手できます。
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 ....................................................4
1.1. Use Cases and Deployment Scenarios .........................5
2. Terminology .....................................................6
3. Protocol Overview ...............................................6
3.1. Multicast Context Transfer between Access Routers ..........7
3.2. Protocol Operations Specific to FMIPv6 .....................9
3.3. Protocol Operations Specific to PFMIPv6 ...................12
4. Protocol Details ...............................................15
4.1. Protocol Operations Specific to FMIPv6 ....................15
4.1.1. Operations of the Mobile Node ......................15
4.1.2. Operations of the Previous Access Router ...........15
4.1.3. Operations of the New Access Router ................16
4.1.4. Buffering Considerations ...........................17
4.2. Protocol Operations Specific to PFMIPv6 ...................17
4.2.1. Operations of the Mobile Node ......................17
4.2.2. Operations of the Previous MAG .....................17
4.2.3. Operations of the New MAG ..........................19
4.2.4. IPv4 Support Considerations ........................20
5. Message Formats ................................................20
5.1. Multicast Indicator for Proxy Router Advertisement
(PrRtAdv) .................................................20
5.2. Extensions to Existing Mobility Header Messages ...........21
5.3. New Multicast Mobility Option .............................21
5.4. New Multicast Acknowledgement Option ......................24
5.5. Length Considerations: Number of Records and Addresses ....25
5.6. MLD and IGMP Compatibility Requirements ...................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Appendix A. Considerations for Mobile Multicast Sources ..........29
Acknowledgments ...................................................29
Authors' Addresses ................................................30
Mobile IPv6 [RFC6275] defines a network-layer mobility protocol involving participation by Mobile Nodes, while Proxy Mobile IPv6 [RFC5213] provides a mechanism without requiring mobility protocol operations at a Mobile Node (MN). Both protocols introduce traffic disruptions on handovers that may be intolerable in many real-time application scenarios such as gaming or conferencing. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of handovers for unicast communication. Delays are reduced to the order of the maximum of the link switching delay and the signaling delay between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis].
モバイルIPv6 [RFC6275]は、モバイルノードによる参加を含むネットワーク層モビリティプロトコルを定義し、プロキシモバイルIPv6 [RFC5213]は、モバイルノード（MN）でのモビリティプロトコル操作を必要としないメカニズムを提供します。どちらのプロトコルも、ゲームや会議などの多くのリアルタイムアプリケーションシナリオでは耐えられない可能性がある、ハンドオーバーでのトラフィックの中断をもたらします。モバイルIPv6高速ハンドオーバー（FMIPv6）[RFC5568]とプロキシモバイル高速IPv6（PFMIPv6）[RFC5949]は、ユニキャスト通信のハンドオーバーのパフォーマンスを向上させます。遅延は、アクセスルーター（AR）またはモバイルアクセスゲートウェイ（MAG）間のリンクスイッチング遅延とシグナリング遅延の最大値のオーダーまで削減されます[FMIPv6-Analysis]。
No dedicated treatment of seamless IP multicast [RFC1112] data service has been proposed by any of the above protocols. MIPv6 only roughly defines multicast for Mobile Nodes using a remote subscription approach or a home subscription through bidirectional tunneling via the Home Agent (HA). Multicast forwarding services have not been specified in [RFC5213] but are subject to separate specifications: [RFC6224] and [RFC7287]. It is assumed throughout this document that mechanisms and protocol operations are in place to transport multicast traffic to ARs. These operations are referred to as 'JOIN/LEAVE' of an AR, while the explicit techniques to manage multicast transmission are beyond the scope of this document.
上記のプロトコルでは、シームレスIPマルチキャスト[RFC1112]データサービスの専用処理は提案されていません。 MIPv6は、リモートサブスクリプションアプローチまたはホームエージェント（HA）を介した双方向トンネリングによるホームサブスクリプションを使用して、モバイルノードのマルチキャストを大まかにのみ定義します。マルチキャスト転送サービスは[RFC5213]で指定されていませんが、[RFC6224]と[RFC7287]の別の仕様が適用されます。このドキュメントでは、マルチキャストトラフィックをARに転送するためのメカニズムとプロトコル操作が用意されていることを前提としています。これらの操作はARの「JOIN / LEAVE」と呼ばれますが、マルチキャスト送信を管理する明示的な手法はこのドキュメントの範囲外です。
Mobile multicast protocols need to support applications such as IPTV with high-volume content streams and allow distribution to potentially large numbers of receivers. They should thus preserve the multicast nature of packet distribution and approximate optimal routing [RFC5757]. It is undesirable to rely on home tunneling for optimizing multicast. Unencapsulated, native multicast transmission requires establishing forwarding state, which will not be transferred between access routers by the unicast fast handover protocols. Thus, multicast traffic will not experience expedited handover performance, but an MN -- or its corresponding MAG in PMIPv6 -- can perform remote subscriptions in each visited network.
モバイルマルチキャストプロトコルは、大量のコンテンツストリームを使用するIPTVなどのアプリケーションをサポートし、潜在的に多数のレシーバーへの配信を可能にする必要があります。したがって、それらは、パケット配信のマルチキャストの性質を維持し、最適なルーティングを近似する必要があります[RFC5757]。マルチキャストを最適化するためにホームトンネリングに依存することは望ましくありません。カプセル化されていないネイティブマルチキャスト転送では、転送状態を確立する必要があります。転送状態は、ユニキャスト高速ハンドオーバープロトコルによってアクセスルータ間で転送されません。したがって、マルチキャストトラフィックは、迅速なハンドオーバーパフォーマンスを経験しませんが、MN-またはそれに対応するPMIPv6のMAG-は、訪問した各ネットワークでリモートサブスクリプションを実行できます。
This document specifies extensions to FMIPv6 and PFMIPv6 that include multicast traffic management for fast handover operations in the presence of any-source or source-specific multicast. The protocol extensions were designed under the requirements that
このドキュメントでは、FMIPv6およびPFMIPv6の拡張機能について説明します。これには、任意のソースまたはソース固有のマルチキャストが存在する場合の高速ハンドオーバー操作のためのマルチキャストトラフィック管理が含まれます。プロトコル拡張は、以下の要件の下で設計されました
o multicast context transfer shall be transparently included in unicast fast handover operations;
o マルチキャストコンテキスト転送は、ユニキャスト高速ハンドオーバー操作に透過的に含まれます。
o neither unicast mobility protocols nor multicast routing shall be modified or otherwise affected; and
o ユニキャストモビリティプロトコルもマルチキャストルーティングも変更またはその他の影響を受けません。そして
o no active participation of MNs in PMIPv6 domains is defined.
o PMIPv6ドメインへのMNのアクティブな参加は定義されていません。
The solution common to both underlying unicast protocols defines the per-group or per-channel transfer of multicast contexts between ARs or MAGs. The protocol defines corresponding message extensions necessary for carrying (*,G) or (S,G) context information independent of the particular handover protocol. ARs or MAGs are then enabled to treat multicast traffic according to fast unicast handovers and with similar performance. No protocol changes are introduced that prevent a multicast-unaware node from performing fast handovers with multicast-aware ARs or MAGs.
基礎となる両方のユニキャストプロトコルに共通のソリューションは、ARまたはMAG間のマルチキャストコンテキストのグループごとまたはチャネルごとの転送を定義します。プロトコルは、特定のハンドオーバープロトコルとは無関係に、（*、G）または（S、G）コンテキスト情報を運ぶために必要な対応するメッセージ拡張を定義します。その後、ARまたはMAGは、高速ユニキャストハンドオーバーに従って、同様のパフォーマンスでマルチキャストトラフィックを処理できるようになります。マルチキャスト非対応ノードがマルチキャスト対応ARまたはMAGで高速のハンドオーバーを実行できないようにするプロトコル変更は導入されていません。
The specified mechanisms apply when a Mobile Node has joined and maintains one or several multicast group subscriptions prior to undergoing a fast handover. It does not introduce any requirements on the multicast routing protocols in use, nor are the ARs or MAGs assumed to be multicast routers. It assumes network conditions, though, that allow native multicast reception in both the previous and new access network. Methods to bridge regions without native multicast connectivity are beyond the scope of this document.
指定されたメカニズムは、モバイルノードが参加して、高速ハンドオーバーを受ける前に1つまたは複数のマルチキャストグループサブスクリプションを維持する場合に適用されます。使用中のマルチキャストルーティングプロトコルに関する要件は導入されていません。また、ARまたはMAGがマルチキャストルーターであると想定されていません。ただし、以前のアクセスネットワークと新しいアクセスネットワークの両方でネイティブマルチキャスト受信が可能なネットワーク条件を前提としています。ネイティブマルチキャスト接続なしでリージョンをブリッジする方法は、このドキュメントの範囲外です。
Section 5.1 of this memo updates the Proxy Router Advertisements (PrRtAdv) message format defined in Section 6.1.2 of [RFC5568] to allow an FMIPv6 AR to indicate support for multicast.
このメモのセクション5.1は、[RFC5568]のセクション6.1.2で定義されたプロキシルーターアドバタイズ（PrRtAdv）メッセージフォーマットを更新して、FMIPv6 ARがマルチキャストのサポートを示すことを可能にします。
Multicast extensions for fast handovers enable multicast services in domains that operate either of the unicast fast handover protocols: [RFC5568] or [RFC5949]. Typically, fast handover protocols are activated within an operator network or within a dedicated service installation.
高速ハンドオーバーのマルチキャスト拡張機能は、ユニキャスト高速ハンドオーバープロトコル[RFC5568]または[RFC5949]のいずれかを運用するドメインでマルチキャストサービスを有効にします。通常、高速ハンドオーバープロトコルは、オペレーターネットワーク内または専用サービスインストール内でアクティブ化されます。
Multicast group communication has a variety of dominant use cases. One traditional application area is infotainment with voluminous multimedia streams delivered to a large number of receivers (e.g., IPTV). Other time-critical services, such as news items or stock-exchange prices, are commonly transmitted via multicast to support fair and fast updates. Both of these use cases may be mobile, and both largely benefit from fast handover operations. Mobile operators may therefore enhance their operational quality or offer premium services by enabling fast handovers.
マルチキャストグループ通信には、さまざまな主要なユースケースがあります。従来のアプリケーション領域の1つは、大量のマルチメディアストリームが多数のレシーバー（IPTVなど）に配信されるインフォテインメントです。ニュースアイテムや株式交換価格などの他のタイムクリティカルなサービスは、公正かつ迅速な更新をサポートするために、マルチキャストを介して送信されるのが一般的です。これらのユースケースはどちらもモバイルである可能性があり、どちらも主に高速なハンドオーバー操作の恩恵を受けます。したがって、モバイルオペレーターは、高速なハンドオーバーを可能にすることで、運用品質を向上させたり、プレミアムサービスを提供したりできます。
Another traditional application area for multicast is conversational group communication in scenarios like conferencing or gaming as well as in dedicated collaborative environments or teams. Machine-to-machine communication in the emerging Internet of Things is expected to generate various additional mobile use cases (e.g., among cars). High demands on transmission quality and rapidly moving parties may require fast handovers.
マルチキャストのもう1つの従来のアプリケーション領域は、会議やゲームなどのシナリオでの会話型グループ通信だけでなく、専用のコラボレーション環境やチームでの通信です。新しいモノのインターネットにおけるマシン間通信は、さまざまな追加のモバイルユースケース（たとえば、車間）を生成することが期待されています。伝送品質への高い要求と急速に変化する当事者は、高速なハンドオーバーを必要とする場合があります。
Most of the deployment scenarios above are bound to a fixed infrastructure with consumer equipment at the edge. Today, they are thus likely to follow an operator-centric approach like PFMIPv6. However, Internet technologies evolve for adoption in infrastructureless scenarios, for example, disaster recovery, rescue, crisis prevention, and civil safety. Mobile end-to-end communication in groups is needed in Public Protection and Disaster Relief (PPDR) scenarios, where mobile multicast communication needs to be supported between members of rescue teams, police officers, fire brigade teams, paramedic teams, and command control offices in order to support the protection and health of citizens. These use cases require fast and reliable mobile services that cannot rely on operator infrastructure. They are thus expected to benefit from running multicast with FMIPv6.
上記の導入シナリオのほとんどは、エッジに民生機器を備えた固定インフラストラクチャにバインドされています。したがって、今日、彼らはPFMIPv6のようなオペレーター中心のアプローチに従う可能性があります。ただし、インターネットテクノロジーは、災害復旧、救助、危機防止、市民の安全など、インフラストラクチャのないシナリオで採用するために進化しています。公共保護および災害救援（PPDR）シナリオでは、グループでのモバイルエンドツーエンド通信が必要です。この場合、レスキューチームのメンバー、警察官、消防隊チーム、救急隊チーム、および司令部署の間でモバイルマルチキャスト通信をサポートする必要があります。市民の保護と健康をサポートするために。これらの使用例では、オペレーターのインフラストラクチャに依存できない高速で信頼性の高いモバイルサービスが必要です。したがって、FMIPv6でマルチキャストを実行することでメリットが期待されます。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the terminology for mobility entities in [RFC5568], [RFC5949], [RFC6275], and [RFC5213].
このドキュメントでは、[RFC5568]、[RFC5949]、[RFC6275]、および[RFC5213]のモビリティエンティティの用語を使用しています。
A multicast group is any group (*,G) or (S,G) multicast channel listed in a Multicast Listener Report Message.
マルチキャストグループは、マルチキャストリスナーレポートメッセージにリストされているグループ（*、G）または（S、G）マルチキャストチャネルです。
This section provides an informative overview of the protocol mechanisms without normative specifications.
このセクションでは、規範的な仕様なしのプロトコルメカニズムの概要を説明します。
The reference scenario for multicast fast handover is illustrated in Figure 1. A Mobile Node is initially attached to the previous access network (P-AN) via the Previous Access Router (PAR) or Previous Mobile Access Gateway (PMAG) and moves to the new access network (N-AN) connected via a New AR (NAR) or New MAG (NMAG).
マルチキャスト高速ハンドオーバーの参照シナリオを図1に示します。モバイルノードは最初に、以前のアクセスルータ（PAR）または以前のモバイルアクセスゲートウェイ（PMAG）を介して以前のアクセスネットワーク（P-AN）に接続され、新しいノードに移動します。 New AR（NAR）またはNew MAG（NMAG）を介して接続されたアクセスネットワーク（N-AN）。
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
図1：高速ハンドオーバーの参照ネットワーク
In a fast handover scenario (see Figure 1), ARs/MAGs establish a mutual binding and provide the capability to exchange context information concerning the MN. This context transfer will be triggered by detecting the forthcoming movement of an MN to a new AR and assists the MN to immediately resume communication on the new subnet using its previous IP address. In contrast to unicast, multicast flow reception does not primarily depend on address and binding cache management but requires distribution trees to adapt so that traffic follows the movement of the MN. This process may be significantly slower than fast handover management [RFC5757]. To accelerate the handover, a multicast listener may offer a twofold advantage of including the multicast groups under subscription in the context transfer. First, the NAR can proactively join the subscribed groups as soon as it gains knowledge of them. Second, multicast flows can be included in traffic forwarding via the tunnel that is established from the PAR to the NAR by the unicast fast handover protocol.
高速ハンドオーバのシナリオ（図1を参照）では、AR / MAGは相互バインディングを確立し、MNに関するコンテキスト情報を交換する機能を提供します。このコンテキスト転送は、新しいARへのMNの今後の移動を検出することによってトリガーされ、MNが以前のIPアドレスを使用して新しいサブネットでの通信をすぐに再開するのに役立ちます。ユニキャストとは対照的に、マルチキャストフローの受信は、主にアドレスとバインディングキャッシュの管理に依存しませんが、トラフィックがMNの動きに追従するように、配布ツリーを適応させる必要があります。このプロセスは、高速なハンドオーバー管理[RFC5757]よりも大幅に遅くなる可能性があります。ハンドオーバーを加速するために、マルチキャストリスナーは、コンテキスト転送のサブスクリプションにマルチキャストグループを含めるという2つの利点を提供します。第1に、NARはサブスクライブされたグループの知識を得るとすぐに、それらのグループに積極的に参加できます。第2に、ユニキャスト高速ハンドオーバープロトコルによってPARからNARに確立されるトンネルを介したトラフィック転送にマルチキャストフローを含めることができます。
There are two modes of operation in FMIPv6 and in PFMIPv6. The predictive mode allows for AR-binding and context transfer prior to an MN handover, while in the reactive mode, these steps are executed after detection that the MN has reattached to a NAR (NMAG). Details of the signaling schemes differ between FMIPv6 and PFMIPv6 and are outlined in Sections 3.2 and 3.3.
FMIPv6とPFMIPv6には2つの動作モードがあります。予測モードでは、MNハンドオーバーの前にARバインディングとコンテキスト転送が可能ですが、リアクティブモードでは、MNがNAR（NMAG）に再接続されたことを検出した後でこれらの手順が実行されます。シグナリングスキームの詳細はFMIPv6とPFMIPv6で異なり、セクション3.2および3.3で概説されています。
In a predictive fast handover, the access router (i.e., PAR (PMAG) in Figure 1) learns about the impending movement of the MN and simultaneously about the multicast group context as specified in Sections 3.2 and 3.3. Thereafter, the PAR will initiate an AR-binding and context transfer by transmitting a Handover Initiation (HI) message to the NAR (NMAG). The HI message is extended by multicast group states carried in mobility header options, as defined in Section 5.3. On reception of the HI message, the NAR returns a multicast acknowledgement in its Handover Acknowledgement (HAck) answer that indicates its ability to support each requested group (see Section 5.4). The NAR (NMAG) expresses its willingness to receive multicast traffic forwarded by the PAR using standard Multicast Listener Discovery (MLD) signaling for IPv6 or the Internet Group Management Protocol (IGMP) for an IPv4 compatibility case.
予測高速ハンドオーバーでは、アクセスルーター（図1のPAR（PMAG））は、セクション3.2および3.3で指定されているように、MNの差し迫った移動と、同時にマルチキャストグループコンテキストについて学習します。その後、ＰＡＲは、ハンドオーバー開始（ＨＩ）メッセージをＮＡＲ（ＮＭＡＧ）に送信することにより、ＡＲバインディングおよびコンテキスト転送を開始する。セクション5.3で定義されているように、HIメッセージは、モビリティヘッダーオプションで伝送されるマルチキャストグループステートによって拡張されます。 HIメッセージを受信すると、NARは、Handover Acknowledgment（HAck）応答でマルチキャスト確認応答を返します。これは、要求された各グループをサポートする能力を示します（セクション5.4を参照）。 NAR（NMAG）は、IPv6の場合は標準のマルチキャストリスナーディスカバリ（MLD）シグナリング、IPv4互換の場合はインターネットグループ管理プロトコル（IGMP）を使用して、PARによって転送されるマルチキャストトラフィックを受信する意欲を表します。
Nodes normally create forwarding state for each group requested. There are several reasons why a node may decide not to forward a specific group, e.g., the NAR could already have a native subscription for the group(s) or capacity constraints can hinder decapsulation of additional streams. At the previous network, there may be policy or capacity constraints that make it undesirable to forward the multicast traffic. The PAR can add the tunnel interface obtained from the underlying unicast protocol to its multicast forwarding database for those groups the MN wishes to receive, so that multicast flows can be forwarded in parallel to the unicast traffic.
ノードは通常、要求されたグループごとに転送状態を作成します。ノードが特定のグループを転送しないことを決定する理由はいくつかあります。たとえば、NARがグループのネイティブサブスクリプションをすでに持っているか、容量の制約が追加のストリームのカプセル化解除を妨げる可能性があります。以前のネットワークでは、マルチキャストトラフィックを転送することが望ましくないポリシーまたは容量の制約がある場合があります。 PARは、基になるユニキャストプロトコルから取得したトンネルインターフェイスを、MNが受信するグループのマルチキャスト転送データベースに追加できるため、マルチキャストフローをユニキャストトラフィックに並行して転送できます。
The NAR implements an MLD proxy [RFC4605] providing host-side behavior towards the upstream PAR. The proxy will submit an MLD report to the upstream tunnel interface to signal the set of groups to be forwarded. It will terminate multicast forwarding from the tunnel when the group is natively received. In parallel, the NAR joins all groups that are not already under subscription using its native multicast upstream interface. While the MN has not arrived at a downstream interface of the NAR, multicast subscriptions on behalf of the MN are associated with a downstream loopback interface. Reception of the Join at the NAR enables downstream native multicast forwarding of the subscribed group(s).
NARはMLDプロキシ[RFC4605]を実装し、ホスト側の動作を上流のPARに提供します。プロキシはMLDレポートをアップストリームトンネルインターフェイスに送信して、転送するグループのセットを通知します。グループがネイティブに受信されると、トンネルからのマルチキャスト転送を終了します。並行して、NARは、ネイティブマルチキャストアップストリームインターフェイスを使用して、まだサブスクリプションになっていないすべてのグループに参加します。 MNはNARのダウンストリームインターフェイスに到達していませんが、MNに代わってマルチキャストサブスクリプションがダウンストリームループバックインターフェイスに関連付けられています。 NARでのJoinの受信により、サブスクライブされたグループのダウンストリームネイティブマルチキャスト転送が可能になります。
In a reactive fast handover, the PAR will learn about the movement of the MN after the latter has re-associated with the new access network. Also, from the new link, it will be informed about the multicast context of the MN. As group membership information is present at the new access network prior to context transfer, MLD join signaling can proceed in parallel to HI/HAck exchange. Following the context transfer, multicast data can be forwarded to the new access network using the PAR-NAR tunnel of the fast handover protocol. Depending on the specific network topology, multicast traffic for some groups may natively arrive before it is forwarded from the PAR.
リアクティブ高速ハンドオーバーでは、PARはMNが新しいアクセスネットワークに再度関連付けられた後、MNの移動について学習します。また、新しいリンクから、MNのマルチキャストコンテキストについて通知されます。グループメンバーシップ情報はコンテキスト転送の前に新しいアクセスネットワークに存在するため、MLD加入シグナリングはHI / HAck交換と並行して進行できます。コンテキスト転送に続いて、高速ハンドオーバープロトコルのPAR-NARトンネルを使用して、マルチキャストデータを新しいアクセスネットワークに転送できます。特定のネットワークトポロジによっては、一部のグループのマルチキャストトラフィックは、PARから転送される前にネイティブに到着する場合があります。
In both modes of operation, it is the responsibility of the PAR (PMAG) to properly apply multicast state management when an MN leaves (i.e., to determine whether it can prune the traffic for any unsubscribed group). Depending on the link type and MLD parameter settings, methods for observing the departure of an MN need to be applied (see [RFC5757]). While considering subscriptions of the remaining nodes and from the tunnel interfaces, the PAR uses normal multicast forwarding rules to determine whether multicast traffic can be pruned.
どちらの動作モードでも、MNが離れるときにマルチキャスト状態管理を適切に適用する（つまり、サブスクライブされていないグループのトラフィックをプルーニングできるかどうかを判断する）のは、PAR（PMAG）の責任です。リンクタイプとMLDパラメータ設定に応じて、MNの離脱を監視する方法を適用する必要があります（[RFC5757]を参照）。残りのノードのサブスクリプションとトンネルインターフェイスからのサブスクリプションを検討している間、PARは通常のマルチキャスト転送ルールを使用して、マルチキャストトラフィックをプルーニングできるかどうかを判断します。
This method allows an MN to participate in multicast group communication with a handover performance that is comparable to unicast handover. It is worth noting that tunnel management between access routers in all modes is inherited from the corresponding unicast fast handover protocols. Tunnels thus remain active until unicast handover operations have been completed for the MN.
この方法により、MNはユニキャストハンドオーバーに匹敵するハンドオーバーパフォーマンスでマルチキャストグループ通信に参加できます。すべてのモードのアクセスルータ間のトンネル管理は、対応するユニキャスト高速ハンドオーバープロトコルから継承されることに注意してください。したがって、トンネルは、MNのユニキャストハンドオーバー操作が完了するまでアクティブのままです。
ARs that provide multicast support in FMIPv6 will advertise this general service by setting an indicator bit ('M' bit) in its PrRtAdv message, as defined in Section 5.1. Additional details about the multicast service support, e.g., flavors and groups, will be exchanged within HI/HAck dialogs later at handover.
FMIPv6でマルチキャストサポートを提供するARは、5.1で定義されているように、PrRtAdvメッセージにインジケータビット（ 'M'ビット）を設定することにより、この一般的なサービスをアドバタイズします。マルチキャストサービスサポートに関する追加の詳細（フレーバーやグループなど）は、後でハンドオーバー時にHI / HAckダイアログ内で交換されます。
An MN operating FMIPv6 will actively initiate the handover management by submitting a Fast Binding Update (FBU). The MN, which is aware of the multicast groups it wishes to maintain, will attach mobility options containing its group states (see Section 5.3) to the FBU and thereby inform ARs about its multicast context. ARs will use these multicast context options for inter-AR context transfer.
FMIPv6を運用するMNは、高速バインディング更新（FBU）を送信することにより、ハンドオーバー管理をアクティブに開始します。維持したいマルチキャストグループを認識しているMNは、グループ状態（5.3を参照）を含むモビリティオプションをFBUにアタッチし、ARにマルチキャストコンテキストを通知します。 ARは、AR間コンテキスト転送にこれらのマルチキャストコンテキストオプションを使用します。
In predictive mode, the FBU is issued on the previous link and received by the PAR as displayed in Figure 2. The PAR will extract the multicast context options and append them to its HI message. From the HAck message, the PAR will redistribute the multicast acknowledgement by adding the corresponding mobility options to its Fast Binding ACK (FBack) message. From receiving the FBack message, the MN will learn about the multicast support for each group in the new access network. If some groups or multicast service models are not supported, it can decide to take actions to overcome a missing service (e.g., by tunneling). Note that the proactive multicast context transfer may proceed successfully, even if the MN misses the FBack message on the previous link.
予測モードでは、FBUは前のリンクで発行され、図2に示すようにPARによって受信されます。PARはマルチキャストコンテキストオプションを抽出し、それらをHIメッセージに追加します。 PARは、HAckメッセージから、対応するモビリティオプションをそのFast Binding ACK（FBack）メッセージに追加することにより、マルチキャスト確認を再配布します。 MNはFBackメッセージの受信から、新しいアクセスネットワークの各グループのマルチキャストサポートについて学習します。一部のグループまたはマルチキャストサービスモデルがサポートされていない場合、不足しているサービスを克服するためのアクションを実行することを決定できます（トンネリングなど）。 MNが前のリンクのFBackメッセージを逃した場合でも、プロアクティブマルチキャストコンテキスト転送が正常に進行する場合があることに注意してください。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HAck---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBack---|--FBack------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Multicast Handover for FMIPv6
図2：FMIPv6の予測マルチキャストハンドオーバー
The flow diagram for reactive mode is depicted in Figure 3. After attaching to the new access link and performing an Unsolicited Neighbor Advertisement (UNA), the MN issues an FBU that the NAR forwards to the PAR without processing. At this time, the MN is able to rejoin all subscribed multicast groups without relying on AR assistance. Nevertheless, multicast context options are exchanged in the HI/HAck dialog to facilitate intermediate forwarding of the requested multicast flows. The multicast traffic could arrive from an MN subscription at the same time that the NAR receives the HI message. Such multicast flows may be transparently excluded from forwarding by setting an appropriate Multicast Acknowledgement Option. In either case, to avoid duplication, the NAR MUST ensure that not more than one flow of the same group is forwarded to the MN.
リアクティブモードのフロー図を図3に示します。新しいアクセスリンクに接続し、Unsolicited Neighbor Advertisement（UNA）を実行した後、MNはNBUが処理せずにPARに転送するFBUを発行します。このとき、MNは、AR支援に依存することなく、サブスクライブされたすべてのマルチキャストグループに再参加できます。それにもかかわらず、要求されたマルチキャストフローの中間転送を容易にするために、マルチキャストコンテキストオプションがHI / HAckダイアログで交換されます。マルチキャストトラフィックは、NARがHIメッセージを受信すると同時にMNサブスクリプションから到着する可能性があります。このようなマルチキャストフローは、適切なマルチキャスト確認オプションを設定することにより、転送から透過的に除外できます。どちらの場合でも、重複を避けるために、NARは同じグループの複数のフローがMNに転送されないようにする必要があります。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HAck----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HAck if necessary)|
| | |
| FBack, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Multicast Handover for FMIPv6
図3：FMIPv6のリアクティブマルチキャストハンドオーバー
In a proxy mobile IPv6 environment, the MN remains agnostic of network layer changes, and fast handover procedures are operated by the access routers or MAGs to which MNs are connected via node-specific point-to-point links. The handover initiation, or the re-association, is managed by the access networks. Consequently, access routers need to be aware of multicast membership state at the Mobile Node. There are two ways to obtain the multicast membership of an MN.
プロキシモバイルIPv6環境では、MNはネットワークレイヤーの変更にとらわれず、MNがノード固有のポイントツーポイントリンクを介して接続されているアクセスルーターまたはMAGによって高速ハンドオーバー手順が実行されます。ハンドオーバーの開始または再アソシエーションは、アクセスネットワークによって管理されます。したがって、アクセスルータはモバイルノードでのマルチキャストメンバーシップの状態を認識する必要があります。 MNのマルチキャストメンバーシップを取得するには、2つの方法があります。
o MAGs may perform explicit tracking (see [RFC4605] and [RFC6224]) or extract membership status from forwarding states at node-specific links.
o MAGは明示的な追跡を実行するか（[RFC4605]および[RFC6224]を参照）、ノード固有のリンクで転送状態からメンバーシップステータスを抽出します。
o routers can issue a general MLD query at handovers. Both methods are equally applicable. However, a router that does not provide explicit membership tracking needs to query its downstream links after a handover. The MLD membership information then allows the PMAG to learn the multicast group subscriptions of the MN.
o ルーターは、ハンドオーバー時に一般的なMLDクエリを発行できます。どちらの方法も同様に適用できます。ただし、明示的なメンバーシップ追跡を提供しないルーターは、ハンドオーバー後にダウンストリームリンクを照会する必要があります。次に、MLDメンバーシップ情報により、PMAGはMNのマルチキャストグループサブスクリプションを学習できます。
In predictive mode, the PMAG will learn about the upcoming movement of the Mobile Node, including its new Access Point Identifier (New AP ID). Without explicit tracking, it will immediately submit a general MLD query and receive MLD reports indicating the multicast address listening state of the subscribed group(s). As displayed in Figure 4, it will initiate binding and context transfer with the NMAG by issuing a HI message that is augmented by multicast contexts in the mobility options defined in Section 5.3. NMAG will extract multicast context information and act as described in Section 3.1.
予測モードでは、PMAGは新しいアクセスポイント識別子（新しいAP ID）を含むモバイルノードの今後の動きについて学習します。明示的な追跡がなければ、一般的なMLDクエリがすぐに送信され、サブスクライブされたグループのマルチキャストアドレスリスニング状態を示すMLDレポートが受信されます。図4に示すように、セクション5.3で定義されているモビリティオプションのマルチキャストコンテキストによって拡張されたHIメッセージを発行することにより、NMAGとのバインディングおよびコンテキスト転送を開始します。 NMAGはマルチキャストコンテキスト情報を抽出し、セクション3.1で説明されているように動作します。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<----establishment----->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<========================================== deliver packets
| | | | |
Figure 4: Predictive Multicast Handover for PFMIPv6
図4：PFMIPv6の予測マルチキャストハンドオーバー
In reactive mode, the NMAG will learn the attachment of the MN to the N-AN and establish connectivity using the PMIPv6 protocol operations. However, it will have no knowledge about multicast state at the MN. Triggered by an MN attachment, the NMAG will send a general MLD query and thereafter join the groups for which it receives multicast listener report messages. In the case of a reactive handover, the binding is initiated by the NMAG, and the HI/HAck message semantic is inverted (see [RFC5949]). For multicast context transfer, the NMAG attaches to its HI message those group identifiers it requests to be forwarded from PMAG. Using the identical syntax in its Multicast Mobility Option headers, as defined in Section 5.4, the PMAG acknowledges the set of requested groups in a HAck answer, indicating the group(s) it is willing to forward. The corresponding call flow is displayed in Figure 5.
リアクティブモードでは、NMAGはN-ANへのMNの接続を学習し、PMIPv6プロトコル操作を使用して接続を確立します。ただし、MNでのマルチキャスト状態については認識されません。 MNアタッチメントによってトリガーされるNMAGは、一般的なMLDクエリを送信し、その後、マルチキャストリスナーレポートメッセージを受信するグループに参加します。リアクティブハンドオーバーの場合、バインディングはNMAGによって開始され、HI / HAckメッセージセマンティクスは逆になります（[RFC5949]を参照）。マルチキャストコンテキスト転送の場合、NMAGはPMAGからの転送を要求するグループ識別子をHIメッセージに添付します。セクション5.4で定義されているマルチキャストモビリティオプションヘッダーの同じ構文を使用して、PMAGは要求されたグループのセットをHAck応答で確認し、転送するグループを示します。対応するコールフローを図5に示します。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HAck----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
Figure 5: Reactive Multicast Handover for PFMIPv6
図5：PFMIPv6のリアクティブマルチキャストハンドオーバー
This section provides a normative definition of the protocol operations.
このセクションでは、プロトコル操作の規範的な定義を提供します。
A Mobile Node willing to manage multicast traffic by fast handover operations MUST transfer its MLD listener state records within fast handover negotiations.
高速ハンドオーバー操作によってマルチキャストトラフィックを管理しようとするモバイルノードは、高速ハンドオーバーネゴシエーション内でMLDリスナー状態レコードを転送する必要があります。
When sensing a handover in predictive mode, an MN MUST build a Multicast Mobility Option, as described in Section 5.3, that contains the MLD or IGMP multicast listener state and append it to the Fast Binding Update (FBU) prior to signaling with PAR.
予測モードでハンドオーバーを感知する場合、MNはセクション5.3で説明されているように、MLDまたはIGMPマルチキャストリスナーの状態を含むマルチキャストモビリティオプションを構築し、PARでシグナリングする前に高速バインディング更新（FBU）に追加する必要があります。
The MN will receive the Multicast Acknowledgement Option(s) as a part of the Fast Binding Acknowledge (FBack) (see Section 5.4) and learn about unsupported or prohibited groups at the NAR. The MN MAY take appropriate actions such as home tunneling to enable reception of groups that are not available via the NAR. Beyond standard FMIPv6 signaling, no multicast-specific operation is required by the MN when reattaching in the new network.
MNは、Fast Binding Acknowledge（FBack）（セクション5.4を参照）の一部としてマルチキャスト確認オプションを受け取り、NARでサポートされていないグループまたは禁止されているグループについて学習します。 MNは、ホームトンネリングなどの適切なアクションを実行して、NARを介して利用できないグループの受信を可能にする場合があります。標準のFMIPv6シグナリングを超えて、新しいネットワークに再接続するときに、MNはマルチキャスト固有の操作を必要としません。
In reactive mode, the MN MUST append the identical Multicast Mobility Option to the FBU sent after its reconnect. In response, it will learn about the Multicast Acknowledgement Option(s) from the FBack and expect corresponding multicast data. Concurrently, it joins all subscribed multicast groups directly on its newly established access link.
リアクティブモードでは、MNは再接続後に送信されるFBUに同じマルチキャストモビリティオプションを追加する必要があります。応答として、FBackからマルチキャスト確認オプションについて学習し、対応するマルチキャストデータを期待します。同時に、加入しているすべてのマルチキャストグループに、新しく確立されたアクセスリンクに直接参加します。
A PAR that supports multicast advertises that support by setting the 'M' bit in the Proxy Router Advertisement (PrRtAdv) message, as specified in Section 5.1 of this document. This indicator exclusively informs the MNs about the capability of the PAR to process and exchange Multicast Mobility Options during fast handover operations.
このドキュメントのセクション5.1で指定されているように、プロキシルーターアドバタイズ（PrRtAdv）メッセージで「M」ビットを設定することでサポートするマルチキャストアドバタイズをサポートするPAR。このインジケータは、高速のハンドオーバ操作中にマルチキャストモビリティオプションを処理および交換するPARの機能について、MNに排他的に通知します。
In predictive mode, a PAR will receive the multicast listener state of an MN prior to handover from the Multicast Mobility Option appended to the FBU. It forwards these records to the NAR within HI messages and will expect Multicast Acknowledgement Option(s) in a HAck, which is itself returned to the MN as an appendix to the FBack. In performing the multicast context exchange, the PAR is instructed to include the PAR-to-NAR tunnel obtained from unicast handover management in its multicast downstream interfaces and awaits reception of multicast listener report messages from the NAR. In response to receiving multicast subscriptions, the PAR SHOULD forward group data acting as a regular multicast router or proxy. However, the PAR MAY refuse to forward some or all of the multicast flows (e.g., due to administrative configurations or load conditions).
予測モードでは、PARは、FBUに追加されたマルチキャストモビリティオプションからのハンドオーバーの前に、MNのマルチキャストリスナー状態を受信します。これらのレコードをHIメッセージ内でNARに転送し、HAck内のマルチキャスト確認オプションを期待します。これは、FBackの付録としてそれ自体がMNに返されます。マルチキャストコンテキスト交換の実行時に、PARはユニキャストハンドオーバー管理から取得したPARからNARへのトンネルをマルチキャストダウンストリームインターフェイスに含めるように指示され、NARからのマルチキャストリスナーレポートメッセージの受信を待ちます。マルチキャストサブスクリプションの受信に応答して、PARは通常のマルチキャストルーターまたはプロキシとして機能するグループデータを転送する必要があります（SHOULD）。ただし、PARはマルチキャストフローの一部またはすべてを転送することを拒否する場合があります（たとえば、管理構成または負荷条件のため）。
In reactive mode, the PAR will receive the FBU augmented by the Multicast Mobility Option from the new network but continues with an identical multicast record exchange in the HI/HAck dialog. As in the predictive case, it configures the PAR-to-NAR tunnel for the multicast downstream. It then (if capable) forwards data according to the group membership indicated in the multicast listener report messages received from NAR.
リアクティブモードでは、PARは新しいネットワークからマルチキャストモビリティオプションによって拡張されたFBUを受信しますが、HI / HAckダイアログで同じマルチキャストレコード交換を続行します。予測の場合と同様に、マルチキャストダウンストリームのPARからNARへのトンネルを構成します。次に、（可能であれば）NARから受信したマルチキャストリスナーレポートメッセージに示されているグループメンバーシップに従ってデータを転送します。
In both modes, the PAR MUST interpret the first of the two events -- the departure of the MN or the reception of the Multicast Acknowledgement Option(s) -- as if the MN had sent a multicast LEAVE message and react according to the signaling scheme deployed in the access network (i.e., MLD querying, explicit tracking).
両方のモードで、PARは2つのイベントの最初のイベント（MNの離脱またはマルチキャスト確認オプションの受信）を解釈しなければなりません（MNがマルチキャストLEAVEメッセージを送信し、シグナリングに従って反応したかのように）アクセスネットワークに配置されたスキーム（つまり、MLDクエリ、明示的な追跡）。
A NAR that supports multicast advertises that support by setting the 'M' bit in PrRtAdv as specified in Section 5.1 of this document. This indicator exclusively serves the purpose of informing MNs about the capability of the NAR to process and exchange Multicast Mobility Options during fast handover operations.
このドキュメントのセクション5.1で指定されているように、PrRtAdvの「M」ビットを設定することでサポートするマルチキャストアドバタイズをサポートするNAR。このインジケータは、高速ハンドオーバー操作中にマルチキャストモビリティオプションを処理および交換するNARの機能についてMNに通知する目的のみを果たします。
In predictive mode, a NAR will receive the multicast listener state of an expected MN from the Multicast Mobility Option appended to the HI message. It will extract the multicast group membership records from the message and match the request subscription with its multicast service offer. Further on, it will join the requested groups using a downstream loopback interface. This will lead to suitable regular subscriptions to a native multicast upstream interface without additional forwarding. Concurrently, the NAR builds a Multicast Acknowledgement Option(s) (see Section 5.4) listing the set of groups that are unsupported on the new access link and returns this list within a HAck. As soon as there is an operational bidirectional tunnel from the PAR to NAR, the NAR joins the groups requested by the MN, which are then forwarded by the PAR using the tunnel link.
予測モードでは、NARは、予想されるMNのマルチキャストリスナー状態を、HIメッセージに追加されたマルチキャストモビリティオプションから受信します。メッセージからマルチキャストグループメンバーシップレコードを抽出し、要求サブスクリプションをマルチキャストサービスオファーと照合します。さらに、ダウンストリームループバックインターフェイスを使用して、要求されたグループに参加します。これにより、追加の転送なしで、ネイティブマルチキャストアップストリームインターフェイスへの適切な定期サブスクリプションが作成されます。同時に、NARはマルチキャスト確認オプション（セクション5.4を参照）を作成し、新しいアクセスリンクでサポートされていないグループのセットをリストして、このリストをHAck内で返します。 PARからNARへの動作可能な双方向トンネルができるとすぐに、NARはMNによって要求されたグループに参加し、トンネルリンクを使用してPARによって転送されます。
In reactive mode, the NAR will learn about the multicast listener state of a new MN from the Multicast Mobility Option appended to each HI message after the MN has already performed local subscriptions of the multicast service. Thus, the NAR solely determines the intersection of requested and supported groups and issues a join request for each group forwarding this on the PAR-NAR tunnel interface.
リアクティブモードでは、NARは、MNがマルチキャストサービスのローカルサブスクリプションをすでに実行した後に、各HIメッセージに追加されたMulticast Mobility Optionから新しいMNのマルチキャストリスナー状態について学習します。したがって、NARは要求されたグループとサポートされたグループの共通部分のみを決定し、PAR-NARトンネルインターフェイスでこれを転送する各グループに参加要求を発行します。
In both modes, the NAR MUST send a LEAVE message to the tunnel when it is no longer needed to forward a group, e.g., after arrival of native multicast traffic or termination of a group membership from the MN. Although the message can be delayed, immediately sending the LEAVE message eliminates the need for the PAR and NAR to process traffic that is not to be forwarded.
どちらのモードでも、NARは、たとえばネイティブマルチキャストトラフィックの到着後やMNからのグループメンバーシップの終了後など、グループを転送する必要がなくなったときにLEAVEメッセージをトンネルに送信する必要があります。メッセージは遅延する可能性がありますが、LEAVEメッセージをすぐに送信すると、PARおよびNARが転送されないトラフィックを処理する必要がなくなります。
Multicast packets may be lost during handover. For example, in predictive mode, as illustrated by Figure 2, packets may be lost while the MN is -- already or still -- detached from the networks, even though they are forwarded to the NAR. In reactive mode as illustrated by Figure 3, the situation may be worse, since there will be a delay before joining the multicast group after the MN reattaches to the NAR. Multicast packets cannot be delivered during this time. Buffering the multicast packets at the PAR can reduce multicast packet loss but may then increase resource consumption and delay in packet transmission. Implementors should balance the different requirements in the context of predominant application demands (e.g., real-time requirements or loss sensitivity).
マルチキャストパケットは、ハンドオーバー中に失われる可能性があります。たとえば、予測モードでは、図2に示すように、たとえNARに転送されていても、MNが（既にまたはまだ）ネットワークから切り離されている間、パケットが失われる可能性があります。図3に示すように、リアクティブモードでは、MNがNARに再接続してからマルチキャストグループに参加するまでに遅延が生じるため、状況は悪化する可能性があります。この間、マルチキャストパケットは配信できません。 PARでマルチキャストパケットをバッファリングすると、マルチキャストパケットの損失を減らすことができますが、リソースの消費とパケット送信の遅延が増える可能性があります。実装者は、主なアプリケーション要求（リアルタイムの要件や損失感度など）のコンテキストでさまざまな要件のバランスをとる必要があります。
A Mobile Node willing to participate in multicast traffic will join, maintain, and leave groups as if located in the fixed Internet. It will cooperate in handover indication as specified in [RFC5949] and required by its access link-layer technology. No multicast-specific mobility actions nor implementations are required at the MN in a PMIPv6 domain.
マルチキャストトラフィックに参加するモバイルノードは、固定インターネットに配置されているかのように、グループに参加、維持、および脱退します。 [RFC5949]で指定され、そのアクセスリンク層テクノロジーで必要とされるハンドオーバー指示に協力します。 PMIPv6ドメインのMNでは、マルチキャスト固有のモビリティアクションも実装も必要ありません。
A MAG receiving a handover indication for one of its MNs follows the same predictive fast handover mode as a PMAG. It MUST issue an MLD General Query immediately on its corresponding link unless it performs explicit membership tracking on that link. After knowledge of the multicast subscriptions of the MN is acquired, the PMAG builds a Multicast Mobility Option, as described in Section 5.3, that contains the MLD and IGMP multicast listener state. If not empty, this Mobility Option is appended to the regular fast handover HI messages. In the case when a unicast HI message is submitted prior to multicast state detection, the multicast listener state is sent in an additional HI message to the NMAG.
そのMNの1つに対するハンドオーバー指示を受信するMAGは、PMAGと同じ予測高速ハンドオーバーモードに従います。そのリンクで明示的なメンバーシップ追跡を実行しない限り、対応するリンクですぐにMLD General Queryを発行する必要があります。 MNのマルチキャストサブスクリプションの知識が得られた後、PMAGは、セクション5.3で説明されているように、MLDおよびIGMPマルチキャストリスナーの状態を含むマルチキャストモビリティオプションを構築します。空でない場合、このモビリティオプションは通常の高速ハンドオーバーHIメッセージに追加されます。マルチキャスト状態検出の前にユニキャストHIメッセージが送信された場合、マルチキャストリスナー状態が追加のHIメッセージでNMAGに送信されます。
The PMAG then waits until it receives the Multicast Acknowledgement Option(s) with a HAck message (see Section 5.4) and the bidirectional tunnel with the NMAG is created. After the HAck message is received, the PMAG adds the tunnel to its downstream interfaces in the multicast forwarding database. For those groups reported in the Multicast Acknowledgement Option(s), i.e., not supported in the new access network, the PMAG normally takes appropriate actions (e.g., forwarding and termination) according to the network policy. It SHOULD start forwarding multicast traffic down the tunnel interface for the groups indicated in the multicast listener reports received from NMAG. However, it MAY deny forwarding some or all groups included in the multicast listener reports (e.g., due to administrative configurations or load conditions).
次にPMAGは、HAckメッセージ（セクション5.4を参照）でマルチキャスト確認オプションを受信し、NMAGとの双方向トンネルが作成されるまで待機します。 HAckメッセージを受信した後、PMAGはマルチキャスト転送データベースのダウンストリームインターフェイスにトンネルを追加します。マルチキャスト確認オプションで報告されたグループ、つまり新しいアクセスネットワークでサポートされていないグループの場合、PMAGは通常、ネットワークポリシーに従って適切なアクション（転送や終了など）を実行します。 NMAGから受信したマルチキャストリスナーレポートに示されているグループのトンネルインターフェイスを介してマルチキャストトラフィックの転送を開始する必要があります。ただし、マルチキャストリスナーレポートに含まれている一部またはすべてのグループの転送を拒否する場合があります（たとえば、管理構成または負荷の条件により）。
After the departure of the MN and on the reception of a LEAVE message, it is RECOMMENDED that the PMAG terminates forwarding of the specified groups and updates its multicast forwarding database. It correspondingly sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link.
MNの出発後、LEAVEメッセージの受信時に、PMAGが指定されたグループの転送を終了し、そのマルチキャスト転送データベースを更新することをお勧めします。対応して、ダウンストリームリンク上にアクティブなリスナーがなくなったグループのアップストリームリンクにLEAVEメッセージを送信します。
A MAG receiving a HI message with the Multicast Mobility Option for a currently attached node follows the reactive fast handover mode as a PMAG. It will return a Multicast Acknowledgement Option(s) (see Section 5.4) within a HAck message listing the groups for which it does not provide forwarding support to the NMAG. It will add the bidirectional tunnel with NMAG to its downstream interfaces and will start forwarding multicast traffic for the groups listed in the multicast listener report messages from the NMAG. On reception of a LEAVE message for a group, the PMAG terminates forwarding for the specific group and updates its multicast forwarding database. According to its multicast forwarding state, it sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link.
現在接続されているノードのマルチキャストモビリティオプションを含むHIメッセージを受信するMAGは、PMAGとしてリアクティブ高速ハンドオーバーモードに従います。 NMAGへの転送サポートを提供しないグループをリストするHAckメッセージ内でマルチキャスト確認オプション（5.4を参照）を返します。 NMAGの双方向トンネルをダウンストリームインターフェイスに追加し、NMAGからのマルチキャストリスナーレポートメッセージにリストされているグループのマルチキャストトラフィックの転送を開始します。グループのLEAVEメッセージを受信すると、PMAGは特定のグループの転送を終了し、マルチキャスト転送データベースを更新します。マルチキャスト転送状態に応じて、ダウンストリームリンクにアクティブなリスナーがなくなったグループのアップストリームリンクにLEAVEメッセージを送信します。
In both modes, the PMAG will interpret the departure of the MN as a multicast LEAVE message of the MN and react according to the signaling scheme deployed in the access network (i.e., MLD querying and explicit tracking).
両方のモードで、PMAGはMNの離脱をMNのマルチキャストLEAVEメッセージとして解釈し、アクセスネットワークに展開されたシグナリングスキーム（つまり、MLDクエリと明示的な追跡）に従って反応します。
A MAG receiving a HI message with a Multicast Mobility Option for a currently unattached node follows the same predictive fast handover mode as an NMAG. It will decide the multicast groups to be forwarded from the PMAG and build a Multicast Acknowledgement Option (see Section 5.4) that enumerates only unwanted groups. This Mobility Option is appended to the regular fast handover HAck messages or, in the case of a unicast HAck message being submitted prior to multicast state acknowledgement, sent in an additional HAck message to the PMAG. Immediately thereafter, the NMAG SHOULD update its MLD membership state based on the membership reported in the Multicast Mobility Option. Until the MN reattaches, the NMAG uses its Loopback interface for downstream and MUST NOT forward traffic to the potential link of the MN. The NMAG SHOULD issue JOIN messages for those newly selected groups to its regular multicast upstream interface. As soon as the bidirectional tunnel with PMAG is established, the NMAG additionally joins those groups on the tunnel interface requested to be forwarded from the PMAG.
現在接続されていないノードのマルチキャストモビリティオプションを含むHIメッセージを受信するMAGは、NMAGと同じ予測高速ハンドオーバーモードに従います。 PMAGから転送されるマルチキャストグループを決定し、不要なグループのみを列挙するマルチキャスト確認オプション（セクション5.4を参照）を構築します。このモビリティオプションは、通常の高速ハンドオーバーHAckメッセージに追加されるか、ユニキャストHAckメッセージがマルチキャスト状態確認応答の前に送信された場合、追加のHAckメッセージでPMAGに送信されます。その後すぐに、NMAGは、マルチキャストモビリティオプションで報告されたメンバーシップに基づいて、MLDメンバーシップの状態を更新する必要があります（SHOULD）。 MNが再接続するまで、NMAGはダウンストリームにループバックインターフェイスを使用し、MNの潜在的なリンクにトラフィックを転送してはなりません。 NMAGは、新しく選択されたグループのJOINメッセージを通常のマルチキャストアップストリームインターフェースに発行する必要があります（SHOULD）。 PMAGとの双方向トンネルが確立されるとすぐに、NMAGは、PMAGからの転送を要求されたトンネルインターフェース上のグループに追加で参加します。
A MAG experiencing a connection request for an MN without prior reception of a corresponding Multicast Mobility Option is operating in the reactive fast handover mode as an NMAG. Following the reattachment, it SHOULD immediately issue an MLD General Query to learn about multicast subscriptions of the newly arrived MN. Using standard multicast operations, the NMAG joins groups not currently forwarded using its regular multicast upstream interface. Concurrently, it selects groups for forwarding from PMAG and builds a Multicast Mobility Option, as described in Section 5.3, that contains the multicast listener state. If not empty, this Mobility Option is appended to the regular fast handover HI messages with the F flag set or, in the case of unicast HI message being submitted prior to multicast state detection, sent in an additional HI message to the PMAG. Upon reception of the Multicast Acknowledgement Option and establishment of the bidirectional tunnel, the NMAG additionally joins the set of groups on the tunnel interface that it wishes to receive by forwarding from the PMAG. When multicast flows arrive, the NMAG forwards data to the appropriate downlink(s).
対応するマルチキャストモビリティオプションを事前に受信せずにMNの接続要求を経験しているMAGは、NMAGとしてリアクティブ高速ハンドオーバーモードで動作しています。再接続後、すぐにMLD General Queryを発行して、新しく到着したMNのマルチキャストサブスクリプションについて学習する必要があります（SHOULD）。 NMAGは標準のマルチキャスト操作を使用して、通常のマルチキャストアップストリームインターフェイスを使用して現在転送されていないグループに参加します。同時に、PMAGから転送するグループを選択し、セクション5.3で説明されているように、マルチキャストリスナー状態を含むマルチキャストモビリティオプションを構築します。空でない場合、このモビリティオプションはFフラグが設定された通常の高速ハンドオーバーHIメッセージに追加されるか、ユニキャストHIメッセージがマルチキャスト状態検出の前に送信された場合、追加のHIメッセージでPMAGに送信されます。 Multicast Acknowledgement Optionの受信と双方向トンネルの確立時に、NMAGはさらに、PMAGから転送することで受信したいトンネルインターフェイス上のグループのセットに参加します。マルチキャストフローが到着すると、NMAGは適切なダウンリンクにデータを転送します。
In both modes, the NMAG MUST send a LEAVE message to the tunnel when forwarding of a group is no longer needed, e.g., after native multicast traffic arrives or group membership of the MN terminates. Although the message can be delayed, immediately sending the LEAVE message eliminates the need for PAR and NAR to process traffic that is not to be forwarded.
どちらのモードでも、ネイティブマルチキャストトラフィックが到着した後やMNのグループメンバーシップが終了した後など、グループの転送が不要になったときに、NMAGはトンネルにLEAVEメッセージを送信する必要があります。メッセージは遅延する可能性がありますが、LEAVEメッセージをすぐに送信することで、PARおよびNARが転送されないトラフィックを処理する必要がなくなります。
An MN in a PMIPv6 domain MAY use an IPv4 address transparently for communication, as specified in [RFC5844]. For this purpose, Local Mobility Anchors (LMAs) can register IPv4-Proxy-CoAs in its binding caches, and MAGs can provide IPv4 support in access networks. Correspondingly, multicast membership management will be performed by the MN using IGMP. For multiprotocol multicast support on the network side, IGMPv3 router functions are required at both MAGs (see Section 5.6 for compatibility considerations with previous IGMP versions). Context transfer between MAGs can transparently proceed in the HI/HAck message exchanges by encapsulating IGMP multicast state records within Multicast Mobility Options (see Sections 5.3 and 5.4 for details on message formats).
[RFC5844]で指定されているように、PMIPv6ドメインのMNは、通信にIPv4アドレスを透過的に使用する場合があります。この目的のために、ローカルモビリティアンカー（LMA）はそのバインディングキャッシュにIPv4-Proxy-CoAを登録でき、MAGはアクセスネットワークでIPv4サポートを提供できます。同様に、マルチキャストメンバーシップ管理は、IGMPを使用してMNによって実行されます。ネットワーク側でマルチプロトコルマルチキャストをサポートするには、両方のMAGでIGMPv3ルーター機能が必要です（以前のIGMPバージョンとの互換性に関する考慮事項については、セクション5.6を参照してください）。 MAG間のコンテキスト転送は、マルチキャストモビリティオプション内でIGMPマルチキャストステートレコードをカプセル化することにより、HI / HAckメッセージ交換で透過的に続行できます（メッセージフォーマットの詳細については、セクション5.3および5.4を参照）。
The deployment of IPv4 multicast support SHOULD be homogeneous across a PMIP domain. This avoids multicast service breaks during handovers.
IPv4マルチキャストサポートの展開は、PMIPドメイン全体で均一である必要があります（SHOULD）。これにより、ハンドオーバー中のマルチキャストサービスの中断が回避されます。
It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access network and the use of Generic Routing Encapsulation (GRE) tunneling as specified in [RFC5845]. Corresponding implications and operations are discussed in the PMIP Multicast Base Deployment document (see [RFC6224]).
デュアルスタックIPv4 / IPv6アクセスネットワークのシナリオと、[RFC5845]で指定されているGeneric Routing Encapsulation（GRE）トンネリングの使用について言及する価値があります。対応する影響と操作は、PMIPマルチキャストベース展開ドキュメント（[RFC6224]を参照）で説明されています。
This document updates the Proxy Router Advertisements (PrRtAdv) message format defined in Section 6.1.2 of [RFC5568]. The update assigns the first bit of the Reserved field to carry the 'M' bit, as defined in Figure 6. An FMIPv6 AR indicates support for multicast by setting the 'M' bit to a value of 1.
このドキュメントは、[RFC5568]のセクション6.1.2で定義されているプロキシルーターアドバタイズメント（PrRtAdv）メッセージフォーマットを更新します。この更新では、図6で定義されているように、予約フィールドの最初のビットを割り当てて「M」ビットを伝送します。FMIPv6ARは、「M」ビットを値1に設定することでマルチキャストのサポートを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Multicast Indicator Bit for Proxy Router Advertisement (PrRtAdv) Message
図6：プロキシルーターアドバタイズ（PrRtAdv）メッセージのマルチキャストインジケータービット
This document updates the Reserved field to include the 'M' bit. It is specified as follows.
このドキュメントでは、予約フィールドを更新して「M」ビットを含めています。以下のように指定します。
M = 1 indicates that the specifications of this document apply.
M = 1は、このドキュメントの仕様が適用されることを示します。
M = 0 indicates that the behavior during fast handover proceeds according to [RFC5568].
M = 0は、高速ハンドオーバー中の動作が[RFC5568]に従って進行することを示します。
The default value (0) of this bit indicates a non-multicast-capable service.
このビットのデフォルト値（0）は、非マルチキャスト対応サービスを示します。
The fast handover protocols use an IPv6 header type called Mobility Header, as defined in [RFC6275]. Mobility Headers can carry variable Mobility Options.
高速ハンドオーバープロトコルは、[RFC6275]で定義されているように、モビリティヘッダーと呼ばれるIPv6ヘッダータイプを使用します。モビリティヘッダーは、さまざまなモビリティオプションを伝送できます。
The multicast listener context of an MN is transferred in fast handover operations from PAR/PMAG to NAR/NMAG within a new Multicast Mobility Option and MUST be acknowledged by a corresponding Multicast Acknowledgement Option. Depending on the specific handover scenario and protocol in use, the corresponding option is included within the mobility option list of HI/HAck only (PFMIPv6) or of FBU/FBack/HI/ HAck (FMIPv6).
MNのマルチキャストリスナーコンテキストは、新しいハンドオーバモビリティオプション内でPAR / PMAGからNAR / NMAGへの高速ハンドオーバー操作で転送され、対応するマルチキャスト確認オプションで確認する必要があります。特定のハンドオーバーシナリオと使用中のプロトコルに応じて、対応するオプションは、HI / HAckのみ（PFMIPv6）またはFBU / FBack / HI / HAck（FMIPv6）のモビリティオプションリストに含まれます。
This section defines the Multicast Mobility Option. It contains the current listener state record of the MN obtained from the MLD Multicast Listener Report message and has the format displayed in Figure 7.
このセクションでは、マルチキャストモビリティオプションを定義します。これには、MLDマルチキャストリスナーレポートメッセージから取得されたMNの現在のリスナー状態レコードが含まれ、図7に表示されているフォーマットを持っています。
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 | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Mobility Header Multicast Option
図7：モビリティヘッダーマルチキャストオプション
Type: 60
タイプ：60
Length: 8-bit unsigned integer. The length of this option in 32-bit words, not including the Type, Length, Option-Code, and Reserved fields.
長さ：8ビットの符号なし整数。 Type、Length、Option-Code、およびReservedフィールドを含まない、32ビットワードでのこのオプションの長さ。
Option-Code:
オプションコード：
1: IGMPv3 Payload Type
1：IGMPv3ペイロードタイプ
2: MLDv2 Payload Type
2：MLDv2ペイロードタイプ
3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode
3：IGMPv2互換モードからのIGMPv3ペイロードタイプ
4: MLDv2 Payload Type from MLDv1 Compatibility Mode
4：MLDv1互換モードからのMLDv2ペイロードタイプ
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
予約済み：送信者はゼロに設定する必要があり、受信者は無視する必要があります。
MLD or IGMP Report Payload: This field is composed of the Membership Report message after stripping its ICMP header. This Report Payload always contains an integer number of multicast records. Corresponding message formats are defined for MLDv2 in [RFC3810] and for IGMPv3 in [RFC3376]. This field MUST always contain the first header line (Reserved field and No of Mcast Address Records).
MLDまたはIGMPレポートペイロード：このフィールドは、ICMPヘッダーを取り除いた後のメンバーシップレポートメッセージで構成されます。このレポートペイロードには、常に整数のマルチキャストレコードが含まれています。対応するメッセージ形式は、[RFC3810]のMLDv2と[RFC3376]のIGMPv3で定義されています。このフィールドには、常に最初のヘッダー行が含まれている必要があります（予約済みフィールドおよびNo of Mcast Address Records）。
Figure 8 shows the Report Payload for MLDv2 (see Section 5.2 of [RFC3810] for the definition of Multicast Address Records). When IGMPv3 is used, the payload format is defined according to IGMPv3 Group Records (see Section 4.2 of [RFC3376] for the definition of Group Records).
図8は、MLDv2のレポートペイロードを示しています（マルチキャストアドレスレコードの定義については、[RFC3810]のセクション5.2を参照してください）。 IGMPv3が使用される場合、ペイロード形式はIGMPv3グループレコードに従って定義されます（グループレコードの定義については、[RFC3376]のセクション4.2を参照してください）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MLDv2 Report Payload
図8：MLDv2レポートのペイロード
The Multicast Acknowledgement Option reports the status of the context transfer and contains the list of state records that could not be successfully transferred to the next access network. It has the format displayed in Figure 9.
Multicast Acknowledgement Optionは、コンテキスト転送のステータスを報告し、次のアクセスネットワークに正常に転送できなかった状態レコードのリストを含みます。これは、図9に表示されている形式です。
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 | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Mobility Header Multicast Acknowledgement Option
図9：モビリティヘッダーのマルチキャスト確認オプション
Type: 61
タイプ：61
Length: 8-bit unsigned integer. The length of this option in 32-bit words, not including the Type, Length, Option-Code, and Status fields.
長さ：8ビットの符号なし整数。タイプ、長さ、オプションコード、ステータスフィールドを含まない、32ビットワードでのこのオプションの長さ。
Option-Code: 0
オプションコード：0
Status:
状態：
1: Report Payload type unsupported
1：サポートされていないペイロードタイプのレポート
2: Requested group service unsupported
2：要求されたグループサービスはサポートされていません
3: Requested group service administratively prohibited
3：要求されたグループサービスは管理上禁止されています
MLD or IGMP Unsupported Report Payload: This field is syntactically identical to the MLD and IGMP Report Payload field described in Section 5.3 but is only composed of those Multicast Address Records that are not supported or prohibited in the new access network. This field MUST always contain the first header line (Reserved field and No of Mcast Address Records) but MUST NOT contain any Mcast Address Records if the status code equals 1.
MLDまたはIGMPのサポートされていないレポートペイロード：このフィールドは、セクション5.3で説明されているMLDおよびIGMPレポートのペイロードフィールドと構文的に同じですが、新しいアクセスネットワークでサポートまたは禁止されていないマルチキャストアドレスレコードのみで構成されています。このフィールドには常に最初のヘッダー行（予約済みフィールドとNo of Mcast Address Records）が含まれている必要がありますが、ステータスコードが1の場合は、Mcast Address Recordsが含まれていてはなりません。
Note that group subscriptions to specific sources may be rejected at the destination network; thus, the composition of multicast address records may differ from initial requests within an MLD or IGMP Report Payload option.
特定のソースへのグループサブスクリプションは、宛先ネットワークで拒否される場合があることに注意してください。したがって、マルチキャストアドレスレコードの構成は、MLDまたはIGMPレポートペイロードオプション内の最初の要求とは異なる場合があります。
Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs impose length restrictions on multicast context records due to the 8-bit Length field. The maximal payload length available in FBU/ FBack messages is 4 octets (Mobility Option header line) + 1024 octets (MLD Report Payload). For example, not more than 51 Multicast Address Records of minimal length (without source states) may be exchanged in one message pair. In typical handover scenarios, this number reduces further according to unicast context and Binding Authorization data. A larger number of MLD reports that exceeds the available payload size MAY be sent within multiple HI/HAck or FBU/ FBack message pairs. In PFMIPv6, context information can be fragmented over several HI/HAck messages. However, a single MLDv2 Report Payload MUST NOT be fragmented. Hence, for a single Multicast Address Record, the number of source addresses (S,.) is limited to 62.
HI / HAckおよびFBU / FBackダイアログで交換されるモビリティヘッダーメッセージは、8ビットの長さフィールドにより、マルチキャストコンテキストレコードに長さ制限を課します。 FBU / FBackメッセージで使用可能な最大ペイロード長は、4オクテット（モビリティオプションヘッダー行）+ 1024オクテット（MLDレポートペイロード）です。たとえば、最短の長さ（ソース状態なし）の51以下のマルチキャストアドレスレコードを1つのメッセージペアで交換できます。通常のハンドオーバーシナリオでは、この数はユニキャストコンテキストとバインディング認証データに従ってさらに減少します。利用可能なペイロードサイズを超える多数のMLDレポートが、複数のHI / HAckまたはFBU / FBackメッセージペア内で送信される場合があります。 PFMIPv6では、コンテキスト情報を複数のHI / HAckメッセージにフラグメント化できます。ただし、単一のMLDv2レポートペイロードはフラグメント化しないでください。したがって、単一のマルチキャストアドレスレコードの場合、送信元アドレス（S ,.）の数は62に制限されます。
Access routers (MAGs) MUST support MLDv2 and IGMPv3. To enable multicast service for MLDv1 and IGMPv2 listeners, the routers MUST follow the interoperability rules defined in [RFC3810] and [RFC3376] and appropriately set the Multicast Address Compatibility Mode.
アクセスルーター（MAG）はMLDv2およびIGMPv3をサポートする必要があります。 MLDv1リスナーとIGMPv2リスナーのマルチキャストサービスを有効にするには、ルーターは[RFC3810]と[RFC3376]で定義された相互運用性ルールに従い、マルチキャストアドレス互換モードを適切に設定する必要があります。
When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a router internally translates the subsequent MLDv1 and IGMPv2 messages for that multicast address to their MLDv2 and IGMPv3 equivalents and uses these messages in the context transfer. The current state of Compatibility Mode is translated into the code of the Multicast Mobility Option, as defined in Section 5.3. A NAR (NMAG) receiving a Multicast Mobility Option during handover will switch to the lowest level of MLD and IGMP Compatibility Mode that it learned from its previous and new option values. This minimal compatibility agreement is used to allow for continued operation.
マルチキャストアドレス互換モードがMLDv1またはIGMPv2の場合、ルーターは内部でそのマルチキャストアドレスの後続のMLDv1およびIGMPv2メッセージをMLDv2およびIGMPv3の同等のメッセージに変換し、コンテキスト転送でこれらのメッセージを使用します。互換モードの現在の状態は、セクション5.3で定義されているように、マルチキャストモビリティオプションのコードに変換されます。ハンドオーバー中にマルチキャストモビリティオプションを受信するNAR（NMAG）は、以前のオプション値と新しいオプション値から学習したMLDおよびIGMP互換モードの最低レベルに切り替えます。この最小限の互換性合意は、継続的な運用を可能にするために使用されます。
Security vulnerabilities that exceed issues discussed in the base protocols mentioned in this document ([RFC5568], [RFC5949], [RFC3810], and [RFC3376]) are identified as follows.
このドキュメントで言及されている基本プロトコル（[RFC5568]、[RFC5949]、[RFC3810]、および[RFC3376]）で説明されている問題を超えるセキュリティの脆弱性は、次のように識別されます。
Multicast context transfer at predictive handovers implements group states at remote access routers and may lead to group subscriptions without further validation of the multicast service requests. Thereby, a NAR (NMAG) is requested to cooperate in potentially complex multicast rerouting and may receive large volumes of traffic. Malicious or inadvertent multicast context transfers may result in a significant burden of route establishment and traffic management onto the backbone infrastructure and the access router itself. Rapid rerouting or traffic overload can be mitigated by a rate control at the AR that restricts the frequency of traffic redirects and the total number of subscriptions. In addition, the wireless access network remains protected from multicast data injection until the requesting MN attaches to the new location.
予測的ハンドオーバーでのマルチキャストコンテキスト転送は、リモートアクセスルータでグループステートを実装し、マルチキャストサービスリクエストをさらに検証することなくグループサブスクリプションにつながる可能性があります。それにより、NAR（NMAG）は、潜在的に複雑なマルチキャストルーティングに協力するように要求され、大量のトラフィックを受信する可能性があります。悪意のある、または不注意によるマルチキャストコンテキスト転送は、ルートの確立とバックボーンインフラストラクチャおよびアクセスルータ自体へのトラフィック管理に大きな負担をかける可能性があります。トラフィックのリダイレクトの頻度とサブスクリプションの総数を制限するARでのレート制御により、迅速な再ルーティングまたはトラフィックの過負荷を軽減できます。さらに、ワイヤレスアクセスネットワークは、要求元のMNが新しい場所に接続するまで、マルチキャストデータインジェクションから保護されたままです。
This document defines two new mobility options that have been allocated from the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters>:
このドキュメントでは、<http://www.iana.org/assignments/mobility-parameters>の「モビリティオプション」レジストリから割り当てられた2つの新しいモビリティオプションを定義しています。
60 Multicast Mobility Option, described in Section 5.3
セクション5.3で説明されている60マルチキャストモビリティオプション
61 Multicast Acknowledgement Option, described in Section 5.4
61マルチキャスト確認オプション、セクション5.4で説明
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「Mobility Support in IPv6」、RFC 6275、2011年7月、<http://www.rfc-editor.org/info/rfc6275>。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、August 2008、<http：//www.rfc-editor .org / info / rfc5213>。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009, <http://www.rfc-editor.org/info/rfc5568>.
[RFC5568] Koodli、R。、「Mobile IPv6 Fast Handovers」、RFC 5568、2009年7月、<http://www.rfc-editor.org/info/rfc5568>。
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010, <http://www.rfc-editor.org/info/rfc5949>.
[RFC5949]横田浩司、チョウドリーK.、クードリR.、パティルB.、およびF.シア、「プロキシモバイルIPv6の高速ハンドオーバー」、RFC 5949、2010年9月、<http：// www。 rfc-editor.org/info/rfc5949>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"） "、RFC 4605、2006年8月、<http://www.rfc-editor.org/info/rfc4605>。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月、<http://www.rfc-editor.org/info/rfc3810>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月、<http：// www .rfc-editor.org / info / rfc3376>。
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010, <http://www.rfc-editor.org/info/rfc5757>.
[RFC5757] Schmidt、T.、Waehlisch、M。、およびG. Fairhurst、「Mobile IP Version 6（MIPv6）：Multicast Mobility in Mobile IP Version 6（MIPv6）：Problem Statement and Brief Survey」、RFC 5757、2010年2月、<http：// www。 rfc-editor.org/info/rfc5757>。
[FMCAST-MIP6] Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, draft-suh-mipshop-fmcast-mip6-00, February 2004.
[FMCAST-MIP6] Suh、K.、Kwon、D.、Suh、Y。、およびY. Park、「高速ハンドオーバ環境におけるモバイルIPv6の高速マルチキャストプロトコル」、作業中、draft-suh-mipshop-fmcast -mip6-00、2004年2月。
[FMIPv6-Analysis] Schmidt, T. and M. Waehlisch, "Predictive versus Reactive -- Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, Vol. 30, No. 1-3, pp. 123-142, November 2005, <http://dx.doi.org/10.1007/s11235-005-4321-4>.
[FMIPv6-Analysis] Schmidt、T. and M. Waehlisch、 "Predictive vs Reactive-Analysis of Handover Performance and its Impacts on IPv6 and Multicast Mobility"、Telecommunication Systems、Vol。 30、No。1-3、pp。123-142、2005年11月、<http://dx.doi.org/10.1007/s11235-005-4321-4>。
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011, <http://www.rfc-editor.org/info/rfc6224>.
[RFC6224] Schmidt、T.、Waehlisch、M。、およびS. Krishnan、「プロキシモバイルIPv6（PMIPv6）ドメインでのマルチキャストリスナーサポートの基本展開」、RFC 6224、2011年4月、<http：//www.rfc- editor.org/info/rfc6224>。
[RFC7287] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 7287, June 2014, <http://www.rfc-editor.org/info/rfc7287>.
[RFC7287] Schmidt、T.、Gao、S.、Zhang、H。、およびM. Waehlisch、「プロキシモバイルIPv6（PMIPv6）ドメインでのモバイルマルチキャスト送信者サポート」、RFC 7287、2014年6月、<http：// www .rfc-editor.org / info / rfc7287>。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月、<http://www.rfc-editor.org/info/rfc5844>。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010, <http://www.rfc-editor.org/info/rfc5845>.
[RFC5845] Muhanna、A.、Khalil、M.、Gundavelli、S。、およびK. Leung、「Generic Routing Encapsulation（GRE）Key Option for Proxy Mobile IPv6」、RFC 5845、2010年6月、<http：// www .rfc-editor.org / info / rfc5845>。
This document only specifies protocol operations for fast handovers for mobile listeners. In this appendix, we briefly discuss aspects of supporting mobile multicast sources.
このドキュメントでは、モバイルリスナーの高速ハンドオーバーのプロトコル操作のみを指定しています。この付録では、モバイルマルチキャストソースのサポートの側面について簡単に説明します。
In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender support is likely to be enabled by any one of the mechanisms described in [RFC7287]. In this case, multicast data packets from an MN are transparently forwarded either to its associated LMA or to a multicast-enabled access network. In all cases, a mobile source can continue to transmit multicast packets after a handover from PMAG to NMAG without additional management operations. Packets (with a persistent source address) will continue to flow via the LMA or the access network into the previously established distribution system.
マルチキャスト対応のプロキシモバイルIPv6ドメインでは、[RFC7287]で説明されているメカニズムのいずれかによってマルチキャスト送信側のサポートが有効になる可能性があります。この場合、MNからのマルチキャストデータパケットは、関連するLMAまたはマルチキャスト対応アクセスネットワークのいずれかに透過的に転送されます。すべての場合において、モバイルソースは、追加の管理操作なしで、PMAGからNMAGへのハンドオーバー後にマルチキャストパケットを送信し続けることができます。パケット（永続的なソースアドレスを持つ）は、LMAまたはアクセスネットワークを介して、以前に確立された配布システムに流れ続けます。
In contrast, an MN will change its Care-of Address while performing FMIPv6 handovers. Even though MNs are enabled to send packets via the reverse NAR-PAR tunnel using their previous Care-of Address for a limited time, multicast sender support in such a Mobile IPv6 regime will most likely follow one of the basic mechanisms described in Section 5.1 of [RFC5757]: (1) bidirectional tunneling, (2) remote subscription, or (3) agent-based solutions. A solution for multicast senders that is homogeneously deployed throughout the mobile access network can support seamless services during fast handovers, the details of which are beyond the scope of this document.
対照的に、MNはFMIPv6ハンドオーバーの実行中に気付アドレスを変更します。 MNは、以前の気付アドレスを使用してリバースNAR-PARトンネル経由で一定期間パケットを送信できるようになっていますが、このようなモバイルIPv6レジームでのマルチキャスト送信者のサポートは、おそらくセクション5.1で説明されている基本メカニズムの1つに従います。 [RFC5757]：（1）双方向トンネリング、（2）リモートサブスクリプション、または（3）エージェントベースのソリューション。モバイルアクセスネットワーク全体に均一に展開されるマルチキャストセンダーのソリューションは、高速ハンドオーバー中にシームレスなサービスをサポートできます。その詳細は、このドキュメントの範囲外です。
Acknowledgments
謝辞
Protocol extensions to support multicast in Fast Mobile IPv6 have been loosely discussed for several years. Repeated attempts have been made to define corresponding protocol extensions. The first version [FMCAST-MIP6] was presented by Kyungjoo Suh, Dong-Hee Kwon, Young-Joo Suh, and Youngjun Park in 2004.
Fast Mobile IPv6でマルチキャストをサポートするためのプロトコル拡張は、ここ数年の間、大まかに議論されてきました。対応するプロトコル拡張を定義する試みが繰り返し行われました。最初のバージョン[FMCAST-MIP6]は、2004年にキョンジュ・ソ、ドンヒ・クォン、ヨンジュ・ソ、ヨンジュン・パークから発表されました。
This work was stimulated by many fruitful discussions in the MobOpts research group. We would like to thank all active members for constructive thoughts and contributions on the subject of multicast mobility. The MULTIMOB working group has provided continuous feedback during the evolution of this work. Comments, discussions, and reviewing remarks have been contributed by (in alphabetical order) Carlos J. Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao, Brian Haberman, Dirk von Hugo, Min Hui, Georgios Karagian, Marco Liebsch, Behcet Sarikaya, Stig Venaas, and Juan Carlos Zuniga.
この作業は、MobOpts研究グループでの多くの実りある議論によって刺激されました。マルチキャストモビリティのテーマに関して建設的な考えと貢献をしてくださったすべてのアクティブメンバーに感謝します。 MULTIMOBワーキンググループは、この作業の進化中に継続的なフィードバックを提供しています。コメント、ディスカッション、レビューの見解は、（アルファベット順）Carlos J. Bernardos、Luis M. Contreras、Hui Deng、Shuai Gao、Brian Haberman、Dirk von Hugo、Min Hui、Georgios Karagian、Marco Liebsch、Behcet Sarikayaによって寄稿されました、スティグ・ベナス、ファン・カルロス・ズニガ。
Funding has been provided by the German Federal Ministry of Education and Research within the projects Mindstone, SKIMS, and SAFEST. This is gratefully acknowledged.
資金は、ドイツ連邦教育研究省からプロジェクトMindstone、SKIMS、SAFESTの中で提供されています。これは感謝して認められます。
Authors' Addresses
著者のアドレス
Thomas C. Schmidt (editor) HAW Hamburg Dept. Informatik Berliner Tor 7 Hamburg D-20099 Germany
トーマスC.シュミット（編集者）HAWハンブルク部インフォマティクスベルリナーTor 7ハンブルクD-20099ドイツ
EMail: t.schmidt@haw-hamburg.de
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin D-10318 Germany
Matthias Waehlischリンクラボ＆FUベルリンHoenower Str。 35ベルリンD-10318ドイツ
EMail: mw@link-lab.net
Rajeev Koodli Intel 3600 Juliette Lane Santa Clara, CA 95054 United States
Rajiv Koodli Intel ^ Juliette Lane Santa Clara、K ೯೫೦೫೪ United States
EMail: rajeev.koodli@intel.com
Godred Fairhurst University of Aberdeen School of Engineering Aberdeen AB24 3UE United Kingdom
Godred Fairhurst University of Aberdeen School of EngineeringアバディーンAB24 3UEイギリス
EMail: gorry@erg.abdn.ac.uk
Dapeng Liu China Mobile
DA Pengl IU China Mobile
Phone: +86-123-456-7890
EMail: liudapeng@chinamobile.com