Re: 20 ppm clock tolerance for WIS
At 06:56 PM 5/30/00 , Praveen Kumar wrote:
> For the benefit of those who could not make it to your presentation in
>Ottawa, could you clarify some of the issues that you raise.
>You mention that the "cost difference between +/-20ppm and +/-100ppm
>oscillators is a tiny fraction of the total cost of a 10GigE interface".
>Could you perhaps substantiate this statement with quantitative input (some
>real numbers). My understanding is that the +-100ppm tolerance was
>specified only to keep the cost down (as the cost differential between a
>20ppm solution and 100ppm solution is perceived to be significant).
I am still waiting for feedback from some oscillator companies on an exact cost differential between a 20ppm and a 100ppm oscillator. I will get back to you on this.
The other point I was trying to make is that all the existing sonet reference oscillators that you can buy off the shelf are specified at 20ppm. You can get these oscillators from multiple suppliers today. If we specified 100ppm it would have to be a custom part, which would only be used for the 10GE WAN PHY. Suppliers would then have to stock both 20ppm and 100ppm versions of the same oscillator. I can't see this leading to lower costs. It also has the potential to cause a lot of confusion with for example a 100ppm 10GE oscillator inadvertently ending up in a standard sonet interface, or vice-versa.
In terms of cost reduction the main benefit comes from eliminating approx 95% of the synchronization functionality that is required on a sonet Add Drop Multiplexor, and not from relaxing the tolerance on an oscillator from 20ppm to 100ppm. Examples of synchronization functions which are required in a sonet TDM box but which would not be required in an Ethernet switch include (note this is identical to packet-over-sonet (POS) interfaces on routers which also only require simple, low cost synchronization based on 20ppm clocking):
- ability to lock all interfaces on the box to a central clock
- backup central clock
-ability to meet very stringent phase transient requirements when switching between the working and standby central clock
- ability to lock the central clock to a reference from any one of the user interfaces
- ability to lock the central clock to a BITS reference
- backup BITS reference
- ability to meet stringent phase transient requirements when switching between BITS references.
- ability to source BITS
- monitor and alarm all timing references
- Stratum 3 oscillator
- meet stringent 24 hour holdover requirements on reference failures
- ability to meet stringent phase transient requirements going into and out of holdover
- implement synchronization status messaging protocol to control reference switching
As a further data point there are 42 pages in GR-253 which define all the synchronization requirements for a SONET ADM. Only about 1/2 page of these are applicable to a POS interface on a router. I would expect it to be the same for the WAN PHY. This is where the cost savings come from !
>You recommend using "LAN PHY jitter specs". This makes the WIS
>incompatible with installed base SONET . This doesn't seem to meet your
>goal of being compatible with installed OC-192 SONET
>infrastructure. Please clarify.
A good point. This probably does require some clarification. I guess using the word 'recommend' might have been too strong because this is an area which I believe still requires some further discussion. Personally I would agree with you in that the only way to ensure compatibility with the installed SONET based transport infrastructure would be to use SONET jitter specs. This is the same conclusion we came to about 12-18 months ago in the OIF when we went down a similar path of investigating relaxed jitter specs for Packet-Over-SONET (POS) interfaces in order to lower cost. At the time this was strongly opposed by both network operators and equipments suppliers. If I remember correctly companies like British Telecom, AT&T, Marconni, Lucent and Nortel were the most vocal in opposing any changes to the jitter specifications.
However there are some other points we need to consider here. Unlike the issues of clock tolerance and overhead there probably is a significant cost associated with meeting SONET jitter specs (or so I have been told by a number of transceiver vendors). I also believe there is a strong desire within the group to use the same PMDs (optics) for both the LAN and WAN phys, so therefore burdening the PMD with meeting SONET jitter specs might add a lot of unnecessary cost and complexity to the LAN application.
Bottom line is that you bring up a good point to which I don't have a good answer. I guess I will just open it up to the rest of the group for discussion.