Subject: RE: F-HMIPv6 ( was Re: [mobile-ip] RE: Address config for FMIPv6)

From: Soliman Hesham <[email-masked]>
Date: Wed, 25 Jun 2003 23:55:53 -0400

Greg, 

Thanks for the comments, one question and one comment.

 > Personally, just from my initial reading, I think
 > section 5.2 (No Anticipation) is too defensive.
 > 
 > There's likely to be limited benefit to doing
 > F-HMIPv6 with the old AR in the reactive case
 > (if the MAP is close) anyway, so I don't see an
 > issue here.
 > This is the likely topology for F-HMIPv6 so
 > I think it is worth saying this, rather than
 > indicating that reactive tunnel establishment
 > is unable to be achieved.

=> It is achievable but I'm not sure which tunnel
end point you want ?

 > 
 > What is worth indicating is that the De-encapsulation
 > provided by the BU with F-bit on the new access
 > network is valuable even in the reactive case.
 > This is certainly possible, if the MN can prove
 > that it is actually on that network.
 > 
 > It may be necessary in this case though to
 > ensure that an MN when it inspects the RA
 > checks that both the MAP and nAR support
 > F-HMIPv6.
 > 
 > This could also be used to initiate the tunnel
 > before a prediction is required (so one is always
 > using F-HMIPv6).

=> Ok, in hind sight I think we should put section
7 in section 5 sometime in future.

Hesham

---

From: Greg Daley <[email-masked]>
Date: Thu, 26 Jun 2003 14:38:33 +1000

> => It is achievable but I'm not sure which tunnel

I think you can say that F-HMIPv6 is uninterested
in pAR<=>nAR, but interested in MAP<=>nAR even
if there's no prediction (because of the MTU
benefits).

This doesn't need Hi/HAck, although some authorization
may be needed on the local link.

I wasn't talking about MAP<=>nLCoA.  This is
what we're trying to avoid isn't it?

> 7 in section 5 sometime in future.

About section 7, I actually think that it's fine
where it is.   There's a lot of value to indicating
which methods are optional (if you know what I mean).

I think that the tunnel extension (to the MN) for
F-HMIPv6 is a bit like co-located CoA in MIPv4:-

It's fine but why would you if you've got an FA?

I think the answer is the same except for the
predicition database in the ARs.

If there's no oAR with predictive capabilities, then
this can be resolved by RtSolPr querying the MAP
(maybe over the MAP tunnel).

For MN initiated handovers (on ARs which
don't explicitly support FMIPv6, for example),
I can't really see why this can't be done
on the MAP generally.

Is this just too far fetched?

Greg

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 Jun 2003 10:54:16 +1000

Hello Seok,

Seok Joo Koh wrote:
> Greg,
> 
> From: "Greg Daley" <[email-masked]>
> 
> I'm sorry but I don't understand what you mean by this :-)
> Cold you clarify this ?

What I'm talking about is that there's no need for the
tunnel extension MAP<=>MN, if the nAR provides tunneling
and decapsulation support (allows MAP<=>nAR).

If the nAR provides this, then the it is almost always
better to use the decapsulaion support in nAR (especially
if the access network link has a low MTU).

The tunnel extension to MN is only really useful if the
tunnel may not be easily established.

> In Section 5.2, "No Anticipation" means that both MN and oAR cannot predict the handover.
> Anyway, in case of MN-initiated handovers, the MN will send RtSolPr to oAR.
> 
> If oAR could provide any predictive capavbility, then we may have two choices:
> 1) MN sends it directly to MAP (over the MAP tunnel), where we assume
 > the MAP has the information to handle the messages.

I think this is reasonable, since the MAP is advertising as
F-HMIPv6 capable.   If it cannot predict movement it can
easily indicate this to the MN.

The MAP would have to undertake the HI/HAck with the nAR
in order to establish tunnel state, and send PrRtrAdv to
MN on the tunnel.

> 2) The oAR relays the received RtSolPr to MAP over a dedicated channel

