CN1787489A - 将接口流量在多个网络处理器引擎中均担的方法 - Google Patents

Abstract

本发明提供一种在数据通信产品中实现业务流量在***内部负责处理逻辑的引擎板卡中进行负载均担的方法。该方法将端口汇聚功能应用在数据通信设备内部接口板和引擎板之间，每块引擎板分配一个虚物理端口加入到端口汇聚组中。本发明可以提升产品的整体性能，实现更大的数据处理能力，并且能够合理均匀的将业务处理负担分配在引擎板卡上。同时该方法也能够提供冗余备份的功能，满足引擎出现故障时***需要不间断服务的需要。

Description

将接口流量在多个网络处理器引擎中均担的方法

技术领域

本发明属于数据通信技术领域，尤其涉及机架式数据通信设备中接口流量在设备内部的多个处理引擎中的均担和冗余备份。

背景技术

在机架式数据通信产品中，***中包含有多块板卡，共同来完成数据转发处理，***控制等功能。其中负责数据转发处理的板卡分为主控板，接口板和引擎板。如图1所示，主控板是***的控制中心，运行***控制软件。负责设备的管理维护，接收用户输入控制，并且运行包含路由协议，网管协议，链路层协议等在内的各种应用协议模块。主控板通过带外管理通道对***中的其他板卡进行管理和通信。

接口板上负责接入业务流量，同时板卡上配置有基于ASIC(Application SpecificIntegrated Circuit)的硬件处理逻辑。拥有有限的报文缓存，二层转发表，三层路由表，流表，能够完成简单的报文转发处理。

引擎板上拥有复杂的业务控制逻辑，并且配有可以扩展的报文缓存，二三层转发表，流表等等。能够完成复杂的业务处理，而且控制逻辑是可以编程定制，对于新协议和复杂业务能够通过编程来加以支持。然而引擎板的处理能力有一定限度，不能支持所有接口板的全线速条件下的报文处理。

在数据通信设备中，接口板提供数据接入，采用固化的硬件芯片实现，可以完成较简单的业务处理，对于需要复杂逻辑控制的业务，如：PPPOE(Point to Point Protocol OverEthernet)，L2TP(Layer2 Tunnel Protocol)，MPLS(Multi-protocol Label Switch)，VPN(VirtualPrivate Network)等业务需要拥有能完成更为复杂逻辑处理能力的网络处理器来实现。同时接口板的各种转发表的表项空间也非常有限，无法同拥有TCAM，SRAM接口的网络处理器相比。因此机架式设备中，为了处理PPPOE，L2TP，MPLS VPN这些复杂业务流，接口板收到的流量转发给拥有网络处理器的引擎板处理，从而完成这些复杂的应用和表项空间提升。但是这同时面临新的问题，拥有网络处理器的引擎板处理能力有限，不能满足所有接口板的流量处理要求，而且限制于器件尺寸以及功耗等问题，无法将更多的网络处理器集成在单独一块板卡上，这样***必须提供能够将不同接口板的流量在多个引擎板间均担的方法，才能够提升整机的处理能力，满足网络骨干节点的流量处理要。

发明内容

本发明提出一种将接口流量在多个网络处理器引擎中均担的方法，实现***整机最大数据处理能力。

本发明的技术内容：一种将接口流量在多个网络处理器引擎中均担的方法，步骤包括：

将一组引擎板的虚端口设置成一个端口汇聚组，配置到每个接口板，形成一个逻辑端口。在接口板的转发表中，将需要使用引擎板进行处理的业务数据流的目的端口设置成这个逻辑端口，表示相应的数据流将转发到这个逻辑端口。而实际上，进入这个逻辑端口的报文将进一步按照指定的哈希函数进行运算，选择得到端口汇聚组中的一个虚端口号，从而被发送到某一个引擎板进行处理。

端口汇聚组可以根据需要设置多个，各自对应一组处理引擎板。从而根据处理能力和业务类型的需要，将多组接口板与多组处理引擎灵活地对应起来。例如一个接口板上可以配置两个端口汇聚组，将两种业务的数据流分配到两组处理引擎上。

引擎板可以执行的处理包括：PPPOE，L2TP，MPLS VPN等。引擎板完成处理之后，再根据路由表或MPLS交换表的输出接口信息，将报文转发到正确的输出接口板发送出去。这个过程与网络设备上的一般处理流程是一致的。

具体的管理维护流程在下文分别进行描述。

端口汇聚组的创建：

在设备启动时，设备管理检测***中存在的引擎板数量，每块引擎板分配一个虚端口加入到端口汇聚组中，并且下发给所有接口板。

端口汇聚组的更新：

当设备管理检测到新的引擎板***和拔出时，更新端口汇聚组，并且下发给所有接口板重新设置。

接口板业务流量转发设置到端口汇聚组：

接口板在创建转发到引擎板的相关表项设置时，将***创建包含所有引擎板虚端口的端口汇聚组标示作为转发的目的端口。

端口汇聚组的哈希算法设置：

哈希算法可以通过编程控制，可以基于源MAC地址，目的MAC地址，源IP，目的IP，用户自定义字段等方式实现。为了防止出现数据报文乱序，需要确保每个具体数据流的每个报文都交同一个引擎板处理。为此，选择哈希算法的输入参数必须受一定的限制，应选择同一个数据流中各报文保持不变的信息，如各种源地址、目的地址、端口号、协议号、MPLS标签等。而不能选择一个数据流中各报文会有变化的字段，如报文长度、应用层报文类型等。

软件表项的下发设置：

因为采用负载均担的处理，所有加入端口汇聚组的引擎板都要负责报文转发，因此路由转发表项要下发给所有的引擎板。

本发明的技术效果：本发明能够合理均匀地将业务处理负担分配在引擎板上，并且分担粒度基于每个报文，能够达到比基于端口和单板更好的效果。

通过采用不同的端口汇聚组，还可使输入数据流根据不同的业务类型在恰当的引擎板之中进行分配，对于多业务类型处理的灵活性很好。

本发明还能提供引擎板的冗余备份功能，当单块引擎板出现故障时，业务可以不受影响的在剩余的引擎板中继续分担处理，***能够始终在线提供服务而不用人工干预。

附图说明

下面结合附图，详细描述本发明。

图1机架***结构图；

图2端口汇聚的原理图；

图3负载均担后的数据流量转发流程图；

图4 Slot7引擎板拔出后的数据流量转发流程图。

具体实施方式

将端口汇聚功能应用在数据通信设备内部接口板和引擎板之间，每块引擎板分配一个虚物理端口加入到端口汇聚组中。虚端口并不是面板上真实存在的物理端口，但是虚端口编号包含于***的端口表空间中，可以在***内部被识别作为报文的出入端口。例如，Slot2引擎板的端口31，实际上Slot2上没有这个物理端口，但是在***内部，其他接口板可以将报文转发给Slot2的端口31，这样引擎板才能接收到报文。

端口汇聚组需要在所有接口板上配置。这样无论哪个接口板收的报文，在需要转发给引擎板处理时，实际上都是转发给端口汇聚组，端口汇聚组作为一个逻辑端口，分配有逻辑端口号，可以通过端口号所属的范围或者在组成端口号的数据位中增加类型位来和普通端口号区别开来。因此在接口板路由表或者重定向表中的端口字端中保存端口汇聚组的逻辑端口号，转发引擎根据逻辑端口号所属的范围或者标志位来识别是否是端口汇聚组。根据端口汇聚组中的成员内容，硬件采用哈希方式对报文中的字段进行计算，来选择其中一个端口。哈希算法可以配置成基于源目的MAC地址，源目的IP地址，也可以是用户自定义的内容。由于报文中这些字段内容是不同的，因此哈希的结果也就不同，从而实现了流量在引擎板中的分担。

下面是基于源目的IP地址的哈希算法示例：

SIP(源IP地址)，DIP(目的IP地址)，XOR抑或运算

HASH_INDEX＝SIP[29:27]XOR SIP[26:24]XOR SIP[23:21]XOR SIP[20:18]XORSIP[17:15]XOR SIP[14:12]XOR SIP[11:9]XOR SIP[8:6]XOR SIP[5:3]XOR SIP[2:0]XORDIP[29:27]XOR DIP[26:24]XOR DIP[23:21]XOR DIP[20:18]XOR DIP[17:15]XORDIP[14:12]XOR DIP[11:9]XOR DIP[8:6]XOR DIP[5:3]XOR DIP[2:0]

端口索引＝HASH_INDEX模(端口成员数量-1)

哈希计算的结果范围在端口成员数量-1到0之间，对应的就是端口汇聚组中的端口成员索引。根据这个索引再查找相应的成员端口号就可以找到真正的物理端口。哈希计算还可以基于报文的MAC地址，甚至用户自定义字段。根据业务类型不同，要选择合适的哈希算法，但是一个端口汇聚组只能配置有一种哈希算法，因此要支持所有的业务类型***中需要配置多个端口汇聚组。例如：MPLS报文基于标签转发，指定基于IP地址作哈希计算不合适，因此要用基于MAC地址的哈希算法；而纯粹的IP转发流则使用基于IP地址的哈希计算分担效果要好。

端口汇聚中成员端口的维护基于引擎板的设备管理，当引擎板***和拔除时，端口汇聚可以立即做到更新，不影响已有的业务处理。这也是一种冗余备份功能，当***中存在多块引擎板时，一块引擎板拔出对整机流量转发没有影响，控制软件可以检测到这一情况，自动完成端口汇聚组的更新，业务流量继续在其余的引擎板中分担。

