www.Tutorialsforu.info

6.8. Diameter Server Discovery

   The basic architecture assumption of this document is that all the
   data related to a user is stored in a unique Diameter server.
   Contrary to general opinion, this does not create a single point of
   failure.  It is assumed that Diameter servers are configured in a
   redundant fashion in an attempt to mitigate the
   single-point-of-failure problem.

   In large networks, where the number of users may be significantly
   high, there might be a need to scale the number of Diameter servers.
   All the data associated with a user is still stored in one Diameter

   server (typically, operating in a redundant configuration), but the
   data associated with different users may reside in different Diameter
   servers.

   Although this configuration scales well, it introduces a new problem,
   namely: given the user's SIP AOR as an input, how to determine which
   of various Diameter servers is storing the data for that particular
   SIP AOR.  We solve this problem with inspiration from the Diameter
   redirection mechanism specified in RFC 3588 [RFC3588].  We include in
   the architecture a new Diameter node that, for the purpose of this
   document, is known as Diameter Subscriber Locator (SL).  The Diameter
   SL contains a database or routing tables that map SIP AORs to
   Diameter server URIs.  A particular Diameter server URI points to the
   actual Diameter server that stores all the data related to a
   particular SIP AOR, and in consequence, to the user who owns the SIP
   AOR.  The Diameter SL acts in a similar way to a Diameter Redirect
   Agent, dispatching Diameter requests (e.g., providing the redirection
   URI in the answer).  The Diameter SL can redirect all the request
   pertaining to a user by setting the Redirect-Host-Usage AVP with a
   value ALL_USER, as specified in RFC 3588 [RFC3588].

   The Diameter SL can be replicated in different nodes along the
   network, for the purpose of building scalability and redundancy.  The
   database or routing tables have to be consistent across all these
   different Diameter SLs, so that equal Diameter requests will produce
   equal Diameter answers, no matter which Diameter SL processes the
   request.

           +--------+   +--------+  +--------+  +--------+
           |  SIP   |   |Diameter|  |Diameter|  |  SIP   |
           |server 1|   |SL red. |  |server 1|  |server 2|
           +--------+   +--------+  +--------+  +--------+
                |           |           |            |
   1. SIP INVITE|           |           |            |
   ------------>| 2. LIR    |           |            |
                |---------->|           |            |
                | 3. LIA    |           |            |
                |<----------|           |            |
                |       4. LIR          |            |
                |---------------------->|            |
                |       5. LIA          |            |
                |<----------------------|            |
                |         6. SIP INVITE |            |
                |----------------------------------->| 7. SIP INVITE
                |           |           |            | ------------->
                |           |           |            |

      Figure 7: Locating a Diameter server.  SL redirecting requests

   Figure 7 shows an example of operation of a Diameter SL acting in
   redirect mode.  SIP server 1 receives an INVITE request (step 1)
   addressed (in the SIP Request-URI) to a user for which the Diameter
   client in SIP server 1 does not possess routing information.  In
   other words, the Diameter client in SIP server 1 does not know the
   URI of the Diameter server 1.  The Diameter client sends a Diameter
   LIR message (step 2) to any of the Diameter SLs configured in the
   network.  The address of those SLs is assumed to be pre-provisioned
   in the Diameter client.  The Diameter SL, based on the contents of
   the SIP-AOR AVP and its own routing tables, determines the Diameter
   server that stores the information allocated to such user.  Then it
   builds a Diameter LIA message (step 3) that includes a Result-Code
   AVP set to DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP,
   whose value is set to the URI of the Diameter server that stores the
   information related to such user.  Then the Diameter client in SIP
   server 1 builds a new LIR message (step 4) addressed to the Diameter
   server received in the Redirect-Host AVP.  The rest of the procedure
   is completed as described in previous sections.