What is Ring-Switching within a Shared-Ring Protection-Switching System?
COMMENT: Throughout this post, I will be using the terms, Ring-Switching and Ring Protection-Switching interchangeably.
A Shared-Ring Protection-Switching system, whether it is 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.
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 a total 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 also flows in the Clockwise Direction (e.g., the Pink-Shaded Loop, that I’ve labeled P(b)).
- A 3rd Optical Loop is a Protection Transport entity, in which the data is flowing 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 is also flowing in the Counter-Clockwise Direction (e.g., the Blue-Shaded Loop, that 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.
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
Whenever this event occurs, then Node C will declare the SF defect for both 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, then it will also declare the SF-R (Signal Fail-Ring) defect.
Whenever Node C declares the SF-R condition, then 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!!!
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), then these nodes will have to communicate with each other 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 that we show below.
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 as well. I show this “Opposite-Direction” Ring Protection-Switching below in Figure 4.
Figure 4, Opposite-Direction Ring Protection-Switching
If I were to combine the Ring Protection-Switching Paths of both the Defect-Direction and the Opposite Direction, into a single figure; then I get the drawing that I present below in Figure 5.
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 are using 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) creates two separate ring protection loops.
Why can’t we use Span-Switching whenever we have defects in both the Working and Protection Transport entity, within a Span?
In the Span-Switching post, we considered a single defect that is occurring only in the Working-Transport entity (in the span, going from Node B to Node C). As a consequence, Node C declared the SF-W (and, in-turn) the SF-S (Signal Fail – Span) condition.
In this case, we were able to use Span-Switching, because we still had a Protection-Transport entity fiber (that was transmitting data in the same direction as the broken Working Transport entity fiber). Therefore, we were able to simply 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 not available to us, in this scenario.
Therefore, we have to use a different protection-switching approach.