CN107968754B - 流表下发方法、接收方法、控制器、交换机及转发系统 - Google Patents

Abstract

本发明公开一种流表下发方法、控制器、交换机及转发系统，涉及通信技术领域，用以解决现有技术中流表下发过程中容易产生流表不一致的问题。所述流表下发方法包括：与交换机协商确定流表发送参数；向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表。

Description

流表下发方法、接收方法、控制器、交换机及转发系统

技术领域

本发明涉及通信技术领域，特别是涉及一种流表下发方法、控制器、交换机及转发系统。

背景技术

SDN(Software-defined networking，软件定义网络)是一种控制逻辑和数据转发分离的创新网络架构，由软件驱动的控制器(Controller)自动化控制转发面设备，它以开放软件的模式替代传统基于嵌入式且不够灵活的控制平面。

OpenFlow是实现SDN的一项重要技术。OpenFlow网络主要由控制器(Controller)和OpenFlow交换机组成：控制器对网络进行集中控制，实现控制层的功能；OpenFlow交换机进行数据层的转发。控制器通过OpenFlow协议来管理OpenFlow交换机，OpenFlow交换机拥有若干个流表(FlowTable)，它只按照流表进行转发，流表的生成、维护和下发由外置的控制器来实现。

在OpenFlow网络中，控制器和OpenFlow交换机之间流表的一致性，是系统可靠性的最为关键的环节。然而，从控制器产生流表，到OpenFlow交换机接收并生效流表，中间要经过多个流程环节，涉及多个组件，容易造成流表不一致。例如：控制器或交换机软件的缺陷造成流表丢失、软件组件之间性能不匹配造成消息丢失、控制器和交换机性能不匹配造成TCP缓存溢出、FlowMod(Flow Table Modification)操作引用的组表/Meter表等关联表项缺失造成FlowMod下发被拒绝等。控制器和交换机之间流表不一致会带来严重后果，可能造成转发面无谓的丢包或网络中断，甚至可能造成整网业务瘫痪，并且无法自动恢复，故障定位也比较困难。

发明内容

本发明要解决的技术问题是提供一种流表下发方法、控制器、交换机及转发系统，用以解决现有技术中流表下发过程中容易产生流表不一致的问题。

一方面，本发明提供一种流表下发方法，包括：与交换机协商确定流表发送参数；向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表。

可选的，所述与所述交换机协商确定流表发送参数包括：向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

可选的，所述控制器的发送能力参数包括：是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。

可选的，所述向所述交换机发送流表并缓存所述流表以等待所述交换机的确认包括：根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

可选的，所述向所述交换机发送流表并缓存所述流表以等待所述交换机的确认还包括：根据流表发送中的重传次数动态调整所述流控阈值。

可选的，所述根据流表发送中的重传次数动态调整所述流控阈值包括：在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。

进一步的，所述方法还包括：如果收到来自所述交换机的流表出错消息，释放或者重传对应的流表。

另一方面，本发明还提供一种流表接收方法，包括：与控制器协商确定所述控制器的流表发送参数；接收来自所述控制器的流表并对所述流表进行处理；根据处理结果向所述控制器反馈。

可选的，所述与控制器协商确定所述控制器的流表发送参数包括：接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

可选的，所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

可选的，所述接收来自所述控制器的流表并对所述流表进行处理包括：接收所述流表并进行识别处理，将识别出的流表写入转发面。

可选的，所述根据处理结果向所述控制器反馈包括：如果处理成功：将所述流表的下发事务信息置入确认消息缓存队列；当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；如果处理失败，向所述控制器发送流表错误消息。

可选的，所述流表确认消息包括至少一个流表的下发事务信息。

另一方面，本发明还提供一种控制器，包括：控制协商单元，用于与交换机协商确定流表发送参数；发送缓存单元，向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；释放单元，用于如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；重传单元，用于如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表。

可选的，所述控制协商单元包括：控制协商发送模块，用于向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；控制协商接收模块，用于从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

可选的，所述发送能力参数包括：是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。

可选的，所述发送缓存单元包括：缓存队列初始化模块，用于根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；消息构造模块，当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；流控阈值确定模块，用于根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；流表发送模块，用于根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

进一步的，所述发送缓存单元还包括：调整模块，用于根据流表发送中的重传次数动态调整所述流控阈值。

可选的，所述调整模块，具体用于：在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。

进一步的，所述控制器还包括：错误处理单元，用于如果收到来自所述交换机的流表出错消息，释放或者重传对应的流表。

另一方面，本发明还提供一种交换机，包括：交换协商单元，用于与控制器协商确定所述控制器的流表发送参数；接收和处理单元，用于接收来自所述控制器的流表并对所述流表进行处理；反馈单元，用于根据所述接收和处理单元对流表的处理结果向所述控制器反馈。

可选的，所述交换协商单元包括：交换协商接收模块，用于接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；交换协商确定模块，用于根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；交换协商发送模块，用于将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

可选的，所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

可选的，所述接收和处理单元，具体用于接收所述流表并进行识别处理，将识别出的流表写入转发面。

可选的，所述反馈单元包括：确认模块，用于如果所述接收和处理单元处理成功：将所述流表的下发事务信息置入确认消息缓存队列；当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；报错模块，用于如果所述接收和处理单元处理失败，向所述控制器发送流表错误消息。

可选的，所述流表确认消息包括至少一个流表的下发事务信息。

另一方面，本发明还提供一种数据转发系统，包括本发明提供的任一种控制器以及任一种交换机。

本发明实施例提供的流表下发方法、接收方法、控制器、交换机及转发系统，能够与交换机协商确定流表发送参数，以便使流表的发送方和接收方都能够在该流表发送参数限定的条件下进行流表发送并等待确认，在收到确认的情况下释放对应流表，在上述条件下如果始终没有收到确认，则重新发送对应流表。这样，每个发送出去的流表都存在对应的确认信息，从而使流表在复杂的转发、生效过程中能够保持一致，有效提高了流表转发性能。

附图说明

图1是本发明实施例提供的流表下发方法的一种流程图；

图2是本发明实施例提供的流表接收方法的一种流程图；

图3是本发明实施例中流表下发和接收的一种示意图；

图4是本发明实施例提供的流表下发和接收方法的一种流程图；

图5是本发明实施例中能力协商消息和流表确认消息格式示意图；

图6是本发明实施例中的控制器发送缓存示意图；

图7是本发明实施例中的交换机接收缓存示意图；

图8是本发明实施例中流表下发和接收方法所基于的系统的一种结构示意图；

图9是本发明实施例提供的控制器的一种结构示意图；

图10是本发明实施例提供的交换机的一种结构示意图。

具体实施方式

以下结合附图对本发明进行详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

如图1所示，本发明实施例提供一种流表下发方法，基于控制器，包括：

S11，与交换机协商确定流表发送参数；

S12，向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；

S13，如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表。

本发明实施例提供的流表下发方法，能够与交换机协商确定流表发送参数，以便使流表的发送方和接收方都能够在该流表发送参数限定的条件下进行流表发送并等待确认，在收到确认的情况下释放对应流表，在上述条件下如果始终没有收到确认，则重新发送对应流表。这样，每个发送出去的流表都存在对应的确认信息，从而使流表在复杂的转发、生效过程中能够保持一致，有效提高了流表转发性能。

可选的，在步骤S11中，与所述交换机协商确定流表发送参数可包括：

向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；

从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

具体而言，流表转发可基于OpenFlow流程。OpenFlow连接启动，控制器和交换机双方交互HELLO消息协商协议版本号之后，控制器可以发送流表可靠性请求消息，例如自定义的OFP_EX_FLOW_RELIABILITY_REQUEST请求消息，携带控制器本身的发送能力参数，请求与交换机协商流表确认机制的处理能力。

如果交换机能识别该消息，并且支持流表确认机制，则取出能力参数，与自身能力比较，得到双方都能承受的能力参数，发送流表可靠性应答消息，例如自定义的OFP_EX_FLOW_RELIABILITY_REPLY回应消息，在流表可靠性应答消息中携带协商的所述流表发送参数。

如果交换机无法识别该消息，可以反馈流表出错消息。如果控制器收到来自所述交换机的流表出错消息，则可以根据具体情况，释放或者重传对应的流表。

可选的，控制器的发送能力参数可包括：是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间等。相应的，控制器接收到的协商后的流表发送参数也可以包括上述内容及其相关内容。其中，支持的流表操作类型可以包括OFPT_FLOW_MOD、OFPT_GROUP_MOD、OFPT_METER_MOD等流表操作消息中的一种或多种。

协商好流表发送参数后，即可在步骤S12中向所述交换机发送流表并缓存所述流表以等待所述交换机的确认。可选的，在本发明的一个实施例中，步骤S12具体可包括如下步骤：

根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；

当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；

根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；

根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

本实施例中，为了便于对流表进行管理，将待发送的流表与已发送待确认的流表分开缓存，并且对两个缓存队列维持动态平衡，以便利用合理的资源使流表能够被高效的发送和确认。可选的，流控阈值需要小于或等于相应的流表发送参数，当所述待发送消息缓存队列占用率较高，且待确认消息缓存队列的占用率较低时，说明待发送的流表较多，且没有太多流表在等待确认，则可以将流控阈值设置成比较大的值；当待发送消息缓存队列占用率较低，且待确认消息缓存队列的占用率较高时，说明此时没有太多需要发送的流表，但有很多流表的确认消息还在路上，尚未被确认，为了减轻流表确认消息和缓存队列的压力，此时发送的流表数量也不宜过多，流控阈值可以设置成比较小的值。

进一步的，确定好流控阈值后，还可以根据流表发送中的重传次数动态调整所述流控阈值，以便随时调整流表发送。可选的，可以在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。当然，也可以按照其他方案调节，本发明的实施例对此不作限定。

相应的，如图2所示，本发明的实施例还提供一种流表接收方法，基于交换机，包括：

S21，与控制器协商确定所述控制器的流表发送参数；

S22，接收来自所述控制器的流表并对所述流表进行处理；

S23，根据处理结果向所述控制器反馈。

本发明实施例提供的流表接收方法，能够与控制器协商确定所述控制器的流表发送参数，接收来自所述控制器的流表并对所述流表进行处理，并根据处理结果向所述控制器反馈。这样，交换机能够将接收到的每个流表反馈给控制器，从而使流表在复杂的转发、生效过程中能够保持一致，有效提高了流表转发性能。

可选的，步骤S21中，与控制器协商确定所述控制器的流表发送参数可包括：

接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；

根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；

将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

可选的，所述流表发送参数可包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间等。

具体而言，交换机回应的可靠性应答消息，例如，OFP_EX_FLOW_RELIABILITY_REPLY消息，可以采用与控制器端发送的流表可靠性请求消息OFP_EX_FLOW_RELIABILITY_REQUEST具有相同或不同的消息结构。交换机在根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数时，回应消息携带的流表发送参数代表的能力不能超过控制器请求消息中携带的能力，即：交换机回应的所能支持确认机制的流表操作类型，需要是控制器所能支持的类型的子集；交换机回应的最大延迟确认消息数量，需要小于等于控制器支持的最大延迟确认消息数量；交换机回应的最大延迟确认时间，需要小于等于控制器支持的最大延迟确认时间。

与控制器协商好流表发送参数后，即可在步骤S22中接收来自所述控制器的流表并对所述流表进行处理。具体的，可以接收所述流表并进行识别处理，将识别出的流表写入转发面。

具体的，在步骤S23中，根据处理结果向所述控制器反馈可包括处理成功和处理失败两种情况。可选的，如果处理成功，则可以将所述流表的下发事务信息置入确认消息缓存队列；当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送。可选的，所述流表确认消息包括一个或多个流表的下发事务信息。如果处理失败，则可以向所述控制器发送流表错误消息。

下面通过具体实施例对本发明提供的流表下发方法和接收方法进行详细说明。

图3是本发明实施例中的消息交互示意图。如图3所示，流表确认机制的能力协商消息，由控制器发送的OFP_EX_FLOW_RELIABILITY_REQUEST请求消息和交换机回应的OFP_EX_FLOW_RELIABILITY_REPLY消息组成。流表确认机制，是在控制器发送若干个流表消息后，交换机才延迟发送一个确认消息，其中包含对前面若干个流表消息的确认。控制器可以在需要的时候发起能力协商，可以动态调整能力协商参数，也可以动态请求开启或关闭确认机制。

如图4所示，本实施例提供的流表下发和接收方法可包括以下步骤：

