🚀 go-pugleaf

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