2. Protokollübersicht

Das Diameter-Basisprotokoll befasst sich mit dem Aufbau von Verbindungen zu Peers, der Aushandlung von Fähigkeiten, der Art und Weise, wie Nachrichten über Peers gesendet und weitergeleitet werden, und dem letztendlichen Abbau der Verbindungen. Das Basisprotokoll definiert auch bestimmte Regeln, die für alle Nachrichtenaustausche zwischen Diameter-Knoten gelten.

Die Kommunikation zwischen Diameter-Peers beginnt damit, dass ein Peer eine Nachricht an einen anderen Diameter-Peer sendet. Die Menge der in der Nachricht enthaltenen AVPs wird durch eine bestimmte Diameter-Anwendung bestimmt. Ein AVP, das zum Verweisen auf die Sitzung eines Benutzers enthalten ist, ist die Session-Id.

Die anfängliche Anfrage zur Authentifizierung und/oder Autorisierung eines Benutzers würde das Session-Id AVP enthalten. Die Session-Id wird dann in allen nachfolgenden Nachrichten verwendet, um die Sitzung des Benutzers zu identifizieren (siehe Abschnitt 8 für weitere Informationen). Die kommunizierende Partei kann die Anfrage akzeptieren oder ablehnen, indem sie eine Antwortnachricht mit dem Result-Code AVP zurückgibt, das so eingestellt ist, dass ein Fehler aufgetreten ist. Das spezifische Verhalten des Diameter-Servers oder -Clients, der eine Anfrage empfängt, hängt von der eingesetzten Diameter-Anwendung ab.

Der Sitzungszustand (der einer Session-Id zugeordnet ist) MUSS beim Empfang von Session-Termination-Request, Session-Termination-Answer, beim Ablauf der autorisierten Dienstzeit im Session-Timeout AVP und gemäß den in einer bestimmten Diameter-Anwendung festgelegten Regeln freigegeben werden.

Das Diameter-Basisprotokoll kann für sich allein für Abrechnungsanwendungen verwendet werden. Für Authentifizierung und Autorisierung wird es immer für eine bestimmte Anwendung erweitert.

Diameter-Clients MÜSSEN das Basisprotokoll unterstützen, das die Abrechnung umfasst. Darüber hinaus MÜSSEN sie jede Diameter-Anwendung vollständig unterstützen, die zur Implementierung des Dienstes des Clients erforderlich ist, z. B. Network Access Server Requirements (NASREQ) [RFC2881] und/oder Mobile IPv4. Ein Diameter-Client MUSS als "Diameter X Client" bezeichnet werden, wobei X die von ihm unterstützte Anwendung ist, und nicht als "Diameter Client".

Diameter-Server MÜSSEN das Basisprotokoll unterstützen, das die Abrechnung umfasst. Darüber hinaus MÜSSEN sie jede Diameter-Anwendung vollständig unterstützen, die zur Implementierung des beabsichtigten Dienstes erforderlich ist, z. B. NASREQ und/oder Mobile IPv4. Ein Diameter-Server MUSS als "Diameter X Server" bezeichnet werden, wobei X die von ihm unterstützte Anwendung ist, und nicht als "Diameter Server".

Diameter-Relays und Umleitungsagenten sind für die Diameter-Anwendungen transparent, aber sie MÜSSEN das Diameter-Basisprotokoll unterstützen, das die Abrechnung umfasst, sowie alle Diameter-Anwendungen.

Diameter-Proxies MÜSSEN das Basisprotokoll unterstützen, das die Abrechnung umfasst. Darüber hinaus MÜSSEN sie jede Diameter-Anwendung vollständig unterstützen, die zur Implementierung von Proxy-Diensten erforderlich ist, z. B. NASREQ und/oder Mobile IPv4. Ein Diameter-Proxy MUSS als "Diameter X Proxy" bezeichnet werden, wobei X die von ihm unterstützte Anwendung ist, und nicht als "Diameter Proxy".

2.1. Transport

