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

From: Rajeev Koodli <[email-masked]>
Date: Thu, 31 Mar 2005 18:20:40 -0800

Hi Greg,

Greg Daley wrote:

>> You mean the previous router can also support HA functionality right?
>
>
> No, not really.
>
> The issue isn't about the capabilities of the previous access router,
> which are well known (the MN was just there).  The issue is the
> requirement for a tunnel endpoint in the new AR, and the ability to
> process FBU messages.
>
But, the new AR is neither the tunnel end-point nor processes the
FBU.

> The issue is that the MN doesn't know (because prediction failed)
> that the AR supports this.  Perhaps we can learn this upon our visit,
> but this would either require probes or use of an existing information
> service like RA or DHC (I guess RA could be used).
>
So, let's say when the MN visits an access point AP-X, it realizes that
it has no subnet information for that AP. That is, prediction has failed.
So, the MN

a)  does movement detection
b)  does IP configuration, and
c)  sends FBU to previous AR.

DNA should help with a) and b). We have reactive fast handovers
without neighbor maps, and with HA functionality on the router.

This should work, right?

>
> Absolutely.  My assumption previously was about knowledge of whether
> FBU could be sent to an AR.

This is related to whether the AR is also an HA and how a MN knows about
it. Since FBU only needs a new Type number, an AR that is an HA can
support FBU. We could indicate it using a bit in the RA. Perhaps this is
what you meant by DHC/RA above?

>> I don't see an FMIP router being different from a temporary HA for the
>> reactive case. If you only care for reactive handovers, you can do that
>> with the HA functionality extended for temporary tunnels for fast 
>> handovers.
>>
>
> Yes. I can see that.  There are a few tricks with ND caches may not be
> easy.  Do you have any idea how hard it was to keep the caches clean 
> from your group's implementation?
>
We simply re-use the BCE datastructure. The HA also acts as a Proxy for NA.
Basic HA functionality.

>> I believe DNA should be useful for FMIP! Once the MN discovers
>> subnet movement, becomes IP-enabled, it can send FBU to the
>> previous router. I think DNA should help in sending FBU faster.
>
>
> Oh OK, I think we were talking at cross purposes.
>
> That clears things up a lot.
>
Yes, I believe DNA should help with reactive fast handovers
in the absence of neighbor maps or when prediction fails.

>> I don't see any reason why maps cannot be shared between subnets.
>
>
> There's no reason why they can't.  It's just that they won't without
> explicit management.
>
It's the same for intra-subnet too.

> This is all working on the host side though.  It's not like there's
> a set of procedures which is going to allow APs to share cross
> link boundary information without management.
>
I don't know. But I have a feeling someone else will solve this.

> There's no network upgrade (apart from the DNA and FastRA of course ;),
> and the host is in control regardless of the network's infrstructure.
>
This is an unbalanced statement. Again, I have to repeat that FMIP is not
an upgrade anymore than MIP and DNA are for today's networks for reactive
handovers.

>
> I don't really think that the costs are terribly high in this case,
> as the optimization and security model for RR+ is conversation based and
> end-to-end.
>
In this case (reactive handovers), the cost of access network handovers 
is the
cost of supporting MIP, which RR also needs AFAIK.

>
> I guess that I'm arguing for a new view of the technology, in addition
> to the established view with is based on (local/regional) HAs.  I'm not
> trying to get rid of the existing work.
>
I am only pointing out that when you say no network infra is needed, you
are assuming an HA (for RR, RR+) somewhere. The very same HA on an
AR can also provide reactive fast handovers. Just to put the two 
perspectives
together..

-Rajeev

> In some cases it may take a different set of tricks to achieve good
> performance.
>
> Greg
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 1 Apr 2005 10:27:04 -0800

> The MN sends an Early Binding Update to the CN telling it to use the
> new CoA (instead of the old one).  In some cases, the reception of
> packets at the old CoA is possible, even though the MN would prefer
> the binding to change.  In some environments (say with CBA) there's not
> going to be a convincing reason for the CN to send packets to the
> unverified new CoA, so falling back to transmitting to the old CoA is
> at least as good as changing the binding to drop packets.
>

