RFC704 日本語訳

Network Working Group                                Paul J. Santos, Jr.  (BBN)
Request for Comments 704                                              Sept 1975
NIC #33490

ワーキンググループのポール・J.サントスをネットワークでつないでください、そして、Jr.(BBN)はコメント704のために1975年9月のNIC#33490を要求します。

             IMP/Host and Host/IMP Protocol Change

悪童/ホストとホスト/悪童プロトコル変化

This note is a revision of RFC 687 and sketches the design
of an expansion to the IMP/host and host/IMP protocol which will
include among other things the possibility of addressing hosts on
more than 63 IMPs. Our intention in this expansion is to correct
certain existing limits without fundamental changes in the
philosophy of the IMP/host protocol; i.e., while many issues
which would represent fundamental changes to the IMP/host
protocol are presently under discussion in the world-wide
packet-switching community, we are not able to undertake massive
fundamental changes on a time scale compatible with the short
term needs for network improvement (e.g., already there are 62
IMPs).

この注意は、RFC687の改正であり、63IMPsでホストに演説する特に可能性を含んでいるIMP/ホストとホスト/IMPプロトコルに拡張のデザインについてスケッチします。 この拡張における私たちの意志はIMP/ホストプロトコルの哲学における根本的変化なしである既存の限界を修正することです。 すなわち、現在、IMP/ホストプロトコルへの根本的変化を表す多くの問題は世界的なパケット交換共同体に議論中でありますが、私たちはネットワーク改良のための必要性という短い期間とのコンパチブルタイムスケールで大規模な根本的変化を引き受けることができません(例えば、既に、62IMPsがあります)。

The following paragraphs cover each of the major
characteristics of the expanded protocol. A knowledge of Section
3 of BBN Report 1822 is assumed. As is discussed below, the
expanded protocol is backwards compatible.

以下のパラグラフはそれぞれの拡張プロトコルの主要な特性をカバーしています。 BBN Report1822のセクション3に関する知識は想定されます。 以下で議論していて、そのままで、拡張プロトコルは後方にそうです。互換性がある。

1. Expanded Leader Size. The leader will be expanded from two
to six 16-bit words. This will provide space for necessary field
expansions and additions. The expansion of the IMP/host
(host/IMP) leader to 96 bits from 32 causes word-boundary
problems for some hosts. To be able to deliver messages between
two hosts of which one is using the old protocol and the other
the new, without shifting the data in the IMP words, it is
necessary that the data (i.e. the first bit of the host/host
leader) start at an even multiple of 8-bit bytes from the
beginning of the entire message. On the other hand, each host
prefers (in fact requires, if no shifting is to be performed by
the host) that the combined host/IMP (IMP/host) and host/host
leaders occupy some integral number of machine words (defined as
the smallest sequence of bits that can be independently accessed
by the host/IMP interface). With a total host/IMP (IMP/host) and
host/host leader of 136 bits, only machines with 8-, 16-, 32-,
and 64-bit words will find the leader size suitable. To simplify
things for machines with other word lengths, a provision of the
protocol permits each host to tell its IMP a number of 16-bit
padding words to be inserted between the host/IMP (IMP/host) and
host/host leaders. This padding will be stripped off during
host-to-IMP processing by the IMP, and added in during
IMP-to-host processing. Thus, for instance, 24-bit machines can
specify one 16-bit word of padding, and 10- and 36-bit machines
can specify five 16-bit words.

1. リーダーサイズを広げました。 リーダーは2〜6つの拡張16ビットの単語になるでしょう。 これは必要な分野拡張と追加にスペースを提供するでしょう。 32から96ビットへのIMP/ホスト(ホスト/IMP)リーダーの拡張は何人かのホストのために語境界問題を引き起こします。 IMP単語のデータを移行させないでどれが古いプロトコルともう片方を使用するかに関する2人のホストの間のメッセージに新しさを提供できるように、データ(すなわち、ホスト/ホストリーダーの最初のビット)が全体のメッセージの始まりからの8ビットのバイトの同等の倍数で始まるのが必要です。 他方では、各ホストが好む、(移行でないのがホスト) それによって実行されるために、結合したホスト/IMP(IMP/ホスト)とホスト/ホストリーダーが何らかの整数の機械ワード(ホスト/IMPインタフェースから独自にアクセスできるビットの最も小さい系列と定義される)を占領するということであるなら、事実上、必要です。 総ホスト/IMP(IMP/ホスト)とホスト/ホストと共に、136ビット、8、16があるマシンだけ、32、および64ビットの単語のリーダーは、リーダーサイズが適当であることがわかるでしょう。 マシンのために他の語長でものを簡素化するために、プロトコルに関する条項は、各ホストが、ホスト/IMP(IMP/ホスト)とホスト/ホストリーダーの間に挿入されるように多くの16ビットの詰め物が言い表すIMPに言うことを許可します。 この詰め物は、ホストからIMPへの処理の間、IMPによって全部はぎ取られて、IMPからホスト・プロセッシングの間、加えられるでしょう。 このようにして、例えば、24ビットのマシンは詰め物の1つの16ビットの単語を指定できます、そして、10と36ビットのマシンは5つの16ビットの単語を指定できます。

2. Expanded Address field. The address field will be expanded
to 32 bits, 16 bits of IMP address, 0 bits of host address, and 8
bits for (future) network address. This expansion is adequate
for any forseeable ARPA Network growth.

2. Address分野を広げました。 アドレス・フィールドは32ビット、IMPアドレスの16ビット、ホスト・アドレスの0ビット、および(将来)のネットワーク・アドレスのための8ビットに広げられるでしょう。 どんなforseeableアーパネットの成長にも、この拡張は適切です。

                                 -1-

-1-

3. New Message Length Field. A new field will be added which
will allow the source host to optionally specify the message
length (in bits) to the IMP subnetwork. The IMP subnetwork may
be able to use this information (when available) to better
utilize network buffer storage. The destination host may also be
able to use this information to better utilize its buffer
storage. This field will be 16 bits wide. There will be
provision for expanding the maximum number of packets per message
to 16 from the present 8.

3. 新しいメッセージ長分野。 送信元ホストが任意に、メッセージ長(ビットの)をIMPサブネットワークに指定できる新しい分野は加えられるでしょう。 IMPサブネットワークは、ネットワーク緩衝記憶装置をよりよく利用するのに、この情報(利用可能であるときに)を使用できるかもしれません。 また、あて先ホストは、緩衝記憶装置をよりよく利用するのにこの情報を使用できるかもしれません。 この分野は幅16ビットでしょう。 1メッセージあたりのパケットの最大数を現在の8から16に広げることへの支給があるでしょう。

4. Expanded Handling Type Field. The handling type field which
now is used to distinguish between priority and non-priority
message streams, etc., will be expanded to eight bits. This
expanded field will provide for the possibility of a number of
parallel message streams having different handling
characteristics between pairs of hosts; e.g., priority,
non-priority, varying numbers of packets per message (see below),
a message stream requiring guaranteed capacity, etc. Only the
old-style priority and non-priority handling types will be
available in the initial implementation of the expanded protocol.

4. タイプがさばく取り扱いを広げました。 現在優先権を見分けるのに使用される取り扱いタイプ分野と非至急メッセージストリームなどは8ビットに広げられるでしょう。 この拡張分野はホストの組の間の異なった取り扱いの特性を持っている多くの平行なメッセージストリームの可能性に備えるでしょう。 例えば、優先権、非優先権、異なった数のメッセージ(以下を見る)あたりのパケット、保証された容量を必要とするメッセージストリームなど 古いスタイル優先権と非優先権取り扱いタイプだけが拡張プロトコルの初期の実装で手があくでしょう。

5. Source Host Control of Packets per Message. The possibility
will exist for the source host to specify a message stream which
will use a given number of packets per multi-packet message (e.g,
two packets per message or five packets per message). Since the
IMP network will not have to use eight packet-buffers for
reassembly purposes, as at present, this may result in better
services for such hosts. This will help users who need both low
delay and high throughput. Since this facility is orthogonal to
and of lower priority than the address expansion, it will be
implemented after the other proposed basic changes.

5. 1メッセージあたりのパケットの送信元ホストコントロール。 送信元ホストが与えられた数のマルチパケットメッセージ(1メッセージあたり1メッセージあたり2つのパケットか5つのパケットのe.g)あたりのパケットを使用するメッセージストリームを指定するように、可能性は存在するでしょう。 IMPネットワークが再アセンブリ目的に8つのパケットバッファを使用する必要はないので、プレゼントのように、これはそのようなホストには、より良いサービスをもたらすかもしれません。 これは低い遅れと高生産性の両方を必要とするユーザを助けるでしょう。 この施設が優先度とアドレス拡張より低い優先度で直交しているので、もう片方が基本的な変化を提案した後に、それは実装されるでしょう。

6. Unordered (type-3) Message Change. Unordered messages will
be indicated by a subtype of the type O message, rather than by a
separate message type as at present. This is compatible with the
need to check the host access control capabilities of all
messages. This will provide a slight backward incompatibility
for the three or so hosts which presently use type-3 messages in
their research.

6. 順不同の(タイプ-3)メッセージ変化。 順不同のメッセージはプレゼントのように別々のメッセージタイプでというよりむしろタイプOメッセージの「副-タイプ」によって示されるでしょう。 これはすべてのメッセージのホストアクセス制御能力をチェックする必要性と互換性があります。 これはわずかな後方の不一致をおよそ3人のホストに供給するでしょう(現在、彼らの研究にタイプ-3つのメッセージを使用します)。

7. Change in Format of Fake Host Addresses. The For/From IMP
bit will be eliminated. The fake host addresses will be the four
highest host numbers (e.g., IMP Teletype will be host 252).

7. にせのホスト・アドレスの形式では、変化してください。 IMPビットからのFor/は排除されるでしょう。 にせのホスト・アドレスは4つの最も高いホスト番号(例えばIMPテレタイプはホストにな252る)でしょう。

8. Addition of a Parameter to the IMP to Host NOP. The IMP to
host NOP will have added to it a parameter specifying the address
(IMP and host number) of the host.

8. ホストNOPへの悪童へのパラメタの追加。 ホストNOPへのIMPはホストのアドレス(IMPとホスト番号)を指定するパラメタをそれに加えてしまうでしょう。

9. Backward Compatibility. The old and new formats will be
supported in parallel in the IMPs for the foreseeable future to
allow gradual phaseover of host software. A host will be able to
specify to its IMP whether the old or new formats are to be used;
thus, it will be possible for the host to specify switching back
and forth between the two modes for debugging purposes. The

9. 後方の互換性。 予見できる未来がホストソフトウェアのゆるやかなphaseoverを許容するように、古くて新しい形式はIMPsで平行でサポートされるでしょう。 ホストは、古いか新しい形式が使用されているかどうかことであるとIMPに指定できるでしょう。 したがって、ホストが指定するのは、デバッグ目的のために2つのモードを前後に切り換えながら、可能でしょう。 The

                                 -2-

-2-

specification of the mode to be used will be possible via a
proper choice of format in the host to IMP NOP message; the IMP
will use the mode of the host to IMP NOP message the IMP has
received. Further, a host may select to use either the old or
new format without needing to know more about the other format
messages than to discard them should they arrive. The IMP will
initialize by sending several NOP messages of each type to give
the hosts its choice. Although a host not implementing the new
format will not be able to address hosts on IMPs with IMP-number
greater than 63, the IMPs will wherever possible do the
conversion necessary to permit hosts using the old format to
communicate with hosts using the new format and the reverse.

使用されるべきモードの仕様はホストでの形式の適切な選択でIMP NOPメッセージに可能になるでしょう。 IMPはIMPが受け取ったIMP NOPメッセージにホストのモードを使用するでしょう。 さらに、到着するならそれらを捨てるより他の形式メッセージに関する以上を知る必要はなくて、ホストは古いか新しい形式を使用に選択するかもしれません。 IMPは各タイプがホストに与えるいくつかのNOPメッセージを送るのによる選択を初期化するでしょう。 新しい形式を実装しないホストはできないでしょうが、どこでも、可能であるところで63以上、IMPsがそうするIMP-数があるIMPsの上のホストに演説するには、古い方式を使用しているホストがホストとコミュニケートすることを新しい形式と逆を使用することで許可するのに必要な変換をしてください。

1O. Non-blocking Host Interface. A mechanism will be provided
which allows the IMP to refuse a message from a host without
blocking the host interface. This mechanism will permit the IMP
to gather the necessary resources to send the refused message and
then ask the host to resend the message. Finally, the host will
be permitted to ask to be able to send a message and be notified
when it is possible without requiring the message to actually be
sent and refused. Again, as in point 5 above, this facility will
be added after the other more basic changes have been
implemented.

1O。 非ブロッキングホスト・インターフェース。 IMPがホストからホスト・インターフェースを妨げないでメッセージを拒否できるメカニズムを提供するでしょう。 このメカニズムは、IMPが拒否されたメッセージを送って、次に、メッセージを再送するようにホストに頼むために必要なリソースを集めるのを可能にするでしょう。 最終的に、ホストは、メッセージを送ることができると尋ねることが許可されていて、それが実際に送られるべきメッセージを必要としないで可能であるときに、通知されて、拒否されるでしょう。 一方、他の、より基本的な変化が実装された後に上では、この施設がポイント5のように加えられるでしょう。

11. Maximum Message Length. The maximum number of bits of data
in a single-packet message may be reduced by a few bits.

11. 最大のメッセージ長。 単一のパケットメッセージのビットのデータの最大数は数ビットによって減少させられるかもしれません。

We are now producing a draft version of the necessary
changes to Report 1822 and will circulate it so that host
programmers can begin to make their preparations.

私たちは、今、Report1822への必要な改革の草案バージョンを生産していて、ホストプログラマが彼らの準備をし始めることができるように、それを循環させるつもりです。

                                 -3-

-3-