跳到主要内容

9. 计费 (Accounting)

9. 计费 (Accounting)​

本计费协议基于服务器主导 (server directed) 模型, 并具备实时传递计费信息的能力. 协议中内置了多种容错恢复方法 [RFC2975], 以尽量减少在各种故障情形以及在对所用设备能力有不同假设下计费数据的丢失.

9.1. 服务器主导模型 (Server Directed Model)​

服务器主导模型是指, 生成计费数据的设备从授权服务器 (若已联系) 或计费服务器获得有关如何转发计费数据的信息, 其中包括计费记录的时效性要求.

如 [RFC2975] 所讨论, 实时传送计费记录是一项需求, 例如执行信用额度检查和欺诈检测. 注意, 批量计费并非需求, 因此 Diameter 不支持批量计费. 若将来需要批量计费, 需要创建新的 Diameter 应用, 或使用其他协议处理. 但请注意, 即使在 Diameter 层计费请求是逐条处理的, 在 Diameter 之下使用的传输协议在高流量条件下通常会在同一数据包中批量封装多个请求. 对许多应用而言这可能已足够.

授权服务器 (链) 根据其对用户及漫游合作关系所掌握的信息, 指导选择适当的传送策略. 服务器 (或代理) 使用 Acct-Interim-Interval (计费间隔) AVP 和 Accounting-Realtime-Required (计费实时性要求) AVP 来控制作为客户端运行的 Diameter 对等端的行为. 当存在 Acct-Interim-Interval AVP 时, 它指示作为客户端的 Diameter 节点即使在会话期间也要持续产生计费记录. Accounting-Realtime-Required AVP 用于在从 Diameter 客户端传送计费记录被延迟或失败时控制客户端的行为.

Diameter 计费服务器可以通过在 Accounting-Answer (计费应答) 消息中包含 Acct-Interim-Interval 或 Accounting-Realtime-Required AVP 来覆盖间隔或实时性要求. 当存在这些 AVP 之一时, 后续对同一会话的计费活动应当使用最新收到的值.

9.2. 协议消息 (Protocol Messages)​

从 Diameter 服务器收到成功的认证和/或授权消息的 Diameter 节点应当为该会话收集计费信息. Accounting-Request (计费请求) 消息用于将计费信息传送给 Diameter 服务器, 服务器必须用 Accounting-Answer 消息回复以确认接收. Accounting-Answer 消息包含 Result-Code AVP, 它可以指示计费消息中存在错误. 先前为该会话收到的 Accounting-Realtime-Required AVP 的值可能表明, 在收到被拒绝的 Accounting-Request 消息时必须终止用户会话.

9.3. 计费应用扩展与要求 (Accounting Application Extension and Requirements)​

每个 Diameter 应用 (例如 NASREQ, Mobile IP) 应当在题为 "Accounting AVPs" 的章节中定义其必须在 Accounting-Request 消息中出现的服务专用 AVP. 应用必须假定本文档所述的 AVP 将出现在所有计费消息中, 因此该章节只需定义各自的服务专用 AVP.

应用可以选择使用以下一种或两种计费应用扩展模型之一:

分离计费服务 (Split Accounting Service)

计费消息将携带 Diameter 基础计费应用的 Application Id (见第 2.4 节). 计费消息可以路由到与对应 Diameter 应用不同的 Diameter 节点. 这些节点可以是集中式计费服务器, 为多种不同的 Diameter 应用提供计费服务. 这些节点必须在能力交换期间通告 Diameter 基础计费 Application Id.

耦合计费服务 (Coupled Accounting Service)

计费消息将携带使用它的应用的 Application Id. 应用本身将处理收到的计费记录或将其转发给计费服务器. 能力交换期间不需要通告计费应用, 计费消息的路由方式与其他应用消息相同.

若应用未定义自己的计费服务, 优先采用分离计费模型.

9.4. 容错能力 (Fault Resilience)​

使用 Diameter 基础协议机制来克服短暂的小规模丢包和网络故障.

