mwg@petrus.UUCP (Mark Garrett) (02/24/86)
++ As far as being an expert or an Expert, I don't know how I would pidgeonhole myself. I have been working on research prototypes for two years, doing a lot of hardware design and protocol specifi- cation for very high speed LANs and MANs. (A MAN is a Metropolitan Area Network, which is just a LAN which can be big. For instance, Ethernet could not be a MAN because its protocol requires very limited distance.) However I must plead ignorance as far the details of commercially available LANs and especially on what terminology vendors use for their stuff. I got a request from Derek Bergin to go into how we build gateways, as opposed to writing them, so I'll go into that later on. It seems to me that Skip Addison is mistaken (picking on Skip seems to have become popular sport around here! :-) ) about converting an "IBM 3270 datastream to VT100 escape sequences" being a gateway function. I would think this is the job of the receiving host's presentation layer. We have to distinguish between the network (of which gateways and bridges are a part) and the hosts on the network (of which the resident software is a part, even though that code may be performing higher layer network functions). Such conversion of data format is a session layer function and is performed at one end or the other. You would not do this at multiple points within the network, so I wouldn't call it a gateway function. What Skip describes as a "buffered repeater" is exactly what I would call a bridge. A gateway is something which requires some intellegence. For example, conversion between two different protocols (MAC level). Are you people familiar with the IEEE LAN reference model? Sometimes it is more convenient to divide things into Physical, Medium Access Control, and Logic Link Control layers, where the MAC level overlaps the ISO physical and data link layers somewhat and the other two fill in what's left of ISO 1 & 2. We build the MAC layer into a single board or a single chip which does synchronization, some resource sharing mechanism, timing, serial/parallel conversion and station access for a number of user data sources with different priorities. We have designed what we call a MAN/LAN gateway where we use Fasnet (the original paper on this is: Limb & Flores, "Description of Fasnet - A Unidirectional Local Area Network", Bell System Tech Journal, Vol 61, No 7, p 1413, September 1982) for the MAN and Ethernet for the LAN (simply because it was there, we're not allowed to endorse products). The design of the gateway will be presented at ICC'86 in June, and at least some of the implementation will be described at EFOC/LAN in Amsterdam, also in June 1986. Although it looks like a bridge to the end users, we call it a gateway because there are two distinct protocols involved. Ethernet packets are transparently encapsulated in Fasnet packets, transported and put back together at the remote end. Everything is broadcast routing in the MAN; the gateway only knows what LAN addresses are in its local Ethernet. LAN packets not destined locally are put out on the MAN, and packets comming in from the MAN are only repeated on the LAN if the address matches one of the local station's. None of this relies on host processing since computers are so abominably slow. Each MAN station would have a bit-sliced sequencer to do very fast things like fragmenting LAN packets and recoginzing addresses (it's even too slow for this). Then there is a 68000 and LANCE on the Ethernet side to do slower things like memory management, network diagnostics, debugging or whatever. The MAN runs at 140 Mbps and the MAC controller and bit-slice can pretty much keep up with that. If (when) this is upgraded in speed we'll probably have to move even more layers (3 & 4) out of the host and down to dedicated station processors. I think this is the important trend: get the network intellegence distributed away from the hosts. Mark Garrett Bell Communications Research