CN107222353B - 支持协议无关的软件定义网络虚拟化管理平台 - Google Patents

Abstract

本发明公开了一种支持协议无关的软件定义网络虚拟化管理平台，该平台支持不同租户在同一物理资源上创建和管理多个虚拟网络，每个虚拟网络都可以灵活的自定义拓扑，且每个虚拟网络可以根据需求使用自定义协议，从而充分发挥SDN的可编程能力；同时，虚拟网络之间通过添加标签的方式隔离流量；此外，通过引入分支流表和虚拟网络流表，对流表进行规划，使得数据包处理速率大幅提高。

Description

支持协议无关的软件定义网络虚拟化管理平台

技术领域

本发明涉及软件定义网络的虚拟化管理技术领域，尤其涉及一种支持协议无关的软件定义网络虚拟化管理平台。

背景技术

网络虚拟化(networkvirtualization)是指在一个共享的物理网络资源之上创建多个虚拟网络，且可以同时独立地部署以及管理多个虚拟网络。其中，每个虚拟网络可以自定义虚拟网络拓扑并运行自定义协议。通过使用网络虚拟化，可以提高底层物理资源的利用率。此外，网络虚拟化的引入使得网络结构的动态化和多元化成为可能，被认为是解决现有网络僵化问题，构建下一代互联网最好的方案。

由于网络虚拟化具有众多的优点且应用场景广泛，因此针对网络虚拟化技术的研究越来越多。目前针对网络虚拟化的研究有两种思路，一种是基于当前网络架构实现。例如：虚拟局域网络(VLAN)、虚拟专用网络(VPN)、主动可编程网络(APN)、覆盖网络(OverlayNetwork)。另外一种是采用诸如软件定义网络(SoftwareDefinedNetworking，以下简称SDN)这类新型的网络架构。

SDN是一种新型的网络架构，通过集中控制的方式，将网络中的控制平面与转发平面分离。其中，控制平面由控制器组成，负责集中化管控；转发平面由相关的转发设备组成，负责数据的转发。SDN不仅解决了当前网络架构中存在的诸多问题，例如：设备配置繁琐且迭代缓慢。而且还实现了网络可编程，有助于实现资源的优化利用，提升网络管控效率。

基于SDN优良的体系结构，使用SDN部署实现网络虚拟化得到越来越多的重视。传统的网络虚拟化部署需要手动逐跳配置，效率低下，人力成本很高。SDN通过集中控制的方式，网络管理员可以通过控制器的API来编写程序，从而实现自动化的业务部署，大大缩短业务部署周期。两层分离的模型使得SDN可以实现三种不同层级的网络虚拟化。一种是转发平面虚拟化，即每个交换机本身具备虚拟化能力。一种是介于控制平面与转发平面之间实现虚拟化，即通过消息代理实现虚拟化。另一种是控制平面虚拟化，即实现SDN控制器的虚拟化。

目前，SDN最知名的南向接口是ONF提出的OpenFlow协议。OpenFlow使得原来完全由交换机、路由器控制的数据转发过程转化为由OpenFlow交换机和OpenFlow控制器共同完成，从而实现了数据转发和路由控制的分离。控制器可以通过事先规定好的接口操作控制OpenFlow交换机中的流表，从而达到控制数据转发的目的。

Flowvisor是第一个基于OpenFlow协议的SDN网络虚拟化管理平台。它能够将底层的物理资源抽象出来供多个虚拟网络共享。虚拟网络的划分范围涵盖了物理层、数据链路层、网络层和传输层的协议字段，按照流的思想将网络资源进行合理分配，使不同的虚拟网络具有不同的流空间，从而使各虚拟网络之间流量隔离。

然而，Flowvisor存在若干问题：

1)无法处理流空间重叠的情况。Flowvisor根据用户策略生成的流空间划分虚拟网络，实际上是将一个完整的协议头部字段空间划分给不同的用户，由于每个虚拟网络的流空间由用户自己定义，因而存在潜在的可能性使得不同虚拟网络的流空间重叠，对此Flowvisor无法妥善处理。

2)Flowvisor没有虚拟设备的概念。由于同一个物理设备可能被多个虚拟网络共用，当其中一个虚拟网络修改该设备的相关属性时，可能会对其它虚拟网络产生影响。

3)不支持虚拟拓扑。Flowvisor同样没有虚拟端口和虚拟链路的概念，只是对物理端口进行简单的划分。因此，虚拟网络的拓扑一定是物理网络拓扑的子图。

4)不支持地址虚拟化。所有的虚拟网络共享地址空间，每个虚拟网络都无法拥有一个完整独立的地址空间。

针对Flowvisor存在的问题，原有团队提出了一种新的网络虚拟化管理平台OpenVirtex(以下简称OVX)。与Flowvisor相似，OVX也处于OpenFlow交换机与OpenFlow控制器之间，作为两者之间的代理。两者之间的区别在于对数据包头的处理粒度不同，Flowvisor会根据流空间的信息将不同主机进行划分，以此来组成不同的虚拟网络。而OVX则为每个虚拟网络提供一个完整的地址空间，即地址虚拟化。此外，OVX还允许租户自定义独立于物理网络拓扑的虚拟网络拓扑。

即使OVX弥补了Flowvisor的存在的问题，但它仍面临以下问题：

