Network Working Group V. Aggarwal
Request for Comments: 1291 JvNCnet Computer Network
December 1991
Mid-Level Networks Potential Technical Services
Aggarwal [Page 1]
RFC 1291 Potential Technical Services December 1991 1. IntroductionOver 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.
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.
Aggarwal [Page 2]
RFC 1291 Potential Technical Services December 1991
o Experimental sites for testing and dissemination of new software and technology to end sites on the network
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.
Aggarwal [Page 3]
RFC 1291 Potential Technical Services December 1991
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].
Aggarwal [Page 4]
RFC 1291 Potential Technical Services December 1991 3.3 Network TimeAn 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.
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.
Aggarwal [Page 5]
RFC 1291 Potential Technical Services December 1991
A mid-level network could alleviate such occurrences by being able to provide a newsfeed to any or all of its directly connected end sites. Though an expensive resource, some of the costs can be moderated by acting as a transit news feeder so that the news needn't be stored for a long time on disk. The software for providing the news feed is not specific and depends entirely on the newsfeed provider.
3.5 Mailing Lists
Internet mailing lists are another popular source of information in parallel to Network News. However, like public software, there is no central repository of all the possible mailing lists available on the Internet, and it would require considerable effort to compile one (at the time of writing this document, a fairly comprehensive list is available on the Internet and mentioned in appendix A.
4. Experimental Testbeds
Due to the working relationships that they have with their end sites and peer networks, the mid-level networks are very good media for distribution of new ideas and technology. Examples of this function are the White Pages pilot project [RS90] established by NYSERnet, the NSAP routing schema for OSI transitioning [CGC91], etc. The mid-level networks could establish cooperative experimental testbeds for testing and deployment of new technologies similar to the ones mentioned above. Besides deployment and testing of new technology, this could also serve to provide a "help" service to the end-sites and to get them started with the new software.
Aggarwal [Page 6]
RFC 1291 Potential Technical Services December 1991
The exact interaction between the mid-level networks in this area is not very clear. It is complicated by competition for members between the mid-level networks and needs to be discussed further.
5. Network Information Services
There are a variety of new and useful user services available on the Internet that are difficult to document and provide a comprehensive list of. Some attempt has been made at documenting such resources [NNS] and a mid-level network can be the initial point of contact for distribution of such information on a wide basis. The information can be disseminated in a more controlled and complete manner using this hierarchical approach if each mid-level network maintains up-to-date information about its directly connected sites. Network Information services (NIC) also make the network easier and more attractive to end users. Examples of these services are:
6. Network Operations
The Network Operation Center's (NOC's) at the mid-level networks need to cooperate with each other to resolve network problems. In the event of a network problem between two mid-level networks or if an end-site has trouble getting to any host, the mid-level network NOCs can serve to be the initial point of contact. The procedures for interaction among NOCs and the formats for exchange of trouble- tickets between the NOCs are described elsewhere [JOH91, ML91].
Aggarwal [Page 7]
RFC 1291 Potential Technical Services December 1991
It is important for cooperating NOCs to have contact information for their directly connected campus/organizational sites and also about their peer mid-level networks. A distributed mechanism for maintaining contact information could be implemented by using a nameserver TXT entry for "noc" or by maintaining "finger" information for user "noc@domain" or "noc@noc.domain". A NOC "phonebook" listing the contact information for the various NOCs can be used as a static non-distributed mechanism (it is understood that the phonebook can contain outdated information, but the distributed mechanisms can provide correct and updated NOC information provided that the hosts are reachable at the desired time). If it is undesirable to publish the phone number or email address of the NOC for any reason, an entry saying "unpublished" (or words to that effect) could exist in the nameserver or "finger" entry instead.
7. References
[BOG] Dunlap, K., and M. Karels, "Nameserver Operations Guide
Aggarwal [Page 8]
RFC 1291 Potential Technical Services December 1991
[MOC87b] Mockapetris, P., "Domain Names - Concepts and
8. Security Considerations
Security issues are not discussed in this memo.
9. Author's Address
Vikas Aggarwal JvNCnet 6 von Neumann Hall Princeton University Princeton, NJ 08544
Aggarwal [Page 9]
RFC 1291 Potential Technical Services December 1991
Appendix A - Mailing Lists