Subject: Re: [nemo] Rewording of RO work in the charter

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 1 May 2006 19:23:09 +0300

Hi Terry,

I have been reading the email that you sent to the ppml list about 
aviation requirements and PI addressing (which was very clarifiyng BTW) 
and i have another question about the requirements below. In 
particular, you seem to have 3 different networks on board... does all 
the requirements affect all the three networks? because i mean for 
instance in the case of the closed network, i guess that it is easier 
to provide some of the features since the peers are clearly located and 
cannot be anywhere in the global internet and any solution would only 
affect the close network/routing system...

thanks, it is a really interesting problem statement this one that you 
have here

regards, marcelo

El 29/04/2006, a las 7:45, Davis, Terry L escribió:

> T.J.
>
> You'll probably wish that you hadn't asked for this...
>
> These would be our ideal mobility solution.  I realize that meeting all
> of these is probably an extreme stretch.
>
> Take care
> Terry
>
> =================================================================
> Generally the aviation mobility requirements are:
>
> 1- Ability to "dock" with numerous Internet service providers utilizing
> different media; satellite (KU & L), EVDO, 802.11/802.16 airport;
> hardwired Ethernet "gatelink".
>
> 2- Ability to be multihomed to different providers over different links
> simultaneously.  The desired aircraft state will be to have two links
> active always.
>
> 3- Ability to assign traffic for specific providers links only (safety
> or operational certified providers)
>
> 4- Ability to re-profile traffic to match available link capacity and
> constraints when handing off between links.
>
> 5- Ability to seamlessly hand off existing network connections without
> dropping the session (we do this today).
>
> 6- Ability to maintain security through link hand off.
>
> 7- Ability to continue to receive multicast traffic after hand off.
>
> 8- Route optimization such that on hand off to a new link,
> connection/session routing is optimized to the new ground site.
>
> 9- Ability to maintain QoS on hand off with the capacity of the new 
> link
> (You may hand off to a link with a smaller capacity or higher error 
> rate
> or from an EVDO low latency link to a satellite high latency link)
>
> 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an
> IP-v6 network.
>
> 11- Ability to receive priority multicast/broadcast messages.
>
> 12- Ability to establish connections to multiple onboard networks over 
> a
> single link and hand off them simultaneously.  (We expect the aircraft
> to have at three independent onboard isolated networks; air traffic
> control, airline operations, and passenger services.
>
> 13- Ability to initiate encrypted tunnels on all links with IPSec 
> before
> passing traffic.
>
>
>> -----Original Message-----
>> From: T.J. Kniveton [mailto:[email-masked]]
>> Sent: Friday, April 21, 2006 3:13 AM
>> To: ml-nemo WG
>> Subject: [nemo] Rewording of RO work in the charter
>>
>> Folks,
>>
>> I have been watching the conversation started by Marcelo a couple of
>> weeks ago, regarding the rewording of the (n,n,n) item in the
>> charter. (Sorry I haven't been commenting lately).
>>
>> We need to figure out how to massage the concepts being batted around
>> so that we have something tractable that we can work on and complete.
>>  From the discussion so far, I tend to think:
>>
>> 1) We need somewhat more concrete idea of the requirements for the
>> type of situation we want to solve. I agree with Andrew that we don't
>> want to get bogged down in this, and I do believe Terry gave us a
>> list for the Conexion scenario quite a while ago. Perhaps he or
>> Andrew could give an updated list.
>>
>> 2) We need a bit more analysis still on the RO problem space, based
>> on some idea of requirements for the solution to be worked out
>> (according to charter items). Specifically, the effects of having a
>> "Mobile ISP" vs. "ISP-independent mobile home networks", the
>> implications of that for the global BGP tables, how likely it is to
>> get custom agreements between a mobility provider and ISPs it (or its
>> customers) uses, etc.
>>
>> 3) Route optimization - "Performance" as Marcelo called it - avoiding
>> long tunneling (geographically) - or avoiding expensive links. This
>> is what we have discussed so far, and we need a stronger boundary so
>> that we can define what is to be solved in these specific
>> circumstances. Otherwise this walks down the road toward many other
>> long-standing issues. My view is that having a good list of
>> requirements for the RO situation of interest would be helpful here.
>>
>> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use
>> it because it made sense. It's possible we have another deployment
>> case where it does not make sense, but we still want a solution for
>> Network Mobility. However, we have to be careful here.
>>    There are some general network mobility problems.. such as
>> multiple ISPs, having high-cost links, and how/whether to inject
>> routes into the BGP tables. I believe Terry already gave us a list of
>> requirements for this type of situation - can we review that?
>>
>> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be
>> "the only" or even "the" solution for RO. It is simply something that
>> addressed a shown need, and so I considered it to be something that
>> could be added for future work. But according to the list items
>> above, the group is not including or excluding any certain solution
>> at this point. We need more definition of what and how to solve, and
>> the implications of various approaches first. I would like to hear
>> the RO-analysis authors chime in on this one.
>>
>> Besides Aviation, I have asked numerous times for anyone who is
>> actually deploying NEMO or NEMO-like technology to give us industry
>> input for requirements. Aside from aviation, I have heard a little
>> bit regarding Japanese auto makers, but not much else. I also used to
>> know things about some large cell phone makers that might be doing
>> these things, but never enough to make a good list of requirements.
>>
>> Remember, our goal here is to reshape the charter to solve problems
>> so that NEMO can be deployed. If there are deployments that are
>> facing these issues, they can be brought forward to be studied at
>> this phase.
>>
>> In conclusion, I would like to have a bit more discussion, and then
>> maybe people can offer suggestions on how specifically to reword
>> charter language and/or change milestones so that these things can be
>> accomplished.
>
>

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 1 May 2006 11:24:28 -0700

