RFC730 日本語訳

RFC 730                                                        20 May 77
Extensible Field Addressing

RFC730の1977年5月20日の広げることができる分野アドレシング

Network Working Group                                         Jon Postel
Request for Comments: 730                                        USC-ISI
NIC: 40400                                                   20 May 1977

コメントを求めるワーキンググループジョンポステルRequestをネットワークでつないでください: 730USC-ISI NIC: 40400 1977年5月20日

                      Extensible Field Addressing

広げることができる分野アドレシング

Introduction

序論

This memo discusses the need for and advantages of the expression of
addresses in a network environment as a set of fields.  The suggestion
is that as the network grows the address can be extended by three
techniques: adding fields on the left, adding fields on the right, and
increasing the size of individual fields.  Carl Sunshine has described
this type of addressing in a paper on source routing [1].

このメモが必要性について議論して、aとしてのネットワーク環境における、アドレスの式の利点がセットした、分野。 提案はネットワークが成長するのに従って3つのテクニックでアドレスを広げることができるということです: 左で分野を加えて、右で分野を加えて、個々の分野のサイズを増強します。 カール・サンシャインはソースルーティング[1]で論文のアドレシングのこのタイプについて説明しました。

Motivation

動機

Change in the Host-IMP Interface

ホスト悪童インタフェースで変化してください。

The revised Host-IMP interface provides for a larger address space for
hosts and IMPs [2].  The old inteface allowed for a 2 bit host field and
a 6 bit IMP field.  The new interface allows a 8 bit host field and a 16
bit IMP field.  In using the old interface it was common practice to
treat the two fields as a single eight bit quantity.  When it was
necessary to refer to a host by number a decimal number was often used.
For example host 1 on IMP 1 was called host 65. Doug Wells has pointed
out some of problems associated with attempting to continue such useage
as the new interface comes into use [3].  If a per field notation had
been used no problems would arise.

改訂されたHost-IMPインタフェースはホストとIMPs[2]のための、より大きいアドレス空間に備えます。 古いintefaceは2ビットのホスト分野と6ビットのIMP分野を考慮しました。 新しいインタフェースは8ビットのホスト分野と16ビットのIMP分野を許容します。 古いインタフェースを使用するのにおいて、8ビットのただ一つの量として2つの分野を扱うのは、一般的な習慣でした。 数に従ってホストについて言及するのが必要であったときに、10進数はしばしば使用されました。 例えばIMP1の上のホスト1はホスト65と呼ばれました。 ダグ・ウェルズは、新しいインタフェースが入るようなuseageを続けているのを試みると関連している問題のいくつかが[3]を使用すると指摘しました。 分野記法あたりのaが使用されたなら、問題は全く起こらないでしょう。

Some examples of old and new host numbers are:

古くて新しいホスト番号に関するいくつかの例は以下の通りです。

  Host Name       Host IMP old #   new #
  --------------------------------------
  SRI-ARC            0   2     2       2
  UCLA-CCN           1   1    65   65537
  ISIA               1  22    86   65558
  ARPA-TIP           2  28   156  131100
  BBNA               3   5   197  196613

Name Host IMPの古い#新しい#、を接待してください。-------------------------------------- 様アーク0 2 2 2UCLA-CCN1 1 65 65537ISIA1 22 86 65558アルパチップ2 28 156 131100BBNA3 5 197、196613

Multinetwork Systems

Multinetworkシステム

The prospect of interconnections of networks to form a complex
multinetwork system poses additional addressing problems.  The new
Host-IMP interface specification has reserved fields in the leader to

複雑な「マルチ-ネットワーク」システムを形成するネットワークのインタコネクトの見通しは追加アドレシング問題リーダーのインターフェース仕様が予約した分野新しいHost-IMPにポーズをとらせます。

Postel                                                          [page 1]

ポステル[1ページ]

RFC 730                                                        20 May 77
Extensible Field Addressing

RFC730の1977年5月20日の広げることができる分野アドレシング

carry network addresses  [2].  There is experimental work in progress on
interconnecting networks [4, 5, 6]. We should be prepared for these
extensions to the address space.

ネットワーク・アドレス[2]を運んでください。 ネットワーク[4、5、6]とインタコネクトするときの進行中の実験研究があります。 私たちはこれらの拡大のためにアドレス空間に用意ができているべきです。

The addressing scheme should be expandable to increase in scope when
interconnections are made between complex systems.

