Skip to main content

Problem Statement for the use of IP in some ITS scenarios
draft-petrescu-its-problem-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Alexandre Petrescu , Dapeng Liu
Last updated 2015-09-18
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-petrescu-its-problem-00
Network Working Group                                        A. Petrescu
Internet-Draft                                                 CEA, LIST
Intended status: Informational                                    D. Liu
Expires: March 21, 2016                               September 18, 2015

       Problem Statement for the use of IP in some ITS scenarios
                   draft-petrescu-its-problem-00.txt

Abstract

   abstract

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 March 21, 2016.

Copyright Notice

   Copyright (c) 2015 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.  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.

Petrescu & Liu           Expires March 21, 2016                 [Page 1]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  The Problem . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Discovery sub-Problem . . . . . . . . . . . . . . . . . . . .   4
   5.  Prefix Exchange sub-Problem . . . . . . . . . . . . . . . . .   4
   6.  Problem of Prefix Exchange with the First-hop
       Infrastructure  . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   5
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     12.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   intro

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   term

3.  The Problem

   The problem is how to establish IP communication paths between the
   computers embarked in two or more neighboring vehicles.

   Several use-cases in Intelligent Transportation Systems may involve
   the TCP/IP suite of protocols and benefit from Internet-style
   interactions.  Some applications require low-latency data exchanges
   between vehicles: Cooperative Adaptive Cruise Control, Platooning.
   For these applications, connecting the vehicles through long-range
   cellular networks brings too high latency.  It is necessary to
   connect vehicles directly, by using shorter-range communication
   technologies.

   A vehicle embarks several IP devices, forming a stable embedded
   network.  Typically Ethernet cables are run through a car, together

