一种面向SDN 的传统网络功能集成方法设计与实现

郑友伟，朱晓东，刘 磊，郑 策

（1.中国科学院声学研究所国家网络新媒体工程技术研究中心，北京 100190；2.中国科学院大学，北京 100049）

软件定义网络(SDN)[1-3]通过实现控制平面和数据平面的分离推动了网络业务和应用的部署和发展。在SDN 网络中，开发人员调用控制器的北向API 开发网络应用，实现相应的网络功能或者业务需求。对于像DHCP 中继[4]、动态路由[5]等传统网络功能，目前已经存在了非常成熟的第三方网络组件，如果能够设法借助这类第三方组件将网络功能集成到控制器上，将会大大简化传统网络应用的开发。

RouteFlow[6]项目为了能实现在二层交换机上完成三层路由的功能，采用了虚拟路由器与交换机一一映射的方式。Quagga[7-8]路由引擎运行在虚拟路由器上，完成路由的计算。B4 控制器[9]同样集成了Quagga 实现了分布式路由；另一种方案提出在由多个ONOS 控制器[10]组成的集群中，使用SDN-IP 被动式路由，以提供高可用性服务。Click 项目[11]以类似运算集群的设计使得可操作性比较强。L3Routing[12]则将整个网络拓扑抽象成一台路由器，相当于对拓扑内部的特性进行了一定程度地封装。

上述技术方案基本上都是针对某一特定网络功能，如动态路由功能实现的集成方法，不能兼容其他传统网络功能。该文设计与实现了一种通用的传统网络功能集成方法，该方法的核心是创建了与交换机端口具有一一映射关系的TAP 虚拟设备[13]，TAP虚拟设备与交换机端口网络配置完全相同。通过该方法可以便捷地将传统网络功能集成到网络应用上，且适用于多种传统网络功能。该方法大大简化了传统网络应用的开发，且该方法不拘泥于特定控制器，适用于多种类型的控制器。

1 通用集成方法设计与实现

该方法将底层网络流量通过流量代理程序同步给服务器或虚拟化容器中的第三方网络组件，由第三方网络组件完成核心的网络功能。流量代理程序将需要发送的流量发送回APP。流量代理程序是控制器APP 和第三方网络组件之间的桥梁，负责在APP 和第三方网络组件之间传递网络流量。该方法的关键技术是创建了与真实交换机端口一一对应的TAP 虚拟设备，TAP 虚拟设备与交换机端口网络配置完全相同。网络流量代理程序读写TAP 虚拟设备。第三方组件工作于TAP 虚拟设备，通过该方式完成流量的同步与网络功能的实现。可以通过虚拟化容器docker[14]承载该功能模块，并在K8S[14]环境中部署，通过K8S 环境对第三方组件容器进行管理，其工作原理如图1 所示。

图1 第三方组件集成方法工作原理

网络流量代理程序工作程序如算法1 所示，程序首先构建TAP 虚拟设备，用于映射真实交换机的端口，与真实交换机端口为一一对应关系。TAP 虚拟设备是相对独立的虚拟网络设备，其模拟了以太网设备，可以操作二层数据包（以太帧）。使用TAP虚拟设备的目的是把来自协议栈的数据包先交给某个打开了/dev/net/tun 字符设备的用户程序进程处理，还可以选择把数据包重新发回到链路中。可以将虚拟化网卡驱动理解为一端连接着网络协议栈，另一端连接着用户态程序，而普通的网卡驱动则是一端连接着网络协议栈，另一端连接着真实物理网卡。

该文设计了一套基于UDP 的自定义协议，用于规范APP 与网络流量代理之间的通信，自定义协议的报文结构如图2 所示，自定义协议头部包含三个字节：前两个字节记录device_id，第三个字节记录port_id，该协议头完成了TAP 虚拟设备与底层交换机端口的映射关系，该映射关系由APP 进行维护，网络流量代理程序按照预设规则进行协议头与TAP 虚拟设备的转换，并完成对TAP 虚拟设备的读写。具体工作机制主要涉及pkt-in 数据包处理流程以及pkt-out数据包生成和发送流程。

图2 自定义协议报文结构

