Session initiation

Like most client-server communication models, a Diameter session starts by issuing a request message from the client to the server. In Diameter context, a Diameter client will send an auth-request message containing a unique Session-Id to a Diameter server (or a Diameter proxy if message forwarding is required). Note that the AVPs to be used for authentication and authorization are application-specific, and that they are not defined in the base protocol. After accepting the auth-request message, the Diameter server may include an Authorization-Lifetime AVP in the response messaging. This AVP is used to indicate the amount of time in seconds that the Diameter client needs to be re-authorized. After the timeout and acceptable Auth-Grace-Period have passed, the Diameter server will remove the session from its session list and release all resources allocated for the session.

The session

During the session, a Diameter server might initiate a re-authentication or re-authorization request. With prepaid service, this type of request is used to check whether the user is still engaging the service, and if not, the server removes the session to avoid further charging. Also, the Origin-State-Id AVP is used for the inference of exceptional session closure. The sender of a request will include this AVP, and because it is required for the value of this AVP to be monotonically increased, the receiver of the request can easily infer that the previous session was closed, either because the access device was abnormally shutdown or because of some other exceptional situation. The request receiver can then remove the session from its list, free the resources, and possibly notify its upper stream Diameter servers if it acts as a proxy server.

Session termination

Session termination messages are only used in the context of authentication and authorization, and only when the session state was maintained. For accounting services, an accounting stop message is used instead. A session termination message can be initiated by either the Diameter client or the Diameter server. When a session is deemed to be closed, the Diameter client sends a Session-Termination-Request message to the Diameter server. The Termination-Clause AVP is included in this request telling the Diameter server the reason why the session should be closed. Alternately, if the Diameter server detects that the session should be closed -- perhaps because the user runs out of credit or just for administrative purposes -- the Diameter server sends an Abort-Session-Request message to the Diameter client. However, depending upon different policy or usage scenarios, the Diameter client might decide not to close the session even when receiving a session termination message from the server, and let the user keep using its service.

AAA in Diameter

Authentication and Authorization

As we mentioned, the Diameter protocol isn't bound to a specific application running on top of it. It focuses on general message exchanging features. Because authentication and authorization mechanisms vary among applications, the Diameter base protocol doesn't define command codes and AVPs specific to authentication and authorization. It is the responsibility of Diameter applications to define their own messages and corresponding attributes based on the application's characteristics. For example, the AA-Request message is used to carry authentication and authorization information in the NAS application, while in the SIP application (see Resources) the message is called User-Authorization-Request.

Accounting

Unlike authentication and authorization, the behavior and message to be exchanged for accounting is clearly defined. Accounting in Diameter essentially follows a server directed model, which means the device that generates accounting records follows the direction of an authorization server. Based on the user profile or any business condition, a Diameter server informs the corresponding Diameter client as to what behavior is expected, such as how often the accounting record should be sent from client to server, or if the accounting record should be generated continuously within an accounting session. Generally speaking, depending on the service to be provided, there are two kinds of accounting records: For one-time invocation-based services, the EVENT_RECORD is used. However, if the service will be provided in a measurable period, the accounting record types START_RECORD, INTERIM_RECORD, and STOP_RECORD could be used to mark the start, update, and end of a session. To prevent duplicated accounting records, each accounting message is associated with a Session-Id AVP along with an Accounting-Record-Number AVP. As this combination can uniquely identify an accounting record, a Diameter node acting as a Diameter agent can use this information to detect duplicated accounting messages being sent to the Diameter server, thereby avoiding unnecessary processing for the Diameter server. This situation might come from temporary network problems or client shutdowns. Also, it is required that the Diameter client keep a local cache of outgoing accounting messages until an acknowledgement message arrives.

Error handling

Errors in the Diameter fall into two categories: protocol errors and application errors. Protocol errors refer to something being wrong with the underlying protocol used to carry Diameter messages, perhaps incorrect routing information or temporary network failure. Applications errors, on the other hand, result from the failure of the Diameter protocol itself, and there are plenty of sources that will cause application errors. For example, when a mandatory AVP is missing in a particular Diameter command, a DIAMETER_MISSING_AVP error code is returned. Every response message in Diameter will carry a Result-Code AVP, and the receiver of a response message can check this AVP to see if the previous message was successfully processed. To support early connection failure detection, the Diameter protocol defined a Device-Watchdog-Request message. When two connected Diameter nodes don't exchange messages for a certain length of time, this message is sent from either of these nodes to detect possible network problems. The discussion of algorithms to detect transport failures is beyond the scope of this article, but if you are interested in this topic, you can refer to the AAA Transport Profile (see Resources) for more information. The Diameter protocol shares the same semantics of error code definition as the HTTP protocol. The return status of messages can be easily identified by checking the first digit of the return code: 1. 1xxx: means the request can't be satisfied and additional information is required for the service to be granted. 2. 2xxx: means the request was processed successfully. 3. 3xxx: means there was a protocol error when transmitting a Diameter message. Generally, a Diameter proxy should try to fix this problem by either routing the message to another Diameter server, or by keeping the message in a local cache and sending it again later. 4. 4xxx: means the requested message cannot be satisfied at the moment, but it might work in the future. An example is a server that temporarily lacks physical storage space to handle any incoming requests. 5. 5xxx: means there was an application error when the server was processing the request message. The sender should not try to send the same message again. Instead, the sender will have to determine the cause of the application error by checking the error code, and then fix the problem. Besides the Return-Code AVP, the message sender can also check other AVPs that carry additional information for error handling. The Error-Message AVP carries human readable error messages and can be used to determine the actual cause. The Error-Reporting-Host AVP contains the identity of the host generating the Result-Code. This AVP is very helpful for troubleshooting to spot the location of a problem. The Failed-AVP contains the group of AVPs that caused the exception. After an error has been detected, the sending node forwards all pending messages to an alternative Diameter node. This process is called FailOver. A pending message is a message that has been sent, but hasn't received its corresponding answer yet. It is required for each Diameter node to keep a local copy of its outgoing messages. The Hop-to-Hop Identification within each message is used to reference out-going messages for each target peer. However, this process may cause a Diameter node to receive an identical message more than one time. As a result, the Diameter node must use the combination of End-to-End Identification message header and Original-Host AVP to uniquely identify a message coming from a specific Diameter node. Table 2 summarizes some significant changes between the Diameter and RADIUS protocols:

Table 2. Comparison of Diameter and RADIUS protocols

In summary

In this article, we have gone through the Diameter base protocol from many aspects, including the role and responsibility of different Diameter nodes, the anatomy of a Diameter message, and how messages are sent and received. You have also been given a brief overview of how AAA and Error Handling are achieved in Diameter. After reading this article, you should have a sense of how the Diameter protocol works and have the base knowledge for exploring it in more detail. In addition to SIP, Diameter is the other core protocol used in the IP Multimedia Subsystem (IMS) architecture, both in the service plane and the control plane. IMS defines a set of reference points between different IMS entities and some of them use Diameter as the underlying protocol to exchange subscription-, presence-, and billing-related messages. For example, the Sh reference point in IMS defined a set of Diameter messages for subscription and notification purposes. As IMS continues to evolve, we believe there will be more Diameter applications to come, as well as Diameter-related implementations.

---