Configuring Diameter CCN

Configuring Diameter
OPERATING INSTRUCS
1/1543-CRA 119 0019/2 Uen F

Copyright
© Copyright Ericsson AB 2007-2009. 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/1543-CRA 119 0019/2 Uen F | 2009-08-07

Contents
Contents
1 Overview 1
1.1 Description 1
1.2 Prerequisites 1
2 Managed Object Structure 5
3 LDAP Command Line Applications 9

3.1 LDAP-add Operation 9
3.2 LDAP-modify Operation 10
3.3 LDAP-delete Operation 10
3.4 LDAP-search Operation 11
4 Configuring Security Management 13

4.1 Adding an Access Group 13
4.2 Modifying an Access Group 14
4.3 Deleting an Access Group 14
4.4 Adding an Administrator 14
4.5 Modifying an Administrator 15
4.6 Deleting an Administrator 15
4.7 Example of a Security Management Configuration 15
5 Configuring Common Stack Data 17

5.1 Modifying Attributes to Common Stack Data 17
5.2 Examples of Common Stack Data Configuration 18
6 Configuring the Own Node 21

6.1 Initial Configuration of the Own Node 21
6.2 Modifying Attributes to the Own Node 22
6.3 Disabling or Enabling the Own Node 22
6.4 Example of an Own Node Initial Configuration 23
7 Configuring a Peer Node and Connections 25

7.1 Adding a Peer Node 25
7.2 Modifying Attributes to a Peer Node 26
7.3 Disabling or Enabling a Peer Node 26
7.4 Deleting a Peer Node 27
1/1543-CRA 119 0019/2 Uen F | 2009-08-07

7.5 Adding a Connection 27

7.6 Disabling or Enabling a Connection 28
7.7 Deleting a Connection 28
7.8 Example of a Peer Node Configuration 28
7.9 Example of Connection Configuration 29
8 Configuring the Realm Routing Table 35

8.1 Adding a Realm Routing Table 35
8.2 Adding an AppRouting to an RRT 36
8.3 Modifying Attributes to an AppRouting for an RRT 36
8.4 Deleting an AppRouting from an RRT 37
8.5 Deleting a Realm Routing Table 38
8.6 Example of a Realm Routing Table Configuration 38
9 Configuring Vendors and Attribute Value Pairs 41

9.1 Adding a Vendor 41
9.2 Modifying a Vendor 41
9.3 Deleting a Vendor 42
9.4 Adding an AVP 42
9.5 Modifying an AVP 43
9.6 Deleting an AVP 43
9.7 Example of an AVP Configuration 43
10 Configuring NetRed Using Local VIP Address 47

10.1 Add Configuration for NetRed Local VIP Address Use 47
10.2 Modify Configuration for NetRed Local VIP Address Use 49
10.3 Delete Configuration for NetRed Local VIP Address Use 50
10.4 Example of a NetRed Configuration Using Local VIP
Address 51
11 Application Installation Preparation 53

11.1 Installation Priority 53
11.2 Resource Use Limits 54
11.3 VIP Mapping 55
1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Overview
1 Overview
1.1 Description
This instruction describes how to configure the Diameter Stack. The following
configurations are described:
• Configuration of Security Management
• Configuration of Common Stack Data
• Configuration of the Own Node
• Configuration of a Peer Node and Connections
• Configuration of the Realm Routing Table
• Configuration of Vendors and Attribute Value Pairs
• Configuration of NetRed using Local VIP Address
Additionally, this instruction describes the necessary steps to do prior to an

application installation.
• Application installation priority
• Resource use limit
• Add VIP Mapping
1.2 Prerequisites
1.2.1 Documents
Before starting this procedure, ensure that you have read the following
documents:
• Diameter User Guide
0 The Diameter User Guide gives an overview of the node configuration

management in the Diameter Stack. The overview refers to the
configuration activities described in this document.
• Diameter Parameter List
0 The Diameter Parameter List describes the parameters used for node
configuration management in the Diameter Stack. When performing the
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 1

configuration activities described in this document, detailed information

about parameter data is found in the Diameter Parameter List.
• LDAP Interface Description
0 This document describes the Lightweight Directory Access Protocol

(LDAP) standards.
• Node Management Toolbox User Guide
0 This document describes the Toolbox. The CM browser LDAP client

(Jxplorer) is included.
• http://www.openldap.org/
0 The LDAP command based interface is developed and maintained by

the OpenLDAP project. More information is found at this address.
1.2.2 Tools
Before starting this procedure, ensure that the following tools are available:
• Any LDAP v3 compliant command line client.
All instructions and examples are made using a command line client.
• The CM browser (JXplorer) in NM Toolbox, or other LDAP v3 compliant

browsers can also be used.
Some of the examples are also shown using the JXplorer.
1.2.3 Conditions
Before starting this procedure, ensure that the following conditions are met:
• The IP address and IP port for the LDAP Server on the node to be updated
must be known.
• The Administrator name and password must be known.
• The node name must be known.
• Diameter configuration data.
1.2.4 Limitations
When configuration data is changed, there may be a latency of up to 10
seconds before the change has impact on the traffic.
2 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Overview
1.2.5 Conventions
• < > Indicates that the information is unique to the operator or application
and must be known by the operator.
• * Indicates a key attribute. When there is more than one key, the primary
key is listed first.
• In all examples the nodeName is set to “jambala”.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 3

4 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Managed Object Structure
2 Managed Object Structure
The Diameter stack Managed Objects (MOs) are structured in a Directory

Information Tree (see Figure 1) that are used to identify the entry to be
managed. Every entry in the directory has a distinguished name (DN). The DN
is the name that uniquely identifies an entry in the directory. A DN is made up
of attribute=value pairs, separated by commas. The order of the component
attribute value pairs is important.
The DN contains one component for each level of the directory hierarchy from
the root down to the level where the entry resides. The first component of the
DN is referred to as the Relative Distinguished Name (RDN). It identifies an
entry distinctly from any other entries that have the same parent.
An example of the RDN for the DIA-CFG-Vendor is:
diaVendorId=1045
The diaVendorId is the Key attribute of the DIA-CFG-Vendor MO and 1045

is the identity of a defined vendor.
An example of the DN of the DIA-CFG-Vendor is:
dn:diaVendorId=1045,
dictionaryContainerName=dictionaryContainerName,
applicationName=DIA,nodeName=jambala
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 5

Figure 1 MO Structure
The following RDNs are always fixed for all Diameter configuration activities:
• nodeName has the value that was set at installation (see TSP Runtime
Maiden Installation), for instance jambala (the value that the JIM-Node
is created with)
• applicationName = DIA (DIA-CFG-Application)
6 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Managed Object Structure
• configuration = Diameter
• dictionaryContainerName = dictionaryContainerName
(DIA-CFG-DictionaryContainer)
• securityContainerName = securityContainerName
(DIA-ADM-SecurityContainer)
• accReqContainerName = accReqContainerName (DIA-CFG-AccRe

qContainer)
• authReqContainerName = authReqContainerName
(DIA-CFG-AuthReqContainer)
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 7

8 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

LDAP Command Line Applications
3 LDAP Command Line Applications
The OpenLDAP software distribution includes several command line

application clients, such as: ldapadd, ldapdelete, ldapmodify and
ldapsearch. These are all documented in the OpenLDAP help pages (see
http://www.openldap.org/), and briefly commented in the following subsections.
The OpenLDAP version to be used is OpenLDAP 2.2.6.
All these command line clients return success (result code 0) if there was
no error when performing the operation. The ldapsearch tool also returns
the objects in the directory that match the search request with the specified
attributes (if any). If there are errors while performing the operation, an error
result code and an error message are sent back to the client, along with the
information about the source of the problem.
3.1 LDAP-add Operation

The ldapadd command line opens a connection to the LDAP server to
bind and add entries. The entry information is read from the standard input
or from file, specified using the -f option. Once the command is launched,
it waits for the specification of an attribute-value pair from the standard
input, entered with a Carriage Return (CR). The request is sent with all
attributes when two consecutive CRs are entered. For example, adding a
DIA-CFG-NeighbourNode object, see Page 9.
ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-D "administratorName=jambala,nodeName=jambala" \
-w "password"
\ << __END__
dn:nodeId=cscf1.ericsson.se#HSS,peerNodeContainerId=HSS,
stackContainerId=HSS,applicationName=DIA,nodeName=jambala
objectClass:DIA-CFG-NeighbourNode
realm:ericsson.se
ipAddressesList:0:123.11.22.33
initiateConnection:FALSE
transportLayerType=1
__END__
Example 1 An Add Operation
The main options are:
• -h specifies the machine where the LDAP server (slapd) is running.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 9

• -p specifies the port in which slapd is listening.
• -D specifies the Distinguished Name to use for binding (the administrator).
• -w specifies the password to use for binding.
3.2 LDAP-modify Operation

The ldapmodify command line opens a connection to the LDAP server to
bind and modify entries. The entry information is read from the standard input
or from file, specified using the -f option. Once the command is launched, it
waits for the specification of an attribute-value pair from the standard input,
entered with a Carriage Return (CR). The request is sent with all attributes
when two consecutive CRs are entered. For example, modification of the
DIA-CFG-NeighbourNode object previously created, see Page 10.
ldapmodify \
-c \
-x \
-h $host \
-p $ldapPort \
-w "password" \
<< __END__
realm:ericsson.se
transportLayerType=1
__END__
Example 2 A Modify Operation
3.3 LDAP-delete Operation

The command arguments are also the same for ldapdelete, but in
this case insert the DN to delete into the file (alternatively, the DN may
be specified as a command line argument). An object may be easily
deleted using the ldapdelete command. For example, deletion of the
DIA-CFG-NeighbourNode object previously created, see Page 11.
10 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

LDAP Command Line Applications
$LDAPDIR/ldapdelete \
-c \
-x \
-h $host \
-p $ldapPort \
-w "password" \
<< __END__
__END__
Example 3 A Delete Operation
3.4 LDAP-search Operation

When there are many objects of the same class, it may be useful to search
for one of them among all other objects of the same class. For example, to
find out all DIA-CFG-NeighbourNode objects whose nodeId starts with ba*,
and print their complete nodeId and realm, a typical ldapsearch command
is shown in Page 11:
ldapsearch -u -h 127.0.0.1 -p 57596 \

-D "administratorName=diameteradmin,nodeName=jambala" \
-w "password" \
-s sub \
-b "applicationName=DIA,nodeName=jambala" \
nodeId= ’ba*’ nodeId realm
Example 4 A Search Operation
The -h, -p, -D and -w flags are described for ldapadd and ldapmodify. In
addition:
• -b specifies the DN of the base object for the search (the root of the subtree
to search in the LDAP hierarchy).
• -s specifies the scope. Valid scopes are base, one and sub, for “base
object only”, “first-level children” and entire subtree.
The first non-flag argument is the filter (required). Complex filters are allowed,
for example: "(&(userName=*)(sharedProfileName=profile-a)", to
retrieve all users associated with profile-a. For objects with multi-valued
attributes, if any value matches the filter criteria, the object is returned.
Following the filter is an optional list of attributes to retrieve. By default, all
attributes are retrieved. The behavior is the same if all user attributes are
requested through the * character. The output of ldapsearch is printed to
the standard output, in a format similar to the input format of ldapadd. These
commands have many more options.
For more information, see http://www.openldap.org/.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 11

12 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Security Management
4 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, except for modifying and/or deleting other objects
created during installation time. At installation time, the following default
administrator and access groups are created:
• DIA-ADM-Administrator
One DIA-ADM-Administrator is created during installation. It is called

diameteradmin.
• DIA-ADM-AccessGroup
One DIA-ADM-AccessGroup is created during installation. It is called

diameteradmin.
There is also a Root Administrator. The name of this administrator is

jambala and can perform any operation in any object.
4.1 Adding an Access Group

Perform the following steps:
1. Identify the dn for an Access Group.
The dn for a Access Group is as follows:
accessGroupId=<accessGroupId>,
securityContainerName=securityContainerName,
2. Set the attributes by using the ldapadd command.
Check the document Diameter Parameter List for the correct values of the
attributes to be set.
The attributes of the DIA-ADM-AccessGroup object to be set is shown

in Page 13.
Table 1 Mandatory Attributes of the DIA-ADM-AccessGroup

*accessGroupId
*accessGroupName
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 13

4.2 Modifying an Access Group

2. Set the attributes by using the command ldapmodify.
Check the document Diameter Parameter List for the correct values of
the attributes to be modified.
4.3 Deleting an Access Group

2. Use the ldapdelete command to delete the Access Group.
4.4 Adding an Administrator

1. Identify the dn for an Administrator.
The dn for a Administrator is as follows:
administratorId=<admId>,
The attributes of the DIA-ADM-Administrator object to be set is shown

in Page 15.
14 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Security Management
Table 2 Mandatory Attributes of the DIA-ADM-Administrator

*administratorId
*administratorName
password
groups
4.5 Modifying an Administrator

2. Set the attributes by using the ldapmodify command.
4.6 Deleting an Administrator

2. Use the ldapdelete command to delete the Administrator.
4.7 Example of a Security Management Configuration

The Page 16 shows how a new Diameter administrator administratorNew is
created together with the password Admin with group rights 0:100. There is
also a new access group NEW created.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 15

ldapadd \
-x \
-v \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:administratorId=9,securityContainerName=securityContainerName,
objectClass:DIA-ADM-Administrator
administratorName:administratorNEW
password: "Admin"
groups: 0:100
__END__
ldapadd \
-x \
-v \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:accessGroupId=9,securityContainerName=securityContainerName,
objectClass:DIA-ADM-AccessGroup
accessGroupName:NEW
__END__
Example 5 Security Management Configuration
16 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Common Stack Data
5 Configuring Common Stack Data
This section shows how to configure common data for the Diameter stack. The
configuration consists of the DIA-CFG-Configuration MO, which is created
during installation. Once the application has been successfully installed and
if SCTP is used as transport layer, the DIA-CFG-Configuration object must
be modified.
There is the attribute traceSctpHandler, which defines whether SS7 traces

for all SCTP connection handlers are enabled or disabled, and the attribute
sctpHandlerLogLevel, which defines log level for all SCTP connection
handlers. There are attributes with the same names in DIA-CFG-Conn,
DIA-CFG-NeighbourNode, DIA-CFG-OwnNodeConfig MOs. These SS7
tracing and logging parameters for Diameter handlers are configured in the
cascading way – the special attribute value, DEFAULT, is used to let the parent
MOs define the configuration. The Page 17 depicts how enabling/disabling
tracing configuration for a handler serving a particular connection is determined.
The logging level is configured similarly.
Table 3 Configuring tracing and logging parameters

Value of traceSctpHandlerattribute in different MOs
DIA-CFG-Con DIA-CFG-Neigh DIA-CFG-Own DIA-CFG Resulting
n bourNode, NodeConfig -Configu value
ration
TRUE TRUE
Does not matter
FALSE Does not FALSE
TRUE matter Does not TRUE
FALSE matter FALSE
TRUE TRUE
DEFAULT
FALSE FALSE
DEFAULT
TRUE TRUE
DEFAULT
FALSE FALSE
5.1 Modifying Attributes to Common Stack Data

1. Identify the dn for the common stack data.
The dn for the common stack data is as follows:
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 17

configuration=Diameter,applicationName=DIA,nodeName=j
ambala
5.2 Examples of Common Stack Data Configuration

The Page 18 is an example of a configuration of common stack
data in the DIA-CFG-Configuration MO which shows how to define
numberOfFrontEnds attribute with the value 4.
The Page 20 is an example of a configuration of data in the

DIA-CFG-Configuration MO which shows how to define a
traceSctpListener with the value TRUE for enabling SS7 traces for all
SCTP connection listeners and how to define a sctpListenerLogLevel
with the value 9.
The Page 20 is an example of a configuration of data in the

DIA-CFG-Configuration MO which shows how to define a
traceSctpHandler with the value TRUE for enabling SS7 traces for all SCTP
connection handlers and how to define a sctpHandlerLogLevel with the
value 9.
Note: Attributes traceSctpListener, sctpListenerLogLevel,

traceSctpHandler and sctpHandlerLogLevel are can also be
configured by using the CM browser in NM Toolbox (JXplorer).
5.2.1 Command Line Example
ldapmodify \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:configuration=Diameter,applicationName=DIA,nodeName=jambala
objectClass:DIA-CFG-Configuration
numberOfFrontEnds:4
__END__
Example 6 Common Stack Data Configuration
18 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Common Stack Data
5.2.2 JXplorer Example
The common stack data can also be configured by using the CM browser in
NM Toolbox (JXplorer), see Page 19.
To perform the same configuration as shown in the command line example

above, perform the following actions:
• Set the value 4 for the numberOfFrontEnds attribute type.
• Submit.
Figure 2 DIA-CFG-Configuration MO in JXplorer
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 19

5.2.3 Command Line Example for changing traceSctpListener and

sctpListenerLogLevel attributes
ldapmodify \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
traceSctpListener:TRUE
sctpListenerLogLevel:9
__END__
Example 7 Data Configuration
5.2.4 Command Line Example for changing traceSctpHandler and

sctpHandlerLogLevel attributes
ldapmodify \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
traceSctpHandler:TRUE
sctpHandlerLogLevel:9
__END__
Example 8 Data Configuration
20 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring the Own Node
6 Configuring the Own Node
A unique identifier called StackId is associated with the Diameter Application

in order for the Diameter Stack to recognize it. The administrator has to
configure the Own Node before bringing the application into service. Once the
application has been successfully installed, the DIA-CFG-OwnNodeConfig
object created for the application has to be configured using a command-based
LDAP client.
The configuration of the node from the point of view of the Diameter Stack
consists of the following MO: DIA-CFG-OwnNodeConfig.
There is the attribute traceSctpHandler, which defines whether SS7

traces for all SCTP connection handlers are enabled or disabled, and
the attribute sctpHandlerLogLevel, which defines log level for all
SCTP connection handlers. There are attributes with the same names in
DIA-CFG-Configuration, DIA-CFG-NeighbourNode, DIA_CFG_Conn
MOs. These SS7 tracing and logging parameters for Diameter handlers are
configured in the cascading way – the special attribute value, DEFAULT, is
used to let the parent MOs define the configuration. The Page 17 depicts
how enabling/disabling tracing configuration for a handler serving a particular
connection is determined. The logging level is configured similarly.
6.1 Initial Configuration of the Own Node

1. Identify the dn for the Own Node.
The dn for an Own Node is as follows:
stackId=<applStackId>,
stackContainerId=<applStackId>,
The attributes of the DIA-CFG-OwnNodeConfig object to be set is shown

in Page 21.
Table 4 Mandatory Attributes of the DIA-CFG-OwnNodeConfig

*stackId
hostId
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 21

realm
(1) (2)
ipAddressesList
(1) (1)
sctpAddressesList
portNr
transportLayerType
productName
supportedVendorsIds
(3)
supportedAcctAppIds
(3)
supportedAuthAppIds
(3)
supportedVendorSpecificApps
(1) When in Geographical Network Redundant configuration, Geographical Network Redundant
VIP address alias must be used instead of ordinary VIP address.
(2) Either ipAddressesList or sctpAddressesList (or both) must be defined. The
AddressesList fields must correspond to transportLayerType.
(3) supportedAcctAppIds, supportedAuthAppIds and supportedVendorSpecificApps are optional
because a node may not support authorization, accounting and supportedVendorSpecificApps
Diameter applications at the same time. One of these three attributes has to be defined.
6.2 Modifying Attributes to the Own Node

6.3 Disabling or Enabling the Own Node

22 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring the Own Node
2. Use the ldapmodify command and set the enabled attribute to FALSE
or TRUE. The attribute value FALSE disables the node and TRUE enables
the node.
6.4 Example of an Own Node Initial Configuration

The LDAP command example Page 24 contains the basic information that is
needed to establish a basic communication with a peer.
In this example the Own Node is configured for the application belonging
to the HSS Stack instance (Stack ID). The realm and host identity is
specified for the Diameter node. The Node starts listening on the Port
number 3868 for incoming connection requests from other Diameter Nodes.
The applications and Vendors supported by the stack instance users are
specified in the supportedAcctAppIds, supportedAuthAppIds and
supportedVendorIds. The Node is configured to allow connection requests
from Diameter Nodes that have not been predefined as Peer Nodes.
Watchdog messages are sent only if there is no peer communication within 30

seconds. If there are no answers received for a request within 10 seconds, the
message is retransmitted (at maximum three times).
This configuration example contains an ipAddressesList field. The field

contains the IP addresses of the hosts.
This is an example of the configuration of the Own Node in the Diameter

Stack database:
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 23

ldapmodify \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:stackId=HSS,stackContainerId=HSS,applicationName=DIA,
nodeName=jambala
objectClass:DIA-CFG-OwnNodeConfig
realm:ericsson.se
hostId:server.ericsson.se
portNr:3868
transportLayerType:1
productName:HSS Diameter Stack
supportedVendorsIds:0
supportedAcctAppIds:3
supportedAuthAppIds:1
allowConnectFromUnknownNode:TRUE
__END__
Example 9 Own Node Configuration
24 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring a Peer Node and Connections
7 Configuring a Peer Node and Connections
Other Diameter Peer 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. One DIA-CFG-NeighbourNode object has
to be created for each peer node in the network.
For each created DIA-CFG-NeighbourNode object, a DIA-CFG-Conn object

is created by default. To get multiple connections for a Peer Node, more
DIA-CFG-Conn objects must be added, one for each required connection.
Setting up multiple connections gives advantages: the processor load is spread

and the throughput is increased. There is a relation between the number
of connections and the number of processors in the DiaStackProcPool. It
means, defining equal numbers of connections as numbers of processors in
the pool gives that the load is spread evenly among all processors in the
DiaStackProcPool (a new process is created for each connection).
Note: Setting up multiple connection is possible only between TSP Diameter

Nodes (multiple connections with other types of nodes is not described
in the standard).
The configuration of the Peer Node from the point of view of the Diameter Stack
consists of the following MOs: DIA-CFG-NeighbourNode and DIA-CFG-Conn.
There is the attribute traceSctpHandler, which defines whether SS7

traces for all SCTP connection handlers are enabled or disabled, and the
attribute sctpHandlerLogLevel, which defines log level for all SCTP
connection handlers in DIA-CFG-Conn and in DIA-CFG-NeighbourNode.
There are attributes with the same names in DIA-CFG-Configuration,
DIA-CFG-OwnNodeConfig MOs. These SS7 tracing and logging parameters
for Diameter handlers are configured in the cascading way – the special
attribute value, DEFAULT, is used to let the parent MOs define the configuration.
The Page 17 depicts how enabling/disabling tracing configuration for a handler
serving a particular connection is determined. The logging level is configured
similarly.
7.1 Adding a Peer Node

1. Identify the dn for the Peer Node.
The dn for a Peer Node is as follows:
nodeId=<applNodeId>,
peerNodeContainerId=<applStackId>,
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 25

The attributes of the DIA-CFG-NeighbourNode object to be set is shown

in Page 26.
Table 5 Mandatory Attributes of the DIA-CFG-NeighbourNode

*nodeId
ipAddressesList
sctpAddressesList
transportLayerType
Note: Either ipAddressesList or sctpAddressesList (or both)

must be defined. The AddressesList fields must correspond to
transportLayerType.
7.2 Modifying Attributes to a Peer Node

7.3 Disabling or Enabling a Peer Node

26 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

2. Use the ldapmodify command to set the enabled attribute to FALSE or

TRUE. The attribute value FALSE disables the node and TRUE enables
the node.
When the Peer Node is disabled (enabled = false), all its connections are
disconnected. When the Peer Node is enabled again (enabled = true)
all its connections are established again, provided that the Peer Node is
configured as connection initiator (initiateConnection = true).
7.4 Deleting a Peer Node

2. Use the ldapmodify command and set the enabled attribute to FALSE
to disable the node.
3. Use the ldapdelete command to delete the node.
7.5 Adding a Connection

To establish a new connection, perform the following steps:
1. Identify the dn for the connection.
The dn for a connection is as follows:
connId=<applConnId>,
The attributes of the DIA-CFG-Conn object to be set is shown in Page 27.
Table 6 Mandatory Attributes of the DIA-CFG-Conn

*connId
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 27

7.6 Disabling or Enabling a Connection

2. Use the ldapmodify command to set the enabled attribute to FALSE

or TRUE. The attribute value FALSE disables the connection and TRUE
enables the connection.
7.7 Deleting a Connection

To disconnect an established connection, perform the following steps:
2. Use the ldapdelete command to delete the connection.
7.8 Example of a Peer Node Configuration

The LDAP example Page 29 contains the basic information that is needed to
establish a basic communication with a peer (one connection).
The LDAP command in the example configures the data for a Peer Node.
The nodeId field contains the data that is introduced as Own Node in the
client. The nodeId field in the dn contains the Diameter host identity of the
Client. The Own Node (stack ID=TST_CLI) is able to have a connection toward
the Diameter host Id of the Client. The connection is not initiated from the
Own Node since InitiateConnection=FALSE. Instead, the connection is
established from the Peer Node and is also accepted since it is defined in
the Own Node configuration.
28 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:nodeId=DestSrv0.ericsson.se#TST_CLI,peerNodeContainerId=TST_CLI,
stackContainerId=TST_CLI,applicationName=DIA,nodeName=jambala
portNr:38401
transportLayerType:1
__END__
Example 10 Peer Node Configuration
7.9 Example of Connection Configuration

This example contains the basic information that is needed to establish one
more connection with a peer.
The connId field consists of three parts:
• stackId, the identity of the stack
• hostId, the host identity of the client
• connId, the unique identity of the connection
Each time a new connection is added for a Peer Node, a new connection identity
must be added, while the other two parts of the connId remain the same.
7.9.1 Command Line Example

The LDAP command example is shown in Page 30
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 29

ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:c,
nodeId=DestSrv0.ericsson.se#TST_CLI,peerNodeContainerId=TST_CLI,
stackContainerId=TST_CLI,applicationName=DIA,nodeName=jambala
objectClass:DIA-CFG-Conn
__END__
Example 11 Configuration of Multiple Connections
7.9.2 JXplorer Example

A new connection can also be configured by using the CM browser in NM
Toolbox (JXplorer).
To perform the same configuration as shown in the command line example

above, perform the following actions:
• Right click on the Peer Node in the Peer Node container that the new
connection is to be created for. Select New. See Page 31.
• Select the MO DIA-CFG-Conn and enter the RDN connId=TST_CLI#De

stSrv0.ericsson.se#conn2. Click OK. See Page 31.
• Set the mandatory attributes (none for this MO). Click Submit. See Page
32.
• Click the newly created MO to see the values. See Figure 6.
30 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Figure 3 Create new entry for the Peer Node
Figure 4 Select entry to create and set RDN
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 31

Figure 5 New entry created
32 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Figure 6 Default values for the new entry
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 33

34 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring the Realm Routing Table
8 Configuring the Realm Routing Table
The different Realm Routing Table (RRT) entries determine the routing
behavior of the node. Depending on the realm, the request type, and the
application, 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 the routing of incoming
requests from the peer nodes and another for the routing of 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 found in the MOs. The RRT consists of the following MOs:
• DIA-CFG-Drt
• DIA-CFG-AppRouting
There is one or more DIA-CFG-AppRouting MO depending on how many

applications are supported for a specific Stack Instance.
8.1 Adding a Realm Routing Table

1. Identify the dn for the RRT.
The dn for a Realm Routing Table is as follows:
entryId=<entryId>,routingContainerId=<applStackId>,
stackContainerId=<applStackId>,applicationName=DIA,
nodeName=jambala
The attribute of the DIA-CFG-Drt object to be set is shown in Page 35.
Table 7 Mandatory Attribute of the DIA-CFG-Drt

*entryId
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 35

8.2 Adding an AppRouting to an RRT

1. Identify the dn for the AppRouting.
The dn for the AppRouting is as follows:
requestedApp=<appId>,
authReqContainerName=authReqContainerName,
entryId=<entryId>,
routingContainerId=<applStackId>,
secondaryNodeIds=<applNodeId>,
secAutoFailback=<true/false>,
or
accReqContainerName=accReqContainerName,
entryId=<entryId>,
secondaryNodesIds=<applnodeId>,
Note: The DN to use depends on if it is an authorization/authentication

application or if it is an accounting application.
The attributes of the DIA-CFG-AppRouting object to be set is shown in Page

36.
Table 8 Mandatory Attributes of the DIA-CFG-AppRouting

*requestedApp
action
(1)
nodeIds
(1) Mandatory for none and optional for redirect .
8.3 Modifying Attributes to an AppRouting for an RRT

36 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

entryId=<entryId>,
or
entryId=<entryId>,

8.4 Deleting an AppRouting from an RRT

entryId=<entryId>,
or
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 37

entryId=<entryId>,

2. Use the ldapdelete command to delete the AppRouting from the RRT.
8.5 Deleting a Realm Routing Table

1. Identify the dn for the Realm Routing Table.
The dn for a Realm Routing Table is as follows:
entryId=<entryId>,
2. Use the ldapdelete command to delete the RRT.
8.6 Example of a Realm Routing Table Configuration

The mandatory entryId field has three parts:
• the realm of the client.
• the stack instance to identify the Own Node.
• the indication of whether this entry of the Realm Routing Table is used to
route incoming or outgoing requests.
The Page 39 is an example of the configuration of the RRT in the Diameter

Stack database. The server receives the requests from the client so this
indicator is set to TRUE. The mandatory action field has been set to local,
indicating that the Own Node acts as a Server and treats the requests. The
fieldsecondaryNodeIds is a list of struct containing number in the list, nodeId
and priority for secondary destinations. The flag secAutoFailback has
default value TRUE, it is indicating that failback to primary destination shall be
done as soon as it becomes available.
38 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:entryId=ericsson.se:HSS:TRUE,routingContainerId=HSS,
objectClass:DIA-CFG-Drt
__END__
ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END_
dn:requestedApp=0:1,authReqContainerName=authReqContainerName,
entryId=ericsson.se:HSS:TRUE,routingContainerId=HSS,secondaryNodesI
secAutoFailback=TRUE,
objectClass:DIA-CFG-AppRouting
requestedApp:0:1
action:0
__END__
Example 12 Realm Routing Table Configuration
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 39

40 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Vendors and Attribute Value Pairs
9 Configuring Vendors and Attribute Value

Pairs
The Attribute -Value Pairs (AVPs) that the node is able to recognize must be
configured. An AVP always belongs to a Vendor and the Vendor must be
defined first. This configuration consists of the following MOs:
• DIA-CFG-Vendor
• DIA-CFG-AvpDef
9.1 Adding a Vendor

1. Identify the dn for the Vendor.
The dn for a Vendor is as follows:
diaVendorId=<diaVendorId>,
The attributes of the DIA-CFG-Vendor object to be set is shown in Page 41.
Table 9 Mandatory Attributes of the DIA-CFG-Vendor

*diaVendorId
diaVendorName
stackIds
9.2 Modifying a Vendor

1. Identify the dn for an Vendor.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 41

9.3 Deleting a Vendor

1. Identify the dn for the Vendor.
2. Use the ldapdelete command to delete the Vendor.
9.4 Adding an AVP

1. Identify the dn for an AVP.
The dn for a AVP is as follows:
avpId=<avpId>,
The attributes of the DIA-CFG-AvpDef object to be set is shown in Page 42.
Table 10 Mandatory Attributes of the DIA-CFG-AvpDef

*avpId
avpName
stackIds
avpDataType
42 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

9.5 Modifying an AVP

avpId=<avpId>,
9.6 Deleting an AVP

avpId=<avpId>,
2. Use the ldapdelete command to delete the AVP.
9.7 Example of an AVP Configuration

In Page 44 a new AVP exampleAVP is created for the Vendor
exampleVendor. The AVP is of the type address and is used by the HSS
Stack Instance users. The Vendor ID is id = 9999 and the AVP ID is Id = 2.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 43

ldapadd \
-x \
-v \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:diaVendorId=99999,
objectClass:DIA-CFG-Vendor
diaVendorName:exampleVendor
stackIds:0:HSS
dn:avpId=99999:2,diaVendorId=99999,
objectClass:DIA-CFG-AvpDef
avpName:exampleAVP
avpDataType:9
stackIds:0:HSS
__END__
Example 13 Vendor and AVP Configuration
In Page 44 another AVP, exampleAVP2, is created for the Vendor in example

9. The AVP is of the type octet string and is used by the HSS Stack
Instance users.
ldapadd \
-x \
-v \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
avpName:exampleAVP2
avpDataType:0
stackIds:0:HSS
__END__
Example 14 Add an AVP
44 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

In Page 45 a grouped AVP, exampleGroupedAVP1, is created. The AVP is of

the type grouped and contains the AVP created in Example 9 above.
ldapadd \
-x \
-v \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
avpName:exampleGroupedAVP1
avpDataType:8
stackIds:0:HSS
groupedAvpList:0:99999\:2:1:5
__END__
Example 15 Grouped AVP Configuration
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 45

46 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring NetRed Using Local VIP Address
10 Configuring NetRed Using Local VIP

Address
In order to configure TSP NetRed system using local VIP addresses, Diameter
connections of a client node must be set up to both primary and standby
zones of a server node employing NetRed. Depending on a role each node
plays in communication, different MOs must be configured.
Server node:
• DIA-CFG-OwnNode MO: ipAddressesList and sctpAddressesList

attributes contain local VIP addresses of preferred primary zone.
• DIA-CFG-OwnNode-LocalVIPNetRed MO: zone2TcpAddressList

and zone2SctpAddressList attributes contain local VIP addresses of
preferred standby zone.
Client node:
• DIA-CFG-Conn MO: ipAddressesList and sctpAddressesList

attributes contain local VIP addresses of a particular zone (primary or
standby) in a server node.
• DIA-CFG-Conn-LocalVIPNetRed MO: the zoneId attribute defines

which zone of the server node the connection is aimed at (1 represents
preferred primary zone, 2 represents preferred standby zone). Together
with DIA-CFG-Conn MO, this MO specifies which addresses must be used
to reach each zone of the NetRed node.
• DIA-CFG-NeighbourNode-LocalVIPNetRed MO: the attribute

connectFailureQuarantineTime allows to configure a timer threshold
value that is used to shorten the failover time.
10.1 Add Configuration for NetRed Local VIP Address Use
10.1.1 Adding an OwnNode for Local VIP Address Use
1. Identify the dn for the local VIP Own Node.
localVIPNetRedStackId=<applStackId>,
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 47

The attributes of the DIA-CFG-OwnNode-LocalVIPNetRed object to be

set is shown in Page 48.
Table 11 Mandatory Attributes of the DIA-CFG-OwnNode-LocalVIPNetRed

*localVIPNetRedStackId
(1)
zone2TcpAddressList
(1)
zone2SctpAddressList
(1) Either zone2TcpAddressList or zone2SctpAddressList (or both) must be
defined. The AddressList fields must correspond to transportLayerType of the
DIA-CFG-OwnNodeConfig.
10.1.2 Adding a Peer Node for Local VIP Address Use

1. Identify the dn for the local VIP Peer Node.
localVIPNetRedNodeId=<applNodeId>,
The attributes of the DIA-CFG-NeighbourNode-LocalVIPNetRed object to

be set is shown in Page 48.
Table 12 Mandatory Attributes of the DIA-CFG-NeighbourNode-LocalVIP

NetRed
*localVIPNetRedNodeId
10.1.3 Adding a Connection for Local VIP Address Use

1. Identify the dn for the local VIP connection.
48 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

localVIPNetRedConnId=<applConnId>,
The attributes of the DIA-CFG-Conn-LocalVIPNetRed object to be set

is shown in Page 49.
Table 13 Mandatory Attributes of the DIA-CFG-Conn-LocalVIPNetRed

*localVIPNetRedConnId
zoneId
10.2 Modify Configuration for NetRed Local VIP Address

Use
10.2.1 Modifying an Own Node for Local VIP Address Use
10.2.2 Modifying a Peer Node for Local VIP Address Use

1/1543-CRA 119 0019/2 Uen F | 2009-08-07 49

10.2.3 Modifying a Connection for Local VIP Address Use

1. Identify the dn for the local VIP connection.
10.3 Delete Configuration for NetRed Local VIP Address

Use
10.3.1 Deleting an Own Node for Local VIP Address Use

10.3.2 Deleting a Peer Node for Local VIP Address Use

50 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

The dn for an Peer Node is as follows:
10.3.3 Deleting a Connection for Local VIP Address Use

1. Identify the dn for the local VIP Connection.
10.4 Example of a NetRed Configuration Using Local VIP

Address
The LDAP command example Page 52 contains the basic information that is
needed to configure a NetRed system using local VIP addresses.
This is an example of the configuration of a NetRed system using local VIP

addresses in the Diameter Stack database:
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 51

ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:localVIPNetRedStackId=HSS,stackId=HSS,
stackContainerId=HSS,applicationName=DIA,
nodeName=jambala
objectClass:DIA-CFG-OwnNode-LocalVIPNetRed
zone2IpAddressesList:0:10.0.194.130
__END__
ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:localVIPNetRedNodeId=cscf1.ericsson.se#HSS,
nodeId=cscf1.ericsson.se#HSS,peerNodeContainerId=HSS,
objectClass:DIA-CFG-NeighbourNode-LocalVIPNetRed
connectFailureQuarantineTime:150
__END__
ldapadd \
-c \
-x \
-h $host \
-p $ldapPort \
-w "Pokemon1" \
<< __END__
dn:localVIPNetRedConnId=HSS#cscf1.ericsson.se#conn2,
connId=HSS#cscf1.ericsson.se#conn2,
nodeId=cscf1.ericsson.se#HSS,peerNodeContainerId=HSS,
objectClass:DIA-CFG-Conn-LocalVIPNetRed
zoneId:1
__END__
Example 16 NetRed Configuration
52 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Application Installation Preparation
11 Application Installation Preparation
This section describes the necessary steps to be taken before a Diameter

application can be installed in an already running TSP system.
Note: After the parameters according to this section has been added or
changed, a backup must be taken to preserve the new values after
a Zone Reload.
Note: For maiden installation (TSP and application together), see Preparing
for Application Installation, Diameter.
11.1 Installation Priority

Each Diameter application to be installed must set a Diameter environment
variable, DIA_INSTALLER_ <priority> = <StackID>, prior to the
Application installation. The StackId is defined and provided by the
Application to be installed.
The DIA_INSTALLER variable specifies the installation order between the

Diameter applications in case of multiple Diameter Applications using separate
Stack instances (StackIds). The variable must be set even if only one
Diameter application is installed. The <priority> must use consecutive
numbers starting from 0 (zero). The <StackID> is a string used by the
Diameter to identify the Stack instance a Diameter Application uses for its
configuration of the Diameter protocol.
The Page 53 assumes that there are three Diameter applications installed;
HSS, CSCF and CCN using the StackIds; HSS, CSCF and CCN respectively.
The Page 53 shows when only one application is installed.
DIA_INSTALLER_0 = "HSS"
DIA_INSTALLER_1 = "CSCF"
DIA_INSTALLER_2 = "CCN"
Example 17 Example of DIA_INSTALLER settings, where three Diameter

applications are installed
Example 18 Example of DIA_INSTALLER settings, where only CCN is
installed
11.1.1 Procedure
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 53

1. Identify all stack instances that are installed for the Diameter protocol. This
includes both Diameter applications that have already been installed, and
the Diameter applications that are to be installed.
2. From the IO processor, telnet into the Initial loader using the 8110 port.
3. change the directory :

>cd env/
4. print all environment variables “printenv”.

>printenv
5. Identify all already used StackIds by searching DIA_INSTALLER_x.
6. Set the wanted installation priority for all Diameter applications to be

installed by using the next consecutive available number.
> setenv DIA_INSTALLER_x “stackID”.
Example:
> setenv DIA_INSTALLER_4 “HSS”
11.2 Resource Use Limits

The Diameter environment variable DIA_RESOURCE_LIMIT specifies the
maximum number of resources (such as timers or ports) that a diameter
connection handler process can use before the process is aborted. The needed
resources are directly coupled with the amount of ongoing Diameter Application
User Processes that simultaneously are connected to one Diameter Handler
Process (peer connection).
The rule for setting this data is to calculate how many simultaneous Diameter
Application User Processes there are using one Diameter peer connection
simultaneously and set the resource limit to this value.
Each application can set its own value for the resource limit, there is one
environment variable for each stack instance (StackId) in the system, see
Page 55.
DIA_RESOURCE_LIMIT_<StackID> = maximum number of user processes

per connection.
The StackId must be the same as used for the

DIA_INSTALLER_0= "StackId"
Note: The resource limit setting is not obligatory. If an application does not
specify the limit, the Handler process is created with a default value of
10000 simultaneous connections.
54 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Application Installation Preparation
DIA_INSTALLER_0 = "HSS"
DIA_INSTALLER_1 = "CSCF"
Then the following resource limits can be set:
DIA_RESOURCE_LIMIT_HSS = "10000"
DIA_RESOURCE_LIMIT_CSCF = "20000"
DIA_RESOURCE_LIMIT_CCN = "30000"
Example 19 Example of resource limit settings, where the three Diameter

applications are installed
Note: There are other TSP system limitations that need to be coordinated on
a system level, such as maximum number of IPC ports per processor
or maximum number of processes per processor. It is the responsibility
of the Diameter Application Designer to coordinate all system limits.
11.2.1 Procedure
1. From the IO processor, telnet into the Initial loader using the 8110 port.
2. change the directory.

“cd env/
3. Set the wanted resource limit for all Diameter applications to be installed.
>setenv ”DIA_RESOURCE_LIMIT_<StackID> “limit”
Example: DIA_RESOURCE_LIMIT_CCN = "30000"
Note: This procedure can be performed if the resource limit must be changed
at any time.
11.3 VIP Mapping
11.3.1 VIP Ports for Incoming TCP Connection

Diameter applications use the reserved TCP ports in the range of 8700-8732
and 3868 for listening to incoming TCP connection requests. These are
reserved for diameter in TSP and are normally defined at installations of first
application. If not already defined, or if other TCP ports are needed, these ports
must be added at application deployment.
The procedure for adding VIP Ports is described in Adding Virtual IP to a Live
System.
Note: This procedure can be performed whenever a new TCP listening port
is needed.
1/1543-CRA 119 0019/2 Uen F | 2009-08-07 55

11.3.2 VIP Addresses for Incoming Connection
If more than one address is required for listening to incoming connection

requests, more addresses must be added at application deployment.
The procedure for adding VIP Addresses is described in Adding Virtual IP

to a Live System.
Note: This procedure can be performed whenever a new TCP or SCTP

listening address is needed.
56 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

Configuring Diameter CCN

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Configuring Diameter CCN

Caricato da

Copyright:

Formati disponibili

Configuring Diameter

1/1543-CRA 119 0019/2 Uen F

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

1/1543-CRA 119 0019/2 Uen F | 2009-08-07

2 Managed Object Structure 5

3 LDAP Command Line Applications 9

4 Configuring Security Management 13

5 Configuring Common Stack Data 17

6 Configuring the Own Node 21

7 Configuring a Peer Node and Connections 25

1/1543-CRA 119 0019/2 Uen F | 2009-08-07

7.5 Adding a Connection 27

8 Configuring the Realm Routing Table 35

9 Configuring Vendors and Attribute Value Pairs 41

10 Configuring NetRed Using Local VIP Address 47

11 Application Installation Preparation 53

1/1543-CRA 119 0019/2 Uen F | 2009-08-07

• Configuration of Security Management

• Configuration of Common Stack Data

• Configuration of the Own Node

• Configuration of a Peer Node and Connections

• Configuration of the Realm Routing Table

• Configuration of Vendors and Attribute Value Pairs

• Configuration of NetRed using Local VIP Address

Additionally, this instruction describes the necessary steps to do prior to an

• Application installation priority

• Resource use limit

• Add VIP Mapping

• Diameter User Guide

0 The Diameter User Guide gives an overview of the node configuration

• Diameter Parameter List

1/1543-CRA 119 0019/2 Uen F | 2009-08-07 1

configuration activities described in this document, detailed information

• LDAP Interface Description

0 This document describes the Lightweight Directory Access Protocol

• Node Management Toolbox User Guide

0 This document describes the Toolbox. The CM browser LDAP client

0 The LDAP command based interface is developed and maintained by

• Any LDAP v3 compliant command line client.

• The CM browser (JXplorer) in NM Toolbox, or other LDAP v3 compliant

Some of the examples are also shown using the JXplorer.

• The Administrator name and password must be known.

• The node name must be known.

• Diameter configuration data.

2 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

• In all examples the nodeName is set to “jambala”.

1/1543-CRA 119 0019/2 Uen F | 2009-08-07 3

4 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

2 Managed Object Structure

The Diameter stack Managed Objects (MOs) are structured in a Directory

An example of the RDN for the DIA-CFG-Vendor is:

The diaVendorId is the Key attribute of the DIA-CFG-Vendor MO and 1045

An example of the DN of the DIA-CFG-Vendor is:

1/1543-CRA 119 0019/2 Uen F | 2009-08-07 5

• applicationName = DIA (DIA-CFG-Application)

6 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

• accReqContainerName = accReqContainerName (DIA-CFG-AccRe

1/1543-CRA 119 0019/2 Uen F | 2009-08-07 7

8 1/1543-CRA 119 0019/2 Uen F | 2009-08-07

3 LDAP Command Line Applications

The OpenLDAP software distribution includes several command line

3.1 LDAP-add Operation

The main options are:

• -h specifies the machine where the LDAP server (slapd) is running.