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
insertion/removal.
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
period.
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
http://grouper.ieee.org/groups/802/3/10G_study/public/july99/bottorff_1_0799.pdf
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.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02237.html
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
regenerators?
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02156.html
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.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02233.html
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,
Osamu
At 4:56 PM -0500 00.4.10, Tim Armstrong wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02241.html
> 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.