RFC4619 日本語訳
4619 Encapsulation Methods for Transport of Frame Relay overMultiprotocol Label Switching (MPLS) Networks. L. Martini, Ed., C.Kawa, Ed., A. Malis, Ed.. September 2006. (Format: TXT=38193 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
エド、ワーキンググループL.マティーニをネットワークでつないでください。コメントのために以下を要求してください。 4619年のシスコシステムズInc.カテゴリ: エド標準化過程C.Kawa、エドオンスコミュニケーションA.Malis、Tellabs2006年9月
Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks
Multiprotocolラベルの切り換え(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
フレームリレーpseudowireはプロバイダーの縁のネットワーク・ノードの間に存在して、MPLSパケット交換網の上でフレームリレーサービスをできるだけ忠実に支持するメカニズム(PSN)です。 このドキュメントはMPLSネットワークの上でフレームリレーパケットを輸送するのに必要な詳細なカプセル化について説明します。
Martini & Kawa Standards Track [Page 1] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[1ページ]RFC4619カプセル化
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. 序論…2 2. 要件の仕様…4 3. 共同執筆します。4 4. 頭文字語と略語…5 5. 適用性声明…5 6. 一般カプセル化方法…6 7. 一対一モードのためのMPLS PSNの上のフレームリレー…7 7.1. MPLS PSNトンネルとPW…7 7.2. MPLS PSNの上のパケット形式…7 7.3. コントロールWord…8 7.4. コントロールが言い表すマティーニ遺産モード…9 7.5. PWパケット処理…9 7.5.1. フレームリレーフレームのカプセル化…9 7.5.2. 一連番号を設定します…10 7.6. PWパケットの被膜剥離術…11 7.6.1. 一連番号を処理します…11 7.6.2. 受信機による長さの分野の処理…11 7.7. MPLS詰め物のEXPは値に噛み付きました…12 7.8. MPLS詰め物Sは値に噛み付きました…12 7.9. フレームリレーサービスのための飛行機の詳細を制御してください…12 7.9.1. フレームリレーの特定のインタフェース・パラメータサブTLV…12 8. フレームリレーポートモード…13 9. 混雑コントロール…13 10. セキュリティ問題…14 11. 標準の参照…14 12. 有益な参照…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:
MPLSかIPネットワークでは、ネットワークの向こう側に層2のプロトコルのプロトコルData Unitsを運ぶ「pseudowires」(PWs)をセットアップするために[RFC4447]で指定されたものなどの制御プロトコルを使用するのは可能です。 これらの多くの見習われたPWsが単一のトンネルで運ばれるかもしれません。 主な機能がProvider Edge(PE)によるPWが含むフレームリレーを支持するのが必要です:
- encapsulation of frame relay specific information in a suitable
pseudowire (PW) packet;
- 適当なpseudowire(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パケットからのフレームリレー特殊情報の抽出。
Martini & Kawa Standards Track [Page 2] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[2ページ]RFC4619カプセル化
- 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のプロトコルは別々のドキュメントで説明されます。 [気圧][RFC4448][RFC4618]
The following figure describes the reference models that are derived from [RFC3985] to support the frame relay PW emulated services.
以下の図はフレームリレーを支持するために[RFC3985]から派生して、PWがサービスを見習ったということである規範モデルについて説明します。
|<-------------- 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
| <。-------------- 見習われたサービス---------------->|、|、|、| | <、-、-、-、-、-、-- Pseudowire------->|、|、|、|、|、|、|、| | <-- PSNはトンネルを堀ります-->|、|、|、| PW終わりのV V V V PWエンド| Vサービス+----+ +----+ サービス対+-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | (PE1) (PE2) | | 顧客| | 顧客縁1| | 縁2| | | | 付属の付属のCircuitの(西暦)ネイティブのフレームリレーサービスのネイティブのフレームリレーCircuit(西暦)サービス
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].
フレームリレーVCsとpseudowiresの間で2つのマッピング方式を定義できます: 最初のものは「1〜1」マッピングと呼ばれます、フレームリレーVCと1pseudowireとの1〜1つの通信があるので。 ポートに割り当てられた複数のフレームリレーVCsが1pseudowireに写像されるので、2番目のマッピングは「1つへの多く」マッピングか「ポートモード」と呼ばれます。 「ポートモード」カプセル化はHigh-レベルData Link Control(HDLC)pseudowireカプセル化と同じです。(それは、[RFC4618]で説明されます)。
Martini & Kawa Standards Track [Page 3] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[3ページ]RFC4619カプセル化
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
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.
以下に、定義がドキュメント中で使用される期間、あります。 [RFC3916、RFC3985]でPWE3定義を見つけることができます。 このセクションはフレームリレーに特定の用語を定義します。
- 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
ナセル高架鉄道-Aawar Level3 コミュニケーション、LLCエリックC.ローゼンシスコシステムズダニエルタッパンシスコシステムズトーマスK.ペニスリッチフィールドコミュニケーションKireeti Kompella杜松はNishit VasavadaノキアのジャイルスHeron TellabsディミトリストラットンVlachosマヅがネットワークでつなぐInc.スティーブフォーゲルザングローレルネットワークInc.Vinai Sirkay信用Infocommラービーバートノキアをネットワークでつなぎます、株式会社クリスLiljenstolpeケーブル・アンド・ワイヤレスPrayson頭の序曲ネットワーク、Inc
Martini & Kawa Standards Track [Page 4] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[4ページ]RFC4619カプセル化
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
適任DLCIデータリンク接続識別子FCSフレームチェックシーケンスFECN順方向明示的輻輳通知FRフレームリレーLSPがラベルするBECN逆方向明示的輻輳通知Ce顧客縁のC/Rコマンド/応答DE破棄は経路LSRラベル切り換えルータMPLS Multiprotocolラベルの切り換えを切り換えました; SDH PVC相手固定接続QoSサービスの質SVC交換仮想回路UNIユーザSonet/ネットワーク・インターフェースのVCの仮想のサーキットの上にPOSパケットを斜めに進ませる最大のMTUの縁のPSNパケット交換網PW Pseudowire PWE3 Pseudowireエミュレーション移動単位数NNIネットワークネットワーク・インターフェースPEプロバイダー縁
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.
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.
- 伝統的なフレームリレーのためのServiceモデルのQualityを見習うことができます。 しかしながら、このドキュメントの範囲の外にこれはあります。
- A Frame relay port mode PW does not process any frame relay status
messages or alarms as described in [Q922] [Q933]
- [Q922]で説明されて、PWが少しのフレームリレーステータスメッセージやアラームも処理しないFrameリレーポートモード[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ネットワークの状態を反映できません。
Martini & Kawa Standards Track [Page 5] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[5ページ]RFC4619カプセル化
- Support for frame relay SVC and Switched Permanent Virtual Circuit
(SPVC) is outside the scope of this document.
- このドキュメントの範囲の外にフレームリレーSVCとSwitched Permanent Virtual Circuit(SPVC)のサポートがあります。
- Frame relay Local Management Interface (LMI) is terminated locally
in the PE connected to the frame relay attachment circuit.
- フレームリレーLocal Management Interface(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.
フレームリレー情報(ユーザのペイロードとフレームリレー制御情報)を2PEsの間まで運ぶための一般的なフレームリレーpseudowireパケット・フォーマットは図2に示されます。
+-------------------------------+
| |
| MPLS Transport header |
| (As required) |
+-------------------------------+
| Pseudowire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
+-------------------------------+ | | | MPLS Transportヘッダー| | (必要に応じて) | +-------------------------------+ | Pseudowire(PW)ヘッダー| +-------------------------------+ | コントロールWord| +-------------------------------+ | FRサービス| | 有効搭載量| +-------------------------------+
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 Transportとpseudowireヘッダーによって先行された単語と有効搭載量を制御してください。 異なった分野の意味は以下の通りです:
-i. MPLS Transport header is specific to the MPLS network. This
header is used to switch the PW packet through the MPLS core.
-i。 MPLS TransportヘッダーはMPLSネットワークに特定です。 このヘッダーは、MPLSコアを通してPWパケットを切り換えるのに使用されます。
-ii. PW header contains an identifier for multiplexing PWs within
an MPLS tunnel.
-ii。 PWヘッダーはMPLSトンネルの中にマルチプレクシングPWsのための識別子を保管しています。
-iii. Control Word contains protocol control information for
providing a frame relay service. Its structure is provided in
the following sections.
-iii。 コントロールWordはフレームリレーサービスを提供するためのプロトコル制御情報を含んでいます。 以下のセクションに構造を提供します。
-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のフレームリレーフレームを含んでいます。
Martini & Kawa Standards Track [Page 6] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[6ページ]RFC4619カプセル化
7. Frame Relay over MPLS PSN for the One-to-One Mode
7. 一対一モードのための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 Tunnels」と呼ばれるMPLSラベルの切り換えられた経路(LSPs)は、PEsの間で使用されて、パケットをPWに送るのにMPLSコアネットワークの中で使用されます。 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.
数個のPWsが1つのMPLSトンネルの中で入れ子にされるかもしれません。 各PWは独身のフレームリレーVCの交通を運びます。 この場合、PWヘッダーはPWラベルと呼ばれるMPLSラベルです。
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ネットワークの上のフレームリレーのための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
| |
+-------------------------------+
+-------------------------------+ | MPLS Tunnelラベル| n*4つの八重奏(1ラベルあたり4つの八重奏)+-------------------------------+ | PWラベル| 4つの八重奏+-------------------------------+ | コントロールWord| | (図4を参照します) | 4つの八重奏+-------------------------------+ | 有効搭載量| | (フレームリレーフレーム| | 情報フィールド) | n八重奏| | +-------------------------------+
Figure 3. Frame Relay over MPLS PSN Packet for the
One-to-One Mapping
図3。 一対一マッピングのためのMPLS PSNパケットの上のフレームリレー
The meaning of the different fields is as follows:
異なった分野の意味は以下の通りです:
- MPLS Tunnel label(s)
- MPLS Tunnelラベル(s)
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 Tunnelラベルは図2のMPLS輸送ヘッダーに文通されます。 ラベルによる/が1PEからもう片方までPWパケットを進めるのにMPLS LSRsによって使用されるということです。
- 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に割り当てられた1PW(すなわち、1LSP)を特定します。 それは図2のPWヘッダーに文通されます。 MPLS TunnelラベルとPWラベルはMPLSラベルスタック[RFC3032]を一緒に、形成します。
Martini & Kawa Standards Track [Page 7] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[7ページ]RFC4619カプセル化
- Control Word
- コントロールWord
The Control Word contains protocol control information. Its
structure is shown in Figure 4.
Control Wordはプロトコル制御情報を含んでいます。 構造は図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バイトのフレーム・サイズを支持するRECOMMENDEDです。 2PEsがペイロード分野の最大の長さに同意しなければなりません。 PWが設立されるときMTUインタフェース・パラメータを使用することによって、これを達成できます。 [RFC4447]
7.3. The Control Word
7.3. コントロールWord
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つのモードのためのREQUIREDです。 規制単語は出口PEにフレームリレーフレームを作り直すのに必要なあるフレームリレー特殊情報を運びます。 また、さらに、規制単語はMPLSネットワークの上までフレームリレーを運ぶとき、sequentialityを保存するのに使用できる一連番号を運びます。 構造は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Control Word structure for the one-to-one mapping mode
図4。 1〜1つのマッピング方式のためのコントロールWord構造
The meaning of the Control Word fields (Figure 4) is as follows (see also [X36 and X76] for frame relay bits):
Control Word分野(図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.
上のダイヤグラムで、最初の4ビットをPWデータを示すように0に設定しなければなりません。
- F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
- F(ビット4)FR FECN(前進のExplicit Congestion Notification)は噛み付きました。
- B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
- B(ビット5)FR BECN(後方のExplicit Congestion Notification)は噛み付きました。
- D (bit 6) FR DE bit (Discard Eligibility) bit.
- D(ビット6)FR DEはビットに噛み付きました(Eligibilityを捨てます)。
- C (bit 7) FR frame C/R (Command/Response) bit.
- C(ビット7)FRはC/R(コマンド/応答)ビットを縁どっています。
Martini & Kawa Standards Track [Page 8] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[8ページ]RFC4619カプセル化
- 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台の可能なメカニズムを提供します。 一連番号分野の処理はOPTIONALです。 一連番号スペースは16ビットの無記名の円形のスペースです。 一連番号値0は、一連番号チェックアルゴリズムが使用されていないのを示すのに使用されます。
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.
既存の実現への後方の互換性において、規制単語の以下のバージョンはフレームリレーのための「マティーニモード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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Control Word structure for the frame relay martini mode
図5。 フレームリレーマティーニモードのためのコントロールWord構造
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(マティーニモード)」に使用されます。
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]インタフェースの1つからフレームリレーフレームを受けるとき、フレームリレーフレームのカプセル化の過程は着手されます。 PEは以下の分野を発生させます。
Martini & Kawa Standards Track [Page 9] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[9ページ]RFC4619カプセル化
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 Control Wordで変わりがない状態でコピーされます。
- 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によるこのビットの設定はOPTIONALです。 PE MUST NOTはこのビットをきれいにします(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によるこのビットの設定はOPTIONALです。 PE MUST NOTはこのビットをきれいにします。(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によるこのビットの設定はOPTIONALです。 PE MUST NOTはこのビットをきれいにします(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未満の八重奏であるなら、パケットの長さに長さの分野を設定しなければなりません。 さもなければ、長さの分野をゼロに設定しなければなりません。
- 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 Recommendations 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.
与えられたPWと1組のルータのPE1とPE2において、PE1がパケット順序制御を支持するなら、[RFC4385]の手順(セクション4.1)に従わなければなりません。
Martini & Kawa Standards Track [Page 10] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[10ページ]RFC4619カプセル化
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パケットを受けるとき、それは、aフレームリレーのUNIかNNIの上のCEへの伝送のためフレームリレーフレームをdecapsulateするように規制単語の異なった分野を処理します。 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.
- フレームリレーヘッダーDEビットにDビットをコピーしなければなりません。
- 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.
- フレームリレーヘッダーFECNビットにFビットをコピーしなければなりません。 Fビットがゼロに設定されるなら、FECNビットは1つに設定されるかもしれません、順方向でPE装置の混雑状態によって。 PEでこのビットの状態を変えるのは、OPTIONALです。
- 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.
- フレームリレーヘッダーBECNビットにBビットをコピーしなければなりません。 Bビットがゼロに設定されるなら、BECNビットは1つに設定されるかもしれません、逆方向でPE装置の混雑状態によって。 PEでこのビットの状態を変えるのは、OPTIONALです。
- 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.
PE2が支持するルータが一連番号処理を受けたなら、[RFC4385]の手順(セクション4.2)を用いなければなりません。
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.
どんな詰め物八重奏、存在しているなら、PWのペイロード分野では、データを転送する前に、受け取られたパケットを取り除かなければなりません。
- If the Length field is set to zero, then there are no padding
octets following the payload field.
- Length分野がゼロに設定されるなら、ペイロード野原に続く詰め物八重奏が全くありません。
Martini & Kawa Standards Track [Page 11] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[11ページ]RFC4619カプセル化
- 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詰め物の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.
Service情報のQuality、Service情報SHOULDのQualityを運ぶのが必要であるなら、PW MPLSラベル[RFC3032]のExperimental Use Bits(EXP)分野に表されてください。 1個以上のMPLSラベルがイングレスLSRによって課されるなら、いずれの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.
イングレスLSR(PE1)は、1の値へのPWラベルのSビットにPWラベルがスタックの下部にあるのを指示するように設定しなければなりません。
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 MUSTはフレームリレーネットワークに合図するフレームリレーPVC状態を提供します。 PEが特定のDLCIのためのサービスに影響する状態を検出するなら、[Q933]Q.933、IA FRF1.1に位置するAnnex A.5で定義されるように、PE MUSTはフレームリレーDLCI状態に対応するPWの状態をリモートPEに伝えます。 Egress PE SHOULDは出口FrameリレーPVCの[Q922][Q933]で定義されるように対応する誤りとアラームを発生させます。
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、「フレームリレーDLCI(マティーニモード)」のPWに使用されるでしょう、そして、計画を命令する新しいビットはタイプ0x0019、「フレームリレーDLCI」のPWに使用されるでしょう。 「Pseudowireはタイプする」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:
一般的なインタフェース・パラメータサブTLVsを含んでいて、別々のドキュメント[RFC4447]は詳細にPWコントロールと維持プロトコルについて説明します。 適切であるときに、インタフェース・パラメータ情報はそれを有効にするのに使用されて、サーキットの縁のPEs、イングレス、および出口港には互いと共に共同利用する必要機能があるということであるに違いありません。 InterfaceパラメタTLVは[RFC4447]で定義されます、そして、インタフェース・パラメータサブTLVタイプのための初期の値があるIANA登録は[RFC4446]で定義されますが、フレームリレーの特定のインタフェース・パラメータサブTLVタイプは以下の通り指定されます:
- 0x08 Frame Relay Header Length Sub-TLV
- 0×08 フレームリレーヘッダ長サブTLV
Martini & Kawa Standards Track [Page 12] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[12ページ]RFC4619カプセル化
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 Headerの長さを示す任意の16ビットの値。 このOPTIONALインタフェース・パラメータSub-TLVはデフォルトが2であるなら2、3、または4の値を持つことができます。 このSub-TLVが存在していないなら、2のデフォルト値は想定されます。
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によって提供されたサービスに影響を与えるパケット損失を示すかもしれません。 さらに、フレームリレーPWsがTCP/IPに含んでいますが、制限されなかったPSNの向こう側にさまざまなサービスを提供するので、それらは[RFC2914]によって定められたTCPに優しい態度で振る舞うかもしれません。 通信速度を減少させるサービスがあるときフレームリレーPWsはその結果、彼らの正当な分け前よりさらに、その場合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.
可能なフレームリレーPWsがひかれるべきであるときはいつも、帯域幅配分と入場を提供する交通の設計されたPSNsがメカニズムを制御します。EF(完全優先転送)を使用することでGuaranteed Service(GS)かDiffServによって可能にされたドメインを提供するIntServによって可能にされたドメインは交通で設計されたPSNsに関する例です。 そのようなPSNsは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(Forwardingを保証する)、そして/または、DF(デフォルトForwarding)を使用するかもしれないことに注意してください。 フレームリレーのCommitted情報Rate(CIR)であるならVCが特に、ゼロである、次に、それはIPの流れで混雑に関してベストエフォート型UDPに同等です: ネットワークは必要に応じてコマ落ちに自由です。 この場合、ホップの振舞い(PHB)あたりの"DF"はデフserv Teドメインで適切でしょう。 あるいはまた、フレームリレーのCIRであるなら、VCは非零です、そして、DEビットはFRヘッダーのゼロです、そして「AF31"は使用されているのが適切でしょう、そして、DEビットがオンである、フレームリレーのコンパス座であるなら、VCは非零ですが、次に、「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
フレームリレーPWを使用するサービスが維持されるかもしれないのを確実にして、PEs SHOULDは混雑(明白な混雑通知、[VCCV]を使用するか、またはパケット損失を測定するのによる)のためにモニターします。 aです。
Martini & Kawa Standards Track [Page 13] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[13ページ]RFC4619カプセル化
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 PDUs(リモートPEに通知するセットとリモートフレームリレーが混雑状況のスイッチであったなら同じPW SHOULDで伝えられたフレームリレーフレームのBECNビット)を受けている間、重要な混雑を検出します。 FECNビットSHOULDが付属サーキットから送られたFRフレームで用意ができていて、FR DTE aを与えるように、さらに、たまたまトランスポート層の広告を出しているウィンドウを調整してください、できれば。
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]で定義されたプロトコルを使用するのに用意ができていたなら、イングレスPEで出口PEからパケット伝送を無効にするのに[RFC4447]で状態通知に指定された手順は用いることができます。 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 Tunnel Layerによって提供されたセキュリティー対策に投機するかもしれません。 [RFC3985、RFC4447、RFC3916]でPWセキュリティの、より詳細な議論をします。
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] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] ブライアント、S.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、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.Malis、「Multiprotocolの上のポイント・ツー・ポイントプロトコル/ハイレベル・データ・リンク制御手順(ppp/HDLC)の輸送のためのカプセル化方法は切り換え(MPLS)をネットワークとラベルします」、RFC4618、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エミュレーション縁から縁(PWE3)への断片化とReassembly」、RFC4623、8月2006日
Martini & Kawa Standards Track [Page 14] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[14ページ]RFC4619カプセル化
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)への構造」、RFC3985、2005年3月。
[VCCV] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection
Verification (VCCV)", Work in Progress, October 2005.
[VCCV] ナドー、T.、他、「疑似ワイヤの仮想のサーキット接続検証(VCCV)」、Progress、2005年10月のWork。
[ATM] Martini, L., et al., "Encapsulation Methods for Transport
of ATM Over MPLS Networks", Work in Progress, April 2005.
[ATM] マティーニ、L.、他、「MPLSネットワークの上の気圧の輸送のためのカプセル化方法」、Progress、2005年4月のWork。
[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] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、およびG.サギ、「MPLSネットワークの上のイーサネットの輸送のためのカプセル化方法」、RFC4448(2006年4月)。
[FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement,
Frame Relay Forum, April 2000.
[FRF1]FRF.1.2、FrameリレーPVC UNI Implementation Agreement、Frame Relay Forum、2000年4月。
[FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement,
Frame Relay Forum, April 2002
[FRF2]FRF.2.2、FrameリレーPVC UNI Implementation Agreement、Frame Relay Forum、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.、マクファーソン、D.、およびP.頭、「疑似ワイヤエミュレーション縁から縁への(PWE3)のための要件」、RFC3916、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 Recommendation X.36、フレームリレーを提供するジュネーブ、2000を公衆データのためのDTEとDCEの間のInterfaceはネットワークでつなぎます。
[X76] ITU-T Recommendation X.76, Network-to-network interface
between public data networks providing frame relay
services, Geneva,2000
[X76]ITU-T Recommendation X.76、フレームリレーサービス、ジュネーブ、2000を提供する公衆データネットワークの間のNetworkからネットワーク・インターフェース
[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode
Basic call control, ITU Geneva 1995
Frame Mode Basicのための[Q922]ITU-T Recommendation Q.922 Specificationは、1995にコントロール、ITUジュネーブに電話をします。
[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode
Basic call control, ITU Geneva 2003
Frame Mode Basicのための[Q933]ITU-T Recommendation Q.933 Specificationは、2003にコントロール、ITUジュネーブに電話をします。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルの切り換え(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
Martini & Kawa Standards Track [Page 15] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[15ページ]RFC4619カプセル化
Contributing Author Information
作者情報を寄付します。
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella杜松は1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
ジャイルスのサギのTellabs修道院の地域24-28イーストン通りハイウィカムバックスHP11 1NTイギリス
EMail: giles.heron@tellabs.com
メール: giles.heron@tellabs.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
ラオCherukuri Juniperは1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140
ディミトリストラットンVlachosマヅはInc.125Cambridgepark Driveケンブリッジ、MA 02140をネットワークでつなぎます。
EMail: d@mazunetworks.com
メール: d@mazunetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193
Floorレストン、クリスLiljenstolpeアルカテル11600学生金融公庫博士の第9ヴァージニア 20193
EMail: chris.liljenstolpe@alcatel.com
メール: chris.liljenstolpe@alcatel.com
Martini & Kawa Standards Track [Page 16] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[16ページ]RFC4619カプセル化
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
LLC、ナセル高架鉄道-Aawarは3つのコミュニケーションを平らにします。 1025 エルドラドBlvd. ブルームフィールド、CO 80021
EMail: nna@level3.net
メール: nna@level3.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、ダンタッパンシスコシステムズInc.1414MA 01719
EMail: tappan@cisco.com
メール: tappan@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
Prayson頭のオーバーチュアはMorrisville、NC米国 Inc.507空港並木街27560をネットワークでつなぎます。
EMail: prayson.pate@overturenetworks.com
メール: prayson.pate@overturenetworks.com
David Sinicrope Ericsson IPI
デヴィッドSinicropeエリクソンIPI
EMail: david.sinicrope@ericsson.com
メール: david.sinicrope@ericsson.com
Ravi Bhat Nokia
ラービーバートノキア
EMail: ravi.bhat@nokia.com
メール: ravi.bhat@nokia.com
Nishit Vasavada Nokia
Nishit Vasavadaノキア
EMail: nishit.vasavada@nokia.com
メール: nishit.vasavada@nokia.com
Martini & Kawa Standards Track [Page 17] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[17ページ]RFC4619カプセル化
Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
スティーブ・フォーゲルザング・ECI電子通信オメガ法人のセンター1300オメガDriveピッツバーグ、PA 15205
EMail: stephen.vogelsang@ecitele.com
メール: stephen.vogelsang@ecitele.com
Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134
Vinai Sirkay20ドル紙幣はサンノゼ、カリフォルニア 300オルガーWay、95134をネットワークでつなぎます。
EMail: sirkay@technologist.com
メール: sirkay@technologist.com
Authors' Addresses
作者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112
EMail: lmartini@cisco.com
メール: lmartini@cisco.com
Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2
クロードKawa OZ Communicationsウインザー駅1100、de la Gauchetieは通りの西モントリオールQCカナダH3B 2S2です。
EMail: claude.kawa@oz.com
メール: claude.kawa@oz.com
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
イリノイ アンドリューG.Malis Tellabs1415の西ディール・Roadナパービル、60563
EMail: Andy.Malis@tellabs.com
メール: Andy.Malis@tellabs.com
Martini & Kawa Standards Track [Page 18] RFC 4619 Encapsulation for Transport of Frame Relay September 2006
フレームリレー2006年9月の輸送のためのマティーニとKawa標準化過程[18ページ]RFC4619カプセル化
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Martini & Kawa Standards Track [Page 19]
マティーニとKawa標準化過程[19ページ]
一覧
スポンサーリンク
