6.1.1.1. System Name

The system name is the MIB II (RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)) sysName object. By convention, this text string is the node’s fully qualified domain name. The system name can be any ASCII printable text string of up to 32 characters.

6.1.1.2. System Contact

The system contact is the MIB II sysContact object. By convention, this text string is a textual identification of the contact person for this managed node, together with information on how to contact this person.The system contact can be any ASCII printable text string of up to 80 characters.

6.1.1.3. System Location

The system location is the MIB II sysLocation object, which is a text string conventionally used to describe the node’s physical location; for example, “Bldg MV-11, 1st Floor, Room 101”. The system location can be any ASCII printable text string of up to 80 characters.

6.1.1.4. System Coordinates

The Nokia Chassis MIB tmnxChassisCoordinates object defines the system coordinates. This text string indicates the Global Navigation Satellite System (GNSS) coordinates of the location of the chassis.

Two-dimensional GNSS positioning offers latitude and longitude information as a four-dimensional vector:

(direction, hours, minutes, seconds)

where:

direction is one of the four basic values: N, S, W, E

hours range from 0 to 180 (for latitude) and 0 to 90 (for longitude)

minutes and seconds range from 0 to 60

<W, 122, 56, 89> is an example of longitude and <N, 85, 66, 43> is an example of latitude.

System coordinates can be expressed in different notations; for example:

The system coordinates can be any ASCII printable text string up to 80 characters.

6.1.1.5. Common Language Location Identifier

A Common Language Location Identifier (CLLI) code string for the device is an 11-character standardized geographic identifier that uniquely identifies the geographic location of places and certain functional categories of equipment unique to the telecommunications industry. The CLLI code is stored in the Nokia Chassis MIB tmnxChassisCLLICode object.

The CLLI code can be any ASCII printable text string of up to 11 characters.

6.1.1.6. System Identifier

A system identifier is a manually configured IPv4 address that can be used to uniquely identify the 7705 SAR in the network in situations where the more commonly used system IP address may change dynamically, causing loss of historical data attributed to the node. For example, the system IP address can change dynamically using DHCP when the 7705 SAR is acting as a DHCP client and the DHCP server-facing interface is unnumbered. In this situation, a static system identifier may be desirable.

The system identifier can be any IPv4 address.

6.1.1.7. PoE Power Source

The 7705 SAR-H supports Power over Ethernet (PoE) on all four 10/100/1000 copper Ethernet ports. To use PoE, the PoE power source must be configured at the system level as either internal or external. When the system is configured for the internal PoE power source option, PoE capability can be enabled on ports 5 and 6 only. In addition, port 5 can be enabled for PoE+ but in that case, port 6 cannot support any PoE capability. When the system is configured for the external PoE power source option, a mix of PoE and PoE+ is available on ports 5, 6, 7, and 8. Refer to the 7705 SAR-H Chassis Installation Guide, “Ethernet Ports”, for information about supported combinations of PoE and PoE+.

To enable PoE or PoE+ on a PoE-capable port on the 7705 SAR-H, use the config>port>ethernet>poe command; refer to the 7705 SAR Interface Configuration Guide, “Configuration Command Reference”, for more information.

The PoE-capable ports on the 7705 SAR-H act as a Power Source Equipment (PSE) device. They support IEEE 802.3at and IEEE 802.3af.

The 7705 SAR-W supports PoE+ on the two RJ-45 Ethernet ports with PoE+. The 7705 SAR-Wx (variants 3HE07616AA and 3HE07617AA) supports PoE+ on the RJ-45 Ethernet port with PoE+. The PoE+ ports are used to deliver power to a “Powered Device”, such as a non-line-of-sight (NLOS) or line-of-sight (LOS) microwave radio, at levels compatible with the IEEE 802.3at standard.

To enable PoE+ on a PoE+-capable port on the 7705 SAR-W or 7705 SAR-Wx, use the config>port>ethernet>poe plus command; refer to the 7705 SAR Interface Configuration Guide, “Configuration Command Reference”, for more information.

6.1.2.1. Time Zones

Setting a time zone in the 7705 SAR allows for times to be displayed in the local time rather than in UTC. The 7705 SAR has both user-defined and system-defined time zones.

A user-defined time zone has a user-assigned name of up to four printable ASCII characters that is different from the system-defined time zones. For user-defined time zones, the offset from UTC is configured as well as any summer time adjustment for the time zone.

The 7705 SAR system-defined time zones are listed in Table 25, which includes both time zones with and without summer time correction.

6.1.2.2. NTP

NTP is the Network Time Protocol defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis and RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification. It allows for the participating network nodes to keep time more accurately and maintain time in a more synchronized fashion among all participating network nodes.

NTP uses stratum levels to define the number of hops from a reference clock. The reference clock is considered to be a Stratum-0 device that is assumed to be accurate with little or no delay. Stratum-0 servers cannot be used in a network. However, they can be directly connected to devices that operate as Stratum-1 servers. A Stratum-1 server is an NTP server with a directly connected device that provides Coordinated Universal Time (UTC), such as a GNSS or atomic clock.

The higher stratum levels are separated from the Stratum-1 server over a network path; thus a Stratum-2 server receives its time over a network link from a Stratum-1 server. A Stratum-3 server receives its time over a network link from a Stratum-2 server.

The 7705 SAR runs a single NTP clock that operates NTP message exchanges with external NTP clocks. Exchanges can be made with external NTP clients, servers, and peers. These exchanges can be through the base, management, or VPRN routing instances.

When NTP is enabled, the NTP clock in the 7705 SAR operates as an NTP client by default. The 7705 SAR typically operates as a Stratum-2 device, relying on an external Stratum-1 server to source accurate time into the network.

Alternatively, the NTP clock in the 7705 SAR can recover time from a local PTP or GNSS source. This is achieved by configuring the PTP clock or GNSS receiver as the internal system time. The internal system time can then be identified as the preferred source of NTP timing into the network with the command config>system>time>ntp>server>system-time>prefer. This configuration makes the local PTP or GNSS source appear as a Stratum-0 server. When the internal PTP clock or GNSS is identified as the server for NTP, NTP will promote the internal NTP server (the 7705 SAR) to Stratum-1 level, which may affect the NTP network topology.

The 7705 SAR can also operate as an NTP server and provide timing to downstream clients with the ntp-server command. When the NTP server is enabled with authentication, any NTP clients must authenticate using the proper key.

In server mode, the 7705 SAR advertises the ability to act as a clock source for other network elements. By default, the router transmits NTP packets in NTP version 4 mode. Server mode is supported on the CSM Management port, in the base routing context, and in the VPRN routing context.

As an NTP server, the 7705 SAR can peer with an external NTP server in another router that is considered more trustworthy or accurate than other routers carrying NTP in the system. This allows the peers to act as mutual backups where they can obtain time from or supply time to the other server as required. If both servers are peering each other, the router is in symmetric active mode. This mode requires that the peer association is set on both routers so that the local and remote router designate each other as a peer. If only one server is peering the other (that is, the other peer has not specifically configured the peer association), the router is in symmetric passive mode.

The 7705 SAR can be configured to transmit broadcast NTP packets on a specified interface with the broadcast command. The interface can be the management interface, interfaces in the base routing context, or an interface in the VPRN context. The messages are transmitted using a destination address that is the NTP broadcast address. Only IPv4 addressing is supported.

The 7705 SAR can also be configured to receive broadcast NTP packets on interfaces in the base routing context or on the management interface with the broadcastclient command.

The router can be configured to transmit or receive multicast NTP packets on the CSM Management port. The multicast command configures the transmission of NTP multicast messages. The multicastclient command configures the receipt of multicast NTP packets. When receiving or sending multicast NTP messages, the default address 224.0.1.1 is used. Only IPv4 addressing is supported.

The following NTP elements are supported:

NTP accuracy depends on the accuracy of NTP packet timestamping. By default, NTP packets are timestamped by the CSM where the NTP protocol is executed. However, an enhanced NTP mode is available where the timestamping is performed on the adapter card by the network processor. This reduces variations introduced by packet delay within the router as well as by a busy CPU in the CSM. This enhanced mode is only available for in-band NTP over a network interface. When enhanced NTP mode is used, NTP authentication is not supported.

6.1.2.3. SNTP Time Synchronization

For synchronizing the system clock with outside time sources, the 7705 SAR includes a Simple Network Time Protocol (SNTP) client. As defined in RFC 2030, SNTP Version 4 is an adaptation of the Network Time Protocol (NTP). SNTP typically provides time accuracy within 100 ms of the time source. SNTP can only receive the time from NTP servers; it cannot be used to provide time services to other systems. SNTP is a compact, client-only version of NTP. SNTP does not authenticate traffic.

SNTP can be configured in both unicast client modes (point-to-point) and broadcast client modes (point-to-multipoint). SNTP should be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the highest stratum (leaves) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP time servers should operate only at the root (Stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio clock is available.

The 7705 SAR SNTP client can be configured for either broadcast or unicast client mode.

6.1.2.4. PTP

Precision Time Protocol (PTP) is a timing-over-packet protocol defined in the IEEE 1588v2 standard 1588 2008.

PTP provides the capability to synchronize network elements to a Stratum-1 clock or primary reference clock (PRC) traceable source over a network that may or may not be PTP-aware. PTP has several advantages over ACR. It is a standards-based protocol, has lower bandwidth requirements, can transport both frequency and time, and can potentially provide better performance.

For more information about PTP, see IEEE 1588v2 PTP.

6.1.2.5. Time-of-Day Measurement (ToD-1pps)

The 7705 SAR can receive and extract time of day/phase recovery from a 1588 grand master clock or boundary clock and transmit the recovered time of day/phase signal to an external device such as a base station through an external time of day port, where available. Transmission is through the ToD or ToD/PPS Out port with a 1 pulse/s output signal. The port interface communicates the exact time of day by the rising edge of the 1 pulse/s signal.

For more information about ToD-1pps, see PTP Ordinary Slave Clock for Time of Day/Phase Recovery.

6.1.2.6. GNSS

The 7705 SAR supports frequency synchronization via a Layer 1 interface such as synchronous Ethernet, and ToD synchronization via a protocol such as NTP or PTP. In cases where these methods are not possible, or where accuracy cannot be ensured for the service, you can deploy a GNSS receiver as a synchronous timing source. GNSS data is used to provide network-independent frequency and ToD synchronization.

GNSS receivers on the following platforms support GPS reference only, or combined GPS and GLONASS reference:

A 7705 SAR chassis equipped with a GNSS receiver and an attached GNSS antenna can be configured to receive frequency traceable to Stratum-1 (PRC/PRS). The GNSS receiver provides a synchronization clock to the SSU in the router with the corresponding QL for SSM. This frequency can then be distributed to the rest of the router from the SSU as configured with the ref-order and ql-selection commands. The GNSS reference is qualified only if the GNSS receiver is operational, has five or more satellites locked, and has a frequency successfully recovered. A PTP master/boundary clock can also use this frequency reference with PTP peers.

In the event of GNSS signal loss or jamming resulting in the unavailability of timing information, the GNSS receiver automatically prevents output of clock or synchronization data to the system, and the system can revert to alternate timing sources.

6.1.2.7. CRON

On the 7705 SAR, the CRON feature supports periodic and date- and time-based scheduling. CRON can be used, for example, to schedule Service Assurance Agent (SAA) functions. CRON functions include the ability to specify scripts that need to be run and when they will be scheduled. Reboots, peer turn-ups, and SAA tests can be scheduled with CRON, as well as OAM events such as connectivity checks or troubleshooting runs.

CRON supports the schedule function. The schedule function is used to configure the type of schedule to run, including one-time-only (one-shot), periodic, or calendar-based runs. All runs are scheduled by month, day, hour, minute, and interval (seconds).

Scripts that have been configured under the config>system>script-control context are referenced by the CRON schedule. For information on scripts, see CLI Script Control.

6.2.1.1. Redundancy

The following redundancy features enable the duplication of data elements and software functionality to maintain service continuation in case of outages or component failure.

6.2.1.1.5. Multi-Chassis LAG Redundancy

Multi-chassis LAG (MC-LAG) prevents service interruptions that are caused by 7705 SAR nodes that are taken out of service for maintenance, upgrades, or relocation. MC-LAG also provides redundancy for incidents of peer nodal failure. This improves network resiliency. When typically used at access or aggregation sites, MC-LAG ensures high availability without service disruptions by providing redundant access or aggregation nodes.

MC-LAG extends the link level redundancy provided by LAG to include protection against failure of a 7705 SAR node. With MC-LAG, a CE device can be connected to two redundant-pair peer nodes. The redundant-pair peer nodes act like a single node, using active/standby signaling to ensure that only one peer node is used at a time. The redundant-pair peer nodes appear to be a single system as they share the same MAC address and system priority when implementing MC-LAG. Availability and status information are exchanged through an MC-LAG Control Protocol (MCCP). It is used to ensure that one peer is active and to synchronize information between the peers.

Note: The 7705 SAR nodes must be of the same type, except for the 7705 SAR-8 Shelf V2 and 7705 SAR-18, which can be used together in a redundant-pair configuration.

A peer is configured by specifying its IP address, to which the MCCP packets are sent. The LAG ID, system priority, and MAC address for the MC-LAG are also configured under the peer. Up to 16 MC-LAGs can be configured and they can either use the same peer or different peers up to a maximum of 4 peers.

It is possible to specify the remote LAG ID in the MC-LAG lag command to allow the local and remote LAG IDs to be different on the peers. If there are two existing nodes which already have LAG IDs that do not match, and an MC-LAG is to be created using these nodes, then the remote LAG ID must be specified so that the matching MC-LAG group can be found. If no matching MC-LAG group can be found between neighbor systems, the individual LAGs will operate as usual and no MC-LAG operation is established.

Two timer options, keep-alive-interval and hold-on-neighbor-failure, are available in the MC-LAG configuration. The keep-alive-interval option specifies the frequency of the messages expected to be received from the remote peer and is used to determine if the remote peer is still active. If hold-on-neighbor-failure messages are missed, then it is assumed that the remote peer is down.

Figure 10 shows an example of MC-LAG deployed at access and aggregation sites.

Figure 10:  MC-LAG at Access and Aggregation Sites 

Inter-Chassis Backup (ICB) spoke SDPs are supported for use with Epipe services in an MC-LAG configuration. ICB spoke SDPs provide resiliency by reducing packet loss when an active endpoint is switched from a failed node of an MC-LAG group to a standby node. For example, if a port on an active MC-LAG node fails, the port on one of the peers becomes active, but traffic continues to route to the previously active MC-LAG node until it detects the failure. ICB spoke SDPs ensure that in-flight packets are delivered to the newly active MC-LAG node. Two ICB spoke SDPs must be created. The ICB associated with the MC-LAG on the first node must be associated with the pseudowire on the second node. Likewise, the ICB associated with the MC-LAG on the second node must be associated with the pseudowire on the first node.

Note: A 7705 SAR node in an MC-LAG configuration that has an ICB spoke SDP configured on it with the MC-LAG in standby mode does not terminate Ethernet CFM frames. It transparently switches the frames to the other node of the MC-LAG group. This mode of operation is consistent with the 7705 SAR operating in S-PE mode.

Enabling the LAG slave-to-partner parameter ensures synchronized activity switching between the multi-chassis and the single-chassis endpoints. When multi-chassis endpoints are configured in slave-to-partner mode, multi-chassis endpoints always follow the single-chassis activity. The link that is promoted as active via the single-chassis endpoint is used as the active link. Enabling slave-to-partner ensures that out-of-sync scenarios do not occur for the LAG. A multi-chassis pair with pseudowire redundancy and ICBs is always able to direct traffic to the active endpoint, so enabling slave-to-partner does not impose any risk on the network side.

MC-LAG includes support for hash–based peer authentication, configurable heartbeat timers between peers, heartbeat multiplier, LAG bound to MC-LAG with LACP and support for any valid IP link between peers for the multi-chassis Control Protocol (MCCP). MC-LAG supports a configurable fault propagation delay and also provides an option to shut down a MEP on a standby endpoint.

MC-LAG maintains state across a CSM switchover event. The switchover event is transparent to peer MC-LAG nodes where sessions and state are preserved. MC-LAG is supported on the following platforms, adapter cards, and modules:

1. 8-port Ethernet Adapter card
2. 8-port Gigabit Ethernet Adapter card
3. 6-port Ethernet 10Gbps Adapter card
4. 10-port 1GigE/1-port 10GigE X-Adapter card (supported on the 7705 SAR-18 only)
5. Packet Microwave Adapter card
6. 6-port SAR-M Ethernet module
7. 7705 SAR-M (the port must be in access mode and autonegotiation must be off or limited)
8. 7705 SAR-X

Note: The 7705 SAR only supports MC-LAG for Epipes and VPLS.

6.2.1.2. Nonstop Routing (NSR)

With NSR on the 7705 SAR, routing neighbors are unaware of a routing process fault. If a fault occurs, a reliable and deterministic activity switch to the inactive control complex occurs such that routing topology and reachability are not affected, even in the presence of routing updates. NSR achieves high availability through parallelization by maintaining up-to-date routing state information, at all times, on the standby route processor. This capability is achieved independently of protocols or protocol extensions, providing a more robust solution than graceful restart protocols between network routers.

The NSR implementation on the 7705 SAR applies to all supported routing protocols. NSR makes it possible to keep the existing sessions (such as LDP) during a CSM switchover, including support for MPLS signaling protocols. Peers will not see any change.

Traditionally, high availability issues have been patched through non-stop forwarding solutions. NSR overcomes these limitations by delivering an intelligent hitless failover solution.

The following NSR entities remain intact after a switchover:

6.2.1.3. In-service Upgrade

In-service upgrades allow new routing engine software and microcode to be installed on the 7705 SAR while existing services continue to operate. Software upgrades can be performed only for certain maintenance releases (generally R4 loads and higher). Software upgrades also require NSR. If software or microcode on the CSM needs to be upgraded, CSM redundancy is required.

Note: The in-service upgrade requires the adapter cards to be reset. This will cause a short outage.

Follow the steps below to upgrade routing engine software on the 7705 SAR without affecting existing services:

6.2.1.4. CSM Switchover

During a switchover, system control and routing protocol execution are transferred from the active to the standby CSM. A switchover may occur automatically or manually.

An automatic switchover may occur under the following conditions:

Users can manually force the switchover from the active CSM to the standby CSM by using the admin redundancy force-switchover now CLI command or the admin reboot active [now] CLI command.

With the 7705 SAR, the admin reboot active [now] CLI command does not cause both CSMs to reboot.

6.2.1.5. Synchronization

Synchronization between the CSMs includes the following:

6.3.4.1. Saving Configurations

Whenever configuration changes are made, the modified configuration must be saved so that it will not be lost when the system is rebooted.

Configuration files are saved by executing explicit command syntax that includes the file URL location to save the configuration file as well as options to save both default and non-default configuration parameters. Boot options file (BOF) parameters specify where the system should search for configuration and image files as well as other operational parameters during system initialization.

For more information about the BOF, see the chapter on Boot Options in this guide.

6.3.4.2. Specifying Post-Boot Configuration Files

Two post-boot configuration extension files are supported and are triggered when either a successful or failed boot configuration file is processed. The boot-bad-exec and boot-good-exec commands specify URLs for the CLI scripts to be run following the completion of the boot-up configuration. A URL must be specified or no action is taken.

For example, after a configuration file is successfully loaded, the specified URL can contain a nearly identical configuration file with certain commands enabled or disabled, or particular parameters specified and according to the script which loads that file.

6.3.5.1. Boot-Env Option

The boot-env option enables a synchronization of all the files used in system initialization.

When configuring the system to perform this synchronization, the following occurs:

6.3.5.2. Config Option

The config option synchronizes configuration files by copying the files specified in the active CSM BOF file to the same compact flash on the standby CSM.

6.3.6.1. Forcing a Switchover

The force-switchover now command forces an immediate switchover to the standby CSM card.

If the active and standby CSMs are not synchronized for some reason, users can manually synchronize the standby CSM by rebooting the standby by issuing the admin reboot standby command on the active CSM.

6.4.3.1. ACR States

There are five potential ACR states:

When a port’s ACR state is normal, phase tracking, or frequency tracking, the recovered ACR clock is considered to be a qualified reference source for the SSU. If this reference source is being used, then transitions between any of these three states will not affect SSU operation.

When a port’s ACR state is free-run or holdover, the recovered ACR clock is disqualified as a reference source for the SSU. If this reference source is being used, then transitions to either of these two states cause the SSU to drop the reference and switch to the next highest prioritized reference source. This can potentially be SSU holdover.

6.4.3.2. ACR Statistics

The system collects statistics on all ACR-capable ports. ACR statistics detail how the digital phase locked loop (DPLL) is functioning in one or more ACR instances in the adapter card. ACR statistics assist with isolating a problem during degraded synchronization performance or with anticipating future issues.

Within the DPLL, there are two values that contribute to ACR statistics:

The DCO is the digitally controlled oscillator that produces the regenerated clock signal. The input phase error is the correction signal that provides feedback to the DPLL in order to tune the DCO output. The input phase error should approach zero as the DPLL locks in to the source timing information and stabilizes the output.

The continuous 2-second updates to the output DCO frequency are directly applied as the clock output of the ACR instance. ACR statistics allow you to view the mean frequency and the standard deviation of the output DCO frequency.

During every 2-second update interval, the input phase error and the output DCO frequency are recorded. The input phase error mean, input phase error standard deviation, output DCO mean (Hz and ppb), and output DCO standard deviation are calculated every 60 seconds.

Entering a show CLI command on a port with ACR displays the mean and standard deviation values for the previous 60-second interval. A show detail command on the same port displays the previous 15 sets of 60-second intervals and a list of state and event counts. An SNMP MIB is also available with these statistics.

6.4.4.1. DCR Frequencies

Each DS1, E1, DS3, or E3 circuit configured with DCR executes its own clock recovery from the packet stream. This allows each circuit to have an independent frequency.

Table 26 lists the supported timestamp frequencies for each platform and adapter card.

The timestamp frequency is configured at the adapter card level and is used by all DCR ports or channels on the supporting platforms and cards. Both ends of a TDM pseudowire using DCR must be running the same frequency. If a network contains different types of equipment using DCR, a common frequency must be selected that is supported by all equipment.

DCR complies with published jitter and wander specifications (G.823, G.824, and G.8261) for traffic interfaces under typical network conditions and for synchronous interfaces under specified packet network delay, loss, and delay variance (jitter) conditions.

6.4.7.1. Best Master Clock Algorithm

Each master clock has its own configuration for IP address, packet rate, and messaging timeouts, and for statistics, alarms, and events. Each available master clock advertises its presence and information using Announce messages. If both master clocks are available, the slave clock uses the Best Master Clock Algorithm (BMCA) to dynamically compare the information in the Announce messages of each master clock to determine to which of the two master clocks it should synchronize. This master clock is known as the best master. After the slave clock has determined which is the best master, it may begin to negotiate with it for unicast synchronization communication.

The configured setting for the profile command determines the precedence order for selecting the best master clock algorithm. The 7705 SAR supports the following profile settings: ieee1588-2008, itu-telecom-freq, g8275dot1-2014, g8275dot2-2016, iec-61850-9-3-2016, and c37dot238-2017. For information about the g8275dot1-2014 and g8275dot2-2016 profile parameters, see ITU-T G.8275.1 and G.8275.2. For information about the iec-61850-9-3-2016 and c37dot238-2017 profile parameters, see IEC/IEEE 61850-9-3 and C37.238-2017.

If the profile setting for the clock is ieee1588-2008, iec-61850-9-3-2016, or c37dot238-2017, the precedence order for the best master selection algorithm is as follows:

If the profile setting for the clock is itu-telecom-freq (ITU-T G.8265.1 profile), the precedence order for the best master selection algorithm is as follows:

If the profile setting for the clock is g8275dot1-2014 or g8275dot2-2016, the precedence order for the best master selection algorithm is as follows if the grand master clock is connected to a primary reference time clock (PRTC) in locked mode:

If the profile setting for the clock is g8275dot1-2014 or g8275dot2-2016, the precedence order for the best master selection algorithm is as follows if the grand master clock is in holdover and out of holdover specification, or is without a time reference since startup:

Figure 14 shows an example of the messaging sequence between the PTP slave clock and the two PTP master clocks.

Figure 14:  Messaging Sequence Between the PTP Slave Clock and PTP Master Clocks 

6.4.7.2. PTP Clock Synchronization

The IEEE 1588v2 standard synchronizes the frequency and time from a master clock to one or more slave clocks over a packet stream. This packet-based synchronization can be over UDP/IP or Ethernet and can be unicast (for IP) or multicast (for Ethernet). For UDP/IP, both IPv4 and IPv6 unicast mode with unicast negotiation is supported.

As part of the basic synchronization timing computation, a number of event messages are defined for synchronization messaging between the PTP slave clock and PTP master clock. A one-step or two-step synchronization operation can be used, with the two-step operation requiring a follow-up message after each synchronization message. Currently, only one-step operation is supported when the 7705 SAR is a master clock; PTP frequency and time can be recovered from both one-step and two-step operation when the 7705 SAR is acting as a slave or boundary clock.

For IPv4, the two-step operation is optional. For IPv6, the two-step operation is a mandatory requirement for the 7705 SAR.

Note: Two-step operation does not apply if PTP packets are routed over a physical port on the 7705 SAR-X or on the 6-port Ethernet 10Gbps Adapter card.

In one-step operation, a timestamp is inserted in the synchronization message when the packet is transmitted to the slave clock. In two-step operation, the timestamp is sent in the follow-up message. If the timestamp is changed in the synchronization message, the checksum field is recomputed. Because the checksum field is a mandatory field for IPv6 (optional for IPv4), the 7705 SAR requires the timestamp to be sent separately to avoid potential checksum corruption in the packet.

During startup, the PTP slave clock receives the synchronization messages from the PTP master clock before a network delay calculation is made. Prior to any delay calculation, the delay is assumed to be zero. A drift compensation is activated after a number of synchronization message intervals occur. The expected interval between the reception of synchronization messages is user-configurable.

The basic synchronization timing computation between the PTP slave clock and PTP best master is illustrated in Figure 15. This figure illustrates the offset of the slave clock referenced to the best master signal during startup.

Figure 15:  PTP Slave Clock and Master Clock Synchronization Timing Computation 

6.4.7.3. Performance Considerations

Although IEEE 1588v2 can be used on a network that is not PTP-aware, the use of PTP-aware network elements (boundary clocks) within the packet switched network improves synchronization performance by reducing the impact of PDV between the grand master clock and the slave clock.

Note: The grand master clock is the master clock for the network. The best master clock is the clock that the slave clock selects as its master. For example, the slave clock’s best master clock might be a boundary clock, which is connected to a grand master clock. A 7705 SAR equipped with a GNSS receiver can function as a grand master clock.

The performance objective is to meet the synchronization interface maximum time interval error (MTIE) mask. Similar to ACR, the number of factors with the PSN will contribute to how well PTP can withstand, and still meet, those requirements.

6.4.7.4. PTP Capabilities

PTP messages are supported via IPv4 unicast with a fixed IP header size or via IPv6.

PTP messaging is supported on network interfaces. If a node loopback address is used as the source interface for 1588 packets, the packets can ingress any network IP interface on the router. If the source interface is associated with a physical port, packets must be sent to the interface on that port.

PTP messaging is also supported on IES interfaces for access ports.

The 7705 SAR can also forward IPv4-encapsulated PTP messages over BGP-LU routes for frequency synchronization. The following profiles are supported for these messages: ieee1588-2008, itu-telecom-freq, and g8275dot2-2016.

Table 29 describes the supported message rates for slave and master states for IP-encapsulated PTP traffic, based on the profile configured. The ordinary clock can be either in the slave or master state. The boundary clock can be in both of these states.

See Table 32 for the supported message rates for Ethernet-encapsulated PTP traffic.

State and statistics data for each master clock are available to assist in the detection of failures or unusual situations.

The PTP algorithm is able to recover the clock using both the upstream and downstream directions in both ordinary slave and boundary clock modes. The ability to perform bidirectional recovery will improve the performance of networks where the upstream and downstream load is not symmetrical.

The Bell Labs algorithm looks at the PTP packet exchange in both directions between the master and slave. There can be more packet delay variation in one direction if there is a high utilization rate or congestion in that direction. The algorithm assesses the stability and reliability of the packet exchange in each direction and assigns weight values based on the results. The system gives preference to frequency synchronization from the direction with a higher weight value. The weight values change dynamically and can be viewed with detailed PTP show commands.

6.4.7.5. PTP Ordinary Slave Clock For Frequency

The PTP ordinary clock with slave capability on the 7705 SAR provides an option to reference a Stratum-1 traceable clock across a packet switched network. The recovered clock can be referenced by the internal SSU and distributed to all slots and ports.

Figure 16 shows a PTP ordinary slave clock network configuration.

Figure 16:  Slave Clock 

The PTP slave capability is implemented on the Ethernet ports of the platforms listed in Table 27 and on the cards listed in Table 28.

The 7705 SAR-8 Shelf V2 can support up to six slave clocks and the 7705 SAR-18 can support up to eight slave clocks.

All other fixed platforms listed in Table 27 can support up to two PTP clocks when one of those clock types is configured as transparent; otherwise, they support only one slave clock.

Each slave clock can provide a separate frequency reference to the SSU.

Figure 17 shows the operation of an ordinary PTP clock in slave mode.

Figure 17:  Ordinary Slave Clock Operation 

Each PTP ordinary slave clock is configured for a specific slot where the card (see Table 28) or Ethernet port (see Table 27) will perform the slave function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on the 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each slave is also associated with an IP interface on a specific port, adapter card, or loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a slave clock.

For best performance, the network should be designed so that the IP messaging between the master clock and the slave clock will ingress and egress through a port where the slave is configured. If the ingress and egress flow of the PTP messages is via a different port or adapter card on the 7705 SAR, then the packets will be routed through the fabric to the Ethernet card with the PTP slave.

It is possible that the PTP IP packets may be routed through another Ethernet port/VLAN, OC3/STM1 or OC12/STM4 clear channel POS, OC3/STM1 or OC12/STM4 channelized MLPPP, DS3/E3 PPP, or DS1/E1 MLPPP. The PTP slave performance may be slightly worse in this case because of the extra PDV experienced through the fabric. Packets will be routed this way only if the clock is configured with a loopback address. If the clock is configured with an address tied to a physical port, the packets will arrive on that physical port as described above.

6.4.7.6. PTP Ordinary Master Clock For Frequency

The 7705 SAR supports the PTP ordinary clock in master mode. Normally, a 1588v2 grand master is used to support many slaves and boundary clocks in the network. In cases where only a small number of slaves and boundary clocks exist and only frequency is required, a PTP integrated master clock can greatly reduce hardware and management costs to implement PTP across the network. It also provides an opportunity to achieve better performance by placing a master clock deeper into the network, as close to the slave clocks as possible.

Figure 18 shows a PTP master clock network configuration.

Figure 18:  PTP Master Clock 

The PTP master clock capability is implemented on the Ethernet ports of the platforms listed in Table 27 and on the cards listed in Table 28.

The 7705 SAR-8 Shelf V2 can support up to six master clocks and the 7705 SAR-18 can support up to eight master clocks. The fixed platforms listed in Table 27 can each support one master clock.

Figure 19 shows the operation of an ordinary PTP clock in master mode.

Figure 19:  Ordinary Master Clock Operation 

Each PTP master clock is configured for a specific slot where the card (see Table 28) or Ethernet port (see Table 27) will perform the master function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on a 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each master is also associated with an IP interface on a specific port, adapter card, or loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a master clock. All packets that ingress or egress through a port where the master is configured are routed to their destination via the best route as determined in the route table.

Each master clock can peer with up to 50 slaves or boundary clocks. The IP addresses of these peers can be statically configured via CLI or dynamically accepted via PTP signaling messages. A statically configured peer may displace a dynamic peer on a particular PTP port. If there are fewer than 50 peers, then that dynamic peer can signal back and be granted a different PTP-port instance.

6.4.7.7. PTP Boundary Clock For Frequency

The 7705 SAR supports boundary clock PTP devices in both master and slave states. IEEE 1588v2 can function across a packet network that is not PTP-aware; however, the performance may be unsatisfactory and unpredictable. PDV across the packet network varies with the number of hops, link speeds, usage rates, and the inherent behavior of the routers. By using routers with boundary clock functionality in the path between the grand master clock and the slave clock, one long path over many hops is split into multiple shorter segments, allowing better PDV control and improved slave performance. This allows PTP to function as a valid timing option in more network deployments and allows for better scalability and increased robustness in certain topologies, such as rings.

Boundary clocks can simultaneously function as a PTP slave of an upstream grand master (ordinary clock) or boundary clock, and as a PTP master of downstream slaves (ordinary clock) and/or boundary clocks. Figure 20 shows the operation of a boundary clock.

Figure 20:  Boundary Clock 

The PTP boundary clock capability is implemented on the Ethernet ports of the platforms listed in Table 27 and on the cards listed in Table 28.

The 7705 SAR-8 Shelf V2 can support up to six boundary clocks and the 7705 SAR-18 can support up to eight boundary clocks. The fixed platforms listed in Table 27 can each support one boundary clock.

Each PTP boundary clock is configured for a specific slot where the card (see Table 28) or Ethernet port (see Table 27) will perform the boundary clock function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on a 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each boundary clock is also associated with a loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a boundary clock.

Each boundary clock can be peered with up to 50 slaves, boundary clocks, or grand master clocks. The IP addresses of these peers can be statically configured via CLI or dynamically accepted via PTP signaling messages. A statically configured peer may displace a dynamic peer on a particular PTP port. If there are fewer than 50 peers, that dynamic peer can signal back and be granted a different PTP-port instance.

Figure 21 shows an example of boundary clock operation.

Figure 21:  Boundary Clock Operation 

6.4.7.8. PTP Ordinary Slave Clock for Time of Day/Phase Recovery

The following equipment supports PTP slave clock for time of day/phase recovery:

The 7705 SAR can receive and extract time of day/phase recovery from a 1588 grand master clock or boundary clock and transmit the recovered time of day/phase signal to an external device such as a base station through an external time of day port, where available. The PTP slave clock can be used as a reference for the router system time clock, providing high-accuracy OAM timestamping and measurements for the 7705 SAR chassis.

On the 7705 SAR-8 Shelf V2 CSMv2, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-M, and 7705 SAR-X, transmission is through the ToD port with a 1 pulse/s output signal that is phase-aligned with other routers that are similarly time of day/phase synchronized. An RS-422 serial interface within the ToD port connector communicates the exact time of day of the rising edge of the 1 pulse/s signal. The serial interface on the ToD out port and the ToD in port on the CSMv2 are currently not supported; therefore, the 7705 SAR-8 Shelf V2 does not support Time of Day messages.

On the 7705 SAR-H, transmission is through the IRIG-B Out port. An RJ-45 interface is used for the IRIG-B Out port to communicate the exact time of day by the rising edge of the 1 pulse/s signal, an IRIG-B000 unmodulated time code signal, and an IRIG-B12X modulated time code signal.

On the 7705 SAR-H, the Time of Day message output is only available when the router is configured with an active IP PTP slave clock or boundary clock. For all other routers, the Time of Day message output is available when the router is configured with an active IP PTP slave clock or boundary clock or when Time of Day is recovered from an Ethernet PTP clock or integrated GNSS.

Table 30 lists the 1 pulse/s signal (1pps) support and Time of Day messaging support per platform.

Table 31 describes the format of the ToD message.

For incoming IEEE 1588 packets, the destination IP address is the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, 7705 SAR-Wx, or 7705 SAR-X loopback address. The ingress interface can be an SFP Ethernet port on the faceplate of the chassis, an RJ-45 port on the faceplate of the chassis, or a port on an installed module.

Each PTP slave clock can be configured to receive timing from up to two PTP master clocks in the network. If both master clocks are available, the slave clock uses default BMCA to determine which of the two master clocks it should synchronize.

PTP messaging between the PTP master clock and PTP slave clock is done over UDP/IP using IPv4 unicast mode with a fixed IP header size or using IPv6. Unicast negotiation is supported. Each PTP instance supports up to 128 synchronization messages per second.

PTP recovered time accuracy depends on the delay of the forward path and the reverse path being symmetrical. It is possible to correct for known path delay asymmetry by using the  ptp-asymmetry command for PTP packets destined for the local slave clock or downstream PTP slave clock.

6.4.7.9. PTP Boundary Clock for Time of Day/Phase Recovery

The following equipment supports PTP boundary clock capability for time of day/phase recovery:

The 7705 SAR-8 Shelf V2 can support up to six boundary clocks and the 7705 SAR-18 can support up to eight boundary clocks. The fixed platforms can each support one boundary clock. PTP boundary clocks that recover time of day/phase from a grand master clock or another boundary clock can be used as a reference for the router system time clock, providing high-accuracy OAM timestamping and measurements for the 7705 SAR chassis.

Each PTP boundary clock for time of day/phase is configured for a specific slot where the adapter card or port will perform the boundary clock function. On fixed platforms, with the exception of the 7705 SAR-X, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. Each boundary clock is also associated with a loopback or system address for the router.

6.4.7.10. PTP End-to-End Transparent Clock for Time of Day/Phase Recovery

PTP end-to-end transparent clock for time of day/phase recovery is supported on the following:

Transparent clock functionality is supported for PTP packets over UDP/IP over Ethernet (with and without VLAN tags).

For high-accuracy 1588 PTP clock recovery, timestamping of incoming and outgoing messages should be done as close to ingress and egress as possible when the 7705 SAR is acting as a 1588 transparent clock. Edge timestamping is performed on all packets from all Ethernet ports, including SFP and RJ-45 ports on the faceplate of the chassis or a port on an installed module.

PTP recovered time accuracy depends on the delay of the forward path and the reverse path being symmetrical. It is possible to correct for known path delay asymmetry by using the ptp-asymmetry command to configure an asymmetry delay setting in nanoseconds per direction for each edge.

To enable transparent clock processing at the node level, configure a PTP clock with the transparent-e2e clock type (using the clock-type command). Deconfiguring such a PTP clock will disable transparent clock processing.

6.4.7.11. PTP Master Clock for Time of Day/Phase Distribution

PTP master clock capability for time of day/phase distribution is implemented on the following platforms:

Time of day input must be enabled using the use-node-time command before the node can be used as a PTP grand master clock. GNSS must also be the active system time reference for nodes that are being used as a grand master clock. When the use-node-time command is enabled, the PTP master clock uses the system time as a source of PTP time and can be used for time of day/phase distribution. When the use-node-time command is disabled, the PTP master clock can be used for frequency only.

6.4.7.12. PTP Clock Redundancy

Each PTP slave clock can be configured to receive timing from up to two PTP master clocks. If two PTP master clocks are configured, and if communication to the best master is lost or if the BMCA determines that the other PTP master clock is better, then the PTP slave clock switches to the other PTP master clock.

For a redundant or simple CSM configuration on the 7705 SAR-8 Shelf V2 and 7705 SAR-18, a maximum of two PTP slave clocks can be configured as the source of reference (ref1 and ref2) to the SSU. If a failure occurs between the PTP slave clock and the master clock, the SSU detects that ref1 or ref2 is unavailable and automatically switches to the other reference source. This switching provides PTP hot redundancy for hardware failures (on the 8-port Ethernet Adapter card, 6-port Ethernet 10Gbps Adapter card, 8-port Gigabit Ethernet Adapter card, 10-port 1GigE/1-port 10GigE X-Adapter card, or Packet Microwave Adapter card) or port or facility failures (SFP or cut fiber). If a loopback address is used, PTP packets may arrive on any router network interface and the PTP clock will remain up.

The 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X support only one PTP slave clock. This slave clock can be configured as the source of reference (ref1 or ref2) to the SSU.

6.4.7.13. PTP Ethernet Capabilities

The 7705 SAR can be configured to transmit and receive PTP messages over a port that uses Ethernet encapsulation. The encapsulation type can be null, dot1q, or qinq. Ethernet-encapsulated PTP messages are processed on the node CSM or CSM functional block, and they are supported on ordinary slave, ordinary master, or boundary clocks for either frequency or time of day/phase recovery. The 7705 SAR-Ax can also support a grand master clock. The 7705 SAR-H, 7705 SAR-Wx, 7705 SAR-8 Shelf V2, and 7705 SAR-18 can also support a grand master clock when equipped to support GNSS. A PTP clock using Ethernet encapsulation can support up to 50 external peer clocks.

All platforms and cards that support PTP functionality support Ethernet-encapsulated PTP messages, except for the 8-port Ethernet Adapter card and the 2-port 10GigE (Ethernet) Adapter card/module. See Table 27 and Table 28 for a complete list of supported platforms and cards.

Ethernet encapsulation is configured on a per-port basis using the config>system> ptp>clock command, with the clock-id parameter set to csm. Ports can simultaneously support IPv4-encapsulated or IPv6-encapsulated PTP messages and Ethernet-encapsulated PTP messages. As well, the 7705 SAR supports the interworking of a PTP slave using IPv4-encapsulated or IPv6-encapsulated messages with a PTP master using Ethernet-encapsulated messages.

When a PTP clock is configured for Ethernet encapsulation, the following profiles are available:

Table 32 describes the supported message rates for slave and master states for Ethernet-encapsulated PTP traffic, based on the profile configured. The ordinary clock can be either in the slave or master state. The boundary clock can be in both of these states.

See Table 29 for the supported message rates for IP-encapsulated PTP traffic.

PTP messages are transported within Ethernet frames with the Ethertype set to 0X88F7. Ports can be configured with one of two reserved multicast destination addresses:

Either address can be used for all messages depending on customer requirements. Refer to Recommendation ITU-T G.8275.1/Y.1369.1. When the profile configuration is iec-61850-9-3-2016 or c37dot238-2017, the 01-80-C2-00-00-0E address must be used for peer delay. Refer to IEC/IEEE 61850-9-3 and the C37.238-2017 extension.

When the profile configuration is ieee1588-2008, iec-61850-9-3-2016, or c37dot238-2017, the PTP clock’s priority1 and priority2 settings are used by the BMCA to help determine which clock should provide timing for the network. When the profile configuration is g8275dot1-2014, the local-priority value is used to choose between PTP masters in the BMCA.

6.4.7.14. ITU-T G.8275.1 and G.8275.2

The 7705 SAR supports Recommendation ITU-T G.8275.1 and ITU-T G.8275.2, which specify the architecture that allows the distribution of time and phasing. ITU-T G.8275.1 supports full timing support from the network and ITU G.8275.2 supports partial timing support and assisted partial timing support. It is assumed that these profiles will be used in well-planned cases where network behavior and performance can be constrained within well-defined limits, including limits on static asymmetry. When configured for the G.8275.1 or G.8275.2 profile, the 7705 SAR can operate as boundary clock, an ordinary master clock, or an ordinary slave clock.

Note: Support for control of static asymmetries is not yet available with G.8275.2 and assisted partial timing support.

When the 7705 SAR is configured for the G.8275.1 or G.8275.2 profile, it uses an alternate BMCA for best master clock selection. This BMCA includes a PTP dataset comparison that is defined in IEEE 1588-2008, but with the following differences:

The ITU-T G.8275.1 and G.8275.2 profiles have the following characteristics.

For further details, refer to Recommendation ITU-T G.8275.1/Y.1369.1 and ITU-T G.8275.2/Y.1369.2.

6.4.7.14.1. Synchronization Certainty/Uncertainty

As described in IEEE 1588v2 PTP, master clocks transmit Announce messages containing the clock priority and quality. Each clock in the network can use the BMCA and the clock properties received from the Announce messages to select the best clock to synchronize to.

Within a PTP-aware network, there could be situations where boundary clocks advertise clockClass 6 in the Announce message, which indicates that the parent clock is connected to a traceable primary reference source/clock (PRS/PRC) in locked mode (for example, locked to GNSS), and is therefore designated as the synchronization time source. However, the PTP network may still be in a transient state and stabilizing.

For example, this may occur when:

1. a grand master clock locks and relocks to GNSS
2. an intermediate boundary clock is started or restarted
3. a new parent clock is chosen

Depending on the application, it may be important for a downstream boundary clock or slave clock to know whether the PTP network has stabilized or is still “synchronization uncertain”.

Specifically when the G.8275.1profile (with IP encapsulation) or the G.8275.2 profile is used, the synchronizationUncertain flag is added to the Announce message. The use of this flag is optional. The 7705 SAR PTP grand master, boundary, and slave clocks support the processing of the synchronization state as follows.

1. If a grand master clock has its synchronous equipment timing source (SETS) frequency clock and time clock locked to GNSS and its clockClass equals 6, it is in a “synchronization certain” state. The synchronizationUncertain flag in the Announce message is set to FALSE.
2. If a grand master clock does not meet the above criteria, it is in a “synchronization uncertain” state. The synchronizationUncertain flag in the Announce message is set to TRUE.
3. In order for a boundary clock to be in the “synchronization certain” state, its parent clock’s clockClass must be “synchronization certain”, its SETS must be locked and PRS/PRC traceable, and PTP must have sufficient time to stabilize to the parent clock. At that point, its PTP port state will transition from an Uncalibrated state to a Slave state.
   The transition period is 16 s for G.8275.1 and 256 s for G.8275.2. To be selected as a system time reference, a G.8275.1 or G.8275.2 clock must be in the “synchronization certain” state.
4. A boundary clock can fall back to the “synchronization uncertain” state if its parent clock changes to the “synchronization uncertain” state, its SETS becomes unlocked or not PRS/PRC traceable, or the local clock is restarted or reset. The PTP port state will transition away from the Slave state.

This behavior is shown in Figure 22.

Figure 22:  Synchronization Certain/Uncertain States 

Because the synchronizationUncertain flag is newly agreed upon in standards, most base station slave clocks do not look at this bit. Therefore, in order to ensure that the downstream clocks are aware of the state of the network, the PTP clock (grand master, boundary, slave) may optionally be configured to transmit Announce and Sync messages only if the clock is in a “synchronization certain” state. This is done using the no tx-while-sync-uncertain command.

6.4.7.15. IEC/IEEE 61850-9-3 and C37.238-2017

The 7705 SAR supports IEC/IEEE 61850-9-3 and the C37.238-2017 extension, which are profiles that allow PTP to act as a timing source in power utility networks.

The IEC/IEEE 61850-9-3 and C37.238-2017 profiles support only Ethernet encapsulation with multicast addressing. Both profiles use the peer delay mechanism instead of the delay-request/response mechanism.

When configured for IEC/IEEE 61850-9-3 or C37.238-2017, the 7705 SAR can operate as a grand master clock, a boundary clock, or an ordinary slave clock and supports recovery of frequency as well as time of day/phase. Grand master clock functionality is only available for 7705 SAR variants with integrated GNSS.

Synchronous Ethernet can be used for frequency recovery as an optional mode for best time/phase recovery.

The IEC/IEEE 61850-9-3 and C37.238-2017 profiles have the following characteristics.

The C37.238-2017 profile uses the IEEE_C37_238 TLV in Announce messages between the parent and slave clocks. This TLV includes the grand master clock ID and the total time inaccuracy. Each clock in the chain adds its own inaccuracy to the total time inaccuracy, which gives the ultimate slave clock an estimate of the inaccuracy over the entire path.

The grand master inaccuracy includes the source time inaccuracy and the grand master time inaccuracy. When acting as a boundary clock, the system receives the total time inaccuracy from the parent clock and adds its own time inaccuracy, then sends out a TLV with the updated total time inaccuracy. By default, the time inaccuracy value is 100 ns for a grand master clock and 50 ns for a boundary clock. The default value can be changed for a boundary clock with the time-inaccuracy-override command.

For further details, refer to the IEC/IEEE 61850-9-3 standard and the C37.238-2017 extension.

6.4.7.16. PTP Profile Interworking

The PTP profile interworking feature allows the 7705 SAR to use G.8275.1 as a primary PTP profile while interworking with ports using alternate profiles connected to external devices. The 7705 SAR supports one primary profile for interworking, which must be configured as G.8275.1, and up to two alternate profiles, which can be configured as either IEC/IEEE 61850-9-3 or C37.238-2017.

By default, all PTP ports use the primary profile. The port must be shut down before the profile configuration can be modified. Any port that uses an alternate profile must be shut down before the alternate profile configuration can be modified.

Only messages exchanged on interfaces using the primary profile are included in the BMCA for the PTP clock. Interfaces using an alternate profile are considered to have their master-only value set to true and will ignore any Announce messages they receive.

The PTP clock follows the BMCA rules of the primary profile and updates all datasets appropriately. Interfaces using an alternate profile use the datasets of the PTP clock to populate fields in PTP messages. However, some values from the primary profile are modified because they are incompatible with values expected by the alternate profiles. The message rates used for the Announce messages may differ between profiles. The Announce rate is controlled by the log-anno-interval command configured for the profile in use. The Sync and Delay message rates are controlled by the per-port configuration.

The clockClass value in the Announce message may need to be converted (as shown in Table 33) when interworking from a G.8275.1 primary profile to either the IEC/IEEE 61850-9-3 or C37.238-2017 alternate profile.

See IEC/IEEE 61850-9-3 and C37.238-2017 for more information about these profiles.

6.4.7.17. PTP Statistics

The 7705 SAR provides the capability to collect statistics, state, and events data for the PTP slave clock’s interaction with PTP peer clock 1 and PTP peer clock 2. This data is collected separately for each peer clock and can be displayed using the show system ptp clock ptp-port command. This data can be used to monitor the PTP slave clock performance in relation to the peer clocks and to diagnose a problem or analyze the performance of a packet switched network for the transport of synchronization messages. The following data is collected:

PTP peer-1/PTP peer-2 statistics:

PTP master-1/PTP master-2 algorithm state statistics (in seconds):

PTP master-1/PTP master-2 algorithm event statistics:

6.4.9.1. Timing Reference Selection Based on Quality Level

For a SONET/SDH interface, a BITS DS1 or E1 physical port, a DS1 or E1 port interface that supports SSM, or a synchronous Ethernet interface that supports ESMC, a timing input provides a quality level value to indicate the source of timing of the far-end transmitter. These values provide input to the selection processes on the nodal timing subsystem. This selection process determines which input to use to generate the signal on the SSM egress ports and the reference to use to synchronize the nodal clock, as described below.

After the quality level values have been associated with the system timing inputs, the two reference inputs and the external input timing ports are processed by the system timing module to select a source for the SSU. This selection process is described below.