CN108183861B - Sdn交换机获取精确流表项方法及sdn交换机、控制器、系统 - Google Patents

Abstract

本发明实施例公开了一种SDN交换机获取精确流表项的方法，应用于SDN网络，SDN网络包括SDN控制器以及多个SDN交换机，SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信，上述方法包括：第一SDN交换机先与SDN控制器建立可靠连接，然后基于可靠连接协议对应的包发送第一控制消息，在控制消息中加入自己的路径信息，后续每个收到第一控制消息的SDN交换机也都在第一控制消息中加入自己的路径信息，使得最后SDN控制器知道整个路径，从而将流表下发给第一SDN交换机。

Description

SDN交换机获取精确流表项方法及SDN交换机、控制器、系统

技术领域

本发明涉及通信技术领域，尤其涉及一种SDN交换机获取精确流表项方法、SDN交换机、SDN控制器及SDN系统。

背景技术

软件定义网络(Software Defined Network，SDN)是一种新型的网络架构，正在被越来越多地研究及应用，其中，现在的SDN最主要基于OpenFlow(开放流)协议来实现。在下文中，称基于OpenFlow协议的SDN网络为OpenFlow网络，OpenFlow网络包括开放流控制器(OpenFlow Controller，OFC)以及开放流交换机(OpenFlow Switch，OFS)。OFS会在本地维护一个流表(Flow Table)，流表中包括多个流表项，如果要转发的包在流表中有对应的流表项，则根据流表对包进行转发，如果流表中没有对应的流表项，则OFS会向OFC请求指令，OFC收到OFS请求后会给OFS下发流表的流表项，OFS得到下发的流表项后添加到流表项，从而根据新的流表对包进行转发。

OpenFlow网络中，OFS一般都需要获取初始流表(即OFS向OFC请求，OFC收到请求后下发流表项)，以使得该OFS能够转发包。现有技术中，一般采用控制面和数据面分离的方式来获取流表。

参见图1，为现有技术一种OpenFlow网络架构示意图，包括OFC，传统交换机，多个OFS(OFS1-OFS6)，其中，传统交换机，OFS1-OFS6以及OFC组成控制面；OFS1-OFS6以及OFC组成数据面。OFS首先在传统交换机的工作模式下，基于链路层发现协议(Link LayerDiscovery Protocol，LLDP)及生成树协议(Spanning Tree Protocol，STP)等协议打通控制面，也即通过STP等协议生成的转发表实现各种OpenFlow控制消息的转发，控制面打通后，OFC便可以通过该控制面向OFS下发初始的流表项，OFS收到流表项后将其添加到自己的流表中，从而获取初始流表。进而根据流表处理包，包的转发通过数据面进行。

现有技术中，控制面与数据面为两张不同的物理网，并且还需要一个或多个传统交换机，增大了硬件成本；同时，针对两张物理网还需要分别维护两个网络管理系统，也增大了维护成本。

发明内容

本发明实施例提供了软件定义网络SDN交换机获取精确流表项方法及对应的SDN交换机、SDN控制器以及SDN系统；本发明实施例还提供了SDN交换机转发包的方法及该方法对应的SDN交换机；最后，本发明实施例还提供了OFS收集路径信息的方法及与该方法对应的OFS。本发明实施例提供的SDN交换机获取精确流表项方法用于解决现有技术存在着的硬件成本以及维护成本高的问题。

在第一方面第一种实现方式中，本发明实施例公开了一种软件定义网络SDN交换机获取精确流表项方法，应用于第二SDN交换机，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信，所述方法包括

接收所述第一SDN交换机发送的用于收集路径信息的第一控制消息，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

将所述第二SDN交换机的路径信息添加到所述第一控制消息，得到更新后的第一控制消息；

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的第一控制消息的最终更新后的第一控制消息后，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第一方面第一种实现方式，第一方面第二种可能的实现方式中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包来建立。

结合第一方面第一种实现方式，第一方面第三种可能的实现方式中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令：

所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包包括：

所述第二SDN交换机接收来自所述第一SDN交换机的发送的第一TCP/IP包；

获取接收到的所述第一TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

将所述多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配不成功且判断收到所述第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理，以将所述第一TCP/IP包转发到所述SDN控制器，其中，所述第一类TCP握手消息为第一次TCP握手消息，或者第三次TCP握手消息。

结合第一方面第三种实现方式，第一方面第四种可能的实现方式中，所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包还包括：

所述第二SDN交换机接收来自所述SDN控制器的发送的第三TCP/IP包，所述第三TCP/IP包承载有第二次握手消息；

获取所述第三TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

将所述多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发，如果匹配失败且判断所述第三TCP/IP包承载的是所述第二次TCP握手消息时，则广播所述第三TCP/IP包。

结合第一方面第二种实现方式到第四种实现方式中的任一种实现方式，第一方面第五种可能的实现方式中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述接收所述第一SDN交换机发送的用于收集路径信息的第一控制消息；将所述第二SDN交换机的路径信息添加到所述第一控制消息，得到更新后的第一控制消息；将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器包括：

所述第二SDN交换机接收来自所述第一SDN交换机发送的承载有所述第一控制消息的第二TCP/IP包，所述第二TCP/IP包包括多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

所述第二SDN交换机根据所述第二TCP/IP包中的特征信息与精确流表进行精确匹配，当所述精确匹配不成功且判断收到的所述第二TCP/IP包中承载的是所述第一控制消息后，根据所述TCP/IP包中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则在所述第一控制消息中添加所述第二SDN交换机的路径信息，得到添加有所述第二SDN交换机的路径信息的更新后的第一控制消息，并将所述更新后的第一控制消息按照通配匹配成功的精确流表项中指令转发给所述SDN控制器。

结合第一方面第五种实现方式，第一方面第六种可能的实现方式中，如果通配匹配不成功，获取所述第二SDN交换机可用的输出端口，在所述第一控制消息中添加各个可用的输出端口对应的所述第二SDN交换机的路径信息，并从可用的输出端口将添加了各个可用的输出端口对应的所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器。

结合第一方面第三种到第六种任一实现方式，第一方面第七种可能的实现方式中，所述特征信息包括：目的MAC，目的IP以及目的端口号；所述精确流表的用于通配匹配的流表项中的匹配域为：目的MAC，目的IP以及目的端口号；所述将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理包括：

将所述多个特征信息中的目的MAC，目的IP以及目的端口号与流表项中的目的MAC，目的IP以及目的端口号相匹配，如果匹配成功，则按匹配成功的精确流表项中的指令对接收到的所述第一TCP/IP包进行处理。

结合第一方面第一种到第七种任一种实现方式，第一方面第八种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息；

所述将所述第二SDN交换机的路径信息添加到所述第一控制消息，得到更新后的第一控制消息包括：

将所述第二SDN交换机的路径信息添加到所述OFPT_HELLO消息中的用于承载所述路径信息的扩展后的body域，得到更新后的OFPT_HELLO消息；

所述将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的第一控制消息的最终更新后的第一控制消息后，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机包括：

将添加有所述第二SDN交换机的路径信息的所述更新后的OFPT_HELLO消息转发给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第一方面第一种到第八种任一种实现方式，第一方面第九种可能的实现方式中，所述将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器包括：

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息直接转发给所述SDN控制器，所述最终更新后的第一控制消息为所述更新后的第一控制消息；或者，

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息通过一个或多个其他SDN交换机间接转发给所述SDN，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

结合第一方面第一种到第九种任一种实现方式，第一方面第十种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述方法还包括：

接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有目的SDN交换机需要的多条精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的OFPT_FLOW_MOD消息时，提取所述OFPT_FLOW_MOD消息中携带的多条精确流表项后添加到本地精确流表中。

结合第一方面第一种到第九种任一种实现方式，第一方面第十一种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述方法还包括：

接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机使用一个或多个精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的所述OFPT_FLOW_MOD消息时，根据与自身对应的路径信息提取自身所需使用的一个或多个精确流表项，并将提取完后的OFPT_FLOW_MOD消息转发给下一个路由路径上的节点。

结合第一方面第一种到第十一种任一种实现方式，第一方面第十二种可能的实现方式中，所述路径信息包括：发送或收到所述第一控制消息的SDN交换机的ID，接收所述第一控制消息所用的端口号以及发送所述第一控制消息所用的端口号。

本发明实施例第二方面第一种实现形式公开了一种一种软件定义网络SDN交换机获取流表方法，应用于SDN控制器，所述SDN控制器与第二SDN交换机相连，所述第二SDN交换机与第一SDN交换机相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信，所述方法包括：

接收所述第二SDN交换机转发的最终更新后的第一控制消息，其中，所述最终更新后的第一控制消息包括更新后的第一控制消息，所述更新后的第一控制消息由所述第二SDN交换机在收到所述第一SDN交换机发送的用于收集路径信息的第一控制消息后，将所述第二SDN交换机的路径信息添加到所述第一控制消息后得到；其中，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

根据所述最终更新后的第一控制消息中携带的各个SDN交换机添加的路径信息获取所述SDN控制器自身与所述第一SDN交换机之间的路由路径；

根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第二方面第一种实现方式，第二方面第二种可能的实现方式中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包来建立。

结合第二方面第一种到第二种任一种实现方式，第二方面第三种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息。

结合第二方面第一种到第三种任一种实现方式，第二方面第四种可能的实现方式中，所述接收所述第二SDN交换机转发的最终更新后的第一控制消息包括：

直接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为所述更新后的第一控制消息；

或者，

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息通过一个或多个其他SDN交换机间接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

结合第二方面第一种到第四种任一种实现方式，第二方面第五种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述根据所述路由路径将精确流表项下发给所述第一SDN交换机包括：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入所述第一SDN交换机需要的多条精确流表项；

根据所述路由路径将所述OFPT_FLOW_MOD消息发送给所述第一SDN交换机，使得所述第一SDN交换机收到所述OFPT_FLOW_MOD消息后，提取所述OFPT_FLOW_MOD消息中携带的所述多条精确流表项后添加到本地精确流表中。

结合第二方面第一种到第五种任一种实现方式，第二方面第六种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述根据所述路由路径将精确流表项下发给所述第一SDN交换机包括：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机需要一个或多个精确流表项；

根据所述路由路径下发给所述其他SDN交换机，使得所述其他SDN交换机收到后根据路径信息以及所述OFPT_FLOW_MOD消息中的路径信息提取自身所需的精确流表项，并转发剩下的精确流表项，最终将所述第一SDN交换机所需的精确流表项转发给所述第一SDN交换机。

本明实施例第三方面第一种实现方式公开了一种软件定义网络SDN交换机，该SDN交换机为第二SDN交换机，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机相互之间通过带内通信的方式进行通信，所述第二SDN交换机包括：

连接建立单元，用于与所述第一SDN交换机以及所述SDN控制器之间进行消息交互，使得所述第一SDN交换机以及所述SDN控制器之间建立可靠连接；

第一接收单元，用于接收第一SDN交换机发送的用于收集路径信息的第一控制消息，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述可靠连接所使用的协议对应的包进行承载；

路径添加单元，将所述第二SDN交换机的路径信息添加到所述第一接收单元接收到的所述第一控制消息，得到更新后的第一控制消息；

转发单元，用于将所述路径添加单元添加了所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的第一控制消息的最终更新后的第一控制消息后，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第三方面第一种实现方式，第三方面第二种可能的实现方式中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包；

所述连接建立单元具体用于：转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包，从而使得所述第一SDN交换机与所述SDN控制器之间建立TCP连接。

结合第三方面第二种实现方式，第三方面第三种可能的实现方式中，所述第二SDN交换机包括精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述连接建立单元包括：

接收子单元，接收来自所述第一SDN交换机的发送的第一TCP/IP包；

特征信息获取子单元，获取所述接收子单元接收到的所述第一TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

第一匹配子单元，用于将所述特征信息获取子单元获取的所述第一TCP/IP包中的多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配不成功且判断收到所述第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理，以将所述第一TCP/IP包转发到所述SDN控制器，其中，所述第一类TCP握手消息为第一次TCP握手消息，或者第三次TCP握手消息。

结合第三方面第三种实现方式，第三方面第四种可能的实现方式中，所述接收子单元还用于：接收来自所述SDN控制器的发送的第三TCP/IP包，所述第三TCP/IP包承载有第二次握手消息；

所述特征信息获取子单元还用于：获取所述接收子单元接收到的所述第三TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

所述第一匹配子单元还用于：将所述特征信息获取子单元获取的所述第三TCP/IP包中的多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发，如果匹配失败且判断所述第三TCP/IP包承载的是所述第二次TCP握手消息时，则广播所述第三TCP/IP包。

结合第三方面第一种到第四种任一种实现方式，第三方面第五种可能的实现方式中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述第一接收单元具体用于：

接收来自所述第一SDN交换机发送的承载有所述第一控制消息的第二TCP/IP包，所述第二TCP/IP包包括多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

所述路径添加单元包括：

第二匹配子单元，用于根据所述第二接收子单元接收到的所述第二TCP/IP包中的特征信息与精确流表进行精确匹配，当所述精确匹配不成功且判断收到的所述第二TCP/IP包中承载的是所述第一控制消息后，根据所述TCP/IP包中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；

添加子单元，用于在所述第二匹配子单元通配匹配成功时，在所述第一控制消息中添加所述第二SDN交换机的路径信息，得到添加有所述第二SDN交换机的路径信息的更新后的第一控制消息；

