Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

From: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 14:54:53 -0400

Rajeev:

See my previous posting. I agree that you and I have very different
pictures. For me, providing seamless handovers means eliminating as much
signalling overhead as possible, particularly over the air, and doing as 
much as possible as early as possible. The latter includes reacting as soon
as possible to an on-going handover as much as it means being proactive
about
possible handovers.

MN triggers, router discovery, etc. don't fit my goal of providing no
degradation to the user service. 

This difference of viewpoints is all ok, for we all love diversity in the
Internet. But this also means that the definition of CT should not be
limited, at very least, not limited so early in the design process, to
exclusive trigger events when the potential of alternative approaches has
not been explored.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 2:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > And that "standard router discovery" works for mobile access?
> 
> I don't know what you mean, but, if it is in a standards track RFC, I
> "guess" it (router discovery) should work for whatever access. We know
> it does and provides a standard reference for us. Given the different
> pictures we all have, this is perhaps the best we have as a reference
> point.
> 
> -Rajeev
> 
> 
> >
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:[email-masked]]
> > > Sent: Thursday, June 28, 2001 2:01 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> > 'Charles
> > > E. Perkins'; [email-masked]'
> > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > proactive
> > > and re active CT definitions
> > >
> > >
> > >
> > > Hello Gary,
> > >
> > > Gary Kenward wrote:
> > >
> > > >
> > > >
> > > > To expand a bit on my previous question: what defines a "default
> > > > router"
> > > > in a mobile wireless access network? This is a similar issue to
> > > > defining
> > > > "what is a handoff or handover".
> > > >
> > > >
> > >
> > > Rajeev: There is standard IP router discovery that 
> enables any node
> > to
> > > determine its default router. See RFC 2461.
> > >
> > >
> > > > Before everyone starts talking MIP, be reminded that the
> > > charter (and
> > > > the
> > > > problem statement, and the requirements) state that ct 
> should work
> >
> > > > with
> > > > with different wireless networks and different mobility
> > > solutions and
> > > > not
> > > > just with MIP (if ct is to be an augmentation of MIP, fine, let
> > Pat
> > > > rewrite
> > > > the charter and those of use who need to work on non-MIP ct can
> > move
> > > > on).
> > > >
> > >
> > > Rajeev: router discovery is independent of MIP.
> > >
> > > >
> > > > Clearly, from the discussion that has transpired, if we 
> all really
> >
> > > > believe
> > > > that defining an "event" for reactive mode in the requirements
> > draft
> > > > is key
> > > > to making ct work, then we should define what a handover is. As
> > > > everyone
> > > > knows by now, I do not believe it is required by for the
> > requirement
> > > > document,
> > > > and even more important, I suspect that a general definition of
> > > > handover
> > > > will take a long time to work out. However, if the wg 
> believes it
> > is
> > > > needed,
> > > > then let's make the valiant attempt.
> > > >
> > >
> > > Rajeev: using "default AR" as the basis would not need such a
> > > defintion.
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > Regards,
> > > > Gary
> > > >
> > > > > -----Original Message-----
> > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 27, 2001 8:28 PM
> > > > > To: Pat Calhoun
> > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E.
> > > > Perkins';
> > > > > [email-masked]'
> > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > > > proactive
> > > > > and re active CT definitions
> > > > >
> > > > >
> > > > > Pat Calhoun wrote:
> > > > >
> > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev 
> Koodli wrote:
> >
> > > > > > > > >
> > > > > > > > > Rajeev: I guess the point is that you would 
> do CT either
> >
> > > > > > > > >
> > > > > > > > > 1. before the new AR becomes the MN's default 
> router, or
> >
> > > > > > > > > 2. after the new AR becomes the MN's default router
> > > > > > > > >
> > > > > > > > > Both 1) and 2) are related to handover.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > The point of above text was to indicate that defining
> > > > > context transfer to be
> > > > > > > independent of handover is perhaps not sensible. Getting
> > > > > it to work with
> > > > > > > handovers is the challenge we are peddling.
> > > > > > > If we all agree on this, may be we should try to
> > > close the issue
> > > > ?
> > > > > >
> > > > > > The issue I have is that the current definitions use some
> > > > > random packet destined
> > > > > > for the mobile as the timing "event". This, im my mind,
> > > > > makes no sense whatsoever,
> > > > > > because one side (oAR) may not know when the packet shows
> > > > > up, and therefore it
> > > > > > has no idea whether a reactive or proactive CT is to be
> > invoked.
> > > > > >
> > > > > > FWIW, some CTs will transfer L2 session keys used for
> > > > > authentication and
> > > > > > encryption, so this is where the first packet doesn't
> > > make sense.
> > > > > >
> > > > > >
> > > > >
> > > > > Rajeev: But the above text (and the text Kulwinder sent
> > > > > today) does not say anything
> > > > > about the "first" packet. It is based on whether CT is
> > > > > initiated when the new AR is
> > > > > (not) the default router.
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > > PatC
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > -Rajeev
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> 
>

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 28 Jun 2001 15:30:16 -0700

