Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP separat e

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 16 Oct 2001 08:54:52 -0500

Resending ....

Hi,

Just to make my question a little bit more attractive consider the following scenarios:
(In all of the scenarios SGP1 and SGP2 are belonging to the same logical SG, ASP1 and ASP2 are serving AS1)
1)
  
  +------------+       +------------+
  |            |       |            |
  |    ASP1    |       |    ASP2    |
  |            |       |            |
  +-----+--+---+       +---+----+---+
        |  |               |    |
        |  |               |    |
        |  X               |    |
        X  +------------+  |    |
        |  +------------+--+    |
        |  |            |       |
        |  |            |       |
        |  |            |       |
  +-----+--+----+      ++-------+---+
  |             |      |            |
  |     SGP1    |      |    SGP2    |
  |             |      |            |
  +-------------+      +------------+

In this scenario association between ASP1-SGP1 and ASP1-SGP2 is broken (or ASP1 goes down). Now, NTFY(AS-Pending) will be send to ASP2, but both from SGP1 and SGP2 or just from one of them?

2)
a)
 
    +-------------+
    |             |
    |    ASP1     |
    |  (Override) |
    |             |
    +---+-----+---+
        |     |
        |     |
        |     |
        |     +----------------+
        |                      |
        |                      |
    +---+---------+       +----+-------+
    |             |       |            |
    |             |       |            |
    |   SGP1      |       |  SGP2      |
    |             |       |            |
    +-------------+       +------------+

a) is a quite normal case, one ASP connected to two SGPs.

b)

  +-------------+      +-------------+
  |             |      |             |
  |    ASP1     |      |   ASP2      |
  |   (Override)|      |  (Override) |
  |             |      |             |
  +---+-----+---+      +---------+---+
      |     |                    |
      |     |                    |
      |     |                    |
      |     +----------------+   |
      |                      |   |
      |                      |   |
  +---+---------+       +----+---+---+
  |             |       |            |
  |             |       |            |
  |   SGP1      |       |  SGP2      |
  |             |       |            |
  +-------------+       +------------+

Now a second ASP (ASP2) send ASPAC(AS1) and receives ASPACACK(as1) from SGP2. NTFY(Alternate ASP active) will be sent only by one SGP or by both of the SGPs?

3)
a)

   +-----------+
   |           |
   |   ASP1    |
   | (override)|
   +-----+-----+
         |
         |
         |
         |
   +-----+-----+        +------------+
   |           |        |            |
   |   SGP1    |        |   SGP2     |
   |           |        |            |
   +-----------+        +------------+

Again SGP1 and AGP2 are belonging to the same SG. But ASP1 has connection to only SGP1.

b)

  +-----------+        +------------+
  |           |        |            |
  |   ASP1    |        |  ASP2      |
  | (override)|        | (override) |
  +-----+-----+        +-----+------+
        |                    |
        |                    |
        |                    |
        |                    |
  +-----+-----+        +-----+------+
  |           |        |            |
  |   SGP1    |        |   SGP2     |
  |           |        |            |
  +-----------+        +------------+

Now a second ASP(ASP2) sends ASPAC(AS1) and receives ASPACACK(AS1) to and from SGP2. I assume SGP1 should send NTFY(alternate ASP active) to ASP1.

    Tolga

> -----Original Message-----
> From: Asveren, Tolga 
> Sent: Monday, October 15, 2001 9:07 AM
> To: sigtran
> Subject: m3ua v09 :NOTIFY message once fro SG or for every 
> SGP separate
> 
> 
> From 3.8.2 and 4.3.4.6 it was not clear to me whether NOTIFY 
> should be sent
> once per SG or for every SGP. Which approach is taken in draft09?
> 
>    Tolga
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 16 Oct 2001 08:24:31 -0500

Hi,

Just to make my question a little bit more attractive consider the following
scenarios:
(In all of the scenarios SGP1 and SGP2 are belonging to the same logical SG,
ASP1 and ASP2 are serving AS1)
1)

In this scenario association between ASP1-SGP1 and ASP1-SGP2 is broken (or
ASP1 goes down). Now, NTFY(AS-Pending) will be send to ASP2, but both from
SGP1 and SGP2 or just from one of them?

2)
a)
 
    +-------------+
    |             |
    |    ASP1     |
    |  (Override) |
    |             |
    +---+-----+---+
        |     |
        |     |
        |     |
        |     +----------------+
        |                      |
        |                      |

b)

Now a second ASP (ASP2) send ASPAC(AS1) and receives ASPACACK(as1) from
SGP2. NTFY(Alternate ASP active) will be sent only by one SGP or by both of
the SGPs?

3)
a)

   +-----------+
   |           |
   |   ASP1    |
   | (override)|
   +-----+-----+
         |
         |
         |
         |

Again SGP1 and AGP2 are belonging to the same SG. But ASP1 has connection to
only SGP1.

b)

Now a second ASP(ASP2) sends ASPAC(AS1) and receives ASPACACK(AS1) to and
from SGP2. I assume SGP1 should send NTFY(alternate ASP active) to ASP1.

    Tolga

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 16 Oct 2001 14:25:38 -0400

Tolga,

Based on the definition of Signaling Gateway:

Where an SG contains more than one SGP, the 
SG is a logical entity and the contained SGPs 
are assumed to be coordinated into a single 
management view to the SS7 network and to 
the supported Application Servers.

It seems that a Notify from just one of the SGPs would be necessary.

Regards,

Ken

At 08:24 AM 10/16/01 -0500, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 16 Oct 2001 14:14:29 -0500

Hi,

Please see comments/questions below.

  Tolga

> From: Ken Morneault [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 2:26 PM
> To: sigtran
> Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
> separat e
> 
> 
> 
> 
> Tolga,
> 
[TOLGA] I also think the same way. But this is not well explained in the
draft. For example, for SSNM messages this is said explicitly "The DUNA
message is sent from an SGP in an SG to all concerned ASPs to indicate that
the SG has determinded that one ...." But in 3.8.2 there is no word of SG. I
think it can be said also more clearly as in the case for SSNM messages.
And also what about ASPSM and ASPTM messages? I assume they are also
sent/received once to/from SG.

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 13:08:38 +0200

Hi Tolga, 

I can not see where it is not clear... It is always said that an SGP sends the NOTIFY message... The approach is that one SGP as a representant of the whole SG sends it to all the affected ASPs, since it is informing of some AS or ASP change.

Do you think it needs a more specific text?

Cheers // Javier.

> From: Asveren, Tolga [mailto:[email-masked]]
> Sent: Monday, October 15, 2001 3:07 PM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 07:48:53 -0500

Hi Javier,

My point is, for SSNM messages it is said explicity "SG has determined that
one or more destinations are unreachable" etc. Maybe something similar can
be more clarifying.
On the defination for Signaling Gateway it is said "Where an SG contains
more than one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7 network
and to the supported Application Servers". Does this mean that also ASPSM
and ASPTM messages are sent only once by an SGP as representative of the
whole SG? The discussion was always about SSNM messages so it is not very
clear to me where the boundary of "single management view" is.

   Tolga

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 7:09 AM
> To: sigtran
> I can not see where it is not clear... It is always said that 
> an SGP sends the NOTIFY message... The approach is that one 
> SGP as a representant of the whole SG sends it to all the 
> affected ASPs, since it is informing of some AS or ASP change.
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 07:59:01 -0500

Tolga,

The boundary to the single management view is the SS7 network.

--brian

Asveren, Tolga wrote:                                    (Wed, 17 Oct 2001 07:48:53)
> assumed to be coordinated into a single management view to the SS7 network
                                   =========================================
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 08:09:17 -0500

Hi Brian,
Does what you say correspond that everything else SSNM should be sent by all of the SGPs not just by one SGP?

   Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 8:59 AM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: m3ua v09 :NOTIFY message once fro SG or for every SGP
> separat e
> 
> 
> Tolga,
> 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 15:18:52 +0200

Hi, 

You can see the SG as a single MTP3 layer with several M3UA processing layers (one SG that consist of several SGPs).  But all the SGPs have to share the same information. And any of them are seeing from the ASP point of view as an SG process. In that way, only one SGP has to deal with each communication with any ASPs. It's sharing work, not duplicating it.

Cheers / Javier.

> Sent: Wednesday, October 17, 2001 3:09 PM
> To: sigtran
> Does what you say correspond that everything else SSNM should 
> be sent by all of the SGPs not just by one SGP?
> 
>    Tolga
> 
> [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 08:58:40 -0500

Hi Javier,

Now which messages are sent by only one SGP and which are sent by all of them
SSNM (only one, this was discussed)
ASPSM (?)
ASPTM(?)

It seems you think that also ASPSM and ASPTM should be sent only once, or did I misunderstand?

  Tolga

> Sent: Wednesday, October 17, 2001 9:19 AM
> To: sigtran
> You can see the SG as a single MTP3 layer with several M3UA 
> processing layers (one SG that consist of several SGPs).  But 
> all the SGPs have to share the same information. And any of 
> them are seeing from the ASP point of view as an SG process. 
> In that way, only one SGP has to deal with each communication 
> with any ASPs. It's sharing work, not duplicating it.
> 
> Cheers / Javier.
> 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 16:20:13 +0200

Hi Tolga, 

All the messages are directed to an SGP since this is an instance (OO language) of the whole SG. If you send a broadcast, you are overloading the network and you don't get any benefit if you have communication mechanism amongst the different SGP to keep consistent state information.

Cheers // Javier.

> Sent: Wednesday, October 17, 2001 3:59 PM
> To: sigtran
> [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 09:30:07 -0500

Hi Javier,

My intention is not to disagree with the approach in the draft (maybe I can disagree after it is clear to me what is meant exactly :) ). 
So, your answer for all of them is YES.
For example ASP will send ASPUP only to one of the SGPs.

   Tolga

> Sent: Wednesday, October 17, 2001 10:20 AM
> To: sigtran
> All the messages are directed to an SGP since this is an 
> instance (OO language) of the whole SG. If you send a 
> broadcast, you are overloading the network and you don't get 
> any benefit if you have communication mechanism amongst the 
> different SGP to keep consistent state information.
> 
> Cheers // Javier.
> 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 17:01:04 +0200

Hi Tolga, 

That's really good. If you think it is not the right approach, you can also make your point... :-)

What I was saying was what you state : an ASP will send ASPUP only to one of the SGPs

:-D

Cheers //  Javier.

> Sent: Wednesday, October 17, 2001 4:30 PM
> To: sigtran
> My intention is not to disagree with the approach in the 
> draft (maybe I can disagree after it is clear to me what is 
> meant exactly :) ). 
> > > > > > > My point is, for SSNM messages it is said 
> explicity "SG has 
> > > > > > determined that
> > > > > > > assumed to be coordinated into a single 
> management view to 
> > > > > > the SS7 network
> > > > > >                                    
> > > > > > > whole SG? The discussion was always about SSNM 
> messages so 
> > > > > > it is not very

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 13:44:27 -0500

Tolga,

Because the SGP now has a way of having traffic withdrawn (unsolicited
ASPIA Ack), we no longer need the per-SGP DUNA/DRST that we were talking
about for v7/8.  DUNA/DRST/... when sent by one SGP applies to an entire
AS (MTP-User) and must be consistent with the view presented by other SGP.

When an ASP receives an SNMM from an SGP it should treat it as having
SG-scope.  Each SGP could send their own SNMM, but each would just apply
to the entire SG.

Sound right?

--brian

Asveren, Tolga wrote:                                    (Wed, 17 Oct 2001 08:09:17)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 13:59:46 -0500

Brian,

With SSNM there is no problem, but I think you are saying ASPIA-ACK is per SGP (not per SG). I think , this means you are saying ASPTM-ASPSM is per SGP?
Just to make clear, now I am just trying to understand what is said in the draft and if you really say that ASPTM-ASPSM is per SGP, then I think there is a problem because two of the authors of the draft are interpreting it in different ways :) (Brian: ASPTM-ASPSM per SGP (correct me if I misinterprete it) , ASPTM-ASPSM per SG)
Otherwise I agree that ASPIA-ACK makes per SGP DUNA/DRST/... unnecessary.

   Tolga

