Internet Draft						J. Noel Chiappa
Expires:  yyy xx, 2000					zzz xx, 1999




		    Endpoints and Endpoint Names:
	A Proposed Enhancement to the Internet Architecture





Status of this Memo

	This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
	Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a 'working draft' or
'work in progress.'
	Please check the Internet Draft abstract listing (in the file
1id-abstracts.txt) contained in the Internet Drafts shadow directories
(cd internet-drafts, on ds.internic.net, nic.ddn.mil, nic.nordu.net, or
munnari.oz.au) to learn the current status of any Internet Draft.

	This draft document will be submitted to the RFC Editor as an
Informational RFC. Distribution of this document is unlimited. Please
send comments to jnc@lcs.mit.edu.


Extended Abstract

	Early work on internetworking used a minimal number of different
fundamental objects in the network, and names for them; among them were
"host-names" and "addresses". Experience with internetworking, along with
further reflection on exactly what the fundamental objects in networking are,
have resulted in two conclusions.
	First, early work on networking was not careful to distinguish
between the concepts of an object, and the name(s) of that object. This
has resulted in widespread confusion between the properties of the
name, and those of the object itself. Secondly, the set of fundamental
objects recognized was not rich enough. Thus, difficulties have arisen
when solutions to various problems demanded that objects which were
previously hidden 'inside' or 'behind' other objects be recognized as
separate entities.
	This paper discusses these issues in detail, and, as a result,
defines, and proposes explicit recognition of, a new fundamental object
in internetworking, the "endpoint". It further proposes the creation of
an explicit naming space, the "endpoint name", for these objects. It
gives several examples of existing problems with internetworking which
will be easier to solve if endpoints are explicitly recognized and
named, and examines the pros and cons of a number of potential types of
names for endpoints.


Acknowledgments

	A basic analysis of naming and objects in networks which
introduced the notion that explicit recognition of another important
class of fundamental objects was needed was performed by Jerry Saltzer,
in [Saltzer82].
	In addition to this, and the other sources mentioned in the
list of references, the ideas in this document have been shaped by
(incessant :-) conversation with the members of the IETF, particularly
the members of the Big-Internet mailing list. Space, and time to
research the issue in detail, prohibit mentioning everyone who should
be named here, and my apologies to them all.
	However, a special mention must go to Dave Oran, who pointed
out to me that the objects which should be named in any new namespace
in the Internet architecture are not physical hosts (as in the Saltzer
paper), but more abstract entities; this lead to the creation of the
"endpoint" concept.
	Thanks also go to several people who found the time and energy
to read an earlier version of this document, and send in (gratefully
appreciated) comments on the text: Brian Carpenter, Avri Doria, Robert
Elz, Johna Till Johnson, Frank Kasteholz, and Stev Knowles. My
apologies if I missed anyone who participated during the many years
this paper took to finish off.

	This paper is respectfully dedicated to the memory of Bosko
Brckic and Admira Ismic, and the countless others who have suffered
because of the irrationality of their compatriots, in Yugoslavia and
around the world.


Note

	It is intended that before final publication, to reduce the
bulk of this paper and keep it more sharply focused, most of the more
generic material on general large scale network system design
(contained in Sections 7 and 11) will be moved to a separate paper
which is specifically about such general system design principles.
	This material is placed here temporarily as it is an important
part of the logic behind this proposal, and it is not, so far as is
known to the author, available elsewhere.



1 Introduction

	As mentioned, early work on internetworking used a minimal
number of different fundamental objects, along with names for them, and
did not always clearly distinguish between the objects and the names.
An example of such an early work is [Shoch], which says:

	'The "name" of a resource indicates *what* we seek, an
	"address" indicates *where* it is, and a "route" tells us *how
	to get there*.'

	The use of this set of terms seems to have grown out of earlier
exploratory experience with networking, such as the ARPANET [Heart,
Feinler]. There, "address" had a very simple and straightforward
meaning, it being the concatenation of the number of the IMP the host
was attached to, and the port number on the IMP to which the host was
attached. "host-names" were undoubtly introduced in a fairly ad-hoc way
to make the user interface more palatable.

	However, a crucial (and unfortunately little-noticed) paper
[Saltzer82] pointed out that networking had gone astray. It pointed out
both of the problems mentioned above in the Abstract:

	'This confusion stems sometimes from making *too tight an
	association between various types of network objects and the
	most common form for their names*. *It also stems from trying
	to discuss the issues with too few well-defined concepts at
	hand*.'

	These problems are particularly true of the term "address",
which is used for several different functions, as discussed below. This
multiplicity of roles has led to substantial difficulties as the
functionality and scale of internetworking have grown, as might be
expected. However, up to this point, little or nothing has been done to
attack in the Internet (i.e. TCP/IP) architecture the problems pointed
out by Saltzer.
	As a result, this paper proposes a more limited and clear
definition and use of the term "address", by picking one of the current
uses and limiting the term to refer to that particular one. (The author
has no illusions that this suggestion will be widely adopted anytime
soon, however.) Also, as mentioned above, this paper defines a new kind
of fundamental object, the "endpoint", which already exists in the
internetwork, but simply has not been formally recognized.


2 Terminology of Naming and Binding

	Before proceeding to the technical details, it is important to
understand some definitions about objects, names, and related subjects.

	The terms "object" and "name" are hopefully self-explanatory:
it is crucial to differentiate between the thing itself, and any
identifier (in the generic sense) by which we refer to it. In this
paper, whenever the term "name" is used, unless otherwise explicitly
indicated, the meaning given to it is the generic one of "an identifier
(of no specific syntax or properties) for an object".
	Thus, the phrase "name of a host" does *not* refer to an
existing system of printable strings (e.g "lcs.mit.edu"), or somesuch;
it refers, instead, to the abstract concept of an identifier for a
host. (The term "host-name" is used to refer to such printable strings,
at the possible risk of some confusion, because it is of long-standing
use in the networking community.)

	This may seem confusing (and some might suggest use of a
different term for "name"), but the use of the term "name" in this
manner is established in the literature (along with subsidiary
terminology such as "namespace"), and while use of the term "name" has
perhaps been confused in the networking community, it seems a major
distraction to try and tackle that issue now.

2.1 Bindings and Namespaces

	The association between a name and an object is called a
"binding"; bindings may also map from one kind of name for an given
object, to another name.
	It is important to realize that a single instance of an object
(i.e. a member of an "object class") may have more than one name.
Moreover, each of those names may be drawn from the same class of names
(or "namespace"), i.e. a many-to-one binding; alternatively, each of
the names may be from a different namespace, i.e. multiple one-to-one
bindings.
	For example, the person writing this document is an instance of
the object class of humans, and has several names, from different kinds
of namespaces, such as his 'name' name ('J. Noel Chiappa'), his Social
Security Number (a government supplied personal identification number
in the U.S.A.), etc. However, all the names refer to the same object;
the author.

2.2 Structure and Representation of Names

	The *form* of the names in a namespace is usually driven by the
use to which the name will be put. Any structure in the name is usually
intended to make some operation on or with the name (be it looking it
up in a directory, or whatever) easier. For example, Unix filenames and
DNS names have hierarchical levels, indicated in the name, to allow
them to be looked up in hierachical directories. IP addresses have
structure in them to help them be routed.
	Names may also have multiple "representations", or ways of
encoding the same individual name. For instance, the IP address
"18.8.0.8" (in decimal, printed notation) is the same exact name as the
bit string "00010010 00001000 00000000 00001000" in an IP packet
header; they are just different ways of encoding the exact same
information, just as 12 base 8, and 10 base 10, are the same number.

	A collection of bindings in which a system records and looks up
the connections is called a "context" (sometimes loosely referred to as
a "directory", although this term has other meanings). A context may
either map from names for objects to a direct attachment to the object,
or from one class of name for an object to another kind of name for the
same object, or perhaps some other useful mapping.


3 Existing Objects and Namspaces in the TCP/IP Architecture

	The TCP/IP architecture did not make a clear distinction
between objects and the names of those objects; it also used basically
those namespaces which were in the existing NCP protocol architecture;
i.e. addresses, and host-names.

3.1 IP Addresses

	In fact, however, IP addresses are basically the *only* name
used throughout the TCP/IP architecture, however. They are:

  - Used directly by the routers, as the data in the packet which
    the routers look at to forward (i.e. process) user data packets.

  - Used to name the place in the internetwork (i.e. the destination)
    to which the packet is to be directed to; i.e. the place in the
    internetwork where that host is connected; this is referred to as
    the "network attachment point", or "interface").

  - Used to name the host which is doing the end-end communication.
    They are the only information identifying the hosts on each end
    which appear in any TCP/IP packet headers. They are thus part of
    the identification of a TCP connection, together with a TCP port
    (which simply disambiguates among multiple TCP connections on a
    single host).

