[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
MEXT                                                       R. Baldessari
Internet-Draft                                                NEC Europe
Intended status: Informational                                  T. Ernst
Expires: January 15, 2009                                          INRIA
                                                               A. Festag
                                                             NEC Germany
                                                              M. Lenardi
                                                          Hitachi Europe
                                                           July 14, 2008


      Automotive Industry Requirements for NEMO Route Optimization
               draft-ietf-mext-nemo-ro-automotive-req-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 15, 2009.

Abstract

   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).






Baldessari, et al.      Expires January 15, 2009                [Page 1]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  NEMO Automotive Deployments  . . . . . . . . . . . . . . . . .  5
     3.1.  Car2Car Communication Consortium . . . . . . . . . . . . .  5
       3.1.1.  System and Protocol Architecture . . . . . . . . . . .  6
       3.1.2.  IPv6 Deployment  . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  Scope of NEMO  . . . . . . . . . . . . . . . . . . . . 11
     3.2.  ISO TC204 WG 16 (CALM) . . . . . . . . . . . . . . . . . . 12
       3.2.1.  System and Protocol Architecture . . . . . . . . . . . 12
       3.2.2.  IPv6 Deployment  . . . . . . . . . . . . . . . . . . . 16
       3.2.3.  Scope of NEMO  . . . . . . . . . . . . . . . . . . . . 17
   4.  NEMO Example Use Cases . . . . . . . . . . . . . . . . . . . . 17
     4.1.  Notification Services  . . . . . . . . . . . . . . . . . . 17
     4.2.  Peer-to-peer Applications  . . . . . . . . . . . . . . . . 17
     4.3.  Upload and Download Services . . . . . . . . . . . . . . . 18
     4.4.  Vehicles Monitoring  . . . . . . . . . . . . . . . . . . . 18
     4.5.  Infotainment Applications  . . . . . . . . . . . . . . . . 18
     4.6.  Navigation Services  . . . . . . . . . . . . . . . . . . . 18
   5.  NEMO Route Optimization Scenarios  . . . . . . . . . . . . . . 18
   6.  NEMO Route Optimization Requirements . . . . . . . . . . . . . 19
     6.1.  Req 1 - Separability . . . . . . . . . . . . . . . . . . . 19
     6.2.  Req 2 - RO Security  . . . . . . . . . . . . . . . . . . . 20
     6.3.  Req 3 - Binding Privacy Protection . . . . . . . . . . . . 20
     6.4.  Req 4 - Multihoming  . . . . . . . . . . . . . . . . . . . 20
     6.5.  Req 5 - Minimum Signaling  . . . . . . . . . . . . . . . . 21
     6.6.  Req 6 - Switching HA . . . . . . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25















Baldessari, et al.      Expires January 15, 2009                [Page 2]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


1.  Introduction

   NEMO Basic Support [RFC3963] defines a protocol that provides IPv6
   mobility support for entire moving networks, where all data packets
   go through the IPv6-in-IPv6 tunnel established between the Mobile
   Router (MR) and the Home Agent (HA).  As already pointed out in
   various documents ([RFC4888], [RFC4889] and
   [I-D.ietf-mext-aero-reqs]) this can have severe consequences on the
   communication performances, as it causes data packets to follow a
   path that can be very far from optimal and requires a double IPv6
   header for every packet exchanged with a Correspondent Node (CN) in
   the Internet.  Compared with a communication that uses the ideal
   packet routing and the normal IPv6 header size, these factors result
   in an increased delay and a reduced throughput, plus indirect
   consequences like increased packet fragmentation and overall less
   efficient usage of resources.

   Various projects and consortia involving the automotive industry are
   considering NEMO as part of their protocol stack for the provisioning
   of session continuity and global reachability.  Nevertheless, the
   lack of standardized Route Optimization (RO) techniques allowing data
   packets to be exchanged directly between vehicles or between vehicles
   and hosts in the Internet is regarded as an obstacle for the actual
   deployment of this protocol.  As the definition of a general NEMO
   Route Optimization technique is highly complex, it appears more
   reasonable to address specific deployment requirements and design
   more tailored, less complex schemes for Route Optimization.

   This document gathers requirements from two bodies that are committed
   in deploying vehicular communications including NEMO as part of their
   protocol stacks.

   o  The Car2Car Communication Consortium [c2ccc-web] is an industry
      consortium of car manufacturers and electronics suppliers
      operating in Europe.  Its mission is to establish an open European
      industry standard for vehicular communications based on wireless
      LAN technology.  Its approach consists in considering vehicles as
      a Vehicular ad hoc Network (VANET), where cars are equipped with
      short-range communication devices that operate at frequencies
      dedicated to safety and non-safety vehicular applications.

   o  ISO TC 204 WG 16 (CALM): ISO (International Standard Organization)
      runs a number of Technical Committees.  Members are nations and
      offical participants represent their country.  TC 204 is devoted
      to Intelligent Transport Systems (ITS) and comprises a number of
      Working Groups (16, but 12 still in operation).  ISO TC 204 WG 16
      is working on "Wide Area Communications Protocols and Interfaces"
      and was established in year 2000.  It is specifying a protocol



