Category: Optical Transport Networks

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.

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

The BMP (Bit-Synchronous Mapping Procedure)

This post describes the Bit-Synchronous Mapping (BMP) for mapping non-OTN CBR client signals into an OTN signal.


What is the BMP (Bit-Synchronous Mapping Procedure)?

This post describes the BMP (Bit-Synchronous Mapping Procedure) for mapping a non-OTN CBR (Constant Bit Rate) client signal into an OPUk/ODUk signal.

NOTE:  Whenever ITU-T G.709 discusses procedures for mapping a client signal into an OPUk/ODUk signal, it will often refer to the OPUk/ODUk signal as the Server signal.  

Therefore, we will use the terms OPUk/ODUk and Server interchangeably throughout the remainder of this post.

ITU-T G.709 also defines two other mapping procedures that one can use to map a non-OTN CBR client signal into a Server signal.

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

We discuss each of these other two mapping procedures in other posts.

What is the Bit-Synchronous Mapping Procedure?  

The name Bit-Synchronous Mapping Procedure means that there is a bit-synchronous relationship between the client signal (that we are mapping into an OPUk payload) and the bit rate of the OPUk payload.

In other words, the System Designer must ensure that ALL the following conditions are true before they can use the Bit-Synchronous Mapping Procedure to map a particular client signal into the OPUk payload.

  • The OPUk/ODUk/OTUk clock signal must be phase-locked (or synchronized) to the client clock signal, as Figure 1 illustrates below.

Timing Requirements between Client Signal and OPUk/ODUk Signal to use Bit Synchronous Mapping Procedure - BMP

Figure 1, Illustration of the Synchronization Requirements (between the OPUk/ODUk/OTUk signal and the client signal) to use BMP

  • We must use fixed-stuffing to handle rate differences (between the Client signal and OPUk/ODUk/OTUk signal).
    • In other words, we insert a fixed number of bits/bytes into the Server (OPUk) payload, along with the client data.
      • OPUk_rate = Client_rate + (Fixed_Stuff x Server_Frame_Rate);
  • Client bit-rate tolerances MUST NOT exceed the Server bit-rate tolerances.
    • For example, if the bit-rate tolerance for an OPUk is +/-20ppm, then the Client signal’s bit rate tolerance cannot exceed +/-20ppm.

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

Discounts Available for a Short Time!!

ITU-T G.709 Recommendations on Using BMP

ITU-T G.709 recommends using BMP when mapping the following non-OTN Client Signals into each of the OPUk/ODUk Structures listed below in Table 1.

Table 1, List of Client Signals that ITU-T G.709 Recommends using BMP when mapping into an OPUk Structure

ITU-T G.709 Recommendations for the Bit-Synchronous Mapping Procedure (BMP)

BMP and De-Mapping Jitter

BMP offers the best de-mapping jitter of the three recommended Mapping Procedures.  

Fixed stuffing and the presence of the OTUk/ODUk/OPUk overhead bytes are the only contributions to mapping (and de-mapping jitter).  Justification events (which imposes 8UI-pp of mapping-related jitter) for AMP applications do not occur in BMP.

However, the System Designer will still need to implement a clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.  

This requirement is especially true for SONET/SDH applications.

Summary

Finally, Table 2 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODUk clock) that the System Designer must comply with before using any ITU-T G.709 Recommended Mapping Procedures.  

Please note that I have highlighted the BMP items below with a “Red Rectangular” outline.

TABLE 2, MAPPING PROCEDURE TIMING REQUIREMENTS

BMP Mapping Requirements

Has Inflation got You Down? Our Price Discounts Can Help You Fight 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

ODU/ODUk – Optical Data Unit

This post defines and describes the ODU (Optical Data Unit) Frame that is used in OTN (Optical Transport Networks).

What is the ODU/ODUk (Optical Data Unit)?

An ODU (Optical Data Unit) is a data structure that Path Terminating Equipment (PTE)  within an Optical Transport Network (OTN) will generate and monitor as it transmits and receives data.

This post will call any entity that generates and transmits ODUk frames a Source PTE.  Likewise, we will call any entity that receives, processes, and terminates ODUk frames a Sink PTE.  

Anytime an OTN Terminal “wishes” to transport an ODUk frame to the outside world (over a fiber-optic connection), it will first encapsulate this data into an OTUk Frame.

In other words, an ODUk frame is a subset of an OTUk frame.

NOTE:  This post will discuss the ODUk structures (such as the ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, and ODUflex).

This post will not be discussing the new (higher-rate) ODUCn structures.  Please see the post on ODUCn structures for information on these types of structures.

OTN Path and Section Terminating Equipment

In the OTN arena, we will often state that the OTN Path Terminating Equipment (PTE) is the entity that is responsible for handling and processing ODUk frames.

We will also state that OTN Section Terminating Equipment (STE) handles and processes OTUk frames.

Please see the posts for OTN Path Terminating Equipment (PTE) and OTN Section Terminating Equipment (STE) to understand these two types of equipment.

The ODUk Frame Format

An ODUk consists of an OPUk structure, along with the ODUk Overhead fields.

Figure 1 presents an illustration of the ODUk structure, along with its overhead.

ODU Frame with ODU Overhead Shown

Figure 1, Illustration of an ODUk Structure

The ODU Structure (and Overhead) aims to help the OTN manage the transmission of OPU frames (transporting client data) from the Source PTE to the Sink PTE.

The OTN will use the ODU Overhead to monitor the Network’s performance and health (or the Path) as we transport these OPUk frames from the Source PTE to the Sink PTE.  

Figure 2 illustrates a single OTN Path network connection bounded by a Source PTE and a Sink PTE.

OTN Path Terminating Equipment connected to the Optical Transport Network

Figure 2, an Illustration of a single OTN Path (which is bounded by both a Source PTE and a Sink PTE)

The Source and Sink PTE (in Figure 2) will perform the following tasks on the data it processes.

Processing at the Source PTE

The Source PTE is a piece of equipment that will take on the responsibility of mapping a client signal into an OTN signal (e.g., into an OPUk structure).

Whenever the Source PTE maps this client signal (which could be a 1GbE, 100GbE, OC-48, FC-800 Signal, etc.) into an OTN signal:

  • It will accept the client data (from the client-side equipment), and it will map this signal into an OPUk Structure, and
  • The Source PTE will also compute and generate the ODUk Overhead, and
  • Finally, it will combine the ODUK Overhead and OPUk Structure to form an ODUk Frame.

Processing at the Sink PTE

The Sink PTE  will also be responsible for de-mapping (or extracting) the client signal from the OTN signal.

In this case, whenever the Sink PTE de-maps this client signal from an OTN signal:

  • It will evaluate the ODUk Overhead of each ODUk frame it receives (to check for client signal data integrity and the occurrence of defect conditions).  It will terminate the ODUk signal.
  • The Sink PTE will also terminate the OPUk structure and
  • It will de-map (or extract) the client signal from the OPUk structure.
  • Finally, the Sink PTE will output this client signal to the client-side equipment for further processing.

NOTE:  The OTN Path Terminating Equipment (at the “Source” and “Sink” terminals) will map (the client signal into an OTN signal) and de-map (the client from the OTN signal) in such a way as to minimize the amount of jitter within the de-mapped client signal.

Please see the posts on BMP, AMP, and GMP mapping for more details on this topic.

Things that the user can do with an ODUk frame

Once a “Source” PTE creates an ODUk frame, there are two things that it can do with the ODUk frames.

  • The Source PTE/STE can encapsulate this ODUk into an OTUk frame structure and then transmit this OTUk frame to a remote piece of terminal equipment (over a fiber-optic connection), or
  • It can treat this ODUk signal as a tributary signal and multiplex this ODUk signal into a higher-speed ODUm server signal (where m > k).  Please see the post on ODUk Multiplexing for more details.

You cannot transport an ODUk signal over optical fiber without first mapping this signal into an OTUk signal.  We only transport OTUk signals on optical fiber.  

Definition of the ODUk Overhead

The ODUk Overhead is a 3 Row by 14 Byte Column structure that contains the following thirteen (13) fields.

  • RES – Reserved
  • PM/TCM Byte
  • EXP – Experimental Byte
  • TCM1 Field
  • TCM2 Field
  • TCM3 Field
  • TCM4 Field
  • TCM5 Field
  • TCM6 Field
  • PM Field
  • GCC1 Field
  • GCC2 Field
  • APS/PCC Field

I describe each of these overhead fields below.

RES – Reserved

These fields are “reserved” and currently have no standardized role or function within the ODU overhead.

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

Discounts Available for a Short Time!!

PM (Path Monitoring) Field (3 Bytes)

Figure 3 shows the byte format for the Path Monitoring Field.

ODU PM (Path Monitoring) Field

Figure 3, Byte-Format of the PM (Path Monitoring) Field.

Hence, Figure 3 shows that the PM Field consists of the following three bytes:

  • TTI- Trail Trace Identifier Byte
  • BIP-8 Byte
  • PM Byte

Below, we will describe each of the bytes (within the PM field).  We also discuss these bytes in much greater detail in other posts.

TTI Byte – Trail Trace Identifier Byte

This byte-field carries the 64-byte Path Monitoring Trail-Trace Identifier message.

Since there is only one TTI byte within each ODU frame (not including that within the TCMn fields), the Source PTE will have to transmit 64 consecutive ODUk frames to transmit this 64-byte Trail Trace Identifier message completely.

Please see the Path Monitor – Trail Trace Identifier post to see how we use this identifier in an OTN system.

BIP-8 (Path Monitoring, BIP-8) Byte

The PTE will perform a BIP-8 calculation over the entire OPUk frame within its corresponding ODUk frame.

Afterward, the Source PTE will insert the results of this BIP-8 calculation into the BIP-8 byte field of the outbound ODUk frame two frame periods later.

The remote Sink PTE will use this BIP-8 calculation to check for bit errors during transmission from the Source PTE to the Sink PTE.

Please see the Path Monitoring BIP-8 post for more information about this byte field and how it is computed and used in an OTN system.

PM (Path Monitoring) Byte

Figure 4 presents the bit format for the Path Monitoring byte (not to be confused with the 3-byte PM Field).

ODU PM (Path Monitoring) Byte - BEI, BDI, STAT

Figure 4, Bit Format of the Path Monitoring Byte

This figure shows that the PM Byte consists of the following bit-fields

  • BEI (4-bits)
  • BDI (1 bit)
  • STAT (3 bits)

We will briefly describe each of these bit-fields below.

BEI – Path Monitoring – Backward Error Indicator (BEI) (4 bits)

The purpose of the BEI Nibble field is to permit a Network Element (consisting of a Source PTE and a Near-End Sink PTE) to send feedback to the far-end Network Element on the quality of the ODUk signal that it is sending to our Network Element.

As the Near-End Sink PTE receives its stream of ODUk frames (from the far-end Network Element), it will check and verify the PM-BIP-8 values within each incoming ODUk frame.  

While the Near-End Sink PTE performs this task, it will determine the total number of bits in error between its locally computed PM-BIP-8 byte value and that it has received from the far-end Network Element.  

The Source PTE will obtain that number from its Near-End Sink PTE and then load that number (of PM-BIP-8 bits in error) into the BEI Nibble-field within the ODUk frames and transmits it back out to the far-end Network Element.  

In doing this, our local Network Element provides the far-end Network Element with the total number of PM-BIP-8 bit errors that are received from it.

