Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 12 Feb 2002 18:11:08 +0100

Tolga,

In M3UA 1.4.6, it is said That a SG on receipt of a SCON can trig 
a TFC to the ss7 concerned DPC.
This ss7 DPC in national option then trig a RCT procedure (Q704 13.9). 
What must be the behavior of the SG when it receive a RCT... must it 
discard it (this is not compliant with the national option). If the 
SG decide to reply to this RCT by a TFC, it must always be aware of 
the state of congestion of the AS which is not local to the SG.

In the ss7 recommendation, it is possible to specify as implementation 
dependant some behavior internal to a stack, but with M3UA, the AS and 
the SG are separated by an IP network where M3UA is supposed to define 
ALL messages exchanged between the entities.

Again in on my first remark, if the "end of congestion" SCON level 0 
message is lost between the SG and the as, how can the SG request 
"after a long time" if the AS is still congested, In order to answer 
to the received RCT?

Francois.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 6:00 PM
To: Zannin, Francois; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS

Francois,

m3uav12 3.4.4 says:
"The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA
peer indicating that the M3UA layer or the ASP is congested."
In my opinion, M3UA layer congestion corresponds to Signalling
point/signalling transfer point congestion(Q.704 11.2.6) and ASP congestion
corresponds to User Part congestion(Q.704 11.2.8). No specific procedure is
defined for those cases as can be seen in Q.704.
So as pointed out by Brian, no RCT is necessary.

    Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Zannin, Francois
> Sent: Tuesday, February 12, 2002 11:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS
>
>
> Brian,
>
> In the ss7 network, the RCT is used to test a possible route for
> a SP specified in the RCT header message. If the route is not congested,
> the final SP itself (The AS or the SG for the AS) discards the RCT.
>
> Now, if we consider (or not) the SG as a STP, when it receive a RCT for
> a SP played by an AS, this SG must be able to reply by another TFC if
> the AS is still congested (the SG has receive a SCON from this AS).
>
> If the SG is not able to have information about the AS congestion state,
> how can it handle the RCT received from the ss7 network?
>
> My opinion is if a message is used to send the congestion information
> from an AS to a SG, we must have a message to test from the SG if the
> congestion problem still exists on the AS.At least if we need to be
> compliant with the ss7 "national option with priority" congestion mode.
>
> Francois.
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 5:00 PM
> To: Zannin, Francois
> Cc: [email-masked]
> Subject: Re: [Sigtran] M3UA congestion monitoring between a SG and an AS
>
>
> Francois,
>
> The ANSI/ITU specs do not describe RCT in conjunction
> with SP generated TFC, only in conjunction with routeset
> congestion.
>
> --brian
>
> Zannin, Francois wrote:                    (Tue, 12 Feb 2002 16:42:05)
> > Brian,
> >
> > The mechanism of congestion handling can (and is) implementation
> > dependent but when some platform external messages must be exchanged
> > between the nodes, these messages MUST be specified by the protocol.
> > For the ss7 protocol, these messages are the TFC matching the SCON
> > and the RCT that does not have any equivalent for M3UA.
> >
> > When the SG and the Asp are not developed by the same stack M3UA
> > provider, we must be sure have a reference message to exchange in
> > order to give the possibility to the SG to have information about
> > the Asp congestion level. The same kind of stuff allowed by the
> > DAUD message from the Asp to the SGp.
> >
> > Francois.
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, February 12, 2002 4:08 PM
> > To: Zannin, Francois
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] M3UA congestion monitoring between a SG and an AS
> >
> >
> > Francois,
> >
> > This mechanism is implementation dependent even in ANSI/ITU specs
> > and optional.
> >
> > --brian
> >
> >
> > Zannin, Francois wrote:                    (Tue, 12 Feb 2002 10:17:33)
> > > Hi,
> > >
> > > I have an issue about the congestion handling in M3ua between
> the ASp and
> > > the SGp when congestion occurs on the AS(p).
> >
> > > It is said that an ASP can send a SCON to a SGP or another
> IPSP when a local
> > > congestion occurs.
> >
> > > If we use the multi level of congestion between the ASp and
> the SGp, what
> > > message can be used to monitor the level of congestion in the
> ASp from the
> > > SGp or remote IPSp. An ASp can send the DAUD SSMN to a SGp
> but there is no
> > > matching message from the SGp to the ASP.
> >
> > >
> > > If a multi level congestion (National option) is detected in
> an ASp, a SCON
> > > is sent from the Asp to a SGp that sends a TFC to the ss7
> Concerned SP. This
> > > SP trigs the RCT procedure to monitor the state of the
> affected DPC, but
> > > because the SGP cannot send this message to the ASP, it must
> keep locally
> > > the state of congestion of the AS, state that can only be
> updated by the
> > > ASp. If the SCON indicating "No Congestion" is lost between
> the ASp and the
> > > SGP, the AS will stay congested forever in the SG!
> >
> > >
> > > Is there a procedure that can be used from a SGp to monitor
> the state of
> > > congestion of an AS, something equivalent to the DAUD that
> can only be used
> > > from ASp to SGp?
> >
> > >
> > > Francois Zannin.
> > >
> > >
> > > _______________________________________________
> > > 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: Tue, 12 Feb 2002 11:43:07 -0600

Francois,

Zannin, Francois wrote:                    (Tue, 12 Feb 2002 18:11:08)
> a TFC to the ss7 concerned DPC.

Well, it doesn't really say that.  It says:

 The M3UA layer is informed of local and IP network congestion by means 
 of an implementation-dependent function (e.g., an implementation-
 dependent indication from the SCTP of IP network congestion). 
 At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-
 Users by means of an MTP-STATUS primitive, as per current MTP3 
 procedures, to invoke appropriate upper layer responses.  

 The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 
 M3UA peer with an SCON message.  When an SG receives a congestion 
 message (SCON) from an ASP, and the SG determines that an SPMC is now 
 encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled 
 management messages to concerned SS7 destinations according to 
 congestion procedures of the relevant MTP3 standard.

The SG only need send TFC when it determines that the SPMC is
encountering congestion (entire point code).  This is not the
AS.  This is the group of ASPs which an SG is represents as a
unique signalling point to the SS7 network for the purposes of
signalling network management.  SCON from an AS or ASP is only
one factor that "MAY" be used.

DAUD would be useless from SG to AS to audit congestion.  It
is also useless from AS to SG to audit congestion.  Congestion
states are neither maintained for local SPMC nor for remote
destinations (routesets).  TFC is sent purely responsive.
Just because an SS7 node has received TFC for a destination
does not mean that its MTP will stop sending messages at that
priority level.  MTP-Users are informed, however, MTP will
continue to transfer messages and the user will get repeated
MTP-STATUS indications indicating congestion.  MTP does not
keep congestion states.

As there is no congestion state to audit, a DAUD from SG to AS
would be pointless.  Sending DAUD from ASP to SG to audit
congestion state is also pointless as this state is not
maintained for SS7.

The SCON message from AS to SG is all but useless.  The SG has
other means at its disposal to determine congestion towards an
AS (e.g, SCTP congestion).  Flow control is best performed at
the MTP-User (e.g, SCCP flow control, ISUP congestion levels).
I requested that it be removed, and the resolution was to
place "MAY" and "could, for example", and a bunch of weak
words around it.

There is certainly no need to start putting more useless
protocol around this useless message.

It works like this: the SG determines whether an SPMC is
congestsed using implementation dependent functions.  It is on
this basis that the SG determines how to respond to RCT.  RCT
is not propagated in any way to AS.  An ASP "MAY" send SCON if
it wants, that might trigger TFC if the SG implementation
wishes to do so.  The SG is responsible for the MTP management
view towards the SS7 network with regard to the SPMC, not the
AS.

This is identical to SEP generated TFC in SS7.  Nothing more
is required.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 12 Feb 2002 13:32:01 -0500

Francois,

Although explained by Brian in detail the short answer is 1.4.6 is about
SCTP/IP network congestion. It is not related with SCON sent from ASP to
SGP, and is detected locally by an implementation dependent way. As
mentioned in my previous message SCON sent from ASP to SGP corresponds to
Signalling Point Congestion or User Part Congestion.

   Tolga

> From: Zannin, Francois [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 12:11 PM
> To: Tolga Asveren; [email-masked]
> Cc: [email-masked]