I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T G.709.1/Y.1331.1
TELECOMMUNICATION (01/2017)
STANDARDIZATION SECTOR
OF ITU

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Digital terminal equipments – General
SERIES Y: GLOBAL INFORMATION
INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS,
NEXT-GENERATION NETWORKS, INTERNET OF
THINGS AND SMART CITIES
Internet protocol aspects – Transport

Flexible OTN short-reach interface

Recommendation ITU-T G.709.1/Y.1331.1

 ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER- G.200–G.299
TRANSMISSION SYSTEMS
INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.300–G.399
SYSTEMS ON METALLIC LINES
GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS G.400–G.449
ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC
LINES
COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499
TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600–G.699
DIGITAL TERMINAL EQUIPMENTS G.700–G.799
General G.700–G.709
Coding of voice and audio signals G.710–G.729
Principal characteristics of primary multiplex equipment G.730–G.739
Principal characteristics of second order multiplex equipment G.740–G.749
Principal characteristics of higher order multiplex equipment G.750–G.759
Principal characteristics of transcoder and digital multiplication equipment G.760–G.769
Operations, administration and maintenance features of transmission equipment G.770–G.779
Principal characteristics of multiplexing equipment for the synchronous digital hierarchy G.780–G.789
Other terminal equipment G.790–G.799
DIGITAL NETWORKS G.800–G.899
DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999
MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER- G.1000–G.1999
RELATED ASPECTS
TRANSMISSION MEDIA CHARACTERISTICS G.6000–G.6999
DATA OVER TRANSPORT – GENERIC ASPECTS G.7000–G.7999
PACKET OVER TRANSPORT ASPECTS G.8000–G.8999
ACCESS NETWORKS G.9000–G.9999

For further details, please refer to the list of ITU-T Recommendations.

 Recommendation ITU-T G.709.1/Y.1331.1

Flexible OTN short-reach interface

Summary
Recommendation ITU-T G.709.1/Y.1331.1 specifies functions associated with the n x 100 Gbit/s
FlexO Group interface application. The intent is to keep it separate from the main ITU-T G.709 text.

History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.709.1/Y.1331.1 2017-01-12 15 11.1002/1000/13082

Keywords
B100G, FlexO, Flex OTN, IrDI, KP4 FEC, SR or short reach.

* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/1
1830-en.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) i

 FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes
the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.

NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve
the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or
applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of
the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected
by patents, which may be required to implement this Recommendation. However, implementers are cautioned
that this may not represent the latest information and are therefore strongly urged to consult the TSB patent
database at http://www.itu.int/ITU-T/ipr/.

 ITU 2017
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.

ii Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Table of Contents
Page
1 Scope............................................................................................................................. 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 2
3.1 Terms defined elsewhere ................................................................................ 2
3.2 Terms defined in this Recommendation ......................................................... 2
4 Abbreviations and acronyms ........................................................................................ 2
5 Conventions .................................................................................................................. 3
6 Introduction and applications ....................................................................................... 4
6.1 FlexO considerations ...................................................................................... 4
6.2 Sample applications ........................................................................................ 4
7 Structure and processes................................................................................................. 5
7.1 Basic signal structure ...................................................................................... 6
7.2 Process flow.................................................................................................... 6
8 FlexO frame .................................................................................................................. 6
8.1 Frame structure ............................................................................................... 7
8.2 Multi-frame structure...................................................................................... 7
8.3 Bit rates ........................................................................................................... 8
8.4 FEC ................................................................................................................. 8
9 Alignment markers and overhead ................................................................................. 9
9.1 Lane alignment markers (AM) ....................................................................... 9
9.2 Overhead description ...................................................................................... 11
10 OTUCn mapping .......................................................................................................... 16
10.1 Dividing and combining OTUCn ................................................................... 16
10.2 FlexO frame payload ...................................................................................... 17
10.3 Mapping of OTUC into FlexO frame ............................................................. 17
10.4 FlexO group alignment and deskewing .......................................................... 18
10.5 Scrambling ...................................................................................................... 18
11 FOIC interface .............................................................................................................. 19
11.1 FOIC1.4 interface ........................................................................................... 19
Bibliography............................................................................................................................. 21

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) iii

Recommendation ITU-T G.709.1/Y.1331.1

Flexible OTN short-reach interface

1 Scope
This Recommendation specifies a flexible interoperable short-reach OTN interface, over which an
OTUCn (n ≥ 1) is transferred, using bonded interfaces. The FlexO interfaces are covered by
application codes which are at the time of publication 4I1-9D1F, 4L1-9C1F, C4S1-9D1F and
4L1-9D1F in [ITU-T G.695] and [ITU-T G.959.1]. A FlexO group interface complements the existing
functions specified in [ITU-T G.709], such as B100G OTUCn frame, ODUk/flex, with new functions
such as physical interface bonding, group management and OTUCn (de)mapping. The intent of the
FlexO Recommendation is to capture links to existing [ITU-T G.709]/[ITU-T G.798] functions and
to provide specifications for new functions that are applicable to FlexO groups. In addition, some
introduction material for the addressed application is included.

