RFC1042 日本語訳
1042 Standard for the transmission of IP datagrams over IEEE 802networks. J. Postel, J.K. Reynolds. February 1988. (Format: TXT=34359 bytes) (Obsoletes RFC0948) (Also STD0043) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 1042 J. Reynolds
ISI
Obsoletes: RFC-948 February 1988
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 1042J.レイノルズISIは以下を時代遅れにします。 RFC-948 1988年2月
A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
IEEE802ネットワークの上のIPデータグラムの送信の規格
Status of this Memo
このMemoの状態
This RFC specifies a standard method of encapsulating the Internet Protocol (IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests and replies on IEEE 802 Networks. This RFC specifies a protocol standard for the Internet community. Distribution of this memo is unlimited.
このRFCはIEEE802Networksでインターネットプロトコル(IP)[1]データグラムとAddress Resolutionプロトコル(ARP)が[2]要求と回答であるとカプセル化する標準方法を指定します。 このRFCはインターネットコミュニティのプロトコル標準を指定します。 このメモの分配は無制限です。
Acknowledgment
承認
This memo would not exist with out the very significant contributions of Drew Perkins of Carnegie Mellon University, Jacob Rekhter of the T.J. Watson Research Center, IBM Corporation, and Joseph Cimmino of the University of Maryland.
このメモはアウトのIBMのカーネギーメロン大学のドリュー・パーキンスの非常に重要な貢献、T.J.ワトソン研究所のヤコブRekhter、社、およびメリーランド大学のジョゼフCimminoと共に存在していないでしょう。
Introduction
序論
The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies. To achieve this it may be necessary in a few cases to limit the use that IP and ARP make of the capabilities of a particular IEEE 802 standard.
この仕様の目標はIPデータグラム、ARP要求、および回答を送るためのコンパチブル、そして、共同利用できる実装を許容することです。 これを達成するために、IPとARPが特定のIEEE802規格の能力でする使用を制限するのがいくつかの場合で必要であるかもしれません。
The IEEE 802 specifications define a family of standards for Local Area Networks (LANs) that deal with the Physical and Data Link Layers as defined by the ISO Open System Interconnection Reference Model (ISO/OSI). Several Physical Layer standards (802.3, 802.4, and 802.5) [3,4,5] and one Data Link Layer Standard (802.2) [6] have been defined. The IEEE Physical Layer standards specify the ISO/OSI Physical Layer and the Media Access Control Sublayer of the ISO/OSI Data Link Layer. The 802.2 Data Link Layer standard specifies the Logical Link Control Sublayer of the ISO/OSI Data Link Layer.
IEEE802仕様はISOオープンSystem Interconnection Reference Model(ISO/OSI)によって定義されるようにPhysicalとData Link Layersに対処するローカル・エリア・ネットワーク(LAN)の規格のファミリーを定義します。 いくつかのPhysical Layer規格(802.3、802.4、および802.5)[3、4、5]と1つData Link Layer Standard(802.2)[6]は定義されました。 IEEE Physical Layer規格はISO/OSI Data Link LayerのISO/OSI Physical LayerとメディアAccess Control Sublayerを指定します。 802.2Data Link Layer規格はISO/OSI Data Link LayerのLogical Link Control Sublayerを指定します。
This memo describes the use of IP and ARP on the three types of networks. At this time, it is not necessary that the use of IP and ARP be consistent across all three types of networks, only that it be consistent within each type. This may change in the future as new IEEE 802 standards are defined and the existing standards are revised
このメモは3つのタイプのネットワークでIPとARPの使用について説明します。 このとき、IPとARPの使用がすべての3つのタイプのネットワークの向こう側に一貫していて、それが各タイプの中で一貫しているだけであるのは必要ではありません。 新しいIEEE802規格が定義されて、既存の規格が改訂されているとき、これは将来、変化するかもしれません。
Postel & Reynolds [Page 1] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[1ページ]RFC1042IPとARP
allowing for interoperability at the Data Link Layer.
Data Link Layerで相互運用性を考慮します。
It is the goal of this memo to specify enough about the use of IP and ARP on each type of network to ensure that:
それはそれぞれのタイプのネットワークでIPとARPの使用に関してそれを確実にするほど指定するこのメモの目標です:
(1) all equipment using IP or ARP on 802.3 networks will
interoperate,
(1) 802.3のネットワークでIPかARPを使用するすべての設備が共同利用するでしょう。
(2) all equipment using IP or ARP on 802.4 networks will
interoperate,
(2) 802.4のネットワークでIPかARPを使用するすべての設備が共同利用するでしょう。
(3) all equipment using IP or ARP on 802.5 networks will
interoperate.
(3) 802.5のネットワークでIPかARPを使用するすべての設備が共同利用するでしょう。
Of course, the goal of IP is interoperability between computers attached to different networks, when those networks are interconnected via an IP gateway [8]. The use of IEEE 802.1 compatible Transparent Bridges to allow interoperability across different networks is not fully described pending completion of that standard.
もちろん、IPの目標は異なったネットワークに取り付けられたコンピュータの間の相互運用性です、それらのネットワークがIPゲートウェイ[8]を通してインタコネクトされるとき。 異なったネットワークの向こう側に相互運用性を許容するIEEE802.1のコンパチブルTransparentブリッジスの使用はその規格の完全に説明されるというわけではない未定の完成です。
Description
記述
IEEE 802 networks may be used as IP networks of any class (A, B, or C). These systems use two Link Service Access Point (LSAP) fields of the LLC header in much the same way the ARPANET uses the "link" field. Further, there is an extension of the LLC header called the Sub-Network Access Protocol (SNAP).
IEEE802ネットワークはどんなクラス(A、B、またはC)のIPネットワークとしても使用されるかもしれません。 これらのシステムはアルパネットが「リンク」分野を使用する似たり寄ったりの方法でLLCヘッダーの2Link Service Access Point(LSAP)分野を使用します。 さらに、Sub-ネットワークAccessプロトコル(SNAP)と呼ばれるLLCヘッダーの拡大があります。
IP datagrams are sent on IEEE 802 networks encapsulated within the 802.2 LLC and SNAP data link layers, and the 802.3, 802.4, or 802.5 physical networks layers. The SNAP is used with an Organization Code indicating that the following 16 bits specify the EtherType code (as listed in Assigned Numbers [7]).
IPデータグラムは802.2LLCとSNAPデータ・リンク層と、802.3か、802.4か、802.5個の物理ネットワーク層の中でカプセル化された転送されたIEEE802ネットワークです。 SNAPは以下の16ビットがEtherTypeコードを指定するのを示すOrganization Codeと共に使用されます。(Assigned民数記[7])で記載されているように。
Normally, all communication is performed using 802.2 type 1 communication. Consenting systems on the same IEEE 802 network may use 802.2 type 2 communication after verifying that it is supported by both nodes. This is accomplished using the 802.2 XID mechanism. However, type 1 communication is the recommended method at this time and must be supported by all implementations. The rest of this specification assumes the use of type 1 communication.
通常、すべてのコミュニケーションが、802.2タイプ1コミュニケーションを使用することで実行されます。 IEEE802ネットワークが802.2に使用するかもしれない同じくらいの同意システムはそれが両方のノードによってサポートされることを確かめた後に、2コミュニケーションをタイプします。 これは802.2XIDメカニズムを使用するのに優れています。 しかしながら、タイプ1コミュニケーションをこのときお勧めのメソッドであり、すべての実装でサポートしなければなりません。 この仕様の残りはタイプ1コミュニケーションの使用を仮定します。
The IEEE 802 networks may have 16-bit or 48-bit physical addresses. This specification allows the use of either size of address within a given IEEE 802 network.
IEEE802ネットワークには、16ビットの、または、48ビットの物理アドレスは、あるかもしれません。 この仕様は与えられたIEEE802ネットワークの中でアドレスのサイズの使用を許します。
Note that the 802.3 standard specifies a transmission rate of from 1
802.3規格が1から通信速度を指定する注意
Postel & Reynolds [Page 2] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[2ページ]RFC1042IPとARP
to 20 megabit/second, the 802.4 standard specifies 1, 5, and 10 megabit/second, and the 802.5 standard specifies 1 and 4 megabit/second. The typical transmission rates used are 10 megabit/second for 802.3, 10 megabit/second for 802.4, and 4 megabit/second for 802.5. However, this specification for the transmission of IP Datagrams does not depend on the transmission rate.
20メガビット/秒に、802.4規格は5、および10 1、メガビット/秒を指定します、そして、802.5規格は1と4メガビット/秒を指定します。 使用される典型的な通信速度は、802.3のための10メガビット/秒と、802.4のための10メガビット/秒と、802.5のための4メガビット/秒です。 しかしながら、IPデータグラムの送信のためのこの仕様は通信速度によりません。
Header Format
Header
ヘッダー形式ヘッダー
...--------+--------+--------+
MAC Header | 802.{3/4/5} MAC
...--------+--------+--------+
...--------+--------+--------+ MACヘッダー| 802. 3/4/5、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, making the 802.2 protocol overhead come out on an nice boundary.
LLC HeaderとSNAPヘッダーの全長は8八重奏です、802.2プロトコルオーバーヘッドを良い境界で出て来させて。
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 Mappings
アドレス・マッピング
The mapping of 32-bit Internet addresses to 16-bit or 48-bit IEEE 802 addresses must be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [2].
Address Resolutionプロトコル(ARP)[2]のダイナミックな発見手順で16ビットの、または、48ビットのIEEE802アドレスへの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 IEEE 802 addresses when needed.
インターネット・アドレスはインターネット網で任意に割り当てられます。 各ホストの実装は、適切にそれ自身のインターネット・アドレスを知って、Address Resolution要求に応じなければなりません。 また、必要であると、それは、IEEE802アドレスにインターネット・アドレスを翻訳するのにARPを使用しなければなりません。
The ARP Details
ARPの詳細
The ARP protocol has several fields that parameterize its use in
any specific context [2]. These fields are:
ARPプロトコルには、どんな特定の文脈[2]でも使用をparameterizeするいくつかの分野があります。 これらの分野は以下の通りです。
Postel & Reynolds [Page 3] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[3ページ]RFC1042IPとARP
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 the IEEE 802 networks (of all
kinds) is 6 (see [7] page 16).
IEEE802ネットワーク(すべての種類の)のために割り当てられたハードウェアタイプコードは6([7] 16ページを参照する)です。
The protocol type code for IP is 2048 (see [7] page 14).
IPのためのプロトコルタイプコードは2048([7] 14ページを参照する)です。
The hardware address length is 2 for 16-bit IEEE 802 addresses, or
6 for 48-bit IEEE 802 addresses.
ハードウェア・アドレスの長さは48ビットのIEEE802アドレスのための16ビットのIEEE802のアドレス、または6のための2です。
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) should be mapped to the broadcast IEEE 802 address (of all binary ones) (see [8] page 14).
放送インターネットアドレス(すべての2進のもののホスト部分があるそのネットワークに関するアドレス)は放送IEEE802アドレス(すべての2進のものの)に写像されるべきです([8] 14ページを参照してください)。
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 IEEE 802 network may use this format between themselves. Details of the trailer encapsulation method may be found in [9]. However, all hosts must be able to communicate using the standard (non-trailer) method.
Unix 4.x bsdのいくつかのバージョンが、VAX仮想記憶アーキテクチャによる、より良いネットワーク性能を得るのに異なったカプセル化メソッドを使用します。 同じIEEE802ネットワークの同意システムは自分たちの間のこの形式を使用するかもしれません。 トレーラカプセル化メソッドの詳細は[9]で見つけられるかもしれません。 しかしながら、すべてのホストが、標準(非トレーラの)のメソッドを使用することで交信できなければなりません。
Byte Order
バイトオーダー
As described in Appendix B of the Internet Protocol specification [1], the IP datagram is transmitted over IEEE 802 networks as a series of 8-bit bytes. This byte transmission order has been called "big-endian" [11].
インターネットプロトコル仕様[1]のAppendix Bで説明されるように、IPデータグラムは一連の8ビットのバイトとしてIEEE802ネットワークの上に送られます。 このバイトトランスミッション命令は「ビッグエンディアン」[11]と呼ばれました。
Maximum Transmission Unit
マキシマム・トランスミッション・ユニット
The Maximum Transmission Unit (MTU) differs on the different types of IEEE 802 networks. In the following there are comments on the MTU for each type of IEEE 802 network. However, on any particular network all hosts must use the same MTU. In the following, the terms "maximum packet size" and "maximum transmission unit" are equivalent.
Maximum Transmission Unit(MTU)は異なったタイプのIEEE802ネットワークについて異なる意見をもちます。 以下に、それぞれのタイプのIEEE802ネットワークのためのMTUのコメントがあります。 しかしながら、どんな特定のネットワークでも、すべてのホストが同じMTUを使用しなければなりません。 以下では、用語「最大のパケットサイズ」と「マキシマム・トランスミッション・ユニット」は同義です。
Postel & Reynolds [Page 4] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[4ページ]RFC1042IPとARP
Frame Format and MAC Level Issues
フレーム形式とMACは問題を平らにします。
For all hardware types
すべてのハードウェアタイプのために
IP datagrams and ARP requests and replies are transmitted in
standard 802.2 LLC Type 1 Unnumbered Information format, control
code 3, with the DSAP and the SSAP fields of the 802.2 header set
to 170, the assigned global SAP value for SNAP [6]. The 24-bit
Organization Code in the SNAP is zero, and the remaining 16 bits
are the EtherType from Assigned Numbers [7] (IP = 2048, ARP =
2054).
IPデータグラム、ARP要求、および回答は標準の802.2LLC Type1Unnumbered情報形式で送られます、制御コード3、802.2ヘッダーの分野が170に設定するDSAPとSSAPと共に、SNAP[6]のための割り当てられたグローバルなSAP値。 SNAPの24ビットのOrganization Codeはゼロです、そして、残っている16ビットはAssigned民数記[7](2048、IP=ARP=2054)からのEtherTypeです。
IEEE 802 packets may have a minimum size restriction. When
necessary, the data field should be padded (with octets of zero)
to meet the IEEE 802 minimum frame size requirements. This
padding is not part of the IP datagram and is not included in the
total length field of the IP header.
IEEE802パケットには、最小規模制限があるかもしれません。 必要であるときに、データ・フィールドは、IEEE802の最小のフレーム・サイズ必要条件を満たすために水増しされるべきです(ゼロの八重奏で)。 この詰め物は、IPデータグラムの一部でなく、またIPヘッダーの全長分野に含まれていません。
For compatibility (and common sense) the minimum packet size used
with IP datagrams is 28 octets, which is 20 (minimum IP header) +
8 (LLC+SNAP header) = 28 octets (not including the MAC header).
IPデータグラムと共に使用される最小のパケットサイズが互換性(そして、常識)のための、28の八重奏である、どれが20(最小のIPヘッダー)+8であるか(LLC+SNAPヘッダー)は28の八重奏と等しいです(MACヘッダーを含んでいなくて)。
The minimum packet size used with ARP is 24 octets, which is 20
(ARP with 2 octet hardware addresses and 4 octet protocol
addresses) + 8 (LLC+SNAP header) = 24 octets (not including the
MAC header).
ARPと共に使用される最小のパケットサイズが24の八重奏である、どれが20(2つの八重奏ハードウェア・アドレスと4つの八重奏プロトコルアドレスがあるARP)+8であるか(LLC+SNAPヘッダー)は24の八重奏と等しいです(MACヘッダーを含んでいなくて)。
In typical situations, the packet size used with ARP is 32 octets,
which is 28 (ARP with 6 octet hardware addresses and 4 octet
protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not
including the MAC header).
典型的な状況において、ARPと共に使用されるパケットサイズが32の八重奏である、どれが28(6つの八重奏ハードウェア・アドレスと4つの八重奏プロトコルアドレスがあるARP)+8であるか(LLC+SNAPヘッダー)は32の八重奏と等しいです(MACヘッダーを含んでいなくて)。
IEEE 802 packets may have a maximum size restriction.
Implementations are encouraged to support full-length packets.
IEEE802パケットには、最大サイズ制限があるかもしれません。 実装が等身大のパケットをサポートするよう奨励されます。
For compatibility purposes, the maximum packet size used with IP
datagrams or ARP requests and replies must be consistent on a
particular network.
互換性目的のために、IPデータグラムかARP要求と回答と共に使用される最大のパケットサイズは特定のネットワークで一貫していなければなりません。
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 [10].
ホスト導入は等身大のパケットを受け入れるように準備されるべきであり、しかしながら、ホストはそれらに目的地が準備される形式知がないなら576の八重奏がそれらを受け入れるより長い間、データグラムを送ってはいけません。 ホストはTCP Maximum Segment Sizeオプション[10]でTCPのベースのアプリケーションにおけるサイズ好みを伝えるかもしれません。
Postel & Reynolds [Page 5] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[5ページ]RFC1042IPとARP
Datagrams on IEEE 802 networks may be longer than the general
Internet default maximum packet size of 576 octets. Hosts
connected to an IEEE 802 network should keep this in mind when
sending datagrams to hosts not on the same IEEE 802 network. It
may be appropriate to send smaller datagrams to avoid unnecessary
fragmentation at intermediate gateways. Please see [10] for
further information.
IEEE802ネットワークのデータグラムは576の八重奏の一般的なインターネットデフォルトより長い最大のパケットサイズであるかもしれません。 どんな同じIEEE802ネットワークでもデータグラムをホストに送らないとき、IEEE802ネットワークに接続されたホストはこれを覚えておくべきです。 中間ゲートウェイで不要な断片化を避けるために、より小さいデータグラムを送るのは適切であるかもしれません。 詳細のための[10]を見てください。
IEEE 802.2 Details
IEEE802.2の詳細
While not necessary for supporting IP and ARP, all
implementations are required to support IEEE 802.2 standard
Class I service. This requires supporting Unnumbered
Information (UI) Commands, eXchange IDentification (XID)
Commands and Responses, and TEST link (TEST) Commands and
Responses.
IPとARPをサポートするのに必要でない間、すべての実装が、IEEE802.2が私が調整する標準のClassであるとサポートするのに必要です。 これはUnnumbered情報(UI)がコマンドであるとサポートする、eXchange IDentification(XID)コマンド、およびResponsesを必要とします、そして、TESTは(TEST)コマンドとResponsesをリンクします。
When either an XID or a TEST command is received a response
must be returned; with the Destination and Source addresses,
and the DSAP and SSAP swapped.
XIDかTESTコマンドのどちらかが受け取られているとき、応答を返さなければなりません。 交換されたDestination、Sourceアドレス、DSAP、およびSSAPと共に。
When responding to an XID or a TEST command the sense of the
poll/final bit must be preserved. That is, a command received
with the poll/final bit reset must have the response returned
with the poll/final bit reset and vice versa.
XIDかTESTコマンドに応じるとき、投票/最終的なビットの感覚を保持しなければなりません。 すなわち、コマンドは投票/最終的なビットで返された応答がリセットで逆もまた同様にリセットしなければならない投票/最終的なビットで受信されました。
The XID command or response has an LLC control field value of
175 (decimal) if poll is off or 191 (decimal) if poll is on.
(See Appendix on Numbers.)
XIDコマンドか応答には、投票が取り止めになっているか、または191が(10進)であるなら、投票が進行中なら、175(10進)のLLC制御フィールド価値があります。 (数の付録を見てください。)
The TEST command or response has an LLC control field value of
227 (decimal) if poll is off or 243 (decimal) if poll is on.
(See Appendix on Numbers.)
TESTコマンドか応答には、投票が取り止めになっているか、または243が(10進)であるなら、投票が進行中なら、227(10進)のLLC制御フィールド価値があります。 (数の付録を見てください。)
A command frame is identified with high order bit of the SSAP
address reset. Response frames have high order bit of the SSAP
address set to one.
コマンド・フレームはSSAPアドレスリセットの高位のビットと同一視されています。 レスポンス・フレームで、SSAPアドレスの高位のビットを1つに設定します。
XID response frames should include an 802.2 XID Information
field of 129.1.0 indicating Class I (connectionless) service.
(type 1).
XIDレスポンス・フレームは私(コネクションレスな)が調整する129.1.0表示Classの802.2XID情報分野を含んでいるはずです。 (1をタイプします。)
TEST response frames should echo the information field received
in the corresponding TEST command frame.
TESTレスポンス・フレームは対応するTESTコマンド・フレームに受け取られた情報フィールドを反響するはずです。
Postel & Reynolds [Page 6] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[6ページ]RFC1042IPとARP
For IEEE 802.3
IEEE802.3のために
A particular implementation of an IEEE 802.3 Physical Layer is
denoted using a three field notation. The three fields are data
rate in megabit/second, medium type, and maximum segment length in
hundreds of meters. One combination of of 802.3 parameters is
10BASE5 which specifies a 10 megabit/second transmission rate,
baseband medium, and 500 meter segments. This correspondes to the
specifications of the familiar "Ethernet" network.
IEEE802.3Physical Layerの特定の実装は、3分野記法を使用することで指示されます。 3つの分野がメガビット/秒、ミディアム・タイプ、および最大のセグメントの長さが何百メーターのもデータ信号速度です。 1つの組み合わせ、802.3では、パラメタはa10メガビット/第2通信速度、ベースバンド媒体、および500メーターのセグメントを指定する10BASE5です。 身近な「イーサネット」ネットワークの仕様へのこのcorrespondes。
The MAC header contains 6 (2) octets of source address, 6 (2)
octets of destination address, and 2 octets of length. The MAC
trailer contains 4 octets of Frame Check Sequence (FCS), for a
total of 18 (10) octets.
MACヘッダーはソースアドレスの6(2)八重奏、送付先アドレスの6(2)八重奏、および長さの2つの八重奏を含んでいます。 MACトレーラは合計18の(10)八重奏のためのFrame Check Sequence(FCS)の4つの八重奏を含んでいます。
IEEE 802.3 networks have a minimum packet size that depends on the
transmission rate. For type 10BASE5 802.3 networks the minimum
packet size is 64 octets.
IEEE802.3に、ネットワークには、通信速度に依存する最小のパケットサイズがあります。 タイプ10BASE5 802.3ネットワークにおいて、最小のパケットサイズは64の八重奏です。
IEEE 802.3 networks have a maximum packet size which depends on
the transmission rate. For type 10BASE5 802.3 networks the
maximum packet size is 1518 octets including all octets between
the destination address and the FCS inclusive.
IEEE802.3に、ネットワークには、通信速度に依存する最大のパケットサイズがあります。 タイプ10BASE5 802.3ネットワークにおいて、最大のパケットサイズは包括的に送付先アドレスとFCSの間のすべての八重奏を含む1518の八重奏です。
This allows 1518 - 18 (MAC header+trailer) - 8 (LLC+SNAP header) =
1492 for the IP datagram (including the IP header). Note that
1492 is not equal to 1500 which is the MTU for Ethernet networks.
これは1518--18(MACヘッダー+トレーラ)を許容します--IPデータグラム(IPヘッダーを含んでいる)のための8(LLC+SNAPヘッダー)=1492。 イーサネットネットワークには、1492がMTUである1500と等しくないことに注意してください。
For IEEE 802.4
IEEE802.4のために
The MAC header contains 1 octet of frame control, 6 (2) octets of
source address, and 6 (2) octets of destination address. The MAC
trailer contains 4 octets of Frame Check Sequence (FCS), for a
total of 17 (9) octets.
MACヘッダーはフレームコントロールの1つの八重奏、ソースアドレスの6(2)八重奏、および送付先アドレスの6(2)八重奏を含んでいます。 MACトレーラは合計17の(9)八重奏のためのFrame Check Sequence(FCS)の4つの八重奏を含んでいます。
IEEE 802.4 networks have no minimum packet size.
IEEE802.4に、ネットワークには、どんな最小のパケットサイズもありません。
IEEE 802.4 networks have a maximum packet size of 8191 octets
including all octets between the frame control and the FCS
inclusive.
IEEE802.4に、ネットワークはフレームコントロールとFCSの間のすべての八重奏を含む8191の八重奏の最大のパケットサイズを包括的にします。
This allows 8191 - 17 (MAC header+trailer) - 8 (LLC+SNAP header) =
8166 for the IP datagram (including the IP header).
これは8191--17(MACヘッダー+トレーラ)を許容します--IPデータグラム(IPヘッダーを含んでいる)のための8(LLC+SNAPヘッダー)=8166。
Postel & Reynolds [Page 7] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[7ページ]RFC1042IPとARP
For IEEE 802.5
IEEE802.5のために
The current standard for token ring's, IEEE 802.5-1985, specifies
the operation of single ring networks. However, most
implementations of 802.5 have added extensions for multi-ring
networks using source-routing of packets at the MAC layer. There
is now a Draft Addendum to IEEE 802.5, "Enhancement for Multi-Ring
Networks" which attempts to standardize these extensions.
Unfortunately, the most recent draft (November 10, 1987) is still
rapidly evolving. More importantly, it differs significantly from
the existing implementations. Therefore, the existing
implementations of 802.5 [13] are described but no attempt is made
to specify any future standard.
トークンリングのものの現在の規格(IEEE802.5-1985)はただ一つのリングネットワークの操作を指定します。 しかしながら、802.5のほとんどの実装が、マルチリングネットワークのためにMAC層でパケットのソースルーティングを使用することで拡大を加えました。 現在、IEEE802.5、これらの拡大を標準化するのを試みる「マルチリングネットワークのための増進」へのDraft Addendumがあります。 残念ながら、最新の草稿(1987年11月10日)はまだ急速に発展しています。 より重要に、それは既存の実装から有意差があります。 したがって、802.5[13]の既存の実装について説明しますが、どんな将来の規格も指定するのを試みを全くしません。
The MAC header contains 1 octet of access control, 1 octet of
frame control, 6 (2) octets of source address, 6 (2) octets of
destination address, and (for multi-ring networks) 0 to 18 octets
of Routing Information Field (RIF). The MAC trailer contains 4
octets of FCS, for a total of 18 (10) to 36 (28) octets. There is
one additional octet of frame status after the FCS.
MACヘッダーはアクセスコントロールの1つの八重奏、フレームコントロールの1つの八重奏、ソースアドレスの6(2)八重奏、送付先アドレスの6(2)八重奏、および経路情報Field(RIF)の(マルチリングネットワークのための)の0〜18の八重奏を含んでいます。 MACトレーラは合計18(10)のためのFCSの4つの八重奏を36(28)八重奏に含んでいます。 FCSの後に、フレーム状態の1つの追加八重奏があります。
Multi-Ring Extension Details
マルチリング拡大の詳細
The presence of a Routing Information Field is indicated by the
Most Significant Bit (MSB) of the source address, called the
Routing Information Indicator (RII). If the RII equals zero, a
RIF is not present. If the RII equals 1, the RIF is present.
Although the RII is indicated in the source address, it is not
part of a stations MAC layer address. In particular, the MSB
of a destination address is the individual/group address
indicator, and if set will cause such frames to be interpreted
as multicasts. Implementations should be careful to reset the
RII to zero before passing source addresses to other protocol
layers which may be confused by their presence.
経路情報Indicator(RII)は、経路情報Fieldの存在がソースアドレスのMost Significant Bit(MSB)によって示されると呼びました。 RIIがゼロと等しいなら、RIFは存在していません。 RIIが1と等しいなら、RIFは存在しています。 RIIはソースアドレスで示されますが、それはステーションMAC層のアドレスの一部ではありません。 送付先アドレスのMSBは特に、個人/グループアドレスインディケータとセットがマルチキャストとしてそのようなフレームを解釈させるかどうかということです。 実装はそれらの存在によって混乱するかもしれない他のプロトコル層にソースアドレスを通過する前にゼロにRIIをリセットするのに慎重であるはずです。
The RIF consists of a two-octet Routing Control (RC) field
followed by 0 to 8 two-octet Route-Designator (RD) fields. The
RC for all-routes broadcast frames is formatted as follows:
RIFは0〜8の2八重奏のRoute-指示子(RD)分野があとに続いた2八重奏のルート設定Control(RC)分野から成ります。 オールルート放送フレームへのRCは以下の通りフォーマットされます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B | LTH |D| LF | r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B| LTH|D| LF| r| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
各ダニ麻痺が1つのビット位置を表すことに注意してください。
Postel & Reynolds [Page 8] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[8ページ]RFC1042IPとARP
B - Broadcast Indicators: 3 bits
B--インディケータを放送してください: 3ビット
The Broadcast Indicators are used to indicate the routing
desired for a particular frame. A frame may be routed
through a single specified route, through every distinct
non-repeating route in a multi-ring network, or through a
single route determined by a spanning tree algorithm such
that the frame appears on every ring exactly once. The
values which may be used at this time are (in binary):
Broadcast Indicatorsは、特定のフレームに望まれていたルーティングを示すのに使用されます。 フレームはただ一つの指定されたルートで発送されるかもしれません、マルチリングネットワークか、スパニングツリーアルゴリズムによって決定しているただ一つのルートを通したあらゆる異なった非反復しているルートでフレームはまさにあらゆるリングの上に一度現れます。 このとき使用されるかもしれない値はこと(バイナリーで)です:
000 - Non-broadcast (specific route)
100 - All-routes broadcast (global broadcast)
110 - Single-route broadcast (limited broadcast)
000--非放送(特定のルート)100--オールルート放送(グローバルな放送)110--ただ一つのルート放送(限られた放送)
All other values are reserved for future use.
他のすべての値が今後の使用のために予約されます。
LTH - Length: 5 bits
LTH--、長さ: 5ビット
The Length bits are used to indicate the length or the RI
field, including the RC and RD fields. Only even values
between 2 and 30 inclusive are allowed.
Lengthビットは、RCとRD分野を含む長さかロードアイランド分野を示すのに使用されます。 2と30の間で包括的な値だけさえ許容されています。
D - Direction Bit: 1 bit
D--方向ビット: 1ビット
The D bit specifies the order of the RD fields. If D
equals 1, the routing-designator fields are specified in
reverse order.
DビットはRD分野の注文を指定します。 Dが1と等しいなら、ルーティング指示子分野は逆順で指定されます。
LF - Largest Frame: 3 bits
LF--最も大きいフレーム: 3ビット
The LF bits specify the maximum MTU supported by all
bridges along a specific route. All multi-ring broadcast
frames should be transmitted with a value at least as
large as the supported MTU. The values used are:
LFビットは特定のルートに沿ったすべてのブリッジによってサポートされた最大のMTUを指定します。 すべてのマルチリング放送フレームがサポートしているMTUと少なくとも同じくらい大きい値で伝えられるべきです。 使用される値は以下の通りです。
LF (binary) MAC MTU IP MTU
LFの(2進)のMAC MTU IP MTU
000 552 508
001 1064 1020
010 2088 2044
011 4136 4092
100 8232 8188
000 552 508 001 1064 1020 010 2088 2044 011 4136 4092 100 8232 8188
All other values are reserved for future use.
他のすべての値が今後の使用のために予約されます。
The receiver should compare the LF received with the MTU.
If the LF is greater than or equal to the MTU then no
action is taken; however, if the LF is less than the MTU
受信機はMTUと共に受け取られたLFを比較するはずです。 LFがそう以上である、MTU、次に、行動を全く取りません。 しかしながら、LFはMTU以下です。
Postel & Reynolds [Page 9] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[9ページ]RFC1042IPとARP
the frame is rejected.
フレームは拒絶されます。
There are actually three possible actions if LF < MTU.
First is the one required for this specification
(reject the frame). Second is to reduce the MTU for
all hosts to equal the LF. And, third is to keep a
separate MTU per communicating host based on the
received LFs.
実際に、3つの可能な動作がLF<MTUであるならあります。 まず最初に、この仕様に必要であるものがあります(フレームを拒絶してください)。 2番目はすべてのホストがLFと等しいようにMTUを減少させることです。 そして、3番目は容認されたLFsに基づくホストを伝えるのあたり1別々のMTUを保つことです。
r - reserved: 4 bits
r--予約される: 4ビット
These bits are reserved for future use and must be set to
0 by the transmitter and ignored by the receiver.
これらのビットを今後の使用のために予約されて、送信機によって0に設定されて、受信機で無視しなければなりません。
It is not necessary for an implementation to interpret
routing-designators. Their format is left unspecified.
Routing-designators should be transmitted exactly as received.
ルーティング指示子を解釈するのは実装に必要ではありません。 それらの形式は不特定のままにされます。 ルート設定指示子はちょうど受け取るように伝えられるべきです。
IEEE 802.5 networks have no minimum packet size.
IEEE802.5に、ネットワークには、どんな最小のパケットサイズもありません。
IEEE 802.5 networks have a maximum packet size based on the
maximum time a node may hold the token. This time depends on many
factors including the data signalling rate and the number of nodes
on the ring. The determination of maximum packet size becomes
even more complex when multi-ring networks with bridges are
considered.
IEEE802.5に、ネットワークには、トークンがノードが保持するかもしれない最大の時のベースの最大のパケットサイズにあります。 今回はデータ合図速度とリングの上のノードの数を含む多くの要素に依存します。 ブリッジがあるマルチリングネットワークが考えられるとき、最大のパケットサイズの決断はさらに複雑になります。
Given a token-holding time of 9 milliseconds and a 4
megabit/second ring, the maximum packet size possible is 4508
octets including all octets between the access control and the FCS
inclusive.
9ミリセカンドのトークンを保持する時間と4メガビット/セカンド・リングを考えて、可能な最大のパケットサイズは包括的にアクセス制御とFCSの間のすべての八重奏を含む4508の八重奏です。
This allows 4508 - 36 (MAC header+trailer with 18 octet RIF) - 8
(LLC+SNAP header) = 4464 for the IP datagram (including the IP
header).
これは4508--36(18八重奏RIFがあるMACヘッダー+トレーラ)を許容します--IPデータグラム(IPヘッダーを含んでいる)のための8(LLC+SNAPヘッダー)=4464。
However, some current implementations are known to limit packets
to 2046 octets (allowing 2002 octets for IP). It is recommended
that all implementations support IP packets of at least 2002
octets.
しかしながら、いくつかの現在の実装がパケットを2046の八重奏(IPのための2002の八重奏を許容する)に制限するのが知られています。 すべての実装が、IPが少なくとも2002の八重奏のパケットであるとサポートするのは、お勧めです。
By convention, source routing bridges used in multi-ring 802.5
networks will not support packets larger than 8232 octets. With a
MAC header+trailer of 36 octets and the LLC+SNAP header of 8
octets, the IP datagram (including IP header) may not exceed 8188
octets.
コンベンションで、マルチリング802.5のネットワークに使用されるソースルーティングブリッジは8232の八重奏より大きいパケットをサポートしないでしょう。 36の八重奏のMACヘッダー+トレーラと8つの八重奏のLLC+SNAPヘッダーと共に、IPデータグラム(IPヘッダーを含んでいる)は8188の八重奏を超えないかもしれません。
A source routing bridge linking two rings may be configured to
2個のリングをリンクするのが構成されるかもしれないソースルーティングブリッジ
Postel & Reynolds [Page 10] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[10ページ]RFC1042IPとARP
limit the size of packets forwarded to 552 octets, with a MAC
header+trailer of 36 octets and the LLC+SNAP of 8 octets, the IP
datagram (including the IP header) may be limited to 508 octets.
This is less that the default IP MTU of 576 octets, and may cause
significant performance problems due to excessive datagram
fragmentation. An implementation is not required to support an
MTU of less than 576 octets, although it is suggest that the MTU
be a user-configurable parameter to allow for it.
パケットのサイズが552の八重奏に送った限界、36の八重奏のMACヘッダー+トレーラと8つの八重奏のLLC+SNAPと共に、IPデータグラム(IPヘッダーを含んでいる)は508の八重奏に制限されるかもしれません。 これが、より少ない、それ、576の八重奏のデフォルトIP MTU、過度のデータグラム断片化による原因の重要な性能問題はそうするかもしれません。 実装は576未満の八重奏のMTUをサポートするのに必要ではありません、それがそれを考慮するためにMTUがユーザ構成可能なパラメタであると示唆することですが。
IEEE 802.5 networks support three different types of broadcasts.
All-Stations broadcasts are sent with no RIF or with the Broadcast
Indicators set to 0 and no Routing Designators, and are copied
once by all stations on the local ring. All-Routes broadcasts are
sent with the corresponding Broadcast Indicators and result in
multiple copies equal to the number of distinct non-repeating
routes a packet may follow to a particular ring. Single-Route
broadcasts result in exactly one copy of a frame being received by
all stations on the multi-ring network.
IEEE802.5に、ネットワークは3つの異なったタイプの放送をサポートします。 オール駅の放送は、RIFなしで0に用意ができているBroadcast Indicatorsにもかかわらず、どんなルート設定Designatorsと共にも送られないで、一度局所環の上のすべてのステーションによってコピーされます。 パケットが特定のリングに従うかもしれない異なった非反復しているルートの数と等しい複本における対応するBroadcast Indicatorsと結果でオールRoutes放送を送ります。 ただ一つのルート放送はまさにマルチリングネットワークのすべてのステーションによって受け取られるフレームのコピー1部をもたらします。
The dynamic address discovery procedure is to broadcast an ARP
request. To limit the number of all rings broadcasts to a
minimum, it is desirable (though not required) that an ARP request
first be sent as an all-stations broadcast, without a Routing
Information Field (RIF). If the all-stations (local ring)
broadcast is not supported or if the all-stations broadcast is
unsuccessful after some reasonable time has elapsed, then send the
ARP request as an all-routes or single-route broadcast with an
empty RIF (no routing designators). An all-routes broadcast is
preferable since it yields an amount of fault tolerance. In an
environment with multiple redundant bridges, all-routes broadcast
allows operation in spite of spanning-tree bridge failures.
However, single-route broadcasts may be used if IP and ARP must
use the same broadcast method.
ダイナミックなアドレス発見手順はARP要求を放送することです。 最初にオールステーション放送としてARP要求を送るのはすべてのリングの数を制限するのが最小限に放送されるのが望ましいです(必要ではありませんが)、経路情報Field(RIF)なしで。 オールステーション(局所環)放送がサポートされないか、またはいくらかの妥当な時間が経過した後にオールステーション放送が失敗しているなら、空のRIF(ルーティング指示子がない)とのオールルートかただ一つのルート放送としてARP要求を送ってください。 耐障害性の量をもたらすので、オールルート放送は望ましいです。 複数の余分なブリッジがある環境で、スパニングツリーブリッジ失敗にもかかわらず、オールルート放送は操作を許します。 しかしながら、IPとARPが同じ放送メソッドを使用しなければならないなら、ただ一つのルート放送は使用されるかもしれません。
When an ARP request or reply is received, all implementations are
required to understand frames with no RIF (local ring) and frames
with an empty RIF (also from the local ring). If the
implementation supports multi-ring source routing, then a non-
empty RIF is stored for future transmissions to the host
originating the ARP request or reply. If source routing is not
supported them all packets with non-empty RIFs should be
gracefully ignored. This policy will allow all implementations in
a single ring environment, to interoperate, whether or not they
support the multi-ring extensions.
ARP要求か回答が受信されているとき、すべての実装が、空のRIF(局所環からも)があるRIF(局所環)とフレームなしでフレームを理解するのに必要です。 実装がマルチリングソースルーティングをサポートするなら、非空のRIFは今後のトランスミッションのためにARP要求か回答を溯源するホストとして保存されます。 それらがソースルーティングにサポートされないなら、非空のRIFsがあるすべてのパケットが優雅に無視されるべきです。 この方針は共同利用するためにただ一つのリング環境におけるすべての実装を許容するでしょう、それらがマルチリング拡大をサポートするか否かに関係なく。
It is possible that when sending an ARP request via an all-routes
broadcast that multiple copies of the request will arrive at the
destination as a result of the request being forwarded by several
オールルート放送を通したARP要求に要求のそんなに複数のコピーを送るとき、それが数個によって転送される要求の結果、目的地に到着するのは、可能です。
Postel & Reynolds [Page 11] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[11ページ]RFC1042IPとARP
bridges. However, these "copies" will have taken different routes
so the contents of the RIF will differ. An implementation of ARP
in this context must determine which of these "copies" to use and
to ignore the others. There are three obvious and legal
strategies: (1) take the first and ignore the rest (that is, once
you have an entry in the ARP cache don't change it), (2) take the
last, (that is, always up date the ARP cache with the latest ARP
message), or (3) take the one with the shortest path, (that is,
replace the ARP cache information with the latest ARP message data
if it is a shorter route). Since there is no problem of
incompatibility for interworking of different implementations if
different strategies are chosen, the choice is up to each
implementor. The recipient of the ARP request must send an ARP
reply as a point to point message using the RIF information.
ブリッジ。 しかしながら、これらの「コピー」が異なったルートを取ってしまうだろうので、RIFのコンテンツは異なるでしょう。 ARPの実装は、これらの「コピー」のどれを使用して、無視したらよいかをこのような関係においては決定しなければなりません。他のもの。 3つの明白で法的な戦略があります: (1) (2) (3) 1番目を取ってくださいといって、残りを無視するか(すなわち、ARPキャッシュにおけるエントリーがいったんあると、それを変えないでください)、最終、(すなわち、いつもARPが最新のARPメッセージでキャッシュする上の日付)を取るか、または最短パスがあるもので取ってください、(すなわち、それがいっそう早く行けるルートであるならARPキャッシュ情報を最新のARPメッセージデータに取り替えます。) 異なった戦略が選ばれているなら異なった実装を織り込む不一致の問題が全くないので、選択は各作成者次第です。 ARP要求の受取人は、RIF情報を使用することでメッセージを指すためにポイントとしてARP回答を送らなければなりません。
The RIF information should be kept distinct from the ARP table.
That is, there is, in principle, the ARP table to map from IP
addresses to 802 48-bit addresses, and the RIF table to map from
those to 802.5 source routes, if necessary. In practical
implementations it may be convenient to store the ARP and RIF
information together.
RIF情報はARPテーブルと異なるように保たれるべきです。 すなわち、原則として、必要なら、それらから802.5ソースまでルートを写像するために802の48ビットのアドレス、およびIPアドレスからRIFテーブルまで写像するARPテーブルがあります。 実用的な実装では、ARPとRIF情報を一緒に保存するのは便利であるかもしれません。
Storing the information together may speed up access to the
information when it is used. On the other hand, in a
generalized implementation for all types of 802 networks a
significant amount of memory might be wasted in an ARP cache if
space for the RIF information were always reserved.
情報を一緒に保存すると、それがいつ使用されているかという情報へのアクセスは加速するかもしれません。 他方では、802のネットワークのすべてのタイプのための一般化された実装では、RIF情報のためのスペースがいつも予約されるなら、重要なメモリー容量はARPキャッシュで浪費されるでしょうに。
IP broadcasts (datagrams with a IP broadcast address) must be sent
as 802.5 single-route broadcasts. Unlike ARP, all-routes
broadcasts are not desirable for IP. Receiving multiple copies of
IP broadcasts would have undesirable effects on many protocols
using IP. As with ARP, when an IP packet is received, all
implementations are required to understand frames with no RIF and
frames with an empty RIF.
802.5のただ一つのルートが放送されるとき、IP放送(IP放送演説があるデータグラム)を送らなければなりません。 ARPと異なって、IPには、オールルート放送は望ましくはありません。 複本のIP放送を受けると、望ましくない影響は、IPを使用することで多くのプロトコルに与えられるでしょう。 IPパケットが受け取られているとき、すべての実装が空のRIFがあるRIFとフレームなしでフレームを理解するのにARPと共に必要であるときに。
Since current interface hardware allows only one group address,
and since the functional addresses are not globally unique, IP and
ARP do not use either of these features. Further, in the IBM
style 802.5 networks there are only 31 functional addresses
available for user definition.
現在のインタフェースハードウェアが1つのグループアドレスだけを許容して、機能アドレスがグローバルにユニークでないので、IPとARPはこれらのどちらの特徴も使用しません。 さらに、IBMスタイル802.5ネットワークには、ユーザ定義に利用可能な31の機能アドレスしかありません。
IP precedence should not be mapped to 802.5 priority. All IP and
ARP packets should be sent at the default 802.5 priority. The
default priority is 3.
IP先行を802.5優先権に写像するべきではありません。 デフォルト802.5優先権ですべてのIPとARPパケットを送るべきです。 デフォルト優先権は3です。
After packet transmission, 802.5 provides frame not copied and
address not recognized indicators. Implementations may use these
パケット伝送、802.5が認識されたインディケータではなく、コピーされなかったフレームとアドレスを提供した後に。 実装はこれらを使用するかもしれません。
Postel & Reynolds [Page 12] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[12ページ]RFC1042IPとARP
indicators to provide some amount of error detection and
correction. If the frame not copied bit is set but the address
not recognized bit is reset, receiver congestion has occurred. It
is suggested, though not required, that hosts should retransmit
the offending packet a small number of times (4) or until
congestion no longer occurs. If the address not recognized bit is
set, an implementation has 3 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.
いくらかの量の誤り検出と訂正を提供するインディケータ。 噛み付かれた状態で認識されなかったアドレスはリセットされます、そして、フレームがコピーされなかったなら、ビットは設定されますが、受信機混雑は起こりました。 それは示されます、必要ではありませんがホストが(4)か混雑まで回の怒っているパケットa少ない番号を再送するべきであるのはもう起こりません。 噛み付かれた状態で認識されなかったアドレスが設定されるなら、実装には、3つのオプションがあります: (1) (3) 誤りを無視してください、そして、遠くに、(2)が返すパケットにソースへのICMP送信不可能メッセージを投げてください、または、送付先アドレスにこのパケットを送って、新しいARP要求を送るのに使用されたARPエントリーを削除してください。 最初のホップブリッジ、ルータ失敗、および変えられたハードウェア・アドレスからの優雅な回復を許すので、後者のオプションは好ましい方法です。
Interoperation with Ethernet
イーサネットがあるInteroperation
It is possible to use the Ethernet link level protocol [12] on the same physical cable with the IEEE 802.3 link level protocol. A computer interfaced to a physical cable used in this way could potentially read both Ethernet and 802.3 packets from the network. If a computer does read both types of packets, it must keep track of which link protocol was used with each other computer on the network and use the proper link protocol when sending packets.
同じ物理ケーブルの上でIEEE802.3リンク・レベルプロトコルでイーサネットリンク・レベルプロトコル[12]を使用するのは可能です。 このように使用される物理ケーブルに連結されたコンピュータはネットワークからイーサネットと802.3のパケットの両方を潜在的に読むかもしれません。 コンピュータが両方のタイプのパケットを読むなら、パケットを送るとき、それは、ネットワークにどのリンク・プロトコルが互いと共に使用されたかに関する道がコンピュータであることを保って、適切なリンク・プロトコルを使用しなければなりません。
One should note that in such an environment, link level broadcast packets will not reach all the computers attached to the network, but only those using the link level protocol used for the broadcast.
そのような環境でそれに注意するべきであり、リンク・レベル放送パケットはネットワークに取り付けられたすべてのコンピュータに達するのではなく、放送に使用されるリンク・レベルプロトコルを使用するものだけに達するでしょう。
Since it must be assumed that most computers will read and send using only one type of link protocol, it is recommended that if such an environment (a network with both link protocols) is necessary, an IP gateway be used as if there were two distinct networks.
そのような環境(両方のリンク・プロトコルがあるネットワーク)が必要であるなら、ほとんどのコンピュータが1つのタイプのリンク・プロトコルだけを使用することで読んで、発信すると思わなければならなくて、それはそれに推薦されます、IPゲートウェイ。まるで2つの異なったネットワークがあるかのように、使用されます。
Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram.
802.3ネットワークが1492年の八重奏IPデータグラムだけを許容するので、MTUと共にイーサネットのためのMTUが1500年の八重奏IPデータグラムを許容することに注意してください。
Appendix on Numbers
数の付録
The IEEE likes to specify 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は、ビット伝送命令、またはビットの賢明なリトルエンディアンオーダーにおける数を指定するのが好きです。 インターネットプロトコルはバイト的なビッグエンディアンオーダーに記録されます。 これは数に使用する固有値に関して何らかの混乱を引き起こすかもしれません。 ここに、興味がある数個の数のための変換があります。
Postel & Reynolds [Page 13] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[13ページ]RFC1042IPとARP
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] 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.
[3] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスする」IEEE、ニューヨーク(ニューヨーク)1985。
[4] IEEE, "IEEE Standards for Local Area Networks: Token-Passing
Bus Access Method and Physical Layer Specification", IEEE, New
York, New York, 1985.
[4] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「トークンパッシングはアクセス法と物理的な層の仕様をバスで運ぶ」IEEE、ニューヨーク(ニューヨーク)1985。
[5] IEEE, "IEEE Standards for Local Area Networks: Token Ring
Access Method and Physical Layer Specifications", IEEE, New
York, New York, 1985.
[5] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「トークンリングはメソッドと物理的な層の仕様にアクセスする」IEEE、ニューヨーク(ニューヨーク)1985。
[6] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[6] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」、IEEE、ニューヨーク(ニューヨーク)1985。
[7] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
[7] USC/情報科学が設けるレイノルズ、J.K.、およびJ.ポステル、「規定番号」、RFC-1010は1987がそうするかもしれません。
[8] Braden, R., and J. Postel, "Requirements for Internet
Gateways", RFC-1009, USC/Information Sciences Institute, June
1987.
[8] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」RFC-1009、科学が1987年6月に設けるUSC/情報。
[9] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
University of California at Berkeley, April 1984.
[9] レフラー、S.とM.Karels、「トレーラカプセル化」、RFC-893、カリフォルニア大学バークレイ校、1984年4月。
[10] Postel, J., "The TCP Maximum Segment Size Option and Related
[10] ポステル、「TCPの最大のセグメントサイズオプションと関連」のJ.
Postel & Reynolds [Page 14] RFC 1042 IP and ARP on IEEE 802 Networks February 1988
IEEE802ネットワーク1988年2月のポステルとレイノルズ[14ページ]RFC1042IPとARP
Topics", RFC-879, USC/Information Sciences Institute, November
1983.
「話題」、USC/情報科学が1983年11月に設けるRFC-879。
[11] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
October 1981.
[11] D. コーエン、コンピュータ、IEEE、「平和のための聖戦と請願」の1981年10月。
[12] D-I-X, "The Ethernet - A Local Area Network: Data Link Layer
and Physical Layer Specifications", Digital, Intel, and Xerox,
November 1982.
[12] D-I-X、「イーサネット--ローカル・エリア・ネットワーク:、」 「データ・リンク層と物理的な層の仕様」、Digital、インテル、およびゼロックス、1982年11月。
[13] IBM, "Token-Ring Network Architecture Reference", Second
Edition, SC30-3374-01, August 1987.
[13]IBM、「トークンリングネットワークアーキテクチャ参照」、第2版、SC30-3374-01、1987年8月。
Postel & Reynolds [Page 15]
ポステルとレイノルズ[15ページ]
一覧
スポンサーリンク
