Subject: [ippm] Synchonization state: consistency among owdp and ippm mib

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Wed, 31 Jul 2002 11:13:54 +0200

Hi Stanislav, all

Regarding the clock with "no notion of external synchronization for the
time source (e.g., a cesium oscillator is used directly)" what may be
the corresponding state ? 

are there other states to discuss now(e.g. such as 'fail') ?

ippmSynchonizationState OBJECT-TYPE
	SYNTAX INTEGER  {
		other(0),
		unsynchronized(1),
		initializing(2),
		synchronized(4)
	}
	MAX-ACCESS read-only
	STATUS     current
	DESCRIPTION
" ippmSynchonizationState describes the state of the clock
synchronization.

Other(0)
The status of the synchronization is unknown.

unsynchronized(1)
The system is not synchronized. 

initializing(2) 
The system is receiving synchronization information but is not yet
synchronized. 

synchronized(4) 
The system is synchronized. 
"

regards
Emile

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 31 Jul 2002 14:51:21 +0200 (CEST)

Emile, others,

> the corresponding state ?

I'd think that the condition for synchronized is that the clocks on both
sending and receiving end are synchronized to one and the same source, and
it is thus impossible for one to drift away from the other.

So, a cesium clock connected to a PC but not to anything else, is
unsynchronized, a cesium clock connected to a PC and to (say) a clock at a
standards institute, is synchronized.

> are there other states to discuss now(e.g. such as 'fail') ?

Isn't this implementation dependent?  For the MIB/OWDP, we need 3 states:

  * Unsynchronized
  * Synchronized
  * Other

Other covering any state not being synchronized or unsynchronized, leaving
it up to the implementor to decide what to do next.

I don't think that there is a need for a "initializing" state, it is too
generic and the behaviour of the clock during initialization varies from
one hardware vendor to the other.  Or to be more precise, for our
equipment, we use GPS clocks from 2 different vendors and they behave
completely different from the moment they are switched on until they
have synchronized themselves.  The same happens when something goes wrong
(for example, the cable antenna is cut).

Henk

> The system is synchronized.

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)

NOTE: My email address (and a hole in our mailing list software) is being
      abused by a spammer.  We are working on fixing this hole and tracking
      the spammer down.  If you receive mail from "[email-masked]" that is
      obviously spam, please send me a copy of the mail including ALL headers.
      I'm sorry for any inconvenience caused by this.

---

From: stanislav shalunov <[email-masked]>
Date: 31 Jul 2002 11:42:21 -0400

> the corresponding state ? 

Currently, draft-ietf-ippm-owdp-04.txt recommends to set the
`synchronized' bit for sources of time that do not have a notion of
synchronization -- so it would be the `synchronized(4)' state in your
case.

(Maybe draft-ietf-ippm-owdp-04.txt needs to be changed in this respect.)

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at sea level.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 31 Jul 2002 11:45:34 -0400

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> writes:

> I'd think that the condition for synchronized is that the clocks on
> both sending and receiving end are synchronized to one and the same
> source, and it is thus impossible for one to drift away from the
> other.

How can a sender possibly know where the receiver gets its time?

> unsynchronized, a cesium clock connected to a PC and to (say) a
> clock at a standards institute, is synchronized.

Cesium oscillators, being the current definition of time, can only
drift with respect to each other due to relativistic effects, right?

Al your Qaeda are belong to US.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 31 Jul 2002 20:52:24 +0200 (CEST)

> How can a sender possibly know where the receiver gets its time?

Without a separate communication channel, it can't.

However, to implement this, I'd put a flag in the packet when it is sent
indicating the status of the clock at the sender.  The packet is then
received by the receiver, the receiver looks at its clock and tags the
packet accordingly: both clock synchronized so a valid (delay)
measurement, one or two clocks unsynchronized and a non-valid (delay)
measurement.

> drift with respect to each other due to relativistic effects, right?

I've no idea what would happen if I switched off my cesium clock and
switched it on later.  (And yes, that is a silly thing to do).

The flag just says "I'm synchronized".  Now, a cesium clock needs perhaps
one calibration cycle in its life and a cheap GPS receiver a constant
signal but that is up to the implementation.

Henk

---

From: "Robert Holley" <[email-masked]>
Date: Wed, 31 Jul 2002 15:12:33 -0400

The sender can know where the reciever gets it time source. The information
is maintained in the NTP MIB. This may be accessed by the "separate
communication channel" reference in the thread below.

FYI, here is a link to a whitepaper on NTP deployment and configurations.

http://cisco.com/warp/public/126/ntpm.html

regards
Bob Holley

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Henk Uijterwaal (RIPE-NCC)
> Sent: Wednesday, July 31, 2002 2:52 PM
> To: stanislav shalunov
> Cc: [email-masked]
> Subject: Re: [ippm] Synchonization state: consistency among owdp and
> ippm mib
>
>

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 31 Jul 2002 21:20:49 +0200 (CEST)

> communication channel" reference in the thread below.

If you are running NTP, yes, and you don't even need a MIB for it.
However, not all implementations use NTP.

Henk