---------选择同学整理文档
1. 协议概述
Diameter协议主要为应用程序提供认证、鉴权、计费框架,即AAA,并支持本地AAA和漫游场景下的AAA。
1.1. 特点介绍
以前的AAA协议如RADIUS、TACACS主要是针对PPP服务和终端服务而设计的。随着网络技术的发展,新的接入方式如无线接入、DSL接入、移动IP陆续出现,以太网也不断发展,AAA中的网络访问服务器(NAS)自身也逐渐变得越来越复杂。这些发展变化,对AAA协议提出了新的要求。原 有的AAA协议已经不能充分满足这些要求,而新一代AAA协议-Diameter协议却可以满足这些需求,主要包括如下几个方面:
1) 良好的故障切换机制。Diameter协议支持应用层的信息确认和失效检测机制。
2) 传输层安全。Diameter协议通过IPsec和TLS保证传输的安全性,其中TLS对于客户端来讲是可选的。
3) 可靠的传输。Diameter协议通过TCP或SCTP提供可靠的传输。
4) 支持各种类型的代理,包括中继代理、重定向代理、Proxy代理、协议转换代理。
5) 支持服务器发起消息。例如服务器可以发消息要求客户端重新认证。
6) 保持与现有网络AAA协议(如RADIUS)的兼容性。
7) 支持节点间的能力协商机制。
8) 支持对等端自主发现和配置机制。
9) 支持漫游。Diameter协议定义了域间漫游、消息路由及安全传输,能够提供安全漫游服务。
1.2. 协议框架
Diameter协议族包括基础协议和各种应用协议。
基础协议(RFC 3588):提供了作为一个AAA协议的最低需求,是Diameter网络节点都必须实现的功能,包括节点间能力的协商、Diameter消息的接收及转发、计费信息的实时传输等。基础协议可以作为一个计费协议单独使用,但一般情况下需与某个应用一起使用。
应用协议:充分利用基础协议提供的消息传送机制,规范相关节点的功能以及其特有的消息内容,来实现应用业务的AAA。
应用 |
ID |
Diameter Common Message |
0 |
NASREQ |
1 |
Mobile-IP |
2 |
Diameter Base Accounting |
3 |
Diameter Credit Control |
4 |
Diameter EAP Application |
5 |
3GPP保留(Cx/Dx接口) |
16777216 |
3GPP保留(Sh/Dh接口) |
16777217 |
Relay |
Oxffffffff |
注意:NASREQ(网络访问服务应用协议)、Mobile-IP(移动IP应用协议)、Diameter Credit Control(信用控制应用协议)、Diameter EAP Application(扩展认证应用协议)
1.3. 术语
• AAA
认证、鉴权、计费
• Accounting(计费)
为能力计划制定、审计、账单、费用分配等目的而进行资源使用的信息的收集动作。
• Accounting Record (计费记录)
记录某个用户在整个会话期间资源消费的情况,
• Authentication(认证)
校验一个实体一致性的动作。
• Authorization(鉴权)
决定一个请求实体是否允许访问某项资源。
• AVP (属性值对)
Diameter消息由一个报文头后跟一个或多个Attribute-Value-Pairs(AVPs),一个AVP包含一个头用于协议细节数据(例如路由信息)。
• Broker (代理)
代理是一个用于AAA架构中的商业术语,可以是relay, proxy,或者redirect agent。
• Diameter Agent(Diameter 代理)
指一个提供relay、proxy、redirect或翻译服务的diameter结点。
• Diameter Client(Diameter 客户端)
为一个处于网络边缘的,提供访问控制的设备。如NAS。
• Diameter Node(Diameter 节点)
为一个实现了diameter协议的主机进程,其行为为客户端、代理、服务端之一。
• Diameter Peer (Diameter 对端)
为一个具有直连连接的diameter节点。
• Diameter Security Exchange (diameter 安全交换)
为一个进程,两个diameter节点可以通过它建立端到端的安全。
• Diameter Server(diameter 服务端)
用于处理指定域中认证、鉴权、计费请求。
• End-to-End Security (端到端安全)
TLS和IPSec提供逐跳的安全,当relays或proxy很复杂时,逐跳的安全不能保证全部的diameter用户会话,端到端安全为两个diameter节点间的安全,或者Agent间的,这种安全保证了整个dimeter传送路径上的安全。
• Home Realm(归属域)
为一个维护帐户关系的管理域。
• Interim accounting(临时计费)
一个临时计费消息提供一个用户会话的使用快照,通常为一个用户会话在设备重启或者网络问题出现时提供部分的计费。
• Local Realm(本地域)
一个提供服务的管理域。
• Multi-Sessin(多会话)
一个多会话表示多个会话的逻辑连接,多会话使用Acct-Multi-Session-Id来跟踪。
• Network Access Identifier(网络接入标识)
即NAI,用来在diameter协议中提取一个用户的标识及域。用于在认证中识别用户,域用来消息路由。
• Proxy Agent or Proxy (代理)
除传输请求和响应外,代理制定与资源有关的策略,通常用来完成NAS设备状态的跟踪,代理在收到一个服务端的响应前不会对客户端的请求进行应答。当策略被违反时,它们可能会生成一个拒绝消息。因此,代理需要理解通过它们传输的消息的语义,它们可能不支持所有的diameter应用。
• Realm(域)
在NAI中跟在@符号之后的字符串,NAI的域要求为唯一的,且为DNS域的分段,用于判断消息是否满足本地处理的条件,或者被路由或重定向。
• Real-time Accounting(实时计费)
它包含在一个限定的时间窗内处理资源使用的信息,时间限制通常用来限制风险。
• Relay Agent or Relay(中继代理或转播)
转播请求和响应基于路由相关的AVPs和路由表,中继不会制定策略,他们不会检查或更改非路由AVPs,因此,中继从不产生消息,不需要理解消息的语义或者非路由AVPs,可能会处理八种diameter应用或消息类型,因此,中继依据路由和域来做决定,并且不保存NAS资源使用的状态或会话。
• Redirect Agent(重定向代理)
与其在客户端和服务端间传递消息,重定向代理涉及客户端和服务端,并允许它们直接通信,所以重定向代理不出现在传输路径中,它们从不修改客户端和服务端传输的任何AVPs,也不产生消息,可以处理任何消息类型,尽管它们可能仅配置为重定向特定类型的消息,与Proxy代理相比,重定向代理不保存会话或NAS资源相关的状态。
• Security Association(安全偶联)
一个安全的偶联是指两个端点之间的diameter会话,此会话允许端点完整且可信地通信,包括中继和/或Proxy。
• Session(会话)
会话是指一个事件相关的活动。每个应用应该为会话的开始和结束提供指导,所有具有相同会话标识的diameter包被认为同一个会话的一部分。
• Sub-session(子会话)
一个子会话表示一个明确的服务(例如Qos),这些服务可能同时或连续发生(例如同时产生的语音和同一会话中传输的数据)。此类会话由Accounting-Sub-Session-Id来跟踪。
• Transaction state(传输状态)
Diameter协议要求代理来维护传输状态,用于failover。传输状态暗指一个请求,逐跳标识被保存,且原来存储对应应答接收时的初始值字段被本地唯一标识符替代,当拒绝一个应答时请求的状态被释放。
• Translation Agent(传输代理)
是指为一个具有状态的dimaeter节点,用于在diameter和其它的AAA协议(如RADIUS)间进行翻译。
• Translation Connection(传输连接)
一个传输连接是指直接存在于两个diameter对端间的TCP或SCTP连接,或者说端到端连接。
• Upstream(上行)
用来标识一个特定的diameter消息从接入设备到归属服务器的传送方向。
• User(用户)
产生请求或使用某些资源的实体,支持diameter客户端产生一个请求。
1.4. Diameter角色
在Diameter协议之中,每一个(支持Diameter协议的)网络功能节点都称为Peer。任何一个Peer至少充当如下角色之一:
Diameter Client(客户端)
Diameter Server(服务端)
Diameter Relay Agent(中继)
Diameter Proxy Agent (代理)
Diameter Redirector Agent(重定向)
Diameter Translation Agent(翻译)
至少充当上述角色之一的含义是:一个Peer可能同时充当上述多种角色。
1.4.1. 角色-Client/Server
发起请求消息方被称为Diameter Client。
接收并处理请求方被称为Diameter Server。
Diameter协议中,哪个节点作为Client,哪个节点作为Server仅仅是一个逻辑概念,在Diameter协议层没有实际的物理实现上的差别。
如下图所示
1.4.2. 角色-Relay agent
能够从Diameter请求消息中提取信息,再根据Diameter基于域的路由表的内容决定消息发送的下一Diameter节点,Diameter中继只对过往消息进行路由信息的修改,而不改动消息中的其他内容。
Diameter协议层的角色:
a) 根据与路由相关的AVP和域路由表转发请求和响应消息
b) 中继不作策略决定,它们不检查或改变非路由AVP,不会更改消息体
c) 减轻了client和server的配置压力
d) 中继不需要维护会话状态,但需要维护事务状态
1.4.3. 角色-Redirect Agent
不知道如何路由的请求消息发给Diameter重定向器时,重定向器将根据其详尽的路由配置信息,把路由指示信息加入到请求消息的响应里,从而明确地通知该Diameter节点的下一跳Diameter节点。
Diameter协议层的角色:
a) 当Diameter Relay Agent无法寻找到恰当的路由时,可以将消息通过缺省路由发给Redirect Agent,由后者指定一个特定路由响应给Diameter Relay Agent,后者重定向该消息
b) 存在的价值之一是集中配置域内所有的路由信息
c) 本身并不转发任何消息,重定向Agent引导Diameter客户端到服务端,使得它们可以直接通信
1.4.4. 角色-Proxy/Translation Agent
根据Diameter路由表的内容决定消息发送的下一跳Diameter节点。此外,Diameter代理能够修改消息中的相应内容。主要用于实现RADIUS与Diameter,或者TACACS与Diameter之间的协议转换。
Proxy Agent是Diameter应用层的角色
a) 能够基于路由规则转发消息包
b) 能够基于特殊的代理功能需求去修改消息包的内容
c) 需要对资源进行限制的Proxy必须维护会话状态,所有的Proxy必须维护事务状态
Translation Agent是Diameter应用层的角色
a) 提供了协议转换的功能
b) 保证了传统AAA协议和新协议的互通
2. 消息结构
2.1. 消息头
a) Version: 目前全部填写1;
b) Message Length: 填写包含消息头的整个消息的长度;
c) R: 请求消息填写为1, 响应消息填写为0,ABNF范式中用REQ表示;
d) P: 本消息是否可以被转发,Diameter基本协议命令字CERDPRDWR不能被转发,ABNF范式中用PXY表示;
e) E: 如果本消息是响应消息,并且指明了某种错误信息,则置为1,该位不可在请求消息中设置,ABNF范式中用ERR表示;
f) T: 本消息是否是重发消息;
g) Command-Code: 消息命令字,响应消息和对应的请求消息的命令字是一样的;Diameter协议的基本命令字包括CERCEA(257), DWRDWA(280), DPRDPA(282);
h) Application-ID: 消息涉及的应用ID;
i) Hop-by-Hop:逐跳标识用于判断请求与应答的对应关系;
j) End-to-End:端到端标识主要用于重复消息的检查,此标识不可以被任何agent修改。该标识和Origin-Host结合起来可以用来检测重复消息。
2.2. 消息体
Diameter消息的消息体部分以AVP(Attribute-Value-Pair)为单位,Diameter把与一条消息相关的各种信息用一个个的AVP封装起来,然后逐个头尾衔接。每个AVP包含AVP头和Data部分。
a) AVP Code: AVP的类别,例如Original-Host AVP的Code值为264;
b) V: 本AVP头之中是否出现Vendor-ID字段;
c) M: 本AVP是否属于必需AVP,就一个特定的Diameter命令而言,有一些AVP是必须出现的,例如Original-Host AVP和Original-Realm AVP在任何Diameter消息之中都是必须出现的,Session-ID AVP在Diameter的计费应用命令字之中必须出现;
d) P: 本AVP的数据部分是否经过了加密;
e) AVP Length: 本AVP包含数据部分的长度,注意任何AVP的数据部分长度都必须为4的整数倍,不够的以’ ’填充;
f) Vendor-ID: 可选,标识生成本AVP值的设备的供应商,IANA给华为分配的Vendor-ID值为2011;
g) Data: 记录具体的数据值,具体数据的类型是由AVP Code决定的。
1. 消息数据类型
a) OctetString:可变长字符串
b) Integer32:32bit长的整数
c) Integer64:64bit长的整数
d) Unsigned32:32bit长的无符号整数
e) Unsigned64:64bit长的无符号整数
f) Float32:32bit长的浮点数
g) Float64:64bit长的浮点数
h) Grouped:一组数据类型的组合
i) Address:以OctetString 为基础,前两个字节为ddressType,从第三个字节开始表示地址。
j) Time:以OctetString为基础,表示从1900年1月1日0时起的秒数,到2036年02月7日6点28分16秒截止。
k) UTF8String:使用UTF-8传输格式。可变长度需要标具体使用情况。
l) DiameterIdentity:唯一表示DCC节点,用于重复连接和路由环路检测。DCC节点的FQDN。
m) Enumerated:枚举类型。
以Grouped为例
属性名 |
AVP码 |
章节号 |
数据类型 |
AVP标志规则 |
Encr |
|||
MUST |
MAY |
SHLD NOT |
MUST NOT |
|||||
Acct- Interim-Interval |
85 |
9.8.2 |
Unsigned32 |
M |
P |
|
V |
Y |
Accounting- Realtime-Required |
483 |
9.8.7 |
Enumerated |
M |
P |
|
V |
Y |
Acct- Multi-Session-Id |
50 |
9.8.5 |
UTF8String |
M |
P |
|
V |
Y |
Accounting- Record-Number |
485 |
9.8.3 |
Unsigned32 |
M |
P |
|
V |
Y |
Accounting- Record-Type |
480 |
9.8.1 |
Enumerated |
M |
P |
|
V |
Y |
Accounting- Session-Id |
44 |
9.8.4 |
OctetString |
M |
P |
|
V |
Y |
Accounting- Sub-Session-Id |
287 |
9.8.6 |
Unsigned64 |
M |
P |
|
V |
Y |
Acct- Application-Id |
259 |
6.9 |
Unsigned32 |
M |
P |
|
V |
N |
Auth- Application-Id |
258 |
6.8 |
Unsigned32 |
M |
P |
|
V |
N |
Auth-Request- Type |
274 |
8.7 |
Enumerated |
M |
P |
|
V |
N |
Authorization- Lifetime |
291 |
8.9 |
Unsigned32 |
M |
P |
|
V |
N |
Auth-Grace- Period |
276 |
8.10 |
Unsigned32 |
M |
P |
|
V |
N |
Auth-Session- State |
277 |
8.11 |
Enumerated |
M |
P |
|
V |
N |
Re-Auth-Request- Type |
285 |
8.12 |
Enumerated |
M |
P |
|
V |
N |
Class |
25 |
8.20 |
OctetString |
M |
P |
|
V |
Y |
Destination-Host |
293 |
6.5 |
DiamIdent |
M |
P |
|
V |
N |
Destination- Realm |
283 |
6.6 |
DiamIdent |
M |
P |
|
V |
N |
Disconnect-Cause |
273 |
5.43 |
Enumerated |
M |
P |
|
V |
N |
E2E-Sequence AVP |
300 |
6.15 |
Grouped |
M |
P |
|
V |
Y |
Error-Message |
281 |
7.3 |
UTF8String |
|
P |
|
V,M |
N |
Error-Reporting- Host |
294 |
7.4 |
DiamIdent |
|
P |
|
V,M |
N |
Event-Timestamp |
55 |
8.21 |
Time |
M |
P |
|
V |
N |
Experimental- Result |
297 |
7.6 |
Grouped |
M |
P |
|
V |
N |
Experimental- Result-Code |
298 |
7.7 |
Unsigned32 |
M |
P |
|
V |
N |
Failed-AVP |
279 |
7.5 |
Grouped |
M |
P |
|
V |
N |
Firmware- Revision |
267 |
5.3.4 |
Unsigned32 |
M |
P |
|
P,V,M |
N |
Host-IP-Address |
257 |
5.3.5 |
Address |
M |
P |
|
V |
N |
Inband-Security -Id |
299 |
6.10 |
Unsigned32 |
M |
P |
|
V |
N |
Multi-Round- Time-Out |
272 |
8.19 |
Unsigned32 |
M |
P |
|
V |
Y |
Origin-Host |
264 |
6.3 |
DiamIdent |
M |
P |
|
V |
N |
Origin-Realm |
296 |
6.4 |
DiamIdent |
M |
P |
|
V |
N |
Origin-State-Id |
278 |
8.16 |
Unsigned32 |
M |
P |
|
V |
N |
Product-Name |
269 |
5.3.7 |
UTF8String |
|
|
|
P,V,M |
N |
Proxy-Host |
280 |
6.7.3 |
DiamIdent |
M |
|
|
P,V |
N |
Proxy-Info |
284 |
6.7.2 |
Grouped |
M |
|
|
P,V |
N |
Proxy-State |
33 |
6.7.4 |
OctetString |
M |
|
|
P,V |
N |
Redirect-Host |
292 |
6.12 |
DiamURI |
M |
P |
|
V |
N |
Redirect-Host- Usage |
261 |
6.13 |
Enumerated |
M |
P |
|
V |
N |
Redirect-Max- Cache-Time |
262 |
6.14 |
Unsigned32 |
M |
P |
|
V |
N |
Result-Code |
268 |
7.1 |
Unsigned32 |
M |
P |
|
V |
N |
Route-Record |
282 |
6.7.1 |
DiamIdent |
M |
|
|
P,V |
N |
Session-Id |
263 |
8.8 |
UTF8String |
M |
P |
|
V |
Y |
Session-Timeout |
27 |
8.13 |
Unsigned32 |
M |
P |
|
V |
N |
Session-Binding |
270 |
8.17 |
Unsigned32 |
M |
P |
|
V |
Y |
Session-Server- Failover |
271 |
8.18 |
Enumerated |
M |
P |
|
V |
Y |
Supported- Vendor-Id |
265 |
5.3.6 |
Unsigned32 |
M |
P |
|
V |
N |
Termination- Cause |
295 |
8.15 |
Enumerated |
M |
P |
|
V |
N |
User-Name |
1 |
8.14 |
UTF8String |
M |
P |
|
V |
Y |
Vendor-Id |
266 |
5.3.3 |
Unsigned32 |
M |
P |
|
V |
N |
Vendor-Specific- Application-Id |
260 |
6.11 |
Grouped |
M |
P |
|
V |
N |
2. 常用命令
常用命令如下表所示
命令名 |
命令代码 |
缩略语 |
说明 |
Credit-Control-Request |
272 |
CCR |
信用控制请求和响应 |
Credit-Control-Answer |
272 |
CCA |
|
Re-Auth-Request |
258 |
RAR |
重新鉴权/授权请求和响应,该命令可以由任何服务器发送给提供会话服务的接入设备,来请求对用户进行重新认证/授权。 |
Re-Auth-Answer |
258 |
RAA |
|
Capabilities-Exchange-Request |
257 |
CER |
能力交换请求消息和响应 |
Capabilities-Exchange-Answer |
257 |
CEA |
|
Device-Watchdog-Request |
280 |
DWR |
设备监控请求和响应(心跳消息),用于进行链路异常检测,以降低消息被发送到无法响应的对端的可能性 |
Device-Watchdog-Answer |
280 |
DWA |
|
Disconnect-Peer-Request |
282 |
DPR |
拆除对等端连接请求和响应,将此消息发送至对等端,提示对方自己将关闭传输连接 |
Disconnect-Peer-Answer |
282 |
DPA |
|
Abort-Session-Request |
274 |
ASR |
中断会话请求和响应,它由任何服务器向提供接入服务的接入设备发送,来请求中断指定的会话 |
Abort-Session-Answer |
274 |
ASA |
2.1. 命令-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 ]
CERCEA是Diameter基本协议命令字,应用于连接建立过程中的能力协商。
以上Diameter命令符合ABNF定义,其表示如下
< XXX > 该AVP必须存在一个,且位置固定
{ XXX } 该AVP必须存在一个
1*{ XXX } 该AVP存在一个或者多个
°[ XXX ] 该AVP可存在一个或者不存在
* [ XXX ] 该AVP可存在零个或者多个
2.2. 命令-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 ]
DWRDWA也是Diameter基本协议命令字,实际上就是握手消息。
2.3. 命令DPR/DPA
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 ]
DPRDPA是Diameter基本协议命令字,当Peer发生问题需要终止时通知对端中断连接。
Diameter通过传输层TCP/SCTP建立连接后,传输的第一个消息就是CER/CEA,通过该消息的交互了解对端都支持哪些应用,看是否有共同的应用;如果对端是Relay Agent,则认为肯定存在共同应用;获知对方支持你哪些应用后,发送消息的时候就不会发送对方不认识的消息,对方对收到的不认识的消息也不会处理。此外双方的IP地址也会在CER/CEA消息中交换。CER/CEA是不能被Proxy,Relay或者是Redirection的,所以说CER/CEA只能是直连节点之间的交换,如果节点A经过Relay Agent发送消息到节点B,那么需要建立两个连接,进行两次CER/CEA的交互。当需要断开连接时,主动方需要发起DPR消息给对端指示断开传输层连接。在连接期间,双方需要互发DWR/DWA (Watching Dog)消息,用来检测对方是否处于Active状态。
3. 关键技术
3.1. Diameter对等端发现机制
1) 通过静态配置查找
2) 通过SLPV2发现diameter服务。(建议采用SLPV2的安全机制,保证被发现的对等端的角色是授权的。)
3) 通过NAPTR查询特定域中的服务器。
a) 如果没有发现NAPTR记录,则进行'_diameter._sctp'.realm 、'_diameter._tcp'.realm.形式的DNS查询。
b) 如果DNS服务器没有返回地址记录,则查询失败。
c) Diameter对等端列表和域路由表
对等端列表(Peer Table):
Host identity(包含CER、CEA消息中的Origin-Host AVP)
StatusT(动态或者静态)
TLS Enabled(是否采用TLS安全手段)
如果需要,还可以包括一些安全信息,如密钥、证书
Host identity |
StatusT |
Static or Dynamic |
Expiration time |
abc.example.com |
R-Open |
statically |
0 |
xyz.example.net |
R-Open |
dynamically |
10 |
域路由表:
Realm Name域名(域名是路由表查询中的主关键字)
Application Identifier应用标识(应用标识是路由表查询中的次关键字。同一个路由入口根据不同的应用,可以有不同的目的地址。)
Local Action本地动作,包括消息本地处理、中继、代理、REDIRECT重定向
Server Identifier服务器标识
Static or Dynamic静态或者动态
Expiration time动态路由的超时时间
Realm Name |
Application Identifier |
Local Action |
Server Identifier |
Static or Dynamic |
Expiration time |
example |
16777250 |
RELAY |
abc.example.com |
statically |
0 |
example |
16777272 |
RELAY |
xyz.example.net |
dynamically |
10 |
3.2. 能力交换
Capabilities-Exchange-Request(CER)能力交换请求:
Capabilities-Exchange-Answer(CEA)能力交换应答
能力交换内容:协议版本号、支持的Diameter应用及安全机制等。
3.3. Diameter对等端连接的中断
当一个Diameter节点中断和对等端的连接,对等端是无法了解中断的原因的。
在这种情况下,对等端可能会认为是连接出现问题,或者对方重启,因此它会周期性地进行连接重试。该动作通过TC定时器控制,通常建议30秒。
但是如果中断的原因是内部资源缺乏或者不希望和对方再保持连接, 则必须通知对方中断的原因,以避免不必要的周期性重试。
Disconnect-Peer-Request(DPR)对等端中断请求
Disconnect-Peer-Answer(DPA)对等端中断响应
3.4. 传输失败检测
尽快检测出差错可以降低将消息发送至无效代理的机会,减少不必要的时延,并且提供更好的Failover性能。
Device-Watchdog-Request(DWR)
Device-Watchdog-Answer(DWA)
3.5. Failover and Failback
当检测到一个对等端的传输失败时,必须将所有等待处理的请求消息发送到替代的Agent。
为了进行倒换,Diameter节点必须维护给定对等端的消息等待队列。
对于失败的对等端要进行周期性的尝试,以便重新建立连接。当传输恢复正常后,消息可以再次发送到该对等端,这被称为倒回。
3.6. 重复消息检测
重复检测用于应用服务器检测收到的请求消息是否与先前收到的消息有重复
Diameter消息中的T标志用来指示在应用层发生重传事件
可以根据Diameter头中的End-to-End Identifier和Origin-Host AVP对重复消息进行识别。
4. 消息路由规则
4.1. 创建与发送Request消息
1) 产生一个Request消息时,必须遵守下列规则:
•设置头部的Command code;
•设置头部的'R'位;
•设置头部的End-to-End为本地的唯一值;
•Origin-Host和Origin-Realm AVPs必须携带, 用来标识消息的源地址;
•Destination-Host和Destination-Realm AVPs需根据以下规则设置;
a) 不能被Proxy的消息一定不能带Destination-Realm and Destination-Host AVPs;
b) 如果消息是发往某个realm而不是具体的host,则只携带Destination-Realm AVP;
c) 如果消息是发往某个具体的host,则需要同时携带Destination-Realm and Destination-Host AVPs;
•如果消息有可能被转发,则消息中还必须携带下列AVP之一:an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP;
2) 当发送一个Request消息时,无论是源主机发送还是Agent转发,都需要执行下列操作:
a) 给该消息分配一个新的Hop-by-Hop值替换该消息之中的Hop-by-Hop字段值,同时将该消息原来的Hop-by-Hop字段值,上一跳信息记录在本端的待响应请求(Pending Request)队列之中;
b) 在该消息之中添加一个Router-Record字段值,具体信息为该消息的上一跳Peer标识;
待响应请求队列节点信息,每个待响应请求队列应该包含如下信息:
请求消息体,可选;
本请求消息的当前Hop-by-Hop值;
本请求消息的上一跳Hop-by-Hop值;
本请求消息的上一跳Peer信息。
待响应请求队列的作用是路由响应消息。
4.2. 收到Request消息
1) 任何一个Diameter Peer接收到请求消息后,首先判断是否为CER(能力交换请求)DWR(握手请求)DPR(断连请求)消息,然后则按照Peer基本状态机进行成立;
a) 如果满足如下条件,则本地处理:
•Destination-Host AVP包含了本地host的标识,
•Destination-Host AVP 不存在, Destination-Realm AVP 经过在路由表中查询被配置为本地处理,
•Destination-Host和Destination-Realm都不存在;
b) 如果Destination-Host AVP存在于本地的Peer table中,则执行Request Forwarding:
c) 如果没有本地处理也没有进行Request forwarding,则根据 Destination-Realm AVP 和 Auth-Application-Id 或 Acct-Application-Id 或 Vendor-Specific-Application-Id 查找Realm Routing Table,执行Request Routing;
d) 返回错误DIAMETER_UNABLE_TO_DELIVER;
注意:这里区分了Request forwarding和Request Routing;本文其它地方提到的“转发”都是泛指消息非本地处理的情况;
2) Request消息在被Relay或者Proxy的时候,Relay Agent和Proxy Agent需要做如下工作:
a) 在转发出去的Request消息中插入Route-Record AVP,里面包含发送该Request消息的主机标识;
b) 保存和该Request消息相关的:Protocol,IP Address,Port,Hop-by-Hop标识;保存这些信息是为了收到与该Reqeuest消息对应的Answer消息后能够将Answer消息正确的转发出去;
4.3. 创建Answer消息
当一个Request消息被本地处理后,必须按照如下规则创建并发送Answer消息:
a) 从Request消息中拷贝Hop-by-Hop填入Answer消息;
b) 将本地主机标识作为Origin-Host AVP;
c) Destination-Host和Destination-Realm AVPs不允许出现在Answer消息中;
d) 加上 Result-Code AVP指示成功与否.
e) 如果Request消息中包含了Session-Id,那么Answer消息中也应该包含该值;
f) 在Request消息中的任何Proxy-Info AVPs都应原封不动的拷贝到Answer消息中;
g) 'P'位需要和Request消息中保持一致;
h) End-to-End需要和Request消息中保持一致;
4.4. 收到Answer消息
Diameter协议对响应消息的路由完全不同于对请求消息的路由,这个过程只基于消息之中的Hop-by-Hop值,并且响应消息一定是按照对应请求消息的原路径返回的。
1) 任何一个Diameter Peer接收到响应消息后,首先判断是否为CEA(能力交换响应)DWA(握手响应)DPA(断连响应)消息,然则按照Peer基本状态机进行成立;
2) 如果不是,则取该响应消息的Hop-by-Hop字段值在待响应请求队列之中查找:
如果能够找到,则将该消息的Hop-by-Hop字段值填写为本端待响应请求队列之中记录的前一跳Hop-by-Hop值,然后将响应消息发送给本端待响应请求队列之中记录的前一跳Peer,并删除该待响应请求节点;
如果无法不能找到,直接扔弃该请求消息;
4.5. 错误异常处理
当Relay Agent长时间无法收到某个待响应请求队列中的节点对应的响应消息时,或者收到指明了错误信息的响应消息(例如Server忙,无法处理请求消息)时:
a) 如果Relay Agent保存了该原始请求消息,可以寻找替代路由发送该消息;
b) 如果Relay Agent未保存该原始请求消息,应将该响应消息发回给对应请求消息的上一跳。
5. Diameter在IMS中的应用
3GPP作为Diameter协议的提供者,IANA分配给3GPP的Vendor ID为10415。
Cx/Dx/Sh作为一种应用,IANA分配给Cx/Dx接口的Diameter应用标识为16777216,分配给SH接口的Diameter应用标识为16777217。
Diameter协议在IMS之中主要用于Rf接口(离线计费接口),Ro接口(实时计费接口),Cx接口(I-CSCF/S-CSCF与HSS的接口),Dx接口(I-CSCF/S-CSCF与SLF的接口)等。
SLF的角色为Diameter重定向代理功能,HSS为Diameter服务器,I/S-CSCF为Diameter客户端。
5.1. 接口命令消息
5.1.1. Cx/Dx接口命令消息
Source |
Destination |
Command-Name |
Abbreviation |
Code |
I-CSCF |
HSS |
User-Authorization-Request |
UAR |
300 |
HSS |
I-CSCF |
User-Authorization-Answer |
UAA |
|
S-CSCF |
HSS |
Server-Assignment-Request |
SAR |
301 |
HSS |
S-CSCF |
Server-Assignment-Answer |
SAA |
|
I-CSCF |
HSS |
Location-Info-Request |
LIR |
302 |
HSS |
I-CSCF |
Location-Info-Answer |
LIA |
|
S-CSCF |
HSS |
Multimedia-Authentication-Request |
MAR |
303 |
HSS |
S-CSCF |
Multimedia-Authentication-Answer |
MAA |
|
HSS |
S-CSCF |
Registration-Termination-Request |
RTR |
304 |
S-CSCF |
HSS |
Registration-Termination-Answer |
RTA |
|
HSS |
S-CSCF |
Push-Profile-Request |
PPR |
305 |
S-CSCF |
HSS |
Push-Profile-Answer |
PPA |
5.1.2. Sh接口命令消息
Source |
Destination |
Command-Name |
Abbreviation |
Code |
AS |
HSS |
User-Data-Request |
UDR |
306 |
HSS |
AS |
User-Data-Answer |
UDA |
|
AS |
HSS |
Profile-Update-Request |
PUR |
307 |
HSS |
AS |
Profile-Update-Answer |
PUA |
|
AS |
HSS |
Subscribe-Notifications-Request |
SNR |
308 |
HSS |
AS |
Subscribe-Notifications-Answer |
SNA |
|
HSS |
AS |
Push-Notification-Request |
PNR |
309 |
AS |
HSS |
Push-Notification-Answer |
PNA |
5.2. 基本流程
5.2.1. 用户注册
由上图可以看出HSS不但作为归属域的用户数据服务器,还作为Diameter服务器,为用户提供AAA服务。
用户注册所依照的参考点为Cx(HSS与CSCF之间的参考点),用户注册过程中所涉及的Diameter命令如上表所示。
如下为用户成功注册的过程描述:
1) 用户终端向P-CSCF发SIP Register消息请求注册,但注册消息中没包含完整的认证(Authorization)的信息;
2) P-CSCF查询DNS服务器获取归属域的I-CSCF的IP地址;
3) P-CSCF将SIP Register消息转发给归属域的I-CSCF;
4) 归属域的I-CSCF收到Register请求后,发UAR消息向HSS查询用户的注册状态(或者说查询S-CSCF);
5) HSS发UAA回应查询请求;对于已经注册的用户则回应用户已经注册在哪个S-CSCF;对于没有注册的用户,返回S-CSCF能力集,I-CSCF会根据这个能力集选择一个具备这种能力的S-CSCF并把注册请求转发给它。
6) 归属域的I-CSCF将Register消息转发给查询到的归属域的S-CSCF;
7) S-CSCF发MAR到HSS,查询如何认证;
8) HSS回应MAA,MAA包含认证有关信息;
9) S-CSCF根据收到的MAA包含的认证信息,对本次注册进行判断,认为注册失败(由于注册消息中没包含完整的认证信息),需要用户终端重发包含认证的注册信息;
10) S-CSCF回SIP 401(认证失败)给I-CSCF,401中包含了认证所需的信息,如随机数(nonce)、算法等;
11) I-CSCF再把401转发给P-CSCF,P-CSCF再转发给用户终端;
12) 用户终端重新向P-CSCF发SIP Register消息请求注册,消息包含了认证有关信息,如随机数(nonce)及其response等;
13) 重复以上2到6部后,S-CSCF认为本次收到的注册信息有效,用户注册成功;
14) S-CSCF向HSS发送SAR,要求更新此用户的S-CSCF信息;
15) HSS回应SAA,表示此用户的S-CSCF的信息更新成功,SAA还包含用户的配置文件(userdata);
16) S-CSCF向I-CSCF发200,表示注册成功;I-CSCF再将200转发给P-CSCF,P-CSCF再转发给用户终端,用户成功注册。
5.3. Diameter消息实例分析
下面以UAR消息为例,熟悉一下Diameter消息的格式。如下是一个UAR消息的十六进制的原始代码:
01000140 c000012c 01000000 4f8cdca1 c3be982e 00000107 4000003f 69637366
2d737464 6e2e696d 73677270 2d303030 2e696d73 2e637463 2e636f6d 3b323337
34303434 37323b32 33373430 34343732 3a303000 00000104 40000020 0000010a
4000000c 000028af 00000102 4000000c 01000000 00000115 4000000c 00000001
00000108 40000028 69637366 2d737464 6e2e696d 73677270 2d303030 2e696d73
2e637463 2e636f6d 00000128 40000013 696d732e 6374632e 636f6d00 0000011b
40000013 494d532e 4354432e 434f4d00 00000001 40000008 00000259 c0000029
000028af 7369703a 2b383631 30383838 38323030 3140696d 732e6374 632e636f
6d000000 00000258 c0000017 000028af 696d732e 6374632e 636f6d00 00000125
40000011 4354435f 4843462d 34000000 0000026f c0000010 000028af 00000000
解释此Diameter消息如下:
01000140:版本为1,长度为320(0x000140)字节。
c000012c:本消息是请求(Request)消息,可以被代理处理、可以被转发、重定向;本消息的命令代码为UAR(300,0x00012c)。
01000000:应用标识为16777216(见表4)。
4f8cdca1 c3be982e:逐跳标识和端到端标识。
随后为多个属性值对(AVP),现在只列举两个具有代表性的AVP:
第一个AVP如下(AVP Code由Diameter基本协议定义):
00000107 4000003f 69637366 2d737464 6e2e696d 73677270 2d303030 2e696d73 2e637463 2e636f6d 3b323337 34303434 37323b32 33373430 34343732 3a303000:
AVP命令是Session-Id(263,0x00000107),Vendor标志位为0(此AVP不包含Vendor-ID),AVP长 度为63(0x00003f)。之后的为数据部分,表示:icsf-stdn.imsgrp- 000.ims.ctc.com;237404472;237404472:00。最后的00为补足32比特而加上的。
再一个AVP如下(AVP由3GPP TS29.229定义):
00000258 c0000017 000028af 696d732e 6374632e 636f6d00:
AVP命令是Visited-Network-Identifier(600,0x00000258),Vendor标志位为1(此AVP包含 Vendor-ID),AVP长度为23(0x000017),Vendor-ID为10415(0x000028af)。之后为数据部分,表 示:ims.ctc.com。
上面的Diameter消息的完整解释如下:
Message:
version (1B) = 0x01 - 1
requestFlag (1b) = 1
proxyableFlag (1b) = 1
errorFlag (1b) = 0
retransFlag (1b) = 0
cmdCode (3B) = 0x00012c - 300
appIdType (4B) = 0x01000000 - 16777216
hopByHopId (4B) = 0x4f8cdca1 - 1334631585
endToEndId (4B) = 0xc3be982e - 3284047918
Command UserAuthorizationRequest:
AVP SessionId 1/1 = icsf-stdn.imsgrp-000.ims.ctc.com;237404472;237404472:00
AVP VendorSpecificApplicationId 1/1
AVP VendorId 1/1 = 0x000028af - 10415
AVP AuthApplicationId 1/1 = 0x01000000 - 16777216
AVP AuthSessionState 1/1 = 0x00000001 - 1 - NoStateMaintained
AVP OriginHost 1/1 = icsf-stdn.imsgrp-000.ims.ctc.com
AVP OriginRealm 1/1 = ims.ctc.com
AVP DestinationRealm 1/1 = IMS.CTC.COM
AVP UserName 1/1 =
AVP PublicIdentity 1/1 = sip:+861088882001@ims.ctc.com
AVP VisitedNetworkIdentifier 1/1 = ims.ctc.com
AVP DestinationHost 1/1 = CTC_HCF-4
AVP UserAuthorizationType 1/1 = 0x00000000 - 0 - Registration
6. 参考文档
RFC 3588