Summary

  • RFC 1609 于 1994 年 3 月以实验性提案发表，建议在 X.500 目录中分别存放物理网络、节点、接口，以及面向 IP、OSI 等用途的逻辑“影像”。
  • imageOf 将逻辑条目指向实物或另一层影像。同一台设备可以在一种协议下充当网关，在另一种协议下不承担这个角色。

故障电话打进来时，“有线相连”听起来像好消息。值班员照着机柜图指向另一条出口，随后才发现这台机器根本没有替眼前的协议充当网关。这里说的是 RFC 模型揭示的可能误判，并非一宗有记录的事故。Glenn Mansfield、Thomas Johannsen 和 Mark Knopper 在 1994 年的 RFC 里抓住了这个差别：设备可以共享，网络图不能偷懒合并。

当时，作者认为网络管理偏重本地的故障与性能，跨管理区域的基础设施资料缺少有组织的存放处。他们列出的信息包括节点、连接、地址、服务、联系人与政策。提案先把网络画成图：设备和子网是点，连接是边。简单网络可以是一段线路，复合网络可以由多个子网组成。物理连接说明“碰得到”，协议视图才说明“走得通”。

RFC 把视图称为 image。X.500 目录里，network、node、networkInterface 记录物理层；networkImage、nodeImage、networkInterfaceImage 则记录逻辑层。每个影像通过 imageOf 指向对应实物，也可以指向另一影像。实物条目还可反向列出影像。这种安排让一个机柜容得下多套地图，却要求每张图交代自己究竟指向什么。

网关最能说明问题。一台机器接着两个网络，可能为 IP 转发，却不为 OSI 转发。排障的人若先翻错图，就会沿着根本无法转发的出口继续查。提案因此把 externalGateway 放进相应的逻辑网络影像；逻辑接口地址按该协议解释，可以是 IP 号，也可以是 OSI 的 NSAP。connectedNetwork 指向同一视图里的网络。只有协议实际使用某个物理接口，模型才给它建逻辑接口影像。把网线图复制成所有协议的路由图，等于凭空送出一条不存在的路。

作者还希望减少重复数据，并保留各管理方的边界。设备位置、所有者、联系人留在物理记录；协议用途写在各自视图。RFC 1608 随后把这套通用框架用于 IP 网络、地址、掩码和自治系统资料。目录把不同责任连起来，却没有替任何一方自动维护事实。

代价藏在更新里。RFC 把缓存规则留给本地决定，流量与收费字段也注明尚待细化；安全问题没有给出具体方案。若要知道它在某个网络里是否有效，需要带日期的目录条目与操作记录。原文提供的是结构提案。它留下的教训很实在：imageOf 能告诉值班员两条记录对应同一台机器，却不能替他检查出口是否仍在转发。翻错图，连排障的第一步都可能走反。