[要約] RFC 4719は、L2TPv3を使用してイーサネットフレームを転送するためのプロトコル仕様です。このRFCの目的は、L2TPv3を使用してイーサネットフレームをトンネリングするための手順と要件を定義することです。
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)
レイヤー2トンネルプロトコルバージョン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).
Copyright（c）The IETF Trust（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ネットワーク全体でレイヤー2パケットデータユニットを輸送するための擬似動物（PW）をセットアップすることができます[RFC3931]。このドキュメントでは、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 [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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 pseudowire（[rfc3985]を参照）pwe3 pseudowireエミュレーションエッジ（ワーキンググループ）
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 START-CONTOL-CONNECTION-REQUESTコントロールメッセージSCCRP L2TPV3 START-CONTOL-CONNECTION-REPLY CONTROL CONTROLION MESSING SCCCN L2TPV3 START-CONTOL-CONNECTION-CONNECTED CONTROLE MESSOPCCN L2TPV3 STOT-CONTROL-CONNECTION-NOTIFIITIOUN CONTROLメッセージICRQリクエスト制御メッセージICRP L2TPV3着信 - コールリプリーコントロールメッセージICCN L2TPV3着信コール接続コントロールメッセージOCRQ L2TPV3 OUNVERVENG-CALL-REQUESTコントロールメッセージOCRP L2TPV3call-disconnect-notifyコントロールメッセージsli l2tpv3 set-link-infoコントロールメッセージ
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ターミネーションポイントは、タグなし（「raw」とも呼ばれる）またはタグ付きイーサネットフレームを受信し、リモート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機能は、ローカルプロビジョニングと組み合わせて使用して、2つの端での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の間の物理層、およびITと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をトンネリングプロトコルとして、イーサネットPWはL2TPV3セッションです。L2TP制御接続を最初に2つのLCCEの間に設定する必要があります。その後、個々のPWは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]に記載されているように、イーサネットPWSをセットアップしたい2つのLCCEは、最初に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で説明されている標準の着信3方向握手を介して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発信コールは、本質的にスイッチ付き仮想回路（SVC）の発信ポイントを制御する方法であり、発信コールを実行できる範囲のL2TP対応デバイスから確立できることに注意してください。発信コールモデルとその対応する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) PSEUDOWIRE TYPE：擬似ワイヤのタイプは、「イーサネットポート」または「イーサネット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) PSEUDOWIRE ID：各PWは、擬似ワイヤーIDに関連付けられています。PWの2つのLCCEには、同じ擬似ワイヤーIDがあります。リモートエンド識別子AVP [RFC3931]を使用して、Pseudowire IDを伝えます。リモートLCCEがPWを決定するためにL2TPセッションを関連付けるために、リモートエンド識別子AVPがICRQに存在する必要があります。実装は、手動構成または他の手段のいずれかで両方のLCCEに知られている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]をICRQおよびICRPに含めて、イーサネットポートまたはイーサネットVLANの回路状態を示す必要があります。ICRQおよびICRPの場合、回路ステータスAVPは、回路ステータスが新しい回路用であることを示す必要があります（セクション2.3.3のNビットを参照）。ICRQまたはICRPの回路ステータスAVP（セクション2.3.3で少し参照）がイーサネットポートまたはイーサネット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の制御接続キープアライブメカニズムは、制御接続に関連付けられたPWSのセットのリンクステータス監視メカニズムとして機能します。
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).
L2TP3のコントロール接続のキープアライブメカニズムに加えて、L2TPを介したイーサネットPWは、[RFC3931]で定義されたSet-Link-INFO（SLI）コントロールメッセージを利用しています。SLIメッセージは、LCCE間のイーサネットリンクステータス通知を信号するために使用されます。これは、L2TPセッションを倒さずにイーサネットインターフェイスの状態の変更を示すのに役立ちます。イーサネットインターフェイス状態の変更は、そのイーサネットインターフェイスに関連付けられた各PWのSLIメッセージをトリガーすることに注意してください。これは、1つのイーサネットポートPWまたは複数のイーサネットVLAN PWです。SLIメッセージは、回路ステータスAVPで識別される値のステータス変更がある場合はいつでも送信する必要があります。これの唯一の例外は、L2TPセッション自体を確立および解体する最初のICRQ、ICRP、およびCDNメッセージです。SLIメッセージは、最初のICRQが送信された後（およびおそらくICRPが受信される前にいつでも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.
値は16ビットマスクで、2つの最も有意なビットが定義されており、残りのビットは将来の使用のために予約されています。予約ビットは、受領時に送信して無視するときに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にカプセル化され、Ingress LCCEによって単一のパケットとして送信されます。これは、VLANタグがイーサネットフレームに存在するかどうかに関係なく行われます。イーサネットポートからポートモードの場合、リモートLCCEはL2TPペイロードを単純に脱カプセル化し、イーサネットヘッダーを変更せずに適切なインターフェイスに送信します。イーサネットVLAN-to-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.
イーサネットPWSでは、データパケットシーケンスが有効になる場合があります。[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パケットは、プリアンブルまたは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セッションヘッダー：フラグ、Ver、RES -4オクテット（UDPのみのL2TPV3）セッションID -4オクテットCookieサイズ-0、4、または8オクテットL2固有のサブレーヤー-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).
したがって、オクテットのnの範囲は次のとおりです。N= 4-16、IP上のL2TPV3データメッセージの場合。n = 16-28、UDP上のL2TPV3データメッセージの場合。（nにはIPヘッダーが含まれていません）。
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.
PSNの断片化は、customer edge（CE）ルーターとプロバイダーエッジ（PE）ルーターの間にMTUサイズの適切な構成と管理が整っていない限り、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).
イーサネット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を接続します。これらはどちらも可変長イーサネットフレームの双方向輸送をサポートします。Ingress LCCEは、イーサネットフレームからプリアンブルとFCをストリップし、PW全体でフレームを完全に輸送します。これは、フレーム内のVLANタグの存在に関係なく行われます。出力LCCEは、PWからイーサネットフレームを受信し、接続されたリモートシステムにフレームを転送する前にプリアンブルとFCSを再生します（セクション3.1を参照）。FCSはイーサネットまたはイーサネットVLAN PWのいずれにも輸送されていないため、ペイロードの整合性の透明性が失われる可能性があります。UDP/IPを介してL2TPまたはL2TPを使用してイーサネットまたはイーサネットVLAN PWSのペイロード整合性の透明性を達成するために、L2TPV3セッションは[RFC3931]のセクション4.1.3で指定されている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).
o L2TPV3 PW自体の範囲外で建築的に[RFC3985]が、VLANタグが存在する場合、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ステータス通知は、SLIメッセージの回路ステータスAVPを使用して提供されます（セクション2.3.2および2.3.3を参照）。LCCE間の接続の喪失は、L2TPV3キープアリブメカニズムによって検出できます（このドキュメントのセクション2.3.1および[RFC3931]のセクション4.4を参照）。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 サポートできる最大フレームサイズは、断片化と再組み立てを使用しない限り、PSN MTUからL2TPV3ヘッダーサイズを差し引いて制限されます（このドキュメントのセクション3.3および[RFC3931]のセクション4.1.4を参照）。
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 パケットスイッチネットワークは、パケットを再注文、複製、または静かにドロップする場合があります。セッションごとに紛失、重複、またはオーダーアウトオブオブオブオブパケットを検出するために、一部またはすべてのパケットのイーサネットまたはイーサネットVLAN PWでシーケンスを有効にすることができます（セクション3.2を参照）。
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の忠実さは、LCCEと基礎となるPSNのサービス品質（QOS）機能を活用することにより、増加する可能性があります。たとえば、イーサネット802.1Q [802.1Q] VLANトランスポートの場合、Ingress LCCEは、分化したサービス（DS）フィールドの決定など、トラフィック分類およびQoS治療のためのVLANタグのユーザー優先フィールド（すなわち802.1p）を考慮することができます。[RFC2474]カプセル化IPヘッダーの。同様に、Egress LCCEは、VLANタグのユーザーの優先度フィールドを書き換えたり、イーサネットフレームをキューにしてから、フレームをリモートシステムに転送する際に、カプセル化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は、TCP/IPに限定されていないが制限されていないPSN全体でさまざまなサービスを提供しているため、[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 PWは、帯域幅の割り当てと入学制御メカニズムを提供するトラフィックエンジニアリングPSNSを介して実行する必要があります。EF（Expedited Forwarding）を使用して保証されたサービス（GS）またはDiffServ対応ドメインを提供するIntServ対応ドメインは、トラフィックエンジニアリングPSNSの例です。このようなPSNSは、隣接するストリームからのイーサネットまたはイーサネットVLAN PWの効果をある程度分離しながら、損失と遅延を最小限に抑えます。
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.
LCCEは、イーサネットまたはイーサネット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.
この仕様は輻輳制御を提供せず、TCPフレンドリーではありません[TFRC]。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]):
このドキュメントで定義されているシグナル伝達メカニズムは、次のイーサネット擬似型タイプに依存しています（[RFC3931]の5.4.3で定義されている擬似能力リストを参照し、[RFC3931]の10.6のL2TPV3擬似型タイプを参照）。[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
Rahul Aggarwal Juniper Networks
Xipeng Xiao Riverstone Networks
Xipeng Xiao Riverstoneネットワーク
W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems
W.マークタウンズリースチュワートブライアントマリアアリスドスサントスシスコシステム
Cheng-Yin Lee Alcatel
チェン・イン・リー・アルカテル
Tissa Senevirathne Consultant
Tissa 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。Anderson、C。Flores、N。Tingle、S。Khandekar、D。Zelig、G。Heronの貢献に感謝します。また、L2TPドキュメントを介して最初のイーサネットを作成してくれた「レイヤー2トンネリングプロトコルのイーサネットサービス」の著者であるS. Nanjiに感謝します。
Thanks to Carlos Pignataro for providing a thorough review and helpful input.
徹底的なレビューと有用な入力を提供してくれたCarlos Pignataroに感謝します。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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、「Pseudowire Emulation Edge-to-Edge（PWE3）の断片化と再組み立て」、RFC 4623、2006年8月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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 STD 802.3 -2005/COR 1-2006 IEEE情報技術のIEEE標準 - システム間の通信および情報交換 - ローカルおよびメトロポリタンエリアネットワーク」、IEEE STD 802.3-2005/COR 1-2006（IEEEへの回復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 STD 802.1q-2005（IEEE STD 802.1Q1998、IEEE STD 802.1U-2001、IEEE STD 802.1V-2001、およびIEEE STD 802.1S-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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
Author Information
著者情報
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089
EMail: rahul@juniper.net
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークタウンズリーシスコシステム7025キットクリークロードPOボックス14987リサーチトライアングルパーク、ノースカロライナ州27709
EMail: mark@townsley.net
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134
マリアアリスドスサントスシスコシステム170 Wタスマン博士サンノゼ、カリフォルニア95134
EMail: mariados@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。