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

From: Tolga Asveren <[email-masked]>
Date: Tue, 5 Nov 2002 17:47:05 -0500

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 5 Nov 2002 19:10:15 -0800 (PST)

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

> would prefer a new ASPTM message for it.

__________________________________________________
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