1、最新的OTN性能(G.709)RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) #RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) # 介紹OTN,即光傳輸網絡，來源于2001年初國際電信聯盟所下的定義，目的是提供涵蓋光網絡的所有特征例如速率，格式和光波分復用等各個方面的一套建議。在G.709建議方案里還涉及了對OTN速率，格式的選擇以及當時的設想客戶,G.709第一版中列出了諸如STM-N,ATM,IP和以太網等客戶信號選項，如圖1所示。Clients(e.g.STM-N,ATM,

2、IP,Ethernet)OPUkODUkPODUkODUkTOTUkVOTUkOChOTUkVOTUkOChrOMSnOTSnOPSnOTM-n.mFullfunctionalityOTMinterfaceT1543480-01OTM-0.m,OTM-nr.mReducedfunctionalityOTMinterfaceFigure6-1/G.709/Y.1331-StructureoftheOTNInterfaces圖一：OTN接口結構示意圖(摘自ITU-TG.709/Y.1331規范2001年2月版)在這些客戶信號中，過去十年的大部分時間,STM-N是最常見的。通常情況下，許多OTN設備

3、的部署時，都被要求提供STM-N客戶端信號的透明傳輸機制。自從OTN設備被首次啟用之后，網絡世界發生了許多變化，OTN也隨之得到了提升以便保持同步。2009年12月發布的第三版G.709，連同2010年7月發布的附件1，則定義了一些改進后的OTN新特征。新特征包括：NewClientSignalsODU0(andTTTfirstdefinedinAmendment3ofG.709Issue2)GMPODUflex(CBR)andODUflex(GFP)HitlessresizingofODUflex(GFP)1.25Gb/sTributarySlots(PT=21)OTU/ODU/OPU4Mu

4、ltistageMultiplexingDelayMeasurementRecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) 新的客戶信號從第一次部署OTN設備用于SDH和SONET信號的傳輸開始,以太網不斷突破企業領域的應用界限，向公共網絡領域延伸。相應的，國際電信聯盟(ITU)已為此做了很多工作，定義和標準化了通過OTN網絡傳輸多種速率的以太網信號，包括千兆以太網、10G以太網、40G以太網和100G以太網等。由于調整的需要以及諸如云計算等新趨勢的出現，大型數據中心和計算場已經應運而生。與此同時，對多地信號進行同步化的需求也日益增加，從而

5、使得1G/2G/4G/8G/10G光纖通道作為重要的OTN客戶信號。除了這些以數據為中心的客戶,OTN還在考慮一些其它的高比特率客戶，如數字影像和通用公共射頻接口(CPRI)。所有這些客戶信號在OTN傳輸時需要具備有效的比特透明性和定時透明性，而且OTN建議書已據此作了相應改進，以適應這些新的需求。ODU0(和TTT)實現以太網支持的其中一個重要的新概念是針對千兆以太網定義一個合適尺寸的傳輸容器。雖然這個概念事實上已經在2003年3月加入第二版G.709規范,但仍然被視為2009年12月第三版G.709規范的一個重大改進。在OTN的最初定義中，光通道數據單元ODU1是最小的傳輸容器，專門用于傳

6、輸單個STM-16信號，凈荷容量為2,488,320kbit/s。這也意味著僅僅傳輸單個千兆以太網信號的ODU1會浪費大量帶寬。為此，ITU將ODU0定義為光通道凈荷單元OPU1凈荷比特率的一半，即1,244,160kbit/s。在加上ODU0和OPU0開銷后，相應的凈荷容量為238/239x1,244,160kbit/s，即1,238,954.310kbit/s。千兆以太網物理編碼子層(PCS)采用8B/10B線路編碼方式，產生的比特率比1Gbit/s的信息速率高25%。為了能夠實現千兆以太網的比特透傳和時鐘透傳，PCS層信號必須保留并傳輸，但OPU0凈荷比特率不足以承載速度為1.25Gbi

7、t/s的PCS信號，所以需要在OTN網絡入口處對PCS信號進行定時透明轉碼(TTT)處理，從而減少所傳輸信號的比特率，同時保存在OTN網絡出口處恢復PCS信號所需的信息。TTT處理采用了ITUG.7041規范中針對通用成幀規程(GFP-T)定義的8B/10B凈荷編碼的透明映射機制。該機制終止8B/10B線路編碼，并用具有較低開銷的64B/65B塊編碼取而代之。加入GFP幀頭，但并無基于GFP的速率調整或GFP凈荷幀校驗序列(FCS)，從而以15/16的速率縮減比產生了速率為1.17875Gbit/s的客戶信號。雖然該信號的速率已經低于OPU0的凈荷速率，但是仍然不夠接近OPU0凈荷速率，以至于