作为客户端的 Diameter 对等端必须实现故障转移 (failover), 以防服务器故障和某些网络故障. 作为代理的 Diameter 对等端或相关离线处理系统必须检测重复计费记录, 其原因包括将同一条记录发送到多台服务器以及传输中的消息重复. 该检测必须基于检查 Session-Id 与 Accounting-Record-Number AVP 对. 附录 C 讨论重复检测需求与实现问题.

Diameter 客户端可以具备非易失性存储器, 用于在重启、长时间网络故障、网络分区和服务器故障期间安全保存计费记录. 若具备此类存储器, 客户端应当在记录一经创建就将其存入该处, 直到收到 Diameter 服务器对其接收的肯定确认为止. 重启后, 客户端必须开始向计费服务器发送非易失性存储器中的记录, 并对记录中的终止原因、会话长度及其他相关信息作适当修改.

本协议的进一步应用可以包含用于控制可在 Diameter 客户端中存储、尚未提交到非易失性存储器或尚未传送到 Diameter 服务器的计费记录最大数量的 AVP.

在收到正确的 Accounting-Answer 之前, 客户端不应从其任何存储区删除计费数据. 若内存等资源耗尽, 客户端可以删除最旧的、未送达或尚未确认的计费数据. 在此条件下客户端是否接受新会话由实现决定.

9.5. 计费记录 (Accounting Records)​

在所有计费记录中, Session-Id AVP 必须出现, 若 Diameter 客户端能够获得 User-Name AVP, 则 User-Name AVP 必须出现.

根据被计费服务的实际类型以及授权服务器对中期计费的指示, 发送不同类型的计费记录. 若被计费服务为一次性事件, 即事件的开始与结束同时发生, 则 Accounting-Record-Type AVP 必须存在且取值为 EVENT_RECORD.

若被计费服务具有可度量的持续时间, 则该 AVP 必须使用 START_RECORD, STOP_RECORD, 以及可能的 INTERIM_RECORD. 若授权服务器未指示为该会话启用中期计费, 则对每个会话型服务必须生成两条计费记录. 当发送给定会话的初始 Accounting-Request 时, Accounting-Record-Type AVP 必须设为 START_RECORD. 当发送最后一条 Accounting-Request 时, 取值必须为 STOP_RECORD.

若授权服务器指示启用中期计费, Diameter 客户端必须在 START_RECORD 与 STOP_RECORD 之间额外产生标记为 INTERIM_RECORD 的记录. 这些记录的产生由 Acct-Interim-Interval 以及会话的任何重新认证或重新授权指导. 若正在为同一会话生成新记录, Diameter 客户端必须覆盖本地存储待发送的任何先前中期计费记录. 这确保对任一给定会话, 接入设备上仅存在一条待发送的中期记录.

除重传目的外, Accounting-Sub-Session-Id 的特定取值只能出现在来自 Diameter 客户端的一条计费记录序列中. 发送的该序列必须要么是 Accounting-Record-Type AVP 取 EVENT_RECORD 的一条记录, 要么是以 START_RECORD 开始、后跟零条或多条 INTERIM_RECORD 并以单条 STOP_RECORD 结束的若干记录. 特定的 Diameter 应用规范必须定义必须使用的序列类型.

9.6. 计费记录的关联 (Correlation of Accounting Records)​

若应用使用计费消息, 可以通过在计费消息中使用特定应用会话的 Session-Id, 将计费记录与该应用会话关联. 计费消息也可以使用与应用会话不同的 Session-Id, 此时需要其他与会话相关的信息才能执行关联.

若应用需要多个计费子会话, 使用 Accounting-Sub-Session-Id AVP 区分各子会话. Session-Id 对所有子会话保持不变, 用于将所有子会话关联到特定应用会话. 注意, 若在 START_RECORD 消息中原本使用了子会话, 而收到的 STOP_RECORD 不含 Accounting-Sub-Session-Id AVP, 则表示所有子会话均已终止.

