Subject: [Sigtran] AS concepts and Relay in SUA and M3UA

From: Stanislav Ivanovich <[email-masked]>
Date: Wed, 14 Dec 2005 09:31:52 -0800 (PST)

Hello SIGTRAN experts,
   
  I kindly ask You to help me clarify some important AS and relay concepts of both M3UA and SUA. I have noticed a question with subject "AS, RK , RC concepts 
  in SE model" that Ilie Glib posted on 6th of December and discussion there raised serious doubts in my understanding of particularly SUA relay.
  It looks like that Brian's and Tolga's answers maybe are aligned with relevant specifications (M3UA and SUA) but I not quite sure since there might be 
  inconsistencies in the specifications.
  Questions:
  1) Both M3UA and SUA specifications in the same sec. 4.3.4.3. "ASP Active Procedures" say:
  "By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). The ASP SHOULD NOT send 
  Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss."
  
I have a configuration of SGP-ASP. SE model used. 2 AS'es registered, namely AS1:DPC=2-100 and AS2:DPC=2-200. I am considering both M3UA as well as SUA. ASP 
  has activated AS1 but not AS2 by sending ASP ACTIVE indicating RC1 only.
  Does the reference above mean that after ASP activates AS1 but not AS2 that it is allowed to send towards SGP but only indicating OPC=2-100 for M3UA or 
  SPC=2-100 in Source Address for SUA but not indicating OPC=2-200 for M3UA or SPC=2-200 in Source Address for SUA?
  Is the answer the same for M3UA and SUA?
   
  2) According to Your answers sent to Ilie in IPSP-IPSP configuration in SE model one must install the same RK at both processes and the RK specify the SS7 
  relation(s). I have this configuration in SE model:
  
IPSP-A<---------------->IPSP-B
SPC-a1                  SPC-b
SPC-a2
  AS1 = SPC-a1 <-> SPC-b
AS2 = SPC-a2 <-> SPC-b
  and IPSP-A activates AS1 but keeps AS2 inactive.
  Does the SUA/M3UA reference in question 1 mean that IPSP-A is allowed to send towards SPC-b using OPC=SPC-a1 for M3UA (or SPC=SPC-a1 in Source Address for 
  SUA) but is not allowed to send towards SPC-b using OPC=SPC-a2 for M3UA (or SPC=SPC-a2 in Source Address for SUA)?
  Is the answer the same for M3UA and SUA?
   
  3) If the answers for questions 1 and 2 is "Yes" that implies that the concept of Application Servers (which is supported by corresponding ASP procedures) 
  used by both M3UA and SUA seems to be extremely unfriendly to the relay concept as used by traditional SS7 networks.
  Essentially in traditional SS7 networks traffic is managed separately and independently in both directions while in the AS concept the traffic (at least in 
  SE model which is mandatory!) is managed symmetrically. This important asymmetrical principle of SS7 is reflected on both external as well as API internal 
  interfaces.
  Thus for example TFP message sent by node A to node B indicating unavailability of a destination C means that node B cannot reach node C via node A. However 
  the opposite direction (if exists at all) is managed separately. The same is valid for SSP messages of SCCP.
  The same principles are kept for API internal interfaces. Thus when MTP indicates MTP_PAUSE to a User Part it means that the User Part is not allowed to send 
  towards the indicated destination. However this does not mean that the User Part cannot receive a message from the peer at the indicated concerned 
  destination. The same is valid for SCCP N_PCSTATE and N_STATE indications.
  However in the AS concept of xxUA networks one ASP TM message affects the traffic in both directions (if the answers is "Yes" for the previous questions).
