ASIC芯片中BFD定时器协商机制改进设计与实现
开篇：润墨网以专业的文秘视角，为您筛选了一篇ASIC芯片中BFD定时器协商机制改进设计与实现范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘 要：描述了在电信级以太网芯片中实现BFD快速检测与定时器协商机制的逻辑设计过程，并将硬件逻辑在FPGA仿真芯片中进行了验证。验证了单纯硬件逻辑实现BFD定时器协商机制的可行性，该机制使用软硬件联合设计的改进方法，能够在节约硬件资源的前提下，发挥硬件的速度优势和软件的灵活优势，实现可靠的BFD时间协商过程与快速检测机制。此改进设计经过使用软件和硬件的联合验证，结果表明能够达到预期的效果，并能够实现商业应用。
关键词关键词：asic；BFD；快速故障检测；定时器协商机制
中图分类号：TP302 文献标识码：A 文章编号文章编号：16727800（2013）008002603
0 引言
随着千兆和万兆以太网技术的发展，IP over Ethernet的应用已经从局域网扩展到城域网和广域网，特别是实时语音、视屏点播、云服务等业务的大量应用，使得网络对服务质量（QoS）的要求越来越高，必须达到电信运营商的级别。相对于传统的SDH硬件，目前的IP网络无法实现快速的端到端的链路检测，依靠秒级别的路由协议来实现快速检测已经不能满足当前电信级的业务要求。双向链路检测协议——Bidirectional Forwarding Detection （BFD）能够在系统之间任何类型的通道上实现1s以下的快速检测和恢复，这些通道包括物理链路、IP链路、隧道、MPLS LSP等。BFD使IP网络能够提供客户所需要的高可靠性、高适用性的VoIP等实时业务[1，2]。
一般而言，电信级别的服务质量要求50ms的自动切换，10ms左右的链路检测周期[3]，这对于实现BFD提出了硬件要求。BFD的技术标准提供了微妙到秒的各种数量级的检测周期。当前，秒以上级别的功能已经由软件实现，秒以下级别的链路检测必须依赖于硬件实现。实现快速BFD，一般使用网络处理器（NP）或专用集成电路（ASIC）两种方式。本文提出了一种在ASIC芯片中实现快速bfd的设计，改进BFD协议中动态定时器协商的实现方法，在尽量节约硬件资源的前提下，配合软件以实现多会话（Session）的快速BFD。
1 BFD定时器协商机制
ITEFRFC5880[46]规定了BFD的功能和流程，其核心是通过站点间互相发送短周期的BFD控制报文来检测链路是否出现失效，根据报文中的控制字段和BFD会话状态机的状态迁移来通知上层协议，以使其它机制能够进行快速的链路切换，保证网络通信的及时恢复。
BFD使用三路握手的机制来建立会话，一旦建立会话，BFD会话站点就以特定的频率，持续高速发送和检测接收BFD报文，在链路状态发生变化后，仍然能够通过慢速的报文，等待状态恢复。在电信级网络中，链路的检查周期为3.3ms、10ms、20ms、50ms、300ms和1s[5]，这实际要求硬件定时器的精度要小于1ms。
BFD协议规定了定时器协商机制，在会话建立后，一端能够主动要求对端调整双方的发送和检测报文的频率，发起方将报文中的P字段置位，接收方响应后，在回应报文中将F字段置位，其主要原理为[1，2，5]：
（1）BFD报文发送时间间隔为本端Desired Min TX Interval与对端Required Min RXInterval之中的最大值。
（2）检测时间为对端BFD控制报文中的Detect Mult乘以经过协商的对端BFD控制报文发送时间间隔。
（3）如果加大本端Desired Min TX Interval，那么本端实际发送BFD控制报文的时间间隔必须要等收到对端F字段置位的报文后才能改变。
（4）如果减小本端Required Min RX Interval，那么本端检测时间必须要等收到对端F字段置位的报文后才能改变。
（5）如果减小Desired Min TX Interval，本端报文发送间隔将立即减小；加大Required Min RX Interval，本端检测时间将立即加大。
2 ASIC芯片中BFD定时器协商机制设计
在电信级IP网络中，ASIC芯片处理流程是：报文进入ASIC芯片后，完成对物理层和基本二层的分析，到达入口报文处理单元（Ingress Packet Process Block），根据报文分析器（Packet Parser）的结果和入口处理逻辑，读取入口逻辑表的设置，对报文进行入口处理，然后将报头及转发信息一同发送至集中转发引擎芯片（Fabric Chip）。Fabric芯片根据报头及转发信息，决定该报文是否需要送CPU处理或者转发到系统中其它的包处理器，或者送到BFD引擎（BFD Engine）来进一步做特殊处理，最后将报文送到出口报文处理单元（Egress Packet Process Block）进行出口的逻辑处理。
由于BFD的处理逻辑比较复杂且相对独立，在入口和出口报文处理单元中无法完成相应的功能，所以在设计上，BFD引擎相对独立，并且由自己的SRAM和寄存器进行控制。
BFD引擎设计主要包括全局寄存器设计、BFD表项设计、BFD处理流程设计及相关数据通道。BFD处理流程涉及报文解析、报文发送、定时器检测、事件上报（中断与缓存读写）。电信级的网络处理芯片中，一般支持2k～4k个BFD会话，需要配备相应数量的本端BFD硬件表和对端BFD硬件表，可以分别表示为bfd和rbfd。
参照上节所提到的定时器协商原理，定时器协商机制在芯片中的关键逻辑可以设计成为3个关联的模块：收包处理模块、定时器更新（发送报文与报文超时检测）模块、参数设置（时间协商由用户或上层接口发起）模块。BFD报文解析后，报文的上下文信息放在inpkt缓存中。3个模块的关键逻辑图中标示了bfd和rbfd两个表的主要字段和功能。芯片中收包处理模块、定时器更新模块、用户设置参数模块的微码逻辑图分别为图1、图2、图3。
图1 BFD接收报文处理模块逻辑
图2 BFD发送报文及定时器更新处理模块逻辑
图3 用户设置参数模块逻辑
收包处理模块、定时器更新模块（发送报文与报文超时检测）在设计上具有很强的关联性，并且需要考虑本端主动发起参数协商时的用户接口设计。用FPGA硬件仿真（比真实ASIC降频2 000倍）实现上述逻辑，结果表明，该设计能够在不影响BFD状态机的前提下，处理由用户发起的参数协商，也能够响应对端发起的参数协商，完成时间参数的双向调整。
对于支持2k～4k个BFD会话的ASIC芯片来讲，由于用硬件支持BFD定时器协商机制的开销过高，必须在硬件逻辑中增加P字段报文和F字段报文的处理逻辑，并且在每个bfd表项中增加2个32 bit的字段：bfd.newMinTxInterval，bfd.newMinRxInterval，需要超过128k bit的SRAM空间。同时，软件仍需要保存这2个中间变量与每个bfd会话的主要信息。ASIC设计的原则是让芯片实现对速度要求高但逻辑相对简单的功能，而让软件来实现对速度要求低但逻辑复杂的功能。
考虑到BFD会话发起定时器协商并不是经常性、高频率的事件，并且BFD的机制已经能够容忍因网络故障或对端延迟响应而导致的协商失败，硬件可以只完成高速度、高效率的BFD控制报文的发送和接收，而要求软件配合完成复杂的、对及时性要求不高的定时器协商逻辑。据此，BFD定时器协商机制的硬件和软件的设计改进如下：
（1）删除BFD硬件表项中P、F、newMinTxInterval、newMinRxInterval等4个字段。
（2）删除BFD引擎接收报文处理流程中对报文中P、F字段的处理流程，改为收到P、F置位的报文送CPU，并通知CPU报文类型为BFD_P和BFD_F。
（3）修改BFD引擎报文发送流程，P、F字段始终置0。
（4）软件设计完成相应的定时器协商流程，使用软件表localBfdList存放系统支持的所有BFD会话信息，软件处理CPU收到的BFD报文，并且由CPU发送必要的BFD参数协商报文。
（5）参数协商的用户设置，如果需要立即生效的，则写入硬件表；否则新参数写入localBfdList软件表对应的项中暂存，直到CPU收包流程收到对方回应报文才写入硬件。
核心的软件流程设计如图4。此设计大大降低了硬件开销，依靠软件的灵活性实现了完整的BFD定时器协商机制。
图4 CPU收取和发送报文流程
4 BFD时间协商机制仿真测试与验证结果
上述改进的设计在FPGA上进行芯片仿真并且配合操作系统与软件实现，使用一组设备进行对接测试。测试证明，系统能够建立起2k个BFD会话，并且从一个设备发起时间参数协商，不论是增大或减小本端的Required Min RX Interval或Desired Min TX Interval，另一个设备能够正确响应。BFD硬件表中的各个字段值验证无误。测试证明，本文所提出的设计与改进，能够在节省硬件开销的同时，利用软件设计，实现高速的BFD链路检测与相对慢速的BFD定时器协商机制。
5 结语
BFD的提出解决了IP网络缺乏电信级别服务质量的缺点，各大芯片与网络设备厂商都推出了符合标准的、设计各异的支持BFD功能的产品。BFD的定位在于转发平面，从而脱离具体的网络协议，使快速检测缺陷、实现电信级倒换成为可能，加上BFD处理的低开销使得BFD具有很好的扩展性和更广的适用性。BFD除了应用于IP链路、隧道、MPLS LSP外，更可以应用于当前急速发展的MPLSTP网络，需要更多的技术力量去具体设计与实现。BFD必将成为IP网络电信化的一支重要推动力量。
参考文献参考文献：
[1] 华为技术有限公司.BFD技术白皮书[S].2008.
[2] 杭州华三通信技术有限公司.BFD技术白皮书[S].2008.
[3] INTERNATIONAL TELECOMMUNICATION UNION. ITUT Y.1731[S].2008.
[4] INTERNET ENGINEERING TASK FORCE （IETF） . IETFRFC5880 bidirectional forwarding detection （BFD）[S].2010.
[5] INTERNET ENGINEERING TASK FORCE （IETF） . InternetDraft.Standardized interval support in BFD draftakiyabfdintervals03[S].2013.
[6] INTERNET ENGINEERING TASK FORCE （IETF） . IETFRFC5881 bidirectional forwarding detection （BFD） for IPv4 and IPv6 （single hop）[S].2010.