Download A Model for Naming, Addressing, and Routing

RESEARCH
CONTRIBUTIONS
A Model for Naming, Addressing,
and Routing
BERNARD M. HAUZEUR
Montefiore Institute, University of Liege
Naming and addressing are areas in which there is still a need for clarificaton.
Many definitions for
names, addresses, and routes have been proposed, but the exact relations among these concepts are
obscure. A taxonomy of names, addresses, and routes is presented. First, we identify names and
routes as the essential concepts of communication. Then, addresses are introduced as an intermediate
form that eases the process of mapping between names and routes; an original definition of an address
is thus proposed. Relations among names, addresses, and routes are explained with the concept of
mapping. On this basis, a general model relating names, addresses, and routes is built and then
applied recursively throughout a layered architecture, leading to a layered naming and addressing
model which may play the same role for naming and addressing features that the OS1 reference model
plays for the definition of services and protocols. Finally, the model is particularized
to a typical
network architecture. The model may also be applied to non-OS1 layered systems; naming, addressing,
and routing issues in any network architecture could be a particular instance of this layered model.
Categories and Subject Descriptors: C.2.0 [Computer-Communication
Networks]:
[Computer-Communication
Networks]:
Network Architecture and Design
General Terms: Design, Standardization,
Additional
routes
General; C.2.1
Theory
Key Words and Phrases: Addresses, layered architecture,
mapping, names, OS1 model,
1. INTRODUCTION
J. Shoch suggests that in any communication system there are three distinct
abstract concepts:
The name of a resource indicates what we seek,
an address indicates where it is,
a route tells how to get there.
[22, p. 721
These definitions have the advantage of being very simple and of giving clarity
to the basic concepts. Nevertheless, when going into detail the definition of an
This research has been done within the framework of the ESPRIT Project 73, “Broad Site Local
(D)
Wideband Communication
System, )) involving ACEC (B), BTM (B), SG2 (F), STOLLMANN
and the University of Liege.
Author’s address: Montefiore Institute, University of Liege, Liege, Belgium.
Permission to copy without fee all or part of this material is granted provided that the copies are not
made or distributed for direct commercial advantage, the ACM copyright notice and the title of the
publication and its date appear, and notice is given that copying is by permission of the Association
for Computing Machinery.
To copy otherwise, or to republish, requires a fee and/or specific
permission.
0 1986 ACM 0734-2047/86/1000-0293
$00.75
ACM Transactions on Office Information
Systems, Vol. 4, No. 4, October 1986, Pages 293-311.
294
l
Bernard M. Hauzeur
address is not satisfactory. Ambiguities may arise with regard to its interpretation, and questions are left open.
For instance, a group address cannot really indicate where the group is, since
a group may spread over many locations; moreover, members may be added or
removed, so the “location” of the group changes, whereas the group address does
not. Therefore, we may wonder whether a group address is a special form of a
name or an address, but then the word “where” must be interpreted in a more
subtle sense.
In the same way, an absolute address (like an Ethernet address) does not really
tell where the entity is, since there is deliberately neither an internal structure
in such an address, nor rules to interpret their values.
We also know that in Ethernet, Xerox has introduced the concept of factory
set addresses [2]. These addresses are 48-bit numbers, and no two controllers in
the world may have the same number. Since controllers have their addresses
fixed before they are installed on some Ethernet LAN, it is obvious that the
address cannot tell “where it is.” Then it seems that such a factory set address
is the name of the controller, causing us to wonder whether this is an incorrect
use of the term “address.” Where does the address concept lie? However, the fact
that the controller directly identifies this (48-bit) “name” on the Ethernet bus
fits our intuitive feeling of an address.
Moreover, these definitions do not introduce a fourth concept that is a key
point in the discussion of naming and addressing problems: the concept of
mapping.
There are, in fact, two basic needs in distributed systems: On the one hand,
we are faced with the necessity of assigning names to applications or resources
accessible through the network in order to indicate what we seek (using Shoch’s
expression). Since human users operate at this level, such names would most
often be human readable. On the other hand, there is the basic need to achieve
communication.
Thus a physical route (the path from source to destination
through communication
equipments) must ultimately be determined in one way
or another. Names and routes are the essential concepts, and the problem of
communication
will be solved if we know how to derive the route from a name,
or, in other words, how to map a name into a route.
This mapping function can be accomplished in one step (i.e., routing by name;
cf. Section 5) or in many steps. Addresses are like bridges between names and
routes, which decompose the global mapping function into two steps: mapping
names into addresses and then addresses into routes.
With regard to names and routes, addresses are considered only as an intermediate form, but one that has been revealed in practice as offering the most
convenient properties for identifying objects involved in data communications.
The design of layered architectures like the Open Systems Interconnection
(OSI)
model is mainly responsible for such an emphasis on the address concept.
Considering addresses as an intermediate form is very helpful when looking at
the problems that addresses are intended to solve: Addresses are torn between
names and routes; on the one hand, names are most often statically bound to the
entity they denote and thus move over the network with the named entity. On
the other hand, routes may change with the naturally evolving network configuration and topology, and sometimes with the traffic load as well. Then names
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing,
and Routing
Fig. 1.
Partitioned
295
names.
Name of q isA.x.P
Name of •l is C.x.2
provide application entities with a transparent network, hiding, in particular,
locations and topological parameters on which routes are highly dependent.
Addresses would serve as a bridge between both.
We believe that many practical naming, addressing, and routing issues are
simplified instances of the general naming and addressing principles that are
presented in the following sections. These principles provide support for a unified
view.
2. NAMES
The name is the first fundamental concept implied by communication as soon as
more than two entities communicate. We assume the following definition:
A nane is a linguistic object that singles out a particular entity from among
a collection of entities [26]; it is the collection of entities that defines the
naming domain. The correspondence between names and entities is the
relation of denoting [12]. A name denotes (identifies) the entity to which it
is bound. A name is not always a human-readable string.
Any kind of entity (in the broad sense, not limited to the OS1 definition for
entity) may have a name. In this paper we are concerned with users, groups of
users, services, service agents (servers), hosts, gateways or nodes, networks, roles
(e.g., the “central administration”),
and so forth.
Names may be characterized by three attributes: Structure, time, and number.
(1) Structure
A primitive or flat name in a specific domain is a name that alone identifies
unambiguously a particular entity out of the set of entities composing that
domain. It has no internal structure.
A partitioned name is a succession of primitive names identifying,
respectively, a domain, subdomain, sub-subdomain,
and so on, followed by a
primitive
name identifying
the entity inside that sub-sub- . . . -domain.
Domains are arranged in a strictly nested structure and must not overlap
(Figure 1).
ACM Transactions on Office Information Systems, Vol. 4, No.
4,
October 1986.
296
-
Bernard M. Hauzeur
-.
.. . . . . . . yellow..
........
yellow . . .......
. . . . - .. ...............
. . . . . . . . . . . . . green..
green .- ..
..,.
.I
, ,- -_--------~.
;: ---. soft --\
i
Fig. 2.
Descriptive
names.
-----------+---hard
#
-........................-**
--- : :.
*..............
/
blue . ..j
Name of
q
is [color = green;hardness
= soft;size
or [co/or= green;size = small]
Name of
q
is [color = yellow;hardness
= soft;size
= small]
= small]
A descriptive name is a list of attributes that are true for exactly one entity,
for example, “Personal name = B. Hauzeur; organizational unit = Montefiore
Institute; organization = ULg; Place = Liege; country = Belgium”. In this
context, an attribute consists of an attribute type and an attribue value, the
latter being a primitive name. Attribute types may be implied in some
circumstances, leading to “B. Hauzeur @ Montefiore Institute @ULg @ Liege
@Belgium”. A partitioned name is a particular form of descriptive name that
has a rigid structure (a rigid set of attributes). Nevertheless, with descriptive
names, domains can be arranged in any manner, and names may not be
unique for the same entity (see Figure 2). A standard naming convention
based on descriptive structures is specified in [l].
(2) Time
A static name is a name that permanently denotes the same entity. This is a
very usual property of names and is often implied.
A dynamic name is a name that is assigned to an entity for only a limited
period of time, which is short with respect to the lifetime of the entity. Such
names have little interest in practice, since it is obviously not convenient for
human users to handle them. However, in Section 4 this concept is extended
to addresses.
(3) Number
Agroup name denotes a defined set of entities. An individual
or specific name
denotes a single entity.
Names are generally ambiguous; their meanings depend on the context. For
instance, in the context of entities connected to a network, DECBO may represent
an interface process; in the context of a machine offering a time-sharing service,
DECBOmay denote the logging server; in the context of mailing processes, DECBO
may denote a mail transfer agent; and, for human users, DECBO denotes the
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing,
Time
Structure
1
Scheme
=
and Routing
297
Number
Function
Time
List of NAMES
Fig. 3.
Fundamental
diagram.
overall computer. Names do not need to be meaningful to all users or to be drawn
from a uniform name space [3].
A name, either absolute, partitioned, or descriptive, whose domain covers the
global network (i.e., all the accessible entities in some layer) and that is valid for
a long period of time is often called a global name or common name [18] or
distinguished name [l]. In internetworks,
it means that its scope is not limited
to a particular host or subnetwork.
The term absolute name is often used to mean a global flat name that is also
static. For denoting application entities, global static flat names (i.e., absolute
names) offer many advantages. First, flat naming is the most human and natural
way of denoting. Second, static naming is independent of the communication
support. Services, resources, and any kind of application entity keep the same
name when they change places. This is an important property when one considers
that “changing the name would require [changing] not only some mapping tables,
but also user programs, documentation, scribbled notes, advertising copies, etc.”
[20]. Finally, absolute names would present the network as “a network of
resources rather than a network of computers” [18].
3. ROUTES
AND
ROUTING
The route is the second fundamental
definition is general:
concept in communication;
A route is a list of names representing
the following
the path from source to destination
PO].
We may already anticipate that addresses are names, in which case a list of
addresses is only a particular form of route, and, in fact, this is the most usual
form of route. In a layer, when there is no intermediate entity between source
and destination through which the packet must transit, the route is reduced to a
list of a single element, which is the address of the destination entity.
So, on the one hand, a name identifies an entity, and on the other, a route
specifies the path to an entity. Communication
will become effective if we can
map a name into the corresponding route (Figure 3). This function of mapping
names (or addresses, in particular) into routes is called routing. In fact the term
routing is used with two different meanings: routing as a mapping function, or
ACM Transactions on Office Information Systems, Vol. 4, No. 4, October 1986.
298
l
Bernard M. Hauzeur
routing as the action of forwarding a packet. The first meaning is used in this
context.
The following short taxonomy of routing functions is based on [22] and [25].
However, a distinction is made between the entity that has to make the routing
decision and the one that effectively provides the routing information. Thus, up
to four attributes may enable the following classification of routing functions:
(1) The place where the routing decision is made.
Source routing:
The entire route is determined
at the source.
Hop-by-hop routing: Only the next portion of the route is determined at each
step. That is, the mapping of the destination name into a list of names is not
performed once by a single entity; each entity along the route determines
only the next element.
To be complete, one should add the definition of broadcast routing (or receiver
routing according to [25]). Packets carry their destination name (or address).
Each packet is broadcast through the network and every entity receives it,
but only the one that recognizes its name (or address) actually picks up the
packet from the network.
The route may be reduced to a list of a single element: The destination name
or address. In this case, source routing or broadcast routing may lead to the
same mechanisms as explained below.
One may wonder what these routing concepts are over a single carriersense multiple-access (CSMA) local-area network like Ethernet, for instance,
since in such a context these concepts are straightforward.
Indeed, the route
degenerates to the destination Ethernet addresss (according to the definition,
this is the specific information
needed to forward a packet from source to
destination). Once a packet is transmitted on the Ethernet bus, all stations
have simultaneous access to it, and only the one that recognizes its address
takes it. This is a broadcast routing scheme, since the source station performs
a null routing function. One can also say that this is source routing, since
the source entity knows the entire route as soon as it knows the destination
address!
These basic schemes may be combined into hybrid routing schemes; for
instance, the source entity may specify only some intermediate points and
let the communication
system determine the routes between those points.
This is the source routing option in ARPANET
[4].
(2) The place where the routing function
is performed.
The routing function can be centralized, partially distributed, or fully distributed. Indeed, when an entity has to originate either a part of the route (hopby-hop routing) or the complete route (source routing), this entity can
perform the routing function locally or ask a remote site for the information.
In the first case, the entity has all the information
needed to perform the
routing function. The routing function is fully distributed. In the second
case, either a unique entity or a subset of all the entities (of this same layer)
has the capability of performing the function. The routing function is either
centralized or partially distributed, respectively.
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing,
and Routing
299
Fig. 4. General diagram.
(3) The time constant of the information
based [22].
upon which the routing function is
We distinguish between static, fixed, or deterministic routing in which routing
tables do not change for very long periods of time and dynamic or adaptive
routing in which the routing information is constantly updated.
(4) With adaptive routing, a fourth attribute, the control mechanism, may be
defined [ 221.
Entities performing the routing function may try to update their routing
information in an isolated manner by trying various routes and observing
performances. When a few entities are responsible for promulgating the
updated information, the control is centralized. Finally, the update process
may be distributed among all the entities mutually exchanging the routing
table updates.
The preceding considerations lead to the diagram presented in Figure 3. It is
important to note that this is a formal model linking up concepts. Therefore, the
single arrow does not imply that the mapping function is done once and for all
by a single entity. Indeed, in the hop-by-hop routing scheme, for instance, many
entities contribute to the determination of the complete route.
4. ADDRESSES
Into the model of Figure 3, we now introduce an address as an intermediate form
between the name and the route; this is shown in Figure 4. The feeling that an
address is an intermediate form is based mainly on two facts: (1) the model of
Figure 3 is consistent without the introduction of an address; (2) there exist
routing schemes that work without the use of addresses (cf. Section 5). It is the
introduction of the service accesspoint (SAP) concept and the numerical nature
of addresses that elucidate the universal and exclusive use of addresses in layers
l-6 of the OS1 architecture. The remaining sections explain how we go from the
model of Figure 3 to practical network architectures.
We now propose the following definition of an address:
An address is an intermediate form between a name and a route; it is oriented
to machine processing and used to generate the route.
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
300
l
Bernard M. Hauzeur
This definition is the most general. In practice, entities are linked to a
communication object through which they can send and receive messages:thus,
addresses of entities are chosen such that “they are the name[s] of the communication object/s] these entities are bound to” [20]. This last definition relies on
the important concept of binding. In fact, actual information is intended for
the entity, but it is always sent via the communication object the entity is
bound to [22].
It thus turns out that an address is not only a name, but a particular kind of
name that has a special meaning with regard to communications and that is
oriented to machine processing (i.e., route generation). But this criterion is not
sufficient to determine whether or not a particular kind of name is an address.
Indeed, the main difference between pure names (which are not addresses) and
addresses is that an address is attached to a communication object but not to an
entity. It is only through the concept of binding that an address refers to the
entity, whereas the name of an entity directly denotes the entity.
The concept of binding is particularly obvious in the telephone network. In
fact, the telephone number (a telephone network address) of a person is the
“name” of the telephone set this person is bound to.
In computer networks, the communication object may be an abstract object
like a service access point. This corresponds to the OS1 definition of an (N)
address (cf. Section 6.1) [lo]. As a consequence of the binding concept, if the
communication object is reattached to another entity, then the address identifies
the new entity and not the old one. Service access points in OS1 follow this
rule [lo].
Attempts to classify addresses may be done in two ways. If we build a
classification of addresses on the basis of experience without prior assumptions,
we shall discover a remarkable parallelism with the classification of names and
thus be led to consider addresses as a special kind of name. On the other hand,
if we consider addresses as names a priori, the three attributes of structure, time,
and number should be applicable to addresses.
(1) Structure
Addresses may be primitive or flat addresses (also called absolute addresses)
or partitioned addresses [7], with definitions corresponding to those for
names. The term hierarchical address [23, 241 is used only for a kind of
partitioned address constructed over the lower layer address (cf. Section 6.2).
Pure descriptive addresses can also be imagined.
As an example, an XNS internet address [(net number) (host number)
(socket number)] [27] is a mix of partitioned (hierarchical in this case) and
descriptive structures. Indeed, the host number is flat and intended to identify
only a single host in the entire world. The socket number identifies an
internet service access point (SAP) inside the specified host. Thus the pair
(host number) (socket number) is a partitioned address, and the (net
number) is redundant. Moreover, since a host may be connected to several
networks, more than one internet address may identify a single internet SAP
in that host; this is a feature of a descriptive structure that is brought by the
net number.
ACM Transactions
on Office Infbrmation
Systems, Vol. 4. No. 4, October 1986.
A Model For Naming, Addressing, and Routing
l
301
(2) Time
An address may be static or dynamic as in [14]. It is always relative to a
certain time scale. A relevant scale would be the lifetime of an entity. If an
entity’s address only changes once or twice during its lifetime, then these
changes may be put into the category of those that occur when entities are
added or retrieved and the address is considered to be static. On the other
hand, if the address changes with each power failure, disconnection, maintenance operation, etc., the address is considered to be dynamic.
(3) Number
An address may refer to a group of entities (e.g., multicast addresses, broadcast
addresses), or it may be an individual (or specific) address identifying a single
entity.
Addresses can be viewed as a rigid way of naming offering many interesting
features in comparison with (user-friendly) names directly denoting entities:
-Addresses are most often numerical and obey a very specific format; therefore, they are more appropriate to machine processing. For the same reason, they
are more easily administered than names and can guarantee more reliable and
unambiguous references. However, since an address identifies an entity only
indirectly because of the process of binding, the sole use of the address does not
guarantee that the adequate destination entity is reached.
-Addresses are always recognizable by all the entities of the corresponding
layers. This may not be the case for names.
-Adequate address structures allow the routing function to be easily distributed (e.g., partitioned address with hop-by-hop routing).
-Since addresses are attached to communication equipment and not to
entities, the problem of relocation of entities is relegated to the mapping of
addresses to names and does not interfere with route generation (mapping routes
to addresses).
-In layered architectures, addresses are very convenient for relating entities
in a layer to others in adjacent layers; this bears a close relationship to the
principle of layer independence in the OS1 reference model, which includes the
important SAP concept to which addresses are bound [lo].
Because addresses are names, in order to avoid confusion in the following
discussion, the term name is used only when we refer to names directly denoting
entities and not for names of communication objects to which entities are bound,
except when interpretation is clear from the context.
5. MAPPINGS
5.1 General Diagram
The introduction of the address concept in the fundamental diagram in Figure 3
has led to the formal diagram represented in Figure 4. Owing to this introduction
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
302
l
Bernard M. Hauzeur
of an intermediate
a route:
form, we can now identify
two ways of mapping a name into
(a) The name is directly mapped into a route.
(b) The name is mapped into an address, and the address is mapped into a route.
The mapping function is then decomposed into two stages, which may be
performed in different locations.
In fact, there are three different mapping functions among three objects
(Figure 4): mapping a name into a route (arrow a), mapping a name into an
address (arrow b), and mapping an address into a route (arrow b’). Arrow b
corresponds to a directory function, and arrows a and b ’ correspond to routing
functions. Each of these mapping functions may be distributed among several
entities. This has already been explained for routing functions (cf. hop-by-hop
routing). In practice, the routing function is very often a fully distributed function,
each routing entity (in gateways, routers or relays, depending on the terminology)
having its own routing table and interacting with neighboring entities to update
it. Similarly, the directory function is often partially distributed; it is performed
by a few entities that are called name servers or directory service agents [l, 8,
11, 15, 16, 17, 211. A directory service agent may interact with several others in
order to perform the mapping of a single name into an address.
The term directory function has a broader meaning beyond just the mapping
of a name into an address. This function may be rather complex, especially in
the application layer where several stages of mapping can be performed before
getting the address. For instance, a group name is mapped into a list of names
that may contain other group names [5]. Additional mappings will lead to a list
of individual names, which are then mapped into addresses. Let us stress again
that if we formally consider this directory function as a whole, it does not mean
that it is performed by a single entity in a single place.
Names, addresses, routes, and related mappings can take place in any layer,
and each layer fulfills
a particular
function,
which thus makes each of
these concepts more or less apparent. These points are discussed in detail in
Section 6. Note that routes may, of course, be reduced to the destination address,
but they are still routes even if the concept is hidden behind the address.
Mapping a name (denoting an entity) into an address, and then mapping the
address into a route (b, b’) is much more usual than mapping a name directly
into a route (a). Indeed, this corresponds to OS1 layering principles. Mapping
names into addresses is merely performed at the application level where human
operators interact.
Nevertheless, the direct mapping of a name (denoting an entity) into a route
may be something of a surprise. It is called “routing by name. “?l’his function is
much less common than routing on the basis of an address (denoting an access
point). However, the classification of routing functions defined in Section 3 is
applicable to both.
So, let us give an example of “source routing by name.” This example, which
is based on [19], is sketched in Figure 5. We assume two subnetworks A and X,
of different types, on top of which a kind of network layer has been built. The
route, which is completely determined at the source, is composed of subnetwork
addresses and ends with a selector (or port number) that allows network entities
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing, and Routing
DEST name
:;$$.,
mapping
303
;$~Tc$E;o
route to DEST
souRCE
--
4
1 &$
-------------------
A=l
-
+
x ________-my .__a___
I
I
SUBNET A
Fig. 5.
SUBNET X
Source routing by name.
to multiplex incoming packets among several applications. The route, which will
appear in packets flowing from SOURCE to DEST, is represented in Figure 5.
When receiving such a packet, a network entity takes the next element of the
route as pointed out by the “pointer to next step,” increments the pointer (for
the next entity), and then uses the element as an immediate destination to which
the packet should be sent. So, in Figure 5, the network entity that is serving the
entity SOURCE will use subnet address b to forward the packet to the intermediate entity, which will use subnet address y to forward the packet to the rightmost
entity, which will use port number 3 to deliver the packet to DEST. More precise
and detailed explanations may be found in [19].
What is important to note is that some concepts, such as network layer,
network interface, and network ports or service access points (SAPS), are clearly
defined. But there is no concept of a networkwide address that unambiguously
identifies an SAP, whereas we usually expect such a definition of an address once
a network interface and network SAPS have been defined. In fact, a hierarchical
address like y.3 may be constructed to identify the entity DEST at SAP 3, but
its validity will be limited to subnetwork X; because y has a format proper to a
particular type of subnetwork or the value y may well exist on distinct subnetworks in the system, y.3 would be ambiguous. In other words, nothing prevents
subnetwork addressing spaces from overlapping.
Another example of routing by name is broadcast routing by name. We assume
that each network entity may serve several higher level entities through ports.
Thus, it maintains a table giving the port number (which is a very local address)
corresponding to the name of any local higher level entity. A network entity
receiving a request to send a packet will broadcast this packet (which carries
only the name of the destination) to all the other network entities, each one
having, therefore, the opportunity to check whether the destination name in the
packet corresponds to one of their local higher level entities. In fact this approach
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
304
l
Bernard M. Hauzeur
is used in multiprocessor machines where (simplifying) the network is the bus,
network entities are (the interprocess communication handlers in) kernels on
processors, higher level entities are processes, names are process handles, packets
are interprocess messages,and port numbers may be compared to queue identifiers. This approach is theoretically feasible in computer networks but not
practical for obvious performance reasons. However, it is again proof that the
address concept may be useless, even in the case in which concepts of a layer
interface and SAPS are present.
The above considerations confirm that, from a theoretical point of view, the
concepts relevant to communication are names and routes, and that addresses
are an intermediate form (denoting the communication object bound to the
entity). These considerations have led to the general diagram of Figure 4.
5.2 Variability
Mapping names into routes is confronted with two factors of variability:
(1) Entities are sometimes relocated. They move from one location to another
in the network but keep the same name, however, because names are most often
static. New entities are added, old ones retrieved, and names may change. Then
other routes may be needed to reach the same entity, routes to new entities may
have to be included, etc.
(2) The network topology evolves in time. Adding new subnetworks or gateways creates new routes. Subnetworks or gateways may have temporary failures
or be congested or flooded, thereby raising the need for alternative routes.
Most often in practice, the first stage of mapping (names into addresses) deals
with the first factor of variability, and the second stage of mapping (addresses
into routes) deals with the second factor. So the address concept not only
decomposes the name-into-route mapping into two steps, but also separates the
two factors of variability. One can find here an additional justification for the
practical usefulness of the address concept.
With routing by name, the single name-into-route mapping function should
deal with both factors at a time.
5.3 Address Designs
Major design issues in addressing can be seen as consequences of the level at
which addresses are put between names and routes and, therefore, as consequences of the role assumed by each stage of mapping. Flat addressing schemes
like 48-bit Ethernet addresses can be considered closer to name forms, whereas
partitioned addressing schemes like internet addresses in the TCP/IP, ISO, or
XNS architectures are closer to route forms [4, 7, 13, 271.
6. NAMES,
ADDRESSES,
AND LAYERING
6.1 Definitions
Name, address, and route concepts may apply to any layer of a layered architecture, typically the OS1 reference model. However, in practical implementations
each layer fulfills a specific function, which makes some of these concepts useless
or completely transparent in that particular layer. It is always a subset of these
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing, and Routing
I
305
I
LAYERNil
lt!!.2!4f~
+ I)ENTITY
Fig. 6.
OS1 layered architecture.
LAYER N-l
I
(N- I)ENTITY
concepts and of the relevant mapping functions that are found in each layer.
This point is detailed in Section 6.4.
For the moment, we shall adhere to the most general context in order to
introduce the concepts of names, addresses, and routes in a layer and of relationships between one layer and another.
In the OS1 model, each layer is composed of entities (Figure 6). A title identifies
an entity regardless of its location and is unchanged if the entity moves in any
manner [lo]. A title is the OS1 definition for a static name. A title may have a
flat or partitioned structure. A title is unique within the scope of the title domain.
Title domains of primary importance are the layers themselves.
A service access point (SAP) is an association between two entities in adjacent
layers in which the service is offered by the lower entity and can be requested by
the upper one. An (N)address identifies a particular (N)service access point
(SAP). According to the definition
of an address, the (N)address of the
(N + 1)entity is the name of the (N)SAP it is bound to.
Note that the address is attached to the SAP and not to the entity. If the SAP
is reattached to a different entity, the address identifies the new entity but not
the old one [lo]. This introduces the binding concept.
An (N)address usually refers to an (N + l)entity, which is the entity above the
SAP. Nevertheless, the (N)address may also be used to identify the (N)entity
under the SAP because this association is unambiguous. Indeed, in the OS1
model, any (N)SAP is always supported by a single (N)entity (but note that a
single entity may support several SAPS). Such referencing of (iV)entities by
(N)addresses is sometimes used in optional source routing [4], for example, and
may be found in routing tables of some hop-by-hop routing procedures.
6.2 Addressing and Subaddressing
Addresses denote SAPS that are conceptual attachment points between entities;
therefore, addresses offer a very systematic and convenient way of relating
entities in a layer with entities in adjacent layers.
Addresses also provide for layer-to-layer independence. Indeed, if (N)entities
had to deal with (N + 1)entity names instead of (N)addresses, these (iV)entities
ACM Transactions on Office Information Systems, Vol. 4, No. 4, October 1986.
306
l
Bernard M. Hauzeur
GENERAL
CONFIGURATION
Fig. 7.
Service access points configurations.
would have to know about the existence of (N + l)entities, which is not the case
with (N)addresses.
Moreover, addresses provide for flexible addressing techniques in any layer
when relating (N)addresses to (N)entities and (N)entities to (N - 1)addresses
(see Figure 7). One can see fan-in and fan-out as flexibility
in mapping (N)entity
names into (N - 1)addresses and mapping (N)addresses into (N)entity
names, respectively. Nevertheless, the intermediate step through the (N)entity
name is very often skipped in practice, and (N)addresses are mapped into
(N - 1)addresses in a single step. Correspondence between (N)addresses and
(N - 1)addresses may be hierarchical (subaddressing) or set through mapping
tables [lo]). For these reasons, a name is a rather useless concept below the
application layer.
6.3 General Model
To send a message to a destination entity whose name is known, the name is
mapped into an address and then the address is mapped into a route. Since the
route definition is a list of names, recursivity from layer to layer is suggested (as
can be seen in Figure 4). The resulting expansion is sketched in Figure 8. In fact,
the complete model expands into a tree structure whose root corresponds to the
name of a destination entity in the application layer, and which ends with the
physical routes in the physical layer. Only some depth-first branches are drawn
in Figure 8. It is possible to create similar figures with routing-by-name
procedures at some stages, if desired. In the following, we concentrate on the OSI-like
architectures where each layer supports the concept of an address.
As seen in Figure 8, the general diagram of Figure 4 takes place astride layer
interfaces. This discrepancy between layer boundaries and the general diagram
boundaries may look surprising but is, in fact, very natural. Going from a name,
which identifies the entity with which we intend to communicate, to a route,
which is used for effective communication,
implies that a communication
service
has been offered-and
communication
services are offered at layer interfaces.
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing,
and Routing
307
DESTINATION
(N + 2)NAME
lAYERN+Z
i
-(N+l)ADDRESS
----------
--
(N + 1)ROUTE = {(N + l)NAME,
A
m--m
...,
(N + l)NAME,
B
LAYERN+I
--------
- ____
- _____------_
(N + l)NAME}
DEST:’
4b
(N)ADDRESS
(N)ROUTE = { (N)NAME,
(N)NAME,
Y
X
LAYER N
4
etc.. .
.--------------------------
etc. . .
...,
44
_--------------
(N-1)ADDRESS
4
(N-l)ROUTE
LAYER N-l
Fig. 8.
4
etc.. .
_-----------_-----_-
= {. . . etc . . .(route to X-1)
etc..
.
}
Layered naming and addressing model.
So, (iV)entities perform both the mapping of (iV)addresses into (N)routes
(routing) and the mapping of (N)entities’ names (appearing in (N)routes) into
(N - 1)addresses. In the figure, the lower layer entity that serves Dest is named
Dest-1, the entity that serves A is named A-l, and so on.
In this general model (Figure 8), each name, address, route, and related
mapping functions may be independently described with attributes selected from
the corresponding classifications (cf. Sections 2, 3, 4, or Figure 3). For instance,
names may have a flat, partitioned, or descriptive structure, be static or dynamic,
individual or group, and so forth. The model does not show which particular
(N)entity in an (N)layer is performing the mapping functions or how they are
performed; for instance, an (N)route may be constructed by a single (N)entity
(if there is a single hop to the destination entity, or in the case of source routing)
or by several entities, each one mapping the next step of the route to the
destination (N)address (hop-by-hop routing).
So, names, addresses, and the address-into-route mapping functions in each
layer may be stamped with attributes defined in Sections 2-4, leading to a vast
number of theoretical alternatives, of which only a few are sound and even fewer
used in practice.
6.4 Practical Model
In practice, many intermediate steps in the general model of Figure 8 disappear.
As already said, each layer fulfills a particular role that makes some concepts or
mapping stages impractical, useless, or completely transparent. An example is
given in Figure 9, which represents a typical OS1 architecture. One can observe
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
308
Bernard M. Hauzeur
l
DESTINA T/ON
APPLICATION
NAME
LAYERS 5,6,7
1
TRANSPORTADDRESS
---------
___---------__
-_--_-_--
LAYER 4
NETWORK ADDRESS
--a
_____
- _-_---------____
-___---
LAYER 3c : lNTERNET LAYER
4
INTERNETWORK
ROUTE = {
ADDRESS,
OF 1st IG
-------
ADDRESS,
OF 2nd IG
4
1
SUBNETADDRESS
LAYER 2
Fig. 9.
ADDRESS,
.. ,
X
1
DATALINKADDRESS
+
PHYSICAL ROUTE
LAYER 1
4s
Typical
}
etc.. .
---_-----------_---------
4
PHYSICALADDRESS
------------
ADDRESS
OF DEsT.-’
etc.. .
SUBNET ROUTE
={
ADDRESS,
LAYER 3a,b :
SUBNETDEPENDENT
LAYERS
---------a-.
.. ,
i
ADDRESS }
OF WIG-1
4
etc.. .
etc.. .
--------------------
--------------------NOTE: IG = INTERNET
GATEWAY
naming and addressing architecture.
that this is an instance of the general model of Figure 8 in which many
intermediate steps have vanished and the remaining ones have been particularized. In order to derive this practical architecture from the general model of
Figure 8, the following considerations have been used:
Names are found rather exclusively at the application level and are not used
below this layer. Since the application layer is the layer where human interactions
take place, names are used at this level to identify application entities. On the
other hand, in layers l-6, addresses have many advantages over names (OS1
titles) in relating entities in a layer to others in adjacent layers (cf. Section 6.2).
In the presentation, session, and transport layers (layers 6,5, and 4), protocols
are end to end; thus the route is reduced to the destination entity address, and
the routing function is straightforward.
Moreover, in the OS1 architecture,
presentation and session addresses are equal to the transport address. Therefore, the application
name can be mapped directly to a transport address
(Figure 9).
In the transport layer (4), just as in the data link layer (2), the route degenerates
into a single element and names are not used, the two mapping functions,
ACM Transactions on Office Information Systems, Vol. 4, No. 4, October 1986.
A Model For Naming, Addressing, and Routing
309
(N)address-into-(N)name
and (N)name-into-(N
- l)address, merge together
into a single mapping function, defined in the OS1 reference model as the
correspondence between (N)addresses and (N - 1)addresses. In the transport
layer, even when the transport address is mapped into a single network address,
fan-out techniques may be used; thus, this mapping function should be identified
separately. The same consideration applies to the data link layer.
In Figure 9, the decomposition
of the network layer (layer 3) into three
sublayers is assumed [6]. Sublayer 3a is the subnetwork access sublayer where
some intranet routing functions may take place. Sublayer 3b is the subnetwork
enhancement sublayer that transposes subnetwork services into some uniform
service for use by the internet sublayer. Sublayers 3a and 3b have been merged
in the figure into a single subnet sublayer. Sublayer 3c is the internet sublayer
that provides the networkwide service on top of the independent subnetworks.
The terms network address and internet address are synonyms.
Since names (titles) are not used below layer 7, a route is a list of addresses
(i.e., a particular kind of a list of names). So, network addresses (internet
addresses) are used instead of names to specify the internetwork
route (Figure
9). Such internet addresses are adequate since they unambiguously
identify
internet entities networkwide, as stressed in Section 6.1. Another alternative is
to use a concatenation of some local subnet identifier and a subnet address as an
element of the route in place of the internet address. Then, in an internet gateway
(also called internetwork
router or network relay), the local subnet identifier is
used to select one of the attached subnetworks, and the subnet address is used
to forward the packet over this subnetwork.
Our intent is not to particularize the general layering model of Figure 8 for all
existing architectures. The above example shows that this procedure is simple.
For instance, if we integrate the IEEE 802 type of subnetwork, sublayer 3a would
be empty but some routing functions may take place in the data link layer, which
should also be decomposed into MAC and LLC sublayers [9].
The model of Figure 9 represents only the relations between names, addresses,
and routes in a typical architecture. The complete model is specified when the
characteristics (in terms of attributes defined in the classifications) of each name,
address, and mapping function are specified for each layer, together with the
configuration of entities (fan-in, fan-out, etc.).
Little emphasis has been put on the application layer. In fact, this layer may
itself be decomposed into sublayers where additional mapping functions (i.e.,
directory functions and routing functions) may take place. Let us note also that
a single application name is directly mapped into an address in Figure 9, which
is a simplified view. A more realistic situation may be that the name of a role
(e.g., “department of. . .“) is mapped into several names of services, one of which
is mapped into several names of service agents, one of which is finally mapped
into an address.
7. CONCLUSION
We have tried to lay down classification systems and models that encompass all
existing naming and addressing schemes and most practical issues. We have also
tried to clarify the concepts of names, addresses, and routes. It was mainly the
existence of routing schemes that map a name (denoting a proper entity even if
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.
310
l
Bernard M. Hauzeur
it is numerically coded) directly into a route that has led us to assume an address
as an intermediate form between a name and a route. Names and routes are
deemed the fundamental concepts pertinent to communication;
a name is essential for singling out a destination entity from a collection of entities, and a route,
consisting of a set of names, specifies the path toward that entity.
Nevertheless, in practice, an entity is bound to a communication object through
which it can send and receive messages. In the telephone example, entities are
people and communication
objects are the telephone sets. In the OS1 world,
entities are formal elements of open systems, and communication
objects are
SAPS. As entities, communication objects are denoted by names, which now take
a special format dedicated to machine processing. This is the address concept.
Owing to the process of binding, an address can no longer be used to identify the
communication
object but only the entity to which it is bound.
The diagram of Figure 4 presents the relationships among the three concepts
of names, addresses, and routes. Since a route is a list of names, a recursive
application of this diagram has led to a general tree-shaped naming and addressing model that is partially represented in Figure 8. The combination of this last
model with the classification systems introduced earlier leads to a vast number
of theoretical alternatives, out of which a very small number are practical issues.
A typical OS1 architecture is then presented. It is shown that this practical
architecture is a particular instance of the general tree-shaped model.
ACKNOWLEDGMENTS
I would like to thank my colleague G. Leduc for his pertinent remarks during the
elaboration of this paper, D. Rayner for his comments on a first version, and,
more particularly, Professor A. Danthine for pushing me until the concepts were
polished.
REFERENCES
1. CCITT-ITT
CONSULTATIVECOMMIITEE. Directory System-s. Draft recommendations X.dsO
to X.ds6. CCITT, Sept. 1985.
2. DALAL, Y., AND PRINTIS, R. 48-bit absolute Internet and Ethernet host numbers. In Proceedings
of the 7th Data Communications Symposium (Mexico City, Oct. 26-28). IEEE, New York, 1981,
pp. 240-245. (Also in ACM-SZGCOMM
4,11 (1981)J
3. DANTHINE, A. Network interconnection. In Proceedings of ZFIpIWG6.4 Symposium on Local
Computer Networks (Florence, Italy, Apr.). North-Holland, Amsterdam, 1982, pp. 289-308.
4. DARPA. Internet protocol-DARPA
Internet program protocol specification. RFC 791, Information Sciences Institute, Univ. of Southern California, Los Angeles Calif., Sept. 1981. In
Internet Protocol Transition Workbook. ARPANET Network Information Center, SRI Intemational, Menlo Park, Calif., Mar. 1982.
5. DEUTSH, D. Implementing distribution lists in computer-based message systems. In Proceedings
of ZFZP/ WG6.5 Conference on Computer Message Services (Nottingham, May). Nottingham Univ.,
U.K., 1984, pp. l-11.
6. EUROPEANCOMPUTERMANUFACTURERSASSOCIATION. Network layer principles. Tech. Rep.
13, ECMA, Geneva, Switzerland, Sept. 1982.
7. EUROPEAN COMPUTERMANUFACTURERSASSOCIATION. Layer 4 to 1 addressing. Tech. Rep.
20, ECMA, Geneva, Switzerland, Mar. 1984.
8. EUROPEANCOMPUTERMANUFACTURERSASSOCIATION. Directory service standard-first draft.
ECMA/TC23/84/110, ECMA, Geneva, Switzerland, Sept. 1984.
ACM Transactions
on Office Information
Systems, Vol. 4, NO. 4, October 1986.
A Model For Naming, Addressing, and Routing
l
311
9. INSTITUTE OF ELECTRICAL AND ELECTRONICSENGINEERS. Local area networks standards.
Drafts IEEE 802.1-802.5, IEEE Project 802 Committee, New York, 1983.
10. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Data Processing-Open Systems
Interconnection-Basic
Reference Model. International Standard IS0 7498, 1981 (Available
from American National Standards Institute, New York). (Also in Comput. Networks 5 (1981),
81-118.)
11. INTERNATIONAL ORGANIZATIONFOR STANDARDIZATION. Directory service for OS1 systemsdraft service specification. ISO/TC97/SC16/N1715, Oct. 1983. (Available from American National Standards Institute, New York.)
12. INTERNATIONALORGANIZATIONFORSTANDARDIZATION. Working draft addendum to IS0 7498
on naming and addressing. ISO/TC97/SC16 N1918, June 1984. (Available from American
National Standards Institute, New York.)
13. INTERNATIONAL ORGANIZATIONFOR STANDARDIZATION. Addendum to the network service
definition covering network layer addressing. Draft Proposal 8348/DAD2, Apr. 1984. (Available
from American National Standards Institute, New York.)
14. JANSON, P., AND MUMPRECHT, E. Addressing and routing in a hierarchy of token rings. In
Proceedings of IFIP/WG6.4
International
Workshop on Ring Technology. CT2 2NF, Univ. of
Kent, Canterbury, U.K., Sept 1983, pp. 97-109.
15. MOCKAPERTIS, P. The domain name system. In Proceedings of IFIP/WG6.5
Conference on
Computer Message Services (Nottingham, May). Nottingham Univ., U.K., 1984, pp. 59-70.
16. OPPEN,D., AND DALAL, Y. The clearinghouse: A decentralized agent for locating named objects
in a distributed environment. OPD-T8103, Xerox Office Product Division, Palo Alto, Calif.,
Oct. 1981.
17. POSTEL, J. Internet name server. IEN 116, Information Sciences Institute, Univ. of Southern
Calif. Los Angeles, Calif., August 1979. In Internet Protocol Transition Workbook, ARPANET
Network Information Center, SRI International, Menlo Park, Calif., Mar. 1982.
18. POUZIN, L., AND ZIMIUERMANN,H. A tutorial on protocols. Proc. IEEE 11, 66 (Nov. 1978),
1346-1370.
19. SALTZER,J., REED, D., AND CLARK, D. Source routing for campus-wide internet transport. In
Proceedings
20.
21.
22.
23.
24.
25.
of IFIP/WG6.4
Symposium
on Local Networks
for
Computer
Communications
(Zurich, Switzerland Aug.). North-Holland, Amsterdam, 1980, pp. l-23.
SALTZER,J. On the naming and binding of network destinations. In Proceedings of IFIP/ WG6.4
Symposium on Local Computer Networks (Florence, Italy, Apr.). North-Holland, Amsterdam,
1982, pp. 311-317.
SIRBU, M., AND SUTHERLAND,J. Naming and directory issues in message transfer systems. In
Proceedings of IFIPIWG6.5
Conference on Computer Message Services (Nottingham, May).
Nottingham Univ., U.K., 1984, pp. 13-35.
SHOCH, J. Inter-network naming, addressing, and routing. In Proceedings of IEEE Computer
Conference, COMPCON (Washington, D.C., Fall). IEEE, New York, 1978, pp. 72-79.
SUNSHINE, C. Addressing problems in multi-network systems. In Proceedings of IEEE INFOCOM 82 (Las Vegas, Mar.). IEEE, New York, 1982, pp. 12-18.
TANENBAUM, A. Computer Networks. Prentice-Hall, Englewood Cliffs, N. J., 1981.
TSICHRITZIS, D. Message addressing schemes. ACM Trans. Off. Inf. Syst. 2, 1 (Jan. 1984),
58-77.
WHITE, J. A user-friendly naming convention for use in communication networks. In Proceedings of IFIPjWG6.5
Conference on Computer Message Services (Nottingham, May). Nottingham
Univ., U.K., 1984, pp. 37-57.
27. XEROX CORPORATION. Internet transport protocols. Xerox System Integration Standard XSIS
028112, Xerox Corp., Stamford, Conn., Dec. 1981.
26.
Received February 1986; revised May 1986; accepted September 1986
ACM Transactions
on Office Information
Systems, Vol. 4, No. 4, October 1986.