RE: Transfer of N-STATE_request in SUA

Stanislav,

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Stanislav Ivanovich
Sent: Thursday, January 05, 2006 1:32 PM
To: SIGTRAN
Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA


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.
[TOLGA]Although it has a wider meaning in the node, the concept of AS
corresponds to a traffic range from SUA stack point of view. It makes sense
to me that a traffic range is active/inactive, in-service/out-of-service as
a whole. Afterall, if one wants finer granularity control of that range, one
would define traffic ranges accordingly.

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).
[TOLGA]I personally do not see a problem with multiple SSNs in a SE-IPSP
scenario -or I misunderstood the scenario you had in mind-. What probably
needs to be done is to group corresponding SSNs in separate RKs.

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?
[TOLGA]What I am saying is that this sounds against the spirit of AS to me.
You define traffic ranges, i.e. an atomic entity from SUA control procedures
point of view, but want to have a finer granularity control on the same
entity.

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.