Egress Answer messages are always routed according to the Connection-Id and Diameter Hop-By-Hop-Id of the Request they are answering.
For the P-DRA function, when a binding capable session initiation message (CCR-I) arrives for an IMSI that is not already bound to a PCRF, the P-DRA function selects a PCRF from the list of adjacent PCRFs configured on Policy and Charging -> Configuration -> Policy DRA -> PCRFs GUI page. This list of PCRFs generally contains only PCRFs that are local to the site with the P-DRA node. PCRFs that are local to the PCA node's mate should generally not be included. The reason to include only local PCRFs is to avoid the extra latency associated with selection of a PCRF separated across a WAN from the policy client that initiated the session.
If the PCRF has different hostnames for different 3GPP interfaces (e.g. Gx, Rx, Gxx, S9), only the binding capable hostnames should be configured on the Policy and Charging -> Configuration -> Policy DRA ->PCRFs GUI page.
Policy DRA uses a round-robin selection algorithm to distribute new bindings across the set of configured PCRFs. The round-robin algorithm runs independently on each DA-MP server, so predicting the next PCRF that will be used is difficult on a PCA node that has policy client connections to multiple DA-MP servers. In addition, the round-robin selection algorithm is executed for each CCR-I received, causing the next PCRF to be updated, even if the CCR-I is for a subscriber that already has a binding.
A binding becomes finalized when a successful CCA-I is received from a PCRF for a given subscriber. At this point, all Policy sessions for that subscriber must be routed to that PCRF Peer Node, or a Peer Node that shares state with the bound Peer Node. The subscriber remains bound to this PCRF until all of the subscriber’s binding capable sessions (Gx, Gxx, S9) are terminated.
The architecture for many PCRFs is such that a single Diameter host is not a single point of failure for a subscriber’s Policy sessions. This is generally accomplished by designating a set of Diameter hosts that all share a common database and can therefore all access the subscriber’s Policy data and Resource usage.
For the P-DRA function, when the PCRF name is not topology hidden, the policy client is expected to learn the PCRF name from the Origin-Host and Origin-Realm of the answer to the session initiation request (e.g. CCA-I or AAA). This PCRF name should be used as the Destination-Host and Destination-Realm of all subsequent in-session requests originated by the policy client.
Policy clients that are proxy-compatible (can learn the PCRF name) allow P-DRA to host-route in-session requests without the need for any binding or session database lookup. This behavior is desirable because it reduces the cost of the P-DRA by reducing the number of SBR servers needed to support a given Diameter traffic load.
There are, however, policy clients that are not proxy-compatible. Many of these always omit the Destination-Host AVP from requests, or worse, include the Destination-Host AVP with the PCA Diameter hostname. In order to support such policy clients, the P-DRA function must be configured to add or replace the Destination-Host and Destination-Realm of all requests with the PCRF that the subscriber is bound to. This can be accomplished by setting table PdraEngdValues entry CheckSessionForAllBindCapMessages value to the number one (1). This value defaults to zero (0), meaning that the P-DRA function does not replace the Destination-Host for in-session messages by default. Policy clients that are not proxy-compatible can also be accommodated by enabling topology hiding
When topology hiding is enabled, the PCRF name is hidden from the applicable policy client. If the PCRF name is hidden from the policy client, obviously the policy client cannot use the PCRF as the Destination-Host and Destination-Realm in its in-session requests. When topology hiding is in force for a policy client, PCA must route in-session requests to the bound PCRF by performing a session record lookup and using the PCRF information stored in the session record.
Use of topology hiding is expensive in terms of the increased stack event processing required and the increased latency required to lookup the bound PCRF in the session record. For these reasons, topology hiding should be scoped as narrow as possible. For example, if topology should be hidden from only a few policy clients, choose the per policy client topology hiding scope instead of choosing to hide topology from all policy clients.
Topology hiding can also be used to "work around" a policy client that does not have the ability to learn the PCRF name (i.e. is not proxy-compatible). Turning on topology hiding for a subset of policy clients is more efficient than using the CheckSessionForAllBindCapMessages option
If the "Single OCS Pool" mode is configured, OC-DRA removes the Destination-Host AVP, if present, from the session initiation request and forwards the message to DRL. PRT/RL will be used to route the request message to one of the OCS servers connected to the DSR based on some round-robin load balance algorithm.
If the "Multiple OCS Pools" mode is configured, OC-DRA forwards the session initiation request without any modification to DRL. DRL may use the Destination-Host info in the request message to match the PRT/RL to route the message to an OCS pool and then an OCS within the pool using priorities/weights configured in the Route List selected via PRT.
When PCA is deployed in large networks with multiple PCA mated pairs, the DRL routing tables can be greatly simplified by employing some simple naming conventions. For example, naming all clients and PCRFs/OCSs local to a particular PCA node such that they start with a common prefix allows PRT rules like "Destination-Host Starts-With xxx", where xxx is the site prefix for that PCA node. The "Starts-With" rule will point to a route list that routes to the PCA node where the equipment is located. Then if a new client or a PCRF/OCS is added at a given PCA node, routing changes are needed only at that node and that node's mate, which have peer node entries and Diameter connections (i.e. are adjacent) to the new client or PCRF/OCS. PCA nodes that are non-adjacent do not require any routing updates.