System management

You can configure a name for the system device. The name is used in the prompt string. Only one system name can be configured. If multiple system names are configured the last one encountered overwrites the previous entry. Use the following command to configure the system name.

configure system name

Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.

Use the following command to configure the contact.

configure system contact

Use the location command to specify the location of the device. For example, enter the city, building address, floor, room number, and so on, where the router is located.

Use the following command to configure the location.

configure system location

You can optionally configure the GPS location of the device. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. Use the following command to configure the system coordinates.

configure system coordinates

Avoid configuring named objects with a name that starts with ‟_tmnx_” and with ‟_” in general.

A Common Language Location Identifier (CLLI) for the device is an 11-character standardized code string that uniquely identifies the geographic location of places and specific 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.

DNS Security (DNSSEC) Extensions are now implemented in the SR OS, allowing operators to configure DNS behavior of the router to evaluate whether the Authenticated Data bit was set in the response received from the recursive name server and to trust the response, or ignore it.

Setting a time zone in SR OS allows for times to be displayed in the local time rather instead of UTC. SR OS 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 in length and is unique 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.

configure system time prefer-local-time

Time strings include the following:

• log filenames and log header information
• times in rollback information
• times in rollback and configuration files header information
• times related to CRON scripts
• times related to CRON scripts
• times in the event handler system
• times in NETCONF and gRPC date-and-time leafs

configure log log-id time-format

The SR OS system-defined time zones are listed in the following table, which includes both time zones with and without daylight saving (summer) time adjustment.

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 more importantly they can maintain time in a more synchronized fashion between all participating network nodes.

SR OS uses an NTP process based on a reference build provided by the Network Time Foundation. Nokia strongly recommends that the users review RFC 8633, Network Time Protocol Best Current Practices, when they plan to use NTP with the router. The RFC section ‟Using Enough Time Sources” indicates that using only two time sources (NTP servers) can introduce instability if they provide conflicting information. To maintain accurate time, Nokia recommends configuring three or more NTP servers.

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 GPS or atomic clock.

The higher stratum levels are separated from the stratum-1 server over a network path, therefore, 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.

SR OS routers normally operate as a stratum-2 or higher device. The router relies on an external stratum-1 server to source accurate time into the network. However, SR OS also allows for the use of the local PTP recovered time to be sourced into NTP. In this latter case, the local PTP source appears as a stratum-0 server and SR OS advertises itself as a stratum-1 server. Activation of the PTP source into NTP may impact the network NTP topology because the SR OS router is promoted to stratum-1.

SR OS router runs a single NTP clock which then 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.

NTP operates associations between clocks as either client or server, symmetric active and symmetric passive, or broadcast modes. These modes of operation are applied according to which elements are configured on the router. To run server mode, the operator must enable NTP server mode for the base and each needed VPRN routing instance. To run client mode, the operator must configure external servers. If both the local router and remote router are configured with each other as peers, then the router operates in symmetric active mode. If only one side of the association has peering configured, then the modes are symmetric passive. To operate using broadcast mode, interfaces must be configured to transmit as broadcast servers or receive as broadcast clients.

NTP server operation for both unicast and broadcast communication within a VPRN is configured within the VPRN (see "NTP Within a VPRN Service" in the 7705 SAR Gen 2 Layer 3 Services Guide: IES and VPRN).

The following NTP elements are supported:

• server mode

  In this mode, the node advertises the ability to act as a clock source for other network elements. The node, by default, transmits NTP packets in NTP version 4 mode.

• authentication keys

  Authentication keys implement increased security support in carrier and other networks. Both DES and MD5 authentication are supported, as well as multiple keys.

• operation in symmetric active mode

  This capability requires that NTP be synchronized with a specific node that is considered more trustworthy or accurate than other nodes carrying NTP in the system. This mode requires that a specific peer is set.

• server and peer addressing using IPv6

  Both external servers and external peers may be defined using IPv6 or IPv4 addresses. Other features (such as multicast, broadcast) use IPv4 addressing only.

