Re: Interface reality check
Roy Bynum wrote:
> 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.
Roy,
I understand your terminology and I think we have been using a slightly
different
one. Let me redo the example with the notation as per the original
XGMII proposal
in:
http://grouper.ieee.org/groups/802/3/10G_study/public/july99/frazier_1_0799.pdf
(except I have replaced \I with \Z)
Assume that the input octet stream to the PCS is:
d d d d df df df df T Z Z Z Z Z Z Z Z Z Z Z Sp dp dp dp dp dp dp dp d d d d
Here:
d, df, dp : are data octets and can have one of 256 values
(Note: The preamble octets dp are really data octets as they are signalled at
the
XGMII interface with the control flag deasserted.page 8 of the above pdf file)
T, Z, Sp: are non data octets with
Sp = start-of-packet delimiter - a fixed hex pattern
T = end-of-packet delimiter - a fixed hex pattern
Z = other non data octets. I understand there has been lots of discussions over
this
but at the minimum, this can be one of either \I or \E.
64/66 can accomodate 10 others besides \I, \E and Sp, T.
(actually it can accomodate a bit more since it supports ordered sets,
but lets ignore
this for this discussion).
I also wanted to clarify your phrase "invalid data". I assume you are refering
to non-data as
invalid data? In any case, for 64/66, there is the notion of valid-non-data and
invalid-non-data.
A valid-non-data consists of one of 14 non-data octets (Sp, T, and 12 other
Zs). All other
non-data octets are considered as invalid-non-data (and mapped to \E).
Resuming with the example:
64/66 considers everything in between a start-of-packet delimiter (Sp) and the
end-of-packet delimiter (T) as data octets. In other words, it is oblivous of
the
the underlying packet structure (and treats the preamble octets as data
octets).
The above stream gets coded (conceptually) as
01_dddddfdfdfdf 10_TZZZZZZZ 10_ZZZZSpdpdpdp 01_dpdpdpdpdddd
(wish I could use subscripts for dp and df).
For the first and last frames, the 66-bit frame merely consists of the 64bits
of
data with the 2bit 01 preamble.
The mapping is a bit more complicated for
the middle two frames as the non-data octets (T, Sp, Z) are not directly
transported
but are remapped to compress them.
The reason for this compression is to put in redundancy to achieve 4-bit
protection for the T and Sp octets - and 3-bits for the Zs.
For example, instead of transporting the fixed
8-bit hex pattern for \T, the 64/66 coder merely indicates which byte if any of
the 8byte
frame, holds the \T non-data octet. This requires only 4bits (actually log2(9)
bits).
Similarly for Sp, instead of transporting the corresponding fixed 8-bit
pattern,
the coder indicates which of the two byte locations the Sp octet is present.
This
requires 2-bits (actually log2(3) bits ). You can combine the above: 8
possible
locations for T, 2 for Sp and one where none of these two are present.
This can be represented in 4 bits.
Similarly, since only 12 non-data octets , Z, are supported, the full 8-bit hex
pattern of Z is not transported, but is compressed into a 6-bit pattern.
(Actually
8 are mapped directly into 6-bit entities, and the remainig four which
correspond
to headers of ordered sets are treated a bit differently)
Hope I have reduced entropy a bit.
Regards,
Birdy
>
> 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
> >
> >
> >
--
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
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