Marcelo

To me it is preferable to be able to use one consistent design approach regardless of the onboard domain (air traffic control, airline operations, passenger services).  But it is certainly conceivable that for instance multi-homing and seamless hand off could be relaxed for airline operations and passenger services.

And definitely the routing solutions may be different (i.e. the relatively small size of a closed aviation network allows consideration of technologies that may scale adequately for the global Internet).

Take care
Terry

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Monday, May 01, 2006 9:23 AM
> To: Davis, Terry L
> Cc: ml-nemo WG; T.J. Kniveton
> Subject: Re: [nemo] Rewording of RO work in the charter
> 
> Hi Terry,
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 1 May 2006 21:44:38 +0300

El 01/05/2006, a las 21:24, Davis, Terry L escribió:

> Marcelo
>
> To me it is preferable to be able to use one consistent design 
> approach regardless of the onboard domain (air traffic control, 
> airline operations, passenger services).

i can see that such approach would provide benefits since it would be 
simpler

>  But it is certainly conceivable that for instance multi-homing and 
> seamless hand off could be relaxed for airline operations and 
> passenger services.
>

yes

i would suggest to identify the requirements for the different type of 
on board networks and also note explicitly that it would be a plus if 
all the capabilities could be provided by a single mechanism

regards, marcelo

> And definitely the routing solutions may be different (i.e. the 
> relatively small size of a closed aviation network allows 
> consideration of technologies that may scale adequately for the global 
> Internet).
>
> Take care
> Terry
>

---

From: T.J. Kniveton <[email-masked]>
Date: Mon, 15 May 2006 10:47:04 -0700

> of these is probably an extreme stretch.

Terry,

I second the request to put your list of items into a draft. It will  
be helpful to have a concrete list of deployment requirements to  
refer to. While the WG can't necessarily solve all of the problems  
for one specific deployment, an informational document listing them  
can be useful for guidance when making engineering design decisions.

Would you be willing to do that? Perhaps others in the WG can help  
with maintaining the document / editing if needed.

TJ

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 09:19:30 +0300

El 15/05/2006, a las 20:47, T.J.Kniveton escribió:

> be helpful to have a concrete list of deployment requirements to refer 
> to. While the WG can't necessarily solve all of the problems for one 
> specific deployment, an informational document listing them can be 
> useful for guidance when making engineering design decisions.
>

i am willing to help Terry on this in case it is needed...

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 16 May 2006 11:01:01 +0200

[I changed the subject line]

Speaking about "deployment requirements", I would propose to add a
section in draft-ietf-nemo-requirements (actually, I intended to extend
that draft since the beginning ;-) rather of editing a separate
document.

Would that make sense to everyone ?

Thierry.

