`
`~~
`
`,.~..,~.m.m-.,~.~.,,.~,n;.. ,
`
`R~.~-'..—~~ — - -
`
`Bright House Networks
`- Ex. 1030, Page 1
`
`
`
`Library of Congress Cataloging-1n-Publicat1on Data
`
`Comer, Douglas E.
`Internetworking w1th TCP/IP I Douglas E. Co~er. --2nd ed.
`em.
`p.
`> and index.
`Includes b1b11ograph1cal references <v. 1, p.
`Contents: vol. 1. Pr1nc1ples, protocols, and arch1tecture.
`ISBN 0-13-468505-9 <v. 1>
`f. Co•puter networks. 2. Computer network protocols . 3. Data
`transm1ss1on systems.
`I. Title.
`TK5105.5.C59 1991
`004.6--dc20
`
`90-7829
`CIP
`
`Editorial/production supervision: Joe Scordato
`Cover design: Karen Stephens
`Cover illustration: Jim Kinstrey
`Manufacturing buyers: Linda Behrens and Patrice Fraccio
`
`The author and publisher of this book have used their best efforts in preparing this book.
`These efforts include the development, research, and testing of the theories and programs to
`determine their effectiveness. The author and publisher make no warranty of any kind,
`expressed or implied, with regard to these programs or the documentation contained in this
`book. The author and publisher shall not be liable in any event for incidental or consequential
`damages in connection with, or arising out of, the furnishing, performance, or use of these
`programs.
`
`A Paramount Communications Company
`Englewood Cliffs, New Jersey 07632
`
`• © 1991 by Prentice-Hall, Inc .
`
`All rights reserved. No part of this book
`may be reproduced, in any form or by any
`means without permission in writing from
`the publisher.
`
`Printed in the United States of America
`
`10 9 8
`
`ISBN 0-13-468505-9
`
`UNIX is a registered trademark of AT&T Bell
`Laboratories. proNET-10 is a trademark of
`Protean Corporation. VAX, Microvax, and
`LSI II are trademarks of Digital Equipment
`Corporation. Network Systems and HYPER(cid:173)
`channels are registered trademarks of Network
`Systems Corporation.
`
`Prentice-Hall International (UK) Limited, London
`Prentice-Hall of Australia Pty. Limited, Sidney
`Prentice-Hall Canada Inc., Toronto
`Prentice-Hall Hispanoamericana, S. A., Mexico
`Prentice-Hall of India Private Limited, New Delhi
`Prentice-Hall of Japan, Inc., Tokyo
`Simon & Schuster Asia Pte. Ltd., Singapore
`Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
`
`Bright House Networks
`- Ex. 1030, Page 2
`
`
`
`2
`
`Introduction and Overview
`
`Chap. I
`
`anyone can build the software needed to communicate across an internet. More impor(cid:173)
`tant, the entire technology has been designed to foster communication between
`machines with diverse hardware architectures, to use almost any packet switched net(cid:173)
`work hardware, and to accommodate multiple computer operating systems.
`To appreciate internet technology, think of how it affects research. Imagine for a
`minute the effects of interconnecting all the computers used by scientists. Any scientist
`would be able to exchange data resulting from an experiment with any other scientist.
`It would be possible to establish national data centers to collect data from natural
`phenomena and make the data available to all scientists. Computer services and pro(cid:173)
`grams available at one location could be used by scientists at other locations. As a
`result, the speed with which scientific investigations proceed would increase. In short,
`the changes would be dramatic.
`
`1.2 The TCP/I P Internet
`
`Government agencies have realized the importance and potential of internet tech(cid:173)
`nology for many years and have been funding research that will make possible a nation(cid:173)
`al internet. This book discusses principles and ideas underlying the leading internet
`technology, one that has resulted from research funded by the Defense Advanced
`Research Projects Agency (DARPA). The DARPA technology includes 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. Officially named the
`TCP/IP Internet Protocol Suite and commonly referred to as TCPIIP (after the names of
`its two main standards), it can be used to communicate across any set of interconnected
`networks. For example, some corporations use TCP/IP to interconnect all networks
`within their corporation, even though the corporation has no connection to outside net(cid:173)
`works. Other groups use TCP/IP for long haul communication among geographically
`distant sites.
`Although the TCP/IP technology is noteworthy by itself, it is especially interesting
`because its viability has been demonstrated on a large scale. It forms the base technolo(cid:173)
`gy for a large internet that connects most major research institutions, including universi(cid:173)
`ty, corporate, and government labs. The National Science Foundation (NSF), the
`Department of Energy (DOE); the Department of Defense (DOD), the Health and Hu(cid:173)
`man Services Agency, (HHS) and the National Aeronautics and Space Administration
`(NASA) all participate, using TCP/IP to connect many of their research sites with those
`of DARPA. The resulting entity, known as the connected Internet, the DARPA/NSF In(cid:173)
`ternet, the TCPIIP Internet, or just the lnternett, allows researchers at connected institu(cid:173)
`tions to share information with colleagues across the country as easily as they share it
`with researchers in the next room. An outstanding success, the Internet demonstrates
`the viability of the TCP/IP technology and shows how it can accommodate a wide
`variety of underlying network technologies.
`
`tWe will follow the usual convention of capitalizing lnterner when referring specifically to the connected
`internet, and use lower case otherwise; we will also assume the term "internet" used without further qualifica(cid:173)
`tion refers to TCP/IP internets.
`
`Bright House Networks
`- Ex. 1030, Page 3
`
`
`
`Sec. 1.2
`
`The TCP/IP Internet
`
`Most of the material in this book applies to any internet that uses TCP/IP, but
`some chapters refer specifically to the connected Internet. Readers interested only in
`the technology should be careful to watch for the distinction between the Internet archi(cid:173)
`tecture as it exists and general TCP/IP internets as they might exist. It would be a mis(cid:173)
`take, however, to ignore sections of the text that describe the connected Internet com(cid:173)
`pletely - many corporate networks are already more complex than the connected Inter(cid:173)
`net of ten years ago, and many of the problems they face have already been solved in
`the connected Internet.
`
`1.3 Internet Services
`
`One cannot appreciate the technical details underlying TCP/IP without understand(cid:173)
`ing the services it provides. This chapter reviews internet services briefly, highlighting
`the services most users access, and leaving to later chapters the discussion of how com(cid:173)
`puters connect to a TCP/IP internet and how the functionality is implemented.
`Much of our discussion of services will focus on standards called protocols. Proto(cid:173)
`cols, like TCP and IP, give the formulas for passing messages, specify the details of
`message formats, and describe how to handle error conditions. Most important, they al(cid:173)
`low us to discuss communication standards independent of any particular vendor's net(cid:173)
`work hardware.
`In a sense, protocols are to communication what programming
`languages are to computation. A programming language allows one to specify or
`understand a computation without knowing the details of any particular CPU instruction
`set. Similarly, a communication protocol allows one to specify or understand data com(cid:173)
`munication without depending on detailed knowledge of a particular vendor's network
`hardware.
`Hiding the low-level details of communication helps improve productivity in
`several ways. First, because programmers deal with higher-level protocol abstractions,
`they do not need to learn or remember as many details about a given hardware confi(cid:173)
`guration. They can create new programs quickly. Second, because programs built us(cid:173)
`ing higher-level abstractions are not restricted to a particular machine architecture or
`particular network hardware, they do not need to be changed when machines or net(cid:173)
`works are reconfigured. Third, because application programs built using higher-level
`protocols are independent of the underlying hardware, they can provide direct communi(cid:173)
`cation for an arbitrary pair of machines. Programmers do not need to build special ver(cid:173)
`sions of application software to move and translate data between each possible pair of
`machine types.
`We will see that all network services are described by protocols. The next sections
`refer to protocols used to specify application-level services as well as those used to de(cid:173)
`fine network-level services. Later chapters explain each of these protocols in more de(cid:173)
`tail.
`
`Bright House Networks
`- Ex. 1030, Page 4
`
`
`
`4
`
`Introduction and Overview
`
`Chap. 1
`
`1.3.1 Application Level Internet Services
`
`From the user's point of view, a TCP/IP internet appears to be a set of application
`programs that use the network to carry out useful communication tasks. We use the
`term interoperability to refer to the ability of diverse computing systems to cooperate in
`solving computational problems. We say that internet application programs exhibit a
`high degree of interoperability. Most users that access the Internet do so merely by run(cid:173)
`ning application programs without understanding the TCP/IP technology, the structure
`of the underlying internet, or even the path their data travels to its destination; they rely
`on the application programs to handle such details. Only programmers who write such
`application programs view the internet as a network and need to understand the details
`of the technology.
`The most popular and widespread Internet application services include:
`
`• Electronic mail. Electronic mail allows a user to compose memos and send them
`to individuals or groups. Another part of the mail application allows users to read
`memos that they have received. Electronic mail has been so successful that many
`Internet users depend on it for normal business correspondence. Although many
`electronic mail systems exist, it is important to understand that using TCP/IP
`makes mail delivery more reliable. Instead of relying on intermediate machines to
`relay mail messages, the TCP/IP mail delivery system operates by having the
`sender's machine contact the receiver's machine directly. Thus, the sender knows
`that once the message leaves the local machine, it has been successfully received
`at the destination site.
`• File transfer. Although users sometimes transfer files using electronic mail, mail
`is designed primarily for short, text files. The TCP/IP protocols include a file
`transfer application program that allows users to send or receive arbitrarily large
`files of programs or data. For example, using the file transfer program, one can
`copy from one machine to another large data banks containing satellite images,
`programs written in FORTRAN or Pascal, or an English dictionary. The system
`provides a way to check for authorized users, or even to prevent all access. Like
`mail, file transfer across a TCP/IP internet is reliable because the two machines
`involved communicate directly, without relying on intermediate machines to make
`copies of the file along the way.
`• Remote login. Perhaps the most interesting Internet application, remote login al(cid:173)
`lows a user sitting at one computer to connect to a remote machine and establish
`an interactive login session. The remote login makes it appear that the user's ter(cid:173)
`minal or workstation connects directly to the remote machine by sending every
`keystroke from the user's keyboard to the remote machine and displaying every
`character the remote computer prints on the user's terminal screen. When the re(cid:173)
`mote login session terminates, the application returns the user to the local system.
`
`Bright House Networks
`- Ex. 1030, Page 5
`
`
`
`sec. 1.3
`
`Internet Services
`
`We will return to each of these applications in later chapters to examine them in more
`detail. We will see exactly how they use the underlying TCP/IP protocols, and why
`having standards for application protocols has helped ensure that they are widespread.
`
`1.3.2 Network-Level Internet Services
`
`A programmer who writes application programs that use TCP/IP protocols has an
`entirely different view of an internet than a user who merely executes applications like
`electronic mail. At the network level, an internet provides two broad types of service
`that all application programs use. While it is unimportant at this time to understand the
`details of these services, they cannot be omitted from any overview of TCP/IP:
`
`• Connectionless Packet Delivery Service. This service, explained in detail
`throughout the text, forms the basis for all other internet services. Connectionless
`delivery is an abstraction of the service that most packet-switching networks offer.
`It means simply that a TCP/IP internet routes small messages from one machine
`to another based on address information carried in the message. Because the con(cid:173)
`nectionless service routes each packet separately, it does not guarantee reliable,
`in-order delivery. Because it usually maps directly onto the underlying hardware,
`the connectionless service is extremely efficient. More important, having connec(cid:173)
`tionless packet delivery as the basis for all internet services makes the TCP/IP
`protocols adaptable to a wide range of network hardware.
`
`• Reliable Stream Transport Service. Most applications need much more than
`packet delivery because they require the communication software to recover au(cid:173)
`tomatically from transmission errors, lost packets, or failures of intermediate
`switches along the path between sender and receiver. The reliable transport ser(cid:173)
`vice handles such problems. It allows an application on one computer to establish
`a "connection" with an application on another computer, and then to send a large
`volume of data across the connection as if it were a permanent, direct hardware
`connection. Underneath, of course, the communication protocols divide the
`stream of data into small messages and send them, one at a time, waiting for the
`receiver to acknowledge reception.
`
`Many networks provide basic services similar to those outlined above, so one
`might wonder what distinguishes TCP/IP services from others. The primary distin(cid:173)
`guishing features are:
`
`• Network Technology Independence. While TCP/IP is based on conventional pack(cid:173)
`et switching technology, it is independent of any particular vendor's hardware.
`The connected Internet includes a variety of network technologies ranging from
`netw1>rks designed to operate within a single building to those designed to span
`large distances. TCP/IP protocols define the unit of data transmission, called a
`datagram, and specify how to transmit datagrams on a particular network.
`
`Bright House Networks
`- Ex. 1030, Page 6
`
`
`
`6
`
`Introduction and Overview
`
`Chap. I
`
`• Universal Interconnection. A TCP/IP internet allows any pair of computers to
`which it attaches to communicate. Each computer is assigned an address that is
`universally recognized throughout the internet. Every datagram carries the ad(cid:173)
`dresses of its source and destination. Intermediate switching computers use the
`destination address to make routing decisions.
`• End-to-End Acknowledgements. The TCP/IP internet protocols provide ack(cid:173)
`nowledgements between the source and ultimate destination instead of between
`successive machines along the path, even when the two machines do not connect
`to a common physical network.
`• Application Protocol Standards. In addition to the basic transport-level services
`(like reliable stream connections), the TCP/IP protocols include standards for
`many common applications including electronic mail, file transfer, and remote lo(cid:173)
`gin. Thus, when designing application programs that use TCP/IP, programmers
`often find that existing software provides the communication services they need.
`
`Later chapters will discuss the details of the services provided to the programmer as
`well as many of the application protocol standards.
`
`1.4 History And Scope Of The Internet
`
`Part of what makes the TCP/IP technology so exciting is its almost universal adop(cid:173)
`tion as well as the size and growth rate of the connected Internet. DARPA began work(cid:173)
`ing toward an internet technology in the mid 1970s, with the architecture and protocols
`taking their current form around 1977-79. At that time, DARPA was known as the pri(cid:173)
`mary funding agency for packet-switched network research and had pioneered many
`ideas in packet-switching with its well-known ARPANET. The ARPANET used con(cid:173)
`ventional point-to-point leased line interconnection, but DARPA had also funded ex(cid:173)
`ploration of packet-switching over radio networks 'and satellite communication channels.
`Indeed, the growing diversity of network hardware technologies helped force DARPA
`to study network interconnection, and pushed internetworking forward.
`The availability of research funding from DARPA caught the attention and imagi(cid:173)
`nation of several research groups, especially those researchers who had previous experi(cid:173)
`ence using packet switching on the ARPANET. DARPA scheduled informal meetings
`of researchers to share ideas and discuss results of experiments. By 1979, so many
`researchers were involved in the TCP/IP effort that DARPA formed an informal com(cid:173)
`mittee to coordinate and guide the design of the protocols and architecture of the evolv(cid:173)
`ing connected Internet. Called the Internet Control and Configuration Board (ICCB),
`the group met regularly until 1983, when it was reorganized.
`The connected Internet began around 1980 when DARPA started converting
`machines attached to its research networks to the new TCP/IP protocols. The AR(cid:173)
`PANET, already in place, quickly became the backbone of the new Internet and was
`used for many of the early experiments with TCP/IP. The transition to Internet technol(cid:173)
`ogy became complete in January 1983 when the Office of the Secretary of Defense
`
`Bright House Networks
`- Ex. 1030, Page 7
`
`
`
`Sec. 1.4
`
`History And Scope Of The Internet
`
`7
`
`mandated that all computers connected to long-haul networks use TCP/IP. At the same
`time, the Defense Communication Agency (DCA) split the ARPANET into two separate
`networks, one for further research and one for military communication. The research
`part retained the name ARPANET; the military part, which was somewhat larger, be(cid:173)
`came known as the MILNET.
`To encourage university researchers to adopt and use the new protocols, DARPA
`made an implementation available at low cost. At that time, most university computer
`science departments were running a version of the UNIX operating system available in
`the University of California's Berkeley Software Distribution, commonly called Berke(cid:173)
`ley UNIX or BSD UNIX. By funding Bolt Beranek and Newman, Inc. (BBN) to imple(cid:173)
`ment its TCP/IP protocols for use with UNIX, and funding Berkeley to integrate the
`protocols with its software distribution, DARPA was able to reach over 90% of the
`university computer science departments. The new protocol software came at a particu(cid:173)
`larly significant time because many departments were just acquiring second or third
`computers and connecting them together with local area networks. The departments
`needed communication protocols and no others were generally available.
`The Berkeley software distribution became popular because it offered more than
`basic TCP/IP protocols. In addition to standard TCP/IP application programs, Berkeley
`offere a set of utilities for network services that resembled the UNIX services used on
`a single
`achine. The chief advantage of the Berkeley utilities lay in their similarity to
`standard
`IX. For example, an experienced UNIX user can quickly learn how to use
`Berkeley's re ote file copy utility (rep) because it behaves exactly like the UNIX file
`copy utility ex ~pt that it allows users to copy files to or from remote machines.
`Besides a s~t of utility programs, Berkeley UNIX provides a new operating system
`abstraction known as a socket that allows application programs to access communica(cid:173)
`tion protocols. A generalization of the UNIX mechanism for 1/0, the socket has options
`for several types of network protocols in addition to TCP/IP. Its design has been debat(cid:173)
`ed since its introduction, and many operating systems researchers have proposed alter(cid:173)
`natives.
`Independent of its overall merits, however, the introduction of the socket
`abstraction was important because it allowed programmers to use TCP/IP protocols with
`little effort. Thus, it encouraged researchers to experiment with TCP/IP.
`The success of the TCP/IP technology and the Internet among computer science
`researchers led other groups to adopt it. Realizing that network communication would
`soon be a crucial part of scientific research, the National Science Foundation took an
`active role in expanding the TCP/IP Internet to reach as many scientists as possible.
`Starting in 1985, it began a program to establish access networks centered around its six
`supercomputer centers. In 1986 it expanded networking efforts by funding a new long
`haul backbone network, called the NSFNETt, that eventually reached all its supercom(cid:173)
`puter centers and tied them to the ARPANET. Finally, in 1986 NSF provided seed mo(cid:173)
`ney for many regional networks, each of which now connects major scientific research
`institutions in a given area. All the NSF-funded networks use TCP/IP protocols, and all
`are part of the connected Internet.
`
`tThe term NSFNET is sometimes used loosely to mean all the NSF-funded networking activities, but we
`will use it to refer to the backbone. The next chapter gives more details about the technology.
`
`Bright House Networks
`- Ex. 1030, Page 8
`
`
`
`8
`
`Introduction and OveJView
`
`Chap. I
`
`Within seven years of its inception, the Internet had grown to span hundreds of in(cid:173)
`dividual networks located throughout the United States and Europe. It connected nearly
`20,000 computers at universities, government, and corporate research laboratories. Both
`the size and the use of the Internet continued to grow much faster than anticipated. By
`late 1987 it was estimated that the growth had reached 15% per month and remained
`high for the following two years. By 1990, the connected Internet included over 3,000
`active networks and over 200,000 computers.
`Adoption of TCP/IP protocols and growth of the Internet has not been limited to
`government-funded projects. Major computer corporations are all connected to the In(cid:173)
`ternet as well as many other large corporations including: oil companies, the auto indus(cid:173)
`try, electronics firms, and telephone companies. In addition, many companies use the
`TCP/IP protocols on their internal corporate internets even though they choose not to be
`part of the connected Internet.
`Rapid expansion introduced problems of scale unanticipated in the original design
`and motivated researchers to find techniques for managing large, distributed resources.
`In the original design, for example, the names and addresses of all computers attached
`to the Internet were kept in a single file that was edited by hand and then distributed to
`every site on the Internet. By the mid 1980s, it became apparent that a central database
`would not suffice. First, requests to update the file would soon exceed the capacity of
`people to process them. Second, even if a correct central file existed, network capacity
`was insufficient to allow either frequent distribution to every site or on-line access by
`every site.
`New protocols were developed and a naming system was put in place across the
`connected Internet that allows any user to resolve the name of a remote machine au(cid:173)
`tomatically. Known as the Domain Name System, the mechanism relies on machines
`called name servers to answer queries about names. No single machine contains the en(cid:173)
`tire domain name database. Instead, data is distributed among a set of machines that
`use TCP/IP protocols to communicate among themselves when answering a query.
`
`1.5 The Original Internet Activities Board
`
`Because the TCP!IP internet protocol suite did not arise from a specific vendor or
`from a recognized professional society, it is natural to ask, ''who sets the technical
`direction and decides when protocols become standard?" The answer is a group known
`as the Internet Activities Board (JAB). The lAB provides the focus and coordination for
`much of the research and development underlying the TCP!IP protocols and guides the
`evolution of the connected Internet. It decides which protocols are a required part of
`the TCP!IP suite and sets official policies.
`Formed in 1983 when DARPA reorganized the Internet Control and Configuration
`Board, the lAB inherited much of its charter from the earlier group. Its initial goals
`were to encourage exchange among the principals involved in research related to
`TCP!IP and the Internet and to keep researchers focused on common objectives.
`Through the first six years, the lAB evolved from a DARPA-specific research group
`
`Bright House Networks
`- Ex. 1030, Page 9
`
`
`
`Sec. 1.5
`
`The Original Internet Activities Board
`
`9
`
`into an autonomous organization. During these years, each member of the lAB chaired
`an Internet Task Force charged with investigating a problem or set of issues deemed to
`be important. The lAB consisted of approximately ten task forces, with charters rang(cid:173)
`ing from one that investigated how the traffic load from various applications affects the
`Internet to one that handled short term Internet engineering problems. The lAB met
`several times each year to hear status reports from each task force, review and revise
`technical directions, discuss policies, and exchange information with representatives
`from agencies like DARPA and NSF who funded Internet operations and research.
`The chairman of the lAB had the title Internet Architect and was responsible for
`suggesting technical directions and coordinating the activities of the various task forces.
`The lAB chairman established new task forces on the advice of the lAB and also
`represented the lAB to others.
`Newcomers to TCP/IP are sometimes surprised to learn that the lAB did not
`manage a large budget; although it set direction, it did not fund most of the research and
`engineering it envisioned. Instead, volunteers performed much of the work. Members
`of the lAB were each responsible for recruiting volunteers to serve on their task forces,
`for calling and running task force meetings, and for reporting progress to the lAB . Usu(cid:173)
`ally, volunteers came from the research community or from commercial organizations
`that produced or used TCP/IP. Active researchers participated in Internet task force ac(cid:173)
`tivities for two reasons. On one hand, serving on a task force provided opportunities to
`learn about new research problems. On the other hand, because new ideas and problem
`solutions designed and tested by task forces often became part of the TCP/IP Internet
`technology, members realized that their work had a direct, positive influence on the
`field.
`
`1.6 The New lAB Organization
`
`By the summer of 1989, both the TCP/IP technology and the connected Internet
`had grown beyond the initial research project into production facilities on which
`thousands of people depended for daily business. It was no longer possible to introduce
`new ideas by changing a few installations overnight. To a large extent, the literally
`hundreds of commercial companies that offer TCP/IP products determined whether pro(cid:173)
`ducts would intemperate by deciding when to incorporate changes in their software.
`Researchers who drafted specifications and tested new ideas in laboratories could no
`longer expect instant acceptance and use of their ideas. It was ironic that the research(cid:173)
`ers who designed and watched TCP/IP develop found themselves overcome by the com(cid:173)
`mercial success of their brainchild. In short, TCP/IP became a successful , production
`technology and the market place began to dominate its evolution.
`To reflect the political and commercial realities of both TCP/IP and the connected
`Internet, the lAB was reorganized in the summer of 1989. The chairmanship changed.
`Researchers were moved from the lAB itself to a subsidiary group and a new lAB
`board was constituted to include representatives from the wider community.
`
`Bright House Networks
`- Ex. 1030, Page 10
`
`
`
`The new JAB organization and names for subparts can best be explained by the di(cid:173)
`agram in Figure 1.1.
`
`lnlroduction aJI(l Ovei'\'Jew
`
`Ol:;tp. l
`
`THE lAB ORGANIZATI.ON
`
`~BOARD---=:>
`
`Figure 1.1 The structure of the lAB after the 1989 reorganization.
`
`As Figure 1.1 shows, in addition to the Board itself, the lAB organization contains
`two major groups: the Internet Research Task Force (/RTF) and the Internet Engineer(cid:173)
`ing Task Force (IETF).
`As its name implies, the IETF concentrates on short-term or medium-term en(cid:173)
`gineering problems. The IETF existed in the old lAB structure, and its success provid(cid:173)
`ed part of the motivation for reorganization. Unlike most lAB task forces, which were
`limited to a few individuals who focused on one specific issue, the IETF had grown to
`include dozens of active members who worked on many problems concurrently. Before
`the reorganization, the IETF had been divided into over 20 working groups, each work(cid:173)
`ing on a specific problem. Working groups held individual meetings to formulate prob(cid:173)
`lem solutions. In addition, the entire IETF met regularly to hear reports from working
`groups and discuss proposed changes or additions to the TCPIIP technology. Usually
`held three times annually, full IETF meetings attracted hundreds of participants and
`spectators. The IETF had become too large for the chairman to manage.
`The reorganized lAB structure retained the IETF, but split it into eight areas, each
`with its own manager. The IETF chairman and the eight IETF area managers comprise
`the Internet Engineering Steering Group (JESG), the individuals responsible for coordi(cid:173)
`nating all efforts of IETF working groups.
`
`Bright House Networks
`- Ex. 1030, Page 11
`
`
`
`Sec. 1.6
`
`The New lAB Organization
`
`II
`
`Because the IETF was widely known throughout the Internet, and because its
`meetings were widely recognized and attended, the name "IETF" was preserved in the
`reorganization and still refers to the entire body, including the chairman, area managers,
`and all members of working groups. Similarly, the name "IETF working group" was
`retained.
`Created during the reorganization, the Internet Research Task Force was given a
`name that denotes it as the research counterpart to the IETF. The IRTF coordinates
`research activities related to TCP/IP protocols or internet architecture in general. Like
`the IETF, the IRTF has a small group called the Internet Research Steering Group or
`IRSG, that sets priorities and coordinates research activities. Unlike the IETF, however,
`the IRTF is currently a much smaller organization. Each member of the IRSG chairs a
`volunteer Internet Research Group analogous to the IETF working groups; the IRTF is
`not divided into areas.
`
`1. 7 Internet Request For Comments
`
`We have said that no vendor owns the TCP/IP technology nor does any profession(cid:173)
`al society or standards body. Thus, the documentation of protocols, standards, and poli(cid:173)
`cies cannot be obtained from a vendor. Instead, DCA funds a group at SRI Internation(cid:173)
`al to maintain and distribute information about TCP/IP and the connected Internet.
`Known as the Network Information Center or simply The NICt, the group handles
`many administrative details for the Internet in addition to distributing documentation.
`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 Re(cid:173)
`quests 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