[e2e] Port numbers in the network layer?

[Joe Touch]

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.

>>     - 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.

>> 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.

> 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.

>> 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.

>> 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.

Joe