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]