What is Span-Switching?

This post defines and describes the term: Span-Switching


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

A 4-Fibre/4-Lambda Shared-Ring Protection-Switching system will support the two types of Protection-Switching.

NOTE:  A 2-Fibre/2-Lambda Shared-Ring Protection-Switching system will NOT support Span-Switching.  It will only support Ring-Switching.

Span-Switching is a Protection-Switching scheme that only involves a single-Span.

Example of Span-Switching

The best way to describe Span-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.  Additionally, I will focus on the Span between Nodes B and C in this case.

Therefore, in Figure 1, I highlight a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system with the span between Nodes B and C.

Span between Nodes B and C

Figure 1, Illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, with the span (between Nodes B and C) highlighted.

If you look closely at the span between Nodes B and C, you will notice that this span contains the following four optical signals.

  • The Clockwise Optical Signal – Working Transport entity (the blue-shaded fiber – with the signal passing through it in the clockwise direction),
  • The Clockwise Optical Signal – Protection Transport entity (the pink-shaded fiber – with the signal moving through it in the clockwise direction),
  • The Counter-Clockwise Optical Signal – Working Transport entity (the blue-shaded fiber – with the signal passing through it in the counter-clockwise direction),
  • The Counter-Clockwise Optical Signal – Protection Transport entity (the pink shaded fiber – with the signal passing through it in the counter-clockwise direction).

Now that we’ve introduced our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, let’s see some protection-switching.

A Defect in the Fiber

Let’s further assume that we are experiencing a service-affecting defect within the Clockwise-Direction Working Transport entity fiber, as I show below in Figure 2.

SF-S Defect in Span between Nodes B and C - Span Switching

Figure 2, Illustration of a Service-Affecting Defect within the Clockwise Direction Working Transport entity fiber (between Nodes B and C)

Whenever this service-affecting defect occurs (within the Span between Nodes B and C), Node C will declare the SF-S (Signal Fail – Span) defect condition.  Node C will respond to this SF-S defect condition by issuing a Span-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 Span-Switching

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

After Nodes B and C have completed this exchange of information (via the APS/PCC protocol), each of these nodes will have executed some protection-switching, such that both Nodes will now be exchanging regular ODUk traffic via the Protection Transport entities (in both directions), rather than using the Defective Working Transport entity (in the Clockwise Direction).

I show the results of this Protection-Switching effort below in Figure 3.

Span-Switching between Nodes B and C

Figure 3, Illustration of Span-Switching, between Nodes B and C

Span-Switching works (in this scenario) because we can use the Protection-Transport entity fiber.  This Protection Transport entity fiber carries traffic in the same direction as the broken Working Transport entity (within the Span, going from Nodes B to C).

Therefore, we can use it to bypass the defect within the Working Transport entity fiber.

NOTE:  All Shared-Ring Protection-Switching will use a 1:1 Protection-Switching Architecture.

Why is this Span-Switching Bidirectional?

Question:

Our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system experienced a single Service-Affecting Defect (within the Working Transport entity of the Clockwise Optical Loop).

Why did we perform Span-Switching in both directions (even for the Counter-Clockwise Optical Loops)?

Answer:

ITU-T G.808.2 states that all Shared-Ring Protection-Switching MUST be Bidirectional.

Therefore, if we are required to perform protection-switching in one direction (to avert a defect condition), we must also complete a similar protection switch in the opposite direction – to make it bidirectional.

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

In a word, Yes.

In our example, Nodes B and C only use the Protection-Transport entity resources between these two nodes.  We have not taken up any other Protection-Transport entity resources along any remaining spans within the ring.

Therefore, the user can have multiple instances of Span-Switching within a Single Ring.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You 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) ...

Shared-Ring Protection Switching

This post briefly defines the term: Shared-Ring Protection-Switching


What is Shared-Ring Protection Switching?

A Shared-Ring Protection Switching system is a Protection System that contains at least three (3) Nodes.

Each Node within this Shared-Ring Protection-Switching System (or Ring) is connected to two neighboring nodes.

I show an illustration of a Shared-Ring Protection-Switching System below in Figure 1.

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

Figure 1, Illustration of a Shared-Ring Protection-Switching System

Figure 1 presents a shared-ring protection-switching system that consists of six (6) nodes that are each connected to a shared ring that contains four (4) Optical loops (or rings).

Some optical rings carry traffic that flows in the clockwise direction (through each node).  Other rings carry traffic that flows in the counter-clockwise direction.

In Figure 1, I have labeled some of these optical loops as “Working” or Working Transport Entity loops and others as “Protect” or Protection Transport Entity loops.

What are the Nodes within a Shared-Ring Protection-Switching System?

Each node (on the Shared-Ring Protection-Switching system) is an electrical/optical system that functions similarly to an Add-Drop-MUX.

Some data traveling on an optical loop (within the ring) will pass through these nodes.  These Nodes also can add in and drop-out some of the data traveling on these loops.

I show the Add-, Drop- and Pass-Through capability of these Nodes below in Figure 2.

Add-Drop MUX features of Nodes in Shared-Ring Protection-Switching

Figure 2, Illustration of the Add-, Drop- and Pass-Through capabilities of a given node, sitting on the shared-ring.  

It is also important to note that each Node can function as either a Source (or Head-End) Node, a Sink (or Tail-End) Node, or both.

Types of Shared-Ring Protection-Switching Systems

ITU-T G.873.2 defines the following two types of Shared-Ring Protection-Switching systems.

  • The 2-Fibre/2-Lambda Shared-Ring Protection-Switching system, and
  • The 4-Fibre/4-Lambda Shared-Ring Protection-Switching system.

Please click on the links above to learn more about these Shared-Ring Protection-Switching systems.

Types of Protection-Switching within a Shared-Ring Protection-Switching System

The Shared-Ring Protection-Switching system can support both the following kinds of Protection-Switching.

Click on the above links to learn more about these types of Protection-Switching within a Shared-Ring Protection-Switching system.

Design Variations for Shared-Ring Protection-Switching Systems

Shared-Ring Protection-Switching systems are available in a wide variety of features.  I’ve listed some of these features and their possible variations below.

Shared-Ring Protection-Switching Types

  • 2-Fibre/2-Lambda Shared-Ring Protection-Switching systems
  • 4-Fibre/4-Lambda Shared-Ring Protection-Switching systems.

Architecture Type

All Shared-Ring Protection-Switching is of the 1:N Protection-Switching Architecture.

Switching Type

All Shared-Ring Protection-Switching is Bidirectional.

Operation Type

All Shared-Ring Protection-Switching systems use Revertive Operation.

APS Protocol – Using the APS/PCC Channel

All Shared-Ring Protection-Switching systems use the APS Protocol.

What about other types of Protection-Switching?

Other types of Protection-Switching Systems are not Shared-Ring, such as Linear or Shared-Mesh Protection-Switching.

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

Discounts Available for a Short Time!!!

Please Click on the Image below to See More Protection-Switching posts within this Blog.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...

What is 1:N Protection Switching?

This post defines and describes the 1:n Protection Switching architecture.

What is the 1:n Protection Switching Architecture?

ITU-T G.808 defines the “1:n (protection) architecture (n >= 1) as:

A 1:n protection architecture has n normal traffic signals, n working transport entities, and one protection transport entity.  

It may have an extra traffic signal.  

At the source end, a normal traffic signal is either permanently connected to its working transport entity and may be connected to the protection transport entity (in the case of a broadcast bridge) or is connected to either its working or protection transport entity (in the case of a selector bridge).  

The sink-end can select the normal traffic signal from either the working or the protection transport entity.  

An unprotected extra traffic signal can be transported via the protection transport entity whenever the protection transport entity is not used to carry a normal traffic signal.

What Does All This Mean?

As for all Protection Groups, a 1:n Protection Architecture consists of the following elements:

  • n instances of the Head-End (or Source-End)
  • n instances of the Tail-End (or Sink-End)
  • and n separate Normal Traffic Signals
  • n sets of Working Transport entities
  • a single Protect Transport entity
  • a single Extra Traffic Signal
  • Protection Switching Controller (that can detect and declare defects within the Normal Traffic Signals).
  • An APS Communications Link/Protocol (Required)

Figure 1 shows a variation of the 1:n Protection Switching architecture.

In this case, we show a 1:2 Protection Switching Architecture.

Basic Drawing of a 1:2 Protection Switching Scheme

Figure 1, Illustration of a 1:2 Protection Switching Architecture

This figure shows that a Broadcast Bridge realizes each of the two Head-Ends (of this Protection Group).  We realize each of the two Tail-ends by a Selector Switch.

I have designated the Broadcast Bridges with the Blue Overlay Shading in this figure.

Likewise, I have designated the Selector Switches with the Red Overlay shading.

NOTES:  

  1. The user can also opt to realize the Head-ends with a Selector Switch for the 1:n Protection Switching Architecture.
  2. Figure 1 includes some other bells and whistles (in the form of some additional Selector Switches) that I will discuss later in this blog.

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

Corporate Discounts Available!!!

How does the 1:n Protection Switching Architecture Work?

One of the noteworthy features of a 1:n Protection Switching Architecture is that you have a single Protection Transport entity that protects n Normal Traffic Signals.

This means that for the 1:n Protection Switching Architecture, you only need 1/n more bandwidth to transport the n Normal Traffic Signals in a protected manner, from the Head-ends to the Tail-ends (where n is the total number of Normal Traffic Signals that you are transporting via this Protection Group).

In contrast, for a 1+1 Protection Switching Architecture, you have one Protection Transport entity protecting one Normal Traffic Signal.

This means that we are providing the Normal Traffic Signal with twice the bandwidth required to transport this signal from the Head-End to the Tail-End in a protected manner.

For many applications, this is inefficient, expensive, and inconvenient.

Of course, this same ratio would also hold if you used a 1:1 Protection Switching Architecture.

Another Key Characteristic of a 1:N Protection Architecture

Another critical characteristic of a 1:N Protection Architecture is the use of Broadcast Bridges on the Head-End Circuitry.  In contrast to a Permanent Bridge, during No-Defect Operation, there will not be a hardwired connection between the Normal Traffic Signal and the Working and Protection Transport entities.  There is only the connection between the Normal Traffic Signal and the Working Transport Entity.  When we are required to perform Protection-Switching, we will close the Broadcast Bridges and complete the electrical connection between the Normal Traffic Signal and the Protection Transport entity.  

We will discuss how the 1:n Protection Switching Architecture works by examining the following cases/conditions.

  • The Normal (No Defect) Case
  • A service-affect defect occurring Working Transport entity # 1
  • Protection Switching (after the defect has been declared).
  • The Normal (No Defect) Case – also using the Extra Traffic Signal

The Normal (No Defect) Case

Figure 2 shows a drawing of the Normal (No Defect) Case.

In this case, we have two Network Elements that are exchanging data with each other.

One Network Element (which we labeled Network Element West) is transmitting data to another Network Element (which we labeled Network Element East).

In most actual applications, we would also have traffic going in the opposite direction (East to West).

But, to keep these figures simple, we are only showing one direction of traffic in each of the figures in this post.

In Figure 2, Normal Traffic Signal # 1 travels over Working Transport entity # 1.

Likewise, Normal Traffic Signal # 2 travels over Working Transport entity # 2.

Additionally, the Extra Traffic Signal is traveling over the Protection Transport entity.

There are no impairments on any of the Working Transport entities, and everything is expected in this case.

1:2 Protection Switching Scheme - Normal Condition - Extra Traffic Signal

Figure 2, Illustration of the Normal (No Defect) Case 

A Service-Affecting Defect occurs in Working Transport entity # 1

Now, let us assume that an impairment occurs in Working Transport entity # 1, such that some circuitry (sitting within the Tail-End of this Working Transport entity, within Network Element East) is declaring either a service-affecting defect such as SF (Signal Fail) or the signal degrade defect, such as SD (Signal Degrade).

In this case, Normal Traffic Signal # 1 can no longer travel on the Working Transport entity # 1.

Figure 3 shows a drawing of this condition.

1:2 Protection Switching Scheme - Defect in Working Transport entity # 1

Figure 3, Illustration of a Service-Affecting Defect Occurring in Working Transport Entity # 1

Protection Switching – After the Defect (in Working Transport Entity # 1) has been declared

Now, since the Tail-End circuitry of Working Transport entity # 1, within Network Element East) has declared this defect condition, it needs to invoke Protection Switching.

In particular, this circuitry needs to perform the following four tasks.

  1. The circuitry within Network Element East needs to switch the local Selector Switch, which I’ve labeled SE1 (at the Tail-End of Working Transport entity # 1), away from this (now failed) Working Transport entity over to selecting the Protection Transport entity.
  2. The Network Element East circuitry also needs to send a command across the Transport entities back to the upstream Network Element (e.g., Network Element West).  In this case, Network Element East will also command Network Element West to invoke Protection Switching (for Working Transport entity # 1).
  3. Next, Network Element West (after it has received this command from Network Element East) then needs to command the Broadcast Switch, which I’ve labeled BBW1 (at the Head-end of Working Transport Entity # 1) to switch such that Normal Traffic Signal # 1 is now also connected to the Protection Transport entity.
  4. Finally, Network Element West needs to pre-empt the Extra Traffic signal by opening the switch that I’ve labeled SWP.  Once this switch is OPEN, the Extra Traffic signal will no longer travel across the Protection Transport entity.

In this case, Normal Traffic Signal # 1 will now travel (from Network Element West to Network Element East) using the Protect Transport entity.

Figure 4 presents the resulting configuration (with Network Elements East and West) after protection switching.

1:2 Protection Switching Scheme - Protection EventFigure 4, Illustration of our 1:2 Protection Switching Protect Group, following Protection Switching

NOTE:  Protection Groups using the 1:n Protection Switching scheme are required to support an APS Communications Channel to command and coordinate Protection Switching activities between the Head-ends and Tail-ends of the Protection Group.

This is how 1:N Protection Switching works.

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

Discounts Available for a Short Time!!

Additional Options in the 1:n Protection Switching Architecture

There are several options that users can use when designing a 1:n protection switching scheme.

Some of these options include:

  • Transmitting the NULL Signal during the Normal (No Defect) Case – as the Extra Traffic signal.
  • Transmitting the FDI/AIS signal during Protection Switching
  • Revertive Protection Switching
  • Unidirectional or Bidirectional protection switching

We will briefly discuss each of these options below.

Transmitting the NULL Signal during the Normal (No Defect) Case – as the Extra Traffic Signal.

In some cases, the user can transmit the NULL signal as the Extra Traffic signal (via the Protect Transport entities) anytime each of the n Working Transport entities is defect-free and is functioning properly.

In the Protection Group (discussed in this post), we could close the Switch labeled SN and open the Switch labeled SWP (within Network Element West).

This configuration setting would allow the NULL signal (that originates from Network Element West) to flow through the Protect Transport entity, as shown in Figure 5.

1:2 Protection Switching Sceme - Normal with NULL Signal

Figure 5, Transmitting the NULL Signal via the Protect Transport Entity, during Standby Times.  

Transmitting the FDI/AIS signal during Protection Switching

In many cases, the user will transmit the FDI/AIS signal towards the circuitry downstream from Network Element East by switching the switch, which I’ve labeled SEP (within Network Element East), away from the Protect Transport entity towards the FDI/AIS signal source.

Figure 4 (above) shows Network Element East transmitting the FDI/AIS indicator towards downstream traffic during Protection Switching.

The user would typically only do this whenever the Extra Traffic Signal (e.g., the NULL signal or some other low-priority signal) has been pre-empted due to a Protection Switching event.

The purpose of transmitting this FDI/AIS signal is to alert downstream equipment of a service-affecting defect condition within one of the Working Transport entities between Network Elements East and West.

NOTE:  For OTN applications, the Network Element will transmit the ODUk-AIS indicator during these protection switching events.

Revertive Protection Switching

Some Protection Groups will support Revertive operations, and others will not.

Suppose you designed a Protection Group to support Revertive operations.  In that case, the Protection Group will automatically reroute the affected Normal Traffic Signal back through its Working Transport entity shortly after the servicing-affecting defect (which caused the protection switching event in the first place) has cleared.

1:n Protection Switching systems typically support Revertive operations, whereas 1+1 Protection Switching systems may NOT support Revertive operations.

If a 1:n Protection Switching system was to support Revertive operations, then the Network Element that first declared (and is now clearing) the service-affecting defect; would have to send a command back to the other (remote) Network Element to coordinate revert protection switching activities (between both the Head-Ends and Tail-Ends of the Protection Group).

Please see the post on the Revertive Operation and the Automatic Protection Switching Channel for more details on this topic.

Unidirectional or Bidirectional Protection Switching

A 1:n Protection Switching scheme can support either Unidirectional or Bidirectional Protection Switching.

If the Protection Group supports Unidirectional Protection Switching, then the Network Element (that detects and declares the Service-Affecting defect within one of the Working Transport entities) will need to send the necessary command information (back to the upstream Network Element) to command and coordinate the Unidirectional Protection Switching event.

Conversely, suppose the Protection Group supports Bidirectional Protection Switching.  In that case, the Network Element (that detects and declares the Service-Affecting defect) will need to send the necessary command information (back to the upstream Network Element) to command and coordinate the Bidirectional Protection Switch.

Please see the posts for Unidirectional and Bidirectional Protection Switching for more details on this topic.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You 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) ...

What is 1+1 Protection Switching (APS)

This post defines and describes the term 1+1 Protection Switching.


What is 1+1 Protection Switching?

ITU-T G.808 Defines 1+1 (Protection) Architecture as:
A 1+1 protection architecture has one normal traffic signal, one working transport entity, one protection transport entity, and a permanent bridge.
At the source end, the normal traffic signal is permanently bridged to both the working and the protection transport entities.  

At the sink end, the normal traffic signal is selected from the better of the two transport entities.

Due to the permanent bridging, the 1+1 (protection) architecture does not allow an unprotected extra traffic signal to be provided.  

What Does All This Mean?

As for all Protection Groups, a 1+1 Protection Architecture consists of the following elements.

Figure 1 presents an illustration of a 1+1 Protection Switching Architecture.

1+1 Protection Switching Architecture - Normal Operation

Figure 1, Illustration of a 1+1 Protection Switching Architecture – Normal (No Defect) Condition

How to Know if You’re Working with a 1+1 Protection Architecture?

This figure shows that a Permanent Bridge realizes the Head-End (of this Protection Group) and that a Selector Switch realizes the Tail-end.  This is a crucial characteristic of the 1+1 Protection Architecture.  

As we defined earlier (from the excerpts of ITU-T G.808), the Permanent Bridge means that there is a hardwired connection between the Normal Traffic Signal and both the Working and Protection Transport entities at the Head-End circuitry.  This fact helps you to identify a 1+1 Protection Architecture quickly.  This is not the case for a 1:N Protection Architecture.  

You can see all of this in Figure 1.  

No-Defect Operation of the Normal Traffic Signal in a 1+1 Protection Architecture

The Normal Traffic Signal will travel through the Working Transport entity for normal conditions, as shown in Figure 1.

Although the Normal Traffic signal is bridged (or connected) to both the Working and Protect Transport entities, it only flows through the Working Transport entity because we connected the Selector switch to the Working Transport entity.

Whereas the Selector Switch leaves the connection between the Protection Transport entity and the Tail-End circuitry, OPEN.

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

Corporate Discounts Available!!!

A Service-Affecting Defect occurs.

Now, let us look and see what happens if “bad things” occur.

Figure 2 presents an illustration in which an impairment now exists within the Working Transport entity; this impairment causes the Protection Controller (not shown but sitting behind the Tail-end circuitry) to declare a Service-Affecting defect (e.g., SF) or SD.

1+1 Protection Switching Architecture - Defect Condition

Figure 2, Illustration of a Service-Affecting Defect within the Working Transport entity

In this case, the Normal Traffic signal can no longer travel through the Working Transport entity.

If our circuitry did not have any protection switching capability, then all the customers (and end-users) of the Normal Traffic Signal would lose their service.

This would be very bad, especially for the service provider and their financial future.

Protection Switching Occurs

Fortunately, this system does offer protection switching.

In this case, since the Protection Controller has detected and declared a service-affecting defect condition within the Working Transport entity signal, it will then switch the Selector such that it is now connected to the Protect Transport entity, as we show in Figure 3.

1+1 Protection Switching - Protection Switching Condition

Figure 3, Illustration of Normal Traffic signal flow – following Protection Switching

Once the Selector switches over and connects to the Protection Transport entity, the Normal Traffic signal will flow through the Protection Transport entity.

This is an excellent thing for all parties involved.

The users (of the Normal Traffic signal) will get their data or have their service still available.  And the service provider will have fewer irate customers and nasty phone calls.

Other Considerations for 1+1 Protection Switching

The 1+1 Protection Switching Architecture is quite simple.

We usually implement the head-end with a Permanent Bridge and realize the tail-end with a Selector switch.

However, there are some variations that we need to consider for the 1+1 Protection Switching architecture.

Unidirectional or Bidirectional Switching

The user can design their 1+1 Protection Switching architecture to be either a Unidirectional or Bidirectional type.

Please see the Unidirectional and Bidirectional Protection Switching posts for more details on these terms.

NOTE:  If you intend to use Bidirectional Protection Switching, then you will need to use some form of APS communication link/protocol to coordinate the switching of both ends of the protection group.

Protection Ratio:

The protection ratio for a 1+1 Protection Switching system is not very good.  This situation is not good because the user must design twice (2X) the bandwidth of the Normal Traffic signal.

We have to allocate 1X of the bandwidth for the Working Transport entity and 1X for the Protection Transport entity.

To Revert or Not-Revert

If a Protection Switching architecture supports “revert” (or reverting), then this means that the Selector switch will automatically switch back to the Working Transport entity once the service-affecting defect (which caused the switching event) has cleared.

Please see the post on revert for more details about this option.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You Become an Expert on OTN and Protection-Switching!! 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) ...

Bidirectional Protection Switching

This post defines the term Bidirectional Protection Switching for APS (Automatic Protection Switching) applications.


What is Bidirectional Protection Switching (and How is it Different from Unidirectional Protection Switching)?

The Definition of Bidirectional Protection Switching

ITU-T G.780 defines Bidirectional Protection Switching as follows:

A protection switching architecture in which, for a unidirectional failure (i.e., a failure affecting only one direction of transmission), both directions (of the “trail,” “subnetwork connection,” etc.), including the affected direction and the unaffected direction, are switched to protection.  

What does All That Mean?

I will explain all this through three (3) illustrations/cases.

  • The Normal/No Defect Case
  • The Defect/Bidirectional Protection Switching Case and
  • The Defect/Unidirectional Protection Switching Case

The Normal/No Defect Case

Figure 1 illustrates a “Normal” (e.g., No Defect) condition.

This illustration shows two network elements transmitting and receiving traffic to and from each other.

We will call one of these network elements Network Element West and the other network element Network Element East.

Normal Traffic/No Defect Condition - Protection Switching

Figure 1, Illustration of two Network Elements exchanging traffic during Normal/No-defect conditions.

Figure 1 also shows Protection Switching support for the traffic flow between these two Network Elements.

This figure shows a Bidirectional Working Transport Entity between these two Network Elements.

The figure also shows that there is a Bidirectional Protection Transport Entity between these two Network Elements, as well.

In this case, neither Network Element declares any defect within the Working Transport Entity, and Good/Normal Bi-directional traffic flows between these two Network Elements.

Finally, this figure also shows that all the traffic flows through the Working Transport Entities and that none of the traffic flows through the Protect Transport Entities.

Next, we will consider what happens whenever one Network Elements declares a service-affecting defect within the Working Transport Entity.

Bidirectional Protection Switching Case

Figure 2 presents an illustration of a Defect condition.

In this case, some impairment exists within the West-to-East Working Transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Bidirectional Protection Switching

Figure 2, Illustration of Bidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport connection (in the West-to-East direction), this protection switching scheme will route all West-to-East traffic through the Protect Transport Entity instead.

Yet, this protection scheme does not stop there.  It will also route all East-to-West traffic through the Protect Transport entity.

In other words, if we detect a defect within the Working Transport Entity (at all), we will route traffic for BOTH directions from the Working Transport entity to the Protect Transport entity.

We call this particular protection scheme Bidirectional Protection Switching because, in this case, we are performing protection switching in BOTH directions, even if we only declare a service-affecting defect in one direction.

NOTE:  Since we perform protection switching in BOTH directions (for bidirectional protection switching), this kind of protection scheme requires that the protection group uses an APS or PCC (Protection Communications Channel).

Both ends of the protection group will need to communicate and coordinate with each other during protection switching events.

We will clarify the difference between Bidirectional and Unidirectional Protection Switching by showing the Unidirectional Protection Switching Case.

Unidirectional Protection Switching Case

Figure 3 presents another illustration of a Defect condition.

In this case, there is (once again) some impairment that exists within the West-to-East Working transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Unidirectional Protection Switching

Figure 3, Illustration of Unidirectional Protection Switching – responds to a Service-Affecting Defect in one direction on traffic.

Since this defect exists within the Working Transport Entity, this protection scheme will route all West-to-East traffic through the Protect Transport entity.

Yet, in contrast to the Bidirectional Protection Switching scheme, it will continue to route all East-to-West traffic through the Working Transport entity; since there are no defects in that particular direction.

In other words, the Unidirectional Protection Switching scheme only routes the traffic directions (the Network Element has determined to be defective) through the Protect Transport Entity.

If it detects no defects within a given Working Transport entity (in the other direction), it will continue to route that traffic through the Working Transport entity.

We call this particular protection scheme Unidirectional Protection Switching because, in this case, we are performing protection switching in ONE direction if we only detect a service-affecting defect in ONE direction.

Please see the Unidirectional Protection Switching post for more detailed information on this protection switching scheme.

Summary

In summary, the main difference between Unidirectional and Bidirectional Protection switching is as follows.

For Bidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), the protection scheme will still switch BOTH directions of traffic from the Working to the Protect Transport entity.

In the case of Unidirectional Protection Switching, if the Network Elements declare a service-affect defect in ONLY one direction (of traffic), then the protection scheme will only switch the defective direction from the Working Transport entity to the Protect Transport entity.

The other (non-defective) direction of traffic will continue to use the Working Transport Entity.

Has Inflation got You Down? With Our Pricing Special, You Can Beat Inflation and 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) ...

