Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Post by kaja_love1 » Fri, 22 Jun 2007 07:13:53


hello


The job of router is to forward packets and it usually operates at
layer 3 of OSI model. And I realize that many routers are also
gateways.

But the definition of gateway really got me confused: My textbook says
that gateway can connect networks with different architecture and
protocols. It does this by taking the incoming packet and removing all
of its headers ( including header created in layer 4 of the OSI
model ) and replacing the removed headeres with headers created by
protocols used on network this packet is destined to.

Now as little as I know about networking, I always assumed that the
two protocols ( residing on the two communicating computers ) must be
the same --> I'm talking about protocols at layer 3 or layer 4 of OSI
model?
Thus if one PC uses IP protocol at layer 3, then the other PC must
also use IP?! Right?
Or if one PC uses TCP, then other must also use TCP in order for the
two PCs to be able to communicate with eachother?!
BTW - I realize that routers can pass packets between networks with
different data link and physical layers

So anyways, according to my book ( as I understood it ) the TCP
protocol can establish a connection with some protocol that is
totally different ( in terms of its packet structure and services it
provides) than TCP, just as long as we have a good gateway between the
two end systems?! In other words, one PC could be using TCP to
communicate with PC which uses UDP ( I know this is far fetched, I'm
just making an example using only two protocols I know of at layer 4
of OSI model )?


thank you
 
 
 

Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Post by robertwess » Fri, 22 Jun 2007 07:42:01


Part of the confusion is that historically IP Routers were called
"gateways." But most routers are most certainly not gateways in the
modern sense.

But that aside, there are all sorts of gateways in the world, and
these tend to connect networks at some higher level than OSI 3/4.
These are also usually application specific, and not generic, since
typically the low level protocol are different enough to make a simple
translation impossible. For example, I have a mainframe terminal
session on my desktop running TN2370/Telnet/TCP/IP to a gateway which
has a 3270/LU2/SNA connection to the actual mainframe. Back in the
days when mail was not exclusively handled via SMTP, there were scores
of email gateways about.

While most gateways involve higher level functions, it's not
completely unheard for lower level gateways to exist. For example, I
saw a TCP to (OSI) TP4 gateway at one point, although it had somewhat
limited functionality on both sides, but managed the basic byte stream
connection OK.

 
 
 

Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Post by Albert Man » Sat, 23 Jun 2007 00:52:55


Actually, if you want to be rigorous with terms, no. Routers are layer 3
devices which use a specific layer 3 protocol. It is an unfortunate
circumstance that routers were often called "gateway" is early RFCs.
This is now confusing. So just be aware of this oddity.


Yes. Gateways come in many varieties. Some operate all the way up to
layer 7, and were used some years ago to tie together, for example, IBM
SNA networks with DECnet or IP networks. For example, they would be used
to do file transfers or send e-mail among these different nets. By
definition, these two examples would require changes all the way up to
layer 7.


That's right. So what do you do to allow two PCs to communicate, when
they are on different types of network? You install a gateway.


Same idea, moved up the protocol stack. Bridges can sometimes tie
together different link layer protocols, but routers cannot tie together
different network layer protocols. And what is the device that can tie
together different application layer protocols, e.g. SMTP to VMSmail?
"Gateway" is a rather ambiguous terms that describes this magic box that
does this sort of thing. They used to be very popular in days before IP
became the global standard for digital networks.


I think the SMTP to VMSmail is perhaps a better example, and was just
the sort of thing these gateways were used for, back in the 1980s and
early to mid 1990s. But yes, in principle, a gateway would also be the
box that permits a TCP session one one side to become UDP on the other
end.

As far as I know, gateways are not in widespread use these days. I could
be wrong, though.

Bert
 
 
 

Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Post by kaja_love1 » Sat, 23 Jun 2007 21:06:09

hello

Thanx to you guys it's starting to make some sense :)

My text book also claims that gateways are used for the purpose of
connecting main frame computers to LAN in such a way, that mainframes
don't realize they are connected with LAN

1)
So do gateways connect mainframe PC to LAN in such a way, that other
PCs in LAN perceive this mainframe as being member of this LAN ( thus
it also gets broadcast messages etc )


2)
What is the purpose of connecting mainframe in such a way, that it
doesn't realize it is connected to LAN why shouldn't mainframe know
this?

3)
Main point I don't understand is why needs a gateway to translate
between protocols LAN uses and protocols mainframe uses ( is this
translation between protocols at application layer or network layer )?
Meaning, does mainframe always uses some special protocols which LANs
never use?


thank you
 
 
 

Gateway - can make two totally different layer 3 or 4 protocols to communicate with each other?

Post by robertwess » Sun, 24 Jun 2007 01:47:31


Most mainframes these days speak TCP/IP quite well, so you often don't
need an external gateway, but you might have one for cost or
performance reasons.

Mainframes historically have used SNA for networking, which is very
different from TCP/IP. While direct SNA connections all the way out
to workstation are perfectly possible, and can run over "normal" LANs
like Ethernet or Token Ring, it's clumsy and expensive. Not only do
you need to SNA stack on the PC, you need the correct network
infrastructure. Older sub-area SNA is not routable in the same sense
that TCP/IP is, so you need to have routers that can also bridge the
SNA traffic in addition to routing the IP stuff, which certainly
complicates management of the network. Or if you had APPN, that's
routable, but the APPN routing functions required pretty expensive
high end routing gear (not for technical reasons, just because of the
limited market).

So even if you need much of the SNA functionality out to the
workstation or near there, a gateway provides a single, much more
manageable point where you can do the translation.

And there are still some reasons for running SNA out to various
servers, but it's pretty strongly avoided at the workstation level
these days.

Internally much of the traffic on the mainframe (and inside a cluster)
is still SNA, and some of what's happened is that the gateway is part
of the standard mainframe TCP/IP stack. For example, 3270 terminal
traffic is almost all SNA internally, and the mainframe TCP/IP stack
provides the TN3270/TELNET gateway function. That's actually a common
function that's offloaded to an external gateway (and then it's low-
overhead SNA traffic between the mainframe and the gateway, and you're
not burning expensive CPU cycles on mundane terminal handling).

Certainly the need for special purpose gateways in the mainframe world
has diminished greatly over the years.