As we will see later, loading all three of these functions onto a
single name, and "field" (i.e. a group of bits in a packet, containing
a specific item of information) in the packet, has problems (discussed
below), and it is perhaps best to split these three functions up, to be
performed by separate names or fields.

	(It should be noted that the use of the term "host" here is for
ease of comprehension, and is not absolutely accurate. A more accurate
term would be "endpoint", or "end-to-end entity", but this paper will
defer using that very abstract term until it is more necessary for
exactness.)

3.2 IP Host-Names

	The other existing namespace in the TCP/IP architecture is that
of host-names. Host-names were, and remain, fairly peripheral in the
TCP/IP architecture. Host-names are human-readable strings, which now
contain built in hierarchical structure, and can be looked up in a
distributed, replicated, database called the Domain Name System
[Mockapetris], which maps from DNS names to IP addresses.
	However, this lookup is usually done as the first step in an
application, which from then on uses the IP address as the 'name' of
the entity it is communicating with. In fact, it is possible to open a
TCP connection, indeed to run a TCP/IP application, without use of a
DNS name at all. All that is really needed is the IP address.
	(Using the terminology above, the DNS name actually names an
entry in the DNS directory; this entry has, as one of its attributes,
one or more IP addresses.)


4 Problems With the Existing IP Object Naming Architecture

	A number of problems arise, and a number of capabilities are
harder to provide, because of the fact that one name (the IP address)
is used to identify two completely different things (the host and the
interface). As Saltzer puts it:

	"One way or another, the permanent binding of attachment point
	name to [host] name has made some function harder to
	accomplish...."

This is absolutely on target, as the examples here indicate.

4.1 Problems with Host Mobility

	For instance, a host may wish to move to a different place in
the internetwork, while keeping a TCP connection open. (This facility is
called "mobility", to distinguish it from the case where the host
moves, but does not wish to keep any connections open, which is
referred to as "portability".)
	This is difficult, although not impossible, in TCP/IP, as it
stands. The problem is that TCP connections (and which packets belong
to a given connection) are uniquely identified by the combination of
their (IP_source_address, IP_source_port, IP_destination_address, and
IP_destination_port). To get the packets to a different place in the
network, a different IP destination address ought to be used, but if a
different address is in fact used, the packets will not be recognized
as belonging to that connection.
	Proposed techniques for supporting this facility include using
the IP Source Routing option or encapsulation. Note, however, that in
both of these cases, the name which identifies the host (the IP address
in the useful packet) is no longer the name of the interface; that is
carried either in the SR option, or in the wrapper packet. Providing
the mobile host functionality has required use of two separate names
for the two concepts given above.
	There is another ways to solve this particular problem, if we
do not restrict ourselves to the internetwork layer. We could change
the definition of TCP to allow a given connection to change the values
of (IP_address, IP_port) (either source, or destination), and thus move
to a different location. This is slightly complex to do, and leaves us
without an invariant name for a connection. It also has the disdvantage
that a similar mechanism would have to be created for every different
client protocol of IP; a single generic mechanism would be better. More
will be said about this approach after an alternative is introduced.

4.2 Problems with Other Capabilities

	Other examples are plentiful. Among the things which are made
more difficult by the lack of differentiation between the names of
host, and the interface(s) through which it is attached to the
internetwork, are: mobile processes, multi-homed hosts (which present
many issues, which will not be explored here in detail), and automatic
address reassignment to match changing network topology (since an
address hierarchy is to some degree isomorphic to the topology it
names). Many of these, like mobile hosts, can be attacked via various
ad-hoc mechanisms, but some are very hard.
	For instance, consider a mobile process, which has a TCP
connection open on port X. It wishes to move from the host with IP
address A to the host with IP address B. It might be possible to use
mobile host mechanisms to accomplish this, but difficulties remain.
First, if there were two TCP connections from host A to some distant
host H, H might become confused if A had apparently simultaneously
moved to B, and stayed where it was. Secondly, if some process on B *is
already using* port X, a collision over that port number will occur.
	Again, if the transport layer could be redone, the solution of
being able to change port numbers on the fly would solve this problem,
but the alternative proposed here is felt to be superior.

	Thus, the failure to differentiate between two different
classes of objects (the host itself, and the interface through which it
attaches to the internetwork), along with the names for those separate
objects (using the term "address" for both kinds of name) leads to a
number of problems which cannot be solved cleanly in the current
architecture, although various ad hoc solutions can be constructed.
	A case can be made that a proper solution to this entire class
of problems (and more which are as yet uncovered) requires a major
change, to separate these concepts. How should this be done?


5 A Better Definition for "Address"

	As has been noted above, the term "address" is currently used
to describe a number of conceptually quite different things, resulting
in confusion and poor engineering analysis. Either the term must be
deprecated, or a better definition must be created and adopted. The
latter is preferred here, as the term is quite popular in networking,
and will continue to confuse people unless they start to use it in a
non-confusing way.

	It is proposed that "address" be generally defined to be "the
name of an interface"; the "network attachment point", remember, is the
place in the internetwork where a host is connected; this usually means
a network interface. The packet headers at the network/internetworking
layer may carry the address, as the data item used in determining where
the packets go (as do Ethernet and IP), or they may not (as does X.25).

5.1 Structure of Addresses

	Addresses may be effectively flat, such as in the Ethernet, or
they may have built in structure, as do the addresses in all current
internetworking protocols. If they have structure, that structure is
usually hierarchical structure, put there to help the reduce the
overhead of running the routing mechanisms in the internetwork; i.e.
those mechanisms (routing protocols, etc) which distribute information
on where things are in the internetwork, and compute routes from
sources to destinations.

	At this point, it is worth noting that the addressing
architecture for a internetwork usually makes provisions for naming
topological aggregates as well as individual interfaces; these names
for topological aggregates are usually called 'addresses' as well, so
perhaps a more exact term for the name of a interface would be
"interface address".
	As a side note, any such structure in the addresses must be
basically purely related to topology. The temptation is great to make
it also related to administrative concerns, but for the structure to be
useful in helping reduce the overhead of the routing mechanisms, it
must defer to actual topology first, and administrative boundaries only
secondarily.
	However, a full exploration of the topic of structure in
addresses, and how this structure is used by the routing architecture,
is a complex one which is beyond the scope of this paper. (See
[Chiappa95] for a fuller exploration of this topic.)

5.2 Abstract Definition of "Address"

	This definition seems precise, but there are peculiar instances
in which it is not quite adequate, as a result of which an alternate,
somewhat more abstract definition is also provided.
	A sample problematic case comes with a computer running a
'virtual machine' operating system. Does each virtual machine have a
separate 'address' or not? This depends on exactly what virtual
configuration is modeled by the operating system; one model is that
there is a virtual network inside the computer, to which each virtual
machine is attached through a virtual interface, with the operating
system containing a virtual router which forwards packets through in
each direction. Other models are possible, such as the different
virtual machines all sharing an interface, and the traffic being
disambiguated using some sort of names for the individual machines;
however, the first is the most transparent.
	Another case comes with some switching fabrics, where a number
of otherwise totally independant hosts may share the same physical wire
to the network. Does this interface (i.e. the wire) have one 'address',
or several? To the extent that the local network header has to contain
a different 'destination physical address' to get traffic correctly to
each of the various hosts, it is clear that each host has a different
address.

	Thus, the exact definition of "address", at least in an
internetwork with routers, ought to be "the name of a place to which
the 'last hop' router will deliver a packet", or, more formally, "the
name of a network connection entity to which the system of routers will
deliver a packet".

5.3 Other Terminology

	We noted above that there are several different meanings for
the term "address", currently. We have proposed restricting the meaning
of the term "address" to correspond, more or less, with the second. We
thus need terms for the other two.

	One term that has been proposed for the first, which is the
field in the packets that the routers look at to forward user data
packets, is "selector". This term actually has a slightly broader
meaning than "address", in that it refers to *any* field in the packet
which is used by the routers to decide where to forward the traffic to.
Thus, in an virtual circuit architecture, the "connection identifier"
field in the packet is the selector.
	Datagram architectures conventionally use the address as the
selector, but this may not always be the case.

	The other name which is needed is a name for the host which is
