一种分布式的高性能PIM-SM组播实坝方案

名称:一种分布式的高性能PIM-SM组播实坝方案
摘要：提出了一种分布式的PlM—SM组播实现方案。将PIM—SM控制平面与数据平面功能分离，数据平面功能利用TCAM+ FPGA 的硬件方式实现，达到快速数据转发的目的，控制平面功能由软件在主控完成，数据平面与控制平面之间通过高速内部网络进行通信。经过实际的测试表明，该方案在保证协议功能一致性的前提下，能够大大提高组播教据转发性能，使数据达到10G接口的线速转发能力，是一种高效可行的PIM—SM组播实现方案。
关键词：分布式P1M—SM组播TCAM+ FPGA 线速转发 在宽带网络的建设和运营中，业务是先导和核心。其中组播业务作为最具潜力的未来业务之一，已经得到了前所未有的重视。IP组播技术具有独特的优越性：在组播网络中，即使用户数量成倍增长，主干带宽也不需要随之增加。随着宽带技术的不断发展，FTP、HTTP、SMTP等传统的数据业务已无法满足人们对信息的需求，而视频点播、远程教学、新闻发布、网络电视等将成为各大运营商争相发展的新型业务，这些业务都可以利用组播实现，使得IP组播技术成为当前网络技术中的研究热点之一。为此，人们开发了多种组播路由协议来支持组播的应用，而HM-SM是目前应用最广泛、功能最强大的一种，适合广域网环境下用户比较分散的组播业务的开展。美国UC-Berkeley最早于 1990 年初开始在MBone上研究基于组播的协同环境，国内也于20世纪90年代后期开始研究和应用组播视频会议。 2004 年4月，在CE]RNET主干网络8个城市10个地区主节点之间成功配置了全程组播(Native multicast)。 2003 年SARS之后，开始向38个省级主节点扩展，其中主要实现了基于PIM-SM的组播视频会议业务。实现高性能PIM-SM组播将会对未来实现大规模组播应用产生深远而重要的影响。
PIM-SM组播通常采用纯软件或者利用ASIC、NP等硬件方式转发。纯软件方式常用于中低端路由器，在转发性能七难以满足核心路由器的要求；由于PIM-SM协议还未完全定型，ASIC转发方式难以更新升级，并且开发周期长不适合在研发阶段采用；而NP方式虽然开发效率高但技术成熟度低。为此，本文提出了一种PIM-SM分布式实现方案。该方案以笔者研发的T比特级路由器为平台，将PIM-SM控制平面与数据平面分离，控制平面在路由器的主控上利用软件方式实现，而数据平面利用TCAM+ FPGA 的方式在路由器的转发子系统上实现。考虑到路由查表的特性，将转发表存放在商用TCAM芯片中，可以充分利用TCAM的关键字查找优势，利用FPCA程序实现转发处理逻辑。这样的设计方式开发简单，成本较低，灵活性强。其实现模型如图1所示。
1 实现难点分析
考察近几年的路由器技术发展，单播路由协议采用硬件转发、软件维护已经不是新的方案。这是因为单播路由表类型比较单一，存放的是下一跳、网络度量、出接口等固定长度的信息，而且协议控制平面与数据平面功能划分清晰。数据平面只用来转发而不影响协议机制的运行，它使用的转发表只需要简单的目的地址和出接口信息(只有一个)，其工作就是对到来的数据包进行目的地址的匹配，然后根据匹配结果直接转发即可。因此，单播协议的转发功能采用硬件方式实现较容易，只需简单的硬件转发表和判定逻辑对数据进行处理，然后交给调度模块直接输出即可。
PIM-SM实现方案的设计可以借鉴单播路由协议的硬件转发模式。但是，它实现硬件转发比单播协议硬件转发困难得多。其主要困难如下：
(1)组播转发过程较为复杂，输入输出项多且输出项不定长。PIM-SM组播路由协议的路由表项类型不单一．多达四种且有匹配优先顺序，数据包的匹配查找逻辑相当复杂。
(2)组播转发表容量庞大，表项宽。受器件水平的限制，硬件实现方案中可能根据可用器件的情况设计多级转发表，而多级查表又限制了硬件实现方案速度优势的发挥。
(3)与单播转发相比，数据包需要硬件复制和交换转发。组播转发不仅大大增加了路由器转发模块的复杂度，而且还增加丁调度模块和接口模块的复杂度。
(4)一些利用软件容易解决的问题，可能利用硬件实现就比较困难，例如转发查表、RPF检查、数据驱动报文处理等。
(5)组播路由协议尚不完善，组播应用还未普及，可以预见在未来的几年中，随着组播应用的发展，IPv4组播路由协议还要不断改进和完善。目前IPv6组播路由协议还未有标准，但是转发设计必须考虑基于IPv6的宴现方式。
这些由协议特性造成的与单播路由协议硬件转发的不同之处，也是PIM-SM实现硬件转发的复杂之处。这种复杂性在具体设计和实现时虽然在一定程度上会增加硬件转发设计的复杂度，但是只要合理设计，采用正确的技术手段和策略，硬件转发的性能优势是很明显的。
2 方案设计
经过分析，不难得出关于。PIM-SM分布式实现方案的大致轮廓。方案总体上可以分为数据平面转发设计、控制平面实现方式设计和平面问通信方式设计三个部分。其中，数据平面转发部分的设计是整个方案的关键和难点，影响着PIM-SM组播的转发性能，其主要难点是转发表格式和转发逻辑的设计，在T比特路由器的转发子系统上实现。协议软件部分负责控制平面的协议行为，应该在T比特路由器的主控子系统上实现，主要工作是维护协泌状态机的运行，与其他模块进行交互，以及对路由表项的更新管理。平面问通信部分包括两方面的工作：路由表下发和数据驱动报文上报。这两部分包括判定、封装、上报和处理等操作，涉及到主控和转发两方面的工作，也是比较复杂的一部分，需要通过高速内部网络进行通信。考虑到在T比特路由器上的实现，PIM-SM实现方案的总体框图如图2所示。
图2中只描绘了一个转发的框图，对于多个转发的情况可以类推。
协议控制平面以及路由表管理部分在主控板上以软件形式实现，数据平面部分在T比特路由器的转发板上利用硬件实现，数据报文经查表后直接转发。主控与转发之间通过高速网络互联，数据驱动报文在转发生成后通过该网络上报给主控的协议软件处理。
值得注意的是，协议报文必须上交给主控进行处理。因此，为减少转发逻辑的复杂度可以将协议报文在线路接口部分判断后直接通过内部网络上交给主控协议栈处理。这样既可减少了硬件转发部分的负担，叉使协议报文的处理不会与数据报文的处理相混淆。
前面已经提到过，影响数据高速转发的关键因素是转发表格式和查表转发算法的设计。因此，必须从保证协议一致性的角度出发考虑哪些功能可以用硬件完成，哪些需要经软件计算后下发。这部分设计的正确与否不仅会影响协议一致性，而且会对转发性能产生影响。经过对协议转发规则的细致分析以及针对本路由器体系结构特点，提出了以下HM-SM转发表格式，如表1所示。该格式支持PIM-SM三种转发项。
查表转发算法包括三部分：查表、结果判别和转发上报。查表部分负责数据包转发表项的匹配，方式是针对数据包利用TCAM中存放的转发表进行关键字匹配，输出查表结果，如果失败则丢弃数据包；结果判别部分包括RPF检查、数据驱动报文判定、查表成败判定等逻辑，根据查表结果信息进行判定；转发上报部分包括正常数据包的转发和数据驱动报文封装上报等操作。其中查表部分相对复杂，时间耗费较多，利用 FPGA 程序实现时需要考虑如何进行性能优化，否则容易导致数据不能及时查表转发，达不到线速转发的要求。数据驱动报文的封装上报等操作可以采用硬件或者软件实现。在路由器中硬件对组播的支持包括两个方面：一是完成硬件查表转发，二是在硬件上支持组播复制。在组播复制的硬件实现中，将组播复制功能放到调度模块实现。调度模块收到转发送来的组播报文后，根据转发所贴标签标识的目的端口号及复制数目进行相应的复制，并直接送到相应端口的 FIFO 。
3 线速转发可行性分析
该分布式设计方案的目的是实现高速数据转发，目标是达到10G接口的线速转发。根据以上设计需要估算一下能否达到线速转发能力和主要限制因素。考虑到查表过程的时间耗费对转发性能的影响最大，从这方面展开对线速转发限制因素的分析。
3.1 线速转发条件
线速转发要求数据包的吞吐率在达到线路接口的最高值时不会丢包，即必须能及时处理所有的数据包，那么衡量的标准为查表的时间应低于单个数据包的线速转发时间。数据包越长，对应的查表时间就越长。因此对短数据包的要求更为苛刻。要在数据速率高达10Gbps的条件下，实现常见最短组播数据包(长度为40字节)的线速转发，则转发处理一个数据包的最长时间为：
(IP报文长度)40×8bit／(端口速率)10Gbps=32ns。
表2给出了不同长度数据包的转发最长时间。
假定商用TCAM芯片的时钟为 100MHZ ，每个时钟周期长10ns，也就是说必须在4个时钟周期内完成查表转发，才能实现最短数据包的线速转发。根据转发表格式的设计，源地址和目的地址作为查表关键字存放于TCAM中，针对IPv4关键字长64bit，IPv6关键字长256bit，使用的TCAM为 NETLOGIC 公司的NSE5512，其容量为 512K x72bit(即：若表项宽度为72位，则该容量(包括掩码)为 512K ×72bit，事实上表项为 256K 条)。该器件的表项宽度可配置为72位、144位、288位和576位，表项配置为144位时，容量为 128K 条；配置为288位时，容量即为64k条。根据笔者设计的转发表格式，组播表的查表关键字设为288位宽。
利用TCAM实现查表所需的总时间T可分为两部分。一部分为查表关键字的输入时间T1，例如对数据总线为72位的TCAM而言，288位查表关键字的输入时间需要4个 FPGA 时钟周期；另一部分为查表关键字搜索TCAM内部表项从而得出查表结果所需的时间，也可以称之为查表结果等待时间T2，目前业界比较先进的TCAM的等待时间通常为10个 FPGA 时钟周期。因此，有：T=T1+T2=14。这说明，采用通常的查表方案在4个时钟周期内无法处理完最短包，10G接口的线速转发无法得到。
3．2 优化查表策略
为了实现10G接口的线速转发，必须设法使得转发查表能在4个时钟周期内完成。而纯粹的TCAM查表不能在4个时钟周期内完成，这就要求必须采用流水查表技术对查表实现方案进行优化。这样，一种由TCAM和 SRAM 共同完成的路由查表流水线方案在此处可以得到应用。该流水查表方案中，TCAM表项仅存储查表关键字，查表结果则存储在相应地址的 SRAM 中。组播查表过程被分解成为三级流水级。其中，一级关键字是组播查表关键字，该关键宇格式应为(S，G)，一级关键字的查表利用TCAM实现；二级关键字是TCAM中表项最低匹配地址，二级关键字的查表利用 SRAM 实现；二级关键字查表结果为最终结果，即出接口等信息。则查表流水线如图3所示。
流水线的功能段完成该段任务所需的时间即为功能段延迟时间，表3列出了IPv4／IPv6组播数据包查表时各功能段的时间延迟。由该表可知，该查表流水线中延迟时间最长的段为“TCAM查表关键字输入”，需要4个 FPGA 时钟周期。
目前，在 FPGA 和TCAM、 SRAM 器件允许的条件下，该查表流水线结构可以支持OC-192接口40字节组播包线速查表。该流水线已经在T比特路由器上得到应用，其具体设计方案不是本文讨论的问题，只用来说明采用TCAM+ FPGA 方式能够实现10G接口线速转发，这一点将由实际测试得到证明。
关于硬件转发性能的测试，RFC建议以最短报文来测试路由器的吞吐量。在同样端口速率下转发小包是对路由器包转发能力最大的考验。笔者进行了测试，测试端口包括10G wAN／LAN和10G POS，利用Spirent通信公司的AX／ 4000 测试仪对该路由器依照RFC2544规定进行转发性能测试。结果10G WAN／LAN接口40字节以上组播数据包均可达到线速转发，10G POS接口70字节以上可达到线速转发。只要 FPGA 程序进一步优化可以实现任意包长的线速转发。本次测试的丢包率为0。64字节的包延迟仅为12.35μs。证明组播数据包能够实现10G线速转发，延迟很小，适合组播应用。
本文结合国家863项目“可扩展到T比特的高性能IPv4／v6路由器基础平台及实验系统”的要求，提出了一种可应用于T比特路由器平台的分布式PIM-SM组播实现方案，采用TCAM+ FPGA 方式实现了高速数据转发，并研究设计了转发表格式和查表转发算法，分析了该方式下线速转发的可行性，并最终得到实际性能的验证。总之，本文提出了一种实现相对简单、高效可行的PIM-SM组播实现方案。它具有较强的创新性，该方案的设计思想不仅可以应用于T比特路由器，同样也适用于其他具有分布式结构的高端路由器。