Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SONET/Ethernet clock tolerance




Devendra,

The question I'm asking is actually fairly simple. 

All 10 GbE proposed link architectures are a subset of 1000BASE-X in that only
fiber and full-duplex mode is supported. Another similarity is that there is a
strong desire to retain a clock tolerance spec of +/-100 PPM. One of the key
differences between GbE and 10 GbE is that data is moving 10 times as fast for
10 GbE.

Clock tolerance compenstation for Gigabit Ethernet products is performed above
the Physical layer, usually within a switch and between links. A link and jitter
budget is specified for the Physical layer and all link elements, transceiver
modules, PCB traces, the fiber, the SerDes, GBIC cages, etc. must all not exceed
their jitter margins. This architecture is fairly fragile since an element
exceeding its allocated margins will "break" the link if all other elements are
worst case.

My experience thus far with the 2 Gbps Fibre Channel Physical layer
architecture, which uses the same link architecture as 1 GbE and 1 Gbps FC, is
that meeting the tighter jitter budgets at twice the speed is very difficult.

As a result, for 10 GbE, we have proposals to perform clock tolerance
compensation (read: retiming) in intermediate link elements. For example,
retiming may be necessary in a WWDM or Serial 10 GbE PCS/PMA in order to meet
the link and jitter budget of the medium. In essence, a 10 GbE link architecture
may be separated into three distint jitter domains, one intra-cabinet jitter
domain at either link end, and an inter-cabinet jitter domain primarily for the
medium. Please see:
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/taborek_1_0100.pdf,
slide 4. A 10 GbE implementation may choose not to perform retiming. However,
link jitter at all compliance points (TBD) must be met in order for the link to
operate reliably.

Whenever, retiming is performed within a link, the packet stream must be
adjusted. A 8B/10B PCS performs clock tolerance compensation by
insertion/removal of Skip (/R/) columns. This methodology may be employed at the
XGXS for a Serial PHY or the WWDM PCS and does not affect the packet stream.

SONET performs clock tolerance compensation via the manipulation of pointers
which involves significant modification of the SONET stream. My observation is
that wherever SONET framing is employed in link with a clock tolerance of +/-100
PPM that SONET reframing must be performed at any link point where clock
tolerance compensation is required. After all, this is the same methodology
employed in a SONET ring where a regenerator is periodically employed to ensure
the SONET stream meets its +/-4.6 PPM requirements.

It's not a "joint" problem. It's a problem with a so-called WAN PHY employing
SONET framing as the sole method of performing clock tolerance compensation.  

I understand how the 10 GbE link architecture works when SONET framing is
stripped off. I'm concerned about the implications of performing clock tolerance
compensation, if required, for a 10 GbE link architecture when SONET framing is
present.

Best Regards,
Rich
      
--

Devendra Tripathi wrote:
> 
> Hi Rich,
> 
> After replying to Mr Osamu, earlier I noticed some inconsistency in my
> statement. If all overheads (including POH) is getting stripped off and
> re-generated at the E-S joint and if, Ethernet Frame (including preamble)
> is SPE payload, where is the question of pointer adjustment?
> This means that I have missed your original point. Could you please explain the
> picture of data flow + mapping as the Ethernet packet moves to SONET frames
> and vice-versa ?
> 
> Thanks,
> Tripathi.
> 
> At 10:36 AM 3/28/00 +0900, you wrote:
> 
> >Tripathi,
> >
> >As I understand, your suggestion causes SONET Path Termination at the
> >edge of SONET infrastructure.  That will require 'Ethernet Path
> >Terminating Equipment' in addition to 'Ethernet Line Terminating
> >Equipment' to re-write B3 Bit-Interleaved Parity byte.
> >
> >Regards,
> >Osamu
> >
> >-----------------------------------------
> >Osamu ISHIDA
> >NTT Network Innovation Laboratories
> >TEL +81-468-59-3263  FAX +81-468-55-1282
> >-----------------------------------------
> >
> >At 9:20 AM -0800 00.3.27, Devendra Tripathi wrote:
> > > Rich,
> > >
> > > My suggestion is that clock adjustment should happen on Ethernet side of
> > > the "joint". The reason is that IPG can be used to compensate for
> > > adjustments. This will avoid any pointer adjustments in SONET frames.
> > >
> > > Regards,
> > > Tripathi.
> > >
> > > At 02:20 PM 3/25/00 -0800, you wrote:
> > >
> > >>Dave Martin, Norival Figueira,
> > >>
> > >>I've been looking at the various requirements for transporting Ethernet
> > >>over SONET and one of them in particular is bothering me. That requirement
> > >>is the one to bridge the clock tolerance of Ethernet (+/-100 ppm) with
> > >>that of SONET (+/-4.6 ppm).
> > >>
> > >>The root question I have is whether or not current SONET framing or that
> > >>proposed for the Ethernet WAN can accommodate a clock of +/- 100 ppm? This
> > >>would be required to transport the proposed WAN PHY (or UniPHY) across
> > >>clock domains tolerance. I'm asking this question because I'm trying to
> > >>proposal for SONET framing for the UniPHY which is 100% compatible and
> > >>come up with a compliant with SONET OC/192c and I am using all the WAN
> > >>PHY information presented by yourself and others as a model.
> > >>
> > >>My understanding from a previous presentation by Paul Bottorff,
> > >>http://grouper.ieee.org/groups/802/3/10G_study/public/july99/bottorff_1_
> > >>0799.pdf, slide 9, is that the payload clock tolerance is 320 ppm.
> > >>Since I'm unfamiliar with the many nuances of SONET framing, can you
> > >>please acertain that this is true? If the proposed SONET framing for
> > >>Ethernet is adequate to support +/-100 ppm clock tolerance compensation,
> > >>the second question I have is as to the mechanism for performing clock
> > >>tolerance compensation. It seems to me that the mechanism involves at
> > >>least the rewriting of SPE pointers and the modification of Line
> > >>Overhead Bytes (H1 and H2).
> > >>
> > >>My further understanding is that the clock tolerance compensation
> > >>process is referred to as one of the 3 "R's" (Re-Amplify, Re-Shape,
> > >>Re-Time). The specific process is Re-Timing and is usually reserved
> > >>to SONET Regenerators and LTE's (Line Terminating Equipment). It has
> > >>been proposed that Transponders for coupling an Ethernet WAN PHY to
> > >>SONET OC-192c can be either "Passive" or "Active" according to our
> > >>agreed upon "WAN PHY Definitions":
> > >>http://grouper.ieee.org/groups/802/3/ae/public/mar00/law_1_0300.pdf.
> > >>My observation is that a transponder which contains both 100 ppm and
> > >>4.6 ppm optics MUST perform re-timing. Therefore, it must be an
> > >>Active Transponder. This is also the case for all WAN PHY elements
> > >>which cross clock domain boundaries. Please help me validate or
> > >>invalidate my observations.
> > >>
> > >>If my observations are correct, my suggestion is to not bridge Ethernet to
> > >>SONET until the SONET boundary is encountered. A WAN PHY, SONET Lite or
> > >>UniPHY which transports SONET framed Ethernet in any manner may require
> > >> significant re-framing at any point that retiming is required.
> > >>
> > >>-------------------------------------------------------
> > >>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
                                
------------------------------------------------------- 
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