doing the end-end communication. This is the topic of the rest of this
paper. To recap, however, a "network attachment point", or "address",
is (or ought to be), in order of increasing formality:

    - the name of an interface to the (inter)network
    - the name of a network attachment point
    - the name of a place to which the 'last hop' router will deliver a
      packet
    - the name of a network connection entity to which the system of
      routers will deliver a packet


6 A New Fundamental Object, the Endpoint

	Up until now, this paper has assumed that the fundamental
object (other than the interface) which should be named was the host.
This is a fairly obvious choice; everyone has a good idea what a host
is. Also, it is clear that for functionality like mobile hosts, the
host is the other kind of object which needs a separate namespace,
distinct from the place where it attaches to the internetwork.
	This turns out to not be the best choice. There are instances
in which having a host be the other fundamental object does not turn
out cleanly. For instance, in a system with mobile processes, which can
move from host to host while keeping reliable connections open, it can
be somewhat tricky, as noted above, to keep straight which connections
go where.
	A more abstract object, drawn from the philosophical design
base of internetworking, seems to actually be the best choice. This is
the "endpoint". What exactly is an endpoint anyway?

6.1 Endpoints and End-End Design

	The case has been made that many functions of network
communication, such as reliability, can only be implemented on an "end
to end" basis, i.e. between the ultimate source of the data, and the
ultimate consumer. [Saltzer84] puts it concisely:

	"The function in question can completely and correctly be
	implemented only with the knowledge and help of the application
	[entity] standing at the endpoints of the communication
	system."

An "endpoint" is thus defined as one participant of an end-end
communication; i.e. the fundamental agent of end-end communication. It
is the entity which is performing a reliable communication on an
end-end basis.

	In most circumstances, this concept maps in a fairly direct and
straightforward way to the concept of "host". (I.e. if this definition
is a little too abstract to be useful in thinking about endpoints, just
substitute the concept "simple host" in whatever scenario was being
considered.) There are circumstances, however, such as mobile
processes, when an endpoint is clearly not a concrete object like a
host, but a more abstract construct.
	Note that an "endpoint" is a purely networking concept. Many
people, in trying to think about endpoints, try to use existing
fundamental concepts from elsewhere in informations systems, such as
"process", and attach the term "endpoint" to them. This is wrong.
Concepts such as "process" are operating system concepts, and name
fundamentally different things. There might in *some circumstances* be
a mapping from endpoints to processes, or from endpoints to hosts, but
it's not universal. An endpoint is a new concept, a fundamental object
of networking, and *requires* an independent existence.

6.2 Endpoints and Fatesharing

	An alternative way to characterize endpoints uses the design
principle of "fatesharing" [Clark]. Fatesharing is a concept of
internetworking which states that the most robust design occurs when
the "critical state" (i.e. non-replaceable information about the status
of the communication between two end-to-end entities) is co-located
with the end-to-end entities themselves. As that paper puts it:

	'The fate-sharing model suggests that it is acceptable to lose
	the state associated with [the communications of] an entity if,
	at the same time, the entity itself is lost.'

To put it more crudely (in the military environment which provided some
of the impetus for the design of TCP/IP), it doesn't matter if the
connection information is vaporized, if the application which is using
the connection is necessarily vaporized at the same time.
	An "endpoint" may thus be alternately viewed as a "fatesharing
region"; i.e. a boundary drawn around a set of state and/or
computations such that it lives or dies as a unit.

	Note that each process running an application might be seen as
an independant endpoint, since processes are the entities which are
communicating. Also, processes, and the state associated with them, can
normally be terminated individually.
	However, in most operating systems (virtual machine operating
systems, and system which support mobile processes are exceptions), the
division of the state in the system is not clean enough to fully apply
the "fatesharing region" analysis given above, showing that the processes
in this system are not true endpoints.
	In a similar vein, some application might decide that, for the
purposes of providing a high-reliabilty and/or high-availability
service, it wishes to provide for reliable replication of state across
redundant server machines, so that the failure of one machine can be
completely hidden from the clients of that service. (We will leave
aside questions of whether this is the best system-wide way to provide
that capability.) To the extent that a single end-end entity, and a
single fatesharing region of state, encompass several machines, that
group of machines could be thought of, and named, as a single endpoint.

	Again, note that an "endpoint" is a purely networking concept,
and cannot be mapped directly to a concept from elsewhere in
informations systems, such as "process". There might in some
circumstances be a such a mapping, but it's not universal; endpoints
are a networking concept, and have to be understood on their own.

6.3 Endpoints and Transport Protocols

	Note that a single endpoint has, from the point of view of the
network, effectively all the functionality that a host has now. I.e. it
can have multiple connections in a given transport protocol (e.g. TCP);
it can also have a number of separate transport protocols (e.g. TCP and
UDP). An endpoint is not just one TCP connection, or one transport
layer; it is the entire TCP, with all its open connections, other
transport protocols, and everything else that is currently thought of
as being in a host.
	Thus, for example, the the TCP port is still used in exactly
the same fashion as previously; it is used to distinguish incoming
packets for the multiple TCP connections a single endpoint can have. A
given TCP connection is globally uniquely identified by the combination
of source endpoint and port, and the destination endpoint and port.

	To recap, however, an "endpoint" is, in order of increasing
formality:

    - one participant of an end-end communication
    - the fundamental agent of end-end communication
    - the entity which is performing a reliable communication on an
      end-end basis

    - a fatesharing region
    - a boundary drawn around a set of state and/or computations such
      that it lives or dies as a unit


7 The Layer Model of Data Communication Systems

	Before moving on to see where this new concept ought to fit in
the protocol architecture, it is necessary to examine the concept of
layers in some detail. It has been commonplace for some time now to
define complete networking and internetworking systems in terms of
layered models. The ISO reference model is one such. [ISO]
	However, it is unwise to keep the reference model static over a
long time (in terms of number of layers, and what functionality is at
each layer), since this will limit the natural development of the
overall functional partitioning of data communication architectures, as
more understanding and experience are gained.

7.1 A New Layer Model 

	In actuality, the layering of internetwork architectures is not
a simple ladder, but a more complex stucture. Many different local
"network" layers appear underneath a single, ubiquitous, "internetwork"
layer which provides an absolute minimum set of facilities which must
be provided uniformly, on a system-wide bases. More importantly, above
this rests a tree of "transport" and "application" layers, with each
layer from the "internetwork" layer on up supporting multiple client
layers.

	Note that this paper does not follow slavishly the ISO model,
which does not distinguish "network" and "internetwork" layers below
"transport". As noted above, such rigidity can be detrimental to
discussion, evolution, and understanding of new communication
architectures. This modified model, and terminology, provide a clearer
set of terms for use with the latest developments in communication
systems.
	The functional difference between the service model of the
network layer and the internetwork layer is minimal; they both provide
an unreliable datagram service. The difference is the scope of that
service; a network layer is inherently limited in scope, usually to one
particular infrastructure technology, such as Ethernet or X.25. An
internetwork layer is explicitly created to provide a uniform service
interface across many different infrastructure technologies.

7.2 Layering and General System Modularization Principles

	This tendency to use designs which are basically layered, but
with multiple potential clients of most layers, may be easily related
to general system design principles. Most system architecture work is
done by using functional division into modules, and, moreover, modules
in which dependency loops are avoided. [Schroeder, Dijkstra]
	The structure of the typical internetwork architecture is thus
seen as nothing more than the application of this software system design
principle to the protocols of the distributed system which is the network.

	To recap, however, the layer names used below in this paper are:

    "network" - all mechanism pertaining to a single communication
	network which is not convered by the "physical" and "link"
	layers; examples are the MAC layer in 802.5, and the call
	signalling of X.25.
    "internetwork" - the layer immediately above the network layer, the
	layer which is responsible for delivering packets, unreliably,
	from one place anywhere in internetwork to another.
    "transport" - the layer immediately above the internetwork layer,
	which is usually responsible for providing the appropriate
	level of reliability for the end-end channel.


8 Which Architectectural Level is Appropriate for the Endpoint

	Within this layered model, however, the question arises as to
at which layer should endpoints appear? The two most obvious
possibilities are either the internetwork layer, or the transport
layer. It seems fairly obvious that the correct answer is the
internetwork layer, for a number of reasons.

8.1 Why the Internetwork Layer?

	First, if it is decided to add support for explicit naming of
endpoints, this allows the naming of endpoints to be provided once,
rather than needing to replicate it for each transport layer. There
does not seem to be any need for the flexibility of allowing different
transport layers to define their own endpoint namespaces.
	Moreover, a single endpoint name can then be used to refer to
