idnits 2.17.1 draft-jiang-dmm-ps-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 == Line 258 has weird spacing: '...enarios for D...' -- The document date (June 29, 2012) is 4318 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) == Unused Reference: 'RFC6275' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'I-D.yokota-dmm-scenario' is defined on line 257, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Jiang 3 Intended Status: Proposed Standard Huawei Technologies 4 Expires: December 31, 2012 June 29, 2012 6 Problem statement for distributed mobility management 7 draft-jiang-dmm-ps-00 9 Abstract 11 Due to the limitation of sub-optimal routing, reliability and 12 scalability problems in the centralized mobility management approach, 13 distributed mobility management approaches are developed to resolve 14 those problems. However, the proposed distributed mobility management 15 approaches also bring some new problems. This document mainly 16 introduces two kinds of approaches classified by the control plane 17 management mode and proposes the new problems should be resolved in 18 the future. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 60 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. DMM overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1 F-DMM solution . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2 P-DMM solution . . . . . . . . . . . . . . . . . . . . . . . 4 65 4 Problem statement . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1 Signaling costs . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2 Resource utilization . . . . . . . . . . . . . . . . . . . . 5 68 4.3 Deployment problem . . . . . . . . . . . . . . . . . . . . . 6 69 4.4 Multihoming support . . . . . . . . . . . . . . . . . . . . 6 70 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 74 6.2 Informative References . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 With the development of the mobile communication technologies, the 80 number of mobile subscribers is growing year by year with the result 81 that the amount of data traffic generated by them is experiencing a 82 huge growth, and the future traffic amount is unpredictable. More and 83 more users prefer to user mobile phones and tablet to obtain data 84 information through wireless technologies. In the meanwhile more and 85 more mobile Internet applications designed for handheld mobile 86 terminals have already attracted the attention of most mobile users. 88 In order to supply the perfect user experiences for those mobile 89 subscribers to increase the acceptance, the mobile operators SHOULD 90 adopt the suitable protocols or architecture to management those huge 91 number of mobile terminals. Thus IETF have proposed some standards to 92 deal with the mobility management problems for mobile nodes. Typical 93 protocols include Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6). 94 These protocols generally utilize the mobility anchor to handle the 95 management operations. Thus the key point for those approaches is 96 based on the centralized theory. However, the centralized approach 97 has several drawbacks such as sub-optimal routing, scalability 98 problem, reliability problem and so on. 100 For overcoming the drawbacks of the centralized mobility management 101 approaches, the new approach SHOULD be distributed and never utilizes 102 a central management point to deliver the control and data packets. 103 Thus the IETF researchers begin to discuss the requirements and 104 propose the solutions. Then the proposed solutions can be divided 105 into two kinds: fully distributed and partially distributed. The main 106 difference is whether the control plane is distributed or 107 centralized. 109 However, as other already deployed mobility management protocols, 110 whether the fully distributed mobility management protocols or the 111 partially distributed mobility management protocols are not perfect 112 and with some limitations had to be considered and resolved. So this 113 document analyzes the model of distributed mobility management and 114 proposes some problems in the deployment situation. 116 2. Requirements and Terminology 118 2.1 Requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2.2 Terminology 126 In addition to the terminology defined in [RFC5213], the following 127 terminology is also used: 129 DMM: Distributed Mobility Management 131 F-DMM: Fully Distributed Mobility Management 133 P-DMM: Partially Distributed Mobility Management 135 NME: Network Management Entity is an access router and allocates the 136 prefix for MN which attaching to it. It can be used to exchange 137 messages for MN to complete the mobility management. 139 CCE: Central Control Entity is a central control unit used to manage 140 the location and other information for MN in P-DMM. 142 3. DMM overview 144 As mentioned above, Distributed Mobility Management (DMM) can be 145 divided as follows: 147 3.1 F-DMM solution 149 In F-DMM solution, Network Management Entity (NME) which achieves the 150 mobility management is an access router with the function of anchor. 151 It takes the role of LMA and MAG as in PMIPv6. So when MN attaches 152 the NME1, NME1 advertises the prefix for MN to configure the IP 153 address. When MN moves to attach NEM2, NEM2 will advertise the new 154 prefix to MN and sends a PBU message to NME1. After receiving the 155 reply PBA message, NME1 will create a tunnel with NME2. So the 156 traffic transmitted by NME1 will be forwarded to NME2 so as to reach 157 MN. And so on, the tunnels will be created with the MN's moving 158 situation. 160 3.2 P-DMM solution 162 In P-DMM solution, the Central Control Entity (CCE) is used to 163 execute the control signaling interaction and manage the statement of 164 the MN. CCE achieves the control functions as LMA in PMIPv6. When MN 165 connects to NME1, NME1 advertises the prefix for MN to configure the 166 IP address. NME1 sends a PBU message to CCE. Then CCE replies a PBA 167 message to confirm the new registration. When MN moves to NME2, it 168 gets a new prefix. NME2 sends a PBU to CCE for registration. By 169 searching the BCE table, CCE gets former location information of MN 170 and sends PBU messages to those NMEs. After receiving PBU message, 171 NME1 will send a PBA message to CCE to confirm and another PBA to 172 NME2. Then the tunnel will be created between NME1 and NME2. So the 173 traffic transmitted by NME1 will be forwarded to NME2 so as to reach 174 MN. And so on, the tunnels will be created with the MN's moving 175 situation. 177 4 Problem statement 179 Although DMM approaches solve some problems caused by centralized 180 mobility management approaches, it also brings some new challenges 181 which SHOULD be resolved for the real large scale business 182 deployment. 184 4.1 Signaling costs 186 Signaling cost is measurement criteria to evaluate the mobility 187 management approach. In F-DMM solution, because the control plane is 188 also distributed, the way NME to verify if the attachment of MN is 189 fresh is to send PBU messages to other NMEs. Apparently, in a large 190 scale network with lots of NMEs, it will cost too much signaling to 191 get this information. Otherwise, the new solution SHOULD be proposed 192 to alleviate the signaling cost. In P-DMM solution, When NME sends a 193 PBU message to CCE after a MN attachment, CCE will sends PBA messages 194 to all NMEs in the local area to obtain the PBA reply. This cost is 195 very large if the network domain is large and with many NEMs. For 196 example, if the MN is moving in a city to get service, then the PBA 197 messages costs are expensive. 199 4.2 Resource utilization 201 In both of two DMM approaches, how to manage the network resource is 202 also important. Each time when MN attaches to a new NME, it will 203 create a new tunnel between the new NME and previous NME after the 204 registration. So when MN keeps on moving in the large network area 205 and frequently attaching to different NME, then there are many 206 tunnels between those NEMs. The problem is that most of those tunnels 207 will be idle after the moving, so it is unnecessary to keep the 208 mobility session for those cases. Moreover, the number of NMEs 209 involves the mobility session will increase and become very large. So 210 Removing some NMEs which MAY not be used such as having long distance 211 with the latest location of MN. 213 4.3 Deployment problem 215 Whether F-DMM or P-DMM, how to deploy the network architecture is a 216 head-scratching puzzlement. For F-DMM, the deployment of NMEs depends 217 on the network area that MN locating. For P-DMM, the location of CCE 218 is also troublesome. Moreover, CCE also will cause the single point 219 failure problem. So it only can be used in small area or localized 220 moving cases. In large area network, mobile operators SLOULD deploy 221 many CCEs to keep synchronization so as to manage the mobility of MN 222 conveniently and save the long distance network cost. 224 4.4 Multihoming support 226 Up to now, the proposed DMM solutions in IETF have not talking about 227 the multihoming support for MN. All solutions are just assuming that 228 MN connects to the network by one interface. So when MN moving, the 229 mobility handover and session maintaining is very clearly and easy to 230 achieve. However, in multihoming scenario, how to keep the mobility 231 session well when one interface of MN moving while other interfaces 232 remain unchanged is also unclear. 234 5 Security Considerations 236 None 238 5 IANA Considerations 240 None 242 6 References 244 6.1 Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 6.2 Informative References 251 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 252 and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008. 254 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 255 in IPv6", RFC6275, July 2011. 257 [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z. 258 Cao, "Use case scenarios for Distributed Mobility 259 Management",draft-yokota-dmm-scenario-00 (expired), 260 October 2010. 262 [Paper-Distributed.Centralized.Mobility] Fabio, G., Antonio, O., 263 Carlos J. Bernardos and Rui, Costa. ,"A Network-based 264 Localized Mobility Solution for Distributed Mobility 265 Management", Proceedings of International Workshop on 266 Mobility Management for Flat Networks (MMFN 2011). 268 Authors' Addresses 270 Haisheng Jiang 271 Huawei Building, No.156 Beiqing Rd. 272 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 273 Beijing 100095 P.R. China 275 EMail: haisheng.jiang@huawei.com