rfc1498.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 563 行 · 第 1/2 页

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


   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.

   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.

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

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

   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



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


   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.

   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.



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


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:

   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.

   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.

   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.

   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.

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



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


   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.

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.

   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.

   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.

   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.

   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.

   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.

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









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


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.

   Phone: [phone]
   EMail: [e-mail]





































Saltzer                                                        [Page 10]