Network Working Group                                    L. Martini, Ed.
Request for Comments: 4619                           Cisco Systems, Inc.
Category: Standards Track                                   C. Kawa, Ed.
                                                       Oz Communications
                                                           A. Malis, Ed.
                                                          September 2006

Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (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).

Copyright(C)The Internet Society(2006)。



A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network.


Table of Contents


   1. Introduction ....................................................2
   2. Specification of Requirements ...................................4
   3. Co-authors ......................................................4
   4. Acronyms and Abbreviations ......................................5
   5. Applicability Statement .........................................5
   6. General Encapsulation Method ....................................6
   7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
      7.1. MPLS PSN Tunnel and PW .....................................7
      7.2. Packet Format over MPLS PSN ................................7
      7.3. The Control Word ...........................................8
      7.4. The Martini Legacy Mode Control Word .......................9
      7.5. PW Packet Processing .......................................9
           7.5.1. Encapsulation of Frame Relay Frames .................9
           7.5.2. Setting the Sequence Number ........................10
      7.6. Decapsulation of PW Packets ...............................11
           7.6.1. Processing the Sequence Number .....................11
           7.6.2. Processing of the Length Field by the Receiver .....11
      7.7. MPLS Shim EXP Bit Values ..................................12
      7.8. MPLS Shim S Bit Value .....................................12
      7.9. Control Plane Details for Frame Relay Service .............12
           7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
   8. Frame Relay Port Mode ..........................................13
   9. Congestion Control .............................................13
   10. Security Considerations .......................................14
   11. Normative References ..........................................14
   12. Informative References ........................................15
1. Introduction
1. はじめに

In an MPLS or IP network, it is possible to use control protocols such as those specified in [RFC4447] to set up "pseudowires" (PWs) that carry the Protocol Data Units of layer 2 protocols across the network. A number of these emulated PWs may be carried in a single tunnel. The main functions required to support frame relay PW by a Provider Edge (PE) include:


- encapsulation of frame relay specific information in a suitable pseudowire (PW) packet;

- フレームリレー固有の情報を適切な疑似配線(PW)パケットにカプセル化します。

- transfer of a PW packet across an MPLS network for delivery to a peer PE;

- ピアPEに配信するためのMPLSネットワークを介したPWパケットの転送。

- extraction of frame relay specific information from a PW packet by the remote peer PE;

- リモートピアPEによるPWパケットからのフレームリレー固有の情報の抽出。

- regeneration of native frame relay frames for forwarding across an egress port of the remote peer PE; and

- リモートピアPEの出力ポートを介して転送するためのネイティブフレームリレーフレームの再生成。そして

- execution of any other operations as required to support frame relay service.

- フレームリレーサービスをサポートするために必要なその他の操作の実行。

This document specifies the encapsulation for the emulated frame relay VC over an MPLS PSN. 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. Other layer 2 protocols are described in separate documents. [ATM] [RFC4448] [RFC4618]

このドキュメントでは、MPLS PSNを介したエミュレートされたフレームリレーVCのカプセル化を指定します。異なるレイヤ2プロトコルでは、このカプセル化で異なる​​情報を伝送する必要がありますが、すべてのレイヤ2プロトコルでカプセル化をできるだけ共通にする試みが行われています。他のレイヤー2プロトコルは、別のドキュメントで説明されています。 [ATM] [RFC4448] [RFC4618]

The following figure describes the reference models that are derived from [RFC3985] to support the frame relay PW emulated services.


         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudowire ------->|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnel -->|    |          |
         | PW End   V    V                  V    V  PW End  |
         V Service  +----+                  +----+  Service V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |       (PE1)                    (PE2)       |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
            |                                            |
    Attachment Circuit (AC)                    Attachment Circuit (AC)
   native frame relay service                 native frame relay service

Figure 1. PWE3 frame relay PVC interface reference configuration

図1. PWE3フレームリレーPVCインターフェイスのリファレンス構成

Two mapping modes can be defined between frame relay VCs and pseudowires: The first one is called "one-to-one" mapping, because there is a one-to-one correspondence between a frame relay VC and one pseudowire. The second mapping is called "many-to-one" mapping or "port mode" because multiple frame relay VCs assigned to a port are mapped to one pseudowire. The "port mode" encapsulation is identical to High-Level Data Link Control (HDLC) pseudowire encapsulation, which is described in [RFC4618].