所述转发单元包括第一转发子单元，用于将所述添加子单元处理后得到的所述更新后的第一控制消息按照通配匹配成功的精确流表项中指令转发给所述SDN控制器。

结合第三方面第五种可能的实现方法，第三方面第六种可能的实现方式中，所述添加子单元还用于，如果所述第二匹配子单元通配匹配不成功，获取所述第二SDN交换机可用的输出端口，在所述第一控制消息中添加各个可用的输出端口对应的所述第二SDN交换机的路径信息；

所述转发单元还包括第二转发子单元，用于从可用的输出端口将所述添加子单元添加了各个可用的输出端口对应的所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器。

结合第三方面第一种或第六种任一种实现方式，第三方面第七种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息；

所述第一接收单元具体用于通过所述连接建立单元建立的所述可靠连接接收第一SDN交换机发送的用于收集路径信息的OFPT_HELLO消息，所述OFPT_HELLO消息用于承载所述路径信息的扩展后的body域中携带有所述第一SDN交换机的路径信息；

所述路径添加单元具体用于将所述第二SDN交换机的路径信息添加到所述第一接收单元接收到的所述OFPT_HELLO消息中的用于承载所述路径信息的扩展后的body域，得到更新后的OFPT_HELLO消息；

所述转发单元具体用于将所述路径添加单元添加了所述第二SDN交换机的路径信息的所述更新后的OFPT_HELLO消息转发给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第三方面第一种到第七种任一种实现方式，第三方面第八种可能的实现方式中，所述转发单元具体用于：将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息直接转发给所述SDN控制器，所述最终更新后的第一控制消息为所述更新后的第一控制消息；或者，

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息通过一个或多个其他SDN交换机间接转发给所述SDN，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

结合第三方面第一种到第八种任一种实现方式，第三方面第九种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述SDN交换机还包括：

第二接收单元，用于接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有目的SDN交换机需要的多条的精确流表项；

第一流表项处理单元，用于当判断通过所述第二接收单元收到的消息为发送给所述第二SDN交换机自身的OFPT_FLOW_MOD消息时，提取所述OFPT_FLOW_MOD消息中携带的多条精确流表项后添加到本地精确流表中。

结合第三方面第一种到第八种任一种实现方式，第三方面第十种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述SDN交换机还包括：

第三接收单元，用于接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机使用一个或多个精确流表项；

第二流表项处理单元，用于当判断所述第三接收单元收到的消息为发送给所述第二SDN交换机自身的所述OFPT_FLOW_MOD消息时，根据与自身对应的路径信息提取自身所需使用的一个或多个精确流表项，并将提取完后的OFPT_FLOW_MOD消息转发给下一个路由路径上的节点。

结合第三方面第一种到第十种任一种实现方式，第三方面第十一种可能的实现方式中，所述路径信息包括：发送或收到所述第一控制消息的SDN交换机的ID，接收所述第一控制消息所用的端口号以及发送所述第一控制消息所用的端口号。

本发明实施例第四方面第一种实现方式公开了一种软件定义网络SDN控制器，所述SDN控制器与第二SDN交换机相连，所述第二SDN交换机与第一SDN交换机相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信，所述SDN控制器包括：

第一接收单元，用于接收所述第二SDN交换机转发的最终更新后的第一控制消息，其中，所述最终更新后的第一控制消息包括更新后的第一控制消息，所述更新后的第一控制消息由所述第二SDN交换机在收到所述第一SDN交换机发送的用于收集路径信息的第一控制消息后，将所述第二SDN交换机的路径信息添加到所述第一控制消息后得到；其中，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

路径获取单元，用于根据所述第一接收单元接收的所述最终更新后的第一控制消息中携带的各个SDN交换机添加的路径信息获取所述SDN控制器自身与所述第一SDN交换机之间的路由路径；

流表下发单元，用于通过所述路径获取单元获取的所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第四方面的第一种实现方式，第四方面第二种可能实现方式中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包来建立。

结合第四方面的第一种到第二种任一种实现方式，第四方面第三种可能实现方式中，所述SDN网络基于OpenFlow协议实现，所述第一控制消息包括OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息。

结合第四方面的第一种到第三种任一种实现方式，第四方面第四种可能实现方式中，所述第一接收单元具体用于：

直接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为所述更新后的第一控制消息；

或者，

通过一个或多个其他SDN交换机间接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

结合第四方面的第一种到第四种任一种实现方式，第四方面第五种可能实现方式中，所述SDN网络基于OpenFlow协议实现，所述流表下发单元具体用于：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入所述第一SDN交换机需要的精确流表项；

通过所述路由路径将所述OFPT_FLOW_MOD消息发送给所述第一SDN交换机，使得所述第一SDN交换机根据所述OFPT_FLOW_MOD消息获取精确流表项。

结合第四方面的第一种到第四种任一种实现方式，第四方面第六种可能实现方式中，所述流表下发单元具体用于：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入多个位于路由路径上的OFS需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机需要一个或多个精确流表项；

通过所述路由路径下发给所述其他SDN交换机，使得所述其他SDN交换机收到后根据路径信息以及所述OFPT_FLOW_MOD消息中的路径信息提取自身所需的精确流表项，并转发剩下的精确流表项，最终将所述第一SDN交换机所需的精确流表项转发给所述第一SDN交换机。

本发明实施例第五方面第一种实现方式公开了一种软件定义网络系统，包括：第一SDN交换机、第二SDN交换机以及SDN控制器，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信；

所述第一SDN交换机用于向所述第二SDN交换机发送用于收集路径信息的第一控制消息，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

所述第二SDN交换机用于接收所述第一控制消息，将所述第二SDN交换机的路径信息添加到所述第一控制消息，得到更新后的第一控制消息，并将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器；

所述SDN控制器用于接收所述第二SDN交换机发送的包括所述更新后的第一控制消息的最终更新后的第一控制消息，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

结合第五方面第一种实现方式，第五方面第二种可能的实现方式中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包来建立。

结合第五方面第二种实现方式，第五方面第三种可能的实现方式中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述第二SDN交换机具体用于接收来自所述第一SDN交换机的发送的第一TCP/IP包；获取接收到的所述第一TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；将所述多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配不成功且判断收到所述第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理，以将所述第一TCP/IP包转发到所述SDN控制器，其中，所述第一类TCP握手消息为第一次TCP握手消息，或者第三次TCP握手消息；以实现与所述第一SDN交换机、所述其他OFS以及所述SDN控制器之间进行用于可靠连接建立的消息交互，以建立所述可靠连接。

结合第五方面第二种到第三种任一种实现方式，第五方面第四种可能的实现方式中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述第二SDN交换机具体用于接收来自所述第一SDN交换机发送的承载有所述第一控制消息的第二TCP/IP包，所述第二TCP/IP包包括多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；根据所述第二TCP/IP包中的特征信息与精确流表进行精确匹配，当所述精确匹配不成功且判断收到的所述第二TCP/IP包中承载的是所述第一控制消息后，根据所述TCP/IP包中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则在所述第一控制消息中添加所述第二SDN交换机的路径信息，得到添加有所述第二SDN交换机的路径信息的更新后的第一控制消息，并将所述更新后的第一控制消息按照通配匹配成功的精确流表项中指令转发给所述SDN控制器。

结合第五方面第一种到第四种任一种实现方式，第五方面第五种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息。

结合第五方面第一种到第五种任一种实现方式，第五方面第六种可能的实现方式中，所述第二SDN交换机具体用于：

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息直接转发给所述SDN控制器，所述最终更新后的第一控制消息为所述更新后的第一控制消息；或者，

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息通过一个或多个其他SDN交换机间接转发给所述SDN，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

结合第五方面第一种到第六种任一种实现方式，第五方面第七种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第二SDN交换机还用于：

接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有目的SDN交换机需要的多条精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的OFPT_FLOW_MOD消息时，提取所述OFPT_FLOW_MOD消息中携带的多条精确流表项后添加到本地精确流表中。

结合第五方面第一种到第六种任一种实现方式，第五方面第八种可能的实现方式中，所述SDN网络基于OpenFlow协议实现，所述第二SDN交换机还用于：

接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机使用一个或多个精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的所述OFPT_FLOW_MOD消息时，根据与自身对应的路径信息提取自身所需使用的一个或多个精确流表项，并将提取完后的OFPT_FLOW_MOD消息转发给下一个路由路径上的节点。

结合第五方面第一种到第八种任一种实现方式，第五方面第九种可能的实现方式中，所述路径信息包括：发送或收到所述第一控制消息的SDN交换机的ID，接收所述第一控制消息所用的端口号以及发送所述第一控制消息所用的端口号。

本发明实施例第六方面第一种实现方式公开了一种软件定义网络SDN交换机转发包的方法，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括至少一个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，所述方法包括：

接收来自第一SDN交换机发送的包，所述包包括多个特征信息，其中，所述特征信息与所述精确流表项中的匹配域相对应；

获取所述包中的所述特征信息；

将所述特征信息与所述精确流表中的精确流表项进行精确匹配；如果精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则按通配匹配成功的精确流表项中的指令对所述包进行转发。

结合第六方面第一种实现方式，第六方面第二种可能的实现方式中，如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；

如果通配匹配不成功，则通过广播转发接收到的包。

结合第六方面第一种到第二种任一种实现方式，第六方面第三种可能的实现方式中：

所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

结合第六方面第一种到第三种任一种实现方式，第六方面第四种可能的实现方式中：

所述包为所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

本发明实施例第七方面第一种实现方式公开了一种软件定义网络SDN交换机，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，所述第二SDN交换机包括：

接收单元，用于接收来自第一SDN交换机发送的包，所述包包括一个或多个特征信息；

获取单元，用于获取所述接收单元接收的包中的所述特征信息；

精确匹配单元，用于将所述获取单元获取的所述一个或多个特征信息与所述精确流表中的精确流表项进行精确匹配，其中，所述一个或多个特征信息与所述精确流表中的所述精确流表项中的匹配域相对应；

通配匹配单元，用于如果所述精确匹配单元执行的精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；

转发单元，用于如果所述通配匹配单元执行的通配匹配成功，则按匹配成功的精确流表项中的指令对所述包进行转发。

结合第七方面第一种实现方式，第七方面第二种可能的实现方式中，所述匹配及转发单元还用于：

如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；

如果通配匹配不成功，则通过广播转发。

结合第七方面第一种到第二种任一种实现方式，第七方面第三种可能的实现方式中，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

结合第七方面第一种到第三种任一种实现方式，第七方面第四种可能的实现方式中，所述包为所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

本发明实施例第八方面第一种实现方式公开了一种开放流交换机OpenFlowSwitch，OFS收集路径信息的方法，应用于第二OFS，所述第二OFS与第一OFS，开放流控制器OpenFlow Controller，OFC相连，形成OpenFlow网络，其中，所述OFC与各个OFS之间通过带内通信的方式进行通信，所述方法包括：

接收第一OFS发送的用于收集路径信息的OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息，所述OFPT_HELLO消息承载有所述第一OFS的路径信息，所述OFPT_HELLO消息通过所述第一OFS与所述OFC之间建立的可靠连接所使用的协议对应的包进行承载；

添加所述第二OFS路径信息到所述OFPT_HELLO消息，得到更新后的OFPT_HELLO消息；

将所述更新后的OFPT_HELLO消息转发给所述OFC，使得所述OFC收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各OFS添加的路径信息确定自身与所述第一OFS之间的路由路径并根据所述路由路径将精确流表项下发给所述第一OFS。

结合第八方面第一种实现方式，第八方面第二种实现方式中，所述路径信息包括：发送或收到所述OFPT_HELLO消息的OFS的ID，接收所述OFPT_HELLO消息所用的端口号以及发送所述OFPT_HELLO消息所用的端口号。

结合第八方面第一种到第二种任一种实现方式，第八方面第三种实现方式中，所述将所述更新后的OFPT_HELLO消息转发给所述OFC包括：

将所述更新后的OFPT_HELLO消息直接转发给所述OFC，所述最终更新后的OFPT_HELLO消息为所述更新后的OFPT_HELLO消息；或者，

将所述更新后的OFPT_HELLO消息通过一个或多个其他OFS间接转发给所述OFC，其中，所述其他OFS在收到的所述更新后的OFPT_HELLO消息中添加路径信息，得到所述最终更新后的OFPT_HELLO消息。

本发明实施例第九方面第一种实现方式公开了一种开放流交换机OpenFlowSwitch，OFS，该OFS为第二OFS，所述第二OFS与第一OFS，开放流控制器OpenFlowController，OFC，以及至少一个其他OFS相连，形成OpenFlow网络，其中，所述OFC与各个OFS之间通过带内通信的方式进行通信，所述第二OFS包括：

接收单元，用于接收第一OFS发送的用于收集路径信息的OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息，所述OFPT_HELLO消息承载有所述第一OFS的路径信息，所述OFPT_HELLO消息通过所述第一OFS与所述OFC之间建立的可靠连接所使用的协议对应的包进行承载；

路径信息添加单元，添加所述第二OFS路径信息到所述接收单元接收到的所述OFPT_HELLO消息，得到更新后的OFPT_HELLO消息；

转发单元，用于将通过所述路径信息添加单元添加了第二OFS路径信息的所述更新后的OFPT_HELLO消息转发给所述OFC，使得所述OFC收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各OFS添加的路径信息确定自身与所述第一OFS之间的路由路径并根据所述路由路径将精确流表项下发给所述第一OFS。

结合第九方面第一种实现方式，第九方面第二种实现方式中，所述路径信息包括：发送或收到所述OFPT_HELLO消息的OFS的ID，接收所述OFPT_HELLO消息所用的端口号以及发送所述OFPT_HELLO消息所用的端口号。

结合第九方面第一种到第二种任一种实现方式，第九方面第三种实现方式中，所述转发单元具体用于：

将所述更新后的OFPT_HELLO消息直接转发给所述OFC，所述最终更新后的OFPT_HELLO消息为所述更新后的OFPT_HELLO消息；或者，

将所述更新后的OFPT_HELLO消息通过一个或多个其他OFS间接转发给所述OFC，其中，所述其他OFS在收到的所述更新后的OFPT_HELLO消息中添加路径信息，得到所述最终更新后的OFPT_HELLO消息。

本发明实施例SDN交换机获取精确流表项的方法中，SDN控制器与各SDN交换机之间使用带内的方式进行通信，并通过先建立可靠连接，再基于建立的可靠连接传递携带各SDN交换机自身路径信息的控制消息，使得SDN控制器能够根据接收到的控制消息携带的各SDN交换机的路径信息确定自身与第一SDN交换机之间的路由路径，并根据该路径下发精确流表项给第一SDN交换机。通过上述方式，并不需要维护两张物理网，从而节省了硬件成本以及维护成本。

附图说明

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

图1为现有技术中OpenFlow网络架构示意图；

图2为本发明实施例一提供的一种OFS获取精确流表项的方法的流程图；

图3为本发明实施例二提供的第二OFS处理第一类TCP握手消息的流程示意图；

图4为本发明实施例二提供的流表示意图；

图5为本发明实施例三提供的OFS处理第一次TCP握手消息简要示意图；

图6为本发明实施例三提供的OFS处理第一次TCP握手消息的流程图；

图7为本发明实施例三提供的承载第一次TCP握手消息的包的包头中的几个字段示意图；

图8为本发明实施例三提供的第二OFS转发第一次TCP握手消息的包进行转发的示意图；

图9为本发明实施例三提供的承载第二次TCP握手消息的包的包头中的几个字段示意图；

图10为本发明实施例三提供的OFS处理第二次TCP握手消息简要示意图；

图11为本发明实施例三提供的OFS处理第二次TCP握手消息的流程图；

图12为本发明实施例三提供的承载第三次TCP握手消息的包的包头中的几个字段示意图；

图13为本发明实施例三OFS处理第三次TCP握手消息的简要示意图；

图14为本发明实施例三OFS处理第三次TCP握手消息的流程图；

图15为本发明实施例四提供的在OPFT_HELLO消息body域扩展路径信息的示意图；

图16为本发明实施例四提供的OFS处理OPFT_HELLO消息的流程图；

图17本发明实施例四提供的OPFT_HELLO消息在各OFS传递的示意图；

图18本发明实施例四提供的OPFT_HELLO消息在各OFS传递的另一示意图；

图19为本发明实施例五提供的OFS流表项示意图；

图20为本发明实施例五提供的OFC收到Hello消息后下发流表项的流程图；

图21为本发明实施例五提供的OFS收到OFC下发的流表项后处理流程图；

图22为本发明实施例六提供的一种OFS硬件结构图；

图23为本发明实施例六提供的一种用软件器件实现OFS的示意图；

图24为本发明实施例七提供的一种SDN交换机结构示意图；

图25为本发明实施例七提供的SDN交换机中的连接建立单元结构示意图；

图26为本发明实施例七提供的SDN交换机中的路径添加单元结构示意图；

图27为本发明实施例七提供的SDN交换机中的转发单元结构示意图；

图28为本发明实施例八提供的一种SDN控制器结构示意图；

图29为本发明实施例九提供的一种SDN系统结构示意图；

图30为本发明实施例十提供的一种SDN交换机转发包方法流程示意图；

图31为本发明实施例十一提供的一种SDN交换机结构示意图；

图32为本发明实施例十二提供的一种OFS收集路径信息方法流程示意图；

图33为本发明实施例十三提供的一种OFS结构示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下将通过具体实施例和相关附图，对本发明作进一步详细说明。

实施例一

本发明实施例一提供了一种SDN交换机获取精确流表项的方法，本实施例中SDN网络架构可以基于现在应用最广泛的OpenFlow技术实现，也可以采用其他的技术来实现，这里并不限定。本实施例中，SDN网络架构跟OpenFlow网络架构一样，也包括一个或多个SDN交换机以及一个或多个SDN控制器，这些SDN交换机以及SDN控制器可以使用OpenFlow协议或者其他协议进行通信，如果使用OpenFlow协议，则SDN交换机可称为OpenFlow交换机，简称OFS，SDN控制器可称为OpenFlow控制器，使用其他协议时也类似。

本实施例及以下各实施例中，主要基于由OFS以及OFC构成的OpenFlow网络对本方案进行具体介绍，本领域技术人员可以将SDN控制器等同成OFC，将SDN交换机等同成OFS。当然，本发明各实施例中基于OpenFlow网络的相关方案也同样适用于其他类似协议实现的SDN网络。

本实施例中，SDN网络中并不需要传统交换机，并且，控制面以及数据面都基于同一个物理网，例如，基于OpenFlow网络实现时，OFS中的一个物理端口既用于收发控制包，也用于收发包。本实施例及以下各实施例中，“控制面”的概念与现有技术中“控制面”的概念类似，即一些相关节点(如OFC以及各OFS)以及这些节点之间的链路组成一个用于传输控制消息的网络平面，通过相互之间的控制消息的交互，让OFS获取由OFC下发的流表项，只不过相比于现有技术，并不需要传统交换机来完成。“数据面”的概念也与背景技术中提到的类似，即一些相关节点(OFC以及各OFS)以及这些节点之间的链路组成一个用于传输数据信息的网络平面，当各个OFS收到OFC下发的流表项后，OFS根据流表项对接收的包进行转发。上述这种基于同一个物理网进行通信的方式在可称为“带内通信”。

本实施例一种获取流表下发方法应用于第二SDN交换机，即由第二SDN交换机来执行，“第二SDN交换机”是指转发第一SDN交换机(即发起流表获取请求的SDN交换机)控制消息到SDN控制器的SDN交换机，这里的转发包括直接转发以及间接转发，因此，当网络中存在多个用于转发第一SDN交换机控制消息的SDN交换机时，这些SDN交换机中的每一个都可以认为是“第二SDN交换机”，本实施中，基于其中某一个第二SDN交换机来描述，可以理解，其他第二SDN交换机的处理流程也与本实施例中的举例的第二SDN交换机类似，本实施例不再针对各个SDN交换机进行一一描述。在本实施例中，SDN控制器与各个SDN交换机之间通过“带内通信”的方式进行通信。

具体的，参见图2，本实施例一种SDN交换机获取流表项的方法包括：

S101、接收第一SDN交换机发送的用于收集路径信息的第一控制消息，第一控制消息中携带有第一SDN交换机的路径信息，第一控制信息通过第一SDN交换机与SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

以SDN网络为OpenFlow网络为例，可靠连接在第一OFS中通过一个或多个中间OFS与OFC之间进行用于可靠连接建立的消息交互后被建立。其中，本实施例中，各个OFS都可以作为中继节点，以将一个消息从一个节点(如第一OFS)传递到另一个节点(如OFC)。

本实施例中，“可靠连接”指为了保证通信可靠性而建立的连接，一般“可靠连接”都会有确认重传机制，例如，TCP连接(使用TCP协议建立的连接)视为典型的可靠连接，而UDP可视为“非可靠连接”。本实施例中，可以使用TCP连接，或者SCTP连接(使用SCTP协议的连接)作为可靠连接，或者在这些协议的基础上再加上UDP，SSH等协议来进行，如TCP加上SSH，或者TCP加上UDP。

本实施例中，“路径信息”为OFS节点用于标识自己在网络中路径的信息，通常使用OFS的端口号作为“路径信息”，网络中的路径是指包从一个节点(可以是OFS或OFC)的某个端口到发往另一个节点的某个端口的传输链路，本实施及以下各实施例中，路径都是双向的，即包传输时来回的通路都使用同一条路径，例如，OFS1从自己的11号端口向OFS3的33端口发送了一个包，则OFS3需要向OFS1发送包时，也使用33端口向OFS1的11端口发包。路径信息中也会携带OFS的ID，以标识是哪个OFS的端口号。

需要说明的是，本实施例中，OFS的端口(port)是指物理端口，并非协议端口(也称“软件端口”，例如针对HTTP应用定义的80端口)。在OpenFlow技术领域以及互联网技术领域中，端口(port)既可以指物理端口，也可以指软件端口，本领域技术人员可以根据上下文知道端口的实际含义，例如，参见图4，在OFS流表项中instruction字段中出现的端口号为物理端口号；而IP Port字段中的端口号表示的为协议端口号。本实施例及以下各实施例中，为了兼顾本领域技术人员的对端口的用法以及方便说明，不并针对每个端口一一指出其所表达的为“物理端口”或者“协议端口”，本领域技术人员结合上下文可以很容易知道“端口”为哪种类型的端口。

本实施例中，可以扩展一些OpenFlow协议中定义的控制消息(这里命名为“第一控制信息”)来完成路径信息的收集，例如，第一控制信息可以是OFPT_HELLO消息。具体的，可对OFPT_HELLO消息的body域进行扩展，从而用于承载路径信息。如果基于其他协议实现时，也可以采用扩展现有协议这种类似的方法，或者在协议中定义一些新的字段以实现扩展。

S102、添加第二SDN交换机的路径信息到第一控制消息，得到更新后的第一控制消息；

与步骤S101中的路径信息中的内容相似，以SDN网络为OpenFlow网络为例，这里的路径信息包括第二OFS的ID以及端口号。本步骤在第一控制消息中已经有第一OFS路径信息的基础上，再在第一控制消息中添加路径信息，得到更新后的第一控制消息。执行本步骤后，第一控制消息中又增加了中间节点的路径信息，此时，就知道第一OFS是从哪个端口发送了第一控制消息以及OFS从哪个端口接收到了第一控制消息，第一OFS以及第二OFS之间的路径就可以知道了。

需要说明的是，本实施例中，“第一控制消息”为第一OFS发往OFC的OpenFlow协议的控制消息，例如下文会提到的OPFT_HELLO消息。当然，用其他协议实现SDN网络时，也可以是基于其他协议的控制消息。第一控制消息的定义主要由其头部信息决定，在消息的其他部分内容发生变化时(例如经过第二OFS时消息的一些域当中可以增加第二OFS的路径消息)，本实施例中仍称其为“第一控制消息”，或者，更准确地说，是“更新后的第一控制消息”，如无对“第一控制消息”的特殊说明，本领域技术人员可以结合上下文明白第一控制消息的含义(第一OFS一开始发的第一控制消息，或者经过各个OFS后添加了新的路径信息后的第一控制消息)。

S103、将添加有第二SDN交换机的路径信息的更新后的第一控制消息转发给SDN控制器，使得SDN控制器收到包括更新后的第一控制消息的最终更新后的第一控制消息后，根据最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与第一SDN交换机之间的路由路径并根据路由路径将精确流表项下发给第一SDN交换机。

本步骤中，转发分直接转发以及间接转发两种，与之对应的，最终更新后的第一控制消息也会不同。

还是以SDN网络为OFS网络为例，如果是直接转发(即第二OFS直接转发到OFC，中间不经过任何一个OFS)，则最终更新后的第一控制消息为更新后的第一控制消息；如果是间接转发(即第二OFS通过一个或多个其他OFS后将第一控制消息转发到OFC)，则每个其他OFS在收到前面一个OFS发送的第一控制消息后，都会添加自己的路径信息，从而不断更新第一控制消息，最终到达OFC的是包含了所有OFS路径信息的第一控制消息。

其他OFS添加路径信息跟第二OFS添加路径信息方式相同，即也可以将自身的ID及端口号添加到第一控制消息中，得到最终更新后的第一控制消息。由于每个OFC都添加了自身路径信息，OFC就可以根据第一控制消息里面的路径信息知道第一OFS中间连着哪些OFS，使用哪些端口发送消息，从而可以获取路由路径(即第一OFS发送的第一控制消息经过哪些中间OFS后最终到达OFC的路径)，并通过该路由路径将流表项下发给第一OFS(实际应用中，也可以基于该路由路径给其他相关的OFS下发流表，具体可参见下面的实施五)。

第一OFS收到流表项后，添加到本地流表，后续可根据流表中的各个流表项对收到的包进行转发。实际应用中，各个OFS(或SDN交换机)为对等的关系，其他OFS也可以像本实施例中的第一OFS一样获取流表项，第一OFS也可以像本实施例中的“第二OFS”、“其他OFS”一样作为中间OFS转发各种消息。

此外，本步骤转发的第一控制消息也是承载在基于相应协议(如TCP/IP协议)的包中的，其中也会涉及到一些封装包的流程，这些都属于现有技术，这里并不对这些具体实现进行详细说明。

