JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (10/20/87)
The bridge vendor whose bridges require source routing is IBM. I do not know whose bridges restrict the size of the packet to 508 bytes of IP data, but I sincerely hope it isn't IBM. You see, I don't really expect IBM to notice that their product has this sort of mis-feature, and I do expect them to sell a great deal of whatever it is, mis-feature or not, so my own code is likely to have to live with whatever they do (like MS/DOS). jbvb
minshall@OPAL.BERKELEY.EDU (10/21/87)
In a recent posting I asked an essentially political question about the status of source routing within the IEEE 802 committees. Today I checked with someone who has been attending some of the 802 meetings. She directed me to Daniel Pitt, of IBM Raleigh (dreaded home of SNA) as being a good contact on the 802.5 committee. I then spoke with Daniel Pitt. From what my two informants of today said, the situation appears to be that the 802 committee decided that the 802.5 committee (which was the only one which had come forward with the source routing proposal) could do whatever it wanted in terms of bridges, AS LONG AS their "product" (ie: end result) would inter-operate with the "internetworking" standardized on by the 802.1 committee (see below). In addition, the 802.1 committee was charged with coming up with a proposal for "internetworking", with the proviso that the 802.1 proposal had to be "shown" to work with all the MAC-types (ie: 802.3, 802.4, 802.5). At this point, 802.5 and 802.1 are going ahead with their separate but not antithetical proposals (and each proposal is, apparently, in the "bits and bytes" stage). Daniel Pitt, though understandably unwilling to predict the future success of any proposed standard, mentioned that the current 802.5 work looks like source routing as documented by IBM in the "Token-Ring Network Architecture Reference" book. Greg Minshall ps - 802.1 is a group which is supposed to tie together the work of the 802.2 committee (which is mostly a Data Link Layer-entity) and the three MAC committees (802.3,4,5, the physical layer). 802.1 is also supposed to explain how the 802 family fits into the ISO OSIRM, how network management works, and how "internetworking" happens.
lamaster@pioneer.arpa (Hugh LaMaster) (10/21/87)
I understood from previous postings that the encapsulation of
IP on 802.2 was to be compatible with 802.3 4 5 + (FDDI) etc.
I don't really understand the source routing issue, but I thought
that IBM planned to use it for SNA over 802.5 type stuff...No? I
would hate to see multiple encapsulations for 802.2 depending
on whether the medium is 802.3 4 or 5 ...
Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov
(Disclaimer: "All opinions solely the author's responsibility")minshall@OPAL.BERKELEY.EDU (10/22/87)
Hugh, The catch is that, as defined by IBM and (apparently) by the current work in 802.5, "source routing" is a MAC issue. MAC, which means Media Access Control (or some such) is separate from LLC (== Logical Link Control). 802.2 is LLC; if source routing were a LLC entity, then it would apply to all 802.X MAC layers. I *suppose* that some of the past controversy about source routing was whether it belonged at the MAC layer, or at the LLC layer. To me, it seems it belongs at the LLC layer, since routing information (in the IBM scheme) is acquired by an LLC-layer broadcast (a TEST or XID command) which picks up (and returns) routing information. Additionally, the IBM "SEND_MAC_DATA" primitive (which corresponds with the 802.2 MA_DATA.request primitive) supplies, in addition to the MAC address of the destination, the "source route" (previously acquired). Anyway, source routing is purely an 802.5 issue. The source routing happens during 802.5 MAC encapsulation, not during 802.2 LLC encapsulation. The 802.2 encapsulation remains the same. What it does mean, I guess, is that the interface (in your kernel, or whereever) between the LLC and MAC layers is different with an 802.5 MAC than with an 802.3 or 802.4 MAC. Hope this sheds a bit more light. Greg Minshall
jas@MONK.PROTEON.COM (John A. Shriver) (10/22/87)
Source routing is not soley in internal 802.5 issue. Unfortunately IBM (a/k/a 802.5) source routing IS an LLC issue, and in turn a Network layer issue. IBM source routing is implemented in 802.2 class 2 quite transparently. When the stations begin their virtual circuit, they exchange XID messages. These XID messages are sent as limited broadcast, and serve as the needle to resolve a source route. The source route is stored inside the LLC connection block, and the class 2 application can be completely ignorant of it. The arguments to L_DATA_CONNECT.request remain the same for all three of the MAC layers. (This is the TRANSMIT.I.FRAME in the PC, you only supply the data, it provides all LLC and MAC headers.) The problem is that 802.2 class 1 cannot implement source routing transparently, or does not in any current IBM implmentation. It is the responsibility of the LLC user (the NETWORK layer) to discover and provide the source route. Basically, there is an extra argument to the L_DATA.request in 802.2 of "remote_source_route" ONLY in the case of 802.5 as the MAC layer. (This is the TRANSMIT.UI.FRAME in the PC, you have to supply the LLC & MAC headers, including the Routing Information Field.) The reason class 1 is not transparent is very primitive: there is no connection block to store the source route in. IBM has no reason to be concerned, since all of their "important" software uses class 2 (SNA, NetBios). Unfortunately, the rest of the world (IP, DECnet, XNS, Novell IPX, Banyan Vines) is using class 1. So far, only IBM has tried to implment source routing on any class 1 application, namely their IP. The most interesting point to note is that if any of the bridges on a source route fail, everything goes crazy. There is no dynamic recovery implemented. Your 802.2 class 2 virtual circuit will DIE. Your class 1 application will have packets black holing. The frame copied bits will not provide the sender ANY indication that this is happening. (I don't even know if the first-hop bridge sets the frame copied bit.) This is distinctly inferior to the current state of the art in IP, XNS, or DECnet routing, where the routers will find a new route before the Transport layer times out. This black-hole phenomenon will cause users to ask for more layering violations. As is, ARP has become hardware dependent for 802.5. Now people will want to flush the 802.5 ARP/source route cache when a TCP connection is getting timeouts. The problem is that one layering violation usually causes more of them to propogate up through the layers.
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (10/23/87)
Well, one of the problems here is that IBM has defined 802.5, more or less, and they seem to have felt they wanted to sell: 1) MAC-level bridges that don't learn connectivity like Ethernet bridges do, instead requiring that packets be source-routed, and 2) MAC-level bridges which can only hack datagrams about 1/10th the size of the MTU of the connected LANs. Given that they are still successfully selling EBCDIC architectures, I'm not sure what we can do besides document what they have legislated. So, ARP and related MAC-level routing schemes take a nasty hit, and useful MAC-level transparency amongst 802.x LANs becomes much harder to achieve. Anyway, at the 802.2 level, the encapsulation is indeed identical. As Greg has pointed out, 802.2 is LLC, not MAC. jbvb
minshall@OPAL.BERKELEY.EDU (10/23/87)
John, Yes, I see what you mean. It does appear (from the IBM documentation) that the LLC-layer hides source routing in type 2 service. This is, I suppose, one of the big reasons for complaints about source routing. You mention that if one of the bridges goes down, everything goes crazy. However, this is the case with MAC-level bridges (eg: TransLan), and with "proxy ARP routing". So, this doesn't put source routing in any worse company than those (although none of those are what I would pick for a network - mainly for this reason). Now, I have previously asked the question "what's the politics of source routing in the IEEE 802 committees?". I then reported on a conversation with an IBMer on 802.5. From that conversation, it seemed that source routing was, probably, only a matter of time (though the IBMer, to his credit, was very cautious about anyone's ability to predict the outcome of any given standardization process). I have talked to one final 802 person. This person is Mick Seaman, of DEC, who is on the 802.1 committee. He prefaced his comments, and reiterated throughout, that his comments were HIS PERSONAL comments; that they DID NOT necessarily represent DEC or IEEE 802 views. Mick Seaman's introductory remarks were that source routing was something IBM was interested in in order to support existing IBM products. However, he said, there was a general 802 interest in supporting multiple paths. He expressed a bit of worry, though, that some schemes might conflict with (to-be-developed) ISO schemes. He also expressed his view that source routing MIGHT not make it through the standardization effort (though he attributed this view to his lack of cynicism about standardization processes). He felt much surer that ISO would be very unlikely to standardize source routing, even in an 802.5 environment. He said there were some improvements to source routing that could be made, but wasn't sure that the 802.5 committee was consistent in looking at the overall picture (as opposed to spending time on bits and other low-level issues). When I mentioned there was some interest within the internet to standardize on 802 encapsulation, including source routing for 802.5 networks, he said he was worried that the source routing (802.5) document was not yet technically stable (from the specification point of view). End of report. Greg Minshall ps - Someone, in a private note, mentioned that maybe 802.1 (the internetworking portion) had been quashed by ISO. From what Mick Seaman said (though I didn't ask him about this), it appears that the original 802.1 charter had been "to solve all the world's networking problems, in the context of 802", but that the current charter seems to be "solve those problems in networking which are peculiar to LAN's, and which no one else [ISO, I suppose] is actively working on". He seemed quite happy with the current charter, and they are apparently quite close to releasing a draft standard.