Subject: [Sigtran] ASP to SGP communication

From: "Srikanth Yandapalli" <[email-masked]>
Date: Tue, 8 Oct 2002 12:03:52 +0530

I am late entrant to this group.I am quite sure all this should have 
been discussed and I am sorry about this. 

In the context of a single ASP in communication with multiple SGPs,
how should the routing of a MTP_DATA_REQ take place at the ASP?

approach 1:
We may find out the  RK and find out the SGP list that the RK is
active on and choose one SGP for sending the message based
on congestion level and also whether we have received any DRST
message from any of the SGPs. 

approach 2:
An SGP can also be viewed as providing route to a set of DPCs 
and the routing can be based on the DPC for the message alone. 
This approach is reduces the complexity but adds a situation
where the RK may not be active on that association. And also is 
is mandatory to send RC on this association and if so what could
the SGP make out of the RC?

Is there a preferred approach to this issue?

Regards,
Sriky

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 01:47:25 -0600

Srikanth,

Srikanth Yandapalli wrote:               (Tue, 08 Oct 2002 12:03:52)
>    been discussed and I am sorry about this.

Welcome.

>    how should the routing of a MTP_DATA_REQ take place at the ASP?

I assume you are talking about M3UA?  As we are dealing with 5 or more UAs
now, in the future it would be helpful to add M3UA (or whichever) to the
subject line.

>    message from any of the SGPs.

This approach is applicable to multiple SGs, but not to multiple SGPs within a
single SG.

>    the SGP make out of the RC?

RC should be coordinated and the same across multiple SGPs within an SG.

>    Is there a preferred approach to this issue?

Typically, the logic can be something like this: (but there are several other
schools of thought):

Single SG case: (multiple SGs is more complicated)

  MTP-TRANSFER request is issued by an MTP-User.  The MTP-User is bound to an
  MTP-SAP.  The MTP-SAP is associated with an AS/RC/RK.  There is a pool of
  SGPs on an SG for which the AS/RC/RK is active.  The AS may have received
  MTP-PAUSE/RESUME/STATUS indications from the SG and may choose to honor that
  information or not.  If the ASP chooses not to honor this information it can
  blindly send messages to the SGP and rely upon a DUNA/SCON response from the
  SGP later.

  Selection of an SGP within an SG is based on the traffic mode for the SGP.
  This traffic mode is not managed by M3UA, however, M3UA provides for
  distribution of traffic over SGP based on any of the methods described for
  ASPs (active/standby, load-share, broadcast).  A typical method is
  load-share based on SLS.  In this scheme, using the SLS in the MTP-TRANSFER
  request, the ASP selects load-shares traffic over the available SGP.

Multiple SG case:

  In the more complicated multiple SG case, the ASP must first select an SG
  before it selects an SGP within the SG.  The ASP must maintain some
  additional routing information to be able to properly select an SG.  This
  routing information is updated by collecting DUNA/DAVA/DRST messages
  received from (any of the SGP in) the SG.  To select the outgoing SG, the
  ASP must examine the destination of the MTP-TRANSFER request.

  (If the SG has no SGP active for the AS/RC/RK, all destinations can be
  considered prohibited).

  If the destination is available and unrestricted for several SGs, the ASP
  should select an SG on a load-sharing basis (based on SLS) and then select
  an active SGP within the SG on the basis of the traffic mode for the SG.

  If some SG are restricted for the specified destination (based on received
  DRST messages from the SG), the ASP should load-share across the available
  unrestricted SGs.  If all SGs are restricted for a given destination, the
  ASP should load-share across the available SGs and ignore the restricted
  status.
  
  If some SG are prohibited for the specified destination (based on received
  DUNA messages from the SG), the ASP should load-share across the available
  non-prohibited SGs.  If all SGs are prohibited for a given destination (or
  no SGP is active for the AS/RC/RK in any SG), the ASP should respond to the
  MTP-User with an MTP-PAUSE in accordance with the style of the MTP-User
  interface (ITU-T and ANSI differ here).

Properly selecting SGs requires that the ASP maintain the DUNA/DAVA/DRST
information for each destination received from any SGP in an SG, on a per-SG
basis.  This is the same as MTP Level 3 ROUTE status.  However, SCON
information should only be maintained on a per-destination basis (and not
per-SG).  This is the same as MTP Level 3 ROUTESET status.

Note that, in general, it is a bad idea to consider congestion (SCON) when
selecting an SG.  SCON does not necessarily indicate congestion at an SG or on
a path to an SG, but indicates congestion at the affected destination or
somewhere (perhaps distant) in the SS7 network.  SCON is ROUTESET-specific
(applies to the destination), whereas DUNA/DAVA/DRST is ROUTE-specific
(applies to the destination and path).  SCON should only be used to determine
whether a message should be dropped completely and an MTP-STATUS returned to
the MTP-User according to the style of the MTP-User interface (ITU-T and ANSI
differ here again).

So, to summarize:  on behalf of the AS/RC/RK/MTP-User, the ASP determines
whether to send a message based on SCON received for the specified
destination, then selects an SG based on DUNA/DAVA/DRST received for the
specified destination and load-shares based on SLS across the eligible SGs.
Once an SG is selected, an active SGP (active for the AS/RC/RK) is selected
within the SG based on the traffic mode of the SG (active/standby, load-share,
broadcast: but typically load-share on SLS).

As I said, there are other schools of thought, but that is my understanding.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran