| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Rich,
My comments are interlaced below.
-----Original Message-----
From: Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
Sent: Thursday, April 13, 2000 9:16 PM
To: HSSG
Subject: Re: 66-bit alignment vs 8-bit alignment
Dave,
Please allow me to initiate yet another new thread on this specific subject
since there are too many branches on the original "interface reality check"
thread whose purpose was to focus on code transparency for XAUI and PCS.
Please explain the following points in your response to Mr. Bharadwaj Amrutur:
1) Why would a SONET section framer or any SONET framer, including that in the
UniPHY proposal, care about the contents of the payload it is carrying for the
specific case that the payload is 10 GbE payload? I may be wrong, but I don't
believe that any other SONET payload is relevant or of any interest to IEEE
P802.3ae;
The SONET section framer does not care about the contents of the SONET path. It
is the circuitry that recovers the payload from the SONET path that is simpler if that
payload is byte aligned, since the byte alignment is already provided by the section
framer.
2) What is your definition of payload delineation mechanism for the WAN PHY?
More specifically since this issue questions the SONET interpretation of word
size alignment, if the WAN PHY is UniPHY, the PCS is 64B/66B + SONET framing +
SONET scrambling. Therefore, for the UniPHY, the payload delineation mechanism
is the 64B/66B decoder. Is there some other requirement for the SONET transport
to perform payload delineation?;
Examples of payload delineation mechanisms, which occur after SONET section
framing and after SONET pointer processing to locate the SONET path: (a) 64B/66B
case - hunting for the 2 bit 01 or 10 pattern every 66 bits; (b) <length><type><HEC>
case - hunting for an 8 byte string which has a CRC-16 which matches the 2 byte value
following the 8 byte string. Case (a) requires searching by bit. Case (b) requires
searching by byte.
3) What specifically are we hunting for here... snipe?;
See above. Please excuse my terminology.
4) Your last comment about bit-slipping vs. byte-slipping involving more
circuitry is incorrect with respect to 64B/66B code vs. SONET framing. First of
all, this "slipping" operation is part of the link synchronization function and
need not be performed (at least for 64B/66B) once the link is in sync. For
64B/66B link synchronization is performed by syncing on either a b'01' or b'10'
pattern with 66-bit periodicity. I don't know SONET that well, but my
understanding is that you're looking for a many byte pattern which occurs every
155,000 or so bytes. I believe it's safe to say that 64B/66B bit-slipping
involves significantly LESS circuitry than SONET byte-slipping. Please tell me
if I mis-interpreted your "slipping" comment in any way.
The slipping operation is performed on link synchronization. Of course that circuitry
is still there after link sync is achieved, it's just burning power. Your reference
to the byte pattern search is the SONET section framer operation, which is common
for either 64B/66B or <length><type><HEC> mappings into a SONET path.
Is it clearer now?
...Dave
David W. Martin
Nortel Networks
+1 613 765-2901
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx
========================
Best Regards,
Rich
--
> David Martin wrote:
>
> Bharadwaj,
>
> The issue with 66-bit alignment vs 8-bit alignment arises at the receive end.
> The SONET section framer provides a byte-aligned output. If the payload is
> byte aligned then the payload delineation mechanism can hunt directly. If the
> payload is 66-bit aligned, then the delineation mechanism must hunt on a bit
> by bit basis. Bit-slipping vs byte-slipping involves more circuitry.
>
> ...Dave
>
> David W. Martin
> Nortel Networks
> +1 613 765-2901
> +1 613 763-2388 (fax)
> dwmartin@xxxxxxxxxxxxxxxxxx
>
> ========================
>
> -----Original Message-----
> From: Bharadwaj S Amrutur [SMTP:bharadwaj_amrutur@xxxxxxxxxxx]
> Sent: Wednesday, April 12, 2000 8:28 PM
> To: Roy Bynum; stds-802-3-hssg@xxxxxxxx
> 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
>
> << File: Card for Bharadwaj S Amrutur >>
-------------------------------------------------------
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