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

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

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


* : 64/66 is really tuned to 10GE-standards proposals  in the following
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
      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)


>Using the Ethernet TYPE field does not work in a practical design.
>the effect of errors in the TYPE field will alter the location of the
>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.



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

adr:;;3500 Deer Creek Rd. MS 26U-4;Palo Alto;CA;94304-1392;USA
fn:Bharadwaj Amrutur