第五篇：OTN，不只是把SDH做成了大水管

1. 为什么现在还得认真聊OTN，它不是个老协议吗

有朋友在群里问了个挺有意思的问题：现在IP都跑到400G了，DCI（数据中心互联）动不动就是ZR相干模块直接怼，OTN这玩意儿是不是该进博物馆了？我当时没直接回，反手给他贴了一张我前阵子调过的某省干线波分拓扑图：环上20多个站点，每个站的开销字节都打着OTN的烙印，监控通道、保护倒换、性能监视全靠它兜底。IP确实灵活，但灵活不等于可靠，电信级的"看得见、管得住、倒得快"这三个硬指标，目前还真只有OTN体系给得起。

这篇是通信工程系列里关于OTN的第十五篇，前面的内容从DWDM基础一路聊到C+L波段，今天干点正事：把OTN的帧结构、映射复用、FEC、OAM和保护机制串起来讲一遍。这篇文章更像一份“实战导图”，目标读者是刚入行传输两三年、已经能配波分但没系统啃过G.709的朋友，以及那些日常和传输对接但总被一堆ODU/OPU缩写搞晕的IP网工程师。看完之后你至少能回答三个问题：OTN和SDH、DWDM的本质区别在哪儿，ODUflex到底怎么用，以及为什么说OTN是网络编排时代最关键的标准化底座。

开聊之前先说个基调：我不会把G.709的每条字段都搬出来念，而是按一条真实业务从客户侧进来、被打包、被映射、被复用、上线传输、遇故障倒换的完整路径来讲。这样你理解到的不是孤立的概念，而是一整套解决问题的思路。

2. 从PDH到OTN的演进逻辑：这一路到底在解决什么痛点

2.1 为什么SDH时代的那套玩法会触到天花板

SDH在传输史上的地位不用我吹，直到今天很多城域接入层还在跑STM-16甚至STM-64。但SDH的问题在于它的一切设计都围着TDM业务转，而TDM业务的世界有一个铁律：带宽是固定时隙分配的，64k就64k，2M就2M，哪怕这一路语音静默期一个字都不传，时隙照样占着。等到以太网业务大规模上来之后，SDH网络就尴尬了——GE端口的实际流量是突发的，可SDH只能给一整条VC-4的管道，剩下的空时隙纯属浪费。

另一层痛点是SDH的交叉粒度，VC-4级别的交叉在10G时代还算够用，可到了40G/100G时代，业务颗粒普遍是10GE、100GE，如果还按VC-4来切，交叉表项会爆炸，调度效率低得可怕。传输体系需要一个新的非线性、非时隙绑定的调度单位，而这个单位必须足够大、足够灵活，还能承载任意客户信号。

2.2 DWDM解决了容量，但没解决管理和保护

DWDM解决了物理层面的带宽问题，一根光纤放80个波、单波100G，容量一下子上来了。但DWDM在逻辑层面其实挺“裸”的：光层不知道跑的是什么业务、不知道有没有误码、不知道业务优先级，更做不了基于业务颗粒的倒换。早期的波分系统里，业务倒换靠的是客户侧路由器之间的保护协议或者SDH层面的SNCP，传输网络本身只负责把光信号从A点到B点放大再放大。

长此以往会出什么问题？故障定位就变成了互相扯皮。路由器说你光口收光正常但CRC在涨，传输说我光模块收光功率平稳、OSNR看着没问题，两边都觉得自己没毛病，最后只能上仪表一点一点测。OTN的价值就在这儿：它在DWDM提供的物理管道之上定义了一套完整的数字封装和运维语言，让传输网从“哑管道”变成“智能管道”。

2.3 OTN的定位：SDH的运维能力 + DWDM的带宽能力

OTN在标准上的全称是Optical Transport Network，ITU-T G.709系列定义。它本质上做了四件事：

• 把各种客户信号（SDH、以太网、FC、CPRI等）统一封装进一个标准的数字容器；
• 提供比SDH大得多的颗粒度等级，从ODU0到ODU4再到ODUflex；
• 引入带外FEC，把传输链路的纠错能力从物理层扩展到数字层；
• 建立完整的TCM（串联连接监视）、PM（路径监视）、SM（段监视）以及多达8级的嵌套保护机制。

这四件事合起来，就让OTN既能像SDH一样被精细管理，又能像DWDM一样扛大带宽。这也是为什么今天的100G/400G相干传输系统，几乎无一例外地内置了OTN处理能力，哪怕你只把它当普通波分用，内部的FEC和监视开销也一直在默默工作。

3. OTN的分层模型和帧结构，G.709到底在纸上画了什么

3.1 三层机构：OPU、ODU、OTU，别把它们搞混

一说到OTN分层，很多人的第一反应是记不住OPU/ODU/OTU分别管什么。我教你一个记法：把客户信号想象成你要寄出去的货物，OPU是标准货箱，ODU是带运单信息的货箱，OTU是已经绑好防震标签和GPS追踪器的货箱。

OPU（Optical Channel Payload Unit）层负责干一件事：把客户信号适配进一个固定大小的净荷区，并加上映射相关的开销（比如映射方式指示、客户信号类型指示）。这一层决定的是一个帧里到底装的是什么类型的业务、用什么方式装的。

ODU（Optical Channel Data Unit）层相当于给OPU加了个“快递面单”，上面写着发件人、收件人、路径信息、性能和告警状态。这一层是OTN网络管理的核心，所有的交叉连接、保护倒换、性能统计都在ODU层做。ODU层还分ODU0、ODU1、ODU2、ODU3、ODU4以及ODUflex，分别对应不同的容量等级，细节后面单独讲。

OTU（Optical Channel Transport Unit）层则是在ODU外面再套一层，加上FEC校验字节和帧定位字节，负责物理层的可靠传输。这一层的处理发生在每个站点、每个光中继器上，行话叫“3R再生”——reshaping、retiming、regeneration。

3.2 OTUk帧布局：4行4080列，其中关键的不是净荷而是开销

OTN帧的结构常被概括为“4行4080列”，每个字节对应一个ODUk时期的基本传输单位。这个结构和SDH的9行270列有本质不同——SDH是按字节交织排列的块状帧，而OTN是横向扫描的块状帧。

先把行数列数记住：

• 第1到第14列：OTU开销区（含帧定位信号FAS、OTU开销、ODU开销）
• 第15到第16列：OPU开销区（含映射结构指针、客户信号类型）
• 第17到第3824列：OPU净荷区（实际承载客户映射后的数据）
• 第3825到第4080列：FEC区（里德-所罗门RS(255,239)校验字节）

这个帧结构里最值钱的设计是：净荷区占3824-16=3808列，每行3808字节，4行就是15232字节净荷，而整个OTU4帧速率约111.81Gbit/s，扣掉开销后约104.355Gbit/s的OPU4净荷速率，这就是为什么100GE业务映射进OTU4时，用标称100G的客户信号填充后还有充足冗余供开销和FEC用。

3.3 为什么帧定位要专门设计一套FAS逻辑

FAS（Frame Alignment Signal）是OTN帧每行前6个字节的固定图案，设计成“OA1、OA2、OA3 + 预留”的形式。前三行是0xF6 F6 F6 28 28 28，第四行是0xF6 F6 F6 28 28 28再补位。接收侧靠这个图案在高速比特流里锁定帧边界。

实际工程中，FAS锁定这个动作看着简单，做起来非常考验硬件设计。100G单波信号速率在111.81Gbit/s左右，要在这么高的速率里一句一句地扫描比对FAS图案，对FPGA资源消耗极大。有些低端板卡在帧锁定时间上做妥协，结果就是光路闪断后业务恢复时间偏长。选设备的建议是：查一下它的帧锁定时间指标，最好在毫秒量级。

4. 映射、复用和ODUflex，OTN灵活性的真正看点

4.1 客户信号进OTN的三条路：比特异步、比特同步和通用成帧

先理解一个概念：数据只有被装进OPU的净荷区才算完成映射。客户信号类型五花八门，映射方式也分了多种，但主流的是这三类路径：

第一类是异步映射（AMP），客户信号和OTN线路时钟各自独立，通过插入/删除调整字节来适配速率差。这种映射对客户侧时钟质量要求不高，但调整机制会引入一定的时延抖动，适用于对抖动容忍度较高的业务。

第二类是同步映射（BMP），客户信号时钟锁定到OTN线路时钟，不插入调整字节，开销低、时延稳定。但这种映射要求客户信号时钟与OTN时钟同源，典型场景是SDH信号映射进OTN，因为两者时钟体系天然兼容。

第三类是通用成帧过程（GFP-F），这是最灵活的一种方式，客户信号先被切成不定长帧，再封装进GFP帧，然后映射进OPU净荷。以太网、FC、CPRI这类分组型或定长帧信号都用这种方式。

实际配置时，不同的客户信号对应哪种映射方式，设备网管上通常已经内置好了推荐选项，不用背表格。但理解映射原理还是很有必要的，因为映射方式直接影响时延和设备端口配置逻辑。

4.2 ODU0到ODU4的速率阶梯，以及一个被误解的“ODUflex”

ODU的速率等级是OTN设计里最容易被搞混的部分。我把G.709里定义的速率阶梯列个表：

ODUflex是个特别值得聊的设计。它的净荷大小不固定，而是根据客户速率动态定义，采用“n×1.25G”的步进方式，最大可到80G左右。这相当于把一个原来只按定档速率发货的物流公司，改造成了支持任意体积货物的定制服务。

我有一年在数据中心互联项目里，客户要在两个DC之间跑一段8.5G的FC存储业务。传统思路是给它分配一个ODU2（约10G速率），可问题在于ODU2的交叉容量被白白浪费了1.5G。用ODUflex之后，8.5G FC信号被GFP-F映射进一个6×1.25G≈7.5G的ODUflex容器，带宽利用率和调度灵活性都好了很多。

4.3 复用就是“集装箱拼柜”：ODTU结构怎么把小的组合成大的

OTN的复用结构可以直观类比成物流拼柜：多个ODU0拼成一个ODU1，多个ODU1拼成一个ODU2，以此类推。G.709规定了具体的复用结构和支路时隙（Tributary Slot），ODU2里有8个ODU1的时隙位置，ODU3里有32个，ODU4里有80个（按1.25G颗粒计）。

复用规则里有个很容易犯的错：不同速率等级的ODU并不能任意拼装。比如ODU2里面可以放8个ODU0，也可以放2个ODU1+4个ODU0，但ODUflex不能直接复用进ODU2的标准时隙里，必须通过一个叫ODTUflex的特殊结构间接承载。实际工程里的教训就是：以为ODUflex可以无所不能地放进任意大容器，结果在网管上配置时发现不支持该组合，只能重新规划路径。

5. FEC：从“加了校验”到“可以纠错”，这是OTN最深的护城河

5.1 RS(255,239)纠错机制到底是怎么干活的

FEC是OTN租借给传输链路的一种“容错空间”。里面用的是里德-所罗门编码，具体参数是RS(255,239)：每255个字节里，有239个是原始数据字节，16个是校验字节。这种编码能纠正每个码字里最多8个字节的错误。

你可能觉得8个字节不多，但叠加到整个系统上就很可观了。OTU4帧每行有256个FEC字节，4行总共1024个，纠错能力折合到链路上约能改善1~2dB的OSNR容限。这1~2dB意味着什么？意味着在同样的光信噪比条件下，带FEC的系统可以支持更长的无电中继传输距离；或者说，在同样的传输距离下，允许光路有更大的衰减和损伤。

5.2 软判决和硬判决，为什么200G时代都在炒SD-FEC

RS(255,239)属于硬判决FEC，输入信号被判决成0/1之后再做纠错。到了200G/400G相干时代，出现了软判决FEC（SD-FEC），它不再把信号一刀切成0和1，而是保留每个比特的置信度信息，把“模糊”的信息交给解码器去综合判断，从而获得比硬判决大得多的编码增益。

工程上，SD-FEC释放的额外增益一般能多撑1~2dB，对200G及以上速率的高阶调制格外重要。代价是芯片复杂度和功耗显著上升，解码延迟也会有几十微秒量级的增加。所以200G时代选型时，不是说SD-FEC一定就好，而是要看你的传输距离目标。如果只是城域100~300km，传统硬判决配合适当入纤功率完全够用；如果是1000km级别的干线，软判决就是刚需。

5.3 一个容易忽略的指标：FEC纠前误码率阈值

做传输维护的朋友都知道，设备网管上有个“FEC BER”的实时值，很多人在意的是纠后无误码就万事大吉。但真正需要盯的是纠前误码率预兆——当纠前误码率接近阈值时，意味着FEC的解码余量在急剧缩小，接下来随时可能出现无法纠正的错误。

各家的阈值设置不太一样，华为设备的典型告警阈值在2E-3左右，对应RS(255,239)的纠错极限附近；中兴设备一般稍保守，在1E-3~1.5E-3之间。我的习惯是：把纠前误码率的趋势告警阈值设在极限值的二分之一左右，给自己留出至少6dB的提前量。等看到纠前BER开始缓慢爬坡，而不是已经淹没FEC极限，这项工作才算做到位。

6. OAM和保护机制，凭什么传输网络敢说自己是“电信级”

6.1 三层监视体系：SM、PM、TCM各管一段

OTN的管理能力和SDH一脉相承，但它把监视能力做得更细了。整个监视体系分三层：

段监视（SM）覆盖相邻两个3R再生点之间，也就是OTUk段。这一段的连通性、信号劣化由SM开销里的TTI（路径追踪标识）、BIP-8校验等字段负责。

路径监视（PM）覆盖整个ODUk路径的端到端连接，从源端ODU交叉一直到宿端ODU交叉。PM开销里有路径状态指示、BIP-8、后向缺陷指示等，是传输维护中最常用的一层监视。

串联连接监视（TCM）是在PM之下再细分出的多个子路径监视域，G.709支持最多6级TCM嵌套。这个机制在跨运营商边界、跨设备厂商域的网络里特别实用，每一方可以独立监控自己辖区内的那一段，故障时快速确认“到底是谁的辖区里出的问题”。

6.2 路径追踪标识（TTI）：多路径混跑时怎么防止接错纤

OTN的TTI机制相当于给每个ODU分配了一个数字身份证。发送端在TTI字段里写入源接入点标识、宿接入点标识以及运营商自定义信息，接收端检测收到的TTI是否和配置期望一致。如果不一致，会上报“路径追踪标识失配”告警。

这个功能在日常维护里太有用了。波分网络里经常出现业务割接、跳纤、光纤调度，稍不留神就会把A业务接到B路径上。没有TTI检测时，可能要到业务侧发现中断或者性能劣化才能回溯；有TTI失配告警，在光层接通但数字层TTI对不上的那一刻，网管上就已经报出来了。我建议所有干线业务在创建时都把TTI规范填好，别留空，否则这个机制等于没启用。

6.3 保护倒换家族：从SNCP到ODUk SNCMP，差异在“共享备件”还是“专线备件”

OTN保护机制的家族非常庞大，名称也容易把人绕晕。我把它简化成两大类：

第一类是路径保护，典型代表是ODUk SNCP（子网连接保护），工作路径和保护路径完全独立，业务在工作路径上发，同时保护路径也传着一份相同的信号，接收端靠选择器判断用哪一路。倒换时间可以达到50ms以内，代价是带宽利用率低，一份业务要占用两份带宽。

第二类是共享式保护，典型代表是ODUk SPRing（共享保护环）或者基于Mesh网的共享备份路径。多条工作路径共享一条保护路径，平时保护路径不承载业务，只有工作路径故障时才切换过来。带宽利用率高，但倒换逻辑复杂，涉及抢占和优先级，需要全网统一规划和协调。

工程选型的原则很简单：核心骨干和政企专线，宁可花双倍带宽也上路径保护；城域汇聚里带宽紧张、业务等级一般，用共享式保护更划算。即便是同一个网络里，不同业务等级也可以混用不同的保护策略，这正好发挥OTN分层交叉的优势。

6.4 保护倒换测试：别在半夜割接时才第一次验证

我想多嘴一句实战经验：保护倒换是需要定期测试的，不是配完就完事儿了。具体做法一般是计划内中断工作路径的光纤或者拔掉发光模块，观察业务侧中断时长和网管倒换记录。

有个容易踩的坑是“双端点选择器不一致”——保护倒换要求业务源宿两端同时切换，如果某一端的路径选择器状态卡住了，就会出现倒换后单向业务不通的情况。这类问题在单端测试时往往发现不了，因为单端口环回测试的结果看起来一切正常。所以我每次做倒换验证都会要求双向业务同时拔纤，并且让对端配合确认双向业务状态，绝不允许只看一端。

7. 从OTN到骨干网业务调度：交叉连接和ROADM怎么配合

7.1 电层交叉与光层调度，为什么谁都替代不了谁

OTN设备和ROADM（可重构光分插复用器）是现代骨干网的左右手，分别管电和光。ROADM解决的是波长级的光道路由，可以把一个波从任意站点上/下，但它不知道波里面装的是什么业务；OTN交叉解决的是ODU级的电层调度，可以在任意站点把业务从这一路波搬到另一路波。

举个例子：一条100G波从A站传到D站，中间经过B、C两个站点。如果某个业务的目的地是C站，ROADM可以把这条波在C站下光，但波里面混合着多个ODU业务时，就需要OTN交叉先在C站把这路波里的ODU业务拆开，目标业务下到本地的客户端口，其余业务再交叉到另一路波长继续传。波分时代经常有人说“将来全光网就不需要电交叉了”，但混合业务的上下、梳理解复用、性能劣化时的3R再生，仍然离不开电层交叉。

7.2 电层交叉能力怎么评估：交叉容量、接入容量和颗粒度

选OTN设备时，除了看单波速率，还要重点看三组参数：

交叉容量指的是设备电交叉矩阵能处理的最大ODU带宽，中端设备一般在2T~8T量级，高端子架可以到20T以上。接入容量是设备能接入的客户侧总带宽。实际组网时还要看这两者之间的比例关系，如果接入容量远大于交叉容量，就会出现在某些方向上业务无法全部上下的瓶颈。

另一个关键参数是交叉颗粒度。老一代设备最小调度颗粒是ODU1（2.5G），新一代设备普遍支持ODU0和ODUflex级别的调度。别小看这个差距——如果一个客户的业务只有1G，而交叉颗粒是ODU1，那一个ODU1通道就只能装这一个1G业务，剩下1.5G就浪费了。

7.3 一张骨干网的业务路径设计实例

我用一个实际角度来说明路径设计流程。某省骨干网上有三个核心节点：A市、B市、C市，A到C需求是100G以太网业务，A到B是40G FC存储业务，B到C是80G数据中心互联需求。

方案选择时可以走纯OTN电路：A市100G客户信号通过GFP-F映射进ODU4，用一条100G波直驱到C市；40G FC映射进ODUflex，在A市交叉到去B市的波长通道上；B到C的80G业务映射进ODUflex，由B处的电交叉调度到C方向。这里面最需要仔细盘的环节是B站的电交叉资源——B市既有从A方向下来的40G FC，又要上到C方向的80G业务，B站的交叉矩阵必须同时塞下这两个方向的流量，同时还要预留未来扩容的余量。

这种设计如果只依赖光层直通，40G FC在A市可能就得凑齐一整条波长才能传，而实际业务量远不满一条100G波，光层直通反而造成严重浪费。OTN电层交叉的价值就是把这些“组合零散”高效拼接成整波，显著提升波道利用率。

8. 实操落地时容易踩的坑，以及我的一些行之有效的策略

8.1 开局建模时最容易忽视的开销速率

OTN网络规划第一阶段就要设计光层和电层通道，这里最容易犯的错是忘记算FEC和开销占用的额外带宽。标称100G的线路口，实际OTU4速率是111.81Gbit/s；标称400G的线路口，实际线路速率远超400G。

结果就是：如果按客户侧100G需求去设计光功率和OSNR容限，而没把111.81Gbit/s的纠后编码速率对应的更高占空比和更低的OSNR容限考虑进去，轻则中继距离算多，重则系统误码率不达标。做传输规划的朋友务必养成一个习惯：所有光层计算都基于线路速率，而不是客户速率。

8.2 时延敏感业务必须考虑FEC解码时延和映射方式差异

金融高频交易和5G前传承载对时延极其敏感，OTN的时延有几个固定组成部分：线路传输时延、映射缓存时延、FEC编解码时延和交叉交换时延。FEC解码在软判决下可能达到几十微秒的量级，映射缓冲根据映射方式不同也有明显差异。

如果时延指标特别严苛，可以考虑几个优化手段：使用无FEC开销的短距模式、选用BMP同步映射代替GFP-F异步映射、以及减少不必要的中间站点交叉跳数。这些手段每一项都牺牲了别的性能，但在关键业务上值得付出代价。实际是我做过一个金融客户的项目，他们要求单方向端到端时延不超过500微秒，最后就是靠减少TCM级数、关闭不必要的开销处理，压缩到约450微秒才达标。

8.3 多厂商设备互通，别再幻想“标准万能”了

G.709虽然是一套国际标准，但各厂商在实现上存在大量兼容性差异。最典型的是开销处理实现不一致、某些告警抑制策略不同、以及ODUflex映射方式的实际支持范围有区别。

解决多厂商互通问题的几个实操经验：第一，所有跨厂商的电路尽量以标准OTUk接口互通，别在两个厂商设备之间跑非标速率的ODUflex；第二，务必约定统一的TTI内容和告警屏蔽策略，否则一边上报大量告警、一边静默，维护人员会被搞崩溃；第三，互通测试阶段把FEC关掉测一遍又开起来测一遍，确认两端的FEC工作模式完全匹配——我有一次就遇到过两边FEC均开启但编码参数不一致，导致业务成功但纠后误码率指标始终是临界状态的情况。

8.4 网管上的“一键下发”不等于配置正确

现在主流厂商的OTN网管都支持模板化配置，从路径规划到业务下发可以“一键完成”。但我不建议过分依赖一键下发而不做人工核对，我把业务割接前的检查流程固定成这样，供大家参考：

第一，检查整个路径上每个跳点的ODU交叉是否一致，尤其注意同一业务在不同站的VCG/ODU编号是否对得上；第二，检查保护关系是否明确，工作路径和保护路径不能出现共享同一物理路由的情况；第三，检查TTI是否填写完整且与客户端口对应；第四，检查客户侧端口速率/模式选择是否匹配实际客户信号；第五，业务上线后观察至少24小时的性能监视数据，包括每分钟FEC BER的变化趋势。

这套流程虽然看起来繁琐，但它帮我拦住过至少三次本来要出大事的割接，有一次甚至是在割接前夜发现了工作路径和保护路径居然通过了同一个物理光放——如果不改，那所谓保护就是个摆设，一个光放炸了工作和保护同时中断。

9. 面对基于OSU的灵活OTN，该以什么姿势迎接

OTN体系还在演进。过去两年里，新版G.709引入了OSU（OTN小颗粒）的概念，支持最小2.6G级别的灵活带宽容器，以及对更细颗粒业务的高效承载。OSU的意义和当年ODUflex的出现有些类似——都是为了应对以太网小颗粒业务在OTN网络中的高效承载问题。

但对传输工程师来说，新概念落地还需要很长周期，现网大规模应用尚需时日。我更建议你先吃透现有的ODU体系，把交叉、保护、性能监视这些基本功打扎实。OSU真正大规模商用的时候，你会发现核心思路不变，变的只是封装的颗粒度更细了。传输网络所有设计的底层逻辑，永远是“在可靠传输的前提下尽可能灵活地适配各类客户信号”，抓住这个主线，无论技术名词怎么变，你都能快速跟上。