MSTP Timing

[tgimmel]

We have installed new MSTP systems. The documentation is very unclear on when timing is needed on MSTP. In fact, we have been told that transpondes do not need timing at all, for they recover timing from the Rx OC stream. Does anyone have any experience with timing and MSTP? Can I transport timing with the OSC's?

Thanks,

Tim

[thomas.chen]

DWDM interfaces are not synchronized.

MSTP nodes in a network, in any case, leverage on the OSC to share a synchronization signal at network level. This synch signal is transported over the OC-3 framed OSC signal and is used for the network-level applications (e.g. APC and WPP) to have the possibility to have a token-based communication protocol.

Tom

[tgimmel]

It makes sense that DWDM interfaces would not need timing in a lot of cases. If I was bringing in a another customer's signal, I have no way of knowing what his timing is and/or if he is a timing island; I wouldn't want to force timing on the customer. But what if I WANT to put timing in the transponder, perhaps it's its at a place in the network that a new stratum 1 timing need to be placed on the signal (one of the "R's"), how can I do it?

Another question: if timing is recovered from the rx of the client side of the transponder, and that clock is used to time the line side transmit, then is the converse true on the line side?

Tim

[cxa23]

In order to fully answer your questions it is important to understand how timing works within an optical transport system. Timing is carried within the SONET (or SDH) Line overhead. Transponders only terminate the Section overhead bytes (A1, A2, B1, etc) for framing, error checking, and DCC between nodes thus they are incapable of being timed or providing timing to downstream equipment. In order to inject timing into an optical stream it must be done at a card where process Line overhead (such as an ADM). A signal carried by a transponder card must be timed prior to its introduction to the transponded network. This may seem an unwise or unfavorable practice but consider that in order for the transponder to be truly transparent to the traffic it carries this becomes necessary. The whole point of using transponders is to provide the customer with a protocol independent environment with which to transport signals between 2 points.

Timing is a function of multiplexing in order to allocate STS channels or timeslots for DS3 mapping or OC3c/OC12c/OC48c/OC192c aggregation and transport into larger SONET payloads (i.e. 4xOC48 signals muxed into 1xOC192 signal). The best analogy I have found for transponders is to compare them to Ethernet hubs as they are in effect a simple repeater.

DWDM cannot be timed as it is a physical medium for transporting signals, nothing more. The OSC is an out-of-band management channel that has no influence on the optical channels riding adjacent to it. The OSC will derive timing for itself from the shelf/node timing source.

Clay

[tgimmel]

Clay,

Thanks for the info. I completely missed that timing was carred in the line overhead. Thank you very much for the explanation and I will forward it on to others here, as this has been a perplexing subject.

Thanks,

Tim

[ranzhang]

An MSTP system can get its timing just like a typical 15454 system. Additionally it can get its timing from the OC3 interface in an OSC (one form of line timing) or from one of its transponder line interfaces (also line timing).

How transponders use timing for its signals depend on the type of transponders and payload. For example, a 3R transponder uses the system timing to retime the signal. In a 2R case, timing is recovered on the Rx and transparently used for the Tx. In this case, system clock is not used.

It is incorrect that SONET/SDH line overhead provides timing signals. It does not. What it does provide is SSM in S1 byte. SSM provides the quality information of the Tx clock but not the clock signal itself. The receiving system needs to recover the clock from the bit streams and not from the S1.

[tgimmel]

Randy,

Ok, so in this instance, I am using TXP_MR_2.5G transponder card and I would like to inject _new_ timing from the system onto signal that is passing through the transponder. How would I provision the TXP card in CTC to make this happen (assume that the chassis has an external BITS clock attached and BITS-1 and BITS-2 are enabled)?

Tim

[ranzhang]

Tim,

Here is my understanding: if a transponder supports retiming (3R) or provisioned such with the supported payload type, it will use the system clock (or NE clock) on all its Tx timing and no specific configuration is required.

In the case of TXP_MR_2.5G transponder, it can perform 2R or 3R depending on the payload type provisioned.

3R payload: OC3/OC12/OC48, GE, 1G FC/FICON, 2G FC/FICON,

2R payload (unframed): ESCON, HDTV etc

In 2R mode, signal is passed through without performance monitoring. In 3R mode, digital wrapper is applied and removed on the trunk side.

Also in my previous reply, TCC can get its timing in an MSTP shelf from two additional sources when it is in line timing mode: OSC and client signals. So you do not always need external clocks directly attached.

Randy

[ranzhang]

OK my statements in my previous reply are not completely accurate or clear. Let me correct myself and restate the following:

A transponder can support 2R and 3R depending on the type of transponder and the payload type. For 3R operations, a transponder can get its timing from several sources depending on the type of transponder: system clock, line clock (recovered from client signals), and internal clock. The system can get its clock from a variety of sources: BITS, optical lines including OSC and client signals, and internal oscillator.

For the specific transponder mentioned previously (TXP_MR_2.5G), retiming is supported if payload falls into the catrgory listed previously. The source of the retiming comes from the line (recovered) and no specific provisioning is required.

The termination mode provisioned on the transponder only relates to SONET/SDH overhead termination and is not relevant to timing signal.

Randy