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

Re: [HSSG] Reach Objectives



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.