包转发率

包转发率（共3篇）

包转发率 篇1

摘要：铁路无线Mesh网络不仅要求用户数据包按照确定的无线多跳链进行数据转发, 而且需要根据节点故障概率的动态变化进行自适应的调整。为此设计了用户/管理数据包选择性转发策略, 并基于Linux开源代码进行了具体的功能实现。实验结果表明, 基于用户/管理数据包选择性转发策略的铁路无线Mesh网络能正确而高效地进行数据转发, 同时可根据Mesh节点故障概率的动态变化进行自适应的转发路径调整。

关键词：铁路无线Mesh网络,无线多跳链,选择性转发策略,尾节点

互联网已经成为人们生活的一部分, 但是在旅客列车上至今还难以提供高效的互联网服务, 旅客列车Internet应用成为国内外的研究热点之一[1]。如图1所示, 文献[2]提出了一种榕树型拓扑, 并设计了一种多出口总线结构的铁路无线Mesh网络。理论分析表明:铁路无线Mesh网络具有较高的传输带宽和较低的传输延迟, 部署便捷, 结构调整灵活, 适合于铁路无线宽带覆盖的部署。

铁路无线Mesh网络由交换控制中心 (Switch Center, SC) 、Mesh网关 (Mesh Gateway, MG) 和Mesh路由器 (Mesh Router, MR) 构成。其中, SC是铁路无线Mesh网络的核心, 通过它实现网络的集中式管理。MR是部署在铁路沿线的多模Mesh节点, 为部署在列车上的Mesh终端 (Mesh Client, MC) 提供无缝的无线宽带接入, 当它与有线网络出口直接连接时, 它就成为MG, 同时负责起进行无线/有线网络数据转发的任务。MC承担着车-地无线互联的任务, 随着列车快速地从一个MR切换到下一个MR而保持着不间断的网络连接。

MR是铁路无线Mesh网络的主体, 它承担着MC接入、ingress和egress数据回传3项主要任务。MR由3个无线模块和1个有线模块构成[2], 其中3个无线模块分别负责这3项任务。当该节点作为网关节点时, 由有线模块负责与有线网络的数据传输任务。MR设计为一个2层网络设备, 采用bridge模块将4个网络模块连接在一起, 实现数据包的转发。

根据bridge的数据包转发策略[3], MRi接收的数据包可能同时通过MRi-1和MRi+1转发给SC, 从而导致重复数据包的出现, 严重影响铁路无线Mesh网络的性能。为此, 文献[2]设计了动态最小生成树算法。该算法根据节点故障概率的动态变化, 导出一棵不包含任何回路的最小生成树, 从而用户数据包可按照节点失效危险性最小的路径进行转发。在铁路无线Mesh网络中, 该路径实质上是一条无线多跳链l<i, j>=vi, vi+1, …, vj。其中, vj是MG节点, vi是最后一个MR节点。

bridge的数据包转发策略不能满足铁路无线Mesh网络这种特定的需求。本文将对这种需求进行深入分析, 提出用户/管理数据包选择性转发策略, 并基于bridge开源代码对该策略进行具体的功能实现。

1 选择性数据包转发策略

显然, 为避免重复数据包的出现, 节点vi不能将用户数据包转发给相邻另一条无线多跳链l<i-1, j-1>=vi-1, vi-2, …, vj-1, 而只能沿l<i, j>转发, 从而在逻辑上将铁路无线Mesh网络转化为一棵不包含回路的普通树型结构。

同时, 节点vi需要将包含节点故障信息或最小生成树信息的管理数据包不受限制地转发。因为若无线多跳链l<i, j>=vi, …, vk-1, vk, vk+1, …, vj的某节点vk出现故障, 则vi到vk-1的节点故障信息不能再通过l<i, j>转发到SC, 而只能通过l<i-1, j-1>转发给SC。SC根据节点故障概率的动态变化, 更新最小生成树, 并将最小生成树信息发布给各Mesh节点, 从而得到两条新的无线多跳链l<k+1, j>=vk+1, …, vj和l<k-1, j-1>=vk-1, …, vi, …, vj-1。

