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

From: "Zannin, Francois" <[email-masked]>
Date: Thu, 6 Feb 2003 14:30:15 +0100

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent: Thursday, February 06, 2003 2:01 PM
> To: Zannin, Francois
> Cc: Samuel Dur D. Jeyaseelan; Nagar, Ashish; [email-masked]
> Subject: Re: [Sigtran] M3UA - ASP database equalization
> 
> 
> Zannin,,
> 
> Zannin, Francois wrote:                                       
>                      (Thu, 06 Feb 2003 13:44:40)
> > Bidolock,,
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, February 06, 2003 1:35 PM
> > > To: Zannin, Francois
> > > Cc: Samuel Dur D. Jeyaseelan; Nagar, Ashish; [email-masked]
> > > Subject: Re: [Sigtran] M3UA - ASP database equalization
> > > 
> > > 
> > > Zannin,,
> > > 
> > > So you see that there are ASP that do not want to receive
> > > SSNM for inactive AS.  This is one reason why the SG cannot 
> > > be required to send such useless SSNM to inactive ASPs.
> > 
> > If an ASP do not need to receive SSNM, it just do not send 
> the ASP UP. 
> > As soon as the ASP is ready to activate an AS, it sends the ASP UP, 
> > and then it is notified by the SSNM.
> 
> There are ASP that need to receive NTFY for an AS but do not 
> need to receive SSNM for the AS.  In ASP-INACTIVE state, the 
> ASP receives NTFY, but does not receive SSNM.  If the ASP 
> wishes to receive SSNM, it moves to the ASP-ACTIVE state.
> 
> > SSNM reflect the state of a ss7 SP and is valid for all AS 
> of the same 
> > NA, so receiving a SSNM for one or several AS is the same thing.
> 
> Not true.  Two AS in the same NA (but different point codes, 
> not just different SI) can have different routing.  One AS 
> can be given DUNA because it is not permitted to access the 
> destination (has no route to the destination), the other 
> given DAVA because it is permitted to access the destination 
> (has a route to the destination). So, where multiple AS share 
> the same association, RC is required in the SSNM message to 
> indicate for which AS the SSNM message pertains. All RCs to 
> which the message pertains must be listed in the SSNM. None 
> of these RCs may be inactive.
> 

The state of a ss7 network destination is the SAME on a SG for all users
(remote AS).
DUNA/DAVA/DRST reflects the state of the PC.
DUPU reflects the state of a SI on a SP.

UNLESS special SG that locally allows an AS to use or not a destination,
this behavior means that a SG can see a ss7 destination but prohibits an
AS to use it! In that case, the SSNM do not reflects the state of a
destination but a management state on a SG for a couple (M3UA-AS <-> ss7
Destination)! Very tricky SG to manage.

> > If you receive a SSNM for one AS, it is valid for all AS of 
> the same 
> > NA.
> 
> That is not true.  See above.
> 
> > If you don't need to receive SSNM,,,,  don't send the ASP UP.
> 
> On the contrary, of you need to receive SSNM, send ASP Active.
> 
> --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, 6 Feb 2003 06:43:13 -0700

Zannin,,

Zannin, Francois wrote:                                                            (Thu, 06 Feb 2003 14:30:15)
> DUPU reflects the state of a SI on a SP.

No it does not.  See the thread "RC in DATA and SNMM".  Several example
network configurations were presented where this does not hold.

> UNLESS special SG that locally allows an AS to use or not a destination,

One AS can have one set of routing, another a different set of routing.

> AS to use it!

The SG uses one set of routes for one AS, and a different set of routes
for another AS.  This is not a radical concept.

> In that case, the SSNM do not reflects the state of a

Not tricky at all.  STPs do this all day long.

--brian

---

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

Hi,
All i want to say - here i have precised.

    SG1
 +------+               +------+
 | SGP1 |---------------| ASP1 |
 +------+               +------+
     |
     |                  +------+
     +------------------| ASP2 |
                        +------+