8、無法利用異步映射規程(AMP)進行映射。因此，采用新的映射規程勢在必行。GMP最初針對OTN定義的OPU凈荷速率和STM-n(n=16,64,256)客戶信號速率非常匹配，可以通過簡單的AMP方式，將STM-n信號映射為OPU,以及將低階ODU映射為高階OPU的支路時隙。隨著新的客戶信號的出現以及基于100G以太網的OPU4的定義，很多情況下AMP映射的調整范圍無法覆蓋客戶信號和服務器信號的速率差異(需要指出的是一個低階ODU可視為高階OPU服務層的客戶信號)。所以，種更靈活或更通用的方法由此形成，并恰如其分地被命名為通用映射規程(GMP)。只要在所有情況下(如客戶信號的最大ppm頻偏和服務器

9、信號的最小ppm頻偏)，服務器信號速率確定高于客戶信號速率，該方法可將任何的客戶信號速率映射為任何服務器凈荷速率。為了實現此目的，GMP僅僅采用一些可用的承載信號容器凈荷字節/字對每個幀或復幀進行填充，而所填充字節/字的數量可根據需要進行調整，從而吸收客戶信號和信號容器之間非整速率差異，然后通過圖2所示的Sigma-Delta數據/填充算法，所填充的字節/字平均分布于容器中。extractCnfromOHextractCnclientdataMapperDemapperFigureD.2-ProcessingflowCn(t)clientdataentitiesaremappedintothe

10、payloadareaoftheserverframeormultiframeusingasigma/deltadata/stuffmappingdistribution.ItprovidesadistributedmappingasshowninFigureD.3.Payloadfieldj(j=1.Pserver)carries:-clientdata(D)jixf(Cn(t)modPserverCn(t)-stuffdata(S)jixCn(t)modgerver2Cn(t)PayloadAreaserverframeormultiframeclientdatastuffFigureD.

11、3-Sigma/deltabasedmapping圖2.GMP概要(摘自ITU-TG.709/Y.1331規范附件D,2009年12月版)和AMP樣，每個幀或復幀需要利用從映射器發送到解映射器的有關容器凈荷字節/字用法的信號，準確地進行去映射，這主要通過OPU開銷字節位置（即第16列的JC/1/2/3字節）完成。對于GMP來說,所填充的容器信號凈荷字節/字必須正確傳送,其數量取決于客戶信號和容器兩者具體頻差，但是最大值為相應OPUk的凈荷字節總數（k=0,1,2,3時為15232,k=4時為15200）。全部的字節/字數量的傳輸需要通過14個比特位來完成。由于通常情況下，從個幀/復幀到另個幀/

12、復幀，字節/字數可能增加也可以減少，所以很有必要借用SDH指針增量/減量的概念。因此，有兩個專用比特位用于指示字節/字數量的變化，從而通過創建個16位長度的字段，對每個幀或復幀上填充了客戶數據信息的實際服務器信號凈荷字節/字數量進行記錄和傳輸。此外,GMP還進行CRC-8錯誤校驗碼的計算和發送，需要占用OPUk服務器信號開銷的JC1、JC2、JC3字段。很重要的一點，GMP并非用于替代AMP和BMP,而是作為一種補充方案，專門用于處理無法通過AMP和BMP方式映射的客戶信號。G.709明確說明了將客戶信號映射為OPUk或將ODUj映射為OPUk等多種情況下的映射方法。RecentFeature

13、sofOTN(G.709)RecentFeaturesofOTN(G.709) #ODUflexODUO并非是用于匹配客戶信號唯一的新容器。事實上OTN網絡中的恒定比特率(CBR)業務和數據包業務不斷變化，其速率并不能一勞永逸地根據現有OPUk凈荷進行調整。為了處理這種變化，個更加靈活的概念應運而生，即靈活速率光數字單元(ODUflflex)。針對CBR業務的透明傳輸,客戶信號映射進ODU/OPU后在OTN網絡上傳輸,從而借助客戶信號容器的開銷,全程對信號進行管理和監測。理想狀態下,OPU凈荷率非常接近CBR客戶信號的比特率，此時達到效率最大化,而實現該目的的最佳方法是利用比特異步映射規程(B

14、MP),從而使得OPU凈荷率和客戶信號比特率相同，而且ODU速率是客戶信號比特率的239/238倍,便于加入ODU和OPU開銷。和其它具有標稱速率、容差為20ppm的ODUk(k=0,1,2,3,4)不同，ODUflflex(CBR)的速率是CBR客戶信號的倍數。例如，傳輸FC-400信號的ODUflex(CBR)速率是4.268Gbit/s(即239/238x4.250Gbit/s)容差為100ppm,傳輸傳輸FC-800信號的ODUflex(CBR)速率是8.536Gbit/s(即239/238x8.500Gbit/s)容差為100ppm。需要注意的是，即使客戶信號有更小的容差,ODUfl

15、ex(CBR)的容差總是100ppm。對靈活ODU速率的定義也解決了對不匹配固定OPUk(k=0,1,2,3,4)凈荷速率的包數據流進行有效傳輸的需要。GFP把數據包碼流封裝為OPUflex(GFP)從而通過高階OPUk(k=2,3,4)傳輸，凈荷率為最低的高階OPUk支路時隙容量的倍數。這種方法提供了一種可管理的容器，其大小可通過采用1.25Gbit/s左右的粒度進行適當配置，便于在OTN網絡上傳輸數據包流。按照2003年3月版的G.709規范第18條所作的定義,OPUk的虛擬級聯技術也能為傳輸靈活速率的數據包流提供了一種傳輸機制，但是，因為每個OPU/ODUk單元需要在網絡上各自進行路由,

16、所以虛擬級聯涉及到發送基于不同協議的信號，且需要解決差分時延的問題，實施和管理的復雜度非常大。每個傳輸單元都有各自的管理開銷，這樣總體的連接狀態取決于各個單元的狀態。對于通過單個高階ODUk在每個網絡鏈路上傳輸的數據包流來說,這樣的復雜性毫無附加值可言。G.709對上述ODUflex(GFP)的靜態配置已有定義除此之外,還需確定一個無損調整的程序(目前命名為ODUflex無損調整,即HAO),從而允許動態增加或減少ODUflex凈荷率通過這種方法，各節點之間的帶寬需求的變化在任何時候都能夠加以解決。1.25Gb/s支路時隙(PT=21)ODU0、ODUflex(CBR)和ODUflex(GFP

17、)意味著需要比2.5Gbit/s更細的支路時隙粒度為了實現該目的,1.25Gbit/s支路時隙被定義,從而更有效地將低階ODUj(j=0,1,2,3,flex)多路復用為高階OPUk(k=2,3,4)為了區別和2.5Gbit/s結構的區別，定義了一種新的凈荷類型(PT)，并由高階OPUk開銷的凈荷結構標識(PSI)字節定義。RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) 和ODU2映射為4個2.5Gbit/sOPU3(ODTU23,PT=20)的支路時隙一樣，ODU2如今可以映射為8個OPU3QDTU23,PT=21)1.25Gbit/

18、s支路時隙。無論所采用的支路時隙是1.25Gbit/s或2.5Gbit/s，將ODU1映射為OPU2/3以及將ODU2映射為OPU3均采用AMP規程。由于其實際上早于G.709第三版被定義，ODU0映射到OPU1的1.25Gbit/s支路時隙，仍使用AMP(ODTU01).所有其他的映射到OPUk的1.25Gbit/s支路時隙的ODUj,則使用GMP。圖三從中總結了如下映射類型：Table7-10-OverviewofODUjintoOPUkMappingTypes2.5GTributarySlots1.25GTributarySlotsOPU2OPU3OPU1AMPOPU2GMPOPU3GM

19、POPU4GMPODU0-(PT=20)(PT=21)(PT=21)(PT=21)AMPAMPAMPAMPGMPODU1-(PT=20)(PT=20)(PT=21)(PT=21)(PT=21)AMPAMPGMPODU2-(PT=20)(PT=21)(PT=21)GMPGMPODU2e-(PT=21)(PT=21)GMPODU3-(PT=21)GMPGMPGMPODUflex-(PT=21)(PT=21)(PT=21)圖3.ODUj至OPUk映射類型OTU/ODU/OPU4OTU/ODU/OPU4速率定義不僅僅被要求能夠傳輸100G以太網，還被要求致力于通過提供將ODU2和ODU3復用至OTU/

20、ODU/OPU4以及滿足在網絡核心區不斷增長的10Gb/s和40Gb/s鏈接的需求。盡管OTU/ODU/OPU4比特率仍定義為2488320kbit/s里的STM-16速率的倍數關系，唯一被定義為可映射到OPU4的非OTN客戶信號是100G以太網。未來的OTN速率將與IEEE標準所定義的速率保持同步。如圖三所示，當OPU4負載低階ODUj(j=0,1,2,3,flfle)時，只能支持1.25Gbit/s支路時隙。由于任一ODUj都能被映射到一個或者多個1.25Gbit/s支流時隙，所以同時定義一個2.5Gbit/s支路時隙架構就沒有意義了。根據被OTU/ODU/OPU4所選定的速率，一個OPU

21、4支流時隙的空間實際上比1.3Gbit/s要大，這意味著被要求可以負載一個給定的ODUj(j=0,1,2,3,flflex)的n(n=1.80)支流時隙的空間要遠遠大于ODUj本身因此，GMP是唯一定義為將低階ODUj復用到高階OPU4的映射程序。多級復用G.872(11/2001)9.2節中建議，僅有一個單級復用(如ODU1-ODU2或ODU1,ODU2-ODU3)存在，以便減少整個網絡的復雜性。因為新定義的ODU0和ODUflex不能直接在高階ODU2或者ODU3網絡進行傳輸這使得這些新的容器在使用上產生了新問題。因此，在G.872中的建議已被從附件2(07/2010)中刪除。因此，多級的

22、復用組合不會遺漏任何可能的需求，而且能在單一網絡和ASIC/FPGAs里支持復雜的架構，比如ODU0-ODU1-ODU2-ODU3-ODU4。然而，較之前面推薦的單一層級架構，它無疑增加了管理和資源的復雜性。延遲測量為了讓Fiberchannel這樣對延遲特性敏感的客戶的更順利的實現傳輸，可以通過一個傳輸網絡的路徑了解端到端的延遲是非常重要的。同樣，它有利于確定延遲變化（例如根據保護轉換）。為了實現這一點,將定義一個機制用于通過使用之前保留的ODU到ODUk的開銷字節。該機制為整個端對端ODUk或者任一串聯連接段提供測量。通過管理控制，這些測量在有電路連接時或定期性監測等需求時被啟用。結論通過

23、G.709的一些更新，我們可以看出，近幾年，ITU已經讓OTN在致力于滿足新的客戶傳輸需求方面取得重大進展。大多數部署了的OTN設備都已然支持SDH和SONET客戶信號，但這些應用不是未來幾年市場的主導。而正是那些以數據業務為主的客戶，如以太網，光纖通道和數字視頻已經迅速成長為網絡帶寬發展的驅動力，我們在此討論的標準上的變化，都將推動OTN設備持續為運營商網絡提供最高效的傳輸能力！RecentFeaturesofOTN(G.709)NoticeEXARCorporationreservestherighttomakechangestotheproductscontainedinthispubl

24、icationinordertoimprovedesign,performanceorreliability.EXARCorporationassumesnoresponsibilityfortheuseofanycircuitsdescribedherein,conveysnolicenseunderanypatentorotherright,andmakesnorepresentationthatthecircuitsarefreeofpatentinfringement.Chartsandschedulescontainedhereinareonlyforillustrationpurp

25、osesandmayvarydependinguponausersspecificapplication.Whiletheinformationinthispublicationhasbeencarefullychecked;noresponsibility,however,isassumedforinaccuracies.EXARCorporationdoesnotrecommendtheuseofanyofitsproductsinlifesupportapplicationswherethefailureormalfunctionoftheproductcanreasonablybeex

26、pectedtocausefailureofthelifesupportsystemortosignificantlyaffectitssafetyoreffectiveness.ProductsarenotauthorizedforuseinsuchapplicationsunlessEXARCorporationreceives,inwriting,assurancestoitssatisfactionthat:(a)theriskofinjuryordamagehasbeenminimized;(b)theuserassumesallsuchrisks;(c)potentialliabi

27、lityofEXARCorporationisadequatelyprotectedunderthecircumstances.Copyright2011EXARCorporationWhitePaper:May2011(CN)Reproduction,inpartorwhole,withoutthepriorwrittenconsentofEXARCorporationisprohibited.RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) #RecentFeaturesofOTN(

