RFC1103 日本語訳
1103 Proposed standard for the transmission of IP datagrams over FDDINetworks. D. Katz. June 1989. (Format: TXT=19439 bytes) (Obsoleted by RFC1188) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Katz
Request for Comments: 1103 Merit/NSFNET
June 1989
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 1103 長所/NSFNET1989年6月
A Proposed Standard for the Transmission of
IP Datagrams over FDDI Networks
FDDIネットワークの上のIPデータグラムの送信の提案された標準
Status of this Memo
このMemoの状態
This RFC specifies a method of encapsulating the Internet Protocol (IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests and replies on Fiber Distributed Data Interface (FDDI) Networks. This RFC specifies a proposed protocol standard for the Internet community. Comments are welcome. Distribution of this memo is unlimited.
このRFCはファイバ分散データインタフェース(FDDI)ネットワークでインターネットプロトコル(IP)[1]データグラムとAddress Resolutionプロトコル(ARP)が[2]要求と回答であるとカプセル化するメソッドを指定します。 このRFCはインターネットコミュニティの提案されたプロトコル標準を指定します。 コメントを歓迎します。 このメモの分配は無制限です。
Acknowledgment
承認
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.
このメモは概念とテキストの両方でUSC/情報Sciences Instituteのジョン・ポステルとジョイス・K.レイノルズによって書かれたRFC1042[3]から大いに作成されます。
Conventions
コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
"Must" or "Mandatory"--the item is an absolute requirement of the
specification.
"Must"か「義務的」--項目は仕様に関する絶対条件です。
"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月」か「任意」--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
Introduction
序論
The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies.
この仕様の目標はIPデータグラム、ARP要求、および回答を送るためのコンパチブル、そして、共同利用できる実装を許容することです。
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
ファイバ分散データインタフェース(FDDI)仕様はISOオープンSystem Interconnection Reference Model(ISO/OSI)によって定義されるようにData Link LayerのPhysical LayerとメディアAccess Control Sublayerを提供するローカル・エリア・ネットワーク(LAN)の規格のファミリーを定義します。 様々なステージの進行にはドキュメントがあります。
Katz [Page 1] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[1ページ]RFC1103IPデータグラム
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].
メディアアクセスのための国際標準化に向かって、(MAC)[4](物理的な層のプロトコル(PHY)[5]、物理的な層の中型の依存する(PMD)[6]、および駅の管理(SMT)[7])を制御してください。 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 |
+-------------+
| FDDI PHY |
+-------------+
| FDDI PMD |
+-------------+
+-------------+ | IP/アルプ| +-------------+ | 802.2 LLC| +-------------+ | FDDI Mac| +-------------+ | FDDI PHY| +-------------+ | 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相互運用性を排除しない意図です。
Packet Format
パケット・フォーマット
IP datagrams and ARP requests and replies sent on FDDI networks must be encapsulated within the 802.2 LLC and Sub-Network Access Protocol (SNAP) 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 [12]).
IPデータグラム、ARP要求、および回答は、802.2LLCとSub-ネットワークAccessプロトコル(SNAP)データ・リンク層、FDDI MAC、および物理的な層の中でFDDIネットワークをカプセル化しなければならないのを転送しました。 SNAPヘッダーがEtherTypeコードを含むのを示すOrganization Codeと共にSNAPを使用しなければなりません。(Assigned民数記[12])で記載されているように。
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 [12] (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民数記[12](2048、IP=ARP=2054)からのEtherTypeです。
Katz [Page 2] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[2ページ]RFC1103IPデータグラム
...--------+--------+--------+
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 16-bit or 48-bit FDDI addresses must be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [2].
Address Resolutionプロトコル(ARP)[2]のダイナミックな発見手順で16ビットの、または、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 use ARP to translate Internet addresses to FDDI addresses when needed.
インターネット・アドレスはインターネット網で任意に割り当てられます。 各ホストの実装は、適切にそれ自身のインターネット・アドレスを知って、Address Resolution要求に応じなければなりません。 また、必要であると、それは、FDDIアドレスにインターネット・アドレスを翻訳するのにARPを使用しなければなりません。
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 [12]. FDDI networks, although not IEEE 802 networks per se, are semantically equivalent and use the same type code.
IEEE802ネットワークのために割り当てられたハードウェアタイプコードは6[12]です。 FDDIネットワークは、そういうもののIEEE802ネットワークではありませんが、意味的に同等であり、同じタイプコードを使用します。
The protocol type code for IP is 2048 [12].
IPのためのプロトコルタイプコードは2048[12]です。
Katz [Page 3] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[3ページ]RFC1103IPデータグラム
The hardware address length is 2 for 16-bit FDDI addresses, or 6 for 48-bit FDDI addresses.
ハードウェア・アドレスの長さは、16ビットのFDDIアドレスのための2、または48ビットのFDDIアドレスのための6です。
The protocol address length (for IP) is 4.
プロトコルアドレスの長さ(IPのための)は4です。
The operation code is 1 for request and 2 for reply.
命令コードは、要求のための1と回答のための2です。
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 [13]).
放送インターネット・アドレス(すべての2進のもののホスト部分があるそのネットワークに関するアドレス)を放送FDDIアドレス(すべての2進のものの)に写像しなければなりません。([13])を見てください。
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. Consenting systems on the same FDDI network may use this format between themselves. Details of the trailer encapsulation method may be found in [14]. However, all hosts must be able to communicate using the standard (non-trailer) method.
Unix 4.x bsdのいくつかのバージョンが、VAX仮想記憶アーキテクチャによる、より良いネットワーク性能を得るのに異なったカプセル化メソッドを使用します。 同じFDDIネットワークの同意システムは自分たちの間のこの形式を使用するかもしれません。 トレーラカプセル化メソッドの詳細は[14]で見つけられるかもしれません。 しかしながら、すべてのホストが、標準(非トレーラの)のメソッドを使用することで交信できなければなりません。
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" [15].
インターネットプロトコル仕様[1]のAppendix Bで説明されるように、IPデータグラムは一連の8ビットのバイトとしてFDDIネットワークの上に送られます。 このバイトトランスミッション命令は「大きいエンディアン」[15]と呼ばれました。
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 gives the following MAC
layer overhead:
FDDI MAC仕様[4]はすべてのフレーム分野の9000のシンボル(4500の八重奏)の最大のフレーム・サイズを定義します、序文の4つのシンボル(2つの八重奏)を含んでいて。 これは以下のMAC層のオーバーヘッドを与えます:
Katz [Page 4] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[4ページ]RFC1103IPデータグラム
Field Size in Octets
八重奏における分野サイズ
Preamble 2
Start Delimiter 1
Frame Control 1
Destination Address 6 (2)
Source Address 6 (2)
FCS 4
End Delimiter/Frame Status 2
序文2はデリミタ1フレーム規制1送付先アドレス6(2)ソースアドレス6(2)FCS4終わりのデリミタ/フレーム状態2を始めます。
Total 22 (14)
Remaining for Data 4478 (4486)
データ4478のための総22(14)残り(4486)
Subtracting the 8 byte LLC/SNAP header, this gives a maximum
packet size (MTU) of 4470 (4478) octets. For compatibility
purposes, the maximum packet size used with IP datagrams or ARP
requests and replies must be consistent on a particular network.
8バイトのLLC/SNAPヘッダーを引き算して、これは4470(4478)の八重奏の最大のパケットサイズ(MTU)を与えます。 互換性目的のために、IPデータグラムかARP要求と回答と共に使用される最大のパケットサイズは特定のネットワークで一貫していなければなりません。
The overhead calculations (above) assume a standard Frame Status
field consisting of three symbols. Additional Implementor Defined
frame status information, although permitted by the FDDI MAC
specification, must not be used with IP datagrams because it
affects the maximum packet size.
頭上の計算(above)は3つのシンボルから成る標準のFrame Status分野を仮定します。 FDDI MAC仕様で受入れられますが、最大のパケットサイズに影響するので、IPデータグラムと共に追加Implementor Definedフレーム状態情報を使用してはいけません。
Gateway implementations must be prepared to accept full-length
packets and fragment them when necessary.
等身大のパケットを受け入れて、必要であるときにはそれらを断片化するようにゲートウェイ実装を準備しなければなりません。
Host implementations should be prepared to accept full-length
packets; however, hosts must not send datagrams longer than 576
octets unless they have explicit knowledge that the destination is
prepared to accept them. A host may communicate its size
preference in TCP-based applications via the TCP Maximum Segment
Size option [16].
ホスト導入は等身大のパケットを受け入れるように準備されるべきです。 しかしながら、ホストはそれらに目的地が準備される形式知がないなら576の八重奏がそれらを受け入れるより長い間、データグラムを送ってはいけません。 ホストはTCP Maximum Segment Sizeオプション[16]で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 [16] for
further information.
FDDIネットワークのデータグラムは576の八重奏の一般的なインターネットデフォルトより長い最大のパケットサイズであるかもしれません。 同じ企業内情報通信網の一員でないホストにデータグラムを送るとき、FDDIネットワークに接続されたホストはこれを覚えておくべきです。 中間ゲートウェイで不要な断片化を避けるために、より小さいデータグラムを送るのは適切であるかもしれません。 詳細のための[16]を見てください。
There is no minimum packet size restriction on FDDI networks.
どんな最小のパケットサイズ制限もFDDIネットワークにありません。
Other MAC Layer Issues
他のMAC層の問題
The FDDI MAC specification does not require that 16-bit and 48-bit address stations be able to interwork fully. It does, however,
FDDI MAC仕様は、16ビットの、そして、48ビット・アドレスのステーションができるのを必要としません。完全に織り込むために。 しかしながら、それはします。
Katz [Page 5] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[5ページ]RFC1103IPデータグラム
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. For use with IP and ARP, all communicating stations on a LAN must use a consistent address size. Implementations must discard any IP or ARP packets received with an unimplemented or inactive address size. 16-bit and 48-bit implementations may coexist on the same FDDI network; however, if they wish to interwork they must be considered separate IP networks and linked with an IP router capable of supporting 16-and 48-bit addresses simultaneously.
16ビットのステーションには完全な48ビットの機能性があって、両方のタイプのステーションがサイズ放送演説に送られたフレームを受け取ることができるのを必要であってください。 IPとARPとの使用のために、LANのステーションを皆、伝えると、一貫したアドレスサイズは使用されなければなりません。 実装は非実装しているか不活発なアドレスサイズで受け取られたどんなIPやARPパケットも捨てなければなりません。 16ビットの、そして、48ビットの実装は同じFDDIネットワークに共存するかもしれません。 そして、しかしながら、織り込む願望がそれらであるならサポートすることをIPネットワークを切り離して、IPルータができていた状態でリンクした、それらを考えなければならない16、-、同時の48ビットのアドレス。
Group (multicast) addresses are defined by the FDDI MAC specification but are not necessarily supported by existing hardware. Therefore, this feature must not be used by IP and ARP.
グループ(マルチキャスト)アドレスは、FDDI MAC仕様で定義されますが、必ず既存のハードウェアによってサポートされるというわけではありません。 したがって、この特徴はIPとARPによって使用されてはいけません。
The FDDI MAC specification defines two classes of 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. The priority mechanism is currently implemented locally by the transmitting station and the Priority field in Asynchronous frames is ignored by other stations. This field will likely be interpreted by Transparent Bridges once they are defined. There is no default value for priority called out in the MAC standard.
FDDI MAC仕様は2つのクラスのフレーム、Asynchronous、およびSynchronousを定義します。 非同期なフレームは優先権メカニズムと2つのクラスのトークン、Restricted、およびUnrestrictedによってさらに制御されます。 UnrestrictedトークンとAsynchronousフレームの使用だけがFDDI相互運用性の規格によって必要とされます。 優先権メカニズムは現在送信所によって局所的に実装されます、そして、AsynchronousフレームのPriority分野は他のステーションによって無視されます。 それらがいったん定義されると、この分野はTransparentブリッジスによっておそらく解釈されるでしょう。 MACの外に標準であると呼ばれた優先権のためのデフォルト値が全くありません。
Therefore, all IP and ARP frames must be transmitted as Asynchronous 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.
したがって、AsynchronousフレームとしてUnrestrictedトークンを使用することですべてのIPとARPフレームを伝えなければなりません、そして、Priority値は地方のコンベンションの物質です。 実装は優先権を今後の使用のための調整可能なパラメタにするべきです。 実装がSynchronousフレームにIPとARPパケットのレセプションに備えるのは、お勧めです。
After packet transmission, FDDI provides Frame Copied (C) and Address Recognized (A) indicators. There are four possible combinations of the indicators with the following semantics:
パケット伝送の後に、FDDIはFrame Copied(C)とAddress Recognized(A)にインディケータを供給します。 以下の意味論へのインディケータの4つの可能な組み合わせがあります:
(C) (A)
Reset Reset The frame was not received by any station.
Reset Set The addressed station is congested.
Set Reset Reserved.
Set Set The addressed station received the frame.
(C) (A) Resetをリセットしてください。フレームはどんなステーションによっても受け取られませんでした。 Setをリセットしてください。充血する扱われたステーション。 控えられたリセットを設定してください。 Setを設定してください。扱われたステーションはフレームを受けました。
Implementations may use these indicators to provide some amount of error detection and correction:
実装はいくらかの量の誤り検出と訂正を提供するのにこれらのインディケータを使用するかもしれません:
If the Frame Copied bit is reset but the Address Recognized bit is
Frame Copiedビットがリセットされますが、Address Recognizedビットがリセットされるなら
Katz [Page 6] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[6ページ]RFC1103IPデータグラム
set, receiver congestion has occurred. It is recommended, though
not mandatory, that hosts retransmit the offending packet a small
number of times (4) or until congestion no longer occurs.
セットしてください、そして、受信機混雑は起こりました。 それがお勧めであって、もっとも、義務的でない、ホストが(4)か混雑まで回の怒っているパケットa少ない番号を再送するのはもう起こりません。
If the both the Address Recognized indicator and the Frame Copied
indicator are reset, an implementation has three options: (1)
ignore the error and throw the packet away, (2) return an ICMP
destination unreachable message to the source, or (3) delete the
ARP entry which was used to send this packet and send a new ARP
request to the destination address. The latter option is the
preferred approach since it will allow graceful recovery from
first hop bridge and router failures and changed hardware
addresses.
実装には、両方であるなら、Address RecognizedインディケータとFrame Copiedインディケータはリセットされて、3つのオプションがあります: (1) (3) 誤りを無視してください、そして、遠くに、(2)が返すパケットにソースへのICMP送信不可能メッセージを投げてください、または、送付先アドレスにこのパケットを送って、新しいARP要求を送るのに使用されたARPエントリーを削除してください。 最初のホップブリッジ、ルータ失敗、および変えられたハードウェア・アドレスからの優雅な回復を許すので、後者のオプションは好ましい方法です。
As of this writing there is a proposal within ANSI to set the
Frame Copied indicator and reset the Address Recognized indicator
when a frame is forwarded by a Transparent Bridge. For future
compatibility, implementations should interpret this combination
of indicators as if the frame were successfully delivered to the
destination (i.e., do nothing).
この書くこと現在、フレームがTransparent Bridgeによって進められるとき、Frame Copiedインディケータを設定して、Address Recognizedインディケータをリセットするために、ANSIの中に提案があります。 将来の互換性のために、まるでフレームが首尾よく送付先に提供されるかのように(すなわち、何もしないでください)実装はインディケータのこの組み合わせを解釈するべきです。
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. This requires supporting Unnumbered Information (UI) Commands, eXchange IDentification (XID) Commands and Responses, and TEST link (TEST) Commands and Responses.
IPとARPをサポートするのに必要でない間、すべての実装が、IEEE802.2が私が802.2で言いなりになるために調整する標準のClassであるとサポートしなければなりません。 これはUnnumbered情報(UI)がコマンドであるとサポートする、eXchange IDentification(XID)コマンド、およびResponsesを必要とします、そして、TESTは(TEST)コマンドとResponsesをリンクします。
When an XID or TEST command is received, a response must be returned with Destination and Source addresses, and DSAP and SSAP, swapped.
XIDかTESTコマンドが受け取られているとき、Destinationと共に応答を返さなければなりませんでした、そして、Sourceアドレス、DSAP、およびSSAPはスワップしました。
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ビットの価値をコピーしなければなりません。
The XID command or 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 or 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制御フィールド価値があります。
Command frames are identified by having the high order bit of the SSAP address reset to zero. Response frames have the high order bit of the SSAP address set to one.
コマンド・フレームは、SSAPアドレスの高位のビットをゼロにリセットさせることによって、特定されます。 レスポンス・フレームで、SSAPアドレスの高位のビットを1つに設定します。
Katz [Page 7] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[7ページ]RFC1103IPデータグラム
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コマンド・フレームに受け取られた情報フィールドを反響しなければなりません。
Appendix on Numbers
数の付録
The IEEE specifies numbers in bit transmission order, or bit-wise little-endian order. The Internet protocols are documented in byte- 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.
IEEEはビット伝送命令、またはビット的なリトルエンディアンオーダーにおける数を指定します。 インターネットプロトコルはバイトの賢明なビッグエンディアンオーダーに記録されます。 これは数に使用する固有値に関して何らかの混乱を引き起こすかもしれません。 ここに、興味がある数個の数のための変換があります。
Number IEEE IEEE Internet Internet
HEX Binary Binary Decimal
数のIEEE IEEEインターネットインターネット十六進法バイナリー2進の小数
UI Op Code C0 11000000 00000011 3
SAP for SNAP 55 01010101 10101010 170
XID F5 11110101 10101111 175
XID FD 11111101 10111111 191
TEST C7 11000111 11100011 227
TEST CF 11001111 11110011 243
Info 818000 129.1.0
UIオペコードC0 11000000 00000011 3はスナップ55 01010101 10101010のために170XID F5 11110101 10101111 175XID FD11111101 10111111 191テストC7 11000111 11100011 227テストCf11001111 11110011 243インフォメーション818000 129.1.0を徐々に破壊します。
References
参照
[1] Postel, J., "Internet Protocol", RFC-791, USC/Information
Sciences Institute, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、RFC-791、科学が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イーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、RFC-826、MIT(1982年11月)
[3] Postel J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC1042, 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, 1988. See also ANSI X3.139-1987.
[4] ISO、「ファイバ分散データインタフェース(FDDI)--メディアアクセスは制御する」、ISO9314-2、1988 また、ANSI X3.139-1987を見てください。
[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
Physical Layer Protocol", ISO 9314-1, 1988. See also ANSI
X3.148-1988.
[5] ISO、「ファイバ分散データインタフェース(FDDI)--トークンリング身体検査層は議定書を作る」、ISO9314-1、1988 また、ANSI X3.148-1988を見てください。
[6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
Medium Dependent", ISO DIS 9314-3, 1988. See also ANSI X3.166-
[6] ISO、「ファイバ分散データインタフェース(FDDI)--身体検査は中型の扶養家族を層にする」、ISOが9314-3に、1988にけなします。 また、ANSI X3.166を見てください。
Katz [Page 8] RFC 1103 IP Datagrams over FDDI Networks June 1989
FDDIネットワーク1989年6月の上のキャッツ[8ページ]RFC1103IPデータグラム
198x.
198x。
[7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 4.0, 1988.
[7]ANSI、「FDDI駅の管理」、ANSI X3T9.5/84-49回転4.0、1988。
[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] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
[12] USC/情報科学が設けるレイノルズ、J.K.、およびJ.ポステル、「規定番号」、RFC-1010は1987がそうするかもしれません。
[13] Braden, R., and J. Postel, "Requirements for Internet Gateways",
RFC-1009, USC/Information Sciences Institute, June 1987.
[13] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」RFC-1009、科学が1987年6月に設けるUSC/情報。
[14] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
University of California at Berkeley, April 1984.
[14] レフラー、S.とM.Karels、「トレーラカプセル化」、RFC-893、カリフォルニア大学バークレイ校、1984年4月。
[15] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
October 1981.
[15] D. コーエン、コンピュータ、IEEE、「平和のための聖戦と請願」の1981年10月。
[16] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC-879, USC/Information Sciences Institute, November
1983.
[16] ポステル、J.、「TCPの最大のセグメントサイズは、話題をゆだねて、関係づけた」RFC-879、科学が1983年11月に設けるUSC/情報。
Author's Address
作者のアドレス
Dave Katz Merit/NSFNET 1075 Beal Ann Arbor, MI 48109-2112
ビール・アナーバー、デーヴキャッツ長所/NSFNET1075MI48109-2112
Phone: 1-800-66-MERIT
以下に電話をしてください。 1-800-66-長所
Email: Dave_Katz@um.cc.umich.edu
メール: Dave_Katz@um.cc.umich.edu
Katz [Page 9]
キャッツ[9ページ]
一覧
スポンサーリンク
