RE: SONET/Ethernet clock tolerance

["Tim Armstrong" <tim@xxxxxxxxxxxxxxxxxx>]

Title: RE: SONET/Ethernet clock tolerance

Osamu,

Regarding the subset of SONET/SDH overhead functionality required by the
proposed WAN-Compatible PHY: this has been described in

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

and, in greater detail, in

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

Some of the functions that are NOT needed by the WAN-Compatible PHY that
would normally be required by STS-192 PTE are (the most significant are marked
with an asterisk):

Section Orderwire (E1) insert / extract
User Data (F1) insert / extract
Section DataComm (D1-D3) insert / extract
*383 STS pointer processors (192 in each of Tx and Rx direction normally required)
*384 Line BIP-8 (B2) generators (this is a big chunk: > 6144 bits of high-speed storage)
*192 Line BIP-8 extract / compare and B2 mis-match accumulator (~ 1600 bits of storage)
Line APS bytes (K1/K2) extract / validate
Line DataComm (D4-D12) insert / extract
Synchronization Status Message (S1) extract / validate
Line REI (M1) extract / accumulate
Line Orderwire (E2) insert / extract
Path Trace (J1) extract / message assembly / Trace Mismatch compare
Path BIP-8 (B3) modification to support Tandem Connection
Path User (F2) insert / extract
Path Multiframe (H4) insert / extract
Tandem Connection Maintenance (N1) insert / extract

In addition to these data-path insert / extract functions are the corresponding processing
functions and management registers, which are also NOT required.

Conversion to power-dissipation/gate-count/etc will depend on partitioning and process.

Tim Armstrong
Nortel Networks

-----Original Message-----
From:   Osamu ISHIDA [SMTP:ishida@xxxxxxxxxxxxxxxxxxx]
Sent:   Tuesday, April 11, 2000 12:34 AM
To:     Armstrong, Tim [SKY:1I63:EXCH]
Cc:     stds-802-3-hssg@xxxxxxxx
Subject:        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.