Subject: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2003 20:21:05 +0100

<[email-masked]> writes:
> 	Title		: Mobile IPv4 Dynamic Home Agent Assignment Framework
> 	Author(s)	: M. Kulkarni, A. Patel, K. Leung
> 	Filename	: draft-kulkarni-mobileip-dynamic-assignment-02.txt
> 	Pages		: 21
> 	Date		: 2003-10-17

Hi to MIP4 members, I've read this draft because it relates to a
similar draft for Mobile IPv6 with which I got familiar weeks ago.

I was wondering if I can get IPv4-specific clarification for the
motivation behind this idea.

Once an MN is assigned a new HA (by the previous HA), is the new HA
capable of receiving packets originated by CN and addressed to the
same unique Home Address?  Does the MN keep its old Home Address?

>        If the distance between the visited network and the home
>        network of the mobile node is large, the signaling delay for
>        these registrations may be long.

Is the high delay of the _registration_ signalling (not the delay
CN-MN useful comm) of enough high importance as to motivate choosing a
new HA?

>        In such a case the MN will be anchored to its distant home
>        agent, resulting in tunneled traffic traveling a long
>        distance between home agent and the mobile node.

This sounds to me like a typical route optimization problem.  I think
I remember about a RO draft existed some time (1 year?) ago but I
don't know about its status.  Is the RO work taken somewhere?

>       When a Mobile IP session initiates, if the mobile node can be
>       assigned an home agent which is close to the mobile node it
>       can drastically reduce the latency between the home agent and
>       mobile node.

Yes, that looks reasonable.  But remark that it is not the
communication between MN and its HA that is of paramount importance.
It is the useful app-level communication of MN that takes the most
bandwidth and other network resources.  In this case, it is very
important to reduce MN-to-CN distances (instead of only the MN-to-HA
distances), no?

Thanks for any clarification,

Alex
GBU

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 07 Nov 2003 14:03:07 -0800

Alex,

Thanks for your feedback on the dynamic HA assignment
draft. Please see inline...

> motivation behind this idea.

There are atleast 4 motivating reasons for dynamic HA assignment.
They are listed in section 3 of the draft.

> same unique Home Address?  

Since the draft suggests RRQ rejection as the mechanism for
redirecting, the new HA has all the capabilities and that
includes sending packets to MN.

 >Does the MN keep its old Home Address?

I presume you are saying MN's home IP address. The MN may or
may not keep its old IP address because it uses NAI.

