Re: Interface reality check
Bharadwaj,
The 20 bytes that I refer to as "IPG" included the 7 bytes that normally are
referred to as "preamble" and the 1 byte that is normally referred to as
"start of frame delimiter". I may not be using the term correctly. The
terms "Inter-Frame Gap" and "Inter-Packet Gap" are sometimes used in ways
that seem to mean the same thing, or that one is included in the other.
Sorry, if I have generated any confusion about this.
In your message you used the conceptual coded output of the 64B/66B as
"10_DDDTZZZZ 10_ZZZZZZZZ 10_ZZZZZZZZ 10_SDDDDDDD". I believe that you are
representing the two additional bits to generate 1/0 transitions that the
64B/66 inserts into the data stream as "10_". The "D" would be an octet of
valid data. I believe that you are using the "Z" and "S" to represent
invalid data within the data stream. If I am correct, you have represented
the invalid data as 2 separate characters. Do these characters have any
special fixed hex value that would differentiate them?
Thank you,
Roy Bynum
----- Original Message -----
From: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>
To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, April 13, 2000 11:39 AM
Subject: Re: Interface reality check
> Roy,
>
> As an example consider the following segment of an octet stream:
>
> DDDTZZZZZZZZZZZZZZZZZZZZSDDDDDDD
>
> This gets coded up as (conceptually)
> 10_DDDTZZZZ 10_ZZZZZZZZ 10_ZZZZZZZZ 10_SDDDDDDD
>
> So the 32 octets at the input gets coded into 33 octets at the output.
Exactly
> how
> your 20 byte idle gets coded depends really on where it is embedded in the
> input
> octet stream. But yes, the 20 byte idle is spread across 3 66-bit frames.
But
> there
> is no wastage of bits in these frames as any left over space is allocated
to
> the tail
> of the preceding data packet or the head of the succeeding data packet.
>
> Incidentally, I believe the only other possible scenario for a 20 octet
> IPG, which is valid
> under the currently proposed XGMII is:
> DDDDDDDTZZZZZZZZZZZZZZZZZZZZSDDD
>
> This gets coded up as (conceptually)
> 10_DDDDDDDT 10_ZZZZZZZZ 10_ZZZZZZZZ 10_ZZZZSDDD
>
> Regards,
> Birdy
>
> ps: I had thought that the minimum IPG was 12 octets. I assume the 20
octet
> number you used was merely for discussion purposes.
>
>
> Roy Bynum wrote:
>
> > 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
> > >
> > >
> > >
>
> --
> 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
>
>
>