Baldessari, et al.      Expires January 15, 2009                [Page 3]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


      architecture from the physical layer up to the application layer
      and designed for all ITS types of communications (vehicle-vehicle,
      vehicle-infrastructure, infrastrutcure-vehicle).  Known as the
      CALM architecture, the acronym was initially set to mean
      "Communications Air-interface, Long and Medium range" but was
      renamed in 2007 to "Communication Architecture for Land Mobile".

   The document is organized as follows: Section 2 defines terminology.
   Section 3 overviews the technical approaches adopted by the two
   automotive bodies to deploy NEMO.  Section 4 provides a non-
   exhaustive list of use cases of NEMO in automotive applications.
   Section 5 introduces the RO scenario and finally Section 6 lists the
   requirements for NEMO RO.


2.  Terminology

   The following terms used in this document are defined in the Network
   Mobility Support Terminology document [RFC4885]:

   o  Mobile Network

   o  Network Mobility (NEMO)

   o  Home Agent (HA)

   o  Home Address (HoA)

   o  Mobile Router (MR)

   o  Mobile Network Prefix (MNP)

   o  Mobile Network Node (MNN)

   o  Correspondent Router (CR)

   o  Correspondent Entity (CE)

   o  Egress Interface

   o  Ingress Interface

   The following new terms are used in this document:

   o  On Board Unit (OBU): a device installed in vehicles, implementing
      the communication protocols and algorithms and equipped with at
      least 1) a short-range wireless network interface operating at
      dedicated frequencies and 2) a wireless or wired network interface



Baldessari, et al.      Expires January 15, 2009                [Page 4]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


      where Application Units (AU) can be attached to.  With respect to
      the NEMO terminology, the OBU is the physical machine acting as
      MR, 1) is used as egress interface and 2) as ingress.

   o  Application Unit (AU): a portable or built-in device connected
      temporarily or permanently to the vehicle's OBU.  It is assumed
      that AUs support a standard TCP/IPv6 protocol stack.  Devices
      enhanced with Mobile IPv6, like hand-held user devices, also fall
      into the definition of Application Unit.  With respect to the NEMO
      terminology, an AU is a generic MNN.

   o  Road Side Unit (RSU): a device installed along roadsides
      implementing automotive communication protocols and algorithms.
      RSUs can either be isolated or connected to a network
      infrastructure.  In the latter case, RSUs are attachment points
      either acting themselves as IPv6 access routers or as bridges
      directly connected to an access router.

   o  In-vehicle network: the wireless or wired network placed in a
      vehicle and composed by (potentially) several AUs and one OBU.

   o  Vehicle-to-Vehicle (V2V) Communication Mode: a generic
      communication mode in which data packets are exchanged between two
      vehicles, either directly or by means of multi-hop routing,
      without involving any node in the infrastructure.

   o  Vehicle-to-Infrastructure (V2I) Communication Mode: a generic
      communication mode in which data packets sent or received by a
      vehicle traverse a network infrastructure.


3.  NEMO Automotive Deployments

3.1.  Car2Car Communication Consortium

   The Car2Car Communication Consortium (C2C-CC [c2ccc-web]) is an
   industry consortium of car manufacturers and electronics suppliers
   that focuses on the definition of an European standard for vehicular
   communication protocols.  The Consortium gathers results from
   research projects and aims at harmonizing their efforts.  For the
   standardization activity, the C2C-CC operates in cooperation with the
   newly established ETSI TC ITS (Technical Committee Intelligent
   Transportation System).

   The consortium's Manifesto [c2ccc-manifesto] gives an overview of the
   system and protocol architecture, as well as of the applications on
   which the Consortium has agreed so far.  In essence, this document
   defines a C2C-C protocol stack that offers specialized



Baldessari, et al.      Expires January 15, 2009                [Page 5]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   functionalities and interfaces to (primarily) safety-oriented
   applications and relies as a communication technology on a modified
   version of IEEE 802.11p [IEEE.802-11p-d3-0].  This protocol stack is
   placed beside a traditional TCP/IP stack, based on IP version 6,
   which is used mainly for non-safety applications or potentially by
   any application that is not subject to strict delivery requirements,
   including Internet-based applications.  The interaction between these
   stacks is currently discussed and briefly overviewed in this
   document.

3.1.1.  System and Protocol Architecture

   The current draft reference architecture of the C2C communication
   system is shown in Figure 1.





