But let's think of this from the DNA standpoint.

The MN has some reason to believe it is on a new IP link, some indication
from L2. It probes, RS/RA, finds yes.

How would the old CoA be of use at that point, unless there was some access
network mechanism for interAR forwarding, or the MN used FMIP to update the
old AR with it's location?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 1 Apr 2005 10:37:07 -0800

> I don't know. But I have a feeling someone else will solve this.

Don't count on it. This is exactly the problem that Seamoby failed to come
up with a solution for. I think it's probably a good topic for a draft in
Mobopts, if anybody cares.

> an upgrade anymore than MIP and DNA are for today's networks for reactive

Well, I suppose one could take the position that, really, IPv6 is a network
upgrade, and a network operator will need to do that before any of these
technologies can be used. In the face of that, including DNA, FMIP or
whatever on the access routers is pretty trivial.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 04 Apr 2005 09:56:01 +1000

Hi James,

> old AR with it's location?

I'd argue that while there's little benefit in defaulting to the
existing CoA in this case, the cost of sending trough the home agent is
in most cases worse (in terms of latency, reordering, etc).

The choice of not modifying the binding cache makes an EBU equivalent to
a CoTI (and may actually function as one if we rationalize the EBU/CoTI
messages).  The trust accorded to the MN is then exactly the same as for
MIPv6 RR, which is already in existence.

So it can be readily argued that the procedure doesn't make the security
any worse, and is easily predictable.

If the MN can explicitly ask for the data to be directed to its own
verified home address, I guess that's fine, but I think a default should
be treat the message as a CoTI if there's insufficient reason to send
packets to the unverified address.

Greg

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 4 Apr 2005 03:14:18 +0300 (EEST)

Hi Greg,

> MIPv6 RR, which is already in existence.

=> If this is the case then IMHO it can be applied to OMIPv6...
Am I missing something?

Regards,

Wassim H.

---

From: Greg Daley <[email-masked]>
Date: Mon, 04 Apr 2005 10:38:54 +1000

Hi Rajeev.

> But, the new AR is neither the tunnel end-point nor processes the

After re-reading FMIPv6 (again), I see that the NAR isn't an
endpoint.

For some reason I thought that FMIPv6 escaped the encapsulation tax
and used unusual proxying techniques on the new link.

Was that in an old (old) version of the spec?

> without neighbor maps, and with HA functionality on the router.

My only concern was the requirement for HI/HAck, which aren't needed in 
this case.

> what you meant by DHC/RA above?

Yes. It is. This information could be stored and then RtSolPr could be 
sent (or SA bootstrap), or if there's no valid PrRtAdv upon arrival on a
new link, the existing knowledge could be used to send an FBU.

Bits are really hard to find in the RA header though.  It would be nice
if the combination of the H bit and SA/CGA bootstrap meant FMIPv6.

> We simply re-use the BCE datastructure. The HA also acts as a Proxy for NA.

Yes, I see after rereading that the main worry I had was about the
TEP being on the NAR.  That would have been sticky.

Now I see that the function is as close to MIPv6 as it could have been
for this case.

> It's the same for intra-subnet too.

Yes, but the L2 switching domain within the link is going to
redirect packets to the MN if it sends any packets at all.
So the urgency is less (if the L2 handoffs cost is discounted).

> an upgrade anymore than MIP and DNA are for today's networks for reactive

It seems that the costs are lower than I thought.

> cost of supporting MIP, which RR also needs AFAIK.

There's a decision as to whether the function is placed in each AR or
not. There are advantages in HMIPv6 like networks to say:

We can avoid putting function in every device.

On the other hand, there's advantages in FMIPv6 saying:

We can do this without (separate) points of failure in the network
(security bootstrap becomes easier too).

I'd guess that with an RR+, the requirement on the home network may
go down.  Removal of home tests from the network (for example with CGA),
mean that the identity isn't as tied to a particular place since the
proof of identity is separated from reachability through the HA.

As a pipe dream, if the delivery of signaling packets also wasn't tied
to transfer through the HA, then MIPv6 wouldn't need Home Network 
support at all, if it could avoid the rendezvous problem (for example
with multiple interface bindings).  This is fodder for Mobopts though.

