摘要

  • RFC 3532 要求动态分区在调整活动虚拟交换单元时保留既有状态，却没有要求每一种控制协议都主动通知控制器。资源已经减少，控制器仍可能要等到下一次请求收到错误，再查询可用资源后才知道原因。
  • 可靠的收据链必须分别记录授权、旧额度、实际占用、释放或拒绝、冻结与排空、控制器知情路径、分区间服务以及业务结果。“重分配成功”不能替代这些事实。

资源调整最容易产生误判的地方，不是系统返回了错误，而是系统没有明显中断。静态分区会让问题变得直观：受影响的控制器断开，虚拟交换单元下线，原有配置通常被释放，重连以后再重建状态。动态分区则让活动分区在原地改变额度，并要求保留与该分区有关的既有状态。

这种连续性当然有价值，但它也把风险从“可见停机”转移到了“多方认知不一致”。交换单元可以已经严格执行新上限，分区管理器可以已经看到新清单，控制器却仍按旧地图调度。控制会话还在，只能证明会话还在；转发表项还在，只能证明状态没有被清空。两者都不能证明资源仍然足够，更不能证明应用结果没有改变。

RFC 3532 发布于 2003 年 5 月，状态为 Informational，并明确说明它没有规定任何种类的互联网标准。它是一份需求文档，不是一套完整协议。它主要讨论 GSMP 交换机的分区；对于非 GSMP 交换机以及最长前缀匹配转发设备，文档只说这些要求可能是必要的，并没有声称已经充分。

四种角色，四个不能互相冒充的事实

交换单元（SE）执行分组交换，并提供可以划分的资源。一个分区，也称虚拟 SE，是其中一组资源。控制器负责操作活动分区。分区管理器（PM）决定要有多少虚拟 SE，以及每个分区获得哪些资源。

这四种逻辑角色形成了不同的控制面。PM 与 SE 之间谈分配；控制器与分区之间谈运行；PM 与控制器之间可能要谈资源增加或减少。只保存一条“容量已修改”的记录，会同时丢掉请求者、执行者、被通知者和实际使用者。

逻辑角色可以位于同一台物理设备，也可以分布在多台系统上。因此，“组件分开”不能自动证明物理隔离、故障域隔离或者独立进程；“组件在一起”也不能抹掉它们不同的权限。审计记录既要写逻辑身份，也要绑定当时真正执行该角色的运行主体。

文档举了出租分区的例子：设备所有者划分资源，让第三方控制各自的虚拟交换单元。这个例子不能被当成某项真实商业租约的证据。商业权利、PM 的重分配权限、控制器的运行权限以及 SE 当前真正执行的额度，是四套事实。验证其中一项，不能替其他三项签字。

未使用的资源可以移动，正在使用的资源不能被账面抹掉

SE 必须阻止控制器使用超过当前分配额度的资源。这是新边界的执行要求，却不是允许设备为了让缩容请求显得成功而静默删除活动对象。

如果 PM 要求释放活动分区的资源，而请求释放的资源中有任何一部分仍在使用，SE 必须拒绝该请求。这个拒绝是符合要求的保护结果，不是需要被包装掉的失败。它保留了一个关键区别：空闲容量可以立即重新分配，承载现有连接的容量需要协调。

遭到拒绝后，PM 应该冻结分区和/或要求控制器降低资源使用。冻结不是关机。冻结的分区交出尚未使用的资源，允许当前连接继续存在，并在连接关闭时逐步归还资源。它处于一种有方向的中间状态：不再扩张，但还没有清空。只显示“运行中”会隐藏稀缺压力，只显示“已停止”又会隐藏仍在流动的连接。

如果控制器始终不肯或不能释放资源，PM 最终可以使用虚拟断电控制，把活动分区变成非活动状态并断开控制器。这个后备手段避免资源永久被占用，却明显具有破坏性。系统通过断开分区最终获得了目标容量，不能倒过来被描述成“一次无中断的动态缩容”。

因此，一条缩容收据至少要保存资源类型、旧额度、变更前占用、目标额度、SE 的决定、冻结状态、控制器释放动作以及所有仍在使用资源的最终处置。如果旧额度是一百、使用量是九十二、目标是八十，而系统靠终止十二个活动对象才达到八十，那么“新额度八十”远远不是完整叙述。

冻结分区是一段排空过程，不是一个布尔值

冻结把资源治理变成一个时间过程。开始冻结时，未使用资源可以立即被拿走；之后每个连接关闭，都可能释放更多容量；在排空完成以前，旧工作仍然占据一部分资源。这个过程需要起点、进度和结束条件，不能压缩成单个 frozen=true。

首先要记录冻结所依据的拒绝：哪项缩容请求、哪些资源仍被占用、由哪个授权 PM 发出。然后要记录控制器是否收到降低使用量的请求、是否承诺一个目标、实际关闭了哪些连接，以及 SE 的可用量如何变化。最后才能判断目标额度是否已经实现，或者是否触发虚拟断电。

冻结期间的服务也不是天然安全。保留现有连接并不等于这些连接仍有同样的带宽、队列或缓冲条件；不允许创建新连接也可能改变上层系统的容错行为。需要分别观察控制面状态、数据面容量和应用完成率。

这种表述也保护了未受影响的分区。静态调整时，RFC 明确说没有受影响的分区不必下线；动态调整更不应被解释为整台设备重启许可。资源变更的影响集合必须按实际分配和依赖关系计算，而不是因为多个分区共享一个机箱、一个配置文件或同一个 PM 就全部纳入。

控制器可能在下一次失败时才获知事实

RFC 3532 给出了几条知情路径。控制协议可以支持主动通知：SE 在重分配发生时异步告诉控制器。这条路径的时间边界最清楚，但文档没有要求每种控制协议都必须实现主动通知。

被动通知则必须存在，可以是显式，也可以是隐式。显式路径中，控制器随后提出一个无法满足的请求，SE 返回“资源已被重新分配”之类的专门错误。隐式路径中，控制器只得到一般错误、未知错误或资源错误；它必须再查询可用资源，才能判断失败是否由重分配造成。

PM 还可以直接联系控制器。这又形成了一条独立收据链：消息由谁发送、用什么授权、传给哪个控制器、是否送达、控制器是否确认、内部资源模型何时更新。发送成功不能证明对方采用了新模型，收到错误也不能证明控制器做出了正确解释。

所以至少要保存四个时刻：分配改变的时刻、控制器得到信号的时刻、控制器更新调度模型的时刻，以及新的业务行为被观测的时刻。它们可以相同，也可能相差一个消息延迟、一次后续请求，甚至一段故障诊断时间。

在这个间隔内，SE 按新上限拒绝请求可能完全正确；控制器依据尚未更新的旧模型继续申请也可能符合它自己的状态。把这种情况统一标成“随机资源错误”，会让自动化重试持续撞击同一边界，也会让运营人员看不见真正的认知欠账。

清单回答设备拥有什么，不回答控制器相信什么

PM 必须能够查询 SE 的资源、已配置的分区和每个分区的分配。为了自动完成 PM 与控制器之间的互动，PM 必须能从 SE 得知连接在虚拟 SE 上的控制器地址；它还可以了解控制协议及其版本。

这是分配者需要的权威清单。它能够说明某一时刻 SE 报告哪些资源、划给了谁，也可以帮助 PM 找到应联系的控制器。但是，它不能证明控制器已经收到通知、已经降低使用、停止申请不存在的容量，或者保住了服务结果。

发生不一致时，应先判断是哪一层。如果 PM 的期望值与 SE 报告值不同，是分配落实问题。如果两者一致，但控制器仍按旧额度操作，是知情或适应问题。如果三者一致，而用户仍看到故障，则要继续追到数据面和应用层。一条笼统的“同步失败”会把这三类问题混在一起。

清单本身也有观测时间。收据应保存 SE 身份、分区身份、资源模型、查询时间、响应摘要和各项额度。下一次查询不能覆盖上一次结果，否则事故发生后只能看到“现在是什么”，无法还原“错误请求发生时各方知道什么”。

分区之间的服务让局部调整产生真实依赖

SE 可以在两个虚拟 SE 之间提供服务，例如一条虚拟链路。设备必须暴露存在哪些分区间服务，PM 必须能够配置它们。如果配置增加或删除虚拟端口，并且控制协议支持相关通知，SE 必须通知所连接的控制器。

这意味着，一次调整可以在分配清单上只触及一个分区，却改变另一个分区所依赖的服务。被调整的分区可能保留全部控制状态，但虚拟链路的端口或容量已经不同。另一个分区没有直接收到重分配命令，也不等于它在运行结果上完全不受影响。

验证必须同时守住两个边界。第一，证明影响集合之外的代表性分区保持原有额度和进程身份，防止把局部操作扩大成全设备中断。第二，枚举跨越变更边界的分区间服务，并按实际依赖进行测试。前者保护无关分区，后者防止“最小影响”被误用成“忽略真实依赖”。

