Diameter Address Format

DiameterIdentity

Every diameter address (Diameter Node Address) should follow the DiameterIdentity format. DiameterIdentity is used to uniquely identify a Diameter Node.DiameteIdentity has following format

DiameterIdentity=FQDN (DiameterURI)

DiameterURI MUST follow the URI syntax given below

aaa://FQDN [Port][Transport][Protocol]  //No Transport security
              or
aaas://FQDN [Port][Transport][Protocol]  //Transport security used

FQDN = Fully Qualified Host Name
Port = :<1*digit>
Port Number of the port use for listen the incoming connection if Absent the default Diameter port 3868 is assumed.
Transport= ;transport=
Name of the transport used to listen. if Absent then default SCTP is assumed. we shall not mention the UDP when Protocol field is set to diameter.
Protocol = ;protocol=
If absent then by default diameter is assumed.

Example of Valid diameter host identities

1) aaa://host.example.com
 
on default port (3868), default transport(SCTP) and default protocol(diameter)

2)aaa://host.example.com:6666;transport=tcp;protocol=diameter
 Port=6666, Transport=tcp , Protocol=diameter

3)aaa://host.example.com:1813;transport=udp;protocol=radius



Your Comments/Suggestions and Questions are always welcome. We would try to clarify doubts with best of our knowledge. So feel free to put Questions.

Diameter Errors

There are two type of errors in diameter

1. Protocol Errors :- These are the errors that occours at protocol level (mostly at Transport layer) such as link break, Node Rebooted etc. while handling these errors, Bit-E of the diameter answer message must be set.

Example of Protocol Error

2.Application Error:- These errors occour while the diameter application processing the message it has received, such as unknown avp, invalid Avp value etc. These errors fall in the categories where diameter node has properly received the message while the protocol errors fall in categories where diameter node unable to receive the message.

Example to Application Error

Result code AVP are use to report both type of error along with some other avp to give the description of the error. The decimal values of the result code avp are divided in to following
- 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Protocol Errors)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure)

Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

Transport Failure Detection

Here today i try to explain in more general fassion, Transport failure detection depends on the deployment of the Network. I will explain this with the help of an Example.

Example

Suppose their are two nodes Node-1 and Node-2 , Peer connection is already  established between them and they are exchanging messages on that connection. Now Node-1 sends a message MESSAGE-X to Node-2 and doesnot receive the response for the MESSAGE-X. So how long Node-1 should WAIT for the Respose (say 10ms) or should Node-1  retry (say YES) or How many time NOde-1 should retry (say 2-Times) all these things are deployment specific.

After satisfying all the deployment specific conditions Node-1 would check whether there is break in network connection or not. So for this Node-1 send DWR message to Node-2 and does not receive the DWA in specific period of time then it will retry the DWR for 3 time (include in the first DWR). If DWA is not received for any the DWR then it will take this situation as the Connection Failure. and Send the Other Messages to the Secondary Peer.

If Node-1 will receive the DWA with the Error does not mean that Connection Failure, because Node-1 has received the DWA on that Network for which Node-1 was checking whether the Transport-connection was there or not. DWA with error may contain Diameter_too_Busy or any other Error message is just  to inform the Node-1 the status of Node-2.

Failover

The process of detecting the Transport connection failure with its peer and forwarding the all pending messages to the Secondary Peer Node (Alternate Node) is known as failover.

Avp Structure of DWR and DWA
Device-Watchdog-Request
<DWR> ::= < Diameter Header: 280, REQ >
                { Origin-Host }
                { Origin-Realm }
                [ Origin-State-Id ]

Device-Watchdog-Answer
<DWA> ::= < Diameter Header: 280 >
                { Result-Code }
                { Origin-Host }
                { Origin-Realm }
                [ Error-Message ]
                * [ Failed-AVP ]
                [ Original-State-Id ] = [ Origin-State-Id ]

Avp Description

Failed-AVP:- is a grouped avp provide the Debugging information in case of reject or Error during the processing such as AVP not supported etc.

Error-Message:- provides the Error in human readable form.



Original-State-Id:- is misprinted in RFC. It is basically  Origin-State-Id.

Origin-State-Id :- Origin-State-Id is used to infer the session/connection between two nodes. Whenever there is  change is state due break/disconnection in session or transport because of reboot for instance, Then rebooted node will increase the value so that other node become aware of the fact that state of peer is changed and all previous session are no more valid. Origin-State-Id is stored on non-volatile memory on all nodes.




Every time the session fails or the node is rebooted this Origin-State-Id is monotonically increased. Both nodes that are communicating stores or maps this id for mapping the Answer-Message with proper Request-Message.



Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.  

Diameter Peer Connection and Disconnection

Diameter Peer Connection

A diameter node can make connection to all other node in the realm, but at a minimum , a diameter node should have to connection per REALM Known as primary and Secondary. Typically all messages for a realm are sent to Primary Node, but in the event that invokes the failover procedures, all the pending requests are sent to the Secondary Peer.

Diameter Peer discovery process is used to discover any node to which sender(considered) node wants to communicate.

Disconnecting Peer Connection.

When a Diameter node disconnect its transport connection with other node, the Other node does not know the reason of disconnect and assumes it as connectivity problem and keep trying to reconnect.

But in some situation a node intentionally drops its connection with other node and does not want any connection request in near future without any proper reason. So a node can trigger the Disconnect-Peer-Request message which contain the Disconnect-Cause AVP.

In most of the cases Node does not wait for the Disconnect-Peer-Answer to disconnect the connection.

Disconnect-Peer-Request

The Disconnect-Peer-Request (DPR),is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.

<DPR> ::= < Diameter Header: 282, REQ >
                   { Origin-Host }
                   { Origin-Realm }
                   { Disconnect-Cause }

Disconnect-Peer-Answer

<DPA> ::= < Diameter Header: 282>
                { Result-Code }
                { Origin-Host }
                { Origin-Realm }
                [ Error-Message ]
                * [ Failed-AVP ]

Disconnect-Cause AVP

Disconnect-Cause AVP is Enumerated having following values
REBOOTING 0
A scheduled reboot is imminent.
BUSY 1
The peer’s internal resources are constrained, and it has determined that the transport connection needs to be closed.
DO_NOT_WANT_TO_TALK_TO_YOU 2
The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future.



Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

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

PREVIOUS                                                                                                                             NEXT

Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

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

     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 mis-routed 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(i.e. Route is looped/circular) and take the appropriate action that was configured during the deployment.

(PREVIOUS)                                                     (NEXT)


Your Comments /Suggestions and Questions are always welcome.We would try to clarify doubts with best of our knowledge. So feel free to put Questions.