White Paper

Generic Mapping Procedure

Generic Mapping Procedure

Introduction
Recent enhancements to the OTN address the growing need to provide a transport layer for packet and
data oriented networks. These enhancements have included definition of new rates in the OTN hierarchy like
ODU0 for GbE and Fibre Channel-100, ODU2e for 10GbE and FC-1200, and ODU/OTU4 for 100GbE. In addition,
ODUflex has been introduced for transport of Constant Bit Rate (CBR) clients with rates above 2.5Gbit/s and for
GFP encapsulated packet flows.

These new additions have resulted in client/server mapping scenarios that require more rate adaptation
range than are addressed with the Asynchronous Mapping Procedure (AMP) or the Bit-synchronous Mapping
Procedure (BMP). As a consequence, the Generic Mapping Procedure (GMP) has been defined to provide
the ability to map any client signal into any server regardless of their rate differences, provided the server is
faster.

While similar in fundamental concepts to AMP, the specifics of GMP differ significantly in both its stuffing
algorithm and in its signalling. The mapping/multiplexing scenarios under which AMP or BMP were specified
remain unchanged, while GMP is specified for the many new scenarios that require greater adaptation
range.

Mapping and Multiplexing

In the OTN, an ODUk server may contain a single, non-OTN client or it may contain multiple lower rate ODUjs.
In the former case, a client is mapped into the entire server and in the latter the server payload is subdivided
into tributary slots, and each lower rate ODUj is mapped into a Tributary Unit, or ODTU, that occupies one or
more tributary slots. The ODTUs are then multiplexed into the higher rate ODUk. In both cases, the mapping
procedure used must address any granularity and rate differences.

Constant Bit Rate clients are transparently mapped into an ODUk and no explicit word delineation is required.
Consequently, sets of consecutive bits of the client are mapped based on the word size of the server. When
mapping lower rate ODUjs into ODTUs, however, sets of bytes of the ODUj are mapped into the same number
of bytes of the ODTU.

When a single client is mapped into an ODUk, two possibilities exist for rate adaptation. First, it is possible to
lock the server rate to the client rate such that no explicit adaptation is required. Second, the server rate can
be independent from the client rate requiring a mechanism that allows some server word locations to carry
either data or stuff as necessary. In the case of ODUj to ODUk multiplexing, the ODTU rates are derived from
the ODUk and so can not be locked to each individual ODUj. Thus, a rate adaptation mechanism is always
required.

Bit-synchronous Mapping Procedure

The simplest mapping mechanism involves no rate adaptation and can be used if the server rate is explicitly
derived from the client rate. This is the case for the BMP. When using BMP to map a client into ODUk, the
server granularity is always one byte. Consequently, 8 consecutive bits of the client are placed in each
payload byte of the server. Every server payload byte always carries client data.

2
 Generic Mapping Procedure

Asynchronous Mapping Procedure

As the name suggests, AMP is a mechanism that maps a client into a server when the two rates are
asynchronous or independent. In these scenarios, both the client and server have equivalent nominal bit
rates but each has some tolerance. As a result, it is possible for the client rate to be higher than the server
or the server rate to be higher than the client in any given instance. To accommodate this, AMP has both
negative and positive justification capabilities.

Figure 1 shows the details of CBR client mapping into OPUk (which is payload carrying portion of an ODUk
server) with AMP. With the exception of the Positive Justification Opportunity (PJO) byte at Row 4, Column 17,
and some fixed stuff columns in some cases, the entire OPUk Payload area is always populated with client
data. Then, on a frame by frame basis, the Negative Justification Opportunity (NJO) byte and the PJO byte
may or may not be populated depending on the relative bit rates of the client and the OPUk. The nominal
rate of the OPUk payload, including the PJO byte is equal to the nominal rate of the CBR client.

Column
Row 15 16 17 18 … 3824
1 RES JC1

2 RES JC2

3 RES JC3
Data
4 PSI NJO PJO

OPUk OH OPUk Payload

NJO/PJO
Data or Stuff Data/Stuff
Signalling
Figure 1: AMP Detail for CBR client to OPUk mapping

When the client rate is slower than the OPUk payload rate, the NJO byte will never carry data and the PJO
byte will periodically not carry data. When the client rate is greater than the OPUk payload rate, the PJO byte
will always carry data and the NJO byte will periodically carry data. In each frame, the least significant 2 bits
of the Justification Control bytes (JC1, 2, 3) indicate the usage of NJO and PJO for that frame.

It is also possible that the client and server are at exactly the same rate when using AMP. When this occurs,
the PJO byte will always carry data and the NJO byte will never carry data. This corresponds exactly to the
server payload usage with BMP mapping. To be compatible with AMP and to enable a single demapper
to be used for either procedure, the JC1/2/3 byte positions, while not required to signal anything in BMP, are
permanently set to the AMP values that signals data in PJO and stuff in NJO.

The use of NJO and PJO bytes accommodates a modest rate tolerance between the CBR client and the
ODUk server payload. For SDH clients, the rate tolerance is ±20ppm and the rate tolerance for the ODUk is
also ±20ppm which is within the justification range of AMP.

3
Generic Mapping Procedure

AMP is also used for lower rate ODUj to higher rate ODUk Multiplexing for some combinations of ODUj/k
(e.g. ODU1 into ODU2 or ODU3). In these cases, there are actually two PJO bytes due to the nominal rate
differences, but the purpose is still to manage a ±20ppm client into a ±20ppm server where the nominal rates
are very close.

Evolution of GMP
With the definition of ODU4 as the 100G server for 100GE and lower rate ODU clients, and ODUflex as an ‘any
rate’ client into servers greater than 10G, nominal client rates are no longer always close to that of their server.
In addition, new CBR clients that are not close to 1.25 or 2.5 Gbit/s like STM-4 and FC-200 have been defined
to be mapped into ODU0 and ODU1. These new characteristics require an adaptation mechanism with many
possible stuff bytes per server payload frame to accommodate both the rate differences and wider client bit
rate tolerances of up to ±100ppm for some new clients.

Two proposals were advanced within the ITU for a mapping procedure that would satisfy these requirements.
One was an adaptation of AMP and one was a new mechanism that utilizes a flexible data/ stuff distribution
algorithm.

The AMP based proposal built on the approach used for mapping STM-64 into OPU2 and STM-256 into OPU3
where fixed stuff columns are used to reduce the OPUk payload to a rate close to the client rate. To support
this for any possible client/server pair, the number and location of fixed stuff columns are determined based
on a simple algorithm. Then, the finer adaptation adjustments to accommodate bit rate tolerances are
managed with an AMP mechanism using up to 7 Justification Opportunity bytes. As with AMP, the use of
these bytes each frame are signalled in the JC1/2/3 bytes.

The other proposal took a different approach with the goal of achieving the best possible distribution of data
and stuff throughout the server frame. In this case, any payload word can be data or stuff depending on the
overall ratio of data to payload. A formula based on the current payload position, the total number of client
data words and the total number of payload words determines whether each payload position is populated
with client data or stuff. To perform this calculation at the demapper, the client data word count must be
signalled rather than just the usage of predefined justification locations.

The latter proposal, using a Sigma/Delta algorithm for data/stuff distribution, was ultimately adopted by the
ITU as the Generic Mapping Procedure due to its perceived flexibility and superior client jitter performance.

GMP Details
The formula governing the Sigma/Delta algorithm is as follows;

Content of each Payload position is

Data: if (Payload position x data byte count) mod (PServer) < data word count
Stuff: if (Payload position x data byte count) mod (PServer) ≥ data word count
PServer = total # of word positions in server frame payload
Payload word position = 1..PServer

In each case of mapping, PServer is always known and fixed. Similarly, the Payload position being evaluated
is also inherently known. The final variable, the data word count, changes from frame to frame to match the
rate of the client being mapped. For each frame, the appropriate count is determined by the mapper and
signalled in the OPUk overhead to the demapper using the JC1/2/3 bytes.

