Re: ASP active procedure

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.

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.

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.

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.

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]<mailto:[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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf
> Of Anand N Ilkal
> Sent: Tuesday, January 04, 2011 1:22 PM
> To: [email protected]<mailto:[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."

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