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

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

Brian ,
   I agree with you that in SS7 SEP congestion status is only maintained
per routeset basis and not per route basis, beacause due to RCT procedure
there is no need of maintaining congestion status  on per route basis.Now
putting ASP as SEP you have no RCT procedure defined, but as you say SG's
connected with ASP perform  RCT on the behalf of ASP.Assuming affected
point code x-y-z is reachable through two SG's SG1 and SG2.Now ASP receives
SCON(1) from SG1 and update the point code (X-Y-Z) congestion status  to 1
and MTP3 users are informed with MTP-STATUS with congestion status 1.Now
ASP has to start DAUD procedure for affected point code x-y-z per SG and
ASP will continue to send DAUD messages with affected point code X-Y-Z to
SG1 untill ASP is sure that point code(x-y-z) congestion status  is 0
(no-congestion) through SG1.Mean- while SG1 might be doing RCT procedure on
the behalf of ASP for affected point code X-Y-Z.There are actually two
options for ASP to stop sending DAUD messages to SG1  with affected point
code x-y-z. Either ASP maintains congestion status per SG route or mark the
SG1 route for affected point code x-y-z congested by using some flag so
that ASP can know when to stop DAUD procedure for affected point code per
SG.Roueset (x-y-z) congestion status is just there to indicate MTP-STATUS
primitives.ASP will AUDIT affected point code per SG till congestion
abates, for that ASP has to know when to start and stop sending DAUD
messages for affected congested point code to a given SG which in a way
implies ASP has to maintain either congestion status or flag (indicationg
occurance and abatement of congestion).Now for abatement of affected point
code congestion status there are two approaches either SCON(0) received
from SG for affected point code or timer supervision because once you have
indicated congestion status greater than 0 to MTP3 user you have to
indicate congestion abatement with congestion status 0 to MTP3 user this
statement is only true if the network appearance associated with affected
point code is of national option with congestion priority.I have taken two
SG's in my above example to explain that affected point code  X-Y-Z
congestion status can get updated to 3 on receiving SCON(3) from SG2.Now
you have to send DAUD messages to both SG1 and SG2 till abatement of
congestion occures. Please comment

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 07/17/2003
06:46:00 AM

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,

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

--
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: Fri, 18 Jul 2003 01:40:22 -0600

kakaul,

I don't think the ASP needs to do all that.  Instead of DAUD, it can simply
lower the congestion status of the routeset after a time interval and indicate
abatement to the National MTP-User.  The next message sent by the MTP-User
will illicit SCON if the abatement was premature (without sending any message
on the SS7 network) and the timer can be reset.  Only one timer per routeset
is necessary.

In the multiple SG scenario SCON is comparable to TFC, not MTP-STATUS.
SCON(0) is not necessary in the multiple SG scenario, the ASP can abate
after a time interval and rely on responsive SCON from the SG.  If no
SCON is delivered, then abatement to no congestion sticks.

Also, understand that the Nation MTP (e.g. ANSI) does not indicate abatement
in all situations: only when the congestion is remote.  When the congestion
is a result of congestion of a signalling link, abatement is not indicated.
(e.g. see ANSI T1.111.4/2000 SDLs).

--brian

[email-masked] wrote:                                                           (Fri, 18 Jul 2003 10:15:37)

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