Re: Interface reality check
Using the Ethernet TYPE field does not work in a practical design. First,
the effect of errors in the TYPE field will alter the location of the CRC,
in effect producing a huge burst error. The large error will break the
misdetected error probabilities. Second, the Ehternet TYPE can not
eliminate the overhead of the SA and DA before generating a new frame.
At 04:45 PM 4/7/00 -0700, Rick Walker wrote:
>> To support T1X1 other types of frames aside from Ethernet format are
>> required. Since the format must be determined before the CRC can be located
>> using any part of the existing Ethernet frame to determine the format is
>> not a technique which works.
>This is easy.
>Define a different frame type using the <type/length> field.
>In the first two data bytes of the payload of your newly defined "T1X1"
>packet, put your T1X1 <length><type><crc> doodad. This give you exactly
>what you want, and is redundantly protected by the CRC32 of the data
>You see, once you get issued your own <type/length> value for T1X1 packets,
>you can define the packet structure any way you desire. If you want, you
>can make it use exactly T1X1 bit patterns, omit CRC32, etc.
>The mechanism is quite flexible. The only issue is whether you can get
>enough support to get the mechanism standardized.
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365