home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1291 < prev    next >
Text File  |  1991-12-30  |  24KB  |  563 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        V. Aggarwal
  8. Request for Comments: 1291                      JvNCnet Computer Network
  9.                                                            December 1991
  10.  
  11.  
  12.                            Mid-Level Networks
  13.                       Potential Technical Services
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC provides information for the Internet community. It does not
  18.    specify an Internet standard. Distribution of this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document proposes a set of technical services that each Internet
  23.    mid-level network can offer within the mid-level network itself and
  24.    and to its peer networks. The term "mid-level" is used as a generic
  25.    term to represent all regional and similar networks, which, due to
  26.    continuous evolutions and transitions, can no longer be termed
  27.    "regional" [MAN]. It discusses the pros and cons of offering these
  28.    services, as well as areas in which mid-level networks can work
  29.    together.
  30.  
  31.    A large portion of the ideas stem from discussions at the IETF
  32.    Operational Statistics (OPstat), User Connectivity Problems (UCP) and
  33.    Network Joint Management (NJM) working groups.
  34.  
  35. Table of Contents
  36.  
  37.    1. Introduction..................................................   2
  38.    2. The Generic Model.............................................   2
  39.    3. Technical Services............................................   3
  40.    3.1  Domain Name Service.........................................   3
  41.    3.2  Public Domain Software......................................   4
  42.    3.3  Network Time................................................   5
  43.    3.4  Network News................................................   5
  44.    3.5  Mailing Lists...............................................   6
  45.    4. Experimental Testbeds.........................................   6
  46.    5. Network Information Services..................................   7
  47.    6. Network Operations............................................   7
  48.    7. References....................................................   8
  49.    8. Security Considerations.......................................   9
  50.    9. Author's Address..............................................   9
  51.    Appendix A Mailing Lists.........................................  10
  52.    Appendix B DNS Architecture Strategy.............................  10
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Aggarwal                                                        [Page 1]
  59.  
  60. RFC 1291             Potential Technical Services          December 1991
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    Over the past few years, the Internet has grown to be a very large
  66.    entity and its dependability is critical to its users. Furthermore,
  67.    due to the size and nature of the network, the trend has been to
  68.    decentralize as many network functions (such as domain name-service,
  69.    whois, etc.) as possible. Efforts are being made in resource
  70.    discovery [SHHH90] so that the work of researchers is not lost in the
  71.    volumes of data that is available on the Internet.
  72.  
  73.    A side result of this growth has been the logical structure imposed
  74.    in the Internet of networks classified by function. Tangible examples
  75.    in the present state are the NSFnet national backbone, the mid-
  76.    level/regional networks and campus networks. Each of these can be
  77.    viewed as hierarchies within an organization, each serving a slightly
  78.    different function than the other (campus LANs providing access to
  79.    local resources, mid-level networks providing access to remote
  80.    resources, etc.). The functions of each hierarchy then become the
  81.    "services" offered to the organizational layer below it, who in turn
  82.    depend on these services.
  83.  
  84.    This document proposes a set of basic technical services that could
  85.    be offered by a mid-level network. These services would not only
  86.    increase the robustness of the mid-level network itself, but would
  87.    also serve to structure the distribution of resources and services
  88.    within the Internet. It also proposes a uniform naming convention for
  89.    locating the hosts offering these services.
  90.  
  91. 2. The Generic Model
  92.  
  93.    The Internet model that is used as the basis for this document is a
  94.    graph of mid-level networks connected to one another, each in turn
  95.    connecting the campus/organization networks and with the end users
  96.    attached to the campus networks. The model assumes that the mid-level
  97.    networks constitute the highest level of functional division within
  98.    the Internet hierarchy described above (this could change in the
  99.    unforeseen future). With this model in perspective, this document
  100.    addresses the objectives of minimizing unnecessary traffic within the
  101.    Internet as well as making the entire structure as robust as
  102.    possible.
  103.  
  104.    The proposed structure is a derived extension of organizational LANs
  105.    where certain services are offered within the organizational LAN
  106.    itself, such as nameservice, mail, shared files, single or
  107.    hierarchical points of contact for problems, etc.
  108.  
  109.    The following are the services that are discussed as possible
  110.    functions of a mid-level network:
  111.  
  112.  
  113.  
  114. Aggarwal                                                        [Page 2]
  115.  
  116. RFC 1291             Potential Technical Services          December 1991
  117.  
  118.  
  119.      o  Technical services
  120.  
  121.      o  Experimental sites for testing and dissemination of new
  122.         software and technology to end sites on the network
  123.  
  124.    In addition, the following services are mentioned briefly which are
  125.    discussed in detail elsewhere [SSM91, ML91]:
  126.  
  127.      o  Network Operation services and the interaction between
  128.         different mid-level networks in this area
  129.  
  130.      o  Network Information services
  131.  
  132. 3. Technical Services
  133.  
  134.    The Internet has grown to be an essential entity because of the
  135.    services that it offers to its end users. The list of services is
  136.    long and growing, but some services are more widely used and deployed
  137.    than others. This section attempts to list and discuss those
  138.    technical services that could help a mid-level network provide robust
  139.    and improved services to its end sites.
  140.  
  141. 3.1 Domain Name Service
  142.  
  143.    According to the NSFnet traffic statistics collected for May 1991,
  144.    about 7% of the packets on the NSFnet backbone were domain nameserver
  145.    (DNS) packets. This is a significant amount of traffic, and since
  146.    most of the other network applications depend on this service, a
  147.    robust DNS service is critical to any Internet site.
  148.  
  149.    Proper location of secondary nameservers so that they are located on
  150.    different physical networks can increase the reliability of this
  151.    service to a large extent [MOC87a, MOC87b]. However, the nature of
  152.    the service requires that the nameservers for the next highest level
  153.    be available in order to resolve names outline-mode side of one's
  154.    domain.  Thus, for "foo.princeton.edu" to resolve "a.mid.net", the
  155.    root nameservers which point to mid.net's nameservers have to be
  156.    reachable.
  157.  
  158.    To make the service more reliable, the mid-level network could have
  159.    at least one nameserver that is able to resolve nameserver queries
  160.    for all domains directly connected to it. Thus, in the event that the
  161.    entire mid-level network becomes isolated from the rest of the
  162.    Internet, applications can still resolve queries for sites directly
  163.    connected to the mid-level network. Without this functionality, there
  164.    is no way of resolving a name if the root (or higher level)
  165.    nameservers become unreachable, even if the query is for a site that
  166.    is directly connected and reachable.
  167.  
  168.  
  169.  
  170. Aggarwal                                                        [Page 3]
  171.  
  172. RFC 1291             Potential Technical Services          December 1991
  173.  
  174.  
  175.    Strategies for implementing this architecture are discussed in
  176.    appendix B.
  177.  
  178.    To locate such a "meta-domain" server within a mid-level network, it
  179.    is proposed that a nameserver entry for "meta-dns" exist within the
  180.    mid-level network's domain.
  181.  
  182. 3.2 Public Domain Software
  183.  
  184.    File transfer traffic constituted 23% of the NSFnet backbone traffic
  185.    for May 1991. Public shareware is a very valuable resource within the
  186.    Internet and a considerable amount of effort is being put into
  187.    developing applications to track all available resources in the
  188.    public archives [SHHH90].
  189.  
  190.    It would be difficult, if not impossible to create an up-to-date
  191.    repository for every public domain package available on the Internet,
  192.    simply because of the volume of software and the rate at which new
  193.    software is being developed every day. Some hosts have gained
  194.    popularity as good public archives (such as uunet.uu.net, sumex-
  195.    aim.stanford.edu, wuarchive.wustl.edu) and new developers tend to
  196.    distribute the software to these sites as distribution points. The
  197.    economics of maintaining centralized archives is another deterrent to
  198.    centralization (the UUnet archives at uunet.uu.net take up roughly
  199.    1GB of disk storage).
  200.  
  201.    Recently however, a number of methods for resource discovery have
  202.    been developed and are available on the Internet ("ftp-list" file
  203.    compiled by John Granose - odin@pilot.njin.net, Archie at
  204.    archie.cs.mcgill.ca and Prospero [NEU]).
  205.  
  206.    It is desirable that the mid-level networks be able to provide up-
  207.    to-date pointers to the distribution hosts for available public
  208.    software archives. Coordinating the distribution of a static list is
  209.    difficult (though not impossible) and the use of automated resource
  210.    discovery mechanisms such as Archie and Prospero is recommended.
  211.    Under ideal conditions, any software that is popular and significant
  212.    (e.g., X11, TeX, RFC's) could be archived and distributed within the
  213.    mid-level network, but measuring "popularity" and "significance" are
  214.    debatable and left for further evaluation. Furthermore, a nameserver
  215.    entry for host "swdist" within the domain can provide information on
  216.    the various available alternatives for software distribution and
  217.    discovery (static file location, pointers to Archie servers, etc.) --
  218.    this nameserver entry can be an alias for a CNAME or a TXT entry.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Aggarwal                                                        [Page 4]
  227.  
  228. RFC 1291             Potential Technical Services          December 1991
  229.  
  230.  
  231. 3.3 Network Time
  232.  
  233.    An important feature of any computer network providing distributed
  234.    services is the capability to synchronize the local clocks on the
  235.    various systems in the network. Ideally, the clocks of all the
  236.    reference sources would be synchronized to national standards by wire
  237.    or radio. The importance and immense popularity of this service makes
  238.    Network Time a very useful potential service that can be provided by
  239.    a mid-level network. No specific protocol for maintaining time is
  240.    proposed, and any available protocol that maintains time with
  241.    reasonable accuracy could be used.
  242.  
  243.    Network Time Protocol (NTP) traffic constituted 1% of the NSFnet
  244.    traffic during May 1991. The traffic might seem insignificant, but
  245.    there have been instances where a particular stratum-1 timeserver
  246.    (e.g., one of the stratum-1 servers at University of Delaware) has
  247.    reached a point of overload with too many different sites trying to
  248.    peer with it.
  249.  
  250.    It is proposed that at least one stratum-1 and two stratum-2 servers
  251.    be located within a mid-level network (the selection of three servers
  252.    is based on the NTP standards documentation [MIL89]).  Note that the
  253.    servers can be located at any of the directly connected sites in the
  254.    network as long as they are publicly accessible. All sites connected
  255.    to the mid-level network can then coordinate their system times with
  256.    the servers within the mid-level network itself. Besides increasing
  257.    the reliability of the timekeeping network, this approach would also
  258.    limit the load on each timeserver.
  259.  
  260.    For locating the network time servers within a domain, nameserver
  261.    entries for "timekeeper-x" (where x= 1,2,3..) can be made within the
  262.    domain. The servers are numbered in order of preference and accuracy.
  263.    Thus, "timekeeper-1.foo.net" would be the primary timekeeper and
  264.    "timekeeper-2.foo.net" would be additional (possibly secondary)
  265.    timekeepers within domain "foo.net". If such hosts are not available
  266.    within a domain, a TXT entry pointing to other recommended time-
  267.    servers could be provided instead.
  268.  
  269. 3.4 Network News
  270.  
  271.    Network News (or Usenet News) constituted 14% of the NSFnet traffic
  272.    in May 1991. Netnews is an expensive service, both in terms of disk
  273.    and CPU power, as well as network bandwidth consumed.
  274.  
  275.    The present structure of Network News consists of several hub sites
  276.    which are distributed over the Internet. End sites get news feeds
  277.    from other sites, and an article gets injected into the news stream
  278.    by sending it to the nearest "upstream" site, which then forwards it
  279.  
  280.  
  281.  
  282. Aggarwal                                                        [Page 5]
  283.  
  284. RFC 1291             Potential Technical Services          December 1991
  285.  
  286.  
  287.    to its connected news sites, and so on. There is no preset norm for
  288.    finding a site willing to provide a news feed, and it usually ends up
  289.    being a site with whom the site administrator happens to be
  290.    acquainted. However, this could easily result in some sites not being
  291.    able to get an economical news feed from within the mid-level network
  292.    and actually having to derive the feed from a site located on another
  293.    mid-level network.
  294.  
  295.    A mid-level network could alleviate such occurrences by being able to
  296.    provide a newsfeed to any or all of its directly connected end sites.
  297.    Though an expensive resource, some of the costs can be moderated by
  298.    acting as a transit news feeder so that the news needn't be stored
  299.    for a long time on disk. The software for providing the news feed is
  300.    not specific and depends entirely on the newsfeed provider.
  301.  
  302. 3.5 Mailing Lists
  303.  
  304.    Internet mailing lists are another popular source of information in
  305.    parallel to Network News. However, like public software, there is no
  306.    central repository of all the possible mailing lists available on the
  307.    Internet, and it would require considerable effort to compile one (at
  308.    the time of writing this document, a fairly comprehensive list is
  309.    available on the Internet and mentioned in appendix A.
  310.  
  311.    At this time, there is no clear strategy for distributing or
  312.    maintaining mailing lists. However, it can be very expensive for a
  313.    site to distribute mail to all individual end users directly, and if
  314.    a clear strategy for maintaining a list of mailing-lists can be
  315.    devised, then mail exploders can be set up at the mid-level networks,
  316.    each of which forwards the mail to exploders at the end sites. This
  317.    mechanism would reduce the load on the originating systems, and
  318.    provides a clean path for tracking down mailer problems. Also, in
  319.    order to prevent bounced mail from propagating back to the originator
  320.    of the message, the mailing lists should be set up in a way so that
  321.    bounced mail goes to the the "owner" of the list and not to the
  322.    originator of the mail message.
  323.  
  324.    A list of major mailing lists for the services discussed in this
  325.    document are listed in appendix A.
  326.  
  327. 4. Experimental Testbeds
  328.  
  329.    Due to the working relationships that they have with their end sites
  330.    and peer networks, the mid-level networks are very good media for
  331.    distribution of new ideas and technology. Examples of this function
  332.    are the White Pages pilot project [RS90] established by NYSERnet, the
  333.    NSAP routing schema for OSI transitioning [CGC91], etc.
  334.  
  335.  
  336.  
  337.  
  338. Aggarwal                                                        [Page 6]
  339.  
  340. RFC 1291             Potential Technical Services          December 1991
  341.  
  342.  
  343.    The mid-level networks could establish cooperative experimental
  344.    testbeds for testing and deployment of new technologies similar to
  345.    the ones mentioned above. Besides deployment and testing of new
  346.    technology, this could also serve to provide a "help" service to the
  347.    end-sites and to get them started with the new software.
  348.  
  349.    The exact interaction between the mid-level networks in this area is
  350.    not very clear. It is complicated by competition for members between
  351.    the mid-level networks and needs to be discussed further.
  352.  
  353. 5. Network Information Services
  354.  
  355.    There are a variety of new and useful user services available on the
  356.    Internet that are difficult to document and provide a comprehensive
  357.    list of. Some attempt has been made at documenting such resources
  358.    [NNS] and a mid-level network can be the initial point of contact for
  359.    distribution of such information on a wide basis. The information can
  360.    be disseminated in a more controlled and complete manner using this
  361.    hierarchical approach if each mid-level network maintains up-to-date
  362.    information about its directly connected sites. Network Information
  363.    services (NIC) also make the network easier and more attractive to
  364.    end users. Examples of these services are:
  365.  
  366.      o  provide information resources
  367.  
  368.           -  security advisory messages
  369.  
  370.           -  list of library catalogs [GL91]
  371.  
  372.           -  geographical information servers
  373.  
  374.           -  password generators
  375.  
  376.      o  resolve end user problems (user support)
  377.  
  378.    These services are NIC related and discussed in detail elsewhere
  379.    [SSM91]. For accessibility information, an entry for "nic" could
  380.    exist in the DNS for the domain (this could be a TXT entry listing
  381.    email or phone number information for users or other NIC's).
  382.  
  383. 6. Network Operations
  384.  
  385.    The Network Operation Center's (NOC's) at the mid-level networks need
  386.    to cooperate with each other to resolve network problems.  In the
  387.    event of a network problem between two mid-level networks or if an
  388.    end-site has trouble getting to any host, the mid-level network NOCs
  389.    can serve to be the initial point of contact. The procedures for
  390.    interaction among NOCs and the formats for exchange of trouble-
  391.  
  392.  
  393.  
  394. Aggarwal                                                        [Page 7]
  395.  
  396. RFC 1291             Potential Technical Services          December 1991
  397.  
  398.  
  399.    tickets between the NOCs are described elsewhere [JOH91, ML91].
  400.  
  401.    It is important for cooperating NOCs to have contact information for
  402.    their directly connected campus/organizational sites and also about
  403.    their peer mid-level networks. A distributed mechanism for
  404.    maintaining contact information could be implemented by using a
  405.    nameserver TXT entry for "noc" or by maintaining "finger" information
  406.    for user "noc@domain" or "noc@noc.domain". A NOC "phonebook" listing
  407.    the contact information for the various NOCs can be used as a static
  408.    non-distributed mechanism (it is understood that the phonebook can
  409.    contain outdated information, but the distributed mechanisms can
  410.    provide correct and updated NOC information provided that the hosts
  411.    are reachable at the desired time).  If it is undesirable to publish
  412.    the phone number or email address of the NOC for any reason, an entry
  413.    saying "unpublished" (or words to that effect) could exist in the
  414.    nameserver or "finger" entry instead.
  415.  
  416. 7. References
  417.  
  418.    [BOG]     Dunlap, K., and M. Karels, "Nameserver Operations Guide
  419.              for Bind Release 4.8", CSRG, Department of Electrical
  420.              Engineering and Computer Sciences, University of
  421.              California, Berkeley, California.
  422.  
  423.    [CCI88]   CCITT Blue Book, "X.500 Series Recommendations", ITU,
  424.              1989.
  425.  
  426.    [CGC91]   Collela, R., Gardner, E., and R. Callon, "Guidelines for
  427.              OSI NSAP Allocation in the Internet'', RFC 1237,
  428.              NIST, Mitre, DEC, July 1991.
  429.  
  430.    [SSM91]   Sitzler, D., Smith, P., and A. Marine, "Building a Network
  431.              Information Services Infrastructure", RFC in
  432.              preparation.
  433.  
  434.    [GL91]    George, A., and R. Larsen, "Internet Accessible Library
  435.              Catalogs & Databases", Aug 1991.
  436.              Available via anonymous FTP from ariel.unm.edu.
  437.  
  438.    [JOH91]   Johnson, D., "NOC TT Requirements", RFC in
  439.              preparation.
  440.  
  441.    [MAN]     Mandelbaum, R., and P. Mandelbaum, "The Strategic Future
  442.              of the Mid-Level Networks", University of Rochester,
  443.              NY, 1991.
  444.  
  445.    [MOC87a]  Mockapetris, P., "Domain Names - Implementation and
  446.              Specification", RFC 1035, USC Information Sciences
  447.  
  448.  
  449.  
  450. Aggarwal                                                        [Page 8]
  451.  
  452. RFC 1291             Potential Technical Services          December 1991
  453.  
  454.  
  455.              Institute, November 1987.
  456.  
  457.    [MOC87b]  Mockapetris, P., "Domain Names - Concepts and
  458.              Facilities", RFC 1034, USC Information Sciences
  459.              Institute, November 1987.
  460.  
  461.    [MIL89]   Mills, D., "Network Time Protocol", RFC 1129, UDel,
  462.              October 1989.
  463.  
  464.    [ML91]    Mathis, M., and D. Long, "User Connectivity Problems
  465.              Working Group", RFC in preparation.
  466.  
  467.    [NEU]     Neuman, B., "The Virtual System Model: A Scalable
  468.              Approach to Organizing Large Systems", Department of
  469.              Computer Science, University of Washington, FR-35,
  470.              Seattle, WA, May 1990.
  471.  
  472.    [NNS]     NSF Network Service Center, "Internet Resource Guide",
  473.              Cambridge, MA.
  474.              Available via anonymous FTP from nnsc.nsf.net.
  475.  
  476.    [RS90]    Rose, M., and M. Schoffstall, "The NYSERnet White Pages
  477.              Pilot Project", NYSERnet, Inc., Mar 1990.
  478.  
  479.    [SHHH90]  Schwartz, M., Hardy, D., Heinzman, W., and G.
  480.              Hirschowitz, "Supporting Resource Discovery Among
  481.              Public Internet Archives", Department of Computer
  482.              Science, University of Colorado, Boulder, CO.,
  483.              September 1990.
  484.  
  485. 8. Security Considerations
  486.  
  487.    Security issues are not discussed in this memo.
  488.  
  489. 9. Author's Address
  490.  
  491.    Vikas Aggarwal
  492.    JvNCnet
  493.    6 von Neumann Hall
  494.    Princeton University
  495.    Princeton, NJ 08544
  496.  
  497.    Phone: +1-609-258-2403
  498.    Email: vikas@jvnc.net
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Aggarwal                                                        [Page 9]
  507.  
  508. RFC 1291             Potential Technical Services          December 1991
  509.  
  510.  
  511. Appendix A - Mailing Lists
  512.  
  513.    The following is a list of popular mailing lists for the services
  514.    listed in this document. To subscribe to a particular mailing list,
  515.    send a request to "mailing-list-request" (do not send a request to
  516.    the entire mailing list).
  517.  
  518.   o  ietf@isi.edu: The general mailing list for the Internet
  519.      Engineering Task Force. This group is concerned with the evolution
  520.      and development of Internet related protocols and standards. Old
  521.      mail is archived at "venera.isi.edu" in directory ftp/irg/ietf.
  522.  
  523.   o  ntp@trantor.umd.edu: For discussions on the Network Time
  524.      Protocol (NTP).
  525.  
  526.   o  namedroppers@nic.ddn.mil: Mailing list for discussions on DNS
  527.      topics. Old mail is archived at "nic.ddn.mil".
  528.  
  529.    At the time of writing this document, a list of mailing lists on the
  530.    Internet is available via anonymous FTP from host "ftp.nisc.sri.com"
  531.    in the file "netinfo/interest-groups".
  532.  
  533. Appendix B - DNS Architecture Strategy
  534.  
  535.    This section discusses practical strategies for implementing a
  536.    nameserver architecture within a mid-level network, so that it can
  537.    resolve nameserver queries for all domains directly attached to it.
  538.  
  539.    In order to resolve queries for all directly connected networks, a
  540.    host that is authoritative for all directly attached domains will
  541.    need to exist within the mid-level network. Nameservers at the end
  542.    sites would then treat this "group-of-domains" nameserver as a
  543.    forwarding server to resolve all non-local queries.
  544.  
  545.    This can be done by adding a line to the named.boot file on the end
  546.    site nameservers such as:
  547.  
  548.               forwarders 128.121.50.7 128.32.0.4
  549.  
  550.    This method has the added advantage that the forwarding server builds
  551.    up a very rich cache of data [BOG] and acts like a metacache that all
  552.    hosts can benefit from. Note that the forwarding server is queried
  553.    only if the end-site server cannot service a query locally -- hence
  554.    the "meta-domain" server is not overloaded with queries for all
  555.    nameserver lookups.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Aggarwal                                                       [Page 10]
  563.