Subject: M3UA 08 - ASP Auditing

From: "Duhoon, Rajiv" <[email-masked]>
Date: Wed, 15 Aug 2001 16:24:49 -0700

Hi Greg,

In section 4.3.3 "ASP Auditing" it has been mentioned that 

"If the SS7 destination is available and congested, the SGP
responds with an SCON message in addition to the DAVA message.
If the destination is restricted and congested, the SGP responds
with an SCON message in addition to the DRST."

1)

I want to know that if the sequence of messages is defined in such 
cases or these messages can be sent from SGP in any order.

I think that the sequence of these messages is important otherwise if a
DAVA message is received after SCON message, then how an ASP will
distinguish
between DAVA received in case PC status is both "congested & available"
and a DAVA received when PC status is "available" only.

2)

Do we really need to send DAVA and SCON if destination is congested and 
available? Doesn't "congested" status of a PC at ASP itself implies that 
its congested but still available.

3)

Is SGP always supposed to send an SCON message with "zero" cogestion level
in 
case a DPC is no more congested or it can also send a DAVA message in
response 
of DAUD message ?

Thanks,
Rajiv

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 21:42:45 -0500

Rajiv,

This has been discussed much on the list already.

Please see comments below...

Duhoon, Rajiv wrote:                      (Wed, 15 Aug 2001 16:24:49)
> and a DAVA received when PC status is "available" only.

The SCON must come before the DAVA or the DRST, and must be
followed by a DAVA or DRST.

> its congested but still available.

The SCON must come before the DAVA or the DRST, and must be
followed by a DAVA or DRST.

The DAVA comes after the SCON so the ASP knows to stop waiting
for a DRST.

> case a DPC is no more congested or it can also send a DAVA message in

Don't send a SCON if there is no congestion: just send DAVA
or DRST.  DAVA or DRST with no SCON indicates "no congestion"
response to DAUD.

Nevertheless, I see no reason why you shouldn't be able send
SCON(0) before DAVA if you really want.  It should not confuse
the ASP, as the ASP is prepared to receive SCON before DAVA or
DRST.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Wed, 15 Aug 2001 20:38:19 -0700

Thanks Brian. See my comments below:

-Rajiv

Rajiv,

[Rajiv] I want to know why do we need to send DAVA at all, when PC is
in available & congested state, only SCON should be sufficient?

[Rajiv] I am little confused here. What I understand from above text 
is if "congestion" is removed then only DAVA is sent. So here reception
of DAVA means no "congestion"

In response of my query# 1 you have mentioned that if destination is 
"congested & available" then SCON followed by DAVA is sent. In this
case even after receiving DAVA I am assuming that PC status is still
"congested".

We don't have any means (e.g. any timer) to distinguish between
DAVA message received in two different scenarios.
&
Why do we need to send DAVA at all in case PC is "congested and 
available". SCON message should be sufficient enough.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Greg Sidebottom <[email-masked]>
Date: Thu, 16 Aug 2001 01:59:01 -0400

Hi Rajiv, Brian

I think we need to add Brian's understanding re the order of the audit
responses to the M3UA draft - there is no text about the order in Issue 8.
I propose the following line in Section 4.3.3:

"In the case of a congested SS7 destination, the SCON MUST be sent before
the DAVA or DRST message."

Rajiv, one more response below ...

----- Original Message -----
From: "Duhoon, Rajiv" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Wednesday, August 15, 2001 11:38 PM
Subject: RE: M3UA 08 - ASP Auditing

> in available & congested state, only SCON should be sufficient?

[Greg] The thread we had some time ago on this topic concluded that an SCON
is not sufficient to say the PC is available - the PC could be also be in
the restricted and congested state.

Thanks,

    Greg

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Thu, 16 Aug 2001 09:18:26 -0700

Hi Greg, Brian

Thanks for your comments. Please see my comments below .....

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 10:59 PM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Hi Rajiv, Brian

----- Original Message -----
From: "Duhoon, Rajiv" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Wednesday, August 15, 2001 11:38 PM
Subject: RE: M3UA 08 - ASP Auditing

[Rajiv] I completely agree with you that only SCON is not 
sufficient in case PC is both restricted and congested but I think
only "SCON" is sufficient if PC is "congested and available" (i.e 
not restricted which is another possibility). If we send DAVA after
SCON to ASP, then ASP doesn't have any means to distinguish this DAVA
(which means that destination is not restricted) with another DAVA(which
means no congestion no restriction). Please let me know if I am missing
something .....

Thanks,
Rajiv  

Thanks,

    Greg

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 11:27:01 -0500

Rajiv,

Duhoon, Rajiv wrote:                                      (Thu, 16 Aug 2001 09:18:26)

[snip]

Otherwise, M3UA will need another timer at the ASP to say when
to stop waiting for a DRST after receiving a SCON in response
to a DAUD.  Instead, we just send DAVA after SCON to avoid the
need for a timer and the associated delays.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Thu, 16 Aug 2001 10:28:04 -0700

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 9:27 AM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Rajiv,

Duhoon, Rajiv wrote:                                      (Thu, 16 Aug 2001
09:18:26)

[snip]

