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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 15:26:55 +0200

Hi Brian, 

See comments inline.

BR // javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 12:33 PM
> To: sigtran
> Subject: Re: [SUA issue 17 & M3UA issue #11] IPSP cases.
> Importance: High
> 
> 
> 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.
> 

The point is that SG is always up since it has no application over M3UA. And we know it is up and running whenever it replies a message from the ASP. 

In ASP, not only the M3UA layer has to be up and running, but also the application that is over it. As we have two applications (one per IPSP) it's needed to know that both of them are up and running

> > 
> > 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?

As you said MTP signaling links are bidirectional, however, in order to access a remote destination you have to define a MTP route. The MTP routes are unidirectional. You can define diferent routes in one way than in the other. So it is possible to have unidirectional traffic in SS7.

> 
> > - 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.
> 

ASP-INACTIVE only refers to the capability of message reception of the remote IPSP/ASP, not to its msg sending capability. If there is no other ASP active for that AS, the remote node will be effectively unavailable for the local M3UA user. The user will see no difference.

> > 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.

You can read our first answer to find the argument.

> 
> --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]
> 

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