Network Working Group L. Martini, Ed.
Request for Comments: 4905 E. Rosen, Ed.
Category: Historic Cisco Systems, Inc.
N. El-Aawar, Ed.
Level 3 Communications, LLC
June 2007
Encapsulation Methods for Transport of
Layer 2 Frames over MPLS Networks
Status of This Memo
このメモのステータス
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための歴史的な文書を定義します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.
この文書は、フレームリレー、非同期転送モード（ATM）、またはMPLSネットワーク上で搬送するためのイーサネット（登録商標）などのレイヤ2プロトコルのプロトコルデータユニット（PDU）をカプセル化するための方法を記載しています。この文書では、以来、RFC 4447および関連するドキュメントで説明したワーキンググループの仕様をEdgeに擬似ワイヤエミュレーションエッジに取って代わられている、いわゆる「ドラフト・マティーニ」プロトコルを、説明しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Special Note ....................................................4
4. General Encapsulation Method ....................................4
4.1. The Control Word ...........................................4
4.1.1. Setting the Sequence Number .........................5
4.1.2. Processing the Sequence Number ......................6
4.2. MTU Requirements ...........................................6
5. Protocol-Specific Details .......................................7
5.1. Frame Relay ................................................7
5.2. ATM ........................................................8
5.2.1. ATM AAL5 CPCS-SDU Mode ..............................9
5.2.2. ATM Cell Mode ......................................10
5.2.3. OAM Cell Support ...................................12
5.2.4. CLP bit to Quality of Service Mapping ..............12
5.3. Ethernet VLAN .............................................12
5.4. Ethernet ..................................................12
5.5. High-Level Data Link Control (HDLC) .......................13
5.6. PPP .......................................................13
6. Using an MPLS Label as the Demultiplexer Field .................13
6.1. MPLS Shim EXP Bit Values ..................................14
6.2. MPLS Shim S Bit Value .....................................14
6.3. MPLS Shim TTL Values ......................................14
7. Security Considerations ........................................14
8. Normative References ...........................................14
9. Informative References .........................................16
10. Co-Authors ....................................................16
In an MPLS network, it is possible to use control protocols such as those specified in [RFC4906] to set up "emulated virtual circuits" that carry the Protocol Data Units of layer 2 protocols across the network. A number of these emulated virtual circuits (VCs) may be carried in a single tunnel. This requires, of course, that the layer 2 PDUs be encapsulated. We can distinguish three layers of this encapsulation:
MPLSネットワークでは、それが設定するような[RFC4906]で指定されたもののような制御プロトコルを使用することが可能であるネットワークを介してレイヤ2プロトコルのプロトコルデータユニットを運ぶ「仮想回線をエミュレート」。これらのエミュレートされた仮想回線（VCS）の数は、単一のトンネル内に実施することができます。これは、レイヤ2 PDUがカプセル化されることを、当然のことながら、必要とされます。私たちは、このカプセル化の三つの層を区別することができます。
- the "tunnel header", which contains the information needed to transport the PDU across the MPLS network; this header belongs to the tunneling protocol, e.g., MPLS, Generic Routing Encapsulation (GRE), and Layer 2 Tunneling Protocol (L2TP).
- MPLSネットワーク上でPDUを搬送するために必要な情報が含まれている「トンネルヘッダ」、;このヘッダは、トンネリングプロトコル、例えば、MPLS、総称ルーティングカプセル化（GRE）、およびレイヤ2トンネリングプロトコル（L2TP）に属します。
- the "demultiplexer field", which is used to distinguish
individual emulated virtual circuits within a single tunnel;
this field must be understood by the tunneling protocol as well;
it may be, e.g., an MPLS label or a GRE key field.
- the "emulated VC encapsulation", which contains the information about the enclosed layer 2 PDU that is necessary in order to properly emulate the corresponding layer 2 protocol.
- 適切に対応するレイヤ2プロトコルをエミュレートするために必要で囲まれたレイヤ2 PDUに関する情報が含まれ、「VCカプセル化をエミュレート」。
This document specifies the emulated VC encapsulation for a number of layer 2 protocols. Although different layer 2 protocols require different information to be carried in this encapsulation, an attempt has been made to make the encapsulation as common as possible for all layer 2 protocols.
このドキュメントでは、レイヤ2つのプロトコルの数のエミュレートVCカプセル化を指定します。異なるレイヤ2プロトコルは、このカプセル化で運ばれるさまざまな情報を必要とするが、試みは、すべてのレイヤ2プロトコルに対して可能な限り共通としてカプセル化を行うために行われています。
This document also specifies the way in which the demultiplexer field is added to the emulated VC encapsulation when an MPLS label is used as the demultiplexer field.
また、このドキュメントでは、MPLSラベルがデマルチプレクサフィールドとして使用されている場合、デマルチプレクサフィールドは、エミュレートVCカプセル化に追加される方法を指定します。
Quality of service (QoS)-related issues are not discussed in this document.
サービスの品質（QoS）は、問題はこのドキュメントで説明されていません - 関連しました。
For the purpose of this document, R1 will be defined as the ingress router, and R2 as the egress router. A layer 2 PDU will be received at R1, encapsulated at R1, transported, decapsulated at R2, and transmitted out of R2.
このドキュメントの目的のために、R1は、出口ルータとして入口ルータとして定義され、そしてR2されます。レイヤ2 PDUは、R1で受信されたR1でカプセル化、輸送、R2でデカプセル化、及びR2から送信されます。
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]に記載されているように解釈されます。
This document describes the so called "draft-martini" protocol, which is used in many deployed implementations. This document and its contents have since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications: [RFC4447], [RFC4385], [RFC4448], [RFC4717], [RFC4618], [RFC4619], [RFC4553], [RFC4842], and related documents. This document serves as documentation of current implementations, and MUST NOT be used for new implementations. The PWE3 Label Distribution Protocol control protocol document [RFC4447], which is backward compatible with this document, MUST be used for all new implementations of this protocol.
この文書は、多くの展開の実装に使用されている、いわゆる「ドラフト・マティーニ」プロトコルを、説明しています。この文書およびその内容は、以来、ワーキンググループの仕様をEdgeにスードワイヤ・エミュレーション・エッジによって取って代わられています[RFC4447]、[RFC4385]、[RFC4448]、[RFC4717]、[RFC4618]、[RFC4619]、[RFC4553]、[RFC4842 ]、及び関連文書。このドキュメントは、現在の実装のドキュメントとして機能し、新しい実装のために使用してはいけません。本文書との下位互換性があるPWE3ラベル配布プロトコル制御プロトコルドキュメント[RFC4447]は、このプロトコルの全ての新しい実装のために使用されなければなりません。
In most cases, it is not necessary to transport the layer 2 encapsulation across the network; rather, the layer 2 header can be stripped at R1 and reproduced at R2. This is done using information carried in the control word (see below), as well as information that may already have been signaled from R1 to R2.
ほとんどの場合、ネットワークを介してレイヤ2のカプセル化を輸送する必要がありません。むしろ、レイヤ2ヘッダはR1でストリッピング及びR2で再生することができます。これは、制御ワード（下記参照）で運ばれた情報、ならびに既にR1からR2にシグナリングされていてもよい情報を使用して行われます。
There are three requirements that may need to be satisfied when transporting layer 2 protocols over an MPLS backbone:
MPLSバックボーン上でレイヤ2プロトコルを輸送する際に満足する必要があるかもしれない3つの要件があります。
-i. Sequentiality may need to be preserved.
-私。シーケンシャルは保存する必要があるかもしれません。
-ii. Small packets may need to be padded in order to be transmitted on a medium where the minimum transport unit is larger than the actual packet size.
-II。小さなパケットは、最小の搬送ユニットは、実際のパケットサイズよりも大きい媒体上で送信されるためにパディングする必要があるかもしれません。
-iii. Control bits carried in the header of the layer 2 frame may need to be transported.
-III。レイヤ2フレームのヘッダで運ば制御ビットが搬送される必要があるかもしれません。
The control word defined here addresses all three of these requirements. For some protocols, this word is REQUIRED, and for others OPTIONAL. For protocols where the control word is OPTIONAL, implementations MUST support sending no control word, and MAY support sending a control word.
ここで定義された制御ワードは、これらの要件のすべての3つに対応しています。いくつかのプロトコルでは、この言葉は必須、オプションの他人のためにされています。制御ワードはオプションですプロトコルでは、実装は何の制御ワードの送信をサポートしなければならない、と制御ワードの送信をサポートするかもしれません。
In all cases, the egress router must be aware of whether the ingress router will send a control word over a specific virtual circuit. This may be achieved by configuration of the routers or by signaling, for example, as defined in [RFC4906].
すべての場合において、出口ルータは、入口ルータが特定の仮想回線を介して制御ワードを送信するかどうかを認識する必要があります。 [RFC4906]で定義されるように、これは、例えば、ルータの設定によって、またはシグナリングすることによって達成することができます。
The control word is defined as follows:
次のように制御ワードが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Flags |0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram, the first 4 bits are reserved for future use. They MUST be set to 0 when transmitting, and MUST be ignored upon receipt.
上記の図では、最初の4ビットは将来の使用のために予約されています。彼らは、送信時に0に設定しなければならなくて、受信時に無視しなければなりません。
The next 4 bits provide space for carrying protocol-specific flags. These are defined in the protocol-specific details below.
次の4ビットは、プロトコル固有のフラグを搬送するための空間を提供します。これらは、以下のプロトコルの特定の詳細に定義されています。
The next 2 bits MUST be set to 0 when transmitting.
送信するとき、次の2ビットは0に設定しなければなりません。
The next 6 bits provide a length field, which is used as follows: If the packet's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 bytes, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to 0. The value of the length field, if non-zero, can be used to remove any padding. When the packet reaches the service provider's egress router, it may be desirable to remove the padding before forwarding the packet.
次の6ビットは次のように使用される長さフィールドを提供する：（レイヤ2ペイロードの長さを加えた制御ワードの長さとして定義される）、パケットの長さが64バイト未満である場合、長さフィールドに設定する必要がありパケットの長さ。そうでない場合、長さフィールドは長さフィールドの0値に設定しなければなりません、非ゼロの場合、任意のパディングを除去するために使用することができます。パケットがサービスプロバイダーの出口ルータに到達すると、そのパケットを転送する前に詰め物を除去することが望ましいです。
The next 16 bits provide a sequence number that can be used to guarantee ordered packet delivery. The processing of the sequence number field is OPTIONAL.
次の16ビットは、順序付きパケットの配信を保証するために使用することができるシーケンス番号を提供します。シーケンス番号フィールドの処理は任意です。
The sequence number space is a 16-bit, unsigned circular space. The sequence number value 0 is used to indicate an unsequenced packet.
シーケンス番号空間は、16ビット符号なし円形の空間です。シーケンス番号値0はunsequencedパケットを示すために使用されます。
For a given emulated VC, and a pair of routers R1 and R2, if R1 supports packet sequencing, then the following procedures should be used:
R1は、パケットの順序付けをサポートしている場合は与えられたエミュレートVC、およびルータR1とR2のペアについては、次の手順を使用する必要があります。
- The initial packet transmitted on the emulated VC MUST use sequence number 1.
- エミュレートVCに送信され、最初のパケットは、シーケンス番号1を使用しなければなりません。
- Subsequent packets MUST increment the sequence number by 1 for each packet.
- 後続のパケットは、パケット毎に1のシーケンス番号をインクリメントしなければなりません。
- When the transmit sequence number reaches the maximum 16 bit value (65535), the sequence number MUST wrap to 1.
- 送信シーケンス番号は最大16ビット値（65535）に達すると、シーケンス番号は1にラップしなければなりません。
If the transmitting router R1 does not support sequence number processing, then the sequence number field in the control word MUST be set to 0.
送信ルータR1は、シーケンス番号の処理をサポートしていない場合には、制御ワードのシーケンス番号フィールドは0に設定しなければなりません。
If a router R2 supports receive sequence number processing, then the following procedures should be used:
ルータR2は、シーケンス番号処理を受けるサポートしている場合は、以下の手順を使用する必要があります。
When an emulated VC is initially set up, the "expected sequence number" associated with it MUST be initialized to 1.
エミュレートVCが最初に設定されている場合は、それに関連付けられている「期待シーケンス番号が」1に初期化する必要があります。
When a packet is received on that emulated VC, the sequence number should be processed as follows:
パケットがそのエミュレートVCで受信されると、以下のように、シーケンス番号が処理されるべきです。
- If the sequence number on the packet is 0, then the packet passes the sequence number check.
- パケットのシーケンス番号が0である場合、パケットは、シーケンス番号チェックを渡します。
- Else if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order.
- そうでなければ、パケットシーケンス番号> =期待シーケンス番号とパケットシーケンス番号であれば - 期待シーケンス番号<32768、パケットが順序です。
- Else if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order.
- = 32768、パケットが順序である - それ以外のパケットシーケンス番号<パケットシーケンス番号期待シーケンス番号と期待シーケンス番号>もし。
- Otherwise, the packet is out of order.
- それ以外の場合、パケットは順不同です。
If a packet passes the sequence number check or is in order, then it can be delivered immediately. If the packet is in order, then the expected sequence number should be set using the algorithm:
パケットがシーケンス番号チェックをパスまたは順序である場合、それはすぐにお届けすることができます。パケットが順番にある場合、予想されるシーケンス番号は、アルゴリズムを使用して設定する必要があります。
expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number := 1;
expected_sequence_number：= packet_sequence_number + 1 MOD 2 ** 16 IF（expected_sequence_number = 0）をexpected_sequence_number：= 1;
Packets that are received out of order MAY be dropped or reordered at the discretion of the receiver.
順不同で受信されたパケットは、受信機の裁量で削除または再順序付けされるかもしれません。
If a router R2 does not support receive sequence number processing, then the sequence number field MAY be ignored.
ルータR2は、シーケンス番号処理を受けるサポートされていない場合は、シーケンス番号フィールドは無視されるかもしれません。
The network MUST be configured with an MTU that is sufficient to transport the largest encapsulation frames. If MPLS is used as the tunneling protocol, for example, this is likely to be 12 or more bytes greater than the largest frame size. Other tunneling protocols may have longer headers and require larger MTUs. If the ingress router determines that an encapsulated layer 2 PDU exceeds the MTU of the tunnel through which it must be sent, the PDU MUST be dropped. If an egress router receives an encapsulated layer 2 PDU whose payload length (i.e., the length of the PDU itself without any of the encapsulation headers) exceeds the MTU of the destination layer 2 interface, the PDU MUST be dropped.
ネットワークは、最大カプセル化フレームを搬送するのに十分であるMTUを設定する必要があります。 MPLSは、トンネリングプロトコルとして使用される場合、例えば、これは、最大フレームサイズよりも大きい12以上のバイトである可能性が高いです。他のトンネリングプロトコルは長いヘッダを持っているし、大きなMTUのが必要な場合があります。入口ルータは、カプセル化されたレイヤ2 PDUは、それが送信されなければならないそこを通ってトンネルのMTUを超えていると判断した場合、PDUは破棄されなければなりません。出口ルータは、そのペイロード長（カプセル化ヘッダーのいずれかせずPDU自体の、すなわち、長さ）宛先レイヤ2インターフェースのMTUを超えるカプセル化レイヤ2 PDUを受信した場合、PDUは破棄されなければなりません。
A Frame Relay PDU is transported without the Frame Relay header or the Frame Check Sequence (FCS). The control word is REQUIRED; however, its use is optional, although desirable. Use of the control word means that the ingress and egress Label Switching Routers (LSRs) follow the procedures below. If an ingress LSR chooses not to use the control word, it MUST set the flags in the control word to 0; if an egress LSR chooses to ignore the control word, it MUST set the Frame Relay control bits to 0.
フレームリレーPDUは、フレームリレーヘッダまたはフレーム・チェック・シーケンス（FCS）なしに搬送されます。制御ワードが必要です。望ましいものの、その使用は、任意です。制御ワードの使用は、入力および出力ラベルスイッチングルータ（LSRの）は、以下の手順に従うことを意味します。入口LSRは、制御ワードを使用しないことを選択した場合、それは0に制御ワードにフラグを設定しなければなりません。出口LSRは、制御ワードを無視することを選択した場合、それは0にフレームリレー制御ビットを設定しなければなりません。
The BECN (Backward Explicit Congestion Notification), FECN (Forward Explicit Congestion Notification), DE (Discard Eligibility), and C/R (Command/Response) bits are carried across the network in the control word. The edge routers that implement this document MAY, when either adding or removing the encapsulation described herein, change the BECN and/or FECN bits from 0 to 1 in order to reflect congestion in the network that is known to the edge routers, and the D/E bit from 0 to 1 to reflect marking from edge policing of the Frame Relay Committed Information Rate. The BECN, FECN, and D/E bits SHOULD NOT be changed from 1 to 0.
BECN（逆方向明示的輻輳通知）、FECN（順方向明示的輻輳通知）、DE（廃棄適格）、およびC / R（コマンド/レスポンス）ビットは、制御ワードにネットワークを介して行われます。本明細書に記載のカプセル化を追加または削除のいずれか本書MAYを実装エッジルータ、エッジルータに知られているネットワークの輻輳を反映するために、0から1までBECN及び/又はFECNビットを変更し、D 0から1まで/ Eビットは、フレームリレーのエッジポリシング認定情報レートからマーキング反映します。 BECN、FECN、およびD / Eビットが1から0に変更しないでください。
The following is an example of a Frame Relay packet:
以下は、フレームリレーパケットの例です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |B|F|D|C| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay PDU |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* B ( BECN ) Bit
* B（BECN）ビット
The ingress router, R1, SHOULD copy the BECN field from the incoming Frame Relay header into this field. The egress router, R2, MUST generate a new BECN field based on the value of the B bit.
入口ルータ、R1は、このフィールドに入ってくるフレームリレーヘッダからBECNフィールドをコピーする必要があります。出口ルータ、R2は、Bビットの値に基づいて新しいBECNフィールドを生成しなければなりません。
* F ( FECN ) Bit
* F（FECN）ビット
The ingress router, R1, SHOULD copy the FECN field from the incoming Frame Relay header into this field. The egress router, R2, MUST generate a new FECN field based on the value of the F bit.
入口ルータ、R1は、このフィールドに入ってくるフレームリレーヘッダからFECNフィールドをコピーする必要があります。出口ルータ、R2は、Fビットの値に基づいて、新しいFECNフィールドを発生させなければなりません。
* D ( DE ) Bit
* D（DE）ビット
The ingress router, R1, SHOULD copy the DE field from the incoming Frame Relay header into this field. The egress router, R2, MUST generate a new DE field based on the value of the D bit.
入口ルータ、R1は、このフィールドに入力フレームリレーヘッダからDEフィールドをコピーする必要があります。出口ルータ、R2は、Dビットの値に基づいて新たなDEフィールドを生成しなければなりません。
If the tunneling protocol provides a field that can be set to specify a Quality of Service, the ingress router, R1, MAY consider the DE bit of the Frame Relay header when determining the value of that field. The egress router MAY then consider the value of this field when queuing the layer 2 PDU for egress. Note however that frames from the same VC MUST NOT be reordered.
トンネリングプロトコルは、サービス品質を指定するように設定することができるフィールドを提供している場合、そのフィールドの値を決定する際に、入口ルータ、R1は、フレーム・リレー・ヘッダのDEビットを考慮することができます。出口のためのレイヤ2 PDUをキューイングするとき出口ルータは、このフィールドの値を考慮することができます。同じVCからのフレームを並べ替えてはならないことに注意してください。
* C ( C/R ) Bit
* C（C / R）ビット
The ingress router, R1, SHOULD copy the C/R bit from the received Frame Relay PDU to the C bit of the control word. The egress router, R2, MUST copy the C bit into the output frame.
入口ルータ、R1は、制御ワードのCビットに受信したフレーム・リレーPDUのC / Rビットをコピーする必要があります。出口ルータ、R2は、出力フレームにCビットをコピーする必要があります。
Two encapsulations are supported for ATM transport: one for ATM Adaption Layer 5 (AAL5) and another for ATM cells.
二つのカプセル化は、ATMの輸送のためにサポートされていますATMセルのためのATMアダプテーションレイヤ5（AAL5）と別のもの。
The AAL5 Common Part Convergence Sublayer - Service Data Unit (CPCS-SDU) encapsulation consists of the REQUIRED control word and the AAL5 CPCS-SDU. The ATM cell encapsulation consists of an OPTIONAL control word, a 4-byte ATM cell header, and the ATM cell payload.
AAL5共通パートコンバージェンスサブレイヤ - サービスデータユニット（CPCS-SDU）カプセル化は必要な制御語とAAL5 CPCS-SDUから構成されています。 ATMセルのカプセル化は、オプションの制御ワード、4バイトのATMセルヘッダー、及びATMセルペイロードから成ります。
In ATM AAL5 mode, the ingress router is required to reassemble AAL5 CPCS-SDUs from the incoming VC and transport each CPCS-SDU as a single packet. No AAL5 trailer is transported. The control word is REQUIRED; its use, however, is optional, although desirable. Use of the control word means that the ingress and egress LSRs follow the procedures below. If an ingress LSR chooses not to use the control word, it MUST set the flags in the control word to 0; if an egress LSR chooses to ignore the control word, it MUST set the ATM control bits to 0.
ATM AAL5モードでは、入口ルータは、着信VCからAAL5 CPCS-SDUを再アセンブルし、単一のパケットとして各CPCS-SDUを輸送する必要があります。いいえAAL5トレーラーが輸送されていません。制御ワードが必要です。その使用は、しかし、望ましいが、任意です。制御ワードの使用は、入口と出口のLSRは、以下の手順に従うことを意味します。入口LSRは、制御ワードを使用しないことを選択した場合、それは0に制御ワードにフラグを設定しなければなりません。出口LSRは、制御ワードを無視することを選択した場合、それは0にATM制御ビットを設定しなければなりません。
The EFCI (Explicit Forward Congestion Indication) and CLP (Cell Loss Priority) bits are carried across the network in the control word. The edge routers that implement this document MAY, when either adding or removing the encapsulation described herein, change the EFCI bit from 0 to 1 in order to reflect congestion in the network that is known to the edge routers, and the CLP bit from 0 to 1 to reflect marking from edge policing of the ATM Sustained Cell Rate. The EFCI and CLP bits MUST NOT be changed from 1 to 0.
EFCI（明示的順方向輻輳表示）およびCLP（セル廃棄優先）ビットは、制御ワードにネットワークを介して行われます。本明細書に記載のカプセル化を追加または削除のいずれかの場合、本文書MAYを実装するルータは、エッジルータに知られているネットワークの輻輳を反映するために0から1にEFCIビットを変更するエッジ、およびCLPビットは0〜 1 ATM維持セル・レートのエッジポリシングからマーキング反映します。 EFCIとCLPビットが1から0に変更してはなりません。
The AAL5 CPCS-SDU is prepended by the following header:
AAL5 CPCS-SDUは以下のヘッダーによって付加されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |T|E|L|C| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM AAL5 CPCS-SDU |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* T (transport type) bit
* T（トランスポート・タイプ）ビット
Bit (T) of the control word indicates whether the packet contains an ATM cell or an AAL5 CPCS-SDU. If set, the packet contains an ATM cell, encapsulated according to the ATM cell mode section below; otherwise, it contains an AAL5 CPCS-SDU. The ability to transport an ATM cell in the AAL5 mode is intended to provide a means of enabling Operations and Management (OAM) functionality over the AAL5 VC.
制御ワードのビット（T）は、パケットがATMセルまたはAAL5 CPCS-SDUが含まれているかどうかを示します。設定した場合、パケットは、以下のATMセルモード部に応じてカプセル化されたATMセルを含み、それ以外の場合は、AAL5 CPCS-SDUが含まれています。 AAL5モードでATMセルを輸送する能力がAAL5 VC以上の運用と管理（OAM）の機能を有効にする手段を提供することを意図しています。
* E ( EFCI ) Bit
* E（EFCI）ビット
The ingress router, R1, SHOULD set this bit to 1 if the EFCI bit of the final cell of those that transported the AAL5 CPCS-SDU is set to 1, or if the EFCI bit of the single ATM cell to be transported in the packet is set to 1. Otherwise, this bit SHOULD be set to 0. The egress router, R2, SHOULD set the EFCI bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field.
AAL5 CPCS-SDUを搬送するものの最終セルのEFCIビットが1に設定されている場合、または単一のATMセルのEFCIビットがパケットで搬送される場合、入口ルータ、R1は、このビットを1に設定すべきですそうでなければ1にセットされ、このビットが出口ルータ、R2は、このフィールドに含まれる値にAAL5 CPCS-SDUを輸送するすべてのセルのEFCIビットを設定すべきである0に設定されるべきです。
* L ( CLP ) Bit
* L（CLP）ビット
The ingress router, R1, SHOULD set this bit to 1 if the CLP bit of any of the ATM cells that transported the AAL5 CPCS-SDU is set to 1, or if the CLP bit of the single ATM cell to be transported in the packet is set to 1. Otherwise, this bit SHOULD be set to 0. The egress router, R2, SHOULD set the CLP bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field.
入口ルータ、R1は、AAL5 CPCS-SDUを搬送するATMセルのいずれかのCLPビットが1に設定されている場合、このビットを1に設定すべきである、または単一のATMセルのCLPビットは、パケットで搬送される場合そうでなければ1にセットされ、このビットが出口ルータ、R2は、このフィールドに含まれる値にAAL5 CPCS-SDUを輸送するすべてのセルのCLPビットを設定すべきである0に設定されるべきです。
* C ( Command / Response Field ) Bit
* C（コマンド/レスポンスフィールド）ビット
When FRF.8.1 Frame Relay / ATM PVC Service Interworking [FRF.8.1] traffic is being transported, the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS-SDU may contain the Frame Relay C/R bit. The ingress router, R1, SHOULD copy this bit to the C bit of the control word. The egress router, R2, SHOULD copy the C bit to the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU.
FRF.8.1フレームリレー/ ATM PVCサービスインターワーキングは、[FRF.8.1]トラフィックが搬送される際に、AAL5 CPCS-SDUのCPCS-UUは、最下位ビット（LSB）フレームリレーC / Rビットを含んでいてもよいです。入口ルータ、R1は、制御ワードのCビットにこのビットをコピーしてください。出口ルータ、R2は、AAL5 CPCS PDUのCPCS-UU最下位ビット（LSB）にCビットをコピーする必要があります。
In this encapsulation mode, ATM cells are transported individually without a Segmentation and Reassembly (SAR) process. The ATM cell encapsulation consists of an OPTIONAL control word, and one or more ATM cells - each consisting of a 4-byte ATM cell header and the 48- byte ATM cell payload. This ATM cell header is defined in the FAST encapsulation [FAST] section 3.1.1, but without the trailer byte. The length of each frame, without the encapsulation headers, is a multiple of 52 bytes long. The maximum number of ATM cells that can be fitted in a frame, in this fashion, is limited only by the network MTU and by the ability of the egress router to process them. The ingress router MUST NOT send more cells than the egress router is willing to receive. The number of cells that the egress router is willing to receive may either be configured in the ingress router or may be signaled, for example, using the methods described in [RFC4906]. The number of cells encapsulated in a particular frame can be inferred by the frame length. The control word is OPTIONAL.
このカプセル化モードでは、ATMセルはセグメンテーションとリアセンブリ（SAR）処理することなく、個別に輸送されます。 ATMセルのカプセル化は、オプションの制御ワードで構成され、一つ以上のATMセル - 各4バイトのATMセルのヘッダと、48バイトのATMセルペイロードからなります。このATMセルのヘッダはなく、トレーラバイトなしで、FASTカプセル化[FAST]セクション3.1.1で定義されています。各フレームの長さは、カプセル化ヘッダーなしで、長い52バイトの倍数です。フレームに取り付けることができるATMセルの最大数は、このように、唯一のネットワークMTUによって、それらを処理するために出口ルータの能力によって制限されます。入口ルータは、出口ルータが受信しようとするよりも多くのセルを送ってはいけません。出口ルータが受信する意思がある細胞の数は、[RFC4906]に記載された方法を用いて、例えば、いずれかの入口ルータで構成され得るか、またはシグナリングすることができます。特定のフレームにカプセル化された細胞の数は、フレーム長によって推定することができます。制御ワードはオプションです。
If the control word is used, then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt.
制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信するときに0に設定しなければならなく、そして受信時に無視しなければなりません。
The EFCI and CLP bits are carried across the network in the ATM cell header. The edge routers that implement this document MAY, when either adding or removing the encapsulation described herein, change the EFCI bit from 0 to 1 in order to reflect congestion in the network that is known to the edge router, and the CLP bit from 0 to 1 to reflect marking from edge policing of the ATM Sustained Cell Rate. The EFCI and CLP bits SHOULD NOT be changed from 1 to 0.
EFCIとCLPビットは、ATMセルのヘッダ内にネットワークを介して行われます。本明細書に記載のカプセル化を追加または削除のいずれかの場合、本文書MAYを実装するルータは、エッジルータに知られているネットワークの輻輳を反映するために0から1にEFCIビットを変更するエッジ、およびCLPビットは0〜 1 ATM維持セル・レートのエッジポリシングからマーキング反映します。 EFCIとCLPビットが1から0に変更しないでください。
This diagram illustrates an encapsulation of two ATM cells:
この図は、2つのATMセルのカプセル化を示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control word ( Optional ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Payload ( 48 bytes ) |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Payload ( 48 bytes ) |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VPI (Virtual Path Identifier)
* VPI（仮想パス識別子）
The ingress router MUST copy the VPI field from the incoming cell into this field. For particular emulated VCs, the egress router MAY generate a new VPI and ignore the VPI contained in this field.
入口ルータは、このフィールドに入力セルからVPIフィールドをコピーする必要があります。特定のエミュレートVCのために、出口ルータは、新しいVPIを生成し、この分野に含まれるVPIを無視するかもしれません。
* VCI (Virtual Circuit Identifier)
* VCI（仮想回線識別子）
The ingress router MUST copy the VCI field from the incoming ATM cell header into this field. For particular emulated VCs, the egress router MAY generate a new VCI.
入口ルータは、このフィールドに受信ATMセルのヘッダからVCIフィールドをコピーする必要があります。特定のエミュレートVCのために、出口ルータは、新たなVCIを生成することがあります。
* PTI (Payload Type Identifier) & CLP ( C bit )
* PTI（ペイロードタイプ識別子）およびCLP（Cビット）
The PTI and CLP fields are the PTI and CLP fields of the incoming ATM cells. The cell headers of the cells within the packet are the ATM headers (without HEC) of the incoming cell.
PTIとCLPフィールドは、着信ATMセルのPTIおよびCLPフィールドです。パケット内のセルのセル・ヘッダは、着信セルの（HECなし）ATMヘッダです。
OAM cells MAY be transported on the VC LSP. An egress router that does not support transport of OAM cells MUST discard frames that contain an ATM cell with the high-order bit of the PTI field set to 1. A router that supports transport of OAM cells MUST follow the procedures outlined in [FAST] section 8 for mode 0 only, in addition to the applicable procedures specified in [RFC4906].
OAMセルは、VC LSPに輸送することができます。 1に概説された手順に従わなければならないOAMセルの輸送をサポートするルータを設定PTIフィールドの上位ビットを有するATMセルを含むフレームを破棄しなければならないOAMセルの輸送をサポートしていない出口ルータ[FAST] [RFC4906]で指定された適切な手順に加えて専用モード0セクション8、。
The ingress router MAY consider the CLP bit when determining the value to be placed in the Quality of Service fields (e.g., the EXP fields of the MPLS label stack) of the encapsulating protocol. This gives the network visibility of the CLP bit. Note however that cells from the same VC MUST NOT be reordered.
カプセル化プロトコルのサービスフィールド（例えば、MPLSラベルスタックのEXPフィールド）の品質に置かれるべき値を決定する際に入口ルータはCLPビットを考慮することができます。これは、CLPビットのネットワークの可視性を提供します。同じVCからの細胞は並べ替えてはならないことに注意してください。
For an Ethernet 802.1q VLAN, the entire Ethernet frame without the preamble or FCS is transported as a single packet. The control word is OPTIONAL. If the control word is used, then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt. The 4-byte VLAN tag is transported as is, and MAY be overwritten by the egress router.
イーサネット802.1Q VLANに、プリアンブル又はFCSなしで全体のイーサネットフレームを単一のパケットとして搬送されます。制御ワードはオプションです。制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信するときに0に設定しなければならなく、そして受信時に無視しなければなりません。 4バイトのVLANタグがそのまま搬送され、出口ルータによって上書きされるかもしれません。
The ingress router MAY consider the user priority field [IEEE802.3ac] of the VLAN tag header when determining the value to be placed in the Quality of Service field of the encapsulating protocol (e.g., the EXP fields of the MPLS label stack). In a similar way, the egress router MAY consider the Quality of Service field of the encapsulating protocol when queuing the packet for egress. Ethernet packets containing hardware-level Cyclic Redundancy Check (CRC) errors, framing errors, or runt packets MUST be discarded on input.
カプセル化プロトコル（例えば、MPLSラベルスタックのEXPフィールド）のServiceフィールドの品質に置かれるべき値を決定する際に入口ルータは、[IEEE802.3ac] VLANタグヘッダのユーザプライオリティフィールドを考慮することができます。出口のためのパケットをキューに入れるとき、同様の方法で、出口ルータは、カプセル化プロトコルのサービス分野の品質を考慮することができます。ハードウェアレベルの巡回冗長検査（CRC）エラー、フレーミングエラー、ラントパケットを含むイーサネットパケットは、入力時に廃棄されなければなりません。
For simple Ethernet port to port transport, the entire Ethernet frame without the preamble or FCS is transported as a single packet. The control word is OPTIONAL. If the control word is used, then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt. As in the Ethernet
ポートの輸送への単純なイーサネットポート、プリアンブル又はFCSなしで全体のイーサネットフレームを単一のパケットとして搬送されます。制御ワードはオプションです。制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信するときに0に設定しなければならなく、そして受信時に無視しなければなりません。イーサネットのように、
VLAN case, Ethernet packets with hardware-level CRC errors, framing errors, and runt packets MUST be discarded on input.
VLANの場合、ハードウェアレベルのCRCエラー、フレーミングエラー、およびラントパケットとイーサネットパケットは、入力時に廃棄されなければなりません。
HDLC mode provides port to port transport of HDLC-encapsulated traffic. The HDLC PDU is transported in its entirety, including the HDLC address, control, and protocol fields, but excluding HDLC flags and the FCS. Bit/byte stuffing is undone. The control word is OPTIONAL. If the control word is used, then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt.
HDLCモードはHDLCカプセル化されたトラフィックのポートトランスポートにポートを提供します。 HDLC PDUはHDLCアドレス、制御、およびプロトコルフィールドが、HDLCフラグを除くとFCSを含め、その全体に搬送されます。ビット/バイトスタッフィングが取り消されます。制御ワードはオプションです。制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信するときに0に設定しなければならなく、そして受信時に無視しなければなりません。
The HDLC mode is suitable for port to port transport of Frame Relay User-Network Interface (UNI) or Network-Network Interface (NNI) traffic. It must be noted, however, that this mode is transparent to the FECN, BECN, and DE bits.
HDLCモードは、フレームリレーユーザ・ネットワーク・インターフェイス（UNI）またはネットワーク - ネットワークインターフェイス（NNI）トラフィックのポート輸送へのポートに適しています。このモードはFECN、BECN、およびDEビットに透明であること、しかし、注意しなければなりません。
PPP mode provides point to point transport of PPP-encapsulated traffic, as specified in [RFC1661]. The PPP PDU is transported in its entirety, including the protocol field (whether compressed using PFC or not), but excluding any media-specific framing information, such as HDLC address and control fields or FCS. Since media-specific framing is not carried, the following options will not operate correctly if the PPP peers attempt to negotiate them:
PPPモードは、[RFC1661]で指定されるように、PPPカプセル化トラフィックの輸送を指すようにポイントを提供します。 PPP PDUは、プロトコルフィールド（PFCかを使用して圧縮されたかどうか）を含め、その全体を搬送するが、このようなHDLCアドレスおよび制御フィールドやFCSなどの任意のメディア固有のフレーミング情報を除いています。メディア固有のフレーミングが行われていないので、PPPピアは、それらを交渉しようとすると、次のオプションが正常に動作しません。
- Frame Check Sequence (FCS) Alternatives - Address-and-Control-Field-Compression (ACFC) - Asynchronous-Control-Character-Map (ACCM)
- フレームチェックシーケンス（FCS）代替 - 住所・アンド・コントロール・フィールド圧縮（ACFC） - 非同期制御用キャラクタ・マップ（ACCM）
Note also that VC LSP Interface MTU negotiation as specified in [RFC4906] is not affected by PPP Maximum Receive Unit (MRU) advertisement. Thus, if a PPP peer sends a PDU with a length in excess of that negotiated for the VC LSP, that PDU will be discarded by the ingress router.
注また、[RFC4906]で指定されたVC LSPインターフェイスMTUのネゴシエーションがPPP最大の影響を受けていないことをユニット（MRU）の広告を受信します。したがって、PPPピアはPDUが入口ルータによって破棄されること、VC LSPのために交渉それ以上の長さのPDUを送信した場合。
The control word is OPTIONAL. If the control word is used, then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt.
制御ワードはオプションです。制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信するときに0に設定しなければならなく、そして受信時に無視しなければなりません。
To use an MPLS label as the demultiplexer field, a 32-bit label stack entry [RFC3032] is simply prepended to the emulated VC encapsulation, and hence will appear as the bottom label of an MPLS label stack. This label may be called the "VC label". The particular emulated VC identified by a particular label value must be agreed by the ingress and egress LSRs, either by signaling (e.g., via the methods of [RFC4906]) or by configuration. Other fields of the label stack entry are set as follows.
デマルチプレクサフィールドとしてMPLSラベルを使用する、32ビットのラベルスタックエントリー[RFC3032]は、単純にエミュレートされたVCカプセル化の前に付加されるため、MPLSラベルスタックの底ラベルとして表示されます。このラベルは、「VCラベル」と呼ばれることもあります。特定のラベルの値によって識別される特定のエミュレートVCは（[RFC4906]の方法によって、例えば）シグナリングによって、またはコンフィギュレーションのいずれかによって、入口と出口LSRsによって合意されなければなりません。次のようにラベルスタックエントリーの他のフィールドが設定されています。
If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the EXP field of the VC label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value.
それは、サービス情報の品質を運ぶために必要な場合は、サービス情報の品質は、VCラベルのEXPフィールドに表現できるようにして下さい。複数のMPLSラベルがイングレスLSRによって課された場合、スタックの上位の任意のラベルのEXPフィールドも同じ値を運ぶべきです。
The ingress LSR, R1, MUST set the S bit of the VC label to a value of 1 to denote that the VC label is at the bottom of the stack.
入口LSR、R1は、VCラベルがスタックの一番下にあることを示すために1の値にVCラベルのSビットを設定しなければなりません。
The ingress LSR, R1, SHOULD set the TTL field of the VC label to a value of 2.
イングレスLSR、R1は、2の値にVCラベルのTTLフィールドを設定する必要があります。
This document specifies only encapsulations, and not the protocols, used to carry the encapsulated packets across the network. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein. More detailed security considerations are also described in Section 8 of [RFC4447].
この文書では、ネットワークを介してカプセル化されたパケットを運ぶために使用されるプロトコルを、唯一のカプセル化を指定し、ではありません。各そのようなプロトコルは、セキュリティ上の問題の独自のセットを持っている可能性がありますが、これらの問題は、ここで指定されたカプセル化の影響を受けません。より詳細なセキュリティ上の考慮事項はまた、[RFC4447]のセクション8に記載されています。
[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月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、2006年2月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4842] Malis、A.、パテ、P.、コーエン、R.、編、及びD.カメレオンマン、 "同期光ネットワーク/同期デジタル階層（SONET / SDH）パケット（CEP）を超える回線エミュレーション"、RFC 4842 、2007年4月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.編、及びYJ。スタイン、エド。、 "パケット（のSAToP）以上の構造に依存しない時分割多重（TDM）"、RFC 4553、2006年6月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]マティーニ、L.、エド。、カワ、C.、エド。、およびA. Malis、エド。、 "フレームリレーの輸送のためのカプセル化方法マルチプロトコルラベルの上に（MPLS）ネットワークの切り替え"、RFC 4619、2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717]マルティーニ、MPLSネットワークの上の非同期転送モードのトランスポート（ATM）のためのL.、Jayakumar、J.、ボッチ、M.、エルAawar、N.、Brayley、J.、およびG. Koleyni、「カプセル化方法」、RFC 4717、2006年12月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]マティーニ、L.、ローゼン、E.、ヘロン、G.、およびA. Malis、RFC 4618、2006年9月 "MPLSネットワーク上のPPP /ハイレベルデータリンク制御（HDLC）の輸送のためのカプセル化方法" 。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]マティーニ、L.、エド。、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed., "Transport of Layer 2 Frames Over MPLS", RFC 4906, June 2007.
[RFC4906]マティーニ、L.、エド。、ローゼン、E.、エド。、およびN.エルAawar、エド。、 "MPLS上の層の交通2つのフレーム"、RFC 4906、2007年6月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[FRF.8.1] Frame Relay Forum, "Frame Relay / ATM PVC Service Interworking Implementation Agreement", February 2000.
[FRF.8.1]フレームリレーフォーラム、「フレームリレー/ ATM PVCサービスインターワーキング実装合意書」、2000年2月。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[FAST] ATMフォーラム、 "SONET / SDHトランスポート上でフレーム・ベースATM（FAST）"、AF-fbatm-0151.000、2000年7月。
[IEEE802.3ac] IEEE 802.3ac-1998, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) frame extensions for Virtual Bridged Local Area Networks (VLAN) tagging on 802.3 networks".
[IEEE802.3ac] IEEE 802.3ac-1998、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 特定の要件パート3：衝突検出（CSMA / CD）仮想ブリッジ用のフレーム拡張子を持つキャリア検知多重アクセスローカルエリアネットワーク802.3ネットワーク上の（VLAN）タギング」。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK EMail: giles.heron@tellabs.com
ジャイルズヘロンテラブスアビー場所24-28イーストンストリートハイウィコムバックスHP11 1NT英国のEメール：giles.heron@tellabs.com
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 EMail: d@mazunetworks.com
ディミトリ・ストラットンVlachos媽祖ネットワークス株式会社125 Cambridgeparkドライブケンブリッジ、MA 02140 Eメール：d@mazunetworks.com
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: tappan@cisco.com
ダンタッパンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 Eメール：tappan@cisco.com
Jayakumar Jayakumar Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA 95134 EMail: jjayakum@cisco.com
Jayakumar Jayakumarシスコシステムズ株式会社225、E.Tasman、MS-SJ3 / 3、サンノゼ、CA 95134 Eメール：jjayakum@cisco.com
Alex Hamilton Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA 95134 EMail: tahamilt@cisco.com
アレックス・ハミルトンシスコシステムズ株式会社285 W.タスマン、MS-SJCI / 3月4日、サンノゼ、CA 95134 Eメール：tahamilt@cisco.com
Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: sjv@laurelnetworks.com
スティーブVogelsangのローレルネットワークス株式会社オメガコーポレートセンター1300オメガドライブピッツバーグ、PA 15205 Eメール：sjv@laurelnetworks.com
John Shirron Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jshirron@laurelnetworks.com
ジョンShirronローレルネットワークス株式会社オメガコーポレートセンター1300オメガドライブピッツバーグ、PA 15205 Eメール：jshirron@laurelnetworks.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066 EMail: tob@netapp.com
トビー・スミスネットワーク・アプライアンス株式会社800クランベリーウッズドライブスイート300クランベリータウンシップ、PA 16066 Eメール：tob@netapp.com
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 EMail: Andy.Malis@tellabs.com
アンドリューG. Malisテラブス90リオロブレス博士サンノゼ、CA 95134 Eメール：Andy.Malis@tellabs.com
Vinai Sirkay Redback Networks 300 Holger Way San Jose, CA 95134 EMail: vsirkay@redback.com
Vinai Sirkayレッドバック・ネットワーク300ホルガー・ウェイサンノゼ、CA 95134 Eメール：vsirkay@redback.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 EMail: vasile@nortelnetworks.com
バシレRadoaca Nortel Networksの600テクノロジーパークビレリカMA 01821 Eメール：vasile@nortelnetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193 EMail: chris.liljenstolpe@alcatel.com
クリスLiljenstolpeアルカテル11600サリーメイ博士は9階レストン、バージニア州20193 Eメール：chris.liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 EMail: dcooper@gblx.net
デイブ・クーパーグローバル・クロッシング960ハムリン法廷サニーベール、CA 94089 Eメール：dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：kireeti@juniper.net
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 EMail: lmartini@cisco.com
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO 80112 Eメール：lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 EMail: nna@level3.net
ナセルエルAawarレベル3コミュニケーションズ、LLC。 1025エルドラドブールバード。ブルームフィールド、CO 80021 Eメール：nna@level3.net
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
エリック・ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 Eメール：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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 HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。