Subject: Re: [Mip4] New ID: End Node based IP Mobility

From: "Jee J.Z." <[email-masked]>
Date: Tue, 22 Mar 2005 13:29:30 -0000

Hi Subrata,

Thank you for writing this concise ID. I have a few question:

1. Section 2: "...The CN would still use ipx1 as destination address for all
outgoing packets, which would result in all packets sent to subnet X2..."
Are you trying to say "...all packets sent to subnet X1."?

2. It seems you are trying to use only end nodes to support mobility. And as
you have pointed out, how subnet changes are detected is beyond the scope of
this document. However, IMHO, it is hard to quickly detect subnet changes
quickly without the network assistance. Also, how does the access network
know it should offer service to the MN without any securtiy entities in the
network for supporting mobility?

3. It seems you are considering the case that the MN can only communicate
with one access subnet at a time. Therefore, the CN receiving Subnet Change
Challenge responses from both old and new subnets could be viewed as
spoofing. What if the MN can simultaneously communicate with both new and
old access subnets at least during handovers? Are you assuming the MN always
sends only one Subnet Change Challenge response in this case?

4. Without the network assistance, how do you suppose to handle those
mis-routed packets to the old subnet after the MN connects to the new
subnet?

The ID looks like a simple interesting idea, but it seems a lot of issues
are waiting to be considered. Maybe you think it could be too earlly?

Jee

----- Original Message ----- 
From: "subrata goswami" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 10, 2005 7:39 PM
Subject: [Mip4] New ID: End Node based IP Mobility

> A new Internet Draft is available on mobility support in IP networks.
>
> Title: IPv4 Mobility through Peer Signaling
>
> ID: draft-goswami-mip4-peer-signaling-00.txt
>
> Abstract:  This document describes a way to perform mobility in IPv4
> (potentially IPv6) without requiring any new entity in networks
> infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using
> infrastructure entities this method delegates all the mobility function
> to the end nodes. The method relies on source and destination address
> translation at the end nodes, and signaling between end nodes to perform
> hand offs - all these function can be encapsulated in an entity called
> Mobility Agent (MA) in the end nodes.
>
> URL:
> https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788
>
>
> -- 
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: subrata goswami <[email-masked]>
Date: Tue, 22 Mar 2005 10:11:02 -0800

please see in line for any answers.

>Are you trying to say "...all packets sent to subnet X1."?
no,  packets would be routed to subnet X2 as a result of translation
in the sender.

>network for supporting mobility?
many different approaches have been suggested for detecting network
change, any of these methods can be used.
agreed that some these methods are very slow.

as mobility is entirely handled by  the end nodes, the network does not
really need to get involve (i.e. regular routing
handles all packets).

>sends only one Subnet Change Challenge response in this case?
there is not really any reason why the MN needs to be connected to only
one subnet.   i do not think there is any
reason why the MN can not talk to both old and new , although at the
point the draft does not address that.

>mis-routed packets to the old subnet after the MN connects to the new
this can be handled by buffering packets at the sender - will be added
in the next version of the draft.
buffering is not required if only TCP type of traffic is supported.

>are waiting to be considered. Maybe you think it could be too earlly?
thanks for your comments - will address these issues in the next revision.

---

From: "Jee J.Z." <[email-masked]>
Date: Tue, 22 Mar 2005 19:56:12 -0000

Hi Sibrata,

> no,  packets would be routed to subnet X2 as a result of translation

OK. 

> agreed that some these methods are very slow.

OK. So IMO this method would inherently induces larger disruption caused by subnet changes than Mobile IP.

> point the draft does not address that.

Alright. I think it would be good to specify that the MN must only return one Subnet Change Challenge response (sent from the new subnet).
 
> in the next version of the draft.

How does the sender know when to start buffering? It never knows the MN's subnet change until the MN tells it. And the long time needed for subnet change detection could lead to a large number of data to be misrouted, before the sender is aware of that. If the sender always buffers a number of sent packets, it still does not know which packet is lost and which is not.

Thank you for your answers. And look forward to your next revision.

Jee

> >>https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788

Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 2005-1-10
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/