Re: ASP active procedure

Hello Chris, deepak, arif,

here's the summary what i understood -

1. receive ASP Up Ack.
2. check if the ASP is part of n+k model, and already n ASP's are active for
a particular RK. if so dont send the ASP Active.
3. check if the ASP is following a particular traffic mode.
Then take a decision to send ASP Active.
 I am just curious, all the examples in this RFC include NOTIFY message.
will NOTIFY message do not play any role in this decision making?

PS: i have cut short the mail due to message size restriction.

On 5 January 2011 12:23, Anand N Ilkal <[email protected]> wrote:

> chris , deepak,
>
> please find my comments inline -
>
> will the following statement fairly sums up the behaviour?
> 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.
>
> On 5 January 2011 11:21, Chris Benson <[email protected]> wrote:
>
>> Anand,
>>
>> My comments to your questions are inline.
>> With thanks, from, Chris Benson.
>>
>> On Wed, 5 Jan 2011, Anand N Ilkal wrote:
>>
>> >>  Date: Wed, 5 Jan 2011 10:49:49 +0530
>> >>  From: Anand N Ilkal <[email protected]>
>> >>  To: Chris Benson <[email protected]>
>> >>  Cc: arif khan <[email protected]>, "[email protected]" <
>> [email protected]>
>> >>  Subject: Re: [Sigtran] 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?
>>
>> Yes it is safe and usually (but not always) desirable.
>>
> Yes. This is not the sole reason on which i can decide to send ASP Active.
>
>
>>
>> >>  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)
>>
>> 1.  Yes the n+1th ASP to receive ASP Up Ack is allowed to issue
>> an ASP Active message.  It is not always desirable though, for
>> example as you suggest, it may not have resources to do that
>> yet.  There may be a locally-decided strategy to support at
>> most n ASPs in the active state.  If n = 1 and k > 0, it is
>> not usually a good idea to issue ASP Active from the 2nd ASP
>> if in Override Traffic Mode for example.  This decision is
>> left to a "Layer Manager" and the best M3UA implementation
>> would defer to a modifyable LM strategy.
>>
> How about using NOTIFY procedure to come to this conclusion?
>
>>
>> 2.  I am not sure what exactly you meant by another AS.
>> An ASP Up message is about the ASP and every AS in which
>> it resides.  An ASP Active message is only about one or
>> more AS contexts as specified in the message, and an ASP
>> can specify different traffic modes for receipt of traffic
>> within each AS (using different ASP Active messages from
>> the same ASP).  This complexity is governed by the local
>> prefernces and LM implementation and not by RFC 4666.
>> The LM implementor can offer a simple automatic LM or a
>> more complex set of tools to use at run-time (traffic
>> time).  The implementations of the LM and of its strategies
>> are not part of the M3UA internal implementation.
>>
>> I consider M3UA as an automated implementation of RFC 4666,
>> and the two separate entities of LM and M3UA user interface
>> as a library of tools that make the concepts of RFC 4666
>> Section 1.6.3 available as needed.
>>
>> >>
>> >>  >
>> >>  > 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?
>> >>  > >>  > >
>>
>

-- 
with regards,
Anand kumar Ilkal

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