> Sent: Wednesday, October 17, 2001 2:44 PM
> To: Asveren, Tolga
> Cc: sigtran
> > Does what you say correspond that everything else SSNM 
> should be sent by all
> > of the SGPs not just by one SGP?
> > 
> >    Tolga
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 14:11:26 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 17 Oct 2001 17:01:04)
> What I was saying was what you state : an ASP will send ASPUP only to one of

No way!  The single management view stops at SNMM.  An ASP must send ASP UP
to each SGP on each association that it forms!  That is not even in dispute.
It has always been the case.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 17 Oct 2001 14:54:18 -0500

Brian,

What about NTFY? Per SG or per SGP?

Tolga

> Sent: Wednesday, October 17, 2001 3:23 PM
> To: Asveren, Tolga
> Cc: sigtran
> Asveren, Tolga wrote:                                    
> (Wed, 17 Oct 2001 13:59:46)
> > Brian,
> > 
> > With SSNM there is no problem, but I think you are saying 
> ASPIA-ACK is per
> > SGP (not per SG).  I think , this means you are saying 
> ASPTM-ASPSM is per
> > SGP?
> 
> Yes.  It is and always has been.
> 
> > Just to make clear, now I am just trying to understand what 
> is said in
> > the draft and if you really say that ASPTM-ASPSM is per 
> SGP, then I think
> > there is a problem because two of the authors of the draft 
> are interpreting
> > it in different ways :) (Brian: ASPTM-ASPSM per SGP (correct me if I
> > misinterprete it) , ASPTM-ASPSM per SG) Otherwise I agree 
> that ASPIA-ACK
> > makes per SGP DUNA/DRST/... unnecessary.
> 
> ASPTM/SM was never intended to be anything but per-SGP.  All messages
> only apply within the context of an association (between one SGP and
> one ASP).  SNMM used to be per-SGP but we changed it back to per-SG
> (but can be sent by each SGP).
> 
> --brian
> 
> > 
> >    Tolga
> > 
> > You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 17:42:01 -0500

Tolga,

NTFY notifies of a particular SGP's view of the AS and ASP
state.  A particular ASP can be in different states with
different SGPs.  An ASP cannot be UP to an SGP unless it
has an association to the SGP and has performed ASP UP
procedures with the SGP.

Therefore, NTFY is per SGP.

--brian

Asveren, Tolga wrote:                                    (Wed, 17 Oct 2001 14:54:18)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 08:16:20 -0500

Brian (and the others),

Let me summarize what I currently understand from the draft and after some message exchange on the forum:
SGPs of a SG are a single entity from MTP3 point of view. But except SSNM they are acting individually in M3UA domain. According to me, the most impirtant feature of SGP concept was, that SGPs are sharing AS state information among themselves. So, even if they send NTFYs individually, when they are going to send it is coordinated between SGPs forming a logical SG. I only disagree with Brian's statement that "NTFY notifies of a particular SGP's view of the AS and ASP state". I interprete NTFY as a notification of the global AS state. If there is a one SGP SG, of course, this will be the local view of this SGP but otherwise it will be the combined vieew of the SGPs in the SG. So, even if NTFY is sent by all of the SGPs, it will contain the same AS state.

Just before draft9, there was a consensus on having SSNM per SG, instead of per SGP. But now, this does not sound to me totallt right, because, SGPs are forming a unique entity in M3UA domain or not. But everything else than SSNM is still per SGP. What is the reason behind that? I think, important point is to decide, being active/inactive for a routing key is an attribute of an association or of a M3UA entity. IMHO, it is an attribute of an M3UA entity. So, if SGPs are forming a single M3UA entity, why not to have ASPTM per SG, instead of SGP? But I also have to say, I don't see any significant improvement with this approach (just not to send some messages multiple times but I think they will be a very small percentage of the whole message exchange between ASP and SGP) and the disadvantage is that it will complicate ASP. Because now ASP needs to know which SGPs are belonging to the same SG. Here the important thing is that the advantage and disadvantage is the same for SSNM.!
 I don't see any other benefit than not to send SSNM multiple times, which contains the same information, from different SGPs, when we make it per SG. And it brings the same complication to ASP side. Extra configuration and implementation. If SSNM is per SGP, then ASP does not need to know, which SGPs are belonging to the same SG. 

So, one can ask, if we return also SSNM back to per SGP, what is the meaning of to have SGPs instead of just SGs (or SGs with one SGPs). Like said at the beginning of the message, it is that they are sharing AS state information among themselves. So, although they will send separate NTFYs, it will have the global information, and this is again important to make logic at ASP more simple. If this change is done, then we don't need to say that SGPs are forming a single M3UA entity, just they are sharing AS state information.

     Tolga

> Sent: Wednesday, October 17, 2001 6:42 PM
> To: sigtran
> (Wed, 17 Oct 2001 14:54:18)
> > Brian,
> > 

---

---

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Oct 2001 09:18:41 -0700

Hi   

I have some basic doubt about multiple SGPs.

M3UA draft says that an SG can have multiple SGPs.
These SGPs will need to share some state (how toshare is
implementation dependent). For some procedures, event from
one SGP is to be interpreted as representative of whole
SG e.g SSNM messages. For some procedures, each SGP 
responds individually .....

All this is making M3UA and our life real complicated here.

Why don't we view SG as one instance i.e. comprising of just 
one SGP. If ASPs want, they can have multiple associations 
with same SG. How exactly an SG is made fault-tolerant or
distributed (SG running on multiple hosts) should be left
completely to the implementation. Mixing of the fault-tolerant and 
distributed architectures without detailed description about 
handling of all the scenarios is causing much trouble.

For legacy SS7 protocols( e.g TCAP,SCCP,MTP3 etc) ITU has just 
specified protocol with one instance of the process. This has
made implementing these quite easier (everything is covered in
detail). But  telcos are running these in fault/tolerant as well as
distributed manner using their own implementations. 

Implementing  distributed  MTP3 is easier than M3UA with multiple 
instances(e.g multiple SGPs) because M3UA discusses somethings
about distribution but leaves too many questions and doubts
unanswered.

regards
Umesh Vats

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 6:16 AM
To: sigtran
Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
separat e

Brian (and the others),

Let me summarize what I currently understand from the draft and after some
message exchange on the forum:
SGPs of a SG are a single entity from MTP3 point of view. But except SSNM
they are acting individually in M3UA domain. According to me, the most
impirtant feature of SGP concept was, that SGPs are sharing AS state
information among themselves. So, even if they send NTFYs individually, when
they are going to send it is coordinated between SGPs forming a logical SG.
I only disagree with Brian's statement that "NTFY notifies of a particular
SGP's view of the AS and ASP state". I interprete NTFY as a notification of
the global AS state. If there is a one SGP SG, of course, this will be the
local view of this SGP but otherwise it will be the combined vieew of the
SGPs in the SG. So, even if NTFY is sent by all of the SGPs, it will contain
the same AS state.

Just before draft9, there was a consensus on having SSNM per SG, instead of
per SGP. But now, this does not sound to me totallt right, because, SGPs are
forming a unique entity in M3UA domain or not. But everything else than SSNM
is still per SGP. What is the reason behind that? I think, important point
is to decide, being active/inactive for a routing key is an attribute of an
association or of a M3UA entity. IMHO, it is an attribute of an M3UA entity.
So, if SGPs are forming a single M3UA entity, why not to have ASPTM per SG,
instead of SGP? But I also have to say, I don't see any significant
improvement with this approach (just not to send some messages multiple
times but I think they will be a very small percentage of the whole message
exchange between ASP and SGP) and the disadvantage is that it will
complicate ASP. Because now ASP needs to know which SGPs are belonging to
the same SG. Here the important thing is that the advantage and disadvantage
is the same for SSNM.!
 I don't see any other benefit than not to send SSNM multiple times, which
contains the same information, from different SGPs, when we make it per SG.
And it brings the same complication to ASP side. Extra configuration and
implementation. If SSNM is per SGP, then ASP does not need to know, which
SGPs are belonging to the same SG. 

So, one can ask, if we return also SSNM back to per SGP, what is the meaning
of to have SGPs instead of just SGs (or SGs with one SGPs). Like said at the
beginning of the message, it is that they are sharing AS state information
among themselves. So, although they will send separate NTFYs, it will have
the global information, and this is again important to make logic at ASP
more simple. If this change is done, then we don't need to say that SGPs are
forming a single M3UA entity, just they are sharing AS state information.

     Tolga

> > What about NTFY? Per SG or per SGP?

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 12:16:55 -0500

Hi Umesh,

Just to make clear, I think SGP concept is usefull, when they share AS states. Here the discussion is more about how to handle the messages, per SG or per SGP. I think the draft is not forcing anybody to implement SGs consisting of multiple SGs. If one wants, one can have always SGs consisting of single SGPs. 

   Tolga

> From: Vats, Umesh [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 12:19 PM
> To: sigtran

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 12:18:48 -0500

small correction  ===> "I think the draft is not forcing anybody to
implement SGs consisting of multiple SGPs" 

  Tolga

> Sent: Thursday, October 18, 2001 1:17 PM
> To: sigtran
> Just to make clear, I think SGP concept is usefull, when they 
> share AS states. Here the discussion is more about how to 
> handle the messages, per SG or per SGP. I think the draft is 
> not forcing anybody to implement SGs consisting of multiple 
> SGs. If one wants, one can have always SGs consisting of single SGPs. 
> 
>    Tolga
> 

---

---

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Oct 2001 11:45:29 -0700

Hi  Tolga

The problem with current draft is that it allows only one 
association between a pair of SGP and ASP. Today if we have 
an SG with just one SGP, a single point of failure between SG 
and ASP results (only one SCTP board handles one association. 
If this board  fails, the connectivity between SG and ASP
breaks). 

To take care  of this, M3UA draft tells that ASP can connect
with multiple  SGPs through separate associations. 

If instead, multiple associations between SG-ASP pairs were
possible, then one could easily implement an SG with one 
SGP(with SGP distributed in an implementation dependent way)
and multiple associations for each ASP as shown in figure below : 
             
             -------------------------               -------- 
             | Single SGP distributed|---------------|      |
             | in implementaion      |---------------| ASP  |  
             |  dependent way        |               |      |
             -------------------------               --------

Then M3UA protocol will become real simple. 

regards
Umesh Vats

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 10:17 AM
To: sigtran
Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
separat e

Hi Umesh,

Just to make clear, I think SGP concept is usefull, when they share AS
states. Here the discussion is more about how to handle the messages, per SG
or per SGP. I think the draft is not forcing anybody to implement SGs
consisting of multiple SGs. If one wants, one can have always SGs consisting
of single SGPs. 

   Tolga

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 13:53:40 -0500

Hi Umesh,

I think there is a difference between your and mine interpretation of the draft. As far as I know multiple SCTP associations between M3UA entities is possible. I favor SGP concept, because it can hide SG-side host failures -not interface failures- from ASP side to some extent.

   Tolga

> Sent: Thursday, October 18, 2001 2:45 PM
> To: sigtran

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 14:15:34 -0500

resending.....

Hi Umesh,

I think there is a difference between your and mine interpretation of the
draft. As far as I know multiple SCTP associations between M3UA entities are
possible. I favor SGP concept, because it can hide SG-side host failures
-not interface failures- from ASP side to some extent.

   Tolga

---

---

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Oct 2001 12:42:48 -0700

Hi  Tolga

As per my understanding till now , between one SGP and ASP, only
one association can exist. An SGP may have associations
with multiple ASPs. If multiple associations between single
SGP and single ASP can exist, then how will these association 
be managed ? Will ASP send data to SGP on different associations 
in loadsharing manner or how ?

Regarding your comment below :
I favor SGP concept, because it can hide SG-side host failures -not
interface failures- from ASP side to some extent.

Hiding host side failures should be prime motive of the
developer. I agree with that. What I want to emphasise is 
that this should be left to the implementation. If we
want high reliability/fault-tolerance/high-availability,
we can implement it in our own implementation dependent way.
The problem is happening because the M3UA draft touches the
distribution related logic but doesn't define it completely.
This results in too many unanswered issues.

Umesh 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 11:54 AM
To: sigtran
Subject: RE: m3ua v09 :NOTIFY message once fro SG or for every SGP
separat e

Hi Umesh,

I think there is a difference between your and mine interpretation of the
draft. As far as I know multiple SCTP associations between M3UA entities is
possible. I favor SGP concept, because it can hide SG-side host failures
-not interface failures- from ASP side to some extent.

   Tolga

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 14:54:43 -0500

Hi Umesh,

Regarding multiple associations between multiple M3UA entities, I don't
favor this approach but as far as I know it is allowed in the draft. I think
with ASPTM messages, you can use those associations as you want.
And apart from this, with SCTP one has multihoming feature against
interface-failures.
Now for implementing high-redundancy in an implementation dependent way,
interaction among SGPs is already implementation dependent. But as long as
the relationship between ASP-SG is concerned, it should be defined in the
draft, otherwise how can an ASP know, what to expect from a SG consisting of
multiple SGPs?

      Tolga

> Sent: Thursday, October 18, 2001 3:43 PM
> To: sigtran

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 15:02:10 -0500

Hi,

It can sound strange but just now while posting another message I realized
that one of my ideas is not well matching with the draft. That's whether
being active/inactive for a route key is an attribute of a M3UA entity or of
an association.
Because multiple associations are allowed between two M3UA entities
(although I don't like this approach, it is allowed in the draft and I think
people are using it, still I would be thankfull if somebody can explain to
me why supporting thi sapproach is necessary and what we can't do without
it) I think the more flexible interpretation should be that it is an
attribute of the assocaition (so that one can use different associations for
different routekey traffic). 

So, if ASPTM/ASPSM is per SGP, -although DPC reachability is an attribute of
SG- I still think it is worth to reconsider to return back to SSNM per SGP,
so ASP side again does not need to know which SGPs are belonging to which
SG.

   Tolga

> Sent: Thursday, October 18, 2001 9:16 AM
> To: sigtran
> Let me summarize what I currently understand from the draft 
> and after some message exchange on the forum:
> SGPs of a SG are a single entity from MTP3 point of view. But 
> except SSNM they are acting individually in M3UA domain. 
> According to me, the most impirtant feature of SGP concept 
> was, that SGPs are sharing AS state information among 
> themselves. So, even if they send NTFYs individually, when 
> they are going to send it is coordinated between SGPs forming 
> a logical SG. I only disagree with Brian's statement that 
> "NTFY notifies of a particular SGP's view of the AS and ASP 
> state". I interprete NTFY as a notification of the global AS 
> state. If there is a one SGP SG, of course, this will be the 
> local view of this SGP but otherwise it will be the combined 
> vieew of the SGPs in the SG. So, even if NTFY is sent by all 
> of the SGPs, it will contain the same AS state.
> 
> Just before draft9, there was a consensus on having SSNM per 
> SG, instead of per SGP. But now, this does not sound to me 
> totallt right, because, SGPs are forming a unique entity in 
> M3UA domain or not. But everything else than SSNM is still 
> per SGP. What is the reason behind that? I think, important 
> point is to decide, being active/inactive for a routing key 
> is an attribute of an association or of a M3UA entity. IMHO, 
> it is an attribute of an M3UA entity. So, if SGPs are forming 
> a single M3UA entity, why not to have ASPTM per SG, instead 
> of SGP? But I also have to say, I don't see any significant 
> improvement with this approach (just not to send some 
> messages multiple times but I think they will be a very small 
> percentage of the whole message exchange between ASP and SGP) 
> and the disadvantage is that it will complicate ASP. Because 
> now ASP needs to know which SGPs are belonging to the same 
> SG. Here the important thing is that the advantage and 
> disadvantage is the same for SSNM.!
>  I don't see any other benefit than not to send SSNM multiple 
> times, which contains the same information, from different 
> SGPs, when we make it per SG. And it brings the same 
> complication to ASP side. Extra configuration and 
> implementation. If SSNM is per SGP, then ASP does not need to 
> know, which SGPs are belonging to the same SG. 
> 
> So, one can ask, if we return also SSNM back to per SGP, what 
> is the meaning of to have SGPs instead of just SGs (or SGs 
> with one SGPs). Like said at the beginning of the message, it 
> is that they are sharing AS state information among 
> themselves. So, although they will send separate NTFYs, it 
> will have the global information, and this is again important 
> to make logic at ASP more simple. If this change is done, 
> then we don't need to say that SGPs are forming a single M3UA 
> entity, just they are sharing AS state information.
> 
>      Tolga
> 

---

---

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Oct 2001 14:15:57 -0700

Hi  Tolga

>And apart from this, with SCTP one has multihoming feature against

Regarding multiple asociation support, I am not sure.
I don't know whether same SCTP has to take care of multihoming or not.
If same SCTP instance has to take care of it, then it still presents one
point of failure(unless implementation dependent fault-tolerant) SCTP is
used.

>draft, otherwise how can an ASP know, what to expect from a SG consisting
of

In the current architecture(draft 9), each SGP of SG provides similar 
functionality to the ASPs. My point is, if we define an SG as a single 
SGP, ASPs need not worry about connecting with multiple SGPs. ASPs  need 
to manage their association with just one  SGP. Internally, SGP(or SG) can
be 
distributed on separate processors(in implementation dependent way).
From the draft, we can just remove the concept if multiple SGPs in SG.

SGPs need to communicate with one another in implentation dependent way in
both the architectures. Why not make it completely implementation dependent 
and avoid all the issues that arise with ASPs registering with multiple SGPs
?
In this architecture, as ASP will always view SG as one SGP :
 a. ASP will need to manage association(s) with just one SGP.
 b. If allowed, ASP can have multiple associations with SGP to
    take care of path redundancy.
 c. ASP can receive SSNM messages from only one SGP. This avoids
    maintaining status about accessibility of SS7 nodes via multiple SGPs.
 d. ASP will need to manage ASPTM/ASPSM messages from just one SGP.
 e. ASP gets same performance as  it got in case of multiple SGPs.
 f. The SG implementation becomes easier as now it need not worry about
    interworking issues with ASPs that may occur in a scenario where SG 
    comprises of multiple SGPs. 

The architecture discussed above achieves all that is achieved using
the architecture mentioned in M3UA draft 9. The difference is, ease 
of implementation at both SGP and ASP ends. The second difference is
less number of interworking issues betweeb SGPs and ASPs.

regards
Umesh

> > > except SSNM
> > > a logical SG.
> > > vieew of the
> > > SG, instead of
> > > messages multiple
> > > times, which
> > > is the meaning

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 16:23:39 -0500

Tolga,

The SGP concept has always been symmetrical to the ASP concept.
It is just that there are no (few) SGP management procedures or
messages.  An SGP "serves as an active, backup, loadsharing or
broadcast process of a Signalling Gateway." Also, take another
look at section 1.4.4.2.

Just as ASPTM/SM message are on a per-ASP basis, they are also
on a per-SGP basis.  However, this does not stop an
implementation from making all the SGP identical in both state
and event.  This allows both models: distributed and monolithic
whether there are multiple associations or not.

As the model is quite flexible, you have to make some choices
when implementing.  However, if the basic premise that an SGP
and an ASP are SCTP endpoints is maintained, the result will be
interoperable.

As to SNMM, although we have recommended that an ASP take a
single network view (SHOULD) we have not required it (MUST).
So, for example, if an ASP receives DUNA(1-2-3) from one SGP in
an SG, it can assume that 1-2-3 is unreachable from all SGPs in
the SG.  This does not stop other SGPs from sending DUNA(1-2-3)
to that ASP also.  It just means that the ASP can make
assumptions off of the first one.

Since this has received a lot of discussion lately, perhaps a
line of attack would be to identify what you feel needs to be
changed in the draft and why.  If it is just a matter of
confusion over the flexibility in the draft, perhaps a few
examples (e.g., multiple SGP examples in section 5) would cover
the problem.  If there are some requirements that need to be
changed in the draft, what requirements is there a problem with?

Can we come up with an example situation that would highlight
the difficulties you are having?

--brian

Asveren, Tolga wrote:                                    (Thu, 18 Oct 2001 15:02:10)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 16:34:09 -0500

Hi Umesh,

Please see comments below.

  Tolga

> Sent: Thursday, October 18, 2001 5:16 PM
> To: sigtran
> >favor this approach but as far as I know it is allowed in 
> the draft. I
> think
[TOLGA] I am sure :) 
> point of failure(unless implementation dependent 
[TOLGA] SCTP can make use of multiple IP addresses with multihoming feature. In that case, you are using different hardware interfaces, although you have a single SCTP entity.
> >draft, otherwise how can an ASP know, what to expect from a 
> SG consisting
> of
> >multiple SGPs?
> 
[TOLGA] I don't think this restriction currently exists. You can have associations to multiple SGs and all of them can consists of multiple SGPs.
>     maintaining status about accessibility of SS7 nodes via 
[TOLGA] SGPs are forming a single MTP3 entity, this is the real reason why SSNM per SG is enough. But still if you are connected to more than one SG, it is highly possible that your implementation will require to maintain an accessibility table.
> less number of interworking issues betweeb SGPs and ASPs.
[TOLGA] What you propose is the same what is explained in draft9 except d. In draft9 ASPTM/ASPSM is per SGP. ALthough I also was thinking at the beginning like you, now I favor the approach in the draft more because it allows to use different asociations for different route keys among two M3UA entities. Some people are using this, to understand to which AS the traffic is belonging to (as I said before many times, I don't like this approach but currently it exists).

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 16:46:53 -0500

resending....

Hi Umesh,

  Tolga

[TOLGA] I am sure :) 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 17:30:29 -0500

Umesh,

Please see comments below...

Vats, Umesh wrote:                                          (Thu, 18 Oct 2001 14:15:57)
> less number of interworking issues betweeb SGPs and ASPs.

You have just swapped the concept of SGP for the concept of association.
All the same procedures need to be performed to achieve host redundancy
for SCTP.  Now it will just be between associations rather than between
SGP.  SGP is defined as an SCTP endpoint, so all that you have done is
changed terminology.  SGP would now be multiple SCTP endpoints and the
ASP would have to distribute and manage traffic and state across these
endpoints in the same manner as it did across SGP.  There is no reason
to just change terminology now.

Consider an SGP as an SCTP endpoint and you won't have a problem.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 18 Oct 2001 19:31:14 -0500

Brian,

Thanks for explanations/clarifications. I hope those thinks will be
explained also in the draft in a clear way. Currently one has to take
"Introduction to Fortunetelling" course to intepret it correctly :)
Please see commnets/questions below.

  Tolga

> Sent: Thursday, October 18, 2001 5:24 PM
> To: sigtran
[TOLGA] I agree, it is better to keep being up/down/active/inactive as
attributes of associations. This bring more flexibilitya and keeps things as
it is. And also makes the concepts of ASP/SGP look symmetrical.
> assumptions off of the first one.
[TOLGA] That is the interesting point.        

                 +-----------+
                 |           |
                 |    ASP1   |
                 |           |
                 +-+--+----+-+
                   |  |    |
                   |  |    |
                   |  |    +---------------------+
                   |  +-------+                  |
                   |          |                  |
  xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  x      +---------+--+ x x  ++-----------+   +--+---------+    x
  x      |            | x x  |            |   |            |    x
  x      |  SGP3      | x x  |   SGP1     |   |    SGP2    |    x
  x      |            | x x  |            |   |            |    x
  x      |            | x x  |            |   |            |    x
  x      +------------+ x x  +------------+   +------------+    x
  x                     x x                                     x
  x                     x x                                     x
  x       SG2           x x              SG1                    x
  x                     x x                                     x
  xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ASP1 receives DUNA from SGP1. Lets assume SG1 is sending SSNM per SG, so
only one DUNA is sent. ASP1 should know that SGP1 and SGP2 are belonging to
the same SG, so it can inteprete DUNA correctly. It is effective both for
SGP1 and SGP2 but not for SGP3. This brings the problem, that on ASP-side,
it should be configured, which SGPs are part of the same SG. This means
extra configuration. Here, I see three different approaches:
1- Accept the situation and implement the extra logic on ASP
2- Force in the draft that all of the M3UA entities an ASP is connected to
are working as SGPs, which are part of the same SG
3- Send SSNM per SGP.
Probably 2- is too restrictive.

If we examine another example, 3- will change unfortunately to another
alternative.

                      +--------------+
                      |              |
                      |    ASP1      |
                      |              |
                      ++-------+----++
                       |       |    |
             +---------+       X    |
             |                 |    +--------------+
             |                 |                   |
  xxxxxxxxxxx|xxxxxxxxxxx xxxxx|xxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxx
  x      +---+--------+ x x  +-+----------+   +----+-------+    x
  x      |            | x x  |            |   |            |    x
  x      |  SGP3      | x x  |   SGP1     |   |    SGP2    |    x
  x      |            | x x  |            |   |            |    x
  x      |            | x x  |            |   |            |    x
  x      +-----+------+ x x  +----+-------+   +-------+----+    x
  x            |        x x       |                   |         x
  x            |        x x       |                   |         x
  x       SG2  |        x x       |      SG1          |         x
  x            |        x x       |                   |         x
  xxxxxxxxxxxxx|xxxxxxxxx xxxxxxxx|xxxxxxxxxxxxxxxxxxx|xxxxxxxxxx
               |                  |                   |
               |                  |                   |
               |      +-----------+----+              |
               |      |                |              |
               +------+    ASP2        +--------------+
                      |                |
                      +----------------+

