OTN Tutorial PDF

Preview

Summary

Copyright © 2010 IP Light 1 OTN Tutorial By: Leon Bruckman VP System Engineering [email protected] April, 2010 Copyright © 2010 IP Light 2 OTN Network Intra-domain Interfaces (IaDI) Carrier B domain Vendor B2 domain Vendor B1 domain NE NE NE NE Carrier A domain Interdomain Carrier C domain NE in...

Description

Copyright © 2010 IP Light

1

OTN Tutorial By: Leon Bruckman VP System Engineering [email protected] April, 2010 Copyright © 2010 IP Light

2

Intra-domain Interfaces (IaDI)

OTN Network Carrier B domain Vendor B2 domain

Vendor B1 domain NE NE

Carrier A domain NE

NE

NE

Interdomain interfaces (IrDI)

Carrier C domain NE

NE

NE

CPE

End-to-end OTN-standard service management Copyright © 2010 IP Light

CPE

3

OTN Layers ODU

OCh and OTU OMS

OTS

OMS

OTS

OTS OLA

OLA

MSTP

• • • • •

OADM

OTS

OADM

OADM

MSTP

OTS – Monitors optical span connections between NEs OMS – Monitors connections between NEs with optical multiplexing functions OCh – Transports client signals between 3R (Reamplification, Reshanping, Retiming) regeneration points OTU – Monitors electrical span connections between MultiService Transport Platforms (MSTPs) ODU – Monitors end-to-end client path Copyright © 2010 IP Light

4

Information Containment Relationships Frame Alignment

OTUk Specific Overhead

ODU and TCM Specific Overhead

OPUk Specific Overhe ad

OPU Payload (Client)

FEC

Client

OPUk

ODUk path

ODUk tandem connection OTUk section

OTUk OH

Client

OPUk OH

OPUk

ODUk PM OH

ODUk

ODUk TCM OH

ODUk

FEC

OTUk = OCh Payload

Copyright © 2010 IP Light

5

OTM-n.m Information Containment

OMU-n.m

OTM-n.m

OTM Comms

OCC0

...

OTUk = OCh Payload

OCC0

OCC0

OCh OH

OCC0

OCG-n.m

OCC0

OCh

OCCp

OCCp

OCCp

OMSn OH

OMSn Payload

OTSn OH

OTSn Payload

………..

OCCp

OCCp

OOS OTM: Optical Transport Module OCG: Optical Carrier Group OMU: Optical Multiplex Unit OOS: OTM Overhead Signal OCC: Optical Channel Carrier

n : used to represent the order of the OTM, OTS, OMS, OPS, OCG, OMU. n represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. m : used to represent the bit rate or set of bit rates supported on the interface. This is one or more digits "k", where each "k" represents a particular bit rate.

Copyright © 2010 IP Light

6

Information Containment Relationships • OTM-0.m – Single channel without an assigned specific color OChr

OTUk = OCh Payload

OTM-0.m

OPS0

 OTM-nr.m – OTM Interface with reduced functionality OTUk = OCh Payload

OChr

OCG-nr.m

OTM-nr.m

OCCp

OCCp

………..

OCCp

OCCp

OCCp

OPSn

Copyright © 2010 IP Light

7

OTM-0.mvn Information Containment Relationships OTUk section

OT Lanes

OTLCG

OTM-0.mvn

ODUk

OTUk OH

FEC

OTLk.n #0

OTLk.n #1

…………………………..

OTLk.n #n-1

OTLCp

OTLCp

…………………………..

OTLCp

OPSMnk

OTLCG: Optical Transport Lane Carrier Group Copyright © 2010 IP Light

8

Adaptation of OTU3/4 over Multichannel I/F •

This mechanism is designed to allow the use of the optical modules being developed for IEEE 40GBASE-R and 100GBASE-R signals for short-reach client-side OTU3 and OTU4 interfaces, respectively.

•

OTU3 signals may be carried over parallel interfaces consisting of four lanes.

•

OTU4 signals may be carried over parallel interfaces consisting of four or ten lanes, which are formed by bit multiplexing of 20 logical lanes.

