1. History of TCP/IP
TCP/IP was initially designed to meet the data communication needs of the
U.S. Department of Defence (DOD).
In the late 1960s the Advanced Research Projects Agency (ARPA, now called
DARPA) of the U.S. Department of Defence began a partnership with U.S.
universities and the corporate research community to design open, standard
protocols and build multi-vendor networks.
Together, the participants planned ARPANET, the first packet switching
network. The first experimental four-node version of ARPANET went into
operation in 1969. These four nodes at three different sites were connected
together via 56 kbit/s circuits, using the Network Control Protocol (NCP). The
experiment was a success, and the trial network ultimately evolved into a useful
operational network, the "ARPA Internet".
In 1974, the design for a new set of core protocols, for the ARPANET, was
proposed in a paper by Vinton G. Cerf and Robert E. Kahn. The official name
for the set of protocols was TCP/IP Internet Protocol Suite, commonly referred
to as TCP/IP, which is taken from the names of the network layer protocol
(Internet protocol [IP]) and one of the transport layer protocols (Transmission
Control Protocol [TCP]).
TCP/IP is a set of network standards that specify the details of how computers
communicate, as well as a set of conventions for interconnecting networks and
routing traffic.
The initial specification went through four early versions, culminating in version
4 in 1979.
1
2. History of the Internet
By 1985, the ARPANET was heavily used and congested. In response, the
National Science Foundation (NSF) initiated phase one development of the
NSFNET. ARPANET was officially decommissioned in 1989. The NSFNET
was composed of multiple regional networks and peer networks (such as the
NASA Science Network) connected to a major backbone that constituted the
core of the overall NSFNET
In its earliest form, in 1986, the NSFNET created a three-tiered network
architecture. The architecture connected campuses and research
organisations to regional networks, which in turn connected to a main
backbone linking six nationally funded super-computer centres. The original
links were 56 kbit/s.
The links were upgraded in 1988 to faster T1 (1.544 Mbit/s) links as a result of
the NSFNET 1987 competitive solicitation for a faster network service, awarded
to Merit Network, Inc. and its partners MCI, IBM, and the state of Michigan. The
NSFNET T1 backbone connected a total of 13 sites that included Merit,
BARRNET, MIDnet, Westnet, NorthWestNet, SESQUINET, SURANet, NCAR
(National Centre of Atmospheric Research), and five NSF supercomputer
centres.
In 1991 the NSF decided to move the backbone to a private company and start
charging institutions for connections. In 1991, Merit, IBM, and MCI started a
not-for-profit company named Advanced Networks and Services (ANS). By
1993, ANS had installed a new network that replaced NFSNET. Called
ANSNET, the new backbone operated over T3 (45 Mbit/s) links. ANS owned
this new Wide Area Network (WAN), unlike previous WANs used in the
Internet, which had all been owned by the U.S. government.
In 1993, NSF invited proposals for projects to accommodate and promote the
role of commercial service providers and lay down the structure of a new and
robust Internet model. At the same time, NSF withdrew from the actual
operation of the network and started to focus on research aspects and
initiatives.
The "NSF 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 provide equitable treatment
of the various network service providers with regard to routing
administration.
• Providing a very high-speed Backbone Network Service (vBNS) for
educational and governmental purposes.
• Moving existing "regional" networks, from the NSFNET backbone to other
Network Service Providers (NSPs) which have connections to NAPs.
Partly as a result of the NSF solicitations, today's Internet structure has moved
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, called Network Access Points (NAPs). A NAP
is defined as a high-speed switch to which a number of routers can be
2
connected for the purpose of traffic exchange. This allows Internet traffic from
the customers of one provider to reach the customers of another provider.
Internet Service Providers (ISPs) are companies that provide Internet services,
for example, Web access and Internet mail, to end customers, both individual
users and corporate users. The connection point between a customer and an
ISP is called a point of presence (POP). The physical connection between a
customer and as ISP can be provided by many different physical access
methods, for example dial-up or Frame Relay.
ISP networks exchange information with each other by connecting to NSPs that
are connected to NAPs, or by connecting directly to NAPs.
The NSFNET was physically connected to the following four NAPS between
1993 and 1995: (1) Sprint NAP, Pennsauken, NJ (2) PacBell NAP, San
Francisco, CA (3) Ameritech Advanced Data Services (AADS) NAP, Chicago,
IL (4) MFS Datanet (MAE-East) NAP, Washington, D.C.
Additional NAPs continue to be created around the world as providers keep
finding the need to interconnect.
In 1995 the NSF awarded MCI the contract to build the very high performance
Backbone Network Service (vBNS) to replace ANSNET.
The vBNS was designed for the scientific and research communities. It
originally provided high speed interconnection among NSF supercomputing
centres and connection to NSF-specified Network Access Points. Today (1999)
the vBNS connects two NSF supercomputing centres and research institutions
that are selected under the NSF's high performance connections program.
MCI owns and operates the network, but cannot determine who connects to it.
The NSF awards grants under its high performance connection program. The
vBNS is only available for research projects with high-bandwidth uses and is
not used for general Internet traffic.
The vBNS is a US based network that operates at a speed of 622 megabits per
second (OC12) using MCI's network of advanced switching and fibre optic
transmission technologies.
The vBNS relies on advanced switching and optical fibre transmission
technologies, known as Asynchronous Transfer Mode (ATM) and Synchronous
Optical Network (SONET). The combination of ATM and SONET enables very
high speed, high capacity voice, data, and video signals to be combined and
transmitted "on demand".
The vBNS's speeds are achieved by connecting Internet Protocol (IP) through
an ATM switching matrix, and running this combination on the SONET network.
3
3. Internet Architecture Board (IAB)
The IAB, with responsibility for the Internet architecture, was reorganised in
1989 to include a wider community. The new IAB organisation consisted of: (1)
an elected IAB chairman and IAB members, (2) the Internet Research Task
Force (IRTF), (3) the Internet Engineering Task Force (IETF) and (4) the
Internet Assigned Numbers Authority (IANA). The structure is illustrated in the
diagram.
The IETF has engineering working groups, the IRTF has research groups, and
each has a steering group. The IANA, chartered by the IAB, assigned or co-ordinated
all numbers associated with the TCP/IP protocol suite and the
Internet. The IETF, IRTF, and IANA remain active today.
The IAB was reorganised in 1992 when it was brought under the auspices of
the Internet Society (ISOC), an international body. The IAB was renamed the
Internet Architecture Board, but the functions remain reasonably unchanged.
The ISOC is governed by a board of 14 trustees (including five officers) and an
executive director. The officers include the president, two vice presidents, a
secretary, and a treasure. The board of trustees has an advisory council and a
secretariat.
The individual members of the ISOC elect trustees for three-year terms.
Volunteers manage the infrastructure of the ISOC, including members of the
IAB and its task forces. Although several government agencies continue to
support key aspects of the TCP/IP protocol development, the majority of
personal activity (for example, attending meetings writing RFCs) is done on a
voluntary basis.
The IAB is the co-ordinating committee for Internet design, engineering and
management. The IAB has a maximum of 15 members who work on a
4
voluntary basis. Individuals are nominated for membership to the IAB by
Internet community members and selected by the ISOC trustees for two-year,
renewable terms. The IAB creates task forces, committees, and working
groups as required within the scope of the IAB's responsibility.
The initial appointments are the following: the editor of the RFC publication
series and the chairs of the IETF and the IRTF.
Members of the IAB appoint the chair of the IAB who then has the authority to
organise and direct task forces as deemed necessary.
The Internet Engineering Steering Group (IESG) members are nominated by
the Internet community and selected by the IAB. All terms are two years
renewable. The chairman and the IESG members organise and manage the
IETF.
There is an overlap of functions and membership between the IETF and the
IRTF, with the major difference being viewpoint and sometimes time frame.
This overlap is deliberate and considered vital for technology transfer. The
following sections briefly describe the IETF, IRTF and IANA.
4. Internet Engineering Task Force (IETF)
The IETF co-ordinates the operation, management and evolution of the Internet
protocols. The IETF does not deal with the operation of any Internet network,
nor does it set any operational policies. Its charter is to specify the protocols
and architecture of the Internet and recommend standards for IAB approval.
The IETF is organised in relation to several technical areas. These areas,
which change periodically, would typically include the 8 areas listed in the
5
diagram. Details on each of these groups can be obtained from the IETF home
page (www.ietf.org)
The IETF chairperson and a technical area director from each area make up
the IESG membership. Each technical area director has a responsibility for a
subset of all IETF working groups. There are many working groups, each with a
narrow focus and the goal of completing a specific task before moving onto a
new task.
The IETF is the major source of proposed protocol standards for final approval
by the IESG. The IETF meets three times annually, and extensive minutes as
well as reports from each of the working groups are issued by the IETF
secretariat.
4.1 Internet Research Task Force (IRTF)
The IRTF is a community of network researchers that make up the eight IRTF
work groups, listed in the diagram. Details on each of these groups can be
obtained from the IRTF home page (www.irtf.org)
The IRTF is concerned with understanding technologies and how they may be
used in the Internet, rather than products or standard protocols. However,
specific experimental protocols may be developed, implemented and tested to
gain the required understanding.
The work of the IRTF is governed by its IRSG. The chairman of the IRTF and
the IRSG appoint a chair for each research group (RG). Each RG typically has
10 to 20 members and covers a broad area of research, which is determined by
the interests of the members and by recommendations from the IAB.
6
4.2 Internet Assigned Number Authority
(IANA)
The Internet employs a central Internet Assigned Numbers Authority (IANA) for
the allocation and assignment of various numeric identifiers needed for the
operation of the Internet. The IANA function is performed by the University of
Southern California's Information Sciences Institute. The IANA is chartered by
the IAB to co-ordinate the assigned values of protocol parameters, including
type codes, protocol numbers, port numbers, Internet addresses, and Ethernet
addresses.
The IANA delegates the responsibility of assigning IP network numbers and
domain names to three Regional Internet Registries (RIRs):
• ARIN (American Registry for Internet Numbers)
• RIPE (Reseaux IP European)
• APNIC (Asia Pacific Network Information Centre)
The registries provide databases and information servers such as WHOIS
registry for domains, networks, AS numbers, and their associated Point Of
Contacts (POCs).
The documents distributed by the Internet registries include network
information, and procedures, including application forms, to request network
numbers and register domain name servers. All of these are available from the
relevant web sites: www.arin.org, www.ripe.org, www.apnic.org.
The RIPE web site contains a list that shows all (ISO 3166 defined) countries
listed in the three RIR areas, (www.ripe.net/info/ncc/rir-areas.html).
For the RIPE area there are also geographical maps which show the RIPE area
countries and which list the Local Internet Registries (LIRs) in each country.
7
4.3 Request for Comments (RFCs)
Documentation of work on the Internet, proposals for new or revised protocols,
and TCP/IP protocol standards all appear in a series of technical reports called
Internet Request for Comments, or RFCs. Preliminary versions of RFCs are
known as Internet drafts. RFCs can be short or long, can cover broad concepts
or details, and can be standards or merely proposals for new protocols. The
RFC editor is a member of the IAB.
The RFC series is numbered sequentially in the chronological order RFCs are
written. Each new or revised RFC is assigned a new number, so readers must
be careful to obtain the highest numbered version of a document.
Copies of RFCs are available from many sources including the IETF web page
(www.ietf.org/rfc.html).
A unique standard (STD) number is assigned to each protocol reaching the
maturity level of standard. The STD number identifies one or more RFCs that
provide a specification for the protocol. Although the RFC identified by the STD
number may change, the STD number is constant.
When a new RFC replaces an existing RFC, the existing RFC becomes
obsolete. The replaced RFC number (or numbers) are listed under the title of
“obsoletes” on the front page of the new RFC.
Standards Track
Each RFC providing a specification of a protocol is assigned a "maturity level"
(state of standardisation) and a "requirement level" (status). The maturity level
of a Standards Track protocol begins with “proposed” standard. There are also
protocols with a maturity level of “experimental”. Experimental protocols may
8