アドレシング体系はインタコネクトが複合システムの間で作られているとき、範囲を増やすのにおいて拡張可能であるべきです。

Multiprocessor Hosts

マルチプロセッサホスト

There may be configurations of hardware that could be interfaced to a
network as a single host that in fact contain multiple processors.
Tasks could be associated with processors such that it is desirable to
dispatch network messages associated with certain sockets or message-ids
to certain processors.  For example it might be desirable to service all
Telnet use from one processor and all FTP use from a different
processor.

事実上、複数のプロセッサを含む独身のホストとしてネットワークに連結できたハードウェアの構成があるかもしれません。 タスクをプロセッサに関連づけることができたので、あるソケットに関連しているネットワークメッセージかメッセージイドをあるプロセッサに派遣するのは望ましいです。 例えば、すべてのTelnetが1台のプロセッサとすべてのFTPと異なったプロセッサから使用を使用するのは、サービスに望ましいかもしれません。

The addressing scheme should be expandable to explicitly address the
fine structure within a host when that is desirable.

アドレシング体系はそれが望ましいときに、ホストの中で明らかに微細構造を扱うのにおいて拡張可能であるべきです。

Some examples where such fine structure addressing would have been
useful in the ARPANET are:

そのような微細構造アドレシングがアルパネットで役に立っているいくつかの例は以下の通りです。

  At ISI, we have the capability of emulating computers using the PRIM
  system [7].  For many applications it is desirable to add the emulated
  host to the network.  Since the emulation is carried out under control
  of a program operating under Tenex, we have a host within a host.
  Extensible addressing of hosts would provide the necessary handle.

ISIでは、私たちはPRIMシステム[7]を使用することでコンピュータを見習う能力を持っています。 多くのアプリケーションに、見習われたホストをネットワークに追加するのは望ましいです。 エミュレーションがTenexの下で作動するプログラムのコントロールの下で行われるので、私たちには、ホストがホストの中にいます。 ホストの広げることができるアドレシングは必要なハンドルを提供するでしょう。

  SCRL once had a PDP-11 connected by VDH to an IMP at UCSB.  It became
  necessary to add a second PDP-11 to the network.  The two PDP-11s were
  already physically connected and it would have been a simple matter to
  have the first serve as a multiplexor for both.  However, because of
  the limitations in the network addressing structure, there was no way
  to identify the two hosts to other sites on the network.  A new IMP
  had to be installed!

SCRLはVDHにUCSBでPDP-11をIMPに一度接続させました。 第2のPDP-11をネットワークに追加するのは必要になりました。 2 11PDP-年代は既に物理的に接続されました、そして、両方のためのマルチプレクサーとして最初のサーブを持つのは、簡単な事柄だったでしょう。 しかしながら、構造を扱うネットワークにおける制限のために、ネットワークに関する他のサイトに2人のホストを特定する方法が全くありませんでした。 新しいIMPはインストールされなければなりませんでした!

  In many other cases, it is desirable to have two hosts share the same
  front end to the network.  With the current limitation, one IMP port
  must be consumed for each host.

他の多くの場合では、2人のホストに同じフロントエンドをネットワークと共有させるのは、望ましいです。 現在の制限で、各ホストのために1つのIMPポートを消費しなければなりません。

Postel                                                          [page 2]

ポステル[2ページ]

RFC 730                                                        20 May 77
Extensible Field Addressing

RFC730の1977年5月20日の広げることができる分野アドレシング

Proposal

提案

The necessary solution to the problem posed by the change in the
Host-IMP inteface is to always represent the address by fields.  This
solution provides for a natural growth into an internetwork environment,
and allows explicit addressing of the fine structure within a host if
that is desirable.

Host-IMP intefaceにおける変化によって引き起こされた問題への必要な解決は分野のそばにいつもアドレスを表すことです。 このソリューションは、インターネットワーク環境に自然の生長物に備えて、それが望ましいなら、ホストの中に微細構造の明示番地指定を許容します。

The fields should be written in a natural way, and i believe that means
that the most general field should come first with additional fields
specifying more and more details of the address.  In the current case
this would lead to the following fields:

分野は自然な方法で書かれているべきです、そして、私は追加分野がアドレスのますます多くの詳細を指定している状態で最も一般的な野原が一番になるはずであるとその手段に信じています。 現在の場合では、これは以下の分野に通じるでしょう:

Network / IMP / Host / Message-Identifier

メッセージネットワーク/悪童/ホスト/識別子

