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

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 09:04:13 -0500

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 4:26 AM
> To: Tolga Asveren
> Cc: [email-masked]; Tolga Asveren
> Subject: Re: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> 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.
[TOLGA] I agree for MTP3 part of your comments. 
> 
> 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
[TOLGA] Agreed, I also think the same.
> 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.
[TOLGA] That's the point where it gets interesting. It is true that ASP in
multiple-SG case has some SMH functionality (BTW, IMO this is not elegant at
all, a layer3 UA shouldn't cross PC boundaries, so I think multiple SG case
is forcing the model) But declaring congestion of ASP is not related with
outgoing message routing. It is about about local congestion status. So, for
example consider the following scenario:
       AS1:1-1-1          AS1=1-1-1
       +------+           +------+
       |ASP1  |           | ASP2 |
       |      |           |      |
       +--+--++           ++--+--+
          |  |             |  |
          |  |             |  |
          |+-+-------------+  |
          || |                |
          || +-------------+  |
          ||               |  |
      +---++-+            ++--+--+
      | SG1  |            | SG2  |
      |      |            |      |
      +---+--+            +---+--+
          |                   |
          |                   |
          |                   |
          |   --------------  |
          |///              \\|\
        //                      \\
      //                          \\
    ||                              ||
    |         SS7 Network            |
   |                                  |
   |                                  |
    |                                |
    ||                              ||
      \\                          //
        \\                      //
          \\\\              ////
              --------------
How it should work IMO:
Whenever ASP1 gets congested it informs both SG1 and SG2. Whenever there is
a message for 1-1-1, SG1 (or SG2) probably won't decide replying with TFC
but they will route it to ASP2 (I think deciding when the whole SPMC is
congested can be left as implementation dependent). So, IMO, multiple SG
case is not very different from ASP congestion indication point of view, and
I think that SCON from ASP to SG directly generated TFC is not suitable for
any configuration and for any protocol, and this congestion from ASP should
be declared when it happens not as a response to an incoming message to ASP.

> 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, 
[TOLGA] I agree for that, although it is very ugly. In fact this happen
because PC boundary is passed between ASP and SG. Personanly I like SG-SG
modelling more, when the node directly connected to TDM and the nodes in IP
domain should have different PCs. There it is not necessary that the node
connected to TDM generated RCT on behalf of other nodes.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Nov 2002 10:19:18 -0700

Tolga,

Tolga Asveren wrote:                                 (Thu, 07 Nov 2002 09:04:13)
>
> But declaring congestion of ASP is not related with outgoing message
> routing. It is about about local congestion status.

ANSI T1.111.4/2000 talks of congestion of the message routing (SMH) function.
Nevertheless, I would think that a "properly" designed ASP would push back on
the SCTP assocation (by slowing or stopping servicing its association receive
buffer) and the SG would be thus informed.

> be declared when it happens not as a response to an incoming message to ASP.

The ASP can indicate SCON as many or as few times as it likes, in response
to messages or in response to status changes: it is the SG/NIF reponsibility
to turn this into status changes and any resulting TFC messages precisely as
stated in RFC 3332 section 1.4.6.

--brian

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