RE: Clock Tolerance and WAN PHY
Gary,
Several vendors are working a "Digital Wrapper" that is supposed to allow
the mapping of any optical data signal on to the OTN. The problems are:
the "Digital Wrapper" is not vendor interoperable in implementation; the
"Digital Wrapper" is green field and would require a long time to build out
any size of operational environment; the "Digital Wrapper" is new
technology and is very expensive; the "Digital Wrapper" is new technology
that is even more complex than SONET or SDH and would require a new
training cycle for all support and operations people, making cost of
operations higher; the "Digital Wrapper" is high bandwidth overhead which
requires expensive electronics to implement; etc. Some of these
propositions may change over the next ten years, but P802.3ae can not wait
that long.
Thank you,
Roy Bynum
At 12:37 AM 1/25/01 -0500, Gary Nicholl wrote:
>Luigi,
>
>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)?
>
>Regards,
>
>Gary Nicholl .....
>
>At 09:49 AM 1/23/01, Luigi.Ronchetti@xxxxxxxxxxxxxxxx wrote:
>>Dave, Tom, James and all,
>>
>>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.
>>
>>Best regards,
>>Luigi
>>
>> > -----Original Message-----
>> > From: dwmartin@xxxxxxxxxxxxxxxxxx [mailto:dwmartin@xxxxxxxxxxxxxxxxxx]
>> > Sent: Monday, January 22, 2001 11:11 PM
>> > To: james_colin_j@xxxxxxxxx; Ronchetti, Luigi /itah32;
>> > tripathi@xxxxxxxxxxxx
>> > Cc: dwmartin@xxxxxxxxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
>> > Subject: RE: Clock Tolerance and WAN PHY
>> >
>> >
>> >
>> > James, Luigi,
>> >
>> > The 'ELTE' is also necessary to fill in the remaining SONET
>> > overhead.
>> >
>> > ...Dave
>> >
>> > David W. Martin
>> > Nortel Networks
>> > +1 613 765-2901
>> > +1 613 765-0769 (fax)
>> > dwmartin@xxxxxxxxxxxxxxxxxx <mailto:dwmartin@xxxxxxxxxxxxxxxxxx>
>> >
>> > -----Original Message-----
>> > From: Tom_Alexander@xxxxxxxxxxxxxx
>> > [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
>> > Sent: Monday, January 22, 2001 11:12 PM
>> > To: james_colin_j@xxxxxxxxx; Ronchetti, Luigi /itah32;
>> > tripathi@xxxxxxxxxxxx
>> > Cc: Tom_Alexander@xxxxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
>> > Subject: RE: Clock Tolerance and WAN PHY
>> >
>> >
>> >
>> > James,
>> >
>> > 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.
>> >
>> > Best regards,
>> >
>> > - Tom
>> >
>> > -----Original Message-----
>> > From: James Colin [mailto:james_colin_j@xxxxxxxxx]
>> > Sent: Sunday, January 21, 2001 12:54 AM
>> > To: Luigi.Ronchetti@xxxxxxxxxxxxxxxx; tripathi@xxxxxxxxxxxx
>> > Cc: stds-802-3-hssg@xxxxxxxx
>> > Subject: Clock Tolerance and WAN PHY
>> >
>> >
>> > Luigi,
>> > 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?
>> >
>> > James
>> >
>> > --- Luigi.Ronchetti@xxxxxxxxxxxxxxxx wrote:
>> > > Hi Devendra and all,
>> > >
>> > > 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.
>> > >
>> > > Best regards,
>> > > Luigi
>> > > __
>> > > \/ Luigi Ronchetti
>> > > A L C A T E L via Trento, 30 - 20059 Vimercate (MI)
>> > > Italy
>> > > TND R&D phone: +39-039-686.4793 (Alcanet
>> > > 2-210-(3)4793)
>> > > fax: +39-039-686.3590 (Alcanet
>> > > 2-210-(3)3590)
>> > >
>> > > mailto:luigi.ronchetti@xxxxxxxxxxxxxxxx
>> > >
>> > > > -----Original Message-----
>> > > > From: tripathi@xxxxxxxxxxxx
>> > > [mailto:tripathi@xxxxxxxxxxxx]
>> > > > Sent: Tuesday, January 09, 2001 10:50 PM
>> > > > To: stds-802-3-hssg@xxxxxxxx
>> > > > Cc: tripathi@xxxxxxxxxxxx
>> > > > Subject: Clock tolerance
>> > > >
>> > > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > 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.
>> > > >
>> > > > Regards,
>> > > > Devendra Tripathi
>> > > > VidyaWeb, Inc
>> > > >
>> > >
>> >
>> >
>> > __________________________________________________
>> > Do You Yahoo!?
>> > Yahoo! Auctions - Buy the things you want at great prices.
>> > http://auctions.yahoo.com/
>> >
>