Configuring the Server Pools

Consider the configuration in the following figure:

Server Pool S6a Reference Configuration (Servers Adjacent to DEA)

In this configuration, the HSS and MME nodes in realm local.com all advertise support for the S6a application. To correctly transmit realm-routed requests to the HSS nodes (and not to the MME nodes), the dea.local.com has to be configured to know which entities are servers (in this case, the HSS nodes). This configuration is done by provisioning a Server Pool for the S6a application within dea.local.com.

Typical configuration steps are as follows:

1. Create a Server Pool object with the appropriate load balancing (see To create a Server Pool)
   
   

2. Create one Member Diameter ID object for each server.

   Tip

   If the Member Diameter ID is adjacent to the local node, assign a relative weight for load balancing. For Least Loaded Load Balancing, use an estimate of the server capacity in messages per second (see To create Member Diameter ID).

3. Create one Pool Application ID object for each Diameter Application ID that uses the same set of servers and the same Server Pool configuration (see To create Pool Application ID)
   
   

4. Activate the Server Pool (see To activate or deactivate a Server Pool)

Example 1: S6a Application - Servers are Adjacent

Consider again the configuration in Figure Server Pool S6a Reference Configuration (Servers Adjacent to DEA)  where all servers (HSS nodes) are adjacent to dea.local.com.

In this scenario, the Server Pool configuration might look as follows:

Example 2: S6a Application - Servers are Not Adjacent

Consider the configuration in the following figure:

Server Pool S6a Reference Configuration (Servers Not Adjacent to DEA)

In this configuration, the Diameter IDs of the servers should still be configured since routing decisions can depend on the Origin-Host AVP to determine if a message is transmitted to servers or clients. However, the weight of the servers is no longer relevant since the slf.local.com node does the server selection.

In this scenario, the Server Pool configuration might look as follows, which is essentially the same as in Example 1: S6a Application - Servers are Adjacent, but with the server weights set to 0 to indicate they are nonadjacent.

Example 3: Routing of S6a Requests within the Local Realm

In this section, an example is provided for DSC Default Routing with a Server Pool Configuration.

Consider the configuration in the following figure:

Sample Network for Default Routing Using Server Pools for S6a Traffic

In the network configuration depicted in the preceding illustration, MME1 and 2 and HSS 1 and 2 send messages using DSC 1. All nodes are in the same Diameter realm.

This routing may be performed using dsc_default routing, provided a Server Pool is provisioning for the S6a Application ID (see Creating Application ID Definitions) with the HSS Diameter IDs (see Configuring DSC Nodes) and Member Diameter IDs (see Configuring Member Diameter IDs).

The example in the preceding illustration depicts the DSC configured with the following Server Pool attribute values.

The Server Pool configuration provided in the preceding table results in the following traffic flow:

• A Realm-Routed Request (that contains no Destination-Host AVP) from MME1 arrives at the DSC and is routed to one of the HSSs.  MME2 is not considered a viable next hop because of the Server Pool configuration.
  
  
• A Request from an MME to an HSS that contains a Destination-Host AVP is routed to that HSS only.
  
  
• A Request from an HSS to an MME must contain a Destination-Host AVP. Such a Request is only sent to the identified MME (as per 3GPP TS 29.272 “Requests initiated by the HSS towards an MME or SGSN shall include both Destination-Host and Destination-Realm AVPs.”).

Example 4: Routing of S6a Requests within the Local Realm with Two DSC Nodes

In this section, an example is provided for DSC Default Routing with a Server Pool Configuration.

 Consider the configuration in the following figure:

Sample Network for Default Routing Using Server Pools for S6a Traffic with Two DSC Nodes

In the network configuration depicted in the preceding illustration, DSC 1 and DSC 2 are configured as in Figure Sample Network for Default Routing Using Server Pools for S6a Traffic, but with the additional ADN between the DSC Nodes.

This scenario results in the following traffic flow:

• A Realm-Routed Request (that contains no Destination-Host AVP) from MME1 arrives at DSC1 and is routed to one of the HSSs.  MME2 is not considered a viable next hop because of the Server Pool configuration.  If both HSSs are unavailable, the Request may be routed to DSC2.  DSC2 examines the origin host and determines from the Server Pool configuration that the message must be routed to HSS1 or HSS2.  If both HSSs are unavailable, an Answer DIAMETER_UNABLE_TO_DELIVER is returned.  DSC2 does not route the message back to DSC1 (incoming ADN).
  
  
• A Request from an MME to an HSS that contains a Destination-Host AVP is routed to that HSS only.  If the HSS is not available, the request may be relayed using the other DSC.
  
  
• A Request from an HSS to an MME must contain a Destination-Host AVP. Such a Request is only sent to the identified MME (as per 3GPP TS 29.272 “Requests initiated by the HSS towards an MME or SGSN shall include both Destination-Host and Destination-Realm AVPs.”).  If the target MME is not available directly, the request may be relayed using the other DSC.