NATIONAL SCIENCE FOUNDATION Request For Public Comment: Solicitation Concept SUMMARY: NSF is requesting comments on a proposed solicitation covering two separate projects: a Network Access Point (NAP) Manager and Routing Authority (RA) organization; and a provider of very high speed Backbone Network Services (vBNS). This draft solicitation is being released to the public to solicit comments specifically on the scope of NSF's concept on how the various services can best be provided, including (but not limited to) the methodology and feasibility of providing services as proposed. It is anticipated that a new approach to the provision of NSFNET Backbone Network Services will help provide for the continued development and growth of NSFNET and to continue the transition to a more privatized network. DATES: After consideration of comments received by August 3, 1992, NSF intends to prepare and release a final program solicitation for the NAP Manager/RA and the vBNS Provider projects. ADDRESSES: To become part of the official record and to guarantee that issues are addressed through this process, all comments regarding the concepts contained in this draft solicitation must be submitted to NSF in writing (paper, facsimile, or electronic mail) and must be received by 3:00 P.M. Eastern Standard Time, Monday, August 3, 1992, at: National Science Foundation Division of Networking and Communications Research and Infrastructure 1800 G Street, N.W., Room 416 Washington, D.C. 20550 ATTN: G Strawn (NAP Manager/RA and vBNS Provider Comment) Facsimile: 202-357-0320 Electronic mail: gstrawn@nsf.gov PUBLIC DRAFT NETWORK ACCESS POINT MANAGER/ROUTING AUTHORITY AND VERY HIGH SPEED BACKBONE NETWORK SERVICES PROVIDER FOR NSFNET AND THE NREN PROGRAM PROGRAM SOLICITATION I. PURPOSE OF THIS SOLICITATION The NSFNET was designed to support the data networking needs of the research and education community. It has become an essential infrastructure for that community used daily to facilitate communication among researchers, educators, and students and to provide them with remote access to information and computing resources. The number of users, the number of connected networks, and the amount of network traffic continue to grow rapidly. NSFNET also supports the goals of the High Performance Computing and Communications (HPCC) Program which was delineated in the President's Fiscal 1992 and 1993 budgets and became law with the passage of The High Performance Computing Act of 1991 (PL 102-194). One component of the HPCC Program is the National Research and Education Network (NREN) Program which calls for gigabit per second speed networking for research and education by the mid 1990s. Since the creation of the NSFNET in 1986, the data networking industry itself has evolved considerably. New companies have been created and a number of existing companies have shown increasing interest in data networking. These and other evolutionary changes, together with the pending expiration of the current Cooperative Agreement for NSFNET Backbone Network Services, have prompted the need for new arrangements for NSFNET Backbone Network Services. To provide for the continued development and growth of NSFNET and to continue the transition to a more privatized network, a new architecture to provide for Backbone Network Services has been formulated and is specified here. The architecture includes two separate projects for which solicitations are required: a Network Access Point (NAP) Manager and Routing Authority (RA) organization; and, a provider of very high speed Backbone Network Services (vBNS). This architecture also includes components such as regional networks and network service providers for which NSF solicitations are not required. (These components are, however, discussed in Section III.D.) The solicitation invites proposals for a NAP Manager/RA organization to: arrange for and oversee a specific number of NAPs where the vBNS and other appropriate networks may interconnect; establish and maintain a route server database at each NAP which may be used by the NAP-attached networks to obtain routing information with which to construct routing tables. This component of the backbone network services architecture will: provide access for other networks to the U.S. Research and Education community; provide for the interconnection of appropriate networks in an environment which is not subject to the NSF Acceptable Use Policy (AUP) which, in essence, limits traffic to that which is in support of research and education; provide routing stability; provide for advances in routing technology; and, provide for the maintenance of a policy routing database. The solicitation also invites proposals for a vBNS Provider to establish and maintain a vBNS which will be connected to all NAPs and all of whose NSFNET vBNS traffic must be in compliance with the NSF AUP. In the tradition of NSFNET and as discussed below, the vBNS Provider will be expected to demonstrate leadership in the development and deployment of high performance data communications networks. This component of the architecture will: provide for high speed interregional connectivity; enable distributed computing applications; enable multimedia applications such as visualization, collaboration, and distance learning; and, promote the development and deployment of advanced routing technologies. It is anticipated that the solicitation will result in two separate five-year cooperative agreements between NSF and the organizations and/or consortia chosen as NAP Manager/RA, and vBNS Provider. The two anticipated awards will be made to different organizations (or non-overlapping consortia of organizations). Total NSF funding is expected to be approximately $10,000,000 per year. This solicitation is issued pursuant to the National Science Foundation Act of 1950, as amended (42 U.S.C. 1861 et seq) and the Federal Cooperative Agreement Act (31 U.S.C. 6305) and is not subject to the Federal Acquisition Regulations. II. BACKGROUND The network of networks known as the Internet includes more than 5,000 networks. These networks link together hundreds of thousands of computers and millions of users throughout the world. The domestic portion of the Internet contains a number of NSFÐsupported networks. These include: campus network connections at educational institutions; midlevel networks; and NSFNET backbone network services. Broadly speaking, NSFNET consists of all of these networks together with a number of other networks at locations such as government laboratories and private corporations. The Internet also includes other federally-sponsored networks such as NASA Science Internet (NSI), DOE's Energy Sciences Network (ESnet), and DARPA's DARTnet and TWBnet. These and other networks and the NSFNET are expected to evolve into a gigabit per second network that allows for both the interconnection and interoperability of federally funded research and education networks with each other and with private sector networks. This multi- agency program is referred to as the NREN. During the evolution of the NREN Program, account will have to be taken of the requirements of the various network-sponsoring federal agencies. For example, network traffic on NSI and ESnet normally must be in support of the focused missions of NASA and DOE, respectively. NSF, on the other hand, has the broad mission to support science and engineering research and education. As such, NSFNET will carry traffic in support of general research and education requirements. Because of the breadth of the charter of the NSFNET and because of its wide use by the research and education community, it is projected that the NSFNET user base will continue to grow and that its users will continue to require new levels of network services. The expansion in numbers of users and levels of services make the provision of increasingly high performance Backbone Network Services necessary for the continued success and growth of NSFNET. The new NSFNET Backbone Network Services will also be important in the evolution of the NREN Program. After consultation with many segments of the Internet community, the National Science Foundation has developed this solicitation for a NAP Manager/RA organization and a vBNS Provider. In the manner specified below, it is anticipated that NSFNET will: develop increasingly high performance network services; accommodate the anticipated growth in numbers of users and networks and in network traffic; and, transition to a networking infrastructure that is increasingly provisioned by network service providers from the private sector. III. NETWORK ARCHITECTURE AND PROJECT REQUIREMENTS NSF intends to establish a vBNS for NSFNET in the following manner. A number of NAPs will be established where the vBNS and other appropriate networks will be interconnected. (The number and location of the NAPs will be specified in the final solicitation.) A NAP Manager/RA organization will arrange for and oversee the NAPs and will maintain Route Servers with routing and policy databases for networks attached to the NAPs. The NAP Manager/RA will also provide certain routing services for the Internet community. This section gives more details on this approach to providing backbone network services and gives specific requirements for both providers. A. Network Access Points A NAP is defined as a high speed network or switch to which a number of routers can be connected for the purpose of traffic exchange and interoperation. It must have capacity adequate to keep up with the switching requirements of the attached networks. A NAP Manager/RA Organization will be responsible for oversight and coordination of the NAPs. The NAPs will be a conceptual evolution of the Federal Information eXchanges (FIX-East and FIX-West) and the Commercial Information eXchange (CIX). The FIXes are each built around a 100 mbps FDDI ring with attached networks operating at speeds of up to 45 megabits per second (but neither the FIXes nor the CIX currently have dedicated route servers with route databases). Examples of NAP implementation include (but are not limited to) a LAN (like the FIXes) or a MAN (Metropolitan Area Network) using a service such as Switched Multimegabit Data Service (SMDS). With any implementation, it would be desirable to provide an environment which attempts to equalize and lower the cost of connecting to the NAPs for prospective network services providers. For example, this might be accomplished by locating each NAP "close" to a Point of Presence (POP) of each of the major Inter- eXchange Carriers (IXCs). ("Close" might mean within the same Local Access and Transport Area and, for a LAN implementation, also within a specified number of air miles of the POP of each major IXC.) The vBNS will operate under the same Acceptable Use Policy (AUP) as the current NSFNET BNS. However, the NAPs will operate in an "AUP-free" mode. This will permit, for example, two attached networks to exchange traffic without violating the AUPs of any other attached network. B. NAP Manager/Routing Authority Under the current cooperative agreement that provides for backbone network services, the same consortium which provides the BNS also acts as routing authority. Under the new cooperative agreements described here, the routing authority function will be separated from the provision of the BNS. The NAP Manager/RA will provide for equitable treatment of the various network services providers during routing administration and will provide for a common database of route information to promote stability of the network. By the use of specified external gateway protocols such as BGP and IDRP (Boarder Gateway Protocol and Inter-Domain Routing Protocol), the NAP Manager/RA will create a database of all announced networks and their paths of accessibility. This information will be maintained in route databases which will be deployed at each NAP. Attached networks will be able to utilize this information while creating and modifying their own routing tables. The NAP Manager/RA organization will also provide certain other services which will facilitate the logical interconnection of the attached networks. In particular, it will assist in the development of new routing technologies and the deployment of simplified routing strategies for attached networks. The specific anticipated duties of the NAP Manager/RA organization are as follows: ¥ Establish and maintain, possibly with subcontractors, the specified NAPs for the purpose of connecting the vBNS and other appropriate networks. NAPs are to be AUP- free and can be proposed to be implemented as LANs or MANs or other innovative approaches. NAPs must operate at speeds of at least 100 mbps and must be able to be upgraded as required by demand and usage and by Program goals ¥ Develop and establish attachment policies (including attachment fee schedules) which would apply to networks that connect to NAPs ¥ Specify reliability and security standards for the NAPs and ensure that these standards are met ¥ Specify appropriate access procedures to the NAPs for authorized personnel of connecting networks and ensure that these procedures are carried out ¥ Provide appropriate NAP accounting and statistical capabilities ¥ Establish and maintain a Route Server database at each NAP by exchanging routing information with and dynamically updating routing information from the attached Autonomous Systems using BPG and IDRP. NAPs must support the switching of IP and CLNP packets (Internet Protocol and ConnectionLess Networking Protocol) ¥ Work to ensure routing stability ¥ Develop advanced routing standards and technologies in cooperation with the global Internet community ¥ Provide for simplified routing strategies for attached networks such as default routing ¥ Propose and establish procedures to work with the vBNS Provider and personnel from other attached networks to resolve problems and to support end-to-end connectivity and quality of service for network users ¥ Promote distributed operation of the Internet C. Very High Speed Backbone Network Services Provider Since its inception, the NSFNET has been a leader in providing for high speed networking services for the research and education community. The vBNS will continue this tradition and will provide for: high speed interregional connectivity; multimedia traffic in support of visualization, collaboration, and distance learning; and, distributed computing capabilities. The vBNS must be able to switch both IP and CLNP packets and it must operate at speeds of at least 155 megabits per second. The vBNS Provider must participate in the development of advanced routing technologies such as type of service and precedence routing. The vBNS may have connections and customers beyond those specified by NSF as long as the quality and quantity of required services for NSF-specified customers are not affected. In this regard, the vBNS Provider must be able to distinguish between NSF customer traffic and that of other customers and to report traffic statistics based on these categories. Figure 1 shows the network architecture from the point of view of NSF. The specific anticipated duties of the vBNS Provider are as follows: o Establish and maintain a 155 mbps or higher transit network which switches IP and CLNP packets and which connects to all NAPs in order to provide NSFNET users with a vBNS. o Propose and establish a set of quality of service metrics which will be used to characterize the proposed network services and to ascertain and publicize network performance on an ongoing basis o Subscribe to the policies of the NAP Manager/RA; implement BGP- and IDRP- based procedures to interact with those of that organization to assist in establishing and maintaining the route database o Provide for real-time multimedia services, including multicasting and video teleconferencing o Propose and establish procedures to work with the NAP Manager/RA and personnel from other attached networks to resolve problems and to support end-to-end connectivity and quality of service for network users o Participate in the development of advanced routing technologies (such as type of service or precedence routing) in cooperation with the global Internet community o Propose and establish a schedule to enhance both the speed at which the network operates and other quality of service measures and type of service advances in line with NSF's broad program goals and consistent with anticipated NSF customer requirements and available funding D. Other Architectural and Policy Considerations It is anticipated that networks other than the vBNS will connect to the NAPs. Examples of such networks include: other federally sponsored networks; other service providers for research and education; service providers for traffic which is not limited to the support of research and education; and international networks. In each case, attachment of a network to one or more NAPs will require the payment of both an initial and an annual fee (which will depend on parameters such as number of NAP connections and bandwidth of the connections). Fees will be determined by the NAP Manager/RA and NSF so as to recover the expenses associated with the NAPs and with the NAP Manager/RA. To attach to a NAP, a network must also subscribe to the policies of the NAP Manager/RA and implement BGP- and IDRP-based procedures to interact with those of the NAP Manager/RA to assist in establishing and maintaining the route database. Networks attaching to NAPs must operate at speeds of 1.5 mbps or greater and must be able to switch both IP and CLNP packets. Additionally, attached networks must be able to support video teleconferencing, either by packet video or by circuits multiplexed from their total bandwidth. As shown in Figure 2, when the network architecture is viewed from the perspective of any network service provider, the vBNS is just another service provider. (This may even be the view for the network which underlies the vBNS if that network has customers beyond those specified by NSF.) NSFNET midlevel networks may connect either to network services providers which are connected to NAPs or directly to NAPs. NSF will support for one year a single such connection fee for midlevel networks which are currently connected to the NSFNET Backbone Network Service. In the following years of the cooperative agreement, NSF support for the connection fee will decrease and the midlevel network will need to increase other sources of support correspondingly. NSF support of this fee will cease after the (first) term of the NAP Manager/RA Cooperative Agreement. It is anticipated that a number of research institutions will want to take advantage of the advanced capabilities of the vBNS as they access facilities such as the NSF Supercomputing Centers and the NSF Science and Technology Centers, especially for multimedia-based and distributed computing-based applications. Although the subject is not addressed in this solicitation, NSF expects to support such institutional requirements where feasible based on the scientific merit of proposed applications. Each network connected to the NAPs may be required to provide access to the NAP Manager/RA to certain network Management Information Base (MIB) variables. (Specific MIB variables may be listed in the final solicitation, but the list of variables will be subject to change as conditions warrant.) The use of these MIB variables will be to promote the performance and stability of the network.