[要約] RFC 4619は、MPLSネットワーク上でフレームリレーを転送するためのカプセル化方法についての規格です。このRFCの目的は、MPLSネットワークでのフレームリレートラフィックの効率的な転送を実現することです。
Network Working Group L. Martini, Ed.
Request for Comments: 4619 Cisco Systems, Inc.
Category: Standards Track C. Kawa, Ed.
Oz Communications
A. Malis, Ed.
Tellabs
September 2006
Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks
マルチプロトコルラベルスイッチング（MPLS）ネットワークを介したフレームリレーのトランスポートのカプセル化方法
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）。
Abstract
概要
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.
フレームリレー疑似配線は、プロバイダーのエッジネットワークノード間に存在するメカニズムであり、MPLSパケット交換ネットワーク（PSN）を介して可能な限り忠実にフレームリレーサービスをサポートします。このドキュメントでは、MPLSネットワーク経由でフレームリレーパケットを転送するために必要な詳細なカプセル化について説明します。
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
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:
MPLSまたはIPネットワークでは、[RFC4447]で指定されているような制御プロトコルを使用して、ネットワーク全体でレイヤー2プロトコルのプロトコルデータユニットを伝送する「疑似配線」（PW）を設定できます。これらのエミュレートされたPWの多くは、単一のトンネルで伝送されます。プロバイダーエッジ（PE）がフレームリレーPWをサポートするために必要な主な機能は次のとおりです。
- 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.
次の図は、フレームリレーPWエミュレートサービスをサポートするために[RFC3985]から派生した参照モデルを示しています。
|<-------------- 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）疑似配線カプセル化と同じです。
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).
フレームリレーでは、転送されるフレームが取る方向とは逆の方向です（転送方向も参照）。
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
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仮想回線
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.
フレームリレーオーバーPWサービスは、従来のフレームリレーサービスを完全にエミュレートすることを目的としたものではありませんが、フレームリレートランスポートサービスを必要とするアプリケーションに使用できます。
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リンクの整合性チェックのサポートは、このドキュメントの範囲外です。
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.
2つのPE間でフレームリレー情報（ユーザーのペイロードとフレームリレー制御情報）を伝送するための一般的なフレームリレー疑似配線パケットフォーマットを図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:
PWパケットは、次のフィールドで構成されています：コントロールワードとペイロード、その前にMPLSトランスポートと疑似配線ヘッダー。各フィールドの意味は次のとおりです。
-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.
-iii。制御ワードには、フレームリレーサービスを提供するためのプロトコル制御情報が含まれています。その構造は次のセクションで提供されます。
-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.
-iv。フレームリレーサービスのペイロードフィールドの内容は、マッピングモードによって異なります。一般に、レイヤ2フレームリレーフレームが含まれます。
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.
複数のPWが1つのMPLSトンネル内にネストされる場合があります。各PWは、単一のフレームリレーVCのトラフィックを伝送します。この場合、PWヘッダーはPWラベルと呼ばれるMPLSラベルです。
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ネットワーク上のフレームリレーの1対1マッピングモードの場合、PWパケットのフォーマットは図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].
PWラベルは、一方向のフレームリレーVCに割り当てられた1つのPW（つまり、1つのLSP）を識別します。これは、図2のPWヘッダーに対応しています。MPLSトンネルラベルとPWラベルは、MPLSラベルスタック[RFC3032]を形成します。
- Control Word
- コントロールワード
The Control Word contains protocol control information. Its structure is shown in Figure 4.
制御ワードには、プロトコル制御情報が含まれています。その構造を図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]
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:
以下に定義する制御ワードは、フレームリレーの1対1モードで必須です。コントロールワードは、出力PEでフレームリレーフレームを再生成するために必要な特定のフレームリレー固有の情報を伝送します。さらに、コントロールワードにはシーケンス番号も含まれており、MPLSネットワークを介してフレームリレーを伝送するときに、連続性を維持するために使用できます。その構造は次のとおりです。
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):
コントロールワードフィールド（図4）の意味は次のとおりです（フレームリレービットについては、[X36およびX76]も参照してください）。
- Bits 0 to 3
- ビット0から3
In the above diagram, the first 4 bits MUST be set to 0 to indicate PW data.
上記の図では、PWデータを示すために最初の4ビットを0に設定する必要があります。
- 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.
PWが最小フレームサイズを必要とするネットワークリンクを通過する場合（注目すべき例はイーサネット）、最小フレームサイズに到達するにはパディングが必要です。フレームの長さ（レイヤー2ペイロードの長さとコントロールワードの長さの合計として定義）が64オクテット未満の場合、長さフィールドはPWペイロードの長さに設定する必要があります。それ以外の場合、長さフィールドはゼロに設定する必要があります。長さフィールドの値（ゼロ以外の場合）は、出力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.
シーケンス番号は、PWパケットの順序付けられた配信を保証するための1つの可能なメカニズムを提供します。シーケンス番号フィールドの処理はオプションです。シーケンス番号スペースは、16ビットの符号なし循環スペースです。シーケンス番号値0は、シーケンス番号チェックアルゴリズムが使用されていないことを示すために使用されます。
For backward compatibility to existing implementations, the following version of the control word is defined as the "martini mode CW" for frame relay.
既存の実装に対する下位互換性のために、次のバージョンのコントロールワードは、フレームリレーの「martiniモードCW」として定義されています。
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
図5.フレームリレーマティーニモードの制御ワード構造
Note that the "B" and "F" bits are reversed.
「B」と「F」のビットが逆になっていることに注意してください。
This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )"
この制御ワード形式は、PWタイプ「フレームリレーDLCI（マティーニモード）」に使用されます。
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]の内容であり、ビットまたはバイトスタッフィングから取り除かれたフレームリレーフレーム情報フィールドです。
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.
特定のPWとルーターPE1とPE2のペアについて、PE1がパケットシーケンスをサポートしている場合、[RFC4385]のセクション4.1の手順に従う必要があります。
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インターフェイスで送信するためにキューに入れられます。
If a router PE2 supports received sequence number processing, then the procedures in [RFC4385], Section 4.2, MUST be used.
ルーターPE2が受信したシーケンス番号の処理をサポートしている場合は、[RFC4385]のセクション4.2の手順を使用する必要があります。
Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data.
データを転送する前に、受信したPWパケットのペイロードフィールドにパディングオクテットがある場合は、それを削除する必要があります。
- 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.
- それ以外の場合、ペイロードが長いと、コントロールワードのパディング文字で指定された長さが長さフィールドに従って削除されます。
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）。
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ラベルがスタックの一番下にあることを示すために、PWラベルのSビットを値1に設定する必要があります。
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]で定義されています。
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:
別のドキュメント[RFC4447]には、一般的なインターフェイスパラメータサブTLVを含む、PW制御およびメンテナンスプロトコルの詳細が記載されています。該当する場合、インターフェイスパラメータ情報を使用して、回線のエッジにあるPEおよび入力ポートと出力ポートが相互運用に必要な機能を備えていることを検証する必要があります。インターフェイスパラメータTLVは[RFC4447]で定義され、インターフェイスパラメータサブTLVタイプの初期値を持つIANAレジストリは[RFC4446]で定義されていますが、フレームリレー固有のインターフェイスパラメータサブTLVタイプは次のように指定されています。
- 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.
オクテットで表されるFRヘッダーの長さを示すオプションの16ビット値。このOPTIONALインターフェイスパラメータSub-TLVの値は2、3、または4で、デフォルトは2です。このSub-TLVが存在しない場合、デフォルト値の2が想定されます。
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]
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.
可能な限り、フレームリレーPWは、帯域幅割り当てとアドミッション制御メカニズムを提供するトラフィックエンジニアリングされたPSN上で実行する必要があります。保証サービス（GS）を提供するIntServ対応ドメインまたはEF（高速転送）を使用するDiffServ対応ドメインは、トラフィックエンジニアリングPSNの例です。このようなPSNは、隣接ストリームからのフレームリレーPWの影響をある程度分離しながら、損失と遅延を最小限に抑えます。
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は、手動の介入によって、または適切な待機時間の後の自動手段によって再起動できます。
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]を参照してください。
[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月。
[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
EMail: kireeti@juniper.net
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
EMail: giles.heron@tellabs.com
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
EMail: d@mazunetworks.com
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: chris.liljenstolpe@alcatel.com Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
メール：chris.liljenstolpe@alcatel.com Nasser El-Aawar Level 3 Communications、LLC。 1025 Eldorado Blvd.コロラド州ブルームフィールド、80021
EMail: nna@level3.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719
EMail: erosen@cisco.com
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Dan Tappan Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719
EMail: tappan@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
PrysonPathéOverture Networks、Inc. 507 Airport Boulevard Morrisville、NC、USA 27560
EMail: prayson.pate@overturenetworks.com
David Sinicrope Ericsson IPI
デビッドSinicropeエリクソンIPI
EMail: david.sinicrope@ericsson.com
Ravi Bhat Nokia
ラビバットノキア
EMail: ravi.bhat@nokia.com
Nishit Vasavada Nokia
Nishit Vasavada Nokia
EMail: nishit.vasavada@nokia.com Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
Eメール：nishit.vasavada@nokia.com Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh、PA 15205
EMail: stephen.vogelsang@ecitele.com
Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134
Vinai Sirkay Redback Networks 300 Holger Way、San Jose、CA 95134
EMail: sirkay@technologist.com
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
EMail: lmartini@cisco.com
Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2
クロードカワOZコミュニケーションウィンザーステーション1100、デラゴーシュティエセントウェストモントリオールQCカナダH3B 2S2
EMail: claude.kawa@oz.com
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
アンドリューG.マリステラブス1415 West Diehl Road Naperville、IL 60563
EMail: Andy.Malis@tellabs.com
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に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できる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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。