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

发布者:TranquilJourney最新更新时间:2007-04-02 来源: 电子技术应用关键字:视频  ASIC  逻辑 手机看文章 扫描二维码
随时随地手机看文章

在宽带网络的建设和运营中,业务是先导和核心。其中组播业务作为最具潜力的未来业务之一,已经得到了前所未有的重视。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,其容量为512kx72bit(即:若表项宽度为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比特路由器,同样也适用于其他具有分布式结构的高端路由器。

关键字:视频  ASIC  逻辑 引用地址:一种分布式的高性能PIM-SM组播实坝方案

上一篇:基于C8051F040的CAN总线智能节点设计
下一篇:串行通讯到以太网多路转换的实现

推荐阅读最新更新时间:2024-03-30 21:23

ZDS2022示波器百集实操视频之73:通道耦合与触发耦合
大家好,上期视频我们与大家分享了示波器中的“两反”设置,事实上,在示波器中也有“两耦”设置,其中一个是通道的耦合方式设置,另一个则是触发耦合的设置。 按下通道控制软键,可看到通道耦合的菜单。事实上,通道耦合是决定进入输入通道的信号分量。您可以通过设置通道耦合方式来滤除被测信号中不需要的成分。选中通道耦合软键,ZDS2022示波器通道耦合支持直流、交流和接地三种耦合方式。其中,直流耦合支持被测信号的直流分量和交流分量均可通过。交流耦合是指被测信号的直流分量被阻隔,显示的波形始终以零电压为中心。接地是指内部ADC直接输出0电平。 图1 通道耦合 触发耦合在哪里设置呢?按下【Trigger】键,打开触发菜单,按下触发设置软键,即
[测试测量]
ZDS2022示波器百集实操<font color='red'>视频</font>之73:通道耦合与触发耦合
揭开机器人索菲亚黑幕 真人在后台视频通话
不久前,猎豹董事长傅盛在一次公开演讲中揭出机器人黑幕,索菲亚是假的,娇娇也是假的,目前在全世界范围内,没有一家公司做到机器人与人类对话。 如果不是公众人物公开指出,相信大家都还沉浸在智能机器人的高速发展水平中。通过很多资料,大家对那个在被人求婚时表示自己还是孩子,自爆愿望能够上学成家灭人类的索菲亚坚信不疑,否则也不能成为历史上首个获得公民身份的机器人。当然还有那个国产机器人娇娇,在节目录制现场调侃刘仪伟腿短的机器人,瞬间圈粉无数。而现在竟然被人指正都是假的,其实是真人在后台说话,只是宣传的套路而已。 傅盛表示,所谓的人工智能机器人,只是后台有一个真人视频系统,大家听到的声音,是客服通过类似手机上的变音软件发出来的,去跟现场的人互动
[机器人]
PLC可编程逻辑器件的选择方法
摘要:介绍了在控制系统中选择PLC的一般方法,详细说明了在PLC机型的多样性,以及在PLC的输入输出点数功能等方面作如何选择。 关键词:PLC I/O 选择 开关量 模拟量 数字量 随着PLC的推广普及,PLC产品的种类和数量越来越多,而且功能也日趋完善。近年来,从美国、日本、德国等国引进的PLC产品及国内厂家组装或自行开发的产品已有几十个系列、上百种型号。PLC的品种繁多,其结构型式、性能、容量、指令系统、编程方法、价格等各不相同,适用场合也各有侧重。因此,合理选择PLC,对于提高PLC在控制系统中的应用起着重要作用。 1 机型的选择 PLC机型选择的基本原则是,在功能满足要求的前提下,选择最可靠、维护使用最方便以及性
[工业控制]
2007年北京地区将开播手机电视
  手机电视正式在北京开播,用户将可在手机上免费收看CCTV、BTV等各台节目。昨日,广电总局领导宣布北京地区首个移动多媒体广播(包括手机电视)全面开通。这次成功开播,意味着广电系统主导的手机电视产业全面启动。   2007年覆盖北京所有平原地区   昨天,国家广电总局副局长张海涛宣布,北京DAB移动多媒体广播业务正式启动。   张海涛表示,与电视互联网相比,广播媒介有自身的局限,但它接收便捷、传播迅速、覆盖面广,可移动接收。   北京电台台长汪良表示,目前DAB能同时转播12套北京人民广播电台的现有节目,今后还将陆续转播中央人民广播电台和中国国际广播电台的节目。同时,还将试验转播北京电视台第一套节目和中央电视台新闻频道节
[家用电子]
利用Virtex-5 FPGA实现更高性能的方法
在FPGA系统设计中,要达到性能最大化需要平衡具有混合性能效率的元器件,包括逻辑构造(fabric)、片上存储器、DSP和I/O带宽。在本文中,我将向你解释怎样能在追求更高系统级性能的过程中受益于Xilinx 的Virtex-5 FPGA构建模块,特别是新的ExpressFabric技术。以针对逻辑和算术功能的量化预期性能改进为例,我将探究ExpressFabric架构的主要功能。基于实际客户设计的基准将说明Virtex-5ExpressFabric技术性能平均比前一代Virtex-4 FPGA要高30%。 利用新的逻辑构造(在里面你可以实现诸如计数器、累加器和RAM/ROM存储)和可用的硬IP模块、存储器及DSP(经最优化以运
[嵌入式]
Diodes推出多款八路逻辑器件
Diodes公司 (Diodes Incorporated) 新推出八路逻辑器件丰富了低压CMOS逻辑系列。十三款全新常用的八通道逻辑器件采用节省空间的QFN及TSSOP二十引脚封装 ,适合多种消费性电子及数据通信产品的数据总线应用。 Diodes 74LVC系列新增的八路逻辑功能包括缓冲器和线路驱动器、无线电收发器、锁存器及触发器。新逻辑器件的宽广电源电压范围为1.65V到3.6V,可直接替代现有的行业标准产品,并支持传统和先进的电池供电迷你产品设计。 这些八路逻辑器件的输入电压容差最高达5.5V,还能在混合电压环境内运作自如。产品系列的所有器件通过IOFF电路,使系统设计人员能够灵活进行断电隔离。产品在断
[嵌入式]
Diodes推出多款八路<font color='red'>逻辑</font>器件
4K超高清视频监控产品开始起步
    人们对高清的追求永无止境。2013第14届CPSE安博会上,引领高清监控朝着更高清晰度迈进的4K超高清视频监控产品的亮相让人眼前一亮。虽然目前4K超高清视频监控产品还未达到产品化的阶段,但依然引起了市场的关注。     什么是4K超高清?核心关键技术是什么?应用在哪些领域?4K超高清监控产品的出现会对监控系统提出哪些要求?对产品市场产生怎样的影响?就上述问题,记者采访了创维群欣,宇视科技,英飞拓,海康威视等部分涉入4K监控产品开发的企业。深圳市创维群欣安防科技有限公司产品开发部工程师刘保,深圳英飞拓科技股份有限公司市场部产品经理梁琳琳,宇视科技IPC开发经理余恒乐,管蓓,海康威视技术支持与服务部工程师程玮等人参与了讨论。
[安防电子]
G3视频监控网关:构筑3G时代新生活模式
      3G牌照发放,正式吹响了三大运营商全力开拓3G市场的号角,而家庭市场更是3G整体战略布局中最为关键的拼图之一。利用信息化产品和服务,提升家庭用户的信息化生活水平,助力数字家庭建设推广,就成为全业务竞争时代三大运营商业务创新的新方向。       近日,中国移动广东公司深圳分公司推出了以TD-SCDMA网络为基础的创新型家庭信息化产品——G3视频监控网关(TDHOME)。       该产品是中国移动广东公司深圳分公司以客户需求为导向,创新研发,历时半年时间研发成功的。在2009国际消费类电子产品展上G3视频监控网关首次亮相,就依靠其创新的产品设计理念及功能获得各方好评。日前,通过在广东省移动与其他地市政府签署战
[安防电子]
小广播
添点儿料...
无论热点新闻、行业分析、技术干货……
最新工业控制文章
换一换 更多 相关热搜器件
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved