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

RE: SONET/Ethernet clock tolerance

Dear Tim,

As a SONET-framer customer, I am interested in your statement 
regarding "very small subset of the full functionality of a 'SONET 
framer'".  It would be appreciated if you could let me know your 
estimation how far you will be able to reduce the cost, power 
consumption, gate counts, and so on.  Also, it would be better 
if you could add the comparison with the circuits that perform 
skip /R/-column insertion/removal together with /O/ ordered set 

Last year my colleague designed the SONET framer that terminate 
VC-4-16c alone for our non-muxing LTE.  Yes, that is for a kind of 
ELTE at 2.5 Gb/s; it has a single pointer processor, not the 16 
pointer processors.  It still consumes several watts.  It still 
requires larger buffers for pausing at the 3*N-byte SONET header 

Am I missing something?

My basic question is that why we have to stick to SYNCHRONOUS 
mechanisms in order to relay packet data, where there are many 
interspersed IPG for easy clock adjustment.  We need very small 
buffers.  Why we need complex pointer manipulation mechanism just 
for sending OAM&P information?  I don't think a single pointer 
processing shown in slide 8 of Mr. Paul Bottorff's presentation
could be easy.

I don't say we don't need SONET framing.  It would be useful for the 
interface to the install-base SONET infrastructure.  Then why not 
be compliant to SONET?  It may be slightly (say it $100?) expensive 
than +/- 100ppm, but has no confusion and wider interoperability to 
conventional SONET regenerators/active transponders as Mr. Gary Nicholl 
has pointed out.

If you spare this expenses, I recommend you to re-consider your 
whole network;  Are you sure to carry your packet data on SYNCHRONOUS 
networks?  Is it worth investing further in legacy infrastructure?

Look at the real world.  You can see that native Ethernet deployment 
is starting here and there.  Soon you will hear customer's voice, as 
Mr. Bradley Booth has pointed out, that how we can manage the Ethernet 

Recommending the full set of WAN-PHY with SONET framer, ELTE, and SONET 
regenerators to your customer could be your choice, but the other 
vendors may provide a LAN-PHY + XGENIE with SONET OAM&P solution. 
Of course some brand-new methods with SNMP may exist as Jonathan has 
pointed out.  That should be customer's choice.

Note that, regardless of its inclusion of 802.3ae Std. or not, I will 
show you in Ottawa and San Diego how to map the XGENIE ordered set 
to/from SONET overhead bytes completely as best as I can.  I will 
leave the dicision in the community and the customers' hand.

Best Regards,

At 4:56 PM -0500 00.4.10, Tim Armstrong wrote:
> 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.