openzrplus_1p0.pdf

Open ZR+ MSA

Technical Specification

Change History

REV No. Date Description

1.0 4-Sep-2020 First release publication

Chair: Atul Srivastava, NTT Electronics

Co-Chair: Tom Williams, Acacia Communications

Editor: David Lewis, Lumentum

Member companies at the time of publication:

Acacia Communications

Arista Networks

Cisco

Fujitsu Optical Components

Innolight

Juniper Networks

Lumentum

NTT Electronics

Limitation on use of Information:

This specification is provided "AS IS" with NO WARRANTIES whatsoever and therefore the provision of this specification does not include any warranty of merchantability, noninfringement, fitness for a particular purpose, or any other warranty otherwise arising out of any proposal, specification or sample. The authors further disclaim all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein.

Permissions:

You are authorized to download, reproduce and distribute this document. All other rights are reserved. The provision of this document should not be construed as the granting of any right to practice, make, use or otherwise develop products that are based on the document. Any and all IP rights related to this document and the designs disclosed within, except for the rights expressly mentioned above, are reserved by the respective owners of those IP rights.

OpenZR+ MSA Specification, version 1.0 openzrplus.org 2

Contents

1 Scope and Introduction

1.1 400ZR+ Format

1.2 300ZR+ Format

1.3 200ZR+ Format

1.4 100ZR+ Format

1.5 OpenZR+ Supported Client Modes

2 OpenZR+ Block Diagram

3 ZR frame structure

3.1 257-bit Blocks

3.2 ZR400 Frame

3.3 ZR400 Frame

3.4 ZR300 Frame

3.5 ZR200 Frame

3.6 ZR100 Frame

3.7 Framing Overhead

3.8 Media Slot Identifier (MSI) / Tributary Slot Identifier (TSI)

4 Datapath Processing

4.1 OpenZR+ Multiplexing/Demultiplexing (ZRMAP/ZRDEMAP)

4.2 GMP Definition

4.3 GMP Blocks

4.4 Mapping of client traffic into ZR400

4.5 Generic Mapping Procedure Principles

4.6 Stuffing Locations

5 Multiplexing

5.1 ZR400 Frame Structure

5.1.1 400G Container Multiplexing

5.1.2 1×400G Data Multiplexing

5.1.3 2×200G Data Multiplexing

5.1.4 4×100G Data Multiplexing

5.2 ZR300 Frame Structure

5.2.1 300G Container Multiplexing

5.2.2 3×100G Data Multiplexing

5.3 ZR200 Frame Structure

5.3.1 200G Container Multiplexing

5.3.2 1×200G Data Multiplexing

5.3.3 2×100G Data Multiplexing openzrplus.org 3

5.4 ZR100 frame structure

5.4.1 100G Container Multiplexing

5.4.2 1x100G Data Multiplexing

6 ZRx adaptation to OFEC

6.1 Padding Insertion/Removal

6.2 ZR400 adaptation to ZR400-OFEC-16QAM

6.3 ZR300 adaptation to ZR300-OFEC-8QAM

6.4 ZR200 adaptation to ZR200-OFEC-QPSK

6.5 ZR100 adaptation to OFEC input blocks

6.6 Frame Synchronous Scrambling

7 Open Forward Error Correction (OFEC)

7.1 OFEC encoding codec

7.2 Encoding

7.3 Encoder interface

7.4 Formal encoder definition

7.5 Decoding

7.6 OFEC Interleaver

7.7 OFEC Interleaver architecture

7.8 Intra-block interleaving

7.9 Inter-block interleaving

8 Symbol Mapping and Polarization Distribution

8.1 Symbol mapping

8.2 DP-16QAM Symbols

8.3 8QAM Symbols

8.4 QPSK Symbols

9 DSP Framing

9.1 DSP super-frame

9.2 DSP sub-frame

9.3 FAW Sequence

9.4 Training Sequence

9.5 Pilot Sequence

10 Frame Expansion Rate

11 Optical Specifications

11.1 OpenZR+ DWDM amplified application:

openzrplus.org 4

11.1.1 DWDM link specifications (black link methodology)

11.1.2 Transmitter Optical Specifications

11.1.3 Receiver Optical Specifications

11.2 OpenZR+, Single wavelength, Unamplified:

11.3 Optical Parameter Definitions

11.3.1 Receiver Optical Signal-to-noise Ratio Tolerance

11.3.2 Tx spectral excursion

11.3.3 Out-of-Band OSNR (OOB OSNR)

11.3.4 Differential Group Delay (DGD)

11.3.5 Ripple

11.3.6 Optical return loss at SS

11.3.7 Discrete reflectance between SS and RS

11.3.8 Polarization Dependent Loss (PDL)

11.3.9 Polarization rotation speed

11.3.10 Inter-channel crosstalk

11.3.11 Interferometric crosstalk

11.3.12 I-Q offset

12 Appendix - Host interfaces (informative)

12.1 400GE Clients

12.2 200GE Clients

12.3 100GE Clients

12.4 Client signal processing

openzrplus.org 5

1 Scope and Introduction

OpenZR+ defines specifications for 100-400G single-wavelength optical ports for transceiver/transponder, muxceiver/muxponder (TRXR/TRPN, MUXR/MUXP) node functions and for switch/router optical ports.

O F

E C

DSP Frame

100GBASE-R

400GBASE-R

ZR.ts x1..4

[1

-4

G Z

R F ra m e

400ZR-OFEC-16QAM

300ZR-OFEC-8QAM

200ZR-OFEC-QPSK

100ZR-OFEC-QPSK

GMP

GMP

200GBASE-R

PMA/PCS

GMP PIC

400G ETHERNET STREAMING

x1..4 x1..2 x1

RS(544/514)

FEC

100G ETHERNET STREAMING

200G ETHERNET STREAMING

PMA/PCS

RS(544/514)

FEC

RS(544/514) or

RS(528/514)

FEC

PMA/PCS

Figure 1-1: OpenZR+ Architecture reference

The architecture, shown in Figure 1-1 includes client sub-layers for up to four 100GBASE-

R clients, up to two 200GBASE-R clients and a single 400GBASE-R client. Client data and alignment markers are extracted and re-timed to the line side clock domain using the general mapping protocol (GMP). Retimed data plus GMP timing information is then mapped into one of the OpenZR+ frame formats. Those frames are multiplexed and OFEC encoded and become the payload of a DSP frame with DP-16QAM, DP-8QAM, or DP-

QPSK symbols.

Note: this specification makes no assumption about the allocation of functions on a line card or optical modules (albeit, a typical module will provide a transceiver/muxceiver function for Ethernet signals 100G and beyond).

Table 1-1 lists possible combinations of clients and network lane interfaces included in this specification.

Table 1-1: Transceiver/Transponder (TRXR/TRXP) functions

O p e n

Z R

F o r m a t

C a p a c it y

Host Lane Interfaces *

Network Lane Interface

G

B A

S E

-R

G

B A

S

G

B A

S

400ZR+ 400G 1 2 4 ZR400-OFEC-16QAM

300ZR+ 300G 3 ZR300-OFEC-8QAM

200ZR+ 200G 1 2 ZR200-OFEC-QPSK

100ZR+ 100G 1 ZR100-OFEC-QPSK

* Only clients from one column may be multiplexed to a network interface, i.e., no mixed modes are permitted.

OpenZR+ supports the combinations of network framing and modulation modes shown in

Table 1-3.

openzrplus.org 6

Table 1-2: OpenZR+ Line Encoding, Modulation and Symbol Rates

O p e n

Z R

F o r m a t

P a y lo a d

R a te

Framing Format

Symbol Baud Rate

(+/- 20ppm)

M o d u la ti o n

FEC

Net Coding

Gain

(NCG)

(dB)

Pre-

FEC

BER

Reference Standard

400ZR+ 400G ZR400-OFEC-16QAM 60 138 546 798 16QAM

OFEC 11.6 2.0E-2 OpenZR+

300ZR+ 300G ZR300-OFEC-8QAM 60 138 546 798 8QAM

200ZR+ 200G ZR200-OFEC-QPSK 60 138 546 798 QPSK

100ZR+ 100G ZR100-OFEC-QPSK 30 069 273 399 QPSK

1.1 400ZR+ Format

This DSP framing format is based on the OIF-ZR400-01.0 frame, adapted with open forward error correction (OFEC), then modulated over a dual polarization coherent interface with absolute (non-differential) 16QAM modulation. The payload can be of the following types:

• A single 400GBASE-R host interface GMP mapped into a clear channel ZR400 frame structure

• 2 × 200GBASE-R host interfaces each individually GMP mapped into a single channelized 400G ZR frame structure.

• 4 × 100GBASE-R host interfaces each individually GMP mapped into a single channelized 400G ZR frame structure.

1.2 300ZR+ Format

This DSP framing format is a reduced bandwidth 300G ZR frame, adapted with open forward error correction (OFEC), then modulated over a dual polarization coherent interface with absolute (non-differential) 8QAM modulation. The payload can be of the following type:

• 3 × 100GBASE-R host interfaces, each individually GMP mapped into a single channelized 300G ZR frame structure.

1.3 200ZR+ Format

This DSP framing format is a reduced bandwidth 200G ZR frame, adapted with open forward error correction (OFEC), then modulated over a dual polarization coherent interface with absolute (non-differential) QPSK modulation. The payload can be of the following types:

• A single 200GBASE-R host interface GMP mapped into a clear channel 200G

ZR frame structure

• 2 × 100GBASE-R host interfaces, each individually GMP mapped into a single channelized 200G ZR frame structure.

openzrplus.org 7

1.4 100ZR+ Format

This DSP framing format is a reduced bandwidth ZR100 frame, adapted with open forward error correction (OFEC), then modulated over a dual polarization coherent interface with absolute (non-differential) QPSK modulation. The payload can be of the following types:

• A single 100GBASE-R host interface GMP mapped into a reduced rate 100G

ZR frame structure

1.5 OpenZR+ Supported Client Modes

The combinations of host interfaces and media side interfaces listed in Table 1-3 may be supported by OpenZR+ implementations. Modes supported are vendor specific.

Table 1-3 Client modes supported by OpenZR+

Host Side Datapath Media Side

Host

Interface Host Map/Demap MUX/DMUX

Media

Framing

FEC

Encode/Decode Modulation

Media

Interface

1 x 400GBASE-R 1 x 400ZR.ts

400ZR OFEC 16QAM ZR400-OFEC-16QAM 2 x 200GBASE-R 2 x 200ZR.ts

4 x 100GBASE-R 4 x 100ZR.ts

3 x 100GBASE-R 3 x 100ZR.ts ZR300 OFEC 8QAM ZR300-OFEC-8QAM

1 x 200GBASE-R 1 x 200ZR.ts

ZR200 OFEC QPSK ZR200-OFEC-QPSK

2 x 100GBASE-R 2 x 100ZR.ts

1 x 100GBASE-R 1 x 100ZR.ts ZR100 OFEC QPSK ZR100-OFEC-QPSK openzrplus.org 8

2 OpenZR+ Block Diagram

400GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (20*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(20*257b)

CRC-32 checkingCRC-32 Calculation

200GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (10*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(10*257b)

CRC-32 checkingCRC-32 Calculation

OpenZR+

OFEC Adaption/Map

Gray mapping, symbol

Interleaving, Pol distribution

OFEC Adaptation/Demap

DSP Frame

OFEC detected Local Degrade

Pol combining & Symbol de-interleaving

FAW & TS Insertion

Pilot removal Pilot Insertion

DSP Frame

FAW/TS removal

2 2

OFEC Adaption

Encode OFEC Adaption

Decode

RX DSPTX DSP

ADCDAC

PMD (Optical Interface)

Photonic InterfacePhotonic Interface

[100G-400G] OpenZR+ Frame

100GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (5*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(5*257b)

CRC-32 checkingCRC-32 Calculation

100GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (5*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(5*257b)

CRC-32 checkingCRC-32 Calculation

100GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (5*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(5*257b)

CRC-32 checkingCRC-32 Calculation

100GE Client Logic

GMP Mapping

(4*257b stuffing)

OH/AM insertion (5*257b)

GMP de-mapping

(4*257b de-stuffing)

AM/OH detect & removal

(5*257b)

CRC-32 checkingCRC-32 Calculation

OFEC

Figure 2-1 OpenZR+ Block Diagram openzrplus.org 9

3 ZR frame structure

The ZR frame structure is defined prior to OFEC coder adaptation and OFEC processing.

Aspects of the ZR frame structure that are specific to ZRx-OFEC-<modulation> are identified, otherwise the ZRx overhead is common to the requirements defined in

OIF400ZR-01.0.

This section describes the various framing containers used in the ZR multiplexing / demultiplexing process. The generic ZRx frame structure is shown in Figure 3-1. ZRx frames are based on the OIF 400ZR frame. Organized as m columns x n rows, with the values of m being either 5140 or 10280, and the values on n being 128, 192 or 256, all four

ZRx frames are a multiple of 257 bits so that the 257-bit payloads fit into the designated payload area. Frame overhead bits are in the first row of each frame and include alignment markers (AM), pad (PAD), overhead (OH), and sufficient additional pad bits so that these overhead fields lie on a 257b boundary in the frame.

rows m

Columns n

Frame

Payload area

AM PAD OH

n

Frame

Payload area

AM PAD OH

Figure 3-1 – Generic ZRx Frame and Multi-Frame structure

3.1 257-bit Blocks

The ZR frame payloads are broken down into 257-bit blocks. The number of 257-bit blocks is the same in all rows of the frame except the first row. The first row is shared with the frame overhead. Table 3-1 defines the number of 257-bit payload blocks for each of the various framing formats.

openzrplus.org 10

Table 3-1 – 257-bit blocks in ZRx frames and 4-frame multiframes

Server Mode

First row 257-bit blocks allocated to AM/PAD/OH and additional pad bits

Payload 257-bit blocks in 1 frame

Payload 257-bit blocks in 4 frames

ZR100 5 2555 10220

ZR200 10 5110 20440

ZR300 15 7665 30660

ZR400 20 10220 40880

3.2 ZR400 Frame

The diagrams in this section have been cloned directly from the 400ZR IA. Figure 3-1 – shows the high-level format of the ZR400 frame without any FEC overhead. The frame is constructed using 256 rows of 10280 bits. Each row contains forty 257-bit blocks. The first twenty 257-bit blocks of the first row are used to support overhead information. The remaining (255*40) + 20 257-bit blocks are used for payload. There are sixteen frames in a multi-frame. The GMP algorithm is performed across a group of four consecutive frames.

3.3 ZR400 Frame

The 400G frame provides 20 bits of padding between the OH area and the Payload area in order to insure both the OH and payload areas are multiples of 257-bit blocks. The 400G frame has 20 257-bit blocks of framing and 10220 257-bit blocks of payload. The 400G has four unique blocks of OH and each OH is 40 bytes in size.

Columns

1 1920 1921 3840 3841 5120 5141 10280

Rows AM PAD OH 20 Payload (5140 bits)

1 Payload (10280 bits)

2 Payload (10280 bits)

PAYLOAD

Figure 3-2 – 400G ZR400 Frame

3.4 ZR300 Frame

The 300G frame differs slightly from the 400G frame.

• The 300G frame has 192 rows compared to 256 rows.

• The AM area contains 12 lanes of 120-bit alignment markers

• The OH area contains 3 blocks of 320-bits instead of 4 blocks.

• The additional PAD between OH and payload is 15 bits.

openzrplus.org 11

• The 300G frame has AM/PAD/OH/additional pad bits in the first 3855 columns of the first row

(corresponds to 15 x 257-bit blocks) and 7665x 257-bit blocks of payload.

Columns

1 1440 1441 2880 2881 3840 3856 10280

AM PAD OH 15 Payload (6425 bits)

1 Payload (10280 bits)

Figure 3-3 – ZR300 Frame

3.5 ZR200 Frame

The 200G frame differs slightly from the 400G frame.

• The 200G frame has 128 rows compared to 256 rows.

• The AM area contains 8 lanes of 120-bit alignment markers

• The OH area contains 2 blocks of 320-bits instead of 4 blocks.

• The additional PAD between OH and payload is 10 bits.

• The ZR200 frame has AM/PAD/OH/additional pad bits in the first 2570 columns of the first row (corresponds to 10×257-bit blocks) and 5110×257-bit blocks of payload.

1 960 961 1920 1921 2560 2571 10280

Rows AM PAD OH 10 Payload (7710 bits)

1 Payload (10280 bits)

Figure 3-4 –ZR200 Frame openzrplus.org 12

3.6 ZR100 Frame

The 100G frame differs slightly from the 400G frame.

• The 100G frame has 128 rows compared to 256 rows.

• The 100G frame has 5140 bits per row compared to 10280 bits per row.

• The AM area contains 4 lanes of 120-bit alignment markers

• The OH area contains 1 block of 320-bits instead of 4 blocks.

• The additional PAD between OH and payload is 5 bits.

• The 100G frame has 5 257-bit blocks of OH and 2555 257-bit blocks of payload.

1 480 481 960 961 1280 1285 5140

Rows AM PAD OH 5 Payload (3855 bits)

1 Payload (5140 bits)

2 Payload (5140 bits)

Figure 3-5 – 100G ZR400 Frame

3.7 Framing Overhead

Figure 3-6 – ZR400 Framing (Overhead) provides an expanded view of the framing area which lives in the beginning of row 1. The AM section follows the recommendation defined in the 400ZR IA. The OH section follows the recommendation in OIF 400ZR IA but also include GID, PID, MAP and CRC OH bytes. OpenZR+ also defines the Media

Slot Identifier (MSI) byte.

openzrplus.org 13

Figure 3-6 – ZR400 Framing (Overhead)

The ZR frame uses the STAT and GMP JC1-JC6 as defined in OIF 400ZR IA, and MFAS, GID, and PID as defined in G.709. The ZR frame adds the additional MSI field. All other fields are optional or defined as RES.

JC4 RES RES RES RES D1 D2

CRC4

D5 D6RES RES D7 D8JC5

JC6

3 4 5 6 7 8

D3 D4

RES RES

1 2

RES RES

7 -bit S CnD

RES

Provides 8-bit granularity

RES

RES: Reserved/Unused MSI: Media Stream Identifier MAP: PHY Member Map (RES) CRC: Cyclic Redundancy Check (RES) FCC: Frame Communications Channel (RES)

MFAS: Multi-Frame Alignment

STAT: RPF

GID: Group Identification(RES) PID: PHY member Identification(RES) OSMC: Synchronization Message (RES)

GMP justification overhead

1Byte 2 40 x4

CM: Common alignment marker UP: Unique pad UM: Unique alignment marker x16

BITS 1 120

{CM0,CM1,CM2} UP0 {CM3,CM4,CM5} UP1 {UM0,UM1,UM2} UP2 {UM3,UM4,UM5}

1920b 1280b1920b 20b Pad

20 x 257b

Frame 1

AM PAD OH

Frame 2

AM PAD OH

4x320 b

JC5 JC2

JC6 JC3

JC4 JC1

JC5 JC2

JC6 JC3

STAT CRC FCCMFAS MAPGID PIDGID RES OSMCGID

JC4 JC1

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

STAT CRC FCCMFAS MAP OSMC

RES

MSI

A

1 72

O

R

ES

P T

RES

MSI overhead

C1 C2 C3 C4 C5 C6

CRC8

C13 C14C9 C10 II DI

3 4 5 6 7 8

C7 C8

C11 C12

1 2

GMP Cm encoding

14-bit C1028

GMP Overhead &

Parameters (4x257b blocks stuffing granularity

JC1

JC2

JC3A: Tributary Available (0,1) O: Tributary Occupited (0,1) RES: Reserved set to 0 PT: Port (0,1,2,3)

Overhead Bytes

MFAS 1 2 3 4 5 6 7-10 11-12 13-26 27-28 29-40

openzrplus.org 14

Figure 3-7 – ZR400 Overhead

3.8 Media Slot Identifier (MSI) / Tributary Slot Identifier (TSI)

• The Media Slot Identifier (MSI) Row 4 / Byte 5 and follow example of PT22 MSI Byte as defined in G.709 Clause 20.4.1.1.

• OpenZR+ defines a 1:1 mapping between the host port and the Media Slot Identifier. These are then referred to as a Time Slot Instance TSI.

• Optionally a crossbar can be inserted between TSIs and the MSIs.

• The transmitter can send Cm/Cnd information in all OH locations, but the receiver must choose only one and the selection should be to choose Cm/Cnd from lowest ordinal OH assigned to the port.

• A port is assigned the number of tributaries required to accommodate the port rate.

• The tributaries are ordered in time with the lower ordinals first in time.

• The tributaries need not be consecutive to avoid bandwidth fragmentation.

The following Table is an example of the MSI OH byte value for various configurations of a ZR400 frame.

MODE OH1 OH2 OH3 OH4

1x400G 0xc0 0xc0 0xc0 0xc0

2x200G 0xc0 0xc0 0xc1 0xc1

4x100G 0xc3 0xc2 0xc1 0xc0

Table 3-2: MSI OH

0 MFAS STAT GID GID GID RES PID RES

RES

RES

RES

RES

RES

RES

1 MFAS STAT AVAIL JC4 JC1

2 MFAS STAT

JC5 JC2

3 MFAS STAT JC6 JC3

4 MFAS STAT MSI

5 MFAS STAT JC4 JC1

6 MFAS STAT JC5 JC2

7 MFAS STAT JC6 JC3

openzrplus.org 15

4 Datapath Processing

For OpenZR+ applications The TRX maps and multiplexes up to four 100GBASE-R, two

200GBASE-R or one 400GBASE-R Host/Client signals into a channelized ZR container.

Each channel is GMP mapped and 257b multiplexed into tributary unit(s) of a 200G, 300G, or 400G ZR frame structure. The 200-400G ZR frame overhead fields (AM, PAD, and OH) are partitioned in 10-bit tributary ordered slices. The ZR frame is then adapted with

OpenFEC (OFEC). OFEC is required to support Metro/Reginal and long-haul reaches.

OFEC can also provide additional margin when operating on a 75GHz grid.

The scope of this specification is how the node internal set of n × [100,200,400]GBASE-

R signals are mapped into m (m = [n/x]) ZR-x-OFEC-<modulation> signals, with each

ZR-x signal containing “x” (frame/multi-frame aligned interleaved) ZR tributary mapped signals (x ≥ 1).

The digital formatting and processing done by the ZR-x-OFEC-<modulation> port function is shown in Figure 4-1.

Figure 4-1: Digital port functions for a single ZRx-OFEC-mQAM signal

4.1 OpenZR+ Multiplexing/Demultiplexing (ZRMAP/ZRDEMAP)

OpenZR+ supports the mapping / de-mapping (ZRMAP/ZRDEMAP) and multiplexing / demultiplexing (ZRMUX/ZRDMUX) of up to 1 × 400GBASE-R, 1 or 2 × 200GBASE-R, or 1..4 × 100GBASE-R host interfaces. Combinations of 200GBASE-R and 100GBASE-

R host interfaces are also feasible, but outside the scope of this specification release. The

Ethernet host interfaces are assumed to be within +/-100ppm of each other, but otherwise asynchronously framed.

A high-level list of functions provided by OpenZR+ Muxceivers/Muxponders include:

• Multiplexing/Demultiplexing of Ethernet frames in 257-bit blocks.

• GMP mapping of Ethernet frames into n x 100G tributary slots.

• Reflection of PHY fault in reverse direction.

ZRx-OFEC-<modulation>

Padding ZR400 – 992b ZR300 – 744b ZR200 – 496b ZR100 – 496b

ZR TS#

in te rl ea ve

B A

SE

-R

(G M

P

596240b

894360b

1192480b

B A

SE

-R

(G M

P

ZR400 - 116 rows (4640 x 257b) ZR300 - 87 rows (3480 x 257b) ZR200 - 58 rows (2320 x 257b) ZR100 - 116 rows (2320 x 257b)

ZR

596736b

895104b

1193472b Scrambler 7104b

OFEC-x Coder Payload

B A

SE

-R

P M

A /P

C S

B A

SE

-R

P M

A /P

C S oFEC Interleaver Size = 172032b

DP-16QAM: 1376256b DP-8QAM: 1032192b DP-QPSK: 688128b

DP-16QAM (8x) DP-8QAM (6x) DP-QPSK (4x)

ZRx-OFEC

FAW, Counter, Reserved Symbols

FAW, Counter, Reserved Symbols

Insert 576 Symbols

172608

172608

Pilot insert with spacing 31

Pilot insert with spacing 31

32/31

178176

178176

X pol

Y pol

Polarization Distribution

172032

172032

H

V

344064Symbol Map

Scrambler

ENC0

ENC1

168x DP-16QAM 126x: DP-8QAM 84x: DP-QPSK oFEC Coder

596240b 596736b openzrplus.org 16

• Forward and reverse handling of LD, RD indicators, and local handling of FEC Degrade detection. ZR overhead information insertion/removal (MFAS, STAT, GID, PID, MSI, and

GMP JC1-JC6).

• PRBS generation/checking for the ZR payload.

• Local Fault sourcing for tributary slots in alarm state.

4.2 GMP Definition

The ZR400 frames operate at a fixed server frequency. The server frequency is higher than what is required to carry the payload. The difference between the input payload and the payload capacity is handled using GMP stuffing blocks. The client traffic is mapped into the ZR400 payload using GMP blocks. The GMP processor calculates the number of active and stuffing GMP blocks for each frame. The active GMP blocks are filled with client traffic while the stuffing GMP blocks are filled with a fixed pattern of all zeros.

The GMP process is defined in G.709 Annex D.

4.3 GMP Blocks

A consecutive set of 257-blocks are combined to form a GMP block. The ZR400 frame can support time-division multiplexing of both 100G, 200G and 300G clients into the

ZR400 container frame. Each client rate uses a different number of 257-bit blocks for each

GMP block. The GMP algorithm is used across a period of four ZR400 frames. The number of GMP blocks for each client rate is shown in Table 4-1 – GMP Block Counts.

All client rates have the same number of GMP blocks in four frames. This GMP block count serves as the Pm,server parameter in the GMP algorithm.

Client Mode

Number of 257-bit

Blocks in 1 GMP Block

Number of 257-bit Blocks in 4 Frames

Number of GMP blocks In 4 Frames

100G 1 10220 10220

200G 2 20440 10220

300G 3 30660 10220

400G 4 40880 10220

Table 4-1 – GMP Block Counts

4.4 Mapping of client traffic into ZR400

Figure 4-2 - Mapping of Client Traffic into ZR400 describes how data and stuffing are used in the ZR400 frame. For the 400G container, each GMP block is 4×257-bit blocks. Each

GMP block containers either data or stuffing. The GMP mapping scheme operates over a period of four ZR400 frames. The number of stuffing blocks in a frame is defined by the

Cm value that is stored in the ZR400 frame OH. A new Cm value is made available every four ZR400 frames.

openzrplus.org 17

Transmission order payload envelop = 4 × 10220 × 257-bit blocks (4-frame payload)

Stuffing granularity = 4 × 257-bit

2 3 4 4

C4×257b GMP Mapping Scheme

5 6 7 8 4

Data 4×257b

Data 4×257b

Stuff 4×257b

Data 4×257b b b

Stuff 4×257b

Data 4×257b

Data 4×257b

Stuff 4×257b

Data 4×257b

Figure 4-2 - Mapping of Client Traffic into ZR400

The number of 257-bit blocks in a GMP block is a function of the ZR400 container rate as defined in Table 4-1 – GMP Block Counts.

The ZR400 GMP overhead for this mapping consists of:

• Three justification control (JC1, JC2, JC3) bytes carrying the value of GMP overhead Cm;

• Three justification control (JC4, JC5, JC6) bytes carrying the value of GMP overhead ∑ CnD.

Figure 4-3 – Justification Control

The JC1, JC2 and JC3 bytes consist of a 14-bit Cm field (bits C1, C2, .., C14), a 1-bit

Increment Indicator (II) field, a 1-bit Decrement Indicator (DI) field and an 8-bit CRC-8 field which contains an error check code over the JC1, JC2 and JC3 fields.

The JC4, JC5 and JC6 bytes consist of a 7-bit CnD field (bits D1, D2, .., D7), a 4-bit CRC-

8 field which contains an error check code over the JC4, JC5 and JC6 fields.

The ZR400 payload consists of some number of GMP blocks (see Table 4-1 – GMP Block

Counts). Each GMP block consists of some number of 257-bits blocks (see Table 4-1 –

GMP Block Counts).

The ZR400 signal is created from a locally generated clock which is independent of the client signal. The client signal is adapted to the locally generated ZR400 clock by means of a generic mapping procedure (GMP) as specified in G.709 Annex D. The generic mapping process generates the Cm(t) and CnD(t) information, once per four ZR400 frames, according to Annex D and encodes this information in the justification control overhead

JC1/JC2/JC3 and JC4/JC5/JC6. The de-mapping process decodes Cm(t) and CnD(t) from

JC1/JC2/JC3 and JC4/JC5/JC6 and interprets Cm(t) and CnD(t) according to Annex D.

CRC-8 shall be used to protect against an error in JC1/JC2/JC3 and CRC4 protect against and error JC4/JC5/JC6 signals.

4.5 Generic Mapping Procedure Principles

Reference: G.709 Annex D.

The values of n, m, M, fclient, fserver, Tserver, Bserver, and Pm,server for client mapping into the

ZR400 are shown in Table 4-2.

JC4 RES RES RES RES D1 D2

CRC4

D5 D6RES RES D7 D8JC5

JC6

3 4 5 6 7 8

D3 D4

RES RES

1 2

RES RES

7 -bit S CnD

RES

Provides 8-bit granularity

RES

C1 C2 C3 C4 C5 C6

CRC8

C13 C14C9 C10 II DI

3 4 5 6 7 8

C7 C8

C11 C12

1 2

GMP Cm encoding

14-bit C1028

GMP Overhead &

Parameters (4x257b blocks stuffing granularity

JC1

JC2

JC3

openzrplus.org 18

Ref GMP Parameter

Formul a

Client Mapping Unit s

400GE to

ZR400

200GE to

ZR200

100GE to

ZR100

fclient nominal client information bit rate

401,542,892,456.055

200,771,446,228.027

100,390,625,000.000 b/s fclient client bit rate tolerance

100 100 100 ppm fserver server nominal bit rate

402,489,753,309.729

201,244,876,654.865

100,622,438,327.432 fserver server bit rate tolerance

20 20 20 ppm

Tserver period of the server multi-frame

Bserver / fserver 26.154 26.154 26.154 s

Bserver number of bits per server multi-frame

10,526,720

5,263,360

2,631,680 b

Oserver number of overhead bits per server multi-frame

20,560

10,280

5,140

Pserver number of payload bits per server multi-frame

Bserver -

Oserver

10,506,160

5,253,080

2,626,540 fp,server nominal server payload bit rate fserver x

Pserver /

Bserver

401,703,640,510.296

200,851,820,255.148

100,425,910,127.574 m GMP data/stuff granularity

1,028

M m and n ratio m/n

Pm,serv er

Max number of (m bits) in server payload area

Pserver/m

10,220

1028b blocks

Cm Number of client m-bit data entities per server multi-frame at nominal rates

Cm,nom

Cm value at nominal client and server bit rates

(fclient / fp,server) ×

Pm,server

10215.910 10215.910 10216.409

Cm,min Cm at min client, max server rates

Cm,nom × (1 -fclient) / (1

+ fserver)

10214.684 10214.684 10215.183

Cm,max Cm at max client, min server rates

Cm,nom × (1

+ fclient) /

(1 - fserver)

10217.136 10217.136 10217.635

Cm,min integer value of

Cm,min C,min

10214 10214 10215

Cm,max rounded up value of

Cm,max Cm,max

10218 10218 10218 n GMP justification accuracy, n bit data entity

8.03125 4.01563 2.00781 b

Pn,serve r

Max number of (n bits) data entities in the server payload area Pserver / n

1,308,160

8.0312

5b blocks openzrplus.org 19

Ref GMP Parameter

Formul a

Client Mapping Unit s

400GE to

ZR400

200GE to

ZR200

100GE to

ZR100

Cn Number of client n-bit data entities per server multi-frame at nominal rates

Cn,nom Cn value at nominal client and server bit rates

(fclient / fp,server) ×

Pn,server

1,307,636.519

1,307,636.519

1,307,700.372

Cn,min Cn at min client, max server rates

Cn,nom × (1 -fclient) / (1

+ fserver)

1,307,479.606

1,307,479.606

1,307,543.451

Cn,max Cn at max client, min server rates

Cn,nom × (1 + fclient) / (1 -fserver)

1,307,793.439

1,307,793.439

1,307,857.299

CnD remainder of Cn and

Cm

0.910305637 0.910305637 0.409153740

CnD integer value of CnD

ƩCnD accumulated value of CnD 127 127 127

Table 4-2 – Client and ZRx GMP parameter values

Where,

• Nominal client information bit rates for 400GE and 200GE are nominal 400GBASE-R and

200GBASE-R rates after RS(544,514) FEC and AM removal. Nominal client information bit rate for 100GE clients with FEC is the nominal 100GBASE-R rate after RS(544,514) FEC removal. For

100GE clients without FEC, it is the nominal 100GBASE-R rate after transcoding from 64B66B to

256B257B blocks.

• Server is ZR400, ZR200 or ZR100 4-frame multi-frame (both payload and overhead), with fserver nominal bit rate, ∆fserver bit rate tolerance and Bserver number of bits per server 4-frame multi-frame.

• Server payload is ZR400, ZR200 or ZR100 4-frame multi-frame payload (before AM/PAD/OH insert), with fp,server nominal bit rate, ∆fserver bit rate tolerance and Pserver number of bits per server 4-frame multi-frame payload area.

• The maximum number_of_m [=1028] bit GMP data entities per 4-frame multi-frame payload is

Pm,server [=10220, or 5110, or 2555].

• For ZR400, ZR200 or ZR100, we use n = [m / 128] = [4×257-bit]/128 = 8.03125 UI that is used as a phase unit “n-bit equivalent” for Cn parameter. Cn indicates the number of “n-bit equivalent” of the xGBASE-R client per ZRx 4-frame multi-frame server payload. It can be used as a finer phase indicator to encode the client clock at the GMP mapper.

• So, C n, nom

= 128 × C m, nom

; C n, min

= 128 × C m, min

C n, max = 128 × C m, max

• C

= Pm,server × [client_bit_rate / Server_Payload_bit_rate].

• C m is an integer value indicating to every ZRx frame the number of m-bit client blocks carried [m

= 4×257b = 1028b] in this ZRx 4-frame server multi-frame payload = int(Pm,server×[client_bit_rate/Server_Payload_bit_rate]).

• C m ≤ Pm,server and is a value varying between C m,min and C m,max for the given client and payload type, due to client and payload bit rate tolerance range (+/- 100 ppm and +/-20 ppm).

openzrplus.org 20

4.6 Stuffing Locations

Table 4-3 shows the location of the "stuff" GMP blocks for a few specific Cm values.

Cm Stuff Locations (index values of 4×257b locations in 4-frame multi-frame)

10220 N/A

10219 1

10218 1, 5111

10217 1, 3407, 6814

10216 1, 2556, 5111, 7666

10215 1, 2045, 4089, 6133, 8177

10216 1, 1704, 3407, 5111, 6814, 8517

Table 4-3 – GMP STUFF Locations of ZR400

5 Multiplexing

Multiplexing of 100G and 200G clients into the ZR400 frame is performed using simple time division multiplexing of the 257-bit blocks in the ZR payload. A ZR400 frame has four sets of overhead (OH) available in the first row to support multiplexing of GMP for up to four clients.

There are 10220 257-bit blocks in a ZR400 frame. This number is divisible by both 4 and

2. Row 1 has 20 blocks, while all other rows have 40 blocks. The ZR400 stuffing location uses some number of consecutive 257-bit blocks based upon ZR400 rate as shown in Table

4-1 – GMP Block Counts. The ZR400 frame has 4 unique OH chunks of 40 bytes. The

GMP six justification control bytes are distributed inside the OH using four consecutive frames. There are two GMP values processed during the 8-frame ZR400 multi-frame.

openzrplus.org 21

Figure 5-1 – 100G, and 200G Multiplexing in ZR400 Frame

5.1 ZR400 Frame Structure

The ZR400 frame structure is 10280b × 256 rows with 1920b columns of AM, 1920b columns of PAD, and 1280b of OH and 20-bits of additional pad located in row 1 bits 5121 through 5140. The additional pad is to align the payload area on a 257b boundary. Parity is added by the OFEC block and interleaver stages downstream of the ZR400 frame structure.

The ZR400 frame structure is shown in Figure 5-2.

Figure 5-2: ZR400- frame structure

• There are 10220 257-bit blocks in a ZR400 frame. This number is divisible by both 4 and 2.

200G/300G/400G

1x400G

1x200G

1x200G

100G

100G

100G

100G

GMP

GMP

GMP

GMP

HOST MODEM

Ethernet GMP

Bserver = 2626540

Fserver = 100425915477

Fclient = 100390625000

Pserver = 10220

Cm = 10216.409

• Justification Control JC1-JC6 is multiplexed in to

400ZR OH1-OH4

• Payload is 257b-block mulitplexed into the 400ZR payload TS1-TS4 using 4x257b data/stuffing locations

• 400ZR Frame Rate is tied to Modem rate before FEC inflation

400ZR

FRAME

400ZR OH

B

A

B

B

B

C

B

D

B

A

B

B

B

C

B

D

Columns

Frame

Payload area

AM PAD OH

Payload (5140 bits)

Payload (10280 bits)

Payload (10280 bits)

1920b 1280b 20b Pad openzrplus.org 22

• Row 1 has 20-blocks, all other rows have 40 blocks.

• The ZR400 stuffing location uses 4 consecutive 257-bit blocks.

• The ZR400 frame has 4 unique OH chunks of 40 bytes. The GMP is distributed across 4 consecutive frames in the 40-byte OH. There are 2 GMP values processed during the 8 frame

ZR400 multi-frame.

• Multiplexing scheme defines 4×100G and 2×200G.

• Cm/Cnd distributed across OH in 4 frames.

• Cm/Cnd value extracted in current 4 frame set used in next 4 frame set.

5.1.1 400G Container Multiplexing

This section describes how 100G, and 200G, clients are multiplexed in a ZR400 container.

For multiplexed signals, the AM, PAD, and OH from four frame/multi-frame aligned

ZR100 frames or from two frame/multi-frame aligned ZR200 frames and additional pad are 10-bit interleaved. The payload area is 257b interleaved.

This process is shown in Figure 5-3.

Figure 5-3: 4 Interleaved ZR100 frame to ZR400 frame structure

• 4 100G tributaries numbered T1, T2, T3, T4.

• 10220 257-block locations are numbered 1 through 10220, ordered left to right, top to bottom in ZR400 frame view.

• Each tributary assigned 2555 257-bit blocks.

• T1 consumes locations 1,5,9,…,10217

• T2 consumes locations 2,6,10,…,10218

• T3 consumes locations 3,7,11,…,10219

• T4 consumes locations 4,8,12,…,10220

• Simple round-robin ordering.

• 4 Unique 40-byte OH sections in each ZR400 frame, ordered left to right, in ZR400 frame view, numbered OH1, OH2, OH3, OH4

• 4×257-bit stuffing locations.

• Each 4×257-bit stuffing block divided into 4 stuffing locations numbered S1 through S4, ordered left to right in ZR400 frame.

• Each tributary assigned 1 257-bit block of stuffing.

Columns

Payload area

AM

rows

Payload area

ZR TS1

columns

AM OHPAD

OHPAD AM

rows

Payload area

ZR TS2

columns

AM OHPAD

rows

Payload area

ZR TS3

columns

AM OHPAD

rows

Payload area

ZR TS4

columns

AM OHPAD257b 257b 257b 257b 257b 257b 257b 257b

257b 257b257b 257b

257b

257b

257b

400G ZR Frame openzrplus.org 23

• T1 uses S1

• T2 uses S2

• T3 uses S3

• T4 uses S4

• Stuffing location defined by CM value of each OH.

• Every 4×257-bit stuffing location will have mix of data and stuff when multiplexing in play.

• 4 Unique OH numbered OH1, OH2, OH3, OH4.

• T1 uses OH1

• T2 uses OH2

• T3 uses OH3

• T4 uses OH4

5.1.2 1×400G Data Multiplexing

• 1 400G client numbered CL1.

• 400G client assigned all four tributaries.

• The GMP for the client is stored in the assigned overhead.

5.1.3 2×200G Data Multiplexing

• 2 200G clients numbered CL1, CL2.

• Each client assigned two tributaries and two corresponding overhead.

• Tributaries assigned to client need not be consecutive, but data is ordered with first data in time assigned to lower ordinal tributary.

• The GMP for the client is stored in the overhead with the lowest ordinal number.

5.1.4 4×100G Data Multiplexing

• 4 100G clients numbered CL1, CL2, CL3, CL4.

• Each client assigned one tributary and one corresponding overhead.

• The GMP for the client is stored in the overhead with the lowest ordinal number (OH1).

• Alignment markers are inserted in the 100G data stream to transparently pass the BIP3/BIP7 values across transport layer.

• The alignment marker follows the rules defined in 802.3 Clause 91 and G.709 Annex E with one exception.

• When looking at 802.3 Clause 91.5.2 Figure 91-4; the values in amp_tx_0,1,2,3,16,17,18,19 are replaced with the unique values for those 8 logical lanes, as defined by Clause 82.2.7 Table

82-2.

• The alignment markers consume 5 consecutive 257-bit blocks using the intervals defined in

Clause 91.

• The alignment markers are constructed using 128 10-bit symbols followed by the 5-bit pad as defined in Clause 91. The 128 10-bit symbols plus 5-bit pad combine to form 5 257-bit blocks.

• The order of the 10-bit symbols can be referenced using 802.3 Clause 91 Figure 91-4 with the symbols extracted top-to-bottom, left-to-right from the box in this figure with the 5-bit pad following at the end.

openzrplus.org 24

5.2 ZR300 Frame Structure

The ZR300 frame structure is 10280b × 192 rows with 1440b columns of AM, 1440b columns of PAD, and 960b of OH and 15-bits of additional pad located in row 1 bits 3841 through 3855. The additional pad is to align the payload area on a 257b boundary. Parity is added by the OFEC block and interleaver stages downstream of the ZR300 frame

The ZR300 frame structure is shown in Figure 5-4.

Figure 5-4: ZR300 frame structure

5.2.1 300G Container Multiplexing

This section describes how 100G and 300G clients are multiplexed in a ZR300 container.

For multiplexed signals, the AM, PAD, and OH, from three frame/multi-frame aligned

ZR100 frames and additional pad are 10b interleaved. The payload area is 257b interleaved.

This interleaving process is shown in Figure 5-5.

Figure 5-5: Three interleaved ZR100 frames to ZR300 frame structure

Payload area

AM PAD OH

Payload (6425 bits)

Payload (10280 bits)

Payload (10280 bits)

1440b 960b 15b Pad

Frame

Columns

Payload area

AM

rows

Payload area

ZR TS1

columns

AM OHPAD

rows

Payload area

ZR TS2

columns

AM OHPAD

rows

Payload area

ZR TS3

columns

AM OHPAD257b 257b 257b 257b 257b 257b

OHPAD AM 257b 257b257b

257b

257b257b openzrplus.org 25

• 3 100G tributaries numbered T1, T2, T3.

• 7665 257-block locations are numbered 1 through 7665, ordered left to right, top to bottom in

ZR400 frame view.

• Each tributary assigned 2555 257-bit blocks.

• T1 consumes locations 1,4,7,…,7663

• T2 consumes locations 2,5,8,…,7664

• T3 consumes locations 3,6,9,…,7665

• Simple round-robin ordering.

• 3 Unique 40-byte OH sections in each ZR300 frame, ordered left to right, in ZR300 frame view, numbered OH1, OH2, OH3.

• 3×257-bit stuffing locations.

• Each 3×257-bit stuffing block divided into 3 stuffing locations numbered S1 through S3, ordered left to right in ZR300 frame.

• Each tributary assigned 1 257-bit block of stuffing.

• T1 uses S1

• T2 uses S2

• T3 uses S3

• Stuffing location defined by CM value of each OH.

• Every 3×257-bit Stuffing location will have mix of data and stuff when multiplexing in play.

• 3 Unique OH numbered OH1, OH2, OH3.

• T1 uses OH1

• T2 uses OH2

• T3 uses OH3

5.2.2 3×100G Data Multiplexing

• 3 100G clients numbered CL1, CL2, CL3.

• Each client assigned one tributary and one corresponding overhead.

• The GMP for the client is stored in the assigned overhead.

• Alignment markers are inserted in the 100G data stream to transparently pass the BIP3/BIP7 values across transport layer.

• The alignment marker follows the rules defined in 802.3 Clause 91 and G.709 Annex E with one exception.

• When looking at 802.3 Clause 91.5.2 Figure 91-4; the values in amp_tx_0,1,2,3,16,17,18,19 are replaced with the unique values for those 8 logical lanes, as defined by Clause 82.2.7 Table

82-2.

• The alignment markers consume 5 consecutive 257-bit blocks using the intervals defined in

Clause 91.

• The alignment markers are constructed using 128 10-bit symbols followed by the 5-bit pad as defined in Clause 91. The 128 10-bit symbols plus 5-bit pad combine to form 5 257-bit blocks.

• The order of the 10-bit symbols can be referenced using 802.3 Clause 91 Figure 91-4 with the following at the end.

openzrplus.org 26

5.3 ZR200 Frame Structure

The ZR200 frame structure is a block format of 10280-bit columns × 128 rows with 960b columns of AM, 960b columns of PAD, and 640b of OH and 10-bits of additional pad located in row 1 bits 1921 through 2560. The additional pad is to align the payload area on a 257b boundary. Parity is added by the OFEC block and interleaver stages downstream of the ZR200 frame structure.

The ZR200 frame structure is shown in Figure 5-6.

Figure 5-6: ZR200 frame structure

5.3.1 200G Container Multiplexing

This section describes how 100G and 200G clients are multiplexed in a ZR200 container.

For multiplexed signals, the AM, PAD, and OH, from two frame/multi-frame aligned

ZR100 frames and additional pad are 10b interleaved. The payload area is 257b interleaved.

The interleaving process is shown in Figure 5-7.

Payload area

AM PAD OH

Payload (7710 bits)

Payload (10280 bits)

Payload (10280 bits)

960b 640b960b 10b Pad openzrplus.org 27

Figure 5-7: Two interleaved ZR100 frames to a ZR200 frame structure

• 2 100G tributaries numbered T1, T2.

• 5110 257-block locations are numbered 1 through 5110, ordered left to right, top to bottom in

ZR400 frame view.

• Each tributary assigned 2555 257-bit blocks.

• T1 consumes locations 1, 3, 5, …, 5109

• T2 consumes locations 2, 4, 6, …, 5110

• Simple round-robin ordering.

• 2 Unique 40-byte OH sections in each ZR400 frame, ordered left to right, in ZR400 frame view, numbered OH1, OH2.

• 2×257-bit stuffing locations.

• Each 2×257-bit stuffing block divided into 2 stuffing locations numbered S1 through S2, ordered left to right in ZR400 frame.

• Each tributary assigned 1 257-bit block of stuffing.

• T1 uses S1

• T2 uses S2

• Stuffing location defined by CM value of each OH.

• Every 2×257-bit Stuffing location will have mix of data and stuff when multiplexing in play.

• 2 Unique OH numbered OH1, OH2.

• T1 uses OH1

• T2 uses OH2

Columns

Payload area

AM

rows

Payload area

ZR TS1

columns

AM OHPAD

rows

Payload area

ZR TS2

columns

AM OHPAD257b 257b 257b 257b

OHPAD AM 257b 257b 257b

257b openzrplus.org 28

5.3.2 1×200G Data Multiplexing

• 1 200G client numbered CL1.

• 200G client assigned all two tributaries.

• The GMP for the client is stored in the assigned overhead.

5.3.3 2×100G Data Multiplexing

• 2 100G clients numbered CL1, CL2.

• Each client assigned one tributary and one corresponding overhead.

• The GMP for the client is stored in the overhead with the lowest ordinal number (OH1).

• The alignment marker follows the rules defined in 802.3 Clause 91 and G.709 Annex E with one exception.

• When looking at 802.3 Clause 91.5.2 Figure 91-4; the values in amp_tx_0,1,2,3,16,17,18,19 are replaced with the unique values for those 8 logical lanes, as defined by Clause 82.2.7 Table

82-2.

• The alignment markers consume 5 consecutive 257-bit blocks using the intervals defined in

Clause 91.

• The alignment markers are constructed using 128 10-bit symbols followed by the 5-bit pad as defined in Clause 91. The 128 10-bit symbols plus 5-bit pad combine to form 5 257-bit blocks.

• The order of the 10-bit symbols can be referenced using 802.3 Clause 91 Figure 91-4 with the symbols extracted top-to-bottom, left-to-right from the box in this figure with the 5-bit pad following at the end.

5.4 ZR100 frame structure

The ZR100 frame structure is similar to the FlexO-1 frame structure defined in G.709.1

(G.709.1/Y.1331(18)_F8-1) copied as Figure 5-8 for reference. FlexO is a block format of

5140-bit columns × 128 rows. The ZR100 frame structure in Figure 5-9 is also a block format of 5140-bit columns × 128 rows, however, it includes a 5-bit pad located in row 1 bits 1281 through 1285. The additional pad is to align the payload area on a 257b boundary.

Figure 5-8: FlexO frame structure (reference)

Columns

Payload area

AM PAD OH

Payload (3860 bits)

Payload (5140 bits)

Payload (5140 bits)

480b 320b480b openzrplus.org 29

Figure 5-9: ZR100 frame structure

5.4.1 100G Container Multiplexing

This section describes how 100G is multiplexed in a 100G ZR container.

• 1 100G tributaries numbered T1.

• 2555 257-bit block locations are numbered 1 through 2555, ordered left to right, top to bottom in ZR400 frame view.

• Each tributary assigned 2555 257-bit blocks.

• T1 consumes locations 1,2,3,…,2555

• 1 Unique 40 byte OH sections in each ZR400 frame, ordered left to right, in ZR400 frame view, numbered OH1.

• 1×257-bit stuffing locations numbered S1.

• Each tributary assigned 1 257-bit block of stuffing.

• T1 uses S1

• Stuffing location defined by CM value of each OH.

• 1 Unique OH numbered OH1.

• T1 uses OH1

5.4.2 1x100G Data Multiplexing

• 1 100G client numbered CL1.

• 1 100G tributaries numbered T1.

• 1 Unique OH numbered OH1.

• CL1 assigned tributary T1 and overhead OH1.

• The GMP for the client is stored in the overhead with the lowest ordinal number (OH1).

• The alignment marker follows the rules defined in 802.3 Clause 91 and G.709 Annex E with one exception.

• When looking at 802.3 Clause 91.5.2 Figure 91-4; the values in amp_tx_0,1,2,3,16,17,18,19 are replaced with the unique values for those 8 logical lanes, as defined by Clause 82.2.7 Table

82-2.

• The alignment markers consume 5 consecutive 257-bit blocks using the intervals defined in

Clause 91.

Payload area

AM PAD OH

Payload (3855 bits)

Payload (5140 bits)

Payload (5140 bits)

960b 640b 5b Pad openzrplus.org 30

• The alignment markers are constructed using 128 10-bit symbols followed by the 5-bit pad as defined in Clause 91. The 128 10-bit symbols plus 5-bit pad combine to form 5 257-bit blocks.

• The order of the 10-bit symbols can be referenced using 802.3 Clause 91 Figure 91-4 with the following at the end openzrplus.org 31

6 ZRx adaptation to OFEC

The ZRx frame structure is adapted to the OFEC Coder block by adding padding after every n × 10280-bit rows. The data stream is then scrambled and passed to the OFEC encoder. Table 6-1 shows the relationships between the OFEC-x Coder Payload and the

ZRx frame structure. The ZRx-OFEC is aligned and synchronized to the DSP frame, therefore the number of PAD bits, OFEC block and payload bits per DSP frame is modulation dependent.

ZRx Rows

PAD

(bits)

OFEC-x coder payload (bits)

OFEC

Blocks

ZRx (bits)

Modulation Format

ZR400 116 rows 992 1,193,472 168 1,376,256 16QAM

ZR300 87 rows 744 895,104 126 1,032,192 8QAM

ZR200 58 rows 496 596,736 84 688,128 QPSK

ZR100 116 rows 496 596,736 84 688,128 QPSK

Table 6-1: OFEC adaptation rates

The digital formatting and processing done by the DSP to adapt the FlexO-x to the OFEC

Coder is shown in Figure 6-1.

Figure 6-1: Digital processes of ZR-x to ZRx-OFEC adaptation.

6.1 Padding Insertion/Removal

The OFEC block processing is aligned and synchronized to the DSP super-frame (See

Section 9.1). Pad bits are appended to the ZRx framed data to enable this alignment. The

PAD is removed after the decoder on the receive interface. The PAD is an all-zero field that gets scrambled prior to encoding and removed after decoding and descrambling.

6.2 ZR400 adaptation to ZR400-OFEC-16QAM

For ZR400 adaptation to a ZR400-OFEC-16QAM line interface, 116 rows of ZR400 information (1,192,480 bits) plus 992 bits of pad (1,193,472 bits total) are scrambled and then bitwise demultiplexed to two OFEC encoders, each of which operate on input blocks

ZRx-OFEC-<modulation>

Padding ZR400 – 992b ZR300 – 744b ZR200 – 496b ZR100 – 496b

596240b

894360b

1192480b

ZR400 - 116 rows (4640 x 257b) ZR300 - 87 rows (3480 x 257b) ZR200 - 58 rows (2320 x 257b) ZR100 - 116 rows (2320 x 257b)

ZR

596736b

895104b

1193472b Scrambler 7104b

OFEC-x Coder Payload oFEC Interleaver Size = 172032b

DP-16QAM: 1376256b DP-8QAM: 1032192b DP-QPSK: 688128b

DP-16QAM (8x)

ZRx-OFEC

FAW, Counter, Reserved Symbols

FAW, Counter, Reserved Symbols

Insert 576 Symbols

172608

172608

Pilot insert with spacing 31

Pilot insert with spacing 31

32/31

178176

178176

X pol

Y pol

Polarization Distribution

172032

172032

H

V

344064Symbol Map

Scrambler

ENC0

ENC1

168x DP-16QAM 126x: DP-8QAM 84x: DP-QPSK

596240b 596736b openzrplus.org 32 of 3,552 bits and produce output blocks of 4096 bits. To process the 1,193,472 bits each encoder operates on 168 input blocks of 7104 bits.

Figure 6-2 shows the adaptation of the ZR400 frame structure to the OFEC input block

Figure 6-2: ZR400 adaptation to a ZR400-OFEC-16QAM line interface

6.3 ZR300 adaptation to ZR300-OFEC-8QAM

For ZR300 adaptation to an ZR300-OFEC-8QAM line interface 87 rows of ZR300 information (894,360 bits) plus 744 bits of pad (895,104 bits total) are scrambled and then bitwise demultiplexed to two OFEC encoders, each of which operate on input blocks of

3552 bits and produce output blocks of 4,096 bits. To process the 895,104 bits each encoder operates on 126 input blocks of 7104 bits.

Figure 6-3 shows the adaptation of the ZR300 frame structure to the OFEC input block structure.

Columns oFEC input block Payload area

(1,192,480 bits)

AM PAD OH

Payload (5160 bits)

Payload (10280 bits)

1920b 1280b1920b

AM PAD OH Payload (5160 bits)

1920b 1280b

11925 ro w s (Z

R4

0)

Payload information 3480x257-bit blocks

Scrambled Payload, and PAD 7104 bits

B1

B168

168 oFEC Coder Input Blocks

PAD (992b)

PAD (992b)

Scrambler Reset to 0xFFFF

PAD (992b) 116

PAD (992b)

20b Pad openzrplus.org 33

Figure 6-3: ZR300 adaptation to a ZR300-OFEC-8QAM line interface

6.4 ZR200 adaptation to ZR200-OFEC-QPSK

For ZR200 adaptation to an ZR200-OFEC-QPSK line interface 58 rows of ZR200 information (596,240 bits) plus 496 bits of pad (596,736 bits total) are scrambled and then bitwise demultiplexed to two OFEC encoders, each of which operate on input blocks of

3,552 bits and produce output blocks of 4,096 bits. To process the 596,736 bits each encoder operates on 84 input blocks of 7104 bits.

Figure 6-3 shows the adaptation of the ZR200 frame structure to the OFEC input block structure.

Columns

Payload area

(894,360 bits)

AM PAD OH

Payload (6800 bits)

Payload (10280 bits)

1440b 960b

AM PAD OH Payload (6800 bits)

Payload (10280 bits)

1440b 960b ro w s (Z

R3

0)

Payload information 3480x257-bit blocks

Scrambled Payload, and PAD 7104 bits

B1

B126

126 oFEC Coder Input Blocks

PAD (744b)

PAD (744b)

Scrambler Reset to 0xFFFF

PAD (744b) 87

PAD (744b)

15b Pad openzrplus.org 34

Figure 6-4: ZR200 adaptation to a ZR200-OFEC-QPSK line interface

6.5 ZR100 adaptation to OFEC input blocks

For ZR100 116 rows of information (596,240 bits) plus 496 bits of pad (596,736 bits total) are scrambled and then bitwise demultiplexed to two OFEC encoders, each of which operate on input blocks of 3,552 bits and produce output blocks of 4,096 bits. To process the 596,736 bits each encoder operates on 84 input blocks of 7104 bits.

Figure 6-3 shows the adaptation of the ZR100 frame structure to the OFEC input block structure and then to the encoder input block sequence.

rows

Payload area

(596,240 bits)

AM PAD OH Payload (7720 bits)

960b 640b960b r o w s (Z

R

Payload information 3480x257-bit blocks

Scrambled Payload, and PAD 7104 bits

B1

B84

84 oFEC Coder Input Blocks

PAD (496b)

PAD (496b)

Scrambler Reset to 0xFFFF

PAD (496b) 58

PAD (496b)

Columns

AM PAD OH

Payload (7720 bits)

960b 640b960b

10b Pad…