rfc1498.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 563 行 · 第 1/2 页

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


           On the Naming and Binding of Network Destinations

Status of this 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.

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.

   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.

What is the 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



Saltzer                                                         [Page 1]

RFC 1498   On the Naming and Binding of Network Destinations August 1993


   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.

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

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

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:





Saltzer                                                         [Page 2]

RFC 1498   On the Naming and Binding of Network Destinations August 1993


    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.

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

    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.

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

   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.

   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.




Saltzer                                                         [Page 3]

RFC 1498   On the Naming and Binding of Network Destinations August 1993


   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:

    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.

    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.

    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.

   (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].)

   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:

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

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

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

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

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

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



Saltzer                                                         [Page 4]

RFC 1498   On the Naming and Binding of Network Destinations August 1993


       nodes found in 1.

    3. Route service, to identify the paths that lead from the
       requestor's attachment point to the ones found in 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.

   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.

    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.

    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.

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

   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



Saltzer                                                         [Page 5]