Subject: Re: Washington Issue 7 - Time Local or UTC

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 15:29:39 -0500

It is not clear to me that it is important that the
MG and MGCs notion of time be synchronized.  I think it
is only important that the MGC understand what happened
at the MG (order and delay).

If it does matter, then the MG and MGCs should run NTP.

Brian

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 3:19 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Washington Issue 7 - Time Local or UTC
>
>
> This questions brings me to the following.
> How do we synchronize clocks ?
> Since time is distributed in the MGC/MG architecture,
> I propose adding time parameter to servicechange to
> allow both the MGC and MG compute the relative time
> of events. This should be handled with care to overcome the
> problems of packet retransmissions and delayed arrival.
>
> Are there better approaches that address such a problem ?
>
> Abdallah Rayhan
>
> Brian Rosen wrote:
>
> > A number of issues were raised in the Washington meeting that
> > were "send to the list". This is one of these issues, with the
> > problem and my suggested fix.
> >
> > Problem
> >
> > Timestamps don't specify the zone.  Could be local or UTC
> >
> > Proposed Solution
> > All times should be reported in UTC
> >
> > Brian
>

---

From: Nancy-M Greene <[email-masked]>
Date: Mon, 15 Nov 1999 14:26:35 -0500

The time should be UTC time. Below is an excerpt from X.680, defining what
that is.

42      Universal time
42.1    This type shall be referenced by the name:
        UTCTime
42.2    The type consists of values representing:
                a)      calendar date; and
                b)      time to a precision of one minute or one second; and
                c)      (optionally) a local time differential from
coordinated universal time.
42.3    The type is defined, using ASN.1, as follows:
        UTCTime ::= [UNIVERSAL 23] IMPLICIT VisibleString
with the values of the "VisibleString" restricted to strings of characters
which are the juxtaposition of:
                a)      the six digits YYMMDD where YY is the two low-order
digits of the Christian year, MM is the month (counting January as 01), and
DD is the day of the month (01 to 31); and
                b)      either:
                        1)      the four digits hhmm where hh is hour (00 to
23) and mm is minutes (00 to 59); or
                        2)      the six digits hhmmss where hh and mm are as
in 1) above, and ss is seconds (00 to 59); and
                c)      either:
                        1)      the character Z; or
                        2)      one of the characters + or -, followed by
hhmm, where hh is hour and mm is minutes.
The alternatives in b) above allow varying precisions in the specification
of the time.
In alternative c) 1), the time is coordinated universal time. In alternative
c) 2), the time (t1) specified by a) and b) above is the local time; the
time differential (t2) specified by c) 2) above enables the coordinated
universal time to be determined as follows:
        Coordinated universal time is t1 - t2
EXAMPLE 1 - If local time is 7am on 2 January 1982 and coordinated universal
time is 12 noon on 2 January 1982, the value of UTCTime is either of:
                -       "8201021200Z"; or
                -       "8201020700-0500".
EXAMPLE 2 - If local time is 7am on 2 January 2001 and coordinated universal
time is 12 noon on 2 January 2001, the value of UTCTime is either of:
                -       "0101021200Z"; or
                -       "0101020700-0500".
42.4    The tag shall be as defined in 42.3.
42.5    The value notation shall be the value notation for the
"VisibleString" defined in 42.3.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         Monday, November 15, 1999 2:06 PM
> To:   [email-masked]
> Subject:      Washington Issue 7 - Time Local or UTC
>

---

From: "Drage, Keith" <[email-masked]>
Date: Tue, 16 Nov 1999 10:16:55 +0000

DSS1 should NOT be used as the answer to any time/date specification
problems. All it effectively says is that the time is however the network
wants to specify it, providing it can represent it in the coding structure.

In 1986 or 1987, when this was specified, it was seen as completely
adequate, as the DSS1 Time/date information was purely local to an access,
and an access had a physical limit of perhaps 5 km, and even with
regenerators, it practically could not cross time zones. Also, there was
only one local service provider in any particular area (I believe even in
the US) and there was therefore no problem with multiple operators connected
to a PBX wanting to supply different time information. At that time the DSS1
view was probably correct; now it would not be. However, as most networks
tend not to use it, and most TEs except Gp 4 fax machines tend to ignore it
....

It also specifies a 1 octet (256 values) year, and an implementors guide has
just had to be issued clarifying how that year could be understood.

In addition, the coding structure adopted would not be preferred in DSS1
under the current coding rules adopted about 1992.

Keith Drage

