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.
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
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.