Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] Reach Objectives

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

From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
Sent: Sunday, September 03, 2006 2:07 PM
To: Trowbridge, Stephen J (Steve)
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach Objectives


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.

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
and perhaps

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.