软件BFD会极大消耗CPU能力，受CPU性能影响支持的BFD会话规格较小——当网络规模扩大，需要同时检测成百上千条路径时，软件BFD成为性能瓶颈。新华三集团（H3C）Comware实现的硬件BFD技术，将发送报文、接收报文以及故障检测等消耗CPU性能的功能转移到硬件芯片上处理，从而支持大规格的BFD会话。这份白皮书详细阐述了硬件BFD的运行机制、特殊协商流程与应用限制。
产生背景——软件BFD的性能瓶颈
软件BFD是指BFD检测过程中的报文收发、BFD会话状态机的维护完全依赖CPU来处理。软件BFD会极大消耗CPU能力。同时，受CPU性能影响，能够支持的BFD会话规格较小，无法用于大规格BFD会话需求的应用场景。
随着网络规模扩大和可靠性要求提升，BFD会话数量不断增加。在核心网络节点上，可能需要同时检测数百条甚至上千条路径——软件BFD的CPU消耗成为不可忽视的性能瓶颈。硬件BFD正是在这一背景下应运而生。
echo报文方式的硬件BFD
对于echo报文方式的BFD会话，第一次收到转发回来的echo报文后，BFD会话就会尝试将其转发到硬件芯片处理。具体处理机制如下：如果检测到硬件芯片可以支持BFD，系统会通知软件处理成功，软件不再维护BFD会话；如果检测到硬件芯片不支持BFD，系统会通知软件处理失败，仍然由软件维护BFD会话。
echo报文方式的硬件BFD实现相对简单，因为echo方式本身不涉及会话状态协商，只需要硬件芯片能够识别echo报文、记录会话信息并检测报文接收超时。这使得echo方式的硬件BFD更容易实现大规格部署。
控制报文方式的硬件BFD
控制报文方式的BFD会话状态需要通过控制报文进行协商，硬件芯片的功能比较简单，不能完成BFD会话协商功能。因此在会话状态UP之前，仍然需要通过CPU维护。会话UP之后，会尝试转移到硬件芯片处理。
具体处理机制如下：如果系统检测到硬件芯片可以支持BFD，会通知软件处理成功，软件不再维护BFD会话；如果系统检测到硬件芯片不支持BFD，会通知软件处理失败，仍然由软件维护BFD会话。如果需要调整会话的各种参数，则由软件进行协商。这种“软件协商+硬件检测”的分工模式，既保证了会话协商的灵活性，又实现了故障检测的高性能。
硬件BFD的特殊定时器协商机制
为了支持大规格BFD会话的并发协商能力，在协商定时器时，硬件BFD会话有一些特殊的处理：
本端在DOWN状态收到INIT报文，或者在INIT状态收到UP报文后，BFD会话变成UP状态，并开始向对端发送P字段置位的报文。报文中携带的会话发送时间间隔、接收时间间隔和检测倍数都设置为设备支持的最大值。对端收到P字段置位的报文时，回应F字段置位的报文。
当本端收到对端回应的F字段置位的报文，表明对端已经按照最大值调整好，此时开始尝试将发送时间间隔、接收时间间隔和检测倍数下调到配置的值，并向对端发送新的P字段置位的报文。对端收到新的P字段置位的报文时，回应F字段置位的报文。当本端收到对端回应的新的F字段置位的报文，表明对端已经按照P字段置位的报文中携带的参数调整好了实际发送时间间隔和检测时间。
如果本端未收到对端回应的F字段置位的报文，会持续向对端发送P字段置位的报文，在此期间定时器的值为发起协商前的值。直到收到对端回应的F字段置位的报文，协商过程才能结束。
硬件BFD的应用限制
目前，硬件BFD存在如下限制：硬件芯片对BFD会话的发送时间、接收时间和检测倍数有一定的限制，比如发送时间、接收时间可能要求必须是10ms的整数倍；暂不支持对BFD报文进行认证；硬件BFD的协商较普通BFD的协商流程复杂，因此耗时更久，如果在协商未完成之前链路发生故障，可能导致检测时间较长。
这些限制意味着硬件BFD更适合大规模、对性能要求高的场景，而在需要灵活调整参数或需要认证的特定场景中，软件BFD仍有其价值。实践中需要根据具体应用场景选择合适的BFD实现方式。
