一种基于SDN与NFV技术实现高速互联互通的系统和方法与流程

本申请涉及sdn(softwaredefinednetwork，软件定义网络)与nfv(networkfunctionvirtualization，网络功能虚拟化)网络通信技术领域，特别是涉及一种基于sdn与nfv技术实现高速互联互通的系统和方法。

背景技术：

ip网络是一种能够涵盖文本、语音以及视频等多媒体业务的融合网络。随着互联网技术的发展，ip网络采用“打补丁”式的演进策略，使得ip设备的功能和业务越来越复杂，ip设备的复杂导致ip网络管理和运维的复杂化。具体地，当前ip网络在部署一个全局业务策略时，需要逐一配置每台ip设备，而ip网络控制平面和数据平面的深度耦合，使得任何一个新技术的引入都严重依赖网络设备，并需要多个网络设备同步更新，导致新技术的部署周期较长。因此，如何打破网络的封闭架构，增强网络的可编程能力，是提升ip网络性能的重要问题。

目前的ip网络通常采用sdn网络架构，具体地，一个sdn网络架构中包括大型的控制器和复杂的转发器，数据控制面从传统网络的单个设备上剥离，集中到控制器上，而数据转发面由转发器构成，执行转发动作的交换机一般称为转发器。控制器负责收集整个网络的拓扑、流量等信息，计算流量转发路径，通过openflow(用来描述控制器和交换机之间交互所用信息的标准,以及控制器和交换机的接口标准)协议将转发表项下发给交换机，交换机按照表项执行转发动作。

然而，目前的sdn网络架构，由于其控制器和转发器均为大型复杂设备，操作步骤较复杂，使得ip网络的数据部署和配置复杂，数据处理效率不够高，且运维效率低，尤其在中小型企业中不便于推广。

技术实现要素：

本申请提供了一种基于sdn与nfv技术实现高速互联互通的系统和方法，以解决现有技术中的sdn网络操作复杂、运维效率低以及不便于推广的问题。

为了解决上述技术问题，本申请实施例公开了如下技术方案：

一种基于sdn与nfv技术实现高速互联互通的系统，所述系统应用于中小型企业，所述系统包括：一个hubcpe和多个cpe(customerpremiseequipment，客户终端设备)，且所述hubcpe分别与多个cpe中的任一cpe通过数据隧道互联；

所述hubcpe包括hubcpe硬件单元和hubcpe软件单元，所述hubcpe硬件单元支持x86架构，所述hubcpe软件单元包括：vpp(vectorpacketprocessing，批量数据包处理软件)、web系统、vcpeproxy系统和mysql；

所述vpp，用于在hubcpe中利用vpp-dpdk(dataplanedevelopmentkit，数据面开发套件)技术进行数据转发；

所述vcpeproxy系统，用于进行上线认证协议解析，以及根据解析结果对所述vpp进行初步配置；

所述web系统，用于对所述vpp进行查看和整体配置；

所述mysql，用于对vpp相关的数据进行记录；

所述任一cpe包括cpe硬件单元和cpe软件单元，所述cpe硬件单元支持x86架构和arm架构，所述cpe软件单元包括：ovs(openvswitch网络，一个高质量多层虚拟交换机的网络)和自协商程序；

所述ovs，用于在所述任一cpe中进行数据转发；

所述自协商程序，用于对所述ovs进行控制。

可选地，所述hubcpe硬件单元包括：x86架构的vn系列产品或x86架构且设置有支持dpdk技术的网卡的设备。

可选地，所述cpe硬件单元包括：x86架构的vn系列产品或arm架构的en系列产品。

可选地，所述hubcpe和所述任一cpe之间的上线协议结构为json结构。

可选地，所述数据隧道的隧道类型包括：vxlan、ipsec、gre、vxlanoveripsec、greoveripsec、ipsecovervxlan或者greovervxlan。

可选地，其特征在于，所述hubcpe上设置有restful协议接口和netconf协议接口。

一种基于sdn与nfv技术实现高速互联互通的方法，所述方法应用于中小型企业系统中，所述系统中包括一个hubcpe和多个cpe，且所述hubcpe分别与多个cpe中的任一cpe通过数据隧道互联，所述方法包括：

cpe根据hubcpe的ip地址，按照自定义的上线协议向hubcpe发起注册请求；

hubcpe按照自定义上线协议的格式，对所获取的注册请求进行解析；

根据cpe注册清单，判断与所述注册请求相匹配的cpe是否已获批准；

如果是，hubcpe向cpe返回注册成功的回馈报文；

cpe根据所获取的回馈报文，向hubcpe发送keepalive报文；

hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面中创建与所述cpe相匹配的数据隧道，并向所述cpe反馈收到应答；

hubcpe根据cpe发送的第二个及以后的keepalive报文，记录收到keepalive报文的时间，并向所述cpe反馈收到应答。

可选地，所述方法还包括：

如果与所述注册请求相匹配的cpe还未获批准，将所述cpe记录在待审批表中；

根据所获取的审批命令，对所述cpe进行批准。

可选地，hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面中创建与所述cpe相匹配的数据隧道之后，所述方法还包括：

在hubcpe中将cpe的状态修订为已上线。

可选地，当所述数据隧道的隧道类型为vxlan时，所述hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面中创建与所述cpe相匹配的数据隧道的方法，包括：

根据cpe发送的第一个keepalive报文，将远端端口记录在vxlantunnelendpoint结构体中，并创建vxlan隧道；

数据转发过程中，通过vxlantunnel路由查找hash算法，由远端端口和远端ip计算获得相匹配的vxlantunnelnode；

利用所述vxlantunnelnode执行vxlan组包和拆包逻辑。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请提供一种基于sdn与nfv技术实现高速互联互通的系统，该系统主要应用于中小型企业，该系统包括一个hubcpe和多个cpe，hubcpe与每个cpe之间通过数据隧道互联，且hubcpe和每个cpe均包括软件单元和硬件单元。hubcpe软件单元包括作为数据转发平面的vpp以及作为数据控制平面的web系统、vcpeproxy系统和mysql。cpe软件单元包括作为数据转发平面的ovs以及作为数据控制平面的自协商程序。本系统中hubcpe硬件单元可采用x86架构的vn系列产品，cpe硬件单元可采用x86架构或arm架构，因此系统架构简单，不需要购买专门的vpn硬件设备即可实现vpn互联互通，操作简单，数据传输效率高，运维简单，有利于推广使用。而且本申请中hubcpe的数据转发平面vpp采用vpp-dpdk技术，运行在操作系统的userspace(用户态)模式，能够利用自身的数据面库进行收发包处理，从而绕开linux内核态协议栈，有利于提升报文的处理效率，从而能够大大提高网络数据的处理效率。本申请中cpe硬件单元同时支持x86架构和arm架构，可以根据不同的业务需求进行灵活选择，兼容性高，有利于提高整个系统的灵活性。另外，本申请数据隧道的隧道类型包括多种，用户可以根据业务需求进行灵活切换，有利于提高整个系统的灵活性和兼容性。

本申请还提供一种基于sdn与nfv技术实现高速互联互通的方法，该方法主要应用于中小型企业的互联互通系统中，且该系统中包括一个hubcpe和多个cpe。该方法首先cpe根据hubcpe的ip地址，按照自定义的上线协议向hubcpe发起注册请求，hubcpe按照自定义上线协议的格式，对所获取的注册请求进行解析，并判断当前cpe是否已获批准，只有当前cpe已获批准时，hubcpe向cpe返回注册成功的回馈报文，cpe根据所获取的回馈报文，向hubcpe发送keepalive报文，然后hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面中创建与cpe相匹配的数据隧道，并向cpe反馈收到应答，之后仅更新cpe发送keepalive报文的时间，以及hubcpe向cpe发送收到应答，从而实现hubcpe的数据转发平面vpp和cpe的数据转发平面ovs之间正常的高速数据转发和通信。本申请中hubcpe和cpe之间进行自动协商上线并构建数据隧道，灵活性高，数据处理效率高；通过简单的初始化配置ip地址，以及配置hubcpe和每个cpe之间的隧道类型等基本信息，即可实现自动上线，因此本申请中ip网络的部署更加方便快捷，在中小型企业中非常便于推广使用。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例所提供的一种基于sdn与nfv技术实现高速互联互通的系统的结构示意图；

