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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 13:15:50 -0500

Javier,

On Thu, 06 Sep 2001, Javier Pastor-Balbas (ECE) wrote:
> > 
> > > 
> > > 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. 

No. That is not my point.

> 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

That can be accomplished with a single exchange for both directions.

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

It is possible to have a misconfigured network.  User parts are not defined
to support unidirectional only flows, nor are they necessary.

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

That is implementation specific.  ASP-INACTIVE for an AS means that no
traffic may flow, not that unidirectional traffic may flow.  DUNA means
that a remote signalling point is inaccessible, not that one simply
can't send traffic to it.  One can also expect not to receive traffic
from it either.

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

One direction will still suffice.

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