Diameter User Guide

USER DESCRIPTION

1/1553-CRA 119 0019/2 Uen B

Copyright

© Copyright Ericsson AB 2007-2008. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written
permission of the copyright owner.

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Contents

Contents

1 Overview 1
1.1 Key Concepts 2
1.2 Prerequisites 3

2 Configuration Management in the Diameter Stack 5

2.1 General 5
2.2 Configuring the Diameter Stack 5
2.3 Configuring Security Management 6
2.4 Configuring Common Stack Data 7
2.5 Configuring the Own Node 8
2.6 Configuring a Peer Node and Connections 8
2.7 Configuring the Realm Routing Table 10
2.8 Configuring Vendors and Attribute Value Pairs 11
2.9 Configuring NetRed using Local VIP Address 12

3 Diameter Application Installation Preparation 15

3.1 Configuration Activities 15

4 Logging 17

1/1553-CRA 119 0019/2 Uen B | 2008-12-24

Diameter User Guide

1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Overview

1 Overview

This User Guide provides an overview of configuration activities for the

Diameter Stack. Managed Object (MO) information is also included.

An overview of the following Diameter configurations are described in this

document:

• Configuring Security Management

The security management of the Diameter Stack is based on the possibility

of having several administrators and access groups to which these
administrators can belong to. They provide manage, read and write
permissions within the Diameter Stack subtree.

• Configuring Common Stack Data

The configuration of common data for the Diameter stack consists of

the DIA-CFG-Configuration managed object, which is created during
installation. Once the application has been successfully installed and
SCTP is used as transport layer, the DIA-CFG-Configuration object must
be modified.

• Configuring Own Node

Administrators have to configure their Own Node before bringing the

application into service. The configuration of the node from the point of
view of the Diameter Stack consists of the following managed object:
DIA-CFG-OwnNodeConfig.

• Configuring a Peer Node

Other nodes in the network have to be configured for each specific

Diameter application, to make it possible for the application to set up
communication with those nodes. DIA-CFG-NeighbourNode objects have
to be created for each Peer Node in the network.

If more than one connection to a specific Peer Node is desired, a

DIA-CFG-Conn object has to be created for each peer connection.
One DIA-CFG-Conn object is always created by default when the
DIA-CFG-NeighbourNode object is created.

The configuration of the Peer Node from the point of view of

the Diameter Stack consists of the following managed objects:
DIA-CFG-NeighbourNode and DIA-CFG-Conn.

• Configuring the Realm Routing Table

The different Realm Routing Table entries determine the routing behavior
of the node. Depending on the realm, the request type, and the application,

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 1

Diameter User Guide

the entry must be configured so that the node knows exactly what to
do with every request. There are two types of Realm Routing Tables:
one for routing incoming requests from the Peer Nodes and another
for routing outgoing requests toward Peer Nodes. The Diameter Stack
must be configured with information about other nodes in the network
and information about how to behave when routing messages. This
information is contained in the following managed objects: DIA-CFG-Drt,
DIA-CFG-AuthReqContainer, DIA-CFG-AccReqContainer and
DIA-CFG-AppRouting.

• Configuring Vendors and Attribute Value Pairs (AVP)

The Attribute-Value Pairs (AVPs) that the node is able to recognize must
be configured. This configuring consists of the following managed objects:
DIA-CFG-Vendor and DIA-CFG-AvpDef.

• Configuring NetRed using Local VIP Address

To make a TSP NetRed system to use Local VIP addresses the

following managed objects must be configured: DIA-CFG-OwnNode
-LocalVIPNetRed, DIA-CFG-NeighbourNode-LocalVIPNetRed and
DIA-CFG-Conn-LocalVIPNetRed.

• Application Installation preparation

Parameters that are necessary to be defined prior to an application

installation.

• Logging

Some events in the Diameter stack are logged using the TSP AppLog utility.

Note: When configuration data is changed, there is a latency of up to 10

seconds before the change has impact on traffic.

1.1 Key Concepts

1.1.1 Stack ID
The Stack ID is an identifier of an instance of Diameter base configuration.
A group of applications can use the same Stack ID if they want to share the
configuration. A Stack ID has a one to one relation with Own Nodes. The Stack
ID is defined by the applications and configured in the system at installation
time.

1.1.2 Stack Instance

The Stack Instance is a term used in this document and is a synonym with
Stack ID.

2 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Overview

1.1.3 Stack Instance User

The Stack Instance User is a concept used throughout the configuration

