MEXT R. Baldessari Internet-Draft NEC Europe Intended status: Informational T. Ernst Expires: August 21, 2008 INRIA A. Festag NEC Germany M. Lenardi Hitachi Europe February 18, 2008 Automotive Industry Requirements for NEMO Route Optimization draft-ietf-mext-nemo-ro-automotive-req-00 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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 Baldessari, et al. Expires August 21, 2008 [Page 1] Internet-Draft Automotive NEMO RO Requirements February 2008 Technical Committee 204 Working Group 16 (CALM). 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. 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. Infortainment 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 - Privacy Protection . . . . . . . . . . . . . . . . 20 6.4. Req 4 - Multihoming . . . . . . . . . . . . . . . . . . . 20 6.5. Req 5 - Efficient Signaling . . . . . . . . . . . . . . . 20 6.6. Req 6 - Switching HA . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Baldessari, et al. Expires August 21, 2008 [Page 2] Internet-Draft Automotive NEMO RO Requirements February 2008 1. Introduction NEMO Basic Support [1] 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 ([5], [6] and [9]) 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 [10] 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 architecture from the physical layer up to the application layer Baldessari, et al. Expires August 21, 2008 [Page 3] Internet-Draft Automotive NEMO RO Requirements February 2008 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 [7]: 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) The following new terms are used in this document: o On Board Unit (OBU): a device installed in vehicles, implementing the communication protocols and algorithm and equipped with at least 1) a short-range wireless network interface operating at dedicated frequencies and 2) a wireless or wired network interface 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. Baldessari, et al. Expires August 21, 2008 [Page 4] Internet-Draft Automotive NEMO RO Requirements February 2008 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. o Vehicle-to-Infrastructure-to-Vehicle (V2I2V) Communication Mode: a generic communication mode in which data packets are exchanged between two vehicles, by means of multi-hop routing involving a RSU connected or not to a network infrastructure. From the point of view of the communication and routing protocol, this mode is equivalent to V2V, as RSUs act as relay in the same way OBUs do. Nevertheless introducing this definition is beneficial from a functional point of view. 3. NEMO Automotive Deployments 3.1. Car2Car Communication Consortium The Car2Car Communication Consortium (C2C-CC [10]) 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). Baldessari, et al. Expires August 21, 2008 [Page 5] Internet-Draft Automotive NEMO RO Requirements February 2008 The consortium's Manifesto [11] 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 applications and relies as a communication technology on a modified version of IEEE 802.11p [14]. 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 August 21, 2008 [Page 6] Internet-Draft Automotive NEMO RO Requirements February 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 August 21, 2008 [Page 7] Internet-Draft Automotive NEMO RO Requirements February 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 [14] (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 August 21, 2008 [Page 8] Internet-Draft Automotive NEMO RO Requirements February 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 [14] 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 August 21, 2008 [Page 9] Internet-Draft Automotive NEMO RO Requirements February 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 headers are encapsulated into 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 RSU) 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 [4] 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 August 21, 2008 [Page 10] Internet-Draft Automotive NEMO RO Requirements February 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 [3] 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). In addition, a self-generated IPv6 address with as prefix part a pre-defined IPv6 prefix (either reserved for C2C-CC 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. 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- safety applications and for non-critical applications, which can still support safety. Baldessari, et al. Expires August 21, 2008 [Page 11] Internet-Draft Automotive NEMO RO Requirements February 2008 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 [12] 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 doesn't 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 The current draft reference CALM architecture [13] is shown in Figure 3. Baldessari, et al. Expires August 21, 2008 [Page 12] Internet-Draft Automotive NEMO RO Requirements February 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 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 August 21, 2008 [Page 13] Internet-Draft Automotive NEMO RO Requirements February 2008 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 [14], IEEE 802.11a/b/g or 3G. OBUs can communicate with one another, either directly if wireless connectivity exist among them, via multi-hop communication where data is forwarded from one OBU to another, until it reaches its destination, through the roadside infrastrucure, or through the Internet. For example 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. 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 technology not currently available or de facto considered in the CALM architecture may be added at will. 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 August 21, 2008 [Page 14] Internet-Draft Automotive NEMO RO Requirements February 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 CALM protocol stack considered by ISO is depicted in Figure 4. +--------------------+--------------------+-----------------+ | | | | | Non-IP CALM Aware | IP-based CALM | IP-based Legacy | | Aware Applications | Aware Applications | Applications | | | | | + +---------+--------------------+-----------------+ | | | | | TCP/UDP/... | | | | + +------------------------------------------------+ | | | | | CALM IPv6 | | | | +----------------+------------------+-------+---------+-----+ | IEEE 802.11p | Standard WLAN | 2G/3G | CALM IR | ... | | M5/WAVE/DSRC | IEEE 802.11a/b/g | GSM | | ... | +----------------+------------------+-------+---------+-----+ Figure 4: CALM Reference Architecture 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 [14] 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. o CALM IPv6 Network: 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 Baldessari, et al. Expires August 21, 2008 [Page 15] Internet-Draft Automotive NEMO RO Requirements February 2008 (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 Aware Applications: 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. 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 [3] 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 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. Baldessari, et al. Expires August 21, 2008 [Page 16] Internet-Draft Automotive NEMO RO Requirements February 2008 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. 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, the HoA or 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 V2I2V) 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. The C2C-CC also considers this use case when vehicles are isolated from the infrastructure, i.e. V2V mode. As the NEMO protocol is not involved when infrastructure access is not available, this particular case is out of scope of this document. 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 Baldessari, et al. Expires August 21, 2008 [Page 17] Internet-Draft Automotive NEMO RO Requirements February 2008 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 the OBU and sent 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. Infortainment 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 [6], 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 Network Mobility are allowed in ISO CALM but not specifically addressed. 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 August 21, 2008 [Page 18] Internet-Draft Automotive NEMO RO Requirements February 2008 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 Table Figure 5 summarizes which requirement applies to both C2C-CC and ISO, or only one of these. 6.1. Req 1 - Separability A 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. 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 Baldessari, et al. Expires August 21, 2008 [Page 19] Internet-Draft Automotive NEMO RO Requirements February 2008 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 As a minimum security feature, an RO technique MUST prevent off-path malicious nodes to claim false MNP ownership. Further security requirements are TBD. As a minimum requirement, the security level of a RO scheme should be comparable with today's Internet. 6.3. Req 3 - Privacy Protection A RO technique MUST NOT allow off-path malicious nodes to match the MR's CoA with its MNP or HoA. In other words, the RO technique must not expose the MNP/HoA to nodes other than the CE and, indirectly, the nodes on the path between the MR and the CE. 6.4. Req 4 - Multihoming A RO technique MUST allow a MR to be simultaneously connected to multiple access networks, having multiple prefixes and Care-Of Addresses in a MONAMI6 context, and be served by multiple HAs. Adopting the classification of [8], 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 (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. A RO technique must not prevent any of these three configurations from working properly. 6.5. Req 5 - Efficient Signaling A RO technique MUST be capable of efficient 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 A RO technique MUST allow a MR to switch from one HA to another one topologically distant from the first one. Baldessari, et al. Expires August 21, 2008 [Page 20] Internet-Draft Automotive NEMO RO Requirements February 2008 +====================================================+ | | 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 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 the work groups PHY/ MAC/NET and APP of the C2C-C Consortium and in particular Tim Leinmueller, Bernd Bochow, Andras Kovacs and Matthias Roeckl. 10. References 10.1. Normative References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Baldessari, et al. Expires August 21, 2008 [Page 21] Internet-Draft Automotive NEMO RO Requirements February 2008 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [4] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. 10.2. Informative References [5] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", July 2007. [6] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", July 2007. [7] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [9] 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-00 (work in progress), December 2007. [10] "Car2Car Communication Consortium Official Website", http://www.car-2-car.org/ . [11] "Car2Car Communication Consortium Manifesto", http://www.car-2-car.org/index.php?id=570 , May 2007. [12] "The CALM Handbook", http://www.calm.hu , May 2005. [13] "CALM - Medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector - Networking Protocol - Complementary Element", ISO Draft ISO/WD 21210, February 2005. [14] "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 August 21, 2008 [Page 22] Internet-Draft Automotive NEMO RO Requirements February 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 August 21, 2008 [Page 23] Internet-Draft Automotive NEMO RO Requirements February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baldessari, et al. Expires August 21, 2008 [Page 24]