Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs

From: Ilie Glib <[email-masked]>
Date: Tue, 10 Jan 2006 19:29:32 +0100

Hello Folks,

Let's consider two SUA SGs which provide connectivity to an SSN in IP network.
SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the
AS serving the SSN goes inactive in the SG and I also assume in case
the SG loses connectivity to the AS.

5.1.2.3.  Unsuccessful ASP Fail-over scenario

     ASP-a1            ASP-a2                SG                  SEP
   (Primary)           (Backup)
       +-------------ASP Inactive------------->
       <-----------ASP Inactive ACK-----------+
       <--------------------NTFY (AS Pending)-+
                         <--NTFY (AS Pending)-+
             After some time elapses (i.e., timeout).
                                              +--------SSP-------->
                                              <--------SST--------+
       <-------------------NTFY (AS Inactive)-+
                         <-NTFY (AS Inactive)-+

What shall be done in multiple SGs scenario when the SSN is allowed
via another SG?

Is this a realistic example?

Thank you in advance

--
Ilie

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 13:28:14 -0500

Ilie,

Multiple SG scenarios are overall a bit problematic -or better said require
some care and attention-. This is due to the fact that the SCCP layer for AS
is hosted on SG and if you have multiple SGs, you will have multiple copies
of the same SCCP instance which do not know about each others state -if they
knew, they would be part of the same SG-.

OTOH, for most practical cases, one prbably can survive. If we consider your
example, I would expect ASP to send ASPIA to both SGs, causing each ot them
to send SSP -probably only of them would receive SST  though-.

Maybe slightly more interesting scenario is, what happens if ASP looses
connectivity to only one SG? This would cause the subsystem to be available
in one SG and unavailable on the other one, not something we want to have.
OTOH, we should remember multihoming feature of SCTP and what it practically
means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of
association is an indication for host failure. So, in the scenario I
described if it is ASP which is down, both SGs will detect loss of
association. If it is one SG which is down, it won't be able to send SSP.

In any case, one should be careful with multi-SG scenarios.

    Thanks,
    Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ilie Glib
> Sent: Tuesday, January 10, 2006 1:30 PM
> To: SIGTRAN
> Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs
>
>
> Hello Folks,
>

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 10 Jan 2006 11:47:07 -0800 (PST)

