Diameter
Diameter
Diameter
Page
Diameter
What is Diameter ? - Extensible, ASCII based messaging protocol to enable Authentication ,Authorization, and Accounting (AAA) function in IP and multimedia networks. - Defined in the IETF(rfc 3588) and extended in 3GPP(rfc4006). - Diameter supports a scalable architecture with the base protocol and application can run on different processors. - Diameter operates on top of reliable transport protocols like TCP and SCTP. - Its secure and reliable transports make it a suitable choice for charging Applications
Transportation Protocol Connection-Oriented Connectionless Protocol Protocols (TCP and SCTP) (UDP) Agent Support Security Capabilities Negotiation Relay, Proxy, Redirect, Translation Hop-to-Hop, End-to-End Negotiate supported applications and security level Implicit support. Hop-to-Hop only Doesn't support
Peer Discovery
Server Initiated Message
Static configuration
Doesn't support
Diameter Stack
Diameter Stack..
- Base Diameter Protocol(RFC: 3588) - Uses IP for Network Layer Functionality. - Operates on top of reliable transport protocols like TCP and SCTP. - SH ,CX,RO,RF interfaces defined by 3GPP for IMS. - The SH and CX Diameter applications extend the Base Diameter Command codes and AVPs to support the authentication and authorization functions.
Diameter Stack.
Ro interface is used for real-time charging. Based on the IETF defined Credit Control Application (RFC 4006). The Rf interface is based on the accounting functionality of IETFdiameter base (RFC 3588). Applications - Purpose specific: CCA ,SIP, NASREQetc. - Identified by application Id - IANA-assigned application identifier - Used also for diameter message routing
Session Management
Session Management
Routing Management
Routing Management
Connection Management
Base Protocol
Connection Management
Base Protocol
Page 8
AVP Header
AVP Data
Diameter Header = Version, Length, Flags, Code, AppId, H2H Id, E2E {
Id }
AVP Header = Code, Flag, Length, Vendor-Id (Opt) Each message is defined using an ABNF grammar. Pre-defined AVP data types (Integer32, Float, OctetString etc.)
FLAGS :
R- Request
P - Proxiable
E- error , T- Retransmit Flags :VMP-
<CER> ::= < Diameter Header: 257, REQ > { Origin-Host } /* Required AVP, Occurrence: 1 */ { Origin-Realm } { Vendor-Id } * [ Auth-Application-Id ] { Product-Name } [ Origin-State-Id ] /* Optional AVP, Occurrence: 0 or 1 */ * [ Supported-Vendor-Id ] /* Optional AVP, Occurrence: 0+ */ * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] * [ AVP ]
* [ Inband-Security-Id ] *
Connection Management
Connection Management
Peer Discovery :
Static configuration: mandatory [(Peer Table and Peer Routing Table] DNS(Broadcast): optional
Connection Management
Capabilities Negotiation
Capabilities Exchange - Use of Capabilities-Exchange (CER/CEA) messages - Message exchange advertises: - Supported applications - Peer Identity - Security schemes Indicates the use of TLS/IPSec - SCTP host addresses if used - CER/CEA should not be proxied Peer Table Creation - Lists all peers that passes capabilities negotiation - Indicates the connection status of each peers - Also Used for message routing
- Use of Disconnect-Peer exchange (DPR/DPA) - Provides hints for future reconnection attempts - Routing and peer table updates
Routing
Diameter Nodes
Diameter Clients and Severs
Request and Answer Originators Where application normally reside Advertises supported applications only Diameter Agents Request and Answer forwarders Relay Agents Provides basic message forwarding Does not inspect content of the message other than DestinationHost and/or Realm and AppIds Advertises support all applications
Diameter Nodes
Lookup(example.com) Local Process
2.Request
Lookup(example.com) route to Relay Agent 1.Request
Diameter Server
Request Queue
Diameter Client
Request Queue
3.Answer
example.com
4. Answer
Routing rules:
If local identity == Destination-Host AVP then process locally, otherwise If peer identity == Destination-Host AVP then send that peer, otherwise (use Peer Table) Lookup realm table with Destination-Realm and AppId If found send to the designated next-hop Otherwise, send an UNABLE_TO_DELIVER answer(with E=1) Advertises support all applications Use of Request Queue :Successfully forwarded requests are queued
Request Routing..
Realm Routing Table : List of realm routing entries Realm routing entry looks like : Realm (*), AppId (**), Action, Next-hop Peer, isStatic, ExpireTime Realm: Primary key, matched with Destination-Realm AVP AppId: Secondary key, matched with AppId in message header, Action: For each matching entry, possible actions are, LOCAL, RELAY, REDIRECT isStatic: Indication of static or dynamic route ExpireTime: Time before dynamic route are no longer valid
Answer Routing
Information used for routing
Hop-by-Hop Id is used instead of Destination-Host or Destination- Realm AVP Hop-by-Hop Id is unique within each hop Answer routing path is the reverse of the request path
Routing Rules:
For answer originators: - Use the same Hop-by-Hop Id found in the request For answer forwarders: - Lookup Hop-by-Hop Id in request queue. - If found, forward answer to appropriate peer and remove request from the queue - Otherwise, discard
Fall-Back:
Switch back to the original next hop when connection is re-
established
Relay-2
Lookup(example.com) route to Relay Agent
Request Queue
4.Answer
2.Request T=1
4.Answe r
1.Request
Relay-1
Request Queue
Diameter Client
Request Queue
Diameter Server
3.Answer
Request Queue
4.Answer
example.net
example.com
Content
Diameter Credit Control Application Overview Messages Operation Modes Other Protocol Features Timers Duplicate Detection High Availability/Failure Handling Notes for Authors of New Applications
Sent from server to client and carries the result of the corresponding authorization request
Reauthorization
Request (RAR)
Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service
Reauthorization
Answer (RAA)
Operation Modes
Event Based
Session Based
Required when there is a need to reserve credits before providing the service
Server first reserves the credits and debits them after receiving the subsequent CCR
Possible values are INITIAL_REQUEST, UPDATE_REQUEST, TERMINATION_REQUEST for session based scenarios and EVENT_REQUEST for event based scenarios
CC-Request-Number AVP
Requested-Action AVP
Used to indicate type of the requested action for event based scenarios. Possible values are DIRECT_DEBITING, REFUND_ACCOUNT, CHECK_BALANCE and PRICE_ENQUIRY
Server
Cant rely on Tw, configuring Tw to a low value may be undesirable and Tw on the whole message path may not be under control of the client administrating entity
Tcc
timer
Used by server to guard against non-receipt of CCR for session based scenarios
Server can inform client when a tariff change will occur with Tariff-Time-Change AVP
Tariff-Change
Client reports used units before and after tariff change with Tariff-Change-Usage AVP
Duplicate Detection
Session-Id AVP, CC-Request-Number AVP and CC-RequestType can be used to detect duplicates (mechanism described in RFC3588 will work too, i.e. using Origin-Host AVP and Endto-End Identifier
CC-Session-Failover AVP Used by servers to inform clients whether a backup instance is present ( Client needs to know identity of backup peer by other means FAILOVER_NOT_SUPPORTED, FAILOVER_SUPPORTED )
Credit-Control-Failure-Handling AVP Used by server to inform client about the expected behavior for session based scenarios, when CCA for a CCR is not received(TERMINATE , CONTINUE)
Direct-Debiting-Failure-Handling AVP
Used by server to inform client about the expected behavior for event based scenarios, when CCA for a CCR is not received(TERMINATE_OR_BUFFER , CONTINUE )
Thank you