Re: ASP active procedure

Hello Chris,

That certainly help -
Please find my comments inline.

On 5 January 2011 08:37, Chris Benson <[email protected]> wrote:

> Anand,
>
> I believe that the aspect of RFC 4666 that provides the
> answer to your question is found in Section 1.6.3. ...
>
> M-ASP_ACTIVE request
> Direction:  LM -> M3UA
> Purpose: LM requests that ASP send an ASP Active message to its peer.
>
> An ASP Active message is sent both when the local M3UA is
> in the appropriate state *AND* when "Layer Management"
> makes this request.  Therefore, Section 4.3.4.3 only
> suggests that an ASP Active message MAY be sent.  There's
> no intention that this messgae always be sent immediately
> and automatically/unilaterally by M3UA itself.
>
Agreed, then is it safe for me to decide to send ASP Active if M3UA layer is
ready to receive traffic and  it has received ASP Up Ack?
then how about the scenario where n+k ASP's are configured in an AS, there
are already n ASP's active. n+1th ASP has received ASP Up Ack. Since M3UA
layer is ready to receive traffic, can this ASP also send ASP Active ?
(although it can send since there is no problem if there are n+1 ASP's
active in that perticular AS, just it could happen that n+1th ASP may be
part of other AS's too, hence i do not want to load it further unless it is
required)

>
> You could choose to implement a "Layer Management" entity
> that does automatically issue a M-ASP_ACTIVE request
> just as soon as it receives an M-ASP UP confirm from
> the local M3UA ASP, but the RFC does not require that,
> in part because this "Layer Management" is not part of
> M3UA itself.  The "Layer Management" entity could even
> be a bureaucrat or trained monkey.  An extreme analogy,
> but the point is that LM decides to move an ASP to
> Active state, although the M3UA's ASP state enforces
> required conditions as described in Section 4.3.1. etc.
>

Yes, RFC does not cover Layer Manager. But to cover n+k model, traffic mode
support, RFC recommends either internal logic in M3UA layer or use of NOTIFY
message to arrive at conclusive decision whether to send ASP Active or not.
Hence this internal logic or NOTIFY procedure are the necessary condition to
ultimately decide whether to send ASP Active from a particular ASP or not.

Although NOTIFY messages carry only advisory importance, but their
procedures are non-optional. it is at implementor discretion whether to make
use of those or not.

>
> This is the model of RFC 4666 rather than one in which
> states always progress automatically towards data transfer.
>
> I hope this helps, from Chris Benson.
>
>
> On Wed, 5 Jan 2011, Anand N Ilkal wrote:
>
> >>  Date: Wed, 5 Jan 2011 07:45:42 +0530
> >>  From: Anand N Ilkal <[email protected]>
> >>  To: arif khan <[email protected]>
> >>  Cc: "[email protected]" <[email protected]>
> >>  Subject: Re: [Sigtran] ASP active procedure
> >>
> >>  Hello Arif, Deepak,
> >>
> >>  This is not a special scenario, which would require special handling by
> >>  either M3UA layer or LM.
> >>  My argument is, this section could have very well been written as
> follows -
> >>
> >>  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 SHOULD(or MUST) send an ASP Active message to the
> SGP,
> >>     indicating that the ASP is ready to start processing traffic....
> >>
> >>  This would have covered all the scenarios related to readiness of the
> >>  traffic handling (and management blocking). *But text is not as shown
> here*,
> >>  hence receipt of ASP Up Ack is just a sufficient condition where-as
> NOTIFY
> >>  serves the necessary condition to send ASP Active message.
> >>
> >>  I would like you to comment on this sufficient and necessary
> conditions.
> >>
> >>  On 4 January 2011 23:07, arif khan <[email protected]> wrote:
> >>
> >>  > Yes this is the implementation need to handle this kind of situation.
> >>  > Suppose if Peer is already in ASP ACT state or any other
> >>  > state(excluding, waiting for the ASP UP ACK) and receives such
> >>  > messages then state machine of the ASP should perform the state
> change
> >>  > and should come to the original state.
> >>  >
> >>  > This could be done by the system management entity to handle this
> kind
> >>  > of situation.
> >>  >
> >>  >
> >>  >
> >>  >
> >>  > On 1/4/11, Anand N Ilkal <[email protected]> wrote:
> >>  > > 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
> >>  > >
> >>  >
> >>
> >>
> >>
> >>  --
> >>  with regards,
> >>  Anand kumar Ilkal
> >>
>



-- 
with regards,
Anand kumar Ilkal

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