Figure 1.1 shows an example TCP/IP network that uses TCP/IP. In this figure, TCP/IP refers to the data transport protocol and the applications that use TCP/IP such as FTP and TELNET.
Networks that use TCP/IP are called TCP/IP internets. Figure 1.1 is an example of a TCP/IP internet. A distinction must be made between TCP/IP internet and the Internet. The Internet is currently the largest network in the world, with thousands of computers. It spans several continents and is predominantly based on TCP/IP.
In 1972, ARPAnet was demonstrated with 50 packet switched nodes (PSNs) and 20 hosts. Like the previous four-node experiment, this too was a success, and it set the stage for large-scale deployment of PSNs and hosts on the ARPAnet.
Author's Note
Novell's documents say that TCP/IP was an experiment conducted by the DoD
in the 1970s. The actual experiments began in 1969. For the purpose of the CNE
exams, you should remember the 1970s date.
Study Note
TCP/IP originated as a result of experiments done by the Department of
Defense (DoD) in the 1970s.
By 1986, the ARPAnet had expanded to encompass all major universities, the military network called MILNET, Research Laboratories such as Cadre and Tartan at Carnegie-Mellon University (CMU), and satellite links to several international sites (see fig.1.5).
Gradually, the ARPAnet itself was replaced by the Internet. The Internet is experiencing rapid commercialization and is no longer the exclusive domain of universities and research organizations. There is currently more network traffic from commercial organizations than any other source on the Internet.
Author's Note
The original backbone of the Internet in the United States was National
Science Foundation Network (NSFNET). Management of the NSFNET was
contacted to Advanced Network Services (ANS). When commercialization
of the Internet began, an ANSNET backbone was formed for carrying the
commercial traffic. The ANSNET backbone was also managed by ANS. Actually, both
NSFNET and ANSNET traffic were carried over the same physical links, but two
virtual backbones were run over it.
Currently, the Internet community has expanded to include commercial organizations and individual users. The Internet community includes all major universities, research organizations, corporations, individual users and Internet providers.
Internet providers are commercial organizations that sell access to the Internet. Table 1.1 shows a list of some of the Internet providers.
Table 1.1
Internet Access Provider Contact AlterNet UUNET Technologies, Inc. 800-488-6383 703-204-8000 alternet-info@uunet.uu.net Internet Express 719-520-1700 ID: new, password: newuser Local access area codes: 303, 719 klaus@usa.net DELPHI 800-365-4636 Local access areas: Boston, Kansas City walthowe@delphi.com Dial-in-cerf Provided by CERFNET 800-876-2373 619-455-3900 Local access area codes: 213, 310, 415, 510, 619, 714, 818 help@cerf.net NEARnet 617-873-8730 Local access codes: 508, 603, 617 nearnet-join@nic.near.net NETCOM 408-554-UNIX info@netcom.com NorthWestNet 206-562-3000 nic@nwnet.net NYSERnet 315-453-2912 info@nysernet.org PSInet 703-620-6651 all-info@psi.com WELL The Whole Earth `Lectronic Link 415-332-6106 ID: newuser info@well.sf.ca.us World Software Tool & Die 617-739-9753 ID: new 617-739-0202 office@world.std.com
IBM's SNA network has traditionally been hierarchical. The IBM host communicates with communications controllers that off-load the communications processing from the IBM host. The communications controller in turn communicates with the IBM cluster controller that acts like a terminal server to IBM 3278/3279 page-mode display terminals.
Digital's DECnet Phase IV is built around the DECnet suite of protocols, and DECnet Phase V uses both DECnet and OSI protocols. DECnet has a more peer-to-peer orientation at both the physical network and protocol levels when compared with IBM's SNA network.
IBM's SNA networks have evolved to become more peer-to-peer at the API and upper protocol level as can be seen with the introduction of Advanced Peer-to-Peer Communications (APPC) and Advanced Peer-to-Peer Networks (APPN).
Both of these proprietary solutions, IBM's SNA and Digital's DECnet, have become more open--with the availability of TCP/IP (and OSI) support. IBM, VAX or Alpha-based hosts can be accessed using TCP/IP protocols and services.
Both IBM and DEC have intensified their efforts in the TCP/IP market. For example, IBM now off-loads TCP/IP processing from the IBM mainframes to the IBM 3172 Interconnect Controller or to a RISC System 6000 running TCP/IP. The IBM 3172 Interconnect Controller acts as a front-end processor and removes the host out of processing TCP/IP communications. The 3172 is an Intel 80486 micro channel platform running TCP/IP on OS/2. This off-load technology is primarily aimed at MVS, VM mainframes that are currently at peak capacity.
Using a common protocol such as TCP/IP promotes a more competitive market where users can pick the best TCP/IP protocol stack from a wide range of choices.
Figure 1.7 shows an example of a multivendor network based around TCP/IP. This figure shows a HP-9000 class machine running HP-UX that comes with TCP/IP software. It also shows SUN workstations running SunOS or Solaris, VAX/VMS running TCP/IP for VMS or Wollongong's TCP/IP for VMS, Novell NetWare 3.x/4.x running TCP/IP, UnixWare TCP/IP, IBM VM host running TCP/IP for VM or Fibronics TCP/IP, IBM PC with NCSA TCP/IP software, and MacTCP. This is only a partial list. TCP/IP implementations are available on every major computing platform ranging from mainframes and minicomputers to workstations and microcomputers.
Study Note
TCP/IP is implemented on most types of computers ranging from mainframes to
minicomputers to microcomputers.
HP-UX, SunOS/Solaris and UnixWare are examples of TCP/IP implementations
on a UNIX platform. TCP/IP is implemented as a standard part of BSD UNIX and
UNIX System V.
Originally, TCP/IP was implemented in the kernel of the 4.2 BSD UNIX operating system. 4.2 BSD UNIX was a very influential version of UNIX, and is one of the reasons for TCP/IP's widespread popularity. Most universities and many research organizations use BSD UNIX. Today, most host machines on the Internet run a direct descendant of BSD UNIX. In addition, many commercial versions of UNIX, such as SUN's SunOS and Digital's Ultrix, were derived from 4.2 BSD UNIX. UNIX System V TCP/IP implementation has also been heavily influenced by BSD UNIX, as has been Novell's TCP/IP implementation on DOS (LANWorkplace products) and NetWare 3.x/4.x.
Study Note
TCP/IP is implemented as a standard part of UNIX operating systems such as
4.2 BSD (and higher) UNIX and UNIX System V.
Figure 1.9 shows that a rapid increase in the number of vendors providing TCP/IP based products around 1985. There are several reasons that can be attributed to this growth. One of the major reasons is that the microcomputer market grew dramatically around this time, and several vendors began developing TCP/IP protocols and applications for microcomputers. Another reason is that vendors grew tired of waiting for OSI protocols to mature while there was already a mature TCP/IP protocol suite and services that had a proven track record for a number of years.
The three factors driving growth in TCP/IP today are the following:
Author's Note
Figure 1.10 shows why TCP/IP's RIP and Novell's IPX RIP have more in common
besides the name. They both have a common ancestor--XNS RIP. Another protocol
derived from XNS RIP is AppleTalk's Routing Table Maintenance Protocol
(RTMP).
In 1983, the ARPAnet, which had been using Network Control
Protocol (NCP)--not to be confused with NetWare Core Protocol, began converting
to TCP/IP.
In 1987, Novell introduced TCP/IP in NetWare 3.x. Novell had acquired Excelan of San Jose and used the technology gained as a result of this acquisition to introduce TCP/IP protocols and applications in several of its products.
In the late 1980s, multivendor support for TCP/IP accelerated. In the early 1990s, SNMP became a de facto standard for management of TCP/IP networks. SNMP is not restricted to using
TCP/IP protocols. For example, SNMP can also run on Novell's Internetwork Packet Exchange protocol (IPX) and OSI's Connectionless Network Protocol (CLNP).
In 1992, a joint USL (UNIX Systems Laboratories) and Novell venture called UNIVEL was formed to integrate UNIX and NetWare in a product called UnixWare. This was followed by the acquisition of USL by Novell and its renaming to the UNIX Systems Group (USG).
In this figure, user A is at a workstation, using a TELNET session to log on remotely to a VMS host. The TELNET application enables the user to access another host remotely. For this to take place, there are two components of software that must be running. You need a TELNET client application running at the user's workstation. The TELNET client application takes the user's keystrokes and sends them (either a character at a time or a line at a time) to the remote host. At the remote host, you need a TELNET server component. This TELNET server component takes the user's typed-in characters and submits it to the operating system as if they were typed in by a locally attached terminal. The TELNET server is responsible for taking the host's response and sending it to the TELNET client running at the user's workstation.
User B, in figure 1.11, is using an FTP session to transfer files between his or her workstation and an IBM host. The FTP application allows a user to access another host's file system interactively. Once an FTP session is established, the user can type special FTP commands that will allow the user to browse directories and files on the remote system. The user can issue commands for uploading or downloading files between the workstation and the FTP host. For an FTP session to work, you need two software components. You need an FTP client application running at the user's workstation, which enables you to send interactive commands to the FTP host. At the remote host you need an FTP server component, which processes the user's FTP commands and interacts with the file system of the host that it runs on.
User C, in figure 1.11, is using the Simple Mail Transfer Protocol (SMTP) to send e-mail to other users on the network. The mail software running at the user's workstation takes the e-mail message composed by the user and deposits it into an outgoing mail area. A program that runs in the background takes the e-mail and sends it to the destination host. The mail is then deposited in the mail box on the host. This mail box is that of the user who is the recipient of the e-mail.
User D, in figure 1.11, is using SNMP to access information on devices on the network. The user is running SNMP manager software that sends requests in a special SNMP message format to a device, querying the device for management information. Management information is information that the SNMP manager finds useful for monitoring and controlling the device. An SNMP agent running on the device responds to the SNMP requests. The replies sent by the SNMP agent are used by the SNMP Manager to manage the device.
User E, in figure 1.11, is using Network File System (NFS) to access file services on a remote host directly. This means that the file system at the remote host appears to the workstation as an extension of the file system on that workstation. This enables the user to access the remote file system using the commands of the local workstation operating system. For NFS to work, you need two software components. The NFS client application running at the user's workstation connects with the file system on the NFS host. An NFS server component running on the remote host interacts with the file system of the host that it runs on and allows its file system to be treated as a local file system at the user's workstation.
The Domain Name System (DNS) server shown in figure 1.11 is used for TCP/IP applications to refer to host names by their symbolic names rather than by their network address. When a TCP/IP application such as TELNET wishes to log onto the VMS host, it can use a symbolic name for the VMS host. The DNS server will resolve this symbolic name to the network address that will be used by the TELNET application to contact the VMS host.
Table 1.2 summarizes the TCP/IP applications discussed in this section.
Table 1.2
TCP/IP Applications Summary
Application service Description TELNET Enables a user to log in remotely across a TCP/IP network to any host supporting this protocol. FTP Enables users to transfer files between computers on a TCP/IP network. SMTP Enables users to send electronic mail to other users on the TCP/IP network. SNMP Allows remote management of devices such as bridges, routers, gateways on the network. DNS Acts as an electronic directory and clearing house for names of network resources.
Even though the Internet continues to undergo commercialization, it provides an incomparable test network for developing new protocols and application services. For example, a great deal of experimentation and research on OSI application services is conducted on the Internet.
Table 1.3
Networks on the Internet
Network Description NSFNET National Science Foundation Network. The backbone network in the U.S. CSNET Computer Science Network. Affordable internet services using X.25 for small schools and organizations. Cypress Net Provides low-cost and low-volume Internet access centered around Purdue University. MILNET U.S. Department of Defense (DoD) network. Originally part of ARPAnet. BITNET Because It's Time Network. Uses IBM mainframes and low-cost 9600 bps links. CREN Consortium for Research and Education Network. Successor to CSNET and BITNET. EARN European Academic Research Network. Uses BITNET technology. A network for Europe, the Middle East, and Africa. JANET Joint Academic Network. A network for universities and Research Institutions in the U.K. CDNet Network services to Canadian research, education and advanced development community. NRCnet Canadian National Research Council network. Modeled after NSFNET. ACSnet Australian Computer Science Network. Used by universities, research institutions, and industry. Kogaku-bu Established at the University of Tokyo. Uses proprietary 100 Mbps fiber backbone network.Author's Note
On the NFSNET, packet switch nodes called Nodal switching subsystems (NSS) are used. Each NSS consists of nine IBM RT/PCs running AIX connected to token ring networks for redundancy. Within each NSS, a Routing Control Processor (NCP) mediates access between more than 1 NSS. Backbone routing software within each NSS uses IS-IS. Mid-level networks are connected using EGP.
CSNET, established in January 1981, consisted of the Computer Science departments of schools and universities. Membership is now more general and includes industrial, academic, government, and non-profit institutions engaged in computer-related research or advanced development in science and Engineering. This network is mostly confined to US and Canada but has links to Australia, Finland, France, Germany, Israel, Japan, Korea, New Zealand, Sweden, Switzerland, China, and the UK.
CSNET CIC (Computer and Information Center) is administered by BBN.
BITNET is a cooperative network serving more than 2,300 hosts (IBM) at several hundred sites in 32 countries. The underlying protocol is NJE, with some sites running NJE on top of TCP/IP. In Europe, there are plans to migrate to ISO protocols. Major constituents of BITNET are in US, Mexico, Japan, Singapore, Taiwan, Korea (Asian parts are known as Asianet). BITNET is known as NetNorth in Canada and EARN in Europe.
In October 1988, the boards of CSNET and BITNET voted to merge the two into a single net called the CREN. The merger was completed in 1989.
EARN was formed in 1983. EARN's charter states that it is a network for Europe, the Middle East, and Africa. Recent voting has ratified Morocco, Tunisia, Egypt, and India as members. EARN is registered in France and its board of directors consist of members from each member country. EARN uses the technology used in BITNET and is part of BITNET. Many EARN hosts are IBM VM and DEC VAX VMS machines. Gateways exist to other networks, such as JANET in the UK and HEANET in Ireland.
JANET was established to provide consolidated links among universities and research institutions in the UK. JANET is funded by the Computer Board for Universities and Research Councils (CB) and is limited to the following:
CDNET is administered by the CDNet Headquarters at the University of British Columbia (UBC) and is independent of Canadian Department of Defense. Most machines are DEC VAX or Sun file servers (about 60 percent UNIX and 40 percent VMS). Most wide-area links are X.25 at 2400 bps (ranging from 1200 bps to 9600 bps) provided through DATAPAC. There are leased-line connections to the NFSNET backbone. Gateways exist to CSNET and BITNET.
NRCNET is modeled after NFSNET to provide faster services than currently offered by NetNorth and CDNET. It uses the three-level model of backbone, mid-level, and campus LANs.
ACSNET is based on the Sydney UNIX Network (SUN) software developed at the University of Sydney. The network was started in 1979. It provides mail and file transfer traffic among researchers, academia, and industry. Wide-area links include leased lines, dial-up lines, and X.25.
Kogaku-bu, established in 1987, uses TCP/IP over a Toshiba 100 Mbps fiber backbone network that connects Ethernet LANs. Protocols are not FDDI because the technology predates FDDI. The data link protocol on the ring is called TOTOLAN/RING. Applications include TELNET, and FTP. Mainframe remote login access using Japanese character sets have been managed by putting TELNET in the transparent mode and using the character conversion capabilities of the IBM TSS TIOP2 program on the mainframe.
Study Note
For the purposes of the CNE exams, you should have a general knowledge
(at least awareness of names) of the NSFNET, CSNET, MILNET, ARPANET, and
Cypress Net.
The Internet Activities Board (IAB) provides focus, direction, and coordination of TCP/IP related protocols. This body guides the evolution of the Internet. It is comprised of the Internet Research Task Force (IRTF) and the Internet Engineering Task Force (IETF). The Federal Networking Council (FNC) is the U.S government regulatory body that serves as an advisory body. As the Internet gets even more commercialized, the influence of the FNC will be even further reduced.
The Internet Engineering Task Force is managed by the Internet Engineering Steering Group (IESG). It is divided into areas, with areas divided into working groups. The IETF focuses on short to medium term engineering problems.
The Internet Research Task Force is managed by the Internet Research Steering Group (IRSG). It focuses on long-term research problems.
The IETF has the following broad technical areas. The actual areas may change over time depending on the needs of the Internet.
A more recent development is the formation of the Internet Society. The Internet Society promotes the use of the Internet for collaboration on research topics on the Internet. It provides a forum for industry, educators, government and users. It is involved with the recommendation of procedures and technical standards for the global Internet and private internets.
Membership in the Internet Society is open to everyone for an annual membership fee. As this book goes to press, the regular membership is $70 per year. It is $25 per year for students. You can contact the Internet Society at the following address:
Internet Society Suite 100 1895 Preston White Drive Reston, VA 22091-5434 U.S.A. E-mail: isoc@isoc.org Telephone: 703-648-9888 Fax: 703-620-0913
Not all RFCs are Internet Protocol Standards, even though all Internet Protocol Standards have an RFC number. The list of official Internet Protocol Standards is published regularly. This list is also an RFC. When a new RFC is published on the same topic, it contains a statement about which RFC it replaces. Appendix A contains a list of RFCs, at the time this book goes to press, sorted by RFC number, with the most recent RFC first. Thus RFC 1600 is published as:
1600 Postel, J., ed. INTERNET OFFICIAL PROTOCOL STANDARDS. 1994 March; 36 p. (Format: TXT=80958 bytes) (Obsoletes RFC 1540)Notice that this RFC listing states that RFC 1600 is the Internet Official Protocol Standards, and that it obsoletes RFC 1540 on the same topic.
Anyone can submit an RFC, as long as it follows guidelines established by RFC 1543. This RFC is listed in Appendix A as:
1543 Postel, J. Instructions to RFC Authors. 1993 October; 16 p. (Format: TXT=31384 bytes) (Obsoletes RFC 1111)When you write an RFC, you must submit it to the editor-in-chief, whose e-mail address is
RFC-Editor@ISI.EDUEarlier documents and standards on the ARPAnet were written as Internet Engineering Notes (IENs). These have been replaced by RFCs.
Author's Note
Some of the RFCs are actually poems. Some examples are RFCs 968 and RFC
1121. Here are some interesting poems by two of the founders of the Internet:
Vincent Cerf, the father of the Internet, and Leonard Kleinrock, who did major
analytical work on the Internet.
Twas the Night Before Start-upTwas the night before start-up and all through the net,
Vint Cerf, 1985 (RFC 968)
not a packet was moving; no bit nor octet.
The engineers rattled their cards in despair,
hoping a bad chip would blow with a flare.
The salesmen were nestled all snug in their beds,
while visions of data nets danced in their heads.
And I with my datascope tracings and dumps
prepared for some pretty bad bruises and lumps.
When out in the hall there arose such a clatter,
I sprang from my desk to see what was the matter.
There stood at the threshold with PC in tow,
An ARPANET hacker, all ready to go.
I could see from the creases that covered his brow,
he'd conquer the crisis confronting him now.
More rapid than eagles, he checked each alarm
and scrutinized each for its potential harm.
On LAPB, on OSI, X.25!
TCP, SNA, V.35!
His eyes were afire with the strength of his gaze;
no bug could hide long; not for hours or days.
A wink of his eye and a twitch of his head,
soon gave me to know I had little to dread.
He spoke not a word, but went straight to his work,
fixing a net that had gone plumb berserk;
And laying a finger on one suspect line,
he entered a patch and the net came up fine!
The packets flowed neatly and protocols matched;
the hosts interfaced and shift-registers latched.
He tested the system from Gateway to PAD;
not one bit was dropped; no checksum was bad.
At last he was finished and wearily sighed
and turned to explain why the system had died.
I twisted my fingers and counted to ten;
an off-by-one index had done it again...
THE BIG BANG!It was back in '67 that the clan agreed to meet.
(or the birth of the ARPANET)
Leonard Kleinrock (RFC 1121)
The gangsters and the planners were a breed damned hard to beat.
The goal we set was honest and the need was clear to all:
Connect those big old mainframes and the minis, lest they fall.
The spec was set quite rigid: it must work without a hitch.
It should stand a single failure with an unattended switch.
Files at hefty throughput `cross the ARPANET must zip.
Send the interactive traffic on a quarter second trip.
The spec went out to bidders and 'twas BBN that won.
They worked on soft and hardware and they all got paid for fun.
We decided that the first node would be we who are your hosts
And so today you're gathered here while UCLA boasts.
I suspect you might be asking "What means FIRST node on the net?"
Well frankly, it meant trouble, `specially since no specs were set.
For you see the interface between the nascent IMP and HOST
Was a confidential secret from us folks on the West coast.
BBN had promised that the IMP was running late.
We welcomed any slippage in the deadly scheduled date.
But one day after Labor Day, it was plopped down at our gate!
Those dirty rotten scoundrels sent the damned thing out air freight!
As I recall that Tuesday, it makes me want to cry.
Everybody's brother came to blame the other guy!
Folks were there from ARPA, GTE and Honeywell.
UCLA and ATT and all were scared as hell.
We cautiously connected and the bits began to flow.
The pieces really functioned--just why I still don't know.
Messages were moving pretty well by Wednesday morn.
All the rest is history--packet switching had been born!
ROSENCRANTZ AND ETHERNET Vint Cerf, 1989 (RFC 1121)All the world's a net! And all the data in it merely packets
come to store-and-forward in the queues a while and then are
heard no more. 'Tis a network waiting to be switched!
To switch or not to switch? That is the question. Whether
'tis wiser in the net to suffer the store and forward of
stochastic networks or to raise up circuits against a sea
of packets and, by dedication, serve them.
To net, to switch. To switch, perchance to slip!
Aye, there's the rub. For in that choice of switch,
what loops may lurk, when we have shuffled through
this Banyan net? Puzzles the will, initiates symposia,
stirs endless debate and gives rise to uncontrolled
flights of poetry beyond recompense!
SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 415-859-3695 NIC@SRI-NIC.ARPTable 1.4 shows some of the RFC sites that are available. The Primary Repositories will have the RFC available when it is first announced, as will many Secondary repositories. Some Secondary Repositories may take a few days to make available the most recent RFCs.
Table 1.4
Host Name Primary/Secondary DS.INTERNIC.NET Primary NIS.NSF.NET Primary NISC.JVNC.NET Primary VENERA.ISI.EDU Primary WUARCHIVE.WUSTL.EDU Primary SRC.DOC.IC.AC.UK Primary FTP.CONCERT.NET Primary FTP.SESQUI.NET Primary SUNIC.SUNET.SE Secondary CHALMERS.SE Secondary WALHALLA.INFORMATIK.UNI- DORTMUND.DE Secondary MCSUN.EU.NET Secondary FUNET.FI Secondary UGLE.UNIT.NO Secondary FTP.DENET.DK Secondary MUNNARI.OZ.AU Secondary NIC.CERF.NET Secondary FTP.UU.NET Secondary
This chapter also discussed the relationship between the Internet and the older ARPAnet, and the professional bodies that influence research and development of the Internet protocols.