6.1. Vue d'ensemble du routage des requêtes Diameter (Diameter Request Routing Overview)

6.1. Vue d'ensemble du routage des requêtes Diameter (Diameter Request Routing Overview)

Une requête est envoyée vers sa destination finale en utilisant l'une des trois combinaisons suivantes des AVP Destination-Realm et Destination-Host :

• Une requête qui ne peut pas être proxifiée (telle qu'un CER) NE DOIT PAS contenir d'AVP Destination-Realm ni Destination-Host.

• Une requête devant être envoyée à un serveur d'origine desservant un realm spécifique, mais pas à un serveur particulier (telle que la première requête d'une série d'allers-retours), DOIT contenir un AVP Destination-Realm et NE DOIT PAS contenir d'AVP Destination-Host. Pour les clients Diameter, la valeur de l'AVP Destination-Realm PEUT être extraite de l'AVP User-Name, ou par d'autres méthodes.

• Sinon, une requête devant être envoyée à un serveur d'origine précis parmi ceux desservant un realm donné DOIT contenir à la fois les AVP Destination-Realm et Destination-Host.

L'AVP Destination-Host est utilisé comme décrit ci-dessus lorsque la destination de la requête est fixe, ce qui inclut :

• Les requêtes d'authentification s'étendant sur plusieurs allers-retours.

• Un message Diameter utilisant un mécanisme de sécurité fondé sur une clé de session préétablie partagée entre la source et la destination finale du message.

• Les messages initiés par le serveur qui DOIVENT être reçus par un client Diameter spécifique (p. ex. équipement d'accès), tels que le message Abort-Session-Request, utilisé pour demander la terminaison de la session d'un utilisateur particulier.

Notez qu'un agent ne peut transférer une requête vers un hôte décrit dans l'AVP Destination-Host que si cet hôte figure dans sa table des pairs (voir la Section 2.6). Sinon, la requête est routée uniquement sur la base du Destination-Realm (voir la Section 6.1.6).

Lorsqu'un message est reçu, il est traité dans l'ordre suivant :

• Si le message est destiné à l'hôte local, les procédures énumérées à la Section 6.1.4 sont suivies.

• Si le message est destiné à un pair Diameter avec lequel l'hôte local peut communiquer directement, les procédures énumérées à la Section 6.1.5 sont suivies. On parle de « Request Forwarding » (transfert de requête).

• La procédure énumérée à la Section 6.1.6 est suivie, ce qu'on appelle « Request Routing » (routage de requête).

• Si aucune des options ci-dessus ne réussit, une réponse est renvoyée avec le Result-Code défini à DIAMETER_UNABLE_TO_DELIVER, avec le bit 'E' positionné.

Pour que le routage des messages Diameter fonctionne au sein d'un domaine administratif, tous les nœuds Diameter du realm DOIVENT être des pairs.

La vue d'ensemble de cette section (6.1) vise à fournir des lignes directrices générales aux développeurs Diameter. Les implémentations peuvent utiliser d'autres méthodes que celles décrites ici tant qu'elles respectent les exigences des Sections 6.1.1 à 6.1.9. Voir la Section 7 pour plus de détails sur la gestion des erreurs.