BroadNet
DIAMETERGrundlagen

DIAMETER-Basisprotokoll: RFC 6733 erklärt

Aktualisiert am 4 Min. LesezeitStandardsbasiert
Direkte Antwort

DIAMETER (IETF RFC 6733) ist das AAA- und Signalisierungsprotokoll für LTE, IMS und 5G-Zusammenwirken. Es überträgt Request/Answer-Command-Paare — jedes ein 20-Byte-Header plus AVPs — über SCTP oder TCP mit TLS. Peers verhandeln Fähigkeiten mit CER/CEA, überwachen die Erreichbarkeit mit DWR/DWA und fahren sauber mit DPR/DPA herunter.

§01

Was DIAMETER ist

DIAMETER ist das von der IETF in RFC 6733 definierte Basisprotokoll für Authentifizierung, Autorisierung und Accounting (AAA) und der Transport, den 3GPP für die LTE- und IMS-Steuerungsebene gewählt hat. Es ersetzte RADIUS in großen Betreibernetzen und ist auf der Paketseite das Gegenstück zu SS7/MAP auf der Legacy-Seite — es überträgt Subskriptions- und Mobilitätsverwaltung (S6a zum HSS), Policy und Charging (Gx, Gy) sowie IMS-Registrierung (Cx/Dx). Alles läuft als Request/Answer-Command-Paare zwischen benannten Peers ab, die durch eine Diameter Identity (ein FQDN) identifiziert und in Realms gruppiert werden.

§02

Der Nachrichten-Header

Jede DIAMETER-Nachricht beginnt mit einem festen 20-Oktett-Header, gefolgt von einer variablen Liste von AVPs. Der Header trägt eine Version (immer 1), eine 24-Bit-Message-Length, ein Command-Flags-Oktett, einen 24-Bit-Command-Code, eine 32-Bit-Application-Id, die die Anwendung benennt, zu der die Nachricht gehört, sowie zwei Identifikatoren. Der Hop-by-Hop Identifier ordnet einen Request seiner Answer zwischen zwei benachbarten Peers zu und wird von jedem Proxy neu geschrieben; der End-to-End Identifier wird vom Absender gesetzt, über den gesamten Pfad unverändert bewahrt und dient der Erkennung von Duplikaten.

RFC 6733 DIAMETER-Nachrichten-Header (20 Oktette)text
0                   1                   2                   3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version=1    |            Message Length (24)             |
| Command Flags |            Command Code (24)               |
|                    Application-Id (32)                     |
|                 Hop-by-Hop Identifier (32)                 |
|                 End-to-End Identifier (32)                 |
|  AVPs ...                                                  |
Command Flags:  R P E T r r r r
§03

Command-Flags und Command Codes

Ein Command Code plus die Application-Id benennt die Operation; die Answer verwendet denselben Command Code mit gelöschtem Request-Bit erneut. Vier Command-Flags tragen die Nachrichtensemantik. R (Request) unterscheidet einen Request von einer Answer. P (Proxiable) besagt, dass die Nachricht geproxyt, weitergeleitet oder umgeleitet statt lokal verarbeitet werden darf. E (Error) kennzeichnet eine Protokollfehler-Answer. T (potenziell erneut übertragen) kennzeichnet einen nach einem Link-Failover erneut gesendeten Request, damit der Empfänger sich gegen Duplikate schützen kann. Das Basisprotokoll definiert die Housekeeping-Commands; Anwendungen wie S6a, Gx und Cx definieren ihre eigenen Command Codes darauf.

DIAMETER-Basis-Command-Codes (RFC 6733)
BefehlCodeZweck
CER / CEA257Capabilities-Exchange – Aushandlung unterstützter Anwendungen beim Verbindungsaufbau
DWR / DWA280Device-Watchdog — Peer-Liveness / Keepalive (RFC 3539)
DPR / DPA282Disconnect-Peer – geordnete Verbindungsbeendigung
RAR / RAA258Re-Auth – der Server fordert den Client auf, eine Sitzung erneut zu autorisieren
STR / STA275Session-Termination – der Client beendet eine autorisierte Sitzung
ASR / ASA274Abort-Session – der Server erzwingt das Beenden einer Sitzung
ACR / ACA271Accounting-Request/Answer (Basis-Accounting)
§04

Fähigkeitsaustausch: CER / CEA

Unmittelbar nach dem Öffnen einer Transportverbindung tauschen die beiden Peers einen Capabilities-Exchange-Request und -Answer aus (Command 257, Application-Id 0). Jede Seite kündigt ihren Origin-Host und Origin-Realm, ihre Host-IP-Address, eine Vendor-Id und — entscheidend — die Menge der von ihr unterstützten Anwendungen über die AVPs Auth-Application-Id, Acct-Application-Id und Vendor-Specific-Application-Id an. Teilen die Peers keine gemeinsame Anwendung, wird die Verbindung abgelehnt. Über CER/CEA erfährt ein Knoten, ob der Peer S6a, Gx oder Cx sprechen kann, bevor Anwendungsverkehr fließt, und dies geschieht genau einmal pro Verbindung.

§05

Keepalive und Herunterfahren: DWR / DPR

