RFC1498 日本語訳

Network Working Group                                        J. Saltzer
Request for Comments: 1498       M.I.T. Laboratory for Computer Science
                                                            August 1993

Saltzerがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1498 マサチューセッツ工科大学コンピュータ科学研究所1993年8月

           On the Naming and Binding of Network Destinations

ネットワークの目的地の命名と結合に関して

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This brief paper offers a perspective on the subject of names of
   destinations in data communication networks. It suggests two ideas:
   First, it is helpful to distinguish among four different kinds of
   objects that may be named as the destination of a packet in a
   network.  Second, the operating system concept of binding is a useful
   way to describe the relations among the four kinds of objects. To
   illustrate the usefulness of this approach, the paper interprets some
   more subtle and confusing properties of two real-world network
   systems for naming destinations.

この簡潔な紙はデータ通信ネットワークにおける、目的地の名前の問題に関して見解を提供します。 それは2つの考えを示します: まず最初に、パケットの目的地としてネットワークで命名されるかもしれない4つの異種のオブジェクトの中で区別するのは役立っています。 2番目に、結合のオペレーティングシステム概念は4種類のオブジェクトの中で関係について説明する役に立つ方法です。 このアプローチの有用性を例証するために、紙は目的地を命名する2個の本当の世界ネットワーク・システムのそれ以上の微妙で紛らわしい特性を解釈します。

Note

注意

   This document was originally published in: "Local Computer Networks",
   edited by P. Ravasio et al., North-Holland Publishing Company,
   Amsterdam, 1982, pp. 311-317.  Copyright IFIP, 1982.  Permission is
   granted by IFIP for reproduction for non-commercial purposes.
   Permission to copy without fee this document is granted provided that
   the copies are not made or distributed for commercial advantage, the
   IFIP copyright notice and the title of the publication and its date
   appear, and notice is given that copying is by permission of IFIP. To
   copy otherwise, or to republish, requires a specific permission.

このドキュメントは元々、以下で発表されました。 P.Ravasio他、北部オランダ出版会社、アムステルダム、1982、ページによって編集された「地方のコンピュータNetworks」 311-317. Copyright IFIP、1982。 許可は非営利的な目的のための再現のためにIFIPによって与えられます。 商業利点のためにコピーを作りもしませんし、分配もしないで、公表とその日付のIFIP版権情報とタイトルが現れて、そのコピーを通知に与えればこのドキュメントを与える料金なしでコピーする許可がIFIPの許可であります。 そうでなければ、コピーするか、または再刊するのに必要である、特定アクセス許可を必要とします。

   This research was supported in part by the Defense Advanced Research
   Projects Agency of the United States Government and monitored by the
   Office of Naval Research under contract number N00014-75-C-0661.

この研究は、合衆国政府国防高等研究計画庁によって一部サポートされて、契約番号N00014 75C0661の下で海軍研究事務所によってモニターされました。

What is the Problem?

Problemは何ですか?

   Despite a very helpful effort of John Shoch [1] to impose some
   organization on the discussion of names, addresses, and routes to
   destinations in computer networks, these discussions continue to be
   more confusing than one would expect. This confusion stems sometimes
   from making too tight an association between various types of network

コンピュータネットワークの目的地への名前、アドレス、およびルートの議論に何らかの組織を課すジョンShoch[1]の非常に役立っている取り組みにもかかわらず、これらの議論は人が予想するだろうよりずっと紛らわしいです。 この混乱は時々作成からネットワークの様々なタイプの間のきつ過ぎる協会を食い止めます。

Saltzer                                                         [Page 1]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[1ページ]RFC1498

   objects and the most common form for their names.  It also stems from
   trying to discuss the issues with too few well-defined concepts at
   hand.  This paper tries a different approach to develop insight, by
   applying a perspective that has proven helpful in the corresponding
   area of computer operating systems.

オブジェクトとそれらの名前のための最も一般的な用紙。 また、それはあまりにわずかな明確な概念で問題に取り組むトライに手元に由来します。 この紙は洞察を見いだすために異なるアプローチを試みます、コンピュータオペレーティングシステムの対応する領域で役立っていると判明した見解を適用することによって。

   Operating systems have a similar potential for confusion concerning
   names and addresses, since there are file names, unique identifiers,
   virtual and real memory addresses, page numbers, block numbers, I/O
   channel addresses, disk track addresses, a seemingly endless list.
   But most of that potential has long been rendered harmless by
   recognizing that the concept of binding provides a systematic way to
   think about naming [2]. (Shoch pointed out this opportunity to
   exploit the operating system concept; in this paper we make it the
   central theme.) In operating systems, it was apparent very early that
   there were too many different kinds of identifiers and therefore one
   does not get much insight by trying to make a distinction just
   between names and addresses.  It is more profitable instead to look
   upon all identifiers as examples of a single phenomenon, and ask
   instead "where is the context in which a binding for this name (or
   address, or indentifier, or whatever) will be found?", and "to what
   object, identified by what kind of name, is it therein bound?"  This
   same approach is equally workable in data communications networks.

オペレーティングシステムには、名前とアドレスに関して混乱の同様の可能性があります、ファイル名、ユニークな識別子、仮想の、そして、本当のメモリアドレス、ページ番号、街区番号、入出力チャンネル・アドレス、ディスクトラック・アドレス、外観上無限のリストがあるので。 しかし、結合の概念が[2]を命名すると考える系統立った方法を提供すると認めることによって、その可能性の大部分は長い間、無害にされています。 (Shochはオペレーティングシステム概念を利用するこの機会を指摘しました; この紙では、私たちはそれを主要なテーマにします。) オペレーティングシステムで、あまりに多くの異種に関する識別子があったのが、非常に早く明らかであり、したがって、1つは、名前とアドレスのすぐ間で区別をしようとすることによって、多くの洞察を得ません。 単一の現象に関する例としてすべての識別子を見て、代わりに「どこに、この名前(または、アドレス、indentifier、または何でも)のための結合が見つけられる文脈がありますか?」、および「それはそこにどういう名前によって特定されたすべてのオブジェクトに縛られますか?」を尋ねるのは代わりにより有益です。 この同じアプローチはデータ通信網で等しく実行可能です。

   To start with, let us review Shoch's suggested terminology in its
   broadest form:

まず第一に、最も広いフォームでShochの提案された用語を見直しましょう:

        -  a name identifies what you want,
        -  an address identifies where it is, and
        -  an route identifies a way to get there.

- そして、名前はあなたが欲しいものを特定します--アドレスが、それがどこにあるかを特定する、--ルートはそこに到着する方法を特定します。

   There will be no need to tamper with these definitions, but it will
   be seen that they will leave a lot of room for interpretation.
   Shoch's suggestion implies that there are three abstract concepts
   that together provide an intellectual cover for discussion. In this
   paper, we propose that a more mechanical view may lead to an easier-
   to-think-with set of concepts. This more mechanical view starts by
   listing the kinds of things one finds in a communication network.

これらの定義をいじる必要は全くないでしょうが、それらには解釈の多くの余地があるのがわかるでしょう。 Shochの提案は、そんなに一緒にいる抽象的な概念が議論のための知的なカバーを提供する3があるのを含意します。 この紙では、私たちは、より機械的な視点が思っているより簡単なセットの概念につながるかもしれないよう提案します。 このより機械的な視点は、1つが通信ネットワークで見つけるものの種類を記載することによって、始まります。

Types of Network Destinations, and Bindings Among Them

ネットワークの目的地のタイプ、およびそれらの中の結合

   In a data communication network, when thinking about how to describe
   the destination of a packet, there are several types of things for
   which there are more than one instance, so one attaches names to them
   to distinguish one instance from another. Of these several types,
   four turn up quite often:

データ通信ネットワークでは、どうパケットの目的地について説明するかについて考えるとき、1つ以上のインスタンスがあるいくつかのタイプのものがあるので、1つは別のものと1つのインスタンスを区別するために名前をそれらに付けます。 これらのいくつかのタイプでは、4はかなりしばしば現れます:

Saltzer                                                         [Page 2]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[2ページ]RFC1498

    1. Service and Users. These are the functions that one uses, and
       the clients that use them. Examples of services are one that
       tells the time of day, one that performs accounting, or one
       that forwards packets. An example of a client is a particular
       desktop computer.

1. サービスとユーザ。 これらは、1つが使用する機能と、彼らを使用するクライアントです。 サービスの例は、時刻を言うもの、会計を実行するもの、またはパケットを進めるものです。 クライアントの例は特定のデスクトップコンピュータです。

    2. Nodes. These are computers that can run services or user
       programs. Some nodes are clients of the network, while others
       help implement the network by running forwarding services.
       (We will not need to distinguish between these two kinds of
       nodes.)

2. ノード。 これらはサービスかユーザ・プログラムを動かすことができるコンピュータです。いくつかのノードがネットワークのクライアントです、他のものは、転送サービスを実行することによってネットワークを実装するのを助けますが。 (私たちはこれらの2種類のノードを見分ける必要はないでしょう。)

    3. Network attachment points. These are the ports of a network, the
       places where a node is attached. In many discussions about data
       communication networks, the term "address" is an identifier of a
       network attachment point.

3. 付着点をネットワークでつないでください。 これらはネットワークのポート、ノードが添付している場所です。 データ通信ネットワークについての多くの議論では、「アドレス」という用語はネットワーク付着点に関する識別子です。

    4. Paths. These run between network attachment points, traversing
       forwarding nodes and communication links.

4. 経路。 推進ノードと通信リンクを横断して、これらはネットワーク付着点の間で稼働しています。

   We might note that our first step, the listing and characterization
   of the objects of discussion, is borrowed from the world of abstract
   data types. Our second step is to make two observations about the
   naming of network objects, the first about form and the second about
   bindings.

