[要約] RFC 5757は、MIPv6におけるマルチキャストモビリティに関する問題の声明と簡単な調査を提供しています。このRFCの目的は、MIPv6におけるマルチキャストモビリティの問題を明確にし、解決策を提案することです。
Internet Research Task Force (IRTF) T. Schmidt
Request for Comments: 5757 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab
G. Fairhurst
University of Aberdeen
February 2010
Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
モバイルIPバージョン6（MIPV6）のマルチキャストモビリティ：問題の声明と簡単な調査
Abstract
概要
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
このドキュメントでは、現在のモビリティ拡張機能がIP層マルチキャストへの拡張機能について説明します。一般的なモバイルグループ通信、マルチキャストリスナーモビリティの場合、およびソースマルチキャストおよびソース固有のマルチキャストを使用したモバイルセンダーの問題について発生する問題について説明します。固定IPv6ネットワークのマルチキャストルーティングと展開の問題の特徴的な側面が要約されています。基礎となるネットワークアクセスとの特定のプロパティと相互作用は、ワイヤレスドメインの関連技術に関して調査されます。マルチキャストモビリティへの主要なアプローチと、モバイルマルチキャストの問題とソリューションスペースの包括的な調査の概要を説明します。このドキュメントは、将来のモバイルマルチキャストプロトコルデザイナーが使用するための標準化の初期ステップの概念的なロードマップで締めくくります。このドキュメントは、IP Mobility Optimizations（MOBOPTS）研究グループの製品です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the MobOpts Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のMobopts Research Groupのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。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/rfc5757.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5757で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction and Motivation .....................................4
1.1. Document Scope .............................................5
2. Problem Description .............................................6
2.1. General Issues .............................................6
2.2. Multicast Listener Mobility ................................9
2.2.1. Node and Application Perspective ....................9
2.2.2. Network Perspective ................................10
2.3. Multicast Source Mobility .................................11
2.3.1. Any Source Multicast Mobility ......................11
2.3.2. Source-Specific Multicast Mobility .................12
2.4. Deployment Issues .........................................13
3. Characteristics of Multicast Routing Trees under Mobility ......14
4. Link Layer Aspects .............................................15
4.1. General Background ........................................15
4.2. Multicast for Specific Technologies .......................16
4.2.1. 802.11 WLAN ........................................16
4.2.2. 802.16 WIMAX .......................................16
4.2.3. 3GPP/3GPP2 .........................................18
4.2.4. DVB-H / DVB-IPDC ...................................19
4.2.5. TV Broadcast and Satellite Networks ................19
4.3. Vertical Multicast Handovers ..............................20
5. Solutions ......................................................20
5.1. General Approaches ........................................20
5.2. Solutions for Multicast Listener Mobility .................21
5.2.1. Agent Assistance ...................................21
5.2.2. Multicast Encapsulation ............................22
5.2.3. Hybrid Architectures ...............................23
5.2.4. MLD Extensions .....................................23
5.3. Solutions for Multicast Source Mobility ...................24
5.3.1. Any Source Multicast Mobility Approaches ...........24
5.3.2. Source-Specific Multicast Mobility Approaches ......25
6. Security Considerations ........................................26
7. Summary and Future Steps .......................................27
Appendix A. Implicit Source Notification Options...................29
Informative References.............................................29
Acknowledgments....................................................37
Group communication forms an integral building block of a wide variety of applications, ranging from content broadcasting and streaming, voice and video conferencing, collaborative environments and massive multiplayer gaming, up to the self-organization of distributed systems, services, or autonomous networks. Network-layer multicast support will be needed whenever globally distributed, scalable, serverless, or instantaneous communication is required.
グループコミュニケーションは、コンテンツブロードキャストとストリーミング、音声とビデオ会議、共同環境、大規模なマルチプレイヤーゲーム、分散システム、サービス、または自律ネットワークの自己組織化まで、さまざまなアプリケーションの不可欠なビルディングブロックを形成します。ネットワーク層のマルチキャストサポートは、グローバルに分散、スケーラブル、サーバーレス、または瞬時通信が必要な場合はいつでも必要です。
The early idea of Internet multicasting [1] soon led to a wide adoption of Deering's host group model [2]. Broadband media delivery is emerging as a typical mass scenario that demands scalability and bandwidth efficiency from multicast routing. Although multicast mobility has been a concern for about ten years [3] and has led to numerous proposals, there is as yet no generally accepted solution. Multicast network support will be of particular importance to mobile environments, where users commonly share frequency bands of limited capacity. Reception of "infotainment" streams may soon require wide deployment of mobile multicast services.
インターネットマルチリキャスト[1]の初期のアイデアは、すぐにディアリングのホストグループモデル[2]の幅広い採用につながりました。ブロードバンドメディアの配信は、マルチキャストルーティングからスケーラビリティと帯域幅の効率を要求する典型的な大量シナリオとして浮上しています。マルチキャストモビリティは約10年間懸念されており[3]、多くの提案につながっていますが、一般的に受け入れられている解決策はまだありません。マルチキャストネットワークサポートは、ユーザーが一般に限られた容量の周波数帯域を共有するモバイル環境にとって特に重要です。「インフォテインメント」ストリームの受信には、すぐにモバイルマルチキャストサービスの幅広い展開が必要になる場合があります。
Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5][6], and it addresses the scenario of network-layer changes while moving between wireless domains. MIPv6 [5] only roughly defines multicast mobility for Mobile Nodes (MNs) using a remote subscription approach or through bidirectional tunneling via the Home Agent (HA). Remote subscription suffers from slow handovers relying on multicast routing to adapt to handovers. Bidirectional tunneling introduces inefficient overhead and delay due to triangular forwarding, i.e., instead of traveling on shortest paths, packets are routed through the Home Agent. Therefore, these approaches have not been optimized for a large scale deployment. A mobile multicast service for a future Internet should provide "close-to-optimal" routing at predictable and limited cost, offering robustness combined with a service quality compliant to real-time media distribution.
IPv6 [4]のモビリティは、モバイルIPv6 RFCS [5] [6]で標準化されており、ワイヤレスドメイン間を移動しながらネットワーク層の変化のシナリオに対処します。MIPV6 [5]は、リモートサブスクリプションアプローチを使用して、またはホームエージェント（HA）を介した双方向トンネルを使用して、モバイルノード（MNS）のマルチキャストモビリティのみをほぼ定義しています。リモートサブスクリプションは、ハンドオーバーに適応するためにマルチキャストルーティングに依存する遅い拳銃に苦しんでいます。双方向トンネリングは、三角形の転送による非効率的なオーバーヘッドと遅延を導入します。つまり、最短経路で移動する代わりに、パケットはホームエージェントを介してルーティングされます。したがって、これらのアプローチは、大規模な展開に最適化されていません。将来のインターネット向けのモバイルマルチキャストサービスは、予測可能かつ限られたコストで「最適な」ルーティングを提供し、リアルタイムメディアの配布とサービス品質に準拠した堅牢性を提供する必要があります。
Intricate multicast routing procedures are not easily extensible to satisfy the requirements for mobility. A client subscribed to a group while performing mobility handovers requires the multicast traffic to follow to its new location; a mobile source needs the entire delivery tree to comply with or to adapt to its changing position. Significant effort has already been invested in protocol designs for mobile multicast receivers; only limited work has been dedicated to multicast source mobility, which poses the more delicate problem [65].
複雑なマルチキャストルーティング手順は、モビリティの要件を満たすために簡単に拡張できません。モビリティハンドオーバーの実行中にグループに購読したクライアントは、新しい場所に従うためにマルチキャストトラフィックが必要です。モバイルソースは、その変化する位置に準拠したり、適応するために配送ツリー全体を必要とします。モバイルマルチキャストレシーバーのプロトコル設計にはすでに多大な努力が投資されています。限られた作業のみがマルチキャストソースモビリティに専念しており、より繊細な問題を引き起こします[65]。
In multimedia conference scenarios, games, or collaborative environments, each member commonly operates as a receiver and as a sender for multicast group communication. In addition, real-time communication such as conversational voice or video places severe temporal requirements on mobility protocols: Typical seamless handover scenarios are expected to limit disruptions or delay to less than 100 - 150 ms [7]. Jitter disturbances should not exceed 50 ms. Note that 100 ms is about the duration of a spoken syllable in real-time audio. This problem statement is intended to also be applicable to a range of other scenarios with a range of delivery requirements appropriate to the general Internet.
マルチメディアカンファレンスシナリオ、ゲーム、または共同環境では、各メンバーは一般に、マルチキャストグループコミュニケーションの送信者として一般的に動作します。さらに、会話の音声やビデオなどのリアルタイムのコミュニケーションは、モビリティプロトコルに深刻な時間的要件を配置します。典型的なシームレスハンドオーバーシナリオは、100〜150ミリ秒未満に混乱または遅延を制限すると予想されます[7]。ジッターの乱れは50ミリ秒を超えてはなりません。100ミリ秒は、リアルタイムオーディオでの音声音節の期間についてです。この問題ステートメントは、一般的なインターネットに適したさまざまな配信要件を備えた他のさまざまなシナリオにも適用できることを目的としています。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by the Research Group members active in the specific area of work. In addition, this document has been comprehensively reviewed by multiple active contributors to the IETF MEXT, MBONED, and PIM Working Groups.
この文書は、Mobopts Research Groupのコンセンサスを表しています。特定の作業分野で活動している研究グループメンバーによってレビューされています。さらに、このドキュメントは、IETF MEXT、MBONED、およびPIMワーキンググループの複数のアクティブな貢献者によって包括的にレビューされています。
This document defines the problem scope for multicast mobility management, which may be elaborated in future work. It is subdivided to present the various challenges according to their originating aspects, and identifies existing proposals and major bibliographic references.
このドキュメントでは、将来の作業で詳しく説明される可能性のあるマルチキャストモビリティ管理の問題範囲を定義しています。彼らの起源の側面に従ってさまざまな課題を提示することは細分化されており、既存の提案と主要な書誌的参照を特定します。
When considering multicast node mobility, the network layer is complemented by some wireless access technology. Two basic scenarios are of interest: single-hop mobility (shown in Figure 1.a) and multi-hop mobility (shown in Figure 1.b). Single-hop mobility is the focus of this document, which coincides with the perspective of MIPv6 [5]. The key issues of mobile multicast membership control and the interplay of mobile and multicast routing will be illustrated using this simple scenario.
マルチキャストノードモビリティを検討する場合、ネットワークレイヤーはいくつかのワイヤレスアクセステクノロジーによって補完されます。2つの基本的なシナリオが興味深いです：シングルホップモビリティ（図1.aを参照）とマルチホップモビリティ（図1.bを参照）。シングルホップモビリティは、このドキュメントの焦点であり、MIPV6の視点と一致しています[5]。モバイルマルチキャストメンバーシップコントロールの重要な問題とモバイルおよびマルチキャストルーティングの相互作用は、この簡単なシナリオを使用して説明されます。
Multi-hop network mobility is a subsidiary scenario. All major aspects are inherited from the single-hop problem, while additional complexity is incurred from traversing a mobile cloud. This may be solved by either encapsulation or flooding ([8] provides a general overview). Specific issues arising from (nested) tunneling or flooding, especially the preservation of address transparency, require treatment analogous to MIPv6.
マルチホップネットワークモビリティは、子会社のシナリオです。すべての主要な側面はシングルホップの問題から継承されますが、モバイルクラウドの移動から追加の複雑さが発生します。これは、カプセル化または洪水のいずれかによって解決される場合があります（[8]は一般的な概要を提供します）。（ネストされた）トンネルまたは洪水、特に住所の透明性の保存から生じる特定の問題には、MIPV6に類似した治療が必要です。
+------+ +------+
| MN | =====> | MN |
+------+ +------+
| .
| .
| .
+-------+ +-------+
| LAR 1 | | LAR 2 |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
+------+ +------+ * *
| MN | =====> | MN | * Mobile Network *
+------+ +------+ * *
| . * ** ** ** *
| . *** *** *** ***
| . | .
+-------+ +-------+ +-------+ +-------+
| AR 1 | | AR 2 | | AR 1 | =====> | AR 2 |
+-------+ +-------+ +-------+ +-------+
| | | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
a) Single-Hop Mobility b) Multi-Hop Mobility
a) シングルホップモビリティb）マルチホップモビリティ
Figure 1: Mobility Scenarios - A Mobile Node (MN) Directly Attaching to Fixed Access Routers (ARs) or Attached via Local Access Routers (LARs)
図1：モビリティシナリオ - 固定アクセスルーター（ARS）に直接接続するモバイルノード（MN）またはローカルアクセスルーター（LARS）を介して添付
Multicast mobility is a generic term, which subsumes a collection of distinct functions. First, the multicast communication is divided into Any Source Multicast (ASM) [2] and Source-Specific Multicast (SSM) [9][10]. Second, the roles of senders and receivers are distinct and asymmetric. Both may individually be mobile. Their interaction is facilitated by a multicast routing protocol such as the Distance Vector Multicast Routing Protocol (DVMRP) [11], the Protocol Independent Multicast - Sparse Mode / Source-Specific Multicast (PIM-SM/SSM) [12][13], the Bidirectional PIM [14], or the inter-domain multicast prefix advertisements via Multiprotocol Extensions for BGP-4 (MBGP) [15]. IPv6 clients interact using the multicast listener discovery protocol (MLD and MLDv2) [16][17].
マルチキャストモビリティは一般的な用語であり、異なる機能のコレクションを包み込みます。まず、マルチキャスト通信は、ソースマルチキャスト（ASM）[2]およびソース固有のマルチキャスト（SSM）[9] [10]に分割されます。第二に、送信者とレシーバーの役割は明確で非対称です。どちらも個別にモバイルである可能性があります。それらの相互作用は、距離ベクトルマルチキャストルーティングプロトコル（DVMRP）[11]、プロトコル独立マルチキャスト - スパースモード /ソース固有のマルチキャスト（PIM-SM / SSM）[12] [13]などのマルチキャストルーティングプロトコルによって促進されます。双方向PIM [14]、またはBGP-4（MBGP）のマルチプロトコル拡張を介したドメイン間マルチキャストプレフィックス広告[15]。IPv6クライアントは、マルチキャストリスナーディスカバリープロトコル（MLDおよびMLDV2）[16] [17]を使用して対話します。
Any solution for multicast mobility needs to take all of these functional blocks into account. It should enable seamless continuity of multicast sessions when moving from one IPv6 subnet to another. It is desired to preserve the multicast nature of packet distribution and approximate optimal routing. It should support per-flow handover for multicast traffic because the properties and designations of flows can be distinct. Such distinctions may result from differing Quality-of-Service (QoS) / real-time requirements, but may also be caused by network conditions that may differ for different groups.
マルチキャストモビリティのソリューションは、これらの機能ブロックをすべて考慮に入れる必要があります。あるIPv6サブネットから別のIPv6サブネットに移行する際に、マルチキャストセッションのシームレスな連続性を可能にするはずです。パケット分布のマルチキャストの性質と近似最適ルーティングを維持することが望まれます。フローのプロパティと指定は明確である可能性があるため、マルチキャストトラフィックのフローごとの引き渡しをサポートする必要があります。このような違いは、サービス品質の品質（QOS） /リアルタイムの要件が異なることから生じる可能性がありますが、グループごとに異なる可能性のあるネットワーク条件によって引き起こされる場合があります。
The host group model extends the capability of the network-layer unicast service. In common with the architecture of fixed networks, multicast mobility management should transparently utilize or smoothly extend the unicast functions of MIPv6 [5], its security extensions [6][18], its expediting schemes FMIPv6 [19] and Hierarchical Mobile IPv6 Environment (HMIPv6) [20], its context transfer protocols [21], its multihoming capabilities [22][23], emerging protocols like PMIPv6 [62], or future developments. From the perspective of an integrated mobility architecture, it is desirable to avoid multicast-specific as well as unicast-restricted solutions, whenever general approaches can be derived that can jointly support unicast and multicast.
ホストグループモデルは、ネットワーク層ユニキャストサービスの機能を拡張します。固定ネットワークのアーキテクチャと一般的に、マルチキャストモビリティ管理は、MIPv6 [5]のユニキャスト関数[6] [18]、その迅速なスキームFMIPV6 [19]、および階層モバイルIPV6環境を透過的に利用またはスムーズに拡張する必要があります（hmipv6）[20]、そのコンテキスト転送プロトコル[21]、その多発性能力[22] [23]、PMIPv6 [62]のような新興プロトコル、または将来の開発。統合されたモビリティアーキテクチャの観点からは、ユニキャストとマルチキャストを共同でサポートできる一般的なアプローチを導き出すことができる場合はいつでも、マルチキャスト固有およびユニキャスト制限のあるソリューションを避けることが望ましいです。
Multicast routing dynamically adapts to the network topology at the locations of the sender(s) and receiver(s) participating in a multicast session, which then may change under mobility. However, depending on the topology and the protocol in use, current multicast routing protocols may require a time close to seconds to converge following a change in receiver or sender location. This is far too slow to support seamless handovers for interactive or real-time media sessions. The actual temporal behavior strongly depends on the multicast routing protocol in use, the configuration of routers, and on the geometry of the current distribution tree. A mobility scheme that readjusts routing, i.e., partially changes or fully reconstructs a multicast tree, is forced to comply with the time scale for protocol convergence. Specifically, it needs to consider a possible rapid movement of the mobile node, as this may occur at much higher rates than common protocol state updates.
マルチキャストルーティングは、マルチキャストセッションに参加する送信者と受信機の場所でのネットワークトポロジに動的に適応し、モビリティの下で変化する可能性があります。ただし、トポロジと使用中のプロトコルに応じて、現在のマルチキャストルーティングプロトコルは、レシーバーまたは送信者の場所の変更に続いて収束するのに数秒近くの時間が必要になる場合があります。これは、インタラクティブまたはリアルタイムのメディアセッションのシームレスなハンドオーバーをサポートするには非常に遅すぎます。実際の時間的挙動は、使用中のマルチキャストルーティングプロトコル、ルーターの構成、および現在の分布ツリーのジオメトリに大きく依存します。ルーティングを再調整するモビリティスキーム、つまりマルチキャストツリーを部分的に変更または完全に再構築することは、プロトコル収束のための時間スケールに準拠することを余儀なくされます。具体的には、一般的なプロトコル状態の更新よりもはるかに高いレートで発生する可能性があるため、モバイルノードの迅速な動きの可能性を考慮する必要があります。
The mobility of hosts using IP multicast can impact the service presented to the higher-layer protocols. IP-layer multicast packet distribution is an unreliable service that is bound to a connectionless transport service. Where applications are sensitive to packet loss or jitter, countermeasures need to be performed (loss recovery, content recoding, concealment, etc.) by the multicast transport or application. Mobile multicast handovers should not introduce significant additional packet drops. Due to statelessness, the bi-casting of multicast flows does not cause degradations at the transport layer, and applications should implement mechanisms to detect and correctly respond to duplicate datagrams. Nevertheless, individual application programs may not be robust with respect to repeated reception of duplicate streams.
IPマルチキャストを使用したホストのモビリティは、高層プロトコルに提示されたサービスに影響を与える可能性があります。IP層マルチキャストパケット配信は、コネクションレストランスポートサービスに拘束される信頼性の低いサービスです。アプリケーションがパケットの損失またはジッターに敏感な場合、マルチキャストトランスポートまたはアプリケーションにより、対策を実行する必要があります（損失回収、コンテンツの再採算、隠蔽など）。モバイルマルチキャストハンドオーバーは、重要な追加パケットドロップを導入してはなりません。ステートレスのため、マルチキャストフローのバイキャストは輸送層で分解を引き起こすことはなく、アプリケーションはデータグラムの重複を検出して正しく応答するメカニズムを実装する必要があります。それにもかかわらず、個々のアプリケーションプログラムは、重複ストリームの繰り返し受信に関して堅牢ではない場合があります。
IP multicast applications can be designed to adapt the multicast stream to prevailing network conditions (adapting the sending rate to the level of congestion, adaptive tuning of clients in response to measured delay, dynamic suppression of feedback messages, etc.). An adaptive application may also use more than one multicast group (e.g., layered multicast in which a client selects a set of multicast groups based on perceived available network capacity). A mobility handover may temporarily disrupt the operation of these higher-layer functions. The handover can invalidate assumptions about the forwarding path (e.g., acceptable delivery rate, round-trip delay), which could impact an application and level of network traffic. Such effects need to be considered in the design of multicast applications and in the design of network-layer mobility. Specifically, mobility mechanisms need to be robust to transient packet loss that may result from invalid path expectations following a handover of an MN to a different network.
IPマルチキャストアプリケーションは、マルチキャストストリームを一般的なネットワーク条件に適応させるように設計できます（測定された遅延、フィードバックメッセージの動的抑制などに応じて、輻輳のレベル、クライアントの適応チューニングのレベルに送信率を適応させる）。適応型アプリケーションは、複数のマルチキャストグループを使用する場合があります（たとえば、クライアントが知覚された利用可能なネットワーク容量に基づいてマルチキャストグループのセットを選択する階層化されたマルチキャスト）。モビリティハンドオーバーは、これらの高層機能の動作を一時的に混乱させる可能性があります。ハンドオーバーは、転送パス（たとえば、許容可能な配送率、往復遅延など）に関する仮定を無効にする可能性があり、アプリケーションとネットワークトラフィックのレベルに影響を与える可能性があります。このような効果は、マルチキャストアプリケーションの設計とネットワーク層のモビリティの設計で考慮する必要があります。具体的には、モビリティメカニズムは、MNの別のネットワークへの引き渡し後の無効なパス期待に起因する可能性のある一時的なパケット損失に対して堅牢である必要があります。
Group addresses, in general, are location transparent, even though they may be scoped and methods can embed unicast prefixes or Rendezvous Point addresses [24]. The addresses of sources contributing to a multicast session are interpreted by the routing infrastructure and by receiver applications, which frequently are aware of source addresses. Multicast therefore inherits the mobility address duality problem of MIPv6 for source addresses: addresses being a logical node identifier, i.e., the home address (HoA) on the one hand, and a topological locator, the care-of address (CoA), on the other. At the network layer, the elements that comprise the delivery tree, i.e., multicast senders, forwarders, and receivers, need to carefully account for address duality issues, e.g., by using binding caches, extended multicast states, or signaling.
一般に、グループアドレスは、スコープされている可能性があり、メソッドがユニキャストプレフィックスまたはランデブーポイントアドレスを埋め込むことができる場合でも、位置透過性です[24]。マルチキャストセッションに貢献するソースのアドレスは、ルーティングインフラストラクチャとレシーバーアプリケーションによって解釈され、頻繁にソースアドレスを認識しています。したがって、マルチキャストは、ソースアドレスのMIPV6のモビリティアドレスの二重性問題を継承します。アドレスは論理ノード識別子、つまり、一方のホームアドレス（HOA）、およびトポロジカルロケーターであるケアオブアドレス（COA）です。他の。ネットワークレイヤーでは、配信ツリーを構成する要素、つまりマルチキャスト送信者、フォワーダー、レシーバーは、たとえば、拘束力のあるキャッシュ、拡張マルチキャスト状態、またはシグナリングを使用することにより、二重性の問題を慎重に説明する必要があります。
Multicast sources, in general, operate decoupled from their receivers in the following sense: a multicast source sends packets to a group of receivers that are unknown at the network layer and thus operates without a feedback channel. It neither has means to inquire about the properties of its delivery trees, nor the ability to learn about the network-layer state of its receivers. In the event of an inter- tree handover, a mobile multicast source therefore is vulnerable to losing connectivity to receivers without noticing. (Appendix A describes implicit source notification approaches). Applying a MIPv6 mobility binding update or return routability procedure will similarly break the semantic of a receiver group remaining unidentified by the source and thus cannot be applied in unicast analogy.
マルチキャストソースは、一般に、次の意味でレシーバーから切り離された動作を操作します。マルチキャストソースは、ネットワークレイヤーで不明であるため、フィードバックチャネルなしで動作するレシーバーのグループにパケットを送信します。その配達ツリーの特性について問い合わせる手段も、受信機のネットワーク層状態について学ぶ能力もありません。したがって、ツリー間のハンドオーバーが発生した場合、モバイルマルチキャストソースは、気付かずにレシーバーへの接続を失うことに対して脆弱です。（付録Aでは、暗黙のソース通知アプローチについて説明しています）。MIPV6モビリティバインディングアップデートまたはリターンルーティング可能性手順を適用すると、同様にソースによって身元不明のままであるレシーバーグループのセマンティックが破損するため、ユニキャストアナロジーに適用できません。
Despite the complexity of the requirements, multicast mobility management should seek lightweight solutions with easy deployment. Realistic, sample deployment scenarios and architectures should be provided in future solution documents.
要件の複雑さにもかかわらず、マルチキャストモビリティ管理は、簡単に展開して軽量ソリューションを求める必要があります。現実的なサンプル展開シナリオとアーキテクチャは、将来のソリューションドキュメントで提供する必要があります。
A mobile multicast listener entering a new IP subnet requires multicast reception following a handover in real-time. This needs to transfer the multicast membership context from its old to its new point of attachment. This can either be achieved by (re-)establishing a tunnel or by transferring the MLD Listening State information of the MN's moving interface(s) to the new upstream router(s). In the latter case, it may encounter any one of the following conditions:
新しいIPサブネットに入るモバイルマルチキャストリスナーには、リアルタイムでハンドオーバー後にマルチキャストレセプションが必要です。これには、マルチキャストメンバーシップコンテキストを古いものから新しい添付ファイルに転送する必要があります。これは、トンネルを確立するか、MNの移動インターフェイスのMLDリスニング状態情報を新しいアップストリームルーターに転送することによって達成できます。後者の場合、次の条件のいずれかに遭遇する可能性があります。
o In the simplest scenario, packets of some, or all, of the subscribed groups of the mobile node are already received by one or several other group members in the new network, and thus multicast streams natively flow after the MN arrives at the new network.
o 最も単純なシナリオでは、モバイルノードのサブスクライブグループの一部またはすべてのパケットは、新しいネットワークの1つまたは複数のグループメンバーによってすでに受信されているため、MNが新しいネットワークに到着した後、マルチキャストストリームがネイティブに流れます。
o The requested multicast service may be supported and enabled in the visited network, but the multicast groups under subscription may not be forwarded to it, e.g., groups may be scoped or administratively prohibited. This means that current distribution trees for the desired groups may only be re-joined at a (possibly large) routing distance.
o 要求されたマルチキャストサービスは、訪問されたネットワークでサポートおよび有効になる場合がありますが、サブスクリプション中のマルチキャストグループはそれに転送されない場合があります。たとえば、グループはスコープまたは管理上禁止されている場合があります。これは、目的のグループの現在の分布ツリーが（おそらく大きな）ルーティング距離でのみ再生される可能性があることを意味します。
o The new network may not be multicast-enabled or the specific multicast service may be unavailable, e.g., unsupported or prohibited. This means that current distribution trees for the desired groups need to be re-joined at a large routing distance by (re-)establishing a tunnel to a multicast-enabled network node.
o 新しいネットワークはマルチキャスト対応ではない場合があるか、特定のマルチキャストサービスが利用できない場合があります。たとえば、サポートされていないか禁止されています。これは、マルチキャスト対応ネットワークノードへのトンネルを確立することにより、目的のグループの現在の分布ツリーを大きなルーティング距離で再会する必要があることを意味します。
The problem of achieving seamless multicast listener handovers is thus threefold:
したがって、シームレスなマルチキャストリスナーのハンドオーバーを達成する問題は3つあります。
o Ensure multicast reception, even in visited networks, without appropriate multicast support.
o 適切なマルチキャストサポートなしで、訪問されたネットワークでもマルチキャストレセプションを確認してください。
o Minimize multicast forwarding delay to provide seamless and fast handovers for real-time services. Dependent on Layer 2 (L2) and Layer 3 (L3) handover performance, the time available for multicast mobility operations is typically bound by the total handover time left after IPv6 connectivity is regained. In real-time scenarios, this may be significantly less than 100 ms.
o マルチキャスト転送遅延を最小限に抑えるために、リアルタイムサービスにシームレスで高速なハンドオーバーを提供します。レイヤー2（L2）とレイヤー3（L3）のハンドオーバーパフォーマンスに依存します。マルチキャストモビリティ操作に利用できる時間は、通常、IPv6接続が回復した後に残った合計ハンドオーバー時間に拘束されます。リアルタイムシナリオでは、これは100ミリ秒未満になる可能性があります。
o Minimize packet loss and reordering that result from multicast handover management.
o マルチキャストハンドオーバー管理から生じるパケットの損失と並べ替えを最小限に抑えます。
Moreover, in many wireless regimes, it is also desirable to minimize multicast-related signaling to preserve the limited resources of battery-powered mobile devices and the constrained transmission capacities of the networks. This may lead to a desire to restrict MLD queries towards the MN. Multihomed MNs may ensure smooth handoffs by using a "make-before-break" approach, which requires a per-interface subscription, facilitated by an MLD JOIN operating on a pre-selected IPv6 interface.
さらに、多くのワイヤレス体制では、バッテリー駆動のモバイルデバイスの限られたリソースとネットワークの制約された伝送能力を保持するために、マルチキャスト関連のシグナリングを最小限に抑えることも望ましいです。これにより、MLDのクエリをMNに制限したいという欲求につながる可能性があります。マルチホームMNSは、事前に選択されたIPv6インターフェイスで動作するMLD結合によって促進されるインターフェイスごとのサブスクリプションを必要とする「ブレイク前」アプローチを使用することにより、スムーズなハンドオフを確保する場合があります。
Encapsulation on the path between the upstream router and the receiver may result in MTU size conflicts, since path-MTU discovery is often not supported for multicast and can reduce scalability in networks with many different MTU sizes or introduce potential denial-of-service vulnerabilities (since the originating addresses of ICMPv6 messages cannot be verified for multicast). In the absence of fragmentation at tunnel entry points, this may prevent the group from being forwarded to the destination.
Path-MTU発見はマルチキャストではサポートされず、多くの異なるMTUサイズのネットワークのスケーラビリティを低下させたり、潜在的なサービス拒否の脆弱性を導入したりできるため、上流のルーターとレシーバーの間のパスのカプセル化はMTUサイズの競合につながる可能性があります（ICMPV6メッセージの発信アドレスは、マルチキャストでは検証できないため）。トンネルのエントリポイントでの断片化がない場合、これにより、グループが目的地に転送されるのを妨げる可能性があります。
The infrastructure providing multicast services is required to keep traffic following the MN without compromising network functionality. Mobility solutions thus have to face some immediate problems:
マルチキャストサービスを提供するインフラストラクチャは、ネットワーク機能を損なうことなくMNに従ってトラフィックを維持するために必要です。したがって、モビリティソリューションはいくつかの即時の問題に直面する必要があります。
o Realize native multicast forwarding, and where applicable, conserve network resources and utilize link-layer multipoint distribution to avoid data redundancy.
o ネイティブのマルチキャスト転送を実現し、該当する場合は、ネットワークリソースを節約し、リンク層マルチポイントディストリビューションを利用して、データの冗長性を回避します。
o Activate link-multipoint services, even if the MN performs only a L2/vertical handover.
o MNがL2/垂直ハンドオーバーのみを実行しても、Link-MultiPointサービスをアクティブにします。
o Ensure routing convergence, even when the MN moves rapidly and performs handovers at a high frequency.
o MNが迅速に移動し、高頻度で拳オーバーを実行する場合でも、ルーティング収束を確実にします。
o Avoid avalanche problems and stream multiplication (n-casting), which potentially result from replicated tunnel initiation or redundant forwarding at network nodes.
o 雪崩の問題やストリーム乗算（Nキャスト）を避けます。これは、複製されたトンネル開始またはネットワークノードでの冗長転送に起因する可能性があります。
There are additional implications for the infrastructure: In changing its point of attachment, an exclusive mobile receiver may initiate forwarding of a group in the new network and termination of a group distribution service in the previous network. Mobility management may impact multicast routing by, e.g., erroneous subscriptions following predictive handover operations, or slow traffic termination at leaf nodes resulting from MLD query timeouts, or by departure of the MN from a previous network without leaving the subscribed groups. Finally, packet duplication and reordering may follow a change of topology.
インフラストラクチャには追加の意味があります。添付ファイルのポイントを変更する際に、排他的なモバイルレシーバーは、新しいネットワークでグループの転送を開始し、以前のネットワークでグループ配信サービスを終了する場合があります。モビリティ管理は、予測ハンドオーバー操作に続く誤ったサブスクリプション、またはMLDクエリのタイムアウトに起因する葉のノードでのトラフィック終了の遅延、またはサブスクライブされたグループを離れることなく以前のネットワークからのMNの出発により、マルチキャストルーティングに影響を与える可能性があります。最後に、パケットの複製と並べ替えは、トポロジの変化に従う可能性があります。
A node submitting data to an ASM group either forms the root of a source-specific shortest path tree (SPT), distributing data towards a rendezvous point (RP) or receivers, or it forwards data directly down a shared tree, e.g., via encapsulated PIM Register messages, or using bidirectional PIM routing. Native forwarding along source-specific delivery trees will be bound to the source's topological network address, due to reverse path forwarding (RPF) checks. A mobile multicast source moving to a new subnetwork is only able to either inject data into a previously established delivery tree, which may be a rendezvous-point-based shared tree, or to (re-)initiate the construction of a multicast distribution tree for its new network location. In the latter case, the mobile sender will have to proceed without knowing whether the new tree has regained ability to forward traffic to the group, due to the decoupling of sender and receivers.
ASMグループにデータを送信するノードは、ソース固有の最短パスツリー（SPT）のルートを形成し、データをランデブーポイント（RP）または受信機に分配するか、たとえばカプセル化されたカプセル化を介して共有ツリーを直接転送します。PIM登録メッセージ、または双方向PIMルーティングの使用。ソース固有の配信ツリーに沿ったネイティブ転送は、逆パス転送（RPF）チェックにより、ソースのトポロジネットワークアドレスにバインドされます。新しいサブネットワークに移動するモバイルマルチキャストソースは、以前に確立された配信ツリーにデータを注入することができます。その新しいネットワークの場所。後者の場合、モバイル送信者は、送信者と受信機の分離により、新しいツリーがグループにトラフィックを転送する能力を取り戻したかどうかを知らずに進める必要があります。
A mobile multicast source must therefore provide address transparency at two layers: To comply with RPF checks, it has to use an address within the source field of the IPv6 basic header, which is in topological agreement with the employed multicast distribution tree. For application transparency, the logical node identifier, commonly the HoA, must be presented as the packet source address to the transport layer at the receiver side.
したがって、モバイルマルチキャストソースは、2つのレイヤーでアドレスの透明性を提供する必要があります。RPFチェックに準拠するには、IPv6 Basicヘッダーのソースフィールド内のアドレスを使用する必要があります。アプリケーションの透明度のために、一般的にHOAである論理ノード識別子は、受信機側の輸送層へのパケットソースアドレスとして提示する必要があります。
The address transparency and temporal handover constraints pose major problems for route-optimizing mobility solutions. Additional issues arise from possible packet loss and from multicast scoping. A mobile source away from home must respect scoping restrictions that arise from its home and its visited location [5].
アドレスの透明性と時間的ハンドオーバーの制約は、ルートを最適化するモビリティソリューションに大きな問題を引き起こします。追加の問題は、パケット損失の可能性とマルチキャストスコープから発生します。自宅から離れたモバイルソースは、自宅と訪問した場所から生じるスコーピング制限を尊重する必要があります[5]。
Intra-domain multicast routing may allow the use of shared trees that can reduce mobility-related complexity. A static rendezvous point may allow a mobile source to continuously send data to the group by encapsulating packets to the RP with its previous topologically correct or home source address. Intra-domain mobility is transparently provided by bidirectional shared domain-spanning trees, when using bidirectional PIM, eliminating the need for tunneling to the corresponding RP (in contrast to IPv4, IPv6 ASM multicast groups are associated with a specific RP/RPs).
ドメイン内マルチキャストルーティングにより、モビリティ関連の複雑さを軽減できる共有ツリーを使用することができます。静的なランデブーポイントにより、モバイルソースは、以前のトポロジカルな正しいまたはホームソースアドレスを使用してパケットをRPにカプセル化することにより、グループにデータを継続的に送信できる場合があります。ドメイン内移動度は、双方向PIMを使用すると、双方向の共有ドメインにまたがるドメインにまたがるツリーによって透過的に提供され、対応するRPへのトンネリングの必要性が排除されます（IPv4とは対照的に、IPv6 ASMマルチキャストグループは特定のRP/RPに関連しています）。
Issues arise in inter-domain multicast, whenever notification of source addresses is required between distributed instances of shared trees. A new CoA acquired after a mobility handover will necessarily be subject to inter-domain record exchange. In the presence of an embedded rendezvous point address [24], e.g., the primary rendezvous point for inter-domain PIM-SM will be globally appointed, and a newly attached mobile source can contact the RP without prior signaling (like a new source) and transmit data in the PIM register tunnel. Multicast route optimization (e.g., PIM "shortcuts") will require multicast routing protocol operations equivalent to serving a new source.
共有ツリーの分散インスタンスの間にソースアドレスの通知が必要な場合は、ドメイン間マルチキャストで問題が発生します。モビリティハンドオーバー後に取得された新しいCOAは、必然的にドメイン間記録交換の対象となります。埋め込まれたランデブーポイントアドレス[24]の存在下で、例えば、ドメイン間PIM-SMの主要なランデブーポイントがグローバルに任命され、新しく添付されたモバイルソースは、事前のシグナリングなしでRPに連絡することができます（新しいソースのような）PIMレジスタトンネルにデータを送信します。マルチキャストルートの最適化（PIM「ショートカット」など）には、新しいソースの提供に相当するマルチキャストルーティングプロトコル操作が必要です。
Source-Specific Multicast has been designed for multicast senders with static source addresses. The source addresses in a client subscription to an SSM group is directly used to route identification. Any SSM subscriber is thus forced to know the topological address of the contributor to the group it wishes to join. The SSM source identification becomes invalid when the topological source address changes under mobility. Hence, client implementations of SSM source filtering must be MIPv6 aware in the sense that a logical source identifier (HoA) is correctly mapped to its current topological correspondent (CoA).
ソース固有のマルチキャストは、静的なソースアドレスを備えたマルチキャスト送信者向けに設計されています。SSMグループのクライアントサブスクリプションのソースアドレスは、識別をルーティングするために直接使用されます。したがって、SSMサブスクライバーは、参加したいグループへの貢献者のトポロジーアドレスを知ることを余儀なくされます。トポロジーソースアドレスがモビリティの下で変化すると、SSMソースの識別が無効になります。したがって、SSMソースフィルタリングのクライアント実装は、論理ソース識別子（HOA）が現在のトポロジカル特派員（COA）に正しくマッピングされるという意味で、MIPV6を認識する必要があります。
As a consequence, source mobility for SSM requires a conceptual treatment beyond the problem scope of mobile ASM. A listener subscribes to an (S,G) channel membership and routers establish an (S,G)-state shortest path tree rooted at source S; therefore, any change of source addresses under mobility requires state updates at all routers on the upstream path and at all receivers in the group. On source handover, a new SPT needs to be established that will share paths with the previous SPT, e.g., at the receiver side. As the principle of multicast decoupling of a sender from its receivers holds for SSM, the client updates needed for switching trees become a severe burden.
結果として、SSMのソースモビリティには、モバイルASMの問題範囲を超えた概念的な処理が必要です。リスナーは（s、g）チャネルのメンバーシップをサブスクライブし、ルーターはソースSにルート化された（s、g）state最短パスツリーを確立します。したがって、モビリティの下でのソースアドレスの変更には、上流パス上のすべてのルーターとグループ内のすべてのレシーバーでの状態更新が必要です。ソースハンドオーバーでは、以前のSPT、たとえばレシーバー側でパスを共有する新しいSPTを確立する必要があります。受信者からの送信者のマルチキャスト分離の原則がSSMのために保持されるため、ツリーの切り替えに必要なクライアントの更新は深刻な負担になります。
An SSM listener may subscribe to or exclude any specific multicast source and thereby wants to rely on the topological correctness of network operations. The SSM design permits trust in equivalence to the correctness of unicast routing tables. Any SSM mobility solution should preserve this degree of confidence. Binding updates for SSM sources thus should have to prove address correctness in the unicast routing sense, which is equivalent to binding update security with a correspondent node in MIPv6 [5].
SSMリスナーは、特定のマルチキャストソースを購読または除外する場合があり、それにより、ネットワーク操作のトポロジカル正しさに依存したいと考えています。SSM設計により、ユニキャストルーティングテーブルの正確性に等価性を信頼できます。SSMモビリティソリューションは、この程度の信頼性を維持する必要があります。したがって、SSMソースのバインディング更新は、Unicastルーティングの意味での正確性に対処することを証明する必要があります。これは、MIPV6の特派員ノードとの更新セキュリティを結合することと同等です[5]。
The above methods could add significant complexity to a solution for robust SSM mobility, which needs to converge to optimal routes and, for efficiency, is desired to avoid data encapsulation. Like ASM, handover management is a time-critical operation. The routing distance between subsequent points of attachment, the "step size" of the mobile from previous to next designated router, may serve as an appropriate measure of complexity [25][26].
上記の方法は、最適なルートに収束する必要がある堅牢なSSMモビリティのためのソリューションに大きな複雑さを追加する可能性があり、効率のためにデータのカプセル化を避けるために望まれます。ASMと同様に、ハンドオーバー管理は時間的に批判的な操作です。後続のアタッチメントポイント間のルーティング距離、前の指定されたルーターからのモバイルの「ステップサイズ」は、複雑さの適切な尺度として機能する可能性があります[25] [26]。
Finally, Source-Specific Multicast has been designed as a lightweight approach to group communication. In adding mobility management, it is desirable to preserve the leanness of SSM by minimizing additional signaling overhead.
最後に、ソース固有のマルチキャストは、グループコミュニケーションへの軽量アプローチとして設計されています。モビリティ管理を追加する際には、追加のシグナリングオーバーヘッドを最小限に抑えることにより、SSMのlean性を維持することが望ましいです。
IP multicast deployment, in general, has been slow over the past 15 years, even though all major router vendors and operating systems offer implementations that support multicast [27]. While many (walled) domains or enterprise networks operate point-to-multipoint services, IP multicast roll-out is currently limited in public inter-domain scenarios [28]. A dispute arose on the appropriate layer, where group communication service should reside, and the focus of the research community turned towards application-layer multicast. This debate on "efficiency versus deployment complexity" now overlaps the mobile multicast domain [29]. Garyfalos and Almeroth [30] derived from fairly generic principles that when mobility is introduced, the performance gap between IP- and application-layer multicast widens in different metrics up to a factor of four.
一般に、IPマルチキャストの展開は、過去15年間で遅くなりましたが、すべての主要なルーターベンダーとオペレーティングシステムがマルチキャストをサポートする実装を提供しています[27]。多くの（壁に囲まれた）ドメインまたはエンタープライズネットワークはポイントツーマルチポイントサービスを運用していますが、IPマルチキャストロールアウトは現在、公共のドメイン間シナリオで制限されています[28]。グループコミュニケーションサービスが存在する適切なレイヤーで紛争が発生し、研究コミュニティの焦点がアプリケーション層マルチキャストに変わりました。「効率と展開の複雑さ」に関するこの議論は、モバイルマルチキャストドメイン[29]と重複しています。GaryfalosとAlmeroth [30]は、モビリティが導入されると、IPとアプリケーションのマルチキャストのパフォーマンスギャップが異なるメトリックで4倍まで拡大するというかなり一般的な原則に由来しています。
Facing deployment complexity, it is desirable that any solution for mobile multicast does not change the routing protocols. Mobility management in such a deployment-friendly scheme should preferably be handled at edge nodes, preserving a mobility-agnostic routing infrastructure. Future research needs to search for such simple, infrastructure-transparent solutions, even though there are reasonable doubts as to whether this can be achieved in all cases.
展開の複雑さに直面すると、モバイルマルチキャストのソリューションがルーティングプロトコルを変更しないことが望ましいです。このような展開に優しいスキームのモビリティ管理は、エッジノードで処理され、モビリティと依存しないルーティングインフラストラクチャを保存する必要があります。将来の研究では、これがすべての場合に達成できるかどうかについては合理的な疑問があるにもかかわらず、このような単純なインフラストラクチャ透過的なソリューションを検索する必要があります。
Nevertheless, multicast services in mobile environments may soon become indispensable, when multimedia distribution services such as Digital Video Broadcasting for Handhelds (DVB-H) [31][32] or IPTV develop a strong business case for portable IP-based devices. As IP mobility becomes an important service and as efficient link utilization is of a larger impact in costly radio environments, the evolution of multicast protocols will naturally follow mobility constraints.
それにもかかわらず、モバイル環境でのマルチキャストサービスは、ハンドヘルド用のデジタルビデオブロードキャスト（DVB-H）[31] [32]またはIPTVなどのマルチメディア配信サービスまたはポータブルIPベースのデバイスの強力なビジネスケースを開発する場合、すぐに不可欠になる可能性があります。IPモビリティが重要なサービスになり、効率的なリンク利用がコストのかかる無線環境で大きな影響を与えるため、マルチキャストプロトコルの進化は自然にモビリティの制約に従います。
Multicast distribution trees have been studied from a focus of network efficiency. Grounded on empirical observations, Chuang and Sirbu [33] proposed a scaling power-law for the total number of links in a multicast shortest path tree with m receivers (proportional to m^k). The authors consistently identified the scale factor to attain the independent constant k = 0.8. The validity of such universal, heavy-tailed distribution suggests that multicast shortest path trees are of self-similar nature with many nodes of small, but few of higher degrees. Trees consequently would be shaped tall rather than wide.
マルチキャスト分布ツリーは、ネットワーク効率の焦点から研究されています。経験的観察に基づいて、ChuangとSirbu [33]は、M受信機を持つマルチキャスト最短パスツリー（M^Kに比例）のリンクの総数のスケーリングパワーローを提案しました。著者は、独立した定数k = 0.8を達成するためにスケール係数を一貫して特定しました。このような普遍的な尾のある分布の妥当性は、マルチキャストの最短経路ツリーは、多くの小さなノードがありますが、より高い程度のほとんどのノードを持つ自己類似性の性質であることを示唆しています。その結果、木は幅ではなく背が高くなります。
Subsequent empirical and analytical work [34][35] debated the applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. [34] proved that the proposed power law cannot hold for an increasing Internet or very large multicast groups, but is indeed applicable for moderate receiver numbers and the current Internet size of N = 10^5 core nodes. Investigating self-similarity, Janic and Van Mieghem [36] semi-empirically substantiated that multicast shortest path trees in the Internet can be modeled with reasonable accuracy by uniform recursive trees (URTs) [37], provided m remains small compared to N.
その後の経験的および分析的作業[34] [35]は、チュアンとシルブのスケーリング法の適用可能性について議論しました。van Mieghem et al。[34]提案された電力法は、インターネットの増加または非常に大きなマルチキャストグループのために保持できないことを証明しましたが、中程度の受信者数とn = 10^5コアノードの現在のインターネットサイズに実際に適用できます。Janic and Van Mieghem [36]の自己類似性の調査は、インターネット内のマルチキャストの最短パスツリーを、均一な再帰ツリー（URTS）[37]によって合理的な精度でモデル化できることを半強力に実証しました。
The mobility perspective on shortest path trees focuses on their alteration, i.e., the degree of topological changes induced by movement. For receivers, and more interestingly for sources, this may serve as a characteristic measure of the routing complexity. Mobile listeners moving to neighboring networks will only alter tree branches extending over a few hops. Source-specific multicast trees subsequently generated from source handover steps are not independent, but highly correlated. They most likely branch to identical receivers at one or several intersection points. By the self-similar nature, the persistent sub-trees (of previous and next distribution tree), rooted at any such intersection point, exhibit again the scaling law behavior, are tall-shaped with nodes of mainly low degree and thus likely to coincide. Tree alterations under mobility have been studied in [26], both analytically and by simulations. It was found that even in large networks and for moderate receiver numbers more than 80% of the multicast router states remain invariant under a source handover.
最短経路ツリーのモビリティの視点は、その変化、つまり動きによって引き起こされるトポロジー変化の程度に焦点を当てています。受信機の場合、そしてより興味深いことに、これはルーティングの複雑さの特徴的な尺度として機能する可能性があります。隣接するネットワークに移動するモバイルリスナーは、数ホップで伸びるツリーブランチのみを変更します。その後、ソースハンドオーバーステップから生成されたソース固有のマルチキャストツリーは独立していませんが、高度に相関しています。それらは、おそらく1つまたは複数の交差点で同一の受信機に分岐します。自己類似の性質により、そのような交差点に根ざした永続的なサブツリー（前および次の分布ツリーの）は、再びスケーリング法の行動を示し、主に低いノードで背が高いため、一致する可能性があります。モビリティの下での樹木の変化は、[26]で分析的にもシミュレーションも研究されています。大規模なネットワークや中程度の受信機でさえ、マルチキャストルーター状態の80％以上がソースハンドオーバーの下で不変のままであることがわかりました。
Scalable group data distribution has the highest potential in edge networks, where large numbers of end systems reside. Consequently, it is not surprising that most LAN network access technologies natively support point-to-multipoint or multicast services. Wireless access technologies inherently support broadcast/multicast at L2 and operate on a shared medium with limited frequency and bandwidth.
スケーラブルなグループデータ分布は、エッジネットワークで最も高い可能性があり、多数のエンドシステムが存在します。その結果、ほとんどのLANネットワークアクセステクノロジーがポイントツーマルチポイントまたはマルチキャストサービスをネイティブにサポートすることは驚くことではありません。ワイヤレスアクセステクノロジーは、L2での放送/マルチキャストを本質的にサポートし、限られた周波数と帯域幅の共有メディアで動作します。
Several aspects need consideration: First, dissimilar network access radio technologies cause distinct group traffic transmissions. There are:
いくつかの側面には考慮が必要です。まず、異なるネットワークアクセスラジオテクノロジーは、明確なグループトラフィックトランスミッションを引き起こします。がある：
o connection-less link services of a broadcast type, which mostly are bound to limited reliability;
o ほとんどの場合、信頼性が限られているために結合しているブロードキャストタイプの接続のないリンクサービス。
o connection-oriented link services of a point-to-multipoint type, which require more complex control and frequently exhibit reduced efficiency;
o より複雑な制御を必要とするポイントツーマルチポイントタイプの接続指向のリンクサービスは、効率を頻繁に示します。
o connection-oriented link services of a broadcast type, which are restricted to unidirectional data transmission.
o 一方向のデータ送信に制限されているブロードキャストタイプの接続指向リンクサービス。
In addition, multicast may be distributed via multiple point-to-point unicast links without the use of a dedicated multipoint radio channel. A fundamental difference between unicast and group transmission arises from power management. Some radio technologies adjust transmit power to be as small as possible based on link-layer feedback from the receiver, which is not done in multipoint mode. They consequently incur a "multicast tax", making multicast less efficient than unicast unless the number of receivers is larger than some threshold.
さらに、マルチキャストは、専用のマルチポイント無線チャネルを使用せずに、複数のポイントツーポイントユニキャストリンクを介して配布できます。ユニキャストとグループ伝送の根本的な違いは、電力管理から生じます。一部のラジオテクノロジーは、マルチポイントモードでは行われていないレシーバーからのリンク層フィードバックに基づいて、送信電力を可能な限り小さくするように調整します。その結果、「マルチキャスト税」が発生し、受信機の数が何らかのしきい値よりも大きい場合を除き、マルチキャストはユニキャストよりも効率が低くなります。
Second, point-to-multipoint service activation at the network access layer requires a mapping mechanism from network-layer requests. This function is commonly achieved by L3 awareness, i.e., IGMP/MLD snooping [70] or proxy [38], which occasionally is complemented by Multicast VLAN Registration (MVR). MVR allows sharing of a single multicast IEEE 802.1Q Virtual LAN in the network, while subscribers remain in separate VLANs. This L2 separation of multicast and unicast traffic can be employed as a workaround for point-to-point link models to establish a common multicast link.
第二に、ネットワークアクセスレイヤーでのポイントツーマルチポイントサービスのアクティベーションには、ネットワーク層リクエストからのマッピングメカニズムが必要です。この機能は、一般にL3認識、つまりIGMP/MLDスヌーピング[70]またはプロキシ[38]によって達成されます。MVRを使用すると、ネットワーク内の単一のマルチキャストIEEE 802.1Q仮想LANを共有できますが、サブスクライバーは別々のVLANのままです。マルチキャストとユニキャストトラフィックのこのL2分離は、ポイントツーポイントリンクモデルの回避策として使用して、共通のマルチキャストリンクを確立することができます。
Third, an address mapping between the layers is needed for common group identification. Address resolution schemes depend on framing details for the technologies in use, but commonly cause a significant address overlap at the lower layer (i.e., more than one IP multicast group address is sent using the same L2 address).
第三に、レイヤー間のアドレスマッピングが一般的なグループ識別に必要です。アドレス解像度スキームは、使用中のテクノロジーのフレーミングの詳細に依存しますが、一般に下層で重要なアドレスの重複を引き起こします（つまり、同じL2アドレスを使用して複数のIPマルチキャストグループアドレスが送信されます）。
IEEE 802.11 Wireless Local Area Network (WLAN) is a broadcast network of Ethernet type. This inherits multicast address mapping concepts from 802.3. In infrastructure mode, an access point operates as a repeater, only bridging data between the Base (BSS) and the Extended Service Set (ESS). A mobile node submits multicast data to an access point in point-to-point acknowledged unicast mode (when the ToDS bit is set). An access point receiving multicast data from an MN simply repeats multicast frames to the BSS and propagates them to the ESS as unacknowledged broadcast. Multicast frames received from the ESS receive similar treatment.
IEEE 802.11ワイヤレスローカルエリアネットワーク（WLAN）は、イーサネットタイプのブロードキャストネットワークです。これは、802.3のマルチキャストアドレスマッピングの概念を継承します。インフラストラクチャモードでは、アクセスポイントはリピーターとして動作し、ベース（BSS）と拡張サービスセット（ESS）の間でデータを橋渡しするだけです。モバイルノードは、マルチキャストデータをポイントツーポイント認定ユニキャストモードでアクセスポイントに送信します（TODSビットが設定されている場合）。MNからマルチキャストデータを受信するアクセスポイントは、マルチキャストフレームをBSSに繰り返すだけで、承認されていないブロードキャストとしてESSに伝播します。ESSから受け取ったマルチキャストフレームは、同様の治療を受けます。
Multicast frame delivery has the following characteristics:
マルチキャストフレーム配信には、次の特性があります。
o As an unacknowledged service, it offers limited reliability. The loss of frames (and hence packets) arises from interference, collision, or time-varying channel properties.
o 承認されていないサービスとして、それは限られた信頼性を提供します。フレームの損失（したがってパケット）は、干渉、衝突、または時変チャネルプロパティから生じます。
o Data distribution may be delayed, as unicast power saving synchronization via Traffic Indication Messages (TIM) does not operate in multicast mode. Access points buffer multicast packets while waiting for a larger Delivery TIM (DTIM) interval, whenever stations use the power saving mode.
o トラフィック表示メッセージ（TIM）を介したユニキャスト省電力節約の同期はマルチキャストモードで動作しないため、データ分布が遅延する可能性があります。アクセスポイントバッファマルチキャストパケットは、ステーションが電源保存モードを使用するたびに、より大きな配信TIM（DTIM）間隔を待っています。
o Multipoint data may cause congestion, because the distribution system floods multicast, without further control. All access points of the same subnet replicate multicast frames.
o 流通システムはさらに制御せずにマルチキャストをflood濫させるため、マルチポイントデータは混雑を引き起こす可能性があります。同じサブネットのすべてのアクセスポイントが複製マルチキャストフレームを複製します。
To limit or prevent the latter, many vendors have implemented a configurable rate limit for forwarding multicast packets. Additionally, an IGMP/MLD snooping or proxy may be active at the bridging layer between the BSS and the ESS or at switches interconnecting access points.
後者を制限または防止するために、多くのベンダーがマルチキャストパケットを転送するために構成可能なレート制限を実装しています。さらに、IGMP/MLDスヌーピングまたはプロキシは、BSSとESSの間のブリッジングレイヤー、またはアクセスポイントを相互接続するスイッチでアクティブになる場合があります。
IEEE 802.16 Worldwide Interoperability for Microwave Access (WIMAX) combines a family of connection-oriented radio transmission services that can operate in single-hop point-to-multipoint (PMP) or in mesh mode. The latter does not support multipoint transmission and currently has no deployment. PMP operates between Base and Subscriber Stations in distinguished, unidirectional channels. The channel assignment is controlled by the Base Station, which assigns channel IDs (CIDs) within service flows to the Subscriber Stations. Service flows may provide an optional Automatic Repeat Request (ARQ) to improve reliability and may operate in point-to-point or point-to-multipoint (restricted to downlink and without ARQ) mode.
IEEE 802.16マイクロ波アクセス（WIMAX）の世界的な相互運用性は、シングルホップポイントツーマルチポイント（PMP）またはメッシュモードで動作できる接続指向の無線伝送サービスのファミリーを組み合わせています。後者はマルチポイント送信をサポートせず、現在展開していません。PMPは、際立った一方向のチャネルで基地ステーションとサブスクライバーステーションの間で動作します。チャネルの割り当ては、サービスフロー内のチャネルID（CID）をサブスクライバーステーションに割り当てるベースステーションによって制御されます。サービスフローは、信頼性を向上させるオプションの自動リピートリクエスト（ARQ）を提供し、ポイントツーポイントまたはポイントツーマルチポイント（ダウンリンクに制限され、ARQなし）モードで動作する場合があります。
A WIMAX Base Station operates as a full-duplex L2 switch, with switching based on CIDs. Two IPv6 link models for mobile access scenarios exist: A shared IPv6 prefix for IP over Ethernet Circuit Switched (CS) [39] provides Media Access Control (MAC) separation within a shared prefix. A second, point-to-point link model [40] is recommended in the IPv6 Convergence Sublayer [41], which treats each connection to a mobile node as a single link. The point-to-point link model conflicts with a consistent group distribution at the IP layer when using a shared medium (cf. Section 4.1 for MVR as a workaround).
WIMAXベースステーションは、CIDに基づいて切り替えを伴うフルダップレックスL2スイッチとして動作します。モバイルアクセスシナリオ用の2つのIPv6リンクモデルが存在します。イーサネット回路を越えてIPの共有IPv6プレフィックスが切り替えられた（CS）[39]は、共有プレフィックス内でメディアアクセス制御（MAC）分離を提供します。2番目のポイントツーポイントリンクモデル[40]は、IPv6 Convergence Sublayer [41]で推奨されます。これは、モバイルノードへの各接続を単一のリンクとして扱います。ポイントツーポイントリンクモデルは、共有媒体を使用する場合のIPレイヤーでの一貫したグループ分布と競合します（回避策としてMVRのセクション4.1を参照）。
To invoke a multipoint data channel, the base station assigns a common CID to all Subscriber Stations in the group. An IPv6 multicast address mapping to these 16-bit IDs is proposed by copying either the 4 lowest bits, while sustaining the scope field, or by utilizing the 8 lowest bits derived from Multicast on Ethernet CS [42]. For selecting group members, a Base Station may implement IGMP/MLD snooping or proxy as foreseen in 802.16e-2005 [43].
マルチポイントデータチャネルを呼び出すために、ベースステーションはグループ内のすべてのサブスクライバーステーションに共通のCIDを割り当てます。これらの16ビットIDへのIPv6マルチキャストアドレスマッピングは、スコープフィールドを維持しながら4つの最低ビットをコピーするか、イーサネットCSでマルチキャストから派生した8つの最低ビットを利用することにより提案されます[42]。グループメンバーを選択するために、基地局は802.16E-2005で予見されるようにIGMP/MLDスヌーピングまたはプロキシを実装する場合があります[43]。
A Subscriber Station multicasts IP packets to a Base Station as a point-to-point unicast stream. When the IPv6 CS is used, these are forwarded to the upstream access router. The access router (or the Base Station for IP over Ethernet CS) may send downstream multicast packets by feeding them to the multicast service channel. On reception, a Subscriber Station cannot distinguish multicast from unicast streams at the link layer.
サブスクライバーステーションマルチキャストは、ポイントツーポイントユニキャストストリームとしてベースステーションにIPパケットをマルチキャストします。IPv6 CSを使用すると、これらはアップストリームアクセスルーターに転送されます。アクセスルーター（またはイーサネットCSを介したIP用のベースステーション）は、マルチキャストサービスチャネルにフィードすることにより、下流のマルチキャストパケットを送信する場合があります。レセプションでは、サブスクライバーステーションでは、マルチキャストとリンクレイヤーのユニキャストストリームを区別できません。
Multicast services have the following characteristics:
マルチキャストサービスには次の特性があります。
o Multicast CIDs are unidirectional and available only in the downlink direction. Thus, a native broadcast-type forwarding model is not available.
o マルチキャストCIDは一方向であり、ダウンリンク方向でのみ利用可能です。したがって、ネイティブの放送型転送モデルは利用できません。
o The mapping of multicast addresses to CIDs needs standardization, since different entities (Access Router, Base Station) may have to perform the mapping.
o さまざまなエンティティ（アクセスルーター、ベースステーション）がマッピングを実行する必要がある場合があるため、CIDSへのマルチキャストアドレスのマッピングには標準化が必要です。
o CID collisions for different multicast groups may occur due to the short ID space. This can result in several point-to-multipoint groups sharing the same CID, reducing the ability of a receiver to filter unwanted L2 traffic.
o IDスペースが短いため、さまざまなマルチキャストグループのCID衝突が発生する可能性があります。これにより、いくつかのポイントツーマルチポイントグループが同じCIDを共有し、レシーバーが不要なL2トラフィックをフィルタリングする能力を低下させる可能性があります。
o The point-to-point link model for mobile access contradicts a consistent mapping of IP-layer multicast onto 802.16 point-to-multipoint services.
o モバイルアクセスのポイントツーポイントリンクモデルは、802.16ポイントツーマルチポイントサービスへのIPレイヤーマルチキャストの一貫したマッピングと矛盾しています。
o Multipoint channels cannot operate ARQ service and thus experience a reduced reliability.
o マルチポイントチャネルはARQサービスを操作できないため、信頼性が低下します。
The 3rd Generation Partnership Project (3GPP) System architecture spans a circuit switched (CS) and a packet-switched (PS) domain, the latter General Packet Radio Services (GPRS) incorporates the IP Multimedia Subsystem (IMS) [44]. The 3GPP PS is connection-oriented and based on the concept of Packet Data Protocol (PDP) contexts. PDPs define point-to-point links between the Mobile Terminal and the Gateway GPRS Support Node (GGSN). Internet service types are PPP, IPv4, and IPv6, where the recommendation for IPv6 address assignment associates a prefix to each (primary) PDP context [45].
第3世代パートナーシッププロジェクト（3GPP）システムアーキテクチャには、回路が切り替えられた（CS）とパケットスイッチ（PS）ドメインに及び、後者の一般的なパケットラジオサービス（GPRS）にはIPマルチメディアサブシステム（IMS）が組み込まれています[44]。3GPP PSは接続指向であり、パケットデータプロトコル（PDP）コンテキストの概念に基づいています。PDPSは、モバイル端子とゲートウェイGPRSサポートノード（GGSN）の間のポイントツーポイントリンクを定義します。インターネットサービスタイプはPPP、IPv4、およびIPv6であり、IPv6アドレスの割り当ての推奨事項は、各（プライマリ）PDPコンテキスト[45]にプレフィックスを関連付けます。
In Universal Mobile Telecommunications System (UMTS) Rel. 6, the IMS was extended to include Multimedia Broadcast and Multicast Services (MBMS). A point-to-multipoint GPRS connection service is operated on radio links, while the gateway service to Internet multicast is handled at the IGMP/MLD-aware GGSN. Local multicast packet distribution is used within the GPRS IP backbone resulting in the common double encapsulation at GGSN: global IP multicast datagrams over Generic Tunneling Protocol (GTP) (with multipoint TID) over local IP multicast.
Universal Mobile Telecommunications System（UMTS）Rel。6、IMSはマルチメディアブロードキャストおよびマルチキャストサービス（MBMS）を含むように拡張されました。ポイントツーマルチポイントGPRS接続サービスは無線リンクで動作し、インターネットマルチキャストへのゲートウェイサービスはIGMP/MLD-AWARE GGSNで処理されます。ローカルマルチキャストパケット分布は、GPRS IPバックボーン内で使用され、GGSN：Global IP Multicast Datagramsで一般的なダブルカプセル化が汎用トンネルプロトコル（GTP）（Multipoint TIDを使用）上のグローバルIPマルチキャストデータグラムで使用されます。
The 3GPP MBMS has the following characteristics:
3GPP MBMには次の特性があります。
o There is no immediate Layer 2 source-to-destination transition, resulting in transit of all multicast traffic at the GGSN.
o 即時のレイヤー2ソースからドスティーン間遷移はなく、GGSNでのすべてのマルチキャストトラフィックが輸送されます。
o As GGSNs commonly are regional, distant entities, triangular routing and encapsulation may cause a significant degradation of efficiency.
o GGSNは一般的に地域的で遠いエンティティであるため、三角形のルーティング、カプセル化は効率の大幅な分解を引き起こす可能性があります。
In 3GPP2, the MBMS has been extended to the Broadcast and Multicast Service (BCMCS) [46], which on the routing layer operates very similar to MBMS. In both 3GPP and 3GPP2, multicast can be sent using either point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and there is support for switching between PTP and PTM. PTM uses a unidirectional common channel, operating in unacknowledged mode without adjustment of power levels and no reporting on lost packets.
3GPP2では、MBMは放送およびマルチキャストサービス（BCMCS）[46]に拡張されており、ルーティング層ではMBMSと非常によく似ています。3GPPと3GPP2の両方で、マルチキャストはポイントツーポイント（PTP）またはポイントツーマルチポイント（PTM）トンネルのいずれかを使用して送信でき、PTPとPTMを切り替えるサポートがあります。PTMは、電力レベルを調整せずに紛失したパケットの報告なしで、概要モードで動作する単方向の共通チャネルを使用します。
Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional physical layer broadcasting specification for the efficient delivery of broadband and IP-encapsulated data streams, and is published as an ETSI standard [47] (see http://www.dvb-h.org). This uses multiprotocol encapsulation (MPE) to transport IP packets over an MPEG-2 Transport Stream (TS) with link forward error correction (FEC). Each stream is identified by a 13-bit TS ID (PID), which together with a multiplex service ID, is associated with IPv4 or IPv6 addresses [48] and used for selective traffic filtering at receivers. Upstream channels may complement DVB-H using other transmission technologies. The IP Datacast Service, DVB-IPDC [31], specifies a set of applications that can use the DVB-H transmission network.
ハンドヘルド用のデジタルビデオブロードキャスト（DVB-H）は、ブロードバンドおよびIPカプセル化されたデータストリームの効率的な配信のための一方向の物理レイヤーブロードキャスト仕様であり、ETSI標準[47]として公開されています（http：//www.dvb-を参照してください。h.org）。これにより、マルチプロトコルカプセル化（MPE）を使用して、Link Forwardエラー補正（FEC）を備えたMPEG-2トランスポートストリーム（TS）を介してIPパケットを輸送します。各ストリームは、マルチプレックスサービスIDとともにIPv4またはIPv6アドレスに関連付けられており[48]、13ビットTS ID（PID）で識別され、受信機での選択的トラフィックフィルタリングに使用されます。上流チャネルは、他の伝送技術を使用してDVB-Hを補完する場合があります。IP DataCast Service、DVB-IPDC [31]は、DVB-H送信ネットワークを使用できる一連のアプリケーションを指定します。
Multicast distribution services are defined by a mapping of groups onto appropriate PIDs, which is managed at the IP Encapsulator [49]. To increase flexibility and avoid collisions, this address resolution is facilitated by dynamic tables, provided within the self-contained MPEG-2 TS. Mobility is supported in the sense that changes of cell ID, network ID, or Transport Stream ID are foreseen [50]. A multicast receiver thus needs to relocate the multicast services to which it is subscribed during the synchronization phase, and update its service filters. Its handover decision may depend on service availability. An active service subscription (multicast join) requires initiation at the IP Encapsulator / DVB-H Gateway, which cannot be signaled in a pure DVB-H network.
マルチキャスト配信サービスは、IPエンコイプレーター[49]で管理される適切なPIDへのグループのマッピングによって定義されます。柔軟性を高め、衝突を回避するために、このアドレス解像度は、自己完結型のMPEG-2 TS内で提供される動的テーブルによって促進されます。モビリティは、セルID、ネットワークID、または輸送ストリームIDの変更が予見されるという意味でサポートされています[50]。したがって、マルチキャストレシーバーは、同期フェーズ中にサブスクライブするマルチキャストサービスを再配置し、サービスフィルターを更新する必要があります。そのハンドオーバー決定は、サービスの可用性に依存する場合があります。Active Serviceサブスクリプション（マルチキャスト結合）には、IP Encapsurator / DVB-Hゲートウェイで開始が必要です。
IP multicast may be enabled in TV broadcast networks, including those specified by DVB, the Advanced Television Systems Committee (ATSC), and related standards [49]. These standards are also used for one-and two-way satellite IP services. Networks based on the MPEG-2 Transport Stream may support either the multiprotocol encapsulation (MPE) or the unidirectional lightweight encapsulation (ULE) [51]. The second generation DVB standards allow the Transport Stream to be replaced with a Generic Stream, using the Generic Stream Encapsulation (GSE) [52]. These encapsulation formats all support multicast operation.
IPマルチキャストは、DVB、Advanced Television Systems Committee（ATSC）、および関連基準[49]によって指定されたものを含むTV放送ネットワークで有効になる場合があります。これらの標準は、片方および双方向の衛星IPサービスにも使用されます。MPEG-2トランスポートストリームに基づくネットワークは、マルチプロトコルカプセル化（MPE）または単方向の軽量カプセル化（ULE）のいずれかをサポートできます[51]。第2世代のDVB標準により、ジェネリックストリームカプセル化（GSE）[52]を使用して、輸送ストリームを汎用ストリームに置き換えることができます。これらのカプセル化形式はすべて、マルチキャスト操作をサポートしています。
In MPEG-2 transmission networks, multicast distribution services are defined by a mapping of groups onto appropriate PIDs, which is managed at the IP Encapsulator [49]. The addressing issues resemble those for DVB-H (Section 4.2.4) [48]. The issues for using GSE resemble those for ULE (except the PID is not available as a mechanism for filtering traffic). Networks that provide bidirectional connectivity may allow active service subscription (multicast join) to initiate forwarding from the upstream IP Encapsulator / gateway. Some kind of filtering can be achieved using the Input Stream Identifier (ISI) field.
MPEG-2トランスミッションネットワークでは、マルチキャスト配信サービスは、IPエンコイプレーター[49]で管理される適切なPIDへのグループのマッピングによって定義されます。対処する問題は、DVB-Hの問題に似ています（セクション4.2.4）[48]。GSEを使用するための問題は、ULEの問題に似ています（PIDを除き、トラフィックをフィルタリングするメカニズムとして利用できません）。双方向の接続を提供するネットワークは、アクティブなサービスサブスクリプション（マルチキャストJoin）がアップストリームIP Encapsulator / Gatewayから転送を開始できる場合があります。入力ストリーム識別子（ISI）フィールドを使用して、ある種のフィルタリングを実現できます。
A mobile multicast node may change its point of Layer 2 attachment within homogeneous access technologies (horizontal handover) or between heterogeneous links (vertical handover). In either case, a Layer 3 network change may or may not take place, but multicast-aware links always need information about group traffic demands. Consequently, a dedicated context transfer of multicast subscriptions is required at the network access. Such Media Independent Handover (MIH) is addressed in IEEE 802.21 [53], but is relevant also beyond IEEE protocols. Mobility services transport for MIH are required as an abstraction for Layer 2 multicast service transfer in an Internet context [54] and are specified in [55].
モバイルマルチキャストノードは、均一なアクセステクノロジー（水平ハンドオーバー）内または不均一なリンク（垂直ハンドオーバー）内のレイヤー2のアタッチメントのポイントを変更する場合があります。どちらの場合でも、レイヤー3ネットワークの変更が行われる場合と行われない場合がありますが、マルチキャストが認識しているリンクには、グループトラフィックの需要に関する情報が常に必要です。したがって、ネットワークアクセスでは、マルチキャストサブスクリプションの専用コンテキスト転送が必要です。このようなメディア独立したハンドオーバー（MIH）はIEEE 802.21 [53]で対処されていますが、IEEEプロトコルを超えても関連しています。MIHのモビリティサービス輸送は、インターネットのコンテキストでのレイヤー2マルチキャストサービス転送の抽象化として必要であり[54]、[55]で指定されています。
MIH needs to assist in more than service discovery: There is a need for complex, media-dependent multicast adaptation, a possible absence of MLD signaling in L2-only transfers, and requirements originating from predictive handovers. A multicast mobility services transport needs to be sufficiently comprehensive and abstract to initiate a seamless multicast handoff at network access.
MIHは、サービス以上の発見を支援する必要があります。複雑でメディア依存のマルチキャスト適応、L2のみの譲渡でのMLDシグナル伝達の可能性がある可能性があること、予測手順に起因する要件が必要です。マルチキャストモビリティサービストランスポートは、ネットワークアクセスでシームレスなマルチキャストハンドオフを開始するために、十分に包括的かつ抽象的である必要があります。
Functions required for MIH include:
MIHに必要な関数には以下が含まれます。
o Service discovery. o Service context transformation. o Service context transfer. o Service invocation.
o サービスの発見。oサービスコンテキスト変換。サービスコンテキスト転送の。サービスの呼び出しの。
Three approaches to mobile multicast are common [56]:
モバイルマルチキャストへの3つのアプローチが一般的です[56]：
o Bidirectional Tunneling, in which the mobile node tunnels all multicast data via its home agent. This fundamental multicast solution hides all movement and results in static multicast trees. It may be employed transparently by mobile multicast listeners and sources, at the cost of triangular routing and possibly significant performance degradation from widely spanned data tunnels.
o 双方向トンネル。モバイルノードトンネルは、ホームエージェントを介してすべてマルチキャストデータをトンネルします。この基本的なマルチキャストソリューションは、すべての動きを隠し、静的なマルチキャストツリーになります。これは、三角形のルーティングを犠牲にして、広くスパンされたデータトンネルからの大幅なパフォーマンス低下を犠牲にして、モバイルマルチキャストリスナーとソースによって透過的に採用される場合があります。
o Remote Subscription forces the mobile node to re-initiate multicast distribution following handover, e.g., by submitting an MLD listener report to the subnet where a receiver attaches. This approach of tree discontinuation relies on multicast dynamics to adapt to network changes. It not only results in significant service disruption but leads to mobility-driven changes of source addresses, and thus cannot support session persistence under multicast source mobility.
o リモートサブスクリプションは、モバイルノードに、ハンドオーバー後にマルチキャスト分布を再開するように強制します。たとえば、レシーバーが接続されているサブネットにMLDリスナーレポートを送信します。ツリー中止のこのアプローチは、ネットワークの変更に適応するためにマルチキャストダイナミクスに依存しています。それは、大幅なサービスの中断をもたらすだけでなく、ソースアドレスのモビリティ駆動型の変更につながるため、マルチキャストソースモビリティの下でのセッションの持続性をサポートすることはできません。
o Agent-based solutions attempt to balance between the previous two mechanisms. Static agents typically act as local tunneling proxies, allowing for some inter-agent handover when the mobile node moves. A decelerated inter-tree handover, i.e., "tree walking", will be the outcome of agent-based multicast mobility, where some extra effort is needed to sustain session persistence through address transparency of mobile sources.
o エージェントベースのソリューションは、以前の2つのメカニズムのバランスをとろうとします。静的エージェントは通常、ローカルトンネルプロキシとして機能し、モバイルノードが移動するときにエージェント間のハンドオーバーを可能にします。減速されたツリー間のハンドオーバー、つまり「ツリーウォーキング」は、モバイルソースのアドレス透明性を通じてセッションの持続性を維持するためにいくつかの余分な努力が必要なエージェントベースのマルチキャストモビリティの結果となります。
MIPv6 [5] introduces bidirectional tunneling as well as remote subscription as minimal standard solutions. Various publications suggest utilizing remote subscription for listener mobility only, while advising bidirectional tunneling as the solution for source mobility. Such an approach avoids the "tunnel convergence" or "avalanche" problem [56], which refers to the responsibility of the home agent to multiply and encapsulate packets for many receivers of the same group, even if they are located within the same subnetwork. However, this suffers from the drawback that multicast communication roles are not explicitly known at the network layer and may change unexpectedly.
MIPV6 [5]は、最小限の標準ソリューションとして、双方向トンネルとリモートサブスクリプションを導入します。さまざまな出版物が、リスナーモビリティのみにリモートサブスクリプションを利用することを示唆しているが、ソースモビリティのソリューションとして双方向トンネリングをアドバイスすることをお勧めします。このようなアプローチは、「トンネルの収束」または「雪崩」の問題[56]を回避します。これは、同じサブネットワーク内にある場合でも、同じグループの多くの受信機のパケットを乗算してカプセル化するホームエージェントの責任を指します。ただし、これは、マルチキャスト通信の役割がネットワークレイヤーで明示的に知られておらず、予期せずに変化する可能性があるという欠点に苦しんでいます。
None of the above approaches address SSM source mobility, except the use of bidirectional tunneling.
上記のアプローチは、双方向トンネルの使用を除き、SSMソースのモビリティに対処しません。
There are proposals for agent-assisted handover for host-based mobility, which complement the unicast real-time mobility infrastructure of Fast MIPv6 (FMIPv6) [19], the M-FMIPv6 [57][58], and of Hierarchical MIPv6 (HMIPv6) [20], the M-HMIPv6 [59], and to context transfer [60], which have been thoroughly analyzed in [25][61].
ホストベースのモビリティのためのエージェントアシストハンドオーバーの提案があります。これは、高速MIPV6（FMIPV6）[19]、M-FMIPV6 [57] [58]、および階層MIPV6（HMIPV6のユニキャストリアルタイムモビリティインフラストラクチャを補完する提案があります。）[20]、m-hmipv6 [59]、および[25] [61]で徹底的に分析されているコンテキスト伝達[60]へ。
All these solutions presume the context state was stored within a network node that is reachable before and after a move. But there could be cases were the MN is no longer in contact with the previous network, when at the new location. In this case, the network itself cannot assist in the context transfer. Such scenarios may occur when moving from one (walled) operator to another and will require a backwards compatible way to recover from loss of connectivity and context based on the node alone.
これらのソリューションはすべて、コンテキスト状態が移動の前後に到達可能なネットワークノード内に保存されていると推測しています。しかし、MNが新しい場所にいる場合、MNが以前のネットワークと接触しなくなった場合がある場合があります。この場合、ネットワーク自体はコンテキスト転送を支援することはできません。このようなシナリオは、1つの（壁に囲まれた）演算子から別のオペレーターに移動するときに発生する可能性があり、ノードのみに基づいて接続の損失とコンテキストから回復するための後方互換の方法が必要になります。
Network-based mobility management, Proxy MIPv6 (PMIPv6) [62], is multicast transparent in the sense that the MN experiences a point-to-point home link fixed at its (static) Local Mobility Anchor (LMA). This virtual home link is composed of a unicast tunnel between the LMA and the current Mobile Access Gateway (MAG), and a point-to-point link connecting the current MAG to the MN. A PMIPv6 domain thereby inherits MTU-size problems from spanning tunnels at the receiver site. Furthermore, two avalanche problem points can be identified: the LMA may be required to tunnel data to a large number of MAGs, while an MAG may be required to forward the same multicast stream to many MNs via individual point-to-point links [63]. Future optimizations and extensions to shared links preferably adapt native multicast distribution towards the edge network, possibly using a local routing option, including context transfer between access gateways to assist IP-mobility-agnostic MNs.
ネットワークベースのモビリティ管理であるプロキシMIPV6（PMIPV6）[62]は、MNが（静的）ローカルモビリティアンカー（LMA）で固定されたポイントツーポイントホームリンクを経験するという意味でマルチキャスト透明です。この仮想ホームリンクは、LMAと現在のモバイルアクセスゲートウェイ（MAG）の間のユニキャストトンネルと、現在のMAGをMNに接続するポイントツーポイントリンクで構成されています。これにより、PMIPV6ドメインは、受信機サイトでトンネルにまたがるMTUサイズの問題を継承します。さらに、2つの雪崩の問題ポイントを特定できます。LMAは、データを多数の雑誌にトンネルするために必要な場合がありますが、個々のポイントツーポイントリンクを介して同じマルチキャストストリームを多くのMNSに転送するにはMAGが必要になる場合があります[63]。共有リンクへの将来の最適化と拡張機能は、おそらくIPモビリティと存在するMNSを支援するためにアクセスゲートウェイ間のコンテキスト転送を含む、ローカルルーティングオプションを使用して、エッジネットワークにネイティブマルチキャスト分布を適応させることが望ましい。
An approach based on dynamically negotiated inter-agent handovers is presented in [64]. Aside from IETF work, numerous publications present proposals for seamless multicast listener mobility, e.g., [65] provides a comprehensive overview of the work prior to 2004.
動的に交渉されたエージェント間の携帯電話に基づくアプローチは、[64]に示されています。IETFの作業は別として、多数の出版物がシームレスなマルチキャストリスナーモビリティの提案を提示します。たとえば、[65]は、2004年以前の作業の包括的な概要を提供します。
Encapsulation of multicast data packets is an established method to shield mobility and to enable access to remotely located data services, e.g., streams from the home network. Applying generic packet tunneling in IPv6 [66] using a unicast point-to-point method will also allow multicast-agnostic domains to be transited, but does inherit the tunnel convergence problem and may result in traffic multiplication.
マルチキャストデータパケットのカプセル化は、モビリティをシールドし、リモート位置のデータサービス、たとえばホームネットワークからのストリームへのアクセスを可能にするための確立された方法です。ユニキャストポイントツーポイントメソッドを使用してIPv6 [66]に一般的なパケットトンネリングを適用すると、マルチキャストと存在するドメインを通過できますが、トンネル収束問題を継承し、トラフィックの乗算につながる可能性があります。
Multicast-enabled environments may take advantage of point-to-multipoint encapsulation, i.e., generic packet tunneling using an appropriate multicast destination address in the outer header. Such multicast-in-multicast encapsulated packets similarly enable reception of remotely located streams, but do not suffer from the scaling overhead from using unicast tunnels.
マルチキャスト対応環境は、ポイントツーマルチポイントのカプセル化、つまり外側ヘッダーの適切なマルチキャスト宛先アドレスを使用した汎用パケットトンネルを利用する場合があります。このようなマルチキャストインマルチキャストのカプセル化されたパケットは、同様にリモートに位置するストリームを受信できるようにしますが、ユニキャストトンネルの使用によるスケーリングオーバーヘッドに悩まされることはありません。
The tunnel entry point performing encapsulation should provide fragmentation of data packets to avoid issues resulting from MTU-size constraints within the network(s) supporting the tunnel(s).
カプセル化を実行するトンネルエントリポイントは、トンネルをサポートするネットワーク内のMTUサイズの制約に起因する問題を回避するために、データパケットの断片化を提供する必要があります。
There has been recent interest in seeking methods that avoid the complexity at the Internet core network, e.g., application-layer and overlay proposals for (mobile) multicast. The possibility of integrating multicast distribution on the overlay into the network layer is also being considered by the IRTF Scalable Adaptive Multicast (SAM) Research Group.
（モバイル）マルチキャストのアプリケーションレイヤーおよびオーバーレイ提案など、インターネットコアネットワークでの複雑さを回避する方法を求める最近の関心があります。オーバーレイのマルチキャスト分布をネットワークレイヤーに統合する可能性も、IRTFスケーラブルアダプティブマルチキャスト（SAM）研究グループによって考慮されています。
An early hybrid architecture using reactively operating proxy-gateways located at the Internet edges was introduced by Garyfalos and Almeroth [30]. The authors presented an Intelligent Gateway Multicast as a bridge between mobility-aware native multicast management in access networks and mobility group distribution services in the Internet core, which may be operated on the network or application layer. The Hybrid Shared Tree approach [67] introduced a mobility-agnostic multicast backbone on the overlay.
インターネットの端にある反応的に動作するプロキシゲートウェイを使用した初期のハイブリッドアーキテクチャは、ガリファロスとアルメロスによって導入されました[30]。著者は、ネットワークまたはアプリケーションレイヤーで動作する可能性のあるインターネットコアのアクセスネットワークでのモビリティ認識ネイティブマルチキャスト管理とモビリティグループディストリビューションサービスの間のブリッジとしてインテリジェントゲートウェイマルチキャストを提示しました。ハイブリッド共有ツリーアプローチ[67]は、オーバーレイにモビリティに依存しないマルチキャストバックボーンを導入しました。
Current work in the SAM RG is developing general architectural approaches for hybrid multicast solutions [68] and a common multicast API for a transparent access of hybrid multicast [69] that will require a detailed design in future work.
SAM RGの現在の作業は、ハイブリッドマルチキャストソリューションの一般的な建築アプローチ[68]と、将来の作業で詳細なデザインを必要とするハイブリッドマルチキャスト[69]の透明アクセスのための一般的なマルチキャストAPIを開発しています。
The default timer values and Robustness Variable specified in MLD [17] were not designed for the mobility context. This results in a slow reaction of the multicast-routing infrastructure (including L3-aware access devices [70]) following a client leave. This may be a disadvantage for wireless links, where performance may be improved by carefully tuning the Query Interval and other variables. Some vendors have optimized performance by implementing a listener node table at the access router that can eliminate the need for query timeouts when receiving leave messages (explicit receiver tracking).
MLD [17]で指定されたデフォルトのタイマー値と堅牢性変数は、モビリティコンテキスト用に設計されていません。これにより、クライアントの休暇後にマルチキャストルーティングインフラストラクチャ（L3-アウェアアクセスデバイス[70]を含む）の反応が遅くなります。これは、クエリ間隔やその他の変数を慎重に調整することでパフォーマンスが向上する可能性があるワイヤレスリンクの欠点になる可能性があります。一部のベンダーは、アクセスルーターにリスナーノードテーブルを実装することにより、パフォーマンスを最適化しました。
An MN operating predictive handover, e.g., using FMIPv6, may accelerate multicast service termination when leaving the previous network by submitting an early Done message before handoff. MLD router querying will allow the multicast forwarding state to be restored in the case of an erroneous prediction (i.e., an anticipated move to a network that has not taken place). Backward context transfer may otherwise ensure a leave is signaled. A further optimization was introduced by Jelger and Noel [71] for the special case when the HA is a multicast router. A Done message received through a tunnel from the mobile end node (through a point-to-point link directly connecting the MN, in general), should not initiate standard MLD membership queries (with a subsequent timeout). Such explicit treatment of point-to-point links will reduce traffic and accelerate the control protocol. Explicit tracking will cause identical protocol behavior.
FMIPv6を使用するMNの動作予測的ハンドオーバーは、ハンドオフの前に早期に完了したメッセージを送信することにより、前のネットワークを離れるときにマルチキャストサービス終了を加速する場合があります。MLDルータークエリにより、誤った予測の場合（つまり、行われていないネットワークへの予想される移動）、マルチキャスト転送状態を復元できます。それ以外の場合は、後方コンテキストの転送は、休暇が信号を送ることを保証する場合があります。HAがマルチキャストルーターである特別なケースのために、Jelger and Noel [71]によってさらなる最適化が導入されました。モバイルエンドノードからトンネルを介して受信されたメッセージは（一般的にMNを直接接続するポイントツーポイントリンクを介して）、標準のMLDメンバーシップクエリを開始してはなりません（後続のタイムアウトで）。ポイントツーポイントリンクのこのような明示的な処理は、トラフィックを削減し、制御プロトコルを加速します。明示的な追跡により、同一のプロトコル挙動が発生します。
While away from home, an MN may wish to rely on a proxy or "standby" multicast membership service, optionally provided by an HA or proxy router. Such functions rely on the ability to restart fast packet forwarding; it may be desirable for the proxy router to remain part of the multicast delivery tree, even when transmission of group data is paused. To enable such proxy control, the authors in [71] propose an extension to MLD, introducing a Listener Hold message that is exchanged between the MN and the HA. This idea was developed in [59] to propose multicast router attendance control, allowing for a general deployment of group membership proxies. Some currently deployed IPTV solutions use such a mechanism in combination with a recent (video) frame buffer, to enable fast channel switching between several IPTV multicast flows (zapping).
自宅から離れている間、MNは、オプションでHAまたはプロキシルーターによって提供されるプロキシまたは「スタンバイ」マルチキャストメンバーシップサービスに依存したい場合があります。このような機能は、高速パケット転送を再開する機能に依存しています。グループデータの送信が一時停止した場合でも、プロキシルーターがマルチキャスト配信ツリーの一部であることが望ましい場合があります。このようなプロキシ制御を有効にするために、[71]の著者はMLDへの拡張を提案し、MNとHAの間で交換されるリスナーホールドメッセージを導入します。このアイデアは[59]で開発され、マルチキャストルーターの出席制御を提案し、グループメンバーシッププロキシの一般的な展開を可能にしました。現在展開されているIPTVソリューションの中には、最近の（ビデオ）フレームバッファーと組み合わせてこのようなメカニズムを使用して、いくつかのIPTVマルチキャストフロー（Zapping）間の高速チャネルスイッチングを可能にする一部の一部のIPTVソリューションを使用しています。
Solutions for multicast source mobility can be divided into three categories:
マルチキャストソースモビリティのソリューションは、3つのカテゴリに分類できます。
o Statically Rooted Distribution Trees. These methods follow a shared tree approach. Romdhani et al. [72] proposed employing the Rendezvous Points of PIM-SM as mobility anchors. Mobile senders tunnel their data to these "Mobility-aware Rendezvous Points" (MRPs). When restricted to a single domain, this scheme is equivalent to bidirectional tunneling. Focusing on inter-domain mobile multicast, the authors designed a tunnel- or SSM-based backbone distribution of packets between MRPs.
o 静的にルート化された分布ツリー。これらの方法は、共有ツリーアプローチに従います。Romdhani et al。[72]は、PIM-SMのランデブーポイントをモビリティアンカーとして使用することを提案しました。モバイル送信者は、これらの「モビリティ認識ランデブーポイント」（MRPS）にデータをトンネルします。単一のドメインに制限されている場合、このスキームは双方向トンネルと同等です。ドメイン間モバイルマルチキャストに焦点を当てた著者は、MRP間のパケットのトンネルまたはSSMベースのバックボーン分布を設計しました。
o Reconstruction of Distribution Trees. Several authors have proposed the construction of a completely new distribution tree after the movement of a mobile source and therefore have to compensate for the additional routing (tree-building) delay. M-HMIPv6 [59] tunnels data into a previously established tree rooted at mobility anchor points to compensate for the routing delay until a protocol-dependent timer expires. The Range-Based Mobile Multicast (RBMoM) protocol [73] introduces an additional Multicast Agent (MA) that advertises its service range. A mobile source registers with the closest MA and tunnels data through it. When moving out of the previous service range, it will perform MA discovery, a re-registration and continue data tunneling with a newly established Multicast Agent in its new current vicinity.
o 分布ツリーの再構築。数人の著者は、モバイルソースの移動後に完全に新しい分布ツリーの構築を提案しているため、追加のルーティング（ツリービルディング）の遅延を補償する必要があります。M-HMIPv6 [59]トンネルデータは、モビリティアンカーポイントにルート化された以前に確立されたツリーにデータを入れて、プロトコル依存のタイマーが期限切れになるまでルーティング遅延を補正します。レンジベースのモバイルマルチキャスト（RBMOM）プロトコル[73]は、サービス範囲を宣伝する追加のマルチキャストエージェント（MA）を導入します。モバイルソースは、最も近いMAおよびトンネルデータを介して登録します。以前のサービス範囲から移動すると、MAディスカバリー、再登録を実行し、新しい現在の近隣に新しく確立されたマルチキャストエージェントとのデータトンネルを継続します。
o Tree Modification Schemes. In the case of DVMRP routing, Chang and Yen [74] propose an algorithm to extend the root of a given delivery tree for incorporating a new source location in ASM. The authors rely on a complex additional signaling protocol to fix DVMRP forwarding states and heal failures in the reverse path forwarding (RPF) checks.
o ツリー変更スキーム。DVMRPルーティングの場合、Chang and Yen [74]は、ASMに新しいソースの場所を組み込むために特定の配信ツリーのルートを拡張するアルゴリズムを提案します。著者は、DVMRP転送状態を修正し、逆パス転送（RPF）チェックで障害を癒すために、複雑な追加シグナル伝達プロトコルに依存しています。
The shared tree approach of [72] has been extended to support SSM mobility by introducing the HoA address record to the Mobility-aware Rendezvous Points. The MRPs operate using extended multicast routing tables that simultaneously hold the HoA and CoA and thus can logically identify the appropriate distribution tree. Mobility thus may reintroduce the concept of rendezvous points to SSM routing.
[72]の共有ツリーアプローチは、HOAアドレス記録をモビリティ対応のランデブーポイントに導入することにより、SSMモビリティをサポートするために拡張されました。MRPは、HOAとCOAを同時に保持するため、適切な分布ツリーを論理的に識別できる拡張マルチキャストルーティングテーブルを使用して動作します。したがって、モビリティは、SSMルーティングにランデブーポイントの概念を再導入する可能性があります。
Approaches for reconstructing SPTs in SSM rely on a client notification to establish new router state. They also need to preserve address transparency for the client. Thaler [75] proposed introducing a binding cache and providing source address transparency analogous to MIPv6 unicast communication. Initial session announcements and changes of source addresses are distributed periodically to clients via an additional multicast control tree rooted at the home agent. Source tree handovers are then activated on listener requests.
SSMのSPTを再構築するためのアプローチは、クライアント通知に依存して新しいルーター状態を確立します。また、クライアントのアドレス透明性を保持する必要があります。Thaler [75]は、結合キャッシュの導入と、MIPV6ユニキャスト通信に類似したソースアドレスの透明性を提供することを提案しました。最初のセッションの発表とソースアドレスの変更は、ホームエージェントに根付いた追加のマルチキャスト制御ツリーを介してクライアントに定期的に配布されます。ソースツリーハンドオーバーは、リスナーリクエストでアクティブになります。
Jelger and Noel [76] suggest handover improvements employing anchor points within the source network, supporting continuous data reception during client-initiated handovers. Client updates are triggered out of band, e.g., by Source Demand Routing (SDR) / Session Announcement Protocol (SAP) [77]. Receiver-oriented tree construction in SSM thus remains unsynchronized with source handovers.
Jelger and Noel [76]は、ソースネットワーク内のアンカーポイントを使用するハンドオーバーの改善を提案し、クライアントが開始したハンドオーバー中の継続的なデータ受信をサポートします。クライアントの更新は、たとえば、ソースデマンドルーティング（SDR） /セッションアナウンスプロトコル（SAP）[77]により、バンドからトリガーされます。したがって、SSMのレシーバー指向のツリー構造は、ソースハンドオーバーとともに異常化されていません。
To address the synchronization problem at the routing layer, several proposals have focused on direct modification of the distribution trees. A recursive scheme may use loose unicast source routes with branch points, based on a multicast Hop-by-Hop protocol. Vida et al. [78] optimized SPT for a moving source on the path between the source and first branching point. O'Neill [79] suggested a scheme to overcome RPF check failures that originate from multicast source address changes with a rendezvous point scenario by introducing extended routing information, which accompanies data in a Hop-by-Hop option "RPF redirect" header. The Tree Morphing approach of Schmidt and Waehlisch [80] used source routing to extend the root of a previously established SPT, thereby injecting router state updates in a Hop-by-Hop option header. Using extended RPF checks, the elongated tree autonomously initiates shortcuts and smoothly reduces to a new SPT rooted at the relocated source. An enhanced version of this protocol abandoned the initial source routing and could be proved to comply with rapid source movement [81]. Lee et al. [82] introduced a state-update mechanism for reusing major parts of established multicast trees. The authors start from an initially established distribution state, centered at the mobile source's home agent. A mobile source leaving its home network will signal a multicast forwarding state update on the path to its home agent and, subsequently, distribution states according to the mobile source's new CoA along the previous distribution tree. Multicast data is then intended to flow natively using triangular routes via the elongation and an updated tree centered on the home agent. Based on Host Identity Protocol identifiers, Kovacshazi and Vida [83] introduce multicast routing states that remain independent of IP addresses. Drawing upon a similar scaling law argument, parts of these states may then be reused after source address changes.
ルーティング層での同期問題に対処するために、いくつかの提案は、分布ツリーの直接的な変更に焦点を当てています。再帰スキームは、マルチキャストホップバイホッププロトコルに基づいて、ブランチポイントを備えた緩いユニキャストソースルートを使用する場合があります。Vida et al。[78]ソースと最初の分岐点の間のパス上の移動ソースのSPTを最適化しました。O'Neill [79]は、ホップバイホップオプション「RPFリダイレクト」ヘッダーにデータを添付する拡張ルーティング情報を導入することにより、ランデブーポイントシナリオでマルチキャストソースアドレスの変更に起因するRPFチェック障害を克服するスキームを提案しました。SchmidtとWaehlisch [80]のツリーモーフィングアプローチは、ソースルーティングを使用して以前に確立されたSPTのルートを拡張し、それによりホップバイホップオプションヘッダーにルーター状態の更新を注入しました。拡張されたRPFチェックを使用して、細長いツリーは自律的にショートカットを開始し、再配置されたソースにルート化された新しいSPTにスムーズに減少します。このプロトコルの拡張バージョンは、初期のソースルーティングを放棄し、迅速なソースの動きに準拠することが証明される可能性があります[81]。Lee et al。[82]は、確立されたマルチキャストツリーの主要な部分を再利用するための状態増加メカニズムを導入しました。著者は、モバイルソースのホームエージェントを中心とした、最初に確立された流通状態から始まります。ホームネットワークを離れるモバイルソースは、ホームエージェントへのパスに関するマルチキャスト転送状態の更新を示し、その後、以前の配信ツリーに沿ったモバイルソースの新しいCOAに従って配布状態を示します。マルチキャストデータは、伸びを介して三角形のルートを使用して、ホームエージェントを中心とした更新されたツリーを使用してネイティブに流れることを目的としています。ホストIDプロトコル識別子に基づいて、KovacshaziとVida [83]は、IPアドレスから独立したままのマルチキャストルーティング状態を導入します。同様のスケーリング法の議論に基づいて、これらの状態の一部は、ソースアドレスの変更後に再利用される場合があります。
This document discusses multicast extensions to mobility. It does not define new methods or procedures. Security issues arise from source address binding updates, specifically in the case of source-specific multicast. Threats of hijacking unicast sessions will result from any solution jointly operating binding updates for unicast and multicast sessions.
このドキュメントでは、モビリティへのマルチキャスト拡張機能について説明します。新しい方法や手順を定義しません。セキュリティの問題は、特にソース固有のマルチキャストの場合、ソースアドレスのバインディングの更新から発生します。ユニキャストセッションのハイジャックの脅威は、ユニキャストおよびマルチキャストセッションのためのバインディングアップデートを共同で操作するソリューションから生じます。
Multicast protocols exhibit a risk of network-based traffic amplification. For example, an attacker may abuse mobility signaling to inject unwanted traffic into a previously established multicast distribution infrastructure. These threats are partially mitigated by reverse path forwarding checks by multicast routers. However, a multicast or mobility agent that explicitly replicates multicast streams, e.g., Home Agent that n-casts data, may be vulnerable to denial-of-service attacks. In addition to source authentication, a rate control of the replicator may be required to protect the agent and the downstream network.
マルチキャストプロトコルは、ネットワークベースのトラフィック増幅のリスクを示します。たとえば、攻撃者はモビリティシグナルを悪用して、以前に確立されたマルチキャスト分布インフラストラクチャに不要なトラフィックを注入する場合があります。これらの脅威は、マルチキャストルーターによる逆パス転送チェックによって部分的に軽減されます。ただし、マルチキャストのストリームを明示的に複製するマルチキャストまたはモビリティエージェント（たとえば、N-Castsデータがサービス拒否攻撃に対して脆弱なホームエージェント）。ソース認証に加えて、エージェントとダウンストリームネットワークを保護するために、レプリケーターのレート制御が必要になる場合があります。
Mobility protocols need to consider the implications and requirements for Authentication, Authorization, and Accounting (AAA). An MN may have been authorized to receive a specific multicast group when using one mobile network, but this may not be valid when attaching to a different network. In general, the AAA association for an MN may change between attachments, or may be individually chosen prior to network (re-)association. The most appropriate network path may be one that satisfies user preferences, e.g., to use/avoid a specific network, minimize monetary cost, etc., rather than one that only minimizes the routing cost. Consequently, AAA bindings may need to be considered when performing context transfer.
モビリティプロトコルは、認証、承認、会計（AAA）の影響と要件を考慮する必要があります。MNは、1つのモバイルネットワークを使用するときに特定のマルチキャストグループを受信することを許可されている可能性がありますが、これは別のネットワークに接続する場合は有効ではない場合があります。一般に、MNのAAA協会は添付ファイル間で変化する可能性があるか、ネットワーク（RE）関連の前に個別に選択される場合があります。最も適切なネットワークパスは、ルーティングコストを最小限に抑えるだけでなく、特定のネットワークを使用/回避したり、金銭的なコストを最小限に抑えたりすることなど、ユーザーの好みを満たすものです。したがって、コンテキスト転送を実行するときは、AAAバインディングを考慮する必要がある場合があります。
Admission control issues may arise when new CoA source addresses are introduced to SSM channels [84]. Due to lack of feedback, the admission [85] and binding updates [86] of mobile multicast sources require autonomously verifiable authentication. This can be achieved by, for instance, Cryptographically Generated Addresses (CGAs).
新しいCOAソースアドレスがSSMチャネルに導入されると、入場制御の問題が発生する可能性があります[84]。フィードバックが不足しているため、モバイルマルチキャストソースの入場[85]とバインディングの更新[86]は、自律的に検証可能な認証を必要とします。これは、たとえば、暗号化されたアドレス（CGA）によって実現できます。
Modification to IETF protocols (e.g., routing, membership, session announcement, and control) as well as the introduction of new entities, e.g., multicast mobility agents, can introduce security vulnerabilities and require consideration of issues such as authentication of network entities, methods to mitigate denial of service (in terms of unwanted network traffic, unnecessary consumption of router/host resources and router/host state/buffers). Future solutions must therefore analyze and address the security implications of supporting mobile multicast.
IETFプロトコルの変更（例：ルーティング、メンバーシップ、セッションの発表、および制御）および新しいエンティティの導入、例えばマルチキャストモビリティエージェントは、セキュリティの脆弱性を導入し、ネットワークエンティティの認証、メソッドの認証などの問題を考慮する必要があります。サービスの拒否（不要なネットワークトラフィック、ルーター/ホストリソースの不必要な消費、ルーター/ホスト状態/バッファの観点から）を緩和します。したがって、将来のソリューションは、モバイルマルチキャストをサポートすることのセキュリティへの影響を分析し、対処する必要があります。
This document is intended to provide a basis for the future design of mobile IPv6 multicast methods and protocols by:
このドキュメントは、次のようなモバイルIPv6マルチキャストメソッドとプロトコルの将来の設計の基礎を提供することを目的としています。
o providing a structured overview of the problem space that multicast and mobility jointly generate at the IPv6 layer;
o IPv6レイヤーでマルチキャストとモビリティが共同で生成する問題空間の構造化された概要を提供します。
o referencing the implications and constraints arising from lower and upper layers and from deployment;
o 下層と上層と展開から生じる意味と制約を参照します。
o briefly surveying conceptual ideas of currently available solutions;
o 現在利用可能なソリューションの概念的なアイデアを簡単に調査します。
o including a comprehensive bibliographic reference base.
o 包括的な書誌参照ベースを含む。
It is recommended that future steps towards extending mobility services to multicast proceed to first solve the following problems:
モビリティサービスをマルチキャストに拡張するための将来のステップが最初に次の問題を解決することをお勧めします。
1. Ensure seamless multicast reception during handovers, meeting the requirements of mobile IPv6 nodes and networks. Thereby addressing the problems of home subscription without n-tunnels, as well as native multicast reception in those visited networks, which offer a group communication service.
1. ハンドオーバー中にシームレスなマルチキャストレセプションを確保し、モバイルIPv6ノードとネットワークの要件を満たします。これにより、N-Tunnelsのないホームサブスクリプションの問題に対処し、グループ通信サービスを提供する訪問したネットワークのネイティブマルチキャストレセプションに対処します。
2. Integrate multicast listener support into unicast mobility management schemes and architectural entities to define a consistent mobility service architecture, providing equal support for unicast and multicast communication.
2. マルチキャストリスナーのサポートをユニキャストモビリティ管理スキームとアーキテクチャエンティティに統合して、一貫したモビリティサービスアーキテクチャを定義し、ユニキャストおよびマルチキャスト通信を平等にサポートします。
3. Provide basic multicast source mobility by designing address duality management at end nodes.
3. エンドノードでアドレスの二元性管理を設計することにより、基本的なマルチキャストソースモビリティを提供します。
An IP multicast source transmits data to a group of receivers without requiring any explicit feedback from the group. Sources therefore are unaware at the network layer of whether any receivers have subscribed to the group, and unconditionally send multicast packets that propagate in the network to the first-hop router (often known in PIM as the designated router). There have been attempts to implicitly obtain information about the listening group members, e.g., extending an IGMP/MLD querier to inform the source of the existence of subscribed receivers. Multicast Source Notification of Interest Protocol (MSNIP) [87] was such a suggested method that allowed a multicast source to query the upstream designated router. However, this work did not progress within the IETF mboned working group and was terminated by the IETF.
IPマルチキャストソースは、グループからの明示的なフィードバックを必要とせずに、データを受信機のグループに送信します。したがって、ソースは、受信機がグループに購読しているかどうかのネットワークレイヤーでは気づきません。また、ネットワーク内で伝播するマルチキャストパケットを無条件に送信します。リスニンググループメンバーに関する情報を暗黙的に取得する試みがありました。たとえば、IGMP/MLDクエリエを拡張して、購読した受信機の存在の原因を通知します。関心プロトコル（MSNIP）[87]のマルチキャストソース通知は、マルチキャストソースが上流に指定されたルーターを照会できるようにするための提案された方法でした。ただし、この作業はIETF MBONEDワーキンググループ内で進行せず、IETFによって終了しました。
Multicast sources may also be controlled at the session or transport layer using end-to-end control protocols. A majority of real-time applications employ the Real-time Transport Protocol (RTP) [88]. The accompanying control protocol, RTP Control Protocol (RTCP), allows receivers to report information about multicast group membership and associated performance data. In multicast, the RTCP reports are submitted to the same group and thus may be monitored by the source to monitor, manage and control multicast group operations. RFC 2326, the Real Time Streaming Protocol (RTSP), provides session layer control that may be used to control a multicast source. However, RTCP and RTSP information is intended for end-to-end control and is not necessarily visible at the network layer. Application designers may chose to implement any appropriate control plane for their multicast applications (e.g., reliable multicast transport protocols), and therefore a network-layer mobility mechanism must not assume the presence of a specific transport or session protocol.
マルチキャストソースは、エンドツーエンド制御プロトコルを使用して、セッションまたは輸送層でも制御できます。リアルタイムアプリケーションの大部分は、リアルタイムトランスポートプロトコル（RTP）を採用しています[88]。付随するコントロールプロトコルであるRTPコントロールプロトコル（RTCP）により、レシーバーはマルチキャストグループメンバーシップと関連するパフォーマンスデータに関する情報を報告できます。マルチキャストでは、RTCPレポートが同じグループに提出されるため、ソースによって監視されて、マルチキャストグループの操作を監視、管理、制御できます。RFC 2326、リアルタイムストリーミングプロトコル（RTSP）は、マルチキャストソースを制御するために使用できるセッションレイヤー制御を提供します。ただし、RTCPおよびRTSP情報はエンドツーエンド制御を目的としており、ネットワークレイヤーで必ずしも表示されないわけではありません。アプリケーション設計者は、マルチキャストアプリケーション（たとえば、信頼性の高いマルチキャストトランスポートプロトコルなど）に適切な制御プレーンを実装することを選択できます。したがって、ネットワーク層のモビリティメカニズムは、特定のトランスポートまたはセッションプロトコルの存在を想定してはなりません。
Informative References
参考引用
[1] Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, ACM Press, June, 1984.
[1] Aguilar、L。「インターネットマルチキャストのデータグラムルーティング」、ACM SigComm '84 Communications Architectures and Protocols、pp。58-63、ACM Press、1984年6月。
[2] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[2] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[3] G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", IEEE Communications Magazine, 35(1), pp. 54-58, January 1997.
[3] G. XylomenosおよびG.C.Plyzos、「モバイルホスト用のIPマルチキャスト」、IEEE Communications Magazine、35（1）、pp。54-58、1997年1月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[6] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[6] Devarapalli、V。およびF. Dupont、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」、RFC 4877、2007年4月。
[7] ITU-T Recommendation, "G.114 - One-way transmission time", Telecommunication Union Standardization Sector, 05/2003.
[7] ITU-Tの推奨、「G.114-一方向伝送時間」、電気通信ユニオン標準化セクター、2003年5月。
[8] Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.
[8] Akyildiz、I and Wang、X。、「ワイヤレスメッシュネットワークに関する調査」、IEEE Communications Magazine、43（9）、pp。23-30、2005年9月。
[9] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[9] Bhattacharyya、S.、ed。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[10] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[10] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[11] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[11] Waitzman、D.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[12] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[12] Estrin、D.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P.、およびL. Wei、「プロトコル独立したマルチキャスト - スパースモード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[13] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[13] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[14] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[14] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[15] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[15] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[16] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[17] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[17] Vida、R.、ed。、およびL. Costa、ed。、「Multicastリスナーディスカバリーバージョン2（MLDV2）のIPv6」、RFC 3810、2004年6月。
[18] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[18] Arkko、J.、Vogt、C。、およびW. Haddad、「モバイルIPv6の強化されたルート最適化」、RFC 4866、2007年5月。
[19] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[19] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、RFC 5568、2009年7月。
[20] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[20] Soliman、H.、Castelluccia、C.、Elmalki、K。、およびL. Bellier、「Hierarchical Mobile IPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[21] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[21] Loughney、J.、Ed。、Nakhjiri、M.、Perkins、C。、およびR. Koodli、「Context Transfer Protocol（CXTP）」、RFC 4067、2005年7月。
[22] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
[22] N.、N.、Wakikawa、R.、Ernst、T.、Ng、C。、およびK. Kuladinithi、「モバイルIPv6におけるマルチホミングの分析」、2008年5月の進行中。
[23] Narayanan, V., Thaler, D., Bagnulo, M., and H. Soliman, "IP Mobility and Multi-homing Interactions and Architectural Considerations", Work in Progress, July 2007.
[23] Narayanan、V.、Thaler、D.、Bagnulo、M。、およびH. Soliman、「IPモビリティとマルチホーミングの相互作用と建築上の考慮事項」、2007年7月の作業。
[24] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[24] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスにランデブーポイント（RP）アドレスを埋め込む」、RFC 3956、2004年11月。
[25] Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 142, November 2005.
[25] シュミット、T.C。and Waehlisch、M。
[26] Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On the Evolution of Multicast States under Mobility and an Adaptive Routing Scheme for Mobile SSM Sources", Telecommunication Systems, 33(1-3), pp. 131-154, December 2006.
[26] シュミット、T.C。waehlisch、M。
[27] Diot, C. et al. "Deployment Issues for the IP Multicast Service and Architecture", IEEE Network Magazine, spec. issue on Multicasting, 14(1), pp. 78-88, 2000.
[27] Diot、C。etal。「IPマルチキャストサービスとアーキテクチャの展開の問題」、IEEE Network Magazine、Spec。マルチキャストに関する問題、14（1）、pp。78-88、2000。
[28] Eubanks, M. http://multicasttech.com/status/, 2008.
[28] Eubanks、M。http://multicasttech.com/status/、2008年。
[29] Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment Complexity Versus Performance Efficiency in Mobile Multicast", Intern. Workshop on Broadband Wireless Multimedia: Algorithms, Architectures and Applications (BroadWiM), San Jose, California, USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM-04.pdf.
[29] Garyfalos、A、Almeroth、K。、およびSanzgiri、K。ブロードバンドワイヤレスマルチメディアに関するワークショップ：アルゴリズム、アーキテクチャ、アプリケーション（Broadwim）、サンノゼ、カリフォルニア、米国、2004年10月。オンライン：http：//imj.ucsb.edu/papers/broadwim-04.pdf。
[30] Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm., 23(11), pp. 2194-2205, November 2005.
[30] Garyfalos、A、Almeroth、K。「モバイルIPv6マルチキャストのための柔軟なオーバーレイアーキテクチャ」、IEEE Journ。Comm。、23（11）、pp。2194-2205、2005年11月の選択領域。
[31] "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of Specifications for Phase 1", ETSI TS 102 468;
[31] 「デジタルビデオ放送（DVB）; DVB-H上のIPデータキャスト：フェーズ1の仕様のセット」、ETSI TS 102 468;
[32] ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Implementation Guidelines for Mobility)", European Standard (Telecommunications series), November 2004.
[32] ETSI TS 102 611、「デジタルビデオブロードキャスト（DVB）; DVB-H上のIPデータキャスト：モビリティの実装ガイドライン）、欧州標準（電気通信シリーズ）、2004年11月。
[33] Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- Based Approach", Telecommunication Systems, 17(3), 281-297, 2001. Presented at the INET'98, Geneva, Switzerland, July 1998.
[33] Chuang、J。and Sirbu、M。
[34] Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of Multicast", IEEE/ACM Trans. Netw., 9(6), pp. 719-732, Dec. 2001.
[34] Van Mieghem、P、Hooghiemstra、G、Hofstad、R。「マルチキャストの効率について」、IEEE/ACM Trans。Netw。、9（6）、pp。719-732、2001年12月。
[35] Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast trees", IEEE/ACM Trans. Netw., 11(1), 153-165, 2003.
[35] Chalmers、R.C。and Almeroth、K.C、「マルチキャストツリーのトポロジーについて」、IEEE/ACM Trans。Netw。、11（1）、153-165、2003。
[36] Janic, M. and Van Mieghem, P. "On properties of multicast routing trees", Int. J. Commun. Syst., 19(1), pp. 95-114, Feb. 2006.
[36] Janic、M。and Van Mieghem、P。「マルチキャストルーティングツリーの特性について」、int。J.コミューン。Syst。、19（1）、pp。95-114、2006年2月。
[37] Van Mieghem, P. "Performance Analysis of Communication Networks and Systems", Cambridge University Press, 2006.
[37] Van Mieghem、P。「通信ネットワークとシステムのパフォーマンス分析」、Cambridge University Press、2006。
[38] 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.
[38] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「インターネットグループ管理プロトコル（IGMP） /マルチキャストリスナーディスカバリー（MLD）ベースのマルチキャスト転送（「IGMP / MLDプロキシ」」、RFC4605、2006年8月。
[39] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
[39] Jeon、H.、Jeong、S。、およびM. Riegel、「IEEE 802.16ネットワークを介したイーサネット上のIPの送信」、RFC 5692、2009年10月。
[40] Shin, M-K., Ed., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[40] Shin、M-K。、ed。、Han、Y-H。、Kim、S-E。、およびD. Premec、「802.16ネットワークのIPv6展開シナリオ」、RFC 5181、2008年5月。
[41] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[41] Patil、B.、Xia、F.、Sarikaya、B.、Choi、JH。、およびS. Madanapalli、「IEEE 802.16ネットワークを介したIPv6収束崇拝者を介したIPv6の伝送」、RFC 5121、2008年2月。
[42] Kim, S., Jin, J., Lee, S., and S. Lee, "Multicast Transport on IEEE 802.16 Networks", Work in Progress, July 2007.
[42] Kim、S.、Jin、J.、Lee、S。、およびS. Lee、「IEEE 802.16ネットワークのマルチキャスト輸送」、2007年7月、進行中の作業。
[43] IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area networks Part 16: "Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", New York, February 2006.
[43] IEEE 802.16E-2005：ローカルおよびメトロポリタンエリアネットワークのIEEE標準パート16：「ライセンスバンドでの固定およびモバイル操作を組み合わせた物理および中程度のアクセス制御レイヤーの固定およびモバイルブロードバンドワイヤレスアクセスシステムのエアインターフェイス」、ニューヨーク、2006年2月。
[44] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; "IP Multimedia Subsystem (IMS)"; Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007.
[44] 第3世代パートナーシッププロジェクト。技術仕様グループサービスとシステムの側面。「IPマルチメディアサブシステム（IMS）」;ステージ2、3GPP TS 23.228、rel。5 FF、2002-2007。
[45] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[45] Wasserman、M.、ed。、「第3世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[46] 3GPP2, www.3gpp2.org, "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless IP Network, Rev. A.", http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007.
[46] 3GPP2、www.3gpp2.org、 "x.s0022-a、cdma2000ワイヤレスIPネットワーク、Rev。A。のブロードキャストおよびマルチキャストサービス、http：//www.3gpp2.org/public_html/specs/tsgx.cfm、febuery2007年。
[47] ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)", European Standard (Telecommunications series), November 2004.
[47] ETSI EN 302 304、「デジタルビデオブロードキャスト（DVB）;ハンドヘルドターミナルの送信システム（DVB-H）」、欧州標準（電気通信シリーズ）、2004年11月。
[48] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
[48] Fairhurst、G。およびM. Montpetit、「MPEG-2ネットワークを介したIPデータグラムのアドレス解像度メカニズム」、RFC 4947、2007年7月。
[49] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[49] Montpetit、M.-J.、Fairhurst、G.、Clausen、H.、Collini-Nocker、B。、およびH. Linder、「MPEG-2ネットワークを介したIPデータグラムの送信のフレームワーク」、RFC 4259、2005年11月。
[50] Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in DVB-H", IEEE Comm. Surveys, 8(4), pp. 16-24, 2006.
[50] Yang、X、Vare、J、Owens、T。「DVB-Hのハンドオーバーアルゴリズムの調査」、IEEE Comm。調査、8（4）、pp。16-24、2006。
[51] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[51] Fairhurst、G。およびB. Collini-Nocker、「MPEG-2輸送ストリーム（TS）を介したIPデータグラムの送信のための単方向の軽量カプセル化（ULE）」、RFC 4326、2005年12月。
[52] Fairhurst, G. and B. Collini-Nocker, "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
[52] フェアハースト、G。およびB.コリーニノッカー、「単方向の軽量カプセル化（ULE）およびジェネリックストリームカプセル化（GSE）の拡張フォーマット」、RFC 5163、2008年4月。
[53] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007.
[53] 「ローカルおよびメトロポリタンエリアネットワークのIEEE標準ドラフト：メディア独立したハンドオーバーサービス」、IEEE LAN/MANドラフトIEEE P802.21/D07.00、2007年7月。
[54] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[54] Melia、T.、ed。、「Mobility Services Transport：Problem Statement」、RFC 5164、2008年3月。
[55] Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009.
[55] Melia、T.、Ed。、Bajko、G.、Das、S.、Golmie、N。、およびJC。Zuniga、「IEEE 802.21モビリティサービスフレームワーク設計（MSFD）」、RFC 5677、2009年12月。
[56] Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three Approaches Towards Mobile Multicast", IST Mobile Summit 2003, Aveiro, Portugal, 16-18 June 2003.
[56] Janneteau、C、Tian、Y、Csaba、S。et al。「モバイルマルチキャストに対する3つのアプローチの比較」、ISTモバイルサミット2003、ポルトガル、アベロ、2003年6月16〜18日。
[57] Suh, K., Kwon, D.-H., Suh, Y.-J. and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, January 2004.
[57] Suh、K.、Kwon、D.-H.、Suh、Y.-J。Y. Park、「高速ハンドオーバー環境におけるモバイルIPv6向けの高速マルチキャストプロトコル」、2004年1月、進行中の作業。
[58] Xia, F. and B. Sarikaya, "FMIPv6 extensions for Multicast Handover", Work in Progress, March 2007.
[58] Xia、F。、およびB. Sarikaya、「Multicast HandoverのFMIPV6拡張機能」、2007年3月、Work in Progress。
[59] Schmidt, T. and M. Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Work in Progress, November 2005.
[59] Schmidt、T。およびM. Waehlisch、「階層的なモバイルIPv6環境（M-HMIPV6）でのシームレスなマルチキャストハンドオーバー」、2005年11月、進行中の作業。
[60] Miloucheva, I. and K. Jonas, "Multicast Context Transfer in mobile IPv6", Work in Progress, June 2005.
[60] Miloucheva、I。およびK. Jonas、「モバイルIPv6のマルチキャストコンテキスト転送」、2005年6月、進行中の作業。
[61] Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast mobility support using fast MIPv6 extensions", Computer Comm., 29(18), pp. 3745-3765, 2006.
[61] Leoleis、G、Prezerakos、G、Venieris、I、「高速MIPV6拡張機能を使用したシームレスなマルチキャストモビリティサポート」、Computer Comm。、29（18）、pp。3745-3765、2006。
[62] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[62] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[63] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
[63] Deng、H.、Chen、G.、Schmidt、T.、Seite、P。、およびP. Yang、「Proxy Mobile IPv6のマルチキャストサポート要件」、2009年7月、進行中の作業。
[64] Zhang, H., Chen, X., Guan, J., Shen, B., Liu, E., and S. Dawkins, "Mobile IPv6 Multicast with Dynamic Multicast Agent", Work in Progress, January 2007.
[64] Zhang、H.、Chen、X.、Guan、J.、Shen、B.、Liu、E。、およびS. Dawkins、「Mobile IPv6 Multicast with Dynamic Multicast Agent」、2007年1月の作業。
[65] Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), pp. 18-41, 2004.
[65] Romdhani、I、Kellil、M、Lach、H.-Y。et。アル。「IPモバイルマルチキャスト：課題とソリューション」、IEEE Comm。調査、6（1）、pp。18-41、2004。
[66] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[66] Conta、A。およびS. Deering、「IPv6仕様の汎用パケットトンネル」、RFC 2473、1998年12月。
[67] Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On Deployable, Efficient, Mobility-agnostic Group Communication Services", Internet Research, 17(5), pp. 519-534, Emerald Insight, Bingley, UK, November 2007.
[67] Waehlisch、M.、Schmidt、T.C。「アンダーレイとオーバーレイの間：展開可能で効率的な、モビリティに依存しないグループコミュニケーションサービスについて」、インターネットリサーチ、17（5）、pp。519-534、エメラルド洞察、ビングリー、イギリス、2007年11月。
[68] J. Buford, "Hybrid Overlay Multicast Framework", Work in Progress, February 2008.
[68] J. Buford、「ハイブリッドオーバーレイマルチキャストフレームワーク」、2008年2月、進行中の作業。
[69] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", Work in Progress, October 2009.
[69] Waehlisch、M.、Schmidt、T。、およびS. Venaas、「透明なハイブリッドマルチキャストの一般的なAPI」は、2009年10月に進行中の作業。
[70] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[70] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[71] Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", IEEE Wirel. Comm., 9(5), pp 58-64, Oct. 2002.
[71] Jelger、C、Noel、T。Comm。、9（5）、pp 58-64、2002年10月。
[72] Romdhani, I, Bettahar, H. and Bouabdallah, A. "Transparent handover for mobile multicast sources", in P. Lorenz and P. Dini, eds, Proceedings of the IEEE ICN'06, IEEE Press, 2006.
[72] Romdhani、I、Bettahar、H。およびBouabdallah、A。
[73] Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002.
[73] リン、C.R。etal。「IPベースのモバイルネットワークにおけるスケーラブルなマルチキャストプロトコル」、ワイヤレスネットワーク、8（1）、pp。27-36、2002年1月。
[74] Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with Dynamic Tree Adjustment for Mobile IPv6", Journ. Information Science and Engineering, 20(6), pp. 1109-1124, 2004.
[74] チャン、R.-S。とイェン、Y.-S。「モバイルIPv6の動的ツリー調整を伴うマルチキャストルーティングプロトコル」、Journ。Information Science and Engineering、20（6）、pp。1109-1124、2004。
[75] Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings of ietf meeting, Dec. 2001. URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf
[75] Thaler、D。
[76] Jelger, C. and T. Noel, "Supporting Mobile SSM sources for IPv6 (MSSMSv6)",Work in Progress, January 2002.
[76] Jelger、C。and T. Noel、「IPv6（MSSMSV6）のモバイルSSMソースのサポート」、2002年1月、進行中の作業。
[77] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[77] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[78] Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 2002.
[78] Vida、R、Costa、L、Fdida、S。「M -HBH-マルチキャストの効率的なモビリティ管理」、Proc。NGC '02、pp。105-112、ACM Press 2002。
[79] A. O'Neill "Mobility Management and IP Multicast", Work in Progress, July 2002.
[79] A. O'Neill「Mobility Management and IP Multicast」、2002年7月の進行中の作業。
[80] Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - Problems, Solutions and Improvements", Computational Methods in Science and Technology, 11(2), pp. 147-152. Selected Papers from TERENA Networking Conference, Poznan, May 2005.
[80] Schmidt、T。C.およびWaehlisch、M。2005年5月、ポズナンのTerena Networking Conferenceの選択された論文。
[81] Schmidt, T.C., Waehlisch, M., and Wodarz, M. "Fast Adaptive Routing Supporting Mobile Senders in Source Specific Multicast", Telecommunication Systems, 43(1), pp. 95-108, 2009, http://dx.doi.org/10.1007/s11235-009-9200-y.
[81] Schmidt、T.C.、Waehlisch、M。、およびWodarz、M。.org/10.1007/s11235-009-9200-y。
[82] Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source Mobility in Source Specific Multicast", in K. Kawahara and I. Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91, Springer-Verlag, Berlin, Heidelberg, 2006.
[82] Lee、H.、Han、S。、およびHong、J。3961、pp。82-91、Springer-Verlag、Berlin、Heidelberg、2006。
[83] Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast", Third International Conference on Networking and Services ICNS, IEEE Press, pp. 1-1, June 2007.
[83] Kovacshazi、Z。およびVida、R。
[84] Kellil, M, Romdhani, I, Lach, H.-Y, Bouabdallah, A. and Bettahar, H. "Multicast Receiver and Sender Access Control and its Applicability to Mobile IP Environments: A Survey", IEEE Comm. Surveys & Tutorials, 7(2), pp. 46-70, 2005.
[84] Kellil、M、Romdhani、I、Lach、H.-Y、Bouabdallah、A。およびBettahar、H。Surveys＆Tutorials、7（2）、pp。46-70、2005。
[85] Castellucia, C, Montenegro, G. "Securing Group Management in IPv6 with Cryptographically Based Addresses", Proc. 8th IEEE Int'l Symp. Comp. and Commun, Turkey, July 2003, pp. 588-93.
[85] Castellucia、C、Montenegro、G。8th IEEE int'l symp。comp。およびコミューン、トルコ、2003年7月、588-93ページ。
[86] Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - a mobility-compliant protocol framework for multicast sender authentication", Security and Communication Networks, 1(6), pp. 495-509, 2008.
[86] Schmidt、T.C、Waehlisch、M.、Christ、O。、およびHege、G。2008年。
[87] Fenner, B., Holbrook, H., and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", Work in Progress, November 2001.
[87] Fenner、B.、Holbrook、H。、およびI. Kouvelas、「関心プロトコルのマルチキャストソース通知（MSNIP）」、2001年11月、進行中のWork。
[88] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[88] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
Acknowledgments
謝辞
Work on exploring the problem space for mobile multicast has been pioneered by Greg Daley and Gopi Kurup within their early document "Requirements for Mobile Multicast Clients".
モバイルマルチキャストの問題スペースの調査に関する作業は、初期のドキュメント「モバイルマルチキャストクライアントの要件」の中で、グレッグデイリーとゴーピークルップによって開拓されました。
Since then, many people have actively discussed the different issues and contributed to the enhancement of this memo. The authors would like to thank (in alphabetical order) Kevin C. Almeroth, Lachlan Andrew, Jari Arkko, Cedric Baudoin, Hans L. Cycon, Hui Deng, Marshall Eubanks, Zhigang Huang, Christophe Jelger, Andrei Gutov, Rajeev Koodli, Mark Palkow, Craig Partridge, Imed Romdhani, Hesham Soliman, Dave Thaler, and last, but not least, very special thanks to Stig Venaas for his frequent and thorough advice.
それ以来、多くの人々がさまざまな問題について積極的に議論し、このメモの強化に貢献しています。著者は、（アルファベット順に）ケビンC.アルメロス、ラクランアンドリュー、ジャリアークコ、セドリックボードイン、ハンスL.サイコン、フイデン、マーシャルユーバンクス、Zhigang Huang、Christophe Jelger、Andrei Gutov、Rajeev Koodli、Mark Palkowに感謝したいと思います。、クレイグ・パートリッジ、イメッド・ロムダニ、ヘシャム・ソリマン、デイブ・タラー、そして最後になりましたが、彼の頻繁で徹底的なアドバイスをしてくれたStig Venaasに感謝します。
Authors' Addresses
著者のアドレス
Thomas C. Schmidt Dept. Informatik Hamburg University of Applied Sciences, Berliner Tor 7 D-20099 Hamburg, Germany Phone: +49-40-42875-8157 EMail: schmidt@informatik.haw-hamburg.de
トーマス・C・シュミット・デプト・インフォマティック・ハンブルク応用科学大学、ベルリナー・トル7 D-20099ハンブルク、ドイツ電話：49-40-42875-8157電子メール：schmidt@informatik.haw-hamburg.de
Matthias Waehlisch link-lab Hoenower Str. 35 D-10318 Berlin, Germany EMail: mw@link-lab.net
Matthias Waehlisch link-lab hoenower str。35 D-10318ベルリン、ドイツメール：mw@link-lab.net
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, UK EMail: gorry@erg.abdn.ac.uk
アバディーン大学アバディーン大学、AB24 3UE、英国のEngineering School of Engineering School of Engineeringのゴッドレッドメール：gorry@erg.abdn.ac.uk