rfc1291.txt

RFC 的详细文档！

Network Working Group                                        V. Aggarwal
Request for Comments: 1291                      JvNCnet Computer Network
                                                           December 1991


                           Mid-Level Networks
                      Potential Technical Services

Status of this Memo

   This RFC provides information for the Internet community. It does not
   specify an Internet standard. Distribution of this memo is unlimited.

Abstract

   This document proposes a set of technical services that each Internet
   mid-level network can offer within the mid-level network itself and
   and to its peer networks. The term "mid-level" is used as a generic
   term to represent all regional and similar networks, which, due to
   continuous evolutions and transitions, can no longer be termed
   "regional" [MAN]. It discusses the pros and cons of offering these
   services, as well as areas in which mid-level networks can work
   together.

   A large portion of the ideas stem from discussions at the IETF
   Operational Statistics (OPstat), User Connectivity Problems (UCP) and
   Network Joint Management (NJM) working groups.

Table of Contents

   1. Introduction..................................................   2
   2. The Generic Model.............................................   2
   3. Technical Services............................................   3
   3.1  Domain Name Service.........................................   3
   3.2  Public Domain Software......................................   4
   3.3  Network Time................................................   5
   3.4  Network News................................................   5
   3.5  Mailing Lists...............................................   6
   4. Experimental Testbeds.........................................   6
   5. Network Information Services..................................   7
   6. Network Operations............................................   7
   7. References....................................................   8
   8. Security Considerations.......................................   9
   9. Author's Address..............................................   9
   Appendix A Mailing Lists.........................................  10
   Appendix B DNS Architecture Strategy.............................  10





Aggarwal                                                        [Page 1]

RFC 1291             Potential Technical Services          December 1991


1. Introduction

   Over the past few years, the Internet has grown to be a very large
   entity and its dependability is critical to its users. Furthermore,
   due to the size and nature of the network, the trend has been to
   decentralize as many network functions (such as domain name-service,
   whois, etc.) as possible. Efforts are being made in resource
   discovery [SHHH90] so that the work of researchers is not lost in the
   volumes of data that is available on the Internet.

   A side result of this growth has been the logical structure imposed
   in the Internet of networks classified by function. Tangible examples
   in the present state are the NSFnet national backbone, the mid-
   level/regional networks and campus networks. Each of these can be
   viewed as hierarchies within an organization, each serving a slightly
   different function than the other (campus LANs providing access to
   local resources, mid-level networks providing access to remote
   resources, etc.). The functions of each hierarchy then become the
   "services" offered to the organizational layer below it, who in turn
   depend on these services.

   This document proposes a set of basic technical services that could
   be offered by a mid-level network. These services would not only
   increase the robustness of the mid-level network itself, but would
   also serve to structure the distribution of resources and services
   within the Internet. It also proposes a uniform naming convention for
   locating the hosts offering these services.

2. The Generic Model

   The Internet model that is used as the basis for this document is a
   graph of mid-level networks connected to one another, each in turn
   connecting the campus/organization networks and with the end users
   attached to the campus networks. The model assumes that the mid-level
   networks constitute the highest level of functional division within
   the Internet hierarchy described above (this could change in the
   unforeseen future). With this model in perspective, this document
   addresses the objectives of minimizing unnecessary traffic within the
   Internet as well as making the entire structure as robust as
   possible.

   The proposed structure is a derived extension of organizational LANs
   where certain services are offered within the organizational LAN
   itself, such as nameservice, mail, shared files, single or
   hierarchical points of contact for problems, etc.

   The following are the services that are discussed as possible
   functions of a mid-level network:



Aggarwal                                                        [Page 2]

RFC 1291             Potential Technical Services          December 1991


     o  Technical services

     o  Experimental sites for testing and dissemination of new
        software and technology to end sites on the network

   In addition, the following services are mentioned briefly which are
   discussed in detail elsewhere [SSM91, ML91]:

     o  Network Operation services and the interaction between
        different mid-level networks in this area

     o  Network Information services

3. Technical Services

   The Internet has grown to be an essential entity because of the
   services that it offers to its end users. The list of services is
   long and growing, but some services are more widely used and deployed
   than others. This section attempts to list and discuss those
   technical services that could help a mid-level network provide robust
   and improved services to its end sites.

3.1 Domain Name Service

   According to the NSFnet traffic statistics collected for May 1991,
   about 7% of the packets on the NSFnet backbone were domain nameserver
   (DNS) packets. This is a significant amount of traffic, and since
   most of the other network applications depend on this service, a
   robust DNS service is critical to any Internet site.

   Proper location of secondary nameservers so that they are located on
   different physical networks can increase the reliability of this
   service to a large extent [MOC87a, MOC87b]. However, the nature of
   the service requires that the nameservers for the next highest level
   be available in order to resolve names outline-mode side of one's
   domain.  Thus, for "foo.princeton.edu" to resolve "a.mid.net", the
   root nameservers which point to mid.net's nameservers have to be
   reachable.

   To make the service more reliable, the mid-level network could have
   at least one nameserver that is able to resolve nameserver queries
   for all domains directly connected to it. Thus, in the event that the
   entire mid-level network becomes isolated from the rest of the
   Internet, applications can still resolve queries for sites directly
   connected to the mid-level network. Without this functionality, there
   is no way of resolving a name if the root (or higher level)
   nameservers become unreachable, even if the query is for a site that
   is directly connected and reachable.