[Rajiv] I think there is no need to wait at all at ASP if it doesn't 
receive DRST. Its the responsibility of ASP to remember the 
previous state of PC (if it was congested & restricted earlier)
and if it receives only SCON message in response of a DAUD message,
then it should not chanege PC state to be congested only and
forget that its previous state was both "congested & restricted". 
It should assume that its still "restricted and congested".

Later if the PC state becomes "available and congested " then it 
should send DAVA followed by SCON and not other way because after
receiving DAVA ASP will assume that PC is available .
(i.e not congested and not restricted). 

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 13:01:00 -0500

Rajiv,

Duhoon, Rajiv wrote:                                      (Thu, 16 Aug 2001 10:28:04)
[snip]
> (i.e not congested and not restricted). 

The ASP cannot remember PC state if it has just rebooted and
is issuing DAUD messages to recover that state, as was the
intention of the DAUD message.

If the ASP can remember PC states, it does not need to issue
a DAUD message in the first place.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Thu, 16 Aug 2001 11:12:16 -0700

Hi Brian,

see my comments below ....

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 11:01 AM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Rajiv,

10:28:04)
[snip]

[Rajiv] Definitely it can not remember if it has rebooted... but it
should remember it till it doesn't get next response message from SGP.

[Rajiv]If I am not wrong then DAUD is not related to remembering of 
PC status but to know the latest status of PC if in case ASP loses
any update information. So ASP needs to remember the states and send
DAUD as well if its PC status is not available.

And once again you are overlooking the core issue.... the handling
of DAVA messages in two different scenerios .......

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 13:46:06 -0500

Rajiv,

Duhoon, Rajiv wrote:                                      (Thu, 16 Aug 2001 11:12:16)
[snip]
> should remember it till it doesn't get next response message from SGP.

This would cause the ASP to have a transient "available" state
between the SCON and the DRST.  Not wise, particularly in the
reboot case.

(If it doesn't wait for a DAVA or DRST, the ASP may restart
traffic to a restricted destination for which it has just not
yet received the DRST, resulting in possible switchover from the
affected SG risking message missequencing.)

Having DAVA/DRST come after SCON makes it possible for the update
to be atomic in this respect.

> DAUD as well if its PC status is not available.

How was the ASP going to "lose" update information?  I can't see it
happening in anything but the case of a reboot.

> of DAVA messages in two different scenerios .......

I thought we were discussing the order of SCON/DAVA/DRST responses
to the DAUD message.  What "core issue" am I overlooking?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Thu, 16 Aug 2001 12:33:12 -0700

Greg,Brian ,
thanks for your comments
please see my comments below...........

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 11:46 AM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Rajiv,

11:12:16)
[snip]

[Rajiv] In my opinion it won't lead to any transient "available"
state.Consider the scenerio at ASP once again :

1) PC "restricted and congested"
2) DAUD message sent
3) SCON rxed : After processing of this message PC state should
remain to be "congested and restricted". ASP can't assume it to
be "congested and available" by just receiving SCON.

so I don't see any transient "available" state.

[Rajiv]Consider following scenerio 1.

	SGP					ASP
	PC Congested Only			PC Congested Only
		<----- DAUD------<
	PC still congested
		>----- SCON ------>	PC Congested
	PC Available 
		<----- DAUD------<
		>----- DAVA ------>	PC Available (no congestion no
restriction)

If a DAVA is sent after SCON (To indicate congested+available) then 
Scenerio 2:

	SGP					ASP
	PC Congested+Restricted		PC Congested Only
		<----- DAUD------<
	PC congested Only
		>----- SCON ------>	PC Congested
		>----- DAVA ------>     PC Available 
						but EXPECTED = Available +
congested 

But how ASP will differentiate between DAVA rxed in two different scenerios.
In my opinion DAVA followed by SCON must be sent  whenever "restricted +
congested"
status at SGP is changed to "available+congested". In any case DAVA should
not be sent
after SCON message in such a condition. 

[Rajiv] It may also happen if  SGP is down temporarily for some reason....
or
SGP doesn't update ASP for any reason or s/w bug. Protocol should be
robust enough to avoid any unwanted situation.

[Rajiv] just discussed it above.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 19:28:25 -0500

Rahiv,

Please see additional comments below:

Duhoon, Rajiv wrote:                                      (Thu, 16 Aug 2001 12:33:12)
[snip]
> so I don't see any transient "available" state.

We are talking about the ASP which has lost state.  The interoperable
SG would make no assumptions about the ASP's ability to retain state.
The purpose of the DAUD message is for the ASP to inquire of the
state when it is unsure of the the state (not when it knows the state).
For interoperability and atomicity of the response, the SG must
assume that the ASP does not know the state of the point code
(otherwise, why is it asking for it?)

