Re: [HSSG] Reach Objectives
Geoff,
If only it were so simple ...
When Ethernet moves into the infrastructure world, we also
have the case where Ethernet gets carried between bridges or routers over a
layer 1 network (generally over SONET/SDH or OTN). It is in this world where,
for some reason, people expect that all the stuff like preambles and IPGs that
would never transit a bridge should somehow emerge completely untouched and
unscathed after going through dozens of nodes in a layer 1
network.
Perhaps it would be good to standardize at least a
"logical" repeater even if this isn't needed (directly) for physical
reach - we could treat the entire server layer network at layer 1 as if it
were a repeater, and we would have a standard that would put it down in black
and white what is supposed to get reconstructed at the far
end.
Some of the games that are played using the preamble
between adjacent bridges or routers from the same vendor might be easier to
avoid if they won't work with a repeater between them...
Regards,
Steve
Steve-
At 08:08 AM 9/3/2006 , Trowbridge, Stephen J (Steve)
wrote:
It is all well and good to say
(quoting Geoff)
"Preambles are
not payload
Interpacket gaps are not payload."
but it is clear that some customers don't like it if
you have to fiddle with their preambles or interframe gaps to go between LAN
and WAN.
Regards,
Steve
Going between WAN and
LAN is not any different than going between WAN and WAN or going between LAN
and LAN. It is done with a bridge, a device of two or more MACs whose
connection is standardized by 802.1
(Unless you want us to spec a
repeater for this project. We have done repeaters before in 802.3. They have
always been regenerative and have always generated a fresh
preamble.)
The interframe gap exists precisely "to fiddle with". They
are a core reason why Ethernet is different from and cheaper than SDH. At the
system level (without regard to whether or not it is true at the physical
layer level) each Ethernet packet is a different and asynchronous event. This
lack of history and saved state between packets at layer 2 is a major source
of both the robustness and economy of Ethernet implmentations.
It is
the job of 802.3 to spec building blocks for the layered architecture of IEEE
802. In that context, it is and always has been the job of the 802.3 MAC to
strip off the preamble upon reception and to generate a new preamble upon
transmission. 802 compliant bridges have no provision for forwarding packet
information other
than:
Source
address
Destination
address
Type/Length
Data
and
perhaps
FCS.
To
do what you suggest would be a significant change to the 802.3 MAC and the 802
architecture.
I strongly believe (and will argue) that any such change
is outside the scope of the "Higher Speed Study Group". It has nothing to do
with speed.
Customers who want end-to-end unpacketized bit-for-bit
transmission (as opposed to packet integrity) don't want Ethernet. (which is
perfectly OK with me)
Having said that, you are welcome to test the
interest of 802.3 and 802 for such a change by putting together a call for
interest specifically addressing this topic.