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.
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.
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.
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).
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
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
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.
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.
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
- 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.
- 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.
- 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
NOTES:
- We define the ODUflex structure in another post.
- 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.
