基于软件定义网络的光传送网研究与设计

廖振宇

（1.武汉邮电科学研究院湖北武汉430074；2.武汉烽火国际技术有限责任公司湖北武汉430074）

当下，作为骨干传输网络的OTN（光传送网络）建设规模十分巨大，网络复杂性与网络异构化程度与日俱增。同时，随着大数据，云计算，VR等新业务的发展，以及可预见的未来5G商用落地，对网络流量的需求目前呈现爆发式的增长，而且未来会随着业务需求持续增长，OTN系统单纯扩容的解决方案让运营商面临严峻的挑战[1-3]。同时业务的多样性，业务流量突发性与路径不可预知性，对光网络的智能化需求越来越高，目前，对基于固定频谱，固定接口速率的传统静态，刚性光网络进行改造优化，精简光传送网体系结构和实现以降低成本、简化管理、提供及时的服务响应和提高资源利用率为目的的技术变革是对未来光传送网的普遍认知。

软件定义网络的核心思想是逻辑上集中控制平面，实现转发与控制相分离，开放应用程序接口使网络可编程化[4]。这一颠覆传统网络架构的思想，为OTN的演进与发展提供了思路，引入SDN技术，将有望从根本上创造一个高效智能，动态灵活的骨干传送网络架构。而控制器是SDN体系架构中的大脑，是实现网络架构由分布向集中转变以及转控分离的核心所在[5-7]。

1 软件定义光网络的可行性

SDN的提出给电信业提供了无限可能，需要有全新的支持SDN设计思想的OTN软、硬件系统来满足网络的不断演进和变革。但SDN技术的落地，不能也不会是孤军直入，摒弃以往的技术积累，而是新的协议扩展与现有技术的融合，实现网络的平滑升级[8-10]。光网络的智能化发展已被广泛运用的技术路线有自动交换光网络（ASON）和基于路径计算单元的光网络（PCE）。自动交换光网络是基于通用多协议标志交换（GMPLS）为光网络引进控制平面，实现了光网络的动态连接与删除，故障的快速恢复，但ASON是基于分布式架构的网络控制协议复杂，多域管理困难，难以实现不同厂家的设备互通。基于路径计算单元的光网络是一种集中控制方案，其将路径计算与流量控制功能从控制平面中分离出来，成立一个独立的组件，集中提端到端的路径计算，为多层多域管理困难以及设备互通提供了有效地解决方案。PCE集中计算的思想与SDN集中控制的核心思路十分契合，在SDN的网络架构下，可以运用单域控制器与多域控制器分层部署的方式，实现不同厂商设备的互联互通，同时将链路自动发现，路由计算路径下发，网络管理等功能集中到控制器中，如PCE可以实现SDON的部分协议族，同时ASON更注重与物理层的的自动控制，同样可视为SDON的一种功能类型。OpenFlow协议为控制器与转发设备之前提供了通信的标准接口，能实现控制逻辑从转发设备中分离出来，结合PCE，BGP等标准协议，扩展OpenFlow，是软件定义光网络的可行演进方案[11-16]。

2 控制器系统部署与软件设计

2.1 控制器系统部署

本文中SDON网络架构采用分层次的控制器部署方案，单域控制器单独部署在Controller上，多域控制器和单域控制器分层部署，多域控制器通过RestService模块对外提供北向的Rest服务。通过OF Protocol协议栈模块对外提供与主控的南向OF协议接口。为实现可编程性，需通过Web App进行拓扑查询和业务配置，因此部署在局域网同时部署web server和Controller Server，可根据标准组织或客户制定的API规范实现Rest服务接口。控制器与设备主控之间基于Openflow协议和基于OTN光层/ODUK层/虚接口的私有扩展，通过TCP协议进行Socket通信，实现连接建立、端口的上报、业务，接口命令下发等功能。系统总体部署图如图1所示。

图1 系统部署

OFP-FWK模块实现与控制器的连接，交互通信，如控制器实例内的数据分发填写以及状态维护。OFP-TEN实现设备端口的抽象，将设备资源以OF协议上报给控制器以及业务数据配置下发。Openflow协议栈将交叉配置信息链路自动发现报文下发到Openflow设备代理，Openflow设备代理将端口资源，告警信息等上报，两者交互通信。

2.2 控制器软件设计

控制器基于OSGi平台设计开发，该平台实现了完整和动态的组件模型平台且各组件无需重新引导可以被远程安装、启动、升级和卸载。控制器内部模块结构如图2。

图2 控制器内部模块

控制器的设计实现了OpenFlow协议的扩展以及设备与控制器之间基于openflow协议的网络连接的建立、维护、监控、管理，并提供一个基于OF协议的扩展通道，以支持业务下发和资源上报等功能。各模块功能如下：控制器的内核模块（Internal&Ser⁃vices），在OSGi平台基础上封装和抽象，系统其他模块基于Core模块进行服务接口定义和部署。整体运行基于南向的设备消息转换为OFMessage事件进行驱动，对并发消息进行多线程处理，相关Service服务代理模块监听到相应消息后，再调用上层模块进行处理，如设备加载、端口状态、链路发现。同样，上层模块也可调用Serivce代理中提供的对外接口来下发业务配置消息、自动发现报文等。控制器统一模型模块（CoreMode），用于在控制器内部描述IP+光的统一业务和拓扑模型。Openflow定义了各种Openflow协议TLV消息和格式，该模块基于ONF的Openflow Spec 1.4规范。转发模块（ForwardService）将各种北向接收的业务配置转换为基于定制Match&Action规则的配置下发消息，调用扩展业务下发包提供的接口进行下发，模块解析处理各种南向上报的性能数据消息，将性能数据适配为基于端到端业务模型下的性能数据。拓扑更新模块（EdgeUpdate）处理由service模块上报的拓扑对象更新，进行TOPO信息更新，并对北向提供TOPO查询的接口。业务处理模块（ConnectionManager）处理由北向下发的业务请求，其分别调用路由接口进行业务路由计算后，调用ForwardService进行业务转发处理。性能处理模块（PerformanceManager），处理由下面报上来的时延/丢包率/实时流量等数据，并处理后由北向适配模型调用。路由计算模块（RouteManager）：对由Connection⁃Manager传入的业务进行路由计算，包含路由计算的策略，提供的各种路由算法，以及业务的资源模型虚化。另外控制器配有数据库处理模块，对业务模型对象，TOPO对象，下发的消息进行存储，并提供多个接口供其他模块查询。控制器模块提供相应接口与外部模块互通，软件总体结构图如图3。

