Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!harpo!whuxlm!akgua!mhuxv!mhuxt!houxm!ihnp4!ucbvax!pt.cs.cmu.edu!leong%CMU-ITC-LINUS
From: leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: 802.2 SAP's
Message-ID: <8510290013.AA00334@cmu-ws-postoffice>
Date: Mon, 28-Oct-85 19:11:15 EST
Article-I.D.: cmu-ws-p.8510290013.AA00334
Posted: Mon Oct 28 19:11:15 1985
Date-Received: Thu, 31-Oct-85 10:05:02 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 48
Approved: tcp-ip@ucbvax.berkeley.edu


We have been toying around the 802.2 SAP problem for a while.

First of all, we think that RFC 948 should apply for all IP using 802.2
service quite regardless of the underlying network services (802.3,
802.4 or 802.5).

Secondly, the SAP address for IP as per assigned by IEEE is not decimal
96 as in RFC 943, Page 21. IEEE has assigned the patent 01100000 for
IP. In IEEE's notation, the least significant bit is the *leftmost*
bit (section 3.3.1.2 of 802.2). Hence 01100000 is really decimal 6.

Thirdly, having just 7 bit (exclusive of the LSB) for SAP is plain short
sighted giving only 128 SAP's. This is further reduce by the fact that
IEEE has reserved only the range X1DDDDDD (i.e 64 numbers !!). [ It
appears that X0DDDDDD is fair game for anyone ].  I asked Jon Postel
to see if he can get IEEE to get another number for ARP from IEEE. It
looks as though they are quite reluctant to assign one of their scarce
numbers for a protocol rather than a class of protocol.  So, offically,
we are kind of stuck.  There are a number of things we can do :

(a) Twist IEEE's arm until they cough up a number .....

(b) For DSAP, always use X1100000 for IP as per assigned. But for SSAP
field, we will use the un-IEEE reserved convention - X0SSSSSS : Hence
X0100000 will means IP type and X0110000 for ARP.

(c) In view of the IEEE reserved usage of SAP is for really higher level
protocol ID (or equivalent in function to the Ethernet type field),
the SSAP field essentially is redundant (unless there is such unusal
cases where we will like to have two different protocol sets communicating
directly with each other). We can, therefore, bastardise the SSAP field
for our own purpose. Hence SSAP X1100000 can be made to mean IP and
X1110000 for ARP.

My own preference is for (a) then (b).  If (a) does not produce any
result by the end of the year, I will like to produce an RFC based on(b)
to replace 948.

John Leong@*
leong@@h.cs.cmu.edu

P.S. : For those interested in the 802.5 (a..k.a. IBM token ring), there
is, in my opinion, a major oversight - I do not see a maximum packet
size specified any where!!!!  Imagine the case where different interface
cards have different buffer sizes ....... [ we then have to use 802.2's
XID to exchange buffer size information, and, of course, the format
of such exchange is not defined .....]