Diameter Base Protocol: Establishing a Diameter Peer Connection
This chapter provides information about configuring and troubleshooting the Diameter Base protocol to establish a Diameter peer connection.
Topics in this chapter include:
Applicability
This information and configuration in this chapter are based on SR OS Release 19.10.R1.
This chapter covers the Diameter base protocol implementation that is available from SR OS Release 16.0.R4 onward (configured in aaa CLI context as diameter node). The legacy Diameter base implementation (configured in the aaa CLI context as diameter-peer-policy) is supported in maintenance mode only, without any further feature enhancement planned. Nokia recommends using or transitioning to the new Diameter base protocol implementation.
Overview
Diameter is an Authentication, Authorization and Accounting (AAA) protocol defined by the IETF in RFC 6733, Diameter Base Protocol. While historically wireline access networks were largely based on RADIUS for subscriber authentication, authorization, and accounting, it was decided by 3rd Generation Partnership Project (3GPP) that wireless access networks will be largely based on Diameter. Over time, operators are looking to converge both types of networks, and one of the aspects of this is to replace RADIUS in wireline access networks by Diameter.
Diameter is based on three layers: the transport layer, the Diameter base protocol layer and the Diameter applications as shown in Diameter protocol stack.
The bottom layer is the transport layer and can be either TCP or SCTP. SR OS supports TCP. The Diameter base protocol implementation in SR OS is based on RFC 6733. The top layer contains the Diameter applications. SR OS supports NASREQ for authentication, Gx for authorization, policy management and usage monitoring and Gy or Diameter Credit Control Application (DCCA) for online charging.
Diameter network topology shows a Diameter network topology that will be used in the configuration examples in this chapter.
A Diameter Client (BNG) is connected via peer-1a and peer-1b to two Diameter Agents (DRA-1 and DRA-2) that provide connectivity to the Diameter Application Servers (PCRF). Via these peers, the BNG can authenticate and perform policy control of subscriber sessions using the NASREQ and Gx applications. The same Diameter Client (BNG) is also directly connected to another Diameter Application Server (OCS) via peer-2. Via this peer, on-line charging can be done for the subscriber sessions using the Gy application.
Configuration
The Diameter base protocol and the Diameter applications are configured separately, where the Diameter base protocol must be configured first, and the Diameter applications next. The transport layer configuration is part of the Diameter base protocol layer. This example describes the Diameter base protocol configuration.
The Diameter base protocol and the corresponding transport layer configuration is based on Diameter Nodes. Each Diameter Node represents a Diameter routing instance and contains a list of peers in the routing domain that provide direct or indirect connectivity to application servers.
An example Diameter node configuration that corresponds with the topology in Diameter network topology is shown below.
configure {
aaa {
diameter {
node "bng-gx.realm-1.com" {
description "Authentication and Policy Management"
connection {
ipv4 {
local-address 192.0.2.2
}
ipv6 {
local-address 2001:db8::2
}
}
peer index 1 {
admin-state enable
address 2001:db8:2:6::1
destination-host "dra-1.realm-2.com"
preference 10
}
peer index 2 {
admin-state enable
address 172.16.7.2
destination-host "dra-2.realm-2.com"
preference 20
}
}
node "bng-gy.realm-1.com" {
description "Credit Control"
origin-realm "realm-1.com"
router-instance "management"
peer index 1 {
admin-state enable
address 192.99.3.0
destination-host "ocs.realm-1.com"
}
}
}
A Diameter node configuration requires a unique origin host as key. The origin host is used in Diameter application policies to associate the application with the node. All Diameter base and application messages forwarded via the peers of that node use the configured origin host in the Origin-Host AVP. The value for the Origin-Realm AVP is by default derived from the configured origin host: the realm is the part of the origin host after the first dot (".") as delimiter or equal to the origin host when it does not contain a delimiter. For example, for node "bng-gx.realm-1.com": Origin-Host = "bng-gx.realm-1.com", Origin-Realm = "realm-1.com". It is also possible to explicitly configure an origin realm as shown in the example for the node "bng-gy.realm-1.com".
A node configuration can include a routing context, and an IPv4 and/or IPv6 source address. These parameters are used to establish the TCP transport connection for all peers in the node. The specified local-address must be a reachable local interface address in the specified or in the default router instance. For node "bng-gx.realm-1.com" in the example, no router instance is specified. By default, the TCP connections are established in the Base router using the specified local addresses. For node "bng-gy.realm-1.com" in the example, the out of band router instance "management" is used to establish the TCP connection of its peer. As no local address is specified, the system will automatically select an interface address, in this case an out of band IP address configured in the Boot Options File (BOF).
Within a Diameter node, up to 5 peers can be configured with an index value between 1 and 5 as key, an IPv4 or IPv6 destination address for the TCP connection, and a mandatory destination host that is used as Destination-Host AVP value for all Diameter base messages on the peer. In a Diameter node, one peer is selected to forward application messages for a specific application session. The other peers provide redundancy when supported by the Diameter application, such as Gy session failover. A Diameter peer for application messages is selected based on following criteria:
-
Forwarding:
If the application message contains a Destination-Host AVP, select the peer in the peer table with a matching configured destination host. This is the forwarding phase.
-
Routing:
When the lookup in the peer table fails, perform a lookup in the realm routing table and select the peer with realm name equal to the Destination-Realm AVP in the application message, and with matching application ID. When multiple peers are matched, select in order or priority until a single peer is found:
-
the peer with the lowest configured preference (default preference is 50)
-
the peer with the lowest index
-
-
Default peer:
When both forwarding lookup in the peer table and routing lookup in the realm routing table were unsuccessful, use the peer configured as default-peer. Only a single peer in a node can be configured as a default-peer. Multiple peers in a node configured as default-peer results in a validation error:
MINOR: MGMT_CORE #5001: configure aaa diameter node "bng-gx.realm-1.com" peer index 2 - Multiple default peer is not allowed
For node "bng-gx.realm-1.com" in the example, peer-1a with index 1 has a configured preference of 10 and peer-2 with index 2 has a configured preference of 20. Diameter Gx application messages will fail the peer table lookup as the destination host of the PCRF will not be present (no direct connection between Diameter client and Diameter application server):
# /show aaa diameter-node "bng-gx.realm-1.com" peers
===============================================================================
Peers
===============================================================================
Host identity Status Default Preference Active
-------------------------------------------------------------------------------
dra-1.realm-2.com I-Open No 10 Yes
dra-2.realm-2.com I-Open No 20 Yes
-------------------------------------------------------------------------------
No. of peers: 2
===============================================================================
Instead a realm routing table lookup is performed to find the peer for forwarding the application messages. In this case peer-1a (dra-1.realm-2.com) is selected based on the matching destination realm (realm-2.com), application ID (Gx) and the lower preference value:
# /show aaa diameter-node "bng-gx.realm-1.com" routing-table
===============================================================================
Routes
===============================================================================
Realm-Name
Application Pref. Id Server-Identifier
-------------------------------------------------------------------------------
realm-2.com
nasreq gx 10 1 dra-1.realm-2.com
realm-2.com
nasreq gx 20 2 dra-2.realm-2.com
-------------------------------------------------------------------------------
No. of routes: 2
===============================================================================
The realm routing table is populated based on the Origin-Realm AVP and Application-Id AVP received in the Capability Exchange Answer message together with the configured index and preference values.
Note that Diameter answer messages do not rely on peer or realm routing table lookups. Answers are forwarded over the same route in the reverse direction of the matching requests. This is achieved with a transactional cache in each traversed Diameter node, using the Hop-by-Hop AVP to match requests with answers.
When enabling the peer (admin-state enable), the system tries to establish the transport TCP connection. Once the TCP session is up, the system starts a Diameter Capability Exchange using the configured Diameter identity (Origin-Host and Origin-Realm AVPs) and advertising support for all SR OS Diameter applications in Application-Id AVP's (NASREQ, Gx, and Gy). When the Origin-Host AVP in the received CEA message corresponds with the destination host configured for the peer (case insensitive) and at least one application in the CEA is common with the SR OS advertised applications, then the peer moves to the I-Open state (I from Initiator). An example of a Capability Exchange is illustrated in detail in the troubleshooting section.
Optionally, a connection and a watchdog timer can be configured in the Diameter node:
configure {
aaa {
diameter {
node "bng-gx.realm-1.com" {
connection {
timer 30
---snip---
}
peer index 1 {
connection-timer 30
watchdog-timer 30
---snip---
-
connection-timer
The connection timer or Tc timer controls the frequency at which a transport connection is attempted to be established. The default value is 30 seconds. This timer can be configured per node to be used by all peers or overridden per peer.
-
watchdog-timer
The watchdog timer controls the frequency at which Device-Watchdog-Request messages are transmitted to the peer, and is called the Tw timer in RFC 3539, Authentication, Authorization and Accounting (AAA) Transport Profile. A small timer results in a faster detection of a peer failure at the expense of generating more messages. The timer is configured per peer and its default value is 30 seconds.
A Python policy can be configured in the Diameter node to manipulate Diameter messages transmitted to and/or received on its peers.
configure {
aaa {
diameter {
node "bng-gy.realm-1.com" {
python-policy "py-diameter-1"
---snip---
Manipulating Diameter messages, such as changing the content or format of AVPs using Python is out of the scope of this chapter.
By default, Diameter messages are sent with a DSCP set to AF41. The DSCP value can be changed with the sgt-qos configuration:
# /configure router sgt-qos dscp application diameter dscp nc1
SR OS uses TCP as transport and the TCP destination port number is fixed to the standard Diameter base protocol port 3868. The source port is randomly chosen from the ephemeral port range.
Troubleshooting
The status and statistics of the Diameter peers can be verified with following show commands:
# /show aaa diameter-node "bng-gx.realm-1.com" peers
===============================================================================
Peers
===============================================================================
Host identity Status Default Preference Active
-------------------------------------------------------------------------------
dra-1.realm-2.com I-Open No 10 Yes
dra-2.realm-2.com I-Open No 20 Yes
-------------------------------------------------------------------------------
No. of peers: 2
===============================================================================
# /show aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-2.com"
===============================================================================
Peer "dra-1.realm-2.com"
===============================================================================
Index : 1
Status : I-Open
Administrative state : enabled
Active : Yes
Active applications : nasreq gx
Last disconnect cause : rebooting
Preference : 10
Default peer : No
Connection timer (s) : N/A
Watchdog timer (s) : 13
Pending messages : 0
Remote realm : realm-2.com
Remote IP address : 2001:db8:2:6::1
Remote TCP port : 3868
Remote Origin-State-Id : 1574235027
Local host identity : bng-gx.realm-1.com
Local realm : realm-1.com
Local IP address : 2001:db8::2
Local TCP port : 53734
Last management change : 11/19/2019 15:05:48
===============================================================================
# /show aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-2.com" statistics
===============================================================================
Peer "dra-1.realm-2.com"
===============================================================================
Message Sent Received
-------------------------------------------------------------------------------
Capabilities-Exchange-Request 7 0
Capabilities-Exchange-Answer 0 7
Disconnect-Peer-Request 1 4
Disconnect-Peer-Answer 4 1
Device-Watchdog-Request 1217 778
Device-Watchdog-Answer 778 1217
Application message request 0 0
Application message answer 0 0
Last cleared time: N/A
===============================================================================
To clear the peer statistics, use following command:
# /clear aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-2.com" statistics
Diameter debugging is split between node and application level:
debug
diameter
application
policy "diam-nasreq-1"
session-messages
exit
exit
node "bng-gx.realm-1.com"
peer "dra-1.realm-2.com"
peer-to-peer
exit
exit
exit
exit
In this chapter, the Diameter base protocol debugging for peer messages is explained, configured at the node level debug. When a Python script is active for the node, the debug messages are logged after Python processing.
To debug the Diameter base protocol messages for peer "dra-1.realm-2.com", use the following debug commands:
debug
diameter
node "bng-gx.realm-1.com"
peer "dra-1.realm-2.com"
peer-to-peer
exit
exit
exit
exit
The peer-to-peer option enables debug output for all Diameter base messages of the specified peer: Capabilities Exchange, Device Watchdog and Disconnect Peer messages. By default, error conditions are also logged in the debug output. Debug for error conditions can be disabled per Diameter node or per peer with the debug option no on-error. Errors reported at the node level include Diameter base errors that are unrelated to a peer, such as a routing problem for a Diameter application message. Errors reported at the peer level include all errors that occur after peer selection and peer connection errors.
Let's start with the peer connection in Closed state (remote end rebooting):
# /show aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-2.com"
===============================================================================
Peer "dra-1.realm-2.com"
===============================================================================
Index : 1
Status : Closed
Administrative state : enabled
Active : No
Active applications :
Last disconnect cause : rebooting
Preference : 10
Default peer : No
Connection timer (s) : 18
Watchdog timer (s) : N/A
Pending messages : 0
Remote realm : (Not Specified)
Remote IP address : (Not Specified)
Remote TCP port : (Not Specified)
Remote Origin-State-Id : (Not Specified)
Local host identity : bng-gx.realm-1.com
Local realm : realm-1.com
Local IP address : (Not Specified)
Local TCP port : (Not Specified)
Last management change : 11/19/2019 15:05:48
===============================================================================
The Connection timer(s) field in above peer details output show that in 18 seconds, a new connection attempt will be made, followed by a Capabilities Exchange when successful. The transmitted Capabilities-Exchange-Request (CER) and received Capabilities-Exchange-Answer (CEA) are shown in the debug output:
233997 2019/11/20 19:17:16.271 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Transmission
Transmit: "CER"
Application policy: N/A
Node: "bng-gx.realm-1.com"
Received peer: N/A
Transmit peer: "dra-1.realm-2.com"
Python policy: N/A
Header
ver 1 len 284 flags R------- code 257
app-id 0 hbh-id 19864 e2e-id 3486524428
AVPs
origin-host (264) -M------ [26]
data [18] (DiameterIdentity) : bng-gx.realm-1.com
origin-realm (296) -M------ [19]
data [11] (DiameterIdentity) : realm-1.com
host-ip-addr (257) -M------ [26]
data [18] (Address) : ipv6 2001:db8::2
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 6527
product-name (269) -------- [13]
data [5] (UTF8String) : SR-OS
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 1 : Nasreq
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 4 : Gy
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 16777238 : Gx
vend-specific-appl-id (260) -M------ [32]
data [24] (Grouped)
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 10415
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 4 : Gy
vend-specific-appl-id (260) -M------ [32]
data [24] (Grouped)
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 10415
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 16777238 : Gx
supported-vendor-id (265) -M------ [12]
data [4] (Unsigned32) : 3561
supported-vendor-id (265) -M------ [12]
data [4] (Unsigned32) : 6527
supported-vendor-id (265) -M------ [12]
data [4] (Unsigned32) : 10415
supported-vendor-id (265) -M------ [12]
data [4] (Unsigned32) : 13019
firmware-revision (267) -------- [12]
data [4] (Unsigned32) : 191001
233998 2019/11/20 19:17:16.275 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Reception
Receive: "CEA"
Application policy: N/A
Node: "bng-gx.realm-1.com"
Received peer: "dra-1.realm-2.com"
Transmit peer: N/A
Python policy: N/A
Header
ver 1 len 240 flags -------- code 257
app-id 0 hbh-id 19864 e2e-id 3486524428
AVPs
result-code (268) -M------ [12]
data [4] (Unsigned32) : 2001 : DIAM_RESCODE_SUCCESS
origin-host (264) -M------ [25]
data [17] (DiameterIdentity) : dra-1.realm-2.com
origin-realm (296) -M------ [19]
data [11] (DiameterIdentity) : realm-2.com
host-ip-addr (257) -M------ [26]
data [18] (Address) : ipv6 2001:db8:2:6::1
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 6527
product-name (269) -------- [28]
data [20] (UTF8String) : PythonDiameterAgent1
origin-state-id (278) -M------ [12]
data [4] (Unsigned32) : 1574277432
supported-vendor-id (265) -M------ [12]
data [4] (Unsigned32) : 10415
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 1 : Nasreq
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 16777238 : Gx
vend-specific-appl-id (260) -M------ [32]
data [24] (Grouped)
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 10415
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 16777238 : Gx
firmware-revision (267) -------- [12]
data [4] (Unsigned32) : 1
The result of the successful Capabilities Exchange is that the peer moved to the I-Open state, ready to forward NASREQ and Gx application messages:
# /show aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-2.com"
===============================================================================
Peer "dra-1.realm-2.com"
===============================================================================
Index : 1
Status : I-Open
Administrative state : enabled
Active : Yes
Active applications : nasreq gx
Last disconnect cause : rebooting
Preference : 10
Default peer : No
Connection timer (s) : N/A
Watchdog timer (s) : 9
Pending messages : 0
Remote realm : realm-2.com
Remote IP address : 2001:db8:2:6::1
Remote TCP port : 3868
Remote Origin-State-Id : 1574277432
Local host identity : bng-gx.realm-1.com
Local realm : realm-1.com
Local IP address : 2001:db8::2
Local TCP port : 55199
Last management change : 11/19/2019 15:05:48
===============================================================================
The Watchdog timer(s) field in preceding peer details output shows that in 9 seconds, a Device Watchdog exchange will be initiated. The transmitted Device-Watchdog-Request (DWR) and received Device-Watchdog-Answer (DWA) are shown in the debug output:
233999 2019/11/20 19:17:44.268 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Transmission
Transmit: "DWR"
Application policy: N/A
Node: "bng-gx.realm-1.com"
Received peer: N/A
Transmit peer: "dra-1.realm-2.com"
Python policy: N/A
Header
ver 1 len 68 flags R------- code 280
app-id 0 hbh-id 19865 e2e-id 3486524431
AVPs
origin-host (264) -M------ [26]
data [18] (DiameterIdentity) : bng-gx.realm-1.com
origin-realm (296) -M------ [19]
data [11] (DiameterIdentity) : realm-1.com
234000 2019/11/20 19:17:44.271 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Reception
Receive: "DWA"
Application policy: N/A
Node: "bng-gx.realm-1.com"
Received peer: "dra-1.realm-2.com"
Transmit peer: N/A
Python policy: N/A
Header
ver 1 len 92 flags -------- code 280
app-id 0 hbh-id 19865 e2e-id 3486524431
AVPs
result-code (268) -M------ [12]
data [4] (Unsigned32) : 2001 : DIAM_RESCODE_SUCCESS
origin-host (264) -M------ [25]
data [17] (DiameterIdentity) : dra-1.realm-2.com
origin-realm (296) -M------ [19]
data [11] (DiameterIdentity) : realm-2.com
origin-state-id (278) -M------ [12]
data [4] (Unsigned32) : 1574277432
Now let's try to bring up the peer in the node bng-gy.realm-1.com:
# /show aaa diameter-node "bng-gy.realm-1.com" peers
===============================================================================
Peers
===============================================================================
Host identity Status Default Preference Active
-------------------------------------------------------------------------------
ocs.realm-1.com Closed No 50 No
-------------------------------------------------------------------------------
No. of peers: 1
===============================================================================
Debug is enabled at the peer level for error conditions without the peer-to-peer option. Failures are reported, but not all transmitted and received peer messages.
debug
diameter
node "bng-gy.realm-1.com"
peer "ocs.realm-1.com"
exit
exit
exit
exit
The Diameter server is provisioned with an origin host different from the configured destination host for the peer, resulting in a failure and peer reset:
234330 2019/11/22 14:57:32.272 UTC minor: DEBUG #2001 management DIAMETER
DIAMETER: Failure
Receive: "CEA"
Application policy: N/A
Node: "bng-gy.realm-1.com"
Received peer: "ocs.realm-1.com"
Transmit peer: N/A
Python policy: N/A
Result code: "DIAM_RESCODE_INVALID_AVP_VALUE"
Error message: "mismatch with locally stored information"
Failed AVP:
origin-host (264) -M------ [27]
data [19] (DiameterIdentity) : ocs.wrong-realm.com
Message:
Header
ver 1 len 176 flags -------- code 257
app-id 0 hbh-id 6050 e2e-id 3486524894
AVPs
result-code (268) -M------ [12]
data [4] (Unsigned32) : 2001 : DIAM_RESCODE_SUCCESS
origin-host (264) -M------ [27]
data [19] (DiameterIdentity) : ocs.wrong-realm.com
origin-realm (296) -M------ [23]
data [15] (DiameterIdentity) : wrong-realm.com
host-ip-addr (257) -M------ [14]
data [6] (Address) : ipv4 192.99.3.0
vendor-id (266) -M------ [12]
data [4] (Unsigned32) : 6527
product-name (269) -------- [28]
data [20] (UTF8String) : PythonDiameterServer
origin-state-id (278) -M------ [12]
data [4] (Unsigned32) : 1574434643
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 4 : Gy
firmware-revision (267) -------- [12]
data [4] (Unsigned32) : 1
234331 2019/11/22 14:57:32.272 UTC minor: DEBUG #2001 management DIAMETER
DIAMETER: Peer Reset
Node: "bng-gy.realm-1.com"
Peer: "ocs.realm-1.com"
Reason: "failed to parse received CEA"
Events
Following events are defined for the Diameter base protocol:
=======================================================================
Application
ID# Event Name P g/s Logged Dropped
-----------------------------------------------------------------------
2007 tmnxDiamMessageDropped MI thr 0 0
2008 tmnxDiamNdPeerStatActiveChanged MI thr 46 0
=======================================================================
The tmnxDiamNdPeerStatActiveChanged event is generated when the state of a Diameter peer toggles between active / not active:
38080 2019/11/22 14:52:02.269 UTC MINOR: DIAMETER #2008 management peer state change
"DIAMETER node bng-gy.realm-1.com, peer ocs.realm-1.com is active"
The tmnxDiamMessageDropped event is generated when Diameter base drops a malformed message.
Conclusion
As a result of fixed mobile network convergence, Diameter is used in fixed access networks as an alternative for Radius based AAA. Diameter peering provides reliable and secure transport with peer redundancy. Its functionality is defined in a base Diameter protocol specified in RFC 6733. Various applications can be layered on top of base Diameter and they can utilize the robust transport capabilities that Diameter provides.