RFC1051 日本語訳

1051 Standard for the transmission of IP datagrams and ARP packetsover ARCNET networks. P.A. Prindeville. March 1988. (Format: TXT=7779 bytes) (Obsoleted by RFC1201) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                    P. Prindeville
Request for Comments:  1051                           McGill University
                                                             March 1988

Prindevilleがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1051 1988年のマギル大学行進

            A Standard for the Transmission of IP Datagrams
                  and ARP Packets over ARCNET Networks

ARCNETネットワークの上のIPデータグラムとARPパケットのトランスミッションの規格

Status of this Memo

このMemoの状態

   This RFC specifies a standard protocol for the Internet community.
   Distribution of this memo is unlimited.

このRFCはインターネットコミュニティに標準プロトコルを指定します。 このメモの分配は無制限です。

Introduction

序論

   This RFC specifies a standard method of encapsulating Internet
   Protocol (IP) [1] and Address Resolution Protocol (ARP) [2] datagrams
   on an ARCNET [3].

このRFCはARCNET[3]でインターネットプロトコル(IP)[1]とAddress Resolutionプロトコル(ARP)[2]がデータグラムであるとカプセル化する標準方法を指定します。

Acknowledgements

承認

   The author wishes to express thanks to Robert Craig of the McGill
   University Computing Centre and Bruce Hughes of Datapoint Corporation
   for their generous support of facilities and information.  I also
   extend my gratitude to the readers of the PCIP mailing list for their
   helpful ideas and comments.

作者はマギル大学Computing Centreのロバート・クレイグとDatapointのブルース・ヒューズのおかげで彼らの施設と情報の寛大なサポートのために社を言い表したがっています。 また、私は彼らの役立っている考えとコメントのためのPCIPメーリングリストの読者に感謝します。

Frame Format

フレーム形式

   IP and ARP datagrams are transmitted in standard ARCNET packets.  As
   required by Datapoint Corporation, the first octet of the data field
   is reserved for the network layer protocol identification (the
   "system code" in Datapoint nomenclature), and must contain the value
   240 (F0 hex) for IP or 241 (F1 hex) for ARP.  The ARP hardware
   address type for ARCNET is 7 [9].

IPとARPデータグラムは標準のARCNETパケットで送られます。 必要に応じて、データ・フィールドの最初の八重奏は、Datapoint社で、ネットワーク層プロトコル識別(Datapoint用語体系による「システム・コード」)のために予約されて、IPのための値240(F0十六進法)かARPのための241(F1十六進法)を含まなければなりません。 ARCNETのためのARPハードウェア・アドレスタイプは7[9]です。

   ARCNET supports packet formats containing 1-253 octets of data
   (normal format) and 257-508 octets of data (extended format),
   inclusive of system code.  Note that there exists a range of data
   lengths (254-256) which are 'forbidden'.  IP packets within this
   range should be padded (with octets of zero) to meet the minimum
   extended packet size of 257 data octets.  This padding is not part of
   the IP packet and is not included in the total length field of the IP
   header.

ARCNETは、1-253 データ(正常な形式)の八重奏を含むパケット・フォーマットと257-508がデータ(拡張フォーマット)の八重奏であるとサポートします、システム・コードでは、包括的です。 '禁じられる'さまざまなデータの長さ(254-256)が存在することに注意してください。 この範囲の中のIPパケットは、257のデータ八重奏の最小の拡張パケットサイズを達成するために水増しされるべきです(ゼロの八重奏で)。 この詰め物は、IPパケットの一部でなく、またIPヘッダーの全長分野に含まれていません。

Prindeville                                                     [Page 1]

RFC 1051                  IP and ARP on ARCNET                March 1988

ARCNET行進1988のPrindeville[1ページ]RFC1051IPとARP

   On networks where some hosts do not support extended packet format,
   the IP Maximum Transmission Unit (MTU) should be set to 253, though
   implementors are encouraged to support the extended packet format
   mode of operation.

何人かのホストが拡張パケット形式をサポートしないネットワークでは、IP Maximum Transmission Unit(MTU)は253に用意ができるべきです、作成者が、拡張パケット形式が運転モードであるとサポートするよう奨励されますが。

   Because the ARCNET maximum packet length is less than the Internet
   default MTU, implementations are strongly encouraged to support IP
   level fragmentation and reassembly.  Hosts not supporting this should
   take steps to discourage others from sending fragmented packets, such
   as using the TCP Maximum Segment Size option [4].

