Relay Agent Message Flows
Introduction
The JSLEE Diameter service, acting as a Diameter Agent will act as a Diameter relay and/or Diameter proxy between peers and in doing so can perform a variety of actions related to message manipulation and redirection.
This section of the overall Diameter Gateway documentation covers the most frequently seen Diameter relay and proxy scenarios that may be encountered and how the JSLEE Diameter service handles these.
Basic Diameter Relay
As the simplest form of an Agent, the service may be tasked with relaying Diameter requests between two peers. However, even such a straightforward Agent deployment requires careful consideration.
- The JSLEE must accept incoming authentication requests from Diameter Peer(s) over which Diameter requests will be received.
- The JSLEE must initiate and maintain authenticated connections with Diameter Peer(s) over which the relayed Diameter requests will be sent.
The most basic Diameter relay will perform no logic beyond routing to the correct endpoint, and onward to the correct host:
Deployment of a Diameter relay of this configuration requires JSLEE services for both inbound and outbound Diameter. The same service can be used for both - however for clarity it is preferred to use separate service definitions:
{
"applications": {
"diam-in-1": {
"handler": "nz.co.nsquared.slee.diameter.DiameterVerticle",
"configuration": {
"endpoints": [
{
"interface": "127.0.0.1",
"port": 3868,
"origin-host": "slee-01-in.jslee.nsquared.io",
"origin-realm": "jslee.nsquared.io",
"is-server": true,
"applications": [
{
"class-path": "nz.co.nsquared.slee.diameter.application.agent.Agent"
// additional config to be documented
}]}]}},
"diam-out-1": {
"handler": "nz.co.nsquared.slee.diameter.DiameterVerticle",
"configuration": {
"endpoints": [
{
"port": 3868,
"name": "alpha",
"interface": "10.9.8.90",
"remote-server": "10.42.2.172",
"origin-realm": "jslee.nsquared.io",
"origin-host": "slee-01-out.jslee.nsquared.io",
"is-server": false,
"applications": [
{
"class-path": "nz.co.nsquared.slee.diameter.application.agent.Agent"
}]},
{
"port": 3868,
"name": "beta",
"interface": "10.9.8.90",
"remote-server": "10.42.2.48",
"origin-realm": "jslee.nsquared.io",
"origin-host": "slee-01-out.jslee.nsquared.io",
"is-server": false,
"applications": [
{
"class-path": "nz.co.nsquared.slee.diameter.application.agent.Agent"
}]}]}}}}
This configuration will start two JSLEE services, diam-in-1
and diam-out-1
:
diam-in-1
will listen on the loopback interface, on port 3868. As it is defined as a server, it will not initiate any connections. It will accept all incoming connections where a capabilities exchange can be completed.diam-out-1
will connect to two remote Diameter peers using the10.9.8.90
interface. It will maintain these connections as best it can.
Additionally:
- Each endpoint is configured with the
Agent
application. This causes the capabilities exchange between the JSLEE and any peer it connects to use the Diameter Relay application ID. - The inbound diameter service explicitly defines its
Origin-Host
andOrigin-Realm
. The endpoint name (as used internally) is derived from theOrigin-Host
and will beslee-01-in
. In contrast, theOrigin-Host
andname
are defined for the outbound connections, as both outbound endpoints use the sameOrigin-Host
, but must be named differently for unique JSLEE addressing. - If any Diameter “request” messages are received by either endpoint maintained by the
diam-out-1
interface, it will respond with a DIAMETER_UNABLE_TO_DELIVER error, as no routing rules exist. Note that this might happen if the Alpha and Beta peers were to sendRe-Authorization
requests. This limitation could be removed by including routing rules into each of thediam-out-1
endpoints. - The
diam-in-1
service supports as many incoming peers as required, with the inbound Diameter service maintaining connectivity to each independently, and handling each request message independently. - The
diam-out-1
service will maintain a single connection to each named peer.
Diameter Relay by Realm
Extending the basic Diameter relay configuration, the Agent can relay to the
appropriate Destination-Host
based on the Destination-Realm
in incoming messages.
This is the most likely relay configuration required, and allows the JSLEE to
determine the available Diameter Peer within each Diameter realm it maintains a
connection to:
Deployment of a Diameter relay of this configuration requires also JSLEE services for both inbound and outbound Diameter, and the configuration is only slightly changed to the basic relay case:
In addition to the features of the simple relay configuration, with Realm-based relay the solution enables:
- Setting (by the Agent) the
Destination-Host
based on theDestination-Realm
. Host selection will be based on the active (accessible) hosts maintained by the JSLEE for the realm of the request. - The
Origin-Host
of the Answer message will be passed on to the originating Diameter peer. The peer may use this as theDestination-Host
for future requests on the same Diameter session to bypass the Realm -> Host selection mechanism of the JSLEE Diameter relay. - Alternatively (and optionally) the “sticky session” feature may be enabled in
the Agent. Sticky sessions ensure that if the origin peer does not use the
Destination-Host
in subsequent messages for the same session. the JSLEE agent will make sure the same host is used anyway.
Diameter Routing
By default, the Agent will perform relay functionality based on the Diameter-Host
or Diameter-Realm
provided by incoming Diameter requests. However, in many
scenarios the final Diameter realm should be selected by the JSLEE agent based on AVP
information. The most frequently seen example of this is Realm selection based
on Subscription-ID
(or User-Identifier
).
To achieve this, the AVP-replacement feature of the Agent can be used to
replace the Destination-Realm
and Destination-Host
with the value provided
by a lookup:
The configuration for this setup is the same as for Diameter relay by Destination-Realm
,
with the addition of configuration for AVP replacement:
{
"avps": {
"Destination-Realm": {
"lookup-avp": "Subscription-Id[0].Subscription-Id-Data",
"cache": "ported_numbers"
},
"Destination-Host": null
}
}
For lookup of the realm, a cache is expected to be configured within the agent application itself.
Note:
- The
Destination-Host
is cleared, so that the relay logic to select a host based on the realm will apply during the relay processing the Agent application does.