Standards_Update_IEEE_1588_(Silvana_Rodrigues,_Zar

Agenda\nIEEE Std 1588™ Status and History Version 2\n– Application of Interest – New Features – Types of Messages\n\nPTP Clock Synchronization Details PTP Clock Types\n– One-step and Two-step Clocks – Transparent Clock – Boundary Clock\n\nMaster Clock Selection Profiles Summary\nIEEE 1588TM is trademark of its respective owner\n\nP.2\n\n\r\n

IEEE 1588 – Status and History\nIEEE Std 1588™-2002 (version 1) was published November 8, 2002\n– Defines a Precision Time Protocol (PTP) designed to synchronize real-time clocks in a distributed system – Intended for Local Area Networks using multicast communications only – Originally targeted for industrial automation and test and measurement systems\n\nThe PAR (Project Authorization Request) for version 2 was approved in March 2005\n– P1588 – Precise Networked Clock Synchronization Working Group was formed\n– Resolution of known errors – Conformance enhancements – Enhancements to address new applications (including telecom)\n\nIEEE Std 1588™-2008 (version 2) was approved March 27, 2008 and published July 24, 2008\n– It is available for purchase from the IEEE web site\nhttp://www.ieee.org/web/standards/home/index.html\n\nP.3\n\n\r\n

Version 2 – Application of Interest\nTelecom Industrial Automation Test and Measurement Residential Ethernet (IEEE 802.1AS) Military Power Industry Measurement and Control\n– Process Control Applications\n\nAutomotive (On-Board Control)\n\nP.4\n\n\r\n

Version 2 New Features\nNew Frame Format Unicast Messages in addition to Multicast Higher rate of sync messages Fault Tolerance mechanism Transparent Clock New type of messages New mappings\n– PTP over UDP over IPv6 – PTP over IEEE 802.3/Ethernet – PTP over DeviceNet, ControlNet, ProfiNet\n\nMessage extensions capability using TLVs PTP profiles\n\nP.5\n\n\r\n

PTP Version 2 Messages\nEvent Messages (an accurate timestamp is generated at egress and ingress)\n– Sync – Delay_Req – Pdelay_Req – Pdelay_Resp\n\nGeneral Messages (do not require accurate timestamps)\n– Follow_Up – Delay_Resp – Pdelay_Resp_Follow_Up – Announce – Management – Signaling\n\nP.6\n\n\r\n

PTP Clock Synchronization Details\nMaster\n1 t1=4 Sync message containing an approximation of t1 t2=11 Follow_Up message containing the precise sending time (t1)\n\nSlave\n6\n\nt -t =Delay+Offset\n2 4\n\n1\n\nt -t =Delay-Offset\n3\n\nOffset=[(t -t )-( t -t )]/2\n15\n\n10\n\n2 2\n\n1\n\n4 4\n\n3\n\nDelay=[(t -t )+( t -t )]/2\n1 3\nDelay_Req message t4=17 20 Delay_Resp message containing t4 25 t3=20\n\nIn this example Delay = 2 Offset = 5\n\nP.7\n\n\r\n

One-Step and Two-Step Clocks\nOne-Step Clock\n– A clock that provides time information using a single event message, which means that the follow-up message is not sent\n\nTwo-Step Clock\n– A clock that provides time information using the combination of an event message and a subsequent general message, which means that the follow-up message carries a precise estimate of the time the Sync message was placed on the PTP communication path\n\nP.8\n\n\r\n

PTP Clock Types*\nOrdinary Clock\n– “A clock that has a single Precision Time Protocol (PTP) port in a domain and maintains the timescale used in the domain. It may serve as a source of time, i.e., be a master clock, or may synchronize to another clock, i.e., be a slave clock.”\n\nBoundary Clock\n– “A clock that has multiple Precision Time Protocol (PTP) ports in a domain and maintains the timescale used in the domain. It may serve as the source of time, i.e., be a master clock, and may synchronize to another clock, i.e., be a slave clock.”\n\nEnd-to-End Transparent Clock\n– “A transparent clock that supports the use of the end-to-end delay measurement mechanism between slave clocks and the master clock.”\n\nPeer-to-Peer Transparent Clock\n– “A transparent clock that, in addition to providing Precision Time Protocol (PTP) event transit time information, also provides corrections for the propagation delay of the link connected to the port receiving the PTP event message. In the presence of peer-to-peer transparent clocks, delay measurements between slave clocks and the master clock are performed using the peer-to-peer delay measurement mechanism.”\n\nManagement Node\n– “A device that configures and monitors clocks.”\n* IEEE Std 1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol, copyright 2008 IEEE. All right reserved.\n\nP.9\n\n\r\n

Transparent Clock vs. Boundary Clock\n\nVersion 1 and version 2 specifies Boundary Clock (BC) mechanism\n– BC does not pass Sync, Follow_Up, Delay_Req, or Delay_Resp messages – BC mechanism suitable for topology with small number of switches – Cascading BCs introduce the cascade effect\n– BC distributes timing based on the its local clock – Each clock depends on the quality of all preceding clocks\n\nVersion 2 of 1588 specifies Transparent Clock (TC) mechanism\n– TC mechanism is suitable for topology with either small or large number of switches – Cascade effect in cascading TCs is much better than cascading BCs\n– Each clock does not depend on the quality of the preceding clocks\n\nP.10\n\n\r\n

Boundary Clock\nGrand Master\n\nS\nBC-1\n\nM M\nOC-1 S\n\nS M BC-2 M M S M BC-3 M S\nOC-3 Clock in the cascade devices is affected by\nThe local clock of the predecessor Servo error and quantization errors\n\nS\n\nOC-2\n\nP.11\n\n\r\n

End-to-End Transparent Clock\nGrand Master\nIt measures the residence time, which is the time the event message takes to traverse the transparent clock The residence times are accumulated in the correction field of the PTP event message or the associated follow-up message\n\nE2E-TC-1\n\nM\nOC-1 S\nE2E-TC-2\n\nS\n\nOC-2\n\n• Messages exchanged • Sync • Follow_Up • Delay_Req • Delay_Resp\n\nE2E-TC-3\n\nThe accumulated residence times are used by the slave to adjust the time provided by the master\n\nS\nOC-3\n\nP.12\n\n\r\n

Peer-to-Peer Transparent Clock\nGrand Master\nIt measures link delay in addition to the residence time The computation of link delay is based on an exchange of Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages with the link peer P2P and E2E TCs cannot be mixed on the same communication path\n\nP2P-TC-1\n\nM\nOC-1 S\nP2P-TC-2\n\nS\n\nOC-2\n\n• Messages exchanged • Sync • Follow_Up • PDelay_Req • PDelay_Resp • PDelay_Resp_Follow_Up\n\nP2P-TC-3\n\nThe accumulated residence and link delay times are used by the slave to adjust the time provided by the master\n\nS\nOC-3\n\nP.13\n\n\r\n

Transparent Clocks (TC)\nTransparent clocks are implemented in the switches/routers All the nodes of the network will have to implement TCs to be able to benefit from it It is a technology that was developed by the Industrial automation Can TC be used in Telecom?\n– IEEE 1588 equipment that implements TCs must\n– Intercept, read and modify the PTP packet – Keep state for the Sync, Follow_Up, Delay_Req and Delay_Resp messages – Two-step TCs may create some challenges\n\n– ITU-T and TICTOC are studying the use of TCs for different applications\n\nP.14\n\n\r\n

Master Clock Selection\nIEEE 1588 defines an algorithm based on the characteristics of the clocks and system topology called Best Master Clock (BMC) Algorithm\n– BMC in version 2 is very similar to the version 1\n\nBMC uses Announce messages to establish the synchronization hierarchy\n– The algorithm compares data from two clocks to determine the better clock\n\nEach clock continuously monitors the Announce messages issued by the current master and compares the dataset to itself If the BMC algorithm determines another clock is ‘better’ then the current master, then it becomes a master\n\nP.15\n\n\r\n

Master Clock Selection cont’d\nPTP version 2 makes provision for different methods for Master clock selection\n– By default, the BMC mechanism specified in the standard – An alternate best master clock algorithm specified by a profile\n\nP.16\n\n\r\n

Profiles* in Version 2\nProfile is a set of required options, prohibited options, and the ranges and defaults of configurable attributes “An IEEE 1588 profile may be developed by external organizations including: a) A recognized standards organization with jurisdiction over the industry, e.g. IEC, IEEE, IETF, ANSI, ITU, or; b) An industry trade association or other similar organization recognized within the industry as having standards authority for the industry; c) Other organizations as appropriate.”\n\n* IEEE Std 1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol, copyright 2008 IEEE. All right reserved.\n\nP.17\n\n\r\n

