Lesson 4 – Mapping a Non-OTN Client Signal into an OPU Signal using GMP

This post presents both the Training Video and Introductory Material for using the Generic Mapping Procedure (GMP) to map Non-OTN client data into an OPU data-stream.

OTN Lesson 4 – Mapping a Non-OTN Client Signal into an OPU Frame using the Generic Mapping Procedure (GMP)

This post includes a video that describes the GMP (Generic Mapping) Procedure – for mapping a Non-OTN client signal into an OTN signal (OPU frame).  

This video also describes how we use the various JC (Justification Control) fields within the OPU overhead to manage the mapping of Non-OTN client data into an OPU frame.  

Additionally, this video describes how we use these overhead fields to manage the de-mapping of this Non-OTN client data from an OPU frame.  

NOTE:  The roles of the JC fields are very different for GMP than for AMP and BMP.  

Continue reading “Lesson 4 – Mapping a Non-OTN Client Signal into an OPU Signal using GMP”

What is the PTE for OTN Applications?

This post defines and describes the Path and Path Terminating Equipment for OTN Applications.

What is Path Terminating Equipment (PTE) for OTN Applications?

Whenever we discuss the OTN Digital Layers (e.g., the OPUk, ODUk, and OTUk layers), we can group Networking Circuits and Equipment into two broad categories.

I will be using these terms throughout various OTN-related posts within this blog.  Thus, we must have a strong understanding of these terms.

I have devoted this blog post to discussing PTE (Path Terminating Equipment).

I have devoted another post to STE (Section Terminating Equipment).

You can also find a detailed discussion of PTEs and STEs within Lesson 3 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  This discussion also describes the differences between PTEs and STEs.

What is the Path?

Before we define the term Path Terminating Equipment (or PTE), we must first explain the word Path as it pertains to an Optical Transport Network (OTN).

For OTN applications, there are two different types of Paths.

  • A Non-OTN Client Signal Path (for Non-Multiplexed ODU traffic) and
  • An ODUk Server Signal Path (for Multiplexed ODU traffic)

We will define each of these types of Paths below.

Non-OTN Client Signal Path

When transporting a single non-OTN client signal (such as 100GBASE-R) over OTN (e.g., an ODU4/OTU4 signal in this case), the Path begins where the circuitry maps the 100GBASE-R signal into an OPU4 signal.

We can say that the 100GBASE-R signal officially enters the OTN at this point.

This Path ends at the location where the circuitry de-maps the 100GBASE-R signal from the OPU4 signal (and exits the OTN) at the other end of the network.

Figure 1 presents a simple illustration of an OTN that contains some Path Terminating Equipment and some STEs.

Difference between Section Termination Equipment and Path Terminating Equipment

Figure 1, Illustration of both PTE (Path Terminating Equipment) and STE (Section Terminating Equipment) within an Optical Transport Network

In Figure 1, we show that a Source PTE is mapping a 100GBASE-R signal into an OTU4 signal on the left-hand side of Figure 1.

The OTU4 signal transports this 100GBASE-R signal throughout this OTN and through various Section Terminating Equipment blocks labeled STE#1, STE#2, and STE#3.

Afterward, the OTU4 signal finally arrives at the Sink PTE on the right-hand side of Figure 1.

The Sink PTE then de-maps the 100GBASE-R signal from this OTU4 signal.

In the case of Figure 1, the Path (for the 100GBASE-R signal) is that portion of the OTN that exists between the Source PTE (on the left-hand side of Figure 1) and the Sink PTE (on the right-hand side of the same figure).

As this 100GBASE-R signal travels from the Source PTE to the Sink PTE, it will pass through multiple Sections and STEs (we describe in another post).  The Path is the route the 100GBASE-R signal takes (through the OTN, via the OTU4 signal).

A Closer Look at the Non-OTN Client SIGNAL Path

Now that we have a basic understanding of what a Path is, let’s take a much closer look at the Path.

Figure 2 presents a more detailed illustration of the Non-OTN Client Signal path within an OTN.  This figure also indicates where this Path begins and ends within the OTN.

100GbE/OTU4 Path - Path Terminating Equipment

Figure 2, A Closer Look at the Non-OTN Client Signal Path

Once again, Figure 2 shows that the Non-OTN Client Signal Path begins when we map the client signal into an OPU4 signal (and then an ODU4 and OTU4 signal).

In this case, we are mapping a 100GBASE-R client signal into an OPU4 signal at the OPU4 Mapper block.

This figure also shows that this same Path ends where we de-map that same client signal from the OPU4 signal (at the OPU4 De-Mapper block on the lower-right-hand side of Figure 2).

Please note that the diagram in Figure 2 is functionally equivalent to that in Figure 1.  In Figure 1, we referred to each signal (between the STE and PTE boxes) as OTU signals.  We did not discuss these signals at the OPU4 or ODU4 layers, as shown in Figure 2.

For more details on how we map a 100GBASE-R signal into an OPU4 (and ODU4) server signal, please see Lesson 4 within THE BEST DARN OTN TRAINING PERIOD!!

Let’s now move on to the other type of Path.

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

Corporate Discounts Available!!!

The ODUk Server Signal Path (for Multiplexed ODU Signals)

Another type of OTN Path is the ODUk Server Signal Path.

In the ODUk Server Signal Path, we can map and multiplex multiple lower-speed ODUj tributary signals into a Higher-Speed ODUk server signal (where k > j).

We describe the exact procedure for mapping/multiplexing lower-speed ODUj signals into a higher-speed ODUk signal in other posts.

Figure 3 illustrates a Unidirectional Network that contains both a Non-OTN Client Signal and the ODUk Server Signal set of paths.

1GbE to ODU0 to ODU4 - Path Terminating Equipment

Figure 3, A Closer Look at the ODUk Server Path

NOTE: We described the Non-OTN Client Signal path earlier in this post.  Hence, the reader should be familiar with this particular type of Path.

Handling the 1000BASE-X/OPU0/ODU0 Signals

In Figure 3, we have a 1000BASE-X (1GbE) signal that we first map into an OPU0 signal (in the Upper-Left-Hand corner of this figure).

We earlier stated that this point of mapping a non-OTN signal (such as a 1000BASE-X signal) into an OTN signal (e.g., an OPU0 in this case) is the beginning of the Non-OTN Client Signal Path.

Once we’ve mapped this signal into an OPU0, then we will also, in turn, map this OPU0 signal into an ODU0 signal.

Afterward, this ODU0 signal goes through some different processes (that we discuss in detail in other posts) before we map/multiplex this ODU0 tributary signal into an OPU4 signal.

Once we’ve mapped the ODU0 tributary signal (along with 79 other such signals) into an OPU4 signal, this point serves as the entry point for the ODU0 to OPU4/ODU4 Path.  We can also call this the ODUk Server Signal Path entry point.  

Figure 3 labeled this point as the ODU0 to OPU4 Path Demarcation Line.

This is where this OPU4 signal begins (and serves as the starting point for this particular Path).

Handing the OPU4/ODU4 Server Signal

We then quickly map this OPU4 signal into an ODU4 signal and then (eventually) into an OTU4 signal.

Afterward, we convert this OTU4 signal into an optical signal and transmit it through three additional sets of STEs before arriving at the XCVR and Optical I/F at the Remote Terminal (in the lower-left-hand corner of Figure 3).  

The remote terminal converts this signal back into the electrical format and terminates the OTU4 and ODU4 signals.

Finally, the circuitry routes the resulting OPU4 signal to the OPU4 De-Mapper block.  The OPU4 De-Mapper block then terminates this OPU4 signal.

This point serves as the OPU4 to the ODU0 Path Demarcation point.  This point is where this OPU4 signal (and its Path) ends.  We can also say that this is the end of the ODUk Server Signal Path.  

NOTE:  If you wish to learn more about how we map/multiplex lower speed ODUj tributary signals into an ODU4 Server signal, then you can check out Lesson 5 within THE BEST DARN OTN TRAINING PERIOD!!!

This circuitry will then de-map out the ODU0 tributary signal (of interest) along with as many as 79 other ODU0 tributary signals from this OPU4 signal.

