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
begin:vcard
n:Amrutur;Bharadwaj
tel;fax:650-857-3637
tel;home:408-244-5553
tel;work:650-813-3357
x-mozilla-html:FALSE
adr:;;3500 Deer Creek Rd. MS 26U-4;Palo Alto;CA;94304-1392;USA
version:2.1
email;internet:bharadwaj_amrutur@xxxxxxxxxxx
x-mozilla-cpt:;8544
fn:Bharadwaj Amrutur
end:vcard