Optical Transport Network (OTN) Tutorial

Transcription

Optical Transport Network (OTN) TutorialDisclaimer:This is a Tutorial.This is NOT a Recommendation!This tutorial has no standards significance. It is purelyfor educational purposes. In case of conflict between thematerial contained in the tutorial and the material ofthe relevant Recommendation the latter always prevails.This tutorial should NOT be used as a reference; onlythe relevant Recommendations can be referenced.SummaryThis document provides a tutorial for Optical Transport Network standards and their applications.The objective is to provide the telecommunications engineers with a document that forms the basisfor understanding OTN.Contact:Timothy P. WalkerAMCCUSATel: 1-978-247-8407Fax:Email: twalker@amcc.com

-2-1Scope.52Abbreviations.53What is OTN/OTH.73.1OTN Standards .74Where is it standardized for .85Why use OTN.85.1Forward Error Correction (FEC) .85.1.1Theoretical Description .95.1.2Coding Gain.115.2Tandem Connection Monitoring .145.3Transparent Transport of Client Signals.175.4Switching Scalability.176OTN Hierarchy Overview .187OTUk, ODUk, OPUk Frame Structure.208OPUk Overhead and Processing.218.1OPUk Overhead Byte Descriptions .228.1.1Payload Structure Identifier (PSI) .228.1.2Payload Type (PT).228.2Mapping Signals into an OPUk.228.2.1Frequency Justification.238.2.2Mapping a CBR2G5 signal (e.g. STM-16) into OPU1 .258.2.3Mapping a CBR10G signal (e.g. STM-64) into OPU2 .268.2.4Mapping a CBR40G signal (e.g. STM-256) into OPU3 .269ODUk Overhead and Processing .279.1Path Monitoring (PM) Byte Descriptions.299.1.1Trail Trace Identifier (TTI).299.1.2BIP-8.299.1.3Backward Defect Indication (BDI).299.1.4Backward Error Indication and Backward Incoming Alignment Error(BEI/BIAE).309.1.5Path Monitoring Status (STAT) .309.2Tandem Connection Monitoring (TCM) .309.2.1Trail Trace Identifier (TTI).309.2.2BIP-8.319.2.3Backward Defect Indication (BDI).31

-3-9.2.49.2.59.2.69.2.79.2.89.2.9Backward Error Indication and Backward Incoming Alignment Error(BEI/BIAE).31TCM Monitoring Status (STAT) .32Tandem Connection Monitoring ACTivation/deactivation (TCM-ACT) .33General Communication Channels (GCC1, GCC2).33Automatic Protection Switching and Protection Communication Channel(APS/PCC).33Fault Type and Fault Location reporting communication channel (FTFL) .3310OTUk Overhead and Processing.3310.1Scrambling.3410.2Frame Alignment Overhead .3510.2.1 Frame alignment signal (FAS) .3510.2.2 Multiframe alignment signal (MFAS).3510.3SM Byte Descriptions.3610.3.1 Trail Trace Identifier (TTI).3710.3.2 BIP-8.3710.3.3 Backward Defect Indication (BDI).3810.3.4 Backward Error Indication and Backward Incoming Alignment Error(BEI/BIAE).3810.3.5 Incoming Alignment Error (IAE) .3910.4General Communication Channel 0 (GCC0).3911ODUk Multiplexing.3911.1Multiplexing Data Rates.3911.1.1 ODU1 to ODU2 Justification Rate .3911.1.2 ODU2 to ODU3 Justification Rate .4011.1.3 ODU1 to ODU3 Justification Rate .4011.24 x ODU1 to ODU2 Multiplexing.4111.2.1 4 x ODU1 to ODU2 Multiplexing Structure .4111.2.2 4 x ODU1 to ODU2 Justification Structure.4311.2.3 OPU2 Payload Structure Identifier (PSI) .4411.2.4 OPU2 Multiplex Structure Identifier (MSI) .4411.2.5 Frequency Justification.4511.3ODU1/ODU2 to ODU3 Multiplexing .4611.3.1 ODU1/ODU2 to ODU3 Multiplexing Structure .4611.3.2 ODU1/ODU2 to ODU3 Justification Structure.4811.3.3 OPU3 Payload Structure Identifier (PSI) .4911.3.4 OPU3 Multiplex Structure Identifier (MSI) .4911.3.5 Frequency Justification.5011.4Maintenance Signal Insertion .51

1.5.511.5.611.5.711.5.8Client source ODUk-AIS.51Client source ODUk-OCI .51Line source ODUk-AIS .51Defect detection and correlation.52dPLM (Payload Mismatch) .52cPLM .52dMSIM (Multiplex Structure Identifier Mismatch supervision) .53cMSIM.53dLOFLOM (Loss of Frame and Multiframe) .53cLOFLOM.54aAIS (AIS insertion) .54SSF (Server Signal Fail).5412ODUk Virtual Concatenation / OTN over SONET .5513Synchronisation .5513.1Introduction .5513.2Network requirements .5513.3Mapping and Multiplexing .5713.4Equipment requirements .5714OTN Maintenance Signals.5714.1OTUk maintenance signals.5714.1.1 OTUk alarm indication signal (OTUk-AIS).5714.2ODUk maintenance signals .5814.2.1 ODUk Alarm Indication Signal (ODUk-AIS).5814.2.2 ODUk Open Connection Indication (ODUk-OCI).5814.2.3 ODUk Locked (ODUk-LCK) .5914.3Client maintenance signal.5914.3.1 Generic AIS for constant bit rate signals.5915OTN Defects .6016Acknowledgements.6117Bibliography .6118Open Issues.6218.1ODUk Virtual Concatenation / OTN over SONET.62

-5-1ScopeThis document provides a tutorial for Optical Transport Network standards and their applications. Theobjective is to provide the telecommunications engineers with a document that forms the basis forunderstanding OTN.2AbbreviationsThis tutorial uses the following abbreviations:0xYYYY is a value in hexadecimal presentation3RReamplification, Reshaping and RetimingACTActivation (in the TCM ACT byte)AIAdapted InformationAISAlarm Indication SignalAPSAutomatic Protection SwitchingBDIBackward Defect IndicationBEIBackward Error IndicationBIAEBackward Incoming Alignment ErrorBIPBit Interleaved ParityCBRConstant Bit RateCICharacteristic InformationCMConnection MonitoringCRCCyclic Redundancy CheckDAPIDestination Access Point IdentifierEXPExperimentalExTIExpected Trace IdentifierFASFrame Alignment SignalFDIForward Defect IndicationFECForward Error CorrectionGCCGeneral Communication ChannelIaDIIntra-Domain InterfaceIAEIncoming Alignment ErrorIrDIInter-Domain InterfaceJOHJustification OverheadLSBLeast Significant BitMFASMultiFrame Alignment SignalMFIMultiframe IndicatorMSMaintenance Signal

-6-MSBMost Significant BitMSIMultiplex Structure IdentifierNNINetwork Node InterfaceOChOptical channel with full functionalityOCIOpen Connection IndicationODUOptical Channel Data UnitODUkOptical Channel Data Unit-kODTUjkOptical channel Data Tributary Unit j into kODTUGOptical channel Data Tributary Unit GroupODUk-Xv X virtually concatenated ODUk'sOHOverheadOMSOptical Multiplex SectionOMS-OH Optical Multiplex Section OverheadOMUOptical Multiplex UnitONNIOptical Network Node InterfaceOOSOTM Overhead SignalOPSOptical Physical SectionOPUOptical Channel Payload UnitOPUkOptical Channel Payload Unit-kOPUk-Xv X virtually concatenated OPUk'sOSCOptical Supervisory ChannelOTHOptical Transport HierarchyOTMOptical Transport ModuleOTNOptical Transport NetworkOTSOptical Transmission SectionOTS-OHOptical Transmission Section OverheadOTUOptical Channel Transport UnitOTUkOptical Channel Transport Unit-kPCCProtection Communication ChannelPMPath MonitoringPMIPayload Missing IndicationPMOHPath Monitoring OverHeadppmparts per millionPRBSPseudo Random Binary SequencePSIPayload Structure IdentifierPTPayload Type

-7-RESReserved for future international standardizationRSReed-SolomonSAPISource Access Point IdentifierSkSinkSMSection MonitoringSMOHSection Monitoring OverHeadSoSourceTCTandem ConnectionTCMTandem Connection MonitoringTSTributary SlotTxTITransmitted Trace IdentifierUNIUser-to-Network InterfaceVCGVirtual Concatenation GroupVCOHVirtual Concatenation OverheadvcPTvirtual concatenated Payload Type33.1What is OTN/OTHOTN StandardsThere are many standards that fall under the umbrella of “OTN”. This document focuses on Layer 1standards. Therefore, it does not describe the Physical or Optical layers. Furthermore, it doesn’tdescribe any layers implemented in Software. Thus this document only describes the digital layer thatcould be implemented in ASIC.The Optical Transport Hierarchy OTH is a new transport technology for the Optical Transport NetworkOTN developed by the ITU. It is based on the network architecture defined in ITU G.872 "Architecturefor the Optical Transport Network (OTN)"G.872 defines an architecture that is composed of the Optical Channel (OCh), Optical MultiplexSection (OMS) and Optical Transmission Section (OTS). It then describes the functionality thatneeded to make OTN work. However, it may be interesting to note the decision made during G.872development as noted in Section 9.1/G.872 :“During the development of ITU-T Rec. G.709, (implementation of the Optical Channel Layeraccording to ITU-T Rec. G.872 requirements), it was realized that the only techniques presentlyavailable that could meet the requirements for associated OCh trace, as well as providing anaccurate assessment of the quality of a digital client signal, were digital techniques .”“For this reason ITU-T Rec. G.709 chose to implement the Optical Channel by means of a digitalframed signal with digital overhead that supports the management requirements for the OChlisted in clause 6. Furthermore this allows the use of Forward Error Correction for enhancedsystem performance. This results in the introduction of two digital layer networks, the ODU andOTU. The intention is that all client signals would be mapped into the Optical Channel via theODU and OTU layer networks.”Currently there are no physical implementations of the OCh, OMS and OTS layers. As they are definedand implemented, they will be included in this tutorial.

-8-Thus the main implementation of OTH is that described in G.709 and G.798.4Where is it standardized forThe optical transport network architecture as specified in ITU-T G.872 defines two interface classes: Inter-domain interface (IrDI); Intra-domain interface (IaDI).The OTN IrDI interfaces are defined with 3R processing at each end of the interface. This would be theinterface between Operators. It could also be thought of as the interface between different Vendorswithin the same Operator (see Figure 1).UserInter-DomainIrDI3ROperator A3RIntra-DomainIaDIInter-DomainIrDI3ROperator aDIUser3RIntra-DomainIaDIFigure 1 IaDI vs. IrDIThe IaDI is the interfaces within an Operator or a Vendor domain.G.709 applies to information transferred across IrDI and IaDI interfaces. G.709 compliance by itself isnot sufficient to guarantee mid-span meet, since it doesn’t specify the electrical or optical interfaces. Itis important to note that G.709 only defines logical interfaces.5Why use OTNOTN offers the following advantages relative to SONET/SDH: Stronger Forward Error Correction More Levels of Tandem Connection Monitoring (TCM) Transparent Transport of Client Signals Switching ScalabilityOTN has the following disadvantages: Requires new hardware and management systemWe will discuss the advantages and disadvantages in the following sections.5.1Forward Error Correction (FEC)Forward error correction is a major feature of the OTN.Already SDH has a FEC defined. It uses undefined SOH bytes to transport the FEC check informationand is therefore called a in-band FEC. It allows only a limited number of FEC check information,which limits the performance of the FEC.

-9-For the OTN a Reed-Solomon 16 byte-interleaved FEC scheme is defined, which uses 4x256 bytes ofcheck information per ODU frame. In addition enhanced (proprietary) FEC schemes are explicitlyallowed and widely used.FEC has been proven to be effective in OSNR limited systems as well as in dispersion limited systems.As for non-linear effects, reducing the output power leads to OSNR limitations, against which FEC isuseful. FEC is less effective against PMD, however.G.709 defines a stronger Forward Error Correction for OTN that can result in up to 6.2 dBimprovement in Signal to Noise Ratio (SNR). Another way of looking at this, is that to transmit asignal at a certain Bit Error Rate (BER) with 6.2 dB less power than without such an FEC.The coding gain provided by the FEC can be used to:- Increase the maximum span length and/or the number of spans, resulting in an extended reach. (Notethat this assumes that other impairments like chromatic and polarization mode dispersion are notbecoming limiting factors.)- Increase the number of DWDM channels in a DWDM system which is limited by the output power ofthe amplifiers by decreasing the power per channel and increasing the number of channels.(Note that changes in non-linear effects due to the reduced per channel power have to be taken intoaccount.)- Relax the component parameters (e.g launched power, eye mask, extinction ratio, noise figures, filterisolation) for a given link and lower the component costs.- but the most importantly the FEC is an enabler for transparent optical networks:Transparent optical network elements like OADMs and PXCs introduce significant optical impairments(e.g. attenuation). The number of transparent optical network elements that can be crossed by an opticalpath before 3R regeneration is needed is therefore strongly limited. With FEC a optical path can crossmore transparent optical network elements.This allows to evolve from today’s point-to-point links to transparent, meshed optical networks withsufficient functionality.Note: There is additional information on FEC in Section 11 of sup.dsn Also Appendix 1 of G.975.1lists some additional Enhanced FEC schemes.5.1.1Theoretical DescriptionG.709 FEC implements a Reed-Solomon RS(255,239) code. A Reed-Solomon code is specified asRS(n,k) with s-bit symbols where n is the total number of symbols per codeword, k is the number ofinformation symbols, and s is the size of a symbol. A codeword consists of data and parity, also knownas check symbols, added to the data. The check symbols are extra redundant bytes used to detect andcorrect errors in a signal so that the original data can be recovered.For G.709:s Size of the symbol 8 bitsn Symbols per codeword 255 bytesk Information symbols per codeword 239 bytesA typical system is shown in Figure 2:

- 10 -Figure 2 FEC Block DiagramThis means the encoder takes k information symbols of s bits, each, and adds check symbols to makean n-symbol codeword. There are n-k check symbols of s bits, each. A Reed-Solomon decoder cancorrect up to t symbols that contain errors in a codeword, where 2t n-k.The following Figure 3 shows a typical Reed-Solomon codeword:Figure 3 Reed-Solomon CodewordFor the standard ITU recommended RS (255,239) code:2t n - k 255 - 239 16t 8Hence, the decoder can correct any 8 symbols in a codewordReed-Solomon codes treat errors on a symbol basis; therefore, a symbol that contains all bits in error isas easy to detect and correct as a symbol that contains a single bit-error. That is why the Reed-Solomoncode is particularly well suited to correcting burst errors (where a series of bits in the codeword arereceived in error by the decoder.)Given a symbol size s, the maximum codeword length (n) for a Reed-Solomon code isn 2s – 1 255Interleaving data from different codewords improves the efficiency of Reed-Solomon codes becausethe effect of burst errors is shared among many other codewords. By interleaving, it spreads the impactof a noise burst over multiple symbols, which come from several codewords. As long as eachdeinterleaved codeword has fewer errors than it can correct, the interleaved group of codewords will becorrected. It is possible that some codewords will be corrected and some not if excessive errors areencountered.Interleaving actually integrates the error correction powers of all of the codewords included in theinterleaved group, that is the depth of the interleaver. This allows a higher rate of code and channelefficiency and still protects against an occasional very long error. For example, if 64 codewords thatcan correct 8 errors each are interleaved, the interleaved group can correct almost any combination ofsymbol errors that total less than 512. It does not matter if all 512 are in one long burst, there are 512

- 11 -one-symbol errors, or anywhere in between. Both ITU-T G.709 and ITU-T G.975 specify interleavingas part of the transport frame to improve error-correction efficiency.5.1.2Coding GainThe advantage of using FEC is that the probability of an error remaining in the decoded data is lowerthan the probability of an error if an FEC algorithm, such as Reed-Solomon, is not used. This is codinggain in essence.Coding Gain is difference in Input SNR for a given Output BER. The Input SNR is measured either as“Q factor” or as Eb/N0 (Section 5.1.2.2), or OSNR ().The “Net Coding Gain” takes into effect that there was a 7% rate expansion due to the FEC. What thismeans is that the data rate had to increase by 7% in order to transmit both the data and the FEC.5.1.2.1 Coding Gain measured via Q FactorThe widely used technique of measuring coding gain is the Q-factor (Quality factor) measurement. Thistechnique estimates the OSNR at the optical amplifier or receiver by measuring BER vs. voltagethreshold at voltage levels where BER can be accurately determined (see Figures 4 and 5). In reality,however, Q-factor is derived from the measurement of the eye-pattern signal. It is defined as the ratioof peak-to-peak signal to total noise (conventionally electrical):Figure 4 Eye Diagramu1 ON level average valueσ 1 ON level noise standard deviationu0 OFF level average valueσ 0 OFF level noise standard deviationA system that requires an operating BER of 10 -15 has a Q-factor measurement of 18 dB without FEC IfRS(255, 239) FEC is employed, the Q-factor measurement decreases to 11.8 dB, yielding 6.2 dB ofcoding gain.

- 12 -BER vs Q for R-S 255 Code (t 8)1.0E-03BER inBER out1.0E-06No 121314151617181920Q (dB)Figure 5 BER vs. Q FactorThe 6.2 dB gained through FEC would allow a transmission with longer span while maintaining theoriginal BER. Thus the transmission distance is improved with relatively small increase insemiconductor content.5.1.2.2 Coding Gain measured via Eb/N0Another way to measure coding gain is with a plot of BER vs. Eb/N0. Eb is the bit energy and can bedescribed as signal power (S) times the bit time Tb. N 0 is the noise power spectral density and can bedescribed as the noise power (N) divided by the bandwidth (W). Thus Eb/N0 is equal to SNR *(Bandwidth/Bit Rate). For a more thorough discussion see [Sklar]