> ---------------------------------------------------------------
> Keith Drage ([email-masked])
> Siemens Communications Limited,
> Technology Drive, Beeston, Nottingham NG9 1LA, UK
> Tel: +44 115 943 4991   Fax: +44 115 943 4992
> ---------------------------------------------------------------
> Internet communications are not secure and therefore Siemens
> Communications Limited does not accept legal responsibility for the
> contents of this message. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of Siemens
> Communications Limited unless otherwise specifically stated.
>

-----Original Message-----
From: Matt Holdrege [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 6:19 AM
To: [email-masked]
Subject: Re: Washington Issue 7 - Time Local or UTC

I seem to recall that Q.931 allows either local or UTC depending on network
requirements. Seeing as Q.931 is the closest existing analogy to MEGACO
it's probably a good reference in this case. But I would really like to
hear from the Operators on this one. Theoretically, it shouldn't matter
what time spec MEGACO uses as long as it can map to your billing system
which will use local time. Right?

At 02:26 PM 11/15/99 -0500, Nancy-M Greene wrote:

>a)      calendar date; and  b)      time to a precision of one minute or
>one second; and  c)      (optionally) a local time differential from
>a)      the six digits YYMMDD where YY is the two low-order digits of the
>Christian year, MM is the month (counting January as 01), and DD is the
>day of the month (01 to 31); and b)      either:
>1)      the four digits hhmm where hh is hour (00 to 23) and mm is minutes
>(00 to 59); or  2)      the six digits hhmmss where hh and mm are as in 1)
>above, and ss is seconds (00 to 59); and
>c)      either:
>1)      the character Z; or  2)      one of the characters + or -,
>followed by hhmm, where hh is hour and mm is minutes.
>
>In alternative c) 1), the time is coordinated universal time. In
>alternative c) 2), the time (t1) specified by a) and b) above is the local
>time; the time differential (t2) specified by c) 2) above enables the
>coordinated universal time to be determined as follows:
>
>EXAMPLE 1 - If local time is 7am on 2 January 1982 and coordinated
>universal time is 12 noon on 2 January 1982, the value of UTCTime is either
of:
>-       "8201021200Z"; or  -       "8201020700-0500".
>
>EXAMPLE 2 - If local time is 7am on 2 January 2001 and coordinated
>universal time is 12 noon on 2 January 2001, the value of UTCTime is either
of:
>-       "0101021200Z"; or  -       "0101020700-0500".
>
>----------  From:   Brian Rosen[SMTP:[email-masked]]  Sent:   Monday,
>November 15, 1999 2:06
>PM  To:     [email-masked]  Subject:
>Washington Issue 7 - Time Local or UTC
>
>A number of issues were raised in the Washington meeting that  were "send
>to the list". This is one of these issues, with the  problem and my
>suggested fix.
>
>Problem
>
>Proposed Solution  All times should be reported in UTC
>
>Brian

---

From: Scott W Brim <[email-masked]>
Date: Tue, 16 Nov 1999 12:08:12 -0500

>Date: Mon, 15 Nov 1999 14:26:35 -0500
>From: Nancy-M Greene <[email-masked]>
>The time should be UTC time. Below is an excerpt from X.680, defining
>what that is.

...

>a)      the six digits YYMMDD where YY is the two low-order digits of
>the Christian year

Someone made a suggestion here that if you use ISO 8601 format you avoid
the y2k ambiguities.

...Scott

---

From: Nancy-M Greene <[email-masked]>
Date: Tue, 16 Nov 1999 21:29:20 -0600

Scott, and Al,
Thanks for bringing us back to reality. I made a mistake. We are already
using ISO8601, and as Scott says, it is Y2K compliant! The following is from
the ABNF.

TimeNotation = Date "T" Time; per ISO 8601:1988
; Date = yyyymmdd
Date = 8(DIGIT)
; Time = hhmmssss
Time = 8(DIGIT)
statisticsDescriptor = StatsToken LBRKT statisticsParameter *(COMMA
statisticsParameter ) RBRKT

Let's go back to what Time is being used for:

1) a timestamp for events in the ObservedEvents descriptor
2) a timestamp in TransactionPending
3) in packages, time will be one of the stats that will be returned for TDM
terminations - start time and stop time.
--------------------
Al Varney writes (Nov 16/99):
 It seems to me the use of time-stamps in MEGACO is primarily (and
perhaps ONLY) for determining durations between events and/or the sending
of messages.  Thus the actual Date/Time reference point doesn't matter.
Certainly there is no need to synchronize the MG time with MGC time or
other MG times.  What DOES matter is the ability to measure duration in
fractions-of-seconds.

<snip>

   SUMMARY:  For text-based MEGACO, pick either X.680 (YYMMDDHHMMSS) or the
