RFC1201 日本語訳
1201 Transmitting IP traffic over ARCNET networks. D. Provan. February 1991. (Format: TXT=16565 bytes) (Obsoletes RFC1051) (Also STD0046) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Provan Request for Comments: 1201 Novell, Inc. Obsoletes: RFC 1051 February 1991
Provanがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1201 ノベルInc.は以下を時代遅れにします。 RFC1051 1991年2月
Transmitting IP Traffic over ARCNET Networks
ARCNETネットワークの上にIPトラフィックを伝えます。
Status of this Memo
このMemoの状態
This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network. 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.
このメモはIPとARPパケットのトランスミッションのためにARCnetローカル・エリア・ネットワークの上でプロトコルを定義します。 このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. Introduction
1. 序論
This memo specifies a method of encapsulating Internet Protocol (IP) [1] and Address Resolution Protocol (ARP) [2] datagrams for transmission across ARCNET [3] using the "ARCNET Packet Header Definition Standard" [4]. This memo offers a replacement for RFC 1051. RFC 1051 uses an ARCNET framing protocol which limits unfragmented IP packets to 508 octets [5].
このメモはARCNETの向こう側にインターネットプロトコル(IP)[1]とAddress Resolutionプロトコル(ARP)[2]がトランスミッションのためのデータグラムであると[3] 「ARCNETパケットのヘッダー定義規格」[4]を使用することでカプセル化するメソッドを指定します。 このメモはRFC1051のために交換品を提供します。 RFC1051は非断片化しているIPパケットを508の八重奏[5]に制限するARCNET縁どりプロトコルを使用します。
2. ARCNET Packet Format
2. ARCNETパケット・フォーマット
In 1989, Apple Computers, Novell, ACTINET Systems, Standard Microsystems, and Pure Data Research agreed to use the ARCNET datalink protocol defined in "ARCNET Packet Header Definition Standard" [4]. We'll begin with a brief description of that protocol.
1989年に、アップルコンピュータ、ノベル、ACTINET Systems、Standardマイクロシステムズ、およびPure Data Researchは、「ARCNETパケットのヘッダー定義規格」[4]で定義されたARCNETデータリンクプロトコルを使用するのに同意しました。 私たちはそのプロトコルの簡単な説明で始めるつもりです。
2.1. ARCNET Framing
2.1. ARCNET縁どり
ARCNET hardware supports two types of frames: short frames, which are always 256 octets long, and long frames, which are always 512 octets long. All frames begin with a hardware header and end with the client's data preceded by a software header. Software places padding in the middle of the packet between the hardware header and the software header to make the frame the appropriate fixed length. Unbeknown to the software, the hardware removes this padding during transmission.
ARCNETハードウェアは2つのタイプのフレームを支えます: 短いフレーム、長い間、いつもどれが256の八重奏であるか、そして、および長いフレーム。(長い間、いつもそのフレームは512の八重奏です)。 クライアントのデータがソフトウェアヘッダーによって先行されている状態で、すべてのフレームがハードウェアヘッダーと終わりで始まります。 ソフトウェアは、フレームを適切な固定長にするようにハードウェアヘッダーとソフトウェアヘッダーの間のパケットの中央に詰め物を置きます。 未知に、ソフトウェアに、ハードウェアはトランスミッションの間、この詰め物を移します。
Short frames can hold from 0 to 249 octets of client data. Long frames can hold from 253 to 504 octets of client data. To handle frames with 250, 251, or 252 octets of data, the datalink protocol
短いフレームはクライアントデータの0〜249の八重奏まで持ちこたえることができます。 長いフレームはクライアントデータの253〜504の八重奏まで持ちこたえることができます。 250、251、または252でデータの八重奏、データリンクプロトコルをハンドルに縁どっています。
Provan [Page 1] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[1ページ]RFC1201IP
introduces a third frame type: the exception frame.
3番目のフレームタイプを導入します: 例外フレーム。
These three frame formats are shown here. Except as noted, each block represents one octet.
これらの3つのフレーム形式がここに示されます。 注意されるのを除いて、各ブロックは1つの八重奏を表します。
Short Frame Long Frame Exception Frame
短いフレーム長いフレーム例外フレーム
+---------------+ +---------------+ +---------------+ | source | | source | | source | +---------------+ +---------------+ +---------------+ | destination | | destination | | destination | +---------------+ +---------------+ +---------------+ | offset | | 0 | | 0 | +---------------+ +---------------+ +---------------+ . unused . | offset | | offset | . (offset - 3 . +---------------+ +---------------+ . octets) . . unused . . unused . +---------------+ . (offset - 4 . . (offset - 4 . | protocol ID | . octets) . . octets) . +---------------+ +---------------+ +---------------+ | split flag | | protocol ID | | protocol ID | +---------------+ +---------------+ +---------------+ | sequence | | split flag | | flag: FF hex | + number + +---------------+ +---------------+ | (2 octets) | | sequence | | padding: 0xFF | +---------------+ + number + +---------------+ . . | (2 octets) | | padding: 0xFF | . client data . +---------------+ +---------------+ . (256 - offset . . . | (protocol ID) | . - 4 octets) . . . +---------------+ . . . . | split flag | +---------------+ . . +---------------+ . . | sequence | . client data . + number + . (512 - offset . | (2 octets) | . - 4 octets) . +---------------+ . . . . . . . client data . . . . (512 - offset . . . . - 8 octets) . . . . . +---------------+ +---------------+
+---------------+ +---------------+ +---------------+ | ソース| | ソース| | ソース| +---------------+ +---------------+ +---------------+ | 目的地| | 目的地| | 目的地| +---------------+ +---------------+ +---------------+ | 相殺されます。| | 0 | | 0 | +---------------+ +---------------+ +---------------+ 未使用です。| 相殺されます。| | 相殺されます。| . (offset - 3 . +---------------+ +---------------+ . octets) . . 未使用である、未使用. +---------------+ (相殺してください--、4 . . 八重奏) . (相殺してください--4| ID| . 八重奏について議定書の中で述べてください)+---------------+ +---------------+ +---------------+ | 燕尾旗| | プロトコルID| | プロトコルID| +---------------+ +---------------+ +---------------+ | 系列| | 燕尾旗| | 以下に旗を揚げさせてください。 FF十六進法| + 数++---------------+ +---------------+ | (2つの八重奏) | | 系列| | 詰め物: 0xFF| +---------------+ + 数++---------------+ . . | (2つの八重奏) | | 詰め物: 0xFF| . クライアントデータ+---------------+ +---------------+、((256)…相殺される--| (プロトコルID)|、--、4つの八重奏) …+---------------+ . . . . | 燕尾旗| +---------------+ . . +---------------+ . . | 系列| . クライアントデータ+ 数+、(512--オフセット| (2つの八重奏)|、--、4つの八重奏) . +---------------+… クライアントデータ… (512--相殺してください…、--8つの八重奏) …、+---------------+ +---------------+
These packet formats are presented as software would see them through ARCNET hardware. [3] refers to this as the "buffer format". The actual format of packets on the wire is a little different: the destination ID is duplicated, the padding between
ソフトウェアがARCNETハードウェアでそれらを見るようにこれらのパケット・フォーマットは提示されます。 [3]は「バッファ形式」にこれについて言及します。 ワイヤの上のパケットの実際の形式は少し異なっています: 目的地IDがコピーされる、間の詰め物
Provan [Page 2] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[2ページ]RFC1201IP
the offset field and the protocol ID field is not transmitted, and there's some hardware framing information. In addition, the hardware transmits special packets for buffer allocation and reception acknowledgement which are not described here [3].
オフセット野原とプロトコルID野原は伝えられません、そして、何らかのハードウェア縁どり情報があります。 さらに、ハードウェアはバッファ配分とどれがあるかがここで[3]について説明しなかったというレセプション承認のために特別なパケットを伝えます。
2.2. Datalink Layer Fragmentation
2.2. データリンク層の断片化
ARCNET hardware limits individual frames to 512 octets, which allows 504 octets of client data. This ARCNET datalink protocol allows the datalink layer to break packets into as many as 120 fragments for transmission. This allows ARCNET clients to transmit up to 60,480 octets in each packet.
ARCNETハードウェアは個々のフレームを512の八重奏に制限します(クライアントデータの504の八重奏を許容します)。 このARCNETデータリンクプロトコルで、データリンク層はトランスミッションのためにパケットを最大120個の断片に細かく分けることができます。 これで、ARCNETクライアントは各パケットで最大6万480の八重奏を伝えることができます。
The "split flag" describes datalink layer packet fragments. There are three cases: an unfragmented packet, the first fragment of a fragmented packet, and any other fragment of a fragmented packet.
「燕尾旗」はデータリンク層のパケット断片について説明します。 3つのケースがあります: 非断片化しているパケット、断片化しているパケットの最初の断片、および断片化しているパケットのいかなる他の断片。
Unfragmented packets always have a split flag of zero.
Unfragmentedパケットには、ゼロの燕尾旗がいつもあります。
The first fragment of a fragmented packet has a split flag equal to ((T-2)*2)+1, where T is the total number of fragments to expect for the packet.
断片化しているパケットの最初の断片は燕尾旗が+1を((T-2)*2)との等しさにします。(そこでは、Tがパケットのために予想する断片の総数です)。
Subsequent fragments of a fragmented packet have a split flag equal to ((N-1)*2), where N is the number of this fragment. For example, the fourth fragment of a packet will always have the split flag value of six ( (4-1)*2 ).
断片化しているパケットのその後の断片には、((N-1)*2)と等しい燕尾旗があります。そこでは、Nがこの断片の数です。 例えば、パケットの4番目の断片には、6( (4-1)*2)の燕尾旗値がいつもあるでしょう。
The receiving station can identify the last fragment of a packet because the value of its 8-bit split flag will be one greater than the split flag of the first fragment of the packet.
8ビットの燕尾旗の値がパケットの最初の断片の燕尾旗よりすばらしい1つになるので、受入れステーションはパケットの最後の断片を特定できます。
A previous version of this ARCNET datalink protocol definition only allowed packets which could be contained in two fragments. In this older standard, the only legal split flags were 0, 1, and 2. Compatibility with this older standard can be maintained by configuring the maximum client data length to 1008 octets.
このARCNETデータリンクプロトコル定義の旧バージョンは2個の断片に含むことができたパケットを許容しただけです。 このより古い規格では、唯一の法的な燕尾旗が、0と、1と、2でした。 最大のクライアントデータの長さを1008の八重奏まで構成することによって、このより古い規格との互換性を維持できます。
No more that 120 fragments are allowed. The highest legal split flag value is EE hex. (Notice that the split flag value FF hex is used to flag exception packets in what would otherwise be a long packet's split flag field.)
いいえ、120が断片化する以上はそうです。許容にされる。 最も高い法的な燕尾旗値はEE十六進法です。 (燕尾旗値のFF十六進法がそうでなければ、長いパケットの燕尾旗分野であるところで例外パケットに旗を揚げさせるのに使用されるのに注意してください。)
All fragments of a single packet carry the same sequence number.
単一のパケットのすべての断片が同じ一連番号を運びます。
2.3. Datalink Layer Reassembly
2.3. データリンク層のReassembly
The previous section provides enough information to implement
前項は実装することができるくらいの情報を提供します。
Provan [Page 3] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[3ページ]RFC1201IP
datalink reassembly. To avoid buffer allocation problems during reassembly, we recommend allocating enough space for the entire reassembled packet when the first fragment arrives.
データリンク再アセンブリ。 再アセンブリの間、バッファ配分問題を避けるために、私たちは、最初の断片が届くとき、全体の組み立て直されたパケットのために十分なスペースを割り当てることを勧めます。
Since fragments are sent in order, the reassembly procedure can give up on a packet if it receives a fragment out of order. There is one exception, however. It is possible for successfully received fragments to be retransmitted. Reassembly software should ignore repetitious fragments without giving up on the packet.
整然とした状態で断片を送るので、故障していた状態で断片を受けるなら、再アセンブリ手順はパケットに見切りをつけることができます。 しかしながら、1つの例外があります。首尾よく受け取られた断片が再送されるのは、可能です。 パケットに見切りをつけないで、Reassemblyソフトウェアは反復性の断片を無視するはずです。
Since fragments will be sent briskly, the reassembly procedure can give up on a partially reassembled packet if no additional fragments for it arrive within a few seconds.
元気よく断片を送るので、それのためのどんな追加断片も数秒以内に届かないなら、再アセンブリ手順は部分的に組み立て直されたパケットに見切りをつけることができます。
2.4. Datalink Layer Retransmission
2.4. データリンク層のRetransmission
For each unicast ARCNET packet, the hardware indicates to the sender whether or not the receiver acknowledged the packet. To improve reliability, datalink implementations are encouraged to retransmit unacknowledged packets or packet fragments. Several retransmissions may be necessary. Broadcast packets, however, are never acknowledged and, therefore, they should never be retransmitted.
それぞれのユニキャストARCNETパケットに関しては、ハードウェアは、受信機がパケットを承認したかどうかを送付者に示します。 信頼性を改良するために、データリンク実装が不承認のパケットかパケット断片を再送するよう奨励されます。 数個の「再-トランスミッション」が必要であるかもしれません。 しかしながら、放送パケットは決して承認されません、そして、したがって、それらは決して再送されるべきではありません。
Packets which are successfully received may not be successfully acknowledged. Consequently, retransmission by the datalink implementation can cause duplicate packets or duplicate fragments. Duplicate packets are not a problem for IP or ARP. As mentioned in the previous section, ARCNET reassembly support should ignore any redundant fragments.
首尾よく受け取られるパケットは首尾よく承認されないかもしれません。 その結果、データリンク実装による「再-トランスミッション」は、写しパケットを引き起こすか、または断片をコピーできます。 写しパケットはIPかARPのための問題ではありません。 前項で言及されるように、ARCNET reassemblyサポートはどんな余分な断片も無視するべきです。
3. Transmitting IP and ARP Datagrams
3. IPとARPデータグラムを伝えます。
IP and ARP datagrams are carried in the client data area of ARCNET packets. Datalink support places each datagram in an appropriate size ARCNET frame, fragmenting IP datagrams larger than 504 octets into multiple frames as described in the previous section.
IPとARPデータグラムはARCNETパケットのクライアントデータ領域で運ばれます。 データリンクサポートは適切なサイズARCNETフレームに各データグラムを置きます、前項で説明されるように504の八重奏より複数のフレームに大きいIPデータグラムを断片化して。
4. IP Address Mappings
4. IPアドレス・マッピング
This section explains how each of the three basic 32-bit internet address types are mapped to 8-bit ARCNET addresses.
このセクションは3人の32ビットのタイプの基本的なインターネットアドレス各人がどう8ビットのARCNETアドレスに写像されるかを説明します。
4.1. Unicast Addresses
4.1. ユニキャストアドレス
A unicast IP address is mapped to an 8-bit ARCNET address using ARP as specified in [2]. A later section covers the specific values which should be used in ARP packets sent on ARCNET networks.
ユニキャストIPアドレスは、[2]の指定されるとしてのARPを使用することで8ビットのARCNETアドレスに写像されます。 後のセクションはARCNETネットワークで送られたARPパケットで使用されるべきである特定の値をカバーします。
Provan [Page 4] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[4ページ]RFC1201IP
It is possible to assign IP addresses such that the last eight bits are the same as the 8-bit ARCNET address. This would allow direct mapping of IP address to ARCNET address without using a discovery protocol. Some implementations might provide this as an option, but it is not recommended practice. Although such hard- wired mapping is initially appealing, experience shows that ARP is a much more flexible and convenient approach which has a very small cost.
IPアドレスを割り当てるのが可能であるので、ベストエイトビットは8ビットのARCNETアドレスと同じです。 発見プロトコルを使用しないで、これはIPアドレスのダイレクトマッピングをARCNETアドレスに許容するでしょう。 いくつかの実装がオプションとしてこれを提供するかもしれませんが、習慣はそれに推薦されません。 そのような確実なワイヤードなマッピングは初めは、魅力的ですが、経験は、ARPが非常にわずかな費用を持っているはるかにフレキシブルで便利なアプローチであることを示します。
4.2. Broadcast Addresses
4.2. 放送演説
All IP broadcast addresses must be mapped to the ARCNET broadcast address of 0.
すべてのIP放送演説を0のARCNET放送演説に写像しなければなりません。
Unlike unicast packets, ARCNET does not attempt to insure delivery of broadcast packets, so they may be lost. This will not have a major impact on IP since neither IP nor ARP expect all packets to be delivered.
ユニキャストパケットと異なって、ARCNETが、放送パケットの配送を保障するのを試みないので、それらは失われるかもしれません。 IPもARPも、すべてのパケットが提供されると予想しないので、これはIPに強い影響を持たないでしょう。
4.3. Multicast Addresses
4.3. マルチキャストアドレス
Since ARCNET provides no support for multicasts, all IP multicast addresses must be mapped to the ARCNET broadcast address of 0.
ARCNETがマルチキャストのサポートを全く提供しないので、すべてのIPマルチキャストアドレスを0のARCNET放送演説に写像しなければなりません。
5. ARP
5. アルプ
The hardware address length is 1 octet for ARP packets sent over ARCNET networks. The ARP hardware type for ARCNET is 7. ARP request packets are broadcast by directing them to ARCNET broadcast address, which is 0.
ハードウェア・アドレスの長さはARCNETネットワークの上に送られたARPパケットのための1つの八重奏です。 ARCNETのためのARPハードウェアタイプは7歳です。 ARPリクエスト・パケットは、ARCNET放送演説にそれらを向けることによって、放送されます。(放送演説は0です)。
6. RARP
6. RARP
Reverse Address Resolution Protocol [6] packets can also be transmitted over ARCNET. For the purposes of datalink transmission and reception, RARP is identical to ARP and can be handled the same way. There are a few differences to notice, however, between RARP when running over ARCNET, which has a one octet hardware address, and Ethernet, which has a six octet hardware address.
また、逆アドレス解決プロトコル[6]パケットをARCNETの上に伝えることができます。 データリンク送信とレセプションの目的のために、RARPはARPと同じであり、同じように扱うことができます。 1つの八重奏ハードウェア・アドレスを持っているARCNETとイーサネット(6八重奏ハードウェア・アドレスがある)をひくとき、しかしながら、RARPの間で気付くように、いくつかの違いがあります。
First, there are only 255 different hardware addresses for any given ARCNET while there's an very large number of possible Ethernet addresses. Second, ARCNET hardware addresses are more likely to be duplicated on different ARCNET networks; Ethernet hardware addresses will normally be globally unique. Third, an ARCNET hardware address is not as constant as an Ethernet address: ARCNET hardware addresses are set by switches, not fixed in ROM as they are on Ethernet.
まず最初に、非常に多くの可能なイーサネット・アドレスがありますが、ARCNETを考えて、いずれのための255の異なったハードウェア・アドレスしかありません。 2番目に、異なったARCNETネットワークでは、ARCNETハードウェア・アドレスは、よりコピーされそうです。 通常、イーサネットハードウェア・アドレスはグローバルにユニークになるでしょう。 3番目に、ARCNETハードウェア・アドレスはイーサネット・アドレスほど一定ではありません: ARCNETハードウェア・アドレスはそれらがイーサネットにあるのでROMで修理されているのではなく、スイッチによって設定されます。
Provan [Page 5] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[5ページ]RFC1201IP
7. Maximum Transmission Unit
7. マキシマム・トランスミッション・ユニット
The maximum IP packet length possible using this encapsulation method is 60,480 octets. Since this length is impractical, all ARCNET implementations on a given ARCNET network will need to agree on a smaller value. Therefore, the maximum packet size MUST be configurable in implementations of this specification.
このカプセル化メソッドを使用する可能な最大のIPパケット長は6万480の八重奏です。 この長さが非実用的であるので、与えられたARCNETネットワークのすべてのARCNET実装が、より小さい値に同意する必要があるでしょう。 したがって、最大のパケットサイズはこの仕様の実装で構成可能であるに違いありません。
In any case, implementations must be able to send and receive IP datagrams up to 576 octets in length, and are strongly encouraged to handle IP datagrams up to 1500 octets in length.
どのような場合でも、IPデータグラムを送って、長さにおける576の八重奏まで受け取ることができなければならなくて、実装は、IPデータグラムを長さにおける1500の八重奏まで扱うよう強く奨励されます。
Implementations may accept arriving IP datagrams which are larger than their configured maximum transmission unit. They are not required to discard such datagrams.
実装はそれらの構成されたマキシマム・トランスミッション・ユニットより大きい到着しているIPデータグラムを受け入れるかもしれません。 彼らはそのようなデータグラムを捨てる必要はありません。
To minimize the amount of ARCNET fragmentation, implementations may want to aim at an optimum IP packet size of 504 bytes. This avoids the overhead of datalink fragmentation, but at the expense of increasing the number of IP packets which must be handled by each node in the path. In addition to encouraging local applications to generate smaller packets, an implementation might also use the TCP maximum segment size option to indicate a desire for 464 octet TCP segments [7], or it might announce an IP MTU of 504 octets through an MTU discovery mechanism such as [8]. These would inform non- ARCNET nodes of the smaller optimum packet size.
ARCNET断片化の量を最小にするために、実装は504バイトの最適なIPパケットサイズを目的としたがっているかもしれません。 データリンク断片化にもかかわらず、経路の各ノードで扱わなければならないIPパケットについて数を増やすことを犠牲にしてこれはオーバーヘッドを避けます。 また、局所塗布が、より小さいパケットを生成するよう奨励することに加えて、実装が464の八重奏TCPセグメント[7]に関する願望を示すのにTCPの最大のセグメントサイズオプションを使用するかもしれませんか、またはそれは[8]などのMTU発見メカニズムを通して504の八重奏のIP MTUを発表するかもしれません。 これらは、より小さい最適なパケットサイズの非ARCNETのノードを知らせるでしょう。
8. Assigned Numbers
8. 規定番号
Datapoint Corporation assigns ARCNET protocol IDs to identify different protocols running on the same ARCNET medium. For implementations of this specification, Datapoint has assigned 212 decimal to IP, 213 decimal to ARP, and 214 decimal to RARP. These are not the numbers assigned to the IP encapsulation defined by RFC 1051 [5]. Implementations of RFC 1051 can exist on the same ARCNET as implementations of this specification, although the two would not be able to communicate with each other.
Datapoint社は、同じARCNET媒体で動く異なったプロトコルを特定するためにプロトコルIDをARCNETに割り当てます。 この仕様の実装のために、DatapointはIPへの212小数、ARPへの213小数、およびRARPへの214小数を割り当てました。 これらはRFC1051[5]によって定義されたIPカプセル化に割り当てられた数ではありません。 RFC1051の実装はこの仕様の実装と同じARCNETに存在できます、2が互いにコミュニケートできないでしょうが。
The Internet Assigned Numbers Authority (IANA) assigns ARP hardware type values. It has assigned ARCNET the ARP hardware type of 7 [9].
インターネットAssigned民数記Authority(IANA)はハードウェアタイプ値をARPに割り当てます。 それは7[9]のARPハードウェアタイプをARCNETに選任しました。
Acknowledgements
承認
Several people have reviewed this specification and provided useful input. I'd like to thank Wesley Hardell at Datapoint and Troy Thomas at Novell's Provo office for helping me figure out ARCNET. In addition, I particularly appreciate the effort by James VanBokkelen at FTP Software who picked on me until all the fuzzy edges were
数人は、この仕様を再検討して、役に立つ入力を提供しました。 私がARCNETを見積もるのを助けて頂いて、ノベルのプロボオフィスでDatapointとトロイトーマスでウエスリーHardellに感謝申し上げます。 さらに、すべてのあいまいな縁が深く感謝致すまで、ジェームスVanBokkelenは私をいじめたFTP Softwareで取り組みに深く感謝致します。
Provan [Page 6] RFC 1201 IP on ARCNET February 1991
ARCNET1991年2月のProvan[6ページ]RFC1201IP
smoothed out.
取り除かれます。
The pioneering work in transmitting IP traffic on ARCNET networks was done by Philippe Prindeville.
ARCNETネットワークでIPトラフィックを伝えることにおける先導的仕事がフィリップPrindevilleによって行われました。
References
参照
[1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、RFC791、DARPA、1981年9月。
[2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT, November 1982.
[2] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC826、MIT、1982年11月。
[3] Datapoint, Corp., "ARCNET Designer's Handbook", Document Number 61610, 2nd Edition, Datapoint Corporation, 1988.
[3] 社、「ARCNETデザイナーのハンドブック」というDatapointはNo.61610、第2版、Datapoint社、1988を記録します。
[4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell, Inc., November 1989.
[4]ノベルInc.、「ARCNETパケットのヘッダー定義規格」、ノベルInc.、1989年11月。
[5] Prindeville, P., "A Standard for the Transmission of IP Datagrams and ARP Packets over ARCNET Networks", RFC 1051, McGill University, March 1988.
[5]Prindeville、P.、「ARCNETネットワークの上のIPデータグラムとARPパケットのトランスミッションの規格」、RFC1051、マギル大学(1988年3月)。
[6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984.
[6] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」RFC903、スタンフォード、1984年6月。
[7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, September 1981.
[7] ポステル、J.、「通信制御プロトコル」、RFC793、DARPA、1981年9月。
[8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988.
[8] ムガール人とJ.とケントとC.とヤマウズラ、C.とK.McCloghrie、「IP MTU発見オプション」、RFC1063、1988年12月、BBN、TWG、7月。
[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
[9] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131
Driveサンノゼ、ドンProvanノベルInc.2180Fortuneカリフォルニア 95131
Phone: (408) 473-8440 EMail: donp@Novell.Com
以下に電話をしてください。 (408) 473-8440 メールしてください: donp@Novell.Com
Provan [Page 7]
Provan[7ページ]
一覧
スポンサーリンク