Baldessari, et al.      Expires January 15, 2009                [Page 6]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


                        |       Internet        |
                        |                       |
                        +---+-----------------+-+
                            |                 |
                 Access  +--+-+            +--+-+  Access
                 Router  | AR |            | AR |  Router
                         +--+-+            +--+-+
                            |                 |
                      --+---+---            --+---+--
                        |                         |
         Road Side   +--+--+                   +--+--+   Public
           Unit      | RSU |                   | PHS |  Hot Spot
                     +---+-+                   +---+-+
                         |                         |
                        /\                        /\

                        \_                         \_
                          \_                         \_
                            \                          \

            Mandatory        \/
          Mod IEEE 802.11p    |       __               \/  Optional IEEE
            Interface     +---+--+      \__      \/     |   802.11a/b/g
                          | OBU1 |                |     |    Interface
                          +--+---+              +-+-----+---+
                   Vehicle1  |                  |   OBU2    |  On-Board
                        -+---+-+-               +--+--------+    Unit
                         |     |                   | Vehicle2
       Application    +--+-+ +-+--+           --+--+--
          Units       | AU | | AU |             |
                      +----+ +----+           +-+--+
                                              | AU |
                                              +----+

                  Figure 1: C2C-CC Reference Architecture

   Vehicles are equipped with networks logically composed of an OBU and
   potentially multiple AUs.  An AU is typically a dedicated device that
   executes a single or a set of applications and utilizes the OBU
   communication capabilities.  An AU can be an integrated part of a
   vehicle and be permanently connected to an OBU.  It can also be a
   portable device such as laptop, PDA or game pad that can dynamically
   attach to (and detach from) an OBU.  AU and OBU are usually connected
   with wired connection, but the connection can also be wireless, such
   as Bluetooth.  The distinction between AU and OBU is logical, they
   can also reside in a single physical unit.

   Vehicles' OBUs and stationary units along the road, termed road-side



Baldessari, et al.      Expires January 15, 2009                [Page 7]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   units (RSUs), form a self-organizing network.  An OBU is at least
   equipped with a (short range) wireless communication device based on
   draft standard IEEE 802.11p [IEEE.802-11p-d3-0] (adapted to European
   conditions and with specific C2C-C extensions) primarily dedicated
   for road safety, and potentially with other optional communication
   devices.  OBUs directly communicate if wireless connectivity exist
   among them.  In case of no direct connectivity, multi-hop
   communication is used, where data is forwarded from one OBU to
   another, until it reaches its destination.  For example in Figure 1,
   RSU and OBU1 have direct connectivity, whereas OBU2 is out of RSU
   radio coverage but can communicate with it through multi-hop routing.

   The primary role of an RSU is improvement of road safety.  RSUs have
   two possible configuration modes: as isolated nodes, they execute
   applications and/or extend the coverage of the ad hoc network
   implementing routing functionalities.  As attachment point connected
   to an infrastructure network, RSUs distribute information originated
   in the infrastructure and offer connectivity to the vehicles.  As
   result, for example, the latter configuration allows AUs registered
   with an OBU to communicate with any host located in the Internet,
   when at least one RSU connected to a network infrastructure is
   available.

   An OBU may also be equipped with alternative wireless technologies
   for both, safety and non-safety.  For example, an OBU may also
   communicate with Internet nodes or servers via public wireless LAN
   hot spots (PHS) operated individually or by wireless Internet service
   providers.  While RSUs for Internet access are typically set up with
   a controlled process by a C2C-C key stake holder, such as road
   administrators or other public authorities, public hot spots are
   usually set up in a less controlled environment.  These two types of
   infrastructure access, RSU and PHS, also correspond to different
   applications types.  Other communication technologies, such as wide
   coverage/cellular networks (e.g.  UMTS, GPRS) do not fall in the
   scope of the C2C-CC activity.  Nevertheless, the C2C-CC aims at
   guaranteeing future system extensibility and interoperability with
   different technologies.

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











Baldessari, et al.      Expires January 15, 2009                [Page 8]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


               +--------------------+------------------+
               |                    |                  |
               |       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

   Protocol blocks are explained in the following list:

   o  Modified IEEE 802.11p: this block represents MAC and PHY layers of
      a wireless technology based upon current draft standard IEEE
      802.11p [IEEE.802-11p-d3-0] but modified for usage in Europe.  In
      Europe, allocation of dedicated frequencies around 5.9 GHz for
      safety and non-safety applications is in progress.  Expected
      communication range in line of sight is at least 500m.  This
      network interface is mandatory.

   o  IEEE 802.11a/b/g: this block represents MAC and PHY layers
      provided by one ore more IEEE 802.11a/b/g network interfaces.
      This network interface is optional but C2C-C Consortium encourages
      its installation.

   o  C2C-CC Network: this block represents the network layer protocol
      currently defined by the C2C-CC.  The protocol provides secure ad
      hoc routing and forwarding, as well as addressing, error handling,
      packet sequencing, congestion control and information
      dissemination.  The specification of this protocol is currently
      under discussion.  Only the C2C-CC Network protocol can access the
      Modified IEEE 802.11p network interface.  The C2C-CC Network
      protocol can also access the IEEE 802.11a/b/g interface.  The
      C2C-CC Network protocol offers an interface to the IPv6 protocol.
      This interface allows IPv6 headers and payload to be encapsulated
      into C2C-CC Network datagrams and sent over the Modified IEEE
      802.11p or IEEE 802.11a/b/g network interface.  The specification
      of this interface is currently under discussion.  A primary goal



Baldessari, et al.      Expires January 15, 2009                [Page 9]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


      of the C2C-CC Network layer is to provide geographic routing and
      addressing functionalities for cooperative safety applications.
      Through the mentioned interface to the IPv6 protocol, these
      functionalities are also available for IP-based applications.

   o  C2C-CC Transport: this block represents the transport layer
      protocol that is currently being defined by the C2C-CC.  This
      protocol provides a selected set of traditional transport layer
      functionalities (e.g. application data multiplexing/
      demultiplexing, connection establishment, reliability etc.).  The
      specification of this protocol is currently under discussion.

   o  C2C-CC Applications: this block represents the application layer
      protocol currently defined by the C2C-CC and concerns Active
      Safety and Traffic Efficiency Applications.

3.1.2.  IPv6 Deployment

   As described in Section 3.1.1, the C2C-CC includes IPv6 as mandatory
   part of its specified protocol architecture.  Currently, three
   methods are discussed for transmission of IPv6 headers and their
   payload:

   o  On the Modified IEEE 802.11p interface via the C2C-CC Network
      layer: in this method, IPv6 packets are tunneled in C2C-CC Network
      headers and sent using dedicated frequencies for inter-vehicle
      communications.  Since the C2C-CC Network layer provides ad hoc
      routing, from the IPv6 layer perspective other nodes (OBUs and
      RSUs) appear as attached to the same link.  The broadcast domain
      used for IPv6 multicast traffic is selected by the C2C-CC Network
      layer on a geographical basis.  The C2C-CC Network layer presents
      Ethernet-like characteristics, so that [RFC2464] can be applied.

   o  On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in
      this method, IPv6 headers are encapsulated into C2C-CC Network
      headers and sent using license-free ISM frequency bands (wireless
      LAN).  Except the network interface, this method is equivalent to
      the previous one.

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

   As a result, a C2C-CC OBU has at least two IPv6 network interfaces, a
   real one (IEEE 802.11a/b/g) and a virtual one (tunnel over C2C-CC
   Network layer).  The following informational list briefly summarizes
   some currently discussed design concepts:





Baldessari, et al.      Expires January 15, 2009               [Page 10]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   o  in order to avoid address resolution procedures, vehicles only use
      IPv6 addresses with as host part an EUI-64 identifier derived from
      the MAC address.  Privacy issues described in [RFC3041] are
      strongly alleviated through the use of temporary, changing MAC
      addresses, which are assigned in a set to every vehicle;

   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).

   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;

   o  RSUs can either act as IPv6 Access Routers or as bridges connected
      to external IPv6 Access Routers.  Different Access Routers are
      responsible for announcing different network prefixes with global
      validity.  As a consequence, when roaming between different Access
      Routers, vehicles experience layer 3 handovers.

   When infrastructure access via RSUs is available, IPv6 support in
   C2C-CC systems is enhanced with Mobility Support.  As a vehicle
   includes a set of attached devices (AUs), NEMO Basic Support is the
   default protocol selected by the C2C-CC for maintaining ongoing
   sessions during L3 handovers.

3.1.3.  Scope of NEMO

   The C2C-CC is defining a protocol stack for both safety and non-
   safety applications.  These two application categories put different
   requirements on the protocol stack.  Therefore the C2C-CC defined a
   double protocol stack which is depicted in Figure 2.  Applications
   that are subject to safety requirements use the left part, whereas
   applications that do not require these particular features use the
   right part of the stack.  The left part of the stack provides
   functionalities like geographic packet distribution, information
   dissemination according to relevance, information aggregation using
   cross-layer analysis, security and plausibility checks at different
   protocol layers.  The right part of the stack is designed for non-



Baldessari, et al.      Expires January 15, 2009               [Page 11]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   safety applications and for non-critical applications, which can
   still support safety.

   The deployment of NEMO in C2C-CC systems is achieved through the
   right part of the stack depicted in Figure 2 and targets non-safety
   applications.  Nevertheless, applications using NEMO might indirectly
   support safety applications.  Example use cases are listed in
   Section 4.

3.2.  ISO TC204 WG 16 (CALM)

   ISO TC 204 WG 16 (CALM) is working on "Wide Area Communications
   Protocols and Interfaces" and was established in year 2000.  The WG
   is itself devided into a number of sub-groups.  The purpose of this
   WG is specifying a protocol architecture from the physical layer up
   to the application layer and designed for all ITS types of
   communications media.

   The CALM handbook [calm-handbook] gives an overview of the system and
   protocol architecture.  In essence, this document defines a protocol
   stack that offers specialized functionalities and interfaces to
   safety and non-safety applications and does not rely on a specific
   communication technology.  This protocol stack allows for both IP and
   non-IP types of communications.  The IP version 6 is the version
   considered for IP types of flows.