下面描述本发明的一个较佳的具体实现，以一台拥有8个槽位的机架数据通信设备为例，设备配置如下：

Slot1：接口板

Slot2：接口板

Slot3：接口板

Slot4：主控板

Slot5：备用主控板

Slot6：引擎板

Slot7：引擎板

Slot8：引擎板

设计***端口号空间为7位，最高位用于区分端口汇聚组还是普通端口。端口汇聚组的使用空间为64-127，物理端口为0-63。低6位用于保存物理端口号或者端口汇聚组的索引。

1.在Slot1-Slot3接口板的硬件表项中创建两个端口汇聚组：将Slot6，虚端口31；Slot7，虚端口31；Slot8，虚端口31加入端口汇聚组1(逻辑端口号65)，端口汇聚组1的哈希算法设置为基于源和目的MAC地址。将Slot6，虚端口30；Slot7，虚端口30；Slot8，虚端口30加入端口汇聚组2(逻辑端口号66)，端口汇聚组2的哈希算法设置为基于源和目的IP地址。

2、设置Slot1-Slot3接口板的硬件转发表项，将MPLS，PPPOE，L3VPN CE-PE的业务流量的出端口指定为端口汇聚组1；将IP转发业务流量的出端口指定为端口汇聚组2。

3、主控板将学习到的路由，MPLS标签，PPPOE用户Session信息下发给所有的引擎板。在Slot6，Slot7，Slot8的转发逻辑中建立相应的路由表，MPLS转发表和PPPOE用户Session表。

4、图3是此时实现负载均担后的业务流量转发流程图。从Slotl-Slot3接口板收到的业务流量通过端口汇聚组1和端口汇聚组2转发到引擎板。每个报文都经过哈希计算，根据哈希计算的结果索引到端口汇聚组的成员端口，再根据成员的槽位号加端口报文被转发给相应的引擎板继续处理。不同报文的哈希结果不同，因此每块Slot6-Slot8的引擎板都会收到要处理的报文，从而宏观上来看所有接口板的负载在slot6-slot8上都进行了合理分配。

当Slot7引擎板发生故障，板卡被拔出时，***需要做如下处理：

设备管理检测到Slot7引擎板被拔出，立即对端口汇聚组1和端口汇聚组2作更新，将Slot7，虚端口31；Slot7，虚端口30分别从端口汇聚组1和2种删除。更新Slot1-Slot3接口板中的硬件端口汇聚组表项。

图4是Slot7引擎板发出后接口板业务流量的转发流程图。

Slot7拔出后，端口汇聚组1和端口汇聚组2都作了更新，将Slot7/31和Slot7/30从成员列表中删除，同时端口成员数量变为2。这样哈希计算的索引结果就只在0...1之间，报文继续分配给引擎板Slot6和Slot8处理，Slot7的拔出不影响***继续提供服务。

当替换的引擎板重新***Slot7时，***作相应的处理：

设备管理检测到Slot7***新的引擎板，等待Slot7完成热插处理后(包含配置的恢复，和相关表项的重新下发等等)，向端口汇聚组1和端口汇聚组2***新的表项，将Slot7，虚端口31；Slot7，虚端口30加入到汇聚组的端口成员列表中。这个操作完成之后，***就可以从图4恢复成图3的方式转发报文了。

Claims (6)

1、一种将接口流量在多个网络处理器引擎中均担的方法，步骤包括：

(1)将多个处理引擎板对应的虚端口组成一个端口汇聚组，形成一个逻辑端口，接口板需要处理的数据流转发到具体的逻辑端口；

(2)采用哈希算法在端口汇聚组中分配数据流，从而将接口板输入数据流均匀分担到***中的多个处理引擎进行分布式处理；

(3)处理之后的数据流再经过接口板正常发出。

2、如权利要求1所述的将接口流量在多个网络处理器引擎中均担的方法，其特征在于：在设备启动时，设备管理模块检测***中存在的引擎板数量，给每块引擎板分配一个虚物理端口加入到端口汇聚组中，并分配逻辑端口号。

3、如权利要求1所述的将接口流量在多个网络处理器引擎中均担的方法，其特征在于：根据端口汇聚组中的成员内容，不同的端口汇聚组采用不同的哈希算法对报文中的字段进行计算。

4、如权利要求1所述的将接口流量在多个网络处理器引擎中均担的方法，其特征在于：当设备管理检测到新的引擎板***和拔出时，更新端口汇聚组，并且下发给所有接口板重新设置。

5、如权利要求1所述的将接口流量在多个网络处理器引擎中均担的方法，其特征在于：接口板在创建转发到引擎板的相关表项设置时，将***创建包含所有引擎板虚端口的端口汇聚组标示作为转发的目的端口。

6、如权利要求3所述的将接口流量在多个网络处理器引擎中均担的方法，其特征在于：哈希算法通过编程控制，采用同一个具体数据流中保持不变的信息作为哈希函数的参数。

Images