前阵子帮朋友排查一条跨省链路的误码问题登录网管一看ODU2层的BIP-8误码告警一直在跳可光口收发光功率、单波OSNR全部正常。从晚上九点查到十二点最后发现两端OTU单板的FEC模式不一致一个配了软判决EFEC一个用的是标准G.709 FEC。这个问题特别典型——报错报在电层根子却出在光层和协议参数的配合上。如果不把OTN从光层到电层的完整架构在脑子里有一张图这种问题只能靠瞎试。OTN传送网Optical Transport Network光传送网是目前国内骨干网和城域核心网绝对的主流技术。这篇文章不打算背教科书我按平时排障、开业务、做扩容的真实路径从光层到电层把OTN的架构讲透再附一套业务开通的配置示例。适合刚开始接触OTN设备的传输工程师也适合想从SDH/WDM平滑转向OTN的产品、售前和运维人员。顺便提一句搜索“OTN”很容易搜出一堆Oracle技术社区的内容那是另一个世界本文说的是跑业务流量、发激光的传送网。1. SDH和WDM都够好为什么还要硬造出一个OTN1.1 SDH的OAM能力很强但天花板太低很多从传输老设备摸爬滚打过来的工程师对SDH有特殊的感情。SDH同步数字体系解决了PDH时代无法灵活上下业务、无法有效管理的问题它的帧结构里塞了大量开销字节RSOH、MSOH、POH这些字段能做端到端的性能监视、故障定位、时钟传递和自动保护倒换。一段SDH链路断了能很快通过B1/B2字节的误码统计锁定是哪一根纤、哪一块板子出了问题靠APS机制还能在50ms内完成倒换老一代专线客户对SDH的稳定性是有信仰的。但SDH的硬伤也很明显单路容量天花板太低。早期的SDH从155M起步后来发展出2.5G、10G、40G到STM-256基本就到顶了。面对现在的100GE、400GE数据中心互联需求SDH要么绑一堆10G通道做链路聚合要么干脆没法承载。而且SDH处理以太网业务时需要GFP封装、VCAT虚级联、LCAS链路容量调整这几套组合拳配置复杂、时延增加统计复用能力又差。说白了SDH是为TDM语音时代设计的不是为IP大流量时代设计的。1.2 WDM容量大但只有“物理层智商”WDM波分复用的贡献是革命性的一根光纤里同时跑几十上百个波长容量从2.5G一路干到400G、800G。从8波、16波到80波再到最新的CL波段扩展物理层的带宽潜力被不断释放。正因为如此很多运营商骨干网很长一段时间就是“WDM路由器”的架构传输设备只负责把某个波长从A搬到B业务调度全部交给路由器。可纯WDM的问题也藏在“只负责搬波长”这句话里。一个波长的业务到了中间站点要下路传统WDM只能在站点做O-E-O光中继加外部交叉或者靠人工跳纤、预规划波长来满足。波长一旦落地就再也看不到这个波长里具体跑了什么业务更谈不上通道级的误码监视、性能统计、保护倒换。整张WDM网络的OAM能力几乎为零网管上看到的告警无非是“光功率异常”“OSNR劣化”“波长丢失”这类偏物理层的消息。业务量小的时候勉强够用业务一复杂排障完全是灾难。1.3 OTN的本质SDH的“管理脑”长到了WDM的“大身板”上OTN的定位很清晰把SDH引以为傲的开销管理、通道交叉、保护倒换能力嫁接到WDM的大容量光层之上。ITU-T G.709系列标准定义了OTN的帧结构、映射规则、ODUk交叉和保护机制。它等于给每个光波长做了“箱内分装”——一个波长顶多算一条高速公路让业务以标准的ODUk容器在其中运行既能做电层交叉调度又能做端到端性能监控。从设备形态演进也能看出这个思路早期是在WDM设备里加OTN单板先把光口信号用G.709封装起来后来发展出独立的OTN电交叉设备集中做ODUk交叉再往后是ROADMOTN混合平台光层和电层在一个网管体系里协同现在又有分组增强型OTN可以直接处理MPLS-TP分组业务。OTN不是要“取代”SDH或WDM而是把两者的长处叠加起来顺带把IP时代的新需求接住。2. 光层三件套和电层三兄弟先盘清楚每个“层”究竟在干什么2.1 光层OTS、OMS、OCH的嵌套关系ITU-T对OTN光层定义了三个层次很多人刚接触时容易混我用“高速公路—车道—集装箱”来类比一遍就能顺下来。OTS光传输段对应两段光放大器之间的物理光纤链路包括光缆、连接器、光放。它管的是“这段路能不能跑车”监控的是整段光的物理质量和放大器状态。OMS光复用段从合波器到分波器之间承载的是多路波长混合在一起的复用段信号。它管的是“整条车道组是否畅通”监控点是合波/分波器前后的总光功率。OCH光信道一个完整的端到端波长通道从A站发送端到B站接收端。它管的是“某一个集装箱从头到尾是否完好”一个OCH对应承载一路OTUk电信号。三层是严格嵌套的一段OTS里可以有多个OMS段一个OMS段里跑着多个OCH波长。做光层排障时先看OTS光纤/放大器两端光功率再看OMS合分波总功率最后盯OCH单波功率和OSNR这个顺序能帮你快速把问题收敛到一个层次。2.2 电层OPU、ODU、OTU的三层信封电层这边也有三层结构通俗讲就是给客户业务套三层信封。客户业务以太网、SDH、FC存储业务先装进OPU光通道净荷单元——这是最里层的信封负责装业务净荷同时记录映射方式和净荷类型。然后在OPU外面加一层ODU光通道数据单元——这一层最关键它是OTN交叉调度的基本单位带有完整的通道开销可以独立完成性能监视、保护倒换、串联连接监视TCM。最后再给ODU套一层OTU光通道传送单元——这层负责加线路开销和前向纠错FEC形成可以直接送到光模块里发送的线路信号。一个OTU帧的大小是4行×4080个字节其中前3824字节是OTU/ODU/OPU的开销和净荷后面256字节全部是FEC校验位。这就是为什么OTN光口能比裸波长光口在同等OSNR下获得更好的纠错能力——FEC不是可选项只要是标准OTUk接口就带纠错。2.3 层与层的对接关系数据流一次走完从整个数据流视角看一次完整的OTN业务传输是这样的客户口进来的电信号 → 映射进OPU净荷 → 封装成ODU此时可以做电交叉把业务从某个客户单板调度到任意线路单板 → 封装成OTU加FEC和线路开销 → 光模块完成电光转换 → 波分设备把这个波长合进OMS/OTS的光路 → 对端分波 → 光电转换 → 收端OTU解码 → ODU解封装 → OPU解映射 → 从客户口出去。排障的时候一定要记住这个链条客户口CRC错误问题可能在客户侧线缆或客户交换机ODU层BIP误码问题大概率在中间传输链路或光模块OTU层FEC纠错计数剧增那光层OSNR或色散大概率已经踩线了。每一层告警对应的问题范畴完全不同别拿着电层告警去光口那瞎调功率。3. 电层容器选型ODU0、ODUflex、ODUk到底怎么选3.1 ODU等级与业务速率的对应关系OTN的容器等级从ODU0到ODU4加上灵活的ODUflex覆盖了从百兆到100G的绝大多数业务。工程上最常用的对应关系是ODU类型标称速率典型承载业务ODU0约1.244Gbit/s1GE、STM-1、FE、FC100ODU1约2.499Gbit/sSTM-16、OC-48ODU2约10.037Gbit/sSTM-64、OC-192、10GE LANODU3约40.319Gbit/s40GE、STM-256ODU4约104.794Gbit/s100GE、OTU4ODUflex灵活速率按需分配CPRI、FC(8G/16G/32G)、自定义速率选型的第一原则是在满足业务速率的前提下选择“装得下且最省”的容器。10GE业务通常映射到ODU2但很多设备也支持把10GE映射到ODUflex节省中间组合时的时隙浪费。100GE直接上ODU4不要把4路10GE硬绑成ODU4来用——那是SDH时代VCAT的老思路在OTN里既浪费交叉容量又牺牲保护粒度。3.2 ODUflex的带宽到底怎么算ODUflex是OTN体系里最有弹性也最容易配错的地方。ODUflex(GFP)用于承载分组类业务时隙颗粒是1.25Gbit/s的倍数实际带宽业务净荷速率封装开销然后向上取整到n个1.25G时隙。我举个例子一条CPRI Option 7的基站前传业务速率约9.83Gbit/s加上封装开销后可能需要10.5Gbit/s左右那么在ODU4里分配时就是ceil(10.5/1.25)9个时隙实际占用约11.25Gbit/s。很多新手在这会上当觉得9.83G的CPRI放进ODU2约10G就够了其实容器余量已经被吃满一旦有微小的时钟偏差或温漂业务就会出现CRC错误。我现在的习惯是凡是用ODUflex承载的业务都让网管自动计算带宽建议值不自己手填宁可多配一个时隙也不为了省带宽给自己埋雷。3.3 交叉连接粒度和容量决定了这台设备的“段位”OTN电层的核心能力是ODUk交叉。所谓电交叉就是把任意线路口进来的ODU容器在电交叉矩阵里换到任意出口方向不需要在光层动波长。交叉容量从早期的几百G发展到现在的单子架20T甚至更高它决定了一台OTN设备能同时调度多少路ODU业务。交叉粒度是另一个看点早期设备最小只能交叉ODU1意味着1GE业务必须封装到ODU1里浪费巨大后来支持ODU0粒度1GE可以独立调度现在高端设备支持ODU0/ODU1/ODU2/ODU4/ODUflex任意粒度的无阻塞交叉。做网络规划时选设备不仅要看总容量还要看碎片化场景下的调度效率。一台只有ODU1粒度的设备跑满一堆小颗粒业务时容量利用率会很难看。另外提醒一句OTN电交叉和光交叉是两件事。光交叉比如ROADM的WSS直接切换波长不碰ODU容器电交叉先把波长里的ODU容器解出来再切换。电交叉灵活但费电、费时延光交叉省电但粒度大。现网方案往往是“光层导流电层调度”——大颗粒直通用光层需要上下、保护、汇聚的业务落到电层。理解了这一点才能真正看懂厂商的组网推荐。4. 光层细节波长规划、光放大器与光层保护4.1 波长栅格100GHz、50GHz和Flex Grid光层规划的第一步是波长。传统DWDM系统按固定栅格划分波长C波段从1530nm到1565nm大约4.5THz的光谱宽度。按100GHz通道间隔能规划约40个波长按50GHz间隔就是80波。后来为了塞更多波长又扩展了C波段甚至L波段96波、128波系统就是这么来的。到了400G时代固定栅格开始捉襟见肘。400G单波信号往往需要75GHz甚至100GHz的通道带宽如果系统还按50GHz固定栅格切一个400G波长就要占2个栅格效率低不说还可能出现邻道干扰。所以现在新系统普遍支持Flex Grid灵活栅格以12.5GHz为最小颗粒动态分配带宽。规划大容量波分系统时别再用老观念“数波道个数”要算总频谱占用率——这比单纯看波道数量更能反映系统的真实承载能力。4.2 光放大器的工程配置逻辑光层传输离不开光放大器。EDFA掺铒光纤放大器把整个C波段一起放大是波分系统的基石拉曼放大器噪声系数更低、增益谱更宽多用于超长距和开放光缆段。工程上配置OLA光放大站时核心逻辑就一条让每个跨段的入纤光功率等于设计值同时控制单波功率和总功率。每个跨段的光纤衰减大约是0.22dB/km1550nm窗口加上连接器插损和熔接损耗一段80km的光缆总损耗大约18-20dB。EDFA的增益就设成“该跨段总损耗设计余量”把信号恢复到来时的功率水平。级联放大器会逐级累积放大自发辐射ASE噪声OSNR一路下降所以超长距系统要严格控制每级入纤功率不能一味加大光功率——超过阈值会激发出受激布里渊散射、四波混频等非线性效应信号质量反而更差。很多从10G非相干系统转过来的工程师有个误区总想通过提高光功率来压低误码。在100G/400G相干系统里DSP已经通过算法补偿了色散和非线性损伤这时候再盲目提光功率只会增加非线性代价。光层调优的正确路径是先看OSNR是否达标再看入纤总功率是否在工程设计范围内最后才考虑单波功率均衡。4.3 光层保护和电层保护各自护住什么OTN的保护机制分光层和电层两层别搞混。光层保护里最常见的是OLP光线路保护在光缆段做11或1:1保护。OLP倒换速度非常快因为它只是光开关切换完全不做业务解析一台OLP设备能在10ms内完成主备路由切换。但它只能保护光纤断缆这类物理故障保护不了WDM设备的单板故障更保护不了业务所在的电交叉板故障。电层保护的代表是ODUk SNCP。它保护的是ODU容器的端到端路径从业务起点到业务终点任何环节出问题——光纤断、线路板坏、交叉板故障、客户单板问题——只要工作路径失效收端就能从保护路径取到业务完成倒换。保护粒度比光层细得多但代价是额外占用一份带宽和一整套交叉资源。我的建议是普通大颗粒专线用光层保护就够了成本和运维都省高价值政企专线、金融专线直接用ODUk SNCP甚至双节点互保。不过要特别注意电层保护的价值只有在工作路径和保护路径物理上真正分离时才存在下一篇避坑章节我会专门展开这条。5. 配置示例从光口到业务开通走一遍完整配置流程下面给出一套典型的OTN业务配置流程示例。场景是A站和B站相距85km中间有一个中继站R做光放大系统为80波DWDM要求开通一条A站到B站的10GE以太网专线并配置ODU2级别的SNCP保护。以下命令为等效配置示意抽象了不同厂商的CLI差异但配置对象和顺序是通用的实际操作以你设备的网管为准。5.1 配置光层建立OCH波长通道两个站点之间首先要有一条可用的光通道。在网管上通常的配置顺序是创建OMS段、配置OLA中继、再在A/B两站之间建立OCH。# A站创建到中继站R的OMS段 adminA# create-oms-span A-R span-id 1 # A站创建A到B的OCH光通道使用第27波中心频率193.40THz adminA# create-och A-B wavelength 27 center-freq 193.40THz # 中继站R确认OLA放大器使能并设置增益假设跨段损耗18dB预留2dB余量 adminR# config-ola span R-A gain 20dB配置好之后要检查OCH的接收光功率和OSNR是否在设计范围。一般单波接收光功率在-15dBm到-25dBm之间OSNR0.1nm带宽要大于17dB100G相干系统或18dB以上才稳妥。这里如果不达标就先查OLA增益和光纤接头不要急着往下一步配。5.2 配置线路侧OTU端口与FEC光纤通了之后在OTN设备的线路板卡上创建OTU2端口把它绑定到刚才创建的OCH通道上同时设置FEC模式。# A站创建线路侧OTU2端口绑定波长27使能EFEC adminA# create-otu-port slot 10/1 otu2 adminA# set-otu-port slot 10/1 wavelength 27 adminA# set-fec slot 10/1 mode efec # B站同样创建OTU2端口绑定波长27FEC模式也必须为efec adminB# create-otu-port slot 10/1 otu2 adminB# set-otu-port slot 10/1 wavelength 27 adminB# set-fec slot 10/1 mode efec这段配置里的FEC模式是全网管最容易忽略的一步。两端FEC模式不一致链路表象会是OTU帧同步丢失、误码暴增但光功率一切正常。我见过太多现场为了“省事”只在一端开了EFEC结果链路时好时坏。记住OTU口FEC模式必须两端一致。5.3 配置客户侧端口与ODU映射接着把客户侧10GE端口创建出来并指定映射到ODU2容器。这一步要同时确认客户侧端口物理参数比如速率、双工模式、MTU是否对得上客户设备。# A站创建客户侧10GE端口 adminA# create-client-port slot 3/1 speed 10ge # A站创建ODU2容器绑定客户端口3/1承载在线路端口10/1上 adminA# create-odu container 2/1 odu2 adminA# bind-odu-mapping container 2/1 client-port 3/1 adminA# bind-odu-termination container 2/1 line-port 10/1 # B站同样创建对应的客户口和ODU2容器 adminB# create-client-port slot 3/1 speed 10ge adminB# create-odu container 2/1 odu2 adminB# bind-odu-mapping container 2/1 client-port 3/1 adminB# bind-odu-termination container 2/1 line-port 10/1映射类型建议明确选择“10GE LAN”到ODU2的透明映射尽量用GMP标准映射。有的设备默认使用GFP-F封装如果客户业务带特定PCS层特性透明映射会少一层处理时延和兼容性都更好。5.4 创建端到端ODU2业务路径现在可以做电交叉了。在A站和B站的交叉矩阵里把ODU2容器从客户侧调度到线路侧建立A到B的端到端ODU2路径。# 在A站创建到B站的ODU2业务路径 adminA# create-odu2-trail trail-A-B end-point-a A:2/1 end-point-b B:2/1 # 查看路径状态 adminA# show-odu2-trail trail-A-B status路径状态显示“Active/OK”之后再验证两端客户端口是否“Link Up”。此时仪表打流确认10GE业务已经端到端打通。5.5 配置ODU2 SNCP保护如果要上高价值业务再配一条ODU2级别的SNCP保护。思路是业务在工作OTU端口和备用OTU端口各复制一份分别走不同物理路由收端优先从工作路取业务工作路故障后自动切到保护路。# A站创建SNCP保护组 adminA# create-sncp-group sncp-A-B adminA# set-sncp-group sncp-A-B working-path trail-A-B adminA# set-sncp-group sncp-A-B protect-path trail-A-B-PROTECT # 验证保护组 adminA# show-sncp-group sncp-A-B status注意这里工作路径和保护路径必须物理分离。很多现场业务断了没倒换原因就是工作路径和保护路径实际走了同一条光缆路由光缆一断两条路全断。配置保护前一定要查光缆路由资料有条件的话在网管上做SRLG共享风险链路组校验。5.6 业务验证与日常监控配置完成不等于收工。我的习惯是至少观察一周记录以下关键指标形成基线数据监控项关注指标告警触发建议OTU光层单波接收光功率、OSNR光功率偏离基线2dB或OSNR低于系统设计阈值FEC纠错EFEC纠错误码字数量纠错计数持续增长需要定位原因ODU路径BIP误码秒、不可用秒连续15分钟误码秒应开告警客户口CRC错误、丢包率出现CRC即排查客户线缆和设备这些指标不是配置完看一眼就完它们就是以后排障时的“初始参照坐标”。6. 配置实测中的几个隐蔽坑文档里不会明写6.1 FEC模式不匹配告警在电层根因在两端协议参数开头说的那个案例就是典型FEC模式不匹配。当时链路表象是ODU2层BIP误码秒持续跳动OTU层偶发LOF但两端光功率、OSNR都正常完全没有光层劣化的迹象。后来把两端FEC纠错统计调出来看到接收端FEC校正计数远低于预期再一查配置果然一端是标准G.709 FECRS 255/239另一端是软判决EFEC。两种算法的纠错能力和帧结构不同接收端按不匹配的模式去解帧轻则纠错能力失效导致误码累积重则直接帧失步。这类问题的排查链路应该这样走先看OTU层告警LOF、BIP、FEC校正再对比两端业务配置中的FEC模式、ODU类型、映射方式。我强烈建议在新链路验收时专门做一张“两端配置对照表”把FEC模式、ODU速率、映射类型、客户口工作模式全部列进去签字归档。这份表在后续每次排障里都能帮你过滤掉至少一半的无效猜测。6.2 ODUflex带宽下料不足业务“假通真卡”还有一次排障印象很深一条CPRI前传业务配置了ODUflex业务能UP仪表也显示链路通了但基站一跑业务就出现周期性CRC错帧。最后查下来是ODUflex时隙数配少了。业务净荷9.8G当时想着ODU2的10G余量足够配置时直接给他换成了ODU2容器忘了ODU2不光要装净荷还要留出ODU开销和映射间隙的余量加上时钟偏差链路在高温工况下频繁出现CRC。ODUflex/GMP映射的带宽计算必须按“净荷速率封装开销”向上取整网管能自动计算就一定让网管算手动填的速率一律要在设备上验证实际可用带宽。工程上我见过太多“计算器上算好9.8G10G所以没问题”的翻车现场传输这行余量永远比理论跑满重要。6.3 保护路径同路由重金配置了个寂寞某次网络演练客户要求验证SNCP倒换结果故障模拟一启动业务直接中断SNCP完全没有动作。查到最后发现主备两条ODU2路径虽然走的线路板卡不同却在站外经过同一个ODF架、进了同一条光缆。光缆断了两条路径同时失效SNCP自然“巧妇难为无米之炊”。关键教训是电层保护不自动等于物理保护。配置SNCP类保护之前一定要做物理路由核查检查两端站点间是否存在共享光缆、共享管道、共享ODF架。更严谨的做法是直接要求底层波分系统为SNCP的工作和保护通道分配不同光缆类型的SRLG并在网管里标记SRLG属性。这样后续无论谁改路由系统都能自己检查风险。6.4 光功率高并不等于传输质量好最后说一个反直觉的事。有些同事在配置完波分后习惯把单波功率“调满”觉得光功率越高越稳。在长距多波系统里这种做法非常危险。当入纤总功率过高时会产生交叉相位调制、四波混频等非线性效应表现为OSNR明明不错但误码率下不去。尤其是多波道密集的C波段波道之间的非线性串扰会随着总功率上升而急剧恶化。正确的做法是按系统设计的光功率谱密度来配置保持各波道功率均衡。超100G系统如果配置了非线性补偿算法更要严格控制入纤功率在泵浦模型假定范围内。遇到“调大功率反而误码升高”的现象第一反应应该是查看入纤总功率是不是已经超过了工程设计门限而不是继续加功率怼上去。我做OTN这几年最大的体会是这套体系其实并不“高科技炫酷”它特别接近工程本质——光层解决物理可能性电层解决管理可能性所有告警、误码、倒换都逃不开这两层的配合。刚开始接触OTN的人与其急着背命令、记型号不如先画清楚一个业务从客户口进来到对端出去经过的每一个“信封”在哪一层、由谁管理后面所有排障都会顺畅很多。最后再分享一个小习惯每接手一台新OTN设备或一条新链路验收我都会把两端FEC模式、ODU速率、映射方式、保护类型、光功率基线整理成一张保存好的对照表。这张表在后续排障中为我节省的时间远超过当初建表的半小时。