Re: Interface reality check
Bhardwaj,
You are right. I should have said 256 input bit boundaries produces 264
output bit boundaries, which as you pointed out, becomes octet aligned only
on even 32 byte boundary input data. Thank you for the correction.
As a point of question, what happens to the IPG under 64B/66B? Does the 20
byte idle become a control character 33 bytes long?
Thank you,
Roy Bynum
----- Original Message -----
From: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>
To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Wednesday, April 12, 2000 7:27 PM
Subject: Re: Interface reality check
> Roy,
> A small arithmetic error:
> Since 64/66 converts 64 bits to 66 bits, I assume you really want to
> say that the output is octet aligned only on 32 octet boundaries
> of the input (i.e. it outputs 33 octets for every 32 octets).
>
> I am still trying to understand your concern, so please bear with me as I
> think "aloud".
>
> I view the sonet payload as a bucket of so many octets with which
> I need to transport a sequence of 66 bit words. I can have a 33 octet
> buffer into which I write in 66 bit chunks from one end and read from
> the other end in octet chunks, 33 times ( I need to phase lock
> 66bit word clock/4 to byte clock/33).
> Isn't this simple, or are there other issues I am not considering?
>
> I believe, the XGENIE proposal envisions itself to be in between the
> XGXS (or is it RS ?) and the PCS - I might have got the layer names
> wrong, but essentially they want to avail of the inter packet gap and
insert
> some control octets. Since this is before the PCS layer, 64/66 can code
> this up. You can refer to Rick Walkers posting on how he plans to do
that -
> its buried somewhere in the morass of posting.
>
> Thanks
> Birdy
>
>
> 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
> > >
>
> --
> Bharadwaj Amrutur
> Agilent Technologies
> 3500 Deer Creek Road, MS 26U-4
> Palo Alto, CA 94304-1392
> USA
>
> Phone : (650) 813 3357
> Fax : (650) 857 3637
> Email : bharadwaj_amrutur@xxxxxxxxxxx
>
>
>