On Tue, 16 May 2006 09:19:30 +0300

-- 
Thierry ERNST, PhD
INRIA Rocquencourt Projet IMARA
+33 1 39 63 59 30

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 12:47:09 +0300

Hi Thierry,

> Would that make sense to everyone ?

i think that there are some general deployment requirements that could 
fit in there

however, perhaps the case of aviation may have quite specific 
requirements of their own that may not apply in the general case.... i 
mean not all of us have worldwide sites and a nemo moving around 
several of them in a single day :-)

Regards, marcelo

>>> refer

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 16 May 2006 12:46:06 +0200

Hi Marcelo,

Well, do you intend to mean that we should write a deployment
requirements draft for the aviation industry specifically, in which case
we would do the same for the vehicular industry, and for each other
existing use cases ?

If yes, then I guess it would rather be individual submissions that
could be used as input for determining a common list of deployment
requirements.

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 13:59:05 +0300

> we would do the same for the vehicular industry, and for each other

well, i am not sure about the vehicular technology because i don't know 
if they have specific requirements.
but following the emails that have been exchanged lately in this ml, it 
is my opinion that the aviation case have quite special requirements 
and that they need customized solutions for thier problems that have 
their own set of deployment issues.

I mean consider that they are moving globally quite rapidly, they have 
wordlwide infrastruture, they need high reliability,  and so on, which 
makes their case somehow different from the case of nemos deployed in 
buses cars and so on (or at least it seems so to me)

that is why i think that the general requirements and in particular the 
deployment requirements for a solution to this particular problem need 
to be fleshed out

> If yes, then I guess it would rather be individual submissions

yes i think Terry initial list could be a starting point for this

> that

well depending on whether this requirements fit into the general 
requirements, this may be ok.... but i think that they are likely to be 
quite differetn from the general case

regards, marcelo

>>>>>> These would be our ideal mobility solution.  I realize that 
>>>>>> meeting
>>>>>> all

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 16 May 2006 14:45:01 +0200

> well, i am not sure about the vehicular technology because i don't
> know if they have specific requirements.

They do, though they don't speak up yet, because (unfortunately) IETF is
not an organization where they used to be involved. But they (or the
vendors related to the vehicular industry and the standardization bodies
such as ISO and ETSI) will show up when they understand it is important
for them to be involved in the debate.

Would be interesting to get some input from the Japanese folks who I
know are monitoring this ML. I'm not speaking only about the people at
Keio University who are academic though who are involved with these
people, but the people representing the companies who are in this
business. 

Come on folks, this is the right timing to discuss the deployment
requirements for the vehicular industry !

> but following the emails that have been exchanged lately in this ml,
> it is my opinion that the aviation case have quite special
> requirements and that they need customized solutions for thier
> problems that have their own set of deployment issues.

I second this. But the vehicular industry is IMHO more important as it
would involved tens of vendors, with possibly divergent deployment
requirements. 

> buses cars and so on (or at least it seems so to me)

Well, cases and thus requirements are different. RFC 3963 may not always
apply, but even though, the security, authentication and multihoming
considerations are different.

> that is why i think that the general requirements and in particular
> the deployment requirements for a solution to this particular problem
> need to be fleshed out

Yes, but what is the best procedure ? Independent draft, one for each
use case, or shall we came up straight with common requirements, in
which case I would say draft-ietf-nemo-requirements is the best place to
gather these deployment scenarios ?
 
> requirements, this may be ok.... but i think that they are likely to
> be quite differetn from the general case

This may not be an issue. The draft could be explicit that these are
requirements for that specific use cases where we get some input.

Thierry.

> >> i think that there are some general deployment requirements that
> >could> fit in there
> >>
> >> requirements of their own that may not apply in the general
> >case.... i> mean not all of us have worldwide sites and a nemo moving
> >around> several of them in a single day :-)
> >>
> >> Regards, marcelo
> >>
> >>
> >>> Thierry.
> >>>
> >>>
> >>>
> >>>>> to. While the WG can't necessarily solve all of the problems for
> >
> >>>>> one
> >>>>> specific deployment, an informational document listing them can
> >be>>>> useful for guidance when making engineering design decisions.
> >>>>>
> >>>>> Would you be willing to do that? Perhaps others in the WG can
> >help>>>> with maintaining the document / editing if needed.
> >>>>>
> >>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 May 2006 09:57:32 +0300

