The Internet Today

The decommissioning of NSFNET had to be done in specific stages to ensure continuous connectivity to institutions and government agencies that used to be connected to the regional networks. Today's Internet structure is a move from a core network (NSFNET) to a more distributed architecture operated by commercial providers such as Sprint, MCI, BBN, and others connected via major network exchange points. Figure 1-2 illustrates the general form of the Internet today.

Figure 1-2  The general structure of today's Internet.

The contemporary Internet is a collection of providers that have connection points called POP (point of presence) over multiple regions. Its collection of POPs and the way its POPs are interconnected form a provider's network. Customers are connected to providers via the POPs. Customers of providers can be providers themselves. Providers that have POPs throughout the U.S. are called national providers.

Providers that cover specific regions (regional providers) connect themselves to other providers at one or multiple points. To enable customers of one provider to reach customers of another provider, Network Access Points (NAPs) are defined as interconnection points. The term ISP is usually used when referring to anyone who provides service, whether directly to end users or to other providers. The term NSP (network service provider) is usually restricted to providers who have NSF funding to manage the Network Access Points, such as Sprint, Ameritech, and MFS. The term NSP, however, is also used more loosely to refer to any provider that connects to all the NAPs.

NSFNET Solicitations

NSFNET has supported data and research on networking needs since 1986. NSFNET also supported the goals of the High Performance Computing and Communications (HPCC) Program, which promoted leading-edge research and science programs. The National Research and Education Network (NREN) Program, which is a subdivision of the HPCC Program, called for Gigabit-per-second networking for research and education to be in place by the mid 1990s. All these needs, in addition to the April 1995 expiration deadline of the Cooperative Agreement for NSFNET Backbone Network Services, lead NSFNET to solicit for NSFNET services. This process is generally referred to as solicitation.

The first NSF solicitation, in 1987, lead to the NSFNET backbone upgrade to T3 links by the end of 1993. In 1992, NSF wanted to develop a follow-up solicitation that would accommodate and promote the role of commercial service providers and that would lay down the structure of a new and robust Internet model. At the same time, NSF would step back from the actual operation of the network and focus on research aspects and initiatives. The final NSF solicitation (NSF 93-52) was issued in May 1993.

The final solicitation included four separate projects for which proposals were invited:

•  Creating a set of Network Access Points (NAPs) where major providers connect their networks and exchange traffic.

•  Implementing a Route Arbiter (RA) project to facilitate the exchange of policies and addressing of multiple providers connected to the NAPs.

•  Finding a provider of a very high-speed Backbone Network Service (vBNS) for educational and governmental purposes.

•  Transitioning existing and/or realigned regional networks to support interregional connectivity (IRC) by connecting to NSPs that are connected to NAPs or by connecting directly to NAPs. Any NSP selected for this purpose must connect to at least three of the NAPs.

Network Access Points

The solicitation for this project was to invite proposals from companies to implement and manage a specific number of NAPs where the vBNS and other appropriate networks may interconnect. These NAPs should enable regional networks, network service providers, and the U.S. research and education community to connect and exchange traffic with one another. They also should provide for the interconnection of networks in an environment that is not subject to the NSF Acceptable Use Policy. (This policy was put in place to restrict the use of the Internet for research and education.) Thus, general usage, including commercial usage, can go through the NAPs also.

What Is a NAP?

The 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. NAPs must operate at speeds of at least 100 Mbps and must be able to be upgraded as required by demand and usage. The NAP could be as simple as an FDDI switch (100 Mbps) or an ATM switch (155 Mbps) passing traffic from one provider to the other.

The concept of the NAP is built on the FIX (Federal Internet eXchange) and the CIX (Commercial Internet eXchange), which are built around FDDI rings with attached Internet networks operating at speeds of up to 45 Mbps.

The traffic on the NAP should not be restricted to that which is in support of research and education. Networks connected to the NAP are permitted to exchange traffic without violating the use policies of any other networks interconnected to the NAP.

There are four NSF-awarded NAPs:

•  Sprint NAP—Pennsauken, NJ

•  PacBell NAP—San Francisco, CA

•  Ameritech Advanced Data Services (AADS) NAP—Chicago, IL

•  MFS Datanet (MAE-East) NAP—Washington, D.C.

The NSFNET backbone service was physically connected to the Sprint NAP on September 13, 1994. It was physically connected to the PacBell NAP and Ameritech NAP in mid-October 1994 and early January 1995, respectively. The NSFNET backbone service was upgraded to the collocated FDDI offered by MFS on March 22, 1995.

Additional NAPs are being created around the world as providers keep finding the need to interconnect.

Networks attaching to NAPs must operate at speeds commensurate with the speeds of attached networks (1.5 Mbps or greater) and must be upgradable as required by demand, usage, and program goals. NAPs must be able to switch both IP and CLNP (ConnectionLess Networking Protocol). The requirements to switch CLNP packets and to implement IDRP-based (InterDomain Routing Protocol, ISO OSI Exterior Gateway Protocol) procedures may be waived depending on the overall level of service and the U.S. government's desire to foster the use of ISO OSI protocols.