MEXT R. Baldessari
Internet-Draft NEC Europe
Intended status: Informational T. Ernst
Expires: July 19, 2009 INRIA
A. Festag
NEC Germany
M. Lenardi
Hitachi Europe
January 15, 2009
Automotive Industry Requirements for NEMO Route Optimization
draft-ietf-mext-nemo-ro-automotive-req-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 19, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Baldessari, et al. Expires July 19, 2009 [Page 1]
Internet-Draft Automotive NEMO RO Requirements January 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). 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.
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 . . . . . . . . . . . . . . . . . . . 9
3.1.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 10
3.2. ISO TC204 WG 16 (CALM) . . . . . . . . . . . . . . . . . . 11
3.2.1. System and Protocol Architecture . . . . . . . . . . . 11
3.2.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 15
3.2.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 16
3.3. ETSI TC ITS . . . . . . . . . . . . . . . . . . . . . . . 16
4. NEMO Example Use Cases . . . . . . . . . . . . . . . . . . . . 17
4.1. Notification Services . . . . . . . . . . . . . . . . . . 17
4.2. Peer-to-peer Applications . . . . . . . . . . . . . . . . 17
4.3. Upload and Download Services . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . . . 24
Baldessari, et al. Expires July 19, 2009 [Page 2]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 July 19, 2009 [Page 3]
Internet-Draft Automotive NEMO RO Requirements January 2009
architecture from the physical layer up to the application layer
and designed for all ITS types of communications (vehicle-vehicle,
vehicle-infrastructure, infrastructure-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 July 19, 2009 [Page 4]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 of (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 traversing multiple vehicles, 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 provides recommendations to the
newly established ETSI TC ITS, described in Section 3.3.
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
functionalities and interfaces to (primarily) safety-oriented
Baldessari, et al. Expires July 19, 2009 [Page 5]
Internet-Draft Automotive NEMO RO Requirements January 2009
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.
| 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 |
+----+
Baldessari, et al. Expires July 19, 2009 [Page 6]
Internet-Draft Automotive NEMO RO Requirements January 2009
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
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, vehicles can be used
as relays, 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, as OBU1 acts as packet relay.
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
Baldessari, et al. Expires July 19, 2009 [Page 7]
Internet-Draft Automotive NEMO RO Requirements January 2009
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.
+--------------------+------------------+
| | |
| 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
Baldessari, et al. Expires July 19, 2009 [Page 8]
Internet-Draft Automotive NEMO RO Requirements January 2009
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
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.
Baldessari, et al. Expires July 19, 2009 [Page 9]
Internet-Draft Automotive NEMO RO Requirements January 2009
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:
o in order to avoid address resolution procedures, vehicles only use
IPv6 addresses with as Interface Identifier 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
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).
o for V2V communication, i.e. when no infrastructure is available,
OBUs can use link-local addresses. As described above, a portion
of the VANET (geographically or topologically scoped), spanning
beyond the vehicle's physical communication range, is presented to
IPv6 as a single, link-local multicast capable logical link.
Therefore, IPv6 packets can traverse multiple physical hops
without having the Hop Limit decremented, as they do not leave the
logical link;
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
Baldessari, et al. Expires July 19, 2009 [Page 10]
Internet-Draft Automotive NEMO RO Requirements January 2009
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-
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 divided 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 datagrams.
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.
Baldessari, et al. Expires July 19, 2009 [Page 11]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 exists among them, or via vehicles
acting as relays, where data is forwarded from one OBU to another
until it reaches its destination, or through the roadside
infrastructure, or 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 July 19, 2009 [Page 12]
Internet-Draft Automotive NEMO RO Requirements January 2009
| 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 July 19, 2009 [Page 13]
Internet-Draft Automotive NEMO RO Requirements January 2009
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, respectively: 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 July 19, 2009 [Page 14]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 negotiate 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 negotiate priority flow
requirements. Non-IP applications uses CALM FAst as the transport
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 Interface Identifier 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
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
Baldessari, et al. Expires July 19, 2009 [Page 15]
Internet-Draft Automotive NEMO RO Requirements January 2009
as the NEMO Home Address (HoA). In addition, a 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.
3.3. ETSI TC ITS
The European Telecommunications Standards Institute (ETSI) Technical
Committee (TC) Intelligent Transport Systems (ITS) was established in
October 2007 with the goal of developing and maintaining standards,
specifications and other deliverables to support the development and
the implementation of ITS service provision. ETSI TC ITS has been
identified by European industries and institutions as the reference
standardization body for the development of European ITS standards.
To date, a formal mandate from the European Commission to ETSI TC ITS
to develop European ITS standards has not been approved and is still
under discussion.
ETSI TC ITS is going to develop standards and profiles of existing
standards based on the requirements and recommendations of the
aforementioned Car2Car Communication Consortium, ISO TC 204 WG 16
(CALM) and the results of various European research projects. To
date no ETSI TC ITS standard draft is publicly available, nor can be
made available via liaisons.
ETSI TC ITS is expected to harmonize the system and protocol
architectures described above. Among others, ETSI TC ITS will
produce standards defining the communication architecture
[ETSI-TS-102-665], an European profile standard for 802.11p
[ETSI-ES-202-663], a networking layer providing geographic addressing
and forwarding, the way IPv6 packets can be transported by this
geographic networking layer. More interaction between ETSI TC ITS
and the IETF is expected in the near future especially with respect
to the last item.
Baldessari, et al. Expires July 19, 2009 [Page 16]
Internet-Draft Automotive NEMO RO Requirements January 2009
It is expected that in a following version of this draft sections
Section 3.1 and Section 3.2 will be merged based on the architecture
defined by ETSI TC ITS, which is not available to date. The
requirements defined in this document are to be considered valid for
ETSI TC ITS deployments too, as they have been agreed by the two main
contributors to ETSI TC ITS. As an informational reference, the
European project COMeSafety has produced a draft architecture
description which is being used as basis for the ETSI TC ITS
architecture [COMeSafety-Arch-2.0].
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
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.
Baldessari, et al. Expires July 19, 2009 [Page 17]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 and application servers 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.
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
Baldessari, et al. Expires July 19, 2009 [Page 18]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 occur 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.
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. In this document, the term
flow is not referred to the Flow Label field defined in [RFC2460] but
more generically to refer to an exchange of IPv6 packets between two
particular end points. No special requirements is define regarding a
Baldessari, et al. Expires July 19, 2009 [Page 19]
Internet-Draft Automotive NEMO RO Requirements January 2009
finer distinction of flows. The policies mentioned in this
requirement 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 unveil 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).
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
Baldessari, et al. Expires July 19, 2009 [Page 20]
Internet-Draft Automotive NEMO RO Requirements January 2009
(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 service 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 July 19, 2009 [Page 21]
Internet-Draft Automotive NEMO RO Requirements January 2009
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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, 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
Baldessari, et al. Expires July 19, 2009 [Page 22]
Internet-Draft Automotive NEMO RO Requirements January 2009
Mobility Route Optimization Solution Space Analysis",
July 2007.
[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/fileadmin/downloads/
C2C-CC_manifesto_v1.1.pdf , 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) - IPv6 Networking", ISO
Draft DIS 21210, February 2009.
[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.
[ETSI-TS-102-665]
Baldessari, et al. Expires July 19, 2009 [Page 23]
Internet-Draft Automotive NEMO RO Requirements January 2009
"ETSI TS 102 665 - Intelligent Transport Systems (ITS);
Vehicular Communications; Architecture", ETSI TC ITS
Draft (work in progress), January 2009.
[ETSI-ES-202-663]
"ETSI ES 202 663 - Intelligent Transport Systems; European
profile standard on the physical and medium access layer
of 5 GHz ITS", ETSI TC ITS Draft (work in progress),
January 2009.
[COMeSafety-Arch-2.0]
"European ITS Communication Architecture Overall Framework
Proof of Concept Implementation - Version 2.0", http://
www.comesafety.org/fileadmin/uploads/architecture/
COMeSafety_European_Communications_Architecture.pdf (work
in progress), October 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
Baldessari, et al. Expires July 19, 2009 [Page 24]
Internet-Draft Automotive NEMO RO Requirements January 2009
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 July 19, 2009 [Page 25]
