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

From: Tolga Asveren <[email-masked]>
Date: Thu, 31 Oct 2002 12:24:23 -0500

Nitin,

> -----Original Message-----
> From: Nitin Vairagare [mailto:[email-masked]]
> Sent: Thursday, October 31, 2002 11:55 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> 
> 
> 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.
[TOLGA] What do you mean by "Implementation can be independent"?
In fact the second model you mentioned (SG and AS have difderent PCs) is in
my view just forcing the regular ASP/SGP M3UA concept. It is odd for me to
cross PC boundaries between SGP/ASP for a layer3 adaptation layer. That was
also one of the reasons, why M3UA SG-SG (which behaves as a peer-to-peer
protocol) makes sense to me. I would model the configuration you mentioned
as two SGs(one of them having the same PC with the AS), and if I need to
split the user parts on different ASPs, then I would do it with ASP/SGP
model, without crossing PC boundaries. This would also get rid of the
strange case, where SG acting as STP should generate RCT for PC of AS, in
case of ANSI networks.
 
With the current model, one can also have a strange case as below:

                    AS1: PC=1-1-1 SI=3
 +------+         +------+
 |SG1   +---------+      |
 |      |  +------+ ASP1 |
 +------+--+--+   +------+
           |  |
           |  |
           |  |
           |  |
           |  |     AS2: PC=1-1-1 SI =5
 +------+  |  |   +------+
 | SG2  +--+  +---+      |
 |      +---------+ASP2  |
 +------+         +------+

Now when association between SG1 and ASP1 is broken, SG1 will reply with UP
to incoming MTP3 traffic destined to PC=1-1-1/SI=3, but SG2 will route it.
So, one also should be carefull when using multiple SGs, or IMO better one
shouldn't cross PC boundary between SG and ASP.
 
But even with the current model, if you think that carefull configuration
will solve the problem for SEP case, the same care will allow the same
result, where SG acts as STP and has the combined SPMC view.
> 
> 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.
[TOLGA] IPSP has some of the SG logic inside, at least SPMC management I
would say. There DUPU is not necessary. 
> 
> 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,
> 
> > -----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
> _______________________________________________
> 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 14:26:47 -0500

Tolga,

I see your point in two SG case. And yes one has to be very careful
and aware of potential side-effects and issues of their network
architecture design. May be we should come up with guidelines draft
or RFC when using Sigtran. Network designers should be aware of
real issues of mis-configuiring.

For question, When I said "Implementation idependent" that was typo..
I mean it should be left upto implementations to decide how to 
differentiate using configuring parameter if they like to behave 
like SGP-ASP model or SG-SG model crossing PC boundary as you mentioned.
And depending on configuration hey should take decision if they want to 
send DUPU or not. 

Can you elaborate your views on IPSP case for DUPU?

Thanks,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Thursday, October 31, 2002 12:24 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP

Nitin,

                    AS1: PC=1-1-1 SI=3
 +------+         +------+
 |SG1   +---------+      |
 |      |  +------+ ASP1 |
 +------+--+--+   +------+
           |  |
           |  |
           |  |
           |  |
           |  |     AS2: PC=1-1-1 SI =5
 +------+  |  |   +------+
 | SG2  +--+  +---+      |
 |      +---------+ASP2  |
 +------+         +------+