フレームリレーVCと疑似配線の間には2つのマッピングモードを定義できます。最初のマッピングモードは、フレームリレーVCと1つの疑似配線の間に1対1の対応があるため、「1対1」マッピングと呼ばれます。 2番目のマッピングは、「多対1」マッピングまたは「ポートモード」と呼ばれます。これは、ポートに割り当てられた複数のフレームリレーVCが1つの疑似配線にマッピングされるためです。 「ポートモード」カプセル化は、[RFC4618]で説明されている高レベルデータリンク制御(HDLC)疑似配線カプセル化と同じです。

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 RFC 2119.

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。

Below are the definitions for the terms used throughout the document. PWE3 definitions can be found in [RFC3916, RFC3985]. This section defines terms specific to frame relay.

以下は、ドキュメント全体で使用される用語の定義です。 PWE3の定義は[RFC3916、RFC3985]にあります。このセクションでは、フレームリレーに固有の用語を定義します。

- Forward direction

- 順方向

The forward direction is the direction taken by the frame being forwarded.


- Backward direction

- 後方方向

In frame relay, it is the direction opposite to the direction taken by a frame being forwarded (see also forward direction).


3. Co-authors
3. 共著者

The following are co-authors of this document:


Nasser El-Aawar Level 3 Communications, LLC Eric C. Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K. Johnson Litchfield Communications Kireeti Kompella Juniper Networks, Inc. Steve Vogelsang Laurel Networks, Inc. Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks,Inc. Chris Liljenstolpe Cable & Wireless Prayson Pate Overture Networks, Inc

Nasser El-Aawar Level 3 Communications、LLC Eric C. Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K. Johnson Litchfield Communications Kireeti Kompella Juniper Networks、Inc. Steve Vogelsang Laurel Networks、Inc. Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks、Inc. Chris Liljenstolpe Cable&Wireless Prayson Pate Overture Networks、Inc

4. Acronyms and Abbreviations
4. 頭字語と略語

BECN Backward Explicit Congestion Notification CE Customer Edge C/R Command/Response DE Discard Eligibility DLCI Data Link Connection Identifier FCS Frame Check Sequence FECN Forward Explicit Congestion Notification FR Frame Relay LSP Label Switched Path LSR Label Switching Router MPLS Multiprotocol Label Switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudowire PWE3 Pseudowire Emulation Edge to Edge POS Packet over SONET/SDH PVC Permanent Virtual Circuit QoS Quality of Service SVC Switched Virtual Circuit UNI User-Network Interface VC Virtual Circuit

BECN後方明示的輻輳通知CEカスタマーエッジC / Rコマンド/応答DE廃棄適性DLCIデータリンク接続識別子FCSフレームチェックシーケンスFECN前方明示的輻輳通知FRフレームリレーLSPラベルスイッチドパスLSRラベルスイッチングルータMPLSマルチプロトコルラベルスイッチングMTU最大転送ユニットNNIネットワークネットワークインターフェイスPEプロバイダーエッジPSNパケット交換ネットワークPW疑似配線PWE3疑似配線エミュレーションエッジツーエッジPOSパケットover SONET / SDH PVC永久仮想回線QoSサービス品質SVC交換仮想回線UNIユーザーネットワークインターフェイスVC仮想回線

5. Applicability Statement
5. 適用性ステートメント

Frame relay over PW service is not intended to emulate the traditional frame relay service perfectly, but it can be used for applications that need frame relay transport service.


The following are notable differences between traditional frame relay service and the protocol described in this document:


- Frame ordering can be preserved using the OPTIONAL sequence field in the control word; however, implementations are not required to support this feature.

- フレームの順序は、コントロールワードのOPTIONALシーケンスフィールドを使用して保持できます。ただし、この機能をサポートするための実装は必要ありません。

- The Quality of Service model for traditional frame relay can be emulated; however, this is outside the scope of this document.

- 従来のフレームリレーのサービス品質モデルをエミュレートできます。ただし、これはこのドキュメントの範囲外です。

- A Frame relay port mode PW does not process any frame relay status messages or alarms as described in [Q922] [Q933]

- フレームリレーポートモードPWは、[Q922] [Q933]で説明されているように、フレームリレーステータスメッセージまたはアラームを処理しません。

- The frame relay BECN and FECN bit are transparent to the MPLS network and cannot reflect the status of the MPLS network.

- フレームリレーのBECNおよびFECNビットは、MPLSネットワークに対して透過的であり、MPLSネットワークのステータスを反映できません。

- Support for frame relay SVC and Switched Permanent Virtual Circuit (SPVC) is outside the scope of this document.

- フレームリレーSVCおよびスイッチドパーマネントバーチャルサーキット(SPVC)のサポートは、このドキュメントの範囲外です。

- Frame relay Local Management Interface (LMI) is terminated locally in the PE connected to the frame relay attachment circuit.

- フレームリレーローカル管理インターフェース(LMI)は、フレームリレー接続回路に接続されたPEでローカルに終端されます。

- The support of PVC link integrity check is outside the scope of this document.

- PVCリンクの整合性チェックのサポートは、このドキュメントの範囲外です。

6. General Encapsulation Method
6. 一般的なカプセル化方法

The general frame relay pseudowire packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 2.


              |                               |
              |    MPLS Transport header      |
              |       (As required)           |
              |   Pseudowire (PW) Header      |
              |        Control Word           |
              |          FR Service           |
              |           Payload             |

Figure 2. General format of frame relay encapsulation over PSN

図2. PSNを介したフレームリレーカプセル化の一般的な形式

The PW packet consists of the following fields: Control word and Payload, preceded by the MPLS Transport and pseudowire header. The meaning of the different fields is as follows:


-i. MPLS Transport header is specific to the MPLS network. This header is used to switch the PW packet through the MPLS core.

-私。 MPLSトランスポートヘッダーは、MPLSネットワークに固有です。このヘッダーは、MPLSコアを介してPWパケットを切り替えるために使用されます。

-ii. PW header contains an identifier for multiplexing PWs within an MPLS tunnel.

-ii。 PWヘッダーには、MPLSトンネル内でPWを多重化するための識別子が含まれています。

-iii. Control Word contains protocol control information for providing a frame relay service. Its structure is provided in the following sections.


-iv. The content of the frame relay service payload field depends on the mapping mode. In general it contains the layer 2 frame relay frame.


7. Frame Relay over MPLS PSN for the One-to-One Mode
7. 1対1モードのFrame Relay over MPLS PSN
7.1. MPLS PSN Tunnel and PW
7.1. MPLS PSNトンネルおよびPW

MPLS label switched paths (LSPs) called "MPLS Tunnels" are used between PEs and are used within the MPLS core network to forward PW packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.

「MPLSトンネル」と呼ばれるMPLSラベルスイッチドパス(LSP)は、PE間で使用され、MPLSコアネットワーク内でPWパケットを転送するために使用されます。 MPLSトンネルは、図1の「PSNトンネル」に対応しています。

Several PWs may be nested inside one MPLS tunnel. Each PW carries the traffic of a single frame relay VC. In this case, the PW header is an MPLS label called the PW label.


7.2. Packet Format over MPLS PSN
7.2. MPLS PSN上のパケット形式

For the one-to-one mapping mode for frame relay over an MPLS network, the PW packet format is as shown in Figure 3.


    |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
    |      PW label                 |  4 octets
    |       Control Word            |
    |      (See Figure 4)           | 4 octets
    |            Payload            |
    |      (Frame relay frame       |
    |       information field)      | n octets
    |                               |

Figure 3. Frame Relay over MPLS PSN Packet for the One-to-One Mapping

図3. 1対1マッピングのFrame Relay over MPLS PSNパケット

The meaning of the different fields is as follows:


- MPLS Tunnel label(s)

- MPLSトンネルラベル

The MPLS Tunnel label(s) corresponds to the MPLS transport header of Figure 2. The label(s) is/are used by MPLS LSRs to forward a PW packet from one PE to the other.

MPLSトンネルラベルは、図2のMPLSトランスポートヘッダーに対応します。このラベルは、MPLS LSRが1つのPEから別のPEにPWパケットを転送するために使用されます。

- PW Label

- PWラベル

The PW label identifies one PW (i.e., one LSP) assigned to a frame relay VC in one direction. It corresponds to the PW header of Figure 2. Together the MPLS Tunnel label(s) and PW label form an MPLS label stack [RFC3032].


- Control Word

- コントロールワード

The Control Word contains protocol control information. Its structure is shown in Figure 4.


- Payload

- ペイロード

The payload field corresponds to X.36/X.76 frame relay frame information field with the following components removed: bit/byte stuffing, frame relay header, and FCS. It is RECOMMENDED to support a frame size of at least 1600 bytes. The maximum length of the payload field MUST be agreed upon by the two PEs. This can be achieved by using the MTU interface parameter when the PW is established. [RFC4447]

ペイロードフィールドはX.36 / X.76フレームリレーフレーム情報フィールドに対応し、ビット/バイトスタッフィング、フレームリレーヘッダー、FCSのコンポーネントが削除されています。少なくとも1600バイトのフレームサイズをサポートすることをお勧めします。ペイロードフィールドの最大長は、2つのPEで合意する必要があります。これは、PWが確立されているときにMTUインターフェイスパラメータを使用することで実現できます。 [RFC4447]

7.3. The Control Word
7.3. コントロールワード

The control word defined below is REQUIRED for frame relay one-to-one mode. The control word carries certain frame relay specific information that is necessary to regenerate the frame relay frame on the egress PE. Additionally, the control word also carries a sequence number that can be used to preserve sequentiality when carrying frame relay over an MPLS network. Its structure is 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|F|B|D|C|FRG|  Length   | Sequence Number               |

Figure 4. Control Word structure for the one-to-one mapping mode

図4. 1対1マッピングモードの制御ワード構造

The meaning of the Control Word fields (Figure 4) is as follows (see also [X36 and X76] for frame relay bits):


- Bits 0 to 3

- ビット0から3

In the above diagram, the first 4 bits MUST be set to 0 to indicate PW data.


- F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.

- F(ビット4)FR FECN(Forward Explicit Congestion Notification)ビット。

- B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.

- B(ビット5)FR BECN(Backward Explicit Congestion Notification)ビット。

- D (bit 6) FR DE bit (Discard Eligibility) bit.

- D(ビット6)FR DEビット(廃棄適格性)ビット。

- C (bit 7) FR frame C/R (Command/Response) bit.

- C(ビット7)FRフレームC / R(コマンド/応答)ビット。

- FRG (bits 8 and 9): These bits are defined by [RFC4623].

- FRG(ビット8および9):これらのビットは[RFC4623]で定義されています。

- Length (bits 10 to 15)

- 長さ(ビット10から15)

If the PW traverses a network link that requires a minimum frame size (a notable example is Ethernet), padding is required to reach its minimum frame size. If the frame's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the PW payload length. Otherwise, the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove the padding characters by the egress PE.


- Sequence number (Bit 16 to 31)

- シーケンス番号(ビット16から31)

Sequence numbers provide one possible mechanism to ensure the ordered delivery of PW packets. The processing of the sequence number field is OPTIONAL. The sequence number space is a 16-bit unsigned circular space. The sequence number value 0 is used to indicate that the sequence number check algorithm is not used.


7.4. The Martini Legacy Mode Control Word
7.4. マティーニレガシーモードコントロールワード

For backward compatibility to existing implementations, the following version of the control word is defined as the "martini mode CW" for 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
   |0 0 0 0|B|F|D|C|FRG|  Length   | Sequence Number               |

Figure 5. Control Word structure for the frame relay martini mode


Note that the "B" and "F" bits are reversed.


This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )"


7.5. PW Packet Processing
7.5. PWパケット処理
7.5.1. Encapsulation of Frame Relay Frames
7.5.1. フレームリレーフレームのカプセル化

The encapsulation process of a frame relay frame is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI [FRF1] [FRF2] interfaces. The PE generates the following fields

フレームリレーフレームのカプセル化プロセスは、PEがフレームリレーUNIまたはNNI [FRF1] [FRF2]インターフェイスのいずれかからフレームリレーフレームを受信すると開始されます。 PEは次のフィールドを生成します

of the control word from the corresponding fields of the frame relay frame as follows:


- Command/Response (C/R or C) bit: The C bit is copied unchanged in the PW Control Word.

- コマンド/応答(C / RまたはC)ビット:Cビットは変更されずにPWコントロールワードにコピーされます。

- The DE bit of the frame relay frame is copied into the D bit field. However, if the D bit is not already set, it MAY be set as a result of ingress frame policing. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).

- フレームリレーフレームのDEビットがDビットフィールドにコピーされます。ただし、Dビットがまだ設定されていない場合は、入力フレームポリシングの結果として設定される場合があります。コピー操作でまだ設定されていない場合は、PEによるこのビットの設定はオプションです。 PEはこのビットをクリアしてはなりません(1の値で受信された場合は0に設定してください)。

- The FECN bit of the frame relay frame is copied into the F bit field. However, if the F bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1)

- フレームリレーフレームのFECNビットがFビットフィールドにコピーされます。ただし、Fビットがまだ設定されていない場合は、PEによって検出された輻輳状況を反映するように設定される場合があります。コピー操作でまだ設定されていない場合は、PEによるこのビットの設定はオプションです。 PEはこのビットをクリアしてはなりません(1の値で受信された場合は0に設定してください)。

