Re: SONET/Ethernet clock tolerance
Gary:
I agree. The ELTE is the demarcation point between SONET and Ethernet.
The WAN-PHY is necessary even if you consider the ELTE the demarcation
point. As I've pointed out in the 'Why WAN-PHY' presentation, use of a
bridge in the ELTE to transform a LAN-PHY to SONET takes away control from
routers attaching to the WAN. It also prevents extending any management
capability into the SONET network(extending a path from WAN-PHY to
WAN-PHY). Finally, the 'sonet-like' WAN-PHY is the simplest implementation.
Cheers,
Paul
At 05:58 PM 4/3/00 -0400, Gary Nicholl wrote:
>
>At 01:26 PM 3/31/00 , Paul Bottorff wrote:
>>
>>Rich:
>>
>>The 10 GigE WAN-PHY is asynchronous with standard Ethernet clock
>>tolerances. The WAN-PHY has no SONET clock tolerance or jitter
>>considerations. It is true that ELTE equipment (which is not part of
>>Ethernet) needs to make a conversion into the SONET clock domain. Since
>>this function is part of SONET equipment is only of academic concern to the
>>IEEE. David's previous emails indicate how the SONET ELTE equipment may
work.
>
>Paul,
>
>Maybe I'm still confused. From your description it sounds like it is the
ELTE and not the WAN-PHY that is the real demarcation point between the
'sonet' world and the 'ethernet' world ? The ELTE takes in a 'sonet-like'
signal on the WAN-PHY interface from the ethernet switch and then converts
it to a 'sonet-compliant' signal to be transported over the wide area
optical network.
>
>Given that the ELTE has to contain sonet processing to convert between the
ethernet clock domain and the sonet clock domain, then why not consolidate
all the sonet processing onto the ELTE and perform the ethernet-to-sonet
mapping here as well. This means that we could use a standard ethernet
signal as the interface between the ethernet switch and the ELTE, and not
have to define a brand new 'sonet-like-lite-compatible-framed-etc........'
interface specifically for 10GE ?
>
>Gary ....
>
>
>>
>>In the IEEE domain clock compensation may be performed by IDLE frame
>>deletion/insertion. Idle frame deletion/insertion is supported by the
>><Length><HEC> delimiting system we have proposed.
>>
>>Cheers,
>>
>>Paul
>>
>>At 11:21 AM 3/28/00 -0800, Rich Taborek wrote:
>>>
>>>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
>>>
>>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
>>
>
>
>
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