|
Network Working Group Request for Comments: 2427 STD: 55 Obsoletes: 1490, 1294 Category: Standards Track |
C. Brown Consultant A. Malis Ascend Communications, Inc. September 1998 |
このドキュメントは、インターネット社会のためのインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このメモは、フレームリレーのバックボーン上に、ネットワーク相互接続トラフィックを運ぶためのカプセル化方法について規定している。これは、ブリッジングとルーティングの両面をカバーしている。
このドキュメントで規定された両方のカプセル化方法を転送する能力を持つシステムは、仮想回線がどのカプセル化方法を運ぶかについての知識を優先的に持たなければならない。そしてこのカプセル化は、それを使用するために明示的に設定された仮想回線上でのみ使用しなければならない。
このドキュメントは、Avici Systems, Inc. の Terry Bradley のサポート無しでは完成しなかったであろう。多くの情報源からのコメントや貢献、特に Proteon の Ray Samora、Visual Networks の Ken Rehbehn、Cisco Systems の Fred Baker と Charles Carvalho、AT&T の Mostafa Sherif が、このドキュメントに組み込んでくれた。Michigan 大学の Dory Leifer には、フラグメント問題の解決方法についての貢献 (最終版では削除されたが) に対し、そして 3Com の Floyd Backes と Laura Bridge には、ブリッジングの既定についての貢献に対して特に感謝したい。このドキュメントは、大規模公衆データネットワーク上の IP や NBMA 上の IP に関する IETF の作業団体の専門家がいなければ、完成しなかったであろう。
Table of Contents
1. 表記方法と略語
2. 導入
3. フレーム形式
4. 相互接続の問題
4.1. routed フレーム
4.2. bridged フレーム
5. データリンク層パラメタの折衝
6. PVC でのアドレス解決
7. フレームリレー上の IP
8. フレームリレー上の他のプロトコル
9. フレームリレーにおけるブリッジングモデル
10. セキュリティの考慮
11. 付録 A - NLPIDS と PIDs
12. 付録 B - コネクション型の手続き
13. 付録 C - RFC1490 からの変更点
14. 参照
15. 作者のアドレス
16. 完全なコピーライト宣言
このドキュメントで、キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL が表れた場合、[16] で既定されているように解釈する。
このドキュメント中の図は全て、最も左側のビットが送信時の最上位ビットであるものとして書かれている。例えば、図は以下のようなラベルが付けられるかもしれない。
0 1 2 3 4 5 6 7 bits
+---+---+---+---+---+---+---+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
: :
: :
+---------------------------+
各オクテットを 1 行で表したら 1 ページに収まりきらない大きな図は、1 行につき 2 オクテットで記述する。これらの最も左側のビットも、送信時の最上位ビットであるものとして記述される。オクテット間を区別するために、以下の例のように "+" が記述される。
|--- octet one ---|--- octet two ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
以下は、このドキュメントを通して使用される共通の略語である。
BECN - 逆方向明示的輻輳通知 (Backward Explicit Congestion Notification)
BPDU - ブリッジプロトコルデータ単位 (Bridge Protocol Data Unit)
C/R - コマンド/応答ビット (Command/Response bit)
DCE - データ通信装置 (Data Communication Equipment)
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)
以下の議論は、公共か私的なフレームリレーネットワーク (例えば、一般通信事業者や PIT によって提供される) 上で、終端局 (DTE) として働く装置に適用される。DTE が反応しなければならない状況を説明する目的以外では、フレームリレーネットワークの一部 (DCE) と見なされる局の振る舞いについては論じない。
フレームリレーネットワークは、同じフレームリレーネットワークに接続された局間のコネクションの基礎を成す、数多くの仮想回線を提供する。その結果である一連の相互接続された装置は、仮想回線の完全な "メッシュ" と完全に相互接続されているか、部分的に相互接続されているかのいずれかである私的なフレームリレーグループを形成する。いずのケースも各々の仮想回線は、各フレームリレーインタフェースにおいて、データリンクコネクション識別子 (DLCI: Data Link Connection Identifier) によってユニークに識別される。大半の環境で、DLCI は各フレームリレーインタフェースにおいて厳密にローカルな意味を持つ。
このドキュメントの規約は、交換と専用の仮想回線の両方に適用されることを意図している。
全てのプロトコルは、Q.922 Annex A フレーム [1] の中にパケットをカプセル化しなければならない。さらにフレームは、プロトコルデータユニット (PDU) の中で運ばれるプロトコルを識別するのに必要な情報を含むべきである。それによって、受信側は適切に入力パケットを処理することが可能になる。その形式は以下とすべきである。
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
| Control (UI = 0x03) |
+---------------------------+
| Pad (when required) (0x00)|
+---------------------------+
| NLPID |
+---------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+---------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
* 現在定義されている Q.922 アドレスは 2 オクテットであり、
10 ビットの DLCI を含む。あるネットワークでは、Q.922 アド
レスを任意で 3 オクテットか 4 オクテットに増やしてもよい。
control フィールドは Q.922 control フィールドである。もし他の値に折衝されなければ、UI (0x03) 値が使用される。XID (0xAF か 0xBF) を使用することは許されており、これについては後述する。
pad フィールドは、(カプセル化したヘッダを超えて) フレームのデータ位置を、2 オクテット境界に調整するために使用される。もし存在するならば、pad は 1 オクテットであり、0 の値でなければならない。pad フィールドの使用についての明確な説明は、このドキュメントの後半で論じられる。
ネットワークレベルプロトコル ID (NLPID)フィールドは、ISO と ITU によって管理される。これは、IP, CLNP, IEEE サブネットワークアクセスプロトコル (SNAP)[10] を含む、数多くの異なるプロトコルのための値を含む。このフィールドは、何がカプセル化されているか、あるいは何のプロトコルが続いているかを受信側に通知する。このフィールドの値は ISO/IEC TR 9577 [3] で定義されている。0x00 の NLPID 値は、ISO/IEC TR 9577 ではヌルネットワーク層、あるいは非活性セットとして定義されている。これは pad フィールドと区別がつかず、このカプセル化スキームの文脈では意味を持たないので、0x00 の NLPID 値はフレームリレーのカプセル化においては不正である。付録 A はより一般的に使用される NLPID 値を含む。
フレームリレーでは、共通的に実装されるフレーム長の最小、最大は存在しない。しかし、ネットワークは少なくとも最大 262 オクテットをサポートしなければならない。通常、最大は 1600 オクテット以上であるが、各フリームリレー提供者はそのネットワークに適した値を規定するだろう。従って、フレームリレー DTE は、受信可能な最大フレーム長を設定可能にしなければならない。
フレームリレーで許された最小フレーム長は、2 オクテットの Q.922 アドレスフィールドを採用した場合、開始/終了フラグの間に 5 オクテットである。この最小長は、3 オクテットの Q.922 アドレスでは 6 オクテットに増え、4 オクテットの Q.922 アドレス形式では 7 オクテットに増える。
フレームリレーネットワーク内を通過するデータパケットには、二つの基本的なタイプが存在する。それは、routed パケットと bridged パケットである。これらのパケットは別々の形式を持つので、宛先がフレームの内容を正しく解析するのに使用してよい指示子を含まなければならない。この指示子は NLPID と SNAP ヘッダ情報の中に埋めこまれる
既に割り当てられた NLPID を持たないプロトコルでは、簡単なプロトコルの識別を可能にするメカニズムを提供する必要がある。SNAP ヘッダの存在を示すために定義された NLPID 値がある。
その形式の SNAP ヘッダ:
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
3 オクテットの Organizationally Unique Identifier (OUI) は、後に続く Protocol Identifier (PID) の意味を管理する組織を識別する。さらに、それらは別個のプロトコルを識別する。OUI 0x00-00-00 は、後に続く PID がイーサタイプであることを示すことに注意されたい。
幾つかのプロトコルは割り当てられた NLPID を持っているが、NLPID の番号空間は限られており、全てのプロトコルが自身に割り当てられた特定の NLPID 値を持つとは限らない。そのようなプロトコルのパケットがフレームリレーネットワーク上に振り分けられる時、それらは、SNAP が後ろに続く NLPID 0x80 (これは SNAP ヘッダの存在を示す) を使用して送信される。もしプロトコルが割り当てられたイーサタイプを持つならば、その OUI は 0x00-00-00 (これはイーサタイプが後ろに続くことを示す) であり、PID は使用されるプロトコルのイーサタイプである。
SNAP ヘッダが上記で説明されているように存在する場合、以下に示すようにプロトコルデータを 2 オクテット境界に調整するために、1 オクテットの pad が使用される。
SNAP ヘッダを持つ routed フレーム の形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | Organization- |
+---------------+ |
| ally Unique Identifier (OUI) |
+-------------------------------+
| Protocol Identifier (PID) |
+-------------------------------+
| |
| Protocol Data |
| |
+-------------------------------+
| FCS |
+-------------------------------+
幾つかのケースでは、あるプロトコルが割り当てられた NLPID (付録 A 参照) を持つ場合、以下の形式を使用して 48 ビット節約することができる。
routed NLPID プロトコルの形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
上述の NLPID カプセル化形式を使用する場合、pad オクテットは使用しない。
ISO プロトコルの場合、NLPID はプロトコルデータの第一番目のオクテットであると見なされる。この場合、NLPID を繰り返す必要はない。一つのオクテットが、デマルチプレクス値とプロトコルデータの一部の両方で使用される (詳細は、フレームリレー上の他のプロトコルを参照)。その他のプロトコル、例えば IP、は定義された NLPID (0xCC) を持つが、それ自身はプロトコルの一部分ではない。
routed IP データグラムの形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0xCC |
+---------------+---------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+
フレームリレートラフィックの二つ目のタイプは、bridged パケットである。これらのパケットは、SNAP を示す 0x80 の NLPID 値を使用してカプセル化される。他の SNAP カプセル化プロトコルと同様に、カプセル化されたフレームのデータ部を調整するために、1 つの pad オクテットが付けられる。NLPID が後に続く SNAP ヘッダは、bridged パケットの形式を識別する。このカプセル化で使用される OUI 値は 802.1 組織コードの 0x00-80-C2 である。SNAP ヘッダ (OUI 直後の 2 バイト) の PID 部は、SNAP ヘッダの直後にくる MAC ヘッダの形式を指定する。加えて、PID は元の FCS が bridged フレームの中で保持されているか否かを示す。
前の RFC1638 [4] に従って、正規ではない MAC 宛先アドレスは、カプセル化された IEEE 802.5 と FDDI フレームで使用され、正規の MAC 宛先アドレスは、このセクションで定義された残りのカプセル化で使用される
802.1 組織はフレームリレーで使用するための以下の値を予約した。
PID Values for OUI 0x00-80-C2
保持された FCS 付き 保持された FCS 無し 媒体
------------------ ----------------- ----------------
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
加えて、PID 値 0x00-0E は OUI 0x00-80-C2 と共に使用した場合、802.1(d) か 802.1(g) [12] で定義されているように、ブリッジプロトコルデータ単位 (BPDUs: Bridge Protocol Data Units) を識別し、PID 値 0x00-0F は送信元ルーティング BPDU を識別する。
従って、フレームリレー上の bridged パケットは以下の形式の一つを持つ。
Bridged Ethernet/802.3 フレーム形式
+-------------------------------+
| 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 |
+-------------------------------+
Bridged 802.4 フレーム形式
+-------------------------------+
| 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 |
+-------------------------------+
Bridged 802.5 フレーム形式
+-------------------------------+
| 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 |
+-------------------------------+
Bridged FDDI フレーム形式
+-------------------------------+
| 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 |
+-------------------------------+
Bridged 802.6 フレーム形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ -------
| Reserved | BEtag | 共通
+---------------+---------------+ PDU
| BAsize | ヘッダ
+-------------------------------+ -------
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+
bridge 802.6 PDU では、CRC-32 が存在するか否かは MAC フレームのヘッダの CIB ビットによって示されるので、PID 値として一つの選択肢しかないことに注意されたい。
802.6 サブネットワークへの出口ブリッジでのパイプラインを可能にするために、共通プロトコルデータ単位 (CPDU: Common Protocol Data Unit) ヘッダとトレイラが運ばれる。特に CPDU ヘッダは PDU の長さを含む BAsize フィールドを含む。もしこのフィールドが、出口の 802.6 ブリッジで利用可能でなければ、そのブリッジは PDU 全体を受信し、その長さを計算し、BAsize フィールドに長さを挿入するまで、セグメント化された PDU の送信を始めることができない。もしそのフィールドが利用できるならば、出口の 802.6 ブリッジは共通 PDU ヘッダの長さを共通 PDU ヘッダの BAsize フィールドから抽出し、一番最初のセグメントの対応するフィールドにそれを挿入し、そのセグメントを 802.6 サブネットワーク上に即座に送信することができる。従って、ブリッジは完全な PDU を受信する前に、802.6 PDU の送信を開始することができる。
カプセル化されたフレームの共通 PDU ヘッダとトレイラは、出力する 802.6 サブネットワークに単にコピーすべてきではないことを一つ注記しておかねばならない。なぜなら、カプセル化された BEtag の値は、そのブリッジによって送信された以前の BEtag の値と衝突するかもしれないからである。
BPDU フレームの形式
+-------------------------------+
| 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 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0F |
+-------------------------------+
| |
| Source Routing BPDU |
| |
| |
+-------------------------------+
| FCS |
+-------------------------------+
フレームリレー局は、Q.922 [1] の付録 III で規定されている身分証明の交換 (XID: Exchange Identification) を選択してもよい。この XID 交換により、フレームリレー回線の初期化時に次のパラメタの折衝を可能にする。フレーム長 N201、再送タイマ T200、出力情報 (I) フレームの最大個数 K。
局は、最大ウインドウサイズ K に 0 の値を指定することによって、肯定モード複数フレーム処理のサポートに対して同意しないことを示してもよい。
もしこの交換を使用しなければ、これらの値はデータリンクコネクション (DLC) 終端局の相互の同意によって静的に設定してもよい。さもなくば、Q.922 のセクション 5.2 で規定されたデフォルト値にしなければならない。
N201: 260 octets
K: 16Kbps 回線では 3
64Kbps 回線では 7
384Kbps 回線では 32
1.536 Mbps以上の回線では 40
T200: 1.5 秒 [詳細は Q.922 参照]
XID をサポートしている局が XID フレームをサポートしているならば、その局は XID 応答で応答すべきである。XID の処理時に、もしリモートの最大フレーム長がローカルの最大よりも小さいならば、ローカルシステムはこの DLC 上で使用する最大長を、リモート側で指定された値に減らすべきである。これは XID 応答を生成する前に行うべきであることに注意されたい。
以下の図は、肯定モード複数フレーム処理の未使用を指定するために使用する XID を示す。
肯定モード複数フレーム処理の未使用
+---------------+
| 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)
| |
+---------------+
このドキュメントは、PVC 適用時のアドレス解決のみについて記述している。SVC 処理は、将来のドキュメントで論じられるだろう。
フレームリレー局が PVC 上のプロトコルアドレスを動的に解決したい状況がある。これは、以下のように SNAP で符号化されたフレームリレーパケットの中にカプセル化された、標準のアドレス解決プロトコル (ARP) [6] を使用して実現してもよい。
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | ARP を示す
+-----------------------+ OUI 0x00-00-00 + SNAP ヘッダ
| |
+-----------------------+-----------------------+
| PID 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
この場合、ARP パケットは以下の形式と値を持つ。
Data: ar$hrd 16 bits ハードウェアタイプ ar$pro 16 bits プロトコルタイプ ar$hln 8 bits ハードウェアアドレス (n) のオクテット長 ar$pln 8 bits プロトコルアドレス (m) のオクテット長 ar$op 16 bits 処理コード (要求か応答) ar$sha noctets 送信元ハードウェアアドレス ar$spa moctets 送信元プロトコルアドレス ar$tha noctets ターゲットハードウェアアドレス ar$tpa moctets ターゲットプロトコルアドレス
ar$hrd - フレームリレーに割り当てられているのは 10 進で 15 (0x000F) [7]。
ar$pro - ARP を使用するプロトコルのプロトコル ID 番号についての割り当て番号を参照されたい。(IP は 0x0800)
ar$hln - アドレスフィールドのバイト単位の長さ (2 か 3 か 4)
ar$pln - プロトコルアドレス長はプロトコル (ar$pro) による。(IP ar$pln の場合は 4)
ar$op - 要求は 1 で、応答は 2。
ar$sha - Q.922 送信元ハードウェアアドレス。C/R, FECN, BECN, DE の場合は 0 を設定する。
ar$tha - Q.922 ターゲットハードウェアアドレス。C/R, FECN, BECN, DE の場合は 0 を設定する。
大半のフレームリレーネットワーク中の DLCI はローカルの意味しか持たないので、終端局は自分自身に割り当てられた特定の DLCI を持たないだろう。従って、そのような局は ARP 要求や応答に指定するアドレスを持たない。幸いにも、フレームリレーネットワークは正しい DLCI を取得するための方法を提供していない。ローカルに宛てられたフレームリレーネットワークに対して提案されている解決方法は、DLCI がグローバルな意味を持つようなネットワークで、同様にうまく動作するだろう。
フレームリレーヘッダの中で運ばれる DLCI は、ネットワークを通り抜ける時に修正される。パケットが宛先に到着した時に、DLCI は受信局から見て送信局に対応する値に設定される。例えば以下の図 1 で、もし局 A が局 B にメッセージを送信するならば、フレームリレーヘッダに DLCI 50 を指定する。しかし、局 B がこのメッセージを受信する時は、DLCI はネットワークによって修正され、B には DLCI 70 として現れるだろう。
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---フレームリレー
~~~~~~~~~~~~~~~~ ネットワーク
80
|
+-----+
| |
| C |
| |
+-----+
図 1
局間の線はデータリンクコネクション (DLC) を表している。数字は、各コネクションに割り当てられたローカルの DLCI を示している。
図 1 の DLCI と Q.922 アドレステーブル
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401
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|
+--------------+----+----+---+--+
ARP とその変形では、FECN, BECN, C/R, DE ビットが 0 だと仮定する。
ARP メッセージが宛先に到達した時、ハードウェアアドレスは全て不正である。しかし、そのフレームヘッダにあるアドレスは正しいだろう。これは階層化の純粋性に反しているが、フレームリレーはヘッダ中のアドレスを送信側ハードウェアアドレスとして使用してもよい。ARP 要求と応答の両方において、ターゲットハードウェアアドレスが不正あることも注意すべきである。ARP はこれらのフィールドに頼らないので、これを問題としてはならない。実際、実装体は、ターゲットハードウェアアドレスを 0 で埋めてもよいし、完全に無視してもよい。
このアドレス変換スキームがどのように動作するかの例として、図 1 を参照されたい。もし局 A (プロトコルアドレス pA) が、局 B (プロトコルアドレス pB) のアドレスを解決したければ、以下の値を持った ARP 要求を作成する。
A からの ARP 要求
ar$op 1 (要求)
ar$sha unknown
ar$spa pA
ar$tha undefined
ar$tpa pB
局 A は自分に割り当てられた送信元アドレスを持っていないので、送信元ハードウェアアドレスフィールドが正しくない。従って、ARP パケットを受信した時、フレームリレーヘッダから正しいアドレスを取り出して、それを送信元ハードウェアアドレスフィールドに指定しなければならない。これにより A からの ARP 要求は、以下のようになる。
B によって修正された A からの ARP 要求
ar$op 1 (要求)
ar$sha 0x1061 (DLCI 70) フレームリレーヘッダより
ar$spa pA
ar$tha undefined
ar$tpa pB
そして、局 B の ARP は局 A のプロトコルアドレスと Q.922 アドレスの結び付きを保管することができる。次に、局 B は応答メッセージを作成する。多くの実装体は、ターゲットアドレスに単に ARP 要求からの送信元アドレスを設定し、送信元アドレスには自分のアドレスを指定するだろう。この場合、ARP 応答は以下のようになる。
B からの ARP 応答
ar$op 2 (応答)
ar$sha unknown
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
送信元ハードウェアアドレスはまた未知であり、応答を受信した時、局 A はフレームリレーヘッダからアドレスを取り出し、それを送信元ハードウェアアドレスフィールドに設定する。従って、応答は以下のようになる。
A によって修正された B からの ARP 応答
ar$op 2 (応答)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
局 A は今、Q.922 アドレス 0x0C21 (DLCI 50) に結び付いたプロトコルアドレス pB を持つ局 B を正しく認識している。
逆 ARP (RARP) [8] は、全く同じように動作する。また図 1 を使用するが、もし局 C がアドレスサーバであると仮定すると、以下の RARP の交換が発生する。
A からの RARP 要求 C によって修正される RARP 要求
ar$op 3 (RARP 要求) ar$op 3 (RARP 要求)
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
そして局 C は Q.922 アドレス 0x1401 (DLCI 80) に対応するプロトコルアドレスを調べて、RARP 応答を送信する。
C からの RARP 応答 A によって修正される RARP 応答
ar$op 4 (RARP 応答) ar$op 4 (RARP 応答)
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
これは、フレームリレーインタフェースは、入力パケットの処理時に仲介のみしなければらないことを意味する
適当なマルチキャストが無くても、ARP を実装してもよい。これを実現するためには、終端局は単に各々の関連する DLC に ARP 要求のコピーを送信すればよい。それによって、ブロードキャストを真似ることができる。
フレームリレー環境におけるマルチキャストアドレスの使用は、[19] で示されているように、フレームリレー提供者によって現在検討中である。そのうち、マルチキャストのアドレス付けが、ARP 要求や他の "ブロードキャスト" メッセージの送信時に有効になるかもしれない。
フレームリレー環境では擬似ブロードキャストは非効率的であるため、新たなアドレス解決が開発された。それは Inverse ARP [11] と呼ばれ、ハードウェアアドレスを既に知っている時に、プロトコルアドレスを解決するための方法について規定している。フレームリレーの場合、既知のハードウェアアドスとは DLCI である。Inverse ARP のサポートは、この規約を実装するための必須要件ではないが、フレームリレーインタフェースの自動設定では効果的であることが確認されている。その規定とフレームリレーで使用する例については [11] を参照されたい。
局は、同じ IP サブネット (CIDR アドレスプレフィクス) 内の 1 つ以上の IP アドレスを、フレームリレーインタフェース上のある特定の DLCI にマッピングできなければならない。この要件は、例えばリモートアクセスのようなアプリケーションから上がっている。この場合、サーバは多数のダイアルインクライアントのために ARP プロクシとして動作しなければならず、同じ DLC 上で帯域を共有しているが、各々ユニークな IP アドレスを割り当てられている。そのようなアプリケーションの動的な性質は、フレームリレー PVC 状態信号によって通知される時、DLC の状態に影響せずに頻繁なアドレス組み合わせの変更を結果として引き起こす。
ARP を利用する他のインタフェースのように、局は DLC 上に到着する求められていない ("無償の") ARP 要求を処理することによって、IP アドレスと DLCI の組み合わせを知ってもよい。もし一方の局が (恐らくターミナルサーバかリモートアクセスサーバ)、フリームリレー DLC の他方の終端にいる相手局に、IP アドレスとその PVC の新しい組み合わせを通知することを望むならば、送信元 IP アドレスが宛先 IP アドレスと等しく、両方とも DLC 上で使用しようとしている新しい IP アドレスを設定した、求められていない ARP 要求を送信すべきである。これにより、局がある特定の DLCI 上の新しいクライアントコネクションを "アナウンスする" ことが可能になる。受信側の局は新しい組み合わせを格納し、必要ならばそのインタフェース上の他の全ての DLCI から、古い既存のコネクションを全て削除しなければならない。
フレームリレーネットワーク上に送信されるインターネットプロトコル [9] (IP) データグラムは、前に規定されているカプセル化に従う。このコンテキストの範囲内では、IP は異なる二つの方法でカプセル化することができる。
1. IP を示す NLPID 値
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
2. SNAP を示す NLPID 値
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP ヘッダは
+-----------------------+ OUI = 0x00-00-00 + IP を示す
| |
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
これらの両方のカプセル化は所定の定義下でサポートされているが、IP データのカプセル化のために適切なメカニズムとして、一方の方法だけを選択する方が都合がよい。従って、IP データは上記の選択肢 1 で図示されているように、IP を示す 0xCC の NLPID 値を使用してカプセル化すべきである。これ (選択肢 1) の方が転送時に効率的であり (48 ビット少ない)、X.25 での IP のカプセル化と一致している。
IP カプセル化に関して、この定義の範囲内で様々なプロトコルを送信するための別の方法がある。矛盾をなくすために、あるプロトコルにおいてもし NLPID 値が定義されていなければ、SNAP カプセル化しか使わない。
これがどのように動作するかについての例として、ISO CLNP は定義された NLPID (0x81) を持っている。従って、NLPID フィールドは ISO CLNP を示し、データパケットがその直後に続く。そのフレームは以下のようになる。
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+
この例では、NLPID はデータパケットが CLNP であると識別するために使用される。それは CLNP パケットの一部としても見なされ、NLPID は処理するために上位層に送信する前に削除すべきではない。NLPID は重複しない。
例えば IPX のような他のプロトコルは、定義された NLPID 値を持たない。上記で言及されているように、IPX は SNAP ヘッダを使用してカプセル化される。この場合、フレームは以下のようになる。
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+
フレームリレーネットワークにおけるブリッジングのモデルは、IEEE P802.1g "Remote MAC Bridging" [13] で規定されているリモートブリッジングのモデルと同じであり、"仮想ポート" の概念をサポートする。LAN ポートを持つリモートブリッジは、それが接続されている LAN へ/から MAC フレームを送信/受信する。リモートブリッジは他のリモートブリッジへ/から、仮想ポートを通じて MAC フレームを送信/受信してもよい。仮想ポートは、リモートブリッジの一つ以上の他のリモートブリッジへのアクセス点の抽象的概念を表わすかもしれない。
リモートブリッジは、管理者によってリモートブリッジグループのメンバとして静的に設定される。リモートブリッジグループの全メンバは、一つ以上の仮想ポートによって接続される。リモートブリッジグループ中のリモート MAC ブリッジのセットは、一セットの LAN とリモートブリッジが所属してる他のリモートブリッジグループとの間の、実際の、あるいは *潜在的な* MAC 層の相互接続を提供する。
フレームリレーネットワークでは、リモートブリッジグループのブリッジの間で、フレームリレー VC の完全なメッシュ構造でなければならない。もしフレームリレー VC が完全なメッシュ構造でなければ、ブリッジネットワークは複数のリモートブリッジグループに分けなければならない。
リモートブリッジグループのブリッジを相互接続するフレームリレー VC は結合してもよいし、あるいは一つ以上の仮想ブリッジポートを形成するために個別に使用してもよい。これにより、フレームリレーインタフェースを一つのグループの中に全ての VC を持つ単一の仮想ブリッジポートとして扱うか、ブリッジポートの集まり (個々、あるいはグループ化された VC) として扱うかの柔軟性を与える。
単一の仮想ブリッジポートが、あるリモートブリッジグループの全てのブリッジにおける相互接続性を与える時 (すなわち全ての VC が単一の仮想ポートに結合される)、仮想ポートの状態を決定するために、標準的なスパニングツリーアルゴリズムを使用してもよい。一つ以上の仮想ポートがあるリモートブリッジグループの中で構成されるとき、"拡張された" スパニングツリーアルゴリズムが必要である。そのような拡張されたアルゴリズムは、IEEE 802.1g [13] で定義されている。このアルゴリズムの処理は、もしリモートブリッジグループの外側のネットワークにループがあるなば、仮想ポートがバックアップに置かれるだけのものである。
フレームリレーネットワークにおいて最も簡単なブリッジ構成は、全ての VC が一つの仮想ポートに結合される、LAN の観点である。BPDU 等のフレームは LAN 上にブロードキャスト (あるいは、もしフレームリレーサービスで開発されればマルチキャスト) され、各々の VC に氾濫するに違いない。洪水は、フレームリレーインタフェースに割り当てられた各々の関連 DLC に、パケットを送信することによって発生する。この環境における VC は、通常ブリッジには見えない。すなわち、ブリッジは大量のフレームをフレームリレーインタフェースに送信し、そのフレームが各々の VC に転送されていることが "見えない"。もし参加している全てのブリッジが全て接続されていれば (完全メッシュ構成)、標準的なスパニングツリーアルゴリズムは、この構成で十分だろう。
一般的に LAN ブリッジは、ブリッジポートに割り当てられている MAC アドレスによって、特定の終端局がどのインタフェースに到達するかもしれないかを知っている。しかし、LAN に似た単一ブリッジポート (あるいは、単一のブリッジポートを形成するために共にグループ化された VC) で構成されたフレームリレーネットワークでは、ブリッジはブリッジポートに MAC アドレスを割り当てるだけではなく、コネクション識別子も割り当てなければならない。フレームリレーネットワークでは、このコネクション識別子とは DLCI である。あり得る全てのあて先 MAC アドレスと DLC との結び付きを、ブリッジが静的に設定する必要があるとしたら、それは効率的でないし恐らく不可能だろう。従って、フレームリレー LAN モデルのブリッジは、フレームリレーブリッジポートが動的にそれらの結び付きを知ることができるメカニズムを提供しなければならない。この動的認識を実現するために、ブリッジされるパケットはセクション 4.2 で規定したカプセル化に準拠すべきである。この方法で、受信側のフレームリレーインタフェースは、ブリッジパケットを調べて適切な情報を収集する方法が分かるだろう。
二つ目のフレームリレーブリッジングのアプローチはポイントツーポイントの観点であり、各々のフレームリレー VC を別々のブリッジポートとして取り扱う。パケットの大量送出と転送は、ポイントツーポイントのアプローチを使用すれば複雑さがかなり減る。なぜなら、各ブリッジポートは一つの宛先しか持たないからである。意図的に大量送出したり、DLCI を宛先 MAC アドレスに結び付ける必要はない。VC の相互接続とは関係無く、リモートブリッジグループの外部のトポロジに本当のループが無い限りにおいて、全ての仮想ポートを活性化したままに留めるために、拡張されたスパニングツリーアルゴリズムが必要とされるかもしれない。
単一のフレームリレーインタフェース上で、LAN の観点とポイントツーポイントの観点を合わせることも可能である。これを行うために、他の VC がブリッジポートと独立している一方で、ある VC が単一の仮想ブリッジポートを形成して結合される。
以下の図は、別の可能なブリッジング構成を示している。ボックスの間のダッシュ付き行は、仮想回線を表している。
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
この例では、ブリッジ間の VC の完全メッシュ構成よりも少ないので、ネットワークは一つ以上のリモートブリッジグループに分けなければならない。効率的な構成は、ブリッジ A, B, C を一つのグループに持ち、ブリッジ A, D を二つ目のグループに持つことである。
一番目のブリッジグループの構成は、三つのブリッジ (A, B, C) の VC の相互接続を一つの仮想ポートに結合している。これは LAN の観点の構成例である。二番目のグループもまた、A と D のブリッジを単に接続する一つの仮想ポートである。この構成では、ループを検出するために標準的なスパニングツリーアルゴリズムで十分である。
別の構成は、ブリッジ A, B, C 間の VC 相互接続に対応する一番目のグループで、三つの個々の仮想ポートを持つ。標準的なスパニングツリーアルゴリズムのアプリケーションをこの構成に適用すると、トポロジ内のループを検出するので、全ての仮想ポートを活性状態に保つために、拡張されたスパニングツリーアルゴリズムを使用しなければならない。二番目のグループは依然として一つの仮想ポートで構成され、このグループでは標準的なスパニングツリーアルゴリズムを使用できることに注意されたい。
同じ図を使用すると、あるものは 3 つのブリッジグループでリモートブリッジのシナリオを描くことができる。これはポイントツーポイントの場合の例になるだろう。この場合、A と B を接続する VC、A と C を接続する VC、A と D を接続する VC は全て、一つの仮想ポートを持ったブリッジグループである。
このドキュメントは、フレームリレー上でデータグラムの複数プロトコルのカプセル化を識別するためのメカニズムを定義している。如何なるカプセル化プロトコルにも信用する要素が明らかにあり、受信側は、送信側が正しくカプセル化されているプロトコルを識別しているものと信用しなければならない。通常、送信側が適切なプロトコル識別子を実際に使用したかを受信側が確かめる方法は無いし、機能性としても望ましくない。
フレームリレーで ARP と RARP を使用することもまた規定しており、ARP や似たようなアドレス解決プロトコルに影響を及ぼすセキュリティ制約を受ける。認証は ARP の一部ではないので、その使用に関して既知のセキュリティ問題がある (例えばホストのなりすまし)。フレームリレーネットワークで使用するのに、特別なセキュリティメカニズムを ARP や RARP に追加してはいない。
共通的に使用される NLPID の一覧
0x00 ヌルネットワーク層か非活性のセット (フレームリレーでは使用されない) 0x08 Q.933 [2] 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0x8E IPv6 0xB0 FRF.9 データ圧縮 [14] 0xB1 FRF.12 フラグメンテーション [18] 0xCC IPv4 0xCF フレームリレーでの PPP [17]
OUI 00-80-C2 の PID の一覧
保持された FCS 付き 保持された FCS 無し 媒体
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/イーサネット
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D フラグメント
0x00-0E 802.1(d) か 802.1(g)[12]
で定義されている BPDU
0x00-0F 送信元ルーティング BPDU
この付録は、ITU 勧告 Q.933 [2] や、フレームリレー上でデータをカプセル化するための他の ITU 標準を使用するための追加情報や規定を含んでいる。ここに含まれている情報は、ITU Q.933 Annex E にあるものと似ている (幾つかは同じである)。この情報に関する正式な出所は Annex E であり、便宜上のためだけにここで繰り返している。
ネットワーク層プロトコル ID (NLPID) フィールドは、ISO と ITU によって管理されている。それは、IP, CLNP (ISO 8473), ITU Q.933, ISO 8208 を含む、数多くのプロトコルのための値を含んでいる。フレームリレーネットワーク上の一般的なカプセル化技術を要約している図は以下の通り。以下のいずれかで使用される異なるプロトコルを識別するために、フレームリレーネットワーク上に複数の選択肢があるので、このスキームには柔軟性がある。
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
割り当てられた NLPID を持たないか SNAP のカプセル化を持たないプロトコル、0x08 の NLPID 値については、ITU 勧告 Q.933 を使用すべきであることを示す。NLPID の後ろに続く 4 オクテットは、レイヤ 2 とレイヤ 3 の両方のプロトコルの識別を含んでいる。大半のプロトコルを指すコードは、現在 ITU Q.933 下位層互換情報要素で定義されている。"ユーザ特定" を指すコードは、フレームリレーフォーラム FRF.3.1 [15] で規定されている。非標準プロトコルを定義するための逃げ路も存在する。
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 |
+-------------------------------+
ユーザ特定のレイヤ 3 を持つ ISO 8802/2
+-------------------------------+
| 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 |
+-------------------------------+
Note 1: ユーザ特定のレイヤ 3 プロトコルを指すコードを示す。
Note 2: Control フィールドは、I 形式と S 形式のフレーム (88002/2) の 2 オクテットである
I フレーム (レイヤ 2) を使用したカプセル化
Q.922 I フレームは、肯定応答型データリンク層 (例えば ISO 8208) を必要とするレイヤ 3
プロトコルをサポートするためのものである。C/R ビットは、コマンドと応答を示すために使用される。
ISO 8208 フレームモジュロ 8 の形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 8) Note 3 |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Note 3: 8208 パケットの第一オクテットも "..01...." の NLPID を識別する。
ISO 8208 フレームモジュロ 128 の形式
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 128) |
| Note 4 |
+-------------------------------+
| FCS |
+-------------------------------+
Note 3: 8208 パケットの第一オクテットも "..10...." の NLPID を識別する。
RFC1490 は広く実装され使用されており、フレームリレーフォーラム FRF.3.1 [15] や ITU Q.933 [2] に採用されている。このセクションは、この実装や相互運用の経験の結果として作成された RFC1490 の改訂事項について説明しており、それらは現在の実装作業に反映されている。
RFC1490 を明確化するために、幾つかの言葉の変更が必要であった。これらの変更は、どれもこのドキュメントの技術的な面には影響を与えないが、図と言葉は明確で一貫性を保つよう求められていた。これらの変更の細部は、ここでは一覧化しない。以下は、主な変更点の一覧である。
[1] International Telecommunication Union, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU-T Recommendation 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.
[3] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.
[4] Baker, F., and R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC 1638, June 1994.
[5] International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE, Second Edition, 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.
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: 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.
[9] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, February 1988.
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture", IEEE Standard 802-1990.
[11] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media Access Control (MAC) Bridging, March 12, 1997.
[14] Frame Relay Forum, "Data Compression Over Frame Relay Implementation Agreement", FRF.9, January 22, 1996.
[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation Agreement", FRF.3.1, June 22, 1995.
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[17] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997.
[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and Protocol Implementation Agreement", FRF.7, October 21, 1994.
Caralyn Brown Consultant EMail: cbrown@juno.com Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 Phone: (978) 952-7414 EMail: malis@ascend.com
Copyright (C) The Internet Society (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.
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.