本发明涉及sdn网络openflow交换机的流表(flowtable)配置的
技术领域：
：，具体是涉及一种基于openflow的二层业务配置系统及其方法。
背景技术：
：：软件定义网络(softwaredefinednetwork，简称为sdn)是一种新型的网络体系结构，通过将网络的控制平面和转发平面分离，将控制功能从网络节点中抽取出来，以可编程的方式控制网络行为，构建动态的、可控的网络体系结构。软件定义网络概念提出之后，作为sdn核心技术的openflow(开放流)技术发展迅速，openflow技术提供了转发平面和控制平面进行通讯的一种机制。openflow改变了传统的交换机或路由器控制的报文转发过程，在openflow网络中，控制器(controller)和openflow交换机(openflowswitch)共同完成转发过程。这样就实现了路由控制和数据转发的分离。这样做的好处是：把控制权从交换机或路由器中抽取出来，网络管理者可以借助自定义的策略，来控制网络中的数据流的走向及行为。控制平面与转发平面的解耦，可以带来很多优势。一方面，可以降低设备的复杂度，使设备更专注于转发，另一方面，可以给网络带来更大的灵活性和可控性。如图1所示：现有的openflow的数据包处理模型，主要由openflow交换机、openflow协议和控制器组成。数据包经过只有openflow交换机中流表匹配规则时才可以被openflow交换机转发，否则数据包将被openflow交换机丢弃。openflow将数据层和控制层进行了分离，openflow交换机实现转发功能，负责数据的转发，controller实现控制功能，对全局网络拓扑具有可见性和可控性，controller通过openflow协议对openflow交换机或路由器的流表进行编程控制，控制数据包的流向和网络行为，完成对整个网络进行集中控制的功能。openflow协议由国际标准组织开放网络基金会(opennetworkingfoundation，onf)制定，该协议描述了控制器和交换机交互时所使用的信息，并且规定了控制器和交换机交互的接口标准。openflow协议的核心部分是用于控制器和交换机交互的协议信息结构集合。openflow协议为openflow交换机和控制器通信提供开放的、标准化的接口。借助于openflow协议制定的的标准化接口，控制器可以响应交换机的请求，并且通过指令对交换机的flowtable进行编程，从而控制进入到交换机的数据包的流向以及网络行为。openflow交换机是整个openflow网络的核心部件，主要管理数据层的转发。控制器可以接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信时，所有的信息都是按照openflow协议规定的格式来执行。借助于ssl(securesocketslayer，安全套接层)机制，安全通道使交换机和控制器之间的指令和数据可以进行安全传输。如图2所示：现有的openflow网络拓扑模型，外部app安装在计算机上，在openflow网络中，处于控制层的控制器(controller)可以对网络交换设备的流表(flowtable)进行编程和管理。正是由于流表(flowtable)对远程访问控制的支持，可以将流表(flowtable)的配置与管理从网络交换设备本身中抽离出来，从而使得对整个网络中流表(flowtable)进行集中控制与管理成为可能，因此可将物理网络和逻辑网络的有效分离。技术实现要素：本发明的目的是为了克服上述
背景技术：
：的不足，提供一种基于openflow的二层业务配置系统及其方法。本发明基于openflow协议，将控制层面和转发层面分离，控制器实现控制功能，对流表进行编程和管理，方便对openflow交换机进行灵活的配置，以满足业务多样化的需求，openflow交换机只负责转发行为，极大降低了openflow交换机的负担，加快了报文转发速率。本发明提供一种基于openflow的二层业务配置系统，其特征在于：包括openflow交换机、外部app和控制器，openflow交换机、外部app均与控制器相连；openflow交换机用于：接收和解析控制器下发的流表配置，并进行数据包的转发；外部app用于：创建业务配置的源，向控制器发送业务配置信息；控制器用于：生成并维护虚拟的网络拓扑，接收外部app的请求，生成具体的业务流表配置，并通过openflow协议对openflow交换机进行配置和控制；所述openflow交换机包括安全通道和流表；安全通道提供连接openflow交换机和控制器的接口；流表为数据包转发提供依据；控制器通过openflow协议对流表进行编程控制和管理；所述控制器包括业务信息录入模块、业务信息解析模块、流表信息比对模块、流表信息下发模块；业务信息录入模块用于：发送外部app的业务配置信息，并将业务配置信息录入控制器；业务信息解析模块用于：解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息，然后将openflow流表信息与具体的业务绑定，并且在控制器内部进行存储；流表信息比对模块用于：openflow流表信息比对；若控制器内不存在相同openflow流表信息，则该openflow流表信息下发到openflow交换机；若控制器内存在相同openflow流表信息，则该openflow流表信息不下发到openflow交换机，该openflow流表信息存储在控制器内；流表信息下发模块用于：将需要下发的openflow流表信息通过安全通道下发至openflow交换机。在上述技术方案的基础上，所述业务信息录入模块具体用于：将业务配置信息以xml格式录入控制器；其中，业务配置信息包括业务的类型、业务名称、业务源宿交换机、业务源宿端口号、业务vlan、业务的操作管理维护oam和服务质量qos信息。在上述技术方案的基础上，所述业务信息解析模块具体用于：解析业务配置信息，生成控制器内部的业务模型，并为该业务计算一条或者多条标签交换路径lsp，根据计算结果填充控制器内部的业务对象，调用南向适配层，生成南向具体openflow流表信息。在上述技术方案的基础上，所述流表信息下发模块具体用于：将下发的openflow流表信息缓存起来，检测openflow流表信息的完整性，根据openflow多级流表下发方式调整openflow流表信息的下发顺序，使得openflow流表信息按照openflow流表信息的索引的序号从小到大依次下发。在上述技术方案的基础上，所述openflow协议包括openflow标准协议和openflow扩展协议，openflow标准协议支持二层业务的配置；openflow扩展协议支持后续扩展的业务配置。在上述技术方案的基础上，所述控制器通过流表获取openflow交换机对于流表能力的支持，包括支持流表类型以及最大支持流表数目，控制器根据支持流表类型以及最大支持流表数目对openflow交换机进行业务配置。本发明还提供一种基于openflow的二层业务配置方法，包括如下步骤：a、业务信息的录入：外部app向控制器发送业务配置信息，并将业务配置信息录入控制器；b、业务信息的解析：控制器解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息，然后将openflow流表信息与具体的业务绑定，并且在控制器内部进行存储；c、openflow流表信息比对：若控制器内不存在相同openflow流表信息，则该openflow流表信息下发到openflow交换机；若控制器内存在相同openflow流表信息，则该openflow流表信息不下发到openflow交换机，该openflow流表信息存储在控制器内；d、openflow流表信息下发：控制器将需要下发的openflow流表信息通过安全通道下发至openflow交换机。在上述技术方案的基础上，步骤a中，将业务配置信息录入控制器的具体过程为：外部app将业务配置信息以xml格式录入控制器；业务配置信息包括业务的类型、业务名称、业务源宿交换机、业务源宿端口号、业务vlan、业务的操作管理维护oam和服务质量qos信息。在上述技术方案的基础上，步骤b中，控制器解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息的具体过程为：控制器解析业务配置信息，生成控制器内部的业务模型，并为该业务计算一条或者多条标签交换路径lsp，根据计算结果填充控制器内部业务对象，调用南向适配层，生成南向具体openflow流表信息。在上述技术方案的基础上，步骤d中，控制器将需要下发的openflow流表信息通过安全通道下发至openflow交换机之前，还包括如下步骤：控制器将下发的openflow流表信息缓存起来，检测openflow流表信息的完整性，根据openflow多级流表方式调整openflow流表信息的下发顺序，使得openflow流表信息按照openflow流表信息的索引的序号从小到大依次下发。与现有技术相比，本发明的优点如下：本发明基于openflow协议，将控制层面和转发层面分离，控制器实现控制功能，包括基于全网拓扑进行路由计算，基于控制器标签池进行标签分配，openflow交换机只需负责转发行为，极大降低了openflow交换机的负担，加快了报文转发速率。同时，控制器实时获取全网设备状态，统一管理全网设备，可以方便高效地配置业务，并且对业务状态加以维护，保证业务质量。而且，对于支持标准openflow协议的设备有很好的通用性，并且可以基于openflow协议标准结构扩展特定的openflow流表，实现定制功能，比如流量监控管理。此外，本发明采用多级流表的下发方式，解决了单级流表表项臃肿、功能组合复杂度高的问题，多级流表可以根据不同的功能使用不同的流表组合下发，配置方式更加灵活。附图说明图1是现有的openflow的数据包处理模型。图2是现有的openflow网络拓扑模型。图3是本发明实施例基于openflow的二层业务配置方法的流程图。图4是本发明实施例uni_nni侧的流表配置示意图。图5是本发明实施例nni_uni侧的流表配置示意图。具体实施方式下面结合附图及具体实施例对本发明作进一步的详细描述。本发明实施例提供一种基于openflow的二层业务配置系统，包括openflow交换机、外部app和控制器，openflow交换机、外部app均与控制器相连；openflow交换机用于：接收和解析控制器下发的流表配置，并进行数据包的转发；外部app用于：创建业务配置的源，向控制器发送业务配置信息；控制器用于：生成并维护虚拟的网络拓扑，接收外部app的请求，生成具体的业务流表配置，并通过openflow协议对openflow交换机进行配置和控制；openflow交换机包括安全通道和流表；安全通道提供连接openflow交换机和控制器的接口；流表为数据包转发提供依据；控制器通过openflow协议对流表进行编程控制和管理；控制器包括业务信息录入模块、业务信息解析模块、流表信息比对模块、流表信息下发模块；业务信息录入模块用于：发送外部app的业务配置信息，并将业务配置信息录入控制器；业务信息解析模块用于：解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息，然后将openflow流表信息与具体的业务绑定，并且在控制器内部进行存储；流表信息比对模块用于：openflow流表信息比对；若控制器内不存在相同openflow流表信息，则该openflow流表信息下发到openflow交换机；若控制器内存在相同openflow流表信息，则该openflow流表信息不下发到openflow交换机，该openflow流表信息存储在控制器内；流表信息下发模块用于：将需要下发的openflow流表信息通过安全通道下发至openflow交换机。在本实施例中，业务信息录入模块具体用于：将业务配置信息以xml格式录入控制器；其中，业务配置信息包括业务的类型、业务名称、业务源宿交换机、业务源宿端口号、业务vlan、业务的操作管理维护oam和服务质量qos信息。业务信息解析模块具体用于：解析业务配置信息，生成控制器内部的业务模型，并为该业务计算一条或者多条标签交换路径lsp，根据计算结果填充控制器内部的业务对象，调用南向适配层，生成南向具体openflow流表信息。流表信息下发模块具体用于：将下发的openflow流表信息缓存起来，检测openflow流表信息的完整性，根据openflow多级流表下发方式调整openflow流表信息的下发顺序，使得openflow流表信息按照openflow流表信息的索引的序号从小到大依次下发。openflow协议包括openflow标准协议和openflow扩展协议，openflow标准协议支持二层业务的配置；openflow扩展协议支持后续扩展的业务配置。控制器通过流表形式获取openflow交换机对于流表能力的支持，包括支持流表类型以及最大支持流表数目，控制器根据支持流表类型以及最大支持流表数目对openflow交换机进行业务配置。在实际应用中，网络交换设备，无论是交换机还是路由器，其核心信息都保存在流表(flowtable)里面，这些流表(flowtable)可以实现数据转发、防火墙、qos(服务质量)、统计分析等各种功能。当数据包到达交换机时，会先在流表(flowtable)中进行查找，当匹配成功时，则执行相应操作，否则发送到控制器，根据控制器的响应执行相应动作。参见图3所示，本发明实施例还提供一种基于openflow的二层业务配置方法，包括如下步骤：s1、业务信息的录入：外部app向控制器发送业务配置信息，并将业务配置信息录入控制器；s2、业务信息的解析：控制器解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息，然后将openflow流表信息与具体的业务绑定，并且在控制器内部进行存储；s3、openflow流表信息比对：若控制器内不存在相同openflow流表信息，则该openflow流表信息下发到openflow交换机；若控制器内存在相同openflow流表信息，则该openflow流表信息不下发到openflow交换机，该openflow流表信息存储在控制器内；s4、openflow流表信息下发：控制器将需要下发的openflow流表信息通过安全通道下发至openflow交换机。其中，步骤s1中，将业务配置信息录入控制器的具体过程为：外部app将业务配置信息以xml格式录入控制器；业务配置信息包括业务的类型、业务名称、业务源宿交换机、业务源宿端口号、业务vlan、业务的操作管理维护oam和服务质量qos信息。xml格式文件信息主要是业务id，业务名称，端口所属交换机id，端口id，端口访问类型，业务vlan(虚拟局域网)以及qos(服务质量)信息等。业务出端口的配置与入端口类似。其中，步骤s2中，控制器解析业务配置信息，将业务配置信息转化为南向具体的openflow流表信息的具体过程为：控制器解析业务配置信息，生成控制器内部的业务模型，并为该业务计算一条或者多条标签交换路径lsp，根据计算结果填充控制器内部业务对象，调用南向适配层，生成南向具体openflow流表信息。在实际应用中，控制器根据外部app录入的信息，定位到唯一的交换机。在实现中，定义了属性的基类，所有属性的扩展都通过继承该基类与模型绑定，这种实现方式可以保证网络基本模型不变，在后期业务场景需添加其他属性时，保持原模型不变，只需扩展属性项即可。南向适配层通过查询具体模型的属性构造南向所需要的标准openflow流表。其中，步骤s3中，当业务是同属于二层以太网业务时，ingressportflowtable(入端口匹配流表)是复用的，控制器内部会维护一个该表关系的索引值(初始值为0)，每次创建业务后需要下发该表时，优先查询改表索引值(索引值为0才会下发该表至设备)，并且索引值加1。同时，删除操作时，索引值减1，当只有索引值为0时，表明设备上这个表没被引用了，才会下发删除操作至设备。其中，步骤s4中，控制器将需要下发的openflow流表信息通过安全通道下发至openflow交换机之前，还包括如下步骤：控制器将下发的openflow流表信息缓存起来，检测openflow流表信息的完整性。由于openflow交换机对于业务流表的顺序存在要求，只有在该表已经存在的情况下，才可以下发引用该表的其他流表。控制器会根据openflow多级流表(multi-levelflowtable)方式调整openflow流表信息的下发顺序，使得openflow流表信息按照openflow流表信息的索引的序号从小到大依次下发。此外，在下发业务后，控制器可通过安全通道获取接收设备openflow交换机创建业务后回复信息得知业务创建情况，并针对未下发成功的业务作删除操作，防止设备上有流表配置信息残留。业务配置方式是通过openflow多级流表方式下发，流表从序号小的到序号大的索引，每个流表分别对报文进行不同的操作，完成报文的匹配、封装和解析等操作，最终发送至指定的端口。参见图4所示，本发明实施例的uni_nni侧(用户侧到网络侧)的流表配置，只有成功创建了l2interfacegroup(二层接口组表)，才可以成功创建mplsinterfacegroup(多协议标签交换接口组表)。删除的时候则正好相反。其中，flowtable(流表)主要是作报文的匹配来区分报文，group(组表)主要是对符合flowtable(流表)匹配条件的报文作相应的操作。图中，ingressportflowtable(入端口流表)：匹配了报文类型，普通的以太网报文和oam(操作管理维护)报文处理分别走不同的流程。vlanflowtable(vlan流表)：基于vlan和端口进行普通的流分类。mplsl2portflowtable(多协议标签交换二层端口流表)：基于qos的简单流分类。mplstypeflowtable(多协议标签类型流表)：用于区分不同的mpls业务类型。mplsl2vpnlabelgroup(多协议标签二层虚拟专用网标签组表)：包括压入l2包头、压入控制字、压入pw(伪线)标签等，并且所引到mplstunnellabel1group。mplstunnellabel1group(多协议标签隧道标签组表)：压入lsp(标签交换路径)标签等，并索引到mplsinterfacegroup。mplsinterfacegroup(多协议标签接口组表)：包括设置源mac、目的mac和vlanid等动作，并索引到l2interface或者l2unfilteredinterfacegroup。l2interfacegroup/l2unfilteredinterfacegroup(二层接口组表)：l2interface和l2unfilteredinterfacegroup用于指定业务的出口，并配置其vlan(虚拟局域网)属性。其中，业务报文为普通的以太网报文，经过ingressportflowtable(入端口流表)匹配二层以太网报文类型(若业务为三层业务，该表不匹配，设备会丢弃该业务报文)后，指向了vlanflowtable(vlan流表)，该表匹配vlan、端口，区别于不同的业务场景，该表可以有以下匹配类型(匹配端口、匹配vlan、端口和vlan全匹配)，不符合匹配条件的报文将被设备丢弃，同时指向报文下一跳为mplsl2portflowtable(多协议标签交换二层端口流表)，这个表基于qos(服务质量)进行简单流分类，这个表action(操作)中会指定一个唯一的qosindex(服务质量角标)值，该qosindex值对应一种流分类的规则，设备通过该值可唯一索引到分类规则，完成流分类，在指定的下一跳mplstypeflowtable(多协议标签类型流表)完成业务类型匹配后，会执行group表mplsl2vpnlabelgroup(多协议标签二层虚拟专用网标签组表)中压入内层及外层标签，压入二层报文头等操作，最后将报文从指定端口送出，这里就完成了uni(用户侧接口)到nni(网络侧接口)的报文发送。在实际应用中，对于二层业务报文进行封装的操作，如果匹配上对应的配置信息，会在业务报文的外侧打上各种标签、报文头，从而把封装后的报文通过指定的端口发出，如果在其中的某张表匹配失败，则将对应的报文丢弃。参见图5所示，本发明实施例的nni_uni(网络侧到用户侧)流表配置。在接收端会存在相应的解包流程的配置，其中，terminationmacflowtable为mac终结流表。这一侧的配置区别于uni_nni(用户侧到网络侧)主要在于mpls1flowtable(多协议标签交换1表)和mpls2flowtable(多协议标签交换2表)这俩张流表，分别匹配了在uni_nni侧封装的外层标签和内层标签，并且在对应的流表中弹出对应的标签、二层报文头以及控制字的操作，最后还原成初始的业务报文从uni口送出。本领域的技术人员可以对本发明实施例进行各种修改和变型，倘若这些修改和变型在本发明权利要求及其等同技术的范围之内，则这些修改和变型也在本发明的保护范围之内。说明书中未详细描述的内容为本领域技术人员公知的现有技术。当前第1页12当前第1页12