The ConfigurationProfile configuration property provides the resource adaptor entity with the name of a SLEE profile to use.
The profile specification ID is name=Diameter Configuration, vendor=OpenCloud, version=2.6. The example build file demonstrates the SLEE management commands required to create a valid Diameter configuration profile and create a resource adaptor entity with the configuration property. (In practice, normally a profile export XML file is used.)
The profile is polled for changes according to the value of ConfigurationProfilePollTime in the resource adaptor configuration properties. (This is disabled by default).
Most attributes can be changed while the resource adaptor entity is active, but some cannot — as indicated in the tables below.
Host identity
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
product name to use in Product-Name AVPs generated by the stack |
Yes |
|
value to be used as Vendor-Id AVP in CER/CEA messages default value is |
Yes |
|
version number to use in all Firmware-Revision AVPs generated by the stack must be a positive int |
Yes |
|
realm to use in all Origin-Realm AVPs |
No |
Single-node or multi-node host configuration
Two sets of attributes can configure the Diameter host and listener settings. One set, for single-node Rhino instances (including the Rhino SDK), uses simple types. The other, for multi-node clusters, uses array types. The EnableMultiNodeConfig attribute tells the resource adaptor which to use.
Attributes used in both single-node and multi-node configuration.
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
whether to use |
Yes |
|
if true, then any peer may connect to this node; |
Yes |
|
Multi-node host configuration must be used when a Diameter resource adaptor is deployed in a multi-node Rhino cluster. This is so that each node has a unique identity (using the PerNodeHosts attribute). The OpenCloud Diameter simulators will not accept connections from multiple hosts with the same identity (as required by the specification).
|
Single-node host configuration
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
host to use in all Origin-Host AVPs; |
No |
|
local address to listen on if not specified, no listener is started this attribute determines whether the entity operates in client mode or server mode |
Yes |
|
extra addresses to bind SCTP server channels to (SCTP multi-homing) multiple addresses may be separated by commas |
Yes |
|
listen port |
Yes |
|
transport(s) to listen on values can be |
Yes |
Multi-node host configuration
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
a list of Node IDs each element must be unique the index of a node in NodeIDs defines the index that will be used in the arrays below for example, if |
Yes |
|
host names, one per node, in the same order as NodeIDs used for the each hostname must be unique |
No |
|
listen address, one per node, in the same order as NodeIDs used as the listen address on each node; may be null or empty, in which case no listeners will be started on any node |
Yes |
|
extra addresses, one element per node, in the same order as NodeIDs used to bind SCTP server channels (SCTP multi-homing) in each element, multiple addresses may be separated by commas |
Yes |
|
Diameter ports, one per node, in the same order as NodeIDs used for the listen port on each node ignored if |
Yes |
|
The Transports attribute cannot be specified per-node; the same value is used for all nodes.
|
Peer and realm configuration
There are two options for configuring a remote peer and realm. The simple peer configuration uses a handful of profile attributes to configure the essential information and sets all other values to defaults. The complex peer configuration uses two profile attributes that contain XML documents describing multiple peers and realms.
If the PeerTable and RealmTable attributes are set, then they will be used and all the attributes listed for simple peer and realm configuration will be ignored. If PeerTable and RealmTable are not set, then the simple peer configuration will be used.
|
|
Using PeerTable and RealmTable is strongly recommended — the attributes for simple peer configuration will be removed in the next major release of Diameter.
|
Simple peer and realm configuration
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
host of remote Diameter peer |
Yes |
|
port of remote Diameter peer |
Yes |
|
(optional) address to override PeerHost when resolving address for outgoing connections must be a numeric IP address if not specified, the host set in |
Yes |
|
whether to connect to the remote peer at startup must be |
Yes |
|
whether to establish TLS secure session with peer defined in PeerHost |
Yes |
|
value required (exact string match) for owner-distinguished name with certificate from peer (required if defined) example value: |
Yes |
|
Diameter Application ID |
Yes |
|
Vendor ID must be 0 for IETF-specified applications, or an IANA-assigned private enterprise number |
Yes |
|
must be |
Yes |
Advanced peer and realm configuration
| Attribute | What it specifies | Active reconfig? |
|---|---|---|
|
valid XML document for peer table configuration |
Yes |
|
valid XML document for realm table configuration |
Yes |
|
select outgoing request routing algorithm value must be one of: |
Yes |
|
|
See also
Configuring peer and realm tables.
|
