Re: Interface reality check
Bharadwj,
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
>