Internet Engineering Task Force Georgios Karagiannis Internet-Draft Geert Heijenk Intended status: Informational University of Twente Expires: March 23, 2014 Andreas Festag Technical University Dresden & NEC Laboratories Europe Alexandru Petrescu CEA Alison Chaiken Mentor Embedded Software Division September 23, 2013 Internet-wide Geo-networking Problem Statement draft-karagiannis-problem-statement-geonetworking-00 Abstract This document describes the need of specifying Internet-wide location-aware forwarding protocol solutions that provide packet routing using geographical positions for packet transport. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Karagiannis, et al. Expires March 23, 2014 [Page 1] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use cases and scenarios . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Open Design Issues . . . . . . . . . . . . . . . . . . . . . . 14 5. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . . 19 11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . 22 Karagiannis, et al. Expires March 23, 2014 [Page 2] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 1. Introduction 1.1 Motivation Internet-based applications use IP addresses to address a node that can be a host, a server or a router. Scenarios and use cases exist where nodes are being addressed using their geographical location instead of their IP address. The most obvious use cases are related to Intelligent Transportation Systems (ITS) and vehicular networking, environmental monitoring, consumer electronic devices (e.g. cameras) and scientific instruments. In this document we will mainly focus on ITS and vehicular networking. An ITS use case is, for example, a traffic jam or a chain collision, where all vehicles heading towards the potential hazard should be warned. In particular, for vehicles ahead that are moving away from the hazardous location, the information is not relevant anymore. In such dangerous situation geo-networking can offer great support to applications that require geographical addressing. Internet-wide Geo-Networking is a location-aware forwarding protocol that provides packet routing using geographical positions for packet transport over the Internet. Vehicular networking can be considered as one of the most important enabling technologies required to implement a myriad of applications related to vehicles, vehicle traffic, drivers, passengers and pedestrians. Two main types of vehicle communication networks can be distinguished. In the Vehicle- to-Infrastructure (V2I) communication network packets are exchanged among vehicles using an infrastructure that can be Internet-wide. The second type is Vehicle-to-Vehicle (V2V) communication, where packets are exchanged among vehicles without the need for a communication infrastructure. Hybrid scenarios that combine V2V and V2I communication appear reasonable. Intelligent Transportation Systems aim to improve the operation of vehicles, manage vehicle traffic, assist drivers with safety and other information, along with provisioning of convenience applications. Prime examples of ITS services include automated toll collection systems, driver assist systems and other information provisioning systems. Over the last decade, the development of ITS services has been backed up by coordinated efforts for standardization and formation of consortia and other governmental and industrial bodies that aim to set the guiding principles, requirements, and first takes on solutions for ITS-related communication systems that primarily involve vehicles and users within vehicles. The main challenges that are associated with Internet-wide geo- networking are: o) support of geo-addressing, where geographical information should be available in the addressing mechanism, such that packets can be forwarded to a target geographical area. The geographical area may either be specified by the source (application) or might not be specified at all. Karagiannis, et al. Expires March 23, 2014 [Page 3] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 o) support of Internet-wide geo-routing, where data packets that are generated by source nodes placed anywhere in the Internet are forwarded over multiple hops by using the position of the destination node(s) and the positions of intermediate nodes for the routing decisions. o) creation of a forwarding method that comprises a local-computer decision algorithm which can deterministically compare IP/geographical addresses present in a packet to IP/geographical addresses present in a local database, a database mixed (IP and geographical) topology distribution algorithm among several computers, and a IP/geographical path construction algorithm which acts on the IP/geographical database. o) the use of a single consensual geodesic datum which may be used by present and future GNSSs by as many as possible network operators, and agreed datum conversion methods. o) representation of precision in IP addressing. IP addresses are precise and unique, whereas geographical coordinates involve notions of precision and accuracy. Geo-addressing: In [RFC2009], three families of solutions are described to integrate the concept of physical location into the current design of Internet that relies on logical addressing. These families of solutions are: (1) Application layer solutions, (2) GPS-Multicast solution. (3) Unicast IP routing extended to deal with GPS addresses. In particular, [RFC2009] specifies how GPS positioning is used for destination addresses. A GPS address could be represented by using: (1) closed polygons, such as circle (center point, radius), where, any node that lies within the defined geographic area could receive a message, (2) site-name as a geographic access path, where a message can be sent to a specific site by specifying its location in terms of real-word names such as names of site, city, township, county, state, etc. [ETSI-EN-302-636-4-1] specifies geographical addressing for point-to- point and point-to-multipoint communications over short range wireless communication technologies, such as ITS-G5, for vehicle-to- vehicle communication. Also other solutions for geo-addressing have been specified, but none of them have been applied for Internet-wide geo-networking. Geo-routing: A significant number of geo-routing protocols are available, see e.g., [KaAl11] for a survey. These protocols can mainly be divided in two categories. The first category focuses on unicast routing, and the second covers broadcast routing. [ETSI-EN-302-636-4-1] an sub-IP- routing protocol with unicast and broadcast forwarding schemes for multi-hop and ad hoc communication among vehicles and between vehicles and roadside station utilizing geographical positions. [ETSI-EN-302-636-6-1] has standardized the transmission of IPv6 packets over ETSI GeoNetworking that can be used for the forwarding of IPv6 packets using the position of the destination node(s) and the positions of intermediate nodes for the routing decisions. However, these geo-routing protocols are not designed for Internet-wide geo- networking. Karagiannis, et al. Expires March 23, 2014 [Page 4] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 1.2 Goal Internet-wide geo-networking targets at IP-layer extensions that allow source nodes anywhere in the Internet to geo(broad/any)cast packets to all/any node(s) with geo-location awareness within an arbitrary, source-specified destination area. 1.3. Terminology On Board Unit (OBU) a processing and communication feature that is located in a vehicle, which provides an application runtime environment, positioning, security and communications functions and interfaces to other vehicles including human machine interfaces. OBU is also known as OBE (On-Board Equipment). Road Side Unit (RSU) equipment located along highways, at traffic intersections and other type of locations where timely communications with vehicles are needed. Each RSU includes DSRC radio, a positioning system and a router to route packets back through the infrastructure network. RSU is also known as RSE (Road Side Equipment) Vehicle-to-Vehicle (V2V) (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic communication mode in which data packets are exchanged between two vehicles, either directly or traversing multiple vehicles, without involving any node in the infrastructure. Vehicle-to-Infrastructure (V2I) generic communication mode in which data packets sent by a vehicle traverse a communication infrastructure. Infrastructure-to-Vehicle (I2V) generic communication mode in which data packets received by a vehicle traverse a communication infrastructure. Host vehicle a vehicle that uses the ITS application. Traffic safety application application that is primarily applied to decrease the probability of traffic accidents and the loss of life of the occupants of vehicles. Karagiannis, et al. Expires March 23, 2014 [Page 5] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 Geographically-scoped broadcast (or geocast), see [C2C-CC_Manifesto] forwarding mechanism that is used to transport data from a single node to all nodes within a target area that is specified geographical positions, e.g. defined by a geographic region. The geographic region is determined by a geometric shape, such as circle and rectangle. Geographical Unicast (or geounicast) see [C2C-CC_Manifesto] Forwarding mechanism that is used for unidirectional data transport from a single node (source) to a single node (destination) by means of direct communication or by multiple hops based on C2C Communication specific addresses that include node identifier, geographical position, and time information. Geographically-scoped anycast (or geoanycast), see [C2C-CC_Manifesto] forwarding mechanism that transports data from a single node to any of the nodes within a geographically area. Compared to geographically-scoped broadcast, with geographically-scoped anycast a packet is not forwarded inside of the geographic area when the packet has reached the area. 1.4. Organization of This Document This document is organized as follows. Section 2 describes several Geo-networking use cases an scenarios. Section 3 describes the requirements that need to be fulfilled by the Internet-wide Geo-networking solution. The open design issues are discussed in Section 4. Section 5 describes possible solutions of realizing the Internet-wide Geo-networking solution. Section 6 describes the security considerations. The acknowledgement section is provided in Section 8. 2. Use cases and scenarios 2.1 Scenario The scenario that is considered in this document for the support of Internet-wide geo-networking is shown in Figure 1. This scenario shows a source node, which can be located anywhere, and is interconnected with access routers via the Internet. The packets generated by the source are routed through the Internet using the typical destination address based routing up to the access routers. Geo-routing is then used to forward the packets towards the destination area where the recipients are located. In the destination area the packets are geo-broadcasted to all the recipients within the destination area. Karagiannis, et al. Expires March 23, 2014 [Page 6] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 Coverage Area - ~ - ` ` ' ' +------+ ` ` ___|Access|____` ` +----------+ / |Router| +`-----------------`+ / \ / +------+ | ` O ` | +------+ / \/ | ' - ~ - ' | |Source|___/ Internet \ | ` O ` | | Node | \ / | ' - ~ - ' | +------+ \ /\ +------+ | ` ` | \ / \____|Access|____, O `| +----------+ |Router| |` `| +------+ | ` ` | | ' ' | | ` - ~ - ` | | Destination Area | +-------------------+ O Destination Nodes Figure 1: Internet-wide geo-networking scenario 2.2 Use cases The use cases considered in this section are vehicular networking use cases. However, Internet-wide geo-networking can be applied to any use case that is similar to these vehicular use cases where source nodes anywhere in the Internet are able to geo(broad/any)cast packets to all/any node(s) with geo-location awareness within an arbitrary, source-specified destination area. Vehicular networking can be considered as one of the most important enabling technologies needed to support various types of traffic applications, such as infotainment type of applications, traffic efficiency & management and traffic safety applications. Traffic safety applications are those that are primarily applied to decrease the probability of traffic accidents and the loss of life of the occupants of vehicles. Note that VSC and VSC-A projects focus on vehicle-to-vehicle safety. Another project called CICAS-V (Cooperative Intersection Collision Avoidance Systems - Violation) discuss the traffic safety application over vehicle-to-infrastructure communication. Traffic efficiency & management applications are focusing on improving the vehicle traffic flow, traffic coordination and traffic assistance. Moreover, traffic efficiency & management applications are focusing on providing updated local information, maps and in general messages of relevance limited in space and/or time. Karagiannis, et al. Expires March 23, 2014 [Page 7] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 Infotainment types of applications are the applications that are neither traffic safety applications nor traffic efficiency & management applications. Such applications are supported by e.g., media downloading use cases. Such vehicular applications are defined by several initiatives: o the USA VSC (Vehicular Safety Communications) and VSC-A (VSC- Applications) projects. O the European Car-to-Car Communication Consortium (C2C-CC) [C2C-CC] and the ETSI TC ITS [ETSI TC ITS], [ETSI-TR-102-638] with the additional support of some EU funded research projects, such as SEVECOM [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS]. PREDRIVE-C2x [PREDRIVE-C2x], GEONET [GEONET]. The USA Vehicle Safety Communications (VSC) consortium, see [VSC], is supported among others by CAMP (Crash Avoidance Metrics Partnership). CAMP is a partnership that has been formed in 1995 by Ford Motor Company and General Motors Corporation. The objective of CAMP is to accelerate the implementation of crash avoidance countermeasures to improve traffic safety by investigating and developing new technologies. VSC has been realized in two phases. The descriptions of the relevant traffic safety applications are taken from [draft-karagiannis-traffic-safety-requirements]. The first phase, denoted as VSC started in 2002 and ended in 2004. The second phase started in 2006 and ends in 2009. VSC focused and is focusing on traffic safety related applications. In 2006, The VSC 2 consortium in cooperation with USDOT initiated a three-year collaborative effort in the area of wireless-based safety applications under the Vehicle Safety Communications - Applications (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the following members; Mercedes-Benz, Ford, General Motors, Honda & Toyota. The main goal of this project is to develop and test communications-based vehicle safety systems to determine whether vehicle positioning in combination with the DSRC at 5.9 GHz can improve the autonomous vehicle-based safety systems and/or enable new communication-based safety applications. The WAVE Short Message Protocol [IEEE 1609.3] was designed specifically to offer a more efficient (smaller size) alternative to TCP or UDP over IP, for 1-hop messages that require no routing. The European Car-to-Car Communication Consortium (C2C-CC) is an industry consortium of car manufacturers and electronics suppliers that focuses on the definition of an European standard for vehicular communication protocols. The European Telecommunications Standards Institute (ETSI) Technical Committee (TC) Intelligent Transport Systems (ITS) was established in October 2007 with the goal of developing and maintaining standards, specifications and other deliverables to support the development and the implementation of ITS service provision. Karagiannis, et al. Expires March 23, 2014 [Page 8] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 It is foreseen that ETSI ITS will be the reference standardization body of the future European ITS standards, and actually the C2C-CC provides recommendations to the ETSI TC ITS. The following subsections describe use cases that can be implemented using either V2I or V2V. When V2V is applied, the use of Internet- wide Geo-networking solution is not required. 2.2.1 Traffic safety use cases In VSC, see [VSC] 34 vehicle application scenarios have been identified, evaluated and ranked. From this evaluation, a subset of eight significant near- and mid-term traffic safety applications have been selected: (1) cooperative forward collision warning, (2) curve speed warning, (3) pre-crash sensing, (4) traffic signal violation warning, (5) lane-change warning, (6) emergency electronic brake light, (7) left turn assistant, (8) stop sign movement assistant. A brief description of these applications is given below (for more details, see [VSC]): o Traffic signal violation warning: it informs and warns the driver to stop at a legally prescribed location in the situation that the traffic signal indicates a stop and it is estimated that the driver will be in violation. o Curve speed warning - Rollover Warning: aids the driver in negotiating speeds at appropriate speeds. o Emergency Electronic Brake Lights: it is used to inform vehicles that a vehicle brakes hard. In particular in this situation a warning message is sent to the vehicles moving behind the vehicle that brakes hard. o Pre-crash sensing: it prepares the driver for an unavoidable and imminent collision. o Cooperative Forward Collision Warning: aids the driver in mitigating or avoiding collisions with the rear-end vehicles in the forward path of travel through driver notification or warnings of an unavoidable collision. This application does not attempt to control the vehicle to avoid an unavoidable collision. o Left Turn Assistant: it informs the driver about oncoming traffic in order to assist him in making a left turn at a signalized intersection without a phasing left turn arrow. o Lane Change Warning: it warns the driver if an intended lane change may cause a crash with a nearby moving vehicle. o Stop Sign Movement Assistance: it warns the driver that the vehicle is nearby an intersection, which will be passed after having stopped at a stop sign. Karagiannis, et al. Expires March 23, 2014 [Page 9] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 In the VSC-A project an additional investigation has been performed, on traffic safety applications that can be used in crash immitment scenarios, see [VSC-A]. The following 7 traffic safety applications have been selected for implementation in the VSC-A test bed. o Emergency Electronic Brake Light: is a traffic safety application that is the same as the Emergency Electronic Brake Light application defined in the VSC project, see above. o Forward Collision warning: is a traffic safety application that is the same as the Cooperative Forward Collision Warning application defined in the VSC project, see above. o Intersection Movement Assist: is a traffic is intended to warn the driver of a vehicle when it is not safe to enter an intersection due to high collision probability with other vehicles. It is similar to the Stop Sign Movement Assistance application defined in the VSC project, see above. o Blind Spot Warning & Lane Change Warning: it is similar to the Lane Change Warning application defined in the VSC project, see above. In the Blind Spot Warning application the driver of a host vehicle is informed that another vehicle is moving in an adjacent lane and that this vehicle is positioned in a blind spot zone of the host vehicle. o Do Not Pass Warning: this is an application that was not investigated in the VSC project. It is intended to warn the driver of a host vehicle during a passing maneuver attempt when a slower vehicle, ahead and in the same lane, cannot be safely passed using a passing zone which is occupied by vehicles with the opposite direction of travel. In addition, the application provides advisory information that is intended to inform the driver of the host vehicle that the passing zone is occupied when a passing maneuver is not being attempted. o Control Loss Warning: this is an application that was not investigated in the VSC project. It is intended to enable the driver of a host vehicle to generate and broadcast a control- loss event to surrounding vehicles. Upon receiving this information the surrounding vehicle determines the relevance of the event and provides a warning to the driver, if appropriate. The Car to Car Communication Consortium specified a number of traffic safety use cases. The following three are considered as being the main traffic safety use cases, see [C2C-CC_Manifesto]: o Cooperative Forward Collision Warning: this use case tries to provide assistance to the driver. Vehicles share (anonymously) information such as position, speed and direction. This enables the prediction of an imminent rear-end collision, by each vehicle monitoring the behavior of its own driver and the information of neighboring vehicles. If a potential risk is detected, the vehicle warns the driver. Karagiannis, et al. Expires March 23, 2014 [Page 10] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 This use case requires: the ability for all vehicles to share Information with each other over a distance of about 20 to 200 meters, accurate relative positioning of the vehicles, trust relationships among the vehicles and a reasonable market penetration (at least 10%). o Pre-Crash Sensing/Warning: this use case is similar to the previous one, but in this case the collision is identified as unavoidable, and then the involved vehicles exchange more precise information to optimize the usage of actuators such as airbags, seat belt pre-tensors, etc... This use case requires basically the same abilities that the previous one, restricting the needed communication range to 20 to 100 meters, and adding the requirement of a fast and reliable connection between the involved cars. o Hazardous Location V2V Notification: this use case is based on the share of information that relates to dangerous locations on the road, among vehicles, and also among vehicles and the road infrastructure. On one hand, vehicles may detect the dangerous locations from sensors in the vehicle or from events such as the actuation of the ESP (Electronic Stability Program). On the other hand, recipients of this information may use it to properly configure active safety systems and/or warn the driver. This use case requires: vehicles to trust other vehicles and roadside units, reasonable market penetration, the ability of vehicles to share information about a specific geographic location over multiple-hops and the ability to validate information propagated through multiple hops. 2.2.2 Traffic efficiency and management use cases Such applications are focusing on improving the vehicle traffic flow, traffic coordination and traffic assistance and provide updated local information, maps and in general, messages of relevance bounded in space and/or time. Two typical groups of this type of applications are speed management and co-operative navigation are two typical groups of this type of applications [ETSI-TR-102-638], [KaAl11]. o) Speed management: Speed management applications aim to assist the driver to manage the speed of his/her vehicle for smooth driving and to avoid unnecessary stopping. Regulatory/contextual speed limit notification and green light optimal speed advisory are two examples of this type. o) Co-operative navigation This type of applications is used to increase the traffic efficiency by managing the navigation of vehicles through cooperation among vehicles and through cooperation between vehicles and road side units. Some examples of this type are traffic information and recommended itinerary provisioning, co-operative adaptive cruise control and platooning. Karagiannis, et al. Expires March 23, 2014 [Page 11] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 2.2.3 Infotainment Applications Such applications are neither traffic safety applications nor traffic efficiency & management applications and are mainly supported by e.g., media downloading use cases, see [CVIS], [C2C-CC_Manifesto], [ETSI-TR-102-638], [PREDRIVE-C2x], [KaAl11]: o) Co-operative local services This type of applications focus on infotainment that can be obtained from locally based services such as point of interest notification, local electronic commerce and media downloading. b) Global Internet services In this type of applications the focus is on data that can be obtained from global Internet services. Typical examples are Communities services, which include insurance and financial services, fleet management and parking zone management, and ITS station life cycle, which focus on software and data updates. 3. Requirements This section includes the requirements that need to be fulfilled by Internet geo-networking solutions and are based on [ETSI-EN-302-636-1]. 3.1 Functionality requirements This section describes the functionality requirements that need to be supported by the Internet-wide geo-networking solution. 3.1.1 No changes to existing routing infrastructure The Internet geo-networking solution MUST NOT impose any changes on the existing Internet-wide routing infrastructure. 3.1.2 Minimal changes to the IP layer in source nodes The changes on the IP layer used by the source nodes, i.e., the nodes that are making use of Internet-wide geo-networking SHOULD be minimized. 3.1.3 Communication mode The geoanycast, geounicast and geobroadcast communication modes MUST be supported by the Internet-wide geo-networking solution. 3.1.4 Geo-addressing Geographical information MUST be available in the addressing mechanism, such that packets can be forwarded to a target geographical area. Karagiannis, et al. Expires March 23, 2014 [Page 12] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 3.1.5 Internet-wide geo-routing The Internet geo-networking solution MUST enable the forwarding of packets over multiple hops by using the position of the destination node(s) and the positions of intermediate nodes for the routing decisions. The Internet geo-routing solution SHOULD be able to operate without predefining the set of possible destination areas. 3.1.6 Internet-wide geo-networking and IPv6 The Internet geo-networking solution MUST support transparently the routing of IPv6 packets. 3.1.7 Data congestion control Data congestion control functions SHOULD be supported in order to in order to keep network load at an acceptable level and eliminate unnecessary duplicates of packets with limited control overhead. 3.1.8 Security and privacy The Internet-wide geo-networking solution MUST support security objectives for all supported communication modes. Security objectives particularly include integrity, privacy and non-repudiation and SHOULD protect the network and transport layer protocol headers. In addition the Internet-wide geo-networking solution MUST also protect privacy, i.e. provide confidentiality to personal data such as node identifier and location. 3.2 Performance requirements This section describes the performance requirements that need to be supported by the Internet-wide geo-networking solution. 3.2.1 Low-latency communications The Internet geo-networking solution SHOULD support low latency communications. This requirement mainly applies to traffic safety and traffic efficiency applications. 3.2.2 Reliable communications The Internet geo-networking solution SHOULD support reliable communications with the highest reliability for traffic safety messages. 3.2.3 Low signaling, routing and packet forwarding overhead The signaling, routing and packet forwarding overhead SHOULD be minimized. Karagiannis, et al. Expires March 23, 2014 [Page 13] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 3.2.4 Priority support The Internet geo-networking solution SHOULD support packets with different priorities with the highest priority for critical traffic safety packets. 3.2.5 Scalability The Internet geo-networking solution SHOULD be able to maintain its performance to acceptable levels even when it is applied to: o) global coverage with small geocast areas o) large traffic volumes (large flows) o) large number of active sources 4. Open Design Issues This section describes the Internet wide geo-networking open design issues that can be addressed by the IETF. 4.1 Geo-addressing in the wired Internet: The Standard Internet routers are not aware of geo-networking functionality. Therefore, the used addresses used must be regular addresses that route to / via the Access Router. In particular, regarding unicast and multicast addresses the following issues can be identified. o) Using unicast addresses for all destination areas: does not scale well and packets are sent multiple times on the wireless interface o) Unicast addresses of relevant access routers: can be realized by using e.g., tunneling. o) Using multicast addresses to specify destination areas: A standard router should know how to route that means that it should use a predefined multicast address. This implies that an arbitrary, source-specified destination area cannot be coded this way. Alternatively, packet could be sent to set of predefined areas which together include the source-specified destination area (further filtering at destination). However, suppose one multicast address per access point covering 300 x 300 ? 105 m^2. This would imply 5 * 1014 / 105 = 5 * 109 multicast addresses to cover the earth. This is far too many addresses that can be maintained by nowadays routers in their routing tables. A solution could be to define larger predefined areas. In this case however, many useless packet transmissions will need to be supported. It can be, therefore, deduced that normal use of multicast addresses does not scale. Meaning that other solutions are needed, such (1) aggregation of multicast addresses into "larger" multicast addresses, (2) support of a routing hierarchy for geocasting. Karagiannis, et al. Expires March 23, 2014 [Page 14] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 4.2 Exchanging destination area information Until all routers in the Internet are geo-aware, or until a sufficient level of multicast address aggregation has been achieved to have a manageable total number of multicast addresses, we need a way for the source node to reach the (right) first geo-aware access router, e.g., RSU, (over the standard Internet). In addition to that the destination area specification needs to be exchanged at this first geo-aware access router. This can be achieved only if there is precise knowledge about the location of this destination node. The destination area specification has to be carried in the packet, using one of the following options: o) Specify this information in the IP destination address (tunneled in wired Internet) o) Use IP header extensions (not processed by standard Internet routers) o) Carry this information in the application layer header 4.3 Lookup and translation of destination area to IP address When a source that needs to disseminate information in a destination area it will need to lookup and translate the destination area into a standard IPv6 address of the first geo-aware access router, e.g., RSU, which is routable in the standard Internet. The destination area can be specified by an application at the source, and does not have to coincide with known (predefined) areas, e.g., corresponding with the coverage area of an AR (e.g., RSU), or with the area covered by a predefined multicast address. This can be realized using location databases that provide the mapping between the destination area and the IPv6 address of the first geo-aware access router, e.g., RSU. Examples of such location databases are: o) Application specific location database o) DNS extended with location records and queries o) Table of known multicast addresses 4.4 Updating the location database The location databases that stores the mapping between the destination areas and the IPv6 addresses of the first geo-aware access router, e.g., RSU, need to be dynamically maintained and be up to date. Meaning that whenever new destination areas are identified or when the mapping between the stored destination areas and the associated IPv6 addresses change the location database needs to be updated. 5. Possible solutions This section presents two possible ways of how the Intern-wide geo- networking solution can be designed. These solutions are the extended DNS and GeoServer. The extended DNS solution uses GPS coordinates to address geo-location. However, also other types of coordinates, such as the Galileo coordinates could be used for this purpose. Karagiannis, et al. Expires March 23, 2014 [Page 15] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 5.1 Extended DNS One of the ingredients for Internet-wide geo-networking is a (distributed) database, able to resolve a geographical area to relevant IP addresses. Source nodes wishing to send geo-networking packets can then resolve the destination area of (a flow of) packets to a number of IP addresses, and send the packets to these destination addresses. One direction for solutions is to extend the DNS system for this purpose, see [FiHe11]. Rather than modifying the DNS protocol, requiring new top level domains or requiring changes in the routing behavior of today's Internet, this proposal is relying on the use DNS LOC (location) resource records defined in the [RFC1876]. Through the use of LOC records, geographical information about hosts, networks, and subnets can be stored in the DNS files. By performing then forward DNS lookups, geographical information about hosts or domains can be obtained. Current implementation of DNS, such as NSD, support LOC records to be inserted in the master file. This LOC record can then be used to specify the location of an end-host, the coverage area of an access router or access point, or the area in which the members of a multicast group are spread. The key point in this proposal is the use of LOC records as primary key in the forward DNS lookup in order to return IP addresses associated with geographical locations. In other words, we introduce a new primary key into DNS besides the already existing ones (hostnames and IP addresses). The extended version of DNS extends the DNS server with capabilities to handle queries for an area within a domain. Upon receiving a query with such a specified area, the extended DNS server should return resource records for all names for which the area specified in a LOC record overlaps with the area specified in the query, and are also sub-domains of the domain specified in the query. These addresses can then be used by the source as destination address for its geocast packets. A possible format for a query is to replace the lowest-level subdomain by a location description: "("dlat [mlat [slat [mslat]]] "N"|"S" dlon [mlon [ slon [ mslon]]] "E"|"W" alt["m"] size["m"]")".domain Here, dlat, mlat, slat and mslat specify the latitude of the center of the destination area in degree, minute, second, and millisecond, North ("N") or South ("S") respectively. Similarly, dlon, mlon, slon and mslon specify the longitude of the center of the destination area in degree, minute, second, and millisecond East ("E") or West ("W") respectively. Further, alt is the altitude in meters; size the size of the destination area in meters and domain specifies the domain to search in. Such an approach scopes geographical queries to a certain domain. In order to allow for name servers to delegate location queries to servers responsible for subdomains, for each delegated subdomain the latter servers must maintain a bounding box of their subdomains and make sure that also their parent server has its up-to- date bounding box. Karagiannis, et al. Expires March 23, 2014 [Page 16] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 To this end, a new record type BND is used in this proposal. Dynamic DNS update, as specified in [RFC2136] can be used to update BND and LOC records. Different levels of granularity are possible w.r.t. location representation in DNS. If LOC records are stored for individual end- hosts, a significant load for dynamic updates of LOC records may be caused by mobile nodes. Alternatively, (stationary) access routers or access points may store a LOC record specifying their coverage area, and forward geocast packets to their coverage area. As a third alternative, multicast addresses may be used to represent areas, allowing host to subscribe to an area-specific multicast address ([GEONET]). Note: if the destination location is somehow specified in the packet, additional packet filtering can be done by destination hosts, using their exact, current location. Internet /--------------------^--------------------\ / +--------+ | +------+ 'Geo' |Extended| | | Back | ---------------------------> | DNS | | |Office| <--------------------------- | (eDNS) | | +------+ 'IP' +--------+ | | | | < | " "802.11p | | ` ` | + ` _ RSU ` | \ IP ` =|o|= ` | \ ' =|o|= ' | +--------->' =|@|= ' | ' | ' \ ` " " | ` Infrastructure-based ` ` ` ` Comm _____________________`______`____`_ `__________________________ Infrastructure-less ` " " ` Communications ' __ '802.11p / ' _/ L\__ ' | ' (_,.__,._) ' | ` " " `' `' ` " " 802.11p | ` ` ` ` ` ` < - - - - - - - - ` - - - ` -`- -`- - - - - - - ` - - - - - ` - | ` " "` ` ` | ' ___ ' ' ___ ' | ' _/ L\__ ' ' _/ L\__ ' \ ' (_,.__,._) ' ' (_,.__,._) ' ` `' `' ` ` `' `' ` ________________`__________ `__________________`___________`___ ` ` ` ` " " 802.11p " " Figure 2: The extended DNS scenario Karagiannis, et al. Expires March 23, 2014 [Page 17] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 5.1.1 Dynamic IP address-to-geographical Address Resolution A method similar to the name resolution (DNS) method can be provided. The user of this method may query a server in this way: it provides it an IP address and obtains in return the geographical coordinates of where the interface assigned that IP address is situated, or vice-versa. The method should also work for groups of IP addresses (prefixes) and three-dimensional regions. 5.2 GeoServer A design approach for Internet-wide geo-networking is to introduce a new network element that serves as a message reflector to facilitate the communication among vehicles. This network element functions as a server. It processes incoming messages from each vehicle, aggregates these messages when appropriate, and redistributes the messages to other vehicles. Since this server is typically responsible for a geographical area, it is termed GeoServer. The main functionality of a GeoServer is to provide vehicles with geographical-related services such as for traffic safety and traffic efficiency & management and infotainment-type of applications. The GeoServer is linked to an application server; both might be co-located. The application scenario is illustrated in Figure 3. Coverage Area - ~ - ` ` +-------+ ' ' | App | +------+ ` ` | Server| ___|Access|____` ` +-------+ +----------+ / |Router| +`-----------------`+ | / \ / +------+ | ` O ` | +-------+ / \/ | ' - ~ - ' | | Geo |___/ Internet \ | ` O ` | | Server| \ / | ' - ~ - ' | +-------+ \ /\ +------+ | ` ` | \ / \____|Access|____, O `| +----------+ |Router| |` `| +------+ | ` ` | | ' ' | | ` - ~ - ` | | Destination Area | +-------------------+ O Destination Nodes Figure 3: GeoServer scenario Applications may work vehicle or AppServer-triggered. In a typical vehicle-triggered scenario, the vehicle may detect a road works or obstacle by any means (local sensors, communication over other media or user input), triggers a message and sends it to the GeoServer. Karagiannis, et al. Expires March 23, 2014 [Page 18] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 The GeoServer can either forwards the messages directly to the destination area or involve the AppServer for information aggregation before forwarding the data. In the GeoServer-triggered scenario, the application server acts as originator of a message, based on data aggregation or information from a traffic management center or static configuration. The scenario requires three main communication tasks [ITSWC2012], [WANG2013]: location updates, event reporting and geographical messaging (GeoMessaging). Location updates are periodically sent from the vehicle to the GeoServer. Their transmission can be triggered query-based, time-based, distance-based, grid-based (or a combination) (see [ITSWC2011]). If the driver or the vehicle detects an event, then the event will be reported to the GeoServer. The GeoServer enables the distribution of messages to vehicles in a geographical area. The GeoServer also takes care of periodic re- transmission of the warning during the lifetime of the event, i.e. the repetition of the messages in order to keep the information alive in the destination area when vehicles start their journey or enter the area. 6. Security Considerations According to requirement 3.8.1, the Internet-wide geo-networking solution MUST support security objectives for all supported communication modes. Security objectives particularly include integrity, privacy and non-repudiation and SHOULD protect the network and transport layer protocol headers. In addition the Internet-wide geo-networking solution MUST also protect privacy, i.e. provide confidentiality to personal data such as node identifier and location. 7. IANA Considerations No IANA considerations are considered in this document. 8. Acknowledgments We would like to thank the members of the IETF ITS community for their comments and discussions. Furthermore, we would like to thank the authors of the Internet draft [draft-karagiannis-traffic-safety- requirements], G. Karagiannis, R. Wakikawa, J. Kenney, C. J. Bernardos and F. Kargl, since some parts of the traffic safety application descriptions are taken from the mentioned draft. 9. Normative References 10. Informative References [C2C-CC] C2C-CC official website, http://www.car-2-car.org/, (visited in October 2009). Karagiannis, et al. Expires March 23, 2014 [Page 19] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 [C2C-CC_MANIFESTO] Car to Car Communication Consortium, "Car to Car Communication Consortium Manifesto: Overview of the C2C-CC System", C2C-CC, version 1.1, 2007. [CVIS] CVIS EU FP6 project website, http://www.cvisproject.org, (visited in October 2009). [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, Festag, A., Lenardi, M., "Automotive industry requirements for NEMO Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, (Work in progress), 2009. [draft-karagiannis-traffic-safety-requirements] Karagiannis, G., Wakikawa, R., Kenney, J., Bernardos, C.J., Kargl, F.,"Traffic safety applications requirements, IETF Internet draft (work in progress), draft-karagiannis- traffic-safety-requirements-02.txt, February 2010; [ETSI TC ITS] ETSI official website, http://www.etsi.org/, (visited in October 2009). [ETSI-TR-102-638] ETSI TR 102 638, "Intelligent Transport System (ITS); Vehicular Communications; Basic Set of Applications; Definition", ETSI specification TR 102 638, v.1.1.1, June 2009. [ETSI-EN-302-636-1] ETSI TS 102 636-1 V1.1.1, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 1: Requirements", ETSI Specification ETSI TS 102 636-1 V1.1.1, March 2010 [ETSI-EN-302-636-4-1] ETSI TS 102 636-4-1, "Intelligent Transport Systems (ITS); Vehicular communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point- to-multipoint communications; Sub-part 1: Media-Independent Functionality", ETSI specification ETSI TS 102 636-4-1 V1.1.1, June 2011 [ETSI-EN-302-636-6-1] ETSI TS 102 636-6-1 V1.1.1, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols", ETSI specification ETSI TS 102 636-6-1 V1.1.1, March 2011 [FiHe11] Fioreze, T. and Heijenk, G.J. (2011) Extending the Domain Name System (DNS) to Provide Geographical Addressing Towards Vehicular Ad-Hoc Networks (VANETs). In: 2011 IEEE Vehicular Networking Conference (VNC), 14 - 16 Nov 2011, Amsterdam, The Netherlands. pp. 70-77. IEEE. ISBN 978-1-4673-0047-6 [GEONET] GeoNet EU FP7 project website, http://www.geonet-project.eu, (visited in October 2009). [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)-Networking Services", 2007. Karagiannis, et al. Expires March 23, 2014 [Page 20] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 [KaAl11] Karagiannis, G. Altintas, O., Ekici,E., Heijenk, G.J., Jarupan, B., Lin, K., Weil, T., "Vehicular networking: A survey and tutorial on requirements, architectures, challenges, standards and solutions", IEEE Communications Surveys & Tutorials, 13 (4). pp. 584- 616. ISSN 1553-877X, 2011. [ITSWC2012] A. Festag, M. Wiecker, N. Zahariev: "Safety and Traffic Efficiency Appllications for GeoMessaging over Cellular Networks", 19th ITS World Congress and Exhibition, Vienna, Austria, October 2012 [ITSWC2011] G. Jodlauk, R. Rembarz, Z. Xu: "An Optimized Grid-Based Geocasting Method for Cellular Mobile Networks", in Proc. 18th ITS World Congress, Orlando, USA, Oct. 2011 [WANG2013] S. Wang, L. Le, N. Zahariev, and K. K. Leung: "Centralized Rate Control Mechanism for Cellular-Based Vehicular Networks", accepted for IEEE Global Communications Conference GLOBECOM) 2013, Dec. 2013. [PREDRIVE-C2x] Pre-Drive C2X EU FP7 project website, http://www.pre-drive-c2x.eu, (visited in October 2009). [RFC2009] T. Imielinski and J. Navas, "GPS-Based Addressing and Routing", RFC 2009, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1876] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996. [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [SAFESPOT] SAFESPOT EU FP6 project website, http://www.safespot-eu.org, (visited in October 2009). [SEVECOM] SEVECOM EU FP6 project website, http://www.sevecom.org, (visited in October 2009). [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 591, April 2006. [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, Final Annual Report, DOT HS 811 073, January 2009. [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ VSCA-1609_080827.pdf Karagiannis, et al. Expires March 23, 2014 [Page 21] Internet-Draft Internet-wide Geo-networking Prob. Stat. September 2013 11. Authors' Address Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@utwente.nl Geert Heijenk University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: geert.heijenkg@utwente.nl Andreas Festag Technical University Dresden & NEC Laboratories Europe Germany Email: andreas.festag@ifn.et.tu-dresden.de?; Alexandru Petrescu CEA Communicating Systems Laboratory, Point Courrier 173 Palaiseau, F-91120 France Phone: +33(0)169089223 Email: alexandru.petrescu@cea.fr Alison Chaiken Mentor Embedded Software Division 46871 Bayside Parkway Fremont, CA 94538 USA Email: alison@she-devel.com Karagiannis, et al. Expires March 23, 2014 [Page 22]