Yaakov Stein | 9 Mar 16:56 2009

IETF-74 slots

Hi all,

 

The mailing list has been very quiet recently,

but I know that our face-to-face meeting will kick things off again.

 

We will be meeting on Monday afternoon,

the day being chosen in order to accommodate those who are

will be attending the ITU interim meeting.

 

Please send requests for slots ASAP,

as we need to send an initial agenda by Wednesday.

 

Y(J)S

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Silvana.Rodrigues | 12 Mar 15:52 2009

TICTOC agenda


Yaakov and Stewart,

I looked at the TICTOC agenda and it reads:

Progress on the requirements draft (Silvana) 15 min
http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01

I have uploaded rev. 2 of the requirements document, so the agenda is pointing to the wrong document.Rev. 2 can be downloaded from:


http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02

Best Regards,

Silvana



_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 12 Mar 15:56 2009

Re: TICTOC agenda

Silvana

 

Copy and paste error.  I fixed it (and similarly the modules draft is 03 !)

 

Y(J)S

 

From: Silvana.Rodrigues <at> Zarlink.Com [mailto:Silvana.Rodrigues <at> Zarlink.Com]
Sent: Thursday, March 12, 2009 16:53
To: Yaakov Stein; stbryant <at> cisco.com
Cc: tictoc <at> ietf.org
Subject: TICTOC agenda

 


Yaakov and Stewart,

I looked at the TICTOC agenda and it reads:

Progress on the requirements draft (Silvana) 15 min
http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01

I have uploaded rev. 2 of the requirements document, so the agenda is pointing to the wrong document.Rev. 2 can be downloaded from:


http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02

Best Regards,

Silvana



 

----------

This email is confidential and may contain information that is privileged and

exempt from disclosure by law.  If you have received it in error, please contact

the sender immediately by return email and then delete it from your system; you

should not copy it or disclose its contents to anyone.  Emails are not secure

and cannot be guaranteed to be error free as they can be intercepted, amended,

lost or destroyed, or contain viruses.  Anyone who communicates with us by email

is taken to accept these risks.

 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Ronen Solomon | 24 Mar 03:32 2009

bi-directional SyncE - Copper GBE

Yaakov

 

In the last meeting you raised the issue of supporting bi-directional SyncE on Copper GBE. Can you please re-emphasis the problem and the proposed solution.

 

Best regards

 

Ronen

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
STUART VENTERS | 24 Mar 15:50 2009

Yesterday's audio

I never was able to get yesterday's audio to work.

Is there a URL for an archive of the audio for yesterday's meeting?

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Picon

recurring timeslot for teleconferences

Folks,

During yesterday's discussion we decided to try again to have
recurring teleconferences to help establish momentum for the
efforts. The suggested time is the first and third Thursday's
of the month, 1100 Eastern Daylight Time, for one hour maximum.

Karen 

> -----Original Message-----
> From: tictoc-bounces <at> ietf.org 
> [mailto:tictoc-bounces <at> ietf.org] On Behalf Of STUART VENTERS
> Sent: Tuesday, March 24, 2009 10:51
> To: tictoc <at> ietf.org
> Subject: [TICTOC] Yesterday's audio
> 
> I never was able to get yesterday's audio to work.
> 
> Is there a URL for an archive of the audio for yesterday's meeting?
> 
> 
Attachment (smime.p7s): application/x-pkcs7-signature, 6728 bytes
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 24 Mar 18:33 2009

Re: bi-directional SyncE - Copper GBE

Ronen,

 

The problem is that in 1000BaseT you need to use the same clock in both directions

(earlier copper physical interfaces used a different clock in each directions,

but with Gb that would lead to cross talk degrading the performance).

 

802.3-2005 states that when you use autonegotiation, the master is chosen randomly.

In fact, a random or pseudorandom number is generated for this purpose.

 

This would seem to prohibit the use of Gb copper for SyncE,

as the direction of the clock flow has a 50% chance of ending up wrong

(i.e. "upstream").

 

However, apparently the 802.3 people in their wisdom foresaw this problem.

They defined a control register bit (9.12) which forces a device to be master.

If both sides set this bit the autonegotiation fails, so if the link comes up

you can be sure the right side is master.

 

Y(J)S

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Ronen Solomon
Sent: Tuesday, March 24, 2009 04:33
To: tictoc <at> ietf.org
Cc: Rafi Ram
Subject: [TICTOC] bi-directional SyncE - Copper GBE

 

Yaakov

 

In the last meeting you raised the issue of supporting bi-directional SyncE on Copper GBE. Can you please re-emphasis the problem and the proposed solution.

 