本实施例并不需要一个或多个传统交换机就能够完成流表项的下发，从而节省了成本。此外，本实施例中，由于数据面、控制面都可以于同一物理网，因此，相比于现有技术节省了一个物理网，更加降低了硬件成本，同时，本实施例并不需要针对两套物理网分别维护两个网络管理系统，也降低了维护成本。

实施例二

基于上述实施例，以SDN网络为OpenFlow网络为例，本实施例对建立可靠连接的方法进行进一步地描述。实施例一中已经介绍，建立可靠连接的方法可以基于TCP或SCTP等协议来建立，本实施将基于现在广泛使用的TCP来进行进一步说明，可以理解的是，通过本实施例，本领域技术人员也可以使用其他类似的协议(如SCTP)来实现。

本实施例中，TCP握手消息交互基本流程同现有技术一样，需要完成三次握手(three-way handshake)，即源节点向目的节点发送SYN消息(第一次握手)，目的节点收到后向源节点回应一个SYN-ACK消息(也可用“SYN+ACK”表示，即第二次握手)，源节点再向目的节点发送ACK消息(第三次握手)，从而完成TCP三次握手。相应的，SYN消息，SYN-ACK消息以及ACK消息可以分别被称为“第一次握手消息”、“第二次握手消息”以及“第三次握手消息”，各个消息的都是以包的形式(如TCP/IP包)进行承载，这些技术为本领域技术人员所公知的技术，这里不再赘述。

由于本实施例OpenFlow网络中，在第一OFS与OFC之间可能会存在一个或多个OFS，因此，绝大多数情况下，第一OFS不能直接与OFC进行交互，而需要通过第二OFS，以及一个或至少一个其他OFS作为接力节点传递交互消息。

为了让这些接力节点能够传递交互消息，一种方法是第一OFS向所有跟它相连的OFS广播TCP握手消息，每个收到消息的OFS也向其他的OFS广播，最后将TCP握手消息传递到OFC；同时，OFC收到后先向所有连接OFS广播TCP握手消息，每个OFS收到OFC的响应消息后也广播该消息，最终将TCP握手消息传递到第一OFS，从而可以完成三次TCP握手消息交互。

广播占用的网络资源比较大，而且有可能会引起广播风暴，因此，为了更好地利用网络资源，减小广播风暴的产生，本实施例针对第一OFS与OFC之间的OFS提供了一种新的转发TCP握手消息的方法，以第二OFS接收到第一OFS发送的第一类TCP握手消息(第一次TCP握手消息以及第三次TCP握手消息)，并通过其他OFS将第一类TCP握手消息转发给OFC为例，参见图3，该方法包括：

S21、第二OFS接收来自第一OFS发送的TCP/IP包；

可以是直接接收(中间无其他OFS)，或者间接接收(通过多个OFS后收到来自第一OFS的第一TCP/IP包)，由于本实施基于TCP/IP，因此，各种消息都通过TCP/IP包来承载；

S22、获取TCP/IP包中的多个特征信息，其中，特征信息与第二OFS中的流表的流表项中的匹配域相对应；

OpenFlow网络中的OFS中都会有用于转发的流表，流表可以包括一个或多个流表项(flow entry，或者简称entry)，每个流表项包括一个或多个匹配域(match field，下文也简称“域”)，具体的可以包括目的MAC，源MAC，源IP，目的IP，TCP端口号等匹配域；同时，流表项中还会有与流表项对应的指令(instruction)，例如，通过哪个端口转发。当收到的包(用于承载各种消息)符合流表匹配策略时，根据流表项中指令对包进行转发。

参见图4，为流表的示意图，其中，该流表包含精确流表项以及通配流表项，无论哪个流表项，都包括匹配域(如目的MAC、目的IP)以及与这些匹配域对应的指令(instructions)，需要说明的是，流表项中，除了“匹配域”以及“指令”外，也可以包括其他项(例如计数器counters，用于统计流表项被命中的次数)，匹配域本身除了图中所示的几个匹配域外，也可以包括其他的匹配域，本实施例为了说明方便，并未全部列出所有其他的信息。

精确流表项以及通配流表项的区别在于，精确流表项中，每个匹配域都有精确的值，只有跟这个匹配域相等的值才认为是跟这个匹配域匹配；而在通配流表项中，有些匹配域的值并不限定(在图4中用符号“*”表示)，任何值都可以认为与该匹配域相匹配。

图4当中是一个流表有多个流表项，在另一实施例中，也可以将流表划分成“精确流表”以及“通配流表”两个流表，精确流表只包括精确流表项，通配流表只包含通配流表项；或者在其他实施例中，还可以有其他的逻辑划分形式，这里并不限定。

同时，本实施例并不限定“流表”的在物理存储层面上的具体实现方式，例如，可以将一个或多个流表中的内容按一定顺序存储在一块连续物理空间，或者存放在几块物理空间等。物理空间既可以是一些硬件器件(如FPGA)内部自带的存储空间，也可以是通用的内存的空间，具体可以使用SDRAM，DDR SDRAM，flash等作为物理空间的存储介质；在进行流表匹配时，可以基于硬件器件来匹配，或者也可以使用软件(通过CPU执行软件程序)来匹配。

需要说明的是，本方案各实施例中，为了说明方便，如无特殊说明，流表都是指的精确流表，即只含精确流表项的流表。通配流表的使用方法可以参考现有的处理方案，这里并不关注，图4中所示出的通配流表项仅仅用于更清楚地对流表进行说明，以便更好地区别下文中会提到的“通配匹配精确流表”的概念。

本步骤中，收到的TCP/IP包中会有多个与流表项中一些匹配域对应的特征信息(如目的MAC、目的IP等等)，这些特征信息被封装在包中(如在包头部)，OFS收到包，通过解析包就可以获取这些特征信息。

S23、将多个特征信息与第二OFS中的精确流表进行精确匹配，如果精确匹配不成功且判断收到第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与精确流表进行通配匹配，如果通配匹配成功，则按匹配成功的通配匹配项中的指令对接收到的承载了第一类TCP握手消息的第一TCP/IP包进行处理，以直接或间接将第一TCP/IP包转发到OFC。

本实施例流表匹配(这里再次强调，如无特殊说明，流表指的是精确流表)可以包括两种情况，一种是现有技术采用的精确匹配(exact-match)，即将需要匹配的内容与匹配流表项中的每个匹配域都进行匹配，每个匹配域都匹配上了，才认为匹配成功；另一种是通配匹配(wildcard-match)，需要匹配内容与匹配流表中的一个或多个匹配域匹配上了即可认为通配匹配成功，并不需要像精确匹配一样每个匹配域都要匹配上。需要强调的是，这里的“通配匹配”并非是指基于图4中的通配流表项进行通配匹配，而是基于精确流表项进行通配匹配。

为了照顾速度，兼顾灵活性，本实施中，可以使用硬件来实现精确匹配，使用软件来实现通配匹配。在软硬件结合的系统中，CPU可以通过一个接口与硬件器件进行交互，实现流表的共享，从而实现软硬件的流表匹配。流表共享的方式可以有多种，例如软件需要匹配时通过接口去硬件存储器获取一份拷贝，或者硬件更新流表时，通过接口向软件发送一份拷贝，本实施例并不限定流表共享的具体方式或者与之相似的等同的方式(如通过某种策略只拷贝某些具体的流表项)，只要通过共享能完成软硬件的流表匹配即可。

本步骤中，先精确匹配流表，如果没有精确匹配的流表项(即流表中没有每个匹配域都能匹配的流表项)，则对流表进行“通配匹配”，即判断多个特征信息中的一个或多个特征信息是否与流表的流表项中的一个或多个(不要求全部)匹配域相匹配，如果匹配，则根据匹配成功的流表项的指令对TCP握手消息进行处理，从而直接或间接将握手请求消息转发给OFS。例如，第二OFS接收到第一OFS发送的第一次握手消息(SYN消息)后，如果可以通配匹配流表项，则按照匹配成功的流表项里的指令进行处理，例如从特定的端口转发出去，并转发到其他OFS，并由其他OFS再转发到OFC。其他OFS收到后第二OFS转发的包后，也可以像第二OFS一样处理，或者仍然采用广播等其他形式进行处理。

为了说明方便，这里称精确流表项中用于“通配匹配”的匹配域为“通配匹配域”，具有“通配匹配域”的精确流表项称为“通配匹配项”，当这些通配匹配域都匹配成功时，能够通过与所述通配匹配域对应的指令将包转发到第二端。本步骤中，对流表进行“通配匹配”的目的是直接或间接将握手请求消息转发给第二端，在具体选择哪一个或多个匹配域作为“通配匹配域”时，只要这几个匹配域对应的指令所确定的转发路由为能最终到达第二端的路由，即通过这一个或多个匹配域对应的指令(指令内容一般为从哪个端口转发)，可以将消息最终转发到第二端，那么就可以作为通配匹配时用到的匹配域。常用的通配匹配域可以是目的MAC、目的IP以及目的端口(协议端口)，一般通过这几个匹配域就可以确定一个特定的第二端的应用，因此，可以匹配这几个域从而将消息转发给第二端。当然，实际应用中，如果其中两个信息(如目的IP及目的端口)，甚至一个信息也可以确定一个第二端的应用时，也可以只匹配其中两个或一个，最终通过匹配域对应的指令将包转发给第二端；为了增加准确性，本实施例也不限定再增加需要匹配的其他字段。

上述用于通配匹配的流表项可以在第二OFS(或其他各个中间OFS)先前与OFC通信时由OFC下发得到，并在进行通配匹配时仍然有效。这些流表项原来是用于对其他一些信息进行转发，但由于这些流表项中有可能包含有两个节点之间的转发路径，本实施例正是利用了这些流表项中存在着的路径来通过通配匹配来实现更精确地转发。当然，如果先前并没有存储有这么一条流表项，或者虽然有过，但是在通配匹配时已经失效不存在了，那么“通配匹配”就不能成功，这种情况下，可以通过广播来实现包的转发。

本实施例中，特征信息可以包括目的MAC，目的IP以及目的端口号；流表的流表项的匹配域包括：目的MAC，目的IP以及目的端口号；从而步骤S23中的“判断所述多个特征信息中的一个或多个特征信息是否与流表的流表项中的一个或多个匹配域相匹配”具体可以包括：判断所述多个特征信息中的目的MAC，目的IP以及目的端口号是否与流表的流表项中的目的MAC，目的IP以及目的端口号相匹配。上述几个用于匹配的特征信息是比较常用的特征信息，本实施例也不限定减少或增加一个或多个特征信息。

本实施例通过通配匹配精确流表来实现转发，从而并不需要广播也能将第一类握手消息转发出去，从而减少了广播次数，能够更好地节省资源，抑制广播风暴。

实施例三

基于上述各实施例，本实施例对实施例二中的TCP三次握手消息交互进行详细说明。

参见图5，为本实施例一个OpenFlow网络示意图，包括OFS1-OFS6多个OFS，以及一个OFC，假设这里的OFS1为第一OFS，OFS3为第二OFS，其与OFS1直接相连(当然，实际中中间也可以还包括多个OFS)，剩下的OFS2、OFS4-OFS6可认为上述实施例中的“其他OFS”。

一、第一次握手

基于上述各实施例，图5示出了TCP第一次握手交互的一个简要流程，即第一OFS先广播第一次TCP握手消息，用TCP_Req表示，该消息具体为TCP/IP包，包头中的SYN置为1，ACK被置0；第二OFS(OFS3)收到后通配查找流表，如果有匹配的流表项，则通过指令执行转发策略，例如图5中转发到OFS5；同样，OFS5也通配查找流表，如果有匹配的流表项，则可以通过指令执行转发策略。由于图5中，OFS3，OFS5都可以不用广播，而由特定的端口转发到下一跳，因此，节省了网络资源。

具体的，基于图5，参见图6，本实施例TCP三次握手中的第一次可通过如下方法完成：

S31、第一OFS上电后配置参数；

第一OFS这里假设为图5的OFS1，OFS1插上网线并上电后，配置一些参数，包括配置自己的IP地址(如使用命令行配置)，并配置关联的OFC的IP地址、端口号及连接方式(TCP、SSL等)，具体配置方法都为现有技术，这里不进行详细描述。

S32、第一OFS生成用于构造TCP连接的第一次TCP握手消息(TCP_Req)，并通过第一OFS端口(物理端口)向外广播。TCP_Req具体为TCP/IP包，参见图7，为该包中的几个字段，对这些字段进行如下设置：

src_mac：第一OFS的MAC地址；src为source的缩写，表示“源”，本文其余各处src的含义如无特殊说明均表示此意；

src_ip：第一OFS的IP地址；

dst_ip：S31中指定的OFC的IP地址；dst为destination的缩写，表示“目的”，本文其余各处dst的含义如无特殊说明均表示此意；

src_port：可以设定为一个固定的端口号(协议端口号，这里由于使用TCP协议，所以为TCP端口号，以下协议端口号如无特殊说明，也都指TCP端口号)，如“36653”；

dst_port：S31中指定OFC的端口号(协议端口号)，如“6633”；

dst_mac：伪MAC地址，FF-FF-FF-FF-FF-FF，该地址也可以是其他约定的值，用于让其他OFS收到后知道是个用于特殊用途的值后不会将包进行丢弃；由于全F在现有网络中默认是广播，因此，设置该值可以兼容现有网络；

置SYN位为1，置ASK位为0；

设置TTL初始值，如30，TTL值用于定义包在网络上的存活时间；

S33、第二OFS通过通配查找流表的方式对第一OFS发送的第一次TCP握手消息的包进行转发。其他各个OFS收到后也进行与第二OFS类似的处理，最终将第一次TCP握手消息转发到OFC。

参见图8，S33具体包括：

S331、解析包的header(头部)；

解析头部后可以得到多个信息，TTL、源/目的MAC、源/目的IP、源/目的端口等，用于后续步骤的判断，后续各OFS在处理第二/三次握手消息时，也会解析出这些信息并根据解析出的信息进行判断；

S332、判断TTL是否大于0，如果是，则执行S333；否则，丢弃包；

S333、精确匹配流表，如果有匹配项，执行S334，根据匹配项中的“指令”域的值进行转发，如果没有，执行步骤S335；

为了增加处理效率，同时兼顾灵活性，上述步骤S331-S334可以使用硬件(如ASIC、FPGA等)来实现，以增加处理速度，后续步骤可以使用软件来实现(CPU执行软件代码)，这样更加灵活。

S335、判断目的IP地址是不是自身关联的OFC的IP地址，如果是，执行步骤S336，否则，丢弃包；

S336、判断目的端口号是不是自身关联的OFC的端口号，如果是，执行步骤S337，否则，丢弃包；

S337、判断是否“ACK！＝1&SYN＝1”(ACK位不等于1并且SYN位等于1)，如果是，则执行步骤S338，否则，丢弃包；该步骤用于判断是否是第一次握手消息，需要说明的是，本实施例中及以下各实施例中，由于OFS在实际应用中会接收很多消息，而针对不同的消息处理方式并不同，所以需要判断是哪一种消息，在真正代码实现时，可能在该步骤的前面或后面会有另一些用于判断是否是其他消息的代码，本实施例及以下各实施例为了说明方便，并不将这些代码都示出，而仅仅示出跟本实施例相关的代码。

步骤S335-S337的作用丢弃掉自身不需要处理的包。

S338、通配匹配流表，如果有匹配项，执行S339，根据匹配项中的“指令”域中的值进行转发，如果没有匹配项，执行S3310，进行广播；

S339、当有能通配匹配的匹配项时，根据匹配项中的“指令”域中的值进行转发。如果没有匹配项的话，则可以进行广播。

上述S33即为第二OFS处理包转发的流程，通过使用“通配地查找流表”的方式以减少广播，从而节约网络资源，抑制广播风暴。

其他OFS也可以采用如第二OFS(如OFS3)一样的方式进行转发，从而最终将包中的第一次握手请求消息(TCP_Req)传递到OFC。

例如，OFS3、OFS5也可以采用这种转发处理流程，图5当中假设OFS3、OFS5都能够通配地匹配流表，从而这两个OFS都不需要广播就可以将包转到OFC。当然，实际当中，如果流表匹配不成功(包括精确匹配和通配地匹配流表)，则仍然可以通过广播的方式进行包转发，如OFS3向OFS5以及OFS2广播；OFS5向OFS4，OFS6，OFC广播。

后续OFC收到包后，解析头部，由于包的目的MAC地址为全F，因此，OFC将其当作一般的广播包处理，剥去二层地址，将包的三层内容进行如下处理(如果用的是约定的MAC地址，OFC知道是约定的MAC地址后也进行如下处理)：

OFC判断包中的目的IP是否等于自己的IP，并且包中的目的端口号是否等于自己监听TCP连接的端口号以及自己的端口号，只要有其中一项不是，则丢弃包；如果都满足，则继续判断是否满足“ACK！＝1&SYN＝1”，如果是，则第一次握手成功，如果不满足，则也丢弃包。需要说明的是，上述几个判断的顺序并不限定。

二、第二次握手

第一次握手成功后，OFC根据收到TCP_Req消息后构造第二次握手消息(TCP_Res)，该消息具体为TCP/IP包，参见图9，为承载第二次握手消息的包的包头字段与第一次的对应图，TCP_Res包头进行如下设置：

dst_mac：第一OFS的MAC地址，等于TCP_Req包头部中的src_mac；

src_mac：OFC的MAC地址；

src_ip：OFC的IP地址，等于TCP_Req包header的dst_ip；

dst_ip：第一OFS的IP地址；

src_port：OFC用于监听Openflow应用的TCP的端口号，等于TCP_Req包header的dst_port；

dst_port：OFS上用于监听Openflow应用的TCP端口号，等于TCP_Req包header的src_port；

ACK与SYN位均置为“1”；

设置TTL初始值；

OFC构造完第二次握手消息后，向OFS发送第二次握手消息，可以向与之相连的一个或多个OFS发送，优选地，向接收第一次握手消息的OFS发送，或者极端的情况下，可以广播。

每个OFS收到第二次握手消息后，先精确匹配流表，如匹配成功，则通过某个具体端口转发，如果匹配不成功，则广播。在转发第二次握手消息时，OFS并不进行通配匹配的方式来匹配流表，这是因为在实际场景中，第一OFS一般是新的OFS，在其他OFS上不会存在一条转发到第一OFS的流表项，因此，也无法使用通配匹配流表的方式来精确地转发第二次握手消息。当然，如果在某些确实有转发到第一OFS的流表项存在的场景下，也可以通过通配匹配流表的方式来实现从某一端口精确转发，而不是通过广播进行转发。

同时，在处理第二次握手消息时，OFS如果确认是来自OFC的第二次握手消息是发给自己的，则更新本地保存的OFC的IP以及MAC之间的映射关系，用OFC真实的MAC地址替换到原来的伪MAC(全F)，以便后续构造发往OFC的包时使用。

参见图10，为各个OFS处理第二次握手消息的示意图，具体的，参见图11，每个OFS可以通过如下方法对第二次握手消息进行转发，包括：

S51、解析头部；

解析头部后可以得到多个信息，TTL、源/目的MAC、源/目的IP等等；

S52、判断TTL是否大于0，如果是执行S53，否则，丢弃包；

S53、精确匹配流表，如果匹配成功，按照“指令”域的值对包进行转发(如转发到某一个特定的端口)；如果匹配失败，则执行S54、

为了加快处理效率，兼顾灵活性，上述几个步骤可以使用硬件实现，下面步骤可以使用软件实现。

S54、判断目的MAC是否为自己的MAC地址，如果是，执行步骤S55，否则，执行步骤S59；如果判断目的MAC地址是自己的MAC地址，则说明是发给自己的包，此时执行步骤S55-S58；否则，说明这个包是发给其他OFS的，自己只是中间用于转发的OFS，此时，执行步骤S59-S6。判断是否是发给自己的包也可以通过目的IP来判断，但实际当中由于MAC是二层协议，比IP先从包头中解析出来，因此，通过MAC判断可以加快处理速度。

S55、判断源IP地址是否为自身关联的OFC的IP地址，如果是，执行步骤S56，否则丢弃包；

S56、判断源端口号是否为自身关联的OFC的端口号，如果是，执行步骤S57，否则，丢弃包；

S57、判断是否满足“ACK＝1&SYN＝1”(ACK位以及SYN位都为1)，如果是，则执行S58，否则，丢弃包；

S58、OFS更新OFC的IP及MAC地址的映射关系，即记录下与OFC的IP地址对应的真实的MAC地址(第一次握手时收到的是第一OFS发送的伪MAC，这里需要更新一下)，这样后续构造发往OFC的包时，就可以根据更新的值设置包头中需要设置的OFC的MAC地址了。至此TCP第二次握手完成。

S59、判断源IP地址是否为自身关联的OFS的IP地址，如果是，执行步骤S510，否则，丢弃包；

S510、判断源端口号是否为自身关联的OFC的端口号，如果是，则执行步骤S511，否则，丢弃包；

S511、判断是否满足“ACK＝1&SYN＝1”，如果是，执行S512，否则，丢弃包；

S512、对包进行广播。

通过上述步骤，最终可以将承载第二次握手消息的包传递给第一OFS(OFS1)，从而完成第二次握手。

三、第三次握手

第一OFS(OFS1)收到OFC发送的TCP_Res后，构造第三次握手消息(TCP_Req’)，该消息具体为TCP/IP包，参见图12，为第三次握手消息的包头字段与前两次的对应图，包头各字段设置如下：

dst_mac：OFC的MAC地址；

src_mac：第一OFS的MAC地址；

src_ip：第一OFS的IP地址；

dst_ip：OFC的IP地址；

src_port：第一OFS上用于监听TCP连接的端口号；

dst_port：OFC上用于监听TCP连接的端口号；

ACK置为“1”，SYN置为“0”；

设置TTL初始值；

第一OFS对构造包进行广播，参见图13，为第三次握手消息从第一OFS发送到OFC的示意图，其中，由于OFS1仍然未有流表，所以OFS1仍然需要广播，各中间OFS收到包后可以通过通配匹配流表的方式从特定端口进行转发，或者通过广播转发，具体的，参见图14，各个OFS可以按如下方法进行处理：

S71、解析头部；

得到TTL、端口号、IP地址等等信息；

S72、判断TTL是否大于零，如果是，则执行S73，否则，丢弃包；

S73、精确匹配流表，如果有匹配项，根据匹配项中的“指令”域的值进行转发，如果没有，则执行S74；

上述3个步骤可使用硬件处理，以增加处理速度；后续步骤可使用软件处理，以增加处理灵活性；

S74、判断目的IP地址是否是自身关联的OFC的IP地址，如果是，执行S75，否则，丢弃包；

S75、判断目的端口号是不是自身关联的OFC的端口号，如果是，执行S76，否则，丢弃包；

S76、判断是否满足“ACK＝1&SYN！＝1”(ACK位为1，SYN位不为1)，如果是，则执行S77，否则，丢弃包；

S77、通配匹配流表；如果匹配成功，则按匹配成功的匹配项中的“指令”域中的值对包进行转发；如果匹配不成功，则广播该包。

通过S77通配匹配流表的方式，可以节省资源，防止广播风暴。

需要说明的是，本实施例中各个OFS通过通配匹配流表的方式对包进行转发的方法并非一定得限定在建立TCP连接这种特定的应用场景，只要涉及到需要多个OFS交互转发到OFC的场景，都可以使用本实施例中的“通配匹配流表”的方式。

实施例四

基于上述各实施例，本实施例对各OFS如何添加路径信息到控制消息的方法进行具体说明。

本实施例中，控制消息可以使用自定义的一些协议的控制消息，或者，为了更好利用现有的资源，更容易实现，可以对现有的一些协议中的控制消息进行扩展，使之可以携带路径信息。本实施例对OpenFlow协议中的OPFT_HELLO消息的body域进行扩展，使之能够携带路径信息。

OpenFlow协议为在TCP/IP层之上的协议，通过TCP/IP进行承载。OpenFlow协议中的OPFT_HELLO消息用于协商版本信息，其body域现在是预留的，没有使用，因此，可以基于body域对该消息进行扩展。

路径信息用于标识各个节点用于形成网络中的路径所需的信息，网络中的路径(或者也称“路由路径”)指包从一个源节点通过另外一个或多个节点后到达目的节点时所经过的路径(当然，也可以不经过中间节点直接到达)。在网络中，如果知道包从其中一个节点的哪个端口进，哪个端口出(这里的端口都为“物理”端口)，那么就可以知道这条路径中，这个节点为整个路径完整形成所贡献的其中一段路径，如果每个节点都有这种路径信息，那么从源节点到目的节点的整条路径就可以确定。

路径信息具体可以包括：OFS的ID，OFS接收控制消息所用的端口号(物理端口号)以及OFS发送控制消息所用的端口号(物理端口号)。OFS的ID用于标识OFS，能够让OFC识别出OFS，例如可以使用一个自定义的唯一的数值来作为ID，或者也可以使用现有协议中定义的一些字段来作为OFS的ID，例如，使用OpenFlow协议中常用的datapath ID来作为OFS的ID。需要说明的是，有时候对于每个物理的OFS会进行一些虚拟化操作，将一个物理OFS分成几个逻辑OFS，则此时的OFS的ID即可认为是逻辑OFS的ID，几个逻辑OFS对各个消息的处理流程同单个物理OFS的处理流程保持一致。

本实施例中，使用三元组[datapath_id,input_no,output_no]来表示路径信息，如果一个OFS收到的OPFT_HELLO消息已经有了上述三元组，则该OFS继续在先前的三元组基础上添加本节点的三元组，形成三元组序列，可用下面方式表示：

<[datapath_id,input_no,output_no],[datapath_id,input_no,output_no]……>

其中：

datapath_id用于标识OFS，该字段在OpenFlow协议中有定义，其低48bit是交换机的MAC地址，高16位由实现者定义(如配合虚拟网络ID来实现OFS的虚拟化)；

input_no：包进入OFS的端口编号；

output_no：包转出OFS的端口编号。

参见图15，为本实施例在OPFT_HELLO消息body域中扩展路径信息的示意图，图中从body_length域以下的部分就是路径信息，可以有多组路径信息，每组路径信息包括datapath_id,input_no,output_no三部分。

在TCP三次握手交互完成后，第一OFS生成OFPT_HELLO消息，构造TCP/IP包并广播该包；

该TCP/IP包的头部作如下设置

dst_mac：OFC的MAC地址；

src_mac：第一OFS的MAC地址；

src_ip：第一OFS的IP地址；

dst_ip：OFC的IP地址；

src_port：第一OFS上用于监听TCP连接的端口号；

dst_port：OFC上用于监听TCP连接的端口号；

设置TTL初始值；

包中的payload中携带OFPT_HELLO消息，OFPT_HELLO消息中的body域增加路径三元组<[dpid_OFS1,--,output_no_OFS1]>，dpid_OFS1表示路径ID，“--”表示包进入OFS的端口号为空(由于是初始OFS，并没有从其他OFS接收到包)；output_no_OFS1表示包从第一OFS(OFS1)转出的端口号。

第二OFS(OFS3)收到第一OFS(OFS1)发送的OFPT_HELLO消息的包后，将路径信息添加到OFPT_HELLO消息中的body域。本实施例中，各个OFS处理OFPT_HELLO消息的包时也可以基于实施例二、三中提到的通配匹配流表的方式进行转发，如果匹配成功，可以按匹配项中“指令”域的值从特定端口转发，如果匹配不成功，可以广播或者从事先定义的多个端口转发。相应的，从哪个端口转发出去就得添加一个含有这个端口信息的路径信息到OFPT_HELLO消息中的body域。具体的，第二OFS以及其他各OFS接收到OFPT_HELLO消息的包后，可通过下述方法进行转发，参见图16，包括：

S91、解析包，获得TTL、端口号、IP地址、MAC地址等信息；

S92、判断TTL是否大于0，如果是，执行S93，否则，丢弃包；

S93、精确匹配流表，如果有匹配项，则按照匹配项中“指令”域的值将包发送指定的端口；如果没有匹配项，则执行S94；

上述步骤可用硬件实现，以增加处理速度；下述步骤可用软件实现，以增加灵活性。

S94、判断目的IP地址是否是自身关联的OFC的IP地址，如果是，执行S95，否则，丢弃包；

S95、判断目的端口号是否是自身关联的OFC的端口号，如果是，执行S96，否则，丢弃包；

S96、判断包中承载的是否是OFPT类型的消息，如果是，执行S97，否则，丢弃包；具体可通过解析包payload中的信息来判断；

S97、判断消息的类型是否为OFPT类型中的OFPT_HELLO消息，如果是，执行S98，否则，丢弃包；

S98、通配匹配流表，如果有匹配项，执行S99，否则，执行S910；

S99、在OFPT_HELLO消息的body中添加当前OFS的路径信息，执行S911；

S910、获取OFS当前可用的输出端口，执行S912；

一般可选取所有可用的输出端口，后续从这些端口进行广播，实际应用中也可以获取一部分端口进行广播(如获取事先指定的一些端口)，并非一定要获取所有的可用端口全部；

S911、将OFPT_HELLO消息的包按照匹配项中“指令”域中的值进行转发，流程结束；

S912、在OFPT_HELLO消息的body中添加各个可用的输出端口对应的当前OFS的路径信息；例如，假设有两个输出端口，分别是port11，port22，假设datapath_id为datapath_id1，input_no为input_no1，则在OFPT_HELLO消息body域添加如下信息：

[datapath_id1,input_no1,port11],[datapath_id,1input_no1,port22]

继续执行S913；

S913、从S910步骤中获取的可用的输出端口转发，流程结束。

参见图17-图18，为OFPT_HELLO消息在各OFS传递示意图，图中用Hello表示OFPT_HELLO消息(以下简称“Hello消息”)，Hello后面括号里的数字表示添加有不同路径信息的OFPT_HELLO消息，通过图17-图18来对OFPT_HELLO消息传递过程中body域中路径信息变化进行说明。

参见图17，OFS1先广播发送Hello消息，OFS3以及OFS5收到Hello消息后通过通配匹配流表后通过某个特定的端口进行转发(如OFS3通过32号端口)，在这种情况下，各个Hello消息中的body域信息如下：

Hello(1):<[dpid_OFS1,--,11]>

Hello(2):<[dpid_OFS1,--,12]>

Hello(3):<[dpid_OFS1,--,11],[dpid_OFS3,31,32]>

Hello(4):<[dpid_OFS1,--,11],[dpid_OFS3,31,33]>

Hello(5):<[dpid_OFS1,--,11],[dpid_OFS3,31,33],[dpid_OFS5,51,52]>

参见图18，OFS1先广播发送Hello消息，OFS3通过通配匹配流表发现没有匹配项，因此也进行广播，OFS5收到Hello消息后通过通配匹配流表后通过某个特定的端口(52)进行转发，在这种情况下，各个Hello消息中的body域信息如下：

Hello(1):<[dpid_OFS1,--,11]>

Hello(2):<[dpid_OFS1,--,12]>

Hello(3):<[dpid_OFS1,--,11],[dpid_OFS3,31,32]>

Hello(4):<[dpid_OFS1,--,11],[dpid_OFS3,31,33]>

Hello(5):<[dpid_OFS1,--,11],[dpid_OFS3,31,33],[dpid_OFS5,51,52]>

OFC根据收到的Hello(5)消息中携带的路径信息就知道这个消息最先通过OFS1的11号端口发送到OFS3的31号端口，然后再从OFS3的32号端口发送到OFS5的51号端口，最后从OFS5的52号端口发送到OFC。相应的，反向路径(从OFC到OFS1的路径)也能随之确定(如从OFS5的51号端口发送到OFS3的32号端口)。

需要说明的是，在另一实施例中，通过OFPT_HELLO消息的body域的扩展也可以不依赖于前面实施例，例如，可以不使用前述“先建立可靠连接”、“先精确匹配再通配匹配”等步骤，而仅仅关注OFPT_HELLO消息的body域被扩展后用于承载路径信息，具体可参见实施例十二的描述。

实施例五

基于上述各实施例，本实施例提供了OFC获取路径信息后，进行流表项(流表项)下发的方法。

流表项的作用是让OFS不需要再进行广播，而是可以通过流表项实现精确地转发，例如，现在图16中的示意图中，通过给OFS1、OFS3、OFS5下发流表项，使OFS1到OFC的消息能够通过OFS1->OFS3->OFS5->OFC这么一条单向路径传递到OFC(或者也可以反向传递)，而不需要再经过广播(如OFS1发送给OFS2，OFS3发送给OFS2)。

OFC获取路径信息后，制定各个OFS所需的流表项。例如，针对图16中OFS1要向OFC发包的需求，OFS1中流表项中几个主要相关的域例如目的IP、目的MAC、目的端口(软件端口)为OFC的IP、MAC及端口，源IP、源MAC、源端口(软件端口)为OFS1自己的IP、MAC及端口，指令为端口(物理端口)号11。针对其他OFS的流表项也类似，相应调整一下目的/源各类信息及指令中的端口号即可。

参见图19，为针对一些OFS的流表项示意图，图19中，假设OFC收集到的是OFS1->OFS3->OFS5->OFC的路径信息，则可以对相关的OFS发送流表项，例如，可以OFS1、OFS3、OFS5下发正向流表项，从而能够将包从OFS1转发到OFC；对OFS3、OFS5下发反向流表项，从而能将包从OFC转发到OFS1、OFS3。

图19中，各个OFS的MAC地址用“MAC_OFS名称”来表示，如MAC_OFS1表示OFS1的MAC地址；OFS1的IP地址假设为192.169.1.5，OFS3的IP地址假设为192.168.1.12，OFS5的IP地址假设为192.168.1.9，OFC的IP地址假设为192.168.1.21；各个OFS的TCP端口号假设为6633，OFC的TCP端口号假设为36653；各个字段分别为switch port(Switch的输入端口)，目的MAC、源MAC、源IP、目的IP、源端口、目的端口以及匹配成功时执行的指令，最左边的flow_entry表示一条流表项。

图19中，flow_entry(51)-flow_entry(55)是针对OFS5的，其中，flow_entry(51)针对；flow_entry(31)-flow_entry(33)是针对OFS3的，flow_entry(11)是针对OFS1的。具体的，以OFS3的流表项为例，flow_entry(31)用于对OFC发往OFS3的包进行转发，flow_entry(32)用于对OFC发往OFS1的包进行转发，flow_entry(33)用于对OFS1发往OFC的包进行转发。

需要说明的是，图19示例中只列举了流表项中一些相关的域，对于流表项中的其他域的值，本领域技术人员可以很容易结合实际应用场景得到，这里不再赘述。

OFC下发流表时，可以按路径上的OFS与自己跳数从小到大的顺序向各个OFS下发流表项，这样，跳数最小(最近)的OFS收到流表项后，就可以对后续的包进行精确转发，而不需要广播。当然，如果不考虑广播开销的话，也可以通过广播下发流表项。

参见图20，以OFC接收到Hello消息后下发流表项为例，主要流程包括：

S111、解析头部；

S112、判断包中的目的IP地址是否等于自己的IP地址，如果是，执行S113，否则，丢弃包；

S113、判断包中的目的端口号是否等于自己监听的TCP连接的端口号，如果是，执行S114，否则，丢弃包；

S114、判断包中承载的是否是OFPT类型的消息，如果是，执行S115，否则，丢弃包；

S115、判断OFPT消息类型是否是OFPT_HELLO消息，如果是，执行S116，否则，丢弃包；

S116、提取源OFS与OFC之间的路径信息，后续执行S117步骤以及S119步骤制定流表项(S117针对正反路径的流表项、S119针对反向路径)；

S117、为路径上的相关OFS制定到OFC的流表项，执行S118；

为第一OFS以及中间用于转发的OFS制定到OFC的流表项；

S118、下发流表项到该路径上的相关OFS；

可以按路径上的OFS与自己跳数从小到大的顺序向各个OFS下发流表项，或者广播；流程结束；

如果OFC通过路径信息中的datapath_id，不能找到对应的IP地址及MAC地址，则将下发流表项中的MAC地址设置为伪MAC地址(如FF-FF-FF-FF-FF-FF)，如果是IPv4地址，则将该datapath_id对应的地址设置为IPv4组播地址或广播地址，如果是IPv6地址，则将该datapath_id对应的地址设置为IPv6组播地址。

S119、为路径上的中间OFS制定到第一OFS的流表项，执行S1110；

中间OFS指用于将OFC发送的包转给第一OFS的OFS；

S1110、下发流表项到该路径上的中间OFS；与S118类似，可基于跳数下发或者广播，流程结束。

类似的，在这个分支执行过程中，如果OFC通过路径信息中的datapath_id，不能找到对应的IP地址及MAC地址，则将下发流表项中的MAC地址设置为伪MAC地址(如FF-FF-FF-FF-FF-FF)，如果是IPv4地址，则将该datapath_id对应的地址设置为IPv4组播地址或广播地址，如果是IPv6地址，则将该datapath_id对应的地址设置为IPv6组播地址。

下面具体介绍流表项构造及下发的方法。

方法一

遵循现有OpenFlow协议，利用OFPT_FLOW_MOD消息携带流表项每个OFPT_FLOW_MOD消息只包含一个flow_entry。

以OpenFlow Spec 1.2规范为例，OFPF_FLOW_MOD消息结构如下：

OFC构造一个用于承载OFPT_FLOW_MOD消息的TCP/IP包，包头进行如下设置：

dst_mac：OFS的MAC地址；

src_mac：OFC的MAC地址；

src_ip：OFC的IP地址；

dst_ip：OFS的IP地址；

src_port：OFC用于监听的端口

dst_port：OFS上用于监听TCP连接的端口号

设置TTL初始值；

上述OFS是指路径上需要获取流表项的OFS，例如可以是第一OFS或者中间用于转发的OFS。

OFC构造完包后向各个OFS发送，参见图21，每个OFS收到后进行如下处理：

S131、解析头部；

S132、判断TTL是否大于0；如果是，执行S133，否则，丢弃包；

S133、精确匹配流表，如果有匹配项，根据匹配项中的“指令”域中的值进行转发，如果没有匹配项，执行S134；

上述步骤可用硬件实现，下述各步骤可用软件实现。

S134、判断目的MAC地址是否是自身的MAC地址或者伪MAC地址(如全F)，如果是，执行S135，否则执行S1310；

S135、判断源IP是不是自身关联的OFC的IP地址(或者组播地址，或者广播地址)，如果是，执行S136，否则，丢弃包；

S136、判断源端口号是不是自身关联的OFC的端口号，如果是，执行S137，否则，丢弃包；

S137、判断是否是OFPT类型的消息，如果是，执行S138，否则，丢弃包；

S138，判断OFPT消息类型是否是OFPT_FLOW_MOD，如果是，执行S139，否则，丢弃包；

S139、提取OFPT_FLOW_MOD消息中的流表项，将流表项插入到流表中；具体的，OFS判断OFPT_FLOW_MOD中是否包含自己的datapath_id，如果包含，则将datapath关联的一条或者多条精确匹配的流表项添加到流表；如果OFPT_FLOW_MOD中包含的一个MAC域的值等于FF-FF-FF-FF-FF-FF，并且该MAC地址对应的IP地址为组播地址或广播地址，则将本交换机的MAC地址及IP地址更新到流表项中，流程结束。

S1310、判断源IP是不是自身关联的OFC的IP地址，如果是，执行S1311，否则，丢弃包；

S1311、判断源端口号是不是自身关联的OFC的端口号，如果是，执行S1312，否则，丢弃包；

