RE: Recommendation for SUA modifications

Brian,

I'm trying to solve a very specific problem.  Of course you can come up
with many scenarios where what I'm talking about won't work.  And these
are not relevant to the problem I'm trying to solve. 

If the ASPs are multiple DPCs, then when the HOW are you going to send
an SCON since you can only fit "ONE" affected PC in the SCON field?  I
don't even want to go there.  Let's save that one for a different
thread.

Lincoln

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Brian F. G. Bidulock
Sent: Thursday, October 13, 2005 5:27 AM
To: Tolga Asveren; [email protected]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Tolga,

You should also note that despite your stance that M3UA only supports a
single DPC in an RK, SUA supports multiple DPCs.  Therefore an RC does
not necessarily identify which of many possible point codes an AS can
register to receive messages for.  Even a symmetrical arrangement would
not help for SUA.

--brian

Brian F. G. Bidulock wrote:                 (Thu, 13 Oct 2005 03:13:51)
> Tolga,
> 
> Tolga Asveren wrote:                          (Wed, 12 Oct 2005
14:34:27)
> > > > "The ASP SHOULD NOT send Data or SSNM messages for the related 
> > > > Routing Context(s) before receiving an ASP Active Ack message, 
> > > > or it will risk message loss."
> > > > I know it is not a "MUST NOT" but still it is nota good thing to

> > > > do unless one is aware of consequences and happy with them.
> > >
> > > That would be sending messages with RC 1 in them before receiving 
> > > ASP Active Ack for RC 1.  That passage does not speak to the 
> > > addressing of the messages.  Other passages do.  The SG provides 
> > > uniform connectivity to all ASPs in an AS and can route any 
> > > messagew within a Network Appearance.
> > [TOLGA]Here I still think different, i.e. I consider AS state to be 
> > honored in both directions of message flow based on the above
passage-.
> 
> I know what I meant by that sentence when I wrote it.
> 
> One of the possible responses of the SG to an ASP Active request is an

> ASP Inactive Ack, or management blocking.  My point was that if an ASP

> blindly sends messages to the SG following ASP Active, without waiting

> for an ASP Active Ack, that the SG may have to discard them in the 
> case that it responds with an ASP Inactive Ack or management blocking.
> 
> Therefore, if the ASP wishes to avoid risking "message loss", it will 
> wait for the ASP Active Ack.
> 
> If you recall, I was not successful on the argument of symmetrical 
> flows within a routing context.  RK is only used by an SG for routing 
> messages to the ASP, not visa versa.
> 
> If messages in M3UA could not be sent from ASP to SG with different 
> addresses than appear in the RK, then the SG would have to compare the

> routing labels in DATA messages received from the ASP to police the 
> arrangement and do something (no procedure exists yet) in event of a 
> violation.  Currently, the SG can just process the message for M3UA, 
> because the addresses in it are fully specified and the message is 
> self contained.  The SG even knows the proper RC value to place in any

> SSNM messages sent to the ASP in response to respond to the proper AS,

> regardless of the addresses in the message.
> 
> In fact there is no procedure in either M3UA or SUA that relies on the

> ASP applying a symmetric routing key to that of the SG.
> 
> In SUA placing a symmetric requirement on the ASP is not possible, 
> because not even addresses are symmetric (a transaction query often 
> includes GT, whereas the response does not).
> 
> All that the RC does is identify the AS to an SG and corresponds to a 
> routing key used by the SG to send messages to the ASP.  It is a false

> assertion that missing parts of messages sent from ASP to SG can be 
> recreated based on RC.
> 
> --brian
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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