Tag: OPU Frame

Lesson 2 – OPU Framing

This blog post presents a training video on the OPU (or Optical Payload Unit) frames. This post also contains a written overview of OPU frames as well.

OTN Lesson 2 – OPU (Optical Payload Unit) Framing

An OPU (Optical Payload Unit) frame is that portion of an OTU (Optical Transport Unit) frame that carries and transports client data throughout the Optical Transport Network (OTN).

You can Check Out the Training Video on OPU Framing Below.

Click on the Link Below to See the ODU Training Video

Click on the Link Below to Return to the Main Lesson 2 Page.

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

Where is the OPU Layer within the OTN Protocol Stack?

Figure 1 presents an illustration of the OTN Protocol Stack, with the OPU Layer Highlighted.

OTN Protocol Stack - OPU Layer Highlighted

Figure 1, Illustration of the OTN Protocol Stack, with the OPU Layer Highlighted

This figure shows that the OPU Layer is the closest layer to the Client Layer. We map the client data into OPU frames and transport them throughout the OTN.

The Basic Structure of the OPU Frame

I present an illustration of the Basic (or Generic) Structure of the OPU Frame below in Figure 2.

Generic OPUk Frame

Figure 2, Illustration of the Basic (or Generic) Structure of an OPU Frame

Each OPU frame is a 4 Row x 3810 byte-column structure. The OPU Frame consists of two basic types of fields.

  • The Payload Fields (which are the Pink-colored fields in Figure 2), and
  • The Overhead Fields (those non-Pink-colored fields on the left-hand side of the figure).

Each OPU frame contains 8 overhead bytes. And all OPU rates (except for the OPU4 frame) include 15,232 payload bytes. OPU4 frames have 15,200 payload bytes, as I show later in this post.

We use the Payload Fields to transport the client data and the Overhead fields for management purposes.

What Do the OPU Overhead Fields Manage?

In general, the OPU Overhead Fields (that I show in Figure 2) manage the following tasks.

  • They manage the mapping of client data into the OPU payload, and
  • These fields also (in turn) manage the de-mapping of client data from the OPU payload.
    • The JC1 – JC6, NJO, and PJO bytes support this effort.
  • They identify (to the OTN) the type of client signal that we are transporting via this particular OPUk signal.
    • The PSI byte supports this role.
  • And finally, they support mapping Lower-Speed ODUj Tributary signals into an OPU4 frame (in particular).
    • The OMFI byte supports this role.

What are some of the Various Types of OPU Frames

Throughout this training, we will be working with the following four types of OPU frames.

  • The BMP (Bit Synchronous Mapping Procedure) frame.
  • The AMP (Asynchronous Mapping Procedure) Applications
  • The GMP (Generic Mapping Procedure) Applications – up to OPU3 Rates
  • The GMP (Generic Mapping Procedure) Applications – for the OPU4 Rate

Let’s Discuss Each of these Types of OPU Frames below.

OPU Frames for BMP Applications

Figure 3 presents an illustration of an OPU Frame that supports BMP Mapping.

OPUk Frame for BMP Mapping Applications

Figure 3, Illustration of an OPU Frame – supporting BMP Mapping

This is by far the simplest OPU frame.

In this particular OPU frame, the JC1 through JC3 and the NJO bytes serve no real purpose other than to occupy space. Additionally, the PJO byte will always transport client data for BMP Mapping applications.

The PSI (Payload Structure Identifier) byte will repeatedly transmit the PSI Message. We will discuss the PSI Message later in this blog post.

Click Here to learn more about the Bit Synchronous Mapping Procedure (BMP) in Lesson 4.

OPU Frames for AMP Applications

Figure 4 illustrates an OPU frame that supports AMP Mapping Applications.

AMP Discussion - Basic Figure - Introduction of OPUk OH

Figure 4, Illustration of an OPU Frame – supporting AMP Mapping Applications

The OPU Frame in Figure 4 looks (and is) very similar to that for Figure 3. However, in the case of Figure 4, the JC1 through JC3, NJO, and PJO bytes are all active and play a significant role in AMP Mapping (or De-Mapping).

Please Click Here to learn more about AMP Mapping and these overhead fields in Lesson 4.

OPU Frames for GMP Applications – up to OPU3

Figure 5 presents an illustration of an OPU Frame that supports GMP Mapping. In this frame, we are looking at a figure that supports OPU rates from OPU0 up to OPU3.

OPU0 through OPU3 - GMP Applications

Figure 5, Illustration of an OPU Frame – supporting GMP Mapping Applications (OPU0, OPU1, OPU2, OPU3, and OPUflex).

As you can see, the OPU Overhead for this frame looks VERY different from that of Figures 3 and 4. AMP and BMP Mapping are closely related to each other. However, GMP is a VERY different mapping procedure from AMP or BMP.

Hence, GMP Mapping will require using 6 Justification Control fields (JC1 through JC6). Additionally, GMP does not use the NJO or PJO fields.

Finally, this brings us to the next (and final) type of OPU Frame.

OPU Frames for GMP Applications – OPU4 Applications

Figure 6 presents an illustration of an OPU Frame that also supports GMP Mapping applications. However, this particular figure is only applicable to the OPU4 Rate.

OPU Overhead - GMP Mapping - JC1 through JC6 Break down at the Bit-Level

Figure 6, Illustration of an OPU Frame – supporting GMP Mapping Applications (OPU4 ONLY)

The OPU Frame in Figure 6 looks very similar to that in Figure 5, with just two differences.

  • The OPU4 Frame has an OFMI byte-field in the OPU Overhead in Row 4, and
  • The OPU4 Frame has a total of 32-byte area reserved for Fixed Stuffing.

Both OPU Frames in Figures 5 and 6 have six (6) sets of Justification Control Bytes (JC1 through JC6). These Justification Control fields are required to support GMP Mapping.

How is the OPU4 Frame different from the other OPU Frames?

Each OPU frame I show in Figures 3, 4, and 5 has 15,232 bytes within their OPU Payload.

However, because the OPU4 frame has this 32-byte Fixed Stuff area (at the back-end of this frame), it only has 15,200 bytes within its OPU Payload.

I show a different illustration of the OPU4 frame, in which the OMFI is more visible, below in Figure 7.

OPU4 Frame for Lower-Speed ODUj applications

Figure 7, Another Illustration of the OPU4 Frame

Click Here to learn more about GMP Mapping in Lesson 4.

The OMFI (Optical Multi-Frame Identifier) byte field only exists in OPU4 Frames. Additionally, we only use the OMFI field when supporting Multiplexed Applications. We will never use the OMFI field if we are just (for example) mapping a 100GBASE-R client signal into an OPU4 payload.

For example, we will use the OMFI field if we are mapping 80 ODU0 signals into an OPU4/ODU4 server signal.

Click HERE to learn more about Multiplexed Applications (e.g., Mapping Lower-Speed ODUj Tributary Signals into a Higher-Speed ODUk Server signal) in Lesson 5.

The PSI Byte and the Payload Structure Identifier Message

Let’s talk about the PSI Byte-field.

In Figure 8, I illustrate our Generic OPU Frame with the PSI Byte-field Highlighted.

Generic OPU Frame with PSI Byte Highlighted

Figure 8, Illustration of the Generic OPU Frame, with the PSI Byte-field Highlighted.

This figure shows that the PSI byte is located in Row 4, Byte-Column 15, within the OPU frame.

The purpose of the PSI byte is to transport the PSI Message repeatedly.

What is the PSI Message?

The PSI (or Payload Structure Identifier) Message is a 256-byte message that identifies the kind of traffic we are transporting via this particular OPU data stream.

ITU-T G.709 defines two different types of PSI Messages.

  • The Non-OTN Client/Non-Multiplexed Structure PSI Message and
  • The Multiplexed Structure – PSI Message

Figure 9 presents an illustration of an OPU Frame, with the PSI Byte Highlighted, along with a breakout of the Non-OTN Client/Non-Multiplexed Structure PSI Message.

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

Figure 9, Illustration of the OPU Frame, with the PSI Byte-field highlighted and a breakout of the Non-OTN Client/Non-Multiplexed Structure PSI Message.

Likewise, Figure 10 presents an illustration of an OPU Frame, with the PSI Byte Highlighted, along with a breakout of the Multiplexed Structure PSI Message.

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

Figure 10, Illustration of the OPU Frame, with the PSI Byte-field highlighted and a breakout of the Multiplexed Structure PSI Message.

What is the Non-OTN Client/Non-Multiplexed Structure PSI Message?

The Non-OTN Client/Non-Multiplexed Structure PSI Message is one variation of a PSI Message. This message is 256 bytes in length (just like its Multiplexed Structure counterpart).

We use this type of PSI Message when working with an OPU frame that is transporting a Single Non-OTN Client Signal (such as 1000BASE-X or 100GBASE-R).

The easiest way to tell if you are working with the Non-OTN Client/Non-Multiplexed PSI Message is if you see the CSF (Client Signal Fail) Bit-field within PSI byte 2.

What is the Multiplexed Structure PSI Message?

The Multiplexed Structure PSI Message is the other variant of a PSI Message.

We use this type of PSI Message when working with an OPU Frame transporting numerous Lower-Speed ODUj Tributary Signals.

The easiest way to tell if you are working with the Multiplexed Structure PSI Message is to see if you do NOT see the CSF (Client Signal Fail) Bit-field within PSI Byte 2.

How Do We Transport the PSI Message?

Since an OPU frame only contains a single PSI Byte, each PSI Message (whether it is the Non-OTN Client/Non-Multiplexed or the Multiplexed-Structure type) is 256 bytes; we have to transport each PSI Message over a stream of 256 consecutive OPU frames.

The Source PTE will continuously transmit the relevant PSI Message over and over.

Again, this PSI Message aims to inform the OTN of the type of client data we are transporting within this particular OPU data stream.

What is the PT (or Payload Type) Byte?

If you take a close look at the PSI Messages within both figures 9 and 10, then you notice that the very first byte within each of these PSI Messages is the PT (or the Payload Type) byte.

The Payload Type byte is key to helping us identify the type of traffic that we are transporting via this OPU data stream.

Table 1 lists the many standard values for PT and the corresponding traffic we are transporting within our OPU data stream.

Table 1, Listing of the Many ITU-T G.709 Standard Values of PT (Payload Type) and the Corresponding Client Signal(s) we are transporting within our OPU data stream.

Payload Type Value (Hex)Interpretation (Client Data Type)
01Experimental Mapping (Note 3)
02Asynchronous CBR Mapping, see Clause 17.2
03Bit-Synchronous CBR Mapping, See Clause 17.2
04Not Available (Note 2)
05GFP Mapping, See clause 17.4
06Not Available (Note 2)
07PCS Codeword Transparent Ethernet Mapping:
1000BASE-X into OPU0, see Clause 17.7.1 and 17.7.1.1
40GBASE-R into OPU3, see Clauses 17.7.4 and 17.7.4.1
100GBASE-R into OPU4, see Clauses 17.7.5 and 17.7.5.1
08FC-1200 into OPU2e mapping, see Clause 17.8.2
09GFP Mapping into Extended OPU2 Payload, see Clause 17.4.1 (Note 5)
0ASTM-1 Mapping into OPU0, see Clause 17.7.1
0BSTM-4 Mapping into OPU0, see Clause 17.7.1
0CFC-100 Mapping into OPU0, see Clause 17.7.1
0DFC-200 Mapping into OPU1, see Clause 17.7.2
0EFC-400 Mapping into OPUflex, see Clause 17.9
0FFC-800 Mapping into OPUflex, see Clause 17.9
10Bit stream with Octet timing mapping, see Clause 17.6.1
11Bit stream without octet timing mapping, see Clause 17.6.2
12IB SDR mapping into OPUflex, see clause 17.9
13IB DDR mapping into OPUflex, see clause 17.9
14IB QDR mapping into OPUflex, see Clause 17.9
15SDI mapping into OPU0, see Clause 17.7.1
16(I.485/1.001) Gbit/s SDI mapping into OPU1, see Clause 17.7.2
171.485 Gbit/s SDK mapping into OPU1, see Clause 17.7.2
18(2.970/1.001) Gbit/s SDI mapping into OPUflex, see clause 17.9
192.970 Gbit/s SDI mapping into OPUflex, see Clause 17.9
1ASBCON/ESCON mapping into OPU0, see clause 17.7.1
1BDVB_ASI mapping into OPU0, see clause 17.7.1
1CFC-1600 mapping into OPUflex, see Clause 17.9
1DFlexE Client mapping into OPUflex, see Clause 17.11
1EFlexE aware (partial rate) mapping into OPUflex, see Clause 17.12
1FFC-3200 Mapping into OPUflex, see Clause 17.9
20ODU Multiplex Structure supporting ODTUjk only, see Clause 19 (AMP only)
21ODU Multiplex Structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see Clause (GMP capable) (Note 6)
22ODU Multiplex Structure supporting ODTUCn.ts, see Clause 20 (GMP capable)
3025GBASE-R mapping into OPUflex, see Clause 17.13
31200GBASE-R mapping into OPUflex, see Clause 17.13
32400GBASE-R Mapping into OPUflex, see Clause 17.13
55Not Available (Note 2)
66Not Available (Note 2)
80 - 80FReserved Codes for Proprietary Use (Note 4)
FDNULL Test Signal Mapping, see Clause 17.5.1
FEPRBS Test Signal Mapping, see Clause 17.5.2
FFNot Available (Note 2)

NOTES from Table 1

  1. There are 198 spare codes left for future international standardization. Refer to Annex A of ITU-T G.806 for the procedure to obtain one of these codes for a new Payload Type.
  2. These values are excluded from the set of available code points. These bit patterns are present in ODUk maintenance signals or were used to represent client types that are no longer supported.
  3. The value “01” is only used for experimental activities in cases where a mapping code is not defined in this table. Refer to Annex A of ITU-T G.806 for more information on the use of this code.
  4. These 16 code values will not be subject to further standardization. Refer to Annex A of ITU-T G.806 for more information on the use of these codes.
  5. Supplement 43 (2008) to the ITU-T G-series of Recommendations indicated that this mapping was recommended using PT = 0x87.
  6. Equipment supporting ODTUk.ts for OPU2 or OPU3 must be backward compatible with equipment that supports only the ODTUjk. ODTUk.ts capable equipment transmitting PT = 0x21 which receive PT = 0x20 from the far-end shall revert to PT = 0x20 and operate in ODTUjk only mode. Refer to ITU-T G.798 for the specification.

As you can see from Table 1, if we receive an OPU4 signal in which the Payload Type (PT) = 0x07, then this means that this OPU4 signal is transporting a 100GBASE-R client signal. This is one example of how the PSI Message (which contains the PT byte) will inform us of the type of client signal(s) that are transporting via this OPU signal.

We will discuss OPU traffic, in which PT = 0x20 and 0x21 extensively in Lesson 5.

What is the CSF (Client Signal Fail) Bit-field?

As client circuitry (such as an Ethernet MAC) maps its traffic into an OTN signal (such as an OPU4 data-stream), it is expected to monitor the quality of the client signal it provides to the OPU Mapper.

If this client circuitry determines that there is a problem with the data (that it is providing to the OPU Mapper), then it is expected to assert the CSF (Client Signal Fail) bit-field.

The CSF bit-field will travel throughout the OTN (via the PSI Message, within the OPU data stream). This bit-field aims to alert the client circuitry (at the remote PTE) that the underlying client signal is corrupted or defective. In other words, CSF is a caution signal.

It’s like the Biohazard Sign I show in the Figure below.

CSF is like the Bioharzard Sign

Figure 11, A Warning Sign – Similar (in the role) to the CSF (Client Signal Fail) Bit-field.

You Can Also Check Out the OPU Training Video Below.

Click on the Link Below to See the ODU Training Video

Click on the Link Below to Return to the Main Lesson 2 Page.

For More Information/Resources about Lesson 2, Click on the Items Below.

The Forum

The Forum Page

The Best Darn OTN Training ... Period - Forum This page serves as a place-holder for the Forum. The Forum ...
Read More
Mistakes and Corrections to OTN Lesson 2 - OPU, ODU and OTU Framing

OTN – Lesson 2 – Mistakes/Corrections

OTN Lesson 2 - OPU, ODU and OTU Frame Training - Mistakes/Corrections This page identifies any mistakes and corrections to ...
Read More

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

Another post, we spoke about the PSI (Payload Structure Identifier) Message.

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 server 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.  And we can think of the ODUk server signal as the airplane (carrying many passengers).  

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 = 0x20, each MSI byte (or entry) represents 2.5Gbps of bandwidth.  

For PT = 0x21

  • If we’re working with an OPU2/ODU2 server signal, 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.  
  • For PT = 0x21, each MSI byte (or entry) represents 1.25Gbps of bandwidth.

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

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

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, that we are transporting via the OPU4/ODU4 server signal.  

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.  In this case, we are using this bandwidth to transport the individual ODUj tributary signal. 

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 is 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 (Coming Soon to this Blog)

  • 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 extensively cover Multiplexed Traffic and their resulting MSIs 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 the ODUk-AIS Signal?

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


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

What is the ODUk-AIS Maintenance signal?

AIS is an acronym for Alarm Indication Signal.

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

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

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

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

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

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

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

ODUk-AIS Pattern

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

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

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

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

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

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

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

OTUk Bit Rate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inflation’s Got You Down? With our Pricing, We Can Help with Inflation and Make You an OTN Expert!! Click on the Banner Below to Learn More!!!

Discounts Temporarily Available!!

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

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More

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/ODU4 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/ODU4 server 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/ODU4 server signal.

ITU-T G.709 states that whenever we map/multiplex some ODU0s into an OPU4/ODU4 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 tributary signals into an OPU4/ODU4 server 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 Format

We 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) can 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/ODU4 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/ODU4 server 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 tributary 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/ODU4 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 tributary signals?

Each ODU0 tributary signal (that we are mapping into an OPU4/ODU4 server 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 tributary 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/ODU4 server 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 tributary signals as they transition from the “ODU0 tributary signal 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 illustrates an ODU0 tributary signal 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 its ODU0 signal into an ODTU4.1 Data Signal.

ODU0 to OPU4 Mapper Circuit

Figure 4, Illustration of an ODU0 tributary signal 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.

To better appreciate these concepts, I strongly recommend you check out this portion of Lesson 5 within THE BEST DARN OTN TRAINING..PERIOD course.  

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

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