2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published. The reference to a document within this
Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T G.695] Recommendation ITU-T G.695 (2015), Optical interfaces for coarse
wavelength division multiplexing applications.
[ITU-T G.709] Recommendation ITU-T G.709/Y.1331 (2016), Interfaces for the optical
transport network.
[ITU-T G.798] Recommendation ITU-T G.798 (2012), Characteristics of optical transport
network hierarchy equipment functional blocks.
[ITU-T G.870] Recommendation ITU-T G.870/Y.1352 (2016), Terms and definitions for
optical transport networks (OTN).
[ITU-T G.872] Recommendation ITU-T G.872 (2017), Terms and definitions for optical
transport networks.
[ITU-T G.959.1] Recommendation ITU-T G.959.1 (2016), Optical transport network physical
layer interfaces.
[ITU-T G.7041] Recommendation ITU-T G.7041/Y.1303 (2016), Generic framing procedure
(GFP).
[ITU-T G.8260] Recommendation ITU-T G.8260 (2015), Definitions and terminology for
synchronization in packet networks.
[IEEE 802.3] IEEE Std. 802.3:2015, IEEE Standard for Information Technology –
Telecommunications and Information Exchange Between Systems – Local and
Metropolitan Area Networks – Specific Requirements Part 3: Carrier Sense
Multiple Access With Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications.
[OIF FlexE IA] Optical Interworking Forum, OIF (2016), FlexEthernet Implementation
Agreement.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 1

3 Definitions

3.1 Terms defined elsewhere

This Recommendation uses the following term defined elsewhere:
3.1.1 Terms defined in [ITU-T G.870]
– completely standardized OTUCn (OTUCn)
– optical data unit (ODUCn)
– optical payload unit (OPUCn)
– optical transport network (OTN)

3.2 Terms defined in this Recommendation

This Recommendation defines the following terms:
3.2.1 FlexO frame: Consists of frame alignment (markers), OH, FEC and payload area.
3.2.2 FlexO lane: Refers to an electrical/optical lane of a FlexO interface, used to carry OTUC
transport signals.
3.2.3 FlexO interface: Refers to an individual interface that is part of a FlexO group. The acronym
used for FlexO interface is FOICx.k. The term Cx signifies the FlexO interface rate. The term k refers
to the number of lanes in the interface.
NOTE – The terms member and PHY are often used to refer to a FlexO interface.
3.2.4 FlexO group: Refers to the group of m * FlexO interfaces.

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
AM Alignment Marker
B100G Beyond 100G
BMP Bit-synchronous Mapping Procedure
CAUI (Chip to) 100 Gb/s Attachment Unit Interface
CM Common Marker
CRC Cyclic Redundancy Check
FA Frame Alignment
FAS Frame Alignment Signal
FCC FlexO Communications Channel
FEC Forward Error Correction
FlexE Flexible Ethernet
FlexO Flexible Optical Transport Network
FOIC FlexO Interface
GFP Generic Framing Procedure
GID Group Identification
IA Implementation Agreement
LSB Least Significant Bit

2 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

MAP PHY Map field
MFAS Multi-Frame Alignment Signal
MS Multiplexed Section
MSB Most Significant Bit
NNI Network Node Interface
ODU Optical Data Unit
OH Overhead
OPU Optical Payload Unit
OSMC OTN synchronization messaging channel
OTL Optical Transport Lane
OTLk.n Group of n Optical Transport Lanes that carry one OTUk
OTLC.n Group of n Optical Transport Lanes that carry one OTUC of an OTUCn
OTN Optical Transport Network
OTU Optical Transport Unit
PCS Physical Coding Sublayer
PHY Physical Layer
PID Physical Identification
PTP Precise Timing Protocol
RES Reserved for future international standardization
RPF Remote Physical Layer Fault
RS Regeneration Section
RS Reed-Solomon
SM Section Monitoring
SSM Source Sync Message
STAT Status
UM Unique Marker
UP Unique Padding

5 Conventions
This Recommendation uses the following conventions defined in [ITU-T G.870]:
– k
– Cn
– m
– n
– r
Transmission order: The order of transmission of information in all the diagrams in this
Recommendation is first from left to right and then from top to bottom. Within each byte the most

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 3

significant bit is transmitted first. The most significant bit (bit 1) is illustrated on the left side of all
diagrams.
Value of reserved bit(s): The value of an overhead bit, which is reserved for future international
standardization, shall be set to "0''.
Value of non-sourced bit(s): Unless stated otherwise, any non-sourced bits shall be set to "0".

6 Introduction and applications

A FlexO (Flexible OTN) group is defined for interoperable interfacing applications. It complements
B100G (beyond 100G) [ITU-T G.709] Edition 5, by providing an interoperable interface for OTUCn
transport signals. The FlexO group interface provides modularity by bonding standard-rate interfaces
(e.g., m * 100G), over which the OTUCn (n ≥ 1) signal is adapted. The value of m is not standardized.
The specification of OTUCn in [ITU-T G.709] excludes interface specific functions such as FEC,
scrambling, and bit alignment. The FlexO interface wraps OTUCn, abstracting the transport signal
from the interface. FlexO enables ODUflex services >100Gbit/s to be supported across multiple
interfaces, ahead of next-gen interface standards (e.g., 400GE [b-IEEE 802.3bs]).
FlexO provides OTN interfaces with comparable functionality as to what was introduced in
[OIF FlexE IA] for Ethernet interfaces.

6.1 FlexO considerations

