In this section:

Overview

The functionality of the Diameter Redirect Agent is to provide one or more individual hosts to the message sender as the destination of the redirected message. This message redirection is referred to as Host-based Redirection as described in RFC 6733 (refer to Supported Standards).
     

The functionality of a Diameter Realm-based Redirect Server is to redirect messages to an alternate domain without specifying a host or a list of hosts. This message redirection is referred to as Realm-based Redirection as described in RFC 7075 (refer to Supported Standards).

The Diameter message flow is similar to the message flow for a Diameter Redirect Agent, but while a Diameter Redirect Agent returns a list of one or more individual of hosts, a Diameter Realm-based Redirect Server returns a list of Diameter realms (see Host-based Redirect Message Flow and Realm-based Redirect Message Flow, respectively)

Consider the following for Realm-based Redirection:

  • The DSC does not include a Redirect-Host-Usage Attribute Value Pair (AVP) when sending Diameter Realm Redirect Indications.   

  • All Diameter Realm-based Redirect Indications are assumed to only apply to the current Diameter Request.

  • Your system must be upgraded to 17.0.0.R00 to obtain this feature.

Caution
Realm-based and Host-based Redirect should not be applied to messages that have already been subject to session binding. Otherwise, some unexpected system behavior is possible.

Before you can start provisioning either the Host-based or Realm-based Redirection, it is assumed that you have planned your network (refer to Before Configuring the Ribbon DSC) and provisioned the basic and advanced (if required) configuration tasks (refer to DSC Diameter Basic Configuration Tasks, Configuring the Ribbon DSC, and Configuring DSC Advanced Features, respectively).

Note

If you are configuring a Diameter Edge Agent (DEA), the routing tables should be provisioned before activating the ADN connections or you might start receiving traffic before provisioning message routing. No traffic loss occurs in this scenario (the previous hop should re-transmit the message on error), but this provisioning is inefficient

Common Host-based/Realm-based Redirect Record Behavior 

The following three types of Routing Result Table Records are supported on the DSC:  

  • RELAY
  • REDIRECT
  • REALM-REDIRECT

If the records in a Result Table are sorted according to cost, consecutive records of the same type form a group of records that work together (that is, a Record Group).

A Record Group can be sorted as follows:

  • Relay Record Group - contains RELAY records
  • Redirect Record Group - contains REDIREC records
  • Realm Redirect Record Group - contains REALM_REDIRECT records 

The DSC Result Table only supports five combinations of record groups:

  • a Relay Record Group only
  • a Redirect Record Group only
  • a Realm Redirect Record Group only
  • a Relay Record Group followed by a Redirect Record Group
  • a Relay Record Group followed by a Realm Redirect Record Group

Any entries outside these five combinations are ignored when the DSC is handling the Result Records.

For detailed information about configuring Realm Routing Tables and Records, refer to Configuring Realm Routing Tables and Records.

Host-based Redirect Message Flow

The following figure shows the Host-based Redirect message flow.

Host Redirect Message Flow


To provision a Host-based Redirect Record   

  1. Provision the Routing Table so that the message encounters the Result Table Record.
  2. Provision the Redirect Record in the Result Table.
Note

On the indication receiving side, the user has to ensure that the redirect record value is a valid Adjacent Diameter Node (ADN) entity on the diameter proxy node so that it could route the original request using the redirect host

Realm-based Redirect Message Flow 

The following figure shows the Realm-based Redirect message flow.

Realm Redirect Message Flow


To provision a Realm-based Redirect Record 

  1. Make sure that the Realm Redirect Record value is the alias of an existing Realm Definition. 
  2. Provision the Routing Table so that the message encounters the Result Table Record.
  3. Provision the Realm Redirect Record in the Result Table so the Record Value of a Result Record type REALM_REDIRECT is the alias of an existing Realm Definition. For an example, see the following figure.


Configuring and Handling Realm-based Redirect Indications

Realm Redirect Indication in this document refers to a Diameter message with the E-bit set and with Result-Code 3011 as defined in RFC 7075. The handling of received Realm Redirect Indication messages can be specified at the DSC Node using the attribute Receive Realm Redirect Indications (see Realm Redirect Indications) or can be specified per message by using the Modification Record Command attribute (see Modification Record Command). 

Configuring the Realm Redirect Indications Attribute

The values for the Realm Redirect Indication attribute can be as follows:

  • DISABLED -  the received DIAMETER_REALM_REDIRECT_INDICATION is treated as a DIAMETER_UNABLE_TO_DELIVER
      
  • RFC 7075 - the received DIAMETER_REALM_REDIRECT_INDICATION is treated as specified in RFC7075 where it will forward the original request using the new realm provided in the INDICATION message

  • PASSTHROUGH - the DIAMETER_REALM_REDIRECT_INDICATION is forwarded to the incoming Adjacent Diameter Node (ADN) with the appropriate hop-by-hop ID. The Origin-Host and Origin-Realm AVPs in the DIAMETER_REALM_REDIRECT_INDICATION are unchanged.

The Realm Redirect Indication attribute default value set to DISABLED.

Note

If a Diameter Agent cannot route the request to the new realm, this agent returns a Diameter Realm Redirect Indication to the previous node (towards the client).

Configuring Realm Redirect Indication


Configuring the Modification Record Command Attribute

The handling of received Realm Redirect Indications can also be specified per message by using one of the following Modification Record attribute values:

  • receive-realm-redirect-indications DISABLED
  • receive-realm-redirect-indications PASSTHROUGH
  • receive-realm-redirect-indications RFC7075

Because Realm Redirect Indications should only be generated for applications that support them, it is recommended that you leave the Receive Realm Redirect Indications attribute default value set to DISABLED, and explicitly enable the handling of Realm Redirect Indications only for applications that support them using the Modification Table Record (refer to Configuring Modification Tables and Records).

Modification Record Command


Configuring Realm-based Redirection

Execute the steps in the following two procedures to configure Realm-Based Redirection. 

To enable or disable the Receive Realm Redirect Indication

  1. From the Main Menu, click DSC.
  2. Click the DSC Instance ID for the DSC Instance for which you want to receive the Realm-based Redirect Indication.
  3. Click DSC Nodes.
  4. Click the required DSC Node.
  5. Configure the Receive Realm Redirect Indications attribute as required.

To configure a Result record for Realm-based Redirect

  1. From the Main Menu, click DSC.
  2. Click the DSC Instance ID for which you want to create a Result record.
  3. Click DSC Routing Tables.
  4. Click the required Result table under the Result Table Selection heading.
  5. Click Create.
  6. Configure the Result Routing record as required (REALM_REDIRECT).


Note

To delete a Realm Routing record, click X in the Realm Routing Record Selection screen in the same line in which this record appears.