RFC4905 日本語訳
4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLSNetworks. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT=40020 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
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
エド、ワーキンググループL.マティーニをネットワークでつないでください。コメントのために以下を要求してください。 4905 エドE.ローゼン、カテゴリ: 歴史的なシスコシステムズInc.N.高架鉄道-Aawar、エドレベル3 コミュニケーション、LLC2007年6月
Encapsulation Methods for Transport of
Layer 2 Frames over MPLS Networks
MPLSネットワークの上の層2のフレームの輸送のためのカプセル化方法
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.
このメモはインターネットコミュニティのためにHistoric Documentを定義します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはFrame Relay、Asynchronous Transfer Mode(ATM)、またはMPLSの向こう側の輸送のためのイーサネットなどの2つのプロトコルがネットワークでつなぐ層のプロトコルData Units(PDUs)を要約するための方法を説明します。 このドキュメントはいわゆる「草稿マティーニ」プロトコルについて説明します。(それは、以来、Pseudowire Emulation EdgeによってRFC4447と関連するドキュメントで説明されたEdge作業部会仕様に取って代わられています)。
Martini, et al. Historic [Page 1] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[1ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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
1. 序論…3 2. 要件の仕様…3 3. 特別な注意…4 4. 一般カプセル化方法…4 4.1. コントロールWord…4 4.1.1. 一連番号を設定します…5 4.1.2. 一連番号を処理します…6 4.2. MTU要件…6 5. プロトコル特有の詳細…7 5.1. フレームリレー…7 5.2. 気圧…8 5.2.1. 気圧AAL5 CPCS-SDUモード…9 5.2.2. 気圧セルモード…10 5.2.3. OAMセルサポート…12 5.2.4. CLPはService MappingのQualityに噛み付きました…12 5.3. イーサネットVLAN…12 5.4. イーサネット…12 5.5. ハイレベル・データ・リンク制御手順(HDLC)…13 5.6. ppp…13 6. デマルチプレクサ分野としてMPLSラベルを使用します…13 6.1. MPLS詰め物のEXPは値に噛み付きました…14 6.2. MPLS詰め物Sは値に噛み付きました…14 6.3. MPLS詰め物のTTL値…14 7. セキュリティ問題…14 8. 標準の参照…14 9. 有益な参照…16 10. 共同執筆します。16
Martini, et al. Historic [Page 2] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[2ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
1. Introduction
1. 序論
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ネットワークでは、ネットワークの向こう側に層2のプロトコルのプロトコルData Unitsを運ぶ「見習われた仮想のサーキット」をセットアップするために[RFC4906]で指定されたものなどの制御プロトコルを使用するのは可能です。 これらの多くの見習われた仮想のサーキット(VCs)が単一のトンネルで運ばれるかもしれません。 これは、もちろん2PDUs層がカプセルに入れられるのを必要とします。 私たちはこのカプセル化の3つの層を区別できます:
- 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、Genericルート設定Encapsulation(GRE)、およびLayer2Tunnelingプロトコル(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.
- 「デマルチプレクサ分野」(それは、単一のトンネルの中で個々の見習われた仮想のサーキットを区別するのに使用されます)。 また、トンネリングプロトコルにこの分野を解釈しなければなりません。 それがそうであり、例えば、MPLSはラベルかGREキーフィールドです。
- 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のプロトコルを見習うのに必要な2PDUの同封の層の情報を含む「見習われた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と定義されるでしょう。 2PDU層は、R1に受け取られて、R1で要約されて、輸送されて、R2でdecapsulatedされて、R2から伝えられるでしょう。
2. Specification of Requirements
2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Martini, et al. Historic [Page 3] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[3ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
3. Special Note
3. 特別な注意
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.
このドキュメントはいわゆる「草稿マティーニ」プロトコルについて説明します。(それは、多くの配備された実現に使用されます)。 このドキュメントとそのコンテンツは以来、Pseudowire Emulation EdgeによってEdge作業部会仕様に取って代わられています: [RFC4447]、[RFC4385]、[RFC4448]、[RFC4717]、[RFC4618]、[RFC4619]、[RFC4553]、[RFC4842]、および関連するドキュメント。 このドキュメントは、現在の実現のドキュメンテーションとして機能して、新しい実現に使用されてはいけません。 このプロトコルのすべての新しい実現に、PWE3 Label Distributionプロトコル制御プロトコルドキュメント[RFC4447](このドキュメントと互換性があった状態で後方である)を使用しなければなりません。
4. General Encapsulation Method
4. 一般カプセル化方法
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まで既に合図されたかもしれない情報と同様に。
4.1. The Control Word
4.1. コントロールWord
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.
-i。 Sequentialityは、保存される必要があるかもしれません。
-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つの要件を記述します。 いくつかのプロトコル、この単語がREQUIREDであり、および他のものOPTIONALのために。 規制単語がOPTIONALであるプロトコルのために、実現は、規制知らせを全く送るのを支持してはいけなくて、規制知らせを送るのを支持するかもしれません。
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]で定義されるようにルータの構成かシグナリングによって達成されるかもしれません。
Martini, et al. Historic [Page 4] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[4ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 旗|0 0| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットは命令されたパケット配信を保証するのに使用できる一連番号を提供します。 一連番号分野の処理はOPTIONALです。
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は、非配列されたパケットを示すのに使用されます。
4.1.1. Setting the Sequence Number
4.1.1. 一連番号を設定します。
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:
1組のルータの与えられた見習われたVC、R1、およびR2のために、R1がパケット順序制御を支持するなら、以下の手順は用いられるべきです:
- The initial packet transmitted on the emulated VC MUST use
sequence number 1.
- 初期のパケットは見習われたVC MUST使用のときに一連番号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に包装するか。
Martini, et al. Historic [Page 5] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[5ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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に設定しなければなりません。
4.1.2. Processing the Sequence Number
4.1.2. 一連番号を処理します。
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;
次に、(予想された_系列_番号=0)が_系列_数の:=1を予想したなら、_系列_数の:=パケット_系列_数+1モッズ2**16は予想しました。
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が支持しないルータが一連番号処理を受けるなら、一連番号分野は無視されるかもしれません。
4.2. MTU Requirements
4.2. MTU要件
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
最も大きいカプセル化フレームを輸送するために十分なMTUでネットワークを構成しなければなりません。 MPLSがトンネリングプロトコルとして使用されるなら、例えば、これは最も大きいフレーム・サイズより12バイト以上すばらしい傾向があります。 他のトンネリングプロトコルは、より長いヘッダーがあって、より大きいMTUsを必要とするかもしれません。 イングレスです。
Martini, et al. Historic [Page 6] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[6ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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.
ルータは、それを送らなければならない2PDUがトンネルのMTUを超えている要約の層、PDU MUSTが落とされることを決定します。 出口ルータが受信されるなら、ペイロード長(すなわち、カプセル化ヘッダーのどれかのないPDU自身の長さ)の2PDUの要約の層は目的地層2のインタフェースのMTUを超えています、PDU MUST。落とされます。
5. Protocol-Specific Details
5. プロトコル特有の詳細
5.1. Frame Relay
5.1. フレームリレー
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.
Frame Relay PDUはFrame RelayヘッダーもFrame Check Sequence(FCS)なしで輸送されます。 規制単語はREQUIREDです。 しかしながら、望ましいのですが、使用は任意です。 規制単語の使用は、イングレスと出口Label Switching Routers(LSRs)が以下の手順に従うことを意味します。 イングレスであるなら、LSRは、規制単語を使用しないのを選んで、0に対する規制単語に旗をはめ込まなければなりません。 出口であるなら、LSRは、規制単語を無視するのを選んで、それはFrame Relayコントロールビットを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(後方のExplicit Congestion Notification)、FECN(前進のExplicit Congestion Notification)、DE(Eligibilityを捨てる)、およびC/R(コマンド/応答)ビットは規制単語によるネットワークの向こう側に運ばれます。 ここに説明されたカプセル化を加えるか、または取り除くとき、このドキュメントを実行する縁のルータは、Frame Relay Committed情報Rateの縁の取り締まりからのマークを反映するのが縁のルータ、および0〜1までのD/Eビットに知られているネットワークに混雑を反映するためにBECN、そして/または、FECNビットを0〜1に変えるかもしれません。 BECN、FECN、およびD/EビットSHOULD NOT、1〜0に変えてください。
The following is an example of a Frame Relay packet:
↓これはFrame Relayパケットに関する例です:
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 |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フレームリレーPDU| | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Martini, et al. Historic [Page 7] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[7ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
* 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、SHOULDは入って来るFrame Relayヘッダーをこの分野に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、SHOULDは入って来るFrame Relayヘッダーをこの分野に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、SHOULDは入って来るFrame Relayヘッダーをこの分野に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.
その分野の値を決定するとき、トンネリングプロトコルがServiceのQualityを指定するように設定できる野原を供給するなら、イングレスルータ(R1)はFrame RelayヘッダーのDEビットを考えるかもしれません。 そして、2PDU層を出口へ列に並ばせるとき、出口ルータはこの分野の値を考えるかもしれません。 しかしながら、同じVC MUST NOTからのフレームが再命令されることに注意してください。
* 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、SHOULDは容認されたFrame Relay PDUから規制単語のCビットまでC/Rビットをコピーします。 出口ルータ(R2)は出力フレームにCビットをコピーしなければなりません。
5.2. ATM
5.2. 気圧
Two encapsulations are supported for ATM transport: one for ATM Adaption Layer 5 (AAL5) and another for ATM cells.
2つのカプセル化がATM輸送のために支持されます: ATM Adaption Layer5(AAL5)のためのものとATMセルのための別。
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 Common Part Convergence Sublayer--サービスData Unit(CPCS-SDU)カプセル化はREQUIRED規制単語とAAL5 CPCS-SDUから成ります。 ATMセルカプセル化はOPTIONAL規制単語、4バイトのATMセルヘッダー、およびATMセルペイロードから成ります。
Martini, et al. Historic [Page 8] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[8ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
5.2.1. ATM AAL5 CPCS-SDU Mode
5.2.1. 気圧AAL5 CPCS-SDUモード
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-SDUsを組み立て直して、単一のパケットとして各CPCS-SDUを輸送するのに必要です。 AAL5トレーラは全く輸送されません。 規制単語はREQUIREDです。 望ましいのですが、しかしながら、使用は任意です。 規制単語の使用は、イングレスと出口LSRsが以下の手順に従うことを意味します。 イングレスであるなら、LSRは、規制単語を使用しないのを選んで、0に対する規制単語に旗をはめ込まなければなりません。 出口であるなら、LSRは、規制単語を無視するのを選んで、それはATMコントロールビットを0に設定しなければなりません。
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(明白なForward Congestion Indication)とCLP(セルLoss Priority)ビットは規制単語によるネットワークの向こう側に運ばれます。 ここに説明されたカプセル化を加えるか、または取り除くとき、このドキュメントを実行する縁のルータは、ATM Sustained Cell Rateの縁の取り締まりからのマークを反映するのが縁のルータ、および0〜1までのCLPビットに知られているネットワークに混雑を反映するためにEFCIビットを0〜1に変えるかもしれません。 EFCIとCLPビットは1〜0に変わってはいけません。
The AAL5 CPCS-SDU is prepended by the following header:
AAL5 CPCS-SDUは以下のヘッダーによってprependedされます:
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 |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 気圧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の上でOperationsとManagement(OAM)の機能性を可能にする手段を提供することを意図します。
Martini, et al. Historic [Page 9] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[9ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
* 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.
イングレスルータ、R1、AAL5 CPCS-SDUを輸送したものの最終的なセルのEFCIかけらが1に設定されるか、またはパケットで輸送されるべき単一のATMセルのEFCIかけらが1に設定されるなら、SHOULDはこのビットを1に設定します。 さもなければ、これはSHOULDに噛み付きました。0に、用意ができています。 出口ルータ、R2、SHOULDはこの分野に保管されていた値にAAL5 CPCS-SDUを輸送するすべてのセルのEFCIかけらを設定します。
* 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に設定されるか、またはパケットで輸送されるべき単一のATMセルのCLPかけらが1に設定されるなら、SHOULDはこのビットを1に設定します。 さもなければ、これはSHOULDに噛み付きました。0に、用意ができています。 出口ルータ、R2、SHOULDはこの分野に保管されていた値にAAL5 CPCS-SDUを輸送するすべてのセルのCLPかけらを設定します。
* 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.1Frame Relay / ATM PVC Service Interworkingである、[FRF、.8、.1、]、交通が輸送することにされるのである、AAL5 CPCS-SDUのCPCS-UU Least Significant Bit(LSB)はFrame Relay C/Rビットを含むかもしれません。 イングレスルータ、R1、SHOULDは規制単語のCビットにこのビットをコピーします。 出口ルータ、R2、SHOULDはAAL5 CPCS PDUのCPCS-UU Least Significant Bit(LSB)にCビットをコピーします。
5.2.2. ATM Cell Mode
5.2.2. 気圧セルモード
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セルはSegmentationとReassembly(SAR)の過程なしで個別に輸送されます。 ATMセルカプセル化はOPTIONAL規制単語、および1つ以上のATMセルから成ります--それぞれの4バイトのATMセルヘッダーから成って、48バイトATMセルペイロード。 このATMセルヘッダーはFASTカプセル化[FAST]部3.1の.1で定義されますが、トレーラバイトなしで定義されます。 それぞれのフレームの長さはカプセル化ヘッダーがなければ52バイト長の倍数です。 フレームでこんなやり方で取り付けることができるATMセルの最大数は単にネットワークMTUと出口ルータがそれらを処理する能力によって制限されます。 イングレスルータは受けるより構わない出口ルータが、思っている多くのセルを送ってはいけません。 出口ルータが受けても構わないと思っているセルの数は、イングレスルータで構成されるか、または例えば、[RFC4906]で説明された方法を使用することで合図されるかもしれません。 フレームの長さで特定のフレームでカプセルに入れられたセルの数を推論できます。 規制単語はOPTIONALです。
Martini, et al. Historic [Page 10] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[10ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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セルヘッダーでネットワークの向こう側に運ばれます。 ここに説明されたカプセル化を加えるか、または取り除くとき、このドキュメントを実行する縁のルータは、ATM Sustained Cell Rateの縁の取り締まりからのマークを反映するのが縁のルータ、および0〜1までのCLPビットに知られているネットワークに混雑を反映するためにEFCIビットを0〜1に変えるかもしれません。 EFCIとCLPビットSHOULD NOT、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 ) |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 規制単語(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI| VCI| PTI|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM有効搭載量(48バイト)| | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI| VCI| PTI|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM有効搭載量(48バイト)| | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 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分野をこの分野に入って来るセルを回避しなければなりません。 特定の見習われたVCsに関しては、出口ルータは、新しい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分野を回避しなければなりません。 特定の見習われたVCsに関しては、出口ルータは新しいVCIを発生させるかもしれません。
Martini, et al. Historic [Page 11] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[11ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
* 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分野です。 パケットの中のセルのセルヘッダーは入って来るセルのATMヘッダー(HECのない)です。
5.2.3. OAM Cell Support
5.2.3. OAMセルサポート
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で輸送されるかもしれません。 OAMセルの輸送を支持しない出口ルータはPTI分野セットの高位のビットでATMセルを含むフレームを1に捨てなければなりません。 OAMセルの輸送を支持するルータはモード0だけのために[FAST]セクション8で概説された手順に従わなければなりません、[RFC4906]で指定された適切な手順に加えて。
5.2.4. CLP bit to Quality of Service Mapping
5.2.4. Service MappingのQualityに噛み付かれたCLP
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.
値が要約プロトコルのService分野(例えば、MPLSラベルスタックのEXP分野)のQualityに置かれることを決定するとき、イングレスルータはCLPビットを考えるかもしれません。 これはCLPビットのネットワーク目に見えることを与えます。 しかしながら、同じVC MUST NOTからのセルが再命令されることに注意してください。
5.3. Ethernet VLAN
5.3. イーサネットVLAN
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のない全体のイーサネットフレームは単一のパケットとして輸送されます。 規制単語はOPTIONALです。 規制単語が使用されているなら、存在という規制単語によるフラグビットは、使用されて、伝わるとき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分野のQualityに置かれることを決定するとき、イングレスルータは、ユーザ優先権がVLANタグヘッダーの分野[IEEE802.3ac]であると考えるかもしれません。 出口へパケットを列に並ばせるとき、同様の方法で、出口ルータは要約プロトコルのService分野のQualityを考えるかもしれません。 入力されて、パケットを捨てなければならない誤り、またはちびを罪に陥れて、ハードウェアレベルCyclic Redundancy Check(CRC)誤りを含むイーサネットパケット。
5.4. Ethernet
5.4. イーサネット
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のない全体のイーサネットフレームは単一のパケットとして輸送されます。 規制単語はOPTIONALです。 規制単語が使用されているなら、存在という規制単語によるフラグビットは、使用されて、伝わるとき0に設定しなければならなくて、領収書で無視されてはいけません。 イーサネット
Martini, et al. Historic [Page 12] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[12ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
VLAN case, Ethernet packets with hardware-level CRC errors, framing errors, and runt packets MUST be discarded on input.
入力のときにVLANケース、ハードウェアレベルCRC誤りがあるイーサネットパケット、縁どり誤り、およびちびのパケットを捨てなければなりません。
5.5. High-Level Data Link Control (HDLC)
5.5. ハイレベル・データ・リンク制御手順(HDLC)
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を除いて。 ビット/バイト詰め物は元に戻されます。 規制単語はOPTIONALです。 規制単語が使用されているなら、存在という規制単語によるフラグビットは、使用されて、伝わるとき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.
ポートがFrame Relay User-ネットワークInterface(UNI)かNetwork-ネットワークInterface(NNI)交通の輸送を移植するのにおいてHDLCモードは適当です。 しかしながら、このモードがFECN、BECN、およびDEビットに見え透いていることに注意しなければなりません。
5.6. PPP
5.6. ppp
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 Interface MTU交渉がPPP Maximum Receive Unit(MRU)広告で影響を受けないことに注意してください。 したがって、PPP同輩がVC LSPのために交渉されたそれを超えた長さと共にPDUを送ると、その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.
規制単語はOPTIONALです。 規制単語が使用されているなら、存在という規制単語によるフラグビットは、使用されて、伝わるとき0に設定しなければならなくて、領収書で無視されてはいけません。
6. Using an MPLS Label as the Demultiplexer Field
6. デマルチプレクサ分野としてMPLSラベルを使用します。
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
32ビットのラベルスタックエントリー[RFC3032]は、デマルチプレクサ分野としてMPLSラベルを使用するために、単に見習われたVCカプセル化にprependedされて、したがって、MPLSラベルスタックの化粧紙として現れるでしょう。 このラベルは「VCラベル」と呼ばれるかもしれません。 特定の見習われたVC
Martini, et al. Historic [Page 13] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[13ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
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.
値がそうしなければならない特定のラベルによって特定されて、イングレスと出口LSRs、シグナリング(例えば、[RFC4906]の方法を通した)または構成によって同意されてください。 ラベルスタックエントリーの他の分野は以下の通り設定されます。
6.1. MPLS Shim EXP Bit Values
6.1. MPLS詰め物のEXPビット値
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.
Service情報のQuality、Service情報SHOULDのQualityを運ぶのが必要であるなら、VCラベルのEXP分野に表されてください。 1個以上のMPLSラベルがイングレスLSRによって課されるなら、いずれのEXP分野は同じ値をまたSHOULDが運ぶスタックで、より高くラベルします。
6.2. MPLS Shim S Bit Value
6.2. MPLS詰め物のSビット価値
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)は、1の値へのVCラベルのSビットにVCラベルがスタックの下部にあるのを指示するように設定しなければなりません。
6.3. MPLS Shim TTL Values
6.3. MPLS詰め物のTTL値
The ingress LSR, R1, SHOULD set the TTL field of the VC label to a value of 2.
イングレスLSR、R1、SHOULDはVCラベルのTTL分野を2の値に設定します。
7. Security Considerations
7. セキュリティ問題
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で説明されます。
8. Normative References
8. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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]マティーニ、L.(エド)、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、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.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
Martini, et al. Historic [Page 14] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[14ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
[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.カメレオンマン、「パケット(CEP)の上の同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)サーキットエミュレーション」RFC4842(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)」、RFC4553、6月2006日
[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.(エド)、Kawa、C.(エド)、およびA.Malis(エド)、「Multiprotocolの上のフレームリレーの輸送のためのカプセル化方法は切り換え(MPLS)をネットワークとラベルします」、RFC4619、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] マティーニ、L.、Jayakumar、J.、Bocci、M.、高架鉄道-Aawar、N.、Brayley、J.、およびG.Koleyni、「MPLSネットワークの上の非同期通信モード(気圧)の輸送のためのカプセル化方法」、RFC4717(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、「MPLSネットワークの上のppp/ハイレベル・データ・リンク制御手順(HDLC)の輸送のためのカプセル化方法」、RFC4618(2006年9月)。
[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ネットワークの上のイーサネットの輸送のためのカプセル化方法」RFC4448(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(エド)、「層2の輸送はMPLSの上で縁どっています」、RFC4906、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ラベルスタックコード化」、RFC3032(2001年1月)。
[FRF.8.1] Frame Relay Forum, "Frame Relay / ATM PVC Service
Interworking Implementation Agreement", February 2000.
[FRF、.8、.1、]、フレームリレーフォーラム、「実現協定を織り込むフレームリレー/気圧PVCサービス」、2月2000日
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport
(FAST)", af-fbatm-0151.000, July 2000.
[FAST]ATM Forum、「Sonet/SDH輸送(速い)の上のフレームのベースの気圧」、af-fbatm-0151.000、2000年7月。
Martini, et al. Historic [Page 15] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[15ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
[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、「情報技術--地方とシステム--メトロポリタンエリアネットワークの間のテレコミュニケーションと情報交換--決められた一定の要求Part3:」 「Virtual Bridgedローカル・エリア・ネットワーク(VLAN)のための衝突検出(CSMA/CD)フレーム拡大が802.3でネットワークにタグ付けをしている搬送波感知多重アクセス。」
9. Informative References
9. 有益な参照
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
10. Co-Authors
10. 共著者
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK EMail: giles.heron@tellabs.com
ジャイルスのサギのTellabs修道院の地域24-28イーストン通りハイウィカムバックスHP11 1NTイギリスはメールされます: giles.heron@tellabs.com
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 EMail: d@mazunetworks.com
ディミトリストラットンVlachosマヅはケンブリッジ、MA 02140がメールするInc.125Cambridgeparkドライブをネットワークでつなぎます: d@mazunetworks.com
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: tappan@cisco.com
マサチューセッツ通りBoxborough、ダンタッパンシスコシステムズInc.1414MA 01719はメールされます: tappan@cisco.com
Jayakumar Jayakumar Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA 95134 EMail: jjayakum@cisco.com
Jayakumar JayakumarシスコシステムズInc.225、E.タスマン、MS-SJ3/3、サンノゼ、カリフォルニア 95134はメールされます: jjayakum@cisco.com
Martini, et al. Historic [Page 16] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[16ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
Alex Hamilton Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA 95134 EMail: tahamilt@cisco.com
アレックスハミルトンシスコシステムズ株式会社285のW.タスマン、さん-SJCI/3/4、サンノゼ、カリフォルニア 95134はメールされます: tahamilt@cisco.com
Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: sjv@laurelnetworks.com
スティーブ・フォーゲルザング・ローレルはピッツバーグ、PA 15205がメールする1300年のInc.のオメガの法人のセンターオメガドライブをネットワークでつなぎます: sjv@laurelnetworks.com
John Shirron Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jshirron@laurelnetworks.com
ジョン・Shirronローレルはピッツバーグ、PA 15205がメールする1300年のInc.のオメガの法人のセンターオメガドライブをネットワークでつなぎます: jshirron@laurelnetworks.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066 EMail: tob@netapp.com
トビースミスネットアプライアンスInc.800クランベリー森はスイート300クランベリー郡区を運転して、PA 16066はメールされます: tob@netapp.com
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 EMail: Andy.Malis@tellabs.com
サンノゼ、アンドリューG.Malis Tellabs90リオロブレスカリフォルニア博士 95134はメールします: Andy.Malis@tellabs.com
Vinai Sirkay Redback Networks 300 Holger Way San Jose, CA 95134 EMail: vsirkay@redback.com
Vinai Sirkay20ドル紙幣はサンノゼ、カリフォルニア 95134がメールされる300オルガーWayをネットワークでつなぎます: vsirkay@redback.com
Martini, et al. Historic [Page 17] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[17ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 EMail: vasile@nortelnetworks.com
技術公園ビルリカMA 01821がメールするバシレRadoacaノーテルネットワーク600: vasile@nortelnetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193 EMail: chris.liljenstolpe@alcatel.com
Floorレストン、クリスLiljenstolpeアルカテル11600学生金融公庫博士の第9ヴァージニア 20193はメールします: chris.liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 EMail: dcooper@gblx.net
デーヴ・桶屋グローバルクロッシング960ハムリン法廷サニーベル、カリフォルニア 94089はメールされます: dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Aveサニーベル、カリフォルニア 94089がメールするKireeti Kompella杜松ネットワーク1194N.マチルダ: kireeti@juniper.net
Martini, et al. Historic [Page 18] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[18ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
Authors' Addresses
作者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 EMail: lmartini@cisco.com
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112はメールされます: lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 EMail: nna@level3.net
LLC、ナセル高架鉄道-Aawarは3つのコミュニケーションを平らにします。 1025 エルドラドBlvd. ブルームフィールド、CO 80021はメールされます: nna@level3.net
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
マサチューセッツ通りBoxborough、エリックローゼンシスコシステムズInc.1414MA 01719はメールされます: erosen@cisco.com
Martini, et al. Historic [Page 19] RFC 4905 Encapsulation for L2 Frames over MPLS June 2007
マティーニ、他 L2のための歴史的な[19ページ]RFC4905カプセル化は2007年6月にMPLSの上で縁どられます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Martini, et al. Historic [Page 20]
マティーニ、他 歴史的[20ページ]
一覧
スポンサーリンク
