White Paper

ODUflex in Detail
Transporting Any Client Signal in the OTN
ODUflex in Detail: Transporting Any Client Signal in the OTN

Introduction
In the Optical Transport Network (OTN), the Optical Data Unit, or ODU, is the transport container defined to
carry client signals from network ingress to egress. The ODU provides a payload area for client data along
with overhead for performance monitoring and fault management. The payload area of an ODU may
contain a single non-OTN signal as a client or may contain multiple lower rate ODUs as clients.

Until the third version of G.709, released in December 2009 by the ITU, only a handful of ODU rates had
been defined to support the main non-OTN client signals like STM-16/64/256 and 1/10/100 Gigabit Ethernet,
and lower rate ODU to higher rate ODU multiplexing. Transport of many additional non-OTN clients such as
Fibre Channel and Video signals as well as variable rate packet flows had also been examined to ensure
the continuing effectiveness of the OTN in carrier networks. The existing ODU rates were not efficient to
transport these new clients, but it was also not desirable to define a new, fixed rate ODU type for each one.
Consequently, the concept of a flexible rate ODU, or ODUflex, was devised to fill in the gaps of the fixed rate
hierarchy and included in the third version of G.709.

In addition, when packet flows were considered as clients, the ability to resize the ODUflex container to adjust
to changes in traffic patterns was considered beneficial. To support this, a hitless rate adjustment protocol has
been defined to manage this change across an end-to-end network connection.

ODUflex (CBR) for Fixed Rate Client Transport

Most non-OTN client signals that are transported in the OTN are Constant Bit Rate (CBR) signals. A CBR signal
can be synchronously or asynchronously mapped into an ODUk depending on how the rate of the ODUk is
derived. For each fixed rate ODUk (k=0,1,2,2e,3,4 but not flex), Table 7-2 of G.709 specifies a nominal rate and
a frequency tolerance (±100ppm for ODU2e and ±20ppm for the rest). The same is true for any non-OTN client
signal that is to be transported in an ODUk. The ODUk rate generation can be controlled independently from
the client or, when both the ODUk and the client have the same nominal rates and tolerance (e.g. ODU1
and STM-16), it can be directly derived from the client. When the rates are independent an asynchronous
mapping is required involving the use of stuffing for adaptation of the client rate into the ODU payload. When
the ODU rate is derived from the client, no differences exist between the client rate and the ODU payload
rate so a synchronous mapping can be used where all available payload bytes of the ODU carry client data.
From a client clock jitter generation and suppression perspective, a synchronous mapping is preferred.

Figure 1 below shows the ODUk Frame Structure, which is 3824 columns by 4 rows. The fi rst 14 columns contain
the ODUk overhead and the next two columns contain the OPUk overhead. The remaining 3808 columns are
the payload area and they contain the client data and any necessary fixed stuff columns.

Column
Row 1 … 14 15 16 17 18 … 3824
1

2
OPUk
3
ODUk OH Payload Area
Overhead
4

16 columns 238x16 columns

Figure 1: ODUk Frame Structure

2
 ODUflex in Detail: Transporting Any Client Signal in the OTN

When mapping a CBR client into ODUflex, the Bit-synchronous Mapping Procedure, or BMP, is used and every
ODUflex payload byte carries 8 successive bits of client data (clients may or may not be byte oriented). Based
on the number of columns of ODU and OPU overhead and the number of payload columns, the ODUflex rate
is exactly equal to 239/238 x the client rate.

It is important to note that only CBR clients greater than 2.488Gbit/s are mapped into ODUflex (CBR) using
BMP. Clients less than 1.244Gbit/s are mapped into ODU0 using the Generic Mapping Procedure, or GMP, and
clients between 1.244Gbit/s and 2.488Gbit/s are mapped into ODU1 using GMP. Thus, ODUflex (CBR) can be
any rate greater than an ODU1.

ODUflex (GFP) for Packet Flow Transport

ODUflex is also defined to carry packet data flows encapsulated with Generic Framing Procedure, or GFP.
Typically, these would be Ethernet or MPLS packet flows, but any packet oriented data can be encapsulated
in GFP frames and mapped into an ODU. These packet flows do not have a constant bit rate, so it is not
practical to create an ODUflex (GFP) container rate directly based on the packet flow rate as is done for
ODUflex (CBR). Instead, the ODUflex (GFP) rates are multiples of approximately 1.25Gbit/s, to correspond to
the capacity of an integer number of higher order ODU Tributary Slots, and the packet flow is adapted to that
rate using GFP.

In this way, mapping of GFP frames into an ODUflex is exactly the same as mapping GFP frames into a fixed
rate ODUk (k = 0,1,2,2e,3,4). For a given ODUflex (GFP), the rate is established and the packet flow is rate
adapted into it using GFP. It is also possible to adjust the rate of an ODUflex (GFP) to address changes in traffic
profiles. Before, during and after this adjustment process, GFP always takes care of adapting the packet flow
rate into the available payload bandwidth of the ODUflex (GFP).

Transporting ODUflex in High Order ODUk

ODUflex (CBR) and ODUflex (GFP) are always multiplexed into a higher, fixed rate ODUk for transport in the
OTN. As with all cases of ODUj to ODUk multiplexing, the lower rate ODUj occupies some number of Tributary
Slots of the higher rate ODUk. For ODUflex multiplexing, the Tributary Slot granularity is always 1.25Gbit/s and
the mapping mechanism is GMP.

As indicated, an ODUflex (CBR) can be any rate greater than an ODU1 and it is always mapped into the
minimum number of Tributary Slots required for a given higher order ODUk. For example, Single Data Rate
Infiniband (IB SDR) has a nominal bit rate of 2.500Gbit/s and is mapped into an ODUflex (CBR) of 2.511 Gbit/s
(239/238*2.500Gbit/s). Since the Tributary Slot bandwidth of each ODUk is slightly different, this ODUflex
requires 3 Tributary Slots of either ODU2 or ODU3, but only requires 2 Tributary Slots of ODU4.

The rate of an ODUflex (GFP) is always defined to fit in an integer number of Tributary Slots of a higher rate
ODUk. The rate of an ODUflex (GFP) is determined by the lowest rate ODUk over which it can be transported.
For example, the rate of an ODUflex (GFP) that is to be mapped into 4 Tributary Slots (approximately 5Gbit/s)
is controlled to be slightly less than the capacity of 4 ODU2 Tributary Slots regardless of the rate of the initial
ODUk into which it is multiplexed (ie. ODU2,3 or 4). This ensures that the ODUflex (GFP) can be multiplexed into
an ODU2 at some point in the OTN if necessary.

Unlike an ODUflex (CBR), an ODUflex (GFP) is always multiplexed in the same number of Tributary Slots in all
higher rate ODUk. This restriction is in place to simplify ODUflex (GFP) resizing.

While the rate of an ODUflex (GFP) is set based on the rates of higher order Tributary Slots, it can be generated
from a reference that is completely independent from any higher rate ODUk reference. So, both ODUflex
(CBR) and ODUflex (GFP) are effectively asynchronous to the ODUk into which they are multiplexed.
Consequently, GMP must be used to map the ODUflex into the Tributary Slots of the ODUk. From this

3
ODUflex in Detail: Transporting Any Client Signal in the OTN

perspective, there is no processing difference when multiplexing either of the two types of ODUflex. The only
distinction occurs when ODUflex (GFP) resizing is supported.

ODUflex (GFP) Resizing

As mentioned, it is possible to change the rate of an ODUflex (GFP) in order to adapt to changes in traffic
patterns. While there is no explicit limit to how frequently an ODUflex (GFP) is resized, the motivation for
developing a resizing protocol was to address longer term changes that occur over a period of months or
years. Both an increase and a decrease in ODUflex (GFP) capacity is supported by the protocol, which is
referred to as Hitless Adjustment of ODUflex, or HAO, defined in the recently approved ITU Recommendation
G.7044.

To support a change in size of an end-to-end ODUflex (GFP), the number of Tributary Slots used in each node-
to-node link, as well as any switch matrix connections within nodes, must be adjusted. In the case of an
increase in bandwidth, new Tributary Slots must be allocated prior to the change in rate of the ODUflex (GFP).
In the case of a rate decrease, the ODUflex (GFP) must decrease in rate before the Tributary Slots are freed up.

Consequently, there are two aspects to the HAO protocol. One is the Link Connection Resize (LCR) and
the other is the Bandwidth Resize (BWR). Link Connection Resizing is triggered at each node by either the
management plane or the control plane. Both node-to-node and end-to-end handshaking concepts exist
ensuring that the number of Tributary Slots for the entire connection has been properly adjusted and that
the correct Tributary Slots are being utilized. Bandwidth Resizing is controlled by the source node in each
direction. The source node either increases or decreases the rate of the ODUflex (GFP), resulting in changes to
the GMP word count, and each intermediate node follows the incoming changes and adjusts the outgoing
mapping towards the next node.

OTU3
Router A P-OTS P-OTS Router B

20 Gbit/s (8 out of 32 TS) Î 40 Gbit/s (16 out of 32 TS)

Utilized Trib Slot Utilized Trib Slot

Spare Trib Slot SpareTrib Slot

ODU3 ODU3

Figure 2: ODUflex (GFP) Resizing

Figure 2 shows a simplified example of an increase in bandwidth between two routers supported by a change
in rate of the ODUflex that carries the packet data. Initially, the connection is 20Gbits/s and utilizes 8 Tributary
Slots of an OTU3 link. When the bandwidth requirement changes, 8 additional Tributary Slots are allocated to
the connection and the ODUflex (GFP) increases in bandwidth to fill the additional link capacity.

4
 ODUflex in Detail: Transporting Any Client Signal in the OTN

Comparison with Virtual Concatenation

In some ways, the benefits of the ODUflex are similar to those offered by Virtual Concatenation of OPUk in that
it is possible to transport a client signal at a rate that is not aligned to the fixed OPUk capacities. There are
some significant characteristics of ODUflex that distinguish it, however.

With Virtual Concatenation, the client signal is distributed among a number of individual OPU/ODUk
connections. These connections are functionally independent and can traverse the OTN in diverse paths,
which leads to two considerations. First, the relative network delay of each OPUk may be different and may
require realignment at the destination before the client can be demapped. Second, multiple ODUk must be
monitored to provide a view of the health of the end-to-end connection.

ODUflex by definition is a single container that can not be split across multiple fibre links or wavelengths.
Consequently, both the implementation and management of the ODUflex is considerably simpler than that of
a Virtual Concatenation Group.

On the other hand, resizing of a Virtual Concatenation Group involves only the end point of the group.
Intermediate nodes are simply provisioned to provide or tear down connectivity of member paths and
the Source and Sink nodes take care of adding or removing members. By contrast, the HAO protocol
involves participation of every node from ODUflex source to ODUflex sink. This can lead to more complex
interoperability testing and problem resolution.

Conclusion
The fixed rate ODUk that are defined within the OTN have provided efficient transport of the predominant
Constant Bite Rate clients such as SDH and 1/10GE. In order to continue to provide efficient transport for new
CBR clients and packet flows, the ODUflex is a necessary evolution in the definition of an ODUk.

ODUflex provides the ability to create a container that is appropriately sized for the data rate of the client. It
offers a single manageable entity across the OTN that can be a permanently fixed rate, in the case of ODUflex
(CBR), or can adjust to changing connectivity demands in the network, in the case of ODUflex (GFP).

With the definition of ODUflex, the OTN will transport the clients of tomorrow as efficiently as it transports the
clients of today.

5
ODUflex in Detail: Transporting Any Client Signal in the OTN

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: October 2011

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