Re: [M3UA] Handling DUNA about Self Point Code

Hi Brian
	I meant SG-ASP mode only and also SG sending DUNA about itself to an
AS. Now it is clear from your reply that we must do this with unsolicited
INACTIVE-ACK or DOWN-ACK from SG to ASP. 

	So if such DUNA(about self PC) comes from SG, then the handling
behavior in ASP could be just discarding it right ?

	I could not understand the below scenario described by you. Can u
explain ?

" The only case where I can see that an SG would send DUNA for a point
code belonging to an AS to an ASP serving that AS would be where it
is prohibited for an ASP to send a message from a point code
belonging to the AS to another (or the same) point code belonging to
the AS.  So, for example, if the AS attempted to send data from
point code 1-1-1 to point code 1-1-1, the SG could reply with
DUNA(1-1-1).  Is that what you were meaning?"

Thanks & regards
Santhana


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, September 02, 2011 1:24 PM
To: Santhana
Cc: [email protected]
Subject: Re: [Sigtran] [M3UA] Handling DUNA about Self Point Code

Santhana,

Why would one ever do something like that?

In IPSP configuration, SNMM are not used (M3UA is point-to-point in
IPSP mode).  So, I can only conceive that you mean SG-ASP mode.

In SG-ASP mode, an ASP signals its unavailability to service an AS
using ASPIA.  An ASP sending DUNA for the point code associated with
an AS is not only wrong (other ASPs can still serve the AS), it is
not specified (DUNA is only sent from SG to ASP).  So, I don't
suppose that you mean an ASP sending DUNA, but an SG.

An SG sends DUNA for a specific point code when that point code is
unavailable to the SG.  That is, when the routeset from the SG to
the remote point code is transfer-prohibited.  Transfer of MTP
messages to a local point code is always available unless the MTP
layer at the SG is unavailable.

There are two proscribed procedures at the SG for handling
partitioning: when the SG is separated from the SS7 network and
unable to transfer any MTP messages to remote point codes (e.g.
isolation at the NIF) it can send DUNA(*) to indicate the
isolation.  This means that the SG cannot send MTP messages to *any*
*remote* point code.  You see that DUNA means that MTP messages
cannot be transferred *to* the destination point code.  The second
procedure is when the SG is unable to support an AS (local point
code).  In this case the SG can send unsolicited ASPIA Ack for the
affected AS to the affected ASPs.  When the ASP attempts to
reactivate the AS using ASPAC, it returns ERROR(management blocking)
until the fault clears.  When the SG is unable to serve *any* AS, it
an send unsolicited ASPDN Ack, and return ERROR(management blocking)
when the ASP attempts ASPUP until the fault clears.

The only case where I can see that an SG would send DUNA for a point
code belonging to an AS to an ASP serving that AS would be where it
is prohibited for an ASP to send a message from a point code
belonging to the AS to another (or the same) point code belonging to
the AS.  So, for example, if the AS attempted to send data from
point code 1-1-1 to point code 1-1-1, the SG could reply with
DUNA(1-1-1).  Is that what you were meaning?

--brian

Santhana wrote:                              (Fri, 02 Sep 2011 08:14:14)
>    Hi Brian
> 
>              In M3UA can an entity send DUNA(about itself), to convey its
>    unavailability, for some other Management reasons.
> 
> 
>              If such DUNA(about self Point Code) is received from adjacent
>    Point Code, then how to process it ? Can it be processed like normal
>    DUNA, and a DAUD procedure be started?
> 
> 
>              Or for management reasons the control should be only at the
>    level of Blocking the ASP?
> 
> 
>              Pls share your opinion.
> 
> 
>    Regards
> 
>    Santhana


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