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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 01:53:22 -0700

Richard,

Let's say it is an override AS...  In that case only one can be
active at a time.

I'm glad you agree with the concensus in the RFC.  We have discussed
this many times over the last several years and have always arrived
at the same conclusion: SG cannot be required to send SSNM to inactive
ASPs.

It is even worse on an SG when dynamic registration is not performed.
In this case, every ASP is considered to be ASP-INACTIVE for every
AS when it comes up.  Sending SSNM to inactive ASPs would send every
SSNM to every ASP, regardless of the more restricted set of AS that
the ASP is actually configured to ever be active for.

--brian

Richard Adams wrote:                                                               (Thu, 06 Feb 2003 09:41:41)
> 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. 
> Of course, I hope 199,999 of your inactive ASPs do not decide to become
> active at the same time.....! 
> Kind regards,
> Dick Adams,
> [email-masked]
> 
>  
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 06 February 2003 09:15
> To: Zannin, Francois
> Cc: Samuel Dur D. Jeyaseelan; Nagar, Ashish; [email-masked]
> Subject: Re: [Sigtran] M3UA - ASP database equalization
> 
> 
> Zannin,,
> 
> That is contrary to the conensus of the RFC.
> 
> Consider 1 ASP active, 200,000 ASPs inactive.
> 
> The RFC cannot require an SG to send SSNM to an inactive ASP.
> 
> --brian
> 
> Zannin, Francois wrote:
> (Thu, 06 Feb 2003 09:02:41)
> > Samuel,
> > 
> > IMO, it's a good idea to inform inactive (BUT UP) ASP of the state of
> > the ss7 network especially in the override mode where an ASP can be
> > ready to recover an AS as soon as it receive an AS-Pending
> notification
> > from the SGp. In this condition, the ASP is ready to operate quickly
> and
> > minimize the risk of buffered message lost during the pending timer.
> > 
> > If someone does not want to receive SSNM because it is not able to
> > recover an AS, it just stays in an ASP-Down state.
> > 
> > Because SSNM reflects ss7 Point Code state that is not "SI" dependant,
> > it affects all AS for a network and then, unless SG that plays
> multiple
> > networks, the ASP UP is sufficient to filter the undesired SSNM.
> > 
> > Francois.
> > 
> > -----Original Message-----
> > From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]] 
> > Sent: Thursday, February 06, 2003 8:35 AM
> > To: Nagar, Ashish
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M3UA - ASP database equalization
> > 
> > 
> > 
> > Ashish,
> > 
> > But when inactive ASP changes state to active, first of all
> > it does not know whether to send DAUD or not.
> > 
> > It will try to send traffic - but actually destination is unavailable.
> > 
> > The worst case is when SG triggers restart procedures this case all
> the
> > SS7 destinations are unavailable via restarted-SG.But this poor ASP
> > (newly come-up ASP) keeps sending traffic via restarted-SG to reach
> the
> > SS7 destination and for every message ASP receives DUNA.
> > 
> > Are we not doing double-work here?
> > 
> > --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 Wed, 5 Feb 2003, Nagar, Ashish wrote:
> > 
> > > Hi Samuel
> > > 
> > > My point is why to do any processing if ASP is in Inactive state. 
> > > Think about ASP is in Inactive state for longer period and receiving
> 
> > > lots of DUNA and DAVA, while what matter is the present only when
> ASP 
> > > state changes to ASP-ACTIVE.
> > > 
> > > Thanks & Regards
> > > Ashish Nagar
> > > 
> > > 
> > > -----Original Message-----
> > > From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> > > Sent: Thursday, February 06, 2003 12:30 PM
> > > To: Nagar, Ashish
> > > Cc: [email-masked]
> > > Subject: RE: [Sigtran] M3UA - ASP database equalization
> > > 
> > > 
> > > Ashish,
> > > 
> > > My point is if SG is able to send DUNA to all inact and active ASPs,
> 
> > > we should not restrict it.
> > > 
> > > Sending DAUD is an alternative way ,If SG has direct way of sending 
> > > DUNA then Why do you need alternative way?
> > > 
> > > --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 Wed, 5 Feb 2003, Nagar, Ashish wrote:
> > > 
> > > > You can generate DAUD procedure at any time, so whenever ASP
> changes
> > 
> > > > state from Inactive to Active Just generate DAUD.
> > > > 
> > > > Thanks & Regards
> > > > Ashish Nagar
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Samuel Dur D. Jeyaseelan
> [mailto:[email-masked]]
> > > > Sent: Thursday, February 06, 2003 11:27 AM
> > > > To: [email-masked]
> > > > Subject: [Sigtran] M3UA - ASP database equalization
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > Currently RFC 3332 says that SG sends SSNM messages to all 
> > > > 'concerned ASPs'(means only ACTIVE ASPs).
> > > > 
> > > > +----+           +---+           +-----+
> > > > |SEP | ----------|SG |-----------| ASP1|
> > > > +----+           +---+           +-----+
> > > >                    |             
> > > >                    |             +-----+
> > > >                    +-------------| ASP2|
> > > >                                  +-----+
> > > > 
> > > > (ASP1 is active and ASP2 is incative - override mode)
> > > > 
> > > > When SEP is getting restarted ,SG sends DUNA to ASP1.
> > > > But SEP status is not changed in ASP2.There are two ways to solve 
> > > > this problem
> > > > 
> > > > 1. ASP1 can equalize its database with ASP2
> > > > or
> > > > 2.SG itself can send DUNA... to ASP2 (eventhough ASP2 is inactive)
> > > > 
> > > > IMO, SG can send SSNM messages to ASP (either ASP is in active or 
> > > > inact
> > > > state)
> > > > 
> > > > Any comments?
> > > > 
> > > > -----
> > > > 
> > > > section 5.4.2.1
> > > > 
> > > > ...
> > > >       - Pass the MTP-TRANSFER request primitive to the MTP3 of the
> > > >         concerned Network Appearance.
> > > > 
> > > > It conveys the meaning that M3UA layer (at SGP) MTP-TRANSFER
> request
> > 
> > > > is sent to MTP3.
> > > > 
> > > > But there is no primitive availabe between M3UA and MTP3.
> > > > 
> > > > I think it should be corrected.
> > > > 
> > > > ----
> > > > Presently ASP is unaware of SG's MTP3 restart,
> > > > ASP receives only DUNA for all SS7 point codes which can be
> > > > reachable via that SG.But in case of peer to peer protocol
> > > > SG and AS point codes are different, So why dont we send
> > > > DUNA with SG's point code to ASP? So that just by getting
> > > > single DUNA(with SG's PC) ASP will not route any message via that
> > SG.
> > > > This can avoid sending multiple DUNAs to ASP.
> > > > 
> > > > 
> > > > Any comments?
> > > > 
> > > > -----
> > > > section 1.4.1
> > > > 
> > > > ...
> > > >    Where a particular AS can be reached via more than one SGP, the
> > > >    corresponding Routing Keys in the SGPs should be identical.
> > (Note:
> > > >    It is possible for the SGP Routing Key configuration data to be
> > > >    temporarily out-of-sync during configuration updates).
> > > >  
> > > >                               +--------+
> > > >                               |        |
> > > >                  +------------+  SG 1  +--------------+
> > > >      +-------+   |  SS7 links | "STP"  |  IP network  |     ----
> > > >      |  SEP  +---+            +--------+              +---/      \
> > > >      |   or  |                    |*                      | ASPs
> |
> > > >      |  STP  +---+            +--------+              +---\      /
> > > >      +-------+   |            |        |              |     ----
> > > >                  +------------+  SG 2  +--------------+
> > > >                               | "STP"  |
> > > >                               +--------+
> > > >  
> > > >                     Figure 1  Example with mated SGs
> > > > 
> > > > Here SGP1 is in SG1 and SGP2 is in SG2. Basically mated SGs are 
> > > > located geographically in different places.The ideas is when SG1 
> > > > goes down in CITY1(due to earthquake...) , all the traffice still 
> > > > can be handled by SG2 which is in CITY2.
> > > > 
> > > > SGP2 is mate for SGP1, On failure of SGP1, all the messages will
> be 
> > > > routed from SGP1 to SGP2.
> > > > 
> > > > Does all these things mean to say that SGP1's mate 'should be' 
> > > > present in SG2 and not in SG1 itself ?
> > > >  
> > > > 
> > > > Comments are welcome.
> > > > 
> > > > --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.
> > > *******
> > > > 
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/sigtran
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > 
> > > 
> > 
> > _______________________________________________
> > 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

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 03:01:39 -0600 (CST)

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. *******

> interested. Any other method of working would lead to impossible loading

When SG itself is re-starting , it means no ASP can reach any SS7
destinations via re-started SG.Always it is good to tell my ASP
who is in inactive state about SS7 destinations unavailability.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 02:23:44 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 03:01:39)
> who is in inactive state about SS7 destinations unavailability.

It is unneccessary.  Iff the ASP goes active, the SG can send DUNA(*)
to it in one message to indicate that it is restarting.  The SG isn't
required to wait for DAUD to do this, it could send DUNA(*) just because
the ASP hase become active, or it could send DUNA(*) in response to the
first DATA message from the ASP.

There is no need to send SSNM to inactive ASPs.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 04:00:46 -0600 (CST)

Brian,

> first DATA message from the ASP.

Alternative ASP has to find out destination status by sending DAUD or
DATA.This is unnecessary traffic if the ASP had already received DUNA(*).

If there are 100 ASPs coming up ,  100 DAUD or DATA should be sent from
ASP, obviously here the problem with respect to number of un-necessary
messages - POTENTIAL.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 03:16:43 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 04:00:46)
> DATA.This is unnecessary traffic if the ASP had already received DUNA(*).

The alternate ASP does not have to send DAUD.

> ASP, obviously here the problem with respect to number of un-necessary

100 ASPAC Req mesages and 100 ASPUP Ack messages have to be sent for 100 ASPs
to come up.  There is little difficulty bundling a 100 DAUDs on the 100
ASPACs.  There is no loss of efficiency.

If SSNM were to be sent to inactive ASPs, 100 messages would be sent for
every SSNM.  There is no ASPAC or ASPAC Ack to bundle with these and they
could be sent repeatedly to inactive ASPs before they ever activate.

So, for the current situation:

  SG sends 50 SSNM to the active ASP.
  100 ASPs go active sending 100 ASPAC and 100 DAUD and receiving
  100 ASPAC Ack and 100 SSNM (including all 50 indications).

  SG sends a total of 250 messages, bundled in 150 packets.
  Each ASP sends 2 messages bundled in 1 packet.
  Total 150 packets.

For your unnecessary situation:

  SG sends 50 SSNM to each of 101 ASPs (1 active and 100 inactive).
  100 ASPs go active sending 100 ASPAC and receiving 100 ASPAC Ack.

  SG sends a total of 5150 messages, in 5150 packets.
  Each ASP sends 1 message in 1 packet.
  Total 5250 packets.

You suggestion would have us send 5150 packets where 150 will do.

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

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 03:20:26 -0700

Samuel,

Sorry 250 packets vs. 5250.  The 5000 unnecessary packets are the useless
messages sent to inactive ASP.

There is no way the SG can be required to send SSNM to inactive ASP.

--brian

Brian F. G. Bidulock wrote:                                                         (Thu, 06 Feb 2003 03:16:43)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 04:48:37 -0600 (CST)

Brian,

> The alternate ASP does not have to send DAUD.

You have not read properly my mail. I said "DAUD or DATA"..
see above.

> ASPACs.  There is no loss of efficiency.

Bad concept. Only 5% of your idea is good remaining 95% is BAD.
This concept cannot be used to develop a good M3Ua stack.

>   SG sends 50 SSNM to each of 101 ASPs (1 active and 100 inactive).
Again your example is wrong.PRACTICALLY NOBODY WILL NEVER EVER CONFIGURE
1 ASP and 100 ASPs INACTIVE.AND THERE IS NO NEED FOR THIS BAD
CONFUGURATION WHICH IS WASTING RESOURCES.

> You suggestion would have us send 5150 packets where 150 will do.
According to your example 5150 packets are used instead of 150 packets.
Poor example and poor solution.

--Samuel

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 04:51:50 -0600 (CST)

Brian,

I have never and ever used these numbers '250, 5250, and 5000'
they all are your example .Since your example is poor so your suggestion
is also wrong.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 04:17:57 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 04:48:37)
> You have not read properly my mail. I said "DAUD or DATA"..

