PTP Primer for the Cable Dummies

Transcription

1 PTP Primer for the Cable Dummies Contents Introduction Prerequisites Requirements Components Used PTP Protocol PTP GrandMaster PTP Slave PTP Boundary Clock PTP Clock Classes PTP states PTP domain Basic PTP messages definition Configuration on the Master Configuring the local internal oscillator Verification Configuration on the Slave(cBR8) Verification of the proper configuration and behaviour of a Slave (cbr8) Configuration on the Slave (RPD) Verification of the proper configuration and behaviour of a Slave (RPD) Troubleshoot Troubleshoot the PTP master Troubleshoot the PTP slave (cbr8) DTI and PTP Troubleshoot the PTP slave (RPD) Related Information Introduction This document describes the Precision Time Protocol (PTP) which is use in cable network with cbr8 and RPHY networks. The goal is to give a global understanding of the protocol and how to configure it in cbr8/rphy deployments. Contributed by Tristan Van Egroo, Cisco TAC Engineer, edited by Waqas Daar, Cisco TAC Engineer. Prerequisites Requirements Cisco recommends that you have knowledge of these topics:

2 Remote PHY cbr8 Components Used This document is restricted to following software and hardware versions. cbr8 is running release or later. Cisco 1x2 RPD Tip: Refer the Cisco 1x2 RPD cisco article for more information. PTP Protocol PTP is defined under IEEE standard The full specifications are available here: Note: You need to have registered users in order to get the full access to the document. PTP allows to distribute Time and Frequency through a network: Time (Synchronization): Syncs the time between devices in a network Frequency (Syntonization): Syncs the frequency PTP uses either multicast or unicast and ports UDP 319 (For events) and UDP 320 (For general) messages On CMTS implementation, PTP uses IPv4 unicast. The protocol creates a Master-Slave relationship between a Grandmaster clock and client devices through the network. The way PTP elects a clock to be distributed in a network is using an algorithm called the Best Master Clock Algorithm (BCMA). The algorithm determine the best clock in a network using these properties: Identifier (Number, constructed from the MAC-Address of the device, typically looks like the EUI-64 format (xxxx:xxff:fexx:xxxx)) Quality clockaccuracy: Determines how accurate is the clock.the lower the better (the more accurate) Value (hex) Specification 00-1F Reserved 20 The time is accurate to within 25 ns 21 The time is accurate to within 100 ns 22 The time is accurate to within 250 ns 23 The time is accurate to within 1 µs 24 The time is accurate to within 2.5 µs 25 The time is accurate to within 10 µs 26 The time is accurate to within 25 µs

3 27 The time is accurate to within 100 µs 28 The time is accurate to within 250 µs 29 The time is accurate to within 1 ms 2A The time is accurate to within 2.5 ms 2B The time is accurate to within 10 ms 2C The time is accurate to within 25 ms 2D The time is accurate to within 100 ms 2E The time is accurate to within 250 ms 2F The time is accurate to within 1 s 30 The time is accurate to within 10 s 31 The time is accurate to >10 s 32 7F Reserved 80 FD For use by alternate PTP profiles FE Unknown FF Reserved clockclass:reflect the tracability of the time and frequency distributed by the GrandMaster clock.clock classes are defined by the IEEE specifications as such: clockclass (decimal) Specification 0 Reserved to enable compatibility with future versions. 1 5 Reserved. 6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be PTP. A clockclass 6 clock shall not be a slave to another clock in the domain. 7 Shall designate a clock that has previously been designated as clockclass 6 but that has lost the ability to synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The timescale distributed shall be PTP. A clockclass 7 clock shall not be a slave to another clock in the domain. 8 Reserved Reserved to enable compatibility with future versions Reserved. 13 Shall designate a clock that is synchronized to an application-specific source of time. The timescale distributed shall be ARB. A clockclass 13 clock shall not be a slave to another clock in the domain. 14 Shall designate a clock that has previously been designated as clockclass 13 but that has lost the ability to synchronize to an application-specific source of time and is in holdover mode and within holdover specifications. The timescale distributed shall be ARB. A clockclass 14 clock shall not be a slave to another clock in the domain Reserved. 52 Degradation alternative A for a clock of clockclass 7 that is not within holdover specification. A clock of clockclass 52 shall not be a slave to another clock in the domain Reserved. 58 Degradation alternative A for a clock of clockclass 14 that is not within holdover specification. A clock of clockclass 58 shall not be a slave to another clock in the domain Reserved For use by alternate PTP profiles Reserved Reserved For use by alternate PTP profiles Reserved. 187 Degradation alternative B for a clock of clockclass 7 that is not within holdover specification. A clock of clockclass 187 may be a slave to another clock in the domain Reserved. 193 Degradation alternative B for a clock of clockclass 14 that is not within holdover specification. A clock of clockclass 193 may be a slave to another clock in the domain Reserved For use by alternate PTP profiles Reserved. 248 Default. This clockclass shall be used if none of the other clockclass definitions apply Reserved. 251 Reserved for version 1 compatibility; see Clause Reserved.

4 255 Shall be the clockclass of a slave-only clock; see Priority - An administratively assigned value (Between 0-255) Variance - The clock's estimated stability PTP GrandMaster The GrandMaster communicates with the slaves who established sessions with the grandmaster in order to exchange the synchronization (Time) and syntonization information to those slaves. a GrandMaster must in theory be connected to a PRTC (Prime Reference Time clock), such as GPS through a GPS antenna, this way, if a GrandMaster fails and an other GrandMaster takes over, since both are using the same time reference, the slaves will keep on using the same time reference. If not using a PRTC, the failure of a GrandMaster clock will cause the slaves to change the time reference, causing, in CMTS scenarios, the modems to go offline. PTP Slave The Slave initiates the connection to the GrandMaster clock. Both slave and master will exchange their configuration settings and clock settings in order to start the negotiation In our case, cbr8 and RPD will both be slave to an external PTP GrandMaster. Warning: Current cbr8 deployment (as of ) supports only cbr8 as PTP slave. In the future, we might see PTP boundary or PTP master. PTP Boundary Clock Boundary clock synchronize 2 network segments together. Acts as a slave to a GM clock on segment 1 and then acts as a GM clock on segment 2. Non boundary clocks are referred to as 'ordinary clocks'. PTP Clock Classes Clock classes are one of the values used during negotiation to find which clock, in a network with multiple clocks is the most accurate. Clock classes are defined by IEEE , see list above PTP states FREERUN : Not connected to any remote GM, using local oscillator HOLDOVER : Lost connection to a remote GM, attempt to recover it, and try to keep the previous clock. During the HOLDOVER state, the clock may start drifting, and if drifting outside of specifications, it will go back to FREERUN mode. ACQUIRING : Started negotiation with GM, and exchanging messages with the GM to determine the delay induced by the network and trying to sync with the GM clock. FREQ_LOCKED : Slave device is locked to the Master with respect to frequency, but not phase aligned

5 PHASE_ALIGNED : Locked to the master with respect to frequency and phase PTP domain PTP domain is a number identifying a group of devices that talk together. Slave and master devices must be within the same PTP domain to be able to sync with each other. Domain 0 is the default domain and domains are reserved per specifications. Other domain numbers can be 4-255, Note that some PTP variants such as G requires the PTP domain to be within range 44-63, hence if you are not using this variant, avoid using this range of PTP domains, as this might confuse both the user and the device. Additional info on G can be found on the following URL: Basic PTP messages definition Sync, Follow_up, Delay_req, Delay_resp are messages used by boundary and ordinary clocks to communicate time information to slaves across the network. Announce messages are exchanged by both slaves and master to identify the best clock in the network using the Best Master Clock Algorithm. Tip: Please refer the Figures 26,27,28 from the IEEE specifications for the detailed mechanism. Signalling messages are used for non time-critical information Configuration on the Master The recommendation from BU is to use an ASR900 to work as PTP Master, but third party PTP Grand masters are supported, if hardware based, such as Adva or IGM. There is a Software base implementation of the PTP protocol, on Linux, called ptpd. However, since software based, it does not offer enough precision for the cbr8 and RPD to work with it, therefore, the modems won't be able to come online and the PTP synchronization won't happened either. Moreover, the PTPd linux implementation requires hardware timestamping by the NIC in order to increase accuracy. This means that when using a Virtual Machine or a NIC which does not support hardware timestamping, PTPd might not even start at all on Linux. Depending the model of ASR900 in use, it may or may not have a GPS antenna. If the ASR900 does not have a GPS antenna, we will not have PRTC, but we will still be able to run the ASR900 as Grandmaster with a local PRTC (internal oscillator). This means that if this ASR900 fails and that an other ASR900 takes over, the cbr8 and RPD will lose the time reference.

6 Configuring the local internal oscillator network-clock source quality-level QL-PRC tx network-clock synchronization automatic network-clock synchronization mode QL-enabled network-clock synchronization squelch-threshold QL-PRC network-clock quality-level tx QL-PRC ptp domain 0 network-clock input-source 1 External R0 10m Then, once the internal oscillator is configured properly, we can configure PTP as master on the ASR900: ptp clock ordinary domain 0 clock-port MASTER master sync one-step transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface interface Loopback1588 ip address end Note: If there is no local oscillator or GPS configured as source, the PTP mode master won't be available Verification This section provides information that you can use in order to verify that your configuration works properly. ptp clock ordinary domain 0 clock-port MASTER master sync one-step transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface interface Loopback1588 ip address end Note: During the first configuration of internal oscillator, the oscillator needs to warm-up before to be stable. Therefore, it might take a while before the state of the PTP is FREQ_LOCKED. This may take up to 35 minutes. ptp clock ordinary domain 0 clock-port MASTER master sync one-step transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface interface Loopback1588 ip address end Note: By default, the ASR900 will report being class 58 when using internal oscillator. If

7 using a third party GM clock, you may see clock class 6 as well. Configuration on the Slave(cBR8) ptp clock ordinary domain 0 servo tracking-type R-DTI clock-port TOMASTER slave announce interval -3 announce timeout 10 delay-req interval -5 transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface clock source <<< THIS IS OUR PTP MASTER Verification of the proper configuration and behaviour of a Slave (cbr8) ptp clock ordinary domain 0 servo tracking-type R-DTI clock-port TOMASTER slave announce interval -3 announce timeout 10 delay-req interval -5 transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface clock source <<< THIS IS OUR PTP MASTER Configuration on the Slave (RPD) Despite this being the RPD configuration, this needs to be entered on the cbr8 itself, since the cbr8 will provision the Remote Phy Device. ptp r-dti 1 ptp-domain 0 clock-port 1 clock source ip announce interval -3 <-- THIS IS OUR PTP MASTER Note: The intervals for sync and announce are specified in log2 scale. ptp r-dti 1 ptp-domain 0 clock-port 1 clock source ip announce interval -3 <-- THIS IS OUR PTP MASTER Verification of the proper configuration and behaviour of a Slave (RPD) [root@acdc-tools ~]# ssh l admin R-PHY>ena R-PHY#show ptp clock 0 state apr state : PHASE_LOCK

8 clock state : SUB_SYNC current tod : Tue Sep 26 09:45: active stream : 0 ==stream 0 : port id : 0 master ip : stream state : PHASE_LOCK Master offset : 1212 Path delay : Forward delay : Reverse delay : Freq offset : Hz offset : -615 PHASE_LOCK is the correct state when everything is working. Note: See PTP state section for other states and their definition. Troubleshoot This section provides information that you can use in order to troubleshoot your configuration. Troubleshoot the PTP master On the master, the most important thing is to ensure that PTP has a network-clock source for the clocking, either a GPS antenna (preferred), or a local oscillator. In order to ensure the network-clock source is working as expected, you can use the command: bragi#show network-clocks synchronization Symbols: En - Enable, Dis - Disable, Adis - Admin Disable NA - Not Applicable * - Synchronization source selected # - Synchronization source force selected & - Synchronization source manually switched Automatic selection process : Enable Equipment Clock : 2048 (EEC-Option1) Clock Mode : QL-Enable ESMC : Enabled SSM Option : 1 T0 : Internal Hold-off (global) : 300 ms Wait-to-restore (global) : 300 sec Tsm Delay : 180 ms Revertive : No Nominated Interfaces Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx *Internal NA NA/Dis 251 QL-SEC NA NA External R0 10M NA/Dis 1 QL-FAILED NA NA Gi0/2/5 NA Sync/En 1 QL-FAILED QL-PRC - Troubleshoot the PTP slave (cbr8) On the cbr8 acting as slave, what's important to note is that the cbr8 only support, as of now,

