Diameter. The basic protocol. Part 1

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

UPDATE: At the request of ploop , thanks for the valuable comment. Diameter is a protocol of the AAA family, and is a development of RADIUS. It is intended mainly for the evaluation of services in communication networks. In particular, in 3G networks it is used to evaluate data transmission 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; Pat R. Calhoun (Sun), Glen Zorn (MS), Ping Pan (IBM) became its authors.
The draft authors' team changed from version to version, they moved from one company to another, and finally, in 2003, RFC 3588 was released, but always the first name is Pat R. Calhoun. In 3588, the Diameter base model was described, which included the Accounting functionality and allowed developers to create new applications for the protocol based on it. And most recently, in October 2012, RFC 3588 was deprecated, and replaced by RFC6733, in which nothing fundamentally changed, backward compatibility was 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 of an application is the RFC 4006 Diameter Credit Control Application, the development of which began in 2003, and the final RFC was released in 2005. Next, the 3GPP committee pushed away from RCF 3588 and created a number of applications, such as 3GPP 32.299 Diameter charging applications, which is a consequence of the development of RFC 4006 DCCA .

These three sources will suffice to consider the possibilities of Diameter, in many respects it will be a retelling of the recommendations. Below I will provide links to some open specifications. In addition to the open, I came across a proprietary implementation of the Diameter application. As a result, I cannot assess the real number of implementations, versions and applications. But I can say for sure that today, to provide almost any subscriber with the mobile services, Diameter is used in one form or another. And with the development of 3G, IMS, LTE, the percentage of penetration 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, rules for sending messages and their routing, disconnecting.
TCP and SCTP can be used as transport. Protocol security should be provided at the transport level, recommendations also state 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, it is necessary to introduce two terms, 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 a single subscriber.
Connection - controls the state of communication between the Diameter nodes.

The session is determined by the AVP SessionID, and this identifier is pass-through for all nodes participating in the processing session of the subscriber.

Customer

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

Server

The role of the server is quite understandable; it must monitor the state of subscriber sessions.

Agent.

DIAMETER agents are intermediate nodes between the client and the server and perform traffic management functions. For example, they can aggregate messages from devices on one site, act as a load balancer, modify Diameter packets, act as security gateways when moving 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 the list of known neighbors. Relay can be used to aggregate messages from multiple nodes located in the same geographical area.

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

Proxy agent.

Proxy are very similar to Relay, but they can modify the Diameter message payload. For example, to control access to certain services, modify field values, and so on. Most often, Relay and Proxy are combined into one entity, since Proxy without conversion rules is a Relay agent.

Redirect agent (DRD)

DRD is used if the routing rules for the Diameter messages must be controlled from one point. DRD receives the request, determines the node to which it should be sent, and tells the DRL where to redirect it.
On charts, everything looks much simpler.

Translation Agents (TLA)

And the most interesting (from my point of view) class of nodes is Diameter - Protocol translators. They are used if the physical devices are incompatible at the AAA protocol layer. For example, implement conversion from RADIUS to Diameter and back. Or support conversion between 2 incompatible Diameter versions. TLAs must provide transactional and stateful storage of the session during its processing.
TLA should only be announced by those ApplicationIDs whose support is implemented, since 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 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 package.
Application-Id - pointer to the type of application
Hop-by-Hop Identifie r - the unique number of the request within the connection, the answer must have the same number, this field can be modified if necessary by agents.
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.
Behind the code are service bits, data length, and an optional Vendor-ID field.
Then the data itself comes with a certain length.
The data in turn may contain other AVP sets, the AVP structure is perfectly described by ASN.1.

On this finish.

In the next part, we will take a look at how the protocol works. Instead of the narrative, we will analyze the message exchange by stages: connection establishment, Diameter processing, and connection termination. And the most interesting - consider the extensibility of the protocol and its applications.