First of all, what do we achieve with the concept of SGP? They are single
entity from MTP3 point of view and they are sharing AS state machines among
themselves. Why do we want them to share the AS state machine? My
interpretation is to make life of ASP a little bit easier.That they are a
single MTP3 entity is related with the previous example. This one is about
their AS state sharing. 
In the scenario above, ASP1/ASP2 are serving the same AS, are working in
override mode and ASP1 is currently processing the traffic, it is the active
one. The association between SGP1 and ASP1 is broken. But because SGP1 and
SGP2 are sharing AS state, no NTFY is sent to ASP2. This has saved ASP2 from
an analysis in the following way. If this NTFY was sent, ASP2 would ask ASP1
whether it has an active association to SGP2 to determine whether it should
activate its assocaition for this route key or not. Because, if it acted
just by itself and activated its association, both ASP1 and ASP2 would be
active, bad , because they want to work in active/standby. But here SGP
concept has saved ASPs from extra work, they know, when one of them receives
NTFY, the other one is inaccessible from any of the SGPs belonging to the
SG. So far, so good.
But infortunately, there is the SGP3 in play, which belongs to SG2 and is
not sharing anything with SG1 SGPs. So, ASP2 still needs to coordinate its
response with ASP1, for not having a situation where both of them are in
active state (they don't want to be active at the same time, because their
SS7 user part does not support an mixed active/active operation mode) After
all, what did we gain with SGP concept? 
Now the options are:
1- Force in the draft that all of the M3UA entities an ASP is connected to
are working as SGPs, which are part of the same SG (2- in the first example)
2- Accept the fact and always do a coordination between ASPs (By the way it
should be noted that when there is the SGP concept this coordination will
require extra information again, which SGP is belonging to which SG)

Again I think nobody will agree for 1-, finding it too restrictive
(basically forcing to use always SGPs from the same vendor, unless inter-SGP
protocol is standardized)

When I add 3- of example one with 2- of example 2 , it makes:
- Handle SGPs as totally independent entities in M3UA domain. In fact, just
call them SGs, which have the same MTP3 view to the SS7 world.
         
> (Thu, 18 Oct 2001 15:02:10)
> > Hi,
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 21:51:38 -0500

Tolga,

Asveren, Tolga wrote:                       (Thu, 18 Oct 2001 19:31:14)
> Please see commnets/questions below.

As the draft stands, I suppose one might need to have been involved in the
evolution of the draft for some of these concepts to be clear.  Although a lot
of this descriptions is better for an AS or BCP, we should place more
implementation notes in the draft.  Perhaps we can come up with some descriptive
text and maybe an example in this thread to add to the draft for clarity.

> [TOLGA] I agree, it is better to keep being up/down/active/inactive
> as attributes of associations. This bring more flexibilitya and
> keeps things as it is. And also makes the concepts of ASP/SGP look
> symmetrical.

It may not be the best model for specific applications, however, it adapts well
to many implementation architectures.  We seem to get into problems whenever we
try to remove that symmetry.

I am not sure that ASP implementors really realize, however, that SGP can be
active/standby, loadshare or broadcast even though it is mentioned in SGP
redundancy.  Active/standby and broadcast do not require additional provisioning
information, however, loadshare requires that the ASP be able to perform a range
of loadsharing algorithms and on any number of loadsharing keys (SLS, CIC,
etc.).

To make SGP/ASP implementations a little more usable, an AS/BCP should address
common loasharing schemes that an ASP or SGP might want to implement.  As it
stands, every SGP/ASP implementation will probably do their own thing or just
not support it at all.

> [TOLGA] That is the interesting point.        

That was fairly clear from a long thread on SGP paritioning, that each SGP
should be able to indicate SNMM individually when they cannot (or do not want
to) tell whether another SGP has already indicated to the ASPs.  The ASP can
ignore multiples.  The SHOULD is there so (and maybe it should be stated) that
the SGP needs to be careful not to send conflicting SNMM information to the ASP
from different SGPs.

I think 2 is too restrictive as well.  Certainly an ASP must be allowed to
connect to more than one SG.  Each SG may have different assignments of NA and
RC as well, so the ASP is not going to escape maintaining separate configuration
for each ASP.

I think an operator definitely needs an ASP (MGC) to be able to connect to more
than one SG (SPOI) so that an operator of an MGC can connect to multiple SS7
networks.

> interpretation is to make life of ASP a little bit easier. That they ere a

I should really have stressed that the ASP cannot rely on the SGP sharing AS
state whatsoever.  Each SGP figures that the state of the AS is whatever the ASP
has last told it.  The AS exists at the ASPs.  Each SG has its own view of the
AS state, regardless of whether that view was obtained directly from the ASP
using ASPSM procedures, or whether that view was obtained from another SGP makes
no difference.  It is only a proxy for the actual AS state which is maintained
by the ASPs (whether individually or in concert).

> all, what did we gain with SGP concept? 

Although that is one way to implement it, in implementation I approach that
situation a little differently.  Focussing just on ASP1 and 2 and on SGP1:

             +---------+                +---------+
	     |         |                |         |
	     |  ASP1   |----------------|  ASP2   |
	     |         |                |         |
             +---------+                +---------+
                  X                          |
                  X                          |
                  X                          |
                  XXXXXXXXXXXXX  +-----------+
                              X  |
                              X  |
                           +---------+
	                   |         |
	                   |  SGP1   |
	                   |         |
                           +---------+

SGP1 has lost communication with ASP1 following your example.  Given the state
diagram (Figure 4), an SCTP CDI has occured and SGP1 has no choice but to view
ASP1 in the ASP-DOWN state.  Therefore, SGP1 must send a NTFY("ASP Failure") in
accordance with section 4.3.4.6:

	"A Notify message reflecting the change in the AS state MUST
	 be sent to all ASPs in the AS, except those in the ASP-DOWN
	 state, with appropriate Status Information and any ASP
	 Identifier of the failed ASP."

The SGP also needs to notify ASP2 of the AS state change that resulted from the
ASP Failure with a NTFY("AS-Pending") because ASP2 is in the inactive state for
the AS.  There is not any choice here really, it is a MUST.  Any messages that
SGP1 has to send to ASP1 are queued for T(r).

Now consider the actions at ASP1.

                           +---------+
	                   |         |
	                   |  ASP1   |
	                   |         |
                           +---------+
                              X  |
                              X  |
                  XXXXXXXXXXXXX  +-----------+
                  X                          |
                  X                          |
                  X                          |
             +---------+                +---------+
	     |         |                |         |
	     |  SGP1   |----------------|  SGP2   |
	     |         |                |         |
             +---------+                +---------+

ASP1 detects the SCTP CDI and knows that it is now ASP-DOWN for SGP1.  Any
messages that ASP1 has which would otherwise have been sent to SGP1 are now sent
to SGP2.  (The sequence of events for sending messages to SGP2 depends on the
traffic mode of the SGP, let's assume loadsharing on SLS for example).

Now consider the actions at ASP2.

             +---------+                +---------+
	     |         |                |         |
	     |  ASP1   |----------------|  ASP2   |
	     |         |                |         |
             +---------+                +---------+
                  X                          |
                  X                          |
                  X                          |
                  XXXXXXXXXXXXX  +-----------+
                              X  |
                              X  |
                           +---------+
	                   |         |
	                   |  SGP1   |
	                   |         |
                           +---------+

ASP2 receives NTFY("ASP Failure") from SGP1 w.r.t. ASP1.  ASP2 knows that it can
still communicate with ASP1 and, in any event, it has not receive NTFY("ASP
Failure") from SGP2 or 3.  It has also not received NTFY("AS-Pending") from SGP2
or 3.

Now, the only reason for sending "ASP Failure" in the first place was so that
ASP2 could distinguish between the following:

	ASP1 to SGP1 communication failure.
	ASP1 to ASP2 communication failure.
	ASP1 failure.

By receiving ASP Failure from SGP1, but still being able to communicate directly
with ASP1, ASP2 knows that this is an ASP1 to SGP1 communication failure.

When ASP2 receives NTFY("AS Pending") from SGP1 it has choices.  Either it goes
active itself and sents ASP AC to SGP1, or it choses to ignore the situation and
let loadsharing do its work.  Which action it takes will depend on the state of
ASP1 and ASP1's ability to service the traffic.

This was the WG concensus: the ASPs determine when they go active based on
inter-ASP communication.  The SG or SGP does not make this determination for
them.  Sending NTFY("ASP Failure") and NTFY("AS-Pending") to ASP2 is advisory
only.  The action taken by ASP2 is based on ASP2's knowledge of the state of
other ASPs in serving the AS.

If ASP2 sends ASPAC to SGP1 for the traffic being served by ASP1, SGP1 will
place the AS AS-ACTIVE and direct traffic towards ASP2.  If ASP2 does not send
ASPAC to SGP1, when T(r) expires, SGP1 has some choices.

Back to SGP1:  T(r) expires.

                           +---------+
	                   |         |
	                   |  ASP1   |
	                   |         |
                           +---------+
                              X  |
                              X  |
                  XXXXXXXXXXXXX  +-----------+
                  X                          |
                  X                          |
                  X                          |
             +---------+                +---------+
	     |         |                |         |
	     |  SGP1   |----------------|  SGP2   |
	     |         |                |         |
             +---------+                +---------+

This is where I have contention with the draft.  The draft says:

	"It T(r) expires before an ASP becomes ASP-ACTIVE, the SGP
	 stops queueing messages and discards all previously queued
	 messages."

There is no reason for SGP1 to discard messages.  Not having received an ASPAC
from ASP2, it has the choice of sending queued messages to SGP2 for processing,
which is should to.  Also, if sending messages internally to SGP2 causes
problems, it should take steps to remove the cross-directed traffic at the
front-end and have it directly handled by SGP2.

Now, in my implementation, I set T(r) to 0 (which is permitted) when there
is an alternate SGP that can be used..  Therefore, my SGP1 will redirect traffic
to SGP2 and remove itself from receiving the redirected SS7 traffic immediately.
If it later receives ASPAC from ASP2, it will switch traffic back to itself and
redirect it to ASP2 using queueing and HEARTBEAT messages to avoid
missequencing.

In that way:

	o   If SGP1 can reach ASP1 it will.
	o   If ASP1 can reach SGP1 it will.
	o   If ASP2 decides to take over it will.

The decision as to whether ASP2 will take over traffic or not, however, rests
solely in the hands of the ASPs.  The NTFY messages are on a per-SGP basis and
are advisory only.

> require extra information again, which SGP is belonging to which SG)

I don't consider the information about which SGP belongs to which SG as extra
information.  Where there are multiple SGP per SG, the ASP needs to know this
membership so that it can properly perform traffic distribution between SGPs
even when nothing has failed.  SGPs can be configured in active/standby,
loadshare and broadcast modes (just like ASPs).  The ASP not perform this
function without knowing which SG the SGP belong to, just as the SGP cannot
perform this function without know which AS the ASP belong to.

> call them SGs, which have the same MTP3 view to the SS7 world.

So, as you can see, there is no problem with the draft for this example with the
exception of the the statement in 4.3.2 which says that the SGP should discard
message after T(r) expiry.  That is a poor recommendation indeed for multiple
SGP SGs.  Quite the opposite is true: if the SGP has any other way of delivering
the messages, it should do so immediately upon T(r) expiry and only discard when
there is no other alternative.

Another way to look at it, however, is to say that SGP1 sees ASP1 in the
ASP-DOWN state, but, because it knows of SGP2 and that SGP2 is active for the
same AS on ASP1, that SGP1 does not consider the AS to be in the AS-PENDING
state following the failure of ASP1, but views it still in the AS-ACTIVE state
(via SGP2).  In this case, the SGP1 would send NTFY("ASP Failure") but would not
follow up with NTFY("AS-Pending") and could immediately redirect traffic into
SGP2 for ASP1.  The problem with that would be that ASP2 would never be informed
of the situation by the SG, ASP1 cannot detect that SGP1 has redirected through
SGP2, and ASP2 will not be properly notified and given an opportunity to take
action.

Therefore, NTFY must be done on a per-SGP basis.  The ASP is completely
responsible for determining what actions to take as a result of ASP Failure and
AS state changes.

No changes are required in the draft (except that silly discard statement,
but I have brought that up many times).

Clarification?  Perhaps this very example should be placed in section 5.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 19 Oct 2001 08:53:45 -0500

Brian,

I also don't see any major problem ( at least til now) with what was described on the draft, based on your examples. But for sure, some examples and a little bit more explanation is necessary on the draft, so it is more understandable.
 
I agree with you that the sentence "It T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queueing messages and discards all previously queued messages." does not make sense too much. I think, if one speaks of a SG consisting of multiple SGPs, inter-SGP communication is unavoidable. What was the objection to change it like what you described (instead of discarding , trying to send it from another SGP)? Why not to change it that way?

The things are working well, like you have described in the examples. But my real question is more about the necessity of making SGP concept visible to ASP, and what we gain with it, not with the operational procedures of it. What is now easier , when the concept of SGP is known on ASP-side?  

I can see one example , where it makes sense, but I don't know whether this is really something, which necessarly should be supported or not:
    
                    +----------+
                    |          |
                    |   ASP1   |
                    |          |
                    ++--+--+---+
                     |  |  |
                     |  |  |
                     |  |  +-----------------------+
            +--------+  +--------+                 |
            |                    |                 |
            |                    |                 |
  xxxxxxxxxx|xxxxxxxxxxx    xxxxx|xxxxxxxxxxxxxxxxx|xxxxxxxxx
  x         |          x    x    |                 |        x
  x    +----+-----+    x    x  +-+--------+   +----+----+   x
  x    |          |    x    x  |          |   |         |   x
  x    |  SGP3    |    x    x  |   SGP1   |   |  SGP2   |   x
  x    |          |    x    x  |          |   |         |   x
  x    +----------+    x    x  +----------+   +---------+   x
  x                    x    x                               x
  x       SG2          x    x           SG2                 x
  x                    x    x                               x
  x                    x    x                               x
  xxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In that example, if ASP1 is not aware of SGPs and sees every M3UA peer equal, then it can either loadshare among them or use an override-mode approach. But if it is aware that SGP1-SGP2 are belonging to SG1 and SGP3 is belonging to SG2, it for example can use SGs in override-mode, and in SG (for SGP1-SGP2) it can use loadsharing message distribution. But I don't think this feature is very important. Any other examples, where SGP-knowledge on ASP side brings simplicity?

By the way, it should be noted that if we check the symmetricity between AS and SG,  we will see that it does not exist. Traffic belonging to a RK can go only to one AS in SG-ASP direction, but the same traffic can go to two different SGs in ASP-SG direction. There is only one way to make AS symmetric to SG: All of the entities to which an ASP is connected to, should be SGPs of the same SG. This is obviously too restrictive as indicated in the former messages on this thread (maybe a standard inter-SGP protocol can make this possible but for sure not realistic for the near feature)So, I don't think making SGP concept hidden to ASP side will ruin the symmetry between AS-SG, which is currently already broken. In fact, it will make it more symmetric then now, because then ASP will be connected to SGs, but there is neither a difference nor a special grouping between them, so they will correspond to ASPs. Why not to hide SGP concept from ASP and make it a little bit simpler, if th!
ere is no obvious benefit by making it visible to ASP?

    Tolga 

> Sent: Thursday, October 18, 2001 10:52 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 15:24:50 -0500

Tolga,

Asveren, Tolga wrote:                                    (Fri, 19 Oct 2001 08:53:45)
> Brian,
> 
> I also don't see any major problem ( at least til now) with what was
> described on the draft, based on your examples. But for sure, some examples
> and a little bit more explanation is necessary on the draft, so it is more
> understandable.
>  
> I agree with you that the sentence "It T(r) expires before an ASP becomes
> ASP-ACTIVE, the SGP stops queueing messages and discards all previously
> queued messages." does not make sense too much. I think, if one speaks of a
> SG consisting of multiple SGPs, inter-SGP communication is unavoidable. What
> was the objection to change it like what you described (instead of
> discarding , trying to send it from another SGP)? Why not to change it that
> way?

Greg, Javier, John?  Can we change this passage to indicate that the SGP
can take whatever other course of action is available to it before discarding
messages?

> The things are working well, like you have described in the examples. But my
> real question is more about the necessity of making SGP concept visible to
> ASP, and what we gain with it, not with the operational procedures of it.
> What is now easier , when the concept of SGP is known on ASP-side?  

I don't know that things are easier, but what is acheived is host redundancy
at the SG (which you agree that SCTP does not provide) and acheived in a
was that permits the SGP to be organized within an SG as active/standby,
loadshare or broadcast.  Not permitting this would limit the SG implementation
architecture.  Because there are several SG implementation architectures in
use (big metal HA-hosts, HWFT processor, mutli-processor distributed) it is
necessary to provide this flexibility.

> 
> I can see one example , where it makes sense, but I don't know whether this
> is really something, which necessarly should be supported or not:
>     
>                     +----------+
>                     |          |
>                     |   ASP1   |
>                     |          |
>                     ++--+--+---+
>                      |  |  |
>                      |  |  |
> In that example, if ASP1 is not aware of SGPs and sees every M3UA peer
> equal, then it can either loadshare among them or use an override-mode
> approach.

I don't think so.  One of the points in having multiple SGs is because
each can have different connectivity to the SS7 network.  SGPs within
an SG are required to have the same connectivity to the SS7 network.

> But if it is aware that SGP1-SGP2 are belonging to SG1 and SGP3 is
> belonging to SG2, it for example can use SGs in override-mode, and in SG
> (for SGP1-SGP2) it can use loadsharing message distribution. But I don't
> think this feature is very important. Any other examples, where
> SGP-knowledge on ASP side brings simplicity?

So, if SG2 is F-linked to Network A and (hey! there's two SG2s in
your diagram) SG1 is B/D-linked to Network B then ASP1 cannot loadshare
over all the SGP as though they were one SG.  SGP within a loadsharing
group need to have identical SS7 connectivity.

> By the way, it should be noted that if we check the symmetricity between AS
> and SG,  we will see that it does not exist.

I agree there is not complete symmetry between AS and SG; there is much
more symmetry, however, between ASP and SGP.

> Traffic belonging to a RK can
> go only to one AS in SG-ASP direction, but the same traffic can go to two
> different SGs in ASP-SG direction. There is only one way to make AS
> symmetric to SG: All of the entities to which an ASP is connected to, should
> be SGPs of the same SG. This is obviously too restrictive as indicated in
> the former messages on this thread (maybe a standard inter-SGP protocol can
> make this possible but for sure not realistic for the near feature)So, I
> don't think making SGP concept hidden to ASP side will ruin the symmetry
> between AS-SG, which is currently already broken.

It would break symmetry between SGP and ASP.

> In fact, it will make it more symmetric then now, because then ASP will be
> connected to SGs, but there is neither a difference nor a special grouping
> between them, so they will correspond to ASPs. Why not to hide SGP concept
> from ASP and make it a little bit simpler, if th!  ere is no obvious benefit
> by making it visible to ASP?

SG is a logical grouping of alike SGP.  An AS is an SS7 user.  The symmtery
exists in that an SGP provides services to SS7 users (AS) and the ASP provides
services to SS7 users AS.  The AS is also a logical grouping of alike ASPs.

I don't see that it is possible to remove the SG grouping, the ASP needs
to know it both to place in context SS7 connectivity (SNMM) and SGP management
(ASPTM/SM).

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 23 Oct 2001 08:25:27 -0500

Brian,

   Tolga

> Sent: Friday, October 19, 2001 4:25 PM
> To: sigtran
> (Fri, 19 Oct 2001 08:53:45)
> > Brian,
> > 
[TOLGA] I think, what you point out is , what is described in the scenario above: One can need to have different traffic modes for different SGs. I think, this is a valid argument, especially if it considered, that there can be different SG implementation architectures like you have said. If we need such kind of mechanism on SG-side, don't we need it also for ASP-side? Currently one can have only one type of traffic mode, which applies to all of the ASPs. But probably, this is enough, because I think it is almost necessary that ASPs, serving the same AS, should come from the same vendor, so that they can communicate to each other. Any comments on the necessity of supporting different traffic modes for different ASP-groupings?
> an SG are required to have the same connectivity to the SS7 network.
[TOLGA] That part, I don't get exactly. While SG is selected by ASP-side for outgoing traffic, reachability of point codes is considered. Why should ASP care, whether some of the M3UA entities, it can send messages to, are having the same SS7 connectivity? If I can reach the destination point code from a SG, then why should I care whether it has the same SS7 connectivity with another M3UA entity? ASP can keep the reachability status per SGP.
> group need to have identical SS7 connectivity.
[TOLGA] My understanding of loadsharing for traffic from ASP to SG side is as follows:
First based on reachability (and maybe also based on active/inactive status of the route key, which -I think- most of the people are not going to implement) one selects a group of SGs. Then if the traffic mode is loadsharing, one loadshares among them. So, in your example, even if the traffic mode is looadsharing, nothing will be loadshared because two SGs are connected to different networks and no point code in a network is reachable by both of them. Why is it important that two M3Ua entities, from which I can reach the same point code, should have the same SS7 connectivity, if I want to loadshare among them? 
> It would break symmetry between SGP and ASP.
[TOLGA] How I see symmetrity is like this:
AS==> Does not correspond currently to anything. AS is a service and maybe one can interpret that the service, given by all of the M3UA entities on SG-side, is a similar one. Like there are no two ASs for a route key (for a service), there also shouldn't be two different services on SG side. I think the service on SG-side as delivering a message to SS7 node. It is also possible that one thinks it in finer granularity, where a service is defines as delivering a message to a specific point code in SS7 network. Again, this won't change the uniqueness of the the service. For delivering a message to a SS7 point code, still there is one service.
ASP==> Corresponds to current SG, one of the M3UA entities, which can process the messages for a service. 
> to know it both to place in context SS7 connectivity (SNMM) 
[TOLGA] For SSNM, if it is done per SGP like before(sent by every SGP individually), does ASP still need to know the SG grouping? And why does ASP need to know SG grouping for ASPTM/SM? 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 14:30:31 -0500

Tolga,

Asveren, Tolga wrote: (Tue, 23 Oct 2001 08:25:27)
[snip]
> > > I also don't see any major problem ( at least til now) with what
> > > was described on the draft, based on your examples. But for sure,
> > > some examples and a little bit more explanation is necessary on
> > > the draft, so it is more understandable.
> > >  
> > > I agree with you that the sentence "It T(r) expires before an ASP
> > > becomes ASP-ACTIVE, the SGP stops queueing messages and discards
> > > all previously queued messages." does not make sense too much. I
> > > think, if one speaks of a SG consisting of multiple SGPs,
> > > inter-SGP communication is unavoidable. What was the objection to
> > > change it like what you described (instead of discarding , trying
> > > to send it from another SGP)? Why not to change it that way?
> > 
> > Greg, Javier, John?  Can we change this passage to indicate that the
> > SGP can take whatever other course of action is available to it
> > before discarding messages?
> > 
> > > The things are working well, like you have described in the
> > > examples. But my real question is more about the necessity of
> > > making SGP concept visible to ASP, and what we gain with it, not
> > > with the operational procedures of it.  What is now easier , when
> > > the concept of SGP is known on ASP-side?  
> > 
> > I don't know that things are easier, but what is acheived is host
> > redundancy at the SG (which you agree that SCTP does not provide)
> > and acheived in a was that permits the SGP to be organized within an
> > SG as active/standby, loadshare or broadcast.  Not permitting this
> > would limit the SG implementation architecture.  Because there are
> > several SG implementation architectures in use (big metal HA-hosts,
> > HWFT processor, mutli-processor distributed) it is necessary to
> > provide this flexibility.
> > 
> > > 
> > > I can see one example , where it makes sense, but I don't know
> > > whether this is really something, which necessarly should be
> > > supported or not:
> > >     
> > >                     +----------+
> > >                     |          |
> > >                     |   ASP1   |
> > >                     |          |
> > >                     ++--+--+---+
> > >                      |  |  |
> > >                      |  |  |
> > > In that example, if ASP1 is not aware of SGPs and sees every M3UA
> > > peer equal, then it can either loadshare among them or use an
> > > override-mode approach.
>
> [TOLGA] I think, what you point out is , what is described in the
> scenario above: One can need to have different traffic modes for
> different SGs. I think, this is a valid argument, especially if it
> considered, that there can be different SG implementation
> architectures like you have said. If we need such kind of mechanism on
> SG-side, don't we need it also for ASP-side?

> Currently one can have only one type of traffic mode, which applies to
> all of the ASPs.

This is not true.  Traffic Mode Type is a parameter of the AS, not
the ASP.  An ASP can have multiple traffic modes (one for each AS).

> But probably, this is enough, because I think it is almost necessary
> that ASPs, serving the same AS, should come from the same vendor, so
> that they can communicate to each other. Any comments on the necessity
> of supporting different traffic modes for different ASP-groupings?
>
> > 
> > I don't think so.  One of the points in having multiple SGs is
> > because each can have different connectivity to the SS7 network.
> > SGPs within an SG are required to have the same connectivity to the
> > SS7 network.
>
> [TOLGA] That part, I don't get exactly. While SG is selected by
> ASP-side for outgoing traffic, reachability of point codes is
> considered. Why should ASP care, whether some of the M3UA entities, it
> can send messages to, are having the same SS7 connectivity? If I can
> reach the destination point code from a SG, then why should I care
> whether it has the same SS7 connectivity with another M3UA entity? ASP
> can keep the reachability status per SGP.

ASPs are permitted to keep reachability per SGP if they want to.
Other ASPs, however, are permitted to keep reachability per SG.
Other ASPs are permitted to not keep reachability at all, but
have the AS do this if it wants.  The ASP, therefore, might not
have reachability of an SGP as part of its selection criteria
for choosing an SGP.  Only ASPSM/TM need be considered.

> > > belonging to SG2, it for example can use SGs in override-mode, and
> > > in SG (for SGP1-SGP2) it can use loadsharing message distribution.
> > > But I don't think this feature is very important. Any other
> > > examples, where SGP-knowledge on ASP side brings simplicity?
> > 
> > your diagram) SG1 is B/D-linked to Network B then ASP1 cannot
> > loadshare over all the SGP as though they were one SG.  SGP within a
> > loadsharing group need to have identical SS7 connectivity.
>
> First based on reachability (and maybe also based on active/inactive
> status of the route key, which -I think- most of the people are not
> going to implement) one selects a group of SGs. Then if the traffic
> mode is loadsharing, one loadshares among them. So, in your example,
> even if the traffic mode is looadsharing, nothing will be loadshared
> because two SGs are connected to different networks and no point code
> in a network is reachable by both of them. Why is it important that
> two M3Ua entities, from which I can reach the same point code, should
> have the same SS7 connectivity, if I want to loadshare among them? 

