Subject: RE: [mobile-ip] Thoughts on using handover capability extension

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 8 Nov 2002 15:04:20 -0600

Hi Rajeev,

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]] 
Sent: Friday, November 08, 2002 12:34 PM
To: [email-masked]
Subject: [mobile-ip] Thoughts on using handover capability extension

Hello folks,

there has been some discussion on the timing of various messages. It
occurred to me that one _could_ make use the handover capability extension
to provide some of the information to the MN ahead of time. For instance, a
MN may request the map of neighboring APs and ARs via RS much ahead of the
actual handover, e.g., when it first attaches to its router. The AR can
provide this via handover capability extension in a RA.

With this, the functionality of PrRtSol/PrRtAdv is moved
to RS/RA, but also to an earlier time. The MN should be
able to send FBU prior to handover, which then triggers
HI/HAck sequence.

MK> I think it is good idea to include such extension to make the
neighboring ARs available when the MN asked for it. But, I think this
extension should be part of PrRtSol/PrRtAdv not RA.

Downside is increased message size (due to the whole
map being sent). Also, the MN may attach to an AP
not in the map, but I guess this can always happen and
we need tunnel establishment subsequent to handover.

Comments ?

-Rajeev

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 8 Nov 2002 15:35:45 -0600

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]] 
Sent: Friday, November 08, 2002 3:11 PM
To: Hesham Soliman (EAB)
Cc: [email-masked]
Subject: Re: [mobile-ip] Thoughts on using handover capability extension

> => Hmm, why does it have to move to a normal RS?
>

Right, there is a choice between having an option in RS
versus a separate message. One reason why RS
might be better is that the MN will likely do RS anyway
upon attaching to the link. If it receives an unsolicited
RA, the MN needs to do RS with a request for handover capability extension.

MK>> I think if you include this extension in RA, then you are asking all
the routers whether they support mobility or not to implement this
extension. I think it is very difficult to convince the ipng WG with this
point of view, but you are welcome to try. Since, PrRtSol/PrRtAdv are
messages  introduced to extend the router functionality to support mobility,
I think the proper location for this extension is in PrRtAdv.

---

From: [email-masked]
Date: Mon, 11 Nov 2002 19:17:51 -0600

> We seem to be interpreting Router Discovery slightly differently.
> IMO, FMIPv6 allows for "resolving an id to an AR". I can see you
> might call it AR Discovery, but that's not what I have been saying.
> Clearly, the information about the neighboring APs and ARs needs
> to be resident on the ARs. This information could be statically
> configured or through CARD. FMIPv6 only concerns with delivery
> of that information, and not how that information is computed.

Within the scope of the Mobile IP WG FMIPv6 deals only with the
handoff from oAR to nAR. How the oAR determines the nAR is not
dealt with by FMIPv6. It could be configured or there can be
some discovery mechanism. But discovery mechanisms are being
worked on in Seamoby. Now if CARD in seamoby wants to extend
FMIPv6 for CARD, they can do so. But is there such a requirement
at this time? And if such a requirement does exist, are the
FMIPv6 messages incapable of being extended? 

But one thing to say about this thread here is that lets not
get into CARD design using FMIPv6 here.

-Basavaraj

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 17 Nov 2002 20:08:55 +0000

Hi James:

I am not saying that this in complicated. It is simple, rather too 
simplistic to be accurate and efficient enough.

There is no evidence (that I am aware of, please let me know if you know any 
reference to such research) that we need pAR's support to turn on the card. 
It can wake up using physical layer techniques. On the other hand, if we do 
need pAR's support, we have to look for more accurate techniques, probably 
based on location-aware tecniques.

