1386
`
`PROCEEDINGS OF THE IEEE, VOL. 66, NO. 1 1 , NOVEMBER 1978
`
`L. G. Roberts and B. D. Wescller, “Computer network develop-
`ment to achieve resource sharing,”in AFIPS SICCProc., vd. 36,
`p. 543, May 1979.
`M. Shaw, W. A. WUlf and R. L. London, “ A b s ~ c t i o n and veri-
`fication in Alphard: Defining and specirying iteration and gen-
`erators,”CACM, vol. 20, no. 8, p. 553, Aug. 1977.
`R. F. SprouU, “Omnigraph-Simple terminal-independent graphics
`s o f t y e , ” Xerox Palo Alto Rea. Center, CSL-73-4, 1973.
`- , ’Iuterhp display primitives,” Xerox Palo Alto Res.’Center,
`1977, informal note.
`R. F. Sproull and E. L. Thomas, ‘‘A network graphics protocol,”
`Comput. GmpMa, vol. 8, no. 3, Fall 1974.
`C. A. Sunshine, ‘’Survey of protocol definitioa and verification
`techniaues.” in Computer Network Protocob, A. Danthine, Ed.
`
`W. Teitelman, “A display oriented programmer’s sssistant,”Xerox
`Palo Alto Res. Center, CSL-77-3. 1977.
`R H. Thomas, “A resource sharing executive for the ARPAnet,”
`in AmPSProc., NCC, p. 155,1973.
`- , “MSG: he interprocess communication facility for the na-
`tional software works,’’ Bolt Beranek and Newman. Rep. 3483.
`D. C. Walden, “A system for
`interproc- communication
`in a
`resourcesharing computer network,” CACIM, v d . 15. no. 4 , p.
`221, Apr. 1972.
`J. E. White, “A high-level framework for network-based resource
`sharing.”AFIPSPrOc.,NCC,p. 561, 1976.
`P. A. Woodsford. “The design and implementation of the GIN0
`3D graphics software pa~bllge,” Sofrwrrre Pmctice and Expen.-
`
`Issues in Packet-Network Interconnection
`
`VINTON G. CERF AND PETER T. KIRSTEIN
`
`Invited Paper
`
`For single organizations, these data
`switching technology.
`networks are often private ones, built with a technology
`optimized to the specific application. For communication
`between organizations, these networks are being set up by
`In North America, there are many such
`licensed carriers.
`licensed carriers, e.g., TELENET [ 1 1 , DATAPAC [ 2 I , and
`TYMNET [ 31. In the rest of the world, the Post, Telegraph,
`and Telephone Authority
`(PIT) in each country has a near
`monopoly on such services;
`special public data networks
`being set up in
`these countria include TRANSPAC [ 51 in
`France, EURONET [61 for inter-European traffic, DDX [ 71
`in Japan, EDS [81 in the Federal Republic of Germany, and
`the Nordic Public Data Network (NPDN, [9]) in Scandinavia.
`are considered in greater detail
`These public data networks
`in other references (e.g., [ 1014 121 ). Most of the above net-
`works use packet-switching technology; some of them, e.g.,
`EDS and the NPDN, do not do so yet, but may do so in the
`future. In some cases special data networks have been autho-
`rized for specific communities, e.g., SITA [ 131 for the airlines,
`and SWIFT [ 141 for the banks. In addition many private net-
`works have been
`set up among individual organizations, and
`experimental networks of different technologies have @een
`[IS], [ 161, CYCLADES
`developed also, e.&, ARPANET
`[17], ETHERNET [18], SPYDER [19], PRNET [20], [21]
`and SATNET [ 221.
`
`I. INTRODUCTION
`T IS THE THEME of many papers in this issue, that people
`to data resources. In many cases this access
`need access
`must be over large distances, in others it may be local to a
`building or a single site. Data networks have been set up to
`meet many user needs-often, but not necessarily, using packet-
`
`Manuscript received June 20,1978;revised July 21,1978.
`V. G. Cerf is with the Advanced Research Project8 Agency, U.S. De-
`partment of Defense, Arlington, VA 22209.
`P. T. Kirateh h with the Department of Statistic and Computer
`Science, University College, London, Eagland.
`
`U.S. Government work not protected by U.S. copyright
`
`Petitioner Emerson's Exhibit 1011
`Page 1 of 23
`
`

`
`
`
`
`
`
`
`CERF AND KIRSTEIN: ISSUES IN PACKET NETWORK INTERCONNECTION
`
`
`
`
`
`
`
`1387
`
`It is a common user requirement that a single terminal and
`access port should be able to access any computing resource
`if the resource is on another data
`the user may desire-even
`network. From this requirement, there is a clear user need to
`have data networks connected
`together. By the same token,
`the providers of data network services would like to have their
`networks used as intensively as possible; thus they also have a
`strong motivation to connect their data networks
`to others.
`a high
`As a result of these considerations, there has been
`recent interest in the issues arising in the connection of data
`networks [231-[261, [321.
`From the user viewpoint, the requirement for interconnec-
`tion of data networks
`tech-
`is independent of the network
`nology. From the implementation viewpoint,
`there can be
`some considerable complications in connecting networks
`of
`widely different technologies-such as circuit-switched and
`datagram packet-switched networks (these terms are explained
`below). On the whole we will consider only, in this paper, the
`In many
`interconnection of packet-switched data networks.
`cases, however, the arguments will be equally valid for the inter-
`connection of packet-switched to circuit-switched networks.
`Network interconnection raises a great many technical, legal,
`and political questions and issues. The technical issues gen-
`erally revolve around mechanisms for achieving interconnec-
`tion and their performance. How can networks be intercon-
`nected so that packets can flow in a controllable way from one
`net to another? Should all computer systems on all nets be
`able to communicate with each
`other? How can this be
`achieved? What kind of performance can be achieved with
`a
`set of interconnected networks
`of widely
`varying internal
`design and operating characteristics? How are terminals to be
`given access to resources in other networks? What protocols
`are required to achieve this? Should the protocols of one net
`be translated into those of another, or should common proto-
`cols be defined? What kinds
`of communication protocol
`standards are needed to support efficient and useful inter-
`connection? Who should take
`responsibility for setting
`standards?
`The legal and political issues are at least as complex as the
`technical ones. Can
`private networks interconnect
`to each
`other or must they do so through the mediation of a public
`network? How is privacy to be protected? Should
`there be
`control over the kinds of data which move from one net to
`another? Are there international agreements and conventions
`which might be
`affected by international interconnection of
`What kinds of charging and accounting
`data networks?
`policies should apply to multinetwork traffic? How can faults
`Who
`and errors be diagnosed
`in a multinet environment?
`should be responsible for correcting such faults? Who should
`be responsible for maintaining the gateways which connect
`nets together?
`these questions in this
`We cannot possibly answer all of
`paper, but we deal with many of them in the sections below.
`In the next sec-
`This paper is divided into eleven sections.
`tion we provide some definitions, and in Section 111 we ex-
`plore some of the motivations for network interconnection.
`In Section IV we discuss the range of end-user service require-
`ments and choices for providing multinetwork service. Section
`V reviews the concept of computer-communication protocol
`layering. Section VI reviews the basic interconnection choices
`and introduces the concept of gateways between nets, proto-
`col translation and the impact of common protocols; it elabo-
`rates also on the function of gateways. Section VII discusses
`
`the CCITT recommendations X.25 and X.75 and their role in
`network interconnection. Section VI11 describes some of the
`network interconnections achieved and some of the experi-
`ments in progress. Section IX outlines regulatory issues raised
`by network iqterconnection alternatives. Section X mentions
`some unresolved research
`questions, and the f i a l section
`offers some tentative conclusions on network interconnection
`issues.
`
`II. THE DEFINITION OF TERMS
`The vocabulary of networking is extensive and not always
`consistent. We introduce some generic terms below which we
`will use in this paper for purposes of discussion. It is impor-
`tant for the reader not to make any (I priori assumptions about
`the physical realization of the objects named or of the bound-
`ary of jurisdictions owning or managing them. For
`instance,
`a gateway (see below) might
`be implemented to share the
`hardware of a packet switch and be owned by a packet-switch-
`ing service carrier; alternatively it might be embedded in a host
`computer which subscribes to service on two or more com-
`puter networks. Roughly speaking, we are assigning names to
`or may not be realized as
`groups of functions which may
`physically distinct entities.
`Packet: A packet of information is a finite sequence of bits,
`divided into a control header part and a data part. The header
`to be routed
`will contain enough information for the packet
`to its destination. There wiU usually be some checks on each
`such packet, so that any switch through which the packet
`passes may exercise
`error control. Packets are generally
`associated with internal packet-network operation and are not
`necessarily visible to host computers attached to.the network.
`Datagram: A f i t e length packet
`of data together with
`destination host address information (and, usually, source
`address) which can be exchanged in its entirety between hosts,
`independent of all other datagrams sent through a packet
`switched network. Typically, the maximum length of a data-
`gram lies between 1000 and 8000 bits.
`Gateway: ‘The collection of hardware and software required
`to effect the interconnection of two or more data networks,
`enabling the passage of user data from one to another.
`Host: The collection of hardware and software which uti-
`lizes the basic packet-switching service to support end-bend
`interprocess communication and user services.
`Packet Switch: The collection of hardware and software re-
`sources which implements all intranetwork procedures such as
`routing, resource allocation, and error control and provides ac-
`cess to network packet-switching services
`through a host/
`network interface.
`Protocol: A set of communication conventions, including
`formats and procedures which allow two or more end points
`to communicate. The end points
`may be packet switches,
`hosts, terminals, people, fie systems, etc.
`Protocol Translator: A collection of software, and possibly
`hardware, required to convert the high level protocols used in
`one network to those used in another.
`Terminal: A collection of hardware and possibly software
`which may be as simple as a character-mode teletype or as
`complex as a full scale computer system. As terminals increase
`in capability, the distinction between “host” and “terminal”
`may become
`a matter of nomenclature without
`technical
`substance.
`Virtual Cirml: A logical channel between source and desti-
`nation packet switches in a
`packet-switched network. A
`
`Petitioner Emerson's Exhibit 1011
`Page 2 of 23
`
`

`
`1388
`
`PROCEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 1978
`
`virtual circuit requires some form of “setup” which may or
`may not be visible to the subscriber. Packets sent on a virtual
`circuit are delivered in the order sent, but with varying delay.
`PTT: Technically PTT stands for Post, Telegraph, and Tele
`phone Authority; this authority has a different form in differ-
`In this paper, by PTT we mean merely
`ent countries.
`the
`authority (or authorities) licensed in each country to offer
`public data transmimion services.
`We have attempted to make these defmitions as noncontro-
`versial as possible. For example, in the definition of packet
`switch, we alluded to a hostlnetwork
`interface. The reader
`should not assume that subscriber services are limited to those
`offered through the host/network
`interface. The packet-
`switching carrier might also offer host-based services and
`terminal access mechanisms as additional subscriber services.
`III. THE MOTIVATING FORCJS
`IN THE
`INTERCONNECTION OF DATA NETWORKS
`In the introduction, we mentioned that there was a strong
`interest, among both the users and suppliers of data serivces, in
`the interconnection of data networks. However, the technical
`interests of the different parties are not identical. The end
`user would merely like to be able to access any resources from
`a single terminal, with a single access port, as economically
`as possible according
`to his own performance criteria. A
`Public Carrier, or PTT, has a strong motivation to connect its
`network to other PTT’s. As in the telephone system,
`the
`concept of all subscribers being accessible
`through a single
`Public Data Service,
`is considered highly desirable; however
`the different PTT’s may have restricted geographic coverage,
`or only a specific market penetration.
`The motivation of the F ” s to interface to private networks
`facilities
`is weaker and more complex. They always provide
`to attach single terminals, where a terminal may be a complex
`computer system; they are often not interested, at present, in
`making any special arrangements when the “terminal” is a
`whole computer network. The operators of private networks
`often have a vital interest in connecting
`their networks to
`other private networks and to the public ones. Even
`though
`in many cases the bulk of its traffic is internal to the private
`network, which is why it was set up in the fmt place, there is
`usually a vital need to access resources not available on that
`limitations often imposed on the
`network. The regulatory
`method of interconnection of private networks are discussed
`in Section IX. In some countries, it is not permitted to build
`private networks using leased line services, but intrabuilding
`of such local
`networks may be permitted. Interconnection
`networks to public networks may play a crucial role in making
`the local network useful.
`To date the PTT’s have tried to standardize on access pro-
`cedures for their Public-Packet Data Services. The standardiza-
`tion has taken place in the International Consultative Commit-
`tee on Telegraphy and Telephony (called CCITT) in a set of
`recommendations called X.3, X.25, X.28,
`and X.29 ([271-
`[29]). Not all PTT’s have such forms of access yet, but most
`of the industrialized nations in the West are moving in this
`direction. This series of recommendations is discussed in
`much more detail in Section VI; it does not pay special atten-
`tion to the attachment of private networks ([31], 13211, but
`the recommendations are themselves expected to change to
`meet this requirement. The PTT’s are agreeing on a set of inter-
`face recommendations and procedures called X.75 j331, to
`connect their networks to each other; so far this interface
`
`procedure (and
`its corresponding hardware) is not intended
`to be provided to private networks.
`While most PTT’s have preferred to ignore the technical
`implications of the attachment of private networks to the
`public ones, most private network operators cannot
`ignore
`this requirement. They are often motivated to add some extra
`“Foreign Exchange” capability as an afterthought, with mini-
`mum change to their intranetwork procedures; this approach
`can be successful up to a point, but will usually be limited by
`the lack of high-level procedures between the different net-
`procedures have not yet been con-
`works. These high-level
`sidered by CCITT, but it has been proposed that CCITT Study
`Group VI1 investigate high-level procedures and architectural
`models, in cooperation with the investigation of “open system
`architectures” by Technical Committee 97, Subcommittee
`16 of the International Standards organisation (ISO). This
`subject is also considered later in this paper, in Section VI.
`An aim of these standardization exercises is to ensure that
`both manufacturer
`and user
`implementations of network
`resources can communicate with each other
`through single
`private or public data networks. A consequence should
`be
`resources are also compatibly accessible over con-
`that the
`nected data networks.
`Depending on the applications and spatial distribution of
`subscribers, the preferred choice of packet-switching medium
`Intrabuilding applications such as electronic office
`will vary.
`services may be most economically provided through the use
`of a coaxial-packet cable system such as the Xerox ETHERNET
`[ 181 and LCSNET [64], or twisted pair rings such as DCS
`[341, coupled with a mix of self-contained user computers
`(e.g., intelligent terminals with substantial computing and
`memory capacity) and shared computing, storage, and input-
`output facilities. Larger area regional applications might best
`employ shared video cables [ 3 51 or packet radios [ 201 , [ 2 1 ]
`for mobile use. National systems might be composed of a mix-
`ture of domestic satellite channels and conventional
`leased-
`line services. International systems might use point-to-point
`links plus a shared communication satellite channel and multi-
`ple ground stations to achieve the most cost-effective service.
`A consequence of the wide range of technologies which are
`optimum for different packet-switching applications is that
`many different networks, both private and public, may co-exist.
`A network interconnection strategy, if properly designed, will
`permit local networks to be optimized without sacrificing the
`possibility of providing effective internetwork services. The
`advantages of local net-
`potential economic and functional
`works such as ETHERNET or DCS will lead naturally to pri-
`vate user networks. Such private network developments are
`analogous to telephone network private automated branch
`exchanges (PABX) and represent a natural consequence of
`the marriage of computer and telecommunication technology.
`Two further developments can be expected. First, organiza-
`tions which are dispersed geographically, nationally, or inter-
`nationally,. will want to interconnect these private networks
`both to share centralized resources and to effect intraorganiza-
`t b n electronic mail and other automated
`office services.
`Second, there will be an increasing interest in interorganization
`interconnections to allow automated procurement and f i n d
`transaction services, for example, to be applied to interorgani-
`zation affairs.
`countries where private networks are permitted,
`In most
`interorganization telecommunication requires the involvement
`of a PTT. Hence the most typical network interconnection
`
`Petitioner Emerson's Exhibit 1011
`Page 3 of 23
`
`

`
`CERF AND KIRSTEIN: ISSUES IN PACKET NETWORK INTERCONNECTION
`
`1389
`
`scenarios will involve three or four networks. Within one na-
`tional administration the private nets of different organiza-
`tions will be interconnected through a public network. Inter-
`national interconnections will involve
`at least two public
`networks. We will return to this topic in Section VI.
`In addition to permitting locally optimized networks to be
`interconnected, a network interconnection
`strategy should
`also support the
`gradual introduction of new
`networking
`technology into existing systems without
`requiring simul-
`throughout. This consideration leads
`taneous global change
`to the conclusion that
`the public data networks should
`sup-
`port the most important user requirements for internet service
`If this were the case, then changes in net-
`from the outset.
`work technology which require a multinetwork system during
`phased transition would not, a priori, have to affect user
`services.
`w. PROVISION OF END-USER MULTINETWORK SERVICES
`The ultimate choice of a network interconnection strategy
`will be strongly affected by the types of user services which
`must be supported. It is useful to consider the range of exist-
`ing and foreseeable user service requirements without regard
`these requirements are to be
`for the precise means by which
`met. We will leave for discussion in subsequent sections the
`choice of supporting the various services within or external to
`the packet-switched network. The types
`of service discussed
`below are general requirements for network facilities. For this
`reason they also should be supported across interconnected
`networks.
`the currently prevalent computer-communication
`Most of
`services fall into four categories:
`1) terminal access to time-shared host computers;
`2) remote job entry services (RJE);
`3) bulk data transfer;
`4) transaction processing.
`The time-sharing and transaction services typically demand
`short network and host response timk but modest bandwidth.
`f i e transfer services more often require high
`The RJE and
`amounts of data transfer, but can tolerate longer delay. Some
`networks were designed to support primarily terminal service,
`leaving RJE or fie transfer services to be supported by dedi-
`cated leased lines. Packet-switching
`techniques permit both
`types of service to be supported with common network
`bulk
`resources, leading
`to verifiable economies. However,
`data transfer requires increasingly higher throughput rates if
`as the amount of
`delivery delays are
`to be kept constant
`data to be transferred increases.
`As distributed operating systems become more prevalent,
`there will be an increased need
`for host-to-host transaction
`services. A prototypical example of such a system is found in
`the DARF'A National Software Works [4], [36]. In such a
`system, small quantities of control information must be ex-
`changed quickly to coordinate the activity of the distributed
`components. Broadcast or multidestination services will be
`needed to support distributed file systems in which informa-
`tion can be stored redundantly to improve the reliability of
`access and to protect against catastrophic failures.
`Transaction services are also fiiding application in reserva-
`tion systems, credit verification, point of sale, and electronic
`funds-transfer systems in which hundreds or thousands
`of
`terminals supply
`to, or request of, hosts small amounts of
`information at random intervals. Real-time data collection for
`
`NETWORK
`
`GATEWAY
`
`USER TERMINAL
`
`NEmORK
`
`USER
`TERMINAL
`
`Fig. 1. Network concatenation.
`
`ground and air traffic control, and meter
`weather analysis,
`reading, for example, also fall into this category.
`More elaborate user requirements can be foreseen as elec-
`tronic mail facilities propagate. Multiple destination address-
`ing and end-bend encryption for the protection
`of privacy
`as well as support for text, digitized voice, and facsimile mes-
`sage transmission are all likely requirements. Electronic tele-
`conferencing using mixtures of compressed digital packet
`speech, videographics, real-time cursors (for pointing at video
`images under discussion), and text display will give rise to re-
`quirements for
`closed user groups and time-synchronized
`mixes of transaction-like (e.g., for cursor tracking and packet
`speech) and reliable circuit-like services (e.g.,
`for display
`management).
`Reliability and rapid response will be increasingly important
`as more and more computer-based applications requiring tele-
`communications are integrated into the business, government,
`military, and social fabric of the world economy. The more
`such systems are incorporated into their daily activities,
`the
`more vulnerable
`the subscribers are to failures. Reliability
`concerns lead to the requirement for redundant
`alternatives
`such as distributed fie systems, richly connected networks,
`and substantial local processing and storage capability. These
`trends increase the need for networking
`to share common
`hardware and software resources (and thus reduce their mar-
`ginal cost), to support remote software maintenance and de-
`bugging, and to support intra- and inter-organizational infor-
`mation exchange.
`We have described the end-user services required across one
`or more data networks. We have carefully refrained from dis-
`cussing which services should be provided in the data network,
`and which should be provided in the hosts. Here
`the choice
`in single networks will depend on the network technology and
`the application requirements. For example, in a network using
`a broadcast technology such as ETHERNET or the SATNET,
`multidestination facilities may well be incorporated in the data
`In typical store-and-forward networks, this
`network itself.
`feature might be provided at the host level by the transmission
`of multiple copies of packets. This example highlights im-
`mediately the difficulty of using sophisticated services at the
`data network
`level across concatenated networks.
`If A , B,
`and C are data networks connected as in Fig. 1, and A and C
`but not B support broadcast or
`real-time features, it is very
`difficult to provide them across the concatenation of A , B , and
`C.
`The problem of achieving a useful set of internetwork ser-
`vices might be approached in several ways, as follows.
`1) Require all networks to ihplement the entire range of
`desired services (e.%, datagram, virtual circuit, broadcast, real-
`
`Petitioner Emerson's Exhibit 1011
`Page 4 of 23
`
`

`
`1390
`
`
`
`
`
`PROCEEDINGS OF THE VOL. IEEE,
`
`
`
`
`
`66, NO. 11, NOVEMBER 1978
`
`these services across
`
`
`
`to support
`
`time, etc.), and then attempt
`
`
`
`the gateways between the networks.
`2) Require all networks to implement only the most basic
`or virtual circuit), support these ser-
`services (e.g., datagram
`and rely on the subscriber to imple-
`vices across gateways,
`ment all other services end-teend.
`3) Allow the subscriber to identify the services which he
`d&es and provide error indications if the networks involved,
`or the gateways between them, cannot
`provide the desired
`services.
`4) Allow the subscriber to specify the internetwork route to
`be followed and depend on
`the subscriber to decide which
`concatenation of services are appropriate and what end-teend
`protocols are needed to achieve the ultimately preferred class
`of service.
`5) Provide one set of services for local use within each net-
`work and another,
`possibly different set for internetwork
`use.
`The five choices above are by no means exhaustive, and, in
`fact, only scratch the surface of possibilities. Nothing has
`been said, thus far, about the compatibility of various levels
`of communication protocols which exist within each network,
`within subscriber equipments, and within the logical gateway
`between networks. To explore these issues further, it will be
`helpful to have a model of internetwork architecture, taking
`into account the common principle of protocol layering and
`the various possible choices of interconnection strategy which
`layer at which the networks are
`depend upon the protocol
`interfaced. We consider this in the next section.
`V. LAYERED PROTOCOL CONCEPTS
`Both to provide services in single networks, and to compare
`the capabilities of different networks, a very useful concept
`in networking is protocol layering. Various services of increas-
`ing capability can be built one on top of the other, each using
`the facilities of the service layer below and supporting the
`facilities of the layer above. A thorough tutorial on this con-
`cept can be found in the paper by Pouzin and Zimmermann in
`this issue [ 371 . We give some specific examples below of layer-
`ing as a means of illustrating the scope of services and inter-
`faces to be found in packet networks today-and some of the
`multiple
`problems encountered in offering services across
`networks.
`Table I offers a very generic view of
`a typical protocol
`hierarchy in a store-and-forward computer network, including
`layers usually found outside of the communication network
`itself. There are several complications to the use of generic
`protocol layering to study network interconnection
`issues.
`Chief among these is that networks do not all contain the same
`elements of the generic hierarchy. A second complication is
`that some networks implement service 'functions at different
`protocol layers. For instance, virtual circuit networks imple-
`ment an end/end
`subscriber virtual circuit in their intranet,
`end/end level protocol. Finally, the hierarchical ordering of
`functions is not always the same in all networks. For instance,
`TYMNET places a terminal handling protocol within the net-
`work access layer, so that hosts look to each other like'one or
`Figs. 2-7 illustrate the functional layering
`more terminals.
`of some different networks. It is important to note how the
`functions vary with the choice of transmission medium.
`
`A . ETHERNET
`In Fig. 2, we represent the Xerox ETHERNET protocol
`hierarchy. The basic link control mechanism is the ability of
`
`TABLE I
`GENERIC PROTOCOL LAYERS
`
`8. APPLICATION
`
`REIRIEVAL ELECTRONIC MAIL
`TEXT EDITING.. .
`
`4. ENDlEND SUBSCRIBER
`
`INTERPROCESS COMMUNICATION
`1E.G. VIRTUAL CIRCUIT, DATAGRAM,
`
`3. NETWORK ACCESS
`
`NETWORK ACCESS SERVICES
`1E.G. VIRTUAL CIRCUIT. DATAGRAM. . .I
`
`2 INTRANET, END-TO-END
`
`FLOW CONTROL SEQUENCING
`
`1. INTRANET, NODE.TO-NODE CONGESTION CONTROL ROWING
`
`0. LINK CONTROL
`
`ERROR HANDLING, LINK FLOW CONTROL
`
`Unm
`
`FILE TRANSFER
`
`VIRTUAL TERMINAL
`
`END-TOIND
`SUBSCRIBER
`
`I
`NETWORK ACCESS
`
`STREAM PROTOCOL
`
`RELIABLE PACKET PROTOCOL
`
`BROADCAST DATAGRAM IUNRELIABLU
`
`LooKyp,
`FILE A C E S
`
`LINK CONTROL
`
`Fig. 2. ETHERNET protocol layering.
`
`the interface device to detect conflict on a shared coaxial cable.
`If a transmitting interface detects that another
`interface is
`also transmitting, it immediately aborts the transmission.
`Hosts attached to the network interface present datagrams to
`be transmitted and are told if the datagram was aborted.
`Datagrams can be addressed
`to specific interfaces or to all of
`them. The end/end
`subscriber layer of protocol is split into
`two parts: a reliable datagram protocol in which each data-
`gram is reliably delivered and separately acknowledged, and
`a stream protocol which can be thought of as a virtual circuit.
`This split is possible, in part, because there is a fairly large
`maximum datagram size (about 500 bytes) so that user appli-
`cations can send datagrams without having to fragment and
`reassemble them. This makes the datagram service useful for
`otherwise have to use the
`many applications which might
`stream protocol. All higher level protocols, such as Virtual
`Terminal and File Transfer, are carried out in the hosts.
`
`B. ARPANET
`The ARPANET protocol hierarchy is shown in Fig. 3. The
`basic link control between packet switches treats the physical
`link as eight independent virtual links. This increases effec-
`tive throughput, but does not necessarily preserve the order
`in which packets were originally introduced into the network.
`The intranet node-tenode protocols deal with adaptive rout-
`ing decisions, store-and-forward service, and congestion con-
`trol. Hosts have the option of either passing messages (up to
`
`Petitioner Emerson's Exhibit 1011
`Page 5 of 23
`
`

`
`
`
`
`
`CERF AND KIRSTEIN: ISSUES IN PACKET NETWORK INTERCONNECTION
`
`
`
`
`
`I
`
`ENDEND
`SUBSCRIBER
`
`INTRANET
`ENDEND
`INTRANET
`NODE-NODE
`
`1391
`
`I
`P
`
`REASSEMBLY.
`FRAME D-BLY.
`ROWING. STORE/K)RWIRD, CONGOESTION CONTROL
`FRAME-BASED ERROR CONTROL
`RETRANSMISS#)N. SEQUENCING
`Fig. 4. TYMNET protocol layaing.
`
`Fg. 3. ARPANET protocol layering.
`
`8063 bits of text) across the host/network interface, which
`in sequence to the destination, or passing
`will be delivered
`datagrams (up to 1008 bits of text) which are not necessarily
`delivered in sequence. The user’s network access interface is
`datagramae in the sense that no circuit setup exchange is
`In
`needed even to activate the sequenced message s