DMM Working Group J.F. Guan
Internet Draft BUPT
Intended status: Proposed Standard I. You
Expires: February 2018 Soonchunhyang University
S. Yao
AVIC China Aero-Polytechnology Establishment
August 24, 2017
PMIPv6 Group Binding Update for Internet of Things
draft-guan-dmm-gbu-01.txt
Abstract
Internet of Things (IoT) has been booming with rapid increase of
various wearable devices, vehicle embedded devices and so on, and
providing the effective mobility management for these IoT devices
becomes a challenge due to the different application scenarios as
well as the limited energy and bandwidth. Many researchers have
focused on this topic and proposed several solutions based on the
combination of IoT features and traditional mobility management
protocols, in which most of these schemes take the IoT devices as
mobile networks and adopt the NEtwork MObility (NEMO) and its
variants to provide the mobility support. However, these solutions
are in face of the heavy signaling cost problem. Considering that IoT
devices generally collaborate to realize the complex functions, these
devices may have the similar movement behaviors. This document
therefore specifies a PMIPv6-based group binding update method to
reduce the singling cost and improve the scalability for these
devices.
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 [RFC2119].
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
Guan Expires February 24, 2018 [Page 1]
Internet-Draft PMIPv6 Group Binding Update August 2017
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 February 24, 2017.
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.
Table of Contents
1. Introduction ................................................ 2
2. Conventions and Terminology ................................. 3
2.1. Conventions ............................................ 3
2.2. Terminology ............................................ 3
3. Usage scenarios ............................................. 4
4. Group Binding Extension...................................... 4
4.1. Mobile Node Group Identifier Option Extensions.......... 5
4.2. MAG and LMA Operations Extensions ...................... 6
5. Operation flow of Group Binding.............................. 7
5.1. Group Creation Process.................................. 7
5.2. Group Binding Procedure................................. 8
6. Security Considerations...................................... 9
7. IANA Considerations ......................................... 9
8. Acknowledgement ............................................. 9
9. References .................................................. 9
9.1. Normative References.................................... 9
9.2. Informative References................................. 10
1. Introduction
According to the recent statistics analysis from Cisco, the number of
Internet of Things (IoT) devices is expected to reach up to 50
billion by 2020. Because of the large volumes of mobile IoT devices,
it has been a big challenge to provide mobility support. IPv6 is
believed as a suitable protocol thanks to its large address space and
specific mechanisms to support mobility, such as Mobile IPv6 (MIPv6)
[RFC 6275] and its potential solutions for mobility management.
<Guan> Expires February 24, 2018 [Page 2]
Internet-Draft PMIPv6 Group Binding Update August 2017
However, these solutions have been designed for portable devices such
as cell phones or personal computers that have different application
requirements from the IoT devices. Therefore, they need to be
improved or enhanced in terms of bandwidth, energy consumption and
scalability.
It is worth to note from such application scenarios that the group is
one of important features in IoT. Therefore, several works have
focused on this problem and proposed lots of solutions, most of which
tried to apply NEtwork MObility (NEMO) [RFC 3963] into the IoT
scenarios.
NEMO as a mobility support protocol for mobile network is derived
from MIPv6 in which Mobile Router (MR) is introduced to deliver all
the packets for mobile network nodes via the bi-directional tunnel
between MR and its Home Agent (HA). When it is applied in IoT
scenarios, the MR is generally used as the leader to perform the
mobility signaling messages on behalf of all mobile network nodes.
However, due to the frequent mobility, the mobile network nodes will
change their attachment points dynamically which may introduce the
additional signaling and transmission costs due to the nested tunnels
operations according to standard NEMO protocol procedure.
In this document, we focus on the group characteristics of IoT
devices, analyze the dynamic group management mechanism, and extend
the bulk binding update of PMIPv6 [RFC 6602] to set up the dynamic
groups for IoT devices.
2. Conventions and Terminology
2.1. Conventions
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
2.2. Terminology
All the mobility-related terms used in this document are to be
interpreted as defined in the base PMIPv6 specifications [RFC 5213].
Internet of Things
The Internet of Things (IoT) is a system of interrelated computing
devices, mechanical and digital machines, objects, animals or people
<Guan> Expires February 24, 2018 [Page 3]
Internet-Draft PMIPv6 Group Binding Update August 2017
that are provided with unique identifiers and the ability to transfer
data over a network without requiring human-to-human or human-to-
computer interaction.
Group Binding
Group binding sets up dynamic binding for the same group, and
performs single binding for this group to reduce the signaling cost.
Different to bulk binding which is used for session groups, the group
binding is used for node groups.
3. Usage scenarios
There are a number of reasons why Group Binding support in PMIPv6 are
useful, and some of them are shown as following.
o Scenario 1: Wireless Body Network, which contains lots of smart
devices such as smart band. To provide the Internet connection
during the movement, it is better to treat these devices as a
whole group.
o Scenario 2: Vehicular Network in Intelligent Transportation
Systems, which adopts the group binding to merge the data
transmission of all devices in one vehicle or a group of vehicles.
4. Group Binding Extension
Group binding is based on bulk binding update mechanism. Bulk binding
is designed to optimize the binding update and revocation operations
for a group of mobility sessions by introducing group identifier. The
group identifier can be assigned by MAG or LMA, and will be exchanged
via Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA)
messages with B flag, and is finally recorded in the Binding Cache
Entry (BCE) of LMA. Therefore, the bulk binding is generally used to
extend the lifetimes of multiple mobility sessions, and revoke all
the sessions hosted on the failed service card.
The group biding extends the bulk binding not for session groups but
for the node groups and its basic idea is to set up a group for IoT
devices based on some metrics such as the movement similarity,
administrative domain to perform the binding update in form of node
groups. By this way, the signaling cost will be reduced.
Group binding update will extend mobile node group identifier option,
binding information on MAG and LMA.
<Guan> Expires February 24, 2018 [Page 4]
Internet-Draft PMIPv6 Group Binding Update August 2017
4.1. Mobile Node Group Identifier Option Extensions
The Mobile Node Group Identifier Option (MNGIO) defined in [RFC 6602]
is used to carry the group identifier. Figure 1 shows the extended
MNGIO format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Group Identifier (G-ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Mobile Node Group Identifier Option
Type
The type field has been assigned value 50 by IANA. It is an 8-bit
identifier to represent a mobile node group identifier option.
Length
The length field 8 bits, and its value is 6 octets which excludes
the type and length field.
Sub-type
The sub-type field is the 8-bit integer. The values of 0 and 255
have been reserved, the value of 1 has been assigned to bulk
binding update group by IANA. In this memo, a new sub-type called
group binding update is introduced, which is temporarily set its
value of 2 for IoT devices group binding update.
Reserved
Reserved field is 8-bit for future extension.
Mobile Node Group Identifier (G-ID)
The mobile node group identifier (noted as G-ID) is 32-bit integer,
which can be assigned by MAG and LMA. The all 0 and all 1 is
reserved.
Figure 2 shows the extended G-ID format which is 4 octets and divides
into flag and identifier fields. The first 1 octet is set to
<Guan> Expires February 24, 2018 [Page 5]
Internet-Draft PMIPv6 Group Binding Update August 2017
different flags, in which we introduce two flags T and P, and reserve
6 bits for future extensions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|P| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Extended Group Identifier Format
T flag
T flag distinguishes the assigner of group ID. T=1 indicates a
group ID assigned by LMA (called LG-ID). LG-ID represents the
group of IoT devices with the same HA or LMA. T=0 indicates a
group ID assigned by MAG (called MG-ID). MG-ID represents the
group of IoT devices that attaches to the same MAG
In this memo, LG-ID is predefined by HA or LMA to divide its IoT
devices into different groups in advance, while MG-ID is used to
record the attached IoT devices in the same access network.
P flag
P flag indicates the well-known group ID. P=1 indicates a
permanently-assign group ID. P=0 indicates a transient or
dynamical group ID.
Identifier
The following 3 octets identify different groups in which all zeros
and all ones are revised.
4.2. MAG and LMA Operations Extensions
MAG extends its Binding Update List (BUL) to add the MG-ID and LG-ID
fields, while LMA extends its BCE to include MG-ID and LG-ID.
LMA predefines the groups of IoT devices and assigns a LG-ID for each
group in advance, so that the IoT device in the same group will be
marked by LG-ID in the BCE of LMA.
MAG creates the groups of IoT devices dynamically according to the
group policy (for example, movement-based method), and assigns a MG-
ID for each group, and records the MG-ID in the binding update list
for each node in that group.
<Guan> Expires February 24, 2018 [Page 6]
Internet-Draft PMIPv6 Group Binding Update August 2017
LMA and MAG exchange LG-ID and MG-ID via PBU and PBA messages within
the MNGIO. Based on (MG-ID, LG-ID) information, both MAG and LMA
update their binding update list and binding cache, respectively.
Similar to [RFC 6602], the extensions of BCE and BUL use the MAG-
Bulk-Binding-Update-Group-Id to record the MG-ID received from MAG,
and use the LMA-Bulk-Binding-Update-Group-id to record the LG-ID
received from LMA.
5. Operation flow of Group Binding
5.1. Group Creation Process
Assume that there are three groups of IoT devices called LG-ID11, LG-
ID12, and LG-ID21 initially. LG-ID11 and LG-ID12 are assigned by LMA1,
and LG-ID21 is assigned by LMA2. These groups can be noted as (LMA1,
LG-ID11), (LMA1, LG-ID12), and (LMA2, LG-ID21).
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
/ \ |
+--------+ +--------+ +--------+
| o o | | ^ ^ | | * * |
| o o | | ^ ^ | | * |
|o o | | ^ ^ | | * * |
+--------+ +--------+ +--------+
(LMA1,LG-ID11) (LMA1,LG-ID12) (LMA2,LG-ID21)
+--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 |
| o | move | o ^ | move | * |
| o ^ * | <--> | o ^ * | <--> | ^ * |
| o ^ | | o * | | ^ * |
+--------+ +--------+ +--------+
(MAG1,MG-ID11) (MAG2,MG-ID21) (MAG3,MG-ID31)
Figure 3 Group Creation Procedure
At the beginning, several IoT devices attach to MAG1. Based on the
movement trace character or other grouping strategies. MAG1 sets up a
group and assigns a group identifier MG-ID11. After exchanging the
group information between MAG and LMA, the devices in MG-ID1 can be
further divide into multiple subgroups based on their LMAs. As shown
in Figure 3 (different marks denote different nodes), the MG-ID11
group can be divided into two parts. The left part is the subgroup of
devices belonging to LMA1, while the right part belongs to LMA2. The
binding update will be performed in form of a group with same (MG-ID,
LG-ID). To this end, the devices in the same subgroup belonging to
<Guan> Expires February 24, 2018 [Page 7]
Internet-Draft PMIPv6 Group Binding Update August 2017
LMA1 will only perform once registration with their LMA, while the
other IoT devices in the group have to perform the multiple
registrations with their LMAs respectively. By this way, the
signaling cost can be greatly reduced especially when the devices'
density is high. Once these IoT devices move into another access
network, a new group will be created, and performs the similar
procedure as t1. By setting up the group, the IoT devices belonging
to the same LMA will only update once with their LMAs, and therefore
the signaling cost will be reduced.
5.2. Group Binding Procedure
Assume that the LG-IDs are assigned by LMA in advance and stored in
LMA's BCEs. The detailed signaling flow of group binding update when
the IoT devices enters the PMIPv6 domain is shown as follows.
1. In the beginning, MAG1 detects the attachment events of IoT
devices to acquire MN-IDs and their profiles. After that, MAG1
divides the attached IoT devices into different groups based on
the grouping policy such as movement similarity, and assigns the
MG-IDs for these groups. MAG1 records the group members of each
IoT group, and updates the related BUL with MG-ID for each group
member.
2. IoT device (noted as MN1) belonging to MG-ID1 sends Router
Solicitation message (noted as RS1) to MAG1 at any time after it
attached to MAG1.
3. After received RS1, MAG1 sends PBU message with B flag to MN1's
LMA (noted as LMA1). The PBU message carries the MN1's ID (MN-ID1)
and group ID (MG-ID1).
4. Once LMA1 receives this PBU message, it will update the related
BCE based on the MN-ID, and update the MG-ID field, and then it
will reply a PBA message with B flag in which MN1's LG-ID1 is
carried in the MNGIO field.
5. Once MAG1 receives PBA, it will update the related BUL with the
LG-ID1. In this way, the group information is exchanged.
6. In the similar way, other IoT devices (such as MN2, MN3, and so on)
perform the similar binding update procedure.
7. After finishing the initiation procedure, the MAG will perform the
group binding update, and update the group binding relationship of
MG-ID1. For all the nodes with the same LMA, it only performs one
binding update procedure.
<Guan> Expires February 24, 2018 [Page 8]
Internet-Draft PMIPv6 Group Binding Update August 2017
8. In the similar operation, MAG2 and MAG3 will perform the same
procedure as MAG1. By this way, the IoT devices in the same group
such as (MG-ID, LG-ID) will only perform once, and the overall
binding update cost will be reduced.
6. Security Considerations
The potential security threats against group binding is similar to
any network-based mobility management protocol which are described in
[RFC 4832] [RFC 5213].
Other security issues will be analyzed further.
7. IANA Considerations
This document defines a new subtype of Mobile Node Group Identifier
Option. Therefore, IANA should consider the following number
definitions.
Sub-type = 0x02 a new sub-type called group binding update
This document defines a new format of group ID as shown in Figure 2.
8. Acknowledgement
This work was supported by the National Basic Research Program of
China (973 Program) under Grant no. 2013CB329102, the Soonchunhyang
University Research Funding, and the Basic Science Research Program
through the National Research Foundation of Korea (NRF) funded by the
Ministry of Science, ICT & Future Planning (2014R1A1A1005915).
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol," IETF RFC
3963, January, 2005.
<Guan> Expires February 24, 2018 [Page 9]
Internet-Draft PMIPv6 Group Binding Update August 2017
[RFC4068] R. Koodli et al., "Fast Handover for Mobile IPv6, " RFC
4068, 2005.
[RFC4140] H. Soliman, Flarion et al., "Hierarchical Mobile IPv6
Mobility Management (HMIPv6), " RFC 4140, 2005.
[RFC5213] S. Gundavelli et al., "Proxy Mobile IPv6," IETF RFC 5213,
Aug. 2008.
[RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in
IPv6," IETF RFC 6275, July 2011.
[RFC6602] F. Abinader, S. Gundavelli, K. Leung, S. Krishnan, D.
Premec, "Bulk Binding Update Support for Proxy Mobile
IPv6," RFC 6602, 2012.
9.2. Informative References
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4832] C. Vogt, J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832, April
2007.
<Guan> Expires February 24, 2018 [Page 10]
Internet-Draft PMIPv6 Group Binding Update August 2017
Authors' Addresses
Jianfeng Guan
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian district, Beijing, China
Email: jfguan@bupt.edu.cn
Ilsun You
Soonchunhyang University
22 Soonchunhyang-ro, Shinchang-myeon, Asan-si, Choongchungnam-do,
Korea 31538
Email: ilsunu@gmail.com
Su Yao
AVIC China Aero-Polytechnology Establishment
No. 7 Jingshun Road, Chaoyang Distract, Beijing, China
Email: yaosu@bjtu.edu.cn
<Guan> Expires February 24, 2018 [Page 11]