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
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ネットワークのためのマルチキャストルーティングおよび展開の問題の特性側面が要約されています。基盤となるネットワークアクセスの特定のプロパティとinterplaysは、無線ドメイン内の関連する技術に関して調査されています。それは一緒にモバイルマルチキャストの問題と解空間の総合的な探査で、マルチキャストモビリティへの主要なアプローチの概要を説明します。この文書では、将来のモバイルマルチキャストプロトコルの設計者が使用するための標準化における最初のステップのための概念的なロードマップで終了します。この文書では、IPモビリティの最適化（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.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のMobOpts研究グループのコンセンサスを表しています。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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]の幅広い採用につながりました。ブロードバンドメディア配信は、マルチキャストルーティングのスケーラビリティと帯域幅効率を要求する典型的な質量シナリオとして浮上しています。マルチキャストモビリティは、[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] [6] [5]モバイルIPv6 RFCで標準化され、無線ドメイン間を移動しつつ、ネットワーク層の変化のシナリオに対処します。 MIPv6の[5]のみおおよそのモバイルノードに対してマルチキャストモビリティを規定する（MNの）リモートサブスクリプションアプローチを使用するか、ホームエージェント（HA）を介して、双方向トンネリングを介し。リモートサブスクリプションは、ハンドオーバに適応するためのマルチキャストルーティングに頼る遅いハンドオーバに苦しんでいます。双方向トンネリングではなく、最短経路上の走行、すなわち、パケットはホームエージェントを介してルーティングされる、により三角形の転送に非効率的でオーバーヘッド及び遅延を導入します。したがって、これらのアプローチは、大規模な展開のために最適化されていません。今後のインターネットのためのモバイルマルチキャストサービスは、リアルタイムメディア配信に準拠したサービス品質と組み合わせて堅牢性を提供し、予測可能な、限られたコストでのルーティング「に近いツー最適」を提供すべきです。
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.
マルチメディア会議シナリオ、ゲーム、またはコラボレーション環境において、各部材は、一般的に受信機としてマルチキャストグループ通信のための送信側として動作します。 - 150 MS [7]典型的なシームレスなハンドオーバのシナリオを中断または100未満の遅延を制限することが期待される。また、このような会話音声やビデオなどのリアルタイム通信は、モビリティプロトコルに厳しい時間的要件を課します。ジッタ障害が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研究グループのコンセンサスを表しています。それは仕事の特定の領域に積極的に研究グループのメンバーによって検討されています。また、この文書は包括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.
マルチキャストノードの移動性を考慮すると、ネットワーク層は、いくつかの無線アクセス技術によって補完されます。二つの基本的なシナリオは興味深いものである：シングルホップモビリティ（図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：モビリティシナリオ - モバイルノード（MN）を直接ローカルアクセスルータを介して取り付けられた固定アクセスルータ（ARS）またはへの接続（ラース）
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
マルチキャストモビリティは異なる機能の集合を包含し、一般的な用語です。まず、マルチキャスト通信は、任意のソースマルチキャスト（ASM）に分割されている[2]とソース固有マルチキャスト（SSM）[9] [10]。第二に、送信側と受信側の役割ははっきりと非対称です。どちらも、個別に移動体であってもよいです。それらの相互作用は、距離ベクトルマルチキャストルーティングプロトコル（DVMRP）[11]などのマルチキャストルーティングプロトコルによって促進されます
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].
プロトコル独立マルチキャスト - スパースモード/ソース固有マルチキャスト（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サブネットから移動するときには、マルチキャストセッションのシームレスな継続性を有効にする必要があります。パケット分布と近似最適なルーティングのマルチキャスト性質を維持することが望まれます。流れの特性と名称が異なることができるからでマルチキャストトラフィックのフローごとのハンドオーバをサポートしなければなりません。このような区別は、サービス品質（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.
マルチキャストルーティングを動的次いでモビリティ下で変更することができるマルチキャストセッションに参加して送信者（S）と受信機（複数可）の位置でのネットワークトポロジーに適合する。しかし、トポロジおよび使用中のプロトコルに応じて、現在のマルチキャストルーティングプロトコルは、受信機または送信者位置の変化に追従収束する秒に近い時間を必要とするかもしれません。これは、対話型またはリアルタイムメディアセッションのシームレスハンドオーバをサポートするにはあまりにも遅いです。実際の時間的挙動に強く、使用中のマルチキャストルーティングプロトコル、ルータの構成に、電流分配ツリーの幾何学的形状に依存します。ルーティング、すなわち、部分的に変更を再調整または完全にマルチキャストツリーを再構成するモビリティ・スキームは、プロトコルの収束時間スケールに適合するように強制されます。具体的には、これは一般的なプロトコル状態の更新よりもはるかに高いレートで発生する可能性がありますように、移動ノードの可能な急速な動きを考慮する必要があります。
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.
また、多くの無線計画では、バッテリ駆動のモバイル機器とネットワークの制約された伝送容量の限られたリソースを保存するために、マルチキャスト関連のシグナリングを最小限にすることも望ましいです。これは、MNに向けてMLDクエリーを制限したいという願望につながる可能性があります。マルチホームのMNは、MLDすることによって容易にインターフェースごとのサブスクリプションは、事前に選択されたIPv6インターフェイス上で動作JOINを必要とする「メイクの前にブレイク」のアプローチを使用してスムーズなハンドオフを確実にすることができます。
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.
上流のルータとの間の経路上のカプセル化と受信機はパス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 /垂直ハンドオーバーを行う場合であっても、リンクマルチポイントサービスをアクティブにします。
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グループにデータを送信するノードは、ランデブーポイント（RP）または受信機に向けてデータを配信する、ソース固有の最短経路ツリー（SPT）のルートを形成するか、あるいはそれは、共有ツリーの下に直接データを転送しますPIM Registerメッセージ、または双方向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.
モバイルマルチキャストソースは、従って、二つの層のアドレス透過性を提供しなければならない：RPFチェックに準拠するためには、使用マルチキャスト配信ツリーとトポロジー一致しているIPv6の基本ヘッダのソース・フィールド内のアドレスを使用しなければなりません。アプリケーションの透過性のために、論理ノード識別子、一般の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を使用した場合、ドメイン内モビリティが透過（IPv4のとは対照的に、IPv6のASMマルチキャストグループは、特定のRP / 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、G）-stateソースSをルートとする最短経路ツリーを確立します。従って、モビリティ下送信元アドレスの変更は、上流側経路上のすべてのルータに、グループ内のすべての受信機の状態の更新を必要とします。ソースハンドオーバに、新しい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ソースのバインディングアップデートは、このように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のリーンを維持することが望ましいです。
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マルチキャストの展開は、一般的には、[27]、すべての主要なルータベンダやオペレーティングシステムがマルチキャストをサポートする実装を提供するにもかかわらず、過去15年間に遅れています。多くの（壁）ドメインまたは企業ネットワークがポイントツーマルチポイントサービスを運用しながら、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.
マルチキャスト配信ツリーは、ネットワーク効率の焦点から研究されてきました。経験的観察に接地され、荘と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]荘とSIRBUスケーリング法の適用可能性を議論しました。ヴァンMieghemら。 [34]提案べき乗則が増加インターネット又は非常に大きなマルチキャストグループに対して保持することができないことを証明したが、実際に適度受信番号とNの現在のインターネットの大きさは10 ^ 5コアノードを=に適用可能です。 [37]自己相似性を調査し、JANICヴァンMieghem [36]半経験インターネットにおけるマルチキャスト最短パス木が均一再帰木（URTs）によって合理的な精度でモデル化することができることを実証提供MはNに比べて小さいまま
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
最短パス木上の移動度の観点、すなわち、それらの変更、運動によって誘発されるトポロジの変更の度に焦点を当てています。受信機のために、より興味深いことに源ため、これは、ルーティングの複雑さの特性尺度として働くことができます。近隣のネットワークに移動する移動リスナーはわずか数ホップに渡る木の枝を変更します。続いてソースハンドオーバ手順から生成されたソース固有マルチキャストツリーは、独立したが、高度に相関していません。 1で同一の受信器または複数の交点に彼ら最も可能性の高い枝。自己類似の性質によって（前と次分配ツリーの）永続的なサブツリー、任意のそのような交点をルートと、展示再びスケーリング則の挙動、主に低度のノードと背の高い形状であるので、一致する可能性。モビリティの下のツリーの変更は、両方の解析的とすることにより、[26]で研究されています
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.
シミュレーション。それも、大規模なネットワークで、適度な受信機番号のマルチキャストルータ状態の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.
第二に、ネットワーク・アクセス層でのポイント・ツー・マルチポイントサービス起動は、ネットワークレイヤー要求からマッピングメカニズムが必要となります。この機能は、一般に、時折マルチキャストVLAN登録（MVR）によって補完さL3の認識、すなわち、IGMP / MLDスヌーピング[70]またはプロキシ[38]、によって達成されます。加入者は、別のVLANに残りながら、MVRは、ネットワーク内の単一のマルチキャストIEEE 802.1Q仮想LANの共有を可能にします。マルチキャストとユニキャストトラフィックのこの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).
第三に、層の間のアドレス・マッピングは、共通のグループ識別のために必要とされます。アドレス解決スキームが使用されている技術の詳細をフレーミングに依存するが、一般に、下位層における上位アドレス重複を引き起こす（すなわち、複数のIPマルチキャストグループアドレスは、同一のL2アドレスを使用して送信されています）。
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マルチポイントデータは、輻輳を引き起こす可能性があります。同じサブネットのすべてのアクセスポイントがマルチキャストフレームを複製します。
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.
マイクロウェーブ・アクセス（WIMAX）のためのIEEE 802.16ワールドワイド・インターオペラビリティは、シングルホップポイント・ツー・マルチポイント（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基地局が接続識別子に基づいてスイッチングして、全二重L2スイッチとして動作します。モバイルアクセスシナリオのための2つのIPv6リンクモデルが存在します。イーサネット回線上のIPの共有IPv6プレフィックスは、（CS）のスイッチ[39]共有プレフィックス内のメディアアクセス制御（MAC）の分離を提供します。第二、ポイントツーポイントリンクモデル[40]は、単一のリンクとして、移動ノードへの各接続を扱うIPv6の収束サブレイヤ[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マルチキャストアドレスマッピングは、イーサネットCS [42]にマルチキャストに由来する8つの最下位ビットを利用することにより、いずれか4つの最下位ビットをコピーすることによって提案されています。グループメンバーを選択するために、基地局は、の802.16e-2005 [43]に予見としてIGMP / MLDスヌーピングまたはプロキシ実装することができます。
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のCIDにマルチキャストアドレスのマッピングは、標準化を必要とします。
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異なるマルチキャストグループのためのCIDの衝突が原因短いID空間に発生し得ます。これは、不要なL2トラフィックをフィルタリングするための受信機の能力を低下させる、同じCIDを共有するいくつかのポイント・ツー・マルチポイントグループをもたらすことができます。
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].
3GPP（3rd Generation Partnership Project）のシステムアーキテクチャは、回線交換またがる（CS）およびパケット交換（PS）ドメイン、後者の汎用パケット無線サービス（GPRS）は、IPマルチメディアサブシステム（IMS）[44]を搭載しています。 3GPP PSは、コネクション型およびパケットデータプロトコル（PDP）コンテキストの概念に基づいています。 PDPは、移動端末とゲートウェイGPRSサポートノード（GGSN）との間のポイントツーポイントリンクを定義します。インターネットサービスタイプは、IPv6アドレスの割り当てのための推奨は、各（プライマリ）PDPコンテキスト[45]にプレフィックスを関連付けるPPPはIPv4、およびIPv6です。
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.
ユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）のRelで。図6に示すように、IMSは、マルチメディアブロードキャストおよびマルチキャストサービス（MBMS）を含むように拡張しました。インターネットマルチキャストへのゲートウェイサービスは、IGMP / MLD認識GGSNで処理されている間ポイントツーマルチポイントGPRS接続サービスは、無線リンク上で動作します。ローカルIPマルチキャストオーバー（マルチTID付き）ジェネリックトンネリングプロトコル（GTP）を超えるグローバルIPマルチキャストデータグラム：ローカルマルチキャストパケットの配信はGGSNでの共通の二重カプセルが得られGPRS IPバックボーン内で使用されます。
The 3GPP MBMS has the following characteristics:
3GPPのMBMSには次の特徴があります。
o There is no immediate Layer 2 source-to-destination transition, resulting in transit of all multicast traffic at the GGSN.
O GGSNでのすべてのマルチキャストトラフィックの通過をもたらす、即時レイヤ2ソース - 宛先遷移はありません。
o As GGSNs commonly are regional, distant entities, triangular routing and encapsulation may cause a significant degradation of efficiency.
GGSNは、一般的に地域、遠くのエンティティであるため、O、三角ルーティングおよびカプセル化は、効率の大幅な低下を引き起こす可能性があります。
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において、MBMSは、ルーティング層の上にMBMSと非常に類似して動作するブロードキャストおよびマルチキャストサービス（BCMCS）[46]に拡張されています。 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）。これは、リンクの前方誤り訂正（FEC）とMPEG-2トランスポートストリーム（TS）を介してIPパケットを転送するためにマルチプロトコルカプセル化（MPE）を使用しています。各ストリームは、一緒に多重化サービスIDと13ビットのTS ID（PID）によって識別される、[48] IPv4またはIPv6アドレスに関連付けられており、受信機での選択トラフィックのフィルタリングのために使用されます。アップストリームチャネルは、他の伝送技術を使用して、DVB-Hを補完することができます。 IPデータキャストサービス、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.
マルチキャスト配信サービスは、[49] IPエンカプスレータで管理されている適切なPIDを、上のグループのマッピングによって定義されます。柔軟性を向上させ、衝突を避けるために、このアドレス解決は、自己完結型のMPEG-2 TS内に設けられたダイナミックテーブル、によって促進されます。モビリティは、セルID、ネットワークID、トランスポートストリームIDの変更が予見されているという意味で支持されている[50]。マルチキャストレシーバは、このように、それは同期の段階で購読しているマルチキャストサービスを再配置し、そのサービスフィルタを更新する必要があります。そのハンドオーバ決定は、サービスの可用性に依存してもよいです。アクティブサービス加入は、（マルチキャスト参加）の純粋なDVB-HネットワークにシグナリングすることができないIPエンカプスレータ/ 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、高度テレビジョンシステム委員会（ATSC）、および関連規格[49]で指定されたものを含め、テレビ放送ネットワークで有効にすることができます。これらの規格は、1-との双方向衛星IPサービスに使用されています。 MPEG-2トランスポートストリームに基づいて、ネットワークは、マルチプロトコルカプセル化（MPE）又は一方向軽量カプセル化（ULE）[51]のいずれかをサポートすることができます。第二世代の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
MPEG-2伝送ネットワークでは、マルチキャスト配信サービスは、IPエンカプスレータ[49]で管理されている適切なPIDを、上のグループのマッピングによって定義されます。アドレッシングの問題が似ています
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.
DVB-H（セクション4.2.4）のためのもの[48]。 GSEを使用する問題は（PIDフィルタリングトラフィックの機構としては使用できませんを除く）ULEのものに似ています。双方向接続を提供するネットワークは、上流側のIPエンカプスレータ/ゲートウェイから転送を開始する（マルチキャスト参加）アクティブサービス加入を可能にすることができます。フィルタリングのいくつかの種類は、入力ストリーム識別子（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のためのモビリティサービス・トランスポートは、[54]インターネットの文脈でのレイヤ2マルチキャストサービス転送のための抽象化として必要とされており、[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エージェントベースのソリューションは、前の二つの機構の間でバランスをとることを試みます。帯電防止剤は、典型的には、いくつかのエージェント間ハンドオーバモバイルノードの移動を可能にする、ローカルトンネリング・プロキシとして働きます。減速間ツリーのハンドオーバは、すなわち、「ツリーウォーキング」、いくつかの余分な労力が移動発生源のアドレス透明性を通じてセッションの持続性を維持するために必要とされるエージェントベースのマルチキャストモビリティの結果になります。
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]、階層のMIPv6のM-FMIPv6と[57] [58]、及び（HMIPv6の）[20]、十分[25] [61]に分析されており、コンテキスト転送にM-HMIPv6の[59] [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は、以前のネットワークと接触してもはや存在しませんでした。この場合、ネットワーク自体は、コンテキスト転送を支援することはできません。そのようなシナリオは、別の（壁の）オペレータから移動するときに発生する可能性のある単独のノードに基づいて接続し、コンテキストの損失から回復するための後方互換性のある方法が必要となります。
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）、及びMNの現在のMAGを接続するポイントツーポイントリンクとの間のユニキャストトンネルで構成されています。 PMIPv6ドメインは、それによって受信機サイトでトンネルにまたがるからMTUサイズの問題を継承します。さらに、2つのアバランシェ問題点を同定することができる：MAGは、個々のポイントツーポイントリンクを介して多数のMNに同じマルチキャストストリームを転送するために必要とされるかもしれないLMAは、のMAGの多数にトンネルデータに必要とされ得る[63 ]。共有リンクの将来の最適化と拡張機能は、好ましくは、おそらくIPモビリティに依存しないのMNを支援するアクセスゲートウェイとの間のコンテキスト転送を含めて、ローカルルーティングオプションを使用して、エッジネットワークに向けネイティブマルチキャスト配信を適応させます。
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.
インターネットのエッジに位置する反応性作動プロキシゲートウェイを使用して、初期のハイブリッドアーキテクチャはGaryfalosとAlmeroth [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]やハイブリッドマルチキャストの透過的なアクセスのための共通のマルチキャストAPI [69]を開発しています。
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.
ハンドオフ前に早く完了メッセージを送信して、以前のネットワークを出るときに予測ハンドオーバを操作するMNは、例えば、FMIPv6とを使用して、マルチキャストサービスの終了を促進することができます。 MLDルータクエリは、マルチキャスト転送状態が誤予測の場合に復元することを可能にする（即ち、行われていないネットワークへの予想される移動）。そうでない場合は休暇を確保することができる後方コンテキスト転送が通知されます。 HAはマルチキャストルータである場合にさらに最適化は特殊なケースのためJelgerとノエル[71]によって導入されました。完了メッセージは、（後続のタイムアウト付き）標準MLDメンバーシップクエリを開始してはならない（直接一般にMNを、接続ポイントツーポイントリンクを介して）モバイルエンドノードからトンネルを介して受信しました。ポイントツーポイントリンクのような明示的な治療は、トラフィックを削減し、制御プロトコルを加速します。明示的なトラッキングは、同一のプロトコル動作の原因となります。
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]において著者らは、MNとHAとの間で交換されるリスナーの保留メッセージを導入し、MLDへの拡張を提案します。このアイデアは、グループメンバーシッププロキシの一般的な展開を可能に、マルチキャストルータの出席制御を提案する[59]で開発されました。いくつかの現在展開IPTVソリューションは、いくつかの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ら。 [72]モビリティアンカーとしてPIM-SMのランデブーポイントを使用する提案しました。モバイル送信者これらの「モビリティ対応のランデブーポイント」（MRPの）へのトンネルにデータを。 1つのドメインに制限された場合、この方式は、双方向トンネリングと同等です。ドメイン間のモバイルマルチキャストを中心に、著者はtunnel-または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ルーティング、チャンと円[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はを再構成するためのアプローチは、新しいルータの状態を確立するために、クライアントの通知に依存しています。彼らはまた、クライアントのアドレスの透明性を維持する必要があります。ターラー[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とノエル[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ら。 [78]ソースと第一の分岐点との間の経路上の移動元のためのSPTを最適化しました。オニール[79]はホップバイホップオプションヘッダを、「RPFは、リダイレクト」でデータを伴う拡張ルーティング情報を導入することによって、ランデブーポイントシナリオにマルチキャストソースアドレスが変更に由来RPFチェックの失敗を克服するための方式を提案しました。シュミットとWaehlisch [80]のツリーモーフィング手法は、それによって、ホップバイホップオプションヘッダにルータ状態の更新を注入し、以前に確立されたSPTのルートを拡張するためにソースルーティングを使用します。拡張RPFチェックを使用して、細長いツリーは自律的にショートカットを開始し、円滑に移転ソースをルートと新SPTに減少させます。このプロトコルの拡張バージョンは、[81]最初のソースルーティングを放棄し、迅速なソース運動に適合するように証明することができます。 Leeら。 [82]確立されたマルチキャストツリーの大部分を再利用するための状態更新機構を導入しました。著者は、モバイルソースのホーム・エージェントを中心と最初に確立分布状態からスタート。そのホームネットワークを離れるモバイルソースはその後、分布状態は、前回の配信ツリーに沿って、モバイルソースの新たなCoAによると、そのホームエージェントへのパス上のマルチキャスト転送状態の更新を通知してます。マルチキャストデータは、その後の伸びとホームエージェントを中心に更新ツリーを経由して、三角形のルートを使用してネイティブに流れるように意図されます。ホスト識別プロトコル識別子、Kovacshaziとヴィダ[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-キャストデータは、サービス拒否攻撃に対して脆弱である可能性があるということ。ソース認証に加えて、リプリケータのレート制御は、エージェントと下流ネットワークを保護するために必要とされ得ます。
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関連添付ファイルとの間に変更される可能性があり、または個々に（再）アソシエーションをネットワークに前に選択することができます。最も適切なネットワークパスは、ユーザの嗜好を満たすもの、例えば、使用する/など、金銭コストを最小限に抑える、特定のネットワークを避けるためではなく、唯一の経路コストを最小化するものであってもよいです。したがって、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]による自律的検証、認証を必要とします。これは、例えば、暗号化生成アドレス（CGAs）によって達成することができます。
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;
マルチキャストおよびモビリティが共同でIPv6の層で発生するという問題空間の構造化された概要を提供するO;
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-トンネルのない家庭のサブスクリプションの問題だけでなく、ネイティブマルチキャスト受信に取り組みます。
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.エンドノードのアドレスの二重性管理を設計することにより、基本的なマルチキャストソースモビリティを提供。
Appendix A. Implicit Source Notification Options
付録A.暗黙のソース通知オプション
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マルチキャストソースは、グループからの明示的なフィードバックを必要とすることなく、受信機のグループにデータを送信します。源は、従って、任意の受信機がグループに加入しているかどうかのネットワーク層に気付いていない、無条件（多くの場合、指定ルータとしてPIMで知られている）最初のホップルータへのネットワークに伝播するマルチキャストパケットを送信します。加入受信機の存在の源に通知する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.
[2] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[2]デアリング、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通信誌、35（1）、頁54-58、1997年1月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4]デアリング、S.と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]ジョンソン、D.、パーキンス、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.デュポン、RFC 4877、2007年4月 "のIKEv2および改訂のIPsecアーキテクチャとのモバイルIPv6の操作"。
[7] ITU-T Recommendation, "G.114 - One-way transmission time", Telecommunication Union Standardization Sector, 05/2003.
[7] ITU-T勧告、 "G.114 - 片道送信時間"、通信連合標準化部門、05/2003。
[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及びワング、X.、 "無線メッシュネットワークに関する調査"、IEEE通信誌、43（9）、PP。23-30、2005年9月。
[9] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[9]バッタチャリヤ、S.、エド。、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月を。
[10] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[10]ホルブルック、H.、およびB.カイン、 "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.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL 。魏、 "プロトコル独立マルチキャスト - スパースモード（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]フェナー、B.、ハンドリー、M.、ホルブルック、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]ハンドレー、M.、Kouvelas、I.、スピークマン、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]ベイツ、T.、チャンドラ、R.、キャッツ、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見（MLD）IPv6の"、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]ビダ、R.、エド。、およびL.コスタ、エド。、 "マルチキャストリスナ発見バージョン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.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のための強化されたルート最適化"、RFC 4866、2007年5月。
[19] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[19] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、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]ソリマン、H.、カステルッシア、C.、ElMalki、K.、およびL. Bellier、 "階層モバイル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.、編、Nakhjiri、M.、パーキンス、C.、およびR. Koodli、 "コンテキスト転送プロトコル（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] Montavont、N.、Wakikawa、R.、エルンスト、T.、呉、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]ナラヤナン、V.、ターラー、D.、Bagnulo、M.、およびH.ソリマン、 "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.ハーバーマン、 "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。そしてWaehlisch、M.「反応対予測 - ハンドオーバー性能およびIPv6やマルチキャストモビリティへの影響の分析」。、通信システム、30（1-3）、頁123-142、2005年11月。
[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.「ディストリビューションツリーをモーフィング - モビリティの下でマルチキャスト米国の進化とモバイルSSMソースの適応型ルーティングスキームに」。、通信システム、33（1-3）、頁131から154まで、2006年12月。
[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.ら。 「IPマルチキャストサービスとアーキテクチャの展開に関する問題」、IEEEネットワークマガジン、スペック。マルチキャスト、14（1）、頁78-88、2000年問題。
[28] Eubanks, M. http://multicasttech.com/status/, 2008.
[28]ユーバンクス、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）、頁。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）; IPデータキャストDVB-H上：フェーズ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]荘、J.及びSIRBU、M. "価格マルチキャスト通信：コストベースのアプローチ"、通信システム、17（3）、281から297まで、2001 INET'98、ジュネーブ、スイス、2011で発表1998。
[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]ヴァンMieghem、P、Hooghiemstra、G、Hofstad、R. "マルチキャストの効率について"、IEEE / ACMトランス。 NETW。、9（6）、頁。 719から732まで、12月2001。
[35] Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast trees", IEEE/ACM Trans. Netw., 11(1), 153-165, 2003.
[35]チャルマーズ、R.C. "マルチキャストツリーのトポロジーについて" とAlmeroth、K.C、IEEE / ACMトランス。 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.ヴァンMieghem、P.、INT "マルチキャストルーティング木の特性"。 J. COMMUN。 SYST。、19（1）、頁95から114、2006年2月。
[37] Van Mieghem, P. "Performance Analysis of Communication Networks and Systems", Cambridge University Press, 2006.
[37]ヴァンMieghem、P.、ケンブリッジ大学出版局、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]フェナー、B.、彼、H.、ハーバーマン、B.、およびH. Sandick、 "インターネットグループ管理プロトコル（IGMP）/マルチキャストリスナ発見（MLD）ベースマルチキャスト転送（" IGMP / MLDプロキシ」） 」、RFC 4605、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]チョン、H.、チョン、S.、およびM.リーゲル、 "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]新、M-K。編、ハン、Y-H。、キム、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]パティル、B.、夏、F.、Sarikaya、B.、チェ、JH。、およびS. Madanapalli、RFC 5121、2008年2月に "IEEE 802.16ネットワークの上のIPv6コンバージェンスサブレイヤを介したIPv6の送信"。
[42] Kim, S., Jin, J., Lee, S., and S. Lee, "Multicast Transport on IEEE 802.16 Networks", Work in Progress, July 2007.
[42] "IEEE 802.16ネットワーク上のマルチキャスト転送" キム、S.、ジン、J.、リー、S.、およびS.リー、進歩、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.
、RFC 3314、2002年9月[45]ワッサーマン、M.、エド。、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[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.
"CDMA2000無線IPネットワーク、牧師AのX.S0022-A、ブロードキャストおよびマルチキャスト・サービス" [46] 3GPP2、www.3gpp2.org、http://www.3gpp2.org/Public_html/specs/tsgx。 cfmが、2007年2月。
[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、RFC 4947、2007年7月 "MPEG-2ネットワーク上でIPデータグラムのための解決メカニズムアドレス"。
[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.リンダー、 "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]ヤン、X、Vare、J、オーウェンズ、T. "DVB-Hにおけるハンドオーバアルゴリズムの調査"、IEEE Commの。調査、8（4）、頁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、 "一方向軽量カプセル化（ULE）MPEG-2トランスポートストリーム（TS）上のIPデータグラムの送信の"、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] Fairhurst、G.およびB. Collini-Nocker、 "一方向軽量カプセル化（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]メリア、T.、エド、 "モビリティサービス交通：問題文"。、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]メリア、T.、エド。、Bajko、G.、ダス、S.、Golmie、N.、およびJC。スニガ、 "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、天、Y、チャバ、S.ら。 「三の比較は、モバイルマルチキャスト向けての取り組み」、ISTモバイル・サミット2003、アヴェイロ、ポルトガル、16-18 2003年6月。
[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]ソ、K.、クォン、D.-H.、ソ、Y.-J.そして、Y.パーク、「高速ハンドオーバ環境でのモバイルIPv6のための高速マルチキャストプロトコル」、進歩、2004年1月での作業。
[58] Xia, F. and B. Sarikaya, "FMIPv6 extensions for Multicast Handover", Work in Progress, March 2007.
[58]夏、F.及びB. Sarikaya、 "マルチキャストハンドオーバのためのFMIPv6と拡張"、進歩、2007年3月に作業。
[59] Schmidt, T. and M. Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Work in Progress, November 2005.
[59]シュミット、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.ジョナス、 "モバイル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、コンピュータCommの "高速MIPv6の拡張機能を使用してシームレスなマルチキャストモビリティサポート"。、29（18）、頁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。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 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]鄧小、H.、陳、G.、シュミット、T.、Seite、P.、およびP.ヤン、 "プロキシモバイル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]張、H.、チェン、X.、関、J.、シェン、B.、劉、E.、およびS.ドーキンス、 "動的マルチキャストエージェントとモバイルIPv6マルチキャスト"、進歩、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.ら。アル。 「IPマルチキャストモバイル：課題と解決策」、IEEEコム。調査、6（1）、頁18-41、2004。
[66] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[66]コンタ、A.、およびS.デアリング、 "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.、シュミット、T.C。 「アンダーレイとオーバーレイ間：デプロイ、効率、モビリティに依存しないグループコミュニケーションサービスについて」、インターネットリサーチ、17（5）、頁519から534、エメラルドインサイト、ビングレー、イギリス、2007年11月。。
[68] J. Buford, "Hybrid Overlay Multicast Framework", Work in Progress, February 2008.
[68] J.ビュフォードは、「ハイブリッドオーバーレイマルチキャストフレームワーク」、進歩、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.、シュミット、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.
、RFC 4541、2006年5月[70]クリステンセン、M.、キンボール、K.、およびF. Solensky、 "インターネットグループ管理プロトコル（IGMP）およびMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[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、ノエル、T. "マルチキャストIPネットワークにおける移動ホストのために：進歩と課題"、IEEE Wirel。 COMM。、9（5）、頁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] P.ローレンツとP.ディーニ、編、IEEE ICN'06の議事録、IEEEプレス、2006年に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.ら。 "IPベースのモバイルネットワークにおけるスケーラブルマルチキャストプロトコル"、ワイヤレスネットワーク、8（1）、頁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。情報科学と工学、20（6）、頁。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]ターレル、D. "IPv6のモバイルSSMソースのサポート"、IETF会議の議事録12月2001. URL：www.ietf.org/proceedings/01dec/slides/magma-2.pdf
[76] Jelger, C. and T. Noel, "Supporting Mobile SSM sources for IPv6 (MSSMSv6)",Work in Progress, January 2002.
[76] Jelger、C.及びT.ノエル、 "IPv6の（MSSMSv6）用モバイルSSMソースのサポート"、進歩、2002年1月に働いています。
[77] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[77]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、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]ヴィダ、R、コスタ、L、Fdida、S. "M-HBH - マルチキャストにおける効率的なモビリティ管理"、PROC。 NGC '02の、頁105-112、ACMプレス2002。
[79] A. O'Neill "Mobility Management and IP Multicast", Work in Progress, July 2002.
[79] A.オニール「モビリティ・マネジメントおよびIPマルチキャスト」、進歩、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]シュミット、T. C.及びWaehlisch、M. "のMIPv6に拡張SSM - 問題、解決及び改良"、科学技術、11（2）、147-152頁における計算方法。 TERENAネットワーク会議、ポズナン、2005年5月から選ば論文。
[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]シュミット、TC、Waehlisch、M.、およびWodarz、M. "ソース固有マルチキャストでモバイル送信者を支援高速適応ルーティング"、通信システム、43（1）、頁95-108、2009のhttp：// dx.doi.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.
K.川原及びI.チョンに[82]リー、H.、ハン、S.及び香港、J.「ソース固有マルチキャストにおけるソースモビリティのための効率的なメカニズム」、編、「ICOIN2006の議事録」、LNCS体積。 3961、頁82-91、シュプリンガー・フェアラーク、ベルリン、ハイデルベルグ、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.とビダ、R. "ホストアイデンティティ固有マルチキャスト"、ネットワークとサービスICNS、IEEEプレス、頁1-1、2007年6月の第3回国際会議。
[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. "マルチキャスト受信および送信者のアクセス制御とモバイルIP環境への適用：調査"、IEEE Commの。調査＆チュートリアル、7（2）、頁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、モンテネグロ、G. "IPv6におけるセキュリティグループ管理暗号的ベースアドレスを持つ"、PROC。第八IEEE国際SYMP。コンプ。そしてCOMMUN、トルコ、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]シュミット、TC、Waehlisch、M.、キリスト、O.、およびHEGE、G. "AuthoCast - マルチキャスト送信者認証のためのモビリティ対応プロトコル・フレームワーク"、セキュリティおよび通信ネットワーク、1（6）、495頁-509、2008。
[87] Fenner, B., Holbrook, H., and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", Work in Progress, November 2001.
[87]フェナー、B.、ホルブルック、H.、およびI. Kouvelas、 "インタレストプロトコル（MSNIP）のマルチキャストソースの通知"、進歩、2001年11月の作品。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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".
モバイルマルチキャストのための問題空間を探索の作業は、彼らの初期の文書「モバイルマルチキャストクライアントの要件」内グレッグ・デイリーとGopi Kurupによって開拓されています。
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. Almeroth、ラクランアンドリュー、ヤリArkko、セドリックBAUDOIN、ハンス・L.サイコン、ホイトウ氏、マーシャルユーバンクス、志剛黄、クリストフJelger、アンドレイGutov、ラジーブKoodli、マークPalkowに感謝したいと思います、クレイグ・パートリッジ、IMED Romdhani、Heshamソリマン、デイヴ・ターラー、そして彼の頻繁かつ徹底的なアドバイスをスティグ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.シュミット部門Informatikはハンブルク大学、ベルリンのTor 7 D-20099ハンブルク、ドイツ電話：+ 49-40-42875-8157 Eメール：schmidt@informatik.haw-hamburg.de
Matthias Waehlisch link-lab Hoenower Str. 35 D-10318 Berlin, Germany EMail: mw@link-lab.net
マティアスWaehlischリンク・ラボHoenowerのStr。 35 D-10318ベルリン、ドイツEメール：mw@link-lab.net
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, UK EMail: gorry@erg.abdn.ac.uk
エンジニアリングのGodred Fairhurst学校、アバディーン、アバディーン、AB24 3UE、英国の大学Eメール：gorry@erg.abdn.ac.uk