RE: Clock Tolerance and WAN PHY
Roy,
Thank you for the detailed explanation. It helps a lot. However, I still do
not understand couple of things, and would be glad to get some help in. The
first issue is:
A WAN PHY system (Down from the MAC) may looks like:
MAC DEVICE - (xgmii/xaui) - PCS, WIS, PMA - (xsbi) - SERDES (or MUX-DEMUX)
- (differential pecl) - OPTICS - (fiber)
A POS system (down from the link layer) may looks like:
LINK LAYER DEVICE - (pos_level_x) - POS FRAMER DEVICE - (oif_sfi_4 for
instance) - SERDES (or MUX-DEMUX) - (differential pecl) - OPTICS - (fiber)
Both systems look pretty much the same. So, you're saying that the POS
framers are more expensive then Ethernet devices? Is that the motivation?
Or: The SONET BW efficiency is better in the ETHERNET system? I think there
is not much difference from functional point of view, as above the link
layer (IP layer for instance) everything is just the same. Is that correct?
and if so:
Suppose that in the Ethernet system (Lower one) I'm replacing the Ethernet
SERDES and OPTICS devices with SONET SERDES and OPTIC devices. Then I can
achieve clock match to SONET in terms of drift and jitter spec. I
understand, that even after doing so, that with current definition of WIS
you still do not able to connect to the SONET network. So my question is
would'nt it be better if the WIS would be implementing a full SONET framing?
In this case, would you be able to connect to the SONET? Why?
And, at last, the third issue:
Anyway you must use this ELTE in your system. With the WANPHY you have to
do:
MAC - (Wan phy) - ELTE - (sonet ring)- ELTE - (wan phy) - MAC
So: Just do the WIS encapsulation in the ELTE. That is, replace it with the
system:
MAC - (Serial lan phy) - ELTE - (sonet ring) - ELTE - (serial lan phy) - MAC
Anyway, the WIS takes 64/66 frames and encapsulates them into the SONET
frame. So just take the 66/64 bit stream that comes to the ELTE through the
serial LAN and do the same there with a full SONET compliancy. Is that
correct? What is the advantage comes from doing the WIS in the PHY? (The
rate is not a problem Just operate the MAC in SONET rate as you do anyway
and put the FIFO in the ELETE as you anyway have in the WIS)
Thanks (Sorry for the long mail)
Boaz
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Tuesday, January 23, 2001 5:36 PM
> To: Boaz Shahar; 'Tom Alexander'; 'James Colin';
> Luigi.Ronchetti@xxxxxxxxxxxxxxxx; tripathi@xxxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Clock Tolerance and WAN PHY
>
>
> Boaz,
>
> There are two major miss-conceptions about POS. The first is that it
> directly connects to SONET transmission systems. It does not. POS
> interfaces to customer facing, reduced function SONET
> facilities. The
> primary function that causes the most problem with SONET systems, and
> requires a change in service provisioning methodologies has
> to do with
> protection switching. Standard SONET has it, POS interfaces
> invariably do
> not. The second is that IETF creates globally standards.
> Because of the
> way that the IETF standard was written, many of the POS
> interfaces that
> work well with SONET do not work well with SDH because of
> overhead byte
> usage incompatibility.
>
> I was involved with the development of POS several years ago.
> Almost all
> of us within the transmission industry thought that we could
> make a router
> part of the transmission network. We were wrong. A router is data
> equipment, not transmission equipment. The level within the
> OSI stack that
> routers operate at is two layers above SONET. There is
> almost a total
> disconnect between the operation of the router, as a router,
> and SONET
> transmission systems. The attempt to make a router be part of the
> transmission system is perhaps one of the reasons that POS
> interfaces are
> so expensive, per megabit, compared to GbE.
>
> One of the reasons that I have been pushing 10GbE WAN PHY to
> not be full
> SONET compliant is to prevent network implementers from
> falling into the
> same trap, that an Ethernet data switch could be an active
> part of the
> transmission network. Other reasons are that by reducing the
> management
> overhead bytes to a minimum, a set that is common between
> SONET, SDH, and
> SDHJ could be provided, making 10GbE fully interoperable, as
> a passive
> managed element to all of the transmission systems in the
> world. Another
> reason for the Ethernet WAN PHY is reduced cost. The less complex
> management overhead, compared to POS, gives Ethernet an additional
> opportunity to come in a greatly reduced cost, compared to POS.
>
> I hope that this helps you understand why 10GbE WAN PHY will
> be used in
> place of POS. In addition, I wonder how many people have
> recognized that
> the ability to use the Ethernet tag and queuing functionality
> is similar to
> what MPLS is advertised to be going to do. This is a customer
> implementation issue, but I would speculate that a lot of
> customer are
> looking very hard at this as well.
>
> Thank you,
> Roy Bynum
>
>
>
> At 10:33 AM 1/23/01 +0200, Boaz Shahar wrote:
>
> >Tom,
> >Do you see any justification in using this rather then POS?
> >I Mean:
> >If you compare the system {XGXS,PCS,WIS,PMA,PMD} + ELTE to a
> regular POS
> >system, you haev:
> >
> >1.In the POS system you do not need the ELTE; You can
> directly connect to
> >the SONET network
> >2.All the world is talking POS today
> >3.There are components with I/F dedicated to POS which are
> different then
> >XGMII
> >
> >The only advantage (I see) in WAN-PHY is that the
> encapsulation is more
> >efficient in terms of BW consumption from the SONET network.
> >
> >Regards,
> >Boaz
> >
> >
> > > -----Original Message-----
> > > From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
> > > Sent: Monday, January 22, 2001 10:03 PM
> > > To: 'James Colin'; Luigi.Ronchetti@xxxxxxxxxxxxxxxx;
> > > tripathi@xxxxxxxxxxxx
> > > Cc: 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/
> > >
>