Internet DRAFT - draft-jiang-netext-pmip-localization
draft-jiang-netext-pmip-localization
INTERNET-DRAFT Haisheng Jiang
Intended Status: Proposed Standard Huawei
Expires: December 31, 2012 June 29, 2012
Localization for Mobile Nodes in the Proxy Mobile IPv6 Network
draft-jiang-netext-pmip-localization-00
Abstract
Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility
management for mobile nodes (MN) in a local small area. When the
numbers of MNs which attaching to the same MAG is very large, how to
manage those MNs is very urgent. Some MNs are active and have to
update the location information frequently; other ones are in idle
state so how to localize them is a little harder. This document
proposes a scheme to localize the idle MN in the PMIPv6 network. When
the MN is moving in the MD, the network can quickly obtain its
location information to achieve the state synchronization and reduce
the data forwarding delay.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
H. Jiang December 31, 2012 [Page 1]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Localization for Mobile Nodes . . . . . . . . . . . . . . . . 3
3.1 Procedure of Localization . . . . . . . . . . . . . . . . . 4
3.2 Status Management . . . . . . . . . . . . . . . . . . . . . 5
3.3 Signaling Message . . . . . . . . . . . . . . . . . . . . . 5
3.4 Data Forwarding . . . . . . . . . . . . . . . . . . . . . . 6
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
H. Jiang December 31, 2012 [Page 2]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
1. Introduction
Proxy Mobile IPv6 (PMIPv6) is a mobility management protocol on the
basis of the network, which supplies the local mobility management
for Mobile Nodes (MN). MN accesses the PMIPv6 network by cellular
technology or Wi-Fi and maintains the idle state in most of the time.
The registration procedure must be performed as MN moving to a new
area even with idle state, which MAY cause unnecessary and extra
signaling traffic. Furthermore, the mobility entity Mobile Access
Gateway (MAG) is used to perform the related signaling on behalf of
MN, so the frequent location update for MN will waste the network
resource seriously and result in the scalability limitation for
supporting a large number of MNs.
2. Requirements and Terminology
2.1 Requirements
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].
2.2 Terminology
In addition to the terminology defined in [RFC5213], the following
terminology is also used:
Local Management Center (LMC): LMC is located in the PMIPv6 network
to manage the location information for the MN.
Manage Domain (MD): MD is a network area network that cover the
moving of the MN.
MAG-a, MAG-b, MAG-c and MAG-d are MAGs located in the same MD and
used by MN.
3. Localization for Mobile Nodes
For locating the idle MN as soon as possible, Local Management Center
(LMC) is located in the Manage Domain (MD) to manage the states of
the MN. The MAG is allocated to be the LMC when it is attached by MN
which just turns into the idle state. LMC can be used to realize the
localization and disperse the pressure of the LMA. For achieving the
data forwarding quickly, the synchronized information between LMC and
other MAGs includes the detailed flags such as MN-ID, MN-HNP and the
address of LMC. When other MAGs receive the up-link data from the MN,
LMC is used to forward the data on one side, and the PMIP binding
H. Jiang December 31, 2012 [Page 3]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
procedure is activated on the other hand to setup the optimal path.
When LMA forwards the down-link data for the MN, the data are first
forwarded to LMC which initiates the localization. Then MAG forwards
the data to the MN for responding the localization message and
initiates the PMIP binding procedure to the LMA.
3.1 Procedure of Localization
In order to present the procedure of localization, assuming that an
MD is composed of four MAGs: MAG-a, MAG-b, MAG-c and MAG-d. The
detailed process is shown as following:
1) Firstly, MN attaches to MAG-a. As MAG-a does not maintain the
state information of MN, it initiates the PMIP binding procedure and
setup the bi-direction tunnel with LMA;
2) During a period of lifetime, if no traffic data occurred in the
MN, the state of MN is turned into idle in the subnet managed by MAG-
a. Thus MAG-a proposes itself as the LMC of MN and sends the related
information to other MAGs in the MD by localized indication;
3) For the condition that MN is distinguished as an idle node when it
moves to attach with MAG-b, PMIP operation does not have to be
performed. The same procedure is executed when MN moves to MAG-c;
4) When the data packets from the communication Corresponding Node
(CN) are sent to MN, the first destination is LMA. Because LMA is
binding to MAG-a, thus the data packets are redirected to MAG-a. At
present MN has already moved to the other MAG, so MAG-a initiates the
localization procedure. MAGs locating in MD receive the localization
request messages and make the response according to the real
conditions. For example, when MAG-b and MAG-d will ignore the request
messages as the information of MN cannot be found in their subnet.
MAG-c detects that MN is locating in its subnet and makes a
responding to the request message. For one side MAG-a redirects the
data packets to MAG-c for forwarding to MN; for the other side MAG-c
initiates the PMIP binding procedure. LMA will update the binding
state with MAG when receiving the PBU message;
5) At present MN turns into the idle state and MAG-c is selected as
new LMC and announces to other MAGs for updating the information of
MN;
6) Then MN moves to attach to MAG-d and be found with idle state. So
PMIP operation does not have to be performed;
7) When MN sends data packets to CN, MAG-d redirects the data packets
to MAG-c and initiates the PMIP procedure to setup the bi-direction
H. Jiang December 31, 2012 [Page 4]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
tunnel with LMA in the meanwhile.
3.2 Status Management
In order to synchronize the state of MN among MAGs in MD, the
original binding update list in PMIP should be extended as shown in
Table 1:
+-----+-----+-------+-----+----------+
|MN-ID| HNP | State | LMC | Lifetime |
+-----+-----+-------+-----+----------+
| MN-1| HNP1| 1 | MAG1| 50s |
+-----+-----+-------+-----+----------+
| MN-2| HNP2| 0 | MAG2| 50s |
+-----+-----+-------+-----+----------+
Table 1: Binding Update List
The state flag (value 1 indicates the idle state whereas 0 indicates
the active state) is added in to the binding update list of MAG.
Besides, LMC address and Lifetime flag are appended to manage the
states and follow the rules:
O If MAG still does not get any packets from MN when the lifetime of
the active MN is expired, the state of MN is turned into idle.
O The lifetime should be reset when MN received the data packets.
O When the lifetime of the idle MN is expired, the LMC address flag
of the binding update list is null means that the current MAG is
the LMC of the idle MN. Thus it's necessary for the MAG to
communicate with LMA to update the location of MN and maintain the
binding state of MN in LMA. The MAG needs to send the localization
message to update the state of MN in other MAGs.
O When the lifetime of the idle MN is expired, the LMC address flag
of the binding update list is not null means that the current MAG
regards the state of MN turning into active and so deletes the
corresponding entry.
O Current MAG makes sure that MN turns into the idle state and
recommends itself as LMC of MN when no data packets occurred in
the lifetime. Then MAG will initiate the state synchronization for
MN.
3.3 Signaling Message
H. Jiang December 31, 2012 [Page 5]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
In the process of localization for MN, signaling messages which are
proposed to fulfill the communication and information exchange are
including the locating instruction message, the locating request
message and the locating response message. The signaling interaction
process meets the requirements as follows:
O LMC sends the locating instruction messages including MN-ID, MN-
HNP, state information and its own address to other MAGs in the
MD. When MN turns into the active state, LMC can send the locating
instruction messages to notify other MAGs to delete the state
information of MN.
O The locating request messages are sent by LMC to other MAGs in MD
to turn the state of MN into active. MAGs should delete the state
information of MN if without connection. For the MAGs having
connection with MN, the state information should be turned into
active. In the meanwhile those MAGs initiate the PMIP binding
procedure and send the locating response message to LMC.
O The locating response messages sent from MAGs to LMC to give a
response to the locating request messages. The detailed message
includes the flags such as MN-ID, MN-HNP and the address of MAG.
3.4 Data Forwarding
Data forwarding process can be divided into two aspects: the
interaction between MAG and LMA as well as the interaction between
MAG and LMC.
O Data forwarding between MAG and LMA should exactly follow the
operation requirements of PMIPv6.
O The process of transmitting packets between MAG and LMC can be
presented as follows:
a) When receiving the up-link packets from the idle MN, current
MAG (not as LMC) should redirect the data packets to LMC
according to the binding update list and initiate the PMIPv6
binding procedure. If MAG has received the PBA from LMA, it
implies that PMIPv6 tunnel have been setup and the subsequent
packets will be delivered by the tunnel. If MAG is used as LMC
and receives the up-link data packets from the idle MN, MAG
firstly turns the state information of MN into active and sends
the locating instruction message to other MAGs to synchronize
the state information of MN and forwards the data packets to
LMA through the PMIPv6 tunnel.
H. Jiang December 31, 2012 [Page 6]
INTERNET DRAFT Localization for MN in PMIPv6 June 29, 2012
b) When receiving the down-link packets from MN, LMA will forward
the data packets through the tunnel to the MAG which is used to
register in the network. The MAG must be used as LMC for MN. If
MN is located in the subnet of LMC, LMC will forward the
packets to MN and send the locating instruction messages to
other MAGs to synchronize the state information of MN. If MN is
locating in the subnet of other MAGs, LMC firstly locates the
current attaching MAG of MN by sending the locating request
message and then forwards the packets to the appropriate MAG
when receiving the location response message.
4 Security Considerations
This document raises no new security issues for PMIPv6 network.
5 IANA Considerations
None
6 References
6.1 Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC6275, July 2011.
J. Kempf, Ed. Problem Statement for Network-Based Localized Mobility
Management (NETLMM). RFC4830. 2007.
Authors' Addresses
Haisheng Jiang
Huawei Building, No.156 Beiqing Rd.
Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
Beijing 100095 P.R. China
EMail: haisheng.jiang@huawei.com
H. Jiang December 31, 2012 [Page 7]