S1312、判断是否是OFPT类型的消息，如果是，执行S1313，否则，丢弃包；

S1313、判断OFPT消息类型是否是OFPT_FLOW_MOD，如果是，执行S1314，否则，丢弃包；

S1314、广播该包，流程结束。

方法二

另一种构造的方法是扩展OpenFlow协议的OFPT_FLOW_MOD消息，使一条OFPT_FLOW_MOD消息可以包含多条与某个OFS相关的flow_entry。参见以下结构体，结构体ofp_multi_flow_mod_list即为在OFPT_FLOW_MOD消息扩展的部分。

转发流程与方法一中的转发流程类似，但在S139步骤中，一次性可以提取多条流表项。

方法三

扩展OpenFlow协议的OFPT_FLOW_MOD消息，使一条OFPT_FLOW_MOD消息可以包含一条路径上(以OFS1、OFS3、OFS5及OFC组成的路径为例)所有相关OFS(如OFS1、OFS3及OFS5)的多条flow entries(如图30中列出的所有flow_entry)。由于需要发送给所有路径上的设备，所以本实施例在ofp_flow_mod_body结构体中增加了datapath_id标识，以对路径上的设备进行标识，从而后续能够转发给路径上的信息。

包的Payload中携带扩展后的OFPT_FLOW_MOD，包含路径(以OFS1、OFS3、OFS5及OFC组成的路径为例)上每个交换机(OFS1、OFS3、及OFS5)相关的流表项。

OFS接收到一个TCP/IP包后，如果判断出消息类型是OFPT_FLOW_MOD，则从中提取出与自己相关(即，ofp_flow_mod_body.datapath_id等于自身的datapath_id)的若干条flow_entries，并插入到table_id指示的精确表中；然后，继续广播该包，直到该OFPT_FLOW_MOD中涉及的OFS都收到该消息为止。

实施例六

基于上述各实施例，本实施例提供了一种SDN交换机的硬件结构，参见图22，以OFS的硬件结构为例，可以包括：

收发器件、硬件器件以及软件器件；

收发器件为用于完成包收发的硬件电路，也可以与硬件器件做成一块物理芯片；

硬件器件也可称“硬件处理模块”，或者更简单的，也可简称为“硬件”，用于对接收到的包进行处理。硬件器件主要包括基于FPGA、ASIC之类专用硬件电路(也会配合其他配套器件，如存储器)来实现某些特定功能的硬件电路，其处理速度相比通用CPU往往要快很多，但功能一经定制，便很难更改，因此，实现起来并不灵活，通常用来处理一些固定的功能。需要说明的是，硬件器件在实际应用中，也可以包括MCU(微处理器，如单片机)、或者CPU等处理器，但这些处理器的主要功能并不是完成大数据的处理，而主要用于进行一些控制，在这种应用场景下，由这些器件搭配的系统为硬件器件。

软件器件(或者也简单“软件”)主要包括通用的CPU及其一些配套的器件(如内存、硬盘等存储设备)，可以通过软件编程来让CPU具备相应的处理功能，用软件来实现时，可以根据业务需求灵活配置，但往往速度相比硬件器件来说要慢。软件处理完后，可以通过硬件器件将处理完的数据通过收发器件进行发送，也可以通过一个与收发器件相连的接口向收发器件发送处理完的数据。

本实施例中，硬件器件可用于进行上述实施例中提到的精确匹配，软件器件用于进行上述实施例提到的通配匹配。即OFS通过收发电路收到包后，也送至硬件器件处理，如果匹配成功，则转发；如果匹配不成功，则送至软件器件进行处理(例如，可以产生一个OpenFlow协议定义的packet_in消息将包送至软件器件)。

硬件及软件中都保存有精确流表，两者可以保持一定的映射关系，这点在实施例二中已经详细论述，这里不再赘述。

通过本实施例软硬结合的方法，既保证了处理的速度，又具有灵活性。

当然，本实施例也不限定用软件的方式来实现，例如，参见图23，为用软件器件实现的方案，即通过处理器运行存储在存储器(如硬盘、内存)中的代码来执行相应的操作。

实施例七

基于上述各实施例，参见图24，本实施例提供了一种SDN交换机，该SDN交换机为第二SDN交换机，第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，SDN控制器与各个SDN交换机相互之间通过带内通信的方式进行通信，第二SDN交换机包括：

连接建立单元71，用于与所述第一SDN交换机以及所述SDN控制器之间进行消息交互，使得所述第一SDN交换机以及所述SDN控制器之间建立可靠连接；

第一接收单元72，用于接收第一SDN交换机发送的用于收集路径信息的第一控制消息，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述可靠连接所使用的协议对应的包进行承载；

路径添加单元73，将所述第二SDN交换机的路径信息添加到所述第一接收单元接收到的所述第一控制消息，得到更新后的第一控制消息；

转发单元74，用于将所述路径添加单元添加了所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的第一控制消息的最终更新后的第一控制消息后，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

本实施例中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包；

所述连接建立单元具体用于：转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包，从而使得所述第一SDN交换机与所述SDN控制器之间建立TCP连接。

本实施例中，第二SDN交换机包括精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

参见图25，所述连接建立单元71具体包括：

接收子单元711，接收来自所述第一SDN交换机的发送的第一TCP/IP包；

特征信息获取子单元，获取所述接收子单元接收到的所述第一TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

第一匹配子单元712，用于将所述特征信息获取子单元获取的所述第一TCP/IP包中的多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配不成功且判断收到所述第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理，以将所述第一TCP/IP包转发到所述SDN控制器，其中，所述第一类TCP握手消息为第一次TCP握手消息，或者第三次TCP握手消息。

本实施例中，所述接收子单元还用于：接收来自所述SDN控制器的发送的第三TCP/IP包，所述第三TCP/IP包承载有第二次握手消息；

所述特征信息获取子单元还用于：获取所述接收子单元接收到的所述第三TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

所述第一匹配子单元还用于：将所述特征信息获取子单元获取的所述第三TCP/IP包中的多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发，如果匹配失败且判断所述第三TCP/IP包承载的是所述第二次TCP握手消息时，则广播所述第三TCP/IP包。

本实施例中，第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述第一接收单元具体用于：

接收来自所述第一SDN交换机发送的承载有所述第一控制消息的第二TCP/IP包，所述第二TCP/IP包包括多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；

参见图26，所述路径添加单元包括：

第二匹配子单元731，用于根据所述第二接收子单元接收到的所述第二TCP/IP包中的特征信息与精确流表进行精确匹配，当所述精确匹配不成功且判断收到的所述第二TCP/IP包中承载的是所述第一控制消息后，根据所述TCP/IP包中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；

添加子单元732，用于在所述第二匹配子单元通配匹配成功时，在所述第一控制消息中添加所述第二SDN交换机的路径信息，得到添加有所述第二SDN交换机的路径信息的更新后的第一控制消息；

参见图27，所述转发单元74包括第一转发子单元741，用于将所述添加子单元处理后得到的所述更新后的第一控制消息按照通配匹配成功的精确流表项中指令转发给所述SDN控制器。

本实施例中，所述添加子单元732还用于，如果所述第二匹配子单元731通配匹配不成功，获取所述第二SDN交换机可用的输出端口，在所述第一控制消息中添加各个可用的输出端口对应的所述第二SDN交换机的路径信息；

参见图27，所述转发单元74还包括第二转发子单元742，用于从可用的输出端口将所述添加子单元添加了各个可用的输出端口对应的所述第二SDN交换机的路径信息的所述更新后的第一控制消息转发给所述SDN控制器。

与上面提到的实施例类似，本实施例中，SDN网络可以基于OpenFlow协议实现，在这种情景下，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息；

所述第一接收单元具体用于通过所述连接建立单元建立的所述可靠连接接收第一SDN交换机发送的用于收集路径信息的OFPT_HELLO消息，所述OFPT_HELLO消息用于承载所述路径信息的扩展后的body域中携带有所述第一SDN交换机的路径信息；

所述路径添加单元具体用于将所述第二SDN交换机的路径信息添加到所述第一接收单元接收到的所述OFPT_HELLO消息中的用于承载所述路径信息的扩展后的body域，得到更新后的OFPT_HELLO消息；

所述转发单元具体用于将所述路径添加单元添加了所述第二SDN交换机的路径信息的所述更新后的OFPT_HELLO消息转发给所述SDN控制器，使得所述SDN控制器收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机。

本实施例中，所述转发单元具体用于：将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息直接转发给所述SDN控制器，所述最终更新后的第一控制消息为所述更新后的第一控制消息；或者，

将添加有所述第二SDN交换机的路径信息的所述更新后的第一控制消息通过一个或多个其他SDN交换机间接转发给所述SDN，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

本实施例中，所述SDN网络基于OpenFlow协议实现，所述SDN交换机还包括：

第二接收单元，用于接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有目的SDN交换机需要的多条的精确流表项；

第一流表项处理单元，用于当判断通过所述第二接收单元收到的消息为发送给所述第二SDN交换机自身的OFPT_FLOW_MOD消息时，提取所述OFPT_FLOW_MOD消息中携带的多条精确流表项后添加到本地精确流表中。

或者，当SDN网络基于OpenFlow协议实现时，本实施例也可以还包括：

第三接收单元，用于接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机使用一个或多个精确流表项；

第二流表项处理单元，用于当判断所述第三接收单元收到的消息为发送给所述第二SDN交换机自身的所述OFPT_FLOW_MOD消息时，根据与自身对应的路径信息提取自身所需使用的一个或多个精确流表项，并将提取完后的OFPT_FLOW_MOD消息转发给下一个路由路径上的节点。

本实施例中，所述路径信息包括：发送或收到所述第一控制消息的SDN交换机的ID，接收所述第一控制消息所用的端口号以及发送所述第一控制消息所用的端口号。

通过本实施例，可以减少成本，提升SDN交换机转发效率，减少广播风暴，具体原因可参见前述实施例分析，这里不再赘述。

实施例八

基于上述各实施例，本实施例公开了一种SDN控制器，所述SDN控制器与第二SDN交换机相连，所述第二SDN交换机与第一SDN交换机相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信，参见图28，所述SDN控制器包括：

第一接收单元81，用于接收所述第二SDN交换机转发的最终更新后的第一控制消息，其中，所述最终更新后的第一控制消息包括更新后的第一控制消息，所述更新后的第一控制消息由所述第二SDN交换机在收到所述第一SDN交换机发送的用于收集路径信息的第一控制消息后，将所述第二SDN交换机的路径信息添加到所述第一控制消息后得到；其中，所述第一控制消息中携带有所述第一SDN交换机的路径信息，所述第一控制信息通过所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包进行承载；

路径获取单元82，用于根据所述第一接收单元接收的所述最终更新后的第一控制消息中携带的各个SDN交换机添加的路径信息获取所述SDN控制器自身与所述第一SDN交换机之间的路由路径；

流表下发单元83，用于通过所述路径获取单元获取的所述路由路径将精确流表项下发给所述第一SDN交换机。

本实施例中，所述第一SDN交换机与所述SDN控制器之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机转发承载有所述第一SDN交换机以及所述SDN控制器之间进行的三次TCP握手消息的TCP/IP包来建立。

本实施例中，所述SDN网络可以基于OpenFlow协议实现，在这种情景下，所述第一控制消息包括OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息。

本实施例中，所述第一接收单元具体用于：

直接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为所述更新后的第一控制消息；

或者，

通过一个或多个其他SDN交换机间接接收所述第二SDN交换机转发的所述最终更新后的第一控制消息，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

本实施例中，所述SDN网络可以基于OpenFlow协议实现，相应地，所述流表下发单元具体用于：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入所述第一SDN交换机需要的精确流表项；

通过所述路由路径将所述OFPT_FLOW_MOD消息发送给所述第一SDN交换机，使得所述第一SDN交换机根据所述OFPT_FLOW_MOD消息获取精确流表项。

或者，

所述流表下发单元具体用于：

在OpenFlow协议中定义的OFPT_FLOW_MOD消息中加入多个位于路由路径上的OFS需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机需要一个或多个精确流表项；

通过所述路由路径下发给所述其他SDN交换机，使得所述其他SDN交换机收到后根据路径信息以及所述OFPT_FLOW_MOD消息中的路径信息提取自身所需的精确流表项，并转发剩下的精确流表项，最终将所述第一SDN交换机所需的精确流表项转发给所述第一SDN交换机。

实施例九

参见图29，本实施例公开了一种软件定义网络SDN系统，包括：第一SDN交换机91、第二SDN交换机92以及SDN控制器94(中间也可以有一个或多个其他SDN交换机93)，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信；

所述第一SDN交换机9191用于向所述第二SDN交换机92发送用于收集路径信息的第一控制消息，所述第一控制消息中携带有所述第一SDN交换机91的路径信息，所述第一控制信息通过所述第一SDN交换机91与所述SDN控制器94之间建立的可靠连接所使用的协议对应的包进行承载；

所述第二SDN交换机92用于接收所述第一控制消息，将所述第二SDN交换机92的路径信息添加到所述第一控制消息，得到更新后的第一控制消息，并将添加有所述第二SDN交换机92的路径信息的所述更新后的第一控制消息转发给所述SDN控制器94；

