CN103179031A - 基于流方式的多业务转发和处理方法 - Google Patents

Abstract

本发明公开了基于流方式的多业务转发和处理方法，该方法中抽象各个应用程序的处理共同点，并由流模块统一完成；同时由流模块来触发和管理每个应用在数据流转发过程中进一步的私有操作；分布式环境下，通过流方式链接起跨板卡的转发应用。本发明利用流方式实现网络设备多业务支持，就是根据网络报文流的特性，将多种应用整合起来，抽象出各个应用相同的处理部分，将其一次性完成，从而提高整机转发性能。

Description

基于流方式的多业务转发和处理方法

技术领域

本发明涉及一种网络设备数据处理技术，具体涉及一种基于流方式的多业务实现方法。

背景技术

随着计算机网络的日益扩展和丰富，目前的网络设备中，需要支持的业务越来越多，相应的各类应用程序也越来越多。如果只是单一的执行某种应用，整机性能不会收到太大影响。但是如果是很多应用一起执行，每个应用都独立完成自己的从报文解析、查表、建表、报文处理、内部处理、发送一系列流程，那么对整机转发性能会有很大的影响。

发明内容

本发明针对现有网络设备在同时执行多种应用的能力方面所存在的不足，而提供一种基于流方式的多业务转发和处理方法，该方法能够有效提升整机转发性能。

为了达到上述目的，本发明采用如下的技术方案：

基于流方式的多业务转发和处理方法，所述方法中抽象各个应用程序的处理共同点，并由负责管理流表项和转发流数据的流模块统一完成；同时由流模块来触发和管理每个应用在数据流转发过程中进一步的私有操作；分布式环境下，通过流方式链接起跨板卡的转发应用。

在本发明的实施例中，所述流方式的具体流程如下：

(1)根据所有应用程序的处理共同点，将所有应用程序分为不同的流处理域；

(2)在每个流处理域中，流模块针对每条流进行查流表操作，若查找到相应的流表项，流模块会根据流表项里的内容，将报文做处理；若没有查找到相应的流表项，流模块将建立临时流表项，并将报文交由传统流程转发；

(3)在传统流程转发过程中，各个应用程序将自己针对该流的操作方法和需要修改的内部数据挂接到临时流表项里，该临时流表项将提供一些公共操作的数据和接口让各应用程序统一注册；

(4)转发路径上最后的应用程序通知流模块流表项建立完毕，流模块将建立完毕的流表项插入正式流表；

(5)进行流的报文进入，并进行查表，查到相应的流表项，进入流转发流程；

(6)流模块执行公共接口，并根据各应用程序的挂接信息，完成各应用程序的操作，并最终发出。

进一步的，所述各个应用程序的处理共同点包括以下几点：

(1)根据数据流的内容索引本地表项；

(2)简单的vpn头部增加剥离处理；

(3)将路由查询结构和acl查询结果存贮在流表项公共部分里。

进一步的，所述步骤(3)中的挂接操作是将应用程序的私有信息和回调接口存储到临时流表项对应的内存位置。

进一步的，所述流模块在查表时，所采用的索引方式与当前网络设备的配置相对应；在当前索引方式无法满足需要时，由应用程序在挂接到流的私用信息里建立小表，以扩展元组为索引。

进一步的，通过流方式链接起跨板卡的转发应用时，针对线卡上对应的流表项，流模块会根据路由信息决定报文的走向，如果是要进行转发，在最终发送时，判断报文的转发方式。

再进一步的，所述报文的转发方式包括如下三种：

a、直接通过本线卡出口发出；

b、发到另一块线卡，并且通过交换矩阵直接硬件转发；

c、发到另一块线卡，并通过interconn交给流模块，继续处理并最终发送。

根据上述方案得到的本发明与传统的转发流程相比，其根据网络报文流的特性，将多种应用整合起来，抽象出各个应用相同的处理部分，将其一次性完成，从而提高整机转发性能。

本发明加快了设备转发速度，应用业务越多，性能提高幅度越大；同时简化了部分应用程序的实现，比如netflow之类的应用，完全不再保留自己的表项，全部依靠流模块来实现。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为流方式的区域划分实现示意图。