Petrescu & Liu           Expires March 21, 2016                 [Page 2]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

   with the CAN networks.  More and more computers in an automobile
   perform sensing and control tasks.  Typically one embedded Router is
   in charge of wireless communications outside the car, potentially via
   multiple technologies.

   The problem is how to establish IP communication paths between the
   computers embarked in two or more neighboring vehicles.  An
   instantiation of this problem is with the C-ACC use-case: a vehicle
   sends its coordinates to the vehicle behind it; this latter vehicle
   subsequently acts on braking, under certain circumstances.

                     Vehicle 1                             Vehicle 2
                                          e.g.
                                    o)) LTE D2D  ((o
                                    |   802.11p    |
                                    |     LiFi     |
                                    |              |
               +------+           +----+         +----+     +----------+
               |GPS PC|           | eR1|         | eR2|     |Braking PC|
               +------+           +----+         +----+     +----------+
                  |                 |              |              |
                  |                 |              |              |
                  |    Ethernet     |              |  Ethernet    |
                 ---------------------             ---------------------
                   2001:db8:1::/40                      2001:db8:2::/40

   The illustration above depicts two vehicles in close range.  Their
   respective embedded Routers can exchange data by using a short-range
   link-layer wireless technology such as LTE D2D, IEEE 802.11p, and
   others.

   The egress interfaces of eR1, eR2 and eRn form a single IP subnet.
   There is only one IP hop between eR1 and eR2.

   Within each vehicle there is at least one subnet, and there are
   potentially several distinct IP subnets in each vehicle.  In case
   there is one subnet in each vehicle, the IP hop count between one IP
   device in one vehicle and the IP device in another vehicle is maximum
   3: 1 IP hop in each vehicle and 1 IP hop between the vehicles.

   As an application example: the "GPS PC" in one vehicle sends IP
   datagrams containing its coordinates to the Braking PC in the other
   vehicle, controling braking.  The IP datagrams are sent through the
   respective embedded Routers.

Petrescu & Liu           Expires March 21, 2016                 [Page 3]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

   In order for GPS PC to reach Braking PC it is necessary that the two
   embedded Routers have forwarding information about their respective
   subnets: eR1 must learn that prefix 2001:db8:2::/40 is reachable
   through eR2, and vice-versa.  It is thus necessary that they exchange
   routing information.  Otherwise, the GPS PC and Braking PC can not
   reach one another.

   The problem is divided in a discovery sub-problem (how eRs discover
   each other) and a prefix exchange sub-problem (how eRs exchange
   routing information).

4.  Discovery sub-Problem

   Various information needs to be discovered to set up the IP
   communication between the vehicles.  The information that needs to be
   discovered by the eR includes both link layer, MAC layer and IP layer
   information.

   For link layer information, the wireless link layer parameters need
   to be obtained.  For example, power of emmission information which
   can be used to determine the distance of the vehicles.

   For MAC layer information, the MAC address information of the eR need
   to be discovered.

   For IP layer information, in the above figure, eR1 needs to discover
   the IP address and IP prefix of eR2 and eR2 also needs to discover
   the IP address and IP prefix of eR1.  The multicast related
   information may also need to be discovered.

   Service related information sometimes is also needed.  For example,
   the eR on the vehicle need to indicate that it wants to discover
   other eR on other vehicles that can provides V2V communications.

5.  Prefix Exchange sub-Problem

   As mentioned earlier, there is a problem in establishing single-hop
   forwarding between two neighboring vehicles.

   There are two modes of operating a V2V topology:

   o  peer-to-peer operation: one vehicle connects with another vehicle
      and exchanges information in a equipotential basis.

   o  client-server operation: one vehicle connects to another vehicle
      which is considered to master several other vehicles.  The former
      may request an allocation of prefixes, and may use the latter as a

Petrescu & Liu           Expires March 21, 2016                 [Page 4]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

      default router.  This mode of operation is not considered in this
      document.

   The peer-to-peer operation of a V2V topology is an important part in
   ITS applications such as C-ACC and Platooning.  This operation mode
   allows each vehicle to send and receive application data
   (coordinates, speed) as IP packets, without the need of assistance
   from fixed infrastructure.  Each vehicle is pre-equipped with a
   unique IPv6 prefix and each computer in a vehicle is identified by a
   unique IPv6 address.

   In order for one computer in one vehicle to reach another computer in
   another vehicle it is necessary that the embedded routers in each
   vehicle learn the IPv6 prefix (and/or the IPv6 address) of the other
   vehicles.  A prefix-exchange mechanism is needed, otherwise the IP
   communication can not be established.

   After each vehicle has informed the other vehicles nearby about its
   prefix, the forwarding tables of each vehicle must be updated to
   contain the tuple [prefix; IP address] of each other vehicles.  The
   updating must deal with situations when vehicles leave the network,
   otherwise numerous ICMP Destination Unreachable messages may occur on
   the inter-vehicle media.

   The problem is thus how to realize this prefix exchange.

6.  Problem of Prefix Exchange with the First-hop Infrastructure

   The Problem of Prefix Exchange with the First-hop Infrastructure

7.  Conclusions

   conclusions

8.  Security Considerations

   security

9.  IANA Considerations

   iana

10.  Contributors

   contributors

Petrescu & Liu           Expires March 21, 2016                 [Page 5]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

11.  Acknowledgements

   acks

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

12.2.  Informative References

   [I-D.liu-its-scenario]
              Liu, D., "Scenario of Intelligent Transportation System",
              draft-liu-its-scenario-00 (work in progress), March 2015.

   [I-D.petrescu-ipv6-over-80211p]
              Petrescu, A., Pfister, P., Benamar, N., and T.
              Leinmueller, "Transmission of IPv6 Packets over IEEE
              802.11p Networks", draft-petrescu-ipv6-over-80211p-02
              (work in progress), June 2014.

Appendix A.  ChangeLog

   The changes are listed in reverse chronological order, most recent
   changes appearing at the top of the list.

   From nil to draft-petrescu-its-problem-00.xml:

   o  initial version

Authors' Addresses

   Alexandre Petrescu
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette , Ile-de-France   91190
   France

   Phone: +33169089223
   Email: Alexandre.Petrescu@cea.fr

Petrescu & Liu           Expires March 21, 2016                 [Page 6]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015

   Dapeng Liu
   Beijing , Beijing   100022
   China

   Phone: +86-13911788933
   Email: maxpassion@gmail.com

Petrescu & Liu           Expires March 21, 2016                 [Page 7]