3. En-tête Diameter

3. En-tête Diameter

Un résumé du format de l'en-tête Diameter est présenté ci-dessous. Les champs sont transmis dans l'ordre des octets réseau.

    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

Ce champ Version DOIT être défini sur 1 pour indiquer Diameter Version 1.

Message Length (Longueur du message)

Le champ Message Length fait trois octets et indique la longueur du message Diameter, y compris les champs d'en-tête et les AVP remplis. Ainsi, le champ Message Length est toujours un multiple de 4.

Command Flags (Drapeaux de commande)

Le champ Command Flags fait huit bits. Les bits suivants sont attribués:

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

R(equest) (Requête)

S'il est défini, le message est une requête. S'il est effacé, le message est une réponse.

P(roxiable) (Proxyable)

S'il est défini, le message PEUT être proxy, relayé ou redirigé. S'il est effacé, le message DOIT être traité localement.

E(rror) (Erreur)

S'il est défini, le message contient une erreur de protocole, et le message ne sera pas conforme au CCF décrit pour cette commande. Les messages avec le bit 'E' défini sont communément appelés messages d'erreur. Ce bit NE DOIT PAS être défini dans les messages de requête (voir Section 7.2).

T(Potentially retransmitted message) (Message potentiellement retransmis)

Ce drapeau est défini après une procédure de basculement de lien, pour faciliter la suppression des requêtes en double. Il est défini lors de la retransmission de requêtes pas encore acquittées, comme indication d'un éventuel doublon dû à une défaillance de lien. Ce bit DOIT être effacé lors de l'envoi d'une requête pour la première fois; sinon, l'expéditeur DOIT définir ce drapeau. Les agents Diameter n'ont besoin de se préoccuper que du nombre de requêtes qu'ils envoient en fonction d'une seule requête reçue; les retransmissions par d'autres entités n'ont pas besoin d'être suivies. Les agents Diameter qui reçoivent une requête avec le drapeau T défini DOIVENT maintenir le drapeau T défini dans la requête transmise. Ce drapeau NE DOIT PAS être défini si un message de réponse d'erreur (par exemple, une erreur de protocole) a été reçu pour le message précédent. Il ne peut être défini que dans les cas où aucune réponse n'a été reçue du serveur pour une requête, et la requête a été envoyée à nouveau. Ce drapeau NE DOIT PAS être défini dans les messages de réponse.

r(eserved) (Réservé)

Ces bits de drapeau sont réservés pour une utilisation future; ils DOIVENT être définis sur zéro et ignorés par le récepteur.

Command Code (Code de commande)

Le champ Command Code fait trois octets et est utilisé pour communiquer la commande associée au message. L'espace d'adressage de 24 bits est géré par l'IANA (voir Section 3.1). Les valeurs de code de commande 16,777,214 et 16,777,215 (valeurs hexadécimales FFFFFE-FFFFFF) sont réservées à un usage expérimental (voir Section 11.2).

Application-ID (ID d'application)

Application-ID fait quatre octets et est utilisé pour identifier l'application à laquelle le message est applicable. L'application peut être une application d'authentification, une application de comptabilité ou une application spécifique au fournisseur.

La valeur du champ Application-ID dans l'en-tête DOIT être identique à celle de tout AVP Application-Id pertinent contenu dans le message.

Hop-by-Hop Identifier (Identifiant saut par saut)

L'identifiant saut par saut est un champ entier non signé de 32 bits (dans l'ordre des octets réseau) qui aide à faire correspondre les requêtes et les réponses. L'expéditeur DOIT s'assurer que l'identifiant saut par saut dans une requête est unique sur une connexion donnée à tout moment donné, et il PEUT tenter de s'assurer que le numéro est unique même après les redémarrages. L'expéditeur d'un message de réponse DOIT s'assurer que le champ Hop-by-Hop Identifier contient la même valeur que celle trouvée dans la requête correspondante. L'identifiant saut par saut est normalement un numéro à augmentation monotone, dont la valeur de départ a été générée aléatoirement. Un message de réponse reçu avec un identifiant saut par saut inconnu DOIT être rejeté.

End-to-End Identifier (Identifiant de bout en bout)

L'identifiant de bout en bout est un champ entier non signé de 32 bits (dans l'ordre des octets réseau) qui est utilisé pour détecter les messages en double. Lors du redémarrage, les implémentations PEUVENT définir les 12 bits de poids fort pour contenir les 12 bits de poids faible de l'heure actuelle, et les 20 bits de poids faible à une valeur aléatoire. Les expéditeurs de messages de requête DOIVENT insérer un identifiant unique sur chaque message. L'identifiant DOIT rester localement unique pendant une période d'au moins 4 minutes, même à travers les redémarrages. L'initiateur d'un message de réponse DOIT s'assurer que le champ End-to-End Identifier contient la même valeur que celle trouvée dans la requête correspondante. L'identifiant de bout en bout NE DOIT PAS être modifié par des agents Diameter de quelque nature que ce soit. La combinaison de l'AVP Origin-Host (Section 6.3) et de ce champ est utilisée pour détecter les doublons. Les requêtes en double DEVRAIENT provoquer la transmission de la même réponse (modulo le champ Hop-by-Hop Identifier et tous les AVP de routage qui peuvent être présents), et elles NE DOIVENT PAS affecter tout état qui a été défini lors du traitement de la requête originale. Les messages de réponse en double qui doivent être consommés localement (voir Section 6.2) DEVRAIENT être silencieusement rejetés.

AVPs

Les AVP sont une méthode d'encapsulation des informations pertinentes pour le message Diameter. Voir Section 4 pour plus d'informations sur les AVP.