> important to reduce MN-to-CN distances (instead of only the MN-to-HA

True. But MN-CN proximity is automatically taken care of when the
HA and MN are very close. If the MN and CN are close, but the HA
is far away then the problem still remains. And we don't have
intelligent CN like MIP v6 here. We sincerely believe, each reason
above put together offers compelling argument.

Regards,
Milind

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2003 23:37:24 +0100

> They are listed in section 3 of the draft.

Ok I read and not convinced.  Do you think it would be a good if I
address them one by one?

>        Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept
>        of identifying a MN by the NAI and enabling dynamic home
>        address assignment.

Remark that when HA assigns a new Home Address to MN (based on NAI),
this address is obviously topologically correct at HA.  That HA can
not assign an address to MN that is topologically correct at another
HA far away, no?

> includes sending packets to MN.

I understand that, but what I was not asking about HA _sending_
packets to MN, but about the new HA _receiving_ packets from CN
addressed towards the Home Address valid at the old HA.

> may not keep its old IP address because it uses NAI.

Yes, I'm assuming MN keeps its home IP address.  I assume that CN
sends to that MN by sending to the home IP address (and not to the
NAI).

So I was wondering whether when a new HA is assigned to MN, MN keeps
the same home IP address and CN continues to send to that home IP
address?

> is far away then the problem still remains.

I understand the surface of this problem.  The solution you propose
has appeal in that a new HA is assigned that is closer to MN (in terms
of no of IP hops).  But I don't understand how this new HA can obtain
the packets addressed by CN to the home IP address that is
topologically valid only at the old HA.

> And we don't have intelligent CN like MIP v6 here.

I see, so that's why I can't find a draft on RO for MIPv4, maybe?

> We sincerely believe, each reason above put together offers
> compelling argument.

I sincerely believe that it depends who you ask.  If you ask me, I'd
be ready to be compelled, but I need to figure out this new HA
assignment.

Alex
GBU

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 07 Nov 2003 15:19:28 -0800

Alex,

Thanks for your responses. I glanced through NACP draft.
Now I understand the view point you are coming from. The
NACP draft is a different solution altogether. It is
assisting in MN's handoff strategy.

The dynamic HA assignment draft is solving different problem.
It enhances the RFC-3344 behavior to get the optimal HA
during session initiation only. Once selected, the MN is
anchored to that HA for entire session.

BTW, in which WG the NACP draft is tabled?

Thanks,
Milind

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 08 Nov 2003 01:13:25 +0100

Milind Kulkarni wrote:
> Alex,
> 
> Thanks for your responses. I glanced through NACP draft. Now I 
> understand the view point you are coming from. The NACP draft is a 
> different solution altogether. It is assisting in MN's handoff 
> strategy.

Absolutely, NACP is assisting in MN's handoff strategy.  There is no
relation between the two whatsoever.  I was reviewing your draft at the
same time as announcing NACP here, but no relations.

But my interest in the HA selection/assignment scheme comes from the
similarity between HAHA discussed in MIP6 and draft-kulkarni (nothing to
do with NACP).

> The dynamic HA assignment draft is solving different problem.

Absolutely, sorry for the confusion.

> It enhances the RFC-3344 behavior to get the optimal HA during 
> session initiation only. Once selected, the MN is anchored to that HA
>  for entire session.

A-ha, so would it be reasonable to say that, with draft-kulkarni,
upper-layer apps between MN-CN MUST be restarted each time a new HA is
assigned? (thus loosing the classical advantage of Mobile IP that it
preserves ongoing communications when address changes)?  I assume that
when a new HA is assigned, a new Home Address is assigned to MN too,
even if NAI appears in the discussion.  NAI is used by a normal HA to
assign and re-assign the same Home Address to an MN, but it is always
the same HA.

If this session continuity advantage of Mobile IP is lost, is it
reasonable to say that an MN could simply acquire a new address from the
new DHCP server that it finds nearby, use that address for currrent
sessions, then move, break communications, find another DHCP server,
aquire a new address and so on?

Otherwise, if the MN anchored to a new HA tries to continue using the
same Home Address (valid at the old HA), then the new HA MUST absolutely
have a means to get packets from CN towards that home address.  I can
not find something in draft-kulkarni that clarifies this.

> BTW, in which WG the NACP draft is tabled?

As you can see, we have announced NACP in this WG.  It is an individual
submission, just like yours.

Alex
GBU

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 07 Nov 2003 16:37:04 -0800

> Absolutely, sorry for the confusion.

Ok.

>> It enhances the RFC-3344 behavior to get the optimal HA during session 
>> initiation only. Once selected, the MN is anchored to that HA
>>  for entire session.
> 
> 
> preserves ongoing communications when address changes)?  

No, no! The messaging specified in the draft-kulkarni-xxx is done
only at the beginning of a new MIP v4 session. So this is a
*new* MIP session, which gets an optimal HA. The MN stays
anchored to the optimal HA for the rest of the MIP session.
After that everything is RFC3344. The MN's IP address remains
same and upper layer applications remain intact. Breaking upper
layer sessions (and restarting applications) is definitely out
of question :)

The whole process repeats when the MIP session is restarted.
I hope this is clear now.

Milind

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Jan 1980 02:02:42 +0100

Milind Kulkarni wrote:
> only at the beginning of a new MIP v4 session. So this is a *new* MIP
>  session, which gets an optimal HA. The MN stays anchored to the 
> optimal HA for the rest of the MIP session. After that everything is
>  RFC3344. The MN's IP address remains same and upper layer 
> applications remain intact.

Ah, I think I start to get it.  So this would be a scenario like:
MN arrives in a new area (all sessions down), contacts its original
non-optimal HA, that non-optimal HA redirects towards this optimal HA
and, starting from now, rfc3344 goes on and MN can visit various foreign
networks close to this new HA.  Packets from CN would be addressed to
the Home Address valid at this new HA and forwarded to the current CoA,
and all communications are not interupted.

> Breaking upper layer sessions (and restarting applications) is 
> definitely out of question :)