共享设备、共享协议或共享管理器都只是可能的关联，不是自动影响证据。只有资源分配、运行配置、直接依赖或必需迁移真正改变，才应该把一个分区列入影响集合。

有权调整，不等于调整安全

只有获得授权的 PM 才能动态重分配 SE。SE 必须通过安全流程，让获授权的实体选择控制它的 PM；选择可以是明确配置，也可以通过受授权的发现机制完成。只有这个 PM 或它的授权代理，才可以要求控制器减少资源或者告知资源增加。

反方向也要验证。PM 必须认证资源变更请求确实来自有权控制指定虚拟 SE 的控制器。否则，一个租户可能要求改变另一个租户的资源，或者利用共享管理器移动不属于自己的容量。

认证说明在某套信任流程下是谁出示了凭据；授权说明这个主体能否对这个分区执行这项操作。它们都不能单独证明商业权利、容量安全、配置已经执行，或者服务目标已经达到。这些事实分别属于合同政策、SE 收据和结果观测。

PM 的选择记录尤其不能被覆盖。如果控制权在不同管理器之间迁移，后来有效的凭据不能追认早先未授权的变更。每次请求都应绑定当时的 PM 选择状态、凭据、策略版本、分区和负载摘要。

后来的体系结构不能替 2003 年的文档补写结果

RFC 3654 与 RFC 3746 后来讨论了转发单元和控制单元分离的需求与框架。RFC 5810、RFC 5812 规定了后来的 ForCES 协议和转发单元模型，RFC 7121 讨论 ForCES 高可用性。它们可以帮助读者理解控制与转发分离的演进。

它们不能把 RFC 3532 变成标准，不能替一台真实设备生成运行收据，也不能证明某个 RFC 3532 场景使用了 ForCES。RFC 3654、RFC 3746 是 Informational；RFC 5810、RFC 5812、RFC 7121 是 Proposed Standard。每份文档都有自己的日期、状态和范围。

书目记录、文档历史和勘误页面同样只解决身份与文本记录问题。它们不能观察正在运行的分区。协议血缘是背景，不是部署证据。

一条不越权的资源变更收据链

第一段记录身份与权限：SE、PM、控制器、分区、实际物理映射、PM 选择记录、凭据、策略版本和请求摘要。再记录确定性资源类型、旧额度、观测使用量与目标额度。

第二段记录 SE 决策。区分释放未使用资源、因在用资源而拒绝、冻结、控制器协商释放以及虚拟断电。明确哪些既有状态被保留，以及控制器触及新上限时 SE 如何执行限制。

第三段记录知情过程。写明主动通知、显式被动错误、隐式错误加查询，或者 PM 直接联系。把控制器更新后的模型和重试结果接在后面。再次查询 SE 可以证明新清单，但不能替控制器签收。

最后检查分区间服务、代表性未受影响分区、数据面容量和应用结果。每个所有者只对自己的表面负责：PM 证明请求，SE 证明分配，控制器证明内部模型，服务遥测证明运行，应用所有者证明用户结果。

“重分配成功”缺少边界。更诚实的短句是：“获授权的管理器在此时调整了这些未使用资源；SE 保留了这些状态；控制器通过这条路径获知并采用了这个模型；相关依赖和结果随后得到观测。”若证据尚未走到最后，就应明确写出未知项。

Evidence boundary

本文没有指认任何实现、厂商、运营商、交换单元、分区管理器、控制器、租户、租约、资源池、分区、部署、事故、停机、安全事件或客户结果，也没有报告当前采用率、容量数值、使用率、丢包、时延或服务表现。

本文把 RFC 3532 视为 2003 年 5 月发布的 Informational 需求文档，而不是互联网标准或完整协议。它对确定性分区的假设不适用于统计共享或超额分配。后来的 GSMP、Megaco 与 ForCES 材料保留各自的日期、状态与范围，不能证明任何实际系统符合本文所述要求。

文中披露的 Heng Lu 笔记只提供编辑视角：权限记录应限制在它真正控制的操作，运行代码的证据应闭合所声称的结果。它们不证明 IETF 的意图、实现行为或部署事实。

本文的有限结论是：活动分区可以在不重启的情况下改变资源，而控制器可能直到后续通知、错误、查询或直接联系时才知情。保留状态和更新分配清单都是必要证据，但都不等于服务结果。

Sources