1)OVX通过改写MAC和IP字段区分虚拟网络流量。如果租户不是根据MAC转发，即下发的流表项中不匹配MAC，OVX无法处理。

2)流表项爆炸。OVX中主机的MAC地址是区分虚拟网络的关键，改写后的MAC地址中包含FlowID，且每个FlowID对应于一个源MAC和一个目的MAC所组成的地址对。因此，当虚拟网络连接的主机数目增多，为了使任意主机之间可以通信，交换机中流表项的数目将会大幅度增加。

3)匹配效率低。OVX是基于OpenFlow1.0实现的，采用单表结构，所有的虚拟网络的流表项都集中在一张表中，再加上每个虚拟网络的流表项存在爆炸问题，因此，匹配效率低下。

另一方面，虽然OpenFlow实现了SDN可编程网络的思想，但其本身具有以下问题：1)随着软件定义网络应用场景的拓展和网络技术自身的发展，OpenFlow需要支持越来越多的协议和数据处理方式，被动演进造成匹配字段越来越臃肿。2)只支持现有协议，难以支持新协议，如果要实现基于新协议的服务，需要设备厂商修改设备以支持新协议，导致服务部署周期过长。3)即使针对常用的标准协议，如TCP协议，OpenFlow也不能对其头部的任意域进行匹配和处理。因此，基于OpenFlow实现的SDN网络虚拟化平台其本身就包含了OpenFlow固有的缺陷。

针对OpenFlow所面临的问题，华为提出了协议无感知转发(Protocol-Oblivious-Forwarding，以下简称POF)。POF是对当前的SDN转发平面的增强。底层的转发设备对协议以及处理转发流程没有感知，转发策略完全由控制器负责，彻底解耦了控制平面和转发平面。因此，POF使得转发设备能够支持任意的协议而不用修改它们的硬件结构或是代码组成，从而帮助用户快速部署新的服务和策略。

然而，目前还没有将较为完善的基于POF的SDN网络虚拟化管理平台；鉴于此，有必要对此进行深入研究。

发明内容

本发明的目的是提供一种支持协议无关的软件定义网络虚拟化管理平台，可充分发挥SDN的可编程能力，大幅度提高数据包处理速率，同时对底层物理资源的利用率高。

本发明的目的是通过以下技术方案实现的：

一种支持协议无关的软件定义网络虚拟化管理平台，包括：物理网络管理模块、API模块、虚拟网络管理模块、全局映射模块与消息代理模块；其中：

物理网络管理模块，负责管理整个平台的物理网络资源，在与底层的物理交换机完成基本的握手过程之后，其在平台中为每个底层的物理交换机都维护一个实体对象，每一实体对象负责维护与底层的相应物理交换机之间的TCP连接；

API模块，用于提供创建完整的虚拟网络拓扑以及监视虚拟网络配置和状态信息的API；

虚拟网络管理模块，用于根据API模块的调用实现虚拟网络的创建、配置及初始化，在虚拟网络初始化后，负责完成虚拟交换机与控制器基本的握手过程，并在两者之间建立TCP连接；

全局映射模块，用于存储虚拟交换机和物理交换机的映射信息、虚拟端口与物理端口的映射信息，以及虚拟链路和物理链路的映射信息；

消息代理模块，用于拦截控制器与物理交换机之间的消息，结合全局映射模块的信息对消息进行改写。

所述物理网络管理模块与物理交换机握手过程如下：

首先，物理交换机和物理网络管理模块之间通过Hello消息查看双方对应的协议版本是否相同；

随后，物理网络管理模块向物理交换机下发Feature_request消息以请求物理交换机的基本信息，包括设备编号、端口数目、流表数目以及相应资源的状态；物理交换机通过Feature_reply消息回应物理网络管理模块的请求；

物理网络管理模块获得物理交换机的基本信息之后，通过发送Set_config消息获取相应资源的具体信息；物理交换机收到物理网络管理模块的请求之后，发送相应的消息回应物理网络管理模块；

在获取完整的物理交换机的信息之后，物理网络管理模块与物理交换机之间通过发送Echo消息以保持联系。

每一实体对象中包含一个拓扑发现组件，以向网络中发送LLDPDU或是处理从网络中接收到的LLDPDU；

物理交换机的端口分为两种类型，一种为快速端口，即成功接收LLDPDU的端口；另一种为慢速端口，即发送了最大数目的LLDPDU并且未被确认的端口；

当物理交换机接收到LLDPDU时，通过PacketIn消息上报给物理网络管理模块，物理网络管理模块调用相应物理交换机对应的实体对象中的拓扑发现组件处理LLDPDU；根据PacketIn消息中记录的信息以及LLDPDU中记录的相关信息，实现拓扑发现。

所述API模块中定义了两种类型的API：切片API和监控API；其中，切片API用于创建和配置虚拟网络，监控API用于获取虚拟网络配置和状态信息。

所述虚拟网络管理模块，用于根据API模块的调用实现虚拟网络的创建、配置及初始化，具体包括：

当收到租户下发的创建请求后，经API模块的调用，创建相应的虚拟网络；

在虚拟网络的配置过程中，虚拟网络管理模块为虚拟网络中的每个虚拟组件创建虚拟组件实体并将其映射到底层的物理组件实体上，映射关系存放在全局映射模块中；所述的虚拟组件包括：虚拟交换机、虚拟端口与虚拟链路；

在虚拟网络的初始化过程中，虚拟网络管理模块依次让虚拟组件到达活跃状态，从而启动虚拟网络。

虚拟网络管理模块的拓扑发现负责呈现虚拟网络的拓扑；对于每一个虚拟网络，均模拟了网络中LLDPDU广播与接收的过程。

虚拟网络之间的流量隔离以及全局的流表规划均通过消息代理模块实现；具体如下：

虚拟网络之间的流量隔离：通过消息代理模块在相应数据包头部添加虚拟标签来标识数据包所属的虚拟网络，从而实现不同虚拟网络之间的流量隔离；虚拟标签的前N位为一个POFVisorTag，用于区别其它网络流量；中间的N位为TenantID，其作用是标识所属的虚拟网络；最后的N位为LinkID，其标识数据包传输所在的虚拟链路；

全局的流表规划：通过把数据包处理的入口流表设置为分支流表，进而将分属于不同虚拟网络的数据包导入相应的虚拟网络流表中处理；分支流表由两部分组成，一部分为边界流表项，用于识别相应虚拟网络的主机流量，由于主机通过MAC地址识别，因此边界流表项匹配源MAC地址和数据包的进入端口；另一部分为虚拟流表项，用于区分虚拟网络中的流量，该表项匹配数据包中的虚拟标签和数据包的进入端口；当数据包进入物理交换机后，首先匹配分支流表中的边界流表项，如果匹配中说明该数据包是来自于虚拟网络中的主机，匹配后通过指令跳转到相应虚拟网络流表中；如果未匹配中，则匹配分支流表中的虚拟流表项，如果匹配中，则该数据包属于某个虚拟网络，将数据包头部的虚拟标签去掉，然后跳转到相应虚拟网络流表中进行处理。

所述消息代理模块对消息改写的方式如下：

TableMod消息，用于生成流表；修改方式如下：根据TableType为TableMod重新分配新的TableID，并将对应关系存储在全局映射模块中；此外，当TableMod消息中包含的TableType为OF_MM_TABLE时，平台为该表下发一条默认的PacketIn的流表项；

FlowMod消息，用于生成流表项；修改方式如下：根据全局映射模块中的信息，对消息中包含的TableID与CounterID进行改写，此外，还需要对FlowMod消息中包含的指令和动作进行相应的修改；

PortMod消息的作用是设定openflowenable字段命令虚拟网络交换机端口是否开始按照POF模式处理数据包；对于控制器下发的PortMod消息，将其改写成分支流表中的表项：根据PortMod消息对应的端口的类型，如果是边界端口，则将PortMod消息转化为边界流表项，边界流表项匹配主机的MAC地址和对应的物理端口的端口号，然后通过GotoTable指令跳转到对应虚拟网络流表中；如果端口的类型是链路端口，则将PortMod消息转化为虚拟流表项，虚拟流表项匹配虚拟标签和对应物理端口的端口号，然后去掉数据包头部的虚拟标签，并通过GotoTable指令跳转到对应虚拟网络流表中；

PacketIn消息是当数据包未匹配中流表项，或者执行流表项中包含的PacketIn动作时，物理交换机发送给控制器用于报告一个需要控制器处理的数据包信息；对于PacketIn消息的改写需要区分不同的场景：当PacketIn消息来自于分支流表，则平台向分支流表中下发流表项。其中，流表项的匹配项为源MAC以及数据包的进入端口，流表项中的动作为Drop；当PacketIn消息来虚拟网络流表时，则在上报PacketIn消息时需要将对应的物理端口改写成虚拟端口；

PacketOut消息的作用是控制器控制物理交换机对数据包执行相应的动作并转发数据包，相应的动作存储在actionlist中；PacketOut消息的改写需要修改actionlist中的所有动作，通过调用对应动作的改写操作完成；

还包括：日志模块，用于记录平台运行期间的数据，以及打印与平台操作相关的日志信息。

由上述本发明提供的技术方案可以看出，该平台支持不同租户在同一物理资源上创建和管理多个虚拟网络，每个虚拟网络都可以灵活的自定义拓扑，且每个虚拟网络可以根据需求使用自定义协议，从而充分发挥SDN的可编程能力；同时，虚拟网络之间通过添加标签的方式隔离流量；通过引入分支流表和虚拟网络流表，对流表进行规划，使得数据包处理速率大幅提高。此外，POFVisor的引入不会对原有性能造成影响，对物理资源的利用率高。

附图说明

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

图1为本发明实施例提供的一种支持协议无关的软件定义网络虚拟化管理平台的示意图；

图2为本发明实施例提供的全局的流表规划示意图；

图3为本发明实施例提供的物理网络管理模块与物理交换机的握手流程图；

图4为本发明实施例提供的拓扑发现组件的整体行为流程图；

图5为本发明实施例提供的拓扑发现组件处理LLDP的流程图；

图6为本发明实施例提供的虚拟网络初始化的流程图；

图7为本发明实施例提供的虚拟网络拓扑发现的流程图；

图8为本发明实施例提供的实验一中的物理拓扑图；

图9为本发明实施例提供的实验一中创建的虚拟网络VN1的示意图；

图10为本发明实施例提供的实验一中创建的虚拟网络VN2的示意图；

图11为本发明实施例提供的实验一中虚拟网络VN1和VN2的虚拟拓扑图；

