Calhoun: The NPS Institutional Archive

Faculty and Researcher Publications Faculty and Researcher Publications

1983-09

Interconnecting Local Networks to

Long-Distance Networks

Schneidewind, Norman F.

IEEE

Computer, September 1983

http://hdl.handle.net/10945/45145

The approaches to interconnection-network access, network services,and protocolfunctions-are related and overlap. User requirements

and existing specifications determine which one the designer emphasizes.

Interconnecting Local Networks to

Long Distance Networks

Norman F. Schneidewind, Naval Postgraduate School

The demand for broad yet specific network servicesis an urgent one, and as both local and long-distance net-works proliferate, the need for better connections be-tween these disparate systems is becoming critical.A local network is a data communications system that

allows communication between a number of indepen-dent devices. These devices can be computers, terminals,mass storage devices, printers, plotters, or copyingmachines.1 The network may support a wide variety ofapplications, such as file editing and transfer, graphics,word processing, electronic mail, database management,and digital voice. Local networks are usually owned by asingle organization and operated within a restrictedgeographical area, most often within a mile radius, at amoderate to high data rate such as 10 million bits per sec-ond. A long-distance network, on the other hand, isusually owned by a communications carrier and operatedas a public utility for its subscribers, providing servicessuch as voice, data, and video.An emerging service of long-distance networks is pro-

viding the interconnection for local networks and otherlong-distance networks. Interconnection can provide

* local network to local network communication,* local network to long-distance network communica-

tion, and* long-distance network to long-distance networkcommunication.

These interconnection possibilities, though exciting, in-evitably present designers with the problem of resolvingnetwork incompatibilities. There are inherent differences

in network characteristics as the result of the diversity ofnetworks that exist to serve the various user com-munities. These differences have been accentuated by thefailure of some networks to adopt standard protocols, bythe variety of existing protocols and protocol standards,and by the wide range of incompatible options within ex-isting protocol standards. In addition, designers arefaced with a confusing mix of unregulated vendor prod-ucts (e.g., IBM's System Network Architecture), localnetworks (e.g., Ethernet), regulated common carrier net-works (e.g., Telenet), and newly deregulated communi-cation services (e.g., American Bell).

The changing network scene

To set the stage for discussing the interconnectionproblem, let's review the evolution of computer net-works to their current level of complexity.

Early connections. Before the advent of local net-works, network services-supported by a single long-distance network-were viewed as shown in Figure 1.This view had the following major characteristics:

* terminal to computer communication,* computer to computer communication, and* terminal to terminal communication.

The orientation was one of data communication ratherthan networking. The long-distance network providedthe terminal or remote-job-entry user with access to

0018-9162/83/0900-0015501.00 -- 1983 IEEESeptember 1983 15

remote computers or terminals. This mode of operationwas typical of, for example, earlier versions of Arpanet,Decnet, and SNA and of the services provided by datacommunications carriers such as AT&T and MCI. Thenetwork provided access to hardware and softwareresources that were not available locally.

Emergence of networking. Rapid advances in technol-ogy, coupled with the development of local network ar-chitectures and protocols, led to the implementation ofmultiple mini/microcomputer-based workstations. Theworkstations are tied together by a physical communica-tions medium and supported by protocols for network

Figure 1. Previous view of computer networks.

access and for message transmission and reception. In-itially, the terminal was the focal point of activity, access-ing hosts in a resource-sharing network such as Arpanetor using a long-distance communications network suchas AT&T for connection to a remote computer. Now, theemphasis has shifted to complete, self-contained localnetworks that access long-distance networks to com-municate with other networks and, at the same time, pro-vide communication among the local-network worksta-tions. Thus, contemporary network services feature bothinter-local and intra-local network communications (seeFigure 2). As far as the long-distance network is con-cerned, the entire local network looks and functions likea single terminal. Indeed, this is an interconnectiondesign goal.

Interconnection issues

Local and long-distance networks have significant dif-ferences that must be addressed when planning anddesigning networks consisting of one or more local net-works interconnected by one or more long-distance net-works.The differences between local and long-distance net-

works, summarized in Table 1, lead to major intercon-nection issues:

Figure 2. Contemporary view of computer networks.

COMPUTER16

* How should a local network be physically attachedto a long-distance network?

* How should one local network access and com-municate with another local network?

* To what extent should protocol and network ar-chitecture standards used in one network be used inanother network?

* How is the difference in bandwidth, as it affectsacknowledgment handling and flow control, to beresolved?

* How is the difference in delay time, as it affects userresponse time, to be reconciled?

* How should network addressing capability be pro-vided? (A single local network can, of course, have asimpler address structure than a long-distance net-work, but communication among multiple local net-works is the most difficult addressing problem ofall.)

Decisions regarding these interconnection issues must bemade before, not after, the networks are implemented.A variety of situations and factors can affect the type

of interconnection provided. Sometimes the networksalready exist and their specifications are known-for ex-ample, when an existing local network is connected to anexisting long-distance network to communicate withother local networks. In other situations, however, oneor more of the networks must still be specified. A com-mon design problem involves developing specificationsfor nonexistent local networks that are to communicatevia one or more existing long-distance networks.

Thus, the properties of the long-distance network(s)are usually given and part of the local network designproblem involves the specification of the interface forconnecting the two types of networks. For the designer,this situation presents both a challenge and an oppor-tunity: a challenge because few user organizations-other than communications carriers or the Departmentof Defense-can control the characteristics designed intolong-distance networks; an opportunity because thedesigner can influence the effectiveness of both intra-local and inter-local communication by the approach heuses to specify the network interface.

In designing the interface, the following importantprinciple applies:

The more a local network is designed to increase the ef-fectiveness of intra-local network communication, themore the cost of the interface to a long-distance net-work increases and the more the effectiveness of inter-local network communication decreases.

This principle is an outgrowth of the significant dif-ferences in the characteristics that distinguish local andlong-distance networks (Table 1). These differences leadto a high-cost, complex interface if each type of networkis tailored to the particular needs of its user communities.On the other hand, if the local network is designed toachieve compatibility with a long-distance network, thecost of the interface falls, but local-network throughputand response time suffer. The usual way of resolving thistrade-off is to lean heavily in the direction of maximizing

local network effectiveness, at the expense of interfacecost, because the interface represents a one-time costwhile the local network must provide effective service forits users over the lifetime of the network.

The ISO architecture

A significant development in the standards area thatexerts considerable influence on network design and in-tercommunication methods is the International Stan-dards Organization model of architecture for opensystems interconnection.2 (See Figure 3.) The extent to

Table 1.Comparison of local and long-distance network characteristics.

CHARACTERISTIC

Typical Bandwidth

Acknowledgment

Message Size andFormat

Network Control

Flow/ CongestionControl

Error Rate

Message Sequenceand Delivery

Standard Architecture

Routing

Delay Time

Addressing

LOCAL NETWORK

10 million bits persecond.

One messageacknowledged at atime.

Small (simpleheader). No need todivide message intopackets.

Minimum requirementdue to small numberof links and nodesand simple topology.

Minimum due to highbandwidth and simpletopology.

Relatively low.Operated in benignenvironment.

Minimum problemdue to simpletopology (e.g., bus orring).

Usually only two orthree bottom layersprovided.

None required due tosimple topology.

Small due to shortdistance and medium(e.g coaxial cable).

Simple intra-networkcommunication due tosimple topology.Complex inter-net-work communicationdue to the use oflong-distancenetwork(s) .

LONG-DISTANCE NETWORK

56,000 bits per second.

N messages acknowledged at atime.

Large (complex header). Needto divide message into packets.

Extensive due to large numberof nodes and links and complextopology.

Extensive due to low bandwidthand complex topology.

Relatively high. Operated innoisy environment of telephonenetwork.

Major problem due to complextopology (e. g., mesh).

Frequent use of all or many ISOlayers.

Major problem due to complextopology.

Large due to distance andmedium (e.g., satellite).

Complex because of manynodes and links.

September 1983 17

which local and long-distance networks adhere to theISO model has an important bearing on the nature andcomplexity of the interconnection. The use of many, orall, ISO layers is particularly important for long-distancenetworks because of their

* complex topology,* wide geographical coverage,* large number of nodes and links,* extensive switching and routing,* numerous points requiring flow control and conges-

tion control,* relatively long delays in end-to-end transmission,and

* long distance process-to-process communication re-quiring complex acknowledgment schemes.

Local networks, on the other hand, have much simplercharacteristics and thus less need for the various ISO pro-tocol services. Warner3 has suggested that forcing a localnetwork design in total into the ISO mold could result insignificant overhead in terms of (1) a large message sizeto accommodate multiple headers for the many ISOlayers, (2) complicated and unnecessary message ac-knowledgment procedures, and (3) extraneous hardwareand software to support the ISO transport and networklayers. However, not using ISO in the local network risksloss of compatibility with ISO-based networks, one of

PHYSICAL COMMUNICATION MEDIUM

FUNCTION

Communication between cooperating user processesFormatting and display of user dataCoordination and administration of user process data exchangeReliable end-to-end transfer of data over virtual circuitsRouting and switching of packets in the communication subnetworkReliable packet transfer between nodes in the communicationsubnetwork

Transmission of bits between nodes in the communicationsubnetwork

Figure 3. ISO model seven-layer architecture.

which could be a long-distance network that must inter-face with the local network.

Approaches for solvingthe interconnection problem

The three basic approaches to interconnection-net-work access, network services, and protocol func-tions-are related and frequently overlap. Bear in mindthat a combination of the approaches, described andcompared below, may be necessary to interconnectdiverse networks effectively.

Network access. The network access approach in-volves making electrical and physical connections oflocal networks and user communities via the long-distance network. The predominate considerations inthis approach are ones of physical access and interfac-ing-for example, signal levels, pin connectors, cablelength, and transmission medium. But it also emphasizeslocal-network compatibility with the long-distance net-work at the bottom three layers of the ISO model. Allthree layers are needed. Any network communication re-quires the data link layer for reliable internode com-munication, and a long-distance network requires theswitching and routing functions of the network layer.The main concern in this approach is the user's ability

to access additional users and resources at a reasonablecost by the most convenient, feasible method. Whetheror not the network services obtained as a result of theconnection are ideal for the application is of secondaryconcern.A number of situations could motivate user interest in

the network access approach. Frequently, the motivationis convenience; the service needed-say, for example, anX.25-compatible network-might simply be readily avail-able. Another possibility is that the user's objective islimited. He might not be interested in obtaining compu-ter-based services such as database management, finan-cial forecasting, or engineering computation; perhaps heonly wants the services of a transmission medium forproviding connectivity to other users. Then, the need isfor a communications facility whose primary function isthe transport of data. A data communications carrier isfrequently the long-distance network that provides thislevel of service. A third possibility is that the user's ter-minal equipment is only compatible with certain net-works, so the ability to provide interconnection at thelowest physical level outweighs other considerations.

Ordinarily, the network access approach is used whenboth the local networks and the long-distance networkalready exist. Since network characteristics cannot becreated or modified, the user's options are limited, andhe must be content with a low-cost network that ishardware-compatible with his local networks.

Network services. High-level user services can be ob-tained with the network services approach to intercon-nection. Some services, such as database management,could be related to the application and presentationlayers of the ISO model; others, such as a high-level com-

18 COMPUTER

munication service like electronic mail, could be relatedto the transport and network layers.

Obviously, any interconnection approach involvesconnections between local networks and a long-distancenetwork and thereby provides inter-local network access.However, in contrast to the first approach, the networkservices approach stresses obtaining specific network ser-vices for the user organization, and the details of physicaland electrical interfacing, while important, becomesecondary issues. Necessarily, this approach emphasizescompatibility between local networks and a long-distance network at the higher level layers of the ISOmodel.What conditions motivate a user to consider this ap-

proach? One situation is when the long-distance networkprovides a data management or processing service that isnot available in the local networks. Often only a large-scale network (e.g., Arpanet) has the host hardware andsoftware capable of providing a desired service. A secondsituation arises when a high-level, inter-local networkcommunication service is desired. For example, the userorganization may want to tie its local networks together,or connect to other organizations' local networks to pro-vide remote interactive processing involving session con-trol and sequenced, error-free message delivery. Typical-ly, this type of service would be obtained from a long-distance network that provides a virtual circuit service.Since the objective is to obtain a specific type of networkservice, naturally the long-distance network is an existingone. However, the local networks may or may not exist.If they do, protocol conversion will probably be requiredat the interface between the local networks and the long-distance network. If they don't exist and if ease of inter-facing is a primary objective, the desired service mayprompt the local network designer to attempt maximumcompatibility with the layers and protocols of the long-distance network.

In general, a data communication network is appropri-ate for the network access approach, but a resource-sharing or value-added network is germane to the net-work services approach.

Protocol functions. The third method of achieving in-terconnection provides one set of protocol functions forthe local network and another set for the long-distancenetwork, where some functions, or corresponding net-work layers, are common to both networks. When cross-ing network boundaries, a transition or "conversion" ismade between protocols. The boundary points aretypically implemented in hardware with gateways (an in-terface between two networks) and front-end processors.This method is used when the user's primary objective

is to optimize local network communication, by usingonly those layers and protocols necessary for local net-work operation, while also providing communicationbetween local networks via the long-distance network.Although the user will not be indifferent to physical ac-cess and network services, the dominant objective is tomarry two diverse types of networks, which are inherent-ly incompatible, and still retain the effectiveness of each.Protocol conversion is necessary to achieve this objec-tive. The degree of conversion is a function of the dif-

ferences between the layers and protocols in the twotypes of networks.When would a user organization be able to capitalize

on this approach? The most likely situation is when thelocal networks have not been implemented and the userhas the opportunity to influence both intra-local networkand inter-local network effectiveness by virtue of theprotocol functions provided in the local networks; thelong-distance network may or may not have been im-plemented (i.e., it may also be in the planning or develop-ment stage). Regardless of the status of the long-distancenetwork, the user organization would, in most instances,have negligible influence over the design of the long-distance network due to the size and dominant positionof the long-distance network organization.

In some cases, one protocol can betranslated into another. In others, protocols

can be held in common among thecommunicating parties.

This approach is seldom viable when the local net-works exist; the likely degree of protocol conversion re-quired, in terms of message format, message size,acknowledgment method, naming, addressing, errorcontrol, etc., would make it infeasible.

Comparison of approaches

As stated by Cerf and Kirstein,4 the common objectiveof all interconnection methods is to allow all subscribersa means of accessing a host on any of the interconnectednetworks. They go on to declare that achieving this ob-jective requires that data produced at a source in one net-work be delivered and correctly interpreted at thedestination(s) in another network. This reduces to pro-viding interprocess communication across networkboundaries. In some cases, it is enough to translate oneprotocol into another. In others, protocols can be held incommon among the communicating parties.The efficiency of achieving this objective depends on

which approach is utilized. It is not necessary to imple-ment all ISO layers in the local network to achieve effec-tive intra-local network communication, nor is imple-mentation necessary to connect to a long-distance net-work. However, the number, types, and characteristicsof the layers utilized determine the efficiency of inter-local network communication (i.e., communication overthe long-distance network).The network access approach certainly achieves physi-

cal access to hosts, but the interconnection does not pro-vide access to all the services available in the long-distance network. This approach does not fully achievethe requirement of delivering data from the source andhaving it correctly interpreted at the destination, becausecomplete compatibility between local network protocolsand long-distance network protocols may not be possi-ble. For example, it might achieve a datagram service,which requires only the first three ISO layers, but might

September 1983 19

not be able to realize virtual circuit service, which re-quires use of the transport layer.The network services approach does, on the other

hand, completely satisfy the requirement regarding datadelivery and interpretation, but not necessarily efficient-ly. In this approach, it may be necessary to adopt ineffi-cient local network protocols to achieve compatiblitywith the long-distance network. This is the case if theprotocols are held in common among the communicatingparties, where the "communicating parties" are the localnetwork and the long-distance network.

Table 2.Comparison of network interconnection approaches.

APPROACH CHARACTERISTIC ADVANTAGES DISADVANTAGES

Network Achieves physical Relatively Only providesAccess access and protocol inexpensive. May compatibility with

compatibility in lower obtain compati- lower layers oflayers of ISO model bility with network architecture.(e.g., physical, data international Restricted to serviceslink, and network standards. of network accesslayers of X.25). method.

Network Obtains use of The network Restricted to usingServices specific types of service is the same (perhaps

services (e.g., virtual matched to the inefficient) protocolscircuit service) to user need as in all interconnectedsatisfy user needs, opposed to simply networks. May be

obtaining physical restricted to using aaccess to a single type ofnetwork. Reduces service.software develop-ment expense.

Protocol Matches number and Uses only those Expensive softwareFunctions types of protocols to protocols that are development.

each type of network, necessary in each Complex networktype of network, interface.High perfor-mance. Lowoverhead.

Figure 4. Structure of the X.25 interface (adapted from Reference 5).

The protocol functions approach solves the problemof local-network communications efficiency, but at highhardware and software costs. Its use of the protocoltranslation technique necessitates a complex network in-terface.

In general, no matter which approach is utilized, theowner of the local network is responsible for designingthe interface and arranging the connection with theowner of the long-distance network, using the specifica-tions of that network as a guide. This work will takeplace over an extended period of time, and involvesdevelopment, design, implementation, and mainte-nance. The three approaches are summarized and com-pared in Table 2.

Examples of interconnection approaches

Network access. Rybczynski5 provides an example ofthe network access approach to interconnection vis-a-visthe X.25 interface standard. X.25 is a standard device-independent interface between X.25-compatible packetnetworks and user devices operating in the packet mode.The interface point occurs between the user's data ter-minal equipment, or DTE, and the d4ta communicationsequipment, or DCE, of an X.25 packet switching net-work (e.g., GTE-Telenet). Although the DTE is oftenthought of as an individual terminal or host, it could justas well be a front-end processor of a local network. TheDCE could be a modem associated with the communica-tion channel of an X.25 packet-switching node. Multiplelocal networks connected in this fashion would provideinter-local network communication and the services of-fered by the X.25 long-distance network. The interfacebetween the DTE and DCE occurs at the first three layersof the ISO model, as shown in Figure 4.The characteristics of these layers* are as follows:

Physical layer* full duplex,* point-to-point, and* synchronous.

Data link layer* data link control procedures compatible with the

high-level data, link control (HDLC) protocol,* single data links,* data transfer,* link synchronization,* detection of and recovery from errors, and* reporting of errors to a higher layer.

Network layer* packetizing of user and control data,* network addressing, and* multiple virtual circuits.

From a practical standpoint the user organizationmust provide the appropriate hardware and software in

'The X.25 designations for the ISO network and data link layers are"packet" and "frame," respectively; X.25 also uses "level" rather thanthe ISO term "layer. " The ISO terminology is used here to maintain con-sistency.

COMPUTER20

its network access unit (e.g., a front-end processor) in thephysical, data link, and network layers to be compatiblewith X.25. This means, for example, providing softwareto implement HDLC in the data link layer and an RS-232-C hardware interface in the physical layer.

This approach to interconnection emphasizes physicalaccess and the use of the long-distance network as a com-munications medium for the exchange of messages be-tween local networks. The interconnected local networksmust adopt the standards of the long-distance networkand install the lower level protocols (e.g., physical, datalink, and network layers of X.25) of the long-distancenetwork. This will be beneficial or detrimental for theoperation of the local networks, depending on whetherthe protocol characteristics (acknowledgement, address-ing, etc.) enhance or degrade the performance of thelocal networks. Since this approach only addresses thelower level protocols, the user must provide the upperlayer protocols. Also, since network performance isprimarily a function of upper-layer characteristics,achievable performance will be uncertain. The major ad-vantage of this approach is its low cost, since the requiredprotocol software exists for many computers.

DDN, the defense data network, illustrates the limita-tions of the network access approach, specifically withregard to X.25. Although using X.25 is not currently aDDN requirement, it may be added to permit communi-cation with network nodes in the NATO community.6The switching nodes used in the DDN (BBN ModelC/30s) are designed to be compatible with X.25 in allthree layers. However, layer 3 of X.25, the networklayer, is not compatible with the layer-3 host-IMP pro-tocol used to support communication between a local net-work and the DDN. Without the installation of a gateway(i.e., the protocol functions approach), it will not be possi-ble for hosts in the DDN to communicate with hosts inNATO. Thus, although X.25 protocol software exists inDDN, offering the potential for a low-cost interconnec-tion, no local network can presently connect to DDN usingX.25 protocols; it would not be compatible with all theDDN protocols. Achieving this compatibility would re-quire a protocol converter for translation between thehost-IMP and X.25 network layer protocols.

Network services. Another example using X.25 il-lustrates the relationship between network access andnetwork services. In this example, the real significance ofachieving X.25 network access compatibility is to obtainX.25 network services such as switched virtual circuits,permanent virtual circuits, and datagrams.

SVCs and PVCs. Switched virtual circuits, or SVCs,provide a temporary logical circuit between two host pro-cesses. A call request action by the process that wants to

open a connection is required. An SVC will compete forthe use of available network resources, and possibly ex-

perience delay in establishing the circuit, but has the ad-vantage of using these resources efficiently. On the otherhand, a permanent virtual circuit, or PVC, guaranteesnetwork access to the user, obviating the call request pro-cedure, and provides a data path between a fixed pair ofnetwork endpoints. The SVC and PVC services are

analogous to the switched network and leased lines ser-vices offered by data communications carriers.Datagrams. A datagram service provides transmis-

sion of packets in a network where each packet is inde-pendent of other packets. There is no guarantee of se-quenced delivery of packets constituting a message, norguarantee of any type of delivery, for that matter. Adatagram service is fast and uses network resources effi-ciently-for example, the destination node can pass amessage to a host without waiting to reassemble all of itspackets or tieing up valuable buffer space for this pur-pose. If the user desires guaranteed sequenced delivery, itmust be provided by the transport layer residing abovethe network layer, which is charged with datagramdelivery.

It is one thing for users to toleratean occasional lost packet but quite different

to forego sequential delivery.

A datagram service is useful in certain applicationswhere no higher layers are necessary to complete the jobof message delivery and where all the data to carry out afunction can be contained in a single packet for exam-ple, transaction processing such as a file update, whereeach update represents an independent action, and nar-rative message transmission, where each message can beconsidered an independent entity. In some applica-tions- digitized voice, for example a datagram serviceis used primarily because of its speed.Most practical applications of datagram services re-

quire the transport layer to sequence datagrams fordelivery to a host process. It is one thing for all the data ina packet to be self-contained (e.g., a Fortran compilecommand) or to tolerate an occasional lost packet (e.g.,digitized voice) but quite different, from the standpointof the user's operation, to forego sequential delivery; theuser wants a Fortran compile done next or the parts of avoice conversation to reach the listener in sequence.(Subsequent sections show how the Department ofDefense uses the datagram concept in combination withupper layer functions to provide the desired networkservices.)DoD DDN. An application where X.25 takes on great

importance is the Department of Defense's Defense DataNetwork.6 As related by Corrigan,7 planners of DDNwere confronted with the following situation:

(1) For the most part, vendor protocols are incompat-ible across different manufacturers' equipment.

(2) However, the DDN must allow for various vendorprotocols because many DoD user communities,using a great variety of vendor hardware and soft-ware, must be accommodated in the DDN.

(3) Although the Arpanet architecture and protocols,on which the DDN is based, provide many of thecapabilities desired for the DDN, they are notcompletely compatible with the various vendorprotocols.

September 1983 21

(4) X.25 has been adopted by manufacturers but hasnot been implemented in the DDN.

Cerf and Lyons8 point out that, although X.25 is anetwork access standard for connecting to packet-switched networks, it has the following deficienciesrelative to its use in the DDN:

(1) Although datagram service is part of the standard,it has not been implemented in any network. Thedatagram mode is essential to real-time militaryapplications, such as tactical operations andpacket voice.

(2) The availability of only virtual circuit service inX.25, with its required sequencing, introduces in-tolerable delays in certain real-time applications.In many applications, total data integrity is notessential, but minimum delay is mandatory. Cer-tan military applications require a broadcastmode, which is not compatible with sequenceddelivery in a virtual circuit.

Given the diversity of network characteristics,the network services strategy may be

good for inter-local network operationsbut not for intra-local network performance.

Thu.s, the DoD is faced with a dilemma: compatibilitywith X.25 is important because many vendors and com-munications carriers have adopted it, but X.25 does notfully meet DoD's requirements. The DoD's response tothis problem is fourfold8:

(1) The Internet protocol9 has been developed for theDDN and is now operational on Arpanet. IP pro-vides a datagram service for those applicationswhich require fast, nonsequenced delivery and ad-dressing and routing capabilities for transmissionof datagrams across multiple networks.

(2) The Transmission Control Protocol9 has beendeveloped for the DDN and is now operational onthe Arpanet. Using the services of IP, and the ad-ditional capabilities of sequenced delivery, flowcontrol, and end-to-end acknowledgment, TCPprovides a virtual circuit service for applicationsthat require interactive terminal to remote hostprocessing.

(3) As a long-range goal, DDN compatibility withX.25 is planned.

(4) The Defense Communications Agency is workingwith the international standards bodies (e.g., ISOand CCITT) to promote acceptance of TCP/IP inthe civilian community and to urge these bodies togive more weight to military requirements, such asreal-time response, security, precedence messagehandling, and survivability, in their standards ef-forts.

From the above, it can be seen that achieving intercon-nection among diverse networks can verv likely involve a

combination of approaches: network access (e.g., X.25),network services (e.g., datagram and virtual circuit), andpolitical and standards activity (e.g., ISO).The important factor in the network services approach

to interconnection is obtaining services available in thelong-distance network for the user organization's localnetworks. Given the diversity of network characteristics,this strategy may be good for inter-local network opera-tions but not for intra-local network performance. Suchpenalties as high software overhead, due to unneededflow control, routing, and addressinig capabilities, aieespecially prevalent if all layers of the long-distance net-work are incorporated into local network communica-tion operations. Even inter-local network efficiency canlbe poor if service is limited to one type (e.g., fixed-routing virtual circuit service). However, this approachhas the significant advantage of providing clean inter-faces at the network boundaries, due to the use of thesame protocols in all networks. The implication of this isreduced software development costs compared to meth-ods that tailor the protocols to the characteristics of eachinterconnected network.

Protocol functions. An example illustrating the pro-tocol functions approach is the Navy's Stock PointLogistics Integrated Communications Environment sys-tem. The SPL.ICE concept is being developed as a resultof growing demands for automated data processing atNavy stock points and inventory control points. SP[ ICFis designed to augment the existing Navy stock point andinventory control point ADP facilities, which supportthe Uniform Automated Data Processing System-StockPoints. The hardware for the UADPS-SP consists ofBurroughs medium-size systems. At present there are 20new application systems being developed that requireconsiderable interactive and computer communicationsupport. These new application systems will utilizeminicomputers capable of supporting foreground in-teractive and computer communication requirements.Two major objectives led to the development of

SPLICE: first, the increased need for the use of interac-tive database processing to replace the current batch-oriented system; second, the need to standardize the cur-rent multitude of interfaces. To reduce total system cost,SPLICE will be developed using a standard set ofminicomputer hardware and software. Standardizationis particularly important because SPLICE will be im-plemented at some 60 geographical locations, each hav-ing a different mix of application and terminal re-quirements. The SPLICE processors will be co-locatedwith the host Burroughs system at each Navy stock pointand with Burroughs and Univac systems at the inventorycontrol points. A "foreground-background'" conceptwill be implemented with SPLICE minicomputers, whichwill serve as front-end processors for the Burroughssystems via a local area network interface. The Bur-roughs computers will provide background processingfunctions for large file processing and report generation.The SPLICE projectt0 has the following characteris-

tics:

* intra-local area network communication,

COMPUTER22

* inter-LAN communication over the long-distanceDDN,

* conflicting requirements-LAN vs. long-distancenetwork-for communication,

* mandated communications protocols, required forcompatibility purposes, that have little relevance toLAN communication,

* local and remote interactive and batch processing,and

* off-loading of certain processing (e.g., databasemanagement) from mainframes to minicomputers.

The network configuration (Figure 5) shows the in-tegration of the three interconnection methods-net-work access, network services, and protocol functions.Network access is achieved via the hardware of the front-end processor in conjunction with the access line and thehost-IMP protocol, a network access protocol used in theArpanet and adapted to the DDN. Basic network servicesconsist of a virtual circuit service for interactive process-ing and other operations that require reliable, sequencedend-to-end message delivery, plus a datagram service foroperations which involve the transmission of indepen-dent messages (e.g., the sending of a message in the elec-tronic mail system). The datagram service, implementedin the internet protocol (IP) and operating in the networklayer, * supports the transmission control protocol(TCP), operating in the transport layer, to provide a vir-tual circuit service. The datagram service is used to ob-tain efficient bandwidth utilization and flexibile messagerouting. This flexibility is achieved because the messagescan be transmitted as independent packets without beingconstrained to follow a single path and to follow oneanother in sequence. The TCP sequences the messages

'Some authors classify this as an eighth layer-the internet layer-situated between the transport and network layers.

and provides reliable end-to-end delivery. The protocolfunctions approach provides only those protocols in thelocal area network that are needed to support this type ofcommunications environment. Due to the great differ-ences between local and long-distance network charac-teristics, protocol requirements differ significantly. Thispoint is illustrated in Table 3, which delineates differ-ences in the utilization of ISO layers and protocols inLAN and DDN communication.

Sending and receiving messages on the DDN will useall seven layers of the ISO model, as shown in Table 3.The LAN has no need for the services normally providedby the transport and network layers, because routing,switching, and traditional flow control and congestioncontrol services are unnecessary. The presentation layer,implemented in the terminal management module, willaccept data from the application process and convert it toLAN format. Conversely, it will accept messages inLANformat and convert them to the appropriate applicationprocess format.

Table 3.Use of ISO layers In LAN design.

LAN COMMUNICATIONLAYER PROTOCOL/MODULE DON COMMUNICATION

Application Application Process Modules Same as for LAN

Presentation Terminal Management Terminal Management

Session Session Services Session Services

Transport -- TCP

Network -- IP

Data Link Local Communications Specified by the DDN

Physical Local Communications J (Various Protocols)

Figure 5. Relationship between local area networks and the Defense Data Network.

September 1983 23

To simplify the LAN design, the following messageformats are used:

(1) TCP format will be provided to the DDN by theNC module (see Figure 5) whenever communica-tion on the DDN is necessary. A much simpler for-mat will be used for intra-LAN communication.

(2) End-to-end virtual circuit connections and break-ing of complete messages into fragments, servicesnormally provided by the transport layer, will beimplemented in each of the LAN modules. "End-to-end" in this context refers to the logical com-munication linkage between two modules sep-arated by a relatively short distance; in some casesthe two modules could be in the same hardwareunit.

To maximize compatibility and minimize softwaredevelopment, the protocols in the two networks areselected to match as closely as possible, consistent withsatisfying the requirements of vastly different com-munications environments (e.g., routing in the DDN andno routing in the LAN).The protocol functions approach is used where the

inter-local network services and performance providedby the long-distance network (e.g., combination of vir-tual circuit and datagram services) are satisfactory. It isalso used where optimization of intra-local network per-formance is desired. This is accomplished by using onlythose layers and protocols that are compatible with andcan take advantage of the characteristics of local net-works (e.g., single message acknowledgment made pos-sible by high bandwidth). Of course, the user organiza-tion must be willing to pay the relatively high softwarecost of this tailored approach.

It is apparent from the discussion and examples thatusers may have diverse networking requirements and thatlocal and long-distance networks have opposing charac-teristics. For most applications, this means that it will benecessary to use a combination of the three approachesto achieve an effective interconnection.a

Acknowledgment

This work was sponsored by the Fleet Material Sup-port Office and the Naval Supply Systems Command.

References

1. A Status Report, IEEE 802 Local Network Standard,Draft B, Local Network Standards Committee, IEEEComputer Society, Oct. 19, 1981.

2. H. Zimmermann, "OSI Reference Model-The ISO Modelof Architecture for Open Systems Interconnection," IEEETrans. Communications, Vol. COM-28, No. 4, Apr. 1980,pp. 425432.

3. Clifford Warner, "Connecting Local Networks to LongHaul Networks; Issues in Protocol Design," Proc. Fifth

Conf. Local Computer Networks, IEEE Computer Socie-ty, Oct. 1980, pp. 71-76.

4. V. G. Cerf and P. T. Kirstein, "Issues in Packet-NetworkInterconnection," Proc. IEEE, Vol. 66, No. 11, Nov.1978, pp. 1386-1408.

5. A. Rybczynski, "X.25 Interface and End-End Virtual Cir-cuit Service Characteristics," IEEE Trans. Communica-tions, Vol. COM-28, No. 4, Apr. 1980, pp. 500-510.

6. Defense Data Network Program Plan, Defense Com-munications Agency, Jan. 1982, revised May 1982.

7. Michael L. Corrigan, "Defense Data Network Protocols,"Conf. Record, EASCON 82, 15th Annual Electronics andAerospace Systems Conf., Washington, DC, Sept. 1982,pp. 131-135.

8. V. G. Cerf and R. E. Lyons, "Military Requirements forPacket-Switched Networks and Their Implications forProtocol Standardization," op cit., pp. 119-129.

9. Jonathan B. Postel, "Internetwork Protocol Approaches,"IEEE Trans. Communications, Vol. COM-28, No. 4,Apr. 1980, pp. 604-611.

10. N. Schneidewind, "Functional Approach to the Design ofa Local Network: A Naval Logistics System Example,"Compcon Spring 83 Digest of Papers, IEEE ComputerSociety, Mar. 1983, pp. 197-202.

Norman F. Schneidewind is a professor ofcomputer science at the Naval Postgrad-uate School, where he teaches in informa-tion systems and computer science anddoes research in computer networks andsoftware engineering. Schneidewind is theprincipal investigator on the Navy'sSPLICE computer network project. He hasheld various technical and managementpositions in computer system devel-

opment at SDC, PRC, CUC, Sperry Univac, and Hughes Air-craft.

Schneidewind is a senior member of the IEEE; a member ofthe Executive Board of the IEEE-CS Technical Committee onSoftware Engineering, the IEEE Committee on Communica-tions and Information Policy, and the Software EngineeringStandards Subcommittee; chairman of the Software Mainte-nance Workshop; and IEEE-CS representative to the AnnualSimulation Symposium.He received the BSEE from the University of California,

Berkeley; MSCS from San Jose State University; and MSOR(Engr), MBA, and DBA from the University of SouthernCalifornia; and holds the Certificate in Data Processing.

24 COMPUTER