光纤传输技术发展迅速，网络链路层的接口速率目前已达到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给出了测试数据。