I think 2) is not useful (or needs not be defined by F-HMIPv6,
since it is just a context transfer protocol).
This looks the same to the MN as if the oAR is a fully
functioning FMIPv6 router (I'm not sure the cost is less
on the oAR).

The issue is how little support you require in the access routers
and the MAP (since this is a deployment and scalability issue).

Greg

---

From: "HeeYoung Jung" <[email-masked]>
Date: Tue, 1 Jul 2003 08:50:21 +0900

Hi, Greg

I am one of co-authors of F-HMIP, HeeYoung Jung.

First of all, I'd like to thank you for your interest and active comments to F-HMIPv6.

Based on the discussion made so far, I'd like to summarize the issues on F-HMIPv6 and to give my opinion on those.

1) F-HMIPv6 in case of No Anticipation

  I agree to your comments, and I'd like to say that we are looking for a better scheme for it, which will be included in the version 02, we hope.

2) RtSolPr/PrRtAdv exchange between MAP and MN

  Actually, this case was already considered as you can see in version 00 of our draft. But we have not made any decision about which is better of the MAP-MN and MAP-nAR. They will have pros and cons respectively. In this respect, I would like to invite more comments from you and other experts, which will also be disposed in the version 02 of F-HMIPv6 document.

3) Tunneling end point (MN or NAR)

I think, the issue comes from the difference between FMIPv6 and HMIPv6. FMIPv6 prefers nAR as tunneling end point for stability, in contrast to MN (NcoA) in HMIPv6. My personal feeling on that is, " nAR may be used as the tunneling point, which seems to be more friendly with the FMIPv6 concept." But optionally or as a more elaborated scheme, we still need to incorporate the "tunnel-to-MN scheme" into the F-HMIPv6. 

I believe, how to enhance the F-HMIPv6 in this way will rely on the WG consensus and the further works in IETF.  

Thank you,

Young,

P.S: I send this mail again because of our e-mail server's problem.

       If you have already received this mail, ignore this message.

---

From: Greg Daley <[email-masked]>
Date: Tue, 01 Jul 2003 11:52:50 +1000

Hello Young,

HeeYoung Jung wrote:
> Based on the discussion made so far, I'd like to summarize the issues
 > on F-HMIPv6 and to give my opinion on those.
> 
>  
> 
>   I agree to your comments, and I'd like to say that we are looking for
 >   a better scheme for it, which will be included in the version 02,
 >   we hope.
> 
>  
> 
>   Actually, this case was already considered as you can see in version
 >   00 of our draft. But we have not made any decision about which is
 >   better of the MAP-MN and MAP-nAR. They will have pros and cons
 >   respectively. In this respect, I would like to invite more
 >   comments from you and other experts, which will also be disposed
 >   in the version 02 of F-HMIPv6 document.

I cannot speak for anyone else, but believe that
the two methods have different applicability.

Systems which are able to provide predictive PrRtrAdv
on a pAR are likely not to use tunnel extension for
the Data channel on the new link (since the nAR can do
tunneling).

If no prediction is available from a pAR then this doesn't
mean that the nAR isn't able to create a bidirectional
tunnel.

> I think, the issue comes from the difference between FMIPv6
 > and HMIPv6. FMIPv6 prefers nAR as tunneling end point for
 > stability, in contrast to MN (NcoA) in HMIPv6. My personal
 > feeling on that is, " nAR may be used as the tunneling point,
 > which seems to be more friendly with the FMIPv6 concept."
 > But optionally or as a more elaborated scheme, we still
 > need to incorporate the "tunnel-to-MN scheme" into the F-HMIPv6.
> 
> I believe, how to enhance the F-HMIPv6 in this way will
 > rely on the WG consensus and the further works in IETF.

I think that consensus may be harder to achieve (although as
you can see, progress toward agreements on FMIPv6 is
being made slowly :)

A series of applicability statements or descriptions of
how these tunnel-modes are useful will allow people to
decide how to implement in their environment.

I hope that as we discuss things on the list these
become clearer.

If we can determine the minimum requirements for F-HMIPv6
in unmodified AR and FMIPv6 environments, then the
descriptions may become easier to write, and hopefully
there's a better chance of it becoming adopted.

Greg