Das Diameter-Transportprofil ist in [RFC3539] definiert.

Das Diameter-Basisprotokoll wird auf Port 3868 sowohl für TCP [RFC0793] als auch für SCTP [RFC4960] ausgeführt. Für TLS [RFC5246] und Datagram Transport Layer Security (DTLS) [RFC6347] MUSS ein Diameter-Knoten, der vor einem Nachrichtenaustausch eine Verbindung initiiert, auf Port 5658 ausgeführt werden. Es wird angenommen, dass TLS bei Verwendung über TCP läuft und DTLS bei Verwendung über SCTP läuft.

Wenn der Diameter-Peer das Empfangen von TLS/TCP- und DTLS/SCTP-Verbindungen auf Port 5658 nicht unterstützt (d. h. der Peer entspricht nur RFC 3588), KANN der Initiator auf die Verwendung von TCP oder SCTP auf Port 3868 zurückgreifen. Beachten Sie, dass dieses Schema nur zum Zweck der Rückwärtskompatibilität beibehalten wird und dass inhärente Sicherheitslücken bestehen, wenn die anfänglichen CER/CEA-Nachrichten ungeschützt gesendet werden (siehe Abschnitt 5.6).

Diameter-Clients MÜSSEN entweder TCP oder SCTP unterstützen; Agenten und Server SOLLTEN beide unterstützen.

Ein Diameter-Knoten KANN Verbindungen von einem anderen Quellport als dem, den er zum Akzeptieren eingehender Verbindungen deklariert, initiieren, und er MUSS immer bereit sein, Verbindungen auf Port 3868 für TCP oder SCTP und Port 5658 für TLS/TCP- und DTLS/SCTP-Verbindungen zu empfangen. Bei Verwendung der DNS-basierten Peer-Erkennung (Abschnitt 5.2) haben die von SRV-Datensätzen empfangenen Portnummern Vorrang vor den Standardports (3868 und 5658).

Eine gegebene Diameter-Instanz der Peer-Zustandsmaschine DARF NICHT mehr als eine Transportverbindung verwenden, um mit einem gegebenen Peer zu kommunizieren, es sei denn, auf dem Peer existieren mehrere Instanzen, in diesem Fall ist eine separate Verbindung pro Prozess zulässig.

Wenn keine Transportverbindung mit einem Peer besteht, SOLLTE periodisch ein Verbindungsversuch unternommen werden. Dieses Verhalten wird über den Tc-Timer gehandhabt (siehe Abschnitt 12 für Details), dessen empfohlener Wert 30 Sekunden beträgt. Es gibt bestimmte Ausnahmen von dieser Regel, z. B. wenn ein Peer die Transportverbindung beendet hat und angibt, dass er nicht kommunizieren möchte.

Beim Verbinden mit einem Peer und wenn null oder mehr Transporte angegeben sind, SOLLTE zuerst TLS versucht werden, gefolgt von DTLS, dann von TCP und schließlich von SCTP. Weitere Informationen zur Peer-Erkennung finden Sie in Abschnitt 5.2.

Diameter-Implementierungen SOLLTEN in der Lage sein, ICMP-Protokoll-Port-nicht-erreichbar-Nachrichten als explizite Hinweise darauf zu interpretieren, dass der Server nicht erreichbar ist, vorbehaltlich der Sicherheitsrichtlinie zum Vertrauen solcher Nachrichten. Weitere Hinweise zur Behandlung von ICMP-Fehlern finden Sie in [RFC5927] und [RFC5461]. Diameter-Implementierungen SOLLTEN auch in der Lage sein, ein Zurücksetzen vom Transport und zeitüberschrittene Verbindungsversuche zu interpretieren. Wenn Diameter Daten von der unteren Schicht empfängt, die nicht als Diameter-Fehler des Peers analysiert oder identifiziert werden können, ist der Stream kompromittiert und kann nicht wiederhergestellt werden. Die Transportverbindung MUSS mit einem RESET-Aufruf (TCP RST-Bit senden) oder einer SCTP ABORT-Nachricht geschlossen werden (ordnungsgemäßes Schließen ist kompromittiert).