Hi all,
   
  I agree with Tolga!
   
  I would even say -> why would one after all have several SGW'es for the same application??? What is it for?
   
  If one wants reliability of transmission resources (SGW'es) then one installs several SGP'es in the same SGW and provides one logical access point for each application to SS7 network.

  What would be the benefit of multiple SGW per application after all??? Does anyone know that?
   
  regards/ Stanislav

Tolga Asveren <[email-masked]> wrote:
  Ilie,

Thanks,
Tolga

		
---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 14:45:46 -0500

Stanislav,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stanislav Ivanovich
Sent: Tuesday, January 10, 2006 2:47 PM
To: SIGTRAN
Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs

Hi all,

I agree with Tolga!

I would even say -> why would one after all have several SGW'es for the same
application??? What is it for?

If one wants reliability of transmission resources (SGW'es) then one
installs several SGP'es in the same SGW and provides one logical access
point for each application to SS7 network.

What would be the benefit of multiple SGW per application after all??? Does
anyone know that?
[TOLGA]I think, this may makes sense to provide geographical redundancy for
SG services. It may be not very efficient to have a geographically
distributed SG consisting of multiple SGPs, e.g. where SGPs are in different
cities, if one considers that they have to provide a uniqie view of
SCCP/MTP3 layer they are hosting. OTOH, I believe using SG-SG kind of
approach is a better alternative rather than ASP/SGP multi-SG mechanism,
because with SG-SG, there is no remote hosting of SCCP/MTP3 layers, thus no
problem of multiple copies of the same SCCP/MTP3 instance, which are not
synchronized.

regards/ Stanislav

association. ! If it is one SG which is down, it won't be able to send SSP.

Thanks,
Tolga

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays,
whatever.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 13:21:52 -0700

Ilie,

I think Tolga's remarks are more applicable to M3UA than SUA.  MTP does
not provide messaging for user management.  This is partly the
responsibiliy of the MTP User itself.  So, for example, when ISUP
receives MTP-STATUS indicating user part unavailabilty (corresponding to
UPU), ISUP can send UPT to test for return to service of the user part,
but UPT is an ISUP message, not an MTP message.

With RK granularity of a Network Appearance, the ASP needs to send DUNA,
DAVA, DRST, SCON (corresponding to TFP, TFA, TFR, TFC) and the SG needs
to work those messages and AS availability into a management view of the
network appearance, point code and user part.

With RK granularity of a point code, multiple SGs as STP can treat the
AS as though it were any (A-link) attached SEP.  That is, when the AS is
inactive at the SG, it can send TFP for the AS point code, but this does
not stop traffic from being routed via the alternate SG (associated STP
in the STP pair).

When RK granularity is that of an SI value, it is still possible for an
SG as STP supporting the ANSI "Alias" point code concept (see ATIS
T1.111/2000) to suppress issuing UPU and, instead, route traffic to the
associated STP in the STP pair.

SUA, OTOH, supports management of SCCP Users.  In the case of SUA, for
RK at Network Appearance granularity, the ASP needs to send DUNA, DAVA,
DRST, SCON (corresponding to TFP, TFA, TFR, TFC, and SSP, SSA, SOR/SOG,
SSC) and the SG needs to work those messages and AS availability into a
management view of the network appearance, point code and subsystem.

When RK granulariy is that of a point code, the ASP needs to send DUNA,
DAVA, DRST, SCON (corresponding to SSP, SSA, SOR/SOG, SSC) for affected
subsystems and the SG needs to work those messages and AS availability
into a management view of the point code and subsystems.

When RK granularity is that of a subsystem, the ASP uses AS activation
only for subsystem management and the SG needs to work AS availability
into a management view of the subsystem.

For RK granulariy beneath a subsystem (e.g, global title or global title
range), the ASP uses AS activation only for management and the SG needs
to use AS avialability to coordinate a management view of the state of
the subsystem.

As regards when an SG as STP sends SSP or SSA, this is peformed in
accordance with SS7 standards (for both local and remote broadcast and
responsive methods), given the management view of the subsystem at the
STP as formulated above.  Contrary to Tolga's statements, for SUA, and
in general, an SG (as STP and SCCP relay), will not send SSP when the
subsystem is available via the associated STP.  Furthermore, if the
subsystem is replicated, unavailability of one entity in an entity set
does not cause the subsystem to be prohibited if the another entity in
the entity set is available.

But, for both M3UA and SUA, this is largely a matter of MTP transfer and
SCCP relay management and provisioning at the STPs and is outside of the
scope of M3UA and SUA.

When formulating the specifications, we took some care to ensure that
sufficient messaging existed within the M3UA and SUA protocols to
support the multiple SG as STP scenarios.

For M3UA, the message is largely complete (there are cases where it
would be good to send DUPU from the ASP, and load sharing is quite
broken, requiring an approach similar to that described in
draft-bidulock-sigtran-loadsel to fix it).

For SUA, OTOH, the multiple SG as STP scenario is largely broken for
connection-oriented protocol classes (the STP is unnaturally and
untransparently forced to couple connection sections) and DRN/TID
labelling is inadequate for the scenario.  I proposed some years ago
a registration mechanism that would fully support the multiple SG as
STP scenario and it was included in the SUA drafts, but later removed
in favor of the broken DRN/TID labeling mechanism.  You will find many
references to this defect on the mail archives.

--brian

Ilie Glib wrote:                                                      (Tue, 10 Jan 2006 19:29:32)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 13:38:25 -0700

Stanislav,

Stanislav Ivanovich wrote:                                       (Tue, 10 Jan 2006 11:47:07)
>    installs  several  SGP'es  in  the  same  SGW and provides one logical
>    access point for each application to SS7 network.
> 
> 
> 
> 
> 

It is a common practice in the SS7 network: one that we intended the
specifications to support.

There are two (maybe three) common interconnect arrangements in the SS7
network: F-link, A-link and B/D-link.  F-link interconnect is handled by
IPSP and SG/ASP backhaul.  A-link and B/D-link require multiple SG as
STP arrangement.  A transit network (not just an access network) would
also require an SG-SG arrangement for M3UA (or IPSP with relay).  SUA
already handles transit networks with SUA relay and does not require an
SG-SG protocol.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 16:39:03 -0500

Brian,

I tried to look to the issue only from SIGTRAN point of view abot what can
be done with mechanisms described in SUA/M3UA. The SCCP mechanisms you
describe could be helpful but I am not sure how -just brain exercising
here-:

*) The situation of an SG is different than an STP, SG hosts the SCCP layer,
which becomes unavailable, OTOH, STP doesn't. So, I am not sure whether it
would be correct to compare their behavior and expect from SG not to send
SSP, despite corresponding AS is no more ACTIVE.

*) Do we expect SCCP not to send SSP, if there is a replicated subsystem?

    Tolga

> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, January 10, 2006 3:22 PM
> To: Ilie Glib
> Cc: SIGTRAN
> Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs
>
>
> Ilie,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 15:06:46 -0700

Tolga,

Under SUA, even an ASP can have an SCCP relay function, meaning that even
an ASP can behave as an STP.  You are still thinking from an M3UA perspective.

--brian

Tolga Asveren wrote:                                                 (Tue, 10 Jan 2006 16:39:03)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 17:08:40 -0500

Ah O.K., I forget for a while the "undocumented" relaying functionality of
SUA :-)

In any case, personally I don't see how it may be usefull for multiple SG
scenario because SCCPs are locally hosted in SGs. Relaying messages is a
different story.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2006 5:07 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 15:47:15 -0700

Tolga,

Tolga Asveren wrote:                            (Tue, 10 Jan 2006 17:08:40)
> scenario because SCCPs are locally hosted in SGs. Relaying messages is a

SCCPs are only locally hosted at an SG in the pure backhaul case.  In
the multiple SG as STP scenario, and in the SCCP relay scenario, SCCPs
can also be hosted at the ASP or IPSP.

M3UA is not so different.  MTPs can be locally hosted at the ASP in the
multiple SG as STP scenario.  It was always the intention for M3UA to
support this scenario.

E.g, section 1.3.2 of RFC 3332:

  ... However, in the case where an ASP is connected to more than one
  SG, the M3UA layer at an ASP should maintain the status of configured
  SS7 destinations and route messages according to the availability and
  congestion status of the routes to these destinations via each SG.

Also see Section 1.4.1 and Figure 1.  See also, Figure 5 in the
Appendix, Appendix A.2.2.  There are additional passages throughout the
document.

In fact, this is the sole purpose of the DRST message: see section
3.4.6.

SUA simply provides the additional mechanism (as does SCCP) of managing
the availability of SCCP User across such an arrangement.  M3UA provides
only partial MTP User availabilty (DUPU) management, as does MTP3 (UPU).

These are fundamental capabilities required to meet the objective of
providing transparent interworking to the SS7 network.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 17:35:12 -0500

Brian,

You also know as much as I do that SCCP (and MTP3 for M3UA) is hosted on
SGs, the interface between SG and ASP mimics SCCP/SCCP-User (MTP3/MTP3-User
interface for M3UA) interface. It is true that for multiple SG scenario ASPs
have a small portion of MTP3 functionality, but this does not mean that MTP3
is actually not hosted on SG, e.g. it is still SG generating management
messages for SCCP/MTP3.

   Tolga

> Sent: Tuesday, January 10, 2006 5:47 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 17:55:33 -0700

Tolga,

I disagree. An instance of MTP is identified by a point code and the
point code resides at the ASPs in the multiple SG as STP scenario.  The
point code is not local to the MTP stack at the SG in the SS7 sense when
RK is at PC granularity or above.  This is a necessary situation to properly
support the multiple SG as STP scenario.

--brian

Tolga Asveren wrote:                            (Tue, 10 Jan 2006 17:35:12)

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

---

From: Ilie Glib <[email-masked]>
Date: Wed, 11 Jan 2006 14:07:09 +0100

Brian, Tolga

thank you very much indeed for your answers.

I think it is not possible to have multiple SGs without them playing
the role of STPs.
Therefore "multiple SG as STP scenario" is equivalent to "multiple SGs
scenario".
That is STP is always part of SG in this case and in case of SUA the
SG deals with (owns) capability (alias) pointcodes.

Is my understanding correct?

Does it apply to both SUA and M3UA?

By the way capability (alias) pointcodes is not an ITU-T term, is the
function of mimicking capability (alias) pointcodes an implementation
issue for the SG?

Thank you in advance

Ilie

--
Ilie

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 11 Jan 2006 07:54:11 -0500

Brian,

> Sent: Tuesday, January 10, 2006 7:56 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Even for PC granularity RKs, it is SG which controls/creates the
unique view of the signaling enitity to the network, so one has to have
necessary MTP3 procedures to support that.

BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 stack in SG",
it is just providing necessary procedures to have the unique view of the
signaling enitity and generating corresponding network messages -and it is
the multiple clones of the same unique view on different SGs, which are not
synchronized, which may create issues for multiple-SG scenarios-.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Jan 2006 06:18:58 -0700

Ilie,

Ilie Glib wrote:                                                      (Wed, 11 Jan 2006 14:07:09)
> I think it is not possible to have multiple SGs without them playing

I don't think so.  Do you have an example?

> Therefore "multiple SG as STP scenario" is equivalent to "multiple SGs

Don't think so.

> SG deals with (owns) capability (alias) pointcodes.

Other than alias point codes are possible.

> Is my understanding correct?

I don't think that you are there yet.

> Does it apply to both SUA and M3UA?

Did I not decribe this?

> function of mimicking capability (alias) pointcodes an implementation

It in ANSI term from ATIS T1.111 and T1.112.

---brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Jan 2006 06:20:06 -0700

Tolga,

Tolga Asveren wrote:                                                 (Wed, 11 Jan 2006 07:54:11)
> synchronized, which may create issues for multiple-SG scenarios-.

STPs do this all day long.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 11 Jan 2006 09:13:32 -0500

Brian,

[..snip..]
> STPs do this all day long.
[TOLGA]On the practical side of how things work, I agree with you that with
multiple-SG acting as STP scenario where RKs are in PC granularity, the
possibly different views of the hosted PC are less of a problem. In such a
case hosting necessary MTP3 logic for AS maps pretty much to route
management from functionality point of view.

---

From: Stanislav Ivanovich <[email-masked]>
Date: Fri, 13 Jan 2006 11:53:01 -0800 (PST)

Tolga, Brian,
   
  I see that both of you agree that in this case at ASP place we must have MTP3 (or SCCP) logic if one wants to use this configuration scenario. I think no one can question this!
   
  However the essential problem is which protocol we are to use? In my view this is the essence of the dispute. If we are to allow that ASP (or IPSP) can contain MTP or SCCP logic then the difference between the processes disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applications) as we saw from the discussion we had last year (see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" starting from December 14th 2005). So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE flavors)?
   
  However, according to Tolga's idea SG-SG protocol does support this -> i.e. MTP3/SCCP layers communicate without AS concepts in between!
   
  What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can give you and SGP-SGP communication cannot give you if in this cases ASP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)?
   
  OTOH, I see some problems of utilizing AS concepts in between two MTP3/SCCP layers (regardless of how you call the hosting processes)....
   
  / Stanislav

[..snip..]

			
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 13 Jan 2006 16:26:14 -0500

Stanislav,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stanislav Ivanovich
Sent: Friday, January 13, 2006 2:53 PM
To: SIGTRAN
Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs

Tolga, Brian,

I see that both of you agree that in this case at ASP place we must have
MTP3 (or SCCP) logic if one wants to use this configuration scenario. I
think no one can question this!
[TOLGA]Just to prevent a possible confusion, not a fullblown MTP3 logic
though, just enough to select the "right" SG.

However the essential problem is which protocol we are to use? In my view
this is the essence of the dispute. If we are to allow that ASP (or IPSP)
can contain MTP or SCCP logic then the difference between the processes
disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applications) as
we saw from the discussion we had last year (see thread "[Sigtran] AS
concepts and Relay in SUA and M3UA" starting from December 14th 2005). So
why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE flavors)?

However, according to Tolga's idea SG-SG protocol does support this -> i.e.
MTP3/SCCP layers communicate without AS concepts in between!
[TOLGA]First of all I have to say that the credit for SG-SG does not belong
to me alone. There were other people contributing to it as well from very
early on, when the idea came up during initial IPSP discussions -I believe
more than 4 years ago :-)-, or afterwards to review the SG-SG drafts.

What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can
give you and SGP-SGP communication cannot give you if in this cases
ASP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)?
[TOLGA]From redundancy point of view, probably there is no major
difference -or better said, I personally don't see something which couldn't
be added to SG-SG in this regard, if there is a need-. AFAICS, the main
advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC
granularity.  OTOH, if PC boundaries are crossed, I find SG-SG model more
natural and efficient because it is a true peer-to-peer model and does not
require hosting MTP3/SCCP logic on a remote node on behalf of AS.

OTOH, I see some problems of utilizing AS concepts in between two MTP3/SCCP
layers (regardless of how you call the hosting processes)....
[TOLGA]Yes, here I agree with you and actually if one considers that ASP/SGP
interface is mimicing MTP3/MTP3-User Part (SCCP/SCCP-User Part for SUA)
interface, this is not a suprise. That type of interface is more suitable to
distribute traffic for a single signaling entity -whether it be MTP3 or
SCCP- to multiple application logic processing nodes.

/ Stanislav

[..snip..]
> > BTW, I wouldn't call hosting MTP3 logic in SG as "a P! C in MTP3
> stack in SG",

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands
ASAP.