Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7287 HAW Hamburg
Category: Experimental S. Gao
ISSN: 2070-1721 H. Zhang
Beijing Jiaotong University
M. Waehlisch
link-lab & FU Berlin
June 2014
Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7287 HAW Hamburg
Category: Experimental S. Gao
ISSN: 2070-1721 H. Zhang
Beijing Jiaotong University
M. Waehlisch
link-lab & FU Berlin
June 2014
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
代理移动IPv6（PMIPv6）域中的移动多播发送方支持
Abstract
摘要
Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.
通过在移动接入网关上部署多播侦听器发现（MLD）代理功能、使用ISP接入网络内的直接流量分配或通过选择性路由优化方案，可以通过本地移动锚在代理移动IPv6（PMIPv6）域中启用多播通信。本文档描述了一个基本解决方案和一个实验协议，用于在所有三种场景中支持PMIPv6域中的移动多播发送者。定义了PMIPv6与PIM同步的协议优化，以及MLD代理的对等功能。移动源始终不知道多播移动操作。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了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/rfc7287.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7287.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 15
4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 16
4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 16
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 17
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 18
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 18
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 19
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 19
5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Operations in Support of Multicast Senders . . . . . . . 20
5.4. Operations in Support of Multicast Listeners . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 26
A.1. Operations for Local Multicast Sources . . . . . . . . . 26
A.2. Operations for Local Multicast Subscribers . . . . . . . 26
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 15
4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 16
4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 16
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 17
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 18
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 18
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 19
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 19
5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Operations in Support of Multicast Senders . . . . . . . 20
5.4. Operations in Support of Multicast Listeners . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 26
A.1. Operations for Local Multicast Sources . . . . . . . . . 26
A.2. Operations for Local Multicast Subscribers . . . . . . . 26
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 27
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) [RFC6275] 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 Local Mobility Anchor (LMAs) and Mobile Access Gateways (MAGs) are responsible for managing IP mobility on behalf of the mobile node (MN). An MN connected to a PMIPv6 domain, which only operates according to the base specifications of [RFC5213], cannot participate in multicast communication, as MAGs will discard group packets.
代理移动IPv6（PMIPv6）[RFC5213]通过基于网络的管理功能扩展了移动IPv6（MIPv6）[RFC6275]，使主机能够进行IP移动，而无需参与任何移动相关信令。称为本地移动性锚（lma）和移动接入网关（mag）的附加网络实体负责代表移动节点（MN）管理IP移动性。连接到仅根据[RFC5213]基本规范运行的PMIPv6域的MN不能参与多播通信，因为MAG将丢弃组数据包。
Multicast support for mobile listeners can be enabled within a PMIPv6 domain by deploying MLD proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors [RFC6224]. This base deployment option is the simplest way to PMIPv6 multicast extensions in the sense that it follows the common PMIPv6 traffic model and neither requires new protocol operations nor additional infrastructure entities. Standard software functions need to be activated on PMIPv6 entities, only, at the price of possibly non-optimal multicast routing.
通过在移动接入网关部署MLD代理功能和在本地移动锚部署多播路由功能，可以在PMIPv6域内启用对移动侦听器的多播支持[RFC6224]。此基本部署选项是PMIPv6多播扩展的最简单方法，因为它遵循公共PMIPv6流量模型，不需要新的协议操作或额外的基础设施实体。标准软件功能只需要在PMIPv6实体上激活，代价可能是非最佳多播路由。
Alternate solutions leverage performance optimization by providing multicast routing at the access gateways directly [MULTI-EXT] or by using selective route optimization schemes [RFC7028]. Such approaches (partially) follow the model of providing multicast data services in parallel to PMIPv6 unicast routing [RFC7161].
替代解决方案通过在接入网关直接提供多播路由[MULTI-EXT]或使用选择性路由优化方案[RFC7028]来利用性能优化。这种方法（部分）遵循与PMIPv6单播路由并行提供多播数据服务的模型[RFC7161]。
Multicast listener support satisfies the needs of receptive use cases such as IPTV or server-centric gaming on mobiles. However, current trends in the Internet develop towards user-centric, highly interactive group applications like user-generated streaming, conferencing, collective mobile sensing, etc. Many of these popular applications create group content at end systems and can largely profit from a direct data transmission to a multicast-enabled network.
多播侦听器支持满足可接受用例的需求，如IPTV或移动设备上以服务器为中心的游戏。然而，当前互联网的发展趋势是以用户为中心，高度互动的群组应用，如用户生成的流媒体、会议、集体移动感知等。许多这些流行的应用在终端系统创建群组内容，并且可以从直接向支持多播的网络传输数据中获得很大的利润。
This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for the base deployment scenario [RFC6224], for direct traffic distribution within an ISP's access network, as well as for selective route optimization schemes. The source mobility problem as discussed in [RFC5757] serves as a foundation of this document. Mobile nodes in this setting remain agnostic of multicast mobility operations.
本文档描述了代理移动IPv6域中移动多播发送方对基本部署方案[RFC6224]、ISP接入网络内的直接流量分配以及选择性路由优化方案的支持。在[CFC577]中讨论的源移动性问题是本文档的基础。此设置中的移动节点对多播移动操作保持不可知。
This document uses the terminology as defined for the mobility protocols [RFC6275], [RFC5213], and [RFC5844], as well as the multicast routing [RFC4601] and edge-related protocols [RFC3376], [RFC3810], and [RFC4605].
本文档使用移动协议[RFC6275]、[RFC5213]和[RFC5844]以及多播路由[RFC4601]和边缘相关协议[RFC3376]、[RFC3810]和[RFC4605]定义的术语。
Throughout this document, we use the following acronyms:
在本文件中，我们使用以下缩写词：
HNP Home Network Prefix as defined in [RFC5213].
[RFC5213]中定义的HNP家庭网络前缀。
MAG Mobile Access Gateway as defined in [RFC5213].
[RFC5213]中定义的MAG移动接入网关。
MLD Multicast Listener Discovery as defined in [RFC2710] and [RFC3810].
[RFC2710]和[RFC3810]中定义的MLD多播侦听器发现。
PIM Protocol Independent Multicast as defined in [RFC4601].
[RFC4601]中定义的PIM协议独立多播。
PMIPv6 Proxy Mobile IPv6 as defined in [RFC5213].
[RFC5213]中定义的PMIPv6代理移动IPv6。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The reference scenario for multicast deployment in Proxy Mobile IPv6 domains is illustrated in Figure 1. It displays the general setting for source mobility -- mobile nodes (MNs) with Home Network Prefixes (HNPs) that receive services via tunnels, which are spanned between a Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role of first-hop access routers that serve multiple MNs on the downstream while running an MLD/IGMP proxy instance for every LMA upstream tunnel.
代理移动IPv6域中多播部署的参考场景如图1所示。它显示源移动性的常规设置——具有家庭网络前缀（HNP）的移动节点（MN），它们通过隧道接收服务，隧道跨越移动接入网关（MAG）处的本地移动性锚地址（LMAA）和代理转交地址（代理CoA）之间。MAG扮演第一跳接入路由器的角色，该路由器服务于下游上的多个MN，同时为每个LMA上游隧道运行MLD/IGMP代理实例。
+-------------+
| Multicast |
| Listeners |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* 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
+-------------+
| Multicast |
| Listeners |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* 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
Multicast Sender + Listener(s)
多播发送器+侦听器
Figure 1: Reference Network for Multicast Deployment in PMIPv6
图1:PMIPv6中多播部署的参考网络
An MN in a PMIPv6 domain will decide on multicast data transmission completely independent of its current mobility conditions. It will send packets as initiated by applications, using its source address with an HNP and a multicast destination address chosen by application needs. Multicast packets will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these packets in the absence of instructions for packet processing, i.e., a Multicast Routing Information Base (MRIB).
PMIPv6域中的MN将完全独立于其当前移动条件来决定多播数据传输。它将发送由应用程序启动的数据包，使用其源地址和HNP以及由应用程序需要选择的多播目标地址。多播数据包将通过其下游本地（无线）链路之一到达当前活动的MAG。不知道多播的MAG将在没有分组处理指令的情况下简单地丢弃这些分组，即多播路由信息库（MRIB）。
An MN can successfully distribute multicast data in PMIPv6, if MLD proxy functions are deployed at the MAG as described in [RFC6224]. In this setup, the MLD proxy instance serving a mobile multicast source has configured its upstream interface at the tunnel towards the MN's corresponding LMA. For each LMA, there will be a separate instance of an MLD proxy.
如果如[RFC6224]所述在MAG部署MLD代理功能，MN可以在PMIPv6中成功分发多播数据。在此设置中，服务于移动多播源的MLD代理实例已在隧道处向MN的相应LMA配置其上游接口。对于每个LMA，将有一个单独的MLD代理实例。
According to the specifications given in [RFC4605], multicast data arriving from a downstream interface of an MLD proxy will be forwarded to the upstream interface and to all but the incoming downstream interfaces that have appropriate forwarding states for this group. Thus, multicast streams originating from an MN will arrive at the corresponding LMA and directly at all mobile receivers co-located at the same MAG and MLD proxy instance. Serving as the designated multicast router or an additional MLD proxy, the LMA forwards data to the fixed Internet, whenever forwarding states are maintained by multicast routing. If the LMA is acting as another MLD proxy, it will forward the multicast data to its upstream interface and to downstream interfaces with matching subscriptions, accordingly.
根据[RFC4605]中给出的规范，从MLD代理的下游接口到达的多播数据将被转发到上游接口以及除了具有该组适当转发状态的传入下游接口之外的所有其他接口。因此，来自MN的多播流将到达相应的LMA，并直接到达位于同一MAG和MLD代理实例处的所有移动接收机。作为指定的多播路由器或附加的MLD代理，LMA在通过多播路由维持转发状态时将数据转发到固定因特网。如果LMA充当另一个MLD代理，它将相应地将多播数据转发到其上游接口和具有匹配订阅的下游接口。
In case of a handover, the MN (being unaware of IP mobility) can continue to send multicast packets as soon as network connectivity is re-established. At this time, the MAG has determined the corresponding LMA, and IPv6 unicast address configuration (including PMIPv6 bindings) has been completed. Still, multicast packets arriving at the MAG are discarded (if not buffered) until the MAG has completed the following steps.
在切换的情况下，一旦重新建立网络连接，MN（不知道IP移动性）就可以继续发送多播分组。此时，MAG已经确定了相应的LMA，并且IPv6单播地址配置（包括PMIPv6绑定）已经完成。然而，到达MAG的多播数据包被丢弃（如果没有缓冲），直到MAG完成以下步骤。
1. The MAG has determined that the MN is admissible to multicast services.
1. MAG已经确定MN允许多播服务。
2. The MAG has added the new downstream link to the MLD proxy instance with an uplink to the corresponding LMA.
2. MAG已将新的下游链路添加到MLD代理实例，并将上行链路添加到相应的LMA。
As soon as the MN's uplink is associated with the corresponding MLD proxy instance, multicast packets are forwarded again to the LMA and eventually to receivers within the PMIP domain. (See the call flow in Figure 2.) In this way, multicast source mobility is transparently enabled in PMIPv6 domains that deploy the base scenario for multicast.
一旦MN的上行链路与对应的MLD代理实例相关联，多播分组就被再次转发到LMA，并最终转发到PMIP域内的接收机。（参见图2中的调用流。）通过这种方式，多播源移动性在部署多播基本场景的PMIPv6域中被透明地启用。
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| | Mcast Data | | |
| |<---------------+ | |
| | Mcast Data | | |
| Join(G) +================================================>|
+--------------> | | | |
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | < MLD Proxy Configuration > |
| | | | |
| | | (MLD Query) | |
| | |<--------------+ |
| | | Mcast Data | |
| | +-------------->| |
| | | | Mcast Data |
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| | Mcast Data | | |
| |<---------------+ | |
| | Mcast Data | | |
| Join(G) +================================================>|
+--------------> | | | |
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | < MLD Proxy Configuration > |
| | | | |
| | | (MLD Query) | |
| | |<--------------+ |
| | | Mcast Data | |
| | +-------------->| |
| | | | Mcast Data |
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
Legend: Rtr Sol - ICMPv6 Router Solicitation Rtr Adv - ICMPv6 Router Advertisement
图例：Rtr Sol-ICMPv6路由器请求Rtr Adv-ICMPv6路由器广告
Figure 2: Call Flow for Group Communication in Multicast-Enabled PMIP
图2：支持多播的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]. IPv4 multicast is handled by an IGMP proxy function at the MAG in an analogous way.
这些多播部署注意事项同样适用于在PMIPv6域中启用IPv4堆栈的移动节点。PMIPv6可以提供IPv4家庭地址移动支持[RFC5844]。IPv4多播由MAG上的IGMP代理功能以类似的方式处理。
Following these deployment steps, multicast traffic distribution transparently interoperates with PMIPv6. It is worth noting that an MN -- while being attached to the same MAG as the mobile source, but associated with a different LMA -- cannot receive multicast traffic on a shortest path. Instead, multicast streams flow up to the LMA of
按照这些部署步骤，多播通信量分布透明地与PMIPv6互操作。值得注意的是，MN——虽然与移动源连接到同一个MAG，但与不同的LMA关联——无法在最短路径上接收多播流量。相反，多播流向上流向
the mobile source, are transferred to the LMA of the mobile listener, and are tunneled downwards to the MAG again. (See Section 5 for further optimizations.)
移动源被传输到移动监听器的LMA，并再次向下传输到MAG。（有关进一步的优化，请参见第5节。）
Support of multicast source mobility in PMIPv6 requires that general multicast functions be deployed at PMIPv6 routers and that their interactions with the PMIPv6 protocol be defined as follows.
PMIPv6中对多播源移动性的支持要求在PMIPv6路由器上部署通用多播功能，并且它们与PMIPv6协议的交互定义如下。
A mobile node willing to send multicast data will proceed as if attached to the fixed Internet. No specific mobility or other multicast-related functionalities are required at the MN.
愿意发送多播数据的移动节点将像连接到固定互联网一样继续进行。MN不需要特定的移动性或其他多播相关功能。
A Mobile Access Gateway is required to have MLD proxy instances deployed, one for each tunnel to an LMA, which serves as its unique upstream link (cf. [RFC6224]). On the arrival of an MN, the MAG decides on the mapping of downstream links to a proxy instance and the upstream link to the LMA based on the regular Binding Update List as maintained by PMIPv6 standard operations. When multicast data is received from the MN, the MAG MUST identify the corresponding proxy instance from the incoming interface and forwards multicast data upstream according to [RFC4605].
移动接入网关需要部署MLD代理实例，一个用于LMA的每个隧道，LMA作为其唯一的上游链路（参见[RFC6224]）。在MN到达时，MAG基于PMIPv6标准操作维护的常规绑定更新列表来决定下游链路到代理实例的映射以及上游链路到LMA的映射。当从MN接收到多播数据时，MAG必须从传入接口识别相应的代理实例，并根据[RFC4605]向上游转发多播数据。
The MAG MAY apply special admission control to enable multicast data transmission from an MN. It is advisable to take special care that MLD proxy implementations do not redistribute multicast data to downstream interfaces without appropriate subscriptions in place.
MAG可以应用特殊的许可控制来启用来自MN的多播数据传输。建议特别注意，如果没有适当的订阅，MLD代理实现不会将多播数据重新分发到下游接口。
For any MN, the Local Mobility Anchor acts as the persistent Home Agent and at the same time as the default multicast upstream for the corresponding MAG. It will manage and maintain a multicast forwarding information base for all group traffic arriving from its mobile sources. It SHOULD participate in multicast routing functions that enable traffic redistribution to all adjacent LMAs within the PMIPv6 domain and thereby ensure a continuous receptivity while the source is in motion.
对于任何MN，本地移动锚充当持久归属代理，同时充当相应MAG的默认多播上行。它将为从其移动源到达的所有组流量管理和维护多播转发信息库。它应该参与多播路由功能，使流量能够重新分配到PMIPv6域内的所有相邻lma，从而确保在源移动时连续接收。
Local Mobility Anchors that operate the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol [RFC4601] will require sources to be directly connected for sending PIM registers to the Rendezvous Point (RP). This does not hold in a PMIPv6 domain, as MAGs are routers intermediate to the MN and the LMA. In this sense, MNs are multicast sources external to the PIM-SM domain.
操作协议独立多播稀疏模式（PIM-SM）路由协议[RFC4601]的本地移动锚将要求直接连接源，以便将PIM寄存器发送到集合点（RP）。这不适用于PMIPv6域，因为MAG是MN和LMA的中间路由器。从这个意义上讲，MN是PIM-SM域外部的多播源。
To mitigate this incompatibility common to all subsidiary MLD proxy domains, the LMA MUST act as a PIM Border Router and activate the Border-bit. In this case, the DirectlyConnected(S) is treated as being TRUE for mobile sources and the PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel interface from MAG to LMA is not considered part of the PIM-SM component of the LMA (see Appendix A.1 of [RFC4601] ).
为了缓解所有辅助MLD代理域共同的这种不兼容性，LMA必须充当PIM边界路由器并激活边界位。在这种情况下，直接连接被视为适用于移动源，PIM-SM转发规则“iif==RPF_接口”被放宽为适用，因为从MAG到LMA的传入隧道接口不被视为LMA的PIM-SM组件的一部分（参见[RFC4601]的附录A.1]）。
In addition, an LMA serving as the PIM Designated Router (DR) is connected to MLD proxies via individual IP tunnel interfaces and will experience changing PIM source states on handover. As the incoming interface connects to a point-to-point link, PIM Assert contention is not active, and incoming interface validation is only performed by Reverse Path Forwarding (RPF) checks. Consequently, a PIM DR SHOULD update incoming source states, as soon as RPF inspection succeeds, i.e., after the PMIPv6 forwarding state update. Consequently, PIM routers SHOULD be able to manage these state changes, but some implementations are expected to incorrectly refuse packets until the previous state has timed out.
此外，用作PIM指定路由器（DR）的LMA通过单独的IP隧道接口连接到MLD代理，并且在切换时将经历PIM源状态的变化。当传入接口连接到点到点链路时，PIM断言争用不处于活动状态，传入接口验证仅通过反向路径转发（RPF）检查执行。因此，一旦RPF检查成功，即在PMIPv6转发状态更新之后，PIM DR应立即更新传入源状态。因此，PIM路由器应该能够管理这些状态更改，但是一些实现可能会错误地拒绝数据包，直到前一个状态超时。
Notably, running Bidirectional PIM (BIDIR-PIM) [RFC5015] on LMAs remains robust with respect to source location and does not require special configurations or state management for sources.
值得注意的是，在LMA上运行双向PIM（BIDIR-PIM）[RFC5015]在源位置方面保持稳健，并且不需要对源进行特殊配置或状态管理。
An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844]. For this purpose, an LMA can register an IPv4-Proxy-CoA in its Binding Cache, and the MAG can provide IPv4 support in its access network. Correspondingly, multicast membership management will be performed by the MN using IGMP. For 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.
PMIPv6域中的MN可以按照[RFC5844]中的规定透明地使用IPv4地址进行通信。为此，LMA可以在其绑定缓存中注册IPv4代理CoA，MAG可以在其接入网络中提供IPv4支持。相应地，多播成员管理将由MN使用IGMP执行。对于网络端的多播支持，需要以与IPv6完全相同的方式在MAG上部署IGMP代理功能。[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 they 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多播组分发时，基础结构无法将两个数据流标识为相同。因此，可以在异构网络层上转发重复数据。
The following points are worth noting about the scenario in [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中单独识别。由于以下原因，该场景仍然没有对多播通信进行任何特殊处理。
Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). Multicast data transmission from the MAG to the corresponding LMA is link-local between the routers and routing/forwarding remains independent of any individual MN. So, the MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain GRE in multicast communication (including MLD queries and reports). Multicast traffic is transmitted using router-to-router forwarding via the MAG-to-LMA tunnels and according to the MRIB of the MAG or the LMA. It remains independent of MN's unicast addresses, while the MAG proxy instance redistributes multicast data down the point-to-point links (interfaces) according to its local subscription states, independent of IP addresses of the MN.
来自和到MN的多播流通过点到点链路到达MAG（与单播相同）。从MAG到相应LMA的多播数据传输是路由器之间的本地链路，并且路由/转发保持独立于任何单个MN。因此，MAG代理和LMA不应使用GRE密钥标识符，而应在多播通信（包括MLD查询和报告）中使用普通GRE。通过MAG到LMA隧道并根据MAG或LMA的MRIB，使用路由器到路由器转发来传输多播流量。它仍然独立于MN的单播地址，而MAG代理实例根据其本地订阅状态沿着点到点链路（接口）重新分发多播数据，而不依赖于MN的IP地址。
The distribution system of the base solution directly follows PMIPv6 routing rules and organizes multicast domains with respect to LMAs. Thus, no coordination between address spaces or services is required between the different instances, provided their associated LMAs belong to disjoint multicast domains. Routing is optimal for communication between MNs of the same domain or stationary subscribers.
基本解决方案的分发系统直接遵循PMIPv6路由规则，并根据LMA组织多播域。因此，不同实例之间不需要地址空间或服务之间的协调，只要它们关联的LMA属于不相交的多播域。对于同一域或固定用户的MN之间的通信，路由是最优的。
In the following situations, efficiency-related issues remain.
在下列情况下，与效率有关的问题仍然存在。
Multicast reception at LMA In the current deployment scenario, the LMA will receive all multicast traffic originating from its associated MNs. There is no mechanism to suppress upstream forwarding in the absence of receivers.
LMA处的多播接收在当前部署场景中，LMA将接收来自其相关MN的所有多播流量。在没有接收机的情况下，没有抑制上行转发的机制。
MNs on the same MAG using different LMAs For a mobile receiver and a source that use different LMAs, the traffic has to go up to one LMA, cross over to the other LMA, and then be tunneled back to the same MAG, causing redundant flows in the access network and at the MAG.
使用不同LMA的同一MAG上的MNs对于使用不同LMA的移动接收器和源，流量必须上升到一个LMA，跨越到另一个LMA，然后通过隧道传输回同一MAG，从而导致接入网络和MAG中的冗余流。
These remaining deficits in routing efficiency can be resolved by adding peering functions to MLD proxies as described in Section 5.
如第5节所述，通过向MLD代理添加对等功能，可以解决路由效率方面的这些剩余缺陷。
There are deployment scenarios, where multicast services are available throughout the access network independent of the PMIPv6 routing system [RFC7028]. In these cases, the visited networks grant a local content distribution service (in contrast to LMA-based home subscription) with locally optimized traffic flows. It is also possible to deploy a mixed service model of local and LMA-based subscriptions, provided that a unique way of service selection is implemented. For example, access routers (MAGs) could decide on service access based on the multicast address G or the source-specific multicast (SSM) channel (S,G) under request. (See Appendix A for further discussions.)
存在部署场景，其中多播服务可在整个接入网络中独立于PMIPv6路由系统使用[RFC7028]。在这些情况下，访问的网络授予具有本地优化的业务流的本地内容分发服务（与基于LMA的家庭订阅相反）。还可以部署本地和基于LMA的订阅的混合服务模型，前提是实现了一种独特的服务选择方式。例如，接入路由器（mag）可以基于请求下的多播地址G或源特定多播（SSM）信道（S，G）来决定服务接入。（进一步讨论见附录A。）
Direct multicast access can be supported by
可以通过以下方式支持直接多播访问：
o native multicast routing provided by one multicast router that is neighboring MLD proxies deployed at MAGs within a flat access network, or via tunnel uplinks,
o 本地多播路由由一个多播路由器提供，该多播路由器是平面接入网络内部署在MAG的相邻MLD代理，或通过隧道上行链路，
o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM [RFC5015] deployed at the MAGs.
o 多播路由协议，例如部署在MAG的PIM-SM[RFC4601]或BIDIR-PIM[RFC5015]。
*** *** *** ***
* ** ** ** *
* *
* Multicast *
+----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+
| // \\ |
\\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *//
|| || || || * || Routing || *
+----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***|
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
*** *** *** ***
* ** ** ** *
* *
* Multicast *
+----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+
| // \\ |
\\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *//
|| || || || * || Routing || *
+----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***|
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
(a) 代理上行链路上的多播访问（b）MAG上的多播路由
Figure 3: Reference Networks for (a) Proxy-Assisted Direct Multicast Access and (b) Dynamic Multicast Routing at MAGs
图3：（a）代理辅助直接多播访问和（b）MAGs的动态多播路由的参考网络
Figure 3 displays the corresponding deployment scenarios that separate multicast from PMIPv6 unicast routing. It is assumed throughout these scenarios that all MAGs (MLD proxies) are linked to a single multicast routing domain. Notably, this scenario requires coordination of multicast address utilization and service bindings.
图3显示了将多播与PMIPv6单播路由分离的相应部署场景。在这些场景中，假设所有MAG（MLD代理）都链接到一个多播路由域。值得注意的是，此场景需要协调多播地址利用率和服务绑定。
Multicast traffic distribution can be simplified in these scenarios. A single proxy instance at MAGs with uplinks into the multicast domain will serve as a first-hop multicast gateway and avoid traffic duplication or detour routing. Multicast routing functions at MAGs will seamlessly embed access gateways within a multicast cloud. However, mobility of the multicast source in this scenario will require some multicast routing protocols to rebuild distribution trees. This can cause significant service disruptions or delays (see [RFC5757] for further aspects). Deployment details are specific to the multicast routing protocol in use; this is described below for common protocols.
在这些场景中，可以简化多播流量分布。MAGs上的单个代理实例与多播域的上行链路将用作第一跳多播网关，并避免流量重复或迂回路由。MAGs的多播路由功能将在多播云中无缝嵌入访问网关。然而，在这种情况下，多播源的移动性需要一些多播路由协议来重建分发树。这可能会导致严重的服务中断或延迟（有关更多方面，请参阅[RFC5757]）。部署详细信息特定于正在使用的多播路由协议；下面对常见协议进行了描述。
In a PMIPv6 domain, single MLD proxy instances can be deployed at each MAG that enable multicast service at the access via an uplink to a multicast service infrastructure (see Figure 3(a)). To avoid
在PMIPv6域中，可以在每个MAG部署单个MLD代理实例，这些实例通过多播服务基础设施的上行链路在接入点启用多播服务（见图3（a））。避
service disruptions on handovers, the uplinks of all proxies SHOULD be adjacent to the same next-hop multicast router. This can either be achieved by arranging proxies within a flat access network or by using upstream tunnels that terminate at a common multicast router.
服务中断在切换时，所有代理的上行链路应与同一下一跳多播路由器相邻。这可以通过在平面接入网络内安排代理或通过使用终止于公共多播路由器的上游隧道来实现。
Multicast data submitted by a mobile source will reach the MLD proxy at the MAG that subsequently forwards flows to the upstream and to all downstream interfaces with appropriate subscriptions. Traversing the upstream will transfer traffic into the multicast infrastructure (e.g., to a PIM Designated Router) that will route packets to all local MAGs that have joined the group, as well as further upstream according to protocol procedures and forwarding states.
由移动源提交的多播数据将到达MAG处的MLD代理，该代理随后将流转发到具有适当订阅的上游和所有下游接口。穿越上游将把流量转移到多播基础设施（例如，到PIM指定的路由器），该基础设施将把数据包路由到加入该组的所有本地MAG，以及根据协议过程和转发状态进一步向上游。
On handover, a mobile source will reattach to a new MAG and can continue to send multicast packets as soon as PMIPv6 unicast configurations have been completed. Like at the previous MAG, the new MLD proxy will forward data upstream and downstream to subscribers. Listeners local to the previous MAG will continue to receive group traffic via the local multicast distribution infrastructure following aggregated listener reports of the previous proxy. In general, traffic from the mobile source continues to be transmitted via the same next-hop multicast router using the same source address and thus remains unchanged when seen from the wider multicast infrastructure.
在切换时，移动源将重新连接到新的MAG，并且一旦完成PMIPv6单播配置，就可以继续发送多播数据包。与之前的MAG一样，新的MLD代理将向订阅者转发上游和下游数据。在前一个代理的聚合侦听器报告之后，前一个MAG的本地侦听器将继续通过本地多播分发基础结构接收组流量。一般来说，来自移动源的流量继续使用相同的源地址经由相同的下一跳多播路由器传输，因此从更广泛的多播基础设施来看保持不变。
A mobile source that transmits data via an MLD proxy will not be directly connected to a PIM Designated Router as discussed in Section 3.2.3.1. Countermeasures apply correspondingly.
如第3.2.3.1节所述，通过MLD代理传输数据的移动源不会直接连接到PIM指定的路由器。相应地采取对策。
A PIM Designated Router that is connected to MLD proxies via individual IP tunnel interfaces will experience invalid PIM source states on handover. In some implementations of PIM-SM, this could lead to an interim packet loss (see Section 3.2.3.1). This problem can be mitigated by aggregating proxies on a lower layer.
通过单个IP隧道接口连接到MLD代理的PIM指定路由器在切换时将遇到无效的PIM源状态。在PIM-SM的某些实现中，这可能导致临时数据包丢失（见第3.2.3.1节）。通过在较低层上聚合代理，可以缓解此问题。
Source-specific subscriptions invalidate with routes, whenever the source moves from or to the MAG/proxy of a subscriber. Multicast forwarding states will rebuild with unicast route changes. However, this may lead to noticeable service disruptions for locally subscribed nodes.
每当源从订阅服务器的MAG/代理移动或移动到订阅服务器的MAG/代理时，源特定订阅将随路由而失效。多播转发状态将随着单播路由的更改而重建。但是，这可能会导致本地订阅节点的明显服务中断。
The full-featured multicast routing protocol PIM-SM MAY be deployed in the access network for providing multicast services in parallel to unicast routes (see Figure 3(b)). Throughout this section, it is assumed that the PMIPv6 mobility domain is part of a single PIM-SM multicast routing domain with PIM-SM routing functions present at all MAGs and all LMAs. The PIM routing instance at a MAG SHALL then serve as the Designated Router (DR) for all directly attached Mobile Nodes. For expediting handover operations, it is advisable to position PIM Rendezvous Points (RPs) in the core of the PMIPv6 network domain. However, regular IP routing tables need not be present in a PMIPv6 deployment, and additional effort is required to establish reverse path forwarding rules as required by PIM-SM.
功能齐全的多播路由协议PIM-SM可部署在接入网络中，以提供与单播路由并行的多播服务（见图3（b））。在本节中，假设PMIPv6移动域是单个PIM-SM多播路由域的一部分，所有MAG和所有LMA中都存在PIM-SM路由功能。然后，MAG处的PIM路由实例应作为所有直接连接的移动节点的指定路由器（DR）。为了加快切换操作，建议将PIM会合点（RPs）定位在PMIPv6网络域的核心中。然而，常规IP路由表不需要出现在PMIPv6部署中，并且需要额外的努力来建立PIM-SM所要求的反向路径转发规则。
In this scenario, PIM-SM will rely on a Multicast Routing Information Base (MRIB) that is generated independently of the policy-based routing rules of PMIPv6. The granularity of mobility-related routing locators required in PIM depends on the complexity (specific phase) of its deployment.
在这种情况下，PIM-SM将依赖于多播路由信息库（MRIB），该信息库独立于PMIPv6基于策略的路由规则生成。PIM中所需的移动相关路由定位器的粒度取决于其部署的复杂性（特定阶段）。
For all three phases in the operation of PIM (see [RFC4601]), the following information is needed.
对于动力传动系接口模块操作的所有三个阶段（参见[RFC4601]），需要以下信息。
o All routes to networks and nodes (including RPs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among PIM routers and MUST remain unaffected by node mobility. The setup of these general routes is expected to follow the topology of the operator network and is beyond the scope of this document.
o 非PMIPv6域移动成员的网络和节点（包括RP）的所有路由必须在PIM路由器之间一致定义，并且必须不受节点移动性的影响。这些常规路由的设置应遵循运营商网络的拓扑结构，不在本文件的范围内。
The following route entries are required at a PIM-operating MAG when phase two or three of PIM or PIM-SSM is in operation.
当PIM或PIM-SSM的第二或第三阶段运行时，PIM运行MAG需要以下路线条目。
o Local routes to the Home Network Prefixes (HNPs) of all MNs associated with their corresponding point-to-point attachments that MUST be included in the local MRIB.
o 与本地MRIB中必须包含的相应点到点附件相关联的所有MN的家庭网络前缀（HNP）的本地路由。
o All routes to MNs that are attached to distant MAGs of the PMIPv6 domain point towards their corresponding LMAs. These routes MUST be made available in the MRIB of all PIM routers (except for the local MAG of attachment), but they MAY be eventually expressed by an appropriate default entry.
o 连接到PMIPv6域的远程MAG的所有MN路由指向其相应的LMA。这些路由必须在所有PIM路由器的MRIB中可用（附件的本地MAG除外），但它们最终可能由适当的默认条目表示。
A new mobile source S will transmit multicast data of group G towards its MAG of attachment. Acting as a PIM DR, the access gateway will unicast-encapsulate the multicast packets and forward the data to the Virtual Interface (VI) with encapsulation target RP(G), a process known as "PIM source registering". The RP will decapsulate and natively forward the packets down the RP-based distribution tree towards (mobile and stationary) subscribers.
新的移动源S将向其连接的MAG发送组G的多播数据。作为PIM DR，接入网关将单播封装多播数据包，并将数据转发到封装目标RP（G）的虚拟接口（VI），这一过程称为“PIM源注册”。RP将解除封装并沿基于RP的分发树以本机方式将数据包转发给（移动和固定）用户。
On handover, the point-to-point link connecting the mobile source to the old MAG will go down and all (S,*) flows terminate. In response, the previous DR (MAG) deactivates the data encapsulation channels for the transient source (i.e., all DownstreamJPState(S,*,VI) are set to NoInfo state). After reattaching and completing unicast handover negotiations, the mobile source can continue to transmit multicast packets, while being treated as a new source at its new DR (MAG). Source register encapsulation will be immediately initiated, and (S,G) data continue to flow natively down the (*,G) RP-based tree.
切换时，将移动源连接到旧MAG的点对点链路将断开，所有（S，*）流终止。作为响应，先前的DR（MAG）停用瞬态源的数据封装通道（即，所有下游Pstate（S，*，VI）设置为NoInfo状态）。在重新连接并完成单播切换协商之后，移动源可以继续发送多播分组，同时在其新DR（MAG）处被视为新源。源寄存器封装将立即启动，并且（S，G）数据将继续以本机方式沿着基于（*，G）RP的树向下流动。
Source handover management in PIM phase one admits low complexity and remains transparent to receivers. In addition, the source register tunnel management of PIM is a fast protocol operation that introduces little overhead. In a PMIPv6 deployment, PIM RPs MAY be configured to uninitiated (S,G) shortest path trees for mobile sources, and thus remain in phase one of the protocol. The price to pay for such simplified deployment lies in possible routing detours by an overall RP-based packet distribution.
PIM第一阶段中的源切换管理允许较低的复杂性，并且对接收机保持透明。此外，PIM的源寄存器隧道管理是一种快速的协议操作，引入的开销很小。在PMIPv6部署中，PIM-RPs可被配置为移动源的未初始化（S，G）最短路径树，并因此保持在协议的第一阶段。这种简化部署的代价在于通过基于RP的整体数据包分发可能的路由迂回。
After receiving source register packets, a PIM RP eventually will initiate a source-specific Join for creating a shortest path tree to the (mobile) source S and issue a source register stop at the native arrival of data from S. For initiating an (S,G) tree, the RP, as well as all intermediate routers, require route entries for the HNP of the MN that -- unless the RP coincides with the MAG of S -- point towards the corresponding LMA of S. Consequently, the (S,G) tree will proceed from the RP via the (stable) LMA, down the LMA-MAG tunnel to the mobile source. This tree can be of lower routing efficiency than the PIM source register tunnel established in phase one.
在接收到源寄存器数据包后，PIM RP最终将启动源特定连接，以创建到（移动）源S的最短路径树，并在来自S的数据本机到达时发出源寄存器停止。为了启动（S，G）树，RP以及所有中间路由器，要求MN HNP的路由入口，除非RP与S的MAG一致，否则该入口指向S的相应LMA。因此，（S，G）树将通过（稳定）LMA从RP开始，沿着LMA-MAG隧道到达移动源。该树的路由效率可能低于第一阶段中建立的PIM源寄存器隧道。
On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new point of attachment. However, in the absence of a corresponding multicast forwarding state, the new DR will treat S as a new source and initiate a source registering of PIM phase one with the RP. In
切换时，移动源重新连接到新的MAG（DR），PMIPv6单播管理将LMA-MAG隧道传输到新的连接点。然而，在没有相应的多播转发状态的情况下，新的DR将把S视为新的源，并在中向RP发起PIM第一阶段的源注册
response, the PIM RP will recognize the known source at a new (tunnel) interface and will immediately respond with a register stop. As the RP had previously joined the shortest path tree towards the source via the LMA, it will see an RPF change when data arrives at a new interface. This is implementation dependent and can trigger an update of the PIM MRIB as well as a new PIM Join message that will install the multicast forwarding state missing at the new MAG. Otherwise, the tree is periodically updated by Joins transmitted towards the new MAG on a path via the LMA. In proceeding this way, a quick recovery of PIM transition from phase one to two will be performed per handover.
响应时，PIM RP将识别新（隧道）接口处的已知源，并立即响应寄存器停止。由于RP先前通过LMA加入了通向源的最短路径树，因此当数据到达新接口时，它将看到RPF发生变化。这取决于实现，并且可以触发PIM MRIB的更新以及将在新MAG处安装丢失的多播转发状态的新PIM加入消息。否则，通过通过LMA在路径上向新MAG传输的加入定期更新树。通过这种方式，将在每次移交时快速恢复从第一阶段到第二阶段的PIM过渡。
In response to an exceeded threshold of packet transmission, DRs of receivers eventually will initiate a source-specific Join for creating a shortest path tree to the (mobile) source S, thereby transitioning PIM into the final shortcut phase three. For all receivers not sharing a MAG with S, this (S,G) tree will range from the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the serving MAG to the mobile source. This tree is of higher routing efficiency than that established in the previous phase two, but it need not outperform the PIM source register tunnel established in phase one. It provides the advantage of immediate data delivery to receivers that share a MAG with S.
作为对超过的分组传输阈值的响应，接收器的DRs最终将发起特定于源的连接，以创建到（移动）源的最短路径树，从而将PIM过渡到最后的快捷方式阶段3。对于不与S共享MAG的所有接收器，该（S，G）树的范围从通过（稳定）LMA的接收DR、LMA-MAG隧道和服务MAG到移动源。该树的路由效率高于前两阶段中建立的路由效率，但不需要优于第一阶段中建立的PIM源寄存器隧道。它为与S共享MAG的接收器提供了即时数据传输的优势。
On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new point of attachment. However, in the absence of a corresponding multicast forwarding state, the new DR will treat S as a new source and initiate a source registering of PIM phase one. A PIM implementation compliant with this change can recover phase three states in the following way. First, the RP recovers to phase two as described in the previous section and will not forward data arriving via the source register tunnel. Tree maintenance eventually triggered by the RPF change (see Section 4.3.3) will generate proper states for a native forwarding from the new MAG via the LMA. Thereafter, packets arriving at the LMA without source register encapsulation are forwarded natively along the shortest path tree towards receivers.
切换时，移动源重新连接到新的MAG（DR），PMIPv6单播管理将LMA-MAG隧道传输到新的连接点。然而，在没有相应的多播转发状态的情况下，新的DR将把S视为新的源，并启动PIM第一阶段的源注册。符合此更改的PIM实现可以通过以下方式恢复第三阶段状态。首先，RP恢复到前一节所述的第二阶段，并且不会转发通过源寄存器隧道到达的数据。RPF变更（见第4.3.3节）最终触发的树维护将为新MAG通过LMA的本机转发生成适当的状态。此后，到达LMA而没有源寄存器封装的分组沿着最短路径树本地转发到接收机。
In consequence, the PIM transitions from phase one to two to three will be quickly recovered per handover but still lead to an enhanced signaling load and intermediate packet loss.
因此，PIM从第一阶段到第二阶段到第三阶段的转换将在每次切换时快速恢复，但仍会导致增强的信令负载和中间分组丢失。
Source-specific Joins of receivers will guide PIM to operate in SSM mode and lead to an immediate establishment of source-specific shortest path trees. Such (S,G) trees will equal the distribution system of PIM's final phase three (see Section 4.3.4). However, on handover and in the absence of RP-based data distribution, SSM data delivery cannot be resumed via source registering as in PIM phase one. Consequently, data packets transmitted after a handover will be discarded at the MAG until regular tree maintenance has reestablished the (S,G) forwarding state at the new MAG.
接收机的源特定连接将引导PIM在SSM模式下运行，并导致立即建立源特定的最短路径树。此类（S，G）树将等于PIM最终第三阶段的配电系统（见第4.3.4节）。但是，在切换时，在没有基于RP的数据分发的情况下，无法通过源注册恢复SSM数据交付，如PIM第一阶段。因此，切换后发送的数据包将在MAG处丢弃，直到常规树维护在新MAG处重新建立（S，G）转发状态。
Source-specific shortest path trees are constructed in PIM-SM (phase two and three) and in PIM-SSM. These RPF-trees traverse LMA-MAG tunnels towards a source. As PIM remains unaware of source mobility management, these trees invalidate under handovers with each tunnel re-establishment at a new MAG. Regular tree maintenance of PIM will recover the states, but it remains unsynchronized and too slow to seamlessly preserve PIM data distribution services.
源特定最短路径树在PIM-SM（第二阶段和第三阶段）和PIM-SSM中构建。这些RPF树穿过LMA-MAG隧道到达一个震源。由于PIM仍然不知道源移动性管理，这些树在切换时会失效，每次在新的MAG重新建立隧道时都会失效。PIM的定期树维护将恢复状态，但它仍然不同步，速度太慢，无法无缝地保留PIM数据分发服务。
A method to quickly recover PIM (S,G) trees under handover SHOULD synchronize multicast state maintenance with unicast handover operations and can proceed as follows. On handover, an LMA reads all (S,G) Join states from its corresponding tunnel interface and identifies those source addresses S_i that match moving HNPs. After re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join states with the new tunnel endpoint and immediately trigger a state maintenance (PIM Join) message. In proceeding this way, the source-specific PIM states are transferred to the new tunnel endpoint and propagated to the new MAG in synchrony with unicast handover procedures.
在切换下快速恢复PIM（S，G）树的方法应将多播状态维护与单播切换操作同步，并可按如下步骤进行。在切换时，LMA从其相应的隧道接口读取所有（S，G）连接状态，并识别与移动hnp匹配的源地址S_i。重新建立新隧道后，它应将（S_i，*）连接状态与新隧道端点关联，并立即触发状态维护（PIM Join）消息。通过这种方式，源特定的PIM状态被传输到新的隧道端点，并与单播切换过程同步地传播到新的MAG。
BIDIR-PIM MAY be deployed in the access network for providing multicast services in parallel to unicast routes. Throughout this section, it is assumed that the PMIPv6 mobility domain is part of a single BIDIR-PIM multicast routing domain with BIDIR-PIM routing functions present at all MAGs and all LMAs. The PIM routing instance at a MAG SHALL then serve as the Designated Forwarder (DF) for all directly attached Mobile Nodes. For expediting handover operations, it is advisable to position BIDIR-PIM Rendezvous Point Addresses (RPAs) in the core of the PMIPv6 network domain. As regular IP routing tables need not be present in a PMIPv6 deployment, reverse path forwarding rules as required by BIDIR-PIM need to be established.
BIDIR-PIM可以部署在接入网络中，以提供与单播路由并行的多播服务。在本节中，假设PMIPv6移动域是单个BIDIR-PIM多播路由域的一部分，所有mag和所有lma中都存在BIDIR-PIM路由功能。然后，MAG处的PIM路由实例应作为所有直接连接移动节点的指定转发器（DF）。为了加快切换操作，建议将BIDIR-PIM集合点地址（RPA）定位在PMIPv6网络域的核心中。由于PMIPv6部署中不需要常规IP路由表，因此需要建立BIDIR-PIM所需的反向路径转发规则。
In this scenario, BIDIR-PIM will rely on a Multicast Routing Information Base (MRIB) that is generated independently of the policy-based routing rules of PMIPv6. The following information is needed.
在这种情况下，BIDIR-PIM将依赖于多播路由信息库（MRIB），该信息库独立于PMIPv6的基于策略的路由规则生成。需要以下信息。
o All routes to networks and nodes (including RPAs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among BIDIR-PIM routers and remain unaffected by node mobility. The setup of these general routes is expected to follow the topology of the operator network and is beyond the scope of this document.
o 必须在BIDIR-PIM路由器之间一致地定义到非PMIPv6域移动成员的网络和节点（包括RPA）的所有路由，并且不受节点移动性的影响。这些常规路由的设置应遵循运营商网络的拓扑结构，不在本文件的范围内。
BIDIR-PIM will establish spanning trees across its network domain in conformance to its pre-configured RPAs and the routing information provided. Multicast data transmitted by a mobile source will immediately be forwarded by its DF (MAG) onto the spanning tree for the multicast group without further protocol operations.
BIDIR-PIM将根据其预先配置的RPA和提供的路由信息，在其网络域中建立生成树。移动源传输的多播数据将立即由其DF（MAG）转发到多播组的生成树上，而无需进一步的协议操作。
On handover, the mobile source reattaches to a new MAG (DF), which completes unicast network configurations. Thereafter, the source can immediately proceed with multicast packet transmission onto the pre-established distribution tree. BIDIR-PIM does not require protocol signaling or additional reconfiguration delays to adapt to source mobility, and it can be considered the protocol of choice for mobile multicast operations in the access network. As multicast streams always flow up to the Rendezvous Point Link, some care should be taken to configure RPAs compliant with network capacities.
在切换时，移动源重新连接到新的MAG（DF），从而完成单播网络配置。此后，源可以立即在预先建立的分发树上进行多播分组传输。BIDIR-PIM不需要协议信令或额外的重新配置延迟来适应源移动性，并且它可以被认为是接入网络中移动多播操作的首选协议。由于多播流始终流向集合点链路，因此应注意配置符合网络容量的RPA。
A deployment of MLD proxies (see [RFC4605]) at MAGs has proven a useful and appropriate approach to multicast in PMIPv6; see [RFC6224] and [RFC7028]. However, deploying unmodified standard proxies can go along with significant performance degradation for mobile senders as discussed in this document. To overcome these deficits, an optimized approach to multicast source mobility based on extended peering functions among proxies is defined in this section. Based on such direct data exchange between proxy instances at MAGs, triangular routing is avoided and multicast streams can be disseminated directly within a PMIPv6 access network, and in particular within MAG routing machines. Prior to presenting the solution, we will summarize the relevant requirements.
在MAGs部署MLD代理（见[RFC4605]）已证明是PMIPv6中多播的一种有用且适当的方法；参见[RFC6224]和[RFC7028]。但是，部署未经修改的标准代理可能会导致本文档中讨论的移动发件人的性能显著降低。为了克服这些缺陷，本节定义了一种基于代理间扩展对等函数的多播源移动性优化方法。基于MAG上代理实例之间的这种直接数据交换，避免了三角路由，并且可以在PMIPv6接入网络内，特别是在MAG路由机器内，直接传播多播流。在介绍解决方案之前，我们将总结相关需求。
Solutions that extend MLD proxies by additional uplinking functions need to comply to the following requirements.
通过附加上行链路功能扩展MLD代理的解决方案需要符合以下要求。
Prevention of routing loops In the absence of a full-featured routing logic at an MLD proxy, simple and locally decidable rules need to prevent source traffic from traversing the network in loops that would be potentially enabled by multiple uplinks.
防止路由循环在MLD代理上没有全功能路由逻辑的情况下，简单且本地可确定的规则需要防止源流量在可能由多个上行链路启用的循环中穿越网络。
Unique coverage of receivers Listener functions at proxies require simple, locally decidable rules to initiate a unique delivery of multicast packets to all receivers.
在代理中，接收器侦听器功能的唯一覆盖需要简单的、本地可确定的规则来启动对所有接收器的唯一多播数据包交付。
Following local filtering techniques, these requirements are met in the following solution.
根据本地过滤技术，以下解决方案满足了这些要求。
A peering interface for MLD proxies allows for a direct data exchange of locally attached multicast sources. Such peering interfaces can be configured -- as a direct link or a bidirectional tunnel -- between any two proxy instances (locally deployed as in [RFC6224] or remotely deployed). Peerings remain as silent virtual links in regular proxy operations. Data is exchanged on such links only in cases where one peering proxy on its downstream directly connects to a source of multicast traffic to which the other peering proxy actively subscribes. In such cases, the proxy connected to the source will receive a listener report on its peering interface and will forward traffic from its local source accordingly. It is worth noting that multicast traffic distribution on peering links does not follow reverse unicast paths to sources. In the following, operations are defined for Any-Source Multicast (ASM) and SSM, but they provide superior performance in the presence of source-specific signaling (IGMPv3/MLDv2) [RFC4604].
MLD代理的对等接口允许本地连接的多播源的直接数据交换。这种对等接口可以配置为任意两个代理实例之间的直接链路或双向隧道（如[RFC6224]中所述本地部署或远程部署）。对等在常规代理操作中保持为静默虚拟链接。只有在其下游的一个对等代理直接连接到另一个对等代理主动订阅的多播流量源的情况下，才在此类链路上交换数据。在这种情况下，连接到源的代理将在其对等接口上接收侦听器报告，并相应地转发来自其本地源的流量。值得注意的是，对等链路上的多播流量分布并不遵循到源的反向单播路径。在下文中，为任何源多播（ASM）和SSM定义了操作，但它们在存在源特定信令（IGMPv3/MLDv2）[RFC4604]的情况下提供了优异的性能。
An MLD proxy with the perspective of a sender will see peering interfaces as restricted downstream interfaces. It will install and maintain source filters at its peering links that will restrict data transmission to those packets that originate from a source that is locally attached at one of its downstream interfaces.
具有发送方视角的MLD代理将对等接口视为受限制的下游接口。它将在其对等链路上安装并维护源过滤器，该过滤器将数据传输限制为源于本地连接到其下游接口之一的源的数据包。
In detail, a proxy will extract from its configuration the network prefixes attached to its downstream interfaces and MUST implement a source filter base at its peering interfaces that restricts data transmission to IP source addresses from its local prefixes. This filter base MUST be updated if and only if the downstream configuration changes (e.g., due to mobility). Multicast packets that arrive from the upstream interface of the proxy are thus prevented from traversing any peering link, but they are only forwarded to regular downstream interfaces with appropriate subscription states. In this way, multihop forwarding on peering links is prevented.
具体而言，代理将从其配置中提取连接到其下游接口的网络前缀，并且必须在其对等接口处实现源过滤器基，以限制从其本地前缀到IP源地址的数据传输。当且仅当下游配置发生变化（例如，由于移动性）时，必须更新该过滤器基础。因此，从代理的上游接口到达的多播数据包被阻止穿越任何对等链路，但它们仅被转发到具有适当订阅状态的常规下游接口。这样，可以防止对等链路上的多跳转发。
Multicast traffic arriving from a locally attached source will be forwarded to the regular upstream interface and all downstream interfaces with appropriate subscription states (i.e., regular proxy operations). In addition, multicast packets of local origin are transferred to those peering interfaces with appropriate subscription states.
来自本地连接源的多播流量将转发到具有适当订阅状态（即常规代理操作）的常规上游接口和所有下游接口。此外，本地来源的多播数据包被传输到具有适当订阅状态的对等接口。
On the listener side, peering interfaces appear as preferred upstream links. The multicast proxy will attempt to receive multicast services on peering links for as many groups (channels) as possible. The general upstream interface configured according to [RFC4605] will be used only for retrieving those groups (channels) that remain unavailable from peerings. From this extension of [RFC4605], an MLD proxy with peering interconnects will exhibit several interfaces for pulling remote traffic: the regular upstream and the peerings. Traffic available from any of the peering links will be mutually disjoint but normally also available from the upstream. To prevent duplicate traffic from arriving at the listener side, the proxy
在侦听器端，对等接口显示为首选的上游链路。多播代理将尝试在对等链路上为尽可能多的组（通道）接收多播服务。根据[RFC4605]配置的通用上游接口将仅用于检索从对等网络中仍然不可用的组（通道）。从[RFC4605]的这个扩展中，一个具有对等互连的MLD代理将展示几个用于拉动远程通信的接口：常规上游和对等。来自任何对等链路的可用流量将相互不相交，但通常也可从上游获得。为了防止重复流量到达侦听器端，代理
o MAY delay aggregated reports to the upstream, and
o 可能会延迟向上游提交聚合报告，以及
o MUST apply appropriate filters to exclude duplicate streams.
o 必须应用适当的筛选器以排除重复流。
In detail, an MLD proxy instance at a MAG first issues listener reports (in parallel) to all of its peering links. These links span at most one (virtual) hop. Whenever certain group traffic (SSM channels) does not arrive from the peerings after a waiting time (default: 10 ms (node-local) and 25 ms (remote)), additional reports (complementary reports, in the case of SSM) are sent to the standard upstream interface.
具体地说，MAG上的MLD代理实例首先（并行地）向其所有对等链接发出侦听器报告。这些链接最多跨越一个（虚拟）跃点。当某些组通信量（SSM信道）在等待时间（默认值：10ms（节点本地）和25ms（远程））后未从对等方到达时，将向标准上游接口发送附加报告（SSM情况下的补充报告）。
Whenever traffic from a peering link arrives, an MLD proxy MUST install source filters at its upstream interfaces (as described in RFC 4605) in the following way.
每当来自对等链路的流量到达时，MLD代理必须按照以下方式在其上游接口（如RFC 4605中所述）安装源过滤器。
ASM with IGMPv2/MLDv1: In the presence of ASM using IGMPv2/MLDv1, only, the proxy cannot signal source filtering to its upstream. Correspondingly, it applies (S,*) ingress filters at its upstream interface for all sources S seen in traffic on the peering links. It is noteworthy that unwanted traffic is still replicated to the proxy via the (wired) provider backbone, but it is not forwarded into the wireless access network.
带IGMPv2/MLDv1的ASM：仅当存在使用IGMPv2/MLDv1的ASM时，代理无法将信号源过滤到其上游。相应地，它在其上游接口处对对等链路上的流量中看到的所有源应用（S，*）入口过滤器。值得注意的是，不需要的流量仍然通过（有线）提供商主干网复制到代理服务器，但不会转发到无线接入网络。
ASM with IGMPv3/MLDv2: In the presence of source-specific signaling (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude mode for all sources S seen in traffic of the peering links. The corresponding source-specific signaling will prevent forwarding of duplicate traffic throughout the access network.
带IGMPv3/MLDv2的ASM：在存在源特定信令（IGMPv3/MLDv2）的情况下，对于对等链路的流量中看到的所有源，上游接口被设置为（S，*）排除模式。相应的源特定信令将防止在整个接入网络中转发重复通信量。
SSM: In the presence of Source-Specific Multicast, the proxy will subscribe on its uplink interface to those (S,G) channels, only, that do not arrive via the peering links.
SSM：在存在特定于源的多播的情况下，代理将在其上行链路接口上订阅那些（S，G）信道，这些信道不会通过对等链路到达。
MLD proxies will install data-driven timers (source-timeout) for each source but common to all peering interfaces to detect interruptions of data services from individual sources at proxy peers. Termination of source-specific flows may be application specific, but also may be due to a source handover or a transmission failure. After a handover, a mobile source may reattach at another MLD proxy with a peering relation to the listener, or at a proxy that does not peer. While in the first case, traffic reappears on another peering link; in the second case, data can only be retrieved via the regular upstream. To account for the latter, the MLD proxy revokes the source-specific filter(s) at its upstream interface, after the source-timeout expires (default: 50 ms). Corresponding traffic will then be pulled from the regular upstream interface. Source-specific filters MUST be reinstalled whenever traffic of this source arrives at any peering interface.
MLD代理将为每个源安装数据驱动计时器（源超时），但对所有对等接口通用，以检测来自代理对等点的单个源的数据服务中断。源特定流的终止可能是应用特定的，但也可能是由于源切换或传输故障造成的。在切换之后，移动源可以在另一个与侦听器具有对等关系的MLD代理上重新连接，或者在不对等的代理上重新连接。而在第一种情况下，流量重新出现在另一个对等链路上；在第二种情况下，只能通过常规的上游检索数据。为了说明后者，MLD代理在源超时过期（默认值：50毫秒）后，在其上游接口处撤销源特定的筛选器。相应的流量随后将从常规上游接口中提取。每当此源的流量到达任何对等接口时，必须重新安装源特定的筛选器。
There is a noteworthy trade-off between traffic minimization and available traffic at the upstream that is locally filtered at the proxy. Implementors can use this relation to optimize for service-specific requirements.
在流量最小化和上游可用流量之间存在一个值得注意的权衡，上游可用流量在代理服务器上进行本地过滤。实现者可以使用这种关系来优化特定于服务的需求。
In proceeding this way, multicast group data will arrive from peering interfaces first, while only peer-wise unavailable traffic is retrieved from the regular upstream interface.
通过这种方式，多播组数据将首先从对等接口到达，而只有对等不可用的流量从常规上游接口检索。
This document defines multicast sender mobility based on PMIPv6 and common multicast routing protocols. Consequently, threats identified as security concerns in [RFC2236], [RFC2710], [RFC3810], [RFC4605], [RFC5213], and [RFC5844] are inherited by this document.
本文档定义了基于PMIPv6和通用多播路由协议的多播发送方移动性。因此，本文档继承了[RFC2236]、[RFC2710]、[RFC3810]、[RFC4605]、[RFC5213]和[RFC5844]中确定为安全问题的威胁。
In addition, 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 arise from rapid state changes, as well as from high-volume data streams routed into access networks of limited capacities. In cases of PIM-SM deployment, handover operations of the MNs include re-registering sources at the Rendezvous Points at possibly high frequency. In addition to proper authorization checks of MNs, rate controls at routing agents and replicators may be needed to protect the agents and the downstream networks. In particular, MLD proxy implementations at MAGs SHOULD automatically erase multicast state on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will in general not actively terminate group membership prior to departure.
此外，应特别注意在网络实体处结合多播和移动性管理的含义。由于该规范允许移动节点在更改附件的同时在MAG和LMA处发起多播转发状态的创建，PMIP路由器和接入网络的资源耗尽威胁来自于快速状态变化，以及路由到容量有限的接入网络的大容量数据流。在PIM-SM部署的情况下，MNs的切换操作包括以可能高的频率在集合点重新注册源。除了对MN进行适当的授权检查外，可能还需要在路由代理和复制器处进行速率控制，以保护代理和下游网络。特别是，MAG上的MLD代理实现应在MNs离开时自动擦除多播状态，因为PMIPv6域中的移动多播侦听器通常不会在离开前主动终止组成员资格。
The deployment of IGMP/MLD proxies for multicast routing requires particular care, as routing loops on the upstream are not automatically detected. Peering functions between proxies extend this threat in the following way. Routing loops among peering and upstream interfaces are prevented by filters on local sources. Such filtering can fail whenever prefix configurations for downstream interfaces at a proxy are incorrect or inconsistent. Consequently, implementations of peering-enabled proxies SHOULD take particular care on keeping IP configurations consistent at the downstream in a reliable and timely manner. (See [RFC6224] for requirements on PMIPv6-compliant implementations of MLD proxies.)
为多播路由部署IGMP/MLD代理需要特别小心，因为不会自动检测到上游的路由循环。代理之间的对等功能以以下方式扩展此威胁。本地源上的过滤器阻止对等接口和上游接口之间的路由循环。当代理上下游接口的前缀配置不正确或不一致时，这种过滤可能会失败。因此，支持对等的代理的实现应该特别注意以可靠和及时的方式保持下游IP配置的一致性。（有关符合PMIPv6的MLD代理实现的要求，请参见[RFC6224]）
The authors would like to thank (in alphabetical order) David Black, Luis M. Contreras, Spencer Dawkins, Muhamma Omer Farooq, Bohao Feng, Sri Gundavelli, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li, Cong Liu, Radia Perlman, Akbar Rahman, Behcet Sarikaya, Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, and Zhi-Wei Yan for advice, help, and reviews of the document. Funding by the German Federal Ministry of Education and Research within the G-LAB Initiative (projects HAMcast, Mindstone, and SAFEST) is gratefully acknowledged.
作者要感谢（按字母顺序排列）大卫·布莱克、路易斯·孔特雷拉斯、斯宾塞·道金斯、穆罕默德·奥马尔·法鲁克、冯伯豪、斯里·冈达维利、德克·冯·雨果、宁空、朱尼·科霍宁、何武丽、刘聪、拉迪亚·帕尔曼、阿克巴·拉赫曼、贝塞特·萨里卡亚、斯蒂格·维纳斯、李莉·王、塞巴斯蒂安·沃尔克、钱武和志伟言的建议、帮助，以及对文件的审查。感谢德国联邦教育和研究部在G-LAB计划（HAMcast、Mindstone和SAFEST项目）内提供的资金。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[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月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[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月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[MULTI-EXT] Schmidt, T., Ed., Waehlisch, M., Koodli, R., Fairhurst, G., and D. Liu, "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Work in Progress, May 2014.
[MULTI-EXT]Schmidt，T.，Ed.，Waehlisch，M.，Koodli，R.，Fairhurst，G.，和D.Liu，“MIPv6和PMIPv6快速切换的多播侦听器扩展”，正在进行中，2014年5月。
[PEERING-ANALYSIS] Schmidt, TC., Woelke, S., and M. Waehlisch, "Peer my Proxy - A Performance Study of Peering Extensions for Multicast in Proxy Mobile IP Domains", Proc. of 7th IFIP Wireless and Mobile Networking Conference (WMNC 2014), IEEE Press, May 2014.
[对等分析]Schmidt，TC.，Woelke，S.，和M.Waehlisch，“对等我的代理-代理移动IP域中多播对等扩展的性能研究”，Proc。第七届IFIP无线和移动网络会议（WMNC 2014），IEEE出版社，2014年5月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[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月。
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6224]Schmidt，T.，Waehlisch，M.，和S.Krishnan，“代理移动IPv6（PMIPv6）域中支持多播侦听器的基本部署”，RFC 62242011年4月。
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013.
[RFC7028]Zuniga，JC.，Contreras，LM.，Bernardos，CJ.，Jeon，S.，和Y.Kim，“代理移动IPv6的多播移动路由优化”，RFC 7028，2013年9月。
[RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)", RFC 7161, March 2014.
[RFC7161]Contreras，LM.，Bernardos，CJ.，和I.Soto，“通过LMA（SIAL）获取订阅信息实现代理移动IPv6（PMIPv6）多播切换优化”，RFC 7161，2014年3月。
In this section, we document upstream extensions for an MLD proxy that were originally developed during the work on this document. Multiple proxy instances deployed at a single MAG (see Section 3) can be avoided by adding multiple upstream interfaces to a single MLD proxy. In a typical PMIPv6 deployment, each upstream interface of a single proxy instance can interconnect to one of the LMAs. With such ambiguous upstream options, appropriate forwarding rules MUST be supplied to
在本节中，我们将记录MLD代理的上游扩展，该代理最初是在编写本文档的过程中开发的。通过向单个MLD代理添加多个上游接口，可以避免在单个MAG上部署多个代理实例（参见第3节）。在典型的PMIPv6部署中，单个代理实例的每个上游接口都可以互连到其中一个LMA。对于这种不明确的上游选项，必须向用户提供适当的转发规则
o unambiguously guide traffic forwarding from directly attached mobile sources, and
o 明确引导来自直接连接的移动源的流量转发，以及
o lead listener reports to initiating unique traffic subscriptions.
o 引导侦听器报告启动唯一流量订阅。
This can be achieved by a complete set of source- and group-specific filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. These filters MAY be derived in part from PMIPv6 routing policies and can include a default behavior (e.g., (*,*)).
这可以通过在代理接口上安装一整套源和组特定的筛选规则（例如，（S，*），（*，g））来实现。这些过滤器可能部分来自PMIPv6路由策略，并且可以包括默认行为（例如，（*，*））。
Packets from a locally attached multicast source will be forwarded to all downstream interfaces with appropriate subscriptions, as well as up the interface with the matching source-specific filter.
来自本地连接的多播源的数据包将被转发到具有适当订阅的所有下游接口，以及具有匹配的源特定筛选器的接口。
Typically, the upstream interface for a mobile multicast source is chosen based on the policy routing (e.g., the MAG-LMA tunnel interface for LMA-based routing or the interface towards the multicast router for direct routing), but alternate configurations MAY be applied. Packets from a locally attached multicast source will be forwarded to the corresponding upstream interface with the matching source-specific filter, as well as all the downstream interfaces with appropriate subscriptions.
通常，基于策略路由选择用于移动多播源的上游接口（例如，用于基于LMA的路由的MAG-LMA隧道接口或用于直接路由的朝向多播路由器的接口），但是可以应用替代配置。来自本地连接的多播源的数据包将被转发到具有匹配的源特定筛选器的相应上游接口，以及具有适当订阅的所有下游接口。
Multicast listener reports are group-wise aggregated by the MLD proxy. The aggregated report is issued to the upstream interface with a matching group/channel-specific filter. The choice of the corresponding upstream interface for aggregated group membership reports MAY be additionally based on some administrative scoping rules for scoped multicast group addresses.
多播侦听器报告由MLD代理按组聚合。聚合报告通过匹配的组/通道特定筛选器发布到上游接口。为聚合组成员资格报告选择相应的上游接口还可以基于作用域多播组地址的一些管理范围规则。
In detail, a Multiple Upstream Interface proxy will provide and maintain a Multicast Subscription Filter Table that maps source- and group-specific filters to upstream interfaces. The forwarding
具体而言，多上游接口代理将提供并维护一个多播订阅筛选器表，该表将源和组特定筛选器映射到上游接口。转发
decision for an aggregated MLD listener report is based on the first matching entry from this table, with the understanding that for IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the presence of (*,G) after (S,G) interface entries), and that (S,*)-filters are always false in the absence of source-specific signaling, i.e., in IGMPv2/MLDv1 only domains.
聚合MLD侦听器报告的决策基于此表中的第一个匹配条目，并了解对于IGMPv3/MLDv2，如果需要，MLD代理将执行状态分解（即（*，G）订阅拆分为（S，G）和（*\S，G），在（S，G）接口条目之后出现（*，G），并且（S，*）-在没有特定于源的信令的情况下，即仅在IGMPv2/MLDv1域中，过滤器总是错误的。
In typical deployment scenarios, specific group services (channels) are either
在典型的部署场景中，特定的组服务（通道）是
o associated with selected uplinks to remote LMAs, while a (*,*) default subscription entry (in the last table line) is bound to a local routing interface, or
o 与选定的远程LMA上行链路关联，同时（*，*）默认订阅条目（在最后一行中）绑定到本地路由接口，或
o configured as local services first, while a (*,*) default entry (in the last table line) points to a remote uplink that provides the general multicast support.
o 首先配置为本地服务，而（*，*）默认条目（在最后一行中）指向提供一般多播支持的远程上行链路。
An implementation of the extended IGMP/MLD proxy has been provided within the MCPROXY project (http://mcproxy.realmv6.org/). This open-source software is written in C++ and uses forwarding capabilities of the Linux kernel. It supports all regular operations according to [RFC4605] and allows for multiple proxy instances on one node, dynamically changing downstream links, proxy-to-proxy peerings, and multiple upstream links with individual configurations. The software can be downloaded from GitHub at <https://github.com/mcproxy/mcproxy>. Based on this software, an experimental performance evaluation of the proxy peering function has been reported in [PEERING-ANALYSIS].
MCPROXY项目中提供了扩展IGMP/MLD代理的实现(http://mcproxy.realmv6.org/). 这个开源软件是用C++编写的，并使用Linux内核的转发能力。它支持[RFC4605]规定的所有常规操作，并允许在一个节点上有多个代理实例，动态更改下游链路、代理到代理对等以及具有单独配置的多个上游链路。该软件可从GitHub下载，网址为<https://github.com/mcproxy/mcproxy>. 基于该软件，在[peering-ANALYSIS]中报告了代理对等功能的实验性能评估。
Authors' Addresses
作者地址
Thomas C. Schmidt (editor) HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
Thomas C.Schmidt（编辑）HAW Hamburg Berliner Tor 7 Hamburg 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
Shuai Gao Beijing Jiaotong University Beijing China
高帅北京交通大学中国北京
EMail: shgao@bjtu.edu.cn
EMail: shgao@bjtu.edu.cn
Hong-Ke Zhang Beijing Jiaotong University Beijing China
张宏科北京交通大学中国北京
EMail: hkzhang@bjtu.edu.cn
EMail: hkzhang@bjtu.edu.cn
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