• broadcast or multicast modes

  When operating in these modes, the node receives or sends using either a multicast (default 224.0.1.1) or a broadcast address. Multicast is supported only on the CPM MGMT port.

• alert when NTP server is not available

  When none of the configured servers are reachable on the node, the system reverts to manual timekeeping and issues a critical alarm. When a server becomes available, a trap is issued indicating that standard operation has resumed.

• NTP and SNTP

  If both NTP and SNTP are enabled on the node, then SNTP transitions to an operationally down state. If NTP is removed from the configuration or shut down, then SNTP resumes an operationally up state.

• gradual clock adjustment

  As several applications (such as Service Assurance Agent (SAA)) can use the clock, and if determined that a major (128 ms or more) adjustment needs to be performed, the adjustment is performed by programmatically stepping the clock. If a minor (less than 128 ms) adjustment must be performed, then the adjustment is performed by either speeding up or slowing down the clock.

• To avoid the generation of too many events/trap the NTP module rates limit the generation of events/traps to three per second. At that point a single trap is generated that indicates that event/trap squashing is taking place.

The CRON feature supports periodic and date and time-based scheduling in SR OS. CRON can be used, for example, to schedule Service Assurance Agent (SAA) functions. CRON functionality includes the ability to specify scripts that need to be run, when they are scheduled, including one-time only functionality (one-shot), interval and calendar functions. Scheduled reboots, peer turn ups, service assurance agent tests and more can all be scheduled with CRON, as well as OAM events, such as connectivity checks, or troubleshooting runs.

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

The 7705 SAR-Hx and 7705 SAR-Mx support frequency synchronization using a Layer 1 interface, such as Synchronous Ethernet (SyncE), and ToD synchronization using protocols 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 7705 SAR-Hx and 7705 SAR-Mx support GPS and Galileo reference using an integrated GNSS RF port.

A 7705 SAR-Hx or 7705 SAR-Mx 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 is distributed to the rest of the router from the SSU as configured with the following commands:

If GNSS signal loss or jamming causes timing information to become unavailable, the GNSS receiver automatically prevents the output of clock or synchronization data to the system. In this case, the system can revert to alternate timing sources.With Assisted Partial Timing Support (APTS), the system can perform a seamless switch when reverting to a backup PTP session; see GNSS failure with APTS.

E1 signals can indicate the QL of the source generating the timing information using the SSM as specified in Recommendation G.704.

One of the Sa4 to Sa8 bits (the actual Sa bit is for user selection) is allocated for SSMs. To prevent ambiguities in pattern recognition, it is necessary to align the first bit (San1) with frame 1 of a G.704 E1 multi-frame.

A San bit is one of a 4-bit nibble, San1 to San4. San1 is the most significant bit; San4 is the least significant bit.

The message set in San1 to San4 is a copy of the set defined in SDH bits 5 to 8 of byte S1.

For a SyncE interface that supports Ethernet Synchronization Message Channel (ESMC), a timing input or PTP clock class provides a QL value to indicate the source of timing of the far-end transmitter. These values provide input to the selection process 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 follows:

• For the two reference inputs (ref1 and ref2), if the interface configuration supports the reception of a QL over SSM or ESMC, the QL value is associated with the timing derived from that input.

• For the two reference inputs, if the interface configuration is T1 with SF framing, the quality level associated with the input is QL-UNKNOWN.

• For the two reference inputs, if they are SyncE ports and the ESMC is disabled, the QL value associated with that input is QL-UNKNOWN.

• For the two reference inputs, if the interface configuration supports the reception of a QL over SSM (and not ESMC), and no SSM value has been received, the QL value associated with the input is QL-STU.

• For the two reference inputs, if the interface configuration supports the reception of a QL over SSM or ESMC, but the QL value received over the interface is not valid for the type of interface, the QL value associated with that input is QL-INVALID.

• For the two reference inputs, if they are external synchronization ports, the QL value associated with the input is QL-UNKNOWN.

• For the two reference inputs, if they are SyncE ports and the ESMC is enabled, but no valid ESMC Information PDU has been received within the previous 5 s, the QL value associated with that input is QL-FAILED.

• For GNSS reference input, the QL is PRS if a frequency is successfully recovered; otherwise, the QL is QL-FAILED.

• If the user has configured an override for the QL associated with an input, the node displays both the received and override QL value for the input. If no value has been received, the associated value is displayed instead.

After the QL 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 as follows.

• Before an input can be used as a potential timing source, it must be enabled using the following command:

  • MD-CLI

    configure system central-frequency-clock ql-selection

  • classic CLI

    configure system sync-if-timing ql-selection

  If the ql-selection command option is disabled, the priority order of the inputs for the Synchronous Equipment Timing Generator (SETG) is the priority order configured under the following command:

  • MD-CLI

    configure system central-frequency-clock ref-order

  • classic CLI

    configure system sync-if-timing ref-order

• If the ql-selection command is enabled, the priority of the inputs is calculated using the associated QL value of the input and the priority order configured under the ref-order command. The inputs are ordered by the internal relative QL based on their associated QL values. If two or more inputs have the same quality level value, they are placed in order based on where they appear in the ref-order priority. The priority order for the SETG is based on both the reference inputs and the external synchronization input ports.

• After a prioritized list of inputs is calculated, the SETG and the external synchronization output ports are configured to use the inputs in their respective orders.

• After the SETG and external synchronization output ports priority lists are programmed, the highest-qualified priority input is used. To be qualified, the signal is monitored to ensure that it has the expected format and a frequency that is within the pull-in range of the SETG.

SR OS supports the extended QL TLV of the ESMC message as defined in ITU-T G.8264. This TLV allows the communication of newer QL values and some synchronization trail information up to the current clock. The newly added QL values include:

• QL_ePRTC

• QL_PRTC

• QL_PRC

• QL_eEEC

The IEEE 1588v2 standard synchronizes the frequency and time from a timeTransmitter clock to one or more timeReceiver clocks over a packet stream. This packet-based synchronization standard defines transport to use UDP/IP with unicast or Ethernet with multicast.

As part of the basic synchronization timing computation, a number of event messages are defined for synchronization messaging between the PTP timeReceiver port and PTP timeTransmitter port. 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. Ordinary clock timeTransmitter and boundary clock timeTransmitter ports use one-step operation; ordinary clock timeReceiver and boundary clock timeReceiver ports can accept messages from either one-step or two-step operation timeTransmitter ports.

The IEEE 1588v2 standard includes a mechanism to control the topology for synchronization distribution. The Best TimeTransmitter Clock Algorithm (BTCA) defines the states for the PTP ports on a clock. One port is set into timeReceiver state and the other ports are set to timeTransmitter (or passive) states. Ports in timeReceiver state recovered synchronization delivered by from an external PTP clock and ports in timeTransmitter state transmit synchronization to toward external PTP clocks.

The following figure shows the basic synchronization timing computation between the PTP timeReceiver clock and PTP best timeTransmitter. This figure illustrates the offset of the timeReceiver clock referenced to the best timeTransmitter signal during startup.

When using IEEE 1588v2 for distribution of a frequency reference, the timeReceiver calculates a message delay from the timeTransmitter to the timeReceiver based on the timestamps exchanged. A sequence of these calculated delays contain information of the relative frequencies of the timeTransmitter clock and timeReceiver clock but has a noise component related to the PDV experienced across the network. The timeReceiver must filter the PDV effects to extract the relative frequency data, then adjust the timeReceiver frequency to align with the timeTransmitter frequency.

When using IEEE 1588v2 for distribution of time, the 7705 SAR-Hx and 7705 SAR-Mx use the four timestamps exchanged using the IEEE 1588v2 messages to determine the offset between the router time base and the external timeTransmitter clock time base. The router determines the offset adjustment and then in between these adjustments, the router maintains the progression of time using the frequency from the central clock of the router. This allows time to be maintained using a SyncE input source even if the IEEE 1588v2 communications fail. When using IEEE 1588v2 for time distribution, the central clock should at a minimum have a system timing input reference enabled.

The following figure shows a logical model for using PTP/1588 for network synchronization.

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 grandmaster clock and the timeReceiver clock. When IEEE 1588v2 is used to distribute high-accuracy time, such as for mobile base station phase requirements, the network architecture requires the deployment of PTP awareness in every device between the grandmaster clock and the mobile base station timeReceiver.

In addition, performance is also improved by the removal of any PDV caused by internal queuing within the boundary clock or timeReceiver clock. This is accomplished with hardware that is capable of detecting and time stamping the IEEE 1588v2 packets at the Ethernet interface. This capability is referred to as port-based timestamping.

To exchange PTP messages between the router and an external 1588 clock, a unicast session must be established for each PTP message type using the unicast negotiation procedures. The router allows the configuration of the message rate to be requested from external 1588 clocks. The router also supports a range of message rates that it grants to requests received from the external 1588 clocks. The IEEE 1588 standard allows the grantor port to respond with a shorter duration than what was in the request. The router can accept such a grant and uses that duration. The router issues a renegotiation before the duration expires.

The following table describes the ranges for both the rates that the 7705 SAR-Hx, and 7705 SAR-Mx can request and grant.

State and statistics data for each PTP peer are available to assist in detecting failures or unusual situations.

Traditionally, only clock frequency is required to ensure smooth transmission in a synchronous network. The PTP ordinary clock with timeReceiver capability on the router provides another 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.

The following figure shows a PTP ordinary timeReceiver clock network configuration.

The PTP timeReceiver capability is implemented on the CPM, version 3 or later. The IEEE 1588v2 messages can ingress and egress the router on any line interface. The following figure shows the operation of an ordinary PTP clock in timeReceiver mode.

The router supports the PTP ordinary clock in timeTransmitter mode. Normally, an IEEE 1588v2 grandmaster is used to support many timeReceivers and boundary clocks in the network. In cases where only a small number of timeReceivers and boundary clocks exist and only frequency is required, a PTP integrated timeTransmitter 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 timeTransmitter clock closer to the edge of the network, as close to the timeReceiver clocks as possible. The following figure shows a PTP timeTransmitter clock network configuration.

All packets are routed to their destination via the best route as determined in the route table, as shown in the following figure. It does not matter which ports are used to ingress and egress these packets (unless port based time stamping is enabled for higher performance).

The router supports boundary clock PTP devices in both timeTransmitter and timeReceiver 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, utilization rates, and the inherent behavior of the routers. By using routers with boundary clock functionality in the path between the grandmaster clock and the timeReceiver clock, one long path over many hops is split into multiple shorter segments, allowing better PDV control and improved timeReceiver performance. This allows PTP to function as a valid timing option in more network deployments, allowing better scalability and increased robustness in specific topologies, such as rings.

Boundary clocks can simultaneously function as a PTP timeReceiver of an upstream grandmaster (ordinary clock) or boundary clock, and as a PTP timeTransmitter of downstream timeReceivers (ordinary clock) and boundary clocks, as shown in the following figure.

Nokia strongly recommends using port-based timestamping in every network element between the grandmaster and the end timeReceiver application to achieve time accuracies of one microsecond required by mobile applications.

The router always uses the frequency output of the central frequency clock to maintain the timebase within the router. When using the G.8275.1 profile, it is mandatory to have the central frequency clock configured to use a Layer 1 frequency source, such as a SyncE port. For other profiles, Nokia recommends using a Layer 1 frequency source. If a Layer 1 frequency source is unavailable, enable PTP as a source for the central frequency clock to have frequency for timestamping traceable to a high accuracy source.

When a router with an enabled GNSS port is configured with boundary clock functionality, the boundary clock acts as a grandmaster clock. The timeReceiver function stops and the timeTransmitter ports use frequency and time recovered from the GNSS port.

PTP timeTransmitter clock capability for frequency and time distribution is implemented on the7705 SAR-Hx and 7705 SAR-Mx.

GNSS must be the active system timing and frequency reference for routers that are used as a grandmaster clock. The PTP timeTransmitter clock can be used for frequency and time distribution. See Configuring system timing to use a GNSS RF port for information about configuring the router to use GNSS as a system timing reference.

Use the following commands to configure the router as a grandmaster clock:

• MD-CLI

  configure system ptp profile ieee1588-2008
  configure system ptp clock-type master-only
  configure system ptp admin-state enable

• classic CLI

  configure system ptp profile ieee1588-2008
  configure system ptp clock-type ordinary master
  configure system ptp no shutdown

The 7705 SAR-Hx and 7705 SAR-Mx support Recommendation ITU-T G.8275.2, which, similar to Recommendation ITU-T G.8275.1, specifies the architecture that allows the distribution of time and phasing. Recommendation ITU-T G.8275.1 supports full-timing from the network and Recommendation ITU-T G.8275.2 supports partial-timing (PTS) and APTS.

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

• the priority1 value is removed from the dataset comparison
• the master-only value must be considered
• multiple active grandmaster clocks are allowed; therefore, the BTCA selects the nearest clock of equal quality
• a port-level local-priority attribute value is used to select a timeReceiver port if two ports receive an Announce message. This attribute is used as a tiebreaker in the dataset comparison algorithm if all other previous attributes of the datasets being compared are equal.
• the local-priority value is considered for the default dataset

When the clock is configured as a boundary clock, the GNSS is treated as a virtual PTP port into the BTCA. On systems with redundant GNSS, the preference in the BTCA shall be the local GNSS followed by the standby GNSS. The GNSS receiver shall only be considered into the BTCA if it is in locked state. Also in these systems, when one of the GNSS is selected as the parent clock, there may still be a PTP port running frequency and time recovery from a remote PTP timeTransmitter port as a backup. The ptp statistics reflect this backup session.

When the PTP clock is configured to use the G.8275.2 profile without GNSS configured, the clock operates using PTS. When the PTP clock is configured to use the G.8275.2 profile and the internal GNSS is configured and operationally up, GNSS is the preferred reference by default and is selected as the source of time for PTP. For extra resilience, APTS can be deployed by configuring a PTP backup over a network with PTP support to a remote grandmaster clock.

When the clock is configured as a boundary clock, the GNSS is treated as a virtual PTP port into the BTCA. On systems with redundant GNSS, the preference in the BTCA is the local GNSS followed by the standby GNSS. The GNSS receiver is considered into the BTCA when it is in locked state. Also in these systems, when one of the GNSS is selected as the parent clock, there may still be a PTP port running frequency and time recovery from a remote PTP timeTransmitter port as a backup. The PTP statistics reflect this backup session.

During normal operation, the local GNSS source is the reference for time and frequency. If the GNSS source fails, the PTP backup is automatically used to keep the clocks synchronized and stable. The delay offset value, which is calculated while the GNSS source was up, is applied to the PTP backup to keep time and phase as accurate as possible. See GNSS failure with APTS for more information about APTS functionality during a GNSS failure.

The following table describes the mapping between ITU-T G.8275.2 and PTP clock types. T-BC-A and T-TSC-A clocks are applicable to APTS.

For physical ports located on an MDA on the 7705 SAR-Hx and 7705 SAR-Mx, PTP messages are supported in the following encapsulations:

• PTP within raw Ethernet (no VLAN header)
• PTP within UDP/IPv4 or UDP/IPv6 within raw Ethernet (no VLAN header)

No other encapsulations are supported.

PTP has the potential to provide much more accurate time into the router than can be obtained with NTP. This PTP recovered time can be made available for system time and OAM packet timestamping to improve the accuracy of logged events and OAM delay measurements. To activate PTP as the source for these internal time bases, allocate PTP as a local server into NTP. This allows the NTP time recovery to use PTP as a time source and then distribute it to system time and the OAM process within the router. This activation also affects the operation of the NTP server within the SR OS. The PTP server appears as an NTP stratum 0 server. Consequently the SR OS advertises itself as an NTP Stratum 1 server to external peers and clients. This activation may impact the NTP topology.

PTP is supported over direct Ethernet encapsulation (that is, PTP ports) and UDP/IP encapsulation (that is, PTP peers). PTP ports operate below the routing plane. They can be used on appropriate ports irrespective of any type of router interface also on the port. PTP peers operate at the routing plane and have restrictions based on and across the following router instances.

Transmission and reception of PTP messages using PTP peers is supported in the following contexts:

• Network interface in the Base routing instance (configure router interface)

• IES interface (configure service ies interface)

• VPRN interface (configure service vprn interface)

Transmission and reception of PTP messages using PTP peers is not supported in the following contexts:

• IES spoke SDP interface (configure service ies spoke-sdp interface)

• VPRN spoke SDP interface (configure service vprn spoke-sdp interface)

• VPRN transport tunnel (configure service vprn auto-bind-tunnel or configure service vprn spoke-sdp)

• Any interface of the management router instance

• Any interface of the vpls-management router instance

• Any interface of a user created CPM router instance

It is important to note that there is only one PTP clock within the router. All PTP ports and PTP peers communicate into one clock instance. Only one router instance may have PTP peers configured, which means that only that router instance (or PTP port) can run the timeReceiver functionality and recover time from an external PTP clock. All other router instances only support the dynamic PTP peers. The PTP process in the router only includes outward server time toward the dynamic PTP peers. The dynamic PTP peers are shared across all router instances. If controlling the number of dynamic peers that can be consumed by a routing instance is required, the user must configure it specifically for that routing instance.

The PTP clock in the router monitors the Sync, Follow_Up (if present), and Delay_Resp messages received from external neighbor ports. If a high variation is detected in the network path between the external neighbor port and the local port, that neighbor port is considered unusable (PTSF-unusable as defined in the ITU-T G.8275.1 recommendation). When a neighbor is unusable, all Announce messages from that neighbor are discarded on reception and excluded from the BTCA. If the neighbor is the parent clock to the local clock, the local clock must either select a new parent clock or go into holdover. In addition, any neighbor clock marked as unusable cannot act as the parent to the local PTP clock until the underlying condition is investigated and resolved, and the unusable state is cleared. The unusable state is cleared when PTP, PTSF-unusable monitoring, or the local PTP port is administratively disabled; when the PTP port is deleted; or when the external neighbor port stops sending messages to the node. The user can also clear the state by using the following command.

clear system ptp port neighbor ptsf-unusable

There is one PTP clock within an SR OS system. The clock runs a BTCA and can set a port into timeReceiver state to recover frequency, time, or both. The recovery process is controlled by the rules of a primary profile. The SR OS also allows frequency, time, or both to be distributed outward from the clock using PTP messages that conform to the rules of an alternate profile. The primary profile and alternate profiles include a command option to configure the standard profile that defines these rules. The following guidelines apply to profile interworking on the 7705 SAR-Hx and 7705 SAR-Mx:

• Alternate profiles can only be configured if the primary profile is using standard profile g8275dot1-2014 or g8275dot2-2016.
• Alternate profiles can use standard profiles g8265dot1-2010, ieee1588-2008, g8275dot1-2014, g8275dot2-2016, iec-61850-9-3-2016, or c37dot238-2017.
• The primary profile and an alternate profile can use the same standard profile.
• Multiple alternate profiles can also use the same standard profile.

Alternate profiles are associated with PTP ports and peers. Alternate profile associations are configured for PTP ports and learned by PTP peers. PTP peer alternate profiles are learned by matching the domain number of received unicast messaging with the domain of the configured alternate profile. Configured peers always use the primary profile.

The following table lists the profile interworking between the primary and alternate profiles depending on the standard profile used as the primary on the 7705 SAR-Hx and 7705 SAR-Mx.

Support is provided for the collection of performance monitoring statistics for the time recovery algorithm based on Annex J/IEEE1588-2019. The following table describes the record index values.

Each record includes the average, minimum, maximum, and standard deviation for the following statistics:

• offset-from-master
• mean-path-delay
• timeTransmitter-to-timeReceiverDelay (master-to-slave-delay)
• timeReceiver-to-timeTransmitter delay (slave-to-master-delay)

These performance statistics are available in the following scenarios:

• local active timeReceiver port to remote PTP parent
• local active GNSS to backup PTP port
• local active timeReceiver port to other selected local PTP ports

In the local active timeReceiver port to remote PTP parent scenario, the local active timeReceiver port and the remote parent timeTransmitter port are compared. In a system where the PTP has stabilized, the offset-from-master tends toward 0. A high value indicates that the PTP path has high packet delay variation or high asymmetry.

In the local active GNSS to backup PTP port scenario, when a platform includes a GNSS receiver that is being used as a PTP time source with G.8275.1 or G.8275.2 as the PTP profile, the PTP clock runs a PTP timeReceiver port with an external timeTransmitter port, if one is available. If the PTP clock runs a PTP timeReceiver port, the Annex J statistics are computed as a comparison between the timeReceiver computed time and the GNSS time. Computing the Annex J statistics this way can provide a good indication for PTP performance should the GNSS lose lock and the node switches to use PTP input as its source of time.

In the local active timeReceiver port to other selected local PTP ports scenario, the local active timeReceiver port and another timeReceiver port in the router are compared. Up to four timeReceiver ports can be monitored simultaneously. In this case, these timeReceiver port are designated to be monitored by configuring the PTP port (or PTP peer) to be a monitorReceiver. At the remote end of these monitored PTP ports, the timeTransmitter port can be configured to be monitorSender so that the monitor process can proceed correctly, no matter the PTP state of the port.

SR OS supports PTP path trace of IEEE1588-2019 clause 16.2. This feature records and displays the chain of PTP clocks from the local clock up to the grandmaster clock.

A node-level configuration option allows the user to include or exclude the PATH_TRACE TLV. If this feature is enabled and the Announce message received from the parent clock does not include the TLV, the SR OS boundary clock creates the TLV with the local clock identity and includes that TLV in the Announce message transmitted by the node.

SR OS supports a maximum length chain of 40 clocks in the PATH_TRACE TLV. If this number is exceeded, SR OS includes only the closest 40 clock identifiers in the transmitted PATH_TRACE TLV.

The device's system name is used in the prompt string. Only one system name can be configured; if multiple system names are configured, the last one overwrites the previous entry.

Use the following command to configure the system name.

configure system name

Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.

Use the following command to configure the contact.

configure system contact

Use the location command to specify the location of the device. For example, enter the city, building address, floor, room number, and so on, where the router is located.

Use the following command to configure the location.

configure system location

The Common Language Location Code (CLLI code) is an 11-character standardized geographic identifier that is used to uniquely identify the geographic location of a router.

Use the following command to configure the CLLI code.

configure system clli-code

Use the optional coordinates command to specify the GPS location of the device. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

Use the following command to configure the coordinates.

configure system coordinates

The zone command sets the time zone and time zone UTC offset for the router. SR OS supports system-defined and user-defined time zones. The system-defined time zones and offsets are listed in System-defined time zones and UTC offsets.

configure system time zone

Configure the start and end dates and offset for summer (daylight saving) time to override system defaults or for user-defined time zones. When configured, the time will be adjusted by changing to the configured offset when summer time starts and returning to the configured offset when summer time ends.

Use commands in the following context to configure the start day, end day, and offset of the summer.

configure system time dst-zone

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 more importantly they can maintain time in a more synchronized fashion between all participating network nodes.

SR OS uses an NTP process based on a reference build provided by the Network Time Foundation. Nokia strongly recommends that the users review RFC 8633, Network Time Protocol Best Current Practices, when they plan to use NTP with the router. The RFC section ‟Using Enough Time Sources” indicates that using only two time sources (NTP servers) can introduce instability if they provide conflicting information. To maintain accurate time, Nokia recommends configuring three or more NTP servers.

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 GPS or atomic clock.