Next, the ODU0 Terminator block will terminate this ODU0 signal and extract the OPU0 signal.

Afterward, it will transmit this data to the OPU0 De-Mapper block.

The OPU0 De-Mapper block will then de-map out the 1000BASE-X (1GbE) client signal from its incoming OPU0 signal.

Once the OPU0 De-Mapper block de-maps the 1000BASE-X signal from the OPU0 signal, this point serves as the Non-OTN Client Path Demarcation point.

In other words, this is the point at which this particular OPU0 signal (and its Path) ends.

How the PTE Operates in the Optical Transport Network

For OTN applications, the ODUk Layer is the protocol layer responsible for managing and monitoring the transmission/reception of data across a Path.

Path Termination Equipment will process data (in the electrical format) by doing many of the following functions:

In the Transmit Direction

  • Mapping data (either Non-OTN client data or lower-speed ODUj tributary data) into an OPUk signal and generating the new OPUk signal and overhead.
  • Generating the ODUk overhead or the ODUk-PMOH (Path Monitoring Overhead) and attaching the ODUk-PMOH to each outbound OPUk frame.
  • Sending this data downstream, the circuitry will either map this signal into another higher-speed ODUk signal or an OTUk frame and precondition it for transmission across the optical fiber.

NOTE:  Throughout many of the postings on this blog, we will refer to this ODUk overhead data as the ODUk-PMOH (ODUk-Path Monitoring Overhead) data.

In the Receive Direction

  • Receive ODUk data from the upstream OTUk Framer block
  • Process and Terminate the ODUk overhead (or ODUk-PMOH).  While the PTE is processing the ODUk-PMOH, it will check for the following errors and defects within the incoming ODUk signal.
    • Defects or Failures (e.g., dTIM, dPLM, dDEG, dAIS, dOCI, dLCK and PM-BDI)
    • Errors (e.g., PM-BIP-8, PM-BEI)
  • Terminate the OPUk data stream and de-map either the Non-Client OTN signal or some lower-speed ODUj tributary signals.
  • Route the de-mapped data downstream for further processing.

Mapping Data (either Non-OTN client data or lower-speed ODUj tributary data) into an OPUk/ODUk signal

Anytime the PTE maps data (be it non-OTN client data or lower-speed ODUj tributary signals) into an OPUk signal, it will do so by using some of the following mapping procedures.

As the PTE uses one of these mapping procedures to load client data into the OPUk payload, it will load its mapping parameters into the OPUk overhead.

The PTE will also alert the network of the type of traffic that it is transmitting via this OPUk signal by sending the appropriate PSI message via the PSI byte.

Please see the relevant posts for more information on this functionality.

Generating the ODUk Overhead (ODUk-PMOH)

As the PTE receives an OPUk data stream from upstream circuitry, it will precondition all this data for transport through the Path by computing and attaching the ODUk overhead fields to each outbound OPUk frame.

In particular, the PTE will attach some ODUk-PMOH fields to the OPUk frame, which will help it to detect errors and declare and clear certain defect conditions.

Other ODUk overhead fields support maintenance/monitoring features such as Tandem Connection Monitoring, the transport of APS (Automatic Protection Switching) Commands, and other forms of Equipment to Equipment (non-client related) commands and information.

In other posts, we will discuss these topics (e.g., Tandem Connection Monitoring and the APS Channel).

The critical thing to note at this point is that the PTE will use the ODUk-PMOH to monitor the overall health of the entire Path (from the point where it creates the ODUk signal to the end where it terminates this signal).

Figure 4 presents an illustration of the ODUk Overhead that the PTE will use to support the monitoring of this signal as it travels through the Path.  NOTE:  The ODUk-PMOH is the orange PM field within Figure 4.  We will discuss the PMOH in another post.  

ODU Frame with ODU Overhead Shown

Figure 4, ODUk Overhead, PMOH, and Payload fields

NOTE:  Please see the ODUk Frame post for more information on the ODUk frames and the PMOH fields.

Terminating the OPUk Overhead

After the OTUk signal has been converted into the optical format, received, and converted back into the electrical domain (by the remote terminal), the remote terminal will terminate the OTUk signal (because this equipment is an STE).