...until MN moves into an area where another HA is optimal, right?

Am I right to say that re-assigning a second new optimal HA implies
however re-contacting the original HA, and a second new redirection, and
thus restarting applications?

I mean I agree that the first 0th re-direction from the original genuine
HA towards the first optimal HA might work ok for applications started
_after_ that redirection, but a second re-direction towards a second
optimal HA might not work, right?

This is something like: MN arrives somewhere, contacts its HA, its HA
says 'no, use this optimal HA near you' and then MN uses the optimal HA
nearby, that optimal HA assigns MN a Home Address and MN can wander
around with this Home Address, but don't go too far otherwise another HA
becomes optimal and applications need to be restarted.

This sounds very much like being solvable with HA discovery, but the
draft discards it as being a security leak (CERT advisory something).

It is also clearly stated in section 3.1 on Scope that the entire HA
assignment scheme can only work inside the same administrative domain.
Or, this again goes against my comprehension of Mobile IP original
applicability statements, being designed to work across administrative
domain boundaries (rfc2005).

If one considers that only the HA's are required to be _inside_ a
certain admin domain and the CN's can be outside, then, in order for
this draft to bring any benefits with respect to any CN (the claimed
optimal closeness) implies that this HA administrative domain MUST be
close to all CN's in the Internet and such a domain does not exist.

Otherwise, this entire HA assignment solution reduces to placing a CN
inside the HA mobility domain, and thus it is a closed system design,
and, again, designing closed systems is probably not very inline with
the original goals of Mobile IP to work across the entire Internet.

Overall, I feel that this draft involves reducing and eliminating two
key aspects of Mobile IP: work across Internet and maintain ongoing
applications.  At the cost of this, it brings in a minimal re-direction
advantage that avoids a CERT issue raised in 1998.

What do you think?

Alex
GBU

---

From: Alpesh <[email-masked]>
Date: Fri, 07 Nov 2003 21:53:23 -0800

Alexandru -

As Milind has mentioned, draft-kulkarni addresses the
problem of optimal anchoring at the beginning of the
mobile IP session.

On subsequent moves, the MN is NOT anchored (or reanchored
at a different HA) - this aspect is clearly outside the
scope and is clearly mentioned.

 From one of your previous emails, RO was considered in the mobileip
working group quite some time ago and from what I understand, that
work has been abandoned (chairs can comment more about this).

I will be at IETF in Minneapolis and if you are still not
clear about the problem or scope of the draft, we can talk about
this.

-a

Alexandru Petrescu wrote:
>> different solution altogether. It is assisting in MN's handoff strategy.
> 
>

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 07 Nov 2003 22:12:51 -0800

Please see inline...

Alexandru Petrescu wrote:
> Milind Kulkarni wrote:
> 
>> No, no! The messaging specified in the draft-kulkarni-xxx is done only 
>> at the beginning of a new MIP v4 session. So this is a *new* MIP

Correct..

> ...until MN moves into an area where another HA is optimal, right?

If it is the ongoing mobile IP session, MN would continue using it's
assigned HA.

> thus restarting applications?

No. The reassignment will not take place until next new MIP session.

Looks like we going in circles ;) If you are going to IETF meeting
next week, Alpesh Patel will be there and he will explain the
proposal. You may want to read the draft in detail.

Thanks,
Milind

---

From: Alpesh <[email-masked]>
Date: Fri, 07 Nov 2003 22:19:56 -0800

Alexandru -

Please see inline under ALPS>>

BTW, something is wrong with the timestamp on this email
that you sent.

> and all communications are not interupted.

ALPS>> It is also possible that MN did not have a "cached" old-HA
address (from a previous MIP session). Thus, it could start with
All-zero-one-address (AZOA) as mentioned in the draft.

> ...until MN moves into an area where another HA is optimal, right?

ALPS>> Once the MN is anchored, as long as the MIP session is in
progress, we don't reanchor. This is clearly outside the scope of
our draft (and mentioned in the draft).

> thus restarting applications?

ALPS>> No - we don't re-assign MN to a new optimal HA.

> optimal HA might not work, right?

ALPS>> No - as we have mentioned, the dynamic assignment occurs only
when MIP session is established.

> becomes optimal and applications need to be restarted.