301，OpenFlow连接启动，双方交互HELLO消息协商协议版本号之后，控制器发送自定义的OFP_EX_FLOW_RELIABILITY_REQUEST请求消息，携带相应的发送能力参数，请求协商流表确认机制的处理能力。

可选的，发送能力参数可包括：是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。其中支持的流表操作类型，可以是OFPT_FLOW_MOD、OFPT_GROUP_MOD、OFPT_METER_MOD等流表操作消息中的一种或多种。

控制器可以在需要的时候进行能力协商，例如在首次发送流表前，或者发送一段时间的流表之后；控制器可以调整能力协商参数，例如在开启了一段时间的确认机制后，控制器请求关闭确认机制。

302，如果交换机无法识别该自定义的OFP_EX_FLOW_RELIABILITY_REQUEST请求消息，则回应OFPT_ERROR消息。

交换机无法识别该自定义的OFP_EX_FLOW_RELIABILITY_REQUEST请求消息时，按照OpenFlow协议的规定回应OFPT_ERROR消息，控制器收到该OFPT_ERROR消息，知晓该交换机不支持流表确认机制，可以按传统方式(即不支持确认机制的方式)发送流表。

需要说明的是，控制器管理的多个交换机，对于流表确认机制，如果有部分支持而部分不支持，控制器可以全部按传统方式发送流表(此时对于已协商过确认机制的交换机需要重新请求关闭确认机制)，也可以对不同的交换机按不同的方式发送流表。

303a，如果交换机能识别该消息，并且支持流表确认机制，则取出能力参数，与自身能力比较，得到双方都能承受的能力参数，初始化本端应答消息缓存队列，303b，发送自定义的OFP_EX_FLOW_RELIABILITY_REPLY回应消息，。

交换机回应的OFP_EX_FLOW_RELIABILITY_REPLY消息，可以采用与步骤301中OFP_EX_FLOW_RELIABILITY_REQUEST请求消息相同的消息结构。回应消息携带的能力不能超过控制器请求消息携带的能力，即：交换机回应的所能支持确认机制的流表操作类型，需要是控制器所能支持的类型的子集；交换机回应的最大延迟确认消息数量，需要小于等于控制器支持的最大延迟确认消息数量；交换机回应的最大延迟确认时间，需要小于等于控制器支持的最大延迟确认时间。

304，控制器收到交换机的OFP_EX_FLOW_RELIABILITY_REPLY回应消息，取出能力参数，初始化本端发送消息缓存队列。

控制器需要对交换机回应消息及携带的参数进行合法性检查，检查交换机回应的参数是否满足上述条件。可选的，控制器初始化发送缓存队列时，可以按照不同的流表操作类型部署不同的缓存队列，也可以只部署一个公共的缓存队列。

305a，控制器有流表下发时，构造消息并置入发送消息缓存队列，305b，按照协商后的流表确认能力发送一定数量的流表，等待交换机的应答确认。

可选的，控制器可以根据发送缓存队列的动态占用情况控制流表下发速率。

306a，交换机收到流表下发消息后进行识别处理，并写入转发面，如果处理失败或写表失败，则回应OFPT_ERROR消息；306b，如果处理并写表成功，则将该流表下发消息的事务信息置入应答消息缓存队列；306c，累积到一定数量的应答消息或延迟一段时间后，合并到一个自定义的OFP_EX_FLOW_MESSAGE_ACK确认消息中，送控制器。

对于协商支持确认机制的流表类型，交换机收到流表消息后，都可以生成回应消息(OFPT_ERROR消息或流表确认消息)。交换机延迟确认时，只要待确认的流表消息数量达到最大延迟流表消息数量，或者延迟的时间达到最大延迟时间，或者其他预先设定的数量或时间，则交换机就可以将缓冲队列中所有延迟确认的消息都打包到OFP_EX_FLOW_MESSAGE_ACK确认消息中送控制器。

307，控制器收到OFP_EX_FLOW_MESSAGE_ACK确认消息后，解包得到多个流表下发消息的事务ID，将对应流表消息从发送缓存中释放。

可选的，确认消息中携带有待确认的流表操作类型和事务ID。控制器收到的确认消息中包含一个或多个待确认流表消息。

308，控制器收到OFPT_ERROR消息后，根据差错情况决定是否立即重传流表，或者将对应流表消息从发送消息缓存中释放。

