RE: What is 802.3ae WAN-PHY?

["David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>]

Title: RE: What is 802.3ae WAN-PHY?

Praveen,

Could you please clearly identify what WAN infrastructure, other than SONET/SDH,
you are referring to in your closing paragraph below. And in the interest of satisfying
the 'broad market potential' PAR criteria, specifically one that is in wide deployment
today at 10G. Information comparable with that presented in

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

would be appreciated. Thanks.

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx

========================

-----Original Message-----
From:   Praveen Kumar [SMTP:praveen@xxxxxxxxxxx]
Sent:   Tuesday, April 04, 2000 2:22 PM
To:     Jonathan Thatcher
Cc:     stds-802-3-hssg@xxxxxxxx; ishida@xxxxxxxxxxxxxxxxxxx
Subject:        RE: What is 802.3ae WAN-PHY?





>Question: while the 1:1 logical connection is easy for me to make, would
>there be any issue regarding the amount of data that could be carried in the
>SONET overhead compared to the amount of data that could be carried in the
>IPG?

I think there is still quite some work to be done with respect to mapping
the SONET (or OAM&P) overhead onto the IPG. For example, even if we decide
to use the IPG to carry the overhead, it would still be useful to preserve
the notions of section,line & path. How is this layered overhead going to be
distributed. Also, it would still be useful to allow multiple 10G signals to
be multiplexed to a higher rate signal downstream. SONET framing does all of
this for us TODAY.
Another issue associated with using IPG to carry overhead is that, the ratio
of overhead to payload is now a function of payload (packet) size. This
means that the bandwidth consumed by the overhead channel (IPG) is now
unpredictable and Iam not sure if carriers are going to like this.

Nevertheless, I see some benefits associated with the 10GENIE approach. I
think the question of "Why SONET framing" has not been convincingly answered
by the "WAN PHY" proposal. For example, SONET is not the only transport
network. What if one needs to connect the 10G WAN link to an all-optical
(non-SONET) wavelength switched transport network. Is the STS signal the
most optimal in this scenario?

-Praveen




>> -----Original Message-----
>> From: Osamu ISHIDA [mailto:ishida@xxxxxxxxxxxxxxxxxxx]
>> Sent: Tuesday, April 04, 2000 7:50 AM
>> To: Gary Nicholl; stds-802-3-hssg@xxxxxxxx
>> Subject: What is 802.3ae WAN-PHY?
>>
>>
>> Dear Gary,
>>
>> Thank you for your intelligible feedback.  Now I became convinced
>> that I speak English :-).  I am happy to hear the Japanese style
>> here, Nicholl-san!  But please feel free to say just Osamu, because
>> it helps me to trust (fake?) myself that I speak English.
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01952.html
>>
>> Also, thanks to you, I became convinced that we have some issues of
>> clock tolerance compensation in SONET-framing that Rich has pointed
>> out farsightedly.
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01866.html
>>
>> On the other hand, it seems to me that this community has consensus
>> that the ELTE, not the WAN-PHY with SONET framer, is the demarcation
>> point between SONET and Ethernet.  In other words, WAN-PHY with SONET
>> framer or Uni-PHY with WIS (WAN interface sublayer) should not be
>> SONET.  (All, please let me know if this is a wrong observation.)
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01958.html
>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/frazier_1
>> _0300.pdf
>>
>> Then why we need WAN-PHY or WIS other than ELTE?
>>
>> The answer is in Mr. Paul Bottorff's slides in Albuquerque; the
>> router/SW requires minimal management capability of WAN.
>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/bottorff_
>> 2_0300.pdf
>>
>> Here I completely agree with Paul.  This is indispensable to meet the
>> PAR scope "add parameters and mechanisms that enable deployment of
>> Ethernet over the Wide Area Network". 
>> http://grouper.ieee.org/groups/802/3/ae/PAR-802-3ae.pdf
>>
>> Then do we need SONET-frame between WAN-PHY and ELTE?
>>
>> In my opinion, the answer is NO.
>>
>> Once we have Mr. Shimon Muller's open-loop control to provide
>> OC-192c/VC-4-64c compatible MAC rate, my understanding of the need
>> for the SONET-framed PHY or WIS is limited to the OAM&P capability
>> supported by minimal overhead bytes in a SONET frame.
>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/muller_1_0300.pdf
>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/figueira_
>> 1_0300.pdf
>>
>> Here you have another solution 10GENIE; Layer-1 signaling by using
>> interpacket gap.
>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/ishida_1_0300.pdf
>> Assuming that 10GENIE can support the similar OAM&P to the ELTE, my
>> perspective says that 10GENIE would be cheaper than WAN-PHY and WIS;
>> no SONET framer (pointer manipulation), much less extra buffer for
>> OAM&P data insertion, no 9.95Gb/s CLK, no jitter-tolerance
>> limitation. 
>> I will shed light on this comparison in my up-dated 10GENIE proposal
>> in Ottawa.
>>
>> Of course I have understood that 10GENIE has a tough problem
>> indicated
>> by Mr. Steve Haddock; Who is going to define how to OAM&P?
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01919.html
>>
>> My perspective says that IEEE 802 is the only candidate to be able to
>> define it.  I know that this don't suit the traditional
>> 802.3's taste,
>> but still I hope to have your support to define it.  Otherwise we
>> will see the law of the jungle until some de facto OAM&P has
>> established; we will see wasteful investment to every potential loser
>> and local dialect cutting the market into pieces.  We will fail to
>> catch a golden opportunity to unify LAN/WAN hardware for datacom at
>> 10 Gb/s; and may degrade huge unified market potential.
>>
>> In Ottawa, I will show you how 10GENIE OAM&P is simple and easy-
>> interoperable.  I will restrict it to non-negotiable functions. 
>> I think this may be simpler than the auto-negotiation with config-
>> register defined in 802.3z Clause 37. 
>>
>> All, any feedback on this matter would be greatly appreciated.
>>
>> Best Regards,
>> Osamu
>>
>> At 4:08 PM -0400 00.4.3, Gary Nicholl wrote:
>> > I agree with Ishida-san. 
>> >
>> > I think we need to understand that there are two separate
>> issues here.
>> >
>> > (1)  clock tolerance/accuracy specifications (i.e.
>> +/-100ppm, +/-4.6 ppm, etc)
>> > (2)  jitter budget specifications (jitter generation,
>> transfer and tolerance)
>> >
>> > The first one determines the lock range of any oscillators
>> and phase look loops in the network. In SONET the worst case
>> clock accuracy/tolerance is specified as +/- 20ppm and
>> therefore every oscillator and clock recovery circuit in a
>> SONET network should be able to lock on and hold to a +/-
>> 20ppm signal.
>> >
>> > The second one, as Ishida-san points out is, effectively
>> determines the maximum number of  through-timed regenerators
>> that can be traversed on an end-end SONET link to maintain a
>> specified link bit error rate.
>> >
>> > These two specifications (i.e. clock tolerance/accuracy and
>> jitter) are completely intendant. However from my experience
>> in dealing with POS (packet over SONET) there is a tendency
>> among some people to assume that they are related, in that a
>> more accurate clock (say 4.6ppm rather than 20ppm)
>> necessarily has better jitter performance. This is not the
>> case. In fact SONET has a single set of jitter specifications
>> (generation, transfer and tolerance) that are the same
>> irrespective of whether an interface is clocked from a
>> stratum 1 clock, a stratum 3 clock (4.6ppm) or a 'SONET
>> minimum' clock (20ppm).
>> >
>> > As a reference point POS interfaces use a 20ppm clock and
>> are fully compliant with the SONET/SDH jitter specifications
>> in Bellcore GR-253 and ITU G.958.
>> >
>> > Gary ........................
>>
>> -----------------------------------------
>> Osamu ISHIDA
>> NTT Network Innovation Laboratories
>> TEL +81-468-59-3263  FAX +81-468-55-1282
>>
>
>