Subject: Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP

From: [email-masked]
Date: Fri, 25 Oct 2002 15:08:04 +0530

Kamesh,
DUPU is always used in the forward direction, i.e. from SGP to ASP to convey the
state of remote peer-MTP3 user part in the SS7 network.
Since M3UA at SG already maintains the availability state of remote ASP
(Active/Inactive),
there is no requirement of DUPU exchange in the backward direction. (ASP_ACTIVE
implies that application traffic is active). For the scenaio given by you, SG
M3UA
would determine the routing key and find that there is no  ASP in ACTIVE state
for
that. This will trigger sending of UPU message by SG towards  the ss7 network.
Note that this action would be implementation dependent.

regards
-neeraj

[email-masked] on 10/25/2002 09:43:29 AM

To:   [email-masked]
cc:    (bcc: Neeraj Jain/HSS)

Subject:  [Sigtran] M3UA(rfc 3332) DUPU from ASP

Hi,
     In fig. below ASP is actively processing traffic for AS(DPC X).
                SGP sends a data message to ASP for user ISUP. If ASP is
                not able to indicate the data message to ISUP user can ASP
                send DUPU message to SGP with affected point code X and
                 user ISUP.No were in RFC 3332 it is mentioned that ASP can
                send DUPU message to SGP. Please clearify

                                        AS(DPC X)
    SG (DPC Y)
                                      +-------------------+
  +----------+                        |+--------+--------+|
  |          |                        ||        |        ||
  |          |                        ||  SCCP  |    ISUP||
  |   SGP    +------------------------+|        |        ||
  |          |                        |+--------+--------+|
  |          |                        ||      M3UA       ||
  +----------+                        |+-----------------+|
                                      +-------------------+
                                              ASP
Regards
Kamesh

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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

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

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 28 Oct 2002 08:26:58 -0500

Sandeep,

How ASPs declare the traffic range they want to serve or to stop to serve is
via ASPTM. Using SSNM for this is breaking model. Furthermore I don't think
sending DUPU from ASP to SGP is necessary (in fact I remember this was
discussed a few months ago and the decision was not to change anything),
because the protocol has the necessary flexibility also to provide user part
level granularity with DPC+SIO RKs. If one chooses to use DPC based RK, it
is a configuration decision and I don't see a need for a change in the
protocol. As you also pointed out, M3UA does not put any restrictions on the
type of the route key, so there is no problem and even if there were, then
it should be solved within the boundaries of ASPTM.

     Tolga 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 28, 2002 4:25 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> 
> 
> 
> 
> 
> Hi Brian,
> 
> DPC only Routing Key type is allowed in M3UA specifications 
> and I am aware of
> the same being used in some of the SIGTRAN based products.
> So, it does look reasonable to me for M3UA specifications to 
> allow (if not
> recommend) implementations to send DUPU from ASP to SG side also.
> 
> Best Regards,
> -Sandeep
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 10/26/2002 
> 01:44:19 PM
> 
> Please respond to [email-masked]
> 
> To:   Kamesh Kaul/HSS@HSS
> cc:   [email-masked] (bcc: Sandeep Mahajan/HSS)
> 
> Subject:  Re: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> 
> 
> 
> 
> Kamesh,
> 
> Well, I suppose it was a quandry where to put it in SS7 too.  
> ISUP, for
> example has its own UPT/UPA mechanism for restoring unavailable ISUP
> peers.  At one time a general UPT/UPA mechanism was part of the MTP
> (but didn't receive much/any support in the field).
> 
> While in the now distant past there may have been some degree 
> of freedom
> between MTP and MTP-Users (i.e, implemented on completely separate
> processor subsystems), normally MTP and its users are distributed-
> embedded or on monolithic redundant (fault tolerant) systems.  So it
> is quite atypical for an MTP-User to fail independent of MTP.
> 
> For coordinated turndown/turnup of MTP-Users, there are other 
> mechanisms.
> SCCP has the mated pair configurations and the SCCP protocol supports
> replicated subssytems directly within the protocol.  For 
> ISUP, coordinated
> turndown/turnup is accomplished through circuit 
> blocking/unblocking and
> reset procedures.  I think you will find that IUSP response 
> to MTP-STATUS
> indicating an unavailable ISUP at a peer will be of little 
> use to ISUP.
> What is more important is the state of circuits between the 
> swithes and
> the correct recovery procedures involve normal ISUP circuit reset and
> blocking procedures.
> 
> I do not subscribe to "whole point code" routing keys (they are not
> mandatory).  Perhaps a proponent of DPC only routing keys, 
> such as John
> Schantz can better answer your queries in that regard.
> 
> --brian
> 
> 
> [email-masked] wrote:
> (Sat, 26 Oct 2002 11:44:30)
> >
> >
> > Hi
> >      Brian this is  true for SS7 node in SS7 domain too.but why does
> >                 SS7 node generate UPU message when it is 
> unable to notify MSU
> >                 to intended user.
> > Regards
> > Kamesh
> >
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 28 Oct 2002 08:28:50 -0500

Brian,

I don't think there is a need for a change in the protocol and furthermore
encapsulating level3 information in a level3 protocol wouldn't be elegant.

    Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, October 28, 2002 5:09 AM
> To: [email-masked]
> Why not just send UPU in a DATA message?
> 
> --brian
> 
> [email-masked] wrote:                        (Mon, 28 
> Oct 2002 14:54:33)
> > 
> > 
> > 
> > Hi Brian,
> > 
> > So, it does look reasonable to me for M3UA specifications 
> to allow (if not

---

From: [email-masked]
Date: Mon, 28 Oct 2002 19:54:36 +0530

Hi Tolga,

SCON is a SSNM message and it can also be sent from ASP to SGP. So I do not
think breaking the model is strong enough reason for having this restriction.

Best Regards,
-Sandeep

Tolga Asveren <[email-masked]> on 10/28/2002 06:56:58 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP

Sandeep,

     Tolga

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 28 Oct 2002 10:09:09 -0500

Hi Sandeep,

In fact what I think is SCON from ASP to SGP is not fitting the model. If
there is a need to tell about congestion of ASP, this better should be done
with ASPTM(with a new message). IMO, SCON from ASP to SGP direction is a
diversion from the model.

Furthermore, I would expect the congestion declaration from ASP to SGPs not
as a response to an incoming message but as a declaration, whenever
congestion happens (if declaration of congestion is necessary at all, maybe
it is enough that ASP stops serving the congested AS). This situation is
different than congestion handling in pure SS7 case. Here, it is about the
relationship between layer 3 and user parts, and Q.704 does not describe
this. There, handling of user part congestion is left implementation
dependent.

    Tolga

> Sent: Monday, October 28, 2002 9:25 AM
> To: Tolga Asveren
> Cc: [email-masked]'

---

From: [email-masked]
Date: Mon, 28 Oct 2002 20:48:38 +0530

Hi Brian,

Can you please elaborate it a bit further. In case UPU is sent as DATA message
from ASP to SG, how can SG determine it is a UPU and hence it need to convert it
into a MTP3 UPU message.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 10/28/2002 03:39:14 PM

To:   Sandeep Mahajan/HSS@HSS
cc:   Kamesh Kaul/HSS@HSS, [email-masked]

Sandeep,

--brian

[email-masked] wrote:                        (Mon, 28 Oct 2002 14:54:33)
>
>
>
> Hi Brian,
>
> DPC only Routing Key type is allowed in M3UA specifications and I am aware of
> So, it does look reasonable to me for M3UA specifications to allow (if not

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 29 Oct 2002 08:49:44 -0500

typo corrected below.

   Tolga

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, October 29, 2002 8:36 AM
> To: [email-masked]'
> Neeraj,
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, October 29, 2002 2:35 AM
> > To: [email-masked]
> > Cc: 'Tolga Asveren'; [email-masked]'
> > Brian and all,
> > 1. when SCON is sent from SGP to an ASP, it really is a 
> > translation from
> >     MTP-STATUS ( cause - signalling network congestion) but as 3332
> >     advocates that this may as well be used in reverse 
> > direction ( sec. 3.4.4).
> >     The latter is possible in 2 scanrios :
> >      a) M3UA layer itself is congested, in which case this 
> MAY well be
> >           translated to TFC and sent to ss7 n/w to reduce 
> > traffic towards
> >           the affected DPC ( Affected PC  in SCON )
> >      b) ASP is congested, in which case this should not map 
> to TFC, as
> >           this might result in reduction of traffic towards 
> > other ASPs also
> > which are
> >           also resident on the same DPC. This case for user 
> > part congestion
> > control,
> >           as Tolga also says, is not described in Q.704.
> > 
> >     IMO, case (a) makes SCON fit for SSNM while case (b) 
> > makes it fit for ASPTM,
> >     and hence the confusion.
> [TOLGA] IMO, SCON from ASP to SGP is a violation of the 
> model. Anything
> related with the traffic tange ASP serves is better ot be 
> announced with
> ASPTM. If there is a need to declare congestion then it would 
> be better to
> invent an ASPTM for it.
> For the case b), I think different. Multiple ASPs can serve
              ^^^^
               a) 
> the same AS, so
> that M3UA layer is congested at one of the ASPs shouldn't 
> cause TFC. It is
> SG which has the combined view of SPMC. So, IMO the correct 
> approach would
> be, ASPs declare congestion with a message to SG and SG 
> decides for the
> combined nodal congestion for a SPMC, like it decides for the
> availability/unavailability of SPMC. For that to work fine, a response
> mechanism, where congestion indication from ASP to SG is 
> triggered after a
> message is received, won't work. IMO, if needed, congestion 
> indication from
> ASP to SGP should be sent, whenever it occurs. SG, which has the whole
> information for the SPMC can decide to reply with TFC or not, 
> based on that
> combined SPMC view.
> > 
> > 2. Do we really see a situation, where an ASP registers with 
> > Routing key type
> > DPC only
> >      and serves more than one user parts. I don't think so. I 
> > think  each user
> > part should
> >      separately register with DPC+SIO as routing key, and 
> > thus leaves no
> > requirements
> >      for DUPU from ASP to SGP. Pls correct me if I,ve 
> missed a point.
> [TOLGA] This is a configuration decision. The protocol is clear how it
> operates. If one still wants to use it with DPC type RKs and 
> multiple user
> parts, so be it.
> > 
> > -neeraj
> > 
> > 
> > 
> > 
> > 
> > "Brian F. G. Bidulock" <[email-masked]> on 10/29/2002 
> > 02:03:19 AM
> > 
> > To:   "Javier Pastor-Balbas (ECE)" 
> > <[email-masked]>
> > cc:   "'Tolga Asveren'" <[email-masked]>, 
> "[email-masked]'"
> >       <[email-masked]> (bcc: Neeraj Jain/HSS)
> > 
> > Javier,
> > SCON was conceived as a direct translation from MTP-STATUS 
> (not TFC).
> > The MTP-User never sends MTP-STATUS-REQ, and as such, there should
> > never be a requirement for the ASP to send either SCON or 
> DUPU.  These
> > are MTP-STATUS-IND which are only sent from SG to ASP (MTP to 
> > MTP-User).
> > 
> > DPC RKs are not really SGP/ASP operation: IMO they are IPSP 
> operation,
> > 
> > --brian
> > 
> > Javier Pastor-Balbas (ECE) wrote:                 (Mon, 28 
> > Oct 2002 16:35:13)
> > > Hi Sandeep,
> > >
> > > I agree with Tolga, SCON was conceived as a direct 
> > translation from TFC in
> > > order to push information from SS7 to IP domains. The 
> > direction is indicated
> > > in section 3.4.4 of RFC3332.
> > >
> > > Cheers // Javier.
> > >
> > 
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 31 Oct 2002 14:50:33 -0500

Nitin,

> From: Nitin Vairagare [mailto:[email-masked]]
> Sent: Thursday, October 31, 2002 2:27 PM
> To: [email-masked]
> Tolga,
> I see your point in two SG case. And yes one has to be very careful
> and aware of potential side-effects and issues of their network
> architecture design. May be we should come up with guidelines draft
> or RFC when using Sigtran. Network designers should be aware of
> real issues of mis-configuiring.
> 
> For question, When I said "Implementation idependent" that was typo..
> I mean it should be left upto implementations to decide how to 
> differentiate using configuring parameter if they like to behave 
> like SGP-ASP model or SG-SG model crossing PC boundary as you 
> mentioned.
> And depending on configuration hey should take decision if 
> they want to 
> send DUPU or not. 
> 
> Can you elaborate your views on IPSP case for DUPU?
[TOLGA]My view on IPSP is, it is AS-to-AS communciation and should operate
within boundaries of ASPTM for traffic management. If the AS, one is using
is DPC/OPC based, then I would expect it to go down as a whole, if something
happens. IMO, thinking that half of an AS is down, is not logical. If user
part granularity is necesseray then RK should be defined as DPC/OPC/SI and
so one would have AS per user part. When the remote user part is gone, ASPIA
will be received and local user parts will be informed about this, local RK
analysis won't route messages for that AS, unless AS is activated again.
Depending on implementation it might be necessary to generate
MTP-STATUS-IND(Pause)primitives locally for messages destined to that AS but
this is implementation dependent. 
> Thanks,
> Nitin
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Thursday, October 31, 2002 12:24 PM
> To: [email-masked]
> Nitin,
> > From: Nitin Vairagare [mailto:[email-masked]]
> > Sent: Thursday, October 31, 2002 11:55 AM
> > To: [email-masked]
> > Hi All,
> > In a typical M3UA sigtran model, SG has layers up to MTP3
> > and the userparts are located remotely on some IP node (ASP).
> > 
> > UPU's are exchanged between MTP3 only and when they arrive at
> > MTP3, they are suppose to be converted into MTP-STATUS and send
> > to User parts. 
> > 
> > So in the model explained above, UPU received at 
> > SG shall be converted into DUPU and sent to ASP so that M3UA
> > at ASP converts it to MTP-Status and deliver it to user Part.
> > 
> > In other case when the user part at ASP goes down It is duty
> > of Its MTP3/M3UA (which is on SG) to detect that the RK is not
> > active any more and send UPU to remote MTP3 in SS7 network, if
> > it finds the RK is not active any more.
> > 
> > M3UA is acting here as codec between MTP3 at SG and Userpart 
> > at ASP.
> > 
> > Let us consider case of RK as DPC: It is very important to
> > undersatnd if this DPC is public (different from SG PC) or 
> > Same as SG or private behind SG.
> > In later two cases, model explained above is applicable
> > and the DUPU shall be sent from SG to ASP only. only difficulty
> > would be how to determine which user part is unavailable? I would
> > say configuration is messed up. You do not want to use DPC as RK 
> > when there are more than one user part. The service on ASP cannot
> > be identified uniquely anymore (breaking the RK definition). So
> > one has to be careful while configuring such network elements.
> > 
> > The former case of public DPC on ASP different from SG (SG is STP)
> > and ASP is SEP/SCP. Which is kind of slightly wiered from
> > SS7 world point of view (No MTP3 for SCP/SEP). In this case 
> > M3UA on ASP itself behaves like MTP3 for ASP and should be 
> allowed to 
> > send DUPU. It will work like UPU from one MTP3 to other. 
> > Implementation
> > can be independent.
> [TOLGA] What do you mean by "Implementation can be independent"?
> In fact the second model you mentioned (SG and AS have 
> difderent PCs) is in
> my view just forcing the regular ASP/SGP M3UA concept. It is 
> odd for me to
> cross PC boundaries between SGP/ASP for a layer3 adaptation 
> layer. That was
> also one of the reasons, why M3UA SG-SG (which behaves as a 
> peer-to-peer
> protocol) makes sense to me. I would model the configuration 
> you mentioned
> as two SGs(one of them having the same PC with the AS), and 
> if I need to
> split the user parts on different ASPs, then I would do it 
> with ASP/SGP
> model, without crossing PC boundaries. This would also get rid of the
> strange case, where SG acting as STP should generate RCT for 
> PC of AS, in
> case of ANSI networks.
>  
> With the current model, one can also have a strange case as below:
> 
>                     AS1: PC=1-1-1 SI=3
>  +------+         +------+
>  |SG1   +---------+      |
>  |      |  +------+ ASP1 |
>  +------+--+--+   +------+
>            |  |
>            |  |
>            |  |
>            |  |
>            |  |     AS2: PC=1-1-1 SI =5
>  +------+  |  |   +------+
>  | SG2  +--+  +---+      |
>  |      +---------+ASP2  |
>  +------+         +------+
> 
> Now when association between SG1 and ASP1 is broken, SG1 will 
> reply with UP
> to incoming MTP3 traffic destined to PC=1-1-1/SI=3, but SG2 
> will route it.
> So, one also should be carefull when using multiple SGs, or 
> IMO better one
> shouldn't cross PC boundary between SG and ASP.
>  
> But even with the current model, if you think that carefull 
> configuration
> will solve the problem for SEP case, the same care will allow the same
> result, where SG acts as STP and has the combined SPMC view.
> > 
> > How about IPSP? There are no MTP3's? My assumption is
> > all IPSP's should be allowed to send DUPU in case they loose
> > user part. In this case DUPU is not m3ua codec but real UPU itself.
> [TOLGA] IPSP has some of the SG logic inside, at least SPMC 
> management I
> would say. There DUPU is not necessary. 
> > 
> > Hope that calrifies some of the DUPU issues.
> > 
> > Regards,
> > Nitin
> > 
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of
> > Tolga Asveren