Configuring AVP Alias Definitions and Routing Tables

As described in Configuring AVP Alias Definitions, an AVP Alias is used to describe an AVP that is possibly nested or a set of AVPs within a message. Nested AVPs are similar to un-nested (single) AVPs with the exception that the data field of nested AVPs contains one or more AVPs.

The information in this section provides some examples for routing table provisioning using AVP Alias Definitions (see the following figure).

Network Configuration for the Examples in this Section

In this configuration scenario, you manage example.com, and you have a DSC Node named DEA with Diameter ID dea.example.com that provides access to other Diameter realms. Specifically, you reach some other realms (b.com, badnetwork.com, and not-a-badnetwork.com) through a third party gateway.relay.com.

Example 1: Realm-based Routing for Indirect Realms

In Example 1, dsc_default routing does not have enough information to know how to route messages from pcrf.example.com to pcrf.b.com. You can configure this routing information in two ways:

• provision a Realm Routing Table
  
  
• provision explicit routing tables

Perform the following steps to setup corresponding Routing Tables.

Step 1: Create an AVP Alias Definition.

Step 2: Create a Result Table.

Step 3: Create a Result Record.

Step 4: Create an AVP Routing Table.

Step 6: Configure the NO AVP Routing Record to return an error (every routeable message should have a Destination-Realm AVP).

Step 7: Create a VALUE STRING AVP Routing Record to send to b.com using ADN gateway.relay.com.

Step 8: Change the DSC Node DEA Initial Routing Table Name attribute from dsc_default to destrealm.

With this configuration

• messages with Destination-Realm b.com are relayed through gateway.example.com
  
  
• messages with other Destination-Realm AVP values use dsc_default routing
  
  
• messages with no Destination-Realm AVP return an error 3002 UNABLE TO DELIVER.

Example 2: Reject Messages that Transit Untrusted Realms

Example 2 further develops the routing tables from Example 1.

In this configuration scenario

• messages that have passed through Diameter nodes in badnetwork.com are rejected (an error message is returned to the sender).
  
  
• other messages use the same routing as in Example 1

Step 1: Create an AVP Alias Definition

Step 2: Create an AVP Routing Table

Step 3: Create the NO AVP Routing and DEFAULT Records

Step 4: Create an AVP Routing Record to reject messages that have gone through badnetwork.com

At this step of the provisioning, no traffic hits the new tables; therefore, we need to hook the new tables into the existing routing tables.

Step 5: Set DSC Node DEA Initial Routing Table Name attribute to rr-any

The conclusion for Example 2 is as follows.

• messages that have passed through diameter nodes in badnetwork.com return an error 3002 UNABLE TO DELIVER
  
  
• other nodes in the network are correctly populating Route-Record AVPs
  
  
• other messages use the routing from Example 1

Example 3: Share Routing Tables Between DSC Nodes

In this configuration scenario, you have DSC Nodes X and Y that have some common validation, so you want to use some tables to route messages from both nodes. After configuring the common tables, you should divide the message processing based on the DSC Node (for example, before selecting a Result Table).

This example uses the rr-any table for both node X and node Y. This example builds on the routing tables from Example 1 and Example 2. Although the routing table structure will change slightly, the messages from node X are all routed using the same criteria as in the previous example. Messages from node Y use the validation in the rr-any table, but then go to Result Table result-y.

Step 1: Create a Result Table.

Step 3: Create an Incoming ADN Routing Record that matches all ADNs from DSC Node X.

Step 4: Create an Incoming ADN Routing Record that matches all ADNs from DSC Node Y.

Step 5: At this step of the provisioning, no traffic hits split-by-node-name. Insert split-by-node-name to the existing tables from node X by setting the DEFAULT and NO AVP records in the rr-any table to have Next Table Name split-by-node-name.
 

Step 6: Add in traffic from node Y by setting DSC Node Y Initial Routing Table Name attribute to rr-any.

The conclusion for Example 3 is as follows:

• Now, traffic from node X hits the rr-any table to do some traffic validation.
  
  
• messages that pass the rr-any checks hit split-by-node-name and go to dest-realm, for the same routing as previously.
  
  
• Traffic from node Y hits the rr-any table, then split-by-node-name, then result-y.

Example 4: Vendor ID Replacement (Nested AVP)

Change the Vendor-ID AVP of all Vendor-Specific-Application-ID AVPs.

Step 1: Create an AVP Alias Definition

Step 2: Create an AVP Alias Definition

Step 3: Create Modification Table.

Step 4:Create Modification Record.

Step 5: Add Modification Table to an existing Routing Table or create a new one.