Best regards

 

Ronen

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 24 Mar 18:48 2009

Re: Yesterday's audio

The sessions are supposed to be archived here - ftp://videolab.uoregon.edu/pub/videolab/media/ietf74/

but there is nothing there yet.

 

Y(J)S

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of STUART VENTERS
Sent: Tuesday, March 24, 2009 16:51
To: tictoc <at> ietf.org
Subject: [TICTOC] Yesterday's audio

 

I never was able to get yesterday's audio to work.

Is there a URL for an archive of the audio for yesterday's meeting?

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
STUART VENTERS | 24 Mar 20:11 2009

Re: bi-directional SyncE - Copper GBE

Ronen,

It looks like the words that ended up in 8264 to deal with this might require some reading between the lines
  to understand that you need to force the negotiation to setup the desired clock path.

For interoperability, it would have been nice if the words said to force it at the master, or slave , or both.

I think Yaakov just said to force it at the master?

Alternatively, you could make it provisionable if your hardware knows how to do it either way.


Here are the words in G.8264 related to this.

Rec. ITU-T G.8264/Y.1364 (10/2008) – Prepublished version

10.1 Synchronous Ethernet: General
Note: there may be sync Ethernet interfaces with reduced functionality in the sense that they might
provide sync Ethernet functionality in a single direction only (transmit or receive). Details are for
further study.

10.2 Operation modes
Synchronous operation mode

In the particular case of Ethernet interfaces for 1G copper as specified in IEEE 802.3, these
interfaces perform link auto negotiation to determine the master and slave clocks for the link. In the
case where these interfaces are used for Synchronous Ethernet, the resulting timing path must be
considered if frequency distribution based on Synchronous Ethernet is used. The clock master must
be consistent with the network synchronization plan.

Regards,

Stuart Venters
Adtran

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 25 Mar 00:48 2009

mutual synchornoization

I checked Bregni's "A Historical Perspective on Telecommunications Network Synchronization"

(IEEE Communications Magazine Volume 36, Issue 6, Jun 1998 Page(s):158 - 166)

He says

Mutual Synchronization (Democracy)

Mutual synchronization is based on direct mutual control among the clocks so that the output frequency of each

is the result of the "suggestions" of the others. Such a pure democracy seems appealing – there are no masters and no slaves

but mutual cooperation. However, the behavior of the mutually controlled elements is hard to govern.

Modeling the behavior of such networks, or even ensuring the stability of the control algorithms, can be a very complex task.

Networks thus designed tend to be quite expensive, but extremely reliable. Therefore, until now, the field of application

of mutual synchronization has been mostly limited to special cases (e.g., military networks).

 

A quick google turned up the following :

 

From these clock frequencies, the synchronization of the nodes of the network may be performed by two different basic methods: mutual synchronization and master-slave synchronization. In mutual synchronization, each node generates its own clock frequency from the average of the frequencies of incoming signals and its own clock frequency at the moment. Thus all nodes of the network are driven towards a common average frequency and in a stable state they have achieved it. However, a network using mutual synchronization cannot be synchronized with a desired source, which makes an interconnection of different networks problematic, because the operating frequency of the whole network cannot then be predetermined accurately. In master-slave synchronization instead, all nodes of the network are synchronized with the clock frequency of one master node. Each node selects the frequency of one incoming signal as the source of its own clock frequency. The node tries to select a signal having the clock frequency of the master node of the network.

 

If this is what is meant by mutual synchronization, then this technique is completely different from

the classlessness I described, and additionally suffers from 2 major flaws.

 

First, it does not clock off a grand master, rather it causes a group to converge to a common, but arbitrary frequency.

I take that back, they converge to the average frequency.

I take that back, they don't necessarily converge, all that need happen is that the variance will decrease.

 

Second, each clock averages the clock frequencies it sees with its own.

I assume that this is in reality a weighted average, i.e.  f' = a f + (1-a) /N SUM f_n

so that it is actually a single pole IIR filter over time rather than an average; but I digress.

Note that the clocks do NOT remove their influence on the other clocks before taking the average,

so each clock averages in its own frequency, and without renormalization this scheme can become unstable.

I do not need experimental results to see this – it is a necessary result of the system.

In fact, for such a system I can concoct special situations where the frequency drift will diverge.

 

Thus, the prior art of "mutual synchronization" does not seem to be very relevant to the discussion.

But thanks to those who brought it up – it is always interesting to learn about things that have been

tried in the past.

 

Y(J)S

 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

Gmane