Hemant

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>,   
>      <[email-masked]>
>Date: Fri, 15 Nov 2002 15:25:09 -0800
>
>If the MN asks for a mapping of all APs to ARs for link technology X that 
>the
>current AR knows about, and the current AR sends some, then the MN turn on 
>its
>card and check when it hears an AP. If the current AR sends none, then the 
>MN
>keeps the card off.
>
>It does not need to be complicated.
>
>How the current AR gets this information is out of scope for the AR to MN
>protocol (though in scope potentially for a AR to AR protocol).
>
>             jak
>
>----- Original Message -----
>From: "Hemant Chaskar" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Friday, November 15, 2002 1:08 PM
>Subject: RE: [mobile-ip] Thoughts on using handover capability extension
>
>
> > Hi Raj:
> >
> > I agree. There are various (in)feasibility issues in asking link types 
>of
> > other ARs from pAR -
> >
> > 1. How does pAR know geographical adjacency of interfaces? So, if I am
> > connected to WAN pAR, and ask for availability of WLAN APs (or OWLAN APs 
>for
> > that matter) while moving around a busy area, WAN pAR will always say 
>that
> > there are many around. But if I never get indoor, I cannot use them, but 
>my
> > WLAN interface will be awake.
> >
> > 1a. Also, if I am going East and ask such question, I get availability 
>info
> > of OWLANs in all directions as WAN pAR may not know which direction I am
> > moving.
> >
> > In short, evidence of reachability is pre-requisite for handoff. And if 
>MN
> > can produce that evidence, it already knows link type.
> >
> > 2. Have we concluded that it is infeasible to do this wake-up business 
>using
> > physical layer techniques (a variation of how MNs wake up to check for 
>pages
> > in cellular case)? I think doing it at physical layer would be more 
>accurate
> > (IF wakes up when it detects signal/energy => evidence of reachability 
>is
> > automatic). So, only when I walk into the mall, WLAN IF wakes up, and 
>not
> > when I am walking in a garden near the mall. And if that is true, link 
>type
> > info may be superfluous.
> >
> > Hemant
> >
> >
> > >From: [email-masked]
> > >To: <[email-masked]>, <[email-masked]>,
> > ><[email-masked]>
> > >Subject: RE: [mobile-ip] Thoughts on using handover capability extensio
> > >Date: Thu, 14 Nov 2002 16:41:03 -0600
> > >
> > > > > - it seems to me that folks prefer moving the PrRtSol
> > > > >    and PrRtAdv messages to an earlier time. Perhaps
> > > > >    we should recommend that the MN should send
> > > > >    PrRtSol after router discovery (RS/RA) or during router
> > > > >    discovery (see the next issue) ? In this message,
> > > > >    the MN sends a wildcard for target APs.
> > > >
> > > > The MN should also send some indication of the link
> > > > technology, for intertech handover, in addition.
> > > >
> > >
> > >Why? I am not sure if link technology knowledge is
> > >required for network layer HOs. Is this required in
> > >the PrRtAdv to awaken some idle interface at the MN?
> > >This would imply that the pAR knows what types of link
> > >technologies the MN can move to. Not feasible.
> > >
> > >-Basavaraj
> >
> >
> > _________________________________________________________________
> > Add photos to your messages with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

---

From: [email-masked]
Date: Wed, 13 Nov 2002 16:08:37 -0500

Hi James:

Sleeping interfaces can also wake up by themselves after detecting energy at RF output. At least, I don't think anybody would have on their roadmap a device that uses CARD to activate sleeping interfaces.

On the other hand, there aren't ways around capability discoveries of the form QoS, security capabilities etc. That is where CARD would be indispensable.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 3:06 PM
To: Hemant Chaskar; [email-masked]
Cc: [email-masked]
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover
capability extension

In an intertechnology scenerio, the MN could get info on a nonactive interface
through an active one, thus saving power.

            jak

----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 13, 2002 7:11 AM
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
extension

> Hi James:
>
> Could you please provide a scenario where and how knowing wireless link type
> will enhance handover performance?
>
> The reverse address translation part is clear to me. But, I do not see why
> only this kind of capability is critical to convey, and others may not be
> important.
>
>
> Hemant
>
>
> >To: "Eunsoo Shim" <[email-masked]>, "Pete McCann" <[email-masked]>,
> >  "Rajeev Koodli" <[email-masked]>, <[email-masked]>
> >CC: <[email-masked]>
> >Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover
> >capability extension
> >Date: Tue, 12 Nov 2002 05:13:22 -0800
> >
> >I think that CARD should just focus on router address and wireless link
> >type for
> >now, and include a way, like an ICMP option, to extend for later when
> >people
> >actually intend to use other capabilities. Better to start simple with a
> >way to
> >expand than have something complex initially that people won't use nor
> >implement. Is anyone planning on implementing complex capability
> >determination
> >as products at this point? I think using CARD for anything more than
> >wireless
> >link type and router address information is a research topic.
> >
> >Therefore, it makes sense to leverage the FMIP signaling. Why have two
> >protocols
> >that are about 80% the same when you can have one that does the whole job?
> >
> >
> >             jak
> >
> >From: "Eunsoo Shim" <[email-masked]>
> >To: "James Kempf" <[email-masked]>; "Pete McCann"
> ><[email-masked]>;
> >"Rajeev Koodli" <[email-masked]>; <[email-masked]>
> >Cc: <[email-masked]>
> >Sent: Tuesday, November 12, 2002 12:50 AM
> >Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover
> >capability
> >extension
> >
> >
> > > CARD talks about capability which may include more than just IP address
> >(or
> > > subnet prefix) and MAC address.
> > > So distribution of information about ARs to MN may include more than AP
> >ID,
> > > AR MAC, AR IP(or prefix).
> > > I wonder whether people want to extent FMIPv6 protocol to cover such a
> > > general case.
> > > Also one of the requirements for CARD is that it should be independent
> >of
> > > any specific mobility management protocol.
> > > I'd like to suggest we develop CARD protocol further (it is in its very
> > > early stage in terms of protocol spec) and see what is the best way to
> > > resolve the partial overlapping between FMIPv6 and CARD.
> > > Regards,
> > >
> > > Eunsoo
> > >
> > > To: "Pete McCann" <[email-masked]>; "Rajeev Koodli"
> > > <[email-masked]>; <[email-masked]>
> > > Cc: <[email-masked]>; <[email-masked]>;
> > > Sent: Tuesday, November 12, 2002 3:13 AM
> > > Subject: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
> > > extension
> > >
> > >
> > > > I *really* dislike sending email to two lists, but people just don't
> >seem
> > > > willing to take this discussion to the Seamoby list, where it properly
> > > belongs.
> > > > Apologies.
> > > >
> > > > > I agree FMIPv6 does packet forwarding.  Are we sure we want it to do
> > > > > address configuration?  Also, you mentioned router capability
> > > > > discovery (which I agree is in scope of CARD) but not router
> >discovery
> > > > > itself (which I think is also in scope of CARD).
> > > > >
> > > >
> > > > Yes router discovery is in the scope of CARD.
> > > >
> > > > > If Seamoby can agree that PrRtAdv is the right container message,
> >then
> > > > > I am all for it.  Have those discussions converged yet?
> > > > >
> > > >
> > > > No, which is why I am urging people to take this discussion to the
> >Seamoby
> > > list
> > > > so that we can get it to converge.
> > > >
> > > > > Well, I would rather solve a problem once than twice.
> > > > >
> > > > > Sorry to continue discussing CARD here on mobileip, but can we agree
> > > > > that it consists of two things:
> > > > >
> > > > > 1) an inter-AR protocol for discovering info about neighboring
> >access
> > > > >    routers;
> > > > > 2) a MN-to-AR protocol for distributing that info to MNs.
> > > > >
> > > >
> > > > These don't have to be separate. You can use the same signaling for
> >both.
> > > The
> > > > security must be different on them, however.
> > > >
> > > > > To me it sounds like you think CARD is only (1).  I think it is both
> > > > > (1) and (2), and that we shouldn't define two different protocols
> >for
> > > (2).
> > > > >
> > > >
> > > > Yes, exactly.
> > > >
> > > >             jak
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > >
> > >
> > >
> >
> >_______________________________________________
> >Seamoby mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/seamoby
>
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Wed, 13 Nov 2002 17:11:19 -0500

Hi James:

(sorry Raj again):

You should also ask the question: "Is anybody planning to use CARD to wake up sleeping interfaces, or they are rather planning to use physical layer techniques (detecting energy at RF output) to do that?" Answer to this question is important to consider even link type as a capability.

Also, I am not pushing anything. I am raising valid technical issues. If it sounds like pushing to you, I apologize.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 4:36 PM
To: Trossen Dirk (NRC/Boston); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover
capability extension

> I strongly hope that any future discussion on IETF drafts will
> not require to reveal my company's product plans to the WG chair
> in order to approve discussion on the topic.
>
> Further, I strongly suggest that you return to a technical discussion rather
> than shutting people up with comments like you provided in your recent
> emails. Disqualifying technical contributions as "graduate student's
> dissertations" is inappropriate in tone and direction in a technical
> forum. If you have a problem with the approaches on the table, stick
> to technical comments.
>

Several IETFs ago, Phil Roberts asked the MIP group if anybody was going to do
FMIPv4 products. Not a single hand went up. Result: FMIPv4 went to experimental
RFC.

Now, I'm asking the same question about CARD. I singled out Nokia because you
and Hemant have been pushing on this, perhaps that was inappropriate. So let me
ask the same question to both working groups (sorry Raj):

    Is anybody planning on making CARD with many MN capabilities into a product?

If nobody is planning on using this, then we ought to take it to experimental or
move it to the IRTF, and let FMIP move ahead with simple link type and link
address capability discovery.

            jak