所以, 铁路无线Mesh网络要求对用户和管理数据包进行选择性的转发, 即必须阻止用户数据包而许可管理数据包转发给相邻的另一条无线多跳链。

2 总体方案设计

由于MR采用bridge实现数据包的转发, 选择性数据包转发策略将基于bridge开源代码进行具体的功能实现。为此, 首先定义实现方案应遵循的两个基本原则:

用户无关性原则:必须保证用户应用的透明性;

最小修改原则:在保证功能实现的前提下, 仅对bridge开源代码进行最小修改。

对于用户数据包的转发, 铁路无线Mesh网络基于最小生成树算法, 从逻辑上划分为若干条以MG节点为终点的无线多跳链。对于每条无线多跳链, 其接入用户的数据包均只能经由该路径转发。我们不妨定义无线多跳链的最后一个MR节点为尾节点。显然, 若尾节点不将用户数据包转发给相邻的另一条无线多跳链, 则可实现无线多跳链的逻辑划分。同时, 尾节点的设置决定了如何进行这种无线多跳链的逻辑划分。

对于管理数据包的转发, 铁路无线Mesh网络要求不受无线多跳链逻辑划分的限制, 即尾节点应该允许管理数据包转发给相邻的另一条无线多跳链。

为此, 选择性数据包转发策略将主要集中在尾节点的功能实现。对任意两个相邻MG节点间的MR节点集合, 根据最小生成树信息, 设置且仅设置两个尾节点, 从而确定出两条无线多跳链。若无故障节点, 则两个尾节点是相邻节点, 否则两个尾节点之间的MR节点将不属于任意无线多跳链, 成为孤岛。并且, 尾节点应该阻止用户数据包而许可管理数据包转发给另一条无线多跳链, 即尾节点至少需要具备如下两个功能:

功能I:可阻止用户数据包而许可管理数据包转发给另一条无线多跳链;

功能II:可动态实现正常节点与尾节点的状态变换。

显然, 实现功能I的关键是如何识别用户数据包和管理数据包, 实现功能II的关键是如何更新正常节点和尾节点状态。

基于用户无关性原则, 我们必须设置一个bridge处理程序可以读取的、与所有用户数据包均不同的管理数据标志。根据数据包的包头定义[4], 在给定的3个标志位中, 第一位是未使用的位, 系统将默认地赋值为0。从而对于所有的用户数据包, 该标志位的值均为0。如果管理数据包将该标志位设置为1, 则可以通过该标志位识别用户数据包和管理数据包。我们不妨称该标志为管理数据标志。

基于最小修改原则, 我们必须设置一个bridge处理程序可以读取的、与其它所有Mesh节点不同的尾节点标志。根据bridge的stp协议实现方法[5,6], 网桥的每个端口均可以通过用户配置命令设置其pathcost值, 在存在环路的情况下, bridge网桥处理程序根据各端口的pathcost值决定数据包该往哪个端口转发。由于铁路无线Mesh网络由最小生成树算法避免了环路的出现, 所以各端口的pathcost值不再需要, 为此可借用于标志尾节点。在默认情况下, 所有Mesh节点各端口的pathcost值均为100, 不妨设尾节点与另一无线多跳链相连接的端口的pathcost值为1 000, 则bridge处理程序可以通过该标志判断是否向该端口转发数据包。我们不妨称该标志为尾节点标志。

根据以上的分析和方案设计, 我们将基于bridge开源代码进行具体的实现。

3 程序设计与实现

3.1 尾节点功能实现

bridge的端口处于混杂工作模式, 它接受与之相连的所有LAN传送的每一个数据包。当数据包到达时, bridge必须决定将其丢弃还是转发。钩子函数net/core/dev.c/net_bh () 接收到数据包之后将其交给bridge处理程序br_input.c, 经过如图2所示的处理流程, 判断该数据包应该被丢弃, 还是转发给一个或多个目标端口。