The considerations and capabilities for a FlexO group:
– provides an interoperable system interface for OTUCn transport signals;
– enables higher capacity ODUflex and OTUCn, by means of bonding m standard-rate
interfaces;
– provides interface rate modularity and flexibility;
– provides a frame, alignment, deskew, group management, management communication
channel, and such functions that are not associated with the OTUCn transport signal; and
– reuses 100G modules (e.g., CFP2, QSFP28) by matching the interface rate to OTU4 as
specified in [ITU-T G.709]
The FlexO interface is specified in this recommendation at the external reference point. The logical
signal format FOIC can be reused on a system internal interface. These requirements and the
optimizations to the FlexO groups (e.g., lower latency by removing FEC) are beyond the scope of
this recommendation and covered in [b-ITU-T G-Sup.58].

6.2 Sample applications

FlexO group interfaces can be used for a variety of applications. Example applications for a FlexO
interoperable interface are shown in Figure 6-1 and Figure 6-2. An interoperable interface might
represent an OTN handoff between router (R) and transport (T) nodes, or could be a handoff between
different administrative domains.

4 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Figure 6-1 – Example FlexO handoff router-transport

The R-T topology is used in Figure 6-1, to draw an analogy between FlexO and FlexE use cases
presented in [OIF FlexE IA]. The ODUk/flex (which can be a rate higher than 100Gbit/s) is the
transport service (path) and maintenance entity in the OTN transport/switch network. The
ODUCn/OTUCn is the section and FlexO provides the interfacing capabilities (e.g., FEC, bonding
and scrambling).

Figure 6-2 – Example FlexO inter-domain handoff

The example of Figure 6-2 shows a FlexO inter-domain interface used as a handoff between two OTN
switch/transport administrative domains (A and B). The administrative domains can represent
different carriers, different equipment vendors within a carrier or different segments (metro vs core)
within a carrier. The OTUCn is the regen section (RS), the ODUCn is the multiplexed section (MS)
and the m*OTUC is the FlexO group bonded using m*100G FlexO interfaces.

7 Structure and processes

This clause introduces the functions associated with a FlexO group and the basic signal structure,
processes and atomic functions.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 5

7.1 Basic signal structure
The FlexO group interface in this recommendation is only specified for short-reach applications. The
FlexO group functional model is specified in [ITU-T G.872]. The physical optical interface
specifications are beyond the scope of this recommendation.
The information structure for FlexO groups is represented by information containment relationships
and flows. The principal information containment relationship is described in Figure 7-1.

Figure 7-1  FlexO group principal information containment relationship

7.2 Process flow

Functions and process flows are specified in [ITU-T G.798].

8 FlexO frame
A FlexO frame is associated with a FlexO interface and is independent of an OTUCn frame and
transport unit, the latter being specified in [ITU-T G.709]. The OTUCn is the transport unit over OTN
interfaces. A FlexO frame consists of frame alignment (markers), OH, FEC and payload area.
The FlexO frames in the different interfaces of a FlexO group are frame/multi-frame aligned at the
source.

6 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

8.1 Frame structure
The frame structure is shown in Figure 8-1 and consists of 128 rows by 5,440 1-bit columns. It
contains a frame alignment marker area in row 1, columns 1 to 960, an overhead area in row 1 columns
961 to 1280, a FEC area in columns 5,141 to 5,440 in every row and a (128 × 5140 – 1280 = 656640
bit) payload area in the remainder of the frame. The FlexO frame period results is ~6.2us.
Each row constitutes a 5,440-bit FEC codeword, with the last 300 bits used for the FEC parity bits.
This results in a bit-oriented structure. The MSB in each FEC codeword is bit 1, the LSB is bit 5,440.
NOTE – The FlexO frame structure is derived from 100Gbit/s Ethernet clause 91 [IEEE 802.3-2015]
FEC alignment and lane architecture, without any 66b alignment or 256b/257b transcoding functions.

Figure 8-1  FlexO frame structure

8.2 Multi-frame structure

In order to pad the payload area and provide additional OH field locations, an 8-frame multi-frame
structure is defined. The multi-frame structure is shown in Figure 8-2. It uses the three least significant
bits of the multi-frame alignment signal (MFAS) overhead to identify the eight frames within the
multi-frame.
The multi-frame contains seven fixed stuff locations, each containing 1,280 bits. These fixed-stuff
locations are distributed in row 65, columns 1 to 1,280 of the first seven frames within the multi-
frame. The last frame within the multi-frame does not contain fixed stuff.
The fixed stuff bits are filled with all-0s and not checked at the receiver sink function.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 7

 Figure 8-2  FlexO multi-frame structure

8.3 Bit rates

The FlexO frame payload consists of 5,244,160 bits (655,520 bytes) out of the total 5,570,560 bits
(696,320 bytes) per FlexO multi-frame.
FlexO_rate = 256/241 × OTUC_rate
= 256/241 × 239/226 × 99,532,800 kbit/s ±20 ppm
NOTE – The resulting 100G FlexO bit rate is within a -4.46 ppm offset of the OTU4 nominal bit rate.

8.4 FEC
FlexO FEC codewords occupy a row in the FlexO frame. The FlexO frame allocates 300 bits for FEC
parity, per row as shown in Figure 8-1. The FEC scheme employs Reed-Solomon code operating over
the Galois Field GF(210), where the symbol size is 10 bits.
Reed-Solomon code is denoted as RS(n,k) where k represents the number of message symbols to
generate 2t parity symbols, which are appended to the message. The resulting formula is n=k+2t
n=544
k=514
t=15

8 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

