idnits 2.17.1 draft-kim-icnrg-pubsubvn-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ICN Research Group H. Kim 2 Internet Draft K. Choi 3 Intended status: Informational H. Jung 4 Expires: December 31, 2019 S. Kim 5 ETRI 6 July 4, 2019 8 Publish-Subscribe Service in ICN-based Vehicular Network 9 draft-kim-icnrg-pubsubvn-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at https://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on December 31, 2019. 28 Copyright Notice 30 Copyright (c) 2019 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with 38 respect to this document. 40 Abstract 42 As autonomous vehicle is becoming a major research in automotive 43 engineering, the importance of vehicular network is also increasing. 44 Content-oriented vehicular network requires new communication 45 architecture that is different from the existing IP-based 46 architecture. ICN is one of the best alternatives for vehicular 47 network to serve as communication infrastructure. ICN only supports 48 pull-based communication. Therefore, an efficient communication 49 method is needed for disseminating safety information for vehicles, 50 and the publish/subscribe(pub/sub) system can be a good alternative. 51 This document proposes a pub/sub service architecture and procedures 52 for disseminating safety information between vehicles and 53 infrastructure. 55 Table of Contents 57 1. Introduction ................................................ 2 58 2. Pub/Sub Service Architecture for ICN-based Vehicular Network 3 59 2.1. Pub/Sub Applications ................................... 3 60 2.2. Pub/Sub Service Architecture ........................... 3 61 2.3. Name Structure ......................................... 4 62 3. Pub/Sub Service Procedure ................................... 5 63 3.1. Publish Procedure ...................................... 5 64 3.2. Data Synchronization Procedure ......................... 6 65 3.3. Subscribe Procedure .................................... 7 66 4. Open Research Challenges .................................... 7 67 5. IANA Considerations ......................................... 8 68 6. Security Considerations ..................................... 8 69 7. References .................................................. 9 70 7.1. Normative References ................................... 9 71 7.2. Informative References ................................. 9 72 8. Acknowledgments ............................................. 9 74 1. Introduction 76 ICN is one of the future internet alternatives, which focuses on 77 contents rather than connectivity. ICN has unique attributes such as 78 location independent naming, in-network caching, name-based routing 79 and built-in security [BARI12]. 81 The vehicular network helps to exchange information between 82 infrastructure and vehicles by providing driver assistance such as 83 safety, traffic information and other value-added services [WANG19]. 84 ICN is one of the best alternatives to efficiently communicate the 85 safety information in the vehicular network [KHEL19]. 87 The pub/sub system supports asynchronous one-to-many communication 88 and is one of best ways to broadcast events [TARA12]. The pub/sub 89 system in ICN-based vehicular network can be a solution to 90 efficiently disseminate information in terms of events to vehicle 91 users who desire the information. The advantage of this architecture 92 has in-network caching of ICN and information dissemination of the 93 pub/sub system. 95 This document represents an ICN-based pub/sub service architecture 96 for V2I communication on the vehicular Network and describes a 97 publish and subscribe procedures under the proposed architecture. It 98 also describes future research issues required for enhanced pub/sub 99 services in ICN-based vehicular network. 101 2. Pub/Sub Service Architecture for ICN-based Vehicular Network 103 2.1. Pub/Sub Applications 105 In [KHEL19], VANET applications was classified into three main 106 categories: safety applications, traffic information applications, 107 and comfort applications. This document also classifies applications 108 into three categories: 110 o Safety Applications : It concerns lives of the drivers and the 111 passengers 113 o Traffic Information Applications : It provides up-to-date traffic 114 information 116 o Infotainment Applications : It aims to improve the drivers and 117 the passengers comfort and provide an information 119 Among these applications, safety applications and infotainment 120 applications are suitable for pub/sub services because the intent of 121 subscribers is important. 123 2.2. Pub/Sub Service Architecture 125 For the proposed architecture, this document assumes the running 126 environment of vehicular network. First, there are multiple 127 brokers(rendezvous nodes) for wide service coverage. Second, each 128 broker shares topic information with each other. For this purpose, 129 brokers need synchronization protocol such as PSync. Third, A 130 publisher/subscriber communicates with a closest broker. 132 Our proposed pub/sub service architecture uses immobile rendezvous 133 nodes to decouple publishers and subscribers. The rendezvous nodes 134 store and manage information about important events on the road. A 135 publisher sends important event information, such as a car accident 136 on the road, to the closest rendezvous node. Publishers and 137 subscribers can be both vehicles and persons. A subscriber registers 138 the closest rendezvous node and receives subscribed information. A 139 rendezvous node store published event information, and synchronizes 140 the stored information of other rendezvous node using a data sharing 141 protocol. Therefore, subscribers only can subscribe to a rendezvous 142 node and receive information from the rendezvous node. The 143 subscriber does not need to have information about publishers and 144 can obtain event data only by having the information on the 145 rendezvous node. Publishers and subscribers only need FIB entry 146 about the rendezvous node to send packets it. Thus, the routing of 147 proposed architecture is very simple. In addition, the rendezvous 148 node can process published event data to create useful information 149 for subscribers. 151 +-------------------+ +-------------------+ 152 | Rendezvous Node-1 | <-------------> | Rendezvous Node-N | 153 +-------------------+ Sync +-------------------+ 154 ^ ^ 155 |Subscribe Publish | 156 | | 157 =================================================================== 158 | | 159 +-----------+ +-----------+ 160 | Vehicle-1 | | Vehicle-m | 161 +-----------+ +-----------+ 163 =================================================================== 165 Figure 1: Pub/Sub Service in ICN-based Vehicular Network 167 2.3. Name Structure 169 Naming is the pinnacle of NDN that differentiates it from 170 traditional networks. NDN names should be globally unique, secure, 171 location-independent, and human-readable [BARI12]. Khelifi et al. 172 analyzed existing naming solutions in the context of VANET [KHEL19]. 173 Wang et al. proposed a data naming structure for V2V traffic 174 information dissemination [WANG12]. However, this structure is for 175 V2V communication. This document proposes a name structure for V2I 176 communication by expanding that. 178 +-------------------------------------------------------+ 179 | | 180 | /RoutableName/AppName/DataType/GeoLocation/Timestamp | 181 | | 182 +-------------------------------------------------------+ 183 Figure 2: Name Structure for Pub/Sub in ICN-VN 185 o RoutableName : routing prefix toward rendezvous node 187 Ex) /rendezvous 189 o AppName : application name 191 Ex) safety, infotainment, traffic 193 o DataType : occurred event type 195 Ex) alarm, advertisement, speed 197 o GeoLocation : geolocation information 199 Ex) /RoadID/Direction/ZoneNo 201 o Timestamp : specific time (Optional) 203 Ex) 20190721113000 (YYYYMMDDHHMMSS) 205 3. Pub/Sub Service Procedure 207 This document describes publish and subscribe procedure using the 208 safety applications. 210 3.1. Publish Procedure 212 An example of publication is as follow; 214 o There is an accident on the road. 216 o The vehicle or person is aware of an accident. 218 o The publisher generates data names according to the proposed 219 naming structure for publishing events. 221 o The publisher creates an Interest packet with event information. 222 (Use Application Parameter for NDN packet) 224 o The publisher sends an Interest packet to the rendezvous node. 226 o The rendezvous node receives an interest packet with published 227 event. 229 o The rendezvous node stores a received event. 231 +-------------------------------------------------------------+ 232 | | 233 | /RN_prefix/safety/alarm/road1-north-zone12/now/car-accident | 234 | | 235 +-------------------------------------------------------------+ 236 Figure 3: Publish Name Example 238 3.2. Data Synchronization Procedure 240 An example of Synchronization is as follow; 242 o A publisher publishes the event at the nearest rendezvous node. 244 o The rendezvous node stores published events. 246 o The rendezvous node synchronizes the list of topics on which the 247 change occurred with other rendezvous nodes. Specific methods 248 require further study. 250 o The rendezvous node uses a synchronized list of topics to 251 communicate information to subscribers. 253 3.3. Subscribe Procedure 255 An example of subscription is as follow; 257 o A subscriber(vehicle) generates name to obtain data. 259 o A subscriber creates an Interest packet under the name structure 260 and sends it to the rendezvous node. 262 o The rendezvous node receives a subscription interest packet, and 263 analyzes the name from an interest packet. 265 o The rendezvous node searches its repository for data that a 266 subscriber wants. 268 o The rendezvous node generates a manifest based on the retrieved 269 information and forwards it to the subscriber. 271 o The subscriber requests rendezvous nodes, which store the real 272 data based on the information from the received manifest. 274 o Each rendezvous node creates data packets for the information and 275 transmits. 277 o A subscriber receives the data packet, and extracts information 278 from it. 280 +-------------------------------------------------------+ 281 | | 282 | /RN_prefix/safety/alarm/road1-north-zone12/ | 283 | | 284 +-------------------------------------------------------+ 285 Figure 4: Subscribe Name Example 287 4. Open Research Challenges 289 The proposed architecture in Section 3 described how pub/sub service 290 over ICN operate. However, several research challenges remain open 291 and still need to be addressed. The list that need further study is 292 as follows: 294 o A study on the name structure to provide various vehicular 295 network applications 296 The name structure may vary depending on the nature of 297 applications in the vehicular network. For example, the name of 298 navigation application may be preferable to express the origin 299 and destination address in the name. 301 o A study on subscriber certification for provision of premium 302 pub/sub services 304 In order to provide special services to some subscribers, the 305 rendezvous node needs to perform subscriber authentication. 306 Because ICN is content name communication, the rendezvous node 307 should be a way to distinguish certified subscribers. 309 o A study on efficient push mechanism for pub/sub service 311 ICN is a pull-mode communication. A push-type communication 312 method is required that allows instantaneous delivery to 313 subscribers in occurrence of urgent event. 315 o A study on the distributed rendezvous architecture for SPOF and 316 service locality 318 The distributed rendezvous node structure has advantages in terms 319 of scalability. However, research is needed on how data is 320 synchronized between multiple rendezvous nodes and how data 321 residing on multiple rendezvous nodes is communicated to 322 subscribers. 324 5. IANA Considerations 326 This memo includes no request to IANA. 328 6. Security Considerations 330 This document does not define a new protocol (or protocol extension) 331 or a particular mechanism, and therefore introduces no specific new 332 security considerations. General security considerations for 333 Information-Centric Networking are discussed in [RFC7945]. 335 7. References 337 7.1. Normative References 339 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 340 and G. Boggia, "Information-Centric Networking: Evaluation 341 and Security Considerations", RFC 7945, DOI 342 10.17487/RFC7945, September 2016, 343 . 345 7.2. Informative References 347 [BARI12] Md. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, B. 348 Mathieu, "A survey of naming and routing in information- 349 centric networks", IEEE Communications Magazine, vol. 49, 350 no. 12, pp. 44-53, 2012. 352 [TARA12] S. Tarkoma, "Publish/Subscribe Systems Design and 353 Principles", Wiley, 2012. 355 [KHEL19] H. Khelifi, S. Luo, B. Nour, H. Moungla, Y. Faheem, R. 356 Hussain, A. Ksentini, " Named Data Networking in Vehicular 357 Ad hoc Networks: State-of-the-Art and Challenges", IEEE 358 Communications Surveys & Tutorials, 2019, < DOI: 359 10.1109/COMST.2019.2894816>. 361 [WANG12] L. Wang, R. Wakikawa, R. Kuntz, R. Vuyyuru, and L. Zhang, " 362 Data naming in vehicle-to-vehicle communications", 363 INFOCOM2012, pp. 328-333, 2012. 365 [WANG19] J. Wang, J. Liu, and N. Kato, "Networking and 366 Communications in Autonomous Driving: A Survey", IEEE 367 Communications Surveys & Tutorials, vol. 21, no. 2, pp. 368 1243-1274, 2019. 370 8. Acknowledgments 372 We thank all contributors, reviewers and the chairs for their 373 valuable time in providing the comments and feedback, which has 374 helped to improve this draft. 376 This work was supported by the ICT R&D program of MSICT/IITP. [2017- 377 0-00045, Hyper-connected Intelligent Infrastructure Technology 378 Development]. 380 Authors' Addresses 382 Haksuh Kim (editor) 383 ETRI 384 218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea 385 Email: tuple@etri.re.kr 387 Kangil Choi 388 ETRI 389 218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea 390 Email: forerunner@etri.re.kr 392 Heeyoung Jung 393 ETRI 394 218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea 395 Email: hyjung@etri.re.kr 397 Sunme Kim 398 ETRI 399 218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea 400 Email: kimsunme@etri.re.kr