企业官网建设流程全解析

简介：《开放光传输系统光电产品软件白皮书2020》由开放数据中心委员会（ODCC）发布，面向光传输系统研发、运维及标准化从业人员，旨在规范光电产品软件层面的开放性与智能化管理。白皮书聚焦YANG数据建模语言在系统管理中的应用，系统阐述OCyang模型、ODCC yang模型及全局性原则，并详细定义了platform标准中的组件命名规则、subcomponent关系以及各类共性参数，如type、admin-state、oper-status、led、vendor-type等，为设备识别、状态监控和兼容性保障提供完整框架。资源包为单个PDF文档，大小约4.03MB，共1个文件，格式为官方标准文本，适合研读和检索。已有135人学习下载，可作为理解开放光传输架构、优化数据中心运维效率的参考依据。

1. 开放光传输系统软件白皮书：它到底把光电设备的什么管起来了

开放光传输系统的软件难点不在单个设备的功能，而在设备型号一多、接口各自为战之后，上层管理系统很难用同一套模型把它们统一管起来。ODCC 这份编号 ODCC-2020-03002B 的《开放光传输系统光电产品软件白皮书》，要解决的就是这件事：用 YANG 模型把光电产品软件层的骨架固定下来，组件怎么命名、共性参数有哪些、告警事件怎么上报、软件升级走哪些 RPC，全程有明确约定。换句话说，只要设备符合规范，你就能用同一套 netconf/telemetry 接口完成接入和运维，这正是开放光传输系统解决互操作性问题的核心手段。适合三类人读：开发设备软件和 netconf 接口的工程师、设计数据中心光网络管理面的规划人员，以及每天面对光功率告警的运维。这份 PDF 白皮书是标准文档，可复现性在于把其中的模型要求和参数约定落到自己的设备、模拟器或测试脚本里验证。

2. YANG 模型结构概览：OCyang 与 ODCC yang 的兼容边界和全局性原则

2.1 OCyang 与 ODCC yang：95% 兼容背后的扩展逻辑

YANG 是 NETCONF 的数据建模语言，OpenConfig 工作组先制定了一套面向网络设备的开源模型，覆盖网络协议、设备组件结构、端口等。ODCC 在这套模型基础上，结合数据中心光传输的真实业务场景做扩展，保持 OC YANG 模型 95% 以上的完整和一致性。这个数字很关键：意味着厂商如果已经实现了 OpenConfig 模型，迁移到 ODCC 规范的成本很低；对上层网管来说，也不必为不同厂商各写一套适配器。

扩展方式是“文件增加、节点增加、结构明确和细化”三类。文件增加最容易理解：OpenConfig 的 optical-transport 目录偏重通用光模块参数，而 EDFA 的增益控制、OSC 监控通道、OLP 保护这类 WDM 特有组件，在 OC 模型里没有完整容器。ODCC 的做法是把 OCM、EDFA、OLP、OTDR 的特性参数单独建模，再通过 name 的 leaf reference 与 platform 体系建立关联。这样 platform 树仍然干净，光层模块的细节又有独立的扩展空间。

理解“leaf reference”对写查询路径很重要。查 EDFA 的增益，不是在一个文件里从头读到尾，而是先通过 platform 的 component 定位到 name，再进 EDFA 特性容器取参数。两个文件配合着看，字段才能对齐，这也是 YANG 模型扩展的标准姿态：augment 不改原结构，只挂新分支。

2.2 全局性原则：config/state 双容器、CLI 与 netconf 同一数据库

OCyang 中节点分 config 和 state 两种状态：参数可读时存在 state 容器下，参数可配时存在 config 容器下。最容易被忽略的约定是：当模型要求某个节点可配置，但设备实际不支持配置时，config 容器下仍要显示该节点，配置时返回错误或不可配置。这样设计的目的很直白——上层应用拿到的模型永远是完整的，不会因为某个厂商缺字段导致遍历中断。

