Precision Time ProtocolIEEE1588v2

TICTOC BOF IETF Prague 2007

Ron Cohen Resolute Networksronc@resolutenetworks.com

*

AgendaStatusPTPv1 overviewPTPv2 major additionsTransparent clocksPTP and TICTOC

*

The Precision Time Protocol (PTP)PTPv1 published in 2002Industries involved: v1: Industrial Automation, T&M, Military, Power Generation and Distribution v2 : Audio-Visio Bridges (802.1AS), Telecom and MobileSymposia in 2003, 2004, 2005, and 2006. 2007 in ViennaProducts: Microprocessors, GPS Linked Clocks, Boundary Clocks, NIC Cards, Protocol Stacks, RF Instrumentation, Aircraft Flight Monitoring Instruments, etc.Information: http://ieee1588.nist.govVersion 2 PAR approved March 2005. Technical work completed

*

PTPv1 objectivesSub-microsecond synchronizationIntended for relatively localized systemsApplicable to networks supporting multicastSimple, administration free installationSupport heterogeneous systems of clocks with varying precision, resolution and stabilityMinimal resource requirements on networks and host components

*

Protocol overviewTiming ProtocolAlign slaves to master timeMeasure delay between master and slaveMeasure per-link delay (v2)Synchronization Hierarchy routing ProtocolAutomatic Best Master Clock AlgorithmDetermines the master-slave synchronization clock tree hierarchy Management ProtocolConfiguration and performance monitoring

*

PTP Master-Slave Hierarchy*Clock symbols taken from ITU-T SG15 synchronization modeling components time contribution #249 Geneva-2007 by Mike Gilson of BT

*

Timing Protocol Operation

*

Precision using HW time-stamping

*

1-step and 2-step clocks1-step clock updates accurate timestamp (t1) in Sync message2-step clock sends accurate timestamp (t1) in a Follow_Up messageSimplify design while avoiding queuing noiseEase integration of security extensions

*

PTPv2 major additionsSynchronization accuracies better than 1 nanosecond Higher sampling/message ratesUnicast communicationCorrection for asymmetryTransparent clocksRedundancyConfigurable synchronization hierarchyDecouple sync messaging from hierarchy signalingFormal mechanisms for message extensionsMappings to UDP/IPv4&6, Ethernet w/o VLAN, (also DeviceNet, PROFINET, ControlNet)

*

Sync and Delay-Req formats

*

End-to-End Transparent ClocksE2E TCs cancel queuing and processing delays

*

Peer-to-Peer Transparent ClocksP2P TCs cancel queuing, processing and propagation delays

*

Peer Delay Measurement (Optional)

*

E2E TC Enabled PSNPacket queuing and processing is removed

*

P2P TC Enabled PSNTopology change does not effect slave performance

*

Comparison between switches*restriction can be relieved using P-delay over MPLS

Boundary ClockE2E TCP2P TCClockSynchronizedSyntonizedSyntonizedTopology limitations None NoneHomogenous*with 1:1 connection each linkState maintainedPer port statePer unicast contract state Temporal message state for 2-step TCsPer link stateTemporal message state for 2-step TCsSlave scalability HierarchicalMaster sees all slaves Hierarchical (multicast Sync)Linear scalabilityControl wander accumulation Topology changeMeasure new delayMeasure new delay Pre-compute link delays

*

PTP protocol extensions Define a profile that selects optional feature set, default and range of values Define TLV extension to messagesDefine flag-fields to be carried in event messagesDefine alternate management scheme (SNMP)Define alternate synchronization hierarchy selection (routing) algorithmDefine additional transport mapping (PTP over MPLS)Define alternate clock quality levels and attributes

*

PTP and TICTOC

RequirementsDescriptionServicesFrequency, Phase, Time and meta-Time servicesPrecisionNano-seconds accuracy demonstratedSub nano-seconds granularityIncremental Add Transparent clocks or Boundary clocks to improve performance if required in critical junctionsPerformanceTelecom grade performance has been demonstrated over non-PTP-aware networksScalableUse of boundary clocks and/or transparent clocks to scale and maintain performance limitsRobust to master failuresSmart slaves synchronizing to two domains or two masters in a single domain.Alternate master takes over when master failsRobust to topology changesP2P mechanism allows to pre-compute link-delays to minimize effect of topology change

*

PTP and TICTOC

DerivedRequirementsDescriptionHW friendlyCorrection field is scaled nano-seconds. All computations by transparent clocks are performed on correction field Correction field is in a fixed position from beginning of PTP header Single Timestamp in fixed position immediately after PTP header for master and slave HW setting Heterogonous design options2-step clocks simplify master designs1-step transparent clocks do not need to maintain per master-slave message statesSlave friendlyTimescale (Timestamps) is continuous. Timestamps do not jump or miss one second when leap event occursTime-stamps do not roll over

Questions? Ron CohenResolute Networksronc@resoluteNetworks.com

*

NTP message format

**********************