Re: Transfer of N-STATE_request in SUA

Ilie, Tolga,
   
  I would be very happy to hear what Tolga and other will say about SUA relay in ASP (or IPSP)... but nevertheless good point...
   
  However it is irrelevant if SSP is relayed or not (actually in SCCP it is broadcasted upon reception of SSP from the originating SCCP where the subsystem is located).
   
  What is relevant is that:
   
  1) SCCP-user can request N-STATE-Request, therefore ASP should be able to do it by means of DUNA.
   
  2) If we do it through ASP TM then it implies either necessity for support of DE at remote side or support for multiple AS'es at remote side in SE. In my view this is unacceptable!
   
  I vote for removal of administrative and certainly not conceptual restriction in SUA to send DUNA with N-STATE_request primitive from ASP to SGP since current pointless restrictions puts extra requirements on remote processes. If one does not want it he/she does not need to use it... but allowing it cannot harm, can it?
   
  Any opinions from other people?
   
  /stanislav
   
  

Ilie Glib <[email protected]> wrote:
  Hello Folks,

you can look at the problem from another perspective.

Section 3.4.1. Destination Unavailable (DUNA)
says: The DUNA message is sent from the SG or relay node...

According to SUA RFC an ASP can be equiped with relay function, that
is it can be a relay node. So in principle DUNA message as such can be
sent from an ASP. Unfortunately, as far as I can remember, SSP
messagees cannot be relayed in SCCP. Thus DUNA message sent from a
relay node cannot represent N-STATE_request primitive, though it can
carry an N-PCSTATE primitive.

Regards

Ilie


On 1/5/06, Stanislav Ivanovich wrote:
> Tolga,
>
> I disagree that not having possibility of managing separate SCCP subsystems
> is a consequence of the AS concept. In other words I do not see any
> conceptual problems with this -> I have one AS which is a set of several
> independent SCCP subsystems. I want to have possibility to operate the AS as
> a whole but I do not want to loos control over SCCP subsystems within the AS
> separately.
>
> Another problem is that this leads to necessity of having multiple AS'es on
> the other side in SE model which is mandatory and even more affecting
> traffic sate of remote applications!
>
> What if I have a remote process which does not support optional DE neither
> it supports multiple AS'es. However locally I have an AS with several SCCP
> subsystems within it. If I want to manage them separately I need support for
> either optional DE at remote side or support for multiple AS'es per remote!
> process in SE (since ASP TM messages in SE affect two AS'es on each side).
>
> I think we should update SUA and allow DUNA for N-STATE_request to be sent
> from ASP to SGP. This does not require any conceptual change but removal of
> this "administrative" (i.e. not conceptual) restriction.
>
> Are you saying that there are conceptual problems for this?
>
> thanks/ stanislav
>
>
>
> Tolga Asveren wrote:
>
> Stanislav,
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 12:14 PM
> To: SIGTRAN
> Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA
>
>
> Tolga, Brian,
>
> Brian I read all the sections in the SUA and the reason why I am asking this
> question is that Tolga's answer below is the only way how a user is supposed
> to generate N-STATE_request for a particular SCCP subsystem.
>
> However I consider this fault in SUA specification for the following
> reasons:
>
> 1) there are no conceptual problems of having DUNA message containing
> N_STATE-request sent from ASP to SGP within a particular AS for the same
> reason why it is not problem of having N-STATE_request sent from SCCP-user
> to SCCP.
>
> 2) Using ASP TM messages for this management is very problematic since it
> actually says that it is not possible to independently manage several SCCP
> subsystems that are part of the same AS. It forces implementors to support
> multiple AS'es per signaling process just to have separate SCCP subsystems
> separately manageable!!
> [TOLGA]OTOH, one could argue that AS is an entity which becomes
> available/unavailable as a whole, i.e. if it ! has multiple subsystems, they
> should be in-service/out-of-service simultaneously. So, what you consider as
> problematic is IMO a direct consequence of the AS concept.
>
> If you think otherwise why do you forbid sending DUNA from ASP to SGP which
> is to carry N-STATE_request fro independent SCCP subsystems that are part of
> the same AS? What is the problem of having this?
>
> regards/ Stanislav Ivanovich
>
>
>
> Tolga Asveren wrote:
> Stanislav,
>
> The answer to your question is "No". The behavior you are mentioning is
> controlled with ASPAC/ASPIA, i.e. with AS state.
>
> Thanks,
> Tolga
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 11:46 AM
> To: SIGTRAN
> Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA
>
>
> Brian,
>
> You didn't understand my question.! You refer to section! 4.5.1. which is
> related to handling of SSNM messages at SGP. I asked about N_STATE_request
> (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP
> to SCCP at SGP.
>
> I would appreciate answer to my questions with YES or NO.
>
> regards/ Stanislav Ivanovich
>
>
> "Brian F. G. Bidulock" wrote:
> Stanislav,
>
> Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.
>
> --brian
>
> Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
> >
> > Hello SIGTRAN community,
> >
> >
> >
> > In standard SCCP there is a primitive called N-STATE_request which
> > transfers management information (in-service/out-of-service) from
> > SCCP-user to SCCP.
> >
> >
> >
> > How is this information conveyed between SGP and ASP?
> >
> > Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> > having DUNA corresponding to N-STA! TE primitive)?
> >
> >
> >
> &g! t; regards/ Stanislav Ivanovich
> >
> _________________________________________________________________
> >
> > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
> >
> > References
> >
> > 1.
> http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co
> m/broadband/
>
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
>
>
>
>
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add photos, events, holidays,
> whatever.
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
>
> Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> ________________________________
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add photos, events, holidays,
> whatever.
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>


--
Ilie
  


		
---------------------------------
 Yahoo! DSL Something to write home about. Just $16.99/mo. or less

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