idnits 2.17.1 draft-jiang-netext-pmip-localization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2012) is 4317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 96, but not defined == Unused Reference: 'RFC6275' is defined on line 289, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Haisheng Jiang 3 Intended Status: Proposed Standard Huawei 4 Expires: December 31, 2012 June 29, 2012 6 Localization for Mobile Nodes in the Proxy Mobile IPv6 Network 7 draft-jiang-netext-pmip-localization-00 9 Abstract 11 Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility 12 management for mobile nodes (MN) in a local small area. When the 13 numbers of MNs which attaching to the same MAG is very large, how to 14 manage those MNs is very urgent. Some MNs are active and have to 15 update the location information frequently; other ones are in idle 16 state so how to localize them is a little harder. This document 17 proposes a scheme to localize the idle MN in the PMIPv6 network. When 18 the MN is moving in the MD, the network can quickly obtain its 19 location information to achieve the state synchronization and reduce 20 the data forwarding delay. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 62 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Localization for Mobile Nodes . . . . . . . . . . . . . . . . 3 65 3.1 Procedure of Localization . . . . . . . . . . . . . . . . . 4 66 3.2 Status Management . . . . . . . . . . . . . . . . . . . . . 5 67 3.3 Signaling Message . . . . . . . . . . . . . . . . . . . . . 5 68 3.4 Data Forwarding . . . . . . . . . . . . . . . . . . . . . . 6 69 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Proxy Mobile IPv6 (PMIPv6) is a mobility management protocol on the 78 basis of the network, which supplies the local mobility management 79 for Mobile Nodes (MN). MN accesses the PMIPv6 network by cellular 80 technology or Wi-Fi and maintains the idle state in most of the time. 81 The registration procedure must be performed as MN moving to a new 82 area even with idle state, which MAY cause unnecessary and extra 83 signaling traffic. Furthermore, the mobility entity Mobile Access 84 Gateway (MAG) is used to perform the related signaling on behalf of 85 MN, so the frequent location update for MN will waste the network 86 resource seriously and result in the scalability limitation for 87 supporting a large number of MNs. 89 2. Requirements and Terminology 91 2.1 Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2.2 Terminology 99 In addition to the terminology defined in [RFC5213], the following 100 terminology is also used: 102 Local Management Center (LMC): LMC is located in the PMIPv6 network 103 to manage the location information for the MN. 105 Manage Domain (MD): MD is a network area network that cover the 106 moving of the MN. 108 MAG-a, MAG-b, MAG-c and MAG-d are MAGs located in the same MD and 109 used by MN. 111 3. Localization for Mobile Nodes 113 For locating the idle MN as soon as possible, Local Management Center 114 (LMC) is located in the Manage Domain (MD) to manage the states of 115 the MN. The MAG is allocated to be the LMC when it is attached by MN 116 which just turns into the idle state. LMC can be used to realize the 117 localization and disperse the pressure of the LMA. For achieving the 118 data forwarding quickly, the synchronized information between LMC and 119 other MAGs includes the detailed flags such as MN-ID, MN-HNP and the 120 address of LMC. When other MAGs receive the up-link data from the MN, 121 LMC is used to forward the data on one side, and the PMIP binding 122 procedure is activated on the other hand to setup the optimal path. 123 When LMA forwards the down-link data for the MN, the data are first 124 forwarded to LMC which initiates the localization. Then MAG forwards 125 the data to the MN for responding the localization message and 126 initiates the PMIP binding procedure to the LMA. 128 3.1 Procedure of Localization 130 In order to present the procedure of localization, assuming that an 131 MD is composed of four MAGs: MAG-a, MAG-b, MAG-c and MAG-d. The 132 detailed process is shown as following: 134 1) Firstly, MN attaches to MAG-a. As MAG-a does not maintain the 135 state information of MN, it initiates the PMIP binding procedure and 136 setup the bi-direction tunnel with LMA; 138 2) During a period of lifetime, if no traffic data occurred in the 139 MN, the state of MN is turned into idle in the subnet managed by MAG- 140 a. Thus MAG-a proposes itself as the LMC of MN and sends the related 141 information to other MAGs in the MD by localized indication; 143 3) For the condition that MN is distinguished as an idle node when it 144 moves to attach with MAG-b, PMIP operation does not have to be 145 performed. The same procedure is executed when MN moves to MAG-c; 147 4) When the data packets from the communication Corresponding Node 148 (CN) are sent to MN, the first destination is LMA. Because LMA is 149 binding to MAG-a, thus the data packets are redirected to MAG-a. At 150 present MN has already moved to the other MAG, so MAG-a initiates the 151 localization procedure. MAGs locating in MD receive the localization 152 request messages and make the response according to the real 153 conditions. For example, when MAG-b and MAG-d will ignore the request 154 messages as the information of MN cannot be found in their subnet. 155 MAG-c detects that MN is locating in its subnet and makes a 156 responding to the request message. For one side MAG-a redirects the 157 data packets to MAG-c for forwarding to MN; for the other side MAG-c 158 initiates the PMIP binding procedure. LMA will update the binding 159 state with MAG when receiving the PBU message; 161 5) At present MN turns into the idle state and MAG-c is selected as 162 new LMC and announces to other MAGs for updating the information of 163 MN; 165 6) Then MN moves to attach to MAG-d and be found with idle state. So 166 PMIP operation does not have to be performed; 168 7) When MN sends data packets to CN, MAG-d redirects the data packets 169 to MAG-c and initiates the PMIP procedure to setup the bi-direction 170 tunnel with LMA in the meanwhile. 172 3.2 Status Management 174 In order to synchronize the state of MN among MAGs in MD, the 175 original binding update list in PMIP should be extended as shown in 176 Table 1: 178 +-----+-----+-------+-----+----------+ 179 |MN-ID| HNP | State | LMC | Lifetime | 180 +-----+-----+-------+-----+----------+ 181 | MN-1| HNP1| 1 | MAG1| 50s | 182 +-----+-----+-------+-----+----------+ 183 | MN-2| HNP2| 0 | MAG2| 50s | 184 +-----+-----+-------+-----+----------+ 186 Table 1: Binding Update List 188 The state flag (value 1 indicates the idle state whereas 0 indicates 189 the active state) is added in to the binding update list of MAG. 190 Besides, LMC address and Lifetime flag are appended to manage the 191 states and follow the rules: 193 O If MAG still does not get any packets from MN when the lifetime of 194 the active MN is expired, the state of MN is turned into idle. 196 O The lifetime should be reset when MN received the data packets. 198 O When the lifetime of the idle MN is expired, the LMC address flag 199 of the binding update list is null means that the current MAG is 200 the LMC of the idle MN. Thus it's necessary for the MAG to 201 communicate with LMA to update the location of MN and maintain the 202 binding state of MN in LMA. The MAG needs to send the localization 203 message to update the state of MN in other MAGs. 205 O When the lifetime of the idle MN is expired, the LMC address flag 206 of the binding update list is not null means that the current MAG 207 regards the state of MN turning into active and so deletes the 208 corresponding entry. 210 O Current MAG makes sure that MN turns into the idle state and 211 recommends itself as LMC of MN when no data packets occurred in 212 the lifetime. Then MAG will initiate the state synchronization for 213 MN. 215 3.3 Signaling Message 216 In the process of localization for MN, signaling messages which are 217 proposed to fulfill the communication and information exchange are 218 including the locating instruction message, the locating request 219 message and the locating response message. The signaling interaction 220 process meets the requirements as follows: 222 O LMC sends the locating instruction messages including MN-ID, MN- 223 HNP, state information and its own address to other MAGs in the 224 MD. When MN turns into the active state, LMC can send the locating 225 instruction messages to notify other MAGs to delete the state 226 information of MN. 228 O The locating request messages are sent by LMC to other MAGs in MD 229 to turn the state of MN into active. MAGs should delete the state 230 information of MN if without connection. For the MAGs having 231 connection with MN, the state information should be turned into 232 active. In the meanwhile those MAGs initiate the PMIP binding 233 procedure and send the locating response message to LMC. 235 O The locating response messages sent from MAGs to LMC to give a 236 response to the locating request messages. The detailed message 237 includes the flags such as MN-ID, MN-HNP and the address of MAG. 239 3.4 Data Forwarding 241 Data forwarding process can be divided into two aspects: the 242 interaction between MAG and LMA as well as the interaction between 243 MAG and LMC. 245 O Data forwarding between MAG and LMA should exactly follow the 246 operation requirements of PMIPv6. 248 O The process of transmitting packets between MAG and LMC can be 249 presented as follows: 251 a) When receiving the up-link packets from the idle MN, current 252 MAG (not as LMC) should redirect the data packets to LMC 253 according to the binding update list and initiate the PMIPv6 254 binding procedure. If MAG has received the PBA from LMA, it 255 implies that PMIPv6 tunnel have been setup and the subsequent 256 packets will be delivered by the tunnel. If MAG is used as LMC 257 and receives the up-link data packets from the idle MN, MAG 258 firstly turns the state information of MN into active and sends 259 the locating instruction message to other MAGs to synchronize 260 the state information of MN and forwards the data packets to 261 LMA through the PMIPv6 tunnel. 263 b) When receiving the down-link packets from MN, LMA will forward 264 the data packets through the tunnel to the MAG which is used to 265 register in the network. The MAG must be used as LMC for MN. If 266 MN is located in the subnet of LMC, LMC will forward the 267 packets to MN and send the locating instruction messages to 268 other MAGs to synchronize the state information of MN. If MN is 269 locating in the subnet of other MAGs, LMC firstly locates the 270 current attaching MAG of MN by sending the locating request 271 message and then forwards the packets to the appropriate MAG 272 when receiving the location response message. 274 4 Security Considerations 276 This document raises no new security issues for PMIPv6 network. 278 5 IANA Considerations 280 None 282 6 References 284 6.1 Normative References 286 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 287 and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008. 289 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 290 in IPv6", RFC6275, July 2011. 292 J. Kempf, Ed. Problem Statement for Network-Based Localized Mobility 293 Management (NETLMM). RFC4830. 2007. 295 Authors' Addresses 297 Haisheng Jiang 298 Huawei Building, No.156 Beiqing Rd. 299 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 300 Beijing 100095 P.R. China 302 EMail: haisheng.jiang@huawei.com