RE: Clock Tolerance and WAN PHY
Osamu,
For the WAN-PHY I would vote for (3), i.e. reduce the clock tolerance to
+/- 20 ppm. This would allow the WAN-PHY to directly connect to a standard
OC-192 transponder interface on existing DWDM systems or to an OPU2
interface on future OTN systems, without the need for a complex ELTE function.
Gary ....
At 09:55 AM 1/27/01, Osamu ISHIDA wrote:
>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@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx
>NTT Network Innovation Laboratories
>TEL:+81-468-59-3263 FAX:+81-468-55-1282
>---------------------------------------