OTN – Lesson 12 – Detailed Discussion of SNC/I Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) SNC/I (Subnetwork Circuit – Inherent) Monitoring for Protection Switching.

Lesson 12 – Video 4 – Detailed Discussion of SNC/I (Subnetwork Circuit – Inherent) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of SNC/I Monitoring, both at the OTU and ODU layers.

In particular, this video will discuss the following topics:

  • How to perform SNC/I Monitoring at the OTU Layer
    • What Circuitry (Atomic Functions) that we should use
    • What defects to monitor
    • Which is the Normal Traffic Signal when doing SNC/I Monitoring at the OTU Layer.
    • What happens when we declare an OTU Layer Service-Affecting defect (dLOS, dLOF, dLOM, dLOL, dLOFLOM, dLOR, dAIS, and dTIM)?
    • What happens when we declare the SM-dDEG (OTU-layer Signal Degrade) defect?
    • How does protection-switching work?
  • How to perform SNC/I Monitoring at the ODU Layer
    • What Circuitry (Atomic Functions) that we should use
    • What defects to monitor
    • Which is the Normal Traffic Signal when doing SNC/I Monitoring at the ODU Layer.
    • What happens when we declare an ODUk Server-Layer service-affecting defects (such as dAIS, dOCI, dLCK, dTIM, dLOOMFI, and dPLM)?
    • What happens when we declare ODUj Tributary-Layer service-affecting defects (such as dLOFLOM and dMSIM)
    • What happens when we declare the PM-dDEG (ODU-layer Signal Degrade) defect?
    • How does protection-switching work?

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Detailed Discussion of SNC/I Monitoring (Protection Switching)”

OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario Video

In this video, we presume that some ODUk- (or OTUk-) Layer circuitry is declaring a certain defect condition. We then determine how ODU-layer circuitry is expected to respond.

OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario for Multiplexed and Non-Multiplexed Applications

This video summarizes the various defects that OTN circuitry can declare/clear at the ODU-Layer.  

This video also describes how ODU-Layer circuitry is expected to respond to each ODU-Layer (or upstream OTU-Layer) defect.  

  • Should it transmit PM-BDI (Path Monitoring – Backward Defect Indicator) upstream?
  • Should it replace the under-lying 100oBASE-X or 100GBASE-R client signal with the Link or Local Fault Indicator?  

This video answers these questions and more.  

NOTE:  This video covers both Non-Multiplexed and Multiplexed Applications.

Continue reading “OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario Video”

OTN – Lesson 10 – Video 6M – End of ODU-Layer/Multiplexed Sink Circuitry

This post presents the 6th of the 6 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Multiplexed Applications). This post focuses on the Sink Direction ODU-Layer Atomic Functions.

OTN – Lesson 10 – Video 6M – The ODU0_TT_Sk and ODUkP/CBR_ETC1000X_A_Sk Atomic Functions

This blog post contains a video that wraps up our discussion of the Sink (or Receive) Atomic Function circuitry for the ODU-Layer/Multiplexed Applications.  

More specifically, this video includes a discussion of the following Atomic Functions.

  • ODU0_TT_Sk Function, and
  • ODU0P/CBR_1000X-g_A_Sk Function

Continue reading “OTN – Lesson 10 – Video 6M – End of ODU-Layer/Multiplexed Sink Circuitry”

OTN – Lesson 10 – Video 4N – More of the ODUk_TT_Sk Atomic Function

This post presents the 4th of the 7 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Non-Multiplexed Applications). This post focuses on the Sink Direction ODU-Layer Atomic Functions. More specifically, this post includes a video that describes how the ODUk_TT_Sk Atomic Function declares and clears the dTIM, ODUk-AIS, dLCK and dOCI defect conditions.

OTN – Lesson 10 – Video 4N – More of the ODUk_TT_Sk Atomic Function

This blog post includes a video that continues to describe the role/functionality of the ODUk_TT_Sk atomic function

In particular, this video explains how the ODUk_TT_Sk function declares and clears the following defect conditions.  

  • dTIM – Trail Trace Identifier Mismatch defect
  • dAIS – ODUk-AIS defect condition
  • dLCK- ODUk-LCK defect condition
  • dOCI – ODUk-OCI defect condition

Continue reading “OTN – Lesson 10 – Video 4N – More of the ODUk_TT_Sk Atomic Function”

Lesson 2 – ODU Framing

This post provides a comprehensive review and video training of the ODU frame and its overhead fields.

Lesson 2 – ODU (Optical Data Unit) Frame Training

This post presents a video that discusses the ODU (Optical Data Unit) Frame in considerable detail.  

In addition to discussing the ODU frame format, this video also discusses the ODU overhead fields and their roles.

Finally, this video discusses special ODUk signals, such as ODU0, ODU2e, and ODUflex.  

Continue reading “Lesson 2 – ODU Framing”

What is Defect Correlation?

This post briefly defines and explains what Defect Correlation means. In short, the Defect Correlation equations will specify how we expect a system to respond to a specific defect condition.

What is Defect Correlation, and How Should You Interpret It?

The purpose of this blog post is two-fold.

  • To describe the concept of Defect Correlation and
  • To discuss how to interpret the meaning of Defect Correlation and their Equations.

Introduction

Numerous ITU Standards (such as ITU-T G.798 for OTN applications) will define various aspects of defects. These standards will define a defect, such as dLOS (the Loss of Signal) and dLOF (the Loss of Frame).

These standards will (sometimes) describe the conditions that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.

For instance, ITU-T G.798 specifies all of the following defects that an OTN STE can declare and clear.

(*) – Requires membership to THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! to see these links.  

And it is excellent that the ITU-T standard committee does this for us.

But let’s now take a closer look at these defects from a System-Level standpoint.

Should One Defect Lead to Many Other Defects?

Suppose an OTN STE declares the dLOS-P (Loss of Signal-Path) defect condition with its incoming optical lanes or signal.

This STE will declare the dLOS-P condition for one of two reasons.

  1.  Because the optical components (upstream) are detecting too little optical signal energy (within the incoming signal) or
  2. the Clock and Data Recovery circuitry (within the STE electronics) is detecting an absence of recovered (data) signal activity for an extended period.

In Figure 1, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOS-P defect.

OTSi/OTUk-a_A_Sk Function declares dLOS Defect - Defect Correlation

Figure 1, The OTSi/OTUk-a_A_Sk Atomic Function, declares the dLOS Defect Condition.  

In either of these cases, it is clear that this OTN STE should declare the dLOS-P defect condition.

How about the dLOF Condition?

However, if that same OTN STE is not receiving any discernable signal from the remote STE, it is safe to say that it will not be receiving the FAS fields (within this now non-existent incoming data stream).

Should this OTN STE also declare the dLOF defect as well?

In Figure 2, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOF defect condition and the dLOS-P defect condition.

OTSi/OTUk-a_A_Sk Function Declares both the dLOS and dLOF Defects

Figure 2, The OTSi/OTUk-a_A_Sk function declaring the dLOF and dLOS-P Defect Conditions

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

Corporate Discounts Available!!!

What about the dLOM Condition?

And since the OTN STE is not receiving any FAS field bytes, it cannot locate the MFAS bytes.

Should this OTN STE also declare the dLOM defect too?

In Figure 3, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOM, dLOF, and dLOS-P Defect conditions.

OTSi/OTUk-a_A_Sk Function declares dLOS-P, dLOF and dLOM Defects

Figure 3, The OTSi/OTUk-a_A_Sk Atomic Function declaring the dLOM, dLOF, and dLOS-P Defect Conditions

How about the dTIM Condition?

Finally, since our OTN STE is not receiving any discernable signal (from the remote STE), and it cannot locate the boundaries of each incoming OTUk frame, it will certainly not obtain a Trail Trace Identification Message that matches that of the “Expected Trail Trace Identification” Message.

Should this OTN STE also declare the dTIM defect as well?

In Figure 4, I illustrate the OTUk_TT_Sk function declaring the dTIM defect, while the upstream OTSi/OTUk-a_A_Sk function reports the dLOS-P, dLOF, and dLOM defect conditions.

OTUk_TT_Sk Function declares dTIM defect - due to No Defect Correlation

Figure 4, The OTUk_TT_Sk Atomic Function (downstream from the OTSi/OTUk-a_A_Sk Function) declares the dTIM defect.

Many Defects, all due to the dLOS-P Condition

In this scenario, a Loss of Signal event would cause the OTN STE to declare the dLOS, dLOF, dLOM, and dTIM defect conditions.

The OTN STE will accurately declare all four defect conditions because conditions warrant that the STE declare each of these defects.

However, allowing an STE to declare multiple defects (e.g., dLOS, dLOF, dLOM, and dTIM) can be confusing to both System-Management and the System Operator.

Confused Guy - Too Many Defects

I could take this exercise even further and include some of the PTE/ODUk-related defects that an OTN PTE would declare (e.g., ODUk-AIS), all because of the dLOS-P condition. But I think that you get my point.

Whenever a service-affecting defect occurs, the OTN STE needs to alert System Management of a concise description of the problem (just dLOS-P in this case).

The intent should be to help the System Operator isolate the root cause of these problems.

We should not be bombarding the System Operator with a whole slew of defects, which are just artifacts of a single defect.

If the OTN STE declares the dTIM, dLOM, dLOF, and dLOS-P defects, the root cause of this problem has nothing to do with a mismatch in the Trail-Trace Identification Message.

Hence the Purpose of Defect Correlation

The purpose of Defect Correlation and Defect Correlation equations is to establish and report ONLY the root cause of problems to System Management.

The Defect Correlation Equations accomplishes this by creating a hierarchy of defects.

I’ll explain this.

Let’s list some Defect Correlation Equations for the OTSi/OTUk_A_Sk and OTUk_TT_Sk Atomic Functions.

For the OTSi/OTUk_A_Sk Atomic Function

The OTSi/OTUk_A_Sk function has the following Defect Correlation equations:

  • cLOS-P ⇐ dLOS-P and (NOT AI_TSF-P)
  • cLOF ⇐ dLOF and (NOT dLOS-P) and (NOT dAIS) and (NOT AI_TSF-P)
  • cLOM ⇐ dLOM and (NOT dLOS-P) and (NOT dLOF) and (NOT dAIS) and (NOT AI_TSF-P)

Let’s also include the following Consequent Equation to bridge the OTUk_TT_Sk function to the OTSi/OTUk_A_Sk function.

aSSF ⇐ dLOS-P or dAIS or dLOF or dLOM or AI_TSF-P

For the OTUk_TT_Sk Function

In this case, we will focus on the Defect Correlation equation that pertains to the dTIM defect condition.

  • cTIM ⇐ dTIM and (NOT CI_SSF) and (NOT dAIS)

So Now Let’s Study some of these Defect Correlation Equations

Let’s start with the first equation for the OTSi/OTUk-a_A_Sk function.

  • cLOS-P ⇐ dLOS-P and (NOT AI_TSF-P)

Where: 

cLOS-P is the correlated defect value of the dLOS-P defect state.

dLOS-P is the current state of the dLOS-P defect condition that the OTSi/OTUk_A_Sk function will declare or clear.

AI_TSF-P is the current state of the AI_TSF-P (Trail Signal Fail – Path Indicator) Input to the OTSi/OTUk-A_Sk function.

In this equation, the parameter that begins with the letter “c” is the correlated defect parameter (or defect) state that we ultimately report to System Management.

This equation states that we should only set the variable cLOS-P to TRUE if dLOS-P is TRUE.

In other words, we should only report the Loss of Signal condition (e.g., setting cLOS-P to TRUE) if the STE circuitry declares the dLOS-P defect (due to a lack of signal activity within the Clock Recovery Block, for example).

This equation also states that we should NOT set cLOS-P to TRUE because the upstream Optical Circuitry is declaring some other defect condition and is then asserting its AI_TSF-P output – towards the OTSi/OTUk_A_Sk function).

I show a TRUTH TABLE for this Defect Correlation Equation below in Table 1.

Table 1, TRUTH TABLE for the Defect Correlation Equation, cLOS-P ⇐ dLOS-P AND (NOT AI_TSF-P)

dLOS-P DefectAI_TSF-P StatecLOS-P StateComment
ClearedFALSE0
DeclaredFALSE1Sets cLOS-P to TRUE, because dLOS-P is declared.
Don't CareTRUE0We set cLOS-P to 0 when AI_TSF-P is TRUE.

Let’s look at another Defect Correlation Equation.

  • cLOF ⇐ dLOF and (NOT dLOS-P) and (NOT dAIS) and (NOT AI_TSF-P)

Where:

cLOF is the correlated value of the dLOF defect state.