Table 1 lists the value that our Near-End Source PTE will set the BEI Nibble based upon the number of PM-BIP-8 bit errors that its Near-End Sink PTE has detected.  

Table 1, How to Interpret the Path Monitoring BEI bit-fields

ODUk PM BEI Bits and the Number of BIP-8 Errors Detected

Please see the Path Monitoring Error/Defect post to learn more about these defects and error conditions.

BDI – Path Monitoring – Backward Defect Indicator

The purpose of the BDI bit-field is to permit the Source PTE to alert the remote (far-end) Network Element that the local (near-end) Sink PTE is declaring a service-affecting defect.  

The Source PTE will set this bit-field to a “0” or “1” depending upon whether the local (near-end) Sink PTE is declaring a service-affecting defect condition (at the ODUk-layer), as I describe below. 

0 – The Source PTE will set the BDI bit-field to “0” if the near-end Sink PTE is NOT declaring a service-affecting defect condition.

1 – The Source PTE will set this bit-field to “1” if the near-end Sink PTE is currently declaring a service-affecting defect condition.

Please see the Path Monitoring Error/Defect post to learn more about the BDI defect.

STAT – ODU Path Monitoring Status (STAT) Indicator

The Sink PTE will use the STAT fields to determine if it should declare a Maintenance signal-related defect, as shown below in Table 2.

Table 2, How to Interpret the STAT bit-fields within the PM Field

STAT Field within the Path Monitor Field of an ODU Frame

For example, if the Sink PTE were to receive (and accept) a STAT field value of [1, 0, 1], then the Sink PTE will declare the dAIS (ODUk-AIS) defect condition.  

PM/TCM Byte

For ODUk applications (e.g., ODU0, ODU1, ODU2, ODU3, ODU4, and ODUflex), the PM/TCM byte contains seven (7) defined bit-fields.

Figure 5 presents an illustration of the PM/TCM Byte-field.

Path Montoring/Tandem Connection Monitor Byte

Figure 5, Illustration of the PM/TCM Byte-Field

This figure shows that Bit 7 (within the PM/TCM Byte-Field) functions as DMp (or Path Delay Measurement) and that bits 1 through 6 functions as DMti (of Tandem Connection Monitoring Delay Measurements).

Please see the DMp (Path Delay Measurement) post for more details on the DMp bit-field.  And please see the post on DMt1 through DMt6 (TCM Delay Measurements) for more information about the DMti bit-fields.

EXP – Experimental Byte (4 Bytes within the ODUk Overhead)

The ODU Overhead has a total of 4-byte fields that are labeled EXP.  There are two (2) 1-byte fields and one (1) 2-byte field for EXP.

There is no standard-specified use for the EXP bytes.

For now, the System Designer/Manufacturer can use these byte fields to support vendor-proprietary features if they choose to do so.

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

Discounts Available for a Short Time!!

TCM1 (Tandem-Connection Monitoring 1) Field

TCM1 through TCM6 all support Tandem Connection Monitoring.

Please see the post on Tandem Connection Monitoring for more information on how these fields are used in the OTN.

The byte field for the TCM1 field is presented and briefly defined below.  See Figure 6 for the byte format of the TCM1 field.

TCMi (Tandem Connection Monitoring) Field

Figure 6, Byte-Format of the TCM1 Field

Figure 6 shows that the TCM1 Field consists of the following three bytes:

  • TTI- Trail Trace Identifier Byte
  • BIP-8 Byte
  • TCMi-SM Byte

NOTES

  1. The role of the TTI and BIP-8 bytes within the TCM1 field is identical to that presented for the ODUk Path Monitoring Field, and we will not repeat that discussion here.  Please see the post on Tandem Connection Monitoring for more details on how the OTN network uses these byte fields.
  2. Note that the TCMi-SM byte is different from the ODUk PM byte.  Please see the post on the TCMi-SM byte for more information on how we use this byte-field in the network.
  3. The role of the bytes within the TCM1 field is identical to that for the TCM2 through TCM6 fields, and we will not repeat that discussion below.  Please see the post on Tandem Connection Monitoring for more details on how the OTN network uses these byte fields.

TCM2 Field

Please see the description for the TCM1 Field.

TCM3 Field

Same as the description for the TCM1 Field.

TCM4 Field 

Please see the description for the TCM1 Field.

TCM5 Field

Same as the description for the TCM1 Field.

TCM6 Field

Please see the description for the TCM1 Field.

GCC1 – General Communication Channel # 1 – (2 byte)

The GCC1 field is a general communications channel for proprietary communication to the System Designer/Manufacturer.

This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.

Please see the GCC1 post for more information about this field.

GCC2 Field – General Communication Channel # 2 – (2 Byte)

The GCC2 is a general communications channel for proprietary communication to the System Designer/Manufacturer.

This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.

Please see the GCC2 post for more information about this field.

APS/PCC Field – ODU Automatic Protection Switching and Protection Communication Channel

Please see the ODU Automatic Protection Switching and the Protection Communications Channel post to learn more about how we use this 4-byte field in an OTN system.

ODUk Bit Rates

Table 3 presents the ODUk bit rate for each type of ODUk signal.

Table 3, Bit-Rate for each type of ODUk Signal

ODUk Bit Rate

NOTES:

  1. We define the ODUflex structure in another post.
  2. This post only addresses ODUk types of structures.  Please see the post on ODUCn to learn more about those structures.

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

Discounts Available Temporarily

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

The OTU (Optical Transport Unit) Frame

This post defines and describes the OTU (Optical Transport Unit) Frame that is used in OTN (Optical Transport Networks).

What is the OTU Frame/OTUk Frame?

An OTU (Optical Transport Unit) frame is a data structure that an OTN Terminal (or Source STE) will use to transport its data to the outside world.

