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)
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.
レイヤー2トンネリングプロトコル（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
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トンネルで1回だけ伝送されるソリューションは、サービスプロバイダーにとって重要です。 これは、xDSL（デジタル加入者線）サービスとケーブルインフラストラクチャを展開しているオペレーターに特に当てはまります。 したがって、ネットワークでサポートされるL2TPトンネルは、複数の冗長マルチキャストデータをより頻繁に伝送する必要があります。 このドキュメントで説明されているソリューションは、ダウンストリームトラフィックにのみ適用されます。 つまり、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は [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セッションの1つまたはいくつかが到達できるものを含む、複数の受信者に転送されるマルチキャストフローの転送専用にすることができることを意味します。 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とLNSの間で実行することは、常に受け入れられる、または可能であるとは限りません。 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とLNSの間でネゴシエートされます。 ただし、[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.
LACにマルチキャストセッションを処理する能力があることをLNSに通知するために、LACは制御接続確立フェーズ中にマルチキャスト機能AVPを送信します。 このAVPは、SCCRQまたはSCCRP制御メッセージでLACからLNSに向けて送信されます。
Upon receipt of the Multicast Capability AVP, a LNS may adopt two distinct behaviors:
マルチキャスト機能AVPを受信すると、LNSは次の2つの異なる動作を採用できます。
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マルチキャスト拡張を実装するため、Multicast Capability AVPをサポートします。LNSは、マルチキャストトラフィックをLACに伝達するためのL2TP固有のコマンドを送信できます。
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).
1つまたは一連のLAC向けのL2TPマルチキャスト拡張機能。 この場合、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 | 長さ| ベンダー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機能を組み込むルーターは、次のような少なくとも1つのグループ管理プロトコル（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機器であり、このコンテキストでレシーバーとLNS間のGMPまたはSFGMPメッセージを追跡することは想定されていません。 LNSは常に、マルチキャストグループ宛のIPマルチキャストデータグラムの転送専用のマルチキャストL2TPセッションの作成元になければなりません。 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対応機器は、適切なL2TPトンネル内にL2TPマルチキャストセッションを作成するために、GMPおよびSFGMP状態を分類および分析する必要があります。 これは3つのステップで実行されます。
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トンネルのグループ状態を計算する必要があります。 L2TPトンネルのグループ状態の決定については、セクション4.2で説明します。 各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.
-group：マルチキャストグループを示します。 -filter-mode：[RFC3376]で定義されているINCLUDEまたはEXCLUDEのいずれか。 -source-list：フィルターモードに応じて、マルチキャスト受信が必要な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は1つまたは複数のレプリケーションコンテキストを作成します。
For groups in INCLUDE mode, the LNS SHOULD implement two different policies:
INCLUDEモードのグループの場合、LNSは2つの異なるポリシーを実装する必要があります。
- 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.
-（ソース、グループ）のペアごとに1つのセッション：LNSは（ソース、グループ）のペアごとに1つの複製コンテキストを作成します。 または-グループごとに1つのセッション：LNSは、（ソースリスト、グループ）のペアごとに1つのレプリケーションコンテキストを作成します。
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.
EXCLUDEモードのグループの場合、LNSは（* all *受信者、グループによって除外されるソースのリスト）ごとに1つのレプリケーションコンテキストを作成します。 ソースのリストは、集合ではなく集合の共通部分を表します。
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は1つのL2TPマルチキャストセッション（しきい値条件が満たされている場合。セクション4.3を参照）とそれに関連付けられた発信セッションリスト（OSL）を作成します。 OSLは、グループに対応するマルチキャストフローを要求したL2TPセッションと、関連するソースフィルタリングプロパティを一覧表示します。 レプリケーションコンテキストごとに1つのOSLがあります。 つまり、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 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.
したがって、SFGMPを実行しているグループメンバーの場合、同じL2TPトンネル内の他のグループメンバーがこれらのソースからパケットを受信したい場合、SFGMPメンバーシップレポートで明示的に除外されたソースからマルチキャストトラフィックを受信できます。 この動作は、グループメンバーが同じマルチアクセスネットワークに接続されている場合に匹敵します。 グループがEXCLUDEモードまたはINCLUDEモードで、（グループ、ソースリスト）ごとに1つのセッションを許可するポリシーを使用している場合、同じL2TPトンネルを共有することは、受信したマルチキャストトラフィックに関して同じマルチアクセスネットワークに接続することと同等です。 （ソース、グループ）ごとに1つのL2TPマルチキャストセッションを許可するポリシーを持つINCLUDEモードのグループでは、グループメンバーが要求されていないソースからトラフィックを受信できないため、動作がわずかに改善されます。 一方、このポリシーは、確立および維持する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セッションのサブスクリプションに適用されたマージプロセスの結果を表します。 このマージプロセスは、3つのステップで実行されます。
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）サブスクリプションタイマーの削除。フィルターモードがEXCLUDEの場合、ソースタイマーが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.
マルチキャストグループの専用L2TPマルチキャストセッションをいつ開くかを決定するLNSによって実施されるルールは、LNS管理者が設定できる必要があります。 これは通常、レプリケーションコンテキストで参照されるMULTICAST_SESSION_THRESHOLDレシーバー/セッションのしきい値に達するたびに発生します。 このしきい値は、同じ望ましい受信状態を共有する2つのグループメンバーに対して専用のL2TPマルチキャストセッションを開く価値があるため、デフォルトで2に設定する必要があります（2つのL2TPユニキャストセッションが関係することを意味します）。 この場合、OSLは2つの異なる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マルチキャストセッションでマルチキャストトラフィックの送信を停止する必要があります。 次に、セクション7で説明されているように、L2TPマルチキャストセッションを破棄する必要があります。
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）INCLUDEモードからEXCLUDEモードへ
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:
グループ状態フィルターモードがINCLUDEからEXCLUDEに切り替わると、このグループ状態から発行されたレプリケーションコンテキスト（および関連するL2TPマルチキャストセッション）が1つだけ存在できます（セクション4.1を参照）。 LNSは、このグループ状態に対して以前に作成された1つの複製コンテキストを保持する必要があり（SHOULD）、次のように更新する必要があります。
- 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は、必要に応じてL2TPセッションリストの変更（セクション6.2）を反映するために、OSL更新をLACに送信する必要があります。 グループ用に以前に作成されたレプリケーションコンテキストに対応する未使用のL2TPマルチキャストセッションは、対応するOSLを空にすることによりアクティブまたはパッシブに終了する必要があります。
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 sent to the LAC. Therefore, one can assume that terminating a multicast session passively gives the smoothest transition.
残りのL2TPマルチキャストセッションは、受信者の数が事前に定義されたしきい値を下回った場合にも終了する場合があります（セクション7を参照）。 一時的なパケット損失または受信者への重複の期間を制限するには、LNSがLACに送信されるOSL更新メッセージ間の遅延を最小限に抑える必要があります。 したがって、マルチキャストセッションを受動的に終了すると、最もスムーズに移行できると想定できます。
b) From EXCLUDE Mode to INCLUDE Mode
b）EXCLUDEモードからINCLUDEモードへ
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:
グループ状態フィルターモードがEXCLUDEからINCLUDEに切り替わると、このグループ状態によって発行された複数のレプリケーションコンテキストが作成される場合があります（セクション4.1を参照）。 LNSは、このグループ状態に対して以前に作成されたレプリケーションコンテキストを保持する必要があり（SHOULD）、それに応じて次の情報で更新する必要があります。
- 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
-転送する必要があるソースの新しいリスト。 （グループ、ソース）ごとに1つの複製コンテキストがある場合、このリストには1つのレコードのみがあります-新しい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は、必要に応じてL2TPセッションリストの変更を反映するために、OSL更新をLACに送信する必要があります。 LNSが（グループ、ソース）ごとに1つのレプリケーションコンテキストを作成するように構成されている場合、グループのソースの数に応じて、既存のセッションに加えて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:
本書は、ダウンストリームマルチキャストトラフィックの転送を排他的に強化するソリューションを提案しています。 つまり、LNSからLACに接続されたエンドユーザー向けのデータ。 L2TPセッションを使用するグループメンバーがマルチキャストセッションで伝達されるトラフィックのマルチキャストソースでもある場合、データグラムがソースに返送される場合があります。 この動作を防ぐには、LNSで2つのオプションを使用できます。
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のレプリケーションコンテキストに一致するパケットを送信するグループメンバーが使用するL2TPセッションをOSLから除外します。 したがって、対応するマルチキャストフローは、標準のマルチキャスト転送ルールを使用して、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によって開始されます。 セッションのセットアップには、3つのメッセージ交換が使用されます。 以下は、イベントの典型的なシーケンスです。
LAC LNS
--- ---
(multicast session
triggering)
<- MSRQ MSRP ->
<-MSRQ MSRP->
(Ready to replicate)
（複製準備完了）
MSE -> <- ZLB ACK
MSE-> <-ZLB ACK
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.
Multicast-Session-Request（MSRQ）は、マルチキャストセッションを作成できることを示すためにLNSからLACに送信される制御メッセージです。 LNSは、セクション4.3の規則に従ってこのメッセージを開始します。 これは、L2TPトンネル内でマルチキャストセッションを確立するために使用される3メッセージ交換の最初のものです。
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:
次のAVPがMSRQに存在する必要があります。
Message Type Assigned Session ID
メッセージタイプ割り当てられたセッションID
The following AVPs MAY be present in MSRQ:
次のAVPがMSRQに存在する場合があります。
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.
Multicast-Session-Response（MSRP）は、受信したMSRQメッセージへの応答としてLACからLNSに送信される制御メッセージです。 L2TPトンネル内でマルチキャストセッションを確立するために使用される3メッセージ交換の2番目です。
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:
次のAVPがMSRPに存在する必要があります。
Message Type Assigned Session ID
メッセージタイプ割り当てられたセッションID
The following AVP MAY be present in MSRP:
次のAVPがMSRPに存在する場合があります。
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
Multicast-Session-Establishment（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トンネル内でマルチキャストセッションを確立するために使用される3メッセージシーケンスの3番目のメッセージです。
The following AVP MUST be present in MSE:
次のAVPがMSEに存在する必要があります。
Message Type
メッセージタイプ
The following AVP MAY be present in MSE:
次のAVPがMSEに存在する場合があります。
Sequencing Required
シーケンスが必要
Sequencing will occur only from the LNS to the LAC, as a multicast session is only used to forward multicast traffic downstream.
マルチキャストセッションはマルチキャストトラフィックをダウンストリームに転送するためにのみ使用されるため、シーケンスはLNSから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で定義されている関連するオプションの優先度パラメータを通知する必要があります。 これを実現するために、新しい制御メッセージタイプが定義されています：Multicast-Session-Information（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.
Multicast-Session-Information（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で言及されている場合を除き、マルチキャストセッションに関連付けられた割り当てられたセッションID（LACによって割り当てられた）を使用する必要があります。
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:
次のAVPがMSIに存在する必要があります。
Message Type
メッセージタイプ
The following AVPs MAY be present in MSI:
次のAVPがMSIに存在する場合があります。
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).
発信セッションリストで変更が発生するたびに、LNSはその変更を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は、LNSによって送信されたローカルテーブルとしてOSLを維持します。 LNSに関しては、LACはL2TPトンネル内の各L2TPマルチキャストセッションのOSLを維持する必要があります。 LAC OSLを更新するために、LNSは追加のセッションのために新しい発信セッションAVPを送信するか、セッションを削除するために発信セッションAVPを送信します。 これらのAVPで言及されているすべてのセッションは、関連するOSLからLACによって追加または削除されなければなりません。 発信セッションリストは、更新AVPが参照するトンネルIDとマルチキャストセッションIDによって識別されます。 OSLを更新するには、次のAVPが使用されます。
Additional session(s): New Outgoing Sessions AVP Session(s) removal: Withdraw Outgoing Sessions AVP
追加のセッション：新しい発信セッションAVPセッションの削除：発信セッション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.
New Outgoing Sessions 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 | 長さ| ベンダーID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 81 | セッションID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | ... | セッション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.
New Outgoing Sessions AVPには1〜N個のセッションIDがあります（長さフィールドの最大値を考慮）。 このAVPはMSIメッセージに配置され、マルチキャストセッションの確立後にLACへの最初の発信セッションを示すために送信する必要があります。また、マルチキャストセッションの有効期間中に1つ以上の発信セッションが表示される場合はいつでも送信する必要があります。 このAVPを受信すると、LACは新しい発信セッション確認応答AVPをLNSに送信して、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.
New Outgoing Sessions Acknowledgment AVPは、MSIメッセージタイプ内でのみ伝送できます。 このAVPは、LACがAVPにリストされているすべてのセッションIDのトラフィックを複製する準備ができていることをLNSに通知します。
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 | 長さ| ベンダーID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 82 | セッションID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | ... | セッション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メッセージに配置され、LNSからLNSに向けて送信され、LNSからNew Outgoing Sessions AVPで受信されたNew Outgoing Sessionsリストの受信を確認する必要があります。
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.
新しいNS
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がL2TPユニキャストセッション内の対応するマルチキャストフローのパケットの送信を停止できるのは、新しい発信セッション承認AVPを含むMSIメッセージを受信した場合、およびこのAVPで言及されたユニキャストセッションIDのみです。 マルチキャストトラフィックは、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.
New Outgoing Sessions Acknowledgment AVPには1〜N個のセッションIDが存在する場合があります（長さフィールドの最大値を考慮）。 このAVPで言及され、以前の新規発信セッションAVPにリストされていないセッションIDは無視する必要があります。 承認されていないセッションIDは、今後の新しい発信セッションAVPにリストされる場合がありますが、これらのセッションIDがLACによる複製に対して承認されない限り、これらのセッション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).
Withdraw Outgoing Sessions AVPは、対応するマルチキャストフロー（MSIが送信されるセッションIDで指定される）に対して1つ以上の撤回されたサブスクリプションがある場合に送信されます。
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は、このWithdraw Target Session 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 | 長さ| ベンダーID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 83 | セッションID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | ... | セッション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).
1〜NのセッションIDが、発信セッションの撤回AVPに存在する可能性があります（長さフィールドの値を考慮）。 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は、ユニキャストトラフィックに対してマルチキャストトラフィックを処理する方法をLACに示すことを目的としたオプションのAVPです。 ここではLACの動作について部分的に説明していますが、トラフィックの性質（ユニキャストトラフィック用のレイヤー2フレームとマルチキャストトラフィック用の純粋なIPパケット）は、トラフィックの優先順位付けポリシーを実施するための基準ではありません。 最終ユーザー向けに均一にフレーム化されたトラフィックをプロビジョニングするトラフィック処理については、セクション8で説明します。
Three different behaviors can be adopted:
3つの異なる動作を採用できます。
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）ベストエフォート：トラフィックは、トラフィックのタイプに関係なく、LACからエンドユーザーにLNSから来る順序で転送されます。
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 | 長さ| ベンダーID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 84 | 優先値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+
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を使用するには、グローバル構成と個別構成の2つの方法があります。
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 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ユニキャストセッションに対して送信されます。 この場合、AVPは、対応するマルチキャストセッションIDのL2TP MSI制御メッセージで送信されます（セッションID =対応するマルチキャストグループのL2TPセッション）。 優先値は、この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.
これは、MSI制御メッセージをL2TPユニキャストセッションに送信できる唯一のケースです。
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が2回送信される場合（マルチキャストグループ用と特定のエンドユーザー用）、グローバル構成または個別構成間でどの動作を採用するかを決定するのは、ネットワーク管理者の責任です。 デフォルトでは、個々の構成のみがその場合に考慮される必要があります。
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エントリの数がしきい値付近で変動すると、マルチキャストセッションのフラッピングが発生する場合があります。 この動作を回避するには、2つの方法を使用できます。
- 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マルチキャストセッションを切断する必要があるかどうかを判断するために使用されるしきい値が、MULTICAST_SESSION_THRESHOLD値よりも低い。
- 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.
-MULTICAST_SESSION_THRESHOLD値は、L2TPマルチキャストセッションを切断する必要があるかどうかを判断するために使用されます。 対応するOSLのエントリ数がMULTICAST_SESSION_THRESHOLDより少ない場合、マルチキャストセッションはMULTICAST_SESSION_HOLDTIME秒後に終了する必要があります。 MULTICAST_SESSION_HOLDTIMEの値はデフォルトで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またはLNSによって開始できます。 ただし、マルチキャストフローに対応するトラフィックの受信に関心のあるユーザーの数によって終了決定が動機付けられている場合、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によって送信された新しいMulticast-Session-End-Notify（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)
<- MSEN (Clean up) ZLB ACK -> (Clean up)
<-MSEN（クリーンアップ）ZLB ACK->（クリーンアップ）
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.
Multicast-Session-End-Notify（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 LACがマルチキャストセッションを下るトラフィックがないことをLACが検出した場合、またはLNSが特定の期間中にL2TPマルチキャストセッションを介して伝達されるマルチキャストトラフィックを受信しない場合、コード1を使用できます。
o The code 2 refers to General Error Codes maintained by the IANA for L2TP.
oコード2は、L2TPのためにIANAによって維持される一般的なエラーコードを指します。
o The code 3 MAY be used by the LAC or the LNS when the OSL is empty.
o OSLが空の場合、コード3はLACまたはLNSによって使用される場合があります。
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を使用できます（MAY）。 この結果コードは、フィルターモードの変更後にOSLが空になった場合にも使用する必要があります（フィルターモードがINCLUDEからEXCLUDEに変更された場合の受動的な終了。セクション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からエンドユーザーに伝達されるすべてのフレームは、トラフィックの宛先となる考慮対象ピアに適用されるフレーミングスキームに従う必要があります（たとえば、[RFC2661]で説明されているように、LACは常にPPP [RFC1661]リンクパラメーターを認識します ]、セクション6.14）。 L2TPマルチキャスト拡張機能の使用は、LNSとのシーケンス化されたレイヤー2接続をネゴシエートしたエンドユーザーには適切でないことに注意してください。 セッションにPPPカプセル化マルチキャストパケットを挿入している間、LACは各PPPセッションに対してLNSによって実行される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つの新しいメッセージタイプ（属性タイプ0）値：oマルチキャストセッションリクエスト（MSRQ）：23 oマルチキャストセッションレスポンス（MSRP）：24 oマルチキャストセッション確立（MSE）：25 oマルチキャストセッション 情報（MSI）：26 oマルチキャストセッション終了通知（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つの新しい制御メッセージ属性値ペア：oマルチキャスト機能：80 o新しい発信セッション：81 o新しい発信セッションの確認応答：82 o発信セッションの撤回：83 oマルチキャストパケットの優先度：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
-MSENメッセージの4つの結果コード：oグループのマルチキャストトラフィックなし：1 oエラーコードに示された理由によりセッションが終了しました：2 oこれ以上受信者なし：3 oこれ以上受信者なし（フィルターモードの変更）：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.
1つの受信者が、要求されていない追加のマルチキャストトラフィックを別の受信者のリンクに送信することは可能です。 これは、グループごとに単一のレプリケーションコンテキストが異なるソースリストを持つレシーバーでINCLUDEモードで使用されている場合、およびレシーバーが別のソースリストと共有されていないソースリストがある場合にEXCLUDEモードで使用される場合に発生する可能性があります。 この動作は、受信機が共通のマルチアクセスネットワークに接続されるたびに発生する可能性があります。
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.
LACでL2TPマルチキャスト機能を有効にすると、制御接続または関連するLNSがハッキングされた場合、機器がサービス拒否攻撃に対してより敏感になる可能性があります。 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、RFC 1112、1989年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、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]フェナー、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] Townsley、W。、バレンシア、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、「Layer Two Tunneling Protocol "L2TP"」、RFC 2661、1999年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]カイン、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。、「レイヤー2トンネリングプロトコル（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]ハーバーマン、B。、「マルチキャストリスナーディスカバリ（MLD）プロトコルのソースアドレス選択」、RFC 3590、2003年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プロキシ」）」、Work in Progress。
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、IGMPについて貢献してくれたPierre Levis、PPPを検討してくれたFrancis Houllier、そしてしきい値について入力してくれたXavier Vinetに感謝します。 W. Mark Townsley、Isidor Kouvelas、およびBrian Habermanに、プロトコル定義に関する非常に貴重な情報を提供してくれたことに感謝します。
Appendix A. Examples of Group States Determination
付録A.グループ状態の決定の例
*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 {})
ユーザー{1、2、3}は（Group G1、EXCLUDE {}）にサブスクライブしますユーザー{3、4、5}は（Group G2、EXCLUDE {}）にサブスクライブします
Group states for this L2TP tunnel will be:
このL2TPトンネルのグループ状態は次のとおりです。
(G1, EXCLUDE, {}) (G2, EXCLUDE, {})
（G1、除外、{}）（G2、除外、{}）
Therefore, two replication contexts will be created:
したがって、2つの複製コンテキストが作成されます。
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 -RC2: (*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5
-RC1：（*、G1）パケット、マルチキャストセッションMS1、OSL = 1、2、3 -RC2：（*、G2）パケット、マルチキャストセッション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})
ユーザー{1、2、3}がサブスクライブ（グループG1、INCLUDE {S1}）ユーザー{4、5、6}がサブスクライブ（グループG1、INCLUDE {S1、S2}）ユーザー{7、8、9}がサブスクライブ （グループG1、INCLUDE {S2}）
The group state for this L2TP tunnel will be:
このL2TPトンネルのグループ状態は次のとおりです。
(G1, INCLUDE, {S1, S2)})
（G1、INCLUDE、{S1、S2）}）
If the LNS policy allows one replication context per (group, source), two replication contexts will be created:
LNSポリシーで（グループ、ソース）ごとに1つの複製コンテキストが許可されている場合、2つの複製コンテキストが作成されます。
-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）パケット、マルチキャストセッションMS1、OSL = 1、2、3、4、5、6 -RC2：（S2、G1）パケット、マルチキャストセッション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ポリシーが（グループ、ソースリスト）ごとに1つのレプリケーションコンテキストを許可する場合、1つのレプリケーションコンテキストが作成されます。
-RC1: ({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9]
-RC1：（{S1、S2}、G1）パケット、マルチキャストセッション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})
ユーザー{1、2}は（Group G1、EXCLUDE {S1}）にサブスクライブしますユーザー{3}は（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:
したがって、1つのレプリケーションコンテキストが作成されます。
-RC1: (*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC1：（*-{S1}、G1）パケット、マルチキャストセッション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}は（Group G1、INCLUDE {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）パケット、マルチキャストセッション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ポリシーでは、（グループ、ソース）ごとに1つの複製コンテキストが許可されます。
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2})
ユーザー{1、2、3}はサブスクライブします（グループG1、INCLUDE {S1、S2}）
The group state for this L2TP tunnel will be:
このL2TPトンネルのグループ状態は次のとおりです。
(G1, INCLUDE, {S1, S2)})
（G1、INCLUDE、{S1、S2）}）
Therefore, two replication contexts will be created:
したがって、2つの複製コンテキストが作成されます。
-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）パケット、マルチキャストセッションMS1、OSL = 1、2、3 -RC2：（S2、G1）パケット、マルチキャストセッション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}は（Group G1、EXCLUDE {}）にサブスクライブします。これは、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）パケット、マルチキャストセッション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：転送するパケットなし、マルチキャストセッションMS2、OSL = {}（マルチキャストセッションMS2は削除されます）
When user {4} leaves G1, the group state for the L2TP tunnel goes back to:
ユーザー{4}がG1を離れると、L2TPトンネルのグループ状態は次の状態に戻ります。
(G1, INCLUDE, {S1, S2})
（G1、INCLUDE、{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）パケット、マルチキャストセッションMS1、OSL = 1、2、3 -RC2：（S2、G1）パケット、マルチキャストセッションMS2、OSL = 1、2、3（マルチキャストセッションMS2が再確立された ）
Author's Address
著者の住所
Gilles Bourdon France Telecom 38-40, rue du General Leclerc 92794 Issy les Moulineaux Cedex 9 - FRANCE
Gilles Bourdon France Telecom 38-40、rue du General Leclerc 92794 Issy les Moulineaux Cedex 9-フランス
Phone: +33 1 4529-4645 EMail: gilles.bourdon@francetelecom.com
電話：+33 1 4529-4645電子メール：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事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（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 Editor機能の資金は、現在インターネット協会によって提供されています。