WDIFF

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

Internet Draft Nokia Siemens Networks
Intended status: Informational B. Patil
Expires: January September 2009 Nokia
S. Krishnan
Ericsson
July 14, 2008
March 9, 2009

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

Status of this Memo

By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she

This Internet-Draft is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
provisions of BCP 79.

This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC 78 and to translate it into
languages other than English. 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
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
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 14, September 9, 2009.

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 & Patil Expires January 14, September 9, 2009 [Page 1]

Internet-Draft PMIP6 PMIPv6 bulk re-registration July 2008

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 also
intended to be used by a MAG to re-establish bindings at a new LMA
when its old LMA fails.

Conventions used in this document

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 [RFC2119].

Table of Contents

1. Introduction...................................................3 Introduction...................................................2
2. Terminology....................................................4
3. Bulk Re-registration Overview..................................4
4. Message formats................................................6
4.1. Proxy Binding Update message..............................7 message..............................6
4.2. Proxy Binding Acknowledgment message......................8 message......................7
4.3. Bulk Set Identifier.......................................8
5. MAG Operation..................................................8
6. LMA operation.................................................10
7. Security Considerations.......................................12 Considerations.......................................11
8. IANA Considerations...........................................12
9. Acknowledgments...............................................12
10. References...................................................13 References...................................................12
10.1. Normative References....................................13
10.2. Informative References..................................13 References....................................12
Author's Addresses...............................................14
Intellectual Property Statement..................................14

Premec Expires January 14, 2009 [Page 2]

Internet-Draft PMIP6 bulk re-registration July 2008

Disclaimer of Validity...........................................15 Addresses...............................................13

1. Introduction

According to the

The Proxy Mobile IPv6 (PMIP6) (PMIPv6) specification [Gun2008], [RFC5213] defines a
netlmm
PMIPv6 domain is defined as a network which provides a network based IP mobility

Premec Expires September 9, 2009 [Page 2]

Internet-Draft PMIPv6 bulk re-registration March 2009

service by deploying the PMIP6 PMIPv6 protocol. A MAG performs the mobility
related signaling on behalf of a MN by sending the Proxy Binding
Update (PBU) message to a LMA. When the binding lifetime of a
particular MN is close to expiry, the MAG renews the registration of
the MN by sending a PBU message, to the LMA, requesting the extension
of the binding lifetime.

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.

A MAG requests adds a bulk re-registration for MN to a set of MNs by sending a
single PBU message with re-registered in a new bulk re-registration flag (B) set to 1.

Premec Expires January 14, 2009 [Page 3]

Internet-Draft PMIP6 mode by
setting the bulk re-registration July 2008

The LMA extends bit (B) in the binding lifetime of PBU message. A PBU
message with the B bit set may include multiple MNs that are currently
attached to that MAG and meet the criteria contained in the renewals
request. If no current binding cache entry exists, the LMA
creates new bindings for all the MNs listed in the bulk registration
message. The
LMA indicates success of a bulk re-registration by responding with a
PBAck PBU message with sent in response may contain the Bulk Set ID
mobility option (defined in section 4.3). The bulk re-registration flag (B) set to 1. By
using this method, ID is an
opaque identifier allocated by the MAG and LMA accomplish which uniquely identifies the re-registration
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 mobility option and
the LMA extends the binding lifetime of MNs that are members of the
received bulk set ID. 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 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 PMIP6 PMIPv6 specific terminology can be found in [Gun2008].

netlmm [RFC5213].

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

PMIP6 [RFC5213].

PMIPv6
Proxy Mobile IPv6 protocol specified in [Gun2008]. [RFC5213].

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

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 re-
registered in bulk mode. This 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 re-registration set is empty. MAG requests to add
individual MNs to this 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 re-registration registration
flag in the message is set

Premec Expires January 14, 2009 [Page 4]

Internet-Draft PMIP6 bulk re-registration July 2008 to 1. Based on the received bulk re-registration re-
registration bit the LMA adds the MN to the bulk re-registration set
and responds with the PBAck message with the bulk re-registration registration flag
(B) set to 1.