28、G.709)RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) # RecentFeaturesofOTN(G.709)IntroductionTheOTN,orOpticalTransportNetwork,wasfirstdefinedbytheITUinearly2001withthegoalofprovidingasetofRecommendationsthatcoveredallaspectsofopticalnetworkingincludingratesandformats,andopticalWavelengthDivisi

29、onMultiplexing.TheratesandformatschosenfortheOTN,capturedinRecommendationG.709,weredefinedtosuittheenvisionedclientsatthetime.Issue1ofG.709liststheseclientsasSTM-N,ATM,IPandEthernetasisshownbelowinFigure1.Clients(e.g.STM-N,ATM,IP,Ethernet)OPUkODUkPODUkODUkTOTUkVOTUkOChOTUkVOTUkOChrOMSnOTSnOPSnOTM-n.

30、mFullfunctionalityOTMinterfaceT1543480-01OTM-0.m,OTM-nr.mReducedfunctionalityOTMinterfaceFigure6-1/G.709/Y.1331-StructureoftheOTNInterfacesFigure1:OTNInterfaceStructureDiagramfromITU-TG.709/Y.1331(02/2001)Amongtheseclients,STM-Nwasthemostprevalentatthetimeandremainedassuchformostofthelastdecade.Cons

31、equently,muchoftheinstalledbaseofOTNequipmentwasdeployedtoprovidetransparenttransportofSTM-Nclientsignals.SincethefirstdeploymentsofOTNequipment,therehavebeenmanychangesinthenetworkingworldandtheOTNhasbeenenhancedtokeeppace.Issue3ofG.709,releasedinDecemberof2009,alongwithAmendment1,releasedinJulyof2

32、010,defineanumberofnewaspectsoftheOTN.Theseenhancementsinclude:NewClientSignalsODU0(andTTTfirstdefinedinAmendment3ofG.709Issue2)GMPODUflex(CBR)andODUflex(GFP)HitlessresizingofODUflex(GFP)1.25Gb/sTributarySlots(PT=21)OTU/ODU/OPU4MultistageMultiplexingDelayMeasurementRecentFeaturesofOTN(G.709)RecentFe

33、aturesofOTN(G.709) RecentFeaturesofOTN(G.709)NewClientSignalsSincethefirstdeploymentsofOTNequipmenttocarrySDHandSONETclients,Ethernethasbeenbreakingthroughtheboundariesoftheenterpriseandassertingitselfasamajorprotocolinthepublicnetwork.Consequently,muchworkhasbeendoneintheITUtodefinestandardizedmeth

34、odsfortransportingvariousEthernetratesovertheOTN.TheseincludeGigabitEthernet,10GEthernet,40GEthernetand100GEthernet.Duetoregulatoryissuesandnewtrendssuchascloudcomputing,largedatacentersandcomputefarmshavealsodeveloped.Alongwiththis,theneedtosynchronizedataacrossmultiplelocationshasincreasedresultin

35、gintherecognitionofFibreChannel,at1,2,4,8and10G,asanimportantOTNclient.Inadditiontothesedatacentricclients,anumberofotherhighbitrateclientsarecurrentlyunderconsiderationsuchasDigitalVideoandCommonPacketRadioInterface,orCPRI.Alloftheseclientsrequireefficientbitandtimingtransparenttransportandtherehav

36、ebeenenhancementstotheOTNRecommendationstoaccomodatethesenewrequirements.ODU0(andTTT)OneofthemostsignificantnewconceptsforEthernetsupportwasthedefinitionofatransportcontainerappropriatelysizedforGigabitEthernet.WhilethiswasactuallyaddedtoIssue2ofG.709(03/2003)inAmendment3(04/2009),itisconsideredtobe

37、oneofthemajorenhancementsassociatedwithIssue3ofG.709(12/2009).IntheoriginaldefinitionoftheOTN,theODU1wasthesmallesttransportcontaineravailableanditwasspecificallysizedtotransportasingleSTM-16,withapayloadcapacityof2488320kbit/s.ThismeansthatanODU1carryingasingleGigabitEthernetclientwouldhaveasignifi

38、cantamountofwastedbandwidth.Topreventthiswastedbandwidth,theODU0wasdefinedtobeexactlyonehalfthepayloadbitrateoftheOPU1,or1244160kbit/s.Theresultingpayloadcapacity,afteraccountingforODU0andOPU0overhead,is238/239x1244160kbit/s,or1238954.310kbit/s.TheGigabitEthernetPCSlayerusesan8B/10Blinecodinggenerat

