附录 A. OSPF 数据格式
A. OSPF 数据格式（OSPF data formats）
本附录描述 OSPF 协议报文和 OSPF LSA 的格式。OSPF 协议直接运行在
IP 网络层之上。在描述任何数据格式之前，先说明 OSPF 封装的细节。
接下来描述 OSPF Options 字段。该字段描述了 OSPF 路由域中各个部分
可能支持也可能不支持的各种能力。OSPF Options 字段包含在 OSPF Hello
报文、Database Description 报文以及 OSPF LSA 中。
OSPF 报文格式在 A.3 节中详细说明。OSPF LSA 的描述见 A.4 节。
A.1 OSPF 报文的封装
OSPF 直接运行在 Internet Protocol 的网络层之上。因此 OSPF 报文仅由
IP 头和本地数据链路头封装。
OSPF 没有定义对其协议报文进行分片的方法；在发送大于网络 MTU 的
报文时，它依赖 IP 分片。如有必要，OSPF 报文的长度最大可达 65,535
字节（含 IP 头）。那些可能较大的 OSPF 报文类型（Database
Description 报文、Link State Request、Link State Update 和 Link
State Acknowledgment 报文）通常可以被拆分成若干独立的协议报文，
而不损失功能。推荐这样做；应尽可能避免 IP 分片。基于同样的理由，
除非正在执行 Path MTU Discovery（路径 MTU 发现，见 [Ref22]），
否则应尽量把通过 virtual link 发送的 OSPF 报文大小限制在 576 字节。
OSPF 的 IP 封装还有以下重要特性：
o 使用 IP 组播。当通过 broadcast 网络发送时，某些 OSPF 消息是
组播的。使用了两个不同的 IP 组播地址。发送到这些组播地址的
报文绝不应被转发；它们只应传播单跳。为确保这些报文不会传播
多跳，其 IP TTL 必须设为 1。
AllSPFRouters
该组播地址被分配的值为 224.0.0.5。所有运行 OSPF 的路由器
都应准备好接收发往该地址的报文。Hello 报文总是发往这个
目的地。此外，在泛洪过程中某些 OSPF 协议报文也发往该地址。
AllDRouters
该组播地址被分配的值为 224.0.0.6。Designated Router 和
Backup Designated Router 都必须准备好接收发往该地址的
报文。在泛洪过程中某些 OSPF 协议报文发往该地址。
o OSPF 的 IP 协议号是 89。该编号已在 Network Information Center
注册。IP 协议号的分配记录在 [Ref11] 中。
o 所有 OSPF 路由协议报文都使用 [Ref12] 中定义的普通服务 TOS 值
（二进制 0000）发送。
o 路由协议报文发送时把 IP precedence（优先级）设为 Internetwork
Control。无论是发送还是接收，OSPF 协议报文都应优先于普通的
IP 数据流量。把 IP 头中的 IP precedence 字段设为 Internetwork
Control [Ref5] 有助于实现这一目标。
A.2 Options 字段
OSPF Options 字段出现在 OSPF Hello 报文、Database Description
报文以及所有 LSA 中。Options 字段使 OSPF 路由器能够支持（或不支持）
可选能力，并把它们的能力级别告知其他 OSPF 路由器。通过这一机制，
能力各异的路由器可以在一个 OSPF 路由域中混合部署。
在 Hello 报文中使用时，Options 字段允许路由器因能力不匹配而拒绝
某个邻居。另一种做法是，当能力在 Database Description 报文中交换时，
路由器可以因某个邻居功能受限而选择不向它转发某些 LSA。最后，在
LSA 中列出能力，使得路由器可以把功能受限的路由器排除在路由表计算的
某些部分之外，从而绕开这些路由器转发流量。
OSPF Options 字段已分配了五个位，但本备忘录只完整描述了其中一个
（E-bit）。下面简要描述每一位。路由器在发送 Hello 报文或 Database
Description 报文以及始发 LSA 时，应重置（即清零）Options 字段中
无法识别的位。反过来，路由器在收到的 Hello 报文、Database
Description 报文或 LSA 中遇到无法识别的 Option 位时，应忽略该能力
并正常处理该报文/LSA。
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
Options 字段
E-bit
该位描述 AS-external-LSA 的泛洪方式，见本备忘录的 3.6、9.5、
10.8 和 12.1.2 节。
MC-bit
该位描述是否按照 [Ref18] 中的规范转发 IP 组播数据报。
N/P-bit
该位描述 Type-7 LSA 的处理方式，见 [Ref19] 的规定。
EA-bit
该位描述路由器接收和转发 External-Attributes-LSA 的意愿，
见 [Ref20] 的规定。
DC-bit
该位描述路由器对 demand circuit（按需电路）的处理方式，
见 [Ref21] 的规定。
A.3 OSPF 报文格式
共有五种不同的 OSPF 报文类型。所有 OSPF 报文类型都以一个标准的
24 字节头部开始。下面首先描述该头部。然后在后续各节中分别描述
每种报文类型。在这些小节中，先展示每种报文的字段划分，然后逐一
列举字段定义。
除 OSPF Hello 报文外，所有 OSPF 报文类型都处理 LSA 列表。例如，
Link State Update 报文实现了 LSA 在整个 OSPF 路由域中的泛洪。
正因如此，除非同时理解 LSA 的格式，否则无法解析 OSPF 协议报文。
LSA 的格式在 A.4 节中描述。
OSPF 报文的接收处理在 8.2 节中详细说明。OSPF 报文的发送在 8.1 节
中解释。
A.3.1 OSPF 报文头部
每个 OSPF 报文都以一个标准的 24 字节头部开始。该头部包含了判断
是否应接受该报文作进一步处理所需的全部信息。该判断过程在本规范的
8.2 节中描述。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
OSPF 版本号。本规范记录的是该协议的版本 2。
Type
OSPF 报文类型如下。详见 A.3.2 至 A.3.6 节。
Type 描述
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length
OSPF 协议报文的长度（字节）。该长度包含标准 OSPF 头部。
Router ID
报文源端的 Router ID。
Area ID
一个 32 位数字，标识该报文所属的区域。所有 OSPF 报文都与单个
区域关联。大多数只传播一跳。通过 virtual link 传输的报文被
标记为 backbone 的 Area ID 0.0.0.0。
Checksum
对报文全部内容（从 OSPF 报文头部开始，但不包括 64 位的
authentication 字段）计算的标准 IP 校验和。该校验和按如下方式
计算：对报文中所有 16 位字（authentication 字段除外）求反码和，
再取其 16 位反码。如果报文长度不是 16 位字的整数倍，则在计算
校验和之前用一个零字节填充。该校验和被视为报文认证过程的一部分；
对于某些认证类型，校验和计算会被省略。
AuType
标识该报文所使用的认证过程。认证在本规范的附录 D 中讨论。
当前已定义的认证类型列表请查阅附录 D。
Authentication
一个 64 位字段，供认证方案使用。详见附录 D。
A.3.2 Hello 报文
Hello 报文是 OSPF 报文类型 1。这些报文在所有接口（包括 virtual
link）上周期性发送，以便建立和维持邻居关系。此外，在具备组播或
广播能力的物理网络上，Hello 报文以组播方式发送，从而实现相邻路由器
的动态发现。
连接到同一个网络的所有路由器必须在某些参数上达成一致（Network
mask、HelloInterval 和 RouterDeadInterval）。这些参数包含在 Hello
报文中，因而差异会阻止邻居关系的形成。关于 Hello 报文接收处理的
详细解释见 10.5 节。Hello 报文的发送在 9.5 节中说明。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network mask
与该接口关联的网络掩码。例如，如果该接口连接到一个使用第三
字节做子网划分的 B 类网络，则网络掩码为 0xffffff00。
Options
路由器所支持的可选能力，见 A.2 节的说明。
HelloInterval
本路由器发送 Hello 报文的间隔秒数。
Rtr Pri
本路由器的 Router Priority。用于（Backup）Designated Router
选举。如果设为 0，该路由器将没有资格成为（Backup）Designated
Router。
RouterDeadInterval
在宣告一台沉默的路由器已失效之前所等待的秒数。
Designated Router
在发送方路由器看来，该网络的 Designated Router 的身份。
Designated Router 在这里用它在该网络上的 IP 接口地址标识。
如果没有 Designated Router，则设为 0.0.0.0。
Backup Designated Router
在发送方路由器看来，该网络的 Backup Designated Router 的身份。
Backup Designated Router 在这里用它在该网络上的 IP 接口地址
标识。如果没有 Backup Designated Router，则设为 0.0.0.0。
Neighbor
近期在该网络上收到过其有效 Hello 报文的每台路由器的 Router
ID。"近期"是指在最近 RouterDeadInterval 秒内。
A.3.3 Database Description 报文
Database Description 报文是 OSPF 报文类型 2。这些报文在 adjacency
正在初始化时交换。它们描述链路状态数据库的内容。可以使用多个报文
来描述该数据库。为此采用了一种轮询-响应（poll-response）过程。
其中一台路由器被指定为 master，另一台为 slave。master 发送
Database Description 报文（轮询），由 slave 发送的 Database
Description 报文（响应）予以确认。响应通过报文的 DD 序列号与轮询
相关联。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Database Description 报文的格式与 Link State Request 报文和 Link
State Acknowledgment 报文都非常相似。这三者的主体部分都是一个条目
列表，每个条目描述链路状态数据库的一个片段。Database Description
报文的发送记录在 10.8 节。Database Description 报文的接收记录在
10.6 节。
Interface MTU
可以从关联接口发出而无需分片的最大 IP 数据报的字节大小。常见
Internet 链路类型的 MTU 可在 [Ref22] 的表 7-1 中找到。在通过
virtual link 发送的 Database Description 报文中，Interface MTU
应设为 0。
Options
路由器所支持的可选能力，见 A.2 节的说明。
I-bit
Init 位。当设为 1 时，该报文是 Database Description 报文序列
中的第一个。
M-bit
More 位。当设为 1 时，表示后面还有更多的 Database Description
报文。
MS-bit
Master/Slave 位。当设为 1 时，表示该路由器在 Database Exchange
过程中是 master。否则，该路由器是 slave。
DD sequence number
用于给这组 Database Description 报文排序。初始值（由 Init 位
被置位来指示）应当是唯一的。此后 DD 序列号递增，直到完整的
数据库描述发送完毕。
报文的其余部分由链路状态数据库各片段的（可能是部分的）列表构成。
数据库中的每个 LSA 都由其 LSA 头部描述。LSA 头部记录在 A.4.1 节。
它包含唯一标识该 LSA 及其当前实例所需的全部信息。
A.3.4 Link State Request 报文
Link State Request 报文是 OSPF 报文类型 3。在与相邻路由器交换
Database Description 报文之后，路由器可能发现它的链路状态数据库
有部分内容已经过时。Link State Request 报文用于请求邻居数据库中
更新的那些片段。可能需要使用多个 Link State Request 报文。
发送 Link State Request 报文的路由器心中已有它所请求数据库片段的
确切实例。每个实例由其 LS sequence number、LS checksum 和 LS age
定义，尽管这些字段并未在 Link State Request 报文本身中指定。
路由器收到的响应中可能包含更新的实例。
Link State Request 报文的发送记录在 10.9 节。Link State Request
报文的接收记录在 10.7 节。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
每个被请求的 LSA 由其 LS type、Link State ID 和 Advertising
Router 指定。这唯一地标识了该 LSA，但不标识其实例。Link State
Request 报文被理解为对最新实例（无论那是什么）的请求。
A.3.5 Link State Update 报文
Link State Update 报文是 OSPF 报文类型 4。这些报文实现了 LSA 的
泛洪。每个 Link State Update 报文把一组 LSA 从其始发点向外携带
一跳。单个报文中可以包含若干个 LSA。
在支持组播/广播的物理网络上，Link State Update 报文以组播方式发送。
为使泛洪过程可靠，被泛洪的 LSA 在 Link State Acknowledgment 报文
中被确认。如果需要重传某些 LSA，重传的 LSA 总是直接发送给邻居。
关于 LSA 可靠泛洪的更多信息，请查阅第 13 节。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs
本次更新中包含的 LSA 数量。
Link State Update 报文的正文由一个 LSA 列表构成。每个 LSA 都以一个
公共的 20 字节头部开始，见 A.4.1 节的描述。各类 LSA 的详细格式在
A.4 节中描述。
A.3.6 Link State Acknowledgment 报文
Link State Acknowledgment 报文是 OSPF 报文类型 5。为使 LSA 的泛洪
可靠，被泛洪的 LSA 会被显式确认。该确认通过发送和接收 Link State
Acknowledgment 报文来完成。单个 Link State Acknowledgment 报文中
可以确认多个 LSA。
取决于发送接口的状态以及相应 Link State Update 报文的发送者，
Link State Acknowledgment 报文要么发送到组播地址 AllSPFRouters，
要么发送到组播地址 AllDRouters，要么以单播方式发送。Link State
Acknowledgment 报文的发送记录在 13.5 节。Link State
Acknowledgment 报文的接收记录在 13.7 节。
该报文的格式与 Database Description 报文相似。两者的正文都只是一个
LSA 头部列表。
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
每个被确认的 LSA 都由其 LSA 头部描述。LSA 头部记录在 A.4.1 节。
它包含唯一标识该 LSA 及其当前实例所需的全部信息。