Network Working Group M. Townsley
Request for Comments: 4591 G. Wilkie
Category: Standards Track S. Booth
S. Bryant
Cisco Systems
J. Lau
July 2006
Frame Relay 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 Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification.
レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）は、IPネットワークを介してデータ・リンク・プロトコルの様々なトンネリングのためのプロトコルを定義します。この文書では、どのようにトンネルフレームのカプセル化、仮想回線の作成と削除、およびステータス変更の通知を含むL2TPv3のオーバーフレームリレーを、の詳細を記述します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Abbreviations ..............................................3
1.2. Specification of Requirements ..............................3
2. Control Connection Establishment ................................3
3. PVC Status Notification and Session Establishment ...............3
3.1. L2TPv3 Session Establishment ...............................4
3.2. L2TPv3 Session Teardown ....................................5
3.3. L2TPv3 Session Maintenance .................................5
3.4. Use of the Circuit Status AVP for Frame Relay ..............6
3.5. Frame Relay Header Length AVP ..............................7
4. Encapsulation ...................................................7
4.1. Data Packet Encapsulation ..................................7
4.2. Data Packet Sequencing .....................................9
4.3. MTU Considerations .........................................9
5. Applicability Statement ........................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
7.1. Pseudowire Type ...........................................11
7.2. Result Code AVP Values ....................................11
7.3. Control Message Attribute Value Pairs (AVPs) ..............11
8. Acknowledgements ...............................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
[RFC3931] defines a base protocol for Layer 2 Tunneling over IP networks. This document defines the specifics necessary for tunneling Frame Relay over L2TPv3. Such emulated circuits are referred to as Frame Relay Pseudowires (FRPWs).
[RFC3931]は、IPネットワーク上のレイヤ2トンネリングのための基本プロトコルを定義します。この文書では、L2TPv3のオーバートンネリングフレームリレーのために必要な仕様を定義します。そのようなエミュレートされた回路は、フレームリレースードワイヤ（FRPWs）と呼ばれます。
Protocol specifics defined in this document for L2TPv3 FRPWs operating in a "virtual circuit-to-virtual circuit" mode include those necessary for frame encapsulation, PVC creation and deletion, and status change notification. Frame Relay traffic may also be transported in a "port-to-port" or "interface-to-interface" fashion using High-Level Data Link Control (HDLC) Pseudowires as defined in [RFC4349]. Support for Switched Virtual Circuits (SVCs) and Switched/Soft Permanent Virtual Circuits (SPVCs) are outside the scope of this document.
「仮想回線から仮想サーキット」モードで動作したL2TPv3 FRPWsについては、この文書で定義されたプロトコルの仕様は、フレームのカプセル化、PVCの作成と削除、およびステータス変更通知のために必要なものが挙げられます。フレーム・リレー・トラフィックはまた、[RFC4349]で定義されるようにハイレベルデータリンク制御（HDLC）スードワイヤを使用して、「ポート・ツー・ポート」または「インターフェース・ツー・インターフェース」方式で輸送することができます。相手先選択接続（SVC）及び/交換ソフトのPermanent Virtual Circuit（SPVCの）のサポートは、この文書の範囲外です。
The reader is expected to be very familiar with the terminology and protocol constructs defined in [RFC3931].
読者は[RFC3931]で定義された用語とプロトコル構築に精通することが期待されます。
FR Frame Relay FRPW Frame Relay Pseudowire LCCE L2TP Control Connection Endpoint (See [RFC3931]) PVC Permanent virtual circuit PW Pseudowire VC Virtual circuit
FRフレームリレーFRPWフレームリレー擬似回線LCCE L2TPコントロール接続のエンドポイント（[RFC3931]を参照してください）PVCパーマネントバーチャルサーキットPW擬似回線VC仮想回路
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]に記載されているように解釈されます。
In order to tunnel a Frame Relay circuit over IP using L2TPv3, an L2TPv3 Control Connection MUST first be established as described in [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control Message MUST include the Frame Relay Data Link Connection Identifier (DLCI) PW Type of 0x0001 (see IANA Considerations), in the Pseudowire Capabilities List, as defined in Section 5.4.3 of [RFC3931]. This identifies the control connection as able to establish L2TP sessions to support Frame Relay Pseudowires (FRPWs).
[RFC3931]に記載されているようのL2TPv3を使用してIP上フレームリレー回路トンネルするために、L2TPv3の制御接続が最初に確立されなければなりません。 [RFC3931]のセクション5.4.3で定義されたL2TPv3 SCCRQコントロールメッセージと対応SCCRP制御メッセージがフレームは0x0001のリレーデータリンク接続識別子（DLCI）PWタイプを含まなければなりません、疑似回線の能力リストに、（IANAの考慮事項を参照）。これは、フレームリレースードワイヤ（FRPWs）をサポートするためにL2TPセッションを確立することができるような制御接続を識別する。
An LCCE MUST be able to identify itself uniquely in the SCCRQ and SCCRP messages via a globally unique value. By default, this is advertised via the structured Router ID Attribute Value Pairs (AVP) [RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as well.
LCCEは、グローバルに一意の値を介してSCCRQとSCCRPメッセージで一意にそれ自体を識別できなければなりません。構造化されていないホスト名AVP [RFC3931]は、同様LCCEsのを識別するために使用することができるが、デフォルトでは、これは、構造化されたルータID属性値ペア（AVP）[RFC3931]を介してアドバタイズされます。
This section specifies how the status of a PVC is reported between two LCCEs. This includes what should happen when a PVC is created, deleted or when it changes state between ACTIVE and INACTIVE. When emulating a Frame Relay service, if the procedures for PVC status management defined in [Q933] Annex A are being used between an LCCE and the attached Remote System, an LCCE MUST participate in them (see Section 3.3).
このセクションでは、PVCの状態が2つのLCCEsの間に報告される方法を指定します。これはPVCが作成、削除、またはそれはACTIVEとINACTIVE間で状態を変更したときにされたときにどうするか含まれています。フレームリレーサービスをエミュレートするときに[Q933]附属書Aに定義されたPVC状態管理のための手順はLCCEと付属リモートシステムとの間で使用されている場合、LCCE（セクション3.3を参照）、それらに参加しなければなりません。
PVC creation (provisioning) results in establishment of an L2TP session via the standard three-way handshake described in Section 3.4.1 of [RFC3931]. An LCCE MAY initiate the session immediately upon PVC creation or wait until the PVC state transitions to ACTIVE before attempting to establish a session for the PVC. Waiting until the PVC transitions to ACTIVE may be preferred, as it delays allocation of L2TP resources until it is absolutely necessary.
PVCの作成（プロビジョニング）は、[RFC3931]のセクション3.4.1に記載されている標準的なスリーウェイハンドシェイクを介してL2TPセッションの確立をもたらします。 LCCEはすぐにPVCの作成時にセッションを開始するか、PVCのためのセッションを確立しようとする前にACTIVEにPVC状態遷移するまで待つことができます。それは絶対に必要になるまで、それはL2TPのリソースの割り当てを遅らせるようPVCがACTIVEに遷移するまで待って、好ましいかもしれません。
The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], Attribute Type 68, MUST be present in the Incoming-Call-Request (ICRQ) messages and MUST include the Frame Relay DLCI PW Type of 0x0001 for FRPWs.
[RFC3931]のセクション5.4.4で定義された疑似タイプAVPは、68属性タイプ、着信リクエスト（ICRQ）メッセージ内に存在していなければなりませんとFRPWsため0x0001というフレームリレーDLCI PWタイプを含まなければなりません。
The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ and Incoming-Call-Reply (ICRP) messages and MAY be present in the Set Link Info (SLI) message for FRPWs.
回路状態AVP（セクション3.4を参照）ICRQと着信-返信（ICRP）メッセージでなければならず、これFRPWsに設定されたリンク情報（SLI）メッセージ中に存在してもよいです。
The Frame Relay Header Length AVP (see Section 3.5) MAY be present in the ICRQ and ICRP messages.
フレームリレーヘッダ長AVP（セクション3.5を参照）ICRQとICRPメッセージに存在してもよいです。
The following is an example of the L2TP messages exchanged for an FRPW that is initiated after a new PVC is provisioned and becomes ACTIVE.
以下は、新しいPVCをプロビジョニングして、アクティブになった後に開始されFRPWに交換L2TPメッセージの一例です。
LCCE (LAC) A LCCE (LAC) B
------------------ ------------------
FR PVC Provisioned
FR PVC Provisioned
FR PVC ACTIVE
ICRQ (status = 0x03) ---->
FR PVC ACTIVE
ACTIVE FR PVC
<---- ICRP (status = 0x03)
L2TP session established, OK to send data into tunnel
L2TPセッションがトンネルにデータを送信するために、OK設立します
ICCN ----->
L2TP session established,
OK to send data into tunnel
In the example above, an ICRQ is sent after the PVC is created and becomes ACTIVE. The Circuit Status AVP indicates that this PVC is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be
上記の例では、ICRQはPVCが作成された後に送信され、アクティブになっています。サーキットステータスAVPは、このPVCがACTIVEと新（0×03）であることを示しています。リモートエンドID AVP [RFC3931]はでなければなりません
present in the ICRQ in order to identify the PVC (together with the identity of the LCCE itself, as defined in Section 2) to associate the L2TP session with. The Remote End ID AVP, defined in [RFC3931], is of opaque form and variable length, though one MUST at a minimum support use of an unstructured four-octet value that is known to both LCCEs (either by direct configuration, or some other means). The exact method of how this value is configured, retrieved, discovered, or otherwise determined at each LCCE is outside the scope of this document.
（セクション2で定義されるように、一緒にLCCE自身のアイデンティティを有する）PVCを識別するとL2TPセッションを関連付けるためにICRQに存在します。 [RFC3931]で定義されるリモートエンドID AVPは、LCCEsの（直接的な構成によって、またはいくつかの他の両方に知られている構造化されていない4オクテット値の最小支持用いる1つのMUSTものの、不透明な形可変長であります手段）。この値は、構成された検索、発見、またはそうでなければ各LCCEで決定された方法の正確な方法は、この文書の範囲外です。
As with the ICRQ, the ICRP is sent only after the FR PVC transitions to ACTIVE as well. If LCCE B had not been provisioned for the PVC identified in the ICRQ, a Call-Disconnect-Notify (CDN) would have been immediately returned indicating that the circuit was not provisioned or available at this LCCE. LCCE A SHOULD then exhibit a periodic retry mechanism. If so, the period and maximum number of retries MUST be configurable.
ICRQと同じように、ICRPはFR PVCが同様にACTIVEに遷移した後にのみ送信されます。 LCCE BがICRQで識別PVC、コールの切断は、通知（CDN）にプロビジョニングされていなかった場合は、すぐに回路がこのLCCEでプロビジョニングまたは利用できなかったことを示す返されたであろう。 LCCE Aはその後、定期的な再試行メカニズムを示すべきです。その場合は、再試行の期間と最大数は構成可能でなければなりません。
An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as long as the Circuit Status AVP reflects that the PVC is INACTIVE and an SLI is sent when the PVC becomes ACTIVE (see Section 3.3).
PVCの前ICRQかICRPを送るかもしれ実装AVPはPVCが非アクティブで、PVCがアクティブになったときにSLIは（3.3節を参照）が送信されることを反映している限り、回路状態として、ACTIVEです。
The Incoming-Call-Connected (ICCN) is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic.
着信接続（ICCN）は、双方向トラフィックを許可するために許容されるパラメータでICRPの受信を確認し、セッション確立の最終段階です。
In the event that a PVC is deleted (unprovisioned) at either LCCE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [RFC3931].
LCCEいずれかでのPVCが（プロビジョニングされていない）が削除された場合に、関連するL2TPセッションは[RFC3931]のセクション3.4.3で定義されたCDNメッセージを介して解体されなければなりません。
General Result Codes regarding L2TP session establishment are defined in [RFC3931]. Additional Frame Relay result codes are defined as follows:
L2TPセッションの確立に関する一般的な結果コードは[RFC3931]で定義されています。次のように追加のフレームリレーの結果コードが定義されています。
17: FR PVC was deleted permanently (no longer provisioned) 18: FR PVC has been INACTIVE for an extended period of time 19: Mismatched FR Header Length
17：FR PVCが完全に削除されました（もはやプロビジョニング）18：FR PVCは時間19の長期間の間INACTIVEされています：不一致FRヘッダ長
FRPW over L2TP makes use of the SLI control message defined in [RFC3931] to signal Frame Relay link status notifications between LCCEs. This includes ACTIVE or INACTIVE notifications of the VC, and any other parameters that may need to be shared between the tunnel endpoints or LCCEs in order to provide proper PW emulation. The SLI message is a single message that is sent over the L2TP control channel signalling the state change. Since the message is delivered reliably, there is no additional response or action required of the PW subsystem to ensure that the state change notification was received by the tunnel peer.
L2TP上FRPWはLCCEsの間のフレームリレーリンク状態通知を通知するために、[RFC3931]で定義されたSLI制御メッセージを利用します。これは、VCのアクティブまたは非アクティブ通知、及び適切なPWエミュレーションを提供するために、トンネルエンドポイントまたはLCCEsの間で共有される必要があるかもしれない他の任意のパラメータを含みます。 SLIメッセージは、状態変化をシグナリングL2TP制御チャネルを介して送信される単一のメッセージです。メッセージが確実に配信されるので、状態変化通知は、トンネルピアによって受信されたことを保証するためにPWサブシステムの必要な追加の応答またはアクションはありません。
The SLI message MUST be sent any time there is a circuit status change that may be reported by any values identified in the Circuit Status AVP. The only exceptions to this are the initial ICRQ, ICRP, and CDN messages, which establish and tear down the L2TP session itself when the PVC is created or deleted. 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 that the peer to perform a reverse Session ID lookup).
SLIメッセージは、回路状態AVPで特定された値によって報告される回路状態変更がある任意の時間を送らなければなりません。これに対する唯一の例外は、確立し、PVCが作成または削除されたときにL2TPセッション自体を取り壊す初期ICRQ、ICRP、とCDNのメッセージです。最初ICRQが送信された後SLIメッセージは、（ICRPが受信される前に、おそらく、ピアが逆セッションIDルックアップを実行することを必要とする）、任意の時点でいずれかLCCEから送信されてもよいです。
An LCCE participating in the procedures for PVC status management defined in [Q933], Annex A, MUST transmit an SLI message including the Circuit Status AVP (see Section 3.4) when it detects a change in the status for a particular local FR PVC (i.e., when it detects a service-affecting condition or the clearing of such a condition). An LCCE receiving an SLI message indicating a change in the status of a particular FRPW SHOULD generate corresponding updates for the FR PVC towards the Remote System, as defined in [Q933], Annex A.
それは特定のローカルFR PVC（すなわち、の状態の変化を検出した場合[Q933]で定義されたPVC状態管理のための手順に参加LCCE、附属書Aは、（セクション3.4を参照）回路状態AVPを含むSLIメッセージを送信しなければなりません、それはサービスに影響する状態、またはそのような状態のクリアを検出したとき）。 LCCE [Q933]で定義されるように特定のFRPWの状態の変化は、リモートシステムに向けFR PVCのための対応する更新を生成する必要が示すSLIメッセージを受信し、附属書A.
All sessions established by a given control connection utilize the L2TP Hello facility, defined in Section 4.4 of [RFC3931], for session keepalive. This gives all sessions basic dead peer and path detection between LCCEs.
与えられた制御接続によって確立されたすべてのセッションは、セッションキープアライブの[RFC3931]のセクション4.4で定義されたL2TPハロー機能を、利用します。これは、すべてのセッションに基本的な死者ピアとLCCEsの間のパスの検出を提供します。
Frame Relay circuit status is reported via the Circuit Status AVP defined in [RFC3931], Attribute Type 71. For reference, this AVP is shown below:
フレームリレー回線状態が、[RFC3931]で定義される回路状態AVPを介して報告基準の属性タイプ71され、この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 by the sender and ignored by the receiver.
値は、定義された2つの最下位ビットと、将来の使用のために予約残りのビットと16ビット・マスクです。予約ビットは、送信者によって0に設定され、受信機で無視しなければなりません。
The N (New) bit indicates whether the Circuit Status indication is for a new FR PVC (1) or an existing FR PVC (0).
N（新規）ビットは、回路状態指示が新しいFR PVC（1）又は既存のFR PVC（0）のためであるかどうかを示します。
The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or INACTIVE (0).
A（アクティブ）ビットは、FR PVCがアクティブであるかどうかを示す（1）または非アクティブ（0）。
The "Frame Relay Header Length AVP", Attribute type 85, indicates the number of bytes in the Frame Relay header. The two peer LCCEs MUST agree on the length of the Frame Relay header.
「フレームリレーヘッダ長AVP」、属性タイプ85は、フレーム・リレー・ヘッダ内のバイト数を示します。 2つのピアLCCEsのは、フレーム・リレー・ヘッダの長さに同意しなければなりません。
This AVP is exchanged during session negotiation (in ICRQ, ICRP). If the other LCCE supports a different Frame Relay header length, the associated L2TP session MUST be torn down via CDN message with result code 19 (see Section 3.2).
このAVPは（ICRQ、ICRPで）セッションネゴシエーションの間に交換されます。他のLCCEは異なるフレームリレーヘッダ長をサポートしている場合、関連するL2TPセッションが結果コード19（3.2節を参照）CDNメッセージを介して解体されなければなりません。
If the Frame Relay Header Length AVP is not signalled, it MUST be assumed that the peer uses a 2-byte Frame Relay header.
フレームリレーヘッダ長AVPがシグナリングされない場合は、ピアは、2バイトのフレーム・リレー・ヘッダを使用することを想定しなければなりません。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
Frame Relay Header Length (ICRQ, ICRP)
フレームリレーヘッダ長（ICRQ、ICRP）
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Header Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Frame Relay Header Length Type is a 2-octet unsigned integer with the following values defined in this document:
フレームリレーヘッダ長タイプは、この文書で定義され、以下の値を持つ2オクテットの符号なし整数です。
2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header
2：2オクテットのフレームリレーヘッダー4：4オクテットのフレームリレーヘッダー
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP MAY be set to 0 but MAY vary (see Section 5.2 of [RFC3931]). The length (before hiding) of this AVP is 8.
このAVPは、（Hビットが0または1でもよい）隠すことができます。このAVPのためのMビットは0に設定されてもよいが、（[RFC3931]のセクション5.2を参照）を変化させることができます。このAVPのLength（隠れることの前の）は8です。
The FR PDU is transported in its entirety, excluding the opening and closing High Level Data Link Control (HDLC) flags and the frame check sequence (FCS). Bit stuffing is undone. The L2TPv3 Session Header is that as defined in [RFC3931]. If sequencing or other features require presence of an L2-Specific Sublayer, the Default format defined in Section 4.6 of [RFC3931] MUST be used.
FR PDUは、開口部を除くと、ハイレベルデータリンク制御（HDLC）フラグとフレームチェックシーケンス（FCS）を閉じ、その全体に搬送されます。ビットスタッフィングが取り消されます。 L2TPv3のセッションヘッダのように[RFC3931]で定義されるということです。配列決定または他の特徴がL2特有のSublayerの存在を必要とする場合は、[RFC3931]のセクション4.6で定義されたデフォルトのフォーマットを使用しなければなりません。
The FR header is defined in [Q922]; however, the notation used differs from that used in IETF specifications. For reference, the FR header (referred to as Address Field in [Q922]) in IETF notation is
FRヘッダは[Q922]で定義されています。しかしながら、使用される表記法は、IETF仕様書で使用されるものとは異なります。参考のために、IETF表記FRヘッダは（[Q922]のアドレスフィールドとも呼ばれる）であります
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two-octet FR Header
2オクテットFRヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Four-octet FR Header
4オクテットFRヘッダー
C/R (bit 6) FR frame C/R (command/response) bit [Q922].
C / R（ビット6）FRフレームのC / R（コマンド/レスポンス）ビット[Q922]。
F - FECN (bit 12): FR FECN (Forward Explicit Congestion Notification) bit [Q922].
F - FECN（ビット12）：FR FECN（順方向明示的輻輳通知）ビット[Q922]。
B - BECN (bit 13):
B - BECN（ビット13）：
FR BECN (Backward Explicit Congestion Notification) bit [Q922].
FR BECN（逆方向明示的輻輳通知）[Q922]をビット。
D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922].
D - DE（ビット14）FR DEビットは廃棄適性[Q922]を示しています。
Usage of the C/R, FECN, BECN, and DE bits is as specified in [Q922].
[Q922]で指定されるようにC / R、FECN、BECN、およびDEビットの使用です。
The C/R bit is conveyed transparently. Its value MUST NOT be changed by the LCCE.
C / Rビットは透過的に搬送されます。その値はLCCEによって変更してはいけません。
The FECN bit MAY be set by the LCCE to notify the receiving end-user that the frames it receives have encountered congestion. The end-user may use this indication for destination-controlled transmit rate adjustment. The bit must never be cleared by the LCCE. If the LCCE does not support FECN, it shall pass the bit unchanged.
FECNビットは、受信フレームが、輻輳が発生した受信側ユーザに通知するためにLCCEによって設定されてもよいです。エンドユーザは、宛先制御送信レート調整のためにこの指示を使用してもよいです。ビットはLCCEによってクリアされてはなりません。 LCCEがFECNをサポートしていない場合、それは少しそのまま合格しなければなりません。
The BECN bit MAY be set by the LCCE to notify the receiving end-user that the frames it transmits may encounter congestion. The end-user may use this indication to adjust its transmit rate. The bit must never be cleared by the LCCE. If the LCCE does not support BECN, it shall pass the bit unchanged.
BECNビットは、送信フレームは、輻輳が発生する可能性があり、受信側ユーザに通知するためにLCCEによって設定されてもよいです。エンドユーザは、その送信レートを調整するためにこの指示を使用してもよいです。ビットはLCCEによってクリアされてはなりません。 LCCEがBECNをサポートしていない場合、それは少しそのまま合格しなければなりません。
The DE bit MAY be set by a policing function on the LCCE to indicate that this frame SHOULD be discarded in preference to other frames in a congestion situation. The bit must never be cleared by the LCCE. If the LCCE does not support DE, it shall pass the bit unchanged.
DEビットは、このフレームは、輻輳状況における他のフレームを優先して廃棄されるべきであることを示すためにLCCEにポリシング機能によって設定されてもよいです。ビットはLCCEによってクリアされてはなりません。 LCCEは、DEをサポートしていない場合、それは少しそのまま合格しなければなりません。
The encapsulation of Frame Relay frames with the two-octet FR Header is REQUIRED. The encapsulation of Frame Relay frames with the four-octet FR Header is OPTIONAL. The encapsulation of Frame Relay frames with the three-octet FR Header is outside the scope of this document.
2オクテットFRヘッダーとフレームリレーフレームのカプセル化が必要です。 4オクテットFRヘッダーとフレームリレーフレームのカプセル化は任意です。 3オクテットFRヘッダーとフレームリレーフレームのカプセル化は、この文書の範囲外です。
Data Packet Sequencing MAY be enabled for FRPWs. The sequencing mechanisms described in [RFC3931] MUST be used for signalling sequencing support. FRPW over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer when sequencing is enabled and MAY request its presence at all times.
データパケットシーケンスはFRPWsのために有効にすることができます。 [RFC3931]に記載され配列決定メカニズムは、配列決定サポートをシグナリングするために使用されなければなりません。シーケンシングが有効になっていると、すべての回でその存在を要求することができるときL2TPオーバーFRPWはL2TPv3のデフォルトL2特有の副層の存在を要求しなければなりません。
If the FRPW is known to be carrying data that does not require packet order be strictly maintained (such as IP), then packet sequencing for the FRPW SHOULD NOT be enabled.
FRPWは、パケットの順序を厳密に維持することを必要としないデータを（IPなど）を運ぶことが知られている場合は、FRPWためのパケットシーケンスを有効にしないでください。
With L2TPv3 as the tunneling protocol, the packet resulted from the encapsulation is N bytes longer than Frame Relay frame without the opening and closing HDLC flags or FCS. The value of N depends on the following fields:
トンネリングプロトコルとしてのL2TPv3と、パケットはカプセル化に起因Nは開閉HDLCフラグやFCSなしでより長いフレームリレーフレームよりバイトです。 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., with sequencing)
L2TPセッションヘッダー（すなわち、配列決定で）フラグ、版、RES 4つのオクテット（UDP上のL2TPv3のみ）セッションID 4つのオクテットクッキーサイズ0,4、又は8つのオクテットL2特有のSublayer 0または4オクテット
Thus, the range for N in octets is:
したがって、オクテットNの範囲は次のとおりです。
N = 4 - 16 L2TPv3 data messages are over IP N = 16 - 28 L2TPv3 data messages are over UDP (N does not include the IP header)
（Nは、IPヘッダを含まない）28のL2TPv3データメッセージは、UDP上である - = 4つのN - 16のL2TPv3データメッセージは、IP上にあるN = 16
The MTU and fragmentation implications resulting from this are discussed in Section 4.1.4 of [RFC3931].
この起因MTUと断片化含意は[RFC3931]のセクション4.1.4に記載されています。
The Frame Relay PW emulation described in this document allows a service provider to offer a Frame Relay PVC-based service across an IP packet-switched network (PSN). A Frame Relay port-based service can be offered using [RFC4349].
本書では説明フレームリレーPWエミュレーションは、IPパケット交換ネットワーク（PSN）を横切ってフレームリレーPVCベースのサービスを提供するサービスプロバイダを可能にします。フレームリレーポートベースのサービスは、[RFC4349]を使用して提供することができます。
The FRPW emulation has the following characteristics in relationship to the native service:
FRPWエミュレーションはネイティブサービスとの関係で次のような特徴があります。
o There is a one-to-one mapping between a Frame Relay PVC and an FRPW, supporting bi-directional transport of variable length frames. The Frame Relay frame is transported in its entirety, including the DLCI and the C/R, FECN, BECN, and DE bits, but excluding the opening and closing flags and the FCS. The egress LCCE re-writes the DLCI and regenerates the FCS.
O可変長フレームの双方向転送をサポートするフレームリレーPVCとFRPW、間に1対1のマッピングがあります。フレームリレーフレームはDLCIおよびC / R、FECN、BECN、およびDEビットを含む、その全体を搬送するが、開閉フラグとFCSを除いています。出口のLCCEはDLCIを再書き込み、FCSを再生成します。
o Two- and four-octet address fields are supported. The length is negotiated between LCCEs during session establishment (see Section 3.5).
O二次元及び4オクテットのアドレスフィールドがサポートされています。長さは、セッション確立時LCCEsの間でネゴシエートされる（セクション3.5参照）。
o The availability or unavailability of the PVC is signalled between LCCEs using the Circuit Status AVP (see Section 3.4). Loss of connectivity between LCCEs can be detected by the L2TPv3 keepalive mechanism (see Section 4.4 in [RFC3931]). These indications can be used to determine the PVC status to be signalled through [Q933] procedures at the Frame Relay interface.
O PVCの可用性または使用不能が回路状態AVPを用いLCCEsの間にシグナリングされる（セクション3.4参照）。 LCCEsの間の接続の損失は、L2TPv3のキープアライブ機構（[RFC3931]セクション4.4を参照）によって検出することができます。これらの表示は、フレームリレーインターフェイスで[Q933]手順でシグナリングされるPVC状態を決定するために使用することができます。
o The maximum frame size that can be supported is limited by the PSN MTU, unless fragmentation and reassembly is used (see Section 4.1.4 of [RFC3931]).
フラグメンテーションと再構成が使用されない限り支持することができる最大フレームサイズは、（[RFC3931]のセクション4.1.4を参照）、PSN MTUによって制限される、O。
o Sequencing may be enabled on the FRPW to ensure that frames are delivered in order (see Section 4.2).
Oシーケンシングは、フレームは（セクション4.2を参照）の順序で配信されることを保証するためにFRPW上で有効にされてもよいです。
o Quality of Service characteristics, such as throughput (CIR), committed burst size (bc), excess burst size (be), and priority, can be provided by leveraging Quality of Service features of the LCCEs and the underlying PSN.
Oのようなスループット（CIR）、認定バーストサイズ（BC）などのサービス特性、超過バーストサイズ（BE）、および優先度の品質は、サービスLCCEsの特徴および下層のPSNの品質を活用して提供することができます。
Frame Relay over L2TPv3 is subject to the security considerations defined in [RFC3931]. There are no additional considerations specific to carrying Frame Relay that are not present for carrying other data link types.
L2TPv3のオーバーフレームリレーは、[RFC3931]で定義されたセキュリティ問題を受けることです。他のデータリンクタイプを運ぶために存在していないフレームリレーを運ぶに固有の追加の考慮事項はありません。
The following value for the Frame Relay DLCI PW Type (see Pseudowire Capabilities List, as defined in 5.4.3 of [RFC3931], and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]) is allocated by the IANA (number space already created as part of publication of [RFC3931]):
フレームリレーDLCI PWタイプ（[RFC3931]の5.4.3に定義されるように、疑似回線の能力リストを参照し、[RFC3931]の10.6でのL2TPv3疑似回線タイプ）用の次の値は、既に一部として作成IANA（番号空間によって割り当てられ[RFC3931]）の出版：
L2TPv3 Pseudowire Types
-----------------------
0x0001: Frame Relay DLCI Pseudowire Type
0x0001：フレームリレーDLCI擬似回線タイプ
This number space is managed by IANA as described in Section 2.3 of [RFC3438]. Three new L2TP Result Codes for the CDN message appear in Section 3.2. The following is a summary:
[RFC3438]のセクション2.3で説明したように、この番号空間はIANAによって管理されています。 CDNメッセージのための3つの新しいL2TPの結果コードは、3.2節に表示されます。以下は要約です：
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
17: PVC was deleted permanently (no longer provisioned) 18: PVC has been INACTIVE for an extended period of time 19: Mismatched FR Header Length
17：PVCは時間19の長期間の間INACTIVEされています：：不一致FRヘッダ長PVCは永久に（もはやプロビジョニング）18を削除しました
This number space is managed by IANA as described in Section 2.2 of [RFC3438]. An additional AVP Attribute, specified in Section 3.5, was allocated for this specification:
[RFC3438]のセクション2.2に記載されているように、この番号空間はIANAによって管理されています。 3.5節で指定された追加AVP属性は、この仕様のために割り当てられていました。
Control Message Attribute Value Pairs
-------------------------------------
85: Frame Relay Header Length
85：フレームリレーヘッダ長
The first Frame Relay over L2TP document, "Frame Relay Service Type for L2TP", was published in February of 2001, by Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik, and Vijay Gill. This document is substantially different, but the basic concept of carrying Frame Relay over L2TP is the same.
L2TPの文書、「L2TPのためのフレームリレーサービスの種類」を超える最初のフレームリレーは、Nishit Vasavada、ジム・ボイル、クリス・ガードナー、セルジュMaskalik、およびビジェイギルによって、2001年2月に発表されました。この文書は、実質的に異なっているが、L2TP上のフレームリレーを運ぶの基本的な考え方は同じです。
Thanks to Lloyd Wood for a razor-sharp review.
鋭いレビューのためにロイド・ウッドに感謝します。
Carlos Pignataro helped with review and editing of the document.
カルロスPignataroは、レビューや文書の編集を手伝ってくれました。
During IETF Last Call, Mark Lewis provided thorough review and comments.
IETFラストコール時には、マーク・ルイスは徹底的な見直しとコメントを提供しました。
[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月。
[RFC4349] Pignataro, C. and M. Townsley, "High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)", RFC 4349, February 2006.
[RFC4349] Pignataro、C.とM. Townsley、RFC 4349、2006年2月 "ハイレベルデータリンク制御（HDLC）は、レイヤ2トンネリングプロトコル、バージョン3（L2TPv3の）の上にフレーム"。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438] Townsley、W.、 "レイヤ2トンネリングプロトコル（L2TP）IANA（Internet Assigned Numbers Authority）の考慮事項更新"、BCP 68、RFC 3438、2002年12月。
[Q922] ITU-T Recommendation Q.922, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU, Geneva, 1992.
[Q922] ITU-T勧告Q.922、 "フレームモードベアラサービスのためのISDNデータリンク層仕様"、ITU、ジュネーブ、1992年。
[Q933] ITU-T Recommendation Q.933, "Signalling specifications for frame mode switched and permanent virtual connection control and status monitoring", ITU, Geneva, 2003.
[Q933] ITU-T勧告Q.933、ITU、ジュネーブ、2003年、「フレームモードが切り替わると永久仮想接続制御及び状態監視のための仕様をシグナリング」。
Authors' Addresses
著者のアドレス
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
George Wilkie Cisco Systems 96 Commercial Street Edinburgh, EH6 6LX United Kingdom
ジョージ・ウィルキーシスコシステムズ96コマーシャルストリートエディンバラ、EH6 6LXイギリス
EMail: gwilkie@cisco.com
メールアドレス：gwilkie@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
スキップブースシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709
EMail: ebooth@cisco.com
メールアドレス：ebooth@cisco.com
Stewart Bryant Cisco Systems 250 Longwater Ave Green Park Reading RG2 6GB United Kingdom
スチュワートブライアントシスコシステムズ250 Longwaterアベニューグリーンパーク読書RG2 6ギガバイトイギリス
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
Jed Lau
ジェド・ラウ
EMail: jedlau@gmail.com
メールアドレス：jedlau@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。