2.1.1. SCTP-Richtlinien

Diameter-Nachrichten SOLLTEN auf eine Weise auf SCTP-Streams abgebildet werden, die Head-of-Line (HOL)-Blockierung vermeidet. Unter den verschiedenen Möglichkeiten, das Mapping durchzuführen, das diese Anforderung erfüllt, wird EMPFOHLEN, dass ein Diameter-Knoten jede Diameter-Nachricht (Anfrage oder Antwort) über Stream Null mit gesetztem ungeordnetem Flag sendet. Diameter-Knoten KÖNNEN jedoch andere Designalternativen zur Vermeidung von HOL-Blockierung auswählen und implementieren, z. B. die Verwendung mehrerer Streams mit gelöschtem ungeordnetem Flag (wie ursprünglich in RFC 3588 angewiesen). Auf der Empfängerseite MUSS eine Diameter-Entität bereit sein, Diameter-Nachrichten über jeden Stream zu empfangen, und sie steht frei, Antworten über einen anderen Stream zurückzugeben. Auf diese Weise verwalten beide Seiten die verfügbaren Streams in Senderichtung unabhängig von den Streams, die die andere Seite zum Senden einer bestimmten Diameter-Nachricht gewählt hat. Diese Nachrichten können außer der Reihe sein und verschiedenen Diameter-Sitzungen angehören.

Die Lieferung außer der Reihe hat besondere Bedenken während einer Verbindungsherstellung und -beendigung. Wenn eine Verbindung hergestellt wird, sendet die Responder-Seite eine CEA-Nachricht und wechselt in den R-Open-Zustand, wie in Abschnitt 5.6 angegeben. Wenn eine Anwendungsnachricht kurz nach der CEA gesendet und außer der Reihe zugestellt wird, verwirft die Initiator-Seite, die sich noch im Wait-I-CEA-Zustand befindet, die Anwendungsnachricht und schließt die Verbindung. Um diese Race-Bedingung zu vermeiden, SOLLTE die Empfängerseite NICHT Liefermethoden außer der Reihe verwenden, bis die erste Nachricht vom Initiator empfangen wurde, was beweist, dass er in den I-Open-Zustand gewechselt ist. Um eine solche Nachricht auszulösen, könnte die Empfängerseite unmittelbar nach dem Senden einer CEA eine DWR senden. Beim Empfang der entsprechenden DWA sollte die Empfängerseite mit der Verwendung von Liefermethoden außer der Reihe beginnen, um HOL-Blockierung entgegenzuwirken.

Eine weitere Race-Bedingung kann auftreten, wenn DPR- und DPA-Nachrichten verwendet werden. Sowohl DPR als auch DPA sind klein; daher können sie schneller an den Peer geliefert werden als Anwendungsnachrichten, wenn ein Liefermechanismus außer der Reihe verwendet wird. Daher ist es möglich, dass ein DPR/DPA-Austausch abgeschlossen wird, während Anwendungsnachrichten noch übertragen werden, was zu einem Verlust dieser Nachrichten führt. Eine Implementierung könnte diese Race-Bedingung mildern, z. B. durch Verwendung von Timern, und eine kurze Zeitspanne warten, bis ausstehende Nachrichten auf Anwendungsebene eintreffen, bevor die Transportverbindung getrennt wird. Letztendlich werden verlorene Nachrichten durch den in Abschnitt 5.5.4 beschriebenen Wiederholungsmechanismus behandelt.

Ein Diameter-Agent SOLLTE dedizierte Payload-Protokollkennungen (PPIDs) für Klartext- und verschlüsselte SCTP DATA-Chunks verwenden, anstatt nur die nicht spezifizierte Payload-Protokollkennung (Wert 0) zu verwenden. Zu diesem Zweck werden zwei PPID-Werte zugewiesen: Der PPID-Wert 46 ist für Diameter-Nachrichten in Klartext-SCTP DATA-Chunks, und der PPID-Wert 47 ist für Diameter-Nachrichten in geschützten DTLS/SCTP DATA-Chunks.

