摘要

  • RFC 3483 将监测、记录、报告和报告后的清零分成不同状态：PDP 可以暂停报告，而 PEP 仍然继续计数。
  • 每个数值还必须带着时间、清零历史和实际分配对象的身份来理解；上下文停用、请求状态删除和缓存策略到期分别划出了证据边界。

设想一个十分钟没有出现新数字的监控页面。最顺手的解释是“没有发生用量”，但 RFC 3483 要求先问另一件事：沉默的是计数器，还是把计数结果送出去的通道？在它描述的 COPS-PR 环境里，策略执行点 PEP 可以继续观察并累积策略用量，而策略决策点 PDP 已经要求停止非请求式报告。屏幕不动，只说明报告状态，不自动说明被测事实。

这种区分来自框架的三段结构。选择条件策略决定观察哪些对象；用量反馈类决定收集哪些指标；连接策略把对象与指标连接起来，并规定何时生成报告。因此，一项反馈数值不是孤立的“总量”，而是某个对象、某种指标、某套触发条件共同生成的结果。缺少其中任何一项，数值的含义都会漂移。

Accounting Timer 规定了非请求式会计报告的最大发送频率。它的目的在于给消息节流，并不提供精密同步。具体的连接策略可以等待多个基本间隔，可以在越过阈值时触发，可以只在数值变化后上报，也可以不论是否变化都按期上报。于是，接收端时钟上的一个空点，不足以证明报告迟到，更不能证明用量为零。

最鲜明的情形是 Accounting Timer 等于零。零意味着 PEP 不主动发送用量反馈，却不意味着停止监测与跟踪。PEP 仍按 PDP 安装的策略保存用量，等 PDP 主动请求后再报告。这里的零属于发送频率，而不是使用计数。

暂停命令进一步把两个状态拆开。PDP 可以只暂停报告消息，让监测与记录继续；稍后再恢复报告。它也可以连监测本身一并暂停，此时新用量不再被跟踪，报告自然也被抑制。无论选择哪一种，PDP 还要说明状态切换时是否先发送当前累积值。命令可以针对某一项反馈策略，也可以覆盖全部策略。因此，操作记录若只写“已暂停”，就丢掉了最重要的语义。

主动请求会从周期中间切入。PDP 可以在 Accounting Timer 的间隔尚未结束时要求立即反馈，PEP 必须响应。如果该用量策略规定“报告后清零”，这次反馈还会清除已报告的属性。但原有周期不会因此重新起算。下一个定期报告仍按连接建立时的相位到达，所以两个时间很近的报告可能都完全正确：一个回答主动请求，另一个履行既定周期。

这也意味着一份报告未必覆盖计数器的全部历史。它可能是上次清零后的剩余量，可能只覆盖主动请求与定期边界之间的一小段。若不知道报告是否触发清零，把两个数字相加可能重复，把后一个数字当作完整周期也可能漏算。传输时间、测量区间与清零事件必须分别保存。

RFC 3483 还处理了“这个计数究竟属于谁”。有些 COPS 对象直接对应 PEP 内一项唯一配置，有些则是共享对象，能展开为多个实际分配实例，各自独立收集统计信息。由于这些实例未必各有一个 COPS 对象，选择条件 PRC 与用量反馈 PRC 必须合在一起，才能标识 PEP 支持的最细粒度。

文档举例说，同一个 IP 地址若生成多个用量对象，端口号可以补足身份，形成“地址加端口”的唯一组合。规范推荐让选择条件本身就包含完整标识；也允许选择条件较宽，把所有匹配实例纳入监测，再由反馈记录补上区分信息。后一种方式并非含糊许可，而是要求审计时把两边重新连接。只看策略会合并多个实例，只看计数又会失去授权它的策略。

上下文切换为证据划出了清晰终点。COPS-PR 可以在 PEP 中保存多个相互独立的策略上下文，但任一时刻只能有一个处于活动状态。只有活动上下文的策略会被监测、记录和报告。当上下文停用时，PEP 要先发送包含其用量反馈的报告；停用之后，不再对它进行任何监测、跟踪或报告。最后一份消息不是普通样本，而是该权威区间的结账记录。

Delete Request State 也有同样严格的次序。PEP 在发出删除请求状态之前，必须立即发送本周期尚未上报的用量；即使删除由 PDP 发起，这一要求仍然成立。先保存最后证据，再移除赋予证据含义的状态，顺序不能颠倒。

连接断开并不会让本地计数获得无限寿命。PEP 只有在继续执行已缓存策略期间才继续跟踪反馈；一旦本地策略到期，相应的用量反馈数据也到期，监测随之停止。连接恢复后，PDP 必须明确指示可以恢复报告。PEP 随后发送缓存期间的用量，并按照新连接接受的 Accounting Timer 调整周期。

所以，证据的生命跟随实际执行的策略，而不是跟随进程、数据库行或传输连接。断线不自动抹去有效策略下产生的事实；重连也不能把事实向策略失效之后延长。RFC 3483 把控制权边界变成了证据边界。

它没有承诺更多。RFC 3483 是一份 Informational 框架，明确把收费、计价和账单模型排除在外。主动请求 Decision 的具体内容留给实现该框架的后续文档。现有来源不能证明某个具体网络部署过它，也不能证明计数准确、厂商互通、账单正确或用户得到了某种服务结果。

相邻规范各有自己的问题。RFC 3060 讨论策略数据如何与本地评估和执行分开；RFC 3084 处理配置事务、断线缓存与重连；RFC 3159 处理 PRID 行的身份。RFC 3483 从策略已经安装之后开始：执行留下了什么用量证据，这些证据何时开口，又指向哪个实际实例？

沿着 Heng Lu 的现实层方法，审计应先固定活动上下文和实际分配对象，再连接选择、指标与发送条件。记录每一个计时器、阈值、变化条件与报告后清零规则，把请求、暂停、恢复和最后报告放在同一条时间线上。发生断线时，以缓存策略停止执行的时刻截断证据。

完成这些重建之后，沉默才有解释。它或许真是没有用量，也可能是主动报告被关闭、发送被暂停、周期尚未结束，或计数正等待一次请求。RFC 3483 留下的历史价值，正是拒绝把“没有听见”伪装成“什么也没有发生”。

来源