RE: Clock Tolerance and WAN PHY
Hi Gary, and All,
Here is the clock and its tolerance of the client signal for G.709 OTN
(Optical Transport Network) that will be approved by ITU-T (Feb 2001).
It does not support the direct mapping of 10.3 Gb/s LAN-PHY signal.
a) it accepts OC-192c (9 953 280 kbit/s) format with approximately
+/- 45 ppm clock tolerance (CBR10G asynchronous mapping into OPU2)
OPU2: Optical Channel Payload Unit 2 (OPU1 is for 2.5G, OPU3 is for 40G)
b) it accepts OC-192c (9 953 280 kbit/s) with +/- 20 ppm tolerance
(CBR10G bit-synchronous mapping into OPU2)
c) it accepts bit stream (approximately 9 995 276.962 kbit/s) with
+/- 20 ppm tolerance
(Mapping of non-specific client bit stream into OPU2)
The possible directions I see in the 802.3ae WAN-PHY are;
1) no change.
WAN-PHY signal with +/- 100 ppm tolerance will be accommodated into
OTN by ELTE (i.e. by using SONET pointer manipulation mechanism).
2) reduce the WAN-PHY clock tolerance to +/- 45ppm.
This will allow us to map the WAN-PHY signal into OPU2 directly if
the OTN edge equipment supports asynchronous mapping (i.e. byte
stuffing mechanism similar to that using the SONET H3 byte).
3) reduce the WAN-PHY clock tolerance to +/- 20ppm.
This will allow us to map the WAN-PHY signal into OPU2 directly
even if the OTN edge equipment only supports bit-synchronous mapping
(i.e. WAN-PHY clock is used in the OTN signal as well).
I have no preference in the above three directions since my own
interest is to have 9.29 Gb/s MAC rate from the LAN Equipment.
Instead, I recommend vendors to support one more MAC rate of
9.61 Gb/s. This will allow us to map 64/66-encoded LAN-PHY signals
into OPU2 by simply deleting the inter-frame Idles.
(9.61 Gb/s = 9 953 280 kbit/s * 64/66 * 237/238)
Best Regards,
Osamu
At 00:37 01/01/25 -0500, Gary Nicholl wrote:
http://www.ieee802.org/3/10G_study/email/msg04293.html
> Would it be also possible to map the LAN PHY directly into the OTN ( i.e.
> a 10.3125 Gbit/s nominal frequency client signal)?
At 09:26 01/01/24 -0600, Roy Bynum wrote:
http://www.ieee802.org/3/10G_study/email/msg04277.html
> The tighter clock
> tolerance, even in the OTN is a function of attempt to maintain the same
> old multiplexing nature of SONET and SDH, instead of the just the
> operational management of the optical services. The vendors that are
> pushing for the tighter clock tolerance in the OTN at the ITU have a vested
> interest in wanting to be able to multiplex a very expensive "digital
> wrapper" around the customer's optical signal. At present, there are so
> many options for the digital wrapper that none of the different vendors
> wrappers are fully interoperable. Personally, I don't believe that the OTN
> "digital wrapper" solution will make it in the market long term.
>At 15:49 01/01/23 +0100, Luigi.Ronchetti@netit.alcatel.it wrote:
http://www.ieee802.org/3/10G_study/email/msg04259.html
> I apologize but it was not my intention to suggest you to directly
> interface the WAN PHY to standard SONET/SDH network (I completely
> agree with you all, ELTE is needed).
>
> My intention was to make you aware of the new emerging standard that
> defines OTN (Optical Transport Network) in ITU-T (G.709).
> OTN is a "server layer" also for SONET/SDH services (i.e. for the
> first time, SONET/SDH is a "client layer").
> OTN is a "networking solution": it comprises its own performance
> monitor, path provision, ... functions.
> A CBR10G client signal (see my previous mail) is seen from OTN as a
> constant bit rate stream.
>
> I know that one 802.3 "philosophy" is to increase bandwidth by 10
> with a cost increasing of only 3 or 4, for each new generation; I
> wander if (for WAN interfaces only, not for LAN ones) it is convenient
> to make today a "little" exception, to gain advantage from the above
> mentioned new ITU-T standard.
At 12:03 01/01/23 -0500, Geoffrey Garner wrote:
http://www.ieee802.org/3/10G_study/email/msg04261.html
> I want to clarify Luigi's email; his point concerns the Optical Transport
> Network (OTN) defined in G.709; it does not concern the SONET network.
> I think this may have gotten lost in the discussion.
>
> Mappings have been defined in
> G.709 to map constant bit rate (CBR) client signals into the OTN. One of
> these mappings is for a 9.95328 Gbit/s nominal frequency client signal.
> The mapping requires that the CBR client
> have a frequency that is within +/- 20 ppm of the nominal frequency.
> The 9.95328 Gbit/s signal could be an OC-192 or STM-64 or, if desired, a
> 10 Gbe WAN signal.
> If there is a desire that it be possible for the 10 Gbe WAN signal to be
> carried by the OTN, then it would have to have a +/- 20 ppm frequency
> tolerance (this is based on the way the mapping is defined).
>
> Note that this is independent of the SONET network and whether or not
> there is an ELTE at the other end of the WAN PHY link; rather, it is related
> to whether it will be possible for the WAN PHY to be carried over the OTN.
At 14:31 01/01/22 -0500, David Martin wrote:
http://www.ieee802.org/3/10G_study/email/msg04254.html
> The 'ELTE' is also necessary to fill in the remaining SONET overhead.
At 12:02 01/01/22 -0800, Tom Alexander wrote:
http://www.ieee802.org/3/10G_study/email/msg04255.html
> There is no intent or support for directly interfacing the WAN PHY to standard
> SONET gear, especially in outside plant applications. Off hand, I can think of
> the following obstacles, even if you did match the clocks:
>
> - The optics are completely different
> - Most of the overhead bytes are not supported (for instance, it
> would not be possible to provision the ring)
> - Much of the defects and alarm reporting is missing
>
> While it is certainly possible for someone to put back the missing overhead
> and defects and also use SONET optics rather than Ethernet optics, all this
> is totally outside the scope of the 802.3ae standard.
At 00:53 01/01/21 -0800, James Colin wrote:
http://www.ieee802.org/3/10G_study/email/msg04252.html
> I think that the motto in the WAN PHY standard is the
> introduction of a new framing scheme (As opposed to
> POS), rather than being gluelessly connectable to the
> SONET network. The WAN PHY is supposed to be connected
> to a SONET LTE (ELTE) that is doing clock drift and
> jitter adjustments.
>
> Even if the WAN PHY Clock requirements were identical
> to those of SONET, I'm not sure if the ELTE is still
> needed or the WAN PHY can be directly interface to the
> SONET ring. Can anybody comment on that?
At 18:39 01/01/19 +0100, Luigi.Ronchetti@netit.alcatel.it wrote:
http://www.ieee802.org/3/10G_study/email/msg04249.html
> I think that is not enough to reduce the clock tolerance to 50ppm.
>
> As far as I know, ITU-T is going to approve (February 2001) a new
> recommendation (G.709) that defines OTN (Optical Transport Network).
> Future optical backbones over long distances will likely to be realized
> using G.709 and this will happen before 10 GbE final approval.
>
> In G.709, among the others, a CBR10G client signal is defined as "a
> constant bit rate signal of 9953280 kbit/s +/-20 ppm" (for example an
> OC-192/STM-64 signal and then, in principle, also a 10 GbE WAN signal).
>
> So, in my opinion, at least for a 10 GbE WAN signal, the clock
> tolerance should be 20ppm.
At 12:02 01/01/09 -0800, Devendra Tripathi wrote:
http://www.ieee802.org/3/10G_study/email/msg04213.html
> Right now we are specifying the clock tolerance of 100 ppm.
> Currently in-expensive oscillators are available with tolerance
> value less than 50 ppm. Just like we are moving voltage levels,
> it is time we revise the tolerance value too. The elastic buffer
> requirements get simplified by this assumption. I propose that
> we reduce it to 50 ppm.
---------------------------------------
Osamu Ishida,ishida@exa.onlab.ntt.co.jp
NTT Network Innovation Laboratories
TEL:+81-468-59-3263 FAX:+81-468-55-1282
---------------------------------------