GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien31

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:

  1. Processes (not hardware pieces) have names and addresses.
  1. A process may have more than one name, and one address,

but addresses and names correspond uniquely to processes.

  1. The name tells WHAT the process is.
  1. The address tells WHERE the process is.
  1. 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.

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien31.txt · Last modified: 2001/06/25 18:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki