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

From: Stanislav Ivanovich <[email-masked]>
Date: Fri, 13 Jan 2006 12:19:29 -0800 (PST)

Hello,
   
  In addition to the last mail:
   
  The original idea was to have one user function at ASP connected to 2 SGW (thus two independent SCCP/MTP layers). So in order to solve this we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to communicate with independent MTP/SCCP layers at SGW'es side.
   
  However here you again have one user function connected to one MTP/SCCP layer. This is exactly what the Tolga's SGP-SGP solution covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do mandate use of AS concepts with all the restrictions which imply from these protocols... which we do not have in SGP-SGP protocol.
   
  So again we have very fundamental question -> what does AS/RC concept provide us with on the interface between two MTP/SCCP relay equipped processes?
   
  It brings us just restrictions and problems nothing else!
   
  / stanislav

Stanislav Ivanovich <[email-masked]> wrote:
    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

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

[..snip..]
> > [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-.
>
> 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.

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

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

---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 Photo Books. You design it and we’ll bind it!

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Jan 2006 16:44:39 -0700

Stanislav,

Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC.
Define 1 AS per ASP only and give it RC value 0.  Make that AS an entire
point code (or network appearance for that matter).  Then this RK:AS:RC
3-tuple that bothers you so much falls away.

--brian

Stanislav Ivanovich wrote:                      (Fri, 13 Jan 2006 12:19:29)
>    The  original idea was to have one user function at ASP connected to 2
>    SGW  (thus two independent SCCP/MTP layers). So in order to solve this
>    we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to
>    communicate with independent MTP/SCCP layers at SGW'es side.
> 
> 
> 
>    However  here  you  again  have  one  user  function  connected to one
>    MTP/SCCP  layer.  This  is  exactly  what the Tolga's SGP-SGP solution
>    covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do
>    mandate  use of AS concepts with all the restrictions which imply from
>    these protocols... which we do not have in SGP-SGP protocol.
> 
> 
> 
>    So  again we have very fundamental question -> what does AS/RC concept
>    provide  us  with on the interface between two MTP/SCCP relay equipped
>    processes?
> 
> 
> 

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Fri, 13 Jan 2006 18:47:49 -0800 (PST)

Dear Brian and Tolga,
   
  First, thank you Tolga and Brian, indeed very much for your great contribution and patience both of you show to all of us SIGTRAN implementors every single day by answering long questions!
   
  Please, I kindly ask you to have just a little bit more patience with this (in my view) very essential issue. As we have seen here whatever question one arise (in this case multiple SG'es or something else) he/she will finish at the core of the issue which I am to be honest very afraid of.

  Brian,
   
  I really see no problems in understanding AS concepts when they apply on interface between MTP3/SCCP and their user-functions or in-between two user-functions whatever you call the hosting processes. However when one applies this concept in between two MTP3/SCCP instances I have tremendous conceptual problems.
   
  I understand your proposal Brian and this seems reasonable -> if one does not want/like the AS concept in between two MTP3/SCCP instances then he/she does not need to use it (to be honest I thought it was mandatory since RC was mandatory parameter is DATA messages of SUA but now I see that this is not the case). However if one vendor supports this (because he understands this) and my company does not support this (because I do not understand it) this brings my company in serious disadvantage! Therefore regardless of implementation of a particular feature the xxUA protocols offer I first need to fully understand all the capabilities/possibilities the specifications give me.
   
  My point is that in my current understanding AS concept in between two MTP3/SCCP instances brings me just restrictions (i.e. some configurations are not possible), while OTOH I get nothing "in-return"  (e.g. better redundancy... etc). In my view SGP-SGP brings you the same redundancy as ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of restrictions. Which restrictions?
   
  Here are just few of them:
   
  1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that AS represents an SS7 destination. However in MTP3/SCCP networks relay can be easily built because when one sends traffic it is irrelevant what is the state of the sending entity. What only matters is the accessibility state of remote destination.
  For example if I have SGP connected to ASP equipped with relay which serves local user for 2-100 and supports relay for 2-200 then according to xxUA specifications ASP must not send (!) traffic until it is not prepared to receive any. So ASP has to activate its (local) receiver for 2-100 just to make 2-200 possible to send traffic over it to SGP!?! Why this?
  This would imply that ASP has to register 2-200 at SGP also what is very different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender sending over relay and receiving traffic over another independent relay.
   
  My comment is -> This has serious consequence on building of relay networks based on these AS principles. It is obvious why in both M3UA and SUA specifications it is explicitly said ASP is not allowed to send (!) until it is activated itself within an AS at SGP (thus be able to receive) -> this is how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP layers then they will not be able to either send or receive traffic. However if we do not understand AS'es as MTP3/SCCP user functions but as SS7 addresses in between two MTP3/SCCP instances then this becomes serious restriction.
  Note that removing restriction for ASP/IPSP to send (!) traffic regardless of its activation within an AS is not "administrative" but has serious technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE to DOWN state...
   
  2) In traditional MTP/SCCP networks one can have destination SPC1 reachable over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for example.
  However by having the AS concept one is not allowed to have at SPCx place (for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and STP2 is supporting AS2. Because of resolution problems at SPCx place which must have AS configuration in this way: AS1 (SPC1) supported by STP1 and STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1 place!
  This kind of influence of one node on the configuration of other one you cannot find in traditional SS7 networks! Another practical problem!
   
  3) Please Brian, I kindly ask you to make your opinion about this (I would very much appreciate opinions of other SUA RFC co-authors as well!) -> if we allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against basic definition in the SUA paper itself:
   
  e.g. SUA RFC section 1.2.2. "Terminology":
  "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion."
   
  but even more -> this is very serious conceptual problem!
   
  Why do we define several process types and 2 different protocols if there is no difference between the processes?
  By reading all the threads last weeks I see that even ASP can send SSNM messages towards SGP, IPSP can send and receive SSNM so actually even the difference between the protocols themselves disappears!
  This is very serious conceptual problem for which I haven't still received any convincing answer -> the only answers I received are these:
  ----------------------------------------
  [John Loughney]
  "Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process."
  ----------------------------------------
  [John Loughney]
  "The notion of a process, IMO, is an implementation issue - different OSes may behave different."
  ----------------------------------------
  see thread "[Sigtran] AS concepts and Relay in SUA and M3UA"
   
  I am really very sorry but this does not sound very convincing, does it?

  4) If the essence of the AS concept is a redundancy concept (AS is served by several signaling processes) then there is no redundancy scheme which SGP-SGP concept does not provide and which could be provided by existing protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is that it does not suffer from the restrictions/problems described in point 1-3 above.
  However SGP-SGP concept provides us with the resolution of all the problems described in points 1-3 above and at the same time it preserves the existing protocols and keeps the signaling process definition clear and consistent!

  Tolga,
  Thank you for your comments!
   
  I do not only understand this:
   
  [Tolga Asveren]
  "AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity."
   
  In my view this is not effectively possible. Yes, one can have AS configured as User Part of SCCP SSN (i.e. granularity below SPC). However, in my view, this does not imply that relay based on this is effectively possible!
   
  This is for the following reasons:
   
  1) How would STP based on finer granularity support this kind of management? When a process receives DUPU indicating UPU or SSP then it will not try to divert traffic to another "STP" since it assumes that the user function is dead rather then STP connection to it. Especially if we are to relay that UPU/SSP message into SS7 network...
   
  2) Different types of traffic granularity require support for different types of Traffic Management in order to support relay based on different granularities.
  ANSI MTP is a good example -> there you can find the concept of Cluster Destinations. However the essence of this concept is that it is unique granularity across all the STP nodes which is not the subject of "bilateral" agreement between two adjacent STP nodes what we have with IPSP processes equipped with relay capability.
  In other words in ANSI MTP networks all the STP across the network that is to use Cluster concept use the same (!) traffic granularity which is supported by the same Traffic Management which is not subject to agreement between two STP nodes but spans across the whole network.
  In xxUA networks we have management by SSNM and AS is the agreement between two adjacent nodes... All in all - in my opinion not very efficient...

  Thank you both Brian and Tolga once again for your great support to SIGTRAN community as well as your patience!
   
  with best regards/ Stanislav Ivanovich