This post will call any entity that generates and transmits OTUk frames a Source STE (Section Terminating Equipment).  Likewise, we will call any entity that receives, processes, and terminates OTUk frames a Sink STE.  

In other words, as the Source STE accepts OPU/ODU frames to create an OTUk frame, it will encapsulate these OPU/ODU frames into an OTU frame by “tacking” on the OTUk overhead. 

Additionally, the Source STE will pre-condition each OTUk frame for transport over Optical Fiber by computing and appending an FEC (Forward Error Correction) field at the back end of the OTU frame and scrambling much of the OTUk frame data before converting this data into the optical domain and sending it out on Optical Fiber.  

Likewise, the OTU frame is a data structure that an OTN Terminal (or Sink STE) will accept as it receives data from the outside world.

In this case, the OTN Terminal (e.g., Sink STE) will perform the reverse functions as the Source STE.  

It will receive an optical signal from the remote STE and convert this data back into an electrical format.  Afterward, it will descramble this incoming OTUk data stream, decode the FEC field, and correct most symbol errors in the process.  

Finally, the Sink STE will terminate the OTUk data stream by extracting out the OPU/ODU frames and routing this data to downstream circuitry.  

To be clear, What do We Mean by Frame?

OTN, just like many other Networking Standards, uses framing to organize the data it transmits and receives.

Framing is a Data Link Layer function.  A transmitting terminal will organize a group of data bits into a specific data structure (called a “frame”) before transmitting it across a link.

Please see the post about the Data Link Layer for more information about the concept of Framing.

Please note that we are not talking about this kind of frame.

For OTN applications, we only transmit data that we have encapsulated into the form of an OTU frame out onto optical fiber.

OPUk and ODUk signals may be handled and processed internally (within a network element or an integrated circuit).

But we NEVER transmit OPUk and ODUk data onto the network (over optical fiber) unless we first encapsulate these signals into an OTUk frame and pre-condition this data for transport over Optical Fiber.

OTN Section and Path Terminating Equipment

In the OTN arena, we will often state that OTN Section Terminating Equipment (STE) is the entity that is responsible for transmitting and receiving OTUk frames.

We will also state that OTN Path Terminating Equipment (PTE) handles and processes ODUk frames.

Please see the posts for OTN Section Terminating Equipment (STE)and OTN Path Terminating Equipment (PTE) to understand the differences between these two types of equipment.

The OTUk Frame Format

Figure 1 illustrates the format for the standard ITU-T G.709-compliant OTU Frame.

OTUk Frame - Byte Format

Figure 1, Illustration of the Format of the ITU-T G.709-Compliant OTU Frame

This figure shows that an OTU Frame is a 4-Byte-Row by 4080-Byte-Column Structure.  Hence, each OTU Frame consists of (4 x 4080 =)16,320 bytes.

Please note that all OTU Frames (whether an OTU1, OTU2, OTU3, or OTU4 frame) are all the same size; therefore, each frame has exactly 16,320 bytes.

NOTE:  Since each of these OTU frames are the same size (regardless of whether we are talking about an OTU1, OTU2, OTU3, or OTU4), we will, from here on, refer to these OTU frames as OTUk frames.

The Fields within an OTUk Frame

Let’s talk about the various fields within an OTUk frame.

Some of the fields in the OTUk frame have the following labels.

  • FAS
  • MFAS
  • OTUk OH
  • FEC
  • ODUk Frame

I will briefly define each of these bytes below.

FAS – Framing Alignment Signal field

The Framing Alignment Signal field occupies the first 6 bytes within an OTUk Frame.

The first three bytes (which we sometimes call the OA1 bytes) each have a fixed value of 0xF6.

The remaining three bytes (in the FAS field), which we sometimes call the OA2 bytes, each have a fixed value of 0x28.

The purpose of the FAS bytes is to provide the remote receiving OTN terminal (e.g., the Sink STE) with this fixed pattern so that it will “know” that it is receiving the first bytes of a new OTUk frame.

The Sink STE will parse through its incoming OTUk frame data stream.  As it does this, it will search for the occurrence of three consecutive bytes (each with the value 0xF6) followed by another set of three successive bytes (each with the value 0x28).

The Sink STE will rely on these FAS bytes to acquire and maintain framing alignment/synchronization with the incoming stream of OTUk frames.

If the Sink STE repeatedly fails to acquire and maintain framing alignment/synchronization with this incoming stream of OTUk frames, it will declare the dLOF (Loss of Frame) defect condition.  

MFAS – Multi-Frame Alignment Signal byte

The MFAS byte occupies the 7th byte within an OTUk frame and “resides” immediately after the FAS bytes.

Unlike the FAS bytes, the MFAS byte’s value is not fixed, as I will explain here.  

A given Source STE will transmit OTUk frames in groups of Multi-frames.

Each of these multi-frames consists of 256 consecutive OTUk frames.

Whenever a Source STE transmits the first OTUk frame (of a given Multi-frame), it will designate this particular frame as the first frame (of this multi-frame) by setting its MFAS byte field to 0x00.

When the Source STE transmits the next OTUk frame, it will set the MFAS byte (within that particular OTUk frame) to 0x01, and so on.

As the Source STE transmits each OTUk frame, it will increment the value assigned to the MFAS byte field until it reaches the value 0xFF (or 255 in decimal format).

The Source STE will then start over with transmitting a new multi-frame and set the MFAS of this next OTUk frame to 0x00, and the process repeats indefinitely.

The MFAS is a significant byte for a receiving OTN terminal (e.g., Sink STE) to keep track of because other data (such as the TTI – Trail Trace Identifier message – that is transmitted via some of the additional overhead bytes across multiple OTUk frames).

The Source STE will align the transmission of these particular messages (e.g., the SM-TTI messages, PM-TTI messages, PSI Messages, etc.) with the MFAS byte as it transports these messages via the OTUk data stream.

