3. Diameter-Header

3. Diameter-Header

Eine Zusammenfassung des Diameter-Header-Formats wird unten gezeigt. Die Felder werden in Netzwerk-Byte-Reihenfolge übertragen.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |                 Message Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Command Flags |                  Command Code                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Application-ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Hop-by-Hop Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      End-to-End Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

Version

Dieses Versionsfeld MUSS auf 1 gesetzt werden, um Diameter Version 1 anzuzeigen.

Message Length (Nachrichtenlänge)

Das Feld Message Length umfasst drei Oktette und gibt die Länge der Diameter-Nachricht einschließlich der Header-Felder und der aufgefüllten AVPs an. Daher ist das Feld Message Length immer ein Vielfaches von 4.

Command Flags (Befehlsflags)

Das Feld Command Flags umfasst acht Bits. Die folgenden Bits sind zugewiesen:

      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |R P E T r r r r|
     +-+-+-+-+-+-+-+-+

R(equest) (Anfrage)

Wenn gesetzt, ist die Nachricht eine Anfrage. Wenn gelöscht, ist die Nachricht eine Antwort.

P(roxiable) (Proxyfähig)

Wenn gesetzt, KANN die Nachricht per Proxy übertragen, weitergeleitet oder umgeleitet werden. Wenn gelöscht, MUSS die Nachricht lokal verarbeitet werden.

E(rror) (Fehler)

Wenn gesetzt, enthält die Nachricht einen Protokollfehler, und die Nachricht entspricht nicht dem für diesen Befehl beschriebenen CCF. Nachrichten mit gesetztem 'E'-Bit werden üblicherweise als Fehlernachrichten bezeichnet. Dieses Bit DARF NICHT in Anfragenachrichten gesetzt werden (siehe Abschnitt 7.2).

T(Potentially retransmitted message) (Möglicherweise erneut übertragene Nachricht)

Dieses Flag wird nach einem Link-Failover-Verfahren gesetzt, um beim Entfernen doppelter Anfragen zu helfen. Es wird beim erneuten Senden von noch nicht bestätigten Anfragen gesetzt, als Hinweis auf ein mögliches Duplikat aufgrund eines Link-Ausfalls. Dieses Bit MUSS beim erstmaligen Senden einer Anfrage gelöscht werden; andernfalls MUSS der Sender dieses Flag setzen. Diameter-Agenten müssen sich nur um die Anzahl der Anfragen kümmern, die sie basierend auf einer einzelnen empfangenen Anfrage senden; Neuübertragungen durch andere Entitäten müssen nicht verfolgt werden. Diameter-Agenten, die eine Anfrage mit gesetztem T-Flag empfangen, MÜSSEN das T-Flag in der weitergeleiteten Anfrage gesetzt lassen. Dieses Flag DARF NICHT gesetzt werden, wenn eine Fehlerantwortnachricht (z.B. ein Protokollfehler) für die frühere Nachricht empfangen wurde. Es kann nur in Fällen gesetzt werden, in denen keine Antwort vom Server für eine Anfrage empfangen wurde und die Anfrage erneut gesendet wurde. Dieses Flag DARF NICHT in Antwortnachrichten gesetzt werden.

r(eserved) (Reserviert)

Diese Flag-Bits sind für zukünftige Verwendung reserviert; sie MÜSSEN auf Null gesetzt und vom Empfänger ignoriert werden.

Command Code (Befehlscode)

Das Feld Command Code umfasst drei Oktette und wird verwendet, um den mit der Nachricht verbundenen Befehl zu kommunizieren. Der 24-Bit-Adressraum wird von der IANA verwaltet (siehe Abschnitt 3.1). Die Befehlscode-Werte 16.777.214 und 16.777.215 (Hexadezimalwerte FFFFFE-FFFFFF) sind für experimentelle Verwendung reserviert (siehe Abschnitt 11.2).

Application-ID (Anwendungs-ID)

Application-ID umfasst vier Oktette und wird verwendet, um zu identifizieren, für welche Anwendung die Nachricht gilt. Die Anwendung kann eine Authentifizierungsanwendung, eine Abrechnungsanwendung oder eine anbieterspezifische Anwendung sein.

Der Wert des Feldes Application-ID im Header MUSS derselbe sein wie jeder relevante Application-Id-AVP, der in der Nachricht enthalten ist.

Hop-by-Hop Identifier (Hop-für-Hop-Identifikator)

Der Hop-by-Hop-Identifikator ist ein vorzeichenloses 32-Bit-Integer-Feld (in Netzwerk-Byte-Reihenfolge), das beim Abgleichen von Anfragen und Antworten hilft. Der Sender MUSS sicherstellen, dass der Hop-by-Hop-Identifikator in einer Anfrage zu jedem gegebenen Zeitpunkt auf einer gegebenen Verbindung eindeutig ist, und er KANN versuchen sicherzustellen, dass die Nummer über Neustarts hinweg eindeutig ist. Der Sender einer Antwortnachricht MUSS sicherstellen, dass das Feld Hop-by-Hop Identifier denselben Wert enthält, der in der entsprechenden Anfrage gefunden wurde. Der Hop-by-Hop-Identifikator ist normalerweise eine monoton steigende Zahl, deren Startwert zufällig generiert wurde. Eine Antwortnachricht, die mit einem unbekannten Hop-by-Hop-Identifikator empfangen wird, MUSS verworfen werden.

End-to-End Identifier (Ende-zu-Ende-Identifikator)

Der Ende-zu-Ende-Identifikator ist ein vorzeichenloses 32-Bit-Integer-Feld (in Netzwerk-Byte-Reihenfolge), das zur Erkennung doppelter Nachrichten verwendet wird. Nach einem Neustart KÖNNEN Implementierungen die oberen 12 Bits so setzen, dass sie die unteren 12 Bits der aktuellen Zeit enthalten, und die unteren 20 Bits auf einen Zufallswert setzen. Sender von Anfragenachrichten MÜSSEN in jede Nachricht einen eindeutigen Identifikator einfügen. Der Identifikator MUSS für einen Zeitraum von mindestens 4 Minuten lokal eindeutig bleiben, selbst über Neustarts hinweg. Der Urheber einer Antwortnachricht MUSS sicherstellen, dass das Feld End-to-End Identifier denselben Wert enthält, der in der entsprechenden Anfrage gefunden wurde. Der Ende-zu-Ende-Identifikator DARF NICHT von Diameter-Agenten jeglicher Art modifiziert werden. Die Kombination aus dem Origin-Host-AVP (Abschnitt 6.3) und diesem Feld wird verwendet, um Duplikate zu erkennen. Doppelte Anfragen SOLLTEN dazu führen, dass dieselbe Antwort übertragen wird (abgesehen vom Feld Hop-by-Hop Identifier und allen möglicherweise vorhandenen Routing-AVPs), und sie DÜRFEN NICHT irgendeinen Zustand beeinflussen, der bei der Verarbeitung der ursprünglichen Anfrage gesetzt wurde. Doppelte Antwortnachrichten, die lokal verbraucht werden sollen (siehe Abschnitt 6.2), SOLLTEN stillschweigend verworfen werden.

AVPs

AVPs sind eine Methode zur Kapselung von Informationen, die für die Diameter-Nachricht relevant sind. Siehe Abschnitt 4 für weitere Informationen zu AVPs.