In this section:
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).
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.
AVP Alias Definition | |
---|---|
Name | dest-realm |
AVP Name | Destination-Realm |
AVP Instance | FIRST |
Nested AVP Alias | (empty) |
Step 2: Create a Result Table.
Result Table | |
---|---|
Table Name | via-relay |
DSC Node Name | DEA |
Step 3: Create a Result Record.
Result Record | |
---|---|
Cost | 10 |
Record Type | RELAY |
Record Value | gateway.relay.com |
Step 4: Create an AVP Routing Table.
AVP Routing Table | |
---|---|
Table Name | dest-realm |
AVP Alias | dest-realm |
Search Type | EXACT MATCH |
Step 5: Configure the DEFAULT AVP Routing Record to use dsc_default routing.
AVP Routing Record | |
---|---|
Record Type | DEFAULT |
AVP Value | (empty) |
Modification Table Name | (empty) |
Next Table | dsc_error |
Step 6: Configure the NO AVP Routing Record to return an error (every routeable message should have a Destination-Realm AVP).
AVP Routing Record | |
---|---|
Record Type | NO AVP |
AVP Value | (empty) |
Modification Table Name | (empty) |
Next Table | dsc_error |
Step 7: Create a VALUE STRING AVP Routing Record to send to b.com using ADN gateway.relay.com.
AVP Routing Record | |
---|---|
Record Type | VALUE STRING |
AVP Value | b.com |
Modification Table Name | (empty) |
Next Table | via-relay |
Step 8: Change the DSC Node DEA Initial Routing Table Name attribute from dsc_default to destrealm.
DSC Node (DEA) | |
---|---|
Initial Routing Table Name | dest-realm |
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
AVP Alias Definition | |
---|---|
Name | rr-any |
AVP Name | Route-Record |
AVP Instance | ANY |
Nested AVP Alias | (empty) |
Step 2: Create an AVP Routing Table
AVP Routing Table | |
---|---|
Table Name | rr-any |
AVP Alias | rr-any |
Search Type | LONGEST FROM RIGHT |
Step 3: Create the NO AVP Routing and DEFAULT Records
AVP Routing Record | |
---|---|
Record Type | NO AVP |
AVP Value | (empty) |
Modification Table Name | (empty) |
Next Table Name | dest-realm |
AVP Routing Record | |
---|---|
Record Type | DEFAULT |
AVP Value | (empty) |
Modification Table Name | (empty) |
Next Table Name | dest-realm |
Step 4: Create an AVP Routing Record to reject messages that have gone through badnetwork.com
The leading "." in the AVP Value avoids false matches. Without the leading "." , messages from not-a-badnetwork.com would also be rejected.
AVP Routing Record | |
---|---|
Record Type | VALUE STRING |
AVP Value | .badnetwork.com |
Modification Table Name | (empty) |
Next Table Name | dsc_error |
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
DSC Node (DEA) | |
---|---|
Initial Routing Table Name | 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.
A Result Table can only apply to messages from one DSC Node (specified at the creation of the Result Table).
Step 1: Create a Result Table.
Result Table | |
---|---|
Table Name | result-y |
DSC Node Name | Y |
Step 2: Create an Incoming ADN Routing Table.
ADN Routing Table | |
---|---|
Table Name | split-by-node-name |
ADN Search Type | LONGEST FROM THE RIGHT |
Step 3: Create an Incoming ADN Routing Record that matches all ADNs from DSC Node X.
Incoming ADN Routing Record | |
---|---|
Record Type | VALUE |
DSC Node Name | X |
Adjacent Diameter Node | (empty) |
Modification Table Name | (empty) |
Next Table Name | dest-realm |
Step 4: Create an Incoming ADN Routing Record that matches all ADNs from DSC Node Y.
Incoming ADN Routing Record | |
---|---|
Record Type | VALUE |
DSC Node Name | Y |
Adjacent Diameter Node | (empty) |
Modification Table Name | (empty) |
Next Table Name | result-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.
DSC Node Y | |
---|---|
Initial Routing Table Name | 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
AVP Alias Definition | |
---|---|
Name | Vendor |
AVP Name | Vendor-Id |
AVP Instance | ANY |
Nested AVP Alias | (empty) |
Step 2: Create an AVP Alias Definition
AVP Alias Definition | |
---|---|
Name | VendorSpec |
AVP Name | Vendor-Specific-Application-Id |
AVP Instance | ANY |
Nested AVP Alias | Vendor |
Step 3: Create Modification Table.
Modification Table | |
---|---|
Name | VendorSpec Replace |
Step 4:Create Modification Record.
Modification Record | |
---|---|
Order | 1 to 100 |
Command | Replace-avp VendorSpec <avp avp-name="Vendor-Id" value-"1234"/> |
Step 5: Add Modification Table to an existing Routing Table or create a new one.