670 likes | 926 Views
dB Levels, Inc. IEEE 1588 Tutorial. Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588. Mini Glossary. GPS - Global Positioning System, is a satellite navigation system consisting of 24 satellites have atomic clocks that are accurate to within a billionth of a second – 1ns.
E N D
dB Levels, Inc. IEEE 1588 Tutorial Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588
Mini Glossary GPS - Global Positioning System, is a satellite navigation system consisting of 24 satellites have atomic clocks that are accurate to within a billionth of a second – 1ns. UTC or Coordinated Universal Time - A high precision atomic time standard that is used as a time reference for many Internet and WWW applications. Specified in ITU-R TF.460-4. Accuracy - A measure of how closely the frequency generated by the standard corresponds to its assigned value (e.g., the atomic transition frequency for an atomic standard). A measurement of a 100-Hz frequency that is accurate to the sixth decimal place is said to be accurate to 1 part in 108, 0.1 parts per billion, or to have 10−8 accuracy. Precision - A measure of the repeatability of a frequency measurement. It is generally expressed in terms of a standard deviation of the measurement. Stability - A measure of the maximum deviation of the standard’s frequency when operating over a specified parameter range. Holdover - The mode that a clock enters into when it loses connectivity with an input reference. While in holdover, the clock uses stored data to control its output and its stability depends on the stability of its internal oscillator. Jitter - deviation of a time signal from its ideal point in time. Wander - Wander is a phase variation at slow frequency of DC to 10Hz. It requires wider measurement range than Jitter. (The required range is at least 1 x 109 ns according to ITU-T Rec. O.172.). BITS – Building Integrated Timing System – A standard for distributing a precision clock among telecommunications equipment . TIE – Time Interval Error - The variation in time delay of a given timing signal with respect to an ideal timing signal over a particular time period. TDEV - a measure of how much the phase (in time units) of a clock could change over an interval of duration T assuming that any systemmatic (i.e. constant) frequency offset has been removed. MTIE – Maximum Time Interval Error – A measure of the worst case phase variation of a signal with respect to a perfect signal over a given period of time. PDV – Packet Delay Variation - The variation in the amount of Latency among Packets being received, has an impact on jitter and wander for Pseudowire implementations. ACR – Adaptive Clock Recovery – method of recovering frequency from the arrival rate of packets, not recommended in heavily loaded or best effort networks. 2
Timing & Synchronization 101 Confidential
Synchronization Schemes Reference Isochronous - same frequency, out of phase A Asynchronous – out of frequency, out of phase B Synchronous – same frequency, same phase C 4
How is timing used in network equipment? Received Signal Timeslots F4 F3 F2 F1 Data Data Data Data A reference timing source provides a precise clock that is used for framing and timeslot inference in network elements Imperfect timing can cause buffer underflow and overflow conditions leading to frame slips RX TX 5
Frequency and Phase Relationship between frequency and phase: ω=dФ/dt Frequency is the slope in the phase plot 8
Analysis from phase: TDEV TDEV(t) is the rms of filtered TIE, where the bandpass filter (BPF) is centred on a frequency of 0.42/t. 10
Synchronization Analysis (MTIE) Both MTIE and TDEV are measures of wander over ranges of values from very short-term wander to long-term wander MTIE is a peak detector: shows largest phase swings for various observation time windows 11
Synchronization Analysis (TDEV) TDEV is a highly averaged, “rms” type of calculation showing values over a range of integration times 12
Synchronization Hierarchy in North America Stratum 1 Most accurate clock sources in the network Frequency accuracy: ±0.01 ppb to UTC Used in Network Gateways S1 S1 Stratum 2 Receive sync signals from multiple sources, good holdover capability Frequency accuracy: ± 16 ppb Used in Central Offices S2 S2 S2 S2 Stratum 3 Receive sync signals from multiple sources, reasonable holdover capability Frequency accuracy: ± 4.6 ppm Used in local offices S3 S3 S3 S3 S3 Stratum 4 Receive sync signals from multiple sources, Tolerable holdover capability for CPE applications Frequency accuracy: ± 32 ppm Used in CPEs, Set-top boxes, etc. S4 S4 S4 S4 13
ITU-T Sync Reference Chain PRC G.812 Type I G.813 Number of G.813 clocks £20 Number of G.812 type I clocks £10 G.813 G.812 Type I G.813 Total number of G.813 clocks in a synchronization trail should not exceed 60 14
Clock Types SDH SONET PRC PRS Primacy Reference Clock Primacy Reference Source Decreasing Accuracy SSU BITS Synchronization Supply Unit Building Integrated Timing Source SEC SMC SDH Equipment Clock SONET Minimum Clock 15
Timing is critical MAN MAN MAN SEC SEC MAN Local Exchange Ring STM-1/4 SSU ADM ADM SSU SSU ADM Transit Ring STM-4/16 ADM PRC Backbone Ring STM-16 PRC f T1/E1 T1/E1 IWF IWF IP Network Remote Terminal TDM to Packet Central Office Packet to TDM • Digital switching equipment must be synchronized to avoid slips • Slips have a major impact on circuit-switched services • SONET and SDH technologies of the 1990s put stringent requirements on network synchronization • Network synchronization plays an important role in next generation packet switched networks too 16
The Next Generation Network • Predominantly IP-based • Access networks owned by different service providers • Networks provide transit as well as access • Timing is required at points where legacy networks meet IP networks and for QoS assurance across the entire network Wireless Service Provider’s IP Network Synchronization required IP Transit Network Broadband Wireline Service Provider’s IP Network PSTN Service Provider’s IP Network Local Exchange Reproduced from ATIS NGN Framework 17
NGN applications rely on time and frequency synchronization WEB Services Content Distribution SIP Apps Parlay/OSA SCP Service Profiles AAA Messaging Session Control Dynamic Service Data (Presence, Location) WiMAX Existing PSTN DSL M a n a g e m e n t Cable Core IP Centric Network Existing Mobile Access CPE UMTS Edge Existing Internet GigE Broadband Interconnect Access Network Resources Existing Internet NGN Core v1.1, Reproduced from ATIS Time synchronization required Frequency synchronization required 18
Service-specific Synchronization Requirements Source: Cisco 19
Examples of applications that need precise time and frequency Distributed database transaction journaling and logging (Time-of-day) Stock market buy and sell orders (Time-of-day) Secure document timestamps (with cryptographic certification) (Time-of-day) Aviation traffic control and position reporting (Time-of-day) Radio and TV programming launch and monitoring (Time-of-day, frequency) Intruder detection, location and reporting (Time-of-day) Multimedia synchronization for real-time teleconferencing (Time-of-day, frequency) Network monitoring, measurement and control time (Frequency) Early detection of failing network infrastructure devices (Time-of-day, frequency) Differentiated services traffic engineering (Time-of-day, frequency) Distributed network gaming and training (Time-of-day) 20
Next Generation Sync Requirements Real-Time Applications APPLICATION SYNCHRONIZATION REQUIREMENT Voice < 32 ppm (part per million) Ethernet Best Effort < 100 ppm (part per million) Two-way Video < 50 ppb (part per billion) One-way Video MPEG < 500 ppb (part per billion) One-way Video HDTV < 100 ppb (part per billion) One-way Video IPTV < 100 ppb (part per billion) Mobile Sync Requirements Source: Vodafone & others 21
Standards Bodies • ITSF - International Telecom Sync Forum • ITU-T - International Telecommunication Union • ANSI - American National Standards Institute • ATIS - Alliance for Telecommunications Industry Solutions • IEEE - Institute of Electrical and Electronics Engineers • Bellcore/Telcordia - http://www.telcordia.com/ • NIST - National Institute of Standards and Technology • IETF - Internet Engineering Task Force • TicToc BOF – timing and frequency distribution over IP BOF
Applicable Standards • ITU-T G.811: Timing Characteristics of Primary Reference Clocks • ITU-T G.812: Timing requirements of slave clocks suitable for use as node clocks in synchronization networks • ITU-T G.813: Timing characteristics of SDH equipment slave clocks (SEC) • ITU-T G.823: The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy (i.e. E1) • ITU-T G.824: The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy (i.e. T1) • Draft ITU-T Recommendation G.8261/Y.1361 - Timing and synchronization aspects in packet networks – formally G.pactiming • GR-1244-CORE, Clocks for the Synchronized Network: Common Generic Criteria Generic Requirements • GR-378-CORE, Building Integrated Timing Systems • GR-378-CORE, Timing Signal Generator Generic Requirements (supersedes above) • GR-436-core: Digital Network Synchronization Plan • GR-499-core: Transport Systems Generic Requirements (TSGR): Common Requirements • GR-253-CORE, SONET Transport Systems: Common Generic Requirements • GR-2830-CORE: Primary Reference Sources: Generic Criteria • ANSI T1.101-1999: Synchronization Interface Standard • DTI: DOCSIS Timing Interface Specification • PTPv1 – 2002: uSec accurate timestamps and distribution • PTPv2 – 2008???: sub nSec accurate, correction (offsets) for asymmetric topologies, redundancy, etc. • NTP - Network Time Protocol: (NTPv3, RFC 1305, Obsoletes: RFC-1119, RFC-1059, RFC-958), (SNPTv4, RFC 2030, Obsoletes RFC 1769) • ITU-R TF.460-4: STANDARD-FREQUENCY AND TIME-SIGNAL EMISSIONS 24
ITU-T Synchronization Standards ITU-T Recommendation G.803 (2000), Architecture of transport networks based on the synchronous digital hierarchy (SDH). ITU-T Recommendation G.810 (1996), Definitions and terminology for synchronization networks. ITU-T Recommendation G.811 (1997), Timing characteristics of primary reference clocks. ITU-T Recommendation G.812 (1998), Timing requirements of slave clocks suitable for use as node clocks in synchronization networks. ITU-T Recommendation G.813 (1996), Timing characteristics of SDH equipment slave clocks (SEC). ITU-T Recommendation G.823 (2000), The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy. ITU-T Recommendation G.824 (2000), The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy. 25
North American Synchronization Standards ANSI T1-101: Synchronization Interface Standard Bellcore GR-253-core: Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria Bellcore GR-1244-core: Clocks for the Synchronized Network: Common Generic Criteria Bellcore GR-436-core: Digital Network Synchronization Plan Bellcore GR-378-core: Generic Requirements for Timing Signal Generators Bellcore GR-499-core: Transport Systems Generic Requirements (TSGR): Common Requirements 26
NGN Timing Standards 1985 1988 1989 1992 2006 IETF NTPv0 RFC958 NTPv1 RFC1059 NTPv2 RFC1119 NTPv3 RFC1305 NTPv4 Work In progress Evolution from Time Protocol and ICMP Timestamp message Specification of protocol, algorithms state variables and operational modes Management of clients, authentication based on 64-bit DES Sanity checks for lost or corrupted packets, clock algorithm improved, new peering algorithm Improved algorithm, security enhancements 2002 2007 1588v2 IEEE 1588v1 Initial release for Industrial Automation, T&M Enhanced for telecom applications, nanosecond accuracy Feb 2008 Network modeling Feb 2008 Synchronous Ethernet G.8262 G. pacmod Apr 2004 Question 13 Oct 2003 ITU-T G. pactiming G. Paclock. bis G. paclock 2008 Profile for telecom Study Group 15 Timing and Synchronization aspects of Packet Networks Sep 2004 G.8261 Y.1361 Network reference model for timing over IP networks 27
Clock Recovery Methods over Packet • Network Synchronous Operation: network-synchronous operation by using a PRS/PRC traceable network derived clock or a local PRS/PRC as the service clock. In effect, the TDM signal is “retimed”. The clock accuracy of ingress TDM clock (clk1) must be PRS/PRC traceable, otherwise the use of a network clock reference in the egress IWF (i.e. clk3) will cause jitter buffer overflow/underflow events in the egress IWF. • Differential Clock Recovery: The principle of operation of any differential method is based on the availability of “equal” clock references at the ingress and egress IWFs. The difference between the service clock and the reference clock is encoded and transmitted across the packet network.The service clock is recovered on the far end of the packet network making use of the “equal” reference clock. Synchronous Residual Time Stamp (SRTS) is an example of this family of methods. Differential methods can support the plesiochronous circuit timing (also known as asynchronous circuit timing) mode whereby the TDM service clock can have an offset from PRS/PRC provided it is within defined limits. Correct timing in the output TDM signal implies that the clocks generating the TDM signal (clk1) and retiming (clk4) the TDM signal must have the same long term frequency (or within the PRS/PRC limits) otherwise jitter buffer overflow/underflow events will be generated in the egress IWF and the destination TDM NE may experience slips. It is easy to show that wander (and frequency inaccuracy) in the egress TDM signal (clk4) is directly related to the relative wander between the reference clocks clk2 and clk3. Figure 5 shows that the references come from two distinct PRS/PRC units though obviously they could be the same. If the synchronization trail between clk2 and the PRS/PRC and that of clk3 and the PRS/PRC has a “common” node, that node could be in holdover without adversely impacting the differential mode of operation. • Adaptive Clock Recovery: In Adaptive Clock Recovery (ACR) methods, timing is recovered based on the inte-rarrival time of the packets or on the fill level of the jitter buffer. Adaptive methods can support the plesiochronous circuit timing mode whereby the TDM service clock can have an offset from PRS/PRC provided it is within defined limits. If the transit time across the packet network of the packets varies, also known as packet delay variation (PDV) or time-delay variation (TDV), the clock recovery process is affected. In particular, PDV, on a short-term basis, is indistinguishable from a change in the phase/frequency of the service clock and/or the local oscillator. Consequently ACR implementations require high quality oscillators and apply filtering corresponding to bandwidths of the order of milli-hertz (mHz) (time constants of the order of 1,000s). However, if a network clock reference is not available, then ACR is the only available method for service clock recovery. There are several causes of delay variation including the following that are covered in G.8261: • • Random delay variation (e.g. queuing delays) • • Low frequency delay variations (e.g. day/night traffic patterns) • • Systematic delay variation (e.g. transmission window) • • Routing changes (e.g. network re-configuration) • • Congestion effects (e.g. network overload) • Since the performance of adaptive clock recovery is very dependent upon PDV, it is recommended for use only when the PDV can be tightly controlled.
Synchronous Ethernet Point-to-point distribution of timing signals in Ethernet environments Synchronize the Ethernet physical layer as currently done in SONET/SDH Packetize Synchronization Status Messaging protocol (SSMoETH) Bring carrier-grade telecom-quality clocks to Ethernet switches Maintain SONET/SDH network synchronization principles & guidelines Implementation conformant with IEEE 802.3 specification High-level definition part of ITU-T G.8261 clause 8.1.1 Specification to be established within ITU-T G.pacmod & G.paclock Point to point – i.e. all network elements must support in order to be effective frequency distribution mechanism Frequency only, no sense of phase or Time of Day (ToD) 29
Synchronization in the IWF Figure 15/G.8261 - IWF synchronization functions (Packet to TDM direction) 30
Synchronization Techniques Frequency transfer • Network Synchronous • Differential Clock Recovery • Adaptive Clock Recovery • Synchronous Ethernet Time transfer • NTP – Network Time Protocol v4 • IEEE 1588v2 (also known as Precision Time Protocol, PTP) 31
Network Synchronous Operation PRC Traceable network clock is used as a service clock Implies that PRC traceable clock is available at both ends Reference signals at IWF must comply with G.823 and G.824 Figure 6/G.8261 – Example of Network Synchronous Operation 32
f T1/E1 T1/E1 IWF IWF IP Network MSC Packet to TDM Remote Terminal TDM to Packet Synchronization Challenges in the IP Backhaul Network • Synchronization path is broken • Traditional synchronization techniques are not available • IP Networks introduce complexities to data traffic flow • Different upstream and downstream paths • Time varying delays • Asymmetric delays • Synchronization must include both frequency and phase: • Frequency only • Synchronous Ethernet • Adaptive Clock Recovery (ACR) • Frequency and Phase • GPS-based timing that provides T1 retiming capabilities • Differential clock recovery – NTP & IEEE 1588 (PTP) IWF: Interworking Function NextGen timing and sync distribution methods must include time and phase in addition to frequency
Adaptive Clock Recovery Timing is recovered based on the inter-arrival time of the packets or on the fill level of the jitter buffer Service clock is preserved Figure 8/G.8261 – Example of Adaptive Method 34
Adaptive Clock Recovery (ACR) issues • Proprietary – non standard, requires “bookend” approach • Frequency only – no sense of phase • Unpredictable wander, can’t be filtered out • No measurement of differential delay, handoffs a challenge • Recovery from network perturbations (e.g. fiber cut, re-route, traffic loading) also a challenge • No way to prevent instantaneous phase jumps • Jitter buffer adds to latency – lowers user QOE • Buffer overruns and underruns cause packet and data loss • Point to point – multiplexing/aggregation a challenge • No Global reference for time/sync – no visibility of timing loops and islands • Additional PWE on network degrades sync performance • Even with PWE as highest priority traffic, it is self-interfering • PWE packets tend to “clump” • Better local oscillators actually exacerbate the problem – the tighter the freq control, the more the wander: • Amp <= Ts * BWpwe / BWlink
Differential Clock Recovery Distributes Global time. phase and frequency based on Primary Clock Reference Preserves service clock – frequency and phase difference from Global reference Hierarchical distribution from global reference prevents timing loops Synchronization Status Messaging (SSM) – manageability and traceability Scalable, supports point-to-point, point-to-multipoint, multipoint and broadcast services. Signals at IWF comply with ITU G.823 and G.824 sync requirements Standards-based – IEEE1588v2, NTP Figure 7/G.8261 – Example of Differential Method Differential Clock Recovery distributes phase and absolute time, not just frequency 36
PTP/NTP Timing Recovery • Global clock reference – GPS based • Understanding of time, freq and phase • No tendency of timing packets to “clump” – can be staggered to ensure no impact to wander characteristics • Timing updates are negligible BW, not traffic dependent • Standards compliant – IEEE 1588, NTP • Internal algorithms are proprietary, but multiple vendors’ servers and clients are interoperable, unlike ACR and PWE equipment • Brilliant servers are more accurate than competitors, leading to better timing and sync at the edge • Better time, sync and phase mean better QOE
NTP overview • Network Time Protocol (NTP) synchronizes clocks of hosts and routers in the Internet • The NTP architecture, protocol and algorithms have been evolved over the last two decades. Currently NTP Version 4 is being developed • Well-tested and widely-deployed protocol • NIST estimates 10-20 million NTP servers and clients deployed in the Internet and its tributaries all over the world. Every Windows/XP has an NTP client • NTP provides nominal accuracies of low tens of milliseconds on WANs, submilliseconds on LANs, and submicroseconds using a precision time source such as a cesium oscillator or GPS receiver • Current implementations are primarily software-based. Non-deterministic delays in networking stacks contribute to significant timing inaccuracy
NTP overview • Network Time Protocol (NTP) synchronizes clocks of hosts and routers in the Internet • The NTP architecture, protocol and algorithms have been evolved over the last two decades. Currently NTP Version 4 is being developed • Well-tested and widely-deployed protocol • NIST estimates 10-20 million NTP servers and clients deployed in the Internet and its tributaries all over the world. Every Windows/XP has an NTP client • NTP provides nominal accuracies of low tens of milliseconds on WANs, submilliseconds on LANs, and submicroseconds using a precision time source such as a cesium oscillator or GPS receiver • Current implementations are primarily software-based. Non-deterministic delays in networking stacks contribute to significant timing inaccuracy 39
NTP Stratum Levels • Hierarchical layering of clocks based on number of hops from primary reference source • Stratum 1 servers are synchronized with a GPS source • Stratum 2 servers use client/server mode to synchronize with up to six Stratum 1 servers and symmetric mode to synchronize with other servers on the same stratum level • Stratum 4 clocks work in client mode to synchronize with servers in Stratum 3 Stratum 1 S1 S1 Stratum 2 S2 S2 S2 S2 Stratum 3 S3 S3 S3 S3 S3 Stratum 4 S4 S4 S4 S4 NTP Stratum levels are not the same as ITU-T Stratum levels! Next Generation Network Services require ITU-T Stratum level synchronization 40
NTP Protocol Overview Client Server • Clock offset: • [(T2 – T1) + (T4 – T3)] / 2 • Round-trip delay: • (T4 – T1) – (T3 – T2) Client sends request at T1 = 10:15:00 T1 Server receives request at T2 = 10:15:12 T2 Server sends response at T2 = 10:15:15 T3 Client receives response at T2 = 10:15:30 T4 • Key Assumptions: • Network delay is symmetric in both directions • One-way delay is half of round-trip delay • Client and server clocks drift at the same rate
NTP Protocol Overview Clock offset: [(T2 – T1) + (T4 – T3)] / 2 (2 + 4) / 2 = 3 seconds Round-trip delay: (T4 – T1) – (T3 – T2) 19 – 3 = 16 seconds Client Server Client sends request at T1 = 10:15:00 T1 Server receives request at T2 = 10:15:12 T2 Server sends response at T2 = 10:15:15 T3 Client receives response at T2 = 10:15:19 T4 Key Assumptions: • Network delay is symmetric in both directions • One-way delay is half of round-trip delay • Client and server clocks drift at the same rate 42
IEEE 1588 (commonly known as Precision Time Protocol, PTP) was ratified as a standard in September 2002 Provides timing for the control of distributed applications Version 1 of the protocol used for applications in Industrial automation Test and measurement Electric power Military Residential (Audio-Video Bridging) Version 2 developed for telecom applications Early adopters include Vodafone, T-Mobile, etc. IEEE1588 Overview 43
Enhancements to IEEE 1588v2 • IEEE 1588v2 meets accuracy requirements for Telecom applications • High refresh rates up to 64 messages per second • Correction field for asymmetric measurements • Several modes supported • Broad-cast, Multi-cast and Uni-cast are permitted • Smaller message length to conserve bandwidth – 72 octets (44 for 1588v2 payload) • Multiple Master Clock selection methods • Manual, Semi-automatic, Fully-automatic • Transparent Clocks to reduce accumulation of timing errors across network elements in cascaded topologies • Enhanced security • Configurable network in combination with Best Master Clock algorithm for GrandMaster • HASH codes 44
IEEE1588 Protocol Overview • The Slave collects the time values t1, t2, t3, t4 during a transaction and calculates final offset (o) between Master and Slave clocks canceling out network delay (d) as follows: t2 –t1 = o + d t4 - t3 = -o + d o = (t2 + t3 – t1 – t4) / 2 d = (t2 – t1 + t4 – t3) / 2
Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time PTP overview - Sync PTP PTP 1001 SYNC UDP UDP 1001 SYNC IP IP 1001 SYNC MAC MAC 1001 SYNC MII MII PHY PHY Master Slave Sent at 1001 s Received at 1015 s 1015 1003 Tm = 1000s Ts = 1010s 1001: SYNC 1015: SYNC 46
PTP overview – Follow Up PTP PTP 1003 FOLLOW UP UDP UDP 1003 FOLLOW UP IP IP 1003 FOLLOW UP MAC MAC 1003 FOLLOW UP MII MII PHY PHY Master Slave Sent at 1004 s Received at 1018 s Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e. 1003 seconds 1018 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 1018: FOLLOW UP 47
PTP overview – Delay Request PTP PTP 1009 DELAY REQ UDP UDP 1009 DELAY REQ IP IP 1009 DELAY REQ MAC MAC 1009 DELAY REQ MII MII PHY PHY Master Slave Received at 1013 s Sent at 1009 s Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e. 1003 seconds Slave tries to determine unknown line delay by sending a ‘DELAY REQ’ message to the master 1010 1012 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 1018: FOLLOW UP 1010: DELAY REQ 1012: DELAY REQ 48
PTP overview – Delay Response PTP PTP 1012 DELAY RESP UDP UDP 1012 DELAY RESP IP IP 1012 DELAY RESP MAC MAC 1012 DELAY RESP MII MII PHY PHY Master Slave Sent at 1014 s Received at 1018 s Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e. 1003 seconds Slave tries to determine unknown line delay by sending a ‘DELAY REQ’ message to the master Master responds with ‘DELAY RESP’ message containing timestamp when ‘DELAY REQ’ was received Slave calculates average delay by assuming symmetric path and dividing total delay by 2 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 1018: FOLLOW UP 1009: DELAY REQ 1013: DELAY REQ Line delay = ((1012 – 1009) + (1006 – 1003)) / 2 = 3 seconds Slave time = 1015 – 3 = 1012 seconds 1012: DELAY RESP 1015: DELAY RESP 49
Boundary clock PTP PTP PTP PTP UDP UDP UDP UDP IP IP IP IP MAC MAC MAC MAC MII MII MII MII PHY PHY PHY PHY Boundary Clock S M A Boundary Clock extends synchronization across an intermediate network element S M S M IP Network Grandmaster Slave Boundary Clock Grandmaster Boundary Clock Slave • A boundary clock contains more than one PTP port: • a slave port that is synchronized with a remote master, and • a master port that synchronizes other slaves downstream • Synchronization messages are terminated at each port and not forwarded Slave Master 50