> for them to be involved in the debate.

good i am all for working on other cases if there is interest

(FWIW my point about working in aviation and not in other use cases was 
merely because there was no feedback on those, not because i have any 
kind of problem in working in other cases)

> would involved tens of vendors, with possibly divergent deployment

good, let's write those down also and see what is the common 
requiremetns for all the relevant use cases

If the common part is large, we should defineltly include them in the 
common requiremetns draft that we already have. If the common part is 
small and there are a lot of diverging requirements then we should go 
for different drafts i guess

but i guess that the first part is to get individual submissions from 
each of the use cases that people are interested in working on

> gather these deployment scenarios ?

see my suggestion above... i guess that in order to answer this we 
should first figure out what is the common requiremetns for all the 
relevant use cases and then we can decide...

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 17 May 2006 10:39:39 +0200

Hi,

We don't necessarily need a draft to gather the requirements (though a
draft is an easiest way to have a document to refer to when debating).

I'm happy to initiate a document for the vehicular industry though I'm
not sure I will have all the necessary time in the next few weeks. But I
need help from other people already involved with the car industry and
related vendors.

Actaully, I think gathering the deployment requirements is a necessary
step before rechartering the WG.

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 May 2006 12:43:40 +0300

> draft is an easiest way to have a document to refer to when debating).

agree

> step before rechartering the WG.

very much agree

regards, marcelo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 May 2006 11:32:14 -0700

> step before rechartering the WG.

or it could be part of the WG charter.

Vijay

>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi�:
>>>>>>>>

---

From: "Davis, Terry L" <[email-masked]>
Date: Thu, 18 May 2006 00:15:24 -0700

TJ

I have received the backing of the Arinc Air Data Networking committee
(an aviation standards organization) to work on this.  I expect to have
a rough draft of an informational RFC covering aviation network mobility
requirements for Montreal.

Take care
Terry

> Sent: Monday, May 15, 2006 10:47 AM
> To: Davis, Terry L
> Cc: ml-nemo WG

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 18 May 2006 20:03:37 +0900

Hi Thierry

i think the requirements from vehicle industry are summarized by ISO.
Each vehicle company has slightly different requirements, but ISO  
tried to
define a common network architecture for vehicles.
There was a presentation about ISO activity at IETFXX  (forgot which  
IETF).

We can point to the ISO document if there are.
It maybe time to come close between NEMO WG and ISO.

regards,
ryuji

On 2006/05/17, at 17:39, Thierry Ernst wrote:

>>>>> requirements draft for the aviation industry specifically, in  
>>>>> which
>>>>> case
>>> They do, though they don't speak up yet, because (unfortunately)  
>>> IETF
>>> is
>>> which case I would say draft-ietf-nemo-requirements is the best  
>>> place
>>> to
>>>>>>>>> I second the request to put your list of items into a  
>>>>>>>>> draft. It
>>>>>>>>> will

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 May 2006 13:51:22 +0200

Thierry Ernst wrote:
> Hi,
> 
> We don't necessarily need a draft to gather the requirements (though 
> a draft is an easiest way to have a document to refer to when 
> debating).
> 
> I'm happy to initiate a document for the vehicular industry though 
> I'm not sure I will have all the necessary time in the next few 
> weeks. But I need help from other people already involved with the 
> car industry and related vendors.

I can provide text about the IPv4 need in a particular industry where
vehicles on four or more wheels are used.  Would this be considered?

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 18 May 2006 15:14:03 +0200

Hi Ryuji,

Well, this could suffice (and thanks for recalling this presentation
"ISO Activities on NEMO BS", which can be found in the archives at
http://www3.ietf.org/proceedings/05aug/index.html under the NEMO WG
proceedings). However, this would weight more if there were people from
the vehicle industry and related business in Europe and Asia (where IPv6
is more favored) expressing their views on this ML right now.

ISO TC204 WG16 is surely developing a communication system based on IPv6
and there are a number of related projects in Europe developing a
complete architecture around NEMO (RFC 3963). However, most of the folks
involved in these groups are following the output of the IETF, but are
not taking part in the WG discussions, besides a few people. 

Thierry.

