What is the RDI (Remote Defect Indicator)?

This post presents a generic definition of the term: RDI (Remote Defect Indicator) signal. It also describes how and when Network Equipment will transmit this type of signal.


What is the RDI (Remote Defect Indicator) Signal?

What does RDI Mean?

RDI is an acronym for Remote Defect Indicator.

Where is the RDI Signal Used?

RDI is a particular type of alarm signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (back towards upstream Network Equipment) anytime it detects a servicing-affect defect within the signal from that same upstream Network Equipment.

Stated differently, the Network Element (NE) will transmit the RDI indicator (upstream) at the same time (and under the same conditions) that it will send the AIS signal downstream.

For example:  If an NE were to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal, then it will respond to this defect condition by transmitting the RDI signal (back) upstream towards the source of the defective signal.

Whenever the Network Element transmits this RDI signal upstream, it is notifying the upstream NE that there are problems with its data.

What EXACTLY is an RDI Signal?

The method that we use to transmit the RDI signal depends upon the telecom/datacom standard and network layer that we are using.

However, in most cases, the Network Element will transmit the RDI signal by setting a certain overhead bit-field (within the signal that it is transmitting back to the remote or upstream NE) to “1”.

The Network Element will continue to set this bit-field to “1”, within each frame of data (that it is transmitting back to the remote NE) for as long that it is declaring the defect within its incoming data stream.

Likewise, the Network Element will stop sending the RDI signal by clearing that same overhead bit-field to “0”.

For OTN applications, we call the RDI signal the BDI (or Backward Defect Indicator) signal.

I have included posts that describe the BDI signal for both the OTUk and ODUk frames.

For example, SONET Line-Terminating Equipment will transmit the RDI-L indicator, and SONET Path-Terminating Equipment will send the RDI-P indicator.

In the case of PDH signals (e.g., T1/E1 or T3/E3), we call the RDI signal by other synonymous names such as FERF (Far-End Receive Failure) or the “Yellow Alarm.”

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

Discounts Available for a Short Time!!!

When do we transmit the RDI Signal?

We will go through a couple of examples to illustrate how and when we will transmit the RDI signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a simple illustration of a portion of a 3R Repeater/Regenerator, which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West, and E – East)
  • Two (2) Transmit Line Interface blocks (W – West, and E – East)
  • Two (2) Transmit Framer blocks (W – West, and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator)
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West and E – East)

In this figure, our 3R Repeater/Regenerator is receiving a good (error-free) signal from the West Terminal.

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

If the Receive Line Interface (W) and Receive Framer (W) blocks were to detect no problems within this signal. The 3R Repeater/Regenerator would allow this signal to pass through both the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

The Receive Line Interface (W) and the Receive Framer (W) blocks would also do nothing to impact the data, that the Near-End Transmitter circuitry (e.g., the Transmit Line Interface (W) and Transmit Framer (W) blocks) is transmitting, back out to the West Terminal.

Figure 1 presents an illustration of this Normal (No Defect) Condition.

3R Repeater/Regenerator during Normal Conditions

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1, to focus our discussion on this Defect Declaration to RDI Generation mechanism, on the West-side of the 3R Repeater/Regenerator circuit.

Now, let’s discuss the case where we will transmit the RDI indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another simple illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that this signal was severed by a backhoe or some other mishap.

Nonetheless, this means that our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

In this case, the 3R Repeater/Regenerator will respond by doing all the following:

  • The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.
  • The Transmit Framer (E) and the Transmit Line Interface (E) (which sit directly behind the Receive Line Interface and Framer blocks – that are declaring the dLOS condition) will now transmit the AIS indicator (to the East Terminal) as we discussed in the AIS post of this blog.
  • Additionally, the Receive Line Interface (W) and/or the Receiver Framer (W) blocks will also command its “near-end” transmitting circuitry [e.g., the Transmit Framer (W) and Transmit Line Interface (W) blocks] to start sending the RDI signal, back out to the West Terminal.

