Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 May 2002 12:32:17 -0500

Francois,

I'm sorry but there is really no way to do this with SUA as it stands.
I proposed a registration/deregistration of TIDs some time back, but
it was replaced with the inferior lable approach (which doesn't keep
state for things like transactions or connections).  For transactions,
use TUA to get past this defficiency.  CO is out of luck unless the
WG would like to consider including registration/deregistration of
connections again.

I had actually hoped that this issues would have been properly resolved
before the SUA was moved forward, however, there are those who have had
a hard time understanding the problem.  Thus the inferior solution.

--brian

Zannin, Francois wrote:                                   (Wed, 29 May 2002 09:31:25)
> 
> Brian and others,
> 
> What about the TCAP close dialog? A solution should be to use the ACTIVE
> message with a void TID range for the concerned RC. In that case, no new
> transaction will be initiated through the "exiting" ASP until it decide to
> send the INACTIVE once all it's dialog are close.
> 
> This behavior of the INACTIVE message on the SG must be specified if we want
> to have SG/AS that can inter operate for different vendor!
> 
> This consideration should be included in the draft or an implementation
> guide.
> 
> Francois Z.
> 
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, May 17, 2002 9:16 PM
> > To: Zannin, Francois
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and
> > TCAP traffic stop
> > 
> > 
> > Francois,
> > 
> > IMO the existing text is sufficient.
> > 
> > --brian
> > 
> > Zannin, Francois wrote:                                   
> > (Fri, 17 May 2002 10:56:50)
> > > Brian,
> > > 
> > > You are right about note 1 associated to the DRST. A 
> > reading shows that 
> > > N-COORD indication and confirm means a message from the ASP 
> > to the SG(p), 
> > > can we modify the text that describe the DRST (text coming 
> > from M3UA) 
> > > that may give some doubts about the possibility to send 
> > this message from 
> > > an ASP to a SGP.
> > > 
> > > " 3.4.6 Destination Restricted (DRST) 
> > >  
> > >    The DRST message is optionally sent from the SG to all concerned 
> > >    ASPs  ... "
> > > >>> There is no information saying that the DRST can be 
> > send from the ASP to the SGP.  
> > > 
> > > "   This message is optional for the SG to send and it is 
> > optional for 
> > >    the ASP to act on any information received in the message."
> > > >>> This information may be completed to specify that it is 
> > not optional when the DRST is used to carry the SOR/SOG messages.
> > > 
> > > 
> > > My concern was also about the possibility stop new 
> > transaction for a specific ASP. 
> > > I understand that the right solution should be to use TUA 
> > instead of SUA for TCAP 
> > > but while the TID range is included in the SUA protocol, it 
> > may be a good idea to 
> > > have all the messages needed to handle TCAP transactions.
> > > 
> > > Because the DRST can be used to carry SOR/SOG from the ASP 
> > to the SGP, what else 
> > > can be used to carry this "TCAP" needed message from the 
> > ASP to the SGP?
> > > 
> > > Francois.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, May 15, 2002 8:35 PM
> > > > To: Zannin, Francois
> > > > Cc: [email-masked]
> > > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP 
> > for SOR/SOG and
> > > > TCAP traffic stop
> > > > 
> > > > 
> > > > Francois,
> > > > 
> > > > If you read Note 1 under the DRST message you will see that
> > > > the message is for both the SG to AS direction and the AS
> > > > to SG direction for N-COORD.  This is all four: requestion
> > > > indication, response and confirmation.  There is nothing
> > > > missing.
> > > > 
> > > > --brian
> > > > 
> > > > Zannin, Francois wrote:                                   
> > > > (Wed, 15 May 2002 11:07:55)
> > > > > Hi,
> > > > > 
> > > > > In the SUA draft, top-level application or management 
> > > > > application can be synchronized through N_COORD primitives 
> > > > > in a SSNM DRST message.
> > > > > 
> > > > > This message exists only from the SG (p) to the AS (p). 
> > > > > When the application (or the AS management) receive an 
> > > > > N-COORD request and need to respond by a N_COORD response, 
> > > > > which message from the ASP to the SGP must be used to carry 
> > > > > this information?
> > > > > 
> > > > > If an indication has to be added to transport this information, 
> > > > > isn't it an opportunity to also add the missing message that 
> > > > > can be used to inform a SG (p) that an ASP do not need to 
> > > > > receive any "new" transaction for TCAP applications?
> > > > > 
> > > > > Francois.
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > > 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Zannin, Francois" <[email-masked]>
Date: Wed, 29 May 2002 09:31:25 +0200

Brian and others,

What about the TCAP close dialog? A solution should be to use the ACTIVE message with a void TID range for the concerned RC. In that case, no new transaction will be initiated through the "exiting" ASP until it decide to send the INACTIVE once all it's dialog are close.

This behavior of the INACTIVE message on the SG must be specified if we want to have SG/AS that can inter operate for different vendor!

This consideration should be included in the draft or an implementation guide.

Francois Z.