> AR can also provide reactive fast handovers. Just to put the two 

That's fair enough.  Homeless MIPv6 (or HIP, SCTP or MOBIKE) is a real 
possibility if nearby FMIPv6 or HMIPv6 (or MIPv6 bootstrap) agents will
provide addressing  continuity across subnet change.  For single
interface devices this can effectively chop out the rendezvous problem.

Greg

---

From: Greg Daley <[email-masked]>
Date: Mon, 04 Apr 2005 14:53:43 +1000

Hi Wassim,

> => If this is the case then IMHO it can be applied to OMIPv6...

I don't think you're missing anything.

The function for the redirection to home may be functionally
equivalent to the keepflow option from CGA-OMIPv6,
but I'm not sure that function belongs with the long-life
home Kbm.

I think this is how I'm seeing things at the minute.
Please be aware that I'm thinking as I go:

A combined message (not piggyback, but options) which
does EBU along with CoTI, refusal is by default a
rejection of just EBU function.

EBAck is sent back with CoT.

MN receives EBAck, collects the new Care-of keygen token
and sends a BU.

--

At the point where the EBU is sent, the selection of Home or
unverified care-of addresses is made.  I'm not sure where the
response should go, since there's a conflict between sending
the packet back to the Home Address (which it concerns) or
the unverified Care-of-Address (which is the recipient of CoT).

There are still significant problems with RR if there's an
on-path (at least on-home-path) attacker.  If this is teamed with an
early binding scheme (either the unverified-CoA or Home redirection),
an on-home-path attacker could use the CoTI/CoT function implied
by one of these (newer) EBUs to upgrade to a full BU, potentially
without knowledge of the MN.

Of course, this can be done in MIPv6 as well, with raw CoTI/CoT,
so the threat may not be worse.

If the OMIPv6-CGA Shared Key payload is appropriately
constructed (with freshness information) then only the MN could
send a correct Kbm for the BU.

Greg

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 4 Apr 2005 22:24:29 +0900

Dear Christian

> I was looking for a general fallback solution.  But indeed, sending the
> packets to the old CoA, in case sending them to the unverified in
> unacceptable, is probably the better approach anyway. At least from the
> MN's perspective.  The CN wastes some resources if a MN cannot receive
> the packets at the old CoA, but well, who cares...

I agree. It seems the best to keep sending packets to the old CoA.   
 
> We could specify a mechanism for the MN to request a fallback solution.
> But IMO things get too complex then, so we shouldn't do this.
 
yes. I doubt the added benefits are worthy of the added complexities.   

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 4 Apr 2005 22:24:46 +0900

Dear Rajeev

> without neighbor maps, and with HA functionality on the router.

yes. 
 
> in the absence of neighbor maps or when prediction fails.

agree. 

Best Regards

JinHyeock

---

From: Christian Vogt <[email-masked]>
Date: Wed, 06 Apr 2005 16:46:32 +0200

Wassim Haddad wrote:
>> existing CoA in this case, the cost of sending trough the home
>> agent is in most cases worse (in terms of latency, reordering,
>> etc).
>> 
>> The choice of not modifying the binding cache makes an EBU
>> equivalent to a CoTI (and may actually function as one if we
>> rationalize the EBU/CoTI messages).  The trust accorded to the MN
>> is then exactly the same as for MIPv6 RR, which is already in
>> existence.
> 
> => If this is the case then IMHO it can be applied to OMIPv6... Am I
> missing something?

Hi Wassim, hi all,

right.  If we leave it up to the MN to request, after a handover, to
which address the CN should temporarily send its packets, we end up with
three options in both cases, OMIPv6 and EBU.  (We talked about this
before, but we only considered EBU.)

Option (1):  The MN wants the CN to continue to send packets to the OLD
CoA (until the BU reaches the CN).
- When using OMIPv6, the MN sends a Pre-Binding Update message without a
KeepFlow option, initiating the OMIPv6 binding-update procedure.
- When using EBU, well, the MN simply omits the Early Binding Update
message.  In other words, the MN follows the standard RFC-3775
binding-update procedure.
- In either case, the Care-of Test Init message does not lead to a
change in the CN's binding cache.

Option (2):  The MN wants the CN to send packets to its HoA (until the
BU reaches the CN).
- When using OMIPv6, the MN sends a Care-of Test Init message with a
KeepFlow option, initiating the OMIPv6 binding-update procedure.
- When using EBU, the MN sends a standard deregistration BU, just like
defined in RFC 3775, and initiates the standard RFC-3775 binding-update
procedure. (No changes to RFC 3775.)
- Either message is authenticated by a BAD, although the Authenticators
inside the BAD's are computed differently.

Option (3):  The MN wants the CN to already send packets to its NEW CoA.
  This should be the most efficient option in most cases.  In order to
make this option secure, we need Credit-Based Authorization (see below).
- When using OMIPv6, we need a new option for the Care-of Test Init
message in order to tell the CN that it should use the new CoA.  The
semantics of the existing KeepFlow option are currently such that the CN
diverts packets to the HoA.  But, well, actually we could use the
existing KeepFlow option also for redirecting packets to the new CoA.
We would just have to put the new CoA inside instead of the HoA.
- When using EBU, the MN sends an Early Binding Update message, and does
the remaining binding-update procedure in RFC-3775 style.  (Note that we 
can combine the Early Binding Update message with the Care-of Test Init 
message in order to eliminate any increases in signaling overhead.)
- Both the Care-of Test Init message with the KeepFlow option as well as
the Early Binding Update message are authenticated by a BAD, although
the Authenticators inside the BAD's are computed differently.

With option (3), the CN could use Credit-Based Authorization in order to
accept or deny the MN's request to send packets to the new,
yet-unverified CoA.  If CBA leads the CN to deny the request, the CN
simply ignores the KeepFlow option in the OMIPv6 case, or the Early
Binding Update message in the EBU case.  Then, option (3) reduces to
option (1).

We have talked about dropping packets as a potential option (4).  That
would need a different mechanism, possibly another option or flag inside
the various messages.  However, I think that Greg has made a clear and
reasonable statement in favor of using the old CoA over dropping
packets.  So I don't think we need option (4) at all.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Wassim Haddad wrote:
>>>> The MN sends an Early Binding Update to the CN telling it to
>>>> use the new CoA (instead of the old one).  In some cases, the
>>>> reception of packets at the old CoA is possible, even though
>>>> the MN would prefer the binding to change.  In some
>>>> environments (say with CBA) there's not going to be a
>>>> convincing reason for the CN to send packets to the unverified
>>>> new CoA, so falling back to transmitting to the old CoA is at
>>>> least as good as changing the binding to drop packets.
>>> 
>>> 
>>> The MN has some reason to believe it is on a new IP link, some
>>> indication from L2. It probes, RS/RA, finds yes.
>>> 
>>> How would the old CoA be of use at that point, unless there was
>>> some access network mechanism for interAR forwarding, or the MN
>>> used FMIP to update the old AR with it's location?
>> 
>> existing CoA in this case, the cost of sending trough the home
>> agent is in most cases worse (in terms of latency, reordering,
>> etc).
>> 
>> The choice of not modifying the binding cache makes an EBU
>> equivalent to a CoTI (and may actually function as one if we
>> rationalize the EBU/CoTI messages).  The trust accorded to the MN
>> is then exactly the same as for MIPv6 RR, which is already in
>> existence.
> 
> 
> => If this is the case then IMHO it can be applied to OMIPv6... Am I
> missing something?
> 
> 
> Regards,
> 
> Wassim H.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 09:27:55 -0700