A problem with simple field addressing is the desire to specify only the
fields that are necessary given the local context.  A program
interpreting the address is then unsure what the first field represents.
Some clues are needed in the address specification for correct parsing
to be possible.  Dave Crocker has described a syntax for a similar
problem in network access of data [8].

簡単な分野アドレシングに関する問題はローカルの関係を考えて、必要な分野だけを指定する願望です。 アドレスを解釈するプログラムはその時、最初の分野が何を表すかが不確かです。 いくつかの手がかりが、正しい構文解析が可能であるのにアドレス指定で必要です。 デーヴ・クロッカーはデータ[8]のネットワークアクセスにおける同様の問題なので構文について説明しました。

Specific Sugestion

特定のSugestion

Specifically i suggest that we adopt a field based extensible address
scheme where each field is separated from its neighbors by a delimiter
character and each field has a name.  When an address is specified the
name of the most general field must also be indicated.

明確に私は、各野原がデリミタキャラクタによって隣人から分離されて、各分野には名前があるところに私たちが分野のベースの広げることができるアドレス体系を採用することを提案します。 また、アドレスが指定されるとき、最も一般的な分野の名前を示さなければなりません。

  Definitions:

定義:

    <address> ::= <field-name> ":" <fields>

<アドレス>:、:= 「<フィールド名>」:、」 <は>をさばきます。

    <field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"

<フィールド名>:、:= 「ネット」| 「悪童」| 「ホスト」| 「MESSAGE ID」

    <fields> ::= <field> | <field> "/" <fields>

<は>をさばきます:、:= <分野>。| 」 「<分野>」/<は>をさばきます。

    <field> ::= a decimal number

<分野>:、:= 10進数

  Examples:

例:

    NET:1/3/5/7  names message-id 7 at host 5 on imp 3 in network 1.

NET: 1/3/5/7は悪童3の上でホスト5でネットワーク1でメッセージイド7を命名します。

    HOST:6  names host 6 on whatever imp this message originates on.

HOST: 6 このメッセージが起因するいかなる悪童の上でもホスト6に任命します。

Postel                                                          [page 3]

ポステル[3ページ]

RFC 730                                                        20 May 77
Extensible Field Addressing

RFC730の1977年5月20日の広げることができる分野アドレシング

One might ask:  What is all the fuss about, isn't this a non-problem?,
The answer is:  Almost.  There are very few places where any real
difficulties arise, but we have to change the way we think about host
addresses.  The places where there is a problem are typically little
used, except one.  The place where humans will see a difficulty is in
the TIP "open" command [9], and to a lesser extent the user Telnet and
user FTP "connect" commands.  Other places are in the MAIL netaddress
field, the FTP "sock" command [10], the Telnet reconnection option [11],
and in the NIC maintained list of official host names [12].

人は尋ねるかもしれません: すべてがことである、周囲で大騒ぎしてください、このa非問題がそうでない、答えは以下の通りです。 ほとんど。 ほんのわずかな場所がどんな本当の困難も起こりますが、私たちが私たちがホスト・アドレスについて考える方法を変えなければならないところにあります。 通常、1以外に、問題がある場所は少ししか使用されません。 人間が困難を見る場所はTIPの「開いている」コマンド[9]中です、そして、ある程度ユーザTelnetとユーザFTPはコマンドを「接続します」。 他の場所がメールnetaddress分野、FTP「ソックス」コマンド[10]、Telnet再接続オプション[11]と公式のホスト名[12]のリストであることが支持されたNICにあります。

Conclusion

結論

The suggestion is that we adopt field based extensible addressing to
provide for growth in three ways:

提案は私たちが3つの方法で成長に備えるために分野のベースの広げることができるアドレシングを採用するということです:

(1)  growth of the number of hosts and IMPs by allowing these fields to
grow in size independently of each other;

(1) これらの分野が互いの如何にかかわらずサイズに生えているのを許容するのによるホストとIMPsの数の成長。

(2)  growth in scope by the addition of fields on the left to provide
for multinetwork systems;

(2) 「マルチ-ネットワーク」システムに備える左の分野の追加による範囲での成長。

(3)  growth in fine structure by addition of fields on the right for the
implementation of hosts as mininetworks.

(3) mininetworksとしてのホストの実装への右の分野の追加による微細構造での成長。

Postel                                                          [page 4]

ポステル[4ページ]

RFC 730                                                        20 May 77
Extensible Field Addressing

