Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Audioports for....Consolidation for EFM Network Clock/T iming Solution

Title: RE: [EFM] Audioports for....Consolidation for EFM Network Clock/Timing Solution
To all, as I may not be able to get on the conference call from the UK .....
 
There are two ways to get precision timing from one place (node) to another, either synchronise the bearer (as in E1/T1 when used for PSTN / ISDN and SONET / SDH), or carry the clock in the payload in some form, and recover a clock from that signal.
 
In the bearer:
 
Synchronising the 1GE bearer clock for 1GE EFM would be possible. There is nothing in the 1GE spec. that say it can't be + / - 0ppm, the spec. only defines the tolerance limits, it does not put limits on the precision. One could take a reference from a GPS or BITS clock, and use this to keep a PLL at 1GE. It doesn't have to be precisely on 1G, so long as the standard defines a rate within the 100ppm of 'legacy' 1GE. At the far end the reference clock frequency is reproduced from the bearer (with vendor specific degrees of jitter attenuation).
 
In the payload, using circuit emulation:
 
If you don't lose packets this is really simple. Even if you add sequence numbers to check packet loss it's not that hard. From ingress to egress p2p or p2mp is a controlled environment so packet loss and variable latency should be non-issues, particularly in p2p. The timing is carried in the circuit. It's just a question of good clock recovery technique, and jitter attenuation.
 
In the payload (or side band), using a specific payload data
 
Very similar to above just fewer bits. At the end of the day the system is counting clock ticks in the channel to keep a pll on frequency.
 
The specific of 8Khz
 
This is really simple if using the circuit emulation payload method, as it is carried by the framing of the circuit (if the circuit needs it).
 
It would be tough with the bearer method.
 
It would be possible with the dedicated (side band) method, but I haven't thought through the precise mechanism. I would assume that other interested parties have already done the thought experiment on this. It is not an area of immediate relevance to my product plans.
 
Best regards
 
Bob
 
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Glenn Algie
Sent: 08 October 2001 08:03
To: 'Matthew.Beanland@fujitsu.com.au'; 'rabynum@mindspring.com'; 'oksman@broadcom.com'; 'chris.hansen@intel.com'; 'Glen P. Koziuk'; 'bob.barrett@fourthtrack.com'; 'mattsquire@acm.org'; 'onn.haran@passave.com'; 'prayson.pate@overturenetworks.com'; 'Denton Gentry'
Cc: 'stds-802-3-efm'; Scott Faubert; Richard Brand; Glenn Parsons
Subject: RE: [EFM] Audioports for....Consolidation for EFM Network Clock/T iming Solution

As offered, to help explore the possibility of an aligned EFM Network Clock/Timing solution I have arranged an audio bridge as follows.

I was only able to secure a 1-800+7digit toll free bridge for North American callers. For Non North American callers (2 expected) they will have to dial non toll free  to the local number in Ottawa Canada below.

Tuesday Oct 9, 12-1 Eastern
North American Toll free: 1-800-559-9440
Non toll free: 613-763-6338
passcode: 561518#
number of ports: 16

at passcode prompt you can let the call timeout to an operator to try to get added if 16 ports are consumed. 

Those who responded with interest to discuss this are in the to list of the email.
 
The most talked about need was the user side E1/T1/T3... clock sensitive encapsulation needs at an EFM outstation.
 
If other than this use case, such as myself, then would be nice if you can prepare a 3 minute verbal overview of what kind of EFM clock/timing  provision you had in mind and at what layer could it be solved at. Some use case items to mention; is it an application vs link vs nodal vs network level need? Intra vs Inter? HW vs SW?  clock/frequency stability vs syncronization between x points? Parts per million or 10**-n sensitivity? Jitter sensitivity? ie intranodal stable clock need vs internodal synchronized clock need? Any level of simulation or prototyping of the PHY vs MAC vs other layer solution done that you can discuss?

Cheers,
   Glenn Algie, Nortel Networks   613 765 3425






-----Original Message-----
From: Algie, Glenn [WDLN2:AN10:EXCH]
Sent: Monday, October 01, 2001 3:07 PM
To: stds-802-3-efm
Subject: RE: [EFM] Consolidation for EFM Network Clock/Timing Solution


Sounds like there is a number of use cases in our differing EFM end devices  for what appears to be a potential EFM standard for an inter-operable quality clock/timing solution.

Who is interested in having a  birds of a feather session on this network timing/clock problem mapped onto a EFM solution set to see if we can consolidate to a common proposal?

I also have a use case in a Nortel platform connecting into EFM that needs clock stability and I too would like to see a Layer 2 EFM MAC message to solve this interworking problem.

Please reply to this email on availability and if interested in  1 hour timeslot you may have over the next 5-10 days, I can set up a 1 800 audio meet for North  American players maybe more globally if needed. Proposed date for this would be Friday October 5 3-4pm eastern OR Tuesday 12-1pm eastern.

You can reply directly to me and I'll email the agreed time and dial in number on the public IEEE EFM reflector.

Let's see if over the next 60 days  we can achieve quorum on a consolidated EFM clock solution view backed by a good mix of EFM chip and  device suppliers and those operators who would deploy it.

Which 802.3 work group  we take it to is not clear to me and this needs discussion as well. Is 802.ah the right home? I have seen  clock items being discussed on 802.3af reflector as well which is not the right place.

With research I have done to date on my L2 Ethernet clock needs and known similar solutions already rolling into shared Enterprise Campus LAN environments, I personally feel a consolidated request into 802.3 EFM is doable quite quickly here if it were to come from a united front. I prefer to keep clock on the EFM hop layer 2 hardware switched than risk it to more exposed upper layer software interventions.

I don't think we need to standardize or debate the detailed methods that can be used to generate or receive this potential MAC layer message as some of that is our individual secret sauces  and also differs based on use case, but instead just focus on a agreeable ethernet message format that can carry perhaps a reserved ethernet multicast containing a time stamped heartbeat that commonly satisfies our individual use cases.

We are absolutely NOT trying to change ethernet into a synchronous media but instead trying to connect our clock sensitive devices already getting timing through current legacy last mile solutions onto an EFM access solution. I am not convinced that these device clock needs ever do go away.

I would like to have a converged view presented back into IEEE EFM in November time frame or at least before year end 2001.

For those with clock interest on EFM please reply with your preferred timeslot for an audio call. If someone has already started this alignment please let me know.

Cheers,
   Glenn Algie
   Senior Advisor, Nortel Networks. 613 765 3425.