pkt-in 数据包处理流程：交换机接口接收到网络中的数据包，根据流表匹配结果将相关协议的数据包以pkt-in 消息上报到控制器，控制器按照订阅匹配规则将数据包上送给对应的APP。APP 接收到数据包后，根据pkt-in 消息的交换机DPID 及接收端口来设置UDP 数据包的自定义协议头，然后将数据包放入载荷，通过Socket 编程[15]，以UDP 通信的方式将数据包发送给网络流量代理程序。网络流量代理程序接收到数据包，根据数据包中自定义协议头的device_id 和port_id 选取TAP 虚拟设备，将载荷写入TAP 虚拟设备。第三方网络组件通过TAP 虚拟设备接收到网络数据包，并进行相应处理。

pkt-out 数据包处理流程：第三方网络组件完成对数据包的处理需要发送网络数据包，将数据包写入TAP 虚拟设备。网络流量代理程序通过TAP 虚拟设备接收到网络数据包，将网络数据包封装成UDP 数据包发送给APP。APP 解析自定义协议报文头部，根据所维护的映射状态查找到对应的交换机DPID 及发送端口，依据这些信息封装pkt-out 数据包，并将数据包载荷填入pkt-out 数据包中，将pkt-out 数据包下发给交换机。交换机依据pkt-out 数据包将对应数据包从指定网络端口发送出去。

2 网络应用设计与实现

基于ONOS 控制器，利用该集成方法编写一款通用的传统网络应用，用于与交换机和第三方组件模块的交互。代码如算法2 所示：

APP 主要完成了以下工作：

1）给控制器所连设备下发对应应用的相关表项。

2）订阅相关表项的pkt-in 消息。

3）处理pkt-in消息。根据pkt-in消息的device_id和port_id 将pkt-in 的数据部分封装成自定义协议类型的数据包，然后发送给网络流量代理程序。

4）监听UDP4720 端口，接收从网络流量代理模块发来的数据包，解析数据包。根据device_id 和port_id 生成对应的pkt-out 数据包，并将其下发到对应的交换机，交换机依据pkt-out 数据包正确地转发数据包。

3 功能性验证

该文通过集成DHCP Relay 功能对该集成方法进行了功能性验证。搭建了如图3 所示的测试环境，测试拓扑由ONOS 开源控制器、基于DPDK[16]的POF 交换机[17]、DHCP 服务器和一台测试主机构成。在ONOS 上部署使用了该集成方法的通用APP。主机连到交换机的0 号端口，DHCP 服务器连到交换机的1 号端口，控制器和交换机之间通过6643 端口进行通信。网络流量代理程序也运行在交换机所在的服务器上。网络流量代理程序和APP 采用基于UDP的自定义协议进行通信[18]。

图3 测试环境

3.1 测试步骤

1）在一台LINUX 服务器上安装DHCP 软件包用作DHCP 服务器。服务器地址为192.168.8.250。地址池分配如下：

2）将测试主机IP 地址获取方式设置为DHCP获取。

3）启动控制器APP。

4）在192.168.200.2 服务器上启动流量代理程序和DHCP Relay 功能。如图4 所示，DHCP Relay 功能启动后开始监听tap0 和tap1 端口。

图4 DHCP Relay启动过程

3.2 测试结果

如图5 所示，测试主机已经成功分配到了IP 地址。交换机抓取到的pkt-out数据包如图6 所示。

图5 测试主机分到的IP地址

图6 交换机收到的pkt-out数据包

4 结束语

为了简化SDN 控制器传统网络功能应用的开发过程，该文设计与实现了一种通用的传统网络功能集成方法，通过网络流量代理程序将需要处理的流量同步到第三方网络组件，第三方网络组件工作在与交换机端口具有一一映射关系的TAP 虚拟设备上。该方法旨在借助第三方网络组件实现传统网络功能，降低传统网络应用开发复杂度。文中基于ONOS 控制器，利用该集成方法开发了一款通用的传统网络应用。并通过集成DHCP Relay 功能对该方法进行了功能性验证。不局限于某一特定网络功能，该集成方法对于路由等其他传统网络功能同样适用，且无关于控制器类型。未来将通过Docker 承载第三方组件模块，并在K8S 环境中部署。