diameter协议avp.docx

上传人:b****8 文档编号:12948727 上传时间:2023-06-09 格式:DOCX 页数:7 大小:19.42KB
下载 相关 举报
diameter协议avp.docx_第1页
第1页 / 共7页
diameter协议avp.docx_第2页
第2页 / 共7页
diameter协议avp.docx_第3页
第3页 / 共7页
diameter协议avp.docx_第4页
第4页 / 共7页
diameter协议avp.docx_第5页
第5页 / 共7页
diameter协议avp.docx_第6页
第6页 / 共7页
diameter协议avp.docx_第7页
第7页 / 共7页
亲,该文档总共7页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

diameter协议avp.docx

《diameter协议avp.docx》由会员分享,可在线阅读,更多相关《diameter协议avp.docx(7页珍藏版)》请在冰点文库上搜索。

diameter协议avp.docx

diameter协议avp

竭诚为您提供优质文档/双击可除

diameter协议,avp

  篇一:

aaa协议diameter和Radius进行比较总结

  aaa协议diameter和Radius比较总结今天就把两种主要的aaa协议diameter和Radius进行比较总结,如下:

  

(1)Radius固有的c/s模式限制了它的进一步发展。

diameter采用了peer-to-peer模式,peer的任何一端都可以发送消息以发起计费等功能或中断连接。

  

(2)可靠的传输机制。

Radius运行在udp协议上,并且没有定义重传机制,而diameter运行在可靠的传输协议tcp、sctp之上。

diameter还支持窗口机制,每个会话方可以动态调整自己的接收窗口,以免发送超出对方处理能力的请求。

  (3)失败恢复机制。

Radius协议不支持失败恢复机制,而diameter支持应用层确认,并且定义了失败恢复算法和相关的状态机,能够立即检测出传输错误。

  (4)大的属性数据空间。

diameter采用aVp(attributeValuepair)来传输用户的认证和授权信息、交换用以计费的资源使用信息、中继代理和重定向diameter消息等。

网络的复杂化使diameter消息所要携带的信息越来越多,因此属性空间一定要足够大,才能满足未来大型复杂网络的需要。

  (5)支持同步的大量用户的接入请求。

随着网络规模的不断扩大,aaa服务器需要同时处理的用户请求的数量不断增加,这就要求网络接入服务器能够保存大量等待认证结果的用户的接入信息,而Radius的255个同步请求显然是不够的,diameter可以同时支持232个用户的接入请求。

  (6)服务器初始化消息。

由于在Radius中服务器不能主动发起消息,只有客户能发出重认证请求,所以服务器不能根据需要重新认证。

而diameter指定了两种消息类型,重认证请求和重认证应答消息,使得服务器可以随时根据需要主动发起重认证。

  (7)diameter还支持认证和授权分离,重授权可以随时根据需求进行。

而Radius中认证与授权必须是成对出现的。

  (8)Radius仅仅在应用层上定义了一定的安全机制,但没有涉及到数据的机密性。

diameter要求必须支持ipsec以保证数据的机密性和完整性。

  (9)Radius没有明确的代理概念,Radius服务器同时具有proxy服务器和前端服务器的功能。

diameter加入代理来承担Radius服务器的proxy功能

  篇二:

ocp协议学习标记

  ocp协议学习笔记(协议结构和协议格式)

  (20xx-06-1022:

00:

37)

  转载▼

  标签:

分类:

  学习笔记杂谈

  一、ocp协议结构:

  ocp协议是建立在diameter基础协议上的diametercreditcontrolapplication应用协议的具体定义及扩展。

  ocp协议采用tcp作为传输层协议。

  diametercreditcontrolapplication:

dcc应用;

  tls:

transportlayersecurity,传输层安全;

  二、协议格式:

  1.消息头格式:

ocp协议的数据包是以网络字节顺序传送的。

  说明:

ocp协议的消息头长度为固定长度20个字节;

  a.version:

版本号,该版本字段必须置为1,表明diameter版本为1;

  b.messagelength:

该消息长度字段为3个八位组,指明该diameter消息的字

  节长度,包括头字段+aVps;

  mandflags:

该命令标记字段为8个比特。

已经分配的比特位如下:

  R(equest)-如果设置,表明该消息是一个请求。

如果清零,该消息是一个应答。

  p(roxiable)–如果设置,表明该消息可以被proxy、中继或者复位向。

如果清零,该消息必须在本地处理。

  e(rror)-如果设置,表明该消息包含一个协议差错,且该消息与abnF中描述的该命令不一致。

“e”比特设

  置的消息一般当作差错消息。

在请求消息中不能设置该比特。

  t(potentiallyre-transmittedmessage)-该标记在链路失败过程后被设置,以帮助去除重复的请求。

当重发请求还没有被确认时,需要设置该比特,以作为链路失败而造成的可能的重复包的指示。

当第一次发送

  一个请求时,该比特必须被清零,否则发送者必须设置该比特。

diameter代理仅需要关心它们发送的同一

  请求消息的遍数;其它实体进行的重传不须考虑。

diameter代理接收到一个t比特设置为1的请求,必须在

  前转该请求时保持t标记的设置。

如果接收到一个以前消息的差错消息(例如协议差错),则不可以设置该

  标记。

该标记只有在没有接收到任何来自服务器的该请求的应答、且该请求再次被发送的情况下,才能被

  设置。

该标记不能在应答消息中设置。

  r(eserved)-这些标记比特为将来使用预留,必须设置为0,接收者应当忽略。

  mand-code:

该命令码字段为3个八位组,用于表明与该消息相关联的命令。

该24位地址空间由ietF的

  iana负责分配管理。

例如:

ceR、cea消息命令码为257,ccR、cca消息命令码为272,dwR、dwa消息命令码为

  280。

  e.application-id:

应用id为4个8位组,用于标识该消息可适用于哪个应用。

  f.hop-by-hopidentifier:

hop-by-hop标识符为(diameter协议,avp)一个无符号32比特整数字段(按网络字节顺序),用来帮助

  匹配请求和响应。

发送者必须保证请求中的hop-by-hop标识符在特定的连接上在任何特定的时间是唯一的,

  并且保证该数字在经过重启动后仍然唯一。

  g.end-to-endidentifier:

端到端标识符是一个无符号32比特整数字段(按网络字节顺序),用来检测重复消息。

  h.aVps:

传递数据的部分,很多aVp头+数据的组合;

  例如:

dcc客户端和一个dcc服务之间ceR消息的消息头如下:

  010000d480000101000000000000000000000000

  说明:

010000d4---01:

dcc应用的版本为1,d4:

ceR消息的长度,10进制值为212,标识该ceR消息长度为

  212字节;

  80000101---80:

flags的值为128(10进制),表明是一个请求消息,0101:

值为257(10进制)与前面d步骤中ceR消息命令码257吻合;

  00000000---application-id,值为0

  00000000---hop-by-hop标识符,值为0

  00000000---end-to-end标识符,值为0

  2.aVp头格式:

aVp中的字段必须按网络字节顺序发送。

头的格式如图所示:

  说明:

  aVpcode:

aVp码与制造商id结合,可以唯一标识属性。

aVp1到255为前向兼容Radius预留,无需设置制造

  商id字段。

256以及大于256的aVp用于diameter,由iana负责分配。

  aVp标记:

aVp标记字段告知接收者如何处理每个属性。

  “r”:

(预留)比特不使用,应设置为0。

表示以后的diameter应用可以在aVp头中定义附加的比特,一个

  未被承认的比特应被看作差错。

  “p”比特指明为保证端到端安全需要加密。

  “m”比特,称为强制比特,指明对该aVp的支持是否是必需的。

如果diameter客户、服务器、proxy、或者

  翻译代理接收到一个aVp,其“m”比特设置为1,且该aVp或其值为未知,该消息必须被拒绝。

diameter中

  继和复位向代理不可以拒绝带有未知aVp的消息。

“m”比特清零的aVp仅是信息提示性的,接收者接收到其

  不支持的(包括不支持其值)“m”比特为零的aVp,可以简单忽略该aVp。

  “V”比特,称作制造商定义(Vendor-specific)比特,指明在aVp头中是否出现可选的制造商id字段。

当设

  置时,该aVp码属于某特定制造商编码地址空间。

除非另外注明,aVp将拥有以下缺省aVp标记字段设置:

  “m”比特必须设置。

“V”比特不可以设置。

  制造商id(Vendor-id):

如果在aVp标记字段中设置了“V”比特,则会出现制造商id字段。

可选的四个八位

  组的制造商id字段包含iana分配的“smi网络管理私有企业码”值,按网络顺序编码。

任何希望实现制造商

  定义(vendor-specific)diameter的制造商必须使用它们自己的制造商id,顺着它们的私有管理aVp地址空

  间,以保证它们与其它制造商的vendor-specificaVp以及将来的ietF应用的aVp都不会冲突。

制造商id值

  为0符合ietF采用的aVp值,由iana管理。

由于制造商id字段缺失暗示该aVp不是制造商定义的,应用不可以

  使用值为0的制造商id。

该字段为可选字段,如果该aVp值为ietF所定义,则该字段不出现;如果该aVp值为

  3gpp所定义,则该值为10415;如果该aVp值为中国电信所定义,则该值为81000。

  aVplength:

aVp长度字段为3个八位组,指明在这个aVp中的八位组的数量,包括aVp码、aVp长度、aVp标记、

  Vendor-id字段(如果出现)以及aVp数据。

如果接收到一个消息,其带有无效属性长度,该消息应被拒绝。

  3.ocp协议所用消息列表:

  命令名缩写命令码

  credit-control-RequestccR272

  credit-control-answercca272

  Re-auth-RequestRaR258

  Re-auth-answerRaa258

  abort-session-RequestasR274

  abort-session-answerasa274

  device-watchdog-RequestdwR280

  device-watchdog-answerdwa280

  disconnect-peer-RequestdpR282

  disconnect-peer-answerdpa282

  capabilities-exchange-RequestceR257

  capabilities-exchange-answercea257

  注:

  ccR/cca/RaR/Raa/asR/asa:

这几个都是和计费业务相关的消息;

  dwR/dwa:

消息和一般协议中的心跳消息类似,但是不完全一致,当最后一个计费消息上报并且超过一定时间

  未上报新的计费消息时,dcc服务会发送dwR消息监听dcc客户端是否处理连接状态;dpR/dpa:

切断连接请求,拆除掉两个dcc应用之间建立的连接;

  ceR/cea:

建立连接请求,一个dcc应用可以同时和多个dcc应用建立连接;

  例如:

一个完整的ceR消息:

  010000d4800001010000000000000000

  00000000000001084000003674796469

  6334342e68702e73656167756c6c2e75

  6e695f616c6c5f736d322e6368696e61

  篇三:

charging和billing的余额操作dcc接口(20xx0601)

  billing与charging的余额操作dcc接口

  1.billing与charging的dcc参数定义

  1.1.diameter接口概述

  传统的用于完成计费功能的Radius协议,以其简单安全,易于管理,扩展性好,而得到广泛应用。

但是由于协议本身的缺陷,比如基于udp的传输、简单的丢包机制、没有关于重传的规定和集中式计费服务,都使得它不太适应当前网络的发展,需要进一步改进。

  随着新的接入技术的引入和移动网络的快速扩容,对aaa协议提出了新的要求,使得传统的Radius结构的缺点日益明显。

目前3g网络正逐步向全ip网络演进,不仅在核心网络使用支持ip的网络实体,在接入网络也使用基于ip的技术,而且移动终端也成为可激活的ip客户端。

这就需要采用新一代的aaa协议——diameter。

diameter基础协议为各种认证、授权和计费业务提供了安全、可靠、易于扩展的框架。

以此为基础定义diameter应用,只需要定义应用协议的应用标识、参与通信的网络功能实体、相互通信的功能实体间的消息内容以及协议过程,就可以完全依赖diameter基础协议完成特定的接入和应用业务。

diameter协议具有如下特性:

  

(1)拥有良好的失败机制,支持失败替代(failover)和失败回溯(faiback);

(2)拥有快速检测到对端不可达的能力;

  (3)拥有更好的包丢弃处理机制,diameter协议要求对每个消息进行确认;(4)可以保证数据体的完整性和机密性;(5)支持端到端安全,支持tls和ipsec;(6)为每个会话进行认证/授权,以保证安全性;

  在diameter基础协议上扩展的应用协议diametercreditcontrolapplication,定义了针对预付费用户的计费机制,采用信用额度控制实现了基于会话及事件的计费,解决了对于预付费的计费需求。

1.2.dcc消息结构定义

  diametercc协议的消息结构如下,这些字段是以网络字节顺序传送的。

  1

  其中,aVp结构为:

  说明:

在消息体定义中,类型域中的octetstringn(n为整数),由基本类型octetstring派生出来,限制长度不大于n;必选属性域“m”表示该aVp在消息中必选,“c”表示该aVp在消息中条件可选。

对于aVp的m位属性和Vendor-id定义参见接口总册。

aVp名称前面的*表示该aVp是可重复的。

1.3.ccR和cca消息定义

  1.3.1.credit-control-Request消息定义

  :

:

=

  

  {origin-host}{origin-Realm}{destination-Realm}{auth-application-id}{service-context-id}{cc-Request-type}{cc-Request-number}[destination-host][user-name][origin-state-id][event-timestamp]*[subscription-id][termination-cause][Requested-action][multiple-services-indicator]*[multiple-services-credit-control]

  2

  [service-information]*[aVp]

  3

  4

  5

  

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2