Subject: Re: [Sigtran] M3UA - AUTHORS-FINAL-ASP database equalization

From: "denim john" <[email-masked]>
Date: Fri, 07 Feb 2003 15:39:51 +0000

Brian,

I would request any one of the authors to conclude this thread.
samuel's idea seems to be good but this will result in changes of m3ua and 
sua.

Regards,
Denim.

An efficent ASP will take up the load as soon as it comes up.
Inefficient ASP may send DAUD and will receive DRST(...),DUNA(...),
SCON(...).  So from the point of ASP following are the unnecessary
messages.
.SENDING DAUD
.RECEING DRST
.RECEIVING DUNA
.RECEIVING SCON

From the point of SGP these are the unnecessay messages.
.Receiving DAUD
.SENDING DRST
.SENDING DUNA
.SENDING SCON.
Thats what your argument leads.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:

>Samuel,
>
>That is implementation dependent.  Sending SSNM to inactive ASPs restricts
>a dimension not restricted by the current and adequate procedure.  The
>SG cannot be required to send SSNM to inactive ASPs.  The RFC should not
>place a restriction on the number of inactive ASPs, because we cannot
>forsee all future dimensioning.  Procedures should scale as well as 
>possible.
>The existing procedure scales.  Sending SSNM to inactive ASPs does not.
>

>--brian
>
>Samuel Dur D. Jeyaseelan wrote:
(Thu, 06 Feb 2003 23:13:44)
> > > Brian,
> > > Yes , The RFC does not restrict the number of inactive ASPs.
> > But network configuration will restrict.
> > > --Samuel
> > >   Alcatel USA, Inc.                  Internet: 
><userid>@ssd.usa.alcatel.com
> >   1000 Coit Road, Plano, Texas 75075
> >   ******* The opinions expressed are not those of Alcatel USA, Inc. 
>*******
> > > On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:
> > > > Samuel,

> > > > > The RFC does not restrict the number of inactive ASPs.
> > > > > --brian
> > > > > Samuel Dur D. Jeyaseelan wrote:
(Thu, 06 Feb 2003 22:40:48)
> > > > > > > Brian,
> > > > > > > Ok, tell me, where you will configure 1 ASP ACT and 199,000 
>ASPs INACT?
> > > > I want to know which network does this poor configuration.
> > > > > > > --Samuel
> > > > > > > > > >   Alcatel USA, Inc.                  Internet:
<userid>@ssd.usa.alcatel.com
> > > >   1000 Coit Road, Plano, Texas 75075
> > > >   ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
> > > > > > > On Thu, 6 Feb 2003, Brian F. G. Bidulock wrote:
> > > > > > > > Samuel,
> > > > > > > > > The RFC does not restrict the number of inactive ASPs.
> > > > > > > > > --brian
> > > > > > > > > Samuel Dur D. Jeyaseelan wrote:
(Thu, 06 Feb 2003 22:23:12)
> > > > > > > > > > > Richard,
> > > > > > > > > > >   Alcatel USA, Inc.                  Internet:
<userid>@ssd.usa.alcatel.com
> > > > > >   1000 Coit Road, Plano, Texas 75075
> > > > > >   ******* The opinions expressed are not those of Alcatel USA, 
>Inc.
*******
> > > > > > > > > > > On Thu, 6 Feb 2003, Richard Adams wrote:
> > > > > > > > > > > > Brian,
> > > > > > > I agree with you. I think when the ASP becomes active, it 
>should
do an
> > > > > > > audit to update its knowledge of the SS7 network. The ASP 
>needs
to take
> > > > > > > the initiative to find out about the SS7 nodes etc. in which 
>it
is
> > > > > > > interested. Any other method of working would lead to 
>impossible
loading
> > > > > > > on the SG.
> > > > > > > > > > > Yes i agree but your suggestion is an indirect method.
> > > > > > I am proposing a direct method to send SSNM messages from SGP to
INACTIVE
> > > > > > ASP. When SGP sends DUNA or DRST to ACTVIE ASP, let him also 
>send a
copy
> > > > > > of the same message to INACTIVE ASP. I dont find any difficulty
here.
> > > > > > > > > > >  > > > > > > Of course, I hope 199,999 of your 
>inactive ASPs do not decide to
become
> > > > > > > active at the same time.....! > > > > > > > > > > 
>Theoritically your example sounds good but practically NOBODY will
> > > > > > configure 1 ASP ACTIVE and 199,999 ASPs INACTIVE.
> > > > > > > > > > > --Samuel
> > > > > > > > > > > > > > > > > > -- > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > _______________________________________________
> > > > > 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
> > >
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