The FEC encoder processes 20 * 257-bit data blocks, resulting in the 5140 data bits in the FEC
codeword (row), and generates 20 * 15 = 300 bits of FEC parity.
NOTE – The FlexO FEC is based on RS10 (544, 514), as specified in clause 91 of [IEEE 802.3-2015] for
100GBASE-KP4 interfaces.

9 Alignment markers and overhead

The FlexO AM and OH areas consist of 1,280 bits, and are part of the FlexO frame structure. It
includes information to support group management and alignment functions. The FlexO AM and OH
is terminated where the FlexO frame is assembled and disassembled.
An overview of FlexO AM and OH areas is presented in Figure 9-1.

Figure 9-1  Overhead overview

9.1 Lane alignment markers (AM)

Lane alignment markers are used for lane alignment, lane delineation, lane ordering and lane
deskewing.
The AM area length for a FlexO frame is defined as 960 bits, which is a place holder for up to eight
120-bit lane alignment markers.
A lane alignment marker in Figure 9-2 consists of a common portion across all lanes, a unique portion
per lane and some pad bits.
– CMx = 8-bit common marker field (common across lanes) – used for aligning lanes
– UMx = 8-bit unique marker field – used for identifying lanes
– UPx = 8-bit unique pad field – used for providing a DC balance when multiplexing lanes
NOTE – Alignment marker area length specified by clause 91 [IEEE 802.3-2015] for 100 Gbit/s Ethernet
interfaces, is 1285-bit per AM FEC frame period (every 4096 FEC codewords). It consists of 20 AM blocks
of 64-bit, plus 5-bit extra padding required for 257b block alignment. Since the FlexO adaptation method
described in this document does not rely on 257b blocks, the five padding bits are unnecessary.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 9

 Figure 9-2  FlexO lane alignment marker format
9.1.1 100G interface alignment markers
The 100G FlexO interface consists of four logical lanes, numbered 0, 1, 2 and 3. Each lane carries a
120-bit lane alignment marker (ami, i = 0,1,2,3) as specified in Table 9-1 plus 120 pad bits
(padi, i=0,1,2,3) that have a value of all-0s prior to scrambling. Rows of Table 9-1 give the values of
ami transmitted over lane i.
The 960-bit 100G FlexO alignment marker area contains 10-bit interleaved parts of am0, am1, am2,
am3, pad0, pad1, pad2 and pad3 as illustrated in Figure 9-3. The first 480 bits contain the 10-bit
interleaved parts of am0 to am3 in the order am0, am1, am2, am3, am0, am1, etc. The second 480 bits
contain the 10-bit interleaved parts of pad0 to pad3 in the order pad0, pad1, pad2, pad3, pad0, pad1,
etc.

Figure 9-3  100G FlexO alignment marker area with four interleaved lane alignment
markers and padding

Table 9-1  100G FlexO lane alignment marker values

lane Encoding
{CM0, CM1, CM2, UP0, CM3, CM4, CM5, UP1, UM0, UM1, UM2, UP2, UM3, UM4,
UM5}
0 59 52 64 6D A6 AD 9B 9B 80 8E CF 64 7F 71 30
1 59 52 64 20 A6 AD 9B E6 5A 7B 7E 19 A5 84 81
2 59 52 64 62 A6 AD 9B 7F 7C CF 6A 80 83 30 95
3 59 52 64 5A A6 AD 9B 21 61 01 0B DE 9E FE F4
NOTE – The value in each byte of this table is in MSB-first transmission order. Note that this per-byte bit
ordering is the reverse of AM values found in [b-IEEE 802.bs], which uses an LSB-first bit transmission
format.

10 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

9.2 Overhead description
The FlexO OH area is contained in the 320 bits following the FlexO frame AM area. The OH structure
amounts to 2,560 bits (320 bytes) and is distributed across an 8-frame multi-frame, as shown in
Figure 9-4. Each frame contains 40 OH bytes.

Figure 9-4  FlexO OH structure

The FlexO OH area contains the following subfields (see Figure 9-4):
 multi-frame alignment signal (MFAS)
 status (STAT)
 group identification (GID)
 PHY identification (PID)
 PHY map (MAP)
 OTUC availability (AVAIL)
 cyclic redundancy check (CRC)
 FlexO management communication channel (FCC)
 bits reserved for future international standardization (RES)
 OTN synchronisation message channel (OSMC)
9.2.1 Multi-frame alignment signal (MFAS)
An 8-bit (1 byte) multi-frame alignment signal field is provided and incremented in every frame. This
MFAS field counts 0x00 to 0xFF and provides a 256-frame multi-frame. This central multi-frame is
used to lock 2-frame, 4-frame, 8-frame, 16-frame, 32-frame, etc. multi-frame structures of overhead
and payload structure to the principal frame.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 11

 Figure 9-5  Multi-frame alignment signal overhead

