Subject: RE: [Sigtran] Another Congestion/SCON Question

From: "Richard Adams" <[email-masked]>
Date: Thu, 5 Dec 2002 14:25:03 +0100

Brian,
just a niggle (sorry about that!). I've snipped a lot out.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 05 December 2002 12:32
To: Richard Adams
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] Another Congestion/SCON Question

Richard,

Pease see comments below.

{snip}

> And level can be 0.	

>> 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.
{RAA} Text above agreed. {RAA}
This excludes 0. 
{RAA} No, just that the user takes no action to STOP traffic with a
report of 0 congestion. 
 What it does is START traffic (i.e. restart all that had previously
been stopped {RAA}
 
Also, Figure 34/T1.111.4 says "Stop signalling traffic to
conerned destination with message priority less than congestion status.
L3->L4" L4 cannot possibly stop traffic with message priority less than
0,
so no indication need be given.
{RAA} I agree it cannot possibly stop any traffic, but it can start all
previously stopped traffic !  Here it seems (I don't have T1.111.4 with
me) that that should state that it's up to the user to restart traffic
of its own accord, if it wants the MTP NOT to tell the user when to
restart traffic. {RAA}

What the text does NOT say is:

  Each user then takes action to restart traffic with congestion
  priorities equal to or greater than the specified congestion
  status.
{RAA} I agree that that text should be present. I have no control over
T1 text, and never did, I possibly could previously have changed the
ITU-T text (if any contribution were received from an ITU member using
the  congestion priorities national option), but I think that the ITU
text is frozen. 
How user traffic is restarted would be a nodal implementation dependent
matter if user and MTP were co-located, as in SS7, so perhaps for ITU it
doesn't matter. But where the user is remote, I think needs to be
sorted-out! {RAA} 
 
> My conclusion is that M3UA could send SCON(0), but it must be
optional. 
> Incidentally, in Q.701 there isn't an MTP-STATUS indication for
> "restricted"!

DRST is only used in the dual SG as STP case where the ASP must perform
the HMRT function.  This is not pure backhaul.  In the pure backhaul
scenario, (and for MTP users), a restricted MTP-STATUS is never required
(because the MTP user does not do MTP routing).
{RAA} Thanks, that clears up a worry I had! {RAA}

At least we agree that SCON(0) delivered by the SG must be completely
optional. 
{RAA} Yes. Thanks. {RAA}

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 06:42:01 -0700

Richard,

Richard Adams wrote:                            (Thu, 05 Dec 2002 14:25:03)

> the  congestion priorities national option), but I think that the ITU

The ITU-T and ANSI text are identical in this passage.

> doesn't matter. But where the user is remote, I think needs to be

Its clear from Q.714 how traffic is to be restarted.  It is also
clear that Q.764 ignores congestion indications in MTP-STATUS
(particularly because ISUP normally throttles with ACL).  T1.113
also ignores congestion in MTP-STATUS.  T1.112 passed it to the
SCCP user in N-PCSTATE (the procedures which are left for further
study in TCAP).

So, Q.714 is the only one that goes about describing it, and, although
it has the optional level in the MTP-STATUS, it ignores congestion
status 0 and all abatements (will discard while the timer is running
and will decrement when it expires).

So it doesn't appear that there is a user that can use a status
indication of 0 even if you were to send it.

Rewriting the rules of the MTP-User is well outside the scope of
M3UA work.

So, let's leave it a SCON(0) being OPTIONAL (which it is in the
RFC anyway).  Any disagreement?

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 5 Dec 2002 18:43:30 -0800 (PST)

Brian,

One comment/question below, although more MTP3/ISUP
related.

   Tolga
--- "Brian F. G. Bidulock" <[email-masked]>
> SCCP user in N-PCSTATE (the procedures which are
[TOLGA] I don't have ANSI-ISUP spec with me, but if it
ignores MTP-STATUS for congestion case, I would
consider this as a not very wise choice. For ANSI
case, MTP3 will discard messages with priority lower
than congestion level, so I would think that it is
crucial that ANSI user parts are informed by MTP3
about the congestion status changes(both for increase
and decrease) and that they act accordingly, i.e.
stop/start traffic.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Dec 2002 09:39:55 -0700

Tolga,

ANSI T1.113.4 section 2.10:

  (No procedure specified for US networks)

--brian

Tolga Asveren wrote:                 (Thu, 05 Dec 2002 18:43:30)