所述SDN控制器94用于接收所述第二SDN交换机92发送的包括所述更新后的第一控制消息的最终更新后的第一控制消息，根据所述最终更新后的第一控制消息中各SDN交换机添加的路径信息确定自身与所述第一SDN交换机91之间的路由路径并根据所述路由路径将精确流表项下发给所述第一SDN交换机91。

本实施例中，所述第一SDN交换机91与所述SDN控制器94之间建立的可靠连接包括TCP连接，所述可靠连接所使用的协议对应的包为TCP/IP包，所述TCP连接通过所述第二SDN交换机92转发承载有所述第一SDN交换机91以及所述SDN控制器94之间进行的三次TCP握手消息的TCP/IP包来建立。

本实施例中，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令；

所述第二SDN交换机具体用于接收来自所述第一SDN交换机的发送的第一TCP/IP包；获取接收到的所述第一TCP/IP包中的多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；将所述多个特征信息与所述第二SDN交换机中的精确流表进行精确匹配，如果精确匹配不成功且判断收到所述第一TCP/IP包承载的为第一类TCP握手消息时，则将多个特征信息中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果通配匹配成功，则按通配匹配成功的精确流表项中的指令对接收到的承载了所述第一类TCP握手消息的所述第一TCP/IP包进行处理，以将所述第一TCP/IP包转发到所述SDN控制器，其中，所述第一类TCP握手消息为第一次TCP握手消息，或者第三次TCP握手消息；以实现与所述第一SDN交换机、所述其他OFS以及所述SDN控制器之间进行用于可靠连接建立的消息交互，以建立所述可靠连接。

所述第二SDN交换机具体还用于接收来自所述第一SDN交换机发送的承载有所述第一控制消息的第二TCP/IP包，所述第二TCP/IP包包括多个特征信息，其中，所述特征信息与所述第二SDN交换机中的精确流表的精确流表项中的匹配域相对应；根据所述第二TCP/IP包中的特征信息与精确流表进行精确匹配，当所述精确匹配不成功且判断收到的所述第二TCP/IP包中承载的是所述第一控制消息后，根据所述TCP/IP包中的一个或多个特征信息与所述精确流表进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则在所述第一控制消息中添加所述第二SDN交换机的路径信息，得到添加有所述第二SDN交换机的路径信息的更新后的第一控制消息，并将所述更新后的第一控制消息按照通配匹配成功的精确流表项中指令转发给所述SDN控制器。

本实施例中，所述SDN网络可以基于OpenFlow协议实现，此时，所述第一控制消息包括OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载所述路径信息。

本实施例中，第二SDN交换机可以通过直接或间接的方式将第一控制消息转发给SDN控制器，当直接转发时，所述最终更新后的第一控制消息为所述更新后的第一控制消息；当间接转发时，所述最终更新后的第一控制消息为每个所述其他SDN交换机在收到前一个SDN交换机发送的第一控制消息并在其中添加自身路径信息后最终发送给所述SDN控制器的第一控制消息。

本实施例中，当SDN网络基于OpenFlow协议实现时，可以通过几种方法基于OpenFlow协议中的消息来携带精确流表项：

第一种方法对应的实施例中，第二SDN交换机接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有目的SDN交换机需要的多条精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的OFPT_FLOW_MOD消息时，提取所述OFPT_FLOW_MOD消息中携带的多条精确流表项后添加到本地精确流表中。

第二种方法对应的实施例中，第二SDN交换机接收来自所述SDN控制器发送的OpenFlow协议中定义的OFPT_FLOW_MOD消息，所述OFPT_FLOW_MOD消息携带有多个位于路由路径上的SDN交换机需要的多个精确流表项，以及与每个路由路径上的SDN交换机对应的路径信息，其中，每个路由路径上的SDN交换机使用一个或多个精确流表项；

当判断收到的消息为发送给所述第二SDN交换机自身的所述OFPT_FLOW_MOD消息时，根据与自身对应的路径信息提取自身所需使用的一个或多个精确流表项，并将提取完后的OFPT_FLOW_MOD消息转发给下一个路由路径上的节点。

本实施例中的所述路径信息包括：发送或收到所述第一控制消息的SDN交换机的ID，接收所述第一控制消息所用的端口号以及发送所述第一控制消息所用的端口号。

实施例十

基于上述各实施例，本实施例公开了一种SDN交换机转发包的方法，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括至少一个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，参见图30，所述方法包括：

S301、接收来自第一SDN交换机发送的包，所述包包括多个特征信息，其中，所述特征信息与所述精确流表项中的匹配域相对应；

S302、获取所述包中的所述特征信息；

S303、将所述特征信息与所述精确流表中的精确流表项进行精确匹配；如果精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则按通配匹配成功的精确流表项中的指令对所述包进行转发。

本实施例中，如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；如果通配匹配不成功，则通过广播转发接收到的包。

本实施例中，所述第二SDN交换机与第一SDN交换机、SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

本实施例中，所述包为所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

通过本实施例，可以提高SDN交换机转发效率，同时，本实施例也并不限定基于本实施例的方案具体转发的包的类型。

实施例十一

基于上述各实施例，本实施例提供了与实施例十方法对应的SDN交换机，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，参见图31，所述第二SDN交换机包括：

接收单元101，用于接收来自第一SDN交换机发送的包，所述包包括一个或多个特征信息；

获取单元102，用于获取所述接收单元接收的包中的所述特征信息；

精确匹配单元103，用于将所述获取单元获取的所述一个或多个特征信息与所述精确流表中的精确流表项进行精确匹配，其中，所述一个或多个特征信息与所述精确流表中的所述精确流表项中的匹配域相对应；

通配匹配单元104，用于如果所述精确匹配单元执行的精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；

转发单元105，用于如果所述通配匹配单元执行的通配匹配成功，则按匹配成功的精确流表项中的指令对所述包进行转发。

本实施例中，所述匹配及转发单元还用于：

如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；

如果通配匹配不成功，则通过广播转发。

所述第二SDN交换机与第一SDN交换机、SDN控制器相连(可以直接或间接相连)，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

所述包为所述第一SDN交换机与所述SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

实施例十二

基于上述各实施例，本实施例提供了一种开放流交换机OpenFlow Switch，OFS收集路径信息的方法，应用于第二OFS，所述第二OFS与第一OFS，开放流控制器OpenFlowController，OFC相连，形成OpenFlow网络，其中，所述OFC与各个OFS之间通过带内通信的方式进行通信，参见图32，所述方法包括：

S321、接收第一OFS发送的用于收集路径信息的OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息，所述OFPT_HELLO消息承载有所述第一OFS的路径信息，所述OFPT_HELLO消息通过所述第一OFS与所述OFC之间建立的可靠连接所使用的协议对应的包进行承载；

S322、添加所述第二OFS路径信息到所述OFPT_HELLO消息，得到更新后的OFPT_HELLO消息；

S323、将所述更新后的OFPT_HELLO消息转发给所述OFC，使得所述OFC收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各OFS添加的路径信息确定自身与所述第一OFS之间的路由路径并根据所述路由路径将精确流表项下发给所述第一OFS。

所述路径信息包括：发送或收到所述OFPT_HELLO消息的OFS的ID，接收所述OFPT_HELLO消息所用的端口号以及发送所述OFPT_HELLO消息所用的端口号。

本实施例中，将所述更新后的OFPT_HELLO消息转发给所述OFC包括：

将所述更新后的OFPT_HELLO消息直接转发给所述OFC，所述最终更新后的OFPT_HELLO消息为所述更新后的OFPT_HELLO消息；或者，

将所述更新后的OFPT_HELLO消息通过一个或多个其他OFS间接转发给所述OFC，其中，所述其他OFS在收到的所述更新后的OFPT_HELLO消息中添加路径信息，得到所述最终更新后的OFPT_HELLO消息。

通过本实施例，可以基于现有的OpenFlow协议中的消息来完成对路径信息的承载，并不需要再修改协议，节省了开发成本。

实施例十三

基于上述各实施例，本实施例公开了与实施例十二中的方法对应的OFS，该OFS为第二OFS，所述第二OFS与第一OFS，开放流控制器OpenFlow Controller，OFC，以及至少一个其他OFS相连，形成OpenFlow网络，其中，所述OFC与各个OFS之间通过带内通信的方式进行通信，参见图33，所述第二OFS包括：

接收单元131，用于接收第一OFS发送的用于收集路径信息的OpenFlow协议中定义的OFPT_HELLO消息，所述OFPT_HELLO消息的body域被扩展后用于承载路径信息，所述OFPT_HELLO消息承载有所述第一OFS的路径信息，所述OFPT_HELLO消息通过所述第一OFS与所述OFC之间建立的可靠连接所使用的协议对应的包进行承载；

路径信息添加单元132，添加所述第二OFS路径信息到所述接收单元接收到的所述OFPT_HELLO消息，得到更新后的OFPT_HELLO消息；

转发单元133，用于将通过所述路径信息添加单元添加了第二OFS路径信息的所述更新后的OFPT_HELLO消息转发给所述OFC，使得所述OFC收到包括所述更新后的OFPT_HELLO消息的最终更新后的OFPT_HELLO消息后，根据所述最终更新后的OFPT_HELLO消息中各OFS添加的路径信息确定自身与所述第一OFS之间的路由路径并根据所述路由路径将精确流表项下发给所述第一OFS。

其中，所述路径信息包括：发送或收到所述OFPT_HELLO消息的OFS的ID，接收所述OFPT_HELLO消息所用的端口号以及发送所述OFPT_HELLO消息所用的端口号。

本实施例中，转发单元133具体用于：

将所述更新后的OFPT_HELLO消息直接转发给所述OFC，所述最终更新后的OFPT_HELLO消息为所述更新后的OFPT_HELLO消息；或者，

将所述更新后的OFPT_HELLO消息通过一个或多个其他OFS间接转发给所述OFC，其中，所述其他OFS在收到的所述更新后的OFPT_HELLO消息中添加路径信息，得到所述最终更新后的OFPT_HELLO消息。

实施例7-13中涉及的方案的具体步骤本领域技术人员可以参考前述实施例(如实施例1-5)的具体描述得到，在实施例7-13中不再赘述。同时，需要说明的是，上述实施例七到实施例十三中装置中涉及的各个单元(或子单元)为逻辑功能上的划分，并不限定这些单元的具体实现方式。例如，这些单元可以基于实施例六中的软硬件结合的架构实现，或者纯软件的架构实现。由于各单元涉及的功能与上述各方法实施例中的方法步骤相对应，因此，本领域技术人员可以根据实施例六中的具体器件来实现各个单元，例如，使用收发器件来实现装置实施例中涉及的一些接收单元。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

上列较佳实施例，对本发明的目的、技术方案和优点进行了进一步详细说明，所应理解的是，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种软件定义网络SDN交换机转发包的方法，其特征在于，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括至少一个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，所述方法包括：

接收来自第一SDN交换机发送的包，所述包为所述第一SDN交换机与SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包包括多个特征信息，其中，所述特征信息与所述精确流表项中的匹配域相对应；

获取所述包中的所述特征信息；

将所述特征信息与所述精确流表中的精确流表项进行精确匹配；如果精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；如果所述通配匹配成功，则按通配匹配成功的精确流表项中的指令对所述包进行转发。

2.如权利要求1所述的方法，其特征在于：

如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；

如果通配匹配不成功，则通过广播转发接收到的所述包。

3.如权利要求1-2任一所述的方法，其特征在于：

所述第二SDN交换机与所述第一SDN交换机、所述SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

4.如权利要求1-2任一所述的方法，其特征在于：

所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

5.一种软件定义网络SDN交换机，其特征在于，所述SDN交换机为第二SDN交换机，所述第二SDN交换机存储有精确流表，所述精确流表包括多个精确流表项，每个精确流表项包括多个匹配域以及与所述多个匹配域对应的指令，所述第二SDN交换机包括：

接收单元，用于接收来自第一SDN交换机发送的包，所述包为所述第一SDN交换机与SDN控制器之间建立的可靠连接所使用的协议对应的包，所述包包括一个或多个特征信息；

获取单元，用于获取所述接收单元接收的包中的所述特征信息；

精确匹配单元，用于将所述获取单元获取的所述一个或多个特征信息与所述精确流表中的精确流表项进行精确匹配，其中，所述一个或多个特征信息与所述精确流表中的所述精确流表项中的匹配域相对应；

通配匹配单元，用于如果所述精确匹配单元执行的精确匹配不成功，则将多个特征信息中的一个或多个特征与所述精确流表中的精确流表项进行通配匹配，其中，通配匹配时用到的一个或多个匹配域对应的指令所确定的转发路由为能够最终到达所述SDN控制器的路由；

转发单元，用于如果所述通配匹配单元执行的通配匹配成功，则按匹配成功的精确流表项中的指令对所述包进行转发。

6.如权利要求5所述的SDN交换机，其特征在于：

如果精确匹配成功，则按匹配成功的精确流表项中的指令进行转发；

如果通配匹配不成功，则通过广播转发。

7.如权利要求5-6任一所述的SDN交换机，其特征在于：

所述第二SDN交换机与所述第一SDN交换机、所述SDN控制器相连，形成SDN网络，所述SDN控制器与各个SDN交换机之间通过带内通信的方式进行通信。

8.如权利要求5-6任一所述的SDN交换机，其特征在于：

所述包用于承载所述第一SDN交换机发送的用于收集路径信息的第一控制消息。

Images