You did not read above.  I said that the SG can send DUNA(*) to the ASP
when it goes active.  The ASP does not have to send DAUD or DATA.

> This concept cannot be used to develop a good M3Ua stack.

Explain.

> Poor example and poor solution.

It was your example.

And your solution is demostrably poor for your example.

I'll stick with the RFC approach, thank you.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 04:19:27 -0700

Samuel,

Your example, my count.

You have yet to show any efficiencies gained by deviating from the RFC
in any circumstance.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 04:51:50)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 04:25:09 -0700

Samuel,

Mine is not a suggestion.  It is the RFC.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 05:47:50 -0600 (CST)

Brian,

> when it goes active.  The ASP does not have to send DAUD or DATA.

WRONG. 

 What about DAVA, SCON,DRST? as soon as ASP comes up Will you send
these messages based on the destination status?
Again this is indirect solution.Finally stack will be implemented with
these concepts but we cant find efficentcy?

> I'll stick with the RFC approach, thank you.
Yes everybody wants to stick with RFC approach.But if RFC approach is
inefficent then anybody can suggest efficent approach.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 04:50:57 -0700

Samuel,

What inefficiencies do you think exist in the current approach?

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 05:47:50)

---

From: "Richard Adams" <[email-masked]>
Date: Thu, 6 Feb 2003 09:41:41 +0100

Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 06 February 2003 09:15
To: Zannin, Francois
Cc: Samuel Dur D. Jeyaseelan; Nagar, Ashish; [email-masked]
Subject: Re: [Sigtran] M3UA - ASP database equalization

Zannin,,

--brian

Zannin, Francois wrote:
notification
and
multiple
the
the

ASP 

changes
request
|
be 
Inc.

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 22:23:12 -0600 (CST)

Richard,

> interested. Any other method of working would lead to impossible loading

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.

> active at the same time.....! 

Theoritically your example sounds good but practically NOBODY will
configure 1 ASP ACTIVE and 199,999 ASPs INACTIVE.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 21:25:17 -0700

Samuel,

The RFC does not restrict the number of inactive ASPs.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 22:23:12)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 22:40:48 -0600 (CST)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 22:02:02 -0700

Samuel,

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 22:40:48)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 23:13:44 -0600 (CST)

Brian,

Yes , The RFC does not restrict the number of inactive ASPs.
But network configuration will restrict.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 22:19:16 -0700

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)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 7 Feb 2003 00:00:34 -0600 (CST)

Brian,

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 23:19:04 -0700

Samuel,

If DAUD is unnecessary to your implementation, don't send it.
The RFC permits you to not send DAUD.

But, the SG cannot be required to send SSNM to inactive ASPs.

BTW it is not _my_ argument, it was the conensus of the WG as
captured in the RFC, reinforced by emails from Dick, Tolga,
and myself on this thread.

I was responsible for having the DAUD procedure reduced from
SHOULD to MAY on the "MTP Restart" thread from September 2001.
So you can thank me that you don't have to send DAUD if you
don't need the reponses.

A practical approach if your ASPs are stupid enough to not
share any state information in override mode, is to not
send DAUD and rely on responsive procedures.  This is because
having a destination other than accessible is a rare
circumstance in the SS7 network.

For MTP Restart, the smart SG will send DUNA(*) immediately
following ASPAC Ack and I don't see any problem even requiring
the SG to do so when ASPs are activating into an MTP Restart.

So its simple, if you think your ASP needs to update its
database, send DAUD.  If you think it doesn't, don't send DAUD.

Dumb ASPs that don't share state are not going to be able to
process any calls or transactions after the failover anyway,
so it really doesn't matter.

I think that your concerns have been adequately addressed on
this thread.

Unless you can come up with a different argument, further
discussion is pointless.

--brian

Samuel Dur D. Jeyaseelan wrote:              (Fri, 07 Feb 2003 00:00:34)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 7 Feb 2003 00:37:04 -0600 (CST)

Brian,

What is the risk at SGP to send SSNM messages to INACT ASP?

What factor restricts INACT ASP to receive SSNM messages?

(please dont give me IMPOSSIBLE and practically unimaginable examples).

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 23:47:09 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Fri, 07 Feb 2003 00:37:04)
> What factor restricts INACT ASP to receive SSNM messages?

Concensus.

--brian