Consider:  w/o DAVA

        SGP                                    ASP
        PC Congested+Restricted                (Doesn't know)
                       <-------DAUD-------<
                       >-------SCON------->    PC Congested+Available
                                               (incorrect)

                     ******transient state*****

                       >-------DRST------->    PC Congested+Restricted

And: w/DAVA

        SGP                                    ASP
        PC Congested+Restricted                (Doesn't know)
                       <-------DAUD-------<
                       >-------SCON------->    (Still doesn't know)
                       >-------DRST------->    PC Congested+Restricted

        SGP                                    ASP
        PC Congested                           (Doesn't know)
                       <-------DAUD-------<
                       >-------SCON------->    (Still doesn't know)
                       >-------DAVA------->    PC Congested

This was discussed in detail in previous threads.

[snip]
>                                               but EXPECTED = Available + congested 
> 
> congested" status at SGP is changed to "available+congested". In any case
> DAVA should not be sent after SCON message in such a condition. 

I would suggest that you don't design your SG state machines
with implicit races:  proper asynchronous state machine design
requires that you do not accept input events in the middle of
processing the previous input.  Here is how a correct state
machine will respond:

        SGP                                     ASP
                <----- DAUD-------<
                >----- SCON ------>
                >----- DRST ------>     PC Congested+Restricted 
        PC congested Only
                >----- DAVA ------>     PC Congested

The PC congested only even (I assume deriving from a TFA) is not
processed until the state machine has completed responding to the
DAUD.  At the time that the SG receives the DAUD it has the PC in
the Congested+Restricted state.

How about we make it even clearer:

    When the point code is congested and available at the time
    that an SG receives a DAUD for the affected point code, the
    SG MUST send a SCON immediately followed by a DAVA in response.

    When the point code is congested and restricted at the time
    that an SG receives a DAUD for the affected point code, the
    SG MUST send a SCON immediately followed by a DRST in response.

    When the point code is not congested but available at the time
    that an SG receives a DAUD for the affected point code, the
    SG MUST send a DAVA in response to a DAUD.  The SG in this case
    MAY optionally send a SCON indicating no congestion immediately
    before the DAVA response.

    When the point code is not congested but restricted at the time
    that an SG receives a DAUD for the affected point code, the
    SG MUST send a DRST in response to a DAUD.  The SG in this case
    MAY optionally send a SCON indicating no congestion immediately
    before the DAVA response.

There.  That should preclude loose state machine design as well.
> or SGP doesn't update ASP for any reason or s/w bug. Protocol should be

Well then my first example applies, the ASP will have a transient
state between SCON and DRST, particularly if this "lost" message
as a non-audit DRST.

> [Rajiv] just discussed it above.

You are going to a lot of trouble to try and remove a DAVA after
a SCON: I assure you that it is necessary.  But please feel free to
ask more questions.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Fri, 17 Aug 2001 09:24:09 +0530

arre wah pape!!!
aaj kal sigtran par cha raha hai?? :)
munish

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Thu, 16 Aug 2001 20:58:02 -0700

abe saale toone kya samajh rakha hai ;) bhaiya
trillium me kaam karte hain.... koi faltoo company 
nahin hai kya ? Trillium Sigtran have been awarded 
product of year.... or is saale Brain ne to naak
main dum kar ke rkha hai :).... tu suna.... abe
saale apna resume nahin bheja toone .....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 8:54 PM
To: sigtran
Subject: RE: M3UA 08 - ASP Auditing

arre wah pape!!!

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 17 Aug 2001 11:54:12 +0200

Hello,

I agree with Rajiv on this (very confusing) SCON, DAVA, DRST business. Of
course the ASP needs to keep track of the congestion/restriction status of
its peer (SG). DAUD is triggered by onset of congestion/restriction and
would normally only be stopped if no more SCON/DRST is received during some
abatement time, or a DAVA is received explicitly clearing all
congestion/restriction states. On reboot, the ASP can take either of 2
approaches (since it's lost all status information) :

- either assume everything is available (= no congestion/restriction); it'll
get SCONs or DRSTs upon sending DATA messages along the way, which will
trigger DAUD etc.

- be suspicious and send DAUD to every peer (start the auditing procedure
before sending DATA).

The choice between them is implementation/destination dependent.

Reception of either SCON/DRST is independent of one another, the order in
which they are received doesn't even matter ! The only important thing is
that upon sending DATA (ignorant of any state) or DAUD you may receive both
congestion and restriction information. Only if both conditions are absent,
you (may) receive an explicit DAVA. The wait for DAVA after SCON makes no
sense and makes handling of DAVA dependent on local timer settings. I think
the mail discussions here reached an unsatisfactory conclusion.

Hope everyone can agree this is a clearer approach ...

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 2:28
To: sigtran
Cc: Greg Sidebottom
Subject: Re: M3UA 08 - ASP Auditing

Rahiv,

12:33:12)
[snip]

Consider:  w/o DAVA

        SGP                                    ASP
                                               (incorrect)

And: w/DAVA

        SGP                                    ASP

        SGP                                    ASP

[snip]
congested 

        SGP                                     ASP
        PC congested Only

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 10:15:11 -0500

Gery,

Please see below...

Verwimp Gery wrote:                                       (Fri, 17 Aug 2001 11:54:12)
> its peer (SG).

> DAUD is triggered by onset of congestion/restriction and
> congestion/restriction states.

What do you mean triggered by onset of congestion/restriction?  I didn't see
DAUD being used in this fashion at all.  What would be the purpose of sending
DAUD at the onset of congestion/restriction?

I also don't see how (nor why) DAUD would be stopped by the ceasation of
SCON/DRST.  Ceasation is not even an event: it would take a timer.  Why would
you start on congestion/restriction and stop on silence?

Please clarify.

> On reboot, the ASP can take either of 2

We had certainly agreed on previous threads that SCON indicated only
congestion and *not* (as in the case of TFC in SS7) availability for
the audit case.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 17 Aug 2001 17:48:22 +0200

Hi Brian,

See below.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 17:15
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Gery,

Please see below...

Verwimp Gery wrote:                                       (Fri, 17 Aug 2001
11:54:12)

What do you mean triggered by onset of congestion/restriction?  I didn't see
DAUD being used in this fashion at all.  What would be the purpose of
sending
DAUD at the onset of congestion/restriction?

I also don't see how (nor why) DAUD would be stopped by the ceasation of
SCON/DRST.  Ceasation is not even an event: it would take a timer.  Why
would
you start on congestion/restriction and stop on silence?

Please clarify.

=>
[GV] : Of course there's nothing to prevent you to send DAUD whenever you
like, but to avoid unnecessary traffic you might want to wait till the SG
has sent you SCON/DRST/DUNA (triggered by an event in the SS7 network, or as
reminder if the ASP insists on sending traffic, similar to what happens in
the SS7 network). This is what I meant by "onset" : the ASP receives
SCON/DRST/DUNA without having sent DAUD.

Of course you don't have to stop DAUD (a periodic audit is fine by me). But
for those ASPs who'd rather send DATA and be done with DAUD, shouldn't await
an explicit DAVA before restarting traffic (unless you're absolutely sure a
DAVA couldn't get missing somewhere). The worst that can happen is that the
ASP receives an SCON/DRST/DUNA again, isn't it ?

I just wanted to paint different views of when and how to use DAUD.
<=

=>
[GV] : Also, SCON or DRST are "proof of life", i.e. availability is implied.
These messages only urge you to reduce/reroute traffic towards the
(available) destination. It seems silly to wait for an explicit DAVA after
SCON to make sure your destination isn't restricted, or depend on any order
these messages are sent. What do you assume between the reception of SCON
and DAVA anyway, that the destination is restricted as well or not ??
<=

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 11:18:44 -0500

Verwimp,

Verwimp Gery wrote:                                       (Fri, 17 Aug 2001 17:48:22)
[snip]
> > would normally only be stopped if no more SCON/DRST is received during
> > some abatement time, or a DAVA is received explicitly clearing all
> sending DAUD at the onset of congestion/restriction?
> 
> would you start on congestion/restriction and stop on silence?
> 
> Please clarify.
> 
> =>
> [GV]: Of course there's nothing to prevent you to send DAUD whenever you

Please clarify.  How does sending DAUD when it is unnecessary to send DAUD
avoid unnecessary traffic?  Why does one want to send DAUD when the SG has
sent a SCON/DRST/DUNA?  All that the SG is going to report is the same state
it just indicated?  I appears completely pointless to me.  Please explain.

> ASP receives an SCON/DRST/DUNA again, isn't it ?

Please clarify how a periodic audit would be necessary for SCON/DUNA?  If the
ASP goes to send a message it will get a responsive SCON/DUNA: who needs an
audit in this case?  Please explain.

> I just wanted to paint different views of when and how to use DAUD.

I don't understand the view you are attempting to present.  It is certainly
of no use for the ASP to use the DAUD to audit in this fashion.  The  MTP-User
performs similar audits in ITUT interactions with MTP, but they are always
performed by attempting to send a message to the affected destination, not
by an audit procedure.

The only reason I can see for an ASP sending DAUD is because it really
questions it's knowledge of the state of a destination and in low traffic
periods would not otherwise be able to obtain that information.

> > - either assume everything is available (= no congestion/restriction);
> > it'll get SCONs or DRSTs upon sending DATA messages along the way, which
> > will trigger DAUD etc.
> > 
> > that upon sending DATA (ignorant of any state) or DAUD you may receive
> > both congestion and restriction information. Only if both conditions are
> > absent, you (may) receive an explicit DAVA. The wait for DAVA after SCON
> > makes no sense and makes handling of DAVA dependent on local timer
> > settings. I think the mail discussions here reached an unsatisfactory
> > conclusion.
> 
> [GV]: Also, SCON or DRST are "proof of life", i.e. availability is implied.

I put it to you that the MTP-PAUSE/RESUME and MTP-STATUS primitives are two
different and independent primitive.  MTP-STATUS(congestion) does not indicate
availability.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Fri, 17 Aug 2001 11:52:42 -0700

Hi Brain,

This discussion is getting little confusing for me.
I would like to discuss all the issues one by one.
Let us start with Congestion Abatement.

After all this  discussion I don't understand how
SGP is going to declare congestion abatement as 
according to the model, SCON followed by DAVA, ASP 
can't USE DAVA message to assume congestion abatement .
We also don't have provision of "mendatory"
SCON message with congestion level 0 in draft. 

I want to know how a PC state at ASP is going to come 
out of congestion.

In my opinion "congestion" should be kept independent of DAVA
and DRST message like its there in MTP3, where separate TFC procedure 
is used for congestion management and on similar line we 
should have SCON with congestion level = 0 to inform ASP of
congestion abatement.

I think it will make ASP life much easier.

Please let me know if you see any problem with that and then we can
move with other issues. 

Thanks,
Rajiv

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 17, 2001 9:19 AM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Verwimp,

17:48:22)
[snip]

> ASP receives an SCON/DRST/DUNA again, isn't it ?

Please clarify how a periodic audit would be necessary for SCON/DUNA?  If
the
ASP goes to send a message it will get a responsive SCON/DUNA: who needs an
audit in this case?  Please explain.

I don't understand the view you are attempting to present.  It is certainly
of no use for the ASP to use the DAUD to audit in this fashion.  The
MTP-User
performs similar audits in ITUT interactions with MTP, but they are always
performed by attempting to send a message to the affected destination, not
by an audit procedure.

I put it to you that the MTP-PAUSE/RESUME and MTP-STATUS primitives are two
different and independent primitive.  MTP-STATUS(congestion) does not
indicate
availability.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 14:41:20 -0500

Rajiv,

I agree with you.  I see no problem with having SCON with
congestion level 0.  In my mind this fits aptly with an
MTP-STATUS indication indicating "no congestion".  MTP
does not indicate congestion abatement to its users with
MTP-RESUME primitive.  But I don't believe that SCON 0
should be mandated.  Some MTP-User interface definitions
may require the user to retest the congestion status
periodically because of lack of route-set congestion test
procedures in specific MTP variants.  ASs supporting
these users should never receive SCON 0 (because there
is no procedure in the SG MTP to generate it).  Therefore
I agree that SCON 0 should be permitted (an maybe required
per local SS7 variant) but it cannot be made mandatory
in all cases.

In these variants it is also not possible for MTP at the
SG to know the current congestion status of the destination
(really, route to the destination), as it has no routeset
congestion text procedures to update the congestion status.
Therefore, in these cases it might be necessary to move the
responsibility for congestion status to the MTP-User from
the SG.  In which case, the SG would never response to a
DAUD with a SCON.

As a result I don't think any chage is required to the 
working of the text I proposed regarding DAUD.  The SCON
response is really optional (if the SG has no concept of
congestion state, it simply can never report SCON in
response to DAUD, it provides SCON in a responsive only
fashion and never generates SCON 0).

In SG's supporting MTP variants which have congestion
states, SCON 0 needs to be reported when the congestion
state is "not congested".  DAVA will never suffice.
Receipt of a DUNA should clear the congestion state to
"not congested" per applicable SS7 specifications, however,
this is not a matter for the ASP to worry about: DUNA is
simply reported as MTP-PAUSE to the AS (MTP-User).

I can still see no case whatsoever where DAUD is required
without state-loss at the ASP.  Frankly, the ASP should not
maintain this state anyway: it should be the AS (MTP-User)
which maintains state if it is concerned to do so.  When
an MTP-User restarts (not MTP-Restart), the ASP may wish
to audit the state of concerned desintiations on behalf
of the MTP-User and report the results with MTP-PAUSE/RESUME
and MTP-STATUS primitives, but the ASP itself should never
retain such state (that state should, if ever, be associated
with the AS and may even be above the MTP-User boundary).

So, as you can see, it is not a minor matter and the current
specification permits the necessary approaches as described.
The response to the DAUD should be separate for congestion
and acessibility and should be atomic.  The only reason for
an ASP to perform a DAUD is to inquire as to the state of
a desintation which it was not available to an MTP-User (because
the AS has rebooted) and need not maintain this state itself.

--brian

Duhoon, Rajiv wrote:                                      (Fri, 17 Aug 2001 11:52:42)
> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Fri, 17 Aug 2001 14:41:35 -0700

Brian,

Please see my comments below.....

Rajiv,

[Rajiv] If we know that an SG can not send SCON message
then at ASP we may not need SCON message in response of a DAUD
message. For other cases where SCON message is being generated
by SGP then this SGP must send an SCON message with 0 congestion
level.

I would like to know about MTP variants you are talking about.
Are you talking about TTC ?

--brian

Duhoon, Rajiv wrote:                                      (Fri, 17 Aug 2001
11:52:42)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 17:04:52 -0500

Rajiv,

Duhoon, Rajiv wrote:                                      (Fri, 17 Aug 2001 14:41:35)

[snip]
> by SGP then this SGP must send an SCON message with 0 congestion

I think we are in total agreeement on this point.  But, what text
change would be required?  I don't see where a text change is
required...

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Fri, 17 Aug 2001 16:52:58 -0700

Hi Brian,

As per our assumption that DAVA has no relation with congestion.
an SCON with congestion level 0 may be generated along with 
DAVA even when there is no congestion at SGP.

The following text in draft may require a change.

" If the destination is available and congested the SGP
responds with an SCON message in addition to the DAVA
message. If the destination is restricted and congested,
the SGP responds with an SCON message in addition to the
DRST " 

But from the statement above it seems that SCON message will be
generated only if PC state at SGP is congested. Which create
the confusion that reception of DAVA message alone is sufficient
to indicate congestion abatement as well. Which is not true as we 
still may need SCON message with congestion level 0.

So do you see any change now ?

Thanks,
Rajiv

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 17, 2001 3:05 PM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Rajiv,

14:41:35)

[snip]

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 19:46:45 -0500

Rajiv,

Not really.  If the ASP receives only DAVA in response to DAUD it can
take this to mean that the destination is not congested but available.
If the ASP receives only DRST in response to DAUD it can take this to
mean that the destination is not congested but restricted.

Per my previous proposal, I think that the the SG MAY send SCON 0 ahead
of DAVA or DRST in response to DAUD, but it is not necessary.  It is
only necessary that the SG send SCON(!0) immediately followed by DAVA or
DRST in response to DAUD when the destination is congested.

I think that the text already provides for this situation, it just
wasn't terribly clear on the precise order of the SCON and DAVA/DRST in
response to DAUD as Greg mentioned.  There was already clear concensus
on the ordering, the text just isn't too clear on the matter.  I think
that Greg's suggestion to include the brief wording regarding order of
SCON and DAVA/DAUD in response to DAUD is sufficient, and perhaps the
MAY send SCON(0) in response to DAUD could be included: it is a little
matter indeed for the SG to suppress sending SCON in response to DAUD
when there is no congestion.  Where the MTP does not have congestion
states, the SG will not send SCON in response to DAUD anyway.

And yes, receipt of DAVA in response to DAUD *is* sufficient to indicate
that there is either no congestion or that the SG MTP does not support
the notion of congestion states.  In an ASP where the SG MTP does not
support congestion states, the ASP's reaction to SCON(0) might be to
simply echo it to a MTP-STATUS (no congestion) message which would be
wrong for an MTP-User without congestion states.  The MTP-User without
congestion states should never receive MTP-STATUS(no congestion), so the
ASP would need to discard the SCON(0).

I think with the clarification of order of SCON-DAVA and SCON-DUNA with
the existing text is appropriate and properly meets all situations.
This was the resolution from previous discussion on the matter and I
don't see any new arguments or lines of discussion that would change
that.

Given the text that you quote, the only change I would make is to change
"in addition to" to "immediately followed by" and "SGP responds" to "SGP
MUST respond" as follows:

   "If the destination is available and congested the SGP
    MUST respond with an SCON message immediately followed by
    a DAVA message.  If the destination is restricted and
    congested, the SGP MUST respond with a SCON message
    immediately followed by a DRST message."

The reason for the "immediately followed" is clear from this discussion,
and the "MUST" is to ensure interoperability where the ASP relies on the
SGP behavior in this regard.  Any timer that an ASP implementation runs
waiting for a response to a DAUD message would only be cancelled after
receiving DUNA, DAVA or DRST and the SCON would only be stored as an
intermediate result to be discarded on timer expiry and the DAUD
reattempted.

I don't see how the draft can be any more clear on this matter without
starting to fully specify the implementation state machine which is not
really necessary for this minor behavior.

--brian

Duhoon, Rajiv wrote:                                      (Fri, 17 Aug 2001 16:52:58)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Joe Keller <[email-masked]>
Date: Mon, 20 Aug 2001 11:25:41 -0400

Brian,

>fashion and never generates SCON 0).

