The Extended Local Area Network Architecture

and LANBridge _{1 00}

A study was conducted to identify the wide variety of application needs and environments for broadband local area networks. This study con

cluded that no single local area network in isolation was capable of com

pletely solving the broad range of networking problems of interest. The project team investigated alternative ways to provide solutions to these problems, including various local network technologies and interconnec

tion schemes. From this investigation the team developed the Extended LAN Architecture, capable of incorporating a variety of LAN technologies.

Using this architecture, the team designed a high-performance implemen

tation of an Ethernet-to-Ethernet bridge, which led directly to the !AN

Bridge 100, a product satisfying the original goals.

In early 1 982, Digital's Networks and Communi·

cations Group in conjunction with Corporate Research initiated an advanced development effort called the Broadband Project. The project's original goal was to recommend which broad

band products should be implemented during the next two years and which technologies should be contained in those products. There were several motivations behind this goal.

First, there was significant uncertainty with

in computer companies, including Digital, about the most appropriate physical medium for local area network (IAN) products. At that time, Digital had - and still has - a strong commit

ment to the Ethernet concept using baseband coaxial cable. It was clear that while most appli

cations were served very well by an Ethernet using baseband coaxial cable, some applications were better served by other media, such as CATV,

fiber-optic, or twisted-pair cables. The increas

ing number of installations using private broad

band technology, with its moderate bandwidth, led the team to focus on this technology.

Second, the DECOM broadband Ethernet media access unit and related products were under development within Digital at that time.

Therefore, an effective mechanism for intercon

necting broadband and baseband products was

needed. There was a clear need to have LAN products that could intemperate, at least at the network level.

Third, the project team agreed that some IAN applications would require significantly more physical extent than could be offered with either the baseband or broadband Ethernet products.

Therefore, some means of offering a greater extent was required. As will be shown later, the results of the Broadband Project were very differ

ent from the ones that had been anticipated when it was initiated.

Defining the Problem

The project team first proceeded to investigate the user environments in which these networks would be utilized. There were three types of environments ofconcern to the project: the busi

ness office, the university campus, and the fac

tory. Clearly, assumptions about these environ

ments were not mutually exclusive, but the names evoke the problems to be solved in each one. The next step was to gather more input on customers' requirements, applications, and physical environments.

Some information had already been collected by team members on previous visits to customer sites, including a heavy-manufacturing facility

Digital Tecbnk4ljournal No. 3 September 1986

and a university campus . This i nformation bel ped the team to construct a refined set of questions to be asked on visits to other cus

tomers. Subsequently, the team visited two more universities and several commerCial sites where continuous process monitoring and control, and research were performed. The team also exam

ined one of Digital's sites that represented an extensive office environment.

The team discovered several generalized types of message traffic that were characteristic of the applications studied. These types were terminal

to-computer, computer-to-computer, and real

time traffic. 1 Unfortunately, most customers were unable to deliver actual network loads and traffic matrices for their environments. There

fore, the team had to derive models for those generalized types of traffic, using previous mea

surements of internal workloads and some edu

cated assumptions. These models were subse

quently used to evaluate several architectures offered by the team as candidates to meet the project's goals.

The environmental model for each traffic type shows particular characteristics. The terminal

to-computer model has a large number of termi

nals, all needing access to a small or moderate number of host computers. Although the aggre

gate throughput is small, the traffic is bursty. In addition , the cost to connect each terminal device to the network must be small (i.e., not large compared with the cost of an inexpensive terminal).

Computer-to-computer traffic needs full logi

cal connectivity and has higher throughput (up to several megabits per second per computer)

Table 1 Definitions of Environments

Environment Extent

Office Less than

3 kilometers

Campus Less than

25 kilometers

Factory Less than

8 kilometers

Digital TecbnlcalJournal No. 3 September 1986

Number of Stations Less than 1 30 Less than 1 0,000

Less than 2200

than the previous model. The traffic for this model is also bursty. Fu

rt

_Ihermore, the project team thought that, as workstations and personal computers became comm

b

n, this class of traffic would soon become mu

t

h more widespread than terminal-to-computeThe real-time environment is characterized by

�

^traffic.

a large number of devic.

t!

I s (thousands) whose requirements to communicate are quite hierar-chically structured. The a

p

plied load for a real

time environment is more accurately modeled by deterministic arrivals. M

d

reover, most applica

tions in this environment

�

xpect the variance of the access latency to be l

rl

^{w in the}^IAN^.

The team next defined

h

ominal environments for an office, a campus, an

a

a factory. These defi

nitions are summarized in

l

Table 1 .

In these definitions, harsh and benign environ

ments refer to the enviro

rl

mental characteristics in which the IAN needs to

I

operate. For example, in a harsh environment one might expect a wide range of operating tempe

rlu

ures or the presence of strong electromagnetic Added to the definitions were a number of

l

^fields.

I .

facts that customers stressed or that were of general use to the projec

�

. These facts were as follows:

I .

^. ^.^.

• Many customers had a variety of standard and nonstandard higher-le

�d

protocols running on their LANs. Clearl

�

, any solution had to take those existing protocols into account.

• Despite using nonsta

J

₁dard protocols, cus-tomers generally implemented their LANs _I with subsystems comp

�

iant with a standard, such as one of the IEEE

I

802 'tandards.

I

Physical

Environments

I

Frequency of Station Movement Benign

· Benign within a building Harsh between buildings Harsh

I

Occasional Possibly frequent

Rare

l

New Products

The Extended Local Area Network Architecture and LANBridge 100

• In addition to the valid technological and environmental reasons for choosing a particu

lar LAN technology, some customers had based their choices upon faulty assumptions.

This was particularly noted in discussions on the delay variance of token-based systems in various normal recovery modes.

• The importance of performance-monitoring · and serviceability features were emphasized almost universally by customers.

At this point it was clear that the original project goal of investigating only broadband technology was too narrow. Using broadband technology alone could not satisfy the broad requirements of the environments identified by the team . There

fore, the team expanded its scope to encompass the larger problem of providing a wide variety of services (terminal-to-computer, computer-to

computer, and real-time) in the three environ

ments (office, campus, and factory) .

It was also clear that there were two funda

mental approaches to providing those services.

First, the team could attempt to develop a LAN architecture, or enhance an existing one, that

· could cope with the wide range of nodes, dis

tances , media, performance, and cost con

straints . Second, the team could attempt to develop a mechanism for interconnecting the various LAN technologies.

LAN Tecbnology Alternatives

· The team decided first to evaluate a variety of suitable media access methods. Each alternative and the conclusions reached by the team are summarized below.