Profiles\nDifferent applications need different profiles\n– Need to understand the application requirements\n– TICTOC is working on a requirements document\n\nAccording to IEEE 1588 a profile should define\n– Best master clock algorithm options – Configuration management options – Path delay measurement option (delay request-response or peer delay) – Range and default values of all configurable attributes and data set members – Transport mechanisms required, permitted, or prohibited – Node types required, permitted, or prohibited – Options required, permitted, or prohibited – It also allows to extend the standard\n\nP.18\n\n\r\n

Profiles cont’d\nBut in addition to IEEE 1588 profile parameters, other aspects need to be considered Clock requirements\n– What is the clock bandwidth? What is the frequency and holdover accuracy? Etc – ITU-T is working on the clock requirements\n\nFunctions to be implemented\n– – – – One-step versus two-step Does it support Boundary Clocks? Does it support Transparent Clocks? Does it support Synchronous Ethernet?\n\nNetwork Metrics\n– Unicast versus Multicast – Does the network support QoS? – Characterization of the network – ITU-T is studying metrics to characterize the network (e.g., minTDEV) – Traffic load – Number of hops\n\nP.19\n\n\r\n

Summary\nIEEE 1588 standard is available Provides features and functions that are very useful to achieve precise synchronization Work still needs to continue to define the profiles for different applications\n– ITU-T – TICTOC\n\nP.20\n\n\r\n