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

From: [email-masked]
Date: Wed, 16 Jul 2003 21:57:11 +0530

Brian,
   Comments inline

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 07/16/2003
12:41:40 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,

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?
[Kamesh]It would because route-set congestion status will change depending
on the derived congestion status of individual routes I am attaching
section 11.2.4 from Q.704

11.2.4 Signalling route set congestion (National option with congestion
       priorities)
In the case when the congestion status of a signalling route set changes as
a result of either the receipt of a transfer controlled message relating to
a particular destination (see 13.7) or an indication of local signalling
link congestion, or due to the signalling route-set-congestion-test
procedure (see 13.9) an indication is given from the Message Transfer Part
to the local level 4 informing it about the current congestion status of
the signalling route set. Each user then takes appropriate actions in order
to stop generation of signalling messages destined for the affected
signalling point with congestion priorities lower than the specified
congestion status. Messages received from the local level 4 with congestion
priorities lower than the current signalling route set congestion status
are discarded by the Message Transfer Part.
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.
[Kamesh]Yes they do and derived congestion status leads to MTP-STATUS

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).
[Kamesh]Yes there is need to maintain congestion status on the per-SG basis
at ASP because SG1 doing RCT procedure on the behalf of ASP may return
SCON(0) when it receives audit for the affected point code and if affected
point code is reachable through SG1 and SG2 as shown in previous figure SG2
returns SCON(2) then congestion status sent in MTP-STATUS is 2 because
affected point code is still congested.

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.
[Kamesh]I dont agree with striking timer
--brian

[email-masked] wrote:
(Tue, 15 Jul 2003 18:59:37)
>
>
>
>
> 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
>

--
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 19:16:00 -0600

kakaul,

You are confusing congestion at an STP due to the conestion of signalling
links on a route with routeset congestion.  Although the congestion of a
signalling link can trigger sending TFC, the route upon which the TFC is
received has nothing to do with congestion.

Put an SEP where the ASP is and tell me where in the SS7 specs it says
that a TFC received from an STP is correlated to the route upon which it
was received.  A: it doesn't.

The passages you quote correspond to transmit congestion on the SCTP
associations between the ASP and the SG.  (SCON is not involved there.)

--brian

[email-masked] wrote:                                                           (Wed, 16 Jul 2003 21:57:11)

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