Subject: RE: [Sigtran] Re: M3UA DATA message

From: "Richard Adams" <[email-masked]>
Date: Thu, 6 Mar 2003 16:30:20 +0100

Tolga,
I agree with most of what you say. But TFC CAN be sent in networks other
than ANSI ones when a signalling point itself is experiencing congestion
(e.g. the Netherlands, UK,....).
Kind regards,
Dick Adams,
[email-masked]

-----Original Message-----
From: TOLGA ASVEREN [mailto:[email-masked]]
Sent: 06 March 2003 16:00
To: [email-masked]
Subject: Re: [Sigtran] Re: M3UA DATA message

Hi Kamesh,

Does it really work like this according to RFC/IG? I don't think so. And
for that specific case, it is even not said whether AS and SG do have
the
same PC, so how can one decide what to do so easily?
IMO the relevant part of RFC is:
1.4.6 Congestion Management:
"  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."

So based on SCON from ASP (only sent for ANSI and when AS and SG have
different PCs) SG decides based on an implementation dependent way when
SPMC is congested and acts accordingly.

    Tolga

                    [email-masked]

                    .com                 To:     "B.Sasidhar Reddy"
<[email-masked]>    
                    Sent by:             cc:     [email-masked]

                    sigtran-admin@       Subject:     Re: [Sigtran] Re:
M3UA DATA message                     
                    ietf.org

                    06.03.2003

                    15:57

Hi
     On receiving SCON message from ASP 1. SG will handle the received
SCON
message depending on the network appearance associated with AS1.For
national
option with priority M3UA at SG will update the SPMC congestion status
based on
the SCON level and give the notification to NIF about the changed SPMC
congestion status.SG can then send TFC to concerned SEP1.For
international
option notification is given to NIF on the reception of SCON so that SG
can
send
TFC to concerned SEP1. To know more about congestion handling mechanisms
in
M3UA
refer to draft:
http://www.ietf.org/internet-drafts/draft-kamesh-m3ua-congestion-procedu
res-00.txt

Regards
Kamesh
Hughes Software Systems

"Brian F. G. Bidulock" <[email-masked]> on 03/06/2003 05:30:58 PM

Please respond to [email-masked]

To:   "B.Sasidhar Reddy" <[email-masked]>
cc:   [email-masked], [email-masked] (bcc: Kamesh Kaul/HSS)

Subject:  [Sigtran] Re: M3UA DATA message

B.Sasidhar,

B.Sasidhar Reddy wrote:
(Thu, 06 Mar 2003 17:21:59)
>
>    Brian
>
>                                 ----------
>
>                                 |SEP1  |
>
>                                 -----------
>
>                                     |
>
>                                     |
>
>     -------------               -------------
>    -----------
>
>     | ASP1  |---------------| SGP1  | -----------------|SEP2    |
>
>     -------------               --------------
>    ------------
>
>                                     |
>
>                                     |
>
>                               --------------
>
>                               | ASP2   |
>
>                               --------------
>
>
>
>    ASP1 and ASP2 are serving AS1.
>
>    SGP1 is serving SG1.
>
>    SEP1 and SEP2 are two SS7 nodes with different point codes.
>
>
>
>    Let us assume that SGP1 received DATA message from SEP1 for which
ASP1
>    becomes congested and sends SCON with Affected PC of AS1 and
concerned
>    PC of SEP1.
>
>
>
>    Now  when  SEP1 sends DATA message to AS1, Should the SGP1 forward
the
>    message to AS1 though ASP2?.

No.

>
>    Now  when  SEP2 sends DATA message to AS1, Should the SGP1 forward
the
>    message to AS1 either though ASP1 or ASP2?.

No.

The SGP should not alter routing between ASPs in response to SCON
received
from an AS.  In fact, because of the way that SMH TFC is described in
ANSI-2000 SS7 SGP will normally ignore SCON received from the ASP
altogether.

If ASP1 becomes congested it should indicate congestion at the MTP-User
level.
For SCCP users this consists of sending SSC messages.  For ISUP users
this
consists of sending ACL parameters in REL messages.

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

_______________________________________________
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: Thu, 6 Mar 2003 09:45:35 -0700

Richard,

The SCON message from ASP to SGP was intended to indicate SMH-based (Nodal)
TFC which is only defined for ANSI and is not defined for ITU/ETSI based
networks.

--brian

Richard Adams wrote:                                                               (Thu, 06 Mar 2003 16:30:20)

---

From: "B.Sasidhar Reddy" <[email-masked]>
Date: Mon, 10 Mar 2003 11:19:35 +0530

Hi
                             ----------
                             |SEP1  |
                             -----------
                                 |
                                 |
 -------------               -------------                   -----------
 | ASP1  |---------------| SGP1  | -----------------|SEP2    |
 -------------               --------------                  ------------
                                 |
                                 |
                           --------------
                           | ASP2   |
                           --------------

ASP1 and ASP2 are serving AS1.
SGP1 is serving SG1.
SEP1 and SEP2 are two SS7 nodes with different point codes.
SG1 and AS1 are having different point codes.
All the signalling points belong to the same network.
Traffic mode of AS1 is Loadshared.

Let us assume that SGP1 received DATA message from SEP1 for which ASP1
becomes congested and sends SCON with Affected PC of AS1 and concerned PC of
SEP1.

If SCON is received from ASP1 serving AS1, can i say that AS1 is congested?

thanks
Sasidhar

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Mar 2003 01:11:10 -0700

Sasidhar,

It is the responsibility of SG1 to determine how to reflect the
status of the SPMC (point code of AS1) into the SS7 network.
How an SG does this is implementation dependent.

That said, TFC sent to the network by the SGP is used for
signalling network congestion, not internal end node congestion.

If AS1 is an ISUP node, and it is encountering call control
congestion it is better to include ACL in REL instead of sending
SCON.  If AS1 is an SCCP node, and it is encountering subsystem
congestion, it is better to send SSC for the affected subsystem.
SG1 would only normally send TFC to the network if the SG
implementation was configured to do so (it is optional in SS7)
and if the SG is encounting congestion in transferring messages
to AS1.  It is not required and not necessarily wise for the SG
to consider SCON from the AS in its determination of signalling
network congestion.

A stronger reason for sending TFC to SEP1 or SEP2 might be if
the SG discovers that its transmit buffers to ASP1 are filling.
Then it is reasonable for the SG to send TFC to SEP1 or SEP2 on
a similar statistical basis as it does for signalling link
congestion.

There is never really a case where it makes much sense for an SG
to act on SCON received from an ASP.  But, sending TFC from a
node is so vauge in some SS7 specifications that it was placed
there as an option.  The SG is reponsibility for deciding in any
way necessary for it to meet SS7 conformance requirements for
the SS7 network to which it is attached.

Hope that helps.

--brian

B.Sasidhar Reddy wrote:                                                         (Mon, 10 Mar 2003 11:19:35)