摘要：
分析OTN专线业务开通诉求，阐述了OTN网络SDN化现状以及控制系统北向接口标准化存在的主要问题，对多控制系统协同的关键技术进行论述，提出了统一的资源模型、业务模型和多协议适配的技术架构，研发实现SD-OTN协同器系统，并对其系统架构和功能架构进行详细阐述，SD-OTN协同器支持跨域厂商场景下业务端到端自动开通，实现OTN网络能力开放。
引言
光传送网（OpticalTransportNetwork，OTN）是运营商的基础网络，由于OTN专线具备高带宽、低时延、高安全、高私密性的优势，已经成为党政等客户自组网及业务承载的首要选择。随着SDN（SoftwareDefinedNetwork）技术的成熟及大规模商用，传统OTN专线业务在业务开通时效性、跨域跨厂商端到端场景支持以及客户定制化功能实现上的劣势日益凸显，究其根本原因，在于OTN网络及其管控系统独立成域，互成壁垒，缺少跨域跨厂商的统一协同。
SD-OTN（SoftwareDefinedOpticalTransportNetwork）协同器系统通过对ACTN（AbstractionandControlofTrafficEngineeredNetworks）和T-API（TransportAPI）接口协议的适配，建立统一的资源模型和业务模型，并提供标准的北向接口，实现多厂商控制系统统一编排，支持跨域跨厂商业务端到端自动开通，完成OTN网络能力开放。
01
OTN网络SDN化必要性分析
1.1OTN专线业务开通痛点
OTN专线业务是面向重点政企客户推出的高ARUP（AverageRevenuePerUser）值优质专线产品，受限于网络组织及管控技术等因素，长期以来均采用线下方式人工开通和维护，从业务开通到故障处理等多方面均存在缺陷，亟待优化。
a）业务开通慢：单域业务（一干/省内）采用网管独立开通，最快2周；跨域跨厂商业务，需一干和省内配合协调，各自开通，最快1个月。
b）网络资源不可视：缺少网络资源实时上报和可视化工作，带宽资源不足或者SLA级别不满足，导致业务无法开通的情况时有发生。
c）故障定界难：缺少业务级SLA监控手段，业务故障依赖客户申报，被动排障，无法实现故障快速定位。
1.2OTN网络SDN化现状
中国联通近年启动OTN网络SDN化工作，受限于OTN设备开放性不足，设备的控制系统由该设备厂商提供，支持单厂商域内业务自动开通及资源管理。
目前OTN控制器北向接口标准主要包括ACTN和T-API，这2种标准相关情况如下。
a）ACTN由IETF主导，其架构满足SDN基本分层模型，从南至北分为转发层、中间控制层、应用层。对于ACTN控制器，底层设备为OTN物理网络拓扑，使用控制器完成控制配置。控制平面以层次控制方式实现全网拓扑维护、点信息收集、配置流表信息、全网路由等操作，同时提供面向应用的北向开放接口，通过该接口下发至控制单元，自动完成路由转发部署。应用层主要为基于SDN技术的应用部署，通过网管系统等定制化管理应用，减少控制和转发层面交互逻辑，通过软件API编程方式实现业务快速部署，如图1所示。
图1ACTN架构图
b）T-API由ONF主导，T-API接口模型中，将单个物理网络节点抽象为ETH层、ODU层、OCH层3层节点；每层节点上，NEP（NodeEdgePoint）对应物理端口，以SIP描述业务起始点及终点，设备厂商控制器具备抽象链路信息和SIP信息能力。不同层之间通过层间链路连接，层内节点通过层内链路连接，与其他网络域通过域间链路连接。每个抽象层内节点上有若干NEP，每个NEP对应若干个SIP。T-API随着业务及应用发展，已衍生为T-API2.0接口标准，采用模块化的定义方式，相对于T-API1.0，T-API2.0对象的覆盖面和定义更加全面，支持更多业务控制及性能检测，对光网络的发展起到至关重要的扩展作用。
目前华为和烽火控制系统北向接口遵循ACTN标准，中兴控制系统北向接口遵循T-API2.0标准。控制系统北向接口的不兼容使得跨厂商协同和统一编排客观上无法实现，如图2所示。
图2T-API架构图
02
多控制系统协同关键技术
2.1多协议适配技术架构
多控制系统的统一协同，需要在建立统一资源模型的基础上，针对ACTN和T-API进行YANG模型适配，以实现不同配置功能的统一化，并保证各层级通信互不影响。通过增加独立的协议栈实现与控制器层协议互通及访问，并将ACTN和T-API的资源模型进行抽象后，形成业务适配的业务抽象模型，各层级实现接口层次性、区域独立性、层间独立性，各抽象功能相互作用且通信互不影响，如图3所示。
图3多协议适配统一技术架构图
2.2统一资源模型创建
欲实现T-API协议与ACTN协议控制系统的同时纳管，并且同时抽象出对于业务和运维等有效的资源数据，就必须构建一套统一的资源模型，从而使得上层应用对协议与模型的差异零感知。在这之前，就必须充分了解ACTN和T-API模型之间的异同点，以及协同器需要的信息种类，包括资源类（网元、端口、链路、层级等）和业务类（创建、删除、修改等）。
ACTN标准对于资源类信息和业务类信息的定义有以下几类。
a）资源类。RFC中的Ietf-Network结构中，将网络分成了3层，分别是光层（Ietf-Wson-Topology）、电层（Ietf-Otn-Topology）、以太层（Ietf-Eth-Te-Topology），同时由于ACTN参考了MPLS网络的概念，所以同时存在一个MPLS层级（Ietf-Mpls-Tp-Topology）。
b）业务类。ACTN采用隧道（tunnel）方式，这一点和MPLS网络模型十分相似，将业务依赖于隧道之上，但这种表达方式在光网络中，不可避免地造成了一些冗余。
T-API标准对于资源类信息和业务类信息的定义有以下几类。
a）资源类。在ONF发布的T-API2.0传送网模型中，将模型分成了三大类。公共模块（Common）、功能模块、（包括拓扑管理、连接服务、告警和通知服务、虚拟网络、路径计算、OAM等功能）和层协议扩展模块（ODU、ETH、Och等）。
b）业务类。T-API模型将业务抽象为多个SIP之间的网络连接，对于SIP之间的业务路由，采用NEP的方式进行互联，同时将节点抽象成逻辑和物理的概念，模型相对比较复杂，但是扩展性很高。
对二种标准深度分析并结合业务和功能需求，对所需资源信息进行抽象并摒弃冗余和不需要的资源信息，形成统一业务资源模型URM（UnifiedResourceModel，URM），最终抽象出网络（Network）、节点（Node）、端点（Endpoint）、链路（Link）概念，如图4所示。
图4统一资源模型抽取结构图
2.3业务抽象及统一北向接口建立
从业务抽象的角度，需将ACTN中隧道（Tunnel）中继承的管道颗粒度Odu-Type，以及保护恢复属性Protection、Restoration与业务中的SLA等级、TCM层开销、接入信号（Client-Signal）等进行结合，与T-API模型中的相关业务数据保持一致。
从同一资源模型URM中抽取业务中所需要的端点，以及业务所必需的SLA等级、带宽、光通道等级等参数。进行适配后下发至2种协议栈的控制器中，从而实现北向接口模型的一致，如图5所示。
图5业务抽象及统一北向接口
a）业务控制层：协同器通过对业务需求和运维需求分析，使用RestFul接口风格，制定出一套适应于多种协议栈的简便高效的接口模型。
b）资源建模层。通过从资源抽象层中抽象出的网、元、点、属性这几个维度的资源数据，屏蔽掉与设备和专业强相关的动态关联参数，简化2种模型中的冗余部分，最终建模出一套统一的资源架构体系。
例如在ACTN模型中对链路进行了有向性定义，但实际链路基本均为双向，此时在ACTN资源中，链路资源经常出现冗余，而在T-API模型中，并无方向概念，链路均为双向互通。此时协同器在建模时，即可忽略ACTN中的方向概念，简化模型，减少冗余数据。而在T-API模型中，由于扩展性极高，对所有的NEP均可实现逻辑/物理分离，同时可以对不同层次的设备接入端点进行NEP抽象分离，从而使得同一种资源被多次重复创建。此时协同器在建模时，则通过数据关联算法，将这些资源进行精简，最终保留一个准确的统一资源数据。
c）资源抽象层。此层中的数据，已经初步弱化了2个模型之间的差异，但是并没有达到应有的统一，此时通过抽象算法，即可将2个模型数据进行抽象、标准化，使得模型之间的差异进一步缩小。
d）资源过滤/清洗。从2个协议栈中采集到的数据，在此层进行数据过滤和清洗，将不需要的数据进行精简过滤，保留统一模型中关心的资源数据。
03
SD-OTN协同器自主研发及应用
在对多控制系统进行适配并建立统一资源模型和业务模型基础上，中国联通自主研发SD-OTN协同器，目标实现跨域跨厂商OTN专线业务的自动开通。
3.1SD-OTN协同器系统架构
中国联通SD-OTN协同器采用2级架构，如图6所示。
图6SD-OTN协同器及控制系统架构
a）一级协同器作为集团级协同器，对接一干OTN控制系统并纳管，实现一干OTN网络资源采集、业务配置自动下发及业务性能上报；同时，完成跨省业务端到端路径计算，实现端到端业务自动开通，提供北向可编程的API能力。
b）二级协同器作为省级协同器，对接省内OTN控制系统（包括CPE管控平台及采用ACTN/T-API接口的各厂商控制系统）并纳管，实现省内OTN网络资源采集，完成单省内跨厂家的路径计算，实现省内业务跨域段、省内业务配置下发和省内业务管理能力。
3.2SD-OTN协同器功能架构
SD-OTN协同器目前采用企业级J2EE标准的B/S架构分层实现，同时也采用REST接口对外服务。
协同器系统共分为系统前端、业务编排层和网络适配层3个层级，均采用RestfulAPI对接。
a）系统前端。提供系统首页，实现用户注册和登录入口；实现域间哑资源管理，支持以链路首末端方式进行链路创建、链路资源利用率统计、链路搜索及模糊查询等功能；实现业务端到端视图展示，支持以业务名称/业务编号查询、端到端业务路径全信息、业务保护倒换状态、业务故障定界、时延查询等功能。
b）业务编排层。实现信息钻取、分层分域、链路呈现、网元查询、工单拆分、流程控制、业务统计和查询、域间路径计算和系统监控等功能。
c）网络适配层：设置资源中心、业务中心、控制中心、保障中心和自管中心，实现多控制系统北向多协议适配、统一资源模型和业务模型建立、网络资源采集、业务状态执行和管理、SLA保障等功能。
04
结束语
随着OTN专线业务需求的快速增长，光传送网承载业务类型和能力都将面临新的挑战，更小颗粒度、更加灵活的业务配置模式都将是对运营商服务能力的考验。SD-OTN协同器目前已实现基于ACTN和T-API标准控制器的适配和管控，初步实现OTN网络能力开放，有力支持业务发展，面向上层服开系统以及新业务场景下进一步的能力开放，将会是协同器系统演进的重要方向。
参考文献
［1］胡骞，荆瑞泉，赵国永.基于TAPI/ACTN双栈的传送SDN互通方案［J］.光通信技术，（9）：18-21.
［2］唐雄燕，王海军，杨宏博.面向专线业务的光传送网（OTN）关键技术及应用［J］.电信科学，（7）：19-25.
［3］荆瑞泉，孙震强.传送SDNAPI标准化进展和应用概述［J］.电信技术，（6）：10-14.
［4］柳晟.中国移动OTN网络引入SDN技术的探讨［J］.通信世界，（3）：40-41.
［5］邬张帆.OTN网络引入SDN技术的探讨［J］.通信电源技术，（1）：-.
［6］陈明明.软件定义光网络控制平面与南向接口研究［D］.北京：北京邮电大学，.
［7］谢芳，冯先成，周密.传送网中SDN通用信息模型研究［J］.光通信技术，（9）：5-8.
［8］刘亚峰.开放和分解OTN技术研究和分析［J］.电信工程技术与标准化，（11）：27-34.
［9］濮方捷，郭祥明.传送网协同规划建设思路浅谈［J］.中国新通信，（16）：67-68.
［10］韩笑，朱武增.OTN网络SDN技术应用及测试验证［J］.电信工程技术与标准化，（1）：56-61.
［11］马斌，蒋燕，郑晖.面向云网融合的政企专线网络转型技术的创新探索［J］.电信技术，（12）：73-76.
［12］周彦韬，郑滟雷，张贺.自研CPE-OTN设备管控系统中国联通发掘专线市场［J］.通信世界，（30）：36-37.
作者简介：
许鹏，工程师，硕士，主要从事智能云网技术研究和产品开发工作；
杨艳松，高级工程师，硕士，主要从事智能云网技术研究和产品开发工作；
刘雪峰，助理工程师，硕士，主要从事智能云网技术研究和产品开发工作；
张桂玉，高级工程师，学士，主要从事智能云网技术研究和产品开发工作；
李威伟，助理工程师，硕士，主要从事智能云网技术研究和产品开发工作。
点
点击文末“阅读原文”，下载论文PDF
推荐阅读
■国际传输专线承载方式的演进探讨
■Web动态防御系统在电网的应用研究
■基于网络演算的多业务场景确定性网络方案研究
■面向工业互联网云网边端协同技术研究
扫描
联系电话：