I noticed in the discussion You have with Ilie Glib that that You claim that in DE model this management is asymmetrical!
  Does that mean that the SUA/M3UA reference in question 1 is not valid for DE model?
  If so, why is that not indicated then?
  If You still claim that DE model is asymmetrical unlike SE model Why we do not have this asymmetrical management for SGP-ASP interface as well since DE model 
  is only for IPSP-IPSP interface?
   
  4) Why do I claim that the AS concept is extremely unfriendly to the Relay concept? Because in the answer to Ilie Glib as well as in xxUA specifications You 
  claim that (at least in the mandatory SE model) that You have to specify SS7 relations, namely OPC and DPC for IPSP-IPSP configurations.
  Note that SUA specification differs from M3UA since it explicitly mentions the concept of Relay function in sec. 1.4.6. "Relay function" (SUA RFC). There it 
  says that "The determination of the next hop...may also be based on...pointcode contained in the called party address".
  
How could SUA relay be practically achieved if we strictly follow existing AS concept You want to follow and if You have a network of several dozens of 
  processes?
  In SS7 network it is irrelevant which node sends a message - the only thing that matters is whether the addressed destination is accessible. However here in 
  xxUA networks You have to specify all the OPC-DPC combinations that an AS supports! For a network of dozen processes it might be 100's of combinations... 
  that have to be supported!
   
  5) In one of the answers to Ilie Glib You also claimed that there is no MTP management performed by SUA processes equipped with Relay capability. If we look 
  into SUA specification there is no section which describes exchange of DUNA, DAVA messages between two IPSP processes which are equipped with SUA relay.
  However one might consider this as a lack of specification and/or inconsistency with other parts of the specification! Otherwise how do You mean it is 
  possible to support the following SUA configuration:
  
                     ----------           ---------
            ---------| IPSP-A |-----------| 2-200 |
           /         ----------\         /---------
          /                     \       /  IPSP-2
---------/                       \     /
| 2-100 |                         -----
---------\                       /     \
 IPSP-1   \                     /       \
           \         ----------/         \---------
            ---------| IPSP-B |-----------| 2-300 |
                     ----------           ---------
                                             IPSP-3
  
SCCP application at IPSP-1 place communicates with SCCP applications at IPSP-2 and IPSP-3 places by using their SPC addresses. The communication goes over 
  IPSP SUA relay processes IPSP-A and IPSP-B which act as proxies between the processes, namely relay processes represent IPSP-2 and IPSP-3 to IPSP-1 and 
  IPSP-1 to IPSP-2 and IPSP-3. We intend to use SE model.
  We define:
  AS = (2-100 <-> 2-200) and (2-100 <-> 2-300)
at IPSP-1, IPSP-A and IPSP-B places.
  
AS2 = 2-100 <-> 2-200
at IPSP-2, IPSP-A and IPSP-B places.
  
AS3 = 2-100 <-> 2-300
at IPSP-3, IPSP-A and IPSP-B places.
  
If the SCTP association between processes IPSP-B and IPSP-3 fails how can the SUA relay process IPSP-B indicate to IPSP-1 process its incapability to support 
  relation 2-100 <-> 2-300 while the relation 2-100 <-> 2-200 is still available? One would normally expect that IPSP-B sends DUNA message to IPSP-1 indicating 
  inaccessibility of 2-300.
  However this procedures are not described in the SUA RFC! And You claim that there are no DUNA, DAVA... messages to perform MTP management on IPSP-IPSP 
  interface even if You have SUA relay!
  Note that if these SCCP applications reside in classical SS7 network and if IPSP-A and IPSP-B nodes are MTP STP nodes (MTP relay) then SCCP application in 
  node 1 would be isolated from this failure by MTP layer which would perform the re-configuration.
  In another words it is true that SCCP application in node 1 would not be informed by N-PCSTATE primitive of SCCP but the failure would be catered by the 
  lower (MTP) layer.
  The question is, shouldn't SUA then isolate its users from this failure by performing the same job as MTP does in this case? In another words shouldn't SUA 
  relay (and SUA gateway) include MTP STP functionality? That would imply that You need  exchange of SSNM messages between two IPSP processes what You claim is 
  not allowed!?!
  Otherwise what should IPSP-B node do in this case (if not to send DUNA message)?
  Actually, the ultimate question is -> how should SUA relay work after all? (especially considering AS concept, ASP/IPSP traffic management procedures in the 
  multiple AS'es per signalling process environemet)
  
6) Is there at least "hidden" - if not explicit - M3UA relay in M3UA specifications? Is it allowed to send SSNM messages between 2 IPSP processes for M3UA?
   
  7) Does the reference to SUA/M3UA specification in question 1 means that if an SUA AS is specified as Destination_Address_GT=xyz that if the AS is not active 
  the process is not allowed to send any message with Source_Address_GT=xyz?
   
  I would very much appreciate that Your answers either contain references to the existing specifications, or if these are to be updated then some indication 
  that the issues (if any) would be addressed in the next version of the specification(s) (e.g. "SUA Implementor's guide").
  
Thank You very much in advance for Your answers!
   
  best regards/ Stanislav Ivanovich

---------------------------------
Yahoo! Shopping
 Find Great Deals on Holiday Gifts at Yahoo! Shopping 

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 14 Dec 2005 13:12:29 -0500

Stanislav,

IPSP is a peer-to-peer model, there is no relaying functionality. It is used
only to enable communication between two AS in IP domain without any
intermediares.

Please see below for more answers.

   Thanks,
   Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stanislav Ivanovich
Sent: Wednesday, December 14, 2005 12:32 PM
To: [email-masked]
Subject: [Sigtran] AS concepts and Relay in SUA and M3UA

Hello SIGTRAN experts,

I kindly ask You to help me clarify some important AS and relay concepts of
both M3UA and SUA. I have noticed a question with subject "AS, RK , RC
concepts
in SE model" that Ilie Glib posted on 6th of December and discussion there
raised serious doubts in my understanding of particularly SUA relay.
It looks like that Brian's and Tolga's answers maybe are aligned with
relevant specifications (M3UA and SUA) but I not quite sure since there
might be
inconsistencies in the specifications.
Questions:
1) Both M3UA and SUA specifications in the same sec. 4.3.4.3. "ASP Active
Procedures" say:
"By sending an ASP Active Ack message, the SGP or IPSP is now ready to
receive and send traffic for the related Routing Context(s). The ASP SHOULD
NOT send
Data or SSNM messages for the related Routing Context(s) before receiving an
ASP ! Active Ack message, or it will risk message loss."

I have a configuration of SGP-ASP. SE model used. 2 AS'es registered, namely
AS1:DPC=2-100 and AS2:DPC=2-200. I am considering both M3UA as well as SUA.
ASP
has activated AS1 but not AS2 by sending ASP ACTIVE indicating RC1 only.
Does the reference above mean that after ASP activates AS1 but not AS2 that
it is allowed to send towards SGP but only indicating OPC=2-100 for M3UA or
SPC=2-100 in Source Address for SUA but not indicating OPC=2-200 for M3UA or
SPC=2-200 in Source Address for SUA?
Is the answer the same for M3UA and SUA?
[TOLGA]SE model refers to SE-IPSP. there is only one type of SGP/ASP
relationship. ASP SHOULD send DATA only for an ACTIVE RK, so the answer to
your question is "yes" -for SUA, the situation is a bit different for GT
based RKs-.

2) According to Your answers sent to Ilie in IPSP-IPSP configuration in SE
model one must install the same RK at both processes and the RK specify the
SS7
relation(s). I have this configuration in SE model:

IPSP-A<---------------->IPSP-B
SPC-a1                  SPC-b
SPC-a2
AS1 = SPC-a1 <-> SPC-b
AS2 = SPC-a2 <-> SPC-b
and IPSP-A activates AS1 but keeps AS2 inactive.
Does the SUA/M3UA reference in question 1 mean that IPSP-A is allowed to
send towards SPC-b using OPC=SPC-a1 for M3UA (or SPC=SPC-a1 in Source
Address for
SUA) but is not allowed to send towards SPC-b using OPC=SPC-a2 for M3UA (or
SPC=SPC-a2 in Source Address for SUA)?
Is the answer the same for M3UA and SUA?
[TOLGA]The answer is again "yes".

3) If the answers for questions 1 and 2 is "Yes" that implies that the
concept of Application Servers (which is supported by corresponding ASP
procedures)
used by both M3UA and SUA seems to be extremely unfriendly to the relay
concept as used by traditional SS7 networks.
[TOLGA]Please note that neither SGP/ASP not IPSP/IPSP relationship
corresponds to MTP3/MTP3 relationship of SS7 network. ASP/SGP corresponds to
MTP3/MTP3-User Part realtionship and IPSP/IPSP can be thought as direct
communication between SS7 User parts. Only SG-SG communication mimics
MTP3/MTP3 communication.

Esse! ntially in traditional SS7 networks traffic is managed separately and
independently in both directions while in the AS concept the traffic (at
least in
SE model which is mandatory!) is managed symmetrically. This important
asymmetrical principle of SS7 is reflected on both external as well as API
internal
interfaces.
Thus for example TFP message sent by node A to node B indicating
unavailability of a destination C means that node B cannot reach node C via
node A. However
the opposite direction (if exists at all) is managed separately. The same is
valid for SSP messages of SCCP.
[TOLGA]As said above, only SG-SG communication mimics MTP3/MTP3 relationship
and thus only it functions the way you described.

The same principles are kept for API internal interfaces. Thus when MTP
indicates MTP_PAUSE to a User Part it means that the User Part is not
allowed to send
towards the indicated destination. However this does not mean that the User
Part cannot receive a message from the peer at the indicated concerned
destination. The ! same is valid for SCCP N_PCSTATE and N_STATE indications.
However in the AS concept of xxUA networks one ASP TM message affects the
traffic in both directions (if the answers is "Yes" for the previous
questions).
I noticed in the discussion You have with Ilie Glib that that You claim that
in DE model this management is asymmetrical!
Does that mean that the SUA/M3UA reference in question 1 is not valid for DE
model?
If so, why is that not indicated then?
If You still claim that DE model is asymmetrical unlike SE model Why we do
not have this asymmetrical management for SGP-ASP interface as well since DE
model
is only for IPSP-IPSP interface?
[TOLGA]The asymmetry in DE-IPSP is not a desired behavior but can be
considered more as a shortcoming. Considering that SGP/ASP interface mimics
MTP3/MTP3-User Part interface, I don't see the reason why it should behave
asymmetric.

4) Why do I claim that the AS concept is extremely unfriendly to the Relay
concept? Because in the answer to Ilie Glib as well as in xxUA
specifications You
claim that (at least in the mandatory SE model) that You have to specify SS7
relat! ions, namely OPC and DPC for IPSP-IPSP configurations.
Note that SUA specification differs from M3UA since it explicitly mentions
the concept of Relay function in sec. 1.4.6. "Relay function" (SUA RFC).
There it
says that "The determination of the next hop...may also be based
on...pointcode contained in the called party address".
[TOLGA]SUA does not define relay functionality for IPSP communication.

How could SUA relay be practically achieved if we strictly follow existing
AS concept You want to follow and if You have a network of several dozens of
processes?
In SS7 network it is irrelevant which node sends a message - the only thing
that matters is whether the addressed destination is accessible. However
here in
xxUA networks You have to specify all the OPC-DPC combinations that an AS
supports! For a network of dozen processes it might be 100's of
combinations...
that have to be supported!

5) In one of the answers to Ilie Glib ! You also claimed that there is no
MTP management performed by SUA processes equipped with Relay capability. If
we look
into SUA specification there is no section which describes exchange of DUNA,
DAVA messages between two IPSP processes which are equipped with SUA relay.
However one might consider this as a lack of specification and/or
inconsistency with other parts of the specification! Otherwise how do You
mean it is
possible to support the following SUA configuration:

                     ----------           ---------

SCCP application at IPSP-1 place communicates with SCCP applications at
IPSP-2 and IPSP-3 places by using their SPC addresses. The communication
goes over
IPSP SUA relay processes IPSP-A and IPSP-B which act as proxies between the
processes, namely relay processes represent IPSP-2 and IPSP-3 to IPSP-1 and
IPSP-1 to IPSP-2 and IPSP-3. We intend to use SE model.
We define:
AS = (2-100 <-> 2-200) and (2-100 <-> 2-300)
at IPSP-1, IPSP-A and IPSP-B places.

AS2 = 2-100 <-> 2-200

AS3 = 2-100 <-> 2-300

If the SCTP association between processes IPSP-B and IPSP-3 fails how can
the SUA relay process IPSP-B indicate to IPSP-1 process its incapability to
support
relation 2-100 <-> 2-300 while the relation 2-100 <-> 2-200 is still
available? One would normally expect that IPSP-B sends DUNA message to
IPSP-1 indicating
inaccessibility of 2-300.
However this procedures are not described in the SUA R! FC! And You claim
that there are no DUNA, DAVA... messages to perform MTP management on
IPSP-IPSP
interface even if You have SUA relay!
Note that if these SCCP applications reside in classical SS7 network and if
IPSP-A and IPSP-B nodes are MTP STP nodes (MTP relay) then SCCP application
in
node 1 would be isolated from this failure by MTP layer which would perform
the re-configuration.
In another words it is true that SCCP application in node 1 would not be
informed by N-PCSTATE primitive of SCCP but the failure would be catered by
the
lower (MTP) layer.
The question is, shouldn't SUA then isolate its users from this failure by
performing the same job as MTP does in this case? In another words shouldn't
SUA
relay (and SUA gateway) include MTP STP functionality? That would imply that
You need  exchange of SSNM messages between two IPSP processes what You
claim is
not allowed!?!
Otherwise what should IPSP-B node do in this case (if not to send DUNA
message)?
Actually, the ultimate question is -> how should SUA relay work after all?
(especially considering AS concept, ASP/IPSP traffic management procedures
in the
multiple AS'es per signalling process environemet)

6) Is there at least "hidden" - if not explicit - M3UA relay in M3UA
specifications? Is it allowed to send SSNM messages between 2 IPSP processes
for M3UA?
[TOLGA]No, although this is not 100% clear in the specifications -yet-. Only
SCON is used to convey congestion information and hopefully we can replace
it soon with an ASPTM.

7) Does the reference to SUA/M3UA specification in question 1 means that if
an SUA AS is specified as Destination_Address_GT=xyz that if the AS is not
active
the process is not allowed to send any message with Source_Address_GT=xyz?
[TOLGA]As far as I know, for GT based RKs there is no such restriction.

I would very much appreciate that Your answers either contain references to
the existing specifications, or if these are to be updated then some
indication
that the issues (! if any) would be addressed in the next version of the
specification(s) (e.g. "SUA Implementor's guide").

Yahoo! Shopping

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Dec 2005 11:58:21 -0700

Tolga,

> [TOLGA]SUA does not define relay functionality for IPSP communication.

Well... I believe it does.  Only M3UA restricted away relay functionality.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 14 Dec 2005 13:47:10 -0500

Brian,

There is relay functionality defined for SUA SGP/ASP, but I don't think
there has been some official work done yet in terms of SUA IPSP relay
functionality -I may be wrong though-. As far as I can see, SUA-IPSP
directly mimics M3UA-IPSP, that was the rationale behind my statement.

    Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, December 14, 2005 1:58 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Dec 2005 11:39:09 -0700

Stanislav,

You read too much into this passage.  It simply means that if an ASP sends
a message to an SGP labelled with an RC value that corresponds to an AS for
which it is in the ASP Inactive state, it risks the message being discared.

For example, the ASP should not send ASP Active (RC1) followed immediately
by DATA (RC1) or it risks the DATA message being discarded.  It should first
await ASP Active Ack (RC1) before sending DATA (RC1), regardless of what is
in the DATA.

--brian

Stanislav Ivanovich wrote:                      (Wed, 14 Dec 2005 09:31:52)

--X-snip-X--
>    receive  and  send traffic for the related Routing Context(s). The ASP
>    SHOULD NOT send
>    Data  or  SSNM  messages  for  the  related  Routing Context(s) before
>    receiving an ASP ! Active Ack message, or it will risk message loss."
> 
--X-snip-X--

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