Subject: [nemo] Submitted I-D draft-baldessari-c2ccc-nemo-req-01

From: "Roberto Baldessari" <[email-masked]>
Date: Thu, 5 Jul 2007 16:25:08 +0200

Dear all,

We submitted a new version of the C2C-C automotive requirements for NEMO RO.
The draft is attached and also available at ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-baldessari-c2ccc-nemo-req-01.txt

There are several changes. We worked on restricting the requirements to the ones that are in the RO scope and removed what is unlikely to be addressed by the MEXT WG. Further, we compared requirements with the ones from aviation industry (draft-eddy-nemo-aero-reqs-00) and outlined similar or identical requirements.

Also, the structure of the document has changed. If you want to skip the technical approach description, which did not change much, have a look directly at Section 5 (RO scenario) and 6 (Requirements). We borrowed from draft-eddy-nemo-aero-reqs-00 the style in which requirements are listed, which we found particularly good.

Any comment is appreciated.

Best regards,

Roberto

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

NEC Europe Limited | Registered Office: 
NEC House, 1 Victoria Road, London W3 6BL 
Registered in England 2832014 
================================================

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 24 Jul 2007 01:36:22 +0200

Dear Roberto,

Very well written and instructive document.

Please find inline some comments on it (comments start with =>)

       C2C-C Consortium Requirements for NEMO Route Optimization
                   draft-baldessari-c2ccc-nemo-req-01

2.  Terminology

   The following terms used in this document are defined in the Mobile
   IPv6 protocol specification [2]:

   o  Home Agent (HA)

   o  Home Address (HoA)

=> These are defined in [2] but it is superceded by [8] where HA and
HoA are listed.

   The following terms used in this document are defined in the NEMO
   Route Optimization Space Analysis document [6]:

   o  Correspondent Router (CR)

   o  Correspondent Entity (CE)

=> These are defined in [2] but it is superceded by [8] where CR and CE
are listed.

   The following new terms are used in this document:

   o  Application Unit (AU): a portable or built-in device connected
      temporarily or permanently to the vehicle OBU.  It is assumed that
      AUs support a standard TCP/IPv6 protocol stack, optionally
      enhanced with IP Mobility support.  With respect to the NEMO
      terminology, an AU is a generic MNN.

=> Why AUs would be enhanced with IP mobility support ? If you are
considering hand-held devices, may be this should be added as a
justification.

   Vehicles' OBUs and stationary units along the road, termed road-side
   units (RSUs), form an ad hoc network.  

=> Is this necessarily the case ? (having read all the draft, this
seems to be required from the point of view of the C2C-CC, but taking
the OBU from a more generic stand point ?)

3.2.  Protocol Architecture

   The protocol stack currently considered by C2C-CC for OBUs is
   depicted in Figure 2.

               +--------------------+------------------+
               |                    |                  |
               |       C2C-CC       |     IP-based     |
               |    Applications    |   Applications   |
               |                    |                  |
               +--------------------+------------------+
               |                    |    TCP/UDP/...   |
               |  C2C-CC Transport  +------------------+
               |                    |                  |
               +--------------------+-----+    IPv6    |
               |                          |            |
               |      C2C-CC Network      |            |
               |                          |            |
               +--------------------+-----+------------+
               |      Modified      |  Standard WLAN   |
               |    IEEE 802.11p    | IEEE 802.11a/b/g |
               +--------------------+------------------+

                       Figure 2: OBU Protocol Stack

=> Wouldn't is be useful to also show on another figure the protocol
stack at the AU and the RSU (if it differs). 

3.3.  IPv6 Deployment

   o  On the IEEE 802.11a/b/g interface directly: in this method, IPv6
      headers are sent directly to the wireless LAN interface as
      specified by [5].

=> This is not the RFC you had in mind. 

   The following informational list briefly summarizes currently
   discussed design concepts:

   o  vehicles use only IPv6 addresses with as host part an EUI-64
      identifier derived from the MAC address.  

=> I wonder why this constraint ? Why not using random generation of
the host id part ?

   o  when infrastructure access is not available, OBUs use addresses
      with as prefix part a predefined IPv6 prefix (either reserved for
      C2C-C communications or a general purpose one);

