RFC1390 日本語訳
1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January 1993. (Format: TXT=22077 bytes) (Also STD0036) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Katz Request for Comments: 1390 cisco Systems, Inc. STD: 36 January 1993
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 1390年のコクチマスSystems Inc.STD: 1993年1月36日
Transmission of IP and ARP over FDDI Networks
FDDIネットワークの上のIPとARPのトランスミッション
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks.
このメモはファイバ分散データインタフェース(FDDI)ネットワークでインターネットプロトコル(IP)データグラムとAddress Resolutionプロトコル(ARP)が要求と回答であるとカプセル化するメソッドを定義します。
This RFC is the product of the IP over FDDI Working Group of the Internet Engineering Task Force (IETF).
このRFCはFDDIインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の上のIPの製品です。
Acknowledgments
承認
This memo draws heavily in both concept and text from RFC 1042 [3], written by Jon Postel and Joyce K. Reynolds of USC/Information Sciences Institute. The author would also like to acknowledge the contributions of the IP Over FDDI Working Group of the IETF, members of ANSI ASC X3T9.5, and others in the FDDI community.
このメモは概念とテキストの両方でUSC/情報Sciences Instituteのジョン・ポステルとジョイス・K.レイノルズによって書かれたRFC1042[3]から大いに作成されます。 また、作者はIETF、ANSI ASC X3T9.5のメンバー、およびFDDI共同体の他のもののIP Over FDDI作業部会の貢献を承諾したがっています。
Conventions
コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
"Must," "Shall," or "Mandatory"--the item is an absolute
requirement of the specification.
「必須」、「」 「義務的」--項目は仕様に関する絶対条件になるでしょう。
"Should" or "Recommended"--the item should generally be followed
for all but exceptional circumstances.
"Should"か「推薦されました」--一般に、商品はほとんど例外的な事情のために従われるべきです。
"May" or "Optional"--the item is truly optional and may be
followed or ignored according to the needs of the implementor.
「5月」か「任意」--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
Katz [Page 1] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[1ページ]RFC1390IP
Introduction
序論
The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams [1] and ARP requests and replies [2].
この仕様の目標はIPデータグラム[1]、ARP要求、および回答[2]を送るためのコンパチブル、そして、共同利用できる実装を許容することです。
The Fiber Distributed Data Interface (FDDI) specifications define a family of standards for Local Area Networks (LANs) that provides the Physical Layer and Media Access Control Sublayer of the Data Link Layer as defined by the ISO Open System Interconnection Reference Model (ISO/OSI). Documents are in various stages of progression toward International Standardization for Media Access Control (MAC) [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium Dependent (PMD) [6], and Station Management (SMT) [7]. The family of FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9, 10].
ファイバ分散データインタフェース(FDDI)仕様はISOオープンSystem Interconnection Reference Model(ISO/OSI)によって定義されるようにData Link LayerのPhysical LayerとメディアAccess Control Sublayerを提供するローカル・エリア・ネットワーク(LAN)の規格のファミリーを定義します。 ドキュメントは様々なステージの進行でメディアAccess Control(MAC)[4]、Physical Layerプロトコル(PHY)[5]、Physical Layer Medium Dependent(PMD)[6]、および駅のManagement(SMT)[7]のための国際Standardizationに向かっています。 FDDI規格のファミリーはIEEE802MAC層の規格[8、9、10]に文通します。
The remainder of the Data Link Service is provided by the IEEE 802.2 Logical Link Control (LLC) service [11]. The resulting stack of services appears as follows:
IEEE802.2Logical Link Control(LLC)サービス[11]でData Link Serviceの残りを提供します。 結果として起こるサービスのスタックは以下の通りに見えます:
+-------------+
| IP/ARP |
+-------------+
| 802.2 LLC |
+-------------+-----+
| FDDI MAC | F |
+-------------+ D S |
| FDDI PHY | D M |
+-------------+ I T |
| FDDI PMD | |
+-------------+-----+
+-------------+ | IP/アルプ| +-------------+ | 802.2 LLC| +-------------+-----+ | FDDI Mac| F| +-------------+ D S| | FDDI PHY| D M| +-------------+ I T| | FDDI PMD| | +-------------+-----+
This memo describes the use of IP and ARP in this environment. At this time, it is not necessary that the use of IP and ARP be consistent between FDDI and IEEE 802 networks, but it is the intent of this memo not to preclude Data Link Layer interoperability at such time as the standards define it.
このメモはこの環境でIPとARPの使用について説明します。 このとき、IPとARPの使用がFDDIとIEEE802のネットワークの間で一貫しているのは必要ではありませんが、それは規格がそれを定義するときこのメモがそのような時にData Link Layer相互運用性を排除しない意図です。
It is the explicit intent of this memo to allow the interoperability of IP and ARP between stations on FDDI networks and stations on Ethernet networks via translational bridges.
翻訳ブリッジを通してFDDIネットワークのステーションとイーサネットネットワークのステーションの間にIPとARPの相互運用性を許容するのは、このメモの明白な意図です。
The FDDI standards define both single and dual MAC stations. This document describes the use of IP and ARP on single MAC stations (single-attach or dual-attach) only.
FDDI規格は単一のものと同様に二元的なMACステーションを定義します。 または、このドキュメントが単一のMACステーションのIPとARPの使用について説明する、(シングル付いてください、二元的である、-付いてください、)、単に。
Katz [Page 2] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[2ページ]RFC1390IP
Packet Format
パケット・フォーマット
IP datagrams and ARP requests and replies sent on FDDI networks shall be encapsulated within the 802.2 LLC and Sub-Network Access Protocol (SNAP) [12] data link layers and the FDDI MAC and physical layers. The SNAP must be used with an Organization Code indicating that the SNAP header contains the EtherType code (as listed in Assigned Numbers [13]).
IPデータグラム、ARP要求、および回答は、FDDIネットワークが802.2LLCとSub-ネットワークAccessプロトコル(SNAP)[12]データ・リンク層、FDDI MAC、および物理的な層の中でカプセル化されるのを転送しました。 SNAPヘッダーがEtherTypeコードを含むのを示すOrganization Codeと共にSNAPを使用しなければなりません。(Assigned民数記[13])で記載されているように。
802.2 LLC Type 1 communication (which must be implemented by all conforming 802.2 stations) is used exclusively. All frames must be transmitted in standard 802.2 LLC Type 1 Unnumbered Information format, with the DSAP and the SSAP fields of the 802.2 header set to the assigned global SAP value for SNAP [11]. The 24-bit Organization Code in the SNAP must be zero, and the remaining 16 bits are the EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054).
802.2 LLC Type1コミュニケーション(802.2のステーションを従わせながら、すべてで実装しなければならない)は排他的に使用されます。 標準の802.2LLC Type1Unnumbered情報形式ですべてのフレームを伝えなければなりません、802.2ヘッダーの分野がSNAP[11]のために割り当てられたグローバルなSAP値に設定するDSAPとSSAPと共に。 SNAPの24ビットのOrganization Codeはゼロであるに違いありません、そして、残っている16ビットはAssigned民数記[13](2048、IP=ARP=2054)からのEtherTypeです。
...--------+--------+--------+
MAC Header | FDDI MAC
...--------+--------+--------+
...--------+--------+--------+ MACヘッダー| FDDI Mac…--------+--------+--------+
+--------+--------+--------+
| DSAP=K1| SSAP=K1| Control| 802.2 LLC
+--------+--------+--------+
+--------+--------+--------+ | DSAP=K1| SSAP=K1| コントロール| 802.2 LLC+--------+--------+--------+
+--------+--------+---------+--------+--------+
|Protocol Id or Org Code =K2| EtherType | 802.2 SNAP
+--------+--------+---------+--------+--------+
+--------+--------+---------+--------+--------+ |プロトコルイドかOrgコードがケーツーと等しいです。| EtherType| 802.2 スナップ+--------+--------+---------+--------+--------+
The total length of the LLC Header and the SNAP header is 8
octets.
LLC HeaderとSNAPヘッダーの全長は8つの八重奏です。
The K1 value is 170 (decimal).
K1値は170(10進)です。
The K2 value is 0 (zero).
ケーツー値は0(ゼロ)です。
The control value is 3 (Unnumbered Information).
コントロール値は3(無数の情報)です。
Address Resolution
アドレス解決
The mapping of 32-bit Internet addresses to 48-bit FDDI addresses shall be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [2].
Address Resolutionプロトコル(ARP)[2]のダイナミックな発見手順で48ビットのFDDIアドレスへの32ビットのインターネット・アドレスに関するマッピングをするものとします。
Internet addresses are assigned arbitrarily on Internet networks. Each host's implementation must know its own Internet address and respond to Address Resolution requests appropriately. It must also
インターネット・アドレスはインターネット網で任意に割り当てられます。 各ホストの実装は、適切にそれ自身のインターネット・アドレスを知って、Address Resolution要求に応じなければなりません。 また、それはそうしなければなりません。
Katz [Page 3] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[3ページ]RFC1390IP
use ARP to translate Internet addresses to FDDI addresses when needed.
必要であるとARPを使用して、FDDIアドレスにインターネット・アドレスを翻訳してください。
The ARP protocol has several fields that parameterize its use in any specific context [2]. These fields are:
ARPプロトコルには、どんな特定の文脈[2]でも使用をparameterizeするいくつかの分野があります。 これらの分野は以下の通りです。
hrd 16 - bits The Hardware Type Code
pro 16 - bits The Protocol Type Code
hln 8 - bits Octets in each hardware address
pln 8 - bits Octets in each protocol address
op 16 - bits Operation Code
hrd16--ビットHardware Type Codeプロ16--各プロトコルのプロトコルType Code hln8--各ハードウェアのOctetsがpln8を扱うビット--ビットOctetsがオプアート16を扱うビット--ビットOperation Code
The hardware type code assigned for IEEE 802 networks is 6 [13]. The hardware type code assigned for Ethernet networks is 1 [13]. Unfortunately, differing values between Ethernet and IEEE 802 networks cause interoperability problems in bridged environments. In order to not preclude interoperability with Ethernets in a bridged environment, ARP packets shall be transmitted with a hardware type code of 1. ARP packets shall be accepted if received with a hardware type code of 1.
IEEE802ネットワークのために割り当てられたハードウェアタイプコードは6[13]です。 イーサネットネットワークのために割り当てられたハードウェアタイプコードは1[13]です。 残念ながら、イーサネットとIEEE802ネットワークの間の異なった値はブリッジしている環境における相互運用性問題を引き起こします。 ブリッジしている環境でEthernetsがある相互運用性を排除しないように、ARPパケットは1のハードウェアタイプコードで伝えられるものとします。 1のハードウェアタイプコードで受け取るなら、ARPパケットを受け入れるものとします。
The protocol type code for IP is 2048 [13].
IPのためのプロトコルタイプコードは2048[13]です。
The hardware address length is 6.
ハードウェア・アドレスの長さは6です。
The protocol address length (for IP) is 4.
プロトコルアドレスの長さ(IPのための)は4です。
The operation code is 1 for request and 2 for reply.
命令コードは、要求のための1と回答のための2です。
In order to not preclude interoperability in a bridged environment, the hardware addresses in ARP packets (ar$sha, ar$tha) must be carried in "canonical" bit order, with the Group bit positioned as the low order bit of the first octet. As FDDI addresses are normally expressed with the Group bit in the high order bit position, the addresses must be bit-reversed within each octet.
ブリッジしている環境における相互運用性を排除しないように、噛み付いている「正準な」オーダーでARPパケット(ar$sha、ar$tha)のハードウェア・アドレスを運ばなければなりません、Groupビットが最初の八重奏の下位のビットとして置かれている状態で。 通常、FDDIアドレスが高位ビット位置にGroupビットで表されるように、アドレスは各八重奏の中でビットで逆にしなければなりません。
Although outside the scope of this document, it is recommended that MAC addresses be represented in canonical order in all Network Layer protocols carried within the information field of an FDDI frame.
MACアドレスがFDDIフレームの情報フィールドの中で運ばれたすべてのNetwork Layerプロトコルにおける正準なオーダーに表されるのが、このドキュメントの範囲の外でお勧めですが。
Broadcast Address
放送演説
The broadcast Internet address (the address on that network with a host part of all binary ones) must be mapped to the broadcast FDDI address (of all binary ones) (see [14]).
放送インターネット・アドレス(すべての2進のもののホスト部分があるそのネットワークに関するアドレス)を放送FDDIアドレス(すべての2進のものの)に写像しなければなりません。([14])を見てください。
Katz [Page 4] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[4ページ]RFC1390IP
Multicast Support
マルチキャストサポート
A method of supporting IP multicasting is specified in [15]. This method shall be used in FDDI networks if IP multicasting is to be supported. The use of this method may require the ability to copy frames addressed to any one of an arbitrary number of multicast (group) addresses.
IPマルチキャスティングをサポートするメソッドは[15]で指定されます。 このメソッドはIPマルチキャスティングがサポートされることであるならFDDIネットワークに使用されるものとします。 このメソッドの使用はマルチキャスト(グループ)アドレスの特殊活字の数字のいずれにも扱われたフレームをコピーする能力を必要とするかもしれません。
An IP multicast address is mapped to an FDDI group address by placing the low order 23 bits of the IP address into the low order 23 bits of the FDDI group address 01-00-5E-00-00-00 (in "canonical" order). [See 13, page 29.]
IPマルチキャストアドレスは、IPの23ビットがFDDIグループの23ビットが01-00-5E00-00-00を扱う下位に扱う下位(「正準な」オーダーにおける)を置くことによって、FDDIグループアドレスに写像されます。 [13、29ページを参照してください。]
For example, the IP multicast address:
例えば、IPマルチキャストアドレス:
224.255.0.2
224.255.0.2
maps to the FDDI group address:
FDDIへの地図はアドレスを分類します:
01-00-5E-7F-00-02
01-00-5 E-7F-00-02
in which the multicast (group) bit is the low order bit of the first octet (canonical order). When bit-reversed for transmission in the destination MAC address field of an FDDI frame (native order), it becomes:
マルチキャスト(グループ)ビットは最初の八重奏(正準なオーダー)の下位のビットです。 トランスミッションのためにビットで目的地で逆にされたMACがFDDIフレーム(固有のオーダー)の分野を扱うと、なります:
80-00-7A-FE-00-40
80-00-7 1FE-00-40です。
that is, with the multicast (group) bit as the high order bit of the first octet, that being the first bit transmitted on the medium.
すなわち、最初の八重奏の高位のビットとしてのマルチキャスト(グループ)ビットで、1番目が噛み付いたその存在は媒体の上を伝わりました。
Trailer Formats
トレーラ形式
Some versions of Unix 4.x bsd use a different encapsulation method in order to get better network performance with the VAX virtual memory architecture. Hosts directly connected to FDDI networks shall not use trailers.
Unix 4.x bsdのいくつかのバージョンが、VAX仮想記憶アーキテクチャによる、より良いネットワーク性能を得るのに異なったカプセル化メソッドを使用します。 直接FDDIネットワークに接続されたホストはトレーラを使用しないものとします。
Byte Order
バイトオーダー
As described in Appendix B of the Internet Protocol specification [1], the IP datagram is transmitted over FDDI networks as a series of 8-bit bytes. This byte transmission order has been called "big- endian" [16].
インターネットプロトコル仕様[1]のAppendix Bで説明されるように、IPデータグラムは一連の8ビットのバイトとしてFDDIネットワークの上に送られます。 このバイトトランスミッション命令は「大きいエンディアン」[16]と呼ばれました。
Katz [Page 5] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[5ページ]RFC1390IP
MAC Layer Details
MAC層の詳細
Packet Size
パケットサイズ
The FDDI MAC specification [4] defines a maximum frame size of
9000 symbols (4500 octets) for all frame fields, including four
symbols (two octets) of preamble. This leaves roughly 4470 octets
for data after the LLC/SNAP header is taken into account.
FDDI MAC仕様[4]はすべてのフレーム分野の9000のシンボル(4500の八重奏)の最大のフレーム・サイズを定義します、序文の4つのシンボル(2つの八重奏)を含んでいて。 LLC/SNAPヘッダーが考慮に入れられた後にこれはおよそ4470の八重奏をデータに残します。
However, in order to allow future extensions to the MAC header and
frame status fields, it is desirable to reserve additional space
for MAC overhead.
しかしながら、MACヘッダーとフレーム状態分野に今後の拡大を許すために、MACオーバーヘッドで追加スペースを予約するのは望ましいです。
Therefore, the MTU of FDDI networks shall be 4352 octets. This
provides for 4096 octets of data and 256 octets of headers at the
network layer and above. Implementations must not send packets
larger than the MTU.
したがって、FDDIネットワークのMTUは4352の八重奏になるでしょう。 これはネットワーク層において上でデータの4096の八重奏とヘッダーの256の八重奏に提供されます。 実装はMTUより大きいパケットを送ってはいけません。
Gateway implementations must be prepared to accept packets as
large as the MTU and fragment them when necessary. Gateway
implementations should be able to accept packets as large as can
be carried within a maximum size FDDI frame and fragment them.
パケットがMTUとして大きいと受け入れて、必要であるときにはそれらを断片化するようにゲートウェイ実装を準備しなければなりません。 ゲートウェイ実装は、パケットが極めて大きいと最大サイズFDDIフレームの中に運ばれた状態で受け入れて、それらを断片化できるべきです。
Host implementations should be prepared to accept packets as large
as the MTU; however, hosts must not send datagrams longer than 576
octets unless they have explicit knowledge that the destination is
prepared to accept them. Host implementations may accept packets
as large as can be carried within a maximum size FDDI frame. A
host may communicate its size preference in TCP-based applications
via the TCP Maximum Segment Size option [17].
ホスト導入はパケットがMTUとして大きいと受け入れるように準備されるべきです。 しかしながら、ホストはそれらに目的地が準備される形式知がないなら576の八重奏がそれらを受け入れるより長い間、データグラムを送ってはいけません。 ホスト導入は、パケットが極めて大きいと最大サイズFDDIフレームの中に運ばれた状態で受け入れるかもしれません。 ホストはTCP Maximum Segment Sizeオプション[17]でTCPベースのアプリケーションにおけるサイズ好みを伝えるかもしれません。
Datagrams on FDDI networks may be longer than the general Internet
default maximum packet size of 576 octets. Hosts connected to an
FDDI network should keep this in mind when sending datagrams to
hosts that are not on the same local network. It may be
appropriate to send smaller datagrams to avoid unnecessary
fragmentation at intermediate gateways. Please see [17] for
further information.
FDDIネットワークのデータグラムは576の八重奏の一般的なインターネットデフォルトより長い最大のパケットサイズであるかもしれません。 同じ企業内情報通信網の一員でないホストにデータグラムを送るとき、FDDIネットワークに接続されたホストはこれを覚えておくべきです。 中間ゲートウェイで不要な断片化を避けるために、より小さいデータグラムを送るのは適切であるかもしれません。 詳細のための[17]を見てください。
There is no minimum packet size restriction on FDDI networks.
どんな最小のパケットサイズ制限もFDDIネットワークにありません。
In order to not preclude interoperability with Ethernet in a
bridged environment, FDDI implementations must be prepared to
receive (and ignore) trailing pad octets.
ブリッジしている環境におけるイーサネットがある相互運用性を排除しないように受信するようにFDDI実装を準備しなければならない、(無視、)、引きずっているパッド八重奏。
Other MAC Layer Issues
他のMAC層の問題
The FDDI MAC specification does not require that 16-bit and 48-
FDDI MAC仕様はその16ビットと48を必要としません。
Katz [Page 6] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[6ページ]RFC1390IP
bit address stations be able to interwork fully. It does,
however, require that 16-bit stations have full 48-bit
functionality, and that both types of stations be able to receive
frames sent to either size broadcast address. In order to avoid
interoperability problems, only 48-bit addresses shall be used
with IP and ARP.
いてください。ビット・アドレスステーション、完全に織り込むことができます。 しかしながら、サイズ放送演説に送られたフレームを受け取るのが16ビットのステーションには完全な48ビットの機能性があって、両方のタイプのステーションができるのを必要とします。 相互運用性問題を避けるために、48ビットのアドレスだけがIPとARPと共に使用されるものとします。
The FDDI MAC specification defines two classes of LLC frames,
Asynchronous and Synchronous. Asynchronous frames are further
controlled by a priority mechanism and two classes of token,
Restricted and Unrestricted. Only the use of Unrestricted tokens
and Asynchronous frames are required by the standard for FDDI
interoperability.
FDDI MAC仕様は2つのクラスのLLCフレーム、Asynchronous、およびSynchronousを定義します。 非同期なフレームは優先権メカニズムと2つのクラスのトークン、Restricted、およびUnrestrictedによってさらに制御されます。 UnrestrictedトークンとAsynchronousフレームの使用だけがFDDI相互運用性の規格によって必要とされます。
All IP and ARP frames shall be transmitted as Asynchronous LLC
frames using Unrestricted tokens, and the Priority value is a
matter of local convention. Implementations should make the
priority a tunable parameter for future use. It is recommended
that implementations provide for the reception of IP and ARP
packets in Synchronous frames, as well as Restricted Asynchronous
frames.
すべてのIPとARPフレームはAsynchronous LLCフレームとしてUnrestrictedトークンを使用することで伝えられるものとします、そして、Priority値は地方のコンベンションの物質です。 実装は優先権を今後の使用のための調整可能なパラメタにするべきです。 実装がSynchronousフレームにIPとARPパケットのレセプションに備えるのは、お勧めです、Restricted Asynchronousフレームと同様に。
After packet transmission, FDDI provides Frame Copied (C) and
Address Recognized (A) indicators. The use of these indicators is
a local implementation decision. Implementations may choose to
perform link-level retransmission, ARP cache entry invalidation,
etc., based on the values of these indicators and other
information. The semantics of these indicators, especially in the
presence of bridges, are not well defined as of this writing.
Implementors are urged to follow the work of ANSI ASC X3T9.5 in
regard to this issue in order to avoid interoperability problems.
パケット伝送の後に、FDDIはFrame Copied(C)とAddress Recognized(A)にインディケータを供給します。 これらのインディケータの使用はローカルの実装決定です。 実装は、これらのインディケータと他の情報の値に基づいてリンク・レベル「再-トランスミッション」、ARPキャッシュエントリー無効にするのを実行するのを選ぶかもしれません。 特にブリッジがあるとき、これらのインディケータの意味論はこの書くこと現在、よく定義されません。 作成者が相互運用性問題を避けるためにこの問題に関してANSI ASC X3T9.5の仕事に続くよう促されます。
IEEE 802.2 Details
IEEE802.2の詳細
While not necessary for supporting IP and ARP, all implementations must support IEEE 802.2 standard Class I service in order to be compliant with 802.2. Described below is the minimum functionality necessary for a conformant station. Some of the functions are not related directly to the support of the SNAP SAP (e.g., responding to XID and TEST commands directed to the null or global SAP addresses), but are part of a general LLC implementation. Implementors should consult IEEE Std. 802.2 [11] for details.
IPとARPをサポートするのに必要でない間、すべての実装が、IEEE802.2が私が802.2で言いなりになるために調整する標準のClassであるとサポートしなければなりません。 以下で説明されているのは、conformantステーションに必要な最小の機能性です。 機能のいくつかが、直接SNAP SAPのサポートに関係づけられませんが(例えば、ヌルの、または、グローバルなSAPアドレスに向けられたXIDとTESTコマンドに応じます)、一般的なLLC実装の一部です。 作成者はIEEE Stdに相談するべきです。 802.2 詳細のための[11]。
802.2 Class I LLC requires the support of Unnumbered Information (UI) Commands, eXchange IDentification (XID) Commands and Responses, and TEST link (TEST) Commands and Responses. Stations need not be able to transmit XID and TEST commands, but must be able to transmit responses.
802.2 クラスI LLCはUnnumbered情報(UI)コマンド、eXchange IDentification(XID)コマンド、およびResponsesのサポートを必要として、TESTは(TEST)コマンドとResponsesをリンクします。 駅は、XIDとTESTコマンドを伝える必要はないことができますが、応答を伝えることができなければなりません。
Katz [Page 7] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[7ページ]RFC1390IP
Encodings
Encodings
Command frames are identified by having the low order bit of the
SSAP address reset to zero. Response frames have the low order
bit of the SSAP address set to one.
コマンド・フレームは、SSAPアドレスの下位のビットをゼロにリセットさせることによって、特定されます。 レスポンス・フレームで、SSAPアドレスの下位のビットを1つに設定します。
The UI command has an LLC control field value of 3.
UIコマンドには、3のLLC制御フィールド価値があります。
The XID command/response has an LLC control field value of 175
(decimal) if the Poll/Final bit is off or 191 (decimal) if the
Poll/Final bit is on.
XIDコマンド/応答には、Poll/最終的なビットがオフであるか、またはPoll/決勝に噛み付いたなら191(10進)がオンであるなら、175(10進)のLLC制御フィールド価値があります。
The TEST command/response has an LLC control field value of 227
(decimal) if the Poll/Final bit is off or 243 (decimal) if the
Poll/Final bit is on.
TESTコマンド/応答には、Poll/最終的なビットがオフであるか、またはPoll/決勝に噛み付いたなら243(10進)がオンであるなら、227(10進)のLLC制御フィールド価値があります。
Elements of Procedure
手順のElements
UI responses and UI commands with the Poll bit set shall be
ignored. UI commands having other than the SNAP SAP in the DSAP
or SSAP fields shall not be processed as IP or ARP packets.
Pollビットによるコマンドが設定するUI応答とUIは無視されるものとします。 IPかARPパケットとしてSNAP SAP以外に、DSAPかSSAPに分野を持っているUIコマンドを処理しないものとします。
When an XID or TEST command is received, an appropriate response
must be returned. XID and TEST commands must be responded to only
if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0
decimal), or the Global SAP (255 decimal). XID and TEST commands
received with other DSAP values must not be responded to unless
the station supports the addressed service. Responses to XID and
TEST frames shall be constructed as follows:
XIDかTESTコマンドが受け取られているとき、適切な応答を返さなければなりません。 XIDとTESTコマンドは唯一のDSAPがSNAP SAP(170小数)であるか、そして、Null SAP(0小数)、またはGlobal SAP(255小数)に反応しなければなりません。 ステーションが扱われたサービスをサポートしない場合、他のDSAP値で受け取られたXIDとTESTコマンドに応じてはいけません。 XIDへの応答とTESTフレームは以下の通り構成されるものとします:
Destination MAC: Copied from Source MAC of the command
Source MAC: Set to the address of the MAC receiving the
command
DSAP: Copied from SSAP of the command
SSAP: Set to 171 decimal (SNAP SAP + Response bit) if the
DSAP in the command was the SNAP SAP or the Global SAP;
set to 1 decimal (Null SAP + Response bit) if the DSAP
in the command was the Null SAP
目的地MAC: コマンドSource MACのSource MACからコピーされる: MAC受信のアドレスにコマンドDSAPを設定してください: コマンドSSAPのSSAPからコピーされる: 171小数(SNAP SAP+応答に噛み付いた)にコマンドにおけるDSAPがSNAP SAPであったか、そして、Global SAPを設定してください。 1つの小数(ヌルSAP+応答に噛み付いた)に、コマンドにおけるDSAPがNull SAPであったなら、セットします。
When responding to an XID or a TEST command, the value of the
Final bit in the response must be copied from the value of the
Poll bit in the command.
XIDかTESTコマンドに応じるとき、コマンドにおける、Pollビットの価値から応答における、Finalビットの価値をコピーしなければなりません。
XID response frames must include an 802.2 XID Information field of
129.1.0 indicating Class I (connectionless) service.
XIDレスポンス・フレームは私(コネクションレスな)が調整する129.1.0表示Classの802.2XID情報分野を含まなければなりません。
TEST response frames must echo the information field received in
the corresponding TEST command frame.
TESTレスポンス・フレームは対応するTESTコマンド・フレームに受け取られた情報フィールドを反響しなければなりません。
Katz [Page 8] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[8ページ]RFC1390IP
Appendix on Numbers
数の付録
The IEEE specifies numbers as bit strings with the least significant bit first, or bit-wise little-endian order. The Internet protocols are documented in bit-wise big-endian order. This may cause some confusion about the proper values to use for numbers. Here are the conversions for some numbers of interest.
最下位ビットの1番目の、または、ビット的なリトルエンディアンがあるビット列が注文されるとき、IEEEは数を指定します。 インターネットプロトコルはビット的なビッグエンディアンオーダーに記録されます。 これは数に使用する固有値に関して何らかの混乱を引き起こすかもしれません。 ここに、興味がある数個の数のための変換があります。
Number IEEE Internet Internet
Binary Binary Decimal
数のIEEEインターネットインターネットバイナリー2進の小数
UI 11000000 00000011 3
SAP for SNAP 01010101 10101010 170
Global SAP 11111111 11111111 255
Null SAP 00000000 00000000 0
XID 11110101 10101111 175
XID Poll/Final 11111101 10111111 191
XID Info 129.1.0
TEST 11000111 11100011 227
TEST Poll/Final 11001111 11110011 243
UI11000000 00000011 3はスナップ01010101 10101010のために170のグローバルな体液11111111 11111111 255のヌル体液00000000 00000000 0XID11110101 10101111 175XID投票/決勝11111101 10111111 191XIDインフォメーション129.1.0テスト11000111 11100011 227テスト投票/決勝11001111 11110011 243を徐々に破壊します。
Differences between this document and RFC 1188
このドキュメントとRFC1188の違い
The following is a summary of the differences between RFC 1188 and this document:
↓これはRFC1188とこのドキュメントの違いの概要です:
A reference to a future dual-MAC document has been removed.
将来の二元的なMACドキュメントの参照を取り除いてあります。
A statement of explicit intent to support FDDI/Ethernet
interoperability has been added.
FDDI/イーサネットが相互運用性であるとサポートする明白な意図の声明は加えられます。
The acceptance of ARP frames bearing hardware type code 6 (IEEE
802) has been removed.
ハードウェアタイプコード6(IEEE802)を示すARPフレームの承認を取り除きました。
The references have been updated.
参照をアップデートしました。
The author's address has been updated.
作者のアドレスをアップデートしました。
References
参照
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, MIT, November
1982.
[2] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、RFC826、MIT(1982年11月)
Katz [Page 9] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[9ページ]RFC1390IP
[3] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
Sciences Institute, February 1988.
[3] ポステル、J.、およびJ.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、RFC1042(科学が1988年2月に設けるUSC/情報)。
[4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
Control", ISO 9314-2, 1989. See also ANSI X3.139-1987.
[4] ISO、「ファイバ分散データインタフェース(FDDI)--メディアアクセスは制御する」、ISO9314-2、1989 また、ANSI X3.139-1987を見てください。
[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
Physical Layer Protocol", ISO 9314-1, 1989. See also ANSI
X3.148-1988.
[5] ISO、「ファイバ分散データインタフェース(FDDI)--トークンリング身体検査層は議定書を作る」、ISO9314-1、1989 また、ANSI X3.148-1988を見てください。
[6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
Medium Dependent", ISO DIS 9314-3, 1989. See also ANSI X3.166-
199x.
[6] ISO、「ファイバ分散データインタフェース(FDDI)--身体検査は中型の扶養家族を層にする」、ISOが9314-3に、1989にけなします。 また、ANSI X3.166 199xを見てください。
[7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 7.1, 1992.
[7]ANSI、「FDDI駅の管理」、ANSI X3T9.5/84-49回転7.1、1992。
[8] IEEE, "IEEE Standards for Local Area Networks: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications", IEEE, New York, New York,
1985.
[8] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスする」IEEE、ニューヨーク(ニューヨーク)1985。
[9] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
Access Method and Physical Layer Specification", IEEE, New York,
New York, 1985.
[9] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「トークンパッシングはアクセス法と物理的な層の仕様をバスで運ぶ」IEEE、ニューヨーク(ニューヨーク)1985。
[10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
Method and Physical Layer Specifications", IEEE, New York, New
York, 1985.
[10] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「トークンリングはメソッドと物理的な層の仕様にアクセスする」IEEE、ニューヨーク(ニューヨーク)1985。
[11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[11] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」、IEEE、ニューヨーク(ニューヨーク)1985。
[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
[12] IEEE、「標準のP802.1Aを作成してください--概要とアーキテクチャ」、1989
[13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[13] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[14] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」STD4、RFC1009、科学が1987年6月に設けるUSC/情報。
[15] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, Stanford University, August 1989.
[15] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
October 1981.
[16] D. コーエン、コンピュータ、IEEE、「平和のための聖戦と請願」の1981年10月。
Katz [Page 10] RFC 1390 IP Over FDDI January 1993
FDDI1993年1月の間のキャッツ[10ページ]RFC1390IP
[17] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC 879, USC/Information Sciences Institute, November
1983.
[17] ポステル、J.、「TCPの最大のセグメントサイズは、話題をゆだねて、関係づけた」RFC879、科学が1983年11月に設けるUSC/情報。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Dave Katz cisco Systems, Inc. 1525 O'Brien Dr. Menlo Park, CA 94025
メンローパーク、デーヴキャッツコクチマスSystems Inc.1525オブライエン博士カリフォルニア 94025
Phone: (415) 688-8284 EMail: dkatz@cisco.com
以下に電話をしてください。 (415) 688-8284 メールしてください: dkatz@cisco.com
Katz [Page 11]
キャッツ[11ページ]
一覧
スポンサーリンク
