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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 28 Oct 2002 16:35:13 +0100

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.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, October 28, 2002 4:09 PM
> To: [email-masked]'
> Subject: RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> 
> 
> 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
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, October 28, 2002 9:25 AM
> > To: Tolga Asveren
> > Cc: [email-masked]'
> > Subject: RE: [Sigtran] M3UA(rfc 3332) DUPU from ASP
> > 
> > 
> > 
> > 
> > 
> > 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,
> > 
> > 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/
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > 
> > 
> > 
> _______________________________________________
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Oct 2002 13:33:19 -0700

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.
>