dAIS is the current state of the dAIS defect condition within the OTSi/OTUk_A_Sk function.

In this equation, we are stating that we should only set cLOF = TRUE (and report the Loss of Frame condition to System Management) if the STE circuitry declares the dLOF condition.

This equation also states that we should NOT be setting cLOF = TRUE (and report the Loss of Frame Condition to System Management) if:

  • The STE is also declaring the dLOS-P defect, or
  • declaring the dAIS (OTUk-AIS) defect, or
  • If the upstream Optical Components assert the AI_TSF-P input to the OTSi/OTUk_A_Sk function.

If any of the three items (above) are TRUE, then we must set cLOF = FALSE.

I show the TRUTH TABLE for this Defect Correlation Equation below in Table 2.

Table 2, The TRUTH TABLE for the Defect Correlation Equation, cLOF ⇐ dLOF AND (NOT dLOS-P) AND (NOT dAIS) AND (NOT AI_TSF-P)

dLOF Defect ConditiondLOS-P Defect ConditiondAIS Defect ConditionAI_TSF-P StatecLOF StateComments
ClearedClearedClearedFALSECleared
DeclaredClearedClearedFALSEDeclaredWe assert cLOF because we are declaring the dLOF Defect
Don't CareDeclaredClearedFALSEClearedWe set cLOF = 0 whenever dLOS-P is declared.
Don't CareClearedDeclaredFALSEClearedWe set cLOF = 0 whenever dAIS is declared.
Don't CareClearedClearedTRUEClearedWe set cLOF = 0 whenever AI_TSF-P is driven TRUE.

At the risk of “whipping a dead horse,” I will show one more example.

  • cTIM ⇐ dTIM and (NOT CI_SSF) and (NOT dAIS)

Where:

cTIM is the correlated value of the dTIM defect state.

CI_SSF is the current state of the CI_SSF (Server Signal Fail Indicator) input pin to the OTUk_TT_Sk function.

If the STE circuitry declares this defect, this equation states that we must only report the Trail Trace Identifier Mismatch Defect (and set cTIM = TRUE).

This equation also states that we MUST NOT set cTIM = TRUE if any of the following is true.

NOTE:  We have the following Consequent Equation for the CI_SSF signal (from the OTSi/OTUk_A_Sk function).

  • aSSF <- dLOS-P or dAIS or dLOF or dLOM or AI_TSF-P

This equation states that if the upstream OTSi/OTUk_A_Sk function declares any of the following defects, it will set aSSF = TRUE.

  • dLOS-P
  • dAIS (OTUk-AIS)
  • dLOF
  • dLOM, or
  • If the upstream Optical Components assert the AI_TSF-P input to the OTSi/OTUk_A_Sk function.

If aSSF = TRUE, then the OTSi/OTUk_A_Sk function will assert the CI_SSF output signal (towards the OTUk_TT_Sk function).

Finally, we get to the bottom line.

These equations state that the STE MUST NOT set cTIM = TRUE (and MUST NOT report the Trail Trace Identifier Mismatch defect to System Management) if any of the following defect conditions are TRUE.

  • dLOS-P
  • dAIS
  • dLOF
  • dLOM
  • If the AI_TSF-P signal (from the upstream Optical Components) is HIGH.

Summary

I believe that you can see that using Defect Correlation Equations makes Defect Reporting and System-Management MUCH EASIER.

Happy due to Defect Correlation

Stuck at Home? You Can be an Expert on OTN Before You Return to the Office!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

CLICK on the Image below for More OTN Related Blog Posts

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? ...
Read More

What is the ODUk-AIS Signal?

This post defines the ODUk-AIS Maintenance Signal. It also discusses when Network Equipment should transmit this Maintenance Signal. Finally, this post describes how a Sink PTE will declare and clear the dAIS defect.


What is the ODUk-AIS Maintenance Signal, and How does a Network Element declare the dAIS Defect Condition?

What is the ODUk-AIS Maintenance signal?

AIS is an acronym for Alarm Indication Signal.

Another post describes the general purpose/role of the AIS maintenance signal.

For OTN applications, the Network Equipment (NE) will transmit the ODUk-AIS maintenance signal by overwriting the contents of an entire ODUk frame (e.g., ODU Overhead and Payload Data) with an All-Ones pattern.

NOTE:  The variable k in the expression ODUk can be of any of the following values, depending upon the data rate:  0, 1, 2, 2e, 3, 4, and flex.

If an OTN STE were to map the ODUk-AIS Maintenance signal into an OTUk frame, then the OTN STE will be generating/transmitting a series of OTUk frames in which the FAS, MFAS, and OTUk Overhead fields are all valid.

The STE will compute and generate the FEC field based on the contents within these OTUk frames.

However, these OTUk frames will contain an ODUk Overhead, the OPUk Overhead, and the Payload fields that have been overwritten with an All-Ones pattern.

Figure 1 presents a drawing of an OTUk frame transporting the ODUk-AIS Maintenance signal.

ODUk-AIS Pattern

Figure 1, Drawing of an OTUk frame carrying the ODUk-AIS Maintenance signal.

Please note that the ODUk-AIS pattern differs from the OTUk-AIS pattern (an Unframed PN-11 pattern).

What are the timing/frequency requirements for the ODUk-AIS Maintenance signal?

The OTN STE will need to transmit this ODUk-AIS Maintenance signal at the same nominal bit rate as an ordinary ODUk/OTUk signal.

Like any ordinary OTUk signal, the OTN NE will need to transmit this data at the nominal bit-rate ± 20ppm.

Table 1 presents the nominal bit-rates for the OTUk signals (and, in turn, for the OTUk signal, whenever it is transporting the ODUk-AIS indicator) for each value of k.

Table 1, Required Bit Rates for the OTUk signal – when transporting the ODUk-AIS signal.

OTUk Bit Rate

When would OTN Network Equipment transmit/generate the ODUk-AIS Maintenance signal?

An OTN STE will generate/transmit the ODUk-AIS maintenance signal anytime it has detected and declared a service-affecting defect condition (at the OTUk-layer) within the upstream traffic.

For example:  If an STE declares the dLOS-P (Loss of Signal – Path) or the dLOF (Loss of Frame) defect within its incoming OTUk signal, it will respond to this defect condition by transmitting the ODUk-AIS signal downstream.

Whenever the OTN STE transmits this ODUk-AIS maintenance signal downstream, it is (in effect) replacing the missing (or defective) ODUk signal (that the defective OTUk signal was transporting) with the ODUk-AIS maintenance signal.

In other words, the OTN STE will generate and transmit the ODUk-AIS Maintenance signal downstream rather than de-map out and transmit an ODUk signal that was likely destroyed by the service-affecting defect within its OTUk server signal.   I show this phenomenon below in Figure 2.

Service Affecting Defect at the OTUk Layer results in the tranmission of the ODUk-AIS Maintenance Signal

Figure 2, Drawing of OTN Circuitry transmitting the ODUk-AIS Maintenance Signal downstream, in response to a Service-Affecting Defect occurring within the OTUk-Layer, upstream.  

The OTN STE will generate and transmit the ODUk-AIS maintenance signal towards downstream ODUk client equipment; anytime it declares any of the following service-affecting defects in the upstream signal.

Please see the post on AIS for an in-depth write-up on when the NE will (and will not) generate the AIS pattern downstream.

How does a Sink PTE detect and declare the ODUk-AIS (or dAIS) defect condition?

The Sink PTE downstream from the STE transmitting the ODUk-AIS Maintenance signal will detect and declare the ODUk-AIS defect condition whenever it receives a STAT field value of “1, 1, 1” within three (3) consecutive OTUk/ODUk frames.

NOTE:  The STAT field is a 3-bit field that resides within the PM (Path Monitor) byte-field in the ODUk overhead.

The Upstream NE will set this 3-bit field to the value [1, 1, 1] because it overwrites the ODUk overhead with an All-Ones pattern whenever it transmits the ODUk-AIS Maintenance Signal.

Please see the ODUk Frame post for more information about the STAT field.

How does a Sink PTE clear the ODUk-AIS defect condition?

The Sink PTE will clear the ODUk-AIS defect condition whenever it has accepted a STAT field value of something other than “[1, 1, 1]”.

NOTE:  The Sink PTE should accept a new STAT field value if it receives at least three (3) consecutive ODUk frames that contain a consistent STAT field value.

Stuck at Home? You Can Be An Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!

Discounts Temporarily Available!!

For More Information on OTN Posts in this Blog, click on the Image below.

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? ...
Read More