Movatterモバイル変換

RFC: 756                                                July 1979The 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 Conferenceon Distributed Data Management and Computer Networks)

NIC Name Server                                         July 1979                            Abstract  In this paper a new method for distributing and updating hostname/address information in large computer networks is described.The technique uses datagrams to provide a simpletransaction-based query/response service.  A provisional serviceis being provided by the Arpanet Network Information Center (NIC)and is used by mobile packet radio terminals, as well as byseveral Arpanet DEC-10 hosts.  Extensions to the service aresuggested that would expand the query functionality to allow moreflexible query formats as well as queries for service addresses.Several architectural approaches with potential for expansioninto a distributed internet environment are proposed.  Thistechnique may be utilized in support of other distributedapplications such as user identification and group distributionfor computer based mail.1. INTRODUCTION  In large computer networks, such as the Arpanet [1],network-wide standard host-addressing information must bemaintained and distributed.  To fulfill that need, the ArpanetNetwork Information Center (NIC) at SRI International hasmaintained, administered, and distributed the host addressingdata base to Arpanet hosts since 1972 [2].  The most common method for maintaining an up-to-date copy oneach host is to bulk-transfer the entire data base to each hostindividually.  This technique satisfies most host addressingneeds on the Arpanet today.  However, some hosts maintain neithera complete nor a current copy of the data base because of limitedmemory capacity and infrequent processing of updates.  Inaddition, with the expansion of the Arpanet into the internetenvironment [3, 4], a strong need has arisen for new techniquesto augment the distribution of name/address information.  One method currently being investigated is the dynamicdistribution of host-address information via a transaction-based,inquiry-response process called the Name Server [5, 6].  Tosupport this investigation, the NIC has developed a provisionalName Server that is compatible with a level of service specifiedin the Defense Advanced Research Projects Agency (DARPA) Internetexperiment [5].  The basic Name Server is described in this paperand a set of additional functions that such a service might beexpected to support is proposed.  The discussion is structured as follows:Section 1 describesthe NIC Name Server and how it is derived from the NIC data baseservice.Section 2 describes extensions of the name server whichallow a richer syntax and queries for service addresses.  SectionSRI International                                        [Page 1]

