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. 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 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. 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 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. 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 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. 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. 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. 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 Expires February 24, 2018 [Page 11]