私たちは、私たちの第一歩(議論の目的のリストと特殊化)が抽象データ型の世界から借りられることに注意するかもしれません。 私たちの第2ステップはネットワークオブジェクトの命名、フォームに関する1日、および秒頃の間、結合に関して2つの観測をすることです。

   First, one is free to choose any form of name that seems helpful --
   binary identifiers, printable character strings, or whatever, and
   they may be chosen from either a flat or hierarchical name space.
   There may be more than one form of name for a single type of object.
   A node might, for example, have both a hierarchical character string
   name and a unique binary identifier.  There are two semantic traps
   that one can fall into related to name form.  First, the word "name"
   is, in the network world, usually associated with a printable
   character string, while the word "address" is usually associated with
   machine-interpretable binary strings. In the world of systems and
   languages, the term "print name" is commonly used for the first and
   "machine name" or "address" for the second, while "name" broadly
   encompasses both forms. (In this paper we are using the broad meaning
   of "name".)  The second semantic trap is to associate some
   conventional form of name for a particular type of object as a
   property of that type. For example, services might be named by
   character strings, nodes by unique ID's, and network attachment
   points named by hierarchical addresses.  When one participant in a
   discussion assumes a particular name form is invariably associated
   with a particular type of object and another doesn't, the resulting
   conversation can be very puzzling to all participants.

まず最初に、人は自由に役立っているように見えるどんなフォームの名前も選ぶことができます--2進の識別子か、印刷可能な文字列か、何でもと、それらがアパートか階層的な名前スペースのどちらかから選ばれるかもしれません。 単独のタイプのオブジェクトのための1つ以上のフォームの名前があるかもしれません。 ノードには、例えば、階層的な文字列名とユニークな2進の識別子の両方があるかもしれません。 1つがなることができる名前フォームに関連する2つの意味罠があります。 ネットワーク世界では、まず最初に、通常、「名前」という言葉が印刷可能な文字列に関連づけられます、「アドレス」という言葉が通常マシン解明できる2進のストリングに関連していますが。 システムと言語(「名前」が両方のフォームを広く取り囲む間の「印刷名」が2番目のための1番目と「マシン名」か「アドレス」に一般的に使用される用語)(この紙では、私たちは「名前」の広い意味を使用しています。)の世界で 2番目の意味罠は特定のタイプのオブジェクトのためにそのタイプの特性として何らかの伝統的な形式の名前を関連づけることです。 例えば、サービスは文字列、固有のIDのものによるノード、および階層的なアドレスによって指定されたネットワーク付着点によって命名されるかもしれません。 議論の1人の関係者が、特定の名前フォームが不変的に特定のタイプのオブジェクトに関連づけられると仮定して、別のものがそのように仮定しないとき、すべての関係者にとって、結果として起こる会話は非常に不可解である場合があります。

Saltzer                                                         [Page 3]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[3ページ]RFC1498

   The second observation about the four types of network objects listed
   above is that most of the naming requirements in a network can simply
   and concisely be described in terms of bindings and changes of
   bindings among the four types of objects. To wit:

上に記載された4つのタイプのネットワークオブジェクトの周りの2番目の観測は4つのタイプのオブジェクトの中で結合の結合と変化に関してネットワークにおける命名要件の大部分について簡単に、そして簡潔に説明できるということです。 すなわち:

    1. A given service may run at one or more nodes, and may need to move
       from one node to another without losing its identity as a service.

1. 与えられたサービスは、1つ以上のノードで稼働していて、1つのノードから別のノードまでサービスとして本性を失くさないで移行する必要があるかもしれません。

    2. A given node may be connected to one or more network attachment
       points, and may need to move from one attachment point to another
       without losing its identity as a node.

2. 与えられたノードは、1つ以上のネットワーク付着点に接続されて、1つの付着点から別の付着点までノードとして本性を失くさないで移行する必要があるかもしれません。

    3. A given pair of attachment points may be connected by one or more
       paths, and those paths may need to change with time without
       affecting the identity of the attachment points.

3. 付着点の与えられた組は1つ以上の経路によって接されるかもしれません、そして、それらの経路は付着点のアイデンティティに影響しないで時間を交換する必要があるかもしれません。

   (This summary of network naming requirements is intentionally brief.
   An excellent in-depth review of these requirements can be found in a
   recent paper by Sunshine [3].)

(ネットワーク命名要件のこの概要は故意に簡潔です。 サンシャイン[3]は最近の紙でこれらの要件の素晴らしい徹底的なレビューを見つけることができます。)

   Each of these three requirements includes the idea of preserving
   identity, whether of service, node or attachment point. To preserve
   an identity, one must arrange that the name used for identification
   not change during moves of the kind required. If the associations
   among services, nodes, attachment points and routes are maintained as
   lists of bindings this goal can easily be met. Whether or not all the
   flexibility implied by these possibilities should be provided in a
   particular network design is a matter of engineering judgment. A
   judgment that a particular binding can be made at network design time
   and will never need to be changed (e.g., a particular service might
   always run at a particular node) should not be allowed to confuse the
   question of what names and bindings are in principle present. In
   principle, to send a data packet to a service one must discover three
   bindings:

それぞれのこれらの3つの要件がサービス、ノードまたは付着点にかかわらずアイデンティティを保持するという考えを含んでいます。 アイデンティティを保持するために、名前が変化ではなく、識別に種類の移動の間に使用した必須がアレンジするのが必要です。 サービス、ノード、付着点、およびルートの中の協会が結合のリストとして維持されるなら、容易にこの目標を達成されることができます。 これらの可能性によって含意されたすべての柔軟性を特定のネットワークデザインに提供するべきであるかどうかが、工学的判断の問題です。 特定の結合がネットワークデザイン時間に作ることができて、変える(例えば特定のサービスは特定のノードでいつも稼働するかもしれない)ために決して必要としない判断はどんな名前と結合が原則として現在かに関する質問を混乱させることができないべきです。 原則として、サービス1にデータ・パケットを送るのは3つの結合を発見しなければなりません:

    1. find a node on which the required service operates,

1. 必要なサービスが作動するノードを見つけてください。

    2. find a network attachment point to which that node is connected,

2. そのノードが関連しているネットワーク付着点を見つけてください。

    3. find a path from this attachment point to that attachment point.

3. この付着点からその付着点に経路を見つけてください。

   There are, in turn, three conceptually distinct binding services that
   the network needs to provide:

順番に、ネットワークが提供する必要がある概念的に異なった拘束力がある3つのサービスがあります:

    1. Service name resolution, to identify the nodes that run the
       service.

1. 名前解決を修理して、サービスを実行するノードを特定してください。

    2. Node name location, to identify attachment points that reach the

2. ノードは、達する付着点を特定するために位置を命名します。

Saltzer                                                         [Page 4]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[4ページ]RFC1498

       nodes found in 1.

1で見つけられたノード。

    3. Route service, to identify the paths that lead from the
       requestor's attachment point to the ones found in 2.

3. サービスを発送して、要請者の付着点から2で見つけられたものまで導く経路を特定してください。

   At each level of binding, there can be several alternatives, so a
   choice of which node, which attachment point, and which path must be
   made. These choices are distinct, but can interact. For example, one
   might chose the node only after first looking over the various paths
   leading to the possible choices. In this case, the network tables may
   only produce a partial binding, which means that an enquiry produces
   a list of answers rather than a single one. The final binding choice
   may be delayed until the last moment and recorded outside the three
   binding services provided within the network.

それぞれのレベルの結合では、いくつかの選択肢があることができるので、どのノード、どの付着点、およびどの経路の選択をしなければならないか。 これらの選択は、異なりますが、相互作用できます。 例えば、ある力が、最初に後にだけ可能な選択につながる様々な経路に目を通しながら、ノードを選びました。 この場合、ネットワークテーブルは部分的な結合を起こすだけであるかもしれません。(それは、調査がただ一つのものよりむしろ答えのリストを作り出すことを意味します)。 最終的な拘束力がある選択は、土壇場まで遅れて、ネットワークの中で提供された拘束力がある3つのサービスの外で記録されるかもしれません。

   There is a very important subtlety about bindings that often leads
   designers astray. Suppose we have recorded in a network table the
   fact that the "Lockheed DIALOG Service" is running on node "5". There
   are actually three different bindings involved here but only one of
   these three is recorded in this table and changeable by simply
   adjusting the table.

しばしばデザイナーを堕落する結合に関する非常に重要な微妙さがあります。 私たちが「ロッキード対話サービス」が「5インチ」というノードで動いているという事実をネットワークテーブルに記録したと仮定してください。 実際にこれらの3のここでかかわった異なった結合にもかかわらず、1つだけが単にテーブルを調整するのにおいてこのテーブルに記録されていて変わりやすい3があります。

    1. The name "Lockheed DIALOG Service" is properly associate with a
       specific service, management, and collection of stored files. One
       does not usually reassign such a name to a different service. The
       association of the name with the service is quite permanent, and
       because of that permanence is not usually expressed in a single,
       easily changed table.

1. 名前「ロッキード対話サービス」は保存されたファイルの特定のサービス、管理、および収集で適切に副です。 通常、人は異なったサービスにそのような名前を再選任しません。 サービスの名前の協会は、かなり永久的であり、通常、その恒久的のために単一の、そして、容易に変えられたテーブルで言い表されません。

    2. Similarly, the name "5" is assigned to a particular node on a
       fairly long-term basis, without the expectation that it will
       change. So that assignment is also not typically expressed in a
       single, easily changed table.

2. 同様である、「5インチはかなり長期のベースで特定のノードに割り当てられます、それが変える期待なしで」名義の それで、また、その課題は単一の、そして、容易に変えられたテーブルに通常表されません。

    3. The fact that "DIALOG" is now operating on node "5"is the one
       binding that our table does express, because we anticipate that
       this association might reasonably change. The function of our
       table is to allow us to express changes such as "DIALOG" is now
       operating at node "6" or the "Pipe-fitting Service" is now
       operating at node "5".

3. 「対話」が現在ノードを作動させているという事実、「5"is、私たちが、この協会が合理的に変化するかもしれないと予期するので私たちのテーブルが言い表す1つの結合 私たちのテーブルの機能がノードで作動しながら私たちが現在「対話」のような変化を言い表すのを許容することである、「6インチか「パイプがぴったりのサービス」が「5インチ」というノードで作動する現在です。

   The design mistake is to believe that this table allows one to give
   the Lockheed DIALOG service a new name, merely by changing this table
   entry. That is not the function of this table of bindings, and such a
   name change is actually quite difficult to accomplish, since the
   association in question is not usually expressed as a binding in a
   single table. One would have to change not only this table, but also
   user programs, documentation, scribbled notes and advertising copy to

デザイン誤りは人がこのテーブルでロッキードDIALOGサービスに新しい名前を与えることができると信じることです、単にこのテーブル項目を変えることによって。 それは結合のこのテーブルの機能ではありません、そして、そのような改名は達成するのが実際にかなり難しいです、問題の協会が結合として単一のテーブルで通常言い表されないので。 1つはこのテーブルだけではなく、プログラム(ドキュメンテーション)が注意と広告コピーを走り書きしたユーザも変えなければならないでしょう。

Saltzer                                                         [Page 5]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[5ページ]RFC1498

   accomplish such a name change.

そのような改名を達成してください。

Some Real-World Examples

いくつかの本当の世界の例

   Although the ideas outlined so far seem fairly straightforward, it is
   surprisingly easy to find real-world examples that pose a challenge
   in interpretation. In the Xerox/DEC/Intel Ethernet [5, 6], for
   example, the concept of a network attachment point is elusive,
   because it collapses into the node name. A node can physical attach
   to an Ethernet anywhere along it; the node brings with it a 48-bit
   unique identifier that its interfaces watches for in packets passing
   by. This identifier should probably be thought of as the name of a
   network attachment point, even though the physical point of
   attachment can be anywhere. At the same time, one can adopt a policy
   that the node will supply from its own memory the 48-bit identifier
   that is to be used by the Ethernet interface, so a second, equally
   reasonable, view (likely to be taken elsewhere in the network in
   interpreting the meaning of these identifiers) is that this 48-bit
   identifier is the name of the node itself.  From a binding
   perspective this way of using the Ethernet binds the node name and
   the network attachment point name to be the same 48-bit unique
   identifier.

今までのところ概説されている考えはかなり簡単に見えますが、解釈における挑戦を引き起こす本当の世界の例を見つけるのは驚くほど簡単です。 ゼロックス/12月/インテルイーサネット[5、6]では、例えば、ネットワーク付着点の概念はとらえどころがありません、ノード名まで崩れるので。 ノード缶の身体検査はそれに沿ってどこでもイーサネットに付きます。 ノードはそれと共にインタフェースが通り過ぎるパケットで待ち兼ねる48ビットのユニークな識別子をもたらします。 この識別子はたぶんネットワーク付着点の名前として考えられるべきです、物理的な接着点がどこでもあることができますが。 同時に、1つはノードが48ビットの識別子をそれ自身のメモリから提供する方針を採ることができます、イーサネットインタフェースのそばで使用されていて、等しく妥当な2分の1が見る(ネットワークにおけるほかの場所でこれらの識別子の意味を解釈する際に取られそうな)そうがそれであるということであるために、すなわち、この48ビットの識別子はノード自体の名前です。 拘束力がある見解から、イーサネットを使用するこの方法は、同じ48ビットのユニークな識別子になるようにノード名とネットワーク付着点名を縛ります。

   This permanent binding of node name to attachment point name has
   several network management advantages:

付着点名へのノード名のこの永久的な結合には、いくつかのネットワークマネージメント利点があります:

     - a node can be moved from one physical location to another
       without changing any network records.

- どんなネットワーク記録も変えないで、ノードを1つの物理的な位置から別のものに移されることができます。

     - one level of binding tables is omitted. This advantage is
       particularly noticeable in implementing internetwork routing.

- 1つのレベルの拘束力があるテーブルは省略されます。 この利点はネットワーク間ルーティングを実装するのにおいて特にめぼしいです。

     - a node that is attached to two Ethernets can present the same
       attachment point name to both networks, which simplifies
       communication among internet routers and alternate path
       finding.

- 2Ethernetsに添付されるノードは両方のネットワークへのインターネットルータと代替パス調査結果の中でコミュニケーションを簡素化するのと同じ付着点名を提示できます。

   But permanent binding also produces a curiosity if is happens that
   one wants one node to connect to two attachment points on the same
   Ethernet. The curiosity arises because the only way to make the
   second attachment point independently addressable by others is to
   allow the node to use two different 48-bit identifiers, which means
   that some other network records (the ones that interpret the ID to be
   a node name) will likely be fooled into believing that there are not
   one, but two nodes. To avoid this confusion, the same 48-bit
   identifier could be used in both attachment points, but then there
   will be no way intentionally to direct a message to one rather than
   the other. One way or another, the permanent binding of attachment

しかし、また、永久的な結合が好奇心を生産する、起こる、その人は、1つのノードに同じイーサネットの2つの付着点に接続して欲しいです。 好奇心は、他のもので2番目の付着点を独自にアドレス可能にする唯一の方法がノードが2つの異なった48ビットの識別子を使用するのを許容することであるので起こります(ある他のネットワーク記録(ノード名になるようにIDを解釈するもの)がおそらくそこでそれを信じているようにだまされているのが、1ではなく、2つのノードであるということであることを意味します)。 この混乱を避けるのに、両方の付着点で同じ48ビットの識別子を使用できましたが、もう片方よりむしろ1つにメッセージを向けるためには故意にそこでは、方法でないでしょう。 いずれにしても、付属の永久的な結合

Saltzer                                                         [Page 6]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[6ページ]RFC1498

   point name to node name has made some function harder to accomplish,
   though the overall effect of the advantages probably outweighs the
   lost function in this case.

ノード名へのポイント名は、何らかの機能を達成するのをより困難にしました、利点の総合的な効果がこの場合たぶん無くなっている機能より重いのですが。

   For another example, the ARPANET NCP protocol provides character
   string names that appear, from their mnemonics, to be node names or
   service names, but in fact they are the names of network attachment
   points [6]. Thus the character string name RADC-Multics is the name
   of the network attachment point at ARPANET IMP 18, port 0, so
   reattaching the node (a Honeywell 68/80 computer) to another network
   attachment point requires either that the users learn a new name for
   the service or else a change of tables in all other nodes.  Changing
   tables superficially appears to be what rebinding is all about, but
   the need to change more than one table is the tip-off that something
   deeper is going on. What is actually happening is the change of the
   permanent name of the network attachment point. We can see this more
   clearly by noting that a parallel attachment of that Honeywell 68/80
   to a second ARPANET port would be achievable only by assigning a
   second character string identity; this requirement emphasizes that
   the name is really of the attachment point, not the node.
   Unfortunately, because of their mnemonic value, the ARPANET NCP name
   mnemonics are often thought of as service names. Thus one expects
   that that the Rome Air Development Center Multics service is operated
   on the node reached by the name RADC-Multics.  This particular
   assumption doesn't produce any surprises. But any one of the four
   Digital PDP-10 computers at Bolt, Beranek and Newman can accept mail
   for any of the others, as can the groups of PDP-10's at the USC
   Information Sciences Institute, and at the Massachusetts Institute of
   Technology. If the node to which ones tries to send mail is down, the
   customer must realize that the same service is available by asking
   for a different node, using what appears to be a different service
   name. The need for a customer to realize that he must give a
   different name to get the same service comes about because in the
   ARPANET the name is not of a service that is bound to a node that is
   bound to an attachment point, but rather it is directly the name of
   an attachment point.

別の例のために、アルパネットNCPプロトコルはノード名かサービス名になるようにそれらのニーモニックから現れる文字列名を提供しますが、事実上、それらはネットワーク付着点[6]の名前です。 したがって、RADC-Multicsという文字列名はARPANET IMP18、ポート0のネットワーク付着点の名前、したがって、ノード(ハネウェル68/80コンピュータ)を別のネットワーク付着点に再付着させるのがユーザが他のすべてのノードにおける、サービスかテーブルの変化のために新しい名前を学ぶのを必要とするということです。 表面的にテーブルを変えるのは縛り直すのが何に関するすべてかということであるように見えますが、1個以上のテーブルを変える必要性は何かより深いものが先へ進んでいるという情報です。 実際に起こっていることはネットワーク付着点の永久的な名前の変化です。 私たちは明確に2番目のアルパネットポートへのそのハネウェル68/80の平行アタッチメントが2番目の文字列のアイデンティティを割り当てるだけによって達成可能であることに注意するのによるこの以上を見ることができます。 この要件は、名前がノードではなく、本当な付着点のものであると強調します。 残念ながら、それらの簡略記憶値のために、アルパネットNCP名前ニーモニックはサービス名としてしばしば考えられます。 したがって、人は、ローム航空開発センターMulticsが修理するそれがRADC-Multicsという名前で達したノードの上で操作されると予想します。 この特定の仮定は少しの驚きも生産しません。 しかし、Bolt、Beranek、およびニューマンの4台のDigital PDP-10コンピュータのどれかは他のもののどれかのメールを受け入れることができます、USC情報Sciences Instituteにおけるマサチューセッツ工科大学のPDP-10のグループであることができることのように。 ものがメールを送ろうとするノードが下がっているなら、顧客は、同じサービスが異なったノードを求めることによって利用可能であるとわからなければなりません、異なったサービス名であるように見えることを使用して。 顧客がアルパネットでは、名前が生じないのでサービスがサービスを生じさせる付着点に縛られるノードにはバウンドがありますが、むしろそれが直接ある同じくらいに付着点の名前を得るために異なった名前を与えなければならないとわかる必要性。

   Finally, confusion can arise because the three conceptually distinct
   binding services (service name resolution, node name location, and
   route dispensing) may not be mechanically distinct. There is usually
   suggested only one identifiable service, a "name server". The name
   server starts with a service name and returns a list of network
   attachment points that can provide that service. It thereby performs
   both the first and second conceptual binding services, though it may
   leave to the customer the final choice of which attachment point to
   use. Path choice may be accomplished by a distributed routing
   algorithm that provides the final binding service without anyone
   noticing it.

