logo资料库

TCP-IP历史(美国国防部).pdf

第1页 / 共95页
第2页 / 共95页
第3页 / 共95页
第4页 / 共95页
第5页 / 共95页
第6页 / 共95页
第7页 / 共95页
第8页 / 共95页
资料共95页,剩余部分请下载后查看
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
分享到:
收藏