摘要

  • RREQ-Instance 的控制消息从 OrigNode 走向 TargNode，但它发现的路由用于 TargNode 返回 OrigNode；RREP-Instance 则以相反控制方向建立正向数据路由。
  • 端点地址、本地 InstanceID 与六位 Delta 可防止并发发现串台，却不证明两向路由当前已安装、仍新鲜或已被包使用。
  • 双向业务结论必须在同一时间窗内，分别连接两向安装收据、两向包观测，以及可关联的应用请求与响应。

为什么不能借用同一条回程

无线链路的两个方向可以呈现不同的接收强度、干扰、带宽或调度条件。一个节点可以顺利收到邻居的信号，却无法让邻居以同样质量收到回传。RFC 9854 正面承认这一点：当 OrigNode 有数据要发给 TargNode，而现有路由不能满足应用要求时，AODV-RPL 才按需启动点到点发现。

第一次控制扩散形成以 OrigNode 为根的临时 RREQ-Instance。RREQ-DIO 从源走向目标，但加入该 DODAG 的节点形成的是指向根的路由，因此数据用途是 TargNode → OrigNode。随后，RREP-DIO 从目标返回源；若需要第二棵 DODAG，它以 TargNode 为根，为 OrigNode → TargNode 的数据建立方向。消息名称描述控制流，不直接描述数据流。把“收到 RREQ”写成“正向路由成功”，一开始就把证据方向写反了。

S 位记录第一轮传播是否一直保留双向可用性。OrigNode 发出时置 1；每个路由器只有在入站链路的另一个方向也满足 Objective Function 时才保留 1，变成 0 后不会恢复。TargNode 收到 S=1，可沿已知向量或路由项单播 RREP，不必再建 RREP DODAG。若 S=0，TargNode 必须新建 RREP-Instance 并组播 RREP-DIO，沿途节点为指向目标的方向重新选择父节点。两条数据路由因而可能经过不同中间节点。

规范没有规定判定链路对称性的唯一方法。它只列出本地信息、既有知识、测试流量与 OAM 等可能来源，并在附录给出 ETX/RSSI 示例。S=1 是特定实现、策略与时刻下的控制结论，不是永恒的无线事实，更不是之后每个包的签收单。

Delta 解决串台，不解决交付

RPLInstanceID 由节点本地分配。同一对端点可同时发起采用不同 Objective Function 的发现，不同源节点也可能选到相同数值。RFC 9854 因此把 RREQ 身份定义为源节点本地值与源地址的有序组合，把 RREP 身份定义为目标本地值与目标地址的组合。

如果候选 RREP 数值已被同一目标 DODAGID 下的活动实例占用，TargNode 必须换一个值。RREP 里的六位 Delta 表示它在收到的 RREQ 数值上增加了多少；超过 255 后从 0 回绕。接收方在建立目标方向路由时减去 Delta，恢复成对的 RREQ 数值。DODAGID 提供端点语境，避免只凭一个八位数值认错实例。

这套机制确实封住一个重要错误：不同发现或不同 Objective Function 的状态不能混接。但“配对正确”只说明控制记录可归档到同一发现。它没有证明 RREP-Instance 在所有必要节点上形成，也没有证明两边的路由项尚存、同属一个当前世代或已经承载数据。

Rank、序列号与寿命是三类问题

Rank 不是链路延迟、跳数或端到端成本。RFC 6550 的定义明确说，它表示节点在某一 DODAG Version 中相对邻居的位置，不一定是到根距离或路径成本的良好表达；RFC 9854 又明确写出 AODV 消息里的 Rank 不表示到根的距离或成本。Objective Function 可使用的度量与约束另见 RFC 6551。因此，Rank 更优不能被改写成未测量的性能提升。

序列号处理逻辑新鲜度。OrigNode 发起新发现时递增自己的序列号；指向源的状态保存 Orig SeqNo，指向目标的状态保存 ART 中的 Dest SeqNo。同源、同目的、同实例下的陈旧路由项必须删除。这能排序路由世代，却不证明硬件表已接受该项，或链路此刻仍通。

时间也被拆开。L 字段限制节点能在临时实例中停留多久，它与路由项寿命明确独立。路由寿命来自 DODAG 配置，并可在实际使用时延长。“实例尚活”“路由未过期”“刚有包通过”分别需要各自的时钟。

hop-by-hop 与 source routing 留下不同证据

H=1 时，中间路由器逐跳建立包含源、实例、目的、下一跳、寿命与序列号的条目。对目标方向而言，对称路径可把 RREP 发送者作为下一跳，非对称路径则使用 RREP DODAG 的优选父节点。可靠收据必须点名节点、方向、下一跳、安装世代和过期时间。

H=0 时，路径通过 Address Vector 交给源路由。非对称情况下，RREP 向量记录第二轮控制实际经过的接口；对称情况下，目标原样返回 RREQ 收到的向量。发现自身地址已在向量中会触发丢弃，有助于限制环路，但一个结构正确的向量仍只是控制对象，不能证明列出的每个接口在数据到达时都可用。

OrigNode 收到 RREP 后，规范说它“可以开始”发送应用数据。这句话标记发现阶段结束、运行证据阶段开始。第一个包仍可能遇到路由缺失、寿命到期、无线条件改变、拥塞，或一个根本没有产生响应的目标应用。

一次往返需要五张收据

第一张收据固定发现身份：两端地址、两个 DODAGID、RREQ/RREP 数值、Delta、Objective Function、H/S、序列号、临时实例时钟和观测者。第二张单独证明 RREQ 所发现的 TargNode → OrigNode 方向：逐节点路由项或精确向量、寿命与世代。第三张对 RREP 结果所形成的 OrigNode → TargNode 方向做同样证明；两个方向不得互相补空白。

第四张来自包。计数器或探针要带时间窗、分母、复位历史、源/目的及实例语境。只观察到单向包，就只能证明单向传递。即使两个方向各自成功，若发生在不同时间，也未必证明两套路由曾同时存在。

第五张属于应用：用唯一请求标识连接 OrigNode 发出、TargNode 接受、生成响应，以及 OrigNode 在截止时间前收到响应。到这里才有业务意义上的往返事实。成对控制消息不能代替它。

RFC 9854 依赖 RPL 的可选安全框架，并指向 RFC 7416 的威胁分析。即便在安全发现中，掌握密钥的恶意路由器仍可能宣布虚假信息、注入发现或修改回复；恶意 Address Vector 与伪造 G-RREP 还可能制造环路或拒绝服务。认证约束谁能说话以及消息的某些完整性属性，却不会自动认证下游应用结果。

IANA RPL 注册表 登记了 MOP 4 与 RFC 9854 的 RREQ、RREP、ART 选项。RFC Editor 信息页 与 Datatracker 证明其 Proposed Standard 状态和发布历史；审稿时的 errata 查询 没有匹配条目。这些是规范与登记事实，不是厂商支持或部署普及率证据。

Heng Lu 的 Running-Code Primacy 提供本稿的底线：文档与登记协调共同语言，实际运行仍须由运行系统证明。最小初始规范、本地化未来决策与自愿采用 要求共享层只保留可本地验证的必要规则；现实层与符号权力 则提醒我们，配对形式的整齐不能冒充一次已执行的往返。

来源