The higher stratum levels are separated from the stratum-1 server over a network path, therefore, 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.

SR OS routers normally operate as a stratum-2 or higher device. The router relies on an external stratum-1 server to source accurate time into the network. However, SR OS also allows for the use of the local PTP recovered time to be sourced into NTP. In this latter case, the local PTP source appears as a stratum-0 server and SR OS advertises itself as a stratum-1 server. Activation of the PTP source into NTP may impact the network NTP topology because the SR OS router is promoted to stratum-1.

SR OS router runs a single NTP clock which then 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.

NTP operates associations between clocks as either client or server, symmetric active and symmetric passive, or broadcast modes. These modes of operation are applied according to which elements are configured on the router. To run server mode, the operator must enable NTP server mode for the base and each needed VPRN routing instance. To run client mode, the operator must configure external servers. If both the local router and remote router are configured with each other as peers, then the router operates in symmetric active mode. If only one side of the association has peering configured, then the modes are symmetric passive. To operate using broadcast mode, interfaces must be configured to transmit as broadcast servers or receive as broadcast clients.

NTP server operation for both unicast and broadcast communication within a VPRN is configured within the VPRN (see "NTP Within a VPRN Service" in the 7705 SAR Gen 2 Layer 3 Services Guide: IES and VPRN).

The following NTP elements are supported:

• server mode

  In this mode, the node advertises the ability to act as a clock source for other network elements. The node, by default, transmits NTP packets in NTP version 4 mode.

• authentication keys

  Authentication keys implement increased security support in carrier and other networks. Both DES and MD5 authentication are supported, as well as multiple keys.

• operation in symmetric active mode

  This capability requires that NTP be synchronized with a specific node that is considered more trustworthy or accurate than other nodes carrying NTP in the system. This mode requires that a specific peer is set.

• server and peer addressing using IPv6

  Both external servers and external peers may be defined using IPv6 or IPv4 addresses. Other features (such as multicast, broadcast) use IPv4 addressing only.

• broadcast or multicast modes

  When operating in these modes, the node receives or sends using either a multicast (default 224.0.1.1) or a broadcast address. Multicast is supported only on the CPM MGMT port.

• alert when NTP server is not available

  When none of the configured servers are reachable on the node, the system reverts to manual timekeeping and issues a critical alarm. When a server becomes available, a trap is issued indicating that standard operation has resumed.

• NTP and SNTP

  If both NTP and SNTP are enabled on the node, then SNTP transitions to an operationally down state. If NTP is removed from the configuration or shut down, then SNTP resumes an operationally up state.

• gradual clock adjustment

  As several applications (such as Service Assurance Agent (SAA)) can use the clock, and if determined that a major (128 ms or more) adjustment needs to be performed, the adjustment is performed by programmatically stepping the clock. If a minor (less than 128 ms) adjustment must be performed, then the adjustment is performed by either speeding up or slowing down the clock.

• To avoid the generation of too many events/trap the NTP module rates limit the generation of events/traps to three per second. At that point a single trap is generated that indicates that event/trap squashing is taking place.

SNTP is a compact, client-only version of NTP. SNTP can only receive the time from SNTP/NTP servers; it cannot be used to provide time services to other systems. SNTP can be configured in either broadcast or unicast client mode.

SNTP time elements include the Broadcast-client and Server-address.

Use the commands in the following context to configure the SNTP.

configure system time sntp

The CRON feature supports periodic and date and time-based scheduling in SR OS. CRON can be used, for example, to schedule Service Assurance Agent (SAA) functions. CRON functionality includes the ability to specify scripts that need to be run, when they are scheduled, including one-time only functionality (one-shot), interval and calendar functions. Scheduled reboots, peer turn ups, service assurance agent tests and more can all be scheduled with CRON, as well as OAM events, such as connectivity checks, or troubleshooting runs.

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