39、ingabitratewhichis25%higherthanthe1Gbit/sinformationrate.InordertoprovidebitandtimingtransparenttransportofGigabitEthernet,thePCSlayersignalmustbetransported,buttheOPU0payloadbitrateisnotsufficienttocarrythis1.25Gbit/sPCSsignal.Toaccommodatethissituation,aTimingTransparentTranscoding,orTTT,ofthePCSs

40、ignalattheingresstotheOTNisrequiredtoreducethetransportedbitratewhilepreservingtheinformationrequiredforrestorationofthePCSsignalattheegressoftheOTN.Thetransparentmappingmechanismsof8B/10BpayloaddefinedforGFP-TinITUG.7041areusedforthisTimingTransparentTranscoding.Thisinvolvesterminationofthe8B/10Bli

41、necodeandreplacementwithloweroverhead64B/65Bblockcode.WiththeadditionofGFPframeheaders,butnoGFPbasedrateadaptationorGFPpayloadFCS,thisresultsinareductionratioof15/16yieldingaclientsignalrateof1.17875Gbit/s.ThisrateisnowlessthanthepayloadrateofanOPU0,however,itisnotcloseenoughtotheOPU0payloadratetoal

42、lowtheclienttobemappedwithAMP.Consequently,anewmappingprocedureisrequired.GMPTheOPUpayloadratesinitiallydefinedfortheOTNwerecloselymatchedtotheSTM-n(n=16,64,256)clientratesenablingasimpleAsynchronousMappingProcedure,orAMP,tocovertheadaptationofSTM-nclientsintoOPUsandLowerOrderODUsintoTributarySlotso

43、fHigherOrderOPUs.WiththeadditionofnewclientsandthedefinitionofOPU4basedonthe100GErate,manymappingscenariosexistwhereAMPdoesnothavethejustificationrangetomanagetheratedifferencesbetweentheclientandtheserver(notethataLowOrderODUcanbeconsideredtobeaclientofaHighOrderOPUserver).Consequently,amoreflexibl

44、e,orgeneric,methodwasdefinedwhichisappropriatelynamedGenericMappingProcedure,orGMP.Thisproceduresupportsmappinganyclientsignalrateintoanyserverpayloadrateaslongastheserverrateisguaranteedtobehigherthantheclientrateunderallconditions(e.g.maximumclientppmoffset&minimumserverppmoffset).Toachievethis,GM

45、Ponlypopulatessomeoftheavailableserverpayloadbytes/wordseveryframeormulti-frame.Thenumberofpopulatedbytes/wordsperframe/multi-framecanchangeasnecessaryinordertomatchanynon-integeraverageratethatrepresentsthedifferencebetweentheclientandserverrates.Thepopulatedserverbyte/wordsarethenevenlydistributed

46、throughouttheserverframebymeansofaSigma/Deltadata/stuffmappingalgorithmasshowninFigure2.OHPayloadAreahPayloadPayload*LAreaFdetermineqinsertqintoOHinsertqclientdataMapperOHPayloadAreaOHPayloadLOHPayloadAreaEextractCnfromOHextractCnclientdataDemapperRecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709)

47、 # #RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709)RecentFeaturesofOTN(G.709) RecentFeaturesofOTN(G.709)FigureD.2-ProcessingflowCn(t)clientdataentitiesaremappedintothepayloadareaoftheserverframeormultiframeusingasigma/deltadata/stuffmappingdistribution.ItprovidesadistributedmappingasshowninFigu

