Fortunately, nobody owns the Internet, there is no centralized control, and nobody can turn it off. Its evolution depends on rough consensus about technical proposals, and on running code. Engineering feed-back from real implementations is more important than any architectural principles. RFC 1958; B. Carpenter; Architectural Principles of the Internet; June, 1996. |
What is the Internet architecture? It is by definition a meta-network, a constantly changing collection of thousands of individual networks intercommunicating with a common protocol.
The Internet’s architecture is described in its name, a short from of the compound word “inter-networking”. This architecture is based in the very specification of the standard TCP/IP protocol, designed to connect any two networks which may be very different in internal hardware, software, and technical design. Once two networks are interconnected, communication with TCP/IP is enabled end-to-end, so that any node on the Internet has the near magical ability to communicate with any other no matter where they are. This openness of design has enabled the Internet architecture to grow to a global scale.
In practice, the Internet technical architecture looks a bit like a multi-dimensional river system, with small tributaries feeding medium-sized streams feeding large rivers. For example, an individual’s access to the Internet is often from home over a modem to a local Internet service provider who connects to a regional network connected to a national network. At the office, a desktop computer might be connected to a local area network with a company connection to a corporate Intranet connected to several national Internet service providers. In general, small local Internet service providers connect to medium-sized regional networks which connect to large national networks, which then connect to very large bandwidthnetworks on the Internet backbone. Most Internet service providers have several redundant network cross-connections to other providers in order to ensure continuous availability.
The companies running the Internet backbone operate very high bandwidth networks relied on by governments, corporations, large organizations, and other internet service providers. Their technical infrastructure often includes global connections through underwater cables and satellite links to enable communication between countries and continents. As always, a larger scale introduces new phenomena: the number of packets flowing through the switches on the backbone is so large that it exhibits the kind of complex non-linear patterns usually found in natural, analog systems like the flow of water or development of the rings of Saturn (RFC 3439, S2.2).
Each communication packet goes up the hierarchy of Internet networks as far as necessary to get to its destination network where local routing takes over to deliver it to the addressee. In the same way, each level in the hierarchy pays the next level for the bandwidth they use, and then the large backbone companies settle up with each other. Bandwidth is priced by large Internet service providers by several methods, such as at a fixed rate for constant availability of a certain number of megabits per second, or by a variety of use methods that amount to a cost per gigabyte. Due to economies of scale and efficiencies in management, bandwidth cost drops dramatically at the higher levels of the architecture.
Resources. The network topology page provides information and resources on the real-time construction of the Internet network, including graphs and statistics. The following references provide additional information about the Internet architecture:
-
RFC 1958; B. Carpenter, et. al.; Architectural Principles of the Internet; Jun 1996
-
RFC 3426; S. Floyd; General Architectural and Policy Considerations; Nov 2002
-
RFC 3439; R. Bush, D. Meyer; Some Internet Architectural Guidelines and Philosophy; Dec 2002
- RFC 3819; P. Karn, Ed.; Advice for Internet Subnetwork Designers; July 2004
- RFC 3945; E. Mannie, Ed.; Generalized Multi-Protocol Label Switching (GMPLS) Architecture; October 2004