Once the STE has terminated OTUk-SMOH, it will route the resulting ODUk signal towards downstream circuitry for further processing.

At this point, the PTE will proceed to terminate the ODUk-PMOH.

As the PTE performs this task, it will check the ODUk-PMOH for the occurrence of bit errors and defects.

The PTE will report the occurrences of such errors and defects to System Management.

Additionally, the PTE will remove all ODUk-PMOH data from this incoming stream (which leaves us with just an OPUk data stream now).

This OPUk data stream is then routed to a De-Mapper block for further processing.

Important Takeaway

The critical takeaway is that the PTE will rely on the ODUk-PMOH data (as shown in Figure 4) to process, manage, and ultimately terminate the ODUk stream.

NOTE:  Each ODUk signal (whether it is a lower-speed ODUj tributary signal that we map/multiplex into a higher-speed ODUk server signal) or an ODUk signal (that is carrying a single Non-OTN client signal) will have its ODUk-PMOH data.

This means that PTE (whether it is for transporting a single Non-OTN client signal or one of many lower-speed ODUj signals) will manage and monitor its own respective ODU signal.

I have redrawn Figure 2 to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the Non-OTN Client Path (of 100GBASE-R over OPU4/ODU4).  

I have included this figure below in Figure 5.

100GbE to OTU4 PTE w/ ODU4-PMOH

Figure 5, Illustration of the 100GbE to ODU4 Path.  (The Entire ODU4 Path is shaded).  

NOTE:  I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (Non-OTN Client ODU4).

This also means that the circuitry (shown above in Figure 3) would require as many as 81 sets of PTE.

  • 80 sets of PTE would be required to monitor each of the 80 ODU0 signals (that we are transporting via the OPU4/ODU4 signal), and
  • One additional PTE would be required to monitor the more significant ODU4 signal.

I have also redrawn Figure 3 to show where the circuitry generates and terminates/monitors the ODU0-PMOH within the Non-OTN Client Path (of 1000BASE-X over OPU0/ODU0).  

I have included this figure below in Figure 6.

1GbE to ODU0 to ODU4 - ODU0 SMOH Termination

Figure 6, Illustration of the 1GbE to ODU0 -> ODU4 Path.  (The entire ODU0 Path is shaded).

NOTE:  In Figure 6I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU0-PMOH (Non-OTN Client ODU0).  

Finally, I have redrawn Figure 3 (again) to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the ODU0 mapped/multiplexed into OPU4/ODU4 Path.   

I have included this figure below in Figure 7.

1GbE to ODU4 with ODU4-PMOH

Figure 7, Illustration of the 1GbE to ODU0 -> ODU4 Path.   (The Entire ODU4 Path is shaded).

NOTE:  I have highlighted the Locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (ODU0 Mapped/Multiplexed into OPU4/ODU4).

De-Mapping the Client Signal from the OPUk Payload

Once the OPUk has reached the De-Mapper block, the De-Mapper block will de-map out the client data (be it non-OTN client data or lower-speed ODUj tributary signals) using the mapping parameters that the Source PTE loaded into the OPUk overhead bytes (when it was mapping these clients into the OPUk signal).

This point will be the “end of the line’ for the OPUk frame and overhead.

This circuitry will send the client data downstream for further processing (either by non-OTN system-side circuitry, such as a MAC or other PTE circuitry to handle the lower speed ODUj signals).

Examples of PTE

  • Line Cards or Transceivers take (for instance) 100GBASE-R data from a MAC and transport this data over an OTU4 connection (and vice-versa).
  • Any equipment that performs ODUj switching and grooming
  • ROADMs.

Some Final Comments about the ODUk-PMOH and PTE Equipment.

This post introduced the concept of a Path, Path Terminating Equipment (PTE), and the ODUk-PMOH (Path Monitoring Overhead).

In another post, I describe the Section, Section Terminating Equipment (STE), and the OTUk-SMOH (Section Monitoring Overhead).

STEs will use the OTUk-Layer to manage the data transmission across Sections.

