2. Ciena光传输产品与网络架构梳理

升级迁移项目的第一份“底图”不是割接方案，而是对现网的完整梳理。Ciena光传输网络通常由多代设备混跑：早期部署的6500分组光平台、承担长距骨干的WaveLogic系列相干光引擎、面向城域接入的5160/5170、以及新一代6500 RLS与WaveLogic 5 Extreme。若不能准确识别每台设备的型号、软件版本、网元角色与承载业务，后续的波长规划、保护倒换验证和割接窗口设计都会失去依据。本节的目标是建立一套可执行的现网梳理方法，输出一份能直接支撑迁移决策的“网络现状清单”。

一、设备型号与网元角色的识别

梳理的第一步是逐站确认设备型号与角色。Ciena设备型号通常可从网管Manager（或Site Manager）的节点属性、设备面板丝印或命令行show equipment输出中获取。需要记录的关键字段包括：机框型号（如6500-S14、6500-R4）、通用控制卡（如NC、NC-2）、线路卡类型（如WL5e、WL3e、OLT、OMD）、光模块型号与波长、软件版本（如SAOS 10.x或Release 12.x）。

网元角色决定了它在拓扑中的位置。常见角色包括：终端复用器（TM），负责业务上下路；分插复用器（ADM），在中间站上下部分波长；光放站（ILA），仅做光功率放大与色散补偿；ROADM节点，通过WSS实现波长级调度；以及再生站（REG），在长距链路中恢复信号质量。角色识别错误会直接导致保护方式判断失误，例如把ILA误判为ADM，会错误地认为该站具备波长上下能力。

二、拓扑结构与保护方式的对应关系

Ciena现网常见拓扑包括链形（Linear）、环形（Ring）、网状（Mesh）以及ROADM环网。拓扑结构直接决定可用的保护方式：链形通常采用1+1 MSP或光通道保护（OCP）；环形采用BLSR/MS-SPRing或OTN SNCP；ROADM网状则依赖GMPLS/ASON或光层恢复。梳理时必须记录每条链路的保护类型、倒换触发条件（LOS、LOF、SF、SD）以及倒换时间要求。

保护方式的验证不能只看配置，还要结合光功率预算与OSNR余量。例如，某段链路配置了1+1保护，但备用路径的OSNR仅比门限高1.5 dB，实际倒换后可能因余量不足导致误码。因此，梳理时应同步采集每段链路的收光功率、OSNR、色散补偿量等参数，作为后续割接风险评估的输入。

三、业务承载关系的映射

业务承载关系是梳理中最容易被忽略、却最关键的部分。需要建立“客户业务—ODU/OTU容器—波长—光纤链路—设备端口”的完整映射。Ciena设备中，业务通常以ODUflex、ODU2/ODU4或OTU2/OTU4形式承载，再映射到具体波长。梳理时应记录：业务名称、客户侧接口类型（如10GE、100GE、STM-64）、映射到的ODU容器、占用的波长编号、经过的网元序列、以及是否受保护。

一个实用的做法是导出网管的Cross-Connection（交叉连接）表，结合Circuit ID与Service ID逐条核对。对于无法从网管直接获取的业务，可通过OTDR测试或光功率逐段测量辅助确认路径。最终输出应能回答：某条100GE业务从A站到D站，经过哪些网元、占用哪个波长、保护路径是什么、当前OSNR余量多少。

四、梳理成果的落地形式

梳理完成后，建议输出一份结构化的现网现状表，字段至少包括：站点名称、设备型号、网元角色、软件版本、拓扑位置、保护方式、承载业务列表、关键光参数（收光功率、OSNR、色散）、以及备注风险项。这份表格是后续迁移方案、割接脚本和回退预案的共同输入。

在实际项目中，梳理工作往往需要与网管数据、现场标签、竣工资料三方交叉验证。网管数据可能因历史割接未同步而失真，现场标签可能因多次跳纤而混乱，竣工资料可能缺失。因此，建议对关键站点进行现场核对，重点确认光纤连接关系、波长占用情况和保护路径的实际走向。只有底图准确，后续的迁移与割接才能做到“心中有数、手中有策”。