控制器收到OFPT_ERROR消息后的处理，遵循OpenFlow协议的约定，根据不同情况做不同的处理：若需要重传，则从发送缓存中取出消息重传；对于不需要重传的，可以从发送缓存中将对应消息释放。

309，控制器发送流表消息一段时间后，如果未收到交换机的确认，则控制器需重传未确认的流表。

可选的，控制器等待交换机确认的这段时间应该小于或等于最大延迟确认时间。控制器每次发送流表消息后，可以设置延迟定时器等待确认消息，延迟定时器超时，则进行重传处理，如果所有发送消息都已被确认，则关闭延迟定时器。

图5是本发明实施例提供的能力协商消息和流表确认消息格式示意图。如图5所示，能力协商消息和流表确认消息，可以采用OpenFlow协议定义的OFPT_EXPERIMENTER消息，该消息适用于各厂商和组织自定义消息格式。

消息头定义

struct ofp_experimenter_header{

struct ofp_header header；/*ofpt_experimenter*/

uint32_t experimenter；/*厂商组织标识符

*MSB 0：低位字节由IEEE OUI定义

*MSB！＝0：由ONF定义的*/

uint32_t exp_type；/*自定义消息类型*/

/*自定义任意附加数据*/

}；

OFP_ASSERT(sizeof(struct ofp_experimenter_header)＝＝16)；

其中：experimenter字段为4字节，标识厂商组织的EXPERIMENTER消息：如果首字节为0，则其他3个字节采用IEEE OUI(组织唯一标识符，由IEEE分配给各厂商和组织)；如果首字节不为0，则采用ONF分配的一个值。如果本技术使用者没有自己的OUI或ONF值，可以向IEEE或ONF申请，也可以自己定义一个值。

exp_type是自定义消息类型，这里定义为流表确认机制的能力协商消息和流表确认消息。

能力协商的消息体定义

流表确认机制的能力协商请求消息OFP_EX_FLOW_RELIABILITY_REQUEST和回应消息OFP_EX_FLOW_RELIABILITY_REPLY，采用相同的消息体结构：

struct ofp_flow_reliability{

uint32_t flag；/*功能开关标记：0-关闭，1-开启*/

uint8_t ofp_type[8]；/*支持的流表操作类型*/

uint32_t max_ack_count；/*最大延迟确认消息数量*/

uint32_t max_delay_time；/*最大延迟确认时间，单位毫秒*/

}；

OFP_ASSERT(sizeof(ofp_flow_reliability)＝＝12)；

流表确认消息

流表确认消息OFP_EX_FLOW_MESSAGE_ACK，由若干个如下的信息结构组合而成：

struct ofp_flow_msg_ack{

uint8_t ofp_type；/*确认的流表操作类型*/

uint8_t pad[3]；

uint32_t xid；/*确认的事务ID*/

}；

OFP_ASSERT(sizeof(ofp_flow_msg_ack)＝＝8)。

图6是本实施例中的控制器发送缓存示意图。如图6所示，发送缓存由“待发送队列”和“已发送待确认队列”两个队列构成。

控制器有流表下发时，流表发送单元将待发送流表置入“待发送队列”，判断“已发送待确认队列”中消息数量是否超过流控阈值：如果没有超过，则将从“待发送队列”取出对应数量的流表消息进行发送，并移入“已发送待确认队列”；如果已超过，则暂不发送。

流控阈值参照TCP协议的发送窗口计算算法，依据最大延迟确认消息数量及当前重传情况进行调整，例如：没有重传情况时，流控阈值为每次发送增加一个消息；一旦发送重传，流控阈值指数退避，减为原值的一半；流控阈值最大值＝最大延迟确认数量×2，最小值为1。

控制器收到交换机的确认消息，则将对应流表操作消息从“已发送待确认队列”中移除。控制器设置重传延迟定时器，定时扫描“已发送待确认队列”，对已发送但未确认超过延迟时间的流表消息重新发送。

图7是本发明实施例中的交换机接收缓存示意图。如图7所示，接收缓存由“已接收待确认队列”构成。交换机对于已接收并正确处理的流表，生成流表确认信息，置入已“已接收待确认队列”，同时设置延迟确认定时器。当延迟确认定时器超时，或者“已接收待确认队列”中的数量超过最大流表确认数量，则发送流表确认消息。