3.2.1.  System and Protocol Architecture

   Vehicles are equipped with networks logically composed of an
   (potentially multiple) OBU(s) and potentially multiple AUs.  An AU is
   typically a dedicated device that executes a single or a set of
   applications and utilizes the OBU communication capabilities.  An AU
   can be an integrated part of a vehicle and be permanently connected
   to an OBU.  It can also be a portable device such as laptop, PDA or
   game pad that can dynamically attach to (and detach from) an OBU.  AU
   and OBU are usually connected with wired connection, but the
   connection can also be wireless, such as Bluetooth.  The distinction
   between AU and OBU is logical, they can also reside in a single
   physical unit.

   Vehicles' OBUs and stationary units along the road, termed road-side
   units (RSUs), form a self-organizing network.  An OBU is equipped
   with a number of short range, medium range and long range wireless
   communication devices, typically IEEE 802.11p [IEEE.802-11p-d3-0],
   IEEE 802.11a/b/g or 3G. OBUs can communicate with one another, either
   directly if wireless connectivity exist among them, or via multi-hop
   communication where data is forwarded from one OBU to another until
   it reaches its destination, or through the roadside infrastrucure, or



Baldessari, et al.      Expires January 15, 2009               [Page 12]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   through the Internet.

   The primary role of an RSU is improvement of road safety and road
   traffic.  RSUs have two possible configuration modes: as isolated
   nodes, they execute applications and/or extend the coverage of the ad
   hoc network implementing routing functionalities.  As attachment
   point connected to an infrastructure network, RSUs distribute
   information originated in the infrastructure and offer connectivity
   to the vehicles.  As result, for example, the latter configuration
   allows AUs registered with an OBU to communicate with any host
   located in the Internet, when at least one RSU connected to a network
   infrastructure is available.

   An OBU is equipped with alternative wireless technologies for both
   safety and non-safety applications.  For example, an OBU may also
   communicate with Internet nodes or servers via public wireless LAN
   hot spots (PHS) or wide coverage/cellular networks (e.g.  UMTS, GPRS)
   operated individually or by wireless Internet service providers.
   While RSUs for Internet access are typically set up with a controlled
   process by a CALM key stake holder, such as road administrators or
   other public authorities, public hot spots are usually set up in a
   less controlled environment.  These two types of infrastructure
   access, RSU and PHS, also correspond to different applications types.
   Other communication technologies not currently available or de facto
   considered in the CALM architecture may be added at will.

   In Figure 3, RSU and OBU1 have direct connectivity, whereas OBU2 is
   out of RSU radio coverage but can communicate with it through multi-
   hop routing or through the Internet.






















Baldessari, et al.      Expires January 15, 2009               [Page 13]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


                        |       Internet        |
                        |                       |
                        +---+-----------------+-+
                            |                 |
                 Access  +--+-+            +--+-+  Access
                 Router  | AR |            | AR |  Router
                         +--+-+            +--+-+
                            |                 |
                      --+---+---            --+---+--
                        |                         |
         Road Side   +--+--+                   +--+--+   Public
           Unit      | RSU |                   | PHS |  Hot Spot
                     +---+-+                   +---+-+
                         |                         |
                        /\                        /\

                        \_                         \_
                          \_                         \_
                            \                          \

            Optional          \/  \/
 IEEE 802.11a/b/g and 802.11p  |   |     __             \/  Optional IEEE
     Interfaces            +--+---+--+     \__    \/     |   802.11a/b/g and 3G
                           |  OBU1   |             |     |    Interfaces
                           +--+---+--+           +-+-----+---+
                    Vehicle1  |                  |   OBU2    |  On-Board
                         -+---+-+-               +--+--------+    Unit
                          |     |                   | Vehicle2
       Application    +--+-+ +-+--+           --+--+--
          Units       | AU | | AU |             |
                      +----+ +----+           +-+--+
                                              | AU |
                                              +----+

                      Figure 3: ISO's CALM scenarios

   CALM allows all communication modes:

   o  in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged
      directly between OBUs, either via multi-hop or not, without
      involving any RSU;

   o  in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data
      packets through a RSU with an arbitrary node connected to the
      infrastructure (potentially another vehicle not attached to the
      same RSU).