图12为本发明实施例提供的实验一中终端主机h3处抓包结果；

图13为本发明实施例提供的实验一中终端主机h4处抓包结果；

图14为本发明实施例提供的实验二中的物理拓扑图；

图15为本发明实施例提供的实验二中的物理链路实际带宽示意图；

图16为本发明实施例提供的实验二中创建的虚拟网络VN1的示意图；

图17为本发明实施例提供的实验二中虚拟链路实际带宽的示意图；

图18为本发明实施例提供的实验二中物理链路实际带宽与虚拟链路实际带宽的对比示意图。

具体实施方式

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

本发明实施例利用SDN实现网络虚拟化，可以充分利用SDN与网络虚拟化的优势。结合POF技术的优势，实现一种介于控制平面与转发平面之间，支持异构网络切片的软件定义网络虚拟化管理平台：POFVisor。POFVisor支持不同租户在同一物理资源上创建和管理多个虚拟网络，每个虚拟网络都可以灵活的自定义拓扑，且每个虚拟网络可以根据需求使用自定义协议。

本发明实施例提供的POFVisor介于控制平面与转发平面之间，即POFVisor相当于透明代理的作用。因此，虚拟网络与物理网络的映射、虚拟网络之间的流量隔离以及全局的流表规划是实现POFVisor的重点。

1)虚拟网络与物理网络的映射。

本发明实施例中，通过使用全局映射和消息代理结构可以实现虚拟网络与物理网络的映射。首先，利用全局映射结构可以实现虚拟网络中的各种组件与底层的物理网络中的各种组件的映射。其次，控制器下发给物理交换机或是物理交换机上报给控制器的消息可以通过消息代理结构实现消息改写，并发送给相对应的控制器或物理交换机。

2)虚拟网络之间的流量隔离。

实现POFVisor的另外一个关键点是确保虚拟网络之间流量隔离。流量隔离确保虚拟网络之间隔离，不会对彼此造成影响。POFVisor通过给分属于不同虚拟网络中的数据包打上与虚拟网络相关的标签的方式来区分数据包，从而实现不同虚拟网络之间的网络隔离。采用传统的VLAN、MPLS等打标签的方式将会造成这些字段被占用，租户无法使用这些字段。由于POF支持在数据包的任意位置添加字段。因此，通过在原有数据包的头部添加虚拟标签，标识数据包所属的虚拟网络，从而确保虚拟网络之间的流量隔离。虚拟标签如表1所示，虚拟标签的前N位为一个POFVisorTag，其作用是区别其它网络流量；中间的N位为TenantID，其作用是标识所属的虚拟网络；最后的N位为LinkID，其标识数据包传输所在的虚拟链路。作为举例，此处的N可以为16。

表1虚拟标签

3)全局的流表规划。

支持异构网络虚拟化要求每个虚拟网络可以对虚拟网络中的数据包按照其自定义协议进行处理，这样就会导致每个虚拟网络下发的流表可能完全不同。因此，合并各个虚拟网络的流表基本不可能。因此，需要采取合理的全局流表规划，从而将数据包导入其对应的虚拟网络下发的流表进行处理。全局的流表规划如图2所示，POFVisor中的流表分别两类：一类为租户下发的虚拟网络流表，由租户定义的规则所组成；另一类为分支流表，用于将数据包导入某个虚拟网络。其由两部分组成，一部分为边界流表项，另一部分为虚拟流表项。边界流表项用于识别相应虚拟网络的主机流量，而主机通过MAC地址识别，所以边界流表项匹配源MAC地址和数据包的进入端口。虚拟流表项区分虚拟网络中的流量，匹配数据包中的虚拟网络标签和数据包的进入端口。当数据包进入交换机后，首先匹配分支流表中的边界流表项，如果匹配中说明该数据包是来自于某个虚拟网络中的主机，匹配后通过指令跳转到相应虚拟网络下发的流表中。如果匹配不中，则接着匹配分支流表中的虚拟流表项，如果匹配中，则该数据包属于某个虚拟网络。将数据包头部的虚拟标签去掉，并且跳转到相应虚拟网络下发的虚拟网络流表中进行处理。

上述虚拟网络之间的流量隔离中所涉及的虚拟标签，以及全局流表规划中所涉及的各种流表均由消息代理模块实现；具体的将在后文介绍消息代理模块时做详细说明。

为了便于理解，下面从具体实现的角度来介绍POFVisor；如图1所示，其主要包括：物理网络管理模块、API模块、虚拟网络管理模块、全局映射模块、消息代理模块与日志模块。

本领域技术人员可以理解，图1中的控制器数量、虚拟网络数量、物理交换机数量，以及物理网络管理模块所维护的POF交换机实体对象数量仅为举例并非构成限制。

下面针对各个模块做详细介绍。

1、物理网络管理模块。

物理网络管理模块负责管理整个物理网络资源。其负责监听物理网络的资源变化并记录资源变化。具体包括在POFVisor中为每个底层的物理交换机都维护一个实体对象，该实体对象负责维护与底层的物理交换机的TCP连接，完成基本的握手过程。

物理网络管理模块与物理交换机的握手流程如图3所示。在握手阶段，物理交换机和物理网络管理模块之间通过Hello消息查看双方对应的协议版本是否相同；之后，物理网络管理模块向物理交换机下发Feature_request消息以请求物理交换机的基本信息，包括设备编号、端口数目、流表数目以及相应资源的状态；物理交换机通过Feature_reply消息回应物理网络管理模块的请求；物理网络管理模块获得物理交换机的基本信息之后，通过发送Set_config消息获取相应资源的具体信息；物理交换机收到物理网络管理模块的请求之后，发送相应的消息回应物理网络管理模块；在获取完整的物理交换机的信息之后，物理网络管理模块与物理交换机之间通过发送Echo消息以保持联系。此外，在此过程中，物理网络管理模块为底层的物理交换机下发用于将数据包导入相对应的虚拟网络流表的分支流表。

物理网络管理模块中的拓扑发现负责发现和维护底层物理交换机之间的连接状态。底层的物理交换机与物理网络管理模块完成握手过程之后，在平台中为每个底层的物理交换机都维护一个实体对象，该实体对象中包含一个拓扑发现组件，以处理从网络中接收到的链路层发现协议数据单元(Link Layer Discovery Protocol Date Unit，以下简称LLDPDU)或是向网络中发送LLDPDU。

图4表示了拓扑发现组件的整体行为。物理网络管理模块将底层物理交换机的端口分为两种类型，一种为快速端口，即成功接收LLDPDU的端口；另一种为慢速端口，即发送了最大数目的LLDPDU并且未被确认的端口，也就是说端口连接的为主机或者端口并不是链路的一部分。拓扑发现组件每隔一段时间就会让底层的物理交换机上的所有端口执行如图3所示的流程。当底层的物理交换机接收到LLDPDU时，通过PacketIn消息上报，物理网络管理模块调用该底层物理交换机对应的拓扑发现组件处理LLDPDU。根据PacketIn消息中记录的信息以及LLDPDU中记录的相关信息，实现拓扑发现，具体的流程如图5所示。

2、API模块。

所述API模块提供了创建完整的虚拟网络拓扑以及监视虚拟网络配置和状态信息的API。

API模块中定义了两种类型的API：切片API和监控API；其中，切片API用于创建和配置虚拟网络，监控API用于获取虚拟网络配置和状态信息；具体的切片API以及监控API的功能如表2和表3所示。

表2切片API功能

表3监控API功能

3、虚拟网络管理模块。

所述虚拟网络管理模块，用于根据API模块的调用实现虚拟网络的创建、配置及初始化；具体包括：

当收到租户下发的创建请求后，经API模块的调用，创建相应的虚拟网络；

在虚拟网络的配置过程中，虚拟网络管理模块为虚拟网络中的每个虚拟组件，创建虚拟组件实体并将其映射到底层的物理实体上，映射关系存放在全局映射中；所述的虚拟组件包括：虚拟交换机、虚拟端口与虚拟链路；

在虚拟网络的初始化过程中，虚拟网络管理模块让虚拟组件依次到达活跃状态，从而启动虚拟网络，虚拟网络的初始化过程如图6所示。

虚拟网络初始化之后，在配置过程中创建的虚拟交换机实体模拟物理交换机与控制器完成基本的握手过程并且保持TCP连接，让控制器以为连接上了相应的物理交换机。基本的握手过程与物理网络管理模块和物理交换机的握手过程类似。

虚拟网络管理模块的拓扑发现负责呈现虚拟网络的拓扑。对于每一个虚拟网络，POFVisor模拟了虚拟网络中LLDPDU广播、接收的过程。当接收到从控制器发出的包含LLDPDU的PacketOut，POFVisor选出控制器对应的虚拟网络来处理LLDPDU。处理的具体流程如图7所示。本发明实施例中，通过在虚拟网络中处理LLDPDU，能够显著的减少物理网络中的LLDPDU的数量。

4、全局映射模块。

全局映射模块用于存储虚拟交换机和物理交换机的映射信息、虚拟端口与物理端口的映射信息，以及虚拟链路和物理链路的映射信息。

本发明实施例中，由于消息代理模块既需要通过虚拟组件查找物理组件，也需要通过物理组件查找虚拟组件，因此整个映射信息是双向存储的。此外，全局的映射信息由多个线程所共享，每个线程都可能对其进行增删改查。因此，需要对全局映射信息进行同步。

5、消息代理模块。

在SDN中，交换机由控制器集中控制，控制器与交换机之间通过特定的协议消息进行通信。因此，介于控制平面与转发平面之间的虚拟化平台的最重要的功能便是实现消息代理模块。

本发明实施例中，消息代理模块的主要功能是拦截控制器与物理交换机之间的消息，其中包括控制器发给物理交换机的操作和查询指令与物理交换机上报给控制器的状态和事件信息，结合全局映射模块，从而对POF消息进行修改。

到目前为止，POF共定义了33个消息。其中最重要的消息为TableMod和FlowMod消息。TableMod消息用于生成流表，FlowMod用于生成流表项。除了TableMod和FlowMod消息之外，控制器用于直接发送数据包的PacketOut消息、物理交换机在遇到无法处理的数据包时上传的PacketIn消息，以及修改端口状态的PortMod消息也较为重要。除了消息之外，POF还定义了12种用于表间操作的指令(Instruction)；定义了11中用于在当前流表中操作的动作(Action)。除了握手阶段的消息外，消息代理模块需要对剩下的所有的消息、指令以及动作改写。下面将分别介绍TableMod、FlowMod、PortMod、PacketIn、PacketOutt的改写。

