WDIFF

draft-premec-netlmm-bulk-re-registration-02.txt --> draft-premec-netlmm-bulk-re-registration-03.txt

NetLMM Working Group D. Premec
Internet Draft Nokia Siemens Networks
Internet-Draft
Intended status: Informational B. Patil Standards Track S. Gundavelli
Expires: September 2009 Nokia April 10, 2010 K. Leung
Cisco
S. Krishnan
Ericsson
March 9,
B. Patil
Nokia
October 7, 2009

Bulk Re-registration for Proxy Mobile IPv6
draft-premec-netlmm-bulk-re-registration-02.txt
draft-premec-netlmm-bulk-re-registration-03

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 9, 2009. April 10, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Premec

Premec, et al. Expires September 9, 2009 April 10, 2010 [Page 1]

Internet-Draft PMIPv6 bulk re-registration March Bulk Re-registration October 2009

Abstract

The

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 mechanism is document also
intended to
specifies a new mobility option that can be used by the mobility
entities in a MAG to re-establish bindings at Proxy Mobile IPv6 domain for carrying the group
affiliation of a new LMA
when its old LMA fails.

Conventions used mobile node in this document 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].

Premec, et al. Expires April 10, 2010 [Page 2]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

Table of Contents

1. Introduction...................................................2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology....................................................4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Bulk Re-registration Overview..................................4 Overview . . . . . . . . . . . . . . . . 5
3.1. Motivation for bulk re-registration . . . . . . . . . . . 5
3.2. Bulk re-registration operation . . . . . . . . . . . . . . 6
4. Message formats................................................6 formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Proxy Binding Update message..............................6 message . . . . . . . . . . . . . . . 7
4.2. Proxy Binding Acknowledgment message......................7 message . . . . . . . . . . . 8
4.3. Bulk Set Identifier.......................................8 Mobile Node Group Identifier Option . . . . . . . . . . . 9
5. MAG Operation..................................................8
6. LMA operation.................................................10
7. Security Considerations.......................................11
8. IANA Considerations...........................................12
9. Acknowledgments...............................................12
10. References...................................................12
10.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 10
6. LMA operation . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References....................................12
Author's Addresses...............................................13 References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Premec, et al. Expires April 10, 2010 [Page 3]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

1. Introduction

The Proxy Mobile IPv6 (PMIPv6) base specification [RFC5213] uses the mobile
node identifier in the mobility signaling messages for identifying
the mobile node. However, the signaling messages lack the capability
to identify a set of mobile nodes which have a common characteristic.
A group identifier associated with a mobile node enables the ability
to perform protocol operation on a set of mobile nodes via a single
transaction. The group identifier provides a more optimal mechanism
for protocol operation which would otherwise require multiple atomic
transactions on a per 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
service, all the mobile node sessions anchored on a given card can
be part of one single group. When there is a failure on a
specific card, the local mobility anchor can initiate the
revocation signaling to the mobile access gateway by sending a
sending a single revocation request carrying the group identifier.

o For periodic re-registrations, the mobile access gateway may send
a single re-registration message for each of the mobile nodes'
groups and perform re-registrations for all the mobile node's that
are part of that group.

o The mobile access gateway or the local mobility anchor in a proxy
mobile IPv6 domain may choose to revoke the registration of mobile
node associated with a specific realm. In such cases the mobile
access gateway or the local mobility anchor can perform the
binding revocation signaling using the group ID associated with a
specific set of mobile nodes.

The remeinder of this document defines a
PMIPv6 domain as new mobility option, Mobile
Node Group Identifier option, that can be used by a network which provides local mobility
anchor and a network based IP 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

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

Premec, et al. Expires September 9, 2009 April 10, 2010 [Page 2] 4]

Internet-Draft PMIPv6 bulk re-registration March Bulk Re-registration October 2009

service by deploying the

