Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

From: gabriel montenegro <[email-masked]>
Date: Tue, 3 May 2005 02:15:53 -0700 (PDT)

[reappearing after a hiatus...]

Hi Rajeev, James,

I'm not so much thinking about the protocol messages to be sent.
Those are easy enough. What is not as obvious to me is that the
behavioral aspects of the protocol are sufficiently understood
for proposed standard in the predictive case. In other words, 
a complete solution that folks can implement to. It seems like
this is much clearer for the reactive case (as in "it would stand
up to the rigours of the PS publication process"). 

Would you agree that the latter is easier to specify fully?

On a side note, I see that the FMIP-over-CDMA or FMIP-over-WiMax
(some folks did mention this privately) are both a bit too early,
perhaps even for an informational draft. Instead, we could use those
cycles on FMIPv6 itself (thus my interest in finding the right scope).

Comments?

-gabriel

--- Rajeev Koodli <[email-masked]> wrote:

> 
> 
> gabriel montenegro wrote:
> 
> >> Bundling 2)
> >> and 3) makes more sense to me, because they both are on IP transport, 
> >> and
> >> the mobile node can use information on neighboring subnets in order to
> >> pre-configure for handover.
> >
> >
> > Yes, but you've argued quite convincingly that proactive handovers
> > may not be as generally applicable. Rajeev has argued equally 
> > convincingly
> > that the local routing done by FMIPv6 is quite useful even in the
> > absence of any neighborhood information (the reactive case, which 
> > benefits
> > from DNA). The reactive case seems like a well-understood alternative 
> > in its own right,
> > despite performance tradeoffs.
> >
> > This leads me to ask the following question: what are the pros and 
> > cons of
> > having two separate and simpler documents, one on
> > Fast Reactive Handover (FRH) and another one on Fast Proactive 
> > Handover (FPH)?
> >
> sneaking out of my vacation..
> 
> I see the difference between predictive and reactive is the Proxy messages.
> The rest of the machinery involves setting up routing between PCoA and 
> NCoA.
> So, it is far simpler to have a single document with two modes. Besides, 
> when
> the predictive mode fails at runtime, you need the reactive mode. In 
> other words,
> the two modes are not entirely independent.
> And, predictive mode is definitely feasible in WWANs.
> 
> I am inclined to have a single document for completeness.
> 
> -Rajeev
> 
> > -gabriel
> >
> >>
> >> The model for 1) is RFC 3748.
> >>
> >>             jak
> >>
> >> ----- Original Message ----- From: "Marco Liebsch" 
> >> <[email-masked]>
> >> To: "James Kempf" <[email-masked]>
> >> Cc: "Rajeev Koodli" <[email-masked]>; "gabriel montenegro"
> >> <[email-masked]>; <[email-masked]>
> >> Sent: Thursday, April 07, 2005 9:12 AM
> >> Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
> >>
> >>
> >>
> >>> Hi James,
> >>>
> >>> I see 1.) and 3.) perfectly covered by the same document. Since
> >>> InfoElements use same encoding rule as (sub-)options for CARD do (TLV),
> >>> this can be harmonized.
> >>>
> >>> 2.) could be a separate document just for handover and associated
> >>> forwarding control, as you proposed. 1)/3.) then serves as solution
> >>> for handover preparation, 2.) as handover execution related solution.
> >>>
> >>> This also meets the requirement on clear separation of functionality:
> >>> Neighborhood discovery vs. handover execution.
> >>>
> >>> What do you think?
> >>>
> >>> marco
> >>>
> >>>
> >>>
> >>> James Kempf wrote:
> >>>
> >>>
> >>>> Rajeev,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>> - Would such a unified set of information elements imply any changes
> >>>>>> to the
> >>>>>> existing information elements in FMIPv6?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> No.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> Actually, I disagree. Please see below.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>> Even if it doesn't, wouldn't the subset of them that currently in
> >>>>>> FMIPv6 need
> >>>>>> to be lifted into this new document? FMIPv6 would refer to that
> >>>>>
> >>
> >> document
> >>
> >>>>>> for its information elements ( a subset of the whole thing).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> The process of performing "inverse ND" for an AP Address to obtain
> >>>>
> >>
> >> target
> >>
> >>>>> subnet information is *basic* to FMIPv6. Any other property of the AP
> >>>>> that a MN may be interested, e.g., to perform a target AR 
> >>>>> selection, is
> >>>>> suitable
> >>>>> for the "information elements" draft. So, I don't think anything from
> >>>>> FMIPv6
> >>>>> needs to be lifted into a new document. The LLA option format 
> >>>>> should be
> >>>>> made consistent (see below).
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> This "inverse ND" is also defined in CARD. There, it is called 
> >>>> "reverse
> >>>> address translation" (Section 3.1). In fact, CARD is designed to 
> >>>> work for
> >>>> IPv4 as well, which should help for your FMIPv4 draft. With a modified
> >>>> version of CARD appropriate for both FMIP and 802.21, there is one
> >>>
> >>
> >> mechanism
> >>
> >>>> to do this for both IPv4, IPv6 and 802.21, rather than one for IPv4 
> >>>> and
> >>>
> >>
> >> one
> >>
> >>>> for IPv6 and one for 802, as would be the case if the "reverse address
> >>>> translation" mechanism were duplicated in two drafts, the FMIPv4 and
> >>>
> >>
> >> FMIPv6
> >>
> >>>> draft, and a separate one for other neighborhood information.
> >>>>
> >>>> In addition, certain parts of  "inverse ND" as defined in FMIP have 
> >>>> been
> >>>> superceded by recent events. As defined by the FMIP draft, "inverse 
> >>>> ND"
> >>>> includes both discovery of neighboring subnet prefix  and router
> >>>
> >>
> >> information
> >>
> >>>> through mapping from AP to AR address and support for pre-handover
> >>>
> >>
> >> duplicate
> >>
> >>>> address detection. The latter is now obsolete. With the progression of
> >>>> optimistic DAD towards PS (it is likely to get a PS RFC number before
> >>>
> >>
> >> FMIP
> >>
> >>>> does), there is no need for pre-handover duplicate address 
> >>>> detection. It
> >>>> complicates the protocol and is not possible anyway in the only 
> >>>> case that
> >>>> really matters right now, 802.11, because 802.11 does not have 
> >>>> predictive
> >>>> handover. It might be possible on 802.16, which does have predictive
> >>>> handover as one option, but I believe it makes sense to simplify the
> >>>> protocol and use optimistic DAD since I don't see any real difference
> >>>
> >>
> >> from a
> >>
> >>>> technical standpoint. In fact, Rajeev, if I remember correctly I 
> >>>> believe
> >>>> your original individual draft for an FMIP predecessor had 
> >>>> optimistic DAD
> >>>
> >>
> >> in
> >>
> >>>> it. Do you see any problem with using optimistic DAD now, other 
> >>>> than it
> 
=== message truncated ===

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 May 2005 09:30:01 -0700

Gab,

I think it is fair to say that the reactive case is better understood
because people have implemented it and tested it more, and that is because
it has been easiest to do that with 802.11.

We tested predictive handover on an earlier version of FMIP using a handover
emulator (802.3 with a box in the middle simulating the link). There were
some problems with it that we fed back into the design and Rajeev
incorporated it into the document (primarily decoupling the PrxyRtXXX
messages from the immediate handover period). And I believe there was an
implementation done as part of the MobyDick project using 802.11 in ad hoc
mode that allowed predictive handover to be tested (Marco can correct me if
I'm wrong). So there has been some testing.

Regarding FMIP-over-CDMA and FMIP-over-WiMax, I believe it would be
worthwhile inquiring of people in the respective standardization groups
about interest, and recruiting one of them to help with the drafts if there
is any.

            jak

----- Original Message ----- 
From: "gabriel montenegro" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "James Kempf"
<[email-masked]>; "Marco Liebsch" <[email-masked]>
Sent: Tuesday, May 03, 2005 2:15 AM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 03 May 2005 12:12:59 -0700

Hi Gabriel,

the behavior part of predictive handover is clear enough
for standardization. The hooks needed to invoke the predictive
handover are still not widely available. I think a tool like Host AP driver
gives implementors an API to invoke a handover based on
host-specific handover logic. We have used Host AP driver and
we can do predictive handovers. The folks at Keio University
are using their own L2 triggers to effect handovers. I believe folks 
(Peng Sun) at
Institiute for Infocom Research in Singapore have done predictive
handovers (cf. Seoul IETF MobOpts presentation).
And, once the 802.21 triggers are specified, that should be
appealing for implementors as a standard way of invoking
FBU from the previous link (i.e., predictive handover).

I plan to incorporate changes from the implementation experiences.
In the process, I expect the protocol specification will only get
better and the predictive mode will be more succintly specified.

In summary, the behavior is tested via implementations. We can do them
using existing tools (Host AP driver). Standardized triggers can help.

Regarding the reactive mode: assuming no Proxy Router message exchange,
we still have to rely on hooks being available. For instance, a "link up"
indication, faster ways of doing router discovery, IP address configuration
(i.e., DNA). So, the situation is not very different: behavior is 
understood, hooks
are available, some of those hooks are being standardized.

I feel confident that we can produce a single document (with two modes)
that will stand up to the rigors of PS process.

Regards,

-Rajeev

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 04 May 2005 09:43:35 +0200

Rajeev, James,

the implementation we tested in MobyDick just considered predictive 
handovers.
To reduce the L2 latency we used the cards in "ad hoc" mode and the 
terminal triggers the
handover based on a proprietary l2 trigger mechanism (we mainly modified 
a version of the hostap driver).
Together  with Marco, we are currently working on a more deployable 
solution (Daidalos project) combining
CARD together with the draft on network initiated handovers we presented 
during the last meeting in Minneapolis.
Again in this scenario we consider predictive handovers, being the 
combination with the admission control
entity in the network much easier. Layer 2 triggers are still a 
proprietary scheme.

Comments?

regards,
Telemaco

Rajeev Koodli wrote:

>------------------------------------------------------------------------
>

-- 
Telemaco Melia          	[email-masked]
Research Staff Member		Tel: +49 (0) 6221 90511-42
Network Laboratories    	Fax: +49 (0) 6221 90511-55
NEC Europe Ltd.         	Web: http://netlab.nec.de
Kurfrsten-Anlage 36
D-69115 Heidelberg
Germany

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 May 2005 08:28:45 -0700

Telemarco,

Do you use infrastructre mode or ad hoc mode in Daidalos?

            jak

----- Original Message ----- 
From: "Telemaco Melia" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; "James Kempf" <[email-masked]>; "Marco
Liebsch" <[email-masked]>
Sent: Wednesday, May 04, 2005 12:43 AM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 04 May 2005 18:05:55 +0200

Hi James,

we depoly infrastructure mode with an accelerated WLAN driver.
We should be able to report first test results by next meeting in Paris.

Telemaco (without *"R"*) :-)

James Kempf wrote:

>>>we still have to rely on hooks being available. For instance, a "link
>>>      
>>>
>up"
>  
>
>>>>>>>the mobile node can use information on neighboring subnets in order
>>>>>>>              
>>>>>>>
>to
>  
>
>>>>>I see the difference between predictive and reactive is the Proxy
>>>>>          
>>>>>
>messages.
>  
>
>>>>>So, it is far simpler to have a single document with two modes.
>>>>>          
>>>>>
>Besides,
>  
>
>>>>>when
>>>>>>>>InfoElements use same encoding rule as (sub-)options for CARD do
>>>>>>>>                
>>>>>>>>
>(TLV),
>  
>
>>>>>>>>this can be harmonized.
>>>>>>>>
>>>>>>>>for handover preparation, 2.) as handover execution related
>>>>>>>>                
>>>>>>>>
>solution.
>  
>
>>>>>>>>This also meets the requirement on clear separation of
>>>>>>>>                
>>>>>>>>
>functionality:
>  
>
>>>>>>>>>>>- Would such a unified set of information elements imply any
>>>>>>>>>>>                      
>>>>>>>>>>>
>changes
>  
>
>>>>>>>>>>>to the
>>>>>>>>>>subnet information is *basic* to FMIPv6. Any other property of the
>>>>>>>>>>                    
>>>>>>>>>>
>AP
>  
>
>>>>>>>>>>for the "information elements" draft. So, I don't think anything
>>>>>>>>>>                    
>>>>>>>>>>
>from
>  
>
>>>>>>>>>>FMIPv6
>>>>>>>>>IPv4 as well, which should help for your FMIPv4 draft. With a
>>>>>>>>>                  
>>>>>>>>>
>modified
>  
>
>>>>>>>>>for IPv6 and one for 802, as would be the case if the "reverse
>>>>>>>>>                  
>>>>>>>>>
>address
>  
>
>>>>>>>>>translation" mechanism were duplicated in two drafts, the FMIPv4
>>>>>>>>>                  
>>>>>>>>>
>and
>  
>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>FMIPv6
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>address detection. The latter is now obsolete. With the progression
>>>>>>>>>                  
>>>>>>>>>
>of
>  
>
>>>>>>>>>optimistic DAD towards PS (it is likely to get a PS RFC number
>>>>>>>>>                  
>>>>>>>>>
>before
>  
>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>FMIP
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>handover. It might be possible on 802.16, which does have
>>>>>>>>>                  
>>>>>>>>>
>predictive
>  
>
>>>>>>>>>handover as one option, but I believe it makes sense to simplify
>>>>>>>>>                  
>>>>>>>>>
>the
>  
>
>>>>>>>>>protocol and use optimistic DAD since I don't see any real
>>>>>>>>>                  
>>>>>>>>>
>difference
>  
>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>from a
>>>>>>            
>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 10 May 2005 01:48:55 -0700 (PDT)

Folks,

Based on the discussion, interest shown, etc, here's a reduced list of next 
milestone items. Other items, of course, could be added once progress on 
this list has been made.

Further work on FMIPv6
----------------------

- work on MN-AR security. 

   - AAA-based keys for handovers - 
 
   - derive key from SeND for fmip 

	2 documents

- work on FMIPv6 itself:

		1. common information elements for use by 802.11, fmip6, fmip4
		2. local repair a la FBU/FBAck/FNA
		3. IP transport of those information elements from the AR
			(PrRtXXX + CARD MN-AR ==> ICMPv6?)

	potentially two docs:

	- info elements (#1 above)
	- "FMIPv6" (#2 and #3)

	2 documents

RR optimizations
----------------

- merge of CGA-OMIP and CBA 

	1 document

Total:  5 documents

I believe this captures what the WG wants and can reasonably do in the short term.
Unless the list above is terribly broken, this is what I'd like to present to the
AD's for approval.

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Tue, 10 May 2005 09:33:56 -0700

Gab,

This sounds like an excellent list. Have you thought about a schedule of
completion?

           jak