Re: ASP active procedure

Anand N Ilkal <[email protected]> Tue, 4 Jan 2011 21:31:51 +0530
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Hello Deepak, arif,

Please find my comments below -

According to RFC 4666, section -
4.3.4.3.  ASP Active Procedures

   Anytime after the ASP has received an ASP Up Ack message from the SGP
   or IPSP, the ASP MAY send an ASP Active message to the SGP,
   indicating that the ASP is ready to start processing traffic....

what if i decide not to send ASP Active after receiving ASP Up Ack , when
can i decide again to send ASP Active?

On 4 January 2011 16:31, Deepak Gunjal <[email protected]> wrote:

>  Hi Anand,
>
>
>
> Generally the application logic is treated separately from the transport
> layer which is here M3UA layer. So it is not necessary that if the transport
> layer is ready at a node then its application layer will also be in a ready
> state.
>
Agreed : in the entirety of the M3UA layer, it should never depend on the
status of the upper layer. always upper layers use the services of the lower
layers. otherway is seldom used.

>
>
> The M3UA ASP UP message signifies the availability of transport function at
> ASP but not about the application layer processing function on the same ASP.
> Also in similar fashion SGP sends ASP UP Ack to indicate its availability to
> accept the protocol messages only.
>
Consider the hypothetical stack configuration, where only till M3UA layer is
configured, does it mean, it can not send ASP Active Message? I do not think
so.

>
>
> By sending ASP ACTIVE an ASP indicates that now it can generate and process
> the user layer traffic and by sending ASP ACTIVE Ack SGP also indicates the
> same.
>
if application layer is not available local M3UA layer simply drops
message.

>
>
> So there is a distinction as I interpret the RFC for having TWO different
> messages viz. ASP UP and ASP ACTIVE which I think have been designed for
> such aspects. Also note that the application subsequently can initiate ASP
> ACTIVE from another ASP. The interpretation is now in the context of the
> traffic mode. So in Override mode the ASP which has generated the ASP AC
> will take on the active role, in case of loadshare it will be kind of
> parallel processing and in broadcast all the ASPs will process the same
> traffic simultaneously.
>
>
>
> That means there is some control function which will decide when the
> application is ready and traffic can be started. Now I may design my system
> which will first complete all the application level readiness functions and
> then will start with ASP UP. In that case it is possible that as soon as I
> receive and ASP UP ack I will send ASP ACT immediately.
>
that will be a good design. But i am not convinced that the readiness of the
application layer is the reason why sending of ASP Active is marked as MAY
in RFC4666. what if LM is the one who is triggering ASPSM and ASPTM
messages. in that case your design requires LM to communicate to both M3UA
layer and upper layer. there are only following boundaries defined between
M3UA and MTP3 User layers -

      MTP-TRANSFER request
      MTP-TRANSFER indication
      MTP-PAUSE indication
      MTP-RESUME indication
      MTP-STATUS indication


>
> To answer your question if ASP AC can be triggered from a particular ASP I
> would say yes when ASPs are running in high availability framework it is the
> framework which directs a particular ASP to assume ACTIVE role and then only
> that specific ASP will initiate the ASP ACK message to SGP. The framework
> may determine the active ASP based on multiple factors like nodes priority
> in that framework, its previous restart history, the state of application
> functions etc.
>
>
>
> Regards
>
> Deepak
>  ------------------------------
>
> *From:* Anand N Ilkal [mailto:[email protected]]
> *Sent:* Tuesday, January 04, 2011 3:49 PM
> *To:* arif khan; Deepak Gunjal
> *Cc:* [email protected]
> *Subject:* Re: [Sigtran] ASP active procedure
>
>
>
> Hello Deepak,
>
>
>
> I understand that there needs to be local check whether stack is ready to
> receive traffic for that routing key.
>
>
>
> lets assume all those scenarios are satisfied. and i am pretty sure that
> when RFC says MAY, it has taken all these cases into account (for example
> you can read from NOTIFY procedures - for NOTIFY to be sent, lot of
> conditions needs to be satisfied - like n number of ASP's being active. Yet
> RFC uses the words like MUST or SHOULD) .
>
>
>
> If traffic modes are to be taken into account, what should act as trigger
> for sending ASP Active message from a perticular ASP?
>
>
>
> Hence my opinion is ASP Up Ack is only a sufficient condition, where-as
> NOTIFY from peer acts as necessary condition.
>
> can any comment on that?
>
>
>
> On 4 January 2011 14:01, arif khan <[email protected]> wrote:
>
> Implementation logic is ok in their own context ...........
> But ASP can process the TRAFFIC message only after the ASP ACT ACK
> received from the NW and local side ASP with the remote ASP change
> their state and becomes ready to process the TRAFFIC.
>
>
>
>
>
>
>
>
>
>
> On 1/4/11, Deepak Gunjal <[email protected]> wrote:
> > As per my opinion the ASP ACTIVE is triggered after the reception of ASP
> UP
> > ACK only but the trigger point may not be immediate. The trigger point
> can
> > be an indication from high availability framework; it could be some
> > application logic which once determines via local procedures that it is
> > ready to process the application traffic from network can initiate ASP
> > ACTIVE to SGP.
> >
> > Regards
> > Deepak
> >
> > ________________________________
> > From: [email protected] [mailto:[email protected]] On
> Behalf
> > Of Anand N Ilkal
> > Sent: Tuesday, January 04, 2011 1:22 PM
> > To: [email protected]
> > Subject: [Sigtran] ASP active procedure
> >
> > Hello,
> >
> > i have doubt regarding the following section is RFC 4666  -
> > 4.3.4.3.  ASP Active Procedures
> >
> >    Anytime after the ASP has received an ASP Up Ack message from the SGP
> >    or IPSP, the ASP MAY send an ASP Active message to the SGP,
> >    indicating that the ASP is ready to start processing traffic....
> >
> > 1. why ASP MAY chose not to send ASP active on receipt of ASP Up Ack?
> > 2. is receipt of ASP Up Ack message is treated as sufficient condition,
> > whereas there is a necessary condition which should be satisfied so as
> ASP
> > active message is sent? if so, what is that condition?
> >
> > --
> > with regards,
> > Anand kumar Ilkal
> >
> > ________________________________
> > "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely
> > for the use of the individual to whom it is addressed. It may contain
> > privileged or confidential information and should not be circulated or
> used
> > for any purpose other than for what it is intended. If you have received
> > this message in error, please notify the originator immediately. If you
> are
> > not the intended recipient, you are notified that you are strictly
> > prohibited from using, copying, altering, or disclosing the contents of
> this
> > message. Aricent accepts no responsibility for loss or damage arising
> from
> > the use of the information transmitted by this email including damage
> from
> > virus."
> >
>
>
>
>
> --
> with regards,
> Anand kumar Ilkal
>
> ------------------------------
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including damage from
> virus."
>



-- 
with regards,
Anand kumar Ilkal

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran