Re: [Sigtran] Upper boundary of Adaptation Layers

Ilie,

  Please read Brian's statement that I 100% agree with:

  ------------------------------------------------------------------------
[Brian F. G. Bidulock]
Actually, the upper boundary at the ASP is a local matter. There are no
requirements placed on the boundary. It certainly does not have to
specified to the bit.
  ------------------------------------------------------------------------

  What Brian claims here is what I believe is the very essential (!) truth for all xxUA specifications. It is very important here to note that this is not so because of some agreement with the SIGTRAN community but rather a consequence of the very fundamental SIGTRAN concepts -> ASP/IPSP is an application resource not transmission one.

  For example no one would ever accept that M3UA specifies internal (!) boundaries of MTP3-user applications which use M3UA protocol. The same is the case for any other xxUA.

  The point is -> IPSP/ASP'es are application processes whose internal structure is irrelevant for xxUA specifications. What these specifications mandate is only external protocol i.e. behavior of the application processes on the external interface. Internal structure of application processes i.e. should there be any particular layer/box is irrelevant for the xxUA specifications.

  Therefore it is not true that xxUA specifications do mandate any particular layer/box which must have defined upper boundary. It is not true that xxUA specifications say "there MUST be a layer within an application process". However xxUA specifications do not forbid layered approach -> you can implement since it is not visible externally -> externally is only important that ASP/IPSP (application clones) behave according to xxUA protocols.

  Nevertheless applications are APS/IPSP'es which control their own resources -> activation/deactivation... therfore applications (!) control behavior on the external xxUA protocol rather then some magic xxUA box/layer -> there is no such box in xxUA specifications but you can implement them as implementation choice! Specifications only specify external protocols not internal ones!

  / stanislav

Ilie Glib <ilie.glib@googlemail.com> wrote:
  Stanislav

I should correct myself. I mean that there are no doubts that there
are xxUA Layers, and applications residing on top of them depend on
them as SCCP-Users, depend on SCCP services.

Regards

Ilie

On 1/9/06, Ilie Glib 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
> > Sigtran@ietf.org
> > 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
> > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
>
>
> --
> Ilie
>

--
Ilie

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