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

From: Tolga Asveren <[email-masked]>
Date: Tue, 29 Oct 2002 08:36:00 -0500

Neeraj,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 29, 2002 2:35 AM
> To: [email-masked]
> Cc: 'Tolga Asveren'; [email-masked]'
> Subject: Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> 
> 
> 
> 
> 
> 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.
[TOLGA] IMO, SCON from ASP to SGP is a violation of the model. Anything
related with the traffic tange ASP serves is better ot be announced with
ASPTM. If there is a need to declare congestion then it would be better to
invent an ASPTM for it.
For the case b), I think different. Multiple ASPs can serve the same AS, so
that M3UA layer is congested at one of the ASPs shouldn't cause TFC. It is
SG which has the combined view of SPMC. So, IMO the correct approach would
be, ASPs declare congestion with a message to SG and SG decides for the
combined nodal congestion for a SPMC, like it decides for the
availability/unavailability of SPMC. For that to work fine, a response
mechanism, where congestion indication from ASP to SG is triggered after a
message is received, won't work. IMO, if needed, congestion indication from
ASP to SGP should be sent, whenever it occurs. SG, which has the whole
information for the SPMC can decide to reply with TFC or not, based on that
combined SPMC view.
> 
> 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.
[TOLGA] This is a configuration decision. The protocol is clear how it
operates. If one still wants to use it with DPC type RKs and multiple user
parts, so be it.
> 
> -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: "Nitin Vairagare" <[email-masked]>
Date: Thu, 31 Oct 2002 11:54:41 -0500

Hi All,

In a typical M3UA sigtran model, SG has layers up to MTP3
and the userparts are located remotely on some IP node (ASP).

UPU's are exchanged between MTP3 only and when they arrive at
MTP3, they are suppose to be converted into MTP-STATUS and send
to User parts. 

So in the model explained above, UPU received at 
SG shall be converted into DUPU and sent to ASP so that M3UA
at ASP converts it to MTP-Status and deliver it to user Part.

In other case when the user part at ASP goes down It is duty
of Its MTP3/M3UA (which is on SG) to detect that the RK is not
active any more and send UPU to remote MTP3 in SS7 network, if
it finds the RK is not active any more.

M3UA is acting here as codec between MTP3 at SG and Userpart 
at ASP.

Let us consider case of RK as DPC: It is very important to
undersatnd if this DPC is public (different from SG PC) or 
Same as SG or private behind SG.
In later two cases, model explained above is applicable
and the DUPU shall be sent from SG to ASP only. only difficulty
would be how to determine which user part is unavailable? I would
say configuration is messed up. You do not want to use DPC as RK 
when there are more than one user part. The service on ASP cannot
be identified uniquely anymore (breaking the RK definition). So
one has to be careful while configuring such network elements.

The former case of public DPC on ASP different from SG (SG is STP)
and ASP is SEP/SCP. Which is kind of slightly wiered from
SS7 world point of view (No MTP3 for SCP/SEP). In this case 
M3UA on ASP itself behaves like MTP3 for ASP and should be allowed to 
send DUPU. It will work like UPU from one MTP3 to other. Implementation
can be independent.

How about IPSP? There are no MTP3's? My assumption is
all IPSP's should be allowed to send DUPU in case they loose
user part. In this case DUPU is not m3ua codec but real UPU itself.

Hope that calrifies some of the DUPU issues.

Regards,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Tuesday, October 29, 2002 8:36 AM
To: [email-masked]'
Subject: RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP

Neeraj,