1)TableMod消息。

POF支持多表，不同流表之间通过表类型(TableType)、表编号(TableID)来区分。如果不对TableMod消息改写，那么当不同的虚拟网络下发具有相同TableType以及TableID的TableMod消息时，将会产生错误。因此，需要改写TableMod消息：根据TableType为TableMod重新分配新的TableID，并将对应关系存储在全局映射模块中；此外，当TableMod消息中包含的TableType为掩码匹配表(OF_MM_TABLE)时，平台为该表下发一条默认的PacketIn的流表项，目的是当数据包与该表中其他的流表项不匹配时，匹配该条表项，将消息上报给控制器。

2)FlowMod消息。

FlowMod消息的改写与TableMod类似，根据全局映射模块中的信息，对于消息中包含的TableID与CounterID进行改写，并对FlowMod消息包含的指令和动作进行相应的修改；改写这些指令和动作只需要调用这些指令和动作的改写操作即可。

3)PortMod消息。

PortMod消息通过设定openflowenable字段命令虚拟网络交换机端口是否开始按照POF模式处理数据包；对于控制器下发的PortMod消息，将其改写成分支流表中的表项：根据PortMod消息对应的端口的类型，如果是边界端口，则将PortMod消息转化为边界流表项，边界流表项匹配主机的MAC地址和对应的物理端口的端口号，然后通过GotoTable指令跳转到对应虚拟网络流表中；如果端口的类型是链路端口，则将PortMod消息转化为虚拟流表项，虚拟流表项匹配虚拟标签和对应物理端口的端口号，然后去掉数据包头部的虚拟标签，并通过GotoTable指令跳转到对应虚拟网络流表中。另外，PortMod消息由分支流表跳转到虚拟网络流表之前，需要修改元数据(MetaData)中存储的数据包进入的端口号。

4)PacketIn消息

PacketIn消息是当数据包未匹配中流表项，或者执行流表项中包含的PacketIn动作时，物理交换机将发送给控制器用于报告一个需要控制器处理的数据包信息；对于PacketIn消息的改写需要区分不同的场景：当PacketIn消息来自于分支流表，则平台向分支流表中下发流表项。其中，流表项的匹配项为源MAC以及数据包的进入端口，流表项中的动作为Drop；当PacketIn消息来自虚拟网络流表时，则在上报PacketIn消息时需要将对应的物理端口改写成虚拟端口；

5)PacketOut消息

PacketOut消息的作用是控制器控制物理交换机对数据包执行相应的动作并转发数据包，相应的动作存储在actionlist中；PacketOut消息的改写只需要修改actionlist中的所有动作，即调用对应动作的改写操作。

6、日志模块。

日志模块参与POFVisor运行的各个时期，用于记录POFVisor运行期间的数据，以及打印与POFVisor操作相关的日志信息；例如，相关的报错信息，以便于更加全面的了解POFVisor在每个时间点的运行状态。

以上为本发明实施例提供的POFVisor的全部组成及功能，其支持不同租户在同一物理资源上创建和管理多个虚拟网络，每个虚拟网络都可以灵活的自定义拓扑，且每个虚拟网络可以根据需求使用自定义协议，从而充分发挥SDN的可编程能力；同时，虚拟网络之间通过添加标签的方式隔离流量；通过引入分支流表和虚拟网络流表，进行全局的规划，使得数据包处理速率大幅提高。此外，POFVisor的引入不会对原有性能造成影响，对物理资源的利用率高。

下面再针对POFVisor的运行过程做详细介绍。POFVisor的运行过程分为四个阶段，分别为虚拟化平台初始化阶段、虚拟网络创建阶段、虚拟网络运行阶段以及虚拟网络销毁阶段。

在初始化阶段，各个模块初始化。物理网络管理模块首先监听6633端口。物理网络管理模块中维护的交换机实体对象与底层的物理交换机之间建立TCP连接，并且依照POF协议栈保持通信。在完成基本的握手阶段之后，物理交换机实体对象会通过TableMod消息发送用于虚拟化的分支流表。交换机实体对象通过控制对应物理交换机的所有端口定期发送LLDPDU数据包实现拓扑发现。在发现完整的底层物理拓扑后，虚拟化平台的初始化阶段完成。

在虚拟网络创建阶段，API模块接收并处理来自于租户的虚拟网络创建请求。租户可以使用API创建完整的虚拟网络拓扑。当租户远程调用createNetwork时，虚拟网络管理模块创建对应的虚拟网络实体。当租户远程调用createSwitch时，虚拟网络管理模块在对应的虚拟网络中添加虚拟交换机，并将虚拟交换机与物理交换机的映射关系存储在全局映射模块中。当租户远程调用createPort时，虚拟网络管理模块为指定的虚拟交换机添加虚拟端口，并将虚拟端口与物理端口的映射关系存储在全局映射模块中。当租户调用connectLink时，虚拟网络管理模块在指定的两个虚拟端口之间建立虚拟链路，并在物理拓扑上为该虚拟链路计算一条最短路径，然后将虚拟链路与该条最短路径的映射关系存储在全局映射模块中。当租户调用connectHost时，虚拟网络管理模块连接指定的虚拟交换机与终端主机，并在虚拟网络中记录终端主机的MAC地址。租户在创建完整的虚拟网络拓扑之后，虚拟网络创建阶段完成。

在虚拟网络运行阶段，租户调用startNetwork启动整个虚拟网络。根据虚拟网络创建阶段储存的映射信息，虚拟网络管理模块在物理网络上完成所有虚拟链路的初始化工作，即通过下发FlowMod消息，在物理交换机的分支流表中生成用于引导该虚拟网络流量的流表项。接着，虚拟网络管理模块在虚拟网络中所有的虚拟交换机与控制器之间建立连接，完成基本的POF协议栈握手阶段并下发控制器指定的规则，例如TableMod，FlowMod。此时控制器与底层物理交换机的所有POF消息都会通过消息代理模块进行改写。

在虚拟网络销毁阶段，租户调用removeNetwork销毁整个虚拟网络。首先，虚拟网络管理模块断开与控制器之间的连接。然后，根据全局映射模块中的信息，虚拟网络管理模块删除分支流表中的用于引导该虚拟网络流量的流表项，从而禁止整个虚拟网络的数据包进入网络，接着删除租户下发的所有流表。与此同时，全局映射模块删除并回收与该虚拟网络有关的所有资源信息，以便重复使用。在删除和回收虚拟网络在虚拟化平台和物理网络中的所有资源信息之后，虚拟网络销毁阶段完成。

另一方面，为了说明本发明实施例提供的POFVisor所具备的特性，下面结合两个实验进行说明。

实验一

本发明提出的POFVisor的最大特性是支持异构网络切片虚拟化。因此，结合实验一来验证POFVisor支持该特性。

实验的物理拓扑如图8所示，共有两台物理交换机(S1、S2)和四台终端主机(h1～h4)。启动POFVisor，POFVisor通过物理网络管理模块发现底层的物理拓扑，且API模块监听租户的调用请求。如图9和图10所示，租户通过调用API请求创建虚拟网络VN1和VN2，虚拟网络VN1和VN2的虚拟拓扑如图11所示。其中，虚拟网络VN1中运行的协议为IPV4，虚拟网络VN2中运行的协议为IPV6。具体的流表以及流表项由控制器1与控制器2下发，经由POFVisor的消息代理模块改写，下发到底层的物理交换机上。此时，通过ostinato在终端主机h1和终端主机h3对应端口构造并发送相应的数据包，在终端主机h2和终端主机h4通过wireshark抓取包，结果如图12和图13所示。从结果可以看出，在终端主机h3抓包只能抓取终端主机h1发出的数据包，在终端主机h4处抓包只能抓取到终端主机h2发出的数据包。因此，虚拟网络VN1与虚拟网络VN2能各自运行其自定义协议类型，并且虚拟网络VN1和虚拟网络VN2的流量隔离。

实验二

本发明提出的POFVisor对物理资源的利用率高，为了说明该特性同样进行了相关实验。

实验的物理拓扑如14所示：共有两台物理交换机(s1,s2)以及两台终端主机(h1,h2)，将物理交换机直连控制器，并用iperf测量物理交换机s1与物理交换机s2之间的实际带宽，结果如图15所示。

再使用本发明提供的POFVisor构造如图16所示的虚拟网络VN1，并用iperf测量虚拟网络VN1中的虚拟链路的实际带宽，结果如图17所示。

根据图15以及图17测量得到的结果，可以计算出物理链路实际的带宽为856.4Mb/s，虚拟链路实际的带宽为821Mb/s。因此虚拟链路的带宽使用率为95.8％，具体结果可参见图18，说明了对物理资源的利用率高的特性。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (9)

1.一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，包括：物理网络管理模块、API模块、虚拟网络管理模块、全局映射模块与消息代理模块；其中：

物理网络管理模块，负责管理整个平台的物理网络资源，在与底层的物理交换机完成基本的握手过程之后，其在平台中为每个底层的物理交换机都维护一个实体对象，每一实体对象负责维护与底层的相应物理交换机之间的TCP连接；

API模块，用于提供创建完整的虚拟网络拓扑以及监视虚拟网络配置和状态信息的API；

虚拟网络管理模块，用于根据API模块的调用实现虚拟网络的创建、配置及初始化，在虚拟网络初始化后，负责完成虚拟交换机与控制器基本的握手过程，并在两者之间建立TCP连接；

全局映射模块，用于存储虚拟交换机和物理交换机的映射信息、虚拟端口与物理端口的映射信息，以及虚拟链路和物理链路的映射信息；

消息代理模块，用于拦截控制器与物理交换机之间的消息，结合全局映射模块的信息对消息进行改写。

2.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，所述物理网络管理模块与物理交换机握手过程如下：

首先，物理交换机和物理网络管理模块之间通过Hello消息查看双方对应的协议版本是否相同；

随后，物理网络管理模块向物理交换机下发Feature_request消息以请求物理交换机的基本信息，包括设备编号、端口数目、流表数目以及相应资源的状态；物理交换机通过Feature_reply消息回应物理网络管理模块的请求；

物理网络管理模块获得物理交换机的基本信息之后，通过发送Set_config消息获取相应资源的具体信息；物理交换机收到物理网络管理模块的请求之后，发送相应的消息回应物理网络管理模块；

在获取完整的物理交换机的信息之后，物理网络管理模块与物理交换机之间通过发送Echo消息以保持联系。

