Re: [Sigtran] Upper boundary of Adaptation Layers

Ilie Glib <ilie.glib@googlemail.com> Mon, 09 January 2006 17:15 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0cJ-0004Y8-0y; Mon, 09 Jan 2006 12:15:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0cI-0004XW-5l for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:15:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04042 for <sigtran@ietf.org>; Mon, 9 Jan 2006 12:14:15 -0500 (EST)
Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0ip-0004cf-6T for sigtran@ietf.org; Mon, 09 Jan 2006 12:22:19 -0500
Received: by nproxy.gmail.com with SMTP id n28so140088nfc for <sigtran@ietf.org>; Mon, 09 Jan 2006 09:15:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HIWtk9GhFfbTe7WczM8l9X3ypYJ3nublq1xUN1Jf9+nLA5hBvyMnpldCt2cQ7YR73LTMOAksLTaodFiLdxMPkIPhHzPIP+mEaBXurbXrEUne9pff7nj/XlEyLa/5aj0YDxEt7bKNM6VK4F3Vyr3E8dA+Uot93gJRigTE1/Af0Cg=
Received: by 10.48.163.10 with SMTP id l10mr925233nfe; Mon, 09 Jan 2006 09:15:27 -0800 (PST)
Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 09:15:27 -0800 (PST)
Message-ID: <17b146d60601090915r5d9e3bceo2f299e4e8da02f9e@mail.gmail.com>
Date: Mon, 09 Jan 2006 18:15:27 +0100
From: Ilie Glib <ilie.glib@googlemail.com>
To: Stanislav Ivanovich <stanislav_ivanovich@yahoo.com>
Subject: Re: [Sigtran] Upper boundary of Adaptation Layers
In-Reply-To: <20060109165355.45861.qmail@web35401.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> <20060109165355.45861.qmail@web35401.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Content-Transfer-Encoding: quoted-printable
Cc: SIGTRAN <sigtran@ietf.org>
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
Sender: sigtran-bounces@ietf.org
Errors-To: sigtran-bounces@ietf.org

Stanislav,

I did not want to post this question on the SIGTRAN list. I do not
have any doubts that SUA, or M3UA layers can activate and deactivate
ASPs on request from SUA/M3UA Layer Management

On 1/9/06, Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
> 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 <ilie.glib@googlemail.com> 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 SIGT! RAN 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
>
>
>
> ________________________________
> 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

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran