The Diameter protocol includes the Basic Agreement (Diameter Base Protocol) and a variety of application protocols. The basic protocol introduced herein provides the minimum demand for an AAA protocol, which is a functionality that the Diameter network node must be implemented, including the negotiation of the Node's ability, the reception of the Diameter message and the real-time transmission of the billing information. The application protocol fully utilizes the message transfer mechanism provided by the underlying protocol, standardizes the functionality of the relevant node and its unique message content, to implement AAA of the application service. The basic protocol can be used as a billing protocol, but in general, it needs to be used with an application.
Figure 1 is a level diagram of the protocol of DIAMETER.
DIAMETER network node
In the Diameter protocol, including a variety of types of Diameter nodes. In addition to the Diameter client and Diameter servers, there are Diameter relay, Diameter proxy, DIAMETER redirector, and DIAMETER protocol converters.
● The Diameter relay can extract information from the Diameter request message, and then determine the next hop Diameter node sent by the Diameter-based domain-based routing table. The Diameter relay only changes to past messages without changing other content in the message.
● The Diameter agent determines the next hop Diameter node sent by the Diameter routing table. In addition, the DIAMETER agent can modify the corresponding content in the message.
● The DIAMETER redirector does not process the message to the message, which uniformly processes the routing configuration of the Diameter message. When a DIAMETER node sends a request message that does not know how to route a request message, the redirector will add the routing information to the response of the request message according to its detailed routing configuration information, which is clearly Notify the next Jump Diameter node of the Diameter node.
● The DIAMETER protocol converter is mainly used to implement RADIUS and Diameter, or the protocol conversion between TACACS and DIAMETER.
All of the above DIAMETER nodes are configured to establish a one-to-one network connection, which forms a Diameter network.
Peer connection between Diameter network nodes
The network connection between the Diameter node is dynamically established on the TCP or SCTP Transfer Protocol on the Diameter node startup.
For a Diameter node, its peer node, or static configuration, or based on dynamic (utilizing SLP, DNS protocol). When the Diameter protocol is started, the Diameter node attempts to establish a socket connection with each of the peer nodes it know.
After successfully establishing a socket connection, that is, the two Diameter nodes will be able to negotiate, exchange protocol versions, supported application protocols, security modes, and other information. Capacity negotiation is interactive by Diameter's Ability Exchange Request (CER, CAPABILITIES-Exchange-Request) and Capabling Response (CEA, CAPABILITIES-EXCHANGE-ANSWER). After the ability to negotiate, the information such as the application supported by the peer should be saved in the cache so that the messages and AVPs that do not knowually unknown will prevent the peer.
The peer connection can be normalized, which requires a Diameter node actively initiates the peer connection abort request (DPR, DISCONNECT-PEER-REQUEST message, the peer receives this message, answering the peer connection "(DPA, Disconnect- After the peer-answer message, the underlying connection is stopped. For aborting conditions of peer-to-peer connections (such as network failure, one-end system failure, etc.), when discovered such a connection exception abort, you must follow the timer settings, constantly attempt to restore the establishment of a peer connection. Normal peer-to-peer connections can transmit all kinds of DIAMETER messages, when connected to idle no messaging exceeds a certain period of time, the peer connections will send a connection normal detection message (DWR / DWA, Device-WatchDog-Request / Answer). Once the DWR / DWA message is abnormal, the DIAMETER node will determine the peer connection failure, or attempt to restore the establishment connection, or convert the message path to the alternate peer connection.
Diameter's message format
The head of the DIAMETER message includes 20 bytes, as shown in Figure 2. The head 4 bytes are 8 bits of version information and 24-bit message lengths (including message head length). Subsequent 4 bytes are 8 bits of message flags and 24-bit command code.
The command code is used to represent commands corresponding to this message, request messages and corresponding answer messages share a command code.
The application ID, the trip identification, and the end-to-end identity have 4 bytes, where the application ID is used to indicate the application applicable, and the trip identification is used to determine the correspondence of the request and the response, and the end-to-end identification is mainly used for Repeat the message check.
All bytes after the message head are the specific content of the message, and the property value is tail tail one by one in the form of AVP (Attribute-Value-Pair). The format of AVP is also composed of head and data, as shown in Figure 3, the structure is: the head 4 byte is an AVP code, the next four bytes from the 8-bit AVP flag and 24-bit AVP length (including AVP header) Ministerial: AVP flag is used to notify the receiving end how to handle this property.
The byte behind the head is the data content. Data types in AVP, currently include strings, 32-bit integers, 64-bit integers, 32-bit floats, 64-bit float points, and AVP groups.
Diameter's message processing and user session
Both Diameter clients and Diameter servers can form a corresponding request message and sent to each other. It is here to consider that Diameter belongs to peer to peer, not a protocol of client / server mode as RADIUS.
To process users' access, the Diameter client exchanges a series of information exchanges with the Diameter server through the Diameter server, and such a series of information that is initiated from the Diameter Agreement is called a user in the Diameter protocol. Session (User Session).
The average AAA business can be roughly divided into two categories: a class including users of authentication and authorization, may also include billing (such as mobile phone services); another class is only a billing for users (such as current call dialing Access service). To this end, the DIAMETER fundamental protocol provides the corresponding two types of user sessions to serve the upper application.
The establishment of a user session is typically initiated by the Diameter client, and the middle can route a number of DIAMETER proxy, redirector, or protocol converters, extend to the DIAMETER server.
The end of the user session is completely determined by the DIAMETER client, but the server can also issue a suspension user session request (ASR, ABORT-Session-Request), responding to the suspended user session response in the case of the client agreed to abort the request (ASA , Abort-session-answer, then issue a user session end request, and notify the server to end the user session; otherwise the user session is still maintained. In the case where the server request is not obtained, the client can also send a user session end request from the server, such as the client itself, or user access exception, etc.. DIAMETER applications can easily achieve reliable business resource management by the user-session.
Diameter's billing
When the user is allowed to access, the DIAMETER client will generate billing information for the user according to the situation. These billing information will be encapsulated within the specific DIAMETER application proprietary AVP, which is transmitted to the Diameter server as defined by the Diameter underlying Agreement. The server will respond to billing acknowledgment (accounting-answer), indicating successful billing or rejection. The client can only clear the billing record that has been sent only when the successful billing response is received. When a billing denial indication is received, the client will suspend user access.
Diameter supports real-time billing, and the client sends a collected billing information to the server by negotiating a billing message during the first billing request / response interaction. This real-time billing ensures real-time check for user credit.
Diameter message secure transmission
Diameter clients (such as network access servers) must support IPsec, which can support TLS; and Diameter servers must support IPsec and TLS. IPSec is primarily applied to the edge of the network and traffic within the domain, while the traffic between the domain is mainly secured by TLS.
Since IPSec and TLS can only ensure the security of trip, it is a secure connection. When the message passes the Diameter agent, the agent will modify the message, so that the security information obtained by IPsec or TLS is discarded by the agent. The Diameter CMS application provides end-to-end security. End-to-end security is provided by supporting the integrity and confidentiality of AVP between two peer ends. DIAMETER CMS applications use digital signature and encryption techniques to provide the required security business.
Although it is determined by the security policy of each peer to determine the security of the end-to-end, such as when the security provided by the TLS or IPSec is sufficient, it may not require end-to-end security, but the Diameter underject protocol It is also strongly recommended that all DIAMETER implementations support end-to-end security. Such Diameter CMS applications are different from other Diameter applications, which are generally coexisting with the Diameter underlying protocol.
