Diameter Message Structure and Message Flow

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.

Diameter Message 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.
For instance
 Re-Transmission

Client triggers a request to server and at that instance,

suppose server was down, so client does not receive
the answer/acknowledgement for that message then after a
certain period of time the client will trigger the same request
with bit-T=1 and this is called the retransmission.

if client receive the error-Answer-message then client will not

trigger the same request message with bit-T=0,because error-
Answer-messgae it self the answer-message or acknowledgemet for
that request.

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.Use of End-To-End
Identifier is explained below with Example.

Message Flow Explained

Hop-By-Hop Identifier =H-Id
End-To-End Identifier =E-Id

Message Flow among Diameter Agents

Every Dia-Agent contains the map for each message it receives
and forwards to other node, so that answer for any request will
come then answer will be sent to proper host(that generated the
request). Map shown above is just for understanding purpose.

--> Whenever Diameter agent receives a message(Req/Ans) it matches the End-

To-End Id.if message is Request and received End-To-End Identifier is not in
the Table then it will insert the new entry in the table and treat the
message as new message. In case of answer End-To-End Identifier shall not be
inserted in TABLE if it is not present because answer shall follow the route
followed by request(implies misrouted message).

--> if End-To-End Id exists in Table then it will check for

bit-T, if Bit-t=1 and R=1 that means message is retransmitted
so it retransmit the message to the next host.

--> if it receives the message with t=0 and r=0 and End-To-End
Id exists in Table i.e. Answer message corresponding to the
Request received earlier then it will insert the Proper hop-by-
hop Id as shown in figure to the Answer and forwards it and
deletes the entry form the Table.

--> if it receives a message with t=0 and r=1 and End-To-End

Id exists in Table then it will treat the message as duplicate
message of Looped-message and take the appropriate action that
was configured during the deployment.

Diameter AVP Structure

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.

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.

Images given Below shows their format