documents to identify an application or a group of applications using the same
Stack Instance as defined by one Stack ID.

1.1.4 Diameter Application

A Diameter Application is an application that extends the base protocol provided
by TSP. A Diameter Application is associated with only one Stack Instance.
Several Applications can share the same Stack Instance.

1.1.5 Multiple Connections

Between two Diameter peers it is possible to set up either a single connection
or setting up multiple connections. By the usage of multiple connections the
processor load is spread (a new process is created for each established
connection and distributed with a Round-Robin algorithm) and the throughput
is increased.

1.2 Prerequisites
Before the Diameter node can be configured, the Diameter application needs to
be installed together with TSP.

For information about Application installation, see Section 3 on page 15.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 3

Diameter User Guide

4 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Configuration Management in the Diameter Stack

2 Configuration Management in the Diameter

Stack

2.1 General

2.1.1 Common Attributes to All MOs

All the objects in the database that could be managed by LDAP inherit from
JIM_ManagedObject, that includes the general attributes for any object in the
LDAP tree, such as the objectClass and the attributes related to the object
permissions of every object instance.

All MOs include a set of attributes to set the name of the MO class in the LDAP
tree, but also to set the permissions of every MO instance. The owner, group,
and permissions attributes are similar to the corresponding attributes of a
Unix file system.

2.1.2 DIA-CFG-Application MO

This MO identifies the TSP Diameter Stack. It constitutes a container to all MOs
defined for the TSP Diameter Stack and is derived from JIM_Application,
whose only purposes is to serve as a container for the objects belonging to
that application.

Only one instance of this MO exists, and it is created at installation time by the
TSP Diameter Stack.

There are no management activities to be performed in this MO.

2.1.3 DIA-CFG-StackContainer MO
This MO is a container for Node and Routing data related to one Stack Instance
and is automatically created at the Diameter Installation.

2.2 Configuring the Diameter Stack

2.2.1 Initial Configuration

When the Diameter Stack is successfully installed, the following main steps
need to be performed to configure the Diameter Stack:

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 5

Diameter User Guide

• Modify Attributes to Common Stack Data (if SCTP is used), see Configuring
Diameter.

• Initial Configuration of the Own Node, see Configuring Diameter.

• Add a Peer Node, see Configuring Diameter.

• Modify Attributes to a Peer Node, see Configuring Diameter.

• Add a Connection (if multiple connection is used), see Configuring

Diameter.

• Add a Realm Routing Table, see Configuring Diameter.

• Modify Attributes to a Realm Routing Table, see Configuring Diameter.

2.2.2 Delete Configuration

When the Diameter Stack is not used, the following main steps need to be
performed to delete the configuration of the Diameter Stack:

• Delete a Realm Routing Table, see Configuring Diameter.

• Delete a Connection, see Configuring Diameter.

• Delete a Peer Node, see Configuring Diameter.

2.3 Configuring Security Management

2.3.1 Configuration Activities

The following configuration activities are included in the Security Management
Configuration:

• Add an AccessGroup, see Configuring Diameter.

• Modify an AccessGroup, see Configuring Diameter.

• Delete an AccessGroup, see Configuring Diameter.

• Add an Administrator, see Configuring Diameter.

• Modify Administrator Attributes, see Configuring Diameter.

• Delete an Administrator, see Configuring Diameter.

2.3.2 Managed Objects

Note: An AccessGroup has to be created first, then an Administrator can
be created.

6 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Configuration Management in the Diameter Stack

2.3.2.1 DIA-ADM-SecurityContainer

This MO is a container for Administrators and AccessGroup Data. This MO is

automatically created at the Diameter Installation.

2.3.2.2 DIA-ADM-AccessGroup MO

This MO is derived from JIM_AccessGroup class, so all JIM_AccessGroup

attributes are also part of the DIA-ADM-AccessGroup MO. It represents the
default access group for the Diameter Stack, that gives privileges to manage
all MOs of the TSP Diameter Stack.

At installation time of the TSP Diameter Stack, a default access group

diameteradmin is created. This activity is automatically performed.

2.3.2.3 DIA-ADM-Administrator MO

This MO is derived from the JIM_Administrators class so all its attributes

are also part of Application-Administrator objects. It represents the default
administrator for the Diameter Stack, who has privileges to manage all MOs
of the TSP Diameter Stack.

Before an administrator can issue any requests to read, write, create or delete
objects, it must be authenticated by providing an administrator DN and a
password. Each administrator is associated with at least one access group.

At installation time of the TSP Diameter Stack, a default administrator

diameteradmin is created, with the password password. This activity is
automatically performed.

2.4 Configuring Common Stack Data

2.4.1 Configuration Activities

The following configuration activity is included in the Common Stack Data
configuration:

• Modify Attributes to Common Stack Data, see Configuring Diameter.

2.4.2 Managed Objects

2.4.2.1 DIA_CFG_Configuration

This MO is used to define the common data for the Diameter Stack.

Once the Diameter has been successfully installed, the DIA-CFG-Configuration

object has to be configured if SCTP is used as transport layer.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 7

Diameter User Guide

2.5 Configuring the Own Node

2.5.1 Configuration Activities

The following configuration activities are included in the Own Node

Configuration:

• Initial Configuration of the Own Node, see Configuring Diameter.

• Modify Attributes to the Own Node, see Configuring Diameter.

• Disable and Enable the Own Node, see Configuring Diameter.

2.5.2 Managed Objects

2.5.2.1 DIA-CFG-OwnNodeConfig MO

This MO is used to define the configuration of the Own Diameter Node.

Each instance of this MO defines a particular Diameter Stack instance user of

the TSP Diameter Stack. There is only one instance of this MO per Diameter
Stack instance user. Each instance is using the Diameter Stack identity
(stackId) of their corresponding Diameter application as the key.

Once the application has been successfully installed, the DIA-CFG-OwnNode

Config object created for the application has to be configured.

The deletion of a particular DIA-CFG-OwnNodeConfig object automatically

deletes all objects related to that Diameter Stack instance. All Peer Nodes
and the Realm Routing Table (RRT) associated to that stack instance are
deleted. The corresponding stack ID is deleted from the stackIds list of both
DIA-CFG-Vendor and DIA-CFG-AVPDef objects if it exists in these lists.
Those objects are not deleted themselves, because they may be in use by
other Diameter applications.

This is only to be used at uninstallation of a Diameter Stack instance. A new

Own Node can only be created through reinstallation of the Application.

2.6 Configuring a Peer Node and Connections

2.6.1 Configuration Activities

The following configuration activities are included in the Peer Node
Configuration:

• Add a Peer Node, see Configuring Diameter.

• Modify Attributes to a Peer Node, see Configuring Diameter.

8 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Configuration Management in the Diameter Stack

• Disable and Enable a Peer Node, see Configuring Diameter.

• Delete a Peer Node, see Configuring Diameter.

• Add a Connection, see Configuring Diameter.

• Disable and Enable a Connection, see Configuring Diameter.

• Delete a Connection, see Configuring Diameter.

2.6.2 Managed Objects

2.6.2.1 DIA-CFG-PeerNodeContainer

This MO is a container for Peer Nodes related to one Stack Instance. This MO
is automatically created at the Diameter Installation.

2.6.2.2 DIA-CFG-NeighbourNode MO

This MO is used to define Diameter Nodes to which the Own Node has a direct
transport connection/connections.

Peer Nodes are objects used to specify Peer Nodes known to the Applications
using the Diameter Stack. The list of all Peer Nodes is what is known in the
Diameter RFC as Peer Table.

Every stack instance user, identified by a stackId, has its own set
of DIA-CFG-NeighbourNode objects. For example, there is a set of
DIA-CFG-NeighbourNode objects for the Home Subscriber Server (HSS)
Application, another one for Call Session Control Function (CSCF) Application,
if these are installed and defined as different stack instance users.

Prior to the creation of a new DIA-CFG-NeighbourNode object, the stackId

must be defined during installation, otherwise there is an error and the create
operation does not take place.

All hosts in the RRT must be defined as Peer Nodes in the MO. A
DIA-CFG-NeighbourNode to be deleted must be previously deleted from
the RRT for the same stack instance. This means that the reference to that
DIA-CFG-NeighbourNode is no longer kept by the DIA-CFG-AppRouting
object, and that the RRT no longer offers routing toward that Peer Node.

2.6.2.3 DIA-CFG-Conn MO

This MO is used to define a specific connection for a Diameter node. The first
connection object is created by default when the Peer Node object is created.
For each new desired connection a new connection object must be created.

Every Peer Node, identified by nodeId, has its own set of DIA-CFG-Conn
objects.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 9

Diameter User Guide

2.7 Configuring the Realm Routing Table

2.7.1 Configuration Activities

The following configuration activities are included in the Realm Routing Table
Configuration:

• Add a Realm Routing Table, see Configuring Diameter.

• Modify Attributes to a Realm Routing Table, see Configuring Diameter.

• Delete a Realm Routing Table, see Configuring Diameter.

2.7.2 Managed Objects

2.7.2.1 DIA-CFG-RoutingContainer

This MO is a container for Routing Tables related to one Stack Instance. This
MO is automatically created at the Diameter Installation.

2.7.2.2 DIA-CFG-Drt MO

This MO represents an entry in the Realm Routing Table and is used to find
the routing required by the Diameter base protocol, which is based on the
destination realm. Every Diameter application has its own RRT built up of
DIA-CFG-Drt instances.

Prior to the creation of a new DIA-CFG-Drt object, the stackId must be

defined during installation time, otherwise there is an error and the DIA-CFG-Drt
object create operation does not take place.

2.7.2.3 DIA-CFG-AuthReqContainer MO

This MO is a container that has a child relationship with DIA-CFG-Drt objects. It

keeps routing data associated with request messages defined by the Diameter
Authentication application protocols. This MO is automatically created when a
Realm Routing Table is created.

2.7.2.4 DIA-CFG-AccReqContainer MO

This MO is a container that has a child relationship with DIA-CFG-Drt objects. It

keeps routing data associated with request messages defined by the Diameter
Accounting application protocols. This MO is automatically created when a
Realm Routing Table is created.

10 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Configuration Management in the Diameter Stack

2.7.2.5 DIA-CFG-AppRouting MO

The DIA-CFG-AppRouting MO contains a Route Action and possibly a list of

Peer Node IDs. Route Action is used for incoming Diameter request messages
and the Peer Node IDs are used when Diameter request messages are
destined for other Diameter Nodes.

2.8 Configuring Vendors and Attribute Value Pairs

These are optional steps depending on the Application. All Vendors and
Attribute Value Pairs (AVP) can be automatically created by the Application
installation and normally not changed afterwards.

2.8.1 Configuration Activities

The following configuration activities are included in the AVP Configuration:

• Add a Vendor, see Configuring Diameter.

• Modify a Vendor, see Configuring Diameter.

• Delete a Vendor, see Configuring Diameter.

• Add an AVP, see Configuring Diameter.

• Modify an AVP, see Configuring Diameter.

• Delete an AVP, see Configuring Diameter.

2.8.2 Managed Objects

2.8.2.1 DIA-CFG-DictionaryContainer

This MO is a container for Vendors and AVPs related to a Dictionary. This MO

is automatically created at the Diameter Installation.

2.8.2.2 DIA-CFG-Vendor MO

This MO contains attributes to define a Diameter Vendor. The vendor is a

container that has a list with references of all its AVPs.

This object can be used by the different stack instances, in the sense that they
are using a certain vendor. That means that they are aware of the existence of
that vendor.

Prior to the creation or updating of a DIA-CFG-Vendor object, all application

stackIds that are to be defined for the vendor must be defined during
installation, otherwise there is an error and the create or update operation
does not take place.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 11

Diameter User Guide

When a DIA-CFG-Vendor object is to be deleted, all its AVPs are automatically

deleted. Prior to deletion, make sure that no AVPs of any application are used.

2.8.2.3 DIA-CFG-AVPDef MO

This object stores the information of an AVP Definition, and it is used to extract
information from incoming Diameter messages and to build new Diameter
messages.

An AVP code may be reused by different vendors, this is why the

DIA-CFG-AVPDef object key is made of AVPCode + vendorId. This object
can be used by the different stack instances, in the sense that they are using a
certain AVP.

Prior to the creation or updating of a DIA-CFG-AVPDef object, all stackIds

that make use of that AVP, specified by the stackIds attribute, must be
defined during installation, otherwise there is an error and the create or update
operation does not take place.

Similarly, an AVP grouped within another AVP of type ‘‘Grouped’’ cannot be

deleted as long as this last one has references to those DIA-CFG-AVPDef
objects that are grouped within it. Any delete request addressed to a grouped
AVP object results in an error and the operation does not take place. To delete
an AVP grouped within another one, first dissociate it from the list of grouped
AVPs and then delete it. Alternatively, if the grouped AVP is deleted, it is
possible to delete those AVPs previously grouped within it.

2.9 Configuring NetRed using Local VIP Address

2.9.1 Configuration Activities

The following configuration activities are included:

• Add configuration for NetRed local VIP address use, see Configuring
Diameter.