Aggarwal                                                        [Page 3]

RFC 1291             Potential Technical Services          December 1991


   Strategies for implementing this architecture are discussed in
   appendix B.

   To locate such a "meta-domain" server within a mid-level network, it
   is proposed that a nameserver entry for "meta-dns" exist within the
   mid-level network's domain.

3.2 Public Domain Software

   File transfer traffic constituted 23% of the NSFnet backbone traffic
   for May 1991. Public shareware is a very valuable resource within the
   Internet and a considerable amount of effort is being put into
   developing applications to track all available resources in the
   public archives [SHHH90].

   It would be difficult, if not impossible to create an up-to-date
   repository for every public domain package available on the Internet,
   simply because of the volume of software and the rate at which new
   software is being developed every day. Some hosts have gained
   popularity as good public archives (such as uunet.uu.net, sumex-
   aim.stanford.edu, wuarchive.wustl.edu) and new developers tend to
   distribute the software to these sites as distribution points. The
   economics of maintaining centralized archives is another deterrent to
   centralization (the UUnet archives at uunet.uu.net take up roughly
   1GB of disk storage).

   Recently however, a number of methods for resource discovery have
   been developed and are available on the Internet ("ftp-list" file
   compiled by John Granose - [e-mail], Archie at
   archie.cs.mcgill.ca and Prospero [NEU]).

   It is desirable that the mid-level networks be able to provide up-
   to-date pointers to the distribution hosts for available public
   software archives. Coordinating the distribution of a static list is
   difficult (though not impossible) and the use of automated resource
   discovery mechanisms such as Archie and Prospero is recommended.
   Under ideal conditions, any software that is popular and significant
   (e.g., X11, TeX, RFC's) could be archived and distributed within the
   mid-level network, but measuring "popularity" and "significance" are
   debatable and left for further evaluation. Furthermore, a nameserver
   entry for host "swdist" within the domain can provide information on
   the various available alternatives for software distribution and
   discovery (static file location, pointers to Archie servers, etc.) --
   this nameserver entry can be an alias for a CNAME or a TXT entry.







Aggarwal                                                        [Page 4]

RFC 1291             Potential Technical Services          December 1991


3.3 Network Time

   An important feature of any computer network providing distributed
   services is the capability to synchronize the local clocks on the
   various systems in the network. Ideally, the clocks of all the
   reference sources would be synchronized to national standards by wire
   or radio. The importance and immense popularity of this service makes
   Network Time a very useful potential service that can be provided by
   a mid-level network. No specific protocol for maintaining time is
   proposed, and any available protocol that maintains time with
   reasonable accuracy could be used.

   Network Time Protocol (NTP) traffic constituted 1% of the NSFnet
   traffic during May 1991. The traffic might seem insignificant, but
   there have been instances where a particular stratum-1 timeserver
   (e.g., one of the stratum-1 servers at University of Delaware) has
   reached a point of overload with too many different sites trying to
   peer with it.

   It is proposed that at least one stratum-1 and two stratum-2 servers
   be located within a mid-level network (the selection of three servers
   is based on the NTP standards documentation [MIL89]).  Note that the
   servers can be located at any of the directly connected sites in the
   network as long as they are publicly accessible. All sites connected
   to the mid-level network can then coordinate their system times with
   the servers within the mid-level network itself. Besides increasing
   the reliability of the timekeeping network, this approach would also
   limit the load on each timeserver.

   For locating the network time servers within a domain, nameserver
   entries for "timekeeper-x" (where x= 1,2,3..) can be made within the
   domain. The servers are numbered in order of preference and accuracy.
   Thus, "timekeeper-1.foo.net" would be the primary timekeeper and
   "timekeeper-2.foo.net" would be additional (possibly secondary)
   timekeepers within domain "foo.net". If such hosts are not available
   within a domain, a TXT entry pointing to other recommended time-
   servers could be provided instead.

3.4 Network News

   Network News (or Usenet News) constituted 14% of the NSFnet traffic
   in May 1991. Netnews is an expensive service, both in terms of disk
   and CPU power, as well as network bandwidth consumed.

   The present structure of Network News consists of several hub sites
   which are distributed over the Internet. End sites get news feeds
   from other sites, and an article gets injected into the news stream
   by sending it to the nearest "upstream" site, which then forwards it



Aggarwal                                                        [Page 5]