The count being signalled is 14 bits, to support the 15232 payload bytes in an OPUk frame, and spans both JC1
and JC2. To ensure robustness at the receiver in the presence of bit errors, JC3 contains a CRC-8 which allows

4
 Generic Mapping Procedure

error detection and certain amount of error correction. There is also an encoding for count increments or
decrements and a state machine at the receiver is used to manage the values received and protect against
bit errors. It is important to note that the demapper requires the count before the fi rst payload position
occurs, so it has to be determined and signalled in the previous frame.

Figure 2 shows an example of the data/stuff distribution achieved by the Sigma/Delta algorithm where the
word size is one byte. Over any continuous set of payload words, the ratio of data to stuff is the same as it is
over the entire frame.

Column
Row 15 16 17 18 … 3824

1 JC4 JC1 Stuff Data Stuff Data Data Stuff Data Stuff Data Stuff

2 JC5 JC2 Data Stuff Data Stuff Stuff Data Stuff Data Stuff Data

3 JC6 JC3 Data Stuff Data Stuff Stuff Data Stuff Data Stuff Data

4 PSI RES Stuff Data Stuff Data Data Stuff Data Stuff Data

Remainder
OPUk OH Data word count OPUk Payload
(for next frame)

Figure 2: Sigma/Delta based GMP

Also shown in this diagram is the usage of the OPUk overhead bytes. As mentioned, JC1/2/3 carries the count
of data words, which is actually for the next frame. In addition, to meet jitter requirements for some mappings,
an indication of the partial word remainder of client data not mapped is required. This is provided as another
count in JC4/5/6, but at a granularity less than the word size. For example, STM-4 is mapped into OPU0 with a
word size of 8 bits, so the count in JC1/2/3 is a byte count. Then, the granularity required for the remainder is 1
bit, so the remainder count in JC4/5/6 is a bit count in the range of 0 to 7.

The word size used for GMP is based on the server being used. The lowest granularity of 8 bits is used when
mapping a non-OTN client into a 1.25Gbit/s OPU0 or multiplexing an ODU0 into a single 1.25Gbit/s Tributary
Slot of a higher speed OPUk (k=2,3,4). For larger OPUk servers, the mapping granularity is essentially 8 bits per
1.25Gbit/s of server rate. When mapping 100GE into OPU4, a 640 bit granularity is used. This is intended to
align with wider data buses used in silicon for higher data rate solutions.

Conclusion
The recent enhancements to OTN to provide efficient data transport have outstripped the ability of AMP to
provide a suitably flexible mapping mechanism. AMP and BMP retain their existing roles, but GMP has been
introduced to handle the new combinations of client and server rates. With its ability to handle any client rate
into any server rate, GMP also promises to support clients and servers yet to be defined.

5
Generic Mapping Procedure

Notice

EXAR Corporation reserves the right to make changes to the products contained in this publication in order to improve design,
performance or reliability. EXAR Corporation assumes no responsibility for the use of any circuits described herein, conveys no license
under any patent or other right, and makes no representation that the circuits are free of patent infringement. Charts and schedules
contained here in are only for illustration purposes and may vary depending upon a user’s specific application. While the information in
this publication has been carefully checked; no responsibility, however, is assumed for inaccuracies.

EXAR Corporation does not recommend the use of any of its products in life support applications where the failure or malfunction of
the product can reasonably be expected to cause failure of the life support system or to significantly affect its safety or effectiveness.
Products are not authorized for use in such applications unless EXAR Corporation receives, in writing, assurances to its satisfaction that:
(a) the risk of injury or damage has been minimized; (b) the user assumes all such risks; (c) potential liability of EXAR Corporation is
adequately protected under the circumstances.

Copyright 2011 EXAR Corporation

White Paper: September 2011

Reproduction, in part or whole, without the prior written consent of EXAR Corporation is prohibited.