[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

    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]
    

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/