[要約] RFC 6224は、Proxy Mobile IPv6（PMIPv6）ドメインでのマルチキャストリスナーサポートの基本的な展開に関するものです。このRFCの目的は、PMIPv6ドメイン内でのマルチキャストトラフィックの効率的な配信を実現するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) T. Schmidt
Request for Comments: 6224 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab & FU Berlin
S. Krishnan
Ericsson
April 2011
Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains
プロキシモバイルIPv6（PMIPV6）ドメインでのマルチキャストリスナーサポートのベース展開
Abstract
概要
This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document.
このドキュメントでは、モビリティおよびマルチキャストプロトコル標準を変更せずに、プロキシモバイルIPv6ドメインでマルチキャストリスナー関数をアクティブにするための展開オプションについて説明します。モバイルIPv6のホームエージェントと同様に、プロキシモバイルIPv6のローカルモビリティアンカーはマルチキャストサブスクリプションアンカーポイントとして機能し、モバイルアクセスゲートウェイはマルチキャストリスナーディスカバリー（MLD）プロキシ関数を提供します。このシナリオでは、モバイルノードはマルチキャストモビリティ操作の不可知論者のままです。モバイルマルチキャスト送信者のサポートは、このドキュメントの範囲外です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc6224.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6224で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. Multicast Availability throughout the Access Network . . . 12
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 13
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16
Appendix C. Comparative Evaluation of Different Approaches . . . 17
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) [RFC3775] by network-based management functions that enable IP mobility for a host without requiring its participation in any mobility-related signaling. Additional network entities, called the Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs), are responsible for managing IP mobility on behalf of the mobile node (MN).
プロキシモバイルIPv6（PMIPV6）[RFC5213]は、モビリティ関連のシグナル伝達に参加することなくホストのIPモビリティを可能にするネットワークベースの管理機能により、モバイルIPv6（MIPV6）[RFC3775]を拡張します。ローカルモビリティアンカー（LMA）とモバイルアクセスゲートウェイ（MAGS）と呼ばれる追加のネットワークエンティティは、モバイルノード（MN）に代わってIPモビリティを管理する責任があります。
With these entities in place, the mobile node experiences an exceptional access topology towards the static Internet in the sense that the MAG introduces a routing hop in situations where the LMA architecturally acts as the next hop (or designated) router for the MN. In the particular case of multicast communication, group membership management, as signaled by the Multicast Listener Discovery (MLD) protocol [RFC3810] [RFC2710], requires dedicated treatment at the network side.
これらのエンティティが導入されているため、モバイルノードは、MAがMNの次のホップ（または指定）ルーターとしてARACITECTALLYが機能する状況で、MAGがルーティングホップを導入するという意味で、静的インターネットに向けて例外的なアクセストポロジを経験します。マルチキャスト通信の特定のケースでは、マルチキャストリスナーディスカバリー（MLD）プロトコル[RFC3810] [RFC2710]によって合図されるグループメンバーシップ管理には、ネットワーク側での専用の治療が必要です。
Multicast routing functions need to be placed carefully within the PMIPv6 domain in order to augment unicast transmission with group communication services. [RFC5213] does not explicitly address multicast communication. Bidirectional home tunneling, the minimal multicast support arranged by MIPv6, cannot be directly transferred to network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. Consequently, even minimal multicast listener support in PMIPv6 domains requires an explicit deployment of additional functions.
マルチキャストルーティング機能は、グループ通信サービスでユニキャスト伝送を強化するために、PMIPv6ドメイン内に慎重に配置する必要があります。[RFC5213]は、マルチキャスト通信に明示的に対処していません。Mipv6によって配置された最小限のマルチキャストサポートである双方向のホームトンネルは、モビリティとアウェアのノードが移動後にそのようなトンネルを開始しないため、ネットワークベースの管理シナリオに直接転送することはできません。その結果、PMIPv6ドメインでの最小限のマルチキャストリスナーサポートでさえ、追加の機能を明示的に展開する必要があります。
This document describes options for deploying multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. This document does not address specific optimizations and efficiency improvements of multicast routing for network-based mobility discussed in [RFC5757], as such solutions would require changes to the base PMIPv6 protocol [RFC5213]. Support for mobile multicast senders is also outside the scope of this document.
このドキュメントでは、モビリティおよびマルチキャストプロトコル標準を変更せずに、プロキシモバイルIPv6ドメインにマルチキャストリスナー関数を展開するためのオプションについて説明します。モバイルIPv6のホームエージェントと同様に、PMIPV6ローカルモビリティアンカーはマルチキャストサブスクリプションアンカーポイントとして機能し、モバイルアクセスゲートウェイはMLDプロキシ関数を提供します。このシナリオでは、モバイルノードはマルチキャストモビリティ操作の不可知論者のままです。このドキュメントは、[RFC5757]で説明されているネットワークベースのモビリティのマルチキャストルーティングの特定の最適化と効率の改善に対処していません。そのようなソリューションには、ベースPMIPV6プロトコル[RFC5213]の変更が必要になるためです。モバイルマルチキャスト送信者のサポートも、このドキュメントの範囲外です。
This document uses the terminology as defined for the mobility protocols [RFC3775], [RFC5213], and [RFC5844], as well as the multicast edge related protocols [RFC3376], [RFC3810], and [RFC4605].
この文書は、モビリティプロトコル[RFC3775]、[RFC5213]、[RFC5844]、およびマルチキャストエッジ関連のプロトコル[RFC3376]、[RFC3810]、[RFC4605]に定義された用語を使用します。
The reference scenario for multicast deployment in Proxy Mobile IPv6 domains is illustrated in Figure 1. Below, LMAA and MN-HNP are the LMA Address and Mobile Node's Home Network Prefix as defined in [RFC5213].
プロキシモバイルIPv6ドメインでのマルチキャスト展開の参照シナリオを図1に示します。以下では、LMAAおよびMN-HNPは[RFC5213]で定義されているLMAアドレスとモバイルノードのホームネットワークプレフィックスです。
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3
Figure 1: Reference Network for Multicast Deployment in PMIPv6
図1：PMIPv6でのマルチキャスト展開のリファレンスネットワーク
An MN in a PMIPv6 domain will decide on multicast group membership management completely independent of its current mobility conditions. It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses according to [RFC3810] or [RFC2710]. These link-local signaling messages will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these MLD messages.
PMIPV6ドメインのMNは、現在のモビリティ条件とは無関係にマルチキャストグループメンバーシップ管理を決定します。[RFC3810]または[RFC2710]に従って、リンクローカルソースアドレスとマルチキャスト宛先アドレスを使用して、アプリケーショントリガーに基づいてMLDレポートと完了したメッセージを送信します。これらのLink-Local Signalingメッセージは、ダウンストリームローカル（ワイヤレス）リンクの1つを介して、現在アクティブなMAGに到達します。マルチキャストユダヤルの雑誌は、これらのMLDメッセージを単純に破棄します。
To facilitate multicast in a PMIPv6 domain, an MLD proxy function [RFC4605] needs to be deployed on the MAG that selects the tunnel interface corresponding to the MN's LMA for its upstream interface (cf., Section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel interface defines an MLD proxy domain at the MAG, and it contains all downstream links to MNs that share this specific LMA. According to standard proxy operations, MLD Report messages will be aggregated and then forwarded up the tunnel interface to the MN's corresponding LMA.
PMIPv6ドメインのマルチキャストを促進するには、MLDプロキシ関数[RFC4605]を、上流インターフェイスのMNのLMAに対応するトンネルインターフェイスを選択するMAGに展開する必要があります（[RFC5213]のセクション6）。これにより、各MAGからLMAへのトンネルインターフェイスは、MAGのMLDプロキシドメインを定義し、この特定のLMAを共有するMNSへのすべての下流リンクが含まれています。標準のプロキシ操作によると、MLDレポートメッセージは集約され、トンネルインターフェイスをMNの対応するLMAに転送します。
Serving as the designated multicast router or an additional MLD proxy, the LMA will transpose any MLD message from a MAG into the multicast routing infrastructure. Correspondingly, the LMA will create appropriate multicast forwarding states at its tunnel interface. Traffic of the subscribed groups will arrive at the LMA, and the LMA will forward this traffic according to its group/source states. In addition, the LMA will act as an MLD querier, seeing its downstream tunnel interfaces as multicast-enabled links.
指定されたマルチキャストルーターまたは追加のMLDプロキシとして機能するLMAは、MALからマルチキャストルーティングインフラストラクチャにMLDメッセージを転置します。それに対応して、LMAはトンネルインターフェイスに適切なマルチキャスト転送状態を作成します。購読されたグループのトラフィックはLMAに到着し、LMAはグループ/ソースの状態に従ってこのトラフィックを転送します。さらに、LMAはMLDクエリエとして機能し、下流のトンネルインターフェイスをマルチキャスト対応リンクと見なします。
At the MAG, MLD queries and multicast data will arrive on the (tunnel) interface that is assigned to a group of access links as identified by its Binding Update List (cf., Section 6.1 of [RFC5213]). As specified for MLD proxies, the MAG will forward multicast traffic and initiate related signaling down the appropriate access links to the MNs. Hence, all multicast-related signaling and the data traffic will transparently flow from the LMA to the MN on an LMA-specific tree, which is shared among the multicast sources.
MAGでは、MLDクエリとマルチキャストデータは、バインディングアップデートリスト（[RFC5213]のセクション6.1を参照）で識別されるアクセスリンクのグループに割り当てられた（トンネル）インターフェイスに到着します。MLDプロキシに指定されているように、MAGはマルチキャストトラフィックを転送し、関連するシグナルをMNSへの適切なアクセスリンクを開始します。したがって、すべてのマルチキャスト関連のシグナル伝達とデータトラフィックは、マルチキャストソースの間で共有されるLMA固有のツリーでLMAからMNに透過的に流れます。
In case of a handover, the MN (unaware of IP mobility) will not send unsolicited MLD reports. Instead, the MAG is required to maintain group memberships in the following way. On observing a new MN on a downstream access link, the MAG sends a MLD General Query. Based on its outcome and the multicast group states previously maintained at the MAG, a corresponding Report will be sent to the LMA aggregating group membership states according to the proxy function. Additional Reports can be omitted when the previously established multicast forwarding states at the new MAG already cover the subscriptions of the MN.
ハンドオーバーの場合、MN（IPモビリティを認識していない）は、未承諾のMLDレポートを送信しません。代わりに、グループメンバーシップを次の方法で維持するためにMAGが必要です。下流のアクセスリンクで新しいMNを観察すると、MAGはMLD一般クエリを送信します。その結果と以前にMAGで維持されていたマルチキャストグループ状態に基づいて、対応するレポートは、プロキシ関数に従ってLMA集約グループメンバーシップ状態に送信されます。新しいMAGで以前に確立されたマルチキャスト転送状態が、MNのサブスクリプションをすでにカバーしている場合、追加のレポートを省略できます。
In summary, the following steps are executed on handover:
要約すると、次の手順はハンドオーバー時に実行されます。
1. The MAG-MN link comes up and the MAG discovers the new MN.
1. MAG-MNリンクが登場し、MAGが新しいMNを発見します。
2. Unicast address configuration and PMIPv6 binding are performed after the MAG determines the corresponding LMA.
2. MAGが対応するLMAを決定した後、ユニキャストアドレスの構成とPMIPV6結合は実行されます。
3. Following IPv6 address configuration, the MAG should send an (early) MLD General Query to the new downstream link as part of its standard multicast-enabled router operations.
3. IPv6アドレスの構成に続いて、MAGは標準のマルチキャスト対応ルーター操作の一部として（早期）MLD一般的なクエリを新しいダウンストリームリンクに送信する必要があります。
4. The MAG should determine whether the MN is admissible to multicast services; if it's not, then stop here.
4. MAGは、MNがマルチキャストサービスに許容できるかどうかを判断する必要があります。そうでない場合は、ここで止めてください。
5. The MAG adds the new downstream link to the MLD proxy instance with up-link to the corresponding LMA.
5. MAGは、対応するLMAにアップリンクを使用して、新しいダウンストリームリンクをMLDプロキシインスタンスに追加します。
6. The corresponding proxy instance triggers an MLD General Query on the new downstream link.
6. 対応するプロキシインスタンスは、新しいダウンストリームリンクのMLD一般クエリをトリガーします。
7. The MN Membership Reports arrive at the MAG, in response either to the early query or to the query sent by the proxy instance.
7. MNメンバーシップレポートは、早期クエリまたはプロキシインスタンスによって送信されたクエリに応じて、MAGに到着します。
8. The Proxy processes the MLD Report, updates states, and reports upstream if necessary.
8. プロキシは、MLDレポートを処理し、状態を更新し、必要に応じて上流にレポートします。
After Re-Binding, the LMA is not required to issue a MLD General Query on the tunnel link to refresh forwarding states. Multicast state updates should be triggered by the MAG, which aggregates subscriptions of all its MNs (see the call flow in Figure 2).
再結合後、LMAは、転送状態を更新するためにトンネルリンクにMLD一般的なクエリを発行する必要はありません。マルチキャスト状態の更新は、すべてのMNSのサブスクリプションを集約するMAGによってトリガーされる必要があります（図2のコールフローを参照）。
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
Figure 2: Call Flow of Multicast-Enabled PMIP with "MLD Membership Report" Abbreviated by "Join"
図2：「MLDメンバーシップレポート」を備えたマルチキャスト対応PMIPのコールフローは、「Join」によって略されました
These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. PMIPv6 can provide IPv4 home address mobility support [RFC5844]. Such mobile nodes will use IGMP [RFC2236] [RFC3376] signaling for multicast, which is handled by an IGMP proxy function at the MAG in an analogous way.
同様に、これらのマルチキャスト展開の考慮事項は、PMIPv6ドメインで有効になっているIPv4スタックで動作するモバイルノードに適用されます。PMIPv6は、IPv4ホームアドレスモビリティサポート[RFC5844]を提供できます。このようなモバイルノードは、マルチキャストのIGMP [RFC2236] [RFC3376]シグナリングを使用します。これは、MAGのIGMPプロキシ関数によって類似の方法で処理されます。
Following these deployment steps, multicast management transparently interoperates with PMIPv6. It is worth noting that MNs -- while being attached to the same MAG, but associated with different LMAs -- can subscribe to the same multicast group. Thereby, data could be distributed redundantly in the network and duplicate traffic could arrive at a MAG. Additionally, in a point-to-point wireless link model, a MAG might be forced to transmit the same data over one wireless domain to different MNs. However, multicast traffic arriving at one interface of the MN will always remain unique, i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN (see Appendix C for further considerations).
これらの展開手順に従って、マルチキャスト管理はPMIPv6と透過的に相互緩和します。MNSは、同じ雑誌に取り付けられているが、異なるLMAに関連付けられているが、同じマルチキャストグループに購読できることは注目に値します。これにより、ネットワークでデータを冗長に分散させることができ、重複するトラフィックが雑誌に到達する可能性があります。さらに、ポイントツーポイントワイヤレスリンクモデルでは、MAGが同じデータを1つのワイヤレスドメインで異なるMNに送信することを余儀なくされる場合があります。ただし、MNの1つのインターフェイスに到着するマルチキャストトラフィックは常に一意のままです。つまり、モバイルマルチキャスト配信システムは、MNに到着する重複パケットを引き起こすことはありません（詳細な考慮事項については、付録Cを参照）。
Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define their interaction with the PMIPv6 protocol in the following way.
PMIPv6ドメインのマルチキャストアクティベーションでは、PMIPv6ルーターに一般的なマルチキャスト関数を展開し、PMIPv6プロトコルとの相互作用を次の方法で定義する必要があります。
A mobile node willing to manage multicast traffic will join, maintain, and leave groups as if located in the fixed Internet. No specific mobility actions nor implementations are required at the MN.
マルチキャストトラフィックの管理を希望するモバイルノードは、固定インターネットにあるかのようにグループに参加、維持、および去ります。MNでは、特定のモビリティアクションや実装は必要ありません。
A Mobile Access Gateway is required to assist in MLD signaling and data forwarding between the MNs that it serves and the corresponding LMAs associated to each MN. It therefore needs to implement an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been established with an LMA. The MAG decides on the mapping of downstream links to a proxy instance (and hence an upstream link to an LMA) based on the regular Binding Update List as maintained by PMIPv6 standard operations (cf., Section 6.1 of [RFC5213]). As links connecting MNs and MAGs change under mobility, MLD proxies at MAGs must be able to dynamically add and remove downstream interfaces in their configurations.
モバイルアクセスゲートウェイは、サービスを提供するMNSと各MNに関連する対応するLMA間のMLDシグナル伝達とデータ転送を支援するために必要です。したがって、LMAで確立された各上流のトンネルインターフェイスにMLDプロキシ関数[RFC4605]のインスタンスを実装する必要があります。MAGは、PMIPV6標準操作によって維持されている通常のバインディングアップデートリストに基づいて、下流リンクのプロキシインスタンス（したがってLMAへの上流リンク）へのマッピングを決定します（[RFC5213]のセクション6.1）。MNSとMAGSを接続するリンクがモビリティの下で変化するため、MAGSのMLDプロキシは、構成内の下流インターフェイスを動的に追加および削除できる必要があります。
On the reception of MLD reports from an MN, the MAG must identify the corresponding proxy instance from the incoming interface and perform regular MLD proxy operations: it will insert/update/remove multicast forwarding state on the incoming interface and will merge state updates into the MLD proxy membership database. It will then send an aggregated Report via the upstream tunnel to the LMA when the membership database (cf., Section 4.1 of [RFC4605]) changes. Conversely, on the reception of MLD queries, the MAG proxy instance will answer the Queries on behalf of all active downstream receivers maintained in its membership database. Queries sent by the LMA do not force the MAG to trigger corresponding messages immediately towards MNs. Multicast traffic arriving at the MAG on an upstream interface will be forwarded according to the group-specific or source-specific forwarding states as acquired for each downstream interface within the MLD proxy instance. At this stage, it is important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of Section 4.2 in [RFC4605], i.e., treat proxy instances in isolation of each other while forwarding. In providing isolated proxy instances, the MAG will uniquely serve its downstream links with exactly the data that belong to whatever group is subscribed on the particular interface.
MNからのMLDレポートの受信時に、MAGは、受信インターフェイスから対応するプロキシインスタンスを識別し、通常のMLDプロキシ操作を実行する必要があります。MLDプロキシメンバーシップデータベース。次に、メンバーシップデータベース（[RFC4605]のセクション4.1）が変更されると、上流トンネルを介してLMAに集約されたレポートを送信します。逆に、MLDクエリの受信時に、MAGプロキシインスタンスは、メンバーシップデータベースに維持されているすべてのアクティブなダウンストリームレシーバーに代わってクエリに回答します。LMAによって送信されたクエリは、MAGにMNSに対してすぐに対応するメッセージをすぐにトリガーするように強制しません。上流インターフェイスでMAGに到着するマルチキャストトラフィックは、MLDプロキシインスタンス内の各下流インターフェイスについて取得したグループ固有またはソース固有の転送状態に従って転送されます。この段階では、複数のインスタンスが可能なIGMP/MLDプロキシ実装は、[RFC4605]のセクション4.2の仕様に密接に従うことが期待されることに注意することが重要です。孤立したプロキシインスタンスを提供する際、MAGは、特定のインターフェイスでサブスクライブされているグループに属するデータと正確に下流リンクを一意に提供します。
After a handover, the MAG will continue to manage upstream tunnels and downstream interfaces as specified in the PMIPv6 specification. It must dynamically associate new access links to proxy instances that include the upstream connection to the corresponding LMA. The MAG detects the arrival of a new MN by receiving a router solicitation message and by an upcoming link. To learn about multicast groups subscribed by a newly attaching MN, the MAG should send a General Query to the MN's link. Querying an upcoming interface is a standard operation of MLD queriers (see Appendix A) and is performed immediately after address configuration. In addition, an MLD query should be initiated by the proxy instance, as soon as a new interface has been configured for downstream. In case the access link between MN and MAG goes down, interface-specific multicast states change. Both cases may alter the composition of the membership database and this will trigger corresponding Reports towards the LMA. Note that the actual observable state depends on the access link model in use.
ハンドオーバー後、MAGはPMIPv6仕様で指定されているように、上流のトンネルと下流のインターフェイスを管理し続けます。対応するLMAへの上流接続を含むプロキシインスタンスへの新しいアクセスリンクを動的に関連付ける必要があります。MAGは、ルーターの勧誘メッセージを受信し、今後のリンクによって新しいMNの到着を検出します。新しく付着したMNで購読するマルチキャストグループについて学ぶために、MAGはMNのリンクに一般的なクエリを送信する必要があります。今後のインターフェイスのクエリは、MLDクエリエの標準操作であり（付録Aを参照）、アドレス構成の直後に実行されます。さらに、下流の新しいインターフェイスが構成されたらすぐに、プロキシインスタンスによってMLDクエリを開始する必要があります。MNとMAG間のアクセスリンクがダウンした場合、インターフェイス固有のマルチキャスト状態が変更されます。どちらの場合も、メンバーシップデータベースの構成が変更される可能性があり、これによりLMAに対する対応するレポートがトリガーされます。実際の観測可能な状態は、使用中のアクセスリンクモデルに依存することに注意してください。
An MN may be unable to answer MAG multicast membership queries due to handover procedures, or its report may arrive before the MAG has configured its link as the proxy downstream interface. Such occurrences are equivalent to a General Query loss. To prevent erroneous query timeouts at the MAG, MLD parameters should be carefully adjusted to the mobility regime. In particular, MLD timers and the Robustness Variable (see Section 9 of [RFC3810]) should be chosen to be compliant with the time scale of handover operations and proxy configurations in the PMIPv6 domain.
MNは、ハンドオーバー手順のためにMAGマルチキャストメンバーシップクエリに答えることができない場合があります。または、MAGがプロキシダウンストリームインターフェイスとしてリンクを構成する前に、そのレポートが届く場合があります。このような発生は、一般的なクエリ損失に相当します。MAGでの誤ったクエリのタイムアウトを防ぐために、MLDパラメーターはモビリティ体制に慎重に調整する必要があります。特に、MLDタイマーと堅牢性変数（[RFC3810]のセクション9を参照）は、PMIPv6ドメインのハンドオーバー操作とプロキシ構成の時間スケールに準拠するように選択する必要があります。
In proceeding this way, the MAG is able to aggregate multicast subscriptions for each of its MLD proxy instances. However, this deployment approach does not prevent multiple identical streams arriving from different LMA upstream interfaces. Furthermore, a multipoint channel forwarding into the wireless domain is prevented by the point-to-point link model in use.
この方法で進む際に、MAGはMLDプロキシインスタンスごとにマルチキャストサブスクリプションを集約することができます。ただし、この展開アプローチは、異なるLMA上流インターフェイスから到着する複数の同一のストリームを妨げません。さらに、ワイヤレスドメインへのマルチポイントチャネルの転送は、使用中のポイントツーポイントリンクモデルによって防止されます。
For any MN, the Local Mobility Anchor acts as the persistent home agent and at the same time as the default multicast querier for the corresponding MAG. It implements the function of the designated multicast router or a further MLD proxy. According to MLD reports received from a MAG (on behalf of the MNs), the LMA establishes/ maintains/removes group-/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. At the same time, it procures for aggregated multicast membership maintenance at its upstream interface. Based on the multicast-transparent operations of the MAGs, the LMA treats its tunnel interfaces as multicast-enabled downstream links, serving zero to many listening nodes. Multicast traffic arriving at the LMA is transparently forwarded according to its multicast forwarding information base.
任意のMNの場合、ローカルモビリティアンカーは永続的なホームエージェントとして機能し、同時に対応するMAGのデフォルトマルチキャストクエリエと同時に機能します。指定されたマルチキャストルーターまたはさらにMLDプロキシの機能を実装します。（MNSに代わって）MAGから受け取ったMLDレポートによると、LMAは、対応するダウンストリームトンネルインターフェイスでグループ/ソース固有のマルチキャスト転送状態を確立/維持/削除します。同時に、上流インターフェイスで集約されたマルチキャストメンバーシップメンテナンスを調達します。MAGSのマルチキャスト透過操作に基づいて、LMAはトンネルインターフェイスをマルチキャスト対応のダウンストリームリンクとして扱い、多くのリスニングノードにゼロを提供します。LMAに到着するマルチキャストトラフィックは、マルチキャスト転送情報ベースに従って透過的に転送されます。
After a handover, the LMA will receive Binding De-Registrations and Binding Lifetime Extensions that will cause a re-mapping of home network prefix(es) to a new Proxy-CoA in its Binding Cache (see Section 5.3 of [RFC5213]). The multicast forwarding states require updating, as well, if the MN within an MLD proxy domain is the only receiver of a multicast group. Two different cases need to be considered:
ハンドオーバー後、LMAは、結合キャッシュの新しいプロキシCOAにホームネットワークプレフィックス（ES）の再マッピングを引き起こすバインドされた分解と結合寿命拡張を受け取ります（[RFC5213]のセクション5.3を参照）。マルチキャスト転送状態は、MLDプロキシドメイン内のMNがマルチキャストグループの唯一の受信機である場合、更新を必要とします。2つの異なるケースを考慮する必要があります。
1. The mobile node is the only receiver of a group behind the interface at which a De-Registration was received: the membership database of the MAG changes, which will trigger a Report/Done sent via the MAG-to-LMA interface to remove this group. The LMA thus terminates multicast forwarding.
1. モバイルノードは、登録解除が受信されたインターフェイスの背後にあるグループの唯一のレシーバーです。MAGのメンバーシップデータベースが変更されます。これにより、MAG対LMAインターフェイスを介して送信されたレポートがトリガーされ、このグループが削除されます。。したがって、LMAはマルチキャスト転送を終了します。
2. The mobile node is the only receiver of a group behind the interface at which a Lifetime Extension was received: the membership database of the MAG changes, which will trigger a Report sent via the MAG-to-LMA interface to add this group. The LMA thus starts multicast distribution.
2. モバイルノードは、ライフタイム拡張機能が受信されたインターフェイスの背後にあるグループの唯一の受信者です。MAGのメンバーシップデータベースが変更され、MAG対LMAインターフェイスを介して送信されたレポートがトリガーされ、このグループが追加されます。したがって、LMAはマルチキャスト分布を開始します。
In proceeding this way, each LMA will provide transparent multicast support for the group of MNs it serves. It will perform traffic aggregation at the MN-group level and will assure that multicast data streams are uniquely forwarded per individual LMA-to-MAG tunnel.
この方法で進む際、各LMAは、それが提供するMNSグループに透明なマルチキャストサポートを提供します。MNグループレベルでトラフィック集約を実行し、マルチキャストデータストリームが個々のLMAからマグへのトンネルごとに一意に転送されることを保証します。
An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844]. For this purpose, 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 multicast support on the network side, an IGMP proxy function needs to be deployed at MAGs in exactly the same way as for IPv6. [RFC4605] defines IGMP proxy behavior in full agreement with IPv6/ MLD. Thus, IPv4 support can be transparently provided following the obvious deployment analogy.
PMIPV6ドメインのMNは、[RFC5844]で指定されているように、通信にIPv4アドレスを透過的に使用する場合があります。この目的のために、LMAはその結合キャッシュにIPv4-Proxy-Coasを登録でき、MagsはアクセスネットワークでIPv4サポートを提供できます。それに応じて、マルチキャストメンバーシップ管理は、IGMPを使用してMNによって実行されます。ネットワーク側のマルチキャストサポートの場合、IPv6とまったく同じ方法でMAGSにIGMPプロキシ関数を展開する必要があります。[RFC4605]は、IPv6/ MLDと完全に一致してIGMPプロキシの動作を定義しています。したがって、IPv4サポートは、明らかな展開の類推に従って透過的に提供できます。
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances should choose multicast signaling according to address configurations on the link, but may submit IGMP and MLD queries in parallel, if needed. It should further be noted that the infrastructure cannot identify two data streams as identical when distributed via an IPv4 and IPv6 multicast group. Thus, duplicate data may be forwarded on a heterogeneous network layer.
デュアルスタックIPv4/IPv6アクセスネットワークの場合、MAGプロキシインスタンスは、リンクのアドレス構成に従ってマルチキャストシグナリングを選択する必要がありますが、必要に応じてIGMPおよびMLDクエリを並行して送信する場合があります。さらに、インフラストラクチャは、IPv4およびIPv6マルチキャストグループを介して分散した場合、2つのデータストリームを同一と識別できないことに注意する必要があります。したがって、複製データは、不均一なネットワークレイヤーに転送される場合があります。
A particular note is worth giving the scenario of [RFC5845] in which overlapping private address spaces of different operators can be hosted in a PMIP domain by using Generic Routing Encapsulation (GRE) with key identification. This scenario implies that unicast communication in the MAG-LMA tunnel can be individually identified per MN by the GRE keys. This scenario still does not impose any special treatment of multicast communication for the following reasons.
特定のメモは、[RFC5845]のシナリオを提供する価値があります。このシナリオでは、重要な識別を備えた一般的なルーティングカプセル化（GRE）を使用することにより、異なる演算子のプライベートアドレススペースをPMIPドメインでホストできます。このシナリオは、MAG-LMAトンネルのユニキャスト通信がGREキーによってMNごとに個別に識別できることを意味します。このシナリオでは、以下の理由により、マルチキャスト通信の特別な扱いはまだ課されません。
MLD/IGMP signaling between MNs and the MAG is on point-to-point links (identical to unicast). Aggregated MLD/IGMP signaling between the MAG proxy instance and the LMA remains link-local between the routers and independent of any individual MN. So the MAG-proxy and the LMA should not use GRE key identifiers, but plain GRE to exchange MLD queries and reports. Similarly, multicast traffic sent from an LMA to MAGs proceeds as router-to-router forwarding according to the multicast forwarding information base (MFIB) of the LMA and independent of MN's unicast addresses, while the MAG proxy instance distributes multicast data down the point-to-point links (interfaces) according to its own MFIB, independent of MN's IP addresses.
MNSとMAG間のMLD/IGMPシグナル伝達は、ポイントツーポイントリンクにあります（ユニキャストと同一）。MAGプロキシインスタンスとLMAの間の集約されたMLD/IGMPシグナル伝達は、ルーター間でリンクローカルであり、個々のMNとは無関係です。したがって、MAG-ProxyとLMAはGREキー識別子を使用しないでください。MLDクエリとレポートを交換するためにプレーンGREを使用する必要があります。同様に、LMAからMAGSに送られたマルチキャストトラフィックは、LMAのマルチキャスト転送情報ベース（MFIB）に従ってルーターからルーターへの転送として進行し、MNのユニキャストアドレスとは独立していますが、MAGプロキシインスタンスはマルチキャストデータをポイントに分配します。MNのIPアドレスとは無関係に、独自のMFIBに従って、ポイントリンク（インターフェイス）。
It remains an open issue how communication proceeds in a multi-operator scenario, i.e., from which network the LMA pulls multicast traffic. This could be any mobility Operator itself, or a third party. However, this backbone routing in general is out of scope of the document, and most likely a matter of contracts.
マルチオペレーターのシナリオ、つまりネットワークがマルチキャストトラフィックを引き出すマルチオペレーターシナリオでのコミュニケーションがどのように進行するかは未解決の問題のままです。これは、あらゆるモビリティオペレーター自体、または第三者である可能性があります。ただし、一般的にこのバックボーンルーティングはドキュメントの範囲外であり、おそらく契約の問題です。
An MN can connect to a PMIPv6 domain through multiple interfaces and experience transparent unicast handovers at all interfaces (cf., Section 5.4 of [RFC5213]). In such simultaneous access scenarios, it can autonomously assign multicast channel subscriptions to individual interfaces (see [RFC5757] for additional details). While doing so, multicast mobility operations described in this document will transparently preserve the association of channels to interfaces in the following way.
MNは、複数のインターフェイスを介してPMIPV6ドメインに接続し、すべてのインターフェイスで透明なユニキャストハンドオーバーを体験できます（[RFC5213]のセクション5.4を参照）。このような同時アクセスシナリオでは、詳細については、個々のインターフェイスにマルチキャストチャネルサブスクリプションを自律的に割り当てることができます（[RFC5757]を参照）。そうしている間、このドキュメントに記載されているマルチキャストモビリティ操作は、チャネルの関連性を次の方法でインターフェースと透過的に保存します。
Multicast listener states are kept per interface in the MLD state table. An MN will answer to an MLD General Query received on a specific (re-attaching) interface according to the specific interface's state table. Thereafter, multicast forwarding is resumed for channels identical to those under subscription prior to handover. Consequently, an MN in a PMIPv6 domain may use multiple interfaces to facilitate load balancing or redundancy, but cannot follow a 'make-before-break' approach to service continuation on handovers.
マルチキャストリスナー状態は、MLD状態テーブルのインターフェイスごとに保持されます。MNは、特定のインターフェイスの状態テーブルに従って、特定の（再び取り付け）インターフェイスで受信したMLD一般クエリに回答します。その後、マルチキャスト転送は、ハンドオーバー前にサブスクリプション中のチャネルと同じチャネルについて再開されます。その結果、PMIPV6ドメインのMNは、複数のインターフェイスを使用して負荷分散や冗長性を促進する場合がありますが、手元でのサービス継続への「ブレイク前」のアプローチに従うことはできません。
There may be deployment scenarios where multicast services are available throughout the access network, independent of the PMIPv6 infrastructure. Direct multicast access at MAGs may be supported through native multicast routing within a flat access network that includes a multicast router, via dedicated (tunnel or VPN) links between MAGs and designated multicast routers, or by deploying Automatic Multicast Tunneling (AMT) [AUTO-MULTICAST].
PMIPv6インフラストラクチャとは無関係に、アクセスネットワーク全体でマルチキャストサービスが利用できる展開シナリオがある場合があります。MAGSでの直接マルチキャストアクセスは、マルチキャストルーターを含むフラットアクセスネットワーク内のネイティブマルチキャストルーティング、MAGSと指定されたマルチキャストルーター間の専用（トンネルまたはVPN）リンクを介して、または自動マルチキャストトンネル（AMT）[自動 - 自動化することによってサポートされる場合があります。マルチキャスト]。
Multicast deployment can be simplified in these scenarios. A single proxy instance at MAGs with up-link to the multicast cloud, for instance, could serve group communication purposes. MAGs could operate as general multicast routers or AMT gateways as well.
これらのシナリオでは、マルチキャストの展開を簡素化できます。たとえば、マルチキャストクラウドのアップリンクを備えたMAGSの単一のプロキシインスタンスは、グループコミュニケーションの目的を果たすことができます。MAGSは、一般的なマルチキャストルーターまたはAMTゲートウェイとしても動作できます。
Common to these solutions is that mobility management is covered by the dynamics of multicast routing, as initially foreseen in the Remote Subscription approach, i.e., join via a local multicast router as sketched in [RFC3775]. Care must be taken to avoid avalanche problems or service disruptions due to tardy multicast routing operations and to adapt to different link-layer technologies [RFC5757]. The different possible approaches should be carefully investigated beyond the initial sketch in Appendix C. Such work is beyond the scope of this document.
これらのソリューションに共通するのは、モビリティ管理が、リモートサブスクリプションアプローチで最初に予見されるように、マルチキャストルーティングのダイナミクスによってカバーされていることです。つまり、[RFC3775]でスケッチしたローカルマルチキャストルーターを介して結合します。遅刻したマルチキャストルーティング操作による雪崩の問題やサービスの混乱を避け、さまざまなリンク層技術に適応するように注意する必要があります[RFC5757]。付録Cの最初のスケッチを超えて、さまざまな可能なアプローチを慎重に調査する必要があります。このような作業は、このドキュメントの範囲を超えています。
An IGMPv3/MLDv2 Querier may operate in combination with explicit tracking as described in Appendix A.2 of [RFC3376], or Appendix A.2 of [RFC3810]. This mechanism allows routers to monitor each multicast receiver individually. Even though this procedure is not standardized yet, it is widely implemented by vendors as it supports faster leave latencies and reduced signaling.
IGMPV3/MLDV2 Querierは、[RFC3376]の付録A.2または[RFC3810]の付録A.2に記載されているように、明示的な追跡と組み合わせて動作する場合があります。このメカニズムにより、ルーターは各マルチキャストレシーバーを個別に監視できます。この手順はまだ標準化されていませんが、ベンダーは、より速い休暇のレイテンシとシグナルの減少をサポートするため、ベンダーによって広く実装されています。
Enabling explicit tracking on downstream interfaces of the LMA and MAG would track a single MAG and MN respectively per interface. It may be used to preserve bandwidth on the MAG-MN link.
LMAとMAGの下流インターフェイスでの明示的な追跡を有効にすると、インターフェイスごとにそれぞれ単一のMAGとMNを追跡できます。MAG-MNリンクの帯域幅を保存するために使用できます。
This section describes source and destination addresses of MLD messages and encapsulating outer headers when deployed in the PMIPv6 domain. This overview is for clarification purposes only and does not define a behavior different from referenced standards in any way.
このセクションでは、MLDメッセージのソースおよび宛先アドレスと、PMIPv6ドメインに展開されたときの外側ヘッダーのカプセル化について説明します。この概要は説明のみを目的としており、参照された標準とは何らかの形で異なる動作を定義していません。
The interface identifier A-B denotes an interface on node A, which is connected to node B. This includes tunnel interfaces. Destination addresses for MLD/IGMP messages shall be as specified in Section 8 of [RFC2710] for MLDv1, and Sections 5.1.15 and 5.2.14 of [RFC3810] for MLDv2.
インターフェイス識別子A-Bは、ノードBに接続されているノードAのインターフェイスを示します。これにはトンネルインターフェイスが含まれます。MLD/IGMPメッセージの宛先アドレスは、MLDV1の[RFC2710]のセクション8で指定され、MLDV2の[RFC3810]のセクション5.1.15および5.2.14で指定されているとおりです。
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
This document does not introduce additional messages or novel protocol operations. Consequently, no additional threats are introduced by this document beyond those identified as security concerns of [RFC3810], [RFC4605], [RFC5213], and [RFC5844].
このドキュメントでは、追加のメッセージや新しいプロトコル操作は導入されていません。その結果、[RFC3810]、[RFC4605]、[RFC5213]、および[RFC5844]のセキュリティ上の懸念として特定されたものを超えて、このドキュメントによって追加の脅威は導入されません。
However, particular attention should be paid to implications of combining multicast and mobility management at network entities. As this specification allows mobile nodes to initiate the creation of multicast forwarding states at MAGs and LMAs while changing attachments, threats of resource exhaustion at PMIP routers and access networks arrive from rapid state changes, as well as from high-volume data streams routed into access networks of limited capacities. In addition to proper authorization checks of MNs, rate controls at replicators may be required to protect the agents and the downstream networks. In particular, MLD proxy implementations at MAGs should carefully procure automatic multicast state extinction on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will not actively terminate group membership prior to departure.
ただし、ネットワークエンティティでのマルチキャストとモビリティ管理を組み合わせることの影響には特に注意が払われるべきです。この仕様により、モバイルノードはMAGSとLMAでマルチキャスト転送状態の作成を開始できるようにするため、添付ファイル、PMIPルーターでのリソース疲労の脅威、およびアクセスネットワークが急速な状態の変化から届き、アクセスにルーティングされた大量のデータストリームから届きます。限られた容量のネットワーク。MNSの適切な承認チェックに加えて、エージェントとダウンストリームネットワークを保護するために、レプリケーターでのレートコントロールが必要になる場合があります。特に、MAGSでのMLDプロキシ実装は、MNSの出発時に自動マルチキャスト状態の絶滅を慎重に調達する必要があります。PMIPV6ドメインのモバイルマルチキャストリスナーは、出発前にグループメンバーシップを積極的に終了しないためです。
This memo follows initial requirements work presented in "Multicast Support Requirements for Proxy Mobile IPv6" (July 2009), and is the outcome of extensive previous discussions and a follow-up of several initial documents on the subject. The authors would like to thank (in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen, Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for advice, help, and reviews of the document. Funding by the German Federal Ministry of Education and Research within the G-LAB Initiative is gratefully acknowledged.
このメモは、「プロキシモバイルIPv6のマルチキャストサポート要件」（2009年7月）で提示された初期要件の作業に従い、広範な以前の議論の結果と、主題に関するいくつかの初期文書のフォローアップです。著者は、（アルファベット順に）Jari Arkko、Luis M. Contreras、Greg Daley、Gorry Fairhurst、Dirk Von Hugo、Liu Hui、Seil Jeon、Jouni Korhonen、Guang Lu、Sebastian Meiling、Akbar Rahman、Imed Romdhani、Imed Romdhaniに感謝したいと思います。Behcet Sarikaya、Pierrick Seite、Stig Venaas、およびJuan Carlos Zunigaのアドバイス、ヘルプ、レビューについて。G-LABイニシアチブ内のドイツ連邦教育研究省による資金提供は感謝されています。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[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.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「インターネットグループ管理プロトコル（IGMP） /マルチキャストリスナーディスカバリー（MLD）ベースのマルチキャスト転送（「IGMP / MLDプロキシ」）"、RFC 4605、2006年8月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、RFC 5844、2010年5月。
[AUTO-MULTICAST] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Pusateri, "Automatic IP Multicast Without Explicit Tunnels (AMT)", Work in Progress, March 2010.
[Auto-Multicast] Thaler、D.、Talwar、M.、Aggarwal、A.、Vicisano、L。、およびT. Pusateri、「明示的なトンネルなし（AMT）のない自動IPマルチキャスト」、2010年3月の作業。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[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.
[RFC5757] Schmidt、T.、Waehlisch、M。、およびG. Fairhurst、「モバイルIPバージョン6（MIPV6）のマルチキャストモビリティ：問題声明と簡単な調査」、RFC 5757、2010年2月。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
[RFC5845] Muhanna、A.、Khalil、M.、Gundavelli、S。、およびK. Leung、「汎用ルーティングカプセル化（GRE）プロキシモバイルIPv6の重要なオプション」、RFC 5845、2010年6月。
According to [RFC3810] and [RFC2710], when an IGMP-/MLD-enabled multicast router starts operating on a subnet, by default it considers itself as querier and sends several General Queries. Such initial query should be sent by the router immediately, but could be delayed by a (tunable) Startup Query Interval (see Sections 7.6.2 and 9.6 of [RFC3810]).
[RFC3810]および[RFC2710]によると、IGMP-/MLD対応のマルチキャストルーターがサブネットで動作を開始すると、デフォルトではQuerierと見なされ、いくつかの一般的なクエリを送信します。このような初期クエリは、すぐにルーターによって送信する必要がありますが、（調整可能な）起動クエリ間隔によって遅延する可能性があります（[RFC3810]のセクション7.6.2および9.6を参照）。
Experimental tests on Linux and Cisco systems have revealed immediate IGMP Queries followed a link trigger event (within a fraction of 1 ms), while MLD queries immediately followed the autoconfiguration of IPv6 link-local addresses at the corresponding interface.
LinuxおよびCisco Systemsの実験テストにより、IGMPの即時クエリはリンクトリガーイベント（1 msの一部以内）に続いていることが明らかになり、MLDクエリはすぐに対応するインターフェイスでのIPv6 Link-Localアドレスの自動構成に続きました。
Appendix B. State of IGMP/MLD Proxy Implementations
付録B. IGMP/MLDプロキシ実装の状態
The deployment scenario defined in this document requires certain proxy functionalities at the MAGs that implementations of [RFC4605] need to contribute. In particular, a simultaneous support of IGMP and MLD is needed, as well as a configurable list of downstream interfaces that may be altered during runtime, and the deployment of multiple proxy instances at a single router that can operate independently on separated interfaces.
このドキュメントで定義されている展開シナリオには、[RFC4605]の実装が貢献する必要があるというMAGSの特定のプロキシ機能が必要です。特に、IGMPとMLDの同時サポートが必要であり、ランタイム中に変更される可能性のある下流インターフェイスの構成可能なリスト、および分離されたインターフェイスで独立して動作できる単一ルーターでの複数のプロキシインスタンスの展開が必要です。
A brief experimental trial undertaken in February 2010 revealed the following divergent statuses of selected IGMP/MLD proxy implementations.
2010年2月に行われた短い実験的試験では、選択されたIGMP/MLDプロキシ実装の次の分岐ステータスが明らかになりました。
Cisco Edge Router: Software-based commodity edge routers (test device from the 26xx-Series) implement IGMPv2/v3 proxy functions only in combination with Protocol Independent Multicast - Sparse Mode (PIM-SM). There is no support of MLD proxy. Interfaces are dynamically configurable at runtime via the command line interface, but multiple proxy instances are not supported.
Cisco Edge Router：ソフトウェアベースのコモディティエッジルーター（26xxシリーズのテストデバイス）は、Protocol Independent Multicast-Sparse Mode（PIM-SM）と組み合わせてのみIgmpv2/V3プロキシ機能を実装します。MLDプロキシのサポートはありません。インターフェイスは、コマンドラインインターフェイスを介して実行時に動的に構成可能ですが、複数のプロキシインスタンスはサポートされていません。
Linux igmpproxy: IGMPv2 Proxy implementation that permits a static configuration of downstream interfaces (simple bug fix required). Multiple instances are prevented by a lock (corresponding code reused from a previous Distance Vector Multicast Routing Protocol (DVMRP) implementation). IPv6/MLD is unsupported. Project page: http://sourceforge.net/projects/igmpproxy/.
Linux Igmpproxy：下流インターフェイスの静的構成を許可するIgMPv2プロキシ実装（単純なバグ修正が必要）。複数のインスタンスがロックによって防止されます（以前の距離ベクトルマルチキャストルーティングプロトコル（DVMRP）実装から再利用されるコード）。IPv6/MLDはサポートされていません。プロジェクトページ：http：//sourceforge.net/projects/igmpproxy/。
Linux gproxy: IGMPv3 Proxy implementation that permits configuration of the upstream interface, only. Downstream interfaces are collected at startup without dynamic extension of this list. No support of multiple instances or MLD.
Linux gproxy：上流インターフェイスの構成を許可するIGMPV3プロキシ実装のみ。このリストを動的に拡張せずに、下流インターフェイスが起動時に収集されます。複数のインスタンスまたはMLDのサポートはありません。
Linux ecmh: MLDv1/2 Proxy implementation without IGMP support that inspects IPv4 tunnels and detects encapsulated MLD messages. Allows for dynamic addition of interfaces at runtime and multiple instances. However, downstream interfaces cannot be configured. Project page: http://sourceforge.net/projects/ecmh/
Linux ECMH：MLDV1/2 IGMPサポートなしのプロキシ実装IPv4トンネルを検査し、カプセル化されたMLDメッセージを検出します。実行時および複数のインスタンスでインターフェイスを動的に追加できるようにします。ただし、下流のインターフェイスを構成することはできません。プロジェクトページ：http：//sourceforge.net/projects/ecmh/
In this section, we briefly evaluate two orthogonal PMIP concepts for multicast traffic organization at LMAs. In scenario A, multicast is provided by combined unicast/multicast LMAs as described in this document. Scenario B directs traffic via a dedicated, central multicast router ("LMA-M") that tunnels packets to MAGs independent of unicast handoffs.
このセクションでは、LMASのマルチキャスト交通組織の2つの直交PMIP概念を簡単に評価します。シナリオAでは、このドキュメントで説明されているように、Unicast/Multicast LMAを組み合わせたマルチキャストが提供されます。シナリオBは、ユニキャストハンドオフとは無関係にトンネルパケットをマグにパケットにする専用のセントラルマルチキャストルーター（「LMA-M」）を介してトラフィックを指示します。
Neither approach establishes native multicast distribution between the LMA and MAG; instead, they use tunneling mechanisms. In scenario A, a MAG is connected to different multicast-enabled LMAs and can receive the same multicast stream via multiple paths depending on the group subscriptions of MNs and their associated LMAs. This problem, a.k.a. the tunnel convergence problem, may lead to redundant traffic at the MAGs. In contrast, scenario B configures MAGs to establish a tunnel to a single, dedicated multicast LMA for all attached MNs and relocates overhead costs to the multicast anchor. This eliminates redundant traffic but may result in an avalanche problem at the LMA.
どちらのアプローチも、LMAとMAGの間にネイティブマルチキャスト分布を確立しません。代わりに、彼らはトンネリングメカニズムを使用します。シナリオAでは、MAGが異なるマルチキャスト対応LMAに接続されており、MNSとそれに関連するLMAのグループサブスクリプションに応じて、複数のパスを介して同じマルチキャストストリームを受信できます。この問題、別名トンネル収束の問題は、雑誌の冗長なトラフィックにつながる可能性があります。対照的に、シナリオBはMAGを構成して、すべての付属されたMNSに対して単一の専用マルチキャストLMAにトンネルを確立し、オーバーヘッドコストをマルチキャストアンカーに移動します。これにより、冗長なトラフィックが排除されますが、LMAで雪崩の問題が発生する可能性があります。
We quantify the costs of both approaches based on two metrics: the amount of redundant traffic at MAGs and the number of simultaneous streams at LMAs. Realistic values depend on the topology and the group subscription model. To explore scalability in a large PMIP domain of 1,000,000 MNs, we consider the following two extreme multicast settings.
2つのメトリックに基づいて両方のアプローチのコストを定量化します。MAGSでの冗長トラフィックの量とLMAの同時ストリームの数です。現実的な値は、トポロジーとグループサブスクリプションモデルに依存します。1,000,000 mnsの大きなPMIPドメインでのスケーラビリティを調査するために、次の2つの極端なマルチキャスト設定を検討します。
1. All MNs participate in distinct multicast groups.
1. すべてのMNSは、異なるマルチキャストグループに参加します。
2. All MNs join the same multicast group.
2. すべてのMNSが同じマルチキャストグループに参加します。
A typical PMIP deployment approximately allows for 5,000 MNs attached to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000 MNs require approximately 200 MAGs backed by 4 LMAs for unicast transmission. In scenario A, these LMAs also forward multicast streams, while in scenario B one additional dedicated LMA (LMA-M) serves multicast. In the following, we calculate the metrics described above. In addition, we display the number of packet streams that cross the interconnecting (wired) network within a PMIPv6 domain.
典型的なPMIP展開では、1つの雑誌に5,000 mnsが取り付けられ、50マグが1つのLMAで提供できます。したがって、1,000,000 mnsには、ユニキャスト透過のために4 LMAに裏打ちされた約200マグが必要です。シナリオAでは、これらのLMAがマルチキャストストリームを転送し、シナリオBでは、1つの追加の専用LMA（LMA-M）がマルチキャストを提供します。以下では、上記のメトリックを計算します。さらに、PMIPv6ドメイン内で相互接続（有線）ネットワークを横断するパケットストリームの数を表示します。
Setting 1:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to distinct multicast groups.
1,000,000 mnsは、異なるマルチキャストグループにサブスクライブされます。
Setting 2:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to the same multicast group.
1,000,000 mnsが同じマルチキャストグループにサブスクライブされます。
These considerations of extreme settings show that packet duplication and replication effects apply in changing intensities for different use cases of multicast data services. However, tunnel convergence, i.e., duplicate data arriving at a MAG, does cause much smaller problems in scalability than the stream replication at LMAs (avalanche problem). For scenario A, it should also be noted that the high stream replication requirements at LMAs in setting 1 can be attenuated by deploying additional LMAs in a PMIP domain, while scenario B does not allow for distributing the LMA-M, as no handover management is available at LMA-M.
極端な設定のこれらの考慮事項は、マルチキャストデータサービスのさまざまなユースケースの強度の変化にパケットの複製と複製効果が適用されることを示しています。ただし、トンネルの収束、つまり雑誌に到達する複製データは、LMAのストリーム複製よりもはるかに小さな問題を引き起こします（雪崩問題）。シナリオAの場合、PMIPドメインに追加のLMAを展開することにより、設定1のLMAの高速レプリケーション要件を減衰させることができることにも注意する必要がありますが、シナリオBではLMA-Mの分布を許可しません。LMA-Mで入手可能。
Authors' Addresses
著者のアドレス
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
トーマス・C・シュミット・ホー・ハンブルク・ベルリナー・トー7ハンブルク20099ドイツ
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany
Matthias Waehlisch link-lab＆fu Berlin Hoenower str。35ベルリン10318ドイツ
EMail: mw@link-lab.net
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
EMail: suresh.krishnan@ericsson.com