TICTOC Paris Interim Meeting Report

1. TICTOCParis Interim MeetingReport

2. Attendees Yaakov Stein - RAD Pat Diamond - Semtech Emmanuel Sicsik - Spectracom Tim Frost - Symmetricom Doug Arnold - Symmetricom Greg Dowd - Symmetricom Joseph Neil - Symmetricom Grégory LABORDE - Team Avionics Karen O'Donoghue - US Navy Silvana Rodrigues - Zarlink Stewart Bryant - Cisco Systems Mark Townsley - Cisco Systems Laurent Montini - Cisco Systems Leonid Goldin - Cisco Systems Jean-Loup Ferrant - Alcatel-Lucent Michel Le Pallec - Alcatel-Lucent Alex Tal - Axerra Mike Gilson - British Telecom Kurt Erik Lindqvist - Consultant Peter Lothberg - Consultant Helmut Imlau - Deutsche Telekom Stevano Ruffini - Ericsson John Zhao - Huawei Kuiwen (Jacky) Ji - Huawei Zhang Zhan - Huawei Michael Mayer - Nortel Anti Pietilainen - NSN Sébastien JOBERT - Orange- Groupe FT via dial-in : Stuart Venters - Adtran Marshal Eubanks - Iformata Communications

3. Meeting Goals • Kickoff TICTOC work • Progress on first objective of the charter: To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. • If there is time, start work on architecture draft • Hand over document editorship from chairs to others

4. Per-meeting survey In order to gauge areas of interest the chairs generated a questionnaire Prior to the interim meeting a questionnaire was sent out 24 responded to the questionnaire Compilation of responses was sent to the list before the meeting The next 2 slides present some of the questions

5. Some pre-meeting questions Relevant applications that interest you : • Cellular backhauling – (including LTE, WiMAX, etc.) • Remote telco applications • Instrumentation / measurement • Industrial • Networking • Time of Day over the general purpose Internet • Legal time • Electrical power systems • Distributed sensor networks Which of the following best describes what you feel TICTOC should do ? • define minor extensions to NTPv4 • define 1588 profiles • define a new TLV-based protocol • define a new protocol with backwards compatibility to NTP

6. Some more pre-meeting questions What timescale do we want to distribute? Should a separate “frequency only” service be defined? What about a special “time when frequency is locked” service? Should we divide the categories into stringent to undemanding? Do you agree that TICTOC should exploit on-path support when available, but function (with reduced performance) when it is not ? Do we need a signaling protocol to the end system? Do you agree that TICTOC should exploit hardware in clients and servers when available, but function (with reduced performance) when it is not ? Do we need to handle multiple clocks? How should potential clients determine where to find a time server ? What authentication mechanisms are required ?

7. Meeting agenda • Bash questionnaire • Flesh out general requirements • Parallel sessions on specific application requirements • Application requirements integration (matrix) • Presentation on ITU-T work • ITP draft walk-through • Parallel sessions on NTP/1588 capabilities • Capabilities integration (matrix) • Discussion on next steps

8. Timescales There are many possible timescales (TAI, UTC, local time, …) Main differences: • whether there are discontinuous jumps • whether need external information to translate • resolution (picoseconds?) • whether communications is one-way or there is negotiation • whether client is light-weight or supports multiple timescales • scalability vs. flexibility Conclusion: • need default timescale • need to be able to identify the time source • need to be able to distribute multiple timescales (1 at a time per server)

9. On-path support(network helper functions) Any network mechanism that improves timing distribution (even passive network monitor that informs endpoints …) LINK SUPPORT 1) a SyncE link 2) a POS path with frequency available to user 3) a DSL link with NTR NETWORK ELEMENT SUPPORT 1) a network element with high quality local frequency (e.g. atomic clock) 2) a network element with local time (e.g. GPS) 3) boundary clock 4) transparent clock 5) common clock (for differential time-stamping) 6) routing decisions and auto-discovery mechanisms that support timing

10. On-path support (cont.) Agreed : • exploit when available, function (with reduced performance) when not • can’t modify every router to inform that it does not have on-path support • need some concept of domain Questions : • multiple classes ? • how does user know what was available / received ? • operator may contract and set up • or the user may ask the network if it is capable • need a signaling protocol to the end system? • need to work with routing community? • how set up ? • traffic engineering model • hop by hop (RSVP) model • how are failures detected ? • what about multiple operator cases ?

11. Frequency services 1588 and NTP are actually time services but can be used for frequency distribution as well A pure frequency service is useful (SyncE is an example) If there is one, want to maximize commonalities between services Another attractive service is time only given frequency from another service (e.g. SyncE + 1588) This may be an implementation issue and can wait until later to resolve

12. Requirements on requirements Different applications have different requirements we need to meet the ones with the strictest requirements but without overloading the solutions for easier cases We should not try to solve problems that already have solutions but rather to identify gaps (and Reuse is good) Division into stringency categories is hard • performance (accuracy, jitter, wander), • scalability, cost, auto configuration, management No consensus on these issues

13. Misc. general requirements Separation of algorithms from protocols • good idea Is a profiling mechanism required ? • will see later Distinguish between time within an AS and outside it ? • need to discuss more Define API • IETF has done before

14. Scalability Our protocol needs to scale well, but there are several possible scalability issues: • number of clients per server • number of servers on network • number of hops / maximum propagation time The number of clients is a true scalability issue The number of servers is only a client selection issue Specific requirements for scalability are application dependent

15. Multiple protocols (AKA interworking) A single application may cross multiple domains with multiple timing protocols Interworking requirements are an architectural constraint What is meant by interworking? We do not expect interoperability at the timing protocol level We do demand that different protocols coexist i.e., do not break the network e.g., do not use the same protocol identifiers

16. Multiple clocks We need to handle multiple clocks including phase-hitless switching from one to another Actually a packet clock = the master clock + the network How do we handle multiple paths back to the same source clock ? In general we will have • multiple clocks • multiple paths • changing paths

17. Some numeric questions Proposal - time resolution of 1 picosecond • not the case for either NTP or 1588 Proposal for flexible (nonfixed) resolution • HW designers will not like Maximum and minimum update rates • sufficient rate to meet requirements • but without breaking network

18. Security Authentication • of server by client - MUST requirement - should use IPsec • of client by server – yes (clarify available vs must be used) • of on-path support middleboxes - probably • of packets / transaction - maybe Problem • no security protocols understand zero knowledge proof of time • underlying assumption of synchronized time in authentication protocols Source traceability is a requirement Encryption of timing packets (e.g. for fee-based services) not yet needed

19. Requirements matrix (part 1) GSM/WCDMA over packet Frequency/FDD WCDMA TDD LTE/MBMS/(WiMAX/DVB-H) time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

20. Requirements matrix (part 2) circuit emulation remote telco synchronization interface traffic interface time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

21. Requirements matrix (part 3) instrumentation / measurement - automated test system time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

22. Requirements matrix (part 4) industrial electrical power - sub station time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

23. Requirements matrix (part 5) Networking SLA Network CDR TOD/Internet time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

24. Requirements matrix (part 6) legal time metrology sensor networks time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat

25. Capabilities matrix 1588 NTPv4 wide-area constrained Internet constrained time type time resolution client's time resolution freq stability freq accuracy time/phase stability time/phase accuracy acquisition time service jitter service wander asymmetry constrained network on-path support clients/server update rate server auth client auth transaction auth backwards compat