RE: [nemo] new draft

[Mazen TLAIS <[e-mail]>]

 --- "Pascal Thubert (pthubert)" <[e-mail]>
a écrit : 
> Hi Mazen:
> 
> I believe that it is pretty natural for a Mobile
> Router to own more than
> one egress interface. Typically today, you'll find
> MRs with a modem and
> a 802.11 interfaces.
> 
> It is also expected that you'll find some
> proprietary logic for a MR to
> select its interface and its AR over that interface.
> Sometimes, it's as
> obvious as: .11 is fast and free, modem is slow and
> expensive... guess
> what, modem has a lower priority then WIFI.
> 
> On the other hand, potential ARs may be on a same
> (or same type of)
> egress interface, but they might provide uneven
> services (nesting level,
> security, bandwidth). I would really like to see a
> draft that examines
> that problem and makes recommendations on how MRs
> should behave, what
> should be customizable in the AR selection, etc...
> if you're interested
> :)
> 
> For current implementations or trials, a set of
> tools are available:
> 
> RFC 2461: RA is the base tool for all. Proves to be
> a little slow for
> mobility
> 
> RFC 3775: improves ND making RA faster and more
> verbose.
> 
> DNA: should go further in NUD but still, the AR is
> the horizon.  
> 
> draft-ietf-ipv6-router-selection-05.txt helps the
> node (the MR in our
> case) select its attachment router based on a
> preference, and routes if
> you are lucky enough to find an AR that has a more
> specific route to
> home. The draft does not say how the routers
> negotiate that in the
> backend and I believe it's a good thing.
> 
> draft-thubert-tree-discovery-00.txt adds information
> for nested MRs, and
> since TD forms trees, Route Information Option from
> draft-ietf-ipv6-router-selection-05.txt can safely
> be proxied. Also, it
> is expected that more metrics - such as bandwidth -
> will be added to TD
> to help MRs make even more educated decisions.
> 
> All have the concept that the MR makes the final
> decision for AR
> selection. This can be based on the actual
> reachability, bandwidth ...
> it gets by trying the ARs. This can be based on node
> policies. An
> external box does not know about all this. 
> 
> Note also that the problem you address is valid for
> any multihomed node,
> e.g. a web server.

I completely agree with you, this problem is more and
more important and I'm so interested to work on the AR
selection for multihomed nodes. I see a usual case
where the nodes are multihomed like in the forth
generation networks and I think that there is not
enough research on this scenario.   


 
> So, conceptually, I'm not too keen in pushing that
> draft the way it's
> presented, in terms of architecture and in terms of
> WG.
Our choice of the WG is related on the resource
reservation protocol adapted for NEMO networks. We
think that ARC is needed for such protocol.

I did not understand what did you mean by
architecture, is it the place of the ARC in the NEMO
hierarchy? the function of the ARC? or the entities'
communications?


> On the other hand, I agree that there is a need for
> a gateway that would
> be placed like the ARC.
> One example, as we all know it, is a HA for LMM. See
> draft-droms-nemo-dhcpv6-pd-01.txt for a NEMO version
> of it.
>
> I agree that the reservations can not placed end to
> end because it's
> hard to move them when the MR moves, and that it
> would be cool to place
> reservations in loose hops, like:
> 
> MR<->LMM<->HA<->HA<->LMM<->MR
> Or
> MR<->LMM<->CR
> 
> So again, I would like to see a draft describing
> which functions to
> place in such gateway...
> I would also like to see extensions to
>
http://www.ietf.org/internet-drafts/draft-jang-dhc->haopt-00.txt
> to help
> locate that gateway and find out about its
> capabilities, as opposed to
> overload RAs over and over.
I agree that we don't have to overload RAs, I will
read that draft and maybe we can find a suitable 
way to locate the gateway.


> What do you think?
:), I see that ARC functionalities are diverse. ARC
may be useful for AR selection, handover, resource
reservation, service continuity and many other
applications. I think that we can work to improve such
architecture.


Thanks for your comments
Regards
Mazen


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com