Baldessari, et al.      Expires January 15, 2009               [Page 14]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   o  in Vehicle-to-Infrastructure-to-Vehicle mode (V2I2V), an OBU
      exchanges data packets with another OBU through an arbitrary node
      in the infrastructure or the Internet;

   o  in Vehicle-to-Internet mode (Internet), an OBU exchanges data
      packets with an an arbitrary node in the Internet.

   The current draft reference CALM architecture is specified in
   [ISO-21217-CALM-Architecture] whereas the IPv6 networking specific
   parts are specified in [ISO-21210-CALM-IPv6-Networking].  A
   simplified description of the CALM Reference Architecture protocol
   stack currently specified by ISO for OBUs/MRs is depicted in
   Figure 4.

   +---------------+--------------------+----------------------+
   |               |                    |                      |
   | Non-IP        | IPv6               | IPv6                 |
   | CALM Aware    | CALM-Aware         | Legacy               |
   | Applications  | Applications       | Applications         |
   |               |                    |                      |
   +---------------+--------------------+----------------------+
   |               |                                           |
   |               |            TCP/UDP/...                    |
   |               |                                           |
   +               +--+----------------------------------------+
   |                  |                                        |
   |    CALM FAST     |                  IPv6                  |
   |                  |                                        |
   +------------------+---+------------------+-------+------+--+
   | ModifiedIEEE 802.11p |  Standard WLAN   | 2G/3G | CALM |..|
   | M5/WAVE/DSRC         | IEEE 802.11a/b/g | GSM   | IR   |..|
   +----------------------+------------------+-------+------+--+

                 Figure 4: CALM Protocol Stack for OBU/MR

   Protocol blocks are explained in the following list:

   o  M5, WAVE and DSRC are IEEE 802.11p variants, in Europe, USA and
      Japan, respectivelty: this block represents MAC and PHY layers of
      a wireless technology based upon current draft standard IEEE
      802.11p [IEEE.802-11p-d3-0] but modified for usage in Europe.  In
      Europe, allocation of dedicated frequencies around 5.9 GHz for
      safety and non-safety applications is in progress.  Expected
      communication range in line of sight is around 500m.

   o  IEEE 802.11a/b/g: this block represents MAC and PHY layers
      provided by one ore more IEEE 802.11a/b/g network interfaces.




Baldessari, et al.      Expires January 15, 2009               [Page 15]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   o  IPv6: this block represents the IPv6-based network layer protocol
      currently defined by ISO.  The specification of this layer is
      currently under discussion.  Several scenarios are proposed, one
      for IP communications without mobility management, one for IP
      communications with host-mobility management (MIPv6), and one with
      IP communications with network mobility management (NEMO).  The
      former two are out of scope of the present document.  This block
      comprises the NME (Network Management Entity) which is able to
      interoperate with other layers in order to negociate priority flow
      requirements

   o  CALM FAST: this block represents a network protocol specifically
      designed by ISO TC204 WG16 for time critical safety applications
      and running exclusively over IEEE 802.11p.  Both non-IP and IPv6
      CALM Aware applications may use CALM FAST.  Non-IP applications
      uses it directly as the tranport.

   o  CALM Aware Applications (IPv6 and non-IP): this block represents
      specifically designed ITS applications.  CALM Aware applications
      are ranged into IP and non IP applications.  This block comprises
      the CME (CALM Management Entity) which is able to interoperate
      with lower layers in order to negociate priority flow
      requirements.  Non-IP applications uses CALM FAst as the tranport

3.2.2.  IPv6 Deployment

   The CALM architecture includes IPv6 as mandatory part of its
   specified protocol architecture.

   The following informational list briefly summarizes currently
   discussed design concepts:

   o  in order to avoid address resolution procedures, vehicles use only
      IPv6 addresses with as host part an EUI-64 identifier derived from
      the MAC address.  Privacy issues described in [RFC3041] are
      strongly alleviated through the use of temporary, changing MAC
      addresses, which are assigned in a set to every vehicle (as part
      of their assigned "pseudonyms");

   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).  In addition, a



Baldessari, et al.      Expires January 15, 2009               [Page 16]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


      self-generated IPv6 address with as prefix part a pre-defined IPv6
      prefix (either reserved for ISO CALM communications or a general
      purpose one) may be used for ad-hoc communications with other
      OBUs;

   o  RSUs can either act as IPv6 Access Routers or as bridges connected
      to external IPv6 Access Routers.  Different Access Routers are
      responsible for announcing different network prefixes with global
      validity.  As a consequence, when roaming between different Access
      Routers, vehicles experience layer 3 handovers.

3.2.3.  Scope of NEMO

   In all the methods for use of IPv6 in the CALM architecture as
   described above, the IPv6 layer is meant to be enhanced with Mobility
   Support.  As a vehicle includes a set of attached devices (AUs), NEMO
   Basic Support is the default protocol selected by ISO for maintaining
   ongoing sessions during L3 handovers.


4.  NEMO Example Use Cases

   In this section, the main use cases are listed that have been
   identified by the C2C-CC and ISO for usage of NEMO: notification
   services, peer-to-peer applications, upload/download services,
   navigation services, multimedia applications.

4.1.  Notification Services

   A generic notification service delivers information to subscribers by
   means of the Internet.  After subscribing the service with a
   provider, a user is notified when updates are available.  Example
   services are weather, traffic or news reports, as well as commercial
   and technical information from the car producer or other companies.

   In this use case, a pre-defined address belonging to the MNP is
   registered to the service provider.  The service provider sends the
   updates to this address which does not change while the vehicle
   changes point of attachment.

4.2.  Peer-to-peer Applications

   A generic peer-to-peer application exchanges data directly between
   vehicles, without contacting any application server.  Data traffic
   goes through a network infrastructure (V2I) or directly between cars
   when the infrastructure is not available (V2V).  Example applications
   are vehicle-to-vehicle instant messaging (chat) and off-line
   messaging (peer-to-peer email), vehicle-to-vehicle voice over IP and



