简介开放数据中心委员会ODCC发布的《开放光传输系统光电产品软件白皮书2020》聚焦光传输系统软件层面的标准化与智能化面向光网络设备研发、数据中心运维及网络管理平台建设者。该白皮书以YANG模型为核心系统阐述OCyang基础模型与面向开放数据中心扩展的ODCC yang模型并通过全局性原则保障跨设备互操作性。在平台标准部分详细定义电层与光层盒式设备的组件命名规则、subcomponent关系以及type、admin-state/oper-status、led等共性参数为设备识别、状态监控和可视化管理提供统一规范。资源为单个PDF文件大小4.03MB已有135人学习浏览。借助这份标准框架读者可快速掌握开放光传输系统从建模到组件管理的完整设计思路适用于优化数据中心光传输架构、提升运维效率与系统可靠性等场景。1. 开放光传输系统把光层判决权从网管交还给了软件光传输网的维护者长期面对一个尴尬局面ROADM、EDFA、OTN终端这些光电设备每一家的网管系统都是独立的配置界面上能看到的参数不少能真正自动化的接口却寥寥无几。跨设备做光功率均衡往往要打开两三个网管、手工换算偏置值、等人工确认一个波长上下路操作可能要预留十分钟。这背后是设备商用私有协议和封闭北向接口把光层闭环锁在了自家系统里。开放光传输系统的思路正好相反把光层设备也当成可以被控制器或编排器直接管理的通用资源。光电产品的软件白皮书2020之所以值得翻一翻是因为它把视线引向三个具体问题——硬件抽象长什么样、控制接口用什么协议承载、以及光层参数在软件侧如何建模。对正在做DCI网络自动化、集群互联带宽调优或多厂商混纳光层的工程师来说这些内容直接对应到生产环境里能落地的器件选型和控制逻辑。2. 光电产品软件白皮书里的第一件事给光器件立一套语义2.1 光层设备被抽象成什么直接决定上层控制能写多细光电产品里可被软件控制的对象常见的有四类。波长选择开关WSS控制每个通道的功率和方向掺铒光纤放大器EDFA维持光纤段的总功率和增益MCSMulticast Switch多播开关负责无色/无方向/无竞争的分插复用相干光模块或DSP负责电域补偿和调制格式切换。这四类器件物理差异很大却都需要被同样的方式描述否则控制器就谈不上统一编排。从开放光传输系统的角度软件侧一般不直接去控制激光器电流或衰耗器的具体步进而是把每个器件抽象成若干可读写的意图参数。比如WSS被抽象成”某个频率的通道在某个方向上目标输出功率是多少“EDFA被抽象成”总输出功率和增益目标“。白皮书2020对这类器件抽象的贡献是把它们统一映射到了YANG模型中并附带可运行的软件结构建议。这样上层业务调度波长算路、频谱分配和下层硬件行为之间就有了一条清晰的翻译链路。2.2 关键是把”频率“”功率“”光口“定义成一致的单位和语义不同厂商对光功率的单位、绝对精度和取值范围定义并不相同这导致即使北向接口都用NETCONF字段映射起来也极其痛苦。开放光传输系统的软件白皮书2020推动的正是把单位统一到标准物理量上衰耗用dB功率用dBmOSNR用dB网格用GHz或THz表示绝对频率。用YANG模型约束这些单位之后控制器下发和读取的数据就不会出现“-3.0到底是mW还是dBm”的歧义。module: org-openroadm-device --rw roadm --rw wss --rw degree --ro wavelength-number? uint16 --rw span-loss? decimal64 --rw output-power? decimal64 --rw line-port-ref --rw amp --ro operational-state? enumeration这是一段简化的光层设备模型结构。span-loss定义光纤段损耗output-power定义该方向目标输出总功率wavelength-number标明当前实际承载的通道数。上层控制器可以通过修改这些节点来请求调整目标功率而底层软件负责将意图转成硬件寄存器值。参数语义统一正是这套体系的直接收益多厂商设备之间的差异被收窄到驱动适配层。2.3 开放光传输系统软件栈里常见的光电资源属性表属性名物理含义常见单位取值范围示例控制层面用途Frequency通道中心频率THz191.35 ~ 196.10波长选路、频谱分配OutputPower目标输出功率dBm-20 ~ 5功率均衡、EDFA目标设置SpanLoss光纤段插入损耗dB0 ~ 30补偿增益估算OSNR光信噪比dB12 ~ 35性能监测、FEC余量判断ModulationFormat调制格式枚举DP-QPSK / DP-16QAM速率协商、入网能力匹配这些属性在物理上是连续的但控制面上必须离散化和规范化。模型里会把功率精度限制在小数点后一位把调制格式固化成枚举值这便于控制器做约束求解——算路时不用考虑厂商私有能力描述。2.4 为什么控制面要围绕“功率”而不是“衰耗”做闭环传统网管经常暴露的是每级VOA可变光衰耗器的衰耗值但功率才是系统最终关心的指标。开放光传输系统的软件逻辑会把“合适的通道功率”作为控制目标衰耗器只是实现目标的手段。这个视角差别影响着闭环策略的设计围绕衰耗做的系统每次加减波长都要人工推算插入损耗变化围绕功率做的系统控制器可以直接比较目标功率和实测功率差值就是控制误差这让自动化算法变得简单。需要注意的是功率目标一旦发生变化必会影响同一光放段内其他波长。因此软件白皮书2020里会强调关联控制典型做法是在同一个degree下的所有波长共享一个总功率目标单个波长调整时软件侧差额分配给其余通道。这也是后续所有自动化配置脚本都需要考虑的基本逻辑。3. 用YANG和NETCONF把开放光传输系统控制器跑起来3.1 先分清OpenROADM和OpenConfig两套模型的分工在开放光传输系统的软件实践中两套YANG家族经常同时出现。OpenROADM模型偏设备侧对ROADM光层行为的描述非常详细比如节点内每个degree、每个wss端口、每个光放模块都有专门容器OpenConfig则偏网络侧和网元通用属性对转发面、接口和遥测的描述更简洁常用于跟已有交换机控制器对接。实际部署中面向光传输网元做配置下发时OpenROADM模型更贴合白皮书2020所描述的器件抽象面向上层编排器做统一网络视图时OpenConfig模型更容易与既有IP网络管理框架融合。采用哪种模型不是非此即彼的问题很多落地系统会把两套模型做映射OpenConfig接口下发业务意图内部转换成OpenROADM设备模型的动作。3.2 最小实验用ncclient读取光层节点的输入功率和OSNR动手验证这套体系并不需要真实ROADM一个支持NETCONF的设备模拟器就够。下面的Python脚本读取了光层节点上某个degree的输入功率和对应通道OSNR。这类操作是任何开放光传输系统控制器的起点先能读才能谈闭环。from ncclient import manager def fetch_optical_power(host, port, user, password, degree_id): # 建立NETCONF会话 with manager.connect( hosthost, portport, usernameuser, passwordpassword, hostkey_verifyFalse, device_params{name: default} ) as m: # 构造过滤条件获取指定degree下的光放输入功率 filter_xml f roadm xmlnshttp://org/openroadm/device degree degree-id{degree_id}/degree-id amp input-power/ /amp /degree /roadm result m.get(filter(subtree, filter_xml)) return result.xml if __name__ __main__: # 常见测试参数模拟器常开830端口官方示例默认端口 xml_resp fetch_optical_power(192.0.2.10, 830, admin, admin, 1) print(xml_resp)这里用manager.connect建立了NETCONF会话filter参数用子树的XML方式圈定读取范围。之所以筛选到amp容器是因为光放模块是观测输入功率最直接的点位。实际生产环境会额外要求先通过.well-known机制做能力探测确认设备支持org-openroadm-device模型再发请求否则部分网元会直接返回错误节点。3.3 白皮书2020中软件栈里的核心接口从CLI到NETCONF的迁移要点迁移到NETCONF之后最大的变化不再是通道建立方式而是状态维护方式。CLI时代一切以回显文本为准脚本里满是正则匹配NETCONF时代状态以XML数据模型为基准查询结果天然结构化。但副作用是对设备能力集的探测反而比CLI更复杂——不同型号对同一个容器可能支持不同的叶子节点控制器的能力注册表必须跟上。开放光传输系统软件白皮书2020对这个问题的建议通常是把设备能力描述独立为一份元数据文件设备注册时上送控制器据此动态装配可调参数菜单。这样做的直接好处是新老设备的差异被挡在一个适配层上层编排不用为每个型号写死参数列表。工程上常见的做法是让设备在NETCONF中暴露capability列表控制器首次接入时缓存一份映射表。3.4 遥测模型与功率漂移感知NETCONF同步拉取适合低频操作功率均衡这类需要快速感知的场景则依赖遥测。常见做法是订阅光层节点的output-power和osnr叶子节点每1到5秒推送一次数据。数据一旦落库控制器就可以做漂移检测和闭环纠正。这套机制的实现细节往往写在白皮书2020的软件架构章节里落地的核心参数是推送周期和有效告警阈值。{ openconfig-telemetry:subscription: { paths: [ /roadm/degree/amp/output-power, /roadm/degree/amp/osnr ], sample-interval: 2000, suppress-redundant: true } }上面的JSON是遥测订阅的简化配置。sample-interval设为2000毫秒这是光功率波动场景里一个可接受的折中suppress-redundant开启后只有数值超过变化阈值才上送减轻控制器处理压力。真正生产环境还要在订阅列表里加入FEC余量和激光器偏置电流后两者能更早暴露硬件劣化趋势。4. 光层调参实战从功率均衡到OSNR预算的3个必调参数4.1 第一个必调参数output-power对齐CLI的期望值开放光传输系统的配置文件里每个degree下的output-power决定该方向放大器的目标总输出功率。工程上最常见的调节方式是把新增波长的通道功率设置为与现有通道接近尤其要注意不要让EDFA因为总功率突变进入非线性区。以下的参数经验值基于常见的C波段EDFA和标准单模光纤场景参数推荐值调节依据EDFA总输出功率1 ~ 3 dBm过高会加剧非线性代价过低会压缩OSNR每通道功率-3 ~ 1 dBm结合通道数计算保持总功率稳定目标OSNR余量≥ 3 dB考虑FEC开销和长期劣化预留波长增减步长单次不超过8个通道避免光放瞬态振荡调output-power的时候通常要同步查看放大器的operational-state。如果状态显示饱和告警说明总功率设得太高放大器已经进入深饱和区此时继续加波长不会提升通道功率只会让OSNR整体下降。正确的做法是先降总功率给系统留出增益余量。4.2 第二个必调参数span-loss校准偏差大多数EDFA支持自动功率检测标定但实际应用中span-loss的读数经常与物理链路真实损耗有偏差。造成偏差的原因包括光纤接头污染导致插损增大、光缆折弯产生额外衰减、旧连接器氧化。若软件侧span-loss设置低于实际损耗放大器会因增益不足而降低输出端OSNR。校准方法可以对端打OTDR或使用设备自带的环回测试。对程序化控制而言更可靠的是定期读取各通道的入光功率变化与初始基准对比。若发现所有通道同步下降优先怀疑光缆或接头若只有特定通道下降优先怀疑WSS端口或波长漂移。这个区分能帮控制系统决定触发哪类补偿动作避免无谓调整放大器增益。# 通过NETCONF查询当前span-loss和实际输入光功率 # 典型用法在校准前后各执行一次对比误差 ncclient get --subtree /roadm/degree/span-loss ncclient get --subtree /roadm/degree/amp/input-power实际场景里校准动作往往由控制器主导先读取当前配置值再对比输入功率的实测平均值两者差值超过1.5 dB就触发重新标定。白皮书2020里的软件流程建议链路割接后必须校准span-loss否则后续功率均衡会有相当大的偏差。4.3 第三个必调参数调制格式与通道间隔的综合匹配调制格式直接决定了单通道速率和OSNR需求因此功率均衡配方必须跟着调制格式走。DP-QPSK格式对OSNR要求约为16 dB含FEC但如果同一光纤上混用了DP-16QAM和DP-QPSK两者对OSNR要求差出5 dB以上会导致共享放大器时互相挤压。开放光传输系统的软件侧一般有调制格式感知机制配置时会根据各通道的格式计算独立的目标功率权重# 根据调制格式计算通道的目标功率偏置 modulation_offset { DP-QPSK: 0.0, DP-8QAM: -1.2, DP-16QAM: -2.5, } base_power -1.0 # dBm基准通道功率 target_power base_power modulation_offset.get(modulation, 0.0)这个脚本的本质是让OSNR需求高的调制格式获得更高功率权重。参数偏置值根据实验链路实测调整不能照搬所有设备商。每代相干DSP的性能边界不同偏置表在引入新光模块后重新测试。4.4 常见故障现象与控制器的第一反应开放光传输系统落地后的故障处理和传统网管的最大差别在于控制器能看到全链路的手段更多第一反应不应是看告警列表而是对比全网的目标功率和实测功率矩阵。一个非常典型的场景是某段光纤劣化导致span-loss增大0.8 dB链路只见功率小幅度波动FEC纠前误码率轻微提升传统网管不会触发任何告警但控制器可以立刻捕获到。拿到这些数据后的动作顺序先锁定劣化段方向再隔离到单根光纤或单个连接器最后检查是否需要放大器增益补偿。如果控制器一发现功率抖动就主动抬高EDFA增益反而可能掩盖物理接触面的积累性问题。较好的策略是同时建立性能基线库只有抖动幅度超过10倍历史方差时才自动干预。故障现象可能原因软件侧响应单通道功率骤降连接器污染、激光器劣化禁止自动补偿触发工单多通道同步下降光放大增益漂移、光纤折弯重新标定span-lossOSNR整体降低EDFA总功率过高、光纤非线性下调总功率并复核调制格式FEC余量归零波长漂移或收发端失配检查频率网格并对准中心频率5. 验证开放程度的最小动作集从能力探测到多厂商互通判断一套系统是否真正兑现了“开放”承诺不需要阅读完整白皮书2020执行三个最小验证动作就够了。第一步是能力探测。用NETCONF的get-schema或RESTCONF的OPTIONS请求去问设备你到底实现了哪些YANG模块白皮书2020里强调的标准做法是设备能精确列出自身支持的模型版本比如org-openroadm-device 8.1。如果设备对这类请求返回空或只返回私有模型那么后续的所谓“开放”就要打折扣。# 询问设备支持的YANG模型确认是否遵循标准模型 curl -u admin:admin http://192.0.2.10:8080/restconf/data/modules-state/module第二步是多厂商参数对齐。把A厂商和B厂商设备接入同一个控制器同时下发同一个目标功率值例如-1.5 dBm然后读取两边的实际输出功率读数。若两者差异在0.5 dB以内证明模型转换层工作正常若差异超过这个范围多半是设备内部功率参考点定义不一致——有的设备以光口后端为参考有的以芯片内部为参考。这类偏移需要用软件补偿表收敛。第三步是业务级验证。在控制器上发起一个跨厂商的波长通道建立请求同时指定源端、宿端和频谱位置查看两端设备的WSS配置是否同时生效。完整验证还要检查中间放大器的总功率是否自动跟随——通道建立后OLA应自动调整增益而不是等待手工干预。如果这三步都能顺利完成说明该系统的开放程度足以支撑自动化运维闭环。对准备引入开放光传输系统的团队建议在实验室先搭一套两厂商加模拟器的验证环境跑完这三步再谈生产纳管。这套最小验证集能暴露的控制面问题远比烧钱的整网仿真要多。本文还有配套的精品资源点击获取