an entire collection of transport communications, using different
transport protocols, all of which may be associated with a single
actual endpoint. The entire set may be dealt with as an aggregate, e.g.
for purposes of changing the address to endpoint name binding.

	Second, any mechanism provided using the address to endpoint
name binding is thus available to all transports. For example, if it is
decided to support "visible" mobility (i.e. mobility in which the
non-mobile entity is aware that the other end has moved, e.g. to
prevent "triangle" routing through a base station) by the ability to
change the endpoint-address binding, this basic mobility mechanism,
once implemented at the internetwork layer, would automatically be
available to all transport layers.
	Numerous other applications for using an address to endpoint
name binding hidden in the internetwork layer exist, such as support of
multi-homed hosts (i.e. ones with more than a single interface, and
thus, even in the current system, more than one address).

	Finally, the internetwork layer has the job of carrying
packets, unreliably, from one entity to another in the internetwork.
The transport layer communicates between fate-sharing regions, i.e.
endpoints. If the transport layer is to be simplified as much as
possible, and know only of endpoints, then the entities the
internetwork layer deals with, as far as its clients are concerned,
ought to be endpoints.

	In short, they are at the internetworking layer to allow the
binding from the interface to the endpoint to be examined or changed in
that layer. If one wants to be able to pick up a transport layer
connection and move it to a different place, invisibly to the transport
layer, it has to happen *below* the transport layer.

8.2 Use of Endpoints in the Internetwork Layer

	This does not mean that endpoints are ubiquitous in the
internet layer; e.g. routing is not concerned with them. It is
perfectly appropriate to visualize the internetwork layer as being
split into two sub-layers, one of which, the lower, knows only about
interfaces and addresses, and the higher of which knows about endpoints
as well, and maintains the binding between interfaces and endpoints.
	Alternatively, one can visualize endpoints and their bindings
as residing in a "shim" layer which is interpolated between the
existing internetwork and transport layers. This option is discarded
since layers should only be inroduced when needed, and there does not
seem to be a major utility in being able to use the internetwork layer
without dealing with endpoints. If needed, a special endpoint name
meaning "the internetwork layer at this address as a whole" could be
defined to serve that purpose.

	It thus seems that the appropriate layer to know about the
address to endpoint name binding is the internetwork layer.


9 Namespaces for Endpoints

	Having decided that we need to recognize endpoints, and name
them, the next question is "what should the names of endpoints look
like"; i.e. how many namespaces do we need for endpoints, and what do
those names look like.
	To answer that question, it is necessary to answer the question
of what these names are going to be used for. Remember, "the form of
the names in a namespace is usually driven by the use to which the name
will be put".
	Unfortunately, there is no clear answer to the question of
where, and how, these names are going to be used. Moreover, several
potential uses have requirements which are effectively diametrically
opposed, so perhaps there is no single namespace that will do what we
want. Instead, we might have multiple namespaces for endpoints, each
with different characteristics that suit them to different uses. If so,
presumably there would be in addition some system to map from one
namespace to another.

9.1 Useful Characteristics of Endpoint Names

	Some likely useful characteristics of endpoint names, and the
ramifications of those characteristics, will be explored first.

9.1.1 Global Uniqueness

	One likely important characteristic of at least one kind of
endpoint name eventually adopted is that they are unique (i.e. no two
endpoints anywhere in the network can have the same name).
	This uniqueness can be ualified in two ways: spatial and
temporal. The first refers to the scope over which a name is unique,
and means that at any given time, no two endpoints with identical names
are active. The second refers to the time period over which the
uniqueness of a name is valid, and at the extreme, no two endpoints can
ever be referred to with the same name. The former seems more useful,
but the latter is potentially useful as well.
	If the system will not function correctly if two endpoints with
identical names exist, then ensuring uniqueness is an especially
important goal. This is the characteristic of endpoint names which may
present the most difficulty. 

	It is important to understand that the system should not depend
on the assumption that two endpoints with identical names do not exist.
Such a condition is bound to occur sooner or later, either through
human error, faulty software, or some similar cause. Should this
happen, the system must detect it, and call attention to it, so that it
may be corrected.
	Should the system fail to do so, it would probably either fail
in some hard-to-understand way, or, even worse, continue to function,
but erratically, without detecting that there is a problem. So, the
system must detect this failure in cases where it would be a problem,
but it is not necessary to provide an automated solution, if it happens
rarely enough.
	A number of strategies exist for ensuring this uniqueness.

	One is to require that all endpoint names be registered in a
directory; if an endpoint attempts to check to make sure that its name
is registered, and another endpoint is already registered with that
name, the newcomer can detect a problem right away.
	Another strategy is a probabilistic one. If the namespace for
endpoints is very, very large, then if an endpoint randomly chooses one
to use for itself, the chances that it has picked a duplicate name are
very small. The possibility of failure should not concern anyone,
since, as pointed out above, duplicate endpoint names are likely to be
encountered *anyway*. In the low-probability event that a duplicate
name is picked, the mechanisms to handle duplicates caused by error
should handle this case too.

9.1.2 Topological Insensitivity

	Another important characteristic of an endpoint name, for most
purposes, is that it ought to be "topologically insensitive"; i.e. it
does not depend on the location of the endpoint in the network.
	In particular, it ought to stay the same if the endpoint is
detached from the network and re-attached to a different place on the
network. If the name is linked to its location in the network (as an
address is), then if an endpoint moves to a new location (either
because of mobility, or because of a change in service provider, or
whatever), and thus receives a new endpoint name, without a more
complex mechanism it will be impossible to tell that it is the same
endpoint.
	It is possible to work around this, obviously, but it does
introduce complexity. The advantage (in simplicity, etc) of having one
name which is invariant when an endpoint moves is one of the chief
advantages of naming endpoints, so it would be extremely foolish to
discard it.
 
9.1.3 Portability

	This is closely related to, but not exactly the same, as
topological insensitivity. It means that the endpoint can move from
machine to machine in the network. For example, it a particular machine
has two endpoints associated with it, and it is desired to move one
endpoint to another machine, unless the scheme for naming endpoints
allows one to be disassociated with its "host" machine, and associated
with a new one, this will not be possible.

9.1.4 Local Creatability

	In some circumstances, operational considerations make it
likely that a useful characteristic of endpoint names (and endpoints)
is that they can be created locally, without reference to a central
endpoint name allocation authority. To put it another way, it is useful
to be able allocate as many new endpoint names as you like, without
ever having to go back to a central registry to get more.

9.1.5 Anonymity

	There are circumstances in which it is desirable to have
endpoint names which are anonymous; i.e. there is no way for one entity
which is communicating with a remote entity to find out anything about
the remote entity. All the first entity has to identify the remote
entity is a endpoint name which, while it can be used to identify the
remote endpoint, and communications from it, cannot be used to find out
anything more about the remote entity.

9.1.5 Distributed Catalogueabilty

	Another likely important characteristic of any globally unique
endpoint name is that these names probably, but not necessarily, ought
to be a form that can be catalogued and looked up; i.e. a binding from
the name to other useful information is easily found in some sort of
distributed database of these bindings. It is generally useful to have,
somewhere in the architecture (often at a low level), names which can
be used (i.e. turned into useful information) without any further
reference to a catalog (e.g. hardware network addresses), although this
can be worked around, of course.
	For instance, a name might come with a list of addresses for
repositories of bindings in which it can be found; this is both
inconvenient (for human use), as well as having the disadvantage that
the utility of the name will degrade as those addresses become invalid,
either because the repository is no longer there, or because the
repository no longer contains correct information about the bindings of
the name.

9.1.6 Embedded Organizational Affiliation

	Another characteristic suggested for endpoint names is that it
be possible to tell, from looking at the endpoint name, what the
organizational affiliation was. It is not clear how useful this is.
Since this is only one attribute about a name, and, equally, one that
could be kept in a catalogue, as one of many attributes of a name, this
is probably not the best use of structure in an endpoint name.
	The most appropriate use of structure in a name for use in a
large-scale communication system is to help with finding the name in a
distributed catalogue. This structure might indicate organizational
affiliation as a side-effect, but that is secondary to the main goal,
finding the entry in a catalogue.

9.1.7 Fixed Length

	This is a final potentially useful characteristic of endpoint
names, but it is a syntactic attribute, rather than a semantic one, and
thus rather less important. Obviously, software for fixed-length fields
is slightly easier to write than software for variable length fields,
and potentially more efficient. However, using a fixed length has
proven in the past to usually be painful, and the benefits of such a
limitation would have to be weighed most carefully before it could be
accepted as the best choice.