Unidirectional Protection Switching

This post defines the term Unidirectional Protection Switching for APS (Automatic Protection Switching) applications.


What is Unidirectional Protection Switching (and How is it Different from Bidirectional Protection Switching)?

The Definition of Unidirectional Protection Switching

ITU-T G.780 defines Unidirectional Protection Switching as follows:

A protection switching architecture in which, for a unidirectional failure (i.e., a failure affecting only one direction of transmission), only the affected direction (of the “trail,” or “subnetwork connection,” etc.) is switched to protection.  

What does ALL that Mean?

I will explain all this through three illustrations/cases

  • The Normal/No Defect Case
  • The Defect/Unidirectional Protection Switching Case and
  • The Defect/Bidirectional Protection Switching Case

The Normal/No Defect Case

Figure 1 illustrates a “Normal” (e.g., No Defect) condition.

This illustration shows two network elements transmitting and receiving traffic to and from each other.

We will call one of these Network Elements Network Element West and the other Network Element Network Element East.

Normal Traffic/No Defect Condition - Protection Switching

Figure 1, Illustration of two Network Elements exchanging traffic during Normal/No-defect conditions.  

Figure 1 also shows Protection Switching support for the traffic flow between these two Network Elements.

This figure shows a Bidirectional Working Transport Entity between these two Network Elements.