Baldessari, et al.      Expires January 15, 2009               [Page 17]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   file exchange.

4.3.  Upload and Download Services

   A generic upload/download service via the Internet consists in simple
   file exchange procedures with servers located in the Internet.  The
   service is able to resume after a loss of connectivity.

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.

4.5.  Infotainment Applications

   TBD by ISO CALM

4.6.  Navigation Services

   TBD by ISO CALM


5.  NEMO Route Optimization Scenarios

   In this section, operational characteristics of automotive
   deployments of NEMO are described that are relevant for the design of
   Route Optimization techniques.  In particular a restriction of the
   general solution space for RO and motivations for RO requirements
   described in Section 6 are provided.

   With respect to the classification of NEMO Route Optimization
   scenarios described in [RFC4889], the non-nested NEMO RO case
   (Section 3.1) is considered as the most important for the automotive
   deployment.  However, MIPv6-enabled AUs (i.e.  VMNs) and nested NEMOs
   are allowed in ISO CALM but not specifically addressed in the
   specifications.

   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.




Baldessari, et al.      Expires January 15, 2009               [Page 18]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   2.  A dedicated node (host or router) installed on the roadside (2a)
       or in the Internet (2b) for automotive applications.

   3.  An arbitrary node in the Internet.

   In cases 1 and 2, the CE is a newly deployed entity.  Whereas the
   communicating peers in case 1 are obvious, case 2 includes for
   example information points installed along the road, control centers,
   notification points and infotainment service providers located in the
   infrastructure.

   The suboptimal routing due to the lack of RO has the most negative
   impact when the topological distance between MR and CE is
   considerably smaller than between MR and HA.  This is highly likely
   to occour in case 1 (e.g. two neighboring vehicles communicating with
   each others) and case 2a (e.g. vehicles receiving updates from
   information points installed on the roadside).  For these two cases,
   the suboptimal routing might represent a limiting factor for the
   system performance and, in turn, a limiting factor for the deployment
   of NEMO.

   In cases 2b and 3, the impact of suboptimal routing depends on the
   arbitrary CE topological position.  At this point of time no
   particular assumption can be made on the topological position of CE
   in case 2b and, obviously, in case 3.  Consequently, the case 1 and
   2a deserve a higher priority with respect to the definition of a NEMO
   RO solution for automotive applications.

   Any available information about the geographical or topological
   position of the CE is relevant for the MR in order to apply RO.  In
   this respect, external information might be used to define policy
   rules specifying whether or not RO should be enabled with a
   particular pre-defined CE, which is known in advanced to the MR.


6.  NEMO Route Optimization Requirements

   Figure 5 summarizes which requirement applies to both C2C-CC and ISO,
   or only one of these.

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.




Baldessari, et al.      Expires January 15, 2009               [Page 19]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   In some scenarios it might not be beneficial to activate RO due to
   the intermittent connectivity.  Based on external information, a
   management instance of the MR can dynamically specify policies for RO
   establishment of a particular IPv6 flow.  Furthermore, policies can
   prevent unnecessary or unwanted RO sessions to take place (e.g.  DNS
   queries, location privacy protection, etc.).  In case of MRs serving
   multiple MNPs (e.g. served by different HAs or MNPs that vary only in
   the length), the policies allow for specifying for which MNP RO
   should be established (i.e. prefix including length).

6.2.  Req 2 - RO Security

   This requirements consists of the following sub-requirements:

   o  The RO scheme MUST permit the receiver of a BU to validate an MR's
      ownership of the CoAs claimed by an MR.

   o  The RO scheme MUST ensure that only explicitly authorized MRs are
      able to perform a binding update for a specific MNP.

   o  If the RO scheme makes use of cryptographic material, this SHOULD
      be the same material already installed on vehicles as defined by
      automotive consortia.

6.3.  Req 3 - Binding Privacy Protection

   An RO technique MUST protect the MR's binding privacy against on-path
   nodes' attacks.

   In other words, the RO technique must not expose the content of the
   binding (CoA, MNP/HoA) to nodes other than the intended CEs.  The
   rationale behind this requirement is the fact that mechanisms that
   are being designed by the automotive industry for privacy protection
   might be made ineffective if the content of the binding is revealed.
   In fact, a common approach in automotive applications consists of
   equipping a vehicle with a set of CoAs to be used for limited time
   intervals.  Consecutive binding updates, where the MNP/HoA is
   constant and transmitted as clear text, could be used to unveal the
   user's identity by linking together the different addresses.

6.4.  Req 4 - Multihoming

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

   Adopting the classification of [RFC4980], the automotive NEMO
   deployment includes at least the cases (1,n,n), (n,1,1) and (n,n,n).



Baldessari, et al.      Expires January 15, 2009               [Page 20]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   Case (1,n,n) takes place when a single MR is installed in the
   vehicle's OBU but different MNPs/HAs are used for different purposes
   (e.g. vehicle monitoring, traffic information, infotainment) or to
   achieve better fault tolerance.  Cases (n,1,1) and (n,n,n) take place
   when the vehicle's connectivity is enhanced by installing additional
   NEMO MRs in a separated unit in a later stage.  An RO technique must
   not prevent any of these three configurations from working properly.

