Re: That routing/redirection thing: mapping (?)

["Hilarie Orman" <horman@novell.com>]

In this discussion I've seen five things mentioned in almost all
possible subsets:

1. Names (members of namespaces; namespaces may have subspaces).
2. Metadata included with names (most likely via concatentation).
2.a. (Optional?) Metadata is a namespace identifier.
3. Information used to associate a request (including a name, possibly with metadata) 
    with a server/surrogate/etc. (metaphor: forwarding table).
4. The protocol used to convey the information used in the association is
    exchanged by the entities that will perform the association.
    (metaphor: routing protocol)
5. The methods used by intermediaries to cause
    the requestor to issue a request in such a way that it will
    reach the "correct" server/surrogate/etc. (called "redirection",
    "steering", "direction", etc.)

There is a frequent assumption that the requestor must handle the
request in at least two steps: 1. resolve the name to a transport layer address
2. issues the request using transport layer addressing.
3. possibly receive an application layer command to reissue the request using
 a different name; then goto step 1
 else end

In the first table, item 3 is complicated, because the association might be done
even before the request arrives (via rewriting embedded URL's).  Or it might
be done by a name resolution system.  Or by application layer redirection
as in the second table.  That's why I think that the term "redirection" should
only be used if there is consensus about the frequent assumption above.

Even if you don't like the ponderous nature of this text, I think it may serve
to show why the documents cannot, at this point, be perfect, and why the
discussion seems to go in circles (of redirection) sometimes.

Hilarie

>>> Mark Nottingham <mnot@akamai.com> 11/11/00 01:31PM >>>
On Fri, Nov 10, 2000 at 10:21:03PM -0500, Markus Hofmann wrote:
> Every DIRECTION system consists of two parts:
>   (a) the mapper (i.e. finding the best surrogate), and
>   (b) the actual redirection mechanisms, i.e. the "client
>       front end" that makes use of the mapper result and
>       makes sure that the client request ends up at the
>       correct surrogate.
> We can use the same mapper module with different "front ends", for
> example use the mapper module with a DNS front end or with URL
> rewriting.

Yes. The redirection mechanism could be DNS (possibly through multiple
CNAMEs, DNS hierarchy, etc.), HTTP redirection, BGP funniness, etc. What
they base their information on is a separate matter.

Separate again is reqeust identification - associating a particular request
with metadata indended for it, such as the origin server to use (assuming
it's caching, and not replication, that's being used on the back end -- it's
really just a namespace to stick the request into, based on some aspect of
the full URI).


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)