Subject: RE: [Sigtran] M3UA - ASP Inactive

From: "Wung, Joseph" <[email-masked]>
Date: Wed, 13 Nov 2002 09:21:39 -0500

Brian,

To allow SGP to send SSNM messages to an Inactive ASP will be
about making the Inactive ASP hot standby, meaning that it
has the same view of the SS7 newtork as its counterpart ASP
that is currently Active.  At any moment the need for a switchover 
arises, the previously Inactive ASP can take over without
disruptting services to their MTP users, which would be
impossilbe if the newly Active ASP has to use DAUD to get
the current view of the SS7 network as the RFC stands today.

Joe

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 1:29 AM
To: [email-masked]
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?

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?

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.

    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.

    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?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Nov 2002 11:24:24 -0700

Joeseph,

Hot standby is achieved by 1+1 broadcast mode, not active/standby:
which is only warm standby since we removed the standby state.
For broadcast mode, both sides can be active, both receiving SSNM
and DATA, and the ASPs can decide between themselves which is currently
master.  Right idea, wrong traffic mode.

--brian

Wung, Joseph wrote:                       (Wed, 13 Nov 2002 09:21:39)