I thing you are confusing SGP with SG.  I am talking about loadsharing
over SGP within an SG.  Each SGP can reach the network as good as any
other.

> > > By the way, it should be noted that if we check the symmetricity
> > > between AS and SG,  we will see that it does not exist.
> > 
> > I agree there is not complete symmetry between AS and SG; there is
> > much more symmetry, however, between ASP and SGP.
> > 
> > > Traffic belonging to a RK can go only to one AS in SG-ASP
> > > direction, but the same traffic can go to two different SGs in
> > > ASP-SG direction. There is only one way to make AS symmetric to
> > > SG: All of the entities to which an ASP is connected to, should be
> > > SGPs of the same SG. This is obviously too restrictive as
> > > indicated in the former messages on this thread (maybe a standard
> > > inter-SGP protocol can make this possible but for sure not
> > > realistic for the near feature)So, I don't think making SGP
> > > concept hidden to ASP side will ruin the symmetry between AS-SG,
> > > which is currently already broken.
> > 
> AS==> Does not correspond currently to anything. AS is a service and
> maybe one can interpret that the service, given by all of the M3UA
> entities on SG-side, is a similar one. Like there are no two ASs for a
> route key (for a service), there also shouldn't be two different
> services on SG side. I think the service on SG-side as delivering a
> message to SS7 node. It is also possible that one thinks it in finer
> granularity, where a service is defines as delivering a message to a
> specific point code in SS7 network. Again, this won't change the
> uniqueness of the the service. For delivering a message to a SS7 point
> code, still there is one service.

RC/RK applies to both directions and is symmetrical.  The AS served
and the SG serving the AS.

I think of it as an ASP upon which an instance of an SS7/User interface
is exposed to the User and an SGP upon which an instance of an SS7/User
interface is exposed to the Provider.  They are two sides of the same
coin.  They are symmetrical in that sense (even though there might be
a different picture on either side of the coin).

> > > In fact, it will make it more symmetric then now, because then ASP
> > > will be connected to SGs, but there is neither a difference nor a
> > > special grouping between them, so they will correspond to ASPs.
> > > Why not to hide SGP concept from ASP and make it a little bit
> > > simpler, if th!  ere is no obvious benefit by making it visible to
> > > ASP?
> > 
> > SG is a logical grouping of alike SGP.  An AS is an SS7 user.  The
> > symmtery exists in that an SGP provides services to SS7 users (AS)
> > and the ASP provides services to SS7 users AS.  The AS is also a
> > logical grouping of alike ASPs.
> > 
> > I don't see that it is possible to remove the SG grouping, the ASP
> > needs to know it both to place in context SS7 connectivity (SNMM)
> > and SGP management (ASPTM/SM).
>
> [TOLGA] For SSNM, if it is done per SGP like before(sent by every SGP
> individually), does ASP still need to know the SG grouping? And why
> does ASP need to know SG grouping for ASPTM/SM? 