STEs will only generate and process OTUk-SMOH data.  They do not process ODUk-PMOH data AT ALL.

Likewise, PTEs will use the ODUk-Layer to manage data transmission across a Path.

PTEs will only generate and process ODUk-PMOH data.  They do not process OTUk-SMOH data AT ALL.  In most cases, the PTE will not even see the OTUk-SMOH data.

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

The AMP (Asynchronous Mapping Procedure)

This post discusses and describes the AMP (Asynchronous Mapping Procedure) that one can use to map client signals into OTN signals and transport them through the Optical Transport Network (OTN).

What is the AMP (Asynchronous Mapping Procedure)?

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

ITU-T G.709 also states that the system designer can use AMP to map lower-speed ODUj tributary signals into a higher-speed OPUk server signal.  We will discuss that topic in another post.

NOTE:  Whenever ITU-T G.709 discusses procedures for mapping a CBR client signal into an OPUk/ODUk signal, it will often refer to the OPUk/ODUk signal as the Server signal.  We will use the terms OPUk/ODUk and Server interchangeably throughout the rest 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.

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

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

What is the Asynchronous Mapping Procedure?

The name Asynchronous Mapping Procedure means that the timing relationship between the client signal (being mapped into an OPUk payload) and the bit-rate of the OPUk payload are close in frequency but still asynchronous.

This timing relationship is different from that for the BMP (Bit-Synchronous Mapping Procedure).

In BMP, the timing relationship between the Client Signal and the Server signal must be synchronized.  For AMP, we can say (in a “tongue-in-cheek manner”) that the timing relationship between the Client Signal and the Server signal is “close, but no cigar”!!  I’ll explain that comment below.

The System Designer must ensure that ALL the following is true before they can use the Asynchronous Mapping Procedure to map a non-OTN client signal into the OPUk payload.

  • The Client signal clock frequency must be within ±65pm of the OPUk Payload clock frequency.
  • The System-Designer must handle Rate differences (between the Client and the Server signal) via fixed and variable stuffing.
  • This ±65ppm tolerance accounts for the maximum variable stuffing (justification) limits.

How AMP Works

We begin our discussion of AMP by looking at the OPUk Overhead bytes.

In Figure 1, I illustrate the OPUk Frame (within the OTUk Frame).

OTUk Frame with OPUk Portion shown

Figure 1, Illustration of the OPUk Frame – within the OTUk Frame.

In Figure 2, I take a closer look at the OPUk frame structure and show a more detailed drawing of the OPUk Overhead Bytes within the OPUk Frame.

AMP Discussion - Basic Figure - Introduction of OPUk OH

Figure 2, Illustration of the OPUk Overhead Bytes – for AMP Applications

This figure shows five (5) Overhead Bytes that play a role in AMP.

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

Figure 2 also shows the bit format for the three Justification Control Bytes.  This figure shows that Bits 1 through 6 (within each of these 3 bytes) are labeled RES (Reserved) and do not have a role in AMP.

This figure also shows Bits 7 and 8 (within these 3 bytes), which we have labeled JC7 and JC8, do have a role in AMP.

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

Discount Available for a Short Time!!!

Justification Events within an OPU Frame

We earlier stated that if the System Designer wishes to use AMP to map a non-OTN client signal into an OPUk frame, then they must make sure that the frequency differences between the client signal and that for the OPUk payload are within ±65ppm.

Since there is no requirement to phase-lock the OPUk Payload frequency to the client signal frequency (as ITU-T G.709 requires for BMP applications), it is unlikely that these two signals will be at the same rate.  

They will, most likely, be close (in frequency) to each other but off in one direction or the other.

In this case, the Source (OTN) Path Terminating Equipment (PTE) will generate many of its OPUk frames with no justification events.  But, because these two signal frequencies will typically not be identical, the Source PTE will eventually generate OPUk frames with justification events.  We sometimes call these justification events slip events in other forms of data communication.

NOTE:  These justification events are also similar to the pointer justification events in SONET/SDH Networks.

The Source PTE will use these Justification Events to compensate for the frequency differences between the Client and the server signal.  

Please see the post on “slip events” to understand the mechanics of slip events (e.g., why they occur and how we can elegantly handle them).

A Source PTE can generate three (3) types of OPUk frames in AMP.

  • OPUk frames with NO Justification Events (e.g., The Nominal Condition)
  • OPUk frames with Negative-Justification events (occurs periodically if the Client Bit Rate > OPUk Bit Rate)
  • OPUk frames with Positive-Justification events (appears regularly, if the Client Bit Rate < OPUk Bit Rate)

We will discuss each of these types of OPUk frames below.

The Normal Situation – The Source PTE creates an OPUk Frame with No Justification Activities.

Many of the OPUk frames that a Source PTE generates will belong to this category for AMP applications.

Figure 3 shows a drawing of an OPUk Frame, with NO Justification events occurring.

OPUk Frame - AMP Discussion - No Justification Event

 

Figure 3, An Illustration of an OPUk Frame with NO Justification events occurring

This figure shows that this OPUk frame does NOT have a Justification Event by:

  • Setting at least two (out of the three) sets of JC7 and JC8 bit-fields to [0, 0] as shown above.
  • The PJO byte field is currently carrying a client data byte (as it usually does) – in this OPUk frame.
  • The NJO byte field is NOT transporting a client data byte but is (instead) carrying a stuff byte (which is also a nominal condition).

The settings within the JC7 and JC8 bit-fields alert the Sink PTE (at the other end of the network) that there is no justification event occurring within this OPUk frame and:

  • That the PJO byte-field is currently carrying client data, and
  • The NJO byte field is transporting a stuff-byte (and is NOT transporting client data).

NOTE:  If (by design or accident) the OPUk payload rate is equivalent to the Client bit-rate, then the Source PTE will ALWAYS generate these types of OPUk frames (e.g., with NO Justification Events). 

If the System Designer has achieved this synchronous relationship (between the OPUk and the Client signal) by design, this becomes Bit-Synchronous Mapping (BMP).

Negative Stuff Event (Occurs if the Client Bit Rate > OPUk Bit Rate)

If the Client-data bit rate is slightly faster than that for the OPUk payload rate, then (with no intervention) the Mapper Buffer will eventually fill up.

AMP uses Negative-Stuffing (or Negative Justification) to prevent the Mapper buffer from Overflowing.  

In this case, the Source PTE will (temporarily) increase our Server (OPUk) signal’s bandwidth (to pull additional data out of the Mapper Buffer) by forcing both the PJO and the NJO bytes to carry client data momentarily.

Hence, for systems in which the Client data bit rate is faster than the OPUk payload bit rate, the Source PTE will periodically need to generate OPUk frames with Negative Justification to keep the Mapper Buffer from filling up.

Figure 4 shows a drawing of such an OPUk frame.

OPUk AMP Discussion - Negative Justification

 

Figure 4, Illustration of an OPUk Frame with Negative Justification occurring

This figure shows that this OPUk frame has a Negative Justification Event by setting at least two (of the three) sets of JC7 and JC8 bits to [0, 1], as I show above.  

The Source PTE will also (for this particular OPUk frame) use both the NJO and the PJO byte fields to carry client data bytes.

When the Source PTE sets the JC7 and JC8 bit-fields to these values, it notifies the Sink PTE (at the remote end of the network) of the roles of the NJO and PJO bytes within this OPUk frame.

NOTES:

  1. For the NO Justification OPUk frames, the NJO byte is considered part of the OPUk Overhead and usually does not transport any client data.  For Negative Justification OPUk frames, the NJO byte will (for this OPUk frame) be carrying client data.
  2. If the Client-data bit rate is faster than the OPUk Payload rate, then the PJO byte will ALWAYS carry client data (in every OPUk frame).  In this case, we will sometimes use the NJO byte to transport client data (within OPUk frames with justification events).

Positive Stuff Event (Occurs if the Client Bit Rate < OPUk Bit Rate)

If the Client-data bit-rate is slightly slower than that for the OPUk Payload rate, then (with no intervention) the Mapper Buffer will eventually be depleted.

AMP uses Positive-Stuffing (or Positive Justification) to avoid depleting the Mapper buffer.  

In this case, the Source PTE will temporarily reduce the Server signal’s (e.g., the OPUk signal) bandwidth (for this OPUk frame) by forcing both the PJO and the NJO bytes to transport stuff (and NOT client) data.

Hence, for designs in which the Client data bit rate is slower than the OPUk payload, the Source PTE will periodically generate OPUk frames with Positive Justification to avoid depleting the Mapper Buffer.

NOTE:  For the NO Justification OPUk Frames, the PJO byte field will be carrying client data.  But, during Positive Justification frames, the PJO byte will transport a stuff (or dummy) byte instead.  In other words, the Positive Justification OPUk frame will not carry client data within the PJO byte-field. 

This action momentarily slows the rate at which the Server pulls data out of the Mapper Buffer and keeps the buffer from depleting.

Figure 5 shows a drawing of an OPUk frame with Positive Justification occurring.

OPUK Frame - AMP Discussion - Positive Justification Frame

 

Figure 5, Illustration of an OPUk Frame with Positive Justification occurring

This figure shows that this OPUk frame has a Positive Justification event by setting at least two (of the three) sets of JC7 and JC8 bits to “[1, 1].

When the Source PTE sets the JC7 and JC8 bit-fields to these values, it notifies the Sink PTE (at the remote end of the network) of the roles of the NJO and PJO bytes within this OPUk frame.

NOTE:  If the Client data rate is slower than the OPUk Payload rate, then the NJO byte will ALWAYS function as a stuff byte (e.g., never carrying client data), and the PJO will sometimes function as a stuff byte (during OPUk frames with justification events).

Interpreting the JC7 and JC8 Bits

Table 1 summarizes how to understand the JC7 and JC8 bits (within two out of the three Justification Bytes) and the corresponding roles for the NJO and PJO bytes within the OPUk Frame.

Table 1, How to Interpret the Settings of the JC7 and JC8 bits within Two (of the Three) Justification Bytes, and the corresponding roles for the NJO and PJO bytes within the OPU Frame – When Transporting a Non-OTN Client Signal

Relationship between JC7 and JC8 bits and the Justification of OPUk

AMP and De-Mapping Jitter

AMP poses some challenges for the System Designer’s efforts to control de-mapping jitter to meet system requirements.  BMP offers the best de-mapping jitter of the three recommended Mapping Procedures.  

However, AMP imposes all of the following contributions (and challenges) to meeting de-mapping jitter requirements.

  • The presence of OTUk/ODUk/OPUk overhead bytes within the OTN signal (this challenge exists for BMP as well)
  • Fixed-byte stuffing – while mapping the client signal into the OPUk frame (this challenge exists for BMP as well)
  • Justification Events, also known as variable-stuffing, are unique to AMP.

Each Justification Event imposes 8UI-pp of mapping-related jitter within the client signal.

The System Designer will need to implement some clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.

If the System Designer is transporting SONET/SDH data (which has very stringent jitter requirements) through the OTN, we recommend using BMP instead of AMP.  Otherwise, the designer will have to implement some very robust jitter attenuation solutions (at the Sink PTE) when de-mapping this client signal from the OPUk frame.

ITU-T G.709 Recommendations on Using AMP

Table 2 presents a list of the Non-OTN Client signals that ITU-T G.709 recommends using AMP when mapping these signals into each OPUk/ODUk Structures.

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

ITU-T G.709 Recommendations for AMP - Asynchronous Mapping Procedure

Can we use AMP for all OPUk rates?

We can use AMP for the OPU1, OPU2, and OPU3 server signals.  However, we cannot use AMP for mapping client signals into an OPU0 or OPU4 server signal.

ITU-T G.709 recommends using GMP to map client signals into OPU0 and OPU4 signals.

Summary

Table 3 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODUk clock) that the System Designer must follow before using any ITU-T G.709 Recommended Mapping Procedures.  Please note that I have highlighted the AMP items (within Table 3) with a “Red Rectangular” outline.

Table 3, Mapping Procedure Timing Requirements

ITU-T G.709 Requirements to use AMP - Asynchronous Mapping Procedure

 

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

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