Carrier Sense Multiple Access with Collision Detection (CSMAjCDj 2

This was the alternative most familiar to the team members, since Digital was currently building products utilizing CSMAfCD for both baseband and broadband media. The performance of CSMA/CD does not degrade rapidly as a functio of the number of connected nodes (see Figure 1). However, its extent (maximum signal propa

gation path length), transmission rate, and mini

mum packet size are not independent because of fi nite propagation delays . 3 ·4 Therefore , to increase the physical extent of CSMA/CD LAN^, the minimum packet size or the transmission rate or both must be decreased to ensure that there are no undetected collisions.

Figure 1 Local Area Network Performance

Carrier Sense Multiple Access (CSMA)

By eliminating the collision detection capability of CSMA/CD, one can build a LAN whose trans

mission rate scales well with distance . However, the obvious benefits of collision detection will be lost. Without collision detection, the delay variance experienced by applications tends to increase because CSMA relies on more-frequent higher-layer protocol time-outs. To compensate for this problem, the transmission rate could be increased sufficiently to reduce the probability of collision. However, this action would impose significant cost penalties on the end stations, which would need faster logic and would experi

ence more difficult transmission problems.

Carrier Sense Multiple Access with Partial Collision Detection (CSMA ± CD)

Either the physical extent or the transmission rate of a CSMA/CD network could be extended so that collisions would be detected only if the col

liding stations were sufficiently close or if the packets were sufficiently large . Such a scheme would have good throughput-delay characteris

tics if the physical extent were small; however, degraded performance would result if the physi

cal extent were large. Unfortunately, this scheme yields a significant delay variance because the relative locations of the colliding stations and the size of the colliding packets now affect the

Token Passing Bus5

The characteristics of the token-bus access method scale reasonably well with physical extent (see Figure 1 ) , but poorly with the num

ber of nodes.3 This situation is complementary to that of CSMAjCD. The sensitivity of a token bus to the number of nodes makes it unsuitable for a single LAN with many nodes. The token bus, like CSMAjCD, is well suited to implementation on a CA1V-like cabie plant.

Token Ring6

The performance characteristics of the IEEE 802.5 token ring are somewhat similar to those of the token bus. However, an IEEE 802.5 token ring station will not reissue a token until the pre

viously transmitted frame has circulated com

pletely around the ring. This characteristic makes the ring more sensitive than a token bus to increasing physical extent. Moreover, a token ring cannot be applied directly to a branching

tree physical topology, such as the one in a CA1V-like cable plant.

Slotted Ring

The design tradeoffs made in most slotted rings result in small slots, usually less than 20 bytes.

Therefore, it is important to minimize the slot overhead, such as source and destination addresses and error detection fields. Such opera

tions are usually associated with connection

oriented services, such as voice transmission. In slotted ring networks, mechanisms are often present to impose a measure of "fairness" in the network. Those mechanisms make it difficult for an individual station to acquire a significant frac

tion of the instantaneous transmission rate. Such networks are often inadequate for handling the bursty traffic expected in the environments of interest.

Time Division Multiplexed (TDM) Bus

The principal disadvantages of using a TDM structure are that the number of time slots is fixed, and each time slot is assigned to only one station. Thus, with a large number of stations, even with low network utilization, the mean waiting time is large. Furthermore, since the bus is allocated in tum to each station, the maximum throughput of any station is limited to the data transmitted in that station's slot. The TDM bus is well suited to isochronous traffic, such as voice or video.

Digital TecbnlcalJournal No. 3 September 1986

Frequency Division Multiplexed (FDM) Bus The characteristics of an FDM bus are somewhat similar to those of the TDM bus. The FDM bus has an additional degree of freedom in that it could have slots of different bandwidths. The problem with the FDM bus, however, is logical connectiv

ity. To have full connectivity, each node must monitor each frequency band for messages des

tined for that node. In practice, this monitoring is prohibitively expensive.1As an alternative, one could apply a reservation' system to either the TDM or FDM buses. The dharacteristics of such an approach, however, arej much better suited to a connection-oriented ser\rice, such as voice or _I video, rather than one with bursts of data. _.

I. I

Hybrid of FDM and CSM

1

^fCD

A hybrid scheme utilizing multiple slow-speed (approximately 1 million bits per second, or Mbps) CSMAjCD channels, each in its own 6-MHz band, is another specific alternative that was considered. Without increasing the mini

mum packet size used in an Ethernet, each CSMA/CD channel can span an extent of approx

imately 30 kilometers. Multiple CSMAjCD chan

nels could be used to increase the aggregate capacity of the network. Unfortunately, logical connectivity cannot be achieved without some mechanism for switching packets between these channels. Furthermore, th� bandwidth available to any station is limited to a rate of 1 Mbps. Since there is no industry standard for a 1 -Mbps, 6-MHz CSMAjCD LAN, selecting;this approach would make necessary an attempt to standardize it.

These evaluations con

}r

inced the team that none of these access methods sufficed for build

ing a single LAN capable bf successfully operat

ing in all dimensions of interest to the project.

Not one of these alternatives was capable of directly employing all the types of media that the customers wished to utilize. Furthermore, any choice was constrained , by the desire for an access method with a defined standard having the appropriate parameters. The project team would have to find a way to interconnect at least a subset of the standard LANs if the project were to be successful.

LAN Interconnection Alternatives The team next investigated a variety of intercon

nection methods, each of which had certain advantages and drawbacks.

New Products