3.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，每一实体对象中包含一个拓扑发现组件，以向网络中发送LLDPDU或是处理从网络中接收到的LLDPDU；

物理交换机的端口分为两种类型，一种为快速端口，即成功接收LLDPDU的端口；另一种为慢速端口，即发送了最大数目的LLDPDU并且未被确认的端口；

当物理交换机接收到LLDPDU时，通过PacketIn消息上报给物理网络管理模块，物理网络管理模块调用相应物理交换机对应的实体对象中的拓扑发现组件处理LLDPDU；根据PacketIn消息中记录的信息以及LLDPDU中记录的相关信息，实现拓扑发现。

4.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，所述API模块中定义了两种类型的API：切片API和监控API；其中，切片API用于创建和配置虚拟网络，监控API用于获取虚拟网络配置和状态信息。

5.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，所述虚拟网络管理模块，用于根据API模块的调用实现虚拟网络的创建、配置及初始化，具体包括：

当收到租户下发的创建请求后，经API模块的调用，创建相应的虚拟网络；

在虚拟网络的配置过程中，虚拟网络管理模块为虚拟网络中的每个虚拟组件创建虚拟组件实体并将其映射到底层的物理组件实体上，映射关系存放在全局映射模块中；所述的虚拟组件包括：虚拟交换机、虚拟端口与虚拟链路；

在虚拟网络的初始化过程中，虚拟网络管理模块依次让虚拟组件到达活跃状态，从而启动虚拟网络。

6.根据权利要求1或5所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，虚拟网络管理模块的拓扑发现负责呈现虚拟网络的拓扑；对于每一个虚拟网络，均模拟了网络中LLDPDU广播与接收的过程。

7.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，虚拟网络之间的流量隔离以及全局的流表规划均通过消息代理模块实现；具体如下：

虚拟网络之间的流量隔离：通过消息代理模块在相应数据包头部添加虚拟标签来标识数据包所属的虚拟网络，从而实现不同虚拟网络之间的流量隔离；虚拟标签的前N位为一个POFVisorTag，用于区别其它网络流量；中间的N位为TenantID，其作用是标识所属的虚拟网络；最后的N位为LinkID，其标识数据包传输所在的虚拟链路；

全局的流表规划：通过把数据包处理的入口流表设置为分支流表，进而将分属于不同虚拟网络的数据包导入相应的虚拟网络流表中处理；分支流表由两部分组成，一部分为边界流表项，用于识别相应虚拟网络的主机流量，由于主机通过MAC地址识别，因此边界流表项匹配源MAC地址和数据包的进入端口；另一部分为虚拟流表项，用于区分虚拟网络中的流量，该表项匹配数据包中的虚拟标签和数据包的进入端口；当数据包进入物理交换机后，首先匹配分支流表中的边界流表项，如果匹配中说明该数据包是来自于虚拟网络中的主机，匹配后通过指令跳转到相应虚拟网络流表中；如果未匹配中，则匹配分支流表中的虚拟流表项，如果匹配中，则该数据包属于某个虚拟网络，将数据包头部的虚拟标签去掉，然后跳转到相应虚拟网络流表中进行处理。

8.根据权利要求1或7所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，所述消息代理模块对消息改写的方式如下：

TableMod消息，用于生成流表；修改方式如下：根据TableType为TableMod重新分配新的TableID，并将对应关系存储在全局映射模块中；此外，当TableMod消息中包含的TableType为OF_MM_TABLE时，平台为生成的流表下发一条默认的PacketIn的流表项；

FlowMod消息，用于生成流表项；修改方式如下：根据全局映射模块中的信息，对消息中包含的TableID与CounterID进行改写，此外，还需要对FlowMod消息中包含的指令和动作进行相应的修改；

PortMod消息的作用是设定openflowenable字段命令虚拟网络交换机端口是否开始按照POF模式处理数据包；对于控制器下发的PortMod消息，将其改写成分支流表中的表项：根据PortMod消息对应的端口的类型，如果是边界端口，则将PortMod消息转化为边界流表项，边界流表项匹配主机的MAC地址和对应的物理端口的端口号，然后通过GotoTable指令跳转到对应虚拟网络流表中；如果端口的类型是链路端口，则将PortMod消息转化为虚拟流表项，虚拟流表项匹配虚拟标签和对应物理端口的端口号，然后去掉数据包头部的虚拟标签，并通过GotoTable指令跳转到对应虚拟网络流表中；

PacketIn消息是当数据包未匹配中流表项，或者执行流表项中包含的PacketIn动作时，物理交换机发送给控制器用于报告一个需要控制器处理的数据包信息；对于PacketIn消息的改写需要区分不同的场景：当PacketIn消息来自于分支流表，则平台向分支流表中下发流表项；其中，流表项的匹配项为源MAC以及数据包的进入端口，流表项中的动作为Drop；当PacketIn消息来虚拟网络流表时，则在上报PacketIn消息时需要将对应的物理端口改写成虚拟端口；

PacketOut消息的作用是控制器控制物理交换机对数据包执行相应的动作并转发数据包，相应的动作存储在actionlist中；PacketOut消息的改写需要修改actionlist中的所有动作，通过调用对应动作的改写操作完成。

9.根据权利要求1所述的一种支持协议无关的软件定义网络虚拟化管理平台，其特征在于，还包括：日志模块，用于记录平台运行期间的数据，以及打印与平台操作相关的日志信息。