IPWAVE Working Group Z. Yan Internet-Draft CNNIC Intended status: Standards Track J. Lee Expires: May 19, 2021 Sangmyung University J. Jeong Sungkyunkwan University Y. Park University of Malaysia Sabah H. Nakazato Waseda University November 15, 2020 Data Aggregation in IPv6-based Vehicular Networks draft-yan-ipwave-aggregation-02.txt Abstract Considering the large-scale but small-sized information exchange in the vehicular information network, this draft document aims at outlining the requirements to support the data aggregation in vehicular networks based on the concept of Information-centric networking (ICN), in order to make the information retrieval and dissemination in an efficient way. 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 https://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 May 19, 2021. Yan, et al. Expires May 19, 2021 [Page 1] Internet-Draft Data Aggregation November 2020 Copyright Notice Copyright (c) 2020 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Data naming . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Aggregation and Segregation . . . . . . . . . . . . . . . . . 4 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction A vehicular information network aims at implementing a myriad of applications related to vehicles, traffic information, drivers, passengers and pedestrians. Then a flexible data integration and segregation architecture in Intelligent Transportation Systems (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 are shared in some or all hops on the transmission paths. This document 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 Vehicle-to-Everything (V2X), Infrastructure-to- Everything (I2X), and Vehicle-to-Infrastructure-to-Vehicle (V2I2V) communications. The particular requirements under these special cases will be analyzed in the future. Yan, et al. Expires May 19, 2021 [Page 2] Internet-Draft Data Aggregation November 2020 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, a naming scheme needs to incorporate location, data type and device information, in order to be scalable to support trillions of information objects. o Location-based: A critical organizing factor for vehicular sensing data, 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 a specialized vehicle or infrastructure device may be requested. o Type-based: Another critical element for naming is the type of data. Namespaces need 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 can be designed as: /Producer1:Producer2:...ProducerX/ Location1:Location2:...LocationY/ Type1:Type2:...TypeZ/ end/ [The format of the content name used in this document 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. A producer identifies the device here. 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 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. Thus a service discovery scheme, which may make use of the information in the data name as the index, can be designed in ITS. Yan, et al. Expires May 19, 2021 [Page 3] Internet-Draft Data Aggregation November 2020 3. Routing In IP-based vehicular networks, 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 at least two types of entries to 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 either through the coordinate information exchanged between routers or through centralized configuration. On the other hand, 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 for different multicast groups. This document mainly considers IPv6 scenario. 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 to both unicast and multicast cases. 4. Aggregation and Segregation Based on the naming labels and the routing information, the router (especially a router in an RSU) will decide whether the request packet should be split over its multiple outgoing network interfaces or not. Specially, the router should determine whether the outgoing network interfaces for the multiple data elements the same or not. 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 according to 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 whether the request message should be split over their related outgoing network interfaces or not. However, some conditions (e.g., traffic jam or traffic accident information) should be learned by the Yan, et al. Expires May 19, 2021 [Page 4] Internet-Draft Data Aggregation November 2020 traffic administrator as soon as the vehicular information network changes quickly and quite frequently. As a result, a 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, for example, in the emergency case. On the other hand, some of the request messages can only be processed until all the required information is collected, for example, in the case where the overall traffic condition information is required. The upper level aggregator can set up the timer value to the lower level ones (e.g., the next-hop router) in the 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 that maintains the original data name and the newly extracted data names. This table is mainly maintained by a branching node on the communication path, which conducts the segregation operation. In this way, the reverse operation (i.e., 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 Yan, et al. Expires May 19, 2021 [Page 5] Internet-Draft Data Aggregation November 2020 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 toward 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. After the 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 Caching is necessary to reduce unnecessary data transmissions, so it can improve the 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 traffic jam condition. Thus, 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 a long lifetime 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, . Yan, et al. Expires May 19, 2021 [Page 6] Internet-Draft Data Aggregation November 2020 Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China EMail: yan@cnnic.cn Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan Republic of Korea EMail: jonghyouk@smu.ac.kr Jaehoon Paul Jeong Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do Republic of Korea EMail: pauljeong@skku.edu Yong-Jin Park University of Malaysia Sabah 88400, Kota Kinabalu Sabah Malaysia EMail: yjpark@ums.edu.my Hidenori Nakazato Waseda University 1-6-1,Nishi-Waseda,Shinjuku-ku Tokyo Japan EMail: nakazato@waseda.jp Yan, et al. Expires May 19, 2021 [Page 7]