RFC687 日本語訳

0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. June 1975. (Format: TXT=6013 bytes) (Obsoleted by RFC0704) (Updated by RFC0690) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                              David C. Walden (WALDEN@BBN)
Request for Comments: 687                                              Jun 1975
NIC #32654

ウォルデン( WALDEN@BBN )がコメントのために要求するワーキンググループデヴィッドC.をネットワークでつないでください: 687 Jun1975NIC#32654

          IMP/Host and Host/IMP Protocol Change

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

This note 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 com unity, 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 almost 60 IMPs).

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

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 five 16-bit words. This will provide space for necessary
field expansions and additions.

1. リーダーサイズを広げました。 リーダーは2〜5つの拡張16ビットの単語になるでしょう。 これは必要な分野拡張と追加にスペースを提供するでしょう。

2. Expanded Address Field. The address field will be expanded
to 24 bits, 16 bits of IMP address and 8 bits of host address.
This expansion is more than adequate for any foreseeable ARPA
Network growth.

2. 拡張アドレス分野。 アドレス・フィールドは24ビット、IMPアドレスの16ビット、およびホスト・アドレスの8ビットに広げられるでしょう。 どんな予見できるアーパネットの成長にも、この拡張は十二分に適切です。

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 13 bits wide.

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

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),
unordered messages (i.e., the present type-3 messages), a message
stream requiring guaranteed capacity, etc. Note that only some
of these facilities will be available in the near term.

4. タイプがさばく取り扱いを広げました。 現在優先権を見分けるのに使用される取り扱いタイプ分野と非至急メッセージストリームなどは8ビットに広げられるでしょう。 この拡張分野はホストの組の間の異なった取り扱いの特性を持っている多くの平行なメッセージストリームの可能性に備えるでしょう。 例えば、優先権、非優先権、異なった数の1メッセージあたりのパケット(以下を見る)、順不同のメッセージ(すなわち、現在のタイプ-3つのメッセージ)、保証された容量を必要とするメッセージストリームなど これらのいくつかの施設だけが近いうちに利用可能になることに注意してください。

5. Source Host Control of Packets per Message. The possibility
will exist for the source host to specify a message stream which

5. 1メッセージあたりのパケットの送信元ホストコントロール。 メッセージを指定する送信元ホストがどれを流すかので、可能性は存在するでしょう。

                                -1-


-1-

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 messages. This will help users who need both
low delay and high throughput.

与えられた数のマルチパケットメッセージ(1メッセージあたり1メッセージあたり2つのパケットか5つのパケットのe.g)あたりのパケットを使用するでしょう。 IMPネットワークが再アセンブリ目的に8つのパケットバッファを使用する必要はないので、プレゼントのように、これはそのようなメッセージのための、より良いサービスをもたらすかもしれません。 これは低い遅れと高生産性の両方を必要とするユーザを助けるでしょう。

6.    Unordered (type-3) Message Change. Unordered messages will
be indicated by a handling type rather than by a 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)メッセージ変化。 順不同のメッセージはプレゼントのようにメッセージタイプでというよりむしろ取り扱いタイプによって示されるでしょう。 これはすべてのメッセージのホストアクセス制御能力をチェックする必要性と互換性があります。 これはわずかな後方の不一致をおよそ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
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
com unicate with hosts using the new format and the reverse.
Finally, it will be possible to convert the leader format from
old to new or the reverse without knowledge of the message type.

9. 後方の互換性。 予見できる未来がホストソフトウェアのゆるやかなphaseoverを許容するように、古くて新しい形式はIMPsで平行でサポートされるでしょう。 ホストは、古いか新しい形式が使用されているかどうかことであるとIMPに指定できるでしょう。 したがって、ホストが指定するのは、デバッグ目的のために2つのモードを前後に切り換えながら、可能でしょう。 使用されるべきモードの仕様はホストでの形式の適切な選択でIMP NOPメッセージに可能になるでしょう。 IMPはIMPが受け取ったIMP NOPメッセージにホストのモードを使用するでしょう。 さらに、到着するならそれらを捨てるより他の形式メッセージに関する以上を知る必要はなくて、ホストは古いか新しい形式を使用に選択するかもしれません。 IMPは各タイプがホストに与えるいくつかのNOPメッセージを送るのによる選択を初期化するでしょう。 新しい形式を実装しないホストはできないでしょうが、どこでも、可能であるところで63以上、IMPsがそうするIMP-数があるIMPsの上のホストに演説するには、ホストと共にcom unicateに新しい形式と逆を使用することで古い方式を使用することでホストを可能にするのに必要な変換をしてください。 最終的に、メッセージタイプに関する知識なしで古いのから新しくなるまでのリーダー形式か逆を変換するのは可能でしょう。

11.    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.

11. 非ブロッキングホスト・インターフェース。 IMPがホストからホスト・インターフェースを妨げないでメッセージを拒否できるメカニズムを提供するでしょう。 このメカニズムは、IMPが拒否されたメッセージを送って、次に、メッセージを再送するようにホストに頼むために必要なリソースを集めるのを可能にするでしょう。 最終的に、ホストは、メッセージを送ることができると尋ねることが許可されていて、それが実際に送られるべきメッセージを必要としないで可能であるときに、通知されて、拒否されるでしょう。

12.   Maximum Message Length. The maximum number of bits of data
in a message may be reduced by a few bits.

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

                                -2-


-2-

     We are presently working out the details of an
implementation plan for making the above changes to the IMP
software. We will distribute an implementation schedule and
other necessary information (e.g., format details) in plenty of
time for hosts desiring to use the new protocol as soon as it is
available to implement in time.

私たちは現在、IMPソフトウェアへの上の変更を行うための実行計画について詳しいことを決めることです。 私たちはそれが時間内に実装するために利用可能であるとすぐに、新しいプロトコルを使用することを望んでいるホストのための多くの時間、遂行スケジュールと他の必要事項(例えば、形式の詳細)を分配するつもりです。

                                  -3-

-3-

一覧

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

スポンサーリンク

iusリポジトリで公開されているパッケージの一覧

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

上に戻る