top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

AVP Structure in Diameter Protocol

+9 votes
2,402 views

Diameter AVPs are the basic unit inside the Diameter message that carries the Data(Authentication Data , Security Data , Data pertaining to Application etc). There must be at least one AVP inside Diameter message.

AVP has following frame format.
AVP Format

Diameter AVP Structure

AVP Code (4-bytes)
The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.
AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field.

AVP Flag (1-Byte [VMPRRRRR])
These flag give the information to the receiver how the each attribute to be handled. R- Reserved bits and SHOULD be set to 0.

M-Mandatory Bit
* Means If this bit is Set then Diameter Client, Server,Proxy and Translation Agent MUST support the handling of this AVP. If Handling is not support(Either AVP or Its value is Unrecognized) by the mentioned Diameter Agents then Diameter message MUST be Rejected.
* Diameter Relay and Redirect Agent MUST not reject the message with unrecognized AVPs.
* If M bit is clear and Receiver does not support the handling of considered Avp then Receiver may ignore the considered AVP.

V- Vendor Id Bit
* It is just the indication whether Vendor-Id field is there in the AVP or Not
* If V is Set the Vendor-Id Field is prsent in the AVP Otherwise missing this Field.

Vendor-ID (4- bytes)
Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" value.
As we know Diameter is Extensible Protocol, so any vendor wishs to implement vendor-specific Diameter AVp MUST use Their OWN Vendor-ID along with their privately managed AVP address Space.

P-Protected Bit
This bit is set indicates that Avp data is encrypted for end-to-end security.

AVP Length (3- bytes)
Contains No. of octets used by Data + Vendor-ID + AVP Code + AVP Length + AVP Flags.

Data
Data Field is of ZERO or More octets and contains information. AVP with Zero octet length is used for indications only.The format of the Data field MUST be one of the data type defined in Base Diameter protocol RFC-3588.

Grouped AVP
Grouped AVP more or less same like the single AVPs except that the data field of grouped avp contains the one or move avps rather than Raw data. Here avps act as data.

posted Feb 6, 2014 by Satish Mishra

  Promote This Article
Facebook Share Button Twitter Share Button LinkedIn Share Button


Related Articles

Diameter Header Structure

Diameter is Message (Packet) based protocol. There are two types of messages Request Messages and Answer Messages.And the Message structure is of following sort.

Header Structure

Version This Version field MUST be set to 1 to indicate Diameter Version 1.

Message Length Contain the length of Message Header + (Data) Avp

Command Flags The Command Flags field is eight bits. The following bits are assigned:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+

R(equest) - If set, the message is a request. If cleared, the message is an answer.

P(roxiable) - If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.

E(rror) - If set, the message contains a protocol error, This bit MUST NOT be set in request messages.

T(Potentially re-transmitted message) - This flag is set after a link Failover procedures to aid the removal of duplicate requests.
It is set when resending a request that not yet acknowledged,as an indication of a possible duplicate due to a link failure. This bit MUST be cleared when sending a request for the first time, otherwise the sender MUST set this flag.Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request and the request is sent again. This flag MUST NOT be set in answer messages.

r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.

Command-Code To uniquely identify the each diameter message IANA has assigned the unique command code for each Request. The answer of this Request will also have the same command code but have Bit-R=0.The Command-Code field is three octets.
For Example :Command code for User-Authorization-Request is 300, 301 for Server-Assignment-Request and 280 for Device-Watchdog-Request etc.

Application-ID As we know that Base Diameter Protocol is the extensible protocol, so many application/interfaces are built by using the Base Diameter Protocol, Therefore to uniquely identify the each application IANA gives the Application-Id to each application.
There is also an Application-ID Avp, so in one application these two field (Application-ID Avp and Application-ID in structure) will contain the same value. Application-ID is four octets.
For Example : Application Id for S6a/s6d interface is 16777251 and for S13 is 16777252

Hop-by-Hop Identifier The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) and aids in matching requests and replies.The sender MUST ensure that the Hop-by-Hop identifier in a request is unique on a given connection at any given time, and MAY attempt to ensure that the number is unique across reboots. The sender of an Answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding
request.
The Hop-by-Hop identifier is normally a monotonically ncreasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded.Use of Hop-By-Hop Identifier is explain below with figure.

End-to-End Identifier The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) and is used to detect duplicate messages. The identifier MUST remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an Answer message MUST ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request.
The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the hop-by-hop Identifier field and any routing AVPs that may be present),and MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed SHOULD be silently discarded.

 READ MORE
...