idnits 2.17.1 draft-yan-ipwave-aggregation-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 26, 2019) is 1606 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 282, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Standards Track J. Lee 5 Expires: May 29, 2020 Sangmyung University 6 J. Jeong 7 Sungkyunkwan University 8 Y. Park 9 University of Malaysia Sabah 10 H. Nakazato 11 Waseda University 12 November 26, 2019 14 Data Aggregation in IPv6-based Vehicular Networks 15 draft-yan-ipwave-aggregation-00.txt 17 Abstract 19 Considering the large-scale but small-sized information exchange in 20 the vehicular information network, this draft document aims at 21 outlining the requirements to support the data aggregation in 22 vehicular networks based on the concept of Information-centric 23 networking (ICN), in order to make the information retrieval and 24 dissemination in an efficient way. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 29, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Data naming . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Aggregation and Segregation . . . . . . . . . . . . . . . . . 4 70 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 A vehicular information network aims at implementing a myriad of 79 applications related to vehicles, traffic information, drivers, 80 passengers and pedestrians. Then a flexible data integration and 81 segregation architecture in Intelligent Transportation Systems (ITS) 82 should be designed to support the exchange of a huge number of 83 heterogeneous information objects in an efficient and scalable 84 manner. 86 The main case for data integration we discuss in this draft is: 87 multiple requested information objects originated from different 88 sources are shared in some or all hops on the transmission paths. 90 This document outlines the general requirements for data integration 91 from several key aspects described in the following sections. But 92 this draft does not specify the requirements in special communication 93 cases, such as Vehicle-to-Everything (V2X), Infrastructure-to- 94 Everything (I2X), and Vehicle-to-Infrastructure-to-Vehicle (V2I2V) 95 communications. The particular requirements under these special 96 cases will be analyzed in the future. 98 2. Data naming 100 Generally, location and data type are potentially critical indexes 101 for data retrieval in ITS. Also, for configuration, management, and 102 maintenance, devices may need to be accessed directly by a device- 103 specific identifier. Therefore, a naming scheme needs to incorporate 104 location, data type and device information, in order to be scalable 105 to support trillions of information objects. 107 o Location-based: A critical organizing factor for vehicular sensing 108 data, which is to be widely shared and fused, is the location to 109 which it applies. 111 o Device-based: In some cases, the data produced by a specialized 112 vehicle or infrastructure device may be requested. 114 o Type-based: Another critical element for naming is the type of 115 data. Namespaces need also incorporate data type designators, 116 such as speed, emission, trajectory and so on. 118 Then to better support the data aggregation, the name included in the 119 data request message can be designed as: 121 /Producer1:Producer2:...ProducerX/ Location1:Location2:...LocationY/ 122 Type1:Type2:...TypeZ/ end/ 124 [The format of the content name used in this document only identifies 125 the logic of the name structure.] 127 The parsing logic is: the data objects with Type (1,2,...,Z) created 128 from Location (1,2,...,Y) by Producer(1,2,...,X) are requested. A 129 producer identifies the device here. 131 For example, if a vehicle wants to get the traffic information in 132 Street-1, Street-2, and Street-3 (without specifying the data 133 producer/device), a name of the data may be: 135 //Street-1:Street-2:Street-3/traffic/end/ 137 In most cases, the requester only cares what information it wants, 138 but does not exactly know the information source. In other words, it 139 is possible that the requester can not specify the destination 140 address of the request message. Thus a service discovery scheme, 141 which may make use of the information in the data name as the index, 142 can be designed in ITS. 144 3. Routing 146 In IP-based vehicular networks, the routing table and routing scope 147 should be adaptively designed based on the TCP/IP stack. 149 (1) Routing Table 151 To support different kinds of ITS communication and different 152 aggregation policies, in the routing table of the router in the RSU 153 and the edge router in the vehicle, there are at least two types of 154 entries to be maintained: geo-location based and IP based routing 155 entries. The former one is based on the geographical location 156 information of the routers, which is established either through the 157 coordinate information exchanged between routers or through 158 centralized configuration. On the other hand, the latter one is 159 established based on the normal routing protocols in the TCP/IP 160 network. 162 2) Routing Scope 164 As in the IP network, the routing scopes also mainly include 165 multicast and unicast for different communication cases. Then 166 different routers may be configured for different multicast groups. 167 This document mainly considers IPv6 scenario. One router may also 168 belong to multiple different multicast groups. Although the data 169 aggregation acts like the multicast to converge the communications, 170 it is the packet-level optimization and can be applied to both 171 unicast and multicast cases. 173 4. Aggregation and Segregation 175 Based on the naming labels and the routing information, the router 176 (especially a router in an RSU) will decide whether the request 177 packet should be split over its multiple outgoing network interfaces 178 or not. Specially, the router should determine whether the outgoing 179 network interfaces for the multiple data elements the same or not. 180 If so, direct forwarding is made based on the matched entry in the 181 routing table. Otherwise, the router has to split the original 182 request packet into multiple new request packets according to their 183 different outgoing network interfaces and send them to different 184 next-hop routers according to the newly generated names. Similarly, 185 if the data is sent back through the reverse path, they can be 186 aggregated. 188 As illustrated above, based on the routing table, the router decides 189 whether the request message should be split over their related 190 outgoing network interfaces or not. However, some conditions (e.g., 191 traffic jam or traffic accident information) should be learned by the 192 traffic administrator as soon as the vehicular information network 193 changes quickly and quite frequently. As a result, a timer value 194 used for the data aggregation should be carefully set. Different 195 policies for setting the timer value can be used and such policies 196 need to be indicated by the upper level aggregator (e.g., previous- 197 hop router) in the request message. Generally, some of the request 198 messages should be handled on a first-in-first-out basis, for 199 example, in the emergency case. On the other hand, some of the 200 request messages can only be processed until all the required 201 information is collected, for example, in the case where the overall 202 traffic condition information is required. The upper level 203 aggregator can set up the timer value to the lower level ones (e.g., 204 the next-hop router) in the request message. But the protocol to 205 support this notification and policy decision is beyond the scope of 206 this document. 208 Another key element to support the aggregation and segregation 209 procedure is a pending table that maintains the original data name 210 and the newly extracted data names. This table is mainly maintained 211 by a branching node on the communication path, which conducts the 212 segregation operation. In this way, the reverse operation (i.e., 213 data aggregation) can be executed. 215 +---+ 216 | V3|-----\ 217 +---+ | 218 | 219 +-----+ //Street-3/traffic/end/ 220 |RSU3 |------------------\ 221 +-----+ | //Street-3:Street-4/traffic/end/ 222 +-----+ +-----+ 223 |RSU2 |-----------------|RSU1 | 224 +-----+ +-----+ 225 +-----+ | | 226 |RSU4 |------------------/ | 227 +-----+ //Street-4/traffic/end/ | 228 | +---+ 229 +---+ | |V1 | 230 |V4 |-----/ +---+ 231 +---+ //Street-3:Street-4/traffic/end/ 233 Figure 1: Operation of the Aggregation and Segregation 235 An example of the aggregation and segregation is shown in Figure 1. 236 In this figure, Vehicle-1(V1), Vehicle-3(V3), and Vehicle-4(V4) 237 connect to the Internet through RSU1, RSU3, and RSU4, respectively. 238 When V1 wants to know the current traffic states of two blocks served 239 by RSU3 and RSU4 to select a better path between them, it sends out 240 the data request message with the data name //Street-3:Street- 241 4/traffic/end/. When RSU1 receives this request message, it directly 242 sends the message to RSU2 because the next hop to request all the 243 data in this message comes from RSU2. But when RSU2 receives this 244 message, it will recognize that the data should be requested from two 245 different outgoing interfaces toward RSU3 and RSU4, respectively. 246 Then two new names are generated through the information extraction 247 from the original name. Specially, the data request for the new name 248 //Street-3/traffic/end/ is sent to RSU3 and the data request for the 249 new name //Street-4/traffic/end/ is sent to RSU4. 251 After the retrieval of the data corresponding to the two data request 252 messages, the aggregation is conducted through the reverse path based 253 on the recorded states. 255 5. Caching 257 Caching is necessary to reduce unnecessary data transmissions, so it 258 can improve the scalability in ITS. When the router receives a data 259 request, it will check its cache firstly. Based on the cache hit 260 result, the request may be segregated when it is possible. 261 Generally, two different cache tables should be maintained: 263 o Time-sensitive Data Cache: Some data in the ITS is very time- 264 sensitive, such as traffic jam condition. Thus, the timer should 265 be strictly inherited from the related response message for the 266 particular data. 268 o Time-insensitive Data Cache: for other time-insensitive data, such 269 as the geo-map information, a default timer with a long lifetime 270 should be used to serve the following requests efficiently. 272 6. Other Issues 274 TBD 276 7. Security Considerations 278 TBD 280 8. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 Authors' Addresses 289 Zhiwei Yan 290 CNNIC 291 No.4 South 4th Street, Zhongguancun 292 Beijing 100190 293 China 295 EMail: yan@cnnic.cn 297 Jong-Hyouk Lee 298 Sangmyung University 299 31, Sangmyeongdae-gil, Dongnam-gu 300 Cheonan 301 Republic of Korea 303 EMail: jonghyouk@smu.ac.kr 305 Jaehoon Paul Jeong 306 Department of Computer Science and Engineering 307 Sungkyunkwan University 308 2066 Seobu-Ro, Jangan-Gu 309 Suwon, Gyeonggi-Do 310 Republic of Korea 312 EMail: pauljeong@skku.edu 314 Yong-Jin Park 315 University of Malaysia Sabah 316 88400, Kota Kinabalu 317 Sabah 318 Malaysia 320 EMail: yjpark@ums.edu.my 322 Hidenori Nakazato 323 Waseda University 324 1-6-1,Nishi-Waseda,Shinjuku-ku 325 Tokyo 326 Japan 328 EMail: nakazato@waseda.jp