Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt

Dear Alex,

Thank you very much for your comments. Please see inline. 

> 
> I think it would make sense to try to talk somewhere in the 
> document about IP-over-foo-technology.  It may give a good 
> accompanying perspective to the architecture-uses-IPv6 
> perspective currently described.  It's very relevant to talk 
> about IPv6-over-802.11p in a document mentioning 802.11p and 
> IPv6 several times.
> 

Good point. What needs to be specified is IPv6-over-C2CNET (see Figure 2). In fact ETSI TC ITS WG 3 is going to write the standard for the geonetworking protocol that provides non-IP geographic ad-hoc routing. In ETSI, a work item for the specification of IPv6-over-geonetworking (Title: Intelligent Transport System (ITS); Transport & Network; Integration of IPv6 and GeoNetworking) has already been assigned. I am the "rapporteur". The ETSI document should also be followed-up by an IETF I-D. The ETSI drafts need to be stable first. A stable ETSI draft is due by Nov 2009. But that activity does not affect this requirements draft.

Regarding IPv6-over-11p, nothing needs to be specified as 11p does not amend changes to 802.11 as far as this is concerned. The same mechanism as for 802.11 apply (802.11+802.2+SNAP).

> 
> Still in the Terminology section, right after V2I definition, 
> it would be good to add V2I2V definition (vehicle to infra to 
> vehicle), term used later in the document; I think the 
> scenario is very relevant.
> 

You're right, the definition is missing. Among the authors we did not have 100% consensus on this term. The terms 'V2V' and 'V2I' are used in many automotive documents to distinguish whether or not the infrastructure is involved. So V2I2V can be seen as part of V2I, according to this criterion and therefore I think the term can be removed (in fact it only appears in the second part). We'll rediscuss this point.

> Page 11:
> > 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 
> > configured from a prefix permanently allocated to the vehicle and 
> > delegated to the vehicle from a home network.  The former globally 
> > routable IPv6 address is used as the NEMO Care-of Address (CoA) and 
> > the latter as the NEMO Home Address (HoA).
> 
> For the second case, MR's Home Address derived from MNP.  One 
> would make sure to clarify that this behaviour is not 
> standard NEMOv6, needs tweaks on the MR and on the HA, as 
> mentioned in section 5.3 "Home Address from MNP" of RFC 4887 
> "Home Network Models".
> 

Thanks for pointing this out. In fact, this may be an unwanted restriction due to misphrasing. IMO there is no particular reason related to the automotive use cases for which the HoA should be derived from the MNP.

> > o  for V2V communication, i.e. when no infrastructure is available, 
> > OBUs can use link-local addresses (default ones or with a C2C-CC 
> > specific prefix TBD).  As described above, a portion of the VANET 
> > (geographically or topologically scoped) is presented to IPv6 as a 
> > single, link-local multicast link.  Therefore the 
> link-local address 
> > can be used for multi-hop communications within the VANET;
> 
> First, can there be an IPv6 link-local address with a prefix 
> other than
> fe80?  (as suggested above by "C2C-CC specific prefix TBD").  
>  Shouldn't
> this be agreed by the IPv6-related WG - or maybe that's why 
> it's mentioned TBD?
> 

Right. We tried to be as general as possible in these first versions of the draft. But it's unlikely that the automotive industry will really need a (additional) link-local unicast prefix different than fe80::/10. 

> Second, what is understood by 'multi-hop communications'?  In 
> my understanding, 'multi-hop' is like Internet is multi-hop 
> and IP datagrams travel from hop to hop and have their TTL 
> decremented at each hop.  In this sense, if the VANET is 
> presented to IPv6 a single link-local multicast link then it 
> is not multi-hop - the TTL is not decremented throughout this link.
> 

Multi-hop in the draft is not necessarily referred to IP. Since this is an IETF draft, I see your point. If a non-IP protocol is used, then multi-hop communication should be called differently. We'll try to improve this.

> Third, whereas it is indeed possible to have two OBUs (On-Board Units,
> MRs) to talk to each other by using their link-local 
> addresses, it is not possible for the AUs (Applicatin Units, 
> LFNs) to talk to each other even if their respective OBUs 
> used their link-local addresses to talk to each other.  In 
> this sense, I wouldn't say "Therefore the link-local address 
> can be used for multi-hop communications within the VANET".
> 

See the previous observation. In the text, OBU to OBU (not involving AUs) via several non-IP hops is still called multi-hop. This generates confusion. We need to improve the text as to usage of terms.

> Can I simply suggest:
> 
> "Two OBUs can communicate directly through their respective 
> egress interfaces by using their IPv6 link-local addresses.  
> But their respective AUs can not take advantage of this possibility."
> 

Well, correct observation but maybe not in the scope of the doc. Please note that we tried to restrict the scope of requirements to the ones related to Route Optimization for NEMO BS, therefore infrastructure-based. The automotive industry needs more than this, no doubt. But MEXT does not seem to be the right place for that. I was involved in the MANEMO discussion but in the end I agreed with the objections on scopes.

