Subject: Re: [Sigtran] M3UA - ASP Inactive

From: [email-masked]
Date: Thu, 14 Nov 2002 11:23:11 +0530

Brian,

"Brian F. G. Bidulock" <[email-masked]> on 11/13/2002 11:58:47 AM

Please respond to [email-masked]

To:   Anshoo Sharma/HSS@HSS
cc:   [email-masked]

Subject:  Re: [Sigtran] M3UA - ASP Inactive

anssharma,

[email-masked] wrote:                        (Wed, 13 Nov 2002 09:32:09)
> > [TOLGA] Who is "we"? I think interoperability is not the correct place to
> > decide for binding decisions.
> [Anshoo]
> But it is the best place to see where all the implementations are headed. And
if
>  all the implementations have a
> good reason for going against a SHOULD in the RFC, then there is a good reason
> to change that should into MAY.

I seriously doubt that "all implementations" were represented.  Also, the RFC
is a Proposed Standard.  Before it can move to a Standard, there must be
significant implementation and interoperability.  The correct place for
changes of that nature would probably be in the "Standard" rather than the
"Proposed Standard".

It would not be wise to change this behavior unless there is a valid technical
argument to begin with and then the ramifications of the change on
interoperability and the function of the protocol are considered.

Neither have been presented.  On the other hand, technical arguments and
interoperability considerations have been made for the RFC as it stands.  This
is why the SHOULD NOT is there in the first place.  MAY is reserved for
optional capabilitities or sligtly varying that some might think has some
market value but has no impact on imteroperability.

I don't think that one can make a case for MAY.  You are welcome to try.

Here is a list of issues that I think that you will have to resolve before
a MAY could be considered:

1)  What information is an SG then required to send to an ASP when it moves
    from an undefined or unregistered state to ASP-INACTIVE for an AS?

    If the SG is expected to send historical information on acessibility,
    restriction and congestion, then it is doing no more than it would
    in answering a DAUD.  When is this "automatic" DAUD considered sent?

[Anshoo]
It should be the same information that you propose sending a newly Active ASP.
Even if the SG does not send any information, it should be the responsibility
of the ASP to AUDIT the Status of the Point Codes that it would be
communicating with.

2)  Because the SG ASP state and the ASP state can be out of synchronization,
    what error procedures are necessary in response to SSNM sent in the
    ASP-INACTIVE state?  That is, when the SG sends SSNM or DATA to an ASP
    that it considers in the ASP-ACTIVE state for some AS, there are error
    procedures (Unexpected Message) for handling SSNM or DATA sent to an ASP
    in the ASP-INACTIVE state.

    Currently the ASP can send ASPAC to an SG sending SSNM or DATA to an
    ASP in the ASP-INACTIVE state at the ASP to attempt to resynchronize
    state between the ASP and the SG.  If the ASP has the AS unregistered
    or in another undefined state, what can it do when it receives SSNM?
    It would likely send an "Invalid Routing Context" which the SG can do
    what with?  It cannot send unsolicited ASP Inactive Ack as it could before
    to resynchronized the ASP Inactive state: is it to delete the ASP from
    the AS altogether?  With no indication to the ASP?

[Anshoo]
There is no need to combine both SSNM and DATA messages. In case of receiving
SSNM messages the ASP can update the State of the Point Code locally and start
Auditing the Point Code in case it has been marked as Restricted / Unavailable.
If the ASP does not have the routing context configured at its end, it may send
the Error Message "Invalid Routing Context" to SG, since this is a configuration
mismatch and some action is required on part of the SM.
On receiving a DATA Message in INACTIVE State, the ASP can send the SG an ASPIA
indicating to the ASP that it does not want to receive any DATA. The ASP going
into ACTIVE State when it does not want to receive DATA does not seem very
correct.

3)  What impact would this change have on the application at the ASP?

    It is generally agreed that the ASP-INACTIVE state for an AS represents
    the absense of the MTP User part for the AS.  (And maybe this is the what
    makes sending SSNM to inactive ASPs the worst idea.)  So when an ASP that
    is ASP-INACTIVE for an AS has no user part.  This means that there is
    no application to send MTP-PAUSE, MTP-STATUS and MTP-RESUME to during this
    state.  All that the ASP could do is maintain this information internally
    at the ASP.  When the MTP User application reenables for the AS and the
    ASP goes ASP-ACTIVE for the AS. the ASP would have to delivere this
    information to the MTP User no differntly than the DAUD procedure provides
    for today.  If the MTP User application already has the information (from
    another ASP or shared memory or some other place where also the shared
    circuit state and/or transaction state is held) collecting it in the ASP
    before this was a waste of time and might reveal contradictory
    information.

[Anshoo]
The User Part not existing on an INACTIVE ASP need not be the case, the User
Part
might actually not be transferring Data but still can reside on an INACTIVE ASP.
Moreover the User Part might be available on some other ASP, which is ACTIVE and
hence
the STATE of the DPCs at the User Part are out of sync with the underlying M3UA
at
the newly Active ASP after a switchover... This is actually a case for
supporting
SSNM in INACTIVE State.

    One should not forget that in the backhaul case, M3UA messages correspond
    to MTP User primitives (MTP-PAUSE, MTP-RESUME, MTP-STATUS and
    MTP-TRANSFER, and allusions to MTP-RESTART-ENDS).  While the ASP is
    ASP-INACTIVE for an AS, no primitives should cross the boundary.  The MTP
    User might not even be bound to the MTP-SAP, and, even if it is, it
    certainly cannot be expected to be processing MTP primitives when it has
    not acitvated for the MTP-SAP.

[Anshoo]
If the User Part has not bound to MTP-SAP on M3UA at ASP, it would not receive
any of the MTP3 PAUSE, RESUME etc.. Indications. But if it has already bound
while the ASP is in INACTIVE State, it means that it is ready to process MTP3
Indications. The M3UA at ASP can always update the Status of the DPCs in
INACTIVE State, even when it is not indicating it to the Users above.

    I the current situation, the MTP User can rely on the fact that the ASP
    will perform DAUD (if necessary) when moving to ASP-ACITVE for the AS and
    will deliver the MTP-RESTART-ENDS primitive containing the status of all
    destinations.

Well, I could easily go on, but can you address these three issues first?

[Anshoo]
I find that allowing SSNM in INACTIVE State would only be useful.

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Nov 2002 00:08:47 -0700

Anshoo,

[email-masked] wrote:                                                     (Thu, 14 Nov 2002 11:23:11)
> of the ASP to AUDIT the Status of the Point Codes that it would be

So you are going further to say that INACTIVE ASPs can now send DAUD?

> [Anshoo]
> There is no need to combine both SSNM and DATA messages.

Yes there is.  These are both primitives of the MTP/MTP-User interface.
It makes no sense to exporting the MTP/MTP-User interface to send some
primitives and not others.

> Part might actually not be transferring Data but still can reside on an
> INACTIVE ASP.

No, this is the definition of ASP INACTIVE for exporting the MTP/MTP-User
interface, that when the ASP is INACTIVE for an AS, it is not prepared to
receive any MTP-User primitives.  If an ASP wants to receive MTP User primitives
when it is not processing them, it should use Broadcast Mode, for which this
was intended.

> Moreover the User Part might be available on some other ASP, which is ACTIVE
> and hence the STATE of the DPCs at the User Part are out of sync with the
> underlying M3UA at the newly Active ASP after a switchover... This is
> actually a case for supporting SSNM in INACTIVE State.

It think you are missing an important point of M3UA here: ASPs must coordinate
call state, connection state and transaction state perform anything near a
smooth switchover.  The desintation state is trivial compared to the amount of
state that the MTP-User must share between ASPs.  This is the responsibility
of an ASP to ASP protocol.  If you want to synchronize (loose or tight)
multiple ASPs on the same AS, use Broadcast traffic mode.

> INACTIVE State, even when it is not indicating it to the Users above.

The ASP M3UA is never expected to store MTP internal state, nor to store MTP-User
state: it is at the boundary of the MTP/MTP-User interface.  The ASP cannot
correctly perform the responsive MTP-PAUSE and MTP-STATUS procedures of Q.704
in such an arrangement, and transferring copies of these primitives to users
in the INACTIVE state will actually break the 1, 2n, 3n, procedures (by
prematurely delivering MTP-PAUSE and MTP-STATUS to the MTP-User).  MTP-PAUSE
and MTP-STATUS is a more complicated state machine than just storing the
status.  MTP (at the SG) actually needs to know the number of times that the
MTP-User (that is the AS and not a particular ASP) has attempted to send to
inaccessible or congested destinations to correctly perform the procedure.

> I find that allowing SSNM in INACTIVE State would only be useful.

I find it erroneous and incorrect.  Use Broadcast mode: it will provide what
you want to acheive without altering this behavior and destroying traffic
modes other than Active/Standby.

I still to not see a technical argument as to why you think this change is
necessary.

--brian