The MFAS field is located in all frames, in overhead byte 1 immediately following the AM.
9.2.2 Group identification (GID)
A 20-bit (2.5 bytes) FlexO Group Identification field is provided to indicate the FlexO Group instance
that the FlexO interface is a member of. The GID provides the ability to check at the receive side that
the FlexO interface belongs to the intended FlexO group instance.
The GID field is located in frame 1, in overhead bytes 3, 4 and 5.
The same FlexO Group Identification value is used in both directions of transport.
Non-zero values for GID are valid and the value of "0" is reserved for this field.
A FlexO interface that is not part of any group has its GID value set to "0".
9.2.3 PHY identification (PID)
A FlexO group is composed of m FlexO interfaces, also referred to as members or PHYs. An 8-bit
(1 byte) field is provided to uniquely identify each member of a group and the order of each member
in the group. This information is required in the reordering process.
The PID values of the interfaces in a FlexO group are not necessarily arranged consecutively. The
PID values indicate the order of the interfaces within the FlexO group, from low to high. The first
FlexO interface in the group is the one with the lowest PID value.
The PID field is located in frame 1, in overhead byte 6. The values ''0'' and ''255'' are reserved for this
field.
The same FlexO PHY Identification value is used in both directions of transport.
A FlexO interface that is not part of any group has its PID value default to "0".
9.2.4 PHY map (MAP)
A 256-bit (8 bytes) field is provided to indicate the members belonging to the group. Each bit in the
field, is set to ''1'' indicating a member/PHY is part of the group. The bit position of the MAP
corresponds to the PID set for the member FlexO interface, with the MSB corresponding to lowest
numbered PID. The remaining unused fields in the MAP are set to ''0''. The full MAP is sent and
received on all members of the group.
The MAP field is located in all frames, in overhead bytes 7, 8, 9 and 10. As shown in Figure 9-6, the
MSB of overhead byte 7 in frame 1 is associated with PID #0 and the LSB of overhead byte 10 in
frame 8 is associated with PID #255.

12 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Figure 9-6  FlexO PHY MAP field
9.2.5 Status (STAT)
An 8-bit (1 byte) field is provided for general purpose status indication.
– Remote PHY Fault
– Reserved

Figure 9-7  FlexO OH STAT field

The STAT field is located in all frames, in overhead byte 2.

9.2.5.1 Remote PHY fault (RPF)
For section monitoring, a single bit remote PHY fault (RPF) indication to convey the signal fail status
detected at the remote FlexO sink function in the upstream direction.
RPF is set to ''1'' to indicate a remote PHY defect indication; otherwise, it is set to ''0''.
The RPF field is located in bit 1 of the STAT field as shown in Figure 9-7.
9.2.5.2 Reserved (RES)
Seven bits of the STAT byte are reserved for future international standardization as shown in
Figure 9-7. These bits are set to "0".
9.2.6 OTUC availability (AVAIL)
An 8-bit (1 byte) OTUC availability field is provided to indicate the number of valid and available
OTUC slices mapped to the FlexO frame. A 100G FlexO frame has a valid count of 0 or 1. This
functionality is further specified in clause 10.1.
The AVAIL field is located in frame 2, in overhead byte 3.
9.2.7 Cyclic redundancy check (CRC)
The CRC-16 (2 bytes) is located in overhead bytes 11 and 12 of each FlexO frame. The CRC protects
the integrity of the OH fields in bytes 2 to 10 and excludes the MFAS, OSMC and FCC fields. The
CRC-16 uses the G(x) = x16 + x6 + x5 + x3 + 1 generator polynomial, and is calculated as follows:
1) The overhead bytes 2 to 10 of the OH frame are taken in network byte order, most significant
bit first, to form a 72-bit pattern representing the coefficients of a polynomial M(x) of
degree 71.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 13

2) M(x) is multiplied by x16 and divided (modulo 2) by G(x), producing a remainder R(x) of
degree 15 or less.
3) The coefficients of R(x) are considered to be a 16-bit sequence, where x15 is the most
significant bit.
4) This 16-bit sequence is the CRC-16 where the first bit of the CRC-16 to be transmitted is the
coefficient of x15 and the last bit transmitted is the coefficient of x0.
The demapper process performs steps 1-3 in the same manner as the mapper process, except that here,
the M(x) polynomial of step 1 includes the CRC-16 bits in received order, and has degree 87. In the
absence of bit errors, the remainder shall be 0.
9.2.8 FlexO management communications channel (FCC)
An 896-bit (112 bytes) field per multi-frame is provided for a FlexO interface management
communications channel. These are allocated across all 8 frames of the multi-frame. This provides a
clear channel, and the format and content of the management channel is outside the scope of this
recommendation.
NOTE – The FCC is intended for interface management functions and is not a generic communications
channel.
The FCC field is located in all frames, in overhead bytes 13 to 26. If unused, the management channel
shall be filled with all-0s prior to scrambling. The FCC bytes provide a communication channel per
FlexO interface with an approximate bandwidth of 17.98 Mbit/s.

Figure 9-8  FCC transmission order

9.2.9 FlexO reserved overhead (RES)
123.5 bytes of the FlexO overhead area in the FlexO multi-frame structure are reserved for future
international standardization. These bytes/bits are located in frame 1/byte 5, frame 2/bytes 4, 5, 6,
frames 3 to 8/bytes 3 to 6 and frames 1 to 8/bytes 29 to 40. These bytes/bits are set to all-0s prior to
scrambling.
9.2.10 OTN Sync Message Channel (OSMC)
A 128-bit (16 bytes) field per multi-frame is provided for an OTN synchronization message channel.
These are allocated across all eight frames of the multi-frame. This field provides a clear channel, to
transport SSM and PTP messages.
The OSMC is only defined on the first FlexO interface (lowest PID value) of a FlexO group. The
OSMC field is located in all frames, in overhead bytes 27 and 28. If unused, the OTN synchronization
message channel bytes shall be filled with all-0s prior to scrambling. The OSMC bytes are combined
to provide a messaging channel, as illustrated in Figure 9-9, with an approximate bandwidth of
2.56 Mbit/s per 100G interface.