- The BECN bit of the frame relay frame is copied into the B bit field. However, if the B bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).

- フレームリレーフレームのBECNビットがBビットフィールドにコピーされます。ただし、Bビットがまだ設定されていない場合は、PEによって検出された輻輳状況を反映するように設定される場合があります。コピー操作でまだ設定されていない場合は、PEによるこのビットの設定はオプションです。 PEはこのビットをクリアしてはなりません(1の値で受信された場合は0に設定してください)。

- If the PW packet length (defined as the length of the payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero.

- PWパケットの長さ(ペイロードの長さと制御ワードの長さの合計として定義される)が64オクテット未満の場合、長さフィールドはパケットの長さに設定されなければなりません(MUST)。それ以外の場合、長さフィールドはゼロに設定する必要があります。

- The sequence number field is processed if the PW uses sequence numbers. [RFC4385]

- シーケンス番号フィールドは、PWがシーケンス番号を使用する場合に処理されます。 [RFC4385]

- The payload of the PW packet is the contents of ITU-T Recommendations X.36/X.76 [X36] [X76] frame relay frame information field stripped from any bit or byte stuffing.

- PWパケットのペイロードは、ITU-T勧告X.36 / X.76 [X36] [X76]の内容であり、ビットまたはバイトスタッフィングから取り除かれたフレームリレーフレーム情報フィールドです。

7.5.2. Setting the Sequence Number
7.5.2. シーケンス番号の設定

For a given PW and a pair of routers PE1 and PE2, if PE1 supports packet sequencing, then the procedures in [RFC4385], Section 4.1, MUST be followed.


7.6. Decapsulation of PW Packets
7.6. PWパケットのカプセル開放

When a PE receives a PW packet, it processes the different fields of the control word in order to decapsulate the frame relay frame for transmission to a CE on a frame relay UNI or NNI. The PE performs the following actions (not necessarily in the order shown):

PEがPWパケットを受信すると、フレームリレーUNIまたはNNIでCEに送信するためにフレームリレーフレームのカプセル化を解除するために、制御ワードのさまざまなフィールドを処理します。 PEは次のアクションを実行します(必ずしもこの順序である必要はありません)。

- It generates the following frame relay frame header fields from the corresponding fields of the PW packet.

- PWパケットの対応するフィールドから、次のフレームリレーフレームヘッダーフィールドを生成します。

- The C/R bit MUST be copied in the frame relay header.

- C / Rビットはフレームリレーヘッダーにコピーする必要があります。

- The D bit MUST be copied into the frame relay header DE bit.

- DビットはフレームリレーヘッダーのDEビットにコピーする必要があります。

- The F bit MUST be copied into the frame relay header FECN bit. If the F bit is set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL.

- FビットはフレームリレーヘッダーFECNビットにコピーする必要があります。 Fビットがゼロに設定されている場合、順方向のPEデバイスの輻輳状態によっては、FECNビットが1に設定される場合があります。 PEによるこのビットの状態の変更はオプションです。

- The B bit MUST be copied into the frame relay header BECN bit. If the B bit is set to zero, the BECN bit may be set to one, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL.

- BビットはフレームリレーヘッダーのBECNビットにコピーする必要があります。 Bビットがゼロに設定されている場合、逆方向のPEデバイスの輻輳状態によっては、BECNビットが1に設定される場合があります。 PEによるこのビットの状態の変更はオプションです。

- It processes the length and sequence field, the details of which are in the following sub-sections.

- これは、長さとシーケンスフィールドを処理します。詳細は次のサブセクションにあります。

- It copies the frame relay information field from the contents of the PW packet payload after removing any padding.

- パディングを削除した後、PWパケットペイロードの内容からフレームリレー情報フィールドをコピーします。

Once the above fields of a FR frame have been processed, the standard HDLC operations are performed on the frame relay frame: the HDLC header is added, any bit or byte stuffing is added as required, and the FCS is also appended to the frame. The FR frame is then queued for transmission on the selected frame relay UNI or NNI interface.

FRフレームの上記のフィールドが処理されると、標準のHDLC操作がフレームリレーフレームで実行されます。HDLCヘッダーが追加され、必要に応じてビットまたはバイトスタッフィングが追加され、FCSもフレームに追加されます。 FRフレームは、選択されたフレームリレーUNIまたはNNIインターフェイスで送信するためにキューに入れられます。

7.6.1. Processing the Sequence Number
7.6.1. シーケンス番号の処理

If a router PE2 supports received sequence number processing, then the procedures in [RFC4385], Section 4.2, MUST be used.


7.6.2. Processing of the Length Field by the Receiver
7.6.2. 受信者による長さフィールドの処理

Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data.


- If the Length field is set to zero, then there are no padding octets following the payload field.

- 長さフィールドがゼロに設定されている場合、ペイロードフィールドに続くパディングオクテットはありません。

- Otherwise, if the payload is longer, then the length specified in the control word padding characters are removed according to the length field.

- それ以外の場合、ペイロードが長いと、コントロールワードのパディング文字で指定された長さが長さフィールドに従って削除されます。

7.7. MPLS Shim EXP Bit Values
7.7. MPLS Shim EXPビット値

If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the Experimental Use Bits (EXP) field of the PW MPLS label [RFC3032]. 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.

サービス品質情報の伝達が必要な場合、サービス品質情報は、PW MPLSラベル[RFC3032]の実験的使用ビット(EXP)フィールドで表す必要があります(SHOULD)。入力LSRによって複数のMPLSラベルが設定されている場合、スタックの上位にあるラベルのEXPフィールドにも同じ値が含まれる必要があります(SHOULD)。

7.8. MPLS Shim S Bit Value
7.8. MPLSシムSビット値

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.


7.9. Control Plane Details for Frame Relay Service
7.9. フレームリレーサービスのコントロールプレーンの詳細

The PE MUST provide frame relay PVC status signaling to the frame relay network. If the PE detects a service-affecting condition for a particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA FRF1.1, the PE MUST communicate to the remote PE the status of the PW that corresponds to the frame relay DLCI status. The Egress PE SHOULD generate the corresponding errors and alarms as defined in [Q922] [Q933] on the egress Frame relay PVC.

PEは、フレームリレーネットワークにフレームリレーPVCステータスシグナリングを提供する必要があります。 IA FRF1.1にある[Q933] Q.933、Annex A.5で定義されているように、PEが特定のDLCIのサービスに影響する条件を検出した場合、PEはリモートPEに次のPWのステータスを通信する必要があります。フレームリレーDLCIステータスに対応します。出力PEは、[Q922] [Q933]で定義されているように、出力フレームリレーPVCで対応するエラーとアラームを生成する必要があります(SHOULD)。

There are two frame relay flags to control word bit mappings described below. The legacy bit ordering scheme will be used for a PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit ordering scheme will be used for a PW of type 0x0019, "Frame Relay DLCI". The IANA allocation registry of "Pseudowire Type" is defined in [RFC4446] along with initial allocated values.

以下に説明するワードビットマッピングを制御する2つのフレームリレーフラグがあります。タイプ0x0001のPW、「フレームリレーDLCI(マルティーニモード)」には従来のビット順序スキームが使用され、タイプ0x0019、「フレームリレーDLCI」のPWには新しいビット順序スキームが使用されます。 「疑似配線タイプ」のIANA割り当てレジストリは、初期割り当て値とともに[RFC4446]で定義されています。

7.9.1. Frame Relay Specific Interface Parameter Sub-TLV
7.9.1. フレームリレー固有のインターフェイスパラメータサブTLV

A separate document, [RFC4447], describes the PW control and maintenance protocol in detail, including generic interface parameter sub-TLVs. The interface parameter information, when applicable, MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. The Interface parameter TLV is defined in [RFC4447], and the IANA registry with initial values for interface parameter sub-TLV types is defined in [RFC4446], but the frame relay specific interface parameter sub-TLV types are specified as follows:


- 0x08 Frame Relay Header Length Sub-TLV

- 0x08フレームリレーヘッダー長サブTLV

An optional 16-bit value indicating the length of the FR Header, expressed in octets. This OPTIONAL interface parameter Sub-TLV can have value of 2, 3, or 4, the default being 2. If this Sub-TLV is not present, the default value of 2 is assumed.


8. Frame Relay Port Mode
8. フレームリレーポートモード

The frame relay port mode PW shares the same encapsulation as the HDLC PW and is described in the respective document. [RFC4618]

フレームリレーポートモードPWは、HDLC PWと同じカプセル化を共有し、それぞれのドキュメントで説明されています。 [RFC4618]

9. Congestion Control
9. 輻輳制御

As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, the characteristics of which depend on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the frame relay PW. In addition, since frame relay PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914]. In the presence of services that reduce transmission rate, frame relay PWs may thus consume more than their fair share and in that case SHOULD be halted.

