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
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ドメインでマルチキャストリスナーの機能を活性化するための展開オプションについて説明します。モバイルアクセスゲートウェイがマルチキャストリスナ発見（MLD）プロキシ機能を提供しながら、モバイルIPv6、プロキシモバイルIPv6のローカルモビリティアンカーでホームエージェントと同様に、マルチキャストサブスクリプションのアンカーポイントとして機能します。このシナリオでは、モバイルノードは、マルチキャストモビリティ動作の不可知のままです。モバイルマルチキャスト送信者のサポートは、この文書の範囲外です。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 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）とモバイルアクセスゲートウェイ（MAGを）と呼ばれる、モバイルノード（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.
代わりにこれらのエンティティにより、移動ノードはMAGがLMAはアーキテクチャの次のホップ（または指定）として動作する状況MNのためのルータのルーティングホップを紹介するという意味で静的インターネットに対する例外アクセストポロジを経験します。マルチキャスト通信の特定の場合では、グループメンバーシップの管理は、Multicast Listener Discovery（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ドメイン内のマルチキャストリスナー関数を展開するためのオプションについて説明します。モバイルアクセスゲートウェイは、MLDプロキシ機能を提供しながら、モバイルIPv6におけるホームエージェントと同様に、PMIPv6のローカルモビリティアンカーは、などのマルチキャストサブスクリプションアンカーポイントを提供しています。このシナリオでは、モバイルノードは、マルチキャストモビリティ動作の不可知のままです。このようなソリューションは、ベースのPMIPv6プロトコル[RFC5213]への変更を必要とするであろうように、このドキュメントは、[RFC5757]で説明したネットワーク・ベースのモビリティのための特定の最適化およびマルチキャストルーティングの効率向上に取り組んでいません。モバイルマルチキャスト送信者のサポートは、この文書の範囲外でもあります。
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ドメイン内のマルチキャスト展開のためのリファレンスシナリオは、[RFC5213]で定義されるようLMAAとMN-HNPがLMAアドレスとモバイルノードのホームネットワークプレフィックスであり、以下の図1に示されています。
+-------------+
| 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
PMIPv6ドメインにおけるMNは、現在のモビリティ状態から完全に独立したマルチキャストグループメンバーシップの管理を決定します。これは、[RFC3810]か[RFC2710]によると、そのリンクローカル送信元アドレスおよびマルチキャスト宛先アドレスを使用して、アプリケーションのトリガに基づいて、MLDレポートと完了メッセージを送信します。これら
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.
リンクローカルシグナリング・メッセージは、その下流のローカル（無線）リンクのうちの1つを介して、現在アクティブなMAGに到達します。マルチキャスト非対応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]でマルチキャストを容易にするためにその上流インタフェース（参照、[RFC5213]のセクション6）のためのMNのLMAに対応するトンネルインターフェイスを選択するMAGにデプロイする必要があります。これにより、各MAGツーLMAトンネルインターフェースは、MAGにおけるMLDプロキシドメインを定義し、それは、この特定のLMAを共有するのMNへのすべての下流のリンクを含んでいます。標準のプロキシ操作によると、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は、マルチキャストルーティングインフラストラクチャにMAGから任意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は、マルチキャストトラフィックを転送してのMNへの適切なアクセスリンクをダウンシグナル関連開始します。したがって、すべてのマルチキャスト関連のシグナリングおよびデータトラフィックは透過マルチキャストソース間で共有されるLMA固有ツリー上のMNにLMAから流れます。
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:
要約すると、次のステップは、ハンドオーバ上で実行されます。
2. Unicast address configuration and PMIPv6 binding are performed after the MAG determines the corresponding LMA.
MAGは、対応するLMAを決定した後、2ユニキャストアドレス構成との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一般クエリーを発行する必要はありません。マルチキャスト状態の更新は、そのすべてのMNのサブスクリプションを集約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"
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]を提供することができます。そのようなモバイルノードは、同様の方法でMAGでIGMPプロキシ機能によって処理されるマルチキャストのためのシグナリングIGMP [RFC2236]、[RFC3376]を使用します。
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と相互運用できます。同じMAGに取り付けたが、異なるのLMAに関連付けながら - - それはMNのことは注目に値する同じマルチキャストグループに加入することができます。これにより、データは、ネットワーク内の冗長分散及びMAGに到達する可能性がトラフィックを複製することができます。また、ポイント・ツー・ポイント無線リンクモデルでは、MAGが異なるのMNへの1つのワイヤレスドメイン上で同じデータを送信することを余儀なくされる可能性があります。しかし、MNの一つのインタフェースに到着したマルチキャストトラフィックは常に、すなわち、モバイルマルチキャスト配信システムは、（さらなる検討事項については、付録Cを参照してください）MNに到着重複パケットを引き起こすことはありません、ユニークなままになります。
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.
モバイル・アクセス・ゲートウェイは、MLDシグナリングおよびそれが機能することのMNと各MNに関連する対応のLMAとの間のデータ転送を支援するために必要とされます。したがって、LMAとの間に確立された各アップストリームトンネルインターフェイスのMLDプロキシ機能[RFC4605]のインスタンスを実装する必要があります。 MAGは、PMIPv6の標準的な操作（参照、[RFC5213]のセクション6.1）によって維持されるように正規バインディングアップデートリストに基づいて、プロキシインスタンスに下流のリンク（およびLMAへしたがって上流リンク）のマッピングを決定します。移動性の下でのMNとのMAGの変化を接続するリンクとして、のMAGで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プロキシ会員データベース。その後、LMAに上流のトンネルを介して集約レポートを送信する際に会員データベース（参照、[RFC4605]のセクション4.1）に変化します。逆に、MLDクエリーの受信に、MAGプロキシインスタンスには、会員データベースに保持されているすべてのアクティブ下流の受信機に代わってクエリをお答えします。 LMAによって送られたクエリは、MNに向けて、すぐに対応するメッセージをトリガするためにMAGを強制するものではありません。アップストリームインターフェイスに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プロキシの機能を実装しています。 MLDは（のMNに代わって）MAGから受信した報告によると、LMAは、/は維持確立する/それに対応する下流トンネルインターフェイスで基 - /ソース固有マルチキャスト転送状態を除去します。同時に、それは、その上流側の界面における凝集マルチキャストメンバシップメンテナンスのために調達します。 MAGのマルチキャスト透明操作に基づいて、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を（[RFC5213]の5.3節を参照）に家の再マッピングネットワーク接頭語（es）の原因となります生涯Extensionsをバインドします。 MLDプロキシドメイン内のMNがマルチキャストグループの唯一の受信者である場合にマルチキャスト転送状態は、同様に、更新を必要とします。二つの異なる例を考慮する必要があります。
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.
MAG変化の会員データベース、レポート/ Doneを除去するために、MAGツーLMAインターフェースを介して送信トリガする：1.モバイルノードは登録解除が受信されたインターフェースの背後にグループの唯一の受信者でありますこのグループ。 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.
MAG変化の会員データベース、このグループを追加するために、MAGツーLMAインタフェースを介して送信されたレポートをトリガする：2.モバイルノードは、長寿命化が受信されたインターフェースの背後にグループの唯一の受信機です。 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は、それが機能するのMNのグループのための透明なマルチキャストサポートを提供します。これは、MN-グループレベルでトラフィック集約を実行し、マルチキャストデータストリームを一意個々LMAツーMAGトンネルごとに転送されることを保証します。
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.
[RFC5844]で指定されるようにPMIPv6ドメイン内のMNは、通信のために透過的IPv4アドレスを使用してもよいです。この目的のために、のLMAは、その結合キャッシュでのIPv4-プロキシのCoAを登録することができ、かつのMAGは、アクセスネットワーク内のIPv4サポートを提供することができます。これに対応し、マルチキャストメンバーシップ・マネジメントは、IGMPを使用してMNによって実行されます。ネットワーク側でのマルチキャストサポートについては、IGMPプロキシ機能は、IPv6の場合とまったく同じ方法でのMAGで展開する必要があります。 [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.
特に注目すべきは、異なるオペレータの重複プライベートアドレス空間は、キー識別と総称ルーティングカプセル化（GRE）を使用して、PMIPドメイン内でホストすることができる[RFC5845]のシナリオを与える価値があります。このシナリオでは、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.
MNとMAGとの間のMLD / IGMPシグナリングは、（ユニキャストと同じ）、ポイントツーポイントリンクです。 MAGのプロキシ・インスタンスとLMAとの間の凝集MLD / IGMPシグナリングは、任意の個々のMNのルータ間のリンクローカルかつ独立したままです。だから、MAG-プロキシとLMAは、GREキー識別子を使用してはならないが、平野GREはMLDクエリーおよびレポートを交換します。同様に、マルチキャストトラフィックは、マルチキャスト転送情報ベースLMAの（MFIB）とに応じてルータ間転送などのMAG進行にLMAから送信されたMAGのプロキシ・インスタンスがポイント - ダウンマルチキャストデータを配信しながら、MNのユニキャストアドレスとは無関係ポイントツーポイントのリンク（インタフェース）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.
これは、未解決の問題のまま方法LMAは、マルチキャストトラフィックを引っ張るネットワークからマルチオペレータシナリオ、すなわち、で通信が進行します。これは、任意のモビリティオペレータ自身、あるいは第三者である可能性があります。しかし、一般的にルーティングこのバックボーンは、ほとんどの契約の問題文書の範囲外である、と。
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,
MNは、複数のインタフェースを介してPMIPv6ドメインに接続して、すべてのインターフェイス（参照、[RFC5213]のセクション5.4）で透明なユニキャストハンドオーバを経験することができます。このような同時アクセスのシナリオでは、自律的に（詳細については[RFC5757]を参照）は、個々のインターフェイスにマルチキャストチャネルサブスクリプションを割り当てることができます。そうすることが、
multicast mobility operations described in this document will transparently preserve the association of channels to interfaces in the following way.
この文書に記載されたマルチキャストモビリティ動作は透過的、以下のようにインタフェースへのチャネルの関連付けを保存します。
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のインフラに依存しないマルチキャストサービスは、アクセスネットワーク全体で利用可能な展開シナリオがあるかもしれません。 MAGに直接マルチキャストアクセスのMAGと指定マルチキャストルータ間の専用（トンネルまたはVPN）リンクを介して、又は自動マルチキャストトンネリング（AMT）を展開することで、マルチキャストルータを含むフラットアクセスネットワーク内のネイティブマルチキャストルーティングを介して支持されてもよい[AUTO- MULTICAST]。
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.
マルチキャスト展開は、これらのシナリオに簡略化することができます。マルチキャストクラウドへのアップリンクでのMAGの単一プロキシインスタンスは、例えば、グループ通信の目的を果たすことができました。 MAGは、同様に、一般的なマルチキャストルータまたは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.
[RFC3376]の付録A.2、または付録A.2の[RFC3810]に記載されているようにIGMPv3 / MLDv2のクエリアは、明示的なトラッキングと組み合わせて動作することができます。このメカニズムは、ルータが個別に各マルチキャスト受信を監視することを可能にします。この手順はまだ標準化されていない場合でも、それはより速く休暇の待ち時間と減少シグナリングをサポートして、それが広くベンダーによって実装されます。
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、上のインタフェースです。 MLDv2のための[RFC3810]の宛先MLD / IGMPメッセージのアドレスのMLDv1ために[RFC2710]のセクション8で指定されたものでなければならない、とセクション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.
しかし、特に注意がネットワークエンティティでマルチキャストおよびモビリティ管理を組み合わせた場合の影響に留意する必要があります。本明細書に添付ファイルを変更しながら、移動ノードがのMAGとのLMAでマルチキャスト転送状態の作成を開始することを可能にするように、PMIPのルータとアクセスネットワークにおけるリソースの枯渇の脅威は急速な状態変化から、ならびにアクセスにルーティングされる大量のデータストリームから到着します限られた容量のネットワーク。 MNの適切な権限チェックに加えて、レプリケータにおけるレート制御は、エージェントと下流ネットワークを保護するために必要とされ得ます。 PMIPv6ドメイン内のモバイルマルチキャストリスナーが積極的に出発する前に、グループメンバーシップを終了しないであろうように、特に、のMAGにおけるMLDプロキシ実装は注意深くのMNの出発の自動マルチキャスト状態消光を調達すべきです。
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月）で提示初期の要件の作業を次の、そして広範前回の議論の結果、被験者にいくつかの初期の文書のフォローアップです。著者は、（アルファベット順）ヤリArkko、ルイスM.コントレラス、グレッグ・デイリー、Gorry Fairhurst、ディルク・フォン・ヒューゴ、劉輝、セイルチョン、Jouni Korhonen、広呂、セバスチャン美鈴、アクバル・ラーマン、IMED Romdhaniに感謝したいと思い、ベーチェットSarikaya、Pierrick Seite、スティグVenaas、とフアン・カルロス・スニガアドバイス、ヘルプ、およびドキュメントのレビューのために。 G-LABイニシアティブ内で独連邦教育研究省によって資金を深く感謝しています。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ジョンソン、D.、パーキンス、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、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]フェナー、B.、彼、H.、ハーバーマン、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.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R.およびS. Gundavelli、 "プロキシモバイルIPv6のIPv4サポート"、RFC 5844、2010年5月。
[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]ターラー、D.、Talwar、M.、アガルワル、A.、Vicisano、L.、およびT. Pusateri、 "自動IPマルチキャスト明示的なトンネル（AMT）なし"、進歩、2010年3月に作業。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、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]シュミット、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.、カリル、M.、Gundavelli、S.、およびK.レオン、 "プロキシモバイルIPv6の総称ルーティングカプセル化（GRE）キーオプション"、RFC 5845、2010年6月。
Appendix A. Initial MLD Queries on Upcoming Links
付録A.今後のリンク上の初期MLDクエリー
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]).
IGMP- / MLD対応マルチキャストルータがサブネット上で動作を開始したときに、[RFC3810]と[RFC2710]によると、デフォルトでは、クエリアとしての地位を考慮し、いくつかの一般的なクエリーを送信します。このような初期のクエリはすぐにルータによって送られるべきであるが、（調整可能）スタートアップクエリー間隔（セクション7.6.2および[RFC3810]の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.
MLDクエリはすぐに対応するインターフェイスにIPv6リンクローカルアドレスの自動構成を踏襲しながら、Linuxとシスコシステムに関する実験的試験では、すぐにIGMPクエリーが（1ミリ秒の何分の内）リンクトリガイベントに続い明らかにしました。
Appendix B. State of IGMP/MLD Proxy Implementations
IGMP / MLDプロキシの実装の付録B.州
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]の実装が貢献する必要のMAGで特定のプロキシ機能を必要とします。特に、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.
シスコエッジルータ： - 希薄モード（PIM-SM）ソフトウェアベースの商品・エッジ・ルータ（26xxシリーズから試験装置）のみプロトコル独立マルチキャストとの組み合わせでの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：IPv4トンネルを検査し、カプセル化されたMLDメッセージを検出し、IGMPをサポートしていないのMLDv1 / 2プロキシの実装。実行時インタフェースと複数のインスタンスを動的に追加することを可能にします。しかし、ダウンストリームインターフェイスを構成することができません。プロジェクトページ：http://sourceforge.net/projects/ecmh/
Appendix C. Comparative Evaluation of Different Approaches
異なるアプローチの付録C.比較評価
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.
このセクションでは、我々は簡単にのLMAでのマルチキャストトラフィックの組織のための2つの直交PMIPの概念を評価します。この文書に記載されているように、シナリオAでは、マルチキャストを合わせユニキャスト/マルチキャストのLMAによって提供されます。シナリオBは、ユニキャストハンドオフのMAG独立にパケットをトンネリング専用、中央マルチキャストルータ（「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に接続され、グループのMNのサブスクリプションおよびそれらの関連のLMAに応じて複数のパスを介して同じマルチキャストストリームを受信することができます。この問題は、トンネル収束問題別名、のMAGにおける冗長トラフィックをもたらし得ます。対照的に、シナリオBは、すべての接続のMNのための単一、専用マルチキャストLMAへのトンネルを確立するためのMAGを設定し、マルチキャストアンカーへ間接費を再配置します。これは、冗長なトラフィックを排除しますが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.
MAGで冗長なトラフィックの量とのLMAでの同時ストリームの数：私たちは、2つのメトリックに基づいて、両方のアプローチのコストを定量化します。現実的な値は、トポロジとグループのサブスクリプションモデルによって異なります。 1,000,000のMNの大PMIPドメイン内の拡張性を探るために、我々は、次の2つの極端なマルチキャストの設定を検討してください。
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.
50件のMAGは1つのLMAによって提供することができますしながら、典型的なPMIPの展開は、およそ、1つのMAGに添付5,000のMNが可能になります。したがって1,000,000のMNは、ユニキャスト送信のための4つのLMAによって支え約200のMAGを必要とします。シナリオA、これらのLMAも前方にマルチキャストストリームでは、シナリオBにおいて、一方の追加の専用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のMNは、異なるマルチキャストグループに加入しています。
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のMNは、同一のマルチキャストグループに加入しています。
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.
極端な設定のこれらの考慮事項は、パケットの重複や複製効果がマルチキャストデータサービスの異なるユースケースのための強度を変更して適用することを示しています。しかし、トンネル収束は、すなわち、MAGに到着するデータを複製、のLMA（アバランシェ問題）でストリームの複製よりも拡張性ではるかに小さい問題を起こすん。シナリオAのために、また、シナリオBは、LMA-Mを配布する許可しない間は、ハンドオーバ管理はされていないとして1を設定する際のLMAで高いストリーム複製要件は、PMIPドメイン内に追加のLMAを展開することによって減衰させることができることに留意すべきですLMA-Mでご利用いただけます。
Authors' Addresses
著者のアドレス
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
トーマス・C.シュミットHAWハンブルクベルリナートア7 20099ハンブルクドイツ
EMail: schmidt@informatik.haw-hamburg.de URI: http://inet.cpt.haw-hamburg.de/members/schmidt
電子メール：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
マティアスWählischリンク・ラボ＆FUベルリンHönowerのStr。35 10318ベルリンドイツ
EMail: mw@link-lab.net
メールアドレス：mw@link-lab.net
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
EMail: suresh.krishnan@ericsson.com
メールアドレス：suresh.krishnan@ericsson.com