Network Working Group Z. Yan
Internet-Draft CNNIC
Intended status: Standards Track J. Lee
Expires: October 28, 2016 Sangmyung University
April 26, 2016
Requirements for Data Aggregation in Intelligent Transportation Systems
draft-yan-its-aggregation-00.txt
Abstract
Considering the large-scale but small-sized information exchange in
the vehicular information network, this draft aims to outline the
requirements to support the data aggregation in ITS, in order to make
the information retrieval and dissemination more efficient.
Requirements Language
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.
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 October 28, 2016.
Copyright Notice
Copyright (c) 2016 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
Yan & Lee Expires October 28, 2016 [Page 1]
Internet-Draft ITS Data Aggregation April 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Data naming . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Aggregation and Segregation . . . . . . . . . . . . . . . . . 4
5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security considerations . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
A vehicular information network aims to implement a myriad of
applications related to vehicles, traffic information, drivers,
passengers and pedestrians. Then a flexible data integration and
segregation architecture in ITS should be designed to support the
exchange of a huge number of heterogeneous information objects in an
efficient and scalable manner.
The main case for data integration we discuss in this draft is:
multiple requested information objects originated from different
sources share some or all hops on the transmission paths.
This draft outlines the general requirements for data integration
from several key aspects described in the following sections. But
this draft does not specify the requirements in special communication
cases, such as V2X, I2X, V2I2V and so on, the particular requirements
under these special cases will be analyzed in the future.
2. Data naming
Generally, location and data type are potentially critical indexes
for data retrieval in ITS. Also, for configuration, management and
maintenance, devices may need to be accessed directly by a device-
specific identifier. Therefore, the naming scheme needs to
incorporate location, data type and device information, in order to
be scalable to support trillions of information objects.
Yan & Lee Expires October 28, 2016 [Page 2]
Internet-Draft ITS Data Aggregation April 2016
o Location-based: A critical organizing factor for vehicular sensing
data, especially that which is to be widely shared and fused, is
the location to which it applies.
o Device-based: in some cases, the data produced by the specialized
vehicle or infrastructure device may be requested.
o Type-based: another critical element for naming is the type of
data. Namespaces will also incorporate data type designators,
such as speed, emission, trajectory and so on.
Then to better support the data aggregation, the name included in the
data request message should be designed as:
/Producer1:Producer2:...ProducerX/ Location1:Location2:...LocationY/
Type1:Type2:...TypeZ/ end/
[The format of the content name used in this draft only identifies
the logic of the name structure.]
The parsing logic is: the data objects with Type (1,2,...Z) created
from Location (1,2,...Y) by Producer(1,2,...X) are requested
(producer here identifies the device).
For example, if a vehicle wants to get the traffic information in
Street-1, Street-2 and Street-3 (without specifying the data
producer/device), a name of the data may be:
//Street-1:Street-2:Street-3/traffic/end/
In most cases, the requester only cares about what information it
wants, but does not exactly know the information source. In other
words, it is possible that the requester can not specify the
destination address of the request message. Then a service discovery
scheme, which may make use of the information in the data name as the
index, should be designed in ITS.
3. Routing
Because ITS WG aims to apply the IP technologies to the ITS, then the
routing table and routing scope should be adaptively designed based
on the TCP/IP stack.
(1) Routing table
To support different kinds of ITS communication and different
aggregation policies, in the routing table of the router in the RSU
and the edge router in the vehicle, there are two types of entries at
Yan & Lee Expires October 28, 2016 [Page 3]
Internet-Draft ITS Data Aggregation April 2016
least should be maintained: geo-location based and IP based routing
entries. The former one is based on the geographical location
information of the routers, which is established based on the
coordinate information exchanged between routers or through
centralized configuration. While the latter one is established based
on the normal routing protocols in the TCP/IP network.
2) Routing scope
As in the IP network, the routing scopes also mainly include
multicast and unicast for different communication cases. Then
different routers may be configured to different multicast groups (we
mainly consider the IPv6 scenario). And one router may also belong
to multiple different multicast groups. Although the data
aggregation acts like the multicast to converge the communications,
it is the packet-level optimization and can be applied in both
unicast and multicast cases.
4. Aggregation and Segregation
Based on the naming labels and the routing information, the router
(especially the router in RSU) will decide if the request packet
should be split over its multiple outgoing network interfaces.
Specially, the router should determine if the outgoing network
interfaces for the multiple data elements are same: if so, direct
forwarding is made based on the matched entry in the routing table;
otherwise, the router has to split the original request packet into
multiple new request packets according to their different outgoing
network interfaces and send them to different next-hop routers
accordingly with the newly generated names. Similarly, if the data
is sent back through the reverse path, they can be aggregated.
As illustrated above, based on the routing table, the router decides
if the request message should be split over their related outgoing
network interfaces. However, some conditions (e.g., traffic jam or
traffic accident information should be learnt by the traffic
administrator as soon as possible) in the vehicular information
network change quickly and quite frequently. As a result, the timer
value used for the data aggregation should be carefully set.
Different policies for setting the timer value can be used and such
policies need to be indicated by the upper level aggregator (e.g.,
previous-hop router) in the request message. Generally, some of the
request messages should be handled on a first-in-first-out basis such
as in the emergency case; while, some of the request messages can
only be processed until all the required information is collected
(e.g., in the case where we retrieve the overall traffic condition
information). The upper level aggregator can indicate the timer
value to the lower level ones (e.g., the next-hop router) in the
Yan & Lee Expires October 28, 2016 [Page 4]
Internet-Draft ITS Data Aggregation April 2016
request message. But the protocol to support this notification and
policy decision is beyond the scope of this document.
Another key element to support the aggregation and segregation
procedure is a pending table which maintains the original data name
and the newly extracted data names. This table is mainly maintained
by the branching node on the communication path, who conducts the
segregation operation. In this way, the reverse operation (data
aggregation) can be executed.
+---+
| V3|-----\
+---+ |
|
+-----+ //Street-3/traffic/end/
|RSU3 |------------------\
+-----+ | //Street-3:Street-4/traffic/end/
+-----+ +-----+
|RSU2 |-----------------|RSU1 |
+-----+ +-----+
+-----+ | |
|RSU4 |------------------/ |
+-----+ //Street-4/traffic/end/ |
| +---+
+---+ | |V1 |
|V4 |-----/ +---+
+---+ //Street-3:Street-4/traffic/end/
Figure 1: Operation of the aggregation and segregation
An example of the aggregation and segregation is shown in Figure 1.
In this figure, Vehicle-1(V1), Vehicle-3(V3), and Vehicle-4(V4)
connect to the Internet through RSU1, RSU3 and RSU4 respectively.
When V1 wants to know the current traffic states of two blocks served
by RSU3 and RSU4 to select a better path between them, it sends out
the data request message with the data name //Street-3:Street-
4/traffic/end/. When RSU1 receives this request message, it directly
sends the message to RSU2 because the next hop to request all the
data in this message comes from RSU2. But when RSU2 receives this
message, it will recognize that the data should be requested from two
different outgoing interfaces directing to RSU3 and RSU4
respectively. Then two new names are generated through the
information extraction from the original name. Specially, the data
request for the new name //Street-3/traffic/end/ is sent to RSU3 and
the data request for the new name //Street-4/traffic/end/ is sent to
RSU4.
Yan & Lee Expires October 28, 2016 [Page 5]
Internet-Draft ITS Data Aggregation April 2016
After retrieval of the data corresponding to the two data request
messages, the aggregation is conducted through the reverse path based
on the recorded states.
5. Caching
Cache is necessary to reduce unnecessary data transmission, thus
improving scalability in ITS. When the router receives a data
request, it will check its cache firstly. Based on the cache hit
result, the request may be segregated when it is possible.
Generally, two different cache tables should be maintained:
o Time-sensitive data cache: some data in the ITS is very time-
sensitive, such as the traffic jam condition. Then the timer
should be strictly inherited from the related response message for
the particular data.
o Time-insensitive data cache: for other time-insensitive data, such
as the geo-map information, a default timer with long life-time
should be used to serve the following requests efficiently.
6. Other issues
TBD
7. Security considerations
TBD
8. 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>.
Authors' Addresses
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing 100190
China
EMail: yan@cnnic.cn
Yan & Lee Expires October 28, 2016 [Page 6]
Internet-Draft ITS Data Aggregation April 2016
Jong-Hyouk Lee
Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu
Cheonan
Republic of Korea
EMail: jonghyouk@smu.ac.kr
Yan & Lee Expires October 28, 2016 [Page 7]