What is Ring Switching?

This post briefly describes and defined Ring-Switching within a Shared-Ring Protection-Switching system.

Sharing is caring!


What is Ring-Switching within a Shared-Ring Protection-Switching System?

COMMENT:  Throughout this post, I will use the terms, Ring-Switching and Ring Protection-Switching interchangeably.

A Shared-Ring Protection-Switching system, whether a 2-Fibre/2-Lambda or a 4-Fibre/4-Lambda system, will support Ring Switching.

NOTE:  A 4-Fibre/4-Lambda Shared-Ring Protection-Switching system will also support Span Switching.  However, the 2-Fibre/2-Lambda Protection-Switching System does not support Span-Switching.

Ring-Switching is a Protection-Switching scheme that involves the entire Ring.

Example of Ring-Switching

Just like what I said in the Span-Switching post, the best way to describe Ring-Switching is to show an example of how it works.

Let’s suppose that we are using a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system.  I present an illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system below in Figure 1.

4-Fibre/4-Lambda Shared-Ring Protection-Switching System

Figure 1, Illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching

This 4-Fibre/4-Lambda Shared-Ring Protection-Switching system consists of four optical rings (or loops).

  • One Optical Loop is a Working Transport entity in which the data flows in the Clockwise direction.  (e.g., the Blue-Shaded Loop that I’ve labeled W(a)).
  • Another Optical Loop is a Protection Transport entity in which the data flows in the Clockwise Direction (e.g., the Pink-Shaded Loop, which I’ve labeled P(b)).
  • A 3rd Optical Loop is a Protection Transport entity in which the data flows in the Counter-Clockwise Direction.  (e.g., the Pink-Shaded Loop, that I’ve labeled P(a)).
  • And finally, the fourth Optical Loop is a Working Transport entity in which the data flows in the Counter-Clockwise Direction (e.g., the Blue-Shaded Loop, which I’ve labeled W(b)).

Now that we’ve introduced our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, let’s move on to Ring Protection-Switching.

Defects in the Fiber

Let’s assume that we are experiencing service-affecting defects within both of the Clockwise-Direction fibers (Working and Protection), between Nodes B and C, as I show below in Figure 2.

Defects in Both Working and Protection Transport Entity - Ring Protection Switching

Figure 2, Illustration of Service-Affecting Defects within both the Working and Protection Transport fibers that were carrying data from Node B to Node C

When this event occurs, Node C will declare the SF defect for the Working Transport entity (SF-W) and the Protection Transport entity (SF-P).  Anytime the Tail-End circuitry (within Node C) declares both the SF-W and the SF-P defect simultaneously, it will also declare the SF-R (Signal Fail-Ring) defect.

Whenever Node C declares the SF-R condition, it will respond to this event by issuing a Ring-Switching request between it and Node B.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Corporate Discounts Available!!!

Implementing Ring-Switching

Nodes B and C will exchange APS command information with each other through a protocol (that we call the Shared-Ring Protection-Switching system APS/PCC protocol).

Since the defects (within this example) affect both the Working and Protection Transport entities (in the Span, going from Nodes B and C), these nodes will have to communicate via both Short- and Long-Paths.

If Nodes B and C only respond and perform Ring Protection-Switching, directly in response to the SF-R defect condition (that Node C has declared), then we get the Ring Protection-Switching results we show below.

Ring-Switching in the Defect Direction

Figure 3, Illustration of Ring Protection-Switching Results (in the Defect Direction)

If you were to study Figure 3, you would see that Ring-Switching works by routing all of the traffic, such that the following is true.

  • That we are routing traffic away from the locations of the defects, and
  • We are still routing traffic through each of the nodes within the Ring.

However, we are not done yet.

ITU-T G.808.2 states that all protection-switching on a Shared-Ring Protection-Switching system must be bidirectional.   Therefore, we must also implement Ring Protection-Switching in the Opposite Direction.  I show this “Opposite-Direction” Ring Protection-Switching below in Figure 4.

Ring-Switching in the Opposite Direction - Opposite from Defect-Direction

Figure 4, Opposite-Direction Ring Protection-Switching

If I were to combine the Ring Protection-Switching Paths of the Defect-Direction and the Opposite Direction into a single figure, I would get the drawing I present below in Figure 5.

Ring-Switching in Both Directions

Figure 5, Bidirectional Ring Protection-Switching

Can the User Implement Ring-Switching at other locations in the Shared-Ring Protection-Switching System?

In general, the answer is No.

In our example, Nodes B and C use the Protection-Transport entity resources within much of the Shared-Ring Protection-Switching system.  This fact makes supporting an additional Ring-Switching path very difficult.

That being said, there might be strange scenarios that one can dream up that (temporarily) create two separate ring protection loops.

Why can’t we use Span-Switching whenever we have defects within the Working and Protection Transport entity within a Span?

In the Span-Switching post, we considered a single defect occurring only in the Working-Transport entity (in the span going from Node B to Node C).  Consequently, Node C declared the SF-W (and, in turn) the SF-S (Signal Fail – Span) condition.

In this case, we could use Span-Switching, because we still had a Protection-Transport entity fiber (transmitting data in the same direction as the broken Working Transport entity fiber).  Therefore, we were able to by-pass the single defect by using Span-Switching.

In this post, we have defects in both the Working and Transport entity fibers (in the span going from Node B and Node C).  Since we now have a defect within the Protection-Transport entity, that path (of by-passing the defect in the Working Transport entity) is unavailable to us in this scenario.

Therefore, we have to use a different protection-switching approach.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You to Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...

Sharing is caring!

Author: Darrell Smith

Darrell Smith has more than 30 years of experience as an Electrical Engineer. He has about 20 years of experience as an Applications Engineer and the remainder of his time was spent in Hardware Design and Product Marketing. He will now be sharing his wealth of knowledge on this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *