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
Internet Research Task Force (IRTF) T. Schmidt
Request for Comments: 5757 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab
G. Fairhurst
University of Aberdeen
February 2010
Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
移动IP版本6（MIPv6）中的多播移动：问题陈述和简要调查
Abstract
摘要
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
本文档讨论当前对IP层多播的移动性扩展。它描述了一般移动组通信产生的问题、多播侦听器移动的情况以及使用任何源多播和源特定多播的移动发送者的问题。总结了固定IPv6网络中组播路由和部署问题的特点。针对无线领域中的相关技术，调查了基础网络接入的特定特性和相互作用。它概述了多播移动性的主要方法，以及对移动多播问题和解决方案空间的全面探索。本文档最后给出了标准化初始步骤的概念路线图，供未来移动多播协议设计者使用。本文档是IP移动性优化（MobOpts）研究组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the MobOpts Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究工作组（IRTF）MobOpts研究小组的共识。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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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]很快导致了Deering的主机组模型[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]中的移动性在移动IPv6 RFCs[5][6]中进行了标准化，它解决了在无线域之间移动时网络层发生变化的情况。MIPv6[5]仅粗略定义了使用远程订阅方法或通过家乡代理（HA）的双向隧道的移动节点（MN）的多播移动性。远程订阅存在依赖多播路由以适应切换的缓慢切换问题。由于三角转发，双向隧道引入了低效的开销和延迟，即，数据包不是在最短路径上传输，而是通过归属代理进行路由。因此，这些方法尚未针对大规模部署进行优化。未来互联网的移动多播服务应以可预测且有限的成本提供“接近最优”的路由，提供健壮性和符合实时媒体分发的服务质量。
Intricate multicast routing procedures are not easily extensible to satisfy the requirements for mobility. A client subscribed to a group while performing mobility handovers requires the multicast traffic to follow to its new location; a mobile source needs the entire delivery tree to comply with or to adapt to its changing position. Significant effort has already been invested in protocol designs for mobile multicast receivers; only limited work has been dedicated to multicast source mobility, which poses the more delicate problem [65].
复杂的多播路由过程不容易扩展以满足移动性的要求。在执行移动性切换时订阅组的客户端要求多播流量跟随到其新位置；移动源需要整个交付树来遵守或适应其不断变化的位置。移动多播接收机的协议设计已经投入了大量的精力；只有有限的工作致力于多播源移动性，这带来了更微妙的问题[65]。
In multimedia conference scenarios, games, or collaborative environments, each member commonly operates as a receiver and as a sender for multicast group communication. In addition, real-time communication such as conversational voice or video places severe temporal requirements on mobility protocols: Typical seamless handover scenarios are expected to limit disruptions or delay to less than 100 - 150 ms [7]. Jitter disturbances should not exceed 50 ms. Note that 100 ms is about the duration of a spoken syllable in real-time audio. This problem statement is intended to also be applicable to a range of other scenarios with a range of delivery requirements appropriate to the general Internet.
在多媒体会议场景、游戏或协作环境中，每个成员通常作为多播组通信的接收者和发送者进行操作。此外，实时通信（如对话语音或视频）对移动协议提出了严格的时间要求：典型的无缝切换场景预计会将中断或延迟限制在100-150毫秒以内[7]。抖动干扰不应超过50毫秒。请注意，100毫秒大约是实时音频中一个语音音节的持续时间。本问题陈述旨在也适用于具有适用于通用互联网的一系列交付要求的一系列其他场景。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by the Research Group members active in the specific area of work. In addition, this document has been comprehensively reviewed by multiple active contributors to the IETF MEXT, MBONED, and PIM Working Groups.
本文件代表了MobOpts研究小组的共识。该报告已由活跃于特定工作领域的研究小组成员审查。此外，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 *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
+------+ +------+
| 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：移动场景-直接连接到固定接入路由器（AR）或通过本地接入路由器（LAR）连接的移动节点（MN）
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.
多播路由动态地适应参与多播会话的发送方和接收方位置处的网络拓扑，然后在移动性下可能会发生变化。但是，根据拓扑结构和使用的协议，当前的多播路由协议可能需要接近秒的时间才能在接收器或发送器位置发生变化后收敛。这太慢了，无法支持交互式或实时媒体会话的无缝切换。实际的时间行为在很大程度上取决于所使用的多播路由协议、路由器的配置以及当前分发树的几何结构。重新调整路由（即部分更改或完全重建多播树）的移动性方案被迫遵守协议收敛的时间尺度。具体而言，它需要考虑移动节点可能的快速移动，因为这可能发生在比公共协议状态更新高得多的速率。
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
使用IP组播的主机的移动性会影响提供给更高层协议的服务。IP层多播数据包分发是一种绑定到网络的不可靠服务
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 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 在最简单的场景中，移动节点的订阅组的一些或全部的分组已经由新网络中的一个或多个其他组成员接收，并且因此多播流在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:
因此，实现无缝多播侦听器切换的问题有三个方面：
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查询。多宿MNs可通过使用“先通后断”的方法确保平滑切换，该方法要求每个接口订阅，并通过在预先选择的IPv6接口上操作的MLD连接来实现。
Encapsulation on the path between the upstream router and the receiver may result in MTU size conflicts, since path-MTU discovery is often not supported for multicast and can reduce scalability in networks with many different MTU sizes or introduce potential denial-of-service vulnerabilities (since the originating addresses of ICMPv6 messages cannot be verified for multicast). In the absence of fragmentation at tunnel entry points, this may prevent the group from being forwarded to the destination.
上游路由器和接收器之间路径上的封装可能会导致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-casting），这可能是由网络节点上的复制隧道启动或冗余转发引起的。
There are additional implications for the infrastructure: In changing its point of attachment, an exclusive mobile receiver may initiate forwarding of a group in the new network and termination of a group distribution service in the previous network. Mobility management may impact multicast routing by, e.g., erroneous subscriptions following predictive handover operations, or slow traffic termination at leaf nodes resulting from MLD query timeouts, or by departure of the MN from a previous network without leaving the subscribed groups. Finally, packet duplication and reordering may follow a change of topology.
基础设施还有其他含义：在更改其连接点时，专用移动接收器可能会在新网络中发起组转发，并在先前网络中终止组分发服务。移动性管理可能会影响多播路由，例如，预测切换操作之后的错误订阅，或由于MLD查询超时而导致叶节点处的业务缓慢终止，或通过MN离开先前网络而不离开订阅组。最后，数据包复制和重新排序可能随拓扑结构的变化而变化。
A node submitting data to an ASM group either forms the root of a source-specific shortest path tree (SPT), distributing data towards a rendezvous point (RP) or receivers, or it forwards data directly down a shared tree, e.g., via encapsulated PIM Register messages, or using bidirectional PIM routing. Native forwarding along source-specific delivery trees will be bound to the source's topological network address, due to reverse path forwarding (RPF) checks. A mobile multicast source moving to a new subnetwork is only able to either inject data into a previously established delivery tree, which may be a rendezvous-point-based shared tree, or to (re-)initiate the construction of a multicast distribution tree for its new network location. In the latter case, the mobile sender will have to proceed without knowing whether the new tree has regained ability to forward traffic to the group, due to the decoupling of sender and receivers.
向ASM组提交数据的节点要么形成源特定最短路径树（SPT）的根，向集合点（RP）或接收器分发数据，要么直接向下共享树转发数据，例如通过封装的PIM寄存器消息，或者使用双向PIM路由。由于反向路径转发（RPF）检查，沿源特定传递树的本机转发将绑定到源的拓扑网络地址。移动多播源移动到新的子网时，只能将数据注入到先前建立的传递树（可能是基于集合点的共享树）中，或者（重新）为其新的网络位置启动多播分发树的构造。在后一种情况下，由于发送方和接收方的分离，移动发送方将不得不在不知道新树是否已恢复向组转发流量的能力的情况下继续进行。
A mobile multicast source must therefore provide address transparency at two layers: To comply with RPF checks, it has to use an address within the source field of the IPv6 basic header, which is in topological agreement with the employed multicast distribution tree. For application transparency, the logical node identifier, commonly the HoA, must be presented as the packet source address to the transport layer at the receiver side.
因此，移动多播源必须在两层提供地址透明性：为了符合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时，通过双向共享域生成树透明地提供域内移动性，消除了到相应RP的隧道的需要（与IPv4相比，IPv6 ASM多播组与特定RP/RPs相关联）。
Issues arise in inter-domain multicast, whenever notification of source addresses is required between distributed instances of shared trees. A new CoA acquired after a mobility handover will necessarily be subject to inter-domain record exchange. In the presence of an embedded rendezvous point address [24], e.g., the primary rendezvous point for inter-domain PIM-SM will be globally appointed, and a newly attached mobile source can contact the RP without prior signaling (like a new source) and transmit data in the PIM register tunnel. Multicast route optimization (e.g., PIM "shortcuts") will require multicast routing protocol operations equivalent to serving a new source.
每当共享树的分布式实例之间需要通知源地址时，域间多播就会出现问题。在移动性切换后获得的新CoA必须进行域间记录交换。在存在嵌入式会合点地址[24]的情况下，例如，域间PIM-SM的主会合点将被全局指定，并且新连接的移动源可以在没有事先信令的情况下联系RP（如新源）并在PIM寄存器隧道中传输数据。多播路由优化（例如，PIM“快捷方式”）将要求多播路由协议操作相当于为新源提供服务。
Source-Specific Multicast has been designed for multicast senders with static source addresses. The source addresses in a client subscription to an SSM group is directly used to route identification. Any SSM subscriber is thus forced to know the topological address of the contributor to the group it wishes to join. The SSM source identification becomes invalid when the topological source address changes under mobility. Hence, client implementations of SSM source filtering must be MIPv6 aware in the sense that a logical source identifier (HoA) is correctly mapped to its current topological correspondent (CoA).
源特定多播是为具有静态源地址的多播发送者设计的。SSM组的客户端订阅中的源地址直接用于路由标识。因此，任何SSM订户都必须知道其希望加入的组的贡献者的拓扑地址。当拓扑源地址在移动性下发生变化时，SSM源标识无效。因此，SSM源筛选的客户机实现必须在逻辑源标识符（HoA）正确映射到其当前拓扑对应（CoA）的意义上意识到MIPv6。
As a consequence, source mobility for SSM requires a conceptual treatment beyond the problem scope of mobile ASM. A listener subscribes to an (S,G) channel membership and routers establish an (S,G)-state shortest path tree rooted at source S; therefore, any change of source addresses under mobility requires state updates at all routers on the upstream path and at all receivers in the group. On source handover, a new SPT needs to be established that will share paths with the previous SPT, e.g., at the receiver side. As the principle of multicast decoupling of a sender from its receivers holds for SSM, the client updates needed for switching trees become a severe burden.
因此，SSM的源移动性需要一个概念性的处理，超出了移动ASM的问题范围。侦听器订阅（S，G）信道成员资格，路由器在源S上建立（S，G）状态最短路径树；因此，在移动性下源地址的任何更改都需要在上行路径上的所有路由器和组中的所有接收器处进行状态更新。在源切换时，需要建立一个新的SPT，该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多播部署在过去15年中进展缓慢，尽管所有主要路由器供应商和操作系统都提供支持多播的实现[27]。虽然许多（有围墙的）域或企业网络运行点对多点服务，但IP多播的推出目前仅限于公共域间场景[28]。在组通信服务应该驻留的适当层上出现了争议，研究界的焦点转向了应用层多播。关于“效率与部署复杂性”的争论现在与移动多播领域重叠[29]。Garyfalos和Almeroth[30]源自相当普遍的原则，即当引入移动性时，IP层和应用层多播之间的性能差距在不同的度量中会扩大到四分之一。
Facing deployment complexity, it is desirable that any solution for mobile multicast does not change the routing protocols. Mobility management in such a deployment-friendly scheme should preferably be handled at edge nodes, preserving a mobility-agnostic routing infrastructure. Future research needs to search for such simple, infrastructure-transparent solutions, even though there are reasonable doubts as to whether this can be achieved in all cases.
面对部署的复杂性，任何移动多播解决方案都不改变路由协议是可取的。这种部署友好方案中的移动性管理最好在边缘节点处理，以保持移动性无关的路由基础设施。未来的研究需要寻找这种简单的、基础设施透明的解决方案，尽管对于是否在所有情况下都能实现这一点存在合理的怀疑。
Nevertheless, multicast services in mobile environments may soon become indispensable, when multimedia distribution services such as Digital Video Broadcasting for Handhelds (DVB-H) [31][32] or IPTV develop a strong business case for portable IP-based devices. As IP mobility becomes an important service and as efficient link utilization is of a larger impact in costly radio environments, the evolution of multicast protocols will naturally follow mobility constraints.
然而，移动环境中的多播服务可能很快就会变得不可或缺，因为手持设备的数字视频广播（DVB-H）[31][32]或IPTV等多媒体分发服务为基于IP的便携式设备提供了强有力的商业案例。随着IP移动性成为一项重要的服务，并且高效的链路利用率在昂贵的无线环境中具有更大的影响，多播协议的发展自然会受到移动性的限制。
Multicast distribution trees have been studied from a focus of network efficiency. Grounded on empirical observations, Chuang and Sirbu [33] proposed a scaling power-law for the total number of links in a multicast shortest path tree with m receivers (proportional to m^k). The authors consistently identified the scale factor to attain the independent constant k = 0.8. The validity of such universal, heavy-tailed distribution suggests that multicast shortest path trees are of self-similar nature with many nodes of small, but few of higher degrees. Trees consequently would be shaped tall rather than wide.
从网络效率的角度研究了组播分布树。基于经验观察，Chuang和Sirbu[33]提出了一个多播最短路径树中链路总数的缩放幂律，其中有m个接收器（与m^k成比例）。作者一致确定了比例因子，以获得独立常数k=0.8。这种普遍的重尾分布的有效性表明，多播最短路径树具有自相似性质，有许多小节点，但很少有高阶节点。因此，树木的形状应该是高的而不是宽的。
Subsequent empirical and analytical work [34][35] debated the applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. [34] proved that the proposed power law cannot hold for an increasing Internet or very large multicast groups, but is indeed applicable for moderate receiver numbers and the current Internet size of N = 10^5 core nodes. Investigating self-similarity, Janic and Van Mieghem [36] semi-empirically substantiated that multicast shortest path trees in the Internet can be modeled with reasonable accuracy by uniform recursive trees (URTs) [37], provided m remains small compared to N.
随后的实证和分析工作[34][35]讨论了庄和Sirbu标度定律的适用性。Van Mieghem等人[34]证明，所提出的幂律不能适用于不断增加的互联网或非常大的多播组，但确实适用于中等接收器数量和当前互联网大小的N=10^5个核心节点。Janic和Van Mieghem[36]通过对自相似性的研究，半经验地证明了互联网中的多播最短路径树可以通过均匀递归树（URT）[37]以合理的精度进行建模，前提是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
最短路径树的移动性视角关注它们的变化，即由移动引起的拓扑变化的程度。对于接收机，更有趣的是对于信源，这可以作为路由复杂性的特征度量。移动侦听器移动到相邻网络时，只会改变跨越几跳的树枝。源切换步骤生成的源特定多播树不是独立的，而是高度相关的。它们很可能在一个或多个交点处分支到相同的接收器。由于自相似性，植根于任何此类交叉点的持久子树（上一个和下一个分布树）再次表现出缩放律行为，其形状高大，节点的度数主要较低，因此可能会重合。文献[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网络接入技术本机支持点对多点或多播服务也就不足为奇了。无线接入技术固有地支持二级广播/多播，并在频率和带宽有限的共享媒体上运行。
Several aspects need consideration: First, dissimilar network access radio technologies cause distinct group traffic transmissions. There are:
需要考虑几个方面：首先，不同的网络接入无线电技术会导致不同的组流量传输。有：
o connection-less link services of a broadcast type, which mostly are bound to limited reliability;
o 广播类型的无连接链路服务，其可靠性通常有限；
o connection-oriented link services of a point-to-multipoint type, which require more complex control and frequently exhibit reduced efficiency;
o 点对多点类型的面向连接的链路服务，需要更复杂的控制，并且经常表现出降低的效率；
o connection-oriented link services of a broadcast type, which are restricted to unidirectional data transmission.
o 广播类型的面向连接的链路服务，仅限于单向数据传输。
In addition, multicast may be distributed via multiple point-to-point unicast links without the use of a dedicated multipoint radio channel. A fundamental difference between unicast and group transmission arises from power management. Some radio technologies adjust transmit power to be as small as possible based on link-layer feedback from the receiver, which is not done in multipoint mode. They consequently incur a "multicast tax", making multicast less efficient than unicast unless the number of receivers is larger than some threshold.
此外，可以通过多个点对点单播链路来分发多播，而不使用专用的多点无线信道。单播和组传输之间的根本区别在于电源管理。一些无线电技术基于来自接收器的链路层反馈将发射功率调整为尽可能小，这不是在多点模式下完成的。因此，它们会产生“多播税”，使多播比单播效率低，除非接收者的数量大于某个阈值。
Second, point-to-multipoint service activation at the network access layer requires a mapping mechanism from network-layer requests. This function is commonly achieved by L3 awareness, i.e., IGMP/MLD snooping [70] or proxy [38], which occasionally is complemented by Multicast VLAN Registration (MVR). MVR allows sharing of a single multicast IEEE 802.1Q Virtual LAN in the network, while subscribers remain in separate VLANs. This L2 separation of multicast and unicast traffic can be employed as a workaround for point-to-point link models to establish a common multicast link.
其次，网络接入层的点对多点服务激活需要来自网络层请求的映射机制。此功能通常通过L3感知来实现，即IGMP/MLD窥探[70]或代理[38]，偶尔通过多播VLAN注册（MVR）来补充。MVR允许在网络中共享单个多播IEEE 802.1Q虚拟LAN，而订户保留在单独的VLAN中。这种多播和单播通信量的L2分离可以作为点到点链路模型建立公共多播链路的解决方法。
Third, an address mapping between the layers is needed for common group identification. Address resolution schemes depend on framing details for the technologies in use, but commonly cause a significant address overlap at the lower layer (i.e., more than one IP multicast group address is sent using the same L2 address).
第三，层之间的地址映射需要用于公共组标识。地址解析方案取决于所用技术的帧细节，但通常会在较低层造成明显的地址重叠（即，使用相同的L2地址发送多个IP多播组地址）。
IEEE 802.11 Wireless Local Area Network (WLAN) is a broadcast network of Ethernet type. This inherits multicast address mapping concepts from 802.3. In infrastructure mode, an access point operates as a repeater, only bridging data between the Base (BSS) and the Extended Service Set (ESS). A mobile node submits multicast data to an access point in point-to-point acknowledged unicast mode (when the ToDS bit is set). An access point receiving multicast data from an MN simply repeats multicast frames to the BSS and propagates them to the ESS as unacknowledged broadcast. Multicast frames received from the ESS receive similar treatment.
IEEE 802.11无线局域网（WLAN）是一种以太网类型的广播网络。这继承了802.3中的多播地址映射概念。在基础设施模式下，接入点作为中继器运行，仅在基站（BSS）和扩展服务集（ESS）之间桥接数据。移动节点以点对点确认单播模式（设置ToDS位时）向接入点提交多播数据。从MN接收多播数据的接入点只是将多播帧重复到BSS，并将其作为未确认广播传播到ESS。从ESS接收的多播帧接受类似的处理。
Multicast frame delivery has the following characteristics:
多播帧传递具有以下特征：
o As an unacknowledged service, it offers limited reliability. The loss of frames (and hence packets) arises from interference, collision, or time-varying channel properties.
o 作为未确认的服务，它提供的可靠性有限。帧（以及数据包）的丢失是由干扰、冲突或时变信道特性引起的。
o Data distribution may be delayed, as unicast power saving synchronization via Traffic Indication Messages (TIM) does not operate in multicast mode. Access points buffer multicast packets while waiting for a larger Delivery TIM (DTIM) interval, whenever stations use the power saving mode.
o 数据分发可能会延迟，因为通过业务指示消息（TIM）的单播节能同步不能在多播模式下运行。当站点使用省电模式时，接入点会在等待更大的传输TIM（DTIM）间隔时缓冲多播数据包。
o Multipoint data may cause congestion, because the distribution system floods multicast, without further control. All access points of the same subnet replicate multicast frames.
o 多点数据可能会导致拥塞，因为分发系统会淹没多播，而无需进一步控制。同一子网的所有接入点都复制多播帧。
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
IEEE 802.16全球微波接入互操作性（WIMAX）结合了一系列面向连接的无线传输服务，可在单跳点对多点（PMP）或网状网络中运行
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.
模式后者不支持多点传输，目前没有部署。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交换机运行，基于CID进行切换。存在两种用于移动接入场景的IPv6链路模型：用于IP over Ethernet Circuit Switched（CS）[39]的共享IPv6前缀在共享前缀内提供媒体访问控制（MAC）分离。第二种点对点链路模型[40]建议在IPv6聚合子层[41]中使用，该模型将移动节点的每个连接视为单个链路。当使用共享介质时，点到点链路模型与IP层的一致组分布冲突（参考第4.1节MVR作为解决方法）。
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分配给组中的所有用户站。IPv6多播地址映射到这些16位ID的方法是，在保持作用域字段的同时复制4个最低位，或者利用从以太网CS上的多播派生的8个最低位[42]。为了选择组成员，基站可以实现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时，这些将转发到上游接入路由器。接入路由器（或以太网上IP CS的基站）可以通过将下行多播分组馈送到多播服务信道来发送下行多播分组。在接收时，用户站无法在链路层区分多播和单播流。
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 由于ID空间较短，可能会发生不同多播组的CID冲突。这可能导致多个点对多点组共享相同的CID，从而降低接收器过滤不需要的L2通信量的能力。
o The point-to-point link model for mobile access contradicts a consistent mapping of IP-layer multicast onto 802.16 point-to-multipoint services.
o 移动接入的点对点链路模型与IP层多播到802.16点对多点服务的一致映射相矛盾。
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）系统架构跨越电路交换（CS）和分组交换（PS）域，后者的通用分组无线业务（GPRS）包含IP多媒体子系统（IMS）[44]。3GPP-PS是面向连接的，并且基于分组数据协议（PDP）上下文的概念。PDP定义移动终端和网关GPRS支持节点（GGSN）之间的点对点链路。Internet服务类型为PPP、IPv4和IPv6，其中IPv6地址分配建议将前缀与每个（主要）PDP上下文相关联[45]。
In Universal Mobile Telecommunications System (UMTS) Rel. 6, the IMS was extended to include Multimedia Broadcast and Multicast Services (MBMS). A point-to-multipoint GPRS connection service is operated on radio links, while the gateway service to Internet multicast is handled at the IGMP/MLD-aware GGSN. Local multicast packet distribution is used within the GPRS IP backbone resulting in the common double encapsulation at GGSN: global IP multicast datagrams over Generic Tunneling Protocol (GTP) (with multipoint TID) over local IP multicast.
在通用移动通信系统（UMTS）中。6、IMS扩展到包括多媒体广播和多播服务（MBMS）。点对多点GPRS连接服务在无线链路上运行，而互联网多播网关服务在支持IGMP/MLD的GGSN上处理。在GPRS IP主干网内使用本地多播数据包分发，从而在GGSN实现常见的双重封装：通用隧道协议（GTP）上的全局IP多播数据报（具有多点TID）本地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 没有立即的第2层源到目的地转换，导致所有多播流量在GGSN传输。
o As GGSNs commonly are regional, distant entities, triangular routing and encapsulation may cause a significant degradation of efficiency.
o 由于GGSN通常是区域性的、遥远的实体，三角形路由和封装可能会导致效率显著降低。
In 3GPP2, the MBMS has been extended to the Broadcast and Multicast Service (BCMCS) [46], which on the routing layer operates very similar to MBMS. In both 3GPP and 3GPP2, multicast can be sent using either point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and
在3GPP2中，MBMS已经扩展到广播和多播服务（BCMCS）[46]，其在路由层上的操作非常类似于MBMS。在3GPP和3GPP2中，可以使用点对点（PTP）或点对多点（PTM）隧道发送多播，以及
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.
支持在PTP和PTM之间切换。PTM使用单向公共信道，在未确认模式下运行，无需调整功率水平，也无需报告丢失的数据包。
Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional physical layer broadcasting specification for the efficient delivery of broadband and IP-encapsulated data streams, and is published as an ETSI standard [47] (see http://www.dvb-h.org). This uses multiprotocol encapsulation (MPE) to transport IP packets over an MPEG-2 Transport Stream (TS) with link forward error correction (FEC). Each stream is identified by a 13-bit TS ID (PID), which together with a multiplex service ID, is associated with IPv4 or IPv6 addresses [48] and used for selective traffic filtering at receivers. Upstream channels may complement DVB-H using other transmission technologies. The IP Datacast Service, DVB-IPDC [31], specifies a set of applications that can use the DVB-H transmission network.
用于手持设备的数字视频广播（DVB-H）是一种单向物理层广播规范，用于高效传送宽带和IP封装数据流，并作为ETSI标准发布[47]（参见http://www.dvb-h.org). 这使用多协议封装（MPE）在具有链路前向纠错（FEC）的MPEG-2传输流（TS）上传输IP数据包。每个流由13位TS ID（PID）标识，该ID与多路复用服务ID一起与IPv4或IPv6地址相关联[48]，并用于在接收器处进行选择性流量过滤。上行信道可以使用其他传输技术来补充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.
多播分发服务通过将组映射到适当的PID来定义，PID由IP封装器管理[49]。为了增加灵活性并避免冲突，这种地址解析通过在自包含的MPEG-2 TS中提供的动态表来实现。在预见小区ID、网络ID或传输流ID变化的意义上支持移动性[50]。因此，多播接收器需要在同步阶段重新定位其订阅的多播服务，并更新其服务过滤器。其切换决策可能取决于服务可用性。主动服务订阅（多播加入）需要在IP封装器/DVB-H网关处启动，而在纯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]。这些标准也用于单向和双向卫星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传输网络中，多播分发服务通过将组映射到适当的PID来定义，PID由IP封装器管理[49]。解决问题的方法类似于
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的问题与ULE类似（除了PID不能作为过滤流量的机制）。提供双向连接的网络可允许主动服务订阅（多播加入）从上游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的移动服务传输需要作为互联网上下文中第2层多播服务传输的抽象[54]，并在[55]中规定。
MIH needs to assist in more than service discovery: There is a need for complex, media-dependent multicast adaptation, a possible absence of MLD signaling in L2-only transfers, and requirements originating from predictive handovers. A multicast mobility services transport needs to be sufficiently comprehensive and abstract to initiate a seamless multicast handoff at network access.
MIH需要协助的不仅仅是服务发现：需要复杂的、媒体相关的多播自适应，在仅L2传输中可能没有MLD信令，以及来自预测性切换的需求。组播移动服务传输需要足够全面和抽象，以便在网络接入时发起无缝组播切换。
Functions required for MIH include:
MIH所需的功能包括：
o Service discovery. o Service context transformation. o Service context transfer. o Service invocation.
o 服务发现。o服务上下文转换。o服务上下文传输。o服务调用。
Three approaches to mobile multicast are common [56]:
移动多播有三种常见的方法[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
o 双向隧道，其中移动节点通过其归属代理隧道所有多播数据。这个基本的多播解决方案隐藏了所有的移动，并导致静态多播树。它可以被移动多播透明地使用
listeners and sources, at the cost of triangular routing and possibly significant performance degradation from widely spanned data tunnels.
侦听器和数据源，代价是三角路由，并且可能会因数据隧道的广泛分布而导致性能显著下降。
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].
有针对基于主机的移动性的代理辅助切换的建议，补充了Fast MIPv6（FMIPv6）[19]、M-FMIPv6[57][58]和分层MIPv6（HMIPv6）[20]、M-HMIPv6[59]的单播实时移动性基础设施以及上下文传输[60]，这些已在[25][61]中进行了深入分析。
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）之间的单播隧道以及连接当前MAG和MN的点对点链路组成。因此，PMIPv6域继承了接收站点跨越隧道的MTU大小问题。此外，可以确定两个雪崩问题点：可能需要LMA将数据隧道到大量MAG，而MAG可能需要通过单个点到点链路将相同的多播流转发到多个MN[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
MN操作预测切换（例如，使用FMIPv6）可通过在切换前提交提前完成的消息，在离开前一网络时加速多播服务终止。MLD路由器查询将允许在错误预测的情况下恢复多播转发状态（即，预期移动到尚未发生的网络）。反向上下文传输可能会以其他方式确保发出休假信号。Jelger和Noel[71]针对HA是多播路由器的特殊情况引入了进一步的优化。收到一条已完成的消息
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的点对点链路），不应启动标准MLD成员资格查询（随后超时）。这种对点到点链路的明确处理将减少通信量并加速控制协议。显式跟踪将导致相同的协议行为。
While away from home, an MN may wish to rely on a proxy or "standby" multicast membership service, optionally provided by an HA or proxy router. Such functions rely on the ability to restart fast packet forwarding; it may be desirable for the proxy router to remain part of the multicast delivery tree, even when transmission of group data is paused. To enable such proxy control, the authors in [71] propose an extension to MLD, introducing a Listener Hold message that is exchanged between the MN and the HA. This idea was developed in [59] to propose multicast router attendance control, allowing for a general deployment of group membership proxies. Some currently deployed IPTV solutions use such a mechanism in combination with a recent (video) frame buffer, to enable fast channel switching between several IPTV multicast flows (zapping).
在离家时，MN可能希望依赖代理或“备用”多播成员服务，可选地由HA或代理路由器提供。这些功能依赖于重启快速数据包转发的能力；代理路由器可能希望保持多播传送树的一部分，即使在组数据的传输暂停时也是如此。为了启用这种代理控制，[71]中的作者提出了对MLD的扩展，引入了在MN和HA之间交换的侦听器保持消息。这个想法在[59]中发展起来，提出了多播路由器的出勤控制，允许组成员代理的一般部署。一些当前部署的IPTV解决方案将这种机制与最近的（视频）帧缓冲区结合使用，以实现多个IPTV多播流之间的快速信道切换（切换）。
Solutions for multicast source mobility can be divided into three categories:
多播源移动性解决方案可分为三类：
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）。当仅限于单个域时，该方案相当于双向隧道。针对域间移动组播，作者设计了一种基于隧道或SSM的MRP间数据包骨干分发方案。
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
o 重建分布树。几位作者提出在移动源移动后构建一个全新的分发树，因此必须补偿额外的路由（树构建）延迟。M-HMIPv6[59]将数据隧道到先前建立的树中，该树以移动性锚点为根，以补偿路由延迟，直到协议相关计时器过期。基于范围的移动多播（RBMoM）协议[73]引入了一个额外的多播代理（MA），用于宣传其服务范围。移动源使用最近的MA注册，并通过它传输数据。当移出以前的服务范围时，它
will perform MA discovery, a re-registration and continue data tunneling with a newly established Multicast Agent in its new current vicinity.
将执行MA发现、重新注册，并在其新的当前附近使用新建立的多播代理继续数据隧道。
o Tree Modification Schemes. In the case of DVMRP routing, Chang and Yen [74] propose an algorithm to extend the root of a given delivery tree for incorporating a new source location in ASM. The authors rely on a complex additional signaling protocol to fix DVMRP forwarding states and heal failures in the reverse path forwarding (RPF) checks.
o 树修改方案。在DVMRP路由的情况下，Chang和Yen[74]提出了一种算法来扩展给定传递树的根，以便在ASM中合并新的源位置。作者依靠一个复杂的附加信令协议来修复DVMRP转发状态并修复反向路径转发（RPF）检查中的故障。
The shared tree approach of [72] has been extended to support SSM mobility by introducing the HoA address record to the Mobility-aware Rendezvous Points. The MRPs operate using extended multicast routing tables that simultaneously hold the HoA and CoA and thus can logically identify the appropriate distribution tree. Mobility thus may reintroduce the concept of rendezvous points to SSM routing.
[72]中的共享树方法已经扩展，通过将HoA地址记录引入移动感知集合点来支持SSM移动。MRP使用扩展的多播路由表进行操作，这些多播路由表同时包含HoA和CoA，因此可以在逻辑上识别适当的分发树。因此，移动性可能会将集合点的概念重新引入SSM路由。
Approaches for reconstructing SPTs in SSM rely on a client notification to establish new router state. They also need to preserve address transparency for the client. Thaler [75] proposed introducing a binding cache and providing source address transparency analogous to MIPv6 unicast communication. Initial session announcements and changes of source addresses are distributed periodically to clients via an additional multicast control tree rooted at the home agent. Source tree handovers are then activated on listener requests.
在SSM中重建SPT的方法依赖于客户端通知来建立新的路由器状态。他们还需要为客户保持地址的透明度。Thaler[75]建议引入绑定缓存，并提供类似于MIPv6单播通信的源地址透明性。初始会话通知和源地址的更改通过根在归属代理的附加多播控制树定期分发给客户端。然后在侦听器请求时激活源树切换。
Jelger and Noel [76] suggest handover improvements employing anchor points within the source network, supporting continuous data reception during client-initiated handovers. Client updates are triggered out of band, e.g., by Source Demand Routing (SDR) / Session Announcement Protocol (SAP) [77]. Receiver-oriented tree construction in SSM thus remains unsynchronized with source handovers.
Jelger和Noel[76]建议在源网络中使用锚定点来改进切换，支持在客户端发起的切换期间连续接收数据。客户端更新在带外触发，例如，通过源请求路由（SDR）/会话公告协议（SAP）[77]。因此，SSM中面向接收器的树结构与源切换保持不同步。
To address the synchronization problem at the routing layer, several proposals have focused on direct modification of the distribution trees. A recursive scheme may use loose unicast source routes with branch points, based on a multicast Hop-by-Hop protocol. Vida et al. [78] optimized SPT for a moving source on the path between the source and first branching point. O'Neill [79] suggested a scheme to overcome RPF check failures that originate from multicast source address changes with a rendezvous point scenario by introducing extended routing information, which accompanies data in a Hop-by-Hop option "RPF redirect" header. The Tree Morphing approach of Schmidt
为了解决路由层的同步问题，有几项建议侧重于直接修改分发树。递归方案可以基于逐跳多播协议使用带有分支点的松散单播源路由。Vida等人[78]在源和第一个分支点之间的路径上优化了移动源的SPT。O'Neill[79]提出了一种方案，通过引入扩展路由信息（随逐跳选项“RPF redirect”报头中的数据）来克服因多播源地址更改而导致的RPF检查失败，该信息来自集合点场景。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.
Waehlisch[80]使用源路由扩展先前建立的SPT的根，从而在逐跳选项报头中注入路由器状态更新。使用扩展的RPF检查，拉长的树自动启动快捷方式，并平滑地减少到一个新的SPT，该SPT植根于重新定位的源。该协议的一个增强版本放弃了初始源路由，可以证明它符合快速源移动[81]。Lee等人[82]介绍了一种状态更新机制，用于重用已建立的多播树的主要部分。作者从最初建立的分发状态开始，以移动源的主代理为中心。离开其家庭网络的移动源将向其家庭代理发送路径上的多播转发状态更新信号，并且随后根据移动源的新CoA沿着先前的分发树发送分发状态。然后，多播数据打算通过延伸和以归属代理为中心的更新树，使用三角形路由在本地流动。基于主机标识协议标识符，Kovacshazi和Vida[83]引入了保持独立于IP地址的多播路由状态。根据类似的缩放定律参数，这些状态的一部分可以在源地址更改后重新使用。
This document discusses multicast extensions to mobility. It does not define new methods or procedures. Security issues arise from source address binding updates, specifically in the case of source-specific multicast. Threats of hijacking unicast sessions will result from any solution jointly operating binding updates for unicast and multicast sessions.
本文档讨论移动的多播扩展。它没有定义新的方法或过程。源地址绑定更新会产生安全问题，特别是在源特定多播的情况下。任何联合操作单播和多播会话绑定更新的解决方案都会造成劫持单播会话的威胁。
Multicast protocols exhibit a risk of network-based traffic amplification. For example, an attacker may abuse mobility signaling to inject unwanted traffic into a previously established multicast distribution infrastructure. These threats are partially mitigated by reverse path forwarding checks by multicast routers. However, a multicast or mobility agent that explicitly replicates multicast streams, e.g., Home Agent that n-casts data, may be vulnerable to denial-of-service attacks. In addition to source authentication, a rate control of the replicator may be required to protect the agent and the downstream network.
多播协议具有网络流量放大的风险。例如，攻击者可能滥用移动信令将不需要的通信量注入先前建立的多播分发基础设施。多播路由器的反向路径转发检查部分缓解了这些威胁。然而，显式复制多播流的多播或移动代理，例如n-cast数据的归属代理，可能容易受到拒绝服务攻击。除了源认证之外，还可能需要复制器的速率控制来保护代理和下游网络。
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
移动性协议需要考虑对认证、授权和计费（AAA）的影响和要求。当使用一个移动网络时，MN可能已被授权接收特定的多播组，但当连接到不同的网络时，这可能无效。通常，MN的AAA关联可以在附件之间改变，或者可以在网络（重新）关联之前单独选择。最合适的网络路径可能是
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绑定。
Admission control issues may arise when new CoA source addresses are introduced to SSM channels [84]. Due to lack of feedback, the admission [85] and binding updates [86] of mobile multicast sources require autonomously verifiable authentication. This can be achieved by, for instance, Cryptographically Generated Addresses (CGAs).
当新的CoA源地址引入SSM信道时，可能会出现准入控制问题[84]。由于缺乏反馈，移动多播源的接纳[85]和绑定更新[86]需要自主验证的身份验证。例如，这可以通过加密生成地址（CGA）来实现。
Modification to IETF protocols (e.g., routing, membership, session announcement, and control) as well as the introduction of new entities, e.g., multicast mobility agents, can introduce security vulnerabilities and require consideration of issues such as authentication of network entities, methods to mitigate denial of service (in terms of unwanted network traffic, unnecessary consumption of router/host resources and router/host state/buffers). Future solutions must therefore analyze and address the security implications of supporting mobile multicast.
修改IETF协议（如路由、成员资格、会话公告和控制）以及引入新实体（如多播移动代理）可能会引入安全漏洞，并需要考虑网络实体的身份验证、缓解拒绝服务的方法等问题（在不必要的网络流量、路由器/主机资源和路由器/主机状态/缓冲区的不必要消耗方面）。因此，未来的解决方案必须分析和解决支持移动多播的安全影响。
This document is intended to provide a basis for the future design of mobile IPv6 multicast methods and protocols by:
本文档旨在通过以下方式为移动IPv6多播方法和协议的未来设计提供基础：
o providing a structured overview of the problem space that multicast and mobility jointly generate at the IPv6 layer;
o 提供多播和移动在IPv6层共同产生的问题空间的结构化概述；
o referencing the implications and constraints arising from lower and upper layers and from deployment;
o 参考下层和上层以及部署产生的影响和限制；
o briefly surveying conceptual ideas of currently available solutions;
o 简要调查当前可用解决方案的概念想法；
o including a comprehensive bibliographic reference base.
o 包括一个全面的参考书目库。
It is recommended that future steps towards extending mobility services to multicast proceed to first solve the following problems:
建议未来将移动服务扩展到多播的步骤首先解决以下问题：
1. Ensure seamless multicast reception during handovers, meeting the requirements of mobile IPv6 nodes and networks. Thereby addressing the problems of home subscription without n-tunnels, as well as native multicast reception in those visited networks, which offer a group communication service.
1. 在切换过程中确保无缝多播接收，满足移动IPv6节点和网络的要求。从而解决了没有n隧道的家庭订阅问题，以及在提供组通信服务的访问网络中的本地多播接收问题。
2. Integrate multicast listener support into unicast mobility management schemes and architectural entities to define a consistent mobility service architecture, providing equal support for unicast and multicast communication.
2. 将多播侦听器支持集成到单播移动性管理方案和体系结构实体中，以定义一致的移动性服务体系结构，为单播和多播通信提供同等支持。
3. Provide basic multicast source mobility by designing address duality management at end nodes.
3. 通过在终端节点设计地址二元性管理，提供基本的多播源移动性。
An IP multicast source transmits data to a group of receivers without requiring any explicit feedback from the group. Sources therefore are unaware at the network layer of whether any receivers have subscribed to the group, and unconditionally send multicast packets that propagate in the network to the first-hop router (often known in PIM as the designated router). There have been attempts to implicitly obtain information about the listening group members, e.g., extending an IGMP/MLD querier to inform the source of the existence of subscribed receivers. Multicast Source Notification of Interest Protocol (MSNIP) [87] was such a suggested method that allowed a multicast source to query the upstream designated router. However, this work did not progress within the IETF mboned working group and was terminated by the IETF.
IP多播源向一组接收器发送数据，而不需要该组的任何明确反馈。因此，源在网络层不知道是否有任何接收器订阅了该组，并且无条件地将在网络中传播的多播分组发送到第一跳路由器（在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报告被提交到同一组，因此可以由源监控，以监控、管理和控制多播组操作。实时流协议（RTSP）RFC 2326提供了可用于控制多播源的会话层控制。但是，RTCP和RTSP信息用于端到端控制，不一定在网络层可见。应用设计者可以选择为其多播应用实现任何适当的控制平面（例如，可靠的多播传输协议），因此网络层移动机制不得假定存在特定的传输或会话协议。
Informative References
资料性引用
[1] Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, ACM Press, June, 1984.
[1] Aguilar，L.“因特网多播的数据报路由”，载于ACM SIGCOMM'84《通信体系结构和协议》，第58-63页，ACM出版社，1984年6月。
[2] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[2] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[3] G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", IEEE Communications Magazine, 35(1), pp. 54-58, January 1997.
[3] G.Xylomenos和G.C.Plyzos，“移动主机的IP多播”，IEEE通信杂志，35（1），第54-58页，1997年1月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering，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] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[6] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[6] Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[7] ITU-T Recommendation, "G.114 - One-way transmission time", Telecommunication Union Standardization Sector, 05/2003.
[7] ITU-T建议，“G.114-单向传输时间”，电信联盟标准化部门，2003年5月。
[8] Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.
[8] Akyildiz，I和Wang，X.，“无线网状网络的调查”，《IEEE通信杂志》，43（9），第23-30页，2005年9月。
[9] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[9] Bhattacharyya，S.，Ed.“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[10] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[10] Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，2006年8月。
[11] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[11] Waitzman，D.，Partridge，C.和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[12] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[12] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.，和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[13] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[13] Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
[14] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[14] Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[15] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[15] Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[16] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16] Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[17] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[17] Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[18] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[18] Arkko，J.，Vogt，C.，和W.Haddad，“移动IPv6的增强路由优化”，RFC 4866，2007年5月。
[19] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[19] Koodli，R.，Ed.，“移动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] Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[21] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[21] Loughney，J.，Ed.，Nakhjiri，M.，Perkins，C.，和R.Koodli，“上下文传输协议（CXTP）”，RFC 4067，2005年7月。
[22] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
[22] N.Montavont、R.Wakikawa、T.Ernst、T.Ng、C.和K.Kuladinhi，“移动IPv6中的多宿分析”，正在进行的工作，2008年5月。
[23] Narayanan, V., Thaler, D., Bagnulo, M., and H. Soliman, "IP Mobility and Multi-homing Interactions and Architectural Considerations", Work in Progress, July 2007.
[23] Narayanan，V.，Thaler，D.，Bagnulo，M.，和H.Soliman，“IP移动性和多主交互与架构考虑”，正在进行的工作，2007年7月。
[24] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[24] Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，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] Schmidt，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] Schmidt，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期刊。关于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）；DVB-H上的IP数据广播：第1阶段规范集”，ETSI TS 102 468；
[32] ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Implementation Guidelines for Mobility)", European Standard (Telecommunications series), November 2004.
[32] ETSI TS 102 611，“数字视频广播（DVB）；DVB-H上的IP数据广播：移动性实施指南”，欧洲标准（电信系列），2004年11月。
[33] Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- Based Approach", Telecommunication Systems, 17(3), 281-297, 2001. Presented at the INET'98, Geneva, Switzerland, July 1998.
[33] Chuang，J.和Sirbu，M.“定价多播通信：基于成本的方法”，电信系统，17（3），281-2972001。在1998年7月于瑞士日内瓦举行的INET'98上提交。
[34] Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of Multicast", IEEE/ACM Trans. Netw., 9(6), pp. 719-732, Dec. 2001.
[34] Van Mieghem，P，Hooghiemstra，G，Hofstad，R.“关于多播的效率”，IEEE/ACM Trans。《网络》，第9（6）页，第719-732页，2001年12月。
[35] Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast trees", IEEE/ACM Trans. Netw., 11(1), 153-165, 2003.
[35] Chalmers，R.C.和Almeroth，K.C.“关于多播树的拓扑”，IEEE/ACM Trans。《网络》，第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.和Van Mieghem，P.“关于多播路由树的性质”，国际公共杂志。《系统》，第19（1）页，第95-114页，2006年2月。
[37] Van Mieghem, P. "Performance Analysis of Communication Networks and Systems", Cambridge University Press, 2006.
[37] Van 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] Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 46052006年8月。
[39] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
[39] Jeon，H.，Jeong，S.，和M.Riegel，“通过IEEE 802.16网络通过以太网传输IP”，RFC 5692，2009年10月。
[40] Shin, M-K., Ed., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[40] Shin，M-K.，Ed.，Han，Y-H.，Kim，S-E.，和D.Premec，“802.16网络中的IPv6部署场景”，RFC 5181，2008年5月。
[41] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[41] Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月。
[42] Kim, S., Jin, J., Lee, S., and S. Lee, "Multicast Transport on IEEE 802.16 Networks", Work in Progress, July 2007.
[42] Kim，S.，Jin，J.，Lee，S.，和S.Lee，“IEEE 802.16网络上的多播传输”，正在进行的工作，2007年7月。
[43] IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area networks Part 16: "Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", New York, February 2006.
[43] IEEE 802.16e-2005:IEEE局域网和城域网标准第16部分：“固定和移动宽带无线接入系统的空中接口——许可频带内固定和移动组合操作的物理和介质接入控制层修正案”，纽约，2006年2月。
[44] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; "IP Multimedia Subsystem (IMS)"; Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007.
[44] 第三代伙伴关系项目；技术规范组服务和系统方面；“IP多媒体子系统（IMS）”；第2阶段，3GPP TS 23.228，Rel。5日以后，2002-2007年。
[45] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[45] Wasserman，M.，Ed.“第三代合作伙伴项目（3GPP）标准中的IPv6建议”，RFC 3314，2002年9月。
[46] 3GPP2, www.3gpp2.org, "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless IP Network, Rev. A.", http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007.
[46] 3GPP2，www.3GPP2.org，“X.S0022-A，cdma2000无线IP网络中的广播和多播服务，Rev.A.”，http://www.3gpp2.org/Public_html/specs/tsgx.cfm，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，“MPEG-2网络上IP数据报的地址解析机制”，RFC 4947，2007年7月。
[49] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[49] Montpetit，M.-J.，Fairhurst，G.，Clausen，H.，Collini Nocker，B.，和H.Linder，“通过MPEG-2网络传输IP数据报的框架”，RFC 4259，2005年11月。
[50] Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in DVB-H", IEEE Comm. Surveys, 8(4), pp. 16-24, 2006.
[50] Yang，X，Vare，J，Owens，T.“DVB-H中切换算法的调查”，IEEE Comm.Surveys，8（4），第16-242006页。
[51] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[51] Fairhurst，G.和B.Collini Nocker，“通过MPEG-2传输流（TS）传输IP数据报的单向轻量封装（ULE）”，RFC 4326，2005年12月。
[52] Fairhurst, G. and B. Collini-Nocker, "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
[52] Fairhurst，G.和B.Collini Nocker，“单向轻量级封装（ULE）和通用流封装（GSE）的扩展格式”，RFC 51632008年4月。
[53] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007.
[53] “局域网和城域网IEEE标准草案：媒体独立切换服务”，IEEE LAN/MAN草案IEEE P802.21/D07.00，2007年7月。
[54] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[54] Melia，T.，编辑，“移动服务运输：问题陈述”，RFC 51642008年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.，Ed.，巴伊科，G.，达斯，S.，戈尔米，N.，和JC。Zuniga，“IEEE 802.21移动服务框架设计（MSFD）”，RFC 5677，2009年12月。
[56] Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three Approaches Towards Mobile Multicast", IST Mobile Summit 2003, Aveiro, Portugal, 16-18 June 2003.
[56] Janneteau，C，Tian，Y，Csaba，S.等人，“移动多播三种方法的比较”，IST移动峰会2003年，葡萄牙阿维罗，2003年6月16-18日。
[57] Suh, K., Kwon, D.-H., Suh, Y.-J. and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, January 2004.
[57] Suh，K.，Kwon，D.-H.，Suh，Y.-J.和Y.Park，“快速切换环境中移动IPv6的快速多播协议”，正在进行的工作，2004年1月。
[58] Xia, F. and B. Sarikaya, "FMIPv6 extensions for Multicast Handover", Work in Progress, March 2007.
[58] Xia，F.和B.Sarikaya，“多播切换的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] Schmidt，T.和M.Waehlisch，“分层移动IPv6环境中的无缝多播切换（M-HMIPv6）”，正在进行的工作，2005年11月。
[60] Miloucheva, I. and K. Jonas, "Multicast Context Transfer in mobile IPv6", Work in Progress, June 2005.
[60] Miloucheva，I.和K.Jonas，“移动IPv6中的多播上下文传输”，正在进行的工作，2005年6月。
[61] Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast mobility support using fast MIPv6 extensions", Computer Comm., 29(18), pp. 3745-3765, 2006.
[61] Leoleis，G，Prezerakos，G，Venieris，I，“使用快速MIPv6扩展的无缝多播移动性支持”，计算机通讯，29（18），第3745-37652006页。
[62] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[62] Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[63] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
[63] Deng，H.，Chen，G.，Schmidt，T.，Seite，P.，和P.Yang，“代理移动IPv6的多播支持要求”，正在进行的工作，2009年7月。
[64] Zhang, H., Chen, X., Guan, J., Shen, B., Liu, E., and S. Dawkins, "Mobile IPv6 Multicast with Dynamic Multicast Agent", Work in Progress, January 2007.
[64] Zhang，H.，Chen，X.，Guan，J.，Shen，B.，Liu，E.，和S.Dawkins，“使用动态多播代理的移动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-412004页。
[66] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[66] Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[67] Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On Deployable, Efficient, Mobility-agnostic Group Communication Services", Internet Research, 17(5), pp. 519-534, Emerald Insight, Bingley, UK, November 2007.
[67] Waehlisch，M.，Schmidt，T.C.“在底层和覆盖层之间：关于可部署、高效、机动性不可知的群体通信服务”，互联网研究，17（5），第519-534页，Emerald Insight，宾利，英国，2007年11月。
[68] J. Buford, "Hybrid Overlay Multicast Framework", Work in Progress, February 2008.
[68] J.Buford，“混合覆盖多播框架”，正在进行的工作，2008年2月。
[69] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", Work in Progress, October 2009.
[69] Waehlisch，M.，Schmidt，T.，和S.Venaas，“透明混合多播的通用API”，正在进行的工作，2009年10月。
[70] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[70] Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[71] Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", IEEE Wirel. Comm., 9(5), pp 58-64, Oct. 2002.
[71] Jelger，C，Noel，T.“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] Romdhani，I，Bettahar，H.和Bouabdallah，“移动多播源的透明切换”，载于P.Lorenz和P.Dini，编辑，IEEE ICN'06会议录，IEEE出版社，2006年。
[73] Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002.
[73] Lin，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] Chang，R.-S.和Yen，Y.-S.“移动IPv6中具有动态树调整的多播路由协议”，Journ。《信息科学与工程》，20（6），第1109-11242004页。
[75] Thaler, D. "Supporting Mobile SSM Sources for IPv6",
Proceedings of ietf meeting, Dec. 2001.
URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf
[75] Thaler, D. "Supporting Mobile SSM Sources for IPv6",
Proceedings of ietf meeting, Dec. 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.Noel，“支持IPv6移动SSM源（MSSV6）”，正在进行的工作，2002年1月。
[77] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[77] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[78] Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 2002.
[78] Vida，R，Costa，L，Fdida，S.“M-HBH-多播中的高效移动性管理”，Proc。《NGC'02》第105-112页，ACM出版社2002年。
[79] A. O'Neill "Mobility Management and IP Multicast", Work in Progress, July 2002.
[79] A.O'Neill“移动性管理和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] Schmidt，T.C.和Waehlisch，M.“将SSM扩展到MIPv6——问题、解决方案和改进”，《科学和技术中的计算方法》，第11（2）页，第147-152页。特蕾娜网络会议论文选集，波兹南，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] Schmidt，T.C.，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.
[82] Lee，H.，Han，S.和Hong，J.“源特定多播中源移动性的有效机制”，K.Kawahara和I.Chong主编，“2006年ICOO2006年会议记录”，LNCS第3961卷，第82-91页，Springer Verlag，柏林，海德堡，2006年。
[83] Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast", Third International Conference on Networking and Services ICNS, IEEE Press, pp. 1-1, June 2007.
[83] Kovacshazi，Z.和Vida，R.“特定于主机身份的多播”，第三届网络和服务ICN国际会议，IEEE出版社，第1-1页，2007年6月。
[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.Surveys&Tutorials，7（2），第46-702005页。
[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国际研讨会。公司。土耳其公社，2003年7月，第588-93页。
[86] Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - a mobility-compliant protocol framework for multicast sender authentication", Security and Communication Networks, 1(6), pp. 495-509, 2008.
[86] Schmidt，T.C，Waehlisch，M.，Christ，O.，和Hege，G.“AuthoCast-一种适用于多播发送方身份验证的移动性兼容协议框架”，安全与通信网络，1（6），第495-5092008页。
[87] Fenner, B., Holbrook, H., and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", Work in Progress, November 2001.
[87] Fenner，B.，Holbrook，H.，和I.Kouvelas，“多播源兴趣通知协议（MSNIP）”，正在进行的工作，2001年11月。
[88] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[88] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年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".
格雷格·戴利（Greg Daley）和戈皮·库鲁普（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·阿尔梅罗斯、拉克兰·安德鲁、贾里·阿尔科、塞德里克·波多恩、汉斯·L·赛康、惠登、马歇尔·尤班克斯、黄志刚、克里斯托夫·杰尔格、安德烈·古托夫、拉吉夫·库德利、马克·帕尔科夫、克雷格·帕特里奇、伊德·隆达尼、赫萨姆·索利曼、戴夫·泰勒，最后但并非最不重要的是，非常特别地感谢Stig Venaas经常提供的全面建议。
Authors' Addresses
作者地址
Thomas C. Schmidt Dept. Informatik Hamburg University of Applied Sciences, Berliner Tor 7 D-20099 Hamburg, Germany Phone: +49-40-42875-8157 EMail: schmidt@informatik.haw-hamburg.de
Thomas C. Schmidt汉堡应用科学汉堡大学，柏林大学7 D-200 99汉堡，德国电话：+4940-428 75-8157电子邮件：schmidt@informatik.haw-汉堡
Matthias Waehlisch link-lab Hoenower Str. 35 D-10318 Berlin, Germany EMail: mw@link-lab.net
Matthias Waehlisch link lab Hoenower Str.35 D-10318德国柏林电子邮件：mw@link-实验室网络
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, UK EMail: gorry@erg.abdn.ac.uk
阿伯丁大学GoRead FelHurt工程学院，英国，阿伯丁，AB24 3UE，电子邮件：gorry@erg.abdn.ac.uk