Diameter 协议详解 -----Diameter Credit Control Protocol AAA 东海陈光剑

DCC，就是Diameter Credit Control,即信用控制应用，属于应用协议.And it is a peer to peer protocol.

Diameter基础协议是各类应用实施的基本协议要求；

传输机制，主要定义Diameter协议传输层的问题及解决方法，还包括失败检测算法和状态机；

拥有各种不同功能的应用（包含DCC）都必须支持基础协议
 

AAA: Authentication Authorization Accounting

鉴权,授权,计费: 对特定用户的网络资源使用进行管理

Client--认证算法,认证服务器,数据库

随着不同网络的融合以及互联网的发展,催生了基于IP的新一代的AAA技术,于是Diameter Credit Control诞生了.

网络接入:
Wifi DSL MIP Internet
3G-->IP

IEEE802.16e

网络接入服务NAS

AVP:属性值对

Extensible Authentication Protocol
Cryptographic Message Syntax 密码消息语法

Peer to Peer 加密


client--server--agent--|-replay agent  redirect agent
			| proxy agent  translate agent
除了Diameter客户端和Diameter服务器外，还有Diameter中继、Diameter代理、Diameter重定向器和Diameter协议转换器。 



Diameter message format:

Version(8 bits)
Message Length(24 b)
Command-code(CER/CEA(257), DWR\DWA(280),DPR\DPA(282))


Capabilities-Exchange-Request/
Capabilities-Exchange-Answer（257）
        当俩个节点建立连接后,他们必须进行能力协商.了解对方的身份和能力(协议版本号,支持的应用,支持的安全机制). CER/CEA不能被代理,重定向和中继.


Disconnect-Peer-Request/
Disconnect-Peer-Answer（282）
        当发送端出现如下情况时,可以通知接收端断开传输层连接.内部资源不足;对于询问节点在可预测的将来没有任何消息需要其转寄

Device-Watchdog-Request/
Device-Watchdog-Answer（280）
        被用于察觉传输层错误


Re-Auth-Request/
Re-Auth-Answer（258）
        被用于重新鉴定和/或授权

Session-Termination-Request/
Session-Termination-Answer（275）
        正常终止一个被授权的会话,由接收装置发起.

Abort-Session-Request/
Abort-Session-Answer（274）
        异常终止一个被授权的会话,由服务器发起.

Credit-Control-Request/
Credit-Control-Answer（272）
        用于计费控制






Version: 必须为一,表明Diameter的版本为1
Message Length: Diameter信息的长度,包括头部
command flags: 格式如下
           0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |R P E T r r r r|
      +-+-+-+-+-+-+-+-+
R(equest):1为请求,0为应答
P(roxiable):1为信息可以通过代理
E(rror):1为协议错误
T(Potentially re-transmitted message):1为发生错误(没有收到响应)后的重转信息,且该信息必须为请求信息.




Application ID(32)
hop-by-hop identifier
end-to-end identifier


Command-Code: 用来表示这个消息所对应的命令，请求消息和相应的回答消息共享一个命令代码 
Application-ID: 指示消息适用的应用 
Hop-by-Hop Identifier: 逐跳标识用于判断请求与应答的对应关系
End-to-End Identifier: 用于重复消息的检查 
AVPs:消息头部后的全部字节就是消息的具体内容，以属性值对AVP（Attribute-Value-Pair）的形式逐个头尾衔接。 




   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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-





Attribute-Value-Pair:AVP

head--Data


移动互联网---IPv4--->IPv6--->未来AAA Diameter基于IPv6

RFC3588Diameter Protocol
Diameter standards



Diameter协议由IETF的AAA工作组制定，包括Diameter基本协议和一系列应用扩展。 
基础协议提供了作为一个AAA协议的最低需求，是Diameter网络节点都必须实现的功能，包括节点间能力的协商、Diameter消息的接收及转发、计费信息的实时传输等。
应用协议则充分利用基础协议提供的消息传送机制，规范相关节点的功能以及其特有的消息内容，来实现应用业务的AAA。 


目前最常用的认证计费协议——RADIUS 。
  RADIUS最初用来提供拨号PPP和终端服务器接入，但是随着Internet的发展和新的接入技术，路由器和网络接入服务器在复杂度和密度都有所增长，因而对AAA协议提出了新的要求。 在这种环境下, RADIUS的升级版本—— Diameter协议产生了


1.失败恢复机制。RADIUS协议没有定义失败恢复机制。而Diameter支持应用层确认，并且定义了失败恢复算法和相关的状态机。
 2. 安全性。RADIUS仅对响应报文定义了一种应用层认证和完整性机制，没有提供对每个数据包机密性的支持。而Diameter要求必须支持IPSec，以保证传输的安全。

3. 可靠性。RADIUS运行在UDP协议之上，并且没有定义重传机制。而Diameter运行在可靠的传输协议例如TCP，SCTP之上。 
4. Agent支持。RADIUS没有明确提供对代理，重定向和中继等Agent的支持。而Diameter明确定义了Agent的行为。 
5. 服务器发起消息。RADIUS的服务器发起消息支持是可选的，这使得主动断开连接或者跨越不同网络配置所需的重新认证/重新授权等特征难以实现。而在Diameter中，服务器发起消息是强制要求实现的。
 


基于规则引擎 可配置的计费能力
 动态规则引擎驱动，可以配置和扩展计费因素 灵活的支付方式、资费策略、促销和多层账户。运营商能够通过套餐销售，折扣及奖金来推广服务，并且为客户提供如多账户、共享账号和账户组等的多种特性服务。

可扩展的计费维度 在电信服务中影响计费的因素包括时间、地点和人。这些因素称为影响计费的维度，可以通过定义扩展属性、计费规则和资费策略来灵活扩展计费维度。并且这些扩展都是可以进行定制的。

可定制的流程
 业务流程、功能组件和数据源的关系是松耦合的。实时控制引擎可以使用各种功能（如认证、授权和计费）以定制计费流程。 流程的可定制性  适应多样化的计费要求。



命令码:CER/CEA

CER：
CER全称是Capabilities-Exchange-Req,顾名思义即diameter的一个实体用于咨询另外一个实体是否具体相应的能力，CER作为基础协议的一部分，在所有的应用层消息处理之前，必须通过CER


 CCR
CCR全称是Credit-Control-Req,即信用控制请求，即常说的DCC(Diameter Credit Control)

CCR(Initial)消息
01 00 02 EC 80 00 01 10 00 00 00 04 19 E6 B9 0B
19 E6 B9 0C 00 00 01 07 40 00 00 25 73 63 70 31
3B 31 32 36 34 31 34 31 31 30 37 3B 31 33 3B 30
30 30 30 30 30 30 30 30 31 00 00 00 00 00 01 08
40 00 00 0C 73 63 70 31 00 00 01 28 40 00 00 16
77 77 77 2E 68 75 61 77 65 69 2E 63 6F 6D 00 00
...
其中的00 02 EC表示消息的总长度，80 表示是请求,00 01 10是CCR的命令码272, 00 00 00 04 是应用ID，和CER消息中的应用ID相同.从00 00 01 07开始的是AVP，解析AVP时，第一个AVP的AVP码=0x107,即263,根据avp_define中的AVP定义:
>select * from avp_def where avp_code=263;

avpcode            263
group_flag         1   #表示是一个原子AVP，如果包含分组，则group_flag=0
datatype           2   #表示AVP是字符串类型
minlength          0
maxlength          128
minvalue           0
maxvalue           999999999
avpmultitimes      10
…
name_lang1         Session-Id
…
note_lang3         Session-Id
指明该AVP是一个字符串，AVP名称为Session-Id，解析时，根据AVP长度为0x25=37,得出AVP值为跟着的(37-8=)29个字节表示的字符串：73 63 70 31 3B 31 32 36 34 31 34 31 31 30 37 3B 31 33 3B 30 30 30 30 30 30 30 30 30 31，同时因为不够4字节对齐，补齐3个0X00，下一个AVP从00 00 01 08开始，AVP长度为12,即：00 00 0C,AVP值为12-8=4字节,即73 63 70 31，已经是4字节对齐，下一个AVP就从下一个节开始了.




AVP的数据类型
基本AVP 数据格式
数据字段为0到多个八位组，包含属性定义的信息。数据字段的格式和长度由AVP码和AVP长度字段决定。数据字段的格式必须是以下基本数据类型中的一种，或者是基本数据类型导出的一个数据类型。
OctetString
该数据包含任意可变长的数据。除非另外注明，AVP长度字段必须至少设置为8（如果“V”比特有效，则为12）。这种类型的AVP值的长度如果不是4个八位组的倍数，应按照需要填充，这样下一个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
该类型表示单精度浮点值，遵循IEEE标准754-1985中关于浮点的描述。该32比特值按网络字节顺序传送。AVP长度字段必须设置为12（如果“V”比特有效，则为16）。
Float64
该类型表示双精度浮点值，遵循IEEE标准754-1985中关于浮点的描述。该64比特值按网络字节顺序传送。AVP长度字段必须设置为16（如果“V”比特有效，则为20）。
Grouped
该数据字段定义为一个AVP序列。这些AVP按其定义的顺序排列，每一个都包括它们的头和填充位。AVP长度字段值设置为8（如果“V”比特有效，则为12），加上所有序列内的AVP的长度总和。因此Grouped类型的AVP的AVP长度字段总是4的倍数。
导出AVP 数据格式
除了使用基本AVP数据格式以外，应用可以定义从基本AVP数据格式导出的数据格式。定义新的AVP导出数据格式的应用必须包括一个名称为“导出AVP数据格式”的部分，使用和下面相同的定义格式。每一个新定义必须或者定义其格式，或者列出定义其格式的参考标准。
以下是常用的导出AVP数据格式。
Address
地址格式是从OctetString AVP基本格式导出的。它与其他数据格式不同，例如需要区分32比特（IPV4）或128比特（IPV6）地址。地址AVP的头两个八位组为AddressType，其包含一个在［IANA的“地址家族号码”］中定义的地址家族。AddressType用来区别剩下八位组的内容和格式。
Time
时间格式是从OctetString AVP基本格式导出的。该字符串必须包含4个八位组，与NTP时间戳格式的前4个字节格式相同。NTP时间戳在NTP协议规范［RFC2030］第3章中定义。本格式描述的时间，从通用协调时间（UTC）1900年1月1日0点开始。在UTC时间2036年二月7日6点28分16秒，时间值将溢出。SNTP规范中描述了将时间扩展到2104年的程序，所有DIAMETER节点都必须支持该程序。
UTF8String
UTF8String格式是从OctetString AVP基本格式导出的。该格式是使用ISO/IEC IS 10646－1字符集表示的人类可读的字符串，使用RFC 2279中描述的UTF-8转换格式，编码为一个OctetString。由于标准10646不断在更新版本中增加附加编码点，实施必须能够处理0x00000001到0x7fffffff之间的任何编码点。字节顺序不符合UTF-8字符集中编码点的有效编码、或者超出该范围都是被禁止的。控制符编码的使用应当是不允许的。但当需要另起一个新行时，可以使用控制符编码CR LF。应避免使用先导或尾随空白字符。由于用户接口硬件或软件并不直接支持编码点，可以提供其他替换的登录和显示方法，例如十六进制。对于7比特US-ASCII编码的信息，UTF-8字符集与US-ASCII字符集相同。UTF-8可以要求多个字节表示一个字符／编码点；因此一个UTF8String的长度（以八位组计）可能与编码字符的个数不同。注意UTF8String的AVP长度字段是以八位组衡量的，不是字符。
DiameterIdentity
DiameterIdentity格式是从OctetString AVP基本格式导出的。DiameterIdentity = FQDNDiameterIdentity值唯一标识一个Diameter节点，以用于重复连接和路由环路检测。字符串的内容必须是Diameter节点的FQDN。如果多个Diameter节点在同一台主机上运行，每个Diameter节点必须分配一个唯一的DiameterIdentity。如果一个Diameter节点可以由若干个FQDN标识，其中一个FQDN应在启动时被挑选出来，并作为该节点唯一的DiameterIdentity。
DiameterURI
DiameterURI必须遵循以下规定的统一资源标识符（URI）语法规则s
Enumerated
Enumerated是从Integer32 AVP基本格式导出的。该定义包含一个有效值的列表和他们的解释，并在引入该AVP的Diameter应用中有所描述。
IPFilterRule
IPFilterRule格式是从OctetString AVP基本格式导出的。其使用ASCII字符集。分组数据报
附：Diameter的国标版




AVP规则
“<”  AVP “>” 固定必须
“{”  AVP “}” 必须
“[” avp-name “]“ 可选


 CCR的内容

<Credit-Control-Request> ::= 
< Session-Id > :会话ID
{ Origin-Host } :发起主机
{ Origin-Realm } :发起主机所在域
{ Destination-Realm } :目的地主机所在域
[ Destination-Host ] ：目的地主机（可选）
{ CC-Request-Type } ：请求类型
（INITIAL_REQUEST，UPDATE_REQUEST，TERMINATION_REQUEST，EVENT_REQUEST）
{ CC-Request-Number } :请求的次数（从0开始，每次增1）
{ Service-Context-Id } ：服务内容
[ Requested-Service-Unit ] ：请求服务数



 CCA的内容

<Credit-Control-Request> ::= 
< Session-Id > :会话ID
{ Result-Code }:结果码
{ Origin-Host } :发起主机
{ Origin-Realm } :发起主机所在域
{ Destination-Realm } :目的地主机所在域（不存在）
[ Destination-Host ] ：目的地主机（可选） （不存在）
{ CC-Request-Type } ：请求类型
（INITIAL_REQUEST，UPDATE_REQUEST，TERMINATION_REQUEST，EVENT_REQUEST）
{ CC-Request-Number } :请求的次数（从0开始，每次增1）
{ Service-Context-Id } ：服务内容
[ Requested-Service-Unit ] ：请求服务数