Re: Upper boundary of Adaptation Layers

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 <[email protected]> wrote:
> Hello Stanislav,
>
> On 1/9/06, Stanislav Ivanovich <[email protected]> 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 <[email protected]> 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
> > [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
>


--
Ilie