另一条硬性要求是 CLI 与 netconf 操作同一个数据库。过去很多设备 CLI 走私有协议、netconf 走另一套配置通道，两边状态经常对不上。白皮书明确要求：CLI 下发配置后，通过 netconf 查 config 文件夹必须看到一致结果。对自动化平台来说，这是最基础的信任前提；如果这条不成立，配置核查脚本写出来也是废的。

还有几个编制层面的硬约束：string 类型数据长度优选 64 字节，不得超过；remark、text 类节点优选 256 字节，不得超过。component 体系下所有 name 统一使用大写，目的是避免设备与上层交互时大小写转换带来的麻烦。发送的 XML 中 namespace 遵循 RFC 6020，notification 报文遵循 RFC 5277。下面是一个典型的 get-config 请求，注意 name 全大写写法：

<!-- 通过 netconf get-config 读取单板管理状态，name 为 component 的 key，必须大写 --> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <components xmlns="http://openconfig.net/yang/platform"> <component> <name>LINE-1</name> <config> <admin-state/> </config> </component> </components> </filter> </get-config> </rpc>

这里读的是 running 配置库，admin-state 被包在 config 下，表示管理状态可配。如果设备实际上不支持配置该参数，按规范节点仍然存在，但返回错误。遇到这种情况，先别怀疑报文格式，用 get-state 对比运行状态，多半能定位问题。

提示：config 与 state 不一致是允许存在的状态。排障时先 get-config 看“配置被要求成什么样”，再 get-state 看“设备实际跑成什么样”，两者对不上时以 state 为准定位问题。

2.3 模型文件关系：platform、system 与 optical-transport 各管哪一段

模型文件之间的关系可以用一句话概括：platform.yang 定义物理层 component 树，system 管系统参数和告警体系，optical-transport 下放功能配置与性能监测，telemetry 负责流式数据采集，各光层特性参数文件 augment 回 platform 体系。记住这个分层，找字段时就不至于在几十个 yang 文件里瞎翻。

落到操作上：拿到一台新设备，先 get-config 拉一遍 platform 的 component 列表，确认设备上报了哪些组件；再按组件类型去对应特性容器里查细节。不要试图从根节点一次性拿到全部数据，netconf 的树很深，把过滤条件写在 filter 里更稳。

2.4 模型结构理解的三个常见误区

第一个误区是以为 config 和 state 必须一致。规范明确允许两者暂时不一致，设备可能由于硬件故障、告警抑制等原因没有落实配置，这时候强行认为“配置成功就是运行成功”，排障方向就偏了。

第二个误区是忽视 name 大小写。规范要求所有 name 大写，但实际现场偶尔能看到厂商实现不规范，上报小写或混写。上层数据库设计时要留一手：把 name 当唯一键的，先对设备做一致性检查，别等数据跑起来才发现重复键。

第三个误区是直接把 OpenConfig 模型套用到光层。OC 原生模型对 EDFA、OLP、OSC 覆盖很弱，直接用会丢字段。凡涉及光放大、光保护、光监控的场景，必须按 ODCC 扩展模型找字段，这是规范存在的根本原因。

3. platform 标准落地：component 命名规则、共性参数与特性参数怎么建模

platform 是整个设备结构模型的主体。子架、电源、风扇、主控、业务板卡、模块、端口，以及 EDFA 组件、OSC 组件、OCM 组件、OTDR 组件，全部例化成 component。名称是 component 的 key 值，统一的命名规则让模型的使用和数据的解析更便捷。这一章的实质是把物理设备翻译成一张可查询的表：每个硬件单元一行记录，公共字段放前头，特有字段放扩展列。

3.1 component 命名规则：电层盒式设备与光层盒式设备的命名差异

白皮书把命名分成电层盒式设备和光层盒式设备两个方向。电层设备处理客户业务信号，像 OTU 板卡，命名一般体现业务类型和槽位信息；光层设备处理 WDM 波长和放大，像 OA 光放板卡、OLP 保护板卡，命名更多体现光模块功能。文档 4.1 节给了完整清单，这里按缩略语表做一个常见拆解，具体前缀以厂商实现为准：

