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