---

From: Ken Morneault <[email-masked]>
Date: Fri, 07 Feb 2003 11:07:41 -0500

It would be useful if Samuel proposes text changes that could be 
reviewed and, then, we could see if there was consensus for making
this change.

Regards,

Ken

At 03:39 PM 2/7/2003 +0000, denim john wrote:

>samuel's idea seems to be good but this will result in changes of m3ua and sua.
>
>Regards,
>Denim.
>
>>forsee all future dimensioning.  Procedures should scale as well as possible.
>>> > > > > > Ok, tell me, where you will configure 1 ASP ACT and 199,000 ASPs INACT?
>>> > > > > > I agree with you. I think when the ASP becomes active, it should
>do an
>>> > > > > > audit to update its knowledge of the SS7 network. The ASP needs
>to take
>>> > > > > > the initiative to find out about the SS7 nodes etc. in which it
>is
>>> > > > > > interested. Any other method of working would lead to impossible
>loading
>>> > > > > > on the SG.
>>> > > > > ASP. When SGP sends DUNA or DRST to ACTVIE ASP, let him also send a
>copy
>>> > > > > > > > > >  > > > > > > Of course, I hope 199,999 of your inactive ASPs do not decide to
>become
>>> > > > > > active at the same time.....! > > > > > > > > > > Theoritically your example sounds good but practically NOBODY will

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Feb 2003 16:29:36 -0700

denim,

I thought it was concluded.

--brian

denim john wrote:                                                                    (Fri, 07 Feb 2003 15:39:51)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sat, 8 Feb 2003 03:35:26 -0600 (CST)

Ken,

Find the text changes below.

======================start===================

3.17 Disallowing SSNM messages in ASP-INACTIVE state
 
3.17.1 Description of the problem
 
   SSNM messages are received and updated(destination node status) in
   ASP-ACTIVE state but the backup ASP in inactive state is unaware
   of SS7 node status changes. So when backup ASP becomes active, it
   may not take over the traffic as soon as it becomes active.In
   order to avoid this problem following additional changes are
   proposed.
 
       1.SGP can send SSNM messages to ASP-INACTIVE state.
   
       2.ASP in inactive state can receive SSNM messages.
 
     Implementing above two points will enhance the efficiency of ASP by
     taking the traffic as soon as it becomes active.
 
     Above two points are true only when dynamic registration is allowed
     between ASP and SGP.
 
3.17.2 Text changes to the document
 
   ---------
   Old text: (Section 4.6)
   ---------
 
   When the SG discovers SS7 network isolation, the SGPs send an
   indication to all concerned available ASPs (i.e., ASPs in the ASP-
   ACTIVE state) using DUNA messages for the concerned destinations.
 
   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.
   No message is necessary for those destinations still unavailable
   after the restart procedure.
 
   ---------
   New text: (Section 4.6)
   ---------
 
   When the SG discovers SS7 network isolation, the SGPs send an
   indication to all concerned available ASPs (i.e., ASPs in the ASP-
   ACTIVE state or ASP-INACTIVE state) using DUNA messages for the
   concerned destinations.
 
   When the SG has completed the MTP Restart procedure, the M3UA layers
   at the SGPs inform all concerned ASPs in the ASP-ACTIVE state or ASP-
   INACTIVE state of any available/restricted SS7 destinations using the
   DAVA/DRST messages.No message is necessary for those destinations still
   unavailable after the restart procedure.
 
   ---------
   Old text: (Section 4.5.3)
   ---------
 
      - Isolation. The ASP is newly ASP-ACTIVE or has been
                   isolated from an SGP for an extended period.  The ASP
                   MAY request the availability/congestion status of one
                   or more SS7 destinations to which it expects to
                   communicate.
 
   ---------
   New text: (Section 4.5.3)
   ---------
 
      - Isolation. The ASP has been isolated from an SGP for an extended
                   period.  The ASP MAY request the
                   availability/congestion status of one or more SS7
                   destinations to which it expects to communicate.
 
3.17.3 Solution description
 
   Wherever "concerned ASP" is referred in the specification, it does
   mean that ASP in active state or ASP in inactive state.This is true
   only when dynamic registration is allowed between ASP and SGP.

=================END=========

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 8 Feb 2003 04:02:42 -0700

Samuel,

The SG cannot be required to send SSNM to inactive ASPs.

Also, unregistered ASPs are also in the ASP-INACTIVE state, yet are
unable to know to which AS an RC corresponds.  An SG which supports both
dynamic and static configuration cannot know if and ASP is already
configured with the RC of the AS, or whether it must regsiter first.
(An AS does not have an "unregistered" state.)  Therefore, the SG cannot
know whether sending SSNM to ASP in the ASP-INACTIVE state for an AS
will induce an error (Invalid RC), and when an error is induced whether
it is indeed because the ASP needs to register for the AS, or whether
some other configuration problem has occured.

Also, in Section 4.6, and ASP in the ASP-INACTIVE state is not a
"concerned" ASP.  You should note that the SG is not required to send
SSNM to all of the ASP-ACTIVE ASPs either: only the concerned ASPs in
the ASP-ACTIVE state for the AS.  When sending SSNM in using reponsive
procedures, it is only the ASP to which the SSNM is a response that is
"concerned".

MTP does not indicate to its users whether an MTP-PAUSE, MTP-RESUME, or
MTP-STATUS primitive is responsive or broadcast.  Therefore, some
implementations cannot determine which of the ASP-ACTIVE ASPs are
"concerned".  But certainly, for both responsive indications, ASPs in
the ASP-INACTIVE state are not concerned.

Also, the ASP-INACTIVE state for an AS corresponds to no MTP-User being
associated with the MTP-SAP.  This means that when all ASPs are in the
ASP-INACTIVE state, there is no MTP User associated with the MTP at the
SG.  Because there is no MTP-User associated with the MTP at the SG, the
SG cannot deliver MTP-PAUSE, MTP-RESUME or MTP-STATUS primitives to M3UA
at the SG and cannot then issue SSNM to ASPs.

When all the ASPs are ASP-INACTIVE, the SG cannot be expected to send
SSNM to any of them.

The RFC cannot require an implementation at the SG to use facilities
which are not provided to the MTP-User by MTP.  (Things like DRST are
OPTIONAL).

ASPs which are not in the multiple SG configuration are not required to
maintain any destination state whatsoever: SSNM delivered to the ASP are
delivered directly to the user as the corresponding MTP-PAUSE,
MTP-RESUME and MTP-STATUS primitives.  When an ASP is in the
ASP-INACTIVE state for an AS, it has no MTP-User to delivere these
primitive to.  Therefore, it is unnecessary to send SSNM to ASPs in the
ASP-INACTIVE state in the single SG configuration, and the SG cannot be
required to send them.  Multiple SG arrangements are OPTIONAL.

So, as before, the SG cannot be required to send SSNM to inactives ASPs.

The current RFC says that the SG SHOULD NOT send DATA or SSNM to
inactive ASPs or it will risk data loss.  This does not forbit the SG
from sending SSNM to inactive ASPs, it just recommends that it doesn't.
Becase of the above, to recommend that SG send SSNM to inactive ASPs
with the text changes you propose is not workable.

I am in total disagreement with your proposal.

Three others on this thread have also expressed that the current RFC is
sufficient in this regard.

The only change that I see as necessary would be to add the following
statement:

	When an ASP becomes active for an AS and the SG is experiencing
	SS7 network isolation or is performing the MTP Restart procedure
	for the AS, the SG SHOULD send a DUNA(*) to the newly active ASP
	to prevent the ASP from sending traffic.

	When an ASP becomes active for an AS and destinations normally
	acessible to the ASP are inaccessible, restricted or congested
	for the AS, the SG SHOULD send DUNA, DRST or SCON AS for the
	inacessible, restricted or congested destinations to the ASP
	newly active for the AS to prevent the ASP from sending traffic
	for destinations that it might otherwise not know are
	inaccessible, restricted or congested.

Still, the SG cannot be required to send SSNM to inactive ASPs, and the
ASP can certainly not rely upon receiving SSNM while inactive.  So, the
only sure way for the ASP to obtain information is after it goes ASP-ACTIVE.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Sat, 08 Feb 2003 03:35:26)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 8 Feb 2003 04:18:55 -0700

Sigtran,

I take it back: change SHOULD to MAY in the second clause:

 	for the AS, the SG MAY send DUNA, DRST or SCON AS for the
		           ^^^

Otherwise, the SG would be sending redundant information that an
single-SG ASP which does not maintain destination state will subsequently
obtain with DAUD using the currently recommended procedure.  This could
result in multiple MTP-PAUSE and MTP-STATUS primitives delivered to the
MTP User at the ASP which could confuse some MTP Users.

--brian

Brian F. G. Bidulock wrote:                              (Sat, 08 Feb 2003 04:02:42)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sun, 9 Feb 2003 22:27:13 -0600 (CST)

Brian,

> some other configuration problem has occured.
misunderstanding.See the proposed text changes,  it says that "SGP can
send SSNM messages to ASP", only when dynamic registration is allowed,
that means both SGP and ASP know RC.

> procedures, it is only the ASP to which the SSNM is a response that is
Again wrong. Proposed text changes will consider 'concerned ASP' as
ASP-ACTIVE or ASP-INACTIVE only when dynamic registration is allowed.
It means SGP knows AS and ASP knows RC.

> at the SG and cannot then issue SSNM to ASPs.
Wrong. LOGICALLY MTP's user part is available at SG.
Logically ASP-ACTIVE means ASP is ready to take over the traffic,
But still inactive ASP can receive SSNM messages but it SHOULD not 
take up the traffice as long as it is in inactive state.

> When all the ASPs are ASP-INACTIVE, the SG cannot be expected to send
No, Sending SSNM to inactive ASP will increase the efficiency of ASP.

> required to send them.  Multiple SG arrangements are OPTIONAL.

You have not read properly the 'proposed text changes'.

> with the text changes you propose is not workable.

Proposed text changes is only for DUNA,DRST,SCON and DAVA not for DATA.
Updating destination node status changes at inactive ASP will not have
any side effects.

> sufficient in this regard.
Three others also proposed "Sending SSNM to inactive ASP is good method".

> only sure way for the ASP to obtain information is after it goes ASP-ACTIVE.

Once the dynamic registration is over, Both SGP and ASP know th RC.
Once RC is known to SGP and ASP , it means MTP user part is availabe at
SG.
ONLY DATA message should not get exchanged when ASP in inactive state.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Feb 2003 02:25:03 -0700

Samuel,

I disagree with all your comments, and your proposal.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Sun, 09 Feb 2003 22:27:13)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Mon, 10 Feb 2003 04:58:43 -0600 (CST)

Any comment from authors?

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Feb 2003 05:39:17 -0700

Samuel,

I am an author.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Mon, 10 Feb 2003 04:58:43)

---

From: Ken Morneault <[email-masked]>
Date: Mon, 10 Feb 2003 09:07:15 -0500

Samuel,

It really doesn't matter what the authors think.  What matters is
the consensus of the group.

I'm not convinced that these text changes are needed.  Your
one argument is to increase the efficiency of the ASP during
failover.  However, these changes decrease the
efficiency of the SG for each inactive ASP.  This could lead
to unnecessary scaling problems for the SG.

If efficiency during failover is desired, it should be a goal
of the ASP design (which I think has been discussed previously
on this thread).  

Hopefully, more people will send in their comments/opinions.

Regards,

Ken

---

From: Ken Morneault <[email-masked]>
Date: Mon, 10 Feb 2003 09:08:27 -0500

I think the recommended text Brian provides below would be useful
for the IG.

Ken