RE: One common type of 64B/66B PCS?
Paul,
in principle it is possible to distinguish between 10GBASE-R and
10GBASE-W using a sort of "parallel detection" (from a SONET point
of view, the 10GBASE-R signal is seen as a "random" signal, and
viceversa), if both are using the same clock rate.
In a point-to-point connection there are two cases:
1) [10GbE port A] <=> [transparent ntwk] <=> [10GbE port B]
2) [10GbE port A] <=> [SONET ntwk] <=> [10GbE port B]
In the first case "transparent" means OTN or "2R/3R WDM" or dark fibre.
The second case is when in between the two 10GbE ports there is a
SONET network (or the cascading of transp. and SONET networks, with at
least one segment being an SONET network).
Let's suppone that the "default" mode of the two 10GbE ports is
10GBASE-R: only in the second case the two 10GbE ports will "see" a
valid SONET signal because the two Regenerator Section layers at the
"boundary" of the SONET network (inside the ELTEs) will, in any case,
generate a SONET framing.
So only in the second case the two 10GbE ports will go to use SONET
framing for both TX/RX sides.
This can work also when one of the two 10GbE ports is forced to be
10GBASE-W by human intervention.
Of course there is the need to better understand which is the best
"strategy" to be adopted (hysteresis, time-out, ...) in case of
temporary failure of the link, to avoid "ping-pong" decisions.
Best regards,
Luigi Ronchetti
> -----Original Message-----
> From: pbottorf@xxxxxxxxxxxxxxxxxx [mailto:pbottorf@xxxxxxxxxxxxxxxxxx]
> Sent: Monday, April 23, 2001 07:31 PM
> To: Luigi.Ronchetti@xxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Cc: pbottorf@xxxxxxxxxxxxxxxxxx; Ronchetti, Luigi /itah32
> Subject: Re: One common type of 64B/66B PCS?
>
>
>
> Luigi:
>
> I like this proposal very much, though I disagree with a
> number of the
> points you are making. The current design already allows for
> a dual mode
> PHY. It requires 2 transmit clock sources for a dual mode PHY
> which will
> need to be switched when moving form the 10GBASE-R and
> 10GBASE-W modes. The
> advantage to using the same clock source for both is that a
> dual mode PHY
> will require only a single clock source.
>
> I certainly disagree that the number of interface types would
> be reduced
> from 4 to 7. The reason we have 7 interface types is because
> there is no
> ability to autodetect between 10GBASE-R and 10GBASE-W. Since
> the 10GBASE-R
> and 10GBASE-W are incompatible due to the added bytes and
> scrambler of the
> WIS the only way they could be treated as the same interface
> type is if we
> had a standard way to autodetect between them. The current
> standard has no
> way to connect 10GBASE-R to a 10GBASE-W and have them
> automagically resolve
> the coding and proceed to communicate. It will require human
> intervention
> to configure 10GBASE-R or 10GBASE-W even if a single clock
> source is used.
>
> Cheers,
>
> Paul
>
>
> At 06:38 PM 4/20/2001 +0200, Luigi.Ronchetti@xxxxxxxxxx wrote:
> >Hi all,
> >
> >did you ever think about the possibility to have only one type of
> >64B/66B PCS (the same circuit for 10GBASE-R and 10GBASE-W)?
> >
> >Consider to have only one type of PCS that can remove (add) idles as
> >for WIS applications and can integrate (as option) the SONET framer:
> >the upper interface of this PCS may connect to the RS through the
> >XGMII or this PCS may connect to an XGXS sublayer.
> >The XGXS and the RS provide the same service interface to this PCS.
> >The lower interface of this PCS connects only to the PMA sublayer
> >to support the same PMD.
> >
> >When the SONET framer inside this PCS is bypassed (or it is not
> >present), the nominal rate of the PMA service interface is 622.08
> >Mtransfers/s which provides capacity for the MAC data rate of about
> >9.65 Gb/s.
> >
> >When the SONET framer inside this PCS is used, the nominal rate of
> >the PMA service interface is again 622.08 Mtransfers/s which instead
> >provides capacity for the MAC data rate of about 9.29 Gb/s.
> >
> >In both cases the MAC uses IFS stretch mode to ensure that there
> >will be enough idle time that the PCS can delete idles to adjust to
> >the lower rate, with two different values for ifsStretchRatio (about
> >221 bits instead of 104 bits for the first case).
> >
> >Since the data rates are now the same and there is only one PMA
> >interface connection, there are no more additional constraints.
> >
> >Here a list of Con's and Pro's (for sure it is not exhaustive):
> >
> >---- Con's ----
> >1) the LAN "useful" bit rate for 10GBASE-R is reduced by 3.5%
> >2) need to introduce a new ifsStretchRatio value for that
> >3) ...
> >
> >++++ Pro's ++++
> >1) only one type of 64B/66B PCS is needed (two ASICs with the same
> > pinout, one with, the other without the SONET framer, can be
> > hosted by the same PCB)
> >2) only one type of REFCLK (622.08MHz) for serial PMA is needed
> >3) PMA REFCLK is always independent from XGMII_TX clock
> >4) PMA and PMD, just characterized for SONET, can be used without
> > the need of further investigations/tests (for example the
> > 10Gig MSA module or an OIF defined VSR can be used for both
> > LAN/WAN application)
> >5) there is now the possibility to have an automatic adaptation of
> > the 10GbE interface to LAN or WAN applications, depending on
> > what is in between the two peer interfaces, or by presetting
> > (for an PCS with SONET framer inside, of course).
> >
> > As a consequence there will be only 4 physical types instead of 7
> >
> >6) proprietary WDM solutions are able to better transport both LAN
> > and WAN signals because of 3R regeneration is now allowed,
> > (reclocking with a "standard" SONET clock is now possible)
> >
> >... and if, because of points 2) and 3), the PMA REFCLK is generated
> >locally with an accuracy of at least 20ppm ...
> >
> >7) no synchronization problems (PJC thresholds reached) will be
> > reported when 10GbE WAN is transported over an SONET network
> >8) the emerging OTN is now able to transport both 10GbE LAN and WAN
> > signals without the need of "special" adaptation
> >9) ...
> >
> >Waiting for your comments to complete the above list,
> >best regards,
> >
> > Luigi Ronchetti
>
> Paul A. Bottorff, Director Switching Architecture
> Enterprise Solutions Technology Center
> Nortel Networks, Inc.
> 4401 Great America Parkway
> Santa Clara, CA 95052-8185
> Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
> email: pbottorf@xxxxxxxxxxxxxxxxxx
>