Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement)

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 18 May 2001 17:07:43 -0500

John, MM design team folks, 

I don't know what John means by "should we let it die"

Anyway, I read the draft long time ago, but I need to read it again,
so If I ask dumb or unfair questions, let me know. Either way,
I am planning to read it again!
just a few comments, for Friday afternoon (or Saturday morning
your time :) ), I hope this is not a repeat, or not fuel
for a lot of flames! and it is not meant to be criticism.

Regards,
Madjid

   "In this draft, the term 'local mobility' is used in place of
   micromobility."

Why? and why do we call the draft Micromobility then!
I guess later on, I have answered the first "why" but I am not sure.

"While studying solutions for seamless handovers, the SEAMOBY Working
   Group should include the following considerations:"

Is this still true, or might want take the SEAMOBY WG out of it?

"    *  Mobility maintaining the same routable IP address of a mobile
       node or mobile network."

OK, This one sounds like MM to me, but

"    *  Handover between heterogeneous networks.  For example, 802.11,
       Bluetooth and 3G cellular."

This one is a bit not clear. I want to read handover between L2s of
these networks (or APs as we defined them earlier). If it would be
ARs, then isn't handled by MIP then? in anycase it wouldn't be called
micromobility, would it, just wondering? (maybe local mobility is
the better term after all :) )
Generally one problem that I have with the draft is that whether it is
AP or AR, is not alway clear.

"    *  How to discover a new Access Link and the Access Router serving
       the new Access Link."

so you also mean discover a new AP?

"    *  How to discover the bandwidth, cost, error rate (and other
       properties) of candidate Access Links.
    *  Involving QoS characteristics as part of the handover process."

These two sound like the stuff in CNP, do we want to start from there?

"    *  Optimize the path for mobile-to-mobile communications.
    *  Enable plug and play capabilities for Mobile Devices, Access
       Routers/Access Links."

the text that is provided for this (in 4.3.3) talks about capability
discovery of neighboring APs. Is that the same as plug and play 
capability, you say?

    *  Support for mobility of mobile hosts and mobile networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:33 AM
To: Madjid.Nakhjiri; [email-masked]
Subject: RE: MM requirements (was: IRTF mm problem statement)

Hi Madjid,

> Well, what is the status?? until a few days ago, it was not
> clear whether is on the charter or not.

The current problem statement:

http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mm-problem-01.txt

Has recieved no comments on it since before the 50th IETF meeting.
Should we go to last call, or should we let it die?  I have 
asked this several times, and noone has given me an answer.

The proposed SeaMoby Charter has this item in it:

Jul 01  Submit Handoff Candidate Discovery Problem Statement

This topic is seperate from the above problem statement.

Now, does anyone have any preferences on how to procede?

John

---

From: [email-masked]
Date: Mon, 21 May 2001 10:05:17 +0300

Hi Madjid,

> I don't know what John means by "should we let it die"

The current problem statement is used in 2 Internet Drafts
as a refence.  When I asked "should we let it die" - I really
meant should we let the draft expire.

> I guess later on, I have answered the first "why" but I am not sure.

MM was used as it was called that in the charter.  However, after 
countless discussions, it was felt that MM had too much baggage,
and the DT thought Local Mobility was more fitting term.

> Is this still true, or might want take the SEAMOBY WG out of it?

Maybe Pat can comment on this.

> AP or AR, is not alway clear.

That I can try to clean up.
 
> "    *  How to discover a new Access Link and the Access 
> Router serving the new Access Link."
>

Yes.
 
> These two sound like the stuff in CNP, do we want to start from there?

I think CNP is an example of what we want to do, but let's
not take it as a given.

> discovery of neighboring APs. Is that the same as plug and play 

Yes.

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 23 May 2001 12:29:12 -0500

John,

My replies below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 21, 2001 2:05 AM
To: Madjid.Nakhjiri; [email-masked]
Subject: RE: MM requirements (was: IRTF mm problem statement)

MN>> So there would be no problem statement for MM, straight to
requirements?

MN>> I would make more sense to change the name to local mobility then,
if you are keeping the scope the same, doesn't it?

MN>> sure, it is not a given, but a good place to start the technical
discussion.

Yes.

MN>> I don't quite see plug and play capability to be the same as capability
discovery.
From the MN's point of view, plug and play would include, capability
discovery 
AND service/ policy negotiation, handover, maybe context transfer as well.
Don't you think?

Regards,
Madjid

---

From: [email-masked]
Date: Thu, 24 May 2001 10:12:48 +0300

Hi Madjid,

> MN>> So there would be no problem statement for MM, straight to

Nope, we will reuse some material from the existing draft and
write a new problem statement.  From the proposed charter:

This covers CNP; capability discovery and plug 'n play, in my mind.
I will try to get started on this next week.  I want to just work
with the existing material from the MM design team before getting
loads of comments.

> MN>> I don't quite see plug and play capability to be the 
> same as capability discovery. From the MN's point of view, 
> plug and play would include, capability discovery 
> AND service/ policy negotiation, handover, maybe context 
> transfer as well. Don't you think?

I think all will be involved, in some respects.  This is all
stuff we talked about in the MM design team, that is why
my intention is to pull something together & then let
people comment.

John