当查找到数据包的转发目标端口后, bridge处理程序br_forward.c将判决目标端口是否应该转发该数据包, 判决子函数should_deliver () 的实现原型如下:

根据功能I的要求, 对于与另一个无线多跳链连接的端口p, 它不应该转发用户数据包。为此, 我们只需要给判决子函数should_deliver () 增加两个判决条件即可实现第I个功能。由于与另一个无线多跳链连接的端口p的p->path_cost恒为1 000, 且用户数据包包头的第一位标志位总为0, 故我们可将判决条件修改为:

if (skb->dev == p->dev ||p->state != BR_STATE_FORWARDING || (p->path_cost ==1000 && skb->nh.iph->frag_off & 0x8000 ==0) )

则可阻止将用户数据包转发给另一条无线多

跳链。显然, 对于管理数据包依然可以转发给另一条无线多跳链。

3.2 管理数据包封装

根据前面的分析, 对于管理数据包需要设置管理数据标志位为1。由于在socket编程中, 数据包的包头将由操作系统自动封装为普通的用户数据包[7], 为此, 我们采用原始套接字 (raw socket) 编程, 并指定数据包的包头封装由用户程序完成, 然后在数据包的包头封装时将管理数据标志位设置为1。为此, 我们编写一个管理数据包发送程序send.c, 其核心代码如下:

3.3 辅助程序设计

为测试管理数据包可通过无线多跳链的尾节点转发给另一条无线多跳链, 在通信对端设计了一个简单的管理数据包接收程序receive.c。该程序调用函数recvfrom () 接收数据, 然后将相应字节内容读出, 其核心代码如下:

4 实验与验证

4.1 实验平台

为验证本文提出的方法是否成功实现功能I和II, 本节在实验室环境下建立了如图3所示的实验平台。

节点1和节点3为两台通信主机, 它们之间的数据通信由节点2进行转发。其中, 节点1可以发送普通的用户数据包 (执行ping 211.80.197.3) , 也可以发送管理数据包 (执行./send 211.80.197.3) ;节点2配置两块集成了atheros芯片的无线网卡ath0和ath1, 由上节改进的bridge网桥处理模块br0实现数据转发, 它可以允许用户数据包转发 (执行brctl set pathcost br0 eth0 100) , 也可以阻止用户数据包转发 (执行brctl set pathcost br0 eth0 1000) 。

这3个节点的配置为:P4 2.6 GHZ CPU, 512 MB内存, Linux FC4操作系统, 内核版本为2.6.11。节点1、2、3的IP地址分别是211.80.197.1、211.80.197.2、211.80.197.3。下面将基于该实验平台进行具体的功能验证。

4.2 实验步骤

4.2.1 允许管理数据包转发

步骤1:节点2执行brctl set pathcost br0 eth0 1 000设置为尾节点状态

步骤2:节点1执行./send 211.80.197.3产生管理数据包

步骤3:节点3执行./receive接收管理数据包:

4.2.2 阻止用户数据包转发

步骤1:节点2执行brctl set pathcost br0 eth0 1000设置为尾节点状态

步骤2:节点1执行ping 211.80.197.3产生用户数据包, 节点3接受信息

4.2.3 取消尾节点状态

步骤1:节点2执行brctl set pathcost br0 eth0 100设置为正常节点状态

步骤2:节点1执行./send 211.80.197.3产生管理数据包

步骤3:节点3执行./receive接收管理数据包

步骤4:节点1执行ping 211.80.197.3产生用户数据包, 节点3接受信息

4.2.4 实验结论

节点1构造了载荷长度为64B的IPv4_TCP数据包进行测量[8], 在接收端节点3对收到的数据包进行统计。实际测得节点3对不同节点下的不同数据包的丢包率如表1所示:

实验结果表明:无线多跳链的尾节点能很好地实现阻止用户数据包而许可管理数据包转发给另一条无线多跳链, 同时能保证正常节点与尾节点的状态变换。

5 结论与展望

本文设计了用户/管理数据包选择性转发策略, 并基于Linux开源代码, 遵循最小修改和用户无关性原则进行了具体的功能实现。实验结果表明, 基于用户/管理数据包选择性转发策略的铁路无线Mesh网络能正确而高效地进行数据转发, 同时可根据Mesh节点故障概率的动态变化进行自适应的链路调整。下一步将要开展的工作是支持用户大都是快速移动的铁路无线Mesh网络数据包转发策略研究。

参考文献

[1]蒋新华, 邹复民, 林漳希, 等.旅客列车Internet应用与研究现状综述.铁道学报, 2007;29 (5) :103—110

[2]邹复民, 蒋新华, 林漳希, 等.一种基于榕树型拓扑的铁路无线Mesh网络结构.铁道学报

[3]IEEE std802.1D—2004.Media Access Control (MAC) Bridges.2004.6

[4]周明天, 汪文勇.TCP/IP网络原理与技术.北京:清华大学出版社, 2000

[5]朱斌.Linux Socket编程及其在无线网关中的应用.微计算机信息, 2007;23:12—22

[6]Nguyen U T, Jin X.Multicast routing in wireless mesh networks:minimum cost trees or shortest path trees?IEEE Communications Magazine, 2007;45 (11) :72—77

[7]贾明, 严世贤.Linux下的C编程.北京:人民邮电出版社, 2001

[8]周炎涛, 李立明.TCP/IP协议下网络编程技术的实现.航空计算技术, 2002;32 (3) :122—125

包转发率 篇2

浓茶，苦而后香，令人回味;陈酒，香且清醇，让人沉醉;鲜花，淡而不艳，发人深思;母爱，朴而深厚，叫人难忘;母亲节到了，祝您母亲安康幸福。

欧洲人用康乃馨向母亲问好，中国人馈赠母亲忘忧草，母亲节来到，我给您准备了一束萱草，愿母亲忘忧，愿母亲快乐，愿母亲幸福，愿母亲长寿!

朋友，工作之余有没有想到牵挂你的母亲?你体谅女友感受时有没有体谅到母亲一人在家的孤单寂寞?母亲节到了!请为想你牵挂你的母亲打个电话报个平安。

朋友，请别忘了今天为母亲准备一件礼物，多关心她的身体健康，有空为她分担些家务。今天是母亲节，请你代我向你的母亲问个好，祝她身体健康，万事如意!

朋友，我知道你很忙，我也知道你很刻苦劳累;可是你一定要知道：今天是母亲节，早点下班回家，煮妈妈最爱吃的饭菜，孝敬一下她吧!

平日的忙碌忘记了问候，母亲的恩情永记心头;生活的奔波写满了酸楚，母亲的安慰常留心间。母亲节，短信融情寄相思：爱你妈妈，永远年轻。

祈福在行动，孝心大联盟!又临周日母亲节。特送你这一条充满幸福魔力的短信，祝你阖家欢乐的同时为天下所有母亲祈福：愿妈妈们永远年轻，永远健康，永远幸福!

千山万水挡不住我对您千丝万缕的.思念，千呼万唤难以表达我对您的千恩万谢，千言万语无法描绘您的千辛万苦。今天，只能轻轻地对您说：母亲节快乐!

俏容犹在，白发却偷生;双手昔日嫩如玉，今日却是纹横生;曾有桃花面与柳肢，此时却已为往事!天下母亲皆爱儿，节日洒泪感亲恩!祝你我母亲节日快乐!

包转发率 篇3

关键词：众核处理器,数据包转发,路由查找,多分枝Trie树,最长前缀匹配

0 引言

随着光纤通信的迅速发展,当前主干网网速已经普遍达到40 Gbps[1],这就对大多数网络设备的转发能力提出了高要求。目前网络设备的高速IP包转发系统大都依赖硬件,根据原理不同可分为两类:一种是使用专门为实现特定功能设计的硬件电路,获取更高的处理速度,这种方案存在硬件成本高、可移植性差等缺点;另一种是基于专用网络处理器和开放系统结构的转发系统,此方案有开发简单、移植性好等优点,但由于处理器架构的限制,其转发性能相对较低。为了解决此问题,1996年美国Stanford大学首次提出片上多处理器思想,即在一个芯片上集成多个CPU内核来提高性能。此结构的处理器具有性能强大、控制逻辑简单、低通信时延等优点,已经成为高性能通用处理器的发展主流[2]。自从IBM推出第一款商用众核处理器以来,众核处理器已经经过十几年的发展。在这个过程中,为了满足网络数据的快速处理的需求,众核网络处理器也得到迅速发展和广泛的应用。

