[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6602

Netext Working Group                                    F. Abinader, Ed.
Internet-Draft                             Instituto Nokia de Tecnologia
Intended status: Standards Track                           S. Gundavelli
Expires: April 28, 2011                                         K. Leung
                                                                   Cisco
                                                             S. Krishnan
                                                                Ericsson
                                                               D. Premec
                                                            Unaffiliated
                                                        October 25, 2010


               Bulk Re-registration for Proxy Mobile IPv6
               draft-ietf-netext-bulk-re-registration-02

Abstract

   Proxy Mobile IPv6 specification requires the Mobile Access Gateway
   (MAG) to send a separate Proxy Binding Update (PBU) message to the
   Local Mobility Agent (LMA) for each mobile node (MN) to renew the
   MN's mobility binding.  This document defines a mechanism by which a
   MAG can update the mobility bindings of multiple MNs attached to it
   with a single PBU message to the serving LMA.  This document also
   specifies a new mobility option that can be used by the mobility
   entities in a Proxy Mobile IPv6 domain for carrying the group
   affiliation of a mobile node in any of the mobility signaling
   messages.

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
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Abinader, et al.         Expires April 28, 2011                 [Page 1]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   This Internet-Draft will expire on April 28, 2011.

Copyright Notice

   Copyright (c) 2010 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.



































Abinader, et al.         Expires April 28, 2011                 [Page 2]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Bulk Registration Overview . . . . . . . . . . . . . . . . . .  5
     3.1.  Motivation for bulk re-registration  . . . . . . . . . . .  5
     3.2.  Bulk re-registration operation . . . . . . . . . . . . . .  6
       3.2.1.  BULK_ADD_MN operation  . . . . . . . . . . . . . . . .  7
       3.2.2.  BULK_REMOVE_MN operation . . . . . . . . . . . . . . .  8
       3.2.3.  BULK_REREG_SET operation . . . . . . . . . . . . . . .  8
       3.2.4.  BULK_TERMINATE_SET operation . . . . . . . . . . . . .  9
   4.  Message formats  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Proxy Binding Update message . . . . . . . . . . . . . . . 10
     4.2.  Proxy Binding Acknowledgment message . . . . . . . . . . . 11
     4.3.  Mobile Node Group Identifier Option  . . . . . . . . . . . 12
   5.  MAG Operation  . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  LMA operation  . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19





























Abinader, et al.         Expires April 28, 2011                 [Page 3]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


1.  Introduction

   The Proxy Mobile IPv6 (PMIPv6) base specification [RFC5213] uses the
   Mobile Node Identifier (MN-ID) option in the mobility signaling
   messages, i.e.  Proxy Binding Update (PBU) and Proxy Binding
   Acknowledgement (PBAck) messages, for identifying a single Mobile
   Node (MN).  However, these signaling messages lack the capability to
   identify a set of mobile nodes which have a common characteristic.  A
   group identifier associated with a set of mobile nodes enables the
   ability to perform protocol operation on this set of mobile nodes via
   a single transaction.  The group identifier also provides a more
   optimal mechanism for protocol operation which would otherwise
   require multiple atomic transactions on a mobile node basis.
   Following are some of the use-cases where such identifier can be
   used.

   o  In a blade architecture system running the Local Mobility Anchor
      (LMA) service, all the mobile node sessions anchored on a given
      card can belong to a single group.  When there is a failure on a
      specific card, the LMA can initiate the revocation signaling to
      the Mobile Access Gateway (MAG) by sending a single revocation
      request carrying the group identifier.

   o  For periodic re-registrations, the MAG may send a single re-
      registration message for all the mobile nodes that belong to a
      group by informing just the mobile node group identification that
      identifies that group.

   o  The MAG or the LMA in a PMIPv6 domain may choose to revoke the
      registration of all mobile nodes associated with a specific realm.
      In such cases the MAG or the LMA can perform the binding
      revocation signaling using the group ID associated with a specific
      set of mobile nodes.

   The remainder of this document defines a new mobility option, named
   Mobile Node Group Identifier option, that can be used by a local
   mobility anchor and a mobile access gateway for exchanging the mobile
   node's group identifier as well as its application for bulk periodic
   re-registrations.


2.  Terminology

   General mobility related terminology is defined in [RFC3775].
   Additional PMIPv6 specific terminology can be found in [RFC5213].






Abinader, et al.         Expires April 28, 2011                 [Page 4]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   PMIPv6
      Proxy Mobile IPv6 protocol, as specified in [RFC5213].

   PMIPv6 domain
      Network providing the network based IP mobility service as defined
      in [RFC5213].

   Group Identifier
      An opaque identifier (i.e. not containing any information that is
      at risk of becoming not valid in the future) that is allocated by
      the LMA, and which uniquely identifies the bulk set to which the
      MN was added in both the LMA and in the MAG.  As an example of the
      meaning of such opacity, the LMA may decide to use random numbers
      as the value for the group identifier.  This group identifier
      shall be used on signaling messages operating over bulk
      registration sets between the MAG and the LMA.

   Bulk registration
      Operation involving the exchange of PBU/PBAck messages where the
      bulk registration flag (B) is set to 1.

   Bulk registration set
      A set of MNs identified by the Mobile Node Group Identifier option
      to which the bulk registration operation applies.


3.  Bulk Registration Overview

3.1.  Motivation for bulk re-registration

   In a PMIPv6 domain a single LMA serves multiple MAGs and the capacity
   of the LMA in terms of the number of attached MNs can be quite large.
   It can be expected that LMA capacity in managed networks may easily
   exceed hundreds of thousands (or even more) of attached MNs.
   However, as the number of managed MNs grows, it also grows the demand
   for bandwidth for signaling messages to refresh the mobility bindings
   of such MNs.  The following simple formula gives an estimate of the
   average number of re-registration transactions per second as a
   function of the number of registered MNs and the binding lifetime
   period:

   transactions/sec = (number of registered MNs) / (binding lifetime*4)

   For a scenario of 50.000 MNs and the binding lifetime of half an hour
   this gives: 50000 MNs / 1800 sec = 27,7 transactions/sec

   Based on the above formula and example scenario it is apparent that
   the default PMIPv6 re-registration process where the MAG sends a



Abinader, et al.         Expires April 28, 2011                 [Page 5]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   separate message for each MN is inefficient or suboptimal.  These re-
   registration messages consume significant network resources, both in
   terms of processing power at the LMA and MAG and in terms of network
   bandwidth.

   This document proposes an optimization of the PMIPv6 re-registration
   process by which the signaling load for re-registration can be
   reduced to a single transaction per MAG, irrespective of the number
   of attached MNs.  According to this proposal, a MAG adds a MN to a
   set of MNs re-registered in a bulk mode by setting the bulk
   registration flag (B) in the PBU message.  The PBAck message sent in
   response contains the Mobile Node Group Identifier mobility option
   which is defined later in this document.  In the context of bulk re-
   registrations the Mobile Node Group Identifier is an opaque
   identifier that is allocated by the LMA and which uniquely identifies
   the bulk set to which the MN was added.

   A MAG requests a bulk re-registration for a set of MNs by sending a
   single PBU message which includes a Mobile Node Group Identifier
   option, and the LMA then extends the binding lifetime of all the MNs
   that belong to that group.  By using this method, the MAG and LMA may
   accomplish the re-registration of MNs attached to a MAG in a single
   transaction.  The number of re-registration transactions at the LMA
   becomes independent of the number of attached MNs; instead it is
   dependent only on the number of MAGs (i.e. bulk registration sets).

   In addition to minimizing the signaling overhead associated with the
   lifetime extension of the mobility bindings, the MAG and LMA may use
   a single timer per bulk registration set to monitor the binding
   lifetime of all the member MNs instead of an individual timer per MN.

3.2.  Bulk re-registration operation

   The bulk re-registration mechanism allows the MAG and the LMA to
   extend the binding lifetime for a number of MNs with a single
   transaction.  The MAG and LMA maintain a set of MNs that can be re-
   registered in bulk mode.  Such set is called a bulk registration set,
   and is a subset of the MNs attached to a MAG.  There can be multiple
   bulk registration sets for a given MAG-LMA pair; however, there can
   be only one MAG and one LMA associated with a given bulk registration
   set at any moment.

   There are two basic operations related to bulk registration sets
   which may be requested by the MAG for any given MN, namely the
   addition (BULK_ADD_MN) of a MN to some bulk registration set (to be
   determined by the LMA) and the removal (BULK_REMOVE_MN) of a MN from
   some bulk re-registration set.  In the case of the removal of a
   single MN from a bulk registration set (BULK_REMOVE_MN), the LMA may



Abinader, et al.         Expires April 28, 2011                 [Page 6]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   also take a unilateral decision to remove the MN, as specified later
   in this specification.

   In addition to these MN operations, the MAG may also request two
   additional operations for any given bulk registration set.  The first
   operation is the collective re-registration (BULK_REREG_SET) of a set
   of MNs within a given bulk registration set with a single atomic
   operation.  The other operation is the the removal of all MNs
   previously contained in a given bulk registration set
   (BULK_TERMINATE_SET), which means that all MNs previously in that
   bulk registration set must be individually registered again by the
   MAG on the LMA.  The LMA may also decide to terminate the mobility
   binding of all MNs previously contained in a given bulk registration
   set (BULK_TERMINATE_SET), in which case it must use the proper
   mechanism described further in this document.

   Note that this specification does not define any new PMIPv6
   signaling, but solely defines new mobility options for the existing
   PMIPv6 signaling messages, whose are defined in details on
   Section 4.3.

   In the following sections are provided further details both on the
   two operations over the MNs in a bulk registration set (BULK_ADD_MN
   and BULK_REMOVE_MN) as well as on the two operations over the bulk
   registration sets themselves (BULK_REREG_SET and BULK_TERMINATE_SET)
   are provided.

3.2.1.  BULK_ADD_MN operation

   Initially the bulk registration set is empty.  MAG requests to add
   individual MNs to the bulk registration set (while at the same time
   refreshing the MN binding itself) by sending a regular PBU message
   that (a) identifies an individual MN with its MN-ID and (b) sets the
   bulk re-registration flag in the message to 1.  Based on the received
   bulk re-registration flag on the PBU message, the LMA takes the
   decision whether to add the MN to a bulk registration set or not.  If
   the LMA decides for including the MN on a bulk registration set, it
   responds to the MAG with a PBAck message where (a) the bulk
   registration flag (B) set to 1 and (b) the bulk registration set to
   which the MN was added is represented by the Mobile Node Group ID
   option.  If, instead, the LMA decides for reject the addition of the
   MN on a bulk registration set, the LMA processes the PBU message as
   if the bulk registration flag was not set, and responds with PBAck
   message where the bulk re-registration flag is set to 0.

   There may be different aspects involved in the LMA decision process
   whether to include or not a MN on a bulk registration set upon a
   request by the MAG via a PBU message with the the bulk registration



Abinader, et al.         Expires April 28, 2011                 [Page 7]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   flag (B) in the message set to 1.  However, they may be
   implementation or domain specific, and therefore are outside the
   scope of this specification.

3.2.2.  BULK_REMOVE_MN operation

   A MAG may remove a single MN from the bulk registration set in which
   it is currently included by sending a regular PBU message to the LMA
   identifying the MN to be removed (i.e.  MN-ID) and with the bulk re-
   registration flag set to 0.  This PBU message not only informs the
   LMA to remove the MN from its current bulk registration set, but also
   requests to refresh the binding of that MN as well, just as a regular
   PBU message would do.  The LMA then responds with a regular PBAck
   message where the bulk registration flag set to 0 and the MN-ID that
   identifies that MN, therefore indicating to the MAG that the binding
   of such MN was refreshed.

   The LMA itself may also decide (for some implementation or domain
   specific reason not covered on this specification) to remove a single
   MN from its current bulk registration set, in which case it sends a
   non-solicited regular PBAck message to the MAG, with the the bulk
   registration flag set to 0 and with the MN identification field (i.e.
   MN-ID).  This message not only informs that a given MN previously
   contained in a bulk re-registration set was removed, but also that
   the binding of such MN was also refreshed.  If the lifetime value in
   the non-solicited PBAck message is set to a value different than 0,
   this must indicate to the MAG that the MN is no longer on a bulk
   registration set but the binding of the MN in the LMA is indeed
   refreshed and valid, and therefore this MN refreshing timer must be
   controlled separately in a proper way, just as a regular MN as per
   the [RFC5213].  If however the the lifetime value indicated in the
   non-solicited PBAck message is set to 0, it not only indicates that
   the MN was removed from the bulk registration set, but also that the
   binding of that MN on the LMA itself has expired, and therefore is no
   longer valid.

3.2.3.  BULK_REREG_SET operation

   Once there is a non-empty bulk registration set registered at the LMA
   (with one or more MNs), the MAG can request to extend the binding
   lifetime for all MNs belonging to such bulk registration set by
   sending a PBU message with the bulk registration (B) flag set and by
   including the Mobile Node Group ID identifying the bulk registration
   set itself, which value was previously received from the LMA.  Such
   PBU message lacks any options that identify an individual MN.  In
   particular, the MAG omits both the MN-ID (Mobile Node Identifier) and
   the HNP (Home Network Prefix) options.




Abinader, et al.         Expires April 28, 2011                 [Page 8]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   MAG may also include multiple instances of the Mobile Node Group
   Identifier option in a single PBU message only if the intent is to
   request lifetime refreshment for several bulk registration sets at
   the same time.  Even further, the MAG may even request to re-register
   all bulk re-registration sets previously established with the LMA by
   sending a single PBU message where there is a single Mobile Node
   Group Identifier option with the value of all bits set to 1 (see
   Section 4.3 for more information).  However, PBU messages that try to
   extend binding time to some bulk registration sets while at the same
   time terminating bindings with other bulk registration sets (e.g. by
   setting zero lifetime) in the same PBU message are not possible, as
   this PBU message would be ambiguous in determining which bulk
   registration sets would be refreshed and which bulk registration sets
   would be terminated.  As a consequence, if for some reason those two
   classes of operations need to be performed concurrently, they must be
   done with the use of separate PBU messages.

   Upon the receive of the PBU message with the bulk registration (B)
   bit set and by including the Mobile Node Group ID instance(s)
   identifying the bulk registration set(s) to re-register (i.e. refresh
   the binding of each MN belonging to each bulk registration set
   informed), the LMA extends the mobility binding of all MNs that are
   members of the indicated bulk registration set(s) and responds with
   the PBAck message echoing the received Mobile Node Group Identifier
   mobility options, in special with the bulk registration (B) flag set
   and including the Mobile Node Group ID instance(s) identifying the
   bulk registration set(s) re-registered.

3.2.4.  BULK_TERMINATE_SET operation

   A MAG may request to terminate any given bulk registration set at any
   moment with a single atomic operation, which implicates (a) in the
   expiration of the mobility bindings of all the MNs belonging to that
   bulk registration set on the LMA at the same time and (b) on the
   termination of the bulk registration set itself on both the MAG and
   the LMA.  For that, the MAG sends a PBU message with the bulk
   registration flag (B) set to 1, sets the lifetime value to zero and
   informs the bulk registration set to the LMA by including the Group
   I-D option in the message.  Here, the MAG may also perform the
   termination of more than one bulk registration sets with a single
   atomic operation, in which case the PBU message contains the multiple
   mobile node Group I-D options representing these multiple bulk
   registration sets.  Finally, the MAG may also request to terminate
   all bulk registration sets, in which case it should send the Group
   I-D option with the value of all bits set to 1 (see Section 4.3 for
   more information).

   Upon receive of such PBU message indicating a bulk registration



Abinader, et al.         Expires April 28, 2011                 [Page 9]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   termination request, the LMA expires the mobility bindings of all the
   MNs belonging to all the bulk registration sets specified in the PBU
   message and extinguish the representations of the bulk registration
   sets themselves.  Then, the LMA sends back a PBAck message to the
   MAG, reproducing all the mobility options informed on the original
   PBU message, including the bulk registration flag (B) set to 1, the
   lifetime value set to zero and the Group I-Ds originally mentioned.

   The LMA itself may also decide unilaterally that one or more bulk
   registration sets are terminated, in which case it shall expires the
   mobility bindings of all the MNs belonging to these bulk registration
   sets, extinguish the representations of these bulk registration sets
   and send a PBAck message to the MAG where the bulk re-registration
   flag (B) is set to 1, the lifetime value is set to zero and the Group
   I-Ds identifying bulk registration sets.  The MAG, upon the receive
   of such PBAck message, then proceeds with the expiration of the
   mobility bindings of the MNs belonging to the specified bulk
   registration sets as per [RFC5213], and then extinguish the
   management of the bulk registration sets themselves.  The reasons for
   both the MAG or LMA deciding to extinguish bulk registration sets may
   be implementation or domain specific, and therefore are outside the
   scope of this specification.


4.  Message formats

   This section introduces extensions to PBU and PBAck messages used in
   this specification.

4.1.  Proxy Binding Update message
    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |            Sequence #         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|L|K|M|R|P|B|   Reserved    |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   A Proxy Binding Update message is defined in the [RFC5213].  A new
   flag (B) is defined for the Binding Update message, as seen on



Abinader, et al.         Expires April 28, 2011                [Page 10]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   Figure 1, while the other remaining fields (i.e.  Sequence #, flags
   and Lifetime) keep their definition as per defined in the [RFC5213].

   Bulk Registration Flag (B)

   If the bulk registration flag (B) is set to 1, then the PBU message
   is a request to add the MN to the bulk registration set.  If the bulk
   registration flag (B) is set to 0 and if the MN is found to be a
   member of the bulk registration set, then the MN is removed from the
   bulk registration set.

   Mobility Options

   For descriptions of the mobility options, refer to [RFC5213].  When
   the PBU message is sent to refresh bindings in a bulk mode, the
   message MUST contain at least one Mobile Node Group Identifier
   mobility option and does not contain the MN-ID and the HNP mobility
   options.

4.2.  Proxy Binding Acknowledgment message
    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|P|B|  Res. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Sequence #            |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Proxy Binding Acknowledgment message

   A Proxy Binding Acknowledgment message is defined in the [RFC5213].
   A new flag (B) is defined for the Binding Acknowledgment message, as
   seen on Figure 2.

   Bulk Registration Flag (B)

   A new flag (B) is included in the Binding Acknowledgment message to
   indicate to the MAG that the MN was successfully added to the bulk
   re-registration set.  The flag MUST NOT be set to the value of 1 if
   it was not set to 1 in the corresponding PBU message.

   Mobility Options



Abinader, et al.         Expires April 28, 2011                [Page 11]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   These are the original PMIPv6 mobility options as defined in
   [RFC5213].  Additionally, at least one instance of the Mobile Node
   Group Identifier mobility option (see Section 4.3) MUST be included
   on the PBAck message if the bulk registration flag is set to 1 in the
   PBU message.  When the Mobile Node Group Identifier mobility
   option(s) were included in the PBU message, the PBAck message echoes
   back the Mobile Node Group Identifier options from the PBU
   message.[RFC5213].

4.3.  Mobile Node Group Identifier Option

   A new option, Mobile Node Group Identifier option is defined for
   using it in Proxy Binding Update and Proxy Binding Acknowledgement
   messages exchanged between a local mobility anchor and mobile access
   gateway.  This option is used for carrying the mobile node's group
   identifier.

   The alignment requirement for this option is 4n.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |           Sub-type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Mobile Node Group Identifier                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: Mobile Node Group Identifier Option

   Type
      <IANA>

   Length
      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.  The value for this
      field MUST be set to 6 in the case where the PBU message is
      requesting the binding refresh, both for the situation where the
      Mobile Node Group Identifier specifies a single bulk registration
      set and for the situation where this field specifies all the MNs
      attached to the MAG that are members of any bulk set.

   Sub-type
      Identifies the specific group type.  This number space will be
      managed by the IANA.






Abinader, et al.         Expires April 28, 2011                [Page 12]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   Mobile Node Group Identifier   A 32-bit field containing the mobile
      node's group identifier.  This field may identify either a single
      bulk registration set or all the MNs attached to the MAG that are
      members of any bulk set, depending on the value.  Specifically in
      the case where the field is representing all the MNs attached to
      the MAG that are members of any bulk set, then all the bits of
      that field should be set to 1.

   The Mobile Node's Group Identifier option reflects the group
   affiliation that is local to the specific LMA-MAG pair.  The specific
   value for the Mobile Node group Identifier is always determined by
   the LMA on the PBAck message, and must be used by the MAG on all
   future bulk re-registration procedures for that bulk registration
   set.


5.  MAG Operation

   The conceptual Binding Update List entry data structure maintained by
   the MAG, described in Section 6.1 of [RFC5213], MUST be extended to
   store the mobile node's group identifier.  The MAG SHALL maintain
   separate bulk registration sets for each LMA.

   Bulk re-registration operations are optional to PMIPv6 [RFC5213], so
   the Mobile Node Group Identifier option MAY be used in the PBU
   message sent by the MAG to the LMA only when a bulk registration
   operation (i.e.  BULK_REREG_SET and BULK_TERMINATE_SET) is intended.
   When this option is included, the identifier value in the option MUST
   be set to the mobile node's group identifier that was assigned
   previously by the LMA.

   When a new MN attaches to a MAG, the MAG registers the MN with the
   LMA by sending the PBU message formatted as described in [RFC5213].
   Additionally, the MAG MAY set the bulk registration flag (B) in the
   PBU message to 1 to request the LMA to add the MN to the bulk
   registration set.

   The decision to request the bulk registration mode for a MN is a
   matter of local policy at the MAG and is outside the scope of this
   specification.

   The MAG SHALL add the MN to its bulk registration set when it
   receives a PBAck message with the bulk registration flag (B) set to 1
   and if the corresponding PBU message was previously requesting the
   LMA to add the MN to a bulk registration set.  The MAG SHALL
   associate the MN being registered with the Mobile Node Group
   Identifier received in the PBAck message.  If instead the MAG sets
   the bulk registration flag to 1 in a PBU message but the bulk



Abinader, et al.         Expires April 28, 2011                [Page 13]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   registration flag (B) is set to 0 in a PBAck message, the MAG SHALL
   process the PBAck message as per [RFC5213].  In addition, the MAG MAY
   infer that the LMA does not support bulk re-registration procedure.
   The MAG MAY switch to regular, per-MN re-registration mode as
   described in [RFC5213], and MAY NOT retry bulk registration set
   additions to that LMA unless an administrative action is taken.

   The MAG SHALL decide to remove a single MN from the bulk registration
   set in which it is currently included at any time, and in order to
   proceed with such operation the MAG SHALL send a standard PMIPv6 PBU
   message (as per the [RFC5213]) identifying the MN and with the bulk
   registration flag (B) set to 0.  This PBU message not only informs
   the LMA to remove the MN from its current bulk registration set, but
   also requests to refresh the mobility binding of that MN as well, as
   a regular PMIPv6 message would do.

   Upon receive of a standard PBAck message in response for the PBU
   message just sent, the MAG SHALL process the message as per the
   remove the [RFC5213], and then remove the MN from the bulk
   registration set.  If the lifetime of the PBAck message is larger
   than zero, it SHALL mean that the MN only was removed from the bulk
   registration set but the mobility binding of such MN is still valid,
   and therefore the mobility binding should be renewed as specified in
   [RFC5213]; if however the lifetime is equal to zero, it SHALL mean
   for the MAg that not only the MN was removed from the bulk
   registration set but also that the mobility binding of such MN is no
   longer valid, and SHALL proceed as specified in [RFC5213].

   The MAG may also receive a non-solicited standard PBAck message for a
   MN which is currently on a bulk registration set, which SHALL mean
   for the MAG that the LMA decided unilaterally to remove the MN from
   the bulk registration set.  The MAG SHALL proceed processing this
   PBAck message as defined in the previous paragraph, as if this PBAck
   message was sent in response to a request by the MAG to remove the MN
   from the bulk registration set it is currently in.

   The binding lifetime of MNs which belong to a given bulk registration
   set becomes the binding lifetime of the bulk registration set itself.
   Therefore, both the MAG and the LMA MAY not keep separate binding
   lifetimes for all MNs in a given bulk registration set, and instead
   SHALL keep a common binding lifetime for the whole bulk registration
   set.  If later on a given MN leaves the bulk registration set, then
   both the MAG and the LMA SHALL keep separate binding lifetimes for
   this MN.

   When the binding lifetime of a bulk registration set is about to
   expire, the MAG SHALL request the bulk re-registration by sending the
   PBU message containing the Mobile Node Group Identifier mobility



Abinader, et al.         Expires April 28, 2011                [Page 14]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   option.  Alternatively, the MAG MAY include one or more Mobile Node
   Group Identifier options containing the values that were indicated by
   the LMA in the PBAck messages when the MN was added to the bulk set.
   In this case the MAG asks for refreshment of specific bulk sets
   indicated by the Mobile Node Group Identifier options.  The MAG MAY
   even request the refreshment of all the MNs attached to the MAG that
   are members of any bulk set with a single atomic operation, in which
   case there will be a single Mobile Node Group Identifier option on
   the PBU message with all the field bits set to 1 as specified in
   Section 4.3.  In any case, the MAG SHALL NOT include the MN ID and
   the HNP options in the PBU message requesting bulk refreshment.

   The MAG MAY trigger a bulk re-registration at any time.  The policy
   and exact conditions for these additional triggers are outside of
   scope of this specification.

   When the MAG receives a PBAck message indicating success and which
   echoes the Mobile Node Group Identifier options that were included in
   the corresponding PBU message, the MAG SHALL update the binding
   lifetime of all MNs belonging to the indicated groups to the lifetime
   value contained in the PBAck message.  If in the case of bulk
   registration the PBAck message repeatedly indicate an error, the MAG
   SHALL fall back to individual re-registration mode.

   A MAG MAY decide to terminate any given bulk registration set at any
   moment, for reasons not covered at this specification.  In order to
   proceed with such operation, the MAG SHALL request the termination of
   such bulk registration set in a single atomic operation by sending a
   PBU message with the bulk registration flag (B) set to 1, sets the
   lifetime value to zero and informs the bulk registration set to the
   LMA by including the Group I-D option in the message.  Here, the MAG
   may also perform the termination of more than one bulk registration
   sets with a single atomic operation, in which case the PBU message
   contains the multiple mobile node Group I-D options representing
   these multiple bulk registration sets.  Finally, the MAG may even
   request to terminate all bulk registration sets, in which case it
   should send the Group I-D option with the value of all bits set to 1
   (see Section 4.3 for more information).

   Upon receive the PBAck message echoing the PBU message requesting
   bulk registration set(s) termination(s), the MAG SHALL expire the
   mobility bindings of all the MNs belonging to that bulk registration
   sets and also terminate the bulk registration set itself.

   The reasons for the MAG deciding to terminate the bulk registration
   sets may be implementation or domain specific, and therefore are
   outside the scope of this specification.




Abinader, et al.         Expires April 28, 2011                [Page 15]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   The MAG may also receive a non-solicited PBAck message where the bulk
   registration flag (B) is set to 1 and with one or more mobile node
   group identifier option instances, just as if this message was sent
   in reply to a PBU message sent by the MAG when requiring the
   terminaiton of bulk registration sets.  In this case, the MAG SHALL
   interpret this as a unilateral decision by the LMA to terminate the
   mobility bindings of the MNs previously belonging to these bulk
   registration sets, and therefore it should expire the mobility
   bindings of all the MNs belonging to the bulk registration sets at
   the same time and also terminate the bulk registration set(s)
   specified in the PBAck message.


6.  LMA operation

   The conceptual Binding Cache entry data structure maintained by the
   LMA, described in Section 5.1 of [RFC5213], MUST be extended to store
   the mobile node's group identifier.  The LMA SHALL maintain distinct
   bulk registration sets for each MAG and there could be several such
   sets per single MAG.

   The Mobile Node Group Identifier option MAY be used in the PBAck
   message sent by the LMA to the MAG.  When this option is included,
   the identifier value in the option MUST be set to the MN's group
   identifier, local to the LMA.

   When the LMA receives a PBU message with a bulk registration flag (B)
   set to 1, the LMA SHALL first process the PBU message as per
   [RFC5213].  Upon successful processing of the message, the LMA SHALL
   perform additional processing of the PBU message as described further
   below for bulk mode re-registrations.

   If the bulk registration flag in the PBU message is set to 1, the LMA
   MAY add the MN(s) indicated in the PBU to the set of MNs re-
   registered in a bulk mode, subject to the local policy.  The decision
   whether to enable bulk re-registration mode is a matter of local
   policy at the LMA and is outside the scope of this specification.

   If the LMA decides to accept the bulk re-registration mode for the
   MN, it SHALL add the MN to a bulk registration set.  Upon adding the
   MN to the bulk registration set, the LMA SHALL respond with the PBAck
   message containing the bulk registration flag set to 1.  The LMA
   SHALL include the Mobile Node Group Identifier option in the PBAck
   message.  The Mobile Node Group Identifier is allocated by the LMA
   and identifies the particular bulk set to which the MN is assigned.
   If however the LMA decides to reject the bulk re-registration mode
   for the MN, it SHALL proceed with regular registration as per the
   [RFC5213], and return a regular PBAck message with the bulk



Abinader, et al.         Expires April 28, 2011                [Page 16]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   registration set flag (B) set to 0.

   The PBU message without the MN ID and HNP options but including the
   Mobile Node Group Identifier mobility option is a valid message and
   indicates a request for bulk mode re-registration of all MNs that are
   members of the indicated bulk registration set.  There MAY be several
   Mobile Node Group Identifier options in the PBU message, in which
   case the MAG requests the bulk refreshment of all MNs that are
   members of the indicated bulk sets.  If there is a single Mobile Node
   Group Identifier option on the PBU message with all the field bits
   set to 1, as specified in Section 4.3, the MAG is requesting a
   lifetime refreshment of all the MNs attached to the MAG that are
   members of any bulk set.  Therefore, LMA SHALL extend the binding
   lifetime of all affected MNs attached to the MAG that sent the bulk
   PBU.

   The LMA SHALL set the binding lifetime of all MNs re-registered in a
   bulk mode to expire at the same point in time.

   Upon successful processing of bulk mode re-registration request, the
   LMA MUST respond with a PBAck message indicating success and echoing
   the mobility options received from the PBU.  The lifetime in the
   PBAck message indicates the time when binding cache entries of
   affected MNs will expire.  After successfully processing the bulk PBU
   message, the LMA SHALL start a single timer to oversee the binding
   lifetime of all MNs affected by this bulk re-registration
   transaction.

   The LMA not supporting this specification ignores the bulk re-
   registration flag (B) in a PBU message and processes the message as
   per the baseline specification [RFC5213].  In this case the PBAck
   message sent in response contains the bulk registration flag (B) set
   to 0.

   The LMA MAY reject the request for bulk re-registration.  In this
   case the LMA MUST NOT update binding cache entries of any MNs and
   SHALL respond with PBAck indicating the reason for the rejection in
   the status code.

   The LMA may receive a PBU message with the bulk registration flag (B)
   set to 1 and containing one or more mobile node group identifier
   option instances, but with the lifetime set to 0.  In this case, the
   LMA SHALL interpret this as a request by the MAG to terminate these
   bulk registration sets, and therefore the LMA SHALL expire the
   mobility bindings of all the MNs belonging to all the bulk
   registration sets specified in the PBU message and also extinguish
   the rbulk registration sets themselves.  Then, the LMA SHALL send a
   PBAck message to the MAG, reproducing all the mobility options



Abinader, et al.         Expires April 28, 2011                [Page 17]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   informed on the original PBU message, including the bulk registration
   flag (B) set to 1, the lifetime value set to zero and the Group I-Ds
   originally mentioned on the PBU message.

   The LMA itself may also decide unilaterally that one or more bulk
   registration sets may be terminated, in which case it shall expires
   the mobility bindings of all the MNs belonging to these bulk
   registration sets, extinguish the representations of these bulk
   registration sets and send a PBAck message to the MAG where the bulk
   re-registration flag (B) is set to 1, the lifetime value is set to
   zero and the Group I-Ds identifying bulk registration sets.  The
   reasons for the LMA deciding to terminate unilaterally the bulk
   registration sets may be implementation or domain specific, and
   therefore are outside the scope of this specification.


7.  IANA Considerations

   This specification specifies a new flag (B) in the Proxy Binding
   Update (PBU) and Proxy Binding Acknowledgement (PBAck) messages of
   PMIPv6 [RFC5213].  This flag is defined in Section 4.1 and
   Section 4.2.  IANA is requested to allocate the new flag (B) in the
   Proxy Binding Update and Proxy Binging Acknowledgement messages from
   the [RFC5213] Proxy Binding Update Flags and the [RFC5213] proxy
   Binding Acknowledgment Flags registries.

   This specification defines a new Mobility Header option, the Mobile
   Node Group Identifier option.  This option is described in Figure 3.
   The Type value for this option needs to be assigned from the same
   numbering space as allocated for the other mobility options (as
   defined in [RFC3775]).  Also, the Sub-type field of the Mobile Node
   Group Identifier option (as defined in Section 4.3) must have its own
   brand-new, unique number pace allocated and managed by IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   As per [RFC5213], the mobile node's identifier is always present in
   the Proxy Mobile IPv6 signaling messages, which exposes the
   identification of the user and may result in compromising the privacy
   of the user.  By additionally carrying the group identity of the
   mobile node on the PBU messages that perform bulk registration set
   addition operations, similar vulnerabilities are introduced.
   Specifically, it exposes the group affiliation of the user and may
   result in compromising the privacy of the user or the location



Abinader, et al.         Expires April 28, 2011                [Page 18]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   information.

   The Mobile Node Group Identifier option defined in this specification
   is for use in Proxy Binding Update and Proxy Binding Acknowledgement
   messages.  This option is carried like any other mobility header
   option as specified in [RFC3775] and does not require any special
   security considerations.

   The bulk re-registration mechanism does not introduce any new
   security threat or vulnerability to the PMIPv6 specification.


9.  Acknowledgements

   Thanks to Jouni Korhonen and Basavaraj Patil for their review and
   input.

   The authors would like to acknowledge the prior discussions on this
   topic in netlmm mailing list.


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.


Authors' Addresses

   Fuad Abinader (editor)
   Instituto Nokia de Tecnologia
   Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova
   Manaus, AM  69048-660
   BRAZIL

   Email: fuad.junior@indt.org.br









Abinader, et al.         Expires April 28, 2011                [Page 19]

Internet-Draft         PMIPv6 Bulk Re-registration          October 2010


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: sgundave@cisco.com
   URI:


   Kent Leung
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: kleung@cisco.com
   URI:


   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Fax:
   Email: suresh.krishnan@ericsson.com
   URI:


   Domagoj Premec
   Unaffiliated


   Email: domagoj.premec@gmail.com










Abinader, et al.         Expires April 28, 2011                [Page 20]


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