Re: Interface reality check
Roy,
The output of 64B/66B encoding achieves octet alignment every 33, not 256 or 264
octets. 4-66B frames = 33 octets.
You say that "For the WAN compatible PHY with a fixed synchronization frame
payload, being on octet boundaries with
the encoded data is an issue." I challenge this assertion and maintain that no
issue exists.
As I'm on jury duty right now, I'll play the part of the defendant in this case
and maintain that I'm "innocent until proven guilty". Please prove that the IEEE
802.3 WAN PHY requires octet boundaries. If this is indeed the case I may have
to withdraw my support for Mr. Howard Frazier's UniPHY proposal.
As to your second point on XGENIE, Mr. Osamu Ishida's proposal to use
"ordered-set" style signaling during the IPG maps directly to 64B/66B frames,
which in turn, may be SONET framed according to WAN PHY proposals such as
UniPHY. However, I believe that XGENIE information is mapped to SONET OAM&P in
the case of UniPHY which means that XGENIE payload is never carried within
64B/66B information which is SONET framed.
Best Regards,
Rich
--
Roy Bynum wrote:
>
> 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
> >
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com