[RFC3985]で説明されているように、PWを伝送するPSNは輻輳の影響を受ける可能性があり、その特性はPSNタイプ、ネットワークアーキテクチャ、構成、および負荷に依存します。輻輳中、PSNはフレームリレーPWによって運ばれるサービスに影響を与えるパケット損失を示す場合があります。さらに、フレームリレーPWは、TCP / IPを含むがこれに限定されないPSN全体でさまざまなサービスを実行するため、[RFC2914]で規定されているTCPフレンドリーな方法で動作する場合と動作しない場合があります。したがって、伝送速度を低下させるサービスが存在する場合、フレームリレーPWはフェアシェアよりも多く消費する可能性があり、その場合は停止する必要があります(SHOULD)。

Whenever possible, frame relay 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 frame relay PW's effects from neighboring streams.


Note that when transporting frame relay, DiffServ-enabled domains may use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of EF, in order to place less burden on the network and to gain additional statistical multiplexing advantage. In particular, if the Committed Information Rate (CIR) of a frame relay VC is zero, then it is equivalent to a best-effort UDP over IP stream regarding congestion: the network is free to drop frames as necessary. In this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a diff-serv-TE domain. Alternatively, if the CIR of a frame relay VC is nonzero and the DE bit is zero in the FR header, then "AF31" would be appropriate to be used, and if the CIR of a frame relay VC is nonzero but the DE bit is on, then "AF32" would be appropriate [RFC3270].