- 13 .709-8-9-10-11101010-125.86 dB-13-1410106.2 dB-1523456789Eb/No101112131415Figure 6 BER vs E b/N0What Figure 6 shows is that for a given input SNR (Eb/N0), what the BER out of the FEC decoderwould be. Thus if one wanted to operate their system at 10-13 BER, then they would need over 14 dBSNR without FEC or only 8.5 dB with FEC.5.1.2.3 Coding Gain measured via OSNRFigure 7 shows the FEC net coding gain (NCG) of various FEC schemes. These are theoretical and realmeasurements results from running systems.Coding gain is the reduction of signal-to-noise ratio due to the use of the FEC at a reference BERThe Net Coding Gain (NCG) takes into account the fact that the bandwidth extension needed for theFEC scheme is associated with increased noise in the receiver.For example consider a reference BER of 10-15. The SDH in-band FEC provides a NCG of 4 dB. Thestandard OTN FEC a NCG of 6.2 dB and a enhanced FEC a NCG of 9.5 dB.

- 14 -UnencodedSDH in -band FECOTN standard FECOTN EFEC (measured)OTN EFEC (theoretical)FEC marginsFigure 7 Coding Gain measured via OSNR5.2Tandem Connection MonitoringSONET/SDH monitoring is divided into Section, Line and Path monitoring. A problem arises whenyou have “Carrier’s Carrier” situation as shown in Figure 8, where it is required to monitor a segmentof the path that passes another carrier network.

- 15 -Border of the OTNClient mapping into ODUOperator AOperator BOperator AUserWorkingUserProtectionStart of the OTNClient mapping into ODUprotection supervision (TCM4)domain and domain interconnect supervision (TCM3lead operator QoS supervision (TCM2)user QoS supervision (TCM1)end-to-end path supervision (PM)Figure 8 Tandem Connection MonitoringHere Operator A needs to have Operator B carry his signal. However he also needs a way ofmonitoring the signal as it passes through Operator B’s network. This is what a “Tandem connection”is. It is a layer between Line Monitoring and Path Monitoring. SONET/SDH was modified to allow asingle Tandem connection. G.709 allows six.TCM1 is used by the User to monitor the Quality of Service (QoS) that they see. TCM2 is used by thefirst operator to monitor their end-to-end QoS. TCM3 is used by the various domains for Intra domainmonitoring. Then TCM4 is used for protection monitoring by Operator B.There is no standard on which TCM is used by whom. The operators have to have an agreement, so thatthey don’t conflict.TCM’s also support monitoring of ODUk (G.709 w/0 FEC) connections for one or more of thefollowing network applications (refer to ITU-T G.805 and ITU-T G.872): optical UNI to UNI tandem connection monitoring; monitoring the ODUk connection throughthe public transport network (from public network ingress network termination to egressnetwork termination); optical NNI to NNI tandem connection monitoring; monitoring the ODUk connection throughthe network of a network operator (from operator network ingress network termination toegress network termination); sublayer monitoring for linear 1 1, 1:1 and 1:n optical channel subnetwork connectionprotection switching, to determine the signal fail and signal degrade conditions; sublayer monitoring for optical channel shared protection ring (SPRing) protection switching,to determine the signal fail and signal degrade conditions;

- 16 - Monitoring an optical channel tandem connection for the purpose of detecting a signal fail orsignal degrade condition in a switched optical channel connection, to initiate automaticrestoration of the connection during fault and error conditions in the network; Monitoring an optical channel tandem connection for, e.g., fault localization or verification ofdelivered quality of service.A TCM field is assigned to a monitored connection as described in 15.8.2.2.6/G.709. The number ofmonitored connections along an ODUk trail may vary between 0 and 6. Monitored connections can benested, overlapping and/or cascaded. Nesting and cascading is shown in Figure 9. Monitoredconnections A1-A2/B1-B2/C1-C2 and A1-A2/B3-B4 are nested, while B1-B2/B3-B4 are -B2B3-B4A1-A2TCMiTCM OH field not in useTCMiTCM OH field in useT1543640-01Figure 9 ODUk monitored connections (Fig

Optical Transport Network (OTN) Tutorial Disclaimer: This is a Tutorial. This is NOT a Recommendation! This tutorial has no standards significance. It is purely for educational purposes. In case of conflict between the material contained in the tutorial and the material of