Working and Protect Paths

[curt.ritter]

Running a 17 node ONS-15454, UPSR Ring with Software ver. 6.0.3.

Why is it that when viewing or editing some circuits you do not see a Protect Path? On most circuits, you see a green working path and the purple protect path. We occasionally see circuits that have no protect path, only a green path that travels the entire ring. We can manually force to protect, which then clearly defines the protect path, but when we "Clear" the Switch State it reverts back to showing no protect path.

Why would these few circuits not have a defined protect path that shows up in the circuit details? Was there a problem when the circuit was originally created?

[aareed]

Curt,

When a UPSR circuit is created, CTC evaluates the available receive paths at each end of the circuit and will select the best available path as its primary path.

In the Circuit edit screen any path that has a working direction on it will be shown in green while a protect is shown in purple.

When you are seeing Green on both sides of the ring, this is an indication that the receivers for each side are using opposite paths.

If you have reversion enabled, the default path of the circuit will be restored after the hold down timer for the UPSR switch has cleared.

If you are concerned about keeping all traffic on one side of a ring, when you create the circuit you can select the "Provision working go & return on Primary path" option under the UPSR box of the Circuit Creation wizard.

Please see the following link for further details:

http://www.cisco.com/en/US/docs/optical/15000r6_0/15454/sonet/procedure/guide/r60dlp2.html#wp1047917

DLP-A218 Provision Path Protection Selectors

[curt.ritter]

What limitations, if any, are there when you select the "Provision working go & return on primary path" option?

Will the system switch properly should there be a cut anywhere on either the working or protect paths?

Does this change the functionality if the SONET is set up as a Path Protected Mess Network?

[aareed]

There are no limitations, the path protection will switch correctly. This does not change the functionality, it is only forcing CTC to use the same path in circuit creation.

[Tom Randstrom]

You are fine.

In a traditional Telcordia compliant system, the working transmit (go) and receive (return) paths of a unidirectional path switched ring (UPSR) network run over the same fiber spans. Thus, when a particular span goes down, the receivers (go and return) switch to the protection Tx and Rx path.

The protected mesh (PPMN) capabilities of the 15454 allow the go and returns to be on two separate paths. In the event of a span down, whichever path (go or return) that is operating over the down span, the receiver will switch to the operational path.

UPSR/PPMN - For each direction of the circuit (go and return), the signal is split (working and protection) and sent through two paths through the network. At the end of the circuit, the two signals are received and a selector switch decides which signal is better. Thus, the working a protection signals are always present. Just a matter of which is selected at the end of the circuit.

[curt.ritter]

Would you then recommend selecting or de-selecting the "Provision working go & return on primary path" option?

[aareed]

I would recommend Selecting it if you are wanting to ensure your Transmit and Receive are traveling on the same path.

[Tom Randstrom]

I believe using the "Provision the working go & return" on the primary path simplifies understanding and tracking in the network.

Just my view.

[rspell]

Curt,

When going to the Edit circuit screen are you looking at the detailed map by checking on the box at the bottom of the Edit circuit screen?

If you are looking at the non-detailed map of the circuit, you will see green links all the way around the ring unless your transmit and receive are using the same span. The detailed map will show you where each node is transmitting and receiving. By forcing the circuit to the protect path, you are moving both tx and rx to one path, thereby showing the green and purple lines in the non-detailed circuit map.

[curt.ritter]

I'm looking at the both the detailed and non-detailed views. See attached.

This question stems from an issue we had where a fiber was cut between two nodes and only 95% of the traffic switched. 10 of 14 circuits in one STS did not switch.

Almost all of our circuits were created with the "Provision working go and return on primary path" selected. Could this present a problem and should the circuits be re-created?

[aareed]

Curt,

Traffic should have switched. I would recommend that you open a TAC case to troubleshoot this issue further.

Possible issues that would cause this would be if you had a forced switch active on on of your spans, or possible a defective cross connect.