PMIPv6 protocol. A MAG performs domain
Network providing the network based IP mobility
related signaling on behalf of a MN by sending the service as defined
in [RFC5213].

PMIPv6
Proxy Binding
Update (PBU) Mobile IPv6 protocol specified in [RFC5213].

Bulk re-registration
PBU/PBAck message to a LMA. When exchange where the binding lifetime of a
particular MN bulk re-registration flag (B)
is close set to expiry, the MAG renews the registration 1

Bulk re-registration set
a set of
the MN MNs identifed by sending a PBU message, to the LMA, requesting the extension
of Mobile Node Group ID option to which
the binding lifetime.

A bulk re-registration operation applies.

3. Bulk Re-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 more attached 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 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 it is apparent that the default re-
registration process where the MAG sends a 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 network bandwidth. In addition, since
the registration messages are sent per MN, there is no efficient way
for the MAG to recover from the failure of an LMA. It needs to resend
registration messages for each MN attached to it, towards a new LMA.
This increases the service disruption interval.

This document proposes an optimization of the 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 re-
registered in a bulk mode by setting the bulk re-registration bit (B)
in the PBU message. A PBU
message with the B bit set may include multiple MNs and the LMA
creates new bindings for all the MNs listed in the bulk registration
message. The PBU message sent in response may contain contains the

Premec, et al. Expires April 10, 2010 [Page 5]

Internet-Draft PMIPv6 Bulk Set ID Re-registration October 2009

Mobile Node Group Identifier mobility option (defined which is defined later
in section 4.3). The this document. In the context of bulk set ID 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.

Premec Expires September 9, 2009 [Page 3]

Internet-Draft PMIPv6 bulk re-registration March 2009

A MAG requests a bulk re-registration for a set of MNs by sending a
single PBU message which includes a Bulk Set ID Mobile Node Group Identifier
mobility option and the LMA extends the binding lifetime of MNs that
are members of the
received bulk set ID. that group. By using this method, the MAG and LMA
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.

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 re-registration set to monitor the binding
lifetime of all the member MNs instead of an individual timer per MN.

2. Terminology

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

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

PMIPv6
Proxy Mobile IPv6 protocol specified in [RFC5213].

3.2. Bulk re-registration
PBU/PBAck message exchange where the bulk re-registration flag
(B) is set to 1.

bulk re-registration set
a set containing the MNs to which the request for bulk
re-registration applies.

3. Bulk Re-registration Overview 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 re-registration
set and is a subset of the MNs attached to a MAG. There can be
multiple bulk re-registration sets for a given MAG-LMA pair.
Initially the bulk re-registration set is empty. MAG requests to add
individual MNs to the bulk set by sending a regular PBU message that

Premec Expires September 9, 2009 [Page 4]

Internet-Draft PMIPv6 bulk re-registration March 2009
identifies an individual MN and additionally the bulk registration
flag in the message is set to 1. Based on the received bulk re-
registration bit the LMA adds the MN to the bulk re-registration set
and responds with the PBAck message with the bulk registration flag
(B) set to 1. The LMA identifies the bulk re-registration set to
which the MN was added by including the Mobile Node Group ID option
in the PBAck message.

Once there is a non-empty bulk re-registration set, MAG can request
to extend the binding lifetime for all MNs that are part of the bulk
re-registration set by sending a PBU message and omitting any options
that would identify an individual MN. In particular, the MAG omits
both the MN ID (Mobile Node Identifier) option and the HNP (Home
Network Prefix) options.

If the bulk registration message is being sent to recover from an LMA
failure the MAG MUST explicitly identify all the MNs that are
included in with the bulk registration (B) bit
set and provide all the mobility
options that need to be included in an initial PBU. Due to the size
of these options, the MAG may not be able to fit all the MNs attached
to it into a single PBU. In this case the MAG will split the MNs
across multiple PBUs. The receiving LMA can use by including the information
included in these bulk PBUs to recreate Mobile Node Group ID identifiy the bulk re-
registration set, so set. Such PBU message lacks any options that identify
an individual MN. In particular, the MAG can renew omits both the MNs' lifetimes later with a single PBU. MN ID
(Mobile Node Identifier) and the HNP (Home Network Prefix) options.

