[发明专利]一种报文处理方法及设备

说明书

技术领域

本发明涉及通信技术领域，特别涉及一种报文处理方法。本发明同时还涉及一种报文处理设备。

背景技术

传统路由器，交换机等网络设备，除进行报文转发的功能外，内部还集成了许多软件功能，例如路由计算，报文安全过滤等。由于传统网络方案中所有新的软件功能都只能等待设备提供商的实现，所以存在着业务弹性差，业务更新周期长，用户对设备供应商的依赖强等缺点。

对于以上问题，业界提出了网络SDN（Software Defined Network，软件定义网络）方案，通过对网络设备进行软硬件分离，使硬件网络设备主要只负责报文转发，而路由计算等软件功能都由一个独立的运行在服务器上的网络操作系统完成，并由这个网络操作系统实现对硬件网络设备的控制。作为SDN方案的一种具体实现方法，Openflow在一些场景中得到了应用。

如图1所示，为现有技术中Openflow网络的示意图。Openflow方案中网络操作系统称为Openflow控制器，各个网络设备上运行Openflow agent功能，两者之间建立有隧道，并通过Openflow协议进行交互。Openflow控制器向上提供开发API接口，供用户开发自己的各种应用。

Openflow控制器与网络设备之间主要按照下述方式工作：控制器向网络设备下发流表项，网络设备保存这些流表项信息，当有报文进行转发时，网络设备首先找到匹配这个报文的流表项，网络设备按照流表项定义的规则进行转发。对于没有找到对应流表项的报文，网络设备可以选择丢弃或者把报文转发给控制器处理。控制器可能会根据报文生成新的流表项下发给网络设备，指导后续该类报文的转发，也可能丢弃该报文。

Openflow方案中报文的转发路径如图2所示，在这种情况下报文一般不需要上送至控制器。但在有些情况下，则需要对报文进行进一步处理后才能转发报文。例如在IPS（Intrusion Prevention System，入侵预防系统）处理过程中，报文需要被深度分析。而Openflow网络设备进行这种业务处理的能力有限，这种情况下报文需要被上送控制器处理，具体报文的转发路径如图四所示，报文将一次或多次在设备与控制器之间进行交互。

在设备规模较小的情况下，上送报文至控制器处理所造成的设备负担并不明显，因为Openflow网络设备与控制器之间距离近，连接带宽非常大。报文即使被控制器处理，也不会造成太大的时延或丢包。然而，在广域网场景中，控制器和数据中心距离较远，两者之间的带宽在大部分情况下是比较有限的。如果大量的报文上送控制器进行业务处理，可能会造成报文发送时延过大，丢包等严重问题。

发明内容

为解决现有技术中因业务处理所引起的报文延迟、丢包等问题，本发明提出了一种报文处理方法，所述方法应用于包括控制器、网络设备以及本地业务引擎的本地Openflow网络系统中，所述网络设备与所述本地业务引擎通过指定端口相互连接，还包括：

当首次接收到所述网络设备上报的报文时，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理。

相应地，本发明还提出了一种控制器，所述控制器应用于包括网络设备以及本地业务引擎的本地Openflow网络系统中，包括：

接口模块，用于接收所述网络设备上报的报文，并在首次接收到所述网络设备上报的报文时，将所述报文返回至所述网络设备；

处理模块，用于在所述接口模块首次接收到所述网络设备上报的报文时，指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理；

其中，所述网络设备与所述本地业务引擎通过指定端口相互连接。

通过应用以上技术方案，在首次接收到网络设备上报的报文时，控制器返回该报文并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理，从而避免了报文在上送控制器处理的过程中所可能发生的报文延迟、丢包等问题，使网络业务的处理效率以及实用性得到了优化。

附图说明

图1为现有技术中Openflow网络的应用场景示意图；

图2为现有的Openflow方案中报文转发路径示意图；

图3为现有的Openflow方案中深度处理报文转发路径示意图；

图4为本发明提出的一种报文处理方法的流程示意图；

图5为本发明具体实施例所提出的一种报文处理方法的流程示意图；

图6为本发明具体实施例所提出的Openflow方案深度处理报文转发路径示意图；