可选的，交换机发送流表确认消息时，每次可以将“已接收待确认队列”中的信息都封装合并到一个确认消息中发送出去。每个流表确认消息OFP_EX_FLOW_MESSAGE_ACK，可以包含多个流表操作信息结构ofp_flow_msg_ack。

上述流表下发和接收方法所基于的系统可如图8所示。如图8所示，本发明提供的实现OpenFlow流表一致性的系统，涉及控制器Controller和OpenFlow交换机两部分。

控制器Controller包括：

业务应用单元，用于进行拓扑、链路、路由、DHCP、ARP等业务处理，生成各种转发面流表；

流表管理单元，用于接收各种业务应用产生的流表，对流表进行分类管理和存储，并进行流表的下发处理；

流表发送单元，用于管理流表发送缓存队列，并设置延迟定时器进行重传扫描；

设备驱动单元，用于对不同的交换机设备进行驱动处理，包括：设备的接入状态和端口资源管理、流表流水线的协商和适配；

OF协议单元，用于OpenFlow协议的编解码，调用操作系统的TCP SOCKET接口进行报文收发。

OpenFlow交换机包括：

OF协议单元，用于OpenFlow协议的编解码，调用操作系统的TCP SOCKET接口进行报文收发；

流表接收单元，用于管理流表确认缓存队列，设置延迟定时器进行扫描，发送流表确认消息；

流表管理单元，用于接收流表，对流表进行分类管理和存储，并将流表写入转发面芯片。

在OpenFlow协商阶段，控制器的OF协议单元和交换机的OF协议单元之间进行流表确认机制的能力协商。

在流表下发阶段，控制器上：业务应用单元的业务生成各种流表下发流表管理单元；流表管理单元对流表进行分类管理和存储，调用流表发送单元准备发送；流表发送单元将待发送流表置入发送缓存，通过拥塞控制和重传机制进行发送；设备驱动单元则对下发流表进行适配处理，处理后的流表送OF协议单元进行OpenFlow协议编码；OF协议单元将编码后的OpenFlow协议报文写入TCP发送缓存。在OpenFlow交换机上：OF协议单元收到OpenFlow协议报文后，进行解码得到流表操作消息，送流表接收单元；流表接收单元判断流表合法后，将流表送管理单元，同时生成流表确认消息置入缓存队列，设置延迟定时器延迟发送流表确认消息；流表送管理单元存储流表并写入转发面。

本实施例通过扩展OpenFlow协议，通过扩展OpenFlow协议，引入流表延迟确认机制，在仅仅增加很少量的确认消息的情况下，保证流表传输的可靠性和一致性，避免控制器和交换机流表数据不一致造成网络故障和转发面失效。同时，本发明所述的方法和系统，兼容其他设备和系统，具有很强的部署灵活性和实用性。

相应的，如图9所示，本发明实施例还提供一种控制器，包括：

控制协商单元41，用于与交换机协商确定流表发送参数；

发送缓存单元42，向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；

释放单元43，用于如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；

重传单元44，用于如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表。

本发明实施例提供的控制器，能够与交换机协商确定流表发送参数，以便使流表的发送方和接收方都能够在该流表发送参数限定的条件下进行流表发送并等待确认，在收到确认的情况下释放对应流表，在上述条件下如果始终没有收到确认，则重新发送对应流表。这样，每个发送出去的流表都存在对应的确认信息，从而使流表在复杂的转发、生效过程中能够保持一致，有效提高了流表转发性能。

可选的，所述控制协商单元41包括：

控制协商发送模块，用于向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；

控制协商接收模块，用于从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

可选的，发送能力参数包括：是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。

可选的，发送缓存单元42包括：

缓存队列初始化模块，用于根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；

消息构造模块，当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；

流控阈值确定模块，用于根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；

流表发送模块，用于根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

进一步的，发送缓存单元42还包括：调整模块，用于根据流表发送中的重传次数动态调整所述流控阈值。

具体的，所述调整模块，具体可用于：在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。

进一步的，本发明实施例提供的控制器，还可包括：错误处理单元，用于如果收到来自所述交换机的流表出错消息，释放或者重传对应的流表。

相应的，如图10所示，本发明实施例还提供一种交换机，包括：

