STM4 Circuit Fails During Transport Through a Third Party Carrier

Available Languages

Download Options

PDF (50.5 KB)
View with Adobe Reader on a variety of devices

Updated:September 5, 2006

Document ID:68800

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

Background Information

Problem

Solution

Related Information

Introduction

This document describes one reason for the failure of the STM-4 to come up during transport through the network of a service provider. This document also provides a solution to the problem.

Prerequisites

Requirements

Cisco recommends that you have knowledge of Cisco ONS 15454.

Components Used

The information in this document is based on Cisco ONS 15454.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

In the term VC-4-4C, the first 4 represents the VC-4 formatting type and the second 4 stands for the total width of the flow, in VCs (see Figure 1).

Figure 1 – VC-4-4C

Contiguous concatenation has been a part of the TDM specification for quite some time. The TDM payload containers are transported and switched across the SDH network as a single module. The first SDH container payload pointer is set to normal mode, and the subsequent payload pointers are set to concatenation mode, and thus link all the units together.

Problem

Two ONS15454E nodes with TCC2P and STM16 backbone run ONS 15454 version 6.0. When you try to to create a point-to-pint STM-16 that transports data over the SDH network of a service provider, the STM-16 network fails to synchronize through the third party network (see Figure 2).

Figure 2 – Topology

Solution

The output of the OC/STM card is whetever the XC sends. So if you create a circuit between two OC/STM cards, the output is just what the cards receive. The OC/STM cards forward what they receive, and do not affect the overhead and payload.

The service provider needs to channelize the STM-16 exactly as the circuits are created in the ONS nodes. If the service provider does not channelize the STM-16 properly, only the first circuit operates (see Figure 3).

Figure 3 – Incorrect Transport

In this particular case, you do not have a "clear channel" span that connects the ONS15454s. Therefore, the ONS15454s must have the service provider provision these STM-16s to match your provisioning. So for example, if you create a 4c (AU-4-1 through AU-4-4), the service provider also has to create this on the STM-16 (see Figure 4).

Figure 4 – Correct Transport