自从1999年以来,大多数半导体公司都相继推出自己的众核网络处理器,目前主流的众核网络处理器包括IBM公司的Power NP系列、Intel公司的IXA系列、Freescale公司的Qor IQ系列、CAVIUM公司的OCTEON系列和Tilera的Tile系列等型号。经过对它们进行综合比较,本文选择Tilera公司的Tile-Gx36众核网络处理器作为此系统的硬件平台。Tile-Gx36是由Tilera公司于2009年推出的一款核心数量为36核的微处理器,它采用40 nm工艺,由36个Tile CPU组成。相对于其他处理器,Tilera处理器拥有数量更多、计算能力更强的CPU,它的每个Tile CPU工作频率高达1.2 GHz;并且拥有更大、更多类型的缓存空间,如每个CPU包含32 KB私有的一级指令缓存和32 KB私有的一级数据缓存、256 KB私有的二级缓存和高达26 MB的共享缓存,CPU之间通过i Mesh高速网络连接起来,CPU之间的访问速度达到66 Tbps,DDR3内存控制器的访问速率可达1333 MT/s。此外,Tile-Gx36还包括4个双万兆以太网控制器(XAUI)。

已有的研究表明,随着网络规模的不断扩张,网络设备需要维护的路由表表项也不断增加,路由表的查找速度直接影响数据包的转发效率[3]。设计和实现一种具有高效的时间复杂度(查找、更新)和空间复杂度的路由查找算法可以进一步提高IP数据包的转发效率。本文引入基于Hash的前缀长度和多分支Trie树的路由查找算法,设计并实现了基于众核网络处理器的高速IP数据包转发系统。

1 系统结构设计

综合以上分析,本文设计了基于众核网络处理器的高速IP包转发系统。系统结构如图1所示,采用Tile-Gx36作为并行处理硬件平台,并结合改进的路由查找算法,实现对IP数据包的高速转发。转发系统由物理万兆网络接口、众核可编程智能数据报引擎m PIPE(Multi-core Programmable Intelligent Packet Engine)、Tile CPU、路由查找、下一跳表查找等几大模块组成,其中Tile CPU是转发模块的核心。

万兆网络接口模块是数据包和物理链路连接的接口,它满足10 Gbps的收发能力。

m PIPE是一个智能数据包收发引擎,在收包时,它有三种负载均衡模式,即轮询调度、动态流绑定和静态流绑定。轮询调度模式下将数据包交给负载最少的CPU来处理。动态流绑定模式下选取源IP地址、目的IP地址、源端口、目的端口、协议类型其中的字段进行哈希运算,具有相同Hash值的数据包将送往与之对应的一组CPU的缓冲队列等待该CPU处理。如果此CPU的缓冲队列已满,则将数据包交给该组CPU中负载最少的CPU来处理;如果该组所有CPU的缓冲队列已满,则丢弃该数据包。静态流绑定模式下选取源IP地址、目的IP地址、源端口、目的端口、协议类型其中的字段进行哈希运算,具有相同Hash值的数据包将送往相同的CPU缓冲队列等待CPU处理。如果此CPU的缓冲队列已满,则直接丢弃数据包。在发包时,直接将数据包交给万兆网络网口发送。

通常情况下网络流量都是多条流同时存在,但当遇到流大小分布不均匀时,一种方法是增大每个CPU数据包的缓冲区来缓存更多的待处理的数据包;另一种方法是为大流分配更多的CPU来处理此流数据包。综合考虑,本文选择动态流绑定模式作为数据包到对应CPU的负载均衡模式。

