Internet Engineering Task Force (IETF) T. Schmidt
Request for Comments: 6224 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab & FU Berlin
S. Krishnan
Ericsson
April 2011
Internet Engineering Task Force (IETF) T. Schmidt
Request for Comments: 6224 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab & FU Berlin
S. Krishnan
Ericsson
April 2011
Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains
代理移动IPv6（PMIPv6）域中支持多播侦听器的基本部署
Abstract
摘要
This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document.
本文档描述了在代理移动IPv6域中激活多播侦听器功能的部署选项，而无需修改移动和多播协议标准。与移动IPv6中的归属代理类似，代理移动IPv6的本地移动锚作为多播订阅锚点，而移动接入网关提供多播侦听器发现（MLD）代理功能。在这种情况下，移动节点仍然不知道组播移动操作。对移动多播发送者的支持超出了本文档的范围。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6224.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6224.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. Multicast Availability throughout the Access Network . . . 12
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 13
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16
Appendix C. Comparative Evaluation of Different Approaches . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. Multicast Availability throughout the Access Network . . . 12
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 13
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16
Appendix C. Comparative Evaluation of Different Approaches . . . 17
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) [RFC3775] by network-based management functions that enable IP mobility for a host without requiring its participation in any mobility-related signaling. Additional network entities, called the Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs), are responsible for managing IP mobility on behalf of the mobile node (MN).
代理移动IPv6（PMIPv6）[RFC5213]通过基于网络的管理功能扩展了移动IPv6（MIPv6）[RFC3775]，使主机能够进行IP移动，而无需参与任何移动相关信令。其他网络实体，称为本地移动性锚（LMA）和移动接入网关（mag），负责代表移动节点（MN）管理IP移动性。
With these entities in place, the mobile node experiences an exceptional access topology towards the static Internet in the sense that the MAG introduces a routing hop in situations where the LMA architecturally acts as the next hop (or designated) router for the MN. In the particular case of multicast communication, group membership management, as signaled by the Multicast Listener Discovery (MLD) protocol [RFC3810] [RFC2710], requires dedicated treatment at the network side.
在这些实体就位的情况下，移动节点体验到朝向静态因特网的异常接入拓扑，即在LMA架构上充当MN的下一跳（或指定）路由器的情况下，MAG引入路由跳。在多播通信的特定情况下，如多播侦听器发现（MLD）协议[RFC3810][RFC2710]所示，组成员身份管理需要在网络侧进行专门处理。
Multicast routing functions need to be placed carefully within the PMIPv6 domain in order to augment unicast transmission with group communication services. [RFC5213] does not explicitly address multicast communication. Bidirectional home tunneling, the minimal multicast support arranged by MIPv6, cannot be directly transferred to network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. Consequently, even minimal multicast listener support in PMIPv6 domains requires an explicit deployment of additional functions.
多播路由功能需要小心地放置在PMIPv6域中，以便使用组通信服务增强单播传输。[RFC5213]未明确寻址多播通信。双向家庭隧道，即MIPv6安排的最小多播支持，不能直接传输到基于网络的管理场景，因为不知道移动的节点在移动后不会启动这样的隧道。因此，即使在PMIPv6域中支持最小的多播侦听器，也需要显式部署附加功能。
This document describes options for deploying multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. This document does not address specific optimizations and efficiency improvements of multicast routing for network-based mobility discussed in [RFC5757], as such solutions would require changes to the base PMIPv6 protocol [RFC5213]. Support for mobile multicast senders is also outside the scope of this document.
本文档描述了在代理移动IPv6域中部署多播侦听器功能的选项，而无需修改移动和多播协议标准。与移动IPv6中的归属代理类似，PMIPv6本地移动锚作为多播订阅锚点，而移动接入网关提供MLD代理功能。在这种情况下，移动节点仍然不知道组播移动操作。本文件未涉及[RFC5757]中讨论的基于网络的移动性多播路由的具体优化和效率改进，因为此类解决方案需要更改基本PMIPv6协议[RFC5213]。对移动多播发送者的支持也不在本文档的范围之内。
This document uses the terminology as defined for the mobility protocols [RFC3775], [RFC5213], and [RFC5844], as well as the multicast edge related protocols [RFC3376], [RFC3810], and [RFC4605].
本文档使用移动协议[RFC3775]、[RFC5213]和[RFC5844]以及多播边缘相关协议[RFC3376]、[RFC3810]和[RFC4605]定义的术语。
The reference scenario for multicast deployment in Proxy Mobile IPv6 domains is illustrated in Figure 1. Below, LMAA and MN-HNP are the LMA Address and Mobile Node's Home Network Prefix as defined in [RFC5213].
代理移动IPv6域中多播部署的参考场景如图1所示。下面，LMAA和MN-HNP是[RFC5213]中定义的LMA地址和移动节点的家庭网络前缀。
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3
Figure 1: Reference Network for Multicast Deployment in PMIPv6
图1:PMIPv6中多播部署的参考网络
An MN in a PMIPv6 domain will decide on multicast group membership management completely independent of its current mobility conditions. It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses according to [RFC3810] or [RFC2710]. These
PMIPv6域中的MN将完全独立于其当前移动条件来决定多播组成员管理。它将根据[RFC3810]或[RFC2710]使用其链路本地源地址和多播目标地址，基于应用程序触发器提交MLD报告和完成消息。这些
link-local signaling messages will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these MLD messages.
链路本地信令消息将通过其下游本地（无线）链路之一到达当前活动的MAG。不知道多播的MAG只会丢弃这些MLD消息。
To facilitate multicast in a PMIPv6 domain, an MLD proxy function [RFC4605] needs to be deployed on the MAG that selects the tunnel interface corresponding to the MN's LMA for its upstream interface (cf., Section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel interface defines an MLD proxy domain at the MAG, and it contains all downstream links to MNs that share this specific LMA. According to standard proxy operations, MLD Report messages will be aggregated and then forwarded up the tunnel interface to the MN's corresponding LMA.
为了促进PMIPv6域中的多播，需要在MAG上部署MLD代理功能[RFC4605]，该功能为其上游接口选择与MN的LMA相对应的隧道接口（参见[RFC5213]的第6节）。因此，每个MAG到LMA隧道接口在MAG处定义MLD代理域，并且它包含到共享该特定LMA的mn的所有下游链路。根据标准代理操作，MLD报告消息将被聚合，然后通过隧道接口向上转发到MN的相应LMA。
Serving as the designated multicast router or an additional MLD proxy, the LMA will transpose any MLD message from a MAG into the multicast routing infrastructure. Correspondingly, the LMA will create appropriate multicast forwarding states at its tunnel interface. Traffic of the subscribed groups will arrive at the LMA, and the LMA will forward this traffic according to its group/source states. In addition, the LMA will act as an MLD querier, seeing its downstream tunnel interfaces as multicast-enabled links.
LMA作为指定的多播路由器或额外的MLD代理，将任何MLD消息从MAG转置到多播路由基础设施中。相应地，LMA将在其隧道接口处创建适当的多播转发状态。订阅组的流量将到达LMA，LMA将根据其组/源状态转发该流量。此外，LMA将充当MLD查询器，将其下游隧道接口视为支持多播的链路。
At the MAG, MLD queries and multicast data will arrive on the (tunnel) interface that is assigned to a group of access links as identified by its Binding Update List (cf., Section 6.1 of [RFC5213]). As specified for MLD proxies, the MAG will forward multicast traffic and initiate related signaling down the appropriate access links to the MNs. Hence, all multicast-related signaling and the data traffic will transparently flow from the LMA to the MN on an LMA-specific tree, which is shared among the multicast sources.
在MAG，MLD查询和多播数据将到达（隧道）接口，该接口分配给一组由其绑定更新列表标识的接入链路（参见[RFC5213]第6.1节）。如针对MLD代理所指定的，MAG将转发多播通信量，并沿着适当的接入链路向MNs发起相关信令。因此，所有与多播相关的信令和数据业务将在多播源之间共享的LMA特定树上透明地从LMA流向MN。
In case of a handover, the MN (unaware of IP mobility) will not send unsolicited MLD reports. Instead, the MAG is required to maintain group memberships in the following way. On observing a new MN on a downstream access link, the MAG sends a MLD General Query. Based on its outcome and the multicast group states previously maintained at the MAG, a corresponding Report will be sent to the LMA aggregating group membership states according to the proxy function. Additional Reports can be omitted when the previously established multicast forwarding states at the new MAG already cover the subscriptions of the MN.
在切换的情况下，MN（不知道IP移动性）不会发送未经请求的MLD报告。相反，MAG需要以以下方式维护组成员身份。在观察下游接入链路上的新MN时，MAG发送MLD通用查询。基于其结果和先前在MAG维护的多播组状态，将根据代理功能向LMA发送相应的报告，聚合组成员状态。当新MAG处先前建立的多播转发状态已经覆盖MN的订阅时，可以省略附加报告。
In summary, the following steps are executed on handover:
总之，在移交时执行以下步骤：
1. The MAG-MN link comes up and the MAG discovers the new MN.
1. MAG-MN链接启动，MAG发现新的MN。
2. Unicast address configuration and PMIPv6 binding are performed after the MAG determines the corresponding LMA.
2. 单播地址配置和PMIPv6绑定在MAG确定相应的LMA之后执行。
3. Following IPv6 address configuration, the MAG should send an (early) MLD General Query to the new downstream link as part of its standard multicast-enabled router operations.
3. 在IPv6地址配置之后，MAG应向新的下游链路发送（早期）MLD常规查询，作为其标准多播路由器操作的一部分。
4. The MAG should determine whether the MN is admissible to multicast services; if it's not, then stop here.
4. MAG应确定MN是否允许多播服务；如果不是，就停在这里。
5. The MAG adds the new downstream link to the MLD proxy instance with up-link to the corresponding LMA.
5. MAG将新的下行链路添加到MLD代理实例，并将上行链路添加到相应的LMA。
6. The corresponding proxy instance triggers an MLD General Query on the new downstream link.
6. 相应的代理实例在新的下游链接上触发MLD常规查询。
7. The MN Membership Reports arrive at the MAG, in response either to the early query or to the query sent by the proxy instance.
7. MN成员报告到达MAG，以响应早期查询或代理实例发送的查询。
8. The Proxy processes the MLD Report, updates states, and reports upstream if necessary.
8. 代理处理MLD报告，更新状态，并在必要时向上游报告。
After Re-Binding, the LMA is not required to issue a MLD General Query on the tunnel link to refresh forwarding states. Multicast state updates should be triggered by the MAG, which aggregates subscriptions of all its MNs (see the call flow in Figure 2).
在重新绑定之后，LMA不需要在隧道链路上发出MLD通用查询来刷新转发状态。多播状态更新应该由MAG触发，它聚合所有MN的订阅（参见图2中的调用流）。
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
Figure 2: Call Flow of Multicast-Enabled PMIP with "MLD Membership Report" Abbreviated by "Join"
图2：“MLD成员报告”缩写为“Join”的支持多播的PMIP的调用流
These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. PMIPv6 can provide IPv4 home address mobility support [RFC5844]. Such mobile nodes will use IGMP [RFC2236] [RFC3376] signaling for multicast, which is handled by an IGMP proxy function at the MAG in an analogous way.
这些多播部署注意事项同样适用于在PMIPv6域中启用IPv4堆栈的移动节点。PMIPv6可以提供IPv4家庭地址移动支持[RFC5844]。此类移动节点将使用IGMP[rfc236][RFC3376]信令进行多播，该多播由MAG处的IGMP代理功能以类似方式处理。
Following these deployment steps, multicast management transparently interoperates with PMIPv6. It is worth noting that MNs -- while being attached to the same MAG, but associated with different LMAs -- can subscribe to the same multicast group. Thereby, data could be distributed redundantly in the network and duplicate traffic could arrive at a MAG. Additionally, in a point-to-point wireless link model, a MAG might be forced to transmit the same data over one wireless domain to different MNs. However, multicast traffic arriving at one interface of the MN will always remain unique, i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN (see Appendix C for further considerations).
按照这些部署步骤，多播管理与PMIPv6透明地互操作。值得注意的是，MNs虽然连接到同一个MAG，但与不同的LMA关联，但可以订阅同一个多播组。因此，数据可以冗余地分布在网络中，并且重复的业务可以到达MAG。此外，在点对点无线链路模型中，MAG可能被迫通过一个无线域将相同的数据传输到不同的mn。然而，到达MN的一个接口的多播流量将始终保持唯一性，即，移动多播分发系统将永远不会导致到达MN的重复数据包（更多注意事项，请参见附录C）。
Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define their interaction with the PMIPv6 protocol in the following way.
PMIPv6域中的多播激活需要在PMIPv6路由器上部署通用多播功能，并以以下方式定义它们与PMIPv6协议的交互。
A mobile node willing to manage multicast traffic will join, maintain, and leave groups as if located in the fixed Internet. No specific mobility actions nor implementations are required at the MN.
愿意管理多播流量的移动节点将加入、维护和离开组，就像位于固定互联网中一样。MN不需要特定的移动性操作或实现。
A Mobile Access Gateway is required to assist in MLD signaling and data forwarding between the MNs that it serves and the corresponding LMAs associated to each MN. It therefore needs to implement an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been established with an LMA. The MAG decides on the mapping of downstream links to a proxy instance (and hence an upstream link to an LMA) based on the regular Binding Update List as maintained by PMIPv6 standard operations (cf., Section 6.1 of [RFC5213]). As links connecting MNs and MAGs change under mobility, MLD proxies at MAGs must be able to dynamically add and remove downstream interfaces in their configurations.
需要移动接入网关来协助其所服务的MN和与每个MN相关联的相应lma之间的MLD信令和数据转发。因此，它需要为使用LMA建立的每个上游隧道接口实现MLD代理功能[RFC4605]的实例。MAG根据PMIPv6标准操作维护的常规绑定更新列表（参见[RFC5213]第6.1节），决定下游链路到代理实例的映射（从而决定到LMA的上游链路）。由于连接MNs和MAG的链路在移动性下发生变化，MAG处的MLD代理必须能够在其配置中动态添加和删除下游接口。
On the reception of MLD reports from an MN, the MAG must identify the corresponding proxy instance from the incoming interface and perform regular MLD proxy operations: it will insert/update/remove multicast forwarding state on the incoming interface and will merge state updates into the MLD proxy membership database. It will then send an aggregated Report via the upstream tunnel to the LMA when the membership database (cf., Section 4.1 of [RFC4605]) changes. Conversely, on the reception of MLD queries, the MAG proxy instance will answer the Queries on behalf of all active downstream receivers
从MN接收MLD报告时，MAG必须从传入接口识别相应的代理实例，并执行常规MLD代理操作：它将在传入接口上插入/更新/删除多播转发状态，并将状态更新合并到MLD代理成员数据库中。当成员数据库（参见[RFC4605]第4.1节）发生变化时，它将通过上游隧道向LMA发送聚合报告。相反，在接收到MLD查询时，MAG代理实例将代表所有活动下游接收器回答查询
maintained in its membership database. Queries sent by the LMA do not force the MAG to trigger corresponding messages immediately towards MNs. Multicast traffic arriving at the MAG on an upstream interface will be forwarded according to the group-specific or source-specific forwarding states as acquired for each downstream interface within the MLD proxy instance. At this stage, it is important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of Section 4.2 in [RFC4605], i.e., treat proxy instances in isolation of each other while forwarding. In providing isolated proxy instances, the MAG will uniquely serve its downstream links with exactly the data that belong to whatever group is subscribed on the particular interface.
在其成员数据库中维护。LMA发送的查询不会强制MAG立即向MNs触发相应的消息。到达上游接口上的MAG的多播流量将根据为MLD代理实例内的每个下游接口获取的特定于组或特定于源的转发状态进行转发。在此阶段，需要注意的是，能够实现多个实例的IGMP/MLD代理实现应严格遵循[RFC4605]第4.2节的规范，即在转发时将代理实例彼此隔离。在提供独立的代理实例时，MAG将唯一地为其下游链路提供属于特定接口上订阅的任何组的数据。
After a handover, the MAG will continue to manage upstream tunnels and downstream interfaces as specified in the PMIPv6 specification. It must dynamically associate new access links to proxy instances that include the upstream connection to the corresponding LMA. The MAG detects the arrival of a new MN by receiving a router solicitation message and by an upcoming link. To learn about multicast groups subscribed by a newly attaching MN, the MAG should send a General Query to the MN's link. Querying an upcoming interface is a standard operation of MLD queriers (see Appendix A) and is performed immediately after address configuration. In addition, an MLD query should be initiated by the proxy instance, as soon as a new interface has been configured for downstream. In case the access link between MN and MAG goes down, interface-specific multicast states change. Both cases may alter the composition of the membership database and this will trigger corresponding Reports towards the LMA. Note that the actual observable state depends on the access link model in use.
移交后，MAG将继续按照PMIPv6规范的规定管理上游隧道和下游接口。它必须动态地将新的接入链路与代理实例相关联，代理实例包括与相应LMA的上游连接。MAG通过接收路由器请求消息和即将到来的链路来检测新MN的到达。要了解新连接的MN订阅的多播组，MAG应向MN的链路发送一般查询。查询即将到来的接口是MLD查询器的标准操作（见附录a），并在地址配置后立即执行。此外，一旦为下游配置了新接口，代理实例就应该启动MLD查询。如果MN和MAG之间的访问链路断开，特定于接口的多播状态将发生变化。这两种情况都可能改变会员数据库的组成，这将触发向LMA提交的相应报告。请注意，实际的可观察状态取决于所使用的访问链路模型。
An MN may be unable to answer MAG multicast membership queries due to handover procedures, or its report may arrive before the MAG has configured its link as the proxy downstream interface. Such occurrences are equivalent to a General Query loss. To prevent erroneous query timeouts at the MAG, MLD parameters should be carefully adjusted to the mobility regime. In particular, MLD timers and the Robustness Variable (see Section 9 of [RFC3810]) should be chosen to be compliant with the time scale of handover operations and proxy configurations in the PMIPv6 domain.
由于切换过程，MN可能无法回答MAG多播成员资格查询，或者其报告可能在MAG将其链路配置为代理下游接口之前到达。此类事件相当于一般查询损失。为防止MAG出现错误的查询超时，MLD参数应仔细调整，以适应移动机制。特别是，MLD定时器和稳健性变量（参见[RFC3810]第9节）的选择应符合PMIPv6域中切换操作和代理配置的时间尺度。
In proceeding this way, the MAG is able to aggregate multicast subscriptions for each of its MLD proxy instances. However, this deployment approach does not prevent multiple identical streams arriving from different LMA upstream interfaces. Furthermore, a multipoint channel forwarding into the wireless domain is prevented by the point-to-point link model in use.
通过这种方式，MAG能够为其每个MLD代理实例聚合多播订阅。然而，这种部署方法不能防止来自不同LMA上游接口的多个相同流。此外，使用的点到点链路模型阻止多点信道转发到无线域。
For any MN, the Local Mobility Anchor acts as the persistent home agent and at the same time as the default multicast querier for the corresponding MAG. It implements the function of the designated multicast router or a further MLD proxy. According to MLD reports received from a MAG (on behalf of the MNs), the LMA establishes/ maintains/removes group-/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. At the same time, it procures for aggregated multicast membership maintenance at its upstream interface. Based on the multicast-transparent operations of the MAGs, the LMA treats its tunnel interfaces as multicast-enabled downstream links, serving zero to many listening nodes. Multicast traffic arriving at the LMA is transparently forwarded according to its multicast forwarding information base.
对于任何MN，本地移动锚作为持久归属代理，同时作为相应MAG的默认多播查询器。它实现指定多播路由器或进一步MLD代理的功能。根据从MAG（代表MNs）接收到的MLD报告，LMA在其相应的下游隧道接口处建立/维护/移除特定于组/源的多播转发状态。同时，它在其上游接口获取聚合多播成员资格维护。基于MAG的多播透明操作，LMA将其隧道接口视为支持多播的下游链路，服务于零到多个侦听节点。到达LMA的组播流量根据其组播转发信息库进行透明转发。
After a handover, the LMA will receive Binding De-Registrations and Binding Lifetime Extensions that will cause a re-mapping of home network prefix(es) to a new Proxy-CoA in its Binding Cache (see Section 5.3 of [RFC5213]). The multicast forwarding states require updating, as well, if the MN within an MLD proxy domain is the only receiver of a multicast group. Two different cases need to be considered:
切换后，LMA将接收绑定注销和绑定生存期延长，这将导致家庭网络前缀重新映射到其绑定缓存中的新代理CoA（参见[RFC5213]第5.3节）。如果MLD代理域中的MN是多播组的唯一接收器，则多播转发状态也需要更新。需要考虑两种不同的情况：
1. The mobile node is the only receiver of a group behind the interface at which a De-Registration was received: the membership database of the MAG changes, which will trigger a Report/Done sent via the MAG-to-LMA interface to remove this group. The LMA thus terminates multicast forwarding.
1. 移动节点是接口后面接收取消注册的组的唯一接收器：MAG的成员数据库更改，这将触发通过MAG发送到LMA接口的报告/完成，以删除该组。因此，LMA终止多播转发。
2. The mobile node is the only receiver of a group behind the interface at which a Lifetime Extension was received: the membership database of the MAG changes, which will trigger a Report sent via the MAG-to-LMA interface to add this group. The LMA thus starts multicast distribution.
2. 移动节点是接口后面接收到生存期延长的组的唯一接收器：MAG的成员数据库更改，这将触发通过MAG发送到LMA接口的报告以添加该组。因此，LMA开始多播分发。
In proceeding this way, each LMA will provide transparent multicast support for the group of MNs it serves. It will perform traffic aggregation at the MN-group level and will assure that multicast data streams are uniquely forwarded per individual LMA-to-MAG tunnel.
通过这种方式，每个LMA将为其服务的MN组提供透明的多播支持。它将在MN组级别执行流量聚合，并将确保每个LMA将多播数据流唯一地转发到MAG隧道。
An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844]. For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding Caches, and MAGs can provide IPv4 support in access networks. Correspondingly, multicast membership management will be performed by the MN using IGMP. For
PMIPv6域中的MN可以按照[RFC5844]中的规定透明地使用IPv4地址进行通信。为此，LMA可以在其绑定缓存中注册IPv4代理CoA，而MAG可以在接入网络中提供IPv4支持。相应地，多播成员管理将由MN使用IGMP执行。对于
multicast support on the network side, an IGMP proxy function needs to be deployed at MAGs in exactly the same way as for IPv6. [RFC4605] defines IGMP proxy behavior in full agreement with IPv6/ MLD. Thus, IPv4 support can be transparently provided following the obvious deployment analogy.
多播支持在网络端，IGMP代理功能需要以与IPv6完全相同的方式部署在MAG上。[RFC4605]定义与IPv6/MLD完全一致的IGMP代理行为。因此，可以按照明显的部署类比透明地提供IPv4支持。
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances should choose multicast signaling according to address configurations on the link, but may submit IGMP and MLD queries in parallel, if needed. It should further be noted that the infrastructure cannot identify two data streams as identical when distributed via an IPv4 and IPv6 multicast group. Thus, duplicate data may be forwarded on a heterogeneous network layer.
对于双栈IPv4/IPv6接入网络，MAG代理实例应根据链路上的地址配置选择多播信令，但如果需要，可以并行提交IGMP和MLD查询。还应注意，当通过IPv4和IPv6多播组分发时，基础结构无法将两个数据流标识为相同。因此，可以在异构网络层上转发重复数据。
A particular note is worth giving the scenario of [RFC5845] in which overlapping private address spaces of different operators can be hosted in a PMIP domain by using Generic Routing Encapsulation (GRE) with key identification. This scenario implies that unicast communication in the MAG-LMA tunnel can be individually identified per MN by the GRE keys. This scenario still does not impose any special treatment of multicast communication for the following reasons.
值得特别注意的是[RFC5845]的场景，其中不同运营商的重叠私有地址空间可以通过使用具有密钥标识的通用路由封装（GRE）托管在PMIP域中。该场景意味着MAG-LMA隧道中的单播通信可以通过GRE密钥在每个MN中单独识别。由于以下原因，该场景仍然没有对多播通信进行任何特殊处理。
MLD/IGMP signaling between MNs and the MAG is on point-to-point links (identical to unicast). Aggregated MLD/IGMP signaling between the MAG proxy instance and the LMA remains link-local between the routers and independent of any individual MN. So the MAG-proxy and the LMA should not use GRE key identifiers, but plain GRE to exchange MLD queries and reports. Similarly, multicast traffic sent from an LMA to MAGs proceeds as router-to-router forwarding according to the multicast forwarding information base (MFIB) of the LMA and independent of MN's unicast addresses, while the MAG proxy instance distributes multicast data down the point-to-point links (interfaces) according to its own MFIB, independent of MN's IP addresses.
MNs和MAG之间的MLD/IGMP信令在点到点链路上（与单播相同）。MAG代理实例和LMA之间的聚合MLD/IGMP信令保持路由器之间的本地链路，并且独立于任何单个MN。因此，MAG代理和LMA不应使用GRE密钥标识符，而应使用普通GRE来交换MLD查询和报告。类似地，从LMA发送到MAG的多播业务根据LMA的多播转发信息库（MFIB）作为路由器到路由器转发进行，并且独立于MN的单播地址，而MAG代理实例根据其自己的MFIB将多播数据分发到点到点链路（接口），独立于MN的IP地址。
It remains an open issue how communication proceeds in a multi-operator scenario, i.e., from which network the LMA pulls multicast traffic. This could be any mobility Operator itself, or a third party. However, this backbone routing in general is out of scope of the document, and most likely a matter of contracts.
在多运营商场景中，通信如何进行仍然是一个悬而未决的问题，即LMA从哪个网络提取多播流量。这可能是任何移动运营商本身，也可能是第三方。但是，这种主干路由一般不在文档的范围内，很可能是一个合同问题。
An MN can connect to a PMIPv6 domain through multiple interfaces and experience transparent unicast handovers at all interfaces (cf., Section 5.4 of [RFC5213]). In such simultaneous access scenarios, it can autonomously assign multicast channel subscriptions to individual interfaces (see [RFC5757] for additional details). While doing so,
MN可以通过多个接口连接到PMIPv6域，并在所有接口上进行透明单播切换（参见[RFC5213]第5.4节）。在这种同时访问场景中，它可以自主地将多播信道订阅分配给各个接口（有关更多详细信息，请参阅[RFC5757]）。在这样做的同时,，
multicast mobility operations described in this document will transparently preserve the association of channels to interfaces in the following way.
本文档中描述的多播移动操作将以以下方式透明地保留通道与接口的关联。
Multicast listener states are kept per interface in the MLD state table. An MN will answer to an MLD General Query received on a specific (re-attaching) interface according to the specific interface's state table. Thereafter, multicast forwarding is resumed for channels identical to those under subscription prior to handover. Consequently, an MN in a PMIPv6 domain may use multiple interfaces to facilitate load balancing or redundancy, but cannot follow a 'make-before-break' approach to service continuation on handovers.
多播侦听器状态保存在MLD状态表中的每个接口上。MN将根据特定接口的状态表回答在特定（重新连接）接口上接收的MLD通用查询。此后，对于与切换前订阅的信道相同的信道，恢复多播转发。因此，PMIPv6域中的MN可以使用多个接口来促进负载平衡或冗余，但不能遵循“先通后断”的方法来在切换上继续服务。
There may be deployment scenarios where multicast services are available throughout the access network, independent of the PMIPv6 infrastructure. Direct multicast access at MAGs may be supported through native multicast routing within a flat access network that includes a multicast router, via dedicated (tunnel or VPN) links between MAGs and designated multicast routers, or by deploying Automatic Multicast Tunneling (AMT) [AUTO-MULTICAST].
可能存在这样的部署场景，即多播服务在整个接入网络中都是可用的，独立于PMIPv6基础设施。可通过包括多播路由器的平面接入网络内的本机多播路由，通过MAG和指定多播路由器之间的专用（隧道或VPN）链路，或通过部署自动多播隧道（AMT）[自动多播]来支持MAG处的直接多播接入。
Multicast deployment can be simplified in these scenarios. A single proxy instance at MAGs with up-link to the multicast cloud, for instance, could serve group communication purposes. MAGs could operate as general multicast routers or AMT gateways as well.
在这些场景中，可以简化多播部署。例如，MAGs上的一个代理实例与多播云具有上行链路，可以用于组通信目的。MAG也可以作为通用多播路由器或AMT网关运行。
Common to these solutions is that mobility management is covered by the dynamics of multicast routing, as initially foreseen in the Remote Subscription approach, i.e., join via a local multicast router as sketched in [RFC3775]. Care must be taken to avoid avalanche problems or service disruptions due to tardy multicast routing operations and to adapt to different link-layer technologies [RFC5757]. The different possible approaches should be carefully investigated beyond the initial sketch in Appendix C. Such work is beyond the scope of this document.
这些解决方案的共同点是，移动管理包含在多播路由的动态中，如远程订阅方法中最初预见的，即通过本地多播路由器加入，如[RFC3775]所示。必须注意避免由于延迟的多播路由操作而导致雪崩问题或服务中断，并适应不同的链路层技术[RFC5757]。除了附录C中的初始草图外，还应仔细研究不同的可能方法。此类工作超出了本文件的范围。
An IGMPv3/MLDv2 Querier may operate in combination with explicit tracking as described in Appendix A.2 of [RFC3376], or Appendix A.2 of [RFC3810]. This mechanism allows routers to monitor each multicast receiver individually. Even though this procedure is not standardized yet, it is widely implemented by vendors as it supports faster leave latencies and reduced signaling.
IGMPv3/MLDv2查询器可与[RFC3376]附录A.2或[RFC3810]附录A.2中所述的显式跟踪结合使用。这种机制允许路由器单独监控每个多播接收器。尽管该程序尚未标准化，但由于其支持更快的休假延迟和减少的信令，因此被供应商广泛实施。
Enabling explicit tracking on downstream interfaces of the LMA and MAG would track a single MAG and MN respectively per interface. It may be used to preserve bandwidth on the MAG-MN link.
在LMA和MAG的下游接口上启用显式跟踪将分别跟踪每个接口的单个MAG和MN。它可用于保持MAG-MN链路上的带宽。
This section describes source and destination addresses of MLD messages and encapsulating outer headers when deployed in the PMIPv6 domain. This overview is for clarification purposes only and does not define a behavior different from referenced standards in any way.
本节描述MLD消息的源地址和目标地址，以及在PMIPv6域中部署时封装外部头。本概述仅用于澄清目的，不定义任何不同于参考标准的行为。
The interface identifier A-B denotes an interface on node A, which is connected to node B. This includes tunnel interfaces. Destination addresses for MLD/IGMP messages shall be as specified in Section 8 of [RFC2710] for MLDv1, and Sections 5.1.15 and 5.2.14 of [RFC3810] for MLDv2.
接口标识符A-B表示连接到节点B的节点A上的接口。这包括隧道接口。MLD/IGMP消息的目的地地址应符合[RFC2710]第8节关于MLDv1的规定，以及[RFC3810]第5.1.15和5.2.14节关于MLDv2的规定。
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
This document does not introduce additional messages or novel protocol operations. Consequently, no additional threats are introduced by this document beyond those identified as security concerns of [RFC3810], [RFC4605], [RFC5213], and [RFC5844].
本文档不介绍其他消息或新的协议操作。因此，除[RFC3810]、[RFC4605]、[RFC5213]和[RFC5844]确定的安全问题外，本文件未引入其他威胁。
However, particular attention should be paid to implications of combining multicast and mobility management at network entities. As this specification allows mobile nodes to initiate the creation of multicast forwarding states at MAGs and LMAs while changing attachments, threats of resource exhaustion at PMIP routers and access networks arrive from rapid state changes, as well as from high-volume data streams routed into access networks of limited capacities. In addition to proper authorization checks of MNs, rate controls at replicators may be required to protect the agents and the downstream networks. In particular, MLD proxy implementations at MAGs should carefully procure automatic multicast state extinction on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will not actively terminate group membership prior to departure.
然而，应特别注意在网络实体处结合多播和移动性管理的含义。由于该规范允许移动节点在更改附件的同时在MAG和LMA处发起多播转发状态的创建，PMIP路由器和接入网络的资源耗尽威胁来自于快速状态变化，以及来自路由到容量有限的接入网络的大容量数据流。除了对MNs进行适当的授权检查外，还可能需要在复制器上进行速率控制，以保护代理和下游网络。特别是，MAG的MLD代理实现应在MNs离开时小心地实现自动多播状态消失，因为PMIPv6域中的移动多播侦听器不会在离开前主动终止组成员资格。
This memo follows initial requirements work presented in "Multicast Support Requirements for Proxy Mobile IPv6" (July 2009), and is the outcome of extensive previous discussions and a follow-up of several initial documents on the subject. The authors would like to thank (in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen, Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for advice, help, and reviews of the document. Funding by the German Federal Ministry of Education and Research within the G-LAB Initiative is gratefully acknowledged.
本备忘录遵循“代理移动IPv6的多播支持需求”（2009年7月）中介绍的初始需求工作，是之前广泛讨论的结果，也是关于该主题的几个初始文档的后续。作者要感谢（按字母顺序排列）贾里·阿尔科、路易斯·孔特雷拉斯、格雷格·戴利、戈里·费尔赫斯特、德克·冯·雨果、刘辉、塞尔金、朱尼·科霍宁、广路、塞巴斯蒂安·梅林、阿克巴·拉赫曼、艾德·隆达尼、贝塞特·萨里卡亚、皮埃里克·塞特、斯蒂格·维纳斯和胡安·卡洛斯·祖尼加对该文件的建议、帮助和评论。感谢德国联邦教育和研究部在G-LAB倡议范围内提供的资金。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[AUTO-MULTICAST] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Pusateri, "Automatic IP Multicast Without Explicit Tunnels (AMT)", Work in Progress, March 2010.
[自动多播]Thaler，D.，Talwar，M.，Aggarwal，A.，Vicisano，L.，和T.Pusateri，“无显式隧道的自动IP多播（AMT）”，正在进行的工作，2010年3月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010.
[RFC5757]Schmidt，T.，Waehlisch，M.，和G.Fairhurst，“移动IP版本6（MIPv6）中的多播移动性：问题陈述和简要调查”，RFC 5757，2010年2月。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
[RFC5845]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的通用路由封装（GRE）密钥选项”，RFC 58452010年6月。
According to [RFC3810] and [RFC2710], when an IGMP-/MLD-enabled multicast router starts operating on a subnet, by default it considers itself as querier and sends several General Queries. Such initial query should be sent by the router immediately, but could be delayed by a (tunable) Startup Query Interval (see Sections 7.6.2 and 9.6 of [RFC3810]).
根据[RFC3810]和[RFC2710]，当启用IGMP-/MLD的多播路由器开始在子网上运行时，默认情况下，它会将自己视为查询者，并发送几个常规查询。路由器应立即发送此类初始查询，但可延迟（可调）启动查询间隔（见[RFC3810]第7.6.2和9.6节）。
Experimental tests on Linux and Cisco systems have revealed immediate IGMP Queries followed a link trigger event (within a fraction of 1 ms), while MLD queries immediately followed the autoconfiguration of IPv6 link-local addresses at the corresponding interface.
在Linux和Cisco系统上进行的实验测试表明，在链路触发事件之后立即执行IGMP查询（在不到1毫秒的时间内），而MLD查询则在相应接口上立即执行IPv6链路本地地址的自动配置。
Appendix B. State of IGMP/MLD Proxy Implementations
附录B.IGMP/MLD代理实施情况
The deployment scenario defined in this document requires certain proxy functionalities at the MAGs that implementations of [RFC4605] need to contribute. In particular, a simultaneous support of IGMP and MLD is needed, as well as a configurable list of downstream interfaces that may be altered during runtime, and the deployment of multiple proxy instances at a single router that can operate independently on separated interfaces.
本文档中定义的部署场景需要MAG上的某些代理功能，[RFC4605]的实现需要这些功能。特别是，需要同时支持IGMP和MLD，以及可在运行时更改的下游接口的可配置列表，以及在单个路由器上部署多个代理实例，这些实例可以在单独的接口上独立运行。
A brief experimental trial undertaken in February 2010 revealed the following divergent statuses of selected IGMP/MLD proxy implementations.
2010年2月进行的一项简短的实验性试验揭示了所选IGMP/MLD代理实现的以下不同状态。
Cisco Edge Router: Software-based commodity edge routers (test device from the 26xx-Series) implement IGMPv2/v3 proxy functions only in combination with Protocol Independent Multicast - Sparse Mode (PIM-SM). There is no support of MLD proxy. Interfaces are dynamically configurable at runtime via the command line interface, but multiple proxy instances are not supported.
Cisco边缘路由器：基于软件的商品边缘路由器（26xx系列的测试设备）仅在与协议无关的多播稀疏模式（PIM-SM）结合使用时实现IGMPv2/v3代理功能。不支持MLD代理。接口在运行时可通过命令行界面进行动态配置，但不支持多个代理实例。
Linux igmpproxy: IGMPv2 Proxy implementation that permits a static configuration of downstream interfaces (simple bug fix required). Multiple instances are prevented by a lock (corresponding code reused from a previous Distance Vector Multicast Routing Protocol (DVMRP) implementation). IPv6/MLD is unsupported. Project page: http://sourceforge.net/projects/igmpproxy/.
Linux IGMProxy:IGMPv2代理实现，允许对下游接口进行静态配置（需要简单的bug修复）。锁阻止了多个实例（从以前的距离向量多播路由协议（DVMRP）实现中重用的相应代码）。不支持IPv6/MLD。项目页面：http://sourceforge.net/projects/igmpproxy/.
Linux gproxy: IGMPv3 Proxy implementation that permits configuration of the upstream interface, only. Downstream interfaces are collected at startup without dynamic extension of this list. No support of multiple instances or MLD.
Linux gproxy:IGMPv3代理实现，仅允许配置上游接口。下游接口在启动时收集，没有此列表的动态扩展。不支持多实例或MLD。
Linux ecmh: MLDv1/2 Proxy implementation without IGMP support that
inspects IPv4 tunnels and detects encapsulated MLD messages.
Allows for dynamic addition of interfaces at runtime and multiple
instances. However, downstream interfaces cannot be configured.
Project page: http://sourceforge.net/projects/ecmh/
Linux ecmh: MLDv1/2 Proxy implementation without IGMP support that
inspects IPv4 tunnels and detects encapsulated MLD messages.
Allows for dynamic addition of interfaces at runtime and multiple
instances. However, downstream interfaces cannot be configured.
Project page: http://sourceforge.net/projects/ecmh/
In this section, we briefly evaluate two orthogonal PMIP concepts for multicast traffic organization at LMAs. In scenario A, multicast is provided by combined unicast/multicast LMAs as described in this document. Scenario B directs traffic via a dedicated, central multicast router ("LMA-M") that tunnels packets to MAGs independent of unicast handoffs.
在本节中，我们将简要评估LMAs上用于多播流量组织的两个正交PMIP概念。在场景A中，多播由本文档中描述的组合单播/多播LMA提供。场景B通过专用的中央多播路由器（“LMA-M”）引导流量，该路由器将数据包隧道到MAG，而不依赖于单播切换。
Neither approach establishes native multicast distribution between the LMA and MAG; instead, they use tunneling mechanisms. In scenario A, a MAG is connected to different multicast-enabled LMAs and can receive the same multicast stream via multiple paths depending on the group subscriptions of MNs and their associated LMAs. This problem, a.k.a. the tunnel convergence problem, may lead to redundant traffic at the MAGs. In contrast, scenario B configures MAGs to establish a tunnel to a single, dedicated multicast LMA for all attached MNs and relocates overhead costs to the multicast anchor. This eliminates redundant traffic but may result in an avalanche problem at the LMA.
这两种方法都没有在LMA和MAG之间建立本机多播分布；相反，它们使用隧道机制。在场景A中，MAG连接到不同的支持多播的lma，并且可以通过多条路径接收相同的多播流，这取决于mn的组订阅及其关联的lma。这个问题，又称隧道收敛问题，可能会导致MAG的冗余流量。相反，场景B将MAG配置为为为所有连接的MN建立到单个专用多播LMA的隧道，并将开销成本重新定位到多播锚。这消除了冗余通信量，但可能导致LMA出现雪崩问题。
We quantify the costs of both approaches based on two metrics: the amount of redundant traffic at MAGs and the number of simultaneous streams at LMAs. Realistic values depend on the topology and the group subscription model. To explore scalability in a large PMIP domain of 1,000,000 MNs, we consider the following two extreme multicast settings.
我们基于两个指标量化了这两种方法的成本：MAG的冗余通信量和LMA的同时流数量。实际值取决于拓扑和组订阅模型。为了探索在1000000 MNs的大型PMIP域中的可扩展性，我们考虑以下两个极端组播设置。
1. All MNs participate in distinct multicast groups.
1. 所有MN都参与不同的多播组。
2. All MNs join the same multicast group.
2. 所有MN都加入同一个多播组。
A typical PMIP deployment approximately allows for 5,000 MNs attached to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000 MNs require approximately 200 MAGs backed by 4 LMAs for unicast transmission. In scenario A, these LMAs also forward multicast streams, while in scenario B one additional dedicated LMA (LMA-M) serves multicast. In the following, we calculate the metrics described above. In addition, we display the number of packet streams that cross the interconnecting (wired) network within a PMIPv6 domain.
典型的PMIP部署大约允许5000 MN连接到一个MAG，而50个MAG可以由一个LMA提供服务。因此，1000000 MN需要大约200个MAG，由4个LMA支持，用于单播传输。在场景A中，这些LMA还转发多播流，而在场景B中，一个额外的专用LMA（LMA-M）服务于多播。在下文中，我们计算上述指标。此外，我们还显示了在PMIPv6域内通过互连（有线）网络的数据包流的数量。
Setting 1:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
Setting 1:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to distinct multicast groups.
1000000 MN订阅了不同的多播组。
Setting 2:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
Setting 2:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to the same multicast group.
1000000 MN订阅到同一多播组。
These considerations of extreme settings show that packet duplication and replication effects apply in changing intensities for different use cases of multicast data services. However, tunnel convergence, i.e., duplicate data arriving at a MAG, does cause much smaller problems in scalability than the stream replication at LMAs (avalanche problem). For scenario A, it should also be noted that the high stream replication requirements at LMAs in setting 1 can be attenuated by deploying additional LMAs in a PMIP domain, while scenario B does not allow for distributing the LMA-M, as no handover management is available at LMA-M.
这些对极端设置的考虑表明，对于多播数据服务的不同用例，数据包复制和复制效应适用于不断变化的强度。然而，隧道收敛（即，到达MAG的重复数据）在可伸缩性方面造成的问题比LMA上的流复制（雪崩问题）小得多。对于场景A，还应注意，设置1中LMA处的高流复制需求可以通过在PMIP域中部署额外的LMA来减弱，而场景B不允许分发LMA-M，因为LMA-M处没有可用的切换管理。
Authors' Addresses
作者地址
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
Thomas C.Schmidt HAW Hamburg Berliner Tor 7汉堡20099德国
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany
德国柏林Hoenower街35号Matthias Waehlisch link实验室和FU
EMail: mw@link-lab.net
EMail: mw@link-lab.net
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com