最終的に、概念的に異なった拘束力がある3つのサービス(サービス名前解決、ノード名位置、およびルート特免)が機械的に異ならないかもしれないので、混乱は起こることができます。 通常、1つの身元保証可能なサービスだけ、「ネームサーバ」は示されます。 ネームサーバは、サービス名から始まって、そのサービスを提供できるネットワーク付着点のリストを返します。 その結果、それは1番目と2番目の概念的な拘束力があるサービスの両方を実行します、最終的な選択をどの付着点を使用するかを顧客に任せるかもしれませんが。 経路選択はそれに気付きながらだれなしでも最終的な拘束力があるサービスを提供する分配されたルーティング・アルゴリズムで実行されるかもしれません。

Saltzer                                                         [Page 7]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[7ページ]RFC1498

Correspondence with Names, Addresses, and Routes

名前、アドレス、およびルートとの通信

   With this model of binding among services, nodes, network attachment
   points, and paths in mind, one possible interpretation of Shoch's
   names, addresses and routes is as follows:

念頭でサービス、ノード、ネットワーク付着点、および経路の中で付くこのモデルと共に、Shochの名前、アドレス、およびルートの1つの可能な解釈は以下の通りです:

   1.  Any of the four kinds of objects (service, node, network
       attachment point, and path) may have a name, though Shoch would
       restrict that term to human-readable character strings.

1. 4種類のオブジェクト(サービス、ノード、ネットワーク付着点、および経路)のどれかには、名前があるかもしれません、Shochはその用語のときに人間読み込み可能な文字列に制限するでしょうが。

   2.  The address of an object is a name (in the broad sense, not
       Shoch's restricted sense) of the object it is bound to. Thus, an
       address of a service is the name of some node that runs it. An
       address of a node is the name of some network attachment point to
       which it connects. An address of a network attachment point (a
       concept not usually discussed) can be taken to be the name of a
       path that leads to it. This interpretation captures Shoch's
       meaning "An address indicates where it is," but does not very
       well match Shoch's other notion that an address is a
       machine-processable, rather than a human-processable form of
       identification. This is probably the primary point where our
       perspectives differ on which definitions provide the most clarity.

2. オブジェクトのアドレスはそれが制限されているオブジェクトの名前(Shochの制限された感覚ではなく、広い意味における)です。 したがって、サービスのアドレスはそれを実行する何らかのノードの名前です。 ノードのアドレスはそれが接続する何らかのネットワーク付着点の名前です。 それに通じる経路の名前になるようにネットワーク付着点(通常、議論しなかった概念)のアドレスを取ることができます。 この解釈は、Shochの意味が「アドレスは、それがどこにあるかを示します」であるとキャプチャしますが、それほど、アドレスが識別の人間-「プロセス-可能」フォームよりむしろマシン-「プロセス-可能」であるというShochの他の概念によく、合っていません。 これはたぶんどの定義が最も多くの明快を提供するかに関して私たちの見解が異なる原生品集産地です。

   3.  A route is a more sophisticated concept. A route to either a
       network attachment point or a node is just a path, as we have
       been using the term. Because a single node can run several
       services at once, a route to a service consists of a path to the
       network attachment point of a node that runs the service, plus
       some identification of which activity within that node runs the
       service (e.g., a "socket identifier" in the PUP internet [4] or
       the ARPA Internet [7] protocols). But note that a route may
       actually consist of a series of names, typically a list of
       forwarding name nodes or attachment points and the names used by
       the forwarding nodes for the paths between them.

3. ルートは、より洗練された概念です。 ネットワーク付着点かノードのどちらかへのルートはただ経路です、私たちが用語を使用しているとき。 ただ一つのノードがすぐにいくつかのサービスを実行できるので、サービスへのルートはサービスを実行するノードのネットワーク付着点、およびそのノードの中の活動がサービスを実行する何らかの識別(例えば、PUPインターネット[4]かARPAインターネット[7]プロトコルの「ソケット識別子」)のように経路から成ります。 しかし、ルートが実際に通常一連の名前、名前ノードか付着点を転送するリスト、およびそれらの間の経路に推進ノードによって使用される名前から成るかもしれないことに注意してください。

   Whether or not one likes this particular interpretation of Shoch's
   terms, it seems clear that there are more than three concepts
   involved, so more than three labels are needed to discuss them.

人がShochの用語のこの特定の解釈が好きであるか否かに関係なく、3個以上のラベルがそれらについて議論するのに必要であることで、かかわった3つ以上の概念があるのは明確に見えます。

Summary

概要

   This paper has argued that some insight into the naming of
   destinations in a network can be obtained by recognizing four kinds
   of named objects at or leading to every destination (services, nodes,
   attachment points, and routes) and then identifying three successive,
   changeable, bindings (service to node, node to attachment point, and
   attachment point to route). This perspective, modeled on analogous
   successive bindings of storage management systems (file--storage

この紙は、あらゆる目的地にオブジェクトを命名するか、または導く4種類を認識して(サービス、ノード、付着点、およびルート)、次に、連続して、変わりやすい状態で3を特定することによってネットワークにおける、目的地の命名に関する何らかの洞察を得ることができると主張しました、結合(ノード、発送する付着点、および付着点へのノードに対するサービス)。 貯蔵管理システムの類似の連続した結合が似せられたこの見解、(ファイル--ストレージ

Saltzer                                                         [Page 8]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[8ページ]RFC1498

   region--physical location) and virtual memories (object--segment--
   page--memory block) provides a systematic explanation for some design
   problems that are encountered in network naming systems.

領域--物理的な位置) そして、(オブジェクト--セグメント--ページ--メモリブロック)がネットワーク命名システムで遭遇するいくつかの設計上の問題のための順序立った説明を提供する仮想記憶。

Acknowledgements

承認

   Discussions with David D. Clark, J. Noel Chiappa, David P. Reed, and
   Danny Cohen helped clarify the reasoning used here. John F. Shoch
   provided both inspiration and detailed comments, but should not be
   held responsible for the result.

デヴィッド・D.クラーク、J.クリスマスChiappa、デヴィッド・P.リード、およびダニー・コーエンとの議論は、ここで使用された推理をはっきりさせるのを助けました。 ジョンF.Shochはインスピレーションと詳細なコメントの両方を提供しますが、結果に責任を負わせるべきではありません。

References

参照

   1.  Shoch, John F., "Inter-Network Naming, Addressing, and Routing,"
       IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K.
       (ed.), Tutorial: Distributed Processor Communication
       Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287.

1. Shochと、ジョンF.と、「インターネットワーク命名、アドレシング、およびルート設定」、IEEE Proc。 COMPCON Fall1978、ページ 72-79. サーバー、K.編、チュートリアルでも: 分配されたプロセッサ通信アーキテクチャ、IEEE Publ。 #EHO152-9、1979、ページ 280-287.

   2.  Saltzer, J. H., "Naming and Binding of Objects", in: Operating
       Systems, Lecture notes in Computer Science, Vol. 60, Edited by R.
       Bayer, New York; Springer-Verlag, 1978.

2. Saltzer、以下の「オブジェクトは、命名して、固まる」J.H. Systemsを操作して、LectureはコンピュータでScience、Vol.60、R.バイエル薬品(ニューヨーク)のそばのEditedに注意します。 追出石-Verlag、1978。

   3.  Sunshine, Carl A., "Addressing Problems in Multi-Network
       Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada,
       March 30 - April 1, 1982.

3. 日光、Procに現れるためには「マルチネットワークシステムのその問題を訴えます」カールA.。 IEEE INFOCOM82、ラスベガス(ネバダ)3月30日--1982年4月1日。

   4.  Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
       "PUP: An Internetwork Architecture", IEEE Trans. on Comm. 28, 4
       (April, 1980) pp.  612-623.

4. ボッグズとD.R.とShochとJ.F.とタフト、E.A.とメトカルフェ、R.M.、「産んでください」 「インターネットワークアーキテクチャ」、IEEE、移-. Commに関して。 28、4(1980年4月)ページ 612-623.

   5.  (Anonymous), "The Ethernet, A Local Area Network: Data Link Layer
       and Physical Layer Specifications, Version 1.0", published by
       Xerox Corp., Palo Alto, Calif., Intel Corp., Sunnyvale, Calif.,
       and Digital Equipment Corp., Tewksbury, Mass., September 30,
       1980.

5. (匿名)です。, 「イーサネット、ローカル・エリア・ネットワーク:」 1980年9月30日のLink LayerとPhysical Layer Specifications(バージョン1インチ)がゼロックス社で発表したデータとパロアルト、カリフォルニアインテル社とサニーベル、カリフォルニアとディジタル・イクイップメント社、テュークスベリー、マサチューセッツ州。

   6.  Dalal, Y. K., and Printis, R. S., "48-bit Absolute Internet and
       Ethernet Host Numbers", Proc. Seventh Data Communications
       Symposium, Mexico City, Mexico, October 1981, pp. 240-245.

6. Dalal、Y.K.、およびPrintis、R.S.、「48ビットの絶対インターネットとイーサネットは数を接待する」Proc。 第7Data Communications Symposium、メキシコシティー(メキシコ)1981年10月、ページ 240-245.

   7.  Feinler, E., and J. Postel, Editors, "ARPANET Protocol Handbook",
       SRI International, Menlo Park, Calif., January, 1978.

7. Feinler、E.、およびJ.ポステル、エディターズ、「アルパネットプロトコルハンドブック」、SRIインターナショナル、メンローパーク、カリフォルニア1978年1月。

Saltzer                                                         [Page 9]

RFC 1498   On the Naming and Binding of Network Destinations August 1993

ネットワーク目的地1993年8月の命名と結合でのSaltzer[9ページ]RFC1498

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Jerome H. Saltzer
   M.I.T. Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139
   U.S.A.

技術の正方形のMA02139ジェロームH.Saltzerマサチューセッツ工科大学コンピュータ科学研究所545ケンブリッジ(米国)

   Phone: (617) 253-6016
   EMail: Saltzer@MIT.EDU

以下に電話をしてください。 (617) 253-6016 メールしてください: Saltzer@MIT.EDU

Saltzer                                                        [Page 10]

Saltzer[10ページ]