Network Working Group Z. Yan Internet-Draft CNNIC Intended status: Standards Track J. Lee Expires: October 28, 2016 Sangmyung University April 26, 2016 Requirements for Data Aggregation in Intelligent Transportation Systems draft-yan-its-aggregation-00.txt Abstract Considering the large-scale but small-sized information exchange in the vehicular information network, this draft aims to outline the requirements to support the data aggregation in ITS, in order to make the information retrieval and dissemination more efficient. 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. 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 October 28, 2016. Copyright Notice Copyright (c) 2016 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 Yan & Lee Expires October 28, 2016 [Page 1] Internet-Draft ITS Data Aggregation April 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Data naming . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Aggregation and Segregation . . . . . . . . . . . . . . . . . 4 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security considerations . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction A vehicular information network aims to implement a myriad of applications related to vehicles, traffic information, drivers, passengers and pedestrians. Then a flexible data integration and segregation architecture in ITS should be designed to support the exchange of a huge number of heterogeneous information objects in an efficient and scalable manner. The main case for data integration we discuss in this draft is: multiple requested information objects originated from different sources share some or all hops on the transmission paths. This draft outlines the general requirements for data integration from several key aspects described in the following sections. But this draft does not specify the requirements in special communication cases, such as V2X, I2X, V2I2V and so on, the particular requirements under these special cases will be analyzed in the future. 2. Data naming Generally, location and data type are potentially critical indexes for data retrieval in ITS. Also, for configuration, management and maintenance, devices may need to be accessed directly by a device- specific identifier. Therefore, the naming scheme needs to incorporate location, data type and device information, in order to be scalable to support trillions of information objects. Yan & Lee Expires October 28, 2016 [Page 2] Internet-Draft ITS Data Aggregation April 2016 o Location-based: A critical organizing factor for vehicular sensing data, especially that which is to be widely shared and fused, is the location to which it applies. o Device-based: in some cases, the data produced by the specialized vehicle or infrastructure device may be requested. o Type-based: another critical element for naming is the type of data. Namespaces will also incorporate data type designators, such as speed, emission, trajectory and so on. Then to better support the data aggregation, the name included in the data request message should be designed as: /Producer1:Producer2:...ProducerX/ Location1:Location2:...LocationY/ Type1:Type2:...TypeZ/ end/ [The format of the content name used in this draft only identifies the logic of the name structure.] The parsing logic is: the data objects with Type (1,2,...Z) created from Location (1,2,...Y) by Producer(1,2,...X) are requested (producer here identifies the device). For example, if a vehicle wants to get the traffic information in Street-1, Street-2 and Street-3 (without specifying the data producer/device), a name of the data may be: //Street-1:Street-2:Street-3/traffic/end/ In most cases, the requester only cares about what information it wants, but does not exactly know the information source. In other words, it is possible that the requester can not specify the destination address of the request message. Then a service discovery scheme, which may make use of the information in the data name as the index, should be designed in ITS. 3. Routing Because ITS WG aims to apply the IP technologies to the ITS, then the routing table and routing scope should be adaptively designed based on the TCP/IP stack. (1) Routing table To support different kinds of ITS communication and different aggregation policies, in the routing table of the router in the RSU and the edge router in the vehicle, there are two types of entries at Yan & Lee Expires October 28, 2016 [Page 3] Internet-Draft ITS Data Aggregation April 2016 least should be maintained: geo-location based and IP based routing entries. The former one is based on the geographical location information of the routers, which is established based on the coordinate information exchanged between routers or through centralized configuration. While the latter one is established based on the normal routing protocols in the TCP/IP network. 2) Routing scope As in the IP network, the routing scopes also mainly include multicast and unicast for different communication cases. Then different routers may be configured to different multicast groups (we mainly consider the IPv6 scenario). And one router may also belong to multiple different multicast groups. Although the data aggregation acts like the multicast to converge the communications, it is the packet-level optimization and can be applied in both unicast and multicast cases. 4. Aggregation and Segregation Based on the naming labels and the routing information, the router (especially the router in RSU) will decide if the request packet should be split over its multiple outgoing network interfaces. Specially, the router should determine if the outgoing network interfaces for the multiple data elements are same: if so, direct forwarding is made based on the matched entry in the routing table; otherwise, the router has to split the original request packet into multiple new request packets according to their different outgoing network interfaces and send them to different next-hop routers accordingly with the newly generated names. Similarly, if the data is sent back through the reverse path, they can be aggregated. As illustrated above, based on the routing table, the router decides if the request message should be split over their related outgoing network interfaces. However, some conditions (e.g., traffic jam or traffic accident information should be learnt by the traffic administrator as soon as possible) in the vehicular information network change quickly and quite frequently. As a result, the timer value used for the data aggregation should be carefully set. Different policies for setting the timer value can be used and such policies need to be indicated by the upper level aggregator (e.g., previous-hop router) in the request message. Generally, some of the request messages should be handled on a first-in-first-out basis such as in the emergency case; while, some of the request messages can only be processed until all the required information is collected (e.g., in the case where we retrieve the overall traffic condition information). The upper level aggregator can indicate the timer value to the lower level ones (e.g., the next-hop router) in the Yan & Lee Expires October 28, 2016 [Page 4] Internet-Draft ITS Data Aggregation April 2016 request message. But the protocol to support this notification and policy decision is beyond the scope of this document. Another key element to support the aggregation and segregation procedure is a pending table which maintains the original data name and the newly extracted data names. This table is mainly maintained by the branching node on the communication path, who conducts the segregation operation. In this way, the reverse operation (data aggregation) can be executed. +---+ | V3|-----\ +---+ | | +-----+ //Street-3/traffic/end/ |RSU3 |------------------\ +-----+ | //Street-3:Street-4/traffic/end/ +-----+ +-----+ |RSU2 |-----------------|RSU1 | +-----+ +-----+ +-----+ | | |RSU4 |------------------/ | +-----+ //Street-4/traffic/end/ | | +---+ +---+ | |V1 | |V4 |-----/ +---+ +---+ //Street-3:Street-4/traffic/end/ Figure 1: Operation of the aggregation and segregation An example of the aggregation and segregation is shown in Figure 1. In this figure, Vehicle-1(V1), Vehicle-3(V3), and Vehicle-4(V4) connect to the Internet through RSU1, RSU3 and RSU4 respectively. When V1 wants to know the current traffic states of two blocks served by RSU3 and RSU4 to select a better path between them, it sends out the data request message with the data name //Street-3:Street- 4/traffic/end/. When RSU1 receives this request message, it directly sends the message to RSU2 because the next hop to request all the data in this message comes from RSU2. But when RSU2 receives this message, it will recognize that the data should be requested from two different outgoing interfaces directing to RSU3 and RSU4 respectively. Then two new names are generated through the information extraction from the original name. Specially, the data request for the new name //Street-3/traffic/end/ is sent to RSU3 and the data request for the new name //Street-4/traffic/end/ is sent to RSU4. Yan & Lee Expires October 28, 2016 [Page 5] Internet-Draft ITS Data Aggregation April 2016 After retrieval of the data corresponding to the two data request messages, the aggregation is conducted through the reverse path based on the recorded states. 5. Caching Cache is necessary to reduce unnecessary data transmission, thus improving scalability in ITS. When the router receives a data request, it will check its cache firstly. Based on the cache hit result, the request may be segregated when it is possible. Generally, two different cache tables should be maintained: o Time-sensitive data cache: some data in the ITS is very time- sensitive, such as the traffic jam condition. Then the timer should be strictly inherited from the related response message for the particular data. o Time-insensitive data cache: for other time-insensitive data, such as the geo-map information, a default timer with long life-time should be used to serve the following requests efficiently. 6. Other issues TBD 7. Security considerations TBD 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China EMail: yan@cnnic.cn Yan & Lee Expires October 28, 2016 [Page 6] Internet-Draft ITS Data Aggregation April 2016 Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan Republic of Korea EMail: jonghyouk@smu.ac.kr Yan & Lee Expires October 28, 2016 [Page 7]