•

The OTU3 and OTU4 frames are inversely multiplexed over physical/logical lanes on a 16-byte boundary aligned with the OTUk frame –

The OTUk frame is divided into 1020 groups of 16-bytes. 1

4080

1

1:16 (FAS)

17:32

33:48

49:64

………………………

4065:4080

2

4081:4096

4097:5012

5013:5028

5029:5044

………………………

9145:9160

3

9161:9176

9177:9192

9193:9208

9209:9224

………………………

12225:12240

4

12241:12256

12257:12272

12273:12288

12289:13304

………………………

16305:16320

Copyright © 2010 IP Light

9

OTU3 16-byte Increment Frame Distribution • • • • •

Each 16-byte increment of an OTU3 frame is distributed, round robin, to each of the four physical lanes. On each OTU3 frame boundary, the lane assignments are rotated. OTU3 lane rotation and assignment is determined by the two LSB of the MFAS The pattern repeats every 64 bytes until the end of the OTU3 frame. The following frame will use a different lane assignment according to the MFAS. The two LSB of the MFAS will be the same in each FAS on a particular lane, which allows the lane to be identified. Since the MFAS cycles through 256 distinct values, the lanes can be deskewed and reassembled by the receiver as long as the total skew does not exceed 127 OTU3 frame periods (approximately 385s). MFAS=xxxxxx00

Rotate

MFAS=xxxxxx01

Rotate

MFAS=xxxxxx10

Rotate

MFAS=xxxxxx11

Rotate

Lane 0

1:16 (FAS)

65:80

16247:16262

49:64

16305:16320

33:48

16289:16304

17:32

16263:16288

Lane 1

17:32

81:96

16263:16288

1:16 (FAS)

16247:16262

49:64

16305:16320

33:48

16289:16304

Lane 2

33:48

97:112

16289:16304

17:32

16263:16288

1:16 (FAS)

16247:16262

49:64

16305:16320

Lane 3

49:64

113:128

16305:16320

33:48

16289:16304

17:32

16263:16288

1:16 (FAS)

16247:16262

Copyright © 2010 IP Light

10

OTU4 16-byte Increment Distribution • • • •

Each 16-byte increment of a frame is distributed, round robin, to each of the 20 logical lanes. On each frame boundary, the lane assignments are rotated. Since only 32 out of 48 bits of the FAS are checked for frame alignment, the 3rd OA2 byte position is assigned as a logical lane marker (LLM). Since 240 is the largest multiple of 20 that can be represented by 8 bits in order to maximize skew detection range the lane marker value will increment on successive frames from 0-239. In mapping from lanes back to the OTU4 frame, the 6th byte of each OTU4 frame which was borrowed for lane marking is restored to the value OA2. LLM MOD 20 = 0

Rotate

LLM MOD 20 = 1

Rotate

Rotate

Rotate LLM MOD 20 = 18

LLM MOD 19 = 0

Lane 0

1:16 (FAS)

321:33 6

16001:1601 6

305:320

33:48

16033:160 48

17:32

16017:1603 2

1:16 (FAS)

Lane 1

17:32

337:35 2

16017:1603 2

1:16 (FAS)

49:64

16049:160 64

33:48

16033:1604 8

17:32

Lane 18

289:304

609:62 4

16289:1630 4

273:288

1:16 (FAS)

16001:160 16

305:320

16305:1632 0

289:304

Lane 19

305:320

625:64 0

16305:1632 0

289:304

17:32

16017:160 32

1:16 (FAS)

16001:1601 6

305:320

Copyright © 2010 IP Light

11

OTM0.mvn

OPSMn4

x1

OTLCG

xn

OTLC

OPSMn3

x1

OTLCG

xn

OTLC

OPS0

x1

OTM-0.m

OPSn

OTM-nr.m

OCG-nr.m

x1

OTSn

OMSn

OCGn.m

OTS OH x1

OTL3.n

x1

X1/n

OChr

x1

OChr

x1

x1

OChr

x1

OCC

x1

OCh

xl xi xj

OCC

x1

OCh

xk

OCC

xl xi xj

1≤ l+i+j+k ≤ n

OTM-n.m

x1

X1/n

x1

xk

1≤ l+i+j+k ≤ n

OTL4.n

OChr

OCCr

x1

x1

OCCr

OCCr OCCr

OMS OH

OCC

x1

x1

OTU4

OTU3

x1

OTU2 x1

x1

OCh

x1

x1

OCh

x1

OTU1

OCh OH OSC

x1

OTM Overhead Signal (OOS)

Copyright © 2010 IP Light

12

1

OTUk FEC

1

3824

ODUk

2 3 4 14

1 1

FAS

3824

OTUk OH

4080

OTUk FEC

2

RS(239,255) or all zeros

3 4

4 x 256 bytes

 The OTUk forward error correction (FEC) contains the Reed-Solomon RS(255,239) FEC codes.  If no FEC is used, fixed stuff bytes (all-0s pattern) are to be used.

 For interworking of FEC with non-FEC equipment, the FEC supporting equipment shall disable the FEC decoder and ignore the FEC area.

Copyright © 2010 IP Light

13

FEC Sub-Rows Information bytes 1

Parity Check bytes

……………………………………..……………… . . .

Information bytes 1

Parity Check bytes

……………………………………..………………

2 2 3 4 9 0

Information bytes 1

2 2 3 4 9 0

FEC sub-row #2

………………………

………………………

………………………

FEC sub-row #1 2 5 5

Information bytes 1 2

• • •

………………………

FEC sub-row #16 2 5 5

2 5 5

Parity Check bytes

……………………………………..………………

2 2 3 4 9 0

3 8 2 4

16

OTU row

Parity Check bytes 3 8 2 5

3 8 2 6

3 ……… 8 ……………………… 4 0

4 0 8 0

The forward error correction for the OTU-k uses 16-byte interleaved codecs using a ReedSolomon S(255,239) code. The RS(255,239) code operates on byte symbols. The FEC can correct up to 8 symbol errors in the FEC code word. The FEC can detect up to16 symbol errors in the FEC code word in error detection mode. Copyright © 2010 IP Light

14

Enhanced FECs – Super FECs - Defined in ITU-T G.975.1 - Forward Error Correction for DWDM submarine systems. - Defines super FEC codes that have higher correction ability than RS (255,239). - Performance parameters for super FEC codes: – Correction ability – Redundancy ratio – Latency Super FEC decoder

Super FEC encoder

First FEC encoding

Second FEC encoding

EO/Fiber/OE

Second FEC decoding

First FEC encoding

Inner code Outer code

Copyright © 2010 IP Light

15

Correction Strength •

BER characteristics –

•

Coding Gain –

•

BER characteristic for FEC: Decoder input signal BER / Corrected output signal BER. • BER improvement by FEC indicates the FEC correction ability. For randomly distributed errors within the encoded line signal, a FEC decoder reduces the line BERin (Bin) to a required reference BER (Bref) value within the payload signal. • Coding gain accordingly is defined as Bin / Bref.

Net Coding Gain (NCG) Code Rate: The code rate R is the ratio of bit rate without FEC to bit rate with FEC, R OPU0 rate (1239 Kbps)

•

The GBE signal (8B/10B coded, nominal bit rate of 125000 Kbps and a bit rate tolerance up to ±100ppm) has to be synchronously mapped into a 75-octet GFP-T frame stream with a bit rate of 15/16 x 1250000 Kbps ±100ppm (approximately 1171875 Kbps ±100ppm).

•

This process is referred to as “timing transparent transcoding (TTT)”.

•

The 15/16 x 1250000 Kbps ±100 ppm signal is then mapped into an OPU0 by means of the generic mapping procedure

1.25G GBE

8B/10B

64/65 Blocks

GFP-T

GMP

OPU0

TTT

Copyright © 2010 IP Light

52

Adapting 8B/10B Signals via 64B/65B Block Codes Input client character

Flag bit

64-bit (8-Octet) field

All data

0

D1

D2

D3

D4

D5

D6

D7

D8

7 data, 1 control

1

0 aaa C1

D1

D2

D3

D4

D5