Obviously, not all of the characteristics in the lengthy list above
have to be met, and some are potentially in conflict - e.g. 'local
creatability' and 'fixed length' almost certainly conflict. Some that
seem to be in conflict are not necessarily so - for example, 'anonymity
and 'catalogueabilty' might seem to be in conflict, but it is easy to
provide both, by having part of the namespace that is anonymous, and
part which is catalogued. However, the more of these characteristics
that can be provided, the more powerful and useful the namespace will
be.


9.2 Potential Uses of Endpoint names

	Here are some potential uses for endpoint names, along with the
implications for the form of endpoint names.

9.2.1.1 Unique Identification of Endpoints

	The most obvious use of endpoint names is to globally uniquely
identify endpoints in some transaction. That is, two participants in a
conversation can be sure that the identity of the entity of the other
end is what they think it is, if endpoints are globally uniquely named.
(There does not seem to be any reasonable use for endpoint names which
are not globally unique, in terms of simply identifying endpoints.)
	This is particularly true of long-lived communications; they
can be sure that the identity of the other end remains constant, even
if the endpoint moves, etc. Communications relating to dealing with the
fact that one end is moving will be made simpler if there is an
invariant name for the entity that is moving, one that stays the same
for the entire time.

9.2.1.2 Form of Names for Unique Identification

	Other than the characteristics of topological insensitivity, and
global uniqueness, names with a variety of characteristics are suitable
for this use.

	One question that would need to be answered immediately about
these names is whether or not they would be used directly by people. It
is desirable to have, somewhere in the overall design, names which are
amenable to human use; people may pass these around 'out of band' to
inform other people of the 'location' of useful things. (If it seems
from this text that the author views the needs of humans as somewhat
less important, in the long run, than the needs of the machines, there
is perhaps some truth to that! :-)
	It is not clear if endpoint names, even ones used for long-term
identification of endpoints, need to have this characteristic. Perhaps
some other namespace will be the one used by humans, and endpoint names
can be looked up, when needed, from these names.
	If the endpoint names are not directly human-usable, probably
those names will be the ones that can be looked up in a directory, and
the endpoint names will not need to have that capability.

9.2.2.1 Endpoint Names in All Packets

	Another possible use is to put them in the headers of every
packet, to identify the endpoint for which a given packet is destined.
Thus, when the packet gets to the eventual destination interface, if
there are multiple endpoints at that interface, the packet can be
delivered to the correct one.
	Note that the routers would not generally make decisions about
what path to send a packet along using this field, since it is assumed
that such names are not topologically sensititive. (It was at one time
thought that thes endpoint names might usefully form part of the names
of flows, but later developments appear to reduce the chance that this
is useful. [Castineyra])
	Note, at this point, that whether or not the packets include
addresses is a separate question; as addresses must, of necessity, be
variable length, and include a lot of structure, there are good reasons
for proposing designs (e.g. flow-based forwarding systems) in which
addresses are not included in most packets. Further discussion of this
topic is beyond the scope of this paper, however.
	
9.2.2.2 Form of Names for Inclusion in All Packets

	This use would tend to lead towards names that are as short as
possible (since they will be present in every packet, and thus
represent overhead), and fixed length (to ease processing costs, again
since they are always present).

	The first question that would need to be answered here is
whether or not these names would be globally unique or not. Unlike the
identification function mentioned above, names with a smaller scope
could perform this function as well as fully globally unique names. As
long as the packet can be fairly reliably delivered to the scope in
which the non-globally unique name can be correctly resolved, global
uniqueness is not needed.
	Obviously, names which are globally unique are potentially more
useful, but have the disadvantage that they would have to be longer, in
addition to which we would need a more complex allocation mechanism,
particularly if they were to be reliably globally unique.
	If we did have non-globally unique names for endpoints in
packets, we would probably still need some globally unique names (such
as the one referred to above), and a mechanism to allocate the
locally-unique short ones, and map from them to the globally unique
ones.

9.2.3.1 Endpoint Names in the Checksums of All Packets

	If one important function of endpoint names is to make sure
that packets have arrived at the endpoint for which they were destined,
there is an interesting technique for providing this functionality,
without actually including the names in each packet, with obvious
ramifications for the form of the endpoint names (i.e. relaxed
constraints).
	There is a technique which allows one to 'include' a data item
in a packet without actually having a field containing the data item be
present in the packet, if that data item is the same for every packet
of a given connection. That technique is to include the data item in
the "pseudo-header"; i.e. a header which is not actually present in the
packet, but which is constructed at the endpoint on each end, as part
of the computation of the end-end checksum. [Postel80]

	In the pseudo-headers used to date, all the items used in the
pseudo-header actually occur in each packet, and in simplistic
implementations the contents are copied into the pseudo-header for each
incoming or outgoing packet, before computing the "partial checksum" of
the pseudo-header. (Unless the pseudo-header is physically located in
memory immediately preceeding the actual checksummed area of the
packet, it is first necessary to compute an intermediate checksum
result for the pseudo-header, and feed that intermediate result into
the computation of the full checksum on the actual packet.)
	An obvious optimization is to compute the partial checksum for
those parts of the pseudo-header which are normally invariant for the
life of the connection (such as addresses, protocol, etc), and save
that, to save recomputing it on each packet. The obvious next step is
to have that pseudo-header include items (such as endpoint names)
which are not actually in each packet.
	No computational per-packet overhead is incurred by adding
these items, but if a packet is received with an end-end checksum
computed with 'incorrect' values for these items (i.e. not what the
receiver expects), it will fail the end-end checksum on the receiving
end.

	If we take the simple step of saying that endpoint names are
exchanged when the connection is set up, then we can specify that the
pseduo-header used in computing the end-end checksum of data packets
include the endpoint names. That way, if a packet arrives, somehow, at
the incorrect endpoint, if the packet is not rejected for other reasons
before it arrives at the checksum routine (for an invalid port number,
say), the checksum calculation will reject the packet.
	It may seem a bit bizarre, that the checksum is being used to
cover items that are not actually transmitted, but it is quite
functional.

	One might argue that there is a slight loss of reliability,
since in the current pseudo-header, the data item is effectively 'in'
the packet twice; once as the actual fields, and once folded into the
checksum. In this scheme, the endpoint names are only included once,
and in a compressed version, to boot. They are therefore more
susceptible to undetected errors. This is, strictly speaking, true, but
closer anlysis shows that this is actually not very likely.
	The chance of a packet arriving at an incorrect endpoint, but
one which both i) still gives the correct checksum value (when the
checksum is computed with the wrong endpoint name in the
pseudo-header), and ii) in which the packet appears to be a valid
packet for an open connection on that endpoint (i.e. port and sequence
numbers, etc match) is still a lot smaller than the chances of
accepting a damaged packet which is actually for that connection, but
one which still produces the correct checksum.
	Thus, if the risk of undetected data errors is seen as
acceptable, then that event is still more likely than failing to detect
a packet arriving at an incorrect destination.

9.2.3.2 Form of Names for Inclusion in Checksums

	 One major advantage of this technique is that one could then
use endpoint names, for reliable identification purposes in each
packet, without the overhead of carrying the names in each packet. This
would allow such things as much longer endpoint names,and variable
length names, that would not be as plausible if the full endpoint name
were included in each packet. So, this tends to remove limits on the
form of endpoint names, while not much reducing their utility.
	As a side benefit, as mentioned above, if the items included in
the pseudo-header which are invariant over the life of the connection
are put together, one can precompute the partial checksum of those
items at the time the connection is opened, and avoid the overhead of
computing that partial checksum on all packets. This is particularly
true of variable length names, which are slightly more expensive to
handle. Thus, variable-length names (always preferable for their
flexibility) could be added, at no per-packet overhead cost.


9.3 Other Characteristics of Endpoint Names

	One question that arises is whether a single endpoint could or
would have more than one endpoint name. It seems fairly unusual that a
single endpoint would need more than one EID. The whole concept of an
endpoint is that it *is* indivisible, so it's not as if the endpoint is
going to split in two, and each half needs a distinct name to take away
with it, or anything like that.
	Still, it might be useful to allow an endpoint to have more
than one endpoint name, so that it can masquerade as multiple
endpoints. Perhaps there are in fact circumstances in which it might be
useful to relax that, just as there are cases in which we allow one
interface (the object) to have more than one address (the name for the
object).
	One possibility which has been mooted is for use with
