home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ien
/
ien-184
< prev
next >
Wrap
Text File
|
1988-12-02
|
49KB
|
1,659 lines
IEN 184
ISSUES IN INTERNETTING
PART 1: MODELLING THE INTERNET
Eric C. Rosen
Bolt Beranek and Newman Inc.
May 1981
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
ISSUES IN INTERNETTING
PART 1: MODELLING THE INTERNET
1. Modelling the Internet
This is the first in a series of papers which attempt to
deal with the problems of internetting in a comprehensive manner.
By "internetting", we mean the establishment of data
communications among some set of host computers which cannot all
access the SAME data communications network (though we will, of
course, require that each host be on some particular data
communications network). The traditional approach to getting
data from a host on one network to a host on another is to pass
the data through an intermediate, or "gateway", host, which is a
host on both networks. As we shall see, however, building an
internet which is sufficiently robust, and which offers
sufficiently high performance, to be useful in day-to-day data
communications operations involves much more than simply pasting
networks together in a pairwise manner. Rather, it requires us
to build an entirely new network, which can be regarded as being
hierarchically "above" the existent data communications networks.
We shall see that building this new network is no simple task,
but that it raises all the same issues that one must deal with in
building any sort of data communications network. Our basic
approach will be to consider SYSTEMATICALLY the ways in which an
internet is and is not similar to "ordinary" data communications
- 1 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
networks, so that we can easily see how the knowledge we have
gained from studying such networks (in particular, the ARPANET)
can be applied to internetting. This paper will present a model
for the internet which will help us to organize the issues;
further papers will deal more explicitly with such issues as
internet access, addressing, routing, and congestion control.
1.1 The Model Described
We begin by introducing a very general model for a class of
abstract entities called NETWORK STRUCTURES. A Network Structure
consists of three kinds of entities: SWITCHES, PATHWAYS, and
HOSTS. When we say that a particular entity is a Host WITHIN
SOME PARTICULAR NETWORK STRUCTURE, we mean that within that
Network Structure it functions as a data sink and/or source, and
does not perform such functions as store-and-forwarding traffic
which originated elsewhere and is destined for elsewhere. By
saying that a certain entity is a Switch WITHIN A PARTICULAR
NETWORK STRUCTURE, we mean that, within that Network Structure,
it is responsible for store-and-forward functions, i.e., for
receiving data from a source Host, and sending it (possibly
through a sequence of intermediate Switches) into a destination
Host. A Pathway WITHIN A PARTICULAR NETWORK STRUCTURE is a
communications path which has as one endpoint a Switch of the
Network Structure, as its other endpoint either a Switch or a
Host of that Network Structure, and NO intermediate Switches of
that Network Structure.
- 2 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
It is important to understand that the notion of a Network
Structure is intended to be an abstraction which we use in order
to impose a conceptual organization on a set of physical
entities. It makes no sense simply to ask of some particular
computer, is it a Host or a Switch, unless one also references
some particular Network Structure. Saying that a computer is,
e.g., a Switch, attributes to it a certain functionality relative
to a certain Network Structure. A particular computer might well
be a Switch in one Network Structure while simultaneously being a
Host within another Network Structure. (We will capitalize the
terms "Host," "Switch," "Pathway," and "Network Structure" as a
reminder of the abstract nature of these terms.)
Let's look at some examples. The ARPANET can be regarded as
a Network Structure whose Switches are the IMPs, whose Pathways
are the telephone lines that connect the IMPs, as well as the
1822 and VDH lines, and whose Hosts are the devices connected to
the IMPs via either the 1822 or VDH interfaces. From the
perspective of this Network Structure, the Pathways (telephone
lines) have no internal structure, but rather are merely a
passive and transparent medium. When we say that the Pathways
have no internal structure, we mean simply that they contain no
intermediate Switches (i.e., IMPs) and no Hosts of the particular
Network Structure (the ARPANET) under discussion. Of course,
this is quite a significant abstraction. What we regard as a
simple wire (a telephone line) may in fact be no wire at all, but
- 3 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
an entire network, the telephone network! Within the telephone
network, there may be any number of fancy computer switching
devices, which might be just as complicated as the ARPANET's
IMPs. From the perspective of the telephone company, one might
want to regard each telephone line as a Network Structure, which
contains exactly two Hosts (viz., the two IMPs at the end-points
of the line). The Switches of this Network Structure are the
telephone switching devices, and the Pathways really are just
wires. Or, if we had reason to, we could regard the ARPANET as a
sort of hybrid Network Structure, whose Switches included both
the IMPs and the telephone company switching devices, and whose
Pathways were wires terminating either at the IMPs or the other
switching devices. As it happens, we generally don't find this
last means of conceptual organization to be very useful. Since
we have no control over, and little information about, the
telephone company switching devices, it is most "convenient" not
to have to think about them, but rather to just regard each
telephone line as a simple Pathway, with no internal structure,
and no intermediate Switches. It is important to understand that
calling the ARPANET a Network Structure whose Switches are IMPs
and whose Pathways are telephone lines does not beg any questions
about how the telephone network really works; it is just a matter
of imposing a conceptual organization that we find useful for
some purpose.
- 4 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
Of course, the telephone lines are not the only Pathways in
the ARPANET. Each (local or distant) host is also the endpoint
of a Pathway, though one which really is a wire. In general, we
will find it useful to distinguish those Pathways in a Network
Structure which connect Host to Switch (ACCESS PATHWAYS) from
those which connect Switch to Switch (INTERNAL PATHWAYS).
Another example of a Network Structure is one whose Switches
are the gateways on the ARPA Catenet, whose Pathways are segments
of ARPA-controlled networks, and whose Hosts are hosts on the
networks which are part of the Catenet. Within this Network
Structure, the gateways must be regarded as Switches, since they
perform store-and-forward functions, and data from one host to
another is routed through a sequence of gateways. Of course, a
gateway, while a Switch within the Network Structure of the
Catenet, may also be a Host within the Network Structure of the
ARPANET. The proper classification of an entity is a matter of
what function it performs within the concrete realization of some
particular Network Structure; the same physical entity may
perform different functions in different Network Structures of
which it is a part.
We should be a bit more precise about the Pathways of the
Catenet Network Structure. Suppose there are 4 gateways on the
ARPANET. Then the gateways are fully connected through a set of
12 distinct Pathways (i.e., each gateway has a Pathway to each of
- 5 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
the other 3 gateways). Although each of the 12 Pathways utilizes
the ARPANET, we really have 12 distinct Pathways, each of which
has different characteristics as regards delay, throughput, and
operability. That is why we said above that the Pathways of the
Catenet should be identified with SEGMENTS of ARPA-controlled
networks, rather than with the entire networks. Furthermore,
each of the 4 Gateways has a distinct Pathway to EACH host on the
ARPANET. That is, within the Network Structure of the Catenet,
each of the hosts on the ARPANET (all of which are also Hosts on
the internet) is MULTI-HOMED to each of the 4 Gateways via a
distinct Pathway. IN PRINCIPLE, THIS MULTI-HOMING IS NO
DIFFERENT THAN THE MULTI-HOMING OF A SINGLE (LOGICALLY ADDRESSED)
HOST TO TWO DIFFERENT ARPANET IMPS (see IEN 183). As we shall
see, regarding all the Hosts on the Catenet as being multi-homed
to the Switches (i.e., gateways) of the Catenet is a very
important feature of the network architecture we will propose for
internetting. We will argue that many of the problems
encountered in the current Catenet configuration are a result of
the failure to properly conceive internet hosts as being
multi-homed, and that the lessons learned from a study of how to
do multi-homing on individual packet-switching networks can be
applied fairly directly.
The "Network Structure" model is intended to be completely
general. We can, for example, handle an arbitrarily nested
hierarchical internet by establishing a Network Structure whose
- 6 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
Pathways are themselves complex internet configurations. We can
also model overlapping internet configurations. Consider, for
example, four machines, A, B, C, and D connected in order in a
ring. In principle, we could treat this as two Network
Structures, one in which A and C are Switches and B and D are
Hosts, and another in which B and D are Switches and A and C are
hosts. This might be useful if, for example, we have two
different internets, with incompatible gateways, connecting the
same set of packet-switching networks. The model should be
general enough to accommodate complex configurations like this.
1.2 Deficiencies of the Old Model
The idea that the design of an architecture for the internet
should be guided by the development of an abstract model is
hardly original. The earliest IENs often considered the need for
a model, but the discussion there seems to be at an insufficient
level of abstraction. That is, there is much discussion of the
need for a "model of a gateway," but no discussion of the need
for a model of the internet as a gestalt, with a network
architecture of which the gateways are only a part.
It is apparent though that gateway designers and
implementers did work with an IMPLICIT model of the internet in
mind. While the gateway was the focus of much discussion,
however, little critical attention was focussed on the implicit
model of the internet itself. This implicit model represents the
- 7 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
gateways as ordinary network nodes, and the component networks of
the internet as ordinary network lines. Surprisingly, hosts are
not represented at all in this model. (One may be tempted to
think of a host as a sort of piece of one of the "lines" in this
model, but remember that the lines are not supposed to have any
internal structure.) The internet routing problem was conceived
of as the problem of how to get data from one gateway through a
sequence of intermediate gateways to a destination network
(which, in the model, is a destination line!?).
Our experience with the Catenet should have made it quite
clear by now that the basic idea underlying this implicit model
is overly simplistic. This basic idea is that the end-user will
know what network his destination host is attached to, and only
needs the gateways to get his data somewhere or other (it doesn't
matter where) on that destination network. At that point, the
destination network is supposed to take over, and there is no
further work for the gateways to do. We now know, of course,
that things are not so simple. The way in which the gateways get
traffic to the destination network may be very important. A
particular host on a particular network might be reachable from
one gateway on that network, but not from another gateway on that
network. (This is the "partitioned net" problem.) Or
performance considerations might dictate that a host be reached
through one gateway in preference to another gateway on that same
net. It should not be any surprise that this sort of problem has
- 8 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
proved very troublesome in the Catenet, for the problem is built
right into the conceptual mechanism that guided the development
of the Catenet. The fact that the old implicit model of the
internet contains no representation at all of hosts makes it
virtually impossible for gateways that were built with that model
in mind to have any means of representing host-specific
information. It also makes it virtually impossible to take
advantage of (or even to take cognizance of) the way in which
Hosts can be regarded as being "multi-homed" to the gateways.
Failure to model the hosts also makes it difficult to handle the
case of hosts which are not always connected to the same network
(e.g., "mobile hosts"), or hosts which are connected to two or
more networks.
Further difficulties arise from the way in which networks
are represented as "lines." If a network is like a line, then it
must be either up or down. There is no way to represent the fact
that some "parts" of the "line" can be reached from only one
end-point, but not the other. That is, it is difficult to make
the internet system respond to peculiarities in the behavior or
operational status of the underlying packet-switching networks,
since much of that behavior has no analog in the world of
telephone lines. Of course, it cannot really be claimed that
problems like these can never be resolved at all within the
current Catenet configuration, but only that possible resolutions
will not fit easily into the Catenet's architecture, and so will
- 9 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
generally appear to be "kludges" or "hacks" which are grafted on
in order to get around particular operational problems as they
happen to arise. Perhaps a reading of some of the more recent
IENs will bear out this impression.
In attacking the old implicit internet model, we are not
simply trying to beat a dead horse, or to attack a straw man.
Rather, we are just trying to emphasize that the way in which one
initially models or thinks of a set of related problems will
necessarily have a large effect on the way the problems are dealt
with in the final system. A good model for the internet should
provide a framework for discussion of internetting issues which
enables us to place each issue in proper perspective, and which
makes clear the inter-relationships among the various problems
and proposed solutions to them. When important problems (such as
the "partitioned net" problem) cannot even be stated in the terms
of a particular model, it becomes clear that that model does not
provide a proper framework for the discussion of the issues. A
good model should also make it possible to evaluate the effect of
various schemes as part of an integrated system, making it easier
to determine whether or not some proposed scheme gives rise to
more problems than it solves. By allowing us to see solutions to
particular problems as part of an integrated system, the model
also gives us a means of choosing among different schemes which
seem to solve the same problem, since some of those schemes may
fit more easily or more naturally into the integrated system than
- 10 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
do others. A good model should also suggest solutions to
problems that have previously seemed very vexing (we shall argue,
in subsequent papers of this series, for example, that
representing hosts as being multi-homed to gateways suggests
certain addressing schemes that might otherwise be overlooked,
and also subsumes a number of problems previously thought
unrelated under a common rubric). We believe that the model we
proposed in the previous section offers a much more coherent
framework; hopefully this will become apparent as we begin to
work through the issues of internetting in this and subsequent
papers.
1.3 The Importance of Pathway Characteristics
As we have already pointed out, the proposed new model of
the internet as a Network Structure allows us to see the ARPANET
itself as an internet, built upon pieces of the telephone
network. In principle, then, the ARPANET is no different than
the Catenet, which is an internet built upon pieces of the
ARPANET, SATNET, and various other ARPA-controlled networks. Yet
it does seem that the Catenet poses problems which are more
difficult and less tractable than are the problems posed by the
ARPANET. Why should this be the case, if the ARPANET and the
Catenet are both internets of a sort? The answer seems to lie in
the characteristics of the individual networks that constitute
the Pathways in these two different "internets." The pieces of
- 11 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
the telephone network which transmit data within the ARPANET do
so with well-known and well-understood (indeed, with constant)
delay characteristics. The capacity of these pieces of the
telephone network is also a constant. Many of the ARPANET's
protocols and algorithms (both internally and at the host access
level) make use of these facts, and break down when applied to
Pathways of significantly different characteristics. Even within
the ARPANET, we have seen the importance of modifying our
protocols and algorithms to take account of differing Pathway
characteristics. For example, the line up/down protocol which
each pair of neighboring IMPs runs together to determine the
operational status of the line connecting them must be tuned
differently for lines of differing bandwidths or propagation
delays. Particular difficulty has been encountered in making
this protocol work properly over "line 77," the "transparent"
connection via SATNET to London. One problem in trying to extend
ARPANET-like protocols and algorithms to the Catenet environment
is to come to a better understanding of how those protocols and
algorithms actually depend on assumptions about the Pathway
characteristics. Since many of these assumptions may be
implicit, and nowhere clearly stated, this is not a simple
problem. As we develop our proposed internet architecture, we
will try to emphasize the role played by assumptions about
Pathway characteristics.
- 12 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
(Although we will be primarily concerned with protocols and
algorithms to be used in the actual day-to-day operation of the
internet, it is worth noting that the variability of the Pathway
characteristics of the internet also has implications with
respect to the topological layout of the internet. When
designing the topology of a packet-switching network, one often
makes use of mathematical tools (often automated) for optimizing
the topology with respect to some cost-function, such as delay.
These mathematical tools are based on particular mathematical
models of networks which in turn are based on results from
queuing theory which assert a particular relationship between
delay and load over telephone lines. Whatever the merits of
those mathematical models (and there is much to question in
them), they will not be applicable at all to the topological
design of the internet. When a Pathway is a packet-switching
network, rather than a telephone line, it is probably meaningless
even to ask what its bandwidth is, since it just does not have a
constant bandwidth. That is, the maximum throughput that can be
obtained between two gateways over a particular packet-switching
network will vary quite a bit over time, and will depend on what
happens to be going on within that network. In addition, the
relationship between delay over a packet-switching network and
the offered load is much more difficult to model mathematically
than is the same relationship over a telephone line. Issues of
how to properly lay out the topology of the internet to obtain
- 13 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
best performance or least "cost" probably will not be able to be
dealt with in any systematic way until we have much more
experience with day-to-day internet operations.)
The gateways which are currently deployed on the Catenet do
not seem to take Pathway characteristics into account at all.
Certainly there has been no attempt to optimize the gateways to
the particular packet-switching networks that they are connected
to, or even to make the gateways take proper notice of the
various protocol messages that the networks will send to the
gateways. To some extent, gateways really do seem to treat
packet-switching networks as mere wires, simply throwing the bits
at the network interface, and not dealing with the various
exception states that continually arise when attempting to access
a network. One of the main themes that we shall be developing is
that A ROBUST AND HIGH-PERFORMANCE NETWORK STRUCTURE JUST IS NOT
POSSIBLE UNLESS THE SWITCHES ARE CAREFULLY TUNED TO MAKE THE MOST
EFFICIENT POSSIBLE USE OF THE PATHWAYS. As we have stated above,
the ARPANET IMPs often have to be tuned to the particular
characteristics of different telephone lines, and it is that much
more important for the gateways to be tuned to the particular
characteristics of the packet-switching networks that serve as
Pathways between them. It is important to understand that this
sort of issue does not apply only to the way in which gateways
use the INTERNAL PATHWAYS of the internet, but also to the way in
which hosts and gateways use the ACCESS PATHWAYS of the internet.
- 14 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
We will develop these issues in much more detail in subsequent
papers.
We have claimed that the only reason we tend to regard the
telephone network as a Pathway with no internal structure is that
we find it "convenient" to do so. If we are going to properly
apply the Network Structure model to the ARPANET, the Catenet, or
any other networking or internetting environment, it is important
to come to a clear understanding of just when it is and is not
"convenient" or "useful" to ignore the internal structure of a
communications medium, and model it as a Pathway. (Though
ignoring the internal structure of a communications medium is NOT
the same thing as ignoring its delay/throughput/reliability
characteristics; as we shall repeatedly emphasize, there are no
conditions under which it is possible to do that without
incurring extreme penalties in efficiency and/or reliability.)
There are basically two good reasons why we might want to ignore
the internal structure of a communications medium:
1) Efficiency. Some algorithms or protocols in the Network
Structure may need to be driven off some sort of model or
representation of the network. For example, the SPF
routing algorithm in the ARPANET has a database which
represents the network topology. (We will often use the
term "SPF routing" to refer to the ARPANET's current
routing algorithm [1,2], in contradistinction to the
- 15 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
ARPANET's original routing algorithm [3]. The Catenet's
current routing algorithm is based on the original
ARPANET routing algorithm, but internetters should be
aware that that algorithm had a number of serious
deficiencies, especially under heavy load, and was
removed from the ARPANET over two years ago, to be
replaced with SPF routing.) Dividing a single network
into several different Network Structures, and
representing some of those as Pathways with no internal
structure, may be necessary if we need to keep a bound on
the size of the database while allowing the actual
physical configuration of the network to grow without
bound. This is one of several important considerations
driving the internet development.
2) Partial transparency. One may want to be able to replace
the networks which underlie certain Pathways without
having to make extensive changes to the software of the
Switches. Or one may simply not be able or willing to
get any information about some underlying network.
Either of these is a good reason to try to treat that
underlying network transparently. Note, however, that
the best that we can hope to achieve is PARTIAL
transparency. If a Pathway is replaced by another
Pathway of very different characteristics, we cannot
realistically expect to maintain efficient performance
- 16 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
without modifying the Switches in some way to take
account of the new characteristics. However, it may be
possible to restrict the magnitude of the changes; for
example, perhaps only the software in the Switches which
are the endpoints of the Pathways will need to be
changed. This is an issue that we will have to consider
in great detail; certainly it is one of the most
important considerations driving the internet effort.
Note that these considerations, important as they may be, are
really just matters of degree, and generally must be traded off
against other considerations. We can ignore the internal
structure of a Pathway to a greater or lesser degree. It is
possible, for example, that we will want our internet gateways to
exchange information with certain ARPANET IMPs, even though in
general we want the internet gateways to be able to ignore the
internal structure of the ARPANET. The principle of ignoring the
internal structure of a Pathway is supposed to be a tool to help
us, not a straitjacket to prevent us from getting needed
information. This is another issue to which we shall return
repeatedly in subsequent papers of this series.
One of the aspects of a Network Structure that is most
sensitive to Pathway characteristics, and to the decision to
ignore the internal structure of a Pathway, is its
MAINTAINABILITY. Maintainability is one of the most important,
- 17 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
though most neglected, areas of network design. In the long run,
the ability to maintain the network (which means the ability to
isolate faults and to repair them) can have a much larger effect
on the network's efficacy as a communications utility than almost
any other consideration. In some sense, maintainability is the
"bottom line;" if a network is subject to repeated inexplicable
failures and degradations, then the users will be driven away,
and all the effort that has gone into careful optimizations of
the algorithms and protocols will have been wasted. In a complex
Network Structure, which may include Pathways of arbitrary
internal complexity, maintainability is a very crucial issue. A
good example of the kinds of problems that can arise may be taken
from our experience with the ARPANET's line 77 (the "transparent"
connection to the London-TIP via SATNET). The ARPANET generally
treats this as if it were a telephone circuit, even though it
actually consists of a large number of terrestrial access lines,
SIMPs (SATNET nodes), and satellite broadcast facilities, any
component of which might fail in its own peculiar way. When this
special connection was installed, the intention was that it be as
transparent as possible to the ARPANET. It turns out, however,
that a side-effect of treating SATNET transparently is that IT
ALSO BECOMES TRANSPARENT TO THE FAULT-ISOLATION TECHNIQUES WHICH
ARE USUALLY USED FOR TROUBLE-SHOOTING ARPANET LINES. That is,
the usual fault isolation techniques do not see into the
structure of this "line", and hence can say no more than that the
- 18 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
line is up or down. While this is a consequence of the
transparent design, it causes great difficulty, especially since
the various components of this line are maintained by different
organizations, each of which prefers to believe that the problem
is someone else's responsibility. Furthermore, since the IMPs at
each end of the line (which are also Hosts on the Network
Structure of SATNET) don't realize that they are actually
accessing another network, and don't use the usual network access
protocol for SATNET, some of SATNET's standard fault isolation
techniques are bypassed too. A problem that has been recurring
with some frequency is that the ARPANET's line up/down protocol
just will not bring the SATNET "line" up, even though SATNET
itself seems to be working fine, according to the independent
SATNET monitoring. At one time, the team of ARPANET and SATNET
people working on the problem originally seemed to be in
agreement that the source of the problem was in the design of the
ARPANET's line up/down protocol. On further investigation,
however, it turned out that the real problem was that the
terrestrial access line between the London-TIP and one of the
SIMPs really was experiencing intermittent failures, and hence
that the ARPANET's protocol had been performing correctly when it
refused to bring the SATNET "line" up. However, since neither
the SIMP nor the London-TIP (really a host on SATNET) treated
this access line as SATNET-host access lines are normally
treated, the SATNET people found it very difficult to test this
- 19 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
line by itself in order to do fault isolation. If we have a
Network Structure whose Pathways can themselves be arbitrarily
complex and nested internets, then this sort of problem can be
expected to arise with great frequency, UNLESS PROPER
INSTRUMENTATION AND FAULT ISOLATION MECHANISMS ARE DESIGNED INTO
THE NETWORK STRUCTURE FROM THE VERY BEGINNING. To some extent,
some of these problems may just be inevitable once we decide to
ignore the internal structure of a Pathway. The extent to which
this is or is not true is a very important issue for us to
consider, since it may ultimately be one of the most important
factors in determining whether a reliable, operational, flexible,
and growing internet configuration is really feasible. We will
try to keep maintainability issues in mind throughout our entire
discussion of the internet architecture that we propose.
To a lesser extent, this sort of problem can occur even
purely within the ARPANET. Since ARPANET links are really pieces
of the telephone network, it is worth asking whether the
transparency of the telephone network impacts our ability to
maintain the ARPANET. In fact, this does sometimes cause
problems. When the ARPANET Network Control Center complains to
the telephone company that a line is not operational, they really
cannot provide the telephone company with very much data as to
what is really wrong. Sometimes it takes the telephone company a
long time to fix the problem, and it is not uncommon for the
telephone company to claim that a line is fixed and to return the
- 20 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
line to the ARPANET, after which it is discovered that the
ARPANET's line up/down protocol still will not bring it up
(because the packet error rate is too great). Yet the situation
is generally acceptable -- the ARPANET itself does a good enough
job of detecting when there are problems with the lines, and the
phone company does a good enough job (generally) of fault
isolation within their own network to be able to fix problems
relatively quickly. However, in a Network Structure whose
Pathways consist of packet-switching networks, rather than
telephone lines, we probably wouldn't be so lucky. The more
complex and poorly understood the Pathways actually are (and the
behavior of packet-switching networks, not to mention internets,
is still quite poorly understood), the less likely it is that a
simple complaint to the maintainer of the Pathway will get timely
results. As the Pathway characteristics become more and more
complex, it will become more and more important to have
instrumentation at all levels, including the Switches and Hosts
at Pathway end-points, to aid in diagnosing possible problems.
As much as we might want to be able to regard the Pathways as
fully transparent, it may turn out that the sort of
instrumentation needed to help in fault isolation is dependent on
the particular characteristics of the Pathway. This is another
issue that we will have to keep in mind throughout.
Wherever possible, as we develop our proposed internet
architecture, we will try to "parameterize" the effect of Pathway
- 21 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
characteristics on the robustness and performance of the
architecture. It will certainly be important to know whether it
is really possible to build a robust high-performance Network
Structure out of Pathways with totally arbitrary characteristics
(probably not), and if not, just how many constraints we must put
on the Pathway characteristics in order to get reasonable
performance out of our architecture. This approach will help us
to get some understanding in advance of how large and varied a
configuration our architecture can support. This approach will
also help us to understand how our architecture can be adapted to
other applications in which we can place more constraints than
would be appropriate for the Catenet. Consider, for example, a
Network Structure all of whose Pathways are versions of the
ARPANET which are largely homogeneous and under the control of a
single organization. Within this Network Structure, we might be
able to introduce much more effective and efficient routing and
congestion control mechanisms than in a Network Structure whose
Pathways consist of many different kinds of networks controlled
by many different organizations with varied interests (e.g., the
Catenet). In fact, this rather homogeneous Network Structure
might not properly be called an "internet" at all; it might just
be regarded as the ARPANET with area routing. ("Area routing"
refers to any routing scheme in which a network is divided into
several areas, such that Switches in each area have explicit
routes only to other Switches in the same area, but not to
- 22 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
Switches in other areas. Routes are available for getting to
other areas, but the internal structure of these other areas is
disregarded. The term is usually applied to routing schemes used
in single homogeneous, packet-swtiching networks, as opposed to
internets, however.) One of the advantages of our model is that
it enables us to see internetting and area routing as
applications that differ only in regard to the Pathway
characteristics of the appropriate Network Structure.
1.4 A Functional View of the Internet
Let's look now at how we might model the OPERATION of a
Network Structure. There seem to be four main steps involved in
getting data from a source Host to a destination Host:
1) A source Host submits a message to a source Switch,
providing it with the name of a destination Host to which
the message should be delivered, as well as with any
other information which is needed to specify necessary
constraints on the characteristics of data delivery.
(Note that we said "the NAME of a destination Host", not
the address of a destination Host. We will return to
this very important point in later papers.)
2) The source Switch must map the name of the destination
Host into the address OF A DESTINATION SWITCH. This may
or may not be identical to the source Switch itself. If
- 23 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
the name of the destination Host maps to several possible
destination Switch addresses (multi-homing), the source
Switch must choose one, and this must be one which has a
currently operational Pathway to the destination Host.
3) Using the routing scheme of the Network Structure, the
source Switch must get the message to the destination
Switch, via some (possibly empty) sequence of
intermediate Switches.
4) The destination Switch must get the message to the
destination Host.
This model of operation attempts to make a clear separation
between the protocols which the source and destination Hosts must
use to access the Network Structure (steps 1 and 4), the
protocols which the Network Structure uses internally to move
data from one point to another (steps 2 and 3), and the protocols
used by the Hosts to talk to each other. This separation is
required by the precepts of protocol layering, and also by common
sense, since only with a clear separation of access functions
from internal functions can we maintain the flexibility to make
internal changes in the Network Structure without impacting the
access software in the Hosts. The need for this separation
between access functions and internal functions is taken for
granted in most ordinary packet-switching applications, but has
not been incorportated at all into the current Catenet. The
- 24 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
current Catenet protocols freely intermix access functions with
internal functions, and in fact there is only a single protocol,
IP, which contains elements needed for Hosts to talk to each
other, for Hosts to talk to Switches, and for Switches to talk to
Switches. This seems to be a consequence of the old idea that
the internet is just a series of networks pasted together by
hosts which are on two or more of the networks. That idea makes
it difficult to distinguish the gateways from the hosts, or to
properly take account of the fact that although gateways are
Hosts in some Network Structure (that of the individual
packet-switching networks), they are also Switches in another
(that of the internet). A proper distinction of access functions
from internal functions seems essential, though, if we are to
build an internet which functions as a real network, rather than
as a series of pasted together networks and gateways.
Any Network Structure which is to be operational must have
some way of performing these four steps. Furthermore, in order
for particular applications to get satisfactory performance out
of their use of the Network Structure, the Network Structure must
perform these functions under certain constraints with respect to
delay, throughput, reliability, sequential delivery, and fault
detection. (By "fault detection", we mean the ability of the
Network Structure to inform the user about exceptional
conditions, such as the destination host's being down or
unreachable. This constraint is often neglected in the design of
- 25 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
network architectures or protocols, but seems quite important in
a robust operational environment.) The ability to gather and
report exception information at various levels of protocol is
important both for system maintenance and for general user
satisfaction. Nothing makes a worse impression on a user than a
mysterious degradation in service about which he can get no
feedback. It is not immediately obvious, though, to what extent
the various protocols used to operate a Network Structure must
ensure that these constraints are met. It is generally
understood that if some application requiring inter-process
communication must place constraints (such as sequentiality) on
the characteristics of the communications, then the application
itself must utilize some high level protocol (at the Host-Host
level, or even higher) which will enforce the constraints, rather
than depending on the low-level communications medium to enforce
them. What seems to be less generally understood is the fact
that, in general, and other things being equal, the performance
which some user gets from his high-level protocol will be better
if the lower level protocols pass data to the high level
protocols in a way which already satisfies the constraints that
the high level protocols must impose. For example, an
application which requires sequentiality will have to use a high
level protocol like TCP which guarantees sequentiality. However,
the end user will generally see much better performance, in terms
of throughput and delay, if the protocols below TCP maintain
- 26 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
sequentiality, since this will require TCP to do less work, and
put less of a drain on the resources (such as buffer space,
sequence number space, and host CPU bandwidth) needed by TCP.
The area of fault detection and reporting provides a good example
here. A user attempting to talk to a dead host might find his
TCP typing the message "excessive retransmissions" to him. This
sort of message would not generally be too useful to a user
since, if he is not a network expert, it gives him no clue of
what the actual situation is. The average user might prefer to
know that the destination host is dead, so he can try again
later, but this information is very difficult, if not impossible,
to obtain solely at the TCP level, although it might be quite
simple to obtain at a lower protocol level. Of course, putting
more functionality in lower level protocols also has a cost, as
well as a potential benefit, and costs often trade off with
benefits in surprising ways. As we shall see, producing an
operational Network Structure requires a large number of
protocols, and we will attempt to deal with considerations like
these as we consider specific protocol issues. Not surprisingly,
we will find that cost-benefit trade-offs for both access
protocols and internal protocols will often depend on the
characteristics of the Pathways in the Network Structure.
- 27 -
IEN 184 Bolt Beranek and Newman Inc.
Eric C. Rosen
REFERENCES
1. J.M. McQuillan, I. Richer, E.C. Rosen, "The New Routing
Algorithm for the ARPANET", IEEE TRANSACTIONS ON
COMMUNICATIONS, May 1980.
2. E.C. Rosen, "The Updating Protocol of ARPANET's New Routing
Algorithm," COMPUTER NETWORKS, February 1980.
3. J.M McQuillan, G. Falk, I. Richer, "A Review of the
Development and Performance of the ARPANET Routing
Algorithm," IEEE TRANSACTIONS ON COMMUNICATIONS, December
1978.
- 28 -
