AVPs (Attribute-Value Pairs) carry all Diameter data. Each has an AVP Code, a flags octet (V vendor, M mandatory, P reserved), a length, an optional Vendor-Id, and a typed value. Values use base types such as Unsigned32, OctetString, Address, Time, Enumerated and Grouped. Result-Code and Experimental-Result AVPs report outcomes.
AVP structure
Every piece of Diameter data — identities, subscription fields, quotas, results — is encoded as an AVP. An AVP begins with a 32-bit AVP Code, then a flags octet, a 24-bit length covering the whole AVP, an optional 32-bit Vendor-Id, and the value padded to a 4-octet boundary. The AVP Code alone is unique within the IETF-managed space; when the V (Vendor-Specific) flag is set the code is instead interpreted within the numbering space of the Vendor-Id that follows — this is how 3GPP (Vendor-Id 10415) defines the hundreds of AVPs used by S6a, Gx and Cx without colliding with the base protocol.
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code (32) |
| V M P r r r r r| AVP Length (24) |
| Vendor-Id (32) — present only if V=1 |
| Data ... (padded to a 4-octet boundary) |The V, M and P flags
Three AVP flags govern how a receiver must treat the AVP. V (Vendor-Specific) signals that a Vendor-Id follows and the AVP Code lives in that vendor's space. M (Mandatory) is the important one: if M is set and the receiver does not understand the AVP, it must reject the whole message with DIAMETER_AVP_UNSUPPORTED (5001) — so setting M wrongly breaks interworking, and vendor AVPs an implementation may safely ignore are sent with M cleared. P was originally an end-to-end security marker; RFC 6733 deprecated that use and the bit is now reserved and set to zero.
| Flag | Name | Meaning when set |
|---|---|---|
| V | Vendor-Specific | A Vendor-Id field is present; code is in that vendor's space |
| M | Mandatory | Receiver must understand it or reject the message (5001) |
| P | (reserved) | Formerly end-to-end security; deprecated by RFC 6733, set to 0 |
Base data types
AVP values are strongly typed. RFC 6733 defines a set of basic types and several derived types built from OctetString. Integer and unsigned types carry counters, identifiers and enumerations; OctetString carries opaque or structured binary; and derived types add semantics an implementation can validate. Address encodes an IP address with a leading two-octet address family. Time is a 32-bit NTP-style seconds count. Enumerated is an Integer32 whose values are named by the application. DiameterIdentity and DiameterURI carry peer FQDNs and URIs.
| Type | Encoding | Typical use |
|---|---|---|
| Unsigned32 / Integer32 | 32-bit integer | Counters, quotas, Auth-Application-Id, Result-Code |
| Unsigned64 / Integer64 | 64-bit integer | Octet volumes, large counters |
| OctetString | Opaque octets | Binary payloads (auth vectors, TPDUs) |
| UTF8String | OctetString | Human-readable text (User-Name, product name) |
| Enumerated | Integer32 | Named value sets (e.g. RAT-Type, CC-Request-Type) |
| Address | OctetString + family | IPv4/IPv6 addresses (Host-IP-Address, Framed-IP) |
| Time | Unsigned32 | Seconds since 1900 (Event-Timestamp) |
| DiameterIdentity | OctetString | Peer FQDN (Origin-Host, Destination-Host) |
| Grouped | Nested AVPs | AVPs that contain other AVPs |
Grouped AVPs
A Grouped AVP has, as its value, a concatenated list of other AVPs — so structured records nest cleanly without new wire rules. Subscription-Data in S6a, Charging-Rule-Install in Gx and Experimental-Result all carry sub-AVPs inside a group. Grouping is recursive: a Grouped AVP can contain further Grouped AVPs, which is how a full LTE subscription profile or a set of PCC rules is expressed as one top-level AVP. Each contained AVP keeps its own code, flags and length, so a receiver parses the group with the same machinery it uses at the top level.
Result-Code and Experimental-Result
Diameter reports the outcome of a request in the answer. The base Result-Code AVP (code 268) is an Unsigned32 grouped into ranges by leading digit: 1xxx informational, 2xxx success, 3xxx protocol errors (from a proxy/relay), 4xxx transient failures the client may retry, and 5xxx permanent failures. When an application needs a vendor-specific error the base Result-Code cannot express, it uses the Experimental-Result AVP (code 297) — a Grouped AVP carrying a Vendor-Id plus an Experimental-Result-Code — which is how 3GPP signals errors like DIAMETER_ERROR_USER_UNKNOWN or DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
| Range | Class | Example |
|---|---|---|
| 1xxx | Informational | 1001 DIAMETER_MULTI_ROUND_AUTH |
| 2xxx | Success | 2001 DIAMETER_SUCCESS |
| 3xxx | Protocol error (proxy) | 3002 UNABLE_TO_DELIVER, 3007 APPLICATION_UNSUPPORTED |
| 4xxx | Transient failure (retry) | 4181 AUTHENTICATION_DATA_UNAVAILABLE (3GPP) |
| 5xxx | Permanent failure | 5001 AVP_UNSUPPORTED, 5012 UNABLE_TO_COMPLY |
Frequently asked
What is an AVP in Diameter?
An AVP (Attribute-Value Pair) is the unit of data in every Diameter message. It carries an AVP Code, a flags octet (V, M, P), a length, an optional Vendor-Id and a typed value. All identities, subscription fields, quotas and results are encoded as AVPs, and a message is a header followed by a list of them.
What does the M (Mandatory) flag do?
If the M flag is set and the receiver does not understand that AVP, it must reject the entire message with DIAMETER_AVP_UNSUPPORTED (5001). AVPs a peer may safely ignore are therefore sent with M cleared. Misusing the M bit is a common cause of interworking failures between vendors.
What is a Grouped AVP?
A Grouped AVP is an AVP whose value is itself a list of AVPs, letting structured records nest. Subscription-Data, Charging-Rule-Install and Experimental-Result are Grouped AVPs. Grouping is recursive, so a full LTE subscription profile or set of PCC rules can be carried as one top-level AVP.
How are vendor-specific AVPs identified?
By the V flag plus a Vendor-Id field. When V is set, a 32-bit Vendor-Id follows the length and the AVP Code is interpreted within that vendor's numbering space. 3GPP uses Vendor-Id 10415 to define the AVPs for S6a, Gx, Cx and the other application interfaces.
What is the difference between Result-Code and Experimental-Result?
Result-Code (AVP 268) carries the base IETF outcome codes grouped as 1xxx/2xxx/3xxx/4xxx/5xxx. Experimental-Result (AVP 297) is a Grouped AVP with a Vendor-Id and an Experimental-Result-Code, used when an application needs a vendor-specific error such as 3GPP's DIAMETER_ERROR_USER_UNKNOWN.
What do the Diameter result-code ranges mean?
1xxx is informational, 2xxx is success (2001 DIAMETER_SUCCESS), 3xxx is a protocol error usually raised by a proxy, 4xxx is a transient failure the client may retry, and 5xxx is a permanent failure. The leading digit tells a client whether to retry, fail or reroute.
Source specifications
The published standards this page is grounded in. Opens in a new tab.