Tag: BMP

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

Lesson 4 – Mapping Non-OTN Client Signals into an OPU Signal using BMP or AMP

This post introduces Video Training for using AMP and BMP to mapping Non-OTN Client Signals into an OPU Data-Stream.

OTN Lesson 4 – Mapping Non-OTN Client Signals into an OPU Frame, using BMP or AMP

This blog post presents a video discussing the BMP (Bit-Synchronous Mapping) and AMP (Asynchronous Mapping) Procedures in detail.  

This video describes the conditions and circumstances in which you would choose one mapping procedure over another.  

This video also describes how we use some of the OPU overhead fields to manage the mapping of Non-OTN payload data into an OPU frame and how we use these overhead fields to control the de-mapping of that same Non-OTN payload from an OPU frame.  

Continue reading “Lesson 4 – Mapping Non-OTN Client Signals into an OPU Signal using BMP or AMP”

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

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