图2为流表构造示意图。

图3为流表项构造示意图。

图4为流方式处理流程示意图。

图5为建表流程示意图。

图6为建立的私有表项的构造示意图。

图7为应用程序内部信息和流表项为一对多关系时，相关表项定位的示意图。

图8为分布式环境示意图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

为了提升整机转发性能，本发明提供一种基于流方式的多业务转发和处理方案，该方案中抽象各个应用程序的处理共同点，并由流模块统一完成；同时由流模块来触发和管理每个应用在数据流转发过程中进一步的私有操作；分布式环境下，通过流方式链接起跨板卡的转发应用。

本发明中涉及的流模块使用于负责管理流表项和转发流数据的模块。

对于流模块的触发作用：

参见图2和3，根据其所示的流表项的构成可知，每个应用模块会将自己的私有数据，和回调接口注册到流表项里，数据包经过路由器，进行流转发时，会进入这些接口，由应用程序的代码进行私有操作。

对于流模块的管理作用：

各个应用程序在注册流表项删除时，通知他们的回调接口。流表项删除的时候，会通过这些接口让各个模块处理相关事务。

当应用模块的内部发生变化时，可以对相关的表项做删除或修改，而相应的定位相关表项的方法有3种：

1.最简单的方法，应用提供索引方式，遍历某个域里整个流表，定位相关的表项，做操作；

2.在应用程序内部信息和流表项是一对多的关系时，如图7所示，在建立表项时，用链表做关联，同步的时候，只遍历该链表，不用整体遍历；

3.当不是就简单的一对多的关系，又不希望遍历整个流表，应用可以自行在内部建立私有表，记录自己使用的表项。

参见图8，本发明中涉及的分布式环境指核心网的多板卡路由设备，由主控、备控和多个线卡组成，各个板卡可以独立工作，也可以协同工作。

本发明中分布式环境所构成的分布式系统的基本设计是控制和协议报文多在主控处理，业务转发多在线卡处理。板卡间协同工作时，通过板间交换矩阵和Hig通道来进行数据交互，软件层面有专门的interconn模块负责通道和报文交互时的管理。

若某线卡收到报文，该线卡上有对应的流表项，那么流模块会根据路由信息决定报文的走向，如果是要进行转发，那么在最终发送时，判断报文是：

1)直接通过本线卡出口发出(路由信息决定)；

2)还是发到另一块线卡，并且通过交换矩阵直接硬件转发(判断目的线卡没有任何应用操作需求)；

3)发到另一块线卡，并通过interconn交给流模块，继续处理并最终发送。

对于状态防火墙之类的需要将双向流量做关联操作的，会将流建立在主控上，所有的跨线卡转发报文，就必须从入线卡进入主控，再从主控到出线卡。

本发明利用流方式实现网络设备多业务支持，就是根据网络报文流的特性，将多种应用整合起来，抽象出各个应用相同的处理部分，将其一次性完成，从而提高整机转发性能。

基于上述原理，本发明提供的流方式具有如下四个特点：

(1)Data Plane，即应用在数据/报文处理层面；

(2)Diverse Protocol，即支持多种协议；

(3)Dynamic Tuple，即元组可以动态调整；

(4)Distributed System，即支持分布式系统。

Data Plane

网络设备往往分为控制层面和数据层面来实现，即本发明中的流转发主要针对数据层面。

对于普通的转发流程，假如有以下一些应用：

攻击检测、acl、nat、状态防火墙、流量工程、gre。

由此，当一个报文要经过这台设备转发时，如果符合所有应用的判断标准，该报文就要先经过物理层，链路层的解析，到达网络层，在网络层完成报文的解析、检查、路由查询工作，并且经过以上所列模块的处理，无论网络的层次处理还是应用模块自己的处理，完全独立，即前者处理后的信息，后者无法使用。每个模块都要查询自己内部的表来寻找处理所用的控制块，一圈跑下来，耗时很厉害。