图2为本申请实施例中系统的拓扑架构图；

图3为本申请实施例所提供的一种基于sdn与nfv技术实现高速互联互通的方法的流程示意图；

图4为本申请实施例中vxlan穿nat的数据流示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

为了更好地理解本申请，下面结合附图来详细解释本申请的实施方式。

实施例一

参见图1，图1为本申请实施例所提供的一种基于sdn与nfv技术实现高速互联互通的系统的结构示意图。由图1可知，本实施例中的系统主要包括：一个hubcpe和多个cpe，hubcpe作为中心汇聚端，分别与多个cpe中的任一cpe通过数据隧道互联。

hubcpe包括hubcpe硬件单元和hubcpe软件单元。其中，hubcpe硬件单元支持x86架构。具体地，hubcpe硬件单元包括：x86架构的vn系列产品或x86架构且设置有支持dpdk技术的网卡的设备。其中，x86架构且设置有支持dpdk技术的网卡的设备可以选择至强服务器。

hubcpe软件单元包括：vpp、web系统、vcpeproxy系统和mysql。其中，vpp用于在hubcpe中利用vpp-dpdk技术进行数据转发；vcpeproxy系统用于进行上线认证协议解析，以及根据解析结果对vpp进行初步配置；web系统用于对vpp进行查看和整体配置；mysql为数据库，用于使用数据库对vpp相关的数据进行记录。vpp作为hubcpe的数据转发平面，web系统、vcpeproxy系统和mysql构成hubcpe的数据控制平面。

本实施例中hubcpe的数据转发平面vpp采用vpp-dpdk技术，运行在操作系统的userspace模式下，利用vpp自身提供的数据面进行收发包处理，避免使用linux内核态协议栈，使得hubcpe作为中心汇聚端，能够支撑较高的网络转发速率，有利于提高报文处理效率，实现超高速的数据传输，从而大大提高系统对网络数据的处理效率。另外，本实施的数据转发平面vpp还支持多种数据隧道类型，有利于提高系统的兼容性和灵活性。

hubcpe软件单元在实际应用中，首先hubcpe的数据转发平面vpp采用vpp-dpdk技术运行在操作系统的userspace模式下，进行收发包处理；然后，hubcpe运行vcpeproxy程序，对上线认证协议进行解析，根据协议解析结果对vpp进行初步配置，并通过mysql进行相关数据的记录；hubcpe上运行tomcat，利用web系统作为控制平面，对vpp进行全面查看和配置。

继续参见图1可知，本实施例中任一cpe包括cpe硬件单元和cpe软件单元。其中，cpe硬件单元支持x86架构和arm架构。具体地，本实施例中cpe硬件单元包括：x86架构的vn系列产品或arm架构的en系列产品。本实施例中cpe硬件单元兼容x86架构和arm架构，实际应用中可以根据业务需求和侧重点进行灵活选择。通常，侧重于并行计算和虚拟化能力的业务中，可以选择x86架构的cpe硬件单元；侧重于网络转发能力的业务中，可以选择arm架构的cpe硬件单元。

任一cpe中的cpe软件单元包括：ovs和自协商程序。其中，ovs作为cpe的数据转发平面，用于在任一cpe中进行数据转发；自协商程序作为cpe的数据控制平面，用于对ovs进行控制。cpe利用ovs作为数据转发平面，能够提供普通转发、vxlan隧道以及ike协商等功能，其中ike协商的目的是为了创建ipsec隧道。cpe自协商程序负载自定义上线协议的解析和配置。具体地，首先配置hubcpe的ip地址，然后发起上线协商，上线协商成功后即可在hubcpe上显示为已上线。本实施例中基于sdn与nfv技术实现高速互联互通的系统的拓扑架构图，可以参见图2。由图2可知，cpe和hubcpe之间通过数据隧道互联；hubcpe提供可视化的web管理界面，cpe下连设备互通，与hubcpelan口设备互通。

本实施例中用于实现hubcpe与任一cpe之间互联的数据隧道的隧道类型包括：vxlan、ipsec、gre、vxlanoveripsec、greoveripsec、ipsecovervxlan或者greovervxlan等。其中，vxlan即为两层vpn(virtualprivatenetwork，虚拟专用网络)隧道协议，ipsec和gre为三层vpn隧道协议，vxlanoveripsec、greoveripsec、ipsecovervxlan以及greovervxlan为组合协议隧道类型。本实施例中支持多种隧道类型，实际应用中可以根据业务需求进行切换，切换时只需在web系统中修改隧道类型即可。本实施例中，hubcpe与任一cpe之间数据隧道有多种隧道类型可选，能够大大提高整个系统的灵活性和兼容性，有利于提高数据处理效率，便于推广使用。

本实施例中的数据库表都应用于hubcpe软件单元的vcpeproxy系统中。本实施例中利用gw_info表保存所有cpe的设备参数，这些设备参数包括：设备名称、设备sn(serialnumber，产品序列号)、隧道类型以及设备状态。假设定义gw_info表中tunnel_type为0时，隧道类型为vxlan；定义gw_info表中tunnel_type为1时，隧道类型为ipsec，那么，vxlan_id作为一个外键，所连接的是vxlan_info表；ipsec_id作为一个外键，所连接的是ipsec_info表。cpe接入请求表，hubcpe端收到cpe设备发起的上线协商的第一个报文之后，在请求表中新增一条记录，该新增记录可以通过web系统的界面查看、批准以及初始化配置。

另外，本实施例中hubcpe和任一cpe之间的上线协议结构为json结构。上线协议结构采用json格式，该数据格式简单，易于读写和解析，有利于提高数据读写效率，且该格式均为压缩格式，占用的带宽小，有利于节省系统资源。json格式还支持多种语言，如：actionscript，c，c#，coldfusion，java，javascript，perl，php，python以及ruby语言等，这些语言为服务器端语言，便于服务器器进行解析，从而提高数据解析的效率，而且，由于json格式能够直接为服务器端代码使用，能够大大简化服务器端和客户端的代码开发量，提高工作效率且易于推广使用。

进一步地，本实施例中hubcpe上设置有restful协议接口和netconf协议接口，restful协议接口基于http协议，netconf协议接口基于ssh协议。restful协议接口和netconf协议接口作为本系统的控制接口，用于将本系统与其他sdn系统对接，便于将本系统集成到其他sdn系统中，有利于扩大本系统的应用范围和场景。

综上所述，本实施例中基于sdn与nfv技术实现高速互联互通的系统的架构相比于现有的sdn系统，其结构更加简单，只需要普通的vn系列设备和en系列设备即可实现。而且这种结构设置，使得整个系统的部署成本较低，不需要购买专门的vpn硬件设备即可实现vpn互联互通，甚至连vn系列设备和en系列设备都不需要购买，重用现有空闲的设备即可，当然该空闲的设备需要设置有支持dpdk技术的网卡。

实施例二

在图1和图2所示实施例的基础之上参见图3，图3为本申请实施例所提供的一种基于sdn与nfv技术实现高速互联互通的方法的流程示意图。由图3可知，本实施例中基于sdn与nfv技术实现高速互联互通的方法，主要包括如下步骤：

s0：cpe根据hubcpe的ip地址，按照自定义的上线协议向hubcpe发起注册请求。

本实施例中hubcpe的ip地址需要预先配置。

s1：hubcpe按照自定义上线协议的格式，对所获取的注册请求进行解析。

s2：根据cpe注册清单，判断与注册请求相匹配的cpe是否已获批准

具体地，hubcpe软件单元的mysql中预存有cpe注册清单，hubcpe对所获取的注册请求进行解析后，将所获取的注册请求与mysql中的cpe注册清单进行比对，判断与注册请求相匹配的cpe是否已获批准。

