idnits 2.17.1 draft-ietf-mext-nemo-ro-automotive-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1062. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 828: '...establishment procedure, MUST have the...' RFC 2119 keyword, line 830: '... for the switching to RO MUST at least...' RFC 2119 keyword, line 832: '...ished. Policies MAY change dynamicall...' RFC 2119 keyword, line 846: '... an RO technique MUST prevent off-path...' RFC 2119 keyword, line 855: '... A RO technique MUST NOT allow off-pa...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 970 has weird spacing: '..., point to po...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 932, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3041 (ref. '3') (Obsoleted by RFC 4941) == Outdated reference: A later version (-04) exists of draft-ietf-mext-aero-reqs-00 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT R. Baldessari 3 Internet-Draft NEC Europe 4 Intended status: Informational T. Ernst 5 Expires: August 21, 2008 INRIA 6 A. Festag 7 NEC Germany 8 M. Lenardi 9 Hitachi Europe 10 February 18, 2008 12 Automotive Industry Requirements for NEMO Route Optimization 13 draft-ietf-mext-nemo-ro-automotive-req-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document specifies requirements for NEMO Route Optimization 47 techniques as identified by the automotive industry. Requirements 48 are gathered from the Car2Car Communication Consortium and ISO 49 Technical Committee 204 Working Group 16 (CALM). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. NEMO Automotive Deployments . . . . . . . . . . . . . . . . . 5 56 3.1. Car2Car Communication Consortium . . . . . . . . . . . . . 5 57 3.1.1. System and Protocol Architecture . . . . . . . . . . . 6 58 3.1.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 10 59 3.1.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 11 60 3.2. ISO TC204 WG 16 (CALM) . . . . . . . . . . . . . . . . . . 12 61 3.2.1. System and Protocol Architecture . . . . . . . . . . . 12 62 3.2.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 16 63 3.2.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 17 64 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 17 65 4.1. Notification Services . . . . . . . . . . . . . . . . . . 17 66 4.2. Peer-to-peer Applications . . . . . . . . . . . . . . . . 17 67 4.3. Upload and Download Services . . . . . . . . . . . . . . . 17 68 4.4. Vehicles Monitoring . . . . . . . . . . . . . . . . . . . 18 69 4.5. Infortainment Applications . . . . . . . . . . . . . . . . 18 70 4.6. Navigation Services . . . . . . . . . . . . . . . . . . . 18 71 5. NEMO Route Optimization Scenarios . . . . . . . . . . . . . . 18 72 6. NEMO Route Optimization Requirements . . . . . . . . . . . . . 19 73 6.1. Req 1 - Separability . . . . . . . . . . . . . . . . . . . 19 74 6.2. Req 2 - RO Security . . . . . . . . . . . . . . . . . . . 20 75 6.3. Req 3 - Privacy Protection . . . . . . . . . . . . . . . . 20 76 6.4. Req 4 - Multihoming . . . . . . . . . . . . . . . . . . . 20 77 6.5. Req 5 - Efficient Signaling . . . . . . . . . . . . . . . 20 78 6.6. Req 6 - Switching HA . . . . . . . . . . . . . . . . . . . 20 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Intellectual Property and Copyright Statements . . . . . . . . . . 24 88 1. Introduction 90 NEMO Basic Support [1] defines a protocol that provides IPv6 mobility 91 support for entire moving networks, where all data packets go through 92 the IPv6-in-IPv6 tunnel established between the Mobile Router (MR) 93 and the Home Agent (HA). As already pointed out in various documents 94 ([5], [6] and [9]) this can have severe consequences on the 95 communication performances, as it causes data packets to follow a 96 path that can be very far from optimal and requires a double IPv6 97 header for every packet exchanged with a Correspondent Node (CN) in 98 the Internet. Compared with a communication that uses the ideal 99 packet routing and the normal IPv6 header size, these factors result 100 in an increased delay and a reduced throughput, plus indirect 101 consequences like increased packet fragmentation and overall less 102 efficient usage of resources. 104 Various projects and consortia involving the automotive industry are 105 considering NEMO as part of their protocol stack for the provisioning 106 of session continuity and global reachability. Nevertheless, the 107 lack of standardized Route Optimization (RO) techniques allowing data 108 packets to be exchanged directly between vehicles or between vehicles 109 and hosts in the Internet is regarded as an obstacle for the actual 110 deployment of this protocol. As the definition of a general NEMO 111 Route Optimization technique is highly complex, it appears more 112 reasonable to address specific deployment requirements and design 113 more tailored, less complex schemes for Route Optimization. 115 This document gathers requirements from two bodies that are committed 116 in deploying vehicular communications including NEMO as part of their 117 protocol stacks. 119 o The Car2Car Communication Consortium [10] is an industry 120 consortium of car manufacturers and electronics suppliers 121 operating in Europe. Its mission is to establish an open European 122 industry standard for vehicular communications based on wireless 123 LAN technology. Its approach consists in considering vehicles as 124 a Vehicular ad hoc Network (VANET), where cars are equipped with 125 short-range communication devices that operate at frequencies 126 dedicated to safety and non-safety vehicular applications. 128 o ISO TC 204 WG 16 (CALM): ISO (International Standard Organization) 129 runs a number of Technical Committees. Members are nations and 130 offical participants represent their country. TC 204 is devoted 131 to Intelligent Transport Systems (ITS) and comprises a number of 132 Working Groups (16, but 12 still in operation). ISO TC 204 WG 16 133 is working on "Wide Area Communications Protocols and Interfaces" 134 and was established in year 2000. It is specifying a protocol 135 architecture from the physical layer up to the application layer 136 and designed for all ITS types of communications (vehicle-vehicle, 137 vehicle-infrastructure, infrastrutcure-vehicle). Known as the 138 CALM architecture, the acronym was initially set to mean 139 "Communications Air-interface, Long and Medium range" but was 140 renamed in 2007 to "Communication Architecture for Land Mobile". 142 The document is organized as follows: Section 2 defines terminology. 143 Section 3 overviews the technical approaches adopted by the two 144 automotive bodies to deploy NEMO. Section 4 provides a non- 145 exhaustive list of use cases of NEMO in automotive applications. 146 Section 5 introduces the RO scenario and finally Section 6 lists the 147 requirements for NEMO RO. 149 2. Terminology 151 The following terms used in this document are defined in the Network 152 Mobility Support Terminology document [7]: 154 o Mobile Network 156 o Network Mobility (NEMO) 158 o Home Agent (HA) 160 o Home Address (HoA) 162 o Mobile Router (MR) 164 o Mobile Network Prefix (MNP) 166 o Mobile Network Node (MNN) 168 o Correspondent Router (CR) 170 o Correspondent Entity (CE) 172 The following new terms are used in this document: 174 o On Board Unit (OBU): a device installed in vehicles, implementing 175 the communication protocols and algorithm and equipped with at 176 least 1) a short-range wireless network interface operating at 177 dedicated frequencies and 2) a wireless or wired network interface 178 where Application Units (AU) can be attached to. With respect to 179 the NEMO terminology, the OBU is the physical machine acting as 180 MR, 1) is used as egress interface and 2) as ingress. 182 o Application Unit (AU): a portable or built-in device connected 183 temporarily or permanently to the vehicle's OBU. It is assumed 184 that AUs support a standard TCP/IPv6 protocol stack. Devices 185 enhanced with Mobile IPv6, like hand-held user devices, also fall 186 into the definition of Application Unit. With respect to the NEMO 187 terminology, an AU is a generic MNN. 189 o Road Side Unit (RSU): a device installed along roadsides 190 implementing automotive communication protocols and algorithms. 191 RSUs can either be isolated or connected to a network 192 infrastructure. In the latter case, RSUs are attachment points 193 either acting themselves as IPv6 access routers or as bridges 194 directly connected to an access router. 196 o In-vehicle network: the wireless or wired network placed in a 197 vehicle and composed by (potentially) several AUs and one OBU. 199 o Vehicle-to-Vehicle (V2V) Communication Mode: a generic 200 communication mode in which data packets are exchanged between two 201 vehicles, either directly or by means of multi-hop routing, 202 without involving any node in the infrastructure. 204 o Vehicle-to-Infrastructure (V2I) Communication Mode: a generic 205 communication mode in which data packets sent or received by a 206 vehicle traverse a network infrastructure. 208 o Vehicle-to-Infrastructure-to-Vehicle (V2I2V) Communication Mode: a 209 generic communication mode in which data packets are exchanged 210 between two vehicles, by means of multi-hop routing involving a 211 RSU connected or not to a network infrastructure. From the point 212 of view of the communication and routing protocol, this mode is 213 equivalent to V2V, as RSUs act as relay in the same way OBUs do. 214 Nevertheless introducing this definition is beneficial from a 215 functional point of view. 217 3. NEMO Automotive Deployments 219 3.1. Car2Car Communication Consortium 221 The Car2Car Communication Consortium (C2C-CC [10]) is an industry 222 consortium of car manufacturers and electronics suppliers that 223 focuses on the definition of an European standard for vehicular 224 communication protocols. The Consortium gathers results from 225 research projects and aims at harmonizing their efforts. For the 226 standardization activity, the C2C-CC operates in cooperation with the 227 newly established ETSI TC ITS (Technical Committee Intelligent 228 Transportation System). 230 The consortium's Manifesto [11] gives an overview of the system and 231 protocol architecture, as well as of the applications on which the 232 Consortium has agreed so far. In essence, this document defines a 233 C2C-C protocol stack that offers specialized functionalities and 234 interfaces to (primarily) safety-oriented applications and relies as 235 a communication technology on a modified version of IEEE 802.11p 236 [14]. This protocol stack is placed beside a traditional TCP/IP 237 stack, based on IP version 6, which is used mainly for non-safety 238 applications or potentially by any application that is not subject to 239 strict delivery requirements, including Internet-based applications. 240 The interaction between these stacks is currently discussed and 241 briefly overviewed in this document. 243 3.1.1. System and Protocol Architecture 245 The current draft reference architecture of the C2C communication 246 system is shown in Figure 1. 248 | Internet | 249 | | 250 +---+-----------------+-+ 251 | | 252 Access +--+-+ +--+-+ Access 253 Router | AR | | AR | Router 254 +--+-+ +--+-+ 255 | | 256 --+---+--- --+---+-- 257 | | 258 Road Side +--+--+ +--+--+ Public 259 Unit | RSU | | PHS | Hot Spot 260 +---+-+ +---+-+ 261 | | 262 /\ /\ 264 \_ \_ 265 \_ \_ 266 \ \ 268 Mandatory \/ 269 Mod IEEE 802.11p | __ \/ Optional IEEE 270 Interface +---+--+ \__ \/ | 802.11a/b/g 271 | OBU1 | | | Interface 272 +--+---+ +-+-----+---+ 273 Vehicle1 | | OBU2 | On-Board 274 -+---+-+- +--+--------+ Unit 275 | | | Vehicle2 276 Application +--+-+ +-+--+ --+--+-- 277 Units | AU | | AU | | 278 +----+ +----+ +-+--+ 279 | AU | 280 +----+ 282 Figure 1: C2C-CC Reference Architecture 284 Vehicles are equipped with networks logically composed of an OBU and 285 potentially multiple AUs. An AU is typically a dedicated device that 286 executes a single or a set of applications and utilizes the OBU 287 communication capabilities. An AU can be an integrated part of a 288 vehicle and be permanently connected to an OBU. It can also be a 289 portable device such as laptop, PDA or game pad that can dynamically 290 attach to (and detach from) an OBU. AU and OBU are usually connected 291 with wired connection, but the connection can also be wireless, such 292 as Bluetooth. The distinction between AU and OBU is logical, they 293 can also reside in a single physical unit. 295 Vehicles' OBUs and stationary units along the road, termed road-side 296 units (RSUs), form a self-organizing network. An OBU is at least 297 equipped with a (short range) wireless communication device based on 298 draft standard IEEE 802.11p [14] (adapted to European conditions and 299 with specific C2C-C extensions) primarily dedicated for road safety, 300 and potentially with other optional communication devices. OBUs 301 directly communicate if wireless connectivity exist among them. In 302 case of no direct connectivity, multi-hop communication is used, 303 where data is forwarded from one OBU to another, until it reaches its 304 destination. For example in Figure 1, RSU and OBU1 have direct 305 connectivity, whereas OBU2 is out of RSU radio coverage but can 306 communicate with it through multi-hop routing. 308 The primary role of an RSU is improvement of road safety. RSUs have 309 two possible configuration modes: as isolated nodes, they execute 310 applications and/or extend the coverage of the ad hoc network 311 implementing routing functionalities. As attachment point connected 312 to an infrastructure network, RSUs distribute information originated 313 in the infrastructure and offer connectivity to the vehicles. As 314 result, for example, the latter configuration allows AUs registered 315 with an OBU to communicate with any host located in the Internet, 316 when at least one RSU connected to a network infrastructure is 317 available. 319 An OBU may also be equipped with alternative wireless technologies 320 for both, safety and non-safety. For example, an OBU may also 321 communicate with Internet nodes or servers via public wireless LAN 322 hot spots (PHS) operated individually or by wireless Internet service 323 providers. While RSUs for Internet access are typically set up with 324 a controlled process by a C2C-C key stake holder, such as road 325 administrators or other public authorities, public hot spots are 326 usually set up in a less controlled environment. These two types of 327 infrastructure access, RSU and PHS, also correspond to different 328 applications types. Other communication technologies, such as wide 329 coverage/cellular networks (e.g. UMTS, GPRS) do not fall in the 330 scope of the C2C-CC activity. Nevertheless, the C2C-CC aims at 331 guaranteeing future system extensibility and interoperability with 332 different technologies. 334 The protocol stack currently considered by the C2C-CC for OBUs is 335 depicted in Figure 2. 337 +--------------------+------------------+ 338 | | | 339 | C2C-CC | IP-based | 340 | Applications | Applications | 341 | | | 342 +--------------------+------------------+ 343 | | TCP/UDP/... | 344 | C2C-CC Transport +------------------+ 345 | | | 346 +--------------------+-----+ IPv6 | 347 | | | 348 | C2C-CC Network | | 349 | | | 350 +--------------------+-----+------------+ 351 | Modified | Standard WLAN | 352 | IEEE 802.11p | IEEE 802.11a/b/g | 353 +--------------------+------------------+ 355 Figure 2: OBU Protocol Stack 357 Protocol blocks are explained in the following list: 359 o Modified IEEE 802.11p: this block represents MAC and PHY layers of 360 a wireless technology based upon current draft standard IEEE 361 802.11p [14] but modified for usage in Europe. In Europe, 362 allocation of dedicated frequencies around 5.9 GHz for safety and 363 non-safety applications is in progress. Expected communication 364 range in line of sight is at least 500m. This network interface 365 is mandatory. 367 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 368 provided by one ore more IEEE 802.11a/b/g network interfaces. 369 This network interface is optional but C2C-C Consortium encourages 370 its installation. 372 o C2C-CC Network: this block represents the network layer protocol 373 currently defined by the C2C-CC. The protocol provides secure ad 374 hoc routing and forwarding, as well as addressing, error handling, 375 packet sequencing, congestion control and information 376 dissemination. The specification of this protocol is currently 377 under discussion. Only the C2C-CC Network protocol can access the 378 Modified IEEE 802.11p network interface. The C2C-CC Network 379 protocol can also access the IEEE 802.11a/b/g interface. The 380 C2C-CC Network protocol offers an interface to the IPv6 protocol. 381 This interface allows IPv6 headers and payload to be encapsulated 382 into C2C-CC Network datagrams and sent over the Modified IEEE 383 802.11p or IEEE 802.11a/b/g network interface. The specification 384 of this interface is currently under discussion. A primary goal 385 of the C2C-CC Network layer is to provide geographic routing and 386 addressing functionalities for cooperative safety applications. 387 Through the mentioned interface to the IPv6 protocol, these 388 functionalities are also available for IP-based applications. 390 o C2C-CC Transport: this block represents the transport layer 391 protocol that is currently being defined by the C2C-CC. This 392 protocol provides a selected set of traditional transport layer 393 functionalities (e.g. application data multiplexing/ 394 demultiplexing, connection establishment, reliability etc.). The 395 specification of this protocol is currently under discussion. 397 o C2C-CC Applications: this block represents the application layer 398 protocol currently defined by the C2C-CC and concerns Active 399 Safety and Traffic Efficiency Applications. 401 3.1.2. IPv6 Deployment 403 As described in Section 3.1.1, the C2C-CC includes IPv6 as mandatory 404 part of its specified protocol architecture. Currently, three 405 methods are discussed for transmission of IPv6 headers and their 406 payload: 408 o On the Modified IEEE 802.11p interface via the C2C-CC Network 409 layer: in this method, IPv6 headers are encapsulated into C2C-CC 410 Network headers and sent using dedicated frequencies for inter- 411 vehicle communications. Since the C2C-CC Network layer provides 412 ad hoc routing, from the IPv6 layer perspective other nodes (OBUs 413 and RSU) appear as attached to the same link. The broadcast 414 domain used for IPv6 multicast traffic is selected by the C2C-CC 415 Network layer on a geographical basis. The C2C-CC Network layer 416 presents Ethernet-like characteristics, so that [4] can be 417 applied. 419 o On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in 420 this method, IPv6 headers are encapsulated into C2C-CC Network 421 headers and sent using license-free ISM frequency bands (wireless 422 LAN). Except the network interface, this method is equivalent to 423 the previous one. 425 o On the IEEE 802.11a/b/g interface directly: in this method, IPv6 426 headers are sent directly to the wireless LAN interface. 428 As a result, a C2C-CC OBU has at least two IPv6 network interfaces, a 429 real one (IEEE 802.11a/b/g) and a virtual one (tunnel over C2C-CC 430 Network layer). The following informational list briefly summarizes 431 some currently discussed design concepts: 433 o in order to avoid address resolution procedures, vehicles only use 434 IPv6 addresses with as host part an EUI-64 identifier derived from 435 the MAC address. Privacy issues described in [3] are strongly 436 alleviated through the use of temporary, changing MAC addresses, 437 which are assigned in a set to every vehicle; 439 o according to the current availability of infrastructure 440 connectivity, OBUs can use (at least) 2 types of globally routable 441 IPv6 addresses: an IPv6 address configured using standard IPv6 442 stateless address configuration from Router Advertisements sent by 443 RSUs connected to a network infrastructure and an IPv6 address 444 configured from a prefix permanently allocated to the vehicle and 445 delegated to the vehicle from a home network. The former globally 446 routable IPv6 address is used as the NEMO Care-of Address (CoA) 447 and the latter as the NEMO Home Address (HoA). In addition, a 448 self-generated IPv6 address with as prefix part a pre-defined IPv6 449 prefix (either reserved for C2C-CC communications or a general 450 purpose one) may be used for ad-hoc communications with other 451 OBUs; 453 o RSUs can either act as IPv6 Access Routers or as bridges connected 454 to external IPv6 Access Routers. Different Access Routers are 455 responsible for announcing different network prefixes with global 456 validity. As a consequence, when roaming between different Access 457 Routers, vehicles experience layer 3 handovers. 459 When infrastructure access via RSUs is available, IPv6 support in 460 C2C-CC systems is enhanced with Mobility Support. As a vehicle 461 includes a set of attached devices (AUs), NEMO Basic Support is the 462 default protocol selected by the C2C-CC for maintaining ongoing 463 sessions during L3 handovers. 465 3.1.3. Scope of NEMO 467 The C2C-CC is defining a protocol stack for both safety and non- 468 safety applications. These two application categories put different 469 requirements on the protocol stack. Therefore the C2C-CC defined a 470 double protocol stack which is depicted in Figure 2. Applications 471 that are subject to safety requirements use the left part, whereas 472 applications that do not require these particular features use the 473 right part of the stack. The left part of the stack provides 474 functionalities like geographic packet distribution, information 475 dissemination according to relevance, information aggregation using 476 cross-layer analysis, security and plausibility checks at different 477 protocol layers. The right part of the stack is designed for non- 478 safety applications and for non-critical applications, which can 479 still support safety. 481 The deployment of NEMO in C2C-CC systems is achieved through the 482 right part of the stack depicted in Figure 2 and targets non-safety 483 applications. Nevertheless, applications using NEMO might indirectly 484 support safety applications. Example use cases are listed in 485 Section 4. 487 3.2. ISO TC204 WG 16 (CALM) 489 ISO TC 204 WG 16 (CALM) is working on "Wide Area Communications 490 Protocols and Interfaces" and was established in year 2000. The WG 491 is itself devided into a number of sub-groups. 493 The purpose of this WG is specifying a protocol architecture from the 494 physical layer up to the application layer and designed for all ITS 495 types of communications. media. 497 The CALM handbook [12] gives an overview of the system and protocol 498 architecture. In essence, this document defines a protocol stack 499 that offers specialized functionalities and interfaces to safety and 500 non-safety applications and doesn't rely on a specific communication 501 technology. This protocol stack allows for both IP and non-IP types 502 of communications. The IP version 6 is the version considered for IP 503 types of flows. 505 3.2.1. System and Protocol Architecture 507 The current draft reference CALM architecture [13] is shown in 508 Figure 3. 510 | Internet | 511 | | 512 +---+-----------------+-+ 513 | | 514 Access +--+-+ +--+-+ Access 515 Router | AR | | AR | Router 516 +--+-+ +--+-+ 517 | | 518 --+---+--- --+---+-- 519 | | 520 Road Side +--+--+ +--+--+ Public 521 Unit | RSU | | PHS | Hot Spot 522 +---+-+ +---+-+ 523 | | 524 /\ /\ 526 \_ \_ 527 \_ \_ 528 \ \ 530 Optional \/ \/ 531 IEEE 802.11a/b/g and 802.11p | | __ \/ Optional IEEE 532 Interfaces +--+---+--+ \__ \/ | 802.11a/b/g and 3G 533 | OBU1 | | | Interfaces 534 +--+---+--+ +-+-----+---+ 535 Vehicle1 | | OBU2 | On-Board 536 -+---+-+- +--+--------+ Unit 537 | | | Vehicle2 538 Application +--+-+ +-+--+ --+--+-- 539 Units | AU | | AU | | 540 +----+ +----+ +-+--+ 541 | AU | 542 +----+ 544 Figure 3: ISO's CALM scenarios 546 Vehicles are equipped with networks logically composed of an 547 (potentially multiple) OBU(s) and potentially multiple AUs. An AU is 548 typically a dedicated device that executes a single or a set of 549 applications and utilizes the OBU communication capabilities. An AU 550 can be an integrated part of a vehicle and be permanently connected 551 to an OBU. It can also be a portable device such as laptop, PDA or 552 game pad that can dynamically attach to (and detach from) an OBU. AU 553 and OBU are usually connected with wired connection, but the 554 connection can also be wireless, such as Bluetooth. The distinction 555 between AU and OBU is logical, they can also reside in a single 556 physical unit. 558 Vehicles' OBUs and stationary units along the road, termed road-side 559 units (RSUs), form a self-organizing network. An OBU is equipped 560 with a number of short range, medium range and long range wireless 561 communication devices, typically IEEE 802.11p [14], IEEE 802.11a/b/g 562 or 3G. OBUs can communicate with one another, either directly if 563 wireless connectivity exist among them, via multi-hop communication 564 where data is forwarded from one OBU to another, until it reaches its 565 destination, through the roadside infrastrucure, or through the 566 Internet. For example in Figure 3, RSU and OBU1 have direct 567 connectivity, whereas OBU2 is out of RSU radio coverage but can 568 communicate with it through multi-hop routing or through the 569 Internet. 571 The primary role of an RSU is improvement of road safety and road 572 traffic. RSUs have two possible configuration modes: as isolated 573 nodes, they execute applications and/or extend the coverage of the ad 574 hoc network implementing routing functionalities. As attachment 575 point connected to an infrastructure network, RSUs distribute 576 information originated in the infrastructure and offer connectivity 577 to the vehicles. As result, for example, the latter configuration 578 allows AUs registered with an OBU to communicate with any host 579 located in the Internet, when at least one RSU connected to a network 580 infrastructure is available. 582 An OBU is equipped with alternative wireless technologies for both 583 safety and non-safety applications. For example, an OBU may also 584 communicate with Internet nodes or servers via public wireless LAN 585 hot spots (PHS) or wide coverage/cellular networks (e.g. UMTS, GPRS) 586 operated individually or by wireless Internet service providers. 587 While RSUs for Internet access are typically set up with a controlled 588 process by a CALM key stake holder, such as road administrators or 589 other public authorities, public hot spots are usually set up in a 590 less controlled environment. These two types of infrastructure 591 access, RSU and PHS, also correspond to different applications types. 592 Other communication technology not currently available or de facto 593 considered in the CALM architecture may be added at will. 595 CALM allows all communication modes: 597 o in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged 598 directly between OBUs, either via multi-hop or not, without 599 involving any RSU; 601 o in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data 602 packets through a RSU with an arbitrary node connected to the 603 infrastructure (potentially another vehicle not attached to the 604 same RSU). 606 o in Vehicle-to-Infrastructure-to-Vehicle mode (V2I2V), an OBU 607 exchanges data packets with another OBU through an arbitrary node 608 in the infrastructure or the Internet; 610 o in Vehicle-to-Internet mode (Internet), an OBU exchanges data 611 packets with an an arbitrary node in the Internet. 613 The CALM protocol stack considered by ISO is depicted in Figure 4. 615 +--------------------+--------------------+-----------------+ 616 | | | | 617 | Non-IP CALM Aware | IP-based CALM | IP-based Legacy | 618 | Aware Applications | Aware Applications | Applications | 619 | | | | 620 + +---------+--------------------+-----------------+ 621 | | | 622 | | TCP/UDP/... | 623 | | | 624 + +------------------------------------------------+ 625 | | | 626 | | CALM IPv6 | 627 | | | 628 +----------------+------------------+-------+---------+-----+ 629 | IEEE 802.11p | Standard WLAN | 2G/3G | CALM IR | ... | 630 | M5/WAVE/DSRC | IEEE 802.11a/b/g | GSM | | ... | 631 +----------------+------------------+-------+---------+-----+ 633 Figure 4: CALM Reference Architecture 635 Protocol blocks are explained in the following list: 637 o M5, WAVE and DSRC are IEEE 802.11p variants, in Europe, USA and 638 Japan, respectivelty: this block represents MAC and PHY layers of 639 a wireless technology based upon current draft standard IEEE 640 802.11p [14] but modified for usage in Europe. In Europe, 641 allocation of dedicated frequencies around 5.9 GHz for safety and 642 non-safety applications is in progress. Expected communication 643 range in line of sight is around 500m. 645 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 646 provided by one ore more IEEE 802.11a/b/g network interfaces. 648 o CALM IPv6 Network: this block represents the IPv6-based network 649 layer protocol currently defined by ISO. The specification of 650 this layer is currently under discussion. Several scenarios are 651 proposed, one for IP communications without mobility management, 652 one for IP communications with host-mobility management (MIPv6), 653 and one with IP communications with network mobility management 654 (NEMO). The former two are out of scope of the present document. 655 This block comprises the NME (Network Management Entity) which is 656 able to interoperate with other layers in order to negociate 657 priority flow requirements 659 o CALM Aware Applications: this block represents specifically 660 designed ITS applications. CALM Aware applications are ranged 661 into IP and non IP applications. This block comprises the CME 662 (CALM Management Entity) which is able to interoperate with lower 663 layers in order to negociate priority flow requirements. 665 3.2.2. IPv6 Deployment 667 The CALM architecture includes IPv6 as mandatory part of its 668 specified protocol architecture. 670 The following informational list briefly summarizes currently 671 discussed design concepts: 673 o in order to avoid address resolution procedures, vehicles use only 674 IPv6 addresses with as host part an EUI-64 identifier derived from 675 the MAC address. Privacy issues described in [3] are strongly 676 alleviated through the use of temporary, changing MAC addresses, 677 which are assigned in a set to every vehicle (as part of their 678 assigned "pseudonyms"); 680 o according to the current availability of infrastructure 681 connectivity, OBUs can use (at least) 2 types of globally routable 682 IPv6 addresses: an IPv6 address configured using standard IPv6 683 stateless address configuration from Router Advertisements sent by 684 RSUs connected to a network infrastructure and an IPv6 address 685 configured from a prefix permanently allocated to the vehicle and 686 delegated to the vehicle from a home network. The former globally 687 routable IPv6 address is used as the NEMO Care-of Address (CoA) 688 and the latter as the NEMO Home Address (HoA). In addition, a 689 self-generated IPv6 address with as prefix part a pre-defined IPv6 690 prefix (either reserved for ISO CALM communications or a general 691 purpose one) may be used for ad-hoc communications with other 692 OBUs; 694 o RSUs can either act as IPv6 Access Routers or as bridges connected 695 to external IPv6 Access Routers. Different Access Routers are 696 responsible for announcing different network prefixes with global 697 validity. As a consequence, when roaming between different Access 698 Routers, vehicles experience layer 3 handovers. 700 3.2.3. Scope of NEMO 702 In all the methods for use of IPv6 in the CALM architecture as 703 described above, the IPv6 layer is meant to be enhanced with Mobility 704 Support. As a vehicle includes a set of attached devices (AUs), NEMO 705 Basic Support is the default protocol selected by ISO for maintaining 706 ongoing sessions during L3 handovers. 708 4. Example Use Cases 710 In this section, the main use cases are listed that have been 711 identified by the C2C-CC and ISO for usage of NEMO: notification 712 services, peer-to-peer applications, upload/download services, 713 navigation services, multimedia applications. 715 4.1. Notification Services 717 A generic notification service delivers information to subscribers by 718 means of the Internet. After subscribing the service with a 719 provider, a user is notified when updates are available. Example 720 services are weather, traffic or news reports, as well as commercial 721 and technical information from the car producer or other companies. 723 In this use case, the HoA or a pre-defined address belonging to the 724 MNP is registered to the service provider. The service provider 725 sends the updates to this address which does not change while the 726 vehicle changes point of attachment. 728 4.2. Peer-to-peer Applications 730 A generic peer-to-peer application exchanges data directly between 731 vehicles, without contacting any application server. Data traffic 732 goes through a network infrastructure (V2I or V2I2V) or directly 733 between cars when the infrastructure is not available (V2V). Example 734 applications are vehicle-to-vehicle instant messaging (chat) and off- 735 line messaging (peer-to-peer email), vehicle-to-vehicle voice over IP 736 and file exchange. 738 The C2C-CC also considers this use case when vehicles are isolated 739 from the infrastructure, i.e. V2V mode. As the NEMO protocol is not 740 involved when infrastructure access is not available, this particular 741 case is out of scope of this document. 743 4.3. Upload and Download Services 745 A generic upload/download service via the Internet consists in simple 746 file exchange procedures with servers located in the Internet. The 747 service is able to resume after a loss of connectivity. 749 4.4. Vehicles Monitoring 751 Vehicles monitoring services allow car manufacturers, car garages and 752 other trusted parties to remotely monitor vehicle statistics. Data 753 is collected by the OBU and sent to the service center via the 754 Internet. 756 As an example, car manufacturers or garages offering this service 757 could deploy NEMO Home Agents to serve thousands of cars. 759 4.5. Infortainment Applications 761 TBD by ISO CALM 763 4.6. Navigation Services 765 TBD by ISO CALM 767 5. NEMO Route Optimization Scenarios 769 In this section, operational characteristics of automotive 770 deployments of NEMO are described that are relevant for the design of 771 Route Optimization techniques. In particular a restriction of the 772 general solution space for RO and motivations for RO requirements 773 described in Section 6 are provided. 775 With respect to the classification of NEMO Route Optimization 776 scenarios described in [6], the non-nested NEMO RO case (Section 3.1) 777 is considered as the most important for the automotive deployment. 778 However, MIPv6-enabled AUs (i.e. VMNs) and nested Network Mobility 779 are allowed in ISO CALM but not specifically addressed. 781 The requirements defined in this document refer to RO between MR and 782 CE (Correspondent Entity). According to the automotive use cases, 783 the CE can be: 785 1. Another vehicle, i.e. another automotive MR. 787 2. A dedicated node (host or router) installed on the roadside (2a) 788 or in the Internet (2b) for automotive applications. 790 3. An arbitrary node in the Internet. 792 In cases 1 and 2, the CE is a newly deployed entity. Whereas the 793 communicating peers in case 1 are obvious, case 2 includes for 794 example information points installed along the road, control centers, 795 notification points and infotainment service providers located in the 796 infrastructure. 798 The suboptimal routing due to the lack of RO has the most negative 799 impact when the topological distance between MR and CE is 800 considerably smaller than between MR and HA. This is highly likely 801 to occour in case 1 (e.g. two neighboring vehicles communicating with 802 each others) and case 2a (e.g. vehicles receiving updates from 803 information points installed on the roadside). For these two cases, 804 the suboptimal routing might represent a limiting factor for the 805 system performance and, in turn, a limiting factor for the deployment 806 of NEMO. 808 In cases 2b and 3, the impact of suboptimal routing depends on the 809 arbitrary CE topological position. At this point of time no 810 particular assumption can be made on the topological position of CE 811 in case 2b and, obviously, in case 3. Consequently, the case 1 and 812 2a deserve a higher priority with respect to the definition of a NEMO 813 RO solution for automotive applications. 815 Any available information about the geographical or topological 816 position of the CE is relevant for the MR in order to apply RO. In 817 this respect, external information might be used to define policy 818 rules specifying whether or not RO should be enabled with a 819 particular pre-defined CE, which is known in advanced to the MR. 821 6. NEMO Route Optimization Requirements 823 Table Figure 5 summarizes which requirement applies to both C2C-CC 824 and ISO, or only one of these. 826 6.1. Req 1 - Separability 828 A RO technique, including its establishment procedure, MUST have the 829 ability to be enabled on a per-flow basis according to pre-defined 830 policies. Policies criteria for the switching to RO MUST at least 831 include the end points' addresses and the MNP for which RO is to be 832 established. Policies MAY change dynamically. 834 In some scenarios it might not be beneficial to activate RO due to 835 the intermittent connectivity. Based on external information, a 836 management instance of the MR can dynamically specify policies for RO 837 establishment of a particular IPv6 flow. Furthermore, policies can 838 prevent unnecessary or unwanted RO sessions to take place (e.g. DNS 839 queries, location privacy protection etc.). In case of MRs serving 840 multiple MNPs (e.g. served by different HAs or MNPs that vary only in 841 the length), the policies allow for specifying for which MNP RO 842 should be established (i.e. prefix including length). 844 6.2. Req 2 - RO Security 846 As a minimum security feature, an RO technique MUST prevent off-path 847 malicious nodes to claim false MNP ownership. Further security 848 requirements are TBD. 850 As a minimum requirement, the security level of a RO scheme should be 851 comparable with today's Internet. 853 6.3. Req 3 - Privacy Protection 855 A RO technique MUST NOT allow off-path malicious nodes to match the 856 MR's CoA with its MNP or HoA. 858 In other words, the RO technique must not expose the MNP/HoA to nodes 859 other than the CE and, indirectly, the nodes on the path between the 860 MR and the CE. 862 6.4. Req 4 - Multihoming 864 A RO technique MUST allow a MR to be simultaneously connected to 865 multiple access networks, having multiple prefixes and Care-Of 866 Addresses in a MONAMI6 context, and be served by multiple HAs. 868 Adopting the classification of [8], the automotive NEMO deployment 869 includes at least the cases (1,n,n), (n,1,1) and (n,n,n). Case 870 (1,n,n) takes place when a single MR is installed in the vehicle's 871 OBU but different MNPs/HAs are used for different purposes (e.g. 872 vehicle monitoring, traffic information, infotainment) or to achieve 873 better fault tolerance. Cases (n,1,1) and (n,n,n) take place when 874 the vehicle's connectivity is enhanced by installing additional NEMO 875 MRs in a separated unit in a later stage. A RO technique must not 876 prevent any of these three configurations from working properly. 878 6.5. Req 5 - Efficient Signaling 880 A RO technique MUST be capable of efficient signaling. The number of 881 per-flow signaling messages for the establishment of RO SHOULD be 882 smaller than TBD and the number of per-flow signaling messages upon a 883 layer 3 handover should be smaller than TBD. 885 6.6. Req 6 - Switching HA 887 A RO technique MUST allow a MR to switch from one HA to another one 888 topologically distant from the first one. 890 +====================================================+ 891 | | C2C-CC | ISO CALM | 892 +====================================================+ 893 | #1: Separability | x | x | 894 +--------------------------------+--------+----------+ 895 | #2: RO Security | x | x | 896 +--------------------------------+--------+----------+ 897 | #3: Privacy Protection | x | x | 898 +--------------------------------+--------+----------+ 899 | #4: Multihoming | x | x | 900 +--------------------------------+--------+----------+ 901 | #5: Efficient Signaling | x | x | 902 +--------------------------------+--------+----------+ 903 | #6: Switching HAs | | x | 904 +====================================================+ 906 Figure 5: C2C-CC and ISO CALM requirements 908 7. IANA Considerations 910 This document does not require any IANA action. 912 8. Security Considerations 914 This document does not specify any protocol therefore does not create 915 any security threat. However, it specifies requirements for a 916 protocol that include security and privacy issues. 918 9. Acknowledgments 920 The authors would like to thank the members of the work groups PHY/ 921 MAC/NET and APP of the C2C-C Consortium and in particular Tim 922 Leinmueller, Bernd Bochow, Andras Kovacs and Matthias Roeckl. 924 10. References 926 10.1. Normative References 928 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 929 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 930 January 2005. 932 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 933 IPv6", RFC 3775, June 2004. 935 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless 936 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 938 [4] Crawford, M., "Transmission of IPv6 Packets over Ethernet 939 Networks", RFC 2464, December 1998. 941 10.2. Informative References 943 [5] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 944 Route Optimization Problem Statement", July 2007. 946 [6] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 947 Route Optimization Solution Space Analysis", July 2007. 949 [7] Ernst, T. and H-Y. Lach, "Network Mobility Support 950 Terminology", RFC 4885, July 2007. 952 [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 953 Multihoming in Network Mobility Support", RFC 4980, 954 October 2007. 956 [9] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization 957 Requirements for Operational Use in Aeronautics and Space 958 Exploration Mobile Networks", draft-ietf-mext-aero-reqs-00 959 (work in progress), December 2007. 961 [10] "Car2Car Communication Consortium Official Website", 962 http://www.car-2-car.org/ . 964 [11] "Car2Car Communication Consortium Manifesto", 965 http://www.car-2-car.org/index.php?id=570 , May 2007. 967 [12] "The CALM Handbook", http://www.calm.hu , May 2005. 969 [13] "CALM - Medium and Long Range, High Speed, Air Interfaces 970 parameters and protocols for broadcast, point to point, 971 vehicle to vehicle, and vehicle to point communication in the 972 ITS sector - Networking Protocol - Complementary Element", ISO 973 Draft ISO/WD 21210, February 2005. 975 [14] "Draft Amendment to Standard for Information Technology . 976 Telecommunications and information exchange between systems . 977 Local and Metropolitan networks . Specific requirements - Part 978 11: Wireless LAN Medium Access Control (MAC) and Physical Layer 979 (PHY) specifications: Amendment 3: Wireless Access in Vehicular 980 Environments (WAVE)", IEEE P802.11p/D1.0, February 2006. 982 Authors' Addresses 984 Roberto Baldessari 985 NEC Europe Network Laboratories 986 Kurfuersten-anlage 36 987 Heidelberg 69115 988 Germany 990 Phone: +49 6221 4342167 991 Email: roberto.baldessari@nw.neclab.eu 993 Thierry Ernst 994 INRIA 995 INRIA Rocquencourt 996 Domaine de Voluceau B.P. 105 997 Le Chesnay, 78153 998 France 1000 Phone: +33-1-39-63-59-30 1001 Fax: +33-1-39-63-54-91 1002 Email: thierry.ernst@inria.fr 1003 URI: http://www.nautilus6.org/~thierry 1005 Andreas Festag 1006 NEC Deutschland GmbH 1007 Kurfuersten-anlage 36 1008 Heidelberg 69115 1009 Germany 1011 Phone: +49 6221 4342147 1012 Email: andreas.festag@nw.neclab.eu 1014 Massimiliano Lenardi 1015 Hitachi Europe SAS Sophia Antipolis Laboratory 1016 Immeuble Le Theleme 1017 1503 Route des Dolines 1018 Valbonne F-06560 1019 France 1021 Phone: +33 489 874168 1022 Email: massimiliano.lenardi@hitachi-eu.com 1024 Full Copyright Statement 1026 Copyright (C) The IETF Trust (2008). 1028 This document is subject to the rights, licenses and restrictions 1029 contained in BCP 78, and except as set forth therein, the authors 1030 retain all their rights. 1032 This document and the information contained herein are provided on an 1033 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1034 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1035 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1036 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1037 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1038 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1040 Intellectual Property 1042 The IETF takes no position regarding the validity or scope of any 1043 Intellectual Property Rights or other rights that might be claimed to 1044 pertain to the implementation or use of the technology described in 1045 this document or the extent to which any license under such rights 1046 might or might not be available; nor does it represent that it has 1047 made any independent effort to identify any such rights. Information 1048 on the procedures with respect to rights in RFC documents can be 1049 found in BCP 78 and BCP 79. 1051 Copies of IPR disclosures made to the IETF Secretariat and any 1052 assurances of licenses to be made available, or the result of an 1053 attempt made to obtain a general license or permission for the use of 1054 such proprietary rights by implementers or users of this 1055 specification can be obtained from the IETF on-line IPR repository at 1056 http://www.ietf.org/ipr. 1058 The IETF invites any interested party to bring to its attention any 1059 copyrights, patents or patent applications, or other proprietary 1060 rights that may cover technology that may be required to implement 1061 this standard. Please address the information to the IETF at 1062 ietf-ipr@ietf.org. 1064 Acknowledgment 1066 Funding for the RFC Editor function is provided by the IETF 1067 Administrative Support Activity (IASA).