Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...

From: "Hamid Syed" <[email-masked]>
Date: Thu, 21 Jun 2001 09:10:45 -0400

Rajeev,

By the time the context arrives at the new AR and processed (e.g. for
resource availability against the QoS context0, what is going to happen to
the traffic from the MN to the new AR (as you already said that the new AR
has layer 3 connectivity with MN). Sounds like latency issue here. The MN
sends the IP message to the new AR, the new AR goes back to the old AR, and
finally the context arrives at the new AR, it gets processed. Now the new Ar
is able to determine whether the support for the MN's microflows is
available or not. 

Does it help assuring a "seamlessness" to the MN?

-Hamid

> -----Original Message-----
> From:	Rajeev Koodli [SMTP:[email-masked]]
> Sent:	Wednesday, June 20, 2001 8:34 PM
> To:	Pat Calhoun
> Cc:	Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'
> Subject:	Re: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication &  Authorization ...
> 
> 
> Hi Pat,
> 
> consider that the MN just shows up at new AR. I mean it looses its current
> link,
> and gets a new one with new AR. After it establishes the link, the MN
> sends an
> IP message (just as it would send a Binding Update) to the new AR
> providing its
> previous IP address and previous AR address. The new AR contacts the old
> AR to
> fetch contexts.
> 
> How's that ?
> 
> -Rajeev
> 
> 
> Pat Calhoun wrote:
> 
> > Rajeev,
> >
> > I believe I've already asked for this, but let me try again.
> >
> > Could you please provide me with an example of when this would be
> > necessary? Some justification would be useful in my mind.
> >
> > PatC
> > On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote:
> > > Rajeev:
> > >
> > >   The current requirements in no way prohibit signalling from the MN.
> > > Myself and others have re-iterated this many times on the list.
> > >
> > >   o the trigger arrives at an AR at L3; the source is not specified,
> > >     and considered out of scope for CT.
> > >
> > >   o CT must provide the mechanisms to allow per microflow
> enable/disable;
> > >     the control protocols are not specified and considered out of
> scope for
> > > CT.
> > >
> > >   Nothing you have said contradicts the above requirements. The only
> issue
> > > seems to be that you and others want an explicit requirement so that
> the
> > > design
> > > task for these protocols are explicitly part of CT. This would mean
> not only
> > > that
> > > we will have to add MN signalling, but also signalling from other
> sources,
> > > including
> > > L2 (?). Sounds like a lot of effort to me, and the solutions could
> > > unnecessarily
> > > constrain CT.
> > >
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > Sent: Monday, June 18, 2001 2:32 PM
> > > > To: James Kempf
> > > > Cc: [email-masked]; [email-masked]; Kenward, Gary
> > > > [WDLN2:AN10:EXCH]; [email-masked]
> > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
> > > > Authentication & Authorization ...
> > > >
> > > >
> > > >
> > > > Hello James,
> > > >
> > > > James Kempf wrote:
> > > >
> > > > > Rajeev,
> > > > >
> > > > > I don't think we can require L3 triggering in all cases. We need
> > > > >
> > > >
> > > > Rajeev: Unfortunately, I think we cannot require that the MN
> > > > do L2 triggering
> > > > in all cases as well.
> > > >
> > > > > to make sure that an MN not need to do L3 triggering, otherwise,
> > > > > as Gary points out, performance will suffer.
> > > >
> > > > Rajeev: yes in some links, may be (or no impact) in others.
> > > >
> > > >
> > > > > If there's an L2 trigger,
> > > > > it should be used preferentially.
> > > >
> > > > Rajeev: certainly. It is one thing to say that if there is a
> > > > L2 trigger, it
> > > > should be used preferentially, but another thing to say that
> > > > we disallow using
> > > > L3 messages to trigger CT. We should have the possibility of
> > > > MN requesting CT.
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > >
> > > > >
> > > > >                 jak
> > > > >
> > > > > >Delivered-To: [email-masked]
> > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon
> > > > Valley Messaging
> > > > > Protection
> > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700
> > > > > >From: Rajeev Koodli <[email-masked]>
> > > > > >To: Singh Ajoy-ASINGH1 <[email-masked]>
> > > > > >CC: "'Kulwinder Atwal'" <[email-masked]>, Gary
> Kenward
> > > > > <[email-masked]>, "'seamoby'" <[email-masked]>
> > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
> > > > Authentication &
> > > > > Authorization ...
> > > > > >
> > > > > >
> > > > > >Hello Ajoy,
> > > > > >
> > > > > >whereas use of link-layer triggers is very useful, it is
> > > > not something we
> > > > > >can rely upon to be present everywhere (as you correctly
> > > > point out for
> > > > > >Inter-technology handovers). I don't think we ever said we
> > > > disallow link
> > > > > >layer triggers. We must not say that that's our solution.
> > > > At the IP layer,
> > > > > >we need to define IP messages. I think we pretty much agree.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >-Rajeev
> > > > > >
> > > > > >
> > > > > >Singh Ajoy-ASINGH1 wrote:
> > > > > >
> > > > > >> I think it is possible to receive link layer trigger at the new
> > > > > >> access router which can be used to initiate context transfer.
> > > > > >> This will be mostly useful in case of some intra-technology
> > > > > >> handovers. In case MN moves across different technologies, yes
> > > > > >> some sort of MN trigger is useful. Having said that is it a
> > > > > >> good idea to limit the scope of CT protocol? I think we
> > > > > >> should allow both the options.
> > > > > >> regards,
> > > > > >> ajoy
> > > > > >>
> > > >
> > > > [snip, snip]
> > > >
> > > >
>

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Jun 2001 12:31:32 -0700

Hello Hamid,

I guess the discussion along this thread has moved over to different
thread. In any case, see some comments below.

Regards,

-Rajeev

Hamid Syed wrote:

> resource availability against the QoS context0, what is going to
> happen to the traffic from the MN to the new AR (as you already said
> that the new AR has layer 3 connectivity with MN). Sounds like latency
> issue here. The MN sends the IP message to the new AR, the new AR goes
> back to the old AR, and finally the context arrives at the new AR, it
> gets processed. Now the new Ar is able to determine whether the
> support for the MN's microflows is available or not.
>

Rajeev: The point is that you may not have a choice in some situations.
Consider when predictive does not work, the new AR knows of the MN's
arrival only after the MN actually attaches to it. Sure there is
latency. But, you can still fetch the contexts. The alternative is to
re-establish them (over the air interface). And, importantly, you can
still build the contexts "soon enough".

> Does it help assuring a "seamlessness" to the MN?

Rajeev: I don't know how to assure something without implementation
experience. I do know however that it depends on the nature of the
application.

Regards,

-Rajeev