命名最常见的坑是大小写和槽位号格式不统一。规范说得很明确：component 体系下所有 name 统一大写。有些设备上报时用 slug 格式、有的用纯大写，解析层不统一就是事故。设计上层数据库时，我一般把 component name 直接当唯一键存，不做大小写归一，因为设备侧按规范必须大写；如果哪天发现重复键，先怀疑设备上报不符合标准，而不是改程序兜底。

另一个容易被忽略的是 subcomponent 关系。命名解决“叫什么”，subcomponent 解决“挂在哪里”。一个光放板卡下面挂着 EDFA 组件、OSC 组件、OCM 组件，主控板下面挂着风扇子卡，这些层级关系都通过 subcomponent 表达。运维查故障时，顺着 subcomponent 树从上往下找，比在平铺列表里碰运气快得多。

3.2 共性参数：type、admin-state、oper-status、remark、led、vendor-type

共性参数是每个 component 都必须支持的字段，相当于所有组件的“公共头”。白皮书列了 type、admin-state、oper-status、remark、led、vendor-type，外加 component 通用 description 编写规则。我的理解是，这相当于一张设备数据库的通用表结构：不管什么组件，先塞进这几列，再往各自的特性表里补扩展列。

admin-state 和 oper-status 的组合是健康判断的核心。运维里经常看到 admin-state=enable、oper-status=down 的情况：一种原因是配置没下到硬件，另一种是板卡物理故障。排障时先看这两列，再往下钻取特性的告警；如果两者都是 disable/down，多半是管理面主动关断，不用急着报障。

led 这列容易被当成小事，但对机房无人值守很关键。网管端展示的“灯状态”就是从 led 字段读的，厂商如果不按规范上报灯色和闪烁模式，远程可视化就是摆设。vendor-type 则是专门留给厂商做差异的：标准模型管不了的扩展能力放这里，上层应用按需解析，不阻塞标准字段。

3.3 特性参数：从 port 到 optical-channel，八类组件的参数字段

特性参数按组件类型分文件定义，再 augment 进 platform 体系。目录里给出的类型有 port、power-supply、fan、cpu、transceiver、physical-channel、linecard、optical-channel，每类字段的侧重点完全不同。

port 是端口通用参数，速率、协商、FEC 这类；power-supply 管电源模块的输入输出电压电流；fan 管转速和状态；cpu 管主控占用率和温度；transceiver 是可插拔光模块，重点是收发光功率、温度、偏置电流——这是排查光路劣化的第一手数据。举一个我常遇到的场景：线路侧误码率上升，先查 transceiver 的收光功率是否接近灵敏度阈值，再看物理通道的 FEC 纠错计数，两步就能圈定问题在光模块还是在光纤链路。

physical-channel 和 optical-channel 容易混淆。我的理解是：physical-channel 是电层物理传输通道，负责把客户侧业务映射到线路侧；optical-channel 是 WDM 层面的光通道，对应一个波长及其目标功率。OTN 业务创建时，逻辑通道要同时绑定这两类通道，缺一个业务都起不来。linecard 则是业务板卡自身的硬件信息，槽位、硬件版本、功耗都归它管。

特性参数的查询路径有规律：共性参数在 platform/component 容器下，特性参数在各自的 augment 容器下，但都靠 component name 关联。写自动化脚本时，先拉 component 列表拿到 name，再按 name 拼出特性参数的过滤路径，这是我用了很久的稳定套路。

4. 定制化光层标准：OA/OLA、EDFA、OSC、OCM、OTDR 与 OLP 的建模要点

光层是全白皮书定制化程度最高的部分。OpenConfig 对电层以太网和路由覆盖得多，对光放大、光监控、光保护这些 WDM 特有的组件建模很少，所以 ODCC 自己定义了 OA/OLA 光放板卡、OLP 保护板卡的结构和参数，还给了倒换逻辑和默认配置。这一章解决的是“光层设备怎么表达、怎么控制”的问题。

4.1 OA/OLA 光放板卡：结构、共性参数与 EDFA 特性

