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

From: "Gary Kenward" <[email-masked]>
Date: Mon, 18 Jun 2001 16:56:13 -0400

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: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 13:51:57 -0700

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 17:33:48 -0700

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 17:36:40 -0700

> L2 (?). Sounds like a lot of effort to me, and the solutions could

Rajeev: why would we have to add L2 signaling ? An IP message to initiate
CT would be needed for the MN and is perhaps useful for other entities. I think
it is doable.

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 06:32:17 -0700

> previous IP address and previous AR address. The new AR contacts the old AR to

then why wouldn't the authenticated binding update simply cause CT to occur?

Patc

---

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

> then why wouldn't the authenticated binding update simply cause CT to occur?

Rajeev: Sorry for the delayed response to a very good question: This *should* be
allowed, and can very well occur.

Regards,

-Rajeev