Yes it needs to know SG grouping because it needs to know RC numbering
NA numbering, traffic mode amoungst the SGP, etc... and on an on.
Performing SNNM on a per-SG basis permits the ASP to not have to
maintain any reachability (in the non-multiple-SG as STP case).  For
the simple configurations you simply cannot require that the ASP keep
track of stuff that it is not interested in.

SNMM is per-SG.  ASPTM/SM is per SGP.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 14:57:08 -0500

Tolga,

> SNMM is per-SG.  ASPTM/SM is per SGP.

SNMM is per-AS.  ASPTM/SM is per ASP.

I model it like this:

                                    ______                   
                                   |      |___               
             SG               _____| ASP1 |   \    _____     
                             /     |______|    \__|     |    
     _____          ______  /       ______      __| AS1 |    
    |     |________|      |/_______|      |    /  |_____|    
    | AS1 |\    ___| SGP1 |\    ___| ASP2 |___/              
    |_____| \  /   |______| \  /   |______|                  
             \/              \/                              
     _____   /\     ______   /\     ______                   
    |     | /  \___|      | /  \___|      |___               
    | AS2 |/_______| SGP2 |/_______| ASP3 |   \    _____     
    |_____|        |______|\       |______|    \__|     |    
                            \       ______      __| AS2 |    
                             \_____|      |    /  |_____|    
                                   | ASP4 |___/              
                                   |______|                  

The SG only need send SNMM once per AS.  ASPTM/SM is sent
once per ASP.

So, it doesn't matter via which SGP a DUNA for AS1 (RC in SNMM)
is sent.  ASPTM/SM is only in the context of a particular SGP/ASP
association.

It that the problem you were having?  Saying SNMM per-SG instead
of SNMM per-AS?

Perhaps the draft should say that the SNMM need only be sent once
by any of the SGPs serving the AS to which the SNMM applies.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 25 Oct 2001 09:33:21 -0500

Brian,

  Tolga

[snip]
> the ASP.  An ASP can have multiple traffic modes (one for each AS).
[TOLGA] What I meant was, that one can select only one traffic mode for
ASPs, which are serving the same AS (because as you pointed out it is per
AS), one can have a traffic policy to apply among SGs and after the SG is
selected, one can have another traffic mode to select the SGP. The argument
to have such a double-traffic mode mechanism (that SGs can be implemented
with very different architectural models)is a fair one. Does this argument
apply also for ASP side? Should the case, where there are multiple ASPs,
which are distributed implementations and have different architectural
models, considered or not? In fact here one can argue that there is no need
to distribute an ASP, because one achieves host-redundancy by using multiple
ASPs for the same AS. But isn't the same achieved by using multiple SGs (or
one can call them also SGPs, where all of the SGPs are belonging to
different SGs, so no two SGPs are part of the same SG)? So, is SGP concept
really necessary from host-redundancy point of failure?

[.....]
> for choosing an SGP.  Only ASPSM/TM need be considered.
[TOLGA] In the draft09 section 1.4.2.5 it is said "The ASP must choose an
SGP to direct a message to the SS7 network. This is accomplished by
observing the Destination Point Code (and possibly other elements of the
outgoing message such as the SLS value)"
If OPC is not part of the RK, then one has to keep a list, from which SG a
specific point code can be reached, otherwise the implementation wouldn't be
in line with the draft09. And also accordint to me, draft09 forces to make
use of just ASPSM to choose for the SG. One can send traffic only to a SG,
to which ASPUP/ASPUP-ACK messaging is done. But it is not forced that
ASPAC-ASPACACK messaging is done, although I would like to see it in this
way. As far as I remember, related with this, there was a discussion betwen
Brian and Javier, whether traffic in SS7 network is always symmetric or not,
but there was no conclusion. If it is always symmetric, then maybe the draft
can be changed also to force to consider ASPTM for choosing SG. 

> over SGP within an SG.  Each SGP can reach the network as good as any
[TOLGA] But how are you deciding to choose which SG, to send the traffic to?
Only after selecting the SG, one can loadshare among the SGPs of this SG.

[.....]
> track of stuff that it is not interested in.
[TOLGA] I agree with you that for this specific configuration (non-multiple
SG as STP case) SSNM per SG will help.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Oct 2001 05:59:55 -0500

Tolga,

Asveren, Tolga wrote:                                    (Thu, 25 Oct 2001 09:33:21)

[snip]
> really necessary from host-redundancy point of failure?

Both SGs and ASs are SS7 entities in the sense of SS7 network management
(i.e., SNMM is per SG and per AS).  Where multiple SGP make up an SG,
multiple ASPs also serve an AS.  That's just the model.  It works.

> can be changed also to force to consider ASPTM for choosing SG. 

Tolga, for multiple SGs acting as STPs you must maintain a list of
which DPCs are available from which SGs.  For AS which only have
a single SG serving them, there is no need to maintain a list.
M3UA-09 certainly does not require anything whatsoever in section
1.4.2.5.  It is descriptive only.  Saying that an "ASP must choose
and SGP" is just a matter of logic.  If the ASP wants to send a
message, it is going to have to decide which SGP to send it to.
Section 1.4.2.5 makes not requirements on how the ASP goes about
deciding.

> Only after selecting the SG, one can loadshare among the SGPs of this SG.

If you have multiple SGs to choose from to reach the same DPC it can
only mean that the SGs are STPs in the SS7 domain.  When you have multiple
STPs that you are connected to, you must loadshare traffic over the STPs
on the basis of SLS, and must only route traffic to destinations that
are available via that STP.  This is the basic SS7 routing that was
added at the ASP to handle the multiple SGs as STPs case.  What is there
that you don't understand about it?  I'm pretty sure the draft has all
the pieces necessary to support this arrangement.

> SG as STP case) SSNM per SG will help.

DRST exsits only for the multiple SG as STP case.  SNMM per-SG helps
the multiple SG as STP case as well...

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 26 Oct 2001 07:34:00 -0500

Brian,

My point was not, not to have SGP concept but not to make it visible to ASP-side, because it will require to keep SGP->SG list on ASPs and except single SG in STP mode case it won't bring any added value to the model. But this was my personal opinion and it seems nobody else is sharing it. So, I have to accept what is written in the draft :) 

  Tolga

> Sent: Friday, October 26, 2001 7:00 AM
> To: sigtran
> (Thu, 25 Oct 2001 09:33:21)
> 
> [snip]
> > > > [TOLGA] My understanding of loadsharing for traffic 
> from ASP to SG
> > > > side is as follows:
> > > >

---

---

From: Al Varney <[email-masked]>
Date: Fri, 26 Oct 2001 12:47:34 -0500

>the pieces necessary to support this arrangement.

    I'm not disagreeing, Brian, but regarding the phrase "loadshare traffic 
over the STPs"...

    For those who may not know this, SS7 (in theory and practice) supports 
SEPs connected to multiple STP pairs.  In many cases SEP routing tables 
allow alternate A-linkset routing to a DPC via more than one STP pair -- in 
effect, for a given DPC, there is a primary route via a combined linkset to 
STPs A&B and an alternate route via combined linkset to STPs C&D.  The 
alternate route is ONLY used if the DPC is unavailable via any link/STP in 
the primary route.  (Re-routing procedures are similar to those used by 
STPs for C-links when all more-direct routes are unavailable.)

    In M3UA terms, this could be mapped to an AS (or is it ASP?) connected 
to 4 SGs-acting-as-STPs.  The picture of STPs in M3UA 1.4.2 suggests only a 
single pair is possible, but I agree with Brian that the M3UA language in 
1.4.4.2 is sufficiently liberal to support both a single SG-as-STP pairing 
and this 4-SG view.  But ASP vendors may want to consider that a DPC may be 
"reachable" via more than one or 2 SGs.

    If the "C-links" in the picture of STPs in 1.4.1 are not provided, then 
SS7 network management might work better if ASP routing tables treated one 
SG as a primary route and the other as an alternate (for a given set of 
DPCs), rather than loadsharing over the "non-mated" pair of SGs.  This 
would match an ITU-T non-mated STP network (I don't know if any are 
actually configured in this manner).  Again, no M3UA changes are needed to 
support this arrangement.

----

    A side effect of such multiple-pair connections is that the SEP may be 
sending messages to DPC X via STPs A&B while receiving messages from DPC X 
via STPs C&D.  Anyway, message routing may not be symmetrical, either due 
to provisioning of routes or dynamic routing changes.  (Maybe this was an 
SUA discussion -- don't remember.)

----

    A minor M3UA suggestion:  The STP picture in 1.4.1 implies that such 
SGs interwork SS7 messages and M3UA messages.  But such SGs must also 
function as STPs for SS7-to-SS7 and M3UA-to-M3UA messages.  As I understand 
it, two ASPs with individual SS7 Point Codes may register with a SG -- and 
then send messages to each other via that SG.  This is covered (sort of) in 
1.5.3 Example 3 [SCCP GTT], but would it be helpful to add a similar 
paragraph to the end of 1.5.1 Example 1?  For example:

      It is possible that the DPC of a messages sent by the MGC and
      received at the SGP could be associated with another MGC/ASP in
      the IP domain registered with this SGP [SG?].  The MTP-TRANSFER
      indication primitive would be interworked at the NIF to an
      outgoing MTP-TRANSFER request primitive, and sent back to the
     M3UA layer for delivery to the IP destination.

    Also - Example 1 references an "MGC", but the drawing shows an "ASP".

Al Varney

---