Diameter 基本概念
For RFC3588 and TS129.229
起源
• Diameter 协议的最初提出是作为 Radius 协
议的改进或者替代，它的引入是作为支持
基于 IP 技术的 AAA 协议。
功能
• Diameter 基础协议（RFC3588）旨在提供一个 AAA 框架：
1. 认证（Authentication），用户在使用网络系统中的资
源时对用户身份进行确认；
2. 授权（Authorization），网络系统授权用户以特定的方
式使用其资源；
3. 计费（Accounting），网络系统收集、记录用户对其资
源的使用情况，以便向用户收取资源使用费用，或者
用于审计等目的。
• Diameter 扩展协议根据这一框架实现特定的功能，例如
IMS 系统中的：
1. Cx 接口（I-CSCF / S-CSCF 与 HSS 间的接口）；
2. Rf 接口（离线计费接口），Ro 接口（实时计费接口）。
协议栈
•
•
•
•
•
Diameter 应用协议
Diameter 基础协议
TLS（传输层安全）
TCP / SCTP
IP / IPSec
协议栈 > SCTP
• SCTP 与 TCP 相同点是：
1. 面向连接；
2. 保证数据的可靠性和有序性；
3. 应用窗口机制以提供流控。
• SCTP 还提供一些 TCP 不具备的能力：
1. 两端点间的多数据流传输；
2. 面向消息，而 TCP 则是面向比特的；
3. 基于多宿主主机的高可用性，多宿主主机是
指一台具有多个网络接口的主机。
角色
• 每一个 Diameter 节点都被称为 Peer。任何
一个 Peer 至少充当如下角色之一：
1. Client
2. Server
3. Relay Agent（中继代理）
4. Proxy Agent（委托代理）
5. Redirector Agent（重定向代理）
6. Translation Agent（翻译代理）
角色 > Client / Server
• 发起请求消息方被称为 Client。
• 接收并处理请求方被称为 Server。
• 哪个节点作为 Client，哪个节点作为 Server
仅仅是一个逻辑概念，没有实际的物理实
现上的差别。
• Diameter 是对等协议（Peer-To-Peer
protocol）。
角色 > Client / Server
+--------------------+
|
+------+ |
|
| CSCF | |
|
+------+ |
ACR
+--------------------+
|
+------+ |------------------------------->| +------+
|
| Client | AS | |
| | CCF | Server |
|
+------+ |<-------------------------------| +------+
|
|
+------+ |
ACA
+--------------------+
|
| MGCF | |
|
+------+ |
+--------------------+
+--------------------+
RTR / PPR
+--------------------+
|
+------+ |<-------------------------------| +------+
|
| Server | CSCF | |
| | HSS | Client |
|
+------+ |------------------------------->| +------+
|
+--------------------+
RTA / PPA
+--------------------+
角色 > 中继代理
• 根据消息中的路由信息以及路由表转发消
息。
• 会在消息中插入、删除路由信息，但不会
修改消息的其它部分。
• 不维护会话状态，但必须维护事务状态。
• 可以减少服务器的配置负担。
+------+
| NAS |
+------+
example.net
1. Request
--------->
4. Answer
<---------
+------+
| DRL |
+------+
example.net
2. Request
--------->
3. Answer
<---------
+------+
| HMS |
+------+
example.com
角色 > 委托代理
• 与中继代理类似，根据消息中的路由信息
以及路由表转发消息。
• 但是除了会在消息中插入、删除路由信息，
还会修改消息的其它部分以提供增值功能。
角色 > 重定向代理
• 当中继代理无法找到适当的路由时，可以将消息
通过缺省路由发给重定向代理，重定向代理返回
一个特定路由响应给中继代理以重定向该消息。
• 存在的价值之一是集中配置域内所有的路由信息。
• 本身并不转发任何消息。
+------+
| DRD |
+------+
^
|
1. Request |
| 2. Answer (Redirect-Host)
|
v
3. Request
+------+
--------->
+------+
| NAS |
4. Answer
| HMS |
+------+
<--------+------+
example.net
example.com
角色 > 翻译代理
• 提供了协议转换的功能。
• 保证了传统 AAA 协议和新协议的互通。
RADIUS Request
Diameter Request
+------+
--------->
+------+
--------->
+------+
| NAS | RADIUS Answer
| TLA | Diameter Answer | HMS |
+------+
<--------+------+
<--------+------+
example.net
example.net
example.com
消息结构 > 消息头
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version
|
Message Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command flags |
Command-Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Application-ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Hop-by-Hop Identifier
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
End-to-End Identifier
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
消息结构 > 消息头
• Version：目前全部填写 1。
• Message Length：填写包含消息头的整个消息的长度。
• Command Flags：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
1. R：请求消息填写为 1，响应消息填写为 0；
2. P：本消息是否可以被转发；
3. E：如果本消息是响应消息，并且指明了某种错误信息，则置为 1；
4. T：本消息是否是重发消息。
• Command-Code：消息命令码，响应消息和对应的请求消息的命令码
是一样的。
• Application-ID：消息涉及的应用 ID。
• Hop-by-Hop，End-to-End：后面描述。
消息结构 > AVP 头
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
AVP Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r|
AVP Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-ID (opt)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+-+-+-+-+
消息结构 > AVP 头
• AVP Code：AVP 码。
• AVP Flags：
1. V：本 AVP 头之中是否出现 Vendor-ID 字段；
2. M：本 AVP 是否属于必需 AVP，有一些 AVP 是必须出现的，例
如 Original-Host AVP 和 Original-Realm AVP，Session-ID AVP 在
计费消息中必须出现；
3. P：本 AVP 的数据部分是否经过了加密。
• AVP Length：本 AVP 包含数据部分的长度，注意任何 AVP 的数
据部分长度都必须为 4 的整数倍，不够的以‘\0’填充。
• Vendor-ID：可选，标识生成本 AVP 值的设备的供应商。
• Data：记录具体的数据值，具体数据的类型是 AVP Code 决定。
消息结构 > 基本 AVP 格式
•
•
•
•
•
•
•
•
OctetString：包含任意长度的数据。除非另外注明，AVP 长度字段必须至少设
置为 8（如果“V”比特有效，则为 12）。这种 AVP 应该按照 32 比特对齐，这
样下一个 AVP 才能在一个 32 比特边界开始。
Integer32：32 比特有符号值，按照网络字节顺序传送。AVP 长度字段必须设
置为 12（如果“V”比特有效，则为 16）。
Integer64：64 比特有符号值，按照网络字节顺序传送。AVP 长度字段必须设
置为 16（如果“V”比特有效，则为 20）。
Unsigned32：32 比特无符号值，按照网络字节顺序传送。AVP 长度字段必须
设置为 12（如果“V”比特有效，则为 16）。
Unsigned64：64 比特无符号值，按照网络字节顺序传送。AVP 长度字段必须
设置为 16（如果“V”比特有效，则为 20）。
Float32：单精度浮点值，按照网络字节顺序传送。AVP 长度字段必须设置为
12（如果“V”比特有效，则为 16）。
Float64：双精度浮点值，按照网络字节顺序传送。AVP 长度字段必须设置为
16（如果“V”比特有效，则为 20）。
Grouped：包含一系列子 AVP。这些子 AVP 按其定义的顺序排列，每一个都包
括它们的头和填充位。AVP 长度字段必须设置为 8（如果“V”比特有效，则为
12）加上所有子 AVP 的 AVP 长度字段值的总和。
消息结构 > 派生 AVP 格式
•
•
•
•
•
Address：从 OctetString 格式派生。
Time：从 OctetString 格式派生。
UTF8String：从 OctetString 格式派生。
DiameterIdentity：从 OctetString 格式派生。
DiameterURI：从 OctetString 格式派生。它必
须遵循统一资源标识符（URI）语法规则。
• Enumerated：从 Integer32 格式派生。该定义
包含一个有效值的列表和它们的解释。
• IPFilterRule：从 OctetString 格式派生。
• QoSFilterRule：从 OctetString 格式派生。
消息结构 > Grouped AVP
• Grouped AVP 使消息呈现一个树形结构。
Command
|- Avp
|- Avp
|
|- Avp
|
|- Avp
|
\- Avp
|- Avp
\- Avp
对等端
• 一个 Diameter 节点具有和多个对等端通信
的能力。
对等端 > 对等端列表
• 每一个对等端列表项应包括：
1. Host identity，主机标识；
2. StatusT，对端状态，RFC3588 > 5.6；
3. Static or Dynamic，不确定；
4. Expiration time，不确定；
5. TLS Enabled，TLS 是否生效。
对等端 > 连接和会话
• 连接是两个对等端之间的一个传输层连接，用于
发送和接收消息。会话是一个应用层的逻辑概念，
在一个接入设备和一个服务器之间共享，并且通
过 Session-Id AVP 来标识。
• 连接和会话之间并没有关系，一个会话可以跨越
多个连接，而用于多会话的消息也可以在一个单
独的连接中传送。
+--------+
+-------+
+--------+
| Client |
| Relay |
| Server |
+--------+
+-------+
+--------+
<---------->
<---------->
peer connection A peer connection B
<----------------------------->
User session x
对等端 > 建立连接
• 两个对等端建立连接时，必须交换能力信息，以
了解对等端的标识和能力（协议版本号、支持的
应用、安全机制等）。一个节点必须缓存对等端
所支持的应用，以确保未被识别的命令和 AVP 不
会发送给它的对等端。
+--------+
+--------+
| Client |
| Server |
+--------+
+--------+
|
TCP / SCTP connect
|
|<----------------------------->|
|
CER
|
|------------------------------>|
|
CEA
|
|<------------------------------|
|
|
对等端 > 建立连接
• 能力交换请求消息（Capabilities-Exchange-Request）
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
对等端 > 建立连接
• 能力交换应答消息（Capabilities-Exchange-Answer）
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
* [ Failed-AVP ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
对等端 > 监视状态
+--------+
+--------+
| Client |
| Server |
+--------+
+--------+
|
DWR
|
|------------------------------>|
|
DWA
|
|<------------------------------|
|
|
对等端 > 监视状态
• 设备监控请求消息（Device-Watchdog-Request）
<DWR> ::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
• 设备监控应答消息（Device-Watchdog-Answer）
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]
对等端 > 断开连接
+--------+
+--------+
| Client |
| Server |
+--------+
+--------+
|
DPR
|
|------------------------------>|
|
DPA
|
|<------------------------------|
|
TCP / SCTP disconnect
|
|<----------------------------->|
|
|
对等端 > 断开连接
• 拆除对等端连接请求（Disconnect-Peer-Request）
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
• 拆除对等端连接应答（Disconnect-Peer-Answer）
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
消息处理 > 转发请求消息
• Diameter 节点根据请求消息中的转发信息以及对等端列
表对其进行转发。
• 转发信息包括：
1. Destination-Host AVP。
• 在转发请求之前，应该给该消息分配一个新的 Hop-byHop 值，然后在待响应请求列表中添加对应项；
• 待响应请求列表节点应记录：
1. 新分配的 Hop-by-Hop 值；
2. 上一跳的 Hop-by-Hop 值（非第一跳时）；
3. 上一跳的 Peer 信息，包括 IP、port 和 protocol 等（非
第一跳时）；
4. 消息体（可选）。
消息处理 > 路由请求消息
• Diameter 代理根据请求消息中的路由信息以及路由表对其进行
路由。
• 路由信息包括：
1. Destination-Realm AVP；
2. Acct-Application-Id AVP、Auth-Application-Id 或 Vendor-SpecificApplication-Id AVP；
• 路由表的生成依赖于对等端列表。
• 路由表的每一个路由项应包括：
1. 查询输入：域名，应用标识；
2. 查询输出：下一跳的主机名，该主机名必须出现在对等端列
表中。
• 在路由请求之前，在该消息中添加一个 Router-Record AVP，记
录上一跳的 Peer 标识。
消息处理 > 处理请求消息
• 消息中没有 Destination-Host AVP 和 Destination-Realm
AVP，则交给本端上层应用处理。
• 消息中有 Destination-Host AVP：
1. 如果其值等于本端标识，则交给本端上层应用处理；
2. 如果其值等于一个与本端直接相连的对端标识，则转
发给该对端处理。
• 消息中没有 Destination-Host AVP 但是有 DestinationRealm AVP：
1. 如果该字段值等于本端可以支持的域范围，并且本端
可以处理该应用的请求，则交给本端上层应用处理；
2. 否则查询路由表，寻找一个特定的路由将该消息转发
给一个与本端直接相连的对端。
消息处理 > 路由响应消息
• 响应消息根据待响应请求列表进行路由。
• 在路由响应消息之前，应该设置该消息的
Hop-by-Hop 值为待响应请求列表中对应项
的上一跳的 Hop-by-Hop 值，然后删除该对
应项。
消息处理 > 例子
• relay.cn 的对等端列表：
{ HostIdentity: "client.cn", ... }
{ HostIdentity: "relay.tw", ... }
{ HostIdentity: "relay.hk", ... }
• relay.cn 的路由表：
{ Realm: "tw", HostIdentity: "relay.tw" }
{ Realm: "hk", HostIdentity: "relay.hk" }
+----------+
+-----------+
+------------------| relay.tw |---------------| server.tw |
|
+----------+
+-----------+
|
+-----------+
+----------+
+----------+
+-----------+
| client.cn |---------------| relay.cn |---------------| relay.hk |---------------| server.hk |
+-----------+
+----------+
+----------+
+-----------+
消息处理 > 例子
1.
2.
3.
4.
5.
6.
7.
client.cn 产生 Request: { HopByHop: 1, DestinationHost: "server.hk", DestinationRealm:
"hk", ... }，待响应请求列表[1]: { LastHopByHop: null, ... }，发送 Request；
relay.cn 收到 Request，修改为 { HopByHop: 2, DestinationHost: "server.hk",
DestinationRealm: "hk", RouteRecord: "client.cn", ... }，待响应请求列表[2]:
{ LastHopByHop: 1, ... }，路由 Request；
relay.hk 收到 Request，修改为 { HopByHop: 3, DestinationHost: "server.hk",
DestinationRealm: "hk", RouteRecord: "relay.cn", RouteRecord: "client.cn", ... }，待响应请
求列表[3]: { LastHopByHop: 2, ... }，转发 Request；
server.hk 收到 Request，产生 Answer: { HopByHop: 3, ... }，发送 Answer；
relay.hk 收到 Answer，修改为 { HopByHop: 2, ... }，删除待响应请求列表[3]，转发
Answer；
relay.cn 收到 Answer，修改为 { HopByHop: 1, ... }，删除待响应请求列表[2]，转发
Answer；
client.cn 收到 Answer，删除待响应请求列表[1]。
+----------+
+-----------+
+------------------| relay.tw |---------------| server.tw |
|
+----------+
+-----------+
|
+-----------+ 1. Request -> +----------+ 2. Request -> +----------+ 3. Request -> +-----------+
| client.cn |---------------| relay.cn |---------------| relay.hk |---------------| server.hk |
+-----------+ <- 6. Answer +----------+ <- 5. Answer +----------+ <- 4. Answer +-----------+
错误处理 > 协议栈错误
• 当节点收到代表协议栈错误的响应消息或超时
没有收到响应消息时：
1. 如果保存了原始请求消息，可以寻找替代路
由发送该消息；
2. 否则，应该通知上一跳。
1. Request
+---------+ Link Broken
+-------------------------->|Diameter |----///----+
|
+---------------------|
|
v
+------+--+ | 2. Answer + ’E’ set | Relay 2 |
+--------+
|Diameter |<-+ (Unable to Forward) +---------+
|Diameter|
|
|
| Home |
| Relay 1 |--+
+---------+
| Server |
+---------+ |
3. Request
|Diameter |
+--------+
+-------------------->|
|
^
| Relay 3 |-----------+
+---------+
错误处理 > 应用错误
• 主要是消息格式或内容有错误，错误原因
由 Result-Code 表示。
+---------+ 1. Request +---------+ 2. Request +---------+
| Access |------------>|Diameter |------------>|Diameter |
|
|
|
|
| Home
|
| Device |<------------| Relay |<------------| Server |
+---------+ 4. Answer +---------+ 3. Answer +---------+
(Missing AVP)
(Missing AVP)
IMS 中的 Diameter 应用
Cx
命令
缩写
发送方向
User-Authorization-Request
UAR
I-CSCF -> HSS
User-Authorization-Answer
UAA
HSS -> I-CSCF
Multimedia-Auth-Request
MAR
S-CSCF -> HSS
Multimedia-Auth-Answer
MAA
HSS -> S-CSCF
Server-Assignment-Request
SAR
S-CSCF -> HSS
Server-Assignment-Answer
SAA
HSS -> S-CSCF
Location-Info-Request
LIR
I-CSCF -> HSS
Location-Info-Answer
LIA
HSS -> I-CSCF
Registration-Termination-Request
RTR
HSS -> S-CSCF
Registration-Termination-Answer
RTA
S-CSCF -> HSS
Push-Profile-Request
PPR
HSS -> S-CSCF
Push-Profile-Answer
PPA
S-CSCF -> HSS
Cx > UAR / UAA
• 应用场景：
1. 用户注册；
2. 用户注销。
• 作用：
1. I-CSCF 通过 HSS 查询 S-CSCF。
• HSS 处理：
1. 判断 IMPU 在当前网络是否具有漫游权限；
2. 判断 IMPU 是否有注册权限；
3. 判断 IMPU 是否未闭锁。
4. 返回 S-CSCF 的名字或能力集。
Cx > MAR / MAA
• 应用场景：
1. S-CSCF 向 HSS 获取鉴权向量（AV）；
2. UE 和 HSS 之间同步失败，S-CSCF 向 HSS 上报重同步请
求。
• HSS 重同步处理：
1. 解析和验证 AUTS；
2. 同步 SQNhe 为 SQNms；
3. 计算新的鉴权向量返回给 S-CSCF。
• HSS 鉴权向量处理：
1. 检查用户的注册状态并且判断 S-CSCF 的名字是否和
HSS 中保存的相同；
2. 计算鉴权向量返回给 S-CSCF。
Cx > SAR / SAA
• 应用场景：
1. S-CSCF 通知 HSS 注册或者注销用户；
2. S-CSCF 向 HSS 请求用户的签约数据。
• HSS 处理：
1. 检查用户的注册状态并且更新为新的注册
状态；
2. 为用户保存 S-CSCF 的名字；
3. 返回用户的签约数据和 / 或计费地址信息。
Cx > LIR / LIA
• 应用场景：
1. 当用户作为被叫，I-CSCF 向 HSS 查询用户所属
的 S-CSCF。
• HSS 处理：
1. 当用户的状态为 registered 或者 unregistered，
HSS 返回 S-CSCF 的名字；
2. 当用户的状态为 not registered，而且用户签
约了未注册状态业务，HSS 返回 S-CSCF 名字
或者能力集；
3. 其他情况，HSS 返回响应的错误信息。
Cx > RTR / RTA
• 应用场景：
1. 用户的签约关系被更改；
2. 用户分配了新的 S-CSCF；
3. 用户的 S-CSCF 将会产生变化；
4. S-CSCF 不能再为用户服务。
• HSS 发送 RTR 给 S-CSCF 进行网络侧用户注
销。
Cx > PPR / PPA
• 应用场景：
1. 当用户的签约数据或者计费地址信息被更
改，HSS 将更改后的数据通过 PPR 发送给
S-CSCF。
• S-CSCF 处理：
1. 马上更新用户数据；
2. 如果用户数据不支持、用户不存在或者用
户数据过大，将返回响应的错误码给 HSS。
Cx > 注册流程
Visited Network
UA
P-CSCF
1. Register
•
Home Network
I-CSCF
HSS
S-CSCF
2. Register
•
3. UAR
4. UAA
选择 S-CSCF
•
5. Register
6. MAR
选择鉴权向量
9. 401 Unauthorised
10. 401 Unauthorised
RAND||AUTN||CK||IK
RAND||AUTN
11. Register
12. Register
response
response
7. MAA
RAND||AUTN||XRES||CK||IK
8. 401 Unauthorised
RAND||AUTN||CK||IK
13. UAR
14. UAA
15. Register
response
鉴权
18. SAR
19. SAA
22. OK
21. OK
20. OK
I-CSCF 通过 UAR 向
HSS 查询 S-CSCF。
S-CSCF 通过 MAR 向
HSS 查询鉴权向量。
S-CSCF 通过 SAR 向
HSS 查询用户数据。