交换协商单元51，用于与控制器协商确定所述控制器的流表发送参数；

接收和处理单元52，用于接收来自所述控制器的流表并对所述流表进行处理；

反馈单元53，用于根据所述接收和处理单元对流表的处理结果向所述控制器反馈。

本发明实施例提供的交换机，能够与控制器协商确定所述控制器的流表发送参数，接收来自所述控制器的流表并对所述流表进行处理，并根据处理结果向所述控制器反馈。这样，交换机能够将接收到的每个流表反馈给控制器，从而使流表在复杂的转发、生效过程中能够保持一致，有效提高了流表转发性能。

可选的，交换协商单元51可包括：

交换协商接收模块，用于接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；

交换协商确定模块，用于根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；

交换协商发送模块，用于将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

可选的，所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

可选的，接收和处理单元52，具体可用于接收所述流表并进行识别处理，将识别出的流表写入转发面。

可选的，反馈单元53可具体包括：

确认模块，用于如果所述接收和处理单元处理成功：将所述流表的下发事务信息置入确认消息缓存队列；当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；

报错模块，用于如果所述接收和处理单元处理失败，向所述控制器发送流表错误消息。

可选的，流表确认消息可包括至少一个流表的下发事务信息。

相应的，本发明的实施例还提供一种数据转发系统，包括前述实施例提供的任一种控制器以及任一种交换机，因此也能实现相应的技术效果，前文已经进行了详细的说明，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (23)

1.一种流表下发方法，其特征在于，包括：

与交换机协商确定流表发送参数；

向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；

如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；交换机发送的所述流表确认消息包括：所述交换机接收到所述流表，并进行识别处理，将识别出的流表写入转发面，识别处理并写表成功后发送所述流表确认消息；

如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表；所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

2.根据权利要求1所述的方法，其特征在于，所述与所述交换机协商确定流表发送参数包括：

向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；

从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

3.根据权利要求2所述的方法，其特征在于，所述控制器的发送能力参数包括：

是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。

4.根据权利要求1所述的方法，其特征在于，所述向所述交换机发送流表并缓存所述流表以等待所述交换机的确认包括：

根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；

当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；

根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；

根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

5.根据权利要求4所述的方法，其特征在于，所述向所述交换机发送流表并缓存所述流表以等待所述交换机的确认还包括：

根据流表发送中的重传次数动态调整所述流控阈值。

6.根据权利要求5所述的方法，其特征在于，所述根据流表发送中的重传次数动态调整所述流控阈值包括：

在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。

7.根据权利要求1至6中任一项所述的方法，其特征在于，还包括：

如果收到来自所述交换机的流表出错消息，释放或者重传对应的流表。

8.一种流表接收方法，其特征在于，包括：

与控制器协商确定所述控制器的流表发送参数；

接收来自所述控制器的流表并对所述流表进行处理；所述接收来自所述控制器的流表并对所述流表进行处理包括：接收所述流表并进行识别处理，将识别出的流表写入转发面；

根据处理结果向所述控制器反馈；所述根据处理结果向所述控制器反馈包括：当对所述流表识别处理并写表成功时，将流表确认消息发送给所述控制器；如果所述控制器在流表发送参数限定的条件范围内收到所述流表确认消息，所述控制器释放所述流表；如果所述控制器在流表发送参数限定的条件范围内没有收到所述流表确认消息，重新发送所述流表；所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

9.根据权利要求8所述的方法，其特征在于，所述与控制器协商确定所述控制器的流表发送参数包括：

接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；

根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；

将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

10.根据权利要求8至9中任一项所述的方法，其特征在于，所述根据处理结果向所述控制器反馈包括：

如果处理成功：

将所述流表的下发事务信息置入确认消息缓存队列；

当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；

如果处理失败，向所述控制器发送流表错误消息。

11.根据权利要求10所述的方法，其特征在于，所述流表确认消息包括至少一个流表的下发事务信息。

12.一种控制器，其特征在于，包括：

控制协商单元，用于与交换机协商确定流表发送参数；

发送缓存单元，向所述交换机发送流表并缓存所述流表以等待所述交换机的确认；

