OTN – Lesson 12 – Detailed Discussion of CL-SNCG/I Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) CL-SNCG/I (Compound Links – Subnetwork Circuit Group – Inherent) Monitoring for Protection Switching.

Lesson 12 – Video 5 – Detailed Discussion of CL-SNCG/I (Compound Links – Subnetwork Circuit Group – Inherent) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of CL-SNCG/I Monitoring ], for Protection Switching purposes, at the ODU layer.

In particular, this video will discuss the following topics:

  • A Quick Review of the SNC/I Monitoring at the ODU Layer
    • A Single ODUj Tributary is the Normal Traffic Signal
    • How CI_SSF and CI_SSD initiate Protection Switching
  • How to perform CL-SNCG/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 CL-SNCG/I Monitoring at the ODU Layer?
    • What happens when we declare an ODUk Server-Layer service-affecting defects (such as dAIS, dOCI, dLCK, dTIM)?
    • What happens when we declare the PM-dDEG (ODU-Layer Signal Degrade) defect?
    • How does protection-switching work?
  • How does CL-SNCG/I Monitoring (for Protection-Switching) differ from SNC/I Monitoring for Protection-Switching?
    • PI-TSF/PI-TSD versus CI_SSF[n]/CI_SSD[n]
    • Multiple ODUj Tributary Signals are the Normal Traffic Signal
    • dPLM, dLOOMFI, dMSIM[n], and dLOFLOM[n] do not cause Protection-Switching when CL-SNCG/I Monitoring.

Check Out the Video Below

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

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)”

Defect – Definition

This post presents ITU-T G.806’s definition of a defect or defect condition.

Defect – Definition

ITU-T G.806 defines the word defect as follows:

Defect: The density of anomalies has reached a level where the ability to perform a required function has been interrupted.

We use defects as an input for performance monitoring, controlling consequent actions, and determining fault causes.

In other words, defects are bad.

If some piece of networking equipment is declaring a defect condition, it is saying it “cannot do its job properly” because of this condition.

Defects that We Cover in this Blog

We cover the following defects in this blog.

For OTN Applications

OTU Layer
  • dLOS-P – Loss of Signal – Path
  • dLOS-P[i] – Loss of Signal – Path, Electrical Lane, i
  • dLOFLANE[j] – Loss of Frame – of Logical Lane j
  • dLOR[j] – Loss of Recovery, Logical Lane j
  • dLOL – Loss of Lane Alignment
  • Excessive Skew (OTL3.4 and OTL4.4 Applications)
  • dLOF – Loss of Frame
  • dLOM – Loss of Multi-Frame
  • dAIS – (OTUk-) Alarm Indication Signal
  • dTIM – Trail Trace Identifier Mismatch
  • dBDI – Backward Defect Indicator
  • dDEG – Signal Degrade
  • dIAE – Input Alignment Error
  • dBIAE – Backward Input Alignment Error
ODU Layer
  • dAIS – (ODUk) Alarm Indication Signal
  • dLCK – Locked Status
  • dOCI – Open Connection Indication
  • dTIM – Trail Trace Identifier Mismatch
  • dBDI – Backward Defect Indicator
  • dDEG – Signal Degrade
Non-Multiplexed Applications
  • dLCS – Loss of Character Synchronization (100GBASE-R)
  • dPLM – Payload Type Mismatch
Multiplexed Applications
  • dLOOMFI – Loss of OMFI Synchronization
  • dLOFLOM[p] – Loss of Frame, Loss of Multi-Frame – ODUj Tributary Port p
  • dMSIM[p] – Multiplex Structure Identifier Mismatch – ODUj Tributary Port p
Tandem Connection Monitoring (TCM)
  • TCMi-dAIS – TCM Level i, Alarm Indication Signal
  • TCMi-dLCK – TCM Level i, Locked Status
  • TCMi-dOCI – TCM Level i, Open Connection Indication
  • TCMi-dTIM – TCM Level i, Trail Trace Identifier Mismatch
  • TCMi-dBDI – TCM Level i, Backward Defect Indicator
  • TCMi-dDEG – TCM Level i, Signal Degrade
  • TCMi-dIAE – TCM Level i, Input Alignment Error
  • TCMi-dBIAE – TCM Level i, Backward Input Alignment Error
  • dLTC – Loss of Tandem Connection Monitoring

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

Discounts Available for a Short Time!!!

What is the Multiplex Structure Identifier

This post briefly defines the term Multiplex Structure Identifier (MSI) for OTN Applications.


What is the Multiplex Structure Identifier (MSI) within the PSI Message?

The purpose of this post is to define the term:  Multiplex Structure Identifier.

Introduction

We spoke about the PSI (Payload Structure Identifier) Message in another post.

That post states a few things that are of interest to this post.

  • The PSI Message is a 256-byte Message that a given Source PTE will repeatedly transmit to the Sink PTE.
  • The Source PTE will repeatedly transmit this PSI Message via the PSI byte (within each ODUk/OPUk frame).
  • The purpose of this PSI Message is to permit the Source PTE to inform the Sink PTE of the type of traffic that this particular ODUk/OPUk server signal is transporting.
  • The first byte (Byte 0 – within the PSI Message) will be the PT (or Payload Type) byte.
  • This means that there are still 255 other bytes that are available to transport information within each PSI Message.
    • The PSI post also states two different types of PSI Messages.
    • The Non-Multiplexed Traffic Type of PSI Message, and
    • The Multiplexed Traffic Type of PSI Message.  

Suppose we’re discussing the MSI (Multiplex Structure Identifier), which involves OPU/ODU server signals transporting multiple lower-speed ODUj tributary signals.  In that case, we will deal with the Multiplexed Traffic Type of PSI Message.  

I show an illustration of the PSI byte-field (within an OPU frame) and a blow-up of the  Multiplexed-Traffic Type of PSI Message below in Figure 1.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 1, Illustration of the PSI byte-field and a Multiplexed-Traffic Type of PSI Message

Please note that the PSI Message within Figure 1 does not contain a CSF (Client Signal Fail) bit-field.  Hence, you should be able to identify this PSI Message as being the Multiplexed Traffic type of PSI Message.  

A Multiplex Structure ODUk

If the Source PTE (transmitting an ODUk signal to the remote Sink PTE) has set the PT byte value (within each PSI Message) to 0x20 or 0x21, then this means that this ODUk signal is a Multiplex Structure ODUk signal.

If a given ODUk signal is a Multiplex Structure ODUk signal, then this means that it is transporting at least one lower-speed ODUj tributary signal within its payload (where k > j).

NOTE:  We will discuss PT = 0x22 and ODUCn signals in another post.

In this case, the Source PTE (or upstream circuitry) has mapped and multiplexed some number of lower-speed ODUj tributary signals into this particular higher-speed ODUk server signal.

For the OTN to work correctly, the Source PTE needs to send sufficient information to Sink PTE about the type of traffic/data that a given ODUk signal carries.

Hence the purpose of the PSI Message.

The Sink PTE needs more information than the PT byte value

So if the Source PTE sets the PT Byte value (within each outbound PSI Message) to 0x20 or 0x21, then it is telling the remote Sink PTE that this ODUk signal is a Multiplex Structure signal that is transporting some number of Lower-Speed ODUj tributary signals.

However, the Sink PTE needs more information for it to be able to identify and handle this ODUk data stream accurately.

In particular, the Sink PTE needs to “know” how many and what type of lower-speed ODUj tributary signals this ODUk/OPUk server signal is transporting.  

We can think of the remaining bytes (within the PSI Message, following the PSI byte) as a passenger manifest for each of the Lower-Speed ODUj Tributary signals we are transporting within this OPUk/ODUk server.  

Depending upon the PT value and the type of OPUk/ODUk server signal that we are working with, the number of MSI bytes (within the PSI Messages for that particular server signal) will vary, as I show below.

For PT = 0x20

  • If we’re working with an OPU1/ODU1 server signal, the MSI will consist of 2 bytes.
  • If we’re working with an OPU2/ODU2 server signal, the MSI will consist of 4 bytes.
  • An OPU3/ODU3 server signal will use 16 bytes for its MSI.  

For PT = 0x21

  • If we’re working with an OPU2/ODU2 server signal, then the MSI will consist of 8 bytes.
  • An OPU3/ODU3 server signal will use 32 bytes for its MSI, and
  • An OPU4/ODU4 server signal will use 80 bytes for its MSI.  

Let’s Take a Look at an ODU4/OPU4 Signal

For example, if we are dealing with an ODU4 signal, and if the PT byte is set to 0x21, then the PSI Message (that this ODU4/OPU4 signal transports) would have the format that we show below in Figure 2.

Multiplex Structure Identifier for 80 ODU0 Signals within an OPU4 Signal

Figure 2, Illustration of the PSI Message for an ODU4/OPU4 that is transporting 80 ODU0 signals

Figure 2 shows the PSI Message that a Source PTE would carry (within an ODU4 signal) if that ODU4 signal were transporting 80 ODU0 signals (that it has mapped and multiplexed into this ODU4).

Please note that ODU4/OPU4 signals can transport other types of multiplexed traffic.  For example, it can carry any of the following types of multiplexed traffic.

  • 80 ODU0 signals.
  • 40 ODU1 signals
  • 10 ODU2 or ODU2e signals
  • 2 ODU3 signal
  • Some ODUflex signals (provided that the total bandwidth of all of these signals does not exceed 80 time-slots or the OPU4 payload carrying capacity of 104.35597533 Gbps).
  • Various combinations of each of the above signals (again, provided that the total bandwidth of all of these signals does not exceed 80 time-slots

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 Available for a Short Time!!!

How to Read/Decipher these Multiplex Structure Identifier fields

Figure 2 shows that each PSI Message (starting at Byte 2) for an OPU4/ODU4 server signal has 80 consecutive bytes of data. 

These 80 bytes (of data) are the Multiplex Structure Identifier (MSI) for this OPU4/ODU4 serval signal.  In this case, each byte of data (within the MSI) represents a bandwidth of approximately 1.25Gbps.

If we’re working with an OPU4/ODU4 server signal, then:

80 bytes x 1.25Gbps = 100Gbps.

And that makes sense because 100Gbps is the approximate bandwidth of an OPU4/ODU4 signal.  

The MSI will alert the Sink PTE of the type of Lower-Speed ODUj Tributary Signals we are transporting within this OPU4/ODU4 server signal. 

Is the Time-Slot Allocated?

The first bit-field (within each MSI byte) will indicate whether this 1.25Gbps time slot (within this OPU4/ODU4 server signal) has been allocated or not-allocated, as shown below in Figure 3.  

If this bit-field is set to “1”, then that particular time slot (or bandwidth) within the OPU4/ODU4 signal is allocated.  

Conversely, suppose this bit-field is set to “0”. In that case, this particular time slot (or bandwidth) within the OPU4/ODU4 server signal is NOT allocated (or not being used to transport a lower-speed ODUj tributary signal).  

NOTE:  In the PT = 0x21 post, we mention that each time-slot (for PT = 0x21 applications) represents approximately 1.25Gbps of bandwidth.

I have also included Figure 3, which will help you better understand these Multiplex Structure Identifier fields.

Mutliplex Structure Identifier Definition for OPU4 Applications

Figure 3, Multiplex Structure Identifier – Bit Definitions for ODU4/OPU4 Applications.  

The Port ID Number

The remaining 7-bits, within each MSI byte, are the Tributary Port Number (or Port ID Number.  

The Port ID Number identifies which lower-speed ODUj Tributary signal we are transporting within this OPU4/ODU4 server signal.  

Now, since each byte (within the MSI) represents a bandwidth of 1.25Gbps, then the number of times that we see a particular Port ID Number appearing within our 80 bytes of MSI indicates the bandwidth (and, in turn) the type ODUj Tributary signal that we are working with.

For example, if we only see that Port ID Number = 0x00 only appears once within this set of 80 bytes, then we know that this particular ODUj Tributary signal (that corresponds with Port ID Number = 0x00) has a bandwidth of:

1 byte x 1.25Gbps = 1.25Gbps

And it is most likely an ODU0 signal.  

In the case where we see that Port ID Number = 0x00 appears twice, within this set of 80 bytes, then we know that this particular ODUj Tributary signal has a bandwidth of:

2 bytes x 1.25Gbps = 2.50Gbps

And it is most likely an ODU1 signal.  

And so on.  

In Figure 2, I show that the MSI for this OPU4/ODU4 server signal consists of 80 bytes, in which the Port ID Numbers range from 0x00 to 0x4F (or 79 in decimal format). 

Each of the 80 MSI bytes contains a unique Port ID value.  In other words, no two MSI bytes contain the same Port ID value.  

This set of MSI bytes indicates that this OPU4/ODU4 server signal is transporting 80 ODU0 tributary signals or 80 sets of signals with a bandwidth of 1.25Gbps.  

Other Examples of Multiplex Structure Identifiers

  • PT = 0x21 Applications
    • ODU2/OPU2 Server Applications
    • ODU3/OPU3 Server Applications
    • ODU4/OPU4 Server Applications
  • PT = 0x20 Applications
    • ODU1/OPU1 Server Applications
    • ODU2/OPU2 Server Applications
    • ODU3/OPU3 Server Applications

NOTE: We cover Multiplexed Traffic and their resulting MSIs extensively within Lesson 5 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

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

Discounts Available for a Short Time!!

To See More OTN-Related Posts, 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

What is PT = 0x21 for OTN Applications?

This post discusses and describes the PT = 21 Method for Mapping and Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.


What is PT (Payload Type) = 0x21 for OTN Applications, and what does it Mean?

Whenever we are mapping/multiplexing lower-speed ODUj signals into a higher-speed ODUk signal, for up to the ODU3 rate, we have the following two options:

  • Use the PT = 20 (or 0x20) Method for Mapping/Multiplexing the ODUj tributary signals into the ODUk, or
  • Use the PT = 21 (or 0x21) Method for Mapping/Multiplexing the ODUj tributary signals into the ODUk.

If you wish to map/multiplex some lower-speed ODUj signals into an ODU4 signal, then you MUST use the PT  = 21 (ox21) approach.

NOTE:  We discuss the PT = 21 Approach (for mapping/multiplexing) some lower-speed ODUj tributary signals into an ODU4 in Lesson 5/ODU4 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

What is the PT = 21 Method?

Whenever we use the PT = 21 Method, we will set the PT byte (within the PSI Message) to the value 0x21 within this OPUk/ODUk signal.

The PT = 21 Method for Mapping/Multiplexing of ODUj signals into an ODUk signal has the following characteristics.

  • We do Mapping/Multiplexing with 1.25Gbps time-slots (instead of the 2.5Gbps time-slots for PT = 20).
  • In most cases, we use GMP to map the ODUj signal into the ODTUk.ts or ODTUjk structures.
  • However, we do use AMP as the mapping procedure in some cases.

Is the PT = 21 Method better than PT = 20 Method?

The PT = 21 Method is the newer standard and is (therefore) the preferred approach.

For example, for 2-Fibre/2-Lambda Shared-Ring Protection-Switching applications, ITU-T G.873.2 strongly recommends that the System Designer use the PT = 21 methods for combining the Working and Protection time-slots into a single ODUk signal.

Please see the 2-Fibre/2-Lambda Shared-Ring Protection-Switching post for more information on this topic.

What Mapping/Multiplexing Schemes can one use for the PT = 21 Method for Mapping/Multiplexing ODUj Signals into an ODUk Signal?

I summarize the Mapping/Multiplexing scheme information for each of the PT = 21 Cases (for Mapping/Multiplexing Numerous Lower-Speed ODUj signals into a Higher-Speed ODUk signal) in Table 1 below.

Table 1, Summary of Schemes for Mapping/Multiplexing Multiple Lower-Speed ODUj Signals into a Higher-Speed ODUk Signal, PT = 0x21

ODUj SignalMapping StructureMapping MethodNumber of ODUj SignalsIntermediate StructureODUk/OPUk Signal
ODU0ODTU2.1GMP8ODTUG2ODU2/OPU2
ODUflexODTU2.tsGMP1 to 8ODTUG2ODU2/OPU2
ODU1ODTU12AMP4ODTUG2ODU2/OPU2
ODU0ODTU3.1GMP32ODTUG3ODU3/OPU3
ODUflexODTU3.tsGMP1 to 32ODTUG3ODU3/OPU3
ODU1ODTU13AMP16ODTUG3ODU3/OPU3
ODU2ODTU23AMP4ODTUG3ODU3/OPU3
ODU2eODTU3.9GMP3ODTUG3ODU3/OPU3
ODU0ODTU4.1GMP80ODTUG4ODU4/OPU4
ODUflexODTU4.tsGMP1 to 80ODTUG4ODU4/OPU4
ODU1ODTU4.2GMP40ODTUG4ODU4/OPU4
ODU2ODTU4.8GMP10ODTUG4ODU4/OPU4
ODU2eODTU4.8GMP10ODTUG4ODU4/OPU4
ODU3ODTU4.31GMP2ODTUG4ODU4/OPU4

I have also drawn out these cases below as well.

  • ODU0 ⇒ ODTU2.1 ⇒ ×8 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

This scheme will map/multiplex as many as 8 ODU0 signals into an ODU2 signal.

ODU0 to ODU2 - Using PT = 21 Method

Figure 1, Simple Illustration of the ODU0 -> ODU2 Multiplexing/Mapping scheme

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODU1 ⇒ ODTU12 ⇒ ×4 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

This scheme will allow one to map/multiplex as many as 4 ODU1 signals into an ODU2 signal.

ODUflex to ODU4 - Using PT = 21 Method

 

Figure 2, Simple Illustration of the ODU1 -> ODU2 Multiplexing/Mapping scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODUflex ⇒ ODTU2.ts ⇒ ×8/ts ⇒ ODTU2G ⇒ OPU2 ⇒ ODU2

This scheme will allow one to map/multiplex anywhere from 1 to 8 ODUflex signals into an ODU2 signal.

ODUflex to ODU2 - Using PT = 21 Method

Figure 3, Simple Illustration of the ODUflex ⇒ ODU2 Multiplexing/Mapping scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

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

Corporate Discounts Available!!

 

  • ODU0 ⇒ ODTU3.1 ⇒ ×32 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 32 ODU0 signals into an ODU3 signal.

ODU0 to ODU3 - Using PT = 21 Method

Figure 4, Simple Illustration of the ODU0 ⇒ ODU3 Mapping/Multiplexing scheme

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODU1 ⇒ ODTU13 ⇒ ×16 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 16 ODU1 signals into an ODU3 signal.

ODU1 to ODU3 - Using PT = 21 Method

 

Figure 5, Simple Illustration of the ODU1 ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODU2 ⇒ ODTU23 ⇒ ×4 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 4 ODU2 signals into an ODU3 signal.

ODU2 to ODU3 - Using PT = 21 Method

Figure 6, Simple Illustration of the ODU2 ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODU2e ⇒ ODTU3.9 ⇒ ×3 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 3 ODU2e signals into an ODU3 signal.

ODU2e to ODU3 - Using PT = 21 Method

Figure 7, Simple Illustration of the ODU2e ⇒ ODU3 Mapping/Multiplexing scheme. 

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODUflex ⇒ ODTU3.ts ⇒ ×32/ts ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex anywhere from 1 to 32 ODUflex signals into an ODU3 signal.

ODUflex to ODU3 - Using PT = 21 Method

Figure 8, Simple Illustration of the ODUflex ⇒ ODU3 Mapping/Multiplexing scheme.  

Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (COMING SOON).

 

  • ODU0 ⇒ ODTU4.1 ⇒ ×80 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many 80 ODU0 signals into an ODU4 signal.

ODU0 to ODU4 - Using PT = 21 Method

Figure 9, Simple Illustration of the ODU0 ⇒ ODU4 Mapping/Multiplexing scheme.  

Click HERE or click on the figure above to learn more about this Mapping/Multiplexing scheme.

 

  • ODU1 ⇒ ODTU4.2 ⇒ ×40 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 40 ODU1 signals into an ODU4 signal.

ODU1 to ODU4 - Using PT = 21 Method

Figure 10, Simple Illustration of the ODU1 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (*).

 

  • ODU2 ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 10 ODU2 signals into an ODU4 signal.

ODU2 to ODU4 - Using PT = 21 Method

Figure 11, Simple Illustration of the ODU2 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (*).

 

  • ODU2e ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 10 ODU2e signals into an ODU4 signal.

ODU2e to ODU4 - Using PT = 21 Method

Figure 12, Simple Illustration of the ODU2e ⇒ ODU4 Mapping/Multiplexing scheme.  

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (*).

 

  • ODU3 ⇒ ODTU4.31 ⇒ ×2 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 2 ODU3 signals into an ODU4 signal.

ODU3 to ODU4 - Using PT = 21 Method

Figure 13, Simple Illustration of the ODU3 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme.  (*).

 

  • ODUflex ⇒ ODTU4.ts ⇒ ×80/ts ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex anywhere from 1 to 80 ODUflex signals into an ODU4 signal.

ODUflex to ODU4 - Using PT = 21 Method

Figure 14, Simple Illustration of the ODUflex ⇒ ODU4 Mapping/Multiplexing scheme.  

Click HERE or Click on the figure above to learn more about this Mapping/ Multiplexing scheme.  (*).

NOTE:  (*) – Indicates that you must be a member of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!  program to see this link.

In Conclusion

In this posting, we briefly listed the characteristic of a PT = 21 scheme for Mapping/Multiplexing multiple lower-speed ODUj tributary signals into a higher-speed ODUk server signal.

We have also listed out each of the 14 PT = 21 schemes for Mapping/Multiplexing multiple lower-speed ODUj signals into a higher-speed ODUk signal.

Please check out the relevant post for similar information on PT = 20 schemes on Mapping/Multiplexing multiple lower-speed ODUj signals into a higher-speed ODUk signal.

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!!

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

What is an ODTU4.1 Structure?

This post defines the ODTU4.1 (Optical Tributary Data Unit 4.1). This post also describes how we use the ODTU4.1 structure/frame whenever we are mapping/multiplexing ODU0 signals into an OPU4 signal.


What is the ODTU4.1 Frame/Structure?  And When do We use it?

Introduction

The term, ODTU4.1, is an acronym for Optical Data Tributary Unit 4.1.

A Mapper circuit will use this structure whenever mapping and multiplexing anywhere between 1 and 80 ODU0 tributary signals into an OPU4 server signal.

We will discuss the following topics within this blog post.

  • What does the term ODTU4.1 mean?
  • A description/definition of the ODTU4.1 frame/structure.
  • How do we use the ODTU4.1 structure when mapping/multiplexing multiple lower-speed ODU0 tributary signals into an OPU4 server signal?
    • What is the timing/frequency relationship between each ODTU4.1 signal, and
    • What is the timing/frequency relationship between each ODTU4.1 signal and the outbound OPU4 frame data?

What is the meaning of the term ODTU4.1?

The numeral 4 (within the expression ODTU4.1) reflects that we use this structure to map data into an OPU4/ODU4 server signal.

The numeral 1 (again, within the expression ODTU4.1) reflects that this structure transports a single ODU0 signal (which contains only 1 (one) 1.25Gbps-unit  of bandwidth).

Therefore, the ODTU4.1 structure only transports 1 (one) 1.25Gbps-unit (or tributary-slot) of bandwidth as we map/multiplex this data into an OPU4 signal.

NOTE:  I have extensively discussed how we map 80 ODU0 tributary signals into an ODU4 server signal within Lesson 5/ODU4 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

There are other similar structures, such as the ODTU4.2, ODTU4.8, ODTU4.31, and ODTU4.ts frames, that we will use to map an ODU1 (2 time-slots), ODU2/2e (8 time-slots), ODU3 (31 time-slots) and ODUflex (ts time-slots) into an OPU4 signal, respectively.

We will discuss each of these structures in other posts.

When do we use the ODTU4.1 structure?

We use these structures when mapping and multiplexing from 1 to 80 lower-speed ODU0 tributary signals into an OPU4 server signal.

ITU-T G.709 states that whenever we map/multiplex some ODU0s into an OPU4 signal, then we need to do this by executing the following four-step process.

  • Convert each ODU0 signal into an Extended ODU0 signal.
  • GMP map each ODU0 signal into its ODTU4.1 structure/signal, and
  • Byte-Wise Multiplex as many as 80 ODTU4.1 signals together and then
  • Load this data into the OPU4 Payload area.

ITU-T G.709 presents a series of figures on mapping/multiplex lower-speed ODUj tributary signals into a higher-speed OPUk server signal (e.g., k > j).

The standard presents the following figure on how to map/multiplex ODU0 signals into an OPU4.

ITU-T G.709 using ODTU4.1 to map ODU0s into an OPU4

Figure 1, Illustration of the ITU-T G.709 Drawing on how to Map/Multiplex up to 80 ODU0s signals into an OPU4 signal.  

I (more or less) copied Figure 1 straight out of ITU-T G.709.

I added some additional text to explain this figure and ITU-T G.709’s instructions.

Figure 1 states that we must first map a single “Extended ODU0 signal” into a single ODTU4.1 signal using GMP (Generic Mapping Procedure).

What Do We Mean by an Extended ODU0 Signal?

Before we can begin the process of mapping/multiplexing any ODU0 signals into an OPU4 signal, we must first convert each of these ODU0 signals into an Extended ODU0 signal.

This means we need to take an ODU0 frame and then “extend it” by attaching the FAS and MFAS fields to this frame, as shown below in Figure 2.

Extended ODUk Framing Format

Figure 2, Illustration of the Extended ODU0 Framing FormatWee attach the FAS and MFAS fields to each of these ODU0 frames so that the Sink PTE circuitry (at the remote end of the fiber link) will be able to locate the boundaries of ODU0 frames, as it de-maps this data from the ODTU4.1 structures.

Please see the OTU Post for more information on the FAS and MFAS fields.

Please also note that (as we include the FAS and MFAS fields within the ODU0), we fill in the rest of the OTUk Overhead to an all-zeroes pattern, and we don’t append the FEC to the back-end of the ODU0 frame.

Mapping the Extended ODU0 signals into the ODTU4.1 Signal/Structure

Once we have converted each of the ODU0 signals into Extended ODU0 signals, we will proceed to GMP map this data into the ODTU4.1 signal/structure.

After performing this mapping step, we will (from here on) be working with ODTU4.1 signals (instead of ODU0 signals) as we load this data into an OPU4 frame structure and transport it across an optical link.

These ODU0s will remain embedded within this ODTU4.1 data stream until some “ODTU4.1 to ODU0 De-Mapper” circuit de-maps/extracts the ODU0 signals from the ODTU4.1 signals.

If we are mapping/multiplexing 80 ODU0 signals into an OPU4 signal, then we will map 80 ODU0 signals into each of their own 80 ODTU4.1 signals in parallel.

And we will then have 80 separate ODTU4.1 signals to process and manipulate.

Figure 4 (further down in this post) illustrates some “Mapping circuitry” that maps 80 ODU0 signals into 80 ODTU4.1 signals in parallel.

Byte-Wise Multiplexing the ODTU4.1 Data into the ODTUG4 Structure

Next, Figure 1 states that we must byte-wise multiplex each of the 80 ODTU4.1 signals into a single ODTUG4 data stream.

And finally, we should then map (or insert) this ODTUG4 data stream into the OPU4 payload.

What does the ODTU4.1 Structure Look Like?

Figure 3 presents an illustration of the ODTU4.1 Framing Format.

ODTU4.1 Frame Format

Figure 3, Illustration of the ODTU4.1 Frame Format

This figure shows that the ODTU4.1 Frame consists of two different sections.

  • The ODTU4.1 payload area and
  • The ODTU4.1 overhead area

Figure 3 also shows that the ODTU4.1 payload is a 160 Row x 95 Byte Column structure.  This figure also shows that the ODTU4.1 frame comprises 6 bytes of overhead.

Please note that 160 Rows x 95 Byte Columns = 15,200 Bytes.

This means that the payload portion of each ODTU4.1 frame will carry 15,200 bytes (the exact number of payload bytes each OPU4 frame takes).

What kind of data resides within the ODTU4.1 Payload?

In short, the ODTU4.1 Payload will contain the contents of its respective Extended ODU0 signal.

Whenever we are GMP mapping an Extended ODU0 signal into an ODTU4.1 signal, we will load the entire Extended ODU0 data stream (e.g., ODU0 overhead, FAS field, and payload data) into the ODTU4.1 payload.

We will load this data into the ODTU4.1 payload in the standard transmission order.

What kind of data resides within the ODTU4.1 Overhead?

When the Mapper circuitry GMP maps the Extended ODU0 signal into the ODTU4.1 structure, it will compute and generate some GMP parameters (for this particular mapping operation).

The Mapper circuitry will compute these GMP parameters based upon the exact bit-rates of the Extended ODU0 signal and that on the ODTU4.1 (Server) signal.

The Mapper circuitry will then load this GMP mapping data into the JC1 through JC6 fields (within the ODTU4.1 overhead), just as a GMP mapper would for any client signal.

This set of JC1 through JC6 fields serves the same roles as the JC1 through JC6 fields (within an OPUk structure) whenever we use GMP mapping.

How do we transport the ODTU4.1 Overhead and Payload data across the Optical Link (within an OTN)?

Please see the OMFI Post for details.

Are all the ODTU4.1 signals both frame and byte-synchronous with each other whenever we map this data into the OPU4 payload?

In short, the answer is “Yes.”

The ODTU4.1 frames and signals must have the following timing/synchronization characteristics.

  • Each of the 80 ODTU4.1 signals must be bit-synchronous with each other.
  • These ODTU4.1 signals must also be bit-synchronous with the outbound OPU4 data stream.
  • Each of the 80 ODTU4.1 signals must be frame-synchronous with each other, and
  • All 80 ODTU4.1 signals must be frame synchronous with the 80 OPU4 Frame Superframe they will eventually be multiplexed into.

We will discuss these characteristics (of the ODTU4.1 signals) below.

BUT FIRST – What about the timing and requirements of the ODU0 signals?

Each ODU0 signal (that we are mapping into an OPU4 signal) can be utterly asynchronous to each other.

Additionally, the only absolute timing requirement for the ODU0 signals is that they have to comply with the Frequency Tolerance requirements per ITU-T G.709.

There is also no requirement that these 80 ODU0 signals be frame-aligned with each other either.

However, once the ODU0 signals are each GMP mapped into their ODTU4.1 signal, then each of the ODTU4.1 signals MUST be both byte- and frame-synchronous to each other.

Each of these ODTU4.1 signals must also be bit-synchronous with the outbound OPU4 signal.

Additionally, each of these ODTU4.1 frames must be aligned with the 80 OPU4 frame Superframe (that they will eventually be a part of).

GMP mapping addresses the timing differences between each of the individual ODU0 signals as they transition from the “ODU0 time-domains” to the “ODTU4.1/OPU4 Time Domain”.

All of this means that the ODU0 to OPU4 Mapper Circuit must ensure that “Byte 1” (the very first payload byte) within each of the 80 ODTU4.1 frames are all being applied to the “ODTU4.1 Byte MUX” simultaneously.

Let’s focus on these points in greater detail.

ODTU4.1 Signals being Bit-Synchronous with each other

Figure 4 presents an illustration of an ODU0 to OPU4 Mapper circuit.

This figure presents 80 sets of “ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper” blocks.

Each block is responsible for GMP mapping their ODU0 signal into an ODTU4.1 Data Signal.

ODU0 to OPU4 Mapper Circuit

Figure 4, Illustration of an ODU0 to OPU4 Mapper Circuit

Figure 4 also shows that a single clock source (e.g., ODTU4.1 and OPU4 Clock Source) will function as the timing source for each of the 80 ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper blocks.

This means that each of the resulting ODTU4.1 signals will be generated based on and synchronized with a common clock source (e.g., the ODTU4.1 and OPU4 Clock Source, in this case).

The OPU4 Output signal will also use the ODTU4.1 and OPU4 Clock Source as its timing source.

ODTU4.1 Signals are Byte-Aligned with Each Other

Figure 5 illustrates an abbreviated byte-stream for each of the 80 ODTU4.1 payload signals.

80 ODTU4.1 Byte Data Streams

Figure 5, Illustration of the Byte Streams for each of the 80 ODTU4.1 Signals (output from the ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper block in Figure 4).

This figure shows that each ODU0 Frame Extenders/ODU0 to ODTU4.1 Mapper circuit must simultaneously generate and transmit the first payload byte of their ODTU4.1 frame.

Likewise, each ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper circuits must all generate and transmit the very second payload byte of their ODTU4.1 frame simultaneously, and so on.

All 80 of these byte streams will then be routed to downstream circuitry, which will byte-multiplex and map this data into the OPU4 payload, as shown below in Figure 6.

Byte Wise Multiplexing 80 ODTU4.1 Signals into the OPU4 Payload

Figure 6, Simple Illustration of Circuitry Byte-Wise Multiplexing Each (of 80) ODTU4.1 Signals into an OPU4 Payload.  

ODTU4.1 Signals MUST be Frame Aligned to the 80 OPU4 Frame Superframe

In the OMFI post, we mentioned that we would ultimately map and multiplex each of the ODTU4.1 signals into an 80 OPU4 Frame Superframe.

Figure 7 illustrates an 80 OPU4 frame Superframe we created by byte-wise multiplexing these 80 ODTU4.1 data streams together.

Full OPU4 Superframe

Figure 7, Illustration of an 80 OPU4 frame Superframe.

Looking at Row 1, Byte-Column 17 within OPU4 Frame # 1, you will see that we have designated this byte-field as “1-1“.

This designation means that this byte originated from ODTU4.1 Signal # 1 and is the very first byte (e.g., byte # 1) within that particular ODTU4.1 frame.

Likewise, we designated the next byte-field (to the right) as “2-1“.

This means that this byte originated from ODTU4.1 Signal # 2 and that it is the very first byte within that particular ODTU4.1 frame, and so on.

Figure 6 also shows that the very first payload byte (within the 80 OPU4 frame Superframe) is the very first payload byte (within an ODTU4.1 frame) that originates from ODTU4.1 Signal # 1 (e.g., byte-field “1-1“).

This figure also shows that the next 79 bytes (within this OPU4 frame) are the very first bytes (within each of their ODTU4.1 frames) originating from ODTU4.1 Signal # 2 through ODTU4.1 # 80.

We have designated the next 79 bytes as “2-1“, “3-1“, and so on, all the way to “80-1“.

This figure reinforces the fact that each of the ODTU4.1 streams must also be frame-aligned with each outbound 80 OPU4 frame Superframe.

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 Available for a Short Time!!!

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

What is the OMFI Field?

This post defines the acronym OMFI (OPU Multi-Frame Indicator). It also describes when and how we use the OMFI field in OTN (Optical Transport Network) applications.

What is the OMFI (OPU Multi-Frame Indicator) Field?

Introduction

OMFI is an acronym for “OPU Multi-Frame Indicator.”

We use the OMFI field when mapping/multiplexing multiple lower-speed ODUj tributary signals into an ODU4 server signal (where j ranges from 0 through 3 and can include flex or 2e).

Whenever we are mapping/multiplexing these lower-speed ODUj tributary signals into an OPU4 server signal, we will do so on an 80 OPU4 frame Superframe basis.

As we map and multiplex these lower-speed ODUj tributary signals into an OPU4 signal, we will create as many as 80 sets of GMP Mapping Parameter for each Superframe.

At the Source PTE (Path Terminating Equipment), the ODUj to OPU4 Mapper Circuit will insert each of these 80 GMP Mapping Parameters into the Overhead Fields of the 80 consecutive OPU4 frames within each Superframe.

The payload portions of each of these OPU4 frames will contain multiplexed ODTU4.ts data (e.g., ODTU4.1, ODTU4.2, ODTU4.8, ODTU4.31, or ODTU4.ts data-streams).

The Source PTE will transmit these OPU4 frames to the Sink PTE (at the other end of the path).

At the Sink PTE, the OPU4 to ODUj De-Mapper circuit will need to know which set of GMP Parameter data pertains to which ODTU4.ts data-stream to properly de-map out these ODUj tributary signals from these ODTU4.ts signals, within the incoming OPU4 signal.

The de-mapper will use the OMFI field (within each OPU4 frame) to figure this out.

We will explain this concept in greater detail later on in this blog.

Where is the OMFI field located?

If we are dealing with an OPU4 frame, the OMFI field will reside within the OPU4 Overhead in Row # 4 and Column Byte # 16.

Figure 1 shows a drawing of an OPU4 frame in which we highlight the location of the OMFI field.

OMFI Location
Figure 1, Location of the OMFI field within the OPU4 Frame

The OMFI field does not exist in OPUk frames for any other rates.  The OMFI field only exists within the OPU4 frame.

In other words, OPUflex, OPU0, OPU1, OPU2, OPU2e, and OPU3 frames will NOT have an OMFI field.

When would we use the OMFI field?

We will only use the OMFI field if we are mapping/multiplexing some lower-speed ODUj tributary signals into an OPU4 server signal.

In other words, we would use the OMFI field if we wish to perform any of the following mapping/multiplexing operations:

  • 80 ODU0 signals into an OPU4
  • 40 ODU1 signals into an OPU4
  • 10 ODU2 (or ODU2e) signals into an OPU4
  • 2 ODU3 signals into an OPU4
  • Various combinations of rates/number of ODUflex signals into an OPU4 server signal

Further, we can also use the OMFI field if we are mapping/mapping multiple combinations of rates of ODUflex signals along with the appropriate number of other ODUj tributary signals (where j can be 0, 1, 2/2e, or 3) into an OPU4 server signal.

NOTE:  We do NOT use the OMFI field if we map some non-OTN client signals (such as 100GbE/100GBASE-R) into an OPU4 signal.

So What does the OMFI field do?

The OMFI field is a byte-wide counter that counts from 0 to 79 and then overflows back to 0 repeatedly.

More specifically, a piece of OTN Network Equipment (e.g., the Source PTE) will (at some point) transmit an OPU4 frame with the OMFI field set to the value “0x00”.

When the Source PTE transmits the next OPU4 frame, it will set its OMFI byte-field to 0x01.   The Source PTE will proceed to increment the value that it writes into the OMFI byte-field within each OPU4 frame that it generates and transmits

Eventually, the Source PTE will transmit an OPU4 frame with the OMFI field set to the value 0x4F (which is the number 79 in decimal format).

Afterward, when the Source PTE transmits the very next OPU4 frame, it will then set this field back to 0x00, and it will continue to send another set of 80 consecutive OPU4 frames in this manner, repeatedly.

This means that the OTN network can (and does) use the OMFI field to group 80 consecutive OPU4 frames into an OPU4 Superframe.

We will discuss these OPU4 Superframes later on in this post.

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

Corporate Discounts Available!!!

Why can’t we use the MFAS field for OPU4 Applications?

This is a good question.

The MFAS field (like the OMFI field) is a byte-wide counter.  The behavior and function of these two bytes are very similar.

NOTE:  Please see the OTUk Post for more information about the MFAS field.

The Source STE increments the value within the MFAS byte as it transmits each new OTUk frame.

However, the OMFI byte-field only counts from 0 to 79, and then it overflows back to 0 and then repeats the process.

The MFAS byte counts from 0 to 255, overflows back to 0, and then repeats the process indefinitely.

The MFAS field is convenient for grouping 256 consecutive OTUk/ODUk/OPUk frames into a 256-frame Superframe.

It is also suitable for grouping 4, 8, 16, and 32 consecutive OPUk frames in smaller Superframes. 

NOTE:  We use the MFAS byte when mapping/multiplexing lower-speed ODUj tributary signals into ODU1, ODU2, or ODU3 server signals.  

In short, the MFAS is great for grouping OPUk frames into Superframes with sizes of 2n consecutive OPUk frames (e.g., 22 = 4, 23 = 8, 24 = 16, 25 = 32, and so on).

However, no integer value for n (within the expression 2n) will give you a value of 80.

Thus, if I want to group 80 ODU4 frames into an ODU4 Superframe, the MFAS byte is useless for that purpose.

We need a different byte for this role.  This is why we have the OMFI byte-field.

Would we use the OMFI field for the AMP (Asynchronous Mapping Procedure)?

In a word, “No.”

When mapping client signals into an ODU4 server signal, we will ONLY use the GMP (Generic Mapping Procedure).

We never use AMP to map client signals into an OPU4 payload.  This is NOT allowed per ITU-T G.709.

NOTE:  This statement is true, whether we are mapping non-OTN client data (such as 100GBASE-R) or lower-speed ODUj tributary signals into an OPU4 signal.

To be clear, we can use AMP to map client signals into OPU1, OPU2, and OPU3 signals, but not into an OPU4 signal.

This is a good trick question, however.

This is a trick question because if we were using AMP to map client data into an OPUk frame, then the NJO (Negative Justification Opportunity) byte would occupy the same byte position that the OMFI field occupies for OPU4 applications.

NOTE:  Please see the AMP (Asynchronous Mapping Procedure) post for more information on the NJO byte.

How do we use the OMFI field in a system application?

Let’s assume we wish to map and multiplex 80 ODU0 tributary signals into an OPU4 server signal.

If we want to do this, ITU-T G.709 states that we should perform this mapping/multiplexing in a five-step process.

  • Convert each ODU0 signal into an Extended ODU0 signal.
  • Use GMP to map each of the 80 ODU0 signals into their ODTU4.1 structure/signal.  This step will create 80 ODTU4.1 signals.
  • Byte interleaves all 80 of these ODTU4.1 signals together into a single data stream.
  • Load this byte-interleaved ODTU4.1 data into the OPU4 payload within each outbound OPU4 frame.
  • Load the GMP mapping parameters into the OPU4 overhead.  

Please see the Extended ODUj Post for more details on the Extended ODU0 signal.

What is an ODTU4.1 Frame/Signal?  

The standards define the ODTU4.1 as Optical Data Tributary Unit (for an OPU4/ODU4 server signal) with 1 (one) Time-Slot.

For this post, I will state that the ODTU4.1 structure/signal is an intermediate frame/signal (defined in ITU-T G.709). 

We only use this frame/signal whenever mapping/multiplexing ODU0 tributary signals into an OPU4 signal.

We present a more thorough description of the ODTU4.1 structure in another post.

Figure 2 shows a drawing of a Mapper Circuit that performs this two-step Mapping/Multiplexing Process.

ODU0 to OPU4 Mapper Circuit

Figure 2, Illustration of an 80 ODU0 Signal to OPU4 Mapper Circuit

Whenever we GMP map a given ODU0 signal into an ODTU4.1 structure, the Mapper circuit will compute the resulting GMP parameters for this single mapping operation.

What’s the Deal with the Number 80?

Since we individually map each of the 80 ODU0 signals into their ODTU4.1 structure, and since each of the 80 ODU0 signals CAN be asynchronous to the remaining 79 ODU0 signals, there will be 80 unique sets of GMP mapping parameters within this OPU4 signal.

The ODU0 to OPU4 Mapper circuit will need to insert each of these 80 sets of GMP parameters into the OPU4 data stream to provide the OPU4 to ODU0 De-Mapper circuit (at the remote Sink PTE) with the GMP Justification Control information that it needs to be able to properly de-map out each of the ODU0 signals from their ODTU4.1 signal.

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

Discounts Available for a Short Time!!!

So, where does the Mapper Circuit insert the GMP parameters (for all 80 ODU0s) into the OPU4 Frame?

I mentioned earlier that when mapping lower-speed ODUj tributary signals into an OPU4 signal, we execute this procedure by creating an 80 OPU4 frame Superframe.

In other words, as we map and multiplex these 80 ODU0 signals into the OPU4 signal, we will also create these 80 OPU4 frame Superframes.

In the OPU Post, I stated that each OPUk frame consists of an OPUk Payload and OPUk Overhead.

Thus, an 80 OPU4 frame Superframe will contain 80 sets of OPU4 payload and will also include 80 sets of OPU4 overhead.

Please note that each of these OPU4 Superframes contains 80 frames and we are trying to map 80 ODU0s into an OPU4 is NOT a coincidence.

This was all done by design.

ITU-T G.709 states that an ODU0 to OPU4 Mapper circuit should insert the GMP parameters (that we obtained when we GMP mapped ODU0 # 1 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 1 (within the 80 OPU4 Frame Superframe).

Likewise, the standard also states that the Mapper should insert the GMP parameters (we obtained when we mapped ODU0 # 2 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 2.

This process should continue to OPU4 Frame # 80.

At this point, the ODU0 to OPU4 Mapper circuit has completed its transmission of an 80 OPU4 Frame Superframe, and it should start transmitting a new Superframe by sending OPU4 Frame # 1 again (and so on).

But How Do We Know Which OPU4 Frame is OPU4 Frame # 1, # 2, and so on?

The short answer is the contents of the OMFI byte of each of these OPU4 frames.

Whenever the OMFI byte (within a given OPU4 frame) is set to “0x00”, we can state that this particular OPU4 Frame is the first frame in the 80-frame Superframe.

Hence, we can designate this frame as being OPU4 Frame # 1.

Likewise, whenever the OMFI byte (within a given OPU4 frame) is set to “0x01”, we can state that this particular OPU4 frame is the second frame in the 80-frame Superframe.

Thus, we can designate this frame as OPU4 Frame # 2, and so on.

We Use the OMFI Byte to Identify Each of these 80 OPU4 frames.

Therefore, if the Sink PTE (at the remote end) receives an OPU4 frame, in which the OMFI byte is set to “0x00”, then we know the following things about the overhead data within that frame.  We understand that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data we obtained when the Source PTE mapped ODU0 # 1 into its ODTU4.1 frame/signal.

Likewise, if the Sink PTE receives an OPU4 frame, in which the OMFI byte is set to “0x01”, we know the following about the overhead data within this frame.  We understand that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data we obtained when the Source PTE mapped ODU0 # 2 into its ODTU4.1 frame/signal.

And so on, for the remaining 78 frames within this OPU4 frame Superframe.  

Figure 3 presents an abbreviated drawing of an 80 OPU4 Frame Superframe.

This figure also shows some helpful information about the contents of the Overhead data within each of the OPU4 frames. 

More specifically, this drawing also identifies which ODU0 to ODTU4.1 frame GMP mapping operation these overhead fields pertain to within each OPU4 frame.

80 OPU4 Frame Superframe

Figure 3, Illustration of an 80 OPU4 Frame Superframe

For example, for OPU4 Frame 1, some red text states the following:  “GMP Mapping Data associated with ODTU4.1/ODU0 # 1″. 

This text means that the six Justification Control bytes (e.g., the JC1 through JC6 byte – in the Pink Fields) contain the GMP mapping parameters that the Source PTE generated when it GMP mapped ODU0 # 1 into ODT4.1 signal # 1.    

This is handy information for the Sink PTE.  

So what does the De-Mapper Circuit do?

As the De-Mapper circuit (within the remote Sink PTE) receives and processes these OPU4 frames, it will need to execute the following two-step procedure to properly de-map and recover these ODU0 tributary signals from this incoming OPU4 data stream.

  • Byte de-interleaves the OPU4 payload data into 80 parallel streams of these ODTU4.1 signals.
  • Use GMP to de-map each ODU0 signal from their ODTU4.1 signal (e.g., de-map 80 ODU0 signals out of 80 ODTU4.1 signals)

I show an illustration of an OPU4 to 80 Channel ODU0 De-Mapper circuit below in Figure 4.

OPU4 to ODU0 De-Mapper Circuit

Figure 4, Drawing of an OPU4 to 80 Channel ODU0 De-Mapper Circuit

De-Mapping the ODU0 Signal from Each ODTU4.1 Signal

However, for the de-mapper circuit (within the Sink PTE) to do this successfully, it will need to have the correct GMP mapping parameters that the Source PTE created at the remote end. 

In other words, for the Sink PTE to de-map out ODU0 # 1 from ODTU4.1 signal # 1, it will need to have the same GMP mapping parameters that the Source PTE (at the remote end) generated when it mapped ODU0 # 1 into ODTU4.1 signal # 1, in the first place.  

Likewise, for the Sink PTE to de-map out ODU0 # 2 from ODTU4.1 signal # 2, it will need to have the same GMP mapping parameters that the Source PTE (again, at the remote end) generated when it mapped ODU0 # 2 into ODTU4.2 signal # 2.  

The Sink PTE will receive 80 sets of GMP mapping parameters within each 80 Frame OPU4 Superframe.  

How does the Sink PTE know which (of the 80) GMP mapping parameters to de-map out ODU0 # 1 from ODTU4.1 signal # 1?  

Answer:  It needs to use the overhead data within the OPU4 frame, in which the OMFI byte is set to 0x00.

Thus, the de-mapper circuit must rely on the OMFI value to keep this information straight.

In other words, the Sink PTE will use the OMFI byte to properly marry up each of the 80 GMP mapping parameters (within the incoming OPU4 data stream) with 80 ODTU4.1 data streams.  

Hence, using the OMFI byte, the Sink PTE will be able to correctly de-map out all 80 ODU0 signals from each of their ODTU4.1 signals that we extract from the incoming OPU4 data stream.  

Does ITU-T G.798 Define any Defects that Pertain to the OMFI field?

Yes, ITU-T G.798 does define the dLOOMFI (Loss of OMFI Synchronization) defect for applications in which we are mapping and multiplexing lower-speed ODUj signals into an OPU4/ODU4 signal.

I discuss how ODU-Layer circuitry will declare and clear the dLOOMFI defect condition within Lesson 10 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Summary and Other Related Postings

This post describes the OMFI field (within the OPUk frame) and how we use it whenever we are mapping and multiplexing 80 ODU0 signals into an OPU4/ODU4 signal.  We also have similar postings (on the OMFI field) for the following cases.

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 Available for a Short Time!!!

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

What is the PSI – Payload Structure Identifier Byte

This post describes the role of the PSI (Payload Structure Identifier) byte, within the OPUk Overhead, is used within the OTN.

What is the PSI – Payload Structure Identifier (Byte and Message)?

The PSI Byte

The PSI (or Payload Structure Identifier) byte is an Overhead byte within the OPUk structure.

Figure 1 presents an OPU frame with the location of the PSI byte identified.

Generic OPU Frame with PSI Byte Highlighted

Figure 1, Illustration of an OPUk Frame Structure with the Overhead Bytes (along with the PSI Byte) Identified  

The purpose of the PSI byte is to permit an OTN Path Terminating Equipment (PTE) to transport a 256-byte PSI (payload structure identifier) message throughout the OTN (Optical Transport Network).

The primary purpose of this 256-byte PSI Message is to permit the Source PTE to alert the OTN (Network) of the type of data (or traffic) we are transporting within this particular OPU data stream.

Since each OPUk frame contains only 1 PSI byte, an OTN PTE will have to transmit 256 consecutive OPU frames to transmit this PSI message completely.

The OTN PTE will align its transmission of this 256-byte PSI message with the MFAS byte.

Please see the OTUk Frame Structure post for more information on the MFAS byte.

In other words, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x00”, then the OTN PTE will also be sending the first byte of the PSI message (e.g., PSI[0]) via the PSI byte-field.

Likewise, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x01”, then the OTN PTE will also be sending the second byte within this 256-byte message (e.g., PSI[1]) via the PSI byte field, and so on.

Two Types of PSI Messages

An OTN Source PTE will transport one of two types of PSI Messages.

  • The Non-Multiplexed Traffic – PSI Message, and
  • The Multiplexed Traffic – PSI Message.

I will describe each of these types of PSI Messages below.  

The Non-Multiplexed Traffic PSI Message

We will use the Non-Multiplexed Traffic PSI Message when transporting Non-Multiplexed Traffic within our OPU data stream.

Examples of Non-Multiplexed Traffic would be:

  • Transporting 1000BASE-X via an OPU0 signal
  • 10GBASE-R via an OPU2e signal.
  • 100GBASE-R via an OPU4 Signal.

In other words, we are handling Non-Multiplexed Traffic whenever we only transport a single Non-OTN client signal via this OPUk data stream.  

I present an illustration of an OPU Frame, with the PSI field highlighted (along with a break-out of the Non-Multiplexed Traffic type of PSI Message) below in Figure 2.

OPU Frame with PSI Byte-Field highlighted and a Breakout of the Non-OTN Client/Non-Multiplexed PSI Message

Figure 2, Illustration of an OPU Frame, transporting the Non-Multiplexed traffic of PSI Message

NOTE:  The easiest way to tell if you’re working with the Non-Multiplexed Traffic type of PSI Message is to check and see if you see the CSF (Client Signal Fail) bit-field in PSI Byte # 2.

If the CSF bit-field is present, you’re dealing with the Non-Multiplexed Traffic type of PSI Message.

If the CSF bit-field is NOT present (within the PSI Message), then you are dealing with the other type of PSI Message.

The Multiplexed Traffic Type of PSI Message

We use the Multiplexed Traffic type of PSI Message anytime we work with an OPU server signal transporting numerous lower-speed ODUj Tributary Signals.

For example, if we mapped and multiplexed 80 ODU0 tributary signals into an OPU4 server signal, then this OPU4 signal would transport the Multiplexed Traffic type of PSI Message.

Figure 3 presents an illustration of an OPU Frame, with the PSI field highlighted, along with a break-out of the Multiplexed Type of PSI Message.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 3, Illustration of an OPU Frame transporting the Multiplexed Traffic Type of PSI Message

Again, one big difference between the Multiplexed Traffic type of PSI Message and that for Non-Multiplexed Traffic is that the Multiplexed Traffic type of PSI Message will not have the CSF (Client Signal Fail) bit-field.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

The PSI Message

The PSI (Payload Structure Identifier) message is a 256-byte message that an OTN terminal will transport via the PSI byte for 256 consecutive OPUk/ODUk/OTUk frames.

Let’s talk a little bit about the data that we are transporting within these PSI Messages.  

PSI[0] – or PSI Byte # 0 – PT (Payload Type)

The first byte of the PSI Message (e.g., PSI[0]) carries the Payload Type (or PT) value.  The PT byte identifies the type of client data the OPUk structure is transporting via its payload.  

First, Table 1 presents a list of standard PT values and the corresponding client data types (being transported within the OPUk Structure).

Table 1a, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part I

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1b, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part II

PT - Payload Type - PSI Byte - Client Signal into OPUk

NOTES: 

  1. We will discuss the PT = 0x07 case when mapping 100GBASE-R into an OPU4 in Lesson 4.  
  2. Access to Lesson 4 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

Table 1c, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part III

PT - Payload Type - PSI Byte - Client Signal into OPUk

NOTE: 

  1. We will discuss cases where PT = 0x20 and 0x21 in Lesson 5.  
  2. Access to Lesson 5 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

Table 1d, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part IV

PT - Payload Type - PSI Byte - Client Signal into OPUk

Other posts contain detailed information on how ITU-T G.709 recommends that the System Designer map each client signal into their corresponding OPUk structure.

Click HERE for more information about the PT = 0x21 Method for Mapping/Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.

The Remaining Bytes within the PSI Message

PSI bytes 1 and 3 through 255 are for “Mapping and Concatenation Specific” roles that we will discuss in another post. 

In Multiplexed-Traffic Type of PSI Messages

For the Multiplexed-Traffic type of PSI Message, we use these bytes to transport MSI (Multiplex Structure Identifier) information throughout the OTN.  

In other words, we will transport the MSI information (via these PSI Messages) for applications in which we are mapping/multiplexing lower-speed ODUj tributary signals into higher-speed OPUk/ODUk server signals.

The MSI aims to identify these lower-speed ODUj tributary signals we are transporting via this OPUk/ODUk signal to the OTN.  

You can think of the MSI as a passenger list or manifest of lower-speed ODUj tributary signals riding along (or being transported) within this OPUk server signal.  

In Non-Multiplexed-Traffic Type of PSI Messages

PSI byte 2, Bit 1 (for the Non-Multiplexed Traffic PSI Message) is the CSF (or Client Signal Fail) indicator.  The ITU-T Standards Committee has reserved PSI Byte 2, Bits 2 through 8 for “future standardization.”

We discuss the CSF indicator and the MSI information in other posts.

We also extensively discuss these PSI Messages within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!.  

You can click on the Banner below to learn more our this training package.

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 Available for a Short Time ONLY!!

For More Information on OTN-Related 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