Please see the relevant posts on SM-TTI (Section Monitoring – Trail Trace Identifier) Messages, PM-TTI (Path Monitoring – Trail Trace Identifier) Messages, and PSI (Payload Structure Identifier) Messages to learn more about these types of messages.  

ODUk Frame

The ODUk Frame “portion” of the OTUk frame is all the remaining data (which resides within the OTUk frame) that is not considered an OTUk Overhead field.  This includes all bytes within the ODU (Optical Data Unit) and, in turn, OPU (Optical Payload Unit) within the OTUk frame.  Please see the posts for ODUk and OPUk to learn more about those parts of the OTUk frame.

FEC – Forward Error Correction

ITU-T G.709 specifies that OTUk frames should include an FEC (Forward Error Correction) field that contains the Reed-Solomon RS (255,239) FEC codes.

NOTE:  I discuss the RS(255,239) FEC code in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

The FEC field permits a Sink STE to detect and correct many symbol (or byte) errors that may have occurred during transmission.

ITU-T G.709 indicates that using FEC is optional for OTU1, OTU2, and OTU3 applications.  

However, the use of FEC is mandatory for OTU4 applications.  

Please see the OTUk FEC discussion within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!  for more information about this field.

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

Discounts Available for a Short Time!!!

The Rest of OTUk OH (Overhead) fields

The remaining OTUk OH fields consist of the following three fields for a total of seven (7) bytes:

  • SM Field
  • GCC0 Field
  • OSMC (OTN Synchronizing Messaging Channel) Field
  • RES (Reserved) Field

We will briefly describe each of these fields below.

SM (Section Monitoring) Field (3 bytes)

Figure 2 shows the byte format for the Section Monitoring or SM Field.

OTU - SM (Section Monitoring) Field, TTI Byte, BIP-8 Byte, SM Byte

Figure 2, Byte-Format of the SM (Section Monitoring) Field

This figure shows that the SM Field consists of the following three bytes:

  • TTI – Trail Trace Identifier Byte
  • BIP-8 Byte
  • SM Byte

Below, we will describe each of the bytes (within the SM field).  We also discuss these fields in much greater detail in their respective posts.

TTI – Trail Trace Identifier Byte

This byte-field carries the 64-byte Section Monitoring Trail-Trace Identifier message.  Since there is only one TTI byte within each OTUk frame, the OTN Transmitter (or Source STE) will transmit 64 OTUk frames to send the entire 64-byte Trail Trace Identifier message.

Please see the Section Monitor-Trail Trace Identifier post to learn how we use this identifier in an OTN system.

BIP-8 (Section Monitoring BIP-8) Byte

The Source STE will perform a BIP-8 calculation over the entire OPUk frame within its corresponding OTUk frame.

Afterward, the Source STE will insert the results of this BIP-8 calculation into the SM-BIP-8 byte field of the outbound OTUk frame two frame periods later.

Finally, the remote Sink STE will use this BIP-8 calculation to check for bit errors during transmission.

Please see the Section Monitoring BIP-8 post for more information about how we compute and use this byte field in an OTN system.

SM (Section Monitoring) Byte

Figure 3 presents the bit format for the Section Monitoring Byte (not to be confused with the 3-byte SM field).

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

Figure 3, Bit Format of the Section Monitoring Byte

This figure shows that the SM Byte consists of the following bit fields:

  • BEI/BIAE (4 bits)
  • BDI (1 bit)
  • IAE (1 bit)
  • RES – Reserved (2 bits)

We will briefly describe each of these bit-fields below.

BEI/BIAE – Section Monitoring – Backward Error Indicator (BEI) or Backward Incoming Alignment Error (BIAE) – (4 bits)

The purpose of the BEI/BIAE nibble-field is two-fold.

  • To permit the Source STE to provide the remote Sink STE (at the far-end) with feedback on the number of SM-BIP-8 errors that the near-end (local) Sink STE is detecting within its incoming OTUk data stream.
    • The Source STE will set the BEI/BIAE nibble-field (within each outbound OTUk frame) to the SM-BEI (Backward Error Indicator) value.  
  • And to permit the Source STE to alert the remote Sink STE (again, at the far-end) that the near-end (local) Sink STE is declaring the dIAE defect condition.
    • The Source STE will accomplish this by setting the BEI/BIAE nibble-field to the value of “1011”, which carries the BIAE (Backward Input Alignment Error) Indicator.  

Table 1 presents the range of values that the Source STE can set the BEI/BIAE Nibble-field, within its outbound OTUk frames, for each of the conditions mentioned above. 

Table 1, How to Interpret the Section Monitoring BEI/BIAE bit-fields

OTUk SM_BEI/BIAE Nibble-ValueSink STE declaring the dIAE Defect?Number of SM-BIP-8 Errors DetectedComments
0000NO0Good Condition
0001NO1BIP-8 Error
0010NO2BIP-8 Errors
0011NO3BIP-8 Errors
0100NO4BIP-8 Errors
0101NO5BIP-8 Errors
0110NO6BIP-8 Errors
0111NO7BIP-8 Errors
1000NO8BIP-8 Errors
1001, 1010NO0Good Condition
1011YES0BIAE Indicator
1100 to 1111NO0Good Condition

Please see the Section Monitoring Error/Defect post to learn more about these defect and error conditions.

BDI – Section Monitoring – Backward Defect Indicator Bit Field

The purpose of the BDI bit-field is to permit the Source STE to alert the remote (far-end) Network Element that the local (near-end) Sink STE is declaring a service-affecting defect.  

This Source STE will set this bit-field to “0” or “1” depending upon whether the local (near-end) Sink STE is declaring a service-affecting defect condition (at the OTUk-layer), as I describe below.

0 – The Source STE will set the BDI bit-field to “0” if the near-end Sink STE is NOT declaring a service-affecting defect condition.