6.5.  Req 5 - Minimum Signaling

   An RO technique MUST be capable of minimum signaling.  The number of
   per-flow signaling messages for the establishment of RO SHOULD be
   smaller than TBD and the number of per-flow signaling messages upon a
   layer 3 handover should be smaller than TBD.

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.

   A vehicle is typically served by various network access operators,
   simultaneously, and over a period of time depending on its
   geographical location.  Since Internet services providers providing
   the HA servive and the MNP may be topologically distant from the OBU,
   multiple HAs belonging to the same Internet service operator might be
   deployed in order to decrease transmission delays.  In such a case
   the RO solution shall allow the OBU to select the best HA according
   to its location and to switch from one HA to another HA.

               +====================================================+
               |                                | C2C-CC | ISO CALM |
               +====================================================+
               | #1: Separability               |    x   |     x    |
               +--------------------------------+--------+----------+
               | #2: RO Security                |    x   |     x    |
               +--------------------------------+--------+----------+
               | #3: Privacy Protection         |    x   |     x    |
               +--------------------------------+--------+----------+
               | #4: Multihoming                |    x   |     x    |
               +--------------------------------+--------+----------+
               | #5: Efficient Signaling        |    x   |     x    |
               +--------------------------------+--------+----------+
               | #6: Switching HAs              |        |     x    |
               +====================================================+

                Figure 5: C2C-CC and ISO CALM requirements





Baldessari, et al.      Expires January 15, 2009               [Page 21]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


7.  IANA Considerations

   This document does not require any IANA action.


8.  Security Considerations

   This document does not specify any protocol therefore does not create
   any security threat.  However, it specifies requirements for a
   protocol that include security and privacy issues.


9.  Acknowledgments

   The authors would like to thank the members of TC204 WG16 and the
   work groups PHY/MAC/NET and APP of the C2C-C Consortium.  The authors
   particularly appreciated the helpful support of Carlos Bernardos
   Cano, Tim Leinmueller, Bernd Bochow, Andras Kovacs and Matthias
   Roeckl.


10.  References

10.1.  Normative References

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

10.2.  Informative References

   [RFC4888]  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network
              Mobility Route Optimization Problem Statement", July 2007.

   [RFC4889]  Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
              Mobility Route Optimization Solution Space Analysis",
              July 2007.




Baldessari, et al.      Expires January 15, 2009               [Page 22]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


   [RFC4885]  Ernst, T. and H-Y. Lach, "Network Mobility Support
              Terminology", RFC 4885, July 2007.

   [RFC4980]  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
              Multihoming in Network Mobility Support", RFC 4980,
              October 2007.

   [I-D.ietf-mext-aero-reqs]
              Eddy, W., Ivancic, W., and T. Davis, "NEMO Route
              Optimization Requirements for Operational Use in
              Aeronautics and  Space Exploration Mobile Networks",
              draft-ietf-mext-aero-reqs-02 (work in progress), May 2008.

   [c2ccc-web]
              "Car2Car Communication Consortium Official Website",
              http://www.car-2-car.org/ .

   [c2ccc-manifesto]
              "Car2Car Communication Consortium Manifesto",
              http://www.car-2-car.org/index.php?id=570 , May 2007.

   [calm-handbook]
              "The CALM Handbook", http://www.calm.hu , May 2005.

   [ISO-21210-CALM-IPv6-Networking]
              "Intelligent Transport Systems - Continuous air interface,
              long and medium range (CALM) - Networking Protocols", ISO
              Draft DIS 21210, February 2008.

   [ISO-21217-CALM-Architecture]
              "Intelligent Transport Systems - Communications access for
              land mobiles (CALM) - Architecture", ISO Draft DIS 21217,
              June 2008.

   [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.









Baldessari, et al.      Expires January 15, 2009               [Page 23]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


Authors' Addresses

   Roberto Baldessari
   NEC Europe Network Laboratories
   Kurfuersten-anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342167
   Email: roberto.baldessari@nw.neclab.eu


   Thierry Ernst
   INRIA
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153
   France

   Phone: +33-1-39-63-59-30
   Fax:   +33-1-39-63-54-91
   Email: thierry.ernst@inria.fr
   URI:   http://www.nautilus6.org/~thierry


   Andreas Festag
   NEC Deutschland GmbH
   Kurfuersten-anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342147
   Email: andreas.festag@nw.neclab.eu


   Massimiliano Lenardi
   Hitachi Europe SAS Sophia Antipolis Laboratory
   Immeuble Le Theleme
   1503 Route des Dolines
   Valbonne  F-06560
   France

   Phone: +33 489 874168
   Email: massimiliano.lenardi@hitachi-eu.com







Baldessari, et al.      Expires January 15, 2009               [Page 24]


Internet-Draft       Automotive NEMO RO Requirements           July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Baldessari, et al.      Expires January 15, 2009               [Page 25]