Re: [M3UA] Handling DUNA about Self Point Code

Santhana,

Santhana wrote:                                                   (Fri, 02 Sep 2011 13:53:43)
> 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 ?

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

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


> " 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/
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran

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