> > weeks.  But I
> > need help from other people already involved with the car industry
> > and related vendors.
> >
> > Actaully, I think gathering the deployment requirements is a
> > necessary step before rechartering the WG.
> >
> > Thierry.
> >
> >>>> well, i am not sure about the vehicular technology because i
> >don't>>> know if they have specific requirements.
> >>>
> >>> not an organization where they used to be involved. But they (or
> >the>> vendors related to the vehicular industry and the
> >standardization>> bodies
> >> merely because there was no feedback on those, not because i have
> >any> kind of problem in working in other cases)
> >>
> >>> Would be interesting to get some input from the Japanese folks who
> >I>> know are monitoring this ML. I'm not speaking only about the  
> >>> people at
> >>> Keio University who are academic though who are involved with
> >these>> people, but the people representing the companies who are in
> >this>> business.
> >>>
> >>>> but following the emails that have been exchanged lately in this 
> >
> >>>> ml,
> >> If the common part is large, we should defineltly include them in
> >the> common requiremetns draft that we already have. If the common
> >part is> small and there are a lot of diverging requirements then we
> >should go> for different drafts i guess
> >>
> >> but i guess that the first part is to get individual submissions
> >from> each of the use cases that people are interested in working on
> >>
> >>
> >>
> >>>> wordlwide infrastruture, they need high reliability,  and so on, 
> >
> >>>> which
> >>>>
> >>> apply, but even though, the security, authentication and
> >multihoming>> considerations are different.
> >>>
> >>>> that is why i think that the general requirements and in
> >particular>>> the deployment requirements for a solution to this
> >particular  >>> problem
> >>>> need to be fleshed out
> >>>
> >>> use case, or shall we came up straight with common requirements,
> >in>> which case I would say draft-ietf-nemo-requirements is the best 
> >
> >>> place
> >>> to
> >>>>> could be used as input for determining a common list of
> >deployment>>>> requirements.
> >>>>>
> >>>>
> >>> This may not be an issue. The draft could be explicit that these
> >are>> requirements for that specific use cases where we get some
> >input.>>
> >>> Thierry.
> >>>
> >>>>>
> >>>>>>> section in draft-ietf-nemo-requirements (actually, I intended
> >to>>>>>> extend
> >>>>>>> that draft since the beginning ;-) rather of editing a
> >separate>>>>>> document.
> >>>>>>>
> >>>>>> i think that there are some general deployment requirements
> >that>>>> could> fit in there
> >>>>>>
> >>>>>>>>> specific deployment, an informational document listing them 
> >
> >>>>>>>>> can
> >>>>>>>>> Would you be willing to do that? Perhaps others in the WG
> >can>>>> help>>>> with maintaining the document / editing if needed.
> >>>>>>>>>
> >>>>>>>>

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 18 May 2006 15:17:00 +0200

Hi,

>From a requirement point of view, yes, it should.

Thierry

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 May 2006 01:42:00 +0900

Hi Thierry

> is more favored) expressing their views on this ML right now.

yes, this is.

> not taking part in the WG discussions, besides a few people.

I am not so positive that those people will participate the  
discussion here,
since not all vehicle industry develop network system by own..

It's impossible to have completed requirements from all the industry,
I don't know how these partial deployment requirements will have  
"meaning" in this WG.

If somebody come to this ML and express the idea from vehicle  
industry, of course that will be great.

regards,
ryuji

>>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi���:
>>>>>>>>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 18 May 2006 10:39:46 -0700

> requirements for Montreal.

sounds good.

Vijay

---

From: "Roberto Baldessari" <[email-masked]>
Date: Mon, 29 May 2006 10:13:29 +0200

Dear all,

Sorry for reacting with delay.

We have followed the discussion on this mailing list for quite some time
and have noticed that vehicular scenarios are getting more attention in
NEMO. We are happy about this development.

