Subject: RE: [nemo] new draft

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 2 Sep 2004 14:05:19 +0200

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.

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.

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.

What do you think?

Pascal

---

From: Mazen TLAIS <[email-masked]>
Date: Thu, 2 Sep 2004 20:17:38 +0200 (CEST)

--- "Pascal Thubert (pthubert)" <[email-masked]>
> Note also that the problem you address is valid for

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.   

> presented, in terms of architecture and in terms of
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?

> I would also like to see extensions to
http://www.ietf.org/internet-drafts/draft-jang-dhc->haopt-00.txt
> to help
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