Re: Transfer of N-STATE_request in SUA

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 <[email protected]> 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 <[email protected]> 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