跳到主要内容

8. 协议报文处理 (Protocol Packet Processing)

  1. 协议报文处理 (Protocol Packet Processing)

    本节讨论 OSPF 路由协议报文的一般处理过程. 保持路由器的链路状态数据库 (link-state database) 同步非常重要. 因此, 无论发送还是接收, 路由协议报文都应比普通数据报文获得更高优先级的处理.

    路由协议报文只沿邻接关系 (adjacency) 发送, Hello 报文除外, 因为 Hello 报文用于发现邻接关系. 这意味着, 除通过虚链路发送的报文之外, 所有路由协议报文都只经过一个 IP 跳.

    所有路由协议报文都以标准头部开始. 下面各节详细说明如何填写并校验该标准头部. 随后, 针对每种报文类型, 本节列出进一步说明该报文处理过程的章节.

    8.1. 发送协议报文

    当路由器发送路由协议报文时, 会按如下方式填写标准 OSPF 报文头部中的字段. 有关头部格式的更多细节, 请参见 Section A.3.1:

    Version #
    设置为 2, 即本规范所记录的协议版本号.

    Packet type
    OSPF 报文的类型, 例如 Link State Update 或 Hello Packet.

    Packet length
    整个 OSPF 报文的字节长度, 包括标准 OSPF 报文头部.

    Router ID
    路由器自身的身份标识, 即生成该报文的路由器.

    Area ID
    该报文将被发送进入的 OSPF 区域.

    Checksum
    整个 OSPF 报文的标准 IP 16 位反码校验和, 但不包括 64 位认证字段. 该校验和作为相应认证过程的一部分计算; 对某些 OSPF 认证类型, 会省略校验和计算. 细节见 Section D.4.

    AuType and Authentication
    每次 OSPF 报文交换都要经过认证. 认证类型由协议分配, 并在 Appendix D 中记录. 每个 IP 网络/子网可以使用不同的认证过程. AuType 指示正在使用的认证过程类型. 随后的 64 位认证字段由所选择的认证过程使用. 在形成待发送报文时, 该过程应最后调用. 细节见 Section D.4.

    报文的 IP 目的地址按如下规则选择. 在物理点到点网络上, IP 目的地址总是设置为 AllSPFRouters. 在所有其他网络类型上, 包括虚链路, 大多数 OSPF 报文都作为单播发送, 即直接发送到邻接关系的另一端. 在这种情况下, IP 目的地址就是与邻接关系另一端关联的 Neighbor IP address (见 Section 10). 唯一不是单播发送的报文出现在广播网络上: 在这些网络中, Hello 报文发送到多播目的地址 AllSPFRouters; Designated Router 及其 Backup 将 Link State Update Packets 和 Link State Acknowledgment Packets 都发送到多播地址 AllSPFRouters; 而所有其他路由器则把它们的 Link State Update Packets 和 Link State Acknowledgment Packets 都发送到多播地址 AllDRouters.

    Link State Update 报文的重传 ALWAYS 直接发送给邻居. 在多路访问网络上, 这意味着重传应发送到该邻居的 IP 地址.

    IP 源地址应设置为发送接口的 IP 地址. 连接到未编号点到点网络的接口没有关联的 IP 地址. 在这些接口上, IP 源地址应设置为属于该路由器的任意其他 IP 地址. 因此, 路由器必须至少分配有一个 IP 地址.[2] 注意, 对于大多数用途, 虚链路的行为与未编号点到点网络完全相同. 不过, 每条虚链路确实有一个 IP 接口地址 (在路由表构建过程中发现), 发送虚链路上的报文时会把它用作 IP 源地址.

    有关特定 OSPF 报文类型格式的更多信息, 请参见 Table 10 中列出的章节.



    Type Packet name detailed section (transmit)
    _________________________________________________________
    1 Hello Section 9.5
    2 Database description Section 10.8
    3 Link state request Section 10.9
    4 Link state update Section 13.3
    5 Link state ack Section 13.5

    Table 10: 描述 OSPF 协议报文发送过程的章节.

    8.2. 接收协议报文

    每当路由器收到一个协议报文时, 都会标记该报文是在哪个接口上收到的. 对配置了虚链路的路由器来说, 可能无法立即看出应将该报文关联到哪个接口. 例如, 考虑 Figure 6 中所示的 Router RT11. 如果 RT11 在其通往 Network N8 的接口上收到一个 OSPF 协议报文, 它可能希望将该报文关联到 Area 2 的接口, 也可能希望关联到通往 Router RT10 的虚链路 (该虚链路属于 backbone). 在下文中, 我们假定报文最初与非虚链路关联.[3]

    为了让该报文在 IP 层被接受, 即使在报文被交给 OSPF 处理之前, 它也必须通过若干检查:


    o IP 校验和必须正确.

    o 报文的 IP 目的地址必须是接收接口的 IP 地址, 或者是 IP 多播地址 AllSPFRouters 或 AllDRouters 之一.

    o 指定的 IP 协议必须是 OSPF (89).

    o 本地产生的报文不应传递给 OSPF. 也就是说, 应检查源 IP 地址, 以确认这不是路由器自身生成的多播报文.


    接下来校验 OSPF 报文头部. 头部中指定的字段必须与接收接口的配置相匹配. 如果不匹配, 应丢弃该报文:


    o 版本号字段必须指定协议版本 2.

    o 必须校验 OSPF 头部中的 Area ID. 如果以下两种情况都不成立, 则应丢弃该报文. 头部中指定的 Area ID 必须满足以下之一:

    (1) 与接收接口的 Area ID 匹配. 在这种情况下, 报文是通过单跳发送的. 因此, 要求报文的 IP 源地址与接收接口位于同一网络上. 可以通过将报文的 IP 源地址和接口的 IP 地址都与接口掩码相与后再比较, 来验证这一点. 在点到点网络上不应执行此比较. 在点到点网络中, 链路两端的接口地址是独立分配的, 如果有分配的话.

    (2) 指示 backbone. 在这种情况下, 报文是通过虚链路发送的. 接收路由器必须是区域边界路由器 (area border router), 并且报文中指定的 Router ID (源路由器) 必须是已配置虚链路的另一端. 接收接口还必须连接到该虚链路配置的 Transit area. 如果所有这些检查都成功, 该报文被接受, 并从此与该虚链路以及 backbone area 关联.

    o IP 目的地址为 AllDRouters 的报文, 只有在接收接口状态为 DR 或 Backup 时才应被接受 (见 Section 9.1).

    o 报文中指定的 AuType 必须与关联区域所指定的 AuType 匹配.

    o 报文必须经过认证. 认证过程由 AuType 的设置指示 (见 Appendix D). 认证过程可以使用一个或多个 Authentication keys, 这些密钥可以按接口配置. 认证过程也可以验证 OSPF 报文头部中的校验和字段; 使用时, 该字段被设置为 OSPF 报文内容的标准 IP 16 位反码校验和, 但排除 64 位认证字段. 如果认证过程失败, 应丢弃该报文.


    如果报文类型为 Hello, 则随后应由 Hello Protocol 进一步处理 (见 Section 10.5). 所有其他报文类型只在邻接关系上发送/接收. 这意味着该报文必须由路由器的某个活动邻居发送. 如果接收接口连接到广播网络、Point-to-MultiPoint network 或 NBMA network, 则发送方由报文 IP 头部中的 IP 源地址标识. 如果接收接口连接到点到点网络或虚链路, 则发送方由报文 OSPF 头部中的 Router ID (source router) 标识. 与接收接口关联的数据结构包含活动邻居列表. 不匹配任何活动邻居的报文将被丢弃.

    至此, 所有收到的协议报文都已与一个活动邻居关联. 关于特定报文类型后续输入处理的细节, 请参见 Table 11 中列出的章节.



    Type Packet name detailed section (receive)
    ________________________________________________________
    1 Hello Section 10.5
    2 Database description Section 10.6
    3 Link state request Section 10.7
    4 Link state update Section 13
    5 Link state ack Section 13.7

    Table 11: 描述 OSPF 协议报文接收过程的章节.