TTinterim Slide 1 TICTOC Paris Interim Meeting Report

TTinterim Slide 1

TICTOCTICTOC

Paris Interim MeetingParis Interim Meeting

Report Report

TTinterim Slide 2

AttendeesAttendees

Jean-Loup Ferrant - Alcatel-LucentMichel Le Pallec - Alcatel-LucentAlex Tal - AxerraMike Gilson - British TelecomKurt Erik Lindqvist - ConsultantPeter Lothberg - ConsultantHelmut Imlau - Deutsche TelekomStevano Ruffini - EricssonJohn Zhao - HuaweiKuiwen (Jacky) Ji - HuaweiZhang Zhan - HuaweiMichael Mayer - NortelAnti Pietilainen - NSNSébastien JOBERT - Orange- Groupe FT

Yaakov Stein - RADPat Diamond - SemtechEmmanuel Sicsik - SpectracomTim Frost - SymmetricomDoug Arnold - SymmetricomGreg Dowd - SymmetricomJoseph Neil - SymmetricomGrégory LABORDE - Team AvionicsKaren O'Donoghue - US NavySilvana Rodrigues - ZarlinkStewart Bryant - Cisco SystemsMark Townsley - Cisco SystemsLaurent Montini - Cisco SystemsLeonid Goldin - Cisco Systems

via dial-in :Stuart Venters - AdtranMarshal Eubanks - Iformata Communications

TTinterim Slide 3

Meeting GoalsMeeting 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

TTinterim Slide 4

Per-meeting surveyPer-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

TTinterim Slide 5

Some pre-meeting questionsSome 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

TTinterim Slide 6

Some more pre-meeting questionsSome 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 ?

TTinterim Slide 7

Meeting agendaMeeting 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

TTinterim Slide 8

TimescalesTimescales

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)

TTinterim Slide 9

On-path supportOn-path support(network helper functions)(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

TTinterim Slide 10

On-path support (cont.)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 ?

TTinterim Slide 11

Frequency servicesFrequency 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

TTinterim Slide 12

Requirements on requirementsRequirements 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

TTinterim Slide 13

Misc. general requirementsMisc. 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

TTinterim Slide 14

ScalabilityScalability

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

TTinterim Slide 15

Multiple protocols Multiple protocols (AKA interworking)(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

TTinterim Slide 16

Multiple clocksMultiple 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

TTinterim Slide 17

Some numeric questionsSome 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

TTinterim Slide 18

SecuritySecurity

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

TTinterim Slide 19

Requirements matrix (part 1)Requirements matrix (part 1)

GSM/WCDMA over packet Frequency/FDD WCDMA TDD LTE/MBMS/(WiMAX/DVB-

H)time typetime resolutionclient's time resolutionfreq stabilityfreq accuracytime/phase stabilitytime/phase accuracyacquisition timeservice jitterservice wanderasymmetryconstrained networkon-path supportclients/serverupdate rateserver authclient authtransaction authbackwards compat

TTinterim Slide 20


circuit emulation remote telco synchronization interface traffic interfacetime typetime resolutionclient's time resolutionfreq stabilityfreq accuracytime/phase stabilitytime/phase accuracyacquisition timeservice jitterservice wanderasymmetryconstrained networkon-path supportclients/serverupdate rateserver authclient authtransaction authbackwards compat

TTinterim Slide 21


instrumentation / measurement - automated test system

time typetime resolutionclient's time resolutionfreq stabilityfreq accuracytime/phase stabilitytime/phase accuracyacquisition timeservice jitterservice wanderasymmetryconstrained networkon-path supportclients/serverupdate rateserver authclient authtransaction authbackwards compat

TTinterim Slide 22


industrial electrical power - sub station


TTinterim Slide 23


Networking SLA Network CDR TOD/Internet


TTinterim Slide 24


legal time metrology sensor networks


TTinterim Slide 25

Capabilities matrixCapabilities matrix

1588 NTPv4 wide-area constrained Internet

constrainedtime typetime resolutionclient's time resolutionfreq stabilityfreq accuracytime/phase stabilitytime/phase accuracyacquisition timeservice jitterservice wanderasymmetryconstrained networkon-path supportclients/serverupdate rateserver authclient authtransaction authbackwards compat

Documents

TTinterim Slide 1 TICTOC Paris Interim Meeting Report