Solutions for IPv6 AU-to-AU (note that I don't use MNN-to-MNN on purpose) infrastructure-less are needed. But this draft can not target them. We can still point this out in the draft and say that it's out of scope.

> Nit: 'divided' is better than 'devided', page 10.
> 
> Section 3.2.1 "System and Protocol Architecture" first 
> paragraph starting with "Vehicles are equipped with..." is 
> identical to first paragraph of page 7.  Possibly subsequent 
> paragraphs are identical as well.  I think it's redundant 
> text between the C2C-CC and ISO CALM sections.  The reader 
> has already read the C2C-CC part, so now it would make sense 
> to simply state the differences.
> 
> Similarly, Figures 1 and 3 are almost identical, with the 
> only difference being the presence of an optional interface 
> on OBU1.  It's hard to spot that difference - better stress 
> it in the text.
> 

Right, the next step will most likely be merging the sections (we need consensus from the involved bodies)

[can't comment on CALM-related issues, sorry]

> > 4.4.  Vehicles Monitoring
> > 
> > Vehicles monitoring services allow car manufacturers, car 
> garages and  
> > other trusted parties to remotely monitor vehicle 
> statistics.  Data is 
> > collected by an AU and sent by the OBU to the service 
> center via the 
> > Internet.
> > 
> > As an example, car manufacturers or garages offering this service 
> > could deploy NEMO Home Agents to serve thousands of cars.
> 
> I agree with the application and example use case.
> 
> However, I don't think NEMO protocol is adapted for this.  
> For example, in the above paragraph, was the intention to say 
> that NEMO Home Agents will receive monitored data from the 
> thousands of cars?  That's what is implied by the text.
> 
> The NEMO HA would only be involved in managing the mobility, 
> and not in monitoring the data.  Another CN would be 
> receiving the monitored data, from OBU (and probably from AU 
> actually).  HA would be there simply to deal with the 
> mobility of the OBU.
> 
> I am not sure what is the intention of the above paragraph, 
> but I would clarify in order to avoid confusions of believing 
> HA monitors data.
> 

Yes, that's what we meant. The HA is not necessarily the entity that offers the application service. We can clarify this. 

> > 4.5.  Infotainment Applications
> > 
> >    TBD by ISO CALM
> > 
> > 4.6.  Navigation Services
> > 
> >    TBD by ISO CALM
> 
> I suppose this is to be defined?
> 
> >    The requirements defined in this document refer to RO 
> between MR and
> >    CE (Correspondent Entity).  According to the automotive 
> use cases,
> >    the CE can be:
> > 
> >    1.  Another vehicle, i.e. another automotive MR.
> 
> I suggest call it RO between MR and MR.  Or maybe RO between 
> OBU and OBU.  But introducing the term CE is unnecessary.
> 

Already addressed by Thierry. We followed RFC 4885.

> >    In cases 1 and 2, the CE is a newly deployed entity.
> 
> It's not new, it's the MR, or the OBU.  BEtter call it MR or 
> OBU, rather than CE.
> 

Newly deployed means that we have more design freedom as compared to legacy IPv6 nodes. I think the distinction is important. You might want to suggest a different terminology.

> Nit: 'occur' is better than 'occour'.
> 
> Nit: 'known in advance to the MR' is better than
>       'known in advanced to the MR'
> 
> > 6.1.  Req 1 - Separability
> > 
> >    An RO technique, including its establishment procedure, 
> MUST have the
> >    ability to be enabled on a per-flow basis according to 
> pre-defined
> >    policies.  Policies criteria for the switching to RO 
> MUST at least
> >    include the end points' addresses and the MNP for which 
> RO is to be
> >    established.  Policies MAY change dynamically.
> > 
> 
> Before Req 1 I would suggest Req 0 'Reusability' to reuse an 
> existing protocol.
> 

Please elaborate.

> For req 1, I don't understand 'per-flow' - what's a flow?  
> Does it use the flow label in the IPv6 header?  Or is it 
> another newly defined term?
> 

Flow is used in so many RFCs without defining it. Even RFC 2460 defines Flow Labeling Capability without defining what a flow is (Sec 1). Did I maybe miss the RFC where the term flow is defined?

> Nit: 'This requirement' is better than 'This requirements'
> 
> Nit: 'unveil' or 'reveal' are both better than 'unveal'.
> 
> > 6.6.  Req 6 - Switching HA
> > 
> >    An RO technique MUST allow a MR to switch from one HA to 
> another one
> >    topologically distant from the first one.
> 
> This sounds either as an incomplete requirement (subsequent 
> text doesn't
>   contribute to completeness, just to over-generalization) or 
> as a non-requirement at all.
> 
> A requirement would be for MR to switch to another HA while 
> keeping its existing HoAs and CoAs.  That is a requirement, 
> probably difficult to satisfy.  I'd agree list it as 
> requirement, but only if it were qualified by that 'keep its 
> HoAs and CoAs'.

Agreed. CALM needs to clarify.

> 
> >    [c2ccc-manifesto]
> >               "Car2Car Communication Consortium Manifesto",
> >               http://www.car-2-car.org/index.php?id=570 , May 2007.
> 
> When I click on the link it says "TYP03 Error! The requested 
> page does not exist!"

The C2C-CC website has just been redone. This is the new link:
http://www.car-2-car.org/fileadmin/downloads/C2C-CC_manifesto_v1.1.pdf

> 
> >    [IEEE.802-11p-d3-0]
> >               "Draft Amendment to Standard for Information 
> Technology .
> >               Telecommunications and information exchange between
> >               systems . Local and Metropolitan networks . Specific
> >               requirements - Part 11: Wireless LAN Medium 
> Access Control
> >               (MAC) and Physical Layer (PHY) 
> specifications: Amendment
> >               3: Wireless Access in Vehicular Environments (WAVE)",
> >               IEEE P802.11p/D1.0, February 2006.
> 
> Where is this document?
> 

IEEE drafts are only available for IEEE members.

Best regards,

Roberto
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext