Subject: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 5 Oct 2005 15:08:30 -0400

To whom it may concern:

Sorry for the long post:

There seems to be some differences between M3UA and SUA relating to use
of the SCON.  And the RFCs themselves are somewhat inconsistent.

Here is the SUA spec:

"1.5.6.  Congestion Management
....
The SUA layer at an ASP or IPSP MAY indicate local congestion to an SUA
peer with an SCON message.  When an SG receives a congestion message
(SCON) from an ASP, and the SG determines that an endpoint is now
encountering congestion, it MAY trigger congestion procedures of the
relevant SCCP standard."

But later we have:

"3.4.4.  Signalling Congestion (SCON)

The SCON message can be sent from the SG or relay node to all concerned
ASPs to indicate that the congestion level in the SS7 network to a
specified destination has changed."

No mention that the SCON can be sent TO the SG from a concerned ASP.  

Questions:

1) why the inconsistency?

2) The RFC indicates for the SCON that the "affected point code" is
mandatory.  But if the ASP is sending it to the SG, there may not be an
affected point code?

3) If the SG receives an SCON from an ASP, is the assumption that the
whole SSN is congested, or just a single ASP with the AS?

4) Should we only assume that the entire AS is congested (the entire SSN
is congested) if all ASPs are congested?  

5) What actions should the SG take if a single ASP is congested in a set
of ASPs?

6) Should the SG somehow monitor or time the congestion so that we don't
get in a permanent congested state?  This is what is done in SS7 SCCP
Congestion Management.

Then when reviewing M3UA (the latest Bis document):

"1.3.2.3 Interworking with MTP3 Network Management Functions

...
The M3UA layer at an ASP may also indicate to the SG that the M3UA layer
itself or the ASP or the ASP's Host is congested."

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

Questions: 

1) The SS7 standards don't have a User Part Congested.  So what should
the SG do in this case?  

2) If the DPC of the ASP and the DPC of the SG are the same, does the SG
take any action?

3) Should the SG monitor congestion of ASPs as mentioned above.

And now a general set of questions/comments

1) This is one of the areas that I would include as a deficiency in the
current RFCs that needs to be addressed (see previous threads: " Message
loss in SIGTRAN networks"; "recommendations for M3UA/SUA BEATs when
running overSCTP")

2) It might be possible to implement some advanced congestion handling
in the SG.  Some of the following is only relevant to M3UA or SUA.  I
leave it up to you to figure that out.  For example, based upon
congestion level we could reduce traffic as indicated in the SCCP
Congestion procedures.  We could only route high priority messages
(priority in ANSI messages), we could discard new dialogs (although this
would require peaking in SCCP data) or only route new dialogs to
non-congested ASPs.  Given a few more moments, I could probably come up
with a few more.  Anyway, I'm not sure if we would want to standardize
this, or leave it up to implementors to make their SGs more feature rich
then the competitors.

Regards,
Lincoln

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 5 Oct 2005 17:25:54 -0400

Congestion in M3UA/SUA and the use of the SCONLincoln,

For the M3UA/generic part, below is what I think.

  Thanks,
  Tolga
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Haresign Lincoln
  Sent: Wednesday, October 05, 2005 3:09 PM
  To: [email-masked]
  Subject: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

  To whom it may concern:

  Sorry for the long post:

  There seems to be some differences between M3UA and SUA relating to use of
the SCON.  And the RFCs themselves are somewhat inconsistent.

  Here is the SUA spec:

  "1.5.6.  Congestion Management
  ..
  The SUA layer at an ASP or IPSP MAY indicate local congestion to an SUA
peer with an SCON message.  When an SG receives a congestion message (SCON)
from an ASP, and the SG determines that an endpoint is now encountering
congestion, it MAY trigger congestion procedures of the relevant SCCP
standard."

  But later we have:

  The SCON message can be sent from the SG or relay node to all concerned
ASPs to indicate that the congestion level in the SS7 network to a specified
destination has changed."

  Questions:

  ...

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

  Questions:

  1) The SS7 standards don't have a User Part Congested.  So what should the
SG do in this case?

  [TOLGA]SCON from ASP to SG does not correspond to indicating user part
congestion to MTP3. It is there to support the case where SG and ASP have
different PCs and M3UA layer of ASP gets congested. In that case,  because
M3UA layer of ASP is performing routing-like function for ASPs PC while
selecting an outgoing SG, its congestion is considered as signaling point
congestion and to support Q.704 11.2.6 and ANSI procedures, SCON from ASP to
SG is sent.

  [TOLGA]SCON from ASP to SG is not allowed for this case.

  [TOLGA]As far as I recall, SCON from ASP to SG was not meant to monitor
ASP congestion state but to generate a corresponding TFC.

  1) This is one of the areas that I would include as a deficiency in the
current RFCs that needs to be addressed (see previous threads: " Message
loss in SIGTRAN networks"; "recommendations for M3UA/SUA BEATs when running
overSCTP")

  2) It might be possible to implement some advanced congestion handling in
the SG.  Some of the following is only relevant to M3UA or SUA.  I leave it
up to you to figure that out.  For example, based upon congestion level we
could reduce traffic as indicated in the SCCP Congestion procedures.  We
could only route high priority messages (priority in ANSI messages), we
could discard new dialogs (although this would require peaking in SCCP data)
or only route new dialogs to non-congested ASPs.  Given a few more moments,
I could probably come up with a few more.  Anyway, I'm not sure if we would
want to standardize this, or leave it up to implementors to make their SGs
more feature rich then the competitors.

  [TOLGA]Although there were some discussions about it, I also am not very
pleased with the lack of documented information about this. I also believe
that congestion status of ASPs could be useful while routing messages from
SG to ASPs and this is currently supposed to be done based on SCTP
assocaition congestion -which again I do not find sufficient for a number of
reasons which probably I need to document as an individual draft-

  Regards,
  Lincoln

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Oct 2005 18:47:34 -0600

Haresign,

Haresign Lincoln wrote:                                                            (Wed, 05 Oct 2005 15:08:30)
> 
>    To whom it may concern:
> 
>    Sorry for the long post:
> 
>    There  seems  to  be some differences between M3UA and SUA relating to
>    use of the SCON.  And the RFCs themselves are somewhat inconsistent.
> 
>    Here is the SUA spec:
> 
>    The  SUA  layer  at an ASP or IPSP MAY indicate local congestion to an
>    SUA  peer  with  an  SCON  message.   When an SG receives a congestion
>    message  (SCON) from an ASP, and the SG determines that an endpoint is
>    now  encountering  congestion, it MAY trigger congestion procedures of
>    the relevant SCCP standard."
> 
>    But later we have:
> 
>    The  SCON  message  can  be  sent  from  the  SG  or relay node to all
>    concerned  ASPs  to  indicate  that  the  congestion  level in the SS7
>    network to a specified destination has changed."
> 

What inconsistency?  The passages are supplemental not contradictory.  Would
you prefer that they be overlapping and redundant?

>    mandatory.   But  if the ASP is sending it to the SG, there may not be
>    an affected point code?

I don't think so.  There is always an affected point code.  There are no
disembodied subsystems in SCCP.  So, for example, if your HLR is an ASP
and you are indicating congestion in subsystem 5, then the affected point
code(s) are the point code(s) of the HLR.

>    whole SSN is congested, or just a single ASP with the AS?

No, there is no assumption.  It is the responsibility of the SG to
determine how to correlate indications from the various ASPs in an AS
and to determine what SS7 messages, if any, need to be sent to the SS7
network.  Specific behaviours might be mandated by National or Regional
standards bodies, bilateral agreement, or operator requirements.  (Note
that TTC SCCP for the longest time did not support SCCP management
messages at all.)

If you check the ETSI SUA modifications, they might have provided more
direction in this regard.  They did for M3UA.

> 
>    4)  Should  we only assume that the entire AS is congested (the entire
>    SSN is congested) if all ASPs are congested?

Up to you.  For a load-shared AS, it would be the normal case that a single
ASP indicating congestion is shortly ahead of all the others indicating
congestion as well.  Unless, perhaps, you have one of your "stuck" ASPs.

The problem that I have always had with ASP to SG SCON, whether it be
SUA or M3UA is that the SG has at its disposal all of the mechanisms
necessary to determine congestion towards the ASP without ever having to
receive a SCON from an ASP.  Another problem is that there is no
primitive interface described for SCCP that permits one of its users
(the AS) to indicate congestion to the SCCP provider (the SG).  SCCP
(the SG) monitors congestion on its own using (of course) implementation
dependent methods.

> 
>    5)  What  actions should the SG take if a single ASP is congested in a
>    set of ASPs?

The RFC does not place any requirements on SG design in this regard.
ETSI TS 102 443 says that Q.714 congestion procedures are followed if
the SG determines that the endpoint is congested.

Well, if a significant portion of the AS's traffic handling capacity is
congested, the whole AS is certainly congested.  At some point it is
necessary to indicate congestion to originators of traffic so that they
can take appropriate actions and not send messages unlikely to be
processed, possibly further congesting the SS7 network, or possibly
further impairing the endpoint's ability to process messages.

Any method chosen should include the hysteresis-loss concept whereby the
abatement level for congestion is placed lower than the level for onset
within each congestion band.

> 
>    6)  Should  the  SG  somehow monitor or time the congestion so that we
>    don't get in a permanent congested state?  This is what is done in SS7
>    SCCP Congestion Management.

An SS7 node does monitor (dual timer approach).  Other ASPs can monitor with
DAUD.  IPSPs can monitor with DAUD.  At least in M3UA's case, and
probably SUA too, the SG does not need to monitor congestion status send
as SCON from ASP to SG.  Such things just trigger a congestion message
(TFC in M3UA's case).

>    The  M3UA  layer  at  an ASP may also indicate to the SG that the M3UA
>    layer itself or the ASP or the ASP's Host is congested."
> 

The SCON message does not have an affected user part in it.  It has
affected point codes.  When an ASP sends a SCON to the SG it is
indicating that the each entire affected point code is congested.

> 
>    2)  If the DPC of the ASP and the DPC of the SG are the same, does the
>    SG take any action?

ASP point codes are always "hosted" at an SG (or at two or more SGs).

The SG deterimnes whether a signalling point is congested and issues the
appropriate SS7 messages according to whichever SS7 standard it must
conform to.

>    3) Should the SG monitor congestion of ASPs as mentioned above.

The SG does not monitor or maintain congestion state for local
congestion at an ASP that triggered the SCON in the ASP ot SG direction.
A TFC may be issued for each affected point code in the SCON and sent to
the concerned point code, if the SG determines that the endpoint is
congested and wishes to send TFC.  Note that in ANSI networks when the
SG is an STP, TFR is also an apporpriate response, given that the SG
determines that there is "danger of congestion".

>    1)  This  is  one of the areas that I would include as a deficiency in
>    the  current  RFCs that needs to be addressed (see previous threads: "
>    Message loss in SIGTRAN networks"; "recommendations for M3UA/SUA BEATs
>    when running overSCTP")

Really?  This is one of the few areas that I think is not deficient.
All the protocol mechanisms (even ones of questionable utility) are
available to the SG implementation to meet a wide range of varying
requirements imposed by numerous national SS7 standards upon a
deployment.

One particularly reason for avoiding to place requirements on the SG
visa vi its interaction with the SS7 network, is that SS7 conformance
and compliance is definitely outside the scope of the specifications.
Certainly there is enough industry experience to properly implement SS7
stacks on the SG without the M3UA or SUA specifications presuming to
place requirements on SS7 stacks.  The scope of the M3UA and SUA
specifications are the IP network interactions.  The only reason that
the SS7 network is mentioned at all in these passages was because Greg
thought that it would improve understanding while not restricting SS7
implementation.

>    (priority  in  ANSI  messages), we could discard new dialogs (although
>    this  would require peaking in SCCP data) or only route new dialogs to
>    non-congested  ASPs.   Given a few more moments, I could probably come
>    up  with  a  few  more.   Anyway,  I'm  not  sure  if we would want to
>    standardize  this,  or  leave  it up to implementors to make their SGs

The ETSI documents (TS 101 142, TS 101 143) require that such congestion
handling procedure be implemented and in accordance with Q.704 and Q.714
(modified) specifications.  A detail that we could not require in the UA
specifications and yet keep the specification independent of SS7
protocol variant.

For example, if you look the BT PNOC documents, you will see a
completely different perspective on congestion control, particularly for
ISUP and MTP.

--brian

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

---

From: Kamesh Kaul <[email-masked]>
Date: Wed, 5 Oct 2005 22:23:35 -0700 (PDT)

Hi Lincoln,
Even though attached draft
"draft-kamesh-m3ua-congestion-procedures-00.txt" has
expired in Jul 2003 it may provide some insight on
congestion handling in M3UA and can be a base for
fresh discussion.

Best Regards
Kamesh

--- Haresign Lincoln <[email-masked]>

> https://www1.ietf.org/mailman/listinfo/sigtran

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

       INTERNET-DRAFT                                  Kamesh Kaul[EDITOR]
                                                     Hughes Software Systems

       Issued:  Jan 2002
       Expires: Jul 2003

                              M3UA Congestion procedures
                   <draft-kamesh-m3ua-congestion-procedures-00.txt>

       Status of This Memo

       This document is an Internet-Draft and is in full conformance with all
       provisions of Section 10 of RFC 2026. Internet-Drafts are working
       documents of the Internet Engineering Task Force (IETF), its areas,
       and its working groups. Note that other groups may also distribute
       working documents as Internet-Drafts.

            The list of current Internet-Drafts can be accessed at
            http://www.ietf.org/ietf/1id-abstracts.txt

            The list of Internet-Draft Shadow Directories can be accessed at
            http://www.ietf.org/shadow.html.

       To learn the current status of any Internet-Draft, please check the
       '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
       Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
       munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
       ftp.isi.edu (US West Coast).

    Kamesh Kaul, HSS                                                 [Page 1]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       Abstract

       This Internet-Draft describes congestion procedures applicable for both
       M3UA [2] ASP and SG nodes. Draft explains all the procedures needed by
       M3UA [2] ASP and SG to handle local and network congestion communicated
       between M3UA [2] SG and ASP through SSNM messages. Congestion
       procedures proposed are in line with MTP3 Q.704 with some alteration to
       suit sigtran architecture.

                                    TABLE OF CONTENTS

       1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3
           1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3
           1.2 Terminology. . . . . . . . . . . . . . . . . . . . . . 3
           1.3 Conventions. . . . . . . . . . . . . . . . . . . . . . 3
           1.4 Overview . . . . . . . . . . . . . . . . . . . . . . . 3
       2. Congestion handling at M3UA [2] ASP . . . . . . . . . . . . 4
           2.1 Handling local node congestion  . . . . . . . . .. . . 4
           2.2 Handling SCON messages . . . . . . . . . . . . . . . . 5
               2.2.1 International/National-networks-without-priority 5
               2.2.2 National-networks-with-priority . . . . . . . .  5
                   2.2.2.1 Congestion provisioning without timer. . . 5
                   2.2.2.2 Congestion provisioning with timer. . . . .6
           2.3 Handling of MTP3 user messages . . . . . . . . . . . . 7
           2.4 Generation of SCON messages. . . . . . . . . . . . . . 8
       3. Congestion handling at M3UA [2] SGP . . . . . . . . . . . . 8
           3.1 Handling local node congestion. . . . . . . . . . . . .8
           3.2 Handling SCON messages. . . . . . . . . . . . . . . . .9
               3.2.1 International/National-networks-without-priority 9
               3.2.2 National-networks-with-priority . . . . . . . .  10
           3.3 Handling of NIF/local-user messages. . . . . . . . . . 12
       4. Examples of network congestion . . . . . . . . . . . . . . .14
           4.1 ASP network congestion with multiple SG's . . . . . . .14
           4.2 ASP network congestion abatement with multiple SG's . .15
           4.3 SGP network congestion with multiple AS's . . . . . . .16
       5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 17
       6. References. . . . . . . . . . . . . . . . . . . . . . . . . 17
           6.1 Normative References . . . . . . . . . . . . . . . . . 17
           6.2 Informative References . . . . . . . . . . . . . . . . 17
       7. Author's Addresses. . . . . . . . . . . . . . . . . . . . . 17

    Kamesh Kaul, HSS                                                 [Page 2]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       1. Introduction

       1.1. Scope

       This Internet-Draft describes congestion procedures, which are
       necessary for M3UA [2] ASP and SG nodes to handle both local node
       congestion and network congestion communicated to M3UA ASP or SG nodes
       via SSNM messages. This draft proposes congestion procedures, which
       makes M3UA [2] ASP and SG nodes handle congestion in line with
       MTP3(Q.704) specified congestion procedures with some alterations.

       1.2. Terminology

       M3UA congestion draft uses the terminology used in the M3UA
       RFC[3332].

       1.3. Conventions

       The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
       SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
       they appear in this document, are to be interpreted as described in
       [3].

       1.4 Overview

       The purpose of this draft is to propose congestion procedures
       applicable for M3UA ASP and SG nodes in the same lines as suggested by
       MTP3 (Q.704) with some variations. By following MTP3 congestion
       procedures congestion handling will be done in similar fashion across
       the networks, no matter in which domain (SS7 or IP) node resides. This
       will result in effective interworking of congestion handling mechanisms
       between SS7 and M3UA SG/ASP nodes.

    Kamesh Kaul, HSS                                                 [Page 3]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       2. Congestion handling at M3UA [2] ASP

       2.1 Handling local node congestion

       M3UA ASP node undergoes congestion due to local SCTP association
       congestion (which is implementation dependent and may be in a way
       determined from current transmitting buffer occupancy of association at
       SCTP or M3UA level). Change in congestion status of an SCTP association
       may result in the congestion status update of the SG (route) which can
       be reached through congested association. This change in congestion
       status of SG may result in congestion status update of all the point
       codes which can be reached via congested SG. If a point code can be
       reached through more than one SG's, congestion status of point code is
       equal to the congestion level of maximum congested SG (route). Figure
       below shows ASP connected with two SG's SG1 (association a) and SG2
       (association b).Point code X-Y-Z is reachable through both the SG's.

                                     +--+----++
                         assoc a     |        |
                         +--- -- ----+  SG1   +-----+
                         |           |        |     |
                         |           +--------+     |      SS7 NODE
          +--+----++     |                          |    +----------+
          |        |     |                          |    |   PC     |
          |  ASP   +-----+                          +----+  X-Y-Z   |
          |        |     |                          |    |          |
          +--------+     |                          |    +----------+
                         |          +--+----++      |
            AS:A-B-C     |          |        |      |
                         +----------+  SG2   +------+
                          assoc b   |        |
                                    +--------+

                                  Figure: 1

       Now if "association a" undergoes congestion, congestion status of point
       code X-Y-Z maintained at ASP gets updated. If after some time
       "association b" undergoes congestion. Congestion status of point code
       X-Y-Z is updated if "association b" undergoes more congestion than
       "association a".

    Kamesh Kaul, HSS                                                 [Page 4]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       2.2 Handling SCON messages

       Processing of SCON message received from SG depends on the network with
       which affected point codes are associated.

       2.2.1 International/National-networks-without-priority

       If the affected point code is associated with international network,
       congestion level obtained from received SCON message is notified to
       MTP3 user parts. M3UA [2] at ASP does not retain congestion level
       received in SCON message.

       2.2.2 National-networks-with-priority

       2.2.2.1 Congestion provisioning without timer
       If the affected point code is associated with national network with
       congestion priority, M3UA at ASP updates the change in congestion
       status of affected point code configured at ASP. MTP3 user parts are
       notified, if congestion status of affected point code changes. Each
       user then takes appropriate actions in order to stop generation of
       signalling messages destined for the affected point code with
       congestion priorities lower than the specified congestion status.
       At the same time DAUD timer is started to send DAUD messages to SG as
       proposed by M3UA [2] rfc 3332. DAUD messages are send with affected
       point code to SG, until SCON message with 0 congestion level is not
       received from SG. Assuming no local congestion, congestion status of
       affected point code configured at ASP is marked non-congested when SCON
       with 0 congestion level is received from all the SG's which have
       previously send SCON message with level greater than 0. As shown in
       figure 2 below SCON (1) and SCON (3) messages received from SG1 and SG2
       respectively for affected point code X-Y-Z results in change of
       congestion status to 3 for point code X-Y-Z configured at ASP.

    Kamesh Kaul, HSS                                                 [Page 5]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

                              SCON (1)+--+----++
                             <------- |        |
                          +-----------+  SG1   +-----+
                          |           |        |     |
                          |           +--------+     |      SS7 NODE
           +--+----++     |                          |    +----------+
           |        |     |                          |    |   PC     |
           |  ASP   +-----+                          +----+  X-Y-Z   |
           |        |     |                          |    |          |
           +--------+     |                          |    +----------+
                          |          +--+----++      |
             AS:A-B-C     |          |        |      |
                          +----------+  SG2   +------+
                            <------- |        |
                             SCON(3) +--------+

                                  Figure: 2

       Point code X-Y-Z configured at ASP is marked non-congested if SCON
       messages with congestion level 0 is obtained from both SG's (SG1 and
       SG2).

       2.2.2.2 Congestion provisioning with timer
       Alternative approach for national option with congestion priority is to
       provision congestion at ASP using congestion timer. In this approach
       congestion abatement of affected point code is entirely dependent on
       congestion timer expiry. When an SCON message with affected point code
       is received DAUD timer is started. Any SCON message received during
       DAUD time may update the congestion status of affected point code.
       After DAUD timer expiry DAUD message is send to peer SG to audit the
       present congestion status of the affected point code. Congestion timer
       is started along with DAUD timer. If SCON message with affected point
       code is not received till congestion timer expiry, congestion level of
       affected point code is decremented by 1 and the procedure starts again
       till congestion level of affected point code reaches 0 (no-congestion).
       Congestion timer is per SG similar to DAUD timer; it provisions
       congestion status of all the point codes reachable through a given SG.
       One of the advantages of this approach is that provisioning of
       congestion is done even if SCON messages are lost in transit from SG to
       ASP.

    Kamesh Kaul, HSS                                                 [Page 6]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       Figure 3 below shows the mechanism of provisioning congestion using
       congestion timer. The value of congestion timer should be at least
       equal to round trip time between ASP and SG.

                         ASP                                SG

                                         SCON (2)
         PC X-Y-Z        Tdaud   _ <----------------------  |
          (Cong 2)       starts  |                          |
                                 |                          |
                                 |                          |
                                 |                          |
                                 |                          |
                                 |      DAUD ( PC X-Y-Z )   |
                Tcong    Tdaud  -+- ----------------------->|
                starts   restart |                          |
                                 |                          |
                                 |                          |
         PC X-Y-Z      Tcong    -+-                         |
          (Cong 0)     expires

                                  Figure: 3

       2.3 Handling of MTP3 user messages

       When a message signaling unit from a local user part is received for a
       congested point code it is handled differently depending on the network
       appearance associated with the point code.
       If the network appearance is associated with international networks or
       national networks without priority following actions are performed:
       Data message is passed to SCTP (underlying transport layer) for
       transmission.
       An MTP-STATUS primitive will be returned to each level 4 user parts,
       for the initial message or alternatively after every n messages (n = 8)
       received for the congested point code.

       If the network appearance is associated with national networks with
       priority following is applicable:

    Kamesh Kaul, HSS                                                 [Page 7]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       Message priority field in the data message is compared with the
       congestion status of the point code. If the message priority of data
       message is less than the congestion status of the point code data
       message is discarded otherwise it is send to SCTP (underlying transport
       layer) for transmission.
       On message discard MTP-STATUS indication is given to each level 4 users
       with the congestion level of the affected point code.

       2.4 Generation of SCON messages

       M3UA ASP node undergoes receive congestion due to local SCTP
       association congestion (which is implementation dependent and may be in
       a way determined from current receiving buffer occupancy of association
       at SCTP or M3UA level).On receiving M3UA Protocol data message on
       congested association (receive congestion) corresponding to M3UA ASP
       and SGP, data handling depends on network appearance of DPC in data
       message:
       If network appearance is associated with International or national
       network without priority, following actions are performed:
       An MTP-TRANSFER indication is given to concerned user part.
       ASP responds with SCON message for the initial data message or
       alternatively after every n messages (n = 8) received on the congested
       association. Affected point code in SCON message is same as DPC of
       received data message and concerned point code being the OPC of the
       received data message.

       If network appearance is associated with national network with
       congestion priority, M3UA protocol data message received SHOULD be
       responded with SCON message if receive congestion status at ASP is
       greater than message priority field in M3UA protocol data message. An
       MTP-TRANSFER indication is given to concerned user part.

       3. Congestion handling at M3UA [2] SGP
       3.1 Handling local node congestion

       M3UA SG node undergoes congestion due to local SCTP association
       congestion (which is implementation dependent and may be in a way
       determined from current transmitting buffer occupancy of association at
       SCTP or M3UA level). Change in congestion status of an SCTP association
       may result in the congestion status update of remote ASP which can be
       reached through congested association. This change in congestion status
       of remote ASP may result in congestion status update of all the SPMC
       which can be reached via congested ASP. If an SPMC can be reached

    Kamesh Kaul, HSS                                                 [Page 8]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       through more than one remote ASP's, congestion status of SPMC is equal
       to the congestion level of maximum congested remote ASP.
       Figure below shows SGP connected with two ASP's ASP1 (association a)
       and ASP2 (association b).ASP1 and ASP2 are serving SPMC A-B-C.

                                         AS(A-B-C)
                                       +--+----++
                             assoc a   |        |
                           +-----------+  ASP1  +
                           |           |        |
                           |           +--------+
            +--+----++     |
            |        |     |
            |  SGP   +-----+
            |        |     |
            +--------+     |             AS(A-B-C)
                           |           +--+----++
            SPMC:A-B-C     |           |        |
                           +-----------+  ASP2  +
                             assoc b   |        |
                                       +--------+

                                  Figure: 4

       Now if "association a" undergoes congestion, congestion status of SPMC
       A-B-C maintained at SGP gets updated. If after some time "association
       b" undergoes congestion. Congestion status of SPMC A-B-C is updated if
       "association b" undergoes more congestion than "association a".

       3.2 Handling of SCON messages

       Processing of SCON message received from ASP depends on the network
       with which affected SPMC is associated as explained below:

       3.2.1 International/National-networks-without-priority

       If the affected SPMC is associated with international network or
       national network without priority, congestion level obtained from
       received SCON message is notified to NIF or local MTP3 user parts. M3UA
       at SGP does not maintain congestion level of received SCON message. SG

    Kamesh Kaul, HSS                                                 [Page 9]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       SHOULD send TFC to convey congestion status to the concerned point
       code.

       3.2.2 National-networks-with-priority

       If the affected SPMC is associated with national network with
       congestion priority, M3UA at SGP may update the change in congestion
       status of affected SPMC configured at SGP. NIF or local MTP3 user parts
       are notified if congestion status of affected SPMC changes. Congestion
       timer (Tcong) is started.  If SCON message with affected SPMC is not
       received till congestion timer expiry congestion level of affected SPMC
       is decremented by one. Congestion timer is restarted and procedure
       continues until congestion level of affected SPMC reaches 0 (no-
       congestion). Congestion timer provisions congestion status of affected
       SPMC. As shown in figure 5 below SCON (1) and SCON (3) messages
       received from ASP1 and ASP2 respectively for affected SPMC A-B-C
       results in update of SPMC A-B-C congestion status to 3 at SGP.

                                          AS(A-B-C)

                                SCON(1) +--+----++
                                <------ |        |
                            +-----------+ ASP1   +
                            |           |        |
                            |           +--------+
             +--+----++     |
             |        |     |
             |  SGP   +-----+
             |        |     |
             +--------+     |            AS(A-B-C)
                            |           +--+----++
             SPMC:A-B-C     |           |        |
                            +-----------+ ASP2   +
                               <------  |        |
                               SCON(3)  +--------+

                                  Figure : 5

       As shown in figure 6.1 and 6.2 congestion abatement of SPMC A-B-C
       configured at SGP is totally dependent on congestion provisioning timer
       Tcong.

    Kamesh Kaul, HSS                                                 [Page 10]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       When an SCON message with affected point code is received Tcong timer
       is started. Any SCON message received during Tcong time may update the
       congestion status of affected SPMC and congestion timer is restarted.
       After Tcong timer expiry congestion level of affected SPMC is
       decremented by 1 and congestion timer starts again till congestion
       level of affected SPMC reaches 0 (no-congestion).

                       SGP                               ASP1   ASP2

                                       SCON (2)
        SPMC A-B-C     Tcong   _ <------------------------+     |
        (cong 2)       starts  |                          |     |
       <----------             |                          |     |
        notify NIF             |                          |     |
        (local user)           |                          |     |
                               |                          |     |
                               |                          |     |
       SPMC A-B-C      Tcong   +-                         |     |
        (cong 1)       restart |                          |     |
       <----------             |                          |     |
        notify NIF             |                          |     |
        (local user)           |                          |     |
                               |                          |     |
                               |                          |     |
       SPMC A-B-C    Tcong    -+-
        (Cong 0)     expires
       <---------
       notify
       (local user)
                                  Figure 6.1

    Kamesh Kaul, HSS                                                 [Page 11]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

                         SGP                                ASP1  ASP2

                                         SCON (1)
          SPMC A-B-C     Tcong   _ <------------------------+     |
          (cong 1)       starts  |                          |     |
         <----------             |                          |     |
          notify NIF             |                          |     |
          (local user)           |                          |     |
                                 |       SCON (2)           |     |
         SPMC A-B-C      Tcong  -+-<------------------------+-----+
          (cong 2)       reset  -+-                         |     |
         <----------    (before  |                          |     |
          notify NIF     expiry) |                          |     |
         (local user             |                          |     |
                                 |                          |     |
                                 |                          |     |
           SPMC A-B-C    Tcong  -+-                         |     |
            (Cong 1)     expires |                          |     |
           <---------   (restart)|                          |     |
           notify NIF            |                          |     |
           (local user)          |                          |     |
                                 |                          |     |
                                 |                          |     |
          SPMC A-B-C    Tcong   -+-                         +     +
           (Cong 0)     expires
          <---------
          notify
         (local user)
                                  Figure 6.2

       3.3 Handling of NIF/local-user messages

       When a message signaling unit from NIF/local-user part is received for
       a congested SPMC it is handled differently depending on the network
       appearance associated with the SPMC.
       If the network appearance is associated with international networks or
       national networks without priority following actions are performed:
       Data message is passed to SCTP (underlying transport layer) for
       transmission.

    Kamesh Kaul, HSS                                                 [Page 12]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       An MTP-STATUS primitive will be returned to NIF/local-users for the
       initial message or alternatively after every n messages (n = 8)
       received for the congested SPMC.

       If the network appearance is associated with national networks with
       priority following is applicable:
       The message priority field in the data message is compared with the
       congestion status of the concerned SPMC. If the message priority of
       data message is less than the congestion status of the affected SPMC
       data message is discarded otherwise it is send to SCTP (underlying
       transport layer) for transmission.
       On message discard MTP-STATUS indication is given to NIF/local-users
       with the congestion level of the affected SPMC.

    Kamesh Kaul, HSS                                                 [Page 13]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       4. Examples of network congestion

       4.1 ASP network congestion with multiple SG's
       In the following scenario, SG1 consists of SGP1, SG2 consisits
       of SGP2 and SG3 consists of SGP3. Point code X-Y-Z is configured

                                            SG1
                               SCON (3)  ++-----+-++
                             <---------  |         |
                          +--------------+  SGP1   +---+-------++
                          |              |         |            |
                          |              +---------+            |
                          |                                     |
                          |                 SG2                 |
          +------+-++     |    SCON (2)  ++-----+-++        +--++--+-++
          |         |     |   <--------- |         |        |         |
          |  ASP    +-----+--------------+  SGP2   +-- +----+   PC    +
          |         |     |              |         |        | (X-Y-Z) |
          +---------+     |              +---------+        +----+----+
         PC (X-Y-Z)       |                                      |
                          |                SG3                   |
                          |    SCON (1)  +------+-++             |
                          |  <---------- |         |             |
                          +--------------+  SGP3   +---+---------+
                                         |         |
                                         +---------+

    Kamesh Kaul, HSS                                                 [Page 14]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       at ASP.As shown in figure above SCON messages received from SG1,SG2 and
       SG3 are SCON(3),SCON(2)and SCON(1) respectively. Assuming no local
       congestion, congestion status of point code X-Y-Z configured at ASP
       after receiving SCON messages is 3.

       4.2 ASP network congestion abatement with multiple SG's

       As shown in figure below congestion status of point code X-Y-Z
       configured at ASP is marked 0 (non-congested) when SCON (0) is received
       from SG1,SG2 and SG3 (all the routes through which point code is
       reachable). This example is valid if no timer is used to provision
       congestion at ASP.

                                             SG1
                                SCON (0)  ++-----+-++
                              <---------  |         |
                           +--------------+  SGP1   +---+-------++
                           |              |         |            |
                           |              +---------+            |
                           |                                     |
                           |                 SG2                 |
           +------+-++     |    SCON (0)  ++-----+-++        +--++--+-++
           |         |     |   <--------- |         |        |         |
           |  ASP    +-----+--------------+  SGP2   +-- +----+   PC    +
           |         |     |              |         |        | (X-Y-Z) |
           +---------+     |              +---------+        +----+----+
          PC (X-Y-Z)       |                                      |
                           |                SG3                   |
                           |    SCON (0)  +------+-++             |
                           |  <---------- |         |             |
                           +--------------+  SGP3   +---+---------+
                                          |         |
                                          +---------+

    Kamesh Kaul, HSS                                                 [Page 15]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       4.3 SGP network congestion with multiple AS's

       In the following scenario, AS1 consists of ASP1, AS2 consists
       of ASP2 and AS3 consists of ASP3. SPMC A-B-C is configured. Routing key
       type for all the AS's is DPC+SIO+CIC. Routing keys for AS1,AS2 and AS3
       are (A-B-C)+ (ISUP) + (1-10), (A-B-C)+ (ISUP) + (11-20) and (A-B-C)+
       (ISUP) + (21-30) respectively. As shown in figure below SCON messages
       received from ASP1,ASP2 and ASP3 are SCON(3),SCON(2)and SCON(1)
       respectively. Assuming no local congestion, congestion status of SPMC
       A-B-C configured at ASP after receiving SCON messages is 3.

                                            AS1
                               SCON (3)  ++-----+-++
                             <---------  |         |
                          +--------------+  ASP1   +
                          |              |         |
                          |              +---------+
                          |
                          |                 AS2
          +------+-++     |    SCON (2)  ++-----+-++
          |         |     |   <--------- |         |
          |  SGP    +-----+--------------+  ASP2   +
          |         |     |              |         |
          +---------+     |              +---------+
        SPMC (A-B-C)      |
                          |                AS3
                          |    SCON (1)  +------+-++
                          |  <---------- |         |
                          +--------------+  ASP3   +
                                         |         |
                                         +---------+

       Congestion abatement of SPMC A-B-C is provisioned by congestion timer
       explained in earlier text.

    Kamesh Kaul, HSS                                                 [Page 16]
    Internet Draft         M3UA Congestion Procedures                Jan 2003

       5. Acknowledgements

       The authors would like to thank Anshoo Sharma, Sandeep Mahajan and
       Priyaranjan for their valuable comments and suggestions.

       6. References

       6.1 Normative References

       [1] ITU-T Recommendation Q.704 "Specifications of Signalling System
       No. 7 - Message transfer part  Signalling network functions and
       messages"

       [2] RFC[3332] "SS7 MTP3 - User Adaptation Layer (M3UA)"

       6.2 Informative References

       [4] RFC[2119] "Key words for use in RFCs to Indicate Requirement
       Levels"

       7. Author's Addresses

       Kamesh Kaul
       Hughes Software Systems
       Delhi
       EMail : [email-masked],[email-masked]

    Kamesh Kaul, HSS                                             [Page 17]