multi-level secure systems which, will probably need an endpoint name
per sensitivity level, if someone decides to get serious about
security. Security concerns might dictate a separate name for each
level, although looked at from a fate-sharing viewpoint, the system
would still be a single entity.
	The disadvantage of having several endpoint names for one
endpoint is hopefully obvious; if one has one endpoint, and two
endpoint names, one can't tell by inspecting the names that they refer
to the same endpoint.

	The other case of non-one-to-one mapping between endpoints and
endpoint names, i.e. of having two endpoints with one name, is not at
all desirable. One cannot differentiate between the different endpoints
based on the name. (This does not cover such things as the redundant
server machine example given above.)


10 Some Examples of Endpoint Names

	With the above background as a guide, we can now look at some of
the types of names that have been suggested for use as endpoint names.
	It is not clear at this point which namespace, or combination
of them, is the appropriate selection. More needs to be fully decided
about the rest of the system, and what the endpoint names would be used
for, before such a determination could be made.
	However, some of the candidates which have been discussed at greater
or lesser length can be detailed here.

10.1 Addresses

	One obvious suggestion is to name endpoints from the same
namespace as interfaces; i.e. the address namespace. This is probably
not a good idea, going back to the concept that "the form of the names
in a namespace is usually driven by the use to which the name will be
put".
	The names for interfaces (addresses) are structured to be used
by the routing; i.e. they have a hierarchical structure which is
visible to many of the entities which use the routing. The hierarchy is
related to the actual topology of the network. They are not densely
allocated (since they are set up to allow growth without renumbering).
	In many ways, the form of addresses is driven by the
requirements of the uses to which they will be put, and these
requirements are almost certain to be, in many ways, exactly opposite
to those of addresses.

	Additionally, addresses are topologically sensitive, whereas an
explicit goal of endpoint names, mentioned above as highly desireable,
is to *not* be topologically sensitive. While it would be possible to
define part of the address space to not be topologically sensititve, it
seems an inevitable source of confusion. Better to keep the two well
separated.
	With this in mind, all of the other suggest endpoint namespaces
have the characteristicthat they be topologically invariant. (This is
only really useful for the globally unique names, since the utility of
topological invariance for names with only limited scope is limited;
they provide mobility, etc, but only within that limited scope).

10.2 Endpoint Identifiers (EID's)

	An EID is an endpoint name which is fixed length, 'shortish'
(i.e. 48 to 64 bits or so, enough to provide globally unique names for
some time to come at modest usage rates), globally unique, and
topologically insensitive.
	The 'shortish' attribute comes from the fact that they would
be included in all packets, so examination of a packet would show the
globally unqiue identity of the endpoint to which the packet is
destined (and probably its source as well).

	One issue to note with EID's, particularly smaller ones, is
that they do need an allocation system; some sort of administrative
structure to allocate them. As an aside, such an allocation structure
might well provide structure in the EID's themselves that could be
exploited in a directory of EID's, to allow occasional EID->something
translations.
	This should not be difficult to manage; we have a mechanism to
allocate unique 32-bit numbers now, ones that necessarily have more
structure in them than EID's do. If addresses are asssigned by some
more automatic system (which is what needs to happen for them anyway),
the existing number allocation system could be used for EID's.
	The other issue with EID's is the fixed length. This has a
number of ramifications, above and beyond the issue of running out of
them. For instance, it would probably be difficult to arrange to local
creation of EID's, to use in identifying sub-computations.

10.2.1 IPv4 Addresses as EID's

	One possible example of an EID is to reinterpret the IPv4
address as an EID. This was, in fact, the case in the scheme which was
the original motivation for EID's - one which allowed interoperable
migration of IPv4 [Postel81] from an 'address based' paradigm to an
'endpoint-name based' paradigm, as part of a deployment of a new
routing and addressing architecture for IPv4. [Chiappa91]
	The basic concept was that the 32 bit 'address' fields in the
IPv4 packet, and the names in them, would be reinterpreted as endpoint
names; EID's. This would allow definition of an entire new addressing
structure and namespace, one with a syntax, scaling and organization
more suited to use with routing in a global-scale communication network
with flexible capabilities (such as support for Quality-of-Service,
etc). [Little] The new routing and addressing system could then be
deployed as an adjunct to the existing internetwork layer.
	Once that was done, it would be easier to replace the rest of
the original internetwork layer, if and when that became desireable,
since there would be a major piece in common between the old and new;
the routing and addressing architecture.
	The EID concept actually killed several birds with one stone
here. First, it would provide an interoperable deployment path for a new
routing and addressing architecture; no host modifications of any kind
were *required* before the new system could be deployed. Second, it
would upgrade the basic architecture by separating out the addressing
and endpoint naming functions. Third, and very importantly, it would
also extend the lifetime of the existing IPv4 packet format.

	This is because a fixed-size space used for unique names will
provide, in practice, many more names than a space of similar size used
for structured, topologically-sensitive names (i.e. addresses). The
namespace utilization (i.e. the ratio of the number of actually used
names, to the number of theoretically possible names) is poor with
addresses, because of the large amount of structure they need.
	For instance, it's very hard to use a fixed size namespace
well, since some branches of the address hierarchy are denser than
others, and in the less dense branches, space is not utilized well.
Even without this effect, if the branches are all equally well
populated, the cumulative inefficiencies of a multi-layer addressing
hierarchy are substantial. For instance, in a hypothetical addressing
hierarchy where there are five levels of abstraction, and each level
manages a 30% utilization rate (not bad, for addresses), then the
overall utilization efficiency is less than 1%.
	On the other hand, unique ID's can be allocated more in a
serial manner, which can lead to very dense utilization. If the space
is allocated in small blocks, in serial fashion, it can be assumed
that, on average, extremely high utilization is obtained at the time
the namespace fills up. The calculation is identical to the calculation
of the utilization of disk space, allocated in blocks: if an average
name user has N blocks of names, then all but the last are full, and,
on average, the last will be half full. Thus, the utilization will be
(N + 1)/2N. It does not take a very high average number of namespace
blocks per name user to asymptote to effectively 100% usage.
	Of course, very large users may allocate more than one block at
once, which would reduce the utilization, and there might also be a
hierarchy of allocation authorities, which would have the same effect.
However, careful tuning of the block size at each level in the
distribution system (to balance between unused space, and the overhead
of going back to the next higher level of allocation authority for
another block) should minimize this; the usage will sill be very high,
compared to addresses.

	Thus, given the denser utilization of the limited size IPv4
32-bit namespace, this would dramatically extend the lifetime of IPv4,
and with much less disruption to the hosts. By making the 32-bit fields
and names into EID's and allowing maximum utilization of the namespace,
IPv4 could support, more or less unchanged, up to perhaps 10^9 hosts
(assuming 25% utilization of a flat namespace, which should be
reachable with reasonable allocation policies); this is a *lot* of
hosts.
	The ramifications of this extension of the lifetime of IPv4 on
the overall process of evolution of the network architecture are beyond
the scope of this paper, but it would obviously provide a lot of time
to investigate, design, experiment with, and modify, more advanced
successors to IPv4.

10.2.2 IEEE 48-bit Interface Addresses as EID's

	Another possible allocation mechanism that has been suggested
is to use an existing space of unique names, such as the IEEE 48-bit
physical interface naming space. Use of this particular namespace does
present some problems, such as: how to deal with the duplicate numbered
interfaces which occasionally crop up; what to do when an interface,
with embedded number, is moved from one machine to another; etc. It does
provide a source of relatively unique numbers which needs no further
organizational support, though.

10.2.3 Part of the IPv6 128-bit Addresses as EID's

	Another option which has been examined at some length is the
possibility of specifying that part of the IPv6 address be used as an
EID. [O'Dell]
	The GSE proposal includes a number of ideas that are not
related to the thrust of this document though, in particular the idea
that the information about the location of the host, and/or information
related to the path to be used to get to it, be inserted by border
routers as the packets leave the local region.

10.2.4 Utility of EID's as Endpoint Names

	It must be understood, when evaluating the utility of EID's as
endpoint names, that a great deal of their charm arose from their
ability, if the option of reinterpreting IPv4 addresses as EIDS was
chosen, to i) provide an interoperable deployment path for something
that was a radical change to the existing internetwork level
architecture, something which is a substantial accomplishment, and ii)
extend the lifetime of the existing packet format to the maximum degree.
	However, one should not lose sight of the fact that the mode of
operation here, in which endpoint names appear in full in every packet, and
the names have the characteristics of EID's, in the end represents an
answer to a very restricted question; how to work within an existing
design. If one were to design a complete communications architecture from
scratch, one might well find that an alternative namespace for endpoints is
actually superior.

