Zum Hauptinhalt springen

6.1. Überblick über Diameter-Anfragenrouting (Diameter Request Routing Overview)

6.1. Überblick über Diameter-Anfragenrouting (Diameter Request Routing Overview)​

Eine Anfrage wird zu ihrer endgültigen Destination unter Verwendung einer der folgenden drei Kombinationen der AVPs Destination-Realm und Destination-Host gesendet:

  • Eine Anfrage, die nicht proxyfähig ist (wie ein CER), DARF weder ein Destination-Realm- noch ein Destination-Host-AVP enthalten.

  • Eine Anfrage, die an einen Home-Server geschickt werden soll, der ein bestimmtes Realm bedient, aber nicht an einen bestimmten Server (wie die erste Anfrage einer Serie von Roundtrips), MUSS ein Destination-Realm-AVP enthalten und DARF kein Destination-Host-AVP enthalten. Für Diameter-Clients KANN der Wert des Destination-Realm-AVPs aus dem User-Name-AVP oder auf andere Weise gewonnen werden.

  • Andernfalls MUSS eine Anfrage, die an einen bestimmten Home-Server unter denen geschickt werden soll, die ein gegebenes Realm bedienen, sowohl Destination-Realm- als auch Destination-Host-AVPs enthalten.

Das Destination-Host-AVP wird wie oben beschrieben verwendet, wenn die Zieladresse der Anfrage feststeht, was Folgendes umfasst:

  • Authentifizierungsanfragen, die sich über mehrere Roundtrips erstrecken.

  • Eine Diameter-Nachricht, die ein Sicherheitsverfahren nutzt, das einen vorbestehenden, zwischen Quelle und endgültiger Destination der Nachricht geteilten Sitzungsschlüssel verwendet.

  • Vom Server initiierte Nachrichten, die von einem bestimmten Diameter-Client (z. B. Zugangsgerät) empfangen werden MÜSSEN, wie die Abort-Session-Request-Nachricht, mit der die Beendigung der Sitzung eines bestimmten Benutzers verlangt wird.

Beachten Sie, dass ein Agent eine Anfrage nur an einen in Destination-Host beschriebenen Host weiterleiten kann, wenn dieser Host in seiner Peertabelle enthalten ist (siehe Abschnitt 2.6). Andernfalls wird die Anfrage nur auf Basis von Destination-Realm geroutet (siehe Abschnitt 6.1.6).

Wird eine Nachricht empfangen, wird sie in folgender Reihenfolge verarbeitet:

  • Ist die Nachricht für den lokalen Host bestimmt, gelten die in Abschnitt 6.1.4 aufgeführten Verfahren.

  • Ist die Nachricht für einen Diameter-Peer bestimmt, mit dem der lokale Host direkt kommunizieren kann, gelten die in Abschnitt 6.1.5 aufgeführten Verfahren. Dies wird als „Request Forwarding“ bezeichnet.

  • Es gilt das in Abschnitt 6.1.6 aufgeführte Verfahren, bekannt als „Request Routing“.

  • Schlägt nichts davon fehl, wird eine Antwort mit Result-Code DIAMETER_UNABLE_TO_DELIVER und gesetztem Bit 'E' zurückgegeben.

Damit das Routing von Diameter-Nachrichten innerhalb einer Verwaltungsdomäne funktioniert, MÜSSEN alle Diameter-Knoten im Realm Peers sein.

Der Überblick in diesem Abschnitt (6.1) soll Diameter-Entwicklern allgemeine Leitlinien geben. Implementierungen dürfen andere Methoden als die hier beschriebenen verwenden, sofern sie die Anforderungen der Abschnitte 6.1.1 bis 6.1.9 erfüllen. Weitere Einzelheiten zur Fehlerbehandlung siehe Abschnitt 7.

Letztes Update am