There may be different triggers that cause the MAG to request a bulk
re-registration. Typically the trigger is the binding lifetime

Premec, et al. Expires April 10, 2010 [Page 6]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

expiry of a MN that is a member of a bulk re-registration set. There
could be other triggers as well, but they may be implementation or
domain specific and outside the scope of this specification.

When the MAG requests the MN to be added to the bulk re-registration
set, the LMA may include includes the Bulk Set ID Mobile Node Group Identifier mobility
option in the PBAck message. The bulk set ID Mobile Node Group Identifier is an
opaque identifier allocated by the LMA that uniquely identifies the
bulk set at the LMA to which the MN was added. The MAG associates
the MN with the bulk set ID Mobile Node Group Identifier received in the PBAck.

The MAG includes the Bulk Set ID Mobile Node Group Identifier mobility option set
to the value previously received from the LMA to request the bulk re-registration re-
registration for the MNs that are part of this particular bulk re-registration re-
registration set. The MAG may include multiple instances of the Bulk Set ID
Mobile Node Group Identifier option in the PBU message to request
lifetime refreshment for several bulk sets in a single message.

The LMA extends the mobility binding of all MNs that are members of
indicated bulk re-registration sets and responds with PBAck message
echoing the received Bulk Set ID Mobile Node Group Identifier mobility options.

Premec Expires September 9, 2009 [Page 5]

Internet-Draft PMIPv6 bulk re-registration March 2009

A MAG may remove a MN from a bulk re-registration set by sending a
regular PBU message identifying the MN to be removed and with the
bulk re-registration flag set to 0.

When requested to add a MN to the bulk re-registration set, the LMA
may reject the request. In this case the LMA processes the PBU
message as if the bulk re-registration flag was not set and responds
with PBAck message where the bulk re-registration flag is set to 0.

4. Message formats

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

4.1. Proxy Binding Update message

Premec, et al. Expires April 10, 2010 [Page 7]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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 Proxy Binding Update message

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

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 re-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 re-registration set, then the MN is removed from
the bulk re-registration set.

Premec Expires September 9, 2009 [Page 6]

Internet-Draft PMIPv6 bulk re-registration March 2009

Mobility Options

For descriptions of the mobility options, refer to [RFC5213]. When
the bulk registration flag is set to 1, the PBU message containing
multiple MN ID and HNP options is valid and is processed as described
in section 3. When set sent to refresh binding bindings in a bulk mode, the PBU
message contains MUST contain at least one Bulk Set ID Mobile Node Group Identifier
mobility option and does not contain the MN-ID and the HNP mobility
options.

4.2. Proxy Binding Acknowledgment message

Premec, et al. Expires April 10, 2010 [Page 8]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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 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.

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

For descriptions of these options, refer to [RFC5213]. When the bulk
registration flag is set to 1 in the PBU message, then the PBAck
message may MUST also contain the Bulk Set ID Mobile Node Group Identifier mobility
option. When the

Premec Expires September 9, 2009 [Page 7]

Internet-Draft PMIPv6 bulk re-registration March 2009

Bulk Set ID Mobile Node Group Identifier mobility option(s)
were included in the PBU message, the PBAck message echoes back the Bulk Set ID
Mobile Node Group Identifier options from the PBU message.

4.3. Bulk Set Mobile Node Group Identifier Option

A new option, Mobile Node Group Identifier

The format of the Bulk Set ID option is as shown below defined for
using it in Proxy Binding Update and its 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+2. 4n.

Premec, et al. Expires April 10, 2010 [Page 9]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bulk Set ID Mobile Node Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Bulk Set ID Mobility Mobile Node Group Identifier Option

Type: TBD, uniquely identifies

