Subject: Re: [Sigtran] M3UA IG v04 Section 3.18

From: [email-masked]
Date: Tue, 15 Jul 2003 18:59:37 +0530

Brian
   some comments inline

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 07/15/2003
12:16:38 PM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    Kamesh Kaul/HSS@HSS
cc:    [email-masked]

Subject:    Re: [Sigtran] M3UA IG v04 Section 3.18

kakaul,

If there is no interoperablity issue then it is implementation dependent.
A description of a procedure for the timer could be added as an
IMPLEMENTATION
NOTE making a suggestion to the implementor of one way to address local
issues
at the ASP, but it cannot be required.

But looking at your description, this mechanism would be a duplication of
the
mechanism used by SCCP, ISUP, BICC, which use a dual-timer approach to
detecting congestion abatement.  Why would it be necessary for the ASP to
do
this as well?
>> It is also done in MTP3 for nation options with priority do you mean to
say that RCT mechanism is not required in MTP3.

Also, you should not that SCON received from one SG is no different than
SCON
received from another.  The SCON represents a statistical sampling of
congestion in the SS7 network between the ASP and the destination, and is
not
referenced to an SG.  Therefore, the ASP should never perform this
procedure
on a per-SG basis.  The SCON received from either SG will generate an
MTP-STATUS primitive to the AS, and the AS will run suitable timers at the
MTP-User (where the responsibility lies to avoid sending messages of a
priority less that the congestion state).
>> In national option with priority MTP3 user is given MTP-STATUS
indication only if point code (routeset )congestion status
changes.Similarly at ASP MTP-STATUS indication shall be given to the user
part only if derived status of affected point code changes as shown in
figure below :

                              SCON (1)+--+----++
                             <------- |        |
                          +-----------+  SG1   +-----+
                          |           |        |     |
                          |           +--------+     |      SS7 NODE
           +--+----++     |                          |    +----------+
           |        |     |                          |    |   PC     |
           |  ASP   +-----+                          +----+  X-Y-Z   |
           |        |     |                          |    |          |
           +--------+     |                          |    +----------+
                          |          +--+----++      |
             AS:A-B-C     |          |        |      |
                          +----------+  SG2   +------+
                            <------- |        |
                             SCON(3) +--------+

MTP-User will be given only MTP-STATUS indication with congestion status 3
if SCON(3) reaches before SCON(1).So for this you have to maintain
congestion status of affected point code through each SG and ultimately
given the Derived congestion status to MTP-User.

Understand that SCON is not an M3UA congestion indication: it is an SS7
network congestion indication that is directed at the MTP-User.  The ASP
need
only translate SCON messages to MTP-STATUS primitives to the AS to which
they
correspond.  A AS that conforms to MTP-User standards specifications with
deal
with the MTP-STATUS primitives appropriately.
>>It is only true in international and national networks without priority
option.

It is also important to understand that the ASP should not change the
routing
of messages on the basis of a received SCON message.  Where applicable and
for
applicable SS7 standards specifications, the SG will send DRST under very
specific and standardized congestion situations.  The ASP is already
expected
to perform some functions of MTP routing in response to DRST.
>> Here i definitely agree with you that rerouting of messages should not
be done at ASP to avoid missequencing.

So, now I don't understand why you expect the ASP to run this timer at all.
>> Some implementations may want to provision congestion of affected point
code through supervisory congestion timer, they should be allowed to do so.

Please explain.

--brian

[email-masked] wrote:
(Tue, 15 Jul 2003 10:46:03)
>
>
>
>
> Brian,
>    There is no interoperability issue involved in it and also i dont see
> any need of peer knowing the existence of this timer.It is local to ASP
and
> is used by ASP to supervise the congestion status of the affected point
> code reachable through a given SG.ASP after receiving an SCON message
with
> congestion status greater than 0 can start this timer and if no SCON
> message is received from peer till the expiry of congestion timer ASP can
> decrement affected point code  congestion status by 1 and start the timer
> provisioning of congestion again if congestion status of affected point
> code has not reached 0 or no congestion.
>
> Regards
> Kamesh Kaul
> www.hssworld.com
> Hughes Software Systems
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 07/15/2003
> 10:28:40 AM
>
> Please respond to [email-masked]
>
> Sent by:    [email-masked]
>
>
> To:    Kamesh Kaul/HSS@HSS
> cc:    "J.Javier Pastor (EE/EEM)" <[email-masked]>,
>        [email-masked]
>
> Subject:    Re: [Sigtran] M3UA IG v04 Section 3.18
>
>
> kakaul,
>
> Then add text describing how to use the timer in an interoperable way.
> Also, please describe why the peer needs to know about the existence
> of this timer to remain interoperable.  Otherwise, there would not be
> any need to describe it.
>
> --brian
>
>
> [email-masked] wrote:
> (Tue, 15 Jul 2003 09:35:27)
> >
> >
> >
> >
> > Hi Javier,
> >                     This timer may be used by some implementations to
> > supervise the congestion status of point code if SCON messages send by
> SGP
> > are lost in transit to ASP.It was discussed earlier and was agreed upon
> by
> > all to keep this timer.I disagree with removing the mention of the
timer.
> >
> > Regards
> > Kamesh Kaul
> > www.hssworld.com
> > Hughes Software Systems
> >
> >
> >
> >
> > "J.Javier Pastor (EE/EEM)" <[email-masked]>@ietf.org on
> > 07/14/2003 04:05:58 PM
> >
> > Sent by:    [email-masked]
> >
> >
> > To:    "'Brian F. G. Bidulock '" <[email-masked]>
> > cc:    "[email-masked]' '" <[email-masked]>
> >
> > Subject:    RE: [Sigtran] M3UA IG v04 Section 3.18
> >
> >
> > Brian,
> >
> > We'll remove the mention of the timer, if nobody disagrees...
> >
> > Cheers // Javier.
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock
> > To: J.Javier Pastor (EE/EEM)
> > Cc: [email-masked]'
> > Sent: 11/07/2003 11:07
> > Subject: Re: [Sigtran] M3UA IG v04 Section 3.18
> >
> > J.Javier,
> >
> > J.Javier Pastor (EE/EEM) wrote:
> > (Fri, 11 Jul 2003 09:56:59)
> > > Hi Brian,
> > >
> > > Pls, see below...
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: jueves, 10 de julio de 2003 15:34
> > > > To: J.Javier Pastor (EE/EEM)
> > > > Cc: [email-masked]'
> > > > Subject: Re: [Sigtran] M3UA IG v04 Section 3.18
> > > >
> > > >
> > > > Javier,
> > > >
> > > > 3.18.3 Solution Description
> > > >
> > > >    Clarify that the ASP needs to indicate when the congestion
> > > > level has
> > > >    changed (including abatement).  Further, the ASP peer can
> > maintain
> > > >    a timer, if desired, in case the ASP fails to indicate
congestion
> > > >    abatement.
> > > >
> > > > Where are the procedures for this timer described?  This is the
only
> > place
> > > > that the timer is mentioned.  Please describe the timer or remove
> > the
> > > > sentence saying that it has been described...
> > > >
> > >
> > > Do you think is worth include the timer explanation into the new
text?
> > > Otherwise, we may remove that sentence.
> >
> > Please remove mention of the timer.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> >  https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
>  https://www1.ietf.org/mailman/listinfo/sigtran
>

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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 01:11:40 -0600

kakaul,

An SS7 SEP at the position of the ASP, where the SGs are STPs would
not maintain congestion state on a per-route (per-SG) basis.  So
what makes you think that the ASP needs to?

Also, SCON() in this configuration corresponds to TFC (not MTP-STATUS)
and therefore cannot signal abatement.  (TFC does not signal abatement,
the lack of a TFC does.)  In the same ways, the ASP can use the lack
of a SCON to indicate abatement.

So, a) SCON(1) and SCON(3) in your example are congestion signals
(neither is an abatement signal); b) there is no need to maintain congestion
status on a per-SG basis at the ASP ('cause the SS7 SEP doesn't).

This might lead back to the discustion why ASPs don't send RCT, but the
simple answer is that each SG as STP can send RCT on all the ASP's behalf
as it would for an "Alias" point code (ANSI T1.111/2000).

Because this is getting into a narrower and narrower corner of the
specification, I think we are safe to strike the mention of the timer
from the IG.

--brian

[email-masked] wrote:                                                           (Tue, 15 Jul 2003 18:59:37)

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