14 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Figure 9-9  OSMC transmission order

The SSM and PTP messages within a FlexO interface are encapsulated into GFP-F frames as specified
into [ITU-T G.7041]. PTP event messages are timestamped and after encapsulation into GFP-F
frames, inserted into the OSMC as specified in clause 9.2.9.1. GFP-F encapsulated SSM messages
(and PTP non-event messages) are inserted into the OSMC at the earliest opportunity. GFP Idle
frames may be inserted between successive GFP frames.
The mapping of generic framing procedure (GFP) frames is performed by aligning the byte structure
of every GFP frame with the byte of the OSMC overhead field. Since the GFP frames are of variable
length and may be longer than 16 bytes, a GFP frame may cross the FlexO multi-frame boundary.
9.2.10.1 Generation of event message timestamp
The message timestamp point [ITU-T G.8260] for a PTP event message transported over the OSMC
shall be the 32-frame multi-frame event (corresponding to MFAS[4:8] = 00000) preceding the
beginning of the GFP frame, in which the PTP event message is carried. Since the GFP frames may
be longer than 64 bytes, a frame may cross the FlexO 32-frame multi-frame boundary.
All PTP event messages are timestamped on egress and ingress interfaces. The timestamp shall be
the time at which the event message timestamp point passes the reference plane [ITU-T G.8260]
marking the boundary between the PTP node (i.e., OTN node) and the network.
Event message timestamps are generated at the FlexO Access Point. The message timestamp point is
specified below as the 32-frame FlexO multi-frame event corresponding to MFAS[4:8] = 00000. For
this application, the FlexO multi-frame event is defined as when the first bit of the first alignment
marker, corresponding to MFAS[4:8] = 00000 frame, on a lane crosses between the PTP node
(i.e., OTN node) and the network (i.e., the analogous point to Ethernet MDI). In the case of a
multi-lane PHY, the PTP path data delay is measured from the beginning of the alignment marker at
the reference plane, which is equivalent to Ethernet MDI of the lane with the maximum media
propagation delay. In practice:
– On egress interfaces, since the alignment markers for all lanes are transmitted at the same
time conceptually, any alignment marker can be used for timestamping.
– On ingress interfaces, alignment markers are present in all the lanes, but different lanes may
be skewed from each other. The last received alignment marker across all the lanes shall be
used for timestamping.
NOTE 1 – The first byte of a GFP (PTP event message) frame is inserted into the FlexO OSMC between 4 and
31 frames after the 32-frame multi-frame boundary.
NOTE 2 – The guard band of four frames is defined to simplify implementation.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 15

 Figure 9-10  Timing diagram example for OSMC

NOTE 3 – This time synchronization over FlexO interface implementation does not generate event message
timestamps using a point other than the message timestamp point [ITU-T G.8260].
In this time synchronization over FlexO interface implementation, the timestamps are generated at a
point removed from the reference plane. Furthermore, the time offset from the reference plane is
likely to be different for inbound and outbound event messages. To meet the requirement of this
subclause, the generated timestamps should be corrected for these offsets. Figure 19 in [IEEE 1588]
illustrates these offsets. Based on this model, the appropriate corrections are as follows:
<egressTimestamp> = <egressMeasuredTimestamp> + egressLatency
<ingressTimestamp> = <ingressMeasuredTimestamp> – ingressLatency
where the actual timestamps <egressTimestamp> and <ingressTimestamp> measured at the reference
plane are computed from the detected, i.e., measured, timestamps by their respective latencies. Failure
to make these corrections results in a time offset between the slave and master clocks.
The PTP timestamp is associated with the first FlexO interface (lowest PID value) of a FlexO group.

10 OTUCn mapping

10.1 Dividing and combining OTUCn

An OTUCn frame structure is specified in clause 11.3 [ITU-T G.709], and contains n synchronous
instances of OTUC frame structures. The FlexO source adaptation consists of splitting the OTUCn
frame into n * OTUC instances. Similarly, the sink adaptation combines n * OTUC instances into an
OTUCn. A single or multiple OTUC instances are then associated to a FlexO interface. Alignment
and deskewing are performed on the OTUC instances.

16 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Figure 10-1  OTUCn divided onto n * OTUC

10.2 FlexO frame payload

The FlexO payload area is divided in 128-bit blocks. The 128-bit blocks are aligned to the start of a
FlexO payload area (following AM and OH). The FlexO frame payload consists of 5,120 blocks
(frame #1-7 of the multi-frame, with fixed stuff payload) and 5,130 blocks (frame eight of the
multi-frame, without fixed stuffing).
NOTE – This 128-bit (16-byte) word/block alignment of the 100G OTUC is analogous to the 66b block
alignment of a 100G Ethernet PCS stream that is kept through the clause 91 [IEEE 802.3-2015] adaptation
process.

10.3 Mapping of OTUC into FlexO frame

