RE: [nemo] Deployment Requirements

"Roberto Baldessari" <Roberto.Baldessari@netlab.nec.de> Mon, 29 May 2006 08:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcsd-0007NF-5Z; Mon, 29 May 2006 04:13:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcsb-0007NA-Sz for nemo@ietf.org; Mon, 29 May 2006 04:13:37 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkcsY-00083I-1y for nemo@ietf.org; Mon, 29 May 2006 04:13:37 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2C4232007D5F; Mon, 29 May 2006 10:13:49 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24035-01; Mon, 29 May 2006 10:13:49 +0200 (CEST)
Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 08A8E20001B8; Mon, 29 May 2006 10:13:49 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] Deployment Requirements
Date: Mon, 29 May 2006 10:13:29 +0200
Message-ID: <6D28EBC684A4D94096217AD2FE400873650776@venus.office>
In-Reply-To: <765F3C78-C07F-465F-B26B-89FA4D2440DD@sfc.wide.ad.jp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nemo] Deployment Requirements
thread-index: AcZ6migcb7w/yQxgQT6V8ugUzxXDIwIW2QnQ
From: Roberto Baldessari <Roberto.Baldessari@netlab.nec.de>
To: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>, Thierry Ernst <thierry.ernst@inria.fr>
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d
Cc: nemo@ietf.org
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Errors-To: nemo-bounces@ietf.org

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:  roberto.baldessari@netlab.nec.de
web:     http://www.netlab.nec.de/
================================================ 



> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] 
> Sent: Thursday, May 18, 2006 6:42 PM
> To: Thierry Ernst
> Cc: nemo@ietf.org
> Subject: Re: [nemo] Deployment Requirements
> 
> Hi Thierry
> 
> On 2006/05/18, at 22:14, Thierry Ernst wrote:
> 
> >
> > 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.
> 
> yes, this is.
> 
> > 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.
> 
> 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
> 
> 
> 
> 
> 
> > 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:
> >>
> >>>
> >>> 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.
> >>>
> >>>>>>> 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 ?
> >>>>>>>
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>
> >>>> 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 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.
> >>>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>>>> 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)
> >>>>>
> >>>>> 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 ?
> >>>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>>>> 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
> >>>>>>> could be used as input for determining a common list of
> >>> deployment>>>> requirements.
> >>>>>>>
> >>>>>>
> >>>>>> 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
> >>>>>
> >>>>> 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 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 ?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Thierry.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, 16 May 2006 09:19:30 +0300
> >>>>>>>>> marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi   :
> >>>>>>>>>>
> >>>>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> i am willing to help Terry on this in case it is needed...
> >>>>>>>>>>
> >>>>>>>>>> regards, marcelo
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> TJ
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- 
> >>>>>>>>> Thierry ERNST, PhD
> >>>>>>>>> INRIA Rocquencourt Projet IMARA
> >>>>>>>>> +33 1 39 63 59 30
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -- 
> >>>>>>> Thierry ERNST, PhD
> >>>>>>> INRIA Rocquencourt Projet IMARA
> >>>>>>> +33 1 39 63 59 30
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> -- 
> >>>>> Thierry ERNST, PhD
> >>>>> INRIA Rocquencourt Projet IMARA
> >>>>> +33 1 39 63 59 30
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> -- 
> >>> Thierry ERNST, PhD
> >>> INRIA Rocquencourt Projet IMARA
> >>> +33 1 39 63 59 30
> >>>
> >>
> >>
> >>
> >
> >
> > -- 
> > Thierry ERNST, PhD
> > INRIA Rocquencourt Projet IMARA
> > +33 1 39 63 59 30
> >
> 
> 
>