Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-ro-automotive-req-02.txt

From: [email-masked]
Date: Wed, 11 Feb 2009 15:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title		: Automotive Industry Requirements for NEMO Route Optimization
	Author(s)	: R. Baldessari, T. Ernst, A. Festag, M. Lenardi
	Filename	: draft-ietf-mext-nemo-ro-automotive-req-02.txt
	Pages		: 25
	Date		: 2009-1-15
	
This document specifies requirements for NEMO Route Optimization
   techniques as identified by the automotive industry.  Requirements
   are gathered from the Car2Car Communication Consortium and ISO
   Technical Committee 204 Working Group 16 (CALM).  The document also
   overviews the current status of ETSI TC ITS, which is going to unify
   the approaches of these two automotive consortia in a single
   communication architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-ro-automotive-req-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Feb 2009 11:22:37 +0100

Authors of draft-ietf-mext-nemo-ro-automotive-req-02.txt

Thanks for this new version of the draft, and for having included some
of my earlier comments.

I think there is more to which we seemed to agree.

In short:
-difficult to parse the text of HoA and CoA assignments
-link-local addresses facilitates only MR-to-MR communications (not LFN
  to LFN)
-figure 1 is the same as figure 3, redundancy.
-reference to 802.11p is outdated (at least D5 is more recent, there may
  be others).

Details follow.

draft:
> o  according to the current availability of infrastructure 
> connectivity, OBUs can use (at least) 2 types of globally routable 
> IPv6 addresses: an IPv6 address configured using standard IPv6 
> stateless address configuration from Router Advertisements sent by 
> RSUs connected to a network infrastructure and an IPv6 address 
> temporarily or permanently assigned to the vehicle belonging to a 
> home network and not varying while the vehicle changes its point- 
> of-attachment to the Internet.  The former globally routable IPv6 
> address is used as the NEMO Care-of Address (CoA) and the latter as 
> the NEMO Home Address (HoA).

Sounds as if the HoA is not globally routable - it is.

"IPv6 address assigned to the vehicle belonging to a home network" - who
belongs to the home network?

draft:
> o  for V2V communication, i.e. when no infrastructure is available, 
> OBUs can use link-local addresses.

This is only half useful.  Only the OBUs can communicate to each other
using their link-local addresses, on their egress interfaces.  AUs in
the vehicles can not take advantage of that, can not communicate to each
other.  It sounds as a tempting method but deceiving in the end. (OBU:
On-Board Unit, like an MR; AU: Application Unit, like an LFN).

I think that should be mentioned.

In all cases, it shouldn't lead to application-level gateways.

About Figures.

Figure 1 and Figure 3 in 02 are the same as in 01, respectively - they
haven't changed.  Yet they're remarkably similar.  What are the
differences between Figure 1 and Figure 3?  Why should they  be pictured
twice?

> [IEEE.802-11p-d3-0]

The one I'm aware exists is D5.0 of November 2008.  There may be other
more recent?

Alex

[email-masked] a écrit :
> directories. This draft is a work item of the Mobility EXTensions for
>  IPv6 Working Group of the IETF.
> 
>  Author(s)	: R. Baldessari, T. Ernst, A. Festag, M. Lenardi Filename 
> : draft-ietf-mext-nemo-ro-automotive-req-02.txt Pages		: 25 Date		: 
> 2009-1-15  This document specifies requirements for NEMO Route 
> Optimization techniques as identified by the automotive industry. 
> Requirements are gathered from the Car2Car Communication Consortium 
> and ISO Technical Committee 204 Working Group 16 (CALM).  The 
> document also overviews the current status of ETSI TC ITS, which is 
> going to unify the approaches of these two automotive consortia in a 
> single communication architecture.
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> _______________________________________________ I-D-Announce mailing 
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft 
> directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Roberto Baldessari" <[email-masked]>
Date: Mon, 16 Feb 2009 18:12:11 +0100

Hi Alex,

Thanks for your comments, please see inline.

> I think there is more to which we seemed to agree.

Yes, but it was not possible to apply all of the changes for the reasons you'll find below.

[...]
> Sounds as if the HoA is not globally routable - it is.

Was not intended. We can repeat 'globally routable', if this makes things clearer.

> belongs to the home network?

Obviously the address belongs to the network. Maybe this paragraph can be split into more sentences. We'll try to clarify it.

