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

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

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: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 14:11:24 -0400

Gary

> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> Rajeev: There is standard IP router discovery that enables any node to
> > 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).
> >
> 
> > that defining an "event" for reactive mode in the requirements draft
> > is key
> > knows by now, I do not believe it is required by for the requirement
> > document,
> > will take a long time to work out. However, if the wg believes it is
> > needed,
> > > > has no idea whether a reactive or proactive CT is to be invoked.
> > > >

---

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

> pictures we all have, this is perhaps the best we have as a reference

If you are talking about router discovery, then I will have to respectfully
disagree. This is far from what I call "fast". In fact, there are many
optimizations that can be done at the link layer that eliminate the need
for over the air messages that would otherwise occur prior to a CT.

PatC

---

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

> for over the air messages that would otherwise occur prior to a CT.

Pat, the point is _when_ the MN determines that it has changed its default
router. A standard mechanism exists to determine this. If you wish to rely on
your own, it is up to you. In any case, the marker is when the MN determines
that it has changed its default router. Any CT that happens subsequent to that
event is post-something CT. Granted that this is not fast compared to the
"other" CT. However, this is a taxonomy issue, not a performance aspect.
[note: why is this post-X CT useful ? Well, in some scenarios, it is the only
way the MN determines that it has changed its AR. Present day MIP,
inter-technology handovers come to mind]

Regards,

-Rajeev