Internet DRAFT - draft-da-ipwave-advanced-features
draft-da-ipwave-advanced-features
Network Working Group Bin Da
Internet Draft Huawei
Intended status: Informational Antonio Iera
Expires: April 28, 2018 Claudia Campolo
University of Reggio Calabria
October 28, 2017
Advanced Features for Vehicular Networks: Grouping and Socialization
draft-da-ipwave-advanced-features-01.txt
Abstract
For future vehicular networks, some advanced features might be needed
to facilitate use cases as platooning, proximity service awareness,
autonomous driving and so forth. Thus, this draft intends to present
two functions, known as vehicular grouping and socialization, for
enabling some future-oriented use cases. These two functions could be
built upon cross-layer identifiers, such as MAC, IP, and ID, which
also have potential to formulate more value-added services for future
vehicular networks.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Da Expires April 28, 2018 [Page 1]
Internet-Draft Vehicular Advanced Features October 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 28, 2018.
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
1. Introduction ................................................ 3
2. Requirements of Future Use Cases for Vehicular Networks ..... 3
2.1. Grouping Use Case ...................................... 3
2.1.1. Platooning ........................................ 3
2.1.2. Requirements ...................................... 4
2.1.3. More Possibilities ................................ 4
2.2. Socialization Use Case ................................. 5
2.2.1. Fully Socialized Vehicular Networks ............... 5
2.2.2. Requirements ...................................... 6
3. Grouping for Vehicular Networks ............................. 6
3.1. Grouping Sub-functions ................................. 6
3.2. Grouping via Cross-Layer Identifiers ................... 7
3.2.1. MAC as Identifier ................................. 7
3.2.2. IP as Identifier .................................. 7
3.2.3. Application-Level Identifier ...................... 7
3.2.4. Independent Identifier Layer ...................... 7
3.2.5. An Overview of Cross-Layer Identifiers for Grouping.8
3.3. Grouping Management .................................... 8
3.3.1. Dynamic Grouping Management ....................... 9
3.3.2. Pseudonymity and Batch Update of Identifiers ...... 9
4. Socialization for Vehicular Networks ........................10
4.1. Socialization Sub-functions ........................... 10
4.2. Socialization via Identifiers ......................... 11
4.3. Socialized Services ................................... 12
5. Security Considerations .................................... 13
Da Expires April 28, 2018 [Page 2]
Internet-Draft Vehicular Advanced Features October 2017
6. References ................................................. 13
6.1. Normative References .................................. 13
6.2. Informative References ................................ 14
Authors' Addresses ............................................ 15
1. Introduction
Nowadays, vehicular networks are under active development by
different standard organizations (e.g., IEEE, IETF, ITU, ISO, 3GPP,
ETSI, etc.), many industry alliances (e.g., Car2Car CC, OCF
Automotive, 5GAA), and research institutes (e.g., NTU-SMP). As is
well known, future networks demand high-throughput or massive low
data-rate connections, low latency or deterministic delay, high
mobility support with seamless communications, and inherent security
built-in networks. Thus, vehicular networks become a typical use case
satisfying all these future-oriented demands, and formulate one key
scenario for future networks.
IP address plays an important role, as identifiers for end-to-end
communications, in network layer for packet delivery, while other
types of identifiers in cross-layers also function independently
[Wet2010]. For achieving advanced features for future vehicular
networks, all these identifiers could be properly grouped or even
socialized to facilitate platooning, proximity service awareness,
autonomous driving, and so forth. The following sections of this
draft will elaborate vehicular grouping and socialization functions
in more detail, for potential advanced features of vehicular networks,
which may serve as partial requirement inputs for IETF IPWAVE WG with
further investigations on more future-oriented features.
2. Requirements of Future Use Cases for Vehicular Networks
In this section, two typical scenarios for elaborating the functions
of grouping and socialization are provided. Note that, for vehicular
networks, there might exist more use cases to be developed.
2.1. Grouping Use Case
2.1.1. Platooning
One typical use case for orderly grouping is platooning, which has
been described by some SDOs such as in [TR22.886]. Specifically,
Platooning is a cooperative driving pattern for a group of vehicles
Da Expires April 28, 2018 [Page 3]
Internet-Draft Vehicular Advanced Features October 2017
which follow one another and maintain a small and nearly constant
distance among them. Figure 1 illustrates this case on one road land
while few cars are grouped together for platooning driving.
+++++++++RSU+++++++++++++++++++++++++++RSU+++++++++
LANE1 <<<Car1-Car2-Car3 [Platoon1]
LANE2
- - - - - - - - - - - - - - - - - - - - - - - - - -
LANE3
LANE4 [Platoon2] Car6-Car5-Car4>>>
+++++++++RSU+++++++++++++++++++++++++++RSU+++++++++
Figure 1: Example of Platooning
2.1.2. Requirements of Grouping
As shown in platooning [Jia2016], there exist some unique
requirements, for instance: Initial platooning formulation; Dynamic
joining or dismissing; Inter-vehicle distance control; Speed control;
Security alerting. To realize these requirements, an integrated
solution should be developed, which may exceed the scope of this
draft focusing on requirements of advanced features for future
networks. In particular, part of these platooning requirements will
be discussed in Section III, with the discussion of dynamic grouping
using cross-layer identifiers.
2.1.3. More Possibilities
In a smaller scale, the grouping normally happens among vehicles in
tandem (as in above platooning case), or could be possibly operated
among RSUs (Road-Side Units) and vehicles in parallel lanes towards
the same driving direction. However, this case is much more dynamic
and complicated than the former one, for which, we think, grouping in
small scale cannot assume this function and thus a further discussion
on socialization will be elaborated.
Da Expires April 28, 2018 [Page 4]
Internet-Draft Vehicular Advanced Features October 2017
2.2. Socialization Use Case
2.2.1. Fully Socialized Vehicular Networks
The Thing-to-Thing socialization was initially proposed as SIoT
(Social IoT) in [Atz2012], which serves as a paradigm to describe the
relationships among heterogeneous IoT terminals.
More specifically, in terms of vehicular networks, the focused
entities are different types of vehicles (e.g., sedan, ambulance,
police wagon, etc.) on the road, which generally have high mobility
and have frequent interconnections with surrounding vehicles,
infrastructures (e.g., traffic lights, monitors, road-side sensors,
etc.), pedestrians with handheld devices, UAVs, and road-side service
points (e.g., gas station, restaurants). Based on this observation,
there exists a potential for future vehicles to setup a variety of
relationships with all the surrounding terminals with communications
capabilities, for broader value-added functions. Figure 2 shows one
possible scenario regarding this socialization among heterogeneous
terminals. One more specific embodiment is also provided in [Far2015].
|) |^^^^^^^^^^| BS1
|) |Restaurant|
| | | P1 P2 P3
+++++++++++RSU+++++++++++++++++++++++++++RSU+++++++++++
LANE1 <<<Car2
LANE2 <<<Car1
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
LANE3 Car5>>> Car3>>>
LANE4 Car4>>>
+++++++++++RSU+++++++++++++++++++++++++++RSU+++++++++++
| | P4 P5 |
BS2 |Gas Station| (| BS3
|___________| (|
Figure 2: Example of Socialized Environments for Vehicular Networks
Da Expires April 28, 2018 [Page 5]
Internet-Draft Vehicular Advanced Features October 2017
2.2.2. Requirements of Socialization
To properly model the social relationships among vehicles and
surrounding fixed or mobile terminals, some researches have been
carried out recently [Ala2015] and more functions need to be explored
as well [Atz2012]. Among which, a lot of relevant functions should be
developed such as: relationship management (establish, update,
dismiss, etc.), relation-based services (proximity, data delivery,
etc.), mapping, lifecycle, access control and so forth.
3. Grouping for Vehicular Networks
This section is aimed to elaborate the grouping and its sub-functions,
along with some key issues regarding to identifier-based dynamic
grouping method. Some lower layer technical details (e.g., PHY layer)
and specific upper layer implementations are currently beyond the
scope of this draft.
3.1. Grouping Sub-functions
Grouping is not a trivial function, which should include multiple
sub-functions, which are listed below:
- Group establishment: This could be carried out in both distributed
or centralized manner, while one group head (e.g., Platoon head car)
can take in charge of grouping, or alternatively, one central control
node is responsible for grouping (RSU, or BS).
- Group head selection: In distributed manner, there should be a head
car in one group who manages the group proactively. Thus, this head
car should be selected at the beginning.
- Group member management (join or dismiss): Subsequent cars can join
an existing group, or dismiss from the group.
- Group head delegation: With distributed grouping, the head may
leave the group at certain moment. Thus, it should delegate its role
to another member in the group.
- Group status maintenance: Dynamic joining or dismissing of member
cars should be reflected and group status information should be
exchanged as well. This may contain more information such as average
speed, driving direction, fuel consumption, etc.
Da Expires April 28, 2018 [Page 6]
Internet-Draft Vehicular Advanced Features October 2017
All the above functions are demanded for realizing proper grouping in
vehicular networks. This draft focuses on networking identifiers for
grouping, while other aspects are briefly discussed for future
investigations.
3.2. Grouping via Cross-Layer Identifiers
In above listed functions of grouping, there must have certain type
of identifiers to be used for labeling group members and make
associated management.
3.2.1. MAC as Identifier
The MAC address (48 bits) is a typical identifier for grouping at MAC
layer, while one typical use case is Bluetooth cluster (one Master
with several Slaves, being associated by MAC addressed in a group).
3.2.2. IP as Identifier
The IP address is used at network layer for packet delivery, which
could be locally valid or globally reachable. Both IPv4 and IPv6 can
be used for identifying communications endpoints at network layer, so
as to function as grouping identifiers. IP over WAVE is well studied
in [Ces2013].
3.2.3. Application-Level Identifier
As proposed in [Wet2010], a set of dedicated application-level
identifiers are formulated for vehicular networks. These identifiers
have a IPv4-like length, which could be extended further in a IPv6-
like manner to better uniquely identify objects in a global scale.
3.2.4. Independent Identifier Layer
Traditionally, IP address assumes an overloaded semantics, which
serves both as endpoint identifier and routing locator
[RFC6830][RFC7401]. Thus, many ILS (Identifier/Locator Split) schemes
have been studied in the past decades, for the purpose of future
network evolution [Fen2017]. Based on the same principle, it is
possible to have an independent identifier layer above IP layer and
below application layer, to serve for the intention of endpoints'
communications or other purposes. This ILS paradigm also supports
native mobility of moving nodes regardless of locator changes
[Ces2015], so as to support vehicle mobility.
It is worth noting that vehicular networks normally require to
uniquely identify individual vehicles, known as VID (Vehicle ID).
Da Expires April 28, 2018 [Page 7]
Internet-Draft Vehicular Advanced Features October 2017
Based on previous descriptions, this VID could be derived from MAC
address or other types of identifiers, as suggested in ETSI or IEEE.
However, it might formulate VID in the independent identifier layer
proposed here.
3.2.5. An Overview of Cross-Layer Identifiers for Grouping
Collectively, the following Figure 3 shows all potential layered
identifiers for grouping.
+---------------------------------+
| Application Layer Identifier |
+---------------------------------+
| TCP/UDP for Transport Layer |
+---------------------------------+
| Independent Identifier Layer | --> Vehicle ID
+---------------------------------+
| Internet Protocol Identifier |
+---------------------------------+
| Data-Link Layer MAC Identifier |
+---------------------------------+
| Physical Layer |
+---------------------------------+
Figure 3: An Overview of Cross-Layer Identifiers for Grouping
3.3. Grouping Management
Due to the nature of high mobility and desired pseudonymity for
privacy protection, grouping in vehicular networks has many
challenges ahead [Pet2015]. This sub-section discusses two important
aspects on grouping management, which should be of importance for
further studies.
Da Expires April 28, 2018 [Page 8]
Internet-Draft Vehicular Advanced Features October 2017
3.3.1. Dynamic Grouping Management
As described in Section 3.1, there exist few sub-functions for
appropriately managing grouping, while the highly dynamic nature of
vehicle networks requires all the relevant functions to be
implemented quickly whenever a grouping event occurs.
In a distributed manner, the group head should be promptly aware of
any change in its group. Such as in platooning case, the group head
should control overall speed of all group member with their relative
distance between each other. Additionally, the group head should
manage the change of members (joining or dismissing), and delegate
its role to another vehicle if it cannot serve as the group head any
more.
In a centralized manner, one central controller/node should manage
the formation of group and member changes.
3.3.2. Pseudonymity and Batch Update of Identifiers
The pseudonymity is a prominent feature that should be well
considered in future IoT networks in general, for protecting any
specific moving node from being tracked, so as to achieve location
privacy with other associated private and sensitive information.
Particularly, under the circumstance of vehicular networks,
pseudonymity requires frequent updates of communications identifiers
(e.g., MAC, or IP address). This also presents a challenge for
grouping, which may be built upon multiple cross-layer identifiers.
Different layers utilize their respective identifiers to label
vehicles, which may result in dynamically changing higher-layer
identifiers dependent on varying lower-layer identifiers. For
instance, IP addresses may be adopted by a central node to maintain a
group of vehicles, while these IP addresses are associated with
lower-layer MAC addresses. When MAC addresses are updated, the
corresponding IP addresses may need to be modified as well.
One possible solution is that, using persistent VID (Vehicle ID) that
may reside on the independent identifier layer (or defined in other
layers) to build a vehicular group, and further make a dynamic
binding between VIDs and underlying identifiers (e.g., IP, or MAC).
In such case, the paradigm of ILS could be well suited, once the VIDs
are not often exposed in the networks with proper protection.
Da Expires April 28, 2018 [Page 9]
Internet-Draft Vehicular Advanced Features October 2017
4. Socialization for Vehicular Networks
This section intends to introduce an additional novel feature for
future vehicular networks, which originates from SIoT concept
[Atz2012]. Note that the distinction of socialization as compared to
previously introduced grouping is that socialization is actually a
social-link graph for all inter-linked objects, while grouping is
simply a set of objects.
4.1. Socialization Sub-functions
As depicted in Figure 2, when vehicles are moving, they interact with
all available surrounding environments and capable sensors or devices,
which should be very practical in future if all infrastructures are
deployed with intelligent IoT sensors or devices. In such scenario,
the main entity i.e., the vehicle in vehicular networks, should have
differentiated relationships with surrounding devices that may happen
to encounter, often see each other on the road, always follow similar
routine, bound with same services, or sharing similar applications,
and so forth. Thus, it needs to realize a set of functions for
socialized vehicular networks, which are stated below (not limited
to):
- Relationship type definition: The vehicle-to-thing relationship is
heuristic, since there does not have a standardized way to perfectly
define this novel relationship at present. Previous SIoT studies show
some typical relationship as given [Atz2012]. For vehicular networks,
some useful relationships could be parental (same vehicular brand or
manufacturer), co-location (co-geolocation), ownership (same owner),
and social relationship (vehicle-to-thing friendship due to frequent
interactions).
- Relationship management (establish, update, dismiss, etc.):
Individual relation between any pair of vehicular objects should be
properly managed, including relationship establishment, update and
dismiss.
- Relationship storage: All relationships should be stored, mostly in
a distributed manner, while some static relationships could be stored
in a central server.
- Scalable query: Each vehicle may only store relationships from its
own perspective, thus vehicle-to-vehicle relationship query should
resort to some scalable query methodology.
- Relationship-based services: Based on vehicle-to-anything
relationship, some advanced services could be enabled, such as
Da Expires April 28, 2018 [Page 10]
Internet-Draft Vehicular Advanced Features October 2017
proximity service (e.g., road-side discount information), and
alerting service (e.g., alert is sent by the traffic light that this
vehicle passing through every day).
- Data delivery: Based on one-hop and multiple-hop relationships from
one specific vehicle, the data delivery could be performed according
to some relationship-based policies. For instance, when one alerting
event happens, the vehicle is able to automatically inform all nodes
in direct relationship and optionally inform nodes in multiple-hop
relationship.
- Access control: Relationship may provide an additional dimension
for access control, while limited relationships can be granted access
rights.
- Trustworthiness: Different relationships should have differentiated
trustworthiness, which shall support privacy protection over
sensitive information.
4.2. Socialization via Identifiers
Similarly, as stated in Section 3.2, there exist multiple types of
identifiers which could be used to label two endpoints of one
relationship link. However, due to different characteristics of
socialization, a self-certifying and privacy-protected identifier is
wanted to serve for the purpose of socialization for vehicles and
surrounding environmental sensor or devices. Thus, as indicated in
Figure 3, VID defined in an independent identifier layer, could be a
promising candidate.
With the considerations of massive IoT terminals and upper-layer
support, one IPv6-like VID (same length with IPv6, but have distinct
connotation) is recommended below, as shown in Figure 4.
28 bits 4 bits 96 bits
+-------------------------------------------+
| VID Flag | Vehicle Type | PKI-Hashed VID |
+-------------------------------------------+
Figure 4: One embodiment of VID
In Figure 4, VID Flag is 28-bit length, which resembles the function
of HIP Orchid (Overlay Routable Cryptographic Hash IDentifiers)
[RFC7401], and Vehicle Type serves the purpose of ITS Station Type
Da Expires April 28, 2018 [Page 11]
Internet-Draft Vehicular Advanced Features October 2017
defined in [Wet2010] with broader options. The last 96 bits adopt CGA
(Cryptographically Generated Address) principle, which is actually a
cryptographic hash of the public key of one particular vehicle. Note
that this embodiment of VID can be regarded as pseudo-persistent
identifier for vehicular networks, once it is well protected in the
network (e.g., encryption via transmission). Thus, the frequency of
reconstructing such VID becomes low, which potentially supports
socialization functions mentioned above. In addition, IBS (Identity-
Based Signature) might be utilized to construct such VID as well.
Particularly, for Vehicle Type segment shown in Figure 4, it could be
defined as follows, in line with [Wet2010]:
- 0000: Central ITS Station
- 0100: Roadside ITS Station
- 1000: Vehicle ITS Station
- 1100: Personal ITS Sation
The additional two bits are open for future definitions, which could
be that 0101 means traffic light and 1011 indicates ambulance.
4.3. Socialized Services
Once the vehicles and surrounding environmental sensors or devices
are socialized, there may develop lots of innovative future vehicular
services. Some of potential services are provided below:
- Proximity service: When co-location (co-geolocation) relationship
is detected, the services attached by VID could be delivered, such as
upper-layer application coupon information.
- Socialized vehicular status sharing: When two vehicles happen to
see each other on the road, and their VID indicates same brand, they
may activate the service of concerned information sharing, such as
oil consumption, most vulnerable component, etc.
- Social relationship based alerting service: When emergency event
happens, it normally resorts to human social relation to broadcast
the information, if this service is previously subscribed by vehicle
owners. However, in future vehicular networks, individual vehicles
and other surrounding devices are equipped with intelligence inside,
so they may actively exchange some useful information or even build
their own machine-type social networks. In this case, when emergency
Da Expires April 28, 2018 [Page 12]
Internet-Draft Vehicular Advanced Features October 2017
occurs, the corresponding vehicle could search its own social graph
to find the closest devices to inform emergent events.
- Socialized Autonomous Driving: Fully autonomous driving will come
true in the next decade, while an integrated solution with in-vehicle
interconnections, intra-vehicle communications, fast data processing,
intelligent planning should be developed. Then, socialization could
be one enabler for this vision as well, which could support not only
long-term relationship and also can support ephemeral relationship
for cooperative autonomous driving.
Furthermore, given this new socialization feature, there should have
more services available for further investigations, such as the
socialized vehicular navigation studied in [Far2015].
5. Security Considerations
For the two features discussed previously in this draft, there exist
lots of security issues that need to be well considered in near
future. First of all, for dynamic group or social relationship
management, it must ensure credible nodes to join, while preventing
any malicious node. Then, the identifiers used at cross-layers should
be securely managed and updated, such as VID is long-term used and
should not be transmitted explicitly to unwanted targets. Furthermore,
some low-latency and sensitive information should be explored along
the social graph when all vehicles are socialized, which introduces
trustworthiness problem as well. In addition, VID-attached data or
some aforementioned services must be genuine, so that individual
vehicles can utilize them in a secure manner.
6. References
6.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[TR22.886] Study on enhancement of 3GPP Support for 5G V2X Services
(Release 15), 3GPP TR 22.886, March 2017.
[RFC6830] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", Jan. 2013.
[RFC7401] Ed. R. Moskowitz, T. Heer, P. Jokela, and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", April 2015.
Da Expires April 28, 2018 [Page 13]
Internet-Draft Vehicular Advanced Features October 2017
6.2. Informative References
[Wet2010] M. Wetterwald, F. Hrizi, and P. Cataldi, "Cross-layer
Identities Management in ITS Stations", The 10th
International Conference on ITS Telecommunications,
November 2010.
[Jia2016] D. Jia, K. Lu, J. Wang, X. Zhang, and X. Shen, "A Survey on
Platoon-based Vehicular Cyber-physical Systems", IEEE
Communications Surveys & Tutorials, 2016.
[Atz2012] L. Atzori, A. Iera, G. Morabito, M. Nitti, "The Social
Internet of Things (SIoT) - When social networks meet the
Internet of Things: Concept, architecture and network
characterization", Computer Networks, Nov. 2012.
[Far2015] I. Farris, R. Girau, L. Militano, M. Nitti, and L. Atzori,
"Social Virtual Objects in the Edge Cloud", IEEE Cloud
Computing, 2015.
[Ala2015] K.M. Alam, M. Saini, A. El Saddik, "Toward Social Internet
of Vehicles: Concept, Architecture, and Applications", IEEE
Access, March 2015.
[Ces2013] S. Cespedes, N. Lu, and X. Shen, "VIP-WAVE: On the
Feasibility of IP Communications in 802.11p Vehicular
Networks", IEEE Transactions on Intelligent Transportation
Systems, March 2013.
[Fen2017] B. Feng, H. Zhang, H. Zhou, and S. Yu, "Locator/Identifier
Split Networking: A Promising Future Internet Architecture",
IEEE Communications Surveys and Tutorials, in press, 2017.
[Ces2015] S. Cespedes, and X. Shen, "On Achieving Seamless IP
Communications in Heterogeneous Vehicular Networks", IEEE
Transactions on Intelligent Transportation Systems, Dec.
2015.
[Pet2015] J. Petit, F. Schaub, M. Feiri, and F. Kargl, "Pseudonym
Schemes in Vehicular Networks", IEEE Communications Surveys
& Tutorials, 2015.
Da Expires April 28, 2018 [Page 14]
Internet-Draft Vehicular Advanced Features October 2017
Authors' Addresses
Bin Da
Huawei Technologies Co., Ltd.
No.156, Beiqing Road, Zhongguancun, Haidian District
Beijing 100095
China
EMail: dabin@huawei.com
Antonio Iera
University of Reggio Calabria
Salita Melissari, Reggio Calabria, 89124
Italy
EMail: antonio.iera@unirc.it
Claudia Campolo
University of Reggio Calabria
Salita Melissari, Reggio Calabria, 89124
Italy
EMail: claudia.campolo@unirc.it
Da Expires April 28, 2018 [Page 15]
