Subject: [RAM] some draft proposed definitions

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Jun 2007 12:12:18 -0400

Here is a draft proposal for terminology, with the goal
being greater clarity of communication.  This is a starting
point, not an all-inclusive list.

Yours,

Ran

Identifier:	An object that is used only for identification,
		never for forwarding packets or determining location.

ID:		Abbreviation for Identifier.

Locator:	An object that is used only for forwarding packets
		or determining location, never for identification.

Address:	An object that with mixed semantics, where it is
		sometimes used for identity and sometimes used
		for packet forwarding.  Examples include but are
		not limited to IP addresses, which are sometimes
		used to forward packets and sometimes used for
		identity (e.g. in TCP session state).

RLOC:		An object used for forwarding packets
		in the LISP protocols.

Scoped Locator:	A locator that has non-global scope.  Note that
		a scoped locator only has location semantics,
		never identification semantics.

Scoped Identifier:  An identifier with non-global scope.  Note that
		a scoped identifier only has identity semantics,
		never location semantics.

Identity:	A possible property of an object.  Addresses and
		Identifiers are examples of objects that have
		identity semantics.

Location:	A possible property of an object.  Addresses and
		Locators are examples of objects that have
		location semantics.

Identifier/Locator split:	A class of network protocol that
		has no addresses, and only has (pure) identifiers
		and (pure) locators.

Multi-Address split:		A class of network protocol where
		one type of address is used for forwarding in one
		portion of the internetwork and a different type
		of address is used for forwarding in a different
		portion of the internetwork.  Simple NAT is not
		an example of a multi-address split, since the
		same *type* of address (IPv4 xor IPv6) is used
		in all routing domains.

EOF

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "tom.petch" <[email-masked]>
Date: Mon, 11 Jun 2007 12:48:16 +0200

I read the first definition and parted company with you:-(  The way I see it:

Identity is an abstract concept of a something that exists (real or virtual)
that can be meaningfully differentiated from other somethings of the same ilk.
Identifier is what we may then use to differentiate one something from another,
within some set of identifiers (a namespace perhaps).  Hence identifier can be
applied to a stack, a node, a locality, a link, a port, a Universal Resource,
.......

I believe we need this abstraction (and perhaps engineering struggles to deal
with abstract concepts) in this dicussion eg by turning identifier/location
split into stack identifier/location identifier split; which I think would make
for a more focussed discussion.

And I would find the ccamp I-D alluded to earlier clearer if it used identifier
in place of address; it is all about identifiers.

Tom Petch

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 11 Jun 2007 05:57:54 -0700 (PDT)

> terminology...with the goal being greater clarity of communication.

For clarity we may want to start with basics instituting only two properties for an
entity, i.e. an Identifier to permanently name it and a Locator to describe its
current location. The identifier never changes. The locator changes as the entity
moves from one locator to another. The name is globally unique hence the combination
ID + Locator is also always unique. Locators may have a hierarchy and they do not
necessarily have to be unique.

Having only the above two (ID & Loc) eliminates a need for an address (which equals
a locator), a scoped locator and a scoped identifier.

Thanks,
Peter

> 		same *type* of address (IPv4 xor IPv6) is used

____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jun 2007 09:39:55 -0400

Looking at these definitions, and trying to think through more cases, 
I don't think that this actually captures the distinction, at least 
as I think of it.
And I suspect that issue is why people react differently to various 
proposals in which IDs are also used for forwarding.

Lets look at two closely related examples:
Is an IEEE 48 bit "address" really an identifier, a locator, or a 
hybrid.  As far as I can tell, it is strictly an identifier.  It is 
assigned to a particular thing in a way that has no regard to where 
that thing is in any topology.  However, being excessively clever 
engineers, we have then built solutions which allow us to forward 
packets based on that identiifers.  Sometimes even very large 
solutions.  (bridging in all its myriad forms.)  That usage does not 
change the nature of the field.
And before one argues that the MAC was layer 2, not layer 3, remember 
that OSI routing did exactly the same thing with the lower bytes of 
the NSAP within an area.  That potion was an identifier.  It stayed 
the same when the system moved (even if it moved between areas.)

Hence, I think the difference between an Identifier and a Locator is 
in the semantics, not in whether it can be used to deliver 
packets.  It doesn't seem to me that an identifier suddenly becomes a 
locator if in some region we choose to keep track of where the 
identifier can be found.  To take the extreme case, some researchers 
have proposed systems that would use topologically insensitive 
identifiers for routing on systems of the scale of the 
internet.   Without regard to the actually usability of  the specific 
solutions, I think those things used for the end-points would still 
be identifiers, even if the entire system were forwarding packets 
based on them. The bit strings in that case have no location 
semantics in any topology that I can find.

Yours,
Joel M. Halpern

---

From: "Marcus Brunner" <[email-masked]>
Date: Mon, 11 Jun 2007 17:44:09 +0200

Joel,

With the term topology you bring up the issue. A location can actually be specified in at least two different ways. With a

1) topology-bound locator (better term welcome), which is 
- only valid together with a certain topology (examples are IP address, postal address, ..).
- is structured, looking into part of the address you are able to get nearer to the destination (country, city, street, street number, ...)
- you don't need to know the detailed global topology (e.g., internet)

