Network Working Group R. Aggarwal, Ed.
Request for Comments: 4719 Juniper Networks
Category: Standards Track M. Townsley, Ed.
M. Dos Santos, Ed.
Cisco Systems
November 2006
Transport of Ethernet Frames over
Layer 2 Tunneling Protocol Version 3 (L2TPv3)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network.
このドキュメントでは、レイヤ2トンネリングプロトコル、バージョン3（L2TPv3の）上のイーサネットフレームの輸送について説明します。これは、イーサネットポートツーポートフレームの輸送、ならびにイーサネットVLANフレームの輸送を含みます。本書で説明されたメカニズムは、IPネットワーク上でイーサネットフレームを転送するスードワイヤの作成に使用することができます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
1.2. Abbreviations ..............................................3
1.3. L2TPv3 Control Message Types ...............................3
1.4. Requirements ...............................................3
2. PW Establishment ................................................4
2.1. LCCE-LCCE Control Connection Establishment .................4
2.2. PW Session Establishment ...................................4
2.3. PW Session Monitoring ......................................6
3. Packet Processing ...............................................7
3.1. Encapsulation .............................................7
3.2. Sequencing ................................................7
3.3. MTU Handling ..............................................7
4. Applicability Statement .........................................8
5. Congestion Control .............................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
8. Contributors ...................................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a control protocol and for data encapsulation to set up Pseudowires (PWs) for transporting layer 2 Packet Data Units across an IP network [RFC3931]. This document describes the transport of Ethernet frames over L2TPv3 including the PW establishment and data encapsulation.
レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）は、制御プロトコルとして、データのカプセル化は、IPネットワーク[RFC3931]を横切ってレイヤ2つのパケットデータユニットを搬送するためのスードワイヤ（のPW）を設定するために使用することができます。この文書では、PWの確立とデータのカプセル化を含むL2TPv3の上のイーサネットフレームの輸送について説明します。
The term "Ethernet" in this document is used with the intention to include all such protocols that are reasonably similar in their packet format to IEEE 802.3 [802.3], including variants or extensions that may or may not necessarily be sanctioned by the IEEE (including such frames as jumbo frames, etc.). The term "VLAN" in this document is used with the intention to include all virtual LAN tagging protocols such as IEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc.
この文書における用語「イーサネット」、又は必ずしもIEEEによって認可されていてもよい変異体または拡張を含む（含む[802.3] IEEE 802.3へのパケットフォーマットで適度に類似しているすべてのそのようなプロトコルを含むことを意図して使用されますジャンボフレーム、等）のようなフレーム。この文書における用語「VLAN」は、等IEEE 802.1Q [802.1Q]、802.1ad [802.1ad]、などのすべての仮想LANタギングプロトコルを含むことを意図して使用されます
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
AC Attachment Circuit (see [RFC3985]) CE Customer Edge (Typically also the L2TPv3 Remote System) LCCE L2TP Control Connection Endpoint (see [RFC3931]) NSP Native Service Processing (see [RFC3985]) PE Provider Edge (Typically also the LCCE) (see [RFC3985]) PSN Packet Switched Network (see [RFC3985]) PW Pseudowire (see [RFC3985]) PWE3 Pseudowire Emulation Edge to Edge (Working Group)
ACアタッチメント回路（[RFC3985]を参照）CEカスタマーエッジ（一般的にもL2TPv3のリモートシステム）LCCE L2TPコントロール接続のエンドポイント（[RFC3931]を参照）NSPネイティブサービス処理（[RFC3985]を参照）PEのプロバイダーエッジ（一般的にもLCCE） （[RFC3985]を参照）PSNパケットは、ネットワーク（[RFC3985]を参照）PW疑似回線（[RFC3985]を参照）PWE3擬似ワイヤエミュレーションエッジ縁に（ワーキンググループ）をスイッチ
Relevant L2TPv3 control message types (see [RFC3931]) are listed for reference.
関連のL2TPv3コントロールメッセージタイプは、参考のために記載されている（[RFC3931]参照します）。
SCCRQ L2TPv3 Start-Control-Connection-Request control message SCCRP L2TPv3 Start-Control-Connection-Reply control message SCCCN L2TPv3 Start-Control-Connection-Connected control message StopCCN L2TPv3 Stop-Control-Connection-Notification control message ICRQ L2TPv3 Incoming-Call-Request control message ICRP L2TPv3 Incoming-Call-Reply control message ICCN L2TPv3 Incoming-Call-Connected control message OCRQ L2TPv3 Outgoing-Call-Request control message OCRP L2TPv3 Outgoing-Call-Reply control message OCCN L2TPv3 Outgoing-Call-Connected control message CDN L2TPv3 Call-Disconnect-Notify control message SLI L2TPv3 Set-Link-Info control message
SCCRQ L2TPv3のスタートコントロール接続要求制御メッセージSCCRP L2TPv3のスタートコントロール接続返信制御メッセージSCCCN L2TPv3のスタートコントロール接続接続された制御メッセージStopCCN L2TPv3の停止コントロール接続通知制御メッセージICRQ L2TPv3の着信-Call-要求制御メッセージICRPのL2TPv3着信返信制御メッセージICCN L2TPv3の着信接続制御メッセージOCRQ L2TPv3の発信・通話要求制御メッセージOCRP L2TPv3の発信 - コール返信制御メッセージOCCN L2TPv3の発信、コール接続された制御メッセージCDNのL2TPv3コール外し-通知制御メッセージSLI L2TPv3の設定-リンク情報制御メッセージ
An Ethernet PW emulates a single Ethernet link between exactly two endpoints. The following figure depicts the PW termination relative to the NSP and PSN tunnel within an LCCE [RFC3985]. The Ethernet interface may be connected to one or more Remote Systems (an L2TPv3 Remote System is referred to as Customer Edge (CE) in this and associated PWE3 documents). The LCCE may or may not be a PE.
イーサネットPWは正確に2つのエンドポイント間の単一のイーサネットリンクをエミュレートします。次の図は、LCCE [RFC3985]内NSPとPSNトンネルにPW終端相対を示します。イーサネットインターフェイスは、1つまたは複数のリモートシステム（L2TPv3のリモート・システムはこれと関連PWE3ドキュメント内の顧客エッジ（CE）と呼ばれる）に接続されてもよいです。 LCCEは、またはPEであってもなくてもよいです。
+---------------------------------------+
| LCCE |
+-+ +-----+ +------+ +------+ +-+
|P| | | |PW ter| | PSN | |P|
Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
Interface |y| | | |on | | | |y|
+-+ +-----+ +------+ +------+ +-+
| |
+---------------------------------------+
Figure 1: PW termination
The PW termination point receives untagged (also referred to as 'raw') or tagged Ethernet frames and delivers them unaltered to the PW termination point on the remote LCCE. Hence, it can provide untagged or tagged Ethernet link emulation service.
PW終了ポイントがタグなしまたはタグ付けされたイーサネットフレーム（また、「生の」と称する）を受信し、リモートLCCEにPW終端点に変更されていないそれらを配信します。したがって、タグの付いていないか、タグ付きイーサネットリンクエミュレーション・サービスを提供することができます。
The "NSP" function includes packet processing needed to translate the Ethernet frames that arrive at the CE-LCCE interface to/from the Ethernet frames that are applied to the PW termination point. Such functions may include stripping, overwriting, or adding VLAN tags. The NSP functionality can be used in conjunction with local provisioning to provide heterogeneous services where the CE-LCCE encapsulations at the two ends may be different.
「NSP」機能は、PW終端点に適用されるイーサネットフレームから/へのCE-LCCEの界面に到達するイーサネットフレームを変換するために必要なパケットの処理を含みます。このような機能は、ストリッピング上書き、またはVLANタグを追加することを含むことができます。 NSP機能は両端CE-LCCEカプセル化が異なっていてもよく、異種のサービスを提供するために、ローカルプロビジョニングと組み合わせて使用することができます。
The physical layer between the CE and LCCE, and any adaptation (NSP) functions between it and the PW termination, are outside of the scope of PWE3 and are not defined here.
CEとLCCE、及びそれとPWの終了との間の適合（NSP）機能との間の物理層は、PWE3の範囲外であり、ここで定義されていません。
With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3 sessions. An L2TP Control Connection has to be set up first between the two LCCEs. Individual PWs can then be established as L2TP sessions.
トンネリングプロトコルとしてのL2TPv3では、イーサネットPWSがL2TPv3のセッションです。 L2TPコントロール接続は、2つのLCCEsの間で最初に設定する必要があります。個々のPWSが、その後L2TPセッションとして確立することができます。
The two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP Control Connection first as described in [RFC3931]. Hence, an Ethernet PW Type must be included in the Pseudowire Capabilities List as defined in [RFC3931]. The type of PW can be either "Ethernet port" or "Ethernet VLAN". This indicates that the Control Connection can support the establishment of Ethernet PWs. Note that there are two Ethernet PW Types required. For connecting an Ethernet port to another Ethernet port, the PW Type MUST be "Ethernet port"; for connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type MUST be "Ethernet VLAN".
[RFC3931]に記載されているように、イーサネットのPWを設定したい2つのLCCEsのは、最初のL2TP制御接続を確立しなければなりません。 [RFC3931]で定義されるため、イーサネット（登録商標）PWタイプスードワイヤ機能リストに含まれなければなりません。 PWの種類は、「イーサネットポート」または「イーサネットVLAN」のいずれかになります。これは、制御接続はイーサネットのPW設立をサポートできることを示しています。必要な2つのイーサネットPWの種類があることに注意してください。別のイーサネットポートにイーサネットポートを接続するために、PWタイプは、「イーサネットポート」でなければなりません。別のイーサネットVLANにイーサネットVLANを接続するために、PWタイプは、「イーサネットVLAN」でなければなりません。
The provisioning of an Ethernet port or Ethernet VLAN and its association with a PW triggers the establishment of an L2TP session via the standard Incoming Call three-way handshake described in Section 3.4.1 of [RFC3931].
イーサネットポートまたはイーサネットVLANとPWとの関連のプロビジョニングは、[RFC3931]のセクション3.4.1に記載された標準着信スリーウェイハンドシェイクを介してL2TPセッションの確立をトリガします。
Note that an L2TP Outgoing Call is essentially a method of controlling the originating point of a Switched Virtual Circuit (SVC), allowing it to be established from any reachable L2TP-enabled device able to perform outgoing calls. The Outgoing Call model and its corresponding OCRQ, OCRP, and OCCN control messages are mainly used within the dial arena with L2TPv2 today and has not been found applicable for PW applications yet.
L2TP発信コールは、本質的に、それが発信コールを行うことができる任意の到達可能L2TP対応デバイスから確立されることを可能にする、スイッチドバーチャル回路（SVC）の発信点を制御する方法であることに留意されたいです。発信モデルとそれに対応するOCRQ、OCRP、およびOCCN制御メッセージは、主に、今日L2TPv2でダイヤルアリーナ内で使用されていると、まだPWアプリケーションには適用見出されていません。
The following are the signaling elements needed for the Ethernet PW establishment:
以下は、イーサネットPWの確立のために必要なシグナリング要素です：
a) Pseudowire Type: The type of a Pseudowire can be either "Ethernet port" or "Ethernet VLAN". Each LCCE signals its Pseudowire type in the Pseudowire Type AVP [RFC3931]. The assigned values for "Ethernet port" and "Ethernet VLAN" Pseudowire types are captured in the "IANA Considerations" of this document. The Pseudowire Type AVP MUST be present in the ICRQ.
a）は疑似回線の種類：擬似回線の種類は、「イーサネットポート」または「イーサネットVLAN」のいずれかになります。各LCCEは、疑似回線タイプAVP [RFC3931]での疑似回線の種類を知らせます。 「イーサネットポート」および「イーサネットVLAN」擬似回線の種類の割り当てられた値は、このドキュメントの「IANAの考慮事項」に取り込まれます。擬似回線タイプAVPはICRQに存在しなければなりません。
b) Pseudowire ID: Each PW is associated with a Pseudowire ID. The two LCCEs of a PW have the same Pseudowire ID for it. The Remote End Identifier AVP [RFC3931] is used to convey the Pseudowire ID. The Remote End Identifier AVP MUST be present in the ICRQ in order for the remote LCCE to determine the PW to associate the L2TP session with. An implementation MUST support a Remote End Identifier of four octets known to both LCCEs either by manual configuration or some other means. Additional Remote End Identifier formats that MAY be supported are outside the scope of this document.
b）の疑似回線ID：各PWは、疑似回線IDに関連付けられています。 PWの2つのLCCEsのは、それのために同じ擬似回線のIDを持っています。リモートエンド識別子AVP [RFC3931]は擬似回線のIDを伝えるために使用されます。リモートエンド識別子AVPは、とのL2TPセッションを関連付けるためにPWを決定するために、リモートLCCEためにICRQに存在しなければなりません。実装は、両方のLCCEsに手動設定または他の手段によって知られている4つのオクテットのリモートエンド識別子をサポートしなければなりません。サポートされるかもしれ追加のリモートエンド識別子フォーマットは、このドキュメントの範囲外です。
c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP to indicate the circuit status of the Ethernet port or Ethernet VLAN. For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the circuit status is for a new circuit (refer to N bit in Section 2.3.3). An implementation MAY send an ICRQ or ICRP before an Ethernet interface is ACTIVE, as long as the Circuit Status AVP (refer to A bit in Section 2.3.3) in the ICRQ or ICRP reflects the correct status of the Ethernet port or Ethernet VLAN link. A subsequent circuit status change of the Ethernet port or Ethernet VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI control messages. For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP MUST indicate that the circuit status is for an existing circuit (refer to N bit in Section 2.3.3) and reflect the current status of the link (refer to A bit in Section 2.3.3).
C）回路状態AVP [RFC3931]は、イーサネットポートまたはイーサネットVLANの回路状態を示すためにICRQとICRPに含まれなければなりません。 ICRQとICRPのために、回路の状態AVPは、回路の状態は、新しい回路（2.3.3項にNビットを参照）のためのものであることを示す必要があります。イーサネットインターフェイスがアクティブになる前に、回線状態AVPはICRQ中（セクション2.3.3にビットを参照）やICRPは、イーサネットポートまたはイーサネットVLANリンクの正確な状況を反映しているような実装は、限り、ICRQかICRPを送るかもしれません。イーサネットポートまたはイーサネットVLANの後段の回路の状態変化はICCNまたはSLI制御メッセージにおける回路状態AVPに運ばれなければなりません。 ICCNとSLI（セクション2.3.2を参照）のため、回線状態AVPは、回路状態が既存の回路のためのものであることを示している（セクション2.3.3にNビットを参照）、リンクの現在の状態を反映しなければならない（参照してください2.3.3項ではビット）。
The working status of a PW is reflected by the state of the L2TPv3 session. If the corresponding L2TPv3 session is down, the PW associated with it MUST be shut down. The Control Connection keep-alive mechanism of L2TPv3 can serve as a link status monitoring mechanism for the set of PWs associated with a Control Connection.
PWの作動状態がL2TPv3のセッションの状態によって反射されます。対応のL2TPv3セッションがダウンしている場合は、それに関連付けられたPWをシャットダウンする必要があります。 L2TPv3のの制御接続キープアライブメカニズムは、制御接続に関連付けられているのPWセットのリンクステータスの監視機構として機能することができます。
In addition to the Control Connection keep-alive mechanism of L2TPv3, Ethernet PW over L2TP makes use of the Set-Link-Info (SLI) control message defined in [RFC3931]. The SLI message is used to signal Ethernet link status notifications between LCCEs. This can be useful to indicate Ethernet interface state changes without bringing down the L2TP session. Note that change in the Ethernet interface state will trigger an SLI message for each PW associated with that Ethernet interface. This may be one Ethernet port PW or more than one Ethernet VLAN PW. The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exception to this is the initial ICRQ, ICRP, and CDN messages that establish and tear down the L2TP session itself. The SLI message may be sent from either LCCE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup).
L2TPv3のの制御接続キープアライブメカニズムに加えて、L2TPオーバーイーサネットPWは[RFC3931]で定義されたセットリンク情報（SLI）制御メッセージを利用します。 SLIメッセージがLCCEsの間のイーサネットリンク状態通知を通知するために使用されます。これは、L2TPセッションをダウンさせずに、イーサネットインターフェイスの状態変化を示すのに役立ちます。そのイーサネットインターフェイスに関連付けられた各PW用のSLIメッセージをトリガするイーサネットインタフェース状態でその変化に注意してください。これは、1つのイーサネットポートPWまたは複数のイーサネットVLAN PWかもしれません。 SLIメッセージは、回線状態AVPで特定された値の状態変化がある任意の時間を送らなければなりません。これに対する唯一の例外は、確立し、L2TPセッション自体を取り壊す初期ICRQ、ICRP、およびCDNメッセージです。最初ICRQが送信され（及びICRPが受信される前に、おそらく、逆セッションIDルックアップを実行するためにピアを必要とする）した後、SLIメッセージは、任意の時点でいずれかからLCCE送信されてもよいです。
Ethernet PW reports circuit status with the Circuit Status AVP defined in [RFC3931]. For reference, this AVP is shown below:
イーサネットPWは[RFC3931]で定義された回路状態AVPと回路の状態を報告します。参考のために、このAVPは、以下に示されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16-bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 when sending and ignored upon receipt.
値は、定義された2つの最下位ビットと、将来の使用のために予約残りのビットと16ビット・マスクです。予約ビットは、送信時に0に設定し、受信時に無視しなければなりません。
The A (Active) bit indicates whether the Ethernet interface is ACTIVE (1) or INACTIVE (0).
A（アクティブ）ビットイーサネットインターフェイスは、（1）アクティブまたは非アクティブ（0）であるかどうかを示します。
The N (New) bit indicates whether the circuit status is for a new (1) Ethernet circuit or an existing (0) Ethernet circuit.
N（新規）ビットは、回路状態が新しい（1）イーサネット回路または既存の（0）イーサネット回路のためのものであるかどうかを示します。
The encapsulation described in this section refers to the functionality performed by the PW termination point depicted in Figure 1, unless otherwise indicated.
特に明記しない限り、このセクションで説明したカプセル化は、図1に示すPW終了ポイントによって実行される機能を指します。
The entire Ethernet frame, without the preamble or frame check sequence (FCS), is encapsulated in L2TPv3 and is sent as a single packet by the ingress LCCE. This is done regardless of whether or not a VLAN tag is present in the Ethernet frame. For Ethernet port-to-port mode, the remote LCCE simply decapsulates the L2TP payload and sends it out on the appropriate interface without modifying the Ethernet header. For Ethernet VLAN-to-VLAN mode, the remote LCCE MAY rewrite the VLAN tag. As described in Section 1, the VLAN tag modification is an NSP function.
全体イーサネットフレームは、プリアンブルまたはフレームチェックシーケンス（FCS）を含まない、L2TPv3の中に封入されており、入口LCCEによって単一パケットとして送信されます。これは関係なく、VLANタグは、イーサネットフレーム内に存在するか否かの行われます。イーサネットポートツーポートモードの場合、リモートLCCEは単にL2TPペイロードをデカプセル化し、イーサネットヘッダを変更することなく、適切なインターフェイスに送出します。イーサネットVLANツーVLANモードでは、リモートLCCEは、VLANタグを書き換えるかもしれません。セクション1で説明したように、VLANタグ修飾はNSP関数です。
The Ethernet PW over L2TP is homogeneous with respect to packet encapsulation, i.e., both ends of the PW are either untagged or tagged. The Ethernet PW can still be used to provide heterogeneous services using NSP functionality at the ingress and/or egress LCCE. The definition of such NSP functionality is outside the scope of this document.
L2TPオーバーイーサネットPW、すなわち、PWの両端がタグなしまたはタグ付けされたいずれかである、パケットのカプセル化に対して均質です。イーサネットPWはまだ入口および/または出口LCCEでNSPの機能を使用して異種のサービスを提供するために使用することができます。このようNSPの機能性の定義は、この文書の範囲外です。
The maximum length of the Ethernet frame carried as the PW payload is irrelevant as far as the PW is concerned. If anything, that value would only be relevant when quantifying the faithfulness of the emulation.
PWペイロードとして運ばイーサネットフレームの最大長さは限りPWが懸念しているように無関係です。どちらかといえばエミュレーションの忠実を定量化する場合、その値は唯一の関連になります。
Data packet sequencing MAY be enabled for Ethernet PWs. The sequencing mechanisms described in [RFC3931] MUST be used for signaling sequencing support.
データパケットの順序は、イーサネットPWのために有効にすることができます。 [RFC3931]に記載され配列決定メカニズムは、配列決定サポートをシグナリングするために使用されなければなりません。
With L2TPv3 as the tunneling protocol, the IP packet resulting from the encapsulation is M + N bytes longer than the Ethernet frame without the preamble or FCS. Here M is the length of the IP header along with associated options and extension headers, and the value of N depends on the following fields:
トンネリングプロトコルとしてのL2TPv3と共に、カプセル化に起因するIPパケットは、M + Nはプリアンブル又はFCSなしのイーサネットフレームよりも長いバイトです。ここでMは、関連するオプションおよび拡張ヘッダと共にIPヘッダの長さであり、Nの値は、次のフィールドに依存します。
L2TP Session Header: Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) Session ID - 4 octets Cookie Size - 0, 4, or 8 octets L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing)
L2TPセッションヘッダー：フラグ、版、RES - 4つのオクテット（UDP上のL2TPv3のみ）セッションID - 4つのオクテットクッキーサイズ - 0,4、又は8つのオクテットL2特有のSublayer - 0または4オクテット（すなわち、配列決定を使用して）
Hence the range for N in octets is:
N = 4-16, for L2TPv3 data messages over IP;
N = 16-28, for L2TPv3 data messages over UDP;
(N does not include the IP header).
Fragmentation in the PSN can occur when using Ethernet over L2TP, unless proper configuration and management of MTU sizes are in place between the Customer Edge (CE) router and Provider Edge (PE) router, and across the PSN. This is not specific only to Ethernet over L2TPv3, and the base L2TPv3 specification [RFC3931] provides general recommendations with respect to fragmentation and reassembly in Section 4.1.4. "PWE3 Fragmentation and Reassembly" [RFC4623] expounds on this topic, including a fragmentation and reassembly mechanism within L2TP itself in the event that no other option is available. Implementations MUST follow these guidelines with respect to fragmentation and reassembly.
イーサネットを使用する場合にMTUサイズの適切な構成および管理は、顧客エッジ（CE）ルータとプロバイダエッジ（PE）ルータ間、およびPSNを横切って所定の位置にない限り、PSNにフラグメンテーションは、L2TP上に起こり得ます。これはL2TPv3のオーバーイーサネットに特定されず、ベースのL2TPv3仕様[RFC3931]は、セクション4.1.4におけるフラグメンテーション及び再組み立てに関して一般的な推奨事項を提供します。 「PWE3断片化と再アセンブリ」[RFC4623]は、他のオプションが利用可能でない場合にはL2TP自体の内部フラグメンテーションと再組立機構を備え、このトピックについて解説し。実装は断片化と再組み立てに関して、これらのガイドラインに従わなければなりません。
The Ethernet PW emulation allows a service provider to offer a "port-to-port"-based Ethernet service across an IP Packet Switched Network (PSN), while the Ethernet VLAN PW emulation allows an "VLAN-to-VLAN"-based Ethernet service across an IP Packet Switched Network (PSN).
イーサネットVLAN PWエミュレーションは「VLANツーVLAN」を可能にしながら、イーサネットPWエミュレーションは、IPパケットを横切って「ポート・ツー・ポート」ベースのイーサネットサービスを提供するサービスプロバイダがネットワーク（PSN）を交換可能ベースイーサネットIPパケット全体のサービスは、ネットワーク（PSN）を交換しました。
The Ethernet or Ethernet VLAN PW emulation has the following characteristics in relationship to the respective native service:
イーサネットまたはイーサネットVLAN PWエミュレーションでは、それぞれのネイティブサービスとの関係で次のような特徴があります。
o Ethernet PW connects two Ethernet port ACs, and Ethernet VLAN PW connects two Ethernet VLAN ACs, which both support bi-directional transport of variable-length Ethernet frames. The ingress LCCE strips the preamble and FCS from the Ethernet frame and transports the frame in its entirety across the PW. This is done regardless of the presence of the VLAN tag in the frame. The egress LCCE receives the Ethernet frame from the PW and regenerates the preamble and FCS before forwarding the frame to the attached Remote System (see Section 3.1). Since FCS is not being transported across either Ethernet or Ethernet VLAN PWs, payload integrity transparency may be lost. To achieve payload integrity transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can utilize IPsec as specified in Section 4.1.3 of [RFC3931].
OイーサネットPWは、2つのイーサネットポートACSを接続し、イーサネットVLAN PWは、可変長イーサネットフレームの双方向転送をサポートし、両方の2つのイーサネットVLAN ACSを、接続しています。入口LCCEは、イーサネットフレームからプリアンブルとFCSを取り除き、PWを横切るその全体がフレームを搬送します。これは、フレーム内のVLANタグの有無にかかわらず行われます。出口LCCEがPWからイーサネットフレームを受信し、添付のリモートシステムへフレームを転送する前にプリアンブルとFCSを再生する（セクション3.1を参照）。 FCSはイーサネットまたはイーサネットVLANのPWを横切って輸送されていないので、ペイロードの整合性透明性が失われる可能性があります。 [RFC3931]のセクション4.1.3で指定されたUDP / IP上でIPまたはL2TP上でL2TPを使用して、イーサネットまたはイーサネットVLAN PWを上のペイロードの整合性、透明性を達成するために、L2TPv3のセッションは、IPsecを利用することができます。
o While architecturally [RFC3985] outside the scope of the L2TPv3 PW itself, if VLAN tags are present, the NSP may rewrite VLAN tags on ingress or egress from the PW (see Section 3.1).
VLANタグが存在する場合、OのL2TPv3 PW自体の範囲外アーキテクチャ[RFC3985]は、NSPがPWからの入力または出力にVLANタグを書き換えることができるが（セクション3.1を参照）。
o The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet frame type across the PW; both ends of the PW must be either tagged or untagged. Heterogeneous frame type support achieved with NSP functionality is outside the scope of this document (see Section 3.1).
OイーサネットまたはイーサネットVLAN PWのみPWを横切る均一なイーサネットフレームタイプをサポートします。 PWの両端には、タグ付きまたはタグなしのいずれかでなければなりません。 NSP機能で達成異種フレームタイプのサポートは、この文書の範囲外である（3.1節を参照）。
o Ethernet port or Ethernet VLAN status notification is provided using the Circuit Status AVP in the SLI message (see Sections 2.3.2 and 2.3.3). Loss of connectivity between LCCEs can be detected by the L2TPv3 keep-alive mechanism (see Section 2.3.1 of this document and Section 4.4 of [RFC3931]). The LCCE can convey these indications back to its attached Remote System.
OイーサネットポートまたはイーサネットVLAN状態通知は、（セクション2.3.2および2.3.3を参照）SLIメッセージにおける回路状態AVPを使用して提供されます。 LCCEsの間の接続の損失はL2TPv3のキープアライブ機構によって検出することができる（このドキュメントと[RFC3931]のセクション4.4のセクション2.3.1を参照）。 LCCEはその付属リモートシステムにこれらの指示をバック伝えることができます。
o The maximum frame size that can be supported is limited by the PSN MTU minus the L2TPv3 header size, unless fragmentation and reassembly is used (see Section 3.3 of this document and Section 4.1.4 of [RFC3931]).
フラグメンテーションと再構成が使用されていない限りoを支持することができる最大フレームサイズは、（[RFC3931]この文書およびセクション4.1.4のセクション3.3を参照）、PSN MTUマイナスのL2TPv3ヘッダのサイズによって制限されます。
o The Packet Switched Network may reorder, duplicate, or silently drop packets. Sequencing may be enabled in the Ethernet or Ethernet VLAN PW for some or all packets to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 3.2).
Oパケットは、ネットワークが、並べ替え、複製、または静かにパケットをドロップすることができるスイッチ。配列決定は、失われた検出複製、またはアウトオブオーダーパケットセッションごとに（3.2節を参照）し、一部またはすべてのパケットのためのイーサネットまたはイーサネットVLAN PWで有効にすることができます。
o The faithfulness of an Ethernet or Ethernet VLAN PW may be increased by leveraging Quality-of-Service (QoS) features of the LCCEs and the underlying PSN. For example, for Ethernet 802.1Q [802.1Q] VLAN transport, the ingress LCCE MAY consider the user priority field (i.e., 802.1p) of the VLAN tag for traffic classification and QoS treatments, such as determining the Differentiated Services (DS) field [RFC2474] of the encapsulating IP header. Similarly, the egress LCCE MAY consider the DS field of the encapsulating IP header when rewriting the user priority field of the VLAN tag or queuing the Ethernet frame before forwarding the frame to the Remote System. The mapping between the user priority field and the IP header DS field as well as the Quality-of-Service model deployed are application specific and are outside the scope of this document.
OイーサネットまたはイーサネットVLAN PWの忠実は、サービス品質（QoS）のLCCEsの特徴および下地PSNを活用することによって増加させることができます。たとえば、イーサネット802.1Q [802.1Q] VLANの輸送のために、入口LCCEは、トラフィックの分類と、そのような差別化サービスを決定するようにQoS処理、（DS）フィールドにVLANタグのユーザプライオリティフィールド（すなわち、802.1P）を検討することができますカプセル化IPヘッダの[RFC2474]。 VLANタグのユーザプライオリティフィールドを書き換えるまたはリモートシステムにフレームを転送する前にイーサネットフレームをキューイングするとき同様に、出口LCCEは、カプセル化IPヘッダのDSフィールドを考慮することができます。ユーザ優先度フィールド及びIPヘッダのDSフィールドとの間のマッピング、並びに展開サービス品質モデルは、アプリケーション固有であり、この文書の範囲外です。
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, with congestion characteristics depending on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or Ethernet VLAN PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914] and thus consume more than their fair share.
[RFC3985]で説明したように、PWを運ぶPSNは、輻輳特性がPSNのタイプ、ネットワークアーキテクチャ、構成、および負荷に依存して、混雑を受けることができます。混雑時には、PSNは、イーサネットまたはイーサネットVLAN PWで運ばサービスに影響を与えるパケット損失を示すことができます。また、イーサネットまたはイーサネットVLAN PWをするので含め、PSNの向こう様々なサービスを運ぶが、TCP / IPに限らず、彼らは、または[RFC2914]によって定められたTCPに優しい方法で動作し、したがって、より多くを消費しない場合があり、その公正な取り分。
Whenever possible, Ethernet or Ethernet VLAN PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the Ethernet or Ethernet VLAN PW's effects from neighboring streams.
可能な限り、イーサネットまたはイーサネットVLAN PWSが、帯域幅の割り当てと入場制御メカニズムを提供するトラフィックエンジニアリングのPSN上で実行する必要があります。 EF（優先転送）を使用して保証サービス（GS）またはDiffServの対応のドメインを提供イントサーブ対応のドメインは、トラフィックエンジニアリングのPSNの例です。イーサネットまたは隣接するストリームからのイーサネットVLAN PWの効果の分離をある程度提供しながら、このようなのPSNは、損失および遅延を最小化します。
LCCEs SHOULD monitor for congestion (by using explicit congestion notification or by measuring packet loss) in order to ensure that the service using the Ethernet or Ethernet VLAN PW may be maintained. When severe congestion is detected (for example, when enabling sequencing and detecting that the packet loss is higher than a threshold), the Ethernet or Ethernet VLAN PW SHOULD be halted by tearing down the L2TP session via a CDN message. The PW may be restarted by manual intervention or by automatic means after an appropriate waiting time. Note that the thresholds and time periods for shutdown and possible automatic recovery need to be carefully configured. This is necessary to avoid loss of service due to temporary congestion and to prevent oscillation between the congested and halted states.
LCCEsの輻輳のために（明示的輻輳通知を使用して、またはパケット損失を測定することによって）イーサネットまたはイーサネットVLAN PWを使用してサービスを維持することができることを保証するために監視する必要があります。重度の輻輳が検出された場合（例えば、シークエンシングを可能にし、パケット損失が閾値よりも高いことを検出した場合、）、イーサネットまたはイーサネットVLAN PWは、CDNメッセージを介してL2TPセッションを切断することによって停止されるべきです。 PWは適切な待ち時間の後に手動の介入により、または自動手段によって再起動することができます。シャットダウンし、可能な自動復旧のためのしきい値と期間を慎重に設定する必要があることに注意してください。これは一時的な混雑にサービスの損失を回避し、混雑と停止状態の間で発振を防止する必要があります。
This specification offers no congestion control and is not TCP friendly [TFRC]. Future works for PW congestion control (being studied by the PWE3 Working Group) will provide congestion control for all PW types including Ethernet and Ethernet VLAN PWs.
この仕様は、輻輳制御を提供しないと、[TFRC]優しいTCPされていません。 PWの輻輳制御（PWE3ワーキンググループによって研究されている）のための今後の課題は、イーサネットとイーサネットVLAN PWを含むすべてのPWタイプのための輻輳制御を提供します。
Ethernet over L2TPv3 is subject to all of the general security considerations outlined in [RFC3931].
L2TPv3の上のイーサネットは、[RFC3931]に概説した一般的なセキュリティ上の考慮事項の全てを受けます。
The signaling mechanisms defined in this document rely upon the following Ethernet Pseudowire Types (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]), which were allocated by the IANA (number space created as part of publication of [RFC3931]):
IANAによって割り当てられた、（数空間本書で定義されたシグナリングメカニズムは、次のイーサネット疑似回線の種類に依存する（[RFC3931]の10.6の[RFC3931]とのL2TPv3疑似回線タイプの5.4.3に定義されるような疑似回線の能力リストを参照） [RFC3931]）の出版物の一部として作成されました。
Pseudowire Types
----------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type
The following is the complete list of contributors to this document.
以下は、この文書への貢献者の完全なリストです。
Rahul Aggarwal Juniper Networks
ラウール・アガーウォールジュニパーネットワークス
Xipeng Xiao Riverstone Networks
Xipengシャオリバーストーン・ネットワーク
W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems
W.マークTownsleyスチュワートブライアント・マリア・アリス・ドス・サントスシスコシステムズ
Cheng-Yin Lee Alcatel
チェン観音リーアルカテル
Tissa Senevirathne Consultant
ティッサSenevirathneコンサルタント
Mitsuru Higashiyama Anritsu Corporation
みつる ひがしやま あんりつ こｒぽらちおん
This RFC evolved from the document, "Ethernet Pseudo Wire Emulation Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L. Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron for their contribution. We would also like to thank S. Nanji, the author of "Ethernet Service for Layer Two Tunneling Protocol", for writing the first Ethernet over L2TP document.
このRFCは、ドキュメント、「イーサネット疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ」から進化しました。私たちは、彼らの貢献のためにその著者、T.So、X.Xiao、L.アンダーソン、C.フローレス、N.チンクル、S. Khandekar、D.カメレオンマンおよびG.サギに感謝したいと思います。我々はまた、L2TPドキュメント上に第一のイーサネットを書くために、S.蘭芝、「レイヤ2トンネリングプロトコル用のイーサネット・サービス」の著者に感謝したいと思います。
Thanks to Carlos Pignataro for providing a thorough review and helpful input.
徹底的な見直しと役立つ入力を提供するためのカルロスPignataroに感謝します。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"、RFC 3931、2005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623] Malis、A.およびM. Townsley、 "擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）フラグメンテーションおよび再構成"、RFC 4623、2006年8月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[802.3] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for Information Technology - Telecommuincations and Information Exchange Between Systems - Local and Metropolitan Area Networks", IEEE Std 802.3-2005/Cor 1-2006 (Corrigendum to IEEE Std 802.3-2005)
[802.3] IEEE、 "IEEEは、情報技術のための802.3 -2005 /コリント1-2006 IEEEのStd - 地方とメトロポリタンエリアネットワーク - システム間Telecommuincationsと情報交換" IEEEにIEEE規格802.3から2005 / 1-2006コリントに、（正誤表をSTD 802.3-2005）
[802.1Q] IEEE, "IEEE standard for local and metropolitan area networks virtual bridged local area networks", IEEE Std 802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE Std 802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 802.1s-2002)
[802.1Q] IEEE、 "ローカルおよびメトロポリタンエリアネットワークのためのIEEE標準仮想ブリッジローカルエリアネットワーク"、IEEE標準802.1Q-2005（IEEE STD 802.1Q1998、IEEE STDの802.1u-2001、IEEE STDの802.1v-2001を内蔵し、 IEEE STD 802.1-2002）
[802.1ad] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE Std 802.1ad-2005 (Amendment to IEEE Std 8021Q-2005)
[802.1ad] IEEE、 "IEEE STDの802.1ad - ローカルおよびメトロポリタンエリアネットワーク2005 IEEE標準 - 仮想ブリッジローカルエリアネットワーク、修正4：プロバイダ・ブリッジ"、IEEE STDの802.1ad-2005（IEEE STD 8021Q-2005の修正）
[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
【TFRC]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
Author Information
著者の情報
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089
EMail: rahul@juniper.net
メールアドレス：rahul@juniper.net
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークTownsleyシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709
EMail: mark@townsley.net
メールアドレス：mark@townsley.net
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134
マリア・アリス・ドス・サントスシスコシステムズ170 Wタスマン博士サンノゼ、CA 95134
EMail: mariados@cisco.com
メールアドレス：mariados@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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, THE IETF TRUST, 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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。