The Diameter Base Protocol is a successor of the Radius Protocol. It is designed to provide an extensible framework for any services that require the support of authentication, authorization, and accounting (AAA), across several networks. The Diameter Base Protocol, unlike the Radius Protocol, also enables new access control features while maintaining flexibility for further extension.
According to RFC 6733, the Diameter Base Protocol alone does not offer much functionality. The Diameter Base Protocol should be regarded as a standard transport and management interface for AAA applications that provide a well-defined functionality subset. To increase functionality, predefined AAA applications are added. An AAA application usually consist of new command code and AVP definitions that map the semantics of the application. One example of a predefined application is the Diameter Credit-Control. For further information, see RFC 4006.
The Diameter Workflow Operation
There are two Diameter agents in Usage Engine:
Diameter Stack
Diameter Request
Diameter Stack
The Diameter Stack agent manages transport, decoding, and encoding of Diameter input messages. In order for a workflow to act as a Diameter server, you must use the Diameter Stack agent. The Diameter Stack agent communicates with the workflow by using the UDR type called RequestCycleUDR. When a request message arrives to the stack, the message is decoded, validated, and turned into a UDR of the pre-generated UDR type, as specified in the Commands tab in Diameter Application Profile (2.3). This UDR is inserted into the RequestCycleUDRs Request field and routed through the workflow. By using the APL function udrCreate the Answer field is populated with an appropriate answer message, and then RequestCycleUDR is routed back to the stack agent, for transmission of the answer.
...
| Note | ||
|---|---|---|
| ||
|
Diameter Request
In order for a workflow to act as a Diameter client, you must use both the Diameter Request agent and the Diameter Stack agent. The Diameter Request agent simply references a Diameter Stack agent that is suitable for the outgoing route.
...
A Diameter Request workflow
Diameter Related UDR Types
You view the UDR types that are created by default in the Diameter agents (based on RFC 6733), in the UDR Internal Format Browser, in the Diameter folder. To open the browser, open an APL Editor. In the editing area right-click and select UDR Assistance.
...
| Note | ||
|---|---|---|
| ||
The BaseUDR and BaseCommand UDR types are internal and shall not be used in APL code. |
RequestCycleUDR
The Diameter Stack agent and Diameter Request agent communicate with the workflow by using the UDR type RequestCycleUDR. For more information, see the sections above, Diameter Stack, and Diameter Request.
...
Field | Description | |||||
|---|---|---|---|---|---|---|
Answer (BaseCommand (Diameter)) | This field is populated with an "answer message UDR", before routed back by the workflow to the Diameter Stack agent. For the Diameter Request agent it will work the reversed way: after the answer field has been populated by the agent, the RequestCycleUDR is routed to the workflow.
| |||||
AnswerReceivedTime (long) | A timestamp indicating when the client receives the answer in nanoseconds. | |||||
AnswerSentTime (long) | A timestamp indicating when the server sends the answer in nanoseconds. | |||||
Context (any) | This is an internal working field that can be used in the workflow configuration to keep track of and use internal workflow information related to the request, when processing the answer. An example for a proxy workflow including TCP/IP and Diameter agents: When sending the RequestCycleUDR to the Diameter Request agent, the input TCPIPUDR is saved in the Context field. When the response is received from the Diameter agent, the TCPIPUDR can be read from the Context field and this TCPIPUDR can be used to send back the response to the TCP/IP agent. | |||||
ExcludePeers (list<string>) | You can populate this field with a list a list of peers, identified by their hostnames. When Round Robin is selected as the Realm Routing Strategy, these peers will be excluded from lookups in the Realm Routing Table. You can use ExcludePeers to act on errors in the answers from a Diameter server. For instance, if a peer answers with the Result-Code AVP set to | |||||
IncomingRemotePeer (string) | This field is populated with the Diameter identity of the sending peer.
| |||||
Request (BaseCommand (Diameter)) | The Diameter Stack agent populates the Request field with the "request message UDR" before routing the RequestCycleUDR to the workflow. For the Diameter Request agent it will work the reversed way and request messages will be transmitted from the workflow to the Diameter Stack agent by using this field.
| |||||
RequestReceivedTime (long) | A timestamp indicating when the server receives the request in nanoseconds. | |||||
RequestSentTime (long) | A timestamp indicating when the client sends the request in nanoseconds. | |||||
Session_Id(string) | A Diameter Session-Id value that will be read from the Request field in the Diameter message. This is a read-only field. | |||||
Throttled(boolean) | This fl ag indicates whether the UDR has been throttled or not. Default is
|
WrappedMZObject
The WrappedMZObject UDR does not map to a Diameter message but can be used to send data between workflows. WrappedMZObject is added as a field in the RequestCycleUDR (request or answer).
...
Field | Description |
|---|---|
Data (any) | The data to send to another workflow. |
Destination_Host (string) | The server host, the destination of the message. |
Destination_Realm (string) | The realm where to route the message. |
Is_Request (boolean) | Used to indicate if the message is a request or not. |
Is_Unidirectional (boolean) | To be used if when no reply is expected. |
DiameterErrorUDR
When any of the following errors occurs, the Diameter Stack agent creates a DiameterErrorUDR:
...
You can configure the Diameter Stack agent to route UDRs of this type to the workflow. For more information, see Advanced Tab in Diameter Stack Agent Configuration (2.3).
ConnectionLost UDR
The ConnectionLost UDR is sent whenever a connection to a peer is lost, regardless of the reason for the connection going down, i e, whether it is a controlled shutdown or, for example, a network failure.
...
You can configure the Diameter Stack agent to route UDRs of this type to the workflow. For more information, see Advanced Tab in Diameter Stack Agent Configuration (2.3).
Special Error Handling
The Diameter Stack agent produces three error answers with Usage Engine internal result codes.
...
Connection to peer not openWhen connection with the peer that is receiving the request is not established, a message with the error code 4998 is returned.
Timed out waiting for answerWhen a request is sent to a peer and no answer is received within a configurable timeout, a message with the error code 4999 is returned.
Peer Failover Handling
The connections to peers are monitored through the standard Diameter watchdog as described in RFC 6733 and RFC 3539. Possible states of the connections are: OKAY, SUSPECT, DOWN, REOPEN, INITIAL. These states are used by Diameter Stack agent for peer selection, failover handling, and to determine when messages should be routed to the workflow.
...