Gary,

Gary Kenward wrote:

> pictures. For me, providing seamless handovers means eliminating as
> much signalling overhead as possible, particularly over the air, and
> doing as
>

I replied to that e-mail. Actually, I am glad that you share these views
regarding air-interface friendly.

> as possible to an on-going handover as much as it means being
> proactive about
> possible handovers.
>

Yet, I don't think you understand what constitutes router discovery.
This is not something I am proposing new. I guess your definition of
seamlessness includes not doing router discovery, which is quite
puzzling.. How does a MN identify its default router and that it is on
its default router then ? There is an IETF RFC which is implemented in
numerous nodes. I would have to guess that you would not comply with it.

In any case, the summary is that

- I am not proposing new messages over the air interface. I would
appreciate it if you could understand that and stop saying it.

- router discovery provides a good reference point for us for the
purpose of this discussion. I hope you could focus on that.

>
> This difference of viewpoints is all ok, for we all love diversity in
> the Internet. But this also means that the definition of CT should not
> be limited, at very least, not limited so early in the design process,
> to exclusive trigger events when the potential of alternative
> approaches has not been explored.
>

Well, my argument is that the current defintion is ambiguous and
insufficient.

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 29 Jun 2001 11:09:09 -0700

> numerous nodes. I would have to guess that you would not comply with it.

I honestly do not see why a mobile needs to do neighbor discovery in order
for two ARs to initiate a CT. If CT is mobile initiated, then I would agree,
but this is just one method of trigerring CT, not the general rule.

> appreciate it if you could understand that and stop saying it.

Gary isn't. He is just stating that there are altenative methods of
triggering CT. router discovery is one, and using L2 signalling is another.

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 29 Jun 2001 18:15:39 -0700

> but this is just one method of trigerring CT, not the general rule.

CT is done when a MN changes its ARs right ? We all agree that we can figure
out who the target AR is for a lot of cases. When it is not possible to figure
out the target AR before the MN goes there, what do you rely on ? One argument
is that establishing a new L2 is sufficient to start CT. However, my question
is how do you, for sure, determine that you have changed the AR when a new L2
is established ? One definitive marker is when the MN determines that it has
changed its default AR. This marker can be spotted using standard router
discovery. If you have other means, you could try (and err).

The general value of the above proposal is that all that "good" CT can be put
under the case when the MN has not changed its default AR. The remaining cases
are under the "Post"-something case.

> triggering CT. router discovery is one, and using L2 signalling is another.

Well, I am saying that we use router discovery as the marker to classify CT.
Could you explain how changing into a new link(and hence a L2 trigger)
necesssarily guarantees that the MN has changed its default router (which is
when CT is done) ?

-Rajeev