摘要
- RFC 891 用同一轮 HELLO 往返测量选择路由,并把与该路径关联的时钟偏差放进 Host Table,但两类更新并不共享全部校验条件。
- 最小延迟路径只是时间观测的载体,不是主时钟选举结果;主时钟身份由配置项
CLOCK-HID指定。 - 报文等长、保持期、日期有效性与本地渐调或跳变程序,把“收到消息”“接受路由”和“校正时钟”拆成了不同事件。
如果一个系统只留下最终状态,RFC 891 的 Host Table 看起来会很奇怪:为什么同一行既有输出进程和往返延迟,又有时钟偏差、更新时间与存活计数?答案不是早期工程师把两个问题随意塞在一起,而是 DCN 的 HELLO 本来就在同时产生两种可复用的观测。
RFC 891 描述的是规模不超过 256 个主机和网关的本地网络。PDP-11 或 LSI-11 Fuzzball 通过点到点与多点链路相连,一台机器可以同时充当分组交换机、网关和服务主机。网络没有另设一位本地路由领袖,每个节点都要维护自己的判断。
物理主机还可以承载多个虚拟主机。Host Table 以主机 ID 为索引,保存到达目标的输出、延迟、偏差、更新时刻和 TTL 式计数;面向外部网络的 Net Table 则另行保存网关,通常由配置控制,只有 GGP 或 EGP 等进程会动态改写。
先有无需对时的往返测量
同一网络的 HELLO 使用 IP 协议号 63,并携带 Host Table 的延迟与偏差条目。今天的 IANA 协议号登记表 仍把 63 记为 “any local network”。这说明编号关系仍被保存,不说明 DCN 仍有多大部署。
往返计算跨越一次接收和下一次发送。RFC 891 强调,它不要求两端时钟已经一致,也不要求固定的 HELLO 发送间隔;丢失或被反射的 HELLO 也不让方法失效。网络因此可以在尚未校时时先获得选路所需的延迟。
格式错误或校验和失败的报文会被丢弃,但通过这层检查并不等于所有字段都能生效。精确偏差计算还要求最近发送与收到的 HELLO 长度相同。若长度不同,新路径仍可能被接受,偏差却保持不动。
这个细节是全文的控制线:共享报文不等于共享决定。路由循环可以前进,时钟循环可以说“证据不足”。
延迟选择的是承载路径
计算候选路由时,节点把通往邻居的往返延迟与邻居公布的目标延迟相加。新路径只有比当前路径好到超过阈值时才替换它。文档中的实现示例采用约 100 毫秒切换阈值、120 秒 Host Table 保持时间和 30 秒最大路径值;这些是具体实现参数,不是永久标准。
一旦路径被接受,与它相伴的偏差也写入表中。于是最短合格路径确实承担了传递时间观测的工作。但谁是主时钟,根本不是延迟算法选出的。
主时钟的 Host ID 由 CLOCK-HID 预先配置。来自其他目标的偏差可以成为路由表状态,却没有资格仅凭更快就校正本地时间。即使条目对应 CLOCK-HID,有效日期与本地时钟程序仍要继续把关。
因此,“最近的时钟胜出”是错误概括。RFC 891 把身份权交给配置,把到达方式交给测量,把最终效果交给接收端。
路由的来源不能从数字里删掉
如果节点把从某条链路学到的路由原样从该链路公布回去,分布式延迟可能形成闭环。RFC 891 会在回传方向把值改成 MAXDELAY。RFC 2453 后来用水平分割、毒性逆转、触发更新和计数到无穷等术语描述相近的距离向量难题。
这只是比较,不证明 Hellospeak 直接演化成 RIP。可以确认的是:指标若脱离输入链路,接收来的说法就可能伪装成本地独立事实。
保持计数也保存了时间来源。邻居消失后,旧条目不会立刻变成毫无记忆的新空位。路由可达性、偏差新鲜度和时钟有效期彼此关联,却不能用一个“在线”标志代替。
有时校正时钟之后必须暂停测量
RFC 891 区分物理时钟、表观时钟与实际交付给系统的时钟。小偏差不会一次性跳过去,而是逐步转移 CLK.DELTA 的一部分;建议参数把最大渐调速度控制在大约每秒两毫秒以内。
大偏差则可能让表观时钟直接跳变。系统随后进入保持期,此间用于测量的时间戳无效。这个暂停承认了一件容易被仪表盘掩盖的事实:本地时间轴发生断裂时,跨越断点的“往返”不再是普通样本。
表观时钟还会在世界时午夜回卷,因此至少每天要从主时钟获得一次有效日期与时间。能到达 CLOCK-HID,不等于已取得当天有效日期。
RFC 778 更早曾通过 ICMP 与 GGP 的三枚时间戳提供 DCNET 时钟服务,估算单程和往返延迟。RFC 891 的变化,是把这类测量融入持续维护的分布式主机状态和路由选择。
Hellospeak 影响了 NTP,却没有变成 NTP 的别名
RFC 1059 后来把 Fuzzball 路由协议称作 “Hellospeak”,明确写道把时间同步嵌入路由的做法强烈影响了 NTP,同时也明确说它不是面向整个 Internet 的协议,不适合离开本地环境。
RFC 958 提出的早期 NTP 改用 UDP,定义层级与报文表示,但没有规定同步、过滤、对等端发现或认证算法。RFC 1305 则进一步建立多服务器过滤与选择、误差边界,以及源自 Fuzzball 工作的逻辑时钟机制。
历史连续性在思想上有正式文献支持,协议同一性却没有。真正延续下去的问题是:路径、观测与权威如何在复用时仍保持可辨认。
来源与边界
本文依据 RFC 778、RFC 891、RFC 958、RFC 1059、RFC 1305、RFC 2453 与 IANA 协议号登记表。它们不证明 DCN 当前部署、不证明所有 Fuzzball 参数一致、不提供主时钟认证、不保证链路延迟对称、不证明 Hellospeak 与 RIP 的直接谱系,也不保证最小往返延迟必然带来最小校时误差。
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