ALPS>> We are clearly not addressing the same issue. There is no
reanchoring/redirection once MN is anchored. Once anchored, it is
RFC3344, until MN re-initiates MIP session. Thus, our dynamic HA
assignment mechanism kicks-in when the MIP session "starts".

> draft discards it as being a security leak (CERT advisory something).

ALPS>> HA discovery as per 3344 won't work. I would kindly refer
you to the description in the draft and the CERT advisory.

> domain boundaries (rfc2005).

ALPS>> "single administrative domain" means that MN and HA belong
to the same domain. MN can roam to any domain and register to its HA
from where it is currently roaming. MN and HA being in separate domains
is outside the scope of the draft.

> close to all CN's in the Internet and such a domain does not exist.

ALPS>> Well one of the problem statements is the MN/HA proximity (among
others as Milind pointed out). MN/CN or HA/CN proximity is not an issue
that we address in this draft. That problem you mention was part of the
RO draft, but I think it is not a WG item any longer. This draft does 
not suggest/mandate any specific network design WRT HA/CN location.

> the original goals of Mobile IP to work across the entire Internet.

ALPS>> I think we are not in sync. with the problem we are describing.
CN can reside anywhere in the Internet - no reference to this.

> advantage that avoids a CERT issue raised in 1998.

ALPS>> I respectfully disagree. None of the basic assumptions/purposes 
of Mobile IP are broken/violated. The advantages/problem statement is
addressed in section 3 of the draft.

> What do you think?

ALPS>> I think a face to face meeting may help to solve this confusion. 
I would recommend that you read the draft in detail to appreciate the 
problem statement/applicability.

ALPS>> I will be at Minneapolis and am more than willing to talk with 
you/anyone about this. (Will post the summary statement to this thread
to close the loop).

Alpesh

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Jan 1980 14:48:23 +0100

Alpesh wrote:
> progress, we don't reanchor. This is clearly outside the scope of our
>  draft (and mentioned in the draft).

Exactly, so the redirection and assignment of HA happens only at the
beginning of the MIP session and the goal of the draft is not to allow
MN to hop between HA's.

>> I mean I agree that the first 0th re-direction from the original 
>> genuine HA towards the first optimal HA might work ok for 
>> applications started _after_ that redirection, but a second 
>> re-direction towards a second optimal HA might not work, right?
> 

Ok.

>> This is something like: MN arrives somewhere, contacts its HA, its
>>  HA says 'no, use this optimal HA near you' and then MN uses the 
>> optimal HA nearby, that optimal HA assigns MN a Home Address and MN
>>  can wander around with this Home Address, but don't go too far 
>> otherwise another HA becomes optimal and applications need to be 
>> restarted.
> 
> 

Ok, the reassignment is a one time operation.

>> This sounds very much like being solvable with HA discovery, but 
>> the draft discards it as being a security leak (CERT advisory 
>> something).
> 
> 
> ALPS>> HA discovery as per 3344 won't work. I would kindly refer you
>  to the description in the draft and the CERT advisory.

Allright.

I would kindly ask you to describe what is the particular scenario
happening in the real world that needs this kind of HA redirection at
MIP session startup.  I've tried to interpolate one, based on
private-public information.

For example, a private secret set of slides posted to all the NEMO WG
members only, discussed HA re-assignment when a plane travels to a new
continent.  With your solution, the plane arrives over a new continent,
coming from his home continent, starts a MIP session, the HA from the
home continent redirects to the new HA and communications start.

The problem with this scenario is that when the plane does the return
flight, it MUST start a new MIP session in order to get attached to the
old HA of the old continent.

The entire plane scenario has something missing with respect to HA
placing and your solution does not seem to solve that problem.  Your
solution clearly works only for a first HA reassignment to an optimal
HA; once anchored, the MN MUST stay anchored.  If it wants to come back
to its initial home, it MUST re-start applications.

>> It is also clearly stated in section 3.1 on Scope that the entire 
>> HA assignment scheme can only work inside the same administrative 
>> domain. Or, this again goes against my comprehension of Mobile IP 
>> original applicability statements, being designed to work across 
>> administrative domain boundaries (rfc2005).
> 
> 
> ALPS>> "single administrative domain" means that MN and HA belong to
>  the same domain. MN can roam to any domain and register to its HA 
> from where it is currently roaming. MN and HA being in separate 
> domains is outside the scope of the draft.

Exactly.  And with this above paragraph the draft goes further into
believing that the domain holding the HA's can be close to any domain
where MN may roam.  Or, the MN may roam across the entire Internet, thus
the draft seems to place HA's in a single admin domain that is present
across the entire Internet.

> ALPS>> Well one of the problem statements is the MN/HA proximity 
> (among others as Milind pointed out). MN/CN or HA/CN proximity is not
>  an issue that we address in this draft. That problem you mention was
>  part of the RO draft, but I think it is not a WG item any longer. 
> This draft does not suggest/mandate any specific network design WRT 
> HA/CN location.

This draft mandates the placement of all HA's inside a single admin
domain, right?  This is the whole issue, it qualifies the problem of
MN-HA distances inside this domain as more important than the problem of
CN-MN distances across the entire Internet.

>> Otherwise, this entire HA assignment solution reduces to placing a
>>  CN inside the HA mobility domain, and thus it is a closed system 
>> design, and, again, designing closed systems is probably not very 
>> inline with the original goals of Mobile IP to work across the 
>> entire Internet.
> 
> 
> ALPS>> I think we are not in sync. with the problem we are 
> describing. CN can reside anywhere in the Internet - no reference to
>  this.

Look, imagine that plane talks to a CN that is close to the original HA.
  Now plane arrives at new HA, gets anchored to this new HA and starts
again talking to the CN that is close to the home HA.

Using this draft clearly involves loosing benefits, because the CN is
not placed near the new HA, but near the old HA.

>> Overall, I feel that this draft involves reducing and eliminating 
>> two key aspects of Mobile IP: work across Internet and maintain 
>> ongoing applications.  At the cost of this, it brings in a minimal
>>  re-direction advantage that avoids a CERT issue raised in 1998.
> 
> ALPS>> I respectfully disagree. None of the basic 
> assumptions/purposes of Mobile IP are broken/violated. The 
> advantages/problem statement is addressed in section 3 of the draft.

Sure, I wouldn't have expected you to agree :-)  So I respectfully
disagree too.

> ALPS>> I think a face to face meeting may help to solve this 
> confusion. I would recommend that you read the draft in detail to 
> appreciate the problem statement/applicability.

I would recommend that an external reviewer (not the authors) give their
impression about the draft and thus help find out whether there is
interest in this particular draft.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Jan 1980 14:51:03 +0100

> scope and is clearly mentioned.

Ok, this is a good scope.

Just to say that the benefits of this method are lost when the MN tries 
to move back closer to the initial HA.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Jan 1980 15:40:21 +0100

> proposal. You may want to read the draft in detail.

Thanks for the recommendation.  I'm not going to next IETF meeting but
if you go, Hong-Yon Lach (co-author of NACP) will be there so maybe he
will assist at the explanation.

Alex
GBU

---

From: Kent Leung <[email-masked]>
Date: Mon, 10 Nov 2003 09:29:13 -0800

Hi Alex.  Just couple of comments.

>Absolutely, sorry for the confusion.

1) The 2 drafts address different problems and propose different solutions.
     There is no need to tie them together, IMHO.

>aquire a new address and so on?

2) The dynamic HA assignment draft provides the mechanism to anchor
     the session initially (based on optimal path or administrative policy).
     The HA maintains that session until MN decides to re-anchor (possibly
     after restart/dormant mode transition/MN policy).

Kent

---

From: William D Ivancic <[email-masked]>
Date: Wed, 12 Nov 2003 21:47:15 -0500

Hello Alex,  MIP4 and nemo:

Regarding dynamic HA assignments in IPv4 
(draft-kulkarni-mobileip-dynamic-assignment-02.txt) and nemo/IPv6 
(draft-wakikawa-mip6-nemo-haha-00).  I find some similarities and find 
these concepts very useful.  I have had to opportunity to work with the 
dynamic HA in IPv4.  Some of the potential architectures that can take 
advantage of the tools provided by these proposed protocols are documented 
in a paper entitled "Use of Mobile-IP Priority Home Agents for Aeronautics, 
Space Operations and Military Applications."   The draft paper is available 
at the following URL:

http://roland.grc.nasa.gov/~ivancic/papers_presentations/PID1317.pdf

Will