idnits 2.17.1 draft-ietf-mext-nemo-ro-automotive-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 886: '...establishment procedure, MUST have the...' RFC 2119 keyword, line 888: '... for the switching to RO MUST at least...' RFC 2119 keyword, line 890: '...ished. Policies MAY change dynamicall...' RFC 2119 keyword, line 911: '...o The RO scheme MUST permit the recei...' RFC 2119 keyword, line 914: '...o The RO scheme MUST ensure that only...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1091 has weird spacing: '... access layer...' -- 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 (January 15, 2009) is 5580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3775' is defined on line 1018, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-ietf-mext-aero-reqs-02 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: July 19, 2009 INRIA 6 A. Festag 7 NEC Germany 8 M. Lenardi 9 Hitachi Europe 10 January 15, 2009 12 Automotive Industry Requirements for NEMO Route Optimization 13 draft-ietf-mext-nemo-ro-automotive-req-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 19, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 This document specifies requirements for NEMO Route Optimization 53 techniques as identified by the automotive industry. Requirements 54 are gathered from the Car2Car Communication Consortium and ISO 55 Technical Committee 204 Working Group 16 (CALM). The document also 56 overviews the current status of ETSI TC ITS, which is going to unify 57 the approaches of these two automotive consortia in a single 58 communication architecture. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. NEMO Automotive Deployments . . . . . . . . . . . . . . . . . 5 65 3.1. Car2Car Communication Consortium . . . . . . . . . . . . . 5 66 3.1.1. System and Protocol Architecture . . . . . . . . . . . 6 67 3.1.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 9 68 3.1.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 10 69 3.2. ISO TC204 WG 16 (CALM) . . . . . . . . . . . . . . . . . . 11 70 3.2.1. System and Protocol Architecture . . . . . . . . . . . 11 71 3.2.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 15 72 3.2.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 16 73 3.3. ETSI TC ITS . . . . . . . . . . . . . . . . . . . . . . . 16 74 4. NEMO Example Use Cases . . . . . . . . . . . . . . . . . . . . 17 75 4.1. Notification Services . . . . . . . . . . . . . . . . . . 17 76 4.2. Peer-to-peer Applications . . . . . . . . . . . . . . . . 17 77 4.3. Upload and Download Services . . . . . . . . . . . . . . . 17 78 4.4. Vehicles Monitoring . . . . . . . . . . . . . . . . . . . 18 79 4.5. Infotainment Applications . . . . . . . . . . . . . . . . 18 80 4.6. Navigation Services . . . . . . . . . . . . . . . . . . . 18 81 5. NEMO Route Optimization Scenarios . . . . . . . . . . . . . . 18 82 6. NEMO Route Optimization Requirements . . . . . . . . . . . . . 19 83 6.1. Req 1 - Separability . . . . . . . . . . . . . . . . . . . 19 84 6.2. Req 2 - RO Security . . . . . . . . . . . . . . . . . . . 20 85 6.3. Req 3 - Binding Privacy Protection . . . . . . . . . . . . 20 86 6.4. Req 4 - Multihoming . . . . . . . . . . . . . . . . . . . 20 87 6.5. Req 5 - Minimum Signaling . . . . . . . . . . . . . . . . 21 88 6.6. Req 6 - Switching HA . . . . . . . . . . . . . . . . . . . 21 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 NEMO Basic Support [RFC3963] defines a protocol that provides IPv6 100 mobility support for entire moving networks, where all data packets 101 go through the IPv6-in-IPv6 tunnel established between the Mobile 102 Router (MR) and the Home Agent (HA). As already pointed out in 103 various documents ([RFC4888], [RFC4889] and 104 [I-D.ietf-mext-aero-reqs]) this can have severe consequences on the 105 communication performances, as it causes data packets to follow a 106 path that can be very far from optimal and requires a double IPv6 107 header for every packet exchanged with a Correspondent Node (CN) in 108 the Internet. Compared with a communication that uses the ideal 109 packet routing and the normal IPv6 header size, these factors result 110 in an increased delay and a reduced throughput, plus indirect 111 consequences like increased packet fragmentation and overall less 112 efficient usage of resources. 114 Various projects and consortia involving the automotive industry are 115 considering NEMO as part of their protocol stack for the provisioning 116 of session continuity and global reachability. Nevertheless, the 117 lack of standardized Route Optimization (RO) techniques allowing data 118 packets to be exchanged directly between vehicles or between vehicles 119 and hosts in the Internet is regarded as an obstacle for the actual 120 deployment of this protocol. As the definition of a general NEMO 121 Route Optimization technique is highly complex, it appears more 122 reasonable to address specific deployment requirements and design 123 more tailored, less complex schemes for Route Optimization. 125 This document gathers requirements from two bodies that are committed 126 in deploying vehicular communications including NEMO as part of their 127 protocol stacks. 129 o The Car2Car Communication Consortium [c2ccc-web] is an industry 130 consortium of car manufacturers and electronics suppliers 131 operating in Europe. Its mission is to establish an open European 132 industry standard for vehicular communications based on wireless 133 LAN technology. Its approach consists in considering vehicles as 134 a Vehicular ad hoc Network (VANET), where cars are equipped with 135 short-range communication devices that operate at frequencies 136 dedicated to safety and non-safety vehicular applications. 138 o ISO TC 204 WG 16 (CALM): ISO (International Standard Organization) 139 runs a number of Technical Committees. Members are nations and 140 offical participants represent their country. TC 204 is devoted 141 to Intelligent Transport Systems (ITS) and comprises a number of 142 Working Groups (16, but 12 still in operation). ISO TC 204 WG 16 143 is working on "Wide Area Communications Protocols and Interfaces" 144 and was established in year 2000. It is specifying a protocol 145 architecture from the physical layer up to the application layer 146 and designed for all ITS types of communications (vehicle-vehicle, 147 vehicle-infrastructure, infrastructure-vehicle). Known as the 148 CALM architecture, the acronym was initially set to mean 149 "Communications Air-interface, Long and Medium range" but was 150 renamed in 2007 to "Communication Architecture for Land Mobile". 152 The document is organized as follows: Section 2 defines terminology. 153 Section 3 overviews the technical approaches adopted by the two 154 automotive bodies to deploy NEMO. Section 4 provides a non- 155 exhaustive list of use cases of NEMO in automotive applications. 156 Section 5 introduces the RO scenario and finally Section 6 lists the 157 requirements for NEMO RO. 159 2. Terminology 161 The following terms used in this document are defined in the Network 162 Mobility Support Terminology document [RFC4885]: 164 o Mobile Network 166 o Network Mobility (NEMO) 168 o Home Agent (HA) 170 o Home Address (HoA) 172 o Mobile Router (MR) 174 o Mobile Network Prefix (MNP) 176 o Mobile Network Node (MNN) 178 o Correspondent Router (CR) 180 o Correspondent Entity (CE) 182 o Egress Interface 184 o Ingress Interface 186 The following new terms are used in this document: 188 o On Board Unit (OBU): a device installed in vehicles, implementing 189 the communication protocols and algorithms and equipped with at 190 least 1) a short-range wireless network interface operating at 191 dedicated frequencies and 2) a wireless or wired network interface 192 where Application Units (AU) can be attached to. With respect to 193 the NEMO terminology, the OBU is the physical machine acting as 194 MR, 1) is used as egress interface and 2) as ingress. 196 o Application Unit (AU): a portable or built-in device connected 197 temporarily or permanently to the vehicle's OBU. It is assumed 198 that AUs support a standard TCP/IPv6 protocol stack. Devices 199 enhanced with Mobile IPv6, like hand-held user devices, also fall 200 into the definition of Application Unit. With respect to the NEMO 201 terminology, an AU is a generic MNN. 203 o Road Side Unit (RSU): a device installed along roadsides 204 implementing automotive communication protocols and algorithms. 205 RSUs can either be isolated or connected to a network 206 infrastructure. In the latter case, RSUs are attachment points 207 either acting themselves as IPv6 access routers or as bridges 208 directly connected to an access router. 210 o In-vehicle network: the wireless or wired network placed in a 211 vehicle and composed of (potentially) several AUs and one OBU. 213 o Vehicle-to-Vehicle (V2V) Communication Mode: a generic 214 communication mode in which data packets are exchanged between two 215 vehicles, either directly or traversing multiple vehicles, without 216 involving any node in the infrastructure. 218 o Vehicle-to-Infrastructure (V2I) Communication Mode: a generic 219 communication mode in which data packets sent or received by a 220 vehicle traverse a network infrastructure. 222 3. NEMO Automotive Deployments 224 3.1. Car2Car Communication Consortium 226 The Car2Car Communication Consortium (C2C-CC [c2ccc-web]) is an 227 industry consortium of car manufacturers and electronics suppliers 228 that focuses on the definition of an European standard for vehicular 229 communication protocols. The Consortium gathers results from 230 research projects and aims at harmonizing their efforts. For the 231 standardization activity, the C2C-CC provides recommendations to the 232 newly established ETSI TC ITS, described in Section 3.3. 234 The consortium's Manifesto [c2ccc-manifesto] gives an overview of the 235 system and protocol architecture, as well as of the applications on 236 which the Consortium has agreed so far. In essence, this document 237 defines a C2C-C protocol stack that offers specialized 238 functionalities and interfaces to (primarily) safety-oriented 239 applications and relies as a communication technology on a modified 240 version of IEEE 802.11p [IEEE.802-11p-d3-0]. This protocol stack is 241 placed beside a traditional TCP/IP stack, based on IP version 6, 242 which is used mainly for non-safety applications or potentially by 243 any application that is not subject to strict delivery requirements, 244 including Internet-based applications. The interaction between these 245 stacks is currently discussed and briefly overviewed in this 246 document. 248 3.1.1. System and Protocol Architecture 250 The current draft reference architecture of the C2C communication 251 system is shown in Figure 1. 253 | Internet | 254 | | 255 +---+-----------------+-+ 256 | | 257 Access +--+-+ +--+-+ Access 258 Router | AR | | AR | Router 259 +--+-+ +--+-+ 260 | | 261 --+---+--- --+---+-- 262 | | 263 Road Side +--+--+ +--+--+ Public 264 Unit | RSU | | PHS | Hot Spot 265 +---+-+ +---+-+ 266 | | 267 /\ /\ 269 \_ \_ 270 \_ \_ 271 \ \ 273 Mandatory \/ 274 Mod IEEE 802.11p | __ \/ Optional IEEE 275 Interface +---+--+ \__ \/ | 802.11a/b/g 276 | OBU1 | | | Interface 277 +--+---+ +-+-----+---+ 278 Vehicle1 | | OBU2 | On-Board 279 -+---+-+- +--+--------+ Unit 280 | | | Vehicle2 281 Application +--+-+ +-+--+ --+--+-- 282 Units | AU | | AU | | 283 +----+ +----+ +-+--+ 284 | AU | 285 +----+ 287 Figure 1: C2C-CC Reference Architecture 289 Vehicles are equipped with networks logically composed of an OBU and 290 potentially multiple AUs. An AU is typically a dedicated device that 291 executes a single or a set of applications and utilizes the OBU 292 communication capabilities. An AU can be an integrated part of a 293 vehicle and be permanently connected to an OBU. It can also be a 294 portable device such as laptop, PDA or game pad that can dynamically 295 attach to (and detach from) an OBU. AU and OBU are usually connected 296 with wired connection, but the connection can also be wireless, such 297 as Bluetooth. The distinction between AU and OBU is logical, they 298 can also reside in a single physical unit. 300 Vehicles' OBUs and stationary units along the road, termed road-side 301 units (RSUs), form a self-organizing network. An OBU is at least 302 equipped with a (short range) wireless communication device based on 303 draft standard IEEE 802.11p [IEEE.802-11p-d3-0] (adapted to European 304 conditions and with specific C2C-C extensions) primarily dedicated 305 for road safety, and potentially with other optional communication 306 devices. OBUs directly communicate if wireless connectivity exist 307 among them. In case of no direct connectivity, vehicles can be used 308 as relays, where data is forwarded from one OBU to another, until it 309 reaches its destination. For example in Figure 1, RSU and OBU1 have 310 direct connectivity, whereas OBU2 is out of RSU radio coverage but 311 can communicate with it, as OBU1 acts as packet relay. 313 The primary role of an RSU is improvement of road safety. RSUs have 314 two possible configuration modes: as isolated nodes, they execute 315 applications and/or extend the coverage of the ad hoc network 316 implementing routing functionalities. As attachment point connected 317 to an infrastructure network, RSUs distribute information originated 318 in the infrastructure and offer connectivity to the vehicles. As 319 result, for example, the latter configuration allows AUs registered 320 with an OBU to communicate with any host located in the Internet, 321 when at least one RSU connected to a network infrastructure is 322 available. 324 An OBU may also be equipped with alternative wireless technologies 325 for both, safety and non-safety. For example, an OBU may also 326 communicate with Internet nodes or servers via public wireless LAN 327 hot spots (PHS) operated individually or by wireless Internet service 328 providers. While RSUs for Internet access are typically set up with 329 a controlled process by a C2C-C key stake holder, such as road 330 administrators or other public authorities, public hot spots are 331 usually set up in a less controlled environment. These two types of 332 infrastructure access, RSU and PHS, also correspond to different 333 applications types. Other communication technologies, such as wide 334 coverage/cellular networks (e.g. UMTS, GPRS) do not fall in the 335 scope of the C2C-CC activity. Nevertheless, the C2C-CC aims at 336 guaranteeing future system extensibility and interoperability with 337 different technologies. 339 The protocol stack currently considered by the C2C-CC for OBUs is 340 depicted in Figure 2. 342 +--------------------+------------------+ 343 | | | 344 | C2C-CC | IP-based | 345 | Applications | Applications | 346 | | | 347 +--------------------+------------------+ 348 | | TCP/UDP/... | 349 | C2C-CC Transport +------------------+ 350 | | IPv6 | 351 +--------------------+---------+ | 352 | | | 353 | C2C-CC Network | | 354 | | | 355 +--------------------+---------+--------+ 356 | Modified | Standard WLAN | 357 | IEEE 802.11p | IEEE 802.11a/b/g | 358 +--------------------+------------------+ 360 Figure 2: OBU Protocol Stack 362 Protocol blocks are explained in the following list: 364 o Modified IEEE 802.11p: this block represents MAC and PHY layers of 365 a wireless technology based upon current draft standard IEEE 366 802.11p [IEEE.802-11p-d3-0] but modified for usage in Europe. In 367 Europe, allocation of dedicated frequencies around 5.9 GHz for 368 safety and non-safety applications is in progress. Expected 369 communication range in line of sight is at least 500m. This 370 network interface is mandatory. 372 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 373 provided by one ore more IEEE 802.11a/b/g network interfaces. 374 This network interface is optional but C2C-C Consortium encourages 375 its installation. 377 o C2C-CC Network: this block represents the network layer protocol 378 currently defined by the C2C-CC. The protocol provides secure ad 379 hoc routing and forwarding, as well as addressing, error handling, 380 packet sequencing, congestion control and information 381 dissemination. The specification of this protocol is currently 382 under discussion. Only the C2C-CC Network protocol can access the 383 Modified IEEE 802.11p network interface. The C2C-CC Network 384 protocol can also access the IEEE 802.11a/b/g interface. The 385 C2C-CC Network protocol offers an interface to the IPv6 protocol. 386 This interface allows IPv6 headers and payload to be encapsulated 387 into C2C-CC Network datagrams and sent over the Modified IEEE 388 802.11p or IEEE 802.11a/b/g network interface. The specification 389 of this interface is currently under discussion. A primary goal 390 of the C2C-CC Network layer is to provide geographic routing and 391 addressing functionalities for cooperative safety applications. 392 Through the mentioned interface to the IPv6 protocol, these 393 functionalities are also available for IP-based applications. 395 o C2C-CC Transport: this block represents the transport layer 396 protocol that is currently being defined by the C2C-CC. This 397 protocol provides a selected set of traditional transport layer 398 functionalities (e.g. application data multiplexing/ 399 demultiplexing, connection establishment, reliability etc.). The 400 specification of this protocol is currently under discussion. 402 o C2C-CC Applications: this block represents the application layer 403 protocol currently defined by the C2C-CC and concerns Active 404 Safety and Traffic Efficiency Applications. 406 3.1.2. IPv6 Deployment 408 As described in Section 3.1.1, the C2C-CC includes IPv6 as mandatory 409 part of its specified protocol architecture. Currently, three 410 methods are discussed for transmission of IPv6 headers and their 411 payload: 413 o On the Modified IEEE 802.11p interface via the C2C-CC Network 414 layer: in this method, IPv6 packets are tunneled in C2C-CC Network 415 headers and sent using dedicated frequencies for inter-vehicle 416 communications. Since the C2C-CC Network layer provides ad hoc 417 routing, from the IPv6 layer perspective other nodes (OBUs and 418 RSUs) appear as attached to the same link. The broadcast domain 419 used for IPv6 multicast traffic is selected by the C2C-CC Network 420 layer on a geographical basis. The C2C-CC Network layer presents 421 Ethernet-like characteristics, so that [RFC2464] can be applied. 423 o On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in 424 this method, IPv6 headers are encapsulated into C2C-CC Network 425 headers and sent using license-free ISM frequency bands (wireless 426 LAN). Except the network interface, this method is equivalent to 427 the previous one. 429 o On the IEEE 802.11a/b/g interface directly: in this method, IPv6 430 headers are sent directly to the wireless LAN interface. 432 As a result, a C2C-CC OBU has at least two IPv6 network interfaces, a 433 real one (IEEE 802.11a/b/g) and a virtual one (tunnel over C2C-CC 434 Network layer). The following informational list briefly summarizes 435 some currently discussed design concepts: 437 o in order to avoid address resolution procedures, vehicles only use 438 IPv6 addresses with as Interface Identifier an EUI-64 identifier 439 derived from the MAC address. Privacy issues described in 440 [RFC3041] are strongly alleviated through the use of temporary, 441 changing MAC addresses, which are assigned in a set to every 442 vehicle; 444 o according to the current availability of infrastructure 445 connectivity, OBUs can use (at least) 2 types of globally routable 446 IPv6 addresses: an IPv6 address configured using standard IPv6 447 stateless address configuration from Router Advertisements sent by 448 RSUs connected to a network infrastructure and an IPv6 address 449 temporarily or permanently assigned to the vehicle belonging to a 450 home network and not varying while the vehicle changes its point- 451 of-attachment to the Internet. The former globally routable IPv6 452 address is used as the NEMO Care-of Address (CoA) and the latter 453 as the NEMO Home Address (HoA). 455 o for V2V communication, i.e. when no infrastructure is available, 456 OBUs can use link-local addresses. As described above, a portion 457 of the VANET (geographically or topologically scoped), spanning 458 beyond the vehicle's physical communication range, is presented to 459 IPv6 as a single, link-local multicast capable logical link. 460 Therefore, IPv6 packets can traverse multiple physical hops 461 without having the Hop Limit decremented, as they do not leave the 462 logical link; 464 o RSUs can either act as IPv6 Access Routers or as bridges connected 465 to external IPv6 Access Routers. Different Access Routers are 466 responsible for announcing different network prefixes with global 467 validity. As a consequence, when roaming between different Access 468 Routers, vehicles experience layer 3 handovers. 470 When infrastructure access via RSUs is available, IPv6 support in 471 C2C-CC systems is enhanced with Mobility Support. As a vehicle 472 includes a set of attached devices (AUs), NEMO Basic Support is the 473 default protocol selected by the C2C-CC for maintaining ongoing 474 sessions during L3 handovers. 476 3.1.3. Scope of NEMO 478 The C2C-CC is defining a protocol stack for both safety and non- 479 safety applications. These two application categories put different 480 requirements on the protocol stack. Therefore the C2C-CC defined a 481 double protocol stack which is depicted in Figure 2. Applications 482 that are subject to safety requirements use the left part, whereas 483 applications that do not require these particular features use the 484 right part of the stack. The left part of the stack provides 485 functionalities like geographic packet distribution, information 486 dissemination according to relevance, information aggregation using 487 cross-layer analysis, security and plausibility checks at different 488 protocol layers. The right part of the stack is designed for non- 489 safety applications and for non-critical applications, which can 490 still support safety. 492 The deployment of NEMO in C2C-CC systems is achieved through the 493 right part of the stack depicted in Figure 2 and targets non-safety 494 applications. Nevertheless, applications using NEMO might indirectly 495 support safety applications. Example use cases are listed in 496 Section 4. 498 3.2. ISO TC204 WG 16 (CALM) 500 ISO TC 204 WG 16 (CALM) is working on "Wide Area Communications 501 Protocols and Interfaces" and was established in year 2000. The WG 502 is itself divided into a number of sub-groups. The purpose of this 503 WG is specifying a protocol architecture from the physical layer up 504 to the application layer and designed for all ITS types of 505 communications media. 507 The CALM handbook [calm-handbook] gives an overview of the system and 508 protocol architecture. In essence, this document defines a protocol 509 stack that offers specialized functionalities and interfaces to 510 safety and non-safety applications and does not rely on a specific 511 communication technology. This protocol stack allows for both IP and 512 non-IP types of communications. The IP version 6 is the version 513 considered for IP types of datagrams. 515 3.2.1. System and Protocol Architecture 517 Vehicles are equipped with networks logically composed of an 518 (potentially multiple) OBU(s) and potentially multiple AUs. An AU is 519 typically a dedicated device that executes a single or a set of 520 applications and utilizes the OBU communication capabilities. An AU 521 can be an integrated part of a vehicle and be permanently connected 522 to an OBU. It can also be a portable device such as laptop, PDA or 523 game pad that can dynamically attach to (and detach from) an OBU. AU 524 and OBU are usually connected with wired connection, but the 525 connection can also be wireless, such as Bluetooth. The distinction 526 between AU and OBU is logical, they can also reside in a single 527 physical unit. 529 Vehicles' OBUs and stationary units along the road, termed road-side 530 units (RSUs), form a self-organizing network. An OBU is equipped 531 with a number of short range, medium range and long range wireless 532 communication devices, typically IEEE 802.11p [IEEE.802-11p-d3-0], 533 IEEE 802.11a/b/g or 3G. OBUs can communicate with one another, either 534 directly if wireless connectivity exists among them, or via vehicles 535 acting as relays, where data is forwarded from one OBU to another 536 until it reaches its destination, or through the roadside 537 infrastructure, or through the Internet. 539 The primary role of an RSU is improvement of road safety and road 540 traffic. RSUs have two possible configuration modes: as isolated 541 nodes, they execute applications and/or extend the coverage of the ad 542 hoc network implementing routing functionalities. As attachment 543 point connected to an infrastructure network, RSUs distribute 544 information originated in the infrastructure and offer connectivity 545 to the vehicles. As result, for example, the latter configuration 546 allows AUs registered with an OBU to communicate with any host 547 located in the Internet, when at least one RSU connected to a network 548 infrastructure is available. 550 An OBU is equipped with alternative wireless technologies for both 551 safety and non-safety applications. For example, an OBU may also 552 communicate with Internet nodes or servers via public wireless LAN 553 hot spots (PHS) or wide coverage/cellular networks (e.g. UMTS, GPRS) 554 operated individually or by wireless Internet service providers. 555 While RSUs for Internet access are typically set up with a controlled 556 process by a CALM key stake holder, such as road administrators or 557 other public authorities, public hot spots are usually set up in a 558 less controlled environment. These two types of infrastructure 559 access, RSU and PHS, also correspond to different applications types. 560 Other communication technologies not currently available or de facto 561 considered in the CALM architecture may be added at will. 563 In Figure 3, RSU and OBU1 have direct connectivity, whereas OBU2 is 564 out of RSU radio coverage but can communicate with it through multi- 565 hop routing or through the Internet. 567 | Internet | 568 | | 569 +---+-----------------+-+ 570 | | 571 Access +--+-+ +--+-+ Access 572 Router | AR | | AR | Router 573 +--+-+ +--+-+ 574 | | 575 --+---+--- --+---+-- 576 | | 577 Road Side +--+--+ +--+--+ Public 578 Unit | RSU | | PHS | Hot Spot 579 +---+-+ +---+-+ 580 | | 581 /\ /\ 583 \_ \_ 584 \_ \_ 585 \ \ 587 Optional \/ \/ 588 IEEE 802.11a/b/g and 802.11p | | __ \/ Optional IEEE 589 Interfaces +--+---+--+ \__ \/ | 802.11a/b/g and 3G 590 | OBU1 | | | Interfaces 591 +--+---+--+ +-+-----+---+ 592 Vehicle1 | | OBU2 | On-Board 593 -+---+-+- +--+--------+ Unit 594 | | | Vehicle2 595 Application +--+-+ +-+--+ --+--+-- 596 Units | AU | | AU | | 597 +----+ +----+ +-+--+ 598 | AU | 599 +----+ 601 Figure 3: ISO's CALM scenarios 603 CALM allows all communication modes: 605 o in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged 606 directly between OBUs, either via multi-hop or not, without 607 involving any RSU; 609 o in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data 610 packets through a RSU with an arbitrary node connected to the 611 infrastructure (potentially another vehicle not attached to the 612 same RSU). 614 o in Vehicle-to-Infrastructure-to-Vehicle mode (V2I2V), an OBU 615 exchanges data packets with another OBU through an arbitrary node 616 in the infrastructure or the Internet; 618 o in Vehicle-to-Internet mode (Internet), an OBU exchanges data 619 packets with an an arbitrary node in the Internet. 621 The current draft reference CALM architecture is specified in 622 [ISO-21217-CALM-Architecture] whereas the IPv6 networking specific 623 parts are specified in [ISO-21210-CALM-IPv6-Networking]. A 624 simplified description of the CALM Reference Architecture protocol 625 stack currently specified by ISO for OBUs/MRs is depicted in 626 Figure 4. 628 +---------------+--------------------+----------------------+ 629 | | | | 630 | Non-IP | IPv6 | IPv6 | 631 | CALM Aware | CALM-Aware | Legacy | 632 | Applications | Applications | Applications | 633 | | | | 634 +---------------+--------------------+----------------------+ 635 | | | 636 | | TCP/UDP/... | 637 | | | 638 + +--+----------------------------------------+ 639 | | | 640 | CALM FAST | IPv6 | 641 | | | 642 +------------------+---+------------------+-------+------+--+ 643 | ModifiedIEEE 802.11p | Standard WLAN | 2G/3G | CALM |..| 644 | M5/WAVE/DSRC | IEEE 802.11a/b/g | GSM | IR |..| 645 +----------------------+------------------+-------+------+--+ 647 Figure 4: CALM Protocol Stack for OBU/MR 649 Protocol blocks are explained in the following list: 651 o M5, WAVE and DSRC are IEEE 802.11p variants, in Europe, USA and 652 Japan, respectively: this block represents MAC and PHY layers of a 653 wireless technology based upon current draft standard IEEE 802.11p 654 [IEEE.802-11p-d3-0] but modified for usage in Europe. In Europe, 655 allocation of dedicated frequencies around 5.9 GHz for safety and 656 non-safety applications is in progress. Expected communication 657 range in line of sight is around 500m. 659 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 660 provided by one ore more IEEE 802.11a/b/g network interfaces. 662 o IPv6: this block represents the IPv6-based network layer protocol 663 currently defined by ISO. The specification of this layer is 664 currently under discussion. Several scenarios are proposed, one 665 for IP communications without mobility management, one for IP 666 communications with host-mobility management (MIPv6), and one with 667 IP communications with network mobility management (NEMO). The 668 former two are out of scope of the present document. This block 669 comprises the NME (Network Management Entity) which is able to 670 interoperate with other layers in order to negotiate priority flow 671 requirements 673 o CALM FAST: this block represents a network protocol specifically 674 designed by ISO TC204 WG16 for time critical safety applications 675 and running exclusively over IEEE 802.11p. Both non-IP and IPv6 676 CALM Aware applications may use CALM FAST. Non-IP applications 677 uses it directly as the tranport. 679 o CALM Aware Applications (IPv6 and non-IP): this block represents 680 specifically designed ITS applications. CALM Aware applications 681 are ranged into IP and non IP applications. This block comprises 682 the CME (CALM Management Entity) which is able to interoperate 683 with lower layers in order to negotiate priority flow 684 requirements. Non-IP applications uses CALM FAst as the transport 686 3.2.2. IPv6 Deployment 688 The CALM architecture includes IPv6 as mandatory part of its 689 specified protocol architecture. 691 The following informational list briefly summarizes currently 692 discussed design concepts: 694 o in order to avoid address resolution procedures, vehicles use only 695 IPv6 addresses with as Interface Identifier an EUI-64 identifier 696 derived from the MAC address. Privacy issues described in 697 [RFC3041] are strongly alleviated through the use of temporary, 698 changing MAC addresses, which are assigned in a set to every 699 vehicle (as part of their assigned "pseudonyms"); 701 o according to the current availability of infrastructure 702 connectivity, OBUs can use (at least) 2 types of globally routable 703 IPv6 addresses: an IPv6 address configured using standard IPv6 704 stateless address configuration from Router Advertisements sent by 705 RSUs connected to a network infrastructure and an IPv6 address 706 temporarily or permanently assigned to the vehicle belonging to a 707 home network and not varying while the vehicle changes its point- 708 of-attachment to the Internet. The former globally routable IPv6 709 address is used as the NEMO Care-of Address (CoA) and the latter 710 as the NEMO Home Address (HoA). In addition, a self-generated 711 IPv6 address with as prefix part a pre-defined IPv6 prefix (either 712 reserved for ISO CALM communications or a general purpose one) may 713 be used for ad-hoc communications with other OBUs; 715 o RSUs can either act as IPv6 Access Routers or as bridges connected 716 to external IPv6 Access Routers. Different Access Routers are 717 responsible for announcing different network prefixes with global 718 validity. As a consequence, when roaming between different Access 719 Routers, vehicles experience layer 3 handovers. 721 3.2.3. Scope of NEMO 723 In all the methods for use of IPv6 in the CALM architecture as 724 described above, the IPv6 layer is meant to be enhanced with Mobility 725 Support. As a vehicle includes a set of attached devices (AUs), NEMO 726 Basic Support is the default protocol selected by ISO for maintaining 727 ongoing sessions during L3 handovers. 729 3.3. ETSI TC ITS 731 The European Telecommunications Standards Institute (ETSI) Technical 732 Committee (TC) Intelligent Transport Systems (ITS) was established in 733 October 2007 with the goal of developing and maintaining standards, 734 specifications and other deliverables to support the development and 735 the implementation of ITS service provision. ETSI TC ITS has been 736 identified by European industries and institutions as the reference 737 standardization body for the development of European ITS standards. 738 To date, a formal mandate from the European Commission to ETSI TC ITS 739 to develop European ITS standards has not been approved and is still 740 under discussion. 742 ETSI TC ITS is going to develop standards and profiles of existing 743 standards based on the requirements and recommendations of the 744 aforementioned Car2Car Communication Consortium, ISO TC 204 WG 16 745 (CALM) and the results of various European research projects. To 746 date no ETSI TC ITS standard draft is publicly available, nor can be 747 made available via liaisons. 749 ETSI TC ITS is expected to harmonize the system and protocol 750 architectures described above. Among others, ETSI TC ITS will 751 produce standards defining the communication architecture 752 [ETSI-TS-102-665], an European profile standard for 802.11p 753 [ETSI-ES-202-663], a networking layer providing geographic addressing 754 and forwarding, the way IPv6 packets can be transported by this 755 geographic networking layer. More interaction between ETSI TC ITS 756 and the IETF is expected in the near future especially with respect 757 to the last item. 759 It is expected that in a following version of this draft sections 760 Section 3.1 and Section 3.2 will be merged based on the architecture 761 defined by ETSI TC ITS, which is not available to date. The 762 requirements defined in this document are to be considered valid for 763 ETSI TC ITS deployments too, as they have been agreed by the two main 764 contributors to ETSI TC ITS. As an informational reference, the 765 European project COMeSafety has produced a draft architecture 766 description which is being used as basis for the ETSI TC ITS 767 architecture [COMeSafety-Arch-2.0]. 769 4. NEMO Example Use Cases 771 In this section, the main use cases are listed that have been 772 identified by the C2C-CC and ISO for usage of NEMO: notification 773 services, peer-to-peer applications, upload/download services, 774 navigation services, multimedia applications. 776 4.1. Notification Services 778 A generic notification service delivers information to subscribers by 779 means of the Internet. After subscribing the service with a 780 provider, a user is notified when updates are available. Example 781 services are weather, traffic or news reports, as well as commercial 782 and technical information from the car producer or other companies. 784 In this use case, a pre-defined address belonging to the MNP is 785 registered to the service provider. The service provider sends the 786 updates to this address which does not change while the vehicle 787 changes point of attachment. 789 4.2. Peer-to-peer Applications 791 A generic peer-to-peer application exchanges data directly between 792 vehicles, without contacting any application server. Data traffic 793 goes through a network infrastructure (V2I) or directly between cars 794 when the infrastructure is not available (V2V). Example applications 795 are vehicle-to-vehicle instant messaging (chat) and off-line 796 messaging (peer-to-peer email), vehicle-to-vehicle voice over IP and 797 file exchange. 799 4.3. Upload and Download Services 801 A generic upload/download service via the Internet consists in simple 802 file exchange procedures with servers located in the Internet. The 803 service is able to resume after a loss of connectivity. 805 4.4. Vehicles Monitoring 807 Vehicles monitoring services allow car manufacturers, car garages and 808 other trusted parties to remotely monitor vehicle statistics. Data 809 is collected by an AU and sent by the OBU to the service center via 810 the Internet. 812 As an example, car manufacturers or garages offering this service 813 could deploy NEMO Home Agents and application servers to serve 814 thousands of cars. 816 4.5. Infotainment Applications 818 TBD by ISO CALM 820 4.6. Navigation Services 822 TBD by ISO CALM 824 5. NEMO Route Optimization Scenarios 826 In this section, operational characteristics of automotive 827 deployments of NEMO are described that are relevant for the design of 828 Route Optimization techniques. In particular a restriction of the 829 general solution space for RO and motivations for RO requirements 830 described in Section 6 are provided. 832 With respect to the classification of NEMO Route Optimization 833 scenarios described in [RFC4889], the non-nested NEMO RO case 834 (Section 3.1) is considered as the most important for the automotive 835 deployment. However, MIPv6-enabled AUs (i.e. VMNs) and nested NEMOs 836 are allowed in ISO CALM but not specifically addressed in the 837 specifications. 839 The requirements defined in this document refer to RO between MR and 840 CE (Correspondent Entity). According to the automotive use cases, 841 the CE can be: 843 1. Another vehicle, i.e. another automotive MR. 845 2. A dedicated node (host or router) installed on the roadside (2a) 846 or in the Internet (2b) for automotive applications. 848 3. An arbitrary node in the Internet. 850 In cases 1 and 2, the CE is a newly deployed entity. Whereas the 851 communicating peers in case 1 are obvious, case 2 includes for 852 example information points installed along the road, control centers, 853 notification points and infotainment service providers located in the 854 infrastructure. 856 The suboptimal routing due to the lack of RO has the most negative 857 impact when the topological distance between MR and CE is 858 considerably smaller than between MR and HA. This is highly likely 859 to occur in case 1 (e.g. two neighboring vehicles communicating with 860 each others) and case 2a (e.g. vehicles receiving updates from 861 information points installed on the roadside). For these two cases, 862 the suboptimal routing might represent a limiting factor for the 863 system performance and, in turn, a limiting factor for the deployment 864 of NEMO. 866 In cases 2b and 3, the impact of suboptimal routing depends on the 867 arbitrary CE topological position. At this point of time no 868 particular assumption can be made on the topological position of CE 869 in case 2b and, obviously, in case 3. Consequently, the case 1 and 870 2a deserve a higher priority with respect to the definition of a NEMO 871 RO solution for automotive applications. 873 Any available information about the geographical or topological 874 position of the CE is relevant for the MR in order to apply RO. In 875 this respect, external information might be used to define policy 876 rules specifying whether or not RO should be enabled with a 877 particular pre-defined CE, which is known in advanced to the MR. 879 6. NEMO Route Optimization Requirements 881 Figure 5 summarizes which requirement applies to both C2C-CC and ISO, 882 or only one of these. 884 6.1. Req 1 - Separability 886 An RO technique, including its establishment procedure, MUST have the 887 ability to be enabled on a per-flow basis according to pre-defined 888 policies. Policies criteria for the switching to RO MUST at least 889 include the end points' addresses and the MNP for which RO is to be 890 established. Policies MAY change dynamically. 892 In some scenarios it might not be beneficial to activate RO due to 893 the intermittent connectivity. Based on external information, a 894 management instance of the MR can dynamically specify policies for RO 895 establishment of a particular IPv6 flow. In this document, the term 896 flow is not referred to the Flow Label field defined in [RFC2460] but 897 more generically to refer to an exchange of IPv6 packets between two 898 particular end points. No special requirements is define regarding a 899 finer distinction of flows. The policies mentioned in this 900 requirement can prevent unnecessary or unwanted RO sessions to take 901 place (e.g. DNS queries, location privacy protection, etc.). In 902 case of MRs serving multiple MNPs (e.g. served by different HAs or 903 MNPs that vary only in the length), the policies allow for specifying 904 for which MNP RO should be established (i.e. prefix including 905 length). 907 6.2. Req 2 - RO Security 909 This requirements consists of the following sub-requirements: 911 o The RO scheme MUST permit the receiver of a BU to validate an MR's 912 ownership of the CoAs claimed by an MR. 914 o The RO scheme MUST ensure that only explicitly authorized MRs are 915 able to perform a binding update for a specific MNP. 917 o If the RO scheme makes use of cryptographic material, this SHOULD 918 be the same material already installed on vehicles as defined by 919 automotive consortia. 921 6.3. Req 3 - Binding Privacy Protection 923 An RO technique MUST protect the MR's binding privacy against on-path 924 nodes' attacks. 926 In other words, the RO technique must not expose the content of the 927 binding (CoA, MNP/HoA) to nodes other than the intended CEs. The 928 rationale behind this requirement is the fact that mechanisms that 929 are being designed by the automotive industry for privacy protection 930 might be made ineffective if the content of the binding is revealed. 931 In fact, a common approach in automotive applications consists of 932 equipping a vehicle with a set of CoAs to be used for limited time 933 intervals. Consecutive binding updates, where the MNP/HoA is 934 constant and transmitted as clear text, could be used to unveil the 935 user's identity by linking together the different addresses. 937 6.4. Req 4 - Multihoming 939 An RO technique MUST allow an MR to be simultaneously connected to 940 multiple access networks, having multiple prefixes and Care-Of 941 Addresses in a MONAMI6 context, and be served by multiple HAs. 943 Adopting the classification of [RFC4980], the automotive NEMO 944 deployment includes at least the cases (1,n,n), (n,1,1) and (n,n,n). 945 Case (1,n,n) takes place when a single MR is installed in the 946 vehicle's OBU but different MNPs/HAs are used for different purposes 947 (e.g. vehicle monitoring, traffic information, infotainment) or to 948 achieve better fault tolerance. Cases (n,1,1) and (n,n,n) take place 949 when the vehicle's connectivity is enhanced by installing additional 950 NEMO MRs in a separated unit in a later stage. An RO technique must 951 not prevent any of these three configurations from working properly. 953 6.5. Req 5 - Minimum Signaling 955 An RO technique MUST be capable of minimum signaling. The number of 956 per-flow signaling messages for the establishment of RO SHOULD be 957 smaller than TBD and the number of per-flow signaling messages upon a 958 layer 3 handover should be smaller than TBD. 960 6.6. Req 6 - Switching HA 962 An RO technique MUST allow a MR to switch from one HA to another one 963 topologically distant from the first one. 965 A vehicle is typically served by various network access operators, 966 simultaneously, and over a period of time depending on its 967 geographical location. Since Internet services providers providing 968 the HA service and the MNP may be topologically distant from the OBU, 969 multiple HAs belonging to the same Internet service operator might be 970 deployed in order to decrease transmission delays. In such a case 971 the RO solution shall allow the OBU to select the best HA according 972 to its location and to switch from one HA to another HA. 974 +====================================================+ 975 | | C2C-CC | ISO CALM | 976 +====================================================+ 977 | #1: Separability | x | x | 978 +--------------------------------+--------+----------+ 979 | #2: RO Security | x | x | 980 +--------------------------------+--------+----------+ 981 | #3: Privacy Protection | x | x | 982 +--------------------------------+--------+----------+ 983 | #4: Multihoming | x | x | 984 +--------------------------------+--------+----------+ 985 | #5: Efficient Signaling | x | x | 986 +--------------------------------+--------+----------+ 987 | #6: Switching HAs | | x | 988 +====================================================+ 990 Figure 5: C2C-CC and ISO CALM requirements 992 7. IANA Considerations 994 This document does not require any IANA action. 996 8. Security Considerations 998 This document does not specify any protocol therefore does not create 999 any security threat. However, it specifies requirements for a 1000 protocol that include security and privacy issues. 1002 9. Acknowledgments 1004 The authors would like to thank the members of TC204 WG16 and the 1005 work groups PHY/MAC/NET and APP of the C2C-C Consortium. The authors 1006 particularly appreciated the helpful support of Carlos Bernardos 1007 Cano, Tim Leinmueller, Bernd Bochow, Andras Kovacs and Matthias 1008 Roeckl. 1010 10. References 1012 10.1. Normative References 1014 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1015 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1016 RFC 3963, January 2005. 1018 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1019 in IPv6", RFC 3775, June 2004. 1021 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1022 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1023 January 2001. 1025 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1026 Networks", RFC 2464, December 1998. 1028 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1029 (IPv6) Specification", RFC 2460, December 1998. 1031 10.2. Informative References 1033 [RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network 1034 Mobility Route Optimization Problem Statement", July 2007. 1036 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 1037 Mobility Route Optimization Solution Space Analysis", 1038 July 2007. 1040 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1041 Terminology", RFC 4885, July 2007. 1043 [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 1044 Multihoming in Network Mobility Support", RFC 4980, 1045 October 2007. 1047 [I-D.ietf-mext-aero-reqs] 1048 Eddy, W., Ivancic, W., and T. Davis, "NEMO Route 1049 Optimization Requirements for Operational Use in 1050 Aeronautics and Space Exploration Mobile Networks", 1051 draft-ietf-mext-aero-reqs-02 (work in progress), May 2008. 1053 [c2ccc-web] 1054 "Car2Car Communication Consortium Official Website", 1055 http://www.car-2-car.org/ . 1057 [c2ccc-manifesto] 1058 "Car2Car Communication Consortium Manifesto", http:// 1059 www.car-2-car.org/fileadmin/downloads/ 1060 C2C-CC_manifesto_v1.1.pdf , May 2007. 1062 [calm-handbook] 1063 "The CALM Handbook", http://www.calm.hu , May 2005. 1065 [ISO-21210-CALM-IPv6-Networking] 1066 "Intelligent Transport Systems - Continuous air interface, 1067 long and medium range (CALM) - IPv6 Networking", ISO 1068 Draft DIS 21210, February 2009. 1070 [ISO-21217-CALM-Architecture] 1071 "Intelligent Transport Systems - Communications access for 1072 land mobiles (CALM) - Architecture", ISO Draft DIS 21217, 1073 June 2008. 1075 [IEEE.802-11p-d3-0] 1076 "Draft Amendment to Standard for Information Technology . 1077 Telecommunications and information exchange between 1078 systems . Local and Metropolitan networks . Specific 1079 requirements - Part 11: Wireless LAN Medium Access Control 1080 (MAC) and Physical Layer (PHY) specifications: Amendment 1081 3: Wireless Access in Vehicular Environments (WAVE)", 1082 IEEE P802.11p/D1.0, February 2006. 1084 [ETSI-TS-102-665] 1085 "ETSI TS 102 665 - Intelligent Transport Systems (ITS); 1086 Vehicular Communications; Architecture", ETSI TC ITS 1087 Draft (work in progress), January 2009. 1089 [ETSI-ES-202-663] 1090 "ETSI ES 202 663 - Intelligent Transport Systems; European 1091 profile standard on the physical and medium access layer 1092 of 5 GHz ITS", ETSI TC ITS Draft (work in progress), 1093 January 2009. 1095 [COMeSafety-Arch-2.0] 1096 "European ITS Communication Architecture Overall Framework 1097 Proof of Concept Implementation - Version 2.0", http:// 1098 www.comesafety.org/fileadmin/uploads/architecture/ 1099 COMeSafety_European_Communications_Architecture.pdf (work 1100 in progress), October 2008. 1102 Authors' Addresses 1104 Roberto Baldessari 1105 NEC Europe Network Laboratories 1106 Kurfuersten-anlage 36 1107 Heidelberg 69115 1108 Germany 1110 Phone: +49 6221 4342167 1111 Email: roberto.baldessari@nw.neclab.eu 1113 Thierry Ernst 1114 INRIA 1115 INRIA Rocquencourt 1116 Domaine de Voluceau B.P. 105 1117 Le Chesnay, 78153 1118 France 1120 Phone: +33-1-39-63-59-30 1121 Fax: +33-1-39-63-54-91 1122 Email: thierry.ernst@inria.fr 1123 URI: http://www.nautilus6.org/~thierry 1124 Andreas Festag 1125 NEC Deutschland GmbH 1126 Kurfuersten-anlage 36 1127 Heidelberg 69115 1128 Germany 1130 Phone: +49 6221 4342147 1131 Email: andreas.festag@nw.neclab.eu 1133 Massimiliano Lenardi 1134 Hitachi Europe SAS Sophia Antipolis Laboratory 1135 Immeuble Le Theleme 1136 1503 Route des Dolines 1137 Valbonne F-06560 1138 France 1140 Phone: +33 489 874168 1141 Email: massimiliano.lenardi@hitachi-eu.com