Re: [Sigtran] Upper boundary of Adaptation Layers

[Stanislav Ivanovich <[e-mail]>]

Hello Ilie,
   
  Please first let us hear Tolga and Brian on my last mail about this issue.
   
  If you now claim that you didn't question that user function should own control for activation/deactivation of AS please tell us what was your point in this question that you sent me on my private mail and which I simply copy/pasted and forwarded:
   
    -------------------------------------------------------------------------------------------------------------------
  [Ilie Glib] After all what is the point for ASP Activation commands in xxUA layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management)
  M-ASP_ACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Active message to its peer.
  M-ASP_INACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Inactive message to its
  peer.
  Is this an RFC fault?
  -------------------------------------------------------------------------------------------------------------------

   
   
  /stanislav
   
  

Ilie Glib <[e-mail]> wrote:
  Hello Stanislav,

On 1/9/06, Stanislav Ivanovich wrote:
> Hello,
>
> Since I find Ilie's questions ambiguous I will extend his questions by
> asking:
>
> 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP
> process states) indepdnednetly on MTP-user or SCCP-user applications by
> making these applications idendepndtz on the ASP/IPSP state?
>

[Ilie] I have not questioned that, in my view this is a fact written
in stone (RFCs).
check e.g. the SIGTRAN applicability draft:
http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt

> 2) If such layer exisits and if M3UA and SUA are not just and only protocls
> but also boxes/layers which have a place in the signalling system which is
> to isolate user functions on ASP/IPSP state shold such layer own the control
> on ASP/IPSP states?
>
> For example SCCP subsystem does not want to handle traffic. In legacy
> systems SCCP-user applications own the control on the SCCP-subsystem state
> change thus they control appaearance on N-STATE_request primitive on SCCP
> API.
> However if one thinks that xxUA is not just a set of protocls (ASP-SGP and
> IPSP-IPSP) but also a box which contains a functionality which is to isolate
> user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such
> box should own commands for AS state change, i.e. it is SUA box but not SCCP
> user function which owns control on AS state change, see section 1.6.3. in
> xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
>
> M-ASP_ACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP to send an ASP Active message to its peer.
> M-ASP_INACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP to send an ASP Inactive message to its
> peer.
>
> Is this an RFC fault?
>
>
> regards/ stanislav
>
>
> Ilie Glib wrote:
> Hello Folks,
>
> In my current understanding of the SIGTRAN:
>
> - SUA and M3UA RFCs define the primitives of the adaptation layers
> towards their users in Section "1.6.1. Definition of the upper
> boundary".
> SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
> complete definition of the primitives towards the users, therefore
> SIGTRAN supports existing
> SCCP/MTP users without them being aware of the fact that SIGTRAN is
> used for the transport of messages.
> SIGTRAN concepts and the corresponding entities/objects like AS, RK,
> RC, IPSP, ASP, and SGP are not part of the currently standardized
> upper boundary of M3UA (SUA).
> Thus today's SIGTRAN users do not know anything about those concepts.
>
> Can you please confirm this view or tell me if I'm mislead by my
> interpretation ?
>
> Is their any attempt in SIGTRAN WG to define! an extended upper
> boundary for xxUA that gives the option of managing entities like AS,
> RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
> services expected from adaptation layers ?
>
> Thank you in advance
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>


--
Ilie
  


		
---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

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