ARCNETの最大のパケット長がインターネットデフォルトMTUより少ないので、実装が、IPがレベルの断片化と再アセンブリであるとサポートするよう強く奨励されます。 これをサポートしないホストは他のものが断片化しているパケットを送るのを思いとどまるために手を打つべきです、TCP Maximum Segment Sizeオプション[4]を使用するのなどように。

      The frame format is:

フレーム形式は以下の通りです。

                  Normal Packet               Extended Packet
                +----------------+          +----------------+
                |     ALERT*     |          |     ALERT*     |
                +----------------+          +----------------+
                |      SOH (1)   |          |      SOH (1)   |
                +----------------+          +----------------+
                |      SID       |          |      SID       |
                +----------------+          +----------------+
                |                |          |                |
                +      DID       +          +      DID       +
                |                |          |                |
                +----------------+          +----------------+
                |     COUNT      |          |      NUL (0)   |
                +----------------+          +                +
                |  SYSTEM CODE   |          |     COUNT      |
                +----------------+          +----------------+
                |                |          |  SYSTEM CODE   |
                :      DATA      :          +----------------+
                |                |          |                |
                +----------------+          :      DATA      :
                |                |          |                |
                +       CRC      +          +----------------+
                |                |          |                |
                +----------------+          +       CRC      +
                                            |                |
                                            +----------------+