2) coordinate-bounded locator, which is
- a location in a coordinate system (like the 2-dimensional geographic coordinates)
- requires the map/other positioning systems to find the place where you are and a system to find out what direction to go 
- some ad-hoc routing system propose geographic routing

Kind regards,

Marcus

---------------------------------------------------

Dr. Marcus Brunner
Network Laboratories

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Monday, June 11, 2007 3:40 PM
> To: [email-masked]
> Subject: Re: [RAM] some draft proposed definitions
> 
> Looking at these definitions, and trying to think through 
> more cases, I don't think that this actually captures the 
> distinction, at least as I think of it.
> And I suspect that issue is why people react differently to 
> various proposals in which IDs are also used for forwarding.
> 
> Is an IEEE 48 bit "address" really an identifier, a locator, 
> or a hybrid.  As far as I can tell, it is strictly an 
> identifier.  It is assigned to a particular thing in a way 
> that has no regard to where that thing is in any topology.  
> However, being excessively clever engineers, we have then 
> built solutions which allow us to forward packets based on 
> that identiifers.  Sometimes even very large solutions.  
> (bridging in all its myriad forms.)  That usage does not 
> And before one argues that the MAC was layer 2, not layer 3, 
> remember that OSI routing did exactly the same thing with the 
> lower bytes of the NSAP within an area.  That potion was an 
> identifier.  It stayed the same when the system moved (even 
> if it moved between areas.)
> 
> Hence, I think the difference between an Identifier and a 
> Locator is in the semantics, not in whether it can be used to 
> deliver packets.  It doesn't seem to me that an identifier 
> suddenly becomes a locator if in some region we choose to 
> keep track of where the identifier can be found.  To take the 
> extreme case, some researchers have proposed systems that 
> would use topologically insensitive identifiers for routing 
> on systems of the scale of the 
> solutions, I think those things used for the end-points would 
> still be identifiers, even if the entire system were 
> forwarding packets based on them. The bit strings in that 
> case have no location semantics in any topology that I can find.
> 
> Yours,
> Joel M. Halpern
>

---

From: Scott W Brim <[email-masked]>
Date: Mon, 11 Jun 2007 12:40:56 -0400

On 06/11/2007 09:39 AM, Joel M. Halpern allegedly wrote:
> assigned to a particular thing in a way that has no regard to where that
> thing is in any topology.  However, being excessively clever engineers,
> we have then built solutions which allow us to forward packets based on
> that identiifers.  Sometimes even very large solutions.  (bridging in
> all its myriad forms.)  That usage does not change the nature of the field.

Exacto.

Ultimately you need a mapping to a nexthop.  In 802.1d you map
directly from identifier to nexthop.  In other environments you map
from a locator to a nexthop.  Sometimes you need both, sometimes you
it takes multiple lookups, sometimes you do multiple mappings at
multiple points along a path, and so on (a locator need not be the
ultimate end-system locator or even prefix -- it might be an
intermediate point like a tunnel ingress).   But how you get those
mappings can be done by any means, using any kind of information, and
the only thing you can be sure of is the nexthop.

> Hence, I think the difference between an Identifier and a Locator is in
> the semantics, not in whether it can be used to deliver packets.  It
> doesn't seem to me that an identifier suddenly becomes a locator if in
> some region we choose to keep track of where the identifier can be
> found.  

Right, it's about intended use.  Just because something is used to map
to a locator doesn't make it an identifier.

There are two phases to routing, path discovery and path selection.
Path discovery can be aided by dissemination of information and
distributed processing (including most of the routing protocols we
like).  It can be done by probing (PNNI, PCEP, NUTSS etc.).  It can be
done by asking someone who knows more than you do (like DNS).

In the case of SIP you start out with an identifier.  You resolve that
to a locator, and you send an INVITE including your identifier and
locator as payload.

In the case of LISP, you start out with a locator.  At some point that
locator is sent to "someone who knows more", as payload, to map to an
ITR (another locator) and to a nexthop.  This does not make the
original locator an identifier.

>         never for forwarding packets or determining location.

I like this except to avoid ambiguity I suggest leaving out
"forwarding packets".

>         or determining location, never for identification.

Certainly the last part is true, but locators are used for all sorts
of things.  I propose "A locator is a name intended to have
topologically meaningful semantics, in order that it can be used to
determine a next hop for a packet."  That allows other uses.

>         identity (e.g. in TCP session state).

Only if we're talking about the current Internet.  Let's avoid using
this in new architecture discussions.

>         never location semantics.

Don't like them.  Everything has scope by nature.  Sometimes that
scope is global, sometimes not.  Just because we've assumed global
scope in the past doesn't mean that was the right thing to do.

>         Identifiers are examples of objects that have

