Subject: 1.4.4.2 Signalling Gateway Redundancy

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 26 Oct 2001 13:08:22 -0500

Hi,

In the last paragraph of 1.4.4.2 it stands : "From the perspective of the M3UA layer at an ASP, a particular SG is capable of transferring traffic to a provisioned SS7 destination X if ......., the SGP has returned an acknowledgement to the ASP to indicate that the ASP is actively handling traffic for that destination X, ....... "
If OPC is not part of RK, this sentence can be misinterpreted. Based on the activeness of such a RK, one cannot decide whether for a destination X, ASP is activated or not. The correct interpretation should be of course that if OPC is not specified in RK, it includes every possible OPC but still I think this part of the sentence could be made more clear.

     Tolga

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

---

From: Denio Mariz <[email-masked]>
Date: Fri, 26 Oct 2001 23:21:07 -0200

Dear SIGTRAN:

There is some documents and subjects in target for discussion in this list.
"Last paragraph" of what document.... ? some draft ? some RFC ?

Ok, I have an idea what you are talking about, but I Think that would be
better to refer to the document at the begining of each message we are
posting  to the list.  This will make easy to follow -any- discussion.

Just a suggestion...

Thanks.

----- Original Message -----
From: "Asveren, Tolga" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, October 26, 2001 4:08 PM
Subject: 1.4.4.2 Signalling Gateway Redundancy

> Hi,
>
> In the last paragraph of 1.4.4.2 it stands : "From the perspective of the
M3UA layer at an ASP, a particular SG is capable of transferring traffic to
a provisioned SS7 destination X if ......., the SGP has returned an
acknowledgement to the ASP to indicate that the ASP is actively handling
traffic for that destination X, ....... "
> If OPC is not part of RK, this sentence can be misinterpreted. Based on
the activeness of such a RK, one cannot decide whether for a destination X,
ASP is activated or not. The correct interpretation should be of course that
if OPC is not specified in RK, it includes every possible OPC but still I
think this part of the sentence could be made more clear.
>
>      Tolga
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---

---

From: javier pastor <[email-masked]>
Date: Sun, 28 Oct 2001 14:48:05 -0800 (PST)

Hi Tolga, 

After reading it a couple of times, I think a small
reword could be enough. What about this...

"From the perspective of the M3UA layer at an ASP, a
particular SG is capable of transferring traffic to a
provisioned SS7 destination X if 
an SCTP association with at least one SGP of the SG is
established, the SGP has returned an acknowledgement
to the ASP to indicate that this ASP is active for the
Routing Key it has provided, the destination X is
reachable through that SG, the SGP has not indicated
that the destination X is inaccessible and the SGP has
not indicated MTP Restart. [...]"

Cheers // Javier.

-----Original Message-----
From: Asveren, Tolga
To: sigtran
Sent: 10/26/01 8:08 PM
Subject: 1.4.4.2 Signalling Gateway Redundancy

Hi,

In the last paragraph of 1.4.4.2 it stands : "From the
perspective of
the M3UA layer at an ASP, a particular SG is capable
of transferring
traffic to a provisioned SS7 destination X if .......,
the SGP has
returned an acknowledgement to the ASP to indicate
that the ASP is
actively handling traffic for that destination X,
....... "
If OPC is not part of RK, this sentence can be
misinterpreted. Based on
the activeness of such a RK, one cannot decide whether
for a destination
X, ASP is activated or not. The correct interpretation
should be of
course that if OPC is not specified in RK, it includes
every possible
OPC but still I think this part of the sentence could
be made more
clear.

     Tolga

---
You are currently subscribed to sigtran as:
[email-masked]

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 28 Oct 2001 17:00:04 -0600

Javier,

javier pastor wrote:                                       (Sun, 28 Oct 2001 14:48:05)
> not indicated MTP Restart. [...]"

Neither accessibility nor MTP Restart are indicated
on a per-SGP basis, but on a per-SG basis.  Replace
SGP with SG when referring to SNMM:

 "From the perspective of the M3UA layer at an ASP, a
  particular SG is capable of transferring traffic to a
  provisioned SS7 destination X if an SCTP association
  with at least one SGP of the SG is established, the
  SGP has returned an acknowledgement to the ASP to
  indicate that this ASP is active for the Routing Key
  it has provided, the destination X is reachable
| through that SG, the SG has not indicated that the
| destination X is inaccessible and the SG has not
  indicated MTP Restart. [...]"

--brian

> 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: Mon, 29 Oct 2001 06:59:36 -0600

Hi Javier,

Brian's proposed text describes current situation well. Is also a small
change necessary in 1.4.2.5 of M3UA-09 ? Maybe it can be mentioned there
that activeness of the RK also plays a role.

    Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Sunday, October 28, 2001 6:00 PM
> To: sigtran
> Subject: Re: 1.4.4.2 Signalling Gateway Redundancy
> 
> 
> Javier,
> 
> javier pastor wrote:                                       
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 14:47:52 -0800 (PST)

Hi Tolga, 

See comments inline...

--- "Asveren, Tolga" <[email-masked]> wrote:
> Hi Javier,
> 
> Brian's proposed text describes current situation well. 

Yes, I agree. :-)

>Is also a
> small

Activeness of the RK only plays a role in the SGP distribution. What it
says is what kind of incoming traffic is wanted by a specific ASP. You
could ideally use any SGP if the ASP has an association to it and that
SGP has connectivity to the SS7 node you want to communicate with.

Cheers  // Javier.

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 00:36:02 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Mon, 29 Oct 2001 14:47:52)

> SGP has connectivity to the SS7 node you want to communicate with.

You are completely off base with these statements and it is clear that
you do not understand the need for distinction between SNMM (which is
for the management of nodes and traffic in the SS7 network) and ASPSM/TM
(which is for the management of ASPs and SGPs int he IP domain).

It is clear from the current draft that, contrary to what you say here,
an ASP should not go stuffing data messages at an SGP just because it
has received a DAVA for a destination: it must also be ACTIVE for the
AS that is sending the message.  Anything else will risk that the SGP,
being uninformed of the AS's desire need to send messages, will be
unable to satisfy the request.  Any messages received by an SGP that
has an RC value that corresponds to an AS that in INACTIVE at the
ASP sending the message must be permitted to be discarded according to
the current ASPTM procedures.

Maybe you missed it, but this was the concensus that we arrived at after
a long discussion about  per-SG vs. per-SGP SNMM.  The conclusion was
to provide ASPSM/TM on a per-ASP basis only and SNMM on a per-AS basis.
I the procedures have not been completely updated to reflect this, then
it is an error in the draft.  Neither ASPs nor SGPs should not process
messages that arrive that correspond to an INACTIVE AS, and also, the
ASP and SGP must not send messages that correspond to INACTIVE AS.

--brian

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

---