AAA is a StarOS service that runs on Cisco ASR 5500 and virtualized platforms. For additional platform information, refer to the appropriate System Administration Guide and/or contact your Cisco account representative.

AAA is a licensed Cisco feature. Separate feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

This feature allows the user to configure Diameter host template at Global Configuration level. Diameter host template is a table of peer servers that can be shared by different Diameter services. This template can be configured using diameter-host-template command in the Global Configuration Mode.

Note	Currently, only Gx service can be associated with the template.

When this command is configured, it allows the user to specify the name of a new or existing Diameter host template and then enters the Diameter Host Select mode. You can configure up to 256 templates on the system.

To use the template, Diameter applications must be associated with the template. For example, using diameter host-select-template command in Policy Control Configuration Mode will bind the IMS authorization service to the configured Diameter host select template. When an association is made to the template, the system selects the Diameter peer to be contacted based on rows configured in the table and the algorithm configured for selecting rows in the table. The system uses the returned host name(s) to contact the primary PCRF (and secondary if configured) and establish the call.

If no association is made to the template then the diameter peer-select command configured at the application level will be used for peer selection.

If more than one service is using the same set of peer-select commands, then it is better to define all the peer selection CLI commands in the template and associate the services to the template.

For information on the command used for configuring this feature, refer to the Command Line Interface Reference.

Diameter load balancing implementation maintains a fixed number of servers active at all times for load balancing in case of failures. This can be done by selecting a server with lower weight and adding it to the set of active servers.

For information on the commands used for configuring the load-balancing feature, refer to the Command Line Interface Reference.

This feature is introduced to prioritize the signaling traffic based on DSCP marking on the IP packets of the signaling messages. Diameter signaling messages also need to be marked with DS code points to classify/manage network traffic and provide Quality of Service (QoS).

Command dscp in the Diameter endpoint configuration mode is used to set the Differential Services Code Point (DSCP) in the IP header of the Diameter messages sent from the Diameter endpoint.

Note the difference between DSCP and the TOS values. TOS is an 8 bit field, but DSCP uses only the leading 6 bits of the TOS field.

For more information on the command used for configuring this feature, refer to the Command Line Interface Reference.

Apart from the standard and customer-specific dictionaries supported currently in the Diameter application, this feature allows the dynamic configuration of any new Diameter dictionaries at run time. This feature can be configured using diameter dynamic-dictionary command in the Global Configuration Mode. For more information on this command, refer to the Command Line Interface Reference.

Note	Up to a maximum of 10 dynamic dictionaries can be configured and loaded in to the system.

To perform this configuration, a text file should be created in ABNF format and all the required Diameter AVPs and command codes should be configured in the file. Then, the file should be saved in flash or some URL that will be accessible by the system. Now, run the dict_validate.exe authentication tool on the created dynamic dictionary text file. This authentication tool does basic syntax checks on the file and prepends the file contents with an MD5 checksum. This checksum ensures that the dictionary cannot be modified once created. Currently, only Cisco personnel can access the authentication tool dict_validate.exe .

Note	It is highly necessary that you must not create dynamic dictionary for your customization needs. Contact your Cisco account representative for any new dynamic dictionary creation request.

Now, configure a dynamic dictionary with an unique name and map it to the URL of the file to be loaded dynamically in to the system at the global configuration level.

When the names of the dynamic dictionaries and their URLs are configured, the corresponding files at the respective URLs are parsed and populated in all SessMgr and AAAmgr facilities as new dictionaries and kept available to be used when these dictionary names are configured under any Diameter application level or AAA group.

When a dynamic dictionary name is configured under an application such as IMS authorization service or in a AAA group, the corresponding dictionary (which is already loaded in SessMgrs and AAAMgrs) entry will be used.

There will be only one instance of a dynamic dictionary loaded in to a task for one dynamic dictionary name even if the same dictionary name is configured in multiple AAA groups or multiple application configurations. That is, even if the same dictionary name is configured in several applications or several AAA groups, all these applications and AAA groups will refer to the same dynamic dictionary instance.

This feature allows the user to configure Failure Handling template at Global Configuration level. The failure handling template defines the action to be taken when the Diameter application encounters a failure for example, a result-code failure, tx-expiry or response-timeout. The application will take the action given by the template. This template can be configured using failure-handling-template command in the Global Configuration Mode.

Note	A maximum of 64 templates can be configured on the system.

This command specifies the name of a new or existing failure handling template and enters the Failure Handling Template mode. Lookup is done first to identify if there is an exact match for message-type and failure-type. If not present, lookup is done for 'any' match for message and failure type.

If there are different failure handling configurations present within the template for the same message type, the action is applied as per the latest error encountered.

To use the template, Diameter applications must be associated with the template. For example, using associate failure-handling-template command in Credit Control Configuration Mode will bind the Diameter Credit Control Application (DCCA) service to the configured failure handling template. When an association is made to the template, in the event of a failure, the system takes the action as defined in the failure handling template. Both IMS Authorization (Gx) and DCCA (Gy) services can be currently associated with the template.

