参考: https://www.rfc-editor.org/rfc/rfc5880
- 设计
BFD 就是用于在转发面上 “到下一跳” 连通性的故障检测。
应该在系统中的转发面中实现。 在设计上，转发面和控制面板应该是分离的。
该协议应该和路由协议解耦。 以便于可以和这些协议的“优雅重启”机制无缝配合。
BFD下移工作与任何数据层协议之上（网络层，链路层，隧道等），在两个系统间转发。
可以以单播，p2p模式运行。BFD可以封装与隧道协议的payload中，也可以运行于一个系统中的多种（网络）层。
BFD 可以提供 物理链路层链路，虚拟链路，隧道链路，MPLS label交换机链路，多个下一跳路由链路，以及单向链路。
BFD 状态机实现了创建会话和摧毁会话阶段的三向握手，可以有效保证双方系统都可以意识到状态变化。
BFD可以抽象为一个简单的服务，服务源语即是： 创建，删除，修改会话（基于目标地址和其他参数）。 当BFD会话建立或者down的时候，BFD 会提供一个信号给他的client。
- 协议概览
BFD 只一个简单Hello协议。和现有著名常用的路由协议相关的检测组件相同。
两个系统周期性的传输BFD包，如果一段时间没有传输包，就认定为故障。
当双方沟通建立的时候，会建立一个通信路径（path）。然后会为每一个路径，建立一个独立的BFD会话。
3.1 地址寻址以及会话建立
会话建立是为了满足应用层的需要，需要应用层确定基于BFD的需求以及使用什么地址。 BFD中没有自动发现机制。比如 OSPF协议可能需要请求BFD 会话基于 OSPF Hello 协议来进行链路检测。
3.2 操作模式
BFD 有两种操作模式，主模式是异步模式，该模式下，系统周期性发送BFD控制包到另一个端，如果另一个端没有回复收到，那么这个会话会被宣告为down。
另一个模式叫做demand模式，该模式下，它会假设系统有一个独立的方式来确定他已经连接到另一个系统。一旦BFD会话已经建立，其中一个系统会要求另一个系统停止发送BFD控制包。除非该系统明确感觉应该再次确认连通性。比如控制包发生了改变，或者远程系统。 这种模式应该是不需要频繁发包。
如果需要实时同步就用第一种异步模式，如果需要很久确认一次那就用第二种。
但只要发控制包，就必须要收到回包，否则就会认定会话为down。
发出和控制包是通过echo方法实现的。
- BFD 控制包格式
我们仅关注于非认证部分的内容
Version (Vers) : 版本
Diagnostic (Diag): 诊断码，用于在会话状态中标识本地系统的（故障）原因
0 -- No Diagnostic 没诊断
1 -- Control Detection Time Expired 控制检测时间超期
2 -- Echo Function Failed 回复功能执行失败
3 -- Neighbor Signaled Session Down 邻居标识会话状态为down
4 -- Forwarding Plane Reset 转发面重置
5 -- Path Down （逻辑）路径down
6 -- Concatenated Path Down 级联的路径down
7 -- Administratively Down 行政地管理 down
8 -- Reverse Concatenated Path Down 逆向级联路径down
9-31 -- Reserved for future use 预留
State (Sta)
The current BFD session state as seen by the transmitting system.
Values are:
传输系统看到的BFD的会话状态
0 -- AdminDown
1 -- Down
2 -- Init
3 -- Up
Poll (P) 和F状态位对应
如果设置了，传输系统就会请求连接性的确认，或者参数变更的确认。
并且期望在恢复包中包含F位。如果已经确认，就不再重复确认。
Final (F) 和P状态位对应。
Control Plane Independent (C)
如果设置了，换句话说，BFD 是 在转发平面实现并且即使控制平面的中断了，仍可以继续发挥作用。 这个状态位，是应用层控制的。或者说用户在使用时。
Demand (D)：非周期性发送BFD控制包进行链路连通性检测
Multipoint ：点到多点，未来预留。
Length： BFD包的长度
My Discriminator：
一个唯一的，非0的 区分值，该值由发起端传输系统产生，用于区分一对儿系统中的多个path对应的多个BFD会话。 即 该值就是BFD会话的区分符。
Your Discriminator：
另一端的
Desired Min TX Interval： 期望的最小传输间隔
单位毫秒，本地传输系统会按照这个间隔传输BFD控制包。
Required Min RX Interval：
最小接受间隔多久接受一个BFD包，如果该值为0，表示不希望对端系统发送BFD控制包。
Required Min Echo RX Interval
最小接受间隔多久接受一个BFD Echo包。
- BFD 回声爆粉格式。
BFD回声报文以适合接口的封装方式发送
环境。
BFD Echo报文的负载是本地事务，因为只有发送系统一直在处理BFD Echo报文的负载
唯一的要求是包含足够的信息以便对接收到的信息进行多路分解，然后发送到正确的BFD会话，报文回环后返回给发送者。
- 程序要素
6.1 概述
一个系统，在一个会话的建立过程中，要么扮演主动角色，要么扮演被动角色。
扮演主动角色的系统必须要发送BFD控制包，无论它是否收到该包。
扮演被动角色系统一开始必须保持静默，不发送任何包，直达它收到了对应会话的一个BFD控制包，然后它就学到了发起端远程系统的区分符。
至少一个系统必须扮演主动角色，也有可能两端都扮演。（用户|应用层决定谁扮演）
一个会话开始阶段带有周期参数，传输比较慢，当双方建立了连接，BFD会话就会变为up。
一旦会话建立，一个系统就可以基于条件 启用 Echo function发包了。控制包的传输速率设计上比较低。
如果没有 启用Echo function，那么基于控制包的传输速率来判断会话的检测的必要性就变得很低了。
一旦会话up，那么有可能系统会信号触发进度Demand模式，那么远程系统就会保持静默。那么就要基于其他工具来保活会话。如果一方系统更需要确认双方连接，那么可以通过改变BFD的控制包来实现。
如果不是Demand模式，而且在规定期限内没收到包，会话就会被标记为down。
该状态会包含在发给对端包中的State 域中。
如果会话down了，那么Echo packets 就停了，就回到以低频率发控制包的状态。
如果故障方网络恢复了，经过三房握手，那么就会重建进入up状态。
会话可以通过管理员方式AdminDown的方式直接进入down状态
6.2 BFD 状态机
