RFC4045 日本語訳
4045 Extensions to Support Efficient Carrying of Multicast Traffic inLayer-2 Tunneling Protocol (L2TP). G. Bourdon. April 2005. (Format: TXT=59140 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Bourdon Request for Comments: 4045 France Telecom Category: Experimental April 2005
コメントを求めるワーキンググループG.低音部音栓要求をネットワークでつないでください: 4045年のフランス電子通信カテゴリ: 実験的な2005年4月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
Layer Two Tunnelingプロトコル(L2TP)はトンネリングPPPパケットに方法を提供します。 このドキュメントは拡大についてL2TPに説明して、L2TPの効率的な使用をするのは展開マルチキャストの文脈の中でデータがこれらのトンネルによって伝えられなければならないサービスにトンネルを堀ります。
Table of Contents
目次
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
1.2. Terminology............................................. 3
2. Motivation for a Session-Based Solution....................... 4
3. Control Connection Establishment.............................. 5
3.1. Negotiation Phase....................................... 5
3.2. Multicast Capability AVP (SCCRQ, SCCRP)................. 5
4. L2TP Multicast Session Establishment Decision................. 6
4.1. Multicast States in LNS................................. 6
4.2. Group State Determination............................... 8
4.3. Triggering.............................................. 9
4.4. Multicast Traffic Sent from Group Members............... 10
5. L2TP Multicast Session Opening Process........................ 11
5.1. Multicast-Session-Request (MSRQ)........................ 11
5.2. Multicast-Session-Response (MSRP)....................... 12
5.3. Multicast-Session-Establishment (MSE)................... 12
6. Session Maintenance and Management............................ 13
6.1. Multicast-Session-Information (MSI)..................... 13
6.2. Outgoing Sessions List Updates.......................... 14
1. 序論… 2 1.1. このドキュメントで中古のコンベンション… 3 1.2. 用語… 3 2. セッションベースのソリューションに関する動機… 4 3. コネクション確立を制御してください… 5 3.1. 交渉フェーズ… 5 3.2. マルチキャスト能力AVP(SCCRQ、SCCRP)… 5 4. L2TPマルチキャストセッション設立決定… 6 4.1. LNSのマルチキャスト州… 6 4.2. 州の決断を分類してください… 8 4.3. 引き金となります。 9 4.4. マルチキャスト交通はグループのメンバーから発信しました… 10 5. L2TPのマルチキャストのセッションの初めの過程… 11 5.1. マルチキャストセッション要求(MSRQ)… 11 5.2. マルチキャストセッション応答(MSRP)… 12 5.3. マルチキャストセッション設立(MSE)… 12 6. セッション維持と管理… 13 6.1. マルチキャストセッション情報(MSI)… 13 6.2. 外向的なセッションはアップデートを記載します… 14
Bourdon Experimental [Page 1] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[1ページ]RFC4045の効率的なマルチキャスト交通
6.2.1. New Outgoing Sessions AVP (MSI)................. 15
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI). 15
6.2.3. Withdraw Outgoing Sessions AVP (MSI)............ 17
6.3. Multicast Packets Priority AVP (MSI).................... 17
6.3.1. Global Configuration............................ 18
6.3.2. Individual Configuration........................ 19
6.3.3. Priority........................................ 19
7. Multicast Session Teardown.................................... 19
7.1. Operations.............................................. 20
7.2. Multicast-Session-End-Notify (MSEN)..................... 20
7.3. Result Codes............................................ 21
8. Traffic Merging............................................... 22
9. IANA Considerations........................................... 22
10. Security Considerations....................................... 23
11. References.................................................... 23
11.1. Normative References.................................... 23
11.2. Informative References.................................. 24
12. Acknowledgements.............................................. 24
Appendix A. Examples of Group States Determination............... 25
Author's Address.................................................. 27
Full Copyright Statement.......................................... 28
6.2.1. 新しい出発しているセッションAVP(MSI)… 15 6.2.2. 新しい出発しているセッション承認AVP(MSI)。 15 6.2.3. 出発しているセッションAVP(MSI)を引っ込めてください… 17 6.3. マルチキャストパケット優先権AVP(MSI)… 17 6.3.1. グローバルな構成… 18 6.3.2. 個々の構成… 19 6.3.3. 優先権… 19 7. マルチキャストセッション分解… 19 7.1. 操作… 20 7.2. マルチキャストセッション終わりに通知します(MSEN)… 20 7.3. 結果コード… 21 8. 交通合併… 22 9. IANA問題… 22 10. セキュリティ問題… 23 11. 参照… 23 11.1. 標準の参照… 23 11.2. 有益な参照… 24 12. 承認… 24 グループに関する付録A.の例は決断を述べます… 25作者のアドレス… 27 完全な著作権宣言文… 28
1. Introduction
1. 序論
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 Network Server(LNS)能力を埋め込むIPネットワークのルータがマルチキャストデータの推進にかかわるかもしれないと思われます、L2TPトンネルを通ってネットワークにアクセスするユーザに向かって。 そうした受信機が、マルチキャスト流動が使用するよう要求したそれぞれのL2TPセッションのためのマルチキャストデータを模写することを担当してLNSがあります。 ここで説明された解決策では、LNSはL2TP Access Concentrator(LAC)に一度だけマルチキャストデータを送って、交通模写を実行させることができます。 そうすることによって、それがサポートするコアネットワークでトランスミッションリソースを割くと予想されます。
Bourdon Experimental [Page 2] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[2ページ]RFC4045の効率的なマルチキャスト交通
L2TP tunnels. This multicast extension to L2TP is designed so that it does not affect the behavior of L2TP equipment under normal conditions.
L2TPはトンネルを堀ります。 L2TPへのこのマルチキャスト拡大は、正常な状況ではL2TP設備の動きに影響しないように、設計されています。
A solution whereby multicast data is carried only once in a L2TP tunnel is of interest to service providers, as edge devices are aggregating more and more users. This is particularly true for operators who are deploying xDSL (Digital Subscriber Line) services and cable infrastructures. Therefore, L2TP tunnels that may be supported by the network will have to carry multiple redundant multicast data more often. The solution described in this document applies to downstream traffic exclusively; i.e., data coming from the LNS toward end-users connected to the LAC. This downstream multicast traffic is not framed by the LNS but by the LAC, thus ensuring compatibility for all users in a common tunnel, whatever the framing scheme.
マルチキャストデータがL2TPトンネルで一度だけ運ばれる解決策はサービスプロバイダーに興味があります、エッジデバイスがますます多くのユーザに集められているとき。 xDSL(デジタルSubscriber線)サービスを配備しているオペレータとケーブルインフラストラクチャには、これは特に本当です。 したがって、ネットワークによって支えられるかもしれないL2TPトンネルは、よりしばしば複数の余分なマルチキャストデータを運ばなければならないでしょう。 本書では説明された解決策は排他的に川下の交通に適用されます。 すなわち、LNSからエンドユーザに向かって来るデータはLACに接続しました。 LNSによって縁どられるのではなく、この川下のマルチキャスト交通はLACによって縁どられます、その結果、一般的なトンネルのすべてのユーザのために互換性を確実にします、縁どり計画が何であっても。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
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との接続について言及します。 追加Control MessagesとAttribute値のペア(AVPs)は、マルチキャスト交通輸送の特定の目的のためのこの接続を開いて、維持するために本書では定義されます。 LACとLNSとのこの接続がマルチキャスト交通だけを伝えることを意図します。
Session
セッション
This term is used when there is no need to dissociate multicast
from unicast sessions, and thus it designates both.
ユニキャストセッションからマルチキャストを離す必要は全くないとき、今期が使用されています、そして、その結果、それは両方を指定します。
Bourdon Experimental [Page 3] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[3ページ]RFC4045の効率的なマルチキャスト交通
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.
マルチキャストレセプションが望まれている1セットの源からグループに送られたデータグラムに指定します。
GMP
GMP
Group Management Protocol, such as:
以下などのManagementプロトコルを分類してください。
- IGMPv1 ([RFC1112])
- IGMPv2 ([RFC2236])
- MLD ([RFC2710], [RFC3590])
- IGMPv1([RFC1112])--IGMPv2([RFC2236])--MLD([RFC2710]、[RFC3590])
SFGMP
SFGMP
Source Filtering Group Management Protocol, such as:
以下などのソースFiltering Group Managementプロトコル
- IGMPv3 ([RFC3376])
- MLDv2 ([RFC3810])
- IGMPv3([RFC3376])--MLDv2([RFC3810])
2. Motivation for a Session-Based Solution
2. セッションベースのソリューションに関する動機
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セッションを捧げることができることを意味します、1時までに達することができるものかこれらのいくつかのL2TPセッションを含んでいて。 IPマルチキャストデータを運ぶセッションは、基本的な縁どり計画から独立していて、したがって、L2TPプロトコルによって支持されるどんな新しい縁どり計画とも互換性があります。
Using a single L2TP session per multicast flow is motivated by the following arguments:
マルチキャスト流動あたり1つのただ一つの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セッションを使用することでネットワークにアクセスするユーザ)をフィルターにかけることができなければなりません。
Bourdon Experimental [Page 4] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[4ページ]RFC4045の効率的なマルチキャスト交通
- 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とエンドユーザの間のマルチキャストサービスは確実にされます、基本的なネットワークでマルチキャスト能力を活性化する必要性を軽減して。
3. Control Connection Establishment
3. コントロールコネクション確立
3.1. Negotiation Phase
3.1. 交渉フェーズ
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を見てください)。
3.2. Multicast Capability AVP (SCCRQ, SCCRP)
3.2. マルチキャスト能力AVP(SCCRQ、SCCRP)
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はコントロール接続確立段階の間、Multicast Capability AVPを送ります。 SCCRQで送って、このAVPはどちらかかSCCRPコントロールがLNSに向かったLACによるメッセージです。
Upon receipt of the Multicast Capability AVP, a LNS may adopt two distinct behaviors:
Multicast Capability 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マルチキャスト拡張子を実行しません: どんなマルチキャスト関連の情報(Multicast Capability 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がコントロール接続確立段階の間に受け取られているトンネルについて言及します。 それ、SHOULD、LNS管理者が停止するのにおいて、可能であってください。
Bourdon Experimental [Page 5] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[5ページ]RFC4045の効率的なマルチキャスト交通
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つに向かったL2TPマルチキャスト拡大機能かLAC(s)のセット。 この場合、LNSの振舞いは1において)それと同様です。
The AVP has the following format:
AVPには、以下の形式があります:
Vendor ID = 0
Attribute = 80 (16 bits)
0業者ID=属性=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 MAYに設定しなければなりません。隠されてください(H-ビットは0か1にセットします)。
The length of this AVP is 6 octets.
このAVPの長さは6つの八重奏です。
4. L2TP Multicast Session Establishment Decision
4. L2TPマルチキャストセッション設立決定
4.1. Multicast States in LNS
4.1. LNSのマルチキャスト州
The router that embeds the LNS feature MUST support at least one Group Management Protocol (GMP), such as:
LNSの特徴を埋め込むルータは以下などの少なくとも1つのGroup Managementプロトコル(GMP)をサポートしなければなりません。
- IGMPv1
- IGMPv2
- MLD
- IGMPv1--IGMPv2--MLD
or a Source Filtering Group Management Protocol (SFGMP), such as:
または、以下などのSource Filtering Group Managementプロトコル(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 MUSTはマルチキャストL2TPセッションの創造の起源においてそうです。マルチキャストグループに運命づけられたIPマルチキャストデータグラムの推進のために、捧げられます。 LNSはあらゆる論理的なインタフェースへのGMPかSFGMP QuerierとしてL2TPセッションまで関連しているのに機能します。
Bourdon Experimental [Page 6] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[6ページ]RFC4045の効率的なマルチキャスト交通
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セッションあたりの)単位で1グループあたりの状態を維持するでしょう。 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セッションのために記録されたグループ州を使用することによって。 セクション4.2でL2TPトンネルのためのグループ州の決断について議論します。 それぞれのL2TPトンネルに関しては、この計算の結果はフォーム(グループ、フィルタモード、ソース・リスト)の州のリストを発行するでしょう:
- group: Denotes the multicast group.
- filter-mode: Either INCLUDE or EXCLUDE, as defined in
[RFC3376].
- source-list: List of IP unicast addresses from which multicast
reception is desired or not, depending on the filter-mode.
- 以下を分類してください。 マルチキャストグループを指示します。 - フィルタモード: [RFC3376]で定義されるようなINCLUDEかEXCLUDEのどちらか。 - ソース・リスト: フィルタモードによって、マルチキャストレセプションが必要である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は1か複数の模写文脈を作成するでしょう、LNSで構成された考えられたグループとローカルの方針のためにフィルタモードによって。
For groups in INCLUDE mode, the LNS SHOULD implement two different
policies:
INCLUDEモードによるグループのために、LNS SHOULDは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グループあたり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、意志が、ある模写文脈を作成する単位(ソースのリストがすべての*ごとに除いた、受信機、グループ) ソースのリストは組合ではなく、セットの交差点を表します。
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) そして、関連Outgoing Session List(OSL)。 OSLはグループに対応するマルチキャスト流動と関連ソースフィルタリング特性を要求したL2TPセッションを記載します。 模写文脈あたり1OSLがあります。 すなわち、L2TPマルチキャストセッション単位で。
For a group member running an SFGMP, it is therefore possible to receive multicast traffic from sources that have been explicitly excluded in its SFGMP membership report if other group members in the
したがって、SFGMPを走らせているグループのメンバーにとって、中で他のグループのメンバーであるならSFGMP会員資格レポートで明らかに除かれたソースからのマルチキャスト交通を受けるのは可能です。
Bourdon Experimental [Page 7] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[7ページ]RFC4045の効率的なマルチキャスト交通
same L2TP tunnel wish to receive packets from these sources. This behavior is comparable to the case where group members are connected to the same multi-access network. When a group is in EXCLUDE mode or in INCLUDE mode with a policy allowing one session per (group, source-list), sharing the same L2TP tunnel is equivalent to being connected to the same multi-access network in terms of multicast traffic received. For groups in INCLUDE mode with a policy allowing one L2TP multicast session per (source, group), the behavior is slightly improved because it prevents group members from receiving traffic from non-requested sources. On the other hand, this policy potentially increases the number of L2TP multicast sessions to establish and maintain. Examples are provided in Appendix A.
同じL2TPはこれらのソースからパケットを受けるという願望にトンネルを堀ります。 この振舞いはグループのメンバーが同じマルチアクセスネットワークに接続されるケースに匹敵しています。 グループがEXCLUDEモードであるか、または方針が(グループ、ソース・リスト)単位で1つのセッションを許容しているINCLUDEモードで、同じL2TPトンネルを共有するのが交通が受けたマルチキャストで同じマルチアクセスネットワークに関連づけられるのに同等であるときに。 方針が(ソース、グループ)あたり1つのL2TPマルチキャストセッションを許容しているINCLUDEモードによるグループにおいて、グループのメンバーが非要求されたソースからの交通を受けるのを防ぐので、振舞いはわずかに改良されます。 他方では、この方針は確立して、維持するL2TPマルチキャストセッションの数を潜在的に増加させます。 例をAppendix 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を見てください)。
4.2. Group State Determination
4.2. グループ州の決断
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.
ソースFiltering Group Managementプロトコルが付属ネットワーク単位で1グループあたり1つのフィルタモードを保って、グループの総必要なレセプション状態を最小のセットに凝縮するためにquerierルータを必要とするので、すべてのシステムの会員資格は満たされています。
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 Control Connectionは、トンネルでのあらゆる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 Control Connectionのために維持されます。 グループ州のこのリストは1セットのフォームに関する会員資格記録(グループ、フィルタモード、ソース・リスト)です。
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:
それぞれのグループ州はControl ConnectionのL2TPセッションのときに考えられたグループのために購読に適用された合併している過程の結果を表します。 この合併している過程は以下の3ステップで実行されます:
1) Conversion of any GMP subscription into SFGMP subscription
(IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2);
1) SFGMP購読(IGMPv3へのIGMPv1/v2、MLDv2へのMLDv1)へのどんなGMP購読の変換。
2) Removal of subscription timers and, if filter-mode is EXCLUDE,
sources with source timer > 0;
2) ソースタイマ>0がある購読タイマとフィルタモードがEXCLUDEであることのソースの解任。
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)、結果として起こる購読は合併されています。
Bourdon Experimental [Page 8] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[8ページ]RFC4045の効率的なマルチキャスト交通
This process is also described in [PROXY]. Examples of group state determination are provided in Appendix A.
また、この過程は[PROXY]で説明されます。 グループ州の決断に関する例をAppendix Aに提供します。
4.3. Triggering
4.3. 引き金となること
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.
いつaを開くかがマルチキャストのためのL2TPマルチキャストセッションを捧げたと決められるLNSによって実施されるべき規則はSHOULDを分類します。LNS管理者は構成可能であってください。 模写文脈で参照をつけられるMULTICAST_SESSION_THRESHOLD受信機/セッションの敷居に達しているときはいつも、これは通常起こるでしょう。 この閾値SHOULDが2時にデフォルトで評価されて、2グループのためにひたむきなL2TPマルチキャストセッションを開く価値があって、同じように共有しているメンバーがレセプション状態(2つのL2TPユニキャストセッションが関係があることを意味する)を望んでいました。 この場合、OSLは参照two異なった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.
また、関連L2TPマルチキャストセッションが開かれなければならないかどうか決めるために終わりのユーザによって要求されたマルチキャスト交通のLNSによる実際の領収書を考慮に入れることができます。
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 MUSTは、対応する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:
グループがINCLUDEからEXCLUDEまでフィルタモード・スイッチを述べるとき、このグループ状態から発行された1つの模写文脈(そして、関連L2TPマルチキャストセッション)だけが存在できます(セクション4.1を見てください)。 LNS SHOULDは、以前に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 MUSTは、L2TPセッションリスト変化(セクション6.2)を反映するためにOSLアップデートをLACに送ります。 それらの対応するOSLsを空にすることによって活発か受け身に終えられて、以前に対応する未使用のL2TPマルチキャストセッションはグループSHOULDのための模写文脈を作成しました。
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
また、受信機の数が事前に定義された敷居の下にあるなら(セクション7を見てください)、残っているL2TPマルチキャストセッションは終えられるかもしれません。 一時的なパケット損失の持続時間か受信機への写し、LNSが最小にしなければならない限界に、メッセージはOSLアップデートの間で延着しています。
Bourdon Experimental [Page 9] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[9ページ]RFC4045の効率的なマルチキャスト交通
sent to the LAC. Therefore, one can assume that terminating a multicast session passively gives the smoothest transition.
LACに発信しました。 したがって、人は、マルチキャストセッションを終えると最も滑らかな変遷が受け身に与えられると仮定できます。
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:
グループが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
- 転送されなければならないソースの新しいリスト。 このリストには、ある(グループ、ソース)あたりの模写文脈があれば、ある記録しかありません--、新しい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 MUSTは、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マルチキャストセッションが開かれなければならないなら、オリジナルのマルチキャストセッションのOSLをアップデートする前にこれらのマルチキャストセッションが確立されるまで、LNS SHOULDは待っています。 一時的なパケット損失か写しの持続時間を受信機に制限するために、LNSはメッセージがLACに送ったOSLアップデートの間の遅れを最小にしなければなりません。
4.4. Multicast Traffic Sent from Group Members
4.4. グループのメンバーから送られたマルチキャスト交通
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が送られます、標準のマルチキャスト推進規則を使用して。
Bourdon Experimental [Page 10] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[10ページ]RFC4045の効率的なマルチキャスト交通
5. L2TP Multicast Session Opening Process
5. 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)
ラックLNS--- --- (マルチキャストセッションの引き金となること)
<- 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を送ります。
5.1. Multicast-Session-Request (MSRQ)
5.1. マルチキャストセッション要求(MSRQ)
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に送られたコントロールメッセージです。 セクション4.3の規則に従って、LNSはこのメッセージを開始します。 それはL2TPトンネルの中でマルチキャストセッションを確立するのに使用される3交換処理で1番目です。
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がMulticast Capability AVPと共にL2TPトンネルを開けなかったなら、LNS MUST NOTはMSRQコントロールメッセージを送ります。 LAC MUSTはL2TPトンネルで送られたMSRQコントロールメッセージを無視します、コントロールメッセージがMulticast Capability AVPを含んでいてL2TPトンネルが開けられなかったなら。
The following AVPs MUST be present in MSRQ:
以下のAVPsはMSRQに存在していなければなりません:
Message Type
Assigned Session ID
Session IDが割り当てられたメッセージタイプ
The following AVPs MAY be present in MSRQ:
以下のAVPsはMSRQに存在しているかもしれません:
Random Vector
Maximum BPS
無作為のベクトル最大のビーピーエス
Bourdon Experimental [Page 11] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[11ページ]RFC4045の効率的なマルチキャスト交通
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.
Maximum BPS値はLNS管理者によって設定されます。 しかしながら、エンドユーザの線能力に従って、この値は選ばれるべきです。 Maximum BPSはL2TPの中のすべてのための最も高い速度接続より高いエンドユーザがトンネルであったならSHOULD NOTを評価します。
The associated Message Type AVP is encoded with the following values:
関連Message Type AVPは以下の値でコード化されます:
Vendor ID = 0
Attribute Type = 0
Attribute Value = 23 (16 bits)
0属性タイプ=0属性値=業者ID=23(16ビット)
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M-ビットを0に設定しなければなりません、そして、H-ビットを0に設定しなければなりません。
5.2. Multicast-Session-Response (MSRP)
5.2. マルチキャストセッション応答(MSRP)
Multicast-Session-Response (MSRP) is a control message sent by the LAC to the LNS in response to a received MSRQ message. It is the second in a three-message exchange used for establishing a multicast session within an L2TP tunnel.
マルチキャストセッション応答(MSRP)はLACによって受信されたMSRQメッセージに対応して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:
以下のAVPsはMSRPに存在していなければなりません:
Message Type
Assigned Session ID
Session IDが割り当てられたメッセージタイプ
The following AVP MAY be present in MSRP:
以下のAVP MAY、MSRPに存在してください:
Random Vector
無作為のベクトル
The associated Message Type AVP is encoded with the following values:
関連Message Type AVPは以下の値でコード化されます:
Vendor ID = 0
Attribute Type = 0
Attribute Value = 24 (16 bits)
0属性タイプ=0属性値=業者ID=24(16ビット)
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M-ビットを0に設定しなければなりません、そして、H-ビットを0に設定しなければなりません。
5.3. Multicast-Session-Establishment (MSE)
5.3. マルチキャストセッション設立(MSE)
Multicast-Session-Establishment (MSE) is a control message sent by the LAC to the LNS to indicate that the LAC is ready to receive necessary multicast information (Section 6) for the group using the
マルチキャストセッション設立(MSE)はLACがグループ使用のための必要なマルチキャスト情報(セクション6)を受け取る準備ができているのを示すためにLACによってLNSに送られたコントロールメッセージです。
Bourdon Experimental [Page 12] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[12ページ]RFC4045の効率的なマルチキャスト交通
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 MUST、MSEに存在してください:
Message Type
メッセージタイプ
The following AVP MAY be present in MSE:
以下のAVP MAY、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:
関連Message Type AVPは以下の値でコード化されます:
Vendor ID = 0
Attribute Type = 0
Attribute Value = 25 (16 bits)
0属性タイプ=0属性値=業者ID=25(16ビット)
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M-ビットを0に設定しなければなりません、そして、H-ビットを0に設定しなければなりません。
6. Session Maintenance and Management
6. セッション維持と管理
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は新たに作成されたマルチキャストセッションからの交通、および関連する任意の優先権パラメタがセクション6.3で定義した受信したがっていたL2TPユニキャストセッションにおいて知識がなければなりません。 これを達成するために、新しいコントロールメッセージタイプは定義されます: マルチキャストセッション情報(MSI)。
6.1. Multicast-Session-Information (MSI)
6.1. マルチキャストセッション情報(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)コントロールメッセージは、LNSとLACの間でOSLを連動させ続けて、ユニキャスト交通に対してマルチキャスト交通のための任意の優先権パラメタを設定するためにAVPsを運びます。 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メッセージは特定のマルチキャストセッションに特定です。 したがって、コントロールメッセージがケース以外のマルチキャストセッション(LACによって割り当てられる)に関連しているIDが中に言及した割り当てられたセッションを使用しなければならない、6.3、.2
Bourdon Experimental [Page 13] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[13ページ]RFC4045の効率的なマルチキャスト交通
The associated Message Type AVP is encoded with the following values:
関連Message Type AVPは以下の値でコード化されます:
Vendor ID = 0
Attribute Type = 0
Attribute Value = 26 (16 bits)
0属性タイプ=0属性値=業者ID=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 MUST、MSIに存在してください:
Message Type
メッセージタイプ
The following AVPs MAY be present in MSI:
以下のAVPsはMSIに存在しているかもしれません:
Random Vector
New Outgoing Sessions
New Outgoing Sessions Acknowledgement
Withdraw Outgoing Sessions
Multicast Packets Priority
無作為のベクトル新しい外向的なセッションズNewの外向的なセッション承認は外向的なセッションマルチキャストパケット優先権を引き下がらせます。
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.
新しいOutgoingセッションズ、New OutgoingセッションズAcknowledgement、Withdraw Outgoingセッションズ、およびMulticast Packets Priorityはセクション6.2と6.3で定義された新しいAVPsです。
6.2. Outgoing Sessions List Updates
6.2. 外向的なセッションはアップデートを記載します。
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).
変化がOutgoingセッションズListに起こるときはいつも、LNS MUSTはその変化についてLACに知らせます。 OSLは、LNS(セクション4.1)へ駆け込みながら、GMPによって記録された購読レポートかSFGMPの過程に造られます。
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:
地方のテーブルがLNSによって送られたようにLACはOSLを維持します。 LNSに関して、LACはL2TPトンネルの中のそれぞれのL2TPマルチキャストセッションのためにOSLを維持しなければなりません。 LAC OSLをアップデートするなら、LNSは、追加セッションのためにNew OutgoingセッションズAVPを送るか、またはセッションを取り除くためにWithdraw OutgoingセッションズAVPを送ります。 LACは関連OSLからこれらのAVPsで言及されたすべてのセッションを、加えられなければならないか、または取り除かなければなりません。 OutgoingセッションズListはアップデートしているAVPが参照するトンネルIDとマルチキャストセッションIDによって特定されます。 OSLをアップデートするために、以下のAVPsは使用されています:
Additional session(s): New Outgoing Sessions AVP
Session(s) removal: Withdraw Outgoing Sessions AVP
追加セッション(s): 新しいOutgoingセッションズのAVP Session(s)取り外し: 出発しているセッションAVPを引っ込めてください。
These new AVPs MUST be sent in an MSI message.
MSIメッセージでこれらの新しいAVPsを送らなければなりません。
Bourdon Experimental [Page 14] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[14ページ]RFC4045の効率的なマルチキャスト交通
6.2.1. New Outgoing Sessions AVP (MSI)
6.2.1. 新しい出発しているセッション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.
MSIメッセージタイプの中でNew OutgoingセッションズAVPを運ぶことができるだけです。 このAVPはマルチキャスト交通が送られなければならないあらゆるSession IDを背負います。
The AVP has the following format:
AVPには、以下の形式があります:
Vendor ID = 0
Attribute = 81 (16 bits)
0業者ID=属性=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 | セッションID0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | セッション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.
1〜NまでNew OutgoingセッションズAVPの現在のSession IDがあることができます(Length分野の最大値を考える場合)。 このAVPを初期の外向的なセッションをLACに示すためにMSIメッセージに置いて、マルチキャストセッションの設立の後に送らなければならなくて、1つ以上の外向的なセッションがマルチキャストセッション生涯現れる何時でも送らなければなりません。 このAVPを受け取り次第、LACは通知するLNSへのLACがそうであるセッションズAcknowledgment AVPをNew Outgoingに示されたセッションに向かってマルチキャスト交通を模写する準備ができている状態で送ります。
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 MAYに設定しなければなりません。隠されてください(H-ビットは0か1にセットします)。
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)
6.2.2. 新しい出発しているセッション承認AVP(MSI)
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.
MSIメッセージタイプの中でNew OutgoingセッションズAcknowledgement AVPを運ぶことができるだけです。 このAVPは、LACをAVPに記載されたあらゆるSession IDに交通を模写する準備ができていることをLNSに知らせます。
Bourdon Experimental [Page 15] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[15ページ]RFC4045の効率的なマルチキャスト交通
The AVP has the following format:
AVPには、以下の形式があります:
Vendor ID = 0
Attribute = 82 (16 bits)
0業者ID=属性=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 | セッションID0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | セッション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.
New OutgoingセッションズAVPにLNSから受け取られたNew Outgoingセッションズリストの領収書を受け取ったことを知らせるためにこのAVPをMSIメッセージに置かれて、LACは、LNSに向かって送らなければなりません。
An LNS is allowed to send multicast traffic within the L2TP multicast session as soon as a New Outgoing Sessions Acknowledgement AVP is received for the corresponding L2TP multicast session.
対応するL2TPマルチキャストセッションのためにNew OutgoingセッションズAcknowledgement AVPを受け取るとすぐに、LNSはL2TPマルチキャストセッション中にマルチキャスト交通を送ることができます。
An LNS is allowed to stop sending packets of the corresponding multicast flow within L2TP unicast sessions only if it receives an MSI message with the New Outgoing Session Acknowledgement AVP, and only for the unicast Session IDs mentioned in this AVP. The multicast traffic can then be conveyed in L2TP unicast sessions when the L2TP multicast session goes down. From this standpoint, packets related to this multicast flow SHOULD NOT be conveyed within the L2TP unicast sessions mentioned in the AVP in order to avoid the duplication of multicast packets.
LNSは、それがNew Outgoing Session Acknowledgement AVP、およびIDがこのAVPで言及したユニキャストSessionだけへのMSIメッセージを受け取る場合にだけL2TPユニキャストセッション以内に対応するマルチキャスト流動のパケットを送るのを止めることができます。 そして、L2TPマルチキャストセッションが落ちるL2TPユニキャストセッションのときにマルチキャスト交通を伝えることができます。 この見地、このマルチキャスト流れSHOULD NOTに関連するパケットから、マルチキャストパケットの重複を避けるために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.
1〜NまでNew OutgoingセッションズAcknowledgement AVPの現在のSession IDがあることができます(Length分野の最大値を考える場合)。 前のNew OutgoingセッションズAVPに記載されていないこのAVPで言及されたセッションIDは無視されるべきです。 今度のNew OutgoingセッションズAVPsに非承認されたSession IDを記載するかもしれませんが、これらのSession IDが模写のためにLACによって承認されない限り、これらのSession 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 MAYに設定しなければなりません。隠されてください(H-ビットは0か1にセットします)。
Bourdon Experimental [Page 16] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[16ページ]RFC4045の効率的なマルチキャスト交通
6.2.3. Withdraw Outgoing Sessions AVP (MSI)
6.2.3. 出発しているセッションAVPを引っ込めてください。(MSI)
The Withdraw Outgoing Sessions AVP is sent whenever there is one or more withdrawn subscriptions for the corresponding multicast flow (designated by the session ID on which the MSI is sent).
対応するマルチキャスト流動(MSIが送られるセッションIDで、指定される)のための1つ以上のよそよそしい購読があるときはいつも、Withdraw OutgoingセッションズAVPを送ります。
The LAC can stop forwarding packets to Session IDs mentioned in the AVP for the corresponding multicast flow as soon as it receives the MSI message embedding this Withdraw Target Session AVP.
LACは、このWithdraw Target Session AVPを埋め込むMSIメッセージを受け取るとすぐに、対応するマルチキャスト流動のためにAVPで言及されたSession IDにパケットを送るのを止めることができます。
The AVP has the following format:
AVPには、以下の形式があります:
Vendor ID = 0
Attribute = 83 (16 bits)
0業者ID=属性=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 | セッションID0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | セッション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までWithdraw OutgoingセッションズAVPの現在のSession IDがあることができます(Length分野の値を考える場合)。 M-ビットを1、およびAVP MAYに設定しなければなりません。隠されてください(H-ビットは0か1にセットします)。
6.3. Multicast Packets Priority AVP (MSI)
6.3. マルチキャストパケット優先権AVP(MSI)
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.
Multicast Packets Priority 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からエンドユーザまで交通を進めます、交通のタイプが何であっても。
Bourdon Experimental [Page 17] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[17ページ]RFC4045の効率的なマルチキャスト交通
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)
0業者ID=属性=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).
マルチキャスト交通率にMaximum 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).
デフォルトPriority Valueは0歳です。 M-ビットを0、およびAVP MAYに設定しなければなりません。隠されてください(H-ビットは0か1にセットします)。
There are two ways of using this AVP: global configuration and individual configuration.
このAVPを使用する2つの方法があります: グローバルな構成と個々の構成。
6.3.1. Global Configuration
6.3.1. グローバルな構成
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
L2TPマルチキャストセッションで表される特定のマルチキャスト流動に関するすべてのL2TPユニキャストセッションのためにMulticastプリオリティ・パケットAVPを送ります。 この場合、対応するマルチキャストセッションIDへのL2TP MSIコントロールメッセージでAVPを送ります(対応するマルチキャストグループのためのL2TP Session ID=セッション)。 The
Bourdon Experimental [Page 18] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[18ページ]RFC4045の効率的なマルチキャスト交通
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.
優先順位の値はL2TPマルチキャストセッションで指定されたマルチキャストグループが意図するすべてのL2TPユニキャストセッションに適用されます、このAVPが受け取られているとすぐに。
6.3.2. Individual Configuration
6.3.2. 個々の構成
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.
そのSHALLがユニキャストとマルチキャスト通行の両方のための特異的行動を採用する特定のL2TPユニキャストセッションのためにMulticastプリオリティ・パケットAVPを送ります。 この場合、L2TPユニキャストセッションへのL2TP MSIコントロールメッセージでAVPを送ります(関係があるユーザのためのL2TP Session ID=セッション)。 優先順位の値は、狙っているセッションだけに適用して、他のセッションに影響しません。 この場合L2TPマルチキャストセッションのときに運ばれたすべてのマルチキャストパケットが関係があるユーザのために同じようにLACによって扱われることに注意してください。
This is the only case in which an MSI control message can be sent for an L2TP unicast session.
これはL2TPユニキャストセッションのためにMSIコントロールメッセージを送ることができる唯一のそうです。
6.3.3. Priority
6.3.3. 優先権
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を送るなら。 個々の構成SHOULDだけ、その場合考慮に入れられてください。
Support of the Multicast Packets Priority AVP is optional and SHOULD be configurable by the LAC administrator, if it is relevant.
Multicast Packets Priority AVPのサポートが任意である、SHOULD、LAC管理者は構成可能であってください、それが関連しているなら。
7. Multicast Session Teardown
7. マルチキャストセッション分解
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:
OSLエントリーの数が敷居の周りで揺れると、マルチキャストセッションのばたつくことは起こるかもしれません、同じ値がL2TPマルチキャストセッションの創造か削除の引き金となるのに使用されるなら。 この振舞いを避けるために、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価値より低いです。
Bourdon Experimental [Page 19] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[19ページ]RFC4045の効率的なマルチキャスト交通
- 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マルチキャストセッションが取りこわされなければならないかどうか決定するのに使用されます。 マルチキャストセッションSHOULD、対応するOSLがMULTICAST_SESSION_THRESHOLDが達する1未満を維持するならHOLDTIMEが後援するエントリーのMULTICAST_SESSION_の期間の後に殺されてください。 _HOLDTIMEがデフォルトで10秒であることを評価するMULTICAST_SESSIONとSHOULD、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はマルチキャストセッション分解を起こさなければなりません。
7.1. Operations
7.1. 操作
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セッションエンドに通知している新しい(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)
ラック、LNSラックまたはLNS---------- ---------- (マルチキャストセッション終了)
<- MSEN
(Clean up)
ZLB ACK ->
(Clean up)
<MSEN(きれいにする)ZLB ACK->。(きれいにします)
7.2. Multicast-Session-End-Notify (MSEN)
7.2. マルチキャストセッション終わりに通知します。(MSEN)
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セッションエンドに通知している(MSEN)はトンネルの中の特定のマルチキャストセッションの終了を要求するためにLACかLNSのどちらかによって送られたL2TPコントロールメッセージです。 目的は終了が起こった理由を含む関連終了情報を同輩に教えることです。 同輩は、どんな関連リソースもきれいにしなければならなくて、MSENメッセージを承認しません。
Bourdon Experimental [Page 20] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[20ページ]RFC4045の効率的なマルチキャスト交通
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メッセージは任意のError Codeと共にResult Code AVPを運びます。
The following AVPs MUST be present in an MSEN message:
以下のAVPsはMSENメッセージに存在していなければなりません:
Message Type
Result Code
Assigned Session ID
Session IDが割り当てられたメッセージタイプ結果コード
The associated Message Type AVP is encoded with the following values:
関連Message Type AVPは以下の値でコード化されます:
Vendor ID = 0
Attribute Type = 0
Attribute Value = 27 (16 bits)
0属性タイプ=0属性値=業者ID=27(16ビット)
The M-bit MUST be set to 0, and the H-bit MUST be set to 0.
M-ビットを0に設定しなければなりません、そして、H-ビットを0に設定しなければなりません。
7.3. Result Codes
7.3. 結果コード
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 LNSが、ある期間にL2TPマルチキャストセッションの間、運ばれるためにマルチキャスト交通を受けないとき、LACが交通がマルチキャストセッションで来させるそのノーを検出すると、コード1は使用されるかもしれません。
o The code 2 refers to General Error Codes maintained by the IANA
for L2TP.
o コード2はL2TPのためにIANAによって維持されたError Codes司令官について言及します。
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を使用するかもしれません。 この結果はSHOULDをコード化します、また、OSLがフィルタモード変更の後に空になった(INCLUDEからEXCLUDEまでのフィルタモード変更であることの受け身の終了; セクション4.3を見てください)ら、使用されてください。
Bourdon Experimental [Page 21] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[21ページ]RFC4045の効率的なマルチキャスト交通
8. Traffic Merging
8. 交通合併
Both unicast and multicast traffics have to be merged by the LAC in order to forward properly framed data to the end-user. Multicast packets are framed by the LAC and transmitted toward the proper end- user. Methods used to achieve this function are not described here, since it is an implementation-specific issue.
ユニキャストとマルチキャスト通行の両方が、適切に縁どられたデータをエンドユーザに転送するためにLACによって合併されなければなりません。 マルチキャストパケットは、LACによって縁どられて、適切な終わりのユーザに向かって伝えられます。 この機能を獲得するのに使用される方法は、それが実現特有の問題であるので、ここで説明されません。
All frames conveyed from the LAC to the end-users have to follow the framing scheme applied for the considered peer to which the traffic is destined (e.g., the LAC is always aware of the PPP [RFC1661] link parameters, as described in [RFC2661], Section 6.14). Note that using L2TP Multicast Extension features is not appropriate for end- users who have negotiated a sequenced layer-2 connection with the LNS. While inserting PPP-encapsulated multicast packets in a session, the LAC cannot modify PPP sequencing performed by the LNS for each PPP session.
LACからエンドユーザまで運ばれたすべてのフレームが交通が運命づけられている考えられた同輩のために適用された縁どり計画に続かなければなりません(例えば、LACはいつもPPP[RFC1661]リンクパラメータを知っています、[RFC2661]で説明されるように、セクション6.14)。 LNSとの配列された層-2接続を交渉した終わりのユーザには、L2TP Multicast Extensionの特徴を使用するのが適切でないことに注意してください。 セッションのときにPPPによって要約されたマルチキャストパケットを挿入する間、LACはそれぞれのPPPセッションのためにLNSによって実行されたPPP配列を変更しないことができます。
9. IANA Considerations
9. IANA問題
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 新しいMessage Type(属性Type0)値: o マルチキャストセッション要求(MSRQ): 23 o Multicastセッション応答(MSRP): 24 o Multicastセッション設立(MSE): 25 o Multicastセッション情報(MSI): 26 ○ Multicastセッションエンドに通知します(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 新しいControl Message Attribute Valueペア: o マルチキャスト能力: 80 ○ New Outgoingセッションズ: 81 o New OutgoingセッションズAcknowledgement: 82 ○ Withdraw Outgoingセッションズ: 83 o Multicast Packets Priority: 84
- 4 Result Codes for the MSEN message:
o No multicast traffic for the group : 1
o Session terminated for the reason indicated in the
error code : 2
o No more receivers : 3
o No more receivers (filter-mode change): 4
- 4 MSENメッセージのための結果Codes: o グループのためのマルチキャスト交通がありません: 1 理由で、示された状態で終えられたo Sessionは誤りで以下をコード化します。 2 ○ それ以上の受信機がありません: 3 ○ それ以上の受信機がありません(フィルタモード変更): 4
Bourdon Experimental [Page 22] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[22ページ]RFC4045の効率的なマルチキャスト交通
10. Security Considerations
10. セキュリティ問題
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台の受信機が要求されていない追加マルチキャスト交通が別の受信機のリンクを下られるのは、可能です。1グループあたり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:
コントロール接続がハックされる場合にだけ、Outgoing Session Listを変更して、求められていないマルチキャスト交通でエンドユーザをあふれさせるようにトンネルで適切なコントロールパケットを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マルチキャスト交通(コントロールとデータ)を含んでいて。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
Bourdon Experimental [Page 23] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[23ページ]RFC4045の効率的なマルチキャスト交通
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
w.[RFC2236]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[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.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
Assigned Numbers Authority (IANA) Considerations Update",
BCP 68, RFC 3438, December 2002.
w.[RFC3438]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September
2003.
[RFC3590]ハーバーマン、B.、「マルチキャストリスナー発見(MLD)プロトコルのためのソースアドレス選択」、RFC3590、2003年9月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
11.2. Informative References
11.2. 有益な参照
[PROXY] Fenner, B., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
based Multicast Forwarding ("IGMP/MLD Proxying")", Work in
Progress.
[PROXY]フェナー、B.、彼、H.、ハーバーマン、B.、Sandick、H.、「IGMP/MLDはMulticast Forwarding("IGMP/MLD Proxying")を基礎づけた」ProgressのWork。
12. Acknowledgements
12. 承認
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.
このドキュメントと彼の貴重なアドバイスのときに行われたすべての修正のためのクリスチャンのJacquenetと、そして、彼の貢献のためのIGMPに関するピアー・レビーと、そして、PPP問題のためのフランシスHoullierと、そして、彼の入力のための敷居に関するザビエルVinetをありがとうございます。 プロトコル定義に関する彼らの非常に貴重な意見のためにW.マークTownsley、Isidor Kouvelas、およびブライアン・ハーバーマンをありがとうございます。
Bourdon Experimental [Page 24] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[24ページ]RFC4045の効率的なマルチキャスト交通
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が加入する、(G1、EXCLUDEを分類してください、)、ユーザ3、4、5は加入します。(G2を分類してください、除外、)
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) パケット、Multicast Session MS1、OSLは1、2、3-RC2と等しいです: (*、G2) パケット、Multicast Session MS2 3、4、OSL=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が4、5、6が加入するユーザに加入する、(G1を分類してください、INCLUDE S1)(G1を分類してください、INCLUDE、S1、S2)、ユーザ7、8、9は加入します。(G1を分類してください、そして、S2を含めてください)
The group state for this L2TP tunnel will be:
このL2TPトンネルへのグループ状態は以下の通りになるでしょう。
(G1, INCLUDE, {S1, S2)})
(G1、インクルード、S1、S2)、)
If the LNS policy allows one replication context per (group, source), two replication contexts will be created:
LNS(ソースは分類する)であるなら方針が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) パケット、Multicast Session MS1、OSLは1、2、3、4、5、6-RC2と等しいです: (S2、G1) パケット、Multicast Session MS2 4、5、6、7、8、OSL=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) パケット、Multicast Session MS1、OSL=[1..9]
Bourdon Experimental [Page 25] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[25ページ]RFC4045の効率的なマルチキャスト交通
*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は3が加入するユーザに加入します(グループG1、EXCLUDE S1)。(G1を分類してください、そして、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) パケット、Multicast Session MS1 1、2、OSL=3
Next, user {4} subscribes to (Group G1, INCLUDE {S1}). The group
state for the L2TP tunnel is changed to:
次に、ユーザ4は(グループ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) パケット、Multicast Session MS1 1、2、3、OSL=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を分類してください、そして、S1、S2を含めてください)
The group state for this L2TP tunnel will be:
このL2TPトンネルへのグループ状態は以下の通りになるでしょう。
(G1, INCLUDE, {S1, S2)})
(G1、インクルード、S1、S2)、)
Therefore, two replication contexts will be created:
したがって、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) パケット、Multicast Session MS1、OSLは1、2、3-RC2と等しいです: (S2、G1) パケット、Multicast Session MS2 1、2、OSL=3
Bourdon Experimental [Page 26] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[26ページ]RFC4045の効率的なマルチキャスト交通
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、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) パケット、Multicast Session MS1 1、2、3、OSL=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: 進めないパケット、全くMulticast Session MS2、OSL=(マルチキャストSession MS2は削除されるでしょう)
When user {4} leaves G1, the group state for the L2TP tunnel goes
back to:
ユーザ4がG1を残すとき、L2TPトンネルへのグループ状態は以下のことのために戻ります。
(G1, INCLUDE, {S1, S2})
(G1、インクルード、S1、S2)
Replication contexts become:
模写文脈はなります:
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
(Multicast Session MS2 is re-established)
-RC1: (S1、G1) パケット、Multicast Session MS1、OSLは1、2、3-RC2と等しいです: (S2、G1) パケット、Multicast Session MS2 1、2、OSL=3(マルチキャストSession MS2は復職します)
Author's Address
作者のアドレス
Gilles Bourdon France Telecom 38-40, rue du General Leclerc 92794 Issy les Moulineaux Cedex 9 - FRANCE
ジルBourdonフランステレコム38-40、悔悟duルクレール92794Issy les Moulineaux Cedex9司令官--フランス
Phone: +33 1 4529-4645 EMail: gilles.bourdon@francetelecom.com
以下に電話をしてください。 +33 1 4529-4645 メールしてください: gilles.bourdon@francetelecom.com
Bourdon Experimental [Page 27] RFC 4045 Efficient Multicast Traffic in L2TP April 2005
L2TP2005年4月の低音部音栓実験的な[27ページ]RFC4045の効率的なマルチキャスト交通
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Bourdon Experimental [Page 28]
低音部音栓実験的です。[28ページ]
一覧
スポンサーリンク
