Subject: [TICTOC] Agenda for upcoming meeting

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 28 May 2008 10:30:01 +0300

A while ago I sent out the proposed section headings for
the requirements document, and asked for feedback.
 
Sasha proposed adding a section   on the difference between clients  
with various levels of local frequency references 
and Stefano, Stuart, Danny and Dave commented on this proposal.
 
I have not seen any further comments.
 
As we would like to start putting together the agenda,
let me reiterate my request that participants detail which sections  
they want to discuss (providing text would be even better).
 
Y(J)S

 
=====================================================
 
Hi all, 
 
Stewart and I just finished merging the problem statement and Kurt's ITP
draft, 
together with all the requirements statements we found in presentations
given at the BOFs, and came up with the following proposed table of
contents
for the TICTOC requirements draft.
 
We suggest starting from these headings at the interim meeting in June. 
We encourage all of you to provide text for these sections.
Of course, suggestions for changes in the sections or subsections are
also welcome.
 
Y(J)S
 
========================================================
1 Introduction
2 Terminology
3 Application requirements 
  3.1 Time Service
  3.2 Frequency Service
4 Problems with Existing Time and Frequency Distribution Mechanisms  
  4.1 Non-packet distribution
  4.2 Packet distribution
5 Time scale issues
  5.1 Time definition and translations (TAI, UTC, local time)
  5.2 Required accuracy
  5.3 Resolution
  5.4 Time format
  5.5 Handling discontinuities (leap seconds, monotonicity, handover)
6 Network dependencies
  6.1 Layers and encapsulations (including MPLS)
  6.2 Path asymmetry
  6.3 Handling congestion
  6.4 On-path support 
7 Other dependencies 
  7.1 Client's dependency on local frequency reference 
8  Network topology
  8.1 Autodiscovery
  8.2 Optimal path selection
9  Protocol requirements
  9 .1 Scalability (memory, computation and rate constraints)
  9 .2 Service requests (accuracy, update rate, etc.)
  9 .3 Compatibility
  9 .4 Extensibility (TLVs, etc.)
  9 .5 Profiling
  9 .6 Packet format
  9 .7 Algorithm independence
  9 .8 Multicast, unicast, anycast
  9 .9 Robustness
10  Host API
11  Algorithms
 11.1 Best Master
 11.2 Frequency locking
 11.3 Ranging
 11.4 Mitigation (minimum gating, etc.)
 11.5 Clustering and combining
 11.6 Disciplining
12  Performance measurement and management
13  OAM
14  Network management
15  Supporting protocols (DNS, DHCP, IGP)
16  Security Considerations
  16.1  Client authentication 
  16.2 Server authentication
  16.3 Secure traceability
 
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 30 May 2008 16:07:01 +0300

Hi Yaakov,
 
Please consider the following when putting together the agenda. 
 
There are a large number of topics in the proposal. If we start to
simply develop text under all of the section headings of the requirement
document, the job will be huge and there is a risk that we develop a new
timing-over-packet standard altogether, which would be largely waste of
resources.
 
Therefore, I propose to concentrate first in those section headings
where:
1) The end-to-end requirements separately for frequency and time
synchronization are considered. 
2) On the other hand, the current and prospect network architectures and
protocol stacks should be discussed. This is very important for
time-of-day delivery and may be one of the major value-adds TICTOC can
produce.
 
Considering the time inaccuracy budget usable by the network for e.g.
WiMAX, where air interface requires +/- 500 ns (a profile selected by
WiMAX forum), one ends up in a requirement of 200-300 ns over the
network. It is clear that only IEEE 1588 is usable without considerable
additional standardization effort.
 
3) If the above would be be accepted, then it would be straightforward
to concentrate in developing internet/telecom profile components
(separately to frequency and time synchronization) to IEEE 1588 in
cooperation with ITU-T Q13/SG15 and IETF PWE3. While developing the
profile components, selections should be made to limit the options
developed in IEEE 1588. One should also take a look at the selections
made by 802.1AS. During the course of the work possible holes in the
current IEEE 1588 standard would be exposed and could be consequently
fixed.
 
Best regards, Antti 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Yaakov Stein
	Sent: 28 May, 2008 10:30
	To: [email-masked]
	Subject: [TICTOC] Agenda for upcoming meeting

	 
	Sasha proposed adding a section   on the difference between
clients  
	with various levels of local frequency references 
	and Stefano, Stuart, Danny and Dave commented on this proposal.

	As we would like to start putting together the agenda,
	let me reiterate my request that participants detail which
sections  
	they want to discuss (providing text would be even better).
	 
	Y(J)S

	 
	 
	Hi all, 
	 
	Stewart and I just finished merging the problem statement and
Kurt's ITP draft, 
	together with all the requirements statements we found in
presentations
	given at the BOFs, and came up with the following proposed table
of contents
	for the TICTOC requirements draft.
	 
	We suggest starting from these headings at the interim meeting
in June. 
	We encourage all of you to provide text for these sections.
	Of course, suggestions for changes in the sections or
subsections are also welcome.
	 
	Y(J)S
	 
	4 Problems with Existing Time and Frequency Distribution
Mechanisms  
	  5.5 Handling discontinuities (leap seconds, monotonicity,
handover)