GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien143

M.I.T. Laboratory for Computer Science IEN 143

                                                        March 11, 1980

Environment Considerations for Campus-Wide Networks

by Jerome H. Saltzer

"The Campus Environment" is a name proposed here to identify a

particular set of physical properties, geographical extents, data

communication requirements, administrative relationships, and needs for

flexibility that characterize our university campus. With only minor

exceptions they equally apply to a corporate site, a government complex,

or another university. This note discusses seven characteristic

properties of this campus environment. These seven properties provide a

basis for design decisions for a data communication network to span a

campus. As will be seen, the properties of this environment are quite

different from those of a single building, or of a nation-wide,

common-carrier-based network.

Seven Properties of the Campus Environment

1) It has a geographical extent beyond a single building, but within a

   single political and administrative boundary that permits
   transmission media to be installed without resort to a common
   carrier.

This first property is essential, so as to allow exploitation of

low-cost, high-bandwidth communication technology. With current

technololgy and prices the difference in costs between communicating

over privately installed equipment and using common carrier facilities

can be a factor between 10 and 100.

2) Within this geographical area, a large number of nodes–that is,

                                 2
   computers, data sources, and data sinks--require interconnection.
   Today the number of such nodes may be in the range of ten to one
   hundred. Looking ahead to the advent of desktop computers, one may
   be faced with from a few hundred to several thousand nodes by the
   end of the next decade.

The combination of the previous two properties seems to make it

inevitable that local interconnect technologies such as the ETHERNET,

CHAOSNET, L.C.S. Ring net, HYPERCHANNEL, or MITRENET cannot by

themselves completely accomplish the required interconnection, since all

such technologies that have so far been demonstrated have limitations on

distance on the order of a thousand meters and limitations on node count

on the order of a hundred nodes. Thus one would expect to use those

technologies to attach clusters of nodes into subnetworks, for example

all the nodes in a single building, and then install interconnections

(gateways) among these subnetworks. For our own campus, one might

envision by 1990 as many as 100 subnetworks each comprising an average

of, say, 100 nodes. Subnetworks and gateways introduce the problem of

how to route a message from a source node through a series of

subnetworks and gateways, so that it ends up at a desired target node.

3) Administratively, there exist forces both for commonality and for

   diversity of network attachment strategies. The primary force for
   commonality is a desire to be able easily to set up communications
   between any pair of nodes on the campus. The primary force for
   diversity is that the choice of a computer, data source, or data
   sink typically pre-determines the technology of the network to
   which it must be attached, because off-the-shelf network hardware
                                 3
   for that node may be available in only one technology. Further,
   some applications may have special requirements for some
   connections (e.g., high bandwidth) that can be met only with a
   particular network supplier's equipment, yet still need occasional
   "ordinary" connections to nodes elsewhere. Thus the emerging
   diversity of local networks will continue, and probably increase,
   rather than decrease, with time.

4) The worldwide academic, commercial, and regulatory community has

   not yet reached anything resembling a consensus on how functions
   should be divided. Arguments range over issues ranging from obscure
   matters of taste, through fundamental technical disagreements about
   which requirements should have priority in design, to alternative
   opinions of the directions that communication technology is moving.
   Many different and competing standards have been proposed, and one
   can find in the literature a good technical case against any one of
   them. One must anticipate that these arguments will be reflected
   internally in the campus environment, in the form of a diversity of
   protocols and standards, and particularly in the requirement that
   any mutually consenting set of nodes be able to carry on
   communication with one another using a protocol that no one else
   has ever heard of, much less agreed to.  [Imagery borrowed from a
   Chaosnet working paper by David Moon.]

This fourth requirement suggests strongly that any network

interconnection strategy that must be implemented today should have a

campus-wide lowest layer of protocol that accomplishes datagram passing

between any two nodes while making an absolute minimum number of

                                 4

assumptions about the nature of the higher-level communications that are

taking place or the policy of network administration. Some typical

assumptions that should be avoided unless an unusual opportunity is

obvious are: what level of reliability/delay tradeoff is appropriate;

how routing should be optimized; fragmentation/reassembly strategy; flow

control requirements; addressing plan; and particular network topology.

5) Because a data communication network is a campus-wide service,

   there will be no single user or user group with a wide-enough
   interest to administer the entire network. This means that network
   administration will either be done by a haphazard confederation of
   special interest groups or else by a chronically underfunded
   central service organization modeled on the one whose role is to
   minimize telephone costs.

In either case, this property places a requirement on the network

interconnection technology that it be robust and self-surviving to every

extent imaginable. Trouble isolation must be easy to accomplish and easy

for individual users to participate in if they are so inclined, because

trouble isolation and repair may involve multiple administrations.

Simplicity of operation of gateways is important, so that operation can

be completely unattended for long stretches of time. A network design

approach that requires close monitoring is undesirable.

6) The topology of subnetwork interconnection will be administered

   partly with central planning and partly without. This property
   arises from two needs: First, a "dependable" set of gateways that
   one can expect to exhibit predictable and stable properties is an
   essential backbone to a useful service. A centrally planned and
                                 5
   administered set of gateways would provide this dependability.
   Second, whenever a node finds that for some reason it is attached
   to two subnetworks, it may find that it is useful in some of its
   applications to serve also as a gateway between the subnetworks;
   yet it may not want to take on the official responsibility of being
   a publicly available gateway. Another example of a gateway that is
   not centrally administered may arise if some particular application
   needs, and has purchased the gateway equipment to support, a path
   through the network with special properties of delay, reliability,
   bandwidth, or privacy. The person or organization that has
   purchased the special gateway equipment may not be prepared or
   willing to allow public use of it. Alternatively, a user may wish
   to avoid use of a sometimes troublesome gateway that is claimed by
   its owner to be perfectly operating.

7) External networks such as TELENET, the ARPANET, TYMNET< XTEN, SBS,

   or A.C.S., may be attached to some nodes, and some of those nodes
   will serve as gateways between the campus network and the external
   networks. In some cases, the external network will be used simply
   as a "long link" in the campus net. In other cases, facilities
   within the campus net will set up communication paths to services
   having no other connection with or knowledge of the campus net.
   Both kinds of cases require careful consideration of the
   interactions between internal and external network properties.

Note that the campus environment has all these properties only if we

assume the technological opportunity mentioned in point one: that

low-cost hardware and media can provide communication paths in the range

                                 6

from 1 to 10 Mbits/sec. between any two points within the campus.

Availability of interconnect media and subnetworks with this bandwidth

has been demonstrated in several forms. Gateways that operate with such

bandwidths may be harder to construct, and that concern is one of the

considerations involved in developing a campus-wide net. Individual

nodes that can sustain these data rates for very long are likely to be

rare; software often limits the rate at which a mode can act as either a

data source or data sink. Instead, the high bandwidth technology is to

be exploited in two ways:

 1)   to provide enough capacity to handle the aggregate demand of
      many lower-bandwidth sources and sinks of data.
 2)   non-optimal strategies that are relatively simple to implement
      or administer can be considered; it is not a requirement that
      every bit of the available band- width be optimally utilized.

The availability of high bandwidth, together with lack of a requirement

to use that bandwidth efficiently, is probably the most fundamental

technical difference between the "campus-wide network" and the

commercial long-haul data communication network, a difference that can

lead to significantly different design decisions. Future notes in this

series will explore some of these specific technical design

consequences.

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien143.txt · Last modified: 2001/06/25 19:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki