DCC协议简介.doc_第1页
DCC协议简介.doc_第2页
DCC协议简介.doc_第3页
DCC协议简介.doc_第4页
DCC协议简介.doc_第5页
已阅读5页,还剩10页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

中国电信智能交换平台1.0-1.1 消息协议(DCC)1.1.1 DCC概述基于消息的协议通常用于实时通信的目的,消息协议SSAP基于DCC协议进行制定。传统的用于完成计费功能的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)为每个会话进行认证/授权,以保证安全性; 1.1.2 协议结构SSAP协议的协议结构如下表所示:IP/IPsecTCPSCTPTLSDiameter基础协议Diameter Credit Control Application协议结构SSAP协议是建立在Diameter基础协议上的Diameter Credit Control Application应用协议的具体定义及扩展。1.1.2.1 协议格式1.1.2.2 消息头格式DiameterCC协议的消息结构如图X所示,这些字段是以网络字节顺序传送的。 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 . +-+-+-+-+-+-+-+-+-+-+-+-+-图 1 消息头格式 Version:该版本字段必须被置为1,表明Diameter版本1。 Message Length:该消息长度字段为3个八位组,指明该Diameter消息的字节长度,包括头字段。 Command flags:该命令标记字段为8个比特。已经分配的比特位如下:0 1 2 3 4 5 6 7+-+-+-+-+-+-+-+-+|R P E T r r r r|+-+-+-+-+-+-+-+-+n R(equest) -如果设置,表明该消息是一个请求。如果清零,该消息是一个应答。n P(roxiable) 如果设置,表明该消息可以被Proxy、中继或者重定向。如果清零,该消息必须在本地处理。规定省间互联时发送的CCR/CCA消息必须置位。n E(rror) -如果设置,表明该消息包含一个协议差错,且该消息与ABNF中描述的该命令不一致。“E”比特设置的消息一般当作差错消息。在请求消息中不能设置该比特。n T(Potentially re-transmitted message)-该标记在链路失败过程后被设置,以帮助去除重复的请求。当重发请求还没有被确认时,需要设置该比特,以作为链路失败而造成的可能的重复包的指示。当第一次发送一个请求时,该比特必须被清零,否则发送者必须设置该比特。Diameter代理仅需要关心它们发送的同一请求消息的遍数;其他实体进行的重传不须考虑。Diameter代理接收到一个T比特设置为1的请求,必须在前转该请求时保持T标记的设置。如果接收到一个以前消息的差错消息(例如协议差错),则不可以设置该标记。该标记只有在没有接收到任何来自服务器的该请求的应答、且该请求再次被发送的情况下,才能被设置。该标记不能在应答消息中设置。n r(eserved) -这些标记比特为将来使用预留,必须设置为0,接收者应当忽略。 Command-Code:该命令码字段为3个八位组,用于表明与该消息相关联的命令。该24位地址空间由IETF的IANA负责分配管理。命令码值16,777,214和16,777,215(16进制的FFFFFEFFFFFF)被预留为实验使用。 Application-ID: 应用ID为4个八位组,用于标识该消息可适用于哪个应用。该应用可以是一个认证应用。头中的应用ID必须与该消息中包含的其他相关AVP相同。 Hop-by-Hop Identifier:Hop-by-Hop标识符为一个无符号32比特整数字段(按网络字节顺序),用来帮助匹配请求和响应。发送者必须保证请求中的Hop-by-Hop标识符在特定的连接上在任何特定的时间是唯一的,并且保证该数字在经过重启动后仍然唯一。应答消息的发送者必须确保Hop-by-Hop标识符字段维持与相应的请求相同的值。Hop-by-Hop标识符通常是单调升序的数字,其开始值是随机生成的。一个带有未知Hop-by-Hop标识符的应答消息必须被丢弃。 End-to-End Identifier:端到端标识符是一个无符号32比特整数字段(按网络字节顺序),用来检测重复消息。重启动实施可以设置高位12比特为包含当前时间的低位12比特,低位20比特为随机值。请求消息的发送者必须为每一个消息插入一个唯一的标识符。该标识符必须维持本地唯一至少4分钟,即使经过重启动。应答消息的生成者必须确保该端到端标识符字段包含与相应的请求相同的值。端到端标识符不可以被Diameter代理以任何原因修改。源主机AVP和该字段的结合可以用于检测重复。重复请求会造成相同应答的传输,并且不可以影响任何状态的设置,当处理原始请求时。应当在本地被消除的重复的应答消息将会被忽略。 AVPs: AVP是封装与Diameter消息相关信息的一种方法,参见4.2.3节。1.1.2.3 消息列表命令名缩写命令码Credit-Control-RequestCCR272Credit-Control-AnswerCCA272Device-Watchdog-RequestDWR280Device-Watchdog-AnswerDWA280Disconnect-Peer-RequestDPR282Disconnect-Peer-AnswerDPA282Capabilities-Exchange-RequestCER257Capabilities-Exchange-AnswerCEA2571.1.2.4 AVP头格式AVP中的字段必须按网络字节顺序发送。头的格式如图所示:0 1 2 30 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 . +-+-+-+-+-+-+-+-+图 2 AVP头格式 AVP CodeAVP码与制造商ID 结合,可以唯一标识属性。AVP 1到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-specific AVP 以及将来的IETF应用的AVP都不会冲突。制造商ID值为0符合IETF采用的AVP值,由IANA管理。由于制造商ID字段缺失暗示该AVP不是制造商定义的,实施不可以使用值为0的制造商ID。该字段为可选字段,如果该AVP值为IETF所定义,则该字段不出现;如果该AVP值为3GPP所定义,则该值为10415;如果该AVP值为中国电信所定义,则该值为81000。 AVP LengthAVP长度字段为3个八位组,指明在这个AVP中的八位组的数量,能包括AVP码、AVP长度、AVP标记、Vendor-ID字段(如果出现)以及AVP数据。如果接收到一个消息,其带有无效属性长度,该消息应被拒绝。1.1.2.5 AVP数据格式数据字段为0到多个八位组,包含属性定义的信息。数据字段的格式和长度由AVP码和AVP长度字段决定。数据字段的格式必须是以下基本数据类型中的一种。 OctetString该数据包含任意可变长的数据。除非另外注明,AVP长度字段必须至少设置为8(如果“V”比特有效,则为12)。这种类型的AVP值的长度如果不是4个八位组的倍数,应按照需要填充,这样下一个AVP(如果有)才能够在一个32比特边界开始。 Integer3232比特有符号值,按照网络字节顺序。AVP长度字段必须设置为12(如果“V”比特有效,则为16)。 Integer6464比特有符号值,按照网络字节顺序。AVP长度字段必须设置为16(如果“V”比特有效,则为20)。 Unsigned3232比特无符号值,按照网络字节顺序。AVP长度字段必须设置为12(如果“V”比特有效,则为16)。 Unsigned6464比特无符号值,按照网络字节顺序。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的倍数。 Address地址格式是从OctetString AVP基本格式导出的。它与其他数据格式不同,例如需要区分32比特(IPV4)或128比特(IPV6)地址。地址AVP的头两个八位组为AddressType,其包含一个在IANA的“地址簇号码”中定义的地址簇。AddressType用来区别剩下八位组的内容和格式。IANA的“地址簇号码”的定义参见【16】 Time时间格式是从OctetString AVP基本格式导出的。该字符串必须包含4个八位组,与NTP时间戳格式的前4个字节格式相同。NTP时间戳在NTP协议规范RFC2030第3章中定义。本格式描述的时间,从通用协调时间(UTC)1900年1月1日0点开始。在UTC时间2036年二月7日6点28分16秒,时间值将溢出。SNTP规范中描述了将时间扩展到2104年的程序,所有DIAMETER节点都必须支持该程序。 UTF8StringUTF8String格式是从OctetString AVP基本格式导出的。该格式是使用ISO/IEC IS 106461字符集表示的可读的字符串,使用RFC 2279中描述的UTF-8转换格式,编码为一个OctetString。 DiameterIdentityDiameterIdentity格式是从OctetString AVP基本格式导出的。DiameterIdentity = FQDNDiameterIdentity值唯一标识一个Diameter节点,以用于重复连接和路由环路检测。字符串的内容必须是Diameter节点的FQDN。如果多个Diameter节点在同一台主机上运行,每个Diameter节点必须分配一个唯一的DiameterIdentity。如果一个Diameter节点可以由若干个FQDN标识,其中一个FQDN应在启动时被挑选出来,并作为该节点唯一的DiameterIdentity。 EnumeratedEnumerated是从Integer32 AVP基本格式导出的。该定义包含一个有效值的列表及相关解释,并在引入该AVP的Diameter应用中有所描述。1.1.3 Diameter对等端通信模式1.1.3.1 对等端状态机所有的Diameter实施必须遵守本节所描述的有限状态机。任何Diameter节点与任何对等端通信时,都必须遵循下面描述的状态机。多个动作(action)由逗号分隔开,并且可以占用连续的多行。同样的,状态和下一个状态可以扩展占用多行。这个状态机与RFC3539中描述的状态机是紧密结合的,RFC3539中的状态机用于打开open、关闭close、失败替代failover、探测probe和重新打开传输连接。特别注意的是,RFC3539要求使用监控watchdog消息探测连接。对于Diameter,则使用DWR和DWA消息。I为前缀:表示发起侧(连接)连接;R为前缀:表示应答侧(监听)连接。没有前缀意味着事件或者动作是相同的,不管事件发生在哪个连接上。状态机中的稳定状态可以是关闭(closed)、IOpen和Ropen,其余的状态是中间状态。无论初始化侧还是应答侧传输连接被用于通信,Iopen和Ropen都是一样的。连接请求成功完成后,会立即在初始化连接上发送CER消息。在有两条连接的情况下,两条连接中的一条通过选举将会被关闭。如果应答方Diameter实体的Origin-Host高于其对等端,则应答侧连接会被保留。如果对等端的Origin-Host高于发起方Diameter实体,则发起方的连接会被保留。所有后继的消息都会在保留下来的连接上被发送。注意,在一个对等端上的选举结果,一定会是另一个对等端上选举结果的反转。对于TLS的使用,当两个端点均为打开open状态时,TLS握手开始。如果TLS握手成功,所有后续的消息均会通过TLS被发送。如果握手失败,两个端点同时转移到关闭closed状态。状态机仅约束Diameter实施的行为。通常认为产生出相同结果的任何实施是相兼容的。对等端状态机状态事件动作下一状态ClosedStartI-Snd-Conn-ReqWait-Conn-AckR-Conn-CERR-Accept,R-OpenProcess-CER,R-Snd-CEAWait-Conn-AckI-Rcv-Conn-AckI-Snd-CERWait-I-CEAI-Rcv-Conn-NackCleanupClosedR-Conn-CERR-Accept,Wait-Conn-Ack/ElectProcess-CERTimeoutErrorClosedWait-I-CEAI-Rcv-CEAProcess-CEAI-OpenR-Conn-CERR-Accept,Wait-ReturnsProcess-CER,ElectI-Peer-DiscI-DiscClosedI-Rcv-Non-CEAErrorClosedTimeout Error ClosedWait-Conn-Ack/ElectI-Rcv-Conn-AckI-Snd-CER,ElectWait-ReturnsI-Rcv-Conn-NackR-Snd-CEAR-OpenR-Peer-DiscR-DiscWait-Conn-AckR-Conn-CERR-RejectWait-Conn-Ack/ElectTimeoutErrorClosedWait-ReturnsWin-ElectionI-Disc,R-Snd-CEAR-OpenI-Peer-DiscI-Disc,R-OpenR-Snd-CEAI-Rcv-CEAR-DiscI-OpenR-Peer-DiscR-DiscWait-I-CEAR-Conn-CERR-RejectWait-ReturnsTimeoutErrorClosed状态事件动作下一状态R-OpenSend-MessageR-Snd-MessageR-OpenR-Rcv-MessageProcessR-OpenR-Rcv-DWRProcess-DWR,R-OpenR-Snd-DWAR-Rcv-DWAProcess-DWAR-OpenR-Conn-CERR-RejectR-OpenStopR-Snd-DPRClosingR-Rcv-DPRR-Snd-DPA,ClosedR-DiscR-Peer-DiscR-DiscClosedR-Rcv-CERR-Snd-CEAR-OpenR-Rcv-CEAProcess-CEAR-OpenI-OpenSend-MessageI-Snd-MessageI-OpenI-Rcv-MessageProcessI-OpenI-Rcv-DWRProcess-DWR,I-OpenI-Snd-DWAI-Rcv-DWAProcess-DWAI-OpenR-Conn-CERR-RejectI-OpenStopI-Snd-DPRClosingI-Rcv-DPRI-Snd-DPA,ClosedI-DiscI-Peer-DiscI-DiscClosedI-Rcv-CERI-Snd-CEAI-OpenI-Rcv-CEAProcess-CEAI-OpenClosingI-Rcv-DPAI-DiscClosedR-Rcv-DPAR-DiscClosedTimeoutErrorClosedI-Peer-DiscI-DiscClosedR-Peer-DiscR-DiscClosed1.1.3.2 输入连接当接收到Diameter 对等端发送来的连接请求时,一般情况下并不知道该对等端的身份,直到接收到对等端发送来的CER消息才可能知道对等端的身份。这是因为主机和端口决定Diameter 对等端的身份,一个输入连接的源端口是任意的。根据收到的CER消息,对等端的身份能够通过Origin-Host完全确定。基于该原因,Diameter对等端利用某种逻辑方法接收连接请求、接受请求、等待CER消息,这些过程必须与状态机无关。一旦在新连接上接收到CER消息,则使用标识对等端的OriginHost定位与该对等端相关联的状态机,新连接和CER消息被传递给状态机,这就是一个RConnCER事件。如果任何消息在CER之前到达,或者在收到CER消息之前,实施定义的定时器超时,则处理输入连接的逻辑方法应该关闭并且丢弃该连接。1.1.3.3 事件自动机中的转移和动作由事件引起。本节中,我们忽略I和R前缀,因为实际事件将会是相同的,只是仅会在两个可能的连接中的一个上发生。Start

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论