如果与注册请求相匹配的cpe已获批准，则执行步骤s5：hubcpe向cpe返回注册成功的回馈报文。

本实施例中所返回的回馈报文包括cpe的隧道类型和相关参数。

进一步地，如果与注册请求相匹配的cpe未获批准，执行步骤s3和s4。

s3：将cpe记录在待审批表中。

s4：根据所获取的审批命令，对cpe进行批准。

本实施例中对cpe进行注册批准时，需要用户登录web系统进行手工校验和批准。

继续参见图3可知，hubcpe向cpe返回注册成功的回馈报文之后，执行步骤s6：cpe根据所获取的回馈报文，向hubcpe发送keepalive报文。

cpe收到注册成功的回馈报文之后，根据该回馈报文向hubcpe发送keepalive报文。本实施例中cpe会以固定的时间间隔不停地发送keepalive报文，以便于监测连接状态。

s7：hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面中创建与cpe相匹配的数据隧道，并向cpe反馈收到应答。

进一步地，本实施例中hubcpe根据cpe发送的第一个keepalive报文，在hubcpe的数据转发平面vpp中创建与cpe相匹配的数据隧道之后，还包括步骤s8：在hubcpe中将cpe的状态修订为已上线，以便于用户通过web系统及时而方便地获取cpe的状态。

s9：hubcpe根据cpe发送的第二个及以后的keepalive报文，记录收到keepalive报文的时间，并向cpe反馈收到应答。

通过以上步骤s0-s9，hubcpe的数据转发平面vpp和cpe的数据转发平面ovs之间，便可进行正常的数据转发数据通信。

进一步地，本实施例中数据隧道的隧道类型包括：vxlan、ipsec、gre、vxlanoveripsec、greoveripsec、ipsecovervxlan或者greovervxlan。多种隧道类型可选，使得本方法能够适用于不同的业务场景，有利于扩大本方法的应用范围，以及提高数据互联互通的灵活性。

当隧道类型为vxlan时，步骤s7包括如下过程：

s71：根据cpe发送的第一个keepalive报文，将远端端口记录在vxlantunnelendpoint结构体中，并创建vxlan隧道。

s72：数据转发过程中，通过vxlantunnel路由查找hash算法，由远端端口和远端ip计算获得相匹配的vxlantunnelnode。

s73：利用vxlantunnelnode执行vxlan组包和拆包逻辑。

具体地，本实施例中vxlan穿nat的数据流示意图可以参见图4。vxlan协议有五个要素：本地ip、本地端口、远端ip、远端端口、vni。vpp原有vxlan隧道协议实现中，本地端口和远端端口都是固定的，假设远端端口地址固定位4789，无法支撑vxlan穿nat的功能。本实施例对vpp进行改进，改进点包括：vxlantunnelendpoint结构体、vxlantunnel路由查找hash算法、vxlan组包和拆包逻辑、vxlan隧道创建和删除的命令行和api。如果cpe位于nat内侧，当步骤s6中cpe发出的第一个keepalive数据包被封装在vxlan头部之后后，vxlan穿越nat时会把ip地址ip-internal和udp源端口号4789映射成公网ip地址ip-public和一个由nat算法计算得出的端口udp-src-port-public，然后，数据包会被送到hubcpe的数据转发平面vpp中，在步骤s7中，vpp收到数据包后会记录下该ip-public和udp-src-port-public，同时以ip-public作为远端ip，udp-src-port-public作为远端端口，创建vxlan，这样vxlantunnelendpoint结构体就能正常处理与cpe之间的vxlan隧道数据的封装和解封装了。vpp从该vxlan隧道发出的数据会发往ip-public的udp-src-port-public端口，经过查找映射记录，即可把ip-public和udp-src-port-public转换为ip-internal和4789，最后数据到达cpe进行处理。

该实施例未详细描述的部分，可以参见图1和图2所示的实施例一，两个实施例之间可以互相参照，在此不再赘述。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。