4). Diameter Packet format Overview
§ The Diameter base protocol defines the protocol header and the necessary Attribute-Value Pairs (AVPs).
§ Diameter uses Attribute-Value pairs to send data or AAA specific information.
§ Diameter AVPs are defined in the base protocol or Diameter application documents.
§ The applications can extend the protocol by defining new messages and AVPs and append them to the Protocol Data Units (PDUs).
DIAMETER types of messages:
§ Two types of messages: Requests and Answers
§ Diameter is a request and answer protocol, xxR matches xxA; They always appear together.
§ Answer message contains Result-Code AVP
Request messages may be proxiable or non-proxiable (indicated by flag “P” in message header)
§ Non-proxiable: strictly intended for the next hop peer; never forwarded
§ Proxiable: routable and are routed by realm
4-1). Diameter Message format
§ The Diameter message consists of a Diameter header and one or more attribute-value pairs (AVPs) which carry authentication, authorization or accounting information or protocol specific data.
Figure: Diameter Message Format (N/A)
4-2). Diameter Message Header:
§ The Diameter header is 20 bytes, divided in fields
§ Each command request/answer pair is assigned a command code, and the sub-type (i.e., request or answer) is identified via the ‘R’ bit in the command Flag field of the Diameter header.
Figure: Diameter Message Header (N/A)
§ In the command Flag field the first four bits are defined, the other four are reserved for later use:
§ Request (R): If set, the message is a request. If cleared, the message is an answer.
§ Proxiable (P): If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.
§ Error (E): If set, the message contains a protocol error, and the error message will not conform to the ABNF described for this command. Messages with the 'E‘ bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages.
§ Potentially re-transmitted message (T): This flag is set after a link failover procedure, when a retransmission is sent, to help the removal of duplicate requests. This flag can only be set in request messages. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure.
§ The
§ The Hop-by-Hop Identifier aids in matching requests and replies.
§ In requests, the Hop-by-Hop Identifier is replaced at each hop as the Diameter message is relayed to its final destination.
§ The sender of an Answer message returns the same value that was found in the corresponding request.
§ The End-to-End Identifier, together with the origin host's identity, is used to detect duplicate request messages.
§ The End-to-End Identifier is unmodified as a request is forwarded to its final destination.
§ The originator of an Answer message returns the same value that was found in the corresponding request.
4
§ Based on the IETF RFC, the IANA has allocated a standard command code.
| Command-Name | Abbr. | Code |
| AA-Request | | 265 |
| AA-Answer | AAA | 265 |
| Diameter-EAP-Request | DER | 268 |
| Diameter-EAP-Answer | DEA | 268 |
| Abort-Session-Request | ASR | 274 |
| Abort-Session-Answer | ASA | 274 |
| Accounting-Request | ACR | 271 |
| Accounting-Answer | ACA | 271 |
| Credit-Control-Request | CCR | 272 |
| Credit-Control-Answer | CCA | 272 |
| Capabilities-Exchange-Request | CER | 257 |
| Capabilities-Exchange-Answer | CEA | 257 |
| Device-Watchdog-Request | DWR | 280 |
| Device-Watchdog-Answer | DWA | 280 |
| Disconnect-Peer-Request | DPR | 282 |
| Disconnect-Peer-Answer | DPA | 282 |
| Re-Auth-Request | RAR | 258 |
| Re-Auth-Answer | RAA | 258 |
| Session-Termination-Request | STR | 275 |
| Session-Termination-Answer | STA | 275 |
| User-Authorization-Request | UAR | 300 |
| User-Authorization-Answer | UAA | 300 |
| Server-Assignment-Request | SAR | 301 |
| Server-Assignment-Answer | SAA | 301 |
| Location-Info-Request | LIR | 302 |
| Location-Info-Answer | LIA | 302 |
| Multimedia-Auth-Request | MAR | 303 |
| Multimedia-Auth-Answer | MAA | 303 |
| Registration-Termination-Request | RTR | 304 |
| Registration-Termination-Answer | RTA | 304 |
| Push-Profile-Request | PPR | 305 |
| Push-Profile-Answer | PPA | 305 |
| User-Data-Request | UDR | 306 |
| User-Data-Answer | UDA | 306 |
| Profile-Update-Request | PUR | 307 |
| Profile-Update-Answer | PUA | 307 |
| Subscribe-Notifications-Request | SNR | 308 |
| Subscribe-Notifications-Answer | SNA | 308 |
| Push-Notification-Request | PNR | 309 |
| Push-Notification-Answer | PNA | 309 |
| Bootstrapping-Info-Request | BIR | 310 |
| Bootstrapping-Info-Answer | BIA | 310 |
| Message-Process-Request | MPR | 311 |
| Message-Process-Answer | MPA | 311 |
4-3B). Diameter Command Code values for 3GPP:
§ Based on the IETF RFC 3589 [10] the IANA has allocated a standard command code range 300 ‑ 313 for 3GPP.
| Command code | Command name | Abbreviation | Specified in 3GPP TS |
| 300 | User-Authorization-Request/-Answer | UAR/UAA | 29.229 [2] |
| 301 | Server-Assignment-Request/-Answer | SAR/SAA | |
| 302 | Location-Info-Request/-Answer | LIR/LIA | |
| 303 | Multimedia-Auth-Request/-Answer | MAR/MAA | |
| 304 | Registration-Termination-Request/-Answer | RTR/RTA | |
| 305 | Push-Profile-Request/-Answer | PPR/PPA | |
| 306 | User-Data-Request/-Answer | UDR/UDA | 29.329 [4] |
| 307 | Profile-Update-Request/-Answer | PUR/PUA | |
| 308 | Subscribe-Notifications-Request/-Answer | SNR/SNA | |
| 309 | Push-Notification-Request/-Answer | PNR/PNA | |
| 310 | Boostrapping-Info-Request/Answer | BIR/BIA | 29.109 [7] |
| 311 | Message-Process-Request/Answer | MPR/MPA | 29.140 [16] |
| 312 | GBAPush-Info-Request/Answer | GPR/GPI | 29.109 [7] |
4
http://docs.google.com/View?id=ddh56dhg_287ds83gngs
§ IETF RFC 5516 [23]. IANA has allocated the following command code values for the S
| Command code | Command name | Abbreviation | Specified in 3GPP TS |
| 316 | Update-Location-Request/Answer | ULR/ULA | 29.272 [21] |
| 317 | Cancel-Location-Request/Answer | CLR/CLA | |
| 318 | Authentication- Information -Request/Answer | AIR/AIA | |
| 319 | Insert Subscriber Data-Request/Answer | IDR/IDA | |
| 320 | Delete-Subscriber-Data-Request/Answer | DSR/DSA | |
| 321 | Purge-UE-Request/Answer | PUR/PUA | |
| 322 | Reset-Request/Answer | RSR/RSA | |
| 323 | Notify-Request/Answer | NOR/NOA | |
| 324 | ME-Identity-Check-Request/Answer | ECR/ECA |
4-4). Diameter application identifiers:
§ Each Diameter application MUST have an IANA assigned Application Identifier.
§ The base protocol does not require an Application Identifier since its support is mandatory.
Some of the application identifiers in use are:
§ Diameter Common Messages 0
§ NASREQ 1 [NASREQ]
§ Mobile-IP 2 [DIAMMIP]
§ Diameter Base Accounting 3
§ Credit Control 4
§ Relay 0xffffffff
§ The 3GPP specific application identifiers allocated by IANA are listed in the following table
4-5). Diameter 3GPP application identifiers:
§ The 3GPP specific application identifiers allocated by IANA are listed in the following table
| Application ID | Application | 3GPP TS | Description |
| 16777216 | 3GPP Cx/Dx | 29.228 and 29.229 | CSCF -- HSS |
| 16777217 | 3GPP Sh/Dh | 29.328 and 29.329 | AS – SLF/HSS |
| 16777218 | 3GPP Re | 32.296 | EBCF/SBCF – Rating Function |
| 16777219 | 3GPP Wx | 29.234 | AAA Server --- HSS |
| 16777220 | 3GPP Zn | 29.109 | NAF --- BSF (in GAA) |
| 16777221 | 3GPP Zh | 29.109 | BSF --- HSS (in GAA) |
| 16777222 | 3GPP Gq | 29.209 | PDF (PCRF) --- AF |
| 3GPP Gmb | 29.061 | GGSN --- BM-SC | |
| 16777224 | 3GPP Gx | 29.210 | PCRF (Gx) --- PCEF (in PCC) |
| 16777225 | 3GPP Gx over Gy | 29.210 | PCRF (Gx) --- PCEF (Gy) --- OCS |
| 16777226 | 3GPP MM10 | 29.140 | MMS Relay/Server --- MSCF |
| 16777229 | 3GPP Rx/Gx | 29.211 | Rx: PCRF --- AF and Gx:PCRF --- PCEF |
| 16777230 | 3GPP Pr | 29.234 | AAA Server --- Presence Network Agent |
| 16777236 | 3GPP Rx | 29.214 | PCRF --- AF (in PCC) |
| 16777238 | 3GPP Gx | 29.212 | PCRF --- PCEF (in PCC) |
| 16777250 | 3GPP STa | 29.273 | WLAN AN --- AAA Proxy or Server |
| 16777251 | 3GPP S | 29.272 | MME --- HSS and SGSN --- HSS |
| 16777252 | 3GPP S13/S | 29.272 | MME --- EIR and SGSN -- EIR |
| 16777264 | 3GPP SWm | 29.273 | AAA Proxy -- ePDG |
| 16777265 | 3GPP SWx | 29.273 | AAA Server --- HSS |
| 16777266 | 3GPP Gxx | 29.212 | PCRF --- BBERF (in PCC) |
| 16777267 | 3GPP S9 | 29.215 | V-PCRF --- H-PCRF (in PCC) |
| 16777268 | 3GPP Zpn | 29.109 | NAF --- BSF (in GAA Push Function) |
| 16777272 | 3GPP S6b | 29.273 | AAA Server or AAA Proxy --- PDN GW |
4-6). Diameter Attribute-Value Pairs (AVP)
§ Diameter uses Attribute-Value Pairs (AVP) to send data or AAA specific information.
§ Diameter AVPs are defined in the base protocol or Diameter application documents.
Figure: Diameter AVP Format (N/A)
§ Every AVP must be padded to align on a 32-bit boundary.
§ A Grouped AVP is an AVP whose data is a sequence of AVPs. Grouped AVPs are used to nest more AVPs in an AVP. In this case the data field of the AVP contains more AVPs.
§ The AVP Code and AVP Length fields determine the format and length of the Data field.
§ AVP Code: 1~255 reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. The AVP code combined with the vendor-ID gives a unique identification. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.
§ AVP Flags: V(endor specific), M(andatory), P(EncryPtion), r(eserve).
§ AVP Length: all AVP length, include AVP code, flag vendor-id and AVP data.
§ Vendor-ID: optional, set if AVP flag is V.
§ AVP Data field is zero or more octets and contains information specific to the Attribute.
§ AVP Data:
§ Basic format: OctetString, Integer32/64, unsigned32/64, float32/64, Grouped.
§ Derived AVP Data Formats: Address, Time, UTF8String…
§ Basic AVP Data Formats. Commonly used AVP Derived Data Formats are: Address, Time, UTF8String, DiameterIdentity, DiameterURI, Enumerated, IPFilterRule, QoSFilterRule.
The first three AVP flags are defined as follows:
§ AVP Flags: V(endor specific), M(andatory), P(EncryPtion), r(eserve).
§ 'V' Bit Means Vendor Specific; 'M' Bit means Mandatory; 'P' Bit means Protected.
§ Vendor-specific (V): Indicates whether the vendor-id field is present in the header - indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.
§ Mandatory (M): Indicates whether the support of this AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
§ End-to-end encryption (P): Indicates the need for encryption and end-to-end security.
§
4-7). Diameter 3GPP vendor identifier value:
§ The IANA has allocated a vendor identifier value 10415 for 3GPP
4-8). Diameter 3GPP specific AVP codes:
§ The 3GPP specific AVP codes refers to TS 29.230