フレームリレーを転送する場合、DiffServが有効なドメインは、EFではなくAF(Assured Forwarding)やDF(Default Forwarding)を使用して、ネットワークへの負荷を軽減し、統計的多重化の利点をさらに得ることができます。特に、フレームリレーVCの認定情報レート(CIR)がゼロの場合、輻輳に関するIPエフォート上のUDPのベストエフォートに相当します。ネットワークは必要に応じてフレームを自由にドロップできます。この場合、diff-serv-TEドメインでは、ホップごとの「DF」動作(PHB)が適切です。または、フレームリレーVCのCIRがゼロでなく、FRヘッダーのDEビットがゼロの場合、「AF31」を使用するのが適切です。また、フレームリレーVCのCIRがゼロではないが、DEビットが次に、「AF32」が適切です[RFC3270]。

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 frame relay PW may be maintained. When a PE detects significant congestion while receiving the PW PDUs, the BECN bits of the frame relay frame transmitted on the same PW SHOULD be set to notify the remote PE and the remote frame relay switch of the congestion situation. In addition, the FECN bits SHOULD be set in the FR frames sent out the attachment circuit, to give the FR DTE a chance to adjust its transport layer advertised window, if possible.

PEは、フレームリレーPWを使用するサービスが確実に維持されるようにするために、(明示的な輻輳通知、[VCCV]を使用する、またはパケット損失を測定することによって)輻輳を監視する必要があります(SHOULD)。 PEがPW PDUの受信中に重大な輻輳を検出した場合、同じPWで送信されるフレームリレーフレームのBECNビットを設定して、リモートPEおよびリモートフレームリレースイッチに輻輳状況を通知する必要があります。さらに、可能であれば、FR DTEにトランスポート層のアドバタイズされたウィンドウを調整する機会を与えるために、接続回線から送信されるFRフレームでFECNビットを設定する必要があります(SHOULD)。

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.

PWが[RFC4447]で定義されたプロトコルを使用してセットアップされている場合、ステータス通知の[RFC4447]で指定された手順を使用して、出力PEからの入力PEでのパケット送信を無効にできます。 PWは、手動の介入によって、または適切な待機時間の後の自動手段によって再起動できます。

10. Security Considerations
10. セキュリティに関する考慮事項

PWE3 provides no means of protecting the contents or delivery of the PW packets on behalf of the native service. PWE3 may, however, leverage security mechanisms provided by the MPLS Tunnel Layer. A more detailed discussion of PW security is given in [RFC3985, RFC4447, RFC3916].

PWE3は、ネイティブサービスに代わってPWパケットのコンテンツまたは配信を保護する手段を提供しません。ただし、PWE3は、MPLSトンネルレイヤーによって提供されるセキュリティメカニズムを利用する場合があります。 PWセキュリティの詳細については、[RFC3985、RFC4447、RFC3916]を参照してください。

11. Normative References
11. 引用文献

[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] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル配布プロトコル(LDP)を使用した疑似配線のセットアップとメンテナンス」、RFC 4447、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月。