利用本发明提供的流方式在data plane，相对传统转发具有如下优点：

(1)压缩了链路层和网络层，在某些情况下省去链路层的操作；

(2)整合了所有应用的公共操作，比如查表，流量统计；

(3)前后应用程序的联动，比如进出口都配置了acl，进口Permit，出口deny，那么对于指定的流，在进口就可以做deny操作。除非后续路径上有修改报文流属性的应用，(nat，状态防火墙)。

基于上述原理，本发明的具体实施过程如下：

首先根据现实的应用将流方式分为6个区域实现，由流模块完成链路层对报文的初步分析，并将报文交到相关域里做后续操作。

如图1所示，这6个域是逻辑上的概念，分别为IPv4Unicast、IPv6Unicast、IPv4Multicast、IPv6Multicast、L2、MPLS。在代码实现上，为每个域提供单独的域数据结构和表数据结构以及不同的报文进入区域进行处理的接口。

本发明之所以分成这6个域，是因为它们各自有着独特的报文特性和业务组成，分开便于流程控制上的灵活。其具体理由如下：

1、减少流表的大小，比如在v4的表有很多节点，而v6表节点很少的情况下，如果只是收发v6报文，查表速度不会被v4拖累。

2、如果不分区域，在一个流程里做报文分析，hash计算，冲突时的内容比较等等，都需要做类型判断而进行不同的操作，多次判断在分区域后就变成各区域入口前唯一的一次判断。

3、每个区域里对报文可能会有特殊的操作，分区域后，扩展性比较好，比如有些区域需要考虑分片，有些不需要。有些区域需要对入端口做检查。考虑到以后可能会将部分应用程序的操作整合到流转发里进行。区分区域会比较灵活。

4、考虑到转发性能问题，可能会某些域做特殊的快速转发流程。

本发明中流模块在完成链路层对报文的初步分析时所采用的分析方法有两种：

一种是报文控制块里会携带硬件预处理后的信息，比如可以通过硬件处理后设置的信息，知道报文是ipv4，还是ipv6；是unicast，还是multicast；

另一种是解析报文头，通过头部的信息，判断报文的类型。比如udp，gre，ipsec等都可以通过头部判断出来。

针对ipv4域，其具体流的建立和转发流程如下(参见图4)：

1、流模块针对每条流进行查流表操作，若查找到相应的流表项，流模块会根据流表项里的内容，将报文做处理；若没有查找到相应的流表项，流模块将建立临时流表项，并将报文交由传统流程转发。

该步骤涉及的流表项为相同特性的报文建立起来的节点，一个数据结构的实例，流表是这些流表项组织在一起形成的表。

参见图5，每个报文经过路由器会在流模块里查流表，确定是否已经有对应的表项？若有，流模块会根据表项里的内容，将报文做处理；若没有，就分配内存建立表项这个数据结构实例，然后这个报文会交给路由器传统的协议栈转发流程。

参见图3，该步骤中建立的临时流表项只有公共信息，其没有加入转发路径上各个应用程序的信息(如图3中左边开始的4块部分)。

2、在传统流程转发过程中，各个应用将自己针对这条流(即报文)的操作方法和需要修改的内部数据挂接到流表项里，流表项还会提供一些公共操作的数据和接口让各模块统一注册。

3、转发路径上最后的模块通知流模块表项建立完毕，流模块将表项插入正式流表。

基于上述两步，对于ipv4报文，ipv4协议栈模块转发过程中，会根据配置经过各种应用程序的模块，如acl，nat，status firewall等等，这些模块会将自己的信息填入到表项里，并在所有模块处理完之后，将这个信息完整的表项插入到流表，这样之后相同索引方式的报文进入后，就能够查到表项，并通过流模块来转发，而不是传统的转发流程。

4、流的报文进入，查表成功，进入流转发流程。

5、流模块执行公共接口，并根据各模块的挂接信息，完成各模块的操作，并最终发出。

6、对于6to4之类的应用会跨过不同的域，一次流转发无法完成。

7、vpn一对多方向的转发，在一个域内也需要走多次流转发流程。