Groups of 128 successive bits (16 bytes) of the OTUC signal are mapped into a 128-bit block of the
FlexO frame payload area using a BMP control mechanism as specified in clause 17 of
[ITU-T G.709]. The 128-bit group of OTUC is aligned to the OTUC frame structure. The OTUC
frame structure is floating in respect to the FlexO frame.
The serial bit stream of an OTUC signal is inserted into the FlexO frame payload so that the bits will
be transmitted on the FlexO interface in the same order that they were received at the input of the
mapper function.
In clause 8.3, the shown bit rate ratio between FlexO frame and payload is 256/241.
10.3.1 Mapping of OTUC into 100G FlexO frame
There exists a one-to-one relationship between an OTUC and a 100G FlexO interface. The FlexO
payload area is segmented in 128-bit blocks. The OTUC is mapped in contiguous 128-bit segments.
There are (5,140*128*8 – 1,280*15) / (239*16*8*4) = 42.85 OTUC frames per FlexO multi-frame.
This results in ~5 OTUC frames per FlexO frame, or a new OTUC frame every ~24 FlexO frame
rows, as shown in Figure 10-2A.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 17

 Figure 10-2A  OTUC mapped into 100G FlexO frame payload

The FlexO frame payload does not divide elegantly into 128-bit blocks in a single row. The block
will spill over and cross row boundaries as shown in Figure 10-2A. The 128-bit alignment is always
consistent across FlexO frames and the first 128-bit block starts immediately following the overhead
area.
The AVAIL field indicates whether an OTUC is mapped into the FlexO frame payload (set to ''1'') or
if the FlexO payload is empty (set to ''0''). Other AVAIL values are not valid for 100G FlexO
interfaces.

10.4 FlexO group alignment and deskewing

FlexO members are identified within a group and reordered using GID, MAP and PID FlexO OH
field. The PID sequence is used to recreate an OTUCn in proper sequence order. For example
OTUC#1 is mapped into a FlexO frame with the minimum PID number, and so on.
Deskewing in the sink process is performed between OTUC frames within the group, using OTUC
FAS as specified in [ITU-T G.709].
The skew requirements are intended to account for variations due to digital mapping and cable
lengths. The skew tolerance requirement is 300 ns.
NOTE – These requirements are in line with [OIF FlexE IA] Low Skew applications.

10.5 Scrambling
The FlexO frame payload, AM padding, fixed stuffing and overhead must be scrambled prior to
transmission, in order to provide DC balance and proper running disparity on the interface. The ami
fields in the AMs are not scrambled and the chosen values have properties of already being DC
balanced. The padding padi fields of the AMs as shown in Figure 9-3A are scrambled.
The operation of the scrambler shall be functionally equivalent to that of a frame-synchronous
scrambler of sequence 65535 and the generating polynomial shall be x16 + x12 + x3 + x + 1.
(See Figure 11-3 [ITU-T G.709] for an illustration of this scrambler.)
The scrambler resets to 0xFFFF on the most significant bit of the start of frame and the scrambler
state advances during each bit of the FlexO frame (Figure 10-3). In the source function, the AM values
(ami fields) are inserted after scrambling and before the input to the FEC encoder. In other words, the
FEC encoding is performed on unscrambled AM bits (ami fields). The FEC encoder overwrites the

18 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

FEC bit fields. The sink then receives unscrambled AM (ami fields) and FEC fields, as illustrated in
Figure 10-4.

Figure 10-3  FlexO scrambler

Figure 10-4  FlexO scrambler after AM and FEC insertion

11 FOIC interface

11.1 FOIC1.4 interface

An FOIC1.4 interface is used as a system interface with 100G optical modules. A FlexO frame is
adapted over multi-channel parallel interfaces, using four ~28 Gbit/s physical lanes. No
bit-multiplexing is performed.
The alignment markers for the FlexO frame are distributed on four lanes, resulting in 240-bit of data
per lane. The alignment marker (AM) values are specified in clause 9.1. Each AM has unique UMx
and UPx values. When the four AMs distributed to lanes 0, 1, 2 and 3, the differing values are used
for lane reordering in the sink function. The CMx values are replicated on all four lanes to facilitate
the searching, alignment and deskewing process.
After FEC encoding, the data and parity bits are distributed to all four lanes, in groups of 10-bits, in
a round robin distribution scheme from the lowest to the highest numbered lanes. The resulting
per-lane transmitted values of the AM fields are illustrated in Table 11-1 where the transmission order
is from left to right. In other words, for example, AM0 is transmitted in Lane 0, AM1 is transmitted
in Lane 1, etc., and the bits of each 10-bit word are transmitted MSB first.
NOTE 1 – The inverse multiplexing function is based on clause 91 [IEEE 802.3-2015].
NOTE 2 – The mechanism is compatible and can reuse optical modules being developed for
IEEE 100GBASE-R4, with OTU4 rate support.
NOTE 3 – The electrical specifications for an FOIC1.4 25G lane is found in [b-OIF CEI IA].

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 19

 Table 11-1 – AM bit distribution over the four FOIC1.4 lanes
Lane 0 Lane 1 Lane 2 Lane 3
AM bits 10-bit symbol of 10-bit symbol of 10-bit symbol of 10-bit symbol of
AM0 AM1 AM2 AM3
1 – 40 0101100101 0101100101 0101100101 0101100101
41 – 80 0100100110 0100100110 0100100110 0100100110
81 – 120 0100011011 0100001000 0100011000 0100010110
121 – 160 0110100110 0010100110 1010100110 1010100110
161 – 200 1010110110 1010110110 1010110110 1010110110
201 – 240 0110111001 0110111110 0110110111 0110110010
241 – 280 1011100000 0110010110 1111011111 0001011000
281 – 320 0010001110 1001111011 0011001111 0100000001
321 – 360 1100111101 0111111000 0110101010 0000101111
361 – 400 1001000111 0110011010 0000001000 0111101001
401 – 440 1111011100 0101100001 0011001100 1110111111
441 – 480 0100110000 0010000001 0010010101 1011110100
NOTE – Transmission order of each 10-bit word is left-to-right (MSB first). The transmission order within
the FlexO frame is left-to-right across the row, and down the table. The transmission order for each lane is
per-word and down the table.

