Network Working Group L. Martini
Request for Comments: 4618 E. Rosen
Category: Standards Track Cisco Systems, Inc.
G. Heron
A. Malis
Tellabs
September 2006
Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC) over MPLS Networks
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire.
スードワイヤ（PW）は、PPP / HDLCプロトコルを終端することなく、マルチプロトコル・ラベル・スイッチング（MPLS）ネットワーク上のプロトコル（PPP）またはハイレベルデータリンク制御（HDLC）プロトコルデータユニットをポイントツーポイントを運ぶために使用することができます。これは、サービスプロバイダーは、既存のMPLSネットワーク上でHDLC、またはPPPリンクサービス「エミュレート」を提供することができます。この文書は、疑似回線内のPPP / HDLCパケットデータユニット（PDU）のカプセル化を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Applicability Statement .........................................5
4. General Encapsulation Method ....................................6
4.1. The Control Word ...........................................6
4.2. MTU Requirements ...........................................8
5. Protocol-Specific Details .......................................9
5.1. HDLC .......................................................9
5.2. Frame Relay Port Mode ......................................9
5.3. PPP .......................................................10
6. Using an MPLS Label as the Demultiplexer Field .................11
6.1. MPLS Shim EXP Bit Values ..................................11
6.2. MPLS Shim S Bit Value .....................................11
7. Congestion Control .............................................12
8. IANA Considerations ............................................12
9. Security Considerations ........................................12
10. Normative References ..........................................13
11. Informative References ........................................13
A PPP/HDLC pseudowire (PW) allows PPP/HDLC Protocol Data Units (PDUs) to be carried over an MPLS network. In addressing the issues associated with carrying a PPP/HDLC PDU over an MPLS network, this document assumes that a PW has been set up by some means outside the scope of this document. This may be via manual configuration, or using a signaling protocol such as that defined in [RFC4447].
PPP / HDLC擬似回線（PW）は、PPP / HDLCプロトコルデータユニット（PDU）がMPLSネットワーク上で実施されることを可能にします。 MPLSネットワーク上でPPP / HDLC PDUを運ぶに関連する問題に対処する上で、この文書は、PWは、この文書の範囲外で何らかの手段によって設定されていることを前提としています。これは、[RFC4447]で定義されるような手動設定、またはシグナリングプロトコルを使用してを介してもよいです。
The following figure describes the reference models that are derived from [RFC3985] to support the HDLC/PPP PW emulated services. The reader is also assumed to be familiar with the content of the [RFC3985] document.
次の図は、HDLC / PPP PWエミュレートされたサービスをサポートするために、[RFC3985]に由来する参照モデルを記載しています。読者はまた、[RFC3985]の文書の内容に精通しているものとします。
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]に記載されているように解釈されます。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native HDLC/PPP service native HDLC/PPP service
Figure 1. PWE3 HDLC/PPP interface reference configuration
図1 PWE3 HDLC / PPPインターフェイスリファレンス構成
This document specifies the emulated PW encapsulation for PPP and HDLC; however, quality of service related issues are not discussed in this document. For the purpose of the discussion in this document, PE1 will be defined as the ingress router and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported across the network, decapsulated at PE2, and transmitted out on an attachment circuit at PE2.
このドキュメントは、PPPおよびHDLCのためのエミュレートPWカプセル化を指定します。しかし、サービス関連の問題の質は、このドキュメントで説明されていません。本書では説明のために、PE1は、出口ルータとして入口ルータとPE2として定義されます。レイヤ2 PDUは、PE1で受信PE1でカプセル化された、ネットワークを横切って輸送、PE2でデカプセル化、及びPE2に接続回線上で送信されます。
The following reference model describes the termination point of each end of the PW within the PE:
以下の参照モデルは、PE内PWの各端部の終端点を示します。
+-----------------------------------+
| PE |
+---+ +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
| | |y| | | |on | | | |y|
| C | +-+ +-----+ +------+ +------+ +-+
| E | | |
| | +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+-----------------------------------+
^ ^ ^
| | |
A B C
Figure 2. PW reference diagram
図2 PWの参考図
The PW terminates at a logical port within the PE, defined at point B in the above diagram. This port provides an HDLC Native Service Processing function that will deliver each PPP/HDLC packet that is received at point A, unaltered, to the point A in the corresponding PE at the other end of the PW.
PWは、上図のB点で定義されたPE内の論理ポートで終端します。このポートは、PWの他端に対応するPEの点A、点A、不変で受信される各PPP / HDLCパケットを配信するHDLCネイティブサービス処理機能を提供します。
The Native Service Processing (NSP) function includes packet processing that is required for the PPP/HDLC packets that are forwarded to the PW termination point. Such functions may include bit stuffing, PW-PW bridging, L2 encapsulation, shaping, and policing. These functions are specific to the native packet technology and may not be required for the PW emulation service.
ネイティブサービス処理（NSP）関数は、PW終了ポイントに転送されるPPP / HDLCパケットのために必要とされるパケットの処理を含みます。そのような機能は、ビットスタッフィング、PW-PWブリッジ、L2カプセル化、成形、およびポリシングを含むことができます。これらの機能は、ネイティブパケット技術に固有のものであり、PWエミュレーションサービスのために必要とされない場合があります。
The points to the left of B, including the physical layer between the CE and PE, and any adaptation (NSP) functions between it and the PW terminations, are outside of the scope of PWE3 and are not defined here.
CEおよびPE、およびそれとPW終端との間の適合（NSP）機能との間の物理的な層を含むBの左側の点は、PWE3の範囲外であり、ここで定義されていません。
"PW Termination", between A and B, represents the operations for setting up and maintaining the PW, and for encapsulating and decapsulating the PPP/HDLC packets as necessary to transmit them across the MPLS network.
AとBの間の「PW終了」は、設定およびPWを維持するため、およびMPLSネットワークを介して送信するために、必要に応じてPPP / HDLCパケットをカプセル化及びデカプセル化する動作を表します。
PPP/HDLC transport over PW service is not intended to emulate the traditional PPP or HDLC service perfectly, but it can be used for some applications that require PPP or HDLC transport service.
PWサービス上のPPP / HDLC輸送は完全に伝統的なPPPまたはHDLCのサービスをエミュレートするものではありませんが、それはPPPまたはHDLC輸送サービスを必要とするいくつかの用途に使用することができます。
The applicability statements in [RFC4619] also apply to the Frame Relay port mode PW described in this document.
[RFC4619]での適用性の記述は、PWは、この文書で説明するフレームリレーポートモードに適用されます。
The following are notable differences between traditional PPP/HDLC service, and the protocol described in this document:
以下の伝統的なPPP / HDLCサービス、および本文書に記載されているプロトコル間の顕著な違いは以下のとおりです。
- Packet ordering can be preserved using the OPTIONAL sequence field in the control word; however, implementations are not required to support this feature.
- パケットの順序は制御ワードにオプションのシーケンスフィールドを使用して保存することができます。しかし、実装は、この機能をサポートする必要はありません。
- The Quality of Service model for traditional PPP/HDLC links can be emulated, however this is outside the scope of this document.
- 伝統的なPPP / HDLCリンクのサービスモデルの品質をエミュレートすることができますが、これはこの文書の範囲外です。
- A Frame Relay Port mode PW, or HDLC PW, does not process any frame relay status messages or alarms as described in [Q922] [Q933].
- [Q922] [Q933]で説明したようにフレームリレーポートモードPW、またはHDLC PWは、任意のフレーム・リレー・ステータスメッセージまたはアラームを処理しません。
- The HDLC Flags are processed locally in the PE connected to the attachment circuit.
- HDLCフラグは、接続回線に接続されたPEでローカルに処理されます。
The HDLC mode is suitable for port-to-port transport of Frame Relay User Network Interface (UNI) or Network Node Interface (NNI) traffic. Since all packets are passed in a largely transparent manner over the HDLC PW, any protocol that has HDLC-like framing may use the HDLC PW mode, including PPP, Frame-Relay, and X.25. Exceptions include cases where direct access to the HDLC interface is required, or modes that operate on the flags, Frame Check Sequence (FCS), or bit/byte unstuffing that is performed before sending the HDLC PDU over the PW. An example of this is PPP Asynchronous-Control-Character-Map (ACCM) negotiation.
HDLCモードは、フレーム・リレー・ユーザ・ネットワーク・インタフェース（UNI）またはネットワークノードインタフェース（NNI）トラフィックのポート間の輸送に適しています。すべてのパケットはHDLC PW、PPP、フレームリレー、およびX.25などHDLC PWモードを使用することができるHDLC様のフレーミングを有する任意のプロトコルを介して主に透過的に渡されるからです。例外はPW上HDLC PDUを送信する前に実行されるフラグ、フレームチェックシーケンス（FCS）、またはビット/バイトアンスタッフィングで動作HDLCインタフェースへの直接アクセスが必要な場合、またはモードを含みます。この例は、PPP非同期制御用キャラクタ・マップ（ACCM）交渉です。
For PPP, since media-specific framing is not carried, the following options will not operate correctly if the PPP peers attempt to negotiate them:
メディア固有のフレーミングが行われていないので、PPPピアは、それらを交渉しようとするとPPPについては、次のオプションが正常に動作しません。
- Frame Check Sequence (FCS) Alternatives
- フレームチェックシーケンス（FCS）代替
- Address-and-Control-Field-Compression (ACFC)
- アドレス・アンド・コントロール・フィールド圧縮（ACFC）
- Asynchronous-Control-Character-Map (ACCM)
- 非同期-CONTROL-文字-マップ（ACCM）
Note, also, that PW LSP Interface MTU negotiation, as specified in [RFC4447], is not affected by PPP Maximum Receive Unit (MRU)
[RFC4447]で指定されるようにPW LSPインタフェースMTUネゴシエーション、PPP最大の影響を受けていないが、ユニットを受信すること、また、注（MRU）
advertisement. Thus, if a PPP peer sends a PDU with a length in excess of that negotiated for the PW tunnel, that PDU will be discarded by the ingress router.
広告。したがって、PPPピアはPDUが入口ルータによって破棄されること、PWトンネルのネゴシエートその以上の長さのPDUを送信した場合。
This section describes the general encapsulation format for PPP and HDLC packets over MPLS pseudowires.
このセクションでは、MPLS疑似回線上のPPPおよびHDLCパケットのための一般的なカプセル化形式について説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP/HDLC Service Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. General format for PPP/HDLC encapsulation over PSNs
PSN上のPPP / HDLCカプセル化のために、図3の一般的な形式
The PSN Transport Header depends on the particular tunneling technology in use. This header is used to transport the encapsulated PPP/HDLC information through the packet-switched core.
PSN転送ヘッダは、使用中の特定のトンネリング技術に依存します。このヘッダは、パケット交換コアを介してカプセル化されたPPP / HDLC情報を輸送するために使用されます。
The Pseudowire Header identifies a particular PPP/HDLC service on a tunnel. In case the of MPLS, the Pseudowire Header is the MPLS label at the bottom of the MPLS label stack.
疑似ヘッダは、トンネル上の特定のPPP / HDLCサービスを識別する。 MPLSの場合には、疑似ヘッダは、MPLSラベルスタックの底部のMPLSラベルです。
The Control Word is inserted before the PPP/HDLC service payload. It may contain a length and sequence number.
制御ワードは、PPP / HDLCサービスペイロードの前に挿入されています。これは、長さおよび配列番号が含まれていてもよいです。
There are four requirements that may need to be satisfied when transporting layer 2 protocols over an MPLS PSN:
MPLSのPSNの上にレイヤ2プロトコルを輸送する際に満足する必要があるかもしれない4つの要件があります。
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 packet may need to be transported.
III。レイヤ2パケットのヘッダで運ばれた制御ビットが搬送される必要があるかもしれません。
iv. Creating an in-band associated channel for operation and maintenance communications.
IV。操作およびメンテナンス通信のためのインバンド関連チャネルを作成します。
The Control Word defined in this section is based on the Generic PW MPLS Control Word, as defined in [RFC4385]. It provides the ability to sequence individual packets on the PW and avoidance of equal-cost multiple-path load-balancing (ECMP) [RFC2992] and enables Operations and Management (OAM) mechanisms, including [VCCV].
[RFC4385]で定義されるように、このセクションで定義されたコントロールワードは、一般的なPW MPLS制御ワードに基づいています。これは、個々のPW上のパケットと等価コストマルチパスロードバランシング（ECMP）[RFC2992]の回避を配列決定する能力を提供し、[VCCV]を含む、運用及び管理（OAM）メカニズムを可能にします。
[RFC4385] states, "If a PW is sensitive to packet mis-ordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents packet mis-ordering." This is necessary because ECMP implementations may examine the first nibble after the MPLS label stack to determine whether the content of the labeled packet is IP. Thus, if the PPP protocol number of a PPP packet carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. This may increase out-of-order packets on a given PW or cause OAM packets to follow a different path from that of actual traffic.
[RFC4385]の状態、「PWパケットの誤順序に敏感であり、ECMP経路を選択するために、MPLSペイロードの内容を使用したMPLS PSN上に担持されている場合、それは、パケット誤順序を防止する機構を採用しなければなりません。 " ECMP実装がラベルされたパケットの内容がIPであるかどうかを判断するためにMPLSラベルスタックの後の最初のニブルを調べることができるので、これが必要です。現在の制御ワードなしPWを介して搬送されるPPPパケットのPPPプロトコル番号を0x4または0x6に始まる場合したがって、それは、IPv4またはIPv6パケットのために誤解される可能性があります。これは、コンフィギュレーションおよびMPLSネットワークのトポロジに応じて、与えられたPWのためのすべてのパケットが同じパスに従わない状況につながる可能性があります。これは、与えられたPWでアウトオブオーダーのパケットを増やすか、実際のトラフィックとは異なるパスに従うことをOAMパケットを引き起こす可能性があります。
The features that the control word provides may not be needed for a given PPP/HDLC PW. For example, ECMP may not be present or active on a given MPLS network, and strict packet sequencing may not be required. If this is the case, the control word provides little value and is therefore optional. Early PPP/HDLC PW implementations have been deployed that do not include a control word or the ability to process one if present. To aid in backwards compatibility, future implementations MUST be able to send and receive packets without the control word.
制御ワードが提供する機能は、所与のPPP / HDLC PWのために必要とされなくてもよいです。例えば、ECMPは、所与のMPLSネットワーク上に存在するか、またはアクティブでなくてもよく、厳密パケットシーケンシングが必要とされないかもしれません。この場合、制御ワードはほとんど価値を提供し、従って任意です。初期のPPP / HDLC PWの実装は、制御ワードまたは存在する場合1を処理する能力を含んでいないことに配備されています。下位互換性を助けるために、将来の実装は、制御ワードなしでパケットを送信し、受け取ることができなければなりません。
In all cases, the egress PE MUST be aware of whether the ingress PE will send a control word over a specific PW. This may be achieved by configuration of the PEs, or by signaling, as defined in [RFC4447].
全ての場合において、出口PEは、入口PEが特定のPWを介して制御ワードを送信するかどうかを知っていなければなりません。これは、PEの構成によって、または[RFC4447]で定義されるように、シグナリングすることによって達成することができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. MPLS PWE3 control word
図4. MPLS PWE3制御ワード
In the above diagram, the first 4 bits are set to 0 in indicate a CW [RFC4385].
CW [RFC4385]を示す上記の図では、最初の4ビットは0に設定されています。
The next 4 bits provide space for carrying protocol-specific flags. These are not used for HDLC/PPP, and they MUST be set to 0 for transmitting and MUST be ignored upon receipt.
次の4ビットは、プロトコル固有のフラグを搬送するための空間を提供します。これらは、HDLC / PPPのために使用されていない、と彼らは送信するために0に設定しなければならなくて、領収書で無視しなければなりません。
The next 2 bits are defined in [RFC4623].
次の2ビットが[RFC4623]で定義されています。
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 zero. The value of the length field, if not zero, is used to remove any padding that may have been added by the MPLS network. If the control word is used and padding was added to the packet in transit on the MPLS network, then when the packet reaches the egress PE the padding MUST be removed before forwarding the packet.
次の6ビットは次のように使用される長さフィールドを提供する：（レイヤ2ペイロードの長さを加えた制御ワードの長さとして定義される）、パケットの長さが64バイト未満である場合、長さフィールドに設定する必要がありパケットの長さ。それ以外の場合は、長さフィールドはゼロに設定しなければなりません。長さフィールドの値は、ゼロでない場合、MPLSネットワークによって追加された可能性のある詰め物を除去するために使用されます。制御ワードが使用される場合とパディングがMPLSネットワーク上で転送中のパケットに付加されたパケットが出力PEに到達したときに、その後パディングは、パケットを転送する前に除去しなければなりません。
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.[RFC4385]
次の16ビットは、順序付きパケットの配信を保証するために使用することができるシーケンス番号を提供します。シーケンス番号フィールドの処理は任意である。[RFC4385]
The sequence number space is a 16-bit, unsigned circular space. The sequence number value 0 is used to indicate an unsequenced packet.[RFC4385]
シーケンス番号空間は、16ビット符号なし円形の空間です。シーケンス番号値0はunsequencedパケットを示すために使用される。[RFC4385]
The procedures described in Section 4 of [RFC4385] MUST be followed to process the sequence number field.
[RFC4385]のセクション4に記載された手順は、シーケンス番号フィールドを処理するために従わなければなりません。
The network MUST be configured with an MTU that is sufficient to transport the largest encapsulation packets. When MPLS is used as the tunneling protocol, for example, this is likely to be 12 or more bytes greater than the largest packet size. The methodology described in [RFC4623] MAY be used to fragment encapsulated packets that exceed the PSN MTU. However, if [RFC4623] is not used, then if the ingress router determines that an encapsulated layer 2 PDU exceeds the MTU of the PSN tunnel through which it must be sent, the PDU MUST be dropped.
ネットワークは、最大カプセル化パケットを転送するのに十分であるMTUを設定する必要があります。 MPLSは、トンネリングプロトコルとして使用される場合、例えば、これは、最大パケットサイズよりも大きい12以上のバイトである可能性が高いです。 [RFC4623]に記載の方法は、PSN MTUを超えるカプセル化されたパケットを断片化するために使用されるかもしれません。 [RFC4623]は使用されない場合は、次に、入口ルータは、カプセル化されたレイヤ2 PDUは、それが送信されなければならないを通じてPSNトンネルのMTUを超えていると判断した場合、PDUは破棄されなければなりません。
If a packet is received on the attachment circuit that exceeds the interface MTU subTLV value [RFC4447], it MUST be dropped. It is also RECOMMENDED that PPP devices be configured to not negotiate PPP MRUs larger than that of the AC MTU.
パケットはインターフェイスMTU subTLV値[RFC4447]を超え接続回線上で受信された場合、それは廃棄されなければなりません。また、PPPデバイスがAC MTUよりも大きいPPPのMRUを交渉しないように構成されていることが推奨されます。
HDLC mode provides port-to-port transport of HDLC-encapsulated traffic. The HDLC PDU is transported in its entirety, including the HDLC address and control fields, but excluding HDLC flags and the FCS. Bit/Byte stuffing is undone. If the OPTIONAL control word is used, then the flag bits in the control word are not used and MUST be set to 0 for transmitting and MUST be ignored upon receipt.
HDLCモードはHDLCカプセル化されたトラフィックのポート間の輸送を提供します。 HDLC PDUはHDLCアドレスおよび制御フィールドが、除くHDLCフラグとFCSを含め、その全体に搬送されます。ビット/バイトスタッフィングが取り消されます。オプションの制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信のために0に設定しなければならなくて、受信時に無視しなければなりません。
When the PE detects a status change in the attachment circuit status, such as an attachment circuit physical link failure, or if the AC is administratively disabled, the PE MUST send the appropriate PW status notification message that corresponds to the HDLC AC status. In a similar manner, the local PW status MUST also be reflected in a respective PW status notification message, as described in [RFC4447].
PEは、接続回線の物理リンク障害などの接続回線状態の状態変化を検出した場合、またはACが管理上無効になっている場合、PEは、HDLC AC状態に対応する適切なPW状態通知メッセージを送らなければなりません。 [RFC4447]に記載と同様に、ローカルPWステータスはまた、それぞれのPW状態通知メッセージに反映されなければなりません。
The PW of type 0x0006 "HDLC" will be used to transport HDLC packets. The IANA allocation registry of "Pseudowire Type" is defined in the IANA allocation document for PWs [RFC4446] along with initial allocated values.
タイプ0x0006「HDLC」のPWは、HDLCパケットを転送するために使用されます。 「疑似回線種別」のIANA割当レジストリは、初期割り当て値とともにPWsのためのIANA割当文書[RFC4446]で定義されています。
Figure 5 illustrates the concept of frame relay port mode or many-to-one mapping, which is an OPTIONAL capability.
図5は、フレーム・リレー・ポート・モードまたはオプションの機能である多対1のマッピングの概念を示す図です。
Figure 5a shows two frame relay devices physically connected with a frame relay UNI or NNI. Between their two ports, P1 and P2, n frame relay Virtual Circuits (VCs) are configured.
図5Aは、物理的に、フレームリレーUNIまたはNNIに接続された2つのフレームの中継装置を示します。それらの二つのポート、P1とP2、Nフレームリレー仮想回線（VCS）との間に構成されています。
Figure 5b shows the replacement of the physical frame relay interface with a pair of PEs and a PW between them. The interface between a Frame Relay (FR) device and a PE is either an FR UNI or an NNI. All FR VCs carried over the interface are mapped into one HDLC PW. The standard frame relay Link Management Interface (LMI) procedures happen directly between the CEs. Thus with port mode, we have many-to-one mapping between FR VCs and a PW.
図5Bは、PEのペアとそれらの間のPWと物理フレームリレーインターフェースの交換を示します。フレームリレー（FR）デバイスとPEとの間のインターフェースは、FR UNIまたはNNIのいずれかです。インターフェイス上で搬送される全てのFR VCが1 HDLC PWにマッピングされます。標準フレームリレーリンク管理インターフェイス（LMI）の手順は、CE間で直接起こります。したがって、ポートモードでは、我々はFRのVCとPWの間の多対1のマッピングを持っています。
+------+ +-------+
| FR | | FR |
|device| FR UNI/NNI | device|
| [P1]------------------------[P2] |
| | carrying n FR VCs | |
+------+ +-------+
[Pn]: A port
[オン]：ポート
Figure 5a. FR interface between two FR devices
図5a。 2つのFRデバイス間のFRインターフェイス
|<---------------------------->|
| |
+----+ +----+
+------+ | | One PW | | +------+
| | | |==================| | | |
| FR | FR | PE1| carrying n FR VCs| PE2| FR | FR |
|device|----------| | | |---------|device|
| CE1 | UNI/NNI | | | | UNI/NNI | CE2 |
+------+ +----+ +----+ +------+
| |
|<----------------------------------------------->|
n FR VCs
Figure 5b. Pseudowires replacing the FR interface
図5b。 FRインタフェースを交換するスードワイヤ
FR VCs are not visible individually to a PE; there is no configuration of individual FR VC in a PE. A PE processes the set of FR VCs assigned to a port as an aggregate.
FR VCが個別PEに見えません。 PE内の個々のFR VCのない構成がありません。 PEは、骨材としてのポートに割り当てられたFR VCのセットを処理します。
FR port mode provides transport between two PEs of a complete FR frame using the same encapsulation as described above for HDLC mode.
FRポートモードは、HDLCモードに対して上記と同様のカプセル化を使用して、完全なFRのフレームの2つのPE間の輸送を提供します。
Although frame relay port mode shares the same encapsulation as HDLC mode, a different PW type is allocated in [RFC4446]: 0x000F Frame-Relay Port mode.
0x000Fフレームリレーポート・モード：フレームリレーポートモードはHDLCモードと同じカプセルを共有するが、異なるPWタイプは[RFC4446]に割り当てられています。
All other aspects of this PW type are identical to the HDLC PW encapsulation described above.
このPWタイプのすべての他の態様は、上述したHDLC PWカプセル化と同一です。
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 Protocol Field Compression or not), but excluding any media-specific framing information, such as HDLC address and control fields or FCS.
PPPモードは、[RFC1661]で指定されるように、PPPカプセル化トラフィックのポイント・ツー・ポイントの輸送を提供します。 PPP PDUは、プロトコルフィールド（プロトコルフィールド圧縮を使用して圧縮されているか否か）を含め、その全体を搬送するが、このようなHDLCアドレスおよび制御フィールドやFCSなどの任意のメディア固有のフレーミング情報を除いています。
If the OPTIONAL control word is used, then the flag bits in the control word are not used and MUST be set to 0 for transmitting and MUST be ignored upon receipt.
オプションの制御ワードが使用される場合、制御ワード内のフラグ・ビットは使用されず、送信のために0に設定しなければならなくて、受信時に無視しなければなりません。
When the PE detects a status change in the attachment circuit (AC) status, such as an attachment circuit physical link failure, or if the AC is administratively disabled, the PE MUST send the appropriate PW status notification message that corresponds to the PPP AC status. Note that PPP negotiation status is transparent to the PW and MUST NOT be communicated to the remote MPLS PE. In a similar manner, the local PW status MUST also be reflected in a respective PW status notification message, as described in [RFC4447].
PEは、接続回線の物理リンク障害としてアタッチメント回路（AC）の状態、状態変化を検出し、又はACが管理上無効になっている場合、PEは、PPP AC状態に対応する適切なPW状態通知メッセージを送信する必要がある場合。 PPPネゴシエーション状態がPWに透明であり、リモートMPLS PEに伝達されてはならないことに注意してください。 [RFC4447]に記載と同様に、ローカルPWステータスはまた、それぞれのPW状態通知メッセージに反映されなければなりません。
A PW of type 0x0007 "PPP" will be used to transport PPP packets.
タイプ0x0007のPWは「PPPは、」PPPパケットを転送するために使用されます。
The IANA allocation registry of "Pseudowire Type" is defined in the IANA allocation document for PWs [RFC4446] along with initial allocated values.
「疑似回線種別」のIANA割当レジストリは、初期割り当て値とともにPWsのためのIANA割当文書[RFC4446]で定義されています。
To use an MPLS label as the demultiplexer field, a 32-bit label stack entry [RFC3032] is simply prepended to the emulated PW encapsulation and thus appears as the bottom label of an MPLS label stack. This label may be called the "PW label". The particular emulated PW identified by a particular label value must be agreed by the ingress and egress LSRs, either by signaling (e.g., via the methods of [RFC4447]) or by configuration. Other fields of the label stack entry are set as described below.
デマルチプレクサフィールドとしてMPLSラベルを使用する、32ビットのラベルスタックエントリー[RFC3032]は、単純にエミュレートされたPWカプセル化の前に付加し、従ってMPLSラベルスタックの底ラベルとして表示されます。このラベルは、「PWラベル」と呼ばれることもあります。特定のラベルの値によって識別される特定のエミュレートされたPW（例えば、[RFC4447]の方法を介して）シグナリングによって、またはコンフィギュレーションのいずれかによって、入口と出口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 PW label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack MUST also carry the same value.
それは、サービス情報の品質を運ぶために必要な場合は、サービス情報の品質は、PWラベルのEXPフィールドに表現できるようにして下さい。複数のMPLSラベルがイングレスLSRによって課された場合、スタックの上位の任意のラベルのEXPフィールドも同じ値を運ばなければなりません。
The ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to denote that the PW label is at the bottom of the stack.
入口LSR、PE1は、PWラベルがスタックの一番下にあることを示すために1の値にPWラベルのSビットを設定しなければなりません。
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, the characteristics of which are dependent upon PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the PPP/HLDC PW. In addition, since PPP/HDLC PWs carry an unspecified type of services across the PSN, they cannot behave in a TCP-friendly manner prescribed by [RFC2914]. In the presence of services that reduce transmission rate, PPP/HDLC PWs will thus consume more than their fair share and SHOULD be halted.
[RFC3985]で説明したように、PWを運ぶPSNは混雑を受ける可能性の特性は、PSNタイプ、ネットワークアーキテクチャ、構成、およびローディングに依存します。混雑時には、PSNは、PPP / HLDC PWによって運ばれるサービスに影響を与えるパケット損失を示すことができます。 PPP / HDLCのPWSはPSNの向こうサービスの不特定のタイプを運ぶため、また、彼らは[RFC2914]で規定TCPフレンドリーように動作することはできません。伝送速度を下げるサービスの存在下で、PPP / HDLC PWのはこのように彼らの公正な取り分より多くを消費しますし、停止するべきです。
Whenever possible, PPP/HDLC PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the PPP/HDLC PW's effects from neighboring streams.
可能な限り、PPP / HDLC PWSが、帯域幅の割り当てとアドミッション制御メカニズムを提供するトラフィックエンジニアリングのPSN上で実行する必要があります。 EF（優先転送）を使用して保証サービス（GS）またはDiffServの対応のドメインを提供イントサーブ対応のドメインは、トラフィックエンジニアリングのPSNの例です。隣接するストリームからPPP / HDLC PWの効果の分離をある程度提供しながら、このようなのPSNは、損失および遅延を最小化します。
The PEs SHOULD monitor for congestion (by using explicit congestion notification, [VCCV], or by measuring packet loss) in order to ensure that the service using the PPP/HDLC PW may be maintained. When significant congestion is detected, the PPP/HDLC PW SHOULD be administratively disabled. If the PW has been set up using the protocol defined in [RFC4447], then procedures specified in [RFC4447] for status notification can be used to disable packet transmission on the ingress PE from the egress PE. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time.
PEはPPP / HDLC PWを使用してサービスを維持することができることを確実にするために（明示的輻輳通知を用いて、[VCCV]、またはパケット損失を測定することにより）、輻輳を監視すべきです。重大な輻輳が検出された場合、PPP / HDLC PWは管理上無効にする必要があります。 PWは[RFC4447]で定義されたプロトコルを使用して設定されている場合は、ステータス通知に[RFC4447]で指定された手順は、出口PEから入口PEにパケットの送信を無効にするために使用することができます。 PWは適切な待ち時間の後に手動での介入によって、または自動手段によって再起動することができます。
This document has no new IANA Actions. All necessary IANA actions have already been included in [RFC4446].
この文書は、新しいIANAのアクションを持っていません。すべての必要なIANAのアクションは、すでに[RFC4446]に含まれています。
The PPP and HDLC pseudowire type is subject to all the general security considerations discussed in [RFC3985][RFC4447]. This document specifies only encapsulations, and not the protocols that may be used to carry the encapsulated packets across the MPLS network. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein.
PPPおよびHDLC疑似回線の種類は[RFC3985]、[RFC4447]で説明するすべての一般的なセキュリティ問題を受けます。この文書では、唯一のカプセル化、およびないMPLSネットワーク上のカプセル化されたパケットを運ぶために使用されるプロトコルを指定します。各そのようなプロトコルは、セキュリティ上の問題の独自のセットを持っている可能性がありますが、これらの問題は、ここで指定されたカプセル化の影響を受けません。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[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月。
[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月。
[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月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[RFC4447] Martini, L., 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.サギ、 "ラベル配布プロトコル（LDP）を使用して、擬似回線の設定とメンテナンス"、RFC 4447、2006年4月マティーニ。
[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月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623] Malis、A.およびM. Townsley、 "擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）フラグメンテーションおよび再構成"、RFC 4623、2006年8月。
[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995.
[Q922]フレームモード基本呼制御のためのITU-T勧告Q.922仕様、1995年ITUジュネーブ。
[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode Basic call control, ITU Geneva 2003.
[Q933]フレームモード基本呼制御のためのITU-T勧告Q.933仕様、2003年ITUジュネーブ。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[RFC2992] Hoppsが、C.、 "等価コストマルチパスアルゴリズムの分析"、RFC 2992、2000年11月。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.、エド。そして、P.パテ、エド。、「疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[VCCV] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Work in Progress, October 2005.
[VCCV]ナドー、T.、ら、 "疑似ワイヤー仮想回線接続の検証（VCCV）"、進歩、2005年10月に作業。
Contributing Author Information
貢献者の情報
Yeongil Seo 463-1 KT Technology Lab Jeonmin-dong Yusung-gu Daegeon, Korea
Yeongilソ463-1 KTテクノロジーラボJeonmin洞YUSUNG区Daegeon、韓国
EMail: syi1@kt.co.kr
メールアドレス：syi1@kt.co.kr
Toby Smith Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
トビー・スミスローレルネットワークス株式会社オメガコーポレートセンター1300オメガドライブピッツバーグ、PA 15205
EMail: tob@laurelnetworks.com
メールアドレス：tob@laurelnetworks.com
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
ジャイルズヘロンテラブスアビー場所24-28イーストンストリートハイウィコムバックスHP11 1NT英国
EMail: giles.heron@tellabs.com
メールアドレス：giles.heron@tellabs.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
アンドリューG. Malisテラブス1415西ディール道路ネーパーヴィル、IL 60563
EMail: Andy.Malis@tellabs.com
メールアドレス：Andy.Malis@tellabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。