The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
CPS Diameter Routing
Agent (vDRA) is the functional element in a network that routes messages to the
destination node based on routing algorithms.
CPS vDRA is primarily
responsible for routing messages and sending responses back to the origin node.
CPS vDRA is compliant
with IETF RFC 3588 and 3GPP 29.212 and 29.213 message AVPs.
Functions of
DRA
DRA performs the
following functions in the network:
Peer Aggregation:
Provides an
aggregation point to eliminate full mesh of endpoint peer connections.
Addition of
endpoint does not require reconfiguration of endpoints. Requires only the
configuration of a new endpoint on DRA.
Intelligent
Routing:
Provides
intelligent load balancing behavior for endpoints (PGW, AF).
Endpoints
typically only route to primary/secondary peer connections.
Route requests
to servers (PCRF, OCS) based on content of Diameter AVPs (Called-Station-ID,
IPv4 Address, IPv6 Address and IMSI-APN combined).
Weighted
routing of requests to diameter servers (PCRF, OCS).
Binding:
Route requests
for related diameter sessions to the same Diameter server (PCRF, OCS). For
example, DRA binds Gx and Rx to the same IP session using the framed IPs.
Relay:
DRA provides
mechanism to relay request to another DRA. In certain cases, when route for the
request is found on a remote DRA, the request is relayed to the remote DRA.
CPS vDRA
Architecture
The following figure
illustrates the components of CPS vDRA architecture.
DRA Director is
stateless node. DRA Director has diameter stack running on it, which connects
to the external network functions (for example, PCEF, PCRF, AF). DRA Director
receives request messages from origin peer, applies routing algorithm, forwards
messages to the destination peer. DRA Director then gets answer messages for
the requests, which are forwarded back to the origin peer.
DRA Processor is also
stateless node that interacts with session and binding databases in the
persistence tier to store session and bindings.
DRA Database is used
to store bindings and sessions, with MongoDB database running on them. DRA
Database uses MongoDB database sharding to distribute data among multiple
databases. MongoDB replicates data across multiple databases within the replica
set to provide high availability.
Each of these tiers
can be scaled horizontally by deploying more virtual machines.
Types of CPS
vDRA
CPS vDRA can be deployed as IMS or Policy or a combination of both.
Policy DRA is a functional element that supports Gx, Rx, Gy, Sy, and Sd diameter interfaces.
Policy DRA has a binding function that ensures diameter messages for Gx and Rx sessions for the same IP-CAN session are routed
to the same PCRF when multiple and separately addressable PCRFs have been deployed.
IMS DRA is a functional element that supports many diameter interfaces including S6a/S6d, S6b, Sh, Cx, SLh, SLg, SWm, SWx,
SWa, and STa.
IMS DRA supports SLF-based routing to ensure Diameter messages are routed to an HSS and AAA server that can provide service
for a UE based on a subscriber key (that is, IMSI or MSISDN).
Combination DRA is a functional element that supports both Policy DRA and IMS DRA functionality.