RFC 5148：随机错峰不是交付证明

摘要

RFC 7939 可以把 NHDP 的周期 HELLO 与触发 HELLO 最大抖动暴露给管理系统。RFC 6130 还给出 HP_MAXJITTER := HELLO_INTERVAL/4 等默认关系。它们有重要用途：让配置可见、可比较、可审计。但默认值与管理读数仍只是控制面的陈述。

真正运行时，调度器是否按预期调用随机源、所有节点是否因批量重启拿到相关种子、队列是否用另一条路径修改了发送时间，都需要另外观察。把“参数存在”直接写成“碰撞已避免”，就是把符号层提升成现实层。

周期生成使用 MESSAGE_INTERVAL - jitter。从标称间隔中减去随机量，可以避免报文晚于依赖超时的上限；以下一次实际发送为新基准，则能让原本同步的节点逐渐分离。

外部事件触发的报文采用延迟。多个节点看到同一邻接变化时，如果立即回答，就会把共同原因变成空口同步。若触发事件还会重置周期计划，后续计划应从延迟后的时刻开始，否则同步会再次出现。

转发也采用延迟，但中间节点可能不知道源节点的 MESSAGE_INTERVAL。具体协议必须预先约定、随报文携带、通过接收时间估计，或者另设有效规则。因此，一个笼统的“jitter enabled”字段不足以证明参数适用。

RFC 5148 建议在零到 MAXJITTER 之间均匀抽样。周期场景中，上限必须非负，不得大于 MESSAGE_INTERVAL/2，且不应大于四分之一。若 MESSAGE_MIN_INTERVAL 大于零，上限不得大于该最小间隔，且不应大于其一半。

这些边界防止随机化吞掉协议自己的时间结构。它们不能证明样本均匀，也不能证明不同节点独立。抖动还要与 MAC 帧周期相适应；标准以明显更大、例如一个数量级作为例子，而不是全球统一常数。节点密度与干扰范围增加时，较大抖动可能合理，但随之增加的时延会损害其他目标，所以标准同时要求尽量减小。

节点等待发送时，新的同类触发可能到达。如果生成动作本身被推迟，多个触发可以合并为一条更新消息；如果消息已经生成，系统就必须选择丢弃旧消息、发送两条，或者修改时间并维护顺序。转发队列也可能被来自同一源的更新消息追上。

分组聚合还有一个容易隐藏的错误。同一接收分组中的多条待转发消息应共用一次随机延迟。逐条抽样再取最小值，平均等待会系统性缩短，原本的均匀分布也被破坏。来自不同分组的消息可以合并，但最早的独立截止时间可能决定共同发送时刻。

因此审计记录至少需要触发原因、调度时刻、实际抽样、聚合单元、队列决策与最终发射。仅保存上限没有重放能力。

转发报文在每一跳都可能增加抖动。RFC 5148 明确要求参考预计的连续转发次数，最高到网络直径，以限制累计最大时延。RFC 7181 分开周期 TC、触发 TC 与转发抖动；RFC 7183 在拓扑有效期推导中加入逐跳抖动。

延长有效期只是为了覆盖可能的传播时间，并不是某条报文真正到达的证明。证据链应分别记录：配置边界、有效调度、无线发射、指定接收者接收、协议处理、拓扑推断、路由安装、数据面转发与应用结果。

安全边界也同样有限。随机时刻可能让选择性定时干扰更难预测，但不能认证发送者，也不能防御宽带干扰或修复弱随机源。RFC 5148 把完整安全分析留给采用它的协议。