idnits 2.17.1 draft-karagiannis-problem-statement-geonetworking-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2013) is 3825 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Georgios Karagiannis 2 Internet-Draft Geert Heijenk 3 Intended status: Informational University of Twente 4 Expires: May 04, 2014 Andreas Festag 5 Technical University Dresden & NEC Laboratories Europe 6 Alexandru Petrescu 7 CEA 8 Alison Chaiken 9 Mentor Embedded Software Division 10 November 04, 2013 12 Internet-wide Geo-networking Problem Statement 13 draft-karagiannis-problem-statement-geonetworking-01 15 Abstract 17 This document describes the need of specifying Internet-wide 18 location-aware forwarding protocol solutions that provide 19 packet routing using geographical positions for packet transport. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 04, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Use cases and scenarios . . . . . . . . . . . . . . . . . . . . 6 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 4. Open Design Issues . . . . . . . . . . . . . . . . . . . . . . 14 64 5. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 16 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 69 10. Informative References . . . . . . . . . . . . . . . . . . . 20 70 11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . 22 71 1. Introduction 73 1.1 Motivation 75 Internet-based applications use IP addresses to address a node that 76 can be a host, a server or a router. Scenarios and use cases exist 77 where nodes are being addressed using their geographical 78 location instead of their IP address. The most obvious use cases are 79 related to Intelligent Transportation Systems (ITS) and vehicular 80 networking, environmental monitoring, consumer electronic devices 81 (e.g. cameras) and scientific instruments. In this document we will 82 mainly focus on ITS and vehicular networking. An ITS use case is, for 83 example, a traffic jam or a chain collision, where all vehicles 84 heading towards the potential hazard should be warned. In particular, 85 for vehicles ahead that are moving away from the hazardous location, 86 the information is not relevant anymore. In such dangerous situation 87 geo-networking can offer great support to applications that require 88 geographical addressing. 90 Internet-wide Geo-Networking is a location-aware forwarding protocol 91 that provides packet routing using geographical positions for packet 92 transport over the Internet. Vehicular networking can be considered 93 as one of the most important enabling technologies required to 94 implement a myriad of applications related to vehicles, vehicle 95 traffic, drivers, passengers and pedestrians. Two main types of 96 vehicle communication networks can be distinguished. In the Vehicle- 97 to-Infrastructure (V2I) communication network packets are exchanged 98 among vehicles using an infrastructure that can be Internet-wide. The 99 second type is Vehicle-to-Vehicle (V2V) communication, where packets 100 are exchanged among vehicles without the need for a communication 101 infrastructure. Hybrid scenarios that combine V2V and V2I 102 communication appear reasonable. 104 Intelligent Transportation Systems aim to improve the operation of 105 vehicles, manage vehicle traffic, assist drivers with safety and 106 other information, along with provisioning of convenience 107 applications. Prime examples of ITS services include automated toll 108 collection systems, driver assist systems and other information 109 provisioning systems. Over the last decade, the development of ITS 110 services has been backed up by coordinated efforts for 111 standardization and formation of consortia and other governmental and 112 industrial bodies that aim to set the guiding principles, 113 requirements, and first takes on solutions for ITS-related 114 communication systems that primarily involve vehicles and users 115 within vehicles. 117 The main challenges that are associated with Internet-wide geo- 118 networking are: 119 o) support of geo-addressing, where geographical information 120 should be available in the addressing mechanism, such that 121 packets can be forwarded to a target geographical area. The 122 geographical area may either be specified by the source 123 (application) or might not be specified at all. 125 o) support of Internet-wide geo-routing, where data packets that 126 are generated by source nodes placed anywhere in the 127 Internet are forwarded over multiple hops by using the 128 position of the destination node(s) and the positions of 129 intermediate nodes for the routing decisions. 130 o) creation of a forwarding method that comprises (1) a local- 131 computer decision algorithm which can deterministically compare 132 IP/geographical addresses present in a packet to IP/geographical 133 addresses present in a local database, (2) a (mixed IP and 134 geographical) database topology distribution algorithm among 135 several computers, and (3) an IP/geographical path construction 136 algorithm which acts on the IP/geographical database. 137 o) the use of a single consensual geodesic datum which may be used 138 by present and future GNSSs (Global Navigation Satellite 139 Systems) by as many as possible network operators, and agreed 140 datum conversion methods. 141 o) representation of precision in IP addressing. IP addresses are 142 precise and unique, whereas geographical coordinates involve 143 notions of precision and accuracy. 145 Geo-addressing: 146 In [RFC2009], three families of solutions are described to 147 integrate the concept of physical location into the current 148 design of Internet that relies on logical addressing. These 149 families of solutions are: (1) Application layer solutions, (2) 150 GPS-Multicast solution. (3) Unicast IP routing extended to 151 deal with GPS addresses. In particular, [RFC2009] specifies how GPS 152 positioning is used for destination addresses. A GPS (Global 153 Positioning System) address could be represented by using: (1) closed 154 polygons, such as circle(center point, radius), where, any node that 155 lies within the defined geographic area could receive a message, (2) 156 site-name as a geographic access path, where a message can be sent to 157 a specific site by specifying its location in terms of real-word 158 names such as names of site, city, township, county, state, etc. 159 [ETSI-EN-302-636-4-1] specifies geographical addressing for point-to- 160 point and point-to-multipoint communications over short range 161 wireless communication technologies, such as ITS-G5, for vehicle-to- 162 vehicle communication. 163 Also other solutions for geo-addressing have been specified, but 164 none of them have been applied for Internet-wide geo-networking. 166 Geo-routing: 167 A significant number of geo-routing protocols are available, see 168 e.g., [KaAl11] for a survey. These protocols can mainly be divided in 169 two categories. The first category focuses on unicast routing, and 170 the second covers broadcast routing. [ETSI-EN-302-636-4-1] specifies 171 an sub-IP-routing protocol with unicast and broadcast forwarding 172 schemes for multi-hop and ad hoc communication among vehicles and 173 between vehicles and roadside station utilizing geographical 174 positions. 175 [ETSI-EN-302-636-6-1] has standardized the transmission of IPv6 176 packets over ETSI GeoNetworking that can be used for the forwarding 177 of IPv6 packets using the position of the destination node(s) and the 178 positions of intermediate nodes for the routing decisions. 180 However, these geo-routing protocols are not designed for Internet- 181 wide geo-networking. 183 1.2 Goal 185 Internet-wide geo-networking targets at IP-layer extensions that 186 allow source nodes anywhere in the Internet to geo(broad/any)cast 187 packets to all/any node(s) with geo-location awareness within an 188 arbitrary, source-specified destination area. 190 1.3. Terminology 191 On Board Unit (OBU) 193 a processing and communication feature that is located in a 194 vehicle, which provides an application runtime environment, 195 positioning, security and communications functions and interfaces 196 to other vehicles including human machine interfaces. OBU is also 197 known as OBE (On-Board Equipment). 199 Road Side Unit (RSU) 201 equipment located along highways, at traffic intersections and 202 other type of locations where timely communications with vehicles 203 are needed. Each RSU includes DSRC (Direct Short Range Radio, 204 e.g., IEEE 802.11p) radio, a positioning system and a router to 205 route packets back through the infrastructure network. RSU is 206 also known as RSE (Road Side Equipment) 208 Vehicle-to-Vehicle (V2V) 210 (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic 211 communication mode in which data packets are exchanged between two 212 vehicles, either directly or traversing multiple vehicles, without 213 involving any node in the infrastructure. 215 Vehicle-to-Infrastructure (V2I) 217 generic communication mode in which data packets sent by a vehicle 218 traverse a communication infrastructure. 220 Infrastructure-to-Vehicle (I2V) 222 generic communication mode in which data packets received by a 223 vehicle traverse a communication infrastructure. 225 Host vehicle 227 a vehicle that uses the ITS application. 229 Traffic safety application 231 application that is primarily applied to decrease the probability 232 of traffic accidents and the loss of life of the occupants of 233 vehicles. 235 Geographically-scoped broadcast (or geocast), see [C2C-CC_Manifesto] 237 forwarding mechanism that is used to transport data from a single 238 node to all nodes within a target area that is specified by 239 geographical positions, e.g. defined by a geographic region. The 240 geographic region is determined by a geometric shape, such as 241 circle and rectangle. 243 Geographical Unicast (or geounicast) see [C2C-CC_Manifesto] 245 Forwarding mechanism that is used for unidirectional data 246 transport from a single node (source) to a single node 247 (destination) by means of direct communication or by multiple hops 248 based on georgraphic specific addresses that include node 249 identifier, geographical position, and time information. 251 Geographically-scoped anycast (or geoanycast), see [C2C-CC_Manifesto] 253 forwarding mechanism that transports data from a single node to 254 any of the nodes within a geographically area. Compared to 255 geographically-scoped broadcast, with geographically-scoped 256 anycast after a packet reaches one vehicle located in the 257 specified geographic area, it stops being forwarded to other 258 vehicles located in the same area. 260 1.4. Organization of This Document 262 This document is organized as follows. Section 2 describes several 263 Geo-networking use cases an scenarios. Section 3 describes the 264 requirements that need to be fulfilled by the Internet-wide 265 Geo-networking solution. The open design issues are discussed in 266 Section 4. Section 5 describes possible solutions of realizing the 267 Internet-wide Geo-networking solution. Section 6 describes the 268 security considerations. The acknowledgement section is provided in 269 Section 8. 271 2. Use cases and scenarios 273 2.1 Scenario 275 The scenario that is considered in this document for the support of 276 Internet-wide geo-networking is shown in Figure 1. This scenario 277 shows a source node, which can be located anywhere, and is 278 interconnected with access routers via the Internet. The packets 279 generated by the source are routed through the Internet using the 280 typical destination address based routing up to the access routers. 281 Geo-routing is then used to forward the packets towards the 282 destination area where the recipients are located. In the destination 283 area the packets are geo-broadcasted to all the recipients within the 284 destination area. 286 Coverage 287 Area 288 - ~ - 289 ` ` 290 ' ' 291 +------+ ` ` 292 ___|Access|____` ` 293 +----------+ / |Router| +`-----------------`+ 294 / \ / +------+ | ` O ` | 295 +------+ / \/ | ' - ~ - ' | 296 |Source|___/ Internet \ | ` O ` | 297 | Node | \ / | ' - ~ - ' | 298 +------+ \ /\ +------+ | ` ` | 299 \ / \____|Access|____, O `| 300 +----------+ |Router| |` `| 301 +------+ | ` ` | 302 | ' ' | 303 | ` - ~ - ` | 304 | Destination Area | 305 +-------------------+ 307 O Destination Nodes 309 Figure 1: Internet-wide geo-networking scenario 311 2.2 Use cases 313 The use cases considered in this section are vehicular networking use 314 cases. However, Internet-wide geo-networking can be applied to any 315 use case that is similar to these vehicular use cases where source 316 nodes anywhere in the Internet are able to geo(broad/any)cast packets 317 to all/any node(s) with geo-location awareness within an arbitrary, 318 source-specified destination area. 320 Vehicular networking can be considered as one of the most important 321 enabling technologies needed to support various types of traffic 322 applications, such as infotainment type of applications, traffic 323 efficiency & management and traffic safety applications. 325 Traffic safety applications are those that are primarily applied to 326 decrease the probability of traffic accidents and the loss of life of 327 the occupants of vehicles. Note that VSC and VSC-A projects focus on 328 vehicle-to-vehicle safety. Another project called CICAS-V 329 (Cooperative Intersection Collision Avoidance Systems - Violation) 330 discuss the traffic safety application over vehicle-to-infrastructure 331 communication. 333 Traffic efficiency & management applications are focusing on 334 improving the vehicle traffic flow, traffic coordination and traffic 335 assistance. Moreover, traffic efficiency & management applications 336 are focusing on providing updated local information, maps and in 337 general messages of relevance limited in space and/or time. 339 Infotainment types of applications are the applications that are 340 neither traffic safety applications nor traffic efficiency & 341 management applications. Such applications are supported by e.g., 342 media downloading use cases. 343 Such vehicular applications are defined by several initiatives: 344 o the USA VSC (Vehicular Safety Communications) and VSC-A (VSC- 345 Applications) projects. 347 O the European Car-to-Car Communication Consortium (C2C-CC) 348 [C2C-CC] and the ETSI TC ITS [ETSI TC ITS], [ETSI-TR-102-638] 349 with the additional support of some EU funded research projects, 350 such as SEVECOM [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS]. 351 PREDRIVE-C2x [PREDRIVE-C2x], GEONET [GEONET]. 353 The USA Vehicle Safety Communications (VSC) consortium, see 354 [VSC], is supported among others by CAMP (Crash Avoidance Metrics 355 Partnership). CAMP is a partnership that has been formed in 1995 by 356 Ford Motor Company and General Motors Corporation. The objective of 357 CAMP is to accelerate the implementation of crash avoidance 358 countermeasures to improve traffic safety by investigating and 359 developing new technologies. VSC has been realized in two phases. 361 The descriptions of the relevant traffic safety applications are 362 taken from [draft-karagiannis-traffic-safety-requirements]. 364 The first phase, denoted as VSC started in 2002 and ended in 2004. 365 The second phase started in 2006 and ends in 2009. VSC focused and 366 is focusing on traffic safety related applications. In 2006, The VSC 367 2 consortium in cooperation with USDOT initiated a three-year 368 collaborative effort in the area of wireless-based safety 369 applications under the Vehicle Safety Communications - Applications 370 (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the 371 following members; Mercedes-Benz, Ford, General Motors, Honda & 372 Toyota. The main goal of this project is to develop and test 373 communications-based vehicle safety systems to determine whether 374 vehicle positioning in combination with the DSRC at 5.9 GHz can 375 improve the autonomous vehicle-based safety systems and/or enable new 376 communication-based safety applications. 378 The WAVE Short Message Protocol [IEEE 1609.3] was designed 379 specifically to offer a more efficient (smaller size) alternative to 380 TCP or UDP over IP, for 1-hop messages that require no routing. 382 The European Car-to-Car Communication Consortium (C2C-CC) is 383 an industry consortium of car manufacturers and electronics suppliers 384 that focuses on the definition of an European standard for vehicular 385 communication protocols. 387 The European Telecommunications Standards Institute (ETSI) Technical 388 Committee (TC) Intelligent Transport Systems (ITS) was established in 389 October 2007 with the goal of developing and maintaining standards, 390 specifications and other deliverables to support the development and 391 the implementation of ITS service provision. 393 It is foreseen that ETSI ITS will be the reference standardization 394 body of the future European ITS standards, and actually the C2C-CC 395 provides recommendations to the ETSI TC ITS. 397 The following subsections describe use cases that can be implemented 398 using either V2I or V2V. When V2V is applied, the use of Internet- 399 wide Geo-networking solution is not required. 401 2.2.1 Traffic safety use cases 403 In VSC, see [VSC] 34 vehicle application scenarios have been 404 identified, evaluated and ranked. From this evaluation, a subset of 405 eight significant near- and mid-term traffic safety applications have 406 been selected: (1) cooperative forward collision warning, (2) curve 407 speed warning, (3) pre-crash sensing, (4) traffic signal violation 408 warning, (5) lane-change warning, (6) emergency electronic brake 409 light, (7) left turn assistant, (8) stop sign movement assistant. A 410 brief description of these applications is given below (for more 411 details, see [VSC]): 413 o Traffic signal violation warning: it informs and warns the driver 414 to stop at a legally prescribed location in the situation that the 415 traffic signal indicates a stop and it is estimated that the 416 driver will be in violation. 418 o Curve speed warning - Rollover Warning: aids the driver in 419 negotiating speeds at appropriate curves. 421 o Emergency Electronic Brake Lights: it is used to inform vehicles 422 that a vehicle brakes hard. In particular in this situation a 423 warning message is sent to the vehicles moving behind the vehicle 424 that brakes hard. 426 o Pre-crash sensing: it prepares the driver for an unavoidable and 427 imminent collision. 429 o Cooperative Forward Collision Warning: aids the driver in 430 mitigating or avoiding collisions with the rear-end vehicles in 431 the forward path of travel through driver notification or warnings 432 of an unavoidable collision. This application does not attempt to 433 control the vehicle to avoid an unavoidable collision. 435 o Left Turn Assistant: it informs the driver about oncoming traffic 436 in order to assist him in making a left turn at a signalized 437 intersection without a phasing left turn arrow. 439 o Lane Change Warning: it warns the driver if an intended lane 440 change may cause a crash with a nearby moving vehicle. 442 o Stop Sign Movement Assistance: it warns the driver that the 443 vehicle is nearby an intersection, which will be passed after 444 having stopped at a stop sign. 446 In the VSC-A project an additional investigation has been performed, 447 on traffic safety applications that can be used in crash immitment 448 scenarios, see [VSC-A]. The following 7 traffic safety applications 449 have been selected for implementation in the VSC-A test bed. 451 o Emergency Electronic Brake Light: is a traffic safety application 452 that is the same as the Emergency Electronic Brake Light 453 application defined in the VSC project, see above. 455 o Forward Collision warning: is a traffic safety application that is 456 the same as the Cooperative Forward Collision Warning application 457 defined in the VSC project, see above. 459 o Intersection Movement Assist: is a traffic is intended to warn the 460 driver of a vehicle when it is not safe to enter an intersection 461 due to high collision probability with other vehicles. It is 462 similar to the Stop Sign Movement Assistance application defined 463 in the VSC project, see above. 465 o Blind Spot Warning & Lane Change Warning: it is similar to the 466 Lane Change Warning application defined in the VSC project, see 467 above. In the Blind Spot Warning application the driver of a host 468 vehicle is informed that another vehicle is moving in an adjacent 469 lane and that this vehicle is positioned in a blind spot zone of 470 the host vehicle. 472 o Do Not Pass Warning: this is an application that was not 473 investigated in the VSC project. It is intended to warn the 474 driver of a host vehicle during a passing maneuver attempt when a 475 slower vehicle, ahead and in the same lane, cannot be safely 476 passed using a passing zone which is occupied by vehicles with the 477 opposite direction of travel. In addition, the application 478 provides advisory information that is intended to inform the 479 driver of the host vehicle that the passing zone is occupied when 480 a passing maneuver is not being attempted. 482 o Control Loss Warning: this is an application that was not 483 investigated in the VSC project. It is intended to enable the 484 driver of a host vehicle to generate and broadcast a control- loss 485 event to surrounding vehicles. Upon receiving this information 486 the surrounding vehicle determines the relevance of the event and 487 provides a warning to the driver, if appropriate. 489 The Car to Car Communication Consortium specified a number of traffic 490 safety use cases. The following three are considered as being the 491 main traffic safety use cases, see [C2C-CC_Manifesto]: 493 o Cooperative Forward Collision Warning: this use case tries to 494 provide assistance to the driver. Vehicles share (anonymously) 495 information such as position, speed and direction. This enables 496 the prediction of an imminent rear-end collision, by each vehicle 497 monitoring the behavior of its own driver and the information of 498 neighboring vehicles. If a potential risk is detected, the 499 vehicle warns the driver. 501 This use case requires: the ability for all vehicles to share 502 Information with each other over a distance of about 20 to 200 503 meters, accurate relative positioning of the vehicles, trust 504 relationships among the vehicles and a reasonable market 505 penetration (at least 10%). 507 o Pre-Crash Sensing/Warning: this use case is similar to the 508 previous one, but in this case the collision is identified as 509 unavoidable, and then the involved vehicles exchange more precise 510 information to optimize the usage of actuators such as airbags, 511 seat belt pre-tensors, etc... 512 This use case requires basically the same abilities that the 513 previous one, restricting the needed communication range to 20 to 514 100 meters, and adding the requirement of a fast and reliable 515 connection between the involved cars. 517 o Hazardous Location V2V Notification: this use case is based on 518 the share of information that relates to dangerous locations on 519 the road, among vehicles, and also among vehicles and the road 520 infrastructure. 521 On one hand, vehicles may detect the dangerous locations from 522 sensors in the vehicle or from events such as the actuation of 523 the ESP (Electronic Stability Program). 524 On the other hand, recipients of this information may use it to 525 properly configure active safety systems and/or warn the driver. 526 This use case requires: vehicles to trust other vehicles and 527 roadside units, reasonable market penetration, the ability of 528 vehicles to share information about a specific geographic 529 location over multiple-hops and the ability to validate 530 information propagated through multiple hops. 532 2.2.2 Traffic efficiency and management use cases 534 Such applications are focusing on improving the vehicle traffic 535 flow, traffic coordination and traffic assistance and provide 536 updated local information, maps and in general, messages of 537 relevance bounded in space and/or time. Two typical groups of this 538 type of applications are speed management and co-operative 539 navigation are two typical groups of this type of applications 540 [ETSI-TR-102-638], [KaAl11]. 541 o) Speed management: 542 Speed management applications aim to assist the driver to manage 543 the speed of his/her vehicle for smooth driving and to avoid 544 unnecessary stopping. Regulatory/contextual speed limit 545 notification and green light optimal speed advisory are two 546 examples of this type. 548 o) Co-operative navigation 549 This type of applications is used to increase the traffic 550 efficiency by managing the navigation of vehicles through 551 cooperation among vehicles and through cooperation between vehicles 552 and road side units. Some examples of this type are traffic 553 information and recommended itinerary provisioning, co-operative 554 adaptive cruise control and platooning. 556 2.2.3 Infotainment Applications 558 Such applications are neither traffic safety applications nor traffic 559 efficiency & management applications and are mainly supported by 560 e.g., media downloading use cases, see [CVIS], [C2C-CC_Manifesto], 561 [ETSI-TR-102-638], [PREDRIVE-C2x], [KaAl11]: 563 o) Co-operative local services 564 This type of applications focus on infotainment that can be obtained 565 from locally based services such as point of interest notification, 566 local electronic commerce and media downloading. 568 o) Global Internet services 569 In this type of applications the focus is on data that can be 570 obtained from global Internet services. Typical examples are 571 Communities services, which include insurance and financial services, 572 fleet management and parking zone management, and ITS station life 573 cycle, which focus on software and data updates. 575 3. Requirements 577 This section includes the requirements that need to be fulfilled by 578 Internet geo-networking solutions and are based on 579 [ETSI-EN-302-636-1]. 581 3.1 Functionality requirements 583 This section describes the functionality requirements that need to be 584 supported by the Internet-wide geo-networking solution. 586 3.1.1 No changes to existing routing infrastructure 588 The Internet geo-networking solution MUST NOT impose any changes on 589 the existing Internet-wide routing infrastructure. 591 3.1.2 Minimal changes to the IP layer in source nodes 593 The changes on the IP layer used by the source nodes, i.e., the nodes 594 that are making use of Internet-wide geo-networking SHOULD be 595 minimized. 597 3.1.3 Communication mode 599 The geoanycast, geounicast and geobroadcast communication modes MUST 600 be supported by the Internet-wide geo-networking solution. 602 3.1.4 Geo-addressing 604 Geographical information MUST be available in the addressing 605 mechanism, such that packets can be forwarded to a target 606 geographical area. 608 3.1.5 Internet-wide geo-routing 610 The Internet geo-networking solution MUST enable the forwarding of 611 packets over multiple hops by using the position of the destination 612 node(s) and the positions of intermediate nodes for the routing 613 decisions. The Internet geo-routing solution SHOULD be able to 614 operate without predefining the set of possible destination areas. 616 3.1.6 Internet-wide geo-networking and IPv6 618 The Internet geo-networking solution MUST support transparently 619 the routing of IPv6 packets. 621 3.1.7 Data congestion control 623 Data congestion control functions SHOULD be supported in 624 order to keep network load at an acceptable level and eliminate 625 unnecessary duplicates of packets with limited control overhead. 627 3.1.8 Security and privacy 629 The Internet-wide geo-networking solution MUST support security 630 objectives for all supported communication modes. Security objectives 631 particularly include integrity, privacy and non-repudiation and 632 SHOULD protect the network and transport layer protocol headers. 633 In addition the Internet-wide geo-networking solution MUST also 634 protect privacy, i.e. provide confidentiality to personal data such 635 as relation between node identifier and location. 637 3.2 Performance requirements 638 This section describes the performance requirements that need to be 639 supported by the Internet-wide geo-networking solution. 641 3.2.1 Low-latency communications 643 The Internet geo-networking solution SHOULD support low latency 644 communications. This requirement mainly applies to traffic safety and 645 traffic efficiency applications. 647 3.2.2 Reliable communications 649 The Internet geo-networking solution SHOULD support reliable 650 communications with the highest reliability for traffic safety 651 messages. 653 3.2.3 Low signaling, routing and packet forwarding overhead 655 The signaling, routing and packet forwarding overhead SHOULD be 656 minimized. 658 3.2.4 Priority support 660 The Internet geo-networking solution SHOULD support packets with 661 different priorities with the highest priority for critical 662 traffic safety packets. 664 3.2.5 Scalability 666 The Internet geo-networking solution SHOULD be able to maintain its 667 performance to acceptable levels even when it is applied to: 669 o) global coverage with small geocast areas 670 o) large traffic volumes (large flows) 671 o) large number of active sources 673 4. Open Design Issues 675 This section describes the Internet wide geo-networking open design 676 issues that can be addressed by the IETF. 678 4.1 Geo-addressing in the wired Internet 680 The Standard Internet routers are not aware of geo-networking 681 functionality. Therefore, the used addresses used must be regular 682 addresses that route to / via the Access Router. 683 In particular, regarding unicast and multicast addresses the 684 following issues can be identified. 686 o) Using unicast addresses for all destination areas: does not scale 687 well and packets are sent multiple times on the wireless interface 688 o) Unicast addresses of relevant access routers: can be realized by 689 using e.g., tunneling. 690 o) Using multicast addresses to specify destination areas: A standard 691 router should be able to route packets that are using predefined 692 multicast addresses. This implies that an arbitrary, 693 source-specified destination area cannot be coded this way. 694 Alternatively, packets could be sent to a set of predefined areas 695 which together include the source-specified destination area 696 (further filtering at destination). However, consider that one 697 multicast address per access point is needed. Consider also that 698 each access point provides radio coverage to an area of 300m x 699 300m, which is approximately equal to 10^5 m^2. This would require 700 that on a global scale we will need: 5 * 10^14 / 10^5 = 5 * 10^9 701 multicast addresses to cover the earth, which will need to be 702 maintained by the routing table of a router. This is far too many 703 addresses that can be maintained by nowadays routers in their 704 routing tables. A solution could be to define larger predefined 705 areas. In this case however, many useless packet transmissions 706 will need to be supported. It can be, therefore, deduced that the 707 normal use of multicast addresses does not scale. Meaning that 708 other solutions are needed, such (1) aggregation of multicast 709 addresses into "larger" multicast addresses, (2) support of a 710 routing hierarchy for geocasting. 712 4.2 Exchanging destination area information 714 Until all routers in the Internet are geo-aware, or until a 715 sufficient level of multicast address aggregation has been achieved 716 to have a manageable total number of multicast addresses, we need a 717 way for the source node to reach the (right) first geo-aware access 718 router, e.g., RSU, (over the standard Internet). In addition to that 719 the destination area specification needs to be exchanged at this 720 first geo-aware access router. This can be achieved only if 721 there is precise knowledge about the location of this destination 722 node. The destination area specification has to be carried in the 723 packet, using one of the following options: 724 o) Specify this information in the IP destination address 725 (tunneled in wired Internet) 726 o) Use IP header extensions (not processed by standard Internet 727 routers) 728 o) Carry this information in the application layer header 730 4.3 Lookup and translation of destination area to IP address 732 When a source needs to disseminate information in a destination 733 area it should lookup and translate the destination area into a 734 standard IPv6 address of the first geo-aware access router, e.g., 735 RSU, which is routable in the standard Internet. 736 The destination area can be specified by an application at the 737 source, and does not have to coincide with known (predefined) areas, 738 e.g., corresponding with the coverage area of an AR (e.g., RSU), or 739 with the area covered by a predefined multicast address. This can be 740 realized using location databases that provide the mapping between 741 the destination area and the IPv6 address of the first geo-aware 742 access router, e.g., RSU. Examples of such location databases are: 744 o) Application specific location database 745 o) DNS extended with location records and queries 746 o) Table of known multicast addresses 748 4.4 Updating the location database 750 The location databases that stores the mapping between the 751 destination areas and the IPv6 addresses of the first geo-aware 752 access router, e.g., RSU, need to be dynamically maintained and be up 753 to date. Meaning that whenever new destination areas are identified 754 or when the mapping between the stored destination areas and the 755 associated IPv6 addresses change the location database needs to be 756 updated. 758 4.5 Support of Internet-wide geo-routing 760 By using Internet-wide geo-routing the data packets that are generated 761 by source nodes placed anywhere in the Internet are able to be 762 forwarded over multiple hops by using the position of the destination 763 node(s) and the positions of intermediate nodes for the routing 764 decisions. 766 Several geo-routing protocols have been defined by other 767 standardization bodies, e.g., ETSI ITS, however, these geo-routing 768 protocols are not designed for Internet-wide geo-networking. 770 5. Possible solutions 772 This section presents two possible ways of how the Intern-wide geo- 773 networking solution can be designed. These solutions are the extended 774 DNS and GeoServer. The extended DNS solution uses GPS coordinates to 775 address geo-location. However, also other types of coordinates, such 776 as the Galileo coordinates could be used for this purpose. 778 5.1 Extended DNS 780 One of the ingredients for Internet-wide geo-networking is a 781 (distributed) database, able to resolve a geographical area to 782 relevant IP addresses. Source nodes wishing to send geo-networking 783 packets can then resolve the destination area of (a flow of) packets 784 to a number of IP addresses, and send the packets to these 785 destination addresses. 787 One direction for solutions is to extend the DNS system for this 788 purpose, see [FiHe11]. Rather than modifying the DNS protocol, 789 requiring new top level domains or requiring changes in the routing 790 behavior of today's Internet, this proposal is relying on the use DNS 791 LOC (location) resource records defined in the [RFC1876]. Through the 792 use of LOC records, geographical information about hosts, networks, 793 and subnets can be stored in the DNS files. By performing then 794 forward DNS lookups, geographical information about hosts or domains 795 can be obtained. Current implementation of DNS, such as NSD, support 796 LOC records to be inserted in the master file. This LOC record can 797 then be used to specify the location of an end-host, the coverage 798 area of an access router or access point, or the area in which the 799 members of a multicast group are spread. 800 The key point in this proposal is the use of LOC records as primary 801 key in the forward DNS lookup in order to return IP addresses 802 associated with geographical locations. In other words, we introduce 803 a new primary key into DNS besides the already existing ones 804 (hostnames and IP addresses). The extended version of DNS extends the 805 DNS server with capabilities to handle queries for an area within a 806 domain. Upon receiving a query with such a specified area, the 807 extended DNS server should return resource records for all names for 808 which the area specified in a LOC record overlaps with the area 809 specified in the query, and are also sub-domains of the domain 810 specified in the query. 811 These addresses can then be used by the source as destination address 812 for its geocast packets. 813 A possible format for a query is to replace the lowest-level 814 subdomain by a location description: 816 "("dlat [mlat [slat [mslat]]] "N"|"S" dlon [mlon [ slon [ mslon]]] 817 "E"|"W" alt["m"] size["m"]")".domain 818 Internet 819 /--------------------^--------------------\ 820 / +--------+ 821 | +------+ 'Geo' |Extended| 822 | | Back | ---------------------------> | DNS | 823 | |Office| <--------------------------- | (eDNS) | 824 | +------+ 'IP' +--------+ 825 | | 826 | | 827 < | " "802.11p 828 | | ` ` 829 | + ` _ RSU ` 830 | \ IP ` =|o|= ` 831 | \ ' =|o|= ' 832 | +--------->' =|@|= ' 833 | ' | ' 834 \ ` " " | ` 835 Infrastructure-based ` ` ` ` 836 Comm _____________________`______`____`_ `__________________________ 837 Infrastructure-less ` " " ` 838 Communications ' __ '802.11p 839 / ' _/ L\__ ' 840 | ' (_,.__,._) ' 841 | ` " " `' `' ` " " 802.11p 842 | ` ` ` ` ` ` 843 < - - - - - - - - ` - - - ` -`- -`- - - - - - - ` - - - - - ` - 844 | ` " "` ` ` 845 | ' ___ ' ' ___ ' 846 | ' _/ L\__ ' ' _/ L\__ ' 847 \ ' (_,.__,._) ' ' (_,.__,._) ' 848 ` `' `' ` ` `' `' ` 849 ________________`__________ `__________________`___________`___ 850 ` ` ` ` 851 " " 802.11p " " 853 Figure 2: The extended DNS scenario 855 Here, dlat, mlat, slat and mslat specify the latitude of the center 856 of the destination area in degree, minute, second, and millisecond, 857 North ("N") or South ("S") respectively. Similarly, dlon, mlon, slon 858 and mslon specify the longitude of the center of the destination area 859 in degree, minute, second, and millisecond East ("E") or West ("W") 860 respectively. Further, alt is the altitude in meters; size the 861 (radius) size of the destination area in meters and domain specifies 862 the domain to search in. Such an approach scopes geographical queries 863 to a certain domain. In order to allow for name servers to delegate 864 location queries to servers responsible for subdomains, for each 865 delegated subdomain the latter servers must maintain a bounding box 866 of their subdomains and make sure that also their parent server has 867 its up-to-date bounding box. To this end, a new record type (Bounding 868 Box) BND is used in this proposal. 869 Dynamic DNS update, as specified in [RFC2136] can be used to update 870 BND and LOC records. Different levels of granularity are possible 871 w.r.t. location representation in DNS. 873 If LOC records are stored for individual end- 874 hosts, a significant load for dynamic updates of LOC records may be 875 caused by mobile nodes. Alternatively, (stationary) access routers or 876 access points may store a LOC record specifying their coverage area, 877 and forward geocast packets to their coverage area. As a third 878 alternative, multicast addresses may be used to represent areas, 879 allowing host to subscribe to an area-specific multicast address 880 ([GEONET]). 881 Note: if the destination location is somehow specified in the packet, 882 additional packet filtering can be done by destination hosts, using 883 their exact, current location. 885 5.1.1 Dynamic IP address-to-geographical Address Resolution 887 A method similar to the name resolution (DNS) method can be provided. 888 The user of this method may query a server in this way: 889 it provides an IP address and it obtains in return the geographical 890 coordinates of where the interface assigned that IP address is 891 situated, or vice-versa. The method should also work for groups of IP 892 addresses (prefixes) and three-dimensional regions. 894 5.2 GeoServer 896 A design approach for Internet-wide geo-networking is to introduce a 897 new network element that serves as a message reflector to facilitate 898 the communication among vehicles. This network element functions as a 899 server. It processes incoming messages from each vehicle, aggregates 900 these messages when appropriate, and redistributes the messages to 901 other vehicles. Since this server is typically responsible for a 902 geographical area, it is termed GeoServer. The main functionality of 903 a GeoServer is to provide vehicles with geographical-related services 904 such as for traffic safety and traffic efficiency & management and 905 infotainment-type of applications. The GeoServer is linked to an 906 application server; both might be co-located. The application 907 scenario is illustrated in Figure 3. 908 Applications may work vehicle or AppServer-triggered. In a typical 909 vehicle-triggered scenario, the vehicle may detect road works or 910 an obstacle by any means (local sensors, communication over other 911 media or user input), triggers a message and sends it to the 912 GeoServer. 913 The GeoServer can either forwards the messages directly to the 914 destination area or involve the AppServer for information aggregation 915 before forwarding the data. In the GeoServer-triggered scenario, the 916 application server acts as originator of a message, based on data 917 aggregation or information from a traffic management center or static 918 configuration. 920 The scenario requires three main communication tasks [ITSWC2012], 921 [WANG2013]: location updates, event reporting and geographical 922 messaging (GeoMessaging). Location updates are periodically sent from 923 the vehicle to the GeoServer. Their transmission can be triggered 924 query-based, time-based, distance-based, grid-based (or a 925 combination) (see [ITSWC2011]). If the driver or the vehicle detects 926 an event, then the event will be reported to the GeoServer. 928 The GeoServer enables the distribution of messages to vehicles in 929 a geographical area. The GeoServer also takes care of periodic re- 930 transmission of the warning during the lifetime of the event, i.e. 931 the repetition of the messages in order to keep the information alive 932 in the destination area when vehicles start their journey or enter 933 the area. 935 Coverage 936 Area 937 - ~ - 938 ` ` 939 +-------+ ' ' 940 | App | +------+ ` ` 941 | Server| ___|Access|____` ` 942 +-------+ +----------+ / |Router| +`-----------------`+ 943 | / \ / +------+ | ` O ` | 944 +-------+ / \/ | ' - ~ - ' | 945 | Geo |___/ Internet \ | ` O ` | 946 | Server| \ / | ' - ~ - ' | 947 +-------+ \ /\ +------+ | ` ` | 948 \ / \____|Access|____, O `| 949 +----------+ |Router| |` `| 950 +------+ | ` ` | 951 | ' ' | 952 | ` - ~ - ` | 953 | Destination Area | 954 +-------------------+ 956 O Destination Nodes 958 Figure 3: GeoServer scenario 960 6. Security Considerations 962 According to requirement 3.8.1, the Internet-wide geo-networking 963 solution MUST support security objectives for all supported 964 communication modes. Security objectives particularly include 965 integrity, privacy and non-repudiation and SHOULD protect the network 966 and transport layer protocol headers. In addition the Internet-wide 967 geo-networking solution MUST also protect privacy, i.e. provide 968 confidentiality to personal data such as node identifier and 969 location. 971 7. IANA Considerations 972 No IANA considerations are considered in this document. 974 8. Acknowledgments 976 We would like to thank the members of the IETF ITS community for 977 their comments and discussions. Furthermore, we would like to thank 978 the authors of the Internet draft [draft-karagiannis-traffic-safety- 979 requirements], G. Karagiannis, R. Wakikawa, J. Kenney, C. J. 980 Bernardos and F. Kargl, since some parts of the traffic safety 981 application descriptions are taken from the mentioned draft. 983 9. Normative References 985 10. Informative References 987 [C2C-CC] C2C-CC official website, http://www.car-2-car.org/, 988 (visited in October 2009). 990 [C2C-CC_MANIFESTO] Car to Car Communication Consortium, "Car to Car 991 Communication Consortium Manifesto: Overview of the C2C-CC System", 992 C2C-CC, version 1.1, 2007. 994 [CVIS] CVIS EU FP6 project website, http://www.cvisproject.org, 995 (visited in October 2009). 997 [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, 998 Festag, A., Lenardi, M., "Automotive industry requirements for NEMO 999 Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, 1000 (Work in progress), 2009. 1002 [draft-karagiannis-traffic-safety-requirements] Karagiannis, G., 1003 Wakikawa, R., Kenney, J., Bernardos, C.J., Kargl, F.,"Traffic 1004 safety applications requirements, IETF Internet draft (work in 1005 progress), draft-karagiannis- 1006 traffic-safety-requirements-02.txt, February 2010; 1008 [ETSI TC ITS] ETSI official website, http://www.etsi.org/, (visited 1009 in October 2009). 1011 [ETSI-TR-102-638] ETSI TR 102 638, "Intelligent Transport System 1012 (ITS); Vehicular Communications; Basic Set of Applications; 1013 Definition", ETSI specification TR 102 638, v.1.1.1, June 2009. 1015 [ETSI-EN-302-636-1] ETSI TS 102 636-1 V1.1.1, "Intelligent Transport 1016 Systems (ITS); Vehicular Communications; GeoNetworking; Part 1: 1017 Requirements", ETSI Specification ETSI TS 102 636-1 V1.1.1, March 1018 2010 1020 [ETSI-EN-302-636-4-1] ETSI TS 102 636-4-1, "Intelligent Transport 1021 Systems (ITS); Vehicular communications; GeoNetworking; Part 4: 1022 Geographical addressing and forwarding for point-to-point and point- 1023 to-multipoint communications; Sub-part 1: Media-Independent 1024 Functionality", ETSI specification ETSI TS 102 636-4-1 V1.1.1, June 1025 2011 1027 [ETSI-EN-302-636-6-1] ETSI TS 102 636-6-1 V1.1.1, "Intelligent 1028 Transport Systems (ITS); Vehicular Communications; GeoNetworking; 1029 Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 1030 Packets over GeoNetworking Protocols", ETSI specification ETSI TS 102 1031 636-6-1 V1.1.1, March 2011 1033 [FiHe11] Fioreze, T. and Heijenk, G.J. (2011) Extending the Domain 1034 Name System (DNS) to Provide Geographical Addressing Towards 1035 Vehicular Ad-Hoc Networks (VANETs). In: 2011 IEEE Vehicular 1036 Networking Conference (VNC), 14 - 16 Nov 2011, Amsterdam, The 1037 Netherlands. pp. 70-77. IEEE. ISBN 978-1-4673-0047-6 1039 [GEONET] GeoNet EU FP7 project website, http://www.geonet-project.eu, 1040 (visited in October 2009). 1042 [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless 1043 Access in Vehicular Environments (WAVE)-Networking Services", 2007. 1045 [KaAl11] Karagiannis, G. Altintas, O., Ekici,E., Heijenk, G.J., 1046 Jarupan, B., Lin, K., Weil, T., "Vehicular networking: A survey and 1047 tutorial on requirements, architectures, challenges, standards and 1048 solutions", IEEE Communications Surveys & Tutorials, 13 (4). pp. 584- 1049 616. ISSN 1553-877X, 2011. 1051 [ITSWC2012] A. Festag, M. Wiecker, N. Zahariev: "Safety and 1052 Traffic Efficiency Appllications for GeoMessaging over Cellular 1053 Networks", 19th ITS World Congress and Exhibition, Vienna, Austria, 1054 October 2012 1056 [ITSWC2011] G. Jodlauk, R. Rembarz, Z. Xu: "An Optimized 1057 Grid-Based Geocasting Method for Cellular Mobile Networks", in 1058 Proc. 18th ITS World Congress, Orlando, USA, Oct. 2011 1060 [WANG2013] S. Wang, L. Le, N. Zahariev, and K. K. Leung: 1061 "Centralized Rate Control Mechanism for Cellular-Based Vehicular 1062 Networks", accepted for IEEE Global Communications Conference 1063 GLOBECOM) 2013, Dec. 2013. 1065 [PREDRIVE-C2x] Pre-Drive C2X EU FP7 project website, 1066 http://www.pre-drive-c2x.eu, (visited in October 2009). 1068 [RFC2009] T. Imielinski and J. Navas, "GPS-Based Addressing and 1069 Routing", RFC 2009, November 1996. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC1876] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for 1075 Expressing Location Information in the Domain Name System", RFC 1876, 1076 January 1996. 1078 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 1079 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1080 1997. 1082 [SAFESPOT] SAFESPOT EU FP6 project website, 1083 http://www.safespot-eu.org, (visited in October 2009). 1085 [SEVECOM] SEVECOM EU FP6 project website, http://www.sevecom.org, 1086 (visited in October 2009). 1088 [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 1089 591, April 2006. 1091 [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, 1092 Final Annual Report, DOT HS 811 073, January 2009. 1094 [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides 1095 presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found 1096 via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ 1097 VSCA-1609_080827.pdf 1099 11. Authors' Address 1101 Georgios Karagiannis 1102 University of Twente 1103 P.O. Box 217 1104 7500 AE Enschede, 1105 The Netherlands 1106 EMail: g.karagiannis@utwente.nl 1108 Geert Heijenk 1109 University of Twente 1110 P.O. Box 217 1111 7500 AE Enschede, 1112 The Netherlands 1113 EMail: geert.heijenkg@utwente.nl 1115 Andreas Festag 1116 Technical University Dresden & NEC Laboratories Europe 1117 Germany 1118 Email: andreas.festag@ifn.et.tu-dresden.de?; 1120 Alexandru Petrescu 1121 CEA 1122 Communicating Systems Laboratory, Point Courrier 173 1123 Palaiseau, F-91120 1124 France 1125 Phone: +33(0)169089223 1126 Email: alexandru.petrescu@cea.fr 1128 Alison Chaiken 1129 Mentor Embedded Software Division 1130 46871 Bayside Parkway 1131 Fremont, CA 94538 1132 USA Email: alison@she-devel.com