还存在应用需要将多个应用会话关联到单条计费记录的情形, 该记录可能跨越同一用户在给定时间使用的多个不同 Diameter 应用和会话. 此时使用 Acct-Multi-Session-Id AVP. 当服务器判定请求属于既有会话时, Acct-Multi-Session-Id AVP 应当由服务器向接入设备发信号 (通常在授权期间). 接入设备随后必须在所有后续计费消息中包含 Acct-Multi-Session-Id AVP.

Acct-Multi-Session-Id AVP 可以包含原始 Session-Id 的值. 其内容由实现定义, 但在所有其他 Acct-Multi-Session-Id 之间必须全局唯一, 且在会话生存期内不得改变.

Diameter 应用文档必须定义被计费会话的确切概念, 并可以定义多会话 (multi-session) 概念. 例如, NASREQ DIAMETER 应用将到网络接入服务器 (NAS) 的单个 PPP 连接视为一个会话, 将一组多链路 PPP 会话视为一个多会话.

9.7. 计费命令码 (Accounting Command Codes)​

本节定义提供计费服务的所有 Diameter 实现必须支持的命令码 (Command Code) 值.

9.7.1. Accounting-Request​

Accounting-Request (ACR) 命令由命令码字段设为 271 且命令标志中的 R 位置位来标识, 由作为客户端的 Diameter 节点发送, 以便与对等端交换计费信息.

除下列 AVP 外, Accounting-Request 消息应当包含与服务相关的计费 AVP.

消息格式 (Message Format)

::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Destination-Host ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ Route-Record ]
    * [ AVP ]

9.7.2. Accounting-Answer​

Accounting-Answer (ACA) 命令由命令码字段设为 271 且命令标志中的 R 位清除来标识, 用于确认 Accounting-Request 命令. Accounting-Answer 命令包含与对应请求相同的 Session-Id.

只有作为目标的 Diameter 服务器, 即归属 Diameter 服务器, 应当用 Accounting-Answer 命令响应.

除下列 AVP 外, Accounting-Answer 消息应当包含与服务相关的计费 AVP.

消息格式 (Message Format)

::= < Diameter Header: 271, PXY >
    < Session-Id >
    { Result-Code }
    { Origin-Host }
    { Origin-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    [ Failed-AVP ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ AVP ]

9.8. 计费 AVP (Accounting AVPs)​

本节包含描述与特定会话相关的计费用量信息的 AVP.

9.8.1. Accounting-Record-Type AVP​

Accounting-Record-Type AVP (AVP 代码 480) 类型为 Enumerated (枚举), 表示正在发送的计费记录类型. 当前为 Accounting-Record-Type AVP 定义下列取值:

EVENT_RECORD 1

计费事件记录用于表明发生了一次性事件 (即事件的开始与结束同时发生). 该记录包含与服务相关的全部信息, 且是该服务的唯一记录.

START_RECORD 2

计费开始、中期与停止记录用于表明提供了具有可度量持续时间的服务. 计费开始记录用于启动计费会话, 包含与会话启动相关的计费信息.

INTERIM_RECORD 3

中期计费记录包含既有计费会话的累计计费信息. 每次发生重新认证或重新授权时都应当发送中期计费记录. 此外, 特定于应用的 Diameter 应用可以定义额外的中期记录触发条件. 是否使用 INTERIM_RECORD 由 Acct-Interim-Interval AVP 决定.

STOP_RECORD 4

计费停止记录用于终止计费会话, 包含与既有会话相关的累计计费信息.

9.8.2. Acct-Interim-Interval AVP​

Acct-Interim-Interval AVP (AVP 代码 85) 类型为 Unsigned32, 由 Diameter 归属授权服务器发往 Diameter 客户端. 客户端使用该 AVP 中的信息决定如何以及何时产生计费记录. 通过该 AVP 的不同取值, 根据归属组织的需求, 服务会话可以产生一条、两条或 2+N 条计费记录. 包含该 AVP 时指导产生计费记录的行为如下:

  1. 省略 Acct-Interim-Interval AVP, 或其 Value 字段设为 0, 表示按服务需要产生 EVENT_RECORD, START_RECORD 和 STOP_RECORD.

  2. 包含该 AVP 且 Value 字段为非零值, 表示必须在 START_RECORD 与 STOP_RECORD 之间产生 INTERIM_RECORD 记录. 该 AVP 的 Value 字段为这些记录之间的标称间隔, 单位为秒. 产生计费信息的 Diameter 节点 (即客户端) 必须在自 START_RECORD 起该标称间隔大约届满时产生第一条 INTERIM_RECORD, 再经过一个间隔产生下一条, 依此类推, 直到会话结束并产生 STOP_RECORD 记录.

客户端必须对中期记录的产生时间做随机化, 以免在记录之间或在共同的服务开始时间附近形成大规模计费消息风暴.

9.8.3. Accounting-Record-Number AVP​

Accounting-Record-Number AVP (AVP 代码 485) 类型为 Unsigned32, 标识本会话内的本条记录. 由于 Session-Id AVP 全局唯一, Session-Id 与 Accounting-Record-Number AVP 的组合也全局唯一, 可用于将计费记录与确认匹配. 一种简单的唯一编号方式是将 EVENT_RECORD 和 START_RECORD 的值设为 0, 第一条 INTERIM_RECORD 设为 1, 第二条设为 2, 依此类推, 直到 STOP_RECORD 的值比最后一条 INTERIM_RECORD 大 1.

9.8.4. Acct-Session-Id AVP​

Acct-Session-Id AVP (AVP 代码 44) 类型为 OctetString, 仅在发生 RADIUS/Diameter 转换时使用. 该 AVP 包含 RADIUS Acct-Session-Id 属性的内容.

9.8.5. Acct-Multi-Session-Id AVP​

Acct-Multi-Session-Id AVP (AVP 代码 50) 类型为 UTF8String, 格式见第 8.8 节. Acct-Multi-Session-Id AVP 用于关联多个相关计费会话, 其中每个会话有唯一的 Session-Id, 但 Acct-Multi-Session-Id AVP 相同. 该 AVP 可以由 Diameter 服务器在授权应答中返回, 且必须用于该会话的所有计费消息.

9.8.6. Accounting-Sub-Session-Id AVP​

Accounting-Sub-Session-Id AVP (AVP 代码 287) 类型为 Unsigned64, 包含计费子会话标识符. Session-Id 与该 AVP 的组合对每个子会话必须唯一, 且对所有新子会话该 AVP 的值必须单调递增 1. 不存在该 AVP 表示未使用子会话, 但 Accounting-Record-Type 设为 STOP_RECORD 的 Accounting-Request 除外. 不含 Accounting-Sub-Session-Id AVP 的 STOP_RECORD 消息表示终止给定 Session-Id 的所有子会话.

9.8.7. Accounting-Realtime-Required AVP​

Accounting-Realtime-Required AVP (AVP 代码 483) 类型为 Enumerated, 由 Diameter 归属授权服务器发往 Diameter 客户端, 或由计费服务器在 Accounting-Answer 中发送. 客户端使用该 AVP 中的信息决定, 若因例如网络问题而暂时无法向计费服务器发送计费记录时应如何处理.

DELIVER_AND_GRANT 1

Value 设为 DELIVER_AND_GRANT 表示, 仅当与计费服务器存在连接时才必须授予服务. 注意, 在此意义上, 一组备选计费服务器被视为一台服务器. 需要将计费记录流迁移到备份服务器并不是终止对用户服务的理由.

GRANT_AND_STORE 2

Value 设为 GRANT_AND_STORE 表示, 若有连接则应当授予服务, 或者只要仍能按第 9.4 节所述存储记录就应当授予服务.

若授权服务器的应答中未包含该 AVP, 此为默认行为.

GRANT_AND_LOSE 3

Value 设为 GRANT_AND_LOSE 表示, 即使无法投递或存储记录, 也应当授予服务.

最后于 更新