Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 14 Oct 2005 09:18:59 -0400

Brian,

You still have not addressed how to handle _ASP congestion_ in the two
scenarios below.  I have.

At this point, I seem to have the agreement of several other members of
the WG.  You seem to be the only person opposed to making affected point
code optional.  I think Valerie's suggestion was a good one.

I'm not sure this exchange is practical anymore since you and I have a
basic disagreement over how to solve a problem.  I've presented a
solution.  If you have another one, I'd be welcome to listen to it.  But
in lieu of another solution to the two problems outlined below, it is my
opinion that this exchange is no longer serving a practical purpose.  I
look forward to feedback from other members of the WG and the SUA IG
editors.

Thanks for all your feedback.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 9:10 AM
To: Haresign Lincoln
Cc: Valerie Gastaud; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Lincoln,

Haresign Lincoln wrote:
(Fri, 14 Oct 2005 08:48:46)
> Brian,
> 
> Are you saying that an ASP can not congest?  I'm not really sure where

> you are going with this.  The RFC says the following:
> 
>    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.
> 
> If this is not true, let me know and we will need to amend the RFC and

> find another way to handle ASP congestion.  My very first email that 
> started this thread asked the question of whether SCON was valid from 
> ASP to SG.  At the time, you indicated that this was valid. Are you 
> now saying it is valid, but only in limited scenarios?

I tried a good number of times to tell you that SCON was for SCCP and
Subsystem (N-STATE and N-PCSTATE) congestion only.  This is no different
in the SG->ASP or ASP->SG directions.  When the ASP sends SCON it is
indicating SCCP or SCCP Subsystem congestion to the SG depending upon
whether it places SSN in the message or not.  When there is no SSN in
the message, it corresponds to MTP congestion (precisely the same
scenario in which M3UA sends SCON from ASP to SG).  When there is an SSN
in the message, and SSN is 1, it indicates SCCP Congestion, when SSN is
other than 1, it indicates SCCP Subsystem Congestion.

> 
> If this is valid, then there are two scenarios that the RFC does not
> handle:
> 
> 1) ASP shares the same point code as the SG and is not aware of it's 
> point code.  Meaning the ASP may just be a global title.  Or there 
> could be multiple AS behind the SG with different subsystems but 
> sharing the same point code as the SG.

It will try again: an ASP that is not aware of point codes has no
business signalling MTP or SCCP congestion levels.  MTP congestion
levels are maintained on a point code basis.  So are SCCP congestion
levels (RIL).
SCCP subsystem congestion (CL) is also maintained on a point code basis.

If the ASP is unaware of point codes, why is it sending the messages?

Also, in the trivial case where SG an ASP share a single point code, the
SG with a fully functional SCCP layer is capable of providing all SCCP
congestion management functions without assistance from the ASP.  It is
more usable in the multiple SG as STP, and ASP as relay scenarios, where
the ASP can send SCON independently to each SG.

> 
> 2) ASP is multiple point codes.
> 
> In the RFC, the handling of the SCON message by the SG is 
> implementation dependent.

No, the handling of the SCON message is clear.  Whether the SG sends an
SS7 message to the SS7 network is in accordance with the conformances
that it must meet in that direction that are outside the scope of the
SUA specification.  Because the SG MAY (in order to meet conformance)
send an
SS7 congestion message, a SCON sent from the ASP clearly MUST have the
necessary information and be generated under the proper conditions.  The
description of the message, and its mandatory contents, accomplish this.

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 07:46:27 -0600

Haresign,

Signalling ASP congestion with SCON is a misuse of SCON.

Define some ASPTM messages to do the job.  ASPTM messages are
only indexed off of Routing Context, do not contain any addresses,
and can use their own congestion level definition.

Leave SCON alone.

Here you go:

   ASP Traffic Maintenance (ASPTM) Messages

      0         Reserved
      1         ASP Active (ACTIVE)
      2         ASP Inactive (INACTIVE)
      3         ASP Active Ack (ACTIVE ACK)
      4         ASP Inactive Ack (INACTIVE ACK)
>     5         ASP Status (STATUS)
>     6         ASP Status Qry (STATUS QRY)
      7 - 127   Reserved by the IETF
      128 - 255 Reserved for IETF-Defined Message Class Extensions

>3.6.5.  ASP Status (STATUS)
>
>  The ASPST message is sent by an ASP to indicate to a remote SUA peer
>  that it is experiencing congestion in processing signalling traffic
>  for a particular Application Server.
>
>  The format for the STATUS message is as follows:
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |           Tag = 0x0006        |             Length            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  /                       Routing Context                         /
>  \                                                               \
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |           Tag = 0x0019        |             Length            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  /                       ASP Congestion                          /
>  \                                                               \
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |          Tag = 0x0110         |             Length            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  /                          Info String                          /
>  \                                                               \
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  Parameters
>    Routing Context     Optional
>    ASP Congestion      Mandatory
>    Info String         Optional
>
>3.6.4.  ASP Status Qry (STATUS QRY)
>
>  The STATUS QRY message is used to request an ASP-Status message
>  from a remote SUA peer indicating the current congestion of the
>  remote ASP.
>
>  The format for the STATUS Qry message is as follows:
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |          Tag = 0x0006         |             Length            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  /                       Routing Context                         /
>  \                                                               \
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |          Tag = 0x0004         |             Length            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  /                          INFO String                          /
>  \                                                               \
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>  Parameters
>    Routing Context     Optional
>    INFO String         Optional

3.9.  Common Parameters

   These TLV parameters are common across the different adaptation
   layers.

   Parameter Name                     Parameter ID
   ==============                     ============
   Reserved                             0x0000
   Not used in SUA                      0x0001
   Not used in SUA                      0x0002
   Not used in SUA                      0x0003
   Info String                          0x0004
   Not used in SUA                      0x0005
   Routing Context                      0x0006
   Diagnostic Info                      0x0007
   Not used in SUA                      0x0008
   Heartbeat Data                       0x0009
   Not Used in SUA                      0x000A
   Traffic Mode Type                    0x000B
   Error Code                           0x000C
   Status                               0x000D
   Not used in SUA                      0x000E
   Not used in SUA                      0x000F
   Not used in SUA                      0x0010
   ASP Identifier                       0x0011
   Affected Point Code                  0x0012
   Correlation ID                       0x0013
   Registration Result                  0x0014
   Deregistration Result                0x0015
   Registration Status                  0x0016
   Deregistration Status                0x0017
   Local Routing Key Identifier         0x0018
>  ASP Congestion                       0x0019

   The ASP/IPSP state transition diagram is shown in Figure 1.  The
   possible states of an ASP/IPSP are:

   ASP-DOWN: The remote SUA peer at the ASP/IPSP is unavailable and/or
   the related SCTP association is down.  Initially all ASPs/IPSPs will
   be in this state.  An ASP/IPSP in this state SHOULD NOT be sent any
   SUA messages, with the exception of Heartbeat, ASP Down Ack and Error
   messages.

   ASP-INACTIVE: The remote SUA peer at the ASP/IPSP is available (and
   the related SCTP association is up) but application traffic is
   stopped.  In this state the ASP/IPSP SHOULD NOT be sent any DATA or
   SSNM messages for the AS for which the ASP/IPSP is inactive.

   ASP-ACTIVE: The remote SUA peer at the ASP/IPSP is available and
   application traffic is active (for a particular Routing Context or
   set of Routing Contexts).

>  ASP-CONGESTED: The remote SUA peer at the ASP/IPSP is available and
>  application traffic is active (for a particular Routing Context or
>  set of Routing Contexts), however, the ASP is experiencing congestion
>  related to one or more Routing Contexts.

   Figure 1: ASP/IPSP State Transition Diagram, per AS

|                                     +--------------+         +---------------+
|                                     |              |  ASPST  |               |
|              +----------------------|  ASP-ACTIVE  |<------->| ASP-CONGESTED |
|              |   Other ASP/ +-------|              |         |               |
|              |   IPSP in AS |       +--------------+         +---------------+
|              |   Overrides  |           ^     |                      |
|              |              |           |     |<---------------------+
               |              |    ASPAC/ |     | ASPIA/
               |              |[ASPAC-Ack]|     | [ASPIA-Ack]
               |              |           |     v
               |              |       +--------------+
               |              |       |              |
               |              +------>| ASP-INACTIVE |
               |                      |              |
               |                      +--------------+
               |                          ^       |
        ASPDN/ |                          |     | ASPDN /
   [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
     SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
     SCTP RI   |                          |     | SCTP RI
               |                          |     v
               |                      +--------------+
               |                      |              |
               +--------------------->|   ASP-DOWN   |
                                      |              |
                                      +--------------+

   The possible states of an AS are:

   AS-DOWN:     The Application Server is unavailable.  This state
                implies that all related ASPs are in the ASP-DOWN state
                for this AS.  Initially the AS will be in this state.
                An Application Server is in the AS-DOWN state before it
                can be removed from a configuration.

   AS-INACTIVE: The Application Server is available but no application
                traffic is active (i.e., one or more related ASPs are in
                the ASP-INACTIVE state, but none in the ASP-ACTIVE
                state).  The recovery timer T(r) is not running or has
                expired.

   AS-ACTIVE :  The Application Server is available and application
                traffic is active.  This state implies that at least one
                ASP is in the ASP-ACTIVE state.

>  AS-CONGESTED: The Application Server is available and application
>               traffic is active, however at least one ASP is in the
>               ASP-CONGESTED state for the AS.

   AS-PENDING:  An active ASP has transitioned to ASP-INACTIVE or ASP-
                DOWN and it was the last remaining active ASP in the AS.
                A recovery timer T(r) SHOULD be started and all incoming
                signalling messages SHOULD be queued by the SGP.  If an
                ASP becomes ASP-ACTIVE before T(r) expires, the AS is
                moved to the AS-ACTIVE state and all the queued messages
                will be sent to the ASP.

4.3.4.7 ASP Status Procedures

  At any time that an ASP/IPSP is in the ASP-ACTIVE or ASP-CONGESTED states
  for an AS, it can send an ASP Status message updating then congestion
  level, or abatement of congestion, using the ASP Congestion parameter
  contained in the message and pertaining to the included Routing
  Context(s).

  Upon receipt of an ASP Status message, an SG/IPSP MAY take actions with
  regard to ASP congestion giving consideration for the congestion
  and active statuses of the other ASPs/IPSPs in the AS.  Actions could,
  for example, include the redirection or redistribution of traffic within
  a Load-Sharing AS.

4.3.4.8 ASP Status Qry Procedures

  At any time that an ASP/IPSP is in the ASP-ACTIVE or ASP-CONGESTED states
  for an AS, the peer SG/IPSP can send an ASP Status Qry message querying
  the congestion state of the remote ASP/IPSP for the Application Servers
  indicated by the Routing Context(s) contained in the query.

  Upon receipt of an ASP Status Query message, if the ASP/IPSP is in the
  ASP-ACTIVE or ASP-CONGESTED states for the indicated AS, the ASP/IPSP
  MUST respond with an ASP Status message indicating the current congestion
  status for the AS.  Note that because only one ASP Congestion parameter
  is contained in the ASP Status message, that multiple ASP Status messages
  might be required in response to a single ASP Status Qry message.

...etc.

Fill in your own proprietary SG practices here.

--brian

Haresign Lincoln wrote:                      (Fri, 14 Oct 2005 09:18:59)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 07:59:05 -0600

Licoln,

I have an even better one that will work today without waiting 3
or 4 years for a replacement RFC:

Stop servicing your SCTP receive buffer at the ASP (which is
what the ASP will ultimately do if it runs out of time).
 
The SG can use send buffer occupancy to determine the congestion
level of the ASP and redistribute messages or whatever.
 
Gee, that will work for stuck ASPs too!

You don't need SS7 addresses at all!  Not even Routing Contexts!
Nothing to provision! Yeah!

I think I suggested this to you before: refresh my memory as to
what your problem was with that solution...

--brian

Brian F. G. Bidulock wrote:                                                       (Fri, 14 Oct 2005 07:46:27)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 14 Oct 2005 09:48:11 -0500 (CDT)

Sigtran,
  M3UA rfc also has the same 'congestion' problem, will it be modified as
per this thread ?

--Samuel  
  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 08:58:43 -0600

Samuel,

I see what you mean: the existing congestion procedures of all MTP-Users
are woefully inadequate.  We must enhance them.  The nice thing about these
two new ASPTM messages is that, because they only use Routing Context, they
are equally applicable to M3UA.  We can even add M2UA, DUA, V5UA and IAU
too.  They also have woefully inadequate upper layer congestion mechanisms.

Perhaps you could help with defining how the ASP Congestion parameter is
different for M3UA, how it differs from MTP Congestion and MTP-User part
specific congestion mechansims, detection and procedures for responding
to the ASP Status indications?

--brian

Samuel Dur D. Jeyaseelan wrote:                  (Fri, 14 Oct 2005 09:48:11)

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