[e2e] Port numbers, SRV records or...?

[John Day]

At 2:55 -0400 2006/08/10, Dave Eckhardt wrote:
>  >>> 25 years ago we figured out how much naming and
>>>>  addressing we need but we choose to ignore the
>>>>  answer.
>
>>>  Care to supply a pointer?
>
>>  RFC 1498
>
>I've meant to give that a careful read, and this time I
>did--with the result that I'm really unsure what an
>"attachment point" is.

Try Interface.  Saltzer is drawing an analog with Operating Systems, 
where one has physical addresses, logical addresses, and application 
names.  Point of attachment addresses are the first of these.  IP 
addresses are point of attachment addresses because they name the 
interface.

I should have pointed out that Saltzer misses one point, primarily 
because it didn't occur when he wrote.  Routing is a two step process 
(or should be). Routes are sequences of node addresses.  From the 
forwarding table you get the "next hop."  Then you must also keep the 
mappings of node address to point of attachment for all your nearest 
neighbors to choose the specific *path* to the next hop.

Multiple paths between adjacent nodes were rare or non-existent when 
Saltzer was writing.  You will notice that this actually makes a 
cleaner model.

Naming an interface between layer N and N-1 is the same as naming the 
protocol machine at layer N-1.  MAC addresses and IP addresses name 
the same thing.  This has been true since before there were IP 
addresses and was a requirement for IPv6.

>Saltzer himself points out that this is a troublesome
>concept for DIX Ethernet (the old broadcast-along-coax
>kind), with MAC addresses serving roughly but not exactly
>the role.

There is nothing "troublesome" about it. The word Saltzer uses is 
"elusive."  And that is because looking at an Ethernet segment as a 
stand-alone network represents a degenerate case of the structure. 
It isn't a problem.  It is just a degenerate case.  An Ethernet is 
point-to-point and the nature of the beast means that you don't need 
to explicitly keep the "path" mapping.  The structure simply 
collapses as it would for a "network" of two machines connected by a 
wire.

>It's possible to describe an attachment point in a switched
>Ethernet network:  port X on switch aa:bb:cc:dd:ee:ff--but
>the only people who worry about such an attachment point
>are your network operations staff, and only when the machine
>turns into a monster.  A remote endpoint does not need to
>resolve a service onto a node and then the node onto such
>an attachment point for communication to work.

Clearly not.  Since the Internet limps along without half of what 
Saltzer says is needed.  It is just that some things are difficult, 
impossible, or far more complex than they need to be without it.  You 
can make a computer work without application names and virtual 
addresses too.  Doesn't mean I would want to.

>There's more trouble when one considers wireless networks.
>I don't think an "attachment point" can be a (latitude,
>longitude, altitude) tuple, but I don't think it can be
>anything else either.  My "attachment point" could be the

I don't see why it has to be anything like that.  Point of 
attachments need only be unambigous within the scope of that layer. 
They aren't global and they only have to be understood by the other 
elements in that layer.  There is absolutely no requirement for the 
addresses at this level to be "geographic" or even "topological". 
Quite often scope is sufficiently small that enumeration works

>base station I'm registered with, and the architecture of
>cellular phone systems (where phones are seriously not the
>same things as base stations) somewhat argues that way.

It does indeed.

>There are complexities here, though:  in a soft-handoff
>CDMA system, a handset routinely communicates with multiple
>base stations simultaneously--is it x% attached to one
>tower and (1-x)% attached to another?  Here a remote peer
>is firmly not involved in knowing my attachment point--it
>doesn't figure out where I'm attached and then consider
>paths to me.

Nor should it ever be.  This is not a problem.  It is an advantage.

>Things get odder in ad-hoc networks or sensor networks,
>where power control and variable coding mean that each
>node is connected to every other node at some cost (really
>a space of (power,delay) values), which may be varying and
>may be hard to measure.

Not sure I see why this relevant to the problem.

>If "attachment point" is challenged by shared-medium
>Ethernet, switched Ethernet, "wireless Ethernet", CDMA

Which it isn't.

>cellular phone systems, ad-hoc networks, and sensor
>networks, I'm having trouble seeing the crispness of the
>concept--which was apparently clear to Saltzer.  If I've
>missed something obvious, please clue me in...

Take care,
John