北向服务模块（RestService）：参考中国电信针对VTS/BOD定义的Rest API规范，实现了控制器北向提供的Rest接口服务，主要将基于Http URL的各种Rest服务 Request、Reply定义为 Java Bean，并解析消息中的JSON串格式，调用ConnectionManager，PerformanceManager，TopoManager模块的接口提供查询数据和业务下发配置，同时可根据客户需求进行规范替换。Openflow扩展模块该模块基于openflow协议1.4扩展，主要扩展对在网设备的光层信息配置电层信息配置以及设备的虚拟端口上报。FlowProgramService：实现CBB提供的IOFTrans接口，将CBB转化的Match转化成对应的光层和电层扩展信息下发。光端更新模块（OpticalPortUpdate）：通过监听CBB接受的OFPortStatus消息，将此消息生成对应的OFPort，并更新Port信息还回CBB模型。

图3 软件总体部署

3 测试结果

对SDON软件系统的测试基于现网运行设备进行组网，测试了SDON网络中提供北向接口服务，通过Web App进行拓扑查询和业务配置验证APP快速开通ODUk业务功能的实现。

测试组网拓扑结构如图4，使用移动终端上的APP通过控制器对互通的四端OTN设备进行基于ODUk颗粒的业务快速开通，测试步骤为：在APP“业务”标签页，选择新建业务；选择源宿节点及业务端口；选择业务封装信号类型；选择业务保护类型；点击“提交”，通过测试仪表检查业务是否建立成功。

图4 测试网络拓扑

打表测试结果如图5所示，从测试图可看出，我们以快速开通10GE业务为例，选择源宿节点及客户侧10GE端口，选择业务封装信号类型为ODU2后该10GE业务建立成功，通过测试仪表打流无丢包。

4 结束语

SDN基于控制和转发的分离、集中控制、开放接口的思想，使得网络运维更加简单、业务开通更加快捷，通过开放的网络接口API，将使各种网络业务APP化，业务将极大的丰富，提高OTN网络端到端的组网和业务创新能力，实现跨厂商、多域组网场景下的网络控制和管理。控制器的设计是软件定义网络的基础，本文中论述的控制器设计完成了现网要求的部分功能，还需不断优化。

图5 打表测试结果

参考文献：

[1]INDEX VN．Cisco visual networking index：forecast and methodology，2014-2019 white paper[R].2015．

[2]Channegowda M，Nejabati R，Simeonidou D．Soft⁃ware defined optical networks technology and infra⁃structure:enabling software defined optical network operations[J].IEEE/OSA Journal of Optical Commu⁃nications and Networking，2013，5（10）：274-282.

[3]何炜，杨铸，蔡鸣，等.光传送网的SDN化趋势及影响[J].光通信研究，2014，40（3）:4-7.

[4]杨日成.基于SDN框架的通信网络的研究与应用[D].长春：吉林大学，2014.

[5]黄韬，刘江，魏亮，等．软件定义网络核心原理与应用与实践[M]北京：人民邮电出版社，2014

[6]张鹏.SDN破解多厂商组网难题—电信联合设备商完成首个SDON多域组网测试[J].通信世界，2014（26）：13.

[7]荆瑞泉，黄晓明，李俊杰，等.SDON关键技术研究和现场试验[J].电信技术，2016（6）:33-38.

[8]华楠，郑小平.智能光网络发展历程的回顾和展望:从ASON到PCE，再到SDON[J].电信科学，2014，30（2）:88-98.

[9]纪越峰，张杰，赵永利.软件定义光网络（SDON）发展前瞻[J].电信科学，2014，30（8）:19-22

[10]纪越峰.软件定义光网络的机遇与挑战[J].中兴通讯技术，2013，19（3）:17-20.

[11]P Goransson，C Black.Software Defined Networks A Comprehensive Approach[M].USA:Morgan Kauf mann is an imprint of Elsevier.2014.

[12]Gringeri S，Bitar N，Xia T J.Extending software defined network principles to include optical trans⁃port[J].IEEE Communications Magazine，2013，51（3）:32-40.

[13]曹畅，简伟，王海军，等.SDN与光网络控制平面融合技术研究[J].邮电设计技术，2014（3）:11-15.

[14]张佳玮，赵永利，纪越峰.软件定义光网络技术演进及创新应用[J].信息通信技术，2016（1）:10-16.

[15]张海懿，张国颖，徐云斌.软件定义传送网标准化发展探讨与思考[J].中兴通讯技术，2015，21（6）:45-48.

[16]郑小平，华楠.光网络30年:回顾与展望[J].电信科学，2016，32（5）:24-33.