对于Diverse Protocol

IPv4-Unicast协议族

路由器当前在Data-Plane层面需要处理协议最多的是IPv4-Unicast协议族：

routing、PBR、uRPF

ACL、状态防火墙、防攻击、应用层识别

NAT

Qos、各种限速功能

NetFlow、IP-Accounting

L2TP、PPTP、IPSec、GRE/IPIP及各种Tunnel协议、mGRE

VRF-ware

链路层支持Ether、PPP、Vlan、QinQ

IPv4-Multicast协议族

已知的IPv4-Multicast协议族：

mrouting

ACL

限速功能

MVPN

IPv6-Unicast协议族

已知的IPv6-Unicast协议族：

routingv6

ACLv6

IPSecv6、各种Tunnel协议

Qos

Ipv6-multicast目前应用不多.

L2域主要为了支持以mac地址做为流标识的应用，比如pppoe

Mpls是一种独立于ipv4、ipv6的特殊网络层架构，单独支持

上述的应用都纳入到流的管理里，其具体实施如上述的的建流和转发的流程，此处不加以赘述。

对于本发明的Dynamic Tuple

流模式的实现中，查表是最关键的.因为所有的应用共用一张流表来取代各自的表.所以流表的构建必须符合两点：

1.能够满足各种应用对自身信息的索引；

2.查询必须足够快。

对于第一点，不同的应用对流有着不同的索引方式，比如普通的路由查找，只关注目的地址，而组播会关注源地址和目的地址，nat会关注地址、协议和协议端口，qos会关注除了5元组以外的cos等字段，ipsec之类的特殊应用会关注spi之类的私有标识。

以ipv4-unicast域里应用为例

IPv4-unicast域中，各种协议所需的元组数表1：

表1

很明显的一点是，当索引信息越复杂，流就会分得越细，流表就会越大，空间和时间的消耗就越大。

比如，如果设备只是在跑路由转发，而将流按照5元组去分类，就没有任何意义。所以，本发明制定了动态选择的方法，即根据设备的配置来选择索引的复杂度。

目前本发明可以灵活的使用1元到5元，并根据需要增加vrf的信息匹配。

其中2元必然是地址，另外3元根据需要可以变通，因为不少应用程序，比如12tp、pptp、ipsec、关注报文头里的session id而不是协议端口，可以通过迅速的解析来完成索引的建立。

参见图6，对于acl、qos等可能出现的大于5元的情况，考虑到表项大小的承受能力，多于5元+vrf的索引，由应用程序在挂接到流的私用信息里建立私有表项，以扩展的元组为索引。

由上可知，对于一条流，或者说流表项的查询是需要查询的索引关键字，而不同的应用程序会使用不同的关键字索引去查询，udp报文要唯一的定位一条流，需要ip源地址，ip目的地址，源端口号，目的端口号，udp协议号，而pppoe要唯一的定位一条流，需要源mac地址，目的mac地址，tunnel id，sessionid。因为不一样，所以流模块会根据当前路由器设备的配置来决定使用什么样的索引方式，能尽量满足所有当前应用的需要。不过实在不能满足，就采用如图6所示的方法，应用程序扩展自己的索引方式。

对于本发明的Distributed System

对即分布式架构的设备，流的支持是很重要的。

1、由于所有模块的信息在主控上都有，如果选择在主控建流，再将流下发到线卡，那么这条流对应的流表项里有着入线卡和出线卡上应用配置的完整信息。对于一些应用，就可以在入线卡上，通过流表项里的信息完成整个转发过程中所有应用的操作，并通过交换矩阵直接将报文送到出板卡的业务出口，而不用将报文送到出线卡的cpu，做进一步处理。由此，对于跨板卡的报文转发，传统流程里报文需要通过两块线卡各自进行处理，而流的建立，可以在一块线卡或主控上通过第一个报文转发时得到的信息建立支持跨线卡转发的流表项。带来的优点就是可以在一块线卡上处理完报文，免去板间通讯带来的消耗，因为两块板卡都要处理，其板间通讯的内容将不仅仅是报文本身，还有先处理的板卡所要传递的已经对报文做部分解析的结果。

2、本发明支持主控建流和线卡建流，如果选择主控建流，将流同步到线卡的模式，那么各应用在线卡上不用再做完整的代码实现，只需要实现流转发时所要做的操作即可。由此在线卡上对流的依赖将降低各应用模块在线卡的实现复杂度。

3、没有流模块的分布式实现，每个模块在主控发生配置变化或因为拓扑变化导致的内部信息变化，都可能需要将变化同步到相关线卡和备板。而使用流模块后，线卡上某些应用就不再需要完整实现，，也就没有模块自身的同步需求，主控上各模块的变化将统一通过主控上流表的变化和流表向线卡的同步这一过程在整个系统中得到体现。

4、发生主备倒换后，由于主备倒换期间可能网络拓扑发生变化，因为线卡上的状态可能和倒换前不同。而备控上的状态是主备倒换前主控的状态，为了保证系统的运行一致性，在备控变为可运行的主控之前，各模块必须先做一致性检查，即确保线卡和备控上的状态和信息一致。采用主控建流的模式之后，不需要各模块再主动做一致性检查，而是清除线卡上的流表，让新的主控重新建流。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (7)

1.基于流方式的多业务转发和处理方法，其特征在于，所述方法中抽象各个应用程序的处理共同点，并由负责管理流表项和转发流数据的流模块统一完成；同时由流模块来触发和管理每个应用在数据流转发过程中进一步的私有操作；分布式环境下，通过流方式链接起跨板卡的转发应用。

2.根据权利要求1所述的基于流方式的多业务转发和处理方法，其特征在于，所述流方式的具体流程如下：

(1)根据所有应用程序的处理共同点，将所有应用程序分为不同的流处理域；

(2)在每个流处理域中，流模块针对每条流进行查流表操作，若查找到相应的流表项，流模块会根据流表项里的内容，将报文做处理；若没有查找到相应的流表项，流模块将建立临时流表项，并将报文交由传统流程转发；

(3)在传统流程转发过程中，各个应用程序将自己针对该流的操作方法和需要修改的内部数据挂接到临时流表项里，该临时流表项将提供一些公共操作的数据和接口让各应用程序统一注册；

(4)转发路径上最后的应用程序通知流模块流表项建立完毕，流模块将建立完毕的流表项插入正式流表；

(5)进行流的报文进入，并进行查表，查到相应的流表项，进入流转发流程；

(6)流模块执行公共接口，并根据各应用程序的挂接信息，完成各应用程序的操作，并最终发出。

3.根据权利要求1所述的基于流方式的多业务转发和处理方法，其特征在于，所述各个应用程序的处理共同点包括以下几点：

(1)根据数据流的内容索引本地表项；

(2)简单的vpn头部增加剥离处理；

(3)将路由查询结构和acl查询结果存贮在流表项公共部分里。

4.根据权利要求2所述的基于流方式的多业务转发和处理方法，其特征在于，所述步骤(3)中的挂接操作是将应用程序的私有信息和回调接口存储到临时流表项对应的内存位置。

5.根据权利要求2所述的基于流方式的多业务转发和处理方法，其特征在于，所述流模块在查表时，所采用的索引方式与当前网络设备的配置相对应；在当前索引方式无法满足需要时，由应用程序在挂接到流的私用信息里建立小表，以扩展元组为索引。

6.根据权利要求1所述的基于流方式的多业务转发和处理方法，其特征在于，通过流方式链接起跨板卡的转发应用时，针对线卡上对应的流表项，流模块会根据路由信息决定报文的走向，如果是要进行转发，在最终发送时，判断报文的转发方式。

7.根据权利要求6所述的基于流方式的多业务转发和处理方法，其特征

在于，所述报文的转发方式包括如下三种：

a、直接通过本线卡出口发出；

b、发到另一块线卡，并且通过交换矩阵直接硬件转发；

c、发到另一块线卡，并通过interconn交给流模块，继续处理并最终发送。

Images