RFC1044 日本語訳
1044 Internet Protocol on Network System's HYPERchannel: ProtocolSpecification. K. Hardwick, J. Lekashman. February 1988. (Format: TXT=100836 bytes) (Also STD0045) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Hardwick
Request for Comments: 1044 NSC
J. Lekashman
NASA-Ames GE
February 1988
コメントを求めるワーキンググループK.ハードウィック要求をネットワークでつないでください: 1044 NSC J.Lekashman NASA-エームズGE1988年2月
Internet Protocol on Network Systems HYPERchannel
Protocol Specification
ネットワーク・システムHYPERchannelプロトコル仕様に関するインターネットプロトコル
STATUS OF THIS MEMO
このメモの状態
The intent of this document is to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel [1] equipment. Distribution of this memo is unlimited.
このドキュメントの意図がプロトコルの完全な議論を供給することであり、テクニックは以前は、よくDoDの標準のインターネットプロトコルデータグラム(そして、関連より高い平らなプロトコル)をNetwork Systems社のHYPERchannel[1]設備に埋め込んでいました。 このメモの分配は無制限です。
This document is intended for network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.
このドキュメントは既にDDNかイーサネットなどの一般的なネットワークでTCP/IPトラフィックを運ぶのに使用されるTCP/IPプロトコル群とテクニックに詳しいネットワーク立案者と作成者のために意図します。 NSC製品へのどんなすばらしい親しみも想定されません。 付録はNSC技術とプロトコルのレビューにささげられます。
At the time of this first RFC edition, the contents of this document has already been reviewed by about a dozen vendors and users active in the use of TCP/IP on HYPERchannel media. Comments and suggestions are still welcome (and implementable,) however.
この最初のRFC版時点で、このドキュメントのコンテンツは活動的なHYPERchannelメディアにおけるTCP/IPの使用でおよそ1ダースのベンダーとユーザによって既に見直されました。 しかしながら、まだコメントと提案を歓迎しています(そして、実装可能)。
Any comments or questions on this specification may be directed to:
この仕様のどんなコメントや質問による以下のことようも指示されるかもしれません。
Ken Hardwick
Director, Software Technology
Network Systems Corporation MS029
7600 Boone Avenue North
Brooklyn Park, MN 55428
社のMS029 7600ブーンアベニュー北部ブルックリン公園、ソフトウェア技術ネットワーク・システムミネソタ 55428のケンハードウィックディレクター
Phone: (612) 424-1607
以下に電話をしてください。 (612) 424-1607
John Lekashman
Nasa Ames Research Center. NAS/GE
MS 258-6
Moffett Field, CA, 94035
lekash@orville.nas.nasa.gov
ジョンLekashman Nasaエームズ研究センター。 NAS/GE MS258-6モフェット分野、カリフォルニア、94035 lekash@orville.nas.nasa.gov
Phone: (415) 694-4359
以下に電話をしてください。 (415) 694-4359
Hardwick & Lekashman [Page 1] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[1ページ]RFC1044IP
TABLE OF CONTENTS
目次
Status of this memo . . . . . . . . . . . . . . . . . . . . . . 1
Goals of this document . . . . . . . . . . . . . . . . . . . . 3
Basic HYPERchannel network messages . . . . . . . . . . . . . . 4
Basic (16-bit address) Message Proper header . . . . . . . . . 5
TO addresses and open driver architecture . . . . . . . . . . 7
Extended (32-bit address) Message Proper header . . . . . . . . 8
Address Recognition and message forwarding . . . . . . . . . . 10
32-bit message fields . . . . . . . . . . . . . . . . . . . . 12
Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . 14
このドキュメント.3のBasic HYPERchannelネットワークメッセージ. . . . . . . . . . . . . . 4Basic(16ビットのアドレス)メッセージProperヘッダー. . . . . . . . . 5TOの.1Goalsが扱うこのメモと開いているドライバーアーキテクチャの状態; .7の拡張している(32ビットのアドレス)メッセージProperヘッダー. . . . . . . . 8Address Recognitionとメッセージ推進… 10の32ビットのメッセージは.12Broadcasting. . . . . . . . . . . . . . . . . . . . . . . . . 14をさばきます。
PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 17
Basic (16-bit) Message Encapsulation . . . . . . . . . . . . 18
Compatibility with existing implementations . . . . . . . . . . 21
Extended (32-bit) Message Encapsulation . . . . . . . . . . . 24
Address Resolution Protocol . . . . . . . . . . . . . . . . . 27
Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . 31
既存の実装. . . . . . . . . . 21Extended(32ビット)メッセージEncapsulation. . . . . . . . . . . 24Address Resolutionプロトコル. . . . . . . . . . . . . . . . . 27Maximum Transmission Unit. . . . . . . . . . . . . . . . . . . 31とPROTOCOL SPECIFICATION. . . . . . . . . . . . . . . . . . . . 17Basic(16ビット)メッセージEncapsulation.18Compatibility
ADDRESS RESOLUTION . . . . . . . . . . . . . . . . . . . . . . 32
Local Address Resolution . . . . . . . . . . . . . . . . . . . 33
Configuration file format . . . . . . . . . . . . . . . . . . 34
ARP servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
Broadcast ARP . . . . . . . . . . . . . . . . . . . . . . . . 36
ADDRESS RESOLUTION. . . . . . . . . . . . . . . . . . . . . . 32Local Address Resolution. . . . . . . . . . . . . . . . . . . 33Configuration.34のファイル形式ARPサーバ. . . . . . . . . . . . . . . . . . . . . . . . . 35Broadcast ARP. . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.
NSC Product Architecture and Addressing . . . . . . . . . . . . 38
付録A.NSC製品アーキテクチャとアドレシング. . . . . . . . . . . . 38
Appendix B.
Network Systems HYPERchannel protocols . . . . . . . . . . . . 42
付録B.Network Systems HYPERchannelプロトコル. . . . . . . . . . . . 42
Hardwick & Lekashman [Page 2] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[2ページ]RFC1044IP
GOALS OF THIS DOCUMENT
このドキュメントの目標
In this document, there are four major technical objectives:
本書では、4つの主要な技術的目標があります:
1. To bless a "de facto" standard for IP on HYPERchannel that has
been implemented by Tektronix, Cray, NASA Ames, and others.
We are attempting to resolve some interoperability problems with
this standard so as to minimize the changes to existing IP on
HYPERchannel software. If any ambiguities remain in the de facto
standard, we wish to assist in their resolution.
1. HYPERchannelでIPの「事実上」の規格を祝福するために、それはテクトロニクス、クレイ、NASAのエームズ、および他のものによって実装されました。 私たちは、HYPERchannelソフトウェアで既存のIPへの変化を最小にするためにこの規格に関するいくつかの相互運用性問題を解決するのを試みています。 何かあいまいさがデファクトスタンダードに残っているなら、彼らの解決を助けたいと思います。
2. To address larger networks, NSC's newer network products are
moving to a 32-bit address from the current 16-bit TO address.
This document would introduce the addressing extension to the
user community and specify how IP datagrams would work in the
new addressing mode.
2. より大きいネットワークに演説するために、NSCの、より新なネットワーク製品は現在の16ビットのTOアドレスからの32ビットのアドレスに移行しています。 このドキュメントは、アドレシング拡大をユーザーコミュニティに紹介して、IPデータグラムが新しいアドレッシング・モードでどう動作するだろうかを指定するでしょう。
3. To define an Address Resolution Protocol for HYPERchannel and
other NSC products. It is probably well known that current NSC
products do not support the broadcast modes that make ARP
particularly useful. However, many have expressed interest in
"ARP servers" at a known network address. These servers could
fade away as NSC products with broadcast capability come into
existence. Host drivers that can generate and recognize this
ARP protocol would be prepared to take advantage of it as the
pieces fall into place.
3. HYPERchannelと他のNSC製品のためにAddress Resolutionプロトコルを定義するために。 現在のNSC製品が、放送がARPを特に役に立つようにするモードであるとサポートしないのは、たぶんよく知られています。 しかしながら、多くが知られているネットワーク・アドレスの「ARPサーバ」への関心を示しました。 放送能力があるNSC製品が生まれるのに応じて、これらのサーバは消え去ることができました。 このARPプロトコルを生成して、認めることができるホストドライバーは断片がうまく収まってそれを利用する用意ができているでしょう。
4. Part of this effort is to standardize the unofficial "message
type" field that reserves byte 8 of the HYPERchannel network
message. To permit better interoperability, NSC will initiate a
"network protocol registry" where any interested party may
obtain a unique value in byte 8 (or bytes 8 and 9) for their own
public, private, commercial or proprietary protocol. Lists of
assigned protocol type numbers and their "owners" will be
periodically published by NSC and would be available to
interested parties.
4. この取り組みの一部はHYPERchannelネットワークメッセージのバイト8を予約する非公式の「メッセージタイプ」分野を標準化することです。 より良い相互運用性を可能にするために、NSCはどんな利害関係者もバイト8(または、バイト8と9)におけるユニークな値をそれら自身の公共の、そして、個人的なコマーシャルか固有のプロトコルに得るかもしれない「ネットワーク・プロトコル登録」を開始するでしょう。 割り当てられたプロトコル形式数のリストとそれらの「所有者」は、定期的にNSCによって発行されて、利害関係者にとって、利用可能でしょう。
Hardwick & Lekashman [Page 3] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[3ページ]RFC1044IP
BASIC HYPERCHANNEL NETWORK MESSAGES
基本のHYPERCHANNELネットワークメッセージ
Unlike most datagram delivery systems, the HYPERchannel network message consists of two parts:
ほとんどのデータグラム配信システムと異なって、HYPERchannelネットワークメッセージは2つの部品から成ります:
Message Proper
+--------------------+
| |
| |
| 10-64 bytes |
| |
| |
+--------------------+
メッセージ適切な+--------------------+ | | | | | 10-64バイト| | | | | +--------------------+
Associated Data
+----------------------------------------------------+
| |
| |
| |
| |
| Unlimited length |
| |
| |
| |
| |
+----------------------------------------------------+
関連データ+----------------------------------------------------+ | | | | | | | | | 無制限な長さ| | | | | | | | | +----------------------------------------------------+
The first part is a message header that can be up to 64 bytes in length. The first 10 bytes contain information required for the delivery of the entire message, and the remainder can be used by higher level protocols. The second part of the message, the "Associated Data," can be optionally included with the message proper. In most cases (transmission over HYPERchannel A trunks), the length of the associated data is literally unlimited. Others (such as HYPERchannel B or transmission within a local HYPERchannel A A400 adapter) limit the size of the Associated Data to 4K bytes. If the information sent can be contained within the Message Proper, then the Associated Data need not be sent.
最初の部分は長さが最大64バイトであるかもしれないメッセージヘッダーです。 最初の10バイトは全体のメッセージの配送に必要である情報を含んでいます、そして、より高い平らなプロトコルは残りを使用できます。 メッセージが適切な状態で任意に、「関連データ」というメッセージの第二部を含むことができます。 多くの場合(HYPERchannel Aトランクスの上のトランスミッション)、関連データの長さは文字通り無制限です。 他のもの(地方のHYPERchannel A A400アダプターの中のHYPERchannel Bかトランスミッションなどの)はAssociated Dataのサイズを4Kのバイトに制限します。 Message Properの中に送られた情報を含むことができるなら、Associated Dataを送る必要はありません。
HYPERchannel lower link protocols treat messages with and without Associated Data quite differently; "Message only" transmissions are sent using abbreviated protocols and can be queued in the receiving network adapter, thus minimizing the elapsed time needed to send and receive the messages. When associated data is provided, the HYPERchannel A adapters free their logical resources towards driving the host interface and coaxial trunks.
HYPERchannelの低いリンク・プロトコルはAssociated Dataのあるなしにかかわらずメッセージを全く異なって扱います。 「メッセージ専用」トランスミッションを簡略化されたプロトコルを使用させて、受信ネットワークアダプターに列に並ばせることができます、その結果、メッセージを送って、受け取るのに必要である経過時間を最小にします。 関連データを提供するとき、ホスト・インターフェースと同軸トランクスを運転することに向かってHYPERchannel Aアダプターはそれらの論理的なリソースを解放します。
Hardwick & Lekashman [Page 4] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[4ページ]RFC1044IP
BASIC (16-BIT ADDRESS) MESSAGE PROPER HEADER
基本的な(16ビットのアドレス)メッセージ適切なヘッダー
The first 10 bytes of the network Message Proper are examined by the network adapters to control delivery of the network message. Its format is as follows:
ネットワークMessage Properの最初の10バイトはネットワークアダプターによって調べられて、ネットワークメッセージの配送を制御します。 形式は以下の通りです:
byte Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks | |EXC|BST|A/D|
+--------------+---------------+-----------------+---+---+---+
2 | Access code |
| |
+------------------------------+-----------------------------+
4 | Physical addr of | | TO Port |
| destination adapter (TO) | | number |
+------------------------------+-----------------------------+
6 | Physical addr of source | |FROM port|
| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | |
| Available for higher level protocols |
| |
| |
+------------------------------+-----------------------------+
バイトメッセージ適切な+------------------------------+-----------------------------+ 0 | 試すトランクス| メッセージ旗| | TOトランクス| FROMトランクス| |EXC|BST|/D| +--------------+---------------+-----------------+---+---+---+ 2 | アクセスコード| | | +------------------------------+-----------------------------+ 4 | 身体検査はaddrします。| | ポートに| | 目的地アダプター(TO)| | 数| +------------------------------+-----------------------------+ 6 | ソースの物理的なaddr| |FROMポート| | アダプター(FROM)| | 数| +------------------------------+-----------------------------+ 8 | メッセージタイプ| | | +------------------------------+-----------------------------+ 10 | | | より高い平らなプロトコルに、利用可能です。| | | | | +------------------------------+-----------------------------+
TRUNKS TO TRY
試すトランクス
Consists of two four bit masks indicating which of four possible HYPERchannel A coaxial data trunks are to be used to transmit the message and to return it. If a bit in the mask is ON, then the adapter firmware will logically AND it with the mask of installed trunk interfaces and use the result as a candidate list of interfaces. Whenever one of the internal "frames" are sent to communicate with the destination adapter, the transmission hardware electronically selects the first non-busy trunk out of the list of candidates. Thus, selection of a data trunk is best performed by the adapter itself rather than by the host. "Dedicating" trunks to specific applications only makes sense in very critical real time applications such as streaming data directly from high speed overrunnable peripherals.
4の可能なHYPERchannel Aの同軸データトランクスのどれがメッセージを送って、それを返すのに使用されることになっていたらよいかを示す4ビットの2個のマスクから成ります。 ONがマスクに少しあると、アダプターファームウェアは論理的に使用になるでしょう、そして、インストールされたトランクのマスクに接続します、そして、インタフェースの候補リストとして結果を使用してください。 目的地アダプターとコミュニケートするために内部の「フレーム」の1つを送るときはいつも、トランスミッションハードウェアは候補のリストから最初の非忙しいトランクを電子的に選択します。 したがって、データトランクの選択はホストでというよりむしろアダプター自体によって最も上手に実行されます。 トランクスが特定のアプリケーションに「捧げる」であることは直接高速「過剰-腰のな-可能」周辺機器からのストリーミングのデータなどの非常に重要なリアルタイムのアプリケーションで理解できるだけです。
A second Trunk mask is provided for the receiving adapter when it sends frames back to the transmitter, as it is possible to build "asymmetric" configurations of data trunks where trunk 1 on one box
フレームを送信機に送り返すとき、2番目のTrunkマスクを受信アダプターに提供します、1のトランク1が詰め込まれるデータトランクスの「非対称」の構成を築き上げるのが可能であるときに
Hardwick & Lekashman [Page 5] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[5ページ]RFC1044IP
is connected to the trunk 3 interface of a second. Such configurations are strongly discouraged, but the addressing structure supports it if needed.
1秒のトランク3インタフェースに接続されます。 そのような構成は強くがっかりしていますが、必要であるなら、アドレシング構造はそれをサポートします。
The "trunks to try" field is only used by HYPERchannel A. To assure maximum interoperability, a value of 0xFF should be placed in this field to assure delivery over any technology. Other values should only be used if the particular site hardware is so configured to not be physically connected via those trunks.
「試すトランクス」分野はどんな技術の上の配送を保証するために置かれるべきであるA.Toが最大限のインターオペラビリティ、0xFFの値にこの分野に保証するHYPERchannelによって使用されるだけです。 特定のサイトハードウェアがそれらのトランクスを通して物理的に接続されないように構成される場合にだけ、他の値は使用されるべきです。
MESSAGE FLAGS
メッセージ旗
Contains options in message delivery. In the basic type of message, three bits are used:
メッセージ配送におけるオプションを含んでいます。 メッセージの基本型で、3ビットは使用されています:
ASSOCIATED DATA PRESENT (A/D) is ON if an Associated Data block follows the Message Proper. 0 if only a message proper is present in the network message. The value of this bit is enforced by the network adapter firmware.
Associated DataブロックがMessage Properに続くなら、ASSOCIATED DATA PRESENT(/D)はONです。 0 メッセージ自体がネットワークメッセージに存在してさえいる場合、よかったでしょう。 このビットの価値はネットワークアダプターファームウェアによって励行されます。
BURST MODE (BST) Enables a special mode for time critical transfers where a single HYPERchannel A coaxial trunk is dedicated during transmission of the network message. Not recommended for anything that won't cause peripheral device overruns if data isn't delivered once message transmission starts.
BURST MODE(BST)は時間重要な転送のためのただ一つのHYPERchannel A同軸トランクがネットワークメッセージの伝達の間に捧げられる特別なモードを可能にします。 データが一度提供されないなら周辺機超過を引き起こさない何のためにも、メッセージ送信が始まるのを推薦しませんでした。
EXCEPTION (EXC) Indicates to some channel programmed host interfaces that the message is "out of band" in some way and requires special processing.
EXCEPTION(EXC)はメッセージが「バンド」から何らかの方法で来ているプログラムされたホスト・インターフェースをチャンネルに示して、特別な処理を必要とします。
ACCESS CODE
アクセスコード/地球壊滅の警告
A feature to permit adapters to share use of a cable yet still permit an "access matrix" of which adapter boxes and physically talk to which others. Not currently in use by anyone, support is being discontinued.
アダプターがケーブルの使用を共有しますが、まだどのアダプターの「アクセス行列」箱を可能にしているか、そして、物理的にどの他のものと話すかを許可する特徴。 現在だれでも使用中でないことで、サポートは中止されています。
TO ADDRESS
アドレスに
Consists of three parts. The high order 8-bits contains the physical address of the network adapter box which is to receive the message. The low order 8-bits are interpreted in different ways depending on the nature of the receiving network adapter. If the receiving adapter has different host "ports," then the low order bits of the TO field are used to designate which interface is to receive the message. On IBM data channels, the entire "logical" TO field is interpreted as the subchannel on which the incoming data is to be presented. Parts of the logical TO field that are not interpreted by
3つの部品から成ります。 高位の8ビットはメッセージを受け取ることになっているネットワークアダプター箱の物理アドレスを含んでいます。 下位の8ビットは受信ネットワークアダプターの自然による異なった方法で解釈されます。 受信アダプターに異なったホスト「ポート」があるなら、TO分野の下位のビットはどのインタフェースを指定するかに使用されているのが、メッセージを受け取ることであるということです。 IBMのデータ・チャンネルの上では、全体の「論理的な」TO分野は提示される受信データがことであるサブチャネルとして解釈されます。 解釈されない論理的なTO分野の地域
Hardwick & Lekashman [Page 6] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[6ページ]RFC1044IP
the network adapter are passed to the host for further interpretation.
ネットワークアダプターはさらなる解釈のためにホストに渡されます。
FROM ADDRESS
アドレスから
The FROM address is not physically used during the process of transmitting a network message, but is passed through to the receiving host so that a response can be returned to the point of origin. In general, reversing the TO and FROM 16-bit address fields and the TO and FROM trunk masks can reliably return a message to its destination.
FROMアドレスは、ネットワークメッセージを送るプロセスの間物理的に使用されませんが、応答を原産地に返すことができるように受信ホストに通り抜けます。 一般に、TO、FROM16ビットのアドレス分野、TO、およびFROMトランクマスクを逆にすると、メッセージを目的地に確かに返すことができます。
MESSAGE TYPE
メッセージタイプ
The following two bytes are reserved for NSC. Users have been encouraged to put a zero in byte 8 and anything at all in byte 9 so as to not conflict with internal processing of messages by NSC firmware. In the past, this field has been loosely defined as carrying information of interest to NSC equipment carrying the message and not as a formal protocol type field. For example, 0xFF00 in bytes 8 and 9 of the message will cause the receiving adapter to "loop back" the message without delivering it to the attached host.
以下の2バイトはNSCのために予約されます。 ユーザがNSCファームウェアでメッセージの内部の処理と衝突しないようにバイト9におけるバイト8ととにかく何にでもゼロを入れるよう奨励されました。 過去に、この分野は緩く正式なプロトコルタイプ分野ではなく、メッセージを伝えながらNSC設備まで興味がある情報を運ぶと定義されました。 例えば、メッセージのバイト8と9で表現される0xFF00は、受信アダプターが付属ホストにそれを提供しないでメッセージを「輪にし返すこと」を引き起こすでしょう。
Concurrent with this document, it is NSC's intent to use both bytes 8 and 9 as a formal "protocol type" designator. Major protocols will be assigned a unique value in byte 8 that will (among good citizens) not duplicate a value generated by a different protocol. Minor protocols will have 16-bit values assigned to them so that we won't run out when 256 protocols turn up. Any interested party could obtain a protocol number or numbers by application to NSC. In this document, protocol types specific to IP protocols are assigned.
このドキュメントで同時発生であり、正式な「プロトコルタイプ」指示子として両方のバイト8と9を使用するのは、NSCの意図です。 異なったプロトコルによって生成された値をコピーしない(善良な市民の中で)バイト8におけるユニークな値は主要なプロトコルに割り当てられるでしょう。 256のプロトコルが現れるとき、小さい方のプロトコルで、私たちが走るつもりでないようにそれらに割り当てられた16ビットの値は出かけるようになるでしょう。 どんな利害関係者もNSCへのアプリケーションでプロトコル番号か数を得ることができるでしょう。 本書では、IPプロトコルに特定のプロトコルタイプは選任されます。
TO ADDRESSES AND OPEN DRIVER ARCHITECTURE
そして、アドレスに、ドライバーアーキテクチャを開いてください。
Since not all 16-bits of the TO address are used for the physical delivery of the network message, the remainder are considered "logical" in that their meaning is physically determined by host computer software or (in cases such as the FIPS data channel) by hardware in the host interface.
TOアドレスのすべての16ビットがネットワークメッセージの物理的な配送に使用されるというわけではないとき、それらの意味が物理的にハードウェア的にホストコンピュータソフトウェアか(FIPSデータなどのケースが向けるコネ)決定しているので、残りはホスト・インターフェースで「論理的である」と考えられます。
Since HYPERchannel is and will be used to support a large variety of general and special purpose protocols, it is desirable that several independent protocol servers be able to independently share the HYPERchannel network interface. The implementation of many of NSC's device drivers as well as those of other parties (such as Cray Research) support this service. Each protocol server that wishes to send or receive HYPERchannel network messages logically "connects" to a HYPERchannel device driver by specifying the complete 16-bit TO
HYPERchannelがあって、さまざまな一般的で特別な目的がプロトコルであるとサポートするのに使用されるので、いくつかの独立しているプロトコルサーバが独自にHYPERchannelネットワーク・インターフェースを共有できるのは、望ましいです。 相手(クレイリサーチなどの)のものと同様にNSCのデバイスドライバの多くの実装はこのサービスをサポートします。 HYPERchannelデバイスドライバに完全な16ビットのTOを指定することによって論理的に「接続する」というHYPERchannelネットワークメッセージを送りたいか、または受け取りたがっているそれぞれのプロトコルサーバ
Hardwick & Lekashman [Page 7] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[7ページ]RFC1044IP
address it will "own" in the sense that any network message with that TO address will be delivered to that protocol server.
それがそのTOアドレスでいずれもメッセージをネットワークでつなぐという意味で「所有している」アドレスはそのプロトコルサーバに提供されるでしょう。
The logical TO field serves a function similar to the TYPE byte in the Ethernet 802.2 message header, but differs from it in that the width of the logical TO field varies from host to host, and that no values of the logical TO address are reserved for particular protocols. On the other hand, it is possible to have several "identical" protocols (such as two independent copies of IP with different HYPERchannel addresses) sharing the same physical HYPERchannel interface. This makes NSC's addressing approach identical to the OSI concept that the protocol server to reach is embedded within the address, rather than the IP notion of addressing a "host" and identifying a server through a message type.
論理的なTO分野がイーサネットにおけるTYPEバイトと同様の機能を果たす、802.2メッセージヘッダー、ホストによって分野が変えて、論理的なTOのどんな値も扱わない論理的なTOの幅が特定のプロトコルのために予約されるという点においてそれと異なっています。 他方では、いくつかの「同じ」プロトコル(異なったHYPERchannelアドレスがあるIPの独立しているコピー2部などの)を持っているのは、同じ物理的なHYPERchannelインタフェースを共有しながら、可能です。 これで、NSCがアプローチを扱うのが達するプロトコルサーバが「ホスト」を扱って、メッセージタイプでサーバを特定するというIP概念よりむしろアドレスの中で埋め込まれているというOSI概念と同じになります。
Since the HYPERchannel header also has a "message type" field, there is some ambiguity concerning the respective roles of the message type and logical TO fields:
また、HYPERchannelヘッダーには「メッセージタイプ」分野があるので、メッセージタイプと論理的なTO分野のそれぞれの役割に関して何らかのあいまいさがあります:
o The logical TO field is always used to identify the protocol
server which will receive the message. Once a server has
specified the complete TO address for the messages it wishes to
receive, the message will not be delivered to a different
protocol server regardless of the contents of the message type
field.
o 論理的なTO分野は、メッセージを受け取るプロトコルサーバを特定するのにいつも使用されます。 サーバがいったんそれが受け取りたがっているメッセージのための完全なTOアドレスを指定すると、メッセージはメッセージタイプ分野のコンテンツにかかわらず異なったプロトコルサーバに提供されないでしょう。
o Although the "type" field cannot change the protocol server at
the final destination of the message, the type field can be used
by intermediate processes on the network to process the message
before it reaches the server destination. An obvious example is
the 0xFF00 message loopback type function, where network
processing to loop back the message results in nondelivery to
the TO address. In the future, intermediate nodes may process
"in transit" messages based on the message type only for
purposes such as security validation, aging of certain
datagrams, and network management.
o 「タイプ」分野はメッセージの最終的な目的地でプロトコルサーバを変えることができませんが、タイプ分野はネットワークの中間的プロセスによって使用されて、サーバの目的地に達する前にメッセージを処理できます。 明白な例はTOアドレスへのメッセージを輪にし返すネットワーク処理が不着損害をもたらすところの0xFF00メッセージループバックタイプ機能です。 将来的で、中間的なノードでは、あるデータグラム、およびネットワークマネージメントの年をとって、「トランジット」メッセージがメッセージに基礎づけたプロセスがセキュリティ合法化などの目的のためだけにタイプされますように。
EXTENDED (32-BIT ADDRESS) MESSAGE PROPER HEADER
拡張している(32ビットのアドレス)メッセージ適切なヘッダー
In the original days of HYPERchannel, the limitation of 256 adapter "boxes" that could be addressed in a network message was deemed sufficient as 40 or so adapters was considered a "large" network. As with the Ethernet, more recent networks have resulted in a need to address larger networks. Although a few ad hoc modes have existed to address larger HYPERchannel networks for some years, newer technologies of HYPERchannel equipment have logically extended the network message to support 32-bits of addressing, with 24 of those bits to designate a physical network adapter.
オリジナルの日のHYPERchannelでは、ネットワークメッセージで扱うことができた256アダプター「箱」の制限が40として十分であると考えられたか、またはしたがって、アダプターは「大きい」ネットワークであると考えられました。 イーサネットのように、より最近のネットワークは、より大きいネットワークに演説する必要性をもたらしました。 いくつかのアドホック・モードが数年間より大きいHYPERchannelネットワークに演説するために存在しましたが、HYPERchannel設備の、より新しい技術は、物理ネットワークアダプターを指定するためにそれらの24ビットでアドレシングの32ビットを支えるネットワークメッセージを論理的に広げました。
Hardwick & Lekashman [Page 8] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[8ページ]RFC1044IP
This 32-bit header has been designed so that existing network adapters are capable of sending and receiving these messages. Only the network bridges need the intelligence to select messages designated for them.
この32ビットのヘッダーは、これらのメッセージを送って、既存のネットワークアダプターが受け取ることができるように、設計されています。 ネットワークブリッジだけが、それらのために指定されたメッセージを選択するために知性を必要とします。
Hardwick & Lekashman [Page 9] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[9ページ]RFC1044IP
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+--------------+---------------+---+---+--+--+---+---+---+---+
2 | TO Domain # | TO Network # |
| | |
+------------------------------+-----------------------------+
4 |O| Physical addr of | | TO Port |
|N| destination adapter (TO) | | number |
+------------------------------+-----------------------------+
6 |O| Physical addr of source | |FROM port|
|N| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | FROM Domain # | FROM Network # |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | age count |
| | |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (normally 16) | (normally 16) |
+------------------------------+-----------------------------+
16 | Start of user protocol |
| bytes 16 - 64 of message proper |
| |
+------------------------------+-----------------------------+
+------------------------------+-----------------------------+ 0 | 試すトランクス| メッセージ旗| | TOトランクス| FROMトランクス|GNA|CRC| |SRC|EXC|BST|/D| +--------------+---------------+---+---+--+--+---+---+---+---+ 2 | ドメイン#に| ネットワーク#に| | | | +------------------------------+-----------------------------+ 4 |O| 身体検査はaddrします。| | ポートに| |N| 目的地アダプター(TO)| | 数| +------------------------------+-----------------------------+ 6 |O| ソースの物理的なaddr| |FROMポート| |N| アダプター(FROM)| | 数| +------------------------------+-----------------------------+ 8 | メッセージタイプ| | | +------------------------------+-----------------------------+ 10 | ドメイン#から| ネットワーク#から| | | | +------------------------------+-----------------------------+ 12 | - 予約、-| 時代カウント| | | | +------------------------------+-----------------------------+ 14 | 次のヘッダーは相殺しました。| ヘッダー終わりのオフセット| | (通常16) | (通常16) | +------------------------------+-----------------------------+ 16 | ユーザプロトコルの始まり| | メッセージ自体のバイト16--64| | | +------------------------------+-----------------------------+
Associated Data
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| |
+-----------------------------------------------------------------+
関連データ+-----------------------------------------------------------------+ | | | 基本形式でメッセージをネットワークでつないでくださいので| | | +-----------------------------------------------------------------+
ADDRESS RECOGNITION AND MESSAGE FORWARDING
アドレス認識とメッセージ推進
With the 32-bit form of addressing, NSC is keeping with the premise that the native HYPERchannel address bears a direct relation to the position of the equipment in an extended HYPERchannel network.
32ビットのフォームのアドレシングで、NSCは固有のHYPERchannelアドレスが拡張HYPERchannelネットワークで設備の位置とのダイレクト関係を持っているという前提で維持されています。
Each collection of "locally" attached NSC network adapters that are connected by coax or fiber optic cable (with the possible addition of nonselective repeaters such as the ATRn series) is considered a "network". Each network can have up to 256 directly addressable adapters attached to it which can be reached by the basic format
または、接続される「局所的に」添付のNSCネットワークアダプターの各収集、おだて、光ファイバーケーブル(ATRnシリーズなどのnonselectiveリピータの可能な追加がある)は「ネットワーク」であると考えられます。 各ネットワークは最大256個の直接アドレス可能なアダプターをそれに取り付けさせることができます(基本形式で達することができます)。
Hardwick & Lekashman [Page 10] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[10ページ]RFC1044IP
network message.
メッセージをネットワークでつないでください。
Existing bridges or "link adapters" can be programmed to become "selective repeaters" in that they can receive network messages containing a subset of network addresses send them over the bridge medium (if present) and reintroduce them on the other network. Such interconnected local area networks are considered a single network from an addressing point of view.
彼らがブリッジ媒体の上にアドレスがそれらを送るネットワークの部分集合を含むネットワークメッセージを受け取ることができるので(存在しているなら)「選択しているリピータ」になって、既存のブリッジか「リンクアダプター」がもう片方のネットワークでそれらに再紹介するようにプログラムできます。 そのようなインタコネクトされたローカル・エリア・ネットワークはアドレシング観点からのただ一つのネットワークであると考えられます。
A large NSC network can have up to 64K networks which can be complexly interconnected by network bridges and/or "backbone" networks which distribute data between other networks. To simplify the mechanics of message forwarding, the 16-bit network field is divided into two eight quantities, a "network number" identifying which network is to receive the message and a "domain number" which specifies which network of networks is the recipient.
大きいNSCネットワークはネットワークブリッジで複雑にインタコネクトされることができる最大64Kのネットワーク、そして/または、他のネットワークの間にデータを分配する「バックボーン」ネットワークを持つことができます。 メッセージ推進の整備士を簡素化するために、16ビットのネットワーク分野に分割される、2、8つの量、どのネットワークがメッセージを受け取ることになっているかを特定する「ネットワーク・ナンバー」とどのネットワークのネットワークを指定する「ドメイン番号」は受取人です。
The bridge technology adapters which move messages between networks have address recognition hardware which examines all the 24-bits in bytes 2-5 of the network message header to determine if the bridge should accept the message for forwarding. At any given instant of time in the network, each bridge will have a list of networks and domains that it should accept for forwarding to a network at the other end of the bridge. Each Adapter (Including Newer Technology host adapters) contains in address recognition hardware:
メッセージをネットワークの間に動かすブリッジ技術アダプターはブリッジが推進へのメッセージを受け入れるはずであるかどうか決定するためにすべてのネットワークのバイト2-5で表現される24ビットのメッセージヘッダーを調べるアドレス認識ハードウェアを持っています。 ネットワークにおける時間のどんな与えられた瞬間にも、各ブリッジはブリッジのもう一方の端にそれが推進のためにネットワークに受け入れるべきであるネットワークとドメインのリストを持つでしょう。 各Adapter(Newer Technologyホストアダプターを含んでいる)はアドレスに認識ハードウェアを含んでいます:
o domainmask -- a 256-bit mask of domain numbers that should be
accepted for forwarding (not local processing) by this adapter.
o MyDomain -- the value of the domain on which this host
adapter or bridge end is installed.
o NetworkMask -- a 256-bit mask of network numbers that should be
accepted for forwarding by this adapter.
o MyNetwork - the value of the network on which this host
adapter or bridge end is installed.
o AddressMask -- A 256-bit mask of the local network addresses
that should be accepted by the adapter.
o MyAddress -- the "base address" of the box, which must be
supplied in any message that is directed to control processes
within the adapter, such as a loopback message.
o domainmask--推進(ローカル処理でない)のためにこのアダプター. o MyDomainによって受け入れられるはずであるドメイン番号の256ビットのマスク--このホストアダプターかブリッジが終わるドメインの値はインストールされます。o NetworkMask--このアダプターで. o MyNetworkを進めるために受け入れられるべきであるネットワーク・ナンバーの256ビットのマスク--このホストアダプターかブリッジが終わるネットワークの値はインストールされます。. o AddressMask; アダプター. o MyAddressによって受け入れられるはずである企業内情報通信網アドレスの256ビットのマスク--制御するよう指示されるどんなメッセージでも供給しなければならない箱の「ベースアドレス」はアダプターの中に処理されます、ループバックメッセージのように。
Address recognition takes place using the algorithm:
アドレス認識はアルゴリズムを使用することで行われます:
IF Domain IN DomainMask OR
IF (Domain = MyDomain AND Network IN NetworkMask) OR
IF (Domain = MyDomain AND Network = MyNetwork AND
Address IN AddressMask) THEN accept-message
ELSE ignore-message.
ドメインはメッセージを受け入れている(ドメイン=のMyDomainとNetworkはMyNetworkとAddress IN AddressMaskと等しいです)THEN ELSEであるならMyDomainとNetwork IN NetworkMask) ORと等しいです。Domain IN DomainMask ORである、(メッセージを無視します。
Hardwick & Lekashman [Page 11] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[11ページ]RFC1044IP
This algorithm means that an adapter's hardware address recognition logic will accept any messages to the box itself, any secondary or aliased local addresses owned by the adapter, and any message directed to a remote network or domain that that particular adapter is prepared to forward.
このアルゴリズムは、アダプターのハードウェア・アドレス認識論理が箱自体、アダプターによって所有されていた、どんなセカンダリの、または、aliasedされたローカルのアドレス、およびその特定のアダプターが進めるように準備されるリモートネットワークかドメインにあてられたどんなメッセージにもどんなメッセージも受け入れることを意味します。
32-BIT MESSAGE FIELDS
32ビットのメッセージ分野
TRUNK MASK
トランクマスク
Is as in the basic network message. Messages that are to be delivered outside the immediate network should have 0xFF in this byte so that all possible trunks in intermediate networks should be tried. Locally delivered 32-bit messages may still contain specially tailored trunk masks to satisfy local delivery needs.
基本的でメッセージをネットワークでつなぐように、あります。 即座のネットワークの外で提供されることになっているメッセージがこのバイトで0xFFを持つべきであるので、中間ネットワークにおけるすべての可能なトランクスが試されるべきです。 局所的に提供された32ビットのメッセージはまだ地方の配送需要を満たす特にオーダーメイドのトランクマスクを含んでいるかもしれません。
MESSAGE FLAGS
メッセージ旗
The currently defined bits remain as before. Three new bits have been defined since that time.
現在定義されたビットは従来と同様残っています。 その時以来新しい3ビットは定義されています。
CRC (END-END MESSAGE INTEGRITY). Newer technology host adapters are capable of generating a 32-bit CRC for the entire network message as soon as it is received over the channel or bus interface from the host. This 32-bit CRC is appended to the end of the associated data block and is preserved through the entire delivery process until it is checked by the host adapter that is the ultimate recipient of the message, which removes it. This end to end integrity checking is designed to provide a high degree of assurance that data has been correctly moved through all intermediate LAN's, geographic links, and internal adapter hardware and processes.
CRC(終わり-終わりのメッセージの保全)。 ホストからそれをチャンネルかバスインタフェースの上に受け取るとすぐに、より新しい技術ホストアダプターは全体のネットワークメッセージのために32ビットのCRCを生成することができます。 それがそれを取り除くメッセージの究極の受取人であるホストアダプターによってチェックされるまで、この32ビットのCRCは関連データブロックの端まで追加されて、全体の配送過程を通して保存されます。 保全の照合を終わらせるこの終わりは、データが中間的LANのすべてのもの、地理的なリンク、内部のアダプターハードウェア、およびプロセスを通して正しく動かされたという高度合いを保証を提供するように設計されています。
SRC (SOURCE FROM ADDRESS CORRECT). This bit is provided to take advantage of the physical nature of the network address to optionally verify that the 32-bit FROM address provided in the network message is in fact the location that the message originated. If the bit is not set by the transmitting host, no particular processing occurs on the message. If the bit is set, then all intermediate adapters involved in the delivery of the message have the privilege of turning the bit off if the received message FROM address is not a TO address that would be delivered to the originator if the message were going the opposite direction.
SRC、(アドレスからのソースが修正する、) このビットは事実上、32ビットのFROMアドレスがネットワークメッセージに提供されたことを任意に確かめるのにネットワーク・アドレスの物理的な本質を利用するのが、メッセージが溯源した位置であるかどうかということです。 ビットが伝わっているホストによって設定されないなら、どんな特定の処理もメッセージに起こりません。 ビットが設定されるなら、メッセージの配送にかかわるすべての中間的アダプターが受け取られていているメッセージFROMアドレスがメッセージであるなら行くのが逆方向であるなら創始者に提供されるTOアドレスでないならビットをオフにする特権を持っています。
If the message is received by a host computer with this bit still set, then the FROM address is guaranteed correct in the sense that returning a message with TO and FROM information reversed will result in delivery of the message to the process that actually originated
ホストコンピュータでまだ設定されていたこのビットでメッセージを受け取るなら、TOとFROM情報が逆にされている状態でメッセージを返すとメッセージの配送がもたらされるという意味で実際に起因したプロセスに正しい状態でFROMアドレスを保証します。
Hardwick & Lekashman [Page 12] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[12ページ]RFC1044IP
it. By careful attention to the physical security of adapters and intermediate links between networks, a high degree of security can be built into systems that simply examine the FROM address of a message to determine the legitimacy of its associated request.
それ。 アダプターの物理的なセキュリティに関する慎重な注意とネットワークの間の中間的リンクで、単に関連要求の合法性を決定するメッセージのFROMアドレスを調べるシステムは高度合いのセキュリティに組み込むことができます。
GNA (GLOBAL NETWORK ADDRESSING). This bit ON indicates that 32-bit addressing is present in the message. When this bit is on, bytes 2-3 (Domain and Network numbers) should also be nonzero.
GNA(世界的なネットワークアドレシング)。 このビットONは、32ビットのアドレシングがメッセージに存在しているのを示します。 また、このビットがオンであるときに、バイト2-3(ドメインとNetwork番号)は非零であるべきです。
TO ADDRESS
アドレスに
Four bytes contain the TO address, which is used to deliver the network message as described in "Address Recognition and Message Forwarding" on page 8. The "logical" part of the TO address is used to designate a protocol server exactly as in the basic format network message header.
4バイトはTOアドレスを含んでいます。(それは、8ページの「アドレス認識とメッセージ推進」で説明されるようにネットワークメッセージを提供するのに使用されます)。 TOアドレスの「論理的な」部分は、まさに基本形式ネットワークメッセージヘッダーでプロトコルサーバを任じるのに使用されます。
The existing "address" field has its high order bit reserved as an outnet bit for compatibility with existing A-series network adapter equipment. Were it not for this bit, the A-series adapters would attempt to accept messages that were "passing through" the local network on their way elsewhere simply because the address field matched while the the Domain and Network numbers (ignored by the A- series adapters) were quite different.
既存の「アドレス」分野で、outnetに既存のA-シリーズネットワークアダプター設備との互換性のために噛み付いたので、高位のビットを予約します。 このビットがなければ、A-シリーズアダプターは、DomainとNetwork番号(Aシリーズアダプターで、無視される)が全く異なっていましたが、アドレス・フィールドが単に合っていたのでほかの場所を企業内情報通信網を途中に「通り抜けていた」メッセージを受け入れるのを試みるでしょう。
This "outnet" bit is used in the following way:
この"outnet"ビットは以下の方法で使用されます:
o All network adapters (of any type) in an extended set of
networks containing A-Series adapters that will ever use 32-bit
addressing must have their addresses in the range 00-7F (hex.)
o 32ビットのアドレシングを使用するA-シリーズアダプターを含む拡張セットのネットワークにおけるすべてのネットワークアダプター(どんなタイプのも)が範囲00-7Fでそれらの住所を知っていなければなりません。(魔法をかけます。)
o If a message is to be sent to a destination on a nonlocal
network and domain on such an extended network, then the
high order bit of the address field is turned on.
o メッセージがそのような拡大ネットワークの非局所的なネットワークとドメインの目的地に送ることであるなら、アドレス・フィールドの高位のビットをつけます。
o When the last bridge in the chain realizes that it is about to
forward the message to its final destination (the Domain and
Network numbers are local), then it turns the Outnet bit off.
This will result in local delivery to the destination adapter.
o チェーンにおける最後のブリッジが換金されるとき、最終的な目的地にメッセージを転送しようとしていて(DomainとNetwork番号はローカルです)、次に、Outnetを回すのは食いちぎられました。 これは目的地アダプターへの地方の配送をもたらすでしょう。
FROM ADDRESS
アドレスから
The FROM address follows the same logic as the TO address in that any message can be returned to its source by reversing the FROM and TO fields of the message. Since so many protocols examine byte 8 of the message to determine its type, the FROM field has been split so that the Domain and Network numbers extend into bytes 10-11.
FROMアドレスは、メッセージのFROMとTO分野を逆にすることによってどんなメッセージもソースに返すことができるので、TOアドレスと同じ論理に従います。 とても多くのプロトコルがタイプを決定するメッセージのバイト8を調べるので、FROM分野が分けられたので、DomainとNetwork番号はバイト10-11に広がっています。
Hardwick & Lekashman [Page 13] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[13ページ]RFC1044IP
MESSAGE TYPE
メッセージタイプ
This field (informally defined in the past) has been extended to 16- bits so that a unique value can be assigned to any present or future protocol which is layer on HYPERchannel messages for either private or public use.
個人的であるか公共の使用へのHYPERchannelメッセージの層であるどんな現在の、または、将来のプロトコルにもユニークな値を割り当てることができるようにこの分野(過去に非公式に定義される)を16ビットまで広げてあります。
AGE COUNT
時代カウント
This field serves the same purpose as the IP "time to live" in that it prevents datagrams from endlessly circulating about in an improperly configured network. Each time a 32-bit message passes through a bridge, the Age Count is decremented by one. When the result is zero, the message is discarded by the bridge.
この分野は周囲で不適切に構成されたネットワークで際限なく循環するのからのデータグラムを防ぐという点に「生きる時間」にIPと同じ目的に役立ちます。 32ビットのメッセージがブリッジを通り抜けるたびにAge Countは1つ減少します。 結果がゼロであるときに、メッセージはブリッジによって捨てられます。
NEXT HEADER OFFSET AND HEADER END OFFSET
次のヘッダーオフセットANDヘッダーエンドのときに、相殺してください。
These are used as fields to optionally provide "loose source routing", where a list of 32-bit TO addresses can be provided by the transmitter to explicitly determine the path of a message through the network. If this feature is not used, both these fields would contain the value 16 (decimal) to both indicate extra TO addresses are absent and that the beginning of protocol data following the HYPERchannel header is in byte 16.
任意に提供する野原を「ソースルーティングを発射させる」とき、これらは使用されています、送信機で32ビットのTOアドレスのリストを提供して、ネットワークを通して明らかにメッセージの経路を決定できるところで。 この特徴が使用されていないなら、これらの分野の両方が付加的なTOアドレスが欠けていて、バイト16にはHYPERchannelヘッダーに続くプロトコルデータの始まりがあるのをともに示す値16の(小数)を含んでいるでしょう。
Although it is conceivable that a HYPERchannel IP process could use this source routing capability to direct messages to hosts or gateways, this capability is not felt to be of sufficient value to IP to build it into a HYPERchannel IP protocol.
HYPERchannel IPプロセスがホストかゲートウェイにメッセージを向けるこのソースルーティング能力を使用するかもしれないのが想像できますが、この能力はIPへのそれをHYPERchannel IPプロトコルに組み込むことができるくらいの価値があると感じられません。
In the future, all higher level protocols should be able to examine Header End Offset to determine the start of the higher level protocol information.
将来、すべての、より高い平らなプロトコルが、より高い平らなプロトコル情報の始まりを決定するためにHeader End Offsetを調べることができるべきです。
BROADCASTING
放送
NSC message forwarding protocols use low level link protocols to negotiate transmission of a message to its next destination on the network. Furthermore, NSC network boxes often "fan out" so that several hosts share the same network transmission equipment as in the A400 adapter. Both these characteristics mean that providing a genuine broadcast capability is not a trivial task, and in fact no current implementations of NSC technology support a broadcast capability.
NSCメッセージ推進プロトコルは、ネットワークに関して次の目的地とメッセージの伝達を交渉するのに低い平らなリンク・プロトコルを使用します。 その上、NSCネットワーク箱は、数人のホストが同じネットワーク送信を共有するように、A400アダプターのようにしばしば設備を「四方八方に広げます」。 これらの特性の両方が、本物の放送能力を提供するのが、些細なタスクでなく、また事実上、NSC技術のどんな現在の実装も放送能力をサポートしないことを意味します。
The last several years have seen broadcast applications mature to the point where they have virtually unquestioned utility on a local and sometimes campuswide basis. Accordingly, new NSC technologies will
ここ数年は、全面散布がそれらが地方の、そして、時々campuswideなベースに関する実際には疑いのないユーティリティを持っているポイントに熟しているのを見ました。 それに従って、新しいNSC技術はそうするでしょう。
Hardwick & Lekashman [Page 14] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[14ページ]RFC1044IP
support a broadcast capability. Information on the use of this capability is included here as it is essential to the discussion of the Address Resolution Protocol later in this document.
放送が能力であるとサポートしてください。 それが後で本書ではAddress Resolutionプロトコルの議論に不可欠であるようにこの能力の使用に関する情報はここに含まれています。
Broadcast capability will be supported only with the extended (32-bit address) message format. A broadcast message will have the following general appearance:
放送能力は単に拡張している(32ビットのアドレス)メッセージ・フォーマットでサポートされるでしょう。 同報メッセージには、以下の全体的な様子があるでしょう:
byte Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+--------------+---------------+---+---+--+--+---+---+---+---+
2 | TO Domain Number | TO Network Number |
| or 0xFF | or 0xFF |
+------------------------------+-----------------------------+
4 | 0xFF | Broadcast channel number |
| | |
+------------------------------+-----------------------------+
6 |O| Physical addr of source | |FROM port|
|N| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | FROM Domain Number | FROM Network Number |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | age count |
| | |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (normally 16) | (normally 16) |
+------------------------------+-----------------------------+
16 | Start of user protocol |
| bytes 16 - 64 of message proper |
| |
+------------------------------+-----------------------------+
Associated Data
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| Maximum associated data size 1K bytes. |
| |
+-----------------------------------------------------------------+
バイトメッセージ適切な+------------------------------+-----------------------------+ 0 | 試すトランクス| メッセージ旗| | TOトランクス| FROMトランクス|GNA|CRC| |SRC|EXC|BST|/D| +--------------+---------------+---+---+--+--+---+---+---+---+ 2 | ドメイン番号に| ネットワーク・ナンバーに| | または、0xFF| または、0xFF| +------------------------------+-----------------------------+ 4 | 0xFF| 放送論理機番| | | | +------------------------------+-----------------------------+ 6 |O| ソースの物理的なaddr| |FROMポート| |N| アダプター(FROM)| | 数| +------------------------------+-----------------------------+ 8 | メッセージタイプ| | | +------------------------------+-----------------------------+ 10 | ドメイン番号から| ネットワーク・ナンバーから| | | | +------------------------------+-----------------------------+ 12 | - 予約、-| 時代カウント| | | | +------------------------------+-----------------------------+ 14 | 次のヘッダーは相殺しました。| ヘッダー終わりのオフセット| | (通常16) | (通常16) | +------------------------------+-----------------------------+ 16 | ユーザプロトコルの始まり| | メッセージ自体のバイト16--64| | | +------------------------------+-----------------------------+ 関連データ+-----------------------------------------------------------------+ | | | 基本形式でメッセージをネットワークでつないでくださいので| | 関連データのサイズの1Kの最大のバイト。 | | | +-----------------------------------------------------------------+
Hardwick & Lekashman [Page 15] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[15ページ]RFC1044IP
TRUNKS TO TRY AND MESSAGE FLAGS
試すトランクスとメッセージ旗
These fields are defined just as with a normal 32-bit message. All bits in the Message Flags field are valid with broadcast modes.
これらの分野はちょうど正常な32ビットのメッセージのように定義されます。 Message Flags分野のすべてのビットが放送モードで有効です。
BROADCAST ADDRESS
放送演説
For Domain, Network and Adapter Address fields, the value 0xFF is reserved for use by the broadcast mechanism. A value of 0xFF in the adapter address field indicates to the local network hardware that this message is to be sent to all connected network equipment on the individual network.
Domain、Network、およびAdapter Address分野において、値の0xFFは使用のために放送メカニズムによって予約されます。 アダプターアドレス・フィールドの0xFFの値は、このメッセージが個々のネットワークですべての接続ネットワーク装置に送られることであることを企業内情報通信網ハードウェアに示します。
A value of 0xFF in the network or domain fields, respectively indicates a request that the scope of the broadcast exceed the local network. The bridging link adapters will receive the broadcast message along with everyone else and will examine the "Broadcast Channel" field and their internal switches to determine if the message should be forwarded to other remote networks.
ネットワークかドメイン分野の0xFFの値、それぞれ、放送の範囲が企業内情報通信網を超えているという要求を示します。 他のリモートネットワークにメッセージを転送すると、ブリッジしているリンクアダプターは、他の人皆に伴う同報メッセージを受け取って、「放送チャンネル」分野と決定するそれらの内部のスイッチを調べるでしょう。
If the Network and Domain fields contain the local network and domain, then the broadcast message will only be broadcast within the local network. If a remote Network and Domain is specified, then the message will be delivered as a single message to the remote network and broadcast there.
NetworkとDomain分野が企業内情報通信網とドメインを含んでいると、同報メッセージは企業内情報通信網の中で放送されるだけでしょう。 リモートNetworkとDomainが指定されると、メッセージはただ一つのメッセージとしてそこでリモートネットワークと放送に提供されるでしょう。
BROADCAST CHANNEL
放送チャンネル
Since individual hosts and protocol servers generally are not interested in all broadcast messages that float about the network, a filtering mechanism is provided in the header and network adapter equipment so that only proper classes of broadcast messages are delivered to the end point.
個々のホストとプロトコルサーバが一般にネットワークを浮かばせるすべての同報メッセージに興味を持っていないので、ヘッダーとネットワークアダプター設備にフィルタリングメカニズムを提供するので、適切なクラスに関する同報メッセージだけがエンドポイントに提供されます。
Broadcast channel numbers in the range 00-0xFF will be assigned by NSC much like the "message type" field. Host protocol servers specify a specific TO address containing a channel number (such as 0xFF04) when they bind themselves to the HYPERchannel device driver. The driver and the underlying equipment will deliver only broadcast messages with the correct channel number to the protocol server. If a protocol server wishes to receive several different broadcast messages, it must bind itself to the driver several times with the desired addresses.
00-0 範囲xFFの放送論理機番は「メッセージタイプ」分野のようにNSCによって割り当てられるでしょう。 ホストプロトコルサーバはHYPERchannelデバイスドライバに誓うとき論理機番(0xFF04などの)を含む特定のTOアドレスを指定します。ドライバーと基本的な設備は適度の論理機番でプロトコルサーバに同報メッセージだけを提供するでしょう。プロトコルサーバがいくつかの異なった同報メッセージを受け取りたいなら、それは何度か必要なアドレスでドライバーに誓わなければなりません。
Link adapters that are prepared to handle multinetwork broadcast messages may be equipped with switches to determine which broadcast channels will be propagated into the next network. Since multinetwork broadcast is an arrangement that must be configured with
「マルチ-ネットワーク」同報メッセージを扱うように準備されるリンクアダプターは、どの放送チャンネルが次のネットワークに伝播されるかを決定するためにスイッチを備えるかもしれません。 「マルチ-ネットワーク」放送がそれを構成しなければならないアレンジメントであるので
Hardwick & Lekashman [Page 16] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[16ページ]RFC1044IP
care, these switches are off by default.
気にかけてください、そして、これらのスイッチはデフォルトでオフです。
FROM ADDRESS
アドレスから
The FROM address is constructed just as with a normal 32-bit network message. The Source Address Correct bit is processed just as with a normal message.
FROMアドレスはちょうど正常な32ビットのネットワークメッセージのように構成されます。 Source Address Correctビットはちょうど正常なメッセージのように処理されます。
MESSAGE TYPE
メッセージタイプ
Message type is defined as with normal messages. Presumably broadcast applications will have unique message types that are not generally found in normal messages.
メッセージタイプは正常なメッセージのように定義されます。 おそらく、全面散布には、一般に、正常なメッセージで見つけられないユニークなメッセージタイプがあるでしょう。
AGE COUNT
時代カウント
Age count is vitally important in a multinetwork broadcast as "loops" in the network can cause a great deal of activity until all the progeny of the original broadcast message die out.
オリジナルの同報メッセージのすべての子孫が死に絶えるまでネットワークにおける「輪」が大きな活動を引き起こす場合があるので、時代カウントは「マルチ-ネットワーク」放送できわめて重要です。
PROTOCOL SPECIFICATION
プロトコル仕様
This section contains information on the technique used to encapsulate IP datagrams on the HYPERchannel network message. It contains three sections to describe three protocol packagings:
このセクションはHYPERchannelネットワークメッセージでIPがデータグラムであるとカプセル化するのに使用されるテクニックの情報を含みます。 それは3つのプロトコル輸送容器について説明する3つのセクションを含みます:
o The technique used to encapsulate IP datagrams on the basic
16-bit network message. This is a de facto standard that has
been in use for several years and is documented here to make it
official.
o テクニックは、以前は基本の16ビットのネットワークメッセージでよくIPがデータグラムであるとカプセル化していました。 これは数年間使用中であり、それを公式にするようにここに記録されるデファクトスタンダードです。
o The encapsulation technique for IP datagrams on 32 bit network
messages.
o 32ビットのネットワークメッセージのIPデータグラムのためのカプセル化技術。
o The definition of an Address Resolution Protocol on
HYPERchannel.
o HYPERchannelにおけるAddress Resolutionプロトコルの定義。
Hardwick & Lekashman [Page 17] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[17ページ]RFC1044IP
BASIC (16-BIT) MESSAGE ENCAPSULATION
(16ビット)の基本的なメッセージカプセル化
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Access code 0000 |
| (no longer supported) |
+------------------------------+-----------------------------+
4 | Physical addr of | Protocol server |Dest Port|
| destination adapter | logical address | number |
+------------------------------+-----------------------------+
6 | Physical addr of | Originating | Src Port|
| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | IP on HYPERchannel | Offset to start of IP |
| type code 0x05 | header from message start |
+------------------------------+-----------------------------+
10 | IP type designator | Offset to start of IP |
| 0x34 | header from byte 12 |
+------------------------------+-----------------------------+
12 | Padding (variable length incl. zero bytes) |
| |
+------------------------------+-----------------------------+
Off | First (64-Offset) bytes of IP datagram |
| |
| |
| |
+------------------------------+-----------------------------+
Associated Data
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+
メッセージ適切な+------------------------------+-----------------------------+ 0 | 試すトランクス| メッセージ旗| | TOトランクス| FROMトランクス|GNA|CRC| |SRC|EXC|BST|/D| +------------------------------+-----------------------------+ 2 | アクセスコード0000| | (もうサポートされません) | +------------------------------+-----------------------------+ 4 | 身体検査はaddrします。| プロトコルサーバ|Destポート| | 目的地アダプター| 論理アドレス| 数| +------------------------------+-----------------------------+ 6 | 身体検査はaddrします。| 起因します。| Srcポート| | ソースアダプター| サーバアドレス| 数| +------------------------------+-----------------------------+ 8 | HYPERchannelの上のIP| IPの始まりに相殺されます。| | コード0x05をタイプしてください。| メッセージ始めからのヘッダー| +------------------------------+-----------------------------+ 10 | IPタイプ指示子| IPの始まりに相殺されます。| | 0×34| バイト12からのヘッダー| +------------------------------+-----------------------------+ 12 | (可変長inclバイトがありません)を水増しします。| | | +------------------------------+-----------------------------+ 下に| 最初に、(64によるオフセット)のバイトのIPデータグラム| | | | | | | +------------------------------+-----------------------------+ 関連データ+------------------------------+-----------------------------+ | | | IPデータグラムの残り| | | | どんな関連データもIPであるなら存在していません。| | Message Properのデータグラム発作| | | +------------------------------+-----------------------------+
TRUNK MASK
トランクマスク
From the vantage of an IP driver, any trunk mask is valid so long as it results in successful delivery of the HYPERchannel network message to its destination. There is no reason to check this field for validity on reception of the message. Specification of the Trunk Mask on output is a local affair that could be specified by the transmitting driver's address resolution tables.
IPドライバーの優位から、目的地へのHYPERchannelネットワークメッセージのうまくいっている配送をもたらす限り、どんなトランクマスクも有効です。 正当性がないかどうかメッセージのレセプションでこの分野をチェックする理由が全くありません。 出力でのTrunk Maskの仕様は伝わっているドライバーのアドレス解決テーブルで指定できた地方の事です。
Hardwick & Lekashman [Page 18] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[18ページ]RFC1044IP
MESSAGE FLAGS
メッセージ旗
No use is made of the Flags field (byte 1) other than to appropriately set the Associated Data bit. Burst Mode and the Exception bit should not be used with IP.
適切にAssociated Dataビットを設定するのを除いたFlags分野(バイト1)で無駄をします。 Modeを押し破いてください。そうすれば、IPと共にExceptionビットを使用するべきではありません。
ACCESS CODE
アクセスコード/地球壊滅の警告
Although some current implementations of IP on HYPERchannel support the access code, no one appears to be using it at the current time. Since this field is currently reserved for the use of 32-bit addresses, no value other than 0000 should be placed in this field.
HYPERchannelの上のIPのいくつかの現在の実装がアクセスコードをサポートしますが、だれも、現在の時間にそれを使用するように見えません。 この分野が現在32ビットのアドレスの使用のために予約されるので、0000以外の値を全くこの分野に置くべきではありません。
TO ADDRESS
アドレスに
The TO field is generally obtained by a local IP driver through a table lookup algorithm where a 16-bit TO address is found that corresponds to the IP address of a local host or gateway. The high order bits of the TO address of course refer to the adapter number the adapter attached to the destination host.
一般に、TO野原はローカル・ホストかゲートウェイのIPアドレスに文通する16ビットのTOアドレスが見つけられる索表アルゴリズムを通したローカルアイピードライバーによって得られます。 TOアドレスの高位のビットはもちろんアダプターがあて先ホストに愛着していたアダプター番号を示します。
The logical TO field should contain the protocol server address of the HYPERchannel IP driver for that host as determined by the host's system administrator. Many HYPERchannel TCP/IP drivers in the field today are not "open" in that any network message delivered to that host will be presumed to be an IP datagram regardless of the logical TO field; however any transmitting IP process should be capable of generating the entire 16-bit TO field in order to generate a message capable of reaching a destination IP process.
ホストのシステム管理者によって決定されるように論理的なTO分野はそのホストのためのHYPERchannel IPドライバーのプロトコルサーバアドレスを含むべきです。 そのホストに提供されたどんなネットワークメッセージも論理的なTO分野にかかわらずあえてIPデータグラムであるので、今日の分野の多くのHYPERchannel TCP/IPドライバーは「開いていません」。 しかしながら、どんな伝わっているIPプロセスも、目的地IPプロセスに達することができるメッセージを生成するために全体の16ビットのTO分野を生成することができるべきです。
The process of determining which HYPERchannel address will receive an IP datagram based on its IP address is a major topic that is covered in "Address Resolution".
どのHYPERchannelアドレスがIPアドレスに基づくIPデータグラムを受けるかを決定するプロセスは「アドレス解決」でカバーされている主要な話題です。
FROM ADDRESS
アドレスから
The FROM address is filled in with the address that the local driver expects to receive from the network, but no particular use is make of the FROM address.
FROMアドレスは地元のドライバーがネットワークから受け取ると予想するアドレスで記入されますが、どんな特定の使用もFROMアドレスの造ではありません。
MESSAGE TYPE
メッセージタイプ
Network Systems requests that a value of 5 (decimal) be placed in this byte to uniquely indicate that the network message is being used to carry IP traffic. No other well-behaved protocol using HYPERchannel should duplicate this value of 5.
ネットワークSystemsは、5(10進)の値がネットワークメッセージがIPトラフィックを運ぶのに使用されているのを唯一示すためにこのバイトに置かれるよう要求します。 HYPERchannelを使用する他のどんな品行方正のプロトコルも5のこの値をコピーするべきではありません。
Hardwick & Lekashman [Page 19] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[19ページ]RFC1044IP
Many current implementations of IP on HYPERchannel place a zero or other values in this field simply because no value was reserved for IP usage. Transmitting versions of IP should always place a 5 in this field; receiving IP's should presume a delivered message to be an IP datagram until proven otherwise regardless of the contents of the Message Type field.
単に値が全くIP用法のために予約されなかったので、HYPERchannelの上のIPの多くの現在の実装がゼロか他の値をこの分野に置きます。 IPの伝えるバージョンはいつもこの分野に5を置くべきです。 Message Type分野のコンテンツにかかわらずそうでないと立証されるまで、IPを受けるのが提供されたメッセージはあえてIPデータグラムであるべきです。
Developers should note that it is often convenient to permit reception of the value 0xFF00 in bytes 8 and 9 of the IP datagram. Transmitting a message with this value will cause it to be looped back at the destination adapter and returned to the protocol server designate in the FROM address. This permits the developer have host applications talk to others on the same host for purposes of network interface or other protocol debugging. IP HEADER OFFSET
開発者は、8と9個のIPデータグラムをバイトにおける、値の0xFF00のレセプションに可能にするのがしばしば便利であることに注意するべきです。 この値をそれが目的地アダプターで輪にされることを引き起こして、プロトコルサーバに返しているメッセージがFROMアドレスで指定する伝えること。 開発者がホストアプリケーションに何らかのネットワーク・インターフェースの目的のために同じホストに関して他のものと話させるこの許可証はデバッグについて議定書の中で述べます。 IPヘッダーオフセット
Byte 9 contains the offset to the start of the IP header within the message proper, such that the Message Proper address plus the IP header offset generates the address of the first byte of the IP header (at least on byte addressable machines.)
バイト9はメッセージ自体の中にIPヘッダーの始まりようにオフセットを含んでいます、アドレスとIPヘッダーが相殺するMessage ProperがIPヘッダーの最初のバイトのアドレスを作るように(少なくともバイトのアドレス可能なマシンの。)
This field is redundant with the offset field in byte 11, and is present for cosmetic compatibility with 32-bit implementations. On reception, the value in byte 11 should take precedence.
この分野は、バイト11におけるオフセット分野で余分であり、化粧品の互換性のために32ビットの実装について存在しています。 レセプションでは、バイト11における値は優先するべきです。
As part of the migration to larger HYPERchannel headers, this field will become significant with the 32-bit addressing format, as the length of the header is no longer 10 bytes and byte 11 is used for other purposes.
より大きいHYPERchannelヘッダーへの移行の一部として、この分野は32ビットのアドレス指定形式のために重要になるでしょう、ヘッダーの長さがもう10バイトでなく、バイト11が他の目的に使用されるとき。
IP TYPE DESIGNATOR
IPタイプ指示子
Early implementations of IP drivers on HYPERchannel wanted to leave bytes 8 and 9 alone for NSC use and place a "message type" field in later in the message. A value of 0x34 had been selected by earlier developers for reasons that are now of only historical interest. Once again, implementations should generate this value on transmission, but not check it on input, assuming that an IP datagram is present in the message.
NSCのために8と9のバイトを放っておいて欲しかったHYPERchannelの上のIPドライバーの早めの実装は、「メッセージタイプ」野原をメッセージにより遅く使用して、置きます。 0×34の値は単に現在、歴史的におもしろい理由で以前の開発者によって選択されました。 実装は、もう一度、トランスミッションのときにこの値を生成しますが、入力のときにそれをチェックするべきではありません、IPデータグラムがメッセージに存在していると仮定して。
IP HEADER OFFSET
IPヘッダーオフセット
This value is used by a number of commercial implementations of IP on HYPERchannel to align the start of the IP header within the network message. This offset is relative to byte 12 of the network message so that a value of zero indicates that the IP header begins in byte 12. This value should be both correctly generated on transmission, and always respected on input processing.
この値はHYPERchannelでIPの多くの商業実装によって使用されて、ネットワークメッセージの中でIPヘッダーの始まりを並べます。 このオフセットがネットワークメッセージのバイト12に比例しているので、ゼロの値は、IPヘッダーがバイト12で始まるのを示します。 この値は、トランスミッションのときに正しく生成されて、入力処理のときにいつも尊敬されるべきです。
Hardwick & Lekashman [Page 20] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[20ページ]RFC1044IP
The maximum permissible offset in this field is 52 indicating that the IP header begins at the start of the associated data block.
この分野での最大の許されているオフセットはIPヘッダーが関連データブロックの始めで始まるのを示す52です。
IP DATAGRAM CONTENTS
IPデータグラムコンテンツ
Beginning at the offset designated in byte 11, the IP datagram is treated as a contiguous block of data that flows from byte 63 of the message proper into the first byte of associated data, so that the entire message plus data is treated as a single contiguous block.
IPデータグラムはバイト11で指定されたオフセットから関連データの最初のバイトへのメッセージ自体のバイト63から流れるデータの隣接のブロックとして扱われます、全体のメッセージとデータが1つの隣接のブロックとして扱われるように。
If the IP header is small enough to fit within the entire network message, then only the message proper is transmitted. The length of the message proper sent should always be 64 bytes, even if the IP datagram and HYPERchannel header do not occupy all 64 bytes of the message proper.
IPヘッダーが全体のネットワークメッセージの中で合うことができるくらい小さいなら、メッセージ自体だけが送られます。 メッセージ自体の長さは発信しました。いつも64バイトであるべきです、IPデータグラムとHYPERchannelヘッダーがメッセージ自体のすべての64バイトを占領するというわけではなくても。
If the datagram flows over into the associated data, then both message and data are sent. Since a number of machines cannot send a length of data to the HYPERchannel that is an exact number of bytes (due to 16-64 bits on the channel bus,) the length of the associated data received should not be used as a guide to the length of the IP datagram -- this should be extracted from the IP header. A driver should verify, of course, that the associated data received is at least as long as is needed to hold the entire IP datagram.
データグラムが関連データに溢れ出るなら、メッセージとデータの両方を送ります。 多くのマシンがデータの長さをHYPERchannelに送ることができないので、すなわち、ガイドとして関連データの長さが受けたバイト(チャンネルの16-64ビットはバスで行く)のはっきりした数をIPデータグラムの長さに使用するべきではありません--これはIPヘッダーから抽出されるべきです。 ドライバーは、受け取られた関連データが全体のIPデータグラムを持つのに少なくとも同じくらい長いときにそのままで必要であることをもちろん確かめるべきです。
COMPATIBILITY WITH EXISTING IMPLEMENTATIONS
既存の実装との互換性
The basic format described here is clearly a compromise between several implementations of IP on HYPERchannel. Not all existing implementations are interoperable with the standard described above. Currently there are two known "families" of IP HYPERchannel drivers in existence:
ここで説明された基本形式は明確にHYPERchannelの上のIPのいくつかの実装の間の感染です。 規格が上で説明されている状態で、すべての既存の実装がどんな共同利用できるというわけではありません。 現在、現存するIP HYPERchannelドライバーの2知られている「ファミリー」があります:
THE "CRAY-NASA AMES" PROTOCOL
「クレイ-NASAのエームズ」プロトコル
This protocol is in the widest production use and has the largest number of supported drivers in existence. It is interoperable and identical with the standard described above with the sole exception that bytes 8 and 9 are set to zero by these drivers. As these bytes are ignored by most implementations of this driver, they have been assigned values to formalize the use of the message type field and to make it consistent with the 32-bit protocol.
このプロトコルには、最も広い生産使用であって、現存するサポートしているドライバーの最多数があります。 それは、バイト8と9がこれらのドライバーでゼロに合わせるように設定される唯一の例外で上で説明される規格と、共同利用できて同じです。 これらのバイトがこのドライバーのほとんどの実装によって無視されるとき、それらは、メッセージタイプ分野の使用を正式にして、それを32ビットのプロトコルと一致するようにするためには割り当てられた値です。
THE "TEKTRONIX-BERKELEY" PROTOCOL
「テクトロニクス-バークレー」プロトコル
This protocol was historically the first IP on HYPERchannel implementation developed (at Tektronix) and subsequently made its way to Berkeley and BSD UNIX. This protocol is not interoperable with
このプロトコルはHYPERchannel実装の最初のIPが歴史的に、展開して(テクトロニクスで)、次にバークレーとBSD UNIXへの道を作ったということでした。 このプロトコルは共同利用できません。
Hardwick & Lekashman [Page 21] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[21ページ]RFC1044IP
the standard described above due to several distinct differences.
いくつかの明白な差異のため上で説明された規格。
First, bytes 8 through 11 are always zero. The IP header always starts on byte 12. Comments in some of these drivers designate byte 11 as an "IP header offset" field, but apparently this value is never processed.
まず最初に、いつもバイト8〜11はゼロです。 IPヘッダーはいつもバイト12を始めます。 何人かのこれらのドライバーのコメントは「IPヘッダーオフセット」分野としてバイト11を指定しますが、明らかに、この値は決して処理されません。
The major difference (and the incompatibility) concerns the packaging of the IP datagram into the network message. Due to historical difficulties in the early 80's with the sending and receiving of very small blocks of associated data on VAXes, this protocol the takes a curious approach to the placement of the IP header and the headers of higher level protocols (such as TCP or UDP.)
主要な違い(そして、不一致)はネットワークメッセージへのIPデータグラムのパッケージに関係があります。 VAXesに関する非常にわずかなブロックの関連データでは、これが撮影について議定書の中で述べるという送受信がある80年代前半における歴史的な困難のため、IPヘッダーと、より高いことのヘッダーのプレースメントへの好奇心の強いアプローチはプロトコルを平らにします。(TCPかUDPなどの。)
o If the entire length of the IP datagram is 54 bytes or less,
it is possible to fit the entire datagram and the HYPERchannel
header in the 64 byte message proper. In this case, no
associated data is sent; only a message proper is used to carry
the data. The length of the message proper transmitted is the
exact length needed to enclose the IP datagram; no padding bytes
are sent at the end of the message.
o IPデータグラムの全長が54バイト以下であるなら、メッセージの64バイトの自体で全体のデータグラムとHYPERchannelヘッダーに合うのは可能です。 この場合、関連データを全く送りません。 メッセージ自体だけが、データを運ぶのに使用されます。 長さ、伝えられて、メッセージ自体において、IPデータグラムを同封するのに必要である正確な長さはそうです。 詰め物バイトを全くメッセージの終わりに送りません。
o If the length of the IP header is greater than 54 bytes, then:
o 次に、IPヘッダーの長さが54バイト以上であるなら:
- All higher level protocol information (TCP/UDP header and
their associated data fields) are placed in the associated
data block, with the TCP/UDP header beginning at the start
of the associated data block.
- (TCP/UDPヘッダーとそれらの関連データ分野)が関連データブロックに置かれるというTCP/UDPヘッダーが関連データブロックの始めで始まっているすべての、より高い平らなプロトコル情報。
- On transmission, the length of the message proper
transmitted is set to the length of the HYPERchannel header
plus the IP header -- it is not padded out to 64 bytes.
The length of the associated data sent should be sufficient
to accommodate the TCP/UDP header and its data fields.
- 適切な状態で通信してください。トランスミッション、長さ、伝えられているのは、HYPERchannelヘッダーとIPヘッダーの長さへのセットです--それは64バイトに広げられません。 送られた関連データの長さは、TCP/UDPヘッダーとそのデータ・フィールドを収容するために十分であるべきです。
Hardwick & Lekashman [Page 22] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[22ページ]RFC1044IP
WHICH PROTOCOL IS BEST?
どのプロトコルが最も良いですか?
In choosing which to follow, the "Cray-Ames" approach was taken for several reasons:
続くようにどれを選ぶかでは、「クレイ-エームズ」アプローチをいくつかの理由に取りました:
1. Cray Research has performed exemplary work in dealing with other
vendors to provide IP on HYPERchannel from the Cray computers to
other hosts. As a result, there are 4 or 5 vendor supported
implementations of IP on HYPERchannel that use this approach.
1. クレイリサーチはHYPERchannelでクレイコンピュータから他のホストまでIPを提供するために他のベンダーと取り引きする際に模範的仕事をしました。 その結果、4があったか、または5ベンダーはこのアプローチを使用するHYPERchannelでIPの実装をサポートしました。
2. The two part structure of the message proper has its uses when a
machine wishes to make protocol decisions before staging the
transfer of an immense block of associated data into memory.
Many network coprocessors and intelligent I/O subsystems find it
simpler to read in the entire network message before deciding
what to do with it. Arbitrarily catenating the two components
does this best and permits streaming of messages from future
technology network adapters.
2. マシンが関連データの広大なブロックの転送をメモリに上演する前にプロトコル決定をしたがっているとき、メッセージ自体の2部分構造は役に立つことがあります。 多くのネットワークコプロセッサと知的な入出力サブシステムによって、それで何をしたらよいかを決める前に全体のネットワークメッセージで読書するのが、より簡単であることがわかります。 任意に、2つのコンポーネントをcatenatingするのは、これを良くして、未来の技術ネットワークアダプターからメッセージを流れさせるのを許容します。
3. Some TCP users (mostly secure DoD sites) intend to load up IP
datagrams with optional fields in the future. The
Tektronix-Berkeley implementation has problems if the IP header
length exceeds 54 bytes.
3. TCPユーザ(ほとんど安全なDoDサイト)の中には将来IPデータグラムを任意の分野にロードするつもりである人もいます。 テクトロニクス-バークレー実装には、IPヘッダ長が54バイトを超えているなら、問題があります。
Hardwick & Lekashman [Page 23] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[23ページ]RFC1044IP
EXTENDED (32-BIT) MESSAGE ENCAPSULATION
(32ビット)の拡張メッセージカプセル化
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try |1| Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Destination Domain | Destination Network |
| Number | Number |
+------------------------------+-----------------------------+
4 |O| Physical addr of | Protocol server |Dest Port|
|N| destination adapter | logical address | number |
+------------------------------+-----------------------------+
6 |O| Physical addr of | Originating | Src Port|
|N| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | IP on HYPERchannel | Offset to start of IP |
| type code 0x06 | datagram header |
+------------------------------+-----------------------------+
10 | Source Domain Number | Source Network Number |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | Age Count |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| | (usually 16) |
+------------------------------+-----------------------------+
16 | Padding to IP header start (usually 0 bytes) |
| |
+------------------------------+-----------------------------+
Off| Entire IP datagram if datagram length <= (64-Offset) |
| |
| else first (64-Offset) bytes of IP datagram |
+------------------------------+-----------------------------+
メッセージ適切な+------------------------------+-----------------------------+ 0 | 試すトランクス|1| メッセージ旗| | TOトランクス| FROMトランクス|GNA|CRC| |SRC|EXC|BST|/D| +------------------------------+-----------------------------+ 2 | 目的地ドメイン| 送信先ネットワーク| | 数| 数| +------------------------------+-----------------------------+ 4 |O| 身体検査はaddrします。| プロトコルサーバ|Destポート| |N| 目的地アダプター| 論理アドレス| 数| +------------------------------+-----------------------------+ 6 |O| 身体検査はaddrします。| 起因します。| Srcポート| |N| ソースアダプター| サーバアドレス| 数| +------------------------------+-----------------------------+ 8 | HYPERchannelの上のIP| IPの始まりに相殺されます。| | コード0x06をタイプしてください。| データグラムヘッダー| +------------------------------+-----------------------------+ 10 | ソースドメイン番号| ソースネットワーク・ナンバー| | | | +------------------------------+-----------------------------+ 12 | - 予約、-| 時代カウント| +------------------------------+-----------------------------+ 14 | 次のヘッダーは相殺しました。| ヘッダー終わりのオフセット| | | (通常16) | +------------------------------+-----------------------------+ 16 | IPヘッダー始め(通常0バイト)にそっと歩くこと。| | | +------------------------------+-----------------------------+ 下に| 全体のIPデータグラムはデータグラムの長さの<であるなら(64オフセット)と等しいです。| | | | ほかの最初の(64によるオフセット)のバイトのIPデータグラム| +------------------------------+-----------------------------+
Associated Data
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+
関連データ+------------------------------+-----------------------------+ | | | IPデータグラムの残り| | | | どんな関連データもIPであるなら存在していません。| | Message Properのデータグラム発作| | | +------------------------------+-----------------------------+
TRUNK MASK
トランクマスク
From the vantage of an IP driver, any trunk mask is valid so long as
IPドライバーの優位から、どんなトランクマスクも長いように有効です。
Hardwick & Lekashman [Page 24] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[24ページ]RFC1044IP
it results in successful delivery of the HYPERchannel network message to its destination. There is no reason to check this field for validity on reception of the message. Specification of the Trunk Mask on output is a local affair that can be specified by the transmitting driver's address resolution tables.
それは目的地へのHYPERchannelネットワークメッセージのうまくいっている配送をもたらします。 正当性がないかどうかメッセージのレセプションでこの分野をチェックする理由が全くありません。 出力でのTrunk Maskの仕様は伝わっているドライバーのアドレス解決テーブルで指定できる地方の事です。
The use of 0xFF in this value is strongly encouraged for any message other than those using exotic trunk configurations on a single local network.
この値における0xFFの使用はただ一つの企業内情報通信網でのエキゾチックなトランク構成を使用するもの以外のどんなメッセージのためにも強く奨励されます。
MESSAGE FLAGS
メッセージ旗
Several new bits have been defined here.
新しい数ビットはここで定義されました。
EXTENDED ADDRESSING. This bit should be set ON whenever a 32-bit address (Network and/or Domain numbers nonzero) is present in the message. It should always be OFF with the 16-bit message header. If this bit is improperly set, delivery of the message to the (apparent) destination is unlikely.
拡張アドレシング。 32ビットのアドレス(ネットワーク、そして/または、Domain数の非零)がメッセージに存在しているときはいつも、このビットはセットONであるべきです。 いつもそれは16ビットのメッセージヘッダーがあるOFFであるべきです。 このビットが不適切に設定されるなら、(明らか)の目的地へのメッセージの配送はありそうもないです。
END-TO-END CRC. Some newer technology adapters are equipped to place a 32-bit CRC of the associated data at the end of the associated data block when this bit is on. Similarly equipped adapters will examine the trailing 32-bits of associated data (when the bit is on) to determine if the message contents have been corrupted at any stage of the transmission.
終わりから終わりへのCRC。 このビットがオンである関連データブロックの端に関連データの32ビットのCRCを置くためにいくつかの、より新しい技術アダプターを備えています。 同様に備えられているアダプターは、メッセージ内容が何かトランスミッションの段階で腐敗しているかどうか決定するために、引きずっている32ビットの関連データ(ビットがオンであるときに)を調べるでしょう。
Transmitting device drivers should include the ability to set this bit on transmission as a configuration option similar to the specific HYPERchannel device interface used. The bit should be generated to be turned ON if the HYPERchannel IP driver is attached to an adapter equipped to generated CRC information -- it should be left OFF in all other circumstances.
デバイスドライバを伝えると、デバイス・インタフェースが使用した特定のHYPERchannelと同様の設定オプションとしてトランスミッションのこのビットを設定する能力は包含するべきです。 HYPERchannel IPドライバーが発生しているCRC情報に備えていたアダプターに取り付けられるなら、ビットはつけられるために生成されるべきです--それは他のすべての事情でやめられるべきです。
If a message arrives at the host with the CRC bit still on, this indicates that the CRC information was placed at the end of associated data by the transmitting adapter and not removed by the receiving adapter; thus the associated data will be four bytes longer than otherwise expected. Since the IP datagram length is self contained in the network message, this should not impact IP drivers.
CRCビットがまだオンな状態でメッセージがホストに到着するなら、これは、CRC情報が伝えるアダプターによって関連データの終わりに置かれて、受信アダプターによって取り除かれなかったのを示します。 したがって、関連データは別の方法で予想されるより何バイトも長い間、4になるでしょう。 IPデータグラムの長さがネットワークメッセージで自給自足であるので、これはIPドライバーに影響を与えるべきではありません。
It is possible for host computers to both generate and check this CRC information to match the hardware assisted generation and checking logic in newer network adapters. Contact NSC if there are particular applications requiring exceptional data integrity that could benefit from host generation and checking.
ホストコンピュータが、より新しいネットワークアダプターでハードウェアの補助世代と照合論理を合わせるためにともにこのCRC情報を生成して、チェックするのは、可能です。 ホスト世代の利益を得ることができた例外的なデータ保全を必要として、チェックする特定用途はあれば、NSCに連絡してください。
Hardwick & Lekashman [Page 25] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[25ページ]RFC1044IP
FROM ADDRESS CORRECT. This bit should be set by all transmitting IP drivers who have endeavored to provide a completely correct FROM address that properly reflects the adapter interface used. No action should be taken on this bit by the receiving IP driver at this time. Additional work needs to be done to determine the action an IP driver should take if it detects a real or imagined "security violation" should a message arrive with this bit absent.
アドレス正しいです。 このビットは適切にアダプターインタフェースを反映する完全に正しいFROMアドレスを提供するよう努力したIPドライバーを皆、伝えることによって使用されるセットであるべきです。 受信IPドライバーはこのとき、このビットの上で行動を全く取るべきではありません。 追加仕事は、本当の、または、想像される「安全の侵害」を検出するならこのビットが欠けていた状態でメッセージが到着するならIPドライバーが取るべきである行動を決定するためにする必要があります。
TO ADDRESS
アドレスに
The TO address logically constitutes bytes 2-5 of the network message.
TOアドレスはネットワークメッセージのバイト2-5を論理的に構成します。
NETWORK AND DOMAIN NUMBERS. The Network and Domain numbers should both be nonzero when 32-bit addressing is used. If the message is local in nature, then the local Network and Domain numbers should be placed in this field.
ANDドメイン番号をネットワークでつないでください。 32ビットのアドレシングが使用されているとき、NetworkとDomain番号はともに非零であるべきです。 メッセージが現実にローカルであるなら、地方のNetworkとDomain番号はこの分野に置かれるべきです。
ADAPTER ADDRESS. Contains the adapter address as in the basic message. The high order bit of this eight bit field (the "outnet" bit) should be set to zero if the destination network and domain are the same as the transmitting host's. The high order bit should be set to one if the destination host is not in the local network or domain.
アダプターアドレス。 基本のメッセージのようにアダプターアドレスを含んでいます。 送信先ネットワークとドメインが伝わっているホストのものと同じであるなら、この8ビットの分野("outnet"ビット)の高位のビットはゼロに設定されるべきです。 あて先ホストが企業内情報通信網かドメインにいないなら、高位のビットは1つに設定されるべきです。
LOGICAL TO AND SUBADDRESS. The logical TO field should contain the protocol server address of the HYPERchannel IP driver for that host as determined by the host's system administrator.
AND SUBADDRESSに、当然です。 ホストのシステム管理者によって決定されるように論理的なTO分野はそのホストのためのHYPERchannel IPドライバーのプロトコルサーバアドレスを含むべきです。
FROM ADDRESS
アドレスから
The FROM address is filled in with the address that the local driver expects to receive from the network, but no particular use is made of the FROM address.
地元のドライバーがネットワークから受け取ると予想するアドレスでFROMアドレスに記入しますが、FROMアドレスでどんな特定の使用もしません。
MESSAGE TYPE
メッセージタイプ
The value 6 must be placed in this byte to uniquely indicate that the network message is being used to carry IP traffic. No other well- behaved protocol using HYPERchannel should duplicate this value of 6.
ネットワークメッセージがIPトラフィックを運ぶのに使用されているのを唯一示すために値6をこのバイトに置かなければなりません。 HYPERchannelを使用する他のどんなよく振る舞っているプロトコルも6のこの値をコピーするべきではありません。
Note that all IP drivers should be prepared to send and receive the basic format network messages using the 16-bit HYPERchannel addresses. The driver can distinguish an incoming network message by the value of byte 8 -- 32-bit messages will always have a 6 in byte 8, while 16-bit messages should have a 5 here. For interoperability with older drivers, a value of 0 here should be treated as 16 address bit messages.
すべてのIPドライバーが16ビットのHYPERchannelアドレスを使用することで基本形式ネットワークメッセージを送って、受け取る用意ができているべきであることに注意してください。 ドライバーはメッセージがいつも6を持っているバイトの8 -- 32ビットバイト8の値で入って来るネットワークメッセージを区別できます、16ビットのメッセージがここに5を持つべきですが。 より年取ったドライバーがいる相互運用性において、16アドレスがメッセージに噛み付いたので、ここの0の値は扱われるべきです。
Hardwick & Lekashman [Page 26] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[26ページ]RFC1044IP
IP HEADER OFFSET
IPヘッダーオフセット
Byte 9 contains the offset to the start of the IP header within the message proper, such that the Message Proper address plus the IP header offset generates the address of the first byte of the IP header (at least on byte addressable machines.)
バイト9はメッセージ自体の中にIPヘッダーの始まりようにオフセットを含んでいます、アドレスとIPヘッダーが相殺するMessage ProperがIPヘッダーの最初のバイトのアドレスを作るように(少なくともバイトのアドレス可能なマシンの。)
Unlike the 16-bit header, receiving IP drivers should assume that this field contains a correct offset to the IP header and examine the information at that offset for conformance to an IP datagram header.
16ビットのヘッダーと異なって、IPドライバーを受けるのは、この分野がIPヘッダーに正しいオフセットを含むと仮定して、順応のためにIPデータグラムヘッダーに相殺されたそれで情報を調べるべきです。
Valid offsets are in the range of 16 through 44 bytes, inclusive. The limitation of 44 bytes is imposed so that routing decisions on the vast majority of IP datagrams can be made by examining only the message proper, as the basic IP datagram will fit into the message proper if it begins at an offset of 44.
44バイトを通して有効なオフセットが16の範囲にあります。包括的。 44バイトの制限はメッセージ自体だけを調べることによってIPデータグラムのかなりの大部分のルーティング決定をすることができるように課されます、44のオフセットのときに始まると基本的なIPデータグラムがメッセージ自体に収まるとき。
IP DATAGRAM CONTENTS
IPデータグラムコンテンツ
The message and data are treated as logically contiguous entities where the first byte of associated data immediately follows the 64th byte of the message proper.
関連データの最初のバイトがすぐにメッセージ自体の64番目のバイトを以下であるところでメッセージとデータは論理的に隣接の実体として扱われます。
If the entire IP datagram is less than or equal to (64-offset) bytes in length it will fit into the Message Proper. If so, only a message proper containing the HYPERchannel header and IP datagram is sent on the network.
全体のIPデータグラムは長さが(64によるオフセット)の、よりバイト以下であるなら、それはMessage Properに収まるでしょう。 そうだとすれば、ネットワークでHYPERchannelヘッダーとIPデータグラムを含むメッセージ自体だけを送ります。
If the IP datagram is greater than this length, the IP datagram spills over into the associated data. On transmission, a 64 byte message proper is sent followed by as many bytes of associated data as are needed to send the entire datagram.
IPデータグラムがこの長さより大きいなら、IPデータグラムは関連データにあふれ出ます。 トランスミッションのときに、全体のデータグラムを送るのが必要であるのと同じくらい多くのバイトの関連データがあとに続いていて、メッセージの64バイトの自体を送ります。
On reception, the message proper can be read into the start of an IP input buffer and the associated data read into memory 64 bytes from the start of the message. If the received message is in fact a 32- bit address message, no "shuffling" of the message will be required to build a contiguous IP datagram -- it's right there at buffer+16.
レセプションでは、IP入力バッファの始まりからメッセージ自体を読み取ることができます、そして、関連データはメモリをメッセージの始まりから64バイト読み取ります。 事実上、受信されたメッセージが32ビット・アドレスメッセージであるなら、メッセージのどんな「シャッフル」も隣接のIPデータグラムを組立てるのに必要でないでしょう--それはちょうどあそこ、バッファ+16にあります。
ADDRESS RESOLUTION PROTOCOL
アドレス解決プロトコル
Address Resolution Protocol has achieved a great deal of success on the Ethernet as it permits a local IP network to configure itself simply by having each node know its own IP address. Those unfamiliar with the intent, protocol, and logic of the Address Resolution Protocol should refer to RFC-826, "An Ethernet Address Resolution Protocol" [2].
ローカルアイピーネットワーク自体が、それ自身のIPアドレスを知るように単に各ノードを持っていることによって構成することを許可するとき、アドレスResolutionプロトコルはイーサネットに関する多くの成功を遂げました。 Address Resolutionプロトコルの意図、プロトコル、および理論になじみがないものはRFC-826(「イーサネットアドレス解決プロトコル」[2])について言及するはずです。
Hardwick & Lekashman [Page 27] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[27ページ]RFC1044IP
A later section of this document describes four techniques where a target HYPERchannel address is to obtained given the destination's IP address. The protocol is defined in this section for completeness.
このドキュメントの後のセクションは目標HYPERchannelアドレスがある目的地のIPアドレスを考えて、得られた4つのテクニックについて説明します。 プロトコルは完全性のためにこのセクションで定義されます。
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try |1| Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Server Domain or | Server Network or |
| 0xFF | 0xFF |
+------------------------------+-----------------------------+
4 | Server Adapter Address or | Server logical addr/port or |
| 0xFF | 07 |
+------------------------------+-----------------------------+
6 |O| Physical addr of | Originating | Src Port|
|N| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | NSC ARP type code |
| 07 | 00 |
+------------------------------+-----------------------------+
10 | Source Domain | Source Network |
+------------------------------+-----------------------------+
12 | - reserved - | Age Count |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (usually 16) | (usually 16) |
+------------------------------+-----------------------------+
16 | Padding to start of IP info (usually 0 bytes) |
+------------------------------+-----------------------------+
メッセージ適切な+------------------------------+-----------------------------+ 0 | 試すトランクス|1| メッセージ旗| | TOトランクス| FROMトランクス|GNA|CRC| |SRC|EXC|BST|/D| +------------------------------+-----------------------------+ 2 | またはサーバドメイン。| またはサーバネットワーク。| | 0xFF| 0xFF| +------------------------------+-----------------------------+ 4 | またはサーバアダプターアドレス。| またはサーバの論理的なaddr/ポート。| | 0xFF| 07 | +------------------------------+-----------------------------+ 6 |O| 身体検査はaddrします。| 起因します。| Srcポート| |N| ソースアダプター| サーバアドレス| 数| +------------------------------+-----------------------------+ 8 | NSC ARPはコードをタイプします。| | 07 | 00 | +------------------------------+-----------------------------+ 10 | ソースドメイン| ソースネットワーク| +------------------------------+-----------------------------+ 12 | - 予約、-| 時代カウント| +------------------------------+-----------------------------+ 14 | 次のヘッダーは相殺しました。| ヘッダー終わりのオフセット| | (通常16) | (通常16) | +------------------------------+-----------------------------+ 16 | IPインフォメーション(通常0バイト)の始まりようにそっと歩くこと。| +------------------------------+-----------------------------+
Hardwick & Lekashman [Page 28] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[28ページ]RFC1044IP
+------------------------------+-----------------------------+
Off | ARP hardware address type for HYPERchannel |
| 8 |
+------------------------------+-----------------------------+
+2 | HYPERchannel protocol type |
| 06 00 |
+------------------------------+-----------------------------+
+4 | HYPERchannel address length | IP address length |
| 6 | 4 |
+------------------------------+-----------------------------+
+6 | ARP opcode (request or reply) |
+------------------------------+-----------------------------+
+8 | Domain | Network |
+- Sender's 32-bit HYPERchannel address -+
+10 | Adapter address | Logical addr/port |
+------------------------------+-----------------------------+
+12 | Source's MTU size |
+------------------------------+-----------------------------+
+14 | | |
+- Sender's 32-bit IP address -+
+16 | |
+------------------------------+-----------------------------+
+18 | Domain | Network |
+- Destination's 32-bit HYPERchannel address -+
+20 | (to be determined on request) |
| Adapter address | Logical addr/port |
+------------------------------+-----------------------------+
+22 | Destination's MTU size |
| (to be determined on request) |
+------------------------------+-----------------------------+
+24 | | |
+- Destination's 32-bit IP address -+
+26 | |
+------------------------------+-----------------------------+
+------------------------------+-----------------------------+ 下に| HYPERchannelのためのARPハードウェア・アドレスタイプ| | 8 | +------------------------------+-----------------------------+ +2 | HYPERchannelプロトコルタイプ| | 06 00 | +------------------------------+-----------------------------+ +4 | HYPERchannelアドレスの長さ| IPアドレスの長さ| | 6 | 4 | +------------------------------+-----------------------------+ +6 | ARP opcode(要求か回答)| +------------------------------+-----------------------------+ +8 | ドメイン| ネットワーク| +送付者の32ビットのHYPERchannelアドレス-++10| アダプターアドレス| 論理的なaddr/ポート| +------------------------------+-----------------------------+ +12 | ソースのMTUサイズ| +------------------------------+-----------------------------+ +14 | | | +送付者の32ビットのIPアドレス-++16| | +------------------------------+-----------------------------+ +18 | ドメイン| ネットワーク| +目的地の32ビットのHYPERchannelアドレス-++20| (要求に応じて断固とする) | | アダプターアドレス| 論理的なaddr/ポート| +------------------------------+-----------------------------+ +22 | 目的地のMTUサイズ| | (要求に応じて断固とする) | +------------------------------+-----------------------------+ +24 | | | +目的地の32ビットのIPアドレス-++26| | +------------------------------+-----------------------------+
Layout of the fields of this ARP message is a fairly straightforward exercise given the standards of ARP and the 32-bit message header. A few fields are worth remarking upon:
ARPの規格と32ビットのメッセージヘッダーを考えて、このARPメッセージの分野のレイアウトはかなり簡単な運動です。 いくつかの分野は言う価値があります:
TO ADDRESS
アドレスに
The TO address of an ARP message will be one of two classes of address. A "normal" address indicates that the message is an ARP response, or that it is an ARP request directed at an ARP server at a well known address on the local network. For those HYPERchannel networks which are equipped to broadcast, a value of 0xFFFFFF07 in the TO address will (by convention) be picked up only by those protocol servers prepared to interpret and respond to ARP messages.
ARPメッセージのTOアドレスはアドレスの2つのクラスの1つになるでしょう。 「正常な」アドレスは、メッセージがARP応答であるかそれがARPサーバが企業内情報通信網に関するよく知られているアドレスで向けられたARP要求であることを示します。 放送するために備えているそれらのHYPERchannelネットワークのために、TOアドレスの0xFFFFFF07の値は、ARPメッセージに解釈するように準備されたそれらのプロトコルサーバだけによって拾われて、応じるでしょう(コンベンションで)。
Hardwick & Lekashman [Page 29] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[29ページ]RFC1044IP
The issue of which address to use in an ARP request is discussed in the Address Resolution section.
Address Resolution部でARP要求でどのアドレスを使用したらよいかに関する問題について議論します。
FROM ADDRESS
アドレスから
Must be the correct FROM address of the user protocol server issuing an ARP request. The Source Correct bit in the Message Flags byte should be set by this requesting server, as some ARP servers may someday choose to issue ARP information on an "need to know" basis in secure environments. With an ARP response, the FROM address will contain the "normal" HYPERchannel address of the protocol server responding to the ARP address, even if that server was reached via broadcast mechanisms.
正しいFROMがユーザのアドレスであったに違いないなら、ARP要求を出すサーバについて議定書の中で述べてください。 Message FlagsバイトにおけるSource CorrectビットはこれでいくつかのARPサーバがいつか選ぶかもしれないようにサーバを要求するのに安全な環境における「知る必要性」ベースの情報をARPに発行するように設定することであるべきです。 ARP応答で、FROMアドレスはプロトコルサーバの応じることの「正常な」HYPERchannelアドレスをARPアドレスに含むでしょう、放送メカニズムでそのサーバに達したとしても。
ARP responses are returned to the party specified in the FROM address specified in the message header, rather than the address in the "Source HYPERchannel Address" field within the body of the ARP message.
ARPメッセージのボディーの中の「ソースHYPERchannelアドレス」分野のアドレスよりむしろメッセージヘッダーで指定されたFROMアドレスで指定されたパーティーにARP応答を返します。
MESSAGE TYPE
メッセージタイプ
The 16-bit value 0x0700 is reserved for the exclusive use of ARP. Unlike IP messages, no provision is made for the ARP message to begin at an arbitrary offset within the message proper, so the value in byte 9 is an extension of the message type.
16ビットの値0x0700はARPの専用のために予約されます。 IPメッセージと異なって、メッセージ自体の中に任意のオフセットのときに始まるARPメッセージに備えるので、バイト9における値はメッセージタイプの拡大です。
HEADER END OFFSET
ヘッダー終わりのオフセット
ARP uses the 32-bit addressing convention that byte 15 contains the offset to the start of user protocol (and hence the end of user protocol information). Note that this is not a substitute for the IP offset fields, as this field also serves as the end of HYPERchannel header information -- future NSC message processing code may well take exception to "garbage" between the actual header end and the start of user data.
ARPは、ユーザプロトコル(そして、したがって、ユーザプロトコル情報の終わり)の始まりへのオフセットをバイト15が含むコンベンションに扱いながら、32ビットを使用します。 これがIPのオフセット分野の代用品でないことに注意してください、また、この分野がHYPERchannelヘッダー情報の終わりとして機能するとき--将来のNSCメッセージ処理コードはたぶん実際のヘッダーエンドと利用者データの始まりの間の「ゴミ」に反対するでしょう。
HYPERCHANNEL HARDWARE TYPE CODE
HYPERCHANNELハードウェアタイプコード
This 16-bit number is assigned a formal ARP hardware type of 8.
8つの礼儀正しいARPハードウェアタイプがこの16ビットの数に割り当てられます。
HYPERCHANNEL PROTOCOL TYPE
HYPERCHANNELプロトコルタイプ
On the Ethernet, this field is used to distinguish IP from all other protocols that may require address resolution. To be logically consistent, this field is identical to bytes 8 and 9 0x0600 in a 32- bit address HYPERchannel message carrying an IP datagram.
イーサネットでは、この分野は、アドレス解決を必要とするかもしれない他のすべてのプロトコルとIPを区別するのに使用されます。 論理的に一貫しているように、この分野はIPデータグラムを運ぶ32ビット・アドレスHYPERchannelメッセージのバイト8と9 0×0600と同じです。
Hardwick & Lekashman [Page 30] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[30ページ]RFC1044IP
HYPERCHANNEL ADDRESS LENGTH
HYPERCHANNELアドレスの長さ
This contains the value 6, a sufficient number of bytes to accommodate the four byte HYPERchannel address and 2 bytes to indicate the largest IP datagram size that source and destination can handle.
これは値6を含んでいます、バイトのソースと目的地が扱うことができる中で最も大きいIPデータグラムサイズを示すために4バイトのHYPERchannelアドレスと2バイトに対応できるくらいの数。
SOURCE AND DESTINATION HYPERCHANNEL ADDRESS
ソースAND送付先HYPERCHANNELアドレス
This field contains the Domain, Network, and Adapter/port address of source and destination, respectively. A value of 0000 in the Domain and Network fields has special significance as this is interpreted as a request to send and receive 16-bit HYPERchannel headers rather than 32-bit headers. If 32-bit headers are to be used within a single HYPERchannel network, then the local domain and network numbers may be specified.
この分野はそれぞれソースと目的地のDomain、Network、およびAdapter/ポートアドレスを含んでいます。 これが32ビットのヘッダーよりむしろ16ビットのHYPERchannelヘッダーを送って、受け取るという要求として解釈されるとき、DomainとNetwork分野の0000年の値には、特別な意味があります。 32ビットのヘッダーがただ一つのHYPERchannelネットワークの中で使用されるつもりであるなら、局所領域とネットワーク・ナンバーは指定されるかもしれません。
MAXIMUM TRANSMISSION UNIT
マキシマム・トランスミッション・ユニット
HYPERchannel LAN technology is such that messages of unlimited length may be sent between hosts. Since host throughput on a network is generally limited by the rate the network equipment can be functioned, larger transmission sizes result in higher bulk transfer performance. Since not every host will be able to handle the maximum size IP datagram, a more flexible means of MTU (maximum transmission unit) size negotiation than simply wiring the same value into every network host is needed. With this field, each host declares the maximum IP datagram size (not the associated data block size) it is prepared to receive. Transmitting IP drivers should be prepared to send the minimum of the source and destination IP sizes negotiated at ARP time.
HYPERchannel LAN技術は無制限な長さに関するメッセージをホストの間に送るかもしれないようにものです。 ネットワークに関するホストスループットがレートによって一般に制限されるので、ネットワーク装置は機能して、より大きいトランスミッションが、より高いバルク転送性能で結果を大きさで分けるということであるかもしれません。 すべてのホストがどんな最大サイズIPデータグラムを扱うことができないで以来、MTU(マキシマム・トランスミッション・ユニット)サイズ交渉の単にすべてのネットワークホストに同じ値を配線するのが必要であるより多くの柔軟な手段です。 この分野で、各ホストは、最大のIPがそれが受けるように準備されるデータグラムサイズ(関連データブロック・サイズでない)であると宣言します。 IPドライバーを伝えるのはARP時に交渉されたソースと目的地IPサイズの最小限を送るように準備されるべきです。
The MTU size sent refers to the maximum size of IP header + data. It does not include the length of the HYPERchannel Hardware header or any offset between the header and the start of the IP datagram. Since it is the option of the transmitting hosts to use an offset of up to 44 bytes a receiving host must in any event be prepared to receive a 64 byte Message Proper and an Associated Data block of MTU-20 (that is 64 - 44, or the length of the basic IP header).
サイズが送ったMTUはIPヘッダー+データの最大サイズについて言及します。 それはHYPERchannel Hardwareヘッダーの長さかIPデータグラムのヘッダーと始まりの間のどんなオフセットも含んでいません。 それが使用する伝わっているホストのオプションであるので、64バイトのMessage ProperとMTU-20のAssociated Dataブロックを受け取るようにとにかく1受信ホストあたり最大44バイトのオフセットを準備しなければなりません(それは、64--44、または基本的なIPヘッダーの長さです)。
An example of a typical 16-bit packet is:
典型的な16ビットのパケットに関する例は以下の通りです。
12 bytes hardware header.
12 bytes offset.
40 bytes IP/TCP header.
4096 bytes of data.
This gives an MTU of 4136.
12バイトのハードウェアヘッダー。 12バイトは相殺されます。 40バイトのIP/TCPヘッダー。 4096バイトのデータ。 これは4136をMTUに与えます。
Hardwick & Lekashman [Page 31] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[31ページ]RFC1044IP
An example of a typical 32-bit packet is:
典型的な32ビットのパケットに関する例は以下の通りです。
16 bytes hardware header.
8 bytes offset.
40 bytes IP/TCP header.
4096 bytes of associated data,
This also gives an MTU of 4136.
16バイトのハードウェアヘッダー。 8バイトは相殺されます。 40バイトのIP/TCPヘッダー。 また、関連データでは、4096バイト、Thisは4136をMTUに与えます。
The offset values are chosen so that the typical packet causes user data to be page aligned at the start of the associated data area. This is an implementation decision, which can certainly be modified as required.
オフセット値が選ばれているので、典型的なパケットは、利用者データが関連データ領域の始めで並べられたページであることを引き起こします。 これは実装決定です。(確かに、必要に応じてその決定を変更できます)。
The maximum maximum transmission unit is 65536, the current largest size IP datagram. In order to allow this value to fit into a 16-bit field, the offset length is not included in the MTU. This MTU size is not a requirement that a local host be equipped to send or receive datagrams of that size; it simply indicates the maximum capacity of the receiving host.
最大のマキシマム・トランスミッション・ユニットは65536、現在の最も大きいサイズIPデータグラムです。 この値が16ビットの分野に収まるのを許容するために、オフセット長さはMTUに含まれていません。 このMTUサイズはそのサイズのデータグラムを送るか、または受け取るためにローカル・ホストに持たせるという要件ではありません。 それは単に受信ホストの最大能力を示します。
A note on trunk masks:
トランクマスクに関する注:
There is no field for specifying trunk masks. This is intentional, as new NSC hardware will contain trunk reachability information, eliminating the need for the host to maintain hardware configuration layouts. All HYPERchannel messages generated as a result of an ARP response should use 0xFF in the trunk mask.
トランクマスクを指定するための分野が全くありません。 これは意図的です、新しいNSCハードウェアがトランク可到達性情報を含むとき、ホストがハードウェア・コンフィギュレーションレイアウトを維持する必要性を排除して。 ARP応答の結果、生成されたすべてのHYPERchannelメッセージがトランクマスクで0xFFを使用するべきです。
ADDRESS RESOLUTION
アドレス解決
This section describes techniques used by an IP driver to determine the HYPERchannel address and header that a message should contain given an IP datagram containing an IP address. It describes techniques that are local to specific hosts (and hence can be modified without regard to the activities or techniques of other hosts) as well as techniques to use the Address Resolution Protocol on existing HYPERchannel equipment to better manage IP addresses.
このセクションはIPアドレスを含むIPデータグラムを考えて、メッセージが含むべきであるHYPERchannelアドレスとヘッダーを決定するのにIPドライバーによって使用されたテクニックについて説明します。 それは、テクニックと同様にIPアドレスをよりよく管理するのに既存のHYPERchannel設備の上でAddress Resolutionプロトコルを使用するために特定のホストにとって、ローカルであることのテクニックについて説明します(そして、したがって、関係なしで他のホストの活動かテクニックに変更できます)。
It also discusses the migration of name resolution on one of four steps.
また、それは4ステップの1つときに名前解決の移行について議論します。
1. Truncation of the IP address to form a HYPERchannel address.
1. HYPERchannelアドレスを形成するIPアドレスのトランケーション。
2. Local resolution of HYPERchannel addresses through configuration
files.
2. 構成ファイルを通したHYPERchannelアドレスの地方の解決。
3. Centralized resolution of HYPERchannel addresses through an "ARP
server" driven by a configuration file.
3. 構成ファイルによって運転された「ARPサーバ」を通したHYPERchannelアドレスの解決を集結しました。
Hardwick & Lekashman [Page 32] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[32ページ]RFC1044IP
4. Distributed resolution of HYPERchannel addresses using a "real"
address Resolution Protocol on future HYPERchannel media
supporting a broadcast mode.
4. HYPERchannelの分配された決議は、放送モードをサポートしながら、将来のHYPERchannelメディアで使用が「本当」のアドレスResolutionプロトコルであると扱います。
IP ADDRESS TRUNCATION
IPアドレストランケーション
A number of IP on HYPERchannel implementations support modes where the HYPERchannel address is generated by placing the low order 16- bits of the IP address in the TO address of the message proper. This more or less treats a set of HYPERchannel boxes addressable through 16-bit HYPERchannel addresses as a Class B IP network.
HYPERchannel実装のIPの数はHYPERchannelアドレスが下位16を置くことによって作られるモードにメッセージ自体のTOアドレスのIPアドレスのビットを支えます。 これは多少Class B IPネットワークとして16ビットのHYPERchannelアドレスを通ってアドレス可能なHYPERchannel箱のセットを扱います。
This approach certainly offers simplicity: IP addresses are simply chosen to match HYPERchannel addresses and no IP address "configuration files" need be kept. Although this approach works in an environment where the HYPERchannel completely constitutes a Class B network, or where connection to a larger IP network is not a concern, its long term use is discouraged for several reasons:
確かに、このアプローチは簡単さを提供します: IPアドレスはHYPERchannelアドレスを合わせるために単に選ばれています、そして、IPアドレス「構成ファイル」は全く保たれる必要はありません。 このアプローチはHYPERchannelがClass Bネットワークを完全に構成するか、より大きいIPネットワークとの接続が関心でない環境で働いていますが、長期使用はいくつかの理由でお勧めできないです:
o It simply will not work with any Class C address (the physical
TO address is not controllable) or a Class A address (where host
addresses are generally carefully administered.) In addition,
it will not support subnetworks. It is quite incompatible with
32-bit HYPERchannel addresses.
o それはどんなClass Cアドレス(物理的なTOアドレスは制御可能でない)かClass Aアドレス(一般に、ホスト・アドレスが慎重に管理されるところ)でも絶対に働かないでしょう。 さらに、それはサブネットワークをサポートしないでしょう。 それは32ビットのHYPERchannelアドレスと十分非互換です。
o By decoupling the IP and HYPERchannel addresses through more
complex address resolution, the characters of the two addresses
allow greater site flexibility: the IP address becomes
"logical" in character so that an address can move about a site
with the user or host; the HYPERchannel address maintains its
physical character so that a HYPERchannel address carefully
identifies the physical location of the source and destination
within the extended HYPERchannel network.
o より複雑なアドレス解決でIPとHYPERchannelアドレスの衝撃を吸収することによって、2つのアドレスのキャラクタは、より大きいサイトの柔軟性を許容します: IPアドレスはぴったりしたアドレスがユーザかホストと共にサイトを動き回らせることができるように、「論理的に」なります。 HYPERchannelアドレスが物理的なキャラクタを維持するので、HYPERchannelアドレスは拡張HYPERchannelネットワークの中で慎重にソースと目的地の物理的な位置を特定します。
LOCAL ADDRESS RESOLUTION
ローカルアドレス解決
The current state of address resolution art with IP on HYPERchannel works as follows: given an arbitrary IP address, the IP HYPERchannel driver looks up an entry with that address in a (generally hashed) table. If found, the table entry contains the first 6 bytes of the HYPERchannel header that is used to send the IP datagram to the next IP node on the internet. Since implementations such as the 4.3BSD UNIX IP are clever enough to provide its lower level drivers with the IP address of the next gateway as well as the destination address on the internet (assuming the message is not delivered locally on the HYPERchannel,) the number of entries in this table is more or less manageable, as it must only contain the IP hosts and gateway addresses that are directly accessible on the HYPERchannel.
IPがHYPERchannelにあるアドレス解決芸術の現状は以下の通り働いています: 任意のIPアドレスを考えて、IP HYPERchannelドライバーは(一般に、論じ尽くされます)のテーブルでそのアドレスでエントリーを見上げます。 見つけられるなら、テーブル項目はインターネットの次のIPノードにIPデータグラムを送るのに使用されるHYPERchannelヘッダーの最初の6バイトを含んでいます。 4.3BSD UNIX IPなどの実装が賢明であるので、多少インターネット(メッセージを仮定するのはHYPERchannelで局所的に提供されない)に関する送付先アドレスと同様に隣のゲートウェイのIPアドレスをもっている低レベルのドライバーにこのテーブルのエントリーの数を提供できるくらい処理しやすいです、HYPERchannelで直接理解できるIPホストとゲートウェイアドレスを含むだけでよいとき。
Hardwick & Lekashman [Page 33] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[33ページ]RFC1044IP
CONFIGURATION FILE FORMAT
構成ファイル形式
So long as this technique of address resolution is used, the techniques used are exclusively local to the host in the sense that the techniques used to generate and store the information in the table are irrelevant to other hosts.
アドレス解決のこのテクニックが使用されている限り、ホストにとって、使用されるテクニックは他のホストにとって、テーブルの情報を生成して、保存するのに使用されるテクニックが無関係であるという意味で排他的にローカルです。
Shown here is a typical file format. This file should probably be program generated from a database, as asymmetric trunk configurations and multiply homed hosts can cause differences in physical routing and trunk usage. This format is documented here to illustrate what sort of information must be kept at the link layer.
ここに示されているのは、典型的なファイル形式です。 このファイルがたぶん非対称のトランク構成としてデータベースから生成されたプログラムであり、増えるはずである、家へ帰り、ホストは物理的なルーティングとトランク用法の違いを引き起こす場合があります。 この書式は、リンクレイヤにどういう情報を保たなければならないかを例証するためにここに記録されます。
The file consists of source lines each with the form:
ファイルはフォームでそれぞれソース系列から成ります:
<type> <hostname> <trunks/flags> <domain/net> <addr> <MTU>
<タイプ><ホスト名><トランクス/旗の><ドメイン/ネットの>の<addr><MTU>。
an example:
例:
<type> <hostname> <t/f> <dom/net> <addr> <MTU>
# Random front end
host hyper.nsco.com FF88 0103 3702 4148
# because we want to show the 4 byte format
host 192.12.102.1 FF00 0000 2203 1024
# Small packets, interactive traffic.
host cray-b.nas.nasa.gov FF88 0103 4401 4148
# The other interface, for big packets.
ahost cray-b.nas.nasa.gov FF88 0103 4501 32768
# A loopback interface, (What else)
loop loop37.nsco.com FF00 0000 3700 4148
# And of course an example of arp service.
arpserver hcgate.nsco.com FF88 0103 7F07
#4バイトを示したいと思うので、<タイプ><ホスト名><t/f><dom/ネットの>の><MTU>#Randomフロントエンド<addrホストhyper.nsco.com FF88 0103 3702 4148はホスト192.12.102.1FF00 0000 2203 1024#Smallパケット(対話的な通信)をフォーマットします; ザリガニb.nas.nasa.gov FF88 0103 4401 4148を接待してください。loop37.nsco.com FF00 0000 3700 4148#Andを輪にしてください。#他のインタフェース、大きいパケットahostザリガニb.nas.nasa.gov FF88 0103 4501 32768#Aに関して、ループバックが連結する、(他の何、)、もちろんarpサービスの例、arpserver hcgate.nsco.com FF88 0103 7F07
Comments may begin with either # or ;.
Case is not significant in any field.
または、コメントが#で始まるかもしれない、; . ケースはいずれもさばく重要なコネではありません。
<type> indicates the type of entity to be defined.
Currently defined types are "host," "ahost", "loop," "address,"
and "arpserver".
<タイプ>は、定義されるために実体のタイプを示します。 現在定義されたタイプは、「ホスト」"ahost"の「輪」と、「アドレス」と、"arpserver"です。
host This token indicates an IP host. The following field is
expected to be a name that can be resolved to an IP
address.
ホストThisトークンはIPホストを示します。 以下の分野はIPアドレスに決議できる名前であると予想されます。
ahost This field indicates an additional network interface to
the same host. This may be used for performance
enhancements.
ahost This分野は追加ネットワーク・インターフェースを同じホストに示します。 これはパフォーマンス強化に使用されるかもしれません。
Hardwick & Lekashman [Page 34] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[34ページ]RFC1044IP
loop Sets a flag in the entry for that host so that 0xFF00 is
placed in bytes 8 and 9 of the message. This will cause
the IP datagram to be directed towards the specified host
(which must still be a valid host name) and looped back
within the remote adapter. This facility serves both as a
debugging aid and as a crude probe of the availability of
the remote network adapter.
0xFF00がメッセージのバイト8と9で置かれるように、それのためのエントリーにおける旗が接待するSetsを輪にしてください。 これは、IPデータグラムが指定されたホスト(まだ有効なホスト名であるに違いない)に向けられて、リモート・アダプタの中で輪にされることを引き起こすでしょう。 この施設はデバッギング・エイドとしてリモートネットワークアダプターの有用性の粗雑な徹底的調査として機能します。
arpserver This indicates an address to use for directing ARP
requests to the network. If several arpserver addresses
are specified, they will be tried in turn until a response
is received (or we run out of servers.) An arpserver with
the appropriate broadcast address of FFFF FF07 would
cause an ARP broadcast to take place when broadcasting
becomes available. Broadcast and specific addresses may
be used in combination.
arpserver ThisはARP要求をネットワークに向けるのに使用するアドレスを示します。 いくつかのarpserverアドレスが指定されると、応答が受け取られているまで(私たちはサーバを使い果たします)、それらは順番に試みられるでしょう。 放送が利用可能になると、FFFF FF07の適切な放送演説があるarpserverはARP放送を行われさせるでしょう。 放送してください。そうすれば、特定のアドレスは組み合わせに使用されてもよいです。
<hostname> This field is the logical name of the destination. For a host it is the logical name to be given to the local naming service to determine the associated IP address. This field may contain four decimal numbers separated by dots, in which case it is assumed to be the explicit IP address.
<ホスト名>This分野は目的地の論理的な名前です。 ホストにとって、関連IPアドレスを決定するために地方の名前付けサービスに与えるのは、論理的な名前です。 この分野はドットによって切り離された4つの10進数を含むかもしれません、明白なIPアドレスであると思われるどの場合に。
<trunks/flags> This field is the value to be placed in bytes 0 and 1 of the message header when sending to this host. The associated data bit need not be supplied as the driver must control it. All other bits are sent as provided. This field is a hexidecimal number.
トランクス/旗の>Thisがさばく<はこのホストに発信するときメッセージヘッダーのバイト0と1で置かれるべき値です。 ドライバーがそれを制御しなければならないとき、関連データビットを供給する必要はありません。 提供するように他のすべてのビットを送ります。 この分野はhexidecimal番号です。
<domain/net> This field is the value to be placed in the Domain and Network number field of the message. A value of 0000 in this field indicates that the destination should be reached by constructing a 16-bit HYPERchannel header, rather than a 32-bit header.
Thisがさばく<ドメイン/ネットの>はメッセージのDomainとNetworkナンバーフィールドに置かれるべき値です。 この分野の0000年の値は、32ビットのヘッダーよりむしろ16ビットのHYPERchannelヘッダーを組み立てることによって目的地に達するべきであるのを示します。
<address> This field is the value to be placed in the 16-bit TO field to reach <hostname>. This field is a hexidecimal number.
>Thisがさばく<アドレスは<ホスト名>に達するように16ビットのTO分野に置かれるべき値です。 この分野はhexidecimal番号です。
<MTU> This field contains the largest size IP datagram that the destination host is prepared to receive. This field is a decimal number. This field is optional. If not present, a value of 4148 is assumed. See the earlier discussion on Maximum Transmission Unit for more detail.
Thisがさばく<MTU>はあて先ホストが受ける用意ができている最も大きいサイズIPデータグラムを含んでいます。 この分野は10進数です。 この分野は任意です。 プレゼントでないなら、4148年の値は想定されます。 その他の詳細に関してMaximum Transmission Unitについての以前の議論を見てください。
ARP SERVERS
アルプサーバ
The primary problem with local host address resolution is that changes or additions to hosts on the local net must be replicated to every HYPERchannel host in that network. While this is manageable for up to half a dozen hosts, it becomes quite unmanageable for
ローカル・ホストアドレス解決に関するプライマリ問題はそのネットワークでローカルのネットのホストへの変化か追加をすべてのHYPERchannelホストに模写しなければならないということです。 これは半ダース人のホストまで処理しやすいのですが、それは全く「非-処理しやす」になります。
Hardwick & Lekashman [Page 35] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[35ページ]RFC1044IP
larger networks. An approach that can be implemented using existing HYPERchannel technology is to have a server on the HYPERchannel network provide the HYPERchannel destination address that is associated with an IP address.
より大きいネットワーク。 既存のHYPERchannel技術を使用することで実装することができるアプローチはHYPERchannelネットワークのサーバにIPアドレスに関連しているHYPERchannel送付先アドレスを提供させることです。
Although this is strictly a point-to-point request/response dialogue between two network nodes, the Address Resolution Protocol which was originally designed for Ethernet (but thoughtfully constructed to work with any pair of link and network addresses) performs an excellent job.
これは厳密にそうですが、2の間の二地点間要求/応答対話はノードをネットワークでつないで、元々イーサネット(しかし、どんな組のリンクとネットワーク・アドレスでも働くために考え深く組み立てられる)のために設計されたAddress Resolutionプロトコルは好成績を実行します。
ARP servers can be reached simply by placing the address of the server in the 32-bit TO address of the network message. ARP servers only "listen" to messages that arrive on their well known normal address; they do not respond to ARP broadcast messages. Properly equipped IP drivers should respond to the broadcast messages when they appear.
単にネットワークメッセージの32ビットのTOアドレスのサーバのアドレスを置くことによって、ARPサーバに達することができます。 ARPサーバはそれらのよく知られている正常なアドレスで到着するメッセージを「聴くだけです」。 彼らはARP同報メッセージに応じません。 現れるとき、適切に備えられているIPドライバーは同報メッセージに応じるべきです。
If an ARP server receives a message containing an IP address it does not know how to resolve, it ignores the message so that another ARP server might be addressed at the source's next attempt.
ARPサーバがIPアドレスを含むメッセージを受け取るなら、それはソースの次の試みで別のARPサーバを扱うことができるようにメッセージを無視すると決議する方法を知りません。
If the address is resolvable, it places the known HYPERchannel address and MTU size in the response and returns it to the location in the HYPERchannel header FROM address.
アドレスが溶解性であるなら、それは、知られているHYPERchannelアドレスとMTUサイズを応答に置いて、HYPERchannelヘッダーFROMアドレスでそれを位置に返します。
Unlike a broadcast ARP, the ARP server will be required to service two requests when two hosts that are initially unknown to one another attempt to get in touch. Since the destination did not receive the ARP request, it must contact the ARP server when its higher level protocols first generate a datagram to respond to the the source's first IP datagram to go through to the destination.
放送ARPと異なって、ARPサーバが接触で得る2人のお互いにとって、初めは未知であることのホストであることの2つの要求が、試みるサービスに必要でしょう。 目的地がARP要求を受け取らなかったので、より高い平らなプロトコルが最初に目的地を通るためにソースの最初のIPデータグラムに応じるためにデータグラムを生成すると、それはARPサーバに連絡しなければなりません。
The source configuration file described in the previous section was explicitly designed so that it could be sufficient as a data base for an ARP server as well as an individual host.
前項で説明されたソース構成ファイルは、個々のホストと同様にARPサーバのためのデータベースとして十分であることができなるように明らかに設計されました。
BROADCAST ARP
放送アルプ
When a local HYPERchannel network contains a broadcast capability, any IP driver wishing to perform HYPERchannel address resolution may be configured to emit the ARP message on a broadcast instead of a well known address. IP drivers on other hosts are presumed to know if their local HYPERchannel interface can send broadcast messages; if so, they arrange to "listen" on the FF07 broadcast TO address for ARP.
ローカルのHYPERchannelネットワークが放送能力を含むとき、HYPERchannelアドレス解決を実行したがっているどんなIPドライバーも、よく知られているアドレスの代わりに放送に関するARPメッセージを放つために構成されるかもしれません。 他のホストの上のIPドライバーはあえて地元のHYPERchannelインタフェースが同報メッセージを送ることができるかどうかが知られています。 そうだとすれば、彼らは、ARPのためのFF07放送TOアドレスで「聴く」ように手配します。
Processing of a received ARP broadcast message is otherwise identical
そうでなければ、受信されたARP同報メッセージの処理は同じです。
Hardwick & Lekashman [Page 36] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[36ページ]RFC1044IP
to RFC-826:
RFC-826に:
o Messages are responded to if and only if the destination IP
driver is authoritative for the designated IP address.
o そして、メッセージが反応する、指定されたIPアドレスに、目的地IPドライバーが正式である場合にだけ。
o Whenever an ARP message is processed, the IP driver takes the
source HYPERchannel address and MTU size and adds it to its
address resolution tables. Thus the driver is equipped to
turn around the IP datagram that arrives from the destination
host when contact is made.
o ARPメッセージが処理されるときはいつも、IPドライバーは、ソースHYPERchannelアドレスとMTUサイズを取って、アドレス解決テーブルにそれを加えます。 したがって、接触が作られているときあて先ホストから届くIPデータグラムを変えるためにドライバーに持たせます。
Each IP driver may have address resolutions that are set through a static routing table (the configuration file specified above). If ARP information arrives that contradicts a static entry (as opposed to previously set dynamic ARP information) then the ARP information should be ignored. This decision is made on the premise that the only useful purpose of static routing in a broadcast ARP environment is to add authentication, as it's easy to lie with ARP.
それぞれのIPドライバーには、スタティックルーティングテーブルを通して設定されるアドレス解決があるかもしれません(構成ファイルは上で指定しました)。 静的なエントリー(以前に設定されたダイナミックなARP情報と対照的に)に矛盾するARP情報が到着するなら、ARP情報は無視されるべきです。 この決定をします、そして、放送ARP環境におけるスタティックルーティングの唯一の役に立つ目的は認証を加えることです、ARPにはあるのが簡単であるときに。
Hardwick & Lekashman [Page 37] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[37ページ]RFC1044IP
APPENDIX A. NSC PRODUCT ARCHITECTURE AND ADDRESSING
付録A.NSC製品アーキテクチャとアドレシング
This section is intended to be a concise review of the state of the art in NSC networks and the techniques they provide for the delivery of messages. Those who are thoroughly familiar with HYPERchannel may wish to only skim this section; however, there is material on new technologies and addressing formats that are not yet generally known to most of NSC's customers.
このセクションはそれらがメッセージの配送に提供するNSCネットワークとテクニックにおける、到達技術水準の簡潔なレビューであることを意図します。 HYPERchannelにすっかりなじみ深いものはこのセクションをざっと読むだけでありたいかもしれません。 しかしながら、材料がNSCの顧客の大部分においてまだ一般に知られていない新技術とアドレス指定形式にあります。
NETWORK SYSTEMS HYPERCHANNEL TECHNOLOGIES
ネットワーク・システムHYPERCHANNEL技術
Network Systems manufactures several different network technologies that use very different media and link controls, but still provide a common host interface in both the protocol and hardware sense of the term. These four technologies are:
ネットワークSystemsは非常に異なったメディアとリンク制御を使用するいくつかの異なったネットワーク技術を製造していますが、それでも、プロトコルとハードウェアが感じる用語の両方に一般的なホスト・インターフェースを提供してください。 これらの4つの技術は以下の通りです。
o HYPERchannel A -- A 50-megabit, baseband, CSMA with collision
avoidance network using a coaxial cable bus. Individual
HYPERchannel "network adapters" can control up to 4 of these
coaxial cable "trunks," providing up to 200 megabits of
capacity on a fully interconnected network. HYPERchannel A
is NSC's earliest product and has been in production since
1977. It is principally used to interconnect larger
mainframe computers and high speed mainframe peripherals such
as tape drives and laser printers.
o HYPERchannel A--50メガビット、ベースバンド、衝突回避用レーダー警報装置ネットワークが同軸ケーブルバスを使用しているCSMA。 個々のHYPERchannel「ネットワークアダプター」は最大これらの4同軸ケーブル「トランクス」を制御できます、完全にインタコネクトされたネットワークの容量の最大200のメガビットを提供して。 HYPERchannel AはNSCの最も前の製品であり、1977年以来生産中です。 それは、テープドライブやレーザープリンタなどの、より大きいメインフレーム・コンピュータと高速メインフレーム周辺機器とインタコネクトするのに主に使用されます。
o HYPERchannel B -- a 10-megabit, baseband, CSMA with collision
avoidance network using a single coaxial cable bus. This
technology is used for direct host to host communications under
the name HYPERchannel B, and for terminal connections under the
name HYPERbus. It is currently used for three major
applications -- local networks of ASCII terminals, networks
of IBM 3270 terminals, and host to host communications of
smaller computers.
o HYPERchannel B--10メガビット、ベースバンド、衝突回避用レーダー警報装置ネットワークが単一の同軸ケーブルバスを使用しているCSMA。 この技術はダイレクトホストにHYPERchannel Bという名でHYPERbusという名で端末の接続へのホストコミュニケーションに使用されます。 それは現在、3つの主用途に使用されます--ASCII端末の企業内情報通信網、IBM3270端末のネットワーク、および、より小さいコンピュータに関するコミュニケーションをホスティングするホスト。
o DATAPIPE[3] -- a 275-megabit fiber optic "backbone" network
that interconnects lower speed local area networks within a 20
mile range, and to provide an ultra-high-performance network for
the next generation of supercomputers and optical storage
systems. A prototype version of DATApipe is currently under
development at a customer site.
o DATAPIPE[3]--内部連絡される275メガビットの光ファイバー「バックボーン」ネットワークは20マイルの範囲の中に速度ローカル・エリア・ネットワークを下ろして、光記憶装置システムスーパーコンピュータの次世代とDATApipeのプロトタイプバージョンに超-高性能ネットワークを提供するのは現在、顧客サイトで開発中です。
o Bridges and Network Distance Extensions -- NSC quickly
discovered that its customers wanted very high speeds over
geographic areas, not just within the range of several miles
that is conceivable with a coaxial cable network. Starting
in 1978, NSC began to build a series of "link adapters" that
are integral bridges between local area networks. These link
o ブリッジとNetwork Distance Extensions--NSCは、顧客が同軸ケーブルネットワークと共に想像できる数マイルの範囲だけに関して欲しかったのではなく地理上の区域に関して非常に高い速度が欲しかったとすぐに発見しました。 1978年から、NSCはローカル・エリア・ネットワークの間の橋を一連の不可欠の「リンクアダプター」に架け始めました。 これらはリンクされます。
Hardwick & Lekashman [Page 38] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[38ページ]RFC1044IP
adapters support common high speed communications media such
as Telco T1 circuits, private microwave, high speed
satellite links, and fiber optic point to point connections.
アダプターは、一般的な高速が通信業者T1回路や、個人的な電子レンジや、高速衛星中継や、光ファイバーポイントなどの通信機関であるとポイント接続にサポートします。
ATTACHMENT TO HOST COMPUTERS
ホストコンピュータへの付属
Network Systems' high speed interfaces use the attachment techniques of the manufacturer's highest speed peripheral controllers in order to achieve burst transfer rates of tens of megabits per second. These attachment techniques fall into three categories:
ネットワークSystemsの高速インタフェースは、1秒あたり何十ものメガビットのバースト転送率を達成するのにメーカーの最も高い速度周囲のコントローラの付属のテクニックを使用します。 これらの付属のテクニックは3つのカテゴリになります:
"MAINFRAME" DATA CHANNEL ATTACHMENT
+-----------+-------+ +------------+ | | | |
| | | |HYPERchannel+--+ | | |
| | +-------------------+ Network +--|-+ | |
| Host | I/O +-------------------+ Adapter +--|-|-+ |
| | | Standard host | +--|-|-|-+
| Computer |Control| data channel +------------+ | | | |
| | |
| | |
| | |
| | |
+-----------+-------+
「メインフレーム」データ・チャンネル付属+-----------+-------+ +------------+ | | | | | | | |HYPERchannel+--+| | | | | +-------------------+ ネットワーク+--|-+ | | | ホスト| 入出力+-------------------+ アダプター+--|-|-+ | | | | 標準のホスト| +--|-|-|-+ | コンピュータ|コントロール| データ・チャンネル+------------+ | | | | | | | | | | | | | | | | +-----------+-------+
The network adapter contains interface boards and firmware to be cabled to the manufacturer's data channel, such as would be done with a disk or tape controller. Mainframe network adapters do not emulate an existing manufacturer's device (such as a tape drive) but are supported by software which functions the channel and adapter to send and receive network messages.
ネットワークアダプターはディスクかテープコントローラと共にするようなメーカーのデータ・チャンネルに電報を打たれるインターフェースボードとファームウェアを含んでいます。 既存のメーカーのデバイス(テープドライブなどの)を見習いませんが、メインフレームネットワークアダプターによる機能するソフトウェアによってサポートされて、送って、受け取るチャンネルとアダプターがメッセージをネットワークでつなぐということです。
Models of HYPERchannel adapters are available for essentially all large scale computers worldwide.
世界中の本質的にはすべての大型コンピュータについて、HYPERchannelアダプターのモデルがあります。
Hardwick & Lekashman [Page 39] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[39ページ]RFC1044IP
MINICOMPUTER AND WORKSTATION ATTACHMENT
ミニコンピュータANDワークステーション付属
Since the network adapter contains lots of expensive, high speed logic, a different technique is used to provide attachment to minicomputers and workstations.
ネットワークアダプターが多くの高価で、高い速度論理を含んでいるので、異なったテクニックはミニコンピュータとワークステーションへの付属を提供するのに使用されます。
+-------------+ +---------------+ +--------------+
| | | | | |
| Minicomputer| | Supermini | | Workstation |
| | | | | |
+-----+-------+ +-------+-------+ +-------+------+
| | DMA | | | DMA | | DMA | |
| |control| | |control| |control| |
+-----+---++--+ +-------+--++---+ +--++---+------+
|| || ||
|| || ||
|+----------+ || +---------+|
+----------+| || |+---------+
|| || ||
+-++--+-----+--++-+--++-+
| | | | |
+-----+-----+-----+-----+
| x400 |
| Network Adapter |
| |
+-------+-+-+-+---------+
| | | |
------------------|-|-|-+----------------
------------------|-|-+------------------
------------------|-+--------------------
------------------+----------------------
+-------------+ +---------------+ +--------------+ | | | | | | | ミニコンピュータ| | スーパーミニコンピュータ| | ワークステーション| | | | | | | +-----+-------+ +-------+-------+ +-------+------+ | | DMA| | | DMA| | DMA| | | |コントロール| | |コントロール| |コントロール| | +-----+---++--+ +-------+--++---+ +--++---+------+ || || || || || || |+----------+ || +---------+| +----------+| || |+---------+ || || || +-++--+-----+--++-+--++-+ | | | | | +-----+-----+-----+-----+ | x400| | ネットワークアダプター| | | +-------+-+-+-+---------+ | | | | ------------------|-|-|-+---------------- ------------------|-|-+------------------ ------------------|-+-------------------- ------------------+----------------------
In this case, NSC provides a DMA controller designed for direct connection to that minicomputer's backplane bus. These DMA controllers accept functions and burst blocks of data from host memory to a channel cable that is connected to one of four ports on a "general purpose computer adapter." This adapter multiplexes transmissions to and from the HYPERchannel trunks from up to four attached processors.
この場合、NSCはダイレクト接続のためにそのミニコンピュータのバックプレーンバスに設計されたDMAコントローラを提供します。 これらのDMAコントローラは、ホストメモリから「汎用計算機アダプター」の4つのポートの1つに接続されるチャンネルケーブルに、機能を受け入れて、ブロックのデータを押し破きます。 このアダプターはトランクスとHYPERchannelトランクスから最大4つの付加プロセッサからトランスミッションを多重送信します。
Hardwick & Lekashman [Page 40] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[40ページ]RFC1044IP
NETWORK COPROCESSORS
ネットワークコプロセッサ
For about 10 different bus systems, Network systems provides a "smart" DMA controller containing onboard memory and a Motorola 68010 protocol processor.
およそ10個の異なったバス・システムのために、Networkシステムは車載にメモリを含む「賢い」DMAコントローラとモトローラ68010プロトコルプロセッサを提供します。
+------------+-----+---------------+-------+
| | | Coprocessor | | +--------+
| |Host | MC 68010 |Adapter+--------+ x400 |
| HOST |DMA | 256K memory | DMA +--------+ Adapter|
| | | | | +--------+
| Memory +-----+---------------+-------+
| |
+------------+
+------------+-----+---------------+-------+ | | | コプロセッサ| | +--------+ | |ホスト| M.C.68010|アダプター+--------+ x400| | ホスト|DMA| 256 Kメモリ| DMA+--------+ アダプター| | | | | | +--------+ | メモリ+-----+---------------+-------+ | | +------------+
This class of interface works through the network coprocessor's direct access to host memory. Network transmit and receive request packets are placed in a common "mailbox" area and extracted by the coprocessor. The coprocessor reads and writes system memory as required to service network requests in the proper order. The coprocessors currently provide a service to read or write network messages (called Driver service as it is more or less identical to HYPERchannel dumb DMA drivers) and a service for NETEX, which is NSC's OSI-like communications protocol.
このクラスのインタフェースはネットワークコプロセッサの直接アクセスをホストメモリに終えます。 ネットワークはパケットが一般的な「メールボックス」領域に置かれて、コプロセッサによって抽出されるという要求を送受信します。 コプロセッサは必要に応じて適切なオーダーにおけるサービスネットワーク要求にシステムメモリを読み書きします。 コプロセッサは、現在、NETEXのためにネットワークメッセージ(HYPERchannelの馬鹿なDMAドライバーには、それが多少同じであるので、Driverサービスと呼ばれる)とサービスを読むか、または書くためにサービスを提供します。(NETEXはNSCのOSIのような通信規約です)。
Hardwick & Lekashman [Page 41] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[41ページ]RFC1044IP
APPENDIX B. NETWORK SYSTEMS HYPERCHANNEL PROTOCOLS
付録B.ネットワーク・システムHYPERCHANNELプロトコル
The protocols implemented by NSC within its own boxes are designed for the needs of the different technologies. A compact summation of these protocols is:
それ自身の箱の中にNSCによって実装されたプロトコルは異なった技術の必要性のために設計されています。 これらのプロトコルのコンパクトな足し算は以下の通りです。
HYPERchannel B HYPERchannel A DATApipe
10 Mbits/second 50-200 Mbits/second 275 Mbits/second
+----------------------+----------------------+---------------------+
| |
| HYPERchannel network message |
| connectionless datagram protocol |
| |
+----------------------+----------------------+---------------------+
| "HYPERchannel | | |
| compatibility mode" | HYPERchannel A | DATApipe |
| Virtual circuit | reservation and | acknowledgment |
| estab. & control | flow control | & flow control |
+----------------------+ protocol | protocol |
| | | |
| Virtual Circuits | | |
| Flow Control | | |
+----------------------+----------------------+---------------------+
| CSMA / VT | CSMA / CA | |
| frame (datagram) | frame (datagram) | TDMA packet delivery|
| delivery and | delivery and | |
| acknowledgment | acknowledgment | |
+----------------------+----------------------+---------------------+
| | | Fiber optics |
| 75 ohm coax | 1-4 75 ohm coax | (various cable sizes|
| cable | cables | and xmission modes)|
+----------------------+----------------------+---------------------+
HYPERchannel B HYPERchannelはDATApipe10メガビット/秒50-200メガビット/秒275メガビット/第2の+です。----------------------+----------------------+---------------------+ | | | HYPERchannelネットワークメッセージ| | コネクションレスなデータグラムプロトコル| | | +----------------------+----------------------+---------------------+ | "HYPERchannel"| | | | 「互換性モード」| HYPERchannel A| DATApipe| | 仮想の回路| そして予約。| 承認| | estab。 コントロール| フロー制御| フロー制御| +----------------------+ プロトコル| プロトコル| | | | | | 仮想の回路| | | | フロー制御| | | +----------------------+----------------------+---------------------+ | CSMA/バーモント| CSMA/カリフォルニア| | | フレーム(データグラム)| フレーム(データグラム)| TDMAパケット配信| | そして配送。| そして配送。| | | 承認| 承認| | +----------------------+----------------------+---------------------+ | | | 光ファイバー| | オームがおだてる75| 1-4 オームがおだてる75| (様々なケーブルは|大きさで分けます| | xmissionモードに| ケーブルに電報を打ってください)| +----------------------+----------------------+---------------------+
Without getting into great detail on these internal protocols, a few points are particularly interesting to system designers:
これらの内部のプロトコルに関するすばらしい詳細に入らないで、システム設計者には、数ポイントが特におもしろいです:
o All three technologies supply the same interface to the host
computer or network coprocessor, a service to send and receive
network messages that are datagrams from the host's vantage in
that each contains sufficient information to deliver the message
in and of itself. Since this datagram and its header fields are
of paramount interest to the host implementor, it is discussed
in detail below.
o すべての3つの技術がホストコンピュータかネットワークコプロセッサに同じインタフェースを供給します、それぞれがそういうもののメッセージを提供できるくらいの情報を含んでいるので、ホストの優位からデータグラムであるネットワークメッセージを送って、受け取るサービス。 このデータグラムとそのヘッダーフィールドが最高のにホスト作成者におもしろいので、以下で詳細にそれについて議論します。
o All technologies use acknowledgments at a very low level to
determine if packets have been successfully delivered. In
addition to permitting a highly tuned contention mechanism for
the coax medium, it also permits HYPERchannel A to balance the
o すべての技術が、パケットが首尾よく提供されたかどうか決定するのに非常に低いレベルに承認を使用します。 aが主張メカニズムを非常に調整した可能にすることに加えて、媒体をおだててください、そして、それは、また、HYPERchannel Aがバランスをとることを許可します。
Hardwick & Lekashman [Page 42] RFC 1044 IP on Network Systems HYPERchannel February 1988
ネットワーク・システムHYPERchannel1988年2月のハードウィックとLekashman[42ページ]RFC1044IP
load over several coax cables -- a feat that has proven very
difficult on, for example, Ethernet.
数個の上の負荷はケーブルをおだてます--例えば、イーサネットで非常に難しいと判明した功績。
o All boxes go to some lengths to assure that resources exist
in the receiving box before actual transmission takes place.
HYPERchannel B uses a virtual circuit that endures for several
seconds of inactivity after one host first attempts to send a
message to the other. Traffic over this "working virtual
circuit" is flow controlled from source to destination and
buffer resources are reserved for the path.
o すべての箱が、実際のトランスミッションが行われる前にリソースが受信箱の中に存在することを保証するためにどんなことでもします。 HYPERchannel Bは1人のホストが、最初にメッセージをもう片方に送るのを試みた後に数秒の不活発のために続く仮想の回路を使用します。 この「働く仮想の回路」の上のトラフィックはソースから目的地まで制御された流れです、そして、バッファ資源は経路に予約されます。
HYPERchannel A exchanges frames at very high rates to determine that the receiver is ready to receive data and to control its flow as data moves through the network.
HYPERchannel Aは、受信機がデータを受け取って、データがネットワークを通して移行するとき流れを制御する準備ができていることを決定するために非常に高いレートでフレームを交換します。
DATApipe propagation time is relatively long compared to the time needed to send an internal packet of 2K-4K bytes. As a result, DATApipe controllers use a streamlined TP4-like transport protocol to assure delivery of frames between DATApipe boxes.
2K-4のKバイトの内部のパケットを送るのが必要であることで、時間と比べて、DATApipe伝播時間は比較的長いです。 その結果、DATApipeコントローラは、DATApipe箱の間のフレームを配送に保証するのに流線型のTP4のようなトランスポート・プロトコルを使用します。
REFERENCES
参照
[1] HYPERchannel is a trademark of Network Systems Corporation.
[1] HYPERchannelはNetwork Systems社の商標です。
[2] Plummer, D., "An Ethernet Address Resolution Protocol",
RFC-826, Symbolics, September 1982.
[2] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC-826、信条学、1982年9月。
[3] DATApipe is a registered trademark of Network Systems
Corporation.
[3] DATApipeはNetwork Systems社の登録商標です。
Hardwick & Lekashman [Page 43]
ハードウィックとLekashman[43ページ]
一覧
スポンサーリンク
