Subject: RE: [Sigtran] ASP Active

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Fri, 23 Dec 2005 13:59:56 +0530

Hi Stanislav, Tolga,
 
Well, then that would mean that Layer Manager (LM) needs to keep track (or
be aware) of SCCP and applications over SCCP to initiate the ASP Active ie.
LayerN needs to be "aware" of the states of Layer N+2.
 
The applications (SCCP-User) should have inherent ways to inform the peer if
it's NOT ready, OR to drop the incoming message.
And the peer -to-peer messaging between SCCP-Users, should take care of
invalid states of one another.
 
shashank 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 23, 2005 1:35 AM
To: SIGTRAN
Subject: RE: [Sigtran] ASP Active

Shashank,
 
Both M3UA and SUA in the same section 4.3.4.3. "ASP Active Procedures" say:
 
"By sending an ASP Active Ack message, the SGP or IPSP is now ready to
receive and send traffic for the related Routing Context(s). 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."
 
Having in mind that ASP/IPSP is a process that runs one or several
applications the reference above says that process ASP/IPSP is not allowed
to SEND traffic on behalf of application A1 externally represented with RC1
if the process has not activated itself in for the A1 by sending RC1 to the
SGP (or IPSP).
 
In other words the application A1 is dead within the process ASP/IPSP thus
cannot send traffic until the process has activated itself for the AS1.
&nb! sp;
Change of this very fundamental principle that AS is both sink and source at
the same time in the xxUA specifications would cause many other changes
(i.e. it is not just one paragraph I pointed to...).
 
/ Stanislav

Tolga Asveren <[email-masked]> wrote: 

Shashank,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Thursday, December 22, 2005 2:34 PM
> To: [email-masked]
> Subject: [Sigtran] ASP Active
>
>
> I had a question related to ASP Active message and the definition of AS:
>
> The section 3.7.1 says:
>
> The ASP Active message is sent by an ASP to indicate to a remote M3UA
>! ; peer that it is ready to process signalling traffic for a particular
> Application Server.
>
>
> And I read from the specs, that an Application Server can be a a virtual
> switch element handling all call processing for a unique range of PSTN
> trunks, identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a
> virtual database element, handling all HLR transactions for a
> particular SS7
> DPC/OPC/SCCP_SSN combination.
>
> In this context, here is the question:
> Let's assume that we have the following stacks at the both the ends.
>
>
> ******** IP ********
> *IPSP-A* *IPSP-B*
> ******** ********
>
> +------+ +------+
> |SCCP- | |SCCP- |
> | User | | User |
> +------+ +------+
> | SCCP | | SCCP |
> +------+ +------+
> | M3UA | | M3UA |
> +------+ +------+
> | SCTP | | SCTP |
> +------+ +------+
> | I! P | | IP |
> +------+ +------+
> |________________|
>
>
>
> When the IPSP-A sends an ASP Active to IPSP-B, does it mean that the SCCP
> ONLY (at Node A) is ready for receiving signaling traffic or even the
> SCCP-User/Application (at Node A) is ready for Signaling traffic.
>
> I believe that ASP Active was sent to receive the SCCP (at Node A) traffic
> from NodeB. However, there can be a scenario wherein, at the same
> time, the
> SCCP-User (at Node A) is NOT ready to send and receive traffic from NodeB.
[TOLGA]For practical purposes, I would say that ASPAC declares readines of
the application, i.e. SCCP-User in your example. OTOH, I would think from
M3UA point of view, it wouldn't matter whichever interpretation you pick but
receiving messages with no application to process them is probably not very
useful.
>
> Let me know if this interpretation is fine.
>
> shashank
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

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

  _____  

Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo!
<http://us.rd.yahoo.com/mail_us/footer/shopping/*http://shopping.yahoo.com/;
_ylc=X3oDMTE2bzVzaHJtBF9TAzk1OTQ5NjM2BHNlYwNtYWlsdGFnBHNsawNob2xpZGF5LTA1>
Shopping 

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

---

From: Ilie Glib <[email-masked]>
Date: Fri, 23 Dec 2005 12:26:28 +0100

Hello Shashank,

M3UA should not have any knowledge of SCCP-Users, perhaps you meant
something different in your statement below. M3UA knows whether SCCP
is up and running, that is made visible by SG via DUPU, but it is not
necessary to be visible on IPSP to IPSP interface (M3UA), since SI is
not mandatory part of the RK, and RC in general is optional. Handling
of SCCP-Users is up to SCCP layer, in your network scenario.

Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Dec 2005 04:38:10 -0700

Ilie,

Nothing "is made visible" by DUPU.  DUPU (as UPU) signals only the
unavailability of a remote user part.  It is the responsibility of
the MTP-User to test for remote user part availability.

--brian

Ilie Glib wrote:                            (Fri, 23 Dec 2005 12:26:28)

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

---

From: Ilie Glib <[email-masked]>
Date: Fri, 23 Dec 2005 12:47:50 +0100

Brian

unavailability of a remote user part, which is something,  "is made
visible" by DUPU.

Regards

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Dec 2005 04:59:57 -0700

Ilie,

DUPU is valid only for the instant that it was sent.  It does not
may anything visible.

--brian

Ilie Glib wrote:                                                      (Fri, 23 Dec 2005 12:47:50)

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