正常なパケット拡張パケット+----------------+ +----------------+ | 警戒*| | 警戒*| +----------------+ +----------------+ | SOH(1)| | SOH(1)| +----------------+ +----------------+ | シド| | シド| +----------------+ +----------------+ | | | | +は+が+をした+をしました。| | | | +----------------+ +----------------+ | カウント| | NUL(0)| +----------------+ + + | システム・コード| | カウント| +----------------+ +----------------+ | | | システム・コード| : データ: +----------------+ | | | | +----------------+ : データ: | | | | + CRC++----------------+ | | | | +----------------+ + CRC+| | +----------------+

      ALERT*:      Six mark bits signifying the beginning of a frame.
      SID:         Sender's node ID.
      DID:         Receipient's node ID (repeated for reliability).
      COUNT:       Length of data and system code (one's complement).
      SYSTEM CODE: 240 for IP, 241 for ARP (decimal).
      DATA:        Is either an IP or an ARP packet, padded with NULs so
                      as to not be between 254 and 256 octets long.
      CRC:         Cyclic redundancy check (CRC-16).

警戒*: 6はフレームの始まりを意味するビットをマークします。 シド: 送付者のノードID。 しました: ReceipientのノードID(信頼性のために、繰り返されます)。 以下を数えてください。 データとシステム・コード(1の補数)の長さ。 システム・コード: 240 IP、ARP(小数)のための241のために。 データ: 254〜256の八重奏でなくなるようにNULsと共に水増しされたIPかARPパケットのどちらかが長いですか? CRC: 周期冗長検査(CRC-16)。

Prindeville                                                     [Page 2]

RFC 1051                  IP and ARP on ARCNET                March 1988

ARCNET行進1988のPrindeville[2ページ]RFC1051IPとARP

Address Mappings

アドレス・マッピング

   The mappings between 32-bit Internet addresses to 8-bit ARCNET
   addresses can be done several ways, recommended are:

推薦されて、ARCNETがされた数個が道であったかもしれないなら扱う8ビットへの32ビットのインターネット・アドレスの間のマッピングは以下の通りです。

   Host Number Extraction

ホスト番号抽出

      The easiest thing to do is to use the last eight bits of host
      number part of the Internet address as the host's node id.  This
      has been implemented on Experimental Ethernet [5] and ProNET-10
      [6].

する中で最も簡単なことはホストのノードイドとしてインターネット・アドレスのホスト番号部分のベストエイトビットを使用することです。 これはExperimentalイーサネット[5]とProNET-10[6]で実装されました。

   Dynamic Discovery

ダイナミックな発見

      Mappings between 32-bit Internet addresses and 8-bit ARCNET node
      ids could be accomplished through ARP.  Internet addresses are
      assigned arbitrarily on some Internet networks.  All
      implementations supporting ARP must have a means of disabling ARP
      and using the above Host Number Extraction method of address
      mapping so that systems may interoperate.

ARPを通して32ビットのインターネット・アドレスと8ビットのARCNETノードイドの間のマッピングを達成できました。 インターネット・アドレスはいくつかのインターネット網で任意に割り当てられます。 ARPをサポートするすべての実装がARPを無効にして、システムが共同利用できるようにアドレス・マッピングの上のHost Number Extractionメソッドを使用する手段を持たなければなりません。

      The use of ARP is optional.  However, ARP is desirable when using
      IP implementations that don't support subnetting [7], as in the
      Proxy ARP scenario [8].

ARPの使用は任意です。 しかしながら、Proxy ARPシナリオ[8]のようにサブネッティング[7]をサポートしないIP実装を使用するとき、ARPは望ましいです。

Broadcast Address

放送演説

   The broadcast Internet address (the address on the network with a
   host part of all binary ones) should be mapped to the broadcast node
   id 0.

放送インターネットアドレス(すべての2進のもののホスト部分があるネットワークに関するアドレス)は放送ノードイド0に写像されるべきです。

Prindeville                                                     [Page 3]

RFC 1051                  IP and ARP on ARCNET                March 1988

ARCNET行進1988のPrindeville[3ページ]RFC1051IPとARP

References

参照

   [1] Postel, J., "Internet Protocol", RFC-791, Network Information
       Center, SRI, September 1981.

[1] ポステル、J.、「インターネットプロトコル」、RFC-791は1981年9月にインフォメーション・センター、様をネットワークでつなぎます。

   [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC- 826,
       Network Information Center, SRI, November 1982.

[2] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC826は1982年11月にインフォメーション・センター、様をネットワークでつなぎます。

   [3] "ARCNET Designer's Handbook", Order Number 61610, Datapoint
       Corporation, 1983.

[3] No.61610、Datapoint社、1983は、「ARCNETデザイナーのハンドブック」よう命令します。

   [4] Postel, J., "The TCP Maximum Segment Size Option and Related
       Topics", RFC-879, Network Information Center, SRI, November 1983.

[4] ポステルと、J.と、「TCPの最大のセグメントサイズオプションと関連した話題」(RFC-879)は1983年11月にインフォメーション・センター、様をネットワークでつなぎます。

   [5] Postel, J., "A Standard for the Transmission of IP Datagrams over
       Experimental Ethernet Networks", RFC-895, Network Information
       Center, SRI, April 1984.

[5] ポステル、J.、「実験イーサネットネットワークの上のIPデータグラムの送信の規格」、RFC-895はインフォメーション・センターをネットワークでつなぎます、様、1984年4月。

   [6] "ProNET-10 Model p1300 IBM PC Interface System Installation and
       Programming Guide", Version 4.0, Proteon Inc., July 1986.

[6] 「ProNET-10 Model p1300IBM PC Interface System InstallationとProgrammingガイド」、バージョン4.0、Proteon Inc.、7月1986

   [7] Mogul, J. and J. Postel, "Internet Standard Subnetting
       Procedure", RFC-950, Network Information Center, SRI, October
       1984.

[7] ムガール人、J.、およびJ.ポステル(「インターネットの標準のサブネッティング手順」、RFC-950)は1984年10月にインフォメーション・センター、様をネットワークでつなぎます。

   [8] Carl-Mitchell, S. and J.S. Quarterman, "Using ARP to Implement
       Transparent Subnet Gateways", RFC-1027, Network Information
       Center, SRI, October 1987.

[8] カール-ミッチェル、S.、およびJ.S.Quarterman(「透明なサブネットがゲートウェイであると実装するのにARPを使用します」、RFC-1027)は1987年10月にインフォメーション・センター、様をネットワークでつなぎます。

   [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1010,
       Network Information Center, SRI, May 1987.

[9] レイノルズ、J.、およびJ.ポステル、「規定番号」、RFC-1010は1987年5月にインフォメーション・センター、様をネットワークでつなぎます。

Prindeville                                                     [Page 4]

Prindeville[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

lprm 印刷キュー内の印刷ジョブを取り消す

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る