释放单元，用于如果在流表发送参数限定的条件范围内收到来自所述交换机的流表确认消息，释放所述流表；交换机发送的所述流表确认消息包括：所述交换机接收到所述流表，并进行识别处理，将识别出的流表写入转发面，识别处理并写表成功后发送所述流表确认消息；

重传单元，用于如果在流表发送参数限定的条件范围内没有收到来自所述交换机的流表确认消息，重新发送所述流表；所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

13.根据权利要求12所述的控制器，其特征在于，所述控制协商单元包括：

控制协商发送模块，用于向所述交换机发送流表可靠性请求消息，所述流表可靠性请求消息中携带控制器本身的发送能力参数以与所述交换机进行参数协商；

控制协商接收模块，用于从所述交换机接收流表可靠性应答消息，所述流表可靠性应答消息中携带协商的所述流表发送参数。

14.根据权利要求13所述的控制器，其特征在于，所述发送能力参数包括：

是否启用流表确认机制的功能开关、支持的流表操作类型、最大延迟确认消息数量和最大延迟确认时间。

15.根据权利要求12所述的控制器，其特征在于，所述发送缓存单元包括：

缓存队列初始化模块，用于根据所述流表发送参数初始化待发送消息缓存队列和待确认消息缓存队列；

消息构造模块，当出现需要下发的流表时，构造相应的消息并置入所述待发送消息缓存队列；

流控阈值确定模块，用于根据所述流表发送参数、所述待发送消息缓存队列的占用情况以及所述待确认消息缓存队列的占用情况，确定流表发送的流控阈值；

流表发送模块，用于根据所述流控阈值的控制向所述交换机发送流表，并将发送后的所述流表移入所述待确认消息缓存队列。

16.根据权利要求15所述的控制器，其特征在于，所述发送缓存单元还包括：调整模块，用于根据流表发送中的重传次数动态调整所述流控阈值。

17.根据权利要求16所述的控制器，其特征在于，所述调整模块，具体用于：

在没有重传情况时，所述流控阈值随每次发送操作而加一；每发生一次重传，所述流控阈值减为原值的一半。

18.根据权利要求12至17中任一项所述的控制器，其特征在于，还包括：

错误处理单元，用于如果收到来自所述交换机的流表出错消息，释放或者重传对应的流表。

19.一种交换机，其特征在于，包括：

交换协商单元，用于与控制器协商确定所述控制器的流表发送参数；

接收和处理单元，用于接收来自所述控制器的流表并对所述流表进行处理；所述接收和处理单元，具体用于接收所述流表并进行识别处理，将识别出的流表写入转发面；

反馈单元，用于根据所述接收和处理单元对流表的处理结果向所述控制器反馈；所述反馈单元，具体用于当对所述流表识别处理并写表成功时，将流表确认消息发送给所述控制器；如果所述控制器在流表发送参数限定的条件范围内收到所述流表确认消息，所述控制器释放所述流表；如果所述控制器在流表发送参数限定的条件范围内没有收到所述流表确认消息，重新发送所述流表；所述流表发送参数包括：协商支持的流表操作类型、协商最大延迟确认消息数量和协商最大延迟确认时间。

20.根据权利要求19所述的交换机，其特征在于，所述交换协商单元包括：

交换协商接收模块，用于接收来自所述控制器的流表可靠性请求消息，所述流表可靠性请求消息中携带所述控制器的发送能力参数；

交换协商确定模块，用于根据所述发送能力参数以及交换机本身的接收能力参数，协商确定所述流表发送参数；

交换协商发送模块，用于将所述流表发送参数携带在可靠性应答消息中向所述控制器发送。

21.根据权利要求19至20中任一项所述的交换机，其特征在于，所述反馈单元包括：

确认模块，用于如果所述接收和处理单元处理成功：将所述流表的下发事务信息置入确认消息缓存队列；当所述确认消息缓存队列中的下发事务信息的数量超过预设数量阈值时，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；或者延迟预设时间后，将所有所述下发事务信息打包成一个流表确认消息向所述控制器发送；

报错模块，用于如果所述接收和处理单元处理失败，向所述控制器发送流表错误消息。

22.根据权利要求21所述的交换机，其特征在于，所述流表确认消息包括至少一个流表的下发事务信息。

23.一种数据转发系统，其特征在于，包括权利要求12至18中任一项所述的控制器以及权利要求19至22中任一项所述的交换机。

Images