Once there is a non-empty bulk re-registration set, MAG can request
to extend the binding lifetime of some or for all MNs that are part of the bulk
re-registration set by sending a PBU message with bulk re-
registration flag set to 1 and omitting any options
that would identify an individual MN. In particular, the MAG may omit omits
both the MN ID (Mobile Node Identifier) option and the HNP (Home
Network Prefix) option in which case the MAG requests bulk re-registration of
all MNs in the bulk re-registration set. 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 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. PBU. In this case the MAG will split the MNs
across multiple PBUs. The receiving LMA can use the information
included in these bulk PBUs to recreate the bul bulk registration set, so
that the MAG can renew the MNs' lifetimes later with a single PBU.

There may be different triggers that cause the MAG to request a bulk
re-registration. Typically the trigger is the binding lifetime 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.

The

When the MAG may restrict requests the set of MNs MN to be added to which the request for bulk re-
registration applies by including additional re-registration
set, the LMA may include the Bulk Set ID mobility options option in the
PBU message PBAck
message. The bulk set ID is an opaque identifier allocated by the LMA
that act as a filter. In this case only those MNs from uniquely identifies the bulk re-registration set to which match the imposed restrictions
will be re-registered in a bulk mode. This filtering restriction is
valid only for MN was added. The
MAG associates the duration of MN with the current re-registration
transaction. The binding cache entries of MNs that are members of bulk re-registration set but not matching the filter will be left
unaffected. Following options may be used as a filter ID received in a bulk re-
registration request:

1. Mobile Node Identifier (MN ID) option
This the PBAck.

The MAG includes the Bulk Set ID mobility option can be used to select only MNs belonging to particular
domain, for example, by setting it set to "@example.com".

2. Home Network Prefix (HNP) option
This option can be used the value
previously received from the LMA to select MNs whose HNP matches request the
indicated prefix bulk re-registration
for the first Prefix Length bits.

Premec Expires January 14, 2009 [Page 5]

Internet-Draft PMIP6 MNs that are part of this particular bulk re-registration July 2008

3. Service Selection option [RFC5149]
This option can be used to select MNs whose Service Selection
option in the binding cache entry exactly matches
set. The MAG may include multiple instances of the requested
Service Selection Bulk Set ID option
in the PBU.

4. Vendor-Specific Mobility option [RFC5094]
This option can be used PBU message to select MNs whose Vendor-Specific option
in the binding cache entry matches the requested Vendor-Specific
option in the PBU.

If MN's binding cache entry does not match all of the filtering
options from the bulk re-registration request, then it is not
affected by this request lifetime refreshment for several bulk re-registration operation.
sets in a single message.

The LMA extends the mobility binding of all MNs from the bulk re-
registration set that meet the filtering criteria are members of
indicated bulk re-registration sets and responds with PBAck message with
echoing the received Bulk Set ID mobility options.

Premec Expires September 9, 2009 [Page 5]

Internet-Draft PMIPv6 bulk re-registration flag set to 1. The LMA
includes in its response the same mobility options that were included
in the request. 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.

Premec Expires January 14, 2009 [Page 6]

Internet-Draft PMIP6 bulk re-registration July 2008

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

A Proxy Binding Update message that is sent by a MAG to a LMA is referred
to as defined in the "Proxy Binding Update" message; it is defined in the
[Gun2008]. [RFC5213]. A new
flag (B) is included in defined for the Binding Update message.

Bulk Re-registration Registration Flag (B)

If the mobility options included in the message identify a single MN
and if the bulk re-registration 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 re-registration registration flag (B) is set to 0, then 0 and if the PBU
message MN is sent found to remove 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 flag (B) is set to 1 and the included
mobility options do not identify a single MN, then the PBU message is
a request to extend the lifetime of the MNs contained in the bulk re-
registration set and whose binding cache entries match the mobility
options from the message. March 2009

Mobility Options

For descriptions of these the mobility options, refer to [Gun2008]. [RFC5213]. When
the bulk
re-registration registration flag is set to 1, the PBU message without Mobile Node
Identifier option and/or without containing
multiple MN ID and HNP option options is valid and is processed as described
in section 3.

Premec Expires January 14, 2009 [Page 7]

Internet-Draft PMIP6 When set to refresh binding in a bulk re-registration July 2008 mode, the PBU
message contains at least one Bulk Set ID 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 that is sent by a LMA to a MAG is
referred to as the "Proxy Binding Acknowledgment" message; it is defined in the [Gun2008]. [RFC5213]. A
new flag (B) is included in defined for the Binding Acknowledgment message.

Bulk Re-registration Registration Flag (B)