How does this relate to your text suggestion from 8/17
of:

Would the following be better:

   "The SGP MUST respond to a DAUD message with the MTP3
    availability/congested status of the routeset associated
    with each Destination Point Code(s) in the DAUD message.
    The status of each SS7 destination requested is indicated
    in a DUNA message (if unavailable), a DAVA message (if
    available), or a DRST (if restricted and the SGP supports
    this feature).  If the SS7 destination is congested and
    the SGP maintains congestion status, the SGP responds
    with an SCON message.  When a SCON is sent in response
    to a DAUD, the SCON should be followed by the appropriate
    DAVA/DRST message.  If the SGP has no information on the
    availability status of the SS7 destination, the SGP
    responds with a DUNA message, as it has no routing
    information to allow it to route traffic to this
    destination."

11:52:42)
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:55:04 -0500

Joe,

Joe Keller wrote:                                             (Mon, 20 Aug 2001 11:25:41)
[snip]
>    "If the destination is available and congested the SGP MUST
>    respond with an SCON message immediately followed by a DAVA
>    message.  If the destination is restricted and congested, the
>    SGP MUST respond with a SCON message immediately followed by a
>    DRST message."
> 
>    availability/congested status of the routeset associated with
>    each Destination Point Code(s) in the DAUD message.  The status
>    of each SS7 destination requested is indicated in a DUNA
>    message (if unavailable), a DAVA message (if available), or a
>    DRST (if restricted and the SGP supports this feature).  If the
>    SS7 destination is congested and the SGP maintains congestion
>    status, the SGP responds with an SCON message.  When a SCON is
>    sent in response to a DAUD, the SCON should be followed by the
>    appropriate DAVA/DRST message.  If the SGP has no information
>    on the availability status of the SS7 destination, the SGP
>    responds with a DUNA message, as it has no routing information
>    to allow it to route traffic to this destination."

You clearly get the intent, but a question about your proposed
text:

If an SGP does not maintain congestion states, how can it view
the destination as congested?  You text appears to imply that
a destination can be congested in the SGP's view, yet still have
no concept of congestion states.

It is this line that give me a problem:

>    "... If the SS7 destination is congested and the SGP maintains
>    congestion status, ..."

If the SGP has no concept of congestion states (not just that it
doesn't maintain congestion status), then it is impossible for the
SS7 destination to be congested in its view.  Therefore, it is
sufficient to say "and congested" as follows:

>    "If the destination is available and congested the SGP MUST
>    respond with an SCON message immediately followed by a DAVA
>    message.  If the destination is restricted and congested, the
>    SGP MUST respond with a SCON message immediately followed by a
>    DRST message."

The SGP which has no concept of congestion states simply never
views the destination as congested.  There is no need to complicate
the text and make it less clear.

My $0.02

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Joe Keller <[email-masked]>
Date: Mon, 20 Aug 2001 13:51:01 -0400

Brian,

>no concept of congestion states.

[Joe] An SGP can receive a TFC and notify an ASP via a SCON.  The
      SGP doesn't need to maintain that state and attempt to
      abate the congestion.  So an SGP can view a destination as
      congested yet not maintain its state.

>the text and make it less clear.

[Joe] I disagree (obviously) that the text is being more complicated.
      Actually, my intent was to make the text clearer.  Your version
      provides no text in the event the SGP doesn't maintain state as
      referenced in your 8/17 posting.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 13:12:22 -0500

Joe,

Joe Keller wrote:                                             (Mon, 20 Aug 2001 13:51:01)
>       congested yet not maintain its state.

Not with respect to an audit.  In response to DAUD, the SGP which
either doesn't maintain congestion state or does not have a concept
of congestion state cannot have the destination "congested" when it
goes to reply to the DAUD.

>       referenced in your 8/17 posting.

If it doesn't maintains congestion state it cannot consider the
destination as congested when it receives a DAUD.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Joe Keller <[email-masked]>
Date: Mon, 20 Aug 2001 14:46:27 -0400

Brian,

   I agree with you and I think only issue is the wording.  My "issue"
with your text is that there is no mention in the audit procedures
(which is the text in question) of the case in which an SGP doesn't
maintain congestion status.  That is why I added the sentence:

   "If the SS7 destination is congested and the SGP maintains
    congestion status, the SGP responds with an SCON message."

I read the text more as the "SS7 destination being congested" versus
your reading as the "the SGP's view of the SS7 destination being
congested".  The one other change I made to the v08 text was that I
removed "/congestion" from the following sentence.

   "If the SGP has no information on the availability/congestion
    status of the SS7 destination, the SGP responds with a DUNA
    message, as it has no routing information to allow it to route
    traffic to this destination."

Joe

-- Original message

Joe,

Joe Keller wrote:                                             (Mon, 20 Aug 2001
13:51:01)
>
> Brian,
>
> >Joe,
> >
> >Joe Keller wrote:                                             (Mon, 20 Aug
2001
> 11:25:41)

--brian

---

---

From: Kurt Kite <[email-masked]>
Date: Mon, 20 Aug 2001 13:59:13 -0500

Hi,

Brian and Joe have highlighted an issue that I have been meaning to
raise with the mailing list. The issue is when the SG (acting as an STP)
receives a TFC for which it is not the endpoint (i.e., it is not the node
which originated the message which resulted in the TFC). In this case,
I believe the correct behavior is for the SG to simply forward the TFC,
via an SCON, to the appropriate ASP(s). Upon receiving the SCON,
the ASP is free to audit the SG to check the status of the destination.
In this case, the SG does not maintain the congestion status, so it will
return a DAVA. It does not seem like the audit procedures are sufficient
in the case where the SG is acting like an STP. It seems like what is really
needed here is a way for an ASP to perform a RCT. Or is it simply acceptable
to clear the congestion status in the above case?

/Kurt

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Joe Keller <[email-masked]>
Date: Mon, 20 Aug 2001 15:08:26 -0400

Kurt,

   I agree with you.  One possible solution would be to add a congestion
audit message and let the DAUD act only as an availability audit.

Thoughts?

Joe

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 14:11:28 -0500

Joe,

I really don't care about the wording as long as the
intention is captured (I just like arguing ;)  I think
Greg knows what the intention is as well and can probably
decide what text to include.  He has both our versions
to go from.

I don't think that Greg was looking for text here, anyway.

The issue is just editorial.  I'll leave it in Greg's
capable hands.

--brian

Joe Keller wrote:                              (Mon, 20 Aug 2001 14:46:27)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 14:14:53 -0500

Kurt,

Unfortunately the ASP needs a whole bunch more MTP behavior for this
SG acting as STP case.  RCT is just the tip of the iceburg.  What about
CBD/CBA procedures where the changeback is between STPs and the CBD
is addressed with the DPC of the ASP?  It goes on.  Your observation is
another SG as STP issue which needs to be addressed.  Overloading DAUD
could get complicated...

--brian

Kurt Kite wrote:                                             (Mon, 20 Aug 2001 13:59:13)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Mon, 20 Aug 2001 12:32:58 -0700

Brian,

See my comments below ........

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 17, 2001 5:47 PM
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Rajiv,

[Rajiv] How are we going to define "immediately" ? For that matter we need
to define another timer. We also need to define that what would be the
action
taken if we don't receive any "immediate message (DAVA, DRST)" for any
expected reason. ASP can't keep on waiting indefinitely for this message. 

In my opinion we should try to make things as simple as possible and my
suggestion
is that we should have only one message in response of a DAUD message and
add
an new congestion parameter in the DAVA,DRST messages itself. If an SGP
doesn't
support congestion procedures then it can just keep it always 0 and if an
ASP
doesn't support this parameter then it can simply ignore it.

That way SCON message may only be used for unsolicited update of congestion
status by any of the end points.

-- Rajiv

--brian

16:52:58)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 15:15:02 -0500

