[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
ICN Research Group                                               H. Kim
Internet Draft                                                  K. Choi
Intended status: Informational                                  H. Jung
Expires: December 31, 2019                                       S. Kim
                                                           July 4, 2019

          Publish-Subscribe Service in ICN-based Vehicular Network

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 December 31, 2019.

Copyright Notice

   Copyright (c) 2019 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
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.


   As autonomous vehicle is becoming a major research in automotive
   engineering, the importance of vehicular network is also increasing.
   Content-oriented vehicular network requires new communication

Kim, et al.           Expires December 31, 2019               [Page 1]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

   architecture that is different from the existing IP-based
   architecture. ICN is one of the best alternatives for vehicular
   network to serve as communication infrastructure. ICN only supports
   pull-based communication. Therefore, an efficient communication
   method is needed for disseminating safety information for vehicles,
   and the publish/subscribe(pub/sub) system can be a good alternative.
   This document proposes a pub/sub service architecture and procedures
   for disseminating safety information between vehicles and

Table of Contents

   1. Introduction ................................................ 2
   2. Pub/Sub Service Architecture for ICN-based Vehicular Network  3
      2.1. Pub/Sub Applications ................................... 3
      2.2. Pub/Sub Service Architecture ........................... 3
      2.3. Name Structure ......................................... 4
   3. Pub/Sub Service Procedure ................................... 5
      3.1. Publish Procedure ...................................... 5
      3.2. Data Synchronization Procedure ......................... 6
      3.3. Subscribe Procedure .................................... 7
   4. Open Research Challenges .................................... 7
   5. IANA Considerations ......................................... 8
   6. Security Considerations ..................................... 8
   7. References .................................................. 9
      7.1. Normative References ................................... 9
      7.2. Informative References ................................. 9
   8. Acknowledgments ............................................. 9

1. Introduction

   ICN is one of the future internet alternatives, which focuses on
   contents rather than connectivity. ICN has unique attributes such as
   location independent naming, in-network caching, name-based routing
   and built-in security [BARI12].

   The vehicular network helps to exchange information between
   infrastructure and vehicles by providing driver assistance such as
   safety, traffic information and other value-added services [WANG19].
   ICN is one of the best alternatives to efficiently communicate the
   safety information in the vehicular network [KHEL19].

   The pub/sub system supports asynchronous one-to-many communication
   and is one of best ways to broadcast events [TARA12]. The pub/sub
   system in ICN-based vehicular network can be a solution to
   efficiently disseminate information in terms of events to vehicle

Kim, et al.           Expires December 31, 2019               [Page 2]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

   users who desire the information. The advantage of this architecture
   has in-network caching of ICN and information dissemination of the
   pub/sub system.

   This document represents an ICN-based pub/sub service architecture
   for V2I communication on the vehicular Network and describes a
   publish and subscribe procedures under the proposed architecture. It
   also describes future research issues required for enhanced pub/sub
   services in ICN-based vehicular network.

2. Pub/Sub Service Architecture for ICN-based Vehicular Network

2.1. Pub/Sub Applications

   In [KHEL19], VANET applications was classified into three main
   categories: safety applications, traffic information applications,
   and comfort applications. This document also classifies applications
   into three categories:

   o Safety Applications : It concerns lives of the drivers and the

   o Traffic Information Applications : It provides up-to-date traffic

   o Infotainment Applications : It aims to improve the drivers and
      the passengers comfort and provide an information

   Among these applications, safety applications and infotainment
   applications are suitable for pub/sub services because the intent of
   subscribers is important.

2.2. Pub/Sub Service Architecture

   For the proposed architecture, this document assumes the running
   environment of vehicular network. First, there are multiple
   brokers(rendezvous nodes) for wide service coverage. Second, each
   broker shares topic information with each other. For this purpose,
   brokers need synchronization protocol such as PSync. Third, A
   publisher/subscriber communicates with a closest broker.

Kim, et al.           Expires December 31, 2019               [Page 3]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

   Our proposed pub/sub service architecture uses immobile rendezvous
   nodes to decouple publishers and subscribers. The rendezvous nodes
   store and manage information about important events on the road. A
   publisher sends important event information, such as a car accident
   on the road, to the closest rendezvous node. Publishers and
   subscribers can be both vehicles and persons. A subscriber registers
   the closest rendezvous node and receives subscribed information. A
   rendezvous node store published event information, and synchronizes
   the stored information of other rendezvous node using a data sharing
   protocol. Therefore, subscribers only can subscribe to a rendezvous
   node and receive information from the rendezvous node. The
   subscriber does not need to have information about publishers and
   can obtain event data only by having the information on the
   rendezvous node. Publishers and subscribers only need FIB entry
   about the rendezvous node to send packets it. Thus, the routing of
   proposed architecture is very simple. In addition, the rendezvous
   node can process published event data to create useful information
   for subscribers.

      +-------------------+                 +-------------------+
      | Rendezvous Node-1 | <-------------> | Rendezvous Node-N |
      +-------------------+       Sync      +-------------------+
               ^                                       ^
               |Subscribe                      Publish |
               |                                       |
               |                                       |
         +-----------+                            +-----------+
         | Vehicle-1 |                            | Vehicle-m |
         +-----------+                            +-----------+


         Figure 1: Pub/Sub Service in ICN-based Vehicular Network

2.3. Name Structure

   Naming is the pinnacle of NDN that differentiates it from
   traditional networks. NDN names should be globally unique, secure,
   location-independent, and human-readable [BARI12]. Khelifi et al.
   analyzed existing naming solutions in the context of VANET [KHEL19].
   Wang et al. proposed a data naming structure for V2V traffic

Kim, et al.           Expires December 31, 2019               [Page 4]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

   information dissemination [WANG12]. However, this structure is for
   V2V communication. This document proposes a name structure for V2I
   communication by expanding that.

         |                                                       |
         | /RoutableName/AppName/DataType/GeoLocation/Timestamp  |
         |                                                       |
              Figure 2: Name Structure for Pub/Sub in ICN-VN

   o RoutableName : routing prefix toward rendezvous node

         Ex) /rendezvous

   o AppName : application name

         Ex) safety, infotainment, traffic

   o DataType : occurred event type

         Ex) alarm, advertisement, speed

   o GeoLocation : geolocation information

         Ex) /RoadID/Direction/ZoneNo

   o Timestamp : specific time (Optional)

         Ex) 20190721113000 (YYYYMMDDHHMMSS)

3. Pub/Sub Service Procedure

   This document describes publish and subscribe procedure using the
   safety applications.

3.1. Publish Procedure

   An example of publication is as follow;

   o There is an accident on the road.

Kim, et al.           Expires December 31, 2019               [Page 5]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

   o The vehicle or person is aware of an accident.

   o The publisher generates data names according to the proposed
      naming structure for publishing events.

   o The publisher creates an Interest packet with event information.
      (Use Application Parameter for NDN packet)

   o The publisher sends an Interest packet to the rendezvous node.

   o The rendezvous node receives an interest packet with published

   o The rendezvous node stores a received event.

      |                                                             |
      | /RN_prefix/safety/alarm/road1-north-zone12/now/car-accident |
      |                                                             |
                      Figure 3: Publish Name Example

3.2. Data Synchronization Procedure

   An example of Synchronization is as follow;

   o A publisher publishes the event at the nearest rendezvous node.

   o The rendezvous node stores published events.

   o The rendezvous node synchronizes the list of topics on which the
      change occurred with other rendezvous nodes. Specific methods
      require further study.

   o The rendezvous node uses a synchronized list of topics to
      communicate information to subscribers.

Kim, et al.           Expires December 31, 2019               [Page 6]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

3.3. Subscribe Procedure

   An example of subscription is as follow;

   o A subscriber(vehicle) generates name to obtain data.

   o A subscriber creates an Interest packet under the name structure
      and sends it to the rendezvous node.

   o The rendezvous node receives a subscription interest packet, and
      analyzes the name from an interest packet.

   o The rendezvous node searches its repository for data that a
      subscriber wants.

   o The rendezvous node generates a manifest based on the retrieved
      information and forwards it to the subscriber.

   o The subscriber requests rendezvous nodes, which store the real
      data based on the information from the received manifest.

   o Each rendezvous node creates data packets for the information and

   o A subscriber receives the data packet, and extracts information
      from it.

         |                                                       |
         |       /RN_prefix/safety/alarm/road1-north-zone12/     |
         |                                                       |
                      Figure 4: Subscribe Name Example

4. Open Research Challenges

   The proposed architecture in Section 3 described how pub/sub service
   over ICN operate. However, several research challenges remain open
   and still need to be addressed.  The list that need further study is
   as follows:

   o A study on the name structure to provide various vehicular
      network applications

Kim, et al.           Expires December 31, 2019               [Page 7]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

      The name structure may vary depending on the nature of
      applications in the vehicular network. For example, the name of
      navigation application may be preferable to express the origin
      and destination address in the name.

   o A study on subscriber certification for provision of premium
      pub/sub services

      In order to provide special services to some subscribers, the
      rendezvous node needs to perform subscriber authentication.
      Because ICN is content name communication, the rendezvous node
      should be a way to distinguish certified subscribers.

   o A study on efficient push mechanism for pub/sub service

      ICN is a pull-mode communication. A push-type communication
      method is required that allows instantaneous delivery to
      subscribers in occurrence of urgent event.

   o A study on the distributed rendezvous architecture for SPOF and
      service locality

       The distributed rendezvous node structure has advantages in terms
       of scalability. However, research is needed on how data is
       synchronized between multiple rendezvous nodes and how data
       residing on multiple rendezvous nodes is communicated to

5. IANA Considerations

   This memo includes no request to IANA.

6. Security Considerations

   This document does not define a new protocol (or protocol extension)
   or a particular mechanism, and therefore introduces no specific new
   security considerations. General security considerations for
   Information-Centric Networking are discussed in [RFC7945].

Kim, et al.           Expires December 31, 2019               [Page 8]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

7. References

7.1. Normative References

   [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
             and G. Boggia, "Information-Centric Networking: Evaluation
             and Security Considerations", RFC 7945, DOI
             10.17487/RFC7945, September 2016,

7.2. Informative References

   [BARI12] Md. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, B.
             Mathieu, "A survey of naming and routing in information-
             centric networks", IEEE Communications Magazine, vol. 49,
             no. 12, pp. 44-53, 2012.

   [TARA12] S. Tarkoma, "Publish/Subscribe Systems Design and
             Principles", Wiley, 2012.

   [KHEL19] H. Khelifi, S. Luo, B. Nour, H. Moungla, Y. Faheem, R.
             Hussain, A. Ksentini, " Named Data Networking in Vehicular
             Ad hoc Networks: State-of-the-Art and Challenges", IEEE
             Communications Surveys & Tutorials, 2019, < DOI:

   [WANG12] L. Wang, R. Wakikawa, R. Kuntz, R. Vuyyuru, and L. Zhang, "
             Data naming in vehicle-to-vehicle communications",
             INFOCOM2012, pp. 328-333, 2012.

   [WANG19] J. Wang, J. Liu, and N. Kato, "Networking and
             Communications in Autonomous Driving: A Survey", IEEE
             Communications Surveys & Tutorials, vol. 21, no. 2, pp.
             1243-1274, 2019.

8. Acknowledgments

   We thank all contributors, reviewers and the chairs for their
   valuable time in providing the comments and feedback, which has
   helped to improve this draft.

   This work was supported by the ICT R&D program of MSICT/IITP. [2017-
   0-00045, Hyper-connected Intelligent Infrastructure Technology

Kim, et al.           Expires December 31, 2019               [Page 9]

Internet-Draft        Pub/Sub Service in ICN-VN              July 2019

Authors' Addresses

   Haksuh Kim (editor)
   218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea
   Email: tuple@etri.re.kr

   Kangil Choi
   218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea
   Email: forerunner@etri.re.kr

   Heeyoung Jung
   218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea
   Email: hyjung@etri.re.kr

   Sunme Kim
   218 Gajeong-ro, Yuseung-Gu Daejeon 34129 Korea
   Email: kimsunme@etri.re.kr

Kim, et al.           Expires December 31, 2019              [Page 10]