Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7411 HAW Hamburg
Updates: 5568 M. Waehlisch
Category: Experimental link-lab & FU Berlin
ISSN: 2070-1721 R. Koodli
Intel
G. Fairhurst
University of Aberdeen
D. Liu
China Mobile
November 2014
Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Request for Comments: 7411 HAW Hamburg
Updates: 5568 M. Waehlisch
Category: Experimental link-lab & FU Berlin
ISSN: 2070-1721 R. Koodli
Intel
G. Fairhurst
University of Aberdeen
D. Liu
China Mobile
November 2014
Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
用于移动IPv6（MIPv6）和代理移动IPv6（PMIPv6）快速切换的多播侦听器扩展
Abstract
摘要
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.
用于移动IPv6（MIPv6）和代理移动IPv6（PMIPv6）的快速切换协议定义了支持单播通信且切换延迟降低的移动性管理过程。快速切换基本操作不会影响多播通信，因此不会加速本机多播侦听器的切换管理。但是，许多多播应用程序（如IPTV或会议）包含对延迟敏感的实时流量，并将受益于快速切换完成。本文档规定了移动IPv6快速切换（FMIPv6）和代理移动IPv6快速切换（PFMIPv6）协议的扩展，以在快速切换操作中包括多播流量管理。该多播支持首先在控制平面上通过管理接入路由器之间的快速上下文传输来提供，第二在数据平面上通过可选的快速业务转发（可能包括缓冲）来提供。FMIPv6访问路由器表示支持使用更新的代理路由器消息格式的多播。
This document updates RFC 5568, "Mobile IPv6 Fast Handovers".
本文档更新了RFC 5568，“移动IPv6快速切换”。
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/rfc7411.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7411.
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
1.1. Use Cases and Deployment Scenarios .........................5
2. Terminology .....................................................6
3. Protocol Overview ...............................................6
3.1. Multicast Context Transfer between Access Routers ..........7
3.2. Protocol Operations Specific to FMIPv6 .....................9
3.3. Protocol Operations Specific to PFMIPv6 ...................12
4. Protocol Details ...............................................15
4.1. Protocol Operations Specific to FMIPv6 ....................15
4.1.1. Operations of the Mobile Node ......................15
4.1.2. Operations of the Previous Access Router ...........15
4.1.3. Operations of the New Access Router ................16
4.1.4. Buffering Considerations ...........................17
4.2. Protocol Operations Specific to PFMIPv6 ...................17
4.2.1. Operations of the Mobile Node ......................17
4.2.2. Operations of the Previous MAG .....................17
4.2.3. Operations of the New MAG ..........................19
4.2.4. IPv4 Support Considerations ........................20
5. Message Formats ................................................20
5.1. Multicast Indicator for Proxy Router Advertisement
(PrRtAdv) .................................................20
5.2. Extensions to Existing Mobility Header Messages ...........21
5.3. New Multicast Mobility Option .............................21
5.4. New Multicast Acknowledgement Option ......................24
5.5. Length Considerations: Number of Records and Addresses ....25
5.6. MLD and IGMP Compatibility Requirements ...................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Appendix A. Considerations for Mobile Multicast Sources ..........29
Acknowledgments ...................................................29
Authors' Addresses ................................................30
1. Introduction ....................................................4
1.1. Use Cases and Deployment Scenarios .........................5
2. Terminology .....................................................6
3. Protocol Overview ...............................................6
3.1. Multicast Context Transfer between Access Routers ..........7
3.2. Protocol Operations Specific to FMIPv6 .....................9
3.3. Protocol Operations Specific to PFMIPv6 ...................12
4. Protocol Details ...............................................15
4.1. Protocol Operations Specific to FMIPv6 ....................15
4.1.1. Operations of the Mobile Node ......................15
4.1.2. Operations of the Previous Access Router ...........15
4.1.3. Operations of the New Access Router ................16
4.1.4. Buffering Considerations ...........................17
4.2. Protocol Operations Specific to PFMIPv6 ...................17
4.2.1. Operations of the Mobile Node ......................17
4.2.2. Operations of the Previous MAG .....................17
4.2.3. Operations of the New MAG ..........................19
4.2.4. IPv4 Support Considerations ........................20
5. Message Formats ................................................20
5.1. Multicast Indicator for Proxy Router Advertisement
(PrRtAdv) .................................................20
5.2. Extensions to Existing Mobility Header Messages ...........21
5.3. New Multicast Mobility Option .............................21
5.4. New Multicast Acknowledgement Option ......................24
5.5. Length Considerations: Number of Records and Addresses ....25
5.6. MLD and IGMP Compatibility Requirements ...................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Appendix A. Considerations for Mobile Multicast Sources ..........29
Acknowledgments ...................................................29
Authors' Addresses ................................................30
Mobile IPv6 [RFC6275] defines a network-layer mobility protocol involving participation by Mobile Nodes, while Proxy Mobile IPv6 [RFC5213] provides a mechanism without requiring mobility protocol operations at a Mobile Node (MN). Both protocols introduce traffic disruptions on handovers that may be intolerable in many real-time application scenarios such as gaming or conferencing. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of handovers for unicast communication. Delays are reduced to the order of the maximum of the link switching delay and the signaling delay between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis].
移动IPv6[RFC6275]定义了一个涉及移动节点参与的网络层移动协议，而代理移动IPv6[RFC5213]提供了一种不需要移动节点（MN）上的移动协议操作的机制。这两种协议都会在切换时引入流量中断，这在许多实时应用场景（如游戏或会议）中可能是无法忍受的。移动IPv6快速切换（FMIPv6）[RFC5568]和代理移动IPv6快速切换（PFMIPv6）[RFC5949]提高了单播通信切换的性能。延迟被减少到接入路由器（AR）或移动接入网关（MAG）之间的链路切换延迟和信令延迟的最大值[FMIPv6分析]。
No dedicated treatment of seamless IP multicast [RFC1112] data service has been proposed by any of the above protocols. MIPv6 only roughly defines multicast for Mobile Nodes using a remote subscription approach or a home subscription through bidirectional tunneling via the Home Agent (HA). Multicast forwarding services have not been specified in [RFC5213] but are subject to separate specifications: [RFC6224] and [RFC7287]. It is assumed throughout this document that mechanisms and protocol operations are in place to transport multicast traffic to ARs. These operations are referred to as 'JOIN/LEAVE' of an AR, while the explicit techniques to manage multicast transmission are beyond the scope of this document.
上述任何协议均未提议对无缝IP多播[RFC1112]数据服务进行专门处理。MIPv6仅粗略定义了使用远程订阅方法或通过本地代理（HA）通过双向隧道的本地订阅的移动节点的多播。[RFC5213]中未指定多播转发服务，但需要遵守单独的规范：[RFC6224]和[RFC7287]。在本文档中，假设有机制和协议操作将多播通信传输到ARs。这些操作被称为AR的“加入/离开”，而管理多播传输的显式技术超出了本文的范围。
Mobile multicast protocols need to support applications such as IPTV with high-volume content streams and allow distribution to potentially large numbers of receivers. They should thus preserve the multicast nature of packet distribution and approximate optimal routing [RFC5757]. It is undesirable to rely on home tunneling for optimizing multicast. Unencapsulated, native multicast transmission requires establishing forwarding state, which will not be transferred between access routers by the unicast fast handover protocols. Thus, multicast traffic will not experience expedited handover performance, but an MN -- or its corresponding MAG in PMIPv6 -- can perform remote subscriptions in each visited network.
移动多播协议需要支持具有大容量内容流的IPTV等应用程序，并允许分发到潜在的大量接收器。因此，它们应该保留数据包分布的多播性质和近似最优路由[RFC5757]。依靠家庭隧道来优化多播是不可取的。未封装的本机多播传输需要建立转发状态，单播快速切换协议不会在接入路由器之间传输转发状态。因此，多播通信不会经历快速切换性能，但MN（或PMIPv6中相应的MAG）可以在每个访问的网络中执行远程订阅。
This document specifies extensions to FMIPv6 and PFMIPv6 that include multicast traffic management for fast handover operations in the presence of any-source or source-specific multicast. The protocol extensions were designed under the requirements that
本文档指定了对FMIPv6和PFMIPv6的扩展，其中包括在存在任何源或源特定多播的情况下用于快速切换操作的多播流量管理。协议扩展是根据以下要求设计的：
o multicast context transfer shall be transparently included in unicast fast handover operations;
o 单播快速切换操作中应透明地包括组播上下文传输；
o neither unicast mobility protocols nor multicast routing shall be modified or otherwise affected; and
o 不得修改或以其他方式影响单播移动协议或多播路由；和
o no active participation of MNs in PMIPv6 domains is defined.
o 未定义MNs在PMIPv6域中的积极参与。
The solution common to both underlying unicast protocols defines the per-group or per-channel transfer of multicast contexts between ARs or MAGs. The protocol defines corresponding message extensions necessary for carrying (*,G) or (S,G) context information independent of the particular handover protocol. ARs or MAGs are then enabled to treat multicast traffic according to fast unicast handovers and with similar performance. No protocol changes are introduced that prevent a multicast-unaware node from performing fast handovers with multicast-aware ARs or MAGs.
两种基础单播协议通用的解决方案定义了ARs或MAG之间的每组或每通道多播上下文传输。该协议定义了独立于特定切换协议而承载（*，G）或（S，G）上下文信息所需的相应消息扩展。然后，ARs或MAG能够根据快速单播切换和类似性能处理多播流量。没有引入任何协议更改来防止不知道多播的节点使用知道多播的AR或MAG执行快速切换。
The specified mechanisms apply when a Mobile Node has joined and maintains one or several multicast group subscriptions prior to undergoing a fast handover. It does not introduce any requirements on the multicast routing protocols in use, nor are the ARs or MAGs assumed to be multicast routers. It assumes network conditions, though, that allow native multicast reception in both the previous and new access network. Methods to bridge regions without native multicast connectivity are beyond the scope of this document.
当移动节点在经历快速切换之前加入并维护一个或多个多播组订阅时，指定的机制适用。它没有对正在使用的多播路由协议提出任何要求，也没有假定ARs或MAG是多播路由器。不过，它假定网络条件允许在以前的和新的接入网络中接收本机多播。没有本地多播连接的桥接区域的方法超出了本文档的范围。
Section 5.1 of this memo updates the Proxy Router Advertisements (PrRtAdv) message format defined in Section 6.1.2 of [RFC5568] to allow an FMIPv6 AR to indicate support for multicast.
本备忘录第5.1节更新了[RFC5568]第6.1.2节中定义的代理路由器广告（PrRtAdv）消息格式，以允许FMIPv6 AR指示对多播的支持。
Multicast extensions for fast handovers enable multicast services in domains that operate either of the unicast fast handover protocols: [RFC5568] or [RFC5949]. Typically, fast handover protocols are activated within an operator network or within a dedicated service installation.
用于快速切换的多播扩展在运行单播快速切换协议：[RFC5568]或[RFC5949]的域中启用多播服务。通常，在运营商网络或专用服务安装中激活快速切换协议。
Multicast group communication has a variety of dominant use cases. One traditional application area is infotainment with voluminous multimedia streams delivered to a large number of receivers (e.g., IPTV). Other time-critical services, such as news items or stock-exchange prices, are commonly transmitted via multicast to support fair and fast updates. Both of these use cases may be mobile, and both largely benefit from fast handover operations. Mobile operators may therefore enhance their operational quality or offer premium services by enabling fast handovers.
多播组通信有多种主要用例。一个传统的应用领域是信息娱乐，大量多媒体流传送到大量接收器（如IPTV）。其他时间关键型服务，如新闻项目或证券交易所价格，通常通过多播传输，以支持公平和快速的更新。这两个用例都可能是移动的，并且都从快速切换操作中获益匪浅。因此，移动运营商可以通过实现快速切换来提高运营质量或提供优质服务。
Another traditional application area for multicast is conversational group communication in scenarios like conferencing or gaming as well as in dedicated collaborative environments or teams. Machine-to-machine communication in the emerging Internet of Things is expected to generate various additional mobile use cases (e.g., among cars). High demands on transmission quality and rapidly moving parties may require fast handovers.
多播的另一个传统应用领域是在会议或游戏等场景以及专用协作环境或团队中的会话组通信。新兴物联网中的机器对机器通信预计将产生各种额外的移动用例（例如，在汽车之间）。对传输质量的高要求和快速移动的各方可能需要快速切换。
Most of the deployment scenarios above are bound to a fixed infrastructure with consumer equipment at the edge. Today, they are thus likely to follow an operator-centric approach like PFMIPv6. However, Internet technologies evolve for adoption in infrastructureless scenarios, for example, disaster recovery, rescue, crisis prevention, and civil safety. Mobile end-to-end communication in groups is needed in Public Protection and Disaster Relief (PPDR) scenarios, where mobile multicast communication needs to be supported between members of rescue teams, police officers, fire brigade teams, paramedic teams, and command control offices in order to support the protection and health of citizens. These use cases require fast and reliable mobile services that cannot rely on operator infrastructure. They are thus expected to benefit from running multicast with FMIPv6.
上述大多数部署场景都绑定到一个固定的基础架构上，客户设备位于边缘。如今，他们可能会采用以运营商为中心的方法，如PFMIPv6。然而，互联网技术在无基础设施的场景中不断发展，例如灾难恢复、救援、危机预防和公民安全。在公共保护和救灾（PPDR）场景中，需要分组移动端到端通信，其中需要支持救援队、警官、消防队、辅助医疗队和指挥控制办公室成员之间的移动多播通信，以支持公民的保护和健康。这些用例需要快速可靠的移动服务，不能依赖于运营商基础设施。因此，他们有望从使用FMIPv6运行多播中获益。
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]中所述进行解释。
This document uses the terminology for mobility entities in [RFC5568], [RFC5949], [RFC6275], and [RFC5213].
本文件使用[RFC5568]、[RFC5949]、[RFC6275]和[RFC5213]中移动实体的术语。
A multicast group is any group (*,G) or (S,G) multicast channel listed in a Multicast Listener Report Message.
多播组是多播侦听器报告消息中列出的任何组（*，G）或（S，G）多播通道。
This section provides an informative overview of the protocol mechanisms without normative specifications.
本节提供了无规范规范的协议机制的信息性概述。
The reference scenario for multicast fast handover is illustrated in Figure 1. A Mobile Node is initially attached to the previous access network (P-AN) via the Previous Access Router (PAR) or Previous Mobile Access Gateway (PMAG) and moves to the new access network (N-AN) connected via a New AR (NAR) or New MAG (NMAG).
多播快速切换的参考场景如图1所示。移动节点最初经由先前接入路由器（PAR）或先前移动接入网关（PMAG）连接到先前接入网络（P-AN），并移动到经由新AR（NAR）或新MAG（NMAG）连接的新接入网络（N-AN）。
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
图1：用于快速切换的参考网络
In a fast handover scenario (see Figure 1), ARs/MAGs establish a mutual binding and provide the capability to exchange context information concerning the MN. This context transfer will be triggered by detecting the forthcoming movement of an MN to a new AR and assists the MN to immediately resume communication on the new subnet using its previous IP address. In contrast to unicast, multicast flow reception does not primarily depend on address and binding cache management but requires distribution trees to adapt so that traffic follows the movement of the MN. This process may be significantly slower than fast handover management [RFC5757]. To accelerate the handover, a multicast listener may offer a twofold advantage of including the multicast groups under subscription in the context transfer. First, the NAR can proactively join the subscribed groups as soon as it gains knowledge of them. Second, multicast flows can be included in traffic forwarding via the tunnel that is established from the PAR to the NAR by the unicast fast handover protocol.
在快速切换场景中（见图1），ARs/MAG建立相互绑定，并提供交换有关MN的上下文信息的能力。此上下文传输将通过检测MN即将移动到新AR来触发，并帮助MN使用其以前的IP地址立即恢复新子网上的通信。与单播相比，多播流接收主要不依赖于地址和绑定缓存管理，而是需要分布树进行调整，以便流量跟随MN的移动。此过程可能比快速切换管理[RFC5757]慢得多。为了加速切换，多播侦听器可以提供在上下文传输中包括订阅下的多播组的双重优势。首先，NAR可以在了解订阅组后立即主动加入这些组。第二，多播流可以通过通过单播快速切换协议从PAR建立到NAR的隧道中包含在流量转发中。
There are two modes of operation in FMIPv6 and in PFMIPv6. The predictive mode allows for AR-binding and context transfer prior to an MN handover, while in the reactive mode, these steps are executed after detection that the MN has reattached to a NAR (NMAG). Details of the signaling schemes differ between FMIPv6 and PFMIPv6 and are outlined in Sections 3.2 and 3.3.
FMIPv6和PFMIPv6中有两种操作模式。预测模式允许在MN切换之前进行AR绑定和上下文传输，而在反应模式中，这些步骤是在检测到MN已重新连接到NAR（NMAG）之后执行的。FMIPv6和PFMIPv6之间的信令方案细节有所不同，第3.2节和第3.3节对其进行了概述。
In a predictive fast handover, the access router (i.e., PAR (PMAG) in Figure 1) learns about the impending movement of the MN and simultaneously about the multicast group context as specified in Sections 3.2 and 3.3. Thereafter, the PAR will initiate an AR-binding and context transfer by transmitting a Handover Initiation (HI) message to the NAR (NMAG). The HI message is extended by multicast group states carried in mobility header options, as defined in Section 5.3. On reception of the HI message, the NAR returns a multicast acknowledgement in its Handover Acknowledgement (HAck) answer that indicates its ability to support each requested group (see Section 5.4). The NAR (NMAG) expresses its willingness to receive multicast traffic forwarded by the PAR using standard Multicast Listener Discovery (MLD) signaling for IPv6 or the Internet Group Management Protocol (IGMP) for an IPv4 compatibility case.
在预测快速切换中，接入路由器（即图1中的PAR（PMAG））了解MN的即将发生的移动，并同时了解在第3.2和3.3节中指定的多播组上下文。此后，PAR将通过向NAR（NMAG）发送切换发起（HI）消息来发起AR绑定和上下文转移。根据第5.3节中的定义，HI消息通过移动报头选项中携带的多播组状态进行扩展。在接收到HI消息时，NAR在其切换确认（HAck）应答中返回一个多播确认，表明其支持每个请求组的能力（参见第5.4节）。NAR（NMAG）表示愿意接受PAR转发的组播业务，使用IPv6的标准多播侦听器发现（MLD）信令或IPv4兼容性情况下的因特网组管理协议（IGMP）。
Nodes normally create forwarding state for each group requested. There are several reasons why a node may decide not to forward a specific group, e.g., the NAR could already have a native subscription for the group(s) or capacity constraints can hinder decapsulation of additional streams. At the previous network, there may be policy or capacity constraints that make it undesirable to forward the multicast traffic. The PAR can add the tunnel interface obtained from the underlying unicast protocol to its multicast forwarding database for those groups the MN wishes to receive, so that multicast flows can be forwarded in parallel to the unicast traffic.
节点通常为请求的每个组创建转发状态。节点可能决定不转发特定组的原因有很多，例如，NAR可能已经有了组的本机订阅，或者容量限制可能会阻碍其他流的解除封装。在先前的网络上，可能存在策略或容量限制，这使得转发多播通信量是不可取的。PAR可以将从底层单播协议获得的隧道接口添加到其MN希望接收的组的多播转发数据库，从而可以将组播流并行转发到单播业务。
The NAR implements an MLD proxy [RFC4605] providing host-side behavior towards the upstream PAR. The proxy will submit an MLD report to the upstream tunnel interface to signal the set of groups to be forwarded. It will terminate multicast forwarding from the tunnel when the group is natively received. In parallel, the NAR joins all groups that are not already under subscription using its native multicast upstream interface. While the MN has not arrived at a downstream interface of the NAR, multicast subscriptions on behalf of the MN are associated with a downstream loopback interface. Reception of the Join at the NAR enables downstream native multicast forwarding of the subscribed group(s).
NAR实现了向上游PAR提供主机侧行为的MLD代理[RCF4605]。代理将向上游隧道接口提交MLD报告，以通知要转发的组集。当本机接收到组时，它将终止来自隧道的多播转发。同时，NAR使用其本机多播上游接口加入尚未订阅的所有组。当MN尚未到达NAR的下游接口时，代表MN的多播订阅与下游环回接口相关联。在NAR处接收加入可启用订阅组的下游本机多播转发。
In a reactive fast handover, the PAR will learn about the movement of the MN after the latter has re-associated with the new access network. Also, from the new link, it will be informed about the multicast context of the MN. As group membership information is present at the new access network prior to context transfer, MLD join signaling can proceed in parallel to HI/HAck exchange. Following the context transfer, multicast data can be forwarded to the new access network using the PAR-NAR tunnel of the fast handover protocol. Depending on the specific network topology, multicast traffic for some groups may natively arrive before it is forwarded from the PAR.
在反应快速切换中，PAR将了解MN在后者与新接入网络重新关联后的移动。此外，从新链路，它将被告知MN的多播上下文。由于在上下文传输之前新接入网络中存在组成员信息，因此MLD加入信令可以与HI/HAck交换并行进行。在上下文传输之后，可以使用快速切换协议的PAR-NAR隧道将多播数据转发到新的接入网络。根据特定的网络拓扑，一些组的组播业务可以在从PAR转发之前本地到达。
In both modes of operation, it is the responsibility of the PAR (PMAG) to properly apply multicast state management when an MN leaves (i.e., to determine whether it can prune the traffic for any unsubscribed group). Depending on the link type and MLD parameter settings, methods for observing the departure of an MN need to be applied (see [RFC5757]). While considering subscriptions of the remaining nodes and from the tunnel interfaces, the PAR uses normal multicast forwarding rules to determine whether multicast traffic can be pruned.
在这两种操作模式中，当MN离开时，PAR（PMAG）的责任是适当地应用多播状态管理（即，以确定它是否可以修剪任何未订阅组的流量）。根据链路类型和MLD参数设置，需要应用观察MN偏离的方法（参见[RFC5757]）。在考虑剩余节点和隧道接口的订阅时，PAR使用正常多播转发规则来确定是否可以修剪多播业务。
This method allows an MN to participate in multicast group communication with a handover performance that is comparable to unicast handover. It is worth noting that tunnel management between access routers in all modes is inherited from the corresponding unicast fast handover protocols. Tunnels thus remain active until unicast handover operations have been completed for the MN.
该方法允许MN以与单播切换相当的切换性能参与多播组通信。值得注意的是，所有模式下接入路由器之间的隧道管理都继承自相应的单播快速切换协议。因此，隧道保持活动状态，直到MN的单播切换操作完成。
ARs that provide multicast support in FMIPv6 will advertise this general service by setting an indicator bit ('M' bit) in its PrRtAdv message, as defined in Section 5.1. Additional details about the multicast service support, e.g., flavors and groups, will be exchanged within HI/HAck dialogs later at handover.
在FMIPv6中提供多播支持的AR将通过在其PrRtAdv消息中设置一个指示符位（“M”位）来公布该一般服务，如第5.1节所定义。有关多播服务支持的其他详细信息，例如口味和组，将在稍后的HI/HAck对话框中交换。
An MN operating FMIPv6 will actively initiate the handover management by submitting a Fast Binding Update (FBU). The MN, which is aware of the multicast groups it wishes to maintain, will attach mobility options containing its group states (see Section 5.3) to the FBU and thereby inform ARs about its multicast context. ARs will use these multicast context options for inter-AR context transfer.
运行FMIPv6的MN将通过提交快速绑定更新（FBU）主动启动切换管理。MN知道其希望维护的多播组，将把包含其组状态的移动选项（见第5.3节）附加到FBU，从而将其多播上下文通知ARs。AR将使用这些多播上下文选项进行AR间上下文传输。
In predictive mode, the FBU is issued on the previous link and received by the PAR as displayed in Figure 2. The PAR will extract the multicast context options and append them to its HI message. From the HAck message, the PAR will redistribute the multicast acknowledgement by adding the corresponding mobility options to its
在预测模式下，FBU在前一个链路上发出，并由PAR接收，如图2所示。PAR将提取多播上下文选项并将其附加到其HI消息中。从HACK消息中，PAR将通过向其添加相应的移动性选项来重新分配多播确认。
Fast Binding ACK (FBack) message. From receiving the FBack message, the MN will learn about the multicast support for each group in the new access network. If some groups or multicast service models are not supported, it can decide to take actions to overcome a missing service (e.g., by tunneling). Note that the proactive multicast context transfer may proceed successfully, even if the MN misses the FBack message on the previous link.
快速绑定确认（FBack）消息。通过接收FBack消息，MN将了解新接入网络中每个组的多播支持。如果不支持某些组或多播服务模型，它可以决定采取措施来克服丢失的服务（例如，通过隧道）。注意，主动多播上下文传输可能会成功进行，即使MN错过了前一链路上的FBack消息。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HAck---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBack---|--FBack------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HAck---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBack---|--FBack------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Multicast Handover for FMIPv6
图2:FMIPv6的预测性多播切换
The flow diagram for reactive mode is depicted in Figure 3. After attaching to the new access link and performing an Unsolicited Neighbor Advertisement (UNA), the MN issues an FBU that the NAR forwards to the PAR without processing. At this time, the MN is able to rejoin all subscribed multicast groups without relying on AR assistance. Nevertheless, multicast context options are exchanged in the HI/HAck dialog to facilitate intermediate forwarding of the requested multicast flows. The multicast traffic could arrive from an MN subscription at the same time that the NAR receives the HI message. Such multicast flows may be transparently excluded from
反应模式的流程图如图3所示。在附加到新的接入链路并执行未请求的邻居广告（NUA）之后，MN发出NAR转发到PAR而不进行处理的FBU。此时，MN能够在不依赖AR协助的情况下重新加入所有订阅的多播组。然而，多播上下文选项在HI/HAck对话框中交换，以促进请求的多播流的中间转发。多播流量可以在NAR接收HI消息的同时从MN订阅到达。这样的多播流可以透明地从中排除
forwarding by setting an appropriate Multicast Acknowledgement Option. In either case, to avoid duplication, the NAR MUST ensure that not more than one flow of the same group is forwarded to the MN.
通过设置适当的多播确认选项进行转发。在任何一种情况下，为了避免重复，NAR必须确保不超过一个相同组的流被转发到MN。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HAck----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HAck if necessary)|
| | |
| FBack, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HAck----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HAck if necessary)|
| | |
| FBack, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Multicast Handover for FMIPv6
图3:FMIPv6的反应式多播切换
In a proxy mobile IPv6 environment, the MN remains agnostic of network layer changes, and fast handover procedures are operated by the access routers or MAGs to which MNs are connected via node-specific point-to-point links. The handover initiation, or the re-association, is managed by the access networks. Consequently, access routers need to be aware of multicast membership state at the Mobile Node. There are two ways to obtain the multicast membership of an MN.
在代理移动IPv6环境中，MN仍然不知道网络层的变化，并且快速切换过程由MN通过特定于节点的点到点链路连接到的接入路由器或mag操作。切换发起或重新关联由接入网络管理。因此，接入路由器需要知道移动节点处的多播成员状态。有两种方法可以获得MN的多播成员资格。
o MAGs may perform explicit tracking (see [RFC4605] and [RFC6224]) or extract membership status from forwarding states at node-specific links.
o MAG可以执行显式跟踪（参见[RFC4605]和[RFC6224]），或者从节点特定链路的转发状态提取成员身份状态。
o routers can issue a general MLD query at handovers. Both methods are equally applicable. However, a router that does not provide explicit membership tracking needs to query its downstream links after a handover. The MLD membership information then allows the PMAG to learn the multicast group subscriptions of the MN.
o 路由器可以在切换时发出通用MLD查询。这两种方法同样适用。然而，不提供明确成员身份跟踪的路由器需要在切换后查询其下游链路。然后，MLD成员信息允许PMAG学习MN的多播组订阅。
In predictive mode, the PMAG will learn about the upcoming movement of the Mobile Node, including its new Access Point Identifier (New AP ID). Without explicit tracking, it will immediately submit a general MLD query and receive MLD reports indicating the multicast address listening state of the subscribed group(s). As displayed in Figure 4, it will initiate binding and context transfer with the NMAG by issuing a HI message that is augmented by multicast contexts in the mobility options defined in Section 5.3. NMAG will extract multicast context information and act as described in Section 3.1.
在预测模式下，PMAG将了解移动节点即将进行的移动，包括其新接入点标识符（新AP ID）。在没有显式跟踪的情况下，它将立即提交通用MLD查询并接收MLD报告，该报告指示订阅组的多播地址侦听状态。如图4所示，它将通过发出HI消息来启动与NMAG的绑定和上下文传输，该消息由第5.3节中定义的移动选项中的多播上下文扩展。NMAG将提取多播上下文信息，并按照第3.1节所述进行操作。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<----establishment----->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<========================================== deliver packets
| | | | |
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<----establishment----->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<========================================== deliver packets
| | | | |
Figure 4: Predictive Multicast Handover for PFMIPv6
图4:PFMIPv6的预测性多播切换
In reactive mode, the NMAG will learn the attachment of the MN to the N-AN and establish connectivity using the PMIPv6 protocol operations. However, it will have no knowledge about multicast state at the MN. Triggered by an MN attachment, the NMAG will send a general MLD query and thereafter join the groups for which it receives multicast listener report messages. In the case of a reactive handover, the binding is initiated by the NMAG, and the HI/HAck message semantic is inverted (see [RFC5949]). For multicast context transfer, the NMAG attaches to its HI message those group identifiers it requests to be
在反应模式下，NMAG将学习MN与N-AN的连接，并使用PMIPv6协议操作建立连接。然而，它不知道MN上的多播状态。由MN附件触发，NMAG将发送一个通用MLD查询，然后加入它接收多播侦听器报告消息的组。在反应式切换的情况下，绑定由NMAG启动，HI/HAck消息语义颠倒（请参见[RFC5949]）。对于多播上下文传输，NMAG将其请求的组标识符附加到HI消息
forwarded from PMAG. Using the identical syntax in its Multicast Mobility Option headers, as defined in Section 5.4, the PMAG acknowledges the set of requested groups in a HAck answer, indicating the group(s) it is willing to forward. The corresponding call flow is displayed in Figure 5.
由PMAG转发。如第5.4节所定义，PMAG在其多播移动选项报头中使用相同的语法，在黑客应答中确认请求的组集，表示其愿意转发的组。相应的调用流如图5所示。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HAck----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HAck----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
Figure 5: Reactive Multicast Handover for PFMIPv6
图5:PFMIPv6的反应式多播切换
This section provides a normative definition of the protocol operations.
本节提供协议操作的规范性定义。
A Mobile Node willing to manage multicast traffic by fast handover operations MUST transfer its MLD listener state records within fast handover negotiations.
愿意通过快速切换操作管理多播通信的移动节点必须在快速切换协商中传输其MLD侦听器状态记录。
When sensing a handover in predictive mode, an MN MUST build a Multicast Mobility Option, as described in Section 5.3, that contains the MLD or IGMP multicast listener state and append it to the Fast Binding Update (FBU) prior to signaling with PAR.
当检测到预测模式中的切换时，MN必须建立多播移动性选项，如第5.3节所述，包含MLD或IGMP多播侦听器状态，并在与PAR进行信令之前将其附加到快速绑定更新（FBU）。
The MN will receive the Multicast Acknowledgement Option(s) as a part of the Fast Binding Acknowledge (FBack) (see Section 5.4) and learn about unsupported or prohibited groups at the NAR. The MN MAY take appropriate actions such as home tunneling to enable reception of groups that are not available via the NAR. Beyond standard FMIPv6 signaling, no multicast-specific operation is required by the MN when reattaching in the new network.
MN将接收多播确认选项作为快速绑定确认（FBack）的一部分（见第5.4节），并了解NAR上不受支持或禁止的组。MN可以采取适当的行动，例如家庭隧道，以便能够接收通过NAR不可用的组。除了标准的FMIPv6信令，MN在重新连接到新网络时不需要特定于多播的操作。
In reactive mode, the MN MUST append the identical Multicast Mobility Option to the FBU sent after its reconnect. In response, it will learn about the Multicast Acknowledgement Option(s) from the FBack and expect corresponding multicast data. Concurrently, it joins all subscribed multicast groups directly on its newly established access link.
在反应模式下，MN必须将相同的多播移动性选项附加到其重新连接后发送的FBU。作为响应，它将从FBack了解多播确认选项，并期望得到相应的多播数据。同时，它在新建立的访问链路上直接加入所有订阅的多播组。
A PAR that supports multicast advertises that support by setting the 'M' bit in the Proxy Router Advertisement (PrRtAdv) message, as specified in Section 5.1 of this document. This indicator exclusively informs the MNs about the capability of the PAR to process and exchange Multicast Mobility Options during fast handover operations.
支持多播的PAR广告通过在代理路由器广告（PRRTADV）消息中设置“M”位来支持，如本文档第5.1节所述。该指示符仅通知MNS关于PAR在快速切换操作期间处理和交换多播移动性选项的能力。
In predictive mode, a PAR will receive the multicast listener state of an MN prior to handover from the Multicast Mobility Option appended to the FBU. It forwards these records to the NAR within HI messages and will expect Multicast Acknowledgement Option(s) in a HAck, which is itself returned to the MN as an appendix to the FBack. In performing the multicast context exchange, the PAR is instructed
在预测模式中，PAR将接收到从附加到FBU的多播移动性选项切换之前的MN的多播收听者状态。它在HI消息内将这些记录转发给NAR，并期望在HAck中使用多播确认选项，该选项本身作为FBack的附录返回给MN。在执行多播上下文交换时，指示PAR。
to include the PAR-to-NAR tunnel obtained from unicast handover management in its multicast downstream interfaces and awaits reception of multicast listener report messages from the NAR. In response to receiving multicast subscriptions, the PAR SHOULD forward group data acting as a regular multicast router or proxy. However, the PAR MAY refuse to forward some or all of the multicast flows (e.g., due to administrative configurations or load conditions).
将从单播切换管理获得的PAR到NAR隧道包括在其多播下游接口中，并等待从NAR接收多播侦听器报告消息。响应于接收多播订阅，PAR应转发作为常规多播路由器或代理的分组数据。然而，PAR可能拒绝转发某些或所有的多播流（例如，由于管理配置或负载条件）。
In reactive mode, the PAR will receive the FBU augmented by the Multicast Mobility Option from the new network but continues with an identical multicast record exchange in the HI/HAck dialog. As in the predictive case, it configures the PAR-to-NAR tunnel for the multicast downstream. It then (if capable) forwards data according to the group membership indicated in the multicast listener report messages received from NAR.
在反应模式中，PAR将接收来自新网络的多播移动性选项增强的FBU，但是在Hi/HACK对话框中继续相同的多播记录交换。与预测情况一样，它为多播下游配置PAR到NAR隧道。然后，它（如果能够）根据从NAR接收的多播侦听器报告消息中指示的组成员身份转发数据。
In both modes, the PAR MUST interpret the first of the two events -- the departure of the MN or the reception of the Multicast Acknowledgement Option(s) -- as if the MN had sent a multicast LEAVE message and react according to the signaling scheme deployed in the access network (i.e., MLD querying, explicit tracking).
在这两种模式中，PAR必须解释这两个事件中的第一个事件：MN的离开或多播确认选项的接收（S）——就好像MN已经发送了多播离开消息并根据部署在接入网络中的信令方案（即MLD查询、显式跟踪）作出反应。
A NAR that supports multicast advertises that support by setting the 'M' bit in PrRtAdv as specified in Section 5.1 of this document. This indicator exclusively serves the purpose of informing MNs about the capability of the NAR to process and exchange Multicast Mobility Options during fast handover operations.
支持多播的NAR通过按照本文件第5.1节的规定在PrRtAdv中设置“M”位来宣传该支持。该指示器专门用于通知MNs NAR在快速切换操作期间处理和交换多播移动选项的能力。
In predictive mode, a NAR will receive the multicast listener state of an expected MN from the Multicast Mobility Option appended to the HI message. It will extract the multicast group membership records from the message and match the request subscription with its multicast service offer. Further on, it will join the requested groups using a downstream loopback interface. This will lead to suitable regular subscriptions to a native multicast upstream interface without additional forwarding. Concurrently, the NAR builds a Multicast Acknowledgement Option(s) (see Section 5.4) listing the set of groups that are unsupported on the new access link and returns this list within a HAck. As soon as there is an operational bidirectional tunnel from the PAR to NAR, the NAR joins the groups requested by the MN, which are then forwarded by the PAR using the tunnel link.
在预测模式下，NAR将从附加到HI消息的多播移动性选项接收预期MN的多播侦听器状态。它将从消息中提取多播组成员记录，并将请求订阅与其多播服务提供相匹配。此外，它将使用下游环回接口加入请求的组。这将导致对本机多播上游接口进行适当的定期订阅，而无需额外转发。同时，NAR构建一个多播确认选项（见第5.4节），列出新访问链路上不支持的组集，并在HAck中返回该列表。一旦存在从PAR到NAR的操作双向隧道，NAR加入由MN请求的组，然后使用隧道链路将PAR转发给该组。
In reactive mode, the NAR will learn about the multicast listener state of a new MN from the Multicast Mobility Option appended to each HI message after the MN has already performed local subscriptions of
在反应模式下，NAR将在MN已经执行了新MN的本地订阅之后，从附加到每个HI消息的多播移动性选项中了解新MN的多播侦听器状态
the multicast service. Thus, the NAR solely determines the intersection of requested and supported groups and issues a join request for each group forwarding this on the PAR-NAR tunnel interface.
多播服务。因此，NAR仅确定请求组和受支持组的交叉点，并在PAR-NAR隧道接口上为转发此信息的每个组发出加入请求。
In both modes, the NAR MUST send a LEAVE message to the tunnel when it is no longer needed to forward a group, e.g., after arrival of native multicast traffic or termination of a group membership from the MN. Although the message can be delayed, immediately sending the LEAVE message eliminates the need for the PAR and NAR to process traffic that is not to be forwarded.
在这两种模式中，当不再需要转发组时，NAR必须向隧道发送离开消息，例如，在本机多播通信量到达或来自MN的组成员资格终止之后。虽然消息可以被延迟，但是立即发送休假消息消除了PAR和NAR处理不转发的业务的需要。
Multicast packets may be lost during handover. For example, in predictive mode, as illustrated by Figure 2, packets may be lost while the MN is -- already or still -- detached from the networks, even though they are forwarded to the NAR. In reactive mode as illustrated by Figure 3, the situation may be worse, since there will be a delay before joining the multicast group after the MN reattaches to the NAR. Multicast packets cannot be delivered during this time. Buffering the multicast packets at the PAR can reduce multicast packet loss but may then increase resource consumption and delay in packet transmission. Implementors should balance the different requirements in the context of predominant application demands (e.g., real-time requirements or loss sensitivity).
多播数据包可能在切换期间丢失。例如，在预测模式下，如图2所示，当MN已经或仍然与网络分离时，数据包可能丢失，即使它们被转发到NAR。在如图3所示的反应模式中，情况可能更糟，因为在MN重新连接到NAR之后，在加入多播组之前会有延迟。在此期间无法传递多播数据包。在PAR中缓冲多播分组可以减少多播分组丢失，但随后可以增加资源消耗和分组传输的延迟。实现者应该在主要应用程序需求（例如，实时需求或损失敏感性）的上下文中平衡不同的需求。
A Mobile Node willing to participate in multicast traffic will join, maintain, and leave groups as if located in the fixed Internet. It will cooperate in handover indication as specified in [RFC5949] and required by its access link-layer technology. No multicast-specific mobility actions nor implementations are required at the MN in a PMIPv6 domain.
愿意参与多播通信的移动节点将加入、维护和离开组，就像位于固定互联网中一样。它将按照[RFC5949]的规定和其接入链路层技术的要求，配合切换指示。PMIPv6域中的MN不需要特定于多播的移动操作或实现。
A MAG receiving a handover indication for one of its MNs follows the same predictive fast handover mode as a PMAG. It MUST issue an MLD General Query immediately on its corresponding link unless it performs explicit membership tracking on that link. After knowledge of the multicast subscriptions of the MN is acquired, the PMAG builds a Multicast Mobility Option, as described in Section 5.3, that contains the MLD and IGMP multicast listener state. If not empty, this Mobility Option is appended to the regular fast handover HI
接收其MN之一的切换指示的MAG遵循与PMAG相同的预测快速切换模式。它必须立即在其对应的链接上发出MLD常规查询，除非它在该链接上执行显式成员身份跟踪。在获得MN的多播订阅的知识后，PMAG构建多播移动性选项，如第5.3节所述，该选项包含MLD和IGMP多播侦听器状态。如果不为空，此移动选项将附加到常规快速切换HI
messages. In the case when a unicast HI message is submitted prior to multicast state detection, the multicast listener state is sent in an additional HI message to the NMAG.
信息。在多播状态检测之前提交单播HI消息的情况下，多播侦听器状态以附加HI消息的形式发送给NMAG。
The PMAG then waits until it receives the Multicast Acknowledgement Option(s) with a HAck message (see Section 5.4) and the bidirectional tunnel with the NMAG is created. After the HAck message is received, the PMAG adds the tunnel to its downstream interfaces in the multicast forwarding database. For those groups reported in the Multicast Acknowledgement Option(s), i.e., not supported in the new access network, the PMAG normally takes appropriate actions (e.g., forwarding and termination) according to the network policy. It SHOULD start forwarding multicast traffic down the tunnel interface for the groups indicated in the multicast listener reports received from NMAG. However, it MAY deny forwarding some or all groups included in the multicast listener reports (e.g., due to administrative configurations or load conditions).
然后，PMAG等待，直到它接收到带有HAck消息的多播确认选项（见第5.4节），并创建带有NMAG的双向隧道。收到HAck消息后，PMAG将隧道添加到多播转发数据库中的其下游接口。对于在多播确认选项中报告的那些组，即在新接入网络中不受支持的组，PMAG通常根据网络策略采取适当的操作（例如，转发和终止）。它应该开始沿着隧道接口为从NMAG接收的多播侦听器报告中指示的组转发多播流量。但是，它可能会拒绝转发包含在多播侦听器报告中的部分或所有组（例如，由于管理配置或负载条件）。
After the departure of the MN and on the reception of a LEAVE message, it is RECOMMENDED that the PMAG terminates forwarding of the specified groups and updates its multicast forwarding database. It correspondingly sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link.
在MN离开后以及在接收到离开消息时，建议PMAG终止指定组的转发并更新其多播转发数据库。对于任何下游链路上不再有任何活动侦听器的组，它相应地向其上游链路发送离开消息。
A MAG receiving a HI message with the Multicast Mobility Option for a currently attached node follows the reactive fast handover mode as a PMAG. It will return a Multicast Acknowledgement Option(s) (see Section 5.4) within a HAck message listing the groups for which it does not provide forwarding support to the NMAG. It will add the bidirectional tunnel with NMAG to its downstream interfaces and will start forwarding multicast traffic for the groups listed in the multicast listener report messages from the NMAG. On reception of a LEAVE message for a group, the PMAG terminates forwarding for the specific group and updates its multicast forwarding database. According to its multicast forwarding state, it sends a LEAVE message to its upstream link for any group where there are no longer any active listeners on any downstream link.
对于当前连接的节点，接收具有多播移动性选项的HI消息的MAG遵循作为PMAG的反应式快速切换模式。它将在黑客消息中返回多播确认选项（见第5.4节），列出它不向NMAG提供转发支持的组。它将向其下游接口添加带有NMAG的双向隧道，并将开始转发来自NMAG的多播侦听器报告消息中列出的组的多播流量。在接收到组的离开消息时，PMAG终止特定组的转发并更新其多播转发数据库。根据它的多播转发状态，它向它的上行链路发送一条离开消息，该消息适用于在任何下行链路上不再有任何活动侦听器的任何组。
In both modes, the PMAG will interpret the departure of the MN as a multicast LEAVE message of the MN and react according to the signaling scheme deployed in the access network (i.e., MLD querying and explicit tracking).
在这两种模式中，PMAG将MN的离开解释为MN的多播离开消息，并根据接入网络中部署的信令方案（即MLD查询和显式跟踪）作出反应。
A MAG receiving a HI message with a Multicast Mobility Option for a currently unattached node follows the same predictive fast handover mode as an NMAG. It will decide the multicast groups to be forwarded from the PMAG and build a Multicast Acknowledgement Option (see Section 5.4) that enumerates only unwanted groups. This Mobility Option is appended to the regular fast handover HAck messages or, in the case of a unicast HAck message being submitted prior to multicast state acknowledgement, sent in an additional HAck message to the PMAG. Immediately thereafter, the NMAG SHOULD update its MLD membership state based on the membership reported in the Multicast Mobility Option. Until the MN reattaches, the NMAG uses its Loopback interface for downstream and MUST NOT forward traffic to the potential link of the MN. The NMAG SHOULD issue JOIN messages for those newly selected groups to its regular multicast upstream interface. As soon as the bidirectional tunnel with PMAG is established, the NMAG additionally joins those groups on the tunnel interface requested to be forwarded from the PMAG.
对于当前未连接的节点，接收具有多播移动性选项的HI消息的MAG遵循与NMAG相同的预测快速切换模式。它将决定要从PMAG转发的多播组，并构建一个多播确认选项（见第5.4节），该选项仅列举不需要的组。该移动性选项附加到常规快速切换黑客消息，或者，如果在多播状态确认之前提交了单播黑客消息，则在附加黑客消息中发送到PMAG。此后，NMAG应立即根据多播移动选项中报告的成员身份更新其MLD成员身份状态。在MN重新连接之前，NMAG将其环回接口用于下游，并且不得将流量转发到MN的潜在链路。NMAG应向其常规多播上游接口发出新选择组的加入消息。一旦建立了带有PMAG的双向隧道，NMAG就会在隧道接口上加入请求从PMAG转发的组。
A MAG experiencing a connection request for an MN without prior reception of a corresponding Multicast Mobility Option is operating in the reactive fast handover mode as an NMAG. Following the reattachment, it SHOULD immediately issue an MLD General Query to learn about multicast subscriptions of the newly arrived MN. Using standard multicast operations, the NMAG joins groups not currently forwarded using its regular multicast upstream interface. Concurrently, it selects groups for forwarding from PMAG and builds a Multicast Mobility Option, as described in Section 5.3, that contains the multicast listener state. If not empty, this Mobility Option is appended to the regular fast handover HI messages with the F flag set or, in the case of unicast HI message being submitted prior to multicast state detection, sent in an additional HI message to the PMAG. Upon reception of the Multicast Acknowledgement Option and establishment of the bidirectional tunnel, the NMAG additionally joins the set of groups on the tunnel interface that it wishes to receive by forwarding from the PMAG. When multicast flows arrive, the NMAG forwards data to the appropriate downlink(s).
在没有事先接收到相应的多播移动性选项的情况下，经历对MN的连接请求的MAG作为NMAG在反应式快速切换模式下操作。在重新连接之后，它应该立即发出MLD通用查询，以了解新到达的MN的多播订阅。使用标准多播操作，NMAG使用其常规多播上游接口加入当前未转发的组。同时，它选择用于从PMAG转发的组，并构建一个包含多播侦听器状态的多播移动选项，如第5.3节所述。如果不是空的，则该移动性选项附加到设置了F标志的常规快速切换HI消息，或者，如果在多播状态检测之前提交了单播HI消息，则在附加HI消息中发送到PMAG。在接收到多播确认选项并建立双向隧道后，NMAG额外加入隧道接口上它希望通过从PMAG转发来接收的组集。当多播流到达时，NMAG将数据转发到适当的下行链路。
In both modes, the NMAG MUST send a LEAVE message to the tunnel when forwarding of a group is no longer needed, e.g., after native multicast traffic arrives or group membership of the MN terminates. Although the message can be delayed, immediately sending the LEAVE message eliminates the need for PAR and NAR to process traffic that is not to be forwarded.
在这两种模式中，当不再需要转发组时，例如在本地多播通信量到达或MN的组成员资格终止后，NMAG必须向隧道发送离开消息。虽然消息可以被延迟，但是立即发送休假消息消除了PAR和NAR处理不转发的业务的需要。
An MN in a PMIPv6 domain MAY use an IPv4 address transparently for communication, as specified in [RFC5844]. For this purpose, Local Mobility Anchors (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 multiprotocol multicast support on the network side, IGMPv3 router functions are required at both MAGs (see Section 5.6 for compatibility considerations with previous IGMP versions). Context transfer between MAGs can transparently proceed in the HI/HAck message exchanges by encapsulating IGMP multicast state records within Multicast Mobility Options (see Sections 5.3 and 5.4 for details on message formats).
PMIPv6域中的MN可以透明地使用IPv4地址进行通信，如[RFC5844]中所述。为此，本地移动锚（LMA）可以在其绑定缓存中注册IPv4代理CoA，而MAG可以在接入网络中提供IPv4支持。相应地，多播成员管理将由MN使用IGMP执行。对于网络端的多协议多播支持，两个MAG都需要IGMPv3路由器功能（有关与先前IGMP版本的兼容性考虑，请参阅第5.6节）。通过在多播移动选项中封装IGMP多播状态记录，MAG之间的上下文传输可以在HI/HAck消息交换中透明地进行（有关消息格式的详细信息，请参见第5.3节和第5.4节）。
The deployment of IPv4 multicast support SHOULD be homogeneous across a PMIP domain. This avoids multicast service breaks during handovers.
IPv4多播支持的部署应该在PMIP域中是一致的。这避免了切换期间多播服务中断。
It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access network and the use of Generic Routing Encapsulation (GRE) tunneling as specified in [RFC5845]. Corresponding implications and operations are discussed in the PMIP Multicast Base Deployment document (see [RFC6224]).
值得一提的是[RFC5845]中规定的双栈IPv4/IPv6接入网络和使用通用路由封装（GRE）隧道的场景。PMIP多播基础部署文档（参见[RFC6224]）中讨论了相应的含义和操作。
This document updates the Proxy Router Advertisements (PrRtAdv) message format defined in Section 6.1.2 of [RFC5568]. The update assigns the first bit of the Reserved field to carry the 'M' bit, as defined in Figure 6. An FMIPv6 AR indicates support for multicast by setting the 'M' bit to a value of 1.
本文件更新了[RFC5568]第6.1.2节中定义的代理路由器广告（PrRtAdv）消息格式。更新分配保留字段的第一位来携带“M”位，如图6所示。FMIPv6 AR通过将“M”位的值设置为1来表示对多播的支持。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Multicast Indicator Bit for Proxy Router Advertisement (PrRtAdv) Message
图6：代理路由器广告（PrRtAdv）消息的多播指示符位
This document updates the Reserved field to include the 'M' bit. It is specified as follows.
此文档更新保留字段以包含“M”位。具体规定如下。
M = 1 indicates that the specifications of this document apply.
M=1表示本文件的规范适用。
M = 0 indicates that the behavior during fast handover proceeds according to [RFC5568].
M=0表示快速切换期间的行为按照[RFC5568]进行。
The default value (0) of this bit indicates a non-multicast-capable service.
此位的默认值（0）表示不支持多播的服务。
The fast handover protocols use an IPv6 header type called Mobility Header, as defined in [RFC6275]. Mobility Headers can carry variable Mobility Options.
根据[RFC6275]中的定义，快速切换协议使用称为移动报头的IPv6报头类型。移动头可以携带可变的移动选项。
The multicast listener context of an MN is transferred in fast handover operations from PAR/PMAG to NAR/NMAG within a new Multicast Mobility Option and MUST be acknowledged by a corresponding Multicast Acknowledgement Option. Depending on the specific handover scenario and protocol in use, the corresponding option is included within the mobility option list of HI/HAck only (PFMIPv6) or of FBU/FBack/HI/ HAck (FMIPv6).
MN的多播侦听器上下文在快速切换操作中在新的多播移动性选项内从PAR/PMAG传输到NAR/NMAG，并且必须由相应的多播确认选项确认。根据具体的切换场景和使用的协议，相应的选项包含在HI/HAck only（PFMIPv6）或FBU/FBack/HI/HAck（FMIPv6）的移动选项列表中。
This section defines the Multicast Mobility Option. It contains the current listener state record of the MN obtained from the MLD Multicast Listener Report message and has the format displayed in Figure 7.
本节定义了多播移动选项。它包含从MLD Multicast listener报告消息中获得的MN的当前侦听器状态记录，其格式如图7所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Mobility Header Multicast Option
图7：移动报头多播选项
Type: 60
类型：60
Length: 8-bit unsigned integer. The length of this option in 32-bit words, not including the Type, Length, Option-Code, and Reserved fields.
长度：8位无符号整数。此选项的长度（32位字），不包括类型、长度、选项代码和保留字段。
Option-Code:
选项代码：
1: IGMPv3 Payload Type
1:IGMPv3有效负载类型
2: MLDv2 Payload Type
2:MLDv2有效负载类型
3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode
3:IGMPv2兼容模式下的IGMPv3有效负载类型
4: MLDv2 Payload Type from MLDv1 Compatibility Mode
4:MLDv1兼容模式下的MLDv2有效负载类型
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
保留：发送方必须将其设置为零，接收方必须忽略。
MLD or IGMP Report Payload: This field is composed of the Membership Report message after stripping its ICMP header. This Report Payload always contains an integer number of multicast records. Corresponding message formats are defined for MLDv2 in [RFC3810] and for IGMPv3 in [RFC3376]. This field MUST always contain the first header line (Reserved field and No of Mcast Address Records).
MLD或IGMP报告有效负载：此字段由剥离ICMP头后的成员报告消息组成。此报告负载始终包含整数个多播记录。[RFC3810]中为MLDv2和[RFC3376]中为IGMPv3定义了相应的消息格式。此字段必须始终包含第一个标题行（保留字段和没有Mcast地址记录）。
Figure 8 shows the Report Payload for MLDv2 (see Section 5.2 of [RFC3810] for the definition of Multicast Address Records). When IGMPv3 is used, the payload format is defined according to IGMPv3 Group Records (see Section 4.2 of [RFC3376] for the definition of Group Records).
图8显示了MLDv2的报告有效负载（有关多播地址记录的定义，请参见[RFC3810]的第5.2节）。当使用IGMPv3时，根据IGMPv3组记录定义有效负载格式（组记录定义见[RFC3376]第4.2节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MLDv2 Report Payload
图8:MLDv2报告有效负载
The Multicast Acknowledgement Option reports the status of the context transfer and contains the list of state records that could not be successfully transferred to the next access network. It has the format displayed in Figure 9.
多播确认选项报告上下文传输的状态，并包含无法成功传输到下一个接入网络的状态记录列表。它的格式如图9所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Mobility Header Multicast Acknowledgement Option
图9：移动报头多播确认选项
Type: 61
类型：61
Length: 8-bit unsigned integer. The length of this option in 32-bit words, not including the Type, Length, Option-Code, and Status fields.
长度：8位无符号整数。此选项的长度（32位字），不包括类型、长度、选项代码和状态字段。
Option-Code: 0
选项代码：0
Status:
地位：
1: Report Payload type unsupported
1：不支持报告有效负载类型
2: Requested group service unsupported
2:请求的组服务不受支持
3: Requested group service administratively prohibited
3：请求的组服务被行政禁止
MLD or IGMP Unsupported Report Payload: This field is syntactically identical to the MLD and IGMP Report Payload field described in Section 5.3 but is only composed of those Multicast Address Records that are not supported or prohibited in the new access network. This field MUST always contain the first header line (Reserved field and No of Mcast Address Records) but MUST NOT contain any Mcast Address Records if the status code equals 1.
MLD或IGMP不支持的报告有效负载：该字段在语法上与第5.3节中描述的MLD和IGMP报告有效负载字段相同，但仅由新接入网络中不支持或禁止的多播地址记录组成。此字段必须始终包含第一个标题行（保留字段和没有Mcast地址记录），但如果状态代码等于1，则不得包含任何Mcast地址记录。
Note that group subscriptions to specific sources may be rejected at the destination network; thus, the composition of multicast address records may differ from initial requests within an MLD or IGMP Report Payload option.
注意，目标网络可能拒绝对特定源的组订阅；因此，多播地址记录的组成可能不同于MLD或IGMP报告有效负载选项内的初始请求。
Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs impose length restrictions on multicast context records due to the 8-bit Length field. The maximal payload length available in FBU/ FBack messages is 4 octets (Mobility Option header line) + 1024 octets (MLD Report Payload). For example, not more than 51 Multicast Address Records of minimal length (without source states) may be exchanged in one message pair. In typical handover scenarios, this number reduces further according to unicast context and Binding Authorization data. A larger number of MLD reports that exceeds the available payload size MAY be sent within multiple HI/HAck or FBU/ FBack message pairs. In PFMIPv6, context information can be fragmented over several HI/HAck messages. However, a single MLDv2 Report Payload MUST NOT be fragmented. Hence, for a single Multicast Address Record, the number of source addresses (S,.) is limited to 62.
在HI/HAck和FBU/FBack对话框中交换的移动头消息由于8位长度字段而对多播上下文记录施加长度限制。FBU/FBack消息中可用的最大有效负载长度为4个八位字节（移动选项标题行）+1024个八位字节（MLD报告有效负载）。例如，在一个消息对中可交换的最小长度（无源状态）的多播地址记录不超过51条。在典型的切换场景中，此数量会根据单播上下文和绑定授权数据进一步减少。超过可用有效负载大小的更多MLD报告可在多个HI/HAck或FBU/FBack消息对内发送。在PFMIPv6中，上下文信息可以在多条HI/HAck消息上进行分段。但是，单个MLDv2报告有效负载不得分段。因此，对于单个多播地址记录，源地址（S，）的数量被限制为62。
Access routers (MAGs) MUST support MLDv2 and IGMPv3. To enable multicast service for MLDv1 and IGMPv2 listeners, the routers MUST follow the interoperability rules defined in [RFC3810] and [RFC3376] and appropriately set the Multicast Address Compatibility Mode.
接入路由器（MAG）必须支持MLDv2和IGMPv3。要为MLDv1和IGMPv2侦听器启用多播服务，路由器必须遵循[RFC3810]和[RFC3376]中定义的互操作性规则，并适当设置多播地址兼容模式。
When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a router internally translates the subsequent MLDv1 and IGMPv2 messages for that multicast address to their MLDv2 and IGMPv3 equivalents and uses these messages in the context transfer. The current state of Compatibility Mode is translated into the code of the Multicast Mobility Option, as defined in Section 5.3. A NAR (NMAG) receiving a Multicast Mobility Option during handover will switch to the lowest level of MLD and IGMP Compatibility Mode that it learned from its previous and new option values. This minimal compatibility agreement is used to allow for continued operation.
当多播地址兼容模式为MLDv1或IGMPv2时，路由器在内部将该多播地址的后续MLDv1和IGMPv2消息转换为它们的MLDv2和IGMPv3等价物，并在上下文传输中使用这些消息。兼容性模式的当前状态被转换为多播移动选项的代码，如第5.3节所定义。在切换期间接收多播移动选项的NAR（NMAG）将切换到从其先前和新选项值中了解到的最低级别的MLD和IGMP兼容模式。此最小兼容性协议用于允许继续运行。
Security vulnerabilities that exceed issues discussed in the base protocols mentioned in this document ([RFC5568], [RFC5949], [RFC3810], and [RFC3376]) are identified as follows.
超出本文档中提到的基本协议（[RFC5568]、[RFC5949]、[RFC3810]和[RFC3376]）中讨论的问题的安全漏洞识别如下。
Multicast context transfer at predictive handovers implements group states at remote access routers and may lead to group subscriptions without further validation of the multicast service requests. Thereby, a NAR (NMAG) is requested to cooperate in potentially complex multicast rerouting and may receive large volumes of traffic. Malicious or inadvertent multicast context transfers may result in a significant burden of route establishment and traffic management onto the backbone infrastructure and the access router itself. Rapid rerouting or traffic overload can be mitigated by a rate control at the AR that restricts the frequency of traffic redirects and the total number of subscriptions. In addition, the wireless access network remains protected from multicast data injection until the requesting MN attaches to the new location.
预测切换时的多播上下文传输在远程访问路由器上实现组状态，并且可能导致组订阅，而无需进一步验证多播服务请求。因此，NAR（NMAG）被请求在潜在复杂的多播重路由中进行合作，并且可能接收大量流量。恶意或无意的多播上下文传输可能会对主干基础设施和访问路由器本身造成路由建立和流量管理的重大负担。AR上的速率控制限制流量重定向的频率和订阅的总数，可以减轻快速重路由或流量过载。此外，在请求MN连接到新位置之前，无线接入网络保持免受多播数据注入的保护。
This document defines two new mobility options that have been allocated from the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters>:
本文件定义了两个新的移动选项，这些选项已从位于的“移动选项”注册表中分配<http://www.iana.org/assignments/mobility-parameters>:
60 Multicast Mobility Option, described in Section 5.3
60多播移动选项，如第5.3节所述
61 Multicast Acknowledgement Option, described in Section 5.4
61多播确认选项，如第5.4节所述
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月<http://www.rfc-editor.org/info/rfc6275>.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 52132008年8月<http://www.rfc-editor.org/info/rfc5213>.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009, <http://www.rfc-editor.org/info/rfc5568>.
[RFC5568]Koodli，R.，“移动IPv6快速切换”，RFC 55682009年7月<http://www.rfc-editor.org/info/rfc5568>.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010, <http://www.rfc-editor.org/info/rfc5949>.
[RFC5949]横田，H.，乔杜里，K.，库德利，R.，帕蒂尔，B.，和夏菲，“代理移动IPv6的快速切换”，RFC 59492010年9月<http://www.rfc-editor.org/info/rfc5949>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月<http://www.rfc-editor.org/info/rfc1112>.
[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, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月<http://www.rfc-editor.org/info/rfc4605>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月<http://www.rfc-editor.org/info/rfc3810>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月<http://www.rfc-editor.org/info/rfc3376>.
[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, <http://www.rfc-editor.org/info/rfc5757>.
[RFC5757]Schmidt，T.，Waehlisch，M.，和G.Fairhurst，“移动IP版本6（MIPv6）中的多播移动性：问题陈述和简要调查”，RFC 5757，2010年2月<http://www.rfc-editor.org/info/rfc5757>.
[FMCAST-MIP6] Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, draft-suh-mipshop-fmcast-mip6-00, February 2004.
[FMCAST-MIP6]Suh，K.，Kwon，D.，Suh，Y.，和Y.Park，“快速切换环境中移动IPv6的快速多播协议”，正在进行的工作，草稿-Suh-mipshop-FMCAST-MIP6-00，2004年2月。
[FMIPv6-Analysis] Schmidt, T. and M. Waehlisch, "Predictive versus Reactive -- Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, Vol. 30, No. 1-3, pp. 123-142, November 2005, <http://dx.doi.org/10.1007/s11235-005-4321-4>.
[FMIPv6分析]Schmidt，T.和M.Waehlisch，“预测性与反应性——切换性能分析及其对IPv6和多播移动性的影响”，电信系统，第30卷，第1-3期，第123-142页，2005年11月<http://dx.doi.org/10.1007/s11235-005-4321-4>.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011, <http://www.rfc-editor.org/info/rfc6224>.
[RFC6224]Schmidt，T.，Waehlisch，M.，和S.Krishnan，“代理移动IPv6（PMIPv6）域中支持多播侦听器的基本部署”，RFC 62242011年4月<http://www.rfc-editor.org/info/rfc6224>.
[RFC7287] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 7287, June 2014, <http://www.rfc-editor.org/info/rfc7287>.
[RFC7287]Schmidt，T.，Gao，S.，Zhang，H.，和M.Waehlisch，“代理移动IPv6（PMIPv6）域中的移动多播发送方支持”，RFC 7287，2014年6月<http://www.rfc-editor.org/info/rfc7287>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月<http://www.rfc-editor.org/info/rfc5844>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010, <http://www.rfc-editor.org/info/rfc5845>.
[RFC5845]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的通用路由封装（GRE）密钥选项”，RFC 58452010年6月<http://www.rfc-editor.org/info/rfc5845>.
This document only specifies protocol operations for fast handovers for mobile listeners. In this appendix, we briefly discuss aspects of supporting mobile multicast sources.
本文档仅指定移动侦听器快速切换的协议操作。在本附录中，我们将简要讨论支持移动多播源的各个方面。
In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender support is likely to be enabled by any one of the mechanisms described in [RFC7287]. In this case, multicast data packets from an MN are transparently forwarded either to its associated LMA or to a multicast-enabled access network. In all cases, a mobile source can continue to transmit multicast packets after a handover from PMAG to NMAG without additional management operations. Packets (with a persistent source address) will continue to flow via the LMA or the access network into the previously established distribution system.
在支持多播的代理移动IPv6域中，多播发送方支持可能由[RFC7287]中描述的任何一种机制启用。在这种情况下，来自MN的多播数据分组被透明地转发到其相关的LMA或多播启用的接入网络。在所有情况下，移动源可以在从PMAG切换到NMAG后继续发送多播分组，而无需额外的管理操作。数据包（具有持久源地址）将继续经由LMA或接入网络流入先前建立的分发系统。
In contrast, an MN will change its Care-of Address while performing FMIPv6 handovers. Even though MNs are enabled to send packets via the reverse NAR-PAR tunnel using their previous Care-of Address for a limited time, multicast sender support in such a Mobile IPv6 regime will most likely follow one of the basic mechanisms described in Section 5.1 of [RFC5757]: (1) bidirectional tunneling, (2) remote subscription, or (3) agent-based solutions. A solution for multicast senders that is homogeneously deployed throughout the mobile access network can support seamless services during fast handovers, the details of which are beyond the scope of this document.
相反，MN将在执行FMIPv6切换时更改其转交地址。即使MN能够在有限的时间内使用其先前的转交地址通过反向NAR-PAR隧道发送数据包，这种移动IPv6机制中的多播发送方支持也很可能遵循[RFC5757]第5.1节中描述的基本机制之一：（1）双向隧道，（2）远程订阅，或（3）基于代理的解决方案。在整个移动接入网络中均匀部署的多播发送方解决方案可以在快速切换期间支持无缝服务，其细节超出了本文档的范围。
Acknowledgments
致谢
Protocol extensions to support multicast in Fast Mobile IPv6 have been loosely discussed for several years. Repeated attempts have been made to define corresponding protocol extensions. The first version [FMCAST-MIP6] was presented by Kyungjoo Suh, Dong-Hee Kwon, Young-Joo Suh, and Youngjun Park in 2004.
在快速移动IPv6中支持多播的协议扩展已经被松散地讨论了好几年。已多次尝试定义相应的协议扩展。2004年，Kyungjoo Suh、Dong Hee Kwon、Young Joo Suh和Youngjun Park发布了第一版[FMCAST-MIP6]。
This work was stimulated by many fruitful discussions in the MobOpts research group. We would like to thank all active members for constructive thoughts and contributions on the subject of multicast mobility. The MULTIMOB working group has provided continuous feedback during the evolution of this work. Comments, discussions, and reviewing remarks have been contributed by (in alphabetical order) Carlos J. Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao, Brian Haberman, Dirk von Hugo, Min Hui, Georgios Karagian, Marco Liebsch, Behcet Sarikaya, Stig Venaas, and Juan Carlos Zuniga.
MobOpts研究小组的许多富有成果的讨论推动了这项工作。我们要感谢所有活跃的成员在多播移动性问题上的建设性想法和贡献。MULTIMOB工作组在这项工作的发展过程中提供了持续的反馈。Carlos J.Bernardos、Luis M.Contreras、Hui Deng、Shuai Gao、Brian Haberman、Dirk von Hugo、Min Hui、Georgios Karagian、Marco Liebsch、Behcet Sarikaya、Stig Venaas和Juan Carlos Zuniga（按字母顺序）发表了评论、讨论和评论。
Funding has been provided by the German Federal Ministry of Education and Research within the projects Mindstone, SKIMS, and SAFEST. This is gratefully acknowledged.
德国联邦教育和研究部在Mindstone、SKIMS和SAFEST项目中提供了资金。这是非常感谢的。
Authors' Addresses
作者地址
Thomas C. Schmidt (editor) HAW Hamburg Dept. Informatik Berliner Tor 7 Hamburg D-20099 Germany
Thomas C.Schmidt（编辑）HAW Hamburg信息部Berliner Tor 7 Hamburg D-20099德国
EMail: t.schmidt@haw-hamburg.de
EMail: t.schmidt@haw-hamburg.de
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin D-10318 Germany
Matthias Waehlisch link lab&FU Berlin Hoenower Str.35 Berlin D-10318德国
EMail: mw@link-lab.net
EMail: mw@link-lab.net
Rajeev Koodli Intel 3600 Juliette Lane Santa Clara, CA 95054 United States
美国加利福尼亚州圣克拉拉朱丽叶巷3600号，邮编95054
EMail: rajeev.koodli@intel.com
EMail: rajeev.koodli@intel.com
Godred Fairhurst University of Aberdeen School of Engineering Aberdeen AB24 3UE United Kingdom
英国阿伯丁大学工程学院
EMail: gorry@erg.abdn.ac.uk
EMail: gorry@erg.abdn.ac.uk
Dapeng Liu China Mobile
刘大鹏中国移动
Phone: +86-123-456-7890
EMail: liudapeng@chinamobile.com
Phone: +86-123-456-7890
EMail: liudapeng@chinamobile.com