Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN A)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 10 Aug 2005 11:32:06 -0500

James, Alex,
On this particular point, I'd like to add one more objective:

We need to ensure that the failure case in FMIP doesn't lead to a handoff time that is worse than regular MIP6. This was the biggest flaw of Mip4 low latency handoffs - it led to worse than standard MIP handoff times when a message was lost. I think when someone deploys fast handoffs, they expect the handoff to be no worse than regular MIP, at the least - when dealing with degrading links, the chances of losing a message are not that low - so, I think it will help to ensure that the protocol accounts for this. 

Regards,
Vidya

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Petrescu 
> Alexandru-AAP021
> Sent: Wednesday, August 10, 2005 11:19 AM
> To: James Kempf
> Cc: Junghoon Jee; [email-masked]; Koshiro MITSUYA; Petrescu 
> Alexandru-AAP021; Soliman, Hesham
> Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
> Mobility Header (FNA)
> 
> 
> James Kempf wrote:
> > FMIP is an optimization, it isn't required. If the FBack is 
> lost, the 
> > MN can simply fall back to standard MIP6 handover. I think it makes 
> > more sense to simplify the protocol if we can.
> 
> Let me follow up on this particular issue ("simplify the 
> protocol...").
> 
> In one sense - yes, I believe it should be simplified, at 
> least in order to be easier to grasp by a programmer.
> 
> Paradoxically, the strange thing about it is that the 
> protocol as described depends on at least three other 
> potential protocols that are not described anywhere:
> 
> -how do the ARs learn about each other's AR-Info.
> -how do the ARs learn their APs' "AP-ID"s, when AP and AR are 
> disjoint. -what's "assigned addressing" that NAR uses to 
> assign addresses.
> 
> Also, the protocol relies a lot on variable-length link-layer 
> addresses.  That's ok but it means it won't work with 
> 0-length link-layer addresses, like point-to-point ppp and 
> successors.  Which is fine, but should probably be noted somewhere.
> 
> Alex
> 
> 
> _______________________________________________
> 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: Syam Madanapalli <[email-masked]>
Date: Wed, 10 Aug 2005 22:59:54 +0530

Hi Vidya,

What type of failure cases you are talking about?

Pridiction failure or FBU failure?

If it is prediction failure DNA (if used) may help.
If it is FBU failure due to packet loss, MIP6 BU 
may also fail due to the same reason.  

-Syam

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 13:04:23 -0700

The failure case in FMIP is that the FBU doesn't get delivered or the FBack
doesn't. In either case, the result is just that the packets are lost which
the MN would otherwise have gotten if FMIP had succeeded, but this doesn't
interfere with the basic MIP6 handover.

            jak

----- Original Message -----
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "Petrescu Alexandru-AAP021" <[email-masked]>; "James
Kempf" <[email-masked]>
Cc: "Junghoon Jee" <[email-masked]>; <[email-masked]>; "Koshiro MITSUYA"
<[email-masked]>; "Soliman, Hesham" <[email-masked]>
Sent: Wednesday, August 10, 2005 9:32 AM
Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

> We need to ensure that the failure case in FMIP doesn't lead to a handoff
time that is worse than regular MIP6. This was the biggest flaw of Mip4 low
latency handoffs - it led to worse than standard MIP handoff times when a
message was lost. I think when someone deploys fast handoffs, they expect
the handoff to be no worse than regular MIP, at the least - when dealing
with degrading links, the chances of losing a message are not that low - so,
I think it will help to ensure that the protocol accounts for this.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 14:22:13 +0200

> may also fail due to the same reason.

MIP6 BU/BAck have some retransmission mechanisms, FBU doesn't.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 14:38:41 +0200

> interfere with the basic MIP6 handover.

In "predictive" case with "assigned addressing" the PAR sending FBAck is
conditioned by it receiving HAck.  If PAR does not receive HAck it can't
confirm the NCoA to MH.    So MN can't use NCoA.  NCoA is the address MN
uses for updating its HA too.

So, because HAck isn't delivered, or because it may be re-transmitted,
updating the HA (not the PAR) seems to be delayed too.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 14:50:55 +0200

Narayanan Vidya-CVN065 wrote:

> James, Alex, On this particular point, I'd like to add one more
> objective:
> 
> We need to ensure that the failure case in FMIP doesn't lead to a 
> handoff time that is worse than regular MIP6. This was the biggest
> flaw of Mip4 low latency handoffs - it led to worse than standard MIP
> handoff times when a message was lost. I think when someone deploys
> fast handoffs, they expect the handoff to be no worse than regular
> MIP, at the least - when dealing with degrading links, the chances of
> losing a message are not that low - so, I think it will help to
> ensure that the protocol accounts for this.

I agree partially with this.

I'd have a related remark.

I am looking for informal comments about actual user-experience of IPv6
real-time audio-video streaming that works excellent, and when Mobile
IPv6 is used (instead of IPv6) that that experience degrades significantly.

Because I know for example that when Mobile IPv6 handovers are used with
non-real-time audio-video streaming there are no glitches in my
user-experience ("buffering" is used).

Alex

---

From: Subba Reddy <[email-masked]>
Date: Thu, 11 Aug 2005 19:51:23 +0530

Hi Alexandru,

> confirm the NCoA to MH.    So MN can't use NCoA.

(I am mentioning the procedure in the existing FMIPv6)
That means MN has not received FBack. So MN sends FNA[FBU],
in NAR's link after association. If the address (NCoA) is conflicting
then NAR will send RA with NAACK. So, if MN don't receive
RA with NAACK, then MN may assume that NCoA is not in use.
I am not assuming packet loss for RA and FNA[FBU].

Thanks & Regards,
Subba Reddy

> NCoA is the address MN

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Aug 2005 08:21:36 -0700

By "assigned addressing" do you mean "stateful address configuration" via
DHCPv6?

        jak

----- Original Message -----
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Narayanan Vidya-CVN065" <[email-masked]>; "Petrescu
Alexandru-AAP021" <[email-masked]>; "Junghoon Jee"
<[email-masked]>; <[email-masked]>; "Koshiro MITSUYA"
<[email-masked]>; "Soliman, Hesham" <[email-masked]>
Sent: Thursday, August 11, 2005 5:38 AM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 18:03:48 +0200

> I am not assuming packet loss for RA and FNA[FBU].

So, if NAR sends the RA with NAACK and MH does not receive it (because
RAs may get lost) then MH uses NCoA and wrongly updates its HA with an
NCoA that presumably belongs to somebody else.

In other words, because FMIPv6 relies that RAs are always received by MH
the Mobile IPv6 implementation may get stuck... (?)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 18:36:10 +0200

> By "assigned addressing" do you mean "stateful address configuration" via

I've tried to use "assigned addressing" the way it is used in the
document.  I am not sure what the document means in the first place
about "assigned addressing", I've posted a separate question on this.

I was thinking it may mean "PPP for IPv6" but even in that case the PPP
will not actually assign an address but negotiate an Interface
Identifier and the mobile will "assign" the address to itself.

Could anyone please explain what "assigned addressing" is.

Alex

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 11 Aug 2005 22:28:52 +0530

> Could anyone please explain what "assigned addressing" is.

Assigned address means NAR provides the address (NCoA) for MN 
instead of MN constructing the NCoA from the prefix and interface ID.
NAR can be maintaining a pool of addresses from which it assigns
an address to MN through HAck, which finally will be delivered in FBAck.
May be, NAR can also ask DHCPv6 server to get an address for MN's 
NCoA.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 19:14:39 +0200

Syam Madanapalli wrote:

>>> By "assigned addressing" do you mean "stateful address
>>> configuration" via DHCPv6?
>> 
>> I was thinking it may mean "PPP for IPv6" but even in that case the
>> PPP will not actually assign an address but negotiate an Interface 
> Assigned address means NAR provides the address (NCoA) for MN instead
> of MN constructing the NCoA from the prefix and interface ID. NAR can
> be maintaining a pool of addresses from which it assigns an address
> to MN through HAck, which finally will be delivered in FBAck.

Thanks for explanation.  As I supposed, assigned addressing is a
completely new way for doing address configuration in IPv6.  I think it
is also right to say that only FMIPv6 uses assigned addressing.

> May be, NAR can also ask DHCPv6 server to get an address for MN's 

DHCPv6 has its own way of assigning addresses.  In this particular case,
AR could be a DHCP Server, or it could be a DHCP Relay, in which case
all ARs are connected to a central DHCP Server.

If DHCP Relay is used on the NAR then there is a set of standard message
exchanges that happen.

I don't think that a new protocol is needed for NAR to talk to DHCP
Server, because DHCP Relay already does that.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Aug 2005 11:45:34 -0700

> is also right to say that only FMIPv6 uses assigned addressing.

Mmm, don't think this will fly with the IESG. They were probably not so
vigilant with RFC 4068 because its experimental, but the IAB and IESG have
been trying to constrain address assignment to: 1) autoconfigured, 2) DHCP,
3) PPP (legacy basically), and 4) IKEv2.