1 – The Source STE will set the BDI bit-field to “1” if the near-end Sink STE is currently declaring a service-affecting defect condition.

Please see the OTUk-BDI post to learn more about the BDI defect condition.

IAE – Section Monitoring Incoming Alignment Error Bit-Field

The Source STE will set this bit-field to “0” or “1” depending upon whether the upstream circuitry detects a frame-slip event within an ODU signal that we are ultimately mapping into this particular OTUk data stream (that this Source STE is transmitting downstream).

0 – Indicates that upstream circuitry is NOT detecting any frame-slip events (within the ODU signal we are mapping into this particular OTUk signal).   The Source STE will set the IAE bit-field to “0” (within its outbound OTU data-stream) to denote this good condition.

1 – Indicates that upstream circuitry is currently detecting a frame-slip event (within the ODU signal we are mapping into this particular OTUk signal).  The Source STE will set the IAE bit-field to “1” (within its outbound OTU data-stream) to denote this abnormal condition.

I present detailed information on the IAE bit-field within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!.

GCC0 – General Communication Channel # 0 – (2 bytes)

The GCC0 is a general communications channel for proprietary communication to the System Designer/Manufacturer.

This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.

Please see the GCC0 post for more information about how the System Designer/Manufacturer can use this field.

OSMC – OTN Synchronization Messaging Channel  – 1 byte

The Network User can use the OSMC channel to transport SSM (Synchronization Status Messages) or PTP (Precision Time Protocol) messages throughout the OTN.

Please see the OSMC post for more information about how the System Designer/Manufacturer can use this field.

RES – Reserved (or Undefined) (1 byte)

OTUk Frame Repetition Rates and Bit Rates

Since all speeds (or types) of OTUk signals use the same frame size, the reason that (for example) an OTU2 runs at a faster bit rate than does an OTU1 is that the frame repetition rate for an OTU2 is higher (e.g., more rapid) than that for an OTU1.

Table 2 presents the OTUk frame period and bit rate for each type of the OTUk signal.

Table 2, Frame Periods and Bit-Rate for each kind of OTUk signal

OTUk Bit Rate and OTUk Frame Period

NOTES:

  1. This post has defined the Fully Compliant OTUk frames.   It does not address the functionally standardized OTUk frames (such as the OTUkV or OTUk-v).  Please see the posts for the OTUkV and OTUk-v frames for more information on these types of frames.
  2. This post does not discuss the new OTUCn types of OTN signals.  Please see the OTUCn post for more information on these higher-speed signals.

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

(DISCOUNT OFFERED for a Short Time ONLY!!)

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 are some OTN Mapping Procedures?

This post briefly lists and describes the various mapping procedures that have defined for OTN applications and specified in ITU-T G.709.


What Mapping Procedures can we use to Map a Non-OTN Client Signal into an OTN Signal?

This post briefly reviews each standard procedure for mapping non-OTN client signals into an OTN (Optical Transport Network) signal.

Other posts discuss these mapping procedures in greater detail.  

Introduction

As the name suggests, OTN (Optical Transport Network) is a transport technology.  The purpose of the OTN is to transport user (or client) data from Point A to Point B.

All this is analogous to a train system that transports passengers from one train station to another.  In this case, the OTN is the “train,” and the client data are the passengers.

The client data can be a wide range of possible signals (or data types). 

For example, it could be 1GbE (1000BASE-X), 8Gbps Fibre Channel (FC-800), 100GbE (100GBASE-R), SONET/SDH signal, or many other possible client signals.  

We can transport each type of client signal (and more) from one location to another via the OTN.

Note that as we discuss the term mapping (in this and other posts on this website), we are NOT talking about the type of map shown in the figure below.

Mapping Client Signals into OPUk/ODUk/OTUk Frames

Whenever we map a client signal into an OTN signal, we map this client signal into the OPUk portion of an OTUk frame.

Additionally, whenever we map a non-OTN client signal into the OPUk portion of an OTUk frame, we will map this client signal into the entire OPUk payload.

NOTE:  We do discuss OPUk and OTUk frames in other postings.

ITU-T G.709 recommends three mapping schemes we can use when mapping a (non-OTN) client data into (or de-mapping client data from) an OPUk.

(*) – Requires Membership of THE BEST DARN OTN TRAINING PRESENTATION TRAINING….PERIOD!!

Each of these mapping procedures will use its form of rate-adaptation (e.g., adapting the client signal rate to that of the OTN signal).

As I mentioned earlier, I discuss each of these mapping procedures in greater detail – in other postings on this blog.

Let’s quickly review each of these mapping procedures below.

BMP – Bit Synchronous Mapping Procedure

  • Requires that the following equation is true:

Client_Data_Bit_Rate = OPU_Payload_Carrying_Bit_Rate + some Fixed Stuffing

  • This equation means that the OPU Payload data clock signal should be phase-locked to the Client data clock signal.
  • BMP offers the best jitter performance for client signals that are de-mapped from OTN.
    • BMP does not impose any variable byte-stuffing that you can have in both AMP (e.g., the justification events) and GMP.   This fact gives BMP slightly better de-mapping jitter performance than AMP and GMP.  

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

Discounts Available for a Short Time!!!

AMP – Asynchronous Mapping Procedure

  • AMP does not require that the timing between the Client_Data_Clock and the OPU_Payload_Data_Clock be synchronized (as is necessary for BMP).
  • However, to use AMP, the System Design must ensure that the frequencies of the Client_Data_Clock (of the Non-OTN Client Signal) and the OPU_Payload_Data_Clock signals must be within ±65ppm of each other.
    • In other words, the Client data rate can be slightly slower or faster than the OPUk Payload Carrying data rate.
    • AMP is the only recommended mapping procedure that permits us to map a client signal with a slightly faster nominal bit-rate than the OPUk payload, provided that we do not violate the above-mentioned 65ppm requirement.
  • The OTN terminal accommodates these timing differences by performing negative or positive-justification actions on the Non-OTN client data (at the Byte level)  as it loads the client data into the OPUk Payload.  We are inserting stuff-bytes into or removing stuff bytes from the OPUk payload through these justification actions.  This procedure is somewhat similar to executing Pointer Adjustments in SONET/SDH.
  • De-mapping Jitter Performance for AMP is not as good as that for BMP.  The client data incurs 8 UIp-p of (pre-clock smoothing/jitter attenuation) jitter with each justification (negative or positive stuffing) event.

