Diameter Basic protocol. Part 1

He promised to talk about Diameter. We will begin, but I must warn you, I will write in free text, there is a high probability of simplification and omission of a number of important points. The goal is a review article and the very first acquaintance with the protocol, and details can be read in the standards. Examples will be from cellular communications.

UPDATE: At the request of ploop , thanks for the valuable comment. Diameter is an AAA family protocol, and is a development of RADIUS. It is intended primarily for evaluating services in communication networks. In particular, in 3G networks it is used to evaluate data transfer services, and in IMS \ LTE the protocol is one of the main control elements.

Introduction

The first document that described the requirements for the new protocol was published in 1998 as part of the IETF, its authors were Pat R. Calhoun (Sun), Glen Zorn (MS), Ping Pan (IBM).
The draft authors team changed from version to version, they switched from one company to another, and finally, in 2003, RFC 3588 was released, but the name Pat R. Calhoun is always the first. In 3588, the basic Diameter model was described, which included the Accounting functionality and allowed developers to create new applications for the protocol on its basis. And more recently, in October 2012, RFC 3588 was deprecated and replaced by RFC6733, in which nothing has changed dramatically, backward compatibility has been preserved, the changes are described in the document itself and are beyond the scope of the article.

An important feature of the protocol is its extensibility and the ability to create not only its own attributes, but also applications. An example application is the RFC 4006 Diameter Credit Control Application, which began development in 2003 and the final RFC came out in 2005. The 3GPP then pulled off the RCF 3588 and created a number of applications, such as 3GPP 32.299 Diameter charging applications, which is a consequence of the development of the RFC 4006 DCCA .

These three sources will be enough to consider the possibilities of Diameter, in many respects it will be a retelling of recommendations. Below I will provide links to some open specifications. Besides the open ones, I came across proprietary implementations of Diameter applications. As a result, the actual number of Diameter implementations, versions, and applications cannot be estimated. But I can say for sure that today, to provide Diameter almost any subscriber with mobile services, it is used in one form or another. And with the development of 3G, IMS, LTE, the penetration rate will tend to 100%.

Basic protocol

The basic protocol implements the requirements for AAA protocols, the details of which are reflected in RFC2989, and describes the process of establishing a connection, checking compatibility, the rules for sending messages and their routing, and disconnection.
As transport, TCP and SCTP can be used. Protocol security should be ensured at the transport level; the recommendations also indicate that the protocol should not be used without TLS, DTLS, or IPsec. In a trusted network, of course, it is possible to do without them, in particular, if the internal network of the enterprise can be considered reliable.

The specification defines several types of Diameter nodes.
To understand the role of nodes, two terms must be introduced, which will be discussed in more detail below.
Session- monitors the status of the subscriber and includes those and only those messages that relate to an individual subscriber.
Connection - monitors the state of communication between Diameter nodes.

The session is determined by the AVP SessionID, and this identifier is end-to-end for all nodes participating in the processing of the subscriber's session.

Client

The client is usually a network device that directly processes subscriber traffic.

Server

The role of the server is understandable, it should monitor the status of subscriber sessions.

Agent.

DIAMETER agents are intermediate nodes between the client and server and perform traffic control functions. For example, they can aggregate messages from devices on the same site, act as a load balancer, modify Diameter packets, act as security gateways when switching from a trusted network to a public one.

Functionally, agents are divided into several types.

Relay agent (DRL)

Nodes of this type receive Diameter messages from network devices and redirect them to the following nodes based on the data contained in the messages based on Realm and a list of known neighbors. Relay can be used to aggregate messages from multiple nodes located in the same geographic area.

Relay does not modify significant fields in the message body in any way, so they can work with any type of Diameter application, however, when establishing a connection, they must announce a Relay Application Id.

Proxy agent.

Proxies are very similar to Relay, but they can modify the payload of Diameter messages. For example, control access to certain services, modify field values, etc. Most often, Relay and Proxy are combined into one entity, because A proxy without conversion rules is a Relay agent.

Redirect agent (DRD)

DRDs are used if the routing rules for Diameter messages are to be monitored from a single point. DRD receives the request, determines the node to which it should be sent, and tells DRL where it should be redirected.
On the diagrams, everything looks much simpler.

Translation Agents (TLA)

And the most interesting (from my point of view) Diameter node class is Protocol Translators. They are used if physical devices are incompatible at the level of AAA protocols. For example, implement conversion from RADIUS to Diameter and vice versa. Or support conversion between 2 incompatible versions of Diameter. TLAs should provide transactional and stateful state of the session during its processing.
TLAs should announce only those ApplicationIDs whose support is implemented, as only in this case, the agent will be able to correctly process the incoming message.

Package structure

Packages traditionally consist of a header and a payload (in the form of an AVP - Attribute-Value Pair).



The purpose of the first three fields is clear.
Command-Code - the code of the command that is transmitted in the
Application-Id package - a pointer to the application type
Hop-by-Hop Identifie r - a unique request number within the connection, the response must have the same number, this field can be modified by agents if necessary.
End-to-End Identifie r is another request identifier, but unlike Hop-by-Hop, it must remain unique within the session and agents must not change it.
Next comes the payload in the form of AVP (Attribute Value Pairs).

The structure of AVP is also very simple.



AVP Code- attribute code, described in the recommendation.
The code is followed by overhead bits, data length and optional Vendor-ID field.
After that comes the data itself with a certain length.
Data in turn may contain other AVP sets; the AVP structure is well described by ASN.1.

On this I will end.

In the next part, we will look at how the protocol works, instead of the descriptive part, we will analyze the order of message exchange in stages: establishing a connection, processing Diameter sessions, and terminating the connection. And the most interesting - consider the extensibility of the protocol and its applications.