ISO 8601 form (UTC implied) but ADD 2 fractional seconds to the
representation.
If folks would like the "T" delimiter (so time-stamps stand out visually),
fine.  Don't place any requirements on synchronization of time-stamps
between
MGs or between MG and MGCs.

   In binary versions of the protocol, a timestamp in NTP (middle 32 bits)
format is probably useful (and RTP-based MGs will need it anyway for
reports).

end of excerpt from Al Varney
---------------
I agree with Al, that we just need timestamps for 1) and 2) above.

In statistics, you still only need the timestamp. So ISO8601 seems to be
good enough. I assume this means we forget about time zones. Or are time
zones important for statistics - if so maybe having them at the MGC is
sufficient.

Nancy

> ----------
> From:         Scott W Brim[SMTP:[email-masked]]
> Sent:         Tuesday, November 16, 1999 12:08 PM

---

From: Nancy-M Greene <[email-masked]>
Date: Wed, 17 Nov 1999 22:29:57 -0600

We added two extra ss digits for precision in the seconds field.

Nancy

> ----------
> From:         Shalini Philip[SMTP:[email-masked]]
> Sent:         Wednesday, November 17, 1999 10:34 PM
> Hello All, 
>     There is something I would like to point out on the definition of
> TimeNotation in the ABNF. 
> It is not clear that why 8 digits are being used for "Time" field. 
> The information of hours, minutes and seconds can come in 6 digits
> (hhmmss) if we always assume UTC, 
> Or in 7 digits (hhmmssz) to explicitly specify UTC. 
> 
> Thanks & Regards, 
>     Shalini. 
> 
> Brian Rosen wrote: 
> 
>        Can we declare this issue decided:     Time is UTC     If you need
> synchronized time, use NTPBrian 
> 
>               From: Nancy-M Greene [ mailto:[email-masked]] 
>               Sent: Tuesday, November 16, 1999 10:29 PM 
>               To: [email-masked] 
>               Thanks for bringing us back to reality. I made a mistake. We
> are already using ISO8601, and as Scott says, it is Y2K compliant! The
> following is from the ABNF. 
> 
>               statisticsDescriptor = StatsToken LBRKT statisticsParameter
> *(COMMA statisticsParameter ) RBRKT 
> 
>               3) in packages, time will be one of the stats that will be
> returned for TDM terminations - start time and stop time. 
>               -------------------- 
>               fine.  Don't place any requirements on synchronization of
> time-stamps between 
>               format is probably useful (and RTP-based MGs will need it
> anyway for reports). 
> 
>               In statistics, you still only need the timestamp. So ISO8601
> seems to be good enough. I assume this means we forget about time zones.
> Or are time zones important for statistics - if so maybe having them at
> the MGC is sufficient. 
> 
>               Nancy 
> 	
> -- 
> Regards, 
> Shalini Philip 
> Ficon Technology 
> E-Mail : mailto:[email-masked] 
> Web    : http://www.ficon-tech.com 
>  
>

---

From: Peter Blatherwick <[email-masked]>
Date: Fri, 19 Nov 1999 09:50:43 -0600

Brian wrote:
>Can we declare this issue decided:
>     Time is UTC
>     If you need synchronized time, use NTP

I hummm "YES, almost".  ISO 8601 basis, translated to ABNF, seems
appropriate.  Purpose is measurement of duration and relative timing of
events and transaction responses.  I think we agreed on that much.

Final issues and suggestions:

1. As pointed out, we need to specify exactly what the 8 digit time stamp
really means.  How are the extra 2 digits of precision used, 10s of
milliseconds?  Perhaps ISO specifies this already.

2. What to do when events occur within the resolution of the time stamp.  Do
we simply specify that time stamps always increment to the next higher 10 ms
to ensure we can resolve order?  This seems simple enough.  This problem
always exists, no matter what resolution we choose.

3. How to initialize/synchronize time between the MG and MGC.  Pass through
ServiceChange?  Since all things are relative, perhaps this does not
actually matter.  Certainly, given purpose, this can be a bit sloppy and
imprecise.

>Someone made a suggestion here that if you use ISO 8601 format you avoid

Just an observation:  We won't really have this problem until Y2.1K...   ;-)

-- Peter

> From: Scott W Brim [SMTP:[email-masked]]
> Sent: 16 Nov, 1999 12:08

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 19 Nov 1999 14:19:18 -0600

I'm a bit worried about the demands of billing systems which require event
timestamps.  These demands can be pretty stringent in the PSTN, to support
time-of-day tarriffing.  Will we have the same considerations here?

I suppose instead of worrying I should check to see if synchronization has
to be any better than 100 ms.

