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