Re: SONET/Ethernet clock tolerance
Paul,
Lets take your argument (below) of why the WAN PHY is necessary apart one by
one:
1) "use of a bridge in the ELTE to transform a LAN-PHY to SONET takes away
control from routers attaching to the WAN."
Assuming that the LAN PHY must be converted to the WAN PHY at some point in a 10
GbE link, I believe that you are somehow creating a distinction between
performing this conversion within an ELTE and performing this conversion further
back in the link where the LAN PHY is converted to a WAN PHY. I don't see a
difference between these two conversion processes. Both required 802.1D bridges.
I've reviewed your 'Why WAN-PHY' presentation many times and am not convinced
that the bridge function went away. This is also borne out in the definition of
the 802.1D Relay function according to the 'WAN PHY Definitions' proposal from
Albuquerque which bears your name. Please help me understand the difference
here;
2) "extending any management capability into the SONET network": OAM&P over 10
GbE LAN links and even LAN to SONET and back to LAN may be easily accommodated
by proposals such as XGENIE from Mr. Osamu Ishida. Extending SONET framing, the
inability to do simple clock tolerance compensation, and other associated
baggage is a very expensive way of providing simple OAM&P transport;
3) "the 'sonet-like' WAN-PHY is the simplest implementation." I beg to differ
with this on multiple points, not the least of which are are the difficulty of
SONET framing, the inability to do simple clock tolerance compensation,
synchronization complexity, the difficulty of running pure scrambled code across
multiple lanes (e.g. PCB traces). Simplicity is embodied in the LAN PHY. SONET
framing may be added within the ELTE for those 10 GbE links entering the SONET
network. The UniPHY proposed by Mr. Howard Frazier is the simplest way I can see
of accomplishing the latter.
Best Regards,
Rich
--
Paul Bottorff wrote:
>
> 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
> 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
-------------------------------------------------------
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