[要約] RFC 4045は、L2TPでマルチキャストトラフィックを効率的に転送するための拡張機能についての規格です。目的は、L2TPを使用してマルチキャストトラフィックを効果的にサポートすることです。
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)
レイヤー-2トンネルプロトコル（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).
Copyright（c）The Internet Society（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セッションに対してマルチキャストデータを1回しか送信するメカニズムであり、各マルチキャストフローが専用の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 L2TP tunnels. This multicast extension to L2TP is designed so that it does not affect the behavior of L2TP equipment under normal conditions.
IPマルチキャストベースのサービスを展開するというコンテキスト内で、L2TPネットワークサーバー（LNS）機能を埋め込んだIPネットワークのルーターが、L2TPを介してネットワークにアクセスするユーザーに向けてマルチキャストデータの転送に関与している可能性があると想定されています。トンネル。LNSは、マルチキャストフローの使用を要求したレシーバーが使用する各L2TPセッションのマルチキャストデータの複製を担当しています。ここで説明するソリューションでは、LNSはマルチキャストデータを1回だけ送信し、L2TPアクセス濃縮器（LAC）がトラフィックレプリケーションを実行できるようにすることができます。そうすることで、L2TPトンネルをサポートするコアネットワーク内のトランスミッションリソースをspareすることが期待されています。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.
Edgeデバイスがますます多くのユーザーを集約しているため、マルチキャストデータが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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、LNSに向かってLACによってSCCRQまたはSCCRPコントロールメッセージで送信されます。
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マルチキャスト拡張機能を実装しているため、マルチキャスト機能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 L2TP multicast extension features towards one or a set of LAC(s). In this case, the LNS behavior is similar to that in 1).
マルチキャスト機能は、制御接続の確立フェーズ中にAVPが受信されたトンネルのみを指します。LNS管理者がL2TPマルチキャスト拡張機能を1つまたはAセットに向けてシャットダウンできるはずです。この場合、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）（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.
- グループ：マルチキャストグループを示します。-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で構成されたローカルポリシーに応じて、1つまたは複数の複製コンテキストを作成します。
For groups in INCLUDE mode, the LNS SHOULD implement two different policies:
インクルードモードのグループの場合、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.
除外モードのグループの場合、LNSは1つの複製コンテキストごとに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メンバーシップレポートで明示的に除外されたソースからマルチキャストトラフィックを受け取ることができます。この動作は、グループメンバーが同じマルチアクセスネットワークに接続されている場合に匹敵します。グループがモードを除外している場合、または1つのセッション（グループ、ソースリスト）を許可するポリシーを含むモードを含む場合、同じL2TPトンネルを共有することは、受け取ったマルチキャストトラフィックの観点から同じマルチアクセスネットワークに接続されることに相当します。1つのL2TPマルチキャストセッションごとに1つの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セッションのサブスクリプションに適用されるマージプロセスの結果を表します。このマージプロセスは、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) サブスクリプションタイマーの削除、およびフィルターモードが除外されている場合、ソースタイマー> 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.
このプロセスについては、[プロキシ]でも説明されています。グループ状態の決定の例は、付録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によって施行される規則により、マルチキャストグループ向けに専用のL2TPマルチキャストセッションをいつ開くかが決定されることが決定されます。これは通常、複製コンテキストで参照されているMultiCast_Session_Threshold受信機/セッションのしきい値に到達したときに発生します。このしきい値は、デフォルトで2で評価する必要があります。同じ目的の受信状態を共有する2人のグループメンバーに対して専用のL2TPマルチキャストセッションを開く価値があるためです（つまり、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) インクルードモードからモードを除外します
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:
グループ状態フィルターモードが含まれるから除外に切り替えると、このグループ状態から発行された1つの複製コンテキスト（および関連するL2TPマルチキャストセッション）のみが存在する可能性があります（セクション4.1を参照）。LNSは、このグループ状態のために以前に作成された1つの複製コンテキストを保持する必要があり、以下で更新する必要があります。
- 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) 除外モードからモードを含める
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
- 転送する必要があるソースの新しいリスト。このリストには、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から、このOSLの複製コンテキストに一致するパケットを送信するグループメンバーが使用するL2TPセッションを除外します。したがって、対応するマルチキャストフローは、標準のマルチキャスト転送ルールを使用して、ユーザーL2TPユニキャストセッションを介してLNSによって送信されます。
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)
lac lns --- ---（マルチキャストセッションのトリガー）
<- MSRQ MSRP ->
<-srq 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.
マルチキャストセッションレクエスト（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.
マルチキャストセッション応答（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 newly created multicast session. It is the third message in the three-message sequence used for establishing a multicast session within an L2TP tunnel.
マルチキャストセッションと確立（MSE）は、LACがLNSに送信したコントロールメッセージであり、新しく作成されたマルチキャストセッションを使用してグループに必要なマルチキャスト情報（セクション6）を受信する準備ができていることを示しています。これは、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で定義されている関連するオプションの優先パラメーターを通知する必要があります。これを達成するために、新しいコントロールメッセージタイプが定義されています：マルチキャストセッションインフォーメーション（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を運び、OSLをLNSとLACの間で同期させ、マルチキャストトラフィックとユニキャストトラフィックのオプションの優先パラメーターを設定します。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:
次の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を送信するか、SESSIONSを削除するためにAVPを撤回します。これらのAVPに記載されているすべてのセッションは、関連するOSLからLACによって追加または削除する必要があります。発信セッションリストは、トンネルIDと更新AVPが参照するマルチキャストセッションIDによって識別されます。OSLを更新するには、次の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に示す必要があり、マルチキャストセッションの生涯に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.
新しい発信セッションの謝辞AVPは、MSIメッセージタイプ内でのみ実行できます。このAVPは、LNSに、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に向かって送信する必要があります。これは、LNSからの新しい発信セッションAVPで受け取った新しい発信セッションリストの受領を確認する必要があります。
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.
LNSは、対応するL2TPマルチキャストセッションに対して新しい発信セッションの確認AVPが受信されるとすぐに、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は、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.
新しい発信セッションの承認AVP（長さフィールドの最大値を考慮）には、1〜NセッションIDが存在する可能性があります。以前の新しい発信セッションにリストされていないこの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).
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は、この撤回ターゲットセッション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は、ユニキャストトラフィックに対してマルチキャストトラフィックを処理する方法を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) 最善の努力：トラフィックは、トラフィックの種類が何であれ、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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セッション）で送信されます。優先値は、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が2回送信される場合（マルチキャストグループ用、および特定のエンドユーザーの場合は1つ）場合、グローバルまたは個々の構成の間でどの動作を採用するかを決定することは、ネットワーク管理者の責任です。デフォルトでは、その場合は個々の構成のみを考慮する必要があります。
Support of the Multicast Packets Priority AVP is optional and SHOULD be configurable by the LAC administrator, if it is relevant.
マルチキャストパケットのサポートPriority 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によって送信された新しいマルチキャストセッションエンドノティイ（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:
次のAVPはMSENメッセージに存在する必要があります。
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ビット）に示されている理由で終了しました。変化）
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は、L2TPのためにIANAによって維持されている一般的なエラーコードを指します。
o The code 3 MAY be used by the LAC or the LNS when the OSL is empty.
o コード3は、OSLが空の場合に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 コード4は、フィルターモードの変更のためにマルチキャストセッションが取り壊されたときにLNSによって使用される場合があります。この結果コードは、フィルターモードが変更された後に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は常に[RFC2661]で説明されているように、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 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
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で説明されているように、シーケンス番号が現在の制御接続状態と矛盾している場合、[RFC2661]で説明されているように、スプーフィングされた制御メッセージがキュー化または破棄されます。
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] 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] Townsley、W.、Valencia、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] 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] Townsley、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] Haberman、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プロキシ」）」、進行中の作業。
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.
この文書で行われたすべての修正と彼の貴重なアドバイスについて、IGMPに関する彼の貢献についての彼の貴重なアドバイス、PPPの考慮事項のためのフランシス・ホーリエへの、そして彼の閾値に関する彼の入力についての彼の貴重なアドバイスに感謝します。プロトコル定義に関する非常に価値のある入力について、W。マークタウンズリー、イシドールコウベラス、ブライアンハーバーマンに感謝します。
*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 {})
Group states for this L2TP tunnel will be:
このL2TPトンネルのグループ状態は次のとおりです。
(G1, EXCLUDE, {})
(G2, EXCLUDE, {})
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
*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})
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
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]
*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})
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
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
*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})
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
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
The replication context RC2 is changed to:
複製コンテキストRC2は次のように変更されます。
-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、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)
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。