I doubt whether they'll approve a new address assignment mechanism/protocol
when FMIP goes to PS.

            jak

---

From: Subba Reddy <[email-masked]>
Date: Fri, 12 Aug 2005 09:01:20 +0530

Hi Alex,

> the Mobile IPv6 implementation may get stuck... (?)

I also think there are some problems if packet loss occurs. For example, in
predictive
handover FNA is lost, NAR may not know that MN has connected.

Thanks & Regards,
Subba Reddy

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 12 Aug 2005 13:54:13 +0530

> is also right to say that only FMIPv6 uses assigned addressing.

I am not sure about the terminology. But we may need to take the 
literal meaning of "assigned address" meaning not constructed by the
MN, ather assigned by the NAR. This way DHCP also assigns the
addresses.

> Server, because DHCP Relay already does that.

Yeah, new protocol is not required as you said. But I think you need a
DHCPv6 client which can ask for an address on behalf of MN and pass
this address to PA in HAck. PAR then passes this address to MN in 
FBAck. And this nothing to do with the FMIPv6, it is just may be one
of many ways to implement. Also I am not sure if anybody has done this
kind of address configuration.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 11:53:53 +0200

Syam Madanapalli wrote:
>>> instead of MN constructing the NCoA from the prefix and interface
>>> ID. NAR can be maintaining a pool of addresses from which it
>>> assigns an address to MN through HAck, which finally will be
>>> delivered in FBAck.
>> 
>> completely new way for doing address configuration in IPv6.  I
>> think it is also right to say that only FMIPv6 uses assigned
>> addressing.
> 
> 