D6

D7

6 data, 2 control

1

1 aaa C1

0 bbb C2

D1

D2

D3

D4

D5

D6

5 data, 3 control

1

1 aaa C1

1 bbb C2

0 ccc C3

D1

D2

D3

D4

D5

4 data, 4 control

1

1 aaa C1

1 bbb C2

1 ccc C3

0 ddd C4

D1

D2

D3

D4

3 data, 5 control

1

1 aaa C1

1 bbb C2

1 ccc C3

1 ddd C4

0 eee C5

D1

D2

D3

2 data, 6 control

1

1 aaa C1

1 bbb C2

1 ccc C3

1 ddd C4

1 eee C5

0 fff C6

D1

D2

1 data, 7 control

1

1 aaa C1

1 bbb C2

1 ccc C3

1 ddd C4

1 eee C5

1 fff C6

0 ggg C7

D1

8 control

1

1 aaa C1

1 bbb C2

1 ccc C3

1 ddd C4

1 eee C5

1 fff C6

1 ggg C7

0 hhh C8

– Leading bit in a control octet (LCC) = 1 if there are more control octets and = 0 if this payload octet contains the last control octet in that block – aaa = 3-bit representation of the 1st control code's original position (1st Control Code Locator) – bbb = 3-bit representation of the 2nd control code's original position (2nd Control Code Locator) ... – hhh = 3-bit representation of the 8th control code's original position (8th Control Code Locator) – Ci = 4-bit representation of the ith control code (Control Code Indicator) – Di = 8-bit representation of the ith data value in order of transmission D 1

C 2

C 3

D 4

D 5

C 6

D 7

C 8

Flag 1

Copyright © 2010 IP Light

1001 c2

1010 c3

1101 c6

0111 c8

D1

D4

D5

D7

53

Adapting 64B/65B Block Codes into GFP Octet 1, 1 Octet 1,2

Payload Length Indication (PLI)

1

=0x47 (71 decimal)

1

Octet 1,3

cHEC

1 1

. . . . . . . .

67 bytes

1

1 1 1

Octet 8,7

PTI=000

0

EXI=0000

User Payload Identifier (UPI) =0x06 tHEC

Payload

Octet 8,8 L1

L2

L3

L4

L5

L6

L7

L8

CRC-1

CRC-2

CRC-3

CRC-4

CRC-5

CRC-6

CRC-7

CRC-8

CRC-9

CRC-10

CRC-11

CRC-12

CRC-13

CRC-14

CRC-15

CRC-16

where: Octet j, k is the kth octet of the jth 64B/65B code in the superblock Lj is the leading (Flag) bit jth 64B/65B code in the superblock CRC-i is the ith error control bit where CRC-1 is the MSB of the CRC

Copyright © 2010 IP Light

54

RES

JC1

RES

JC2

RES

JC3

PSI

RES

Mapping GFP-T into OPU0 Core Header

Core Header

Core Header

C. Header

S

S

S

Type Header

Type Header

Type

S

Type Header

S

S

S S

Hdr

• Since the OPU0 payload less the stuff bytes rate is equal to the GFP-T rate there is no need for: – GFP-T special 65B_PAD – GFP-T Idle frames

• 14405 ≤ C8 ≤ 14410 Copyright © 2010 IP Light

55

Mapping Sub-1.238 Gbps CBR Signals into OPU0 •

1GFC rate (1062500 Kbps) < OPU0 rate (1238954 Kbps), no transcoding is required OPU0 payload byte

Stuff

10 bit 1GFC character Client Signal

Nominal rate [Kbps]

Tolerance [ppm]

Floor C8

Ceiling C8

C1D range

1GFC

1062500

±100

13601

13605

NA

STM-1

155520

±20

1911

1913

0 to +7

STM-4

622080

±20

7647

7649

0 to +7

Copyright © 2010 IP Light

56

Frame Mapped Ethernet 7

Preamble

1

Start of Frame Delimiter

6

MAC DA

6

MAC SA

2

Length/Type

2

PLI

2

cHEC

2

Type

2

tHEC

GFP Payload Payload

4

•
<...