光传输系统软件层标准化：YANG模型与NETCONF接口实践指南

简介由开放数据中心委员会ODCC发布的《开放光传输系统光电产品软件白皮书2020》面向光传输系统架构师、数据中心网络运维人员、SDN控制器开发者和YANG模型标准化关注者。文档从YANG模型结构概览入手系统介绍OCyang模型与ODCC yang模型的架构关系、全局性原则并围绕platform标准详细阐述组件命名规则、subcomponent层次划分以及type、admin-state、oper-status、remark、led、vendor-type等共性参数。资源为单一PDF文件大小4.03MB便于下载与离线查阅。目前已有135人学习适合需要深入理解开放光传输系统软件管理规范的技术人员。通过这份白皮书读者能掌握光传输设备的核心建模思路明确设备内部各层组件的状态映射与监控方式并可用于数据中心光传输设备选型、网络管理系统设计、基于YANG的配置建模及相关标准培训提升整体运维与架构设计效率同时为区块链等依赖高可靠底层网络的分布式系统提供基础架构参考。1. 开放光传输系统的软件层到底在标准化什么一份 2020 年的白皮书到今天依然是很多 DCI数据中心互联团队做设备选型和控制器对接时的必读文档原因只有一个光传输设备的软件接口长期处于「能跑不能管」的状态。电层设备好歹有 OTN 标准撑着光层设备——EDFA、OSC、OCM、OTDR、OLP——几乎每个厂商一套私有 MIB、一套私有网管协议上层控制器接一套设备要写一套适配器运维脚本更是没法跨厂商复用。ODCC 这份《开放光传输系统光电产品软件白皮书》做的事情就是把这些光电产品的软件接口用 YANG 模型重新定义了一遍让设备的组件结构、告警事件、配置下发、软件升级、性能采集全部走统一的 NETCONF 通道。对做控制器开发的工程师来说它等同于一份可以直接对着写的接口契约对做网络规划的人而言它决定了你选型时「开放性」三个字是写在 PPT 上还是写在模型里。2. 从 OC yang 到 ODCC yang模型兼容与扩展的边界2.1 OpenConfig 模型在光传输场景的缺口OpenConfig 的 platform 模型定义了 device 级别的组件树component 可以表达子架、板卡、端口、电源、风扇但对于光层设备它明显不够用。EDFA 的增益、OSC 的监控通道、OCM 的频谱扫描、OTDR 的测试任务这些在 OpenConfig 里没有对应的数据节点。更麻烦的是OpenConfig 把 transceiver 的光功率、温度、电压放在 optical-transport 里但光放板卡的输入输出光功率、泵浦电流、增益锁定状态根本没有定义。ODCC 的应对方式很务实不推翻 OpenConfig 另起炉灶而是以 OpenConfig 为基线通过 augment 和 leaf-reference 做增量扩展保持 95% 以上的 node 一致性和兼容性。这个思路意味着一个已经适配了 OpenConfig 的控制器接入 ODCC 模型设备时不需要重写基础适配层。2.2 ODCC 扩展的两个具体手法augment 与 leaf-refODCC 扩展分两层。第一层板卡、模块、端口这种「物理存在」的特性参数通过 augment 直接挂进 platform 的 component 下第二层EDFA、OCM、OLP、OTDR 这些逻辑功能组件的特性参数不直接 augment 进 platform而是定义在独立 yang 文件中通过 leafref 关联到 platform component 的 name。这样 platform 树保持稳定新增一种光模块类型不需要动主模型。从实现角度看controller 侧处理时先通过 platform tree 枚举所有组件再按 type 判断是否需要去扩展模型中抓取深度参数两层数据结构解耦转发解析也更快。module odcc-optical-amplifier { yang-version 1.1; namespace urn:odcc:yang:optical-amplifier; prefix oa; import openconfig-platform { prefix oc-platform; } augment /oc-platform:components/oc-platform:component { when oc-platform:state/oc-platform:type EDFA; container edfa { leaf gain-mode { type enumeration { enum AGC; enum APC; } } leaf actual-gain { type decimal64 { fraction-digits 2; } } leaf input-power { type decimal64 { fraction-digits 2; } } } } }这段模型的关键在when条件只有 component 的 type 是 EDFA 时edfa 容器才有效避免非法节点污染通用组件。gain-mode区分自动增益控制和自动功率控制两种工作模式actual-gain和input-power是只读运行数据。实际环境中同一块光放板卡在不同厂商设备里增益精度和功率采样精度差异很大decimal64 的 fraction-digits 建议统一定义为 2 位否则控制器做阈值分析时会出现精度不对齐的问题。2.3 全局性原则config/state 双容器、CLI 与 NETCONF 同库、字符串长度规范OC yang 里每个可配置节点都有 config 和 state 两个容器ODCC 用一条强规则只要模型里定义为可配置的节点即使设备不支持配置config 容器下也要返回该节点配置时返回错误。这种做法对上层应用非常友好——控制器可以预先探测设备支持哪些配置项而不是把「配置报错」当成设备故障。另外一个容易被忽略的规则CLI 和 NETCONF 操作同一个配置数据库。这意味着用命令行改了接口描述通过 NETCONF get-config 必须能看到一致的结果。在开发网管系统时建议始终以 NETCONF 作为最终一致性校验的权威通道CLI 只作为应急兜底。模型里 string 类型的长度限制也值得注意通用字段上限 64 字节remark 和 text 类字段可以到 256 字节排错时如果发现某条描述写不进去先检查是不是字节数超限避免误判为协议故障。3. platform 标准详解从命名规则到光电特性参数3.1 component 命名规范化电层盒式与光层盒式的差异白皮书把传输设备粗分为电层盒式设备和光层盒式设备两类分别定义 component 命名前缀。电层设备通常指 OTN 电交叉或波分终端命名中体现槽位和功能光层设备则要体现光放、监控通道、分波合波等模块身份。实际部署时我一般建议运维团队严格按照白皮书的命名规则建立资产台账因为 YANG 模型的 leafref 依赖 name 做关联命名一乱subcomponent 的挂载关系就会错位。设备类型命名前缀示例说明电层盒式设备LINE-1-1线路板卡槽位 1端口 1电层盒式设备CLIENT-2-1客户侧板卡槽位 2端口 1光层盒式设备EDFA-1-1光放模块编号 1-1光层盒式设备OSC-1-1光监控通道模块编号 1-1光层盒式设备OCM-1-1光性能监控模块编号 1-1光层盒式设备OTDR-1-1光时域反射仪模块编号 1-13.2 subcomponent 关系如何表达板卡、模块、端口之间的树形结构subcomponent 表达的是 component 之间的从属关系典型的树形结构是子架chassis下挂主控MCU、业务板卡linecard业务板卡下再挂可插拔光模块transceivertransceiver 下挂物理通道physical-channel。模型上用 leafref 指向父组件的 name 来建立关联。实现时要特别注意subcomponent 列表是无序的控制器在渲染拓扑时不要依赖列表顺序必须显式递归构建父子树。另外同一个 component 不允许出现在两个不同的父节点下否则会造成子组件归属冲突在 NETCONF 数据校验阶段就应当拦截。3.3 共性参数type、admin-state、oper-status、led、vendor-type以 model 中 type 的 identityref 为例所有平台组件都要求支持。admin-state 是管理期望值oper-status 是设备实际运行状态两者的组合能快速定位问题——例如 admin-state 为 enabled 但 oper-status 为 failed 时基本可以判定是硬件故障或光模块松动。LED 状态也做成了可上报节点增强网管的可观测性避免运维人员必须进机房看灯。vendor-type 的存在是为了让厂商保留私有类型的同时又不破坏标准模型controller 遇到未知 vendor-type 时可以将其视为 generic 组件不影响整体告警和配置流程。component 通用 description编写规范也是白皮书重点之一大概意思是description 不写死但必须遵守长度和编码限制建议用 ASCII 码避免中文字符在部分设备上报时出现编码问题。3.4 特性参数逐个拆port、transceiver、optical-channel、power-supply、fan、cpuport 节点承载速率、端口状态和管理状态是线路板卡和客户侧板卡共用的基础对象。power-supply 和 fan 节点是数据中心设备最常出问题的物理组件oper-status 上报异常时先看电压和转速再决定是否触发更换流程。cpu 节点的使用率和温度是判断主控板健康度的关键指标建议纳入监控阈值连续 5 分钟超过 80% 就要排查告警风暴或协议震荡。transceiver 节点比 port 更下沉一层描述光模块的可插拔特征、光功率、温度、电压、偏置电流。数字诊断监控DDM信息可以从这里读出无需额外走别的协议。optical-channel 是光层特有对象承载波长的中心频率、实际发射功率和接收功率是波分侧唯一能描述光信号的通道级模型。grouping optical-channel-state { leaf frequency { type decimal64 { fraction-digits 3; } units THz; } leaf actual-tx-power { type decimal64 { fraction-digits 2; } units dBm; } leaf actual-rx-power { type decimal64 { fraction-digits 2; } units dBm; } }这段模型对应的是 DWDM 系统中单波长的光功率监控。frequency字段单位是 THz对应 ITU-T 标准的波长栅格比如 193.1 THz 就是常见的 C 波段中心频率。实际调试时经常看到网管上波长对应的频率和光模块实际工作的频率对不上多为 decimal64 小数位定义不一致或换算引入误差。actual-tx-power和actual-rx-power是排障主参考当 rx-power 低于接收灵敏度时优先查线路衰减和连接器污染而不是对端发射功率是否正常。4. RPC 接口与典型运维场景板卡生命周期与远程软件升级4.1 RPC 清单总览从 reboot 到 switch-olp白皮书定义了十几个 RPC 接口大致分成四组系统操作、文件传输、性能采集、光层专项。frequency 调测、光功率巡检、EDFA 增益调整、OSC 业务配置、OTDR 测试、OLP 倒换、告警上报都靠这些 RPC 驱动。其中 reboot 分软重启和硬重启软重启不中断电源硬重启对业务板卡影响更大通常只在软重启无效时才使用。download 和 upload 负责文件上下传get-download-status 和 get-activate-status 用于异步任务查询activate-file 则是加载新版本的关键一步。分组RPC用途系统操作reboot软/硬重启设备或板卡系统操作set-datetime设置系统时间文件操作download / upload上下传软件包文件操作activate-file / remove-file激活/删除软件包状态查询get-download-status / get-activate-status异步任务结果查询性能采集get-pm-data拉取性能监控数据光层专项switch-olp / start-otdr / stop-otdrOLP 倒换及 OTDR 测试4.2 板卡插拔场景的完整流程板卡插入后设备会先上报告警和事件通知给控制器控制器再通过平台标准查询新组件的名称和类型把配置模板下发到组件最后确认操作状态。最开始的状态是空配置插入板卡后状态变为未配置管理员配置完成变为已激活。人工拔板时控制器需要识别板卡被拔的事件并清理对应的业务配置和数据避免残留成为无效记录。板卡重新插入时可以根据历史记录自动恢复配置也可以要求管理员确认后再恢复。删除板卡时必须通过 RPC 先执行软删除确认业务已经清理完毕后才允许物理拔板否则可能造成配置残留。预配置场景是提前把板卡配置文件下发到设备插入相同类型的板卡后自动匹配预配置内容这个过程的核心是「配置模板」与「板卡类型」的匹配逻辑可以在 yaml 文件中按板卡类型定义模板插入时按匹配的模板自动下发配置。这套流程实现的关键是开发一个板卡配置模板库并对每个板卡类型定义默认属性避免误配。4.3 软件升级流程从版本查询到激活确认rpc message-id201 xmlnsurn:ietf:params:xml:ns:netconf:base:1.0 activate-file xmlnsurn:odcc:yang:platform file-nameols-2024.10.1.bin/file-name activate-typeset-active/activate-type /activate-file /rpcACTIVATE 操作的activate-type有两个取值set-active 表示将指定版本设为下次启动的生效版本但不在本次重启后立即生效set-active-plus-reboot 表示立即重启设备并加载新版本适合有维护窗口的场景。生产环境中建议使用两步走的方式先用 set-active 保存配置再通过 reboot 进行重启这样如果 activate 校验出问题还能及时回退到当前版本而不必重新上传老文件。执行 activate 前要检查目标文件的完整性可以从设备上再 download 回来做一次 MD5 比对。整个软件升级流程的三个阶段是查询当前版本确定升级路径将版本文件上传到设备检查上传状态直到成功激活版本并等待设备重启完成。版本回退同样要保留老版本文件不要删除否则一旦新版本出现严重问题回退就非常被动了。4.4 逻辑说明与边界情况RPC 是一类特殊的协议操作与 get-config 或 get-state 的读操作不同它会真正改变设备状态。在实际使用中RPC 的返回结果里既有提交成功的信息也有潜在的失败原因必须检查完整的返回信息而不仅仅是状态码。特别是在大文件上传时设备可能因为存储空间不足导致传输中断控制器需要先通过剩余空间查询来预处理而不是在执行到一半时才报错。另外不同厂商对 download 的支持程度不一样部分老款设备只支持 HTTP 方式下载不支持 NETCONF 流式上传开发适配器时需要提前做个能力探测避免在 RPC 层面死磕。5. OTN 通道建立、OSC 配置与告警订阅的落地要点5.1 从电层到光层OTN 业务创建逻辑的映射关系业务创建过程中ODCC yang 模型非常强调逻辑与物理的解耦。logical-channel 是设备上承载业务流量的逻辑通道抽象它不直接绑定物理 port而是通过 assignments 挂到 physical-channel 上物理通道再关联到具体的 optical-channel通过这样一层层的映射业务流量才真正落到光层波长上。如果后续光层拓扑发生变化只需调整 assignments 中的映射关系而不需要重建整个业务对象。OTU 板卡的建模就是这种思路的典型业务先从客户端口进入经过 OTN 交叉连接后映射到线路侧某一块板卡的某个波分通道在配置逻辑上创建一条业务需要先创建 logical-channel 并配置映射方式再把线路侧端口关联到对应的光层通道。rpc message-id301 xmlnsurn:ietf:params:xml:ns:netconf:base:1.0 edit-config target running/ /target config terminal-device xmlnsurn:odcc:yang:terminal-device logical-channels channel index1/index config descriptionDC-A to DC-B 100GE/description loopback-modenone/loopback-mode test-signalfalse/test-signal /config otn/ ethernet/ ingress config transceiverCLIENT-1-1/transceiver /config /ingress logical-channel-assignments assignment index1/index config assignment-typeoptical-channel/assignment-type optical-channelOPTICAL-CHANNEL-1/optical-channel /config /assignment /logical-channel-assignments /channel /logical-channels /terminal-device /config /edit-config /rpc这一段配置涵盖了业务创建的左右两侧ingress 定义了业务从哪个客户侧光模块进来logical-channel-assignments 定义了这个逻辑通道映射到哪个光层通道。loopback-mode有三个选项 none、mac、line分别对应不环回、MAC 层环回和线路侧环回测试信号可以不用依赖仪表就完成链路验证。实际配置时容易掉坑的地方在于ingress 与 logical-channel-assignments 必须同时配置否则通道会处于半连通状态业务不通但告警不明显。5.2 OSC 接口配置业务、管理、DCN 共用监控通道OSC 是光传输系统里最容易和带外管理端口混淆的对象。很多新接触波分系统的工程师会把 OSC 和管理网口当成一回事实际上二者的定位完全不同。OSC 是光监控通道走的是光层面单独的监控波长带外管理端口则是设备上的一个以太网口两者承载的流量类型也不同OSC 上除了 DCN 管理流量之外还可以承载光放段间的一些 OAM 信令。在实际组网中OSC 接口的配置要点是分配一个独立的 IP 地址段并确保该地址段不影响业务和管理平面。配置方式一般是标准的 interface 模型设置 IP 地址、子网掩码和端口状态。需要注意OSC 连接的主光缆如果发生中断OSC 可能同时失联这时网管仍然可以通过带外管理端口访问到设备所以在部署规划时不要把两个平面绑在同一个光纤路由上否则故障时管理通道同样不可达。5.3 告警模型与告警订阅从 alarm-notification 到事件分类5.3.1 type-id 分类与描述规范告警模型是最体现工程价值的部分。type-id 采用统一分类光衰减类、光功率异常类、温度异常类、电源异常类每类都有标准编码和描述模板。告警描述统一要求带上资源名、阈值、当前值例如 EDFA 输入光功率低这比传统网管上只显示「光功率告警」有排障价值的多。实际上这个描述模板应该直接作为控制器渲染告警文本的默认格式避免每套网管写的拨测告警文案各不相同。5.3.2 notification 报文格式notification xmlnsurn:ietf:params:xml:ns:netconf:notification:1.0 eventTime2024-11-20T14:32:10.123Z/eventTime alarm-notification xmlnsurn:odcc:yang:alarms type-idOPT-PWR-EDFA-LOW/type-id severitycritical/severity resourceEDFA-1-1/resource textinput power -32.5dBm below threshold -30dBm/text /alarm-notification /notification这段 notification 的关键在 resource 字段它直接对应 platform 里的 component name控制器收到告警后可以立刻通过 resource 值去关联组件树而不用再去解析 text 内容。severity 使用标准级别接入 Prometheus Alertmanager 或自有告警平台时可以直接映射。实现上建议订阅所有 alarm 类通知和非告警类 event 通知因为部分业务恢复事件不以告警清除的形式上送不订阅会漏掉恢复状态。5.4 一个值得保留的验证技巧开发完 NETCONF 适配层后第一件事不是跑业务而是用 get-config 和 get-state 分别拉取一份全量数据做 diff。同一配置项如果 config 和 state 不一致说明设备没有真正接受该配置常见原因是模块型号不支持或参数越界。这个验证方法比分功能测试更早暴露出模型层面的兼容性问题建议写进适配器的自测用例。同样在业务割接前先用环回模式验证逻辑通道连通性再用测试信号字段打一层 LOPC 测试帧比对两侧光功率读数是否一致这一套做下来再上真实业务成功率会比直接配置高很多。本文还有配套的精品资源点击获取