---------選擇同學整理文檔
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基本協議命令字CER\DPR\DWR不能被轉發，ABNF范式中用PXY表示；
e) E: 如果本消息是響應消息，並且指明了某種錯誤信息，則置為1，該位不可在請求消息中設置，ABNF范式中用ERR表示；
f) T: 本消息是否是重發消息；
g) Command-Code: 消息命令字，響應消息和對應的請求消息的命令字是一樣的；Diameter協議的基本命令字包括CER\CEA(257), DWR\DWA(280), DPR\DPA(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的整數倍，不夠的以’\0’填充；
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 ]
CER\CEA是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 ]
DWR\DWA也是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 ]
DPR\DPA是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