> I think that should be mentioned.

Yes, we'll probably add it. Link-local addresses are listed in the section you mentioned because the list is not restricted to those addresses that only allow AU-to-AU communication (in different mobile networks). The subsection where this list is inform on IPv6 deployment and goes beyond the scope of NEMO requirements. But adding an observation might be a good idea.

> In all cases, it shouldn't lead to application-level gateways.

Agreed.

> differences between Figure 1 and Figure 3?  Why should they  be

You're right about the figures and there was the intention to remove the duplication. But since efforts to come up with a single architectural view are ongoing between ISO, C2C, ETSI and IEEE, we thought that it would make more sense to have one single section describing a sort of harmonized architecture and move the deployment-specific differences in an appendix, as soon as a stable draft is available.

> The one I'm aware exists is D5.0 of November 2008.  There may be other

Correct, D5.0 is the latest. We'll need to review the references and add ISO, ETSI stable drafts as soon as they are ready.

Roberto

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 23:30:03 +0100

Hi Roberto, thanks for the reply.  I understand some could be included
some not.

More comments below.

Roberto Baldessari a écrit :
>>> connectivity, OBUs can use (at least) 2 types of globally 
>>> routable IPv6 addresses: an IPv6 address configured using 
>>> standard IPv6 stateless address configuration from Router 
>>> Advertisements sent by RSUs connected to a network infrastructure
>>>  and an IPv6 address temporarily or permanently assigned to the 
>>> vehicle belonging to a home network and not varying while the 
>>> vehicle changes its point- of-attachment to the Internet.  The 
>>> former globally routable IPv6 address is used as the NEMO Care-of
>>>  Address (CoA) and the latter as the NEMO Home Address (HoA).

YEs, it's clearer, thanks.

I think this clarification is needed to distinguish it from scenarios
where HoA is NATed (Scenario 3 Home Agent behind a NAT, of DS-MIPv6 draft).

>> "IPv6 address assigned to the vehicle belonging to a home network"
>>  - who belongs to the home network?
> 
> Obviously the address belongs to the network. Maybe this paragraph 
> can be split into more sentences. We'll try to clarify it.

I think yes, would make sense to clarify that.

>> draft:
>>> o  for V2V communication, i.e. when no infrastructure is 
>>> available, OBUs can use link-local addresses.
>> This is only half useful.  Only the OBUs can communicate to each 
>> other using their link-local addresses, on their egress interfaces.
>>  AUs in the vehicles can not take advantage of that, can not 
>> communicate to each other.  It sounds as a tempting method but 
>> deceiving in the end. (OBU: On-Board Unit, like an MR; AU: 
>> Application Unit, like an LFN).
>> 
> Yes, we'll probably add it. Link-local addresses are listed in the 
> section you mentioned because the list is not restricted to those 
> addresses that only allow AU-to-AU communication (in different mobile
>  networks). The subsection where this list is inform on IPv6 
> deployment and goes beyond the scope of NEMO requirements. But adding
>  an observation might be a good idea.

But if this goes beyond the NEMO RO requirements I'm wondering why
should they (link-locals and OBU-to-OBU communications) should be
mentioned at all.

And if they're mentioned then I think it's worth noting they
(link-locals for OBU-to-OBU) only half help for AU-to-AU communication -
there needs to be more.

Thanks,

Alex

>> Figure 1 and Figure 3 in 02 are the same as in 01, respectively - 
>> they haven't changed.  Yet they're remarkably similar.  What are 
>> the differences between Figure 1 and Figure 3?  Why should they  be
>>  pictured twice?
>> 
> 
> You're right about the figures and there was the intention to remove
>  the duplication. But since efforts to come up with a single 
> architectural view are ongoing between ISO, C2C, ETSI and IEEE, we 
> thought that it would make more sense to have one single section 
> describing a sort of harmonized architecture and move the 
> deployment-specific differences in an appendix, as soon as a stable 
> draft is available.

Ah! That's why then.  You mean later there'll be a single figure, and in
the Appendix?

Alex

>>> [IEEE.802-11p-d3-0]
>> The one I'm aware exists is D5.0 of November 2008.  There may be 
>> other more recent?
>> 
> 
> Correct, D5.0 is the latest. We'll need to review the references and
>  add ISO, ETSI stable drafts as soon as they are ready.
> 
> Roberto
> 
>