Staying vague about how the addresses are assigned is worthless.

For one, much of the motivation behind FMIP was that address
autoconfiguration may take too long.  FMIP prescisely optimizes a very
precise stateless autoconfiguration but at the same time uses a new and
very vaguely described assigned addressing.  If the assigned addressing
can be DHCP then DHCP has its own precise message exchanges, just like
the stateless autoconf has.

Second, a FMIP implementation that uses DHCP exchanges but completely
ignores these messages is probably inducing new delays in the handover,
due to the DHCP exchanges.

>> DHCPv6 has its own way of assigning addresses.  In this particular
>> case, AR could be a DHCP Server, or it could be a DHCP Relay, in
>> which case all ARs are connected to a central DHCP Server.
>> 
>> If DHCP Relay is used on the NAR then there is a set of standard
>> message exchanges that happen.
>> 
> Yeah, new protocol is not required as you said. But I think you need
> a DHCPv6 client which can ask for an address on behalf of MN and pass
> of many ways to implement.

This is too vague.  NAR doesn't need to run DHCP Client.  A DHCP Client
doesn't usually obtain an address for somebody else, it obtains it for
itself.  NAR could be a DHCP Relay.  But a Relay does not store the
addresses that are distributed, just relays them.

If one needs to obtain an address on NAR and pass it back to MN through
PAR then one would enhance DHCP to do it.  The DHCP enhancement may look
just like the Mobile IP enhancement where MN sends FBU to PAR compared
to MN sends BU to HA.

In all cases, even if my above description looks simple, having it in a
spec is a long way.  And it looks unfounded for me to have FMIP depend
on a completely unknown assigned addressing scheme.

> Also I am not sure if anybody has done this kind of address
> configuration.

Neither am I.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 08:33:27 -0700

Alex,

I agree that the bis draft needs to clarify DHCP use in FMIP. Use of
autoconfigured addresses seem much clearer.

That said, I think the problem pertains primarily if not exclusively to
predictive handover. If the handover is reactive, the MN must perform a DHCP
REQUEST prior to performing the FBU, since the MN won't know until it is
actually on the new link which link it will move to. However, I think the
DHCP CONFIRM, which would be sent out prior to the REQUEST as soon as the MN
discovered it had move to a new link, could probably be dropped if some form
of movement detection is available that gives the MN a definitive answer
that it is on the new link. This process seems clear and unambiguous to me.

            jak

----- Original Message -----
From: "Alexandru Petrescu" <[email-masked]>
To: "Syam Madanapalli" <[email-masked]>
Cc: "Alexandru Petrescu" <[email-masked]>; "James Kempf"
<[email-masked]>; "Soliman, Hesham" <[email-masked]>;
<[email-masked]>; "Koshiro MITSUYA" <[email-masked]>; "Junghoon
Jee" <[email-masked]>
Sent: Friday, August 12, 2005 2:53 AM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 12 Aug 2005 22:07:36 +0530

[cut]

> Staying vague about how the addresses are assigned is worthless.

Being clear about something is always good. I think the 'assigned 
addressing' has been left for the implementers. Probably as we get more
operational experience we could define this better. 

> due to the DHCP exchanges.

One approach is to get a pool of addresses from DHCP and keep them in the NAR.
This avoids the latency. But the problem for notifying the remaining
parameters as
mentioned in the other mails still exist.

> >>> May be, NAR can also ask DHCPv6 server to get an address for MN's
[cut]
> addresses that are distributed, just relays them.

I doubt DHCP relays can acquire addresses, you need the clients but
the difference could be in invoking the DHCP client.

> on a completely unknown assigned addressing scheme.

I doubt this will ever make into FMIP specification.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 19:32:22 +0200

James Kempf wrote:

> That said, I think the problem pertains primarily if not exclusively
> to predictive handover. If the handover is reactive, the MN must
> perform a DHCP REQUEST prior to performing the FBU, since the MN
> won't know until it is actually on the new link which link it will
> move to. However, I think the DHCP CONFIRM, which would be sent out
> prior to the REQUEST as soon as the MN discovered it had move to a
> new link, could probably be dropped if some form of movement
> detection is available that gives the MN a definitive answer that it
> is on the new link. This process seems clear and unambiguous to me.

I agree that looking into interactions with DHCP is worth exploring.
Actually much of the motivation behind FMIP work was the long DHCPv4
times when changing attachment from one AR to another (without Mobile
IP) (measurements with some implementations show 1s-10s delays).
Surprisingly though, this was used only as a motivator and since then
DHCP exchanges got completely ignored.

About how DHCP REQUEST and CONFIRM could be intertwined with fast
handover messages, which is suggested above, all I could say is that I
see first MN do RS/RA, look at M/O bits, then do DHCP or stateless.  The
CONFIRM message is sent to confirm an already assigned address, or here
the address is changing.  And I agree it could get lost too.

Then one could speculate on the need for a DNS Resolver address too,
which could come from DHCP, or from RA.  That address is needed,
especially since FMIP is concerned about loss of quality of
_applications_ during handovers, or, applications use FQDN names, not IP
addresses.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 24 Aug 2005 17:47:20 +0300

Hello folks,

Especially since the issue has been entered into the issue tracker,
I'd like to respond to this. 

>Staying vague about how the addresses are assigned is worthless.
I thoroughly disagree with this.  All that has to be specified is that the
result of the process has to be a unique address supplied in a timely 
fashion.

>> autoconfiguration may take too long.
>
That's certainly correct.

>  FMIP prescisely optimizes a very
I guess you mean because DHCP has a protocol specification document.

>> due to the DHCP exchanges.

If I were building a box to do this, and I didn't test out the performance
of my DHCP implementation, then I would be risking the success of my
product.  But this is true for every protocol in the system.  What if the IP
header processing takes too long in some poor implementation?  Do we
have to specify timing for every protocol in the system?

I hope not.

There could be value in specifying improvements for DHCP or for
DNS or for service discovery operations, but they do not belong
in FMIP, nor as normative references to other documents.  If the
new document updates FMIP, so be it.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Aug 2005 17:22:43 +0200

Charles E. Perkins wrote:
> I thoroughly disagree with this.  All that has to be specified is 
> that the result of the process has to be a unique address supplied in
>  a timely fashion.

Not only.  When a node assigns an address to its interface it also
associates lifetimes with it.  DHCP and stateless offers lifetimes.
HAck doesn't.  DHCP tells nodes how to no longer use a certain address
too.  HAck doesn't either.  When these things come up, it will be
realized that FMIP should be enhanced and probably do all that DHCP does.

Also, supplying a unique address to somebody and managing a pool of
addresses is something not obvious to do.  DHCP already does it, but it
comes with a set of messages that should be taken into account.  It's
not good to start designing a new mechanism for that.

> That's certainly correct.

Which is why DHCP had to be addressed.

>>> precise stateless autoconfiguration but at the same time uses a 
>>> new and very vaguely described assigned addressing.  If the 
>>> assigned addressing can be DHCP then DHCP has its own precise 
>>> message exchanges, just like the stateless autoconf has.
>> 
>> 
>> 

Yes, and open-source implementations.

>>> Second, a FMIP implementation that uses DHCP exchanges but 
>>> completely ignores these messages is probably inducing new delays
>>>  in the handover, due to the DHCP exchanges.
>> 
>> 
> 
> If I were building a box to do this, and I didn't test out the 
> performance of my DHCP implementation, then I would be risking the 
> success of my product.  But this is true for every protocol in the 
> system.  What if the IP header processing takes too long in some poor
>  implementation?  Do we have to specify timing for every protocol in 
> the system?
> 
> I hope not.

Somehow agree.  But, here IP header processing is actually computing
cycles.  With DHCP I'm not referring to computing cycles the Server
takes to find a new address.  I'm referring to exactly 4 messages being
exchanged and that take time and that are completely overlooked.  For
handovers, there are 6 DHCP messages.

Why do people strive to take into account all RS/RA, DAD, BU/BAck, RR
but completely overlook the fact that assigning an address by a router
is DHCP and that has 4 messages (initial) and 6 messages for handovers.

If we can overlook DHCP why don't we overlook DAD too.

> There could be value in specifying improvements for DHCP or for DNS 
> or for service discovery operations, but they do not belong in FMIP, 
> nor as normative references to other documents.  If the new document 
> updates FMIP, so be it.

That looks like a possible alternative, although I don't share it
entirely.  It still looks to me unfeasible for FMIP to define a new way
to distribute addresses to nodes that assign them on interfaces.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Aug 2005 18:25:53 +0300

Hello Alexandru,

More discussion...

Alexandru Petrescu wrote:

>>         .........          All that has to be specified is 
>HAck doesn't.
This is a good point.  One potential solution is for the mobile node to
hear a router advertisement eventually, and for NAR to agree that the
lifetime of the new care-of address is longer than the period between
local router advertisements.  When the mobile node hears the local
advertisement, then it ought to know what to do.

>  DHCP tells nodes how to no longer use a certain address
>too.  HAck doesn't either.
>
I didn't understand this.

>  When these things come up, it will be
I definitely hope not.  If DHCP services are needed, why not let the
mobile node contact DHCP at the new access network?

>addresses is something not obvious to do.
>
There is room for innovation here.

>  DHCP already does it, but it
I think the immedate problems faced by a mobile device are simpler than 
those
that have been solved by DHCP, and the device should contact DHCP as soon
as it needs to start configuring the additional information

>Which is why DHCP had to be addressed.
Either I don't get your point, or I don't why it follows that
doing something about DHCP is part of FMIPv6.

>Yes, and open-source implementations.
Does it mean that if all implementations were not open-source,
there would be normative impact on the protocol specification?
This would indeed be a new world order.

>takes to find a new address.
>
 From the black box point of view, we can't make the distinction.
What if the signaling is across the system bus to the DHCP code
module on the other side of the access router circuit boards?
Or what if someone builds their proprietary stateless solution
with arbitrary mechanisms?

>is DHCP and that has 4 messages (initial) and 6 messages for handovers.
I'd rather think that the devices in question have to have certain
addressability for the system to work at all.  In order to make
things work fast, we should specify the minimum amount of local
mechanism and signaling to support connectivity to the local
subnet.

>If we can overlook DHCP why don't we overlook DAD too.
DAD is local and DHCP isn't, for one thing.

Or, if you want to say it another way, if a network administrator
requires that the DHCP server mediate the local connectivity
because NAR and PAR cannot be trusted to do so, then that
network administrator is going to need some additional IETF
specifications that haven't been written yet.  But presumably not
all network administrators are quite so power-intensive as that..

And, finally, NAR can always refuse, in order to serve the needs
of the network administrators who can't even let go for 200ms.

>to distribute addresses to nodes that assign them on interfaces.
I didn't see this as a new definition, but the same old same old applied in
a way to enable good performance.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Aug 2005 17:46:29 +0200

Hello Charlie,

