Network Working Group                                          K. Uehara
Internet-Draft                                                   M. Sato
Intended status: Informational                                Keio Univ.
Expires: May 12, 2011                                      K. Shima, Ed.
                                                                  IIJ II
                                                        November 8, 2010


  The Message Format for Decentralized Probe Applications for Vehicles
           draft-uehara-dtnrg-decentralized-probe-message-00

Abstract

   (This document is a description of the decentralized viechle to
   viechle probe mechanism currently being prototyped.  The main purpose
   of disclosing this -00 document is to introduce the application idea
   and start discussion within the DTNRG.  Because of this, the current
   mechanism described in this docment does not conform to the protocols
   defined in the DTNRG at this moment.  The mechanism should be updated
   based on the discussion in this group.)

   This document describes the application message format used for the
   decentralized probe system for vehicles.  The probe system exchanges
   the application messages between vehicles using the transport
   protocol defined in the separate specification.

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 http://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 12, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Uehara, et al.            Expires May 12, 2011                  [Page 1]


Internet-Draft                 DCP Message                 November 2010


   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.  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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Application Behavior  . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Message Generation/Storing/Forwarding . . . . . . . . . . . 3
     2.2.  Dissemination Strategy  . . . . . . . . . . . . . . . . . . 4
   3.  Message Format  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Basic Information Part  . . . . . . . . . . . . . . . . . . 5
     3.2.  Dissamination Parameters Part . . . . . . . . . . . . . . . 6
     3.3.  Security Part . . . . . . . . . . . . . . . . . . . . . . . 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   5.  Protocol Constants  . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Uehara, et al.            Expires May 12, 2011                  [Page 2]


Internet-Draft                 DCP Message                 November 2010


1.  Introduction

   Thanks to the the advance of the Internet and the wireless
   communication technology, it becomes possible to equip communication
   mechanisms for vehicles for various purposes, such as for safety
   applications, entertainment applications, and so on.  Recently,
   approaches utilizing the DTN (Delay Tolerant Network) technology for
   inter-vehicle communication are attracting people from both academy
   and industry.  One of the application of the approaches is
   decentralized probe system for traffic information.  It is considered
   that by combining the existing centralized approach for traffic
   monitoring and the proposed decentralized approach, more detailed
   information exchange is possible and wider area can be covered.  This
   document proposes a standard message format for the traffic
   information dissemination application, and proposes a reference
   message dissemination strategy.


2.  Application Behavior

2.1.  Message Generation/Storing/Forwarding

   The mechanism described in this document proposes a decentralized
   approach of message exchange for car traffic monitoring.  The similar
   purpose is of course provided by the ITS (Intelligent Transport
   System) framework with the centralized approach.  However, since such
   systems require a large amount of investment for the road side units
   and their management system, they are usually deployed only on
   highways and main lines of urban areas.  The decentralized approach
   is one way to extend the area of the ITS service coverage, because
   the decentralized mechanism does not need to build any road side
   units, and each vehicle autonomously organizes the transport
   information network.

   This document defines a general format of the message exchanged in
   the decentralized approach.  Each vehicle monitors its activity,
   creates a message that indicates the activity, and distribute the
   message to other vehicles nearby based on the dissemination strategy
   defined in Section 2.2.  A vehicle that receives messages from other
   vehicles stores the messages in its own message storage, and
   distribute again using the dissemination strategy specified in the
   message body.

   For example, in the traffic jam information distribution case, a
   vehicle periodically monitors its speed and detects a traffic jam
   based on a traffic jam detection algorithm.  Once a jam is detected,
   the vehicle creates a message with an application identifier that
   indicates it is a traffic jam detection application, and distributes



Uehara, et al.            Expires May 12, 2011                  [Page 3]


Internet-Draft                 DCP Message                 November 2010


   the message.  Every message includes the time when the message is
   generated, the location where the message is created, the valid
   lifetime of the message, and the algorithm how/where to distribute
   the message.  The transport mechanism of the messages is defined in
   other document [decentralized-probe-transport].

   To avoid a malicious vehicle to inject faked messages, applications
   can sign the messages based on the identifier of the vehicle if
   necessary.  If the message validation procedure fails when a vehicle
   receives a message, the message is discarded.

2.2.  Dissemination Strategy

   The dissemination strategy determines how to distribute a message.
   This document only defines a simple round dissemination strategy.
   The more complicated strategy is also possible and will be defined in
   separate documents.

   The round-shape dissemination strategy specifies the destination
   location (with latitude/longitude values) and the distribution
   radius.

   If a vehicle receives a message (regardless of the value of the
   dissemination identifier), it first looks up the same message in its
   message storage.  A message can be identified by a node identifier,
   application identifier, and application sequence number.  If the same
   message has already been stored in the storage, the received message
   is just ignored and discarded.  If the message is not found in the
   storage, then the vehicle stores the received message.

   A vehicle periodically checks its message storage to find messages
   which lifetime are expired.  Any messages with expired lifetime are
   marked as deleted and removed when the amount of the free space of
   the storage becomes low.

   A message will not be re-distributed until the dissemination conceal
   period has passed since the time when the message was received or re-
   distributed previously to avoid too frequent message exchange.

   In the round-shape dissemination strategy, a vehicle compares its
   current location and the region specified in the dissemination
   parameter fields in the message.  If the current location is covered
   by the region specified, the vehicle distribute the message to other
   vehicles nearby.

   If the vehicle is out of the dissemination target region, the message
   is not distributed and kept in the storage.