[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。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。

[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation(PWE3)のIANA割り当て」、BCP 116、RFC 4446、2006年4月。

[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of Point to Point Protocol/High-Level Data Link Control (PPP/HDLC) over Multiprotocol Label Switching (MPLS) Networks", RFC 4618, September 2006.

[RFC4618]マティーニ、L。、ローゼン、E。、ヘロン、G。、およびA.マリ、「マルチプロトコルラベルスイッチングによるポイントツーポイントプロトコル/高レベルデータリンク制御(PPP / HDLC)のトランスポートのカプセル化方法( MPLS)ネットワーク」、RFC 4618、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、「Pseudowire Emulation Edge-to-Edge(PWE3)Fragmentation and Reassembly」、RFC 4623、2006年8月。

12. Informative References
12. 参考引用

[RFC3985] Bryant, S. and P. Pate, "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] Nadeau、T.、et al。、 "Pseudo Wire Virtual Circuit Connection Verification(VCCV)"、Work in Progress、2005年10月。

[ATM] Martini, L., et al., "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress, April 2005.

[ATM] Martini、L.、et al。、 "Encapsulation Methods for Transport of ATM over MPLS Networks"、Work in Progress、2005年4月。

[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.

[RFC4448] Martini、L.、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006。

[FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000.

[FRF1] FRF.1.2、フレームリレーPVC UNI実装契約、フレームリレーフォーラム、2000年4月。

[FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2002

[FRF2] FRF.2.2、フレームリレーPVC UNI実装契約、フレームリレーフォーラム、2002年4月

[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.

[RFC3916] Xiao、X.、McPherson、D。、およびP. Pate、「Pseudo-Wire Emulation Edge-to-Edge(PWE3)の要件」、RFC 3916、2004年9月。

[X36] ITU-T Recommendation X.36, Interface between a DTE and DCE for public data networks providing frame relay, Geneva, 2000.

[X36] ITU-T勧告X.36、フレームリレーを提供するパブリックデータネットワーク用のDTEとDCE間のインターフェイス、ジュネーブ、2000年。

[X76] ITU-T Recommendation X.76, Network-to-network interface between public data networks providing frame relay services, Geneva,2000

[X76] ITU-T勧告X.76、フレームリレーサービスを提供するパブリックデータネットワーク間のネットワーク間インターフェース、Geneva、2000

[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995

[Q922] ITU-T勧告Q.922 Frame Mode Basic呼制御の仕様、ITU Geneva 1995

[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode Basic call control, ITU Geneva 2003

[Q933] ITU-T勧告Q.933フレームモード基本呼制御の仕様、ITU Geneva 2003

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。

[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.

[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「マルチプロトコルラベルスイッチング(MPLS)Support of Differentiated Services」、RFC 3270、2002年5月。

Contributing Author Information


Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089

キリーティコンペラジュニパーネットワークス1194 N.マチルダアベニューサニーベール、カリフォルニア州94089


Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK

ジャイルズヘロンテラブスアビープレイス24-28 Easton Street High Wycombe Bucks HP11 1NT UK


Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089

ラオチェルクリジュニパーネットワークス119いいえ。 Mathilda Aave Sunniwale、K202

Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140

Dimitri Stratton Vlachos Mazu Networks、Inc.125 Cambridgepark Drive Cambridge、MA 02140


Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193

Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston、VA 20193

EMail: Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021

メール Nasser El-Aawar Level 3 Communications、LLC。 1025 Eldorado Blvd.コロラド州ブルームフィールド、80021


Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719

Eric C.Rosen Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719


Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719

Dan Tappan Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719


Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560

PrysonPathéOverture Networks、Inc. 507 Airport Boulevard Morrisville、NC、USA 27560


David Sinicrope Ericsson IPI



Ravi Bhat Nokia



Nishit Vasavada Nokia

Nishit Vasavada Nokia

EMail: Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205

Eメール Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh、PA 15205


Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134

Vinai Sirkay Redback Networks 300 Holger Way、San Jose、CA 95134


Authors' Addresses


Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112

Luca Martini Cisco Systems、Inc. 9155 East Nichols Avenue、Suite 400 Englewood、CO、80112


Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2

クロードカワOZコミュニケーションウィンザーステーション1100、デラゴーシュティエセントウェストモントリオールQCカナダH3B 2S2


Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563

アンドリューG.マリステラブス1415 West Diehl Road Naperville、IL 60563


Full Copyright Statement


Copyright (C) The Internet Society (2006).

Copyright(C)The Internet Society(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に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。



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


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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。



Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).