In Europe, the Car to Car Communication Consortium
(http://www.car-2-car.org/) aims at standardizing intervehicle
communication in Europe. 
Other national projects like Network On Wheels in Germany
(http://www.network-on-wheels.de/) deal with that.

NEMO support is taken into consideration as candidate to provide global
IP mobility (and not only that).
Unfortunately, RFC 3963 does not meet all the requirements needed to be
deployed in this scenario. Nevertheless, we think that vehicular
communications are potentially one of the main scenarios where NEMO
could be used. Therefore, it would be beneficial for both the WG and the
companies involved in the projects if a NEMO evolution in this direction
will take place.

In the mentioned projects, vehicles form an ad hoc network which
operates in a licensed frequency band (5.9 GHz) using a communication
standard derived from 802.11 family (something similar to the US in
progress 802.11p standard). The system is mainly oriented to road
safety, but entertainment and convenient applications will definitely
have an important role, using different channels or an additional
network interface. A position based approach is used as routing protocol
in the ad hoc domain and IPv6 was chosen as default protocol for
IP-based applications.

If you are interested, we can continue discussing about the scenario and
how NEMO BS could be extended in order to be deployable in there.

Kind regards,

Andreas Festag
Roberto Baldessari

================================================
Roberto Baldessari
Research Associate
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 90511-167
Fax:     +49 (0)6221 90511-55
e-mail:  [email-masked]
web:     http://www.netlab.nec.de/
================================================ 

> From: Ryuji Wakikawa [mailto:[email-masked]] 
> Sent: Thursday, May 18, 2006 6:42 PM
> To: Thierry Ernst
> Cc: [email-masked]
> Subject: Re: [nemo] Deployment Requirements
> 
> Hi Thierry
> 
> > proceedings). However, this would weight more if there were people 
> > from the vehicle industry and related business in Europe and Asia 
> > (where
> > IPv6
> > complete architecture around NEMO (RFC 3963). However, most of the 
> > folks involved in these groups are following the output of 
> the IETF, 
> > but are not taking part in the WG discussions, besides a few people.
> 
> discussion here, since not all vehicle industry develop 
> network system by own..
> 
> It's impossible to have completed requirements from all the 
> industry, I don't know how these partial deployment 
> requirements will have "meaning" in this WG.
> 
> >> tried to define a common network architecture for vehicles.
> >>>>>>> which case we would do the same for the vehicular 
> industry, and 
> >>>>>>> for each other existing use cases ?
> >>>>>>>
> >>>>>>
> >>>>> IETF is not an organization where they used to be involved. But 
> >>>>> they (or
> >>>>> such as ISO and ETSI) will show up when they understand it is 
> >>>>> important for them to be involved in the debate.
> >>>>>
> >>>>
> >>>>> Well, cases and thus requirements are different. RFC 
> 3963 may not
> >>>>> always
> >>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi   :
> >>>>>>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 May 2006 12:37:37 +0300

Hi Roberto,

thank you for this input, i think it is very valuable...

El 29/05/2006, a las 11:13, Roberto Baldessari escribió:

> deployed in this scenario.

ok, which are those? could you state the specific requirements of the 
vehicular scenario so that extensions to nemo could be designed to 
support those?

(maybe an ID would be the best option for this...?)

>  Nevertheless, we think that vehicular

imho this is very interesting

regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 29 May 2006 18:16:12 +0800

Hello Roberto,

Thanks for the input.  Very encouraging indeed to see more deployment
scenario!

> companies involved in the projects if a NEMO evolution in this direction

Specifically why NEMO-BS (i.e. RFC3963) does not meet the
requirements?  

> in the ad hoc domain and IPv6 was chosen as default protocol for

So the cars are communicating with each other using ad hoc mode.  How
about intra-vehicular?  I expect that's where NEMO would step in.  Is it
within the scope of the consortium as well?

> how NEMO BS could be extended in order to be deployable in there.

Based on your scenario, I would expect that cars to talk to cars in
ad-moc mode, but with in each car a NEMO is formed, being using the CAN
protocol, Ethernet or Bluetooth.

I think NEMO will be involved when the components within a car network
need to talk to (A) another component in the another car, or (B) some
other nodes in the global internet (possibly using other cars as relay
to the base station).

>From the route optimization standpoint, I guess for (A), you need some
form intra-nested NEMO optimization.  It would be, I imagine,
unacceptable to go through the nested tunnels if the communications
involves accident prevention signalling, where any extra delay would be
fatal.

For (B), I suspect you need a form of nested tunnel optimization, or
maybe a way to flatten the NEMO.  Would a global HA-HA solution be of
any help here?

/rgds
/cwng

<much older mails snipped>