摘要

  • RFC 3132 把 paging 与数据包交付明确分开:数据包到达休眠主机的网络一侧后,网络还要先定位并提醒主机,重新建立最后一跳,普通传输才可能继续。
  • 节电不是把工作消掉,而是把工作搬走。终端少报位置、少听业务信道,网络则要保存粗粒度 paging area、扩大搜索,并处理无线区域与 IP 子网边界不一致的问题。

数据包到了网络,却还没有到主机

通常的 IP 叙事里,只要目的地址有效、路由存在,数据包就可以继续前进。RFC 3132 讨论的移动主机却主动削弱了这种能力。它进入 dormant mode,减少对无线信道的监听,从而降低电池消耗与位置更新信令。

代价出现在第一个数据包到来时。主机此时未必监听承载普通 IP 流量的 traffic channel。网络必须先判断去哪里找它,经由仍能被它听见的 paging channel 发出提醒,等待回应,恢复业务信道,必要时再修复 Mobile IP 位置,最后才谈得上交付。

2001 年 6 月发布的 RFC 3132 是一份 Informational 问题说明。它对 paging 下了很窄的定义:因为有数据包抵达,网络通过无线接入点定位并提醒休眠移动主机,使其建立最后一跳连接。单纯把数据包发过最后一跳,不算 paging。

这条定义拆开了几个常被混成一件事的事实:代理收到数据包,不等于终端收到;page 已发出,不等于终端听见;终端回应,不等于三层路径已经恢复;三层可达,也不等于应用取得数据。

休眠方式不同,缺口也不同

RFC 3132 没有认定所有休眠链路都需要新的 IP paging 协议。它先区分两类无线环境。

只有休眠、没有专用 paging 的链路上,主机会按时间片周期醒来,在 traffic channel 上取走接入点缓冲的数据。如果休眠期间移动到另一个接入点,主机醒来后重新关联,新接入点可以向旧接入点取得缓冲包。在这套模型里,网络对主机位置掌握得足够精确,另加 IP paging 没有明显收益。

这个判断带有边界。缓冲多少、保留多久取决于实现;溢出和超时仍会丢包。RFC 并没有把它外推为所有后来的省电无线技术都不需要寻呼。

具备 paging 的链路则把提醒信道与业务信道分开。休眠主机不再在 traffic channel 上收发,只持续或周期性地听 paging channel。网络把多个无线接入点组成 paging area,记住主机上次报告或推测所在的区域。数据包到来后,区域内发出 page;回应意味着可以继续,超时则暂按不可达处理。

这种安排也有频谱经济学。RFC 说明,在许可频谱中,少占用业务信道做控制,可以留下更多可产生收入的容量,也避免为控制开销向用户计费。这是文件记录的运营动机,不是量化过的收益证明。

无线区域与 IP 子网是两张地图

真正困难的地方不是“睡着”,而是两套位置单位不一样。IP 层以 subnet 变化表示拓扑位置变化;无线 paging 以 paging area 表示休眠主机大致在哪。两条边界可以重合,也可以完全错开。

一块 paging area 正好对应一个 subnet 时,事情最简单。无线系统在已知的 IP 位置叫醒主机,不需要额外的 IP paging。

若一个 subnet 内包含多块 paging area,主机在这些区域之间移动时,IP 拓扑位置仍未改变。接入路由器或 Mobile IPv4 foreign agent 可以向多块无线区域发起寻找,地址仍指向正确子网。

最能暴露断层的是一块 paging area 跨越多个 subnet。休眠主机可以越过 IP 子网边界,却仍留在同一无线区域。二层看不到需要上报的 paging-area 变化;IP 层保存的最后位置却已经过期。第一个数据包可能先到旧子网,随后触发的 page 却在另一个子网得到回应。

额外的 Mobile IP 信令能够修复位置,但会在第一个数据包真正抵达前增加往返与延迟。RFC 3132 因而认为,在 home 或 hierarchical agent 与 paging area 内代理之间增加专门的 IP paging 交换,是有希望的优化。它没有说这是唯一可行方案。

图纸上的整齐包含关系并不存在于所有网络

RFC 为了推理先采用简化模型,随后主动承认实际 paging area 可能重叠,同一地点的不同终端也可能拿到不同区域标识。文件还以谨慎措辞记录了一则经验判断:不少运营者并不启用 paging-area registration,而是靠启发式方法猜主机在哪里。

少上报位置能节省终端电量与空口控制开销,却扩大网络的搜索面。区域越大,主机更新越少,首次 page 的 fan-out 越大;区域越小,搜索更精确,移动期间的更新更频繁。成本没有消失,只是在连续跟踪与事后寻找之间重新分配。

多种无线技术并存时,不确定性还多一层。主机可能走进室内,失去一种覆盖,获得另一种带宽更高或价格更低的连接。网络即使知道地理附近,也未必知道用户希望用哪个接口。RFC 勾勒过一种 IP 层标识,由接入点映射成各无线技术自己的 page。那是架构设想,不是部署证据。

ARP 或 Neighbor Discovery 也不是自然替代,因为它们通常假设主机正在监听可用的 traffic channel;休眠状态恰好取消了这个前提。

RFC 3154 把“叫醒”拆成多个责任主体

两个月后的 RFC 3154 给出了需求与功能架构。表面上一个“叫醒动作”,实际要面对百万级主机、消息丢失、代理故障、认证与拒绝服务。

协议既要尽量不影响休眠省电,又要过滤 broadcast、multicast 与 anycast,避免每个群发包都唤醒大量终端。它要区分休眠、inactive 与完全不可达,要支持多种 dormant mode,不依赖单一移动协议,同时与当时的 Mobile IPv4 和 Mobile IPv6 工作衔接。

paging area 与 subnet 的映射必须允许任意形状;有二层 paging 时应高效利用,却不能把二层 paging 当成必备条件。位置注册、区域信息与 paging 消息都要认证,而且安全交换本身不能耗掉原本要节省的电量。

架构把职责分给 Host、Tracking Agent、Paging Agent 与 Dormant Monitoring Agent。有人保存粗略位置,有人发现面向休眠主机的数据包,有人发起无线提醒,主机最后还要恢复可路由的三层连接。“网络叫醒了设备”不是一个原子事实,而是一串可失败、可观测的转换。

五份协议提案没有自动合成一个标准

2002 年的工作组 Internet-Draft 记录了五份协议提案的评估。冻结的 -00 与 -01 版本显示它仍在演化;表格中反复出现未说明、支持不足或依赖特定 Mobile IP 方案的问题,包括多种休眠模式、失败处理、管理、扩展性与移动协议独立性。

这份评估没有成为 RFC。RFC 3132 与 RFC 3154 本身也都是 Informational,不证明实现、互通、采用或部署。后来的 RFC 3344、RFC 6275 与 RFC 3753 可以帮助理解 Mobile IPv4、Mobile IPv6 和移动术语的演进,但不能倒推 paging 架构已经落地。

“可达”从一个标签变成一串凭据

RFC 3132 留下的历史价值,是把地址存在与接收能力分开。一台主机可以有正确地址,却没有打开接收普通流量的信道;网络可以知道它在哪块区域,却不知道具体接入点;page 可以正确发出,却没有回应;无线回应可以出现,却还没修复 IP 路径。

这些事实分别属于不同主体。主机决定何时休眠;tracking 系统保存位置判断;monitoring 功能解释第一个数据包;paging 设施负责搜索;移动协议修复拓扑;运营者决定区域大小、过滤规则与超时。

最危险的压缩,是把“page 已发”直接写成“用户可达”。第一个数据包没有证明自己已经抵达。它只证明网络开始偿还为终端静默而承担的责任:记住沉默大概在哪里,以有限成本找到它,并逐步证明从唤醒到交付的每个环节。

来源

  1. https://www.rfc-editor.org/rfc/rfc3132.txt
  2. https://www.rfc-editor.org/info/rfc3132
  3. https://www.rfc-editor.org/rfc/rfc3132.html
  4. https://www.rfc-editor.org/rfc/rfc3154.txt
  5. https://www.rfc-editor.org/info/rfc3154
  6. https://www.rfc-editor.org/rfc/rfc3154.html
  7. https://www.rfc-editor.org/rfc/rfc2002.txt
  8. https://www.rfc-editor.org/rfc/rfc3344.txt
  9. https://www.rfc-editor.org/rfc/rfc6275.txt
  10. https://www.rfc-editor.org/rfc/rfc3753.txt
  11. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-00.txt
  12. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-01.txt