Subject: [Sigtran] [M3UA] Handling DUNA about Self Point Code

From: Santhana <[email-masked]>
Date: Fri, 02 Sep 2011 08:14:14 +0530

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Sep 2011 01:54:28 -0600

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)
>    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-masked]
http://www.openss7.org/

---

From: Santhana <[email-masked]>
Date: Fri, 02 Sep 2011 13:53:43 +0530

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-masked]] 
Sent: Friday, September 02, 2011 1:24 PM
To: Santhana
Cc: [email-masked]
Subject: Re: [Sigtran] [M3UA] Handling DUNA about Self Point Code

Santhana,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Sep 2011 09:38:41 -0600

Santhana,

Santhana wrote:                                                   (Fri, 02 Sep 2011 13:53:43)
> behavior in ASP could be just discarding it right ?

Well, no.  DUNA received at the ASP (other than DUNA(*)), corresponds to
MTP-PAUSE.  The ASP should issue MTP-PAUSE corresponding to the DUNA to
the MTP-User of the AS at the ASP.  The MTP-User of the AS at the ASP should
process the MTP-PAUSE just as it always does.  Receiving an MTP-PAUSE for
any point code is valid for the MTP-User.

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

There are several reasons why a detintaion (point code) is unavailable:
there is currently no route to the destination, or the destinaion is
prohibited from a GWS perspective.  A point code on the SG typically
always available from a routing perspective (because it is local), with
the possible exception of isolation of the NIF (handled by unsolicited
ASPDN Ack), but the local destination could be unavailable from an
authorization perspective (the MTP-User is not permitted to route MTP
messages to itself).  That is what I meant by an MTP-User sending an
MTP message from itself (e.g. 1-1-1) to itself (1-1-1).  This might
be quite possible at the SG from a routing (discrimination) perspective
but might be prohibited from an authorization perspective.  In this case
the SG would send DUNA(1-1-1) and would, therefore, be sending a DUNA
for one of its own point codes.

--brian

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

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