1、BFD 技术白皮书华为技术有限公司Huawei Technologies Co., Ltd.BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 i目 录1 BFD技术应用定位 .12 BFD技术介绍 .12.1 协议概述 .12.2 报文格式 .22.3 检测模式 .32.4 发送周期及检测时间 .42.5 参数修改 .52.6 会话建立 .52.6.1 会话初始化过程 .52.6.2 会话建立过程 .63 BFD的标准化 .84 华为BFD进展情况及典型应用 .94.1 应用于快速重路由 .94.2 应用于媒体网关与核心网的可靠连接 .115 结束语.11附录A
2、 参考资料 .12附录B 缩略语 .12BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 1BFD技术白皮书【摘要】BFD(双向转发检测 )是一套用来实现快速检测的国际标准协议，提供一种轻负荷、持续时间短的检测。与以往的其他”HELLO”检测机制相比，具有许多独到的优势。华为公司已经在高端网络产品上实现了BFD技术，并将提供整套解决方案。【关键字】BFD、快速检测1 BFD 技术应用定位网络设备一个越来越重要的特征是，要求对相邻系统之间通信故障进行快速检测，这样在出现故障时可以更快的建立起替代通道或倒换到其他链路。目前，一些硬件如SDH等可以提供这个功能，但是对
3、于很多硬件或者软件无法提供这个功能，比如以太网。还有一些无法实现路径检测，比如转发引擎或者接口等，无法实现端到端的检测，在目前的网络一般采用慢Hello机制，尤其在路由协议中，在没有硬件帮助下，检测时间会很长（例如：OSPF需要 2秒的检测时间， ISIS需要1秒的检测时间），这对某些应用来说时间太长了，当数据速率到吉比特时，缺陷感应时间长代表着大量数据的丢失，并且对于不允许路由协议的节点没有办法检测链路的状态。同时，在现有的IP网络中并不具备秒以下的间歇性故障修复功能，而传统路由架构在对实时应用（如语音）进行准确故障检测方面能力有限。伴随着VoIP应用的激增，实现快速网络故障检测和修复越发显
4、得必要。BFD协议的出现，为上述问题提出了一种解决方案，BFD能够在系统之间的任何类型通道上进行故障检测，这些通道包括直接的物理链路，虚电路，隧道，MPLS LSP，多跳路由通道，以及非直接的通道。同时正是由于BFD实现故障检测的简单、单一性，致使BFD能够专注于转发故障的快速检测，帮助网络以良好QoS 实现语音、视频及其它点播业务的传输，从而帮助服务提供商基于IP网的实现，为客户提供所需的高可靠性、高适用性VoIP及其它实时业务。2 BFD 技术介绍2.1 协议概述BFD是一个简单的“Hello”协议，在很多方面，它与那些著名的路由协议的邻居检测BFD 技术白皮书 http:/ 2007 华
5、为技术有限公司 版权所有，侵权必究 2部分相似。一对系统在它们之间的所建立会话的通道上周期性的发送检测报文，如果某个系统在足够长的时间内没有收到对端的检测报文，则认为在这条到相邻系统的双向通道的某个部分发生了故障。在某些条件下，为了减少负荷，系统之间的发送和接收速率需要协商。 2.2 报文格式BFD发送的检测报文是UDP报文，定义两种类型的报文 控制报文其格式如下：强 制 部 分0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1Vers Diag Sta DPFCA R Detect Mult Leng
6、thMy DiscreaminatorYour DiscreaminatorDesired Min TX IntervalRequired Min RX IntervalRequired Min Echo RX IntervalAuth Type Auth Len Authentication Data 可 选 部 分强 制 部 分可 选 部 分 Vers：BFD协议版本号，目前为1 Diag：诊断字，标明本地BFD系统最近一次会话状态发生变化的原因 Sta：BFD 本地状态 P：参数发生改变时，发送方在BFD报文中置该标志，接收方必须立即响应该报文 F：响应P标志置位的回应报文中必须将 F标
7、志置位 C：转发/控制分离标志，一旦置位，控制平面的变化不影响BFD检测，如：控制平面为ISIS，当ISIS重启/GR时，BFD可以继续监测链路状态 A：认证标识，置位代表会话需要进行验证 D：查询请求，置位代表发送方期望采用查询模式对链路进行监测 R：预留位BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 3 Detect Mult：检测超时倍数，用于检测方计算检测超时时间 Length：报文长度 My Discreaminator：BFD会话连接本地标识符 Your Discreaminator：BFD会话连接远端标识符 Desired Min Tx Int
8、erval：本地支持的最小BFD报文发送间隔 Required Min RX Interval：本地支持的最小BFD接收间隔 Required Min Echo RX Interval：本地支持的最小Echo报文接收间隔（如果本地不支持Echo功能，则设置0） Auth Type：认证类型，目前协议提供有 Simple Password Keyed MD5 Meticulous Keyed MD5 Keyed SHA1 Meticulous Keyed SHA1 Auth Length：认证数据长度 Authentication Data：认证数据区其中认证部分为可选部分，可以在报文中选择使用
9、，其中认证方式可以有：Simple Password、Keyed MD5、Meticulous Keyed MD5、Keyed SHA1、Meticulous Keyed SHA1。协议定义了控制报文所使用的 UDP目的端口号为3784 。 回声报文（ECHO）BFD协议并未定义回声报文的格式，但是对于回声报文，其格式只是与本地相关，远端只需把此报文在反向通道上返回，对于本地系统必须能够根据报文中相应的内容分离到相应的会话上（所以对于回声包的发送，及其接收处理在协议中都没有定义）。协议定义了回声包所使用的UDP目的端口号为3785 。2.3 检测模式BFD协议描述了实现双向检测的机制，可分为两
10、种：异步模式、查询模式，另外还有一种辅助功能回声功能，它可以与这两种模式结合起来使用。异步模式和查询模式的本质BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 4区别在于检测的位置不同，异步模式下本端按一定的发送周期发送BFD控制报文，需要在远端检测本端系统发送的BFD控制报文；而在查询模式下检测本端发送的BFD控制报文是在本端系统进行的 异步模式在异步模式下，系统之间相互周期性地发送BFD控制包，如果某个系统在检测时间内没有收到对端发来的BFD控制报文，就宣布会话为Down 查询模式在查询模式下，假定每个系统都有一个独立的方法用来确认它连接到其他系统。这样一旦
11、一个BFD会话建立起来以后，系统停止发送BFD控制报文，除非某个系统需要显式地验证连接性，在需要显式验证连接性的情况下，系统发送一个短系列的BFD控制包，如果在检测时间内没有收到返回的报文就宣布会话为Down，如果收到对端的回应报文，协议再次保持沉默。 回声功能本地发送一系列BFD回声报文，远端系统通过它的转发通道将它们环回回来。如果本地系统连续几个回声报文都没有接收到，会话就被宣布为Down。回声功能可以和上述两种检测模式一起使用，可以使用回声功能来代替BFD控制报文的检测的任务，这样可以降低控制报文的发送周期（异步模式下）或者完全取消BFD控制报文（查询模式下）。2.4 发送周期及检测时间
12、对于发送周期的计算与检测模式无关，无论在那种检测模式下，由于要考虑到链路的抖动，需要一个允许的范围，其具体的计算发送如下所述：如果DetectMulti为1，发送周期=(90%70%) * max(bfd.DMTI, 接收的RMRI) ；否则，发送周期 = (100%75%) * max(bfd.DMTI, 接收的RMRI)。对于检测时间，由于BFD存在两种检测模式，所以对于这两种检测模式下相应检测时间的计算并不完全相同。由于两种检测模式下都可以使用回声功能，对于回声包的检测时间的计算草案中并没有给出，任何一种可以检测回声包丢失的机制都可以。 异步模式在异步模式下，由于检测的位置是在对端，所以
13、对端计算检测时间时需要用到本端的BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 5检测倍数，公式如下：检测时间 = 接收的远端DM * max(bfd.RMRI,接收到的DMTI)。 查询模式在查询模式下，由于检测的位置是在本端，所以本端计算检测时间时只需用本端的检测倍数，公式如下：检测时间 = bfd.DM * max(bfd.RMRI,接收到的DMTI)。2.5 参数修改BFD的各种参数在会话建立起来以后都可以动态的改变，但是不影响会话的当前状态，其中可以动态改变的参数有：DMTI、RMRI、使能去使能 ECHO功能、使能去使能查询功能、使能去使能认证等。
14、对于DMTI增加时，本地实际的发送间隔不能改变直到接收一个F比特为1的BFD 控制报文，这是为了保证远端系统在本地发送间隔增加时更新了它的检测时间；对于RMRI减少时，远端计算的检测时间必须不能改变，直到接收到一个F比特（参见报文格式字段解释）为1的BFD控制报文。这是为了保证在减少检测时间之前，远端系统已经按照较高的速率发送BFD控制报文2.6 会话建立BFD在检测前，需要在通道两端建立对等会话，会话建立以后以协商后的速率各自向对端发送BFD的控制报文来实现故障检测。其会话检测的路径可以是标记交换路径，也可以是其它类型的隧道或是可交换以太网。2.6.1 会话初始化过程对于BFD会话建立过程中
15、的初始化阶段，两端是主动角色还是被动角色是由应用来决定的，但是至少有一端为主动角色，所以对于初始化阶段可以分为两种方式。 两端都为主动方当两端都为主动角色时，两端的系统都要向对端发送Your Discriminator 为0的BFD控制报文，直到两端学到对端的Discriminator，然后开始建立会话（例如：由 OSPF或者ISIS建立的BFD会话可以是两端都为主动角色）。BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 6当两端都为主动方时，由于Your Discriminator字段为0，依据BFD协议无法分离到相应的会话上，所以对于初始化报文需要其它的方
16、法： 对于 1hop：第一个报文的分离依据接收报文的接口（无论是物理链路还是逻辑链路），同时收到报文TTL必须为255 。 对于 multihop： 方法 1：限制配置在单一 BFD 会话上的（源地址，目的地址）对唯一。在 OSPF的虚链路上建立 BFD 会话时可以使用这种方法。 方法 2：在会话建立之前先用带外的方式得到对端的 Discriminator。在 MPLS的 LSP 上建立会话时可以使用这种方法。 方法 3：使用两条单向链路，初始化报文的分离类似 1hop，对其中的一条单向链路来说，会话在建立前一个为主动方、一个被动方，被动方根据接收报文的接口来分离 Your Discrimin
17、ator 为 0 的 BFD 控制报文。 一端主动方、一端被动方一端为主动角色、一端为被动角色时，是由应用来决定谁是主动角色、谁是被动角色的，主动方首先发送报文，然后由应用把对端的Discriminator携带回来给主动方，被动方在收到主动方的报文后也开始发送报文，以后主动方和被动方发送的报文中Your Discriminator都不为零，每端都依据相应的Discriminator把控制报文分离到本端相应的会话上（例如：由LSP-Ping建立的BFD会话）。2.6.2 会话建立过程会话建立过程是一个三次握手的过程，经过此过程后两端的会话变为Up状态，在此过程中同时协商好相应的参数，以后的状态变
18、化就是根据缺陷的检测结果来进行，并做相应的处理。其状态机迁移如下：BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 7upDOWNINIT UPinitdown,timer init,upinit,updowndowntimer Up stae in packetup:init Init t i tdow:Down stae in packetUp stUP:Init staeINITDown staeDOWtimer:Control detction timeexir图 1 BFD 状态迁移图以BFD会话连接建立过程为例，简要介绍状态机迁移过程：downPac
19、ket ransmit downBFD OWN intBFD OWNBFD INTBFD INTintBFD UPBFD UPdown = intint = up down = intint = upA B:Point f changi stae(i sedi pckt):Point f changi stae(Lol)X = Y:Resault of changite (Ll)BFD OWN:DOWN stae in packetBFD INT:INT stae in packetBFD UP:UP stae in packet图 2 BFD 会话连接建立 A、B 两站启动BFD，各自初始状
20、态为“down”，发送BFD报文携带状态为“down” B站收到状态为“down ”的BFD报文，本地状态切换至 “init”，发送BFD报文携带状态为“init”BFD 技术白皮书 http:/ 2007 华为技术有限公司 版权所有，侵权必究 8 B站本地BFD状态为“init”后，再接收到状态为“down”的报文不做处理 A站BFD状态变化过程同上 B站收到状态为“init ”的BFD报文，本地状态切换至“up ” A站BFD状态变化过程同上 A、B 两站在发生“down = init”变化后，会启动一个超时定时器，该定时器的作用是防止本地状态阻塞在“init”（有可能AB连接此时断连，会
21、话不能正常建立），如果在规定的时间内仍未收到状态为“init/up ”的 BFD报文，则状态自动切换回“down” 本地状态UP标志会话建立成功3 BFD 的标准化自从2004年7月推出BFD标准的第一个草案起，ietf开始了 BFD协议的讨论修订，至今已经从draft base-00发展到draft base-03，在这期间经历了一次版本的变化，从版本 0升级为版本1。下图是 BFD的发展进程示意图： Aug 04 Submit the base protocol specification to theIESG to be considered as a Proposed Standard
22、. Aug 04 Submit BFD encapsulation and usage profile for single-hop IPv4 andIPv6 adjacencies to the IESG to be considered as a Proposed StandardAug 04 Submit BFD encapsulation and usage profile for MPLSLSPs to the IESG to be considered as a Proposed StandardNov 04 Submit BFD MIB to the IESG to be con
23、sidered as Proposed Standard.Feb 05 Submit BFD encapsulation and usage profile for multi-hop IPv4 andIPv6 adjacencies to the IESG to be considered as a Proposed StandardDraft base-002004.7Draft base-012005.2Draft base-022005.3 Draft base-032005.7BFD协议已经被整个业界所接受和认可。虽然BFD技术标准是一个新的协议标准，但是在大量厂商参与的情况下，我们相信BFD技术将更加完善和成熟。以后必将形成一个技术成熟，众多厂商支持，得到广泛应用的国际标准技术。
