DIAMETER

Struttura

Diameter è definito in termini di un protocollo base e di un set di applicazioni. Questa progettazione consente al protocollo di essere esteso a nuove tecnologie d'accesso. Il protocollo base fornisce meccanismi di base per un trasporto affidabile, delivery dei messaggi e gestione degli errori, e deve essere utilizzato in concomitanza con un'applicazione Diameter. Ogni applicazione si affida ai servizi del protocollo base per supportare uno specifico tipo di accesso alla rete. Le due principali applicazioni sono Mobile IPv4 e NASREQ (Network Access Server Requirements). L'applicazione NASREQ supporta PPP/IP dial-in ed è inteso come sostituto di RADIUS.

Il protocollo base definisce il formato di un messaggio Diameter di base. I dati sono trasportati nel messaggio Diameter come collezione di AVP (Attribute Value Pair); un AVP è l'equivalente di un attributo RADIUS e consiste di campi multipli: AVP Code, Length, Flags e Data. Alcuni AVP sono utilizzati dal protocollo base di Diameter; altri AVP servono alle applicazioni Diameter; altri ancora possono essere usati dall'applicazione di alto livello dell'end system che impiega Diameter.

Diameter, a differenza di RADIUS, opera su un layer di trasporto affidabile (TCP o SCTP) che fornisce controllo di flusso, conferme a livello trasporto e ritrasmissioni. Mentre TCP è universalmente noto, Stream Control Transmission Protocol (SCTP) è qualcosa di simile ad un nuovo protocollo di trasporto IP, esistente allo stesso livello di UDP o TCP. Nel 2000 SCTP è stato proposto come standard ed è specificato nella RFC 2960.

Definizioni

Oltre a client e server, il protocollo Diameter definisce altri tipi di nodi:

• un Client Diameter è un dispositivo che accede alla rete in maniera controllata. Anche un NAS è un client Diameter;
• un Server Diameter è l'entità che gestisce le richieste di autenticazione, autorizzazione e accounting per un dominio;
• un Relay Agent si occupa del routing dei messaggi Diameter basandosi sulle informazioni contenute nel messaggio. Le decisioni di routing vengono prese usando una lista di domini supportati e peer conosciuti. I Relay Agent sono trasparenti; possono modificare i messaggi solo inserendo o cancellando informazioni di routing, ma non possono modificare altre porzioni del messaggio;
• un Proxy Agent si occupa anch'esso del routing; può modificare i messaggi per implementare decisioni di policy, come ad esempio il controllo di utilizzo delle risorse;
• un Redirect Agent si occupa ancora del routing, generalmente agendo come sorgente centralizzata di mappe di indirizzi di dominio per i membri dello stesso. Diversamente dagli altri tipi di agent, un Redirect Agent restituisce uno speciale tipo di messaggio di risposta al peer che ha inviato la richiesta. Questo messaggio di risposta contiene informazioni di routing che consentono al peer di reinviare la richiesta, direttamente alla corretta destinazione. Un Redirect Agent non ritarda le richieste;
• un Translation Agent effettua “traduzioni” tra protocolli diversi, per esempio da RADIUS a Diameter. In questo caso, il Translation Agent supporta la migrazione da RADIUS a Diameter, consentendo conversioni del server a Diameter, per esempio.

Specifiche

Un messaggio Diameter consiste di un header di lunghezza fissa di 20 byte, seguito da un numero variabile di AVP. Il formato dell'header è il seguente:

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     |                                             |
|0 0 0 0 0 0 0 1|              Message Length                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |                                             |
|R P E T x x x x|              Command-Code                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Application-ID                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Hop-by-hop Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End-to-End Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

L'header del messaggio Diameter contiene due identificatori da 32 bit. L'Hop-by-hop Identifier aiuta nella corrispondenza tra richieste e risposte. Nelle richieste, questo identificatore è sostituito ad ogni hop fin quando il messaggio non viene inoltrato alla sua destinazione finale. Il mittente del messaggio di risposta restituisce lo stesso valore che ha trovato nella corrispondente richiesta. L'End-to-end Identifier, assieme all'identità dell'host di origine, è utilizzato per riconoscere messaggi di richiesta duplicati, e non viene mai modificato fino all'arrivo a destinazione della richiesta. Il mittente della risposta restituisce lo stesso valore che ha trovato nella richiesta corrispondente.

Diameter ammette tipi di dati come Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, OctetString e Grouped; un AVP Grouped è un AVP i cui dati sono una sequenza di AVP.

Sono definiti anche tipi di dati derivati: enumerativi (derivati da integer32), DiameterIdentity (derivati da octetstring), temporali (derivati da unsigned32), UTF8String (derivati da octetstring), IPFilterRule (derivati da octetstring), e QoSFilterRule (derivati da octetstring).

Ogni processo Diameter che gira su un host genera una Diameter Identity, che è una stringa con la sintassi di un Uniform Resource Identifier (URI) che rappresenta il FQDN (Fully Qualified Domain Name) dell'host, una delle porte in ascolto per connessioni in entrata, il protocollo di trasporto (TCP o SCTP), il protocollo AAA (Diameter), e il security transport (nessuno o TLS).

Poiché l'identità trasporta il FQDN dell'host, e poiché più processi Diameter su un singolo host non possono stare in ascolto sulla stessa porta di un dato protocollo, il DiameterIdentity di ogni processo ha la garanzia di essere unico.

Per quanto riguarda i messaggi, ce ne sono di due tipi: Richiesta e Risposta. Ogni messaggio di risposta include un Result-Code AVP, il cui valore è un intero che indica se una particolare richiesta è stata completata con successo oppure se si è verificato un errore. Ciascun messaggio Diameter contiene la Diameter Identity del processo mittente nell'host di origine, ed anche il dominio di tale processo. I messaggi di richiesta possono essere “proxiable” o “non-proxiable”, a seconda di uno dei flag nell'header. Le richieste non-proxiable sono intese strettamente per il next-hop peer, e non vengono mai inoltrate oltre. Le richieste proxiable sono instradabili, e instradate a seconda del dominio. Ogni richiesta proxiable contiene il dominio target nel Destination-Realm AVP.

Un messaggio Diameter pertinente a una specifica sessione utente include un Session-Id AVP, un valore costante per tutta la vita della sessione. Questo valore è una stringa di testo globalmente ed eternamente unica, atta a identificare univocamente una sessione utente senza far riferimento a nessun'altra informazione. Il client Diameter che avvia la sessione crea il Session-Id, il quale inizia con la stringa Diameter Identity del mittente e continua con una sequenza che garantisce unicità sia topologica sia temporale.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      AVP Code                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |                                             |
|V M P x x x x x|                AVP Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Vendor-ID (if vendor-specific AVP)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AVP Data ... (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-