Figure 2 presents an illustration of the dLOS/RDI Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator when transmitting RDI

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition

The Transmit Framer (W) and Transmit Line Interface (W) blocks will send the RDI indicator to the West Terminal for as long as the Receive Line Interface (W) and the Receive Framer (W) blocks are declaring the dLOS defect with the signal that they are receiving from the West Terminal.

The Transmit Framer (W) and Transmit Line Interface (W) blocks will stop sending the RDI indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and starts to receive good/normal data from the West Terminal.

In addition to the dLOS defect, the Network Element will transmit the RDI Indicator (upstream) in response to any other service-affecting defects, such as:

  • dLOF
  • dLOFLOM
  • dPLM
  • dTIM

Why do we bother to transmit the RDI Signal?

The main reason that we send the RDI signal (back to upstream equipment) in response to service-affecting defects is to alert that NE that there is a service-affecting defect, within its output signal between its location and that of the next downstream NE.

This notification aids in troubleshooting and system debugging of fault conditions in the network.

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

What is AIS (Alarm Indication Signal)?

This post defines and describes the AIS (Alarm Indication Signal). It also describes how and when Network Equipment will transmit this type of signal.


What is an AIS (Alarm Indication Signal)?

What does the term AIS Mean?

AIS is an acronym for Alarm Indication Signal.

Where is the AIS Signal Used?

The AIS signal is a particular type of alarm (or maintenance) signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (in its downstream path) anytime it detects some sort of service-affecting defect upstream.

For example:

If a Network Element (NE) were to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal, then it will respond to this defect condition by transmitting the AIS signal downstream.

Whenever the Network Element transmits this AIS signal downstream, it is (in effect) replacing its defective incoming signal with the AIS signal.

What EXACTLY is an AIS signal?

The exact pattern/signature of an AIS signal depends upon the telecom/datacom standard and network layer that we are using.

For some datacom/telecom standards, the AIS signal is transmitted (and received) as an Unframed All One’s pattern.

In other standards, we will transmit the AIS indicator as a Framed All One’s pattern (e.g., where the framing alignment fields are still using normal values, but the payload fields are filled with an All One’s pattern).

Finally, the OTUk AIS pattern is an Unframed PN-11 (PRBS11) pattern.

In all cases, the NE will generate and transmit the AIS signal at the nominal line-rate (of the normally transmitted signal).

The frequency accuracy requirements for this AIS signal also depends on the governing standards for the Telecom/Datacom system.

I have included posts that define the AIS patterns for both the OTUk and ODUk types of signals (for OTN applications).

When do we transmit the AIS pattern?

We will go through a couple of examples to illustrate how and when we will transmit the AIS signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a straightforward illustration of a portion of a 3R Repeater/Regenerator, which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West, and E – East)
  • Two (2) Transmit Line Interface blocks (W – West, and E – East)
  • Two (2) Transmit Framer blocks (W – West, and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator).
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West, and E – East)

In this figure, our 3R Repeater/Regenerator is receiving a good (error-free) signal from the “West Terminal.”

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

If the Receive Line Interface (W) and the Receive Framer (W) blocks were to detect no problems within this signal, then the 3R Repeater/Regenerator will allow this signal to pass through both the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

Our 3R Repeater/Regenerator will then transmit this same data to the East Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the outbound data (towards the East Terminal) based upon the Recovered Clock signal (which originated from the West Terminal and has been routed through the Clock Smoothing PLL for Jitter Attenuation purposes).

Figure 1 presents an illustration of this Normal (No Defect) Condition.

Portion of 3R Repeater/Regenerator during Normal Operation

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1, so that we can focus our discussion on this Defect Declaration to AIS Generation mechanism, in the West-to-East Terminal Path.

Now we will illustrate the case where we will transmit the AIS indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another very simple illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that this signal was severed by a backhoe or some other mishap.

Nonetheless, this means that our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

