[要約] RFC 7028は、Proxy Mobile IPv6におけるマルチキャストモビリティルーティングの最適化に関するものであり、マルチキャストトラフィックの効率的な配信を目的としています。
Internet Engineering Task Force (IETF) JC. Zuniga
Request for Comments: 7028 InterDigital Communications, LLC
Category: Experimental LM. Contreras
ISSN: 2070-1721 Telefonica I+D
CJ. Bernardos
UC3M
S. Jeon
Instituto de Telecomunicacoes
Y. Kim
Soongsil University
September 2013
Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
プロキシモバイルIPv6のマルチキャストモビリティルーティングの最適化
Abstract
概要
This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.
このドキュメントは、プロキシモバイルIPv6（PMIPv6）ドメインでIPマルチキャストをサポートするために、基本ソリューションにいくつかの実験的な拡張を提案します。これらの拡張には、マルチキャストトラフィックのトポロジアンカーポイントとしてのマルチキャストツリーモビリティアンカーの使用、モバイルアクセスゲートウェイがローカルネットワークのマルチキャストコンテンツへのアクセスを提供できる直接ルーティングオプションが含まれます。これらの機能強化の目的は、マルチキャストトラフィックのレプリケーションの削減、さまざまなPMIPv6展開シナリオのサポートなどの利点を提供することです。
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/rfc7028.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7028で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. MTMA/Direct Routing Mode Selection .........................5
3.2. Multicast Tree Mobility Anchor (Subscription via MTMA) .....5
3.3. Direct Routing (Subscription via Direct Routing) ...........7
4. Mobile Access Gateway Operation .................................9
4.1. Extensions to Binding Update List Data Structure ...........9
4.2. MAG as MLD Proxy ...........................................9
4.2.1. MTMA Mode (Subscription via MTMA) ...................9
4.2.2. Direct Routing Mode (Subscription via
Direct Routing) ....................................11
5. Local Mobility Anchor Operation ................................14
5.1. Dynamic IP Multicast Selector Option ......................14
5.1.1. Option Application Rules ...........................14
5.1.2. Option Format ......................................14
6. Multicast Tree Mobility Anchor Operation .......................16
6.1. Conceptual Data Structures ................................17
7. Mobile Node Operation ..........................................17
8. IPv4 Support ...................................................17
9. IANA Considerations ............................................18
10. Security Considerations .......................................18
11. Contributors ..................................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
Appendix A. MTMA Deployment Use Cases .............................22
A.1. PMIPv6 Domain with Ratio 1:1 ...............................22
A.2. PMIPv6 Domain with Ratio N:1 ...............................22
A.3. PMIPv6 Domain with Ratio 1:N ...............................24
A.4. PMIPv6 Domain with H-LMA ...................................26
Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the network and performs the mobility management on behalf of the Mobile Node (MN). The Local Mobility Anchor (LMA) is the home agent for the MN and the topological anchor point. PMIPv6 was originally designed for unicast traffic. However, a PMIPv6 domain may handle data from both unicast and multicast sources.
プロキシモバイルIPv6 [RFC5213]は、IPモビリティの問題を解決するためのネットワークベースのアプローチです。プロキシモバイルIPv6（PMIPv6）ドメインでは、モバイルアクセスゲートウェイ（MAG）はネットワーク内のプロキシモビリティエージェントとして動作し、モバイルノード（MN）に代わってモビリティ管理を実行します。ローカルモビリティアンカー（LMA）は、MNおよびトポロジアンカーポイントのホームエージェントです。 PMIPv6はもともとユニキャストトラフィック用に設計されました。ただし、PMIPv6ドメインは、ユニキャストソースとマルチキャストソースの両方からのデータを処理できます。
The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by IPv4 hosts to report their IP multicast group memberships to neighboring multicast routers. Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] is used in a similar way by IPv6 routers to discover the presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy specification [RFC4605] allows an intermediate (i.e., edge) node to appear as a multicast router to downstream hosts and as a host to upstream multicast routers. IGMP- and MLD-related protocols however were not originally designed to address the IP mobility of multicast listeners (i.e., IGMP and MLD protocols were originally designed for fixed networks).
IPv4ホストは、インターネットグループ管理プロトコル（IGMPv3）[RFC3376]を使用して、IPマルチキャストグループメンバーシップを近隣のマルチキャストルーターに報告します。マルチキャストリスナー検出バージョン2（MLDv2）[RFC3810]は、IPv6ルーターがIPv6マルチキャストホストの存在を検出するために同様の方法で使用します。また、IGMP / MLDプロキシ仕様[RFC4605]では、中間（つまり、エッジ）ノードを、ダウンストリームホストからはマルチキャストルーターとして、アップストリームマルチキャストルーターからはホストとして表示できます。ただし、IGMPおよびMLD関連のプロトコルは、もともとマルチキャストリスナーのIPモビリティに対応するように設計されていませんでした（つまり、IGMPおよびMLDプロトコルは、もともと固定ネットワーク用に設計されていました）。
A base solution to support both IPv4 and IPv6 multicast listener mobility in a PMIPv6 domain is specified in [RFC6224], which describes deployment options without modifying mobility and multicast protocol standards. PMIPv6 allows a mobile access gateway to establish multiple PMIPv6 tunnels with different local mobility anchors, e.g., up to one per mobile node. In the presence of multicast traffic, multiple instances of the same traffic can converge to the same MAG. Hence, when IP multicasting is applied into PMIPv6, it may lead to redundant traffic at a MAG. This is the tunnel convergence problem.
PMIPv6ドメインでIPv4とIPv6の両方のマルチキャストリスナーモビリティをサポートする基本ソリューションは、[RFC6224]で指定されており、モビリティとマルチキャストプロトコル標準を変更せずに展開オプションを説明しています。 PMIPv6により、モバイルアクセスゲートウェイは、異なるローカルモビリティアンカーを使用して複数のPMIPv6トンネルを確立できます。たとえば、モバイルノードごとに1つまでです。マルチキャストトラフィックが存在する場合、同じトラフィックの複数のインスタンスが同じMAGに収束する可能性があります。したがって、IPマルチキャストをPMIPv6に適用すると、MAGで冗長トラフィックが発生する可能性があります。これはトンネル収束の問題です。
In order to address this issue, this document proposes an experimental solution, consisting of two complementary enhancements: multicast anchor and direct routing. The first enhancement makes use of a Multicast Tree Mobility Anchor (MTMA) as the topological anchor point for remotely delivering multicast traffic, while the second enhancement uses direct routing taking advantage of local multicast source availability, allowing a mobile access gateway to connect directly to a multicast router for simple access to local content. Neither of the two schemes has any impact on the mobile node to support IPv4 and IPv6 multicast listener mobility, nor on the wider Internet, as they only affect the PMIPv6 domains where they are deployed. Although references to "MLD proxy" are used in the document, it should be understood to also include "IGMP/MLD proxy" functionality (see Section 8 for details). The status of this
この問題に対処するために、このドキュメントでは、マルチキャストアンカーとダイレクトルーティングという2つの補完的な機能拡張で構成される実験的なソリューションを提案します。最初の拡張では、マルチキャストトラフィックをリモートで配信するためのトポロジアンカーポイントとしてMulticast Tree Mobility Anchor（MTMA）を使用しますが、2番目の拡張では、ローカルマルチキャストソースの可用性を利用して直接ルーティングを使用し、モバイルアクセスゲートウェイがローカルコンテンツに簡単にアクセスできるマルチキャストルーター。 2つのスキームは、モバイルノードがIPv4およびIPv6マルチキャストリスナーモビリティをサポートするために影響を与えることも、より広いインターネットに影響を与えることもありません。このドキュメントでは「MLDプロキシ」への参照が使用されていますが、「IGMP / MLDプロキシ」機能も含まれていることを理解する必要があります（詳細についてはセクション8を参照）。この状態
proposal is Experimental. The status of this proposal may be reconsidered in the future, once more implementation feedback and deployment experience is gathered, reporting on the performance of the two proposed schemes as well as operational feedback on scheme selection.
提案は実験的です。この提案のステータスは、将来再検討される可能性があります。実装のフィードバックと展開の経験がさらに集まり、2つの提案されたスキームのパフォーマンスとスキームの選択に関する運用上のフィードバックが報告されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the terminology defined in [RFC5213], [RFC6275], and [RFC3810]. Specifically, the definition of PMIPv6 domain is reused from [RFC5213] and reproduced here for completeness.
このドキュメントでは、[RFC5213]、[RFC6275]、および[RFC3810]で定義されている用語を使用しています。具体的には、PMIPv6ドメインの定義は[RFC5213]から再利用され、完全を期すためにここで再現されています。
Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in [RFC5213]. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending proxy binding updates on behalf of the mobile nodes can be ensured.
プロキシモバイルIPv6ドメイン（PMIPv6-ドメイン）：プロキシモバイルIPv6ドメインは、[RFC5213]で定義されているプロキシモバイルIPv6プロトコルを使用してモバイルノードのモビリティ管理が処理されるネットワークを指します。プロキシモバイルIPv6ドメインには、ローカルのモビリティアンカーとモバイルアクセスゲートウェイが含まれます。これらの間にセキュリティアソシエーションを設定でき、モバイルノードに代わってプロキシバインディング更新を送信するための認証を確保できます。
In this document we refine the definition from the point of view of the kind of traffic served to the MN in the following way:
このドキュメントでは、次の方法で、MNに提供されるトラフィックの種類の観点から定義を改良します。
PMIPv6 unicast domain: PMIPv6 unicast domain refers to the network covered by one LMA for unicast service. This service supports mobility as the MN moves from one MAG to another one, both associated with the same LMA regarding the MN unicast traffic.
PMIPv6ユニキャストドメイン：PMIPv6ユニキャストドメインは、ユニキャストサービス用に1つのLMAがカバーするネットワークを指します。このサービスは、MNが1つのMAGから別のMAGに移動するときにモビリティをサポートします。どちらもMNユニキャストトラフィックに関して同じLMAに関連付けられています。
PMIPv6 multicast domain: PMIPv6 multicast domain refers to the network covered by one network element named MTMA (defined below) for multicast service in such a way that an MN using that service is not aware of mobility as it moves from one MAG to another.
PMIPv6マルチキャストドメイン：PMIPv6マルチキャストドメインは、そのサービスを使用するMNが1つのMAGから別のMAGに移動するときにモビリティを認識しないように、マルチキャストサービスのMTMA（以下で定義）という名前の1つのネットワーク要素によってカバーされるネットワークを指します
From the definitions above, it can be stated that a PMIPv6 domain can have several PMIPv6 unicast domains and PMIPv6 multicast domains. Additionally, some other definitions are introduced, as follows.
上記の定義から、PMIPv6ドメインは複数のPMIPv6ユニキャストドメインとPMIPv6マルチキャストドメインを持つことができると言えます。さらに、次のように他のいくつかの定義が導入されています。
MTMA or multicast tree mobility anchor: An entity working as topological anchor point for multicast traffic. It manages the multicast groups subscribed by all (or a subset of) the MAGs in a PMIPv6 multicast domain, on behalf of the MNs attached to them. Hence, an MTMA performs the functions of either a designated multicast router or an MLD proxy.
MTMAまたはマルチキャストツリーモビリティアンカー：マルチキャストトラフィックのトポロジアンカーポイントとして機能するエンティティ。アタッチされているMNに代わって、PMIPv6マルチキャストドメイン内のすべて（または一部）のMAGがサブスクライブするマルチキャストグループを管理します。したがって、MTMAは、指定されたマルチキャストルーターまたはMLDプロキシのいずれかの機能を実行します。
H-LMA or Hybrid-LMA: An entity that is dedicated to both unicast and multicast services and able to work as both LMA and MTMA simultaneously.
H-LMAまたはハイブリッドLMA：ユニキャストサービスとマルチキャストサービスの両方に専用であり、LMAとMTMAの両方として同時に機能できるエンティティ。
Direct routing: This scheme uses the native multicast infrastructure for retrieving multicast data. For an operator having its own local content, this technique also includes the case where the content source is directly connected to the MAG.
直接ルーティング：このスキームは、ネイティブマルチキャストインフラストラクチャを使用して、マルチキャストデータを取得します。独自のローカルコンテンツを持つオペレータの場合、この手法には、コンテンツソースがMAGに直接接続されている場合も含まれます。
Subscription via MTMA: Multicast subscription mode in which the content is retrieved from the remote (or home) MTMA.
MTMA経由のサブスクリプション：コンテンツがリモート（またはホーム）MTMAから取得されるマルチキャストサブスクリプションモード。
Subscription via direct routing: Multicast subscription mode in which the content is retrieved using direct routing from the local domain.
直接ルーティングによるサブスクリプション：ローカルドメインから直接ルーティングを使用してコンテンツを取得するマルチキャストサブスクリプションモード。
This specification describes two complementary operational modes that can be used to deliver multicast traffic in a PMIPv6 domain: multicast tree mobility anchor and direct routing. There are different approaches that can be followed to perform this operational mode selection, depending on the operator's preferences and PMIPv6 deployment characteristics. For example, the mode can be manually configured at the mobile access gateway, according to the multicast tree deployment in the PMIPv6 domain, following operator's configuration of the multicast distribution on it. Another option is the use of dynamic policies, conveyed in the PBU (Proxy Binding Update) / PBA (Proxy Binding Acknowledgement) signaling using the Dynamic IP Multicast Selector option described in Section 5.1. Next, each of the two operational modes is introduced.
この仕様では、PMIPv6ドメインでマルチキャストトラフィックを配信するために使用できる2つの補完的な動作モード、マルチキャストツリーモビリティアンカーとダイレクトルーティングについて説明します。オペレーターの設定およびPMIPv6の展開特性に応じて、この操作モードの選択を実行するために従うことができるさまざまなアプローチがあります。たとえば、モードは、オペレーターのマルチキャスト配信の構成に従って、PMIPv6ドメインでのマルチキャストツリーの展開に従って、モバイルアクセスゲートウェイで手動で構成できます。別のオプションは、セクション5.1で説明した動的IPマルチキャストセレクターオプションを使用したPBU（プロキシバインディング更新）/ PBA（プロキシバインディング確認）シグナリングで伝達される動的ポリシーの使用です。次に、2つの動作モードのそれぞれを紹介します。
A multicast tree mobility anchor is used to serve as the mobility anchor for multicast traffic. The MTMA is either a designated multicast router or an MLD proxy. Typically, the MTMA will be used to get access to remote multicast content.
マルチキャストツリーモビリティアンカーは、マルチキャストトラフィックのモビリティアンカーとして機能するために使用されます。 MTMAは、指定マルチキャストルータまたはMLDプロキシのいずれかです。通常、MTMAは、リモートマルチキャストコンテンツにアクセスするために使用されます。
The multicast tree mobility anchor connects to the mobile access gateway, as described in [RFC6224], and it can reuse native PMIPv6 features such as tunnel establishment and security [RFC5213], heartbeat [RFC5847], etc. Unicast traffic will go normally to the local mobility anchors in the PMIPv6 domain as described in [RFC5213]. A MAG connecting to the MTMA acts as an MLD proxy.
マルチキャストツリーモビリティアンカーは、[RFC6224]で説明されているようにモバイルアクセスゲートウェイに接続し、トンネルの確立やセキュリティ[RFC5213]、ハートビート[RFC5847]などのネイティブPMIPv6機能を再利用できます。ユニキャストトラフィックは通常、 [RFC5213]で説明されているPMIPv6ドメインのローカルモビリティアンカー。 MTMAに接続するMAGは、MLDプロキシとして機能します。
This section describes how the MTMA works in scenarios of MN attachment and multicast mobility. It concentrates on the case of both LMA and MTMA defining a unique PMIPv6 domain. Some other deployment scenarios are presented in Appendix A.
このセクションでは、MN接続とマルチキャストモビリティのシナリオでMTMAがどのように機能するかについて説明します。 LMAとMTMAの両方が一意のPMIPv6ドメインを定義している場合に焦点を当てています。その他のいくつかの展開シナリオは、付録Aに示されています。
Figure 1 shows an example of a PMIPv6 domain supporting multicast mobility. The local mobility anchor is dedicated to unicast traffic, and the multicast tree mobility anchor is dedicated to multicast traffic. The MTMA can be considered to be a form of upstream multicast router with tunnel interfaces allowing subscription via MTMA for the MNs.
図1は、マルチキャストモビリティをサポートするPMIPv6ドメインの例を示しています。ローカルモビリティアンカーはユニキャストトラフィック専用で、マルチキャストツリーモビリティアンカーはマルチキャストトラフィック専用です。 MTMAは、MNのMTMAを介したサブスクリプションを可能にするトンネルインターフェイスを備えたアップストリームマルチキャストルータの一種と考えることができます。
As shown in Figure 1, MAG1 may connect to both unicast (LMA) and multicast (MTMA) entities. Thus, a given MN may simultaneously receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 receive unicast traffic, multicast traffic, or both, whereas MN3 receives multicast traffic only.
図1に示すように、MAG1はユニキャスト（LMA）エンティティとマルチキャスト（MTMA）エンティティの両方に接続できます。したがって、所与のＭＮは、ユニキャストおよびマルチキャストの両方のトラフィックを同時に受信することができる。図1では、MN1とMN2はユニキャストトラフィック、マルチキャストトラフィック、またはその両方を受信しますが、MN3はマルチキャストトラフィックのみを受信します。
+--------------+
|Content Source| || - PMIPv6 Tunnel
+--------------+ | - Multicast
| Data Path
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** ** *** *** *** ***
| |
| |
| |
+-----+ +------+
Unicast | LMA | | MTMA | Multicast
Anchor +-----+ +------+ Anchor
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+------+ +------+
| MAG1 | | MAG2 | MLD Proxy
+------+ +------+
| | |
| | |
{MN1} {MN2} {MN3}
Figure 1: Architecture of Multicast Tree Mobility Anchor (MTMA)
図1：マルチキャストツリーモビリティアンカー（MTMA）のアーキテクチャ
Direct routing uses a native multicast infrastructure, allowing a mobile access gateway to directly connect to a multicast router (as next hop) in the PMIPv6 domain. A MAG acts as an MLD proxy.
直接ルーティングはネイティブマルチキャストインフラストラクチャを使用し、モバイルアクセスゲートウェイがPMIPv6ドメイン内のマルチキャストルーター（ネクストホップとして）に直接接続できるようにします。 MAGはMLDプロキシとして機能します。
The main purpose of direct routing is to provide optimal connectivity for local content. As a consequence, it replaces the MTMA of the channel management and data delivery of locally available content. Unicast traffic will go as normally to the LMAs in the PMIPv6 domain.
ダイレクトルーティングの主な目的は、ローカルコンテンツに最適な接続を提供することです。その結果、ローカルで利用可能なコンテンツのチャネル管理とデータ配信のMTMAが置き換えられます。ユニキャストトラフィックは、通常どおりPMIPv6ドメインのLMAに送られます。
This section describes how the direct routing works in scenarios of MN attachment and multicast mobility.
このセクションでは、MN接続とマルチキャストモビリティのシナリオでダイレクトルーティングがどのように機能するかについて説明します。
Multicast Tree
:
: || - PMIPv6 Tunnel
+----------+ +----------+ | - Multicast Data Path
| LMA | | MR |
+----------+ +----------+
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ |
|| /\\ |
|| / \\ |
|| / \\ |
|| / \\ |
|| / \\ |
+--------+ +--------+
| MAG1 | | MAG2 | MLD proxy
+--------+ +--------+
: :
+------+ +------+
| MN1 | -----> | MN1 |
+------+ +------+
Figure 2: Architecture for Direct-Routing-Based PMIPv6 Multicasting
図2：ダイレクトルーティングベースのPMIPv6マルチキャストのアーキテクチャ
Figure 2 shows the architecture for the local routing case using native multicasting infrastructure [PMIP6-REQ].
図2は、ネイティブマルチキャストインフラストラクチャ[PMIP6-REQ]を使用したローカルルーティングケースのアーキテクチャを示しています。
The local mobility anchor is dedicated to unicast traffic, and the multicast traffic is obtained from an upstream multicast router present in the PMIPv6 domain. Note that there can be multiple LMAs for unicast traffic (not shown in Figure 1 for simplicity) in a given PMIPv6 domain.
ローカルモビリティアンカーはユニキャストトラフィック専用であり、マルチキャストトラフィックはPMIPv6ドメインにあるアップストリームマルチキャストルータから取得されます。特定のPMIPv6ドメインには、ユニキャストトラフィック（図1では簡略化のために示されていない）に複数のLMAが存在する可能性があることに注意してください。
As shown in Figure 2, a mobile access gateway may connect to both unicast (LMA) and multicast routers (MRs). Thus, a given mobile node may simultaneously receive both unicast and multicast traffic.
図2に示すように、モバイルアクセスゲートウェイは、ユニキャスト（LMA）とマルチキャストルーター（MR）の両方に接続できます。したがって、所与のモバイルノードは、ユニキャストおよびマルチキャストトラフィックの両方を同時に受信することができる。
As seen in Figure 2, each MAG has a direct connection (i.e., not using the PMIPv6 tunnel interface) with a multicast router. Depending on the multicast support on the visited network, different schemas can be used to provide this direct connection between the MAGs and the multicast router(s), e.g., being connected to the same shared link or using a tunneling approach, such as Generic Routing Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast Tunneling (AMT) [AUTO]. To facilitate IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy function defined in [RFC4605] SHOULD be implemented in the MAG. There SHOULD be direct connectivity between the MAG and the local multicast router (or additional MLD proxy).
図2に示すように、各MAGは、マルチキャストルーターと直接接続しています（つまり、PMIPv6トンネルインターフェイスを使用していません）。訪問したネットワークでのマルチキャストサポートに応じて、異なるスキーマを使用して、MAGとマルチキャストルーターの間にこの直接接続を提供できます。たとえば、同じ共有リンクに接続されている、またはGeneric Routingなどのトンネリングアプローチを使用しているカプセル化（GRE）トンネル[RFC2784]または自動マルチキャストトンネリング（AMT）[AUTO]。 IGMP / MLDシグナリングとマルチキャストトラフィック転送を容易にするために、[RFC4605]で定義されているMLDプロキシ機能をMAGに実装する必要があります（SHOULD）。 MAGとローカルマルチキャストルーター（または追加のMLDプロキシ）の間に直接接続がある必要があります（SHOULD）。
This section describes the operation of the mobile access gateway, considering that the MAG incorporates MLD proxy functions as per [RFC4605].
このセクションでは、MAGが[RFC4605]のようにMLDプロキシ機能を組み込んでいることを考慮して、モバイルアクセスゲートウェイの動作について説明します。
A Binding Update List (BUL) at the MAG, like the one specified in [RFC5213], MUST be maintained to handle the relationship between the serving entities (e.g., MTMA and LMA) and the mobile nodes for both unicast and multicast traffic.
[RFC5213]で指定されているようなMAGのバインディング更新リスト（BUL）は、ユニキャストトラフィックとマルチキャストトラフィックの両方のサービングエンティティ（MTMAやLMAなど）とモバイルノード間の関係を処理するために維持する必要があります。
In case of subscription via MTMA, all MAGs that are connected to the MTMA must support the MLD proxy function [RFC4605]. Specifically in Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces define an MLD proxy domain. The mobile nodes are considered to be on the downstream interface of the MLD proxy (of the MAG), and the MTMA is considered to be on the upstream interface (of the MAG) as per [RFC4605]. Note that the mobile access gateway could also be an IGMP proxy.
MTMAを介したサブスクリプションの場合、MTMAに接続されているすべてのMAGがMLDプロキシ機能[RFC4605]をサポートしている必要があります。具体的には、図1では、MAG1-MTMAおよびMAG2-MTMAトンネルインターフェイスのそれぞれがMLDプロキシドメインを定義しています。 [RFC4605]に従って、モバイルノードは（MAGの）MLDプロキシのダウンストリームインターフェイス上にあると見なされ、MTMAは（MAGの）アップストリームインターフェイス上にあると見なされます。モバイルアクセスゲートウェイはIGMPプロキシでもかまいません。
Figure 3 shows the procedure when MN1 attaches to a MAG, and establishes associations with the LMA (unicast) and the MTMA (multicast).
図3は、MN1がMAGに接続し、LMA（ユニキャスト）およびMTMA（マルチキャスト）との関連付けを確立するときの手順を示しています。
MN1 MAG1 LMA MTMA
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU---->| |
| | | |
| |<----PBA--| |
| | | |
| |=Unicast==| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|< ------ Unicast Traffic------->| |
| | | |
| |==Multicast Tunnel===|
| | | |
|<-------MLD Query----| | |
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|----MLD Report (G)-->| | |
| | | |
| |----Aggregated------>|
| | MLD Report (G) |
| | | |
| | | |
|<-----------Multicast Traffic------------->|
| | | |
Figure 3: MN Attachment and Multicast Service Establishment for MTMA
図3：MTMAのMNアタッチメントとマルチキャストサービスの確立
In Figure 3, the MAG first establishes the PMIPv6 tunnel with LMA for unicast traffic as defined in [RFC5213] after being triggered by the Router Solicitation message from MN1. Unicast traffic will then flow between MN1 and LMA.
図3では、MAGはまず、MN1からのルーター要請メッセージによってトリガーされた後、[RFC5213]で定義されているユニキャストトラフィックのLMAでPMIPv6トンネルを確立します。ユニキャストトラフィックは、MN1とLMAの間を流れます。
For multicast traffic, a multicast tunnel may have been pre-configured between MAG and MTMA, or may be dynamically established when the first MN appears at the MAG.
マルチキャストトラフィックの場合、マルチキャストトンネルはMAGとMTMAの間に事前に設定されているか、最初のMNがMAGに現れたときに動的に確立されます。
MN1 sends the MLD report message (when required by its upper-layer applications) as defined in [RFC3810] in response to an MLD Query from MAG (generated as defined by [RFC6224] upon handover). The MAG, acting as an MLD proxy defined in [RFC4605], will then send an Aggregated MLD Report to the multicast anchor, MTMA (assuming that this is a new multicast group that the MAG had not previously subscribed to). Multicast traffic will then flow from the MTMA towards MN1. The MTMA acts as an MLD Querier, so it will periodically query each mobile access gateway about the subscriptions it maintains (not shown in Figure 3).
MN1は、MAGからのMLDクエリ（[RFC6224]で定義されたように生成）に応答して、[RFC3810]で定義されたMLDレポートメッセージ（上位層アプリケーションで必要な場合）を送信します。 [RFC4605]で定義されたMLDプロキシとして機能するMAGは、マルチキャストMLDレポートをマルチキャストアンカーであるMTMAに送信します（これは、これまでMAGがサブスクライブしていなかった新しいマルチキャストグループであると想定しています）。次に、マルチキャストトラフィックがMTMAからMN1に向かって流れます。 MTMAはMLDクエリアとして機能するため、維持しているサブスクリプションについて各モバイルアクセスゲートウェイに定期的に照会します（図3には表示されていません）。
We next consider a mobility scenario in which MN1 with an ongoing multicast subscription moves from one MAG to another MAG. According to the baseline solution signaling method described in [RFC6224], after MN1 mobility, the new mobile access gateway acting in its role of MLD proxy will send an MLD Query to the newly observed mobile node on its downlink. Assuming that the subsequent MLD Report from MN1 requests membership for a new multicast group (from the new MAG's point of view), this will then result in an Aggregated MLD Report being sent to the MTMA from the new mobile access gateway. This message will be sent through a multicast tunnel between the new MAG and MTMA (pre-established or dynamically established).
次に、マルチキャストサブスクリプションが継続しているMN1が1つのMAGから別のMAGに移動するモビリティシナリオについて検討します。 [RFC6224]で説明されているベースラインソリューションシグナリング方法によれば、MN1モビリティの後、MLDプロキシの役割で動作する新しいモバイルアクセスゲートウェイは、ダウンリンクで新しく観測されたモバイルノードにMLDクエリを送信します。 MN1からの後続のMLDレポートが（新しいMAGの観点から）新しいマルチキャストグループのメンバーシップを要求すると仮定すると、集約されたMLDレポートが新しいモバイルアクセスゲートウェイからMTMAに送信されます。このメッセージは、新しいMAGとMTMAの間のマルチキャストトンネルを介して送信されます（事前確立または動的に確立されます）。
When MN1 detaches, the old MAG may keep the multicast tunnel with the multicast MTMA if there are still other MNs using the multicast tunnel. Even if there are no mobile nodes currently on the multicast tunnel, the old MAG may decide to keep the multicast tunnel temporarily for potential future use.
MN1がデタッチすると、マルチキャストトンネルを使用している他のMNがまだある場合、古いMAGはマルチキャストトンネルをマルチキャストMTMAに保持する可能性があります。マルチキャストトンネル上に現在モバイルノードがない場合でも、古いMAGは将来の使用に備えてマルチキャストトンネルを一時的に保持することを決定する場合があります。
As discussed above, existing MLD (and MLD proxy) signaling will handle a large part of the multicast mobility management for the mobile node.
上記のように、既存のMLD（およびMLDプロキシ）シグナリングは、モバイルノードのマルチキャストモビリティ管理の大部分を処理します。
In this case, the MLD proxy instance is configured to obtain the multicast traffic locally. Figure 4 shows an example of multicast service establishment. The mobile access gateway first establishes the PMIPv6 tunnel with the local mobility anchor for unicast traffic as defined in [RFC5213] after being triggered by the Router Solicitation message from the mobile node. Unicast traffic will then flow between the MN and LMA.
この場合、MLDプロキシインスタンスは、マルチキャストトラフィックをローカルで取得するように構成されています。図4は、マルチキャストサービスの確立の例を示しています。モバイルアクセスゲートウェイは、モバイルノードからのルーター要請メッセージによってトリガーされた後、[RFC5213]で定義されているように、最初にユニキャストトラフィックのローカルモビリティアンカーでPMIPv6トンネルを確立します。ユニキャストトラフィックは、MNとLMAの間を流れます。
For multicast traffic, it is assumed that the upstream interface of the MLD proxy instance has been configured pointing to a multicast router internal to the PMIPv6 domain (or towards an additional MLD proxy node in the domain), for all the multicast channels (which, in consequence, have to be local). There should be direct connectivity between the MAG and the local multicast router (or additional MLD proxy).
マルチキャストトラフィックの場合、MLDプロキシインスタンスのアップストリームインターフェイスは、すべてのマルチキャストチャネル（これは、その結果、ローカルでなければなりません）。 MAGとローカルマルチキャストルーター（または追加のMLDプロキシ）の間に直接接続があるはずです。
MN1 MAG1 LMA MR
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU------->| |
| | | |
| |<-------PBA--| |
| | | |
| |===Unicast===| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|<--------Unicast Traffic---------->| |
| | | |
| | | |
|<-------MLD Query----|<-------------MLD Query----|
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|--MLD Report (G)---->| | |
| | | |
| |----Aggregated------------>|
| | MLD Report (G) |
| | | |
| | | |
|<-------------Multicast Traffic----------------->|
| | | |
Figure 4: Multicast Service Establishment for Direct Routing
図4：直接ルーティングのためのマルチキャストサービスの確立
Upon detecting node attachment from an incoming interface, the MAG adds each downstream interface to the MLD proxy instance with an upstream link to an MR according to the standard MLD proxy operations [RFC4605] and sends an MLD Query message towards the MN. The mobile node sends the MLD report message (when required by its upper-layer applications) in response to an MLD Query from the MAG. Upon receiving the MLD Report message from each incoming interface, the MAG checks the MLD proxy instance associated with the downstream interface and then the MLD Report messages will be aggregated and forwarded to the upstream link associated with the MR (assuming that this is a new multicast group that the MAG had not previously subscribed to). Multicast traffic will then flow from the local multicast router towards the mobile node.
着信インターフェースからのノード接続を検出すると、MAGは、標準のMLDプロキシ操作[RFC4605]に従って、アップストリームリンクを備えたMLDプロキシインスタンスに各ダウンストリームインターフェースをMRに追加し、MNにMLDクエリメッセージを送信します。モバイルノードは、MAGからのMLDクエリに応答して、MLDレポートメッセージを送信します（その上位層アプリケーションで必要な場合）。各着信インターフェイスからMLDレポートメッセージを受信すると、MAGはダウンストリームインターフェイスに関連付けられたMLDプロキシインスタンスをチェックし、MLDレポートメッセージが集約されて、MRに関連付けられたアップストリームリンクに転送されます（これが新しいマルチキャストであると想定） MAGが以前にサブスクライブしていないグループ）。マルチキャストトラフィックは、ローカルマルチキャストルーターからモバイルノードに向かって流れます。
MN1 P-MAG N-MAG LMA MR
| | | | |
| | | | |
|<------------|<-- Multicast Data----------------|
| | . | | |
| | . | | |
| | . | | |
Link Handover | | |
Disconnected Detection | | |
| | | | |
| | | | |
| | MN Attachment | |
| | | | |
| | | | |
|----Rtr Sol------------->| | |
| | | | |
| | |--PBU----->| |
| | | | |
| | |<-----PBA--| |
| | | | |
|<-----------MLD Query----| | |
| | | | |
|----MLD Report---------->| | |
| | | | |
| | |----Aggregated------->|
| | | MLD Report |
| | | | |
|<------------------------|<---Multicast Data----|
| | | | |
Figure 5: Multicast Mobility Signaling for Direct Routing
図5：直接ルーティングのためのマルチキャストモビリティシグナリング
Figure 5 shows the handover operation procedure for the direct routing operation mode. When MN1 hands off to the next MAG (N-MAG) from the previous MAG (P-MAG), the N-MAG detects the newly arrived attached mobile node and performs binding update procedure by exchanging PBU/PBA signaling messages with LMA. At the same time, an MLD proxy instance detecting MN1 transmits an MLD query message to the mobile node. After receiving the MLD query message, MN1 sends an MLD report message that includes the multicast group information. The N-MAG then sends an aggregated MLD report message to the upstream link associated with the MR. An upstream interface of MLD proxy instance is chosen towards certain multicast router. The upstream interface selection can be done according to dynamic policies conveyed in the Dynamic IP Multicast Selector option (as described in Section 5.1) or according to manually configured policies. Note that in the base solution defined in [RFC6224], the interface selection is determined for each MN based on the Binding Update List. When the N-MAG receives the multicast packets from the MR, it then simply forwards them without tunnel encapsulation. The N-MAG updates MN1's location information to the LMA by exchanging PBU/PBA signaling messages.
図5にダイレクトルーティング運用モードのハンドオーバ運用手順を示す。 MN1が前のMAG（P-MAG）から次のMAG（N-MAG）にハンドオフするとき、N-MAGは新しく到着した接続モバイルノードを検出し、LMAとPBU / PBAシグナリングメッセージを交換することでバインディングアップデート手順を実行します。同時に、MN1を検出するMLDプロキシインスタンスは、MLDクエリメッセージをモバイルノードに送信します。 MLDクエリメッセージを受信した後、MN1はマルチキャストグループ情報を含むMLDレポートメッセージを送信します。次に、N-MAGは集約されたMLDレポートメッセージをMRに関連付けられたアップストリームリンクに送信します。 MLDプロキシインスタンスのアップストリームインターフェイスは、特定のマルチキャストルータに向けて選択されます。アップストリームインターフェースの選択は、（セクション5.1で説明されている）動的IPマルチキャストセレクターオプションで伝達される動的ポリシーに従って、または手動で構成されたポリシーに従って行うことができます。 [RFC6224]で定義されている基本ソリューションでは、バインディング選択リストに基づいて各MNのインターフェース選択が決定されることに注意してください。 N-MAGはMRからマルチキャストパケットを受信すると、トンネルカプセル化せずにそれらを転送するだけです。 N-MAGは、PBU / PBAシグナリングメッセージを交換することにより、MN1のロケーション情報をLMAに更新します。
This section includes a new mobility option to support dynamic policies on subscription via MTMA/direct routing based on the local mobility anchor conveying the required info to the mobile access gateway in the proxy binding acknowledgement message.
このセクションには、プロキシバインディング確認メッセージで必要な情報をモバイルアクセスゲートウェイに伝達するローカルモビリティアンカーに基づいて、MTMA /ダイレクトルーティングによるサブスクリプションの動的ポリシーをサポートする新しいモビリティオプションが含まれています。
A new TLV-encoded mobility option, the Dynamic IP Multicast Selector option, is defined for use with the proxy binding acknowledgement message exchanged between an LMA and a MAG to convey dynamic policies on subscription via MTMA/direct routing. This option is used for exchanging the IP addresses of both the group subscribed to by the MN, and the source(s) delivering it, as well as the applicable filter mode. This information is carried by using directly the Multicast Address Record format defined in [RFC3810]. There can be multiple "Dynamic IP Multicast Selector" options present in the message, up to one for each active subscription maintained by the MN.
新しいTLVエンコードされたモビリティオプションであるDynamic IP Multicast Selectorオプションは、LMAとMAGの間で交換されるプロキシバインディング確認メッセージで使用するために定義され、MTMA /ダイレクトルーティングを介してサブスクリプションに関する動的ポリシーを伝達します。このオプションは、MNによってサブスクライブされたグループと、それを配信するソースの両方のIPアドレス、および適用可能なフィルターモードを交換するために使用されます。この情報は、[RFC3810]で定義されているマルチキャストアドレスレコード形式を直接使用することによって伝達されます。メッセージには複数の「ダイナミックIPマルチキャストセレクタ」オプションが存在する場合があり、MNによって維持されるアクティブなサブスクリプションごとに最大1つです。
The format of this new option is as follows:
この新しいオプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |M| Reserved |Nr of Mcast Address Records (N)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
54
５４
Length:
長さ：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
タイプおよび長さフィールドを除く、オクテットでオプションの長さを示す8ビットの符号なし整数。
Protocol:
プロトコル：
Field used to identify the multicast membership protocol in use, and the corresponding format of the next Multicast Address Record. This field maps the type codification used in the original MLD specifications for the Report message, namely for MLDv2 [RFC3810] the Protocol value MUST be 143, whereas for MLDv1 [RFC2710] the Protocol value MUST be 131.
使用中のマルチキャストメンバーシッププロトコル、および次のマルチキャストアドレスレコードの対応する形式を識別するために使用されるフィールド。このフィールドは、レポートメッセージの元のMLD仕様で使用されているタイプコード化をマップします。つまり、MLDv2 [RFC3810]の場合、プロトコル値は143でなければならず、MLDv1 [RFC2710]の場合、プロトコル値は131でなければなりません。
Dynamic IP Multicast Selector Mode Flag (M-bit):
動的IPマルチキャストセレクターモードフラグ（Mビット）：
This field indicates the subscription via MTMA/direct routing mode. If the (M) flag value is set to a value of (1), it is an indication that the IP multicast traffic associated with the multicast group(s) identified by the Multicast Address Record(s) in this mobility option SHOULD be routed locally (subscription via direct routing mode). If the (M) flag value is set to a value of (0), it is an indication that IP multicast traffic associated with the multicast group(s) identified by the Multicast Address Record in this mobility option(s) SHOULD be routed to the home network, via the MTMA (subscription via MTMA mode). The mobile access gateway MAY also choose to use static pre-established policies instead of following the indications provided by the local mobility anchor. All other IP traffic associated with the mobile node is managed according to a default policy configured at the PMIPv6 multicast domain.
このフィールドは、MTMA /直接ルーティングモードによるサブスクリプションを示します。 （M）フラグの値が（1）の値に設定されている場合、これは、このモビリティオプションのマルチキャストアドレスレコードによって識別されるマルチキャストグループに関連付けられているIPマルチキャストトラフィックがルーティングされることを示しています。ローカル（直接ルーティングモードによるサブスクリプション）。 （M）フラグ値が（0）の値に設定されている場合、これは、このモビリティオプションのマルチキャストアドレスレコードによって識別されるマルチキャストグループに関連付けられているIPマルチキャストトラフィックがルーティングされる必要があることを示しています。 MTMA経由のホームネットワーク（MTMAモード経由のサブスクリプション）。モバイルアクセスゲートウェイは、ローカルモビリティアンカーによって提供される指示に従うのではなく、静的な事前に確立されたポリシーを使用することも選択できます（MAY）。モバイルノードに関連する他のすべてのIPトラフィックは、PMIPv6マルチキャストドメインで構成されたデフォルトポリシーに従って管理されます。
Reserved:
予約済み：
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
このフィールドは現在使用されていません。値は送信者によって0に初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
Nr of Mcast Address Records (N)
Mcastアドレスレコードの数（N）
16-bit unsigned integer indicating the number of Mcast Address Records (N) present in this option.
このオプションに存在するMcastアドレスレコード（N）の数を示す16ビットの符号なし整数。
Multicast Address Record:
マルチキャストアドレスレコード：
Multicast subscription information corresponding to a single multicast address as defined in [RFC3810], or as defined in [RFC2710] for MLDv1.
[RFC3810]で定義されている、またはMLDv1の[RFC2710]で定義されている単一のマルチキャストアドレスに対応するマルチキャストサブスクリプション情報。
The MTMA provides connectivity to the multicast infrastructure out of the PMIPv6 domain. The MTMA itself either could act as an additional MLD proxy (only in the case where all the connected mobile access gateways act also as MLD proxies), reporting to a further node an aggregated view of the subscriptions in a PMIPv6 multicast domain, or can act as a designated multicast router for all the MAGs in a PMIPv6 multicast domain. The multicast tree mobility anchor will then request the multicast content on behalf of the MAGs (and mobile nodes behind them). In addition, the MTMA will create and maintain the corresponding multicast forwarding states per each tunnel interface towards the MAGs. Whatever the role played, when the MAGs act as MLD proxy, the MTMA becomes the MLD querier of the MLD proxy instance located in each MAG.
MTMAは、PMIPv6ドメイン外のマルチキャストインフラストラクチャへの接続を提供します。 MTMA自体が追加のMLDプロキシとして機能し（接続されているすべてのモバイルアクセスゲートウェイがMLDプロキシとしても機能する場合のみ）、PMIPv6マルチキャストドメイン内のサブスクリプションの集約ビューを別のノードに報告するか、またはPMIPv6マルチキャストドメイン内のすべてのMAGの指定マルチキャストルータとして。マルチキャストツリーモビリティアンカーは、MAG（およびその背後のモバイルノード）に代わってマルチキャストコンテンツを要求します。さらに、MTMAは、MAGへの各トンネルインターフェイスごとに、対応するマルチキャスト転送状態を作成および維持します。どのような役割を果たしても、MAGがMLDプロキシとして機能する場合、MTMAは各MAGにあるMLDプロキシインスタンスのMLDクエリアになります。
The multicast tree mobility anchor does not directly interact with the mobile nodes attached to any of the mobile access gateways. The MTMA only manages the multicast groups subscribed per MAG on behalf of the MNs attached to it. Having this in mind, the relevant information to be stored in the MTMA should be the tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel for multicast between the MTMA and every MAG (e.g., similar to what is stated in [RFC5213] for the unicast case), the IP addresses of the multicast group delivered per tunnel to each of the MAGs, and the IP addresses of the sources injecting the multicast traffic per tunnel to the multicast domain defined by the MTMA.
マルチキャストツリーモビリティアンカーは、モバイルアクセスゲートウェイに接続されているモバイルノードと直接対話しません。 MTMAは、接続されているMNに代わって、MAGごとにサブスクライブされたマルチキャストグループのみを管理します。これを念頭に置いて、MTMAに格納される関連情報は、MTMAとすべてのMAGの間のマルチキャスト用の双方向トンネルのトンネルインターフェイス識別子（tunnel-if-id）である必要があります（たとえば、[RFC5213 ]ユニキャストの場合）、トンネルごとに各MAGに配信されるマルチキャストグループのIPアドレス、およびトンネルごとにMTMAによって定義されたマルチキャストドメインにマルチキャストトラフィックを注入するソースのIPアドレス。
The mobile node operation is not impacted by the existence of an MTMA as anchor for the multicast traffic being subscribed or the use of direct routing. The MN will act according to the stated operations in [RFC5213] and [RFC6224].
モバイルノードの動作は、サブスクライブされるマルチキャストトラフィックのアンカーとしてのMTMAの存在や直接ルーティングの使用による影響を受けません。 MNは、[RFC5213]および[RFC6224]に記載されている動作に従って動作します。
This document considers that every mobile node requesting multicast-only services is previously registered in a PMIPv6 unicast domain to get a unicast IP address. The registration can also be required for several purposes such as remote management, billing, multicast configuration, etc.
このドキュメントでは、マルチキャストのみのサービスを要求するすべてのモバイルノードが、ユニキャストIPアドレスを取得するために以前にPMIPv6ユニキャストドメインに登録されていることを考慮しています。登録は、リモート管理、請求、マルチキャスト構成など、いくつかの目的で必要になる場合もあります。
A given mobile node's policy profile information must be updated to be able to store the IPv6 addresses of both the local mobility anchor and multicast tree mobility anchor, the later for the subscription via MTMA case.
特定のモバイルノードのポリシープロファイル情報は、ローカルモビリティアンカーとマルチキャストツリーモビリティアンカーの両方のIPv6アドレスを保存できるように更新する必要があります。
This document does not introduce any IPv4-specific issue regarding [RFC5844]. In order for the solution to support IPv4, all the described network elements (i.e., MAG, MTMA, and MR) must support IGMP. In this case, the functionalities of the MAG and MTMA would be as described in [RFC6224], with the MTMA replicating the requirements described for the LMA. For the case of the MR, it must also be dual-stack (i.e., IPv6/IPv4) enabled.
このドキュメントでは、[RFC5844]に関するIPv4固有の問題を紹介していません。ソリューションがIPv4をサポートするためには、説明されているすべてのネットワーク要素（MAG、MTMA、MRなど）がIGMPをサポートしている必要があります。この場合、MAGとMTMAの機能は[RFC6224]で説明されているとおりであり、MTMAはLMAについて説明されている要件を複製します。 MRの場合は、デュアルスタック（IPv6 / IPv4）も有効にする必要があります。
Although references to "MLD proxy" have been used in the document, it should be understood to also include "IGMP/MLD proxy" functionality.
このドキュメントでは「MLDプロキシ」への参照が使用されていますが、「IGMP / MLDプロキシ」機能も含まれていることを理解する必要があります。
Regarding the Dynamic IP Multicast Selector Option format, it SHOULD consider IPv4 compatibility in the following way: Protocol field:
動的IPマルチキャストセレクターオプションの形式については、IPv4の互換性を次のように考慮する必要があります。プロトコルフィールド：
For IPv4, this field maps the type codification used in the original IGMP specifications for the Report message, in the following way:
IPv4の場合、このフィールドは、レポートメッセージの元のIGMP仕様で使用されているタイプコード化を次のようにマップします。
It MUST be 0x12 in case of using IGMPv1.
IGMPv1を使用する場合は、0x12でなければなりません。
It MUST be 0x16 in case of using IGMPv2.
IGMPv2を使用する場合は、0x16でなければなりません。
It MUST be 0x22 in case of using IGMPv3.
IGMPv3を使用する場合は0x22でなければなりません。
Multicast Address Record field:
マルチキャストアドレスレコードフィールド：
This field takes different formats depending on the IGMP version being used by the MN, as follows:
このフィールドは、次のように、MNで使用されているIGMPバージョンに応じて異なる形式を取ります。
* For IGMPv1, it takes the format given by the Group Address in [RFC1112].
* IGMPv1の場合、[RFC1112]のグループアドレスで指定された形式になります。
* For IGMPv2, it takes the format given by the Group Address in [RFC2236].
* IGMPv2の場合、[RFC2236]のグループアドレスで指定された形式になります。
* For IGMPv3, it takes the format given by the Group Record in [RFC3376].
* IGMPv3の場合、[RFC3376]のグループレコードで指定された形式になります。
This document defines a new mobility option, the Dynamic IP Multicast Selector, which has been assigned the Type 54 by IANA. The Type value for these options has been assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC6275]: http://www.iana.org/assignments/mobility-parameters.
このドキュメントでは、IANAによってType 54が割り当てられた新しいモビリティオプションであるDynamic IP Multicast Selectorを定義します。これらのオプションのタイプ値は、[RFC6275]で定義されているように、他のモビリティオプションに割り当てられているのと同じ番号付けスペースから割り当てられています：http://www.iana.org/assignments/mobility-parameters。
This document describes two complementary operational modes that can be used to deliver multicast traffic in a PMIPv6 domain: multicast anchor and direct routing. Different approaches are described in the document to decide which operational mode is selected: i) the use of pre-configured/pre-provisioned policies at the mobile access gateway, or ii) the use of dynamic policies. Approach ii) could introduce a potential security issue if the protocol signaling is not properly secured. The use of the Dynamic IP Multicast Selector option described in the document requires message integrity protection and source authentication. Hence, the IPsec security mechanism recommended by Proxy Mobile IPv6 [RFC5213] MUST be used to secure the Dynamic IP Multicast Selector option conveyed in the PBA (Proxy Binding Acknowledgement).
このドキュメントでは、PMIPv6ドメインでマルチキャストトラフィックを配信するために使用できる2つの補完的な動作モード、マルチキャストアンカーとダイレクトルーティングについて説明します。このドキュメントでは、選択する運用モードを決定するためのさまざまなアプローチについて説明します。i）モバイルアクセスゲートウェイで事前構成/事前プロビジョニングされたポリシーを使用する、またはii）動的ポリシーを使用する。アプローチii）は、プロトコルシグナリングが適切に保護されていない場合、潜在的なセキュリティ問題を引き起こす可能性があります。このドキュメントで説明されているダイナミックIPマルチキャストセレクタオプションを使用するには、メッセージの整合性保護と送信元認証が必要です。したがって、PBA（Proxy Binding Acknowledgement）で伝えられる動的IPマルチキャストセレクターオプションを保護するために、プロキシモバイルIPv6 [RFC5213]によって推奨されるIPsecセキュリティメカニズムを使用する必要があります。
This document does not introduce any additional security threats beyond the current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], IGMP [RFC3376], and IGMP/MLD Proxying [RFC4605].
このドキュメントでは、PMIPv6 [RFC5213]、MLD [RFC3810]、IGMP [RFC3376]、およびIGMP / MLDプロキシ[RFC4605]の現在のセキュリティに関する考慮事項以外のセキュリティ上の脅威は紹介していません。
The following individuals made significant contributions to this document.
以下の個人は、この文書に重要な貢献をしました。
Akbar Rahman InterDigital Communications, LLC EMail: akbar.rahman@interdigital.com
Akbar Rahman InterDigital Communications、LLC Eメール：akbar.rahman@interdigital.com
Ignacio Soto Universidad Carlos III de Madrid EMail: isoto@it.uc3m.es
イグナシオソトカルロスIIIマドリッド大学メール：isoto@it.uc3m.es
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。
[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月。
[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月。
[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月。
[RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010.
[RFC5847] Devarapalli、V.、Koodli、R.、Lim、H.、Kant、N.、Krishnan、S.、J。Laganier、「Heartbeat Mechanism for Proxy Mobile IPv6」、RFC 5847、2010年6月。
[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月。
[AUTO] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, July 2013.
[AUTO] Bumgardner、G。、「Automatic Multicast Tunneling」、Work in Progress、2013年7月。
[MLDPROXY] Asaeda, H. and S. Jeon, "Multiple Upstream Interface Support for IGMP/MLD Proxy", Work in Progress, February 2013.
[MLDPROXY] Asaeda、H. and S. Jeon、「Multiple Upstream Interface Support for IGMP / MLD Proxy」、Work in Progress、2013年2月。
[MUIIMP] Zhang, H. and T. Schmidt, "Multi-Upstream Interfaces IGMP/MLD Proxy", Work in Progress, July 2013.
[MUIIMP] Zhang、H。およびT. Schmidt、「Multi-Upstream Interfaces IGMP / MLD Proxy」、Work in Progress、2013年7月。
[MULTIMOB] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Work in Progress, July 2013.
[MULTIMOB] Schmidt、T.、Gao、S.、Zhang、H。、およびM. Waehlisch、「プロキシモバイルIPv6（PMIPv6）ドメインでのモバイルマルチキャスト送信者のサポート」、作業中、2013年7月。
[PMIP6-REQ] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
[PMIP6-REQ] Deng、H.、Chen、G.、Schmidt、T.、Seite、P。、およびP. Yang、「プロキシモバイルIPv6のマルチキャストサポート要件」、進行中の作業、2009年7月。
[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月。
[UPSTREAM] Contreras, LM., Bernardos, CJ., and JC. Zuniga, "Extension of the MLD proxy functionality to support multiple upstream interfaces", Work in Progress, February 2013.
[アップストリーム]コントレラス、LM、ベルナルドス、CJ、JC。 Zuniga、「複数のアップストリームインターフェイスをサポートするためのMLDプロキシ機能の拡張」、Work in Progress、2013年2月。
This informative appendix describes, from the network architecture point of view, several deployment options considering the MTMA.
この有益な付録では、ネットワークアーキテクチャの観点から、MTMAを考慮したいくつかの展開オプションについて説明します。
These options can be distinguished in terms of the number of LMAs and MTMAs present in a PMIPv6 domain and the service relationship that a set of MNs gets from them, in the form of a "LMA : MTMA" ratio. According to that, it is possible to differentiate the following approaches:
これらのオプションは、PMIPv6ドメインに存在するLMAとMTMAの数、および一連のMNがそれらから取得するサービス関係の観点から、「LMA：MTMA」比率の形で区別できます。それによると、以下のアプローチを区別することが可能です：
o A set of MNs is served in a PMIPv6 domain by two entities, one MTMA for multicast service, and one LMA for unicast, in such a way that the ratio is 1:1 (one common PMIPv6 unicast and multicast domain).
o MNのセットは、比率が1：1になるように、2つのエンティティ、マルチキャストサービス用の1つのMTMA、およびユニキャスト用の1つのLMAによってPMIPv6ドメインで提供されます（1つの一般的なPMIPv6ユニキャストおよびマルチキャストドメイン）。
o A set of MNs is served in a PMIPv6 domain by several entities, one MTMA for multicast service, while the others (LMAs) for unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast domains coexist with a unique multicast domain).
o MNのセットは、複数のエンティティによってPMIPv6ドメインで処理されます。1つはマルチキャストサービス用のMTMA、他は（ユニキャスト）用のLMAで、比率はN：1です（N PMIPv6ユニキャストドメインは一意のマルチキャストと共存します）。ドメイン）。
o A set of MNs is served in a PMIPv6 domain by several entities, one LMA for unicast, while the others (MTMAs) are devoted to multicast service, in such a way that the ratio is 1:N (one single PMIPv6 unicast domain coexists with multiple multicast domains).
o MNのセットは、PMIPv6ドメインでいくつかのエンティティによって提供されます。1つはユニキャスト用のLMAですが、他の（MTMA）はマルチキャストサービス専用であり、比率が1：N（1つの単一のPMIPv6ユニキャストドメインが複数のマルチキャストドメイン）。
Scenarios with an N:M ratio are considered to be a combination of the previous ones.
N：M比のシナリオは、以前のシナリオの組み合わせであると見なされます。
This approach refers to the architecture presented in Figure 1. Within this approach, a common set of MNs is served by a couple of entities, one LMA for unicast and one MTMA for multicast. All the MNs of the set are served by these two elements as they move in the PMIPv6 domain.
このアプローチは、図1に示したアーキテクチャを参照しています。このアプローチでは、MNの共通セットは、ユニキャスト用のLMAとマルチキャスト用の1つのMTMAの2つのエンティティによって処理されます。セットのすべてのMNは、PMIPv6ドメイン内を移動するときに、これら2つの要素によって処理されます。
This approach refers to the situation where a common set of MNs is served by a unique MTMA for multicast service, but simultaneously there are subsets from that group of MNs that are served by distinct LMAs for unicast service as they move in the PMIPv6 domain. Each particular MN association with the LMAs (unicast) and MTMA (multicast) remains always the same as it moves in the PMIPv6 domain.
このアプローチは、MNの共通のセットがマルチキャストサービスの一意のMTMAによって処理されるが、同時に、PMIPv6ドメインで移動するときに、ユニキャストサービスの異なるLMAによって処理されるMNのグループからのサブセットがある状況を指します。 LMA（ユニキャスト）およびMTMA（マルチキャスト）との特定の各MNアソシエーションは、PMIPv6ドメイン内を移動するときに常に同じです。
Figure 6 shows the scenario here described.
図6は、ここで説明するシナリオを示しています。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | MTMA2 | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\oo oo oo oo // ||
|| \\ oo oo oo// ||
|| oo\\ oo oo // ||
|| oo \\ oo oo //oo ||
|| oo \\ oo oo // oo ||
|| oo \\ oo oo // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 6: PMIPv6 Domain with Ratio N:1
図6：比率N：1のPMIPv6ドメイン
Figure 6 proposes an architecture where there are two entities acting as LMAs, LMA1 and LMA3, while there is another one, named MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3 constitute two distinct unicast domains, whereas MTMA2 forms a single multicast domain. The tunnels among MAGs and LMAs represented by lines ("||") indicate a tunnel transporting unicast traffic, while the tunnels among MAGs and MTMA2 depicted with circles ("o") show a tunnel transporting multicast traffic.
図6は、LMA1およびLMA3として動作する2つのエンティティがあり、MTMA2という名前の別のエンティティがマルチキャストツリーモビリティアンカーとして動作するアーキテクチャを提案しています。 LMA1とLMA3は2つの異なるユニキャストドメインを構成し、MTMA2は単一のマルチキャストドメインを形成します。線（ "||"）で表されたMAGとLMA間のトンネルは、ユニキャストトラフィックを伝送するトンネルを示し、円（ "o"）で示されたMAGとMTMA2間のトンネルは、マルチキャストトラフィックを伝送するトンネルを示します。
In the figure, it can be observed that all the MNs are served by MTMA2 for the incoming multicast traffic from sources A or B.
この図では、ソースAまたはBからの着信マルチキャストトラフィックに対して、すべてのMNがMTMA2によって処理されていることがわかります。
However, there are different subsets regarding unicast traffic, which maintain distinct associations within the PMIPv6 domain. For instance, the subset formed by MN10, MN11, MN20, and MN21 is served by LMA1 for unicast, and the rest of MNs are served by LMA3. For the scenario described above, the association between each MN and the corresponding LMA and MTMA is permanently maintained.
ただし、ユニキャストトラフィックに関しては異なるサブセットがあり、PMIPv6ドメイン内で異なる関連付けが維持されます。たとえば、MN10、MN11、MN20、およびMN21によって形成されるサブセットは、ユニキャスト用のLMA1によって処理され、残りのMNはLMA3によって処理されます。上記のシナリオでは、各MNと対応するLMAおよびMTMAの間の関連付けが永続的に維持されます。
This approach is related to a scenario where a common group of MNs is served by a unique LMA for unicast service, but simultaneously there are subsets from that group of MNs that are served by distinct MTMAs for multicast service as they move in the PMIPv6 domain. Different MTMAs might be associated with serving different multicast groups. These associations remain the same even if the MNs move within the PMIPv6 domain.
このアプローチは、MNの共通グループがユニキャストサービスの一意のLMAによって処理されるシナリオに関連していますが、同時に、PMIPv6ドメインで移動するときに、マルチキャストサービスの個別のMTMAによって処理されるMNのグループからのサブセットがあります。異なるMTMAが、異なるマルチキャストグループの提供に関連付けられる場合があります。これらの関連付けは、MNがPMIPv6ドメイン内で移動しても同じままです。
Figure 7 shows the scenario here described.
図7は、ここで説明するシナリオを示しています。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| ******************** |
( ) * * ( )
( ) * Fixed Internet * ( )
( ) * (Unicast Traffic) * ( )
( ) * * ( )
( ) ******************** ( )
| | |
| | |
+------+ +--------------+ +------+
| MTMA1| | LMA2 | | MTMA3|
+------+ +--------------+ +------+
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo/ ^^ ^^
oo //oo ^^ \\ ^^
oo // oo ^^ \\ ^^
oo // oo \\ ^^
oo // ^^ oo \\ ^^
oo // ^^ oo \^^
+-------------+ +-------------+
| \ / | | \ | |
| ~o~~~~o~ | | ~o~~~~o~ |
| ( MLD w ) | | ( MLD w ) |
| ( multip ) | | ( multip ) |
| ( i/f ) | | ( i/f ) |
| ~~~~~~~~ | | ~~~~~~~~ |
| | | |
| MAG1 | | MAG2 |
/+-------------+ +-------------+\
| | | | | |
| | | | | |
{MN10} {MN11} {MN12} {MN20} {MN21} {MN22}
Figure 7: PMIPv6 Domain with Ratio 1:N
図7：比率1：NのPMIPv6ドメイン
Figure 7 proposes an architecture where the LMA2 is the unique LMA for a certain group of MNs, while there are two other entities, MTMA1 and MTMA3, acting as MTMAs for different subsets of multicast content. MTMA1 and MTMA3 constitute two distinct multicast domains, whereas LMA2 forms a single unicast domain. Each MTMA could be devoted to carry on a different content (for instance, MTMA1 for source A and MTMA3 for source B). Looking at the figure, all MNs are served by LMA2 for unicast, while they might be simultaneously served by MTMA1 and MTMA3, depending on the multicast content. For the scenario described above, the association between multicast content and MTMA is permanently maintained. Note that this scenario would require support for MLD proxy with multiple interfaces [MULTIMOB], [UPSTREAM], [MLDPROXY], [MUIIMP] at the MAGs.
図7は、LMA2がMNの特定のグループの一意のLMAであるアーキテクチャを提案していますが、他の2つのエンティティ、MTMA1およびMTMA3があり、マルチキャストコンテンツの異なるサブセットのMTMAとして機能しています。 MTMA1とMTMA3は2つの異なるマルチキャストドメインを構成しますが、LMA2は単一のユニキャストドメインを形成します。各MTMAは、異なるコンテンツ（たとえば、ソースAのMTMA1とソースBのMTMA3）を実行することに専念できます。図を見ると、すべてのMNはLMA2によってユニキャストで提供されていますが、マルチキャストコンテンツによっては、MTMA1とMTMA3で同時に提供される場合があります。上記のシナリオでは、マルチキャストコンテンツとMTMA間の関連付けが永続的に維持されます。このシナリオでは、MAGで複数のインターフェイス[MULTIMOB]、[UPSTREAM]、[MLDPROXY]、[MUIIMP]を備えたMLDプロキシのサポートが必要になることに注意してください。
The H-LMA is defined as an entity that simultaneously transports unicast and multicast service, that is, it simultaneously works as LMA and MTMA. In the context of the MTMA solution, an H-LMA can play the role of MTMA for an entire group of MNs in a PMIPv6 domain, while acting simultaneously as LMA for a subset of them. Figure 8 adapts the PMIPv6 domain with ratio N:1 scenario of Figure 6 to the case where MTMA2 is an H-LMA, which serves multicast traffic to all the MNs in the picture, and simultaneously, it is able to serve unicast traffic to the subset formed by MN21 and MN30.
H-LMAは、ユニキャストサービスとマルチキャストサービスを同時に転送するエンティティとして定義されます。つまり、LMAおよびMTMAとして同時に機能します。 MTMAソリューションのコンテキストでは、H-LMAはPMIPv6ドメイン内のMNのグループ全体に対してMTMAの役割を果たすと同時に、それらのサブセットのLMAとしても機能します。図8は、図6の比率N：1のシナリオのPMIPv6ドメインを、MTMA2がH-LMAであり、画像内のすべてのMNにマルチキャストトラフィックを提供すると同時に、ユニキャストトラフィックをMN21とMN30で構成されるサブセット。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | H-LMA | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\oo db db oo // ||
|| \\ db db oo// ||
|| oo\\ db db // ||
|| oo \\ db db //oo ||
|| oo \\ db db // oo ||
|| oo \\ db db // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 8: PMIPv6 Domain with H-LMA
図8：H-LMAを使用したPMIPv6ドメイン
Figure 8 presents a PMIPv6 network where there are two pure unicast LMAs, LMA1, and LMA3, and a hybrid LMA, labeled as H-LMA in the figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. The tunnels among MAGs and LMAs represented by lines ("||") indicate a tunnel transporting exclusively unicast traffic, the tunnels depicted with circles ("o") show a tunnel transporting exclusively multicast traffic, and the tunnels with mixed lines and circles ("db") describe a tunnel transporting both types of traffic simultaneously.
図8は、2つの純粋なユニキャストLMA、LMA1、LMA3、および図でH-LMAとラベル付けされたハイブリッドLMAがあるPMIPv6ネットワークを示しています。 H-LMAは、MAG1およびMAG4の観点から見たMTMAです。線（ "||"）で表されるMAGとLMA間のトンネルは、ユニキャストトラフィックのみを転送するトンネルを示し、円（ "o"）で示されるトンネルは、マルチキャストトラフィックのみを転送するトンネルを示し、線と円が混在するトンネル（ "db"）は、両方のタイプのトラフィックを同時に転送するトンネルを表します。
All of the MNs in the figure receive the multicast traffic from H-LMA (one single multicast domain), but it is possible to distinguish three subsets from the unicast service perspective (that is, three unicast domains). The first subset is the one formed by MN10, MN11, and MN20, which receives unicast traffic from LMA1. A second subset is the one formed by MN21 and MN30, which receives unicast traffic from H-LMA. And finally, a third subset is built on MN31, MN40, and MN41, which receives unicast traffic from LMA3. For the scenario described above, the association between each MN and the corresponding LMA and H-LMA is permanently maintained.
図のすべてのMNはH-LMA（単一のマルチキャストドメイン）からマルチキャストトラフィックを受信しますが、ユニキャストサービスの観点から3つのサブセット（つまり、3つのユニキャストドメイン）を区別することができます。最初のサブセットは、MN10、MN11、およびMN20によって形成されるサブセットであり、LMA1からユニキャストトラフィックを受信します。 2番目のサブセットは、MN21とMN30によって形成されるサブセットで、H-LMAからユニキャストトラフィックを受信します。最後に、LMA3からユニキャストトラフィックを受信するMN31、MN40、およびMN41に3番目のサブセットが構築されます。上記のシナリオでは、各MNと対応するLMAおよびH-LMAの間の関連付けが永続的に維持されます。
Authors' Addresses
著者のアドレス
Juan Carlos Zuniga InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada EMail: JuanCarlos.Zuniga@InterDigital.com URI: http://www.InterDigital.com/
Juan Carlos Zuniga InterDigital Communications、LLC 1000 Sherbrooke Street West、10th floor Montreal、Quebec H3A 3G4 Canada EMail：JuanCarlos.Zuniga@InterDigital.com URI：http://www.InterDigital.com/
Luis M. Contreras Telefonica I+D Don Ramon de la Cruz, 82-84 Madrid 28006 Spain EMail: lmcm@tid.es
Luis M. Contreras Telefonica I + D Don Ramon de la Cruz、82-84マドリード28006スペインEメール：lmcm@tid.es
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
Aveiro 3810-193
Portugal
EMail: seiljeon@av.it.pt
URI: https://atnog.av.it.pt/~sjeon/
Younghan Kim Soongsil University Sangdo-dong, Dongjak-gu Seoul 511 Republic of Korea EMail: yhkim@dcn.ssu.ac.kr URI: http://dcnlab.ssu.ac.kr/
ヨンハンキムソンシル大学ドンジャク区サンドドンソウル511大韓民国Eメール：yhkim@dcn.ssu.ac.kr URI：http://dcnlab.ssu.ac.kr/