48、reD.3.Payloadfieldj(j=1.Pserver)carries:-clientdata(D)ifj(xCn(t)modPserverCn(t)FigureD.3-Sigma/deltabasedmappingFigure2:SummaryofGMPfromAnnexDofITU-TG.709/Y.1331(12/2009)AsisthecasewithAMP,signallingfromthemappertothedemapperregardingserverpayloadbyte/wordusageisrequiredeveryframeormulti-frametoprop

49、erlyterminatethemapping.OPUoverheadbytepositionsareusedforthis(i.e.JC1/2/3incolumn16)and,forGMP,theabsolutenumberofpopulatedserverpayloadbytes/wordsmustbecommunicated.Therangeofvaluestobesignalleddependsonthespecificclient/servercombination,butthemaximumvaluepossibleisthetotalnumberofpayloadbyteposi

50、tionsforagivenOPUk(15232fork=0,1,2,3or15200fork=4).Fourteenbitsarerequiredtocovertheentirerangeofthevaluesofthebyte/wordcounttobesignalled.Then,becauseitistypicalthatacountmayincrementordecrementfromoneframe/multi-frametothenext,itisalsousefultoborrowfromtheincrement/decrementconceptinSDHpointers.Tw

51、oadditionalbitsareusedforthispurposecreatinga16-bitfieldthatcommunicatestheactualcountofserverpayloadbytesorwordspopulatedwithclientdataoneachframeormulti-frame.Inadditiontothis,aCRC-8iscalculatedandsentthusoccupyingtheJC1,JC2andJC3fieldsintheOPUoverheadoftheOPUkserver.ItisimportanttonotethatGMPisno

52、tareplacementforAMPandBMP,butratheracomplementaryschememeanttoaddressclientswhichcannotbemappedwithAMPandBMP.G.709clearlyspecifiesthemappingmethod(s)tobeusedforeachclientsignaltoOPUkorODUjtoOPUkcombination.ODUflexTheODU0wasnottheonlynewcontainerratethatwasdefinedtocloselymatchaspecificclient.Infact,

53、itwasclearthatevolvingConstantBitRate(CBR)andpacketclientsoftheOTNwouldnothaveratesconvenientlyalignedwiththeexistingOPUkpayloads.Toaccommodatethisevolution,amoreflexibleconceptwasrequired,namely,theODUflex.FortransparenttransportofCBRclients,theclientsignalismappedintoanODU/OPUfortransportacrossthe

54、OTNsothattheclienthasacontainerwithoverheadthatallowsformanagementandmonitoringthroughoutthenetwork.Ideally,theOPUpayloadrateiscloselymatchedtotheCBRclientbitrateformaximumefficiency.ThebestwaytoensurethisistousetheBitSynchronousMappingProcedure(BMP)wheretheOPUpayloadrateisexactlythatoftheclientbitr

55、ateandtheODUrateissimply239/238timestheclientbitratetoaccommodatetheODUandOPUoverhead.ForCBRclientsthatcannotbemappedtoOPUk(k=2,3,4)usingAMPbecausetheirbitratesarenotcloseenough,thismechanismisusedandtheresultingODUiscalledanODUflex(CBR).UnlikeotherODUk(k=0,1,2,3,4)wherethebitrateisafixednominalrate

56、witha20ppmtolerance,therateofanODUflex(CBR)isamultipleoftheCBRclientrate.Forexample,anODUflex(CBR)carryingFC-400is4.268Gbit/s(239/238x4.250Gbit/s)100ppmwhereasanODUflex(CBR)carryingFC-800is8.536Gbit/s(239/238x8.500Gbit/s)100ppm.NotethattheratetoleranceofanODUflex(CBR)isalways100ppmevenforclientshavi

57、ngasmallertolerance.ThedefinitionofaflexibleODUratealsoaddressestheneedforefficienttransportofpacketdataflowsthatdonotmatchthefixedOPUk(k=0,1,2,3,4)payloadrates.Inthiscase,GFPencapsulatedpacketstreamsaremappedintoanOPUflex(GFP),wherethepayloadbitrateissetatamultipleofthecapacityoftheTributarySlotsof

58、thelowestHighOrderOPUk(k=2,3,4)overwhichitcanbecarried.Thisprovidesamanageablecontainer,whichisappropriatelysizedusingagranularityofapproximately1.25Gbit/sfortransportofpacketstreamsacrosstheOTN.VirtualConcatenationofOPUk,asalreadydefinedinClause18ofG.709(03/2003),canalsoprovideamechanismtotransport

59、flexibleratepacketstreams,butitpresentsbothimplementationandmanagementcomplexity.VirtualConcatenationinvolvesprotocolspecificsignallingaswellastolerancefordifferentialdelaysbecauseindividualOPU/ODUkmemberscanbeindividuallyroutedthroughthenetwork.Eachmemberhasitsownmanagementoverheadandsothestatusoft

60、heoverallconnectionmustthenbeconstructedfromthestatusoftheindividualmembers.ThesecomplicationsprovidenoadditionalbenefitwhenthepacketstreamisalwayscarriedinasingleHOODUkoneachnetworklink.ThestaticallysizedODUflex(GFP)asdescribedaboveisdefinedinG.709andworkisongoingtospecifyahitlessresizingprocedure(