Type
<IANA>

Length
8-bit unsigned integer indicating the option as length in octets of the Bulk Set ID
mobility option.

Length: 0 or 4

Bulk
option, excluding the type and length fields. The value for this
field MUST be set ID: a to 6.

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

Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.

Mobile Node Group Identifier A 32-bit unsigned integer that identifies a bulk
re-registration set. field containing the mobile
node's group identifier.

The Bulk Set ID Mobile Node's Group Identifier option reflects the group
affiliation that is valid in local to the Proxy LMA or MAG, as determined by those
respective entities.

5. MAG Operation

The conceptual Binding Update and Proxy
Binding Acknowledgment messages. The semantics List entry data structure maintained by
the MAG, described in Section 6.1 of [RFC5213], MUST be extended to
store the Bulk Set ID mobile node's group identifier.

The Mobile Node Group Identifier option is defined MAY be used in section 3.

5. the PBU
message sent by the MAG Operation to the LMA. 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 SHALL register registers the MN with the
LMA by sending the PBU message formatted as described in [RFC5213].

Premec, et al. Expires April 10, 2010 [Page 10]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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 re-
registration re-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 maintain a separate bulk re-registration sets for each
LMA.

The MAG SHALL add the MN to its bulk re-registration set when it
receives a PBAck message with the bulk registration bit set to 1 and
if the corresponding PBU message was requesting the LMA to add the MN
to the bulk re-registration set. The MAG SHALL maintain a separate
bulk re-registration set for each LMA. If the PBAck message contains

Premec Expires September 9, 2009 [Page 8]

Internet-Draft PMIPv6 bulk re-registration March 2009

the Bulk Set ID option, the bulk re-registration set. The MAG SHALL associate the MN
being registered with the indicated bulk set identifier. Mobile Node Group Identifier received in
the PBAck message.

When the binding lifetime of any MN contained in the bulk re-
registration set is about to expire, the MAG SHALL request the bulk
re-registration by sending the PBU message containing the Bulk Set ID Mobile Node
Group Identifier mobility option. The length of the Bulk Set ID Mobile Node
Group Identifier option may be 0 in which case the MAG is requesting
a refreshment of the binding lifetime for all MN attached to that MAG
that were registered with the B flag set. Alternatively, the MAG may MAY
include one or more Bulk
Set ID 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 Bulk Set ID Mobile Node Group
Identifier options. The MAG SHALL NOT include the MN ID and the HNP
options in the PBU message requesting bulk refreshment.

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

If the bulk registration message is being sent to recover from an LMA
failure the MAG MUST explicitly identify all the MNs that are
included in the bulk registration set and provide all the mobility
options that need to be included in an initial PBU. Due to the size
of these options, the MAG may not be able to fit all the MNs attached
to it into a single BU. In this case the MAG MUST split the MNs
across multiple BUs.

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

Instead of maintaining one timer per MN, the MAG MAY start a single
timer per bulk registration set to oversee the binding lifetime of
all MNs that are members of that bulk registration set.

If the MAG sets the bulk re-registration bit to 1 in a PBU message
but the bulk registration bit (B) is set to 0 in a PBAck message, the

Premec, et al. Expires April 10, 2010 [Page 11]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

MAG SHALL process the PBAck message as per [RFC5213]. In addition,
the MAG SHALL infer that the LMA does not support bulk re-
registration procedure. The MAG SHALL switch to regular, per-MN re-
registration mode as described in [RFC5213]. The MAG MAY retry the

Premec Expires September 9, 2009 [Page 9]

Internet-Draft PMIPv6 bulk re-registration March 2009
bulk re-registration procedure after sufficient time has elapsed from
the previous unsuccessful bulk re-registration. This amount of time
SHOULD be configurable at the MAG.

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 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 mobile node's
group identifier, local to the local mobility anchor.

When the LMA receives a PBU message with a bulk registration bit (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 PBU message contains multiple MNIDs and/or HNP options, and
the LMA cannot find a matching binding cache entry, the LMA MUST
consider this to be equivalent to receiving multiple PBUs with one
MNID and/or HNP option each.

If the bulk re-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 re-registration set. The LMA SHALL
maintain distinct bulk re-registrations set per for each MAG and there
could be several such sets per single MAG.

Upon adding the MN to the bulk re-registration set, the LMA SHALL
respond with the PBAck message containing the bulk registration bit
set to 1. The LMA may SHALL include the Bulk Set ID Mobile Node Group Identifier
option in the PBAck message. The bulk set ID Mobile Node Group Identifier is
allocated by the LMA and identifies the particular bulk set to which
the MN is assigned.

The PBU message without the MN ID and HNP options but including the
Bulk Set ID
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 re-registration set. There MAY be several

Premec, et al. Expires April 10, 2010 [Page 12]

Internet-Draft PMIPv6 Bulk Set
ID Re-registration October 2009

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 the length of the Bulk Set ID Mobile Node
Group Identifier option is zero, the MAG is requesting a lifetime
refreshment of all the MN attached to the MAG that are members of any
bulk set. The LMA SHALL extend the binding lifetime of all affected
MNs attached to the MAG that sent the bulk PBU.

Premec Expires September 9, 2009 [Page 10]

Internet-Draft PMIPv6 bulk re-registration March 2009

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.

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.

After successfully processing the bulk PBU message, the LMA SHOULD
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 bit (B) and the Bulk Set ID Mobile Node Group Identifier option 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 re-
registration re-registration bit (B) is set to 0.

If the LMA that does not support this specification receives a bulk
PBU message that does not contain any options identifying a
particular MN then the LMA responds with the PBAck message where the
status field contains one of the following error codes:

MISSING_HOME_NETWORK_PREFIX_OPTION

MISSING_MN_IDENTIFIER_OPTION

These error codes are defined in the baseline specification
[RFC5213].

7. IANA Considerations

This specification defines a new Mobility Header option, the Mobile

Premec, et al. Expires April 10, 2010 [Page 13]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

Node Group Identifier option. This option is described in section
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].

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

8. Security Considerations

The mobile node's identifier is always present in the Proxy Mobile
IPv6 signaling messages and additionally carrying the group identity
of the mobile node introduces similar vulnerabilities. Specifically,
it exposes the group affiliation of the user and may result in
compromising the privacy of the user or the location 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.

Premec Expires September 9, 2009 [Page 11]

Internet-Draft PMIPv6 bulk re-registration March 2009

8. IANA Considerations

None.

9. Acknowledgments Acknowledgements

Thanks to Jouni Korhonen for his review and input.

This

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

Earlier versions of this document was were prepared using 2-Word-v2.0.template.dot. 2-Word-
v2.0.template.dot.

10. References

10.1. 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, J., "Mobility Support
in IPv6", RFC 3775, June 2004.

Premec, et al. Expires April 10, 2010 [Page 14]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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

Premec Expires September 9, 2009 [Page 12]

Internet-Draft PMIPv6 bulk re-registration March 2009

Author's 2008.

10.2. Informative References

Authors' Addresses

Domagoj Premec
Nokia Siemens Networks
Heinzelova 70a
10000 Zagreb
Croatia

Email: domagoj.premec.ext@nsn.com

Basavaraj Patil
Nokia
6000 Connection domagoj.premec@gmail.com

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

Phone:
Fax:
Email: basavaraj.patil@nokia.com sgundave@cisco.com
URI:

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

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

Premec, et al. Expires April 10, 2010 [Page 15]

Internet-Draft PMIPv6 Bulk Re-registration October 2009

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

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

Premec
URI:

Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA

Phone:
Fax:
Email: basavaraj.patil@nokia.com
URI:

Premec, et al. Expires September 9, 2009 April 10, 2010 [Page 13] 16]

----