• Modify configuration for NetRed local VIP address use, see Configuring
Diameter.

• Delete configuration for NetRed local VIP address use, see Configuring
Diameter.

2.9.2 Managed Objects

2.9.2.1 DIA-CFG-OwnNode-LocalVIPNetRed MO

This MO is used as a complement to the DIA-CFG-OwnNodeConfig when the

use of a TSP NetRed system is required with local VIP addresses.

12 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Configuration Management in the Diameter Stack

Configure the MO on the NetRed node.

2.9.2.2 DIA-CFG-NeighbourNode-LocalVIPNetRed MO

This MO is used as a complement to the DIA-CFG-NeighbourNode when the

use of a TSP NetRed system is required with local VIP addresses.

Configure the MO on the node whose Peer Node is a NetRed node.

2.9.2.3 DIA-CFG-Conn-LocalVIPNetRed MO

This MO is used as a complement to the DIA-CFG-Conn when the use of a

TSP NetRed system is required with local VIP addresses.

Configure the MO on the node whose Peer Node is a NetRed node.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 13

Diameter User Guide

14 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Diameter Application Installation Preparation

3 Diameter Application Installation

Preparation

Prior to an Application installation, the application installation priority must be

defined in the system. Also the TCP listening ports must be defined in VIP
Mappings.

3.1 Configuration Activities

The following activities are included in the Application Installation:

• Application installation priority, see Configuring Diameter.

• Resource use limits, seeConfiguring Diameter.

• Add VIP Mapping, see Configuring Diameter.

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 15

Diameter User Guide

16 1/1553-CRA 119 0019/2 Uen B | 2008-12-24

 Logging

4 Logging

Some events in the Diameter stack are logged using the TSP AppLog utility.
The log messages are saved in the file applog.DIAMETER in the directory
where the DicosApplog client was started. For more information, please
refer to Error Logs User Guide.

The format of the entries in the log file is as follows:

Transport connection failure:

DIAMETER: StackId: <stackId>, peerId: <hostId>, connId: <connId>.

Cause: 10001 Unable to set up transport connection to SCTP.
Detailed info=<info>

Unable to deliver message:

DIAMETER: StackId: <stackId>, peerId: <hostId>.

Cause: 20001 Unable to deliver message

Loop detected in incoming message:

DIAMETER: StackId: <stackId>, peerId: <hostId>.

Cause: 20002 Loop detected in incoming message

Database access failure:

DIAMETER: Cause: 30001 <cause description>

Examples on database access failure:

DIAMETER: Cause: 30001 Database access error, create failed.

File: Test.cc Line: 110
DIAMETER: Cause: 30001 Database access error, openDirtyRead failed.
File: Test.cc Line: 218
DIAMETER: Cause: 30001 Database access error, openSafeRead failed.
File: Test.cc Line: 326
DIAMETER: Cause: 30001 Database access error, openUpdate failed.
File: Test.cc Line: 415
DIAMETER: Cause: 30001 Database access error, openDelete failed.
File: Test.cc Line: 520

Processor overload:

DIAMETER: StackId: <stackId>, peerId: <hostId>, connId: <connId>.

Cause: 40001 Incoming message discarded due to processor overload.
Total count=<number of incoming discarded messages>

Congestion in transport layer:

1/1553-CRA 119 0019/2 Uen B | 2008-12-24 17

Diameter User Guide

DIAMETER: StackId: <stackId>, peerId: <hostId>, connId: <connId>.

Cause: 40002 Outgoing message discarded.
Total count=<number of outgoing discarded messages>.
Detailed info=<info>

The cause description includes the type of failure, for example, create, update,
delete or read failures. Furthermore, the name of the class and the line number
in the source code where the failure occurred is included.

Explanation of priority in Table 1:

• 2 = Critical

• 4 = Warning

Table 1 Logged events

Event Cause ID Cause description Priority
Transport connection 10001 Unable to set up 2
failure transport connection
to TCP/SCTP
An incoming or 20001 Unable to deliver 4
outgoing request is message
not routed properly
A loop is detected in an 20002 Loop detected in 4
incoming message incoming message
Database Access 30001 DB access failure - 4
Failure transaction aborted
DB access failure -
object not found
An incoming request is 40001 Incoming message 2
not processed due to discarded due to
processor overload processor overload
An outgoing request 40002 Outgoing message 2
or answer is not discarded due to
processed due to congestion in transport
congestion in transport layer
layer

18 1/1553-CRA 119 0019/2 Uen B | 2008-12-24