GMP – Generic Mapping Procedure

  • Requires that the Client bit-rate be less than or equal to the OPUk_Payload bit-rate.
    • In other words, the Client bit rate CANNOT be higher than the OPUk Payload bit rate.
  • GMP does not mandate any synchronization or frequency offset requirements.
    • The bit rate of the Non-OTN client signal can be WAY OFF from that of the OPUk Payload to use GMP.  
    • For example, ITU-T G.709 recommends using GMP to map an STM-1/STS-1 signal (155.52 Mbps) into an OPUO server signal (1.238934310 Gbps).  
  • One of the goals of GMP is to evenly distribute the Payload and Stuff Bytes throughout the OPUk payload to enhance de-mapping jitter performance.
  • I cover GMP mapping in detail in Lesson 4, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

When to use BMP, AMP, and GMP – per ITU-T G.709

ITU-T G.709 recommends the following mapping procedures for various Client signal types and OTN rates (see Tables 1 through 4 below)

Table 1, ITU-T G.709 Recommended Mapping Recommendations for SDH signals.

Mapping Procedure for SDH (Synchronous Digital Hierarchy) Signals

Table 2, ITU-T G.709 Recommended Mapping Recommendations for Ethernet Signals

Mapping Procedure for Gigabit Ethernet Signals, 1000BASE-X, 10GBASE-R, 40GBASE-R, 100GBASE-R

Table 3, ITU-T G.709 Recommended Mapping Recommendations for Fibre Channel Signals

Mapping Procedure for Fibre Channel Signals

Table 4, ITU-T G.709, Recommended Mapping Recommendations for Misc Signals.

Mapping Procedures for GPON, InfiniBand Signals

Summary

Table 5 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODU clock) that the System Design must comply with before using any of these Mapping Procedures.

Table 5, Mapping Procedure Timing Requirements

Timing Requirements for BMP, AMP and GMP

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

Temporary Discount Available Now

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 OPU – Optical Payload Unit?

This post presents the definition of an OPU (Optical Payload Unit) frame, within an OTU Frame.

What is the OPU – Optical Payload Unit?

The OPU (Optical Payload Unit) is that portion of an OTU Frame that transports “payload” or “client-data” throughout the Optical Transport Network.

An OPU is a subset of an ODU (Optical Data Unit) and an OTU (Optical Transport Unit) Frame.

Figure 1 presents an illustration of an OTU Frame and also identifies the location of the OPU frame.

OPUk Frame - Byte Format

Figure 1, Illustration of an OTU Frame with the OPU Portion (of the Frame) identified.  

We will typically give the OPU (just like its larger OTU cousin) a designation such as OPU0, OPU1, OPU2, OPU3, and OPU4, depending upon the “data rate” or the Data Carrying Capacity of this structure.

Table 1 lists the data-carrying capacity for each type of OPU structure.

Table 1, The Data Carrying (Rate) or Capacity of each OPU Structure.

OPUk Bit Rates, OPU0, OPU1, OPU2, OPU2e, OPU3, OPU4, OPUC4

From this point forward, we will refer to the OPU structure as an OPUk (where k can be 0, 1, 2, etc… as presented in Table 1).

NOTE:  We describe the ODUflex/OPUflex structure in another post.

The Basic OPUk Frame Format

The OPUk frame consists of two types of bytes:

  • Payload Bytes (which we use to transport the Client Data) and
  • Overhead Bytes permit OTN equipment to manage the transport of this data.

ITU-T G.709 typically draws the OPUk Payload as a 4-Row x 3808-Byte-Column Structure, yielding 15,232 bytes.

The OPUk Structure also includes 8 Overhead Bytes as well.  Hence, the full OPUk Frame (of OPU Payload and Overhead) is a 4-Row x 3810-Byte Column Structure, yielding 15,240 bytes.

Figure 2 presents a Generic Illustration of the OPUk Framing Format with the OPUk Overhead Bytes highlighted.

Generic OPUk Frame

Figure 2, Illustration of a Generic View of the OPUk Structure (e.g., OPUk Payload with the Overhead Bytes highlighted)

Why Do I Call Figure 2 a “Generic Illustration”?

I refer to Figure 2 as a “Generic Illustration” of the OPUk Structure because it includes all possible names/roles for the OPU Overhead bytes.

The names and roles of these OPUk Overhead fields will change depending on which of the following sets of data rates and mapping procedures we are using.

  • When operating at the OPU0 through OPU3 rates and using AMP/BMP Mapping
  • For the OPU0 through OPU3 rates and using GMP Mapping and
  • If running at the OPU4 rate and using GMP Mapping to map/de-map Non-OTN Clients
  • For the OPU4 rate and using GMP Mapping to map/de-map lower-speed ODUj tributary signals into/from this OPU4 server signal.

We will briefly illustrate and describe the roles of the OPUk overhead for each of these operating modes.

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

Discounts Available for a Short Time!!!

The OPUk Frame Format and Overhead for the OPU0 through OPU3 server rates when using BMP/AMP.

If we are supporting the OPU0 through OPU3 rates and if we are using AMP (Asynchronous Mapping Procedure) or BMP (Bit Synchronous Mapping Procedure) to map non-OTN client data or lower-speed ODUj tributary signals into this OPUk server signal, then Figure 3 shows us the OPUk Frame format and overhead that we will be using.

