idnits 2.17.1 draft-zhang-dmm-rpmipdmm-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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 167 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4406 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 section? 'RFC2119' on line 27 looks like a reference -- Missing reference section? '1' on line 357 looks like a reference -- Missing reference section? '2' on line 360 looks like a reference -- Missing reference section? 'RFC5213' on line 347 looks like a reference -- Missing reference section? '3' on line 363 looks like a reference -- Missing reference section? '4' on line 367 looks like a reference -- Missing reference section? '5' on line 373 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group Hong-Ke Zhang 3 Internet Draft Li-Li Wang 4 Expires: September 2012 Bo-Hao Feng 5 Shuai Gao 6 Beijing Jiaotong University 7 March 26, 2012 9 A Robust Solution for PMIPv6-based Distributed Mobility Management 10 draft-zhang-dmm-rpmipdmm-00.txt 12 Abstract 14 Proxy Mobile IPv6 (PMIPv6) is a network-based centralized mobility 15 management protocol, which has many disadvantages for utilizing the 16 centralized anchor LMA. As networks are moving towards flat 17 architectures, a distributed approach is needed to PMIPv6. This 18 document defines a robust solution for PMIPv6-based distributed 19 mobility management which ensures the robustness by organizing the 20 distributed anchors (MAARs) into a Chord ring. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress". 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on September, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction ................................................ 2 68 2. Terminology ................................................. 3 69 3. Description of the solution ................................. 4 70 4. Format of signaling messages ................................ 7 71 4.1. M-PBU .................................................. 7 72 4.2. M-PBA .................................................. 8 73 5. Security Considerations ..................................... 9 74 6. References .................................................. 9 75 Acknowledgment ................................................ 10 77 1. Introduction 79 The current IP mobility protocols, which are either host-based like 80 Mobile IPv6 [1] or network-based like Proxy Mobile IPv6 [2], support 81 the mobility management via centralized anchors. In order to maintain 82 the IP session when MNs handover, the anchors are mainly responsible 83 for allocating home network prefixes to MNs, managing their locations 84 and intercepting as well as forwarding packets that are from or to 85 MNs. However, such centralized anchors lead to some obvious 86 shortcomings like sub-optimal routing, scalability problem, 87 considerable signaling cost and delay and so on. 89 As the networks are moving towards flat architecture, a distributed 90 approach is needed to avoid those disadvantages of centralized 91 mobility protocols. In this distributed scheme, there is no need for 92 any centralized anchors in the network while only distributed anchors 93 are deployed. Besides, it is not necessary to identify MNs by the 94 fixed home addresses or home network prefixes. Some related drafts 95 have been proposed, but there are not any schemes to guarantee the 96 robustness for the distributed mobility management. In this document, 97 we propose a robust solution for PMIPv6-based distributed mobility 98 management. This solution ensures the robustness by organizing the 99 distributed anchors (MAARs) into a Chord ring. 101 2. Terminology 103 The following terms used in this document are defined in the Proxy 104 Mobile IPv6 specification [RFC5213]: 106 Local Mobility Anchor (LMA) 108 Mobile Access Gateway (MAG) 110 Mobile Node (MN) 112 Corresponding Node (CN) 114 Proxy Binding Update (PBU) 116 Proxy Binding Acknowledgment (PBA) 118 The following terms are defined and/or used in this document: 120 MAAR (Mobility Anchor and Access Router). First IP hop routers 121 where the mobile nodes attach to. They provide an IPv6 prefix 122 (topologically anchored at the MAAR) to each attaching mobile node. 123 They also play the role of mobility managers for the IPv6 prefixes 124 they anchor. 126 M-MAAR (Managed Mobility Anchor and Access Router). The MAAR that 127 manages all the path of the MN which is distributed assigned in the 128 Chord ring. 130 M-PBU (Managed PBU). The signaling message sent by MAAR to the M-MAAR. 131 It is used to register to M-MAAR for MN recording the MN's path. 133 M-PBA (Managed PBA). The signaling message sent back by M-MAAR to the 134 MAAR. It is used to register to M-MAAR for MN recording the MN's path. 136 3. Description of the solution 138 The purpose of this solution is to provide robust distributed 139 mobility management based on PMIPv6. For this, it is assumed that 140 there are many MAARs in the management domain and that every MAAR has 141 a MAAR identifier that is similar to an MN-identifier specified in 142 RFC 4283 [3]. And every MAAR in this solution functions as both an 143 LMA for those MNs that are attached to it at the first hop, and a MAG 144 for those MNs that are connected to it while not attached at the 145 first hop. Therefore, there are not any centralized anchors in the 146 architecture of this solution. In addition, all MAARs in this 147 distributed management domain are organized into a Chord circle using 148 consistent hashing over MAAR identifiers [4][5]. Given the fact that 149 the Chord system distributes the information of value among nodes on 150 the ring, the failure of a MAAR only affects a very limited number of 151 MAARs in the Chord system, which indicate that this solution for 152 distributed mobility management based on PMIPv6 is robust. Moreover, 153 for a given MN, the M-MAAR that manages all the path of this MN in 154 the distributed management domain is configured by the network 155 administrator of the domain or by some algorithm and does not change 156 as long as the MN roams within the domain. The architecture of this 157 solution is shown in Figure 1. 159 o @ N1(MAAR) 160 o o 161 @ @ N8 163 o o 165 @ @ N14 167 @ o 169 o @ N21 171 @ o 173 o o 174 @ @ N32 175 N38 o o 177 Figure 1: Architecture of the distributed mobility management based 178 on PMIPv6 using Chord ring 180 As stated above, which M-MAAR is configured and responsible for an MN 181 is unknown to other MAARs when this MN attaches to them. In order to 182 deal with this issue, we store (key, value) pairs at the MAARs by 183 using consistent hashing algorithm, where the key is the hash value 184 of an MN-identifier and the value is the IPv6 address of the M-MAAR 185 serving the corresponding MN. For a given MN, the IPv6 address of its 186 M-MAAR should be stored at the MAAR that is the successor of the MN- 187 identifier. For ease of description, we define QServer(MN) as the 188 MAAR that stores the (key, value) pair for an MN. Also for simplicity, 189 we will use MN-id and M-MAAR or the tuple (MN-id, M-MAAR) to 190 represent both the original and hash value of the MN-identifier and 191 the IPv6 address of its M-MAAR. 193 Whenever a new MAAR detects the attachment of an MN, it may not know 194 the MN's M-MAAR. In this case, it sends a query message including the 195 MN-identifier, the new MAAR's identifier and IPv6 address to the 196 Chord system in order to find the MN's M-MAAR. The other MAARs in the 197 Chord system forward the query message according to their finger 198 tables until it reaches QServer(MN). When the MAAR that serves as the 199 QServer of the MN receives the query message, it sends the IPv6 200 address of the MN's M-MAAR which is defined in the tuple (MN-id, M- 201 MAAR) back to the new MAAR. When the new MAAR receives the IPv6 202 address of the MN's M-MAAR, it stores the M-MAAR's IPv6 address into 203 a table for the attached MN locally. 205 After knowing the M-MAAR's IPv6 address, the new MAAR (MAAR1) sends 206 an M-PBU message to the M-MAAR. If the cache about the MN in M-MAAR 207 is empty, this MAAR1 will also serve as LMA assigning HNP1 for MN as 208 specified in PMIPv6. And also, the M-MAAR should record one item 209 including MN-identifier, HNP1 and the IPv6 address of the MAAR1. 210 However, if there is one item (MN-id, HNP0, the MAAR0's IPv6 address) 211 in the cache about the MN in M-MAAR, the M-MAAR will return an M-PBA 212 message containing the corresponding information to the MAAR1 after 213 receiving the M-PBU message. That is, MAAR1 is not the first hop 214 router to which the MN accesses. And then MAAR1 sends a register 215 message (PBU) to the MAAR0 and establishes the bi-directional tunnel 216 between the MAAR0 and the MAAR1 after receiving the PBA message from 217 the MAAR0. Besides, in this case the MN could also use the HNP1 218 allocated by MAAR1 to start a new IP session. 220 As shown in Figure 2, the paths among the MAARs and the M-MAAR 221 represented by lines ("/" and "\") indicate registrations between 222 MAARs and the M-MAAR, while the path depicted with stars ("*") 223 denotes the query procedure of MAARs for the address of the M-MAAR of 224 the MN-id in chord ring, and the path pictured with circles ("o" and 225 "#") shows the data flow from CN1 and CN2 respectively. In Figure 2, 226 the MN moves from the MAAR1 to the MAAR2. And the MN starts a new 227 session with the CN2 when it moves to the MAAR2 and also continues 228 the session with the CN1 through the MAAR1. The detailed procedure is 229 described in Figure 3. 231 +---+ +------+ +----------+ +---+ 232 |CN1| |M-MAAR| |Chord Ring| |CN2| 233 +---+ +------+ +----------+ +---+ 234 o | * # 235 o / \ * * # 236 o / \ * * # 237 o / \ * * # 238 o / \ * * # 239 o / \ * * # 240 o / * \ * # 241 o / * \ * # 242 o / * \ * # 243 o / * \ * # 244 o | * | * # 245 o +-----+ +-----+ # 246 oooo|MAAR1|(oooooooooo) |MAAR2|####################### 247 +-----+ tunnel +-----+ 248 o| o|# 249 +---+ +---+ 250 |MN |-------------->|MN | 251 +---+ +---+ 253 Figure 2: Scenario after a handover and the data flow 255 MN MAAR1 MAAR2 M-MAAR MAARs(Chord ring) CN1 CN2 256 | | | | | | | 257 |-L2 Attachment->| | | | | | 258 | |----------------------------->| | | 259 | (Query for the address of M-MAAR of the MN-id) | | 260 | | | | | | | 261 | |<-Reply the address of M-MAAR-| | | 262 |<-Allocate HNP1-| | | | | | 263 |(Configure IP address) | | | | | 264 | | | | | | | 265 | |-------M-PBU------>| | | | 266 | (Register to the M-MAAR with address of MAAR1, HNP1 and MN-id) | 267 | | | | | | | 268 | |<-------M-PBA------| | | | 269 | | | | | | | 270 |<---------------|<-----------IP Packets with HNP1-----------| | 271 | | | | | | | 272 |--------Handover-------->| | | | | 273 | | | | | | | 274 |-----L2 Attachment------>| | | | | 275 | | |-------------------->| | | 276 | (Query for the address of M-MAAR of the MN-id) | | 277 | | | | | | | 278 | | |<-Reply the address--| | | 279 |<-----Allocate HNP2------| | | | | 280 | (Configure IP address) | | | | | 281 | | | | | | | 282 | | |--------M-PBU------->| | | 283 | (Register to the M-MAAR with address of MAAR2, HNP2 and MN-id) | 284 | | | | | | | 285 | | |<--------M-PBA-------| | | 286 | | (Reply the address of MAAR1 and HNP1) | | 287 | | | | | | | 288 | |<--PBU--| | | | | 289 | |--PBA-->| | | | | 290 | (Establish the Tunnel) | | | | 291 | | | | | | | 292 | |<------------IP Packets with HNP1----------| | 293 | |=======>| | | | | 294 |<------------------------| | | | | 295 | | | | | | | 296 |<------------------------|<---------IP Packets with HNP2---------| 297 | | | | | | | 299 Figure 3: The detailed procedure of the solution 301 4. Format of signaling messages 303 4.1. M-PBU 305 The format of the M-PBU message is shown in Figure 4. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Sequence # | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 | Mobility options | 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 D flag 321 1-bit "Distributed" flag is used to identify whether this PBU is from 322 the MAAR to the M-MAAR. When this flag is set to "0", this message is 323 the PBU message in the [RFC5213]. If the flag is set to "1", this 324 message is the M-PBU. The flag MUST be set to the value of 1 in this 325 draft. 327 4.2. M-PBA 329 The format of the M-PBA message is shown in Figure 5. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Status |K|R|P|D|Reserved| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Sequence # | Lifetime | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | Mobility options | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 D flag 345 1-bit "Distributed" flag is used to identify whether this PBA is from 346 the M-MAAR to the MAAR. When this flag is set to "0", this message is 347 the PBA message in the [RFC5213]. If the flag is set to "1", this 348 message is the M-PBA. The flag MUST be set to the value of 1 in this 349 draft. 351 5. Security Considerations 353 This document does not introduce any security considerations. 355 6. References 357 [1] C.Perkins, D.Johnson, and J. Arkko, "Mobility Support 358 in IPv6", RFC 6275, July 2011. 360 [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. 361 Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 363 [3] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury, 364 "Mobile node identifier option for mobile IPv6 (MIPv6)", RFC 365 4283, November 2005. 367 [4] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. Kaashoek, 368 F.Dabek, and H. Balakrishnan, "Chord: a scalable peer-to-peer 369 lookup protocol for Internet applications," IEEE/ACM 370 Transactions on Networking, vol.11, no.1, pp: 17-32, February 371 2003. 373 [5] D. R. Karger, E. Lehman, F. Leighton, M. Levine, D. Lewin, and 374 R. Panigrahy, "Consistent hashing and random trees: distributed 375 caching protocols for relieving hot spots on theWorldWideWeb," 376 in Proc. 29th Annu. ACM Symp. Theory of Computing, May 1997, pp. 377 654-663. 379 Authors' Addresses 381 Hong-Ke Zhang, Li-Li Wang, Bo-Hao Feng, Shuai-Gao 382 National Engineering Lab for NGI Interconnection Devices 383 Beijing Jiaotong University, China 385 Phone: +861051684274 386 Email:hkzhang@bjtu.edu.cn 387 liliwang@bjtu.edu.cn 388 11111021@bjtu.edu.cn 389 shgao@bjtu.edu.cn 391 Acknowledgment 393 Funding for the RFC Editor function is currently provided by the 394 Internet Society.