Subject: [arch-d] On Names and Namespaces

From: RJ Atkinson <[email-masked]>
Date: Sat, 18 Nov 2006 18:09:02 -0500

Earlier, Noel Chiappa said, in part:
% ...the question I am pondering is whether
% we need transport-level names as well...

Then, John Day responded, in part:
 > No. we don't. It turns out that transport isn't as important
 > as we thought. ;-) All we need in transport is a connection-id
 > to distinguish flows. And we have that.

It is not obvious over here that a transport-layer name is not needed
and not useful architecturally.  So maybe someone could expand
a bit further on that topic ?  A bit more rationale, perhaps ?

I suppose your notion is that one could use an application-layer
name (e.g. FQDN) at the transport-layer.  Maybe that's true,
I'm not sure, but I think there are architectural advantages
to having an additional level of indirection at the transport-layer.

Earlier, Noel Chiappa said, in part:
% David and Ran are both (if I understand them correctly) talking
% about having the names for transport-level entities say a little bit
% about where they are (within a local scope), and those names are also
% to some degree naming point-of-attachments, so yeah,
% I guess you are right.

If this was the conclusion from my notes, I was somehow unclear.

Identifiers say *nothing* about where they are -- they are only
naming "stacks" or, if one prefers, "nodes".   Identifiers are
location-independent -- and this property seems crucial for
enabling mobility and multi-homing as first-order capabilities.

Locators are the names with location-dependence, and they specifically
name sub-networks.  And there are separate link-layer names besides
the Locator.

Yours,

Ran
[email-masked]

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Sat, 18 Nov 2006 19:45:08 -0500

>a bit further on that topic ?  A bit more rationale, perhaps ?

What would a transport layer identifier do for you that an 
application name would not?

>to having an additional level of indirection at the transport-layer.

What advantages?  Transport is just an error and flow control 
protocol, another version of LLC or HDLC.  Furthermore, Transport 
only deals with per flow state.  Instance are nice, but not that 
important to this discussion.  To put that kind of identifier in 
transport is a major structural change.

>enabling mobility and multi-homing as first-order capabilities.

Ah, I see.  You want this transport identifier to be the short cut 
handle so when the system moves I don't have to change the mapping of 
application to address.  So what is the big deal? Applications may 
move without the system moving and you have to do it anyway.

>name sub-networks.  And there are separate link-layer names besides

I still don't understand why the data link layer isn't part of the "stack."

Take care,
john