10.3 Endpoint Selectors (ESEL's)

	ESEL's, again, are endpoint names which would be present in all
packets. However, unlike EID's, they are not globally unique, but only
unique in some more local scope. This would allow them to be shorter,
and, also, probably somewhat easier to allocate. At one extreme, ESEL's
would only be unique at a given interface address. The names could thus
be fairly short, say a byte or two.
	While not providing a globally unique name, they do allow for
several endpoints to be co-located, and for incoming packets to be
demultiplexed between them. Other methods are available to do this,
however, including use of flow-identifiers to direct packets without
other endpoint identification to the appropriate endpoint.
	Obviously, if ESEL's were used, and several different endpoints
were at a given address, some out of band mechanism would be needed to
inform a given distant entity what the ESEL was for a particular
endpoint that that distant entity wished to communicate with. It would
probably not be useful to store this information in the DNS, as it is
likely to be too dynamic.

10.3.1 Reuse of Existing Fields as ESEL's

	One interesting variant on the ESEL idea is to effectively
reuse existing fields to provide ESEL functionality; the most obvious
example is the TCP port. If a single host support more than one
endpoint, and the selection of which endpoint is actually desired is
accomplished by passing a full endpoint name at the time the connection
is opened, from then on incoming packets can be directed to the correct
endpoint by use of the port.
	Of course, this has the potential to conflict with the
portability characteristic, in that that port may already be assigned
on a distant host. However, a mechanism which can inform the far end of
the connection that other end has moved to a new machine could also
give it the new port.

10.4 Domain Name System (DNS) Names

	An obvious, ready-made, namespace for endpoint are DNS names.
These have the advantage of being an existing system, with an
allocation system all worked out.
	Among other advantages of DNS names, since they are variable
length, and composed of a variable number of levels, there is no danger
of running out of them, and new ones can be allocated locally by
appending some locally unique identifier to the DNS name of the entity
creating the new endpoint name.
	They would probably not be suitable for inclusion in each
packet, of course, at least not directly; this would limit their
ability to be used as demultiplexors. However, an additional ESEL field
in the packets would provide this capability; the full DNS-type
endpoint name would still be used both at the time the connection is
set up, and in the end-end checksum pseudo-header.

10.5 Public Keys

	One interesting idea for what endpoint names might look like
comes to light when it is considered that in the network of the future,
it will be necessary to have encryption keys, or other "secrets" (a
term for any information which is held privately) for use in
authentication. For an entity to simply have a globally unique name is
not enough; any other entity can masquerade as that entity by simply
knowing that endpoint's name.
	Use of public-private key systems (where non-symmetrical keys
are used for the encryption and decryption process, and one is known
publicly, and the other known only to the 'owner' of the key-pair)
provides an obvious source of endpoint names; the public keys. One big
advantage of using these is that rather than needing to associate a
public key with an endpoint name (a process needing a mechanism that is
in itself a point of attack, let alone extra complexity), one data item
serves two purposes, indivisibly.

	Also, these keys are large enough that the resulting namespace
is large enough that collisions are, for all practical purposes,
impossible. (Since a name collision would imply that either party can
read the other's confidential material, a name collision here has other
negative consequences as well!)
	These names do have several disadvantages: since they are
effectively randomly scattered across the namespace, it will be
difficult to use these names in a catalog, and they are probably too
long to use directly in each packet for endpoint identification

	If private keys are used, it is critical that any fields
containing them *not* be fixed length. Either of two circumstances
might call for changing the length; the key length may need to be
extended, to keep the effective real-time computational difficult
constant over time, or because an algorithm has been broken, and a
replacement needs a different key size.

10.6 Uniform Resource Names

	Uniform Resource Names (URN's, [Sollins], [Moats]) are another
possible source of endpoint names. URN's are intended to serve as
persistent, location-independent, names for a number of different
classes of objects. Sub-sets of the URN namespace might have restricted
syntax, and different sub-sets of the URN might have separate allocation
and resolution mechanisms.
	Almost any possible form of names for endpoints, including DNS
names, could thus be embedded in a subset of the URN namespace used to
name endpoints. (All comments above, about the advantages and
disadvantages of DNS names, would thus follow to use of URN names that
had the characteristics of DNS names.)
	The advantages of using a subset of URN's (presumably one
specifically tailored to the needs of naming endpoints) to name
endpoints remains unclear, though.

10.7 Other Possibilities

	One can continue to invent other possibilies for endpoint
names. One suggestion is to use fine-grained physical location (perhaps
from a system like GPS) as part of an endpoint name. Another suggestion
is to make some sort of timestamp part of an endpoint name. Both of
these provide some information on the origin of the name, information
which may also be of use in some other way, and are strategies which
increase the probability that the names are globally unique.
	Any such alternatives would have to undergo engineering
analysis to decide if the advantages of a such a name are worth the
costs of using it, an analysis which cannot be performed here.


11 Do we Really Need Endpoints and Endpoint Names?

	Is such a major change needed? Are there not other, simpler,
solutions (such as allowing a TCP connection to be indentified by
changing host/port pairs)? The answers to these question comes from
design principles for large scale systems.

	There is some skepticism that such generic principles exist, or
that they would apply in this case, but the author has no doubts on
either score, and strongly believes that they are worth taking note of.
Once these principles are outlined, that framework can be used to
examine the worth of explicit recognition of endpoints, and endpoint
names.

11.1 Increased Functionality and System Death by Entropy

	First, a common 'failure mode' for large systems is the
accretion of many small, poorly integrated changes. A large system
will, over its lifetime, generally be called upon to support needs
which were unforseen at the time the system was originally designed.
Often, the changes made to support these additional requirements are
added by engineers other than the original designers. In those
circumstance, those engineers usually take the path of least effort
(and intellectual arrogance :-), and, rather than perform a sweeping
upgrade to the architecture which provides the desired capability as
part of a coherent rethink, add a small change which does just what is
needed.
	This kind of caution is often what is needed; however, there
are circumstances in which it is inappropriate. If another similar
missing capability is detected, and another small change added, these
changes take on the appearance of 'warts' on the design. Had the
engineers performed a more global analysis of the situation, it would
have shown that a more thoroughgoing upheaval would not only provide a
single (usually simpler) mechanism to meet both needs, but the
resulting system would be better situated to support more unforseen
needs than the original system.
	This seems to be exactly the situation at the moment with the
Internet architecture; either a number of small, poorly designed and
integrated changes can be made to the internetwork layer to support
such capabilities as multi-homed hosts and mobile hosts, or a more
sweeping rethink and redesign can be performed. This should produce not
only a design with cleaner functionality (and more of it), but a
refreshed architecture with a longer useful life.

11.2 Shared Mechanisms and System Scale

	The second system design principle worth noting is that in
small systems, it often works to intermingle the support of two
functions in a single mechanism. As a general system design principle,
as systems get larger, one winds up pulling functions apart into
separate mechanisms.
	The reason is obvious: a small system can withstand functions X
and Y being done half-way well by one mechanism, but as the system gets
larger, X and Y usually have to be done much better. Generally, there
are problems of scaling, etc, and one can't do both things any more
with just one mechanism; one winds up with two, each of which does one
thing well.
	Another way to look at this is to recognize that the less
something does, the less chance there is that it has been done wrong,
in ways that won't appear until too later. Things which do just one
thing, and well, seem to age better than things that try to do several
things at once, and do none well.

	One non-obvious corollary to this system design principle is
that systems which explicitly utilize two separate mechanisms have, in
the long run, greater simplicity than those with only one.
	This may seem counterintuitive, that two mechanisms wind up
simpler than one, but the reason is simple. As the users try and do
more things with the system, and expand its capabilities, the lack of
sound underlying mechanisms causes capabilities to be added in an ugly
and complex way. In the long run, the decision to take the "simpler"
approach of a single mechanism is seen to be a false economy.

	A classic example of this general principle, of small systems
being able to do two things with one mechanism, is the ARPANET, which
performed both routing and congestion control with one mechanism
[Heart, McQuillan]. Current designs perform them with two separate
mechanisms [Castineyra, Partridge]. The mechanisms will have to
interact, certainly, but that is a very different thing from using a
single mechanism.
	Again, this is exactly the situation with the Internet; the two
functions of interface identification and host identification used to
be performed with one mechanism, one name, the IP address. Two
different namespaces are needed, each with different characteristics
appropriate to the tasks they have to do.

11.3 Incremental Interoperable Change

	Finally, large scale communication networks present a unique
challenge to the system designer.
	It seems that in general the best method of handling extension
of a system is a process of incremental change, where experience is
used, together with analysis, to plot future changes. This is simply a
reflection of the fact that human foresight is a limited tool, and one
subject to error. Experience often provides lessons which it is
impossible to forsee, with the result that the best method of evolving
a new design is a process in which there is rapid feedback from real
experience.
	This model works well for individual systems, but not so well
in large scale networks. The problem is that upgrading a stand-alone
system is a problem with localized impact; a new version can be
deployed one machine at a time. An installed and functioning
communication system, upon which a large user community relies,
presents a fundamentally different challenge, since to make a change
requires a process of interoperable deployment. This acts to limit the
kinds of changes that are practical.
	The design philosophy that must apply in these large
communication networks is "maximize the lifetime (and flexibility) of
the architecture". Design tradeoffs (i.e. optimizations) that will
adversely affect the flexibility, adaptability and lifetime of the
design are not not necessarily wise choices; they may cost more than
they save. Such optimizations might be the correct choices in a
stand-alone system, where the replacement costs are relatively small,
and the process is easier to manage; in the global communication
network, the replacement costs are very much higher, and the process is
incredibly difficult.
	It is impossible to predict what the Internet is going to look
like over a long time period. This being the case, it is impossible to
"build to requirments", since we have no idea what those requirements
will be. We have to perform the unique challenge of producing a design
that that function perfectly well under conditions which the designers
don't have the slightest imagination of.
	This has been achieved by past designers, and in those cases
where it has been achieved, some of this success is due to luck, but
not all of it. In information systems, the best path to achieving it
seems to be a process of trying to understand the fundamentals of what
is really happening in terms of the information handling, and providing
a system which supplies those fundamentals in a clear way, but in a
design that contains flexibility, adaptability, and generality.
	This generality, of course, has costs. Is there almost
certainly some useless extra and unneeded generality, in a system
designed with this kind of methodology? Of course. However, the costs
of the extra generality that turns out not to be needed are almost
certainly less than the costs of not having any of the generality that
one cannot *at this point in time* predict the need for; much of that
generality will one day prove useful, and in retrospect a bargain.


12 Advantages Of Explicit Recognition and Naming of Endpoints

	Bearing the above system design principles in mind, it is now
possible to again ask the questions about whether such a major change
is needed, and whether there are not other, simpler, solutions, and
answer these questions in that light.

	The single most important reason to explicitly recognize and
name endpoints in the internetwork level is unfortunately not a
concrete one involving a specific facility or capability.
	It is, rather, the indistinct and abtruse one that endpoints
exist (in some abstract way), whether we deign to recognize them or
not, and attempting to create architectures which do not explicitly
recognize them *must inevitably* lead to designs which are not as
flexible, clean, etc as those that do.
	Put in more concrete terms, this argument for explicit
recognition of endpoints, and naming of them, says that doing so will
result in substantial improvements in overall utility, directness,
simplicity, robustness, flexibility, etc; these are all properties
which are treasured highly in designs that have to have a long
life-time.

	To come at the same basic point, but from another angle, it is
important to recognize and name endpoints, as a separate and distinct
class of entities from interfaces. At the moment, we have no namespace
at all for the former.
	The three different uses for existing IP addresses (as laid out
in section 3.1) in fact are a perfect example of the system design
principle laid out in section 11.2 - that a single mechanism may work
well to perform several functions when a system is small, but will
show increasing difficulties as the system gets larger.
	A separate endpoint naming space will separate out endpoint
identification from addressing, allowing (for instance) different
addressing schemes to be used without host involvement.

12.1 Advantages Of Explicit Recognition and Naming of Endpoints in IPv4

	At a more mundane and practical level (but not one without
significant benefits), interpretation of the existing 32-bit fields and
names in IPv4 as EID's would allow deployment of a new addressing
structure without mandating changes to the hosts. It would also
significantly extend the usable lifetime of that 32-bit space, and thus
of the IPv4 packet format.







Author's Address

   J. Noel Chiappa
   Grafton, VA 22392

   Phone: (757) 898-8183

   EMail: jnc@lcs.mit.edu



References

[Castineyra] Isidro Castineyra, J. Noel Chiappa, Charles Lynn, Ram
Ramanathan, Martha Steenstrup, "The Nimrod Routing Architecture", RFC
xxx, University of Southern California, Information Sciences Institute,
Marina Del Rey, Calif., yyyy 19zz.

[Chiappa91]	J. Noel Chiappa, "A New IP Routing and Addressing
Architecture", Internet-Draft, September 1991.

[Chiappa95]	J. Noel Chiappa and Yakov Rekhter, "Fundamentals of
Routing and Addressing In Extremely Large Networks", RFC, in
preparation.

[Clark]		David D. Clark, "The Design Philosophy of the DARPA
Internet protocols", Proceedings of the SIGCOMM '88 Symposium, Computer
Communications Review, Vol. 18, No. 4, pp. 106-114, August 1988.

[Cohen]		Danny Cohen, "On Names, Addresses and Routings",
Internet Experiment Note #23, University of Southern California,
Information Sciences Institute, Marina Del Rey, Calif., 1978.

[Dijkstra]	E.W. Dijkstra, "The Structure of the 'THE' Multi-
Programming System", CACM 11, 5 (May 1968), pp. 341-46.

[Feinler]	Elizabeth Feinler and Jon Postel, Eds., "ARPANET
Protocol Handbook," SRI International, Melo Park, Calif., January,
1978.

[Heart]		Frank Heart, Robert Kahn, S. Ornstein, William Crowther
and David Walden, "The Interface Message Processor for the ARPA
Computer Network", AFIPS Conf. Proc. 36, pp. 551-567, June 1970.

[ISO]		International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection - Basic Reference Model",
ISO-7498-1984, October, 1984.

[Little]	Michael Little, "Goals and functional requirements for
inter-autonomous system routing", RFC 1126, University of Southern
California, Information Sciences Institute, Marina Del Rey, Calif.,
October 1989.

[McQuillan]	John M. McQuillan, Ira Richer and Eric C. Rosen, "The
New Routing Algorithm for the ARPANET", IEEE Transactions on
Communications, COM-28(5); pp. 711-719, May 1980.

[Moats]		R. Moats, "URN Syntax", RFC 2141 University of Southern
California, Information Sciences Institute, Marina Del Rey, Calif., May
1997

[Mockapetris]	Paul Mockapetris, "Domain Names - Concepts and
Facilities", RFC 1034, University of Southern California, Information
Sciences Institute, Marina Del Rey, Calif., November 1987.

[O'Dell]	"GSE - An Alternate Addressing Architecture for IPv6",
Mike O'Dell, (Work in progress).

[Partridge]	Craig Partridge, "Proposed Flow Specification", RFC
1363, University of Southern California, Information Sciences
Institute, Marina Del Rey, Calif., September 1992.

[Postel80]	Jon Postel, "User Datagram Protocol", RFC 768,
University of Southern California, Information Sciences Institute,
Marina Del Rey, Calif., August 1980.

[Postel81]	Jon Postel, "Internet Protocol", RFC 791,
University of Southern California, Information Sciences Institute,
Marina Del Rey, Calif., September 1981.

[Saltzer82]	Jerome H. Saltzer, "On The Naming and Binding of
Network Destinations," in 'Local Computer Networks', edited by P.
Ravasio et al., North Holland, Amsterdam, 1982, pp. 311-317. RFC 1498,
University of Southern California, Information Sciences Institute,
Marina Del Rey, Calif., September 1992.

[Saltzer84]	Jerome H. Saltzer, David Reed and David Clark,
"End-To-End Arguments in System Design", ACM Transactions on Computer
Systems, Vol. 2, No. 4, November 1984.

[Schroeder]	Michael D. Schroeder, David D. Clark, Jerome H.
Saltzer, Douglas H. Well, "Final Report of the Multics Kernel Design
Project", TR-196, M.I.T. Laboratory for Computer Science, Mass., June,
1977.

[Shoch]		John F. Shoch, "Inter-Network Naming, Addressing and
Routing", Internet Experiment Note #19, University of Southern
California, Information Sciences Institute, Marina Del Rey, Calif.,
1978. Also in 'IEEE Proc. COMPCON Fall 1978', pp. 72-79.

[Sollins]	Karen Sollins, and Larry M. Masinter, "Functional
Requirements for Uniform Resource Names," RFC 1737, University of
Southern California, Information Sciences Institute, Marina Del Rey,
Calif., December 1994.




Expires:  yyy xx, 2000					zzz xx, 1999