Rajiv,

Duhoon, Rajiv wrote:                                      (Mon, 20 Aug 2001 12:32:58)
[snip]
> action taken if we don't receive any "immediate message (DAVA, DRST)" for
> any expected reason. ASP can't keep on waiting indefinitely for this
> message. 

Immediately can easily be defined as before sending another
DAVA/DUNA/SCON/DRST for the same affected destination.

Another timer is not required.  Whatever timer the ASP chooses to
use when waiting for DAUD replies will suffice, regardless of the
SCON before DAVA/DRST behavior.

> suggestion is that we should have only one message in response of a DAUD
> message and add an new congestion parameter in the DAVA,DRST messages
> itself. If an SGP doesn't support congestion procedures then it can just
> keep it always 0 and if an ASP doesn't support this parameter then it can
> simply ignore it.
> 

IMHO that would be pointless and too complex (two ways to signal the
same thing), it would also require changes to SUA DAUD for
compatibility.  The current behavior is sufficient.  I see no reason
to change it.  It is a little late in the cycle of the draft to be
making unnecessary changes.  Text clarification is one thing (and
all that is required), changed procedures and additional parameters
where no changes or parameters are needed is another.

Plus the current approach is consistent with the MTP-User primitive
interface, coupling the two would not, requiring the ASP to possibly
generate two primitives to the AS from one message.  As it stands
only one primitive per message is required.  The current case is
actually simpler.

As you have no compelling argument for a change, I propose that we
go with what we have from previous concensus on this topic and allow
Greg to place some text clarifications in the draft in support of that
concensus as stated.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 21 Aug 2001 10:00:40 +0200

Brian,

A few short answers, I think our views are not too far apart ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 18:19
To: sigtran
Subject: Re: M3UA 08 - ASP Auditing

Verwimp,

=>
[GV2] : We're getting a bit confused here. Let's just list some cases where
sending of DAUD would be useful :

- when AS has lost/doesn't have state (e.g. reboot, activation of new SCTP
association)
- on behalf of the MTP-users
- periodic after receiving SCON/DRST/DUNA from SG. This might not be needed,
as the SG would send these messages anyway when the SS7 congestion/etc.
disappears.

However, how does the SG signal end-of-congestion or end-of-restriction ? Is
the current scheme ok then ?

1) SCON - DRST - DAVA : congested + restricted + available

2) DRST - DAVA : uncongested + restricted + available

3) SCON - DAVA : congested + unrestricted + available

4) DAVA : uncongested + unrestricted + available

5) DUNA : unavailable

The AS would thus have to remember which primitives it received (SCON, DRST)
between 2 DAVA's or between DUNA and DAVA, or after sending DAUD ?
<=

=>
[GV2] : I didn't say an audit was needed/required. Whether it's a good thing
or not is another question, and an implementation decision.
<=

