Subject: [nemo] new draft

From: Mazen TLAIS <[email-masked]>
Date: Thu, 19 Aug 2004 12:49:03 +0200 (CEST)

Hi all,
 
We have submitted a new draft on the multihoming, handover and resource management issues, a proposed architecture is presented. Your comments are appreciated.

http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-management-00.txt

Abstract:
   This draft introduces a protocol that achieves handoff and resource
   management in a NEMO network in the case of multi-homed MR.
   We called this protocol an HRMMN protocol (Handoff and Resource
   Management for Multi-homed Networks). We introduce into the NEMO 
   architecture an intelligent control entity called Access Router 
   Controller (ARC). Based on traffic information transmitted through 
   several ARs under the control of specific ARC, this latter is 
   responsible of taking decisions about handoff, resource management 
   and maintain of multiple bidirectional tunnels.

Regards
Mazen TLAIS

---------------------------------
Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Créez votre Yahoo! Mail

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis.Téléchargez GRATUITEMENT ici !

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 19 Aug 2004 20:11:31 +0200

Hello Mazen,

Thanks for the I-D.

I'm rather curious on scenarios when such an architecture as you propose 
would be likely.

You seem to assume that there is a suitable point in a typical access 
network where an ARC can be placed. From your draft I can't be sure what 
security relationships that are required, but if the ARC needs security 
relationships with many ARs this in general creates scalability 
problems. My general assumption is that in order to benefit from 
multihoming, an MR would connect to various access networks of different 
technologies. That would mean that ARs belong to different domains. The 
nature of multihoming is to connect to the network in topological 
locations far from each other, often even completely unrelated 
locations. That is what makes the placement of an ARC difficult, as it 
is meant to be near the different ARs. But I may have misinterpreted 
your architecture.

What is the actual function of the ARC? I don't think the draft explains 
clearly enough if it actually acts as a local home agent and creates 
bi-directional tunnels towards the MRs.

What makes it different from a MAP in HMIPv6 (apart from the very 
loosely defined resource reservations you include)?

BR
Mattias

Mazen TLAIS wrote:
> Hi all,
>  
> We have submitted a new draft on the multihoming, handover and resource 
> management issues, a proposed architecture is presented. Your comments 
> are appreciated.
> 
> /http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-management-00.txt/
> 
> Abstract:
> ------------------------------------------------------------------------
> Créez gratuitement votre Yahoo! Mail avec *100 Mo de stockage !*
> Créez votre Yahoo! Mail 
> <http://fr.rd.yahoo.com/mail/taglines/*http://fr.rd.yahoo.com/evt=25917/*http://fr.rd.yahoo.com/mail/mail_taglines_100/default/*http://fr.benefits.yahoo.com/>
> 
> *Le nouveau Yahoo! Messenger est arrivé !* Découvrez toutes les 
> nouveautés pour dialoguer instantanément avec vos amis. Téléchargez 
> GRATUITEMENT ici ! 
> <http://fr.rd.yahoo.com/mail/taglines/*http://fr.rd.yahoo.com/evt=26111/*http://fr.rd.yahoo.com/messenger/mail_taglines/default/*http://fr.messenger.yahoo.com> 
>

---

From: Mazen TLAIS <[email-masked]>
Date: Fri, 20 Aug 2004 12:08:42 +0200 (CEST)

Hi Mattias,

Here are some responses for your comments

> problems.
Updating messages sent by MR to ARC need 
security relationships. I'm not sure about ARs.

>My general assumption is that in order to
> benefit from 
If the AR is registered within an ARC, then 
this later can manage the AR. It's not a location
question.

> bi-directional tunnels towards the MRs.
through AR preferences option, ARC is responsible to
help MR to prefer an AR in face of another AR .

But we assume that ARC MAY play the role of a
local home agent according to administrator's
configuration. 

> 
> What makes it different from a MAP in HMIPv6
May be i misunderstand HMIPv6, but i think that MAP is
useful for handoff operation, it does not manage
resources, and the MR does not have any additional 
information to choose between different ARs.

> (apart
> from the very 
In our draft, we present a possible scenario 
of the ARC contribution to reserve resources.
We are working now on a complete idea for end to end
reservation protocol adapted for NEMO networks. But we
need few weeks to finalize it.  

Thanks, we really appreciate 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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 20 Aug 2004 12:17:38 +0200

Hi all,

	Thanks for submitting the i-d.

	I agree with Mattias. Besides, there some scenarios of multihoming in
NEMO that have not been covered by your solution and that are also
important IMHO. For example, a NEMO can be multihomed by having more
than one MR connecting to different ARs. Another point I don't see
clearly is what happens when the NEMOs are nested, how does your
mechanism work in this case? With nesting is involved, the overhead
problem is more severe.

	Kind regards,

	C.J.

El jue, 19-08-2004 a las 12:49, Mazen TLAIS escribió:
> Hi all,
>  
> We have submitted a new draft on the multihoming, handover and
> resource management issues, a proposed architecture is presented. Your
> comments are appreciated.
> ______________________________________________________________________
> Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les
-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Mazen TLAIS <[email-masked]>
Date: Fri, 20 Aug 2004 12:41:34 +0200 (CEST)

Hi Carlos,

thanks for your comments, here are some responses

>there some scenarios
> of multihoming in
> than one MR connecting to different ARs.
Yes, our solution does not cover all multihoming
scenarios.

> Another
> point I don't see
In fact, we assume that only the root mobile router
is charged to communicate with the ARC.

Regards
Mazen

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc

---

From: Mattias Pettersson <[email-masked]>
Date: Sun, 29 Aug 2004 19:57:26 +0200

> this later can manage the AR. It's not a location

Continuing my assumption that there is a need for security associations 
between AR and ARC, if an AR is located in a different administrative 
domain than where the ARC is located, this generally creates scalability 
problems.

Maybe you can line out what messages each entity sends to other 
entities, and what state change each message will cause at the receiver? 
Any state change must be authorized.

> information to choose between different ARs.

That is very true.

> need few weeks to finalize it.  

OK, we'll see.

/Mattias