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.

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.

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.

System Coordinates

The system coordinates is the -Alcatel-Lucent Chassis MIB tmnxChassisCoordinates object. This text string indicates the Global Positioning System (GPS) coordinates of the location of the chassis.

Two-dimensional GPS 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 ranges 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.

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 -Alcatel-Lucent Chassis MIB tmnxChassisCLLICode object.

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

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 77705 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 OS Interface Configuration Guide, “Card, Adapter Card, and Port 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 (variant 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 OS Interface Configuration Guide, “Card, Adapter Card, and Port Command Reference”, for more information.

Time Zones

Setting a time zone in the 7705 SAR OS allows for times to be displayed in the local time rather than in UTC. The 7705 SAR 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 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 OS system-defined time zones are listed in Table 21, which includes both time zones with and without summer time correction.

NTP

NTP is the Network Time Protocol defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. 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 GPS or atomic clock. The 7705 SAR typically acts as a Stratum-2 device because a network connection to an NTP server is required.

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 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 the enhanced NTP mode is used, NTP authentication is not supported.

SNTP Time Synchronization

For synchronizing the system clock with outside time sources, the 7705 SAR OS 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.

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.

GPS

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 assured for the service, you can deploy a GPS receiver as a synchronous timing source. GPS data is used to provide network-independent frequency and ToD synchronization.

A 7705 SAR chassis equipped with a GPS receiver and attached external GPS equipment can function as a Stratum-1 server. The GPS 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 GPS reference is qualified only if the GPS receiver is operational, has sufficient 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 GPS signal loss or jamming resulting in the unavailability of timing information, the GPS receiver automatically prevents output of clock or synchronization data to the system, and the system can revert to other alternate timing sources.

CRON

The CRON feature supports the Service Assurance Agent (SAA) functions. CRON functionality includes the ability to specify the commands that need to be run, when they will be scheduled, including one-time-only functionality (oneshot), interval and calendar functions, as well as where to store the output of the results. In addition, CRON can specify the relationship between input, output, and schedule. Scheduled reboots, peer turn ups, and service assurance agent tests can be scheduled with CRON, as well as OAM events, such as connectivity checks or troubleshooting runs.

CRON features are saved to the configuration file on both primary and backup control modules. If a control module switchover occurs, CRON events are restored when the new configuration is loaded. If a control module switchover occurs during the execution of a CRON script, the failover behavior will be determined by the contents of the script.

CRON features run serially with at least 255 separate schedules and scripts. Each instance can support a schedule where the event is executed any number of times.

The following CRON elements are supported:

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.

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.

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 

ICB (Inter-Chassis Backup) 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 and adapter cards:

1. 7705 SAR-8/7705 SAR-18: 8-port Ethernet Adapter card, version 2
2. 7705 SAR-8 Shelf V2 with CSMv2 only/7705 SAR-18: 6-port Ethernet 10Gbps Adapter card
3. 7705 SAR-8/7705 SAR-18: 8-port Gigabit Ethernet Adapter card
4. 7705 SAR-18: 10-port 1GigE/1-port 10GigE X-Adapter card
5. 7705 SAR-8/7705 SAR-18: Packet Microwave Adapter card
6. 7705 SAR-M: all platform variants (the port must be in access mode and autonegotiation must be off or limited)

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:

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:

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.

Synchronization

Synchronization between the CSMs includes the following:

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 option 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 boot option files, see the chapter on Boot Options in this guide.

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.

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:

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.

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.

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.

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.

DCR Frequencies

Each DS1/E1 circuit configured with DCR executes its own clock recovery from the packet stream. This allows every DS1/E1 circuit to have an independent frequency.

Table 22 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.

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 multicast or unicast. Only IPv4 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 7705 SAR is acting as a slave or boundary clock.

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 14. This figure illustrates the offset of the slave clock referenced to the best master signal during startup.

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

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 GPS 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.

PTP Capabilities

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

Table 25 describes the supported message rates for slave and master states. The ordinary clock can be either in the slave or master state. The boundary clock can be in both of these states.

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 clock recovery will improve the performance of networks where the upstream and downstream load is not symmetrical.

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 15 shows a PTP ordinary slave clock network configuration.

Figure 15:  Slave Clock 

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

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

The 7705 SAR-F can support one slave clock. All other fixed platforms listed in Table 23 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 16 shows the operation of an ordinary PTP clock in slave mode.

Figure 16:  Ordinary Slave Clock Operation 

Each PTP ordinary slave clock is configured for a specific slot where the card (see Table 24) or Ethernet port (see Table 23) will perform the slave function. On the 7705 SAR-F, this slot is always 1/2. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. 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 clear channel POS, OC3/STM1 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.

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 17 shows a PTP master clock network configuration.

Figure 17:  PTP Master Clock 

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

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

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

Figure 18:  Ordinary Master Clock Operation 

Each PTP master clock is configured for a specific slot where the card (see Table 24) or Ethernet port (see Table 23) will perform the master function. On the 7705 SAR-F, this slot is always 1/2. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc,7705 SAR-A, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. 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 15 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 15 peers, then that dynamic peer can signal back and be granted a different PTP-port instance.

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 19 shows the operation of a boundary clock.

Figure 19:  Boundary Clock 

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

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

Each PTP boundary clock is configured for a specific slot where the card (see Table 24) or Ethernet port (see Table 23) will perform the boundary clock function. On the 7705 SAR-F, this slot is always 1/2. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. 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.

For best performance, the network should be designed so that the IP messaging between the slave or boundary clocks and the 7705 SAR boundary clock will ingress and egress over a port on its corresponding adapter card. If the ingress or egress flow of the PTP messages is through a different 7705 SAR port or adapter card, then the packets will be routed through the fabric to the Ethernet card with PTP boundary clock. It is possible that the PTP IP packets are routed through another Ethernet port/VLAN, OC3/STM1 clear channel POS, OC3/STM1 channelized MLPPP, DS3/E3 PPP or DS1/E1 MLPPP. The performance seen on the PTP slaves or boundary clocks may be slightly worse in this case because of the extra PDV experienced through the fabric.

Each boundary clock can be peered with up to 15 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 15 peers, then that dynamic peer can signal back and be granted a different PTP-port instance.

Figure 20 shows an example of boundary clock operation.

Figure 20:  Boundary Clock Operation 

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 following equipment:

On the 7705 SAR-A and 7705 SAR-M, 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.

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.

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-W, or 7705 SAR-Wx 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. Unicast negotiation is supported. Each PTP instance supports up to 128 synchronization messages per second. The default is 64 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.

PTP Boundary Clock for Time of Day/Phase Recovery

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

The 7705 SAR-8 can support up to six boundary clocks and the 7705 SAR-18 can support up to 12 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 following equipment:

Each PTP boundary clock for time of day/phase is configured for a specific slot where the 6-port Ethernet 10Gbps Adapter card, 8-port Gigabit Ethernet Adapter card, 10-port 1GigE/1-port 10GigE X-Adapter card, Packet Microwave Adapter card, or Ethernet port will perform the boundary clock function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-W, and 7705 SAR-Wx, this slot is always 1/1. Each boundary clock is also associated with a loopback address for the router.

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.

PTP Master Clock for Time of Day/Phase Distribution

PTP master clock capability for time of day/phase distribution is implemented on the 7705 SAR-H with a GPS Receiver module and on 7705 SAR-Wx variants with a GPS RF port. 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. GPS 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.

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 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, version 2, 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-F, 7705 SAR-M (all variants), 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A (both variants), 7705 SAR-W, and 7705 SAR-Wx (all variants) support only one PTP slave clock. This slave clock can be configured as the source of reference (ref1 or ref2) to the SSU.

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:

NTR on xDSL Interfaces

On xDSL interfaces, all CPE lines must be connected to the same LT because the clock source for all lines must be identical. While operating in VDSL2 mode, all pairs on an 8-port xDSL module must have their VDSL2 DMT signals aligned.

When NTR on xDSL is in use, a message is sent to the 7705 SAR-M indicating which pair is currently being used to derive NTR. However, once all lines are in show-time mode, NTR is carried on all lines. If there is an NTR status change from one pair to another, a status change is indicated in the CLI for the 7705 SAR-M. The status change is also visible through the 5620 SAM.

The chipset automatically selects the line with the best signal-to-noise ratio on the pilot tone. If there is a line drop, or if the signal-to-noise ratio degrades, the system automatically switches NTR to another line in show-time mode to recover clock synchronization. When NTR is locked to a particular line, the status is updated and indicated in the CLI and on the 5620 SAM.

If the line carrying NTR is taken out of show-time mode, there may be phase drift during the switchover if a phase delta difference has been missed.

NTR on SHDSL Interfaces

NTR for SHDSL is carried equally across all lines because all lines must connect back to the same LT on the same DSLAM. NTR for SHDSL operates in auto-detect mode. The 6-port DSL Combination module automatically selects an SHDSL pair that will be used to extract NTR and transmit to the SSU. The SHDSL pair is selected based on clock activity monitoring, coarse frequency monitoring, and chipset level indications on the active status of individual lines.

The auto-detect algorithm on the 6-port DSL Combination module selects an SHDSL pair used for NTR by first checking SHDSL pair 1. If pair 1 is not considered an acceptable source, the algorithm checks each pair in sequence until it finds an acceptable source or reaches SHDSL pair 4. The ID of the in-use line is displayed in CLI; however, it is not user-configurable.

When NTR on SHDSL interfaces is in use, the status is indicated to the 7705 SAR-M. The pair currently being used to derive NTR is shown in the CLI and is updated to the 5620 SAM. However, once all lines are in show-time mode, NTR is carried on all lines. If there is an NTR status change from one pair to another, a status change is indicated in the CLI for the 7705 SAR-M. The status change is also visible through the 5620 SAM.

The 6-port DSL Combination module automatically selects the SHDSL pair for NTR to use based on the selection algorithm. If there is a line drop, or if the signal-to-noise ratio degrades, the system automatically switches NTR to another line in show-time mode to recover clock synchronization. When NTR is locked to a particular line, the status is updated and indicated in the CLI and on the 5620 SAM.

If the line carrying NTR is taken out of show-time mode, there will be phase drift during the switchover and clock recovery may enter the holdover state if this was the only external timing reference available. If this happens, the 6-port DSL Combination module selects a new SHDSL line if one is available.

Timing Reference Selection Based on Quality Level

For a SONET/SDH interface, a BITS DS1 or E1 physical port, or an E1 port interface that supports SSM, or for 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.