[要約] RFC 7287は、Proxy Mobile IPv6（PMIPv6）ドメイン内でのモバイルマルチキャスト送信者のサポートに関する仕様です。このRFCの目的は、PMIPv6ネットワークでのモバイルマルチキャスト送信者の動作とインタフェースを定義することです。
Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7287 HAW Hamburg
Category: Experimental S. Gao
ISSN: 2070-1721 H. Zhang
Beijing Jiaotong University
M. Waehlisch
link-lab & FU Berlin
June 2014
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
プロキシモバイルIPv6（PMIPv6）ドメインでのモバイルマルチキャスト送信者のサポート
Abstract
概要
Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.
マルチキャスト通信は、モバイルアクセスゲートウェイにマルチキャストリスナーディスカバリ（MLD）プロキシ機能を導入するか、ISPのアクセスネットワーク内で直接トラフィック分散を使用するか、または選択的なルート最適化スキームによって、ローカルモビリティアンカーを介してプロキシモバイルIPv6（PMIPv6）ドメインで有効にできます。 。このドキュメントでは、3つのシナリオすべてについてPMIPv6ドメインでモバイルマルチキャストセンダーをサポートするための基本的なソリューションと実験的なプロトコルについて説明します。 PMIPv6をPIMと同期するためのプロトコル最適化、およびMLDプロキシのピアリング機能が定義されています。モバイルソースは、常にマルチキャストモビリティ操作に依存しません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7287.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7287で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 15
4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 16
4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 16
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 17
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 18
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 18
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 19
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 19
5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Operations in Support of Multicast Senders . . . . . . . 20
5.4. Operations in Support of Multicast Listeners . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 26
A.1. Operations for Local Multicast Sources . . . . . . . . . 26
A.2. Operations for Local Multicast Subscribers . . . . . . . 26
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 27
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) [RFC6275] 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 Local Mobility Anchor (LMAs) and Mobile Access Gateways (MAGs) are responsible for managing IP mobility on behalf of the mobile node (MN). An MN connected to a PMIPv6 domain, which only operates according to the base specifications of [RFC5213], cannot participate in multicast communication, as MAGs will discard group packets.
プロキシモバイルIPv6（PMIPv6）[RFC5213]は、ネットワークベースの管理機能によってモバイルIPv6（MIPv6）[RFC6275]を拡張し、モビリティ関連のシグナリングに参加することなく、ホストのIPモビリティを可能にします。ローカルモビリティアンカー（LMA）およびモバイルアクセスゲートウェイ（MAG）と呼ばれる追加のネットワークエンティティは、モバイルノード（MN）に代わってIPモビリティを管理します。 [RFC5213]の基本仕様に従ってのみ動作するPMIPv6ドメインに接続されたMNは、MAGがグループパケットを破棄するため、マルチキャスト通信に参加できません。
Multicast support for mobile listeners can be enabled within a PMIPv6 domain by deploying MLD proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors [RFC6224]. This base deployment option is the simplest way to PMIPv6 multicast extensions in the sense that it follows the common PMIPv6 traffic model and neither requires new protocol operations nor additional infrastructure entities. Standard software functions need to be activated on PMIPv6 entities, only, at the price of possibly non-optimal multicast routing.
モバイルリスナーのマルチキャストサポートは、モバイルアクセスゲートウェイにMLDプロキシ機能を展開し、ローカルモビリティアンカー[RFC6224]にマルチキャストルーティング機能を展開することにより、PMIPv6ドメイン内で有効にできます。この基本展開オプションは、一般的なPMIPv6トラフィックモデルに従い、新しいプロトコル操作も追加のインフラストラクチャエンティティも必要としないという意味で、PMIPv6マルチキャスト拡張への最も簡単な方法です。標準のソフトウェア機能は、おそらく最適ではないマルチキャストルーティングを犠牲にして、PMIPv6エンティティでのみアクティブ化する必要があります。
Alternate solutions leverage performance optimization by providing multicast routing at the access gateways directly [MULTI-EXT] or by using selective route optimization schemes [RFC7028]. Such approaches (partially) follow the model of providing multicast data services in parallel to PMIPv6 unicast routing [RFC7161].
代替ソリューションは、アクセスゲートウェイでマルチキャストルーティングを直接提供することによって[MULTI-EXT]、または選択的なルート最適化スキームを使用することによって、パフォーマンスの最適化を活用します[RFC7028]。そのようなアプローチは、（部分的に）PMIPv6ユニキャストルーティング[RFC7161]と並行してマルチキャストデータサービスを提供するモデルに従います。
Multicast listener support satisfies the needs of receptive use cases such as IPTV or server-centric gaming on mobiles. However, current trends in the Internet develop towards user-centric, highly interactive group applications like user-generated streaming, conferencing, collective mobile sensing, etc. Many of these popular applications create group content at end systems and can largely profit from a direct data transmission to a multicast-enabled network.
マルチキャストリスナーのサポートは、IPTVやモバイルでのサーバー中心のゲームなどの受容的なユースケースのニーズを満たします。ただし、インターネットの現在の傾向は、ユーザー生成のストリーミング、会議、集合モバイルセンシングなどのユーザー中心の非常にインタラクティブなグループアプリケーションに向かって発展しています。これらの人気のあるアプリケーションの多くは、エンドシステムでグループコンテンツを作成し、直接データから大きな利益を得ることができます。マルチキャスト対応ネットワークへの送信。
This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for the base deployment scenario [RFC6224], for direct traffic distribution within an ISP's access network, as well as for selective route optimization schemes. The source mobility problem as discussed in [RFC5757] serves as a foundation of this document. Mobile nodes in this setting remain agnostic of multicast mobility operations.
このドキュメントでは、ベース展開シナリオ[RFC6224]のプロキシモバイルIPv6ドメインでのモバイルマルチキャストセンダーのサポートについて、ISPのアクセスネットワーク内での直接トラフィック分散、および選択的なルート最適化スキームについて説明します。 [RFC5757]で説明されているソースモビリティの問題は、このドキュメントの基礎となります。この設定のモバイルノードは、マルチキャストモビリティ操作に依存しません。
This document uses the terminology as defined for the mobility protocols [RFC6275], [RFC5213], and [RFC5844], as well as the multicast routing [RFC4601] and edge-related protocols [RFC3376], [RFC3810], and [RFC4605].
このドキュメントでは、モビリティプロトコル[RFC6275]、[RFC5213]、[RFC5844]、およびマルチキャストルーティング[RFC4601]、エッジ関連プロトコル[RFC3376]、[RFC3810]、および[RFC4605]で定義されている用語を使用します。 。
Throughout this document, we use the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
HNP Home Network Prefix as defined in [RFC5213].
[RFC5213]で定義されているHNPホームネットワークプレフィックス。
MAG Mobile Access Gateway as defined in [RFC5213].
[RFC5213]で定義されているMAGモバイルアクセスゲートウェイ。
MLD Multicast Listener Discovery as defined in [RFC2710] and [RFC3810].
[RFC2710]および[RFC3810]で定義されているMLDマルチキャストリスナーディスカバリ。
PIM Protocol Independent Multicast as defined in [RFC4601].
[RFC4601]で定義されているPIMプロトコル独立マルチキャスト。
PMIPv6 Proxy Mobile IPv6 as defined in [RFC5213].
[RFC5213]で定義されているPMIPv6プロキシモバイルIPv6。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The reference scenario for multicast deployment in Proxy Mobile IPv6 domains is illustrated in Figure 1. It displays the general setting for source mobility -- mobile nodes (MNs) with Home Network Prefixes (HNPs) that receive services via tunnels, which are spanned between a Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role of first-hop access routers that serve multiple MNs on the downstream while running an MLD/IGMP proxy instance for every LMA upstream tunnel.
プロキシモバイルIPv6ドメインでのマルチキャスト展開のリファレンスシナリオを図1に示します。これは、ソースモビリティの一般的な設定を表示します。トンネルを介してサービスを受信するホームネットワークプレフィックス（HNP）を備えたモバイルノード（MN）は、モビリティアクセスゲートウェイ（MAG）でのローカルモビリティアンカーアドレス（LMAA）およびプロキシ気付アドレス（Proxy-CoA）。 MAGは、すべてのLMAアップストリームトンネルに対してMLD / IGMPプロキシインスタンスを実行しながら、ダウンストリームで複数のMNにサービスを提供するファーストホップアクセスルーターの役割を果たします。
+-------------+
| Multicast |
| Listeners |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* 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
Multicast Sender + Listener(s)
マルチキャスト送信者+リスナー
Figure 1: Reference Network for Multicast Deployment in PMIPv6
図1：PMIPv6でのマルチキャスト展開の参照ネットワーク
An MN in a PMIPv6 domain will decide on multicast data transmission completely independent of its current mobility conditions. It will send packets as initiated by applications, using its source address with an HNP and a multicast destination address chosen by application needs. Multicast packets will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these packets in the absence of instructions for packet processing, i.e., a Multicast Routing Information Base (MRIB).
PMIPv6ドメインのMNは、現在のモビリティ条件とは完全に無関係に、マルチキャストデータ送信を決定します。 HNPのある送信元アドレスと、アプリケーションのニーズによって選択されたマルチキャスト宛先アドレスを使用して、アプリケーションによって開始されたとおりにパケットを送信します。マルチキャストパケットは、ダウンストリームのローカル（ワイヤレス）リンクの1つを介して現在アクティブなMAGに到着します。マルチキャスト非対応MAGは、パケット処理の命令、つまりマルチキャストルーティング情報ベース（MRIB）がない場合、これらのパケットを単に破棄します。
An MN can successfully distribute multicast data in PMIPv6, if MLD proxy functions are deployed at the MAG as described in [RFC6224]. In this setup, the MLD proxy instance serving a mobile multicast source has configured its upstream interface at the tunnel towards the MN's corresponding LMA. For each LMA, there will be a separate instance of an MLD proxy.
[RFC6224]で説明されているようにMLDプロキシ機能がMAGに展開されている場合、MNはPMIPv6でマルチキャストデータを正常に配信できます。このセットアップでは、モバイルマルチキャストソースにサービスを提供するMLDプロキシインスタンスは、MNの対応するLMAに向かうトンネルでアップストリームインターフェイスを構成しています。 LMAごとに、MLDプロキシの個別のインスタンスが存在します。
According to the specifications given in [RFC4605], multicast data arriving from a downstream interface of an MLD proxy will be forwarded to the upstream interface and to all but the incoming downstream interfaces that have appropriate forwarding states for this group. Thus, multicast streams originating from an MN will arrive at the corresponding LMA and directly at all mobile receivers co-located at the same MAG and MLD proxy instance. Serving as the designated multicast router or an additional MLD proxy, the LMA forwards data to the fixed Internet, whenever forwarding states are maintained by multicast routing. If the LMA is acting as another MLD proxy, it will forward the multicast data to its upstream interface and to downstream interfaces with matching subscriptions, accordingly.
[RFC4605]で指定されている仕様によれば、MLDプロキシのダウンストリームインターフェイスから到着するマルチキャストデータは、アップストリームインターフェイスと、このグループに適切な転送状態を持つすべての着信ダウンストリームインターフェイスに転送されます。したがって、MNから発信されたマルチキャストストリームは、対応するLMAに到着し、同じMAGおよびMLDプロキシインスタンスに共存するすべてのモバイルレシーバーに直接到着します。 LMAは、指定されたマルチキャストルーターまたは追加のMLDプロキシとして機能し、マルチキャストルーティングによって転送状態が維持される場合は常に、固定インターネットにデータを転送します。 LMAが別のMLDプロキシとして機能している場合は、それに応じて、マルチキャストデータをそのアップストリームインターフェイスと、サブスクリプションが一致するダウンストリームインターフェイスに転送します。
In case of a handover, the MN (being unaware of IP mobility) can continue to send multicast packets as soon as network connectivity is re-established. At this time, the MAG has determined the corresponding LMA, and IPv6 unicast address configuration (including PMIPv6 bindings) has been completed. Still, multicast packets arriving at the MAG are discarded (if not buffered) until the MAG has completed the following steps.
ハンドオーバーの場合、ネットワーク接続が再確立されるとすぐに、（IPモビリティを認識しない）MNはマルチキャストパケットを送信し続けることができます。この時点で、MAGは対応するLMAを決定し、IPv6ユニキャストアドレスの構成（PMIPv6バインディングを含む）が完了しています。それでも、MAGに到着するマルチキャストパケットは、MAGが次の手順を完了するまで廃棄されます（バッファされていない場合）。
1. The MAG has determined that the MN is admissible to multicast services.
1. MAGは、MNがマルチキャストサービスを受け入れることができると判断しました。
2. The MAG has added the new downstream link to the MLD proxy instance with an uplink to the corresponding LMA.
2. MAGは、対応するLMAへのアップリンクを持つ新しいダウンストリームリンクをMLDプロキシインスタンスに追加しました。
As soon as the MN's uplink is associated with the corresponding MLD proxy instance, multicast packets are forwarded again to the LMA and eventually to receivers within the PMIP domain. (See the call flow in Figure 2.) In this way, multicast source mobility is transparently enabled in PMIPv6 domains that deploy the base scenario for multicast.
MNのアップリンクが対応するMLDプロキシインスタンスに関連付けられるとすぐに、マルチキャストパケットが再びLMAに転送され、最終的にはPMIPドメイン内の受信者に転送されます。 （図2のコールフローを参照してください。）この方法で、マルチキャストソースモビリティは、マルチキャストの基本シナリオを展開するPMIPv6ドメインで透過的に有効になります。
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| | Mcast Data | | |
| |<---------------+ | |
| | Mcast Data | | |
| Join(G) +================================================>|
+--------------> | | | |
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | < MLD Proxy Configuration > |
| | | | |
| | | (MLD Query) | |
| | |<--------------+ |
| | | Mcast Data | |
| | +-------------->| |
| | | | Mcast Data |
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
Legend: Rtr Sol - ICMPv6 Router Solicitation Rtr Adv - ICMPv6 Router Advertisement
凡例：Rtr Sol-ICMPv6ルーター要請Rtr Adv-ICMPv6ルーターアドバタイズメント
Figure 2: Call Flow for Group Communication in Multicast-Enabled PMIP
図2：マルチキャスト対応PMIPでのグループ通信のコールフロー
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]. IPv4 multicast is handled by an IGMP proxy function at the MAG in an analogous way.
同様に、これらのマルチキャスト展開の考慮事項は、PMIPv6ドメインでIPv4スタックを有効にして動作するモバイルノードに適用されます。 PMIPv6はIPv4ホームアドレスモビリティサポートを提供できます[RFC5844]。 IPv4マルチキャストは、MAGのIGMPプロキシ機能によって同様の方法で処理されます。
Following these deployment steps, multicast traffic distribution transparently interoperates with PMIPv6. It is worth noting that an MN -- while being attached to the same MAG as the mobile source, but associated with a different LMA -- cannot receive multicast traffic on a shortest path. Instead, multicast streams flow up to the LMA of the mobile source, are transferred to the LMA of the mobile listener, and are tunneled downwards to the MAG again. (See Section 5 for further optimizations.)
これらの展開手順に従って、マルチキャストトラフィック配信は、透過的にPMIPv6と相互運用します。 MNは、モバイルソースと同じMAGに接続されているが、異なるLMAに関連付けられているため、最短パスでマルチキャストトラフィックを受信できないことに注意してください。代わりに、マルチキャストストリームはモバイルソースのLMAまで流れ、モバイルリスナーのLMAに転送され、MAGに向けて下向きにトンネルされます。 （さらなる最適化については、セクション5を参照してください。）
Support of multicast source mobility in PMIPv6 requires that general multicast functions be deployed at PMIPv6 routers and that their interactions with the PMIPv6 protocol be defined as follows.
PMIPv6でマルチキャストソースモビリティをサポートするには、一般的なマルチキャスト機能をPMIPv6ルーターに展開し、PMIPv6プロトコルとの相互作用を次のように定義する必要があります。
A mobile node willing to send multicast data will proceed as if attached to the fixed Internet. No specific mobility or other multicast-related functionalities are required at the MN.
マルチキャストデータを送信するモバイルノードは、固定インターネットに接続されているかのように処理されます。 MNでは、特定のモビリティやその他のマルチキャスト関連の機能は必要ありません。
A Mobile Access Gateway is required to have MLD proxy instances deployed, one for each tunnel to an LMA, which serves as its unique upstream link (cf. [RFC6224]). On the arrival of an MN, the MAG decides on the mapping of downstream links to a proxy instance and the upstream link to the LMA based on the regular Binding Update List as maintained by PMIPv6 standard operations. When multicast data is received from the MN, the MAG MUST identify the corresponding proxy instance from the incoming interface and forwards multicast data upstream according to [RFC4605].
モバイルアクセスゲートウェイには、MLDプロキシインスタンスを展開する必要があります。LMAへのトンネルごとに1つあり、LMAは、独自のアップストリームリンクとして機能します（[RFC6224]を参照）。 MAGはMNの到着時に、PMIPv6標準操作によって維持される通常のバインディングアップデートリストに基づいて、プロキシインスタンスへのダウンストリームリンクとLMAへのアップストリームリンクのマッピングを決定します。マルチキャストデータがMNから受信されると、MAGは着信インターフェイスから対応するプロキシインスタンスを識別し、[RFC4605]に従ってマルチキャストデータをアップストリームに転送する必要があります。
The MAG MAY apply special admission control to enable multicast data transmission from an MN. It is advisable to take special care that MLD proxy implementations do not redistribute multicast data to downstream interfaces without appropriate subscriptions in place.
MAGは、MNからのマルチキャストデータ送信を可能にするために、特別なアドミッションコントロールを適用する場合があります。 MLDプロキシの実装では、適切なサブスクリプションを設定せずに、マルチキャストデータをダウンストリームインターフェイスに再配布しないように特別な注意を払うことをお勧めします。
For any MN, the Local Mobility Anchor acts as the persistent Home Agent and at the same time as the default multicast upstream for the corresponding MAG. It will manage and maintain a multicast forwarding information base for all group traffic arriving from its mobile sources. It SHOULD participate in multicast routing functions that enable traffic redistribution to all adjacent LMAs within the PMIPv6 domain and thereby ensure a continuous receptivity while the source is in motion.
どのMNでも、ローカルモビリティアンカーは永続的なホームエージェントとして機能すると同時に、対応するMAGのデフォルトのマルチキャストアップストリームとして機能します。モバイルソースから到着するすべてのグループトラフィックのマルチキャスト転送情報ベースを管理および維持します。それは、PMIPv6ドメイン内の隣接するすべてのLMAへのトラフィックの再配布を可能にするマルチキャストルーティング機能に参加して、ソースが動いている間も継続的な受容性を確保する必要があります。
Local Mobility Anchors that operate the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol [RFC4601] will require sources to be directly connected for sending PIM registers to the Rendezvous Point (RP). This does not hold in a PMIPv6 domain, as MAGs are routers intermediate to the MN and the LMA. In this sense, MNs are multicast sources external to the PIM-SM domain.
Protocol Independent Multicast-Sparse Mode（PIM-SM）routing protocol [RFC4601]を操作するローカルモビリティアンカーは、PIMレジスタをRendezvous Point（RP）に送信するためにソースを直接接続する必要があります。 MAGはMNとLMAの中間にあるルーターであるため、これはPMIPv6ドメインには当てはまりません。この意味で、MNはPIM-SMドメインの外部のマルチキャストソースです。
To mitigate this incompatibility common to all subsidiary MLD proxy domains, the LMA MUST act as a PIM Border Router and activate the Border-bit. In this case, the DirectlyConnected(S) is treated as being TRUE for mobile sources and the PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel interface from MAG to LMA is not considered part of the PIM-SM component of the LMA (see Appendix A.1 of [RFC4601] ).
すべての従属MLDプロキシドメインに共通するこの非互換性を軽減するために、LMAはPIMボーダールータとして機能し、ボーダービットをアクティブ化する必要があります。この場合、DirectlyConnected（S）はモバイルソースに対してTRUEとして扱われ、PIM-SM転送ルール「iif == RPF_interface（S）」は、MAGからLMAへの着信トンネルインターフェイスがTRUEに緩和されます。 LMAのPIM-SMコンポーネントの一部と見なされます（[RFC4601]の付録A.1を参照）。
In addition, an LMA serving as the PIM Designated Router (DR) is connected to MLD proxies via individual IP tunnel interfaces and will experience changing PIM source states on handover. As the incoming interface connects to a point-to-point link, PIM Assert contention is not active, and incoming interface validation is only performed by Reverse Path Forwarding (RPF) checks. Consequently, a PIM DR SHOULD update incoming source states, as soon as RPF inspection succeeds, i.e., after the PMIPv6 forwarding state update. Consequently, PIM routers SHOULD be able to manage these state changes, but some implementations are expected to incorrectly refuse packets until the previous state has timed out.
さらに、PIM指定ルーター（DR）として機能するLMAは、個々のIPトンネルインターフェイスを介してMLDプロキシに接続され、ハンドオーバー時にPIMソースの状態が変化します。着信インターフェイスはポイントツーポイントリンクに接続するため、PIMアサートの競合はアクティブではなく、着信インターフェイスの検証は、Reverse Path Forwarding（RPF）チェックによってのみ実行されます。したがって、RPMインスペクションが成功するとすぐに、つまりPMIPv6転送状態の更新後に、PIM DRは着信ソースの状態を更新する必要があります（SHOULD）。その結果、PIMルーターはこれらの状態変化を管理できるはずですが、一部の実装では、前の状態がタイムアウトするまで、パケットを誤って拒否することが予想されます。
Notably, running Bidirectional PIM (BIDIR-PIM) [RFC5015] on LMAs remains robust with respect to source location and does not require special configurations or state management for sources.
特に、LMAで双方向PIM（BIDIR-PIM）[RFC5015]を実行すると、ソースの場所に関して堅牢であり、ソースの特別な構成や状態管理を必要としません。
An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844]. For this purpose, an LMA can register an IPv4-Proxy-CoA in its Binding Cache, and the MAG can provide IPv4 support in its access network. 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-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 they 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クエリを並行して送信できます（MAY）。さらに、IPv4およびIPv6マルチキャストグループを介して配信される場合、インフラストラクチャは2つのデータストリームを同一として識別できないことに注意してください。したがって、重複したデータが異種ネットワーク層で転送される可能性があります。
The following points are worth noting about the scenario in [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]のシナリオについて注目に値します。このシナリオでは、異なるオペレーターの重複するプライベートアドレススペースを、キー識別付きのGeneric Routing Encapsulation（GRE）を使用してPMIPドメインでホストできます。このシナリオは、MAG-LMAトンネル内のユニキャスト通信が、GREキーによってMNごとに個別に識別できることを意味します。このシナリオでは、次の理由により、マルチキャスト通信の特別な扱いはまだありません。
Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). Multicast data transmission from the MAG to the corresponding LMA is link-local between the routers and routing/forwarding remains independent of any individual MN. So, the MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain GRE in multicast communication (including MLD queries and reports). Multicast traffic is transmitted using router-to-router forwarding via the MAG-to-LMA tunnels and according to the MRIB of the MAG or the LMA. It remains independent of MN's unicast addresses, while the MAG proxy instance redistributes multicast data down the point-to-point links (interfaces) according to its local subscription states, independent of IP addresses of the MN.
MNとの間のマルチキャストストリームは、ポイントツーポイントリンク（ユニキャストと同じ）でMAGに到達します。 MAGから対応するLMAへのマルチキャストデータ送信は、ルーター間でリンクローカルであり、ルーティング/転送は、個々のMNから独立しています。したがって、MAGプロキシとLMAはGREキー識別子を使用すべきではなく（SHOULD）、マルチキャスト通信（MLDクエリとレポートを含む）ではプレーンGREを使用します。マルチキャストトラフィックは、MAG-to-LMAトンネル経由のルーター間転送を使用して、MAGまたはLMAのMRIBに従って送信されます。 MAGプロキシインスタンスは、MNのIPアドレスとは無関係に、ローカルサブスクリプションの状態に応じてマルチキャストデータをポイントツーポイントリンク（インターフェイス）に再配布しますが、MNのユニキャストアドレスには依存しません。
The distribution system of the base solution directly follows PMIPv6 routing rules and organizes multicast domains with respect to LMAs. Thus, no coordination between address spaces or services is required between the different instances, provided their associated LMAs belong to disjoint multicast domains. Routing is optimal for communication between MNs of the same domain or stationary subscribers.
基本ソリューションの配信システムは、PMIPv6ルーティングルールに直接従い、LMAに関してマルチキャストドメインを編成します。したがって、関連付けられたLMAが独立したマルチキャストドメインに属している場合は、異なるインスタンス間でアドレス空間またはサービス間の調整は必要ありません。ルーティングは、同じドメインのMN間または固定加入者間の通信に最適です。
In the following situations, efficiency-related issues remain.
以下の状況では、効率に関連する問題が残っています。
Multicast reception at LMA In the current deployment scenario, the LMA will receive all multicast traffic originating from its associated MNs. There is no mechanism to suppress upstream forwarding in the absence of receivers.
LMAでのマルチキャスト受信現在の展開シナリオでは、LMAは関連するMNから発信されたすべてのマルチキャストトラフィックを受信します。レシーバーがない場合、アップストリーム転送を抑制するメカニズムはありません。
MNs on the same MAG using different LMAs For a mobile receiver and a source that use different LMAs, the traffic has to go up to one LMA, cross over to the other LMA, and then be tunneled back to the same MAG, causing redundant flows in the access network and at the MAG.
異なるLMAを使用する同じMAG上のMN異なるLMAを使用するモバイルレシーバーとソースの場合、トラフィックは1つのLMAに到達し、他のLMAに渡り、同じMAGにトンネリングされ、冗長フローを引き起こす必要があります。アクセスネットワークとMAGで。
These remaining deficits in routing efficiency can be resolved by adding peering functions to MLD proxies as described in Section 5.
セクション5で説明されているように、MLDプロキシにピアリング機能を追加することで、ルーティング効率のこれらの残りの不足を解決できます。
There are deployment scenarios, where multicast services are available throughout the access network independent of the PMIPv6 routing system [RFC7028]. In these cases, the visited networks grant a local content distribution service (in contrast to LMA-based home subscription) with locally optimized traffic flows. It is also possible to deploy a mixed service model of local and LMA-based subscriptions, provided that a unique way of service selection is implemented. For example, access routers (MAGs) could decide on service access based on the multicast address G or the source-specific multicast (SSM) channel (S,G) under request. (See Appendix A for further discussions.)
PMIPv6ルーティングシステム[RFC7028]とは無関係に、アクセスネットワーク全体でマルチキャストサービスを利用できる展開シナリオがあります。これらの場合、訪問先ネットワークは、ローカルに最適化されたトラフィックフローを使用して、ローカルコンテンツ配信サービス（LMAベースのホームサブスクリプションとは対照的）を許可します。独自のサービス選択方法が実装されている場合は、ローカルサブスクリプションとLMAベースのサブスクリプションの混合サービスモデルを展開することもできます。たとえば、アクセスルータ（MAG）は、要求に応じて、マルチキャストアドレスGまたはソース固有のマルチキャスト（SSM）チャネル（S、G）に基づいてサービスアクセスを決定できます。 （詳細については、付録Aを参照してください。）
Direct multicast access can be supported by
ダイレクトマルチキャストアクセスは、
o native multicast routing provided by one multicast router that is neighboring MLD proxies deployed at MAGs within a flat access network, or via tunnel uplinks,
o フラットアクセスネットワーク内のMAGに配置された隣接MLDプロキシである1つのマルチキャストルーターによって、またはトンネルアップリンクを介して提供されるネイティブマルチキャストルーティング
o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM [RFC5015] deployed at the MAGs.
o MAGに展開されたPIM-SM [RFC4601]またはBIDIR-PIM [RFC5015]などのマルチキャストルーティングプロトコル。
*** *** *** ***
* ** ** ** *
* *
* Multicast *
+----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+
| // \\ |
\\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *//
|| || || || * || Routing || *
+----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***|
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
（a）プロキシアップリンクでのマルチキャストアクセス（b）MAGでのマルチキャストルーティング
Figure 3: Reference Networks for (a) Proxy-Assisted Direct Multicast Access and (b) Dynamic Multicast Routing at MAGs
図3：（a）プロキシ支援直接マルチキャストアクセスと（b）MAGでの動的マルチキャストルーティングの参照ネットワーク
Figure 3 displays the corresponding deployment scenarios that separate multicast from PMIPv6 unicast routing. It is assumed throughout these scenarios that all MAGs (MLD proxies) are linked to a single multicast routing domain. Notably, this scenario requires coordination of multicast address utilization and service bindings.
図3は、PMIPv6ユニキャストルーティングからマルチキャストを分離する、対応する展開シナリオを示しています。これらのシナリオ全体で、すべてのMAG（MLDプロキシ）が単一のマルチキャストルーティングドメインにリンクされていると想定しています。特に、このシナリオでは、マルチキャストアドレスの利用とサービスバインディングの調整が必要です。
Multicast traffic distribution can be simplified in these scenarios. A single proxy instance at MAGs with uplinks into the multicast domain will serve as a first-hop multicast gateway and avoid traffic duplication or detour routing. Multicast routing functions at MAGs will seamlessly embed access gateways within a multicast cloud. However, mobility of the multicast source in this scenario will require some multicast routing protocols to rebuild distribution trees. This can cause significant service disruptions or delays (see [RFC5757] for further aspects). Deployment details are specific to the multicast routing protocol in use; this is described below for common protocols.
これらのシナリオでは、マルチキャストトラフィックの分散を簡素化できます。マルチキャストドメインへのアップリンクがあるMAGの単一のプロキシインスタンスは、ファーストホップマルチキャストゲートウェイとして機能し、トラフィックの重複や迂回ルーティングを回避します。 MAGのマルチキャストルーティング機能は、マルチキャストクラウド内にアクセスゲートウェイをシームレスに埋め込みます。ただし、このシナリオでのマルチキャストソースのモビリティには、配信ツリーを再構築するためにいくつかのマルチキャストルーティングプロトコルが必要になります。これにより、サービスの大幅な中断または遅延が発生する可能性があります（詳細については、[RFC5757]を参照してください）。展開の詳細は、使用中のマルチキャストルーティングプロトコルに固有です。これについては、一般的なプロトコルについて以下で説明します。
In a PMIPv6 domain, single MLD proxy instances can be deployed at each MAG that enable multicast service at the access via an uplink to a multicast service infrastructure (see Figure 3(a)). To avoid service disruptions on handovers, the uplinks of all proxies SHOULD be adjacent to the same next-hop multicast router. This can either be achieved by arranging proxies within a flat access network or by using upstream tunnels that terminate at a common multicast router.
PMIPv6ドメインでは、各MAGに単一のMLDプロキシインスタンスを展開できます。これにより、マルチキャストサービスインフラストラクチャへのアップリンクを介したアクセスでマルチキャストサービスが可能になります（図3（a）を参照）。ハンドオーバーによるサービスの中断を回避するために、すべてのプロキシのアップリンクは、同じネクストホップマルチキャストルーターに隣接している必要があります。これは、フラットアクセスネットワーク内でプロキシを配置するか、共通のマルチキャストルーターで終端するアップストリームトンネルを使用することで実現できます。
Multicast data submitted by a mobile source will reach the MLD proxy at the MAG that subsequently forwards flows to the upstream and to all downstream interfaces with appropriate subscriptions. Traversing the upstream will transfer traffic into the multicast infrastructure (e.g., to a PIM Designated Router) that will route packets to all local MAGs that have joined the group, as well as further upstream according to protocol procedures and forwarding states.
モバイルソースによって送信されたマルチキャストデータは、MAGのMLDプロキシに到達し、その後、適切なサブスクリプションを使用して、フローをアップストリームおよびすべてのダウンストリームインターフェイスに転送します。アップストリームを通過すると、グループに参加しているすべてのローカルMAGにパケットをルーティングするマルチキャストインフラストラクチャ（PIM指定ルーターなど）にトラフィックが転送され、さらにプロトコル手順と転送状態に従ってアップストリームに転送されます。
On handover, a mobile source will reattach to a new MAG and can continue to send multicast packets as soon as PMIPv6 unicast configurations have been completed. Like at the previous MAG, the new MLD proxy will forward data upstream and downstream to subscribers. Listeners local to the previous MAG will continue to receive group traffic via the local multicast distribution infrastructure following aggregated listener reports of the previous proxy. In general, traffic from the mobile source continues to be transmitted via the same next-hop multicast router using the same source address and thus remains unchanged when seen from the wider multicast infrastructure.
ハンドオーバー時に、モバイルソースは新しいMAGに再接続し、PMIPv6ユニキャスト構成が完了するとすぐにマルチキャストパケットを送信し続けることができます。以前のMAGと同様に、新しいMLDプロキシは、アップストリームとダウンストリームのデータをサブスクライバーに転送します。以前のMAGのローカルリスナーは、以前のプロキシのリスナーレポートが集約された後、引き続きローカルマルチキャスト配信インフラストラクチャを介してグループトラフィックを受信します。一般に、モバイルソースからのトラフィックは、同じソースアドレスを使用する同じネクストホップマルチキャストルーターを介して送信され続けるため、より広いマルチキャストインフラストラクチャから見た場合、変更されません。
A mobile source that transmits data via an MLD proxy will not be directly connected to a PIM Designated Router as discussed in Section 3.2.3.1. Countermeasures apply correspondingly.
MLDプロキシを介してデータを送信するモバイルソースは、セクション3.2.3.1で説明されているように、PIM指定ルーターに直接接続されません。対応策も同様に適用されます。
A PIM Designated Router that is connected to MLD proxies via individual IP tunnel interfaces will experience invalid PIM source states on handover. In some implementations of PIM-SM, this could lead to an interim packet loss (see Section 3.2.3.1). This problem can be mitigated by aggregating proxies on a lower layer.
個々のIPトンネルインターフェイスを介してMLDプロキシに接続されているPIM指定ルーターは、ハンドオーバー時に無効なPIMソース状態になります。 PIM-SMの一部の実装では、これにより一時的なパケット損失が発生する可能性があります（セクション3.2.3.1を参照）。この問題は、下位層でプロキシを集約することで軽減できます。
Source-specific subscriptions invalidate with routes, whenever the source moves from or to the MAG/proxy of a subscriber. Multicast forwarding states will rebuild with unicast route changes. However, this may lead to noticeable service disruptions for locally subscribed nodes.
ソース固有のサブスクリプションは、ソースがサブスクライバーのMAG /プロキシから、またはMAG /プロキシに移動するたびに、ルートで無効になります。マルチキャスト転送状態は、ユニキャストルートが変更されると再構築されます。ただし、これにより、ローカルでサブスクライブしているノードのサービスが著しく中断する場合があります。
The full-featured multicast routing protocol PIM-SM MAY be deployed in the access network for providing multicast services in parallel to unicast routes (see Figure 3(b)). Throughout this section, it is assumed that the PMIPv6 mobility domain is part of a single PIM-SM multicast routing domain with PIM-SM routing functions present at all MAGs and all LMAs. The PIM routing instance at a MAG SHALL then serve as the Designated Router (DR) for all directly attached Mobile Nodes. For expediting handover operations, it is advisable to position PIM Rendezvous Points (RPs) in the core of the PMIPv6 network domain. However, regular IP routing tables need not be present in a PMIPv6 deployment, and additional effort is required to establish reverse path forwarding rules as required by PIM-SM.
ユニキャストルートと並行してマルチキャストサービスを提供するために、フル機能のマルチキャストルーティングプロトコルPIM-SMをアクセスネットワークに展開できます（図3（b）を参照）。このセクション全体で、PMIPv6モビリティドメインは、すべてのMAGおよびすべてのLMAにPIM-SMルーティング機能が存在する単一のPIM-SMマルチキャストルーティングドメインの一部であると想定しています。 MAG SHALLのPIMルーティングインスタンスは、直接接続されたすべてのモバイルノードの指定ルーター（DR）として機能します。ハンドオーバー操作を効率化するには、PMIPv6ネットワークドメインのコアにPIMランデブーポイント（RP）を配置することをお勧めします。ただし、通常のIPルーティングテーブルはPMIPv6展開に存在する必要はなく、PIM-SMで必要なリバースパス転送ルールを確立するために追加の作業が必要です。
In this scenario, PIM-SM will rely on a Multicast Routing Information Base (MRIB) that is generated independently of the policy-based routing rules of PMIPv6. The granularity of mobility-related routing locators required in PIM depends on the complexity (specific phase) of its deployment.
このシナリオでは、PIM-SMは、PMIPv6のポリシーベースのルーティングルールとは無関係に生成されるマルチキャストルーティング情報ベース（MRIB）に依存します。 PIMで必要なモビリティ関連のルーティングロケータの粒度は、その展開の複雑さ（特定のフェーズ）によって異なります。
For all three phases in the operation of PIM (see [RFC4601]), the following information is needed.
PIM（[RFC4601]を参照）の操作の3つのフェーズすべてについて、次の情報が必要です。
o All routes to networks and nodes (including RPs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among PIM routers and MUST remain unaffected by node mobility. The setup of these general routes is expected to follow the topology of the operator network and is beyond the scope of this document.
o PMIPv6ドメインのモバイルメンバーではないネットワークおよびノード（RPを含む）へのすべてのルートは、PIMルーター間で一貫して定義する必要があり、ノードモビリティの影響を受けないようにする必要があります。これらの一般的なルートの設定は、オペレーターネットワークのトポロジーに従うことが予想され、このドキュメントの範囲を超えています。
The following route entries are required at a PIM-operating MAG when phase two or three of PIM or PIM-SSM is in operation.
次のルートエントリは、PIMまたはPIM-SSMのフェーズ2または3が動作しているときに、PIMが動作するMAGで必要です。
o Local routes to the Home Network Prefixes (HNPs) of all MNs associated with their corresponding point-to-point attachments that MUST be included in the local MRIB.
o ローカルMRIBに含める必要がある対応するポイントツーポイント接続に関連付けられているすべてのMNのホームネットワークプレフィックス（HNP）へのローカルルート。
o All routes to MNs that are attached to distant MAGs of the PMIPv6 domain point towards their corresponding LMAs. These routes MUST be made available in the MRIB of all PIM routers (except for the local MAG of attachment), but they MAY be eventually expressed by an appropriate default entry.
o PMIPv6ドメインの遠いMAGに接続されているMNへのすべてのルートは、対応するLMAを指します。これらのルートは、すべてのPIMルーター（アタッチメントのローカルMAGを除く）のMRIBで利用可能にする必要があります（MUST）が、最終的には適切なデフォルトエントリによって表現される場合があります。
A new mobile source S will transmit multicast data of group G towards its MAG of attachment. Acting as a PIM DR, the access gateway will unicast-encapsulate the multicast packets and forward the data to the Virtual Interface (VI) with encapsulation target RP(G), a process known as "PIM source registering". The RP will decapsulate and natively forward the packets down the RP-based distribution tree towards (mobile and stationary) subscribers.
新しいモバイルソースSは、アタッチメントのMAGに向かってグループGのマルチキャストデータを送信します。 PIM DRとして機能するアクセスゲートウェイは、マルチキャストパケットをユニキャストカプセル化し、データをカプセル化ターゲットRP（G）を使用して仮想インターフェイス（VI）に転送します。これは「PIMソース登録」と呼ばれるプロセスです。 RPはカプセル化を解除し、パケットをRPベースの配信ツリーから（モバイルおよび固定）サブスクライバに向けてネイティブに転送します。
On handover, the point-to-point link connecting the mobile source to the old MAG will go down and all (S,*) flows terminate. In response, the previous DR (MAG) deactivates the data encapsulation channels for the transient source (i.e., all DownstreamJPState(S,*,VI) are set to NoInfo state). After reattaching and completing unicast handover negotiations, the mobile source can continue to transmit multicast packets, while being treated as a new source at its new DR (MAG). Source register encapsulation will be immediately initiated, and (S,G) data continue to flow natively down the (*,G) RP-based tree.
ハンドオーバー時に、モバイルソースを古いMAGに接続するポイントツーポイントリンクがダウンし、すべての（S、*）フローが終了します。それに応じて、以前のDR（MAG）は一時的なソースのデータカプセル化チャネルを非アクティブ化します（つまり、すべてのDownstreamJPState（S、*、VI）がNoInfo状態に設定されます）。ユニキャストハンドオーバネゴシエーションを再接続して完了した後、モバイルソースは、新しいDR（MAG）で新しいソースとして扱われながら、マルチキャストパケットを送信し続けることができます。ソースレジスタのカプセル化はすぐに開始され、（S、G）データは（*、G）RPベースのツリーにネイティブで流れ続けます。
Source handover management in PIM phase one admits low complexity and remains transparent to receivers. In addition, the source register tunnel management of PIM is a fast protocol operation that introduces little overhead. In a PMIPv6 deployment, PIM RPs MAY be configured to uninitiated (S,G) shortest path trees for mobile sources, and thus remain in phase one of the protocol. The price to pay for such simplified deployment lies in possible routing detours by an overall RP-based packet distribution.
PIMフェーズ1のソースハンドオーバー管理は、複雑さが低いことを認めており、レシーバーに対して透過的です。さらに、PIMのソースレジスタトンネル管理は、オーバーヘッドがほとんどない高速プロトコル操作です。 PMIPv6展開では、PIM RPは、モバイルソースの開始されていない（S、G）最短パスツリーに設定される場合があり、したがって、プロトコルのフェーズ1のままです。このような簡素化された展開に支払う代償は、全体的なRPベースのパケット配信によるルーティングの迂回の可能性にあります。
After receiving source register packets, a PIM RP eventually will initiate a source-specific Join for creating a shortest path tree to the (mobile) source S and issue a source register stop at the native arrival of data from S. For initiating an (S,G) tree, the RP, as well as all intermediate routers, require route entries for the HNP of the MN that -- unless the RP coincides with the MAG of S -- point towards the corresponding LMA of S. Consequently, the (S,G) tree will proceed from the RP via the (stable) LMA, down the LMA-MAG tunnel to the mobile source. This tree can be of lower routing efficiency than the PIM source register tunnel established in phase one.
ソースレジスタパケットを受信した後、PIM RPは最終的に（モバイル）ソースSへの最短パスツリーを作成するためのソース固有の結合を開始し、Sからのデータのネイティブ到着時にソースレジスタストップを発行します。 、G）ツリー、RP、およびすべての中間ルーターは、MNのHNPのルートエントリを必要とします。これは、RPがSのMAGと一致しない限り、Sの対応するLMAを指します。したがって、（ S、G）ツリーは、RPから（安定した）LMAを経由して、LMA-MAGトンネルを下ってモバイルソースに進みます。このツリーは、フェーズ1で確立されたPIMソースレジスタトンネルよりもルーティング効率が低い場合があります。
On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new point of attachment. However, in the absence of a corresponding multicast forwarding state, the new DR will treat S as a new source and initiate a source registering of PIM phase one with the RP. In response, the PIM RP will recognize the known source at a new (tunnel) interface and will immediately respond with a register stop. As the RP had previously joined the shortest path tree towards the source via the LMA, it will see an RPF change when data arrives at a new interface. This is implementation dependent and can trigger an update of the PIM MRIB as well as a new PIM Join message that will install the multicast forwarding state missing at the new MAG. Otherwise, the tree is periodically updated by Joins transmitted towards the new MAG on a path via the LMA. In proceeding this way, a quick recovery of PIM transition from phase one to two will be performed per handover.
ハンドオーバー時に、モバイルソースは新しいMAG（DR）に再接続し、PMIPv6ユニキャスト管理はLMA-MAGトンネルを新しい接続ポイントに転送します。ただし、対応するマルチキャスト転送状態がない場合、新しいDRはSを新しいソースとして扱い、PIMフェーズ1のソース登録をRPに開始します。これに応答して、PIM RPは新しい（トンネル）インターフェイスで既知のソースを認識し、すぐにレジスタストップで応答します。 RPは以前にLMAを介してソースに向かう最短パスツリーに参加していたため、データが新しいインターフェイスに到着すると、RPFが変化します。これは実装に依存し、PIM MRIBの更新と、新しいMAGで欠落しているマルチキャスト転送状態をインストールする新しいPIM加入メッセージをトリガーできます。それ以外の場合、ツリーは定期的に、LMA経由のパス上の新しいMAGに送信される結合によって更新されます。このように進めると、フェーズ1からフェーズ2へのPIM移行の迅速な回復が、ハンドオーバーごとに実行されます。
In response to an exceeded threshold of packet transmission, DRs of receivers eventually will initiate a source-specific Join for creating a shortest path tree to the (mobile) source S, thereby transitioning PIM into the final shortcut phase three. For all receivers not sharing a MAG with S, this (S,G) tree will range from the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the serving MAG to the mobile source. This tree is of higher routing efficiency than that established in the previous phase two, but it need not outperform the PIM source register tunnel established in phase one. It provides the advantage of immediate data delivery to receivers that share a MAG with S.
パケット送信のしきい値を超えたことに応じて、レシーバーのDRは最終的に（モバイル）ソースSへの最短パスツリーを作成するためのソース固有の結合を開始し、PIMを最終的なショートカットフェーズ3に移行します。 MAGをSと共有していないすべてのレシーバーの場合、この（S、G）ツリーは、受信DRから（安定した）LMA、LMA-MAGトンネル、およびサービングMAGを経由してモバイルソースまでの範囲になります。このツリーは、前のフェーズ2で確立されたツリーよりもルーティング効率が高くなりますが、フェーズ1で確立されたPIMソースレジスタトンネルを上回る必要はありません。これは、MAGをSと共有する受信機への即時データ配信の利点を提供します。
On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new point of attachment. However, in the absence of a corresponding multicast forwarding state, the new DR will treat S as a new source and initiate a source registering of PIM phase one. A PIM implementation compliant with this change can recover phase three states in the following way. First, the RP recovers to phase two as described in the previous section and will not forward data arriving via the source register tunnel. Tree maintenance eventually triggered by the RPF change (see Section 4.3.3) will generate proper states for a native forwarding from the new MAG via the LMA. Thereafter, packets arriving at the LMA without source register encapsulation are forwarded natively along the shortest path tree towards receivers.
ハンドオーバー時に、モバイルソースは新しいMAG（DR）に再接続し、PMIPv6ユニキャスト管理はLMA-MAGトンネルを新しい接続ポイントに転送します。ただし、対応するマルチキャスト転送状態がない場合、新しいDRはSを新しいソースとして扱い、PIMフェーズ1のソース登録を開始します。この変更に準拠したPIM実装では、次の方法でフェーズ3の状態を回復できます。まず、前のセクションで説明したように、RPはフェーズ2に回復し、ソースレジスタトンネル経由で到着したデータを転送しません。最終的にRPFの変更（セクション4.3.3を参照）によってトリガーされたツリーのメンテナンスにより、LMAを介して新しいMAGからネイティブに転送するための適切な状態が生成されます。その後、ソースレジスタカプセル化なしでLMAに到着したパケットは、最短パスツリーに沿ってネイティブに受信者に転送されます。
In consequence, the PIM transitions from phase one to two to three will be quickly recovered per handover but still lead to an enhanced signaling load and intermediate packet loss.
その結果、フェーズ1からフェーズ2からフェーズ3へのPIM移行は、ハンドオーバーごとに迅速に回復されますが、シグナリング負荷の増加と中間パケット損失につながります。
Source-specific Joins of receivers will guide PIM to operate in SSM mode and lead to an immediate establishment of source-specific shortest path trees. Such (S,G) trees will equal the distribution system of PIM's final phase three (see Section 4.3.4). However, on handover and in the absence of RP-based data distribution, SSM data delivery cannot be resumed via source registering as in PIM phase one. Consequently, data packets transmitted after a handover will be discarded at the MAG until regular tree maintenance has reestablished the (S,G) forwarding state at the new MAG.
レシーバーのソース固有の結合により、PIMがSSMモードで動作するようになり、ソース固有の最短パスツリーが即座に確立されます。このような（S、G）ツリーは、PIMの最終フェーズ3の配布システムと同じになります（セクション4.3.4を参照）。ただし、ハンドオーバー時にRPベースのデータ配信がない場合、SIMデータ配信は、PIMフェーズ1のようにソース登録を介して再開できません。その結果、ハンドオーバー後に送信されたデータパケットは、定期的なツリーメンテナンスによって新しいMAGで（S、G）転送状態が再確立されるまで、MAGで破棄されます。
Source-specific shortest path trees are constructed in PIM-SM (phase two and three) and in PIM-SSM. These RPF-trees traverse LMA-MAG tunnels towards a source. As PIM remains unaware of source mobility management, these trees invalidate under handovers with each tunnel re-establishment at a new MAG. Regular tree maintenance of PIM will recover the states, but it remains unsynchronized and too slow to seamlessly preserve PIM data distribution services.
ソース固有の最短パスツリーは、PIM-SM（フェーズ2および3）およびPIM-SSMで構築されます。これらのRPFツリーは、ソースに向かってLMA-MAGトンネルを通過します。 PIMはソースモビリティ管理を認識しないままであるため、これらのツリーは、新しいMAGでトンネルが再確立されるたびに、ハンドオーバーを無効にします。 PIMの定期的なツリーメンテナンスは状態を回復しますが、同期が取れておらず、PIMデータ配信サービスをシームレスに維持するには遅すぎます。
A method to quickly recover PIM (S,G) trees under handover SHOULD synchronize multicast state maintenance with unicast handover operations and can proceed as follows. On handover, an LMA reads all (S,G) Join states from its corresponding tunnel interface and identifies those source addresses S_i that match moving HNPs. After re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join states with the new tunnel endpoint and immediately trigger a state maintenance (PIM Join) message. In proceeding this way, the source-specific PIM states are transferred to the new tunnel endpoint and propagated to the new MAG in synchrony with unicast handover procedures.
ハンドオーバーのもとでPIM（S、G）ツリーを迅速に回復する方法は、マルチキャストステートメンテナンスをユニキャストハンドオーバーオペレーションと同期する必要があり、次のように進めることができます。ハンドオーバー時に、LMAは対応するトンネルインターフェイスからすべての（S、G）結合状態を読み取り、移動するHNPと一致するソースアドレスS_iを識別します。新しいトンネルを再確立した後、（S_i、*）結合状態を新しいトンネルエンドポイントに関連付け、すぐに状態維持（PIM結合）メッセージをトリガーする必要があります（SHOULD）。この方法で、ソース固有のPIM状態が新しいトンネルエンドポイントに転送され、ユニキャストハンドオーバー手順と同期して新しいMAGに伝播されます。
BIDIR-PIM MAY be deployed in the access network for providing multicast services in parallel to unicast routes. Throughout this section, it is assumed that the PMIPv6 mobility domain is part of a single BIDIR-PIM multicast routing domain with BIDIR-PIM routing functions present at all MAGs and all LMAs. The PIM routing instance at a MAG SHALL then serve as the Designated Forwarder (DF) for all directly attached Mobile Nodes. For expediting handover operations, it is advisable to position BIDIR-PIM Rendezvous Point Addresses (RPAs) in the core of the PMIPv6 network domain. As regular IP routing tables need not be present in a PMIPv6 deployment, reverse path forwarding rules as required by BIDIR-PIM need to be established.
ユニキャストルートと並行してマルチキャストサービスを提供するために、BIDIR-PIMをアクセスネットワークに配置できます。このセクション全体で、PMIPv6モビリティドメインは、すべてのMAGおよびすべてのLMAにBIDIR-PIMルーティング機能が存在する単一のBIDIR-PIMマルチキャストルーティングドメインの一部であると想定しています。 MAGのPIMルーティングインスタンスは、直接接続されたすべてのモバイルノードの指定フォワーダー（DF）として機能します。ハンドオーバー操作を促進するために、BIIPv-PIMランデブーポイントアドレス（RPA）をPMIPv6ネットワークドメインのコアに配置することをお勧めします。通常のIPルーティングテーブルはPMIPv6展開に存在する必要がないため、BIDIR-PIMで必要なリバースパス転送ルールを確立する必要があります。
In this scenario, BIDIR-PIM will rely on a Multicast Routing Information Base (MRIB) that is generated independently of the policy-based routing rules of PMIPv6. The following information is needed.
このシナリオでは、BIDIR-PIMは、PMIPv6のポリシーベースのルーティングルールとは無関係に生成されるマルチキャストルーティング情報ベース（MRIB）に依存します。以下の情報が必要です。
o All routes to networks and nodes (including RPAs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among BIDIR-PIM routers and remain unaffected by node mobility. The setup of these general routes is expected to follow the topology of the operator network and is beyond the scope of this document.
o PMIPv6ドメインのモバイルメンバーではないネットワークおよびノード（RPAを含む）へのすべてのルートは、BIDIR-PIMルーター間で一貫して定義され、ノードモビリティの影響を受けないようにする必要があります。これらの一般的なルートの設定は、オペレーターネットワークのトポロジーに従うことが予想され、このドキュメントの範囲を超えています。
BIDIR-PIM will establish spanning trees across its network domain in conformance to its pre-configured RPAs and the routing information provided. Multicast data transmitted by a mobile source will immediately be forwarded by its DF (MAG) onto the spanning tree for the multicast group without further protocol operations.
BIDIR-PIMは、事前構成されたRPAおよび提供されたルーティング情報に準拠して、ネットワークドメイン全体にスパニングツリーを確立します。モバイルソースによって送信されたマルチキャストデータは、そのDF（MAG）によって、それ以上のプロトコル操作を行うことなく、マルチキャストグループのスパニングツリーにすぐに転送されます。
On handover, the mobile source reattaches to a new MAG (DF), which completes unicast network configurations. Thereafter, the source can immediately proceed with multicast packet transmission onto the pre-established distribution tree. BIDIR-PIM does not require protocol signaling or additional reconfiguration delays to adapt to source mobility, and it can be considered the protocol of choice for mobile multicast operations in the access network. As multicast streams always flow up to the Rendezvous Point Link, some care should be taken to configure RPAs compliant with network capacities.
ハンドオーバー時に、モバイルソースは新しいMAG（DF）に再接続し、ユニキャストネットワーク構成が完了します。その後、ソースは、事前に確立された配信ツリーへのマルチキャストパケット送信をすぐに続行できます。 BIDIR-PIMは、ソースモビリティに適応するためにプロトコルシグナリングや追加の再構成遅延を必要とせず、アクセスネットワークでのモバイルマルチキャスト操作に最適なプロトコルと見なすことができます。マルチキャストストリームは常にランデブーポイントリンクまで流れるため、ネットワーク容量に準拠したRPAを構成するように注意する必要があります。
A deployment of MLD proxies (see [RFC4605]) at MAGs has proven a useful and appropriate approach to multicast in PMIPv6; see [RFC6224] and [RFC7028]. However, deploying unmodified standard proxies can go along with significant performance degradation for mobile senders as discussed in this document. To overcome these deficits, an optimized approach to multicast source mobility based on extended peering functions among proxies is defined in this section. Based on such direct data exchange between proxy instances at MAGs, triangular routing is avoided and multicast streams can be disseminated directly within a PMIPv6 access network, and in particular within MAG routing machines. Prior to presenting the solution, we will summarize the relevant requirements.
MAGでのMLDプロキシの展開（[RFC4605]を参照）は、PMIPv6でマルチキャストするための有用で適切なアプローチであることが証明されています。 [RFC6224]と[RFC7028]を参照してください。ただし、このドキュメントで説明するように、未変更の標準プロキシを展開すると、モバイル送信者のパフォーマンスが大幅に低下する可能性があります。これらの欠点を克服するために、プロキシ間の拡張ピアリング機能に基づくマルチキャストソースモビリティへの最適化されたアプローチがこのセクションで定義されています。 MAGでのプロキシインスタンス間のこのような直接データ交換に基づいて、三角ルーティングが回避され、マルチキャストストリームをPMIPv6アクセスネットワーク内、特にMAGルーティングマシン内で直接配布できます。ソリューションを提示する前に、関連する要件を要約します。
Solutions that extend MLD proxies by additional uplinking functions need to comply to the following requirements.
追加のアップリンク機能によってMLDプロキシを拡張するソリューションは、次の要件に準拠する必要があります。
Prevention of routing loops In the absence of a full-featured routing logic at an MLD proxy, simple and locally decidable rules need to prevent source traffic from traversing the network in loops that would be potentially enabled by multiple uplinks.
ルーティングループの防止MLDプロキシにフル機能のルーティングロジックがない場合、シンプルでローカルに決定可能なルールは、複数のアップリンクによって潜在的に有効になるループでソーストラフィックがネットワークを通過しないようにする必要があります。
Unique coverage of receivers Listener functions at proxies require simple, locally decidable rules to initiate a unique delivery of multicast packets to all receivers.
レシーバーの一意のカバレッジプロキシのリスナー機能では、すべてのレシーバーへのマルチキャストパケットの一意の配信を開始するために、ローカルで決定可能な単純なルールが必要です。
Following local filtering techniques, these requirements are met in the following solution.
ローカルフィルタリング手法に従って、これらの要件は次のソリューションで満たされます。
A peering interface for MLD proxies allows for a direct data exchange of locally attached multicast sources. Such peering interfaces can be configured -- as a direct link or a bidirectional tunnel -- between any two proxy instances (locally deployed as in [RFC6224] or remotely deployed). Peerings remain as silent virtual links in regular proxy operations. Data is exchanged on such links only in cases where one peering proxy on its downstream directly connects to a source of multicast traffic to which the other peering proxy actively subscribes. In such cases, the proxy connected to the source will receive a listener report on its peering interface and will forward traffic from its local source accordingly. It is worth noting that multicast traffic distribution on peering links does not follow reverse unicast paths to sources. In the following, operations are defined for Any-Source Multicast (ASM) and SSM, but they provide superior performance in the presence of source-specific signaling (IGMPv3/MLDv2) [RFC4604].
MLDプロキシのピアリングインターフェイスにより、ローカルに接続されたマルチキャストソースの直接データ交換が可能になります。このようなピアリングインターフェイスは、直接リンクまたは双方向トンネルとして、任意の2つのプロキシインスタンス間で構成できます（[RFC6224]のようにローカルに展開されるか、リモートで展開されます）。通常のプロキシ操作では、ピアリングはサイレント仮想リンクのままです。ダウンストリームの1つのピアリングプロキシが、他のピアリングプロキシがアクティブにサブスクライブしているマルチキャストトラフィックのソースに直接接続している場合にのみ、このようなリンクでデータが交換されます。このような場合、ソースに接続されたプロキシは、ピアリングインターフェイスでリスナーレポートを受信し、それに応じてローカルソースからトラフィックを転送します。ピアリングリンク上のマルチキャストトラフィック配信は、ソースへの逆ユニキャストパスに従わないことに注意してください。以下では、操作はAny-Source Multicast（ASM）とSSMに対して定義されていますが、ソース固有のシグナリング（IGMPv3 / MLDv2）[RFC4604]の存在下で優れたパフォーマンスを提供します。
An MLD proxy with the perspective of a sender will see peering interfaces as restricted downstream interfaces. It will install and maintain source filters at its peering links that will restrict data transmission to those packets that originate from a source that is locally attached at one of its downstream interfaces.
送信者の観点からのMLDプロキシは、ピアリングインターフェイスを制限されたダウンストリームインターフェイスとして認識します。ピアリングリンクにソースフィルターをインストールして維持し、ダウンストリームインターフェイスの1つでローカルに接続されているソースから発信されるパケットへのデータ送信を制限します。
In detail, a proxy will extract from its configuration the network prefixes attached to its downstream interfaces and MUST implement a source filter base at its peering interfaces that restricts data transmission to IP source addresses from its local prefixes. This filter base MUST be updated if and only if the downstream configuration changes (e.g., due to mobility). Multicast packets that arrive from the upstream interface of the proxy are thus prevented from traversing any peering link, but they are only forwarded to regular downstream interfaces with appropriate subscription states. In this way, multihop forwarding on peering links is prevented.
詳細には、プロキシはそのダウンストリームインターフェイスに接続されたネットワークプレフィックスを構成から抽出し、ローカルプレフィックスからのIP送信元アドレスへのデータ送信を制限するピアリングインターフェイスにソースフィルターベースを実装する必要があります。このフィルターベースは、ダウンストリーム構成が変更された場合（モビリティなどにより）のみ更新する必要があります。したがって、プロキシのアップストリームインターフェイスから到着するマルチキャストパケットは、ピアリングリンクを通過できませんが、適切なサブスクリプション状態の通常のダウンストリームインターフェイスにのみ転送されます。このようにして、ピアリングリンクでのマルチホップ転送が防止されます。
Multicast traffic arriving from a locally attached source will be forwarded to the regular upstream interface and all downstream interfaces with appropriate subscription states (i.e., regular proxy operations). In addition, multicast packets of local origin are transferred to those peering interfaces with appropriate subscription states.
ローカルに接続されたソースから到着するマルチキャストトラフィックは、通常のアップストリームインターフェイスと、適切なサブスクリプション状態（つまり、通常のプロキシ操作）を持つすべてのダウンストリームインターフェイスに転送されます。さらに、ローカル発信元のマルチキャストパケットは、適切なサブスクリプション状態を持つピアリングインターフェイスに転送されます。
On the listener side, peering interfaces appear as preferred upstream links. The multicast proxy will attempt to receive multicast services on peering links for as many groups (channels) as possible. The general upstream interface configured according to [RFC4605] will be used only for retrieving those groups (channels) that remain unavailable from peerings. From this extension of [RFC4605], an MLD proxy with peering interconnects will exhibit several interfaces for pulling remote traffic: the regular upstream and the peerings. Traffic available from any of the peering links will be mutually disjoint but normally also available from the upstream. To prevent duplicate traffic from arriving at the listener side, the proxy
リスナー側では、ピアリングインターフェイスが優先アップストリームリンクとして表示されます。マルチキャストプロキシは、できるだけ多くのグループ（チャネル）のピアリングリンクでマルチキャストサービスを受信しようとします。 [RFC4605]に従って構成された一般的なアップストリームインターフェースは、ピアリングから利用できないままであるグループ（チャネル）を取得するためにのみ使用されます。 [RFC4605]のこの拡張から、ピアリング相互接続を備えたMLDプロキシは、リモートトラフィックをプルするためのいくつかのインターフェース（通常のアップストリームとピアリング）を示します。ピアリングリンクのいずれかから利用できるトラフィックは相互に分離されますが、通常はアップストリームからも利用できます。重複したトラフィックがリスナー側に到着するのを防ぐために、プロキシ
o MAY delay aggregated reports to the upstream, and
o 集約されたレポートをアップストリームに遅延させることができます。
o MUST apply appropriate filters to exclude duplicate streams.
o 重複するストリームを除外するために適切なフィルターを適用する必要があります。
In detail, an MLD proxy instance at a MAG first issues listener reports (in parallel) to all of its peering links. These links span at most one (virtual) hop. Whenever certain group traffic (SSM channels) does not arrive from the peerings after a waiting time (default: 10 ms (node-local) and 25 ms (remote)), additional reports (complementary reports, in the case of SSM) are sent to the standard upstream interface.
詳細には、MAGのMLDプロキシインスタンスは、最初にすべてのピアリングリンクにリスナーレポートを（並行して）発行します。これらのリンクは、最大で1つの（仮想）ホップにまたがります。待機時間（デフォルト：10ミリ秒（ノードローカル）および25ミリ秒（リモート））の後、特定のグループトラフィック（SSMチャネル）がピアリングから到着しない場合は常に、追加のレポート（SSMの場合は補足レポート）が送信されます標準アップストリームインターフェイスに。
Whenever traffic from a peering link arrives, an MLD proxy MUST install source filters at its upstream interfaces (as described in RFC 4605) in the following way.
ピアリングリンクからのトラフィックが到着するたびに、MLDプロキシは（RFC 4605で説明されているように）アップストリームインターフェイスにソースフィルターを次の方法でインストールする必要があります。
ASM with IGMPv2/MLDv1: In the presence of ASM using IGMPv2/MLDv1, only, the proxy cannot signal source filtering to its upstream. Correspondingly, it applies (S,*) ingress filters at its upstream interface for all sources S seen in traffic on the peering links. It is noteworthy that unwanted traffic is still replicated to the proxy via the (wired) provider backbone, but it is not forwarded into the wireless access network.
IGMPv2 / MLDv1を使用するASM：IGMPv2 / MLDv1を使用するASMが存在する場合のみ、プロキシはソースフィルタリングをアップストリームに通知できません。これに対応して、ピアリングリンク上のトラフィックにあるすべてのソースSに対して、そのアップストリームインターフェイスで（S、*）入力フィルターを適用します。不要なトラフィックが（有線の）プロバイダーバックボーンを介してプロキシにレプリケートされることは注目に値しますが、ワイヤレスアクセスネットワークには転送されません。
ASM with IGMPv3/MLDv2: In the presence of source-specific signaling (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude mode for all sources S seen in traffic of the peering links. The corresponding source-specific signaling will prevent forwarding of duplicate traffic throughout the access network.
ASMとIGMPv3 / MLDv2：ソース固有のシグナリング（IGMPv3 / MLDv2）が存在する場合、アップストリームインターフェイスは、ピアリングリンクのトラフィックで見られるすべてのソースSに対して（S、*）除外モードに設定されます。対応する送信元固有のシグナリングにより、アクセスネットワーク全体での重複トラフィックの転送が防止されます。
SSM: In the presence of Source-Specific Multicast, the proxy will subscribe on its uplink interface to those (S,G) channels, only, that do not arrive via the peering links.
SSM：ソース固有のマルチキャストが存在する場合、プロキシはアップリンクインターフェイスで、ピアリングリンク経由で到着しない（S、G）チャネルのみにサブスクライブします。
MLD proxies will install data-driven timers (source-timeout) for each source but common to all peering interfaces to detect interruptions of data services from individual sources at proxy peers. Termination of source-specific flows may be application specific, but also may be due to a source handover or a transmission failure. After a handover, a mobile source may reattach at another MLD proxy with a peering relation to the listener, or at a proxy that does not peer. While in the first case, traffic reappears on another peering link; in the second case, data can only be retrieved via the regular upstream. To account for the latter, the MLD proxy revokes the source-specific filter(s) at its upstream interface, after the source-timeout expires (default: 50 ms). Corresponding traffic will then be pulled from the regular upstream interface. Source-specific filters MUST be reinstalled whenever traffic of this source arrives at any peering interface.
MLDプロキシは、ソースごとにデータ駆動型タイマー（source-timeout）をインストールしますが、すべてのピアリングインターフェイスに共通であり、プロキシピアの個々のソースからのデータサービスの中断を検出します。ソース固有のフローの終了は、アプリケーション固有である場合がありますが、ソースのハンドオーバーまたは送信の失敗が原因である場合もあります。ハンドオーバー後、モバイルソースは、リスナーとのピアリング関係を持つ別のMLDプロキシ、またはピアリングしないプロキシに再接続できます。最初のケースでは、トラフィックは別のピアリングリンクに再表示されます。 2番目のケースでは、データは通常のアップストリームを介してのみ取得できます。後者を説明するために、MLDプロキシは、source-timeoutの期限が切れた後（デフォルト：50ミリ秒）に、アップストリームインターフェイスでソース固有のフィルターを取り消します。対応するトラフィックは、通常のアップストリームインターフェイスからプルされます。このソースのトラフィックがピアリングインターフェイスに到達するたびに、ソース固有のフィルターを再インストールする必要があります。
There is a noteworthy trade-off between traffic minimization and available traffic at the upstream that is locally filtered at the proxy. Implementors can use this relation to optimize for service-specific requirements.
トラフィックの最小化と、プロキシでローカルにフィルタリングされるアップストリームでの利用可能なトラフィックの間には、注目すべきトレードオフがあります。実装者はこの関係を使用して、サービス固有の要件を最適化できます。
In proceeding this way, multicast group data will arrive from peering interfaces first, while only peer-wise unavailable traffic is retrieved from the regular upstream interface.
この方法では、マルチキャストグループデータが最初にピアリングインターフェイスから到着しますが、通常のアップストリームインターフェイスからはピア単位で使用できないトラフィックのみが取得されます。
This document defines multicast sender mobility based on PMIPv6 and common multicast routing protocols. Consequently, threats identified as security concerns in [RFC2236], [RFC2710], [RFC3810], [RFC4605], [RFC5213], and [RFC5844] are inherited by this document.
このドキュメントでは、PMIPv6と一般的なマルチキャストルーティングプロトコルに基づくマルチキャスト送信側モビリティを定義します。したがって、[RFC2236]、[RFC2710]、[RFC3810]、[RFC4605]、[RFC5213]、および[RFC5844]でセキュリティ上の懸念として識別された脅威は、このドキュメントによって継承されます。
In addition, 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 arise from rapid state changes, as well as from high-volume data streams routed into access networks of limited capacities. In cases of PIM-SM deployment, handover operations of the MNs include re-registering sources at the Rendezvous Points at possibly high frequency. In addition to proper authorization checks of MNs, rate controls at routing agents and replicators may be needed to protect the agents and the downstream networks. In particular, MLD proxy implementations at MAGs SHOULD automatically erase multicast state on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will in general not actively terminate group membership prior to departure.
さらに、ネットワークエンティティでのマルチキャスト管理とモビリティ管理の組み合わせの影響に特に注意する必要があります。この仕様により、モバイルノードはアタッチメントを変更しながらMAGおよびLMAでマルチキャスト転送状態の作成を開始できるため、PMIPルーターおよびアクセスネットワークでのリソース枯渇の脅威は、急速な状態変化や、アクセスにルーティングされる大量のデータストリームから発生します。容量が限られているネットワーク。 PIM-SM展開の場合、MNのハンドオーバー操作には、ランデブーポイントでのソースの再登録が含まれる可能性があり、頻度が高くなります。 MNの適切な承認チェックに加えて、エージェントとダウンストリームネットワークを保護するために、ルーティングエージェントとレプリケータでのレート制御が必要になる場合があります。特に、PMIPv6ドメイン内のモバイルマルチキャストリスナーは一般に、グループメンバーシップを出発前にアクティブに終了しないため、MAGでのMLDプロキシ実装は、MNの出発時にマルチキャスト状態を自動的に消去する必要があります（SHOULD）。
The deployment of IGMP/MLD proxies for multicast routing requires particular care, as routing loops on the upstream are not automatically detected. Peering functions between proxies extend this threat in the following way. Routing loops among peering and upstream interfaces are prevented by filters on local sources. Such filtering can fail whenever prefix configurations for downstream interfaces at a proxy are incorrect or inconsistent. Consequently, implementations of peering-enabled proxies SHOULD take particular care on keeping IP configurations consistent at the downstream in a reliable and timely manner. (See [RFC6224] for requirements on PMIPv6-compliant implementations of MLD proxies.)
アップストリームのルーティングループが自動的に検出されないため、マルチキャストルーティング用のIGMP / MLDプロキシの展開には特別な注意が必要です。プロキシ間のピアリング機能は、次のようにこの脅威を拡大します。ピアリングインターフェイスとアップストリームインターフェイス間のルーティングループは、ローカルソースのフィルターによって防止されます。このようなフィルタリングは、プロキシのダウンストリームインターフェイスのプレフィックス設定が正しくないか、矛盾している場合は常に失敗する可能性があります。その結果、ピアリング対応のプロキシの実装は、ダウンストリームでIP構成の一貫性を確実かつタイムリーに維持することに特に注意を払う必要があります（SHOULD）。 （MLDプロキシのPMIPv6準拠の実装に関する要件については、[RFC6224]を参照してください。）
The authors would like to thank (in alphabetical order) David Black, Luis M. Contreras, Spencer Dawkins, Muhamma Omer Farooq, Bohao Feng, Sri Gundavelli, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li, Cong Liu, Radia Perlman, Akbar Rahman, Behcet Sarikaya, Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, and Zhi-Wei Yan for advice, help, and reviews of the document. Funding by the German Federal Ministry of Education and Research within the G-LAB Initiative (projects HAMcast, Mindstone, and SAFEST) is gratefully acknowledged.
著者は（アルファベット順で）デビッドブラック、ルイスM.コントレラス、スペンサードーキンス、ムハンマオメールファルーク、ボハオフェン、スリガンダヴェッリ、ダークフォンヒューゴ、ニンコング、ジョーニコロネン、ヘーウーリー、コンリュー、ドキュメントのアドバイス、ヘルプ、レビューについては、Radia Perlman、Akbar Rahman、Behcet Sarikaya、Stig Venaas、Li-Li Wang、Sebastian Woelke、Qian Wu、およびZhi-Wei Yanにご相談ください。 G-LABイニシアチブ（プロジェクトHAMcast、マインドストーン、SAFEST）内のドイツ連邦教育研究省からの資金提供は、ありがたく認められています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[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、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"） "、RFC 4605、2006年8月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[MULTI-EXT] Schmidt, T., Ed., Waehlisch, M., Koodli, R., Fairhurst, G., and D. Liu, "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Work in Progress, May 2014.
[MULTI-EXT] Schmidt、T.、Ed。、Wahehlisch、M.、Koodli、R.、Fairhurst、G。、およびD. Liu、「MIPv6およびPMIPv6高速ハンドオーバー用のマルチキャストリスナー拡張」、Work in Progress、 2014。
[PEERING-ANALYSIS] Schmidt, TC., Woelke, S., and M. Waehlisch, "Peer my Proxy - A Performance Study of Peering Extensions for Multicast in Proxy Mobile IP Domains", Proc. of 7th IFIP Wireless and Mobile Networking Conference (WMNC 2014), IEEE Press, May 2014.
[PEERING-ANALYSIS]シュミット、TC、Woelke、S。、およびM. Waehlisch、「Peer my Proxy-A Performance Study of Peering Extensions for Multicast in Proxy Mobile IP Domains」、Proc。第7回IFIPワイヤレスおよびモバイルネットワーキング会議（WMNC 2014）、IEEE Press、2014年5月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPv3）およびソース固有のマルチキャスト用のマルチキャストリスナー検出プロトコルバージョン2（MLDv2）の使用」、RFC 4604、8月2006年
[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、「Mobile IP Version 6（MIPv6）：Multicast Mobility in Mobile IP Version 6（MIPv6）：Problem Statement and Brief Survey」、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、「Generic Routing Encapsulation（GRE）Key Option for Proxy Mobile IPv6」、RFC 5845、2010年6月。
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6224] Schmidt、T.、Wahehlisch、M。、およびS. Krishnan、「プロキシモバイルIPv6（PMIPv6）ドメインでのマルチキャストリスナーサポートの基本展開」、RFC 6224、2011年4月。
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013.
[RFC7028] Zuniga、JC。、Contreras、LM。、Bernardos、CJ。、Jeon、S。、およびY. Kim、「プロキシモバイルIPv6のマルチキャストモビリティルーティングの最適化」、RFC 7028、2013年9月。
[RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)", RFC 7161, March 2014.
[RFC7161] Contreras、LM。、Bernardos、CJ。、およびI. Soto、「LMA（SIAL）によるサブスクリプション情報取得によるプロキシモバイルIPv6（PMIPv6）マルチキャストハンドオーバの最適化」、RFC 7161、2014年3月。
In this section, we document upstream extensions for an MLD proxy that were originally developed during the work on this document. Multiple proxy instances deployed at a single MAG (see Section 3) can be avoided by adding multiple upstream interfaces to a single MLD proxy. In a typical PMIPv6 deployment, each upstream interface of a single proxy instance can interconnect to one of the LMAs. With such ambiguous upstream options, appropriate forwarding rules MUST be supplied to
このセクションでは、このドキュメントの作業中に最初に開発されたMLDプロキシのアップストリーム拡張について説明します。単一のMAG（セクション3を参照）に配置された複数のプロキシインスタンスは、単一のMLDプロキシに複数のアップストリームインターフェイスを追加することで回避できます。典型的なPMIPv6展開では、単一のプロキシインスタンスの各アップストリームインターフェイスをLMAの1つに相互接続できます。このようなあいまいなアップストリームオプションでは、適切な転送ルールを
o unambiguously guide traffic forwarding from directly attached mobile sources, and
o 直接接続されたモバイルソースからのトラフィック転送を明確にガイドします。
o lead listener reports to initiating unique traffic subscriptions.
o リスナーレポートをリードして、一意のトラフィックサブスクリプションを開始します。
This can be achieved by a complete set of source- and group-specific filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. These filters MAY be derived in part from PMIPv6 routing policies and can include a default behavior (e.g., (*,*)).
これは、プロキシインターフェイスにインストールされたソースおよびグループ固有の完全なフィルタールールセット（（S、*）、（*、G）など）によって実現できます。これらのフィルターは、部分的にPMIPv6ルーティングポリシーから派生する場合があり、デフォルトの動作を含めることができます（例：（*、*））。
Packets from a locally attached multicast source will be forwarded to all downstream interfaces with appropriate subscriptions, as well as up the interface with the matching source-specific filter.
ローカルに接続されたマルチキャストソースからのパケットは、適切なサブスクリプションを持つすべてのダウンストリームインターフェイスに転送されるとともに、ソース固有のフィルターに一致するインターフェイスに転送されます。
Typically, the upstream interface for a mobile multicast source is chosen based on the policy routing (e.g., the MAG-LMA tunnel interface for LMA-based routing or the interface towards the multicast router for direct routing), but alternate configurations MAY be applied. Packets from a locally attached multicast source will be forwarded to the corresponding upstream interface with the matching source-specific filter, as well as all the downstream interfaces with appropriate subscriptions.
通常、モバイルマルチキャストソースのアップストリームインターフェイスは、ポリシールーティング（LMAベースのルーティング用のMAG-LMAトンネルインターフェイス、または直接ルーティング用のマルチキャストルーターへのインターフェイスなど）に基づいて選択されますが、代替構成が適用される場合があります。ローカルに接続されたマルチキャストソースからのパケットは、ソース固有のフィルターに対応するアップストリームインターフェイスと、適切なサブスクリプションを持つすべてのダウンストリームインターフェイスに転送されます。
Multicast listener reports are group-wise aggregated by the MLD proxy. The aggregated report is issued to the upstream interface with a matching group/channel-specific filter. The choice of the corresponding upstream interface for aggregated group membership reports MAY be additionally based on some administrative scoping rules for scoped multicast group addresses.
マルチキャストリスナーレポートは、MLDプロキシによってグループごとに集約されます。集約されたレポートは、一致するグループ/チャネル固有のフィルターを使用して、アップストリームインターフェイスに発行されます。集約されたグループメンバーシップレポートに対応するアップストリームインターフェイスの選択は、スコープマルチキャストグループアドレスの管理スコープルールにさらに基づいている場合があります。
In detail, a Multiple Upstream Interface proxy will provide and maintain a Multicast Subscription Filter Table that maps source- and group-specific filters to upstream interfaces. The forwarding decision for an aggregated MLD listener report is based on the first matching entry from this table, with the understanding that for IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the presence of (*,G) after (S,G) interface entries), and that (S,*)-filters are always false in the absence of source-specific signaling, i.e., in IGMPv2/MLDv1 only domains.
詳細には、マルチアップストリームインターフェイスプロキシは、ソースおよびグループ固有のフィルターをアップストリームインターフェイスにマップするマルチキャストサブスクリプションフィルターテーブルを提供および維持します。集約されたMLDリスナーレポートの転送の決定は、このテーブルの最初に一致するエントリに基づいています。IGMPv3/ MLDv2の場合、MLDプロキシは必要に応じて状態分解を実行する（つまり、（*、G）サブスクリプションが分割される） （S、G）および（* \ S、G）が存在する場合（（S、G）インターフェースエントリの後に（*、G）が存在する場合）、およびその（S、*）フィルターはソースがない場合は常にfalseです固有のシグナリング、つまりIGMPv2 / MLDv1のみのドメイン。
In typical deployment scenarios, specific group services (channels) are either
一般的な展開シナリオでは、特定のグループサービス（チャネル）は次のいずれかです。
o associated with selected uplinks to remote LMAs, while a (*,*) default subscription entry (in the last table line) is bound to a local routing interface, or
o リモートLMAへの選択されたアップリンクに関連付けられているが、（*、*）デフォルトのサブスクリプションエントリ（最後のテーブル行）がローカルルーティングインターフェイスにバインドされている、または
o configured as local services first, while a (*,*) default entry (in the last table line) points to a remote uplink that provides the general multicast support.
o 最初にローカルサービスとして構成され、（*、*）デフォルトエントリ（最後のテーブル行）は、一般的なマルチキャストサポートを提供するリモートアップリンクを指します。
An implementation of the extended IGMP/MLD proxy has been provided within the MCPROXY project (http://mcproxy.realmv6.org/). This open-source software is written in C++ and uses forwarding capabilities of the Linux kernel. It supports all regular operations according to [RFC4605] and allows for multiple proxy instances on one node, dynamically changing downstream links, proxy-to-proxy peerings, and multiple upstream links with individual configurations. The software can be downloaded from GitHub at <https://github.com/mcproxy/mcproxy>. Based on this software, an experimental performance evaluation of the proxy peering function has been reported in [PEERING-ANALYSIS].
MCPROXYプロジェクト（http://mcproxy.realmv6.org/）内で、拡張IGMP / MLDプロキシの実装が提供されています。このオープンソースソフトウェアはC ++で記述され、Linuxカーネルの転送機能を使用します。 [RFC4605]に従ってすべての通常の操作をサポートし、1つのノード上で複数のプロキシインスタンスを可能にし、動的に変更するダウンストリームリンク、プロキシからプロキシへのピアリング、および個別の構成を持つ複数のアップストリームリンク。ソフトウェアは、GitHubの<https://github.com/mcproxy/mcproxy>からダウンロードできます。このソフトウェアに基づいて、プロキシピアリング機能の実験的なパフォーマンス評価が[PEERING-ANALYSIS]で報告されています。
Authors' Addresses
著者のアドレス
Thomas C. Schmidt (editor) 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
Shuai Gao Beijing Jiaotong University Beijing China
Shu AIG AO北京J i AO Tong大学北京中国
EMail: shgao@bjtu.edu.cn
Hong-Ke Zhang Beijing Jiaotong University Beijing China
hong-KE Zhang北京J iオーストリア大学北京大学
EMail: hkzhang@bjtu.edu.cn
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany
Matthias Waehlischリンクラボ＆FUベルリンHoenower Str。 35ベルリン10318ドイツ
EMail: mw@link-lab.net