Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP Path: utzoo!watmath!clyde!cbosgd!mark From: mark@cbosgd.UUCP (Mark Horton) Newsgroups: net.lan Subject: Re: Bridges, etc. Defined Message-ID: <1883@cbosgd.UUCP> Date: Mon, 3-Mar-86 11:44:07 EST Article-I.D.: cbosgd.1883 Posted: Mon Mar 3 11:44:07 1986 Date-Received: Tue, 4-Mar-86 05:09:31 EST References: <29500002@siemens.UUCP> <30@petrus.UUCP> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 80 In article <30@petrus.UUCP> mwg@petrus.UUCP (Mark Garrett) writes: >Do gateways really go to layer 7? This would imply that a gateway sometimes >needs to know about what specific application is running through the network. >I can't imagine a need to know anything above the session layer. > >Also, someone mentioned that a bridge can do protocol conversion between >dissimilar networks. I'm not the world's foremost authority on gateways, but here's what "gateway" means to me: A "gateway" is a very general term, used to represent a box or other service which connects two networks together, so that users of one network can communicate with users of the other network. It can go at just about any level of the OSI model. If you have two dissimilar networks, but they both support a service which is similar (e.g. transport, or mail) then you can build a gateway as follows. First, get a host which is on both networks. Then, determine the OSI layer at which the two similar services sit. For this example, I'll use "connection oriented transport" as the service, which sits at layer 4. Now, build into your gateway a translation between transport A and transport B. This translation logically sits "above" layer 4, but it's clearly "below" the session layer. So we'll call it layer 4.5. The resulting tower picture looks like this: --------- ---------- 7. Appl | X.400 | |SMTP/822| --------- ---------- 6. Pres | X.409 | | TELNET | --------- ---------- 5. Sess | OSI | | null | --------- --------------------- ---------- | | | gateway | | | | TP0 | --------------------- | TCP | 4. Tran | | | TP0 | | TCP | | | --------- ---------- ---------- ---------- 3. Net | X.25 | | X.25 | | IP | | IP | --------- ---------- ---------- ---------- 2. DL | HDLC | | HDLC | |Ethernet| |Ethernet| --------- ---------- ---------- ---------- 1. Phys | 56KB |----------| 56KB | |Ethernet|------|Ethernet| --------- ---------- ---------- ---------- It should be clear in looking at this picture (with electronic mail standards filled in at the higher levels) that it doesn't matter that the layers lower than the gateway (1-4) are quite different, but it doesn't matter. These two networks operate independently of each other in the first 4 layers. At the layers higher than the gateway, however, they also speak different protocols, and this DOES matter. Just hooking together two transports doesn't help SMTP and X.400 talk to each other. To make that work, you'd have to build a different kind of gateway: one that sits above layer 7. (This is in fact how the various mail gateways between networks work, and was probably what one previous poster had in mind.) Back in the mid-1970's, a machine which was on both the ARPANET and TELENET was viewed as a gateway between them. If you had a login on the machine, you could connect to it over one network, log in, and go out over the other network. This was the simplest, crudest case, but it did work. I've seen similar setups done at the physical level with dialups and port switches, interconnecting different switches with the dialup world. In general, it's possible to install a gateway at any level. A typical modem might be viewed as a gateway at the physical level. An IBM style protocol converter is a gateway at the data link level. IP is a gateway at the network level. There are two approaches to take, once you've built a gateway such as the above. One is to take the position that the higher levels don't matter - X.25 did this for years, using an X.25 network level connection as if it were a remote login application service. A variation on this is to put the gateway above layer 7, so there are no higher levels to matter (although this really just shunts the conversion problem onto layer 8, e.g. the user.) This is how mail has worked for years, using addresses like cbosgd!mark@Berkeley to route mail through the ARPANET to UUCP. A second approach is to start building new layers on top of the bridged service, on both sides. If you can get the same layers on both sides, they can talk, and the gateway becomes smoothly integrated. This is what was done with TCP/IP - once the new IP service was created, a whole set of appliations (plus TCP and TELNET layers) were defined. This is also what the Domain system does for mail, using uniform addresses like mark@cbosgd.ATT.COM on both sides of the gateway. By the way, if the two layers being connected together (e.g. transport in the examble above) are compatible, then as a special case, the gateway is called a "bridge". For example, a pair of modems serves as a bridge between two compatible RS232 cables. Ethernet bridges (as most except UB seem to use the term) fit above the data link layer (or whichever layer you put Ethernet at.)