Table of Contents

Synchronous Clocking Concepts

Synchronizing the Cisco MC3810 to a Synchronous Clocked Network

Configuring the Clock Source for the Cisco MC3810

Configuring the Cisco MC3810 to Obtain Clocking from the Network

Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to a T1/E1 Controller
Configuring a T1/E1 Controller to Loop-Time the Clocking Back to the Network Clock Source
Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to Serial 0

Configuring the Cisco MC3810 to Use the Internal Clock Source

Configuring a Hierarchy of Clock Sources for Backup Purposes

Clock Source Hierarchy Rules

Configuring Synchronized Clocking

The Cisco MC3810 multiservice access concentrator supports voice and video streams in addition to traditional data streams. Because voice and video streams are real-time streams and originate from synchronous devices, it is important to configure the synchronous clocking to prevent data corruption and data loss.

• Synchronous Clocking Concepts

• Configuring the Clock Source for the Cisco MC3810

• Configuring a Hierarchy of Clock Sources for Backup Purposes

Synchronous Clocking Concepts

Due to the real-time nature of voice and video, more configuration and planning is required for voice traffic than is required for traditional data traffic. Because voice and video streams are real-time and continuous, the information is normally generated by the source device and received by the destination device at a synchronized fixed rate. If the source and destination clocking is not synchronized, meaning the devices generate information at different rates, there will be a loss of information as one side over-runs and the other side under-runs.

As a result, for voice and video configurations a single master clock source must be configured to make the network synchronous. The master clock must be used as the clock source for all devices on the network, even when the voice traffic is compressed.

Clocking mismatches can be caused by a variety of configuration problems. The following situations can cause problems:

• Multiple clock sources on the network that are not synchronized

In back-to-back voice systems where the two devices are using different clock sources that are not synchronized, data loss can occur when one device over-runs the voice stream and the other device under-runs the voice stream.

In situations where there is a minor clock mismatch, the Cisco MC3810 may be able to process the mismatch in its internal voice coders, in the same way that the voice coders handle minor network delay and jitter. The voice waveform will be degraded but often not noticeably.

However, when the Cisco MC3810 is using Circuit Emulation Services (CES) to send video traffic, no similar clock compensation is possible as the CES must be in synchronous mode. As a result, when video traffic is sent over a non-synchronized network, data corruption may occur. This will cause video devices connected to the Cisco MC3810 to lose frame synchronization and enter a frame-search mode, causing noticeable data loss. Because of these requirements, the network clocks must be synchronized when processing video traffic on the Cisco MC3810.

• Layer 1 conflicts

Layer 1 conflicts can take place when a Cisco MC3810 with both a digital voice module (DVM) and a multiflex trunk module (MFT) is placed at the border of two separately clocked T1 or E1 networks and is forced to resolve the clock difference between the networks. As a result, DS1 clock and frame slips can occur, which can result in lengthy reframe times, and can cause an attached DS1 device to declare the line down.

Synchronizing the Cisco MC3810 to a Synchronous Clocked Network

To ensure a synchronized system, you must configure a master clock somewhere within the network, and distribute and recover the clock throughout the network. This will allow end devices at opposite ends of the network to reference a common clock source. If you cannot configure a synchronized system, then you can configure multiple clock sources on your network as long as they are accurate enough that the clocking on both clock sources will match.

You can statically configure the Cisco MC3810 to receive or generate clocking using one of the following scenarios:

• Obtain the synchronous clock from a network device attached to controller T1 or E1 0 and distribute the clocking to the other controller and the universal input/output (UIO) serial ports.

• Obtain the synchronous clock from a network device attached to controller T1 or E1 1, and distribute the clocking to the other controller and the UIO serial ports.

• Obtain the synchronous clock from a network device directly attached to serial port 0 (in DTE mode only) and distribute the clocking to the other serial ports and to both controllers.

• Generate the clock internally on the Cisco MC3810 and distribute the clocking to all interfaces.

• When in T1 or E1 mode, the DVM and MFT can provide either line or internal clocking. When one controller is configured to line clocking (obtaining the clocking from the network), the other controller must be configured to internal clocking (obtaining the clocking internally from the other controller). One controller at a time can also be set to loop-timed mode, to loop a clock back to the source when the controller is configured as a backup clock source in a hierarchy of clock sources.

---

Note Configuring a clock source from the DVM is supported if the installed DVM is either hardware Version 4.50 or higher, and the system control board (SCB) is Version 6.05 or higher. To verify the hardware version of the SCB, enter the show version command and check the entry for the Cisco MC3810 processor revision. To verify the hardware version of the DVM, enter the show controller T1/E1 command and check the HWVersion entry.

---

For more information on how to configure clocking for these scenarios, see the "Configuring the Clock Source for the Cisco MC3810" section.

In addition, you can define a hierarchy of potential clock sources so that when the primary clock source goes down, the Cisco MC3810 can automatically switch to a backup clock source. For more information, see the "Configuring a Hierarchy of Clock Sources for Backup Purposes" section.

Configuring the Clock Source for the Cisco MC3810

Because of the different ways that PSTNs provide clocking and how data networks provide clocking, there may be incompatibilities when using the Cisco MC3810 to integrate voice and data networks. As a result, the Cisco MC3810 must synchronize the disparate clocking, and you must be careful in how you configure your clock sources. The clocking can be derived from one of the following sources:

• PBX

• ATM or Frame Relay WAN carrier

• Cisco MC3810's internal clock

Depending on the configuration, you must determine how to configure the appropriate interface on the Cisco MC3810 for the clocking configuration. Each interface provides different clocking support, and depending on the interface used, the commands required to configure the clocking are different. You must also determine whether the Cisco MC3810 interface will be the DCE or the DTE in the configuration.

