jas@PROTEON.ARPA (10/26/85)
Given as IBM has annouced their 802.5 network, those of us who use IP are starting to think about running IP over it. I've looked at RFC 948 (Two methods for IP over 802.3), and it mentions the issue of using 802.2 SAP's. With 802.5, we don't have any choice but to use SAPs. There is no type field in the header like there was in Ethernet. There is a SAP for IP, as well as ones for ISO and SNA. However we don't have a SAP for ARP, or anything like it. All three of the 802.[345] networks use 48-bit addresses, so all of them will need ARP to map from 32 bits to 48. (Now is not the time to start using translation tables.) Has anybody seen any efforts in this direction from standards bodies? Who beat up the IEEE 802.2 committee to get the IP SAP in the first place? It would be really nice if there were a good RFC as to how IP runs over 802.2/802.5 before a line of code gets written. Let's not have incompatible IP's. (Of course, maybe all this is solved by 802.1, but I doubt it.) -------
cain@EDN-UNIX.ARPA (Edward A. Cain) (10/28/85)
Working with Rob Rosenthal of the National Bureau of Standards, I put together a case for a SAP for IP using the IEEE 802 committee's rules for standard SAP assignments -- basically arguments about universal use and widespread deployment. The IP SAP assignment for IP was an exception to the usual practice of assigning SAPs to "international standards". I tried the same route for ARP a few months ago, even though ARP isn't nearly as universal as IP. I was told: 1. There is a critical shortage of reserved numbers, even limiting them to the ISO and CCITT standards. 2. There are a bunch of numbers available for unofficial assignment, and one of these numbers ought to be picked for things like ARP. A directory of these unoffical number assignment is available to help avoid stepping on already assigned "toes". 3. Don't push your luck. Ed Cain
raklein@MITRE.ARPA (Richard Klein) (10/28/85)
The Manufacturing Automation Protocol (MAP) is an ISO based internetworking concept. MAP uses TP4 and IP on top of X.25 and 802.2 LLC type 1; 802.4 and 802.3 are currently supported. Plans call for including support for 802.2 LLC type 3 and Proway PLC. The people at NBS (John Heafner, 301-921-3537) and the GM Technical Center (Gary Workman, 313-575-0632) can give you more details on the architecture, protocols, and implementation of the system. A demo of MAP will be presented at the AUTOFACT 85 conference in Detroit, during the first week of November.
leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong) (10/29/85)
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 .....]
Kluger.osbunorth@XEROX.ARPA (10/30/85)
Don't Panic! There are contributions before the 802.x committees which will fix the problem of only 64 SAPs. The best contribution fixes the problem by proposing that one of the reserved 64 saps serve as an escape, opening up another field of 40 bits which is then used to demultiplex protocols. (It'll work very well.) The 802.1 contribution is by Tony Lauck <Lauck%Bergil.Dec@decwrl.Arpa> and Arthur Harvey <GAHarvey%Bergil.Dec@decwrl.Arpa> of DEC. The best would be for you all to go to the next meeting and support the proposal (if you agree with it). For more information, you can contact the proposal's authors. =====>>>> But have an influence, go to the IEEE 802 Meetings !!!! It is ONLY by attending the meetings that the work can be influenced. (The reason we got into this pickle in the first place is because not enough people with internetting experience have attended the meetings in the past.) The next meeting is November 11-15, '85 in Atlanta, Georgia at the Ritz-Carlton hotel in Buckhead. Registration fee is $100 at the meeting. Regards, Larry Kluger Team Leader for Internet Services Xerox Palo Alto
JNC@MIT-XX.ARPA ("J. Noel Chiappa") (10/30/85)
Yow! Can you say 'variable length wrappers'? (Those things give packet switches (routers) fits; unless you are prepared to copy data around, you can always think up wierd situations in which preallocated speace on the front of the buffer for construction of local headers isn't big enough.) How on Earth did they manage to use 64 numbers anyway? Does anyone have a list of the assigned numbers they could post? I'm wondering how long the edifice of computer networks will last before it collapses under the weight of its own complexity and braindamage, like some modern day Tower of Babel. Noel -------