gassman@jedi.DEC (02/17/86)
WHOA... it's time to have a few definitions standardized! >Newsgroups: net.lan >Path: decwrl!amdcad!cae780!ubvax!skip >Subject: Re: Baseband <--> Broadband gateways >Posted: 13 Feb 86 18:41:31 GMT >Organization: Ungermann-Bass, Inc., Santa Clara, Ca. >Summary: Depends on network layer protocol >Bridges get involved at the network layer. IEEE 802.3 & 802.4 only >specify up through the data link layer. What bridge you need depends >on what network layer protocols you need. For example, Ungermann-Bass >provides networks based on a variety of different protocols. Which >bridge software you get depends on which network protocols you're using. >Like Ungermann-Bass's, Bridge's and DEC's bridges will only work on >networks that use their protocols. Fortunately, we've all started basing >our products on standard protocols, so depending on your system, >vendor A's network interface units may communicate using vendor B's >bridges. > . > . > . >-- Skip Addison > {lll-crg, decwrl, ihnp4}!amdcad!cae780!ubvax!skip > Ungermann-Bass, Inc > (408) 496-0111 Skip Addison of Ungermann-Bass is greatly mistaken about what DIGITAL's LANbridge 100 will do. He states that DEC's bridge works at the OSI Network layer, and is therefore protocol dependent. THIS IS NOT THE CASE!!!! BRIDGES work at the OSI datalink layer, and therefore MUST BE PROTOCOL INDEPENDENT. DEC's LANbridge 100 is indeed so. What Ungermann-Bass sells as a BRIDGE is actually a ROUTER, a router being a protocol DEPENDENT device working at the network layer. UB has been told this often at trade shows. What is happening is that the marketplace is being confused. In addition to repeaters and bridges, DIGITAL also sells routers to forward DECnet protocol packets between LANs of 802.3 and/or 802.4. DIGITAL's bridge forwards to the 'B' LAN, *ANY* packet who's destination station is not on the 'A' LAN. There also is optional bridge management software to do protocol or multicast filtering. Two models exist. One with two ethernet plugs, and one using up to 2000 meters of fiber optics. Sorry for the commercial, but putting out misinformation about LAN products is not helping the standardization cause at all. REPEATERS, BRIDGES, ROUTERS, and GATEWAYS are words that vendors and users must all agree on, while we trek towards OSI. Skip, please contact me about how DEC and UB can start to agree on what we call standard products! Bill Gassman Networks and Communications Digital Equipment Corp. (603) 884-0192
phil@amdcad.UUCP (Phil Ngai) (02/17/86)
In article <1174@decwrl.DEC.COM> gassman@jedi.DEC writes: >What Ungermann-Bass sells as a >BRIDGE is actually a ROUTER, a router being a protocol DEPENDENT >device working at the network layer. > > REPEATERS, BRIDGES, ROUTERS, and GATEWAYS are words >that vendors and users must all agree on, while we trek towards OSI. Sounds to me like Bill knows what he's talking about and Skip is confused. -- Real men don't have answering machines. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
skip@ubvax.UUCP (Skip Addison Jr) (02/17/86)
In article <1174@decwrl.DEC.COM> gassman@jedi.DEC writes: > > >WHOA... it's time to have a few definitions standardized! > In article something or another, Skip Addison @ Ungermann-Bass writes: >>Bridges get involved at the network layer. IEEE 802.3 & 802.4 only >>specify up through the data link layer. What bridge you need depends >>on what network layer protocols you need. For example, Ungermann-Bass >>provides networks based on a variety of different protocols. Which >>bridge software you get depends on which network protocols you're using. >>Like Ungermann-Bass's, Bridge's and DEC's bridges will only work on >>networks that use their protocols. Fortunately, we've all started basing >>our products on standard protocols, so depending on your system, >>vendor A's network interface units may communicate using vendor B's >>bridges. >> . >> . >> . >>-- Skip Addison >> {lll-crg, decwrl, ihnp4}!amdcad!cae780!ubvax!skip >> Ungermann-Bass, Inc >> (408) 496-0111 > > >Skip Addison of Ungermann-Bass is greatly mistaken about >what DIGITAL's LANbridge 100 will do. He states that DEC's >bridge works at the OSI Network layer, and is therefore protocol >dependent. THIS IS NOT THE CASE!!!! BRIDGES work at the OSI >datalink layer, and therefore MUST BE PROTOCOL INDEPENDENT. >DEC's LANbridge 100 is indeed so. What Ungermann-Bass sells as a >BRIDGE is actually a ROUTER, a router being a protocol DEPENDENT >device working at the network layer. > ... >DIGITAL's bridge forwards to the 'B' LAN, *ANY* packet who's >destination station is not on the 'A' LAN. There also is optional >bridge management software to do protocol or multicast filtering. >Two models exist. One with two ethernet plugs, and one using up to >2000 meters of fiber optics. Sorry for the commercial, but putting >out misinformation about LAN products is not helping the standardization >cause at all. REPEATERS, BRIDGES, ROUTERS, and GATEWAYS are words >that vendors and users must all agree on, while we trek towards OSI. >Skip, please contact me about how DEC and UB can start to agree on >what we call standard products! > >Bill Gassman >Networks and Communications >Digital Equipment Corp. >(603) 884-0192 The original posting referred to DEC's bridge and I assumed (yes, I know what assume breaks down as :-) that DEC's bridge did the same thing as everything else I've heard referred to as a bridge. Incidentally, I learned my network terminology long before I began working for U-B. Rather than saying I'm right and you're wrong or some other sort of non- helpful posting, let's take a vote of people who have worked in the LAN field more than a year or two. I'll post my definition of the terms (which I assume (there's that word again) is close the U-B party line, but not necessarily exactly) and if you (general you, not you Bill) agree with that you should mail me a message saying so. If you disagree on some substantive portion of the posting, post the differences. Repeater -- Performs a translation from one physical cable segment to another. The important part is that it does not change the immediate destination or source addresses. To do so would be a routing function. Generally introduces something like a one bit-time delay, but there are exceptions as noted below. Also generally reproduces jamming signals, fragmented frames, etc. Bridge -- One case of an internetwork router. Changes the immediate destination as necessary to further the purpose of getting the packet to its ultimate destination listed in the Network Layer header. Changes the immediate source to its own address. Of course, if it determines the packet does not need to be forwarded, it does nothing with it. A bridge performs a store and forward operation. Each 'side' of the bridge can be considered a seperate signal space. Jamming signals, frame fragments, etc are not re-transmitted. Gateway -- Another case of an internetwork router. In addition to the functions of a bridge, it provides protocol translation at some higher layer. For example, something that translated TCP/IP to Xerox's Internetwork Datagram Protocol and Sequenced Packet Protocol would be considered a gateway. Translating an IBM 3270 data stream to VT100 escape sequences might also be called a gateway. With the advent of so many network protocols operating on top of Ethernet, many customers have found it helpful to have what I'll call an an Ethernet 'linker' for the moment. It operates just on the information that's available in the official Ethernet header. It does not change anything in the Ethernet header. Ungermann-Bass calls that a Buffered Repeater, but I don't believe that that term is really standardized. What you call one of these 'linkers' is pretty much up in the air. These linkers are not smart enough to serve in a complex network topology with many signal spaces, loops or cycles, parrallel load sharing 'linkers' or whatever. But due to their Network Layer protocol independence, they do have some use. We have quite a few 'experts' on the net. Also a few real experts. Some have even written books on the subject. Care to comment Andy? I'd also be interested in hearing from other network vendors. Bill, your views of the layers, etc are probably pretty well represented above in your followup to my previous article. Is there anything missing? -- Skip Addison {lll-crg, decwrl, ihnp4}!amdcad!cae780!ubvax!skip (408) 496-0111
kik@cernvax.UUCP (kik) (02/26/86)
I have a personal interest in this discussion on the terminology of
LAN interconnection, since I have just written a paper on a project
in which I was involved, interconnecting transparently Ethernets
by means of a high-speed, general-purpose backbone network. I have
included the (more or less) relevant parts of the paper below:
------------------------------
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.
A bridge is assumed to provide a means of propagating a basic
information frame from the source to the destination network, in such a way
that the information content is unchanged. This operation is constrained
by the OSI model to being performed in the lower sublayer of the Link
layer, whence the complete term "Medium Access Control (or MAC)-level
Bridge".
This approach to intercommunication allows any mix of higher-level
protocols to operate within the resulting bridged area network in the same
way as within a single local area network.
In addition, a bridge can carry out "filtering" on the destination
address. This entails forwarding to each segment only the frames whose
destination corresponds to an address on that segment.
A repeater amplifies or regenerates the physical signals on a link or
bus-type network. It is used to overcome distance limitations due to
signal degradation. It should, however, be noted that the term buffered
repeater is generally used to describe a simple MAC-level bridge.
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.
The term station is used to represent a (generally intelligent) device
connected to a LAN.
The service characteristics are examined with their implication on the
required characteristics of the bridge:-
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;
MAC transparency:
the bridge should not need any modification to the existing MAC
specifications (ISO^8802/3,4,5). The assignment of LAN addresses should
not be affected by the presence of the bridge;
minimal increase in errors:
bridges should not significantly increase the incidence of errors between
communicating stations. It should be noted, however, that the general
bridge service definition does not rule out loss, duplication or
misordering of frames;
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;
limited transit delay:
the resultant bridged area network should not exhibit too large an
end-to-end transit delay. This upper limit is set by IEEE at 5^seconds.
Potential disadvantages
=======================
The main problems that can be encountered in a bridged area network fit
roughly into the following categories:
increased delay: the bridges impose a store-and-forward delay;
congestion: congestion in the bridge can lead to several symptoms such as
lost frames, irregular traffic, etc.;
increased security risks: remote access allows unauthorised use of
connected segments;
degradation of some service characteristics: the overall service relies on
the individual services available along the traversed path. This can lead,
for example, to reductions in the maximum frame length compared with that
available on each of the end segments;
loss of local features: one typical such example is for the ISO^8802/5
token ring, where the MAC-level protocol provides the transmitting station
with the information as to whether the receiving station on the ring is
present and whether the data was copied ("R" and" "C" bits). These
features can obviously not be given end-to-end significance across a
bridged area network;
management complexity: analysis of performance and diagnosis of end-to-end
problems become even more complicated than in a single network.
Implications of bridges
=======================
In order to be able to provide the services needed by the bridge itself,
the LAN interface must have a certain minimal functionality.
For reception, it must be capable of receiving all frames travelling on
the LAN ("promiscuous" mode), in order to allow the software to select,
from the total traffic, the frames to be forwarded.
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.
------------------------
I hope that this contributes to the discussion. An effort has been made to
match the terminology to that emerging from the standards organisations,
insofar as it is relevant to the actual, practical application.root@topaz.RUTGERS.EDU (Charles Root) (02/27/86)
Unfortunately, there are several different communities, each of which use words in different ways. I have a reasonable familiarity with the terminology used by PUP, TCP/IP, XNS, and DECnet. I am not going to try to speak for ISO. The Internet community inherits the traditions and terminology of PUP, NCP, TCP, and to some extent XNS. In this community, the term "gateway" normally means something that forwards individual packets based on the addresses in the protocol headers. Thus a gateway must know enough about the protocol to pick the address out of the header. However normally it knows only about the lowest layer. E.g. it would know only about IP (not TCP) or PUPs (not BSP). Most protocols have special ancillary protocols that gateways also must know. E.g. with IP many gateways handle echo requests, generate packets telling the source to slow down when the gateway's buffers are filling, etc. For IP, PUP, and XNS, most gateways communicate with other gateways to keep track of network topology (EGP or routed for TCP/IP, RIP for PUP and XNS). The term "gateway" is always used for these objects in the IP community. I am fairly sure PUP also used the term "gateway". XNS seems to use the term "internetwork router". DEC has a device called a "DECnet router" that seems to be essentially the same sort of object. The term repeater is commonly used to refer to something that operates at the level of physical packets. Most typically, it forwards Ethernet packets. Such a device does not know anything about the protocols being carried on it. The original Ethernet specification used "repeater" to refer to something that connects two Ethernet segments to form what is effectively a single Ethernet. Even collisions must propagate through it unchanged. So this is a very low-level thing. The Ethernet spec uses the term "remote repeater" to refer to a pair of half repeaters connected by a fiber optic cable. This operates at the same level as the other repeaters. I don't know of any IP or PUP specifications defining anything called a "bridge". However this terms seems to be used within the TCP/IP community to refer to devices that forward at the level of Ethernet addresses, but are not repeaters. That is, they are store and forward devices, but they do their routing on the basis of the Ethernet address of the packet rather than the IP or other protocol address. This means that they are independent of the protocol. They may exchange routing information, but normally do so using a private protocol unrelated to the protocols of the packets they are handling. An example of such a device is DEC's new DECbridge 100, and Applitek's system that connects Ethernets using a broadband backbone. I am not sure what people call devices that convert protocols. Examples would be DEC's DECnet/SNA gateway (hmmm.... I guess that means they use the term "gateway"). The XNS spec seems to use the term "gateway" to refer to devices that convert between XNS and a foreign protocol. The only serious conflict seems to be over the word "gateway". This has been used for so many years within the Internet community that it is going to cause incredible confusion for anyone to use the same word with a different meaning. Generally I try to use an adjective with it to clarify the sense in which it is being used. Thus I normally use the term "IP gateway" to refer to the conventional sort of gateway used by TCP/IP, since it operates at the IP level. A term such as DEC's "DECnet/SNA gateway" is also clear enough to avoid confusion. However if you use the term gateway without qualification to refer to something that converts protocols, and if you expect your document to be read by people whose background is either TCP/IP or 4.2, you are asking for misunderstanding.
sjl@amdahl.UUCP (Steve Langdon) (03/01/86)
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. ]