kaiyun官方注册
您所在的位置: 首页> 可编程逻辑> 业界动态> 一种支持多协议的超高速转发引擎的设计与实现

一种支持多协议的超高速转发引擎的设计与实现

2008-07-17
作者:赵峥嵘, 兰巨龙, 曲 晶, 姜

摘 要:从节约FPGA资源的角度出发,分析了超高速条件下多协议" title="多协议">多协议支持策略的实现难点,设计了一种可支持10Gbps" title="10Gbps">10Gbps速率下多协议报文线速转发的引擎结构,解决了FPGA“资源与速度互换”的矛盾。
关键词:路由器转发引擎" title="转发引擎">转发引擎协议


  光纤传输技术发展迅速,网络链路层的接口速率目前已达到10Gbps,出现了诸如10G的LAN、WAN、POS等接口类型。高端路由器作为骨干网的核心交换结点,必须支持10Gbps接口,转发引擎的单包处理时间将急剧缩短。
  另一方面,随着IPv6、组播" title="组播">组播、MPLS协议的成熟及广泛应用,高端路由器也要求提供对以上协议的支持。而不同类型的报文处理流程不尽相同,很难实现通用模块的处理。这无疑增加了超高速转发引擎的设计难度。
  传统的报文处理流程已不能满足超高速转发和多协议支持的要求。作为转发处理的代表方向之一,网络处理器(NP)目前的商用化水平还不支持10Gbps接口,大多不具备多协议支持的能力。
  同时,从自主知识产权的角度出发,也必须在高端路由器上开发自己的转发“芯”。
  本文在深入分析了转发引擎的实现难点后,从提高报文处理速度和节省FPGA资源的角度出发,设计了一种可支持多协议的超高速转发引擎结构,并经国家“863”课题(“大规模接入汇聚路由器ACR”)工程验证,可支持10Gbps接口下多种类型报文的线速转发。
1 10Gbps接口下的线速转发
  表1给出了不同接口下,40字节超短包的线速转发时间。


  对于40字节的超短包,10Gbps接口下的处理时间只有32ns,即使在100MHz时钟下,也只有不到4个周期的时间。而转发引擎的报文处理流程包括报头有效性检查、直连检查、组播RPF检查、查表" title="查表">查表(单、组播、MPLS查表)、报头修改等复杂操作。传统的串行处理流程显然无法满足线速转发的时间要求。
1.1 并行流水线方案
  按照处理流程各步骤之间的时间关系,笔者在对整个处理流程进行了功能划分后,采用流水线设计,缩短了处理时间,如图1。


  引进该方案的最大好处是:整个转发引擎可以处于流水线状态,不必等待单个任务的完成,省去了串行处理中的等待时间。整个流水线的周期等于最长流水段的周期(路由查表),而不是简单的各段周期之和。
  按照这个思路,在实际工程应用时,采用了如下并行流水线引擎结构:
  对某些流水段,可以通过段内的并行设计,进一步缩短处理时间。例如,对图2中的有效性检查模块,可以进一步细化为版本号检查、TTL检查、地址范围检查、Payload Length检查四个子模块,作并行处理,如图3。


1.2 方案分析
  采用并行流水线的设计,其关键在于整个流水线的不断流、不溢出。这要求对各流水段进行精细划分,使各段的周期尽量接近,即实现同步流水线,减少段间的缓存容量。
2 多协议支持策略
  本方案考虑支持的协议为IPv4、IPv6、MPLS,均含单播、组播、二次查表。要支持如此多的协议类型,而不同类型报文的处理流程不尽相同,在时序上很难对齐,难以用通用模块实现,必然需要大量的缓存FIFO。图4给出了其分析。


  可以看出,报头处理的设计非常复杂,资源占用较多。为了合理利用FPGA的内部资源,必须对报头处理单元精心设计。
  报头处理单元要处理的报文包括以下类型:IPv4(单、组播)、IPv6(单、组播)、MPLS(单、组播)6种,加上二次查表,共有12种类型的报文。对此,有如下分析:
  (1)对以上的12种情况各用一个单元进行实现,这就意味着报头处理中任何一处的缓存FIFO都必须生成12个。
  (2)粗略划分成IPv4、IPv6和MPLS三种实现单元,每一个单元又采用单组播独立实现的方式,也就是将二次查表和非二次查表的报头处理做成通用处理方式。这样也需要6套FIFO缓存报文。
  (3) 只分成IPv4、IPv6和MPLS三种情况,对单播和组播、二次查表以及非二次查表做成通用的处理模块,这样内部需要3套缓存FIFO。
  (4) 与(3)的区别在于,通过精细设计报头处理单元的各种读写信号(上报、转发、二次查表),使得报头处理单元内部不需要缓存报文,报头处理主要完成生成内部报头(转发、上报和二次查表),将缓存FIFO合并为一个,不管是IPv4、IPv6还是MPLS共用一个转发FIFO和上报FIFO。
  为节省FPGA资源,提高设计可靠性,笔者在实际工程中采用了方案(4)的设计方法。其实现结构如图5。


  方案分析:显然,该设计方案在节省资源的同时,复杂了内部逻辑的设计,因为任何一个报头处理都需要同时完成单播和组播、非二次查表和二次查表的统一处理,而且各种报文都统一存放于一个缓存FIFO,因此还需要IPv4、IPv6和MPLS报头处理单元中的转发设计和上报设计进行时序对齐,即从缓存FIFO读出报文的同时送往转发和上报,供两路同时使用(在转发和上报都有效时),需要二者的时序进行配合。
3 工程应用
  该方案已应用在“大规模接入汇聚路由器ACR”的10G转发引擎上,采用的FPGA为VIRTEX PRO系列的XC2VP70芯片。图6给出了测试数据。


  分析:
  (1) 单一包长测试条件下,在负荷为100%时,当包长大于等于109.5字节时的丢包率低于1.07E×10-6,吞吐率接近于1。
  (2) 混合包传输条件下,在端口负荷低于90%时,丢包率低于3.0E×10-4
  本文着重结合项目需要,解决了10Gbps线速转发和多协议支持两个问题。通过并行流水线设计,缩短了报文处理时间。而通过报头处理内部各模块的时序配合,减少了FPGA内部缓存FIFO的使用,节省了FPGA资源,保证了该设计的工程实用性。方案的难点在于报头综合处理单元的时序逻辑设计。
  可以预见,链路接口速率即将突破40Gbps,可以考虑采用多条类似流水线并行处理的引擎结构,但将面临流量均衡及转发表效率的问题,这是下一步的研究方向之一。
参考文献
1XilinxCorporation.RocketIO transceiver user guide[Z].UG024 (v2.3.2)June 24,2004
2XilinxCorporation.Virtex pro platform FPGA handbook.2003
3 Mohammad J.Akhbarizadeh and mehrdad nourani. An IP packet forwarding technique based on partitioned lookup table
4 Newman P, Minshall G, Huston L. IP switching and gigabitrouters.

本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306116;邮箱:aet@chinaaet.com。
Baidu
map