"Brian F. G. Bidulock" <[email-masked]> wrote:
  Stanislav,

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Jan 2006 02:15:35 -0700

Stanislav,

I think you are still way off base by thinking that the AS is so foreign
to SS7.  Think of an RK:AS:RC 3-tuple as identifying an MTP-SAP or
SCCP-SAP.

An SCCP-User at an SCCP-SAP does track the state of remote SCCP-SAPs
(Users) of which it is concerned (i.e., that it sends to), and those
are, in all but the most exceptional of cases, the SCCP-SAPs that send
to it.  Nevertheles, the RK:AS:RC simply identifies the SCCP-SAP and is
therefore, really just an SCCP-SAPI.  For many SS7 implementations, the
SCCP-SAPI is just Network Identifier, Point Code and Subsystem Number.
For SUA it can also be IP Address and be restricted further to a Global
Title range.

The same is true for M3UA.  An MTP-User at an MTP-SAP does track the
state of remote MTP-SAPs (Users) (again to which it sends), and those
are, again, in all but the most exceptional of cases, the MTP-SAPs that
send to it.  Nevertheless, the RK:AS:RC simply identifies the MTP-SAP
and is therefore, really just an MTP-SAPI.  Also, for may SS7
implementations, the MTP-SAPI is a Network Identifier, Point Code an and
SI value.  For some, it is just a Network Identifier and Point Code.
For others it is a Network Identifier.