OA 光放大器和 OLA 光线路放大器在结构上都是光放板卡。板卡内部通常包含 EDFA 掺铒光纤放大器、OSC 光监控通道组件、OCM 光通道监测组件，部分还集成 OTDR。把这些全部例化成 component，就是第 3 章讲的建模思路：板卡是一个 component，EDFA、OSC、OCM 是它下面的 subcomponent。

EDFA 特性要关注几个关键量：增益、输出光功率、泵浦状态。白皮书里 EDFA 与 VGA 可变增益放大器相关，意思是增益可以是固定值，也可以动态调节，调节依据一般来自 OCM 的功率反馈。工程安全还有个更重要的点：AOSD 自动光功率关闭和 APR 自动功率降低。当检测到光纤链路异常时，APR 先把输出功率降到安全水平，AOSD 更激进，直接关断泵浦。这两个机制不是摆设，光纤被外力挖断时如果不降功率，断点处会有强光射出，对巡线维护人员是真实的伤害风险。

注意：涉及 AOSD/APR 的板卡，验收时一定要实测：拔掉输入光纤或加衰减，观察输出功率是否在阈值内下降或关断。只配置不验证，等于没配。

默认配置在文档 5.1.7。上线前一般要确认几项：OSC 是否使能、EDFA 增益默认值、告警阈值、AOSD/APR 默认开关。设备出厂默认往往偏保守，会开启保护功能；如果开局调试时需要更高输出功率，再按场景临时调整，调试完记得恢复。

4.2 OSC 模型与 OCM/OTDR 数据格式

OSC 光监控通道是带外管理通道的底层承载，网管数据、告警、OSC 端口的 LLDP 都走它。OSC 接口在 interface 标准里有单独定义，对应文档 7.2 节。如果 OSC 断了，网管对整条光路失联，此时只能从带外管理口登录设备查光放板卡状态。所以 OSC 的配置虽然不起眼，却是整个管理面的命脉。

OCM 光通道监测负责逐波监控功率，数据格式在附录六；OTDR 光时域反射仪负责测光纤链路，能给出事件距离、损耗、反射率，数据格式在附录五。两者是光路质量的两类证据：OCM 告诉你“哪个波长功率不对”，OTDR 告诉你“断点在大概多少公里处”。配合起来定位光路故障，比逐段拔纤试效率高很多。

实际使用里有个习惯：OCM 数据按周期采集，明显超出历史基线时提前预警，这往往在误码率恶化之前就能看到，是最早期的劣化信号。OTDR 不常开，启动测试会短暂占用资源，用 start-otdr RPC 触发、stop-otdr 停止，结果按附录五格式解析。

4.3 OLP 保护板卡：结构、参数与倒换逻辑

OLP 光纤线路保护用于主备光路的自动切换。结构上包含光开关、分光器、监测模块，实际业务走工作路，保护路热备。白皮书 5.2 节定义了保护板卡结构、共性参数、特性参数、默认配置和倒换逻辑，是光层里逻辑最完整的一块。

倒换逻辑分两种触发：自动倒换，工作路收光功率低于阈值或丢失信号时触发；手动倒换，用 switch-olp RPC 强制切换。运维做保护倒换演练时，一般不会去拔纤，而是直接下发手动倒换，验证保护路可用后再切回。下面是 switch-olp RPC 的示意报文：

<!-- 手动将 OLP 保护组倒换到保护路，验证保护链路可用 --> <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <switch-olp xmlns="urn:odcc:yang:olp"> <name>OLP-1</name> <direction>protect</direction> </switch-olp> </rpc>

name 是 OLP 板卡在 platform 里的 component key，direction 取值常见为 working 或 protect，按厂商实现还会带 mode 字段区分自动、手动、强制。下发后不要立刻下结论，等设备上报倒换完成的事件，或用 get-config 核对倒换状态，再确认业务没有中断。

倒换演练有个坑：有些设备倒换是硬切换，毫秒级，网管上看不到业务中断；有些是软切换，会有几十毫秒闪断。验收保护功能时，除了看 OLP 状态，更要看客户侧端口有没有误码，这才是业务真正关心的指标。

4.4 默认配置与上线检查清单

光层板卡默认配置直接决定开局是否顺利。文档里 OLP 和 OA/OLA 都有专门的小节描述默认配置，涉及的共同点包括：默认增益范围、OSC 的使能状态、保护组的初始方向、告警阈值。开局时先按默认配置把板卡跑起来，再根据实际光功率做微调，最后把微调结果固化到配置文件里。

我一般会给每块光层板卡做一份简短的上线检查清单：一、板卡 LED 状态正常；二、OCM 各通道功率在阈值内；三、EDFA 增益与目标值偏差小于 0.5dB；四、AOSD/APR 保护功能实测有效；五、OLP 自动和手动倒换各演练一次。这五条过完，光层板卡才算真正交付。

5. 告警、事件、RPC 接口：三个接口层的常见问题与排查方法

5.1 Alarm 与 Event 模型：type-id、告警描述与 CONFIG-CHANGE 事件

告警和事件是两个不同概念。告警代表当前存在的故障状态，需要恢复，比如光功率越限；事件是一次性操作记录，比如配置变更、板卡插拔，本身不需要恢复。白皮书第九章把两者分开建模：Alarm 模型定义 type-id 类型说明和告警描述，Event 模型定义事件分类、格式，CONFIG-CHANGE 事件专门记录配置变更。附录一、二、三、四分别给了光层和电层的告警事件清单，排障时查清单比猜 type-id 快得多。

告警通知走 RFC 5277 的 notification 机制。下面是告警报文结构的示意：

<!-- 告警通知示意：光通道功率越限，resource 指向具体组件路径 --> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2025-01-15T10:30:00Z</eventTime> <alarm xmlns="urn:odcc:yang:system"> <type-id>OPT-POWER-LOW</type-id> <severity>major</severity> <resource>/components/component[name='OCM-1']</resource> <text>channel 5 optical power below threshold</text> </alarm> </notification>

type-id 是告警类型标识，具体值以附录一、三的清单为准，这里用 OPT-POWER-LOW 做示意；severity 表示严重级别；resource 指向告警源，通常是 component 路径。自动化平台订阅 notification 后，第一件事就是解析 resource 把告警挂到正确的组件上，别只按 text 打标签，否则告警关联会乱。

CONFIG-CHANGE 事件用于审计，记录谁在什么时间改了哪个节点，适合回滚溯源。事件格式在 9.2.2 有统一定义，自动化系统最好把这类事件单独归档，不跟告警混在一起，查历史变更时才翻得出来。

5.2 interface 标准：客户侧、OSC、带外管理、LOOPBACK 四类端口

interface 标准覆盖四类端口：客户侧端口 interface、OSC 端口 interface、带外管理端口 interface、LOOPBACK 端口 interface。客户侧端口就是 OTU 板卡上对接业务设备的接口，速率和 FEC 参数在这定义；OSC 端口是光监控通道的接口；带外管理端口是 IP 网管口；LOOPBACK 端口用于测试环回。

客户侧端口环回是开局自测的常用手段。loopback-mode 的取值常见为 no-loopback、facility-loopback、terminal-loopback，分别代表不环回、设备内部环回、终端侧环回。做通断测试时，先配 facility-loopback 验设备内部转发，再连测试仪打流验外部链路，逐段缩小范围。test-signal 测试信号配合使用，可以在没有业务时填 PRBS 码流验证链路误码。

5.3 RPC 接口总览：13 个接口怎么组合

RPC 接口是设备对外提供的操作入口，白皮书定义了 reboot、download、get-download-status、upload、remove-file、activate-file、get-activate-status、get-pm-data、switch-olp、start-otdr、stop-otdr、get-log、set-datetime 共 13 个。它们不是孤立的，软件升级和运维操作都是多个 RPC 组合出来的。

软件升级的标准动作是 download → get-download-status → activate-file → get-activate-status → reboot。很多人图省事把 download 和 activate 合在一起，一旦下载不完整直接激活，设备可能起不来。血泪经验是：激活前必查 get-download-status 确认文件完整，激活后等 get-activate-status 返回成功再 reboot，顺序不能乱。

5.4 常见问题排查：现象、原因、解决

现象一：刚插上新板卡，立刻 get-config 查不到 component。原因：板卡识别和模型初始化需要时间，设备还没把新组件挂进 platform 树；或者板卡处于预配置状态，只有配置没有实体硬件。解决：等设备上报插卡事件，或轮询 component 列表，确认出现新 name 后再下发配置，别在初始化空窗期做操作。

现象二：config 下发成功，oper-status 一直不 up。原因：config 和 state 允许暂时不一致，配置可能没被硬件接受，或存在抑制性告警。解决：用 get-config 和 get-state 分别核对，确认配置值确实生效；再看该组件是否有告警，比如光模块收无光、供电异常；最后确认 CLI 与 netconf 是否操作同一数据库，有些老设备两边不同步。

现象三：拔板再插回，之前的 admin-state、remark 全丢了。原因：人工拔板不等于删除板卡，但如果网管侧做了删除操作，config 就被清了；插回时按新板卡初始化。解决：删除板卡前先备份 component 的 config；拔板维护时只拔不删，插回后 config 还在；插回后先 get-config 比对，别急着配业务。

现象四：OTDR 测试结果全是乱码或空数据。原因：测试被中途打断，或数据格式没按附录五的约定解析，或者波长类型不匹配。解决：start-otdr 之后确保链路稳定，测完用 stop-otdr 正常结束；解析时严格按附录里的字段顺序和单位换算；同一链路不同波长的结果不能混用。

现象五：订阅了 notification，但告警里找不到具体端口。原因：部分实现只在 resource 里带 component name，不带 interface 名，或者告警源挂在了父板卡上。解决：先解析 resource 定位到 component，再用该组件的 subcomponent 关系往下找端口；同时把 led 字段拉出来，结合告警时间和光功率数据反推物理位置。

6. 从板卡插拔到 OTN 业务创建：用 get-config 和 get-pm-data 做落地验证

6.1 板卡操作场景：初始、插入、拔板、插回、删除、预配置

板卡操作场景是理解 platform 模型行为的入门题。文档 12.1 节把整个过程分成初始状态、初次插入、人工拔板、板卡插回、删除板卡、预配置六种场景，关键差异在 config 和 state 两个文件夹上。

最常见的误操作是把拔板和删除混为一谈。拔板只是物理动作，配置应该保留；删除是管理动作，会清掉 config。文档 12.1.7 专门提到 config 和 state 文件夹的显示问题：有些设备在板卡拔出时 state 文件夹消失、config 文件夹还在，这是正常的；如果两者同时消失，说明是删除语义，别急着报障。

6.2 OTN 业务创建：从 OTU 板卡模型到性能验证

OTN 通道建立逻辑在文档第 14 章，核心是三层模型：OTU 板卡业务端口模型、逻辑通道模型、业务创建流程。业务端口对应客户侧物理口；逻辑通道承载 ODU 映射，logical-channel-assignments 定义映射关系，operational-mode 决定工作模式；ingress 关联关系把客户侧流量引到线路侧。

我的验证步骤是固定的。第一步：get-config 拉平台 component 列表，确认 OTU 板卡和端口都存在且 oper-status up；第二步：配置逻辑通道与客户侧端口映射，核对 operational-mode 是否匹配对端设备；第三步：下发业务后用 get-config 核对映射关系，再拉 get-pm-data 看客户侧和线路侧性能计数；第四步：如果出现误码，先看 transceiver 收发光功率，再查 FEC 纠错和物理通道状态。

从那以后我每次上一块 OTU 板卡，都强制走一遍“插板 → 等 notification → get-config 核对 → 下发业务 → get-pm-data 验证”的流程，软件升级也一样，把 download 和 activate 拆开一步步确认状态，绝不把关键操作压进一个脚本里图省事。这套习惯救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取