Charles E. Perkins wrote:
>>> .........          All that has to be specified is that the 
>>> result of the process has to be a unique address supplied in a 
>>> timely fashion.
>>> 
>> 
>> 
>>  associates lifetimes with it.  DHCP and stateless offers
>> lifetimes. HAck doesn't.
>> 
> This is a good point.  One potential solution is for the mobile node 
> to hear a router advertisement eventually, and for NAR to agree that 
> the lifetime of the new care-of address is longer than the period 
> between local router advertisements.  When the mobile node hears the 
> local advertisement, then it ought to know what to do.

Right, sounds possible.

>> DHCP tells nodes how to no longer use a certain address too.  HAck 
>> doesn't either.
>> 

I was trying to say that if HI/HAck are used for assigning addresses
then they should also be used for deleting addresses, for symmetricity
reasons.  With DHCP, there's DHCPNACK that makes a node no longer use
that address.

>> When these things come up, it will be realized that FMIP should be 
>> enhanced and probably do all that DHCP does.
>> 
>> 

We turn in rounds...

> There is room for innovation here.

I'd rather reuse instead of innovate.

> Either I don't get your point, or I don't why it follows that doing 
> something about DHCP is part of FMIPv6.

To my mind it is simple.  Take a laptop, see why the handover is slow
and correct that something.  If it was DHCP that was slow then quicken
DHCP.  That's why I was thinking it follows.

FMIPv6 is already doing something about DHCP, called "assigned
addressing - addresses are assigned by a router".  All I am asking is to
acknowledge that addresses assigned by a router is actually DHCP.

But this may be a terminology issue.

> Does it mean that if all implementations were not open-source, there 
> would be normative impact on the protocol specification? This would 
> indeed be a new world order.

Right, I was not aiming at that new world order.

I was thinking that in order to design a FMIPv6 protocol based on
inter-operability at least two implemetors should have means and
motivation to interoperate.  That's often easy when open-source software
is available but does not preclude proprietary source.

>>> performance of my DHCP implementation, then I would be risking 
>>> the success of my product.  But this is true for every protocol 
>>> in the system.  What if the IP header processing takes too long 
>>> in some poor implementation?  Do we have to specify timing for 
>>> every protocol in the system?
>>> 
>>> I hope not.
>>> 
>> 
>> 
>> Somehow agree.  But, here IP header processing is actually 
>> computing cycles.  With DHCP I'm not referring to computing cycles 
>> the Server takes to find a new address.
>> 
> From the black box point of view, we can't make the distinction. What
>  if the signaling is across the system bus to the DHCP code module on
>  the other side of the access router circuit boards?

IP-over-Infiniband?

> Or what if someone builds their proprietary stateless solution with
> arbitrary mechanisms?
> 
>> Why do people strive to take into account all RS/RA, DAD, BU/BAck, 
>> RR but completely overlook the fact that assigning an address by a 
>> router is DHCP and that has 4 messages (initial) and 6 messages for
>>  handovers.
>> 
>> 
> mechanism and signaling to support connectivity to the local subnet.

Which leads to think that maybe it's the configuration of link-local
addresses that should be optimized.

> requires that the DHCP server mediate the local connectivity because 
> NAR and PAR cannot be trusted to do so, then that network 
> administrator is going to need some additional IETF specifications 
> that haven't been written yet.  But presumably not all network 
> administrators are quite so power-intensive as that..
> 
> And, finally, NAR can always refuse, in order to serve the needs of 
> the network administrators who can't even let go for 200ms.
> 
>> 
>> 
>> entirely.  It still looks to me unfeasible for FMIP to define a new
>>  way to distribute addresses to nodes that assign them on 
>> interfaces.
>> 
>> 
> I didn't see this as a new definition, but the same old same old 
> applied in a way to enable good performance.

The quest for good performance is certainly motivated, but implementing
it meaningfully is most rewarding.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Aug 2005 20:23:02 +0300

Hello Alexandru,

I think we're just about done here...

>reasons.  With DHCP, there's DHCPNACK that makes a node no longer use
Fast handover is not a symmetric problem.  There's no obvious function
that requires deleting addresses.  In cases where PAR wants to reclaim
addresses, it could do so (say) at the end of the tunnel lifetime.

>> mobile node contact DHCP at the new access network?
Sorry, I don't get your point here.

>I'd rather reuse instead of innovate.
But you are claiming there is nothing you can re-use.

