[e2e] Port numbers in the network layer?

[John Day]

At 5:42 PM -0700 4/26/13, Joe Touch wrote:
>On 4/26/2013 3:30 PM, John Day wrote:
>>At 11:46 AM -0700 4/25/13, Joe Touch wrote:
>>>One issue is the need for ports; there's a summary of that here:
>>>
>>>http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01
>>>
>>>Its use evolved to overload:
>>>
>>>     - part of the stream identifier used to associate groups
>>>     of packets (with IP addresses)
>>
>>The source and destination port-ids form a connection(flow)-identifier.
>
>In the Internet, the IP addresses are part of that connection ID, 
>called the socket pair.

I was speaking generally.  With point to point links, you can have 
multiple connections but no need for addresses.  But a connection-id 
is still necessary.

Strictly speaking, the proper way to define connection-id is the 
concatenation of the port-ids to form a connection-id that is unique 
within the scope of the pair of source/destination addresses.

Given that IP is in a different layer than TCP that would seem to be 
the definition that is consistent with that construction.

According to this socket pair definition then, is the connection id a 
Network Layer identifier or a Transport Layer identifier?

>
>>>     - an identifier for the upper layer protocol (service)
>>>     (the dest port, in all UDP packets or in the TCP SYN)
>>
>>Actually, it does not identify the upper protocol or application, but a
>>path to the upper protocol or application.  It is significant that this
>>identified the type but there was no means (unless application specific)
>>to establish communication with a particular instance of an application.
>
>No protocol has a "means" to initiate connection with anything that 
>isn't waiting for it on the other end. In this case, it would be an 
>application listening on the socket. The assumption is both that the 
>application is listening AND that the service (application protocol) 
>is as expected.

Do you mean the something has to be listening before the requesting 
application initiates the connection?  In that case, it is not true. 
It is possible to do and there are protocols operating today that do 
it.  Admittedly, they are not Internet protocols but that doesn't 
matter.

>
>>>FWIW, one way to decouple these two was described here:
>>>
>>>http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt
>>>
>>>It seems fairly clear that a layered architecture needs agreement on
>>>what the layers are. Indications of a particular layer sequence can
>>>occur anywhere - in band at any layer, or out of band.
>>
>>Actually it doesn't.  A complete layered architecture can create layers
>>on the fly as necessary.
>
>You have to have agreement on the method for doing that. Otherwise 
>you're assigning meaning to bit patterns arbitrarily or reading 
>minds.

If you have a complete architecture handles all three phases of 
communication.  This is possible and has been demonstrated.  Again, 
not in the Internet, but it has been done.

>
>>Actually this proposal would have still made
>>them rooted on the IP address, i.e. the portname was a path to the
>>application, not the name of the application.
>
>The portname is the name of the protocol and the application you 
>expect to interpret it on the other end, just as a destination port 
>is.
>
>Yes, the resulting connections still use the current socket pair as 
>the connection identifier, and yes, that still includes IP 
>addresses. This was intended to be compatible with the existing 
>Internet architecture, as noted therein.

Correct.  I assumed that it was trying preserve its limitations.

>
>>>Consider that ethernet ethertype 0x0800 was originally intended to
>>>mean "IP", allowing the IP version number to be determined at the IP
>>>layer, but packet demuxing efficiency concerns resulted in a new
>>>ethertype for IPv6 (0x86DD). So the ethertype includes not only the
>>>upper layer protocol, but it's redundant with the version at the next
>>>layer.
>>
>>Or perhaps IEEE was noting that since the only common fields between
>>IPv4 and IPv6 was the version field that for all practical purposes they
>>were different protocols. ;-)
>
>That's the feature of such a version field.

;-)

>
>>>Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP".
>>
>>What about IPv4:TCP1 thru IPv4:TCP1000?
>
>I was clearly trying to extrapolate only different protocol stack 
>combinations. If you're referring to variants of TCP, those could 
>either be in a single ethertype or 1000 different ones. If you're 
>referring to specific connections, that's a different semantic that 
>doesn't map to my example about ethertypes.

If Protocol-id is to identify the Protocol in the layer above (and 
not just the syntax), then I would assume that I should be able to 
have multiple instances of the same protocol.   For example, I might 
want a different one for different security domains or something like 
that.  So why not have a few hundred of the same protocol?

>
>>>So any "mix and match" architecture needs to have some indication of
>>>what the particular mix is, but it need not be cascaded layer-by-layer.
>>
>>If I understand what you mean by "some indication" I would have to say
>>no it is not required.
>
>"some indication" means either a preexisting agreement at the 
>endpoints or a label either in-band or out-of-band. You can't 
>differentiate various types of stack combinations without any 
>information.

You would be surprised what can happen.

Take care,
John

>Joe