每个Tile CPU收到需要转发的数据包后,对数据包进行包头检验,检测此数据包是否是正确的报文。如果数据包包头信息不正确则直接丢弃,否则交给下一模块进行处理;路由表查找则根据数据包的目的地址查找路由表,得到此目的地址的路由信息;下一跳表查找则根据路由表查找的路由信息查找NH(Next Hop)表,得到发送接口、下一跳IP地址对应的MAC地址;报文封装模块则根据下一跳表的查询结果对报文进行重新封装。按照系统的数据包转发处理流程,可以将整个系统分为上行处理模块和下行处理模块。

上行处理模块主要包括接收模块和基本转发处理模块。接收模块负责通过m PIPE收包并进行完整性检测,并按照设定的规则,将数据包交给相应的处理器的下一个模块进行处理;基本转发模块负责对报文进行解封装处理、合法性检验、查询路由表项等处理。解封装子模块将数据包的二层头去掉,然后对数据包进行合法性检验。如果数据包正常,则根据目的IP地址查询路由表,否则丢弃数据包。如果查到路由信息,则修改包头TTL和校验和等信息,更新IP包头相关信息,若没有查到,则直接丢弃报文。

下行处理模块主要包括二层封装模块和发送模块。二层封装模块负责根据路由查找结果中的下一跳IP地址信息查询下一跳表NH,得到下一跳MAC地址,然后对数据包封装二层头信息;发送模块负责将封装好的数据包通过m PIPE发送到网络接口上。

2 路由算法方案

为了更有效地利用地址空间,降低路由表规模的增长速度,IETF提出了一种称为无分类域间路由CIDR(Classless Inter Domain Routing)的地址结构。自从CIDR启用以来,IP路由查找的焦点就集中在了最长地址前缀匹配的问题上。传统的路由器执行最长网络前缀匹配的时间很长,使得路由表查找成为路由器转发速度的瓶颈。

目前常用的路由查找算法有基于线性表结构的路由查找算法、基于Hash的前缀长度的路由查找算法和基于多分枝Trie树的路由查找算法。基于线性表结构的路由查找算法是将所有路由表项组成线性表结构,每一次查找需要遍历线性表中的所有表项,遍历过程中记录最长的路由前缀项,直到遍历完整个链表为止[4]。基于Hash的前缀长度的查找算法根据对不同网络掩码维护一个哈希表,当需要查找一个IP地址的路由表项时,把IP地址的32位前缀、31位前缀等分别取出来,到相应前缀长度的哈希表中查找。这种方法结构简单,但是需要维护的Hash表数目众多,查询时需要按照网络掩码长度从高至低依次查找,查找性能较低;但在插入或者删除时,因为已知子网掩码长度,可直接在对应的哈希表中进行插入或删除操作,此方法效率较高。而基于多分支Trie树的路由查找算法,作为基于Trie树路由查找算法的改进算法,它每次查找的比特数(步长)K为大于1的整数。这种查找方案有效增加了每次访问存储器所获取节点的信息数,即每次查找检查的比特数,从而降低了Trie树的深度,减少了存储器访问次数,大幅度提高了路由表的查找性能。假设地址关键字长度为W,步长为K,地址前缀表中前缀数目为N[5],则常用路由查找算法的复杂度[6]如表1所示。

通过表1常用路由查找算法的复杂度可以发现,地址区间的二分查找算法在查找、存储方面性能突出。但在按照前缀更新时,因为插入或者删除每一个关键字有可能会影响多个原有的地址区间,在最坏情况下,更新一个关键字会影响O(N)个地址区间。因此,二分查找法的更新性能较差。而基于Hash的前缀长度路由查找算法在存储和更新的处理上有独特的优势;基于多分支Trie树的路由查找算法因为对一个关键字的查找时间和结点数无关,极大地节约了路由查找的时间。因此,本文提出了一种基于Hash和多分支Trie树的路由查找算法相结合的路由查找算法。使用基于Hash前缀长度路由查找算法将原有的Hash表按照子网掩码长度划分为多张小表用来存储路由节点,相当于用Trie树建立一个一级索引[7];使用基于多分枝Trie树路由查找算法完成路由查找。这样既利用了多分支Trie树的查找速度,也结合了Hash前缀长度算法在存储和更新上的效率,从而提高了路由查找、存储和更新时的整体性能。

