Subject: Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP

From: [email-masked]
Date: Tue, 29 Oct 2002 13:05:05 +0530

Brian and all,

1. when SCON is sent from SGP to an ASP, it really is a translation from
    MTP-STATUS ( cause - signalling network congestion) but as 3332
    advocates that this may as well be used in reverse direction ( sec. 3.4.4).
    The latter is possible in 2 scanrios :
     a) M3UA layer itself is congested, in which case this MAY well be
          translated to TFC and sent to ss7 n/w to reduce traffic towards
          the affected DPC ( Affected PC  in SCON )
     b) ASP is congested, in which case this should not map to TFC, as
          this might result in reduction of traffic towards other ASPs also
which are
          also resident on the same DPC. This case for user part congestion
control,
          as Tolga also says, is not described in Q.704.

    IMO, case (a) makes SCON fit for SSNM while case (b) makes it fit for ASPTM,
    and hence the confusion.

2. Do we really see a situation, where an ASP registers with Routing key type
DPC only
     and serves more than one user parts. I don't think so. I think  each user
part should
     separately register with DPC+SIO as routing key, and thus leaves no
requirements
     for DUPU from ASP to SGP. Pls correct me if I,ve missed a point.

-neeraj

"Brian F. G. Bidulock" <[email-masked]> on 10/29/2002 02:03:19 AM

Please respond to [email-masked]

To:   "Javier Pastor-Balbas (ECE)" <[email-masked]>
cc:   "'Tolga Asveren'" <[email-masked]>, "[email-masked]'"
      <[email-masked]> (bcc: Neeraj Jain/HSS)

Subject:  Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP

Javier,

SCON was conceived as a direct translation from MTP-STATUS (not TFC).
The MTP-User never sends MTP-STATUS-REQ, and as such, there should
never be a requirement for the ASP to send either SCON or DUPU.  These
are MTP-STATUS-IND which are only sent from SG to ASP (MTP to MTP-User).

DPC RKs are not really SGP/ASP operation: IMO they are IPSP operation,

--brian

Javier Pastor-Balbas (ECE) wrote:                 (Mon, 28 Oct 2002 16:35:13)
> Hi Sandeep,
>
> I agree with Tolga, SCON was conceived as a direct translation from TFC in
> order to push information from SS7 to IP domains. The direction is indicated
> in section 3.4.4 of RFC3332.
>
> Cheers // Javier.
>

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 29 Oct 2002 01:42:00 -0700

neeraj,

[email-masked] wrote:                                                           (Tue, 29 Oct 2002 13:05:05)
>           the affected DPC ( Affected PC  in SCON )

Or may be completely ignored by the SG.

>           as Tolga also says, is not described in Q.704.

This use does not exist.

>     IMO, case (a) makes SCON fit for SSNM while case (b) makes it fit for ASPTM,

SCON from ASP was intended only to mimic "nodal" TFC which, AFAIK, is only
provided for in ANSI.  In ASP/SGP case, the SG is always in a better position
to determine "nodal" congestion than is the ASP.  Thus it can basically be
ignored by the SG.  In the ISPS scenario, where there is no SG and SCON from
IPSP to IPSP may be necessary.  But then RFC3332 is vague and incomplete as
regards IPSP operation.

>      for DUPU from ASP to SGP. Pls correct me if I,ve missed a point.

That was the concensus last time we had this discussion: a concensus reflected
in the RFC.

--brian