About Diameter Testing
Diameter is a peer-to-peer protocol that provides basic services such as capability negotiation, connection and user session management, accounting, and error notification, and also provides a framework that can be extended to support various applications. The Diameter Base protocol can be used alone to provide accounting services but an application is required for authentication or authorization services.
The following terminology is used in this documentation when discussing Diameter:
-
Peer — A device that supports Base Diameter and may support one or more Diameter applications.
-
Realm — An administrative domain that maintains the mobile subscriber's account (Home Realm) or that is currently servicing an MN in a foreign network (Local Realm). The Home Realm and Local Realm are the same domain when the MN is in its home network.
-
Client — A peer that requests Diameter services. A client may control MN network access or provide other services to an MN.
-
Server — A peer that provides Diameter services to a client. A Diameter server typically supports one or more Diameter applications.
-
Network Access Server (NAS)— A client on the perimeter of the Local Realm's network that controls MN access to that network, such as an FA, or a client in the Home Realm that controls access to the home network, such as a GGSN or HA.
-
AAA Server — A server that provides Authentication, Authorization, and Accounting services for one or more realms.
-
DCCA Server — A server that provides Diameter Credit Control Application services, including rating and credit control for services requested by an MN.
-
Attribute-Value Pair (AVP) — The combination of a standard Base or application-specific attribute and its associated value.
A Diameter message is comprised of a header and one or more AVPs that provide information useful to the Base protocol or a Diameter application. In addition to routing, protocol version, and the message length, the header identifies the type of message (command) and the way it should be handled (command flags) as well as the Diameter application, if any. Mandatory AVPs are normally included automatically in the messages generated during a test and are provisioned either by test case parameter settings or with values generated during the test. Optional AVPs can be configured using the standard AVPs included in the Test Library or with user-defined attribute templates.
The following sections describe the Diameter messages and applications supported, and when they are used in testing:
Connection Management
TCP is always used as the transport protocol for Diameter. When the test begins, the client establishes a TCP connection with the server (see Using TCP for the messages that set up and teardown TCP connections).
After the TCP connection has been established, the client initiates a Capabilities Exchange with the server. A Capabilities Exchange allows both peers to discover the other peer's identity, security mechanisms, supported protocol version, and supported applications and must be completed before any other Diameter messages are exchanged. If the server does not support any of the applications or security mechanisms requested by the client in the CER message or if it does not recognize the client, it returns the appropriate error indication in the CEA message and then closes the TCP connection.
Either peer can test the TCP connection during times of inactivity by sending a DWR message. When a peer receives a DWR, it responds with a DWA message. The watchdog timer (Tw) is reset whenever a peer receives any Diameter message, and a DWR is sent when the timer expires.
If a peer determines that it cannot continue Diameter operations or that it will not need to send a message to a peer in the foreseeable future — when the test is stopping, for example — it notifies the other peer that it will be closing the TCP connection with a DPR message. The receiving peer responds with a DPA message and the DPA sender initiates the teardown of the TCP connection. If a client receives a DPR when it is waiting for an answer to another Diameter message, it may include an error indication in the DPA to notify the server that it is expecting a response and the server will delay the disconnect if it is able to process any pending requests.
Test Support
-
The messages described are supported in all Diameter testing.
-
Watchdog timers can be configured on both the client and server nodes.
-
Peer and capability validation are not supported.
MN Session Management
From the server's perspective, an MN session can be established and maintained for stateful accounting or when the server supports a stateful application such as the NAS or Credit Control application. It is also possible for a server to host multiple accounting sessions for an MN.
An authentication or authorization application may grant an MN access to a network or service for a finite, possibly extendable, amount of time. Although Diameter Base does not support user authentication, it does provide a mechanism to prompt a client to re-authenticate or re-authorize an MN prior to the end of the session lifetime. The server sends an RAR message to the client, which responds with an RAA message and then follows up with an application-specific authentication or authorization message.
A server may determine that a client should stop providing services to an MN for reasons not anticipated when the MN's session was established — for credit or administrative reasons, for example. In this case, the server notifies the client with an ASR message. The client responds with an ASA message and proceeds to terminate the MN's session.
A client notifies a server that an MN's session should be terminated with an STR message. This can happen naturally when an MN reaches the end of a finite session lifetime or when it becomes idle. A server can trigger a session termination with an ASR as explained above. A client must also terminate the MN's session if it was unable to service the MN after it was successfully authenticated. When the server has cleared the MN's session, it responds with an STA message.
Test Support
-
The messages described are supported in all Diameter testing.
-
A server node will send ASRs for any active sessions when the test is stopping.
Accounting
Diameter Base provides accounting transaction support without the need of an application. This basic accounting capability can be extended by an application with the addition of AVPs, however. The client always initiates an accounting transaction with an ACR message and the server always responds with an ACA message.
Accounting records are correlated and associated with an MN's session with a Session-Id AVP and a User-Name AVP (when a user name is available). The client notifies the server that it wishes to open an accounting session for an MN by sending an ACR with an Accounting-Record-Type value of START_RECORD.
The client may send periodic INTERIM_RECORD ACRs as the MN's session progresses, and it notifies the server that it is terminating the accounting session with a STOP_RECORD ACR.
Diameter accounting supports two state machines:
-
Stateless — In stateless mode, the server will accept valid ACRs in any order and at any time. The server is not obligated by Diameter to process these records in real time, although some error checking and correlation may be performed. The client has no obligation to disconnect or deny service to the MN due to failed accounting transactions in stateless mode.
-
Stateful — In stateful mode, the server establishes an accounting session upon receipt of a valid START_RECORD ACR and it correlates and processes the records in real time. ACRs must be received in the correct order in this mode; an INTERIM_RECORD for an accounting session will be rejected if it is received after the STOP_RECORD for the session, for example. The server also maintains a timer associated with the session and can initiate a session abort or reject subsequent requests if the timer expires before the server receives additional ACRs for the session. The client is obligated to disconnect or deny service to an MN if it cannot establish an accounting session with the server or if the accounting session fails due to a transport failure or other unrecoverable error.
Test Support
-
The AAA server node supports multiple accounting sessions for an MN.
-
In stateful accounting mode, the AAA server node releases the MN's Session ID when the session timer expires, and will respond with an Unknown Session ID error if any ACRs are subsequently received for that session.
-
A Diameter client will recognize and return an Acct-Multi-Session-Id AVP if received from a server but will not recognize an Accounting-Realtime-Required AVP.
-
The timing of INTERIM_RECORD ACRs can be specified by the test case settings or by the server.
Network Access Server Application
The NAS application (NASREQ) extends Diameter Base with authentication and authorization services, additional accounting AVPs, and it defines two application-specific messages.
When an MN attempts to join a network or establish a session, the NAS sends an AAR message to the local or home AAA server and the AAA server responds with an AAA message. If the MN is successfully authenticated or authorized, the server establishes a session for the MN. When accounting is used, the NAS can initiate an accounting transaction upon receipt of a positive AAA message.
If the server allows a session's lifetime to be extended through a re-authentication or re-authorization, it can prompt the NAS to execute the procedure with an RAR message. Since the NAS is also aware of the lifetime, it should pro-actively re-authenticate the MN and send an AAR before the lifetime expires. If a NAS receives an RAR it must respond with an RAA to keep the session alive before sending an AAR.
When the NAS realizes that the MN's Diameter session should be terminated, either due to the MN becoming idle or due to an error, it initiates a Diameter session termination with the server.
Test Cases
Test Support
-
The NAS and AAA Server nodes cannot act as relay, proxy, redirect, or RADIUS-Diameter translation agents. Inclusion of a physical proxy device in the test is supported.
-
AAA server SUTs are discretely defined in the AAA Server Nodal test case; dynamic discovery is not supported.
-
A AAA Server node will respond to any Diameter peer regardless of identity. The node will, however, reject TCP connections from additional peers once the maximum number of peers has been reached.
-
Test using authentication transactions, accounting transactions, or both.
-
Transmission-level security is supported with IPSec and the use of IPSec is optional. End-to-end security, ensuring AVP integrity and confidentiality, is not supported.
-
CHAP and PAP authentication methods are supported.
-
Single-transaction authentication is supported; multiple-transaction authentication is not supported.
-
Re-authentication is supported by both the NAS node and the AAA server node.
-
The Acct-Link-Count AVP is ignored.
See the previous sections for more information regarding Diameter Base support.
Credit Control Application
The Credit Control application adds prepaid credit control and monitoring services to Diameter Base with two application-specific messages, the Credit-Control-Request (CCR) and the Credit-Control-Answer (CCA), and application-specific AVPs. The Credit Control process checks an MN's account balance when prepaid services are requested, can reserve credit when a service is accessed, deducts credit from the MN's account based on service usage, and can refund any unused reserved credit to the account. A DCCA Server controls and maintains the credit accounts. A server can either provide session-based credit control or direct-debiting credit control. DCCA clients request credit authorization based on the service requested by an MN and can monitor the user's activity and report the actual credit consumed to the server depending on the mode used.
Session-Based Credit Control
The diagram to the right shows session-based transactions between a NAS and a DCCA Server. Activity external to the Credit Control application, shown in gray, is included to place the credit transactions within the overall context of an MN session in an access-controlled network.
When an MN attempts to access a credit service, the Diameter client — typically a NAS or an application server — sends an initial CCR to a DCCA Server with an indication of the type of service requested by the MN. If the MN's account balance is sufficient for the request, the server establishes a credit session and reserves an amount of credit (quota) from the MN's account consisting of time or volume (byte) units. The server responds to the request with a CCA with an indication that either the account had sufficient credit to cover the request, in which case an allocation of credit units is included (granted), or that the access cannot be granted due to insufficient credit or other reasons. The server may also include the Validity-Time AVP to indicate to the client that the grant is only valid for a span of time.
Following a successful credit authorization, the client allows the MN to access the service and monitors usage of the service. Clients report the actual credit consumed, based on user activity, to the server when the service has been delivered or completed and may provide interim reports while the service is in use. If the MN consumption approaches the quota limit or if the validity time is close to expiration, the client requests an additional credit grant with an update CCR. When the service has completed, the server returns any unused credit to the MN's quota.
In any of the CCA responses, the server may include the Final-Unit-Indication AVP to notify the client that the credit granted represents the final units remaining in the account. If the MN consumes those units, the client is obligated to take the action directed by the server in the Final-Unit-Action AVP: terminate the MN's session, redirect the MN to a location where the user can replenish the prepaid account or access other services, or restrict access to the prepaid service.
Direct-Debiting Credit Control
In contrast to the session-based mode, direct-debiting consists of a single authorization transaction between the client and server. The client requests a credit authorization for a specific service with an event CCR, indicating a one-time event. Assuming that the MN's account is sufficient to satisfy the request, the server debits the account accordingly and responds with a CCA including the credit grant. Neither the server nor the client maintain a session state and the MN is charged based on the service requested rather than the actual time or bandwidth consumed. The purchase of a ring-tone, for example, could be accomplished using the direct-debiting mode.
Controlling Credit for Multiple Services
Since an MN/MS can access multiple services simultaneously, the Credit Control application provides the Multiple-Services-Credit-Control (MSCC) AVP to independently control credit for prepaid services that fall within a Rating Group. A Rating Group can include one service or group of services that share the same cost and rating type — HTTP and email services could be defined in one Rating Group, for example, while multimedia services are defined in another. The server can choose whether to grant credit for individual services within the same Rating Group or grant credit for the entire Rating Group. In the latter case, all services within a group can draw from the same credit pool.
Test Cases
Test Support
-
A DCCA Server node can act as both a proxy and a Credit Control server depending on the Node Configuration. When proxy support is configured, the server includes the Route-Record AVP in responses to a client as if the response was relayed by a proxy.
-
DCCA Server SUTs are discretely defined in the DCCA Server Nodal test case; dynamic discovery is not supported. You can define a single SUT, a primary SUT with a secondary SUT that will be used as a failover server, or up to 10 SUTs that will be used in round-robin mode.
-
A DCCA Server node will respond to any Diameter peer regardless of identity. The node will, however, reject TCP connections from additional peers once the maximum number of peers has been reached.
-
Transmission-level security is supported with IPSec and the use of IPSec is optional. End-to-end security, ensuring AVP integrity and confidentiality, is not supported.
-
Ten MSCC AVPs are supported by both the DCCA Server and Client nodes.
-
The type and amount of credit units granted by a DCCA Server node and the MN's account balance are configurable at the MSCC level. The server node will attempt to grant a fixed number of units for each request received. The server node does not perform rating. Service-specific rating input AVPs (Service-Parameter-Info or Service-Context-Id) are accepted but the rating information that they may contain is ignored. Although no mechanism is provided to top-up or replenish an account, you can choose to reset the balance to the starting amount after session termination. When a validity time is defined, the server node will send an RAR when the timer expires. The Re-Authorization Test option forced the server node to send RARs at a specific time and rate, and the server node can accept or reject the resulting CCRs.
-
Credit usage reported by Client nodes is also configurable by type and amount, and the nodes will report the defined number of used units with each update CCR. Since user interaction is not possible, the Redirect and Restrict Access actions are accepted but their functionality is not supported. Recognition of the Validity-Time AVP is optional and Client nodes can either ignore the AVP or request an additional credit allocation when the time expires.
-
The Client node cannot act as a relay agent.
See the previous sections for more information regarding Diameter Base support.
Failures and Failover
The Tx timer, which controls how long a client will wait for a CCA response, is supported by the Client node in both dedicated SUT and round-robin modes. The Credit-Control-Failure-Handling (CCFH) AVP is supported in dedicated SUT mode, and the CC-Session-Failover (CCSF) AVP is supported when a dedicated SUT configuration supports secondary devices.
If the Client node detects a communication failure or receives a temporary error code in response to a request and CCSF is supported, the node will attempt to move the CC session to a secondary server when the CCFH AVP permits. The CCFH value directs the Client node to either allow an MN session to continue without a CC session, terminate the MN's session, or try a secondary server and then terminate the MN session if a CC session cannot be established on the secondary server. You can define the default behavior that will be employed in both cases if the applicable AVP is not received. Failback is not supported — if a CC session has been moved from a primary server to a secondary server due to a failure, the primary server will not be contacted in the event of a failure on the secondary server.
Diameter Base provides the watchdog mechanism (DWR/DWA) to detect transport layer failures. A failure is indicated when the watchdog timer (Tw) expires twice and if failover is supported, it is triggered at that time.
The CCFH value and the state of Tx determine how a particular CC session is handled on failover. Tx is reset when the Client node receives a CCA in response to a CCR, and individual timers are maintained for each transaction. The example message flow illustrates the following scenarios, assuming that the CCSF AVP supports failover and the CCFH AVP requires termination on failure:
-
Session 1: A Credit Control session is established on the primary server with the exchange of an initial CCR and a CCA. When the Client node sends an update CCR for the session, no response is received. Since Tw1 has not expired, the Client node is not yet aware of the failure. Tx1 expires, and the Client node tears down the session since a NAS would be obligated to deny service by the CCFH AVP.
-
Session 2: Again, the session is successfully established before the failure. In this case, the Client node is in the process of detecting the failure when an update CCR is sent. Tx2 has not expired by the time the node institutes the failover process and the CCR is sent to the secondary server. As long as Tx2 does not expire before the CCA is received, the session will continue on the secondary server.
-
Sessions 3 and 4: In these scenarios, the Client node is attempting to establish sessions with a non-responsive server. Tx3 expires before the Client node detects the failure, and the node abandons the attempt. Tx4 has not expired by the time the failover occurs and the initial CCR is sent to the secondary server.
The DCCA Server Node test case can emulate a primary and secondary server in order to test a client's failure processing. You can specify the CCFH value sent to clients and introduce failures for all CC sessions serviced by the primary node at a time of your choosing. The secondary node will be ready to accept sessions as the client reacts to session failures.