One document matched: draft-ietf-netext-bulk-re-registration-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-netext-bulk-re-registration-02"
ipr="trust200902">
<front>
<title abbrev="PMIPv6 Bulk Re-registration">Bulk Re-registration for Proxy
Mobile IPv6</title>
<author role="editor" fullname="Fuad Abinader" initials="F." surname="Abinader">
<organization>Instituto Nokia de Tecnologia</organization>
<address>
<postal>
<street>Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova</street>
<city>Manaus</city>
<region>AM</region>
<code>69048-660</code>
<country>BRAZIL</country>
</postal>
<email>fuad.junior@indt.org.br</email>
</address>
</author>
<author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sgundave@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Kent Leung" initials="K." surname="Leung">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>kleung@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<code></code>
<country>Canada</country>
</postal>
<phone>+1 514 345 7900 x42871</phone>
<facsimile></facsimile>
<email>suresh.krishnan@ericsson.com</email>
<uri></uri>
</address>
</author>
<author fullname="Domagoj Premec" initials="D." surname="Premec">
<organization>Unaffiliated</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<email>domagoj.premec@gmail.com</email>
</address>
</author>
<date year="2010" />
<area>Internet Area</area>
<workgroup>Netext Working Group</workgroup>
<keyword>Proxy Mobile IPv6</keyword>
<keyword>PMIPv6</keyword>
<keyword>bulk registrations</keyword>
<keyword>MN group ID</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Proxy Mobile IPv6 (PMIPv6) base specification <xref target="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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
</section>
<section title="Terminology">
<t>General mobility related terminology is defined in <xref
target="RFC3775"></xref>. Additional PMIPv6 specific terminology can be
found in <xref target="RFC5213"/>.</t>
<t><list style="hanging">
<t hangText="PMIPv6"><vspace blankLines="0" />Proxy Mobile IPv6
protocol, as specified in <xref target="RFC5213"/>.</t>
<t hangText="PMIPv6 domain"><vspace blankLines="0" />Network
providing the network based IP mobility service as defined in <xref
target="RFC5213"/>.</t>
<t hangText="Group Identifier"><vspace blankLines="0" />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.</t>
<t hangText="Bulk registration"><vspace
blankLines="0" />Operation involving the exchange of PBU/PBAck messages
where the bulk registration flag (B) is set to 1.</t>
<t hangText="Bulk registration set"><vspace blankLines="0" />A
set of MNs identified by the Mobile Node Group Identifier option to
which the bulk registration operation applies.</t>
</list></t>
</section>
<section anchor="overview" title="Bulk Registration Overview">
<section title="Motivation for bulk re-registration">
<t>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:</t>
<t>transactions/sec = (number of registered MNs) / (binding
lifetime*4)</t>
<t>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</t>
<t>Based on the above formula and example scenario it is apparent that
the default PMIPv6 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 in terms of network bandwidth.</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
</section>
<section title="Bulk re-registration operation">
<t>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.</t>
<t>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 also take a
unilateral decision to remove the MN, as specified later in this
specification.</t>
<t>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.</t>
<t>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 <xref target="mnid_option"/>.</t>
<t>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.</t>
<section title="BULK_ADD_MN operation" anchor="BULK_ADD_MN">
<t>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.</t>
<t>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
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.</t>
</section>
<section title="BULK_REMOVE_MN operation" anchor="BULK_REMOVE_MN">
<t>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.</t>
<t>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 <xref target="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.</t>
</section>
<section title="BULK_REREG_SET operation" anchor="BULK_REREG_SET">
<t>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.</t>
<t>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 <xref target="mnid_option"/>
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.</t>
<t>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.</t>
</section>
<section title="BULK_TERMINATE_SET operation" anchor="BULK_TERMINATE_SET">
<t>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
<xref target="mnid_option"/> for more information).</t>
<t>Upon receive of such PBU message indicating a bulk registration 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.</t>
<t>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 <xref target="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.</t>
</section>
</section>
</section>
<section title="Message formats">
<t>This section introduces extensions to PBU and PBAck messages used in
this specification.</t>
<section title="Proxy Binding Update message" anchor="pbu_message">
<figure anchor="PBU-format">
<artwork><![CDATA[ 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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>A Proxy Binding Update message is defined in the <xref target="RFC5213"/>.
A new flag (B) is defined for the Binding Update message, as seen on
<xref target="PBU-format"/>, while the other remaining fields (i.e.
Sequence #, flags and Lifetime) keep their definition as per defined
in the <xref target="RFC5213"/>.</t>
<t>Bulk Registration Flag (B)</t>
<t>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.</t>
<t>Mobility Options</t>
<t>For descriptions of the mobility options, refer to <xref
target="RFC5213"></xref>. 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.</t>
</section>
<section title="Proxy Binding Acknowledgment message" anchor="pback_message">
<figure anchor="PBAck-message"
title="Proxy Binding Acknowledgment message">
<artwork><![CDATA[ 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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>A Proxy Binding Acknowledgment message is defined in the <xref
target="RFC5213"/>. A new flag (B) is defined for the Binding
Acknowledgment message, as seen on <xref target="PBAck-message"/>.</t>
<t>Bulk Registration Flag (B)</t>
<t>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.</t>
<t>Mobility Options</t>
<t>These are the original PMIPv6 mobility options as defined in
<xref target="RFC5213"/>. Additionally, at least one instance of the Mobile Node
Group Identifier mobility option (see <xref target="mnid_option"/>) 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.<xref target="RFC5213"/>.</t>
</section>
<section title="Mobile Node Group Identifier Option " anchor="mnid_option">
<t>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.</t>
<t>The alignment requirement for this option is 4n.</t>
<figure anchor="GID_option"
title="Mobile Node Group Identifier Option">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="0" /><IANA></t>
<t hangText="Length"><vspace blankLines="0" />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.</t>
<t hangText="Sub-type"><vspace blankLines="0" />Identifies the
specific group type. This number space will be managed by the
IANA.</t>
<t hangText="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.</t>
</list>
<t>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.</t>
</t>
</section>
</section>
<section title="MAG Operation">
<t>The conceptual Binding Update List entry data structure maintained by
the MAG, described in Section 6.1 of <xref target="RFC5213"/>, MUST be
extended to store the mobile node's group identifier. The MAG SHALL maintain
separate bulk registration sets for each LMA.</t>
<t>Bulk re-registration operations are optional to PMIPv6 <xref
target="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.</t>
<t>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 <xref target="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.</t>
<t>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.</t>
<t>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 registration flag (B) is set to 0 in a PBAck message,
the MAG SHALL process the PBAck message as per <xref target="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 <xref target="RFC5213"/>, and
MAY NOT retry bulk registration set additions to that LMA unless
an administrative action is taken.</t>
<t>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 <xref target="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.</t>
<t>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 <xref
target="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 <xref target="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 <xref target="RFC5213"/>.<t>
</t>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.</t>
<t>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.</t>
<t>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 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 <xref target="mnid_option"/>. In any case, the MAG SHALL NOT
include the MN ID and the HNP options in the PBU message requesting bulk
refreshment.</t>
<t>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.</t>
<t>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.</t>
<t>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
<xref target="mnid_option"/> for more information).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="LMA operation">
<t>The conceptual Binding Cache entry data structure maintained by the
LMA, described in Section 5.1 of <xref target="RFC5213"></xref>, 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.</t>
<t>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.</t>
<t>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 <xref
target="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.</t>
<t>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.</t>
<t>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 <xref target="RFC5213"/>, and return a regular
PBAck message with the bulk registration set flag (B) set to 0.</t>
<t>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
<xref target="mnid_option"/>, 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.</t>
<t>The LMA SHALL set the binding lifetime of all MNs re-registered in a
bulk mode to expire at the same point in time.</t>
<t>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.</t>
<t>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 <xref target="RFC5213"></xref>. In this case
the PBAck message sent in response contains the bulk registration flag
(B) set to 0.</t>
<t>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.</t>
<t>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
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.</t>
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification specifies a new flag (B) in the Proxy Binding
Update (PBU) and Proxy Binding Acknowledgement (PBAck) messages of
PMIPv6 <xref target="RFC5213"/>. This flag is defined in
<xref target="pbu_message" /> and <xref target="pback_message" />.
IANA is requested to allocate the new flag (B) in the Proxy Binding
Update and Proxy Binging Acknowledgement messages from the <xref
target="RFC5213"/> Proxy Binding Update Flags and the <xref
target="RFC5213"/> proxy Binding Acknowledgment Flags registries.</t>
<t>This specification defines a new Mobility Header option, the Mobile
Node Group Identifier option. This option is described in <xref target="GID_option"/>.
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 <xref target="RFC3775"/>).
Also, the Sub-type field of the Mobile Node Group Identifier option (as defined
in <xref target="mnid_option"/>) must have its own brand-new, unique number
pace allocated and managed by IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As per <xref target="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 information.</t>
<t>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 <xref target="RFC3775"></xref> and does not require any
special security considerations.</t>
<t>The bulk re-registration mechanism does not introduce any new
security threat or vulnerability to the PMIPv6 specification.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Jouni Korhonen and Basavaraj Patil for their review and input.</t>
<t>The authors would like to acknowledge the prior discussions on this
topic in netlmm mailing list.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC3775">
<front>
<title>Mobility Support in IPv6</title>
<author fullname="D. Johnson" initials="D." surname="Johnson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization></organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3775" />
<format octets="393514"
target="ftp://ftp.isi.edu/in-notes/rfc3775.txt" type="TXT" />
</reference>
<reference anchor="RFC5213">
<front>
<title>Proxy Mobile IPv6</title>
<author fullname="S. Gundavelli" initials="S." surname="Gundavelli">
<organization></organization>
</author>
<author fullname="K. Leung" initials="K." surname="Leung">
<organization></organization>
</author>
<author fullname="V. Devarapalli" initials="V."
surname="Devarapalli">
<organization></organization>
</author>
<author fullname="K. Chowdhury" initials="K." surname="Chowdhury">
<organization></organization>
</author>
<author fullname="B. Patil" initials="B." surname="Patil">
<organization></organization>
</author>
<date month="August" year="2008" />
</front>
<seriesInfo name="RFC" value="5213" />
<format octets="226902"
target="ftp://ftp.isi.edu/in-notes/rfc5213.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:59:05 |