Subject: Re: [SUA issue 17 & M3UA issue #11] IPSP cases.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 05:32:34 -0500

Javier,

Please see comments below...

On Thu, 06 Sep 2001, Javier Pastor-Balbas (ECE) wrote:

> 
> Hi Brian, John, 
> 
> After reading some of your mails, I would like to express my understandings
> just in case it helps.
> 
> We set the status of a remote IPSP or ASP as INACTIVE when it is capable of
> handling ASPSM/ASPTM messages but the application cannot handle signalling
> traffic.
> 
> If we receive an ASPUP-ACK as a response to an ASPUP, it is obvious that the
> remote IPSP is able to handle ASPTM messages, so we can mark it as INACTIVE.
> This means that we only need one ASPUP / ASPUP-ACK to set both IPSPS in the
> INACTIVE state.
> 
> Obviously, if both ends send an ASPUP, it would also work, and I propose
> that in such a case, we always send the corresponding ASPUP-ACK.

Your proposal for ASPUP-ACK sounds reasonable to me.

> 
> On the other hand, the ACTIVE state means that the application on top of
> M3UA can handle the signalling traffic corresponding to the routing contexts
> it handles.
> 
> If you send an ASPAC message, you are saying that you are ready to receive
> traffic for your handled RK/RC. But you can never force the other side to
> have its application ready to receive the traffic you want to send, since
> its corresponding process must be up and running, and you have no authority
> to force that from your own node.
> 
> So, in order to be able to send messages to the other side, you must receive
> an ASPAC letting you know that it is ready. This means that the symmetrical
> way must be used for establishing the signalling traffic.

That doesn't sound reasonable.  In the ASP/SGP case, traffic is established
in both directions with a single ASPAC/ASPAC Ack.  There is no reason why
this could not also be accomplished with IPSPs.  The side which doesn't want
to start traffic can reply with ERR("Refused - Management Blocking") just
as an SGP would.

> 
> Very important:
> 
> - There are cases where bi-directional communication is not needed, for
> instance if you have an application that just registers charging data and
> doesn't need to reply to your messages. So this kind of communication must
> be allowed.

Unidirectional traffic is not supported in SS7, why should it be allowed in
M3UA or SUA?

> - Even for bi-directional applications, there is no problem with receiving a
> message from a prohibited destination, you just deliver the message to your
> user, and when it wants to reply, it will not be able to send the reply.

ASP-INACTIVE and DUNA are two different things.

> Applications are ready for a lost of communication, and usually react by
> re-attempting to send the message after a while (in fact, they do it
> periodically).

Well written applications wait until they are told that the communication
is reestablished rather than flogging a dead horse.

You have not provided any supporting argument for ASPAC requiring activation
in both directions.  One direction will do.

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]