11.1.1 FOIC1.4 skew tolerance requirements

The lane skew tolerance requirement is 180ns.
NOTE – These requirements are in line with CAUI4 [IEEE 802.3-2015].
11.1.2 FOIC1.4 28G lane bit rate
The FOIC1.4 lane is synchronous to the FlexO frame. There are four lanes.
FOIC1.4_lane_rate = 100G_FlexO_rate/4
= 1/4 × 256/241 × 239/226 × 99 532 800 kbit/s ±20 ppm
NOTE – The nominal lane rate is approximately: 27 952 368.611 kbit/s
The 100G_FlexO_rate is specified in clause 8.4.
This results in a FOIC1.4 lane bit rate with a -4.46 ppm offset from the OTL4.4 nominal bit rate.
11.1.3 m*FOIC1.4 interface
The m*FOIC1.4 interface supports multiple optical tributary signals on each of the m single optical
spans with 3R regeneration at each end.
An m*FOIC1.4 interface signal contains one OTUCn signal striped across the m optical interfaces
and the k=4 lanes per optical interface.
Specifications of the optical tributary signal carrying each FOIC1.4 lane are contained in
[ITU-T G.695] and [ITU-T G.959.1].

20 Rec. ITU-T G.709.1/Y.1331.1 (01/2017)

 Bibliography

[b-ITU-T G-Sup.58] ITU-T G-series Recommendations – Supplement 58 (2016), Optical

transport network (OTN) module framer interfaces (MFI).
[b-IEEE 802.3bs] IEEE Std. 802.3bs/D2.0, Draft Standard for Ethernet Amendment: Media
Access Control Parameters, Physical Layers and Management
Parameters for 200 Gb/s and 400 Gb/s Operation.
[b-OIF CEI IA] OIF, Common Electrical I/O (CEI) (2014), Electrical and Jitter
Interoperability agreements for 6G+ bps, 11G+ bps and 25G+ bps I/O.

Rec. ITU-T G.709.1/Y.1331.1 (01/2017) 21

 ITU-T Y-SERIES RECOMMENDATIONS
GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS, NEXT-
GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES

GLOBAL INFORMATION INFRASTRUCTURE

General Y.100–Y.199
Services, applications and middleware Y.200–Y.299
Network aspects Y.300–Y.399
Interfaces and protocols Y.400–Y.499
Numbering, addressing and naming Y.500–Y.599
Operation, administration and maintenance Y.600–Y.699
Security Y.700–Y.799
Performances Y.800–Y.899
INTERNET PROTOCOL ASPECTS
General Y.1000–Y.1099
Services and applications Y.1100–Y.1199
Architecture, access, network capabilities and resource management Y.1200–Y.1299
Transport Y.1300–Y.1399
Interworking Y.1400–Y.1499
Quality of service and network performance Y.1500–Y.1599
Signalling Y.1600–Y.1699
Operation, administration and maintenance Y.1700–Y.1799
Charging Y.1800–Y.1899
IPTV over NGN Y.1900–Y.1999
NEXT GENERATION NETWORKS
Frameworks and functional architecture models Y.2000–Y.2099
Quality of Service and performance Y.2100–Y.2199
Service aspects: Service capabilities and service architecture Y.2200–Y.2249
Service aspects: Interoperability of services and networks in NGN Y.2250–Y.2299
Enhancements to NGN Y.2300–Y.2399
Network management Y.2400–Y.2499
Network control architectures and protocols Y.2500–Y.2599
Packet-based Networks Y.2600–Y.2699
Security Y.2700–Y.2799
Generalized mobility Y.2800–Y.2899
Carrier grade open environment Y.2900–Y.2999
FUTURE NETWORKS Y.3000–Y.3499
CLOUD COMPUTING Y.3500–Y.3999
INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES
General Y.4000–Y.4049
Definitions and terminologies Y.4050–Y.4099
Requirements and use cases Y.4100–Y.4249
Infrastructure, connectivity and networks Y.4250–Y.4399
Frameworks, architectures and protocols Y.4400–Y.4549
Services, applications, computation and data processing Y.4550–Y.4699
Management, control and performance Y.4700–Y.4799
Identification and security Y.4800–Y.4899
Evaluation and assessment Y.4900–Y.4999

For further details, please refer to the list of ITU-T Recommendations.

 SERIES OF ITU-T RECOMMENDATIONS

Series A Organization of the work of ITU-T

Series D Tariff and accounting principles and international telecommunication/ICT economic and
policy issues
Series E Overall network operation, telephone service, service operation and human factors
Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other multimedia
signals
Series K Protection against interference

Series L Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation
and protection of cables and other elements of outside plant
Series M Telecommunication management, including TMN and network maintenance

Series N Maintenance: international sound programme and television transmission circuits

Series O Specifications of measuring equipment

Series P Telephone transmission quality, telephone installations, local line networks

Series Q Switching and signalling, and associated measurements and tests

Series R Telegraph transmission
Series S Telegraph services terminal equipment
Series T Terminals for telematic services

Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects, next-generation networks,

Internet of Things and smart cities
Series Z Languages and general software aspects for telecommunication systems

Printed in Switzerland
Geneva, 2017