The Extended Local Area Network Architecture and LANBridge 1 00

DECnet Router

The architecture for DECnet Phase IV+ could be used to create a DECnet network for the inter

connection. Such a network would be fully capa

ble of handling the number of nodes needed in any of the three environments of interest. In fact this was quite an attractive alternative . One could choose the data links in such a network to optimize the cost and performance. For exam

ple, Ethemets placed in local areas could offer good response at low and moderate network loads. Then a token bus, with its capability to handle high utilizations and large extents, could be used as a backbone to i nterconnect the routers. Those would in tum connect to the Eth

emets. The sensitivity of the token bus to large numbers of nodes would be minimized since the only nodes on the token bus would be the routers. Unfortunately, not all customer nodes use the DECnet routing protocol, making this alternative useful for only a subset of the nodes in a network.

Central Switch

To complete the logical connectivity of a net

work composed of multiple LANs, the team con

sidered an architecture organized around a cen

tral switch element. Conceptually, the switch could be connected to all LANs in the network and then selectively forward packets to the LAN with the destination end station. This alternative has most of the advantages of the DECnet router solution discussed above. Normally, however, all end stations need the same routing protocol. To avoid this problem the switch must either sup

port a variety of routing protocols (and translate among them) or somehow perform its switching task in a way transparent to the end stations. A single switch of sufficient capacity and reliabil

ity to do either task was likely to be fairly com

plex to design and manufacture_ It would also need to scale in a cost-effective manner for a wide range of networks.

Bridge ⁷^•8^•9

A bridge, or MAC layer relay, is a device connect

ing two or more LANs so that a node on one LAN may communicate with a node on another' just as if they were on the same IAN. In operation, a bridge is a store-and-forward switch that isolates traffic to only those IANs on which the traffic must appear. For example, in Figure 2 , traffic between nodes X and Y would not appear on the

LAN to which node Q is connected. Bridges make use of data link layer addresses to make forward

ing decisions. A bridge receives all frames from a particular LAN and then decides, based upon the destination address in the MAC header, whether to forward each frame.

A collection of LANs interconnected by bridges is referred to as an extended IAN. In general, bridges may be used to connect LANs of different types, as shown in Figure 2. Therefore, this alter

native can successfully utill.ze diverse LAN tech

nologies, if appropriate, to optimize some func

tion (e .g., low cost, high performance, or a

combination of these) . Furthermore, a bridge appears to be merely another station on each LAN to which the bridge is connected. Therefore, multiple IANs, each fully configured, can be connected to eliminate their practical con

straints on distance, number of nodes, media, and utilization.

Based on the reasoning above , the team selected the bridge alternative as the one best suited to realize the expanded goals of the pro

ject. Thus the team began to develop an architec

tural specification for extended LANs and bridges. The team also began to develop a work

ing breadboard model that eventually led to the IANBridge 1 00 product. The architecture that was evolved for extended IANs and bridges is described in the next section.

�

AREA NETWORKS ^lOCAL

Figure 2 Bridged Network Configuration

Digital Tecbnical]ournal No. 3 September 1986

Advantages of Bridges

Bridges used to connect IANs have several useful properties:

• Traffic Filtering - Bridges isolate each IAN from traffic that does not have to traverse that IAN. For example, in Figure 2 , traffic between nodes A and B is not sent on the IANs to which P and Q are connected. Because of this filter

ing, the load on a given IAN can be reduced, thus decreasing the delays experienced by all users on the extended IAN.

• Increased Physical Extent - IANs are limited in physical extent (at least in a practical sense) by either propagation delay or signal attenuation and distortion. Being a store

and-forward device, a bridge forwards frames after having gained access to the appropriate IAN via the normal access method. In this way the extended LAN can cover a larger extent than an individual IAN. The penalty for this coverage is a small store-and-forward delay.

• Increased Maximum Number of Stations -Because of either physical layer limitations or stability and delay considerations, most IAN architectures have a practical limit on the

Im Dokument Digital TechnicalJournal Digital Equipment Corporation (Seite 55-74)