>DHCP.  That's why I was thinking it follows.
It's clear to me that your strategy is correct.  But it doesn't mean that
new gluons need to increase the mass of  the FMIPv6 specification.

>acknowledge that addresses assigned by a router is actually DHCP.
I would not acknowledge that.  I'd like to keep room for proprietary
system solutions.

>>Or what if someone builds their proprietary stateless solution with
Here, I meant to say "stateful", sorry...

>addresses that should be optimized.
Tunneling to link-local addresses is a can of worms that is comparable in
size to the whole darned FMIPv6 specification.  Let's not go there.

>it meaningfully is most rewarding.
And to all a meaningful life.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Aug 2005 19:55:37 +0200

Hello Charlie, yes we may just about to be done, I think I've made my
points, thanks for having replied.

Charles E. Perkins wrote:
>> I was trying to say that if HI/HAck are used for assigning
>> addresses then they should also be used for deleting addresses, for
>> symmetricity reasons.  With DHCP, there's DHCPNACK that makes a
>> node no longer use that address.
>> 
>> 
> Fast handover is not a symmetric problem.  There's no obvious
> function that requires deleting addresses.

"Symmetricity" - like when there's BU there's a BAck - is always easy to
understand.

FMIPv6 seems to prefer over-writing.  MN decides to use an address but
HAck may over-write that decision by allocating a different address.  If
nCoA lifetime is incorrect then the true lifetimes in true RA will
over-write them.

But I agree that deleting an address (nCoA) of an MN that is moving is
not required.

> In cases where PAR wants to reclaim addresses, it could do so (say)
> at the end of the tunnel lifetime.

Yes, it could.

I was talking about the nCoA that NAR has sent to PAR (in HAck) that MN
is supposed to use.  I was thinking that if NAR instructs MN to use a
certain address it should have a means to instruct it to no longer use
that address.

>>> I definitely hope not.  If DHCP services are needed, why not let
>>> the mobile node contact DHCP at the new access network?
>>> 
>> 
>> 
>> We turn in rounds...
>> 
>> 

Sorry, I agree that if DHCP services are needed then the MN should
contact DHCP at the new access network.  But care that the address DHCP
is giving MN is exactly the same as the address HAck gave it.

>>>> Also, supplying a unique address to somebody and managing a
>>>> pool of addresses is something not obvious to do.
>>>> 
>>>> 
>>> 

I'm not.  One can reuse DHCP for address assignment, in theory.

>> To my mind it is simple.  Take a laptop, see why the handover is
>> slow and correct that something.  If it was DHCP that was slow then
>> quicken DHCP.  That's why I was thinking it follows.
>> 
>> 
> It's clear to me that your strategy is correct.  But it doesn't mean
> that new gluons need to increase the mass of  the FMIPv6
> specification.

I'd rather use anti-gluons for the FMIPv6 spec, so it becomes clearer,
shorter.

I am not proposing adding DHCP messaging into the FMIPv6 spec.

I am proposing to evaluate in practice, with an application, when Mobile
IPv6 handovers are slow and why.  This is very important in order to be
able to evaluate how the FMIPv6 implementation is better than not using it.

>> addressing - addresses are assigned by a router".  All I am asking
>> is to acknowledge that addresses assigned by a router is actually
>> DHCP.
>> 
>> 

I am confused about how proprietary DHCP system solutions would fit into
FMIP right here... but it is not important.

> Here, I meant to say "stateful", sorry...

I see, but I doubt being proprietary still allows one to assume that
HAck by AR will be able to distribute addresses, since we don't know
exactly what that proprietary solution is and is not.

>>> I'd rather think that the devices in question have to have
>>> certain addressability for the system to work at all.  In order
>>> to make things work fast, we should specify the minimum amount of
>>> local mechanism and signaling to support connectivity to the
>>> local subnet.
>>> 
>> 
>> 
>> Which leads to think that maybe it's the configuration of
>> link-local addresses that should be optimized.
>> 
>> 
> Tunneling to link-local addresses is a can of worms that is
> comparable in size to the whole darned FMIPv6 specification.  Let's
> not go there.

Right, I overlooked tunnels were needed.

>> The quest for good performance is certainly motivated, but
>> implementing it meaningfully is most rewarding.
>> 
>> 
> Regards, Charlie P.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 11:00:07 -0700

> addresses that should be optimized.

This is a key point. The link local address will never be assigned by DHCP, 
it will always be autoconfigured.

            jak