Mode : over-ride
ASP1 - ACTIVE
ASP2 - INACTIVE

Say initially ss7 destination status - TABLE1 at ASP1 and ASP2.

PC   STATUS    DIRECT-ROUTE  ALT-ROUTE ...
--------------------------------------
111 available   SG1           SG2      ...
222 available   SG1           SG2
333 available   SG1           SG2
444 available   SG1           SG2
555 available   SG1           SG2

Now ASP1 is handling traffice.
ASP1 gets DRST(222) and DUNA(333,444,555) from SGP1.

So the TABLE1 at ASP1 looks

PC   STATUS    ROUTE-ROUTE  ALT-ROUTE ...
-------------------------------------
111 available   SG1          SG2      ...
222 restrct     SG1          SG2
333 unavail     SG1          SG2
444 unavail     SG1          SG2
555 restrct     SG1          SG2

But ASP2 keeps the old TABLE1.

Say ASP1 goes down so SGP1 sends NTFY to ASP2.
ASP2 becomes ACTIVE.

1.ASP2 looks at TABLE1 which says all PCs are available So tries sending 
DATA(222) but actually PC 222 is restricted so it receives DRST(222).

2.ASP2 tries sending DATA(333) but it receives DUNA(333)

3.ASP2 tries sending DATA(444) but it receives DUNA(444)

4.ASP2 tries sending DATA(555) but it receives DRST(555).

Here my point is If ASP2 already had received
DRST(222),DUNA(333),DUNA(444)
and DRST(555) from SGP1 when ASP2 was in INACT state, It would have
directly selected ALR-ROUTE SG2 to send the traffice. It does not waste its
precisous time by sending DATA or DAUD to find the dest node
status(according to the old TABLE1).

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

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 08:01:38)
> All i want to say - here i have precised.

Answer me this simple question:

   What time is wasted sending DAUD?

--brian

---

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

Brian,
(Sorry i did not see your last mail, just today morning saw it)

>    What time is wasted sending DAUD?

1.First of all sending DAUD is unnecessary.
  (RFC says newly ACTIVE ASP MAY send DAUD and it never said "MUST")

2.In case if newly ACTIVE ASP sends DATA(222), definitely it will receive
DRST(222) - Here these two messages (DATA and DRST) are un-necessary.

ALL THESE UNNECESSARY MESSAGE COMMUNICATION CAN BE AVOIDED IF SGP HAD SENT
SSNM MESSAGES WHEN ASP2 WAS IN INACTIVE STATE.

SENDING SSNM MESSAGES TO INACTIVE ASP IS A DIRECT METHOD OF UPDATING
DESTINATION STATUS OF SS7 NODES AND SGP IS ALSO ABLE TO SEND SSNM TO 
INACTIVE ASP.

IMO IT WOULD BE GOOD IF WE ALLOW INACTIVE APS TO RECEIVE SSNM MESSAGES.

--Samuel

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 22:13:17)
> IMO IT WOULD BE GOOD IF WE ALLOW INACTIVE APS TO RECEIVE SSNM MESSAGES.

You didn't answer the question:

I suppose that you cannot answer the question, because no time
is wasted sending DAUD.

--brian

---

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

Brian,

> I suppose that you cannot answer the question, because no time
To prepare a DAUD message , ASP has to read BIG ss7 dest status table and
he has to send to SGP, RUN A TIMER AND WAIT FOR RESPONSE.

Another case if ASP has registered with a DPC and empty OPC list(means any
SS7 node can reach ASP via SGP). This case with what point code DAUD will
be sent from ASP?

--Samuel

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 22:37:58)
> he has to send to SGP, RUN A TIMER AND WAIT FOR RESPONSE.

It doesn't have to read any database, it can simply send DAUD(*).

It does not have to run a timer waiting for a response.  There is no
timer specified in the RFC for DAUD responses.  On the other hand, there
is a timer specified while waiting for ASPAC Ack, T(ack).

So the ASP simply tacks DAUD(*) onto the ASPAC Request and waits for
ASPAC Ack.  There is no delay.

> SS7 node can reach ASP via SGP). This case with what point code DAUD will

It sends DAUD(*) (where the '*" is a Mask value in the Affected Point Code
parameter greater than or equal to the number of bits in the point code,
indicating all routes available to the AS as indicated by the RC).

No time delay.

Any other absurd arguments?

Or, would you still have the SGs send hundreds or thousands of useless
messages to avoid you having to send a single DAUD(*) (only about 32
bytes long) immediately following the ASPAC?

Gee, if you have a decent SCTP you can even bundle the DAUD(*) with the
ASPAC.

--brian

---

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

Brian,

> is a timer specified while waiting for ASPAC Ack, T(ack).

Again i am saying RFC never says "NEWLY ACTIVE ASP MUST HAVE TO SEND DAUD"
 your initial example was wrong so it leads into unnecesary things.

> bytes long) immediately following the ASPAC?
After sending DAUD(*), ASP will receive DRST(222,999,112,...), DUNA(333,876,...)
and SCON(555,666,...) all these useless messages, according to your absurd
arguements. And these useless messages i have to process at ASP then ASP
has to start its real work. ASP has to spend its precious time to process
all these useless messages. Thats all your argument.

> Gee, if you have a decent SCTP you can even bundle the DAUD(*) with the
Indirect method and tomorrow your will have one more indirect method...

--Samuel

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 23:33:33)
>  your initial example was wrong so it leads into unnecesary things.

So don't send DAUD.

The RFC is quite clear:

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

   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.  If MTP restart is in progress at the SG, the
   SGP returns a DUNA message for that destination, even if it received
   an indication that the destination became available or restricted.

You said your ASP was coming ASP-ACTIVE and did not have current
destination statuses.  If you want to update them, send DAUD as
described in the RFC.  If you don't, don't.

And, there is no delay cause by the procedure in any event.

> arguements.

There are not useless, the ASP has asked for them because it does not
know the current status of any of the destinations.  If the ASP has
current status it does not need to send DAUD at all.  The ASP gets the
information requested.  If it doesn't need the information it should not
request it.

> And these useless messages i have to process at ASP then ASP

If you don't want to receive them, don't request them with DAUD.

So which is it?  Does you database need to be updated at the ASP or not?
If it needs to be updated, it needs the status of all destinations
(including congestion and restriction).  If it doesn't need to be updated
don't send DAUD.

In any event, contrary to your claims, there is no delay.

--brian

---

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

Brian,

>    an indication that the destination became available or restricted.

It says "ASP MAY..." but not "ASP MUST..."

> And, there is no delay cause by the procedure in any event.

What do you mean? AT ASP Sending DAUD and PROCESSING DRST,DUNA, SOCN
will not consume any CPU time?If so please suggest me what CPU you are
using?
An efficent ASP will never spend its CPU time to process all these
unnecessary messages.

An efficent ASP would have received all ss7 destination status messages
when it was in INACT state.And it will start processing real traffic as
soon as comes up.

> information requested.  If it doesn't need the information it should not
They are absultely usefull for an INEFFICENT ASP but 100% useless for an
EFFICENT ASP.

> In any event, contrary to your claims, there is no delay.
see above.

--Samuel

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Fri, 07 Feb 2003 00:23:34)
> It says "ASP MAY..." but not "ASP MUST..."

Thank you.  I had it changed to MAY.  I'm glad you like it.

> when it was in INACT state.And it will start processing real traffic as

Don't send DAUD if you don't need the responses.
Start sending traffic immediately.

> They are absultely usefull for an INEFFICENT ASP but 100% useless for an

So don't have your EFFICIENT ASP send DAUD.  But, sorry,  it cannot expect
to receive SSNM while inactive.  If you want database updates without DAUD,
get them from the active ASP using whatever means you want.

--brian