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 amdahl.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!amdahl!sjl From: sjl@amdahl.UUCP (Steve Langdon) Newsgroups: net.lan Subject: Re: Repeaters, Bridges, Routers, and Gateways Message-ID: <2852@amdahl.UUCP> Date: Fri, 28-Feb-86 19:59:06 EST Article-I.D.: amdahl.2852 Posted: Fri Feb 28 19:59:06 1986 Date-Received: Sat, 1-Mar-86 23:38:16 EST References: <1174@decwrl.DEC.COM> <442@ubvax.UUCP> <280@cernvax.UUCP> Reply-To: sjl@amdahl.UUCP (Steve Langdon) Organization: Amdahl Corp, Advanced Systems Planning Lines: 90 Keywords: ISO OSI IEEE MAC Summary: minor refinements to an earlier explanation In article <280@cernvax.UUCP> kik@cernvax.UUCP (Crispin PINEY) provides a good overall description of the subject. There are, however, a few points that I would like to comment on. > ... > There are several approaches by which communications can be extended > over several networks. They fit into four main categories: gateways, > relays, bridges, and repeaters. > > A gateway translates between protocols. Gateways can operate at > different levels in the ISO model. A gateway that operates below the > Application layer is also known as a "protocol converter". Gateways are, > naturally, specific to the protocols for which they are designed. > > A relay forwards a packet towards its final destination. This is an > operation carried out in the Network layer and is a characteristic > mechanism of store-and-forward networks. It allows mixing different > communications technologies, but imposes an overall Network level protocol. This is a fairly accurate picture of the terminology used in ISO OSI documents. Unfortunately, the DARPA Internet community tend to use the term "gateway" to mean exactly what is called a (network layer) "relay" in OSI. I prefer the OSI usage, but it will be a while before it is used universally. The use of an overall Network layer protocol is *A* way of performing the network layer relay function. It happens to be the way I prefer, because I am a staunch advocate of IS 8473 (the ISO Internet Protocol). However, readers should be aware that more than one approach is possible. Without going into the gory details of DIS 8648 "Internal Organization of the Network Layer", it is not possible to explain all the variations, but a good example of an alternative, is connecting X.25 networks using X.75. This provides both ends of a connection with the appearance of a common network layer protocol without actually using the same protocol end to end. > ... > MAC-level Bridge Service Definition > =================================== > > This service definition is based on work being carried out within IEEE > project 802 and expected to be incorporated into ISO^8880 and the > long-awaited ISO^8802/1. I am the ISO editor for DP 8880/1, 8880/2, and 8880/3 which have the overall title "Specification of Protocols to Provide and Support the OSI Network Service". At present ther is no mention of MAC bridges, because it was concluded that, except for the Quality of Service differences you described, the network layer should not be aware of the presence of a MAC bridge. An earlier revision of DP 8880 did mention MAC bridges, and at the SC6 WG2 meeting this April, MAC bridges may reappear when the documents are revised. > ... > topology independence: > bridges are invisible to the upper part of level^2 (LLC), and all higher > layers. They are not explicitly addressed, except for management > functions; IBM has proposed a form of source routing that can be used with their preferred variant of a MAC bridge. I do not think this will be accepted by IEEE 802, but no final decision had been made the last time I checked. > ... > sufficient data length: > the bridges should be able to forward at least the minimum useful data > unit. The minimum acceptable size is set by IEEE to 263^bytes; I hope IEEE will reconsider this number, because IS 8473 requires a minimum of 512 octets. The DIS version of 8473 required 256 octets, but this was raised to 512 in the final round of editing. > ... > For emission, it must be able to insert any acceptable value for both > the source and destination addresses, in order to allow the original frame > to be recreated identically on the destination segment. It is also > desirable for the emitter to be able to specify the value of the checksum > to be included with the frame. For maximum data integrity it is desirable to avoid recomputing the frame checksum. This is, of course, only possible when the same algorithm is used on both segments. Thank you for your summary. I wish I had the time to provide more information in this type of discussion. -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]