idnits 2.17.1 draft-yan-ipwave-aggregation-05.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 (May 10, 2022) is 716 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 287, 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: November 11, 2022 Sejong University 6 J. Jeong 7 Sungkyunkwan University 8 H. Nakazato 9 Y. Park 10 Waseda University 11 May 10, 2022 13 Data Aggregation in IPv6-based Vehicular Networks 14 draft-yan-ipwave-aggregation-05.txt 16 Abstract 18 Considering the large-scale but small-sized information exchange in 19 the vehicular information network, this draft document aims at 20 outlining the requirements to support the data aggregation in 21 vehicular networks based on the concept of Information-centric 22 networking (ICN), in order to make the information retrieval and 23 dissemination in an efficient way. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 11, 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Data naming . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Aggregation and Segregation . . . . . . . . . . . . . . . . . 4 69 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 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. Acknowledgements 282 This work was supported by the Beijing Nova Program of Science and 283 Technology under grant Z191100001119113. 285 9. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 Authors' Addresses 294 Zhiwei Yan 295 CNNIC 296 No.4 South 4th Street, Zhongguancun 297 Beijing 100190 298 China 300 EMail: yan@cnnic.cn 302 Jong-Hyouk Lee 303 Sejong University 304 209, Neungdong-ro, Gwangjin-gu 305 Seoul 05006 306 Republic of Korea 308 EMail: jonghyouk@sejong.ac.kr 310 Jaehoon Paul Jeong 311 Department of Computer Science and Engineering 312 Sungkyunkwan University 313 2066 Seobu-Ro, Jangan-Gu 314 Suwon, Gyeonggi-Do 315 Republic of Korea 317 EMail: pauljeong@skku.edu 319 Hidenori Nakazato 320 Waseda University 321 1-6-1,Nishi-Waseda,Shinjuku-ku 322 Tokyo 323 Japan 325 EMail: nakazato@waseda.jp 326 Yong-Jin Park 327 Waseda University 328 1-6-1,Nishi-Waseda,Shinjuku-ku 329 Tokyo 330 Japan 332 EMail: yjpark19@gmail.com