2.1 转发表项结构

基于前缀长度和多分支Trie树的路由查找算法中主要包含两种表结构,一种是基于前缀长度和多分支Trie树的路由表RT;另一种是基于Hash的NH表。在路由表中,维护有基于哈希函数的Hash表,用来存放路由节点信息;基于多分支Trie树的索引表,主要负责使用最长前缀匹配算法进行路由查找;基于哈希函数的NH表存放下一跳信息。

如图2所示,路由表表节点结构中的daddr字段表示目的IP地址,mask_len字段表示掩码长度,result字段指向查询路由表所返回的路由信息。其中mask_len字段表示掩码长度,multi_dest标志位标识此IP地址是否为广播或多播,local_dest标志位标识此IP地址是否为本地IP地址,is_neigh标志位表示此IP地址是否为邻居IP地址,nh_idx字段为通过哈希算法得到的此IP地址在NH表中的索引号。NH表节点中oif字段表示发送网络端口,gw_ip指向网关IP地址,dst_mac表示下一跳节点的MAC地址。

2.2 路由表结构

基于Hash的前缀长度的路由查找算法对不同长度的子网掩码分别维护一个哈希表,每个哈希表中存放此子网掩码长度的路由表项;而多分支Trie树的路由查找算法,作为基于Trie树路由查找算法的改进算法,它每次查找的比特数(步长)K为大于1的整数。本文中多分枝Trie树被分为三层,每层的步长依次是16 bit、8 bit、4 bit,理论上第一层有216个节点,第二层有28个节点,第三层有28个节点。但在实际的应用中,由于一些公用的IP地址、专用的IP地址和保留的IP地址不需要有路由表项,所以只剩下大约56K个路由表项。每个表项中都有路由的详细信息,其中路由表中路由查询结果存放在result字段中。本文基于Hash的前缀长度和多分枝Trie树的路由表结构如图3所示。

路由哈希表是基于前缀长度维护的一张哈希表,主要用来存放所有路由节点,每个节点都有完整的路由信息;路由索引表是基于多分枝Trie树的一张Trie表,此表包含存放56K个路由查找节点,其中查询结果字段result直接指向路由哈希表中对应的路由节点。

2.3 路由操作实现

在对路由表进行添加、查找、删除操作前,应该初始化路由表,此步骤包括分配索引表和哈希表所需要的内存空间等。

2.3.1 路由表项的添加算法

路由添加算法首先查询是否已经有此路由信息存在,如果不存在,则更新NH表中的相应表项,否则根据网络掩码长度,将此路由信息节点插入到对应Hash链表中。最后根据子网掩码的长度将路由信息插入到索引表中[7]。详细步骤如下:

(1)根据子网掩码长度和目的IP地址计算出此路由节点在哈希表中所属的位置,然后将此节点添加到对应子网掩码长度对应的Hash链表对应位置。

(2)根据子网掩码长度mask_len来决定将路由信息附加到索引表的对应位置。如果1≤mask_len≤16,则将此路由信息插入到对应的一级路由索引表中;如果17≤mask_len≤24,则将此路由信息插入到对应的二级路由索引表中;如果25≤mask_len≤32,则将此路由信息插入到对应的三级路由索引表中。

2.3.2 路由查找算法

路由查找算法就是对于一个给定的目的IP地址,使用最长前缀匹配算法,通过查询索引表,逐层判断路由前缀相对路由表每层的偏移的表项,找到叶子节点即完成查找。最后根据路由表的查询结果查询NH表,得到发送端口和下一跳信息,具体流程如图4所示。

算法具体查找步骤如下:

(1)根据目的IP地址和一级索引表、二级索引表、三级索引表分别对应的掩码得到此IP地址对应的一级、二级和三级索引表中对应的索引号。