2.2. Sichern von Diameter-Nachrichten

Verbindungen zwischen Diameter-Peers SOLLTEN durch TLS/TCP und DTLS/SCTP geschützt werden. Alle Implementierungen des Diameter-Basisprotokolls MÜSSEN die Verwendung von TLS/TCP und DTLS/SCTP unterstützen. Falls gewünscht, können alternative Sicherheitsmechanismen, die unabhängig von Diameter sind, wie z. B. IPsec [RFC4301], eingesetzt werden, um Verbindungen zwischen Peers zu sichern. Das Diameter-Protokoll DARF NICHT ohne eines von TLS, DTLS oder IPsec verwendet werden.

2.3. Diameter-Anwendungskonformität

Anwendungs-IDs werden während der Fähigkeitsaustauschphase angekündigt (siehe Abschnitt 5.3). Die Ankündigung der Unterstützung einer Anwendung impliziert, dass der Absender die in der jeweiligen Diameter-Anwendungsspezifikation angegebene Funktionalität unterstützt.

Implementierungen KÖNNEN beliebige optionale AVPs mit gelöschtem M-Bit (einschließlich herstellerspezifischer AVPs) zu einem in einer Anwendung definierten Befehl hinzufügen, jedoch nur, wenn die CCF-Syntaxspezifikation des Befehls dies zulässt. Einzelheiten finden Sie in Abschnitt 11.1.1.

2.4. Anwendungskennungen

Jede Diameter-Anwendung MUSS eine von der IANA zugewiesene Anwendungs-ID haben. Das Basisprotokoll erfordert keine Anwendungs-ID, da seine Unterstützung obligatorisch ist. Während des Fähigkeitsaustauschs informieren Diameter-Knoten ihre Peers über lokal unterstützte Anwendungen. Darüber hinaus enthalten alle Diameter-Nachrichten eine Anwendungs-ID, die im Nachrichtenweiterleitungsprozess verwendet wird.

Die folgenden Anwendungs-ID-Werte sind definiert:

Diameter common message       0
Diameter base accounting      3
Relay                         0xffffffff

Relay- und Umleitungsagenten MÜSSEN die Relay-Anwendungs-ID ankündigen, während alle anderen Diameter-Knoten lokal unterstützte Anwendungen ankündigen MÜSSEN. Der Empfänger einer Fähigkeitsaustauschnachricht, die Relay-Dienst ankündigt, MUSS annehmen, dass der Absender alle aktuellen und zukünftigen Anwendungen unterstützt.

Diameter-Relay- und Proxy-Agenten sind dafür verantwortlich, einen Upstream-Server zu finden, der die Anwendung einer bestimmten Nachricht unterstützt. Wenn keiner gefunden werden kann, wird eine Fehlermeldung mit dem Result-Code AVP zurückgegeben, der auf DIAMETER_UNABLE_TO_DELIVER gesetzt ist.

2.5. Verbindungen vs. Sitzungen

Dieser Abschnitt versucht, dem Leser ein Verständnis für den Unterschied zwischen "Verbindung" und "Sitzung" zu vermitteln, die in diesem Dokument ausgiebig verwendete Begriffe sind.

Eine Verbindung bezieht sich auf eine Verbindung auf Transportebene zwischen zwei Peers, die zum Senden und Empfangen von Diameter-Nachrichten verwendet wird. Eine Sitzung ist ein logisches Konzept auf Anwendungsebene, das zwischen dem Diameter-Client und dem Diameter-Server existiert; sie wird über die Session-Id AVP identifiziert.

          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                Peer-Verbindung A  Peer-Verbindung B

                   <----------------------------->
                       Benutzersitzung x

             Abbildung 1: Diameter-Verbindungen und -Sitzungen

In dem in Abbildung 1 bereitgestellten Beispiel wird die Peer-Verbindung A zwischen dem Client und dem Relay hergestellt. Die Peer-Verbindung B wird zwischen dem Relay und dem Server hergestellt. Die Benutzersitzung X erstreckt sich vom Client über das Relay zum Server. Jeder "Benutzer" eines Dienstes veranlasst das Senden einer Authentifizierungsanfrage mit einer eindeutigen Sitzungskennung. Sobald sie vom Server akzeptiert wurde, sind sowohl der Client als auch der Server sich der Sitzung bewusst.

Es ist wichtig zu beachten, dass es keine Beziehung zwischen einer Verbindung und einer Sitzung gibt und dass Diameter-Nachrichten für mehrere Sitzungen alle über eine einzige Verbindung gemultiplext werden. Beachten Sie auch, dass Diameter-Nachrichten, die sich auf die Sitzung beziehen, sowohl anwendungsspezifische als auch die in diesem Dokument definierten wie ASR/ASA, RAR/RAA und STR/STA, die Anwendungs-ID der Anwendung tragen MÜSSEN. Diameter-Nachrichten, die sich auf die Herstellung und Wartung der Peer-Verbindung beziehen, wie CER/CEA, DWR/DWA und DPR/DPA, MÜSSEN eine Anwendungs-ID von Null (0) tragen.

2.6. Peer-Tabelle

Die Diameter-Peer-Tabelle wird bei der Nachrichtenweiterleitung verwendet und wird von der Routing-Tabelle referenziert. Ein Peer-Tabelleneintrag enthält die folgenden Felder:

Host-Identität

Gemäß den in Abschnitt 4.3.1 für das von DiameterIdentity abgeleitete AVP-Datenformat beschriebenen Konventionen enthält dieses Feld den Inhalt des Origin-Host (Abschnitt 6.3) AVP, das in der CER- oder CEA-Nachricht gefunden wurde.

StatusT

Dies ist der Status des Peer-Eintrags, und er MUSS mit einem der in Abschnitt 5.6 aufgeführten Werte übereinstimmen.

Statisch oder dynamisch

Gibt an, ob ein Peer-Eintrag statisch konfiguriert oder dynamisch entdeckt wurde.

Ablaufzeit

Gibt die Zeit an, zu der dynamisch entdeckte Peer-Tabelleneinträge entweder aktualisiert oder abgelaufen sind. Wenn öffentliche Schlüsselzertifikate für die Diameter-Sicherheit verwendet werden (z. B. mit TLS), DARF dieser Wert NICHT größer sein als die Ablaufzeiten in den relevanten Zertifikaten.

TLS/TCP und DTLS/SCTP aktiviert

Gibt an, ob TLS/TCP und DTLS/SCTP bei der Kommunikation mit dem Peer verwendet werden sollen.

Zusätzliche Sicherheitsinformationen bei Bedarf (z. B. Schlüssel, Zertifikate).

2.7. Routing-Tabelle

Alle Realm-basierten Routing-Lookups werden gegen das durchgeführt, was allgemein als Routing-Tabelle bekannt ist (siehe Abschnitt 12). Jeder Routing-Tabelleneintrag enthält die folgenden Felder:

Realm-Name

Dies ist das Feld, das als Primärschlüssel in den Routing-Tabellen-Lookups verwendet werden MUSS. Beachten Sie, dass einige Implementierungen ihre Lookups basierend auf der längsten Übereinstimmung von rechts auf dem Realm durchführen, anstatt eine genaue Übereinstimmung zu erfordern.

Anwendungskennung

Eine Anwendung wird durch eine Anwendungs-ID identifiziert. Ein Route-Eintrag kann basierend auf der Anwendungs-ID im Nachrichtenkopf ein anderes Ziel haben. Dieses Feld MUSS als sekundäres Schlüsselfeld in Routing-Tabellen-Lookups verwendet werden.

Lokale Aktion

Das Feld Lokale Aktion wird verwendet, um zu identifizieren, wie eine Nachricht behandelt werden soll. Die folgenden Aktionen werden unterstützt:

LOCAL - Diameter-Nachrichten, die lokal erfüllt werden können und nicht an eine andere Diameter-Entität weitergeleitet werden müssen.
RELAY - Alle Diameter-Nachrichten, die in diese Kategorie fallen, MÜSSEN an eine Next-Hop-Diameter-Entität weitergeleitet werden, die durch den unten beschriebenen Identifikator angegeben wird. Das Routing erfolgt ohne Änderung nicht-routender AVPs. Siehe Abschnitt 6.1.9 für Relay-Richtlinien.
PROXY - Alle Diameter-Nachrichten, die in diese Kategorie fallen, MÜSSEN an eine nächste Diameter-Entität weitergeleitet werden, die durch den unten beschriebenen Identifikator angegeben wird. Der lokale Server KANN seine lokalen Richtlinien auf die Nachricht anwenden, indem er neue AVPs in die Nachricht einfügt, bevor er sie weiterleitet. Siehe Abschnitt 6.1.9 für Proxy-Richtlinien.
REDIRECT - Diameter-Nachrichten, die in diese Kategorie fallen, MÜSSEN die Identität des/der Home-Diameter-Server(s) angehängt haben und an den Absender der Nachricht zurückgegeben werden. Siehe Abschnitt 6.1.8 für Umleitungsrichtlinien.

Serverkennung

Die Identität eines oder mehrerer Server, an die die Nachricht weitergeleitet werden soll. Diese Identität MUSS auch im Feld Host-Identität der Peer-Tabelle (Abschnitt 2.6) vorhanden sein. Wenn die lokale Aktion auf RELAY oder PROXY gesetzt ist, enthält dieses Feld die Identität des/der Server(s), an den/die die Nachricht weitergeleitet werden MUSS. Wenn das Feld Lokale Aktion auf REDIRECT gesetzt ist, enthält dieses Feld die Identität eines oder mehrerer Server, an die die Nachricht umgeleitet werden MUSS.

Statisch oder dynamisch

Gibt an, ob ein Route-Eintrag statisch konfiguriert oder dynamisch entdeckt wurde.

Ablaufzeit

Gibt die Zeit an, zu der ein dynamisch entdeckter Route-Tabelleneintrag abläuft. Wenn öffentliche Schlüsselzertifikate für die Diameter-Sicherheit verwendet werden (z. B. mit TLS), DARF dieser Wert NICHT größer sein als die Ablaufzeit in den relevanten Zertifikaten.

Es ist wichtig zu beachten, dass Diameter-Agenten mindestens einen der Betriebsmodi LOCAL, RELAY, PROXY oder REDIRECT unterstützen MÜSSEN. Agenten müssen nicht alle Betriebsmodi unterstützen, um der Protokollspezifikation zu entsprechen, aber sie MÜSSEN die Protokollkonformitätsrichtlinien in Abschnitt 2 befolgen. Relay-Agenten und Proxies DÜRFEN AVPs NICHT neu anordnen.

Die Routing-Tabelle KANN einen Standardeintrag enthalten, der für alle Anfragen verwendet werden MUSS, die mit keinem der anderen Einträge übereinstimmen. Die Routing-Tabelle KANN nur aus einem solchen Eintrag bestehen.

Wenn eine Anfrage weitergeleitet wird, MUSS der Zielserver die Anwendungs-ID (siehe Abschnitt 2.4) für die gegebene Nachricht angekündigt haben oder sich selbst als Relay- oder Proxy-Agent angekündigt haben. Andernfalls wird ein Fehler mit dem Result-Code AVP zurückgegeben, der auf DIAMETER_UNABLE_TO_DELIVER gesetzt ist.

2.8. Rolle der Diameter-Agenten

Zusätzlich zu Clients und Servern führt das Diameter-Protokoll Relay-, Proxy-, Umleitungs- und Übersetzungsagenten ein, die jeweils in Abschnitt 1.2 definiert sind. Diameter-Agenten sind aus mehreren Gründen nützlich:

Sie können die Verwaltung von Systemen auf eine konfigurierbare Gruppierung verteilen, einschließlich der Wartung von Sicherheitsassoziationen.
Sie können zur Konzentration von Anfragen von einer Anzahl von kolokierten oder verteilten NAS-Gerätesätzen an eine Gruppe ähnlicher Benutzergruppen verwendet werden.
Sie können eine Mehrwertverarbeitung der Anfragen oder Antworten durchführen.
Sie können zum Lastausgleich verwendet werden.
Ein komplexes Netzwerk wird mehrere Authentifizierungsquellen haben, sie können Anfragen sortieren und an das richtige Ziel weiterleiten.

Das Diameter-Protokoll erfordert, dass Agenten den Transaktionszustand aufrechterhalten, der für Failover-Zwecke verwendet wird. Der Transaktionszustand impliziert, dass beim Weiterleiten einer Anfrage ihre Hop-by-Hop-Kennung gespeichert wird; das Feld wird durch eine lokal eindeutige Kennung ersetzt, die auf ihren ursprünglichen Wert wiederhergestellt wird, wenn die entsprechende Antwort empfangen wird. Der Zustand der Anfrage wird beim Empfang der Antwort freigegeben. Ein zustandsloser Agent ist einer, der nur den Transaktionszustand aufrechterhält.

Das Proxy-Info AVP ermöglicht zustandslosen Agenten, einer Diameter-Anfrage einen lokalen Zustand hinzuzufügen, mit der Garantie, dass derselbe Zustand in der Antwort vorhanden sein wird. Die Failover-Verfahren des Protokolls erfordern jedoch, dass Agenten eine Kopie der ausstehenden Anfragen aufbewahren.

Ein zustandsbehafteter Agent ist einer, der Sitzungszustandsinformationen verwaltet, indem er alle autorisierten aktiven Sitzungen verfolgt. Jede autorisierte Sitzung ist an einen bestimmten Dienst gebunden, und ihr Zustand wird als aktiv betrachtet, bis der Agent anders benachrichtigt wird oder die Sitzung abläuft. Jede autorisierte Sitzung hat ein Ablaufdatum, das von Diameter-Servern über das Session-Timeout AVP kommuniziert wird.

Die Aufrechterhaltung des Sitzungszustands kann in bestimmten Anwendungen nützlich sein, wie z. B.:

Protokollübersetzung (z. B. RADIUS <-> Diameter)
Begrenzung der einem bestimmten Benutzer zugewiesenen Ressourcen
Prüfung pro Benutzer oder pro Transaktion

Ein Diameter-Agent KANN für einige Anfragen zustandsbehaftet agieren und für andere zustandslos sein. Eine Diameter-Implementierung KANN für einige Anfragen als ein Typ von Agent fungieren und für andere als ein anderer Typ von Agent.

2.8.1. Relay-Agenten

Relay-Agenten sind Diameter-Agenten, die Anfragen akzeptieren und Nachrichten basierend auf in den Nachrichten gefundenen Informationen (z. B. dem Wert des Destination-Realm AVP Abschnitt 6.6) an andere Diameter-Knoten weiterleiten. Diese Routing-Entscheidung wird unter Verwendung einer Liste unterstützter Realms und bekannter Peers getroffen. Dies wird als Routing-Tabelle bezeichnet, wie in Abschnitt 2.7 weiter definiert.

Relays können beispielsweise verwendet werden, um Anfragen von mehreren Network Access Servern (NASes) innerhalb eines gemeinsamen geografischen Gebiets (Point of Presence, POP) zu aggregieren. Die Verwendung von Relays ist vorteilhaft, da sie die Notwendigkeit eliminiert, dass NASes mit den notwendigen Sicherheitsinformationen konfiguriert werden, die sie sonst benötigen würden, um mit Diameter-Servern in anderen Realms zu kommunizieren. Ebenso reduziert dies die Konfigurationslast auf Diameter-Servern, die sonst notwendig wäre, wenn NASes hinzugefügt, geändert oder gelöscht werden.