This section is divided into the following sections:

• Configuring the Cisco MC3810 to Obtain Clocking from the Network

• Configuring the Cisco MC3810 to Use the Internal Clock Source

Configuring the Cisco MC3810 to Obtain Clocking from the Network

This section describes several scenarios for statically configuring clocking on the Cisco MC3810. This section includes the following procedures:

• Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to a T1/E1 Controller

• Configuring a T1/E1 Controller to Loop-Time the Clocking Back to the Network Clock Source

• Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to Serial 0

Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to a T1/E1 Controller

When the Cisco MC3810 recovers clocking from a network device attached to a T1 or E1 controller, the clock recovery circuit on the controller will place a recovered 2-MHz clock on the common circuit toward the network-clock Phase-Lock-Loop (PLL). When the network-clock PLL circuit receives the valid 2-MHz clock from the controller, the network-clock PLL synchronizes to the recovered clock and redistributes the clock to the rest of the system. The other T1/E1 controller and the serial ports on the Cisco MC3810 then derive their clocking from the network-clock PLL.

When you configure a T1/E1 controller to recover clocking from a network device, configure the clock-source controller command to the line setting.

Figure 4-1 shows an example in which the Cisco MC3810 obtains its clock source from a network device attached to controller T1/E1 0 (the MFT). The illustration shows the appropriate clock source command setting to configure on the T1 or E1 controller, and the clock rate network-clock command to configure on the serial ports. The arrows show the propagation direction of the clocking signal.

Figure 4-2 shows an example in which the Cisco MC3810 obtains its clock source from a network device attached to controller T1/E1 1 (the DVM).

Configuring a T1/E1 Controller to Loop-Time the Clocking Back to the Network Clock Source

When you configure a T1/E1 controller to loop-time the clocking back to a network device, you configure the clock-source controller command to the loop-timed setting. The clock-source command on the second T1/E1 controller must be set to the internal setting.

When a controller's clock source is set to loop-timed, that places the internal network clock PLL into free-running mode.

Figure 4-3 shows an example of a configuration in which the input clock source on the MFT is loop-timed back to the clock source device.

Configuring the Cisco MC3810 to Recover Clocking from a Network Device Attached to Serial 0

If serial interface 0 is configured as a DTE, it can accept clocking from the attached DCE and use the clocking to drive the network-clock PLL on the Cisco MC3810. The clocking is then distributed to the T1/E1 controllers and to serial interface 1.

Because the input to the network-clock PLL must be 2 MHz, a clock multiplier circuit is used to multiply the incoming clock on serial 0 to 2 MHz in 8 KHz increments. This multiplier is configured using the clock-rate line serial interface command. This command is valid only when serial 0 is configured as the DTE.

Figure 4-4 shows an example of the Cisco MC3810 obtaining clocking from a network device attached to serial 0.

Configuring the Cisco MC3810 to Use the Internal Clock Source

When you configure the Cisco MC3810 to use the internal clock source, the clock source for both T1/E1 controllers is set to internal and the master clocking is generated from the Cisco MC3810's 2-MHz network-clock PLL. The internal clock source is accurate to a Stratum 4 level (±0.01 percent).

Figure 4-5 shows an example of the Cisco MC3810 using its internal clock source and propagating it outward onto the associated networks.

Configuring a Hierarchy of Clock Sources for Backup Purposes

The previous configurations apply when you want a static network clock source with a single clock source. In some conditions, you may want to define a hierarchy of clock sources so that if the primary clock source fails, the system can be configured to use a secondary source, rather than switching to the internal clock (as in the previous configuration sections).

Clock Source Hierarchy Rules

The following rules apply to configuring the clock source hierarchy:

• If a controller is a potential clock source in the hierarchy, the controller clock source must be configured to line.

• If a controller is a potential clock source in the hierarchy but is not currently being used as the clock source, the clock source setting for that controller is automatically switched to loop-timed. This is a temporary state set by the software to prevent a clocking conflict. If the controller becomes the clock source because another clock source fails, the clock source setting for the controller switches to line.

In this situation, even though the setting for the controller clock is switched to loop-timed, the actual configuration remains line. This is the difference between the preconfigured state and the temporary "set state" of the controller.

• If either controller is the active clock source, the network-clock PLL switch is thrown in the direction of the active clock. The system clock is recovered from the controller with the active clock source.

• If serial interface 0 is the active clock source, the clock source settings for both controllers are automatically set to loop-timed and the network-clock PLL switch is thrown in the direction of the serial interface. The system clock is driven by a clock recovered from the DTE serial 0 interface, which has been multiplied from (n x 8000) Hz to 2 MHz.

• If the internal system clock is the active clock source, the clock source settings for both controllers are automatically set to loop-timed and the network-clock PLL switch is thrown in the direction of the controllers. Because both controllers are in the loop-timed state, neither clock provides a recovered clock to drive the PLL, resulting in a free-running, or internally timed, system clock.

The following is a configuration example showing a hierarchy of clock sources:

network-clock-select 1 t1 0
network-clock-select 2 t1 1
network-clock-select 3 serial0
network-clock-select 4 system
network-clock-switch 10 10
 
controller t1 0
 clock source line
 
controller t1 1
 clock source line
 
interface serial0
 clock rate line 64000

In this configuration, controller T1 0 is the primary clock source, and the clock source is configured to line. Controller T1 1 is a backup clock source and although the clock source is configured to line, the system temporarily sets the clock source to the loop-timed state.

If the controller T1 0 clock source fails, the system switches to use controller T1 1 as the clock source. The clock source loop-timed "set state" on controller T1 1 is switched to the preconfigured line state.

Posted: Tue Feb 22 16:41:42 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.