一种报文处理方法及设备的制作方法
【专利摘要】本发明公开了一种报文处理方法，在首次接收到网络设备上报的报文时，控制器返回该报文并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理，从而避免了报文在上送控制器处理的过程中所可能发生的报文延迟、丢包等问题，使网络业务的处理效率以及实用性得到了优化。
【专利说明】一种报文处理方法及设备
【技术领域】
[0001]本发明涉及通信【技术领域】，特别涉及一种报文处理方法。本发明同时还涉及一种报文处理设备。
【背景技术】
[0002]传统路由器，交换机等网络设备，除进行报文转发的功能外，内部还集成了许多软件功能，例如路由计算，报文安全过滤等。由于传统网络方案中所有新的软件功能都只能等待设备提供商的实现，所以存在着业务弹性差，业务更新周期长，用户对设备供应商的依赖强等缺点。
[0003]对于以上问题,业界提出了网络SDN(Software Defined Network,软件定义网络)方案，通过对网络设备进行软硬件分离，使硬件网络设备主要只负责报文转发，而路由计算等软件功能都由一个独立的运行在服务器上的网络操作系统完成，并由这个网络操作系统实现对硬件网络设备的控制。作为SDN方案的一种具体实现方法，Openflow在一些场景中得到了应用。
[0004]如图1所示，为现有技术中Openflow网络的示意图。Openflow方案中网络操作系统称为Openflow控制器,各个网络设备上运行Openflow agent功能,两者之间建立有隧道，并通过Openflow协议进行交互。Openflow控制器向上提供开发API接口，供用户开发自己的各种应用。
[0005]Openflow控制器与网络设备之间主要按照下述方式工作:控制器向网络设备下发流表项，网络设备保存这些流表项信息，当有报文进行转发时，网络设备首先找到匹配这个报文的流表项，网络设备按照流表项定义的规则进行转发。对于没有找到对应流表项的报文，网络设备可以选择丢弃或者把报文转发给控制器处理。控制器可能会根据报文生成新的流表项下发给网络设备，指导后续该类报文的转发，也可能丢弃该报文。
[0006]Openflow方案中报文的转发路径如图2所示，在这种情况下报文一般不需要上送至控制器。但在有些情况下，则需要对报文进行进一步处理后才能转发报文。例如在IPS(Intrusion Prevention System,入侵预防系统)处理过程中，报文需要被深度分析。而Openflow网络设备进行这种业务处理的能力有限，这种情况下报文需要被上送控制器处理，具体报文的转发路径如图四所示，报文将一次或多次在设备与控制器之间进行交互。
[0007]在设备规模较小的情况下，上送报文至控制器处理所造成的设备负担并不明显，因为Openflow网络设备与控制器之间距离近，连接带宽非常大。报文即使被控制器处理，也不会造成太大的时延或丢包。然而，在广域网场景中，控制器和数据中心距离较远，两者之间的带宽在大部分情况下是比较有限的。如果大量的报文上送控制器进行业务处理，可能会造成报文发送时延过大，丢包等严重问题。
【发明内容】
[0008]为解决现有技术中因业务处理所引起的报文延迟、丢包等问题，本发明提出了一种报文处理方法，所述方法应用于包括控制器、网络设备以及本地业务引擎的本地Openflow网络系统中，所述网络设备与所述本地业务引擎通过指定端口相互连接，还包括:
[0009]当首次接收到所述网络设备上报的报文时，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理。
[0010]相应地，本发明还提出了一种控制器，所述控制器应用于包括网络设备以及本地业务引擎的本地Openflow网络系统中，包括:
[0011]接口模块，用于接收所述网络设备上报的报文，并在首次接收到所述网络设备上报的报文时，将所述报文返回至所述网络设备；
[0012]处理模块，用于在所述接口模块首次接收到所述网络设备上报的报文时，指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理；
[0013]其中，所述网络设备与所述本地业务弓I擎通过指定端口相互连接。
[0014]通过应用以上技术方案，在首次接收到网络设备上报的报文时，控制器返回该报文并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理，从而避免了报文在上送控制器处理的过程中所可能发生的报文延迟、丢包等问题，使网络业务的处理效率以及实用性得到了优化。
【专利附图】
【附图说明】
[0015]图1为现有技术中Openflow网络的应用场景示意图；
[0016]图2为现有的Openflow方案中报文转发路径示意图；
[0017]图3为现有的Openflow方案中深度处理报文转发路径示意图；
[0018]图4为本发明提出的一种报文处理方法的流程示意图；
[0019]图5为本发明具体实施例所提出的一种报文处理方法的流程示意图；
[0020]图6为本发明具体实施例所提出的Openflow方案深度处理报文转发路径示意图；
[0021]图7为本发明提出的一种控制器的结构示意图。
【具体实施方式】
[0022]如【背景技术】所述，针对广域网场景下由大量报文上送控制器处理所导致的丢包，延迟等问题。本发明提出了一种报文处理方法，用以解决因业务处理所引起的报文延迟、丢包等问题，从而优化了现有网络中的业务处理效率。具体地，该方法应用于包括控制器、网络设备以及本地业务引擎的本地Openflow网络系统中，其中网络设备与本地业务引擎通过指定端口相互连接，如图4所示，包括以下步骤:
[0023]S401，当首次接收到所述网络设备上报的报文时，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理。
[0024]本发明在现有网络架构的基础上增设本地业务引擎，该本地业务引擎可运行在一台服务器上，并与Openflow网络中的网络设备放在一起，并用带宽连接。引入该引擎后，本来需要上送控制器进行业务处理的报文可转发给这个引擎处理，引擎处理完成后，再发回给网络设备，进行后续的处理。由于本地业务引擎与网络设备物理位置在一起，并用高速链路连接，不会因为对报文的业务处理造成额外的延迟或丢包。
[0025]具体地，在首次接收到所述网络设备上报的报文时，控制器下发流表项，该流表项用于指示所述网络设备将所述需要上报的报文通过所述指定端口发送至所述本地业务引擎，以及将从所述指定端口返回的报文进行转发；而为了保证后续正常通信以及执行控制器的功能，本发明设置本地业务引擎通过建立隧道与所述网络设备进行数据传输，并利用Echo对网络连接和设备可用性进行探测。
[0026]此外，在控制器首次接收到所述网络设备上报的报文之后，还需要对指定端口的状态进行检测:若所述指定端口的状态为可用，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理；若所述指定端口的状态为不可用，所述控制器对所述上报的报文进行处理。
[0027]具体的，控制器通过以下方式判断所述本地业务引擎是否可用:
[0028]控制器判断所述网络设备是否存在所述指定端口 ；
[0029]若所述网络设备存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路正常，所述控制器确定所述指定端口的状态为可用；
[0030]所述网络设备不存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路异常，所述控制器确定所述指定端口的状态为不可用。
[0031]需要指出的是，本发明中的所提出的本地业务引擎可依据实际情况选择是否需要维护全局拓扑等数据，因为本地业务引擎主要功能(例如进行IPS处理)的实现仅需要维护本地业务数据(例如IPS特征库，用于识别攻击和病毒等)即可。因而本地业务引擎可选择性地与控制器进行周期数据同步。
[0032]为了进一步阐述本发明的技术思想，现结合具体的应用场景，对本发明的技术方案进行说明，如图5所述，为本发明具体实施例所提出的一种报文处理方法的流程示意图，其对应的Openflow方案深度处理报文转发路径示意图如图5所示，包括以下步骤:
[0033]S501，控制器从网络设备接收第一个需要处理的报文。
[0034]S502，控制器查看是否有本地业务引擎可用，若是则转至S504，若否则转至S503。
[0035]在该具体实施例中，通过在Openflow的规范定义中为reserved port (保留端口)增加一种L0CAL_ENGINE类型的端口，该端口与控制器类型的端口比较类似，属于比较特殊的Openflow端口。网络设备通过这个端口和本地业务引擎连接，但为了避免了因为本地业务引擎的引入影响网络原来的拓扑，这条链路并不反映在Openflow的网络拓扑上。
[0036]在控制器查询网络设备的端口状态时，控制器需要确认是否存在L0CAL_ENINGE端口，并且这个端口是否up。如果该端口 up，控制器就会认为该本地业务引擎可用；相应地，当网络设备发现本地业务引擎或连接链路不可用，就将L0CAL_ENGINE端口的状态置为down。
[0037]S503，控制器不进行进一步的业务处理，将该报文发回网络设备。
[0038]S504，控制器下发流表项。
[0039]具体的，控制器下发两条流表项，一条用于指导该报文及后续报文都会被转发L0CAL_ENGINE端口，另一条用于指导经过本地业务引擎处理，从L0CAL_ENGINE返回的报文，进行后续的转发，离开该设备。
[0040]S505,网络设备和本地业务引擎根据流表项对上报报文进行处理。[0041]在本地业务引擎方案中，后续报文到来后，根据流表项，直接被转发到L0CAL_ENINGE端口，给本地业务引擎处理，处理完的报文，从L0CAL_ENINGE端口返回会，根据匹配的流表项进行后续转发。网络设备和本地业务引擎之间的数据交换方式，借用控制器和网络设备之间的Packet-1n和Packet-out消息。
[0042]其中，本地业务引擎只需要实现控制器的隧道建立功能，用于和网络设备传送数据，和Echo功能，用于探测了网络连接和设备的可用性。
[0043]需要说明的是，本发明中本地业务引擎还需要支持Openflow Packet-out消息,用于将处理后的报文发回给网络设备。同时，网络设备需要支持使用Openflow Packet-1n消息将报文通过L0CAL_ENGINE端口发送给本地业务引擎。
[0044]S506，控制器对上报的报文进行后续处理。
[0045]为达到以上技术目的，如图7所示，本发明还提出了一种控制器，所述控制器应用于包括网络设备以及本地业务引擎的本地Openflow网络系统中，包括:
[0046]接口模块710，用于接收所述网络设备上报的报文，并在首次接收到所述网络设备上报的报文时，将所述报文返回至所述网络设备；
[0047]处理模块720，用于在所述接口模块710首次接收到所述网络设备上报的报文时，指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理；
[0048]其中，所述网络设备与所述本地业务弓I擎通过指定端口相互连接。
[0049]在具体的应用场景中，所述处理模块720，具体用于下发流表项，所述流表项用于指示所述网络设备将所述需要上报的报文通过所述指定端口发送至所述本地业务引擎，以及将从所述指定端口返回的报文进行转发。
[0050]在具体的应用场景中，还包括:
[0051]检测模块730，用于在所述接口模块710首次接收到所述网络设备上报的报文之后，对所述指定端口的状态进行检测；
[0052]若所述指定端口的状态为可用，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理；
[0053]若所述指定端口的状态为不可用，所述控制器对所述上报的报文进行处理。
[0054]在具体的应用场景中，所述检测模块730，具体用于:
[0055]判断所述网络设备是否存在所述指定端口 ；
[0056]若所述网络设备存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路正常，所述检测模块730确定所述指定端口的状态为可用；
[0057]所述网络设备不存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路异常，所述检测模块730确定所述指定端口的状态为不可用。
[0058]在具体的应用场景中，所述指定端口为L0CAL_ENGINE端口。
[0059]由此可见，通过应用以上技术方案，在首次接收到网络设备上报的报文时，控制器返回该报文并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理，从而避免了报文在上送控制器处理的过程中所可能发生的报文延迟、丢包等问题，使网络业务的处理效率以及实用性得到了优化。
[0060]通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是⑶-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。
[0061]本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
[0062]本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
[0063]上述本发明序号仅仅为了描述，不代表实施场景的优劣。
[0064]以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
【权利要求】
1.一种报文处理方法，其特征在于，所述方法应用于包括控制器、网络设备以及本地业务引擎的Openflow网络系统中，所述网络设备与所述本地业务引擎通过指定端口相互连接，还包括: 当首次接收到所述网络设备上报的报文时，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理。
2.如权利要求1所述的方法，其特征在于，所述控制器指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理，具体为: 所述控制器下发流表项，所述流表项用于指示所述网络设备将所述需要上报的报文通过所述指定端口发送至所述本地业务引擎，以及将从所述指定端口返回的报文进行转发； 其中，所述本地业务引擎通过建立隧道与所述网络设备进行数据传输，并利用Echo对网络连接和设备可用性进行探测。
3.如权利要求2所述的方法，其特征在于，所述控制器在首次接收到所述网络设备上报的报文之后,还包括: 所述控制器对所述指定端口的状态进行检测； 若所述指定端口的状态为可用，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理； 若所述指定端口的状态为不可用，所述控制器对所述上报的报文进行处理。
4.如权利要求3所述的方法，其特征在于，所述控制器对所述指定端口的状态进行检测，具体为:` 所述控制器判断所述网络设备是否存在所述指定端口； 若所述网络设备存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路正常，所述控制器确定所述指定端口的状态为可用； 所述网络设备不存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路异常，所述控制器确定所述指定端口的状态为不可用。
5.如权利要求1-4任一项所述的方法，其特征在于，所述指定端口为LOCAL_ENGINE端口，所述网络设备与所述本地业务引擎通过Packet-1n和Packet-out消息进行数据交换。
6.一种控制器，其特征在于，所述控制器应用于包括网络设备以及本地业务引擎的本地Openf low网络系统中，包括: 接口模块，用于接收所述网络设备上报的报文，并在首次接收到所述网络设备上报的报文时，将所述报文返回至所述网络设备； 处理模块，用于在所述接口模块首次接收到所述网络设备上报的报文时，指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理； 其中，所述网络设备与所述本地业务引擎通过指定端口相互连接。
7.如权利要求6所述的控制器，其特征在于， 所述处理模块，具体用于下发流表项，所述流表项用于指示所述网络设备将所述需要上报的报文通过所述指定端口发送至所述本地业务引擎，以及将从所述指定端口返回的报文进行转发。
8.如权利要求7所述的控制器，其特征在于，还包括: 检测模块，用于在所述接口模块首次接收到所述网络设备上报的报文之后，对所述指定端口的状态进行检测； 若所述指定端口的状态为可用，所述控制器将所述报文返回至所述网络设备，并指示所有网络设备通过所述本地业务引擎对需要上报的报文进行处理； 若所述指定端口的状态为不可用，所述控制器对所述上报的报文进行处理。
9.如权利要求8所述的控制器，其特征在于，所述检测模块，具体用于: 判断所述网络设备是否存在所述指定端口； 若所述网络设备存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路正常，所述检测模块确定所述指定端口的状态为可用； 所述网络设备不存在所述指定端口，且所述指定端口与所述本地业务引擎之间的连接链路异常，所述检测模块确定所述指定端口的状态为不可用。
10.如权利要求6-9任一项所述的控 制器，其特征在于，所述指定端口为LOCAL_ENGINE端口。
【文档编号】H04L12/70GK103490996SQ201310450919
【公开日】2014年1月1日 申请日期:2013年9月27日 优先权日:2013年9月27日
【发明者】李蒙 申请人:杭州华三通信技术有限公司