Diameter Protocol

Topics To be Covered
1. What is Diameter Protocol?
2. Diameter Protocol in Network Model
3. Diameter Message Header and Its Elements
4. AVP Message Structure and Its Elements
5. Diameter Agents
6. Diameter Peer Discovery
7. Routing Mechanism
8. Diameter Address Format
9. Diameter Credit Control Application and its Architecture
10.Supported Diameter Messages In our Product
11.Credit Control Request Message Format
12.Credit Control Answer Message Format
13.Diameter Result Codes
What is Diameter Protocol?
The Diameter protocol was initially developed by the IETF (Internet Engineering Task Force) to provide an Authentication,
Authorization, and Accounting (AAA) framework for applications such as remote network access or IP mobility. The Diameter
protocol has several advantages over previous AAA protocols like RADIUS in that it offers improvements in the areas of reliability,
security, scalability, and flexibility.
Diameter Default port is 3868 for TCP/SCTP.
Diameter Protocol In Network Model
Diameter Message Header

Diameter is Message based protocol. There are two types of messages: Request
Messages and Answer Messages.
Header Elements

Version- Field must be set to 1 to indicate diameter version. Size is 1 octet

Length – Field contains the message Header. Size is 3 octets
Flags – Field contains 8 Flags : Size is 1 octet
(i)Request- If set, the message is a request. If cleared, the message is an answer.
(ii)Proxyable- If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.
(iii)Error- If set, the message contains a protocol error, This bit MUST NOT be set in request messages.
(iv) T(Potentially re-transmitted message)- This flag is set after a link Failover procedures to aid the removal of duplicate
requests.
(v)Reserved - These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.
Command Code - To uniquely identify the each diameter message IANA has assigned the unique command code for each
Request. Size is 3 octets. Each command code message has unique id for CER- 257,CCR-272 etc.
Application Id - To uniquely identify the each application IANA gives the Application-Id to each application. Size is 4 octets
For example CER- 0, CCR -4 etc.
Hop-by-Hop Identifier - Aids in matching requests and replies. Size is 4 octets.
End-to-End Identifier- Used to detect duplicate messages. Size is 4 octets
AVP Message Structure

Diameter AVPs are the basic unit inside the Diameter message that carries the
Data(Authentication Data , Security Data , Data pertaining to Application etc). There
must be at least one AVP inside Diameter message.
AVP Structure Elements

AVP Code - The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers more than
256 are used for Diameter, less than 256 used for RADIUS.
AVP Flags - For simplicity, "V" bit Means Vendor Specific; "M" bit means Mandatory; "P" bit means Protected.
The "V" bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header.
When set the AVP Code belongs to the specific vendor code address space.
The "M" bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the "M" bit set is
received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the
message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
The "P" bit indicates the need for encryption for end-to-end security.
AVP Lengths - Three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags,
Vendor-ID field (if present) and the AVP data.
Vendor-ID - The AVP Header contains one optional field. The Vendor-ID field is present if the 'V' bit is set in the AVP Flags
field.
Data - Information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP
Length fields
Diameter Agents
There are different diameter agents we are using across the application , few are listed below:

1) Diameter Relay 
It is used to route the message to other diameter node with the help of routing information
received in message such as Destination-Realm, Destination -Host. Relay can accept the request
with multiple networks.
Relay must not change message format and avps except the routing avps. Relay must advertise its
Application Identifier (0xffffffff).

2)Diameter Proxy 
Diameter Proxy does all that relay does. Moreover proxy can change message and avp format if
required to apply some policies.
A Diameter Proxy MUST be called as DIAMETER X Proxy, where X is the application whose
messages are being proxy-ed by by the node.

3)Diameter Redirect
Diameter Relay is useful in the scenario where diameter routing information is stored at
centralized location. Every node can get the route information from Redirect agent and then
forward the message. Redirect Agent does not forward message to any node. It just replies to the
request received with the routing information.[Message Processing at Redirect Agent]
Redirect must advertise its Application Identifier (0xffffffff) 

4)Translator
Translator changes RADIUS message to Diameter and vice-versa for backward compatibility.
Diameter Peer Discovery
As the name suggests it is the process by which a node finds another node to whom it is going to communicate, dynamically.

There are two cases when we need to discover peer.

(i) When a client wants to communicate with server or some diameter agent then it is not necessary  that client is directly
connected to server/diameter agent. there might be one or more diameter agents(relay,proxy) between the client and
server. 
(ii) Any of the in between diameter agent will search the next agent to which the message to be send so that message
reach to destination.

Diameter peer discovery is done by any of the methods.

1. SRVLOC(Service Location Protocol)
In larger networks, one or more Directory Agents are used.  The Directory Agent functions as a cache.  Service Agents send
register messages (SrvReg) containing all the services they advertise to Directory Agents and receive acknowledgements in
reply (SrvAck). These advertisements must be refreshed with the Directory Agent or they expire.  User Agents unicast
requests to Directory Agents instead of Service Agents if any Directory Agents are known.

2. DNS(Domain Name Server)

It is the way of finding the services on the network by using standard DNS programming interface. DNS provides various API's
for the purpose of service discovery. 3 main task it performs: 1. Register 2. Browse 3. Resolving a service name
Routing Mechanism
Routing mechanism basically done by two way.
1. Peer table - Peer Table shall maintain the Identity of very next peer, that has direct connection to considered peer, state of very
next peer (Open,Close,Idle etc.) and how its entry is configured (statically or dynamically).
2. Realm Based Routing table - Realm Routing table shall contain routing and processing information of all peers are  present in Peer
Table, Such as Realm Name to which a peer belong, Application that are supported by node in that Realm (that is exchanged in
CER/CEA), How peer will treat the message e.g. consume LOCALLY if server, forward if Relay etc.
Diameter Address Format
Diameter URI MUST follow the URI syntax given below

aaa://FQDN [Port][Transport][Protocol]  //No Transport security

              or
aaas://FQDN [Port][Transport][Protocol]  //Transport security used

FQDN = Fully Qualified Domain Name

Port = :<1*digit>
Port Number of the port use for listen the incoming connection if Absent the default Diameter port 3868 is assumed.
Transport= ;transport=
Name of the transport used to listen. if Absent then default SCTP is assumed. we shall not mention the UDP when Protocol field
is set to diameter.
Protocol = ;protocol=
If absent then by default diameter is assumed.

Example of Valid diameter host identities

1) aaa://host.example.com
  
on default port (3868), default transport(SCTP) and default protocol(diameter)

2)aaa://host.example.com:6666;transport=tcp;protocol=diameter
 Port=6666, Transport=tcp , Protocol=diameter

3)aaa://host.example.com:1813;transport=udp;protocol=radius
Diameter Credit Control Application
The Diameter Credit-Control Application (reference to RFC 4006) provides a general solution to real-time cost and credit-control.

DCCA Supports two kinds of charging:

1. Event Based Charging

2. Session Based Charging

Credit Control Application Architecture

Figure 1 illustrates the typical credit-control architecture, which consists of a Service Element with an embedded Diameter
credit-control client, a Diameter credit-control server, and an AAA server. A Business Support System is usually deployed; it
includes at least the billing functionality.

When an end user requests services, the request is typically forwarded to a service element in the user’s home domain. In
some cases it might be possible that the service element in the visited domain can offer services to the end user; however,
a commercial agreement must exist between the visited domain and the home domain. Network access is an example of a
service offered in the visited domain where the NAS, through an AAA infrastructure, authenticates and authorizes the user
with the user’s home network.
Supported Diameter Messages in our product
The Credit Control protocol uses the framework defined in the Diameter base protocol (RFC 3588, reference). Below table shows the
messages currently supported.

1. Device Watchdog Request (DWR)- message is sent to a peer when no traffic has been exchanged between two peers. Indicated by the
Command-Code 280 and the Command Flags' 'R' bit set.
2. Device Watchdog Answer (DWA) - message is the response to a Device Watchdog Request message. Indicated by the Command-Code
280 and the Command Flags' 'R' bit cleared.
3. Capabilities Exchange Request (CER)-When two Diameter peers establish a transport connection, they MUST exchange Capabilities
Exchange Request (CER) messages. This message allows the discovery of a peer’s identity and its capabilities. Indicated by the
Command- Code 257 and the Command Flags' 'R' bit set.
4. Capabilities Exchange Answer (CEA)- message is the response to a Capabilities Exchange Request message. Indicated by the Command-
Code 257 and the Command Flags' 'R' bit cleared.
5. Credit Control Request(CCR)-The Credit-Control-Request message (CCR) is indicated by the command-code field being set to 272 and
the 'R' bit being set in the Command Flags field. It is used between the Diameter credit-control client and the credit-control server to
request credit authorization for a given service.
6. Credit Control Answer(CCA)- is indicated by the command-code field being set to 272 and the 'R' bit being cleared in the Command
Flags field. It is used between the credit-control server and the Diameter credit-control client to acknowledge a Credit-Control-Request
command.
Credit Control Request Message Format
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ Framed-IP-Address ]
[ Subscription-Id ]
• Session-ID- the format of the Session-Id is "pid; ip; time", where:
i. PID is a 32-bit integer type indicating the unique PID for a specific session.
ii. IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal
format.
iii. TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from
January 1, 1970.
• Auth-Application-Id is set to the application ID of the protocol.
• Origin-Host is set to the host id (its IP).
• Origin-Realm is set to originating defined realm.
• Destination-Host is set to destination host id(its IP).
• Destination-Realm is set to destination realm. The destination host is not mandatory.
• CC-Request-Type is set to "Initial" on session creation ,”Update” on requested quota and "Termination" on session termination. 
• CC-Request-Number is a unique number within a session-id.
• Framed-IP-Address  is the IP address of the subscriber
• Subscription-Id is set to the subscriber-ID(for example, IMSI/MSISDN)
Credit Control Answer Message Format
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]

• Session-Id is set to the CCR Session-Id.

•Auth-Application-Id is set to the same value as the CCR.
•Origin-Host is set to the message generating host.
•Origin-Realm is set to the Originating CCR realm.
•CC-Request-Type and CC-Request-Number are set to the same type as in the CCR.
•Subscription-Id is set to the subscriber-ID.
• Result Code – It defines particular result code.
Diameter Result Codes
References
1. http://diameter-protocol.blogspot.in/
2. http://www.cisco.com/c/en/us/td/docs/cable/serv_exch/serv_control/broadband_app/rel37x/mobile_sol/mobile_sol/07_mobil
e_appA.html
3. http://tools.ietf.org/pdf/rfc4006.pdf
4. http://tools.ietf.org/html/rfc3588
Thank You