> From: Blatherwick, Peter [CAR:AT14:EXCH]
> Sent: Friday, November 19, 1999 10:51 AM
> 2. What to do when events occur within the resolution of the time stamp.
> Do we simply specify that time stamps always increment to the next higher
> 10 ms to ensure we can resolve order?  This seems simple enough.  This
> problem always exists, no matter what resolution we choose.
>
> 3. How to initialize/synchronize time between the MG and MGC.  Pass
> through ServiceChange?  Since all things are relative, perhaps this does
> not actually matter.  Certainly, given purpose, this can be a bit sloppy
> and imprecise.
>
> Scott wrote:

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 17:50:08 -0500

Naw, you want timestamps to understand what happens when
events are skewed by transport.  Incrementing counters
won't cut it.  We don't need a lot of accuracy, we do need
some reasonable resolution.

Please, can we leave it as it is, UTC, 10 ms resolution.
It may be a bit too much, but it's not worth arguing about.

If you need synchronized time (don't know why you would),
use NTP.

The only thing I've heard that makes me want to
do any further changes was the idea that the registration
ServiceChange maybe ought to have a timestamp.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 5:37 PM
> Can I ask a really dumb question? People aren't
> seriously thinking of using an untrusted MG's idea
> of a UTC or any other clock for a *billing* timer
> are they? For example, when I install a nice shiny
> the MikeMG at home running MEGACO, my service
> provider's not going to get upset that the MikeMG
> has this software "flaw" that always happens to
> have the effect of zeroing the billing timer?
>
> If the only reason for timestamps are billing or
> other DOA things like that, we should not
> introduce them into the spec at all.  If all we
> need is sequencing, we should just use
> monotonically incrementing counters.
>
>                   Mike
>
>
> Al Varney writes:
>  > At 14:19 11/19/1999 -0600, Tom-PT Taylor wrote:
>  >
>  >    While I'm reluctant to quote Telcordia (nee Bellcore)
> documents on an
>  > IETF mailing list, they do provide at least one "PSTNish"
> perspective on
>  > these issues.
>  >
>  >    Accounting records (call detail records) specified in
> GR-1100 have
>  > time stamps and duration values in tenths-of-seconds.
>  >
>  >    The "PSTN switch" requirements are in GR-508, including
> requirements
>  > for duration accuracy and precision.  In general, the
> requirements are
>  > for no more than 400 ms error (variation) in any measure
> of Duration.
>  > Clock drift can affect duration measurements by less than
> 50 ms / hour.
>  > That's about 24 min/year drift rate.
>  >
>  >    I'm assuming the "time/date stamp" for records will be
> generated at
>  > the MGC or some higher-level system, and the MG is only
> used for duration
>  > measurements.  If the higher-level system is considered
> part of the AMA
>  > Data Network, then it must follow GR-1343 requirement
> (clock drift rate
>  > of about 25 ms / hour).
>  >
>  >    So reporting times in tenths-of-seconds (rounded from
> internal 50 ms
>  > times) should be enough for accounting/recording.  I
> haven't looked at
>  > the requirements for things like Event Logs and other
> test-access needs.
>  > The recording unit (an MGC or Signaling Gateway, etc.)
> might have to
>  > time-stamp these at the milli-second level, but I don't
> see a need to
>  > have messages from OTHER units carry a time-stamp of that
> precision.
>  >
>  >    I think the 2 fractional parts of a second (hundredths
> of a second)
>  > that Nancy last proposed are enough.  At most, we could
> make it 3 parts
>  > (milli-seconds) and indicate event detection mechanisms of
> lower precision
>  > should just append one or two zeroes as needed.
>  >
>  >    If you mean synchronization of Clocks [rather than
> precision of duration
>  > measurements], I'm not aware of a requirement that a
> "switch" have a clock
>  > closely synchronized with clocks of other switches, and I
> hope any duration
>  > measurement can be determined from events observed in a
> single MG.  If not,
>  > an MGC may have to estimate the "differential" between
> it's own clock and
>  > that of each MG from which it receives reports.
>  >
>  >    FYI, Telcordia's SR-3336 provides a perspective on the
> use of GPS where
>  > accurate times and timing are required in a telecom
> network.  (Note:
>  > I receive no compensation for mentioning Telcordia's
> publications.  :)
>  >
>  >
>  > Al Varney - Lucent Technologies  +1 630 224-7493
> [email-masked]
>  >
>  >
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 22 Nov 1999 06:48:03 -0600

My apologies for introducing a red herring.  Time synchronization is not a
Megaco protocol issue.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, November 19, 1999 5:50 PM