Re: What is 802.3ae WAN-PHY?
Rich,
One of the advantages, or disadvantages, of working within a large service
provider is close access to the work going on in the other standards
organizations. It sometimes gets a little beyond "bleeding edge",
particularly when it comes to attempting to integrate all of it within a
cohesive view of the directions that communications technology is going.
Some of it is very "threatening" to people that are imbedded in legacy
technologies. I often refer to this as the "politics of technology". I am
sure that you have run into this yourself.
Regards,
Roy
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Sunday, April 09, 2000 7:49 PM
Subject: Re: What is 802.3ae WAN-PHY?
>
> Roy,
>
> Wow! I can hardly wait! Do you mean to tell me that there are some secret
> methods of performing clock tolerance compensation under development for
SONET
> that will soon be released to benefit all mankind!
>
> Sorry. I couldn't hold that one back ;-)
>
> On a serious note, I agree wholeheartedly with your statement in the last
> paragraph of your response to Mr. Osamu Ishida:
>
> "Any Ethernet data switch and router interfaces that are at SONET/SDH
> multiplexed subrate speeds will continue to be expensive compared to the
> proposed P802.3ae WAN compatible PHY interface."
>
> I'll add to this: It is a unanimously agreed upon objective of IEEE
P820.3ae to
> define a WAN PHY, operating at a data rate compatible with the payload
rate of
> OC-192c/SDH VC-4-64c. The definition of this PHY is well underway, with
multiple
> proposals aired to the Task Force. A low-cost 10 GbE alternative to
SONET/SDH
> multirate interfaces or switch and router interfaces is imminent.
>
> Best Regards,
> Rich
>
> --
>
> Roy Bynum wrote:
> >
> > Osamu,
> >
> > Please understand that I am under certain levels of Non-Disclosure for
some
> > of your issues. The real consideration for P802.3ae TF is that at 10Gb,
the
> > P802.3ae WAN compatible PHY will have complete occupancy of any fiber or
> > wavelength that it rides on. Any muxing that is done, is done at the
> > wavelength level within DWDM, not at the data signal level. This is
> > recognized as changing the rules for needing common transmission
clocking,
> > also known as "Stratum" clocking. While the transmission systems
themselves
> > are still required to provide for close clock transfer tolerance, the
full
> > wavelength data originating systems are no longer under that
restriction.
> > There is, or soon will be, one or more contributions to the other
standards
> > bodies regarding this.
> >
> > Subrates of SONET/SDH are still multiplexed at the TDM data signal
level.
> > The data sources for these still require the same level of common
> > transmission clocking as always. For that reason, EOS at OC3/STM1
through
> > OC189c/STM63c still require loop timing off of the Stratum clocked
> > transmission systems. Any transmission systems that provide 802.3
Ethernet
> > interfaces, at any rate, must buffering/bridging functions that provide
for
> > the adjustment between +/- 100ppm clocking of Ethernet and the +/- ~4ppm
> > clocking of the Stratum timed transmission systems. Ethernet data
switches
> > and routers that implement subrate interfaces, such as the ITU PRC EOS
> > proposal will require the normal loop timing and close clock tolerance
of
> > the existing SONET and SDH systems. You need not have any concerns.
For
> > normal multiplexed SONET and SDH systems, I do not foresee any proposals
to
> > ANSI or ITU to change these timing requirements.
> >
> > As you can see, there is a major distinction between the proposed
> > requirements of P802.3ae and the normal TDM multiplexed SONET and SDH
> > transmission systems. Any Ethernet data switch and router interfaces
that
> > are at SONET/SDH multiplexed subrate speeds will continue to be
expensive
> > compared to the proposed P802.3ae WAN compatible PHY interface. I am
sure
> > that there are others in the TF with transmission systems experience
that
> > can confirm these distinctions.
> >
> > Thank you,
> > Roy Bynum
> >
> > ----- Original Message -----
> > From: Osamu ISHIDA <ishida@xxxxxxxxxxxxxxxxxxx>
> > To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; David Martin
> > <dwmartin@xxxxxxxxxxxxxxxxxx>
> > Cc: <stds-802-3-hssg@xxxxxxxx>
> > Sent: Sunday, April 09, 2000 2:06 AM
> > Subject: Re: What is 802.3ae WAN-PHY?
> >
> > >
> > > Hi Roy, Hi Dave,
> > >
> > > Thank you for your feedback. Your comments are helpful for me to
> > > understand what was going on in HSSG and T1, since I have joined
> > > HSSG since the Dallas meeting (Jan. 2000) and I have no liaison
> > > to T1.
> > >
> > > Before discussing in detail, I think we had better be aware once
> > > again that here is a LAN community, and keep in our mind that we
> > > should be much careful to use WAN terminology. I use the
> > > following definitions in this mail; please let me know if there
> > > is any inconvenience to you.
> > > --------------- --------------- ------------ ----------- ------
> > > expression Overhead access CLK Accuracy CLK Jitter Std.
> > > --------------- --------------- ------------ ----------- ------
> > > SONET (almost) full < +/-20ppm SONET spec. T1.105
> > > SONET-compliant reduced < +/-20ppm SONET spec. T1.416
> > > SONET-lite much reduced < +/-100ppm ?????????? ??????
> > > --------------- --------------- ------------ ----------- ------
> > > Here I assume that SONET-lite equals WAN-PHY with SONET framer
> > > proposed in 802.3ae.
> > >
> > > I think we can agree on the following two facts;
> > >
> > > (1) There is no SONET-lite standard at present. All SONET or
> > > SONET-compliant equipment at present, including the emerging
> > > non-muxing LTE, should meet +/-20ppm CLK accuracy and SONET
> > > jitter spec.
> > >
> > > (2) Pointer manipulation mechanism in SONET framer itself has
> > > the potential to accommodate the CLK difference up to +/-320ppm.
> > >
> > > According to Roy, there are some discussions on relaxing the SONET
> > > CLK accuracy for some specific applications in T1 or ITU-T. That's
> > > news to me; please let me know where I can get the more information
> > > about the discussion.
> > >
> > > I have no authority to decide how NTT reacts in ITU-T, but I will
> > > strongly recommend my colleagues who often attend the ITU-T expert
> > > meeting not to approve such standard proposals. The reasons are;
> > >
> > > (1) I know we have at least one SDH system that raises an alarm for
> > > too many pointer re-writing to indicate wrong CLK accuracy.
> > >
> > > (2) It can not be connected to SONET regenerators. This implies
> > > that it is not a SYNCHROUNOUS system any more. I see no reason
> > > to define 'plezioisosynchronous' system with SONET framer which
> > > is optimized for SYNCHRONOUS systems. Note that we have a
> > > serious trade-off between CLK accuracy and jitter transfer in a
> > > SONET regenerator (you can read it in SYNCHRONUS transport
systems).
> > > I think this is what Erik has pointed out in his recent comment.
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02157.html
> > >
> > > (3) I'm afraid that it would nominate the client path; only OC-192c
> > > or some small variations could be carried through non-muxing LTE.
> > > We will lose flexibility to accommodate any combination of OC-1,3,
> > > 12,48,192. Or we require very heavy Line terminating circuit to
> > > re-write up to 192 pointers independently.
> > >
> > > Above consideration tells me that, if we use the SONET framing,
> > > we had better keep +/- 20ppm accuracy to be compliant to SONET.
> > > Then it can be connected directly to existing SONET regenerators and
> > > WDM active transponders. We don't need to pay the SONET-framing
> > > charge twice for WAN-PHY and ELTE. And again, I don't believe
> > > SONET regenerator for 10GbE is a good choice unless you have already
> > > invested in it.
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg01869.html
> > >
> > > Best Regards,
> > > Osamu
> > >
> > > At 14:39 00/04/07 -0500, Roy Bynum wrote:
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02169.html
> > > >
> > > > Osamu,
> > > >
> > > > "SONET Lite" is a term that has been used for some time to mean a
> > reduced
> > > > overhead requirement customer drop interface. T1.416-99 defines the
> > > > required and optional byte usage for "SONET Lite". The
> > plezioisosynchronous
> > > > timing standard is currently being worked on. It should be a full
> > standard
> > > > definition very soon. In this regard, the "ELTE" is acutely a
special
> > case
> > > > non-muxing LTE that is part of the T1X1 standards. The SONET test
sets
> > that
> > > > are used for POS today already have to be adjusted to allow for
wider
> > clock
> > > > and jitter tolerance.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > ----- Original Message -----
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02164.html
> > >
> > > At 15:42 00/04/07 -0400, David W. Martin wrote:
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02170.html
> > > >
> > > > Osamu,
> > > >
> > > > Our WAN PHY proposal uses the traditional +/-100ppm clock tolerance
spec
> > > > of Ethernet. An ELTE would have a matching WAN PHY interface. The
SONET
> > > > side of the ELTE will have an ITU/ANSI interface. Within the ELTE
the
> > clock
> > > > domain adaptation is performed using traditional SONET pointer
> > processing.
> > > > Previous material has shown this is feasible. Please refer to
> > > >
> > > >
> >
http://grouper.ieee.org/groups/802/3/10G_study/public/july99/bottorff_1_0799
> > .pdf
> > > >
> > > > for more background. Thank-you.
> > > >
> > > > ...Dave
>
> -------------------------------------------------------
> Richard Taborek Sr. Phone: 408-845-6102
> Chief Technology Officer Cell: 408-832-3957
> nSerial Corporation Fax: 408-845-6114
> 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> Santa Clara, CA 95054 http://www.nSerial.com