Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Tolga Asveren <[email-masked]>
Date: Wed, 6 Nov 2002 08:36:52 -0500

Hi Kamesh,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 12:17 AM
> To: [email-masked]
> Cc: Tolga Asveren
> Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> 
> 
> hi
>      Tolga  I am not able to understand how TFC is similar to
>       TFP as suggested by you below, also how ASP goes 
> inactive after sending
> SCON
>       message back to SG1. Please clearify.
> 
[TOLGA] Again consider the configuration in the original message. If ASP1
goes INACTIVE for AS1, does SG send TFP to SS7 network or does ASP1 send
DUNA(this is even not allowed, it is strange that SCON is allowed from ASP
to SGP side)? It does not, because there are still other ASPs serving this
AS (i.e. the corresponding PC) -in fact one might argue that when to declare
a destination in IP domain as prohibited is implementation dependent but I
think doing it like I described is a logical way-. SG has the information
for the whole SPMC and can decide about its status. Personally I don't see a
reason, why this shouldn't apply for congestion. Whenever congestion happens
ASPs inform SG, and SG decides for the new SPMC state. When I said "This is
similar to generating TFP, because one of the ASPs goes INACTIVE for AS1.",
what I meant is, in such a case TFP is not generated and so similarly
generating TFc is also wrong. The key point is, it is SG, which has the
combined SPMC view. It can decide, when to send TFC/TFP/TFA for a SPMC, ASPs
don't have the necessary information
> Regards
> Kamesh
> 
> 
> 
> 
> Tolga Asveren <[email-masked]> on 11/06/2002 08:55:15 AM
> 
> To:   [email-masked]
> cc:    (bcc: Kamesh Kaul/HSS)
> 
> Subject:  RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> 
> 
> A correction:
> IMO, SCON should be sent to ASP2, based on RFC3332. I
> didn't pay attention that CPC = SPC of ASP2, sorry for
> that.
> But this is really an interesting scenario:
> Let's assume PC 100 was in TDM domain. In such a case,
> SG would execute relevant congestion test procedures
> on behalf of ASP2(which has sent the message causing
> TFC/SCON to be generated). And let's furthermore
> assume, this is an ANSI network. In this case, SG
> would generate RCT messages. But now what? Based on
> that one might argue introducing a SSNM counterpart
> for RCT (which is really necessary for SG-SG case but
> IMO not for ASP/SGP case)
> As indicated in my former message, following MTP3
> congestion method between SGP and ASP is not a good
> idea IMO. Like SGP combines information from ASPs and
> generates TFP/TFA/DUNA/DAVA, the same should apply
> also for TFC/SCON. Consider the following
> configuration:
>   AS1:1-1-1  AS1:1-1-1    AS1:1-1-1
>    +----+   +----+        +----+
>    |ASP1|   |ASP2|        |ASPn|
>    +-+--+   +--+-+ . . .  +--+-+
>      |         |             |
>      |         |             |
>      |         |  |  |       |
>      |         |  |  |       |
>      |    +----+--+--+--+    |
>      +----+    SG1      +----+
>           |             |
>           +-----+-------+
>                 |
>                 |
>               TDM based SS7 network
> 
> Let's say one message arrives from SS7 network with
> DPC=1-1-1 to SG1 and it routes it to one of the
> ASPs(AS mode is loadsharing for AS1)And if that ASP is
> congested because of that message SCON will be sent
> from ASP to SG and SG will generate a corresponding
> TFC. This is similar to generating TFP, because one of
> the ASPs goes INACTIVE for AS1. But if a method, where
> each ASP declares its congestion to SG, whenever it
> happens, SG has the combined SPMC view and decide-in
> an implementation dependent way-, when to reply with
> TFC(SCON if the initiator is in IP domain) to an
> incoming message destined for AS1.
> 
> 
>     Tolga
> 
> --- Tolga Asveren <[email-masked]> wrote:
> > Some comments below.
> >
> >    Tolga
> > >
> > > 6.  What should SG do in the following situation:
> > >
> > >
> > >         ASP1:  SPC 100, RC X
> > >         ASP2:  SPC 200, RC Y
> > >
> > > ASP1 sends a SCON (APC 100, CPC 200, RC X).  Does
> > > SG send a SCON to ASP2.  If so, does SG maintain
> > congestion
> > > state?  There is no way for SG to audit congestion
> > of ASP1.
> > >
> > > One recommendation:  SG sends SCON to ASP2.
> > Maintains
> > > a timer that decreases congestion level every time
> > it triggers.
> > > Further recommendation was to evaluate based on
> > end-to-end
> > > congestion principle in SS7.  Need to make sure
> > solution works
> > > equally well for ANSI and ITU.
> > [TOLGA] In such a situation, I wouldn't expect that
> > SCON is sent to ASP2,
> > based on the current RFC3332(because it is sent as
> > reply to an incoming
> > message). But as a lot of people might recall, we
> > had some discussions about
> > the current congestion announcement procedure from
> > ASP to SGP recently. I
> > think, the current approach does not fit M3UA model.
> > Trying to mimic
> > congestion mechanims of MTP3 between SGP and ASP is
> > not the correct approach
> > in my opinion. Congestion should be informed from
> > ASP to SGP, whenever it
> > happens, not as a response to an incoming message.
> > SG controls the SPMC and
> > can decide, whenever to reply with TFC or SCON to a
> > message. I furthermore
> > would prefer a new ASPTM message for it.
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
> _______________________________________________
> 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, 7 Nov 2002 02:25:53 -0700

Tolga,

ANSI T1.111.4/2000 permits a signalling end point to (optionally) send TFC
when its Signalling Message Handling (SMH) function is sufficiently congested.
ITU-T/Q.704 does not permit this.  So, we permitted the ASP to send SCON to
the SG to accommodate this; however, it is only applicable where the Signalling
Message Handling (SMH) function is implemented in the ASP.

In a single-SG configuration as that shown, the ASP is *not* responsible for
SMH functions and cannot properly send SCON to the SG (or at least the SG has
no business sending TFC in response to it).  SMH functions include message
discrimination, message distribution, message routing and signalling link
congestion.  The only configuration in which the ASP is responsible for these
MTP functions is the multiple-SG configurations, and this is the only case
that SCON was intended to be sent from ASP to SG.  In the multiple-SG
configuration, the ASP is responsible for message routing functions (at least
selection of SG) and therefore implements some part of the SMH functions.
This SMH function could congest, permitting the ASP to send SCON to the SG
(optionally) in accordance with ANSI networks.

So, the only configuration to talk about would be where ASP1 is connected to
two (or more) SGs.  This also means that the SG has the transfer function and
is operating within an ANSI network.  In this configuration ASP1(PC1) can send
SCON to SG with regard to messages from ASP2(PC2).  In this scenario, it is
fully possible for the SG to do one of the following:

  a) Discard the SCON.  It is completely optional to send TFC in ANSI networks
     in this case.  The important point is that the SEP suffering congestion
     is permitted to discard messages.

  b) Include the SCON in the SG's own determination of the congestion status
     of the point code (including in this configuration, the congestion status
     of the "signalling links" which are the associations to ASP1).  If the
     ASP properly uses SCTP flow controls (arwnd) the SG will be able to tell
     that its SMH function is impaired and also to send TFC on its behalf.

You will see this in RFC 3332 in section 1.4.6:

 "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, effectively, SCON from ASP to SG only occurs when it is optionally
generated by the ASP, when the SG is one of a pair of SGs acting as STP, and
when the SG is in an ANSI network, and when the SG optionally decides to do
something about the SCON, an only when the SG can determine from some other
unspecified means that the SPMC (Affected Point Code) is congested (and
supposedly then can determine when congestion abates so that it can properly
respond to signalling route set congestion test messages on behalf of the
ASP): only then, may the SG generate a TFC (which is optional in the ANSI
specifications).

The presumption here is that the SG can determine through some means (other
than just the SCON) that the SPMC is congested.  Thus the SG is in a position
to respond to signalling route set congestion test messages from the SS7
network, as well as to respond to DAUD or to generate SCON indicating
congestion abatement to other ASPs.

It is the responsibility of the NIF at the SG to interwork route set
congestion procedures in SS7 with the procedures of M3UA, and *not* the ASP's
responsibility.  The SCON from ASP to SG is rather useless, but might provide
some SG implementations with better information to perform this interworking.
Of course, specification of the NIF was well outside the scope of RFC 3332.

--brian

Tolga Asveren wrote:                            (Wed, 06 Nov 2002 08:36:52)

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