OPU0 through OPU3 AMP Applications

Figure 3, An Illustration of the OPUk Frame Format (and Overhead) for the OPU0 through OPU3 server rates whenever we use AMP or BMP.  

Figure 3 shows that the OPUk Frame (for this Operating Mode) has the following overhead bytes:

  • JC1 – Justification Control Byte # 1
  • JC2 – Justification Control Byte # 2
  • JC3 – Justification Control Byte # 3
  • PSI – Payload Structure Identifier Byte
  • NJO – Negative Justification Opportunity Byte
  • PJO – Positive Justification Opportunity Byte

In the case of the OPU0 – OPU3/AMP/BMP modes, the JC1, JC2, JC3, NJO, and PJO bytes will all support the mapping and de-mapping operations of client data into and out of the OPUk signal.

Please see the AMP Post for more details on the roles of these overhead byte fields.

The PSI byte carries information about and identifies the type of client data that the OPUk frame is transporting.

Please see the PSI post for more details about the roles of this byte-field.

NOTE:  Figure 3 presents the appropriate OPUk Frame Format and Overhead for all PT = 0x20 applications and some PT = 0x21 applications in which we use AMP.  

The OPUk Overhead for the OPU0 through OPU3 rates, when we use GMP to map/de-map client signals into/out of the OPUk server signal.

If we support the OPU0 through OPU3 rates and use GMP (the Generic Mapping Procedure) to map either non-OTN client data or lower speed ODUj tributary signals into this OPUk server signal then Figure 4 shows a drawing of the OPUk frame format that we will be using.

OPU0 through OPU3 - GMP Applications

Figure 4, An Illustration of the OPUk Frame Format for the OPU0 through OPU3 rates whenever we use the GMP mapping procedure.  

Figure 4 shows that the OPUk Frame (for this Operating Mode) has the following overhead bytes:

  • JC1 – Justification Control Byte # 1
  • JC2 – Justification Control Byte # 2
  • JC3 – Justification Control Byte # 3
  • JC4 – Justification Control Byte # 4
  • JC5 – Justification Control Byte # 5
  • JC6 – Justification Control Byte # 6
  • PSI – Payload Structure Identifier byte

In the case of the OPU0 – OPU3/GMP modes, the JC1, JC2, JC3, JC4, JC5, and JC6 bytes will all support the GMP mapping and de-mapping of client data into/from an OPUk signal.

Please see the GMP Procedure for Mapping/De-Mapping Non-OTN Client signal training (in Lesson 4 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!) on how we use these byte-fields to support the mapping/de-mapping of non-OTN client data into/from OPU frames.

Likewise, please see Lesson 5 (within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!) for information on how we use the GMP Procedure for Mapping/De-Mapping Lower-Speed ODUj Tributary Signals into an ODUk Server signal.  This same lesson will also include information on how we use these byte-fields to support the mapping/de-mapping lower-speed ODUj tributary signals into/from the ODUk server signal.  

Once again, the PSI byte carries information about and identifies the type of client data that the OPUk frame is transporting.

Please see the PSI post for more details about the roles of this byte-field.

NOTE:  Figure 4 presents the appropriate OPUk Frame Format and Overhead for some PT = 0x21 applications.

The OPUk Overhead for OPU4 Applications – Non-OTN Client Case

If we support the OPU4 rate and use GMP to map/de-map a non-OTN client signal into/from this OPU4 signal, then Figure 5 presents an appropriate OPU4 frame format and overhead fields that we will be using.  Hence, we would use this OPU frame when GMP mapping a 100GBASE-R signal into an OPU4 signal.  

OPU4 Frame for Non-OTN Client applications

Figure 5, An Illustration of the OPU4 Frame structure whenever we use GMP to map/de-map a non-OTN client.  

Figure 5 is very similar to Figure 4, with one exception.

For OPU4 applications, the last eight columns (within the payload) are always a fixed-stuff region that we cannot use to transport data.

Other than that, Figure 5 has the same set of Overhead Bytes as does Figure 4.

The JC1, JC2, JC3, JC4, JC5, and JC6 bytes will all support the GMP mapping and de-mapping client data into/from an OPU4 signal.

Please see the GMP Procedure for Mapping/De-Mapping Non-OTN Client signals lesson (e.g., Lesson 4 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!)  for more information on how we use these byte-fields to support the mapping/de-mapping of non-OTN client data.

The OPUk Overhead for OPU4 Applications – Lower-Speed ODUj Tributary Signal Case

If we are supporting the OPU4 rate and if we are also using GMP to map/de-map lower-speed ODUj tributary signals into/from this OPU4 server signal, then Figure 6 presents a drawing of the appropriate OPU4 frame format and overhead fields that we will be using.

OMFI Location

Figure 6, An Illustration of the OPU4 Frame structure whenever we use GMP to map/de-map lower-speed ODUj tributary signals.

Figure 6 is identical to Figure 5, with one exception.

For Non-OTN Client applications, the byte-field in Row 4/Column 16 is labeled “RES” (for RESERVED) and serves no purpose for mapping/de-mapping client data into/from the OPU4 signal.

For Lower-Speed ODUj Tributary Signal Mapping applications, we call this byte-field the OMFI (OPU Multi-Frame Identifier) field.

The JC1, JC2, JC3, JC4, JC5, JC6, and OMFI bytes will all support the GMP mapping and de-mapping of lower-speed ODUj tributary signals into/from an OPU4 signal.

Please see Lesson 5 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  For more information on how we use these byte-fields to support the mapping/de-mapping of Lower-Speed ODUj Tributary signals into an ODUk Server signal.

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Become an Expert in OTN? Click Below to Learn More!!

Discounts Available Temporarily

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