The goal is to come up with something that is useful to 802.21 as well, like
EAP. If IP transport is specified in the same doc as the information
elements, it will be less useful since 802.21 will likely want to use a
layer 2.5 transport. That's why I think 1) needs to be separate. 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.

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
> >would involve a change in the text of the current FMIPv6 specification?
> >
> >Therefore, IMHO, going forward, the only the part of the "inverse ND"
> >operation that is really necessary to define is the neighborhood
discovery
> >part and that can be done by having the same information elements to
convey
> >the AR address, subnet prefix, and AP address information from the AR to
the
> >MN as for other neighborhood information, and define a transport for that
at
> >the IP layer.
> >
> >
> >
> >>It is important to delineate the (offlink) inverse ND operation that
> >>
> >>
> >FMIPv6
> >
> >
> >>performs from the process of  neighborhood discovery for target AR
> >>selection.
> >>The former needs to be in the FMIP base spec for it to operate without
> >>depending on a particular AR selection method.
> >>
> >>
> >>
> >
> >Can you explain why the format and definition of the information elements
> >involved in conveying the address and prefix information for "inverse ND"
or
> >"reverse address translation" need to be any different than those for
other
> >candidate access router characteristics, since they will be conveyed in
the
> >same manner from the AR to the MN?
> >
> >
> >
> >
> >>>Presumably, in this new document, no duplication would exist. For
> >>>example,
> >>>instead of having both of these:
> >>>
> >>> - FMIPv6 Link-layer Address (LLA) Option (sectin  6.4.3)
> >>> - CARD L2 ID Sub-Option (section 5.1.3.1)
> >>>
> >>>One should one have only one way of codifying the link-layer
> >>>
> >>>
> >information.
> >
> >
> >>>Same for other common information elements.
> >>>
> >>>I *believe* this is what both of you agreed to. Please correct
> >>>if this is wrong.
> >>>
> >>>
> >>>
> >>Moving forward, we can specify a single option format as we revise
> >>FMIPv6 towards PS. CARD can use the same format when it comes
> >>for PS.
> >>
> >>In sum, the FMIPv6 LLA option format can be revised to be consistent.
> >>The "information elements" draft can be useful for 802.21, and possibly
> >>for CARD as well.
> >>
> >>
> >>
> >
> >I don't see either CARD or FMIPv6 moving forward to PS as they currently
> >stand. As I've stated before, what I think we want is a clean functional
> >architecture, where the functions and interfaces are cleanly separated
and
> >we reuse mechanisms from other IETF PS RFCs and drafts where appropriate.
> >What I would like to see is the following:
> >
> >1) A transport independent information element format like EAP that can
be
> >used by 802.21, but also by FMIPv4 and FMIPv6 to convey neighborhood
> >information about neighboring subnets from the AR to the MN upon MN
request
> >(and also possibly pushed by the AR, but we would need to do some more
> >design on that). The information includes AR subnet information (like
prefix
> >lists), AP link addresses, and other information appropriate to address
> >configuration on the neighboring link, which, today, are defined in both
> >CARD and FMIP.
> >
> >2) A protocol based on FBU/FBAck/FNA to allow change in the local routing
> >through setting up a short-term tunnel from the previous AR to the MN's
new
> >CoA.
> >
> >3) A protocol to convey the neighborhood information from the AR to the
MN
> >at the IP level, probably a set of request/reply ICMP messages merging
the
> >PrxyRtXXX messages and CARD MN-AR messages in some fashion.
> >
> >I have no objection to bundling 2) and 3) in one document for PS and
calling
> >it FMIP, but I believe 1) needs to be a standalone document in order that
it
> >be usable by 802.21.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Apr 2005 10:00:54 -0700

>pre-configure for handover.
The key is not to impose transport requirement for the neighborhod 
information elements draft.
The other important objective is to harmonize packet formats across 1, 
2, and 3.

-Rajeev

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 07 Apr 2005 18:12:23 +0200

Hi James,

What do you think?

marco

James Kempf wrote:

>>>to be lifted into this new document? FMIPv6 would refer to that document
>>The process of performing "inverse ND" for an AP Address to obtain target
>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
>translation" mechanism were duplicated in two drafts, the FMIPv4 and FMIPv6
>includes both discovery of neighboring subnet prefix  and router information
>through mapping from AP to AR address and support for pre-handover duplicate
>optimistic DAD towards PS (it is likely to get a PS RFC number before FMIP
>protocol and use optimistic DAD since I don't see any real difference from a
>your original individual draft for an FMIP predecessor had optimistic DAD in
>operation that is really necessary to define is the neighborhood discovery
>part and that can be done by having the same information elements to convey
>the AR address, subnet prefix, and AP address information from the AR to the
>MN as for other neighborhood information, and define a transport for that at
>the IP layer.
>
>  
>
>involved in conveying the address and prefix information for "inverse ND" or
>"reverse address translation" need to be any different than those for other
>candidate access router characteristics, since they will be conveyed in the
>architecture, where the functions and interfaces are cleanly separated and
>1) A transport independent information element format like EAP that can be
>information about neighboring subnets from the AR to the MN upon MN request
>design on that). The information includes AR subnet information (like prefix
>through setting up a short-term tunnel from the previous AR to the MN's new
>CoA.
>
>3) A protocol to convey the neighborhood information from the AR to the MN
>at the IP level, probably a set of request/reply ICMP messages merging the
>I have no objection to bundling 2) and 3) in one document for PS and calling
>it FMIP, but I believe 1) needs to be a standalone document in order that it
>be usable by 802.21.
>
>            jak
>
>            jak
>
>
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Apr 2005 02:41:45 -0700

> 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.
>

The problem is that there are not now any wireless protocols that would use
FMIP which allow proactive handover (modulo host AP). 802.16e will soon,
though. So, up until now, it has been all a matter of speculation.

> 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)?

I'd have to think about it. Actually, I think FMIP has a pretty good story
with respect to covering both, now that the mechanism of using the PrxyRtXXX
messages immediately prior to the handover has been eliminated. Some of the
mechanism is going to overlap, it will just be used differently in both
cases.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 11 Apr 2005 02:14:20 -0700

James Kempf wrote:
> layer 2.5 transport. That's why I think 1) needs to be separate.

I agree with this. It makes sense to have the info elements out on their
own so potentially 802.21 can make use of them. But I'd like to hear
from them about this.

I'm including Ajay, 802.21 chair as I'd like to solicit his input on
this item.

Ajay: There is a proposal to work on an item along these lines:

     transport independent information element format to convery neighborhood
     information. The idea is to use the same format for FMIPv6 and 802.21
     (and perhaps others, like FMIPv4).

What is 802.21's position in this respect?

> Bundling 2)

from DNA). The reactive case seems like a well-understood alternative in its own right,

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)?

-gabriel

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 13 Apr 2005 22:56:40 -0700

> Fast Reactive Handover (FRH) and another one on Fast Proactive 
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

>> ----- Original Message ----- From: "Marco Liebsch" 
>> <[email-masked]>

---

From: Greg Daley <[email-masked]>
Date: Thu, 14 Apr 2005 17:17:36 +1000

Hi Rajeev and Gabriel,

Not wanting to interrupt vacations or anything...

> I am inclined to have a single document for completeness.

I guess that the difference between HMIPv6 and FMIPv6 for the
non-predictive case now is how to trust the SA binding, and
how to discover the presence of an agent.

This isn't really a lot, considering that the tunneling
operations are fairly similar except for HI/HAck.

When one considers the handover-key signaling, there's quite
possibly a way forward for the SA bootstrap to be achieved
with HMIPv6 as well as FMIPv6.

If there's a clear idea of whether a single solution would do
for both of these then maybe the prediction can be split from the
tunnel endpoint discovery and (binding) signaling transport,
in a way which makes sense for both local-repair and 
signaling-reduction/location-privacy?

For example, the (Secured) Router Advertisement could
contains a MAP's CGA address and a precis of the key information,
which allows the MN to contact the MAP fairly securely.
The AR could indicate itself as the identity of the advertisement
for the FMIPv6 case.

Also, the AR could indicate that itself or the MAP (if there's a
MAP option) are capable of running FMIPv6 tunnel endpoint operations.

Clearly, it's possible to have FMIPv6 without the support for HMIPv6.
It's also possible for HMIPv6 to have different SA binding mechanisms
than FMIPv6 (because the potential lifetime of the SA is longer).

If there's one relatively general method to do these then that may be
better than proposing two systems and then making them work together
(or making them not work together ;)

This is not intended to provoke ill-feeling or put back work,
but the question has to be asked before we dive in.

Greg