rfc756.txt

RFC 相关的技术文档

RFC: 756                                                July 1979









    The NIC Name Server--A Datagram Based Information Utility

                         by

   John R. Pickens, Elizabeth J. Feinler, and James E. Mathis




                            July 1979



                        SRI International
               Telecommunications Sciences Center
                         333 Ravenswood
                  Menlo Park, California 94025

(Also published in Proceedings of the Fourth Berkeley Conference
on Distributed Data Management and Computer Networks)           
NIC Name Server                                         July 1979



                            Abstract


  In this paper a new method for distributing and updating host
name/address information in large computer networks is described.
The technique uses datagrams to provide a simple
transaction-based query/response service.  A provisional service
is being provided by the Arpanet Network Information Center (NIC)
and is used by mobile packet radio terminals, as well as by
several Arpanet DEC-10 hosts.  Extensions to the service are
suggested that would expand the query functionality to allow more
flexible query formats as well as queries for service addresses.
Several architectural approaches with potential for expansion
into a distributed internet environment are proposed.  This
technique may be utilized in support of other distributed
applications such as user identification and group distribution
for computer based mail.



1. INTRODUCTION

  In large computer networks, such as the Arpanet [1],
network-wide standard host-addressing information must be
maintained and distributed.  To fulfill that need, the Arpanet
Network Information Center (NIC) at SRI International has
maintained, administered, and distributed the host addressing
data base to Arpanet hosts since 1972 [2].

  The most common method for maintaining an up-to-date copy on
each host is to bulk-transfer the entire data base to each host
individually.  This technique satisfies most host addressing
needs on the Arpanet today.  However, some hosts maintain neither
a complete nor a current copy of the data base because of limited
memory capacity and infrequent processing of updates.  In
addition, with the expansion of the Arpanet into the internet
environment [3, 4], a strong need has arisen for new techniques
to augment the distribution of name/address information.

  One method currently being investigated is the dynamic
distribution of host-address information via a transaction-based,
inquiry-response process called the Name Server [5, 6].  To
support this investigation, the NIC has developed a provisional
Name Server that is compatible with a level of service specified
in the Defense Advanced Research Projects Agency (DARPA) Internet
experiment [5].  The basic Name Server is described in this paper
and a set of additional functions that such a service might be
expected to support is proposed.

  The discussion is structured as follows:  Section 1 describes
the NIC Name Server and how it is derived from the NIC data base
service.  Section 2 describes extensions of the name server which
allow a richer syntax and queries for service addresses.  Section

SRI International                                        [Page 1]
July 1979                                         NIC Name Server



3 discusses architectural issues, and presents some preliminary
thoughts on how to evolve from the current centralized,
hierarchic service to a distributed Name Server service.



2. THE NIC NAME SERVER

  A Name Server service has been installed on SRI-KA, an Arpanet
DEC-10.  Inquiry-response access is via the Internet Name Server
protocol [5], which in turn employs the DARPA Internet Protocol,
IP4 [7].

  To demonstrate the service a simple interactive facility is
provided to format user input into name server requests--e.g. a
query of the form !ARPANET!FOO-TENEX returns an address such as
"10 2 0 9" (NET=10, HOST=2, LOGICALHOST=0, IMP=9; for details of
host address formats see [8]).

  User access to the name server has been implemented on several
Arpanet DEC-10 TENEX and Packet Radio Network LSI-11 Terminal
Interface Unit (TIU) hosts [9, 10].  While the TENEX program
serves primarily as a demonstration vehicle, the LSI-11 program
provides a valuable augmentation of the TIU's host table.  A
typical scenario is that when the packet radio TIU is initiated
or initialized, it contains only a minimal host table, with the
addresses of a few candidate name servers.  The user queries the
name server with a simple manual query process, and then uses the
address obtained to open a TELNET connection to the desired host.

  The information to support the name server originates from the
NIC's Arpanet host address data base.  An optimized version of
this data base is presented to the name server upon program
initiation as an input file.



3. NAME SERVER ISSUES

  The basic name server provides a simple address-binding service
[5].  In response to a datagram query [7, 11], the name server
returns either an address, a list of similar names if a unique
match is not found, or an error indication.  Several useful
additional functions can be envisioned for the name server such
as service queries and broader access to host-related
information.


3.1. Similar Names

  An important issue to be resolved is that of the interpretation
given to the "similar names" response.  A standard definition
should be given and not be left to implementors' whims.

[Page 2]                                        SRI International
NIC Name Server                                         July 1979



  If the "similar names" response is used primarily to provide
helpful information to a human-interface process, then it may be
useful to model the behavior of the name server on the behavior
of other known processes that present host name information on
demand.  An example of this is a common implementation of virtual
terminal access on the Arpanet, User TELNET [12], in which three
different functions occur:

  1. Upon termination of host name input (e.g. <CR>), the
     user is warned only with an audible alarm if the name
     used is not unique.  If the name is unique, the name is
     completed, and the requested operation is initiated.

  2. In response to <ESC>, either the name will be completed
     if unique or the user will be warned with an audible
     alarm if the name is not unique.

  3. Only in response to "?" will a list of similar names be
     printed.  "Similar names", in this case, means all
     names that begin with the same character string.  The
     list is alphabetized.

  In support of this style of user interface, it may be
appropriate to return the "similar names" response only when
requested.  Two ways to achieve this might be either to set an
option bit or to use "?" to force the similar names response.


3.2. Query Syntax

  A second issue in the provision of name server service is that
of query syntax.  The basic level of service previously described
allows only a few query functions.  With more intelligent name
servers, complex queries can be supported.

  The current Internet name server requires two fields in the
query string--a network name field and a host name field.  If the
network field is non-existent, a local network query is assumed.

  Since network independent queries are desirable, an expanded
query functionality must be specified.  One way this might be
done is to add to the notion of "missing field", which means
"local", the notion of a special character like "*", which means
"all".

  The semantic range of queries afforded by adopting this
convention is listed below (Note: ~ is used to mean "null".  If
both network and host fields are null the representation is "~
~".  "N" means "network" and "H" means "host"):





SRI International                                        [Page 3]
July 1979                                         NIC Name Server




~  ~    local net, local host (validity check?)

~  *    local net, all hosts

~  H    local net, named host

*  ~    all nets, local host (inverse search)

*  *    all nets, all hosts (probably prohibited)

*  H    all nets, named host

N  ~    named net, local host (inverse search)

N  *    named net, all hosts

N  H    named net, named host

  By combining the on-demand similar-names function, "all" and
"local", and by allowing "*" to be prefixed or appended to the
query string as a wild card character, one can query as follows:


~  SRI*?        All hosts named SRI* on local net

*  SRI*?        All hosts named SRI* on all nets

*  *UNIX*?      All hosts named *UNIX* on all nets


3.3. Service Queries

  It has been suggested that the name server be generalized into
a binding function [13, 14].  In this context, allowing service
queries is a very useful extension.  One application of this
service, that exists within the Packet Radio Project at SRI, is
the need to find the addresses of Hosts that support the
LoaderServer service--a service that allows packet radio TIUs to
receive executable programs via downline loading.

  Service querying, unlike host names querying, requires a
multiple response capability.  The querying process would, upon
receiving multiple service descriptors, attempt to establish
access to each service, one at a time, until successful.

  Service descriptors consist of an official name, a list of
alias names, and a network-dependent address.  In the case of
Arpanet Internet services, this address field would consist of
the host address(32 bits), port(32 bits), and protocol number(8
bits).  For Arpanet NCP services, the address would consist of a
host address(24 bits) and a socket(32 bits).


[Page 4]                                        SRI International
NIC Name Server                                         July 1979



  Syntactically, service queries can be derived from host queries
by the addition of a service name field, as below:

                        NET HOST SERVICE

  A network-independent service query, for example, can be
represented as:

                           * * SERVICE


3.4. Name Server Options

  The concept of options has been introduced in the discussion of
the "similar names" function.  Another group of options may be
used to specify the format of the reply.  At one extreme is the
compact, binary, style such as exists in the basic level of
service.  At the other extreme is an expanded, textual, style
such as is represented by a NIC host table record with official
and alias names included.  Options can be envisioned that
specify:

   - Binary versus text format

   - Inclusion of each field in the reply

   - Inclusion of official name, per field, in the reply

   - Inclusion of alias names, per field, in the reply

   - Inclusion of other miscellaneous information, such as
     operating system, machine type, access restrictions,
     and so on.

Other options can be envisioned that specify the scope of the
search, such as "find SERVER hosts only".  An alternate form for
specifying formats might be to settle on several standard ones,
and allow an option to select among them.

  Certainly, not all name servers can support all such options,
and not all options are equally useful.  Thus, the proposed list
will be expanded or contracted to fit the actual needs of
processes using the name server service.


3.5. MORE DATA Protocol

  It should be noted that some of the proposed name server
extensions have the potential for generating more than a single
datagram's worth of reply, since the current DARPA Internet
Protocol limits the size which all networks must support to 576
octets [15].  In spite of this, the size of such replies need not
require a full-blown stream protocol.  Several alternatives

SRI International                                        [Page 5]
July 1979                                         NIC Name Server



exist:

  1. Disallow options that imply large replies.

  2. Truncate the packet for large replies.

  3. Ignore the recommended maximum datagram size.

  4. Utilize an alternate base protocol for such requests.

  5. Develop a MORE DATA protocol.