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

RE: SONET/Ethernet clock tolerance

Title: RE: SONET/Ethernet clock tolerance


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

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

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