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

From: [email-masked]
Date: Fri, 25 Jul 2003 10:39:47 +0530

Brian,
             You have not replied to my earlier mail

Kamesh Kaul/HSS@[email-masked] on 07/18/2003 08:38:57 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]

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

Brian,
   I agree with running congestion timer per affected route-set(point code)
basis as you have mentioned. But now the point is that in SS7, SEP runs the
RCT congestion supervisory timers after sending RCT message with current
congestion status of the affected route-set so that if the TFC for that
message is not received congestion abatement procedure will be supervised
by timers.So it means that in SS7, SEP RCT message checks the clearance of
path (for congestion) to affected point code and then monitors the
congestion abatement by timers.But in ASP there is no RCT message so we in
a way have to depend on DAUD message per SG to simulate RCT message and
monitor congestion by one timer per affected point code .But for that we
need to know to which SG DAUD message should be sent. SS7, SEP need not
bother about sending RCT per route because it sends RCT message as if it
has got dummy message from user part for affected point code with current
routeset congestion set in priority.For ASP to figure out to which SG DAUD
has to be send either congestion status or flag(signifying occurance or
abatement) has to be maintained per SG.Please comment.

Do you agree with not striking of timer mention in IG.

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 07/18/2003
01:10:22 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,

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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 25 Jul 2003 03:47:49 -0600

kakaul,

I originally asked to either strike mention in the IG or describe the
timer.  Javier's (1) or (2).  Mentioning a timer that has no description
is of little use.

--brian

[email-masked] wrote:                                                           (Fri, 25 Jul 2003 10:39:47)

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