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

Re: Interface reality check


I may help with an observation.  While the input of the 64B/66B encoding is
a serial octet stream, the output is not.   The output of 64B/66B encoding
achieves octet alignment only on input data frames at 256 octet boundaries,
which outputs to 264 octet boundaries.   For a LAN only PHY which does not
have framing boundaries, that is not an issue.  For the WAN compatible PHY
with a fixed synchronization frame payload, being on octet boundaries with
the encoded data is an issue.  This might also be an issue with XGENIE,
which if I understood correctly, also used fixed octet payload boundaries.

Thank you,
Roy Bynum

----- Original Message -----
From: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>
To: <stds-802-3-hssg@xxxxxxxx>
Sent: Wednesday, April 12, 2000 1:44 PM
Subject: Re: Interface reality check

> Hello Paul, Dave,
> I guess I am slightly confused by your arguments.
> I believe 64/66 provides a general (almost - see *)
> mechanism for transporting a serial octet stream which
> consists of contiguous octets(bytes) of data separated by
> contiguous stream of non-data octets. It doesnt really impose
> any constraint on how you interpret the packet of data,
> except that if the packet of data is CRC32 protected in ethernet
> style, then its 3-bit detection strength is not degraded.
> (One can easily determine/verify which other CRCs share this
> special relationship with 64/66 - there are two scrambler polynomials
> in consideration for 64/66 and maybe one is friendlier to many more
> CRCs?)
> So my question is, why should there be any problem in
> interpreting/allowing/encapsulating other format types within
> this framework?
> Isnt the main issue then how important the 3.125% overhead is for
> WAN transport?
> Please tell me if there are other issues I have  misunderstood or
> if the limitations in (*) below, are severe enough to curtail its
> applicability in other areas.
> I would also appreciate if you can share any insights on burst error
> statistics.
> Thanks,
> Birdy
> * : 64/66 is really tuned to 10GE-standards proposals  in the following
> ways:
> 1)  Data octet streams should start on a special quad octet boundary.
> 2)  It allows for only 8 different non-data octets with 3-bit protection
>       to be transported and four types of ordered sets.
> 3)  Verification of nondegradation of 3-bit detection strength of
> ethernet
>       CRC32 has been done.
> other constraints
> 4)   Data stream must be atleast 8 octets long.
> 5)   Non data stream must be atleast 11 octets long
>        ( I might be off a bit in the above two numbers)
> -----------------------------------------------------------
> >Rick:
> >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.
> >Cheers,
> >Paul
> -----------------------------------------------------------
> >Rick,
> >Your suggestion amounts to mapping L2 payloads into another L2 payload
> >(i.e. Ethernet MAC frames) prior to mapping into SONET/SDH. This would
> >make the SONET/SDH ANSI/ITU standards activity dependent on IEEE.
> >Such a cross-coupling would hinder progress in both IEEE and ANSI/ITU
> >and is therefore undesirable.
> >...Dave