Just because you can define any Routing Key under the Sun does not mean
that all of them will be useful or even rational.  Certainly the most
useful ones are those that correspond to SS7 MTP-SAPs and SCCP-SAPs.
Finer granularity allows distribution of applications over a broader
number of hosts than is otherwise possible, without allocation of unique
point codes.  Because some National point code numbering spaces are
exhausted, providing the capability of distributing applications without
requiring point code assignment is a necessary evil.

I really don't see any limitations with the RK:AS:RC approach to
MTP-SAPIs and SCCP-SAPIs.  In fact, a single RK:AS:RC can identify
multiple MTP-SAPs or SCCP-SAPs and, therefore, better identifies the
user behind the SAPs instead of just the SAPs themselves, as would be
accomplished by only addressing individual SAPs.

Now, MTP Transfer can be large in scope (i.e., entire National
signalling networks at a primary STP), and a RK based on NA alone would
permit this.  SCCP, OTOH, is not so large in scope.  SCCP Relay can be
as granular as the coupling of specific connection sections for protocol
class 2 and 3 relay.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 16 Jan 2006 08:29:48 -0500

Stanislav,

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

Dear Brian and Tolga,

First, thank you Tolga and Brian, indeed very much for your great
contribution and patience both of you show to all of us SIGTRAN implementors
every single day by answering long questions!

Please, I kindly ask you to have just a little bit more patience with this
(in my view) very essential issue. As we have seen here whatever question
one arise (in this case multiple SG'es or something else) he/she will finish
at the core of the issue which I am to be honest very afraid of.

Brian,

I really see no problems in understanding AS concepts when they apply on
interface between MTP3/SCCP and their user-functions or in-between two
user-functions whatever you call the hosting processes. However when one
applies this concept in between two MTP3/SCCP instances I have tremendous
conceptual problems.

I understand your proposal Brian and this seems reasonable -> if one does
not want/like the AS concept in between two MTP3/SCCP instances then he/she
does not need to use it (to be honest I thought it was mandatory since RC
was mandatory parameter is DATA messages of SUA but now I see that this is
not the case). However if one vendor supports this (because he understands
this) and my company does not support this (because I do not understand it)
this brings my company in serious disadvantage! Therefore regardless of
implementation of a particular feature the xxUA protocols offer I first need
to fully understand all the capabilities/possibilities the specifications
give me.
[TOLGA]Actually using one RK on an association does not change anything much
in terms of using "AS concept". It still is there, just implicitly
identified.

My point is that in my current understanding AS concept in between two
MTP3/SCCP instances brings me just restrictions (i.e. some configurations
are not possible), while OTOH I get nothing "in-return"  (e.g. better
redundancy... etc). In my view SGP-SGP brings you the same redundancy as
ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of
restrictions. Which restrictions?

1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that
AS represents an SS7 destination. However in MTP3/SCCP networks relay can be
easily built because when one sends traffic it is irrelevant what is the
state of the sending entity. What only matters is the accessibility state of
remote destination.
For example if I have SGP connected to ASP equipped with relay which serves
local user for 2-100 and supports relay for 2-200 then according to xxUA
specifications ASP must not send (!) traffic until it is not prepared to
receive any. So ASP has to activate its (local) receiver for 2-100 just to
make 2-200 possible to send traffic over it to SGP!?! Why this?
This! would imply that ASP has to register 2-200 at SGP also what is very
different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender
sending over relay and receiving traffic over another independent relay.

My comment is -> This has serious consequence on building of relay networks
based on these AS principles. It is obvious why in both M3UA and SUA
specifications it is explicitly said ASP is not allowed to send (!) until it
is activated itself within an AS at SGP (thus be able to receive) -> this is
how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP
layers then they will not be able to either send or receive traffic. However
if we do not understand AS'es as MTP3/SCCP user functions but as SS7
addresses in between two MTP3/SCCP instances then this becomes serious
restriction.
Note that removing restriction for ASP/IPSP to send (!) traffic regardless
of its activation within an AS is not "administrative" but has serious
technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE
to DOWN state...
[TOLGA]It is clear that ASP/SGP interface mimics MTP3/MTP-User and
SCCP/SCCP-User interfaces for M3UA and SUA respectively. Hence, the
corresponding MTP3, SCCP logic resides in SG. This is a nice model if SG
does not act as STP.If SG acts as STP, MTP3 logic for AS is hosted at SG. As
it stands right now, there is no relaying based on ASP/SGP model in
M3UA -what "SUA relay" really means is a question mark to me, I personally
think it probably is something similar to SG-SG for SUA based on PC+
SSN routing. IPSP for M3UA does not support realying and I think it doesn't
for SUA as well.
If one looks to the relationship between two MTP3-instances, one sees that
it is a peer-to-peer relationship between two network layer entities. Such a
relationship supports relaying.
The relationship between  MTP3/MTP3-User is a client/server relationship and
does not support relaying.
The relationship between two AS is a special one, is peer-to-peer but on
application level and thus it is not logical to think of relaying there on
signaling transport level.

2) In traditional MTP/SCCP networks one can have destination SPC1 reachable
over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for
example.
However by having the AS concept one is not allowed to have at SPCx place
(for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot
be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and
STP2 is supporting AS2. Because of resolution problems at SPCx place which
must have AS configuration in this way: AS1 (SPC1) supported by STP1 and
STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1
place!
This kind of influence of one node on the configuration of other one you
cannot find in traditional SS7 networks! Another practical problem!
[TOLGA]My first question to you is, why do you think that relaying using AS
constructs is supported? It isn't -I excluse SUA realy here because I don't
know what it officially means-.

!
3) Please Brian, I kindly ask you to make your opinion about this (I would
very much appreciate opinions of other SUA RFC co-authors as well!) -> if we
allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against
basic definition in the SUA paper itself:

e.g. SUA RFC section 1.2.2. "Terminology":
"IP Server Process (IPSP) - A process instance of an IP-based application.
An IPSP is essentially the same as an ASP, except that it uses SUA in a
peer-to-peer fashion."

Why do we define several process types and 2 different protocols if there is
no difference between the processes?
By reading all the threads last weeks I see that even ASP can send SSNM
messages towards SGP, IPSP can send and receive SSNM so actually even the
difference between the protocols themselves disappears!
[TOLGA]This is not true, ASP can send only SCON -which IMO is a bug in
M3UA/SUA, we should have had ASPCONG from very early on, Brian started to
work on a draft for this-. The same holds true between IPSPs.

This is very serious conceptual problem for which I haven't still received
any convincing answer -> the only answers I received are these:
----------------------------------------
[John Loughney]
"Process-types, in my view, are illustrative text, to give an implementor an
idea of what we are talking about - however, they are not meant that each
capability MUST be implemented as a separate process."
----------------------------------------
[John Loughney]
"The notion of a process, IMO, is an implementation issue - different OSes
may behave different."
----------------------------------------
see thread "[Sigtran] AS concepts and Relay in SUA and M3UA"

4) If the essence of the AS concept is a redundancy ! concept (AS is served
by several signaling processes) then there is no redundancy scheme which
SGP-SGP concept does not provide and which could be provided by existing
protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is
that it does not suffer from the restrictions/problems described in point
1-3 above.
However SGP-SGP concept provides us with the resolution of all the problems
described in points 1-3 above and at the same time it preserves the existing
protocols and keeps the signaling process definition clear and consistent!

Tolga,

[Tolga Asveren]
"AFAICS, the main advantage of ASP/SGP model is to allow routing on AS
level, i.e. in sub-PC granularity."

In my view this is not effectively possible. Yes, one can have AS co!
nfigured as User Part of SCCP SSN (i.e. granularity below SPC). However, in
my view, this does not imply that relay based on this is effectively
possible!

1) How would STP based on finer granularity support this kind of management?
When a process receives DUPU indicating UPU or SSP then it will not try to
divert traffic to another "STP" since it assumes that the user function is
dead rather then STP connection to it. Especially if we are to relay that
UPU/SSP message into SS7 network...
[TOLGA]I meant it in the other direction, i.e. for messages from SG to ASPs.
The practical value of this depends also on the internal communication
mechanisms of ASPs but still could be useful is SLS type of routing is not
good enough, e.g. one has two applications on different SSN and prefers that
ASP1 receives traffic for app1 and ASP2 for app2 unless one of them fails.
This of course is only for ASP/SGP communication.

2) Different types of traffic granularity require support for different
types of Traffic Management in order to support relay based on different
granularities.
ANSI MTP is a good example -> there you can find the concept of Cluster
Destinations. However the essence of this concept is that it is unique
granularity across all the STP nodes&nb! sp;which is not the subject of
"bilateral" agreement between two adjacent STP nodes what we have with IPSP
processes equipped with relay capability.
In other words in ANSI MTP networks all the STP across the network that is
to use Cluster concept use the same (!) traffic granularity which is
supported by the same Traffic Management which is not subject to agreement
between two STP nodes but spans across the whole network.
In xxUA networks we have management by SSNM and AS is the agreement between
two adjacent nodes... All in all - in my opinion not very efficient...
[TOLGA]IPSP does not support relaying and if you look to the definition of
it it simply doesn't  make sense forcing it to support relaying. It is a
direct relationship between two applications and any necessary relaying
should happen on application layer, not on signaling transport.
Overall, I think I agree with you.

Thank you both Brian and Tolga once again for your great support to SIGTRAN
community as well as your patience!

--brian

> MTP/SCCP layer. This ! is exactly what the Tolga's SGP-SGP solution

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

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