9 the SUP DPIC interfaces to connect to the PTP master, hence don't use the Gig0 interface or the RPHY PIC interfaces, as PTP might not work through those interfaces. Note: Refer the Cisco Remote PHY Device Software Configuration Guide for more information. During inital PTP negotiation, it may take up to 35 minutes for the cbr8 to adjust and align its clock to the clock of the PTP master. During that time, the clock will be seen in ACQUIRING state on the cbr8: ACDC-cBR8-2#show ptp clock running PTP Ordinary Clock [Domain 0] State Ports Pkts sent Pkts rcvd Redundancy Mode ACQUIRING Hot standby PORT SUMMARY PTP Master Name Tx Mode Role Transport State Sessions Port Addr TOMASTER unicast slave Lo1588 Uncalibrated If the ACQUIRING state remains there for longer than 35 minutes, it might indicate that the PTP master clock is not very accurate and drifts back and forth which causes the cbr not to be able to ACQUIRE properly. This might be seen when using a Linux server with PTPd for example. DTI and PTP In order to configure PTP, cable clock DTI must be DISABLED, otherwise, the following error message will appear: ACDC-cBR8-2#show ptp clock running PTP Ordinary Clock [Domain 0] State Ports Pkts sent Pkts rcvd Redundancy Mode ACQUIRING Hot standby PORT SUMMARY PTP Master Name Tx Mode Role Transport State Sessions Port Addr TOMASTER unicast slave Lo1588 Uncalibrated Troubleshoot the PTP slave (RPD) On the RPD, all the interesting commands are under the show ptp umbrella: R-PHY#show ptp clock 0 state apr state : PHASE_LOCK clock state : SUB_SYNC current tod : Tue Sep 26 11:45: active stream : 0 ==stream 0 : port id : 0

10 master ip : stream state : PHASE_LOCK Master offset : 6010 Path delay : Forward delay : Reverse delay : Freq offset : Hz offset : -830 R-PHY#show ptp clock 0 statistics AprState 6 : 2@0-00:14: @0-00:14: @0-00:06: @0-00:06: @0-00:03: @0-00:03: ClockState 5 : 5@0-00:06: @0-00:06: @0-00:06: @0-00:06: @0-00:06: BstPktStrm 3 : 0@0-00:14: @0-00:14: @0-00:06: StepTime 1 : @0-00:05: AdjustTime 99 : 427@0-02:05: @0-02:04: @0-02:03: @0-02:02: @0-02:00: @0-01:58: @0-01:57: @0-01:56: @0-01:55: streamid msgtype rx rxprocessed lost tx 0 SYNC DELAY REQUEST P-DELAY REQUEST P-DELAY RESPONSE FOLLOW UP DELAY RESPONSE P-DELAY FOLLOWUP ANNOUNCE SIGNALING MANAGEMENT TOTAL R-PHY#show ptp clock 0 config Domain/Mode : 0/OC_SLAVE Priority 1/2/local : 128/255/128 Profile : 001b E2E Total Ports/Streams : 1 /1 --PTP Port 1, Enet Port Port local Address : Unicast Duration :300 Sync Interval : -5 Announce Interval : -3 Timeout : 11 Delay-Req Intreval : -4 Pdelay-req : -4 Priority local :128 COS: 6 DSCP: 47 ==Stream 0 : Port 1 Master IP: There are additional files under the linux shell of the RPD which are useful to understand what happened regarding PTP on the RPD, as those contain some history on the past events. R-PHY#shell (Requires challenge password to access the shell) root@rpd2cabeb9a775a:/# cd tmp/ root@rpd2cabeb9a775a:/tmp# ls -lt grep ptp -rw-r--r-- 1 root root Sep 1 10:17 provision_ptp.log -rw-r--r-- 1 root root 5944 Sep 1 10:17 hal_ptp_driver.log root@rpd2cabeb9a775a:/tmp# cat provision_ptp.log root@rpd2cabeb9a775a:/tmp# cat hal_ptp_driver.log

11 cd trace/ ls -lt grep rw-r--r-- 1 root root Sep 1 11: _trace.log root@rpd2cabeb9a775a:/tmp/trace# cat 1588_trace.log Related Information /b_docsis_cbr_full_book_xe16_5_chapter_011.html#concept_hhk_rsl_jz