Ross Callon (rcallon@SRN-VAX.ARPA)
Thu, 30 Jan 86 14:41:57 EST
The same scheme for combined use of SSAPs and DSAPs was discussed in
802 several years ago, and was heavily beat upon, primarily on the
basis that it conflicted with the reference model. SAPs should be
significant in the context of the rest of the associated address, not
in the context of the other specified SAP. For example, suppose the
ultimate other end of the connection is not on the same LAN, but is on
some other LAN that does not follow your convention. In this case you
won't be able to figure out what to do. Also, since the SAP is supposed
to be a continuation of the address, for traffic in the other direction
you would expect to continue to associate each SAP value with the same
address, (i.e., when you exchange source and destination addresses for
return traffic you would also exchange SAP values). This of course
wouldn't work with the proposed scheme.
If you used the alternate scheme in which each SAP by itself identifies
the user protocol, then these problems don't occur. For example, suppose
that you use an explicit mapping between the SAP and the protocol, and the
other end uses some other scheme (such as table lookup, or it implements
only one protocol and uses the user specified part of the SAP for some
other purpose). Here when you receive a packet you can determine what
protocol it contains, and know what addresses to use for return packets.
Originally the 802 standards were not going to include any SAPs at all.
When the idea first came up I suggested that there was an alternate idea
of a "user protocol" field that would eliminate the redundancy of having
the same field twice. This was rejected quickly, partly on the rather
compelling grounds that saving a single octet on a multi-megabit LAN
didn't seem very important.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:39 GMT