Internet Engineering Task Force (IETF) JC. Zuniga
Request for Comments: 7028 InterDigital Communications, LLC
Category: Experimental LM. Contreras
ISSN: 2070-1721 Telefonica I+D
CJ. Bernardos
UC3M
S. Jeon
Instituto de Telecomunicacoes
Y. Kim
Soongsil University
September 2013
Internet Engineering Task Force (IETF) JC. Zuniga
Request for Comments: 7028 InterDigital Communications, LLC
Category: Experimental LM. Contreras
ISSN: 2070-1721 Telefonica I+D
CJ. Bernardos
UC3M
S. Jeon
Instituto de Telecomunicacoes
Y. Kim
Soongsil University
September 2013
Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
代理移动IPv6的组播移动路由优化
Abstract
摘要
This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.
本文档对基本解决方案提出了一些实验性增强，以支持代理移动IPv6（PMIPv6）域中的IP多播。这些增强包括使用多播树移动锚作为多播流量的拓扑锚点，以及移动接入网关可以提供对本地网络中多播内容的访问的直接路由选项。这些增强的目标是提供一些好处，如减少多播通信量复制和支持不同的PMIPv6部署场景。
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/rfc7028.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7028.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. MTMA/Direct Routing Mode Selection .........................5
3.2. Multicast Tree Mobility Anchor (Subscription via MTMA) .....5
3.3. Direct Routing (Subscription via Direct Routing) ...........7
4. Mobile Access Gateway Operation .................................9
4.1. Extensions to Binding Update List Data Structure ...........9
4.2. MAG as MLD Proxy ...........................................9
4.2.1. MTMA Mode (Subscription via MTMA) ...................9
4.2.2. Direct Routing Mode (Subscription via
Direct Routing) ....................................11
5. Local Mobility Anchor Operation ................................14
5.1. Dynamic IP Multicast Selector Option ......................14
5.1.1. Option Application Rules ...........................14
5.1.2. Option Format ......................................14
6. Multicast Tree Mobility Anchor Operation .......................16
6.1. Conceptual Data Structures ................................17
7. Mobile Node Operation ..........................................17
8. IPv4 Support ...................................................17
9. IANA Considerations ............................................18
10. Security Considerations .......................................18
11. Contributors ..................................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
Appendix A. MTMA Deployment Use Cases .............................22
A.1. PMIPv6 Domain with Ratio 1:1 ...............................22
A.2. PMIPv6 Domain with Ratio N:1 ...............................22
A.3. PMIPv6 Domain with Ratio 1:N ...............................24
A.4. PMIPv6 Domain with H-LMA ...................................26
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. MTMA/Direct Routing Mode Selection .........................5
3.2. Multicast Tree Mobility Anchor (Subscription via MTMA) .....5
3.3. Direct Routing (Subscription via Direct Routing) ...........7
4. Mobile Access Gateway Operation .................................9
4.1. Extensions to Binding Update List Data Structure ...........9
4.2. MAG as MLD Proxy ...........................................9
4.2.1. MTMA Mode (Subscription via MTMA) ...................9
4.2.2. Direct Routing Mode (Subscription via
Direct Routing) ....................................11
5. Local Mobility Anchor Operation ................................14
5.1. Dynamic IP Multicast Selector Option ......................14
5.1.1. Option Application Rules ...........................14
5.1.2. Option Format ......................................14
6. Multicast Tree Mobility Anchor Operation .......................16
6.1. Conceptual Data Structures ................................17
7. Mobile Node Operation ..........................................17
8. IPv4 Support ...................................................17
9. IANA Considerations ............................................18
10. Security Considerations .......................................18
11. Contributors ..................................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
Appendix A. MTMA Deployment Use Cases .............................22
A.1. PMIPv6 Domain with Ratio 1:1 ...............................22
A.2. PMIPv6 Domain with Ratio N:1 ...............................22
A.3. PMIPv6 Domain with Ratio 1:N ...............................24
A.4. PMIPv6 Domain with H-LMA ...................................26
Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the network and performs the mobility management on behalf of the Mobile Node (MN). The Local Mobility Anchor (LMA) is the home agent for the MN and the topological anchor point. PMIPv6 was originally designed for unicast traffic. However, a PMIPv6 domain may handle data from both unicast and multicast sources.
代理移动IPv6[RFC5213]是一种基于网络的解决IP移动性问题的方法。在代理移动IPv6（PMIPv6）域中，移动接入网关（MAG）充当网络中的代理移动代理，并代表移动节点（MN）执行移动管理。局部移动锚（LMA）是MN和拓扑锚点的归属代理。PMIPv6最初是为单播通信量设计的。然而，PMIPv6域可以处理来自单播和多播源的数据。
The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by IPv4 hosts to report their IP multicast group memberships to neighboring multicast routers. Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] is used in a similar way by IPv6 routers to discover the presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy specification [RFC4605] allows an intermediate (i.e., edge) node to appear as a multicast router to downstream hosts and as a host to upstream multicast routers. IGMP- and MLD-related protocols however were not originally designed to address the IP mobility of multicast listeners (i.e., IGMP and MLD protocols were originally designed for fixed networks).
IPv4主机使用Internet组管理协议（IGMPv3）[RFC3376]向相邻多播路由器报告其IP多播组成员身份。IPv6路由器以类似的方式使用多播侦听器发现版本2（MLDv2）[RFC3810]来发现IPv6多播主机的存在。此外，IGMP/MLD代理规范[RFC4605]允许中间（即，边缘）节点显示为下游主机的多播路由器和上游多播路由器的主机。然而，与IGMP和MLD相关的协议最初不是为解决多播侦听器的IP移动性而设计的（即，IGMP和MLD协议最初是为固定网络设计的）。
A base solution to support both IPv4 and IPv6 multicast listener mobility in a PMIPv6 domain is specified in [RFC6224], which describes deployment options without modifying mobility and multicast protocol standards. PMIPv6 allows a mobile access gateway to establish multiple PMIPv6 tunnels with different local mobility anchors, e.g., up to one per mobile node. In the presence of multicast traffic, multiple instances of the same traffic can converge to the same MAG. Hence, when IP multicasting is applied into PMIPv6, it may lead to redundant traffic at a MAG. This is the tunnel convergence problem.
[RFC6224]中指定了在PMIPv6域中同时支持IPv4和IPv6多播侦听器移动的基本解决方案，该解决方案描述了在不修改移动和多播协议标准的情况下的部署选项。PMIPv6允许移动接入网关建立具有不同本地移动性锚的多个PMIPv6隧道，例如，每个移动节点最多一个。在存在多播流量的情况下，相同流量的多个实例可以收敛到同一MAG。因此，当IP多播应用到PMIPv6中时，可能会导致MAG上的冗余流量。这就是隧道收敛问题。
In order to address this issue, this document proposes an experimental solution, consisting of two complementary enhancements: multicast anchor and direct routing. The first enhancement makes use of a Multicast Tree Mobility Anchor (MTMA) as the topological anchor point for remotely delivering multicast traffic, while the second enhancement uses direct routing taking advantage of local multicast source availability, allowing a mobile access gateway to connect directly to a multicast router for simple access to local content. Neither of the two schemes has any impact on the mobile node to support IPv4 and IPv6 multicast listener mobility, nor on the wider Internet, as they only affect the PMIPv6 domains where they are deployed. Although references to "MLD proxy" are used in the document, it should be understood to also include "IGMP/MLD proxy" functionality (see Section 8 for details). The status of this
为了解决这个问题，本文提出了一个实验性的解决方案，包括两个互补的增强：多播锚和直接路由。第一个增强使用多播树移动锚（MTMA）作为拓扑锚点远程传送多播流量，而第二个增强使用利用本地多播源可用性的直接路由，允许移动访问网关直接连接到多播路由器，以方便访问本地内容。这两种方案都不会对支持IPv4和IPv6多播侦听器移动性的移动节点产生任何影响，也不会对更广泛的Internet产生任何影响，因为它们只会影响部署它们的PMIPv6域。尽管本文件中使用了“MLD代理”，但应理解为还包括“IGMP/MLD代理”功能（详情见第8节）。这方面的情况
proposal is Experimental. The status of this proposal may be reconsidered in the future, once more implementation feedback and deployment experience is gathered, reporting on the performance of the two proposed schemes as well as operational feedback on scheme selection.
这个建议是试验性的。一旦收集到更多的实施反馈和部署经验，并报告两个拟议方案的绩效以及方案选择方面的运营反馈，未来可能会重新考虑该提案的状态。
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 defined in [RFC5213], [RFC6275], and [RFC3810]. Specifically, the definition of PMIPv6 domain is reused from [RFC5213] and reproduced here for completeness.
本文件使用[RFC5213]、[RFC6275]和[RFC3810]中定义的术语。具体而言，PMIPv6域的定义从[RFC5213]中重复使用，并在此处复制以确保完整性。
Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in [RFC5213]. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending proxy binding updates on behalf of the mobile nodes can be ensured.
代理移动IPv6域（PMIPv6域）：代理移动IPv6域是指使用[RFC5213]中定义的代理移动IPv6协议处理移动节点移动性管理的网络。代理移动IPv6域包括本地移动锚和移动接入网关，在它们之间可以建立安全关联，并且可以确保代表移动节点发送代理绑定更新的授权。
In this document we refine the definition from the point of view of the kind of traffic served to the MN in the following way:
在本文件中，我们从服务于MN的流量类型的角度，通过以下方式对定义进行了细化：
PMIPv6 unicast domain: PMIPv6 unicast domain refers to the network covered by one LMA for unicast service. This service supports mobility as the MN moves from one MAG to another one, both associated with the same LMA regarding the MN unicast traffic.
PMIPv6单播域：PMIPv6单播域是指一个LMA覆盖的网络，用于单播业务。当MN从一个MAG移动到另一个MAG时，该服务支持移动性，两者都与关于MN单播业务的相同LMA相关联。
PMIPv6 multicast domain: PMIPv6 multicast domain refers to the network covered by one network element named MTMA (defined below) for multicast service in such a way that an MN using that service is not aware of mobility as it moves from one MAG to another.
PMIPv6多播域：PMIPv6多播域是指由一个名为MTMA（定义如下）的网络元素覆盖的多播服务的网络，其方式使得使用该服务的MN在从一个MAG移动到另一个MAG时不知道移动性。
From the definitions above, it can be stated that a PMIPv6 domain can have several PMIPv6 unicast domains and PMIPv6 multicast domains. Additionally, some other definitions are introduced, as follows.
根据以上定义，可以说明一个PMIPv6域可以具有多个PMIPv6单播域和PMIPv6多播域。此外，还介绍了一些其他定义，如下所示。
MTMA or multicast tree mobility anchor: An entity working as topological anchor point for multicast traffic. It manages the multicast groups subscribed by all (or a subset of) the MAGs in a PMIPv6 multicast domain, on behalf of the MNs attached to them. Hence, an MTMA performs the functions of either a designated multicast router or an MLD proxy.
MTMA或多播树移动锚点：作为多播流量拓扑锚点的实体。它代表连接到它们的MN管理PMIPv6多播域中所有（或一个子集）MAG订阅的多播组。因此，MTMA执行指定的多播路由器或MLD代理的功能。
H-LMA or Hybrid-LMA: An entity that is dedicated to both unicast and multicast services and able to work as both LMA and MTMA simultaneously.
H-LMA或混合LMA：专用于单播和多播服务且能够同时作为LMA和MTMA工作的实体。
Direct routing: This scheme uses the native multicast infrastructure for retrieving multicast data. For an operator having its own local content, this technique also includes the case where the content source is directly connected to the MAG.
直接路由：该方案使用本机多播基础设施来检索多播数据。对于具有自己的本地内容的运营商，该技术还包括内容源直接连接到MAG的情况。
Subscription via MTMA: Multicast subscription mode in which the content is retrieved from the remote (or home) MTMA.
通过MTMA订阅：从远程（或家庭）MTMA检索内容的多播订阅模式。
Subscription via direct routing: Multicast subscription mode in which the content is retrieved using direct routing from the local domain.
通过直接路由订阅：使用直接路由从本地域检索内容的多播订阅模式。
This specification describes two complementary operational modes that can be used to deliver multicast traffic in a PMIPv6 domain: multicast tree mobility anchor and direct routing. There are different approaches that can be followed to perform this operational mode selection, depending on the operator's preferences and PMIPv6 deployment characteristics. For example, the mode can be manually configured at the mobile access gateway, according to the multicast tree deployment in the PMIPv6 domain, following operator's configuration of the multicast distribution on it. Another option is the use of dynamic policies, conveyed in the PBU (Proxy Binding Update) / PBA (Proxy Binding Acknowledgement) signaling using the Dynamic IP Multicast Selector option described in Section 5.1. Next, each of the two operational modes is introduced.
本规范描述了可用于在PMIPv6域中交付多播流量的两种互补操作模式：多播树移动锚和直接路由。根据操作员的偏好和PMIPv6部署特征，可以采用不同的方法来执行此操作模式选择。例如，可以根据PMIPv6域中的多播树部署，在移动接入网关处手动配置该模式，遵循运营商对其上的多播分发的配置。另一个选项是使用动态策略，使用第5.1节中描述的动态IP多播选择器选项在PBU（代理绑定更新）/PBA（代理绑定确认）信令中传输。接下来，介绍两种操作模式中的每一种。
A multicast tree mobility anchor is used to serve as the mobility anchor for multicast traffic. The MTMA is either a designated multicast router or an MLD proxy. Typically, the MTMA will be used to get access to remote multicast content.
多播树移动锚用作多播流量的移动锚。MTMA是指定的多播路由器或MLD代理。通常，MTMA将用于访问远程多播内容。
The multicast tree mobility anchor connects to the mobile access gateway, as described in [RFC6224], and it can reuse native PMIPv6 features such as tunnel establishment and security [RFC5213], heartbeat [RFC5847], etc. Unicast traffic will go normally to the local mobility anchors in the PMIPv6 domain as described in [RFC5213]. A MAG connecting to the MTMA acts as an MLD proxy.
多播树移动锚连接到移动接入网关，如[RFC6224]中所述，它可以重用本机PMIPv6功能，如隧道建立和安全[RFC5213]、心跳[RFC5847]等。单播通信量将正常进入PMIPv6域中的本地移动锚，如[RFC5213]中所述。连接到MTMA的MAG充当MLD代理。
This section describes how the MTMA works in scenarios of MN attachment and multicast mobility. It concentrates on the case of both LMA and MTMA defining a unique PMIPv6 domain. Some other deployment scenarios are presented in Appendix A.
本节描述了MTMA如何在MN连接和多播移动的场景中工作。它集中于LMA和MTMA定义唯一PMIPv6域的情况。附录A中介绍了一些其他部署场景。
Figure 1 shows an example of a PMIPv6 domain supporting multicast mobility. The local mobility anchor is dedicated to unicast traffic, and the multicast tree mobility anchor is dedicated to multicast traffic. The MTMA can be considered to be a form of upstream multicast router with tunnel interfaces allowing subscription via MTMA for the MNs.
图1显示了支持多播移动性的PMIPv6域的示例。本地移动锚专用于单播业务，而组播树移动锚专用于组播业务。MTMA可以被认为是具有隧道接口的上游多播路由器的一种形式，允许通过MTMA为MNs进行订阅。
As shown in Figure 1, MAG1 may connect to both unicast (LMA) and multicast (MTMA) entities. Thus, a given MN may simultaneously receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 receive unicast traffic, multicast traffic, or both, whereas MN3 receives multicast traffic only.
如图1所示，MAG1可以连接到单播（LMA）和多播（MTMA）实体。因此，给定MN可以同时接收单播和多播业务。在图1中，MN1和MN2接收单播通信量、多播通信量或两者，而MN3仅接收多播通信量。
+--------------+
|Content Source| || - PMIPv6 Tunnel
+--------------+ | - Multicast
| Data Path
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** ** *** *** *** ***
| |
| |
| |
+-----+ +------+
Unicast | LMA | | MTMA | Multicast
Anchor +-----+ +------+ Anchor
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+------+ +------+
| MAG1 | | MAG2 | MLD Proxy
+------+ +------+
| | |
| | |
{MN1} {MN2} {MN3}
+--------------+
|Content Source| || - PMIPv6 Tunnel
+--------------+ | - Multicast
| Data Path
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** ** *** *** *** ***
| |
| |
| |
+-----+ +------+
Unicast | LMA | | MTMA | Multicast
Anchor +-----+ +------+ Anchor
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+------+ +------+
| MAG1 | | MAG2 | MLD Proxy
+------+ +------+
| | |
| | |
{MN1} {MN2} {MN3}
Figure 1: Architecture of Multicast Tree Mobility Anchor (MTMA)
图1：多播树移动锚（MTMA）的体系结构
Direct routing uses a native multicast infrastructure, allowing a mobile access gateway to directly connect to a multicast router (as next hop) in the PMIPv6 domain. A MAG acts as an MLD proxy.
直接路由使用本机多播基础设施，允许移动访问网关直接连接到PMIPv6域中的多播路由器（作为下一跳）。MAG充当MLD代理。
The main purpose of direct routing is to provide optimal connectivity for local content. As a consequence, it replaces the MTMA of the channel management and data delivery of locally available content. Unicast traffic will go as normally to the LMAs in the PMIPv6 domain.
直接路由的主要目的是为本地内容提供最佳连接。因此，它取代了本地可用内容的渠道管理和数据交付的MTMA。单播通信量将正常地发送到PMIPv6域中的LMA。
This section describes how the direct routing works in scenarios of MN attachment and multicast mobility.
本节描述了直接路由在MN连接和多播移动场景中的工作原理。
Multicast Tree
:
: || - PMIPv6 Tunnel
+----------+ +----------+ | - Multicast Data Path
| LMA | | MR |
+----------+ +----------+
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ |
|| /\\ |
|| / \\ |
|| / \\ |
|| / \\ |
|| / \\ |
+--------+ +--------+
| MAG1 | | MAG2 | MLD proxy
+--------+ +--------+
: :
+------+ +------+
| MN1 | -----> | MN1 |
+------+ +------+
Multicast Tree
:
: || - PMIPv6 Tunnel
+----------+ +----------+ | - Multicast Data Path
| LMA | | MR |
+----------+ +----------+
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ |
|| /\\ |
|| / \\ |
|| / \\ |
|| / \\ |
|| / \\ |
+--------+ +--------+
| MAG1 | | MAG2 | MLD proxy
+--------+ +--------+
: :
+------+ +------+
| MN1 | -----> | MN1 |
+------+ +------+
Figure 2: Architecture for Direct-Routing-Based PMIPv6 Multicasting
图2：基于直接路由的PMIPv6多播的体系结构
Figure 2 shows the architecture for the local routing case using native multicasting infrastructure [PMIP6-REQ].
图2显示了使用本机多播基础设施[PMIP6-REQ]的本地路由情况的体系结构。
The local mobility anchor is dedicated to unicast traffic, and the multicast traffic is obtained from an upstream multicast router present in the PMIPv6 domain. Note that there can be multiple LMAs for unicast traffic (not shown in Figure 1 for simplicity) in a given PMIPv6 domain.
本地移动锚专用于单播业务，并且多播业务是从PMIPv6域中存在的上游多播路由器获得的。请注意，在给定的PMIPv6域中，可以有多个用于单播通信的LMA（为简单起见，图1中未显示）。
As shown in Figure 2, a mobile access gateway may connect to both unicast (LMA) and multicast routers (MRs). Thus, a given mobile node may simultaneously receive both unicast and multicast traffic.
如图2所示，移动接入网关可以连接到单播（LMA）和多播路由器（MRs）。因此，给定的移动节点可以同时接收单播和多播业务。
As seen in Figure 2, each MAG has a direct connection (i.e., not using the PMIPv6 tunnel interface) with a multicast router. Depending on the multicast support on the visited network, different schemas can be used to provide this direct connection between the
如图2所示，每个MAG都有一个与多播路由器的直接连接（即，不使用PMIPv6隧道接口）。根据访问网络上的多播支持，可以使用不同的模式来提供访问网络之间的直接连接
MAGs and the multicast router(s), e.g., being connected to the same shared link or using a tunneling approach, such as Generic Routing Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast Tunneling (AMT) [AUTO]. To facilitate IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy function defined in [RFC4605] SHOULD be implemented in the MAG. There SHOULD be direct connectivity between the MAG and the local multicast router (or additional MLD proxy).
MAG和多播路由器，例如，连接到同一共享链路或使用隧道方法，例如通用路由封装（GRE）隧道[RFC2784]或自动多播隧道（AMT）[AUTO]。为了促进IGMP/MLD信令和多播流量转发，应在MAG中实现[RFC4605]中定义的MLD代理功能。MAG和本地多播路由器（或附加MLD代理）之间应具有直接连接。
This section describes the operation of the mobile access gateway, considering that the MAG incorporates MLD proxy functions as per [RFC4605].
本节描述了移动接入网关的操作，考虑到MAG包含了符合[RFC4605]的MLD代理功能。
A Binding Update List (BUL) at the MAG, like the one specified in [RFC5213], MUST be maintained to handle the relationship between the serving entities (e.g., MTMA and LMA) and the mobile nodes for both unicast and multicast traffic.
MAG处的绑定更新列表（BUL），如[RFC5213]中指定的，必须维护以处理服务实体（例如，MTMA和LMA）与单播和多播业务的移动节点之间的关系。
In case of subscription via MTMA, all MAGs that are connected to the MTMA must support the MLD proxy function [RFC4605]. Specifically in Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces define an MLD proxy domain. The mobile nodes are considered to be on the downstream interface of the MLD proxy (of the MAG), and the MTMA is considered to be on the upstream interface (of the MAG) as per [RFC4605]. Note that the mobile access gateway could also be an IGMP proxy.
如果通过MTMA订阅，连接到MTMA的所有MAG必须支持MLD代理功能[RFC4605]。特别是在图1中，MAG1-MTMA和MAG2-MTMA隧道接口中的每一个都定义了一个MLD代理域。根据[RFC4605]，移动节点被认为位于MLD代理（MAG）的下游接口上，MTMA被认为位于（MAG）的上游接口上。请注意，移动接入网关也可以是IGMP代理。
Figure 3 shows the procedure when MN1 attaches to a MAG, and establishes associations with the LMA (unicast) and the MTMA (multicast).
图3显示了MN1连接到MAG并与LMA（单播）和MTMA（多播）建立关联的过程。
MN1 MAG1 LMA MTMA
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU---->| |
| | | |
| |<----PBA--| |
| | | |
| |=Unicast==| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|< ------ Unicast Traffic------->| |
| | | |
| |==Multicast Tunnel===|
| | | |
|<-------MLD Query----| | |
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|----MLD Report (G)-->| | |
| | | |
| |----Aggregated------>|
| | MLD Report (G) |
| | | |
| | | |
|<-----------Multicast Traffic------------->|
| | | |
MN1 MAG1 LMA MTMA
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU---->| |
| | | |
| |<----PBA--| |
| | | |
| |=Unicast==| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|< ------ Unicast Traffic------->| |
| | | |
| |==Multicast Tunnel===|
| | | |
|<-------MLD Query----| | |
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|----MLD Report (G)-->| | |
| | | |
| |----Aggregated------>|
| | MLD Report (G) |
| | | |
| | | |
|<-----------Multicast Traffic------------->|
| | | |
Figure 3: MN Attachment and Multicast Service Establishment for MTMA
图3:MTMA的MN连接和多播服务建立
In Figure 3, the MAG first establishes the PMIPv6 tunnel with LMA for unicast traffic as defined in [RFC5213] after being triggered by the Router Solicitation message from MN1. Unicast traffic will then flow between MN1 and LMA.
在图3中，MAG在被来自MN1的路由器请求消息触发后，首先为[RFC5213]中定义的单播业务建立具有LMA的PMIPv6隧道。然后，单播业务将在MN1和LMA之间流动。
For multicast traffic, a multicast tunnel may have been pre-configured between MAG and MTMA, or may be dynamically established when the first MN appears at the MAG.
对于多播业务，多播隧道可能已经在MAG和MTMA之间预先配置，或者可以在第一MN出现在MAG时动态地建立。
MN1 sends the MLD report message (when required by its upper-layer applications) as defined in [RFC3810] in response to an MLD Query from MAG (generated as defined by [RFC6224] upon handover). The MAG, acting as an MLD proxy defined in [RFC4605], will then send an Aggregated MLD Report to the multicast anchor, MTMA (assuming that this is a new multicast group that the MAG had not previously
MN1发送[RFC3810]中定义的MLD报告消息（当其上层应用程序需要时），以响应MAG的MLD查询（在移交时由[RFC6224]定义生成）。然后，充当[RFC4605]中定义的MLD代理的MAG将向多播锚MTMA发送聚合的MLD报告（假设这是MAG以前没有的新多播组）
subscribed to). Multicast traffic will then flow from the MTMA towards MN1. The MTMA acts as an MLD Querier, so it will periodically query each mobile access gateway about the subscriptions it maintains (not shown in Figure 3).
订阅）。然后，多播流量将从MTMA流向MN1。MTMA充当MLD查询器，因此它将定期向每个移动访问网关查询其维护的订阅（图3中未显示）。
We next consider a mobility scenario in which MN1 with an ongoing multicast subscription moves from one MAG to another MAG. According to the baseline solution signaling method described in [RFC6224], after MN1 mobility, the new mobile access gateway acting in its role of MLD proxy will send an MLD Query to the newly observed mobile node on its downlink. Assuming that the subsequent MLD Report from MN1 requests membership for a new multicast group (from the new MAG's point of view), this will then result in an Aggregated MLD Report being sent to the MTMA from the new mobile access gateway. This message will be sent through a multicast tunnel between the new MAG and MTMA (pre-established or dynamically established).
接下来，我们考虑一个移动性场景，其中MN1与正在进行的组播订阅从一个MAG移动到另一个MAG。根据[RCF6224]中描述的基线解算信令方法，在MN1移动性之后，作为MLD代理的新移动接入网关将在其下行链路上向新观察到的移动节点发送MLD查询。假设来自MN1的后续MLD报告请求新多播组的成员资格（从新MAG的角度来看），这将导致从新移动接入网关向MTMA发送聚合MLD报告。此消息将通过新MAG和MTMA（预先建立或动态建立）之间的多播隧道发送。
When MN1 detaches, the old MAG may keep the multicast tunnel with the multicast MTMA if there are still other MNs using the multicast tunnel. Even if there are no mobile nodes currently on the multicast tunnel, the old MAG may decide to keep the multicast tunnel temporarily for potential future use.
当MN1分离时，如果仍然有其他mn使用多播隧道，则旧MAG可以使用多播MTMA保持多播隧道。即使当前在多播隧道上没有移动节点，旧MAG也可以决定暂时保留多播隧道以备将来可能使用。
As discussed above, existing MLD (and MLD proxy) signaling will handle a large part of the multicast mobility management for the mobile node.
如上所述，现有MLD（和MLD代理）信令将处理移动节点的大部分组播移动性管理。
In this case, the MLD proxy instance is configured to obtain the multicast traffic locally. Figure 4 shows an example of multicast service establishment. The mobile access gateway first establishes the PMIPv6 tunnel with the local mobility anchor for unicast traffic as defined in [RFC5213] after being triggered by the Router Solicitation message from the mobile node. Unicast traffic will then flow between the MN and LMA.
在这种情况下，MLD代理实例被配置为在本地获取多播流量。图4显示了建立多播服务的示例。移动接入网关在被来自移动节点的路由器请求消息触发后，首先为[RFC5213]中定义的单播业务建立具有本地移动性锚的PMIPv6隧道。然后，单播业务将在MN和LMA之间流动。
For multicast traffic, it is assumed that the upstream interface of the MLD proxy instance has been configured pointing to a multicast router internal to the PMIPv6 domain (or towards an additional MLD proxy node in the domain), for all the multicast channels (which, in consequence, have to be local). There should be direct connectivity between the MAG and the local multicast router (or additional MLD proxy).
对于多播业务，假设MLD代理实例的上游接口已被配置为指向PMIPv6域内部的多播路由器（或指向域中的附加MLD代理节点），用于所有多播信道（因此，必须是本地的）。MAG和本地多播路由器（或附加MLD代理）之间应该有直接连接。
MN1 MAG1 LMA MR
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU------->| |
| | | |
| |<-------PBA--| |
| | | |
| |===Unicast===| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|<--------Unicast Traffic---------->| |
| | | |
| | | |
|<-------MLD Query----|<-------------MLD Query----|
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|--MLD Report (G)---->| | |
| | | |
| |----Aggregated------------>|
| | MLD Report (G) |
| | | |
| | | |
|<-------------Multicast Traffic----------------->|
| | | |
MN1 MAG1 LMA MR
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU------->| |
| | | |
| |<-------PBA--| |
| | | |
| |===Unicast===| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|<--------Unicast Traffic---------->| |
| | | |
| | | |
|<-------MLD Query----|<-------------MLD Query----|
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|--MLD Report (G)---->| | |
| | | |
| |----Aggregated------------>|
| | MLD Report (G) |
| | | |
| | | |
|<-------------Multicast Traffic----------------->|
| | | |
Figure 4: Multicast Service Establishment for Direct Routing
图4：直接路由的多播服务建立
Upon detecting node attachment from an incoming interface, the MAG adds each downstream interface to the MLD proxy instance with an upstream link to an MR according to the standard MLD proxy operations [RFC4605] and sends an MLD Query message towards the MN. The mobile node sends the MLD report message (when required by its upper-layer applications) in response to an MLD Query from the MAG. Upon receiving the MLD Report message from each incoming interface, the MAG checks the MLD proxy instance associated with the downstream interface and then the MLD Report messages will be aggregated and forwarded to the upstream link associated with the MR (assuming that this is a new multicast group that the MAG had not previously subscribed to). Multicast traffic will then flow from the local multicast router towards the mobile node.
在检测到来自传入接口的节点连接时，MAG根据标准MLD代理操作[RFC4605]将每个下游接口添加到MLD代理实例，并将上游链路添加到MR，并向MN发送MLD查询消息。移动节点发送MLD报告消息（当其上层应用程序需要时）以响应来自MAG的MLD查询。在从每个传入接口接收MLD报告消息时，MAG检查与下游接口相关联的MLD代理实例，然后MLD报告消息将被聚合并转发到与MR相关联的上游链路（假设这是MAG之前未订阅的新多播组）。然后，多播流量将从本地多播路由器流向移动节点。
MN1 P-MAG N-MAG LMA MR
| | | | |
| | | | |
|<------------|<-- Multicast Data----------------|
| | . | | |
| | . | | |
| | . | | |
Link Handover | | |
Disconnected Detection | | |
| | | | |
| | | | |
| | MN Attachment | |
| | | | |
| | | | |
|----Rtr Sol------------->| | |
| | | | |
| | |--PBU----->| |
| | | | |
| | |<-----PBA--| |
| | | | |
|<-----------MLD Query----| | |
| | | | |
|----MLD Report---------->| | |
| | | | |
| | |----Aggregated------->|
| | | MLD Report |
| | | | |
|<------------------------|<---Multicast Data----|
| | | | |
MN1 P-MAG N-MAG LMA MR
| | | | |
| | | | |
|<------------|<-- Multicast Data----------------|
| | . | | |
| | . | | |
| | . | | |
Link Handover | | |
Disconnected Detection | | |
| | | | |
| | | | |
| | MN Attachment | |
| | | | |
| | | | |
|----Rtr Sol------------->| | |
| | | | |
| | |--PBU----->| |
| | | | |
| | |<-----PBA--| |
| | | | |
|<-----------MLD Query----| | |
| | | | |
|----MLD Report---------->| | |
| | | | |
| | |----Aggregated------->|
| | | MLD Report |
| | | | |
|<------------------------|<---Multicast Data----|
| | | | |
Figure 5: Multicast Mobility Signaling for Direct Routing
图5：用于直接路由的多播移动性信令
Figure 5 shows the handover operation procedure for the direct routing operation mode. When MN1 hands off to the next MAG (N-MAG) from the previous MAG (P-MAG), the N-MAG detects the newly arrived attached mobile node and performs binding update procedure by exchanging PBU/PBA signaling messages with LMA. At the same time, an MLD proxy instance detecting MN1 transmits an MLD query message to the mobile node. After receiving the MLD query message, MN1 sends an MLD report message that includes the multicast group information. The N-MAG then sends an aggregated MLD report message to the upstream link associated with the MR. An upstream interface of MLD proxy instance is chosen towards certain multicast router. The upstream interface selection can be done according to dynamic policies conveyed in the Dynamic IP Multicast Selector option (as described in Section 5.1) or according to manually configured policies. Note that in the base solution defined in [RFC6224], the interface selection is determined for each MN based on the Binding Update List. When the
图5显示了直接路由操作模式的切换操作过程。当MN1从前一个MAG（P-MAG）切换到下一个MAG（N-MAG）时，N-MAG检测新到达的连接移动节点，并通过与LMA交换PBU/PBA信令消息来执行绑定更新过程。同时，检测MN1的MLD代理实例向移动节点发送MLD查询消息。在接收到MLD查询消息之后，MN1发送包括多播组信息的MLD报告消息。然后，N-MAG向与MR相关联的上游链路发送聚合的MLD报告消息。向特定多播路由器选择MLD代理实例的上游接口。可以根据动态IP多播选择器选项（如第5.1节所述）中传输的动态策略或手动配置的策略来选择上游接口。注意，在[RFC6224]中定义的基本解决方案中，根据绑定更新列表为每个MN确定接口选择。当
N-MAG receives the multicast packets from the MR, it then simply forwards them without tunnel encapsulation. The N-MAG updates MN1's location information to the LMA by exchanging PBU/PBA signaling messages.
N-MAG从MR接收多播数据包，然后简单地转发它们，而无需隧道封装。N-MAG通过交换PBU/PBA信令消息将MN1的位置信息更新到LMA。
This section includes a new mobility option to support dynamic policies on subscription via MTMA/direct routing based on the local mobility anchor conveying the required info to the mobile access gateway in the proxy binding acknowledgement message.
本节包括一个新的移动性选项，该选项支持基于本地移动性锚通过MTMA/直接路由进行订阅的动态策略，该本地移动性锚在代理绑定确认消息中将所需信息传送到移动接入网关。
A new TLV-encoded mobility option, the Dynamic IP Multicast Selector option, is defined for use with the proxy binding acknowledgement message exchanged between an LMA and a MAG to convey dynamic policies on subscription via MTMA/direct routing. This option is used for exchanging the IP addresses of both the group subscribed to by the MN, and the source(s) delivering it, as well as the applicable filter mode. This information is carried by using directly the Multicast Address Record format defined in [RFC3810]. There can be multiple "Dynamic IP Multicast Selector" options present in the message, up to one for each active subscription maintained by the MN.
定义了一个新的TLV编码的移动性选项，即动态IP多播选择器选项，用于LMA和MAG之间交换的代理绑定确认消息，以通过MTMA/直接路由传递订阅的动态策略。此选项用于交换MN订阅的组和传递该组的源的IP地址，以及适用的筛选器模式。该信息通过直接使用[RFC3810]中定义的多播地址记录格式来携带。消息中可以有多个“动态IP多播选择器”选项，MN维护的每个活动订阅最多有一个选项。
The format of this new option is as follows:
The format of this new option is as follows:translate error, please retry
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |M| Reserved |Nr of Mcast Address Records (N)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |M| Reserved |Nr of Mcast Address Records (N)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
类型：
54
54
Length:
长度：
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
Protocol:
协议：
Field used to identify the multicast membership protocol in use, and the corresponding format of the next Multicast Address Record. This field maps the type codification used in the original MLD specifications for the Report message, namely for MLDv2 [RFC3810] the Protocol value MUST be 143, whereas for MLDv1 [RFC2710] the Protocol value MUST be 131.
用于标识正在使用的多播成员协议以及下一个多播地址记录的相应格式的字段。此字段映射报告消息的原始MLD规范中使用的类型编码，即对于MLDv2[RFC3810]，协议值必须为143，而对于MLDv1[RFC2710]，协议值必须为131。
Dynamic IP Multicast Selector Mode Flag (M-bit):
动态IP多播选择器模式标志（M位）：
This field indicates the subscription via MTMA/direct routing mode. If the (M) flag value is set to a value of (1), it is an indication that the IP multicast traffic associated with the multicast group(s) identified by the Multicast Address Record(s)
此字段表示通过MTMA/直接路由模式进行的订阅。如果（M）标志值设置为（1）值，则表示与多播地址记录标识的多播组相关联的IP多播流量
in this mobility option SHOULD be routed locally (subscription via direct routing mode). If the (M) flag value is set to a value of (0), it is an indication that IP multicast traffic associated with the multicast group(s) identified by the Multicast Address Record in this mobility option(s) SHOULD be routed to the home network, via the MTMA (subscription via MTMA mode). The mobile access gateway MAY also choose to use static pre-established policies instead of following the indications provided by the local mobility anchor. All other IP traffic associated with the mobile node is managed according to a default policy configured at the PMIPv6 multicast domain.
在这种情况下，移动选项应在本地路由（通过直接路由模式订阅）。如果（M）标志值设置为（0）值，则表示与此移动选项中的多播地址记录标识的多播组相关联的IP多播流量应通过MTMA（通过MTMA模式订阅）路由到家庭网络。移动接入网关还可以选择使用静态预先建立的策略，而不是遵循本地移动锚提供的指示。根据在PMIPv6多播域上配置的默认策略来管理与移动节点相关联的所有其他IP流量。
Reserved:
保留：
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此字段目前未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Nr of Mcast Address Records (N)
Mcast地址记录数量（N）
16-bit unsigned integer indicating the number of Mcast Address Records (N) present in this option.
16位无符号整数，指示此选项中存在的Mcast地址记录数（N）。
Multicast Address Record:
多播地址记录：
Multicast subscription information corresponding to a single multicast address as defined in [RFC3810], or as defined in [RFC2710] for MLDv1.
与[RFC3810]中定义的或[RFC2710]中定义的MLDv1的单个多播地址相对应的多播订阅信息。
The MTMA provides connectivity to the multicast infrastructure out of the PMIPv6 domain. The MTMA itself either could act as an additional MLD proxy (only in the case where all the connected mobile access gateways act also as MLD proxies), reporting to a further node an aggregated view of the subscriptions in a PMIPv6 multicast domain, or can act as a designated multicast router for all the MAGs in a PMIPv6 multicast domain. The multicast tree mobility anchor will then request the multicast content on behalf of the MAGs (and mobile nodes behind them). In addition, the MTMA will create and maintain the corresponding multicast forwarding states per each tunnel interface towards the MAGs. Whatever the role played, when the MAGs act as MLD proxy, the MTMA becomes the MLD querier of the MLD proxy instance located in each MAG.
MTMA提供到PMIPv6域之外的多播基础设施的连接。MTMA本身可以充当附加MLD代理（仅在所有连接的移动接入网关也充当MLD代理的情况下），向另一节点报告PMIPv6多播域中订阅的聚合视图，或者可以充当PMIPv6多播域中所有mag的指定多播路由器。然后，多播树移动锚将代表MAG（以及它们后面的移动节点）请求多播内容。此外，MTMA将为每个通向MAG的隧道接口创建和维护相应的多播转发状态。无论扮演什么角色，当MAG充当MLD代理时，MTMA将成为位于每个MAG中的MLD代理实例的MLD查询器。
The multicast tree mobility anchor does not directly interact with the mobile nodes attached to any of the mobile access gateways. The MTMA only manages the multicast groups subscribed per MAG on behalf of the MNs attached to it. Having this in mind, the relevant information to be stored in the MTMA should be the tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel for multicast between the MTMA and every MAG (e.g., similar to what is stated in [RFC5213] for the unicast case), the IP addresses of the multicast group delivered per tunnel to each of the MAGs, and the IP addresses of the sources injecting the multicast traffic per tunnel to the multicast domain defined by the MTMA.
组播树移动锚不直接与连接到任何移动接入网关的移动节点交互。MTMA仅代表附加到它的MNs管理每个MAG订阅的多播组。考虑到这一点，要存储在MTMA中的相关信息应该是用于MTMA和每个MAG之间的组播的双向隧道的隧道接口标识符（隧道if id）（例如，类似于[RFC5213]中针对单播情况所述的内容），每个隧道传送到每个MAG的多播组的IP地址，以及将每个隧道的多播通信量注入MTMA定义的多播域的源的IP地址。
The mobile node operation is not impacted by the existence of an MTMA as anchor for the multicast traffic being subscribed or the use of direct routing. The MN will act according to the stated operations in [RFC5213] and [RFC6224].
移动节点的操作不受MTMA作为订阅的多播业务的锚的存在或直接路由的使用的影响。MN将根据[RFC5213]和[RFC6224]中规定的操作进行操作。
This document considers that every mobile node requesting multicast-only services is previously registered in a PMIPv6 unicast domain to get a unicast IP address. The registration can also be required for several purposes such as remote management, billing, multicast configuration, etc.
本文档认为，请求仅组播服务的每个移动节点之前都在PMIPv6单播域中注册，以获得单播IP地址。注册还可以用于多种目的，如远程管理、计费、多播配置等。
A given mobile node's policy profile information must be updated to be able to store the IPv6 addresses of both the local mobility anchor and multicast tree mobility anchor, the later for the subscription via MTMA case.
必须更新给定移动节点的策略配置文件信息，以便能够存储本地移动锚和多播树移动锚的IPv6地址，后者用于通过MTMA订阅。
This document does not introduce any IPv4-specific issue regarding [RFC5844]. In order for the solution to support IPv4, all the described network elements (i.e., MAG, MTMA, and MR) must support IGMP. In this case, the functionalities of the MAG and MTMA would be as described in [RFC6224], with the MTMA replicating the requirements described for the LMA. For the case of the MR, it must also be dual-stack (i.e., IPv6/IPv4) enabled.
本文档不介绍与[RFC5844]有关的任何IPv4特定问题。为了使解决方案支持IPv4，所有描述的网络元素（即MAG、MTMA和MR）都必须支持IGMP。在这种情况下，MAG和MTMA的功能如[RFC6224]所述，MTMA复制LMA所述的要求。对于MR，它还必须启用双堆栈（即IPv6/IPv4）。
Although references to "MLD proxy" have been used in the document, it should be understood to also include "IGMP/MLD proxy" functionality.
尽管本文件中使用了“MLD代理”，但应理解为还包括“IGMP/MLD代理”功能。
Regarding the Dynamic IP Multicast Selector Option format, it SHOULD consider IPv4 compatibility in the following way:
关于动态IP多播选择器选项格式，它应该考虑IPv4兼容性：
Protocol field:
协议字段：
For IPv4, this field maps the type codification used in the original IGMP specifications for the Report message, in the following way:
对于IPv4，此字段以以下方式映射报告消息的原始IGMP规范中使用的类型编码：
It MUST be 0x12 in case of using IGMPv1.
如果使用IGMPv1，则必须为0x12。
It MUST be 0x16 in case of using IGMPv2.
如果使用IGMPv2，则必须为0x16。
It MUST be 0x22 in case of using IGMPv3.
如果使用IGMPv3，则必须为0x22。
Multicast Address Record field:
多播地址记录字段：
This field takes different formats depending on the IGMP version being used by the MN, as follows:
根据MN使用的IGMP版本，此字段采用不同的格式，如下所示：
* For IGMPv1, it takes the format given by the Group Address in [RFC1112].
* 对于IGMPv1，它采用[RFC1112]中的组地址给定的格式。
* For IGMPv2, it takes the format given by the Group Address in [RFC2236].
* 对于IGMPv2，它采用[RFC2236]中的组地址给出的格式。
* For IGMPv3, it takes the format given by the Group Record in [RFC3376].
* 对于IGMPv3，它采用[RFC3376]中的组记录给出的格式。
This document defines a new mobility option, the Dynamic IP Multicast Selector, which has been assigned the Type 54 by IANA. The Type value for these options has been assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC6275]: http://www.iana.org/assignments/mobility-parameters.
本文档定义了一个新的移动性选项，即动态IP多播选择器，IANA已将其指定为类型54。根据[RFC6275]中的定义，这些选项的类型值已从分配给其他移动选项的相同编号空间分配：http://www.iana.org/assignments/mobility-parameters.
This document describes two complementary operational modes that can be used to deliver multicast traffic in a PMIPv6 domain: multicast anchor and direct routing. Different approaches are described in the document to decide which operational mode is selected: i) the use of pre-configured/pre-provisioned policies at the mobile access gateway, or ii) the use of dynamic policies. Approach ii) could introduce a potential security issue if the protocol signaling is not properly secured. The use of the Dynamic IP Multicast Selector option described in the document requires message integrity protection and source authentication. Hence, the IPsec security mechanism
本文档描述了两种互补的操作模式，可用于在PMIPv6域中提供多播流量：多播锚和直接路由。文档中描述了不同的方法来决定选择哪种操作模式：i）在移动接入网关处使用预配置/预配置策略，或ii）使用动态策略。方法ii）如果协议信令没有得到适当的保护，可能会引入潜在的安全问题。使用文档中描述的动态IP多播选择器选项需要消息完整性保护和源身份验证。因此，IPsec安全机制
recommended by Proxy Mobile IPv6 [RFC5213] MUST be used to secure the Dynamic IP Multicast Selector option conveyed in the PBA (Proxy Binding Acknowledgement).
必须使用代理移动建议的IPv6[RFC5213]来保护PBA（代理绑定确认）中传输的动态IP多播选择器选项。
This document does not introduce any additional security threats beyond the current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], IGMP [RFC3376], and IGMP/MLD Proxying [RFC4605].
除PMIPv6[RFC5213]、MLD[RFC3810]、IGMP[RFC3376]和IGMP/MLD代理[RFC4605]当前的安全考虑因素外，本文件不引入任何其他安全威胁。
The following individuals made significant contributions to this document.
以下个人对本文件作出了重大贡献。
Akbar Rahman InterDigital Communications, LLC EMail: akbar.rahman@interdigital.com
Akbar Rahman InterDigital Communications，LLC电子邮件：Akbar。rahman@interdigital.com
Ignacio Soto Universidad Carlos III de Madrid EMail: isoto@it.uc3m.es
马德里卡洛斯三世伊格纳西奥·索托大学电子邮件：isoto@it.uc3m.es
[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月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[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月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010.
[RFC5847]Devarapalli，V.，Koodli，R.，Lim，H.，Kant，N.，Krishnan，S.，和J.Laganier，“代理移动IPv6的心跳机制”，RFC 58472010年6月。
[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月。
[AUTO] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, July 2013.
[AUTO]Bumgardner，G.，“自动多播隧道”，正在进行的工作，2013年7月。
[MLDPROXY] Asaeda, H. and S. Jeon, "Multiple Upstream Interface Support for IGMP/MLD Proxy", Work in Progress, February 2013.
[MLDPROXY]Asaeda，H.和S.Jeon，“IGMP/MLD代理的多上游接口支持”，正在进行的工作，2013年2月。
[MUIIMP] Zhang, H. and T. Schmidt, "Multi-Upstream Interfaces IGMP/MLD Proxy", Work in Progress, July 2013.
[MUIIMP]Zhang，H.和T.Schmidt，“多上游接口IGMP/MLD代理”，正在进行的工作，2013年7月。
[MULTIMOB] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Work in Progress, July 2013.
[MULTIMOB]Schmidt，T.，Gao，S.，Zhang，H.，和M.Waehlisch，“代理移动IPv6（PMIPv6）域中的移动多播发送方支持”，正在进行的工作，2013年7月。
[PMIP6-REQ] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
[PMIP6-REQ]Deng，H.，Chen，G.，Schmidt，T.，Seite，P.，和P.Yang，“代理移动IPv6的多播支持要求”，正在进行的工作，2009年7月。
[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月。
[UPSTREAM] Contreras, LM., Bernardos, CJ., and JC. Zuniga, "Extension of the MLD proxy functionality to support multiple upstream interfaces", Work in Progress, February 2013.
[上游]南卡罗来纳州孔特雷拉斯、伯纳德奥斯、CJ.和JC。Zuniga，“扩展MLD代理功能以支持多个上游接口”，正在进行的工作，2013年2月。
This informative appendix describes, from the network architecture point of view, several deployment options considering the MTMA.
本信息性附录从网络体系结构的角度描述了考虑MTMA的几个部署选项。
These options can be distinguished in terms of the number of LMAs and MTMAs present in a PMIPv6 domain and the service relationship that a set of MNs gets from them, in the form of a "LMA : MTMA" ratio. According to that, it is possible to differentiate the following approaches:
这些选项可以根据PMIPv6域中存在的LMA和MTMA的数量以及一组mn以“LMA:MTMA”比率的形式从中获得的服务关系来区分。据此，可以区分以下方法：
o A set of MNs is served in a PMIPv6 domain by two entities, one MTMA for multicast service, and one LMA for unicast, in such a way that the ratio is 1:1 (one common PMIPv6 unicast and multicast domain).
o 一组MN由两个实体在PMIPv6域中提供服务，一个MTMA用于多播服务，一个LMA用于单播，其方式是比率为1:1（一个公共PMIPv6单播和多播域）。
o A set of MNs is served in a PMIPv6 domain by several entities, one MTMA for multicast service, while the others (LMAs) for unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast domains coexist with a unique multicast domain).
o 一组MN在PMIPv6域中由多个实体提供服务，一个MTMA用于多播服务，而其他（LMA）用于单播，其比率为N:1（N个PMIPv6单播域与唯一多播域共存）。
o A set of MNs is served in a PMIPv6 domain by several entities, one LMA for unicast, while the others (MTMAs) are devoted to multicast service, in such a way that the ratio is 1:N (one single PMIPv6 unicast domain coexists with multiple multicast domains).
o 一组MN由多个实体在PMIPv6域中提供服务，其中一个LMA用于单播，而其他（MTMA）用于多播服务，其比率为1:N（一个PMIPv6单播域与多个多播域共存）。
Scenarios with an N:M ratio are considered to be a combination of the previous ones.
具有N:M比率的方案被视为之前方案的组合。
This approach refers to the architecture presented in Figure 1. Within this approach, a common set of MNs is served by a couple of entities, one LMA for unicast and one MTMA for multicast. All the MNs of the set are served by these two elements as they move in the PMIPv6 domain.
这种方法指的是图1所示的体系结构。在这种方法中，一组公共MN由两个实体提供服务，一个LMA用于单播，一个MTMA用于多播。集合中的所有MN在PMIPv6域中移动时由这两个元素提供服务。
This approach refers to the situation where a common set of MNs is served by a unique MTMA for multicast service, but simultaneously there are subsets from that group of MNs that are served by distinct LMAs for unicast service as they move in the PMIPv6 domain. Each particular MN association with the LMAs (unicast) and MTMA (multicast) remains always the same as it moves in the PMIPv6 domain.
此方法指的是这样的情况，即公共MN集合由用于多播服务的唯一MTMA提供服务，但同时该MN组中的子集在PMIPv6域中移动时由用于单播服务的不同LMA提供服务。与lma（单播）和MTMA（多播）的每个特定MN关联在PMIPv6域中移动时始终保持不变。
Figure 6 shows the scenario here described.
图6显示了这里描述的场景。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | MTMA2 | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\oo oo oo oo // ||
|| \\ oo oo oo// ||
|| oo\\ oo oo // ||
|| oo \\ oo oo //oo ||
|| oo \\ oo oo // oo ||
|| oo \\ oo oo // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | MTMA2 | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\oo oo oo oo // ||
|| \\ oo oo oo// ||
|| oo\\ oo oo // ||
|| oo \\ oo oo //oo ||
|| oo \\ oo oo // oo ||
|| oo \\ oo oo // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 6: PMIPv6 Domain with Ratio N:1
图6：比率为N:1的PMIPv6域
Figure 6 proposes an architecture where there are two entities acting as LMAs, LMA1 and LMA3, while there is another one, named MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3 constitute two distinct unicast domains, whereas MTMA2 forms a single multicast domain. The tunnels among MAGs and LMAs represented by lines ("||") indicate a tunnel transporting unicast traffic, while the tunnels among MAGs and MTMA2 depicted with circles ("o") show a tunnel transporting multicast traffic.
图6提出了一种架构，其中有两个实体充当LMA，即LMA1和LMA3，而另一个实体名为MTMA2，充当多播树移动锚。LMA1和LMA3构成两个不同的单播域，而MTMA2形成一个单播域。用线（“| |”）表示的MAG和LMA之间的隧道表示传输单播流量的隧道，而用圆圈（“o”）表示的MAG和MTMA2之间的隧道表示传输多播流量的隧道。
In the figure, it can be observed that all the MNs are served by MTMA2 for the incoming multicast traffic from sources A or B.
在图中，可以观察到，对于来自源A或B的传入多播业务，所有mn都由MTMA2服务。
However, there are different subsets regarding unicast traffic, which maintain distinct associations within the PMIPv6 domain. For instance, the subset formed by MN10, MN11, MN20, and MN21 is served by LMA1 for unicast, and the rest of MNs are served by LMA3. For the scenario described above, the association between each MN and the corresponding LMA and MTMA is permanently maintained.
然而，关于单播通信有不同的子集，它们在PMIPv6域中保持不同的关联。例如，由MN10、MN11、MN20和MN21形成的子集由LMA1提供单播服务，其余的mn由LMA3提供服务。对于上述场景，每个MN与相应的LMA和MTMA之间的关联被永久保持。
This approach is related to a scenario where a common group of MNs is served by a unique LMA for unicast service, but simultaneously there are subsets from that group of MNs that are served by distinct MTMAs for multicast service as they move in the PMIPv6 domain. Different MTMAs might be associated with serving different multicast groups. These associations remain the same even if the MNs move within the PMIPv6 domain.
该方法与这样一种场景相关，即公共MN组由用于单播服务的唯一LMA提供服务，但同时该MN组中的子集在PMIPv6域中移动时由用于多播服务的不同MTMA提供服务。不同的MTMA可能与服务不同的多播组相关联。即使MN在PMIPv6域内移动，这些关联也保持不变。
Figure 7 shows the scenario here described.
图7显示了这里描述的场景。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| ******************** |
( ) * * ( )
( ) * Fixed Internet * ( )
( ) * (Unicast Traffic) * ( )
( ) * * ( )
( ) ******************** ( )
| | |
| | |
+------+ +--------------+ +------+
| MTMA1| | LMA2 | | MTMA3|
+------+ +--------------+ +------+
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo/ ^^ ^^
oo //oo ^^ \\ ^^
oo // oo ^^ \\ ^^
oo // oo \\ ^^
oo // ^^ oo \\ ^^
oo // ^^ oo \^^
+-------------+ +-------------+
| \ / | | \ | |
| ~o~~~~o~ | | ~o~~~~o~ |
| ( MLD w ) | | ( MLD w ) |
| ( multip ) | | ( multip ) |
| ( i/f ) | | ( i/f ) |
| ~~~~~~~~ | | ~~~~~~~~ |
| | | |
| MAG1 | | MAG2 |
/+-------------+ +-------------+\
| | | | | |
| | | | | |
{MN10} {MN11} {MN12} {MN20} {MN21} {MN22}
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| ******************** |
( ) * * ( )
( ) * Fixed Internet * ( )
( ) * (Unicast Traffic) * ( )
( ) * * ( )
( ) ******************** ( )
| | |
| | |
+------+ +--------------+ +------+
| MTMA1| | LMA2 | | MTMA3|
+------+ +--------------+ +------+
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo/ ^^ ^^
oo //oo ^^ \\ ^^
oo // oo ^^ \\ ^^
oo // oo \\ ^^
oo // ^^ oo \\ ^^
oo // ^^ oo \^^
+-------------+ +-------------+
| \ / | | \ | |
| ~o~~~~o~ | | ~o~~~~o~ |
| ( MLD w ) | | ( MLD w ) |
| ( multip ) | | ( multip ) |
| ( i/f ) | | ( i/f ) |
| ~~~~~~~~ | | ~~~~~~~~ |
| | | |
| MAG1 | | MAG2 |
/+-------------+ +-------------+\
| | | | | |
| | | | | |
{MN10} {MN11} {MN12} {MN20} {MN21} {MN22}
Figure 7: PMIPv6 Domain with Ratio 1:N
图7：比率为1:N的PMIPv6域
Figure 7 proposes an architecture where the LMA2 is the unique LMA for a certain group of MNs, while there are two other entities, MTMA1 and MTMA3, acting as MTMAs for different subsets of multicast content. MTMA1 and MTMA3 constitute two distinct multicast domains, whereas LMA2 forms a single unicast domain. Each MTMA could be devoted to carry on a different content (for instance, MTMA1 for source A and MTMA3 for source B). Looking at the figure, all MNs are
图7提出了一种架构，其中LMA2是特定MN组的唯一LMA，而另外两个实体MTMA1和MTMA3充当多播内容不同子集的MTMA。MTMA1和MTMA3构成两个不同的多播域，而LMA2形成单个单播域。每个MTMA可用于承载不同的内容（例如，源a的MTMA1和源B的MTMA3）。从图中可以看出，所有MN都是
served by LMA2 for unicast, while they might be simultaneously served by MTMA1 and MTMA3, depending on the multicast content. For the scenario described above, the association between multicast content and MTMA is permanently maintained. Note that this scenario would require support for MLD proxy with multiple interfaces [MULTIMOB], [UPSTREAM], [MLDPROXY], [MUIIMP] at the MAGs.
由LMA2为单播服务，而它们可能同时由MTMA1和MTMA3服务，具体取决于多播内容。对于上面描述的场景，多播内容和MTMA之间的关联是永久性的。请注意，此场景需要在MAG处支持具有多个接口[MULTIMOB]、[UPSTREAM]、[MLDPROXY]、[MUIIMP]的MLD代理。
The H-LMA is defined as an entity that simultaneously transports unicast and multicast service, that is, it simultaneously works as LMA and MTMA. In the context of the MTMA solution, an H-LMA can play the role of MTMA for an entire group of MNs in a PMIPv6 domain, while acting simultaneously as LMA for a subset of them. Figure 8 adapts the PMIPv6 domain with ratio N:1 scenario of Figure 6 to the case where MTMA2 is an H-LMA, which serves multicast traffic to all the MNs in the picture, and simultaneously, it is able to serve unicast traffic to the subset formed by MN21 and MN30.
H-LMA被定义为同时传输单播和多播服务的实体，即它同时作为LMA和MTMA工作。在MTMA解决方案的上下文中，H-LMA可以对PMIPv6域中的整个MN组发挥MTMA的作用，同时作为其中一个子集的LMA。图8将图6的比率为N:1的PMIPv6域适配为MTMA2是H-LMA的情况，该H-LMA向图片中的所有MN提供组播业务，同时，它能够向MN21和MN30形成的子集提供单播业务。
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | H-LMA | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\oo db db oo // ||
|| \\ db db oo// ||
|| oo\\ db db // ||
|| oo \\ db db //oo ||
|| oo \\ db db // oo ||
|| oo \\ db db // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | H-LMA | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\oo db db oo // ||
|| \\ db db oo// ||
|| oo\\ db db // ||
|| oo \\ db db //oo ||
|| oo \\ db db // oo ||
|| oo \\ db db // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 8: PMIPv6 Domain with H-LMA
图8：含H-LMA的PMIPv6结构域
Figure 8 presents a PMIPv6 network where there are two pure unicast LMAs, LMA1, and LMA3, and a hybrid LMA, labeled as H-LMA in the figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. The tunnels among MAGs and LMAs represented by lines ("||") indicate a tunnel transporting exclusively unicast traffic, the tunnels depicted with circles ("o") show a tunnel transporting exclusively multicast traffic, and the tunnels with mixed lines and circles ("db") describe a tunnel transporting both types of traffic simultaneously.
图8展示了一个PMIPv6网络，其中有两个纯单播LMA，LMA1和LMA3，以及一个混合LMA，在图中标记为H-LMA。从MAG1和MAG4的角度来看，H-LMA是MTMA。直线（“| |”）表示的MAG和LMA之间的隧道表示专门传输单播业务的隧道，圆圈（“o”）表示专门传输多播业务的隧道，混合直线和圆圈（“db”）表示同时传输两种类型业务的隧道。
All of the MNs in the figure receive the multicast traffic from H-LMA (one single multicast domain), but it is possible to distinguish three subsets from the unicast service perspective (that is, three unicast domains). The first subset is the one formed by MN10, MN11, and MN20, which receives unicast traffic from LMA1. A second subset is the one formed by MN21 and MN30, which receives unicast traffic from H-LMA. And finally, a third subset is built on MN31, MN40, and MN41, which receives unicast traffic from LMA3. For the scenario described above, the association between each MN and the corresponding LMA and H-LMA is permanently maintained.
图中的所有MN都从H-LMA（一个多播域）接收多播流量，但是可以从单播服务的角度区分三个子集（即三个单播域）。第一子集是由MN10、MN11和MN20形成的子集，其接收来自LMA1的单播业务。第二子集是由MN21和MN30形成的子集，其接收来自H-LMA的单播业务。最后，在MN31、MN40和MN41上构建第三个子集，其接收来自LMA3的单播业务。对于上述场景，每个MN和对应的LMA和H-LMA之间的关联被永久保持。
Authors' Addresses
作者地址
Juan Carlos Zuniga InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada EMail: JuanCarlos.Zuniga@InterDigital.com URI: http://www.InterDigital.com/
Juan Carlos Zuniga InterDigital Communications，LLC，1000 Sherbrooke Street West，10楼，魁北克蒙特利尔H3A 3G4加拿大电子邮件：JuanCarlos。Zuniga@InterDigital.comURI:http://www.InterDigital.com/
Luis M. Contreras Telefonica I+D Don Ramon de la Cruz, 82-84 Madrid 28006 Spain EMail: lmcm@tid.es
Luis M.Contreras Telefonica I+D Don Ramon de la Cruz，82-84马德里28006西班牙电子邮件：lmcm@tid.es
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
Aveiro 3810-193
Portugal
EMail: seiljeon@av.it.pt
URI: https://atnog.av.it.pt/~sjeon/
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
Aveiro 3810-193
Portugal
EMail: seiljeon@av.it.pt
URI: https://atnog.av.it.pt/~sjeon/
Younghan Kim Soongsil University Sangdo-dong, Dongjak-gu Seoul 511 Republic of Korea EMail: yhkim@dcn.ssu.ac.kr URI: http://dcnlab.ssu.ac.kr/
Younghan Kim Soongsil University Sangdo dong，Dongjak gu首尔511大韩民国电子邮件：yhkim@dcn.ssu.ac.krURI:http://dcnlab.ssu.ac.kr/