Uehara, et al.            Expires May 12, 2011                  [Page 4]


Internet-Draft                 DCP Message                 November 2010


3.  Message Format

   The application message consists of three parts.  Each part is
   concatenated in the order listed below and passed to the packet
   sender module.  The detailed description of the packet sender and
   receiver are found in [decentralized-probe-transport].

   The first part contains the basic information of the application
   message.  The second part contains the parameters for message
   dissemination strategy.  The final part contains the security
   information.

3.1.  Basic Information Part

   Figure 1 shows the basic information part of the message.

    0             7 8            15 16           23 24           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |                  Reserved                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        Node Identifier                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Application Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Application Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Expiration Time                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message Generation Time                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Message Generated Latitude                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                 Message Generation Longitude                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Message Preference                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Uehara, et al.            Expires May 12, 2011                  [Page 5]


Internet-Draft                 DCP Message                 November 2010


                     Figure 1: Basic Information Part

   Version:  1

       The version number of the message format.  Currently version 1 is
       the only version defined.

   Reserved:  Reserved for future use

       The field is reserved to support future extension.  The sender of
       the message should fill 0 in this field and the receiver of the
       message must ignore the field.

   Node Identifier:  The unique identifier of the node

   Application Identifier:  The unique identifier of the application

   Application Sequence Number:  The unique number of the message
       generated within the node and application specified by the
       previous two fields

   Expiration Time:  The message expiration time in second from the
       epoch

   Message Generation Time:  The time from the epoch when the message
       was generated

   Message Generation Latitude/Longitude:  The location information of
       the message where it was generated

       The values are represented in IEEE 754 double precision number
       format.  The WGS 84 is used as a geodetic system.

   Message Preference:  A 32-bit ordered value indicating the preference
       within the application specified by the Application Identifier
       field.

3.2.  Dissamination Parameters Part

   Figure 2 shows the dissemination part of the message.











Uehara, et al.            Expires May 12, 2011                  [Page 6]


Internet-Draft                 DCP Message                 November 2010


    0             7 8            15 16           23 24           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Dissemination Strategy Identifier               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Dissemination Conceal Period                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                 Dissemination Target Latitude                 +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                Dissemination Target Longitude                 +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Dissemination Target Radius                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 2: Dissemination Parameter Part

   Dissemination Strategy Identifier:  The dissemination strategy
       identifier specified in Section 2.2

   Dissemination Conceal Period:  The time in second to stay in the node
       without being disseminated

   Dissemination Target Latitude/Longitude:  The final target area of
       the message to be delivered

       The values are represented in IEEE 754 double precision number
       format.  The WGS 84 is used as a geodetic system.

   Dissemination Target Radius:  The radius in units of meter that
       indicates the size of the final target area

3.3.  Security Part

   Figure 3 shows the security part of the message.

    0             7 8            15 16           23 24           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                       Message Signature                       :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Uehara, et al.            Expires May 12, 2011                  [Page 7]


Internet-Draft                 DCP Message                 November 2010


                          Figure 3: Security Part

   Message Signature:  PKCS #7 based message signature

       The message contents may be signed by the message creater using
       creater's private key associated with the node identifier of the
       creater.  The name space of the common name field is defined
       hierarchically (TBD) and its character code is utf-8.  The key
       length and the algorithm is RSA2048.


4.  Security Considerations

   Sender verification and message integrity are provided by the upper
   layer mechanism, by using PKCS#7 based mechanism.


5.  Protocol Constants

      General

         DCP_VERSION: 1

      Application identifiers

         DCP_APP_ID_RESERVED: 0

         DCP_APP_ID_TRAFFICJAM: 1

      Dissemination strategy identifiers

         DCP_DISS_ID_RESERVED: 0

         DCP_DISS_ID_ROUNDSHAPE: 1


6.  Normative References

   [decentralized-probe-transport]
              Uehara, K., Imaike, M., and K. Shima, Ed., "The Transport
              Protocol for Decentralized Probe Applications for
              Vehicles", 2010.









Uehara, et al.            Expires May 12, 2011                  [Page 8]


Internet-Draft                 DCP Message                 November 2010


Authors' Addresses

   Keisuke Uehara
   Keio University
   5233 Endo
   Fujisawa-shi, Kanagawa  252-8520
   Japan

   Email: kei@wide.ad.jp


   Masaaki Sato
   Keio University
   5233 Endo
   Fujisawa-shi, Kanagawa  252-8520
   Japan

   Email: saikawa@sfc.wide.ad.jp


   Keiichi Shima (editor)
   IIJ Innovation Institute Inc.
   1-105 Kanda-Jinbocho
   Chiyoda-ku, Tokyo  101-0051
   Japan

   Email: keiichi@iijlab.net
























Uehara, et al.            Expires May 12, 2011                  [Page 9]