There are at least two ways of looking at the problem of getting the
packet to the right stack.
And, to put the answer before the quesiton, I think the level of
distinction is irrelevant at this stage of the game.
Let us presume that we started with an identifier for something. And we
are going to end up with enough information to delvier the packet.
That information has to include
enough content that the network can delvier the packet to the right
network interface
enough content that the packet will get from the network interface to
the right processing stack.
Now, whether those two steps are represented by two pieces of
information (a locator plus an ESEL),
one piece of information (a locator that is usable by machine packet
dispatch logic)
or three pieces of information (a subnet locator, an identifier usable
for packet delivery in the subnet, and a potentially separate field
usable for intra-machine handling)
Or a variation on three where the identifier covers the last two pieces,
and we are back to two,
and whether these pieces of information are all part of one fixed length
field, one variable length field, or separate explicit fields,
we still have to get the packet there.
Different solutions will parse this differently.
I think what is important for the solutions to be clear about what the
information names / locates, and in what scope.
I do not think it is important that we mandate a very specific meaning
for the term across those solutions. I don't think this particular
ambiguity introduces major confusion, as long as we make sure we know
what the solution we are examining does, and how it enables this.
(This relates to my hypothesis that we need stack identifiers in the
abstract, but not all solutions need to have those identifiers exchanged
on the wire.)
Yours,
Joel
Noel Chiappa wrote:
> From: Christian Vogt <[email protected]>
> I agree that it would be useful to have locators which route to a given
> host -- or better: to a given stack, since this is the entity through
> which one must pass to reach a given service or session.
I've always had this degree of ambivalent feelings about this concept, that
locators can identify 'things' inside a host.
I've always felt like 'the job of the routing is to deliver the packets to
the right network interface, and once that's done, its job is over'. From
then on, it should be the next layer up's job to do demultiplexing - perhaps
with what I have called a Endpoint Selectors (ESEL - a short identifier, with
scope limited to a single interface, which can get a packet to whichever of
several endpoints is sharing a particular interface).
I guess the best counter-argument I've heard is that if you have a 'virtual
machine' setup, each virtual machine thinks it has a virtual network
interface, and that virtual interface needs its interface name. (You can just
do it with ESELs, since each VM would think it's managing the ESEL namespace,
and you could get clashes.) So that would mean that inside the VM system,
packets would have to be 'routed' to the correct VM.
Do note that if we want to support that model (locators for VIs on VMs), that
probably does imply variable length locators... (ducks :-)
Noel
PS: Nobody has any reaction to my comments about models for connectivity?
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