A new flag (B) is included in the Binding Acknowledgment message to
indicate to the MAG that the requested MN was successfully added to the bulk
re-registration operation
was successful. 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 [Gun2008]. [RFC5213]. When the bulk
re-registration
registration flag was is set to 1 in the PBU message and Mobile Node
Identifier option and/or HNP option were not included, message, then the PBAck
message is may also sent without those contain the Bulk Set ID mobility options as described in
section 3.

5. MAG Operation option. When a new MN attaches to a MAG, the MAG SHALL register the MN with
the LMA by sending the PBU message formatted as described in
[Gun2008]. Additionally, the MAG MAY set the bulk re-registration

Premec Expires January 14, September 9, 2009 [Page 8] 7]

Internet-Draft PMIP6 PMIPv6 bulk re-registration July 2008 March 2009

Bulk Set ID mobility were included in the PBU message, the PBAck
message echoes back the Bulk Set ID options from the PBU message.

4.3. Bulk Set Identifier

The format of the Bulk Set ID option is as shown below and its
alignment requirement is 4n+2.

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bulk Set ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Bulk Set ID Mobility Option

Type: TBD, uniquely identifies the option as the Bulk Set ID
mobility option.

Length: 0 or 4

Bulk set ID: a 32-bit unsigned integer that identifies a bulk
re-registration set.

The Bulk Set ID option is valid in the Proxy Binding Update and Proxy
Binding Acknowledgment messages. The semantics of the Bulk Set ID
option is defined in section 3.

5. MAG Operation

When a new MN attaches to a MAG, the MAG SHALL register 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 set of MNs re-registered in a
bulk mode. 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 add the MN to its bulk re-registration set when it
receives a PBAck message with the bulk re-registration 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 MAG SHALL associate the MN being
registered with the indicated bulk set identifier.

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 with a bulk re-
registration flag set to 1. Mobility options containing the Bulk Set ID
mobility option. The length of the Bulk Set ID option may be 0 in such PBU message
SHALL NOT identify an individual MN.

In addition,
which case the MAG MAY trigger is requesting a bulk re-registration at any time.
The policy and exact conditions for these additional triggers are
outside of scope refreshment of this specification.

A MAG MAY omit HNP and the binding
lifetime for all MN ID options from a PBU message requesting
bulk re-registration.

A attached to that MAG MAY that were registered with
the B flag set. Alternatively, the MAG may include mobility one or more Bulk
Set ID options containing the values that were indicated by the LMA
in a PBU requesting a bulk re-
registration the PBAck messages when the MN was added to restrict the set of MNs updated by this transaction. bulk set. In this
case the set MAG asks for refreshment of MNs affected by this specific bulk re-registration
operation is sets indicated by
the subset of MNs contained in a bulk re-registration
set whose binding cache entries match Bulk Set ID options. The MAG SHALL NOT include the mobility MN ID and the
HNP options included in the PBU message, as described in section 3. 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.

When the MAG receives a PBAck message indicating success with and which
echoes the
bulk re-registration bit set to 1 Bulk Set ID options that were included in response to a PBU message
requesting the bulk re-registration,
corresponding PBU message, the MAG SHALL update the binding lifetime
of all affected MNs to the lifetime value contained in the PBAck
message. If in the case of bulk re-registration the PBAck message
repeatedly indicates an error, the MAG SHALL fall back to individual
re-registration mode.

Premec Expires January 14, 2009 [Page 9]

Internet-Draft PMIP6 bulk re-registration July 2008

After successfully processing the PBAck message indicating successful
re-registration in bulk 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 attached MNs served by the LMA to
which it sent the that are members of that bulk PBU message. registration set.

If the MAG sets the bulk re-registration bit to 1 in a PBU message
but the bulk re-registration registration bit (B) is set to 0 in a PBAck message, the
MAG SHALL process the PBAck message as per [Gun2008]. [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 [Gun2008]. [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.

If the PBAck message indicates success and it contains the MN ID and
HNP options, the MAG SHALL update the binding of the MN indicated by
the MN ID and HNP options, regardless of the value of the bulk re-
registration bit (B) in the PBAck message.

6. LMA operation

When the LMA receives a PBU message with a bulk re-registration registration bit (B)
set to 1 and if the message contains MN ID and/or HNP options
identifying a single MN, 1, the LMA SHALL first process the PBU message as per [Gun2008].
[RFC5213]. Upon successful processing of the message, if the
bulk re-registration flag is set in the message, the LMA SHALL
continue
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 and
if included mobility options identify a single MN, 1, the
LMA MAY add the MN MN(s) indicated in the PBU to the set of MNs re-registered re-
registered in a bulk mode, subject to the local policy. The decision
whether to enable bulk re-registration mode for a MN is a matter of local
policy at the LMA and is outside the scope of this specification.

Premec Expires January 14, 2009 [Page 10]

Internet-Draft PMIP6 bulk re-registration July 2008

If the LMA decides to accept the bulk re-registration mode for the
MN, it SHALL add the MN to the a bulk re-registration set. The LMA SHALL
maintain the distinct bulk re-registration re-registrations set per 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 PBU message with LMA may include the Bulk Set ID option in the PBAck
message. The bulk set ID is allocated by the LMA and identifies the
particular bulk re-registration bit (B) set to 1 but which the MN is assigned.

The PBU message without the MN ID and HNP options but including the
Bulk Set ID 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.

If There MAY be several Bulk Set
ID options in the PBU message, in which case the MAG requests the
bulk re-registration flag (B) refreshment of all MNs that are members of the indicated bulk
sets. If the length of the Bulk Set ID option is set in zero, the PBU message and
included mobility options do not identify an individual MN, 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. The affected MNs are those MNs that are
members of a

Premec Expires September 9, 2009 [Page 10]

Internet-Draft PMIPv6 bulk re-registration set and whose binding cache entries
match the mobility options included in the bulk PBU message. The
valid mobility options and their semantics are described in section
3. March 2009

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

The LMA SHOULD copy the mobility options from the bulk re-
registration request into the PBAck message sent in response.

Upon successful processing of bulk mode re-registration request, the
LMA MUST respond with a PBAck message indicating success and it
SHOULD set echoing
the bulk re-registration bit (B) to 1. 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 where the bulk re-registration bit is set to 1 and
the status code indicates the reason for rejection.

After successfully processing the bulk PBU message, the LMA MAY start
a single timer to oversee the binding lifetime of all MNs affected by
this bulk re-registration transaction.

When the LMA receives a PBU message requesting a (re-)registration of
a single MN from a MAG that successfully executed a bulk re-
registration procedure before and the lifetime of that bulk re-

Premec Expires January 14, 2009 [Page 11]

Internet-Draft PMIP6 bulk re-registration July 2008

registration is not expired yet, the LMA MAY set the lifetime in the SHALL
respond with PBAck message to match indicating the remaining lifetime of reason for the MNs contained rejection in the
status code.

After successfully processing the bulk re-registration set. As a result PBU message, the LMA is not required to SHOULD
start a separate single timer to oversee the binding lifetime of all MNs
affected by this MN. bulk re-registration transaction.

The LMA not supporting this specification ignores the bulk re-
registration bit (B) and the Bulk Set ID option in a PBU message and
processes the message as per the baseline specification [Gun2008]. [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
[Gun2008].
[RFC5213].

7. Security Considerations

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

Premec Expires September 9, 2009 [Page 11]

Internet-Draft PMIPv6 bulk re-registration March 2009

8. IANA Considerations

None.

9. Acknowledgments

Thanks to Jouni Korhonen for his review and input.

This document was prepared using 2-Word-v2.0.template.dot.

Premec Expires January 14, 2009 [Page 12]

Internet-Draft PMIP6 bulk re-registration July 2008

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

[Gun2008]

[RFC5213] Gundavelli, S., Ed., "Proxy Mobile IPv6", May 2008, draft-
ietf-netlmm-proxymip6-18.txt

10.2. Informative References

[RFC5149] J. Korhonen, U. Nilsson, V. Devarapalli, "Service Selection
for Mobile IPv6", RFC 5149, February 5213, August
2008

[RFC5094] V. Devarapalli, A. Patel, K. Leung, "Mobile IPv6 Vendor
Specific Option", RFC 5094, December 2007

Premec Expires January 14, September 9, 2009 [Page 13] 12]

Internet-Draft PMIP6 PMIPv6 bulk re-registration July 2008 March 2009

Author's Addresses

Domagoj Premec
Nokia Siemens Networks
Heinzelova 70a
10000 Zagreb
Croatia

Email: domagoj.premec.ext@nsn.com

Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA

Email: basavaraj.patil@nokia.com

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

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

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this

Premec Expires January 14, 2009 [Page 14]

Internet-Draft PMIP6 bulk re-registration July 2008

specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Premec Expires January 14, September 9, 2009 [Page 15] 13]

----