Internet Engineering Task Force (IETF) LM. Contreras
Request for Comments: 7161 Telefonica I+D
Category: Experimental CJ. Bernardos
ISSN: 2070-1721 I. Soto
UC3M
March 2014
Internet Engineering Task Force (IETF) LM. Contreras
Request for Comments: 7161 Telefonica I+D
Category: Experimental CJ. Bernardos
ISSN: 2070-1721 I. Soto
UC3M
March 2014
Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)
通过LMA（SIAL）获取订阅信息优化代理移动IPv6（PMIPv6）组播切换
Abstract
摘要
This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).
本文档指定了一种用于代理移动IPv6（PMIPv6）的实验性多播切换优化机制，以加速切换后向移动节点交付多播流量。该机制称为通过LMA的订阅信息获取（SIAL），其基础是通过移动接入网关加速移动节点组播上下文的获取。为此，提出了对当前PMIPv6协议的扩展。这些扩展不仅适用于代理移动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/rfc7161.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7161.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Handover Optimization
Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proxy Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 8
4.1. Active Multicast Subscription Mobility Option . . . . . . 8
4.1.1. Option Application Rules . . . . . . . . . . . . . . 8
4.1.2. Option Format . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Backward Compatibility with MLDv1 . . . . . . . . . . 9
4.2. Multicast Signaling Flag on PBU/PBA Message Headers . . . 10
4.2.1. Flag Application Rules . . . . . . . . . . . . . . . 10
4.2.1.1. Registration Process . . . . . . . . . . . . . . 11
4.2.1.2. De-registration Process . . . . . . . . . . . . . 12
4.2.2. New Format of Conventional PBU/PBA Messages . . . . . 12
4.2.2.1. Proxy Binding Update Message . . . . . . . . . . 12
4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13
4.3. Messages for Active Multicast Subscription Query . . . . 13
4.3.1. Subscription Query Message . . . . . . . . . . . . . 13
4.3.1.1. Message Application Rules . . . . . . . . . . . . 13
4.3.1.2. Message Format . . . . . . . . . . . . . . . . . 14
4.3.2. Subscription Response Message . . . . . . . . . . . . 15
4.3.2.1. Message Application Rules . . . . . . . . . . . . 15
4.3.2.2. Message Format . . . . . . . . . . . . . . . . . 15
4.4. New PBA Timer in the LMA . . . . . . . . . . . . . . . . 16
5. Handover Signaling Procedures . . . . . . . . . . . . . . . . 17
5.1. Handover of Proactive Type . . . . . . . . . . . . . . . 17
5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Message Flow Description . . . . . . . . . . . . . . 18
5.2. Handover of Reactive Type . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Handover Optimization
Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proxy Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 8
4.1. Active Multicast Subscription Mobility Option . . . . . . 8
4.1.1. Option Application Rules . . . . . . . . . . . . . . 8
4.1.2. Option Format . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Backward Compatibility with MLDv1 . . . . . . . . . . 9
4.2. Multicast Signaling Flag on PBU/PBA Message Headers . . . 10
4.2.1. Flag Application Rules . . . . . . . . . . . . . . . 10
4.2.1.1. Registration Process . . . . . . . . . . . . . . 11
4.2.1.2. De-registration Process . . . . . . . . . . . . . 12
4.2.2. New Format of Conventional PBU/PBA Messages . . . . . 12
4.2.2.1. Proxy Binding Update Message . . . . . . . . . . 12
4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13
4.3. Messages for Active Multicast Subscription Query . . . . 13
4.3.1. Subscription Query Message . . . . . . . . . . . . . 13
4.3.1.1. Message Application Rules . . . . . . . . . . . . 13
4.3.1.2. Message Format . . . . . . . . . . . . . . . . . 14
4.3.2. Subscription Response Message . . . . . . . . . . . . 15
4.3.2.1. Message Application Rules . . . . . . . . . . . . 15
4.3.2.2. Message Format . . . . . . . . . . . . . . . . . 15
4.4. New PBA Timer in the LMA . . . . . . . . . . . . . . . . 16
5. Handover Signaling Procedures . . . . . . . . . . . . . . . . 17
5.1. Handover of Proactive Type . . . . . . . . . . . . . . . 17
5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Message Flow Description . . . . . . . . . . . . . . 18
5.2. Handover of Reactive Type . . . . . . . . . . . . . . . . 20
5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Message Flow Description . . . . . . . . . . . . . . 21
5.2.3. Further Considerations for the Reactive Handover
Signaling . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Prevention of Large Delays of the Binding
Acknowledgement for Unicast Traffic . . . . . . . . . . . 23
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26
6.2. Signaling Procedures for IPv4 Support . . . . . . . . . . 27
6.3. Binding Cache Extensions for IPv4 Support . . . . . . . . 28
7. Coexistence with PMIPv6 Multicast Architectural
Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Performance Comparison with Base Solution . . . . . 34
A.1. Delay Characterization of the Base Solution . . . . . . . 34
A.2. Delay Characterization of SIAL . . . . . . . . . . . . . 35
A.3. Performance Comparison . . . . . . . . . . . . . . . . . 35
5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Message Flow Description . . . . . . . . . . . . . . 21
5.2.3. Further Considerations for the Reactive Handover
Signaling . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Prevention of Large Delays of the Binding
Acknowledgement for Unicast Traffic . . . . . . . . . . . 23
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26
6.2. Signaling Procedures for IPv4 Support . . . . . . . . . . 27
6.3. Binding Cache Extensions for IPv4 Support . . . . . . . . 28
7. Coexistence with PMIPv6 Multicast Architectural
Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Performance Comparison with Base Solution . . . . . 34
A.1. Delay Characterization of the Base Solution . . . . . . . 34
A.2. Delay Characterization of SIAL . . . . . . . . . . . . . 35
A.3. Performance Comparison . . . . . . . . . . . . . . . . . 35
The base solution for providing continuous multicast service delivery in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]. It specifies the basic functionality needed in the Proxy Mobile IPv6 [RFC5213] entities to provide a multicast service, so continuous delivery of multicast traffic is supported by obtaining, after each handover, the ongoing multicast subscription information directly from the Mobile Node (MN). When a mobile node attaches to a new Mobile Access Gateway (MAG), the mobile node is queried by the mobile access gateway through a Multicast Listener Discovery (MLD) General Query, which is sent just after any new link is set up, to learn of any existing subscription, as specified in [RFC2710] and [RFC3810].
[RFC6224]中描述了在代理移动IPv6（PMIPv6）域中提供连续多播服务交付的基本解决方案。它指定了代理移动IPv6[RFC5213]实体中提供多播服务所需的基本功能，因此，通过在每次切换后直接从移动节点（MN）获取正在进行的多播订阅信息，支持多播流量的连续传送。当移动节点连接到新的移动接入网关（MAG）时，移动接入网关通过多播侦听器发现（MLD）通用查询来查询移动节点，该查询在任何新链路建立后立即发送，以了解任何现有订阅，如[RFC2710]和[RFC3810]中所述。
However, the base solution needs to be improved to meet some performance requirements, especially those referring to the user-perceived service quality, which is seriously affected by the disruption of multicast content forwarding to the mobile node during handovers.
然而，基本解决方案需要改进以满足一些性能要求，特别是那些涉及用户感知的服务质量的性能要求，这些服务质量受到切换期间向移动节点转发的多播内容中断的严重影响。
A mobile node with an active multicast subscription, moving from one point of attachment to another within a Proxy Mobile IPv6 domain, experiences a certain delay until it resumes receiving again the multicast content that it was receiving at the previous location.
具有活动多播订阅的移动节点在代理移动IPv6域内从一个连接点移动到另一个连接点时，会经历一定的延迟，直到重新开始接收其在先前位置接收的多播内容为止。
Such delay causes a gap in the content reception. Two different actions can help mitigate such reception gap. One of them is to buffer at the previous mobile access gateway a copy of the multicast traffic destined to the mobile node and forward it to the new mobile access gateway, in order to deliver that traffic to the mobile node. The other possible (complementary) action is to reduce the time needed by the new mobile access gateway to learn of the active multicast subscription of the mobile node (i.e., the multicast context), so the new mobile access gateway can subscribe to the multicast group(s) on behalf of the mobile node as soon as possible.
这种延迟导致内容接收中的间隙。两种不同的措施有助于缓解这种接收差距。其中之一是在先前的移动接入网关处缓冲目的地为移动节点的多播业务的副本，并将其转发到新的移动接入网关，以便将该业务传送到移动节点。另一个可能的（补充）动作是减少新移动接入网关学习移动节点的活动多播订阅（即，多播上下文）所需的时间，以便新移动接入网关能够代表移动节点尽快订阅多播组。
While the first mechanism could potentially be accomplished by using some adaptation of [RFC5949] to multicast traffic (despite being only applicable in the case the underlying radio access technology supports Layer 2 (L2) triggers, thus requiring additional support on the mobile node), there is no generic standard solution for the accelerated acquisition of the ongoing multicast subscription of the mobile node.
虽然第一种机制可能通过使用[RFC5949]对多播通信量的一些自适应来实现（尽管仅适用于底层无线接入技术支持第2层（L2）触发器的情况，因此需要移动节点上的额外支持），没有通用的标准解决方案用于加速获取移动节点的正在进行的多播订阅。
The approach followed by the base solution [RFC6224] to learn of an existing multicast subscription relies on the behavior of the IGMP/ MLD protocols. Both protocols send multicast membership query messages when a new link is up. The response to such a message reports any existing multicast subscriptions by the mobile node. While this is a straightforward approach, the mobile access gateway can incur in a non-negligible delay in receiving the corresponding MLD Report message. This delay is caused by the time needed for the detection of the attachment in the new link and the re-establishment of the data plane after the handover, the radio transfer delays associated with the signaling to the mobile node, and the MLD query response interval time required by this procedure (whose default value is 10 seconds as defined in [RFC2710] and [RFC3810], or between 5 and 10 seconds as considered in the best case wireless link scenario in [RFC6636]).
基本解决方案[RFC6224]了解现有多播订阅所遵循的方法依赖于IGMP/MLD协议的行为。这两个协议都在新链接启动时发送多播成员资格查询消息。对此类消息的响应报告移动节点的任何现有多播订阅。虽然这是一种简单的方法，但移动接入网关在接收相应的MLD报告消息时会产生不可忽略的延迟。该延迟是由检测新链路中的连接和在切换后重新建立数据平面所需的时间、与发送到移动节点的信令相关联的无线电传输延迟以及该过程所需的MLD查询响应间隔时间（其默认值为中定义的10秒）引起的[RFC2710]和[RFC3810]，或在[RFC6636]中的最佳无线链路方案中考虑的5到10秒之间。
This document extends the Proxy Mobile IPv6 signaling protocol defined in the base protocol [RFC5213] by including a new multicast information option to update Proxy Mobile IPv6 entities during the registration and de-registration processes, and new messages to trigger the transfer of multicast information. No extension is required in any of the multicast-related protocols in use (IGMP/MLD or PIM protocols). Furthermore, this specification does not substitute the standard procedures defined in [RFC6224] (e.g., the mobile access gateway continues sending an MLD Query to the entering mobile node as soon as the point-to-point link is set up), but complements them for accelerating the acquisition of the multicast content by the mobile access gateway associated to the new point-of-attachment.
本文档扩展了基本协议[RFC5213]中定义的代理移动IPv6信令协议，包括用于在注册和注销过程中更新代理移动IPv6实体的新多播信息选项，以及用于触发多播信息传输的新消息。使用中的任何多播相关协议（IGMP/MLD或PIM协议）都不需要扩展。此外，本规范不替代[RFC6224]中定义的标准程序（例如，一旦建立点到点链路，移动接入网关将继续向进入的移动节点发送MLD查询），但是，通过与新连接点相关联的移动接入网关来加速多播内容的获取，这是对它们的补充。
This document provides a signaling method internal to the network to speed up the subscription information acquisition by the mobile access gateway, in order to accelerate the multicast delivery to the mobile node after having completed a handover. By doing so, the knowledge by the mobile access gateway of the currently active multicast subscription becomes independent of the underlying radio technology dynamics and relaxes the requirement of a rapid response from the mobile node in processing IGMP/MLD control messages. Issues like radio framing, radio access contention, channel reliability, MN's capabilities (i.e., L2 triggering support), IGMP/MLD timers optimization for wireless environments, etc., will not impact the observed multicast performance during handovers.
本文档提供了网络内部的信令方法，以加速移动接入网关获取订阅信息，以便在完成切换后加速向移动节点的多播传送。通过这样做，移动接入网关对当前活动的多播订阅的了解变得独立于底层无线电技术动态，并且放松了在处理IGMP/MLD控制消息时来自移动节点的快速响应的要求。无线帧、无线接入争用、信道可靠性、MN能力（即L2触发支持）、无线环境的IGMP/MLD定时器优化等问题不会影响切换期间观察到的多播性能。
The mechanisms described in this document can also be applied to the solutions defined in [RFC7028]. Furthermore, it is also independent of the role played by the mobile access gateway within the multicast network (acting as either MLD proxy or multicast router).
本文件中描述的机制也可应用于[RFC7028]中定义的解决方案。此外，它还独立于移动接入网关在多播网络中扮演的角色（充当MLD代理或多播路由器）。
A basic solution for providing support of multicast in a network-based mobility management environment has been specified in [RFC6224] without introducing changes on the original PMIPv6 specification [RFC5213]. The focus of the present document is on improving the efficiency of the base solution regarding handover performance.
[RFC6224]中规定了在基于网络的移动性管理环境中提供多播支持的基本解决方案，而没有对原始PMIPv6规范[RFC5213]进行更改。本文档的重点是提高基本解决方案在切换性能方面的效率。
One of the critical aspects of the base solution is the expected delay incurred by the mobile access gateway (where the mobile node is being attached to) to be informed about the ongoing multicast subscription of the entering MN, mainly due to the fact that the mechanisms provided in the base solution relay on the original MLD procedures, with long timing interactions not conceived for mobile environments. Then, the requirements to be covered by a handover optimization solution can be established in the following manner:
基本解决方案的一个关键方面是移动接入网关（移动节点连接到其中）被告知进入MN的正在进行的多播订阅所产生的预期延迟，这主要是由于基本解决方案中提供的机制中继于原始MLD过程这一事实，长时间的交互不适用于移动环境。然后，可以通过以下方式确定切换优化解决方案所涵盖的需求：
o The solution MUST be applicable to any kind of MN (that is, not requiring any particular functionality such as, for example, L2 trigger capabilities), in such a way that any type of mobile node in a PMIPv6 domain being served with multicast traffic can benefit from the optimized solution.
o 该解决方案必须适用于任何类型的MN（即，不需要任何特定功能，例如，L2触发功能），以这样的方式，在PMIPv6域中被多播业务服务的任何类型的移动节点都可以受益于优化的解决方案。
o The solution MUST NOT impact existing multicast protocols.
o 该解决方案不得影响现有的多播协议。
o The solution MUST optimize the handover performance with respect to the performance achieved with the base solution for any kind of handover process (i.e., for proactive and reactive handovers).
o 对于任何类型的切换过程（即，对于主动式和反应式切换），该解决方案必须优化切换性能，使其与基本解决方案实现的性能相比较。
o The solution SHOULD minimize the number and extent of additional support (i.e., capabilities) required in the network, aiming at an easier deployment.
o 该解决方案应尽量减少网络中所需的额外支持（即能力）的数量和范围，以便于部署。
o The solution MUST NOT impact deployments of legacy implementations of [RFC5213] and [RFC6224].
o 该解决方案不得影响[RFC5213]和[RFC6224]的旧式实现的部署。
The present specification addresses all these requirements, as described in the following sections.
本规范阐述了所有这些要求，如以下章节所述。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the terminology referring to PMIPv6 components as defined in [RFC5213].
本文件使用[RFC5213]中定义的PMIPv6组件术语。
Additionally, the following terms are defined and used in this document.
此外，本文件中定义并使用了以下术语。
pMAG: The previous MAG or pMAG is the mobile access gateway where the MN was initially registered before a handover event.
pMAG：前一个MAG或pMAG是移动接入网关，MN在切换事件之前最初在其中注册。
nMAG: The new MAG or nMAG is the mobile access gateway where the MN is registered at the end of the handover event.
nMAG：新的MAG或nMAG是移动接入网关，在切换事件结束时在其中注册MN。
Reactive Handover: A reactive handover is a handover event in which the Local Mobility Anchor (LMA) receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG.
反应性切换：反应性切换是一种切换事件，其中本地移动锚（LMA）从nMAG接收移动节点注册，而之前没有从pMAG接收MN取消注册。
Proactive Handover: A proactive handover is a handover event where the mobile node is firstly de-registered on the local mobility anchor by the pMAG, and later on it is registered by the nMAG as a consequence of changing the point of attachment.
主动切换：主动切换是一种切换事件，其中移动节点首先由pMAG在本地移动锚上注销，然后由于连接点的改变而由nMAG注册。
Multicast Membership Context: In this document, multicast membership context makes reference to the information relative to the currently active multicast subscription of an MN in a handover event that is transferred between the PMIPv6 entities to support the handover optimization.
多播成员上下文：在本文档中，多播成员上下文引用切换事件中MN当前活动多播订阅的相关信息，该事件在PMIPv6实体之间传输，以支持切换优化。
The local mobility anchor is a key element within the PMIPv6 infrastructure, which traces the mobile node reachability along the PMIPv6 domain. Therefore, the LMA is the best element to keep the MNs' multicast subscription information up-to-date and to forward it to the rest of PMIPv6 entities (i.e., to the mobile access gateways) as needed when MNs move within the domain. The LMA has timely knowledge of the MNs' locations, especially during handover events, and it is therefore able to quickly provide information to the new point of attachment (e.g., by querying the previous one). Figure 1 summarizes the main idea of the optimization.
本地移动性锚是PMIPv6基础设施中的一个关键元素，它沿着PMIPv6域跟踪移动节点的可达性。因此，LMA是保持MNs的多播订阅信息最新并在MNs在域内移动时根据需要将其转发给其余PMIPv6实体（即，移动接入网关）的最佳元素。LMA及时了解MNs的位置，尤其是在切换事件期间，因此能够快速向新的连接点提供信息（例如，通过查询前一个连接点）。图1总结了优化的主要思想。
+------+
| pMAG | |
+------+ |
/ |
/ |
/ |
/ |
-*-*-*-*- / (MN)
( ) / |
( ) +-----+ +------+ |
( Internet )--| LMA |------| nMAG | v
( ) +-----+ +------+
( )
-*-*-*-*- Registration
<--------------
+------+
| pMAG | |
+------+ |
/ |
/ |
/ |
/ |
-*-*-*-*- / (MN)
( ) / |
( ) +-----+ +------+ |
( Internet )--| LMA |------| nMAG | v
( ) +-----+ +------+
( )
-*-*-*-*- Registration
<--------------
Registration Ack
& Multicast Context
-------------->
Registration Ack
& Multicast Context
-------------->
Figure 1: High-Level Description of the Solution
图1：解决方案的高级描述
The local mobility anchor only obtains the detailed subscription information or multicast context during a handover event. There is no need for continuously informing the LMA about MNs' multicast state while the mobile nodes remain attached to the same mobile access gateway. Such a continuous updating procedure would significantly increase the signaling load within the PMIPv6 domain without a clear benefit. The multicast context is only critical during handovers: neither after nor before. Indicating the active subscription while the handover is ongoing guarantees that such information will be up to date and ready to be transferred to the new MAG where the mobile node has just attached. Therefore, this solution defines the Subscription Information Acquisition through the LMA (SIAL) as the
本地移动锚在切换事件期间仅获取详细的订阅信息或多播上下文。当移动节点保持连接到同一移动接入网关时，不需要连续地向LMA通知MNs的多播状态。这样的连续更新过程将显著增加PMIPv6域内的信令负载，但没有明显的好处。多播上下文仅在切换期间至关重要：既不是在切换之后也不是在切换之前。在切换正在进行时指示活动订阅可确保此类信息将是最新的，并准备好传输到移动节点刚刚连接的新MAG。因此，该解决方案将通过LMA（SIAL）获取订阅信息定义为
procedure to inform the new MAG about the multicast subscriptions maintained by the entering MN.
通知新MAG由进入的MN维护的多播订阅的过程。
To be able to transfer the multicast subscription information between PMIPv6 entities during a handover, this document extends the PMIPv6 protocol in several ways. First of all, a new mobility option is defined to carry the multicast context of the current subscription. Furthermore, additional messages are defined to manage the interchange of the multicast information among PMIPv6 entities. Finally, some flags are defined to govern the process.
为了能够在切换期间在PMIPv6实体之间传输多播订阅信息，本文档以多种方式扩展了PMIPv6协议。首先，定义了一个新的移动选项来承载当前订阅的多播上下文。此外，定义了附加消息以管理PMIPv6实体之间的多播信息交换。最后，定义了一些标志来管理流程。
This section outlines the extensions proposed to the PMIPv6 protocol specified in [RFC5213].
本节概述了[RFC5213]中规定的PMIPv6协议的扩展。
A new TLV-encoded mobility option, Active Multicast Subscription option is defined for use with the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages exchanged between a local mobility anchor and a mobility access gateway to transfer the multicast subscription information. This option is used for exchanging the multicast membership context. This information is carried by directly using the format defined in the original MLD specifications. There can be multiple Active Multicast Subscription options present in the message, one for each active subscription maintained by the mobile node when the handover is taking place (i.e., one per multicast membership context).
定义了一种新的TLV编码的移动选项，即主动多播订阅选项，用于在本地移动锚和移动接入网关之间交换代理绑定更新（PBU）和代理绑定确认（PBA）消息以传输多播订阅信息。此选项用于交换多播成员身份上下文。该信息通过直接使用原始MLD规范中定义的格式进行传输。消息中可以存在多个活动多播订阅选项，当切换发生时，移动节点维护的每个活动订阅一个（即，每个多播成员上下文一个）。
This new option is also used for the same purposes by the new Subscription Response message defined later in this document.
此新选项也用于本文档后面定义的新订阅响应消息的相同目的。
MLDv2 [RFC3810] is the primary objective for the definition of the option format. MLDv1 [RFC2710] is also considered for backward compatibility.
MLDv2[RFC3810]是定义选项格式的主要目标。MLDv1[RFC2710]还考虑了向后兼容性。
The format of this new option is as follows:
此新选项的格式如下：
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 | MLD Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | MLD Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirement of this option is 8n+1.
该选项的对齐要求为8n+1。
Type:
类型：
57, which indicates the Active Multicast Subscription IPv6 option.
57，表示活动多播订阅IPv6选项。
Length:
长度：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
MLD type:
MLD类型：
Field used to identify the IPv6 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original MLD specifications for the Report message. For MLDv2, the MLD Type value is 143, as specified in [RFC3810].
用于标识正在使用的IPv6多播成员身份协议的字段，以及下一个多播成员身份上下文信息字段的相应格式。此字段映射报告消息的原始MLD规范中使用的类型编码。对于MLDv2，MLD类型值为143，如[RFC3810]中所规定。
Multicast Membership Context:
多播成员身份上下文：
Multicast subscription information corresponding to a single subscribed multicast address. For MLDv2, the format of this field follows the Multicast Address Record format as defined in [RFC3810].
与单个订阅的多播地址对应的多播订阅信息。对于MLDv2，此字段的格式遵循[RFC3810]中定义的多播地址记录格式。
The following values are adopted when MLDv1 is used.
使用MLDv1时采用以下值。
MLD type:
MLD类型：
For MLDv1, the MLD Type value is 131, as specified in [RFC2710].
对于MLDv1，MLD类型值为131，如[RFC2710]中所规定。
Multicast Membership Context:
多播成员身份上下文：
For MLDv1, the relevant information for multicast context is simply given, according to [RFC2710], by the multicast address of the subscribed content.
对于MLDv1，根据[RFC2710]，通过订阅内容的多播地址简单地给出多播上下文的相关信息。
In consequence, the Multicast Membership Context is defined as a 4-octet reserved field and the Multicast Address of the subscribed content as in [RFC2710], as shown next.
因此，如[RFC2710]中所示，多播成员上下文被定义为4个八位组的保留字段和订阅内容的多播地址，如下所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new flag S has been added in both the PBU and PBA message headers to advertise the mobile access gateway and the local mobility anchor capabilities of processing multicast-related signaling for the MN that caused the message.
在PBU和PBA消息报头中都添加了新的标志S，以通告移动接入网关和本地移动性锚点处理导致该消息的MN的多播相关信令的能力。
This flag governs the multicast-related signaling between the LMA and the MAG. As a general rule, the value of the flag in the PBA message is a copy of the value received in the PBU message. Specific rules are described in next subsections.
该标志控制LMA和MAG之间的多播相关信令。作为一般规则，PBA消息中的标志值是PBU消息中接收到的值的副本。具体规则将在下一小节中介绍。
During handover, the entities involved in this process are the nMAG and the LMA. These rules also apply for the initial binding registration process.
在移交期间，该过程中涉及的实体是nMAG和LMA。这些规则也适用于具有约束力的初始注册过程。
o PBU message
o PBU报文
* S=0 indicates that the MAG sending the PBU message does not accept multicast-related signaling for the MN being attached. This can be used to discriminate PMIPv6 nodes that are not multicast enabled, for backward compatibility reasons.
* S=0表示发送PBU消息的MAG不接受所连接MN的多播相关信令。出于向后兼容性原因，这可用于区分未启用多播的PMIPv6节点。
* S=1 indicates that the MAG sending the PBU message accepts multicast-related signaling for the MN being attached. Depending on the type of handover (reactive or proactive) the LMA takes some actions, described later in this document.
* S＝1表示发送PBU消息的MAG接受所连接的MN的多播相关信令。根据切换的类型（反应式或主动式），LMA会采取一些措施，本文档稍后将对此进行描述。
o PBA message
o PBA消息
* If S=0 in the corresponding PBU message, the value of the flag in the PBA message MUST be a copy of the value received in the PBU message (thus S=0), without any further meaning.
* 如果在相应的PBU消息中S=0，则PBA消息中的标志值必须是在PBU消息中接收到的值的副本（因此S=0），没有任何进一步的含义。
* If S=1 in the corresponding PBU message, two subcases are possible:
* 如果相应PBU消息中的S=1，则可能有两个子类别：
+ S=1 and Active Multicast Subscription mobility option in the PBA message. When the MN maintains an active multicast session, if the LMA is able to provide the multicast subscription information during registration, the PBA message MUST include the Active Multicast Subscription mobility option. If the LMA is not able to provide such information during registration, the PBA message MUST NOT include the Active Multicast Subscription mobility option. This case is useful to decouple unicast and multicast signaling for an MN being registered at nMAG. A way for obtaining later active multicast-subscription information is described later in this document.
+ S=1和PBA消息中的活动多播订阅移动选项。当MN维持活动多播会话时，如果LMA能够在注册期间提供多播订阅信息，则PBA消息必须包括活动多播订阅移动性选项。如果LMA在注册期间不能提供此类信息，则PBA消息不得包括主动多播订阅移动选项。这种情况对于在nMAG注册的MN的单播和多播信令解耦非常有用。本文档后面将描述获取后续活动多播订阅信息的方法。
+ S=0 in the PBA message if the MN does not maintain an active multicast subscription (note that for backward compatibility reasons, an LMA not supporting multicast related signaling would always send S=0).
+ 如果MN不保持活动多播订阅，则PBA消息中的S=0（注意，出于向后兼容性原因，不支持多播相关信令的LMA将始终发送S=0）。
During handover, the entities involved in this process are the pMAG and the LMA. These rules apply for the binding de-registration process.
在移交期间，参与该过程的实体为pMAG和LMA。这些规则适用于具有约束力的注销流程。
o PBU message
o PBU报文
* S=0 indicates that the MN has no active multicast session (note that for backward compatibility reasons, a pMAG not supporting multicast related signaling would always send S=0).
* S=0表示MN没有活动的多播会话（注意，出于向后兼容性的原因，不支持多播相关信令的pMAG将始终发送S=0）。
* S=1 indicates that the MN has an active multicast session, and the multicast context MUST be transported in the Active Multicast Subscription mobility option.
* S=1表示MN具有活动多播会话，并且必须在活动多播订阅移动选项中传输多播上下文。
o PBA message
o PBA消息
* The value of the flag in the PBA message SHOULD be 0, without any further meaning (note that for backward compatibility reasons, an LMA not supporting multicast related signaling would always send S=0).
* PBA消息中的标志值应为0，没有任何进一步的含义（注意，出于向后兼容性原因，不支持多播相关信令的LMA将始终发送S=0）。
As result of the new defined flag, the PBU message format is updated as follows:
根据新定义的标志，PBU消息格式更新如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As result of the new defined flag, the PBA message format is updated as follows:
根据新定义的标志，PBA消息格式更新如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new pair of messages is defined for querying entities about the active multicast subscription of the MN when the handover is of reactive type.
定义了一对新的消息，用于在切换为被动类型时查询有关MN的主动多播订阅的实体。
These messages are sent using the Mobility Header as defined in [RFC6275].
这些消息使用[RFC6275]中定义的移动报头发送。
The Subscription Query message (value 22) is sent by the LMA towards the pMAG to query it about any existing multicast subscriptions of the MN that is being registered by the nMAG. This message is generated in case the handover is of reactive type.
订阅查询消息（值22）由LMA向pMAG发送，以查询nMAG正在注册的MN的任何现有多播订阅。该消息在切换为被动类型时生成。
Additionally, this message is sent by the nMAG towards the LMA to query it about the existing multicast subscriptions of the MN when the LMA acknowledges the PBU sent by the nMAG but the multicast context is not provided (namely, when the PBU message has set the flag S to 1, and the PBA message has set the flag S to 1 but the multicast context is missing).
此外，当LMA确认nMAG发送的PBU但未提供多播上下文时，nMAG向LMA发送该消息，以查询MN的现有多播订阅（即，当PBU消息已将标志S设置为1，并且PBA消息已将标志S设置为1但多播上下文丢失时）。
The Subscription Query message has the following format.
订阅查询消息的格式如下。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
序列号：
The Sequence Number field establishes the order of the messages sent in the Subscription Query / Subscription Response dialogue between the LMA and the MAG for a certain MN. The initial Sequence Number MUST be determined by the entity that creates the message (either LMA or MAG, depending on the scenario), which is responsible for managing this counter.
序列号字段为特定MN建立在LMA和MAG之间的订阅查询/订阅响应对话中发送的消息的顺序。初始序列号必须由创建消息的实体（LMA或MAG，取决于场景）确定，该实体负责管理该计数器。
This Sequence Number comparison MUST be performed modulo 2**8, i.e., the number is a free-running counter represented modulo 256. A Sequence Number in a received Subscription Query message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 128 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 143 through 255, would be considered less than or equal.
此序列号比较必须以模2**8执行，即该数字是以模256表示的自由运行计数器。如果接收到的订阅查询消息中的序列号的值位于上次接收的序列号和前面的128个值（包括）的范围内，则认为该序列号小于或等于上次接收的序列号。例如，如果最后收到的序列号是15，则序列号为0到15以及143到255的消息将被视为小于或等于。
Reserved:
保留：
This field is unused for now. The value MUST be initialized to 0.
此字段目前未使用。该值必须初始化为0。
Mobility options:
移动选项：
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following:
此消息包含一个或多个TLV编码的移动选项。此消息的有效移动选项如下所示：
* Mobile Node Identifier option [RFC4283] (mandatory).
* 移动节点标识符选项[RFC4283]（必需）。
* Home Network Prefix option [RFC5213] (optional).
* 家庭网络前缀选项[RFC5213]（可选）。
There can be one or more instances of the Home Network Prefix option, but only one instance of the Mobile Node Identifier option.
家庭网络前缀选项可以有一个或多个实例，但移动节点标识符选项只能有一个实例。
The Subscription Response message (value 23) is sent by the pMAG towards the LMA, or by the LMA towards the nMAG, to answer a previously received Subscription Query message, as described above.
订阅响应消息（值23）由pMAG向LMA发送，或由LMA向nMAG发送，以回答先前接收到的订阅查询消息，如上所述。
The Subscription Response message has the following format.
订阅响应消息具有以下格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
序列号：
The value of the Sequence Number field in the Subscriber Response message MUST be a copy of the Sequence Number received in the Subscription Query message.
订户响应消息中的序列号字段的值必须是订阅查询消息中接收到的序列号的副本。
Multicast Information (I):
多播信息（I）：
The multicast Information flag I specifies whether or not there is multicast subscription information available for the MN. The meaning is the following:
多播信息标志I指定是否存在可用于MN的多播订阅信息。其含义如下：
I=0: there is no multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message.
I=0：此消息中的移动节点标识符选项标识的MN没有可用的多播订阅信息。
I=1: there is multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message. The multicast subscription information MUST be
I=1：此消息中有由移动节点标识符选项标识的MN可用的多播订阅信息。必须保存多播订阅信息
carried on one or more instances of the Active Multicast Subscription option in this message (one instance for each active subscription).
执行此消息中活动多播订阅选项的一个或多个实例（每个活动订阅一个实例）。
Reserved:
保留：
This field is unused for now. The value MUST be initialized to 0.
此字段目前未使用。该值必须初始化为0。
Mobility options:
移动选项：
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following:
此消息包含一个或多个TLV编码的移动选项。此消息的有效移动选项如下所示：
* Mobile Node Identifier option [RFC4283] (mandatory).
* 移动节点标识符选项[RFC4283]（必需）。
* Active Multicast Subscription option (mandatory) only when flag I=1; it MUST NOT be present in any other case.
* 仅当标志I=1时，活动多播订阅选项（强制）；在任何其他情况下都不得出现。
* Home Network Prefix option [RFC5213] (optional).
* 家庭网络前缀选项[RFC5213]（可选）。
There can be one or more instances of the Home Network Prefix option (in all cases) and the Active Multicast Subscription option (only when I=1), but only one instance of the Mobile Node Identifier option.
家庭网络前缀选项（在所有情况下）和活动多播订阅选项（仅当I=1时）可以有一个或多个实例，但移动节点标识符选项只有一个实例。
A new timer named "PBA timer" is used in the LMA to define the maximum waiting time before the PBA message is sent to the nMAG in case the multicast subscription information relative to the MN is not yet available. The aim of this timer is to prevent potential large delays in the forwarding of unicast traffic towards the MN being registered at the nMAG. This timer allows decoupling the unicast signaling from the multicast one in the SIAL solution.
在LMA中使用名为“PBA timer”的新定时器来定义在与MN相关的多播订阅信息还不可用的情况下PBA消息发送到nMAG之前的最大等待时间。该计时器的目的是防止在向nMAG注册的MN转发单播流量时出现潜在的大延迟。此计时器允许在SIAL解决方案中将单播信令与多播信令分离。
This timer SHOULD be upper bounded by the constant defined in [RFC6275] INITIAL_BINDACK_TIMEOUT, whose default value is 1 s. This constant sets the time when the nMAG will retry the MN registration by sending again the PBU message. The "PBA timer" has to be set to a value that ensures that the nMAG does not enter the retry mode. Operational experience is needed on how to set up the PBA timer, and therefore it is RECOMMENDED to set the "PBA timer" to zero, except for experimental purposes.
此计时器的上限应为[RFC6275]INITIAL_BINDACK_TIMEOUT中定义的常量，其默认值为1s。此常量设置nMAG通过再次发送PBU消息重试MN注册的时间。必须将“PBA定时器”设置为确保nMAG不会进入重试模式的值。在如何设置PBA定时器方面需要操作经验，因此建议将“PBA定时器”设置为零，实验目的除外。
As the MN moves from one access gateway to another, the mobility-related signaling due to the handover event is carried out independently by the pMAG and the nMAG. That signaling process is not synchronized; thus, two scenarios need to be considered depending on the order in which the LMA receives notification of the MN registration and de-registration in the nMAG and the pMAG, respectively.
当MN从一个接入网关移动到另一个接入网关时，由切换事件引起的移动相关信令由pMAG和nMAG独立地执行。信号传递过程不同步；因此，需要根据LMA分别在nMAG和pMAG中接收MN注册和注销通知的顺序来考虑两种场景。
In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG as a consequence of changing the point of attachment.
在主动式情况下，MN首先由pMAG注销，然后由nMAG注册，这是更改连接点的结果。
Only for those MNs that maintain an active multicast subscription, the pMAG includes the Active Multicast Subscription mobility option carrying the multicast context of the MN at that moment as part of the PBU message (with flag S set to 1).
仅对于那些维护活动多播订阅的MN，pMAG包括活动多播订阅移动选项，该选项携带MN当时的多播上下文作为PBU消息的一部分（标志S设置为1）。
The local mobility anchor stores that information in the corresponding binding cache. If later on the MN attaches to an nMAG, this information is sent (using the same TLV option) to the nMAG as part of the PBA confirmation of the registration process (if the PBU message sent by the nMAG has the flag S set to 1). On the other hand, if no further registration happens, the multicast information is removed together with the rest of binding database for that MN.
本地移动锚将该信息存储在相应的绑定缓存中。如果稍后MN连接到nMAG，则将此信息（使用相同的TLV选项）发送到nMAG，作为注册过程PBA确认的一部分（如果nMAG发送的PBU消息的标志S设置为1）。另一方面，如果没有进一步的注册，多播信息将与该MN的其余绑定数据库一起删除。
After receiving the multicast context, the nMAG can subscribe to the multicast flow(s) on behalf of the MN in case there is no other MN already receiving it at the nMAG. The multicast status can also be set in advance for the point-to-point link towards the MN.
在接收到多播上下文后，如果nMAG上没有其他MN已经接收到多播流，nMAG可以代表MN订阅多播流。也可以预先为指向MN的点到点链路设置多播状态。
Note that the SIAL solution described here does not prevent benefiting from extended support in the mobile node / network that facilitates the proactive mode operation of the solution, e.g., based on L2 capabilities.
注意，这里描述的SIAL解决方案并不妨碍受益于移动节点/网络中的扩展支持，该支持促进了解决方案的主动模式操作，例如，基于L2能力。
Figure 2 summarizes this process.
图2总结了这个过程。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| |==Bi-Dir Tunnel=| |
| Multicast Data | | |
|<---------------| | |
| | | |
1) MN Detached | | |
| MN Detached Event | |
| | | |
| |Ext'd DeReg PBU | |
2) | |--------------->| |
| | | |
3) | | Accept PBU |
| |(Multicast Subscription info stored)
| | | |
| | PBA | |
4) | |<---------------| |
| | | |
5) MN Attached | | |
| | | MN Attached Event
| | | |
| | | PBU |
6) | | |<---------------|
| | | |
| | | Ext'd PBA |
7) | | |--------------->|
| | | |
8) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Multicast Data |
|<-------------------------------------------------|
| | | |
| | | |
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| |==Bi-Dir Tunnel=| |
| Multicast Data | | |
|<---------------| | |
| | | |
1) MN Detached | | |
| MN Detached Event | |
| | | |
| |Ext'd DeReg PBU | |
2) | |--------------->| |
| | | |
3) | | Accept PBU |
| |(Multicast Subscription info stored)
| | | |
| | PBA | |
4) | |<---------------| |
| | | |
5) MN Attached | | |
| | | MN Attached Event
| | | |
| | | PBU |
6) | | |<---------------|
| | | |
| | | Ext'd PBA |
7) | | |--------------->|
| | | |
8) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Multicast Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 2: Proactive Handover
图2：主动切换
The message flow is as follows:
消息流如下所示：
1. A registered MN is receiving a multicast content that has been previously subscribed to by sending a standard MLD report from the mobile node to the currently serving mobile access gateway, pMAG. The pMAG keeps the multicast state of the point-to-point link with the MN.
1. 注册的MN通过从移动节点向当前服务的移动接入网关pMAG发送标准MLD报告来接收先前已订阅的多播内容。pMAG保持与MN的点到点链路的多播状态。
2. The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. As a consequence, pMAG determines a detachment event corresponding to this mobile node, and updates the attachment status of this MN to the local mobility anchor by sending an extended Proxy Binding Update message, including the Active Multicast Subscription, which contains the multicast context of the active multicast subscriptions in the moment of handover.
2. MN通过由新MAG控制的无线电接入发起切换过程（例如，由于更好的无线电条件）。因此，pMAG确定对应于该移动节点的分离事件，并通过发送扩展代理绑定更新消息来更新该MN到本地移动锚的连接状态，包括主动多播订阅，其中包含切换时刻主动多播订阅的多播上下文。
3. The LMA processes the PBU message. Additionally, the LMA stores in the binding cache the information regarding the ongoing multicast subscription(s) when the detachment is initiated. This information is kept until a new registration of the MN is completed by another MAG, or until the binding cache expiration, according to [RFC5213].
3. LMA处理PBU消息。此外，LMA在绑定高速缓存中存储当分离启动时关于正在进行的多播订阅的信息。根据[RFC5213]，在另一个MAG完成MN的新注册之前，或在绑定缓存到期之前，保留此信息。
4. The local mobility anchor acknowledges to the pMAG the previous PBU message.
4. 本地移动锚向pMAG确认先前的PBU消息。
5. As a result of the handover process, the mobile node attaches to another mobility access gateway, called nMAG.
5. 作为切换过程的结果，移动节点连接到另一个称为nMAG的移动接入网关。
6. The nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor.
6. nMAG通过向本地移动锚发送PBU消息（标志S设置为1）来触发注册过程。
7. After the analysis of the PBU message, the LMA sends an extended PBA including the Active Multicast Subscription option, which contains the multicast context of the active subscriptions in the moment of handover.
7. 在分析PBU消息之后，LMA发送包括主动多播订阅选项的扩展PBA，该选项包含切换时刻的主动订阅的多播上下文。
8. The nMAG processes the PBA message following all the standard procedures described in [RFC5213]. Additionally, with the new information relative to multicast subscription, the nMAG sets up the multicast status of the point-to-point link between the nMAG and the MN, and joins the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content due to a previous subscription ordered by another MN attached to it. From that instant, the multicast content is served to the MN.
8. nMAG按照[RFC5213]中描述的所有标准程序处理PBA消息。此外，使用与多播订阅相关的新信息，nMAG设置nMAG和MN之间的点到点链路的多播状态，并加入由（S，G）标识的内容如果nMAG由于另一个附加到其上的MN之前订购的订阅而尚未收到此类内容，则代表MN。从那一刻起，多播内容被提供给MN。
In the reactive case, the LMA receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG.
在反应性情况下，LMA从nMAG接收移动节点注册，而之前没有从pMAG接收MN取消注册。
As the nMAG is not aware of any active multicast subscription of the mobile node, the nMAG starts a conventional registration process, by sending a normal PBU message (with flag S set to 1) towards the local mobility anchor.
由于nMAG不知道移动节点的任何活动多播订阅，因此nMAG通过向本地移动锚发送正常PBU消息（标志S设置为1）来启动常规注册过程。
In the reactive handover case, after MN registration at the nMAG, the local mobility anchor SHOULD generically query the pMAG to retrieve the multicast context of the ongoing multicast subscription of the mobile node. However, the LMA may know in advance if the pMAG supports multicast signaling based on the value of the flag S received during the MN registration in pMAG. Specifically, in case the pMAG does not support multicast signaling (e.g., the S flag value received from pMAG at the time of registering the mobile node was 0), the LMA MAY decide not to query pMAG even in the case of receiving an nMAG indication of supporting multicast signaling.
在反应式切换情况下，在nMAG处进行MN注册之后，本地移动锚应该一般地查询pMAG以检索移动节点的正在进行的多播订阅的多播上下文。然而，LMA可以基于在pMAG中的MN注册期间接收到的标志S的值预先知道pMAG是否支持多播信令。具体地，在pMAG不支持多播信令的情况下（例如，在注册移动节点时从pMAG接收到的S标志值为0），LMA可以决定即使在接收到支持多播信令的nMAG指示的情况下也不查询pMAG。
Once the multicast subscription information is retrieved from the pMAG, the LMA encapsulates it in the PBA message by using the TLV option Active Multicast Subscription and forwards the PBA message to the nMAG. Then, the nMAG can subscribe the multicast flow on behalf of the MN, if there is no other mobile node receiving it already at the nMAG. The multicast status can be also set in advance for the point-to-point link towards the mobile node.
一旦从pMAG检索到多播订阅信息，LMA通过使用TLV选项Active multicast subscription将其封装在PBA消息中，并将PBA消息转发给nMAG。然后，如果在nMAG处没有其他移动节点已经接收到组播流，则nMAG可以代表MN订阅组播流。也可以预先为朝向移动节点的点到点链路设置多播状态。
Figure 3 summarizes this process.
图3总结了这个过程。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| | | MN Attached Event
| | | |
| | | PBU |
1) | | |<---------------|
| | | |
| | Subscr Query | |
2) | |<---------------| |
| | | |
| | Subscr Resp | |
3) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Ext'd PBA |
4) | | |--------------->|
| | | |
5) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | (S,G) Data |
|<-------------------------------------------------|
| | | |
| | | |
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| | | MN Attached Event
| | | |
| | | PBU |
1) | | |<---------------|
| | | |
| | Subscr Query | |
2) | |<---------------| |
| | | |
| | Subscr Resp | |
3) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Ext'd PBA |
4) | | |--------------->|
| | | |
5) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | (S,G) Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 3: Reactive Handover
图3：被动切换
We next take as starting point the situation where an MN is attached to the pMAG, being multicast enabled and maintaining an active multicast subscription at this moment.
接下来，我们将MN连接到pMAG、启用多播并在此时维护活动多播订阅的情况作为起点。
The sequence of messages for the handover of the mobile node is the following (as depicted in Figure 3):
移动节点切换的消息序列如下（如图3所示）：
1. At a certain time, the MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. Then, the nMAG triggers a registration
1. 在特定时间，MN通过由新MAG控制的无线电接入发起切换过程（例如，由于更好的无线电条件）。然后，nMAG触发注册
process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process.
通过向本地移动锚发送PBU消息（标志S设置为1）进行处理。由于这是一种反应性情况，pMAG不知道分离过程。
2. Prior to acknowledging the received PBU message, the LMA queries the pMAG about if there is any active multicast subscription for the MN, by sending a Subscription Query message.
2. 在确认接收到的PBU消息之前，LMA通过发送订阅查询消息，向pMAG查询是否存在针对MN的任何活动多播订阅。
3. The pMAG answers the LMA with a Subscription Response message including the multicast context of the existing subscriptions.
3. pMAG使用订阅响应消息回答LMA，该消息包括现有订阅的多播上下文。
4. After processing the pMAG answer, the LMA acknowledges (with flag S set to 1) the PBU message, including the multicast subscription information within the Active Multicast Subscription option. The nMAG then processes the extended PBA message.
4. 在处理pMAG应答之后，LMA确认（标志S设置为1）PBU消息，包括活动多播订阅选项中的多播订阅信息。然后nMAG处理扩展PBA消息。
5. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up between the nMAG and the local mobility anchor if it has not been established before by another MN connection. At this moment, the multicast content can be served to the MN. The unicast traffic for the mobile node can be forwarded as well.
5. nMAG处理PBA消息，并且它继续设置nMAG和移动节点之间的点到点链路的多播状态，并且在nMAG尚未接收到这样的内容的情况下代表MN加入由（S，G）标识的内容。如果之前未通过另一个MN连接建立双向隧道，则还将在nMAG和本地移动锚之间建立双向隧道。此时，可以向MN提供组播内容。移动节点的单播通信量也可以被转发。
A handover event is managed independently by the pMAG and nMAG. It is not a synchronized process. In a reactive handover, the LMA receives a registration PBU from nMAG before a de-registration PBU is received from pMAG.
移交事件由pMAG和nMAG独立管理。这不是一个同步过程。在反应式切换中，LMA在从pMAG接收取消注册PBU之前从nMAG接收注册PBU。
In the message flows detailed above, it could be the case that the LMA receives a de-registration PBU from pMAG just after sending the Subscription Query message, but before receiving the Subscription Response message. That de-registration PBU message from pMAG carries the multicast subscription information required to assist the MN in the handover, so such valuable information SHOULD be kept by the LMA. Furthermore, it is possible that once the Subscription Query message arrives to pMAG, the pMAG could have already removed the multicast related information for the MN.
在上面详述的消息流中，可能是LMA在发送订阅查询消息之后、但在接收订阅响应消息之前从pMAG接收取消注册PBU的情况。来自pMAG的取消注册PBU消息携带协助MN切换所需的多播订阅信息，因此这些有价值的信息应由LMA保留。此外，一旦订阅查询消息到达pMAG，pMAG可能已经删除了MN的多播相关信息。
In order to avoid losing the multicast subscription information sent in the de-registration PBU message, the local mobility anchor SHOULD store it, and SHOULD include it in the PBA message towards the nMAG in case the Subscription Response message from the pMAG does not contain multicast subscription information for the mobile node.
为了避免丢失在注销PBU消息中发送的多播订阅信息，本地移动锚应将其存储，并且在来自pMAG的订阅响应消息不包含移动节点的多播订阅信息的情况下，应将其包括在朝向nMAG的PBA消息中。
5.3. Prevention of Large Delays of the Binding Acknowledgement for Unicast Traffic
5.3. 单播业务绑定确认大延迟的预防
According to the message sequences described for the reactive handover case, in case the LMA has to request the multicast subscription information from the pMAG, the binding request sent by the nMAG is maintained on-hold until the local mobility anchor receives, processes and includes the multicast subscription information into the extended PBA message. As a consequence, the unicast traffic may then suffer an extra delay motivated by the multicast-related signaling. During that time, the unicast traffic with destination the MN being registered by the nMAG MAY be buffered by the local mobility anchor.
根据针对反应性切换情况描述的消息序列，在LMA必须从pMAG请求多播订阅信息的情况下，nMAG发送的绑定请求被保持，直到本地移动性锚接收到，处理多播订阅信息并将其包含到扩展PBA消息中。结果，单播业务随后可能遭受由多播相关信令激励的额外延迟。在此期间，目的地为nMAG注册的MN的单播业务可由本地移动锚缓冲。
In order to avoid any potential large delay in the forwarding of unicast traffic arriving at the LMA towards the MN, a mechanism SHOULD be implemented to decouple multicast from unicast traffic reception by the MN. Figure 4 shows this mechanism.
为了避免在将到达LMA的单播业务转发到MN时出现任何潜在的大延迟，应该实现一种机制来将多播与MN接收的单播业务分离。图4显示了这种机制。
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
1) | |==Bi-Dir Tunnel=| |
| unicast data | | |
|<-v-v-v-v-v-v-v-| | |
| | | |
| Multicast Data | | |
|<---------------| | |
| | | MN Attached Event
| | | PBU |
2) | | |<---------------|
| | Subscr Query | |
3) | |<---------------| |
| | | |
4) | | <PBA timer starts> |
| | /// |
| | /// |
5) | | <PBA timer expires> |
| | | |
| | | Ext'd PBA |
| | |--------------->|
| | | |
| | | Accept PBA
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Unicast Data |
|<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-|
| | | |
| | | Subscr Query |
6) | | |<---------------|
| | Subscr Resp | |
7) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Subscr Resp |
8) | | |--------------->|
| | | |
| | | Multicast Group join
| | | and P-t-P status setup
| | Multicast Data | |
|<-------------------------------------------------|
| | | |
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
1) | |==Bi-Dir Tunnel=| |
| unicast data | | |
|<-v-v-v-v-v-v-v-| | |
| | | |
| Multicast Data | | |
|<---------------| | |
| | | MN Attached Event
| | | PBU |
2) | | |<---------------|
| | Subscr Query | |
3) | |<---------------| |
| | | |
4) | | <PBA timer starts> |
| | /// |
| | /// |
5) | | <PBA timer expires> |
| | | |
| | | Ext'd PBA |
| | |--------------->|
| | | |
| | | Accept PBA
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Unicast Data |
|<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-|
| | | |
| | | Subscr Query |
6) | | |<---------------|
| | Subscr Resp | |
7) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Subscr Resp |
8) | | |--------------->|
| | | |
| | | Multicast Group join
| | | and P-t-P status setup
| | Multicast Data | |
|<-------------------------------------------------|
| | | |
Figure 4: Decoupling of Unicast and Multicast Signaling
图4：单播和多播信令的解耦
The sequence of messages is the following:
消息的顺序如下所示：
1. An MN is attached to the pMAG. The MN is a multicast-enabled node, and it is receiving both unicast and multicast traffic simultaneously.
1. 将MN连接到pMAG。MN是一个支持多播的节点，它同时接收单播和多播流量。
2. Some time later, The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new mobile access gateway. Then, the nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process.
2. 一段时间之后，MN通过由新的移动接入网关控制的无线电接入发起切换过程（例如，由于更好的无线电条件）。然后，nMAG通过向本地移动锚发送PBU消息（标志S设置为1）来触发注册过程。由于这是一种反应性情况，pMAG不知道分离过程。
3. Prior to acknowledging the received PBU message, the LMA decides to query the pMAG about if there is any active multicast subscription for the mobile node, by sending a Subscription Query message.
3. 在确认接收到的PBU消息之前，LMA决定通过发送订阅查询消息来查询pMAG关于移动节点是否存在任何活动多播订阅。
4. Immediately after sending the Subscription Query message, the LMA starts the timer "PBA timer", which determines the maximum waiting time before the PBA is sent to avoid any potential large delay in the forwarding of unicast traffic towards the MN.
4. 在发送订阅查询消息之后，LMA立即启动计时器“PBA timer”，该计时器确定发送PBA之前的最大等待时间，以避免在向MN转发单播业务时出现任何潜在的大延迟。
5. In case the "PBA timer" expires, the LMA acknowledges the PBU message, by sending the PBA message with flag S=1, without the multicast context information. The nMAG then processes the extended PBA message. Such acknowledgement allows the mobile node to receive the unicast traffic from that time on. The bidirectional tunnel is also set up between the nMAG and the LMA if it has not been established before.
5. 在“PBA定时器”到期的情况下，LMA通过发送带有标志S=1的PBA消息来确认PBU消息，而无需多播上下文信息。然后nMAG处理扩展PBA消息。这种确认允许移动节点从那时起接收单播业务。如果以前未建立双向隧道，则还将在nMAG和LMA之间建立双向隧道。
6. In parallel, the nMAG sends a Subscription Query message to the LMA requesting the multicast-subscription details yet unknown for the mobile node.
6. 并行地，nMAG向LMA发送订阅查询消息，请求移动节点未知的多播订阅细节。
7. The pMAG answers the Subscription Query message originally sent by the local mobility anchor, including the multicast context.
7. pMAG应答最初由本地移动锚发送的订阅查询消息，包括多播上下文。
8. After processing the pMAG answer, the LMA sends a Subscription Response message to the nMAG, including the multicast subscription information within the Active Multicast Subscription option. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up
8. 在处理pMAG应答之后，LMA向nMAG发送订阅响应消息，包括活动多播订阅选项中的多播订阅信息。nMAG处理PBA消息，并且它继续设置nMAG和移动节点之间的点到点链路的多播状态，并且在nMAG尚未接收到这样的内容的情况下代表MN加入由（S，G）标识的内容。还设置了双向隧道
between the nMAG and the LMA if it has not been established before. At this moment, the multicast content can also be served to the mobile node.
在nMAG和LMA之间（如果之前未建立）。此时，组播内容也可以被服务到移动节点。
The "PBA timer" in the LMA determines if the signaling flow follows Figure 3 or Figure 4 in a reactive handover. A value of 0 for the "PBA timer" guarantees that the unicast traffic does not suffer any delay (according to the Figure 4 signaling flow), because the PBA is sent immediately after the LMA receives the PBU from the nMAG. A small non-zero "PBA timer" value MAY be used to reduce the signaling load in the LMA and MAGs (as shown in the signaling flow of Figure 3 if the Subscription Response message from the pMAG is received at the LMA before the "PBA timer" expires), but this has to be carefully balanced against added delay to the unicast traffic.
LMA中的“PBA定时器”确定在反应性切换中信令流是否遵循图3或图4。“PBA定时器”的值为0可确保单播业务不会遭受任何延迟（根据图4信令流），因为PBA是在LMA从nMAG接收PBU后立即发送的。小的非零“PBA定时器”值可用于减少LMA和MAG中的信令负载（如图3的信令流所示，如果在“PBA定时器”到期之前在LMA接收到来自pMAG的订阅响应消息），但这必须小心地与单播业务的附加延迟相平衡。
IPv4-based mobile nodes (being either IPv4/IPv6 dual-stack or IPv4-only enabled) can be supported in a PMIPv6 domain according to [RFC5844]. When referring to multicast membership protocols and procedures, this means that IGMP functionality has to be also supported between the PMIPv6 entities, as documented in [RFC6224], to allow the mobile access gateway requesting multicast contents to the mobility anchor on behalf of the mobile nodes attached to it.
根据[RFC5844]，PMIPv6域中可以支持基于IPv4的移动节点（IPv4/IPv6双栈或仅启用IPv4）。当提及多播成员协议和过程时，这意味着如[RFC6224]中所述，PMIPv6实体之间也必须支持IGMP功能，以允许移动接入网关代表连接到它的移动节点向移动锚请求多播内容。
The Active Multicast Subscription option defined in Section 4.1, which transports the multicast membership context of the mobile node during handover, should be compatible with IGMP-based formats. Specifically, the option format is defined for IPv4-based MNs as follows:
第4.1节中定义的主动多播订阅选项（在切换期间传输移动节点的多播成员上下文）应与基于IGMP的格式兼容。具体而言，基于IPv4的MNs的选项格式定义如下：
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 | IGMP Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | IGMP Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGMPv3 is the primary objective for the definition of the option format. IGMPv1 and IGMPv2 are also considered for backward compatibility. The alignment requirement of this option is 4n+1.
IGMPv3是定义选项格式的主要目标。还考虑了IGMPv1和IGMPv2的向后兼容性。该选项的对齐要求为4n+1。
Type:
类型：
56, which indicates the Active Multicast Subscription IPv4 option.
56，表示活动多播订阅IPv4选项。
Length:
长度：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
IGMP type:
IGMP类型：
Field used to identify the IPv4 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original IGMP specifications for the Report message.
用于标识正在使用的IPv4多播成员身份协议的字段，以及下一个多播成员身份上下文信息字段的相应格式。此字段映射报告消息的原始IGMP规范中使用的类型编码。
0x12: Use of IGMPv1 multicast membership protocol.
0x12:使用IGMPv1多播成员协议。
0x16: Use of IGMPv2 multicast membership protocol.
0x16:使用IGMPv2多播成员协议。
0x22: Use of IGMPv3 multicast membership protocol.
0x22:使用IGMPv3多播成员协议。
Multicast Membership Context:
多播成员身份上下文：
Multicast subscription information corresponding to a single subscribed multicast address. Depending on the IGMP version being used by the mobile node, the format of the Multicast Membership Context could follow the following formats:
与单个订阅的多播地址对应的多播订阅信息。根据移动节点使用的IGMP版本，多播成员身份上下文的格式可以遵循以下格式：
* For IGMPv1, the Group Address format as defined in [RFC1112].
* 对于IGMPv1，[RFC1112]中定义的组地址格式。
* For IGMPv2, the Group Address format as defined in [RFC2236].
* 对于IGMPv2，[RFC2236]中定义的组地址格式。
* For IGMPv3, the Group Record format as defined in [RFC3376].
* 对于IGMPv3，[RFC3376]中定义的组记录格式。
Generic signaling procedures for the support of IPv4 in PMIPv6 domains have been already specified in [RFC5844]. In order to prevent errors while signaling the ongoing multicast subscription for a mobile node during the handover process, the following extensions have to be considered in SIAL.
[RFC5844]中已经规定了在PMIPv6域中支持IPv4的通用信令过程。为了防止在切换过程中向移动节点的正在进行的多播订阅发送信令时出错，在SIAL中必须考虑以下扩展。
o If the registration/de-registration process in a handover is for an IPv6-only MN, and the type of the received Active Multicast Subscription option indicates IPv4, then the multicast membership context received MUST be silently discarded.
o 如果切换中的注册/注销过程仅针对IPv6 MN，并且接收到的活动多播订阅选项的类型指示IPv4，则必须以静默方式放弃接收到的多播成员身份上下文。
o If the registration/de-registration process in a handover is for an IPv4-only MN, and the type of the received Active Multicast Subscription option indicates IPv6, then the multicast membership context received MUST be silently discarded.
o 如果切换中的注册/注销过程仅针对IPv4 MN，并且接收到的活动多播订阅选项的类型指示IPv6，则必须以静默方式放弃接收到的多播成员身份上下文。
o If the registration/de-registration process in a handover is for a dual stack MN, the received Active Multicast Subscription option (or options) MUST be accepted independently of the type indication.
o 如果切换中的注册/注销过程是针对双栈MN的，则必须独立于类型指示接受接收到的活动多播订阅选项（或多个选项）。
Additionally, since the multicast membership information is temporally stored in the mobility anchor under some circumstances (e.g., proactive handover), the binding cache entry for an IPv4-based multicast-enabled MN should be extended for storing the IGMP-based context formats mentioned above, including the IGMP version indicator.
此外，由于在某些情况下（例如，主动切换），多播成员信息临时存储在移动锚中，因此基于IPv4的启用多播的MN的绑定缓存条目应扩展以存储上述基于IGMP的上下文格式，包括IGMP版本指示符。
Throughout this document, the base solution for multicast support in Proxy Mobile IPv6, described in [RFC6224], has been implicitly considered, i.e., both unicast and multicast traffic addressing a mobile node is delivered via the standard PMIPv6 bidirectional tunnel between LMA and MAG. While here all multicast traffic is assumed to be delivered via the local mobility anchor, the SIAL approach described in this document can be also applied to other solutions in which the multicast content is served from other entities in the PMIPv6 domain, as described in [RFC7028] to solve the tunnel convergence problem.
在本文档中，已隐含地考虑了[RFC6224]中描述的代理移动IPv6中多播支持的基本解决方案，即：。，寻址移动节点的单播和多播通信量均通过LMA和MAG之间的标准PMIPv6双向隧道传送。此处，假设所有多播通信量通过本地移动锚传送，本文档中描述的SIAL方法也可应用于其他解决方案，其中多播内容由PMIPv6域中的其他实体提供，如[RFC7028]中所述，以解决隧道收敛问题。
In this case, the transfer of the multicast context would also pass through the local mobility anchor, as described here. However, the nMAG subscribes to the multicast content through the node in charge of distributing multicast according to the adopted solution for multicast distribution in the PMIPv6 domain.
在这种情况下，多播上下文的传输也将通过本地移动锚，如这里所述。然而，nMAG根据PMIPv6域中所采用的多播分发解决方案，通过负责分发多播的节点订阅多播内容。
This proposal does not pose any additional security threats to those already identified in [RFC5213]. All the security considerations in [RFC5213] are directly applicable to this protocol. The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement (extended with the new options defined in this document), the Subscription Query Message, and the Subscription Response Message
本提案不会对[RFC5213]中已经确定的项目构成任何额外的安全威胁。[RFC5213]中的所有安全注意事项直接适用于本协议。信令消息、代理绑定更新和代理绑定确认（使用本文档中定义的新选项进行扩展）、订阅查询消息和订阅响应消息
exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
必须使用端到端安全关联（提供完整性和数据源身份验证）保护移动接入网关和本地移动锚之间的交换。
The mobile access gateway and the local mobility anchor MUST implement the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document. In the following, we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect the new signaling introduced by this specification (Subscription Query Message and Subscription Response Message). We use the same format used by [RFC4877]. The SPD and SAD entries are only example configurations. A particular mobile access gateway implementation and a local mobility anchor home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the signaling messages.
移动接入网关和本地移动锚必须实现代理移动IPv6[RFC5213]强制的IPsec安全机制，以保护本文档中描述的信令。在下文中，我们描述了保护本规范引入的新信令（订阅查询消息和订阅响应消息）所需的安全策略数据库（SPD）和安全关联数据库（SAD）条目。我们使用与[RFC4877]相同的格式。SPD和SAD条目只是示例配置。特定的移动接入网关实现和本地移动锚归属代理实现可以配置不同的SPD和SAD条目，只要它们提供信令消息所需的安全性。
For the examples described in this document, a mobile access gateway with address "mag_address_1", and a local mobility anchor with address "lma_address_1" are assumed.
对于本文档中描述的示例，假设具有地址“mag_address_1”的移动接入网关和具有地址“lma_address_1”的本地移动锚。
mobile access gateway SPD-S: - IF local_address = mag_address_1 & remote_address = lma_address_1 & proto = MH & (remote_mh_type = Subscription Query | local_mh_type = Subscription Response | remote_mh_type = Multicast Activity Indication Ack.| local_mh_type = Multicast Activity Indication) Then use SA1 (OUT) and SA2 (IN)
移动接入网关SPD-S:-如果本地地址=mag地址1和远程地址=lma地址1和协议=MH&（远程类型=订阅查询|本地类型=订阅响应|远程类型=多播活动指示确认|本地类型=多播活动指示），则使用SA1（OUT）和SA2（IN）
mobile access gateway SAD:
- SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
- SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
mobile access gateway SAD:
- SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
- SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
local mobility anchor SPD-S: - IF local_address = lma_address_1 & remote_address =mag_address_1 & proto = MH & (remote_mh_type = Subscription Response | local_mh_type = Subscription Query | remote_mh_type = Multicast Activity Indication | local_mh_type = Multicast Activity Indication Ack.) Then use SA2 (OUT) and SA1 (IN)
本地移动锚SPD-S:-如果本地地址=lma地址=1和远程地址=mag地址=1和协议=MH&（远程类型=订阅响应|本地类型=订阅查询|远程类型=多播活动指示|本地类型=多播活动指示确认），则使用SA2（OUT）和SA1（IN）
local mobility anchor SAD:
- SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
- SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
local mobility anchor SAD:
- SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
- SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
While in the base solution the LMA has learned of the subscribed multicast groups per MAG, in this specification the LMA is aware (during a handover process) of the multicast groups to which an MN visiting the PMIP domain is subscribed.
虽然在基本解决方案中，LMA已经了解到每个MAG订阅的多播组，但是在本规范中，LMA知道（在切换过程中）访问PMIP域的MN订阅的多播组。
This document establishes new assignments to the IANA mobility parameters registry.
本文件为IANA移动参数注册表建立了新的分配。
o Mobility Header types: the Subscription Query (22) and Subscription Response (23) mobility header types. The Type value for these Headers has been assigned from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry defined in <http://www.iana.org/assignments/mobility-parameters>.
o 移动头类型：订阅查询（22）和订阅响应（23）移动头类型。这些头的类型值已从中定义的“移动头类型-移动头中的MH类型”注册表中分配<http://www.iana.org/assignments/mobility-parameters>.
o Mobility options: the Active Multicast Subscription mobility option for both IPv4 (56) and IPv6 (57) modes of operation. The Type value for these Mobility options has been assigned from the "Mobility Options" registry defined in <http://www.iana.org/ assignments/mobility-parameters>.
o 移动选项：IPv4（56）和IPv6（57）操作模式的主动多播订阅移动选项。这些移动选项的类型值已从中定义的“移动选项”注册表中分配<http://www.iana.org/ 分配/移动性参数>。
o Flags: this document reserves a new multicast Signaling flag (S). This flag has been reserved as value 0x0020 in the "Binding Update Flags" registry and value 0x04 in the "Binding Acknowledgment Flags" registry. These registries appear on <http://www.iana.org/ assignments/mobility-parameters>.
o 标志：本文档保留一个新的多播信令标志。此标志在“绑定更新标志”注册表中保留为值0x0020，在“绑定确认标志”注册表中保留为值0x04。这些登记册出现在<http://www.iana.org/ 分配/移动性参数>。
Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von-Hugo@telekom.de) extensively contributed to this document.
Dirk Von Hugo（电信创新实验室，Dirk.Von-Hugo@telekom.de)对本文件作出了广泛贡献。
The authors would like to thank (in alphabetical order) Hitoshi Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt, and Stig Venaas for their valuable comments and discussions on the MULTIMOB mailing list. The authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet Sarikaya, and Stig Venaas for their reviews of this document.
作者要感谢（按字母顺序）Hitoshi Asaeda、Sergio Figueiredo、Georgios Karagiannis、Marco Liebsch、Behcet Sarikaya、Thomas C.Schmidt和Stig Venaas对多人邮件列表的宝贵评论和讨论。作者还感谢Asaeda Hitoshi、Akbar Rahman、Behcet Sarikaya和Stig Venaas对本文件的审查。
The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project), being also partially supported by the Ministry of Science and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 13992-C02-01).
Carlos J.Bernardos的研究导致了这些结果，该研究获得了欧洲共同体第七框架计划（FP7-ICT-2009-5）的资助，资助协议为n。258053（中世纪项目），也得到了西班牙科学和创新部（MICINN）四方项目（TIN2009-13992-C02-01）的部分支持。
The research of Ignacio Soto has also received funding from the Spanish MICINN through the I-MOVING project (TEC2010-18907).
伊格纳西奥·索托的研究也通过I-MOVING项目（TEC2010-18907）获得了西班牙MICINN的资助。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[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月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[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月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，2005年11月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[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月。
[Papagiannaki] Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and C. Diot, "Measurement and Analysis of Single-Hop Delay on an IP Backbone Network", IEEE Journal on Selected Areas in Communications, vol. 21, no. 6, August 2003.
[Papagiannaki]Papagiannaki，K.，Moon，S.，Fraliegh，C.，Thiran，P.，和C.Diot，“IP主干网络上单跳延迟的测量和分析”，IEEE通信选定领域杂志，第21卷，第6期，2003年8月。
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010.
[RFC5949]横田，H.，乔杜里，K.，库德利，R.，帕蒂尔，B.，和夏菲，“代理移动IPv6的快速切换”，RFC 59492010年9月。
[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月。
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012.
[RFC6636]Asaeda，H.，Liu，H.，和Q.Wu，“调整移动和无线网络中路由器的互联网组管理协议（IGMP）和多播侦听器发现（MLD）的行为”，RFC 6636，2012年5月。
[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月。
[Verizon] Verizon, "LTE: The Future of Mobile Broadband Technology", Verizon White Paper, 2010, <http://opennetwork.verizonwireless.com/pdfs/ VZW_LTE_White_Paper_12-10.pdf>.
[Verizon]Verizon，“LTE：移动宽带技术的未来”，Verizon白皮书，2010年<http://opennetwork.verizonwireless.com/pdfs/ VZW\u LTE\u白皮书\u 12-10.pdf>。
[Y.1541] ITU-T, "Network performance objectives for IP-based services", ITU-T Recommendation Y.1541, December 2011.
[Y.1541]ITU-T，“基于IP的服务的网络性能目标”，ITU-T建议Y.1541，2011年12月。
This informative annex briefly analyzes and compares the performance improvement provided by the fast handover extensions specified in this document with the base multicast solution defined in [RFC6224]. The main aim is to determine the potential delay reduction in the acquisition of the multicast subscription information by the nMAG during the MN handover. To do that, the analysis focuses on the delay additional to the unicast handover due to the multicast operation in both cases.
本资料性附录简要分析并比较了本文档中指定的快速切换扩展与[RFC6224]中定义的基本多播解决方案所提供的性能改进。主要目的是确定在MN切换期间nMAG获取多播订阅信息的潜在延迟减少。为了做到这一点，分析的重点是在这两种情况下由于多播操作而导致的单播切换额外的延迟。
Different delay components have to be taken into account for this comparison. Since the interaction between the actors during the handover process (MN, pMAG, nMAG, LMA) is different for each of the solutions, different sources of delay can be expected for each of them.
在进行比较时，必须考虑不同的延迟组件。由于每个解决方案在切换过程中参与者之间的交互（MN、pMAG、nMAG、LMA）是不同的，因此每个解决方案的延迟源是不同的。
The base solution relies on the standard MLD procedures to obtain the multicast subscription information directly from the MN. Once the nMAG completes the configuration of point-to-point link to the attaching MN (the configuration of this link as downstream interface of an MLD proxy instance can run in parallel), it immediately sends an MLD General Query towards the MN for learning of any active multicast subscription by the MN. When the MN receives the MLD Query, the MN provides information about the active memberships it maintains in the form of an MLD Report message. After successful transmission of this information via the wireless point of attachment to nMAG, the corresponding MLD proxy instance at the nMAG sets up the multicast status of the downstream interface. According to this process, the delay is originated on the MAG-MN communication.
基本解决方案依靠标准MLD过程直接从MN获取多播订阅信息。一旦nMAG完成了连接到MN的点到点链路的配置（该链路作为MLD代理实例的下游接口的配置可以并行运行），它立即向MN发送MLD通用查询，以便MN学习任何活动多播订阅。当MN接收到MLD查询时，MN以MLD报告消息的形式提供有关其维护的活动成员身份的信息。在通过nMAG的无线连接点成功传输此信息后，nMAG上相应的MLD代理实例将设置下游接口的多播状态。根据该过程，延迟源于MAG-MN通信。
The delay components to be considered for the base solution are the following:
基本解决方案需要考虑的延迟组件如下：
o D_bh, which is the unidirectional (one-way) delay encountered in the transmission path between the nMAG and the wireless point of attachment.
o D_bh，是在nMAG和无线连接点之间的传输路径中遇到的单向（单向）延迟。
o D_radio, which is the unidirectional delay due to the transfer of MLD control messages over the radio channel (user plane) between the wireless point of attachment and the MN, for the MLD Query and Report messages.
o D_radio，它是由于在无线连接点和MN之间的无线信道（用户平面）上传输MLD控制消息而产生的单向延迟，用于MLD查询和报告消息。
o D_mld, which is the delay incurred by the MN to answer the MLD Query.
o D_mld，它是MN回答mld查询时发生的延迟。
The total observed delay can be then formulated as:
观察到的总延迟可以表示为：
D_base = 2 x (D_bh + D_radio) + D_mld
D_base = 2 x (D_bh + D_radio) + D_mld
As described in this document, it is possible to distinguish two scenarios depending on the order in which the LMA receives the notifications of the MN registration and de-registration in the nMAG and the pMAG, respectively.
如本文件所述，根据LMA分别在nMAG和pMAG中接收MN注册和注销通知的顺序，可以区分两种情况。
In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG. As specified in this document, the LMA stores the multicast subscription information, which is provided to the nMAG during the MN registration process. Since the registration process necessarily happens before the MLD Query and Report process described in the base solution, the proactive case is inherently faster than the base solution. In fact, since the multicast subscription information is acquired properly during the registration process, the delay incurred is null.
在主动式情况下，MN首先由pMAG注销，然后由nMAG注册。如本文所述，LMA存储多播订阅信息，该信息在MN注册过程中提供给nMAG。由于注册过程必然发生在基本解决方案中描述的MLD查询和报告过程之前，因此主动式案例本质上比基本解决方案更快。事实上，由于在注册过程中正确获取了多播订阅信息，因此产生的延迟为空。
In the reactive case, the LMA receives the MN registration from the nMAG without having previously received the MN de-registration from the pMAG. In case the MN maintains an active subscription, the LMA queries the pMAG to retrieve the multicast subscription information, which is forwarded to the nMAG. According to this process, the delay is originated on the MAG-LMA communication.
在反应性情况下，LMA从nMAG接收MN注册，而之前没有从pMAG接收MN取消注册。在MN维持活动订阅的情况下，LMA查询pMAG以检索多播订阅信息，该信息被转发给nMAG。根据该过程，延迟源于MAG-LMA通信。
The delay components to be considered for the base solution are the following:
基本解决方案需要考虑的延迟组件如下：
o D_net, which is the unidirectional delay found in the network path between the LMA and the MAG.
o D_net，它是在LMA和MAG之间的网络路径中发现的单向延迟。
The total observed delay can be then formulated as:
观察到的总延迟可以表示为：
D_sial = 2 x D_net
D_sial = 2 x D_net
The performance of the base solution is highly dependent on the radio technology used by the MN to attach to the PMIPv6 domain. Different radio technologies have distinct properties in terms of radio framing, radio access contention or collision avoidance, channel reliability, etc.
基本解决方案的性能高度依赖于MN用于连接到PMIPv6域的无线电技术。不同的无线电技术在无线电成帧、无线电接入争用或冲突避免、信道可靠性等方面具有不同的特性。
New radio access technologies, such as the one specified in new Long Term Evolution (LTE) standards intend to reduce the latency in order to provide high-speed communications. Even though, typical one-way latencies in the LTE radio access will stay around 15 ms [Verizon].
新的无线电接入技术，例如新的长期演进（LTE）标准中指定的技术，旨在减少延迟以提供高速通信。尽管如此，LTE无线接入中的典型单向延迟将保持在15毫秒左右[Verizon]。
The backhaul delay characterization becomes problematic. In a real network, there are several solutions for the backhaul connection in terms of network topology (ring, star, point-to-point, etc.) and technology (optical fiber, microwave transmission, xDSL-based accesses, etc.), all of them having distinct properties in terms of performance, reliability, and delay. These solutions commonly coexist in a real mobile network, in such a way that an MN changing the point of attachment can pass smoothly from one solution to another. A value of D_bh = 5 ms can be established as the typical value for the backhaul latency in modern networks.
回程延迟特性变得有问题。在实际网络中，回程连接在网络拓扑（环形、星形、点到点等）和技术（光纤、微波传输、基于xDSL的访问等）方面有多种解决方案，所有这些解决方案在性能、可靠性和延迟方面都具有不同的特性。这些解决方案通常共存于实际移动网络中，以这样的方式，MN改变连接点可以顺利地从一个解决方案传递到另一个解决方案。可以将D_bh=5 ms的值确定为现代网络中回程延迟的典型值。
Finally, the MLD induced delay is intrinsic to the MLD protocol specification. A host receiving an MLD Query message waits a random time in the range (0, Maximum Response Delay) to send the MLD Report message. The default value of the Maximum Response Delay (configurable through the Query Response Interval in MLD) is 10 s in [RFC2710] and [RFC3810]. In [RFC6636] the effect of tuning the value of the Query Response Interval is analyzed and 5 s is the smallest value recommended (best case). Then, on average, a potential delay of 5 s or 2.5 s, default and best case respectively, can be expected.
最后，MLD诱导的延迟是MLD协议规范的固有特性。接收MLD查询消息的主机等待范围（0，最大响应延迟）内的随机时间以发送MLD报告消息。[RFC2710]和[RFC3810]中最大响应延迟的默认值（可通过MLD中的查询响应间隔配置）为10秒。在[RFC6636]中，分析了调整查询响应间隔值的效果，5 s是建议的最小值（最佳情况）。然后，平均而言，可以预期5秒或2.5秒的潜在延迟，分别为默认和最佳情况。
As we have seen, D_base is, on average, greater than 2.5 s with the best case of the values of Query Response Interval in MLD that are recommended in [RFC6636]. That means that the handover delay of the base solution is on the order of seconds, while in the solution presented in this specification it is on the order of milliseconds (as shown below). To improve the performance of the base solution, we could further reduce the value of Query Response Interval, but the implications of doing so would need to be carefully analyzed. Even if we assume that Query Response Interval is 0 s, D_base would be around 2 x (5 ms + 15 ms) = 40 ms for last-generation systems. Note that this calculation does not take into account the necessary time to re-establish the data plane after the handover to make possible the MLD Query reception. The expected delay will get much worse for older generation systems (e.g., 3G-based radio systems can suffer radio delays in the order of hundreds of ms).
正如我们所看到的，D_base平均大于2.5 s，最好的情况是[RFC6636]中推荐的查询响应间隔值（以MLD为单位）。这意味着基本解决方案的切换延迟为秒，而在本规范中提供的解决方案中，切换延迟为毫秒（如下所示）。为了提高基本解决方案的性能，我们可以进一步减少查询响应间隔的值，但这样做的含义需要仔细分析。即使我们假设查询响应间隔为0s，对于上一代系统，D_基数也将为2x（5ms+15ms）=40ms。请注意，此计算未考虑在移交后重新建立数据平面以使MLD查询接收成为可能所需的时间。对于老一代系统，预期的延迟将变得更糟（例如，基于3G的无线电系统可能遭受数百毫秒的无线电延迟）。
For the SIAL case, the delay in the MAG-LMA communication will be derived from the network diameter (i.e., the number of hops found between the MAG and the LMA in the PMIPv6 domain). This is largely influenced by the internal network planning. An administrative domain can typically have in the order of five hops from access to the interconnection gateway providing connectivity to other networks.
对于SIAL情况，MAG-LMA通信中的延迟将从网络直径（即，在PMIPv6域中MAG和LMA之间发现的跳数）导出。这在很大程度上受内部网络规划的影响。管理域从访问互连网关到提供到其他网络的连接通常可以有五个跃点。
Even if the LMA plays a central role topologically in the PMIPv6 domain, such number of hops seems reasonable in a common nation-wide network. Each hop in the path between MAG and LMA will add a certain delay, which can be estimated to be around 1 ms in the best case [Papagiannaki] and 3 ms in the worst case [Y.1541]. With this in mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can be expected in the worst case.
即使LMA在PMIPv6域的拓扑结构中起着核心作用，在一个普通的全国性网络中，这样的跳数似乎是合理的。MAG和LMA之间路径中的每一跳都会增加一定的延迟，在最佳情况下[Papagiannaki]估计约为1ms，在最坏情况下[Y.1541]估计约为3ms。考虑到这一点，在最坏的情况下，预计总延迟约为2 x 5 x 3 ms=30 ms。
Then, in conclusion, in a typical deployment, it can be stated that the SIAL proposal, even for the worst-case consideration, will perform better than the best-case situation for the base solution, which consists of the last-generation radio technology, LTE. For any other radio technology, the base solution will show even larger deviations from the delay achievable with the SIAL solution.
然后，总之，在典型部署中，可以指出，对于基本解决方案（包括上一代无线技术LTE），即使考虑到最坏情况，SIAL方案的性能也将优于最佳情况。对于任何其他无线电技术，基本解决方案将显示出与SIAL解决方案可实现的延迟更大的偏差。
Authors' Addresses
作者地址
Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain
Luis M.Contreras Telefonica I+D Ronda de la Comunicion，s/n Sur-3大楼三楼西班牙马德里28050
EMail: lmcm@tid.es
EMail: lmcm@tid.es
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
卡洛斯·J·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
马德里卡洛斯三世伊格纳西奥·索托大学。西班牙马德里勒冈30号大学28911
EMail: isoto@it.uc3m.es
EMail: isoto@it.uc3m.es