If the association is not made to the template then failure handling behavior configured in the application with the failure-handling command will take effect.

For information on the command used for configuring this feature, refer to the Command Line Interface Reference.

The current release supports configuring secondary AAA accounting group for the APN. This supports the RADIUS Fire-and-Forget feature in conjunction with GGSN and P-GW for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server.

This feature also supports configuring secondary AAA accounting group for the subscriber template. This supports the No-ACK RADIUS Targets feature in conjunction with PDSN and HA for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting the acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server.

Typically, the request sent to the Radius Accounting Server configured under the AAA group with the CLI radius accounting fire-and-forget configured will not expect a response from the server. If there is a need to send the request to multiple servers, the accounting algorithm first-n will be used in the AAA group.

If the server is down, the request is sent to the next server in the group. If all the servers in the group are down, then the request is deleted.

Note	Please note that on-the-fly change in the configuration is not permitted. Any change in the configuration will have effect only for the new calls.

For information on the commands used for configuring this feature, refer to the Command Line Interface Reference.

In StarOS 12.0 and later releases, the Diameter routing logic has been modified to enable routing to destination hosts that are not directly connected to the Diameter clients like GGSN, MME, PGW, and that does not have a route entry configured. Message routing to the host is based on the realm of the host.

For a given session towards a Destination Host, all the messages belonging to the session will be routed through the same peer until the peer is down. If the peer goes down, for the subsequent messages failure handling mechanism will be triggered and the message will be sent using other available peers connected to the destination host.

Note	Rate Limiting Function (RLF) is a license-controlled feature. A valid feature license must be installed prior to configuring this feature. Contact your Cisco account representative for more information.

Th RLF feature implements a generic framework that can be used by multiple interfaces and products for rate-limiting/throttling outgoing messages like Diameter messages on Gx, Gy interface towards PCRF.

When applications send messages to peers at a high rate, (e.g. when a large number of sessions goes down at the same time, accounting stop messages for all the sessions are generated at the same time) the peer may not be able to handle the messages at such high rates. To overcome this situation, the Rate Limiting Function (RLF) framework is developed so that the application sends messages at an optimal rate such that peer is capable of receiving all the messages and does not enter an overload condition.

This feature can be enabled using the CLI command rlf-template in the Global Configuration mode. The users can define the rate limiting configurations within this template. For more information on the command, see the Command Line Interface Reference.

Note	RLF template cannot be deleted if it is bound to any application (peers/endpoints).

When RLF feature is enabled, all the messages from the application are pushed to the RLF module for throttling and rate control, and depending on the message-rate configured the RLF module sends the messages to the peer. Once the rate or a threshold value is reached, the RLF module notifies the application to slow down or stop sending messages. RLF module also notifies the application when it is capable of accepting more messages to be sent to the peer. RLF module typically uses a Token Bucket Algorithm to achieve rate limiting.

Currently in the deployment of the Diameter applications ( Gx, Gy, etc.), many operators make use of "max-outstanding <number> " as a means of achieving some rate-limiting on the outgoing control traffic. With RLF in place, this is no longer required since RLF takes care of rate-limiting in all cases. If RLF is used and max-outstanding is also used, there might be undesirable results.

Note	If RLF is being used with an "diameter endpoint ", then set the max-outstanding value of the peer to be 255.

To use the template, Diameter or any other applications must be associated with the template. The RLF provides only the framework to perform the rate limiting at the configured Transactions Per Second (TPS). The applications (like Diameter) should perform the configuration specific to each application.

Diameter host name is too long for the customer network to handle and process. The host name cannot be changed as it remains constant throughout the lifecycle of client application. So, a new CLI configuration require diameter origin-host-abbreviation is introduced in the Global Configuration mode to control the truncation of Diameter origin-host name.

The Diameter origin-host-name is represented as <instance-number>-<procletname>.<name>, where the proclet name can be sessmgr, diamproxy or aaamgr.

The require diameter origin-host-abbreviation CLI command aids in reducing the length of Diameter origin-host names by using "d" instead of "diamproxy", "s" instead of "sessmgr", and "a" instead of "aaamgr". If this CLI command is configured then the Diameter origin-host-name value is constructed with the corresponding proclet name abbreviations.

For example, if a Diameter proxy is used to connect to a peer then the origin host will be 0001-diamproxy.endpoint without the CLI configuration. When the require diameter origin-host-abbreviation CLI command is enabled, the origin host will be 0001-d.endpoint.

Note	This CLI configuration is applicable only at the time of system boot. If the CLI command is configured during run time, the following warning message is displayed "Warning: System already has running services, save config and reboot to take effect".

For more information on CLI configuration, see the Command Line Interface Reference guide.