| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.