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.

Note:

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.

Figure 1. 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.

Figure 2. Diameter network topology

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:

  1. 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.

  2. 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:

    1. the peer with the lowest configured preference (default preference is 50)

    2. the peer with the lowest index

  3. 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.