RE: SONET/Ethernet clock tolerance

["Tim Armstrong" <tim@xxxxxxxxxxxxxxxxxx>]

Title: RE: SONET/Ethernet clock tolerance

Rich,

I just wanted to address the points you raise in 2) and 3) below:

Your point 2):

The issue is: is it a worthwhile investment of effort to define an XGENIE-based OA&M
capability that duplicates functionality that could be more quickly derived from the
existing, well-proven, SONET/SDH infrastructure? This infrastructure includes not
just network hardware and software, but also the substantial body of standards work
developed in ITU and T1 over the course of the last one and one-half decades. This
investment should be leveraged to extract as much return on investment as possible,
as quickly as possible. This return on investment benefits both the operators and
the users of those networks. It also provides an assured, near-term market for vendors
of 10GE equipment.

Your point 3):

The 'difficulty of SONET framing' may be a case of the unfamiliar
appearing more daunting than the familiar. In addition, you have
to remember that what has been proposed for the WAN-Compatible PHY in

http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/figueira_2_1199.pdf

is a very small subset of the full functionality of a 'SONET framer'.

The ability to do clock tolerance compensation is provided by a single
pointer processor. This is a significant reduction from the N pointer
processors required for a full SONET STS-N 'framer'. Also, there is a full
pointer processor only in the Rx direction (PHY to MAC). In the Tx direction,
a fixed value is simply written into the pointer.

I'm not sure what you are referring to as the 'synchronization
complexity'. The candidates appear to be:

Frame Synchronous Scrambler (provided by simple A1/A2 align)
Identification of 'Section/Line' overhead (also provided by A1/A2 align)
Identification of 'Path' overhead (provided by a single Pointer processor)
Self-Sync Scrambler (provided by the scrambled data)

None of these synchronizing functions is particularly complex.

Regarding 'the difficulty of running pure scrambled code across
multiple lanes': to the best of my knowledge, no one has proposed a pure
scrambled code for multiple lanes. If you are referring to SUPI, as described in

http://grouper.ieee.org/groups/802/3/ae/public/mar00/bottorff_1_0300.pdf

then you have to remember that SUPI provides unscrambled phase markers at
deterministic intervals to permit multi-lane alignment.
 

-----Original Message-----
From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
Sent:   Sunday, April 09, 2000 3:57 AM
To:     HSSG
Subject:        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