Network Working Group G. Bourdon
Request for Comments: 4045 France Telecom
Category: Experimental April 2005
Network Working Group G. Bourdon
Request for Comments: 4045 France Telecom
Category: Experimental April 2005
Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)
支持在第二层隧道协议（L2TP）中高效承载多播流量的扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels.
第二层隧道协议（L2TP）提供了一种隧道PPP数据包的方法。本文档描述了L2TP的扩展，以在部署多播服务（其数据必须通过这些隧道传输）的上下文中有效地利用L2TP隧道。
Table of Contents
目录
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
1.2. Terminology............................................. 3
2. Motivation for a Session-Based Solution....................... 4
3. Control Connection Establishment.............................. 5
3.1. Negotiation Phase....................................... 5
3.2. Multicast Capability AVP (SCCRQ, SCCRP)................. 5
4. L2TP Multicast Session Establishment Decision................. 6
4.1. Multicast States in LNS................................. 6
4.2. Group State Determination............................... 8
4.3. Triggering.............................................. 9
4.4. Multicast Traffic Sent from Group Members............... 10
5. L2TP Multicast Session Opening Process........................ 11
5.1. Multicast-Session-Request (MSRQ)........................ 11
5.2. Multicast-Session-Response (MSRP)....................... 12
5.3. Multicast-Session-Establishment (MSE)................... 12
6. Session Maintenance and Management............................ 13
6.1. Multicast-Session-Information (MSI)..................... 13
6.2. Outgoing Sessions List Updates.......................... 14
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
1.2. Terminology............................................. 3
2. Motivation for a Session-Based Solution....................... 4
3. Control Connection Establishment.............................. 5
3.1. Negotiation Phase....................................... 5
3.2. Multicast Capability AVP (SCCRQ, SCCRP)................. 5
4. L2TP Multicast Session Establishment Decision................. 6
4.1. Multicast States in LNS................................. 6
4.2. Group State Determination............................... 8
4.3. Triggering.............................................. 9
4.4. Multicast Traffic Sent from Group Members............... 10
5. L2TP Multicast Session Opening Process........................ 11
5.1. Multicast-Session-Request (MSRQ)........................ 11
5.2. Multicast-Session-Response (MSRP)....................... 12
5.3. Multicast-Session-Establishment (MSE)................... 12
6. Session Maintenance and Management............................ 13
6.1. Multicast-Session-Information (MSI)..................... 13
6.2. Outgoing Sessions List Updates.......................... 14
6.2.1. New Outgoing Sessions AVP (MSI)................. 15
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI). 15
6.2.3. Withdraw Outgoing Sessions AVP (MSI)............ 17
6.3. Multicast Packets Priority AVP (MSI).................... 17
6.3.1. Global Configuration............................ 18
6.3.2. Individual Configuration........................ 19
6.3.3. Priority........................................ 19
7. Multicast Session Teardown.................................... 19
7.1. Operations.............................................. 20
7.2. Multicast-Session-End-Notify (MSEN)..................... 20
7.3. Result Codes............................................ 21
8. Traffic Merging............................................... 22
9. IANA Considerations........................................... 22
10. Security Considerations....................................... 23
11. References.................................................... 23
11.1. Normative References.................................... 23
11.2. Informative References.................................. 24
12. Acknowledgements.............................................. 24
Appendix A. Examples of Group States Determination............... 25
Author's Address.................................................. 27
Full Copyright Statement.......................................... 28
6.2.1. New Outgoing Sessions AVP (MSI)................. 15
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI). 15
6.2.3. Withdraw Outgoing Sessions AVP (MSI)............ 17
6.3. Multicast Packets Priority AVP (MSI).................... 17
6.3.1. Global Configuration............................ 18
6.3.2. Individual Configuration........................ 19
6.3.3. Priority........................................ 19
7. Multicast Session Teardown.................................... 19
7.1. Operations.............................................. 20
7.2. Multicast-Session-End-Notify (MSEN)..................... 20
7.3. Result Codes............................................ 21
8. Traffic Merging............................................... 22
9. IANA Considerations........................................... 22
10. Security Considerations....................................... 23
11. References.................................................... 23
11.1. Normative References.................................... 23
11.2. Informative References.................................. 24
12. Acknowledgements.............................................. 24
Appendix A. Examples of Group States Determination............... 25
Author's Address.................................................. 27
Full Copyright Statement.......................................... 28
The deployment of IP multicast-based services may have to deal with L2TP tunnel engineering. The forwarding of multicast data within L2TP sessions may impact the throughput of L2TP tunnels because the same traffic may be sent multiple times within the same L2TP tunnel, but in different sessions. This proposal aims to reduce the impact by applying the replication mechanism of multicast traffic only when necessary.
基于IP多播的服务的部署可能需要处理L2TP隧道工程。L2TP会话中多播数据的转发可能会影响L2TP隧道的吞吐量，因为相同的流量可能在同一L2TP隧道中多次发送，但在不同的会话中。该方案旨在通过仅在必要时应用多播流量的复制机制来减少影响。
The solution described herein provides a mechanism for transmitting multicast data only once for all the L2TP sessions that have been established in a tunnel, each multicast flow having a dedicated L2TP session.
本文描述的解决方案提供了一种机制，用于针对已在隧道中建立的所有L2TP会话仅发送一次多播数据，每个多播流具有专用L2TP会话。
Within the context of deploying IP multicast-based services, it is assumed that the routers of the IP network that embed a L2TP Network Server (LNS) capability may be involved in the forwarding of multicast data, toward users who access the network through an L2TP tunnel. The LNS is in charge of replicating the multicast data for each L2TP session that a receiver who has requested a multicast flow uses. In the solution described here, an LNS is able to send multicast data only once and to let the L2TP Access Concentrator (LAC) perform the traffic replication. By doing so, it is expected to spare transmission resources in the core network that supports
在部署基于IP多播的服务的上下文中，假设嵌入L2TP网络服务器（LNS）能力的IP网络的路由器可能参与向通过L2TP隧道访问网络的用户转发多播数据。LNS负责为请求多播流的接收器使用的每个L2TP会话复制多播数据。在这里描述的解决方案中，LNS能够只发送一次多播数据，并让L2TP访问集中器（LAC）执行业务复制。通过这样做，预计将在支持
L2TP tunnels. This multicast extension to L2TP is designed so that it does not affect the behavior of L2TP equipment under normal conditions.
L2TP隧道。L2TP的多播扩展设计为在正常情况下不会影响L2TP设备的行为。
A solution whereby multicast data is carried only once in a L2TP tunnel is of interest to service providers, as edge devices are aggregating more and more users. This is particularly true for operators who are deploying xDSL (Digital Subscriber Line) services and cable infrastructures. Therefore, L2TP tunnels that may be supported by the network will have to carry multiple redundant multicast data more often. The solution described in this document applies to downstream traffic exclusively; i.e., data coming from the LNS toward end-users connected to the LAC. This downstream multicast traffic is not framed by the LNS but by the LAC, thus ensuring compatibility for all users in a common tunnel, whatever the framing scheme.
随着边缘设备聚集越来越多的用户，服务提供商对一种解决方案感兴趣，即在L2TP隧道中只传送一次多播数据。对于正在部署xDSL（数字用户线）服务和有线基础设施的运营商来说尤其如此。因此，网络可能支持的L2TP隧道必须更频繁地承载多个冗余多播数据。本文件中描述的解决方案仅适用于下游交通；i、 例如，从LNS向连接到LAC的最终用户发送的数据。这种下行多播通信量不是由LNS而是由LAC加帧的，因此，无论采用何种加帧方案，都可以确保公共隧道中所有用户的兼容性。
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]中所述进行解释。
Unicast session
单播会话
This term refers to the definition of "Session" as it is described in the terminology section of [RFC2661].
该术语指的是[RFC2661]术语部分所述的“会话”定义。
Multicast session
多播会话
This term refers to a connection between the LAC and the LNS. Additional Control Messages and Attribute-Value-Pairs (AVPs) are defined in this document to open and maintain this connection for the particular purpose of multicast traffic transportation. This connection between the LAC and the LNS is intended to convey multicast traffic only.
该术语指LAC和LNS之间的连接。本文档中定义了其他控制消息和属性值对（AVP），用于打开和维护此连接，以实现多播流量传输的特定目的。LAC和LNS之间的这种连接仅用于传输多播通信量。
Session
一场
This term is used when there is no need to dissociate multicast from unicast sessions, and thus it designates both.
当不需要将多播与单播会话分离时，使用此术语，因此它同时指定这两个会话。
M-IGP
M-IGP
Designates a Multicast Interior Gateway Protocol.
指定多播内部网关协议。
Multicast flow
多播流
Designates datagrams sent to a group from a set of sources for which multicast reception is desired.
指定从一组需要多播接收的源发送到组的数据报。
GMP
GMP
Group Management Protocol, such as:
组管理协议，例如：
- IGMPv1 ([RFC1112]) - IGMPv2 ([RFC2236]) - MLD ([RFC2710], [RFC3590])
- IGMPv1（[RFC1112]）-IGMPv2（[RFC2236]）-MLD（[RFC2710]，[RFC3590]）
SFGMP
SFGMP
Source Filtering Group Management Protocol, such as:
源筛选组管理协议，例如：
- IGMPv3 ([RFC3376]) - MLDv2 ([RFC3810])
- IGMPv3（[RFC3376]）-MLDv2（[RFC3810]）
Multicast data have to be seen as a singular flow that may be conveyed into all the L2TP sessions that have been established in a tunnel. This means that a given L2TP session can be dedicated for the forwarding of a multicast flow that will be forwarded to multiple receivers, including those that can be reached by one or several of these L2TP sessions. A session carrying IP multicast data is independent from the underlying framing scheme and is therefore compatible with any new framing scheme that may be supported by the L2TP protocol.
多播数据必须被视为一个单一的流，可以传输到隧道中建立的所有L2TP会话中。这意味着给定的L2TP会话可以专用于转发将被转发到多个接收器的多播流，包括这些L2TP会话中的一个或多个可以到达的接收器。承载IP多播数据的会话独立于底层成帧方案，因此与L2TP协议支持的任何新成帧方案兼容。
Using a single L2TP session per multicast flow is motivated by the following arguments:
每个多播流使用单个L2TP会话的动机如下：
- The administrator of the LNS is presumably in charge of the IP multicast-based services and the related engineering aspects. As such, he must be capable of filtering multicast traffic on a multicast source basis, on a multicast group basis, and on a user basis (users who access the network using an L2TP session that terminates in this LNS).
- LNS管理员可能负责基于IP多播的服务和相关工程方面。因此，他必须能够基于多播源、基于多播组和基于用户（使用在该LNS中终止的L2TP会话访问网络的用户）过滤多播流量。
- Having an L2TP session dedicated for a multicast flow makes it possible to enforce specific policies for multicast traffic. For instance, it is possible to change the priority treatment for multicast packets against unicast packets.
- 拥有一个专用于多播流的L2TP会话，可以对多播流量实施特定的策略。例如，可以改变多播分组相对于单播分组的优先级处理。
- It is not always acceptable or possible to have multicast forwarding performed within the network between the LAC and the LNS. Having the multicast traffic conveyed within an L2TP tunnel ensures a multicast service between the LNS and end-users, alleviating the need for activating multicast capabilities in the underlying network.
- 在LAC和LN之间的网络内执行多播转发并不总是可接受或可能的。在L2TP隧道内传送多播通信量可确保LNS和最终用户之间的多播服务，从而减轻在底层网络中激活多播功能的需要。
The multicast extension capability is negotiated between the LAC and the LNS during the control connection establishment phase. However, establishment procedures defined in [RFC2661] remain unchanged. An LAC indicates its multicast extension capability by using a new AVP, the "Multicast Capability" AVP. There is no explicit acknowledgement sent by the LNS during the control connection establishment phase. Instead, the LNS is allowed to use multicast extension messages to open and maintain multicast sessions (see Section 5).
在控制连接建立阶段，LAC和LN之间协商多播扩展能力。但是，[RFC2661]中定义的设立程序保持不变。LAC通过使用新的AVP“多播能力”AVP来指示其多播扩展能力。在控制连接建立阶段，LNS没有发送明确的确认。相反，允许LNS使用多播扩展消息来打开和维护多播会话（参见第5节）。
In order to inform the LNS that an LAC has the ability to handle multicast sessions, the LAC sends a Multicast Capability AVP during the control connection establishment phase. This AVP is either sent in a SCCRQ or a SCCRP control message by the LAC towards the LNS.
为了通知LNS LAC具有处理多播会话的能力，LAC在控制连接建立阶段发送多播能力AVP。LAC通过SCCRQ或SCCRP控制消息向LNS发送此AVP。
Upon receipt of the Multicast Capability AVP, a LNS may adopt two distinct behaviors:
在接收到多播能力AVP时，LNS可以采用两种不同的行为：
1) The LNS does not implement the L2TP multicast extension: any multicast-related information (including the Multicast Capability AVP) will be silently ignored by the LNS.
1) LNS不实现L2TP多播扩展：任何多播相关信息（包括多播能力AVP）都将被LNS默默忽略。
2) The LNS implements L2TP multicast extensions and therefore supports the Multicast Capability AVP: the LNS is allowed to send L2TP specific commands for conveying multicast traffic toward the LAC.
2) LNS实现L2TP多播扩展，因此支持AVP多播功能：允许LNS发送L2TP特定命令，用于向LAC传输多播流量。
The multicast capability exclusively refers to the tunnel for which the AVP has been received during the control connection establishment phase. It SHOULD be possible for an LNS administrator to shut down
多播能力专门指在控制连接建立阶段已接收AVP的隧道。LNS管理员应该可以关闭
L2TP multicast extension features towards one or a set of LAC(s). In this case, the LNS behavior is similar to that in 1).
L2TP多播扩展功能针对一个或一组LAC。在这种情况下，LNS行为类似于1）中的行为。
The AVP has the following format:
AVP具有以下格式：
Vendor ID = 0 Attribute = 80 (16 bits)
供应商ID=0属性=80（16位）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The M-bit MUST be set to 0, the AVP MAY be hidden (H-bit set to 0 or 1).
M位必须设置为0，AVP可能被隐藏（H位设置为0或1）。
The length of this AVP is 6 octets.
这个AVP的长度是6个八位字节。
The router that embeds the LNS feature MUST support at least one Group Management Protocol (GMP), such as:
嵌入LNS功能的路由器必须至少支持一个组管理协议（GMP），例如：
- IGMPv1 - IGMPv2 - MLD
- IGMPv1-IGMPv2-MLD
or a Source Filtering Group Management Protocol (SFGMP), such as:
或源筛选组管理协议（SFGMP），例如：
- IGMPv3 - MLDv2
- IGMPv3-MLDv2
The LAC does not have any group management activity: GMP or SFGMP processing is performed by the LNS. The LAC is a layer-2 equipment, and is not supposed to track GMP or SFGMP messages between the receivers and the LNS in this context. The LNS MUST always be at the origin of the creation of a multicast L2TP session dedicated for the forwarding of IP multicast datagrams destined to a multicast group. The LNS acts as a GMP or SFGMP Querier for every logical interface associated to an L2TP session.
LAC没有任何集团管理活动：GMP或SFGMP处理由LNS执行。LAC是第2层设备，在这种情况下，不应跟踪接收器和LN之间的GMP或SFGMP消息。LN必须始终位于创建多播L2TP会话的原点，该会话专用于转发目的地为多播组的IP多播数据报。LNS充当与L2TP会话相关的每个逻辑接口的GMP或SFGMP查询器。
As a multicast router, the equipment that embeds the LNS function will keep state per group per attached network (i.e., per L2TP session). The LNS-capable equipment activating multicast extensions for L2TP will have to classify and analyze GMP and SFGMP states in order to create L2TP multicast sessions within the appropriate L2TP tunnels. This is performed in three steps:
作为多播路由器，嵌入LNS功能的设备将保持每个连接网络（即每个L2TP会话）的每个组的状态。能够激活L2TP多播扩展的LNS设备必须对GMP和SFGMP状态进行分类和分析，以便在适当的L2TP隧道内创建L2TP多播会话。这将分三个步骤执行：
1) The LNS has to compute group states for each L2TP tunnel, by using group states recorded for each L2TP session of the tunnel. Group state determination for L2TP tunnels is discussed in Section 4.2. For each L2TP tunnel, the result of this computation will issue a list of states of the form (group, filter-mode, source-list):
1) LNS必须使用为隧道的每个L2TP会话记录的组状态来计算每个L2TP隧道的组状态。第4.2节讨论了L2TP隧道的群状态确定。对于每个L2TP隧道，此计算的结果将发布以下形式的状态列表（组、过滤器模式、源列表）：
- group: Denotes the multicast group. - filter-mode: Either INCLUDE or EXCLUDE, as defined in [RFC3376]. - source-list: List of IP unicast addresses from which multicast reception is desired or not, depending on the filter-mode.
- 组：表示多播组。-过滤模式：包括或排除，如[RFC3376]中所定义源列表：IP单播地址列表，根据过滤模式，需要或不需要从中接收多播。
2) According to each group state, the LNS will create one or multiple replication contexts, depending on the filter-mode for the considered group and the local policy configured in the LNS.
2) 根据每个组状态，LNS将创建一个或多个复制上下文，具体取决于所考虑组的筛选模式和LNS中配置的本地策略。
For groups in INCLUDE mode, the LNS SHOULD implement two different policies:
对于包含模式下的组，LN应实施两种不同的策略：
- One session per (source, group) pair: the LNS creates one replication context per (source, group) pair. or - One session per group: the LNS creates one replication context per (source-list, group) pair.
- 每个（源、组）对一个会话：LNS为每个（源、组）对创建一个复制上下文。或-每个组一个会话：LNS为每个（源列表，组）对创建一个复制上下文。
For groups in EXCLUDE mode, the LNS will create one replication context per (list of sources excluded by *all* the receivers, group). The list of sources represents the intersection of the sets, not the union.
对于处于排除模式的组，LNS将为每个组创建一个复制上下文（由*所有*接收器排除的源列表，组）。源列表表示集合的交集，而不是并集。
3) For each replication context, the LNS will create one L2TP multicast session (if threshold conditions are met; see Section 4.3) and its associated Outgoing Session List (OSL). The OSL lists L2TP sessions that requested the multicast flow corresponding to the group and the associated source-filtering properties. There is one OSL per replication context; i.e., per L2TP multicast session.
3) 对于每个复制上下文，LNS将创建一个L2TP多播会话（如果满足阈值条件；请参阅第4.3节）及其关联的传出会话列表（OSL）。OSL列出了L2TP会话，该会话请求与组和相关源筛选属性相对应的多播流。每个复制上下文有一个OSL；i、 例如，每个L2TP多播会话。
For a group member running an SFGMP, it is therefore possible to receive multicast traffic from sources that have been explicitly excluded in its SFGMP membership report if other group members in the
因此，对于运行SFGMP的组成员，如果该组中的其他组成员
same L2TP tunnel wish to receive packets from these sources. This behavior is comparable to the case where group members are connected to the same multi-access network. When a group is in EXCLUDE mode or in INCLUDE mode with a policy allowing one session per (group, source-list), sharing the same L2TP tunnel is equivalent to being connected to the same multi-access network in terms of multicast traffic received. For groups in INCLUDE mode with a policy allowing one L2TP multicast session per (source, group), the behavior is slightly improved because it prevents group members from receiving traffic from non-requested sources. On the other hand, this policy potentially increases the number of L2TP multicast sessions to establish and maintain. Examples are provided in Appendix A.
相同的L2TP隧道希望从这些源接收数据包。此行为类似于组成员连接到同一多址网络的情况。当一个组处于排除模式或包含模式且策略允许每个（组、源列表）一个会话时，共享相同的L2TP隧道就相当于在接收的多播流量方面连接到相同的多址网络。对于策略允许每个（源、组）有一个L2TP多播会话的处于包含模式的组，该行为稍有改进，因为它阻止组成员从非请求的源接收流量。另一方面，此策略可能会增加要建立和维护的L2TP多播会话的数量。附录A中提供了示例。
In order for the LAC to forward the multicast traffic received through the L2TP multicast session to group members, the LNS sends the OSL to the LAC for the related multicast session (see Section 6).
为了使LAC将通过L2TP多播会话接收到的多播通信转发给组成员，LNS将OSL发送给LAC以用于相关多播会话（参见第6节）。
Source Filtering Group Management Protocols require querier routers to keep a filter-mode per group per attached network, to condense the total desired reception state of a group to a minimum set so that all systems' memberships are satisfied.
源过滤组管理协议要求查询路由器在每个连接的网络中保持每个组的过滤模式，将组的总期望接收状态压缩到最小集，以便满足所有系统的成员资格。
Within the context of L2TP, each L2TP session has to be considered an attached network by GMP and SFGMP protocols. When the L2TP multicast extension is activated, each L2TP Control Connection has to be considered a pseudo attached network, as well, in order to condense group membership reports for every L2TP session in the tunnel.
在L2TP的上下文中，每个L2TP会话必须被GMP和SFGMP协议视为连接的网络。当L2TP多播扩展被激活时，每个L2TP控制连接也必须被视为伪连接网络，以便压缩隧道中每个L2TP会话的组成员报告。
Therefore, a list of group states is maintained for each L2TP Control Connection into which the membership information of each of its L2TP sessions is merged. This list of group states is a set of membership records of the form (group, filter-mode, source-list).
因此，为每个L2TP控制连接维护组状态列表，其中每个L2TP会话的成员信息被合并到其中。此组状态列表是表单（组、筛选模式、源列表）的一组成员记录。
Each group state represents the result of a merging process applied to subscriptions on L2TP sessions of a Control Connection for a considered group. This merging process is performed in three steps:
每个组状态表示应用于所考虑组的控制连接的L2TP会话上的订阅的合并过程的结果。此合并过程分三个步骤执行：
1) Conversion of any GMP subscription into SFGMP subscription (IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2);
1) 将任何GMP订阅转换为SFGMP订阅（IGMPv1/v2转换为IGMPv3，MLDv1转换为MLDv2）；
2) Removal of subscription timers and, if filter-mode is EXCLUDE, sources with source timer > 0;
2) 删除订阅计时器，如果过滤模式为排除，则删除源计时器>0的源；
3) Then, resulting subscriptions are merged by using merging rules described in SFGMP specifications ([RFC3376], Section 3.2, [RFC3810], Section 4.2).
3) 然后，通过使用SFGMP规范（[RFC3376]，第3.2节，[RFC3810]，第4.2节）中描述的合并规则合并生成的订阅。
This process is also described in [PROXY]. Examples of group state determination are provided in Appendix A.
[PROXY]中也描述了此过程。附录A中提供了群状态确定的示例。
The rules to be enforced by the LNS whereby it is decided when to open a dedicated L2TP multicast session for a multicast group SHOULD be configurable by the LNS administrator. This would typically happen whenever a threshold of MULTICAST_SESSION_THRESHOLD receivers/sessions referenced in a replication context is reached. This threshold value SHOULD be valued at 2 by default, as it is worth opening a dedicated L2TP multicast session for two group members sharing the same desired reception state (which means that two L2TP unicast sessions are concerned). In this case, the OSL will reference two distinct L2TP sessions.
LNS管理员应配置LNS强制执行的规则，根据这些规则，LNS决定何时为多播组打开专用L2TP多播会话。这通常会在达到复制上下文中引用的多播会话接收器/会话阈值时发生。默认情况下，该阈值应为2，因为值得为共享相同期望接收状态的两个组成员打开专用L2TP多播会话（这意味着涉及两个L2TP单播会话）。在这种情况下，OSL将引用两个不同的L2TP会话。
The actual receipt by the LNS of multicast traffic requested by end-users can also be taken into account to decide whether the associated L2TP multicast session has to be opened.
LNS对最终用户请求的多播通信量的实际接收也可以考虑，以决定是否必须打开相关的L2TP多播会话。
Whenever an OSL gets empty, the LNS MUST stop sending multicast traffic over the corresponding L2TP multicast session. Then the L2TP multicast session MUST be torn down as described in Section 7.
每当OSL变空时，LNS必须停止通过相应的L2TP多播会话发送多播流量。然后，L2TP多播会话必须按照第7节中的描述被中断。
Filter-mode changes for a group can also trigger the opening or the termination of L2TP multicast sessions in the following ways:
组的筛选器模式更改还可以通过以下方式触发L2TP多播会话的打开或终止：
a) From INCLUDE Mode to EXCLUDE Mode
a) 从包含模式到排除模式
When a group state filter-mode switches from INCLUDE to EXCLUDE, only one replication context (and its associated L2TP multicast session) issued from this group state can exist (see Section 4.1). The LNS SHOULD keep one replication context previously created for this group state and it has to update it with:
当组状态筛选器模式从包含切换到排除时，从该组状态发出的复制上下文（及其关联的L2TP多播会话）只能存在（请参阅第4.1节）。LNS应保留以前为此组状态创建的一个复制上下文，并且必须使用以下内容进行更新：
- a new source-list that has to be excluded from forwarding - a new OSL
- 必须从转发中排除的新源列表-新OSL
The LNS MUST send an OSL update to the LAC to reflect L2TP session list changes (section 6.2), whenever appropriate. The unused L2TP multicast sessions that correspond to previously created replication contexts for the group SHOULD be terminated, either actively or passively by emptying their corresponding OSLs.
必要时，LNS必须向LAC发送OSL更新，以反映L2TP会话列表的变化（第6.2节）。应通过清空相应的OSL，主动或被动地终止与先前为组创建的复制上下文相对应的未使用L2TP多播会话。
The remaining L2TP multicast session MAY also be terminated if the number of receivers is below a predefined threshold (see Section 7). To limit the duration of temporary packet loss or duplicates to receivers, the LNS has to minimize delay between OSL updates messages
如果接收器的数量低于预定义的阈值，则剩余的L2TP多播会话也可以终止（参见第7节）。为了限制接收器的临时数据包丢失或重复的持续时间，LNS必须最小化OSL更新消息之间的延迟
sent to the LAC. Therefore, one can assume that terminating a multicast session passively gives the smoothest transition.
送到拉丁美洲和加勒比海。因此，可以假设被动地终止多播会话可以提供最平滑的过渡。
b) From EXCLUDE Mode to INCLUDE Mode
b) 从排除模式到包括模式
When a group state filter-mode switches from EXCLUDE to INCLUDE, multiple replication contexts issued by this group state may be created (see Section 4.1). The LNS SHOULD keep the replication context previously created for this group state and it has to update it accordingly with the following information:
当组状态筛选器模式从“排除”切换到“包括”时，可能会创建由该组状态发出的多个复制上下文（请参阅第4.1节）。LNS应保留先前为此组状态创建的复制上下文，并且必须使用以下信息对其进行相应更新：
- a new list of sources that has to be forwarded. This list has only one record if there is one replication context per (group, source) - a new OSL
- 必须转发的源的新列表。如果每个（组、源）有一个复制上下文（一个新的OSL），则此列表只有一条记录
The LNS MUST send an OSL update to the LAC to reflect L2TP session list changes, whenever appropriate. If the LNS is configured to create one replication context per (group, source), L2TP multicast sessions will be opened in addition to the existing one, depending on the number of sources for the group.
必要时，LNS必须向LAC发送OSL更新，以反映L2TP会话列表的更改。如果LNS配置为每个（组、源）创建一个复制上下文，则L2TP多播会话将在现有会话的基础上打开，具体取决于组的源数量。
If new L2TP multicast sessions have to be opened, the LNS SHOULD wait until these multicast sessions are established before updating the OSL of the original multicast session. To limit the duration of temporary packet loss or duplicates to receivers, the LNS has to minimize delay between OSL updates messages sent to the LAC.
如果必须打开新的L2TP多播会话，LNS应等到这些多播会话建立后，再更新原始多播会话的OSL。为了限制接收器的临时数据包丢失或重复的持续时间，LNS必须最小化发送到LAC的OSL更新消息之间的延迟。
The present document proposes a solution to enhance the forwarding of downstream multicast traffic exclusively; i.e., data coming from the LNS toward end-users connected to the LAC. If a group member that uses an L2TP session is also a multicast source for traffic conveyed in a multicast session, datagrams may be sent back to the source. To prevent this behavior, two options can be used in the LNS:
本文档提出了一种解决方案，以增强下游多播业务的独家转发；i、 例如，从LNS向连接到LAC的最终用户发送的数据。如果使用L2TP会话的组成员也是多播会话中传输的流量的多播源，则数据报可以发送回该源。为了防止这种行为，LNS中可以使用两个选项：
1) Disable the multicast packets' forwarding capability, for those multicast datagrams sent by users connected to the network by means of an L2TP tunnel. Protocols using well-known multicast addresses MUST NOT be impacted.
1) 对于通过L2TP隧道连接到网络的用户发送的多播数据报，禁用多播数据包的转发能力。不得影响使用已知多播地址的协议。
2) Exclude from the OSL the L2TP session used by a group member that sends packets matching the replication context of this OSL. Therefore, the corresponding multicast flow is sent by the LNS over the user L2TP unicast session, using standard multicast forwarding rules.
2) 从OSL中排除发送与此OSL的复制上下文匹配的数据包的组成员使用的L2TP会话。因此，LNS使用标准多播转发规则通过用户L2TP单播会话发送相应的多播流。
The opening of an L2TP multicast session is initiated by the LNS. A three-message exchange is used to set up the session. The following is a typical sequence of events:
L2TP多播会话的打开由LNS启动。三个消息交换用于设置会话。以下是一系列典型的事件：
LAC LNS
--- ---
(multicast session
triggering)
LAC LNS
--- ---
(multicast session
triggering)
<- MSRQ MSRP ->
<-MSRQ MSRP->
(Ready to replicate)
（准备复制）
MSE -> <- ZLB ACK
MSE-><-ZLB确认
The ZLB ACK is sent if there are no further messages waiting in the queue for that peer.
如果队列中没有其他消息等待该对等方，则发送ZLB ACK。
Multicast-Session-Request (MSRQ) is a control message sent by the LNS to the LAC to indicate that a multicast session can be created. The LNS initiates this message according to the rules in Section 4.3. It is the first in a three-message exchange used for establishing a multicast session within an L2TP tunnel.
多播会话请求（MSRQ）是LN发送到LAC的控制消息，用于指示可以创建多播会话。LNS根据第4.3节中的规则发起此消息。它是用于在L2TP隧道内建立多播会话的三条消息交换中的第一条。
A LNS MUST NOT send a MSRQ control message if the remote LAC did not open the L2TP tunnel with the Multicast Capability AVP. The LAC MUST ignore MSRQ control messages sent in an L2TP tunnel, if the L2TP tunnel was not opened with control messages including a Multicast Capability AVP.
如果远程LAC未使用多播功能AVP打开L2TP隧道，则LNS不得发送MSRQ控制消息。如果L2TP隧道未使用包含多播功能AVP的控制消息打开，LAC必须忽略L2TP隧道中发送的MSRQ控制消息。
The following AVPs MUST be present in MSRQ:
MSRQ中必须存在以下AVP：
Message Type Assigned Session ID
消息类型分配的会话ID
The following AVPs MAY be present in MSRQ:
MSRQ中可能存在以下AVP：
Random Vector Maximum BPS
随机向量最大BPS
The Maximum BPS value is set by the LNS administrator. However, this value should be chosen in accordance with the line capabilities of the end-users. The Maximum BPS value SHOULD NOT be higher than the highest speed connection for all end-users within the L2TP tunnel.
最大BPS值由LNS管理员设置。但是，应根据最终用户的线路能力选择该值。最大BPS值不应高于L2TP隧道内所有终端用户的最高速度连接。
The associated Message Type AVP is encoded with the following values:
关联的消息类型AVP使用以下值进行编码：
Vendor ID = 0 Attribute Type = 0 Attribute Value = 23 (16 bits)
供应商ID=0属性类型=0属性值=23（16位）
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M位必须设置为0，H位必须设置为0。
Multicast-Session-Response (MSRP) is a control message sent by the LAC to the LNS in response to a received MSRQ message. It is the second in a three-message exchange used for establishing a multicast session within an L2TP tunnel.
多播会话响应（MSRP）是LAC向LNS发送的控制消息，以响应接收到的MSRQ消息。它是用于在L2TP隧道内建立多播会话的三条消息交换中的第二条。
MSRP is used to indicate that the MSRQ was successful and that the LAC will attempt to reserve appropriate resources to perform multicast replication for unicast sessions managed in the pertaining control connection.
MSRP用于指示MSRQ成功，LAC将尝试保留适当的资源，以便为相关控制连接中管理的单播会话执行多播复制。
The following AVPs MUST be present in MSRP:
MSRP中必须存在以下AVP：
Message Type Assigned Session ID
消息类型分配的会话ID
The following AVP MAY be present in MSRP:
MSRP中可能存在以下AVP：
Random Vector
随机向量
The associated Message Type AVP is encoded with the following values:
关联的消息类型AVP使用以下值进行编码：
Vendor ID = 0 Attribute Type = 0 Attribute Value = 24 (16 bits)
供应商ID=0属性类型=0属性值=24（16位）
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M位必须设置为0，H位必须设置为0。
Multicast-Session-Establishment (MSE) is a control message sent by the LAC to the LNS to indicate that the LAC is ready to receive necessary multicast information (Section 6) for the group using the
多播会话建立（MSE）是由LAC发送到LNS的控制消息，以指示LAC已准备好接收使用该会话的组的必要多播信息（第6节）
newly created multicast session. It is the third message in the three-message sequence used for establishing a multicast session within an L2TP tunnel.
新创建的多播会话。它是用于在L2TP隧道内建立多播会话的三条消息序列中的第三条消息。
The following AVP MUST be present in MSE:
MSE中必须存在以下AVP：
Message Type
消息类型
The following AVP MAY be present in MSE:
MSE中可能存在以下AVP：
Sequencing Required
需要排序
Sequencing will occur only from the LNS to the LAC, as a multicast session is only used to forward multicast traffic downstream.
由于多播会话仅用于向下游转发多播流量，因此只能从LN到LAC进行排序。
The associated Message Type AVP is encoded with the following values:
关联的消息类型AVP使用以下值进行编码：
Vendor ID = 0 Attribute Type = 0 Attribute Value = 25 (16 bits)
供应商ID=0属性类型=0属性值=25（16位）
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M位必须设置为0，H位必须设置为0。
Once the multicast session is established, the LAC has to be informed of the L2TP unicast sessions interested in receiving the traffic from the newly created multicast session, and a related optional priority parameter, defined in Section 6.3. To achieve this, a new control message type is defined: Multicast-Session-Information (MSI).
一旦建立多播会话，必须通知LAC有兴趣从新创建的多播会话接收流量的L2TP单播会话，以及第6.3节中定义的相关可选优先级参数。为此，定义了一种新的控制消息类型：多播会话信息（MSI）。
Multicast-Session-Information (MSI) control messages carry AVPs to keep the OSL synchronized between the LNS and the LAC, and to set the optional priority parameter for multicast traffic versus unicast traffic. MSI may be extended to update the multicast session with additional parameters, as needed.
多播会话信息（MSI）控制消息携带AVP，以保持LNS和LAC之间的OSL同步，并设置多播通信量与单播通信量的可选优先级参数。可以根据需要扩展MSI以使用附加参数更新多播会话。
Each MSI message is specific to a particular multicast session. Therefore, the control message MUST use the assigned session ID associated with the multicast session (assigned by the LAC), except for the case mentioned in 6.3.2.
每个MSI消息特定于特定的多播会话。因此，除了6.3.2中提到的情况外，控制消息必须使用与多播会话（由LAC分配）关联的分配会话ID。
The associated Message Type AVP is encoded with the following values:
关联的消息类型AVP使用以下值进行编码：
Vendor ID = 0 Attribute Type = 0 Attribute Value = 26 (16 bits)
供应商ID=0属性类型=0属性值=26（16位）
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M位必须设置为0，H位必须设置为0。
The following AVP MUST be present in MSI:
MSI中必须存在以下AVP：
Message Type
消息类型
The following AVPs MAY be present in MSI:
MSI中可能存在以下AVP：
Random Vector New Outgoing Sessions New Outgoing Sessions Acknowledgement Withdraw Outgoing Sessions Multicast Packets Priority
随机向量新传出会话新传出会话确认收回传出会话多播数据包优先级
New Outgoing Sessions, New Outgoing Sessions Acknowledgement, Withdraw Outgoing Sessions, and Multicast Packets Priority are new AVPs defined in sections 6.2 and 6.3.
新传出会话、新传出会话确认、撤回传出会话和多播数据包优先级是第6.2节和第6.3节中定义的新AVP。
Whenever a change occurs in the Outgoing Sessions List, the LNS MUST inform the LAC of that change. The OSL is built upon subscription reports recorded by GMP or SFGMP processes running in the LNS (Section 4.1).
每当传出会话列表发生更改时，LN必须将该更改通知LAC。OSL基于在LNS中运行的GMP或SFGMP流程记录的订阅报告（第4.1节）。
The LAC maintains an OSL as a local table transmitted by the LNS. As for the LNS, the LAC has to maintain an OSL for each L2TP multicast session within an L2TP tunnel. To update the LAC OSL, the LNS sends a New Outgoing Sessions AVP for additional sessions, or sends a Withdraw Outgoing Sessions AVP to remove sessions. All sessions mentioned in these AVPs MUST be added or removed by the LAC from the relevant OSL. The Outgoing Sessions List is identified by the tunnel ID and the multicast session ID to which the updating AVP refers. To update the OSL, the following AVPs are used:
LAC将OSL维护为LNS传输的本地表。对于LN，LAC必须为L2TP隧道内的每个L2TP多播会话维护OSL。为了更新LAC OSL，LNS发送一个新的传出会话AVP用于附加会话，或发送一个撤销传出会话AVP用于删除会话。这些AVP中提到的所有会话必须由LAC从相关OSL中添加或删除。传出会话列表由隧道ID和更新AVP引用的多播会话ID标识。要更新OSL，请使用以下AVP：
Additional session(s): New Outgoing Sessions AVP
Session(s) removal: Withdraw Outgoing Sessions AVP
Additional session(s): New Outgoing Sessions AVP
Session(s) removal: Withdraw Outgoing Sessions AVP
These new AVPs MUST be sent in an MSI message.
这些新的AVP必须在MSI消息中发送。
The New Outgoing Sessions AVP can only be carried within an MSI message type. This AVP piggybacks every Session ID to which the multicast traffic has to be forwarded.
新的传出会话AVP只能在MSI消息类型中进行。这个AVP将多播流量转发到的每个会话ID都背驮起来。
The AVP has the following format:
AVP具有以下格式：
Vendor ID = 0 Attribute = 81 (16 bits)
供应商ID=0属性=81（16位）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 81 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 81 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session IDs present in the New Outgoing Sessions AVP (considering the maximum value of the Length field). This AVP must be placed in an MSI message and sent after the establishment of the multicast session to indicate the initial outgoing sessions to the LAC, and must be sent at any time when one or more outgoing sessions appear during the multicast session lifetime. Upon receipt of this AVP, the LAC sends a New Outgoing Sessions Acknowledgment AVP to the LNS to notify that the LAC is ready to replicate the multicast traffic toward the indicated sessions.
在新的传出会话AVP中可以存在1到N个会话ID（考虑长度字段的最大值）。此AVP必须置于MSI消息中，并在建立多播会话后发送，以向LAC指示初始传出会话，并且必须在多播会话生存期内出现一个或多个传出会话时随时发送。在收到该AVP后，LAC向LNS发送新的传出会话确认AVP，以通知LAC准备好向指示的会话复制多播通信量。
Usage of this AVP is incremental; only new outgoing sessions have to be listed in the AVP.
此AVP的使用是增量的；AVP中只需列出新的传出会话。
The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1).
M位必须设置为1，AVP可以隐藏（H位设置为0或1）。
The New Outgoing Sessions Acknowledgement AVP can only be carried within an MSI message type. This AVP informs the LNS that the LAC is ready to replicate traffic for every Session ID listed in the AVP.
新的传出会话确认AVP只能在MSI消息类型中携带。此AVP通知LNS LAC已准备好为AVP中列出的每个会话ID复制流量。
The AVP has the following format:
AVP具有以下格式：
Vendor ID = 0 Attribute = 82 (16 bits)
供应商ID=0属性=82（16位）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 82 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 82 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP must be placed in an MSI message and sent by the LAC toward the LNS to acknowledge the receipt of a New Outgoing Sessions list received in a New Outgoing Sessions AVP from the LNS.
此AVP必须放在MSI消息中，并由LAC发送至LNS，以确认收到新传出会话AVP中从LNS接收到的新传出会话列表。
An LNS is allowed to send multicast traffic within the L2TP multicast session as soon as a New Outgoing Sessions Acknowledgement AVP is received for the corresponding L2TP multicast session.
一旦接收到对应L2TP多播会话的新传出会话确认AVP，LNS就可以在L2TP多播会话内发送多播通信量。
An LNS is allowed to stop sending packets of the corresponding multicast flow within L2TP unicast sessions only if it receives an MSI message with the New Outgoing Session Acknowledgement AVP, and only for the unicast Session IDs mentioned in this AVP. The multicast traffic can then be conveyed in L2TP unicast sessions when the L2TP multicast session goes down. From this standpoint, packets related to this multicast flow SHOULD NOT be conveyed within the L2TP unicast sessions mentioned in the AVP in order to avoid the duplication of multicast packets.
仅当LNS接收到带有新的传出会话确认AVP的MSI消息时，并且仅针对该AVP中提到的单播会话ID，才允许LNS停止在L2TP单播会话内发送相应多播流的数据包。当L2TP多播会话停止时，可以在L2TP单播会话中传输多播通信量。从这个角度来看，与该多播流相关的分组不应在AVP中提到的L2TP单播会话内传送，以避免多播分组的重复。
There can be from 1 to N Session IDs present in the New Outgoing Sessions Acknowledgement AVP (considering the maximum value of the Length field). Session IDs mentioned in this AVP that have not been listed in a previous New Outgoing Sessions AVP should be ignored. Non-acknowledged Session IDs MAY be listed in forthcoming New Outgoing Sessions AVPs, but multicast traffic MUST be sent to logical interfaces associated to these Session IDs as long as these Session IDs are not acknowledged for replication by the LAC.
在新的传出会话确认AVP中可以存在1到N个会话id（考虑长度字段的最大值）。应忽略此AVP中提到的、在以前的新传出会话AVP中未列出的会话ID。未确认的会话ID可能会在即将到来的新传出会话AVP中列出，但只要LAC未确认这些会话ID进行复制，则必须将多播通信发送到与这些会话ID相关联的逻辑接口。
The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1).
M位必须设置为1，AVP可以隐藏（H位设置为0或1）。
The Withdraw Outgoing Sessions AVP is sent whenever there is one or more withdrawn subscriptions for the corresponding multicast flow (designated by the session ID on which the MSI is sent).
每当有一个或多个针对相应多播流（由发送MSI的会话ID指定）的撤回订阅时，就会发送撤回传出会话AVP。
The LAC can stop forwarding packets to Session IDs mentioned in the AVP for the corresponding multicast flow as soon as it receives the MSI message embedding this Withdraw Target Session AVP.
一旦LAC接收到嵌入该撤回目标会话AVP的MSI消息，它就可以停止将数据包转发到AVP中提到的会话ID以用于相应的多播流。
The AVP has the following format:
AVP具有以下格式：
Vendor ID = 0 Attribute = 83 (16 bits)
供应商ID=0属性=83（16位）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 83 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 83 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session IDs present in the Withdraw Outgoing Sessions AVP (considering the value of the Length field). The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1).
收回传出会话AVP中可以存在1到N个会话ID（考虑长度字段的值）。M位必须设置为1，AVP可以隐藏（H位设置为0或1）。
The Multicast Packets Priority AVP is an optional AVP intended to indicate to the LAC how to process multicast traffic against unicast traffic. Even though the LAC behavior is partially described here, the nature of the traffic (layer-2 frames for unicast traffic and pure IP packets for multicast traffic) is not a criteria for enforcing a traffic prioritization policy. Traffic processing for the provisioning of a uniformly framed traffic for the final user is described is section 8.
多播分组优先级AVP是可选的AVP，用于向LAC指示如何针对单播业务处理多播业务。尽管这里部分描述了LAC行为，但通信量的性质（单播通信量的第2层帧和多播通信量的纯IP分组）并不是实施通信量优先级策略的标准。第8节描述了用于为最终用户提供统一帧业务的业务处理。
Three different behaviors can be adopted:
可以采取三种不同的行为：
1) Best effort: the traffic is forwarded from the LAC to the end-user in the order in which it comes from the LNS, whatever the type of traffic.
1) 尽力而为：无论通信类型如何，通信量都按照来自LNS的顺序从LAC转发给最终用户。
2) Unicast traffic priority: traffic coming down the L2TP unicast session has priority over traffic coming down the L2TP multicast session.
2) 单播流量优先级：来自L2TP单播会话的流量优先于来自L2TP多播会话的流量。
3) Multicast traffic priority: traffic coming down the L2TP multicast session has priority over traffic coming down the L2TP unicast session.
3) 多播流量优先级：L2TP多播会话下的流量优先于L2TP单播会话下的流量。
The priority is encoded as a 16-bit quantity, which can take the following values:
优先级编码为16位量，可采用以下值：
0: Best effort (default) 1: Unicast traffic priority 2: Multicast traffic priority
0:尽力而为（默认）1:单播流量优先级2:多播流量优先级
The AVP has the following format:
AVP具有以下格式：
Vendor ID = 0 Attribute = 84 (16 bits)
供应商ID=0属性=84（16位）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 84 | Priority Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 84 | Priority Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the multicast traffic rate can reach up to Maximum BPS (as indicated in MSRQ). This rate can exceed the maximum rate allowed for a particular end-user. This means that even with a priority value of 0, the end-user may receive multicast traffic only; unicast packets might be dropped because the multicast flow overwhelms the LAC forwarding buffer(s).
请注意，多播通信速率可以达到最大BPS（如MSRQ中所示）。此速率可以超过特定最终用户允许的最大速率。这意味着，即使优先级值为0，最终用户也只能接收多播业务；单播数据包可能会被丢弃，因为多播流覆盖了LAC转发缓冲区。
The default Priority Value is 0. The M-bit MUST be set to 0, and the AVP MAY be hidden (H-bit set to 0 or 1).
默认优先级值为0。M位必须设置为0，AVP可以隐藏（H位设置为0或1）。
There are two ways of using this AVP: global configuration and individual configuration.
使用此AVP有两种方式：全局配置和单独配置。
The Multicast Priority Packet AVP is sent for all L2TP unicast sessions concerned with a specific multicast flow represented by an L2TP multicast session. In this case, the AVP is sent in an L2TP MSI control message for the corresponding multicast session ID (Session ID = L2TP session for the corresponding multicast group). The
多播优先级分组AVP针对与由L2TP多播会话表示的特定多播流有关的所有L2TP单播会话发送。在这种情况下，AVP在L2TP MSI控制消息中针对相应的多播会话ID（会话ID=对应多播组的L2TP会话）发送。这个
priority value applies to all L2TP unicast sessions to which the multicast group designated by the L2TP multicast session is intended, as soon as this AVP is received.
一旦接收到该AVP，优先级值就应用于L2TP多播会话指定的多播组所针对的所有L2TP单播会话。
The Multicast Priority Packet AVP is sent for a specific L2TP unicast session that SHALL adopt a specific behavior for both unicast and multicast traffics. In this case, the AVP is sent in an L2TP MSI control message for the L2TP unicast session (Session ID = L2TP session for the concerned user). The priority value applies to the targeted session only and does not affect the other sessions. Note that in this case, all multicast packets carried in L2TP multicast sessions are treated the same way by the LAC for the concerned user.
多播优先级分组AVP针对特定的L2TP单播会话发送，该会话对于单播和多播业务都应采用特定的行为。在这种情况下，AVP在L2TP单播会话的L2TP MSI控制消息中被发送（会话ID＝相关用户的L2TP会话）。优先级值仅适用于目标会话，不影响其他会话。注意，在这种情况下，L2TP多播会话中承载的所有多播分组由LAC对相关用户以相同的方式处理。
This is the only case in which an MSI control message can be sent for an L2TP unicast session.
这是唯一可以为L2TP单播会话发送MSI控制消息的情况。
It is the responsibility of the network administrator to decide which behavior to adopt between global or individual configurations, if the AVP is sent twice (one for a multicast group and one for a specific end-user). By default, only the individual configurations SHOULD be taken into consideration in that case.
如果AVP发送两次（一次用于多播组，一次用于特定最终用户），则网络管理员有责任决定在全局配置或单个配置之间采用哪种行为。默认情况下，在这种情况下，只应考虑单个配置。
Support of the Multicast Packets Priority AVP is optional and SHOULD be configurable by the LAC administrator, if it is relevant.
支持多播数据包优先级AVP是可选的，如果相关，LAC管理员应可配置。
An L2TP multicast session should be torn down whenever there are no longer any users interested in receiving the corresponding multicast traffic. A multicast session becomes useless once the related OSL has fewer than a predefined number of entries, this number being defined by a threshold.
当不再有任何用户对接收相应的多播流量感兴趣时，L2TP多播会话应该被中断。一旦相关OSL的条目数少于预定义的条目数（该数目由阈值定义），则多播会话将变得无用。
Multicast session flapping may occur when the number of OSL entries oscillates around the threshold, if the same value is used to trigger the creation or deletion of an L2TP multicast session. To avoid this behavior, two methods can be used:
如果使用相同的值触发L2TP多播会话的创建或删除，则当OSL条目数在阈值附近振荡时，可能会发生多播会话抖动。为了避免这种行为，可以使用两种方法：
- The threshold value that is used to determine whether the L2TP multicast session has to be torn down is lower than the MULTICAST_SESSION_THRESHOLD value;
- 用于确定L2TP多播会话是否必须中断的阈值低于多播会话\u阈值；
- The MULTICAST_SESSION_THRESHOLD value is used to determine whether the L2TP multicast session has to be torn down. A multicast session SHOULD be killed after a period of MULTICAST_SESSION_HOLDTIME seconds if the corresponding OSL maintains fewer than a MULTICAST_SESSION_THRESHOLD number of entries. The MULTICAST_SESSION_HOLDTIME value is 10 seconds by default and SHOULD be configurable by either the LAC or the LNS administrator.
- 多播会话阈值用于确定L2TP多播会话是否必须被拆除。如果相应的OSL保持的条目数少于多播会话阈值，则多播会话应在多播会话保持时间秒后终止。默认情况下，多播会话保持时间值为10秒，应由LAC或LNS管理员进行配置。
The multicast session can be torn down for multiple reasons, including specific criteria not described here (which can be vendor specific).
多播会话可能由于多种原因而中断，包括此处未描述的特定条件（可能是特定于供应商的）。
A multicast session teardown can be initiated by either the LAC or the LNS. However, multicast session teardown MUST be initiated by the LNS if the termination decision is motivated by the number of users interested in receiving the traffic corresponding to a multicast flow.
多播会话拆卸可以由LAC或LN启动。然而，如果终止决定是由感兴趣接收与多播流对应的通信量的用户数量所驱动，则多播会话拆卸必须由LNS发起。
The actual termination of a multicast session is initiated with a new Multicast-Session-End-Notify (MSEN) control message, sent either by the LAC or by the LNS.
多播会话的实际终止由LAC或LNS发送的新多播会话结束通知（MSEN）控制消息启动。
The following is an example of a control message exchange that terminates a multicast session:
以下是终止多播会话的控制消息交换示例：
LAC or LNS LAC or LNS
---------- ----------
(multicast session
termination)
LAC or LNS LAC or LNS
---------- ----------
(multicast session
termination)
<- MSEN (Clean up) ZLB ACK -> (Clean up)
<-MSEN（清理）ZLB确认->（清理）
The Multicast-Session-End-Notify (MSEN) is an L2TP control message sent by either the LAC or the LNS to request the termination of a specific multicast session within the tunnel. Its purpose is to give the peer the relevant termination information, including the reason why the termination occurred. The peer MUST clean up any associated resources and does not acknowledge the MSEN message.
多播会话结束通知（MSEN）是由LAC或LNS发送的L2TP控制消息，用于请求终止隧道内的特定多播会话。其目的是向对等方提供相关终止信息，包括终止发生的原因。对等方必须清除任何相关资源，并且不确认MSEN消息。
As defined in [RFC2661], termination of a control connection will terminate all sessions managed within, including multicast sessions if there are any.
如[RFC2661]中所定义，控制连接的终止将终止其中管理的所有会话，包括多播会话（如果有）。
The MSEN message carries a Result Code AVP with an optional Error Code.
MSEN消息包含结果代码AVP和可选错误代码。
The following AVPs MUST be present in an MSEN message:
MSEN消息中必须存在以下AVP：
Message Type Result Code Assigned Session ID
消息类型结果代码分配的会话ID
The associated Message Type AVP is encoded with the following values:
关联的消息类型AVP使用以下值进行编码：
Vendor ID = 0 Attribute Type = 0 Attribute Value = 27 (16 bits)
供应商ID=0属性类型=0属性值=27（16位）
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M位必须设置为0，H位必须设置为0。
The following values are the defined result codes for MSEN control messages:
以下值是MSEN控制消息的定义结果代码：
1 (16 bits) - No multicast traffic for the group 2 (16 bits) - Session terminated for the reason indicated in the error code 3 (16 bits) - No more receivers 4 (16 bits) - No more receivers (filter-mode change)
1（16位）-组2没有多播流量（16位）-会话因错误代码3（16位）中指示的原因终止-没有更多的接收器4（16位）-没有更多的接收器（过滤器模式更改）
o The code 1 MAY be used when the LAC detects that no traffic is coming down the multicast session, or when the LNS doesn't receive multicast traffic to be conveyed over the L2TP multicast session during a certain period of time.
o 代码1可在LAC检测到没有通信量从多播会话下来时使用，或者当LNS在特定时间段内没有接收到要通过L2TP多播会话传送的多播通信量时使用。
o The code 2 refers to General Error Codes maintained by the IANA for L2TP.
o 代码2是指IANA为L2TP维护的一般错误代码。
o The code 3 MAY be used by the LAC or the LNS when the OSL is empty.
o 当OSL为空时，LAC或LNS可使用代码3。
o The code 4 MAY be used by the LNS when a multicast session is torn down because of a filter-mode change. This result code SHOULD also be used when the OSL becomes empty after a filter-mode change (passive termination when filter-mode changes from INCLUDE to EXCLUDE; see Section 4.3).
o 当多播会话由于过滤模式改变而中断时，LNS可以使用代码4。当OSL在过滤器模式更改后变为空时，也应使用该结果代码（当过滤器模式从包含更改为排除时，被动终止；参见第4.3节）。
Both unicast and multicast traffics have to be merged by the LAC in order to forward properly framed data to the end-user. Multicast packets are framed by the LAC and transmitted toward the proper end-user. Methods used to achieve this function are not described here, since it is an implementation-specific issue.
LAC必须合并单播和多播流量，以便将正确帧数据转发给最终用户。多播数据包由LAC加帧并向适当的最终用户传输。这里不描述用于实现此功能的方法，因为这是一个特定于实现的问题。
All frames conveyed from the LAC to the end-users have to follow the framing scheme applied for the considered peer to which the traffic is destined (e.g., the LAC is always aware of the PPP [RFC1661] link parameters, as described in [RFC2661], Section 6.14). Note that using L2TP Multicast Extension features is not appropriate for end-users who have negotiated a sequenced layer-2 connection with the LNS. While inserting PPP-encapsulated multicast packets in a session, the LAC cannot modify PPP sequencing performed by the LNS for each PPP session.
从LAC传输到最终用户的所有帧必须遵循应用于所考虑的业务目的地对等方的帧方案（例如，LAC始终知道PPP[RFC1661]链路参数，如[RFC2661]第6.14节所述）。请注意，使用L2TP多播扩展功能不适用于与LNS协商有序的第2层连接的最终用户。在会话中插入PPP封装的多播数据包时，LAC不能修改LN为每个PPP会话执行的PPP排序。
This document defines:
本文件规定：
- 5 new Message Type (Attribute Type 0) Values:
o Multicast-Session-Request (MSRQ) : 23
o Multicast-Session-Response (MSRP) : 24
o Multicast-Session-Establishment (MSE) : 25
o Multicast-Session-Information (MSI) : 26
o Multicast-Session-End-Notify (MSEN) : 27
- 5 new Message Type (Attribute Type 0) Values:
o Multicast-Session-Request (MSRQ) : 23
o Multicast-Session-Response (MSRP) : 24
o Multicast-Session-Establishment (MSE) : 25
o Multicast-Session-Information (MSI) : 26
o Multicast-Session-End-Notify (MSEN) : 27
- 5 new Control Message Attribute Value Pairs:
o Multicast Capability : 80
o New Outgoing Sessions : 81
o New Outgoing Sessions Acknowledgement : 82
o Withdraw Outgoing Sessions : 83
o Multicast Packets Priority : 84
- 5 new Control Message Attribute Value Pairs:
o Multicast Capability : 80
o New Outgoing Sessions : 81
o New Outgoing Sessions Acknowledgement : 82
o Withdraw Outgoing Sessions : 83
o Multicast Packets Priority : 84
- 4 Result Codes for the MSEN message:
o No multicast traffic for the group : 1
o Session terminated for the reason indicated in the
error code : 2
o No more receivers : 3
o No more receivers (filter-mode change): 4
- 4 Result Codes for the MSEN message:
o No multicast traffic for the group : 1
o Session terminated for the reason indicated in the
error code : 2
o No more receivers : 3
o No more receivers (filter-mode change): 4
It is possible for one receiver to make additional multicast traffic that has not been requested go down the link of another receiver. This can happen if a single replication context per group is used in INCLUDE mode with receivers having divergent source lists, and in EXCLUDE mode if a receiver has a source list not shared by another. This behavior can be encountered every time receivers are connected to a common multi-access network.
一个接收器可以使未被请求的额外多播通信沿着另一个接收器的链路下行。如果在包含模式下使用每个组的单个复制上下文，并且接收器具有不同的源列表，则会发生这种情况；如果接收器具有未被另一个接收器共享的源列表，则在排除模式下会发生这种情况。每次接收器连接到公共多址网络时都会遇到这种行为。
The extension described in this document does not introduce any additional security issues as far as the activation of the L2TP protocol is concerned.
就L2TP协议的激活而言，本文档中描述的扩展不会带来任何额外的安全问题。
Injecting appropriate control packets in the tunnel toward the LAC to modify Outgoing Session List and to flood end-users with unwanted multicast traffic is only possible if the control connection is hacked. As for any reception of illegitimate L2TP control messages, the following apply:
只有在控制连接被黑客攻击的情况下，才可能在隧道中向LAC注入适当的控制数据包，以修改传出会话列表并向最终用户大量发送不需要的多播流量。对于任何非法L2TP控制信息的接收，以下规定适用：
- If the spoofed control message embeds consistent sequence numbers, next messages will appear out of synch, yielding the control connection to terminate.
- 如果伪造的控制消息嵌入了一致的序列号，则下一条消息将出现不同步，从而导致控制连接终止。
- If sequence numbers are inconsistent with current control connection states, the spoofed control message will be queued or discarded, as described in [RFC2661], Section 5.8.
- 如[RFC2661]第5.8节所述，如果序列号与当前控制连接状态不一致，伪造的控制消息将被排队或丢弃。
The activation of the L2TP multicast capability on the LAC could make the equipment more sensitive to Denial of Service attacks if the control connection or the related LNS is hacked. The LAC might also be sensitive to the burden generated by the additional replication work.
如果控制连接或相关LN受到黑客攻击，LAC上L2TP多播功能的激活可能会使设备对拒绝服务攻击更加敏感。LAC还可能对额外复制工作产生的负担很敏感。
As mentioned in [RFC2661], Section 9.2, securing L2TP requires that the underlying transport make encryption, integrity, and authentication services available for all L2TP traffic, including L2TP multicast traffic (control and data).
如[RFC2661]第9.2节所述，保护L2TP需要底层传输为所有L2TP流量（包括L2TP多播流量（控制和数据））提供加密、完整性和身份验证服务。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[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月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[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月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438]汤斯利，W.“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 35902003年9月。
[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月。
[PROXY] Fenner, B., He, H., Haberman, B., Sandick, H., "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", Work in Progress.
[PROXY]Fenner，B.，He，H.，Haberman，B.，Sandick，H.，“基于IGMP/MLD的多播转发（“IGMP/MLD代理”），工作正在进行中。
Thanks to Christian Jacquenet for all the corrections done on this document and his precious advice, to Pierre Levis for his contribution about IGMP, to Francis Houllier for PPP considerations, and to Xavier Vinet for his input about thresholds. Many thanks to W. Mark Townsley, Isidor Kouvelas, and Brian Haberman for their highly valuable input on protocol definition.
感谢Christian Jacquenet对本文件所做的所有更正及其宝贵建议，感谢Pierre Levis对IGMP的贡献，感谢Francis Houllier对PPP的考虑，感谢Xavier Vinet对阈值的投入。非常感谢W.Mark Townsley、Isidor Kouvelas和Brian Haberman在协议定义方面的宝贵意见。
*Example 1:
*例1：
All users are managed in the same control connection.
在同一控制连接中管理所有用户。
Users {1, 2, 3} subscribe to (Group G1, EXCLUDE {})
Users {3, 4, 5} subscribe to (Group G2, EXCLUDE {})
Users {1, 2, 3} subscribe to (Group G1, EXCLUDE {})
Users {3, 4, 5} subscribe to (Group G2, EXCLUDE {})
Group states for this L2TP tunnel will be:
此L2TP隧道的组状态为：
(G1, EXCLUDE, {})
(G2, EXCLUDE, {})
(G1, EXCLUDE, {})
(G2, EXCLUDE, {})
Therefore, two replication contexts will be created:
因此，将创建两个复制上下文：
-RC1:
(*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5
-RC1:
(*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5
*Example 2:
*例2：
All users are managed in the same control connection.
在同一控制连接中管理所有用户。
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1})
Users {4, 5, 6} subscribe to (Group G1, INCLUDE {S1,S2})
Users {7, 8, 9} subscribe to (Group G1, INCLUDE {S2})
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1})
Users {4, 5, 6} subscribe to (Group G1, INCLUDE {S1,S2})
Users {7, 8, 9} subscribe to (Group G1, INCLUDE {S2})
The group state for this L2TP tunnel will be:
此L2TP隧道的组状态为：
(G1, INCLUDE, {S1, S2)})
（G1，包括，{S1，S2）}）
If the LNS policy allows one replication context per (group, source), two replication contexts will be created:
如果LNS策略允许每个（组、源）有一个复制上下文，则将创建两个复制上下文：
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4, 5, 6
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 4, 5, 6, 7, 8, 9
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4, 5, 6
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 4, 5, 6, 7, 8, 9
If the LNS policy allows one replication context per (group, source-list), one replication context will be created:
如果LNS策略允许每个（组、源列表）有一个复制上下文，则将创建一个复制上下文：
-RC1:
({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9]
-RC1:
({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9]
*Example 3:
*例3：
All users are managed in the same control connection.
在同一控制连接中管理所有用户。
Users {1, 2} subscribe to (Group G1, EXCLUDE {S1})
User {3} subscribes to (Group G1, EXCLUDE {S1, S2})
Users {1, 2} subscribe to (Group G1, EXCLUDE {S1})
User {3} subscribes to (Group G1, EXCLUDE {S1, S2})
The group state for this L2TP tunnel will be:
此L2TP隧道的组状态为：
(G1, EXCLUDE, {S1})
（G1，排除，{S1}）
Therefore, one replication context will be created:
因此，将创建一个复制上下文：
-RC1:
(*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC1:
(*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
Next, user {4} subscribes to (Group G1, INCLUDE {S1}). The group state for the L2TP tunnel is changed to:
接下来，用户{4}订阅（组G1，包括{S1}）。L2TP隧道的组状态更改为：
(G1, EXCLUDE, {})
（G1，排除，{}）
The replication context RC1 is changed to:
复制上下文RC1更改为：
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
*Example 4:
*例4：
All users are managed in the same control connection. The LNS policy allows one replication context per (group, source).
在同一控制连接中管理所有用户。LNS策略允许每个（组、源）有一个复制上下文。
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2})
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2})
The group state for this L2TP tunnel will be:
此L2TP隧道的组状态为：
(G1, INCLUDE, {S1, S2)})
（G1，包括，{S1，S2）}）
Therefore, two replication contexts will be created:
因此，将创建两个复制上下文：
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
Next, user {4} subscribes to (Group G1, EXCLUDE {}), equivalent to an IGMPv2 membership report. The group state for the L2TP tunnel is changed to:
接下来，用户{4}订阅（组G1，排除{}），相当于IGMPv2成员报告。L2TP隧道的组状态更改为：
(G1, EXCLUDE, {})
（G1，排除，{}）
The replication context RC1 is changed to:
复制上下文RC1更改为：
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
The replication context RC2 is changed to:
复制上下文RC2更改为：
-RC2: no packets to forward, Multicast Session MS2, OSL = {}
(Multicast Session MS2 will be deleted)
-RC2: no packets to forward, Multicast Session MS2, OSL = {}
(Multicast Session MS2 will be deleted)
When user {4} leaves G1, the group state for the L2TP tunnel goes back to:
当用户{4}离开G1时，L2TP隧道的组状态返回到：
(G1, INCLUDE, {S1, S2})
（G1，包括，{S1，S2}）
Replication contexts become:
复制上下文变为：
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
(Multicast Session MS2 is re-established)
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
(Multicast Session MS2 is re-established)
Author's Address
作者地址
Gilles Bourdon France Telecom 38-40, rue du General Leclerc 92794 Issy les Moulineaux Cedex 9 - FRANCE
Gilles Bourdon法国电信公司Leclerc将军街38-40号92794 Issy les Moulineaux Cedex 9-法国
Phone: +33 1 4529-4645
EMail: gilles.bourdon@francetelecom.com
Phone: +33 1 4529-4645
EMail: gilles.bourdon@francetelecom.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。