rfc756.txt

RFC 的详细文档！

If alternative 1 is chosen, the potential for overflow exists,
even with the basic level of service.  Alternative 2 implies
unpredictable 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 be
implemented very simply.  The name server could return, as part
of the reply, a code of the following form:

                       +------+---------+
                       | MORE | ID_NEXT |
                       +------+---------+

where ID_NEXT is a name-server-chosen quantity that allows the
name server to find the next block of reply, the next time it is
queried.  This quantity may be an internal pointer, a block
number, or whatever the name server chooses.  Follow-on queries
may be implemented by recomputing the entire original query and
discarding output until the ID_NEXT block is reached, or by
efficiently storing the entire reply in a cache, fragmented into
blocks (with appropriate decay algorithms).


3.6. Dynamic Updates

  In the previous discussion, the host name data base was assumed
to have been a static or slowly changing entity with an
administrative and manual update authority.  This model reflects
most of the network needs in the Arpanet and Internet
communities.  However, dynamic automated updating of the host
table may be needed in the future, especially in mobile
environments such as the Packet Radio Network.

  In a closed user group community (such as a local network of
mutually trusting hosts), dynamic updating becomes simply a
technical question concerning packet formats.  In wider
communities, a mechanism to authenticate the change request must
be developed; however, the authentication issue is outside the
scope of this paper.


[Page 6]                                        SRI International
NIC Name Server                                         July 1979



4. ARCHITECTURE

  The Name Server concept is invaluable for allowing hosts with
incomplete knowledge of the network address space to obtain full
access to network services.  Whether for reasons of insufficient
kernel space or of dynamically changing environments, the need
for the service is little questioned.  However, significant
design issues revolve around the methods for providing the
service and for administering and updating the data base.

  In the current NIC Name Server, the service is centralized, and
is supported by a data base administered by a single authority.
In the long range, other architectures are possible that present
more flexible ways to distribute host information within and
between networks and administrative entities.  These present
opportunities for dynamic, automated, approaches to the
maintenance and sharing of data--particularly host name data.

  From an evolutionary point of view, initial Name Server
services will likely exist as a centralized service, possibly
with one large Name Server that has knowledge of multiple
networks.  From this beginning, an expansion in two orthogonal
directions 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 of
the addressing data base.  Such copies may be obtained either by
remembering previous queries made of name servers, or by
receiving automatic distributions of data from name servers.  For
mobile hosts, in which even the home network is unknown, it would
be possible to maintain a very sparse table with the addresses of
only a few name servers.

  For hosts lacking even the knowledge of name server addresses,
a very primitive name server function can be provided by all
network hosts that would allow real name servers to be located;
e.g., a query of the form "*  *  RealNameServer" addressed to an
arbitrarily selected host could elicit the address of a real Name
Server.

  Finally, the possibility exists for multiple name servers to
communicate dynamically in attempting to resolve queries.  If,

SRI International                                        [Page 7]
July 1979                                         NIC Name Server



for example, a name server on the Arpanet receives a query for a
host on the Packet Radio Network, then the Arpanet name server
can conceivably query the Packet Radio Network Name Server to
resolve the reply.



5. FUTURE WORK

  The techniques discussed in this paper for providing dynamic
access to and maintenance of host address information are
generally applicable to other information-providing services.
Two possibilities currently under investigation at SRI include
user identification servers [16] and time servers, which offer
people/address and time-stamp information, respectively, as
datagram driven information utilities.

  Further work is needed to refine the implementation of the name
server and its using query processes.  Two items in particular
are direct system calls into the NIC data base management system
for general access to host information and process-level query
interfaces for using processes.  The design issues for efficient
implementation are complex and involve some trade-offs.  The most
obvious trade-off is volume of network traffic versus "freshness"
of information. The local host table handler can either send a
message to the name server for every address request, or it can
use some type of local cache to remember frequently requested
names.  SRI is exploring both the process-level interface for the
LSI-11 TIU and the problems of local host table management in
small machines operating in a dynamic environment.

  Information services such as the Name Server are integral
components of distributed systems and applications.  However, the
effective utilization of such services is a relatively unstudied
and unexplored area.  One area in which SRI plans to study their
impact on distributed architectures is in computer based mail
applications.  Information utilities in this environment can
range from the support of simple mailbox address queries to
complex address list management needed for inter-organizational
and group resolution.



6. CONCLUSION

  A provisional Name Server service, based on the NIC host
address data base was described in this paper.  In addition, a
collection of design ideas for an internet Name Server service
has been presented.

  Work is continuing on the refinement of the NIC name server
service.  New requirements and opportunities for functional
distribution are being investigated.  Many questions have been

[Page 8]                                        SRI International
NIC Name Server                                         July 1979



raised in exploring an expansion of the existing service. Such an
expansion is expected to result in more useful support of
internet (and intranet) capability.



REFERENCES

1.    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, RFC
      608, 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 Server



12.   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, RFC
      333, 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 Contents

1. INTRODUCTION                                                 1
2. THE NIC NAME SERVER                                          2
3. 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                                       6
4. ARCHITECTURE                                                 7
5. FUTURE WORK                                                  8
6. CONCLUSION                                                   8
REFERENCES                                                      9







































SRI International                                        [Page i]