=>
[GV2] : Agreed.
<=

=>
[GV2] : Hence my question above : is the current scheme ok then ?
<=

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 04:10:59 -0500

Gery,

Verwimp Gery wrote:                                       (Tue, 21 Aug 2001 10:00:40)
[snip]
> [GV2]: We're getting a bit confused here. Let's just list some cases where

This one confuses me: there is no primitive in the MTP-User interface to
query the state of any desintation.  If the MTP-User wants to test the
status of a destination, it sends a message to it using the MTP-TRANSFER
primitive.  What would the MTP-user use to request a DAUD?

>   as the SG would send these messages anyway when the SS7 congestion/etc.

Congestion is not always performed by state, it can be performed responsive
only on a stateless basis.  The SG always informs the ASP of changes in
desintation status of which it is made aware and normally performs routeset
tests to assure that the status reported to users is current.  What would be
the purpose of periodic DAUDs?

> 4) DAVA : uncongested + unrestricted + available

Remove the DAVA from (1) and (2).  As a destination cannot be
unavailable and restricted, DRST also indicates available.
The responses to DAUD are like so:

 1) SCON - DRST : congested + restricted
 
 2) DRST : uncongested + restricted
 
 3) SCON - DAVA : congested + available
 
 4) DAVA : uncongested + available
 
 5) DUNA : unavailable

[snip]
> 
> =>
> [GV2]: I didn't say an audit was needed/required. Whether it's a good thing

Implementation decision or not, I still can't see any reason why one
would want to do so.  Nevertheless, current procedures allow the ASP
to send a DAUD whenever it pleases.

[snip]
> indicate availability.
> [GV2]: Hence my question above : is the current scheme ok then ?
> <=

The current scheme is the draft is fine.  Perhaps with some clarification on
the order of SCON wrt DAVA/DRST in response to DAUD.  (Note the corrections
above.)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---