Subject: [Sigtran] Re: Traffic handling modes of SGPs

From: Ilie Glib <[email-masked]>
Date: Fri, 2 Dec 2005 08:35:20 +0100

Hello Folks,

is my mail out of topic?

If you need that I introduce myself, here is some info:
- at the moment I am looking at SIGTRAN from operation and maintenance
perspective
- for a couple of years I am working as a telecommunication engineer
and SW designer of TMN products in ADD s.r.l. Chisinau

Of course I am asking about a definition, which is an informative part
of the SUA RFC, I assume.

Nevertheless, shall the ASP be able to broadcast its messages to all
SGPs of an SG? According to the SGP definition in SUA RFC, it seems so
to me.

Regards

Ilie

On 11/29/05, Ilie Glib <[email-masked]> wrote:
> Hello,
>
> SGP concept in RFC 3868 sais
>
> "Signalling Gateway Process (SGP) - A process instance of a Signalling
> Gateway. It serves as an active, load-sharing or broadcast process of
> a Signalling Gateway"
>
> It seems that no other part of the RFC allows SGPs to act in different
> traffic modes.
>
> Is this just a leftover?
> Or, shall ASPs know the traffic mode type of SGP by configuration?
> How override can be supported without a NTFY sent from ASPs to SGPs?
>
> Thank you in advance
>
> Ilie
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Dec 2005 02:16:08 -0700

Ilie,

1.5.2.  Address Mapping at the ASP

   To direct messages to the SS7 network, the ASP MAY perform an address
   mapping to choose the proper SGP for a given message.  This is
   accomplished by observing the Destination Point Code and other
   elements of the outgoing message, SS7 network status, SGP
   availability, and Routing Context configuration tables.

   A Signalling Gateway may be composed of one or more SGPs.  There is,
   however, no SUA messaging to manage the status of an SGP.  Whenever
   an SCTP association to an SGP exists, it is assumed to be available.
   Also, every SGP of one SG communicating with one ASP regarding one AS
   provides identical SS7 connectivity to this ASP.

   An ASP routes responses to the SGP that it received messages from;
   within the routing context which it is currently active and receiving
   traffic.

ASPs need to know the distribution method to SGPs by configuration.

There are no management messages to manage the state of an SGP.

When an association exists to an SGP, the ASP assumes that it is capable
of processing traffic for the AS that the ASP has activated to it.

For active-standby, your active SGP could have an association to the
ASP and the standby SGP would not.  If the standby goes active, the
standby would form an association and the previously active SGP would
drop its association.

Alternatively, to act as active-standby within an AS, the stanby SGP can
refuse ASP-ACTIVE for the AS with ERR(Management Blocking) or simply
withhold ASP-ACTIVE Ack and let the ASP fall back to periodic procedure.
When the standby goes active, it can then send ASP-ACTIVE-Ack and the
previously active SGP can send unsolicited ASP-INACTIVE-Ack. (Look in
the spec as to what happens when the ASP receives ASP-INACTIVE-Ack in
the ASP-ACTIVE state for an AS.)

Typically, however, SGPs run in loadshare mode, by nature of the design
of the SS7 network to which they attach.

--brian

Ilie Glib wrote:                            (Fri, 02 Dec 2005 08:35:20)

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

---

From: Ilie Glib <[email-masked]>
Date: Fri, 2 Dec 2005 11:26:31 +0100

Hello Brian,

thank you very much for your response.

For active-standby, your  second alternative fits me well.
According to my understanding of SIGTRAN the first option should not
be possible because SGPs cannot establish associations towards ASPs.

I interperet your statement
> of the SS7 network to which they attach.

as there will be no SGPs that require ASPs to broadcast traffic to all
SGPs, otherwise I would expect a nomative statement in the RFC,
requiring it.

Regards

Ilie

> Ilie,
...
option 1) (it does not work in my view)
> standby would form an association and the previously active SGP would
option 2)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Dec 2005 04:17:55 -0700

Ilie,

Ilie Glib wrote:                               (Fri, 02 Dec 2005 11:26:31)
> be possible because SGPs cannot establish associations towards ASPs.

SGPs can establish associations towards ASPs.

> SGPs, otherwise I would expect a nomative statement in the RFC,

ASPs can be configured to broadcast to SGPs.

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Fri, 2 Dec 2005 12:44:35 +0100

Brian,

I am sorry to bore you with this, and perhaps it does not deserve too
much attention, but ASPs which act as clients (according to the RFC
they should do so) would never open a listening socket. Therefore SCTP
INIT from the SGP will be lost.
Thus option 1 cannot be interoperable, but I agree that it can work in
case ASPs provide necessary support. It means clients (ASPs) should
also listen on the well-known port.

> ASPs can be configured to broadcast to SGPs.

RFC has no statements about it, has it? (except for the definition of the SGP)

Regards

Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Dec 2005 05:35:29 -0700

Ilie,

Ilie Glib wrote:                             (Fri, 02 Dec 2005 12:44:35)
> INIT from the SGP will be lost.

Where does it say that?

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Mon, 5 Dec 2005 09:27:31 +0100

Hello Brian,

here is a quote from RFC 3868
"
1.3.  Signalling Transport Architecture

...
   In general terms, the SUA architecture can be modeled as a peer-to-
   peer architecture.  The first section considers the SS7 to IP
   interworking architectures for connectionless and connection-oriented
   transport.  For this case, it is assumed that the ASP initiates the
   establishment of the SCTP association with SG.
"

I agree that the last sentence of the quoted paragraph does not say
"SHOULD", at the same time it looks like ASPs must act as clients for
establishment of SCTP associations, and there is no statement in the
RFC that would make ASPs to open listening sockets.

Regards

Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Dec 2005 01:31:54 -0700

Ilie,

An assumption is not even close to a requirement.

An ASP that cannot accept a connection is underfeatured compared
to one that does.

--brian

Ilie Glib wrote:                                                      (Mon, 05 Dec 2005 09:27:31)

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