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

[subrata goswami <sgoswami at umich.edu>]

please see in line for any answers.

Jee J.Z. wrote:

> 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."?
>
>  
no,  packets would be routed to subnet X2 as a result of translation
in the sender.

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

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

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

> 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?
>  
thanks for your comments - will address these issues in the next revision.

> Jee
>
> ----- Original Message ----- 
> From: "subrata goswami" <sgoswami at umich.edu>
> To: <mip4 at ietf.org>
> 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: Mip4 at ietf.org
> >    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: Mip4 at ietf.org
   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/