The figure also shows that there is a Bidirectional Protect Transport Entity between these two Network Elements, as well.

In this case, neither Network Element declares any defect within the Working Transport Entity, and Good/Normal Bi-directional traffic flows between these two Network Elements.

Finally, this figure also shows that all the traffic flows through the Working Transport Entities and that none of the traffic flows through the Protect Transport Entities.

Next, we will consider what happens whenever one Network Elements declares a service-affecting defect within the Working Transport Entity.

Unidirectional Protection Switching Case

Figure 2 presents an illustration of a “Defect” condition.

In this case, some impairment exists within the West to East Working Transport entity, and Network Element East is declaring some service-affecting defect with this traffic signal.

Unidirectional Protection Switching

 

Figure 2, Illustration of Unidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport entity (in the West-to-East direction), this protection switching scheme will route all West-to-East traffic through the Protect Transport Entity instead.

Please note this protection switching event only applies to the traffic within the West-to-East Direction.

Since Network Element West is not declaring any defects within the East-to-West Working Transport Entity, the East-to-West traffic will continue to travel via the Working Transport Entity (even though the West-to-East traffic has been switched over to the Protect Transport Entity.

We call this particular protection scheme Unidirectional Protection Switching because, in this case, we only perform protection switching in the ONE direction that has the service-affecting defect.

We will clarify the difference between Unidirectional and Bidirectional Protection Switching by showing the Bidirectional Switching Case.

Bidirectional Protection Switching Case

Figure 3 presents another illustration of a Defect condition.

In this case, there is (once again) some impairment that exists within the West-to-East Working transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Bidirectional Protection Switching

Figure 3, Illustration of Bidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport connection, this protection switching scheme will route all “West-to-East” traffic through the Protect Transport entity instead.

Yet, this protection switching scheme does not stop there.  It will also route all East-to-West traffic through the Protect Transport entity.

In other words, if we detect a defect within the Working Transport Entity (at all), we will route the traffic for BOTH Directions from the Working Transport entity to the Protect Transport entity.

We call this particular protection scheme Bidirectional Protection Switching because, in this case, we are performing protection switching in BOTH directions, even if we only detect a service-affecting defect in one direction.

Please see the Bidirectional Protection Switching post for more detailed information on this protection switching scheme.

Summary

In summary, the main difference between Unidirectional and Bidirectional protection switching is as follows.

For Unidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), then the protection scheme will only switch the defected traffic direction from the Working Transport Entity to the Protect Transport Entity.  The other (non-defective) traffic direction will continue to use the Working Transport Entity.

In the case of Bidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), then the protection scheme will switch BOTH directions of traffic from the Working Transport Entity to the Protect Transport Entity.

Has Inflation Got You Down? With Our Special Pricing, You Can Beat Inflation, and You Can Be 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) ...