韦 文, 师 进, 王 欣, 周宇晖
(1.北京全路通信信号研究设计院集团有限公司,北京 100070;2.北京市高速铁路运行控制系统工程技术研究中心,北京 100070)
软件定义网络(Softw are Defined Netw ork,SDN)技术诞生于2006 年,是一种新型网络创新架构,是一种实现网络虚拟化的方式。SDN 架构的核心思想是将网络设备的控制面与数据面分离开,设备开放可编程的控制接口,由位于中心的SDN 控制器对整个网络设备进行集中控制,功能丰富的控制器将较大地拓展网络能力,实现网络功能的灵活控制和调度,使网络作为管道变得更加智能,为核心网络及应用创新提供良好的平台。
随着SDN 技术的发展成熟,SDN 已在数字中心互连、软件定义的广域网(Softw are Defined-Wide Area Network,SD-WAN)、行业专用网络等场景中应用,并将应用于方兴未艾的5G 移动通信网络领域。
轨道交通通信系统作为行业专用网络系统,对网络的首要要求是高可靠、高安全。传统网络技术主要采用冗余保护、网络安全技术提供相关特性。SDN 的出现为行业专用网络的构建提供了新的思路,如何为轨道交通通信专用网络开发专用SDN 控制器已成为目前相关领域的研究热点之一。本文将研究如何进行SDN 控制器的开发,并主要研究如何采用业界成熟SDN 开源软件项目进行定制化开发方法。该开发方式既可快速构建和部署与业界主用SDN 控制器软件框架一致的控制器,又可融合具有行业特色的用户定制软件功能,满足轨道交通通信等行业的特殊应用需求。
控制器软件可完全自主开发,也可参考部分成熟开源项目。即使自主开发,开源项目也可提供良好的参考。目前业界最典型的两种开源控制器软件为Open Daylight(简称ODL)和Open Netw ork Operating System(简称ONOS)。
ODL 是由Linux 基金会推出的一个开源项目,集聚了行业中领先的供应商和Lin ux 基金会的一些成员。ODL 的目标是建立一套标准化软件,帮助用户以此为基础开发出具有附加值的应用程序。
ONOS 是由斯坦福、伯克利等知名大学联合了运营商、设备制造商等发起的非营利性开源社区组织,其目标是创建一个运营商级的开源SDN 网络操作系统,满足运营商网络迁移到SDN 的需求。
在近几年的快速发展中,两种开源控制器项目相互取长补短,包括在整体软件架构上也相互模仿,接口类型支持全面,它们的开源社区参与者中有很大部分是重合的厂商,因此两种开源控制器目前都是业界主流项目,用户在具体项目开发中可针对更细致的比较项进行对比挑选,如表1 所示。
表1 典型开源控制器软件比较Tab.1 Comparison of typical open-source controllers
本文主要以ONOS 为例对控制器定制化开发方法进行说明。
ONOS 作为一个控制器开发平台,其底层运用了Karaf 平台。Karaf 是一个Java 的轻量级的开放服务网关协议(Open Service Gateway Initiative,OSGi)容器平台,其特点是支持各组件和应用的热部署、动态配置,并集成了多种日志处理系统、可编程扩展控制台、安全认证机制等。因此ONOS 采用的是一个Java 动态化、模块化的系统软件框架。
ONOS 整个框架结构如图 1 所示。
图1 ONOS框架结构图Fig.1 ONOS framework structure
ONOS 的分层结构完整覆盖了SDN 网络从底层网元设备到顶层用户应用组件的各层次,内核层已提供SDN 控制器所需的所有必要组件,而且ONOS为各层解耦开发提供了良好的机制,包括:服务发布(Provider)-调用,服务监听(Listener)-通知,服务注册(Registry)-响应等。传统Java 开发中组件调用依赖关系被转变为服务依赖关系,组件间呈现松耦合状态。
因此,通常基于ONOS 定制化开发控制器时,主要集中考虑应用组件的定制开发即可,有时涉及南向接口中网元硬件私有协议或驱动的开发。
ONOS 应用组件有两种常用的开发方式。
第一种方式是直接修改ONOS 开源代码。由于ONOS 底层为K ar af 容器平台,各应用组件可封装成Bundle 或Feature(即多个Bundle 及配置的集合)动态加载,ONOS 自身还提供了称为App的可选封装方式。因此该方式是以模块化的方式对ONOS 进行修改或添加,其优点是方便快捷,缺点是依赖整个ONOS 代码,当ONOS 定期发布升级版本时,定制化组件的代码移植、重新编译工作较繁琐。
第二种方式是为应用组件创建独立的Bu n d le、Feature 或App 代码工程。Karaf 或ONOS 的容器管理都支持从外部安装和动态部署应用组件,定制开发完成后,在运行阶段而不是编译阶段将应用组件嵌入到ONOS 运行平台中。该方式成功解耦了应用组件代码的开发维护和ONOS 开源社区代码的发展升级,因此是本文推荐的开发方式。下文采用该方式介绍一个定制ONOS 应用组件的开发示例。
在本示例中,假设用户需为ONOS 控制器增添一个基于简单网络管理协议(Simp le Netw or k Management Protocol, SNMP)的链路告警应用组件,其功能为通过SNMP 协议自动接收网元上报的链路状态信息,并在ONOS 控制台界面上打印显示告警信息。
链路告警应用组件的工作场景如图 2 所示。
网元间链路互连组成SDN 网络的数据面,控制器逻辑上与所有网元的管理口连接组成SDN 网络的控制面,此外SNMP 报文也在控制面中传送。网元监测到数据面链路状态变化时,将SNMP 报文上报给控制器的链路告警应用组件进行处理。
用代码开发工具构建一个名为链路告警(Link A lar m)的应用组件代码项目。推荐使用Mav en 或集成了Maven 插件的集成开发环境,因为Maven 提供了很多自动生成ONOS/Karaf 应用组件的模板。该代码项目包含的模块如下。
1)Link Alarm-suite:仅包含一个项目对象模型(Project Object Model,POM)文件,用于描述如何将该组件所有模块组织为一个ONOS ap p,其总体依赖关系和参数等。
2)Link Alarm-apps:应用组件主模块,这里封装为Feature 并包含3 个典型的Bundle:
Link Alarm-main:定义组件主函数入口;
Link Alarm-cli:定义组件在ONOS 控制台中新增的命令;
Link Alarm-api:定义组件的对外服务接口。3种Bundle 均可用对应的Maven 模板生成,注意在生成的POM 文件中使用了标签
3)Pr oviders:SNMP 协议的服务模块,包括两个Bundle:
Device-prov:负责用SNMP 初始化网元设备;
Alarm-prov:负责用SNMP 协议接收网元设备上报的数据,进行处理并输出结果。
4)Dr iver s:SNMP 协议允许各网元设备厂商定义私有管理信息库(Management Information Base,MIB),因此需要在Drivers 模块中定义相应的私有MIB。用一个xml 文件和标签
5)Pr otocols:实现标准的SNMP 通信协议,该部分可直接引用既有的第三方代码或协议库。
6)U tils:一些工具类实用功能模块,如单元测试、异常处理等。
在告警应用组件中,主要功能逻辑体现在Alarm-prov 模块中,其流程框如图3 所示。
该流程主要分为两大部分,一是为网元设备配置、建立SNMP 会话进行报文监听;二是接收网元设备上报的SNMP 报文后,根据厂商MIB 库进行报文内容翻译,提取告警信息并输出。
图3 Alarm-prov模块流程图Fig.3 Flowchart of Alarm-prov module
按照本文所述开发方法设计实现了告警应用组件的演示程序。编译通过后,在图2 所示场景上运行、试验过程如下:
1) 运行ONOS,安装告警应用组件到ONOS中;
2) 用命令使能告警应用组件:ap p activ ate Link Alarm-suite;
3) 网元设备上设置SNMP 试验参数:上报的IP 地址为ONOS 的IP 地址;触发事件的OID分 别 为1.3.6.1.6.3.1.1.5.3( 链 路 断 开) 和1.3.6.1.6.3.1.1.5.4(链路启用);
4) 用脚本将网元设备的配置推送到ONOS 中,让Device-prov 模块发现并初始化网元;
5) 试验操作:对IP 为192.168.10.57 的网元上连接的网线,先拔出后重新插入,观察输出。
结果输出示例如图4 所示,拔出网线时,ONOS 收到SNMP trap 报文后解析,实时显示端口3 为Link Dow n(链路断开)事件;重新插入网线时,ONOS 显示端口3 为Lin k U p(链路启用)事件。
图4 告警应用组件示例运行结果Fig.4 Example result of Link Alarm app
研究基于开源SDN 控制器定制化开发专网控制应用组件的方法,并以ONOS 上开发告警应用组件为示例进行演示。该方法对于快速构建灵活可靠的轨道交通行业专网控制器有指导意义。
基于本文的方法,建议进一步研究扩展告警应用组件并与网络自动恢复组件进行联动,形成自动化网络故障保护功能,发挥SDN 控制器动态调度网络的优势,提高轨道交通通信专网的可靠性。