Internet DRAFT - draft-guan-dmm-gbu

draft-guan-dmm-gbu











    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]