🚀 go-pugleaf

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.)