Subject: RE: [Sigtran] M3UA - ASP Inactive

From: [email-masked]
Date: Wed, 13 Nov 2002 09:32:09 +0530

Tolga,

----- Original Message -----
From: "Tolga Asveren" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 12, 2002 10:36 PM
Subject: RE: [Sigtran] M3UA - ASP Inactive

> Anshoo,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, November 12, 2002 10:26 AM
> > To: [email-masked]
> > Subject: Re: [Sigtran] M3UA - ASP Inactive
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > I would agree with Jeffery that SSNM messages should be
> > processed by ASP in
> > INACTIVE state also.
> > Since RC is an optional parameter inside the SSNM, it is not
> > mandatory to have
> > the AS registered before sending the SSNM.
> [TOLGA] RC is not optional, it is semi-optional, i.e. if traffic for more
> than one AS is carried over one association, it is mandatory.
[Anshoo]
When the ASP has not registered a RK, SG need not send an RC in
SSNM and this is clearly given in the RFC, Section 3.4.1

> > During MTP Restart also, the SSNM can be sent to all the
> > ACTIVE/INACTIVE  ASPs
> > instead of only ACTIVE ASPs.
> [TOLGA] All of this is quite gray area. If you think this as similar to
> MTP3-Restart, in SS7 case, in this situation MTP3 informs user parts about
> the available destinations.
> > We had a concensus regarding this approach at the interop.
> [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.

> >
> > Regards
> > Anshoo.
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Tuesday, November 12, 2002 3:10 PM
> > Subject: Re: [Sigtran] M3UA - ASP Inactive
> >
> >
> > > Jeffrey,
> > >
> > > This issue was addressed in September 2001 in the thread
> > "M3UA: MTP Restart"
> > > where the restarting behavior of SG MTP and ASP AS was
> > addressed.  This is why
> > > SSNM was added with DATA in the passage:
> > >
> > > > > "In this [ASP-INACTIVE] state the ASP SHOULD NOT be sent any
> > > > > DATA or SSNM messages for the AS for which the ASP is inactive."
> > >
> > > It was discussed again in December of 2001 in the thread
> > "m3ua 10, sua 9: SSNM
> > > to inactive ASPs" where the end result was the same.  There
> > is no need to send
> > > SSNM to inactive ASPs.  There are a large number of reasons
> > for not doing so.
> > >
> > > There is no reason to require an SG to send SSNM to
> > inactive AS and the SG
> > > cannot be required to do so.  The ASP has at its disposal
> > the DAUD procedure
> > > and can obtain an update any time that it likes once it is
> > active, or can skip
> > > the DAUD procedure and rely on the responsive MTP-PAUSE
> > procedures to MTP3
> > > users.  No example could be brought forward where an ASP
> > could get any
> > > advantage whatsoever from receiving SSNM while inactive.
> > >
> > > (When an AS is inactive, the SG is not even required to
> > maintain valid routing
> > > information for the AS.  It is only once the AS is active
> > that the SG might
> > > care to send anything to it at all.)
> > >
> > > The correct procedure for a restarting ASP (an ASP going
> > ASP-ACTIVE for an AS)
> > > is to perform the DAUD procedure.  You will see in Section
> > 4.6 MTP Restart:
> > >
> > >    "When the SG has completed the MTP Restart procedure,
> > the M3UA layers at
> > >    the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
> > >    available/restricted SS7 destinations using the
> > DAVA/DRST messages."
> > >
> > > The intention here was that in non-cluster routed networks
> > with a large number
> > > of signalling points, the amount of signalling information
> > sent after MTP
> > > Restart Ends to an active ASP may be a significant amount
> > of information (long
> > > list of DAVAs), and sending these to an inactive ASP is
> > foolish and further
> > > delays the MTP restart procedure.
> > >
> > > So, for the MTP restart procedure, no DAVA/DRST messages
> > are sent to ASPs in
> > > the ASP-INACTIVE state.  Any ASP relying upon SSNM messages
> > to be sent to it
> > > during the ASP-INACTIVE state will not only lose normal
> > SSNM messages but will
> > > lose SNMM messages sent as part of the MTP restart procedure.
> > >
> > > Also, the correct procedure for an ASP is described in
> > Section 4.6 as follows:
> > >
> > >    "The ASP MAY choose to audit the availability of
> > unavailable destinations
> > >    by sending DAUD messages.  This would be for example the
> > case when an AS
> > >    becomes active at an ASP and does not have current
> > destination statuses."
> > >
> > > The phrase "does not have current destination statuses" was
> > intended to
> > > account for the situation where an ASP which is becoming
> > active for an AS
> > > already has valid availability/restriction/congestion
> > information from one of
> > > its ASP peers.
> > >
> > > So, everything in the RFC is declares that ASPs should use
> > the DAUD procedure
> > > when the go active for an AS if they don't have current
> > routing information
> > > and that SSNM will not be sent to inactive ASPs, neither
> > during the normal
> > > course of affairs, nor during MTP restart.  These passages
> > received careful
> > > attention, much discussion and clear consensus before the
> > move to the RFC and
> > > there are no interoperability issues to be addressed.
> > >
> > > The ASPs at the plugtest that failed to implement the
> > simple DAUD procedure as
> > > described in section 4.6 still do not have a
> > interoperability problem: they
> > > can assume when they go active that all destinations are
> > available and rely on
> > > the fact that the SG will send a responsive DUNA/SCON
> > message for every
> > > unavailable or congested destination to which the AS
> > attempts to send.  So the
> > > ASP can discover very quickly the same information that
> > would be relayed in
> > > response to a DAUD by simply sending traffic.  There is no
> > need for ASPs to
> > > collect SSNM in the inactive state (even less work for the
> > implementer).
> > >
> > > It should be pointed out that even the SG's view of the SS7
> > network will be
> > > out of sync with actual conditions when signalling traffic
> > management messages
> > > are lost or delayed in the network.  In those instances, it
> > is only the fact
> > > that the SS7 network itself implements responsive
> > procedures that the ASP will
> > > be informed of the ultimate state of each destination.
> > >
> > > There was also the problem of dynamic registration with
> > regard to SSNM.  This
> > > problem is as follows: the ASP does not have a
> > "de-registered" state for an
> > AS,
> > > it only has active and inactive states for an AS.  An ASP
> > is inactive for an
> > > AS even when it has not yet registered for the AS.
> > Considering that there is
> > > no requirement on an SG to hand out the same RC value for
> > each cycle of
> > > registration/deregistration of an ASP for a particular AS,
> > the SG might not
> > > have an RC value assigned to an ASP which is in the
> > ASP-INACTIVE state for an
> > > AS.  It can hardly send SSNM to it then.
> > >
> > > Overall the reasons for not sending SSNM to ASPs in the
> > inactive state
> > > outweigh any misunderstood advantage and this is why the
> > RFC says SHOULD NOT.
> > > An that is where the RFC should remain.
> > >
> > > --brian
> > >
> > >
> > >
> > > [email-masked] wrote:                 (Tue, 12
> > Nov 2002 01:36:41)
> > > >
> > > > ---------------------- Forwarded by Jeffrey
> > Craig/Raleigh/TEKELEC on
> > > > 11/12/2002 01:41 AM ---------------------------
> > > >
> > > >
> > > > Jeffrey Craig
> > > > 11/12/2002 01:32 AM
> > > >
> > > > To:    [email-masked]
> > > > cc:    [email-masked]
> > > >
> > > > Subject:    Re: [Sigtran] M3UA - ASP Inactive  (Document
> > link: Jeffrey
> > > >        Craig)
> > > >
> > > > Hello Brian,
> > > >
> > > > This contradicts the consensus at the plugtest where it
> > was expressed by
> > > > several
> > > > companies that their ASPs desire to receive SSNM during
> > ASP-INACTIVE. Those
> > > > of you who are following the list for M3UA, please
> > express your opinions
> > > > now.
> > > >
> > > > My opinion is that SSNMs sent by SG to ASP during
> > ASP-INACTIVE are valid
> > > > and
> > > > MAY be processed by the ASP.
> > > >
> > > > Regards,
> > > >
> > > > Jeff
> > > >
> > > >
> > > >
> > > >
> > > > "Brian F. G. Bidulock" <[email-masked]>@ietf.org on
> > 11/11/2002
> > > > 07:20:51 PM
> > > >
> > > > Please respond to [email-masked]
> > > >
> > > > Sent by:    [email-masked]
> > > >
> > > >
> > > > To:    "Wung, Joseph" <[email-masked]>
> > > > cc:    [email-masked]
> > > > Subject:    Re: [Sigtran] M3UA - ASP Inactive
> > > >
> > > >
> > > > Joseph,,
> > > >
> > > > Wung, Joseph wrote:                      (Mon, 11 Nov
> > 2002 18:37:28)
> > > > > The M3UA RFC stated,
> > > > >
> > > > > "In this [ASP-INACTIVE] state the ASP SHOULD NOT be sent any
> > > > > DATA or SSNM messages for the AS for which the ASP is inactive."
> > > > >
> > > > > Does anyone have problems with this statement like I
> > do?  I agree
> > > > > that the ASP should not be sent with DATA when in this state.
> > > > > But, I don't see reasons why SSNM should also be prohibited from
> > > > > being sent to the ASP.  In fact, the ASP in this state
> > would like to know
> > > > > what has happened in the SS7 network and then update its routing
> > > > > information accordingly before turning on user traffic
> > very much like
> > > > > MTP restart does.
> > > >
> > > > The proper approach for a restart procedure is for the ASP to
> > > > send a DAUD for the AS to update its routing tables, if the ASP
> > > > has not already obtained that data from its peers in the AS by
> > > > other means (i.e, ASP-ASP communication).  It is a waste
> > > > (and possibly a danger) for the SG to send SNMM for all inactive
> > > > AS when the AS has no indicated a need for the information.
> > > > This was the concensus on the matter captured in the RFC.
> > > >
> > > > >
> > > > > I would like to see "SSNM" being taken out from the quote.
> > > > > Any objection?
> > > >
> > > > Strong objection.  It was added because the DAUD procedure exists
> > > > for a restarting AS to use if it needs it.
> > > >
> > > > --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
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> > DISCLAIMER: This message is proprietary to Hughes Software Systems
> > Limited (HSS) and is intended solely for the use of the individual
> > to whom it is addressed. It may contain  privileged or confidential
> > information  and should not be circulated or used for any
> > purpose other
> > than for what it is intended. If you have received this
> > message in error,
> > please notify the originator immediately. If you are not the intended
> > recipient, you are notified that you are strictly prohibited
> > from using,
> > copying, altering, or disclosing the contents of this
> > message. HSS accepts
> > no responsibility for loss or damage arising from the use of
> > the information
> > transmitted by this email including damage from virus.
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 12 Nov 2002 23:28:47 -0700

anssharma,

[email-masked] wrote:                        (Wed, 13 Nov 2002 09:32:09)
> 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

---

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

Anshoo,

> SSNM and this is clearly given in the RFC, Section 3.4.1

That is not what section 3.4.1 says: it says that when an RK is not
"coordinated" between SGP and ASP (i.e, there is no routing key, all
traffic defaults to the association), then RC is not required.  In
all cases where multiple routing keys anre routing contexts are used
across a common association, it MUST be included.  Registration has
nothing to do with it.  Tolga's statement was correct.

--brian