DIAMETER nutzt den Watchdog aus RFC 3539, um einen toten Peer schneller zu erkennen, als der Transport es allein könnte. Ist eine Verbindung im Leerlauf, sendet ein Peer einen Device-Watchdog-Request (Command 280) und erwartet innerhalb des Watchdog-Intervalls eine Device-Watchdog-Answer; wiederholt ausbleibende Antworten versetzen den Peer in einen Fehlerzustand und der Verkehr wird auf eine Alternative umgeleitet. Um eine Verbindung bewusst zu schließen — für Wartung oder Neukonfiguration — sendet ein Peer einen Disconnect-Peer-Request (Command 282) mit einem Disconnect-Cause (REBOOTING, BUSY oder DO_NOT_WANT_TO_TALK_TO_YOU) und überlässt der Gegenseite die Entscheidung, ob sie sich neu verbindet.

§06

Transport: SCTP und TCP mit TLS

RFC 6733 verlangt die Unterstützung sowohl von SCTP (RFC 4960) als auch von TCP, wobei SCTP für die Signalisierung bevorzugt wird, weil sein Multi-Streaming Head-of-Line-Blocking vermeidet und sein Multi-Homing Pfadredundanz bietet. Der Well-known-Port ist 3868. Die Sicherheit wird durch TLS über TCP oder DTLS über SCTP bereitgestellt; innerhalb einer vertrauenswürdigen Betreiberdomäne betreiben viele Deployments stattdessen IPsec auf der Netzwerkschicht. DIAMETER besitzt keine eigene In-Band-Nachrichtenauthentifizierung, weshalb die Transportsicherheit und die Edge-Filterung, die unter Diameter-Roaming-Sicherheit behandelt werden, von Bedeutung sind.

Häufig gestellte Fragen

Häufig gestellte Fragen

Was ist das DIAMETER-Basisprotokoll?

Es ist das in IETF RFC 6733 definierte AAA- und Signalisierungsprotokoll, das als Steuerungsebenen-Transport für LTE, IMS und 5G-Zusammenwirken dient. Es überträgt Request/Answer-Command-Paare — ein 20-Byte-Header plus AVPs — über SCTP oder TCP mit TLS und definiert Fähigkeitsaustausch, Watchdog-Keepalive und geordnetes Trennen.

Was bedeuten die R-, P-, E- und T-Flags?

R kennzeichnet einen Request (in der Answer gelöscht). P kennzeichnet die Nachricht als Proxiable — sie darf weitergeleitet, geproxyt oder umgeleitet werden. E kennzeichnet eine Error-Answer. T kennzeichnet einen Request als potenziell nach einem Failover erneut übertragen, damit der Empfänger ein Duplikat über den End-to-End Identifier erkennen kann.

Was ist der Unterschied zwischen dem Hop-by-Hop- und dem End-to-End-Identifier?

Der Hop-by-Hop Identifier ordnet einen Request seiner Answer zwischen zwei benachbarten Peers zu und wird von jedem Proxy neu geschrieben. Der End-to-End Identifier wird einmalig vom Absender gesetzt, über den gesamten Pfad unverändert bewahrt und zur Erkennung von Duplikaten nach einer erneuten Übertragung genutzt.

Wozu dient der CER/CEA-Austausch?

Capabilities-Exchange-Request/Answer (Command 257) läuft einmalig ab, wenn eine Verbindung geöffnet wird. Peers kündigen ihre Identität und die von ihnen unterstützten Diameter-Anwendungen an (Auth-Application-Id, Vendor-Specific-Application-Id). Wird keine Anwendung geteilt, wird die Verbindung abgelehnt, sodass beide Seiten von vornherein wissen, ob sie S6a, Gx oder Cx sprechen können.

Welchen Port und Transport nutzt DIAMETER?

DIAMETER nutzt den Well-known-Port 3868 über SCTP oder TCP, wobei SCTP für die Signalisierung wegen Multi-Streaming und Multi-Homing bevorzugt wird. Die Sicherheit erfolgt über TLS über TCP oder DTLS über SCTP; innerhalb einer vertrauenswürdigen Betreiberdomäne ist stattdessen IPsec auf der Netzwerkschicht üblich.

Wie erkennt ein DIAMETER-Peer, dass sein Partner ausgefallen ist?

Er nutzt den Device-Watchdog aus RFC 3539: Auf einer im Leerlauf befindlichen Verbindung sendet ein Peer einen Device-Watchdog-Request (Command 280) und erwartet innerhalb des Watchdog-Intervalls eine Device-Watchdog-Answer. Wiederholt ausbleibende Antworten versetzen den Peer in einen Fehlerzustand und der Verkehr wird auf einen alternativen Peer umgeleitet.

Referenzen

Quellenspezifikationen

Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)

BNWird vom BroadNet -Entwicklungsteam betreut.·Messaging in Carrier-Qualität seit 2003
Hänge es an den Draht

Entwicklung mit echtem SMPP Binding und REST-API.

Fordern Sie Testzugriff mit echten Testschlüsseln an: Senden Sie zunächst an Ihre eigene verifizierte Nummer und gehen Sie dann in über 200 Ländern zum Produktivbetrieb über, sobald Ihre Absenderidentität und die Routen genehmigt wurden.