=> "when infrastructure access is not available": it depends if you mean
"infrastructure access not always available", or "infrastructure access
never available". If the former, you could remove "when infrastructure
access is not available" because OBUs would always use the same prefix

4.1. Scope of NEMO

   As it does not seem realistic that every car owner will also
   subscribe for such a service [Home Agent]

=> Why not ? It can (and should IMHO) be required in the C2C-CC
architecture

4.2.2.  Peer-to-peer Applications

   In this set of use cases, the same applications should be able to run
   in V2V and V2I mode.  As applications should not be aware of routing
   nor addressing issues, they should use the same identifier for
   sessions and users (e.g. cars/drivers/passengers) independently of
   the communications mode.  Possible approaches are either to adopt
   resolution mechanisms or actually maintain the same network
   identifier in both V2V and V2I modes.  This could be achieved for
   example generalizing the concept of Mobile Network Prefix (MNP) and
   allowing a Mobile Router (OBU) to use it for V2V communications in
   absence of attachment points.  By means of enforcing limited lifetime
   for IPv6 prefixes and due to the isolation of VANET clusters from the
   infrastructure (in V2V), this use of MNP should not introduce routing
   inconsistencies.

=> For this particular paragraph, I think you need to explain how it
fits with NEMO.

5.  NEMO Route Optimization Scenarios

   With respect to the classification of NEMO Route Optimization
   scenarios described in [6], the non-nested NEMO RO case (Section 3.1)
   is considered as the most important for the C2C-CC deployment.  In
   fact, MIPv6-enabled AUs (i.e.  VMNs) and nested Network Mobility are
   not considered in the C2C-CC use cases.

=> Please check my comment about AU in the terminology section. The wording "optionally enhanced with IP mobility support" in definition of AU is not consistent with the above statement.

   The requirements defined in this document refer to RO between MR and
   CR (Correspondent Router).  According to C2C-CC use cases, the CR can
   be:

=> Here (and everywhere above in the remaining parts of this draft), I
would suggest to use CN, or CE. Currently, there is no reasons to
assume that RO would be performed with a CR.

   In the first case, the connectivity to the infrastructure is
   available only for short time intervals.  Vehicles' applications
   exchange data packets with nodes in the infrastructure in form of
   short bursts, containing for example traffic updates or information
   about local points of interests.  In this situation, providing prompt
   and reliable communication is more important than achieving optimal
   routing or highest available throughput.  In particular, the
   additional delay for RO establishment with every CRs can have a
   considerable negative impact.  Furthermore, in some situations the
   path through MR-HA tunnel might be considered more reliable and
   trustworthy than a direct one to the CR.  In particular, the tunnel
   allows the MR to hide its CoA from the CR which results in a location
   privacy protection.  Therefore:

=> It's not for granted in the case where the CN would be immediately
behind the RSU. The path through the HA would be considerably longer
and is obviously less trustworthy than the MR-HA tunnel (the path
MR-AR-CN compares with the path MR-AR-...-HA-HA-...-AR-CN)

6.2.  Req 2 - MNN IPsec

   A RO technique SHOULD allow MNNs connected to the MR to use IPsec as
   if they were connected to a regular access router.

   This requirement comes from the fact that no assumption can be made
   on pre-existing trust relationships between passenger devices and the
   OBU.  Therefore, passenger devices (assumed to run IPv6 without
   Mobility Support) should be able to use full IPsec functionalities
   when connecting to the infrastructure via a MR.

=> This requirement doesn't make much sense to me. Each IPv6 node is
supposed to support IPsec, so it is guaranteed that MNN won't  be
prevented from using IPsec.

6.4.  Req 4 - Privacy Protection

   A RO technique MUST not require that the MNP is revealed to all nodes
   in the visited network.  Instead, a RO technique MUST allow for
   revealing the MNP only to selected nodes in the visited network.
   Furthermore, a RO technique SHOULD allow that MNP and HoA are not
   exchanged as clear text.

=> It should be "MUST allow" (since you wrote about "allowance").

6.5.  Req 5 - Multihoming

   A RO technique MUST allow a MR to be simultaneously connected to
   multiple access networks, having multiple prefixes and Care-Of
   Addresses in a MONAMI6 context.

   In other words, it is required that a RO technique can be used on
   multiple communication technologies.  Assuming that mechanisms for
   registering and handling multiple CoAs are provided from the MONAMI6
   work, NEMO RO should be usable for every available CoA.

   This requirement is also specified in [9].

6.6.  Req 6 - Coexistence with Sub-IPv6 RO

   A RO technique MUST allow for coexistence in the same OBU with a RO
   technique offered by the sub-IPv6 C2C-CC Network layer.  The OBU MUST
   be able to choose which technique to use when both are simultaneously
   available.

=> What about the HA ? 

=> In line with section 5, I think that a requirement "Delay in RO
establishment" is missing in section 6. i.e. the RO mechanism should be
fast enough to adapt to CoA change in order to fit with VANET needs.

=> I would suggest to check if the listed RO requirements match all of
RFC 4886 design goals. For instance, signaling overhead, transparency,
etc. The C2C-CC may have specific considerations.

10.2.  Informative References

   [8]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-06 (work in progress),
         November 2006.

=> This document should be in the normative section since the
terminology is a norm (though the document is in the "Informational"
track).

Thierry.

On Thu, 5 Jul 2007 16:25:08 +0200

---

From: "Teco_Boot" <[email-masked]>
Date: Tue, 24 Jul 2007 15:01:46 +0200

Hi,

Thomas Clausen presented a short introduction of a Mobile Router in the
Autoconf-MANEMO meeting. He also explained the interface roles Ingress and
Egress.
I prefer the term _interface roles_ over _interface types_. However, I
wonder this new term is accepted by the NEMO WG and if the impact is fully
understood. For example, we have to find out if the roles are mutually
exclusive. 
A related issue is allowing the egress interface to act as a router
interface when attached to a foreign link; as this contradicts with NEMO
Basic Support.
I suggest an impact analysis document on this issue is written.
 
Teco.

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 24 Jul 2007 22:55:00 +0800

Hello, 

> understood. For example, we have to find out if the roles are mutually

I kind of agree with the _interface role_ terminology, as I do not
believe the ingress and egress types are mutually exclusive.

In the multihoming issues draft (soon to be RFC), we have included in
the Appendix C a suggestion for MR to listen to its ingress interface
for other MRs, and if its original egress link is down, try to attach to
said other MRs using its ingress interface.

I believe you are looking at this from a MANEMO perspective, and my
description above is using a more "traditional" approach, but I think it
wasn't that different from a higher layer.

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 24 Jul 2007 17:11:51 +0200

>understood. For example, we have to find out if the roles are mutually

Well, MANEMO can define the roles of the interface as it wish, it
doesn't change how NEMO see things. In any case, the NEMO terminology
is set up and published, and a different view from MANEMO doesn't cause
inconsistencies.

>interface when attached to a foreign link; as this contradicts with NEMO

I don't see a contradiction here. NEMO Basic Support just says that
packets must be encapsulated to the HA. But the Mobile Router is not
obliged to perform a NEMO Basic Support function.

>I suggest an impact analysis document on this issue is written.

I think this should be done within MANEMO problem statement.

Thierry.

---

From: "Teco_Boot" <[email-masked]>
Date: Tue, 24 Jul 2007 19:04:20 +0200

Thanks for the quick response.
I think it is described in B.2 Re-Establishment of Bi-Directional Tunnels in
draft-ietf-nemo-multihoming-issues-07.
I'll come back on the mutual exclusive issue.
Teco

> -----Original Message-----
> From: Chan-Wah Ng [mailto:[email-masked]]
> Sent: dinsdag 24 juli 2007 16:55
> To: Teco_Boot
> Cc: [email-masked]
> Subject: Re: [nemo] Interface roles: ingress and egress
> 
> Hello,
>

---

From: "Roberto Baldessari" <[email-masked]>
Date: Tue, 24 Jul 2007 23:13:22 +0200

Dear Thierry,

thanks a lot for the comments, see inline mine.

> => Why AUs would be enhanced with IP mobility support ? If 
> you are considering hand-held devices, may be this should be 
> added as a justification.
> 

[Roberto] Right. In fact this is not consistence with RO Scenario section and will be removed in next version.

> => Is this necessarily the case ? (having read all the draft, 
> this seems to be required from the point of view of the 
> C2C-CC, but taking the OBU from a more generic stand point ?)
> 

[Roberto] Agreed. "form an ad hoc network" to be removed in next version.

> => Wouldn't is be useful to also show on another figure the 
> protocol stack at the AU and the RSU (if it differs). 
> 

[Roberto] we'll put a figure in next version or at least a brief description of AU and RSU stack in the text.

> => This is not the RFC you had in mind. 

[Roberto] Uhm, I think it is.
We wanted to cite how IPv6 is transmitted on IEEE 802.11a/b/g. As far as I know, IEEE 802.11 MAC by default provides transmission of Ethernet Type II headers (14 Bytes [src|dst|proto type]). In the end, it provides a kind of Ethernet abstraction layer. So, I think that RFC 2464 applies to 802.11-based technology.

> => I wonder why this constraint ? Why not using random 
> generation of the host id part ?
> 

[Roberto] I clarified this offline. The draft here refers to the egress iface. C2C uses only EUI-64 identifier derived from the MAC address in order to avoid IPv6 to MAC address resolution via NS/NA.

> => "when infrastructure access is not available": it depends 
> if you mean "infrastructure access not always available", or 
> "infrastructure access never available". If the former, you 
> could remove "when infrastructure access is not available" 
> because OBUs would always use the same prefix
> 

[Roberto] Ok, rephrasing in the text is needed. 

> => Why not ? It can (and should IMHO) be required in the 
> C2C-CC architecture
> 

[Roberto] I'll rephrase this. The point here was that it is not expected that every car with C2C stack will also run NEMO. C2C is concerned about costs and there will be differentiation among cars level, e.g. basic and extended systems. Nevertheless, the phrase might sound strange in this context.

> => For this particular paragraph, I think you need to explain 
> how it fits with NEMO.
> 
> 

[Roberto] We'll address this in next version.

> => Here (and everywhere above in the remaining parts of this 
> draft), I would suggest to use CN, or CE. Currently, there is 
> no reasons to assume that RO would be performed with a CR.
> 

[Roberto] Yes. this is very important. 
After re-thinking I agree. to summarize, RO is between MR and CE. CE can be:
1) a NEMO MR
2) a router (not a MR) implementing NEMO RO
3) a CN, i.e. IPv6 host
4) a MIPv6 CN

case 4) does not have such a high priority in automotive, because in the identified use cases the MR will mainly talk to newly deployed nodes. Anyway, if RO is provided also for 4), it is definitely beneficial.

> => It's not for granted in the case where the CN would be 
> immediately behind the RSU. The path through the HA would be 
> considerably longer and is obviously less trustworthy than 
> the MR-HA tunnel (the path MR-AR-CN compares with the path 
> MR-AR-...-HA-HA-...-AR-CN)
> 
> 

[Roberto] Fine. As you pointed out, a good way to address this is to add a requirement about maximum allowed delay due to RO establishment. If providing numbers is not feasible, the requirement will be more generic but still valid.
The point that in some cases (e.g. exchange of very few packets) establishing RO is not a good idea, is still valid.

> => This requirement doesn't make much sense to me. Each IPv6 
> node is supposed to support IPsec, so it is guaranteed that 
> MNN won't  be prevented from using IPsec.
> 
> 

[Roberto] If full IPsec support is understood among RO solution designers, then the requirement can be removed. If not, the requirement has the benefit to make them aware of something they might not consider. 

I would pose this as a question during the session. My default choice would be to keep it, but pointing out in the text that it is added for sake of clearness.

> => It should be "MUST allow" (since you wrote about "allowance").

[Roberto] ok.

>    be able to choose which technique to use when both are 

[Roberto] HA would not be aware of sub-IPv6 RO. This might raise administrative issues. I don't think that they are in the scope of RO design. If you refer to security issues, they would be fixed by means of C2C-CC security functionalities.

> 
> => In line with section 5, I think that a requirement "Delay 
> in RO establishment" is missing in section 6. i.e. the RO 
> mechanism should be fast enough to adapt to CoA change in 
> order to fit with VANET needs.
> 

[Roberto]already addressed.

> => I would suggest to check if the listed RO requirements 
> match all of RFC 4886 design goals. For instance, signaling 
> overhead, transparency, etc. The C2C-CC may have specific 
> considerations.
> 
> 

[Roberto] ok.

Roberto