On Mar 29, 2009, at 3:39 PM, [email protected] wrote:
Maybe this discussion about what is a locator (and what is it not)
may benefit from reasoning what makes a locator poor, good,
excellent,...
Heiner
Thinking about this some more...
Given a system that has a notion of geography or topology, we can
assign names to different points within that geography or topology.
So, as a starting point, it seems reasonable to define a locator as
(1) a name for a point (or location) in a geography or topology.
Depending upon the nature of the geography or topology, it may be
possible to devise a namespace (and set of semantics) for these names
so that the name (value) itself (2) encodes information about the
geographic or topological position of the point being named.
I think some people have been defining a "locator" as a name that
meets condition (1). Others seem to have been defining a "locator" as
a name that meets condition (2), and still others seem to be thinking
it must meet (1) and (2) (i.e. have location semantics and be "in use"
in that context).
For example, I would argue that a MAC address meets condition (1) -
i.e. it names a location in a topology - but it does not meet (2),
because it does not encode in the name (value) itself any topological
information. Part of what makes this confusing is that different
types of geographies or topologies lend themselves to varying degrees
of location encoding (2) using known mathematical tricks. For
example, the Geographic Coordinate System (http://en.wikipedia.org/wiki/Geographic_coordinate_system
) embeds the complete details about position in the location's name.
Knowing the name, you know the position. On the other end of the
spectrum is a switched ethernet, where knowing the location name (MAC)
tells you nothing about the relative topological position of the point
being named by the MAC. However, the MAC (in my mind) still serves as
the name of a location.
IP routing usually falls somewhere between these two. The proximity
semantics of IP allow some relative positional information to be
encoded in the name. For this to be of benefit, though, the routing
system must be (a) designed to take advantage of the proximity
semantic (e.g. by passing around prefixes instead of individual
addresses) and (b) the points in the geography must be named in a
supporting manner (i.e. locations named with sets of addresses that
allow for aggregation). What is important here is that "if location
information is only partly encoded in the name, a secondary system
(e.g. routing) is needed to complete the mapping function". I think
this leaves us with a spectrum of cases, for example...
Geographic Coordinate System
- the position in the geography is fully encoded in the name of the
location (coordinates)
- no supplemental "routing system" needed
Internet Routing
- location in the topology is partly encoded in the name of the
location (IP address)
- routing system does *some* work.
Ethernet Switching
- location in the topology is not encoded in the name of the location
(MAC address)
- routing (i.e. switching) system does "all" the work.
A key part of the RRG routing problem (if I understand correctly) is
that it is hard to embed positional information in a location's name
when the geography or topology of the system (graph) has Internet-like
properties. Grids are easy, trees are easy, but Internet-like
topologies are not. So what we do currently (again, if I understand
correctly), is devise the semantics for the IP address namespace to
make it efficient to embed position information for points on a tree,
and then use routing as glue between this tree representation and the
actual topology. As such, if we are relying on aggregation as our
scaling tool, the less tree-like the topology, the more routing state
there will be (even in the *best* case where names are assigned in a
maximally aggregatable manner.)
R,
Dow
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