July 1979                                         NIC Name Server3 discusses architectural issues, and presents some preliminarythoughts 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 ArpanetDEC-10.  Inquiry-response access is via the Internet Name Serverprotocol [5], which in turn employs the DARPA Internet Protocol,IP4 [7].  To demonstrate the service a simple interactive facility isprovided to format user input into name server requests--e.g. aquery 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 ofhost address formats see [8]).  User access to the name server has been implemented on severalArpanet DEC-10 TENEX and Packet Radio Network LSI-11 TerminalInterface Unit (TIU) hosts [9, 10].  While the TENEX programserves primarily as a demonstration vehicle, the LSI-11 programprovides a valuable augmentation of the TIU's host table.  Atypical scenario is that when the packet radio TIU is initiatedor initialized, it contains only a minimal host table, with theaddresses of a few candidate name servers.  The user queries thename server with a simple manual query process, and then uses theaddress obtained to open a TELNET connection to the desired host.  The information to support the name server originates from theNIC's Arpanet host address data base.  An optimized version ofthis data base is presented to the name server upon programinitiation 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 serverreturns either an address, a list of similar names if a uniquematch is not found, or an error indication.  Several usefuladditional functions can be envisioned for the name server suchas service queries and broader access to host-relatedinformation.3.1. Similar Names  An important issue to be resolved is that of the interpretationgiven to the "similar names" response.  A standard definitionshould 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 providehelpful information to a human-interface process, then it may beuseful to model the behavior of the name server on the behaviorof other known processes that present host name information ondemand.  An example of this is a common implementation of virtualterminal access on the Arpanet, User TELNET [12], in which threedifferent 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 beappropriate to return the "similar names" response only whenrequested.  Two ways to achieve this might be either to set anoption 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 thatof query syntax.  The basic level of service previously describedallows only a few query functions.  With more intelligent nameservers, complex queries can be supported.  The current Internet name server requires two fields in thequery string--a network name field and a host name field.  If thenetwork field is non-existent, a local network query is assumed.  Since network independent queries are desirable, an expandedquery functionality must be specified.  One way this might bedone 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 thisconvention is listed below (Note: ~ is used to mean "null".  Ifboth 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 hostN  ~    named net, local host (inverse search)N  *    named net, all hostsN  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 thequery 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 nets3.3. Service Queries  It has been suggested that the name server be generalized intoa binding function [13, 14].  In this context, allowing servicequeries is a very useful extension.  One application of thisservice, that exists within the Packet Radio Project at SRI, isthe need to find the addresses of Hosts that support theLoaderServer service--a service that allows packet radio TIUs toreceive executable programs via downline loading.  Service querying, unlike host names querying, requires amultiple response capability.  The querying process would, uponreceiving multiple service descriptors, attempt to establishaccess to each service, one at a time, until successful.  Service descriptors consist of an official name, a list ofalias names, and a network-dependent address.  In the case ofArpanet Internet services, this address field would consist ofthe host address(32 bits), port(32 bits), and protocol number(8bits).  For Arpanet NCP services, the address would consist of ahost 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 queriesby the addition of a service name field, as below:                        NET HOST SERVICE  A network-independent service query, for example, can berepresented as:                           * * SERVICE3.4. Name Server Options  The concept of options has been introduced in the discussion ofthe "similar names" function.  Another group of options may beused to specify the format of the reply.  At one extreme is thecompact, binary, style such as exists in the basic level ofservice.  At the other extreme is an expanded, textual, stylesuch as is represented by a NIC host table record with officialand alias names included.  Options can be envisioned thatspecify:   - 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 thesearch, such as "find SERVER hosts only".  An alternate form forspecifying 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 listwill be expanded or contracted to fit the actual needs ofprocesses using the name server service.3.5. MORE DATA Protocol  It should be noted that some of the proposed name serverextensions have the potential for generating more than a singledatagram's worth of reply, since the current DARPA InternetProtocol limits the size which all networks must support to 576octets [15].  In spite of this, the size of such replies need notrequire a full-blown stream protocol.  Several alternativesSRI International                                        [Page 5]

July 1979                                         NIC Name Serverexist:  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.If alternative 1 is chosen, the potential for overflow exists,even with the basic level of service.  Alternative 2 impliesunpredictable behavior to the user of the name server service.Alternative 3 reduces the availability of the service.Alternative 4 is certainly possible, but may be overkill.  Alternative 5 appears to be a reasonable solution and could beimplemented very simply.  The name server could return, as partof the reply, a code of the following form:                       +------+---------+                       | MORE | ID_NEXT |                       +------+---------+where ID_NEXT is a name-server-chosen quantity that allows thename server to find the next block of reply, the next time it isqueried.  This quantity may be an internal pointer, a blocknumber, or whatever the name server chooses.  Follow-on queriesmay be implemented by recomputing the entire original query anddiscarding output until the ID_NEXT block is reached, or byefficiently storing the entire reply in a cache, fragmented intoblocks (with appropriate decay algorithms).3.6. Dynamic Updates  In the previous discussion, the host name data base was assumedto have been a static or slowly changing entity with anadministrative and manual update authority.  This model reflectsmost of the network needs in the Arpanet and Internetcommunities.  However, dynamic automated updating of the hosttable may be needed in the future, especially in mobileenvironments such as the Packet Radio Network.  In a closed user group community (such as a local network ofmutually trusting hosts), dynamic updating becomes simply atechnical question concerning packet formats.  In widercommunities, a mechanism to authenticate the change request mustbe developed; however, the authentication issue is outside thescope of this paper.[Page 6]                                        SRI International

NIC Name Server                                         July 19794. ARCHITECTURE  The Name Server concept is invaluable for allowing hosts withincomplete knowledge of the network address space to obtain fullaccess to network services.  Whether for reasons of insufficientkernel space or of dynamically changing environments, the needfor the service is little questioned.  However, significantdesign issues revolve around the methods for providing theservice and for administering and updating the data base.  In the current NIC Name Server, the service is centralized, andis supported by a data base administered by a single authority.In the long range, other architectures are possible that presentmore flexible ways to distribute host information within andbetween networks and administrative entities.  These presentopportunities for dynamic, automated, approaches to themaintenance and sharing of data--particularly host name data.  From an evolutionary point of view, initial Name Serverservices will likely exist as a centralized service, possiblywith one large Name Server that has knowledge of multiplenetworks.  From this beginning, an expansion in two orthogonaldirections can be envisioned.   - In the direction of internal distribution, the name     server can be partitioned into multiple, cooperating     processes on separate hosts.  The data base can be     replicated exactly or managed as a distributed data     base.   - In the direction of administrative distribution,     multiple autonomous name servers may exist that     exchange data in an appropriate fashion, on a per     network or other administrative basis.  For hosts with small host tables, caching might be used,whereby local, temporary copies would be maintained of subsets ofthe addressing data base.  Such copies may be obtained either byremembering previous queries made of name servers, or byreceiving automatic distributions of data from name servers.  Formobile hosts, in which even the home network is unknown, it wouldbe possible to maintain a very sparse table with the addresses ofonly a few name servers.  For hosts lacking even the knowledge of name server addresses,a very primitive name server function can be provided by allnetwork hosts that would allow real name servers to be located;e.g., a query of the form "*  *  RealNameServer" addressed to anarbitrarily selected host could elicit the address of a real NameServer.  Finally, the possibility exists for multiple name servers tocommunicate dynamically in attempting to resolve queries.  If,SRI International                                        [Page 7]

July 1979                                         NIC Name Serverfor example, a name server on the Arpanet receives a query for ahost on the Packet Radio Network, then the Arpanet name servercan conceivably query the Packet Radio Network Name Server toresolve the reply.5. FUTURE WORK  The techniques discussed in this paper for providing dynamicaccess to and maintenance of host address information aregenerally applicable to other information-providing services.Two possibilities currently under investigation at SRI includeuser identification servers [16] and time servers, which offerpeople/address and time-stamp information, respectively, asdatagram driven information utilities.  Further work is needed to refine the implementation of the nameserver and its using query processes.  Two items in particularare direct system calls into the NIC data base management systemfor general access to host information and process-level queryinterfaces for using processes.  The design issues for efficientimplementation are complex and involve some trade-offs.  The mostobvious trade-off is volume of network traffic versus "freshness"of information. The local host table handler can either send amessage to the name server for every address request, or it canuse some type of local cache to remember frequently requestednames.  SRI is exploring both the process-level interface for theLSI-11 TIU and the problems of local host table management insmall machines operating in a dynamic environment.  Information services such as the Name Server are integralcomponents of distributed systems and applications.  However, theeffective utilization of such services is a relatively unstudiedand unexplored area.  One area in which SRI plans to study theirimpact on distributed architectures is in computer based mailapplications.  Information utilities in this environment canrange from the support of simple mailbox address queries tocomplex address list management needed for inter-organizationaland group resolution.6. CONCLUSION  A provisional Name Server service, based on the NIC hostaddress data base was described in this paper.  In addition, acollection of design ideas for an internet Name Server servicehas been presented.  Work is continuing on the refinement of the NIC name serverservice.  New requirements and opportunities for functionaldistribution are being investigated.  Many questions have been[Page 8]                                        SRI International

NIC Name Server                                         July 1979raised in exploring an expansion of the existing service. Such anexpansion is expected to result in more useful support ofinternet (and intranet) capability.REFERENCES1.    L. G. Roberts and B. D. Wessler, "Computer Network      Development to Achieve Resource Sharing," in Proceedings of      SJCC, pp. 543-549 (AFIP, 1970).2.    M. D. Kudlick and E. J. Feinler, Host Names On-line,RFC608, Stanford Research Institute, Menlo Park, California      (January 1974).3.    V. G. Cerf and R. E. Kahn, "A Protocol for Packet Network      Interconnection," IEEE Transactions on Communication      Technology, Vol. COM-22, pp. 637-641 (1974)._4.    V. G. Cerf and P. T. Kirstein, "Issues in Packet-Network      Interconnection," Proc. IEEE, Vol. 66, No. 11, pp.      1386-1408 (November 1978).5.    J. Postel, Internet Name Server, IEN 89, Information      Sciences Institute, Univ. of Southern Calif., Marina Del      Rey, California, May 1979.6.    J. R. Pickens, E. J. Feinler and J. E. Mathis, An      Experimental Network Information Center Name Server      (NICNAME), IEN 103, SRI International, Menlo Park,      California (May 1979).7.    J. Postel, Internet Protocol, IEN 81, Information Sciences      Institute, Univ. of Southern Calif., Marina Del Rey,      California (February 1979).8.    J. Postel, Address Mappings, IEN 91, Information Sciences      Institute, Univ. of Southern Calif., Marina Del Rey,      California (May 1979).9.    R. E. Kahn, "The Organization of Computer Resources into a      Packet Radio Network," IEEE Transactions on Communications,      Vol. COM-25, No. 1, pp. 169-178 (January 1977).10.   R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C.      Kunzelman, "Advances in Packet Radio Technology," Proc.      IEEE, Vol. 66, No. 11, pp. 1468-1496 (November 1978).11.   J. Postel, User Datagram Protocol, IEN 88, Information      Sciences Institute, Univ. of Southern Calif., Marina Del      Rey, California (May 1979).SRI International                                        [Page 9]

July 1979                                         NIC Name Server12.   E. Leavitt, TENEX USER'S GUIDE, Bolt Beranek and Newman,      Inc., Cambridge, Massachusetts.13.   R. Bressler, A Proposed Experiment With a Message Switching      Protocol (section on Information Operator), pp. 26-31,RFC333, Bolt Beranek and Newman Inc, Cambridge, Mass. (May 15,      1972).14.   Y. Dalal, Internet Meeting, January 24,25 1979, (Group      Discussion).15.   J. Postel, Internet Meeting Notes - 25,26 January 1979, pp.      12, IEN 76, Information Sciences Institute, Univ. of      Southern Calif., Marina Del Rey, California (February      1979).16.   E. J. Feinler, "The Identification Data Base in a      Networking Environment," in NTC '77 Conference Record, pp.      21:3 (IEEE, 1977).[Page 10]                                       SRI International

NIC Name Server                                         July 1979                        Table of Contents1. INTRODUCTION                                               12. THE NIC NAME SERVER                                        23. NAME SERVER ISSUES                                         2     3.1. Similar Names                                         2     3.2. Query Syntax                                          3     3.3. Service Queries                                       4     3.4. Name Server Options                                   5     3.5. MORE DATA Protocol                                    5     3.6. Dynamic Updates                                       64. ARCHITECTURE                                               75. FUTURE WORK                                                86. CONCLUSION                                                 8REFERENCES                                                      9SRI International                                        [Page i]