6.1. Panoramica dell'instradamento delle richieste Diameter (Diameter Request Routing Overview)

6.1. Panoramica dell'instradamento delle richieste Diameter (Diameter Request Routing Overview)

Una richiesta viene inviata verso la destinazione finale usando una delle seguenti tre combinazioni degli AVP Destination-Realm e Destination-Host:

• Una richiesta che non può essere proxyata (come un CER) NON DEVE contenere né Destination-Realm né Destination-Host.

• Una richiesta che deve essere inviata a un home server che serve un realm specifico, ma non a un server determinato (come la prima richiesta di una serie di round trip), DEVE contenere un AVP Destination-Realm e NON DEVE contenere un AVP Destination-Host. Per i client Diameter il valore dell'AVP Destination-Realm PUÒ essere estratto dall'AVP User-Name o con altri metodi.

• Altrimenti, una richiesta che deve essere inviata a un home server specifico tra quelli che servono un dato realm DEVE contenere sia Destination-Realm sia Destination-Host.

L'AVP Destination-Host si usa come sopra quando la destinazione della richiesta è fissa, e ciò include:

• Richieste di autenticazione che si estendono su più round trip.

• Un messaggio Diameter che usa un meccanismo di sicurezza basato su una chiave di sessione precondivisa tra sorgente e destinazione finale del messaggio.

• Messaggi avviati dal server che DEVONO essere ricevuti da un client Diameter specifico (ad es. dispositivo di accesso), come il messaggio Abort-Session-Request, usato per richiedere la terminazione della sessione di un determinato utente.

Nota: un agente può inoltrare una richiesta verso un host descritto in Destination-Host solo se tale host è incluso nella sua peer table (vedere Sezione 2.6). Altrimenti la richiesta viene instradata solo in base a Destination-Realm (vedere Sezione 6.1.6).

Alla ricezione di un messaggio, l'elaborazione avviene in questo ordine:

• Se il messaggio è destinato all'host locale, si seguono le procedure di Sezione 6.1.4.

• Se è destinato a un peer Diameter con cui l'host locale può comunicare direttamente, si seguono le procedure di Sezione 6.1.5. Questo è il «Request Forwarding».

• Si segue la procedura di Sezione 6.1.6, nota come «Request Routing».

• Se nessuna delle precedenti ha successo, si restituisce una risposta con Result-Code DIAMETER_UNABLE_TO_DELIVER e bit 'E' impostato.

Affinché l'instradamento dei messaggi Diameter funzioni in un dominio amministrativo, tutti i nodi Diameter nel realm DEVONO essere peer.

La panoramica in questa sezione (6.1) intende fornire linee guida generali agli sviluppatori Diameter. Le implementazioni possono usare metodi diversi da quelli qui descritti purché rispettino i requisiti delle Sezioni da 6.1.1 a 6.1.9. Per i dettagli sulla gestione degli errori vedere Sezione 7.