Let's stay away from identity unless we really need it.  I just spent
two years listening to arguments about it.

On 06/10/2007 23:34 PM, Tony Li allegedly wrote:
> This would be a fine addition to the taxonomy draft, if it isn't there
> already...

Here is my current draft text.  Lixia hasn't had a chance to hack it
up.  All comments appreciated ... :

      <section title="Name">
        <t>A "name" is "an identifier (of no specific syntax or
	  properties) for an object" <xref target="ENDPOINTS"></xref>.
	  "Name" is a general term, and includes more specific subsets
	  such as "locator" and "identifier".</t>
      </section>

      <section title="Locator">
        <t>A locator is a name intended to have topologically
	  meaningful semantics, in order that it can be used to
	  determine a next hop for a packet.  </t>
	<t>Just because a locator is intended to be used in forwarding
	  packets does not mean that it can be used to do so in every
	  part of the Internet.  Locators have scope.  Even when a
	  locator is out of its scope and thus cannot be used for
	  forwarding (it cannot be resolved to a next hop), it is
	  still a locator if it is intended to be used in that
	  way.</t>
	<t>Locators which cannot be resolved to a next hop are said to
	  be "not routable".</t>
	<t>A locator may name an ultimate destination attachment
	  point, or it may name an intermediate point on the way to
	  that attachment point. For example, a locator may name a
	  tunnel ingress point which can be used to reach the ultimate
	  destination.</t>
        <t><list hangIndent="7" style="hanging">
            <t hangText="NOTE:">It has been suggested that "locator"
	      by itself implies global scope, and that if the scope of
	      a locator concept is less than global, it must have an
	      adjective associated with it, for example "routing
	      locator". However, it has also been suggested that
	      "locator" by itself is a generic term for all locators,
	      regardless of scope. To be resolved.</t>
          </list></t>
      </section>

      <section title="Identifier">
	<t>An identifier is a name that is used for identification,
	  never for determining location.  It does not have
	  topologically meaningful semantics.  It names an endpoint of
	  a communication. </t>
	<t>An "end system identifier" names the ???TBD??? layer for
	  that end system. </t>
	<t>"ID" is an abbreviation for "identifier".</t>
      </section>
      <section title="Address">
	<t>Before the idea of separation of identifier and locator
	  became common, "address" was used primarily to refer to
	  locator functions but also to identifier functions.  Because
	  the term is ambiguous, its use is deprecated except when
	  talking about the current Internet</t>
	<t><list style="hanging" hangIndent="7">
	    <t hangText="NOTE:">It has been suggested that "address"
	      should continue to be used for a name that functions as
	      both a locator and an identifier.  To be resolved.</t>
	  </list>
	</t>
      </section>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jun 2007 16:54:07 -0400

I don't know how anyone else reads this, but to me both of those are 
values which provide a location in a topological space, i.e. Locators.
And they have the property, as Elliot said, that if the device moves 
in the topology, the locator changes.
Yours,
Joel

At 11:44 AM 6/11/2007, Marcus Brunner wrote:
>Joel,
>
>With the term topology you bring up the issue. A location can 
>actually be specified in at least two different ways. With a
>
>- is structured, looking into part of the address you are able to 
>get nearer to the destination (country, city, street, street number, ...)
>- requires the map/other positioning systems to find the place where 
>you are and a system to find out what direction to go

---

From: Mikko Särelä <[email-masked]>
Date: Wed, 13 Jun 2007 08:46:00 +0300

Here's my take on some of the definitions.

Identifier: An element of a name space that persistently and uniquely
identifies an entity, e.g. independent of the location of the entity.

Locator: A string that indicates a particular point in the network
topology.

Identification: A means that an entity uses for identifying another
entity, e.g. TCP uses a Locator (and port number) to identify the other
end point.

Address: A locator that is used for identification purposes.

Note that identifiers can be used for forwarding data (e.g. ad hoc
network routing protocols typically work with identifiers that have no
topological meaning) and locators can be used for identification
purposes (as TCP and UDP do).

To me the question seems to be whether the naming should be based on the
usage of an object, or by the purpose for which it was created. In the
first case, you can say that if somebody uses a locator for
identification purposes, then it is also an identifier. In the latter
case, you would name the object based on its primary purpose (i.e. an IP
address would be a locator used for identification purposes and not an
identifier).

If one does go for the former approach, then we will need to have
separate definitions for persistent and non-persistent identifiers and
possibly others, whenever somebody decides to use a new class of objects
for identification. Similarly, if we define a locator based on the idea
that it is used for forwarding, we will have to accept that we will have
topologically non-meaningful locators, i.e. in ad hoc networks it is
common to use flat identifier space for routing. And then we will need
to define topologically meaningful locator and topologically
non-meaningful locator separately.

I think this approach is doomed to unnecessary complexity. Instead, I
would go for the latter approach, and name objects based on their
qualities and then denote the usage separately (i.e. IP address is a
locator used for identification rather than an identifier).

-Mikko