3. Intestazione Diameter

Di seguito è mostrato un riepilogo del formato dell'intestazione Diameter. I campi sono trasmessi in ordine di byte di rete.

    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 (Versione)

Questo campo Version DEVE essere impostato su 1 per indicare Diameter Versione 1.

Message Length (Lunghezza del messaggio)

Il campo Message Length è di tre ottetti e indica la lunghezza del messaggio Diameter inclusi i campi di intestazione e gli AVP riempiti. Pertanto, il campo Message Length è sempre un multiplo di 4.

Command Flags (Flag del comando)

Il campo Command Flags è di otto bit. Sono assegnati i seguenti bit:

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

R(equest) (Richiesta)

Se impostato, il messaggio è una richiesta. Se azzerato, il messaggio è una risposta.

P(roxiable) (Proxy)

Se impostato, il messaggio PUÒ essere inviato tramite proxy, ritrasmesso o reindirizzato. Se azzerato, il messaggio DEVE essere elaborato localmente.

E(rror) (Errore)

Se impostato, il messaggio contiene un errore di protocollo e il messaggio non sarà conforme al CCF descritto per questo comando. I messaggi con il bit 'E' impostato sono comunemente chiamati messaggi di errore. Questo bit NON DEVE essere impostato nei messaggi di richiesta (vedere Sezione 7.2).

T(Potentially retransmitted message) (Messaggio potenzialmente ritrasmesso)

Questo flag viene impostato dopo una procedura di failover del collegamento, per aiutare a rimuovere le richieste duplicate. Viene impostato quando si inviano nuovamente richieste non ancora confermate, come indicazione di un possibile duplicato dovuto a un guasto del collegamento. Questo bit DEVE essere azzerato quando si invia una richiesta per la prima volta; altrimenti, il mittente DEVE impostare questo flag. Gli agenti Diameter devono solo preoccuparsi del numero di richieste che inviano in base a una singola richiesta ricevuta; le ritrasmissioni da altre entità non devono essere tracciate. Gli agenti Diameter che ricevono una richiesta con il flag T impostato DEVONO mantenere il flag T impostato nella richiesta inoltrata. Questo flag NON DEVE essere impostato se è stato ricevuto un messaggio di risposta di errore (ad esempio, un errore di protocollo) per il messaggio precedente. Può essere impostato solo nei casi in cui non è stata ricevuta alcuna risposta dal server per una richiesta e la richiesta è stata inviata di nuovo. Questo flag NON DEVE essere impostato nei messaggi di risposta.

r(eserved) (Riservato)

Questi bit di flag sono riservati per uso futuro; DEVONO essere impostati a zero e ignorati dal ricevitore.

Command Code (Codice comando)

Il campo Command Code è di tre ottetti ed è utilizzato per comunicare il comando associato al messaggio. Lo spazio di indirizzamento a 24 bit è gestito da IANA (vedere Sezione 3.1). I valori del codice comando 16.777.214 e 16.777.215 (valori esadecimali FFFFFE-FFFFFF) sono riservati per uso sperimentale (vedere Sezione 11.2).

Application-ID (ID applicazione)

Application-ID è di quattro ottetti ed è utilizzato per identificare a quale applicazione è applicabile il messaggio. L'applicazione può essere un'applicazione di autenticazione, un'applicazione di contabilità o un'applicazione specifica del fornitore.

Il valore del campo Application-ID nell'intestazione DEVE essere lo stesso di qualsiasi AVP Application-Id rilevante contenuto nel messaggio.

Hop-by-Hop Identifier (Identificatore hop-by-hop)

L'identificatore Hop-by-Hop è un campo intero senza segno a 32 bit (in ordine di byte di rete) che aiuta nell'abbinamento di richieste e risposte. Il mittente DEVE assicurarsi che l'identificatore Hop-by-Hop in una richiesta sia unico su una determinata connessione in un dato momento, e PUÒ tentare di garantire che il numero sia unico tra i riavvii. Il mittente di un messaggio di risposta DEVE assicurarsi che il campo Hop-by-Hop Identifier contenga lo stesso valore trovato nella richiesta corrispondente. L'identificatore Hop-by-Hop è normalmente un numero in aumento monotono, il cui valore iniziale è stato generato casualmente. Un messaggio di risposta ricevuto con un identificatore Hop-by-Hop sconosciuto DEVE essere scartato.

End-to-End Identifier (Identificatore end-to-end)

L'identificatore End-to-End è un campo intero senza segno a 32 bit (in ordine di byte di rete) utilizzato per rilevare messaggi duplicati. Al riavvio, le implementazioni POSSONO impostare i 12 bit più significativi per contenere i 12 bit meno significativi del tempo corrente, e i 20 bit meno significativi su un valore casuale. I mittenti di messaggi di richiesta DEVONO inserire un identificatore univoco su ogni messaggio. L'identificatore DEVE rimanere localmente univoco per un periodo di almeno 4 minuti, anche attraverso i riavvii. L'originatore di un messaggio di risposta DEVE assicurarsi che il campo End-to-End Identifier contenga lo stesso valore trovato nella richiesta corrispondente. L'identificatore End-to-End NON DEVE essere modificato da agenti Diameter di alcun tipo. La combinazione dell'AVP Origin-Host (Sezione 6.3) e di questo campo viene utilizzata per rilevare i duplicati. Le richieste duplicate DOVREBBERO causare la trasmissione della stessa risposta (modulo il campo Hop-by-Hop Identifier e qualsiasi AVP di routing che possa essere presente), e NON DEVONO influenzare alcuno stato impostato quando è stata elaborata la richiesta originale. I messaggi di risposta duplicati che devono essere consumati localmente (vedere Sezione 6.2) DOVREBBERO essere silenziosamente scartati.

AVPs

Gli AVP sono un metodo per incapsulare informazioni rilevanti per il messaggio Diameter. Vedere Sezione 4 per ulteriori informazioni sugli AVP.

3. Intestazione Diameter​

3. Intestazione Diameter