This blog post presents a video that discusses the APS features within some of the Atomic Functions that we discussed in Lessons 9 and 10.
Lesson 12 – Video 12 – Detailed Implementation of APS within the Atomic Functions – Video 1
This blog post starts our discussion of the APS Features within various Atomic Functions. In this case, we will present how to implement Automatic Protection Switching in great detail. In particular, we will describe the following:
APS Features within the OTUk/ODUk_A_So and OTUk/ODUk_A_Sk functions (OTU-Layer/SNC/I Monitoring)
How do we implement the APS features within these Atomic Functions to support OTU-Layered SNC/I Monitoring and Protection-Switching?
How do we implement a complete System-Level design (using these atomic functions along with the OTUk_TT_So and OTUk_TT_Sk Atomic Functions)?
NOTE: We discussed these atomic functions in Lesson 9. However, we did not discuss the APS features (within those functions) then.
APS Features within the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (ODU-Layer/SNC/I Monitoring)
How do we implement the APS features within these Atomic Functions to support ODU-Layered SNC/I Monitoring and Protection-Switching?
How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.
APS Features of the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (CL-SNCG/I Monitoring)
How do we implement the APS features within these Atomic Functions to support CL-SNCG/I Monitoring and Protection-Switching?
How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.
This blog post presents a video that shows how to implement APS (Automati Protection Switching) both with and without using an APS Communication Protocol.
Lesson 12 – Video 8 – Detailed Discussion of APS without and with the APS Communication Protocol – Video 1
This blog post describes how we can implement APS (Automatic Protection Switching) without using an APS Communication Protocol. Afterward, this blog introduces how to implement APS using the APS Communication Protocol. This video serves as the first of several videos on this topic.
In particular, this video will discuss the following topics:
Executing APS without using the APS Communication Protocol
Under what conditions can we implement APS without using an APS Communication Protocol?
Why can we implement APS (without an APS protocol) in this case?
When not supporting an APS Communication Protocol, the Architecture/Design of the Protection-Switching Controllers.
How to implement Automatic Protection Switching – without implementing an APS Communication Protocol.
Executing APS with an APS Communication Protocol
Under what conditions must we implement APS with an APS Communication Protocol?
Why do we need to use an APS Communication Protocol for these cases?
How to implement Automatic Protection Switching – while using an APS Communication Protocol
Introduction to the APS/PCC Field for OTN/Linear Protection Switching Applications (per ITU-T G.873.1).
The Architecture/Design of the Protection-Switching Controllers – 1+1 Protection Architecture
The Architecture/Design of the Protection Switching Controllers – 1:N Protection Architecture
The NR (No Request) Command
To Learn How to Implement APS, with and without an APS Communication Protocol, Check Out the Video Below.
This blog post breifly defines the pF_DS (Far-End Defect Second) Performance Monitoring paramteter that the OTN PTE will compute and generate.
This blog post aims to briefly define and describe the pF_DS (Far-End Defect Second) Performance Monitoring parameter that the OTN PTE (or ODUk_TT_Sk Atomic Function) will compute and generate.
The OTN PTE (or ODUk_TT_Sk function) will include information on pF_DS without each Performance Monitoring report that it sends to System Management.
NOTES:
The OTN STE (OTUk_TT_Sk Atomic Function) also monitors and generates information on the pF_DS (Far-End Defect Second) parameter at the OTUk Layer. Please see the pF_DS at OTUk Layer Post for more details on this parameter.
Throughout this post, I will use the terms: OTN PTE and ODUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the ODUk Layer, the OTN (Sink) PTE is the entity that is responsible for detecting and reporting Far-End Defect Second events.
As the OTN PTE receives and monitors its incoming ODUk signal, it will check for many things. It will continuously check for the incoming ODUk signal for Service-Affecting Defect (e.g., dAIS, dOCI, dLCK, dTIM, etc.) as well as bit (or symbol) errors (e.g., PM-BIP-8 errors and PM-BEI errors).
Another thing that the OTN PTE will do (as it continuously monitors its incoming ODUk signal) is to divide each second of (monitoring) time into the following two categories:
Far-End Available (Working) Seconds, and
Far-End Defect Seconds
Anytime the OTN PTE detects and categorizes a given one-second period as being a Far-End Defect Second, it will increment the pF_DS parameter and report that information to System Management.
New Comprehensive OTN Training…. Available Now. Click on the Banner Below to Learn More!!
Discounts Available for a Short Term!!
So When does the OTN PTE detect and flag a given One-Second Period as being a “Far-End Defect Second”?
ITU-T G.798 presents the following Performance Monitoring Equation for the ODUk_TT_Sk function.
pF_DS <- dBDI
Where:
dBDI is the current state of the ODUk-BDI or the Backward Defect Indicator Defect (at the ODUk Layer).
The OTN PTE (or ODUk_TT_Sk function) will continuously evaluate the above equation as it monitors its incoming ODUk signal.
This equation states that the OTN PTE will declare a given one-second period as being a Far-End Defect Second if it has declared the dBDI defect condition during any portion of that one second.
A given OTN PTE will declare a one-second period as a Far-End Defect Second if the remote OTN PTE declares any of the following defect conditions:
dAIS (ODU-AIS)
dOCI
dLCK
dTIM
In this case, the OTN PTE will increment the pF_DS parameter for each one-second period it categorizes as a Far-End Defect Second.
Conversely, the OTN PTE will declare a one-second period as an Available Second if the remote OTN PTE is not declaring any of the defects mentioned above. The OTN PTE will NOT increment the pF_DS parameter in this case.
What Does This Mean in English?
Of course, if the OTN PTE declares the dBDI defect condition, then this also means that the remote PTE is declaring a service-affecting defect condition. In other words, the pF_DS parameter reflects the health of the remote (or Far-End) terminal.
If the remote terminal declares no service-affecting defects, the near-end terminal will not increment the pF_DS parameter. On the other hand, if the remote terminal declares a service-affecting defect, then the near-end terminal will increment the pF_DS parameter.
So, if the ODUk_TT_Sk function has declared the dBDI defect condition for even a fraction of a given one-second period, it will declare it as a Far-End Defect Second. It will also set the parameter pF_DS to 1 and report that information to System Management.
Conversely, if the OTN PTE determines that the ODUk_TT_Sk function did not declare the dBDI defect condition at all during a given one-second period. In that case, it will declare that one-second period is a Far-End Available (Working) Second. In this case, the OTN STE will NOT set the parameter pF_DS to 1.
Hence the pF_DS parameter reflects the network’s health at the remote terminal (e.g., the other end of the ODUk Path).
Is there such a thing as a Near-End Defect Second?
Throughout this post, we have used the term: Far-End Defect Second. Does this mean that there is another parameter called Near-End Defect Second?
Answer: Yes, there is such a parameter. See the Near-End Defect Seconds (pN_DS) post at the ODUk Layer for more details.
Clueless about OTN? We Can Help!! Click on the Banner Below to Learn More.
Discounts Available for a Short Time!!
And Finally, Click on the Image Below to see More OTN-Related Topics in this Blog.
This blog post presents a video that describes (in detail) SNC/S (Subnetwork Circuit Protection – Sublayer) Monitoring for Protection Switching.
Lesson 12 – Video 7 – Detailed Discussion of SNC/S (Subnetwork Circuit – Sublayer) Monitoring for Protection Switching
This blog post contains a video that presents a detailed discussion of SNC/S (Subnetwork Circuit – Sublayer) Monitoring for Protection Switching purposes at the ODU Layer.
In particular, this video will discuss the following topics:
A Detailed Review of SNC/S (Subnetwork Circuit Protection/Sublayer) Monitoring.
This video shows example locations/conditions of where we would use SNC/S Monitoring and why we would use this form of monitoring.
This video also highlights similarities of SNC/S with SNC/I Monitoring.
It also shows the differences between SNC/S and SNC/Ne or SNC/Ns monitoring.
Finally, this video reviews a Multi-Administrative Domain Network (and Tandem Connection Monitoring) and describes how SNC/S works within a given “Protect Domain.”
This blog post introduces the concept of SNCP (Subnetwork Circuit Protection) Switching. This post also briefling introduction SNCP Monitoring schemes such as SNC/I, CL-SNCG/I, SNC/Ne, SNC/Ns and SNC/S.
Lesson 12 – Video 3 – Introduction to SNCP (Subnetwork Circuit Protection) Switching
This blog post contains a video that covers the introductory part of Subnetwork Circuit Protection switching.
In particular, this video will discuss the following topics:
Introduction to the concept of Subnetwork Circuit Protection (SNCP)-Switching
How is SNCP different from Trail Protection Switching
Why does the Industry prefer SNCP Monitoring/Switching instead of Trail Protection Monitoring/Switching?
Introduction to the following forms of SNCP Monitoring:
SNC/I – Subnetwork Circuit/Inherent Monitoring
CL-SNCG/I – Compound Link – Subnetwork Circuit Group/Inherent Monitoring
We will cover each of these monitoring forms (for Protection-Switching purposes), in much greater detail, throughout the remaining videos in Lesson 12.
In particular, we will cover these forms of SNCP Monitoring (in detail) in the following videos.
This blog post contains the second of two videos that analyzes how the Multi-Administrative Domain uses Tandem Connection Monitoring to respond to service-affecting defects within an ODU signal passing through it.
Lesson 11 – Video 11 – Tandem Connection Monitoring (TCM) Multi-Administrative Domain Defect Analysis – Part TWO
This blog post contains a video covering the second (and final) part of the Multi-Administrative Domain Walk-Through when defects occur.
In particular, this video discusses how the Multi-Administrative Domain will respond to the presence of defects.
This video will analyze the Multi-Administrative Domain’s response to the following two cases.
Case 2 – Whenever a Service-Affecting defect occurs within Serving Operator Domain – Operator B, and
Case 3 – Whenever a Service-Affecting defect occurs within the Protect Domain.
NOTE: In the previous video, we analyzed Case 1 (Service-Affecting defect occurs within the ODU signal but outside of any of the administrative regions).
As we analyze the Multi-Administrative Domain’s response to these defects (for Cases 2 and 3), we will cover the following topics:
What exactly occurs within an ODU signal that experiences a service-affecting defect?
How do ODU-layer, ODUT-layer, and OTU-layer circuitry respond to such defects?
How does the circuitry within these Administrative Domains respond to the service-affecting defects associated with Cases 2 and 3?
What does the Path Terminating Equipment (at the remote terminal) do in response to these service-affecting defects?
This video will close out our discussion of Lesson 11 – Tandem Connection Monitoring.
This blog post contains the first of two videos that analyzes how the Multi-Administrative Domain uses Tandem Connection Monitoring to respond to service-affecting defects within the ODU signal passing through it.
Lesson 11 – Video 10 – TCM Multi-Administrative Domain Defect Analysis – Part ONE
This blog post contains a video covering the first part of the Multi-Administrative Domain Walk-Through when defects occur.
In particular, this video discusses how the Multi-Administrative Domain will respond to the presence of defects.
During this video, we assume that we are experiencing a service-affecting defect within the ODU signal (that passes through the Multi-Administrative Domain). However, in this case, we assume that the defect occurs outside any administrative regions. As we analyze the Multi-Administrative Domain’s response to this defect, we will cover the following topics:
What exactly occurs within an ODU signal that experiences a service-affecting defect?
How do ODU-layer, ODUT-layer, and OTU-layer circuitry respond to such defects?
How does each Administrative Domain respond to the presence of a service-affect defect outside of the Service-Requesting (or any other Domain) using Tandem Connection Monitoring?
What does the Path Terminating Equipment (at the remote terminal) do in response to this service-affecting defect?
I hope the student will better understand Tandem Connection Monitoring as we go through this and the following video.
This blog post briefly describes the term pF_EBC (Far-End Errored Block Error).
What is the pF_EBC (Far-End Errored Block Count) Performance Monitoring Parameter for the OTUk Layer?
The purpose of this blog post is to briefly define and describe the pF_EBC (Far-End Errored Block Count) Performance Monitoring parameter that the OTN (Sink) STE (or OTUk_TT_Sk Atomic Function) will compute and tally.
The Sink STE (or OTUk_TT_Sk function) will include information on the pF_EBC parameter within each Performance Monitoring report it sends to System Management.
NOTES:
The OTN PTE (ODUP_TT_Sk Atomic Function) also monitors and generates information on the pF_EBC (Far-End Errored Block Count) parameter at the ODUk Layer. Please see the pF_EBC at ODUk Layer Post for more details on this parameter.
Throughout this post, I will use the terms: OTN STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Far-End Errored Block Counts (or SM-BEI errors).
As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously scan the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8, FEC, etc.). It will also check for Service-Affecting defects (e.g., dTIM, dLOM, dLOF, dAIS, dLOS-P, etc.).
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
Definition of Terms:
Before we proceed, we need to define the following terms for this blog post:
Block: In this case, we define a block as an OTUk frame.
Far-End Errored Block: In this blog post, we define a far-end errored block as any OTUk frame that contains a value for the SM-BEI count that ranges anywhere between 1 and 8. Anytime the OTN STE receives a block with an SM-BEI count value of 0x0, we consider that block to be un-erred.
As the Sink STE checks the incoming OTUk signal for errors and defects, it will also record the total number of far-end errored blocks it detects for each one-second period.
At the end of a given one-second period, the Sink STE will load the total number of far-end errored block counts (detected in the most recent one-second period) into the variable pF_EBC.
The Sink STE will then report this value for pF_EBC to System Management as a part of its Performance Monitoring report.
Table 1 presents the number of blocks/second that each type of OTUk signal will transport for each value of k.
Table 1, Number of Blocks/Second for each OTUk Rate.
OTUk Type
Number of Blocks/Second
OTU1
20,421
OTU2
82,026
OTU3
329,492
OTU4
856,388
OTUCn
n x 860,177
So How does the OTN STE tally Errored Blocks for the pF_EBC parameter?
As the Sink STE receives and monitors its OTUk signal, it will continually check the SM-BEI counts within each incoming OTUk frame (or block).
Anytime the Sink STE receives an OTUk frame in which the SM-BEI value is anywhere from 1 to 8, it will increment its internal (pF_EBC Counter) by 1.
NOTE: This means that even if the Sink STE receives an SM-BEI value of “8”, it will still just increment its pF_EBC Counter by 1 (not 8).
Conversely, the Sink STE will not increment its internal pF_EBC Counter whenever it receives an OTUk frame (or block) that contains an SM-BEI value of 0, or 9 through 15. The Sink STE consider these type of OTUk frames to be un-erred.
At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pF_EBC parameter. The Sink STE will then include that information within its Performance Monitor report that it sends to System Management.
Are there any Times or Conditions during which the Sink STE will NOT tally Errored Block Counts for the pF_EBC parameter?
ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pF_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic Function) asserts the CI_SSF input of the OTUk_TT_Sk function.
In other words, the Sink STE will not tally any Errored Block Counts (for the pF_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declare any of the following service-affecting defect conditions.
Is there such a thing as Near-End Errored Block Counts?
Throughout this post, we have used the term Far-End Errored Block Count. Does this mean that there is another parameter called Near-End Errored Block Count?