RFC730の1977年5月20日の広げることができる分野アドレシング

References

参照

[1]     Sunshine, C. "Source Routing and Computer Networks," Computer
        Communication Review, Vol. 7, Number 1, ACM Special Interest
        Group on Communications (SIGCOMM), January 1977.  Also
        circulated as INWG General Note number 133.

[1] コンピュータコミュニケーションは、C. 日光と、「ソースルート設定とコンピュータネットワーク」と見直します、Vol.7、No.1、コミュニケーション(SIGCOMM)のACM特殊利益集団、1977年1月。 また、INWGの一般Note No.133として、循環されています。

[2]     BBN, "The Interconnection of a Host and an IMP," Report 1822,
        Bolt Beranek and Newman, Revised January 1976.

[2] 「ホストと悪童のインタコネクト」というBBNは、1822(ボルトBeranekとニューマン)が1976年1月に復習されたと報告します。

[3]     Wells, D., "Impact of New IMP Leaders on Higher-level
        Protocols," ARPA Network Message
        [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.

[3] ウェルズ、D.、「上位レベル・プロトコルの新しい悪童リーダーの影響」、アーパネットメッセージ[MIT-Multics]1.2.BBBJGbHZPXdDjl、MIT、1977年5月19日。

[4]     Beeler, et.al. "Gateway Design for a Computer Network
        Interconnection," PRTN 156, February 1976.

[4] Beeler、et.al。 「コンピュータネットワークインタコネクトのためのゲートウェイデザイン」、PRTN156、1976年2月。

[5]     Cerf, V., Y. Dalal, and C. Sunshine. "Specification of an
        Internet Transmission Control Program," INWG General 72, RFC
        675, Revised December 1974.

[5] サーフ、V.、Y.Dalal、およびC.日光。 INWGの一般72(RFC675)は、1974年12月に「インターネットトランスミッション制御プログラムの仕様」と改訂しました。

[6]     Cerf, V. "Specification of TCP version 2," March 1977.

[6] サーフ、V. 「TCPバージョン2の仕様」、1977年3月。

[7]     Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58,
        Information Sciences Institute, University of Southern
        California, March 1977.

[7] ブリット、B.et.al。 「堅苦しいシステム:」 「概要」、ISI/RR-77-58、科学が設ける情報、南カリフォルニア大学、1977年3月。

[8]     Crocker, D., "Network Standard Data Specification Syntax," RFC
        645, Network Information Center Catalog Number 30899, 27 June
        1974.

[8] クロッカー、D.、「ネットワークの標準のデータ指定構文」、RFC645はインフォメーション・センターカタログNo.30899、1974年6月27日をネットワークでつなぎます。

[9]     Malman, J., "User's Guide to the Terminal IMP," Report 2138,
        Bolt Beranek and Newman, Network Information Center Catalog
        Number 10916, Revised March 1976.

[9] Malman、J.、「端末の悪童への使用手引書」、レポート2138、ボルトBeranek、およびニューマンはインフォメーション・センターカタログNo.10916(改訂された1976年3月)をネットワークでつなぎます。

[10]    Neigus, N., "File Transfer Protocol," RFC 542, Network
        Information Center Catalog Number 17759, 12 August 1973.
        Contained in "ARPANET Protocol Handbook," Network Information
        Center Catalog Number 7104, Revised 1 April 1976.

[10] Neigus(N.、「ファイル転送プロトコル」、RFC542)はインフォメーション・センターカタログNo.17759、1973年8月12日をネットワークでつなぎます。 「アルパネットプロトコルハンドブック」に含まれて、インフォメーション・センターカタログNo.7104、改訂された1976年4月1日をネットワークでつないでください。

[11]    Thomas, R., "Telnet Reconnection Option," Network Information
        Center Catalog Number 15391, August 1973. Contained in "ARPANET
        Protocol Handbook," Network Information Center Catalog Number
        7104, Revised 1 April 1976.

[11] トーマス、R.、「telnet再接続オプション」がインフォメーション・センターカタログNo.15391、1973年8月をネットワークでつなぎます。 「アルパネットプロトコルハンドブック」に含まれて、インフォメーション・センターカタログNo.7104、改訂された1976年4月1日をネットワークでつないでください。

[12]    [Offfice-1]<NETINFO>HOSTS.TXT

[12][Offfice-1]<NETINFO>HOSTS.TXT

Postel                                                          [page 5]

ポステル[5ページ]