(2)根据IP地址对应的一级索引表的索引号,得到路由表项实例,检验此实例是否有效、正确。如果正确有效则直接返回查找结果,否则执行第3步。

(3)根据IP地址对应的二级索引表的索引号,得到路由表项实例,检验此实例是否有效、正确。如果正确有效则直接返回查找结果,否则执行第4步。

(4)根据IP地址对应的三级索引表的索引号,得到路由表项实例,检验此实例是否有效、正确。如果正确有效则直接返回查找结果,否则返回错误。

2.3.3 路由删除算法

路由删除算法首先查找需要删除的路由节点的前缀的表项或结点的父节点,然后根据目的地址和子网掩码长度删除索引表中的路由信息并更新表结构,最后删除哈希表中相应的路由节点。

3 测试与功能验证

为了验证此高速转发系统的功能及性能,本文将从转发吞吐量和不同负荷下的丢包率两方面进行验证。测试环境包括两台Tile-Gx36众核处理平台,测试环境如图5所示,每个Tile-Gx36由36个Tile核组成,每个核主频为1.2 GHz,设备使用8 GB的DDR3内存,内存的访问速度为1333 MT/s。两台设备通过光模块连接起来,其中Tile发包器用来向4个万兆口按照10 Gbps的速度发出指定长度(64 B、128 B、1518 B)、指定类型(TCP、UDP)的IP报文;Tile-Gx36数据包转发器则主要负责从物理网络接口获取IP数据包并完成转发工作[8]。

测试过程中,在10 000条路由表项条件下,分别采用包长为64 B、128 B和1518 B的IPv4单播包进行吞吐量和丢包率的测试,图6为不同包长的IP报文在不同转发CPU数量下的转发吞吐量。

根据图6的测试结果,对于64 B的小包,当转发CPU达到22个时,可以达到40 Gbps的转发能力;对于128 B的数据包,8个CPU已满足要求;仅使用2个CPU就可以满足对1518 B的IP报文40 Gbps的转发能力。

实验表明,使用22个或以上CPU可以满足对于不同长度的IP数据包40 Gbps的转发性能。同样,对于丢包率的测试,选择长度为64 B的单一包长IP数据包在不同负荷(2核至22核)下进行丢包率统计,如图7所示。发现在满负荷情况时,丢包率都低于10-4,吞吐量接近于1,满足设计性能要求。

4 结语

为了满足对不同包长数据包的高速转发需求,本文提出了基于众核网络处理器的高速IP包转发系统。基于Tile-Gx36众核网络处理器,采用基于前缀长度和多分支Trie树相结合的路由查找算法,保证了查找算法的高效性,又能保证路由信息的易更新性,其综合性能是比较理想的,最终设计并实现了高速转发引擎。经过实验测试,对于不同包长的IP数据包,都满足40Gbps的转发效率,满足预期性能要求。

参考文献

[1]肖月振,华蓓.基于多核处理器的无锁零拷贝数据包转发框架[J].计算机工程,2013,39(12):35-39,53.

[2]郜国良,李广军.一种基于Trie的快速IP路由查找算法[J].微电子学与计算机,2011,28(6):163-167.

[3]谭明锋,高蕾,龚正虎.IP路由查找算法研究概述[J].计算机工程与科学,2006,28(6):77-80,89.

[4]张琦,金胤丞,李苗.Trie树路由查找算法在网络处理器中的实现[J].计算机工程,2014,40(1):98-102.

[5]杜飞,董治国,苗琳,等.基于无冲突哈希表和多比特树的两级IPv6路由查找算法[J].计算机应用,2013,33(5):1194-1196,1202.

[6]Bando M,Lin Y L,Chao H J.Beyond 100-Gb/s IP Route Lookup Using Hash-Based Prefix-Compressed Trie[J].IEEE/ACM Transactions on Networking,2012,20(4):1262-1275.

[7]Fu Y,Liang H,Liu Z.An Effective IP Routing lookup Algorithm based on Network Processor[C]//2008 11th IEEE Singapore International Conference on Communication Systems,2008:1716-1720.