RFC2427 日本語訳
2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. September 1998. (Format: TXT=74671 bytes) (Obsoletes RFC1490, RFC1294) (Also STD0055) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Brown Request for Comments: 2427 Consultant STD: 55 A. Malis Obsoletes: 1490, 1294 Ascend Communications, Inc. Category: Standards Track September 1998
コメントを求めるワーキンググループC.ブラウン要求をネットワークでつないでください: 2427コンサルタントSTD: 55 A.Malisは以下を時代遅れにします。 1490、1294はコミュニケーションInc.カテゴリを昇ります: 標準化過程1998年9月
Multiprotocol Interconnect over Frame Relay
Multiprotocolはフレームリレーの上で内部連絡します。
Status of this Memo
この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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing.
このメモはFrame Relayバックボーンの上までネットワーク内部連絡トラフィックを運ぶためのカプセル化メソッドを説明します。 それはBridgingとルート設定の両方の局面をカバーしています。
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.
本書では説明されたカプセル化メソッドと他のものの両方を移す能力があるシステムには、仮想の回路がどのカプセル化メソッドを運ぶ先験的な知識がなければなりません、そして、使用のために明らかに構成された仮想の回路の上にこのカプセル化を使用するだけでよいです。
Acknowledgments
承認
This document could not have been completed without the support of Terry Bradley of Avici Systems, Inc.. Comments and contributions from many sources, especially those from Ray Samora of Proteon, Ken Rehbehn of Visual Networks, Fred Baker and Charles Carvalho of Cisco Systems, and Mostafa Sherif of AT&T have been incorporated into this document. Special thanks to Dory Leifer of University of Michigan for his contributions to the resolution of fragmentation issues (though it was deleted in the final version) and Floyd Backes and Laura Bridge of 3Com for their contributions to the bridging descriptions. This document could not have been completed without the expertise of the IP over Large Public Data Networks and the IP over NBMA working groups of the IETF.
このドキュメントはAvici Systems Inc.のテリーブラッドリーのサポートなしで完成できませんでした。 Proteonのレイ・サモラ、Visual NetworksのケンRehbehn、シスコシステムズのフレッド・ベイカーとチャールズ・カルバリョ、およびAT&TのMostafaシェリフからの多くのソース、特にそれらからのコメントと貢献をこのドキュメントに組み入れてあります。 ブリッジする記述への彼らの貢献のための3Comの断片化問題(それは最終版で削除されましたが)の解決への彼の貢献のためのミシガン大学のDoryライファー、フロイドBackes、およびローラBridgeへの特別な感謝。 このドキュメントはIETFのNBMAワーキンググループの上でIPの専門的技術なしでLarge Public Data NetworksとIPの上に完成できませんでした。
Brown & Malis Standards Track [Page 1] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[1ページ]。
1. Conventions and Acronyms
1. コンベンションと頭文字語
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [16].
キーワードが解釈しなければならない、本書では現れるとき、[16]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
All drawings in this document are drawn with the left-most bit as the high order bit for transmission. For example, the drawings might be labeled as:
高いオーダーにトランスミッションのために噛み付いたので、すべての図面が最も左のビットで本書では作成されます。 例えば、図面は以下として分類されるかもしれません。
0 1 2 3 4 5 6 7 bits
+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7ビット+---+---+---+---+---+---+---+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
: :
: :
+---------------------------+
+---------------------------+ | (7Eの16進)に旗を揚げさせてください。| +---------------------------+ | Q.922アドレス*| +-- --+ | | +---------------------------+ : : : : +---------------------------+
Drawings that would be too large to fit onto one page if each octet were presented on a single line are drawn with two octets per line. These are also drawn with the left-most bit as the high order bit for transmission. There will be a "+" to distinguish between octets as in the following example.
各八重奏が単線の上に示されるなら1ページに合うことができないくらい大きい図面は1系列あたり2つの八重奏で作成されます。 また、高いオーダーにトランスミッションのために噛み付いたので、これらは最も左のビットで描かれます。 以下の例のように八重奏の間で区別する「+」があるでしょう。
|--- octet one ---|--- octet two ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|--- 八重奏1---|--- 八重奏two---| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
+--------------------------------------------+ | 組織的では、ユニークです。| +-- +--------------------+ | 識別子| プロトコル| +-----------------------+--------------------+ | 識別子| +-----------------------+
The following are common acronyms used throughout this document.
↓これはこのドキュメント中で使用される一般的な頭文字語です。
BECN - Backward Explicit Congestion Notification
BPDU - Bridge Protocol Data Unit
C/R - Command/Response bit
DCE - Data Communication Equipment
BECN--後方のExplicit Congestion Notification BPDU--ブリッジプロトコルData Unit C/R--コマンド/応答ビットDCE--データCommunication Equipment
Brown & Malis Standards Track [Page 2] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[2ページ]。
DE - Discard Eligibility bit
DTE - Data Terminal Equipment
FECN - Forward Explicit Congestion Notification
PDU - Protocol Data Unit
PTT - Postal Telephone & Telegraph
SNAP - Subnetwork Access Protocol
DE--EligibilityビットDTEを捨ててください--データTerminal Equipment FECN(前進のExplicit Congestion Notification PDU)はData Unit PTT--郵便のTelephone&Telegraph SNAP--サブネットワークAccessプロトコルについて議定書の中で述べます。
2. Introduction
2. 序論
The following discussion applies to those devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT. It will not discuss the behavior of those stations that are considered a part of the Frame Relay network (DCEs) other than to explain situations in which the DTE must react.
以下の議論は終わりのステーション(DTEs)として公共の、または、私設のFrame Relayネットワークでそれらのデバイスにどのサーブを申し込むか。(例えば、運輸業者かPTTでそれらのステーションの動きについて議論しないなら、それはDTEが反応しなければならない状況について説明するのを除いたFrame Relayネットワーク(DCEs)の一部であると考えられます。
The Frame Relay network provides a number of virtual circuits that form the basis for connections between stations attached to the same Frame Relay network. The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface.
Frame Relayネットワークは同じFrame Relayネットワークに付けられたステーションの間の接続の基礎を形成する多くの仮想の回路を提供します。 結果として起こるセットのインタコネクトされたデバイスは仮想の回路の完全な「メッシュ」で完全にインタコネクトされたか、または部分的にインタコネクトされるだけであるかもしれない民間のFrame Relayグループを結成します。 どちらの場合ではも、それぞれの仮想の回路はそれぞれのFrame RelayインタフェースでData Link Connection Identifier(DLCI)によって唯一特定されます。 ほとんどの事情では、DLCIsはそれぞれのFrame Relayインタフェースに厳密にローカルの意味を持っています。
The specifications in this document are intended to apply to both switched and permanent virtual circuits.
本書では、仕様が切り換えられた両方と恒久仮想回路に適用することを意図します。
3. Frame Format
3. フレーム形式
All protocols must encapsulate their packets within a Q.922 Annex A frame [1]. Additionally, frames shall contain information necessary to identify the protocol carried within the protocol data unit (PDU), thus allowing the receiver to properly process the incoming packet. The format shall be as follows:
すべてのプロトコルがQ.922 Annex Aフレーム[1]の中にそれらのパケットをカプセルに入れらなければなりません。 さらに、フレームはプロトコルデータ単位(PDU)の中で運ばれたプロトコルを特定するのに必要な情報を含むものとします、その結果、受信機が適切に入って来るパケットを処理するのを許容します。 形式は以下の通りになるでしょう:
Brown & Malis Standards Track [Page 3] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[3ページ]。
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
| Control (UI = 0x03) |
+---------------------------+
| Pad (when required) (0x00)|
+---------------------------+
| NLPID |
+---------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+---------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
+---------------------------+ | (7Eの16進)に旗を揚げさせてください。| +---------------------------+ | Q.922アドレス*| +-- --+ | | +---------------------------+ | コントロール(UI=0x03)| +---------------------------+ | パッド(必要であると)(0×00)| +---------------------------+ | NLPID| +---------------------------+ | . | | . | | . | | データ| | . | | . | +---------------------------+ | フレームチェックシーケンス| +-- . --+ | (2つの八重奏) | +---------------------------+ | (7Eの16進)に旗を揚げさせてください。| +---------------------------+
* Q.922 addresses, as presently defined, are two octets and
contain a 10-bit DLCI. In some networks Q.922 addresses
may optionally be increased to three or four octets.
* Q.922アドレスは、現在定義されているとしての2つの八重奏であり、10ビットのDLCIを含んでいます。 いくつかのネットワークでは、Q.922アドレスは任意に3か4つの八重奏まで増強されるかもしれません。
The control field is the Q.922 control field. The UI (0x03) value is used unless it is negotiated otherwise. The use of XID (0xAF or 0xBF) is permitted and is discussed later.
制御フィールドはQ.922制御フィールドです。 それが別の方法で交渉されない場合、UI(0×03)値は使用されています。 XID(0xAFか0xBF)の使用について、受入れられて、後で議論します。
The pad field is used to align the data portion (beyond the encapsulation header) of the frame to a two octet boundary. If present, the pad is a single octet and must have a value of zero. Explicit directions of when to use the pad field are discussed later in this document.
パッド分野は、フレームのデータ部(カプセル化ヘッダーを超えた)を2八重奏境界に並べるのに使用されます。 存在しているなら、パッドは、ただ一つの八重奏であり、ゼロの値を持たなければなりません。 後で本書ではいつパッド分野を使用するかに関する明快な指示について議論します。
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It contains values for many different protocols including IP, CLNP, and IEEE Subnetwork Access Protocol (SNAP)[10]. This field tells the receiver what encapsulation or what protocol follows. Values for this field are defined in ISO/IEC TR 9577 [3]. A NLPID value of 0x00 is defined within ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it cannot be distinguished from
Network Level Protocol ID(NLPID)分野はISOとITUによって管理されます。 それはIP、CLNP、およびIEEE Subnetwork Accessプロトコル(SNAP)[10]を含む多くの異なったプロトコルのための値を含んでいます。 この分野は、どんなカプセル化かどんなプロトコルが従うかを受信機に言います。 この分野への値はISO/IEC TR9577[3]で定義されます。 0×00のNLPID値はISO/IEC TR9577の中でNull Network LayerかInactive Setと定義されます。 それと区別できないので
Brown & Malis Standards Track [Page 4] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[4ページ]。
a pad field, and because it has no significance within the context of this encapsulation scheme, a NLPID value of 0x00 is invalid under the Frame Relay encapsulation. Appendix A contains a list of some of the more commonly used NLPID values.
このカプセル化体系の文脈の中に意味を全く持っていないので、パッド分野であり、0×00のNLPID値はFrame Relayカプセル化の下で無効です。 付録Aは一般的により使用されたNLPID値のいくつかのリストを含んでいます。
There is no commonly implemented minimum maximum frame size for Frame Relay. A network must, however, support at least a 262 octet maximum. Generally, the maximum will be greater than or equal to 1600 octets, but each Frame Relay provider will specify an appropriate value for its network. A Frame Relay DTE, therefore, must allow the maximum acceptable frame size to be configurable.
どんな一般的に実装している最小のFrame Relayに、最大のフレーム・サイズもありません。 しかしながら、ネットワークは少なくとも262八重奏最大をサポートしなければなりません。 一般に、最大は1600以上の八重奏になるでしょうが、それぞれのFrame Relayプロバイダーは適切な値をネットワークに指定するでしょう。 したがって、Frame Relay DTEは、最大の許容できるフレーム・サイズが構成可能であることを許容しなければなりません。
The minimum frame size allowed for Frame Relay is five octets between the opening and closing flags assuming a two octet Q.922 address field. This minimum increases to six octets for three octet Q.922 address and seven octets for the four octet Q.922 address format.
Frame Relayのために許容された最小のフレーム・サイズは2八重奏がQ.922アドレス・フィールドであると仮定する初めの、そして、終わりの旗の間の5つの八重奏です。 この最小限は3八重奏Q.922アドレスのための6つの八重奏と4八重奏Q.922アドレス形式のための7つの八重奏まで増加します。
4. Interconnect Issues
4. 内部連絡問題
There are two basic types of data packets that travel within the Frame Relay network: routed packets and bridged packets. These packets have distinct formats and therefore, must contain an indicator that the destination may use to correctly interpret the contents of the frame. This indicator is embedded within the NLPID and SNAP header information.
Frame Relayネットワークの中を移動する2人の基本型のデータ・パケットがあります: パケットを発送して、パケットをブリッジしました。 これらのパケットには、異なった形式があります、そして、したがって、必須は目的地が正しくフレームのコンテンツを解釈するのに使用するかもしれないインディケータを含んでいます。 このインディケータはNLPIDとSNAPヘッダー情報の中で埋め込まれています。
For those protocols that do not have a NLPID already assigned, it is necessary to provide a mechanism to allow easy protocol identification. There is a NLPID value defined indicating the presence of a SNAP header.
既にNLPIDを割り当てないそれらのプロトコルに、簡単なプロトコル識別を許すためにメカニズムを提供するのが必要です。 SNAPヘッダーの存在を示しながら定義されたNLPID値があります。
A SNAP header is of the form:
SNAPヘッダーはフォームのものです:
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
+--------------------------------------------+ | 組織的では、ユニークです。| +-- +--------------------+ | 識別子| プロトコル| +-----------------------+--------------------+ | 識別子| +-----------------------+
The three-octet Organizationally Unique Identifier (OUI) identifies an organization which administers the meaning of the Protocol Identifier (PID) which follows. Together they identify a distinct protocol. Note that OUI 0x00-00-00 specifies that the following PID is an Ethertype.
3八重奏のOrganizationally Unique Identifier(OUI)は続くプロトコルIdentifier(PID)の意味を管理する組織を特定します。 彼らは異なったプロトコルを一緒に、特定します。 以下のPIDは0×00 00-00が指定するOUIですが、それに注意してください。Ethertype。
Brown & Malis Standards Track [Page 5] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[5ページ]。
4.1. Routed Frames
4.1. 発送されたフレーム
Some protocols will have an assigned NLPID, but because the NLPID numbering space is limited, not all protocols have specific NLPID values assigned to them. When packets of such protocols are routed over Frame Relay networks, they are sent using the NLPID 0x80 (which indicates the presence of a SNAP header) followed by SNAP. If the protocol has an Ethertype assigned, the OUI is 0x00-00-00 (which indicates an Ethertype follows), and PID is the Ethertype of the protocol in use.
いくつかのプロトコルには割り当てられたNLPIDがあるでしょうが、NLPID付番スペースが限られているので、すべてのプロトコルも、特定のNLPID値はそれらに割り当てるというわけではありませんでした。 そのようなプロトコルのパケットをFrame Relayネットワークの上に発送するとき、それらにSNAPによって続かれたNLPID0x80(SNAPヘッダーの存在を示します)を使用させます。 プロトコルでEthertypeを割り当てるなら、OUIは0×00 00-00(Ethertypeが続くのを示す)です、そして、PIDは使用中のプロトコルのEthertypeです。
When a SNAP header is present as described above, a one octet pad is used to align the protocol data on a two octet boundary as shown below.
SNAPヘッダーが上で説明されるように出席しているとき、1個の八重奏パッドが、以下に示すように2八重奏境界にプロトコルデータを並べるのに使用されます。
Format of Routed Frames
with a SNAP Header
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | Organization- |
+---------------+ |
| ally Unique Identifier (OUI) |
+-------------------------------+
| Protocol Identifier (PID) |
+-------------------------------+
| |
| Protocol Data |
| |
+-------------------------------+
| FCS |
+-------------------------------+
即座のヘッダー+がある発送されたフレームの形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| 組織| +---------------+ | | 同盟国Unique Identifier(OUI)| +-------------------------------+ | プロトコル識別子(PID)| +-------------------------------+ | | | プロトコルデータ| | | +-------------------------------+ | FCS| +-------------------------------+
In the few cases when a protocol has an assigned NLPID (see Appendix A), 48 bits can be saved using the format below:
プロトコルに割り当てられたNLPIDがあるときの(Appendix Aを見てください)わずかな場合では、以下の形式を使用することで48ビットを節約できます:
Format of Routed NLPID Protocol
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
発送されたNLPIDプロトコル+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| NLPID| +---------------+---------------+ | プロトコルデータ| +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 6] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[6ページ]。
When using the NLPID encapsulation format as described above, the pad octet is not used.
上で説明されるようにNLPIDカプセル化形式を使用するとき、パッド八重奏は使用されていません。
In the case of ISO protocols, the NLPID is considered to be the first octet of the protocol data. It is unnecessary to repeat the NLPID in this case. The single octet serves both as the demultiplexing value and as part of the protocol data (refer to "Other Protocols over Frame Relay for more details). Other protocols, such as IP, have a NLPID defined (0xCC), but it is not part of the protocol itself.
ISOプロトコルの場合では、NLPIDはプロトコルデータの最初の八重奏であると考えられます。 この場合NLPIDを繰り返すのは不要です。 ただ一つの八重奏が逆多重化値としてプロトコルデータの一部として機能する、(言及、「その他の詳細のためのFrame Relayの上の他のプロトコル)」 IPなどの他のプロトコルでNLPIDを定義しますが(0xCC)、それはプロトコル自体の一部ではありません。
Format of Routed IP Datagram
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0xCC |
+---------------+---------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+
発送されたIPデータグラム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| NLPID 0xCC| +---------------+---------------+ | IPデータグラム| +-------------------------------+ | FCS| +-------------------------------+
4.2. Bridged Frames
4.2. フレームであるとブリッジされます。
The second type of Frame Relay traffic is bridged packets. These packets are encapsulated using the NLPID value of 0x80 indicating SNAP. As with other SNAP encapsulated protocols, there will be one pad octet to align the data portion of the encapsulated frame. The SNAP header which follows the NLPID identifies the format of the bridged packet. The OUI value used for this encapsulation is the 802.1 organization code 0x00-80-C2. The PID portion of the SNAP header (the two bytes immediately following the OUI) specifies the form of the MAC header, which immediately follows the SNAP header. Additionally, the PID indicates whether the original FCS is preserved within the bridged frame.
2番目のタイプのFrame Relayトラフィックはパケットであるとブリッジされます。 これらのパケットは、SNAPを示す0×80のNLPID値を使用することでカプセルに入れられます。 他のSNAPがプロトコルであるとカプセル化されていると、カプセル化されたフレームのデータ部を並べる1つのパッド八重奏があるでしょう。 NLPIDの後をつけるSNAPヘッダーはブリッジしているパケットの形式を特定します。 このカプセル化に使用されるOUI値は0×00 802.1組織コード80-C2です。 SNAPヘッダー(すぐにOUIに続く2バイト)のPID部分はMACヘッダーのフォームを指定します。(ヘッダーはすぐに、SNAPヘッダーについて来ます)。 さらに、PIDは、オリジナルのFCSがブリッジしているフレームの中に保存されるかどうかを示します。
Following the precedent in RFC 1638 [4], non-canonical MAC destination addresses are used for encapsulated IEEE 802.5 and FDDI frames, and canonical MAC destination addresses are used for the remaining encapsulations defined in this section.
RFC1638[4]で先例に従って、正典外のMAC送付先アドレスはカプセル化されたIEEE802.5とFDDIフレームに使用されます、そして、正準なMAC送付先アドレスはこのセクションで定義された残っているカプセル化に使用されます。
The 802.1 organization has reserved the following values to be used with Frame Relay:
802.1組織はFrame Relayと共に使用されるために以下の値を予約しました:
Brown & Malis Standards Track [Page 7] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[7ページ]。
PID Values for OUI 0x00-80-C2
PIDはOUIのために0×00 80-C2を評価します。
with preserved FCS w/o preserved FCS Media
------------------ ----------------- ----------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
保存されたFCSメディアのない保存されたFCSと共に------------------ ----------------- ---------------- 0×00イーサネットの0×00-02の0×00-03の0×00-09 802.5の0×00-04の0×00-08 802.4の0×00 0A FDDIの0×00-01 0×00-07 802.3/0B802.6
In addition, the PID value 0x00-0E, when used with OUI 0x00-80-C2,
identifies Bridge Protocol Data Units (BPDUs) as defined by
802.1(d) or 802.1(g) [12], and the PID value 0x00-0F identifies
Source Routing BPDUs.
さらに、OUIが0×00 80-C2である状態で使用されると、802.1(d)か802.1(g)[12]によって定義されるようにPID値はBridgeプロトコルData Units(BPDUs)を0×00-0E特定します、そして、PID値はSourceルート設定BPDUsを0×00-0F特定します。
A packet bridged over Frame Relay will, therefore, have one of the following formats:
したがって、Frame Relayの上でブリッジされたパケットは以下の形式の1つを持つでしょう:
Format of Bridged Ethernet/802.3 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
| FCS |
+-------------------------------+
ブリッジしているイーサネット/802.3フレーム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| OUI0x00| +---------------+ --+ | OUI、0×80C2| +-------------------------------+ | PID0×00-01か0×00-07| +-------------------------------+ | MAC送付先アドレス| : : | | +-------------------------------+ | (MACフレームの残り) | +-------------------------------+ | LAN FCS(PIDが01 0×00-歳であるなら)| +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 8] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[8ページ]。
Format of Bridged 802.4 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
| FCS |
+-------------------------------+
ブリッジしている802.4フレーム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| OUI0x00| +---------------+ --+ | OUI、0×80C2| +-------------------------------+ | PID0×00-02か0×00-08| +---------------+---------------+ | パッド0x00| フレームコントロール| +---------------+---------------+ | MAC送付先アドレス| : : | | +-------------------------------+ | (MACフレームの残り) | +-------------------------------+ | LAN FCS(PIDが02 0×00-歳であるなら)| +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 9] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[9ページ]。
Format of Bridged 802.5 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
ブリッジしている802.5フレーム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| OUI0x00| +---------------+ --+ | OUI、0×80C2| +-------------------------------+ | PID0×00-03か0×00-09| +---------------+---------------+ | パッド0x00| フレームコントロール| +---------------+---------------+ | MAC送付先アドレス| : : | | +-------------------------------+ | (MACフレームの残り) | +-------------------------------+ | LAN FCS(PIDが03 0×00-歳であるなら)| | | +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 10] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[10ページ]。
Format of Bridged FDDI Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
ブリッジしているFDDIフレーム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| OUI0x00| +---------------+ --+ | OUI、0×80C2| +-------------------------------+ | PID0×00-04か0×00 0A| +---------------+---------------+ | パッド0x00| フレームコントロール| +---------------+---------------+ | MAC送付先アドレス| : : | | +-------------------------------+ | (MACフレームの残り) | +-------------------------------+ | LAN FCS(PIDが04 0×00-歳であるなら)| | | +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 11] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[11ページ]。
Format of Bridged 802.6 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+
ブリッジしている802.6フレーム+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| パッド0x00| +---------------+---------------+ | NLPID0x80| OUI0x00| +---------------+ --+ | OUI、0×80C2| +-------------------------------+ | PID、0×00 0B| +---------------+---------------+ ------- | 予約されます。| BEtag| 一般的な+---------------+---------------+ PDU| BAsize| ヘッダー+-------------------------------+ ------- | MAC送付先アドレス| : : | | +-------------------------------+ | (MACフレームの残り) | +-------------------------------+ | | +一般的なPDUトレーラ-+| | +-------------------------------+ | FCS| +-------------------------------+
Note that in bridge 802.6 PDUs, there is only one choice for the PID value, since the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame.
PID値のために802.6PDUsであり1つの選択しかブリッジでは、ないことに注意してください、CRC-32の存在がMACフレームのヘッダーでCIBビットによって示されるので。
The Common Protocol Data Unit (CPDU) Header and Trailer are conveyed to allow pipelining at the egress bridge to an 802.6 subnetwork. Specifically, the CPDU Header contains the BAsize field, which contains the length of the PDU. If this field is not available to the egress 802.6 bridge, then that bridge cannot begin to transmit the segmented PDU until it has received the entire PDU, calculated the length, and inserted the length into the BAsize field. If the field is available, the egress 802.6 bridge can extract the length from the BAsize field of the Common PDU Header, insert it into the corresponding field of the first segment, and immediately transmit the segment onto the 802.6 subnetwork. Thus, the bridge can begin transmitting the 802.6 PDU before it has received the complete PDU.
CommonプロトコルData Unit(CPDU)ヘッダーとTrailerは、出口ブリッジに802.6サブネットワークにパイプライン処理を許容するために運ばれます。 明確に、CPDU HeaderはBAsize分野を含んでいます。(それは、PDUの長さを含みます)。 この分野が出口802.6ブリッジに利用可能でないなら、BAsize分野に全体のPDUを受けて、長さについて計算して、長さを挿入するまで、そのブリッジは区分されたPDUを伝え始めることができません。 分野が利用可能であるなら、802.6がブリッジする出口は、Common PDU HeaderのBAsize分野から長さを抽出して、最初のセグメントの対応する分野にそれを挿入して、すぐに、802.6サブネットワークにセグメントを伝えることができます。 したがって、ブリッジは、完全なPDUを受ける前に802.6PDUを伝え始めることができます。
Brown & Malis Standards Track [Page 12] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[12ページ]。
One should note that the Common PDU Header and Trailer of the encapsulated frame should not be simply copied to the outgoing 802.6 subnetwork because the encapsulated BEtag value may conflict with the previous BEtag value transmitted by that bridge.
カプセル化されたBEtag値がそのブリッジによって送られる前のBEtag値と闘争するかもしれないのでカプセル化されたフレームのCommon PDU HeaderとTrailerが出発している802.6サブネットワークに絶対にコピーされるべきでないことに注意するべきです。
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g)[12] |
| |
+-------------------------------+
| FCS |
+-------------------------------+
BPDUフレーム+の形式-------------------------------+ | Q.922アドレス| +-------------------------------+ | コントロール0x03| +-------------------------------+ | パッド0x00| +-------------------------------+ | NLPID0x80| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-0E| +-------------------------------+ | | | 定義されるBPDU| | 802.1(d)か802.1(g)[12]| | | +-------------------------------+ | FCS| +-------------------------------+
Format of Source Routing BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0F |
+-------------------------------+
| |
| Source Routing BPDU |
| |
| |
+-------------------------------+
| FCS |
+-------------------------------+
ソースルート設定BPDUフレーム+の形式-------------------------------+ | Q.922アドレス| +-------------------------------+ | コントロール0x03| +-------------------------------+ | パッド0x00| +-------------------------------+ | NLPID0x80| +-------------------------------+ | OUI、0×00 80-C2| +-------------------------------+ | PID0×00-0F| +-------------------------------+ | | | ソースルート設定BPDU| | | | | +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 13] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[13ページ]。
5. Data Link Layer Parameter Negotiation
5. データ・リンク層パラメタ交渉
Frame Relay stations may choose to support the Exchange Identification (XID) specified in Appendix III of Q.922 [1]. This XID exchange allows the following parameters to be negotiated at the initialization of a Frame Relay circuit: maximum frame size N201, retransmission timer T200, and the maximum number of outstanding Information (I) frames K.
フレームRelayステーションは、Q.922[1]のAppendix IIIで指定されたExchange Identification(XID)をサポートするのを選ぶかもしれません。 このXID交換は、以下のパラメタがFrame Relay回路の初期化のときに交渉されるのを許容します: 傑出している情報(I)の最大のフレーム・サイズN201、再送信タイマーT200、および最大数はKを縁どっています。
A station may indicate its unwillingness to support acknowledged mode multiple frame operation by specifying a value of zero for the maximum window size, K.
ステーションは、承認されたモードが複数のフレーム操作であると最大のウィンドウサイズ(K)にゼロの値を指定することによってサポートするために気がすすまないことを示すかもしれません。
If this exchange is not used, these values must be statically configured by mutual agreement of Data Link Connection (DLC) endpoints, or must be defaulted to the values specified in Section 5.9 of Q.922:
この交換が使用されていないなら、これらの値は、Data Link Connection(DLC)終点で合意で静的に構成しなければならないか、またはデフォルトとして、値がQ.922のセクション5.9で指定したということでなければなりません:
N201: 260 octets
N201: 260の八重奏
K: 3 for a 16 Kbps link,
7 for a 64 Kbps link,
32 for a 384 Kbps link,
40 for a 1.536 Mbps or above link
K: 3 16Kbpsリンク、64Kbpsリンクへの7、384Kbpsリンクへの32、1.536Mbpsのための40または上のリンクに
T200: 1.5 seconds [see Q.922 for further details]
T200: 1.5秒[さらに詳しい明細についてはQ.922を見ます]
If a station supporting XID receives an XID frame, it shall respond with an XID response. In processing an XID, if the remote maximum frame size is smaller than the local maximum, the local system shall reduce the maximum size it uses over this DLC to the remotely specified value. Note that this shall be done before generating a response XID.
XIDをサポートするステーションがXIDフレームを受けるなら、それはXID応答で応じるものとします。 リモート最大のフレーム・サイズが地方の最大よりわずかであるならXIDを処理する際に、ローカルシステムはそれがこのDLCの上で離れて指定された値に使用する最大サイズを減少させるものとします。 応答がXIDであると生成する前にこれをすることに注意してください。
The following diagram describes the use of XID to specify non-use of acknowledged mode multiple frame operation.
以下のダイヤグラムは、モードの承認された倍数フレーム操作の非使用を指定するためにXIDの使用について説明します。
Brown & Malis Standards Track [Page 14] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[14ページ]。
Non-use of Acknowledged Mode Multiple Frame Operation
+---------------+
| Address | (2,3 or 4 octets)
| |
+---------------+
| Control 0xAF |
+---------------+
| format 0x82 |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length | (2 octets)
| 0x00-0E |
+---------------+
| 0x05 | PI = Frame Size (transmit)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x06 | PI = Frame Size (receive)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x07 | PI = Window Size
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| 0x09 | PI = Retransmission Timer
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| FCS | (2 octets)
| |
+---------------+
モードの承認された倍数フレーム操作+の非使用---------------+ | アドレス| (2、3または4つの八重奏) | | +---------------+ | コントロール0xAF| +---------------+ | 形式0x82| +---------------+ | グループID0x80| +---------------+ | グループの長さ| (2つの八重奏) | 0×00-0E| +---------------+ | 0×05| パイ=フレーム・サイズ(伝える)+---------------+ | 0×02| PL=2+---------------+ | 最大| (2つの八重奏) | フレーム・サイズ| +---------------+ | 0×06| パイ=フレーム・サイズ(受信する)+---------------+ | 0×02| PL=2+---------------+ | 最大| (2つの八重奏) | フレーム・サイズ| +---------------+ | 0×07| パイ=ウィンドウサイズ+---------------+ | 0×01| PL=1+---------------+ | 0×00| +---------------+ | 0×09| パイ=再送信タイマー+---------------+ | 0×01| PL=1+---------------+ | 0×00| +---------------+ | FCS| (2つの八重奏) | | +---------------+
6. Address Resolution for PVCs
6. PVCsのためのアドレス解決
This document only describes address resolution as it applies to PVCs. SVC operation will be discussed in future documents.
それがPVCsに適用されるとき、このドキュメントはアドレス解決について説明するだけです。 将来のドキュメントでSVC操作について議論するでしょう。
Brown & Malis Standards Track [Page 15] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[15ページ]。
There are situations in which a Frame Relay station may wish to dynamically resolve a protocol address over PVCs. This may be accomplished using the standard Address Resolution Protocol (ARP) [6] encapsulated within a SNAP encoded Frame Relay packet as follows:
Frame RelayステーションがPVCsの上でダイナミックにプロトコルアドレスを決議したがっているかもしれない状況があります。 これは[6]がSNAPの中で以下のコード化されたFrame Relayパケットをカプセルに入れった標準のAddress Resolutionプロトコル(ARP)を使用することで達成されるかもしれません:
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+ | Q.922アドレス| +-----------------------+-----------------------+ | コントロール(UI)0x03| パッド0x00| +-----------------------+-----------------------+ | NLPID0x80| | ヘッダー+を折ってください。-----------------------+ OUI0×00 00-00+表示| | アルプ+-----------------------+-----------------------+ | PID0x0806| +-----------------------+-----------------------+ | ARPパケット| | . | | . | | . | +-----------------------+-----------------------+
Where the ARP packet has the following format and values:
ARPパケットはどこに以下の形式を持っていますか、そして、値:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$hln 8 bits Octet length of hardware address (n)
ar$pln 8 bits Octet length of protocol address (m)
ar$op 16 bits Operation code (request or reply)
ar$sha noctets source hardware address
ar$spa moctets source protocol address
ar$tha noctets target hardware address
ar$tpa moctets target protocol address
データ: ar$のhrdの16ビットのHardwareはpln8ドルのハードウェア・アドレス(n)arビットOctetの長さの16ビットのプロトコルアドレス(m)ar$オプアートOperationコード(要求か回答)ar$sha noctetsソースハードウェア・アドレスar$鉱泉moctetsソースプロトコルアドレスar$tha noctets目標ハードウェア・アドレスar$tpa moctets目標プロトコルアドレスのhln8ドルのビットOctetの長さにar$プロの16ビットのプロトコルタイプarをタイプします。
ar$hrd - assigned to Frame Relay is 15 decimal
(0x000F) [7].
ar$hrd--Frame Relayに割り当てられているのは、15小数(0x000F)[7]です。
ar$pro - see assigned numbers for protocol ID number for
the protocol using ARP. (IP is 0x0800).
ar$プロ--ARPを使用することでプロトコルのプロトコルID番号の規定番号を見てください。 (IPは0×0800です。)
ar$hln - length in bytes of the address field (2, 3, or 4)
ar$hln--アドレス・フィールドのバイトで表現される長さ(2、3、または4)
ar$pln - protocol address length is dependent on the
protocol (ar$pro) (for IP ar$pln is 4).
ar$pln--プロトコルアドレスの長さはプロトコル(ar$プロ)に依存しています(IP ar$plnが4であるので)。
Brown & Malis Standards Track [Page 16] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[16ページ]。
ar$op - 1 for request and 2 for reply.
ar$オプアート--1 要求と回答のための2のために。
ar$sha - Q.922 source hardware address, with C/R, FECN,
BECN, and DE set to zero.
ar$sha--C/R、FECN、BECN、およびDEがあるQ.922ソースハードウェア・アドレスはゼロにセットしました。
ar$tha - Q.922 target hardware address, with C/R, FECN,
BECN, and DE set to zero.
ar$tha--C/R、FECN、BECN、およびDEがあるQ.922目標ハードウェアアドレスはゼロにセットしました。
Because DLCIs within most Frame Relay networks have only local significance, an end station will not have a specific DLCI assigned to itself. Therefore, such a station does not have an address to put into the ARP request or reply. Fortunately, the Frame Relay network does provide a method for obtaining the correct DLCIs. The solution proposed for the locally addressed Frame Relay network below will work equally well for a network where DLCIs have global significance.
ほとんどのFrame Relayネットワークの中のDLCIsにはローカルの意味しかないので、端のステーションは特定のDLCIをそれ自体に割り当てさせないでしょう。 したがって、そのようなステーションには、ARP要求か回答に置くアドレスがありません。 幸い、Frame Relayネットワークは正しいDLCIsを入手するためのメソッドを提供します。 以下の局所的に扱われたFrame Relayネットワークのために提案されたソリューションはDLCIsがグローバルな意味を持っているネットワークに等しくうまくいくでしょう。
The DLCI carried within the Frame Relay header is modified as it traverses the network. When the packet arrives at its destination, the DLCI has been set to the value that, from the standpoint of the receiving station, corresponds to the sending station. For example, in figure 1 below, if station A were to send a message to station B, it would place DLCI 50 in the Frame Relay header. When station B received this message, however, the DLCI would have been modified by the network and would appear to B as DLCI 70.
ネットワークを横断するとき、Frame Relayヘッダーの中に運ばれたDLCIは変更されています。 パケットが目的地に到着するとき、DLCIは受入れステーションの見地から送付ステーションに対応する値に用意ができていました。 例えば、以下の1図では、ステーションAがステーションBにメッセージを送るなら、それはDLCI50をFrame Relayヘッダーに置くでしょうに。 ステーションBがこのメッセージを受け取ったとき、しかしながら、DLCIはネットワークによって変更されて、DLCI70としてBに見えるでしょう。
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
~~~~~~~~~~~~~~~ ( ) +-----+ ( ) +-----+ | |-50------(--------------------)---------70-| | | A| ( ) | B| | |-60-----(---------+ ) | | +-----+ ( | ) +-----+、(|、)、(|、)、<。---フレームリレー~~~~~~~~~~~~~~~~ ネットワーク80| +-----+ | | | C| | | +-----+
Figure 1
図1
Lines between stations represent data link connections (DLCs).
The numbers indicate the local DLCI associated with each
connection.
ステーションの間の線はデータリンク接続(DLCs)の代理をします。 数は各接続に関連している地方のDLCIを示します。
Brown & Malis Standards Track [Page 17] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[17ページ]。
DLCI to Q.922 Address Table for Figure 1
図1のためのQ.922アドレス・テーブルへのDLCI
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401
DLCIの(10進)のQ.922が、(十六進法)50 0x0C21 60 0x0CC1 70が0×1061であると扱う、80、0×1401
For authoritative description of the correlation between DLCI and
Q.922 [1] addresses, the reader should consult that specification.
A summary of the correlation is included here for convenience. The
translation between DLCI and Q.922 address is based on a two byte
address length using the Q.922 encoding format. The format is:
DLCIとQ.922[1]アドレスの間の相関関係の正式の記述のために、読者はその仕様に相談するべきです。 相関関係の概要は便宜のためにここに含まれています。 DLCIとQ.922アドレスの間の翻訳は、Q.922コード化形式を使用することで2バイト・アドレスの長さに基づいています。 形式は以下の通りです。
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
8 7 6 5 4 3 2 1 +------------------------+---+--+ | DLCI(高位)|C/R|EA| +--------------+----+----+---+--+ | DLCI(下側の)|FECN|BECN|DE|EA| +--------------+----+----+---+--+
For ARP and its variants, the FECN, BECN, C/R and DE bits are
assumed to be 0.
ARPとその異形に関しては、FECN、BECN、C/R、およびDEビットは0であると思われます。
When an ARP message reaches a destination, all hardware addresses will be invalid. The address found in the frame header will, however, be correct. Though it does violate the purity of layering, Frame Relay may use the address in the header as the sender hardware address. It should also be noted that the target hardware address, in both ARP request and reply, will also be invalid. This should not cause problems since ARP does not rely on these fields and in fact, an implementation may zero fill or ignore the target hardware address field entirely.
ARPメッセージが目的地に達するとき、すべてのハードウェア・アドレスが無効になるでしょう。 しかしながら、フレームヘッダーで見つけられたアドレスは正しくなるでしょう。 レイヤリングの純粋さに違反しますが、Frame Relayは送付者ハードウェア・アドレスとしてヘッダーでアドレスを使用するかもしれません。 また、また、目標ハードウェアアドレスがARPが要求する両方と回答で無効になることに注意されるべきです。 ARPがこれらの分野を当てにしないのでこれが問題を起こすべきでなくて、事実上、実装は、中詰めのゼロを合わせるか、または目標ハードウェアアドレス・フィールドを完全に無視するかもしれません。
As an example of how this address replacement scheme may work, refer to figure 1. If station A (protocol address pA) wished to resolve the address of station B (protocol address pB), it would format an ARP request with the following values:
このアドレス交換体系がどううまくいくかもしれないかに関する例として、1について計算するには、参照してください。 ステーションA(プロトコルアドレスpA)がステーションB(プロトコルアドレスpB)のアドレスを決議したいなら、以下の値でARP要求をフォーマットするでしょうに:
ARP request from A
ar$op 1 (request)
ar$sha unknown
ar$spa pA
ar$tha undefined
ar$tpa pB
ARPはA ar$から未知の1オプアート(要求します)ar$sha arドルの鉱泉pA ar$tha未定義のar$tpa pBを要求します。
Brown & Malis Standards Track [Page 18] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[18ページ]。
Because station A will not have a source address associated with it, the source hardware address field is not valid. Therefore, when the ARP packet is received, it must extract the correct address from the Frame Relay header and place it in the source hardware address field. This way, the ARP request from A will become:
ステーションAにはそれに関連しているソースアドレスがないので、ソースハードウェアアドレス・フィールドが有効ではありません。 したがって、ARPパケットが受け取られているとき、それは、Frame Relayヘッダーから正しいアドレスを抜粋して、ソースハードウェアアドレス・フィールドにそれを置かなければなりません。 このように、AからのARP要求はなるでしょう:
ARP request from A as modified by B
ar$op 1 (request)
ar$sha 0x1061 (DLCI 70) from Frame Relay header
ar$spa pA
ar$tha undefined
ar$tpa pB
変更されるとしてのFrame Relayヘッダーar$鉱泉pA ar$tha未定義のar$tpa pBからのB ar1(要求する)オプアートarドルのsha0×1061ドル(DLCI70)によるAからのARP要求
Station B's ARP will then be able to store station A's protocol address and Q.922 address association correctly. Next, station B will form a reply message. Many implementations simply place the source addresses from the ARP request into the target addresses and then fills in the source addresses with its addresses. In this case, the ARP response would be:
駅のビーズARPはその時、正しくステーションAのプロトコルアドレスとQ.922アドレス協会を保存できるでしょう。 次に、ステーションBは応答メッセージを形成するでしょう。 多くの実装がソースアドレスをあて先アドレスへのARP要求と次に、ソースアドレスにおける中詰めからアドレスに単に置きます。 この場合、ARP応答は以下の通りでしょう。
ARP response from B
ar$op 2 (response)
ar$sha unknown
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
B ar$未知の2オプアート(応答)ar$sha arドルの鉱泉pB ar tha0×1061ドル(DLCI70)ar$tpa pAからのARP応答
Again, the source hardware address is unknown and when the response is received, station A will extract the address from the Frame Relay header and place it in the source hardware address field. Therefore, the response will become:
一方、ソースハードウェア・アドレスが未知であり、応答が受け取られているとき、ステーションAは、Frame Relayヘッダーからアドレスを抜粋して、ソースハードウェアアドレス・フィールドにそれを置くでしょう。 したがって、応答はなるでしょう:
ARP response from B as modified by A
ar$op 2 (response)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
変更されるとしてのA ar$2(応答)オプアートarドルのsha 0x0C21(DLCI50)ar$鉱泉pB ar tha0×1061ドル(DLCI70)ar$tpa pAのBからのARP応答
Station A will now correctly recognize station B having protocol address pB associated with Q.922 address 0x0C21 (DLCI 50).
駅Aは、現在、Q.922アドレス0x0C21(DLCI50)に関連しているプロトコルアドレスpBを持ちながら、正しくステーションBを認識するでしょう。
Reverse ARP (RARP) [8] works in exactly the same way. Still using figure 1, if we assume station C is an address server, the following RARP exchanges will occur:
[8]がまさに同じように扱うアルプ(RARP)を逆にしてください。 私たちが、ステーションCがアドレスサーバであると思うならまだ1図を使用していて、以下のRARP交換は起こるでしょう:
Brown & Malis Standards Track [Page 19] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[19ページ]。
RARP request from A RARP request as modified by C
ar$op 3 (RARP request) ar$op 3 (RARP request)
ar$sha unknown ar$sha 0x1401 (DLCI 80)
ar$spa undefined ar$spa undefined
ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60)
ar$tpa pC ar$tpa pC
3(RARP要求)オプアートarドルの3(RARP要求)オプアートarドルのC ar$のshaの未知のarによってsha0×1401ドル(DLCI80)のar$鉱泉未定義のar$鉱泉未定義のar$tha 0x0CC1(DLCI60)ar$tha 0x0CC1(DLCI60)ar$tpa pC ar$tpa pC変更されるA RARP要求からのRARP要求
Station C will then look up the protocol address corresponding to Q.922 address 0x1401 (DLCI 80) and send the RARP response.
駅Cは、次に、Q.922アドレス0x1401(DLCI80)に対応するプロトコルアドレスを調べて、RARP応答を送るでしょう。
RARP response from C RARP response as modified by A
ar$op 4 (RARP response) ar$op 4 (RARP response)
ar$sha unknown ar$sha 0x0CC1 (DLCI 60)
ar$spa pC ar$spa pC
ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80)
ar$tpa pA ar$tpa pA
0×1401(DLCI80)arドルのtpa pA ar$tpa pAのときにA ar$4(RARP応答)オプアートarドルの未知の4オプアート(RARP応答)ar$sha arドルのsha 0x0CC1(DLCI60)ar$鉱泉pC ar$鉱泉pC arによってtha0×1401ドル(DLCI80)のar$tha変更されるC RARP応答からのRARP応答
This means that the Frame Relay interface must only intervene in the processing of incoming packets.
これは、Frame Relayインタフェースが入って来るパケットの処理を干渉するだけでよいことを意味します。
In the absence of suitable multicast, ARP may still be implemented. To do this, the end station simply sends a copy of the ARP request through each relevant DLC, thereby simulating a broadcast.
適当なマルチキャストがないとき、ARPはまだ実装されているかもしれません。 これをするために、端のステーションはそれぞれの関連DLCを通して単にARP要求のコピーを送ります、その結果、放送をシミュレートします。
The use of multicast addresses in a Frame Relay environment, as specified by [19], is presently being considered by Frame Relay providers. In time, multicast addressing may become useful in sending ARP requests and other "broadcast" messages.
Frame Relay環境におけるマルチキャストアドレスの[19]によって指定される使用は現在、Frame Relayプロバイダーによって考えられています。 時間内に、マルチキャストアドレシングは送付ARP要求と他の「放送」メッセージで役に立つようになるかもしれません。
Because of the inefficiencies of emulating broadcasting in a Frame Relay environment, a new address resolution variation was developed. It is called Inverse ARP [11] and describes a method for resolving a protocol address when the hardware address is already known. In Frame Relay's case, the known hardware address is the DLCI. Support for Inverse ARP is not required to implement this specification, but it has proven useful for Frame Relay interface autoconfiguration. See [11] for its description and an example of its use with Frame Relay.
Frame Relay環境で放送される見習うことの非能率のために、新しいアドレス解決変化は開発されました。 それは、ハードウェア・アドレスが既に知られているときプロトコルアドレスを決議するためにInverse ARP[11]と呼ばれて、メソッドを説明します。 Frame Relayの場合では、知られているハードウェア・アドレスはDLCIです。 Inverse ARPのサポートはこの仕様を履行するのに必要ではありませんが、それはFrame Relayインタフェース自動構成のために有用であることが分かりました。 記述とFrame Relayとの使用に関する例のための[11]を見てください。
Stations must be able to map more than one IP address in the same IP subnet (CIDR address prefix) to a particular DLCI on a Frame Relay interface. This need arises from applications such as remote access, where servers must act as ARP proxies for many dial-in clients, each assigned a unique IP address while sharing bandwidth on the same DLC. The dynamic nature of such applications result in frequent address association changes with no affect on the DLC's status as reported by Frame Relay PVC Status Signaling.
駅は同じIPサブネット(CIDRアドレス接頭語)における1つ以上のIPアドレスをFrame Relayインタフェースの特定のDLCIに写像できなければなりません。 この必要性はサーバが多くのダイヤルインのクライアントのためのARPプロキシとして務めなければならない遠隔アクセスなどのアプリケーションから起こります、固有のIPアドレスが同じDLCにおける帯域幅を共有している間に割り当てられたそれぞれ。 Frame Relay PVC Status Signalingによって報告されるように頻繁なアドレス協会でのそのようなアプリケーション結果のダイナミックな本質は感情を全くDLCの状態に交換しません。
Brown & Malis Standards Track [Page 20] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[20ページ]。
As with any other interface that utilizes ARP, stations may learn the
associations between IP addresses and DLCIs by processing unsolicited
("gratuitous") ARP requests that arrive on the DLC. If one station
(perhaps a terminal server or remote access server) wishes to inform
its peer station on the other end of a Frame Relay DLC of a new
association between an IP address and that PVC, it should send an
unsolicited ARP request with the source IP address equal to the
destination IP address, and both set to the new IP address being used
on the DLC. This allows a station to "announce" new client
connections on a particular DLCI. The receiving station must store
the new association, and remove any old existing association, if
necessary, from any other DLCI on the interface.
いかなる他のインタフェースもARPを利用している場合、ステーションは、DLCで到着する求められていない(「無料」の)ARP要求を処理することによって、IPアドレスとDLCIsとの協会を学ぶかもしれません。 1つのステーション(恐らくターミナルサーバかリモートアクセス・サーバー)がIPアドレスとそのPVCとの新連合のFrame Relay DLCについてもう一方の端の同輩ステーションに知らせたいなら、それは、DLCで使用されることで送付先IPアドレス、および両方と等しいアドレスが新しいIPアドレスに設定したソースIPとの求められていないARP要求を送るべきです。 これは、ステーションが特定のDLCIで新しいクライアント接続を「発表すること」を許容します。 必要なら、受入れステーションは、インタフェースのいかなる他のDLCIからも新連合を保存して、どんな古い既存の協会も取り除かなければなりません。
7. IP over Frame Relay
7. フレームリレーの上のIP
Internet Protocol [9] (IP) datagrams sent over a Frame Relay network conform to the encapsulation described previously. Within this context, IP could be encapsulated in two different ways.
Frame Relayネットワークの上に送られたインターネットプロトコル[9](IP)データグラムは以前に説明されたカプセル化に一致しています。 この文脈の中では、2つの異なった方法でIPをカプセル化することができました。
1. NLPID value indicating IP
1. IPを示すNLPID値
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+ | Q.922アドレス| +-----------------------+-----------------------+ | コントロール(UI)0x03| NLPID 0xCC| +-----------------------+-----------------------+ | IPパケット| | . | | . | | . | +-----------------------+-----------------------+
Brown & Malis Standards Track [Page 21] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[21ページ]。
2. NLPID value indicating SNAP
2. SNAPを示すNLPID値
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+ | Q.922アドレス| +-----------------------+-----------------------+ | コントロール(UI)0x03| パッド0x00| +-----------------------+-----------------------+ | NLPID0x80| | ヘッダー+を折ってください。-----------------------+ OUI=0×00 00-00+表示| | IP+-----------------------+-----------------------+ | PID0x0800| +-----------------------+-----------------------+ | IPパケット| | . | | . | | . | +-----------------------+-----------------------+
Although both of these encapsulations are supported under the given definitions, it is advantageous to select only one method as the appropriate mechanism for encapsulating IP data. Therefore, IP data shall be encapsulated using the NLPID value of 0xCC indicating IP as shown in option 1 above. This (option 1) is more efficient in transmission (48 fewer bits), and is consistent with the encapsulation of IP in X.25.
これらのカプセル化の両方が与えられた定義でサポートされますが、IPデータをカプセル化するための適切な手段として1つのメソッドだけを選定するのは有利です。 したがって、IPデータは、上にオプション1で示されるようにIPを示す0xCCのNLPID値を使用することでカプセル化されるものとします。 これ(オプション1)は、トランスミッション(もう48ビット減)で、より効率的であり、X.25でIPのカプセル化と一致しています。
8. Other Protocols over Frame Relay
8. フレームリレーの上の他のプロトコル
As with IP encapsulation, there are alternate ways to transmit various protocols within the scope of this definition. To eliminate the conflicts, the SNAP encapsulation is only used if no NLPID value is defined for the given protocol.
IPカプセル化のように、この定義の範囲の中で様々なプロトコルを伝える代替の方法があります。 闘争を排除するために、NLPID値が全く与えられたプロトコルのために定義されない場合にだけ、SNAPカプセル化は使用されます。
As an example of how this works, ISO CLNP has a NLPID defined (0x81). Therefore, the NLPID field will indicate ISO CLNP and the data packet will follow immediately. The frame would be as follows:
これがどう働くかに関する例として、ISO CLNPはNLPIDを定義させます(0×81)。 したがって、NLPID分野は、ISO CLNPとデータ・パケットがすぐに続くのを示すでしょう。 フレームは以下の通りでしょう:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+
+---------------------------------------------+ | Q.922アドレス| +----------------------+----------------------+ | コントロール(UI)0x03| NLPID0x81(CLNP)| +----------------------+----------------------+ | CLNPパケットの残り| | . | | . | +---------------------------------------------+
Brown & Malis Standards Track [Page 22] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[22ページ]。
In this example, the NLPID is used to identify the data packet as CLNP. It is also considered part of the CLNP packet and as such, the NLPID should not be removed before being sent to the upper layers for processing. The NLPID is not duplicated.
この例では、NLPIDは、データ・パケットがCLNPであると認識するのに使用されます。 また、CLNPパケットの一部であるとそれを考えます、そして、そういうものとして、処理のために上側の層に送る前にNLPIDを取り外すべきではありません。 NLPIDはコピーされません。
Other protocols, such as IPX, do not have a NLPID value defined. As mentioned above, IPX would be encapsulated using the SNAP header. In this case, the frame would be as follows:
IPXなどの他のプロトコルには、定義されたNLPID値がありません。 以上のように、IPXは、SNAPヘッダーを使用することでカプセル化されるでしょう。 この場合、フレームは以下の通りでしょう:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+
+---------------------------------------------+ | Q.922アドレス| +----------------------+----------------------+ | コントロール(UI)0x03| パッド0x00| +----------------------+----------------------+ | NLPID0x80(折ります)| OUI--0×00 00 00| +----------------------+ | | | +---------------------------------------------+ | PID0x8137| +---------------------------------------------+ | IPXパケット| | . | | . | +---------------------------------------------+
9. Bridging Model for Frame Relay
9. フレームリレーのためにモデルをブリッジします。
The model for bridging in a Frame Relay network is identical to the model for remote bridging as described in IEEE P802.1g "Remote MAC Bridging" [13] and supports the concept of "Virtual Ports". Remote bridges with LAN ports receive and transmit MAC frames to and from the LANs to which they are attached. They may also receive and transmit MAC frames through virtual ports to and from other remote bridges. A virtual port may represent an abstraction of a remote bridge's point of access to one, two or more other remote bridges.
Frame Relayネットワークでブリッジするためのモデルは、リモートブリッジするために「リモートMACのブリッジIEEE P802.1g」[13]で説明されるようにモデルに同じであり、「仮想のポート」の概念をサポートします。 LANポートがあるリモートブリッジは、LANと、そして、それらが付けているLANからMACフレームを受けて、伝えます。 また、彼らは、仮想のポートを通してMACフレームを受けて、ブリッジと他のブリッジからリモート送るかもしれません。 仮想のポートはリモートブリッジの他の1、2つ以上のリモートブリッジへのアクセスのポイントの抽象化を表すかもしれません。
Remote Bridges are statically configured as members of a remote bridge group by management. All members of a remote bridge group are connected by one or more virtual ports. The set of remote MAC bridges in a remote bridge group provides actual or *potential* MAC layer interconnection between a set of LANs and other remote bridge groups to which the remote bridges attach.
リモートブリッジのメンバーが管理で分類するとき、リモートブリッジスは静的に構成されます。 リモートブリッジグループのすべてのメンバーが1つ以上の仮想のポートによって接されます。 リモートブリッジグループにおけるリモートMACブリッジのセットは1セットのLANの、そして、他のリモートブリッジの間の実際か*潜在的*MAC層インタコネクトにリモートブリッジが付くグループを提供します。
In a Frame Relay network there must be a full mesh of Frame Relay VCs between bridges of a remote bridge group. If the frame relay network is not a full mesh, then the bridge network must be divided into multiple remote bridge groups.
Frame Relayネットワークには、リモートブリッジグループのブリッジの間には、Frame Relay VCsの完全なメッシュがあるに違いありません。 フレームリレーネットワークが完全なメッシュでないなら、ブリッジネットワークを複数のリモートブリッジグループに分割しなければなりません。
Brown & Malis Standards Track [Page 23] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[23ページ]。
The frame relay VCs that interconnect the bridges of a remote bridge group may be combined or used individually to form one or more virtual bridge ports. This gives flexibility to treat the Frame Relay interface either as a single virtual bridge port, with all VCs in a group, or as a collection of bridge ports (individual or grouped VCs).
リモートブリッジグループのブリッジとインタコネクトするフレームリレーVCsは、1つ以上の仮想のブリッジポートを形成するのに個別に結合されるか、または使用されるかもしれません。 これは単一の仮想のブリッジポートとしてFrame Relayインタフェースを扱うために柔軟性を与えます、グループか、ブリッジポート(個々の、または、分類されたVCs)の収集としたすべてのVCsと共に。
When a single virtual bridge port provides the interconnectivity for all bridges of a given remote bridge group (i.e. all VCs are combined into a single virtual port), the standard Spanning Tree Algorithm may be used to determine the state of the virtual port. When more than one virtual port is configured within a given remote bridge group then an "extended" Spanning Tree Algorithm is required. Such an extended algorithm is defined in IEEE 802.1g [13]. The operation of this algorithm is such that a virtual port is only put into backup if there is a loop in the network external to the remote bridge group.
単一の仮想のブリッジポートが与えられたリモートブリッジグループのすべてのブリッジに相互接続性を提供するとき(すなわちすべてのVCsが単一の仮想のポートに結合されます)、標準のSpanning Tree Algorithmは、仮想のポートの状態を決定するのに使用されるかもしれません。 1つ以上の仮想のポートがその時与えられたリモートブリッジグループの中で構成されるとき、「広げられた」Spanning Tree Algorithmが必要です。 そのような拡張アルゴリズムはIEEE802.1g[13]で定義されます。 このアルゴリズムの操作がそのようなものであるので、リモートブリッジグループへの外部のネットワークに輪がある場合にだけ、仮想のポートをバックアップに入れます。
The simplest bridge configuration for a Frame Relay network is the LAN view where all VCs are combined into a single virtual port. Frames, such as BPDUs, which would be broadcast on a LAN, must be flooded to each VC (or multicast if the service is developed for Frame Relay services). Flooding is performed by sending the packet to each relevant DLC associated with the Frame Relay interface. The VCs in this environment are generally invisible to the bridge. That is, the bridge sends a flooded frame to the frame relay interface and does not "see" that the frame is being forwarded to each VC individually. If all participating bridges are fully connected (full mesh) the standard Spanning Tree Algorithm will suffice in this configuration.
Frame Relayネットワークのための最も簡単なブリッジ構成はすべてのVCsが単一の仮想のポートに結合されるLAN視点です。 LANで放送されるだろうBPDUsなどのフレームを各VCへあふれさせなければならない、(マルチキャスト、サービスがFrame Relayサービスのために開発される、) 氾濫は、Frame Relayインタフェースに関連しているそれぞれの関連DLCにパケットを送ることによって、実行されます。 一般に、この環境におけるVCsはブリッジに目に見えません。 すなわち、ブリッジは、水につかっているフレームをフレームリレーインタフェースに送って、フレームが個別に各VCに送られているのを「見ません」。 すべて参加しているブリッジが完全に接続されると(完全なメッシュ)、標準のSpanning Tree Algorithmはこの構成で十分でしょう。
Typically LAN bridges learn which interface a particular end station may be reached on by associating a MAC address with a bridge port. In a Frame Relay network configured for the LAN-like single bridge port (or any set of VCs grouped together to form a single bridge port), however, the bridge must not only associated a MAC address with a bridge port, but it must also associate it with a connection identifier. For Frame Relay networks, this connection identifier is a DLCI. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a DLC. Therefore, Frame Relay LAN-modeled bridges must provide a mechanism to allow the Frame Relay bridge port to dynamically learn the associations. To accomplish this dynamic learning, a bridged packet shall conform to the encapsulation described within section 4.2. In this way, the receiving Frame Relay interface will know to look into the bridged packet to gather the appropriate information.
通常、LANブリッジは、特定の端のステーションにどのインタフェースで達するかもしれないかをMACアドレスをブリッジポートに関連づけることによって、学びます。 Frame Relayでは、また、しかしながら、ブリッジが移植する(VCsのどんなセットも単一のブリッジポートを形成するために一緒に分類されました)シングル、ブリッジがそうしなければならないLANのようがブリッジポートがあるMACアドレスだけではなく、それも関連づけたので、構成されたネットワークはそれを接続識別子に関連づけなければなりません。 Frame Relayネットワークにおいて、この接続識別子はDLCIです。 DLCで静的にあらゆる可能な送付先MACアドレスの協会を構成するためにブリッジを必要とするのは、無理であって、恐らく不可能です。 したがって、LANでモデル化されたブリッジがFrame Relayを許容するためにメカニズムを供給しなければならないFrame Relayは、ダイナミックに協会を学ぶためにポートをブリッジします。 このダイナミックな学習を実行するために、ブリッジしているパケットはセクション4.2の中で説明されたカプセル化に従うものとします。 このように、受信Frame Relayインタフェースは適切な情報を集めるためにブリッジしているパケットを調べるのを知るでしょう。
Brown & Malis Standards Track [Page 24] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[24ページ]。
A second Frame Relay bridging approach, the point-to-point view, treats each Frame Relay VC as a separate bridge port. Flooding and forwarding packets are significantly less complicated using the point-to-point approach because each bridge port has only one destination. There is no need to perform artificial flooding or to associate DLCIs with destination MAC addresses. Depending upon the interconnection of the VCs, an extended Spanning Tree algorithm may be required to permit all virtual ports to remain active as long as there are no true loops in the topology external to the remote bridge group.
アプローチをブリッジする第2のFrame Relay(二地点間視点)は別々のブリッジポートとして各Frame Relay VCを扱います。 氾濫とパケットを進めるのはそれぞれのブリッジポートには1つの目的地しかないので二地点間アプローチを使用するのにおいてかなり複雑ではありません。 人工の氾濫を実行するか、または送付先MACアドレスにDLCIsを関連づける必要は全くありません。 VCsのインタコネクトによって、拡張Spanning Treeアルゴリズムが、どんな本当の輪もリモートブリッジグループへの外部のトポロジーにない限り、すべての仮想のポートがアクティブなままで残っているのを許容するのに必要であるかもしれません。
It is also possible to combine the LAN view and the point-to-point view on a single Frame Relay interface. To do this, certain VCs are combined to form a single virtual bridge port while other VCs are independent bridge ports.
また、単一のFrame Relayインタフェースに関するLAN意見と二地点間意見を結合するのも可能です。 これをするなら、あるVCsは、他のVCsが独立しているブリッジポートですが、単一の仮想のブリッジポートを形成するために結合されます。
The following drawing illustrates the different possible bridging configurations. The dashed lines between boxes represent virtual circuits.
以下の図面は異なった可能なブリッジする構成を例証します。 箱の間の投げつけられた系列は仮想の回路を表します。
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
+-------+ -------------------| B| / -------| | / / +-------+ / | +-------+/ \ +-------+ | A| -------| C| | |-----------------------| | +-------+\ +-------+ \ \ +-------+ \ | D| -------------------| | +-------+
Since there is less than a full mesh of VCs between the bridges in this example, the network must be divided into more than one remote bridge group. A reasonable configuration is to have bridges A, B, and C in one group, and have bridges A and D in a second.
ブリッジの間には、この例にVCsの完全なメッシュ以下があるので、ネットワークを1つ以上のリモートブリッジグループに分割しなければなりません。 妥当な構成は、1つのグループでブリッジA、B、およびCを持っていて、1秒後にブリッジAとDを持つことです。
Configuration of the first bridge group combines the VCs interconnection the three bridges (A, B, and C) into a single virtual port. This is an example of the LAN view configuration. The second group would also be a single virtual port which simply connects bridges A and D. In this configuration the standard Spanning Tree Algorithm is sufficient to detect loops.
最初のブリッジグループの構成はシングルへの仮想の3つのブリッジ(A、B、およびC)が移植するVCsインタコネクトを結合します。 これはLAN視点構成に関する例です。 また、グループが単にブリッジAを接続する単一の仮想のポートであるだろう、D.Inがこの構成である秒に、標準のSpanning Tree Algorithmは、輪を検出するために十分です。
Brown & Malis Standards Track [Page 25] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[25ページ]。
An alternative configuration has three individual virtual ports in the first group corresponding to the VCs interconnecting bridges A, B and C. Since the application of the standard Spanning Tree Algorithm to this configuration would detect a loop in the topology, an extended Spanning Tree Algorithm would have to be used in order for all virtual ports to be kept active. Note that the second group would still consist of a single virtual port and the standard Spanning Tree Algorithm could be used in this group.
代替の構成には、この構成への標準のSpanning Tree Algorithmのアプリケーションが輪を検出するトポロジー、拡張Spanning Tree AlgorithmがインタコネクトするブリッジのA、B、およびC.SinceとインタコネクトするVCsに対応する最初のグループの個々の仮想のポートがすべての仮想のポートがアクティブに保たれるのに使用されるために持っている3があります。 2番目のグループが単一の仮想のポートからまだ成っていて、このグループに標準のSpanning Tree Algorithmは使用できたことに注意してください。
Using the same drawing, one could construct a remote bridge scenario with three bridge groups. This would be an example of the point-to- point case. Here, the VC connecting A and B, the VC connecting A and C, and the VC connecting A and D are all bridge groups with a single virtual port.
同じ図面を使用して、1つは3つのブリッジグループと共にリモートブリッジシナリオを構成するかもしれません。 これはポイントからポイントへのケースに関する例でしょう。 ここで、AとDを接続しながらA、B、AとCを接続するVC、およびVCを接続するVCはすべて単一の仮想のポートがあるブリッジグループです。
10. Security Considerations
10. セキュリティ問題
This document defines mechanisms for identifying the multiprotocol encapsulation of datagrams over Frame Relay. There is obviously an element in trust in any encapsulation protocol - a receiver must trust that the sender has correctly identified the protocol being encapsulated. In general, there is no way for a receiver to try to ascertain that the sender did indeed use the proper protocol identification, nor would this be desired functionality.
このドキュメントは、Frame Relayの上でデータグラムの「マルチ-プロトコル」カプセル化を特定するためにメカニズムを定義します。 明らかに、どんなカプセル化プロトコルにも要素が信頼にはあります--受信機は、送付者が正しくカプセル化されるプロトコルを特定したと信じなければなりません。 一般に、受信機が、本当に、送付者が適切なプロトコル識別を使用したのを確かめようとする方法が全くありません、そして、これは必要な機能性でないでしょう。
It also specifies the use of ARP and RARP with Frame Relay, and is subject to the same security constraints that affect ARP and similar address resolution protocols. Because authentication is not a part of ARP, there are known security issues relating to its use (e.g., host impersonation). No additional security mechanisms have been added to ARP or RARP for use with Frame Relay networks.
それは、また、Frame Relayと共にARPとRARPの使用を指定して、ARPに影響する同じセキュリティ規制と同様のアドレス解決プロトコルを受けることがあります。 認証がARPの一部でないので、使用(例えば、ホストものまね)に関連する安全保障問題が知られています。 追加担保メカニズムは全く使用のためにFrame Relayネットワークと共にARPかRARPに加えられていません。
Brown & Malis Standards Track [Page 26] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[26ページ]。
11. Appendix A - NLPIDS and PIDs
11. 付録A--NLPIDSとPIDs
List of Commonly Used NLPIDs
一般的に使用されたNLPIDsのリスト
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0x8E IPv6
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]
0×00 Frame RelayのヌルNetwork LayerかInactive Set(Frame Relayと共に使用されない)0×08Q.933[2]0×80SNAP0x81ISO CLNP0x82ISO ESIS0x83ISO ISIS0x8E IPv6 0xB0 FRF.9Data Compression[14]0xB1 FRF.12断片化[18]0xCC IPv4 0xCF PPP[17]
List of PIDs of OUI 00-80-C2
OUI00-80-C2のPIDsのリスト
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or
802.1(g)[12].
0x00-0F Source Routing BPDUs
保存されたFCSメディアのない保存されたFCSと共に------------------ ----------------- -------------- 802.1(d)か802.1(g)[12]によって定義される0×00イーサネットの0×00-02の0×00-03の0×00-09 802.5の0×00-04の0×00-08 802.4の0×00 0A FDDIの0×00-01 0×00-07 802.3/0Bの0×00 0D Fragmentsの802.6の0×00-0EのBPDUs。 0×00-0Fのソースルート設定BPDUs
Brown & Malis Standards Track [Page 27] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[27ページ]。
12. Appendix B - Connection Oriented Procedures
12. 付録B--接続の指向の手順
This Appendix contains additional information and instructions for using ITU Recommendation Q.933 [2] and other ITU standards for encapsulating data over frame relay. The information contained here is similar (and in some cases identical) to that found in Annex E to ITU Q.933. The authoritative source for this information is in Annex E and is repeated here only for convenience.
このAppendixはITU Recommendation Q.933[2]を使用するための追加情報と指示とフレームリレーの上でデータをカプセル化する他のITU規格を含んでいます。 ここに含まれた情報は、Annex EでITU Q.933において見つけられたそれに、同様、そして、(いくつかの場合が同じ。)です。 この情報のための権威筋は、Annex Eにあって、便宜のためだけにここで繰り返されます。
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It contains values for many different protocols including IP, CLNP (ISO 8473), ITU Q.933, and ISO 8208. A figure summarizing a generic encapsulation technique over frame relay networks follows. The scheme's flexibility consists in the identification of multiple alternative to identify different protocols used either by
Network Level Protocol ID(NLPID)分野はISOとITUによって管理されます。 それはIP、CLNP(ISO8473)、ITU Q.933、およびISO8208を含む多くの異なったプロトコルのための値を含んでいます。 フレームリレーネットワークの上へジェネリックカプセル化技術をまとめている図は続きます。 体系の柔軟性は、使用される異なったプロトコルの身元を確認するために複数の選択肢の識別で成ります。
- end-to-end systems or
- LAN to LAN bride and routers or
- a combination of the above.
- または、または、終わりからエンドへのシステム、--、LAN花嫁とルータへのLAN、--上記の組み合わせ。
over frame relay networks.
フレームリレーネットワークの上で。
Q.922 control
|
|
--------------------------------------------
| |
UI I Frame
| |
--------------------------------- --------------
| 0x08 | 0x81 |0xCC | 0x80 |..01.... |..10....
| | | | | |
Q.933 CLNP IP SNAP ISO 8208 ISO 8208
| | Modulo 8 Modulo 128
| |
-------------------- OUI
| | |
L2 ID L3 ID -------
| User | |
| Specified | |
| 0x70 802.3 802.6
|
---------------------------
|0x51 |0x4E | |0x4C |0x50
| | | | |
7776 Q.922 Others 802.2 User
Specified
Q.922コントロール| | -------------------------------------------- | | UI Iフレーム| | --------------------------------- -------------- | 0×08| 0×81|0xCC| 0×80|..01.... |..10.... | | | | | | Q.933 CLNPのIPの即座のISO8208ISO8208| | 法8法128| | -------------------- OUI| | | L2ID L3ID------- | ユーザ| | | 指定されます。| | | 0×70 802.3 802.6| --------------------------- |0×51|0x4E| |0x4C|0×50| | | | | 7776人のQ.922他のもの802.2ユーザは指定しました。
Brown & Malis Standards Track [Page 28] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[28ページ]。
For those protocols which do not have a NLPID assigned or do not have a SNAP encapsulation, the NLPID value of 0x08, indicating ITU Recommendation Q.933 should be used. The four octets following the NLPID include both layer 2 and layer 3 protocol identification. The code points for most protocols are currently defined in ITU Q.933 low layer compatibility information element. The code points for "User Specified" are described in Frame Relay Forum FRF.3.1 [15]. There is also an escape for defining non-standard protocols.
NLPIDを持っていないそれらのプロトコルには、SNAPカプセル化を割り当てないでください、または持たないでください、0×08のNLPID値、ITU Recommendation Q.933が使用されるべきであるのを示して。 NLPIDに続く4つの八重奏が層2と層3のプロトコル識別の両方を含んでいます。 ほとんどのプロトコルのためのコード・ポイントは現在、ITU Q.933の低層の互換性情報要素で定義されます。 「ユーザは指定した」コード・ポイントがFrame Relay Forum FRF.3.1[15]で説明されます。 また、標準的でないプロトコルを定義するためのエスケープがあります。
Format of Other Protocols
using Q.933 NLPID
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| L2 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| L3 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
Q.933 NLPID+を使用する他のプロトコルの形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| NLPID0x08| +---------------+---------------+ | L2Protocol ID| | 八重奏1| 八重奏2| +---------------+---------------+ | L3Protocol ID| | 八重奏1| 八重奏2| +---------------+---------------+ | プロトコルデータ| +-------------------------------+ | FCS| +-------------------------------+
ISO 8802/2 with user specified
layer 3
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| 802/2 0x4C | 0x80 |
+---------------+---------------+
|User Spec. 0x70| Note 1 |
+---------------+---------------+
| DSAP | SSAP |
+---------------+---------------+
| Control (Note 2) |
+-------------------------------+
| Remainder of PDU |
+-------------------------------+
| FCS |
+-------------------------------+
ユーザの指定された層3の+があるISO8802/2-------------------------------+ | Q.922アドレス| +---------------+---------------+ | コントロール0x03| NLPID0x08| +---------------+---------------+ | 802/2 0x4C| 0×80| +---------------+---------------+ |ユーザ仕様。 0×70| 注意1| +---------------+---------------+ | DSAP| SSAP| +---------------+---------------+ | コントロール(注意2)| +-------------------------------+ | PDUの残り| +-------------------------------+ | FCS| +-------------------------------+
Brown & Malis Standards Track [Page 29] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[29ページ]。
Note 1: Indicates the code point for user specified
layer 3 protocol.
注意1: ユーザの指定された層3のプロトコルのためにコード・ポイントを示します。
Note 2: Control field is two octets for I-format and
S-format frames (see 88002/2)
注意2: 制御フィールドはI-形式とS-形式フレームへの2つの八重奏です。(88002/2を見ます)
Encapsulations using I frame (layer 2)
使用している私が縁どるカプセル化(層2)
The Q.922 I frame is for supporting layer 3 protocols which require acknowledged data link layer (e.g., ISO 8208). The C/R bit will be used for command and response indications.
私が縁どるQ.922は、認知データリンクレイヤ(例えば、ISO8208)を必要とするプロトコルを層3にサポートするものです。 C/Rビットはコマンドと応答指摘に使用されるでしょう。
Format of ISO 8208 frame
Modulo 8
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 8) Note 3 |
| |
+-------------------------------+
| FCS |
+-------------------------------+
ISO8208フレームModulo8+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | ....私が縁どるコントロール| +---------------+---------------+ | 8208年のパケット(法8)注意3| | | +-------------------------------+ | FCS| +-------------------------------+
Note 3: First octet of 8208 packet also identifies the
NLPID which is "..01....".
注意3: 「また、8208年のパケットの最初の八重奏はそうするNLPIDを特定します。」01....".
Format of ISO 8208 frame
Modulo 128
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 128) |
| Note 4 |
+-------------------------------+
| FCS |
+-------------------------------+
ISO8208フレームModulo128+の形式-------------------------------+ | Q.922アドレス| +---------------+---------------+ | ....私が縁どるコントロール| +---------------+---------------+ | 8208年のパケット(法128)| | 注意4| +-------------------------------+ | FCS| +-------------------------------+
Note 4: First octet of 8208 packet also identifies the
NLPID which is "..10....".
注意4: 「また、8208年のパケットの最初の八重奏はそうするNLPIDを特定します。」10....".
Brown & Malis Standards Track [Page 30] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[30ページ]。
13. Appendix C - Modifications from RFC 1490
13. 付録C--RFC1490からの変更
RFC 1490 has been widely implemented and used, and has been adopted by the Frame Relay Forum in FRF.3.1 [15] and by the ITU in Q.933 [2]. This section describes updates to RFC 1490 that have been made as a result of this implementation and interoperability experience, and which reflect current implementation practice.
RFC1490は広く実装されて、使用されて、FRF.3.1[15]のFrame Relay ForumとQ.933[2]のITUによって採用されました。 このセクションはこの実装と相互運用性経験の結果、作られていて、現在の実装習慣を反映するRFC1490にアップデートについて説明します。
Some language changes were necessary to clarify RFC 1490. None of these changes impacted the technical aspects of this document, but were required to keep diagrams and language specific and consistent. Specifics of these changes will not be listed here. Below are listed those changes which were significant.
いくつかの言語変化が、RFC1490をはっきりさせるのに必要でした。 これらの変化のいずれも、このドキュメントの技術的側面に影響を与えましたが、特定で一貫しているのにダイヤグラムと言語を保管するのに必要ではありませんでした。 これらの変化の詳細はここに記載されないでしょう。 以下であることは、記載されたものが、どれが重要であるかを変えるということです。
a) The requirement for stations to accept SNAP encapsulated protocols
for which a NLPID was available, was removed. RFC 1490 indicated
that, if a protocol, such as IP, had a designated NLPID value, it
must be used. Later the document required stations to accept a
SNAP encapsulated version of this same protocol. This is clearly
inconsistent. A compliant station must send and accept the NLPID
encapsulated version of such a protocol. It MAY accept the SNAP
encapsulation but should not be required to do so as these frames
are noncompliant.
a) ステーションがSNAPを受け入れるという要件はNLPIDが利用可能であり、取り外されたプロトコルをカプセル化しました。 RFC1490は、IPなどのプロトコルに指定されたNLPID値があったならそれを使用しなければならないのを示しました。 その後、ドキュメントは、ステーションがこの同じプロトコルのバージョンであるとカプセル化されたSNAPを受け入れるのを必要としました。 これは明確に矛盾しています。 言いなりになっているステーションは、そのようなプロトコルのバージョンであるとカプセル化されたNLPIDを送って、受け入れなければなりません。 それをSNAPカプセル化を受け入れるかもしれませんが、これらのフレームが不従順であるのでそうするために必要とするべきではありません。
b) Fragmentation was removed. To date there are no interoperable
implementations of the fragmentation algorithm presented in RFC
1490. Additionally, there have been several suggestions that the
proposed mechanisms are insufficient for some frame relay
applications. To this end, fragmentation was removed from this
document, and has been replaced by the fragmentation specified in
FRF.12 [18].
b) 断片化を取り除きました。 これまで、RFC1490に提示された断片化アルゴリズムのどんな共同利用できる実装もありません。 さらに、いくつかのフレームリレーアプリケーションに、提案されたメカニズムが不十分であるといういくつかの提案がありました。 このために、断片化をこのドキュメントから移して、FRF.12[18]で指定された断片化に取り替えました。
c) The address resolution presented in RFC 1490 referred only to PVC
environments and is insufficient for SVC environments. Therefore
the section title was changed to reflect this. Further work on
SVC address resolution will take place in the ION working group.
c) RFC1490に提示されたアドレス解決は、PVC環境だけについて言及して、SVC環境に、不十分です。 したがって、これを反映するためにセクションタイトルを変えました。 SVCアドレス解決に対するさらなる仕事はIONワーキンググループで行われるでしょう。
d) The encapsulation for Source Routing BPDUs was added, and the
lists in Appendix A were augmented.
d) Sourceルート設定BPDUsのためのカプセル化は加えられました、そして、Appendix Aのリストは増大しました。
e) The use of canonical and non-canonical MAC destination addresses
in the bridging encapsulations was clarified.
e) ブリッジするカプセル化における正準で正典外のMAC送付先アドレスの使用ははっきりさせられました。
f) The Inverse ARP description was moved to the Inverse ARP
specification [11].
f) Inverse ARP記述はInverse ARP仕様[11]に動かされました。
g) A new security section was added.
g) 新しいセキュリティ部は加えられました。
Brown & Malis Standards Track [Page 31] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[31ページ]。
14. References
14. 参照
[1] International Telecommunication Union, "ISDN Data Link Layer
Specification for Frame Mode Bearer Services", ITU-T
Recommendation Q.922, 1992.
[1]国際電気通信連合、「フレーム方式運搬人サービスのためのISDNデータ・リンク層仕様」、ITU-T推薦Q.922、1992。
[2] International Telecommunication Union, "Signalling Specifications
for Frame Mode Switched and Permanent Virtual Connection Control
and Status Monitoring", ITU-T Recommendation Q.933, 1995.
[2] 国際電気通信連合、「切り換えられたフレーム方式、相手固定接続コントロール、および状態モニターのために仕様に合図します」、ITU-T推薦Q.933、1995。
[3] Information technology - Telecommunications and Information
Exchange between systems - Protocol Identification in the Network
Layer, ISO/IEC TR 9577: 1992.
[3] 情報技術(システムの間のテレコミュニケーションと情報Exchange)はNetwork Layer、ISO/IEC TR9577でIdentificationについて議定書の中で述べます: 1992.
[4] Baker, F., and R. Bowen, "PPP Bridging Control Protocol (BCP)",
RFC 1638, June 1994.
[4] ベイカー、F.、およびR.ボーエン、「コントロールがプロトコル(BCP)であるとブリッジするppp」、RFC1638、1994年6月。
[5] International Standard, Information Processing Systems - Local
Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE,
Second Edition, 1994-12-30.
[5] 国際規格、情報処理システム--ローカル・エリア・ネットワーク--論理的なリンク制御、ISO8802-2、ANSI/IEEE、第2版、1994年12月30日。
[6] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC 826, November
1982.
[6] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、STD37、RFC826(1982年11月)
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[7] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", STD 38, RFC 903, June 1984.
[8] フィンリースンとR.とマンとR.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」STD38、RFC903(1984年6月)。
[9] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC 1042, February 1988.
[9] ポステル、J.、およびJ.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、RFC1042(1988年2月)。
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
Overview and architecture", IEEE Standard 802-1990.
[10] IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「概要とアーキテクチャ」、IEEE Standard802-1990。
[11] Bradley, T., Brown, C., and A. Malis, "Inverse Address
Resolution Protocol", RFC 2390, September 1998.
[11]ブラッドリーとT.とブラウン、C.とA.Malis、「逆さのアドレス解決プロトコル」、RFC2390、1998年9月。
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media
Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[12] IEEE、「ローカルと首都のIEEE規格は以下をネットワークでつなぎます」。 「メディアアクセス制御(MAC)ブリッジ」、IEEEの標準の802.1D-1990。
[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media
Access Control (MAC) Bridging, March 12, 1997.
[13] ISO/IEC15802-5: 1998 (IEEEの標準の802.1G)、1997年3月12日にブリッジして、リモートメディアアクセスは(MAC)を制御します。
Brown & Malis Standards Track [Page 32] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[32ページ]。
[14] Frame Relay Forum, "Data Compression Over Frame Relay
Implementation Agreement", FRF.9, January 22, 1996.
[14] フレームリレーフォーラム、「フレームリレー実装協定の上のデータ圧縮」、FRF.9、1996年1月22日。
[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation
Agreement", FRF.3.1, June 22, 1995.
[15]フレームリレーフォーラム、「Multiprotocolカプセル化実装協定」、FRF.3.1、1995年6月22日。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[16] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[17] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[17] シンプソン、W.、「フレームリレーにおけるppp」、RFC1973、1996年6月。
[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation
Agreement", FRF.12, December 1997.
[18]フレームリレーフォーラム、「フレームリレー断片化実装協定」、FRF.12、1997年12月。
[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and
Protocol Implementation Agreement", FRF.7, October 21, 1994.
[19]フレームリレーフォーラムと、「フレームリレーPVCマルチキャストサービスとプロトコル実装協定」、1994年10月21日のFRF.7。
15. Authors' Addresses
15. 作者のアドレス
Caralyn Brown Consultant
Caralynブラウンコンサルタント
EMail: cbrown@juno.com
メール: cbrown@juno.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
アンドリューMalisはInc.1ロビンス・Roadウェストフォード、Communications MA 01886を昇ります。
Phone: (978) 952-7414 EMail: malis@ascend.com
以下に電話をしてください。 (978) 952-7414 メールしてください: malis@ascend.com
Brown & Malis Standards Track [Page 33] RFC 2427 Multiprotocol over Frame Relay September 1998
ブラウンとMalis規格は1998年9月にフレームリレーの上でRFC2427Multiprotocolを追跡します[33ページ]。
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Brown & Malis Standards Track [Page 34]
ブラウンとMalis標準化過程[34ページ]
一覧
スポンサーリンク
