IEN #31
On Names, Addresses and Routings (II)
Dan Cohen
ISI
28 April 1978
2.3.3.11 On Names, Addresses and Routings (II)
SUMMARY
This note deals with internetwork addressing and routing.
It suggests the following:
(1) Some systems have a tree-like hierarchical Universal-Address
(UA) space.
(2) The communication connectivity is a superset of this tree.
(3) The postal system, the telephone and the ARPANET are such
systems.
(4) The address of a process tells where it is located (or
connected to) by specifying the route to it from the root of
the universal addressing tree.
(5) The default routing to any address (unless a better one is
specifically known) is up the UA-tree, from the source, and
down the tree to the destination.
In the case of networks like the ARPANET, the set of all the
IMPs (the subnet) is considered as a single process, known as
{ARPANET}.
(6) Since the set of all networks is not connected, it cannot be
tree structured. However, for ease of name-management it is
possible to introduce (e.g., administratively) any arbitrary
hierarchy to the address space of all networks. This
hierarchy is "artificial" because it is not a subset of the
communication connectivity.
(7) Since there is no hierarchical structure to the space of all
networks, there is no tree-like hierarchical internetwork
Universal-Addressing scheme.
In particular, the notion of extending addresses like
{NET}-[HOST]-(PORT) or {NET}-/IMP/-[HOST]-(PORT)
2
upward to include METANETs, SUPERNETs and GIGANETs suffers
from the lack of corresponding underlying communication
structure.
(8) Since the set of all networks is too big to be captured in
local tables, and since routing cannot be derived in general
from the addresses, it should always either be apriori known,
or supplied by the source. This apriori knowledge does not
include every step (e.g., the sequence of intermediate IMPs or
PRUs). It has to include only a sequence of addresses such
that the routing between them is locally known.
(9) The corollary of this note is
OPTIONAL SOURCE ROUTING SHOULD BE IMPLEMENTED.
This note explains in great detail several aspects of the addressing
schemes used by the postal and telephone systems. It also mentions the
ARPANET addressing.
These examples are used to support the arguments which are summarized in
paragraphs (1)-(9) above.
Unless one is very interested in the details of these systems and their
relevance to the internetwork environment, or in the details of the
arguments, there is no need to continue reading this note beyond this
point.
INTRODUCTION
Before discussing the internet addressing/routing issues let us
summarize the basic concepts:
- Processes (not hardware pieces) have names and addresses.
- A process may have more than one name, and one address,
but addresses and names correspond uniquely to processes.
- The name tells WHAT the process is.
- The address tells WHERE the process is.
- The route tells HOW-TO-GET-THERE.
The last three beautiful definitions are borrowed (with appreciation)
from John Shoch.
More detailed discussion of names and addresses may be found in
"Internetwork Naming, Addressing, and Routing" [Internet Notebook
Section 2.3.3.5, IEN 19] by John Shoch, and in "On Names, Addresses and
Routings" [Internet Notebook Section 2.3.3.7, IEN 23] by Danny Cohen.
3 Generally the concept of address is well understood, but the concept of routing is much more complex. Who performs the address-to-routing mapping? How is it performed? These and similar problems are the topic of this note. Most of us are familiar with the postal, the telephone, and the ARPANET addressing schemes. We also have a very good understanding of the routing processes performed for these networks. In this note we discuss the similarity of these addressing schemes, and argue that the internetwork environment violates the basic axiom which is common to them, and therefore the internetwork environment requires a different addressing and routing philosophy. This is why we have so much trouble with internet addressing -- it is different. Our experience cannot be used as a model. ON OTHER ADDRESSING/ROUTING SCHEMES Three addressing/routing schemes are discussed: the postal, the telephone, and the ARPANET schemes. The postal addressing scheme is a UA-scheme. It is defined for human processing, and therefore may tolerate a fair amount of redundancy which improves the robustness of the scheme with respect to errors and to partial losses (like stains on envelopes). At the top level of the hierarchy there is the country name, and underneath it there are as many addressing schemes as there are countries. Some countries use ZIP codes which identify major post offices, and require more information to identify the terminal addressee. Other countries use the ZIP code (or its equivalent) to identify the individual letter-carriers, and require less additional information to identify the terminal addressee. In some cases, a street address is sufficient. In others, suite number and names are required. In summary, the postal addressing tree is of variable depth (or: postal addresses are of variable length). Its top level (the country level) has a complete connectivity, since every country knows how to route mail to any other one. Letters are routed, either directly to the destination or to one of its ancestors. This is performed by POs either directly or via their ancestors. Since the address and routing processing is not fully automated, human intelligence is used for resolving ambiguities, for coping with unknown addresses, for redundancy handling and the like. Missing information is usually supplied by using common sense and defaults. As a result, a great amount of variability in addresses can be tolerated. For example, while at Tech, I received letters addressed to
4
Danny (I was the only Danny there)
256-80 (The Computer Science Mail-stop)
91125 (The zip code for Caltech)
I also received letters addressed to:
Dr. Dan Cohen
Computer Science, Mail-Stop 256-80
California Institute of Technology
Pasadena, California 91125
The first address contains all the needed information, but requires
delicate handling. If any of the digits is mistyped, there is very
little chance that the letter would be delivered to the right
destination. The second address, which has about six times more
characters, is more robust, and can cope with the multi-Danny situation,
which (even though undesirable) is still very probable. The terse
address has to be modified if another Danny joins this Mail-Stop.
The phone addressing is considered next. Like the postal system, each
telephone station has a UA. It always starts with the country code, and
usually continues with a Numbering-Plan-Area (NPA, which is the familiar
Area-Code, AC), continues through a Central Office (CO) number and
terminates with the station number. Even though the above fields are of
variable length, the total length never exceeds 12 digits. However,
when private networks are connected to the universal phone system, the
entire address length may exceed this limit.
For example, my current phone number is 12138221511105, which is 14
digits long. The first "1" is the USA code, and the last "105" is my
station (extension) number.
At the top level of the hierarchy there is the country code, and
underneath it there are as many addressing schemes as there are
countries. All countries know how to communicate with any other
country. In both systems addresses are of variable length, and by
looking at an arbitrary address one cannot parse it into fields without
knowing the specifics of each national addressing scheme.
Here are some examples of telephone addresses and their correct parsing
as COUNTRY-NPA-CO-station:
1-213-822-1511 (USA, LA)
44-1-387-3400 (UK, London)
44-31-332-2424 (UK, Edinburgh)
44-745-58-3301 (UK, Wales)
972-4-25-2690 (Israel, Haifa)
972-67-4-0777 (Israel, Kiryat Shmona)
Obviously, the number of fields to be dialed depends on "distance" from
the destination.
5
Since the telephone routing is performed by (relatively) simple minded
automated equipment, no variability in dialing a number is allowed
(except in very unusual situations).
Like the postal addresses, phone dialing sequences are of variable
length, as a function of the distance to the destination. While adding
the country code ("USA") would not hurt either of the postal addresses
shown above, adding the local AC and country code is not allowed for
local phone calls.
The reason is that one does not dial the address (telephone numbers),
but dials the routing! The purpose of the telephone number is to be used
for accounting and for deriving routing, but not for verbatim-dialing.
The actual telephone routing (i.e., hop-by-hop) is very efficient and
deserves attention. The key to it is the existence of more
communication lines than branches in the UA tree.
The USA is divided into 10 regions, which subsequently are divided into
sections and areas. The grouping of areas into sections and regions
cannot be simply deduced from the ACs but has to be found by a table
lookup operation. This is because the ACs were most cleverly assigned
to areas by population size and not geographically like the ZIP codes.
The routing is performed by each center assigning each call to a line
known to be connected (or enroute) to the destination central-office.
This is performed by looking at the first six digits of the address
(AC+CO).
If such a line does not exist, then the call is assigned to a line known
to be connected to the principal city of the destination NPA. If such a
line does not exist either, the call is forwarded to the center above
this one. Since at the top all regions are interconnected, this process
is guaranteed to terminate.
In addition to the SIX digits recognition, the system is designed such
that in many cases CO numbers do not conflict across NPAs. This
eliminated the need to dial an AC of a neighboring town, across a state
line, which is necessarily in a different NPA. This allows, for
example, dialing from Washington, D.C., (AC=202) to Alexandria, Va.,
(AC=703) and to Potomac, Md., (AC=301) without dialing the AC.
The third addressing scheme is the one used in the ARPANET.
Addresses on the ARPANET are of processes which are either NCP-like in
actual hosts or of other types in "fake" hosts. It is logical to extend
the address notion "down" to include the port, too.
Conceptually, one can consider the ARPANET as a single process or as a
star network. The fact that this single process is implemented in a
very clever way by a multitude of IMPs is irrelevant, from a functional
point of view. This allows treating this entire network as a single
addressable process, the {ARPANET}, if so required.
6
Each IMP knows how to forward messages to any other, and therefore all
IMPs constitute the top-level (and the only level) for routing.
In the ARPANET all the connections are between centers (nodes) of the
same (and only) level. This is in contrast to the telephone network,
which has several levels of centers, partially connected at all levels
(except the top, where they are fully connected) and also partially
connected between levels.
An ARPANET address is of the form {ARPANET}-[HOST]-(PORT), which one may
consider as {ARPANET}-/IMP/-[HOST]-(PORT). Adding the /IMP/ field may
help in the ARPANET situation, though some generality will be lacking.
This is a valid address, since the {ARPANET}-process (which is the set
of all IMPs) can forward messages to all hosts, and hosts can give
messages to PORTs. Therefore, routing every message up to the {ARPANET}
and then down through the host to the destination port is a good default
routing strategy.
INTERNETWORK ADDRESSING
After this (very) long introduction, let's return to the Internet
Addressing situation.
But first, let's introduce some more formality:
* An address is a string (i.e., an ordered set) of symbols
taken from a given alphabet (e.g., ASCII, {0,1},
{1,2,...9,0}).
* In a UA tree the level of a given address is its depth in
the tree. The level of the address A is denoted by L(A).
* Address concatenation (extended to the right) will be
used. The concatenation is denoted by a "-".
* If both A1 and A2 are addresses of the same process P,
then
(1) L(A1) and L(A2) may differ, and
(2) The addresses (A1)-(X) and (A2)-(X) are
necessarily addresses of the same process.
* Addresses should always be decodable in a strictly
left-to-right sequential manner (prefix coding).
What is the ARPANET address of my mailbox?
In the TENEX environment it is [ISI]-(MAILBOX)-<DANNY>. But in another
environment, in the host [X], it could be [X]-<DANNY>-(MAILBOX). Or
maybe in the form [X]-/TCP/-(MAIL.DEPO)-<DANNY>.
7
Obviously we want to expand it upwards, to allow for other networks. We
could simply add in front of these addresses a network field and get
{ARPANET}-[ISI]-(MAILBOX)-<DANNY>
and similar addresses. In other networks the value of the NETWORK-field
may be {PRNET-SF}, {PRNET-BOS}, {SATNET}, etc.
What is the relation between these nets? Do they all belong to the same
parent like USA or USA-DoD?
This could be a solution, and if adopted my mail address may be upward
expanded in the UA scheme to be like:
{GALAXY-573}-[SOLAR.SYS]-(EARTH)-<USA>-{ARPANET}-[ISI]-(MAILBOX)-<DANNY>
With a clever use of defaults, the first several fields may be omitted
from most of the intraglobal communication.
The extension of this address upward, to include METANETs, SUPERNETs and
GIGANETs, is very elegant. This is the prevailing popular approach
expressed in a series of notes and papers, such as Ken Harrenstien's
note, and various other communications between the members of
[SRI-KL]<NETINFO>FIELD-ADDRESS.LIST. The intelligent reader probably
has noticed by now that this note does not subscribe to the same
philosophy.
This solution suffers from several problems. What is a network? Is
every bus to which several processes are connected a network? If not,
why? What is the relation between networks?
In order to stress the difference between the structure of the internet
address and of the other universal addressing schemes, let's consider
the following example. One of the ARPANET hosts, [PARC-MAXC], is tied
to a private network. This network is actually a very rich internetwork
environment, with about 14 networks and about 400 hosts, but for
simplicity let us consider it functionally as a single {XEROX-net}. One
of the hosts on this net is [RIG], the University of Rochester
Intelligent Gateway to the internal {U-of-R-net}. This description is
not accurate, since [RIG] is actually connected directly to the
{ARPANET}, not to {XEROX-net}. But for the sake of the argument let us
assume this connectivity. We preferred not to use other actual examples
for several reasons. A poet's-license is nice to have....
One of the hosts on the {U-of-R-net} is, say, [NOVA-3]. What is its
address? Obviously it is
{ARPANET}-[PARC-MAXC]-{XEROX-Net}-[RIG]-{U-of-R-Net}-[NOVA-3].
By the way, whenever an intermediate host in such a specification (i.e.,
a gateway) is between two networks only, there is no need to specify the
destination network, since it is uniquely defined by context. However,
this is not a good practice, since addresses have to be changed when
this host is connected to more networks.
8
What is [ISI]'s address? Obviously {ARPANET}-[ISI].
"Not so!" scream the U-of-R people. The addresses of [NOVA-3] and of
[ISI] are quite different from the point of view of [NOVA-2]. According
to it, the address of [NOVA-3] is simply {U-of-R-Net}-[NOVA-3] but of
[ISI] is {U-of-R-Net}-[RIG]-{XEROX-Net}- [PARC-MAXC]-{ARPANET}-[ISI].
Who is right? Neither!! Either approach is equally wrong. Neither of
these addresses is above the other in the UA scheme. All the networks
involved in the interconnection of these networks are of equal level,
unless we decide otherwise for administrative reasons. The internet
communication environment does not have up-and-down relations, except in
the eyes of some users, which may be very subjective.
INTERNETWORK ADDRESSES ARE DIFFERENT
Telephone stations are always connected to the system network, and their
position in it dictates their addresses. Not so with computer networks
which spring into an independent existence until they are interconnected
to others, if ever. Therefore, their addresses cannot be deduced from
their positions (geographically or connection-wise) and vice versa.
Therefore, the network ID is an arbitrary string. Who assigns it and
makes sure that no conflicts occur? Is it NBS? Jon Postel? Another Czar?
At this point we suggest that:
* There is no universal hierarchy of networks, in contrast
to the telephone and the postal systems.
* There are too many networks to be named and/or addressed
in a single flat name/address space.
* Therefore, some naming/addressing hierarchy has to be
introduced. However, this addressing tree does not serve
as a basis (or underlying structure) for the
communication connectivity.
* Routing cannot be computed from any point to any point
from the addresses alone.
How should internetwork routing be performed? There are obviously
several possibilities. It could be performed entirely by the networks
involved (i.e., the communication system), by the source, or by any
combination of the communication system and the source.
It is always desirable to distribute the knowledge about possible
destinations to the various centers (gateways?), such that their "sphere
of knowledge" is as large as possible, though uniformity should not be
required. More knowledge should be kept about frequent destinations
than about less frequent ones.
9
Since this information must be limited due to practicalities (such as
finite storage and updating procedures), it is impossible that all
sources always know about all possible destinations.
What should be done about unknown destinations?
Several possibilities may be considered.
o Having a `supernet' of default sub destinations with the
hope that they know how to find a way to the terminal
destination (like the phone and the postal systems),
o providing internetwork-wide directory services, or
o refusal of service.
Let's consider each of these three possibilities.
Having both <USA>-{ARPANET} and <USA>-{XEROX-Net-3} does not guarantee
the existence of the path {ARPANET}==<USA>=={XEROX-Net-3}. Therefore,
the supernet (metanet?) is not a part of the underlying communication
structure as in the phone and postal situations.
In order for this approach to work, one has to create this supernet and
keep it updated about all changes of the entire internetwork
environment. Both the storage and the updating procedures seem to be
impractical.
The second approach, the network-wide-directory-help, is a very
reasonable one. It has a major drawback in the necessity to maintain
centers with indefinite knowledge radius. Note that the telephone
directory services are structured according to the addressing hierarchy
of NPA-CO, and are not flat as may be suggested for the internetwork
environment. In essence, this second approach has all the problems of
the first one.
The third approach, namely, refusal of service to unknown destinations,
is consistent, to say the least. Admittedly, it seems like an
inconvenience to users. It should be supplemented by ways of "learning"
about the unknown destinations, such that refusal should never occur, or
at most, only in very rare situations. Directory services could be
helpful.
Hence, this approach supports serving only destinations to which the
routing is either apriori known or supplied. Note how similar this is
to the telephone system philosophy.
In summary: The internet routing problem is different from the routing
problems of other systems because the internet environment does not have
a communication connectivity which supports a UA scheme, and therefore
the addresses cannot support a direct address-to-routing mapping by
using only a definite amount of knowledge.
10
I HATE TO ADMIT IT, BUT ...
At the beginning of this note, and in an earlier note, I used a great
line telling that "names tell what the processes are, and addresses tell
where they are." It continues by "routings tell how to get there."
I hate to admit that by now I have some reservations about this
definition. My name is "Danny." My address is "ISI." When I was at
Tech, my name was the same, but the address was different. This
supports the definition. How about the addresses in a broadcasting
media network? When a host changes its position (location) on the same
Ethernet, its address does not change. Well, maybe these addresses are
not real addresses, according to the definition. Admittedly, this is an
uncomfortable thought.
I believe that there is a better explanation. I suggest that an address
is "the canonic routing from the root of the addressing-tree." It sounds
recursive, doesn't it?
To be more precise, an addressing scheme is a hierarchical organization
of elements, with code assignment such that each element has a unique
set of codes, corresponding to its position in the hierarchy.
The notion that the address tells how-to-get-there from the root of the
tree is very similar to the notion that absolute coordinates are really
relative, with respect to the origin.
Since we know (by default) how to get from the source to the UA root,
and since the address tells how to get to the destination from the root,
the address tells how to get from the source to the destination.
Hence, by definition, addresses are routings.
This leaves us only with names and routings. This should not surprise
us now, since we already discovered that the telephone system has only
names and routings.
Since the general internet environment does not have a hierarchy, the
notion of addresses suffers. Since the addresses are "routing from the
root," and since there is no root of the entire system, our conclusion
is that there are no addresses, only names and routing. In other words,
what we are used to call an address is actually a routing (even though
it is of higher level than the hop-by-hop routing). In a well defined
(and tightly controlled) environment, such as the {ARPANET}, this
address/routing is a well defined string. In general, it may be of
indefinite length and structure.
If the destination is in the neighborhood, such as the same network, the
same nets-cluster, the same agency (even on different net), the system
may have a built-in knowledge of how to get to it. Otherwise the
routing information needed should be supplied by the sender.
11
PROPOSAL FOR ADDRESSING AND ROUTING
Our proposal for addressing and routing is as follows:
* Establish a UA scheme, of variable level structure.
* Disseminate as much knowledge to each participating node
as deemed practical.
* Allow the option of routing to be included in the headers
of the messages.
* Refuse delivery of messages to a destination with unknown
routing
* Establish internet-directory-assistance service.
The proper use of the optional routing is to supply a set of
subdestinations which may be as far apart as the networks can handle
without help. This is very much like source routing for telephone
connections, where a sequence of switching-centers is designated by a
user, but the communication subsystem is free to optimize the hop-by-hop
routing between these centers.
As long as the number of participating networks in the internetwork
environment is small, it is possible to have each of them know about
routing to all the others. However, we already have a large community
of networks, including several PRNETs, networks in universities, about
15 networks at Xerox, the commercial and the national ones, many in DoD,
all the DEC-Nets, and many others. In addition, each big modern
substantial computing system is a network.
One may be advised to expect the number of networks to grow, and the
internet connectivity to get more and more obscure.
Therefore, optional source routing seems to be the most sensible, and
the only, alternative. This does not exclude the notion that internet
clusters of any size optimize their internal routing by any scheme, for
example by ARPANET-like dynamic routing scheme.
We recommend that the optional source routing will be composed of self
level-identifying fields. Note that this is like the telephone dialing
sequence.
The self-identifying fields could be implemented either by
codes-exclusion (like the telephone system) or by identification
subfields. Obviously these two schemes are equivalent, and the choice
between them is just a matter of convenience.
mirror server hosted at Truenetwork, Russian Federation.