This also means that our 3R Repeater/Regenerator has no data to send to the East Terminal.

In this situation, our 3R Repeater/Regenerator will respond by doing all of the following things.

The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) (which resides directly behind the Receiving Line Interface and Framer blocks – that are declaring the dLOS condition) will proceed to transmit the AIS indicator (to the East Terminal) as a replacement signal for the signal that we are no longer receiving from the West Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the AIS pattern (towards the East Terminal) based upon the output frequency of the AIS Oscillator (which is a stand-alone oscillator – that operates at the specified line-rate/clock frequency).

Figure 2 presents an illustration of the dLOS/AIS Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator declaring dLOS and transmitting AIS

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will continue to transmit the AIS indicator to the East Terminal for the duration that the Receive Line Interface (W) and the Receive Framer (W) blocks are declaring the dLOS defect with the signal that they are receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will cease to transmit the AIS indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and start to receive good/normal data from the West Terminal.

At this point, the Transmit Framer (E) and Transmit Line Interface (E) blocks will then proceed to transmit good/normal data to the East Terminal.

In addition to the dLOS defect, the Network Element will typically transmit the AIS indicator (downstream) in response to any of the following other defects.

  • dLOF (Loss of Frame Defect)
  • dLOM (Loss of Multi-Frame Defect)
  • dLOFLANE (Loss of Frame of Logical Lane) – for OTL3.4 or OTL4.4 applications (*)
  • dLOL (Loss of Lane Alignment) – for OTL3.4 or  OTL4.4 applications (*)
  • dTIM (Trail Trace Identifier Mismatch)

(*) – Need to be a member of the THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  to access these links.

Why do we bother to transmit the AIS signal as a replacement signal?

There are several reasons why we transmit the AIS indicator downstream in response to service-affecting defects.

I will list some of those reasons below.

  • Alerts downstream equipment that we have detected and declared a service-affect defect, upstream.
  • To suppress (or prevent) the downstream equipment from declaring their own service-affecting defect.
  • Aids in troubleshooting and system debugging.  It is a lot easier to isolate the causes of defect conditions if we know exactly which NE is declaring the defect and not the whole chain of NEs downstream.
  • Provides the downstream Receive Circuitry with a much-needed clock signal at the correct bit-rate.  Clock Recovery PLLs (Phase-Locked-Loops) and Bias Controllers (for Optical Receive circuitry) all need for upstream NEs to provide them with a line signal with the appropriate timing (bit-rate).

The AIS signal accomplishes these goals.

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!

Discount Available Temporarily

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 on how to map 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 other 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 the case of 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 he/she 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 both 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 taking a look at the OPUk Overhead bytes.

Figure 1 presents an illustration of the OPUk Frame (within the OTUk Frame).

OTUk Frame with OPUk Portion shown

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

Figure 2 takes a closer look at the OPUk frame structure and shows 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

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 breaks out and shows the bit format for each of the three Justification Control Bytes.  This figure shows that Bits 1 through 6 (within each of these 3 bytes), are labeled as RES (Reserved) and do not have a role in AMP.

But, 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.

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!!! 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 he/she 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 of 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 have to 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 that can occur 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 these events).

In AMP, a Source PTE can generate three (3) different types of OPUk frames.

  • 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 (occurs 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

For AMP applications, many of the OPUk frames, that a Source PTE generates, will belong to this category.

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 we show 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 alerts 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
  • That 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, then 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 illustrated above.  

The Source PTE will also (for this particular OPUk) 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 is notifying 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 to be a part of the OPUk Overhead and usually does not transport any client data.  But, 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 instead, transport a stuff (or dummy) byte.  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 is pulling data out of the Mapper Buffer, and keeps the buffer from being depleted.

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 is notifying 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 settings of 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 any 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, which are also known as variable-stuffing, is 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, then we recommend that they use 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 lists out the Non-OTN Client signals that ITU-T G.709 recommends using AMP when mapping these signals into each of the 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 that we use GMP for mapping 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 of the 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

 

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! 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 PSI – Payload Structure Identifier Byte

This post describes the role of the PSI (Payload Structure Identifier) byte, within the OPUk Overhead, is used within the OTN.

What is the PSI – Payload Structure Identifier (Byte and Message)?

The PSI Byte

The PSI (or Payload Structure Identifier) byte is an Overhead byte within the OPUk structure.

Figure 1 presents an illustration of an OPU frame, with the location of the PSI byte identified.

Generic OPU Frame with PSI Byte Highlighted

Figure 1, Illustration of an OPUk Frame Structure with the Overhead Bytes (along with the PSI Byte) Identified  

The purpose of the PSI byte is to permit an OTN Path Terminating Equipment (PTE) to transport a 256-byte PSI (payload structure identifier) message throughout the OTN (Optical Transport Network).

The primary purpose of this 256-byte PSI Message is to permit the Source PTE to alert the OTN (Network) of the type of data (or traffic) that we are transporting within this particular OPU data-stream.

Since each OPUk frame contains only 1 PSI byte, an OTN PTE will have to transmit 256 consecutive OPU frames to transmit this PSI message completely.

The OTN PTE will align its transmission of this 256 byte PSI message with the MFAS byte.

Please see the post on the OTUk Frame Structure for more information on the MFAS byte.

In other words, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x00”, then the OTN PTE will also be transmitting the first byte of the PSI message (e.g., PSI[0]) via the PSI byte-field.

Likewise, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x01”, then the OTN PTE will also be transmitting the second byte within this 256-byte message (e.g., PSI[1]) via the PSI byte field, and so on.

Two Types of PSI Messages

An OTN Source PTE will transport one of two types of PSI Messages.

  • The Non-Multiplexed Traffic – PSI Message, and
  • The Multiplexed Traffic – PSI Message.

I will describe each of these types of PSI Messages below.  

The Non-Multiplexed Traffic PSI Message

We will use the Non-Multiplexed Traffic PSI Message, whenever we are transporting Non-Multiplexed Traffic within our OPU data-stream.

Examples of Non-Multiplexed Traffic would be:

  • Transporting 1000BASE-X via an OPU0 signal
  • 10GBASE-R via an OPU2e signal.
  • 100GBASE-R via an OPU4 Signal.

In other words, we are handling Non-Multiplexed Traffic whenever we are only transporting a single Non-OTN client signal via this OPUk data-stream.  

I present an illustration of an OPU Frame, with the PSI field highlighted (along with a break-out of the Non-Multiplexed Traffic type of PSI Message), below in Figure 2.

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

Figure 2, Illustration of an OPU Frame, transporting the Non-Multiplexed traffic of PSI Message

NOTE:  The easiest way to tell if you’re working with the Non-Multiplexed Traffic type of PSI Message, is to check and see if you see the CSF (Client Signal Fail) bit-field in PSI Byte # 2.

If the CSF bit-field is present, then you’re dealing with the Non-Multiplexed Traffic type of PSI Message.

If the CSF bit-field is NOT present (within the PSI Message), then you are dealing with the other-type of PSI Message.

The Multiplexed Traffic Type of PSI Message

We use the Multiplexed Traffic type of PSI Message anytime we are working with an OPU server signal that is transporting numerous lower-speed ODUj Tributary Signals.

For example, if we mapped and multiplexed 80 ODU0 tributary signals into an OPU4 server signal, then this OPU4 signal would transport the Multiplexed Traffic type of PSI Message.

Figure 3 presents an illustration of an OPU Frame, with the PSI field highlighted, along with a break-out of the Multiplexed Type of PSI Message.

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

Figure 3, Illustration of an OPU Frame transporting the Multiplexed Traffic Type of PSI Message

Again, one big difference between the Multiplexed Traffic type of PSI Message, and that for Non-Multiplexed Traffic is that the Multiplexed Traffic type of PSI Message will not have the CSF (Client Signal Fail) bit-field.

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

Discounts Available for a Short Time!!!

The PSI Message

The PSI (Payload Structure Identifier) message is a 256-byte message that an OTN terminal will transport via the PSI byte, over the course of 256 consecutive OPUk/ODUk/OTUk frames.

Let’s talk a little bit about the data that we are transporting within these PSI Messages.  

PSI[0] – or PSI Byte # 0 – PT (Payload Type)

The first byte of the PSI Message (e.g., PSI[0]) carries the Payload Type (or PT) value.  The PT byte identifies the type of client data that the OPUk structure is transporting via its payload.  

Table 1 presents a list of standard PT values along with the corresponding client data types (being transported within the OPUk Structure).

Table 1a, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part I

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1b, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part II

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1c, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part III

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1d, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part IV

PT - Payload Type - PSI Byte - Client Signal into OPUk

Other posts contain detailed information on how ITU-T G.709 recommends that the System Designer map each of these client signals into their corresponding OPUk structure.

Click HERE for more information about the PT = 0x21 Method for Mapping/Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.

The Remaining Bytes within the PSI Message

PSI bytes 1 and 3 through 255 are for “Mapping and Concatenation Specific” roles that we will discuss in another post. 

In Multiplexed-Traffic Type of PSI Messages

In the Multiplexed-Traffic type of PSI Message, we use these bytes to transport MSI (Multiplex Structure Identifier) information throughout the OTN.  

In other words, we will transport the MSI information (via these PSI Messages) for applications in which we are mapping/multiplexing lower-speed ODUj tributary signals into higher-speed OPUk/ODUk server signals.

The purpose of the MSI is to identify these lower-speed ODUj tributary signals, that we are transporting via this OPUk/ODUk signal, to the OTN.  

You can think of the MSI as a passenger-list or manifest, of lower-speed ODUj tributary signals riding along (or being transported) within this OPUk server signal.  

In Non-Multiplexed-Traffic Type of PSI Messages

PSI byte 2, Bit 1 (for the Non-Multiplexed Traffic PSI Message) is the CSF (or Client Signal Fail) indicator.  The ITU-T Standards Committee has reserved PSI Byte 2, Bits 2 through 8 for “future standardization.”

We discuss the CSF indicator and the MSI information in other posts.

We also discuss both of these types of PSI Messages, extensively within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!.  

You can click on the Banner below to learn more our this training package.

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!!  Click on the Banner Below to Learn More.

Discounts Available for a Short Time ONLY!!

For More Information on OTN-related Posts in this Blog, click on the image below

OTN Related Blog

OTN Related Topics within this Blog

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

The BMP (Bit-Synchronous Mapping Procedure)

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


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

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

NOTE:  Whenever ITU-T G.709 discusses procedures on how to map 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 bit-rate of the OPUk payload.

In other words, the System Designer must ensure that ALL the following conditions are true before he/she 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 handled any 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 that we list 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 any 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 some sort of 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 of the 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

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! 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 are some Mapping Procedures that We Can Use to Map a Non-OTN Client Signal into an OTN Signal?

This post briefly reviews each of the standard procedures 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 of these types of client signals (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 that we show in the figure below.

Mapping Client Signals into OPUk/ODUk/OTUk Frames

Whenever we map a client signal into an OTN signal, we are mapping 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 types of mapping schemes that 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 their form of rate-adaptation (e.g., adapting the rate of the client signal 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 compared to 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 that has a slightly faster nominal bit-rate than that for the OPUk payload, provided that we do not violate the above-mentioned 65ppm requirement.
  • The OTN terminal can accommodate 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.  Through these justification actions, we are either insert stuff-bytes into or removing stuff bytes from the OPUk payload like 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, for us to use GMP.  
    • For example, ITU-T G.709 recommends that we use 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 considerable 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

Stuck at Home? You Can Be an Expert of OTN Before You Return to Your Office!! 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