RFC263 日本語訳

Network Working Group                             A. McKenzie
Request for Comments #263                         BBN
NIC #7811                                         17 December 1971
Categories:  B.1, C.2, I.1
Updates:  none
Obsoletes:  none

コメント#263BBN NIC#7811の1971年12月17日のカテゴリを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: B.1、C.2、I.1アップデート: Obsoletesのいずれも:でない なし

                     "VERY DISTANT" HOST INTERFACE

「非常に遠方」のホスト・インターフェース

     The normal method of connecting a Host computer to the ARPA
Network is, and will continue to be, placing an IMP at the Host
site and making a short-distance hard-wire connection.  However,
during the past several months we have become increasingly aware
of the occasional desire to interface a Host to some IMP via a
long-distance connection (where long-distance, in this context,
is any cable run longer than 2000 feet but may typically be tens
of miles) via either a hard-wire or telephone circuit.  We believe
that any good solution to the general problem of interfacing Hosts
to IMPs must satisfy at least the following criteria:

Hostコンピュータをアーパネットに接続する正常なメソッドは、あって、IMPを置いて、Hostサイトにあって、短距離に接続を配線させるのに続くでしょう。 しかしながら、過去数カ月、私たちはますます固いワイヤか電話回線のどちらかを通る長距離の接続(このような関係においては、長距離であるところでは2000フィートより長い間のどんな電路ですが、通常、何十マイルであるかもしれませんも)でいくらかのIMPにHostを連結する時々の願望を意識するようになっています。 私たちは、IMPsにHostsを連結するという一般的問題へのどんな良い解決も少なくとも以下の評価基準を満たさなければならないと信じています:

     1)  The characteristics of the connection should be such
         that the undetected error rate can be expected to be
         extremely low.

1) 接続の特性は見逃し誤り率が非常に低いと予想できるようにものであるべきです。

     2)  The bandwidth of the connection should not be
         intrinsically limited to a low value.

2) 本質的に接続の帯域幅を低値に制限するべきではありません。

     3)  The nature of the connection should be such that the
         Host may establish multiple network "conversations",
         i.e., it should have all the power of a normal Host
         connection.

3) 接続の本質がそのようなものであるべきであるので、それには、Hostは複数のネットワーク「会話」を設立するかもしれなくて、すなわち、普通のHost接続のすべてのパワーがあるべきです。

These criteria were briefly discussed in our earlier RFC #241
(NIC #7671), "Connecting Computers to MLC Ports."

「MLCポートにコンピュータを接続し」て、私たちの以前のRFC#241(NIC#7671)で簡潔にこれらの評価基準について議論しました。

     After a careful review of the various possibilities for "very
distant" Host connection, we have arrived at a preliminary design
for this type of interface which we believe should prove
satisfactory with regard to the criteria above.  Although
detailed specifications will not be available for some time, the
basic elements of the design are as follows:

「非常に遠方」のHost接続に、様々な可能性の慎重なレビューの後に、私たちは上の評価基準に関して満足できると判明するべきであると信じているこのタイプのインタフェースのために予備のデザインに到着しました。 仕様詳細はしばらく利用可能にならないでしょうが、デザインの基本要素は以下の通りです:

                                                                [Page 1]

Transmissions will be full-duplex and will use the same
Binary Synchronous format that is presently used in inter-IMP
communication.  At the IMP end, a hardware interface identical
in type, but not necessarily in speed, to the usual IMP 50 kilobit
modem interface will be used.  This interface frames blocks of
outgoing data with special characters and appends a 24 bit cyclic
redundancy check (CRC).  It de-frames and checks incoming blocks
which must be of similar format.  The Host must provide mating
formatting, de-formatting and checking facilities at its end.

[1ページ] トランスミッションは、全二重であり、現在相互IMPコミュニケーションで使用されるのと同じBinary Synchronous形式を使用するでしょう。 IMPエンドのときに、必ず速度ではなく、タイプが普通のIMP50キロビットモデム・インタフェースと同じハードウェア・インタフェースは使用されるでしょう。 このインタフェースは、特殊文字でブロックの発信データを縁どっていて、24ビットの周期冗長検査(CRC)を追加します。 それは、同様の形式のものであるに違いない入って来るブロックを、反-縁どっていて、チェックします。 Hostは終わりに施設をフォーマットして、反-フォーマットして、チェックする交配を提供しなければなりません。

     In conjunction with the CRC creation and checking, the IMP
will be provided with a small amount of "retransmission" software
as a front (i.e., Host side) end for the usual Host/IMP interface
software. The retransmission scheme, although not presently
completely defined, will be based on positive acknowledgment/
timeout techniques.

CRC作成と照合に関連して、普通のHost/IMPインタフェースソフトウェアのための前(すなわち、Host側)の終わりとして少量の"「再-トランスミッション」"ソフトウェアをIMPに提供するでしょう。 現在、完全に定義されるというわけではありませんが、「再-トランスミッション」体系は肯定応答/タイムアウトのテクニックに基づくでしょう。

     The Host will be required to provide a front (i.e. IMP side)
end to its NCP which can generate CRCs and test for CRC errors,
provide simple retransmission logic, etc.  This front end may be
implemented in Host software, by means of special purpose hardware,
in a minicomputer, or in any other way which the Host organization
finds reasonable.

HostはCRC誤りのためのCRCsとテストを生成して、簡単な「再-トランスミッション」論理を提供できるなどNCPの前(すなわち、IMP側)の終わりを提供しなければならないでしょう。 このフロントエンドはHostソフトウェアで実装されるかもしれません、ミニコンピュータ、または妥当であることがHost組織によってわかるいかなる他の方法による専用ハードウェアによる。

     This new type of interface will be completely documented,
from both a hardware and software point of view, as soon as the
detailed design is completed.  This documentation will probably
take the form of an update to BBN report No. 1822.

両方から、この新しいタイプのインタフェースは、完全に記録されていてハードウェアとソフトウェア観点になるでしょう、詳細なデザインが完成するとすぐに。 このドキュメンテーションはたぶんBBNレポートNo.1822にアップデートの形を連れて行くでしょう。

     We will be happy to discuss this type of interface with any
interested organization, although it should be remembered that
detailed design is not yet completed.

どんな関心がある組織とのこのタイプのインタフェースについても議論するでしょう、詳細なデザインがまだ完成していなかったのが覚えていられるべきですが。

AMcK:jm

AMcK: jm

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 12/96 ]

                                                                [Page 2]

[2ページ]