简介ITU-T G.873.1《光传送网OTN线性保护》标准中文版是面向光通信网络规划、运维及设备研发人员的重要技术文件专注于ODUk层面的线性保护机制解决网络故障时快速保护倒换与业务连续性保障问题。标准详细定义了配备固有监控功能的ODUk子网络连接保护11和1:n、配备非侵入式监控功能的ODUk子网络连接保护11、以及配备分层监控功能的ODUk子网络连接保护11和1:n三类保护架构并规定了APS自动保护倒换协议的操作流程包括端到端命令、状态处理和本地命令等以最小化服务中断时间。该中文版为单个PDF文件压缩包大小约1.06MB便于离线查阅、打印和团队内部分享。目前已有508人学习下载适合光通信工程师、网络规划者和运维人员深入掌握OTN保护机制作为网络设计、配置和故障排查的参考依据。1. G.873 管的是断纤之后OTN 保护倒换协议族入门地图做过光网络OTN系统割接的人都有这个记忆业务加波顺利、光功率调平真正让人手心出汗的是那场断纤演练。主用光缆一拔业务在多少毫秒内切到备用路径上不是靠设备型号决定的而是靠一套协议标准约束的这就是 ITU-T G.873 系列。这份 G.873 标准 OTN 协议标准中文版把 G.873.1 线性保护、G.873.2 共享环保护、G.873.3 恢复机制以及配套的 G.709 帧结构术语翻译整理到了一起适合传输网维护、设备调测以及刚入行想搞懂 OTN 保护设计的工程师。它解决的不是“光怎么传”而是“断了怎么切、切了怎么恢复、两个方向怎么保持一致”。2. 从协议坐标系看懂 G.873它和 G.709、G.872 分管的不是同一件事很多刚接触光网络的人会问网络标准协议到底是什么为什么光网络里同时有 G.872、G.709、G.873 三个编号手里摆着三份文档不知道先翻哪一份。我的回答是三份都要看但各管一段。G.872 讲的是网络架构G.709 讲的是接口、帧结构和开销字节G.873 讲的是保护倒换。这也是为什么单独下载一份 G.873 中文版还不够最好手边再放一张 G.709 的帧结构图因为 G.873 里所有倒换行为最后都要落到 G.709 定义的开销字节上。理解了这层关系再去看设备网管上那些保护配置选项就不会觉得它们是黑匣子。2.1 G.873 在整个 OTN 标准族里的位置用一张表画坐标把三份最常被混用标准摆在一张表里各自管什么、你会什么时候翻到它一目了然。标准编号它管什么你会在什么场景用到它G.872OTN 网络架构、分层模型、保护架构的顶层概念做网络拓扑规划、设计保护层级时G.709OTN 帧结构、OTU/ODU/OPU 速率、映射路径、开销字节定义读帧格式、查开销字节位置、做线路映射时G.873OTN 保护倒换机制线性保护、共享环保护、恢复机制配置保护、分析倒换失败、做保护验收时G.873 本身不是一个单本建议书而是一个系列。G.873.1 定义线性保护倒换G.873.2 定义共享环保护 ODUk SPRingG.873.3 定义恢复机制。对运维人员来说读 G.873 系列读的是“什么时候该切、怎么切、切完怎么回来”这三件事。如果你在网管上创建保护子网时看到一堆保护类型下拉选项比如 11、1:1、ODUk SPRing那些选项的背后逻辑就是 G.873 系列里定义的状态机和优先级。把标准术语和设备界面上的叫法对应起来排障时能少走很多弯路。2.2 11 与 1:1两种线性保护的工程差异比想象中大11 和 1:1 是 OTN 保护里最基础的两类但实际工程中它们的差异体现在发端行为、是否依赖 APS 协议、保护通道能否跑额外业务三个方面。11 单向保护的典型特征是发端固定桥接信号同时发往工作和保护两条路径收端自己选择质量好的一路。因为发端不需要和对端商量这个模式可以不依赖 APS 协议是速度最快、逻辑最简单的一种保护。11 双向保护则需要两端协商保证两个方向的业务都走同一条路径因此必须依赖 APS 通道传递状态否则会出现 A 端选工作、B 端选保护的情况。1:1 保护平时只在工作路径上传业务保护通道是空闲的可以被低优先级业务占用断纤时通过 APS 协商切到保护通道。它比 11 省带宽但倒换逻辑复杂还牵扯到额外业务抢占的问题。如果保护通道上跑着非保护业务倒换发生时这些业务会被强制丢弃这个行为在设计之初就得跟业务方讲清楚。保护类型发端是否双发是否依赖 APS 协商保护通道能否跑额外业务常见应用场景11 单向是否不能高价值点到点大客户专线追求倒换速度11 双向是是不能需要两端路径状态严格一致的政企专线1:1否是可以倒换时被抢占波长资源紧张想利用保护带宽的场景2.3 环网共享保护省一半波长多一套状态机G.873.2 定义的 ODUk SPRing共享环保护是 SDH 时代 MS-SPRING 思路在 OTN 里的延续核心价值是保护带宽被多个 ODU 业务共享而不是每条业务独占一条备用路径。比如一个只有两个方向的环网配置 ODUk SPRing 后环上的保护时隙可以被多个业务段共用相比每条业务都做 11 独占保护能明显节省波长资源。代价是协议状态机变重了环上每个节点都要感知故障位置、维护桥接和倒换状态还要处理额外业务的抢占优先级。在工程上ODUk SPRing 比 11 难调尤其是二次故障场景——第一根纤断了还没恢复第二根纤又断了这个时候是丢业务还是保住现有连接完全取决于保护协议对优先级的实现。这个场景也是标准里花了大量篇幅定义、设备联调时最容易暴露问题的地方。2.4 怎么选保护不是越快越好而是看业务等级和带宽成本选保护类型时我一般按四个维度判断业务等级、带宽成本、网络拓扑、运维熟练度。如果是跨机房、跨城市的政企专线业务等级高带宽不缺直接上 11 单向保护倒换快故障定位也简单。如果业务是普通的互联网中继流量带宽成本敏感环网拓扑可以考虑 ODUk SPRing 共享保护省波长但要接受协议复杂度带来的排障难度。还有一个实际经验是不要为了“看起来高端”而选择复杂的保护方式。很多网络的故障其实发生在人工割接时而不是光缆中断时。11 单向保护的状态少割接时每一步都看得见摸得着反而比复杂的共享环保护更稳妥。先把简单保护用熟再上共享环保护这是我在多个项目里验证过的顺序。3. 开销字节里的心跳ODUk 怎么感知断纤、APS 怎么商量倒换G.873 的倒换不是设备凭空拍脑袋决定的而是由开销字节驱动的。G.709 帧结构是 4 行 4080 列里面分 OTUk 开销区、ODUk 开销区和 OPU 开销区。对保护倒换来说最重要的是 ODUk 开销区里的 PM路径监测、TCM串联连接监测和 APS/PCC 通道。很多工程师在网管上看到“ODUk-AIS”“ODUk-LCK”“BDI”这类告警只知道它们是故障不清楚它们和倒换有什么关系。实际上这些信号就是保护状态机的输入。G.873 定义的是“收到这些信号后怎么响应”G.709 定义的是“这些信号怎么放在开销字节里通知对端”。两本标准配合起来才构成完整的一套保护机制。3.1 故障感知顺序从光口丢失到路径告警一级一级往上传递一条业务中断最先感知到的不是 ODUk 层而是最底层的物理光口。把这个顺序理清楚排查时会省很多时间。从下往上看光口丢失或光功率劣化产生 LOS。OTUk 帧同步丢失产生 LOF复帧丢失产生 LOM。这些属于线路层的缺陷。再往上是路径层上游故障时下游会收到 ODUk-AIS、ODUk-LCK 或 ODUk-OCI它们的作用是告诉下游“我不是自身故障是上游断了”。其中 ODUk-AIS 尤其重要它让整条链路上的中间网元不会因为收不到信号而刷出一堆无关告警只有真正需要参与保护倒换的节点才做出响应。告警或信号所在层次对保护倒换的含义LOS光层物理接口光口收不到光可能触发线路保护或直接中断业务LOF / LOMOTUk 线路层帧同步或复帧同步丢失通常是上游线路故障或误码严重ODUk-AISODUk 路径层上游故障插入的告警指示信号触发路径保护倒换的关键依据ODUk-LCK / OCIODUk 路径层链路连接未建立或路径被打开维护场景下会阻止倒换3.2 SF 和 SD误码多严重才算“线路不行”除了硬性断纤还有一种常见故障是线路误码急剧升高但链路没有完全中断。这时候就要靠 SF信号失效和 SD信号劣化阈值来判断是否触发倒换。G.709 在 SM段监测和 PM路径监测开销里用 BIP-8 做误码统计G.873 基于这些统计结果定义 SF 和 SD 状态。工程上SF 对应比较严重的误码SD 对应轻微劣化。阈值设得太灵敏线路上一阵瞬断误码就会频繁倒换导致业务反复抖动阈值设得太迟钝线路真的在劣化保护却迟迟不动作。不同设备对 SF/SD 的门限默认值不一样有的按 BER 1e-3 判 SF有的按 1e-6 判 SD具体数值要以设备手册为准但理解这个概念能帮你在网管上找到正确的参数位置而不是面对一堆“PBER”“SD threshold”选项发懵。3.3 APS 通道优先级从高到低倒换消息怎么传双向 11 和 1:1 保护都要依赖 APS 协议来协商两端状态。OTN 的 APS 信息承载在 ODUk 开销的 APS/PCC 通道里思路和 SDH 的 K1/K2 字节一脉相承但字段定义不同。G.873.1 给出了一套请求优先级顺序从高到低大致是锁定、强制倒换、信号失效、信号劣化、人工倒换、等待恢复、无请求。这套优先级解决了“两个方向同时检测到故障时听谁的”这个问题。举例来说A 端到了人工倒换请求B 端同时检测到信号失效那么两端的最终动作是听信号失效的因为它的优先级更高。排障时如果看到业务没有按照你的操作意向走先看当前有没有更高优先级的请求压着。很多“我下了人工倒换命令但业务没动”的案例最后查出来都是有一端还在报信号失效把人工倒换请求压住了。3.4 50ms 时间预算检测、拖延、桥接、恢复四段时序工程上常说 OTN 保护倒换要满足 50ms 目标但这个 50ms 不是单一动作的耗时而是从故障发生到业务切到保护路径的完整时间。拆开看有四段第一段是故障检测时间光口和 ODUk 层检测故障通常在毫秒级。第二段是 Hold-off 延迟这是故意等的一段时间用来避开瞬时抖动干扰可以配 0 到 10 秒。第三段是 APS 信令传递加桥接切换这也是毫秒级。第四段是两端确认状态然后业务恢复正常。在网管上配置保护参数时Hold-off 设成几秒倒换总时间就会很自然地超过 50ms这不是设备有问题而是参数本身就是这么设计的。所以做保护验收时先看仪表测出的丢包窗口再结合设备的倒换启动时间戳比对就能定位时间花在了哪一段。4. 在网管上落地 11 保护创建路径时的参数顺序与验收习惯标准读完之后最终要把 G.873 的行为落到网管配置上。这里以最常用的 ODUk 11 保护为例讲一遍从选保护对象、创建路径到检查参数的流程。有个常见误区是很多工程师把保护配置当成“选一个 11 选项就完事”结果就是参数看着都选了实际故障时倒换起不来。其实 G.873 对 11 保护的定义是完整的涉及发端行为、收端选择、APS 通道、恢复模式等多个维度的组合每一个维度在网管上都有对应的参数项漏一项就会出问题。4.1 第一步是确定保护对象ODUk 还是 ODUflexG.873 的保护对象是 ODUk 路径常见的包括 ODU0、ODU1、ODU2、ODU3、ODU4以及速率可变的 ODUflex。工程里 ODU1 和 ODU2 用得最多大致对应 2.5G 和 10G 级别的业务。ODUflex 保护在标准上是支持的但对两端网元的能力和业务单板类型有要求老网元不一定支持。在网管上创建路径时第一步选的就是“这个业务是 ODU几”。如果选择过小业务装不下选择过大浪费带宽。路径等级确定后再选保护类型和具体参数。我的习惯是在设计阶段就把 ODUk 等级写到业务开通单上和客户确认清楚避免到了网管上再回头改。4.2 创建保护路径的通用流程六个步骤一个都不能少以主流的 OTN 网管操作为例创建一条 ODUk 11 保护路径常见流程是下面六步第一步创建端到端子网连接填写源、宿网元和时隙确认业务带宽。第二步选择保护类型在 11、1:1、SNC、ODUk SPRing 等选项里选 11。第三步指定工作路径和保护路径的路由勾选 SRLG 分离检查让网管计算两条物理上不同路由。第四步设置保护参数包括恢复模式、WTR、Hold-off、SF/SD 门限。第五步下发配置等待保护子网状态变为“无请求”或“正常”。第六步做人工倒换测试强制切到保护路径确认业务恢复再切回工作路径。第三步和第六步是最容易被跳过的。SRLG 分离检查如果没做工作路径和保护路径可能走同一个光缆开孔真实断缆时两条路径同时断保护形同虚设。第六步的人工倒换测试则是验证 APS 通道和桥接动作是否真的有效这比在纸面上看配置要有说服力得多。4.3 参数表填表而不是背概念下面这张表是我在网管上核对保护配置时常用的参数清单每个参数对应一个工程判断直接照着核对比翻标准更实用。参数项常见配置现场怎么调恢复模式返回式业务不允许反复中断时考虑非返回式WTR 等待恢复时间300 至 600 秒出现路径振荡时调大Hold-off 拖延时间0 至 10 秒瞬断误触发倒换时调大SRLG 分离检查必须勾选割接或整改时重新校验物理路由SF/SD 门限按设备默认模板倒换频繁时调整以设备手册为准恢复模式的意思是工作路径恢复后要不要切回去。返回式是切回非返回式是继续留在保护路径上。WTR 的作用是给工作路径一个稳定期防止它一恢复就立刻切回产生新的瞬断。Hold-off 则是倒换前的等待时间适合在光功率抖动频繁的链路上使用但会延长倒换总时间要权衡。这些参数没有绝对的正确值只有适合当前网络状态的值。4.4 跨网元、跨厂家时的附加检查项如果工作路径和保护路径经过不同厂家的网元APS 状态需要跨设备协商此时要重点确认 ODUk 开销里的 APS/PCC 字节在中间节点是透传还是终结。TCM 被中间网元终结的场景常常导致对端收不到正确的 APS 状态表现为“网管上两端都显示正常但一倒换就失败”。这种问题单看网管界面很难发现需要用支持开销分析的仪表抓一下 ODUk 开销直接读 APS 字节的实际内容。5. 避坑与排查G.873 保护配置里最典型的四类翻车现场前面讲的是标准逻辑和标准操作实际网络里真正消耗时间的往往是那些看起来不起眼、却会让整个保护形同虚设的细节。下面四条是我在现网里遇到过的真实问题按“现象、原因、解决”三步还原可以当作排查手册来用。5.1 人工倒换测试正常真实断纤时业务全断现象割接前做人工倒换测试网管下发强制倒换业务正常切到保护路径再切回工作路径也正常。结果真实光缆被挖断时业务直接中断保护完全没有起作用。原因工作路径和保护路径在物理上走了同一条光缆或同一个管道。业务正常时两条路径都通人工倒换也能成功而真实断纤一断两条路径同时断了保护失效。这种故障的本质是 SRLG 未做分离检查两条路由在物理层存在共享风险。解决网管上查看已创建保护子网的路由视图确认工作路径和保护路径的所有物理段是否重叠。设计阶段必须勾选 SRLG 分离约束或对光缆纤芯资源做专门的路由核查。如果两条路径所在的物理路由无法完全分离就该从源头上重新规划设计而不是继续硬扛。5.2 双向 11 保护两端状态不一致业务反复中断现象配置的是双向 11 保护A 端显示工作路径正常B 端显示保护路径在用两个方向业务分别走了不同路径某一段单通或出现丢包。原因双向 11 要求两个方向的收端选择一致依赖 APS 通道协商完成。如果中间网元把 APS 字节处理掉了或者两端一次侧配置的保护属性不一致就会出现两端状态不同步。解决先在网管上确认两端保护子网的属性完全一致特别是保护类型、方向、恢复模式。然后下一边人工倒换命令观察另一端的 APS 状态是否跟随切换。如果对端状态不动重点排查中间节点的 ODUk 开销透传配置用仪表抓 APS 字节确认它在链路中是否完整到达对端。5.3 工作路径恢复后业务在工作保护之间来回振荡现象光缆修复后业务没有平稳切回工作路径而是每隔几十秒或几分钟就来回倒换一次每次倒换都可能产生丢包。原因WTR 参数设成了 0或者设得太短工作路径一恢复保护协议立刻发起切回。但切回瞬间工作路径上可能还有残余误码又触发了新的倒换形成振荡。SD 门限设得过于灵敏也会放大这个问题。解决把 WTR 调到 300 秒以上给工作路径一段稳定观察期。同时检查 SD 门限配置确认它不会因为极轻微的误码抖动就判定劣化。对重要的政企专线非返回式模式能直接避免振荡代价是工作路径恢复后业务会继续占用保护路径直到人工干预。5.4 倒换时间实测超过 50ms但网管上所有状态都正常现象用测试仪表打流人工下发倒换命令仪表记录的丢包窗口超过 100ms远超 50ms 的验收目标。原因最常见的是 Hold-off 设置过长它本来就设计了延迟其次是 APS 协商路径上的网元数量太多开销处理耗时累计还有一种可能是跨域保护在域间没有做 APS 转发倒换请求要通过上层管理平面中转耗时被拉高到秒级。解决第一看网管上的保护和常规记录找到倒换启动时间戳再和仪表测出的丢包时间窗口做对比。如果丢包时间大于倒换启动时间问题出在检测或 Hold-off如果倒换启动时间本身偏长问题出在 APS 协商和中间节点处理。先缩短 Hold-off再查跨域组件配置逐一排除后再复测。6. 进阶用一次人工倒换演练把 50ms 目标做成可验收的事实读了标准、配了参数之后最后一步是把 G.873 的行为变成你随时可以验证的事实。我的做法是不走网管的“状态正常”四个字而是用一次主动倒换演练把保护和倒换时间窗口完整测一遍。先在 OTN 测试仪或以太网误码仪上打满业务流量速率接近但不超过端口容量确认测试过程无丢包。然后在网管上对保护子网下发强制倒换命令切到保护路径同时观察仪表的丢包窗口。丢包窗口结束的时刻就是业务在保护路径上重建的时间这段时长就是本次倒换的实际耗时。恢复时再做一遍同样操作切回工作路径同时观察 WTR 计时是否按配置生效。测试项操作预期结果判定标准初始业务验证仪表打流 5 分钟无丢包、无误码业务通道正常人工倒换到保护路径网管下发强制倒换仪表出现一段丢包窗口后业务恢复丢包时长符合设计目标一般按 50ms 以内评估APS 状态一致性倒换后查看两端保护子网状态两端同时指示保护路径在用两端状态一致恢复切回工作路径下发恢复命令或等待 WTR业务切回无反复振荡单次切换切回后状态稳定保护带宽占用复核查看保护路径时隙占用情况保护通道上无意外占用业务与设计一致这套流程跑完之后保护能不能用、倒换时间是多少、两端状态是否一致全部有实测数据可查而不是凭感觉。进阶一点的验证是用支持开销分析的仪表直接看 ODUk 里的 APS 字段在人工倒换瞬间抓一拍确认请求状态、桥接状态和优先级都按预期变化。这样就算网管界面黑匣子化也能抓到最底层的协议证据。我最早验收 G.873 保护时只验证了工作路径好用保护路径没做真实断纤测试结果后来一次施工导致工作保护两条路由同时中断业务断了十几分钟。从那以后我每次做保护验收都强制走完整套流程拔纤、测倒换时间、恢复、等 WTR、再拔纤两轮下来才敢签字。希望帮到你。本文还有配套的精品资源点击获取