idnits 2.17.1 draft-jikim-dmm-pmip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 340 has weird spacing: '... 2. If the ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2012) is 4425 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 530, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 524, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 544, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 548, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-05) exists of draft-chan-distributed-mobility-ps-02 == Outdated reference: A later version (-02) exists of draft-patil-mext-dmm-approaches-00 == Outdated reference: A later version (-01) exists of draft-kuntz-dmm-summary-00 -- Duplicate reference: RFC3775, mentioned in 'RFC3775', was also mentioned in '1'. -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Duplicate reference: RFC5213, mentioned in 'RFC5213', was also mentioned in '2'. Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobility Extensions for IPv6 (MEXT) J. Kim, S. Koh 2 Internet Draft Kyungpook National University 3 Intended status: Informational H. Jung 4 Expires: September 2012 ETRI 5 Y. Han 6 KUT 7 March 5, 2012 9 Use of Proxy Mobile IPv6 for Distributed Mobility Management 10 draft-jikim-dmm-pmip-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may not be modified, 19 and derivative works of it may not be created, and it may not be 20 published except as an Internet-Draft. 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, except to publish it 25 as an RFC and to translate it into languages other than English. 27 This document may contain material from IETF Documents or IETF 28 Contributions published or made publicly available before November 29 10, 2008. The person(s) controlling the copyright in some of this 30 material may not have granted the IETF Trust the right to allow 31 modifications of such material outside the IETF Standards Process. 32 Without obtaining an adequate license from the person(s) controlling 33 the copyright in such materials, this document may not be modified 34 outside the IETF Standards Process, and derivative works of it may 35 not be created outside the IETF Standards Process, except to format 36 it for publication as an RFC or to translate it into languages other 37 than English. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on September 5, 2012. 56 Copyright Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with 76 respect to this document. 78 Abstract 80 This document discusses how to use the Proxy Mobile IPv6 (PMIP) 81 protocol for distributed mobility management. Specifically, we 82 describe the two schemes of distributed mobility management: Signal- 83 driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD-PMIP). 85 Table of Contents 87 1. Introduction ................................................ 3 88 2. Conventions used in this document ........................... 5 89 3. Operations .................................................. 5 90 3.1. Overview ............................................... 5 91 3.2. Signal-driven PMIP(S-PMIP) ............................. 6 92 3.2.1. Procedures ........................................ 6 93 3.2.2. LMA Operations .................................... 7 94 3.2.3. MAG Operations .................................... 8 95 3.3. Signal-driven Distributed PMIP(SD-PMIP) ................ 8 96 3.3.1. Procedures ........................................ 8 97 3.3.2. MAG Operations .................................... 9 98 4. New Messages ............................................... 10 99 4.1. Proxy Binding Query(PBQ) .............................. 11 100 4.2. Proxy Query ACK(PQA) .................................. 11 101 5. Security Considerations .................................... 12 102 6. IANA Considerations ........................................ 12 103 7. References ................................................. 12 104 7.1. Normative References .................................. 12 105 7.2. Informative References ................................ 12 106 8. Acknowledgments ............................................ 13 108 1. Introduction 110 Most of the existing protocols for Internet mobility support are 111 based on the centralized approach, as shown in the Mobile IPv6 (MIP) 112 and Proxy Mobile IPv6 (PMIP), in which all control and data traffic 113 will be processed by a centralized mobility anchor, such as Home 114 Agent (HA) of MIP or Local Mobility Anchor (LMA) of PMIP. The 115 centralized mobility anchor allows a mobile host to be reachable, 116 when it is not connected to its home domain, by ensuring the 117 forwarding of packets destined to or sent from the mobile device. 118 However, such a centralized mobility scheme is vulnerable to some 119 problems. First, the centralized anchor may induce unwanted traffic 120 into the core network, which tends to give a big burden to mobile 121 network operators in terms of operational costs. In addition, a 122 single point of failure of the central anchor may affect overall 123 data transmission and degradation of performance, which will 124 increase the cost of network dimensioning and engineering. 126 To overcome the limitations of centralized mobility management, the 127 IETF has recently discussed the distributed mobility management. The 128 distributed mobility management can be classified into the partially 129 distributed approach, in which only the data plane is distributed, 130 and the fully distributed approach where both data plane and control 131 plane are distributed. In the centralized management, the routing 132 path through a centralized anchor tends to be longer, which results 133 in non-optimal routes and performance degradation, whereas the route 134 optimization will be intrinsically supported in the distributed 135 management. Moreover, the distributed mobility management can reduce 136 unnecessary traffics, if the two end hosts communicate directly each 137 other, not relying on a centralized anchor. This will also be 138 helpful to reduce the handover delay. Moreover, the centralized 139 approach is vulnerable to a single point of failure, whereas the 140 distributed approach will mitigate such problem to a local network. 142 In the partially distributed approach, the control plane is 143 separated from the data plane, and only data plane will be 144 distributed for route optimization. First, a mobile node (MN) is 145 connected to a mobility agent (MA). Then, the MA binds the location 146 of MN with the control function. If a correspondent node (CN) sends 147 a data packet toward MN, the MA will find the location of MN by 148 contacting with the control function, in which location query and 149 query acknowledgement messages can be exchanged. Based on the 150 obtained location information, the MA of CN can deliver the data 151 packets directly to the MA of MN. Now, the data packet is forwarded 152 to MN. 154 In the fully distributed architecture, both control plane and data 155 plane are distributed and it can be further classified into the 156 data-driven multicast/broadcast scheme and the peer-to-peer search 157 scheme. However, the data-driven multicast/broadcast scheme seems to 158 be not effective, since unnecessary data packets may be excessively 159 generated in the domain, since the data packets will be delivered by 160 multicast to all the MAs in the domain. On the other hand, in the 161 peer-to-peer search scheme, just before transmission of data packets, 162 a searching process will be activated among MAs in the domain to 163 find the location of MN. After network attachment, CN transmits a 164 data packet to its MA. The MA of CN will find the location of MN by 165 using an appropriate searching mechanism, such as the distributed 166 hash table (DHT). Then, the MA of MN will respond to the MN of CN. 167 Now, the MA of CN delivers the data packet to the MA of MN. The data 168 packet will be forwarded to MN. 170 In this document, we discuss how to implement the distributed 171 mobility management in the PMIP-based mobile networks. Based on the 172 PMIP, we describe the two schemes of distributed mobility management: 173 Signal-driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD- 174 PMIP). S-PMIP can be regarded as a partially distributed approach, 175 whereas SD-PMIP corresponds to the fully distributed schemes. 177 In this document, we will only focus the distributed mobility 178 management for 'intra-domain' movement of MN, since there are 179 various possible scenarios for 'inter-domain' movement. 181 2. Conventions used in this document 183 In examples, "C:" and "S:" indicate lines sent by the client and 184 server respectively. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC-2119 [RFC2119]. 190 In this document, these words will appear with that interpretation 191 only when in ALL CAPS. Lower case uses of these words are not to be 192 interpreted as carrying RFC-2119 significance. 194 3. Operations 196 3.1. Overview 198 Table 1 summarizes the main features of the existing PMIP scheme and 199 the proposed distributed mobility management schemes, S-PMIP and SD- 200 PMIP. 202 Table 1. Comparison of PMIP and Proposed DMM Schemes 203 +---------+------+--------------+---------+-----------+-----------+ 204 | Scheme |Agents| Mobility | Binding | Data | Binding | 205 | | | Architecture | Update | Delivery | Query | 206 +---------+------+--------------+---------+-----------+-----------+ 207 | PMIP | MAG | Centralized | Used | Data | Not Used | 208 | | LMA | | | driven | | 209 +---------+------+--------------+---------+-----------+-----------+ 210 | S-PMIP | MAG | Partially | Used | Signal | Used | 211 | | LMA | Distributed | | driven | (unicast) | 212 +---------+------+--------------+---------+-----------+-----------+ 213 | SD-PMIP | MAG | Fully | Not Used| Signal | Used | 214 | | | Distributed | | driven |(multicast)| 215 +---------+------+--------------+---------+-----------+-----------+ 217 The existing PMIPv6 can be regarded as a centralized architecture, 218 in which Mobile Access Gateway (MAG) performs the Proxy Binding 219 Update (PBU) operation with LMA, and the data packets are first 220 delivered to LMA and then forwarded to MN. Therefore, all control 221 and data traffics concentrate on the LMA. 223 S-PMIPv6 is a partially distributed architecture in which the 224 control plane is separated from the data plane. The PBU operation 225 will be performed between MAG and LMA, as done in PMIP. In the 226 packet delivery operation, however, the MAG of CN first finds the 227 CoA of MN, just before data delivery, by contacting with LMA. To do 228 this, the MAG of CN will transmit a newly defined Proxy Binding 229 Query (PBQ) message to LMA, and the LMA will respond with a newly 230 defined Proxy Query ACK (PQA) message to the MAG. These newly 231 defined PBQ and PQA messages will be specified in the next section. 232 In this sense, this scheme is named 'signal-driven' scheme. After 233 that, the MAG of CN will deliver the data packet directly to the MAG 234 of MN, and further to MN. 236 SD-PMIPv6 is also a fully distributed architecture, which is similar 237 to the peer-to-peer search scheme. No PBU operation is performed. In 238 the data packet delivery, on the other hand, MAG of CN will find the 239 MAG of MN by using sending a PBQ message to all of the MAGs in the 240 PMIP domain by multicast. The MAG of MN will respond with a PBA 241 message. After that, the MAG of CN will deliver the data packet 242 directly to the MAG of MN, further to MN. 244 3.2. Signal-driven PMIP(S-PMIP) 246 3.2.1. Procedures 248 +-----+ 249 2.PBU | | 5.PBQ 250 +-------------->| LMA |<--------------+ 251 | | | | 252 | +-----+ | 253 | | | | 254 | | | | 255 +-----+ 3.PBA | | 6.PQA +-----+ 256 | |<------------+ +------------>| | 257 8.Data | MAG | 7.Data | MAG | 4.Data 258 ++===| |<==============================| |<==++ 259 || +-----+ +-----+ || 260 || ^ || 261 || | || 262 || | 1. Connection setup || 263 \/ | (HoA Acquisition) || 264 +----+ | +----+ 265 | MN |---+ | CN | 266 +----+ +----+ 267 Figure 1. S-PMIP Operations 269 Figure 1 shows the operation of S-PMIP. First, MN setups a PMIP 270 connection with MAG and obtains its HoA (step 1). The MAG sends a 271 PBU message to LMA to bind HoA and CoA of MN (step 2). On receiving 272 the PBU request, LMA will create the associated binding cache entry, 273 and send a PBA message to the MAG (step 3). Now, CN sends a data 274 packet to MN (step 4). Then, the MAG of CN sends a PBQ message to 275 LMA to find the CoA (i. e., IP address of MAG) of MN (step 5). On 276 the reception of PBQ, the LMA responds with a PQA message including 277 the CoA of MN to MAG of CN, after lookup of its binding cache (step 278 6). During this process, MAG of CN may buffer the data packets 279 received from CN to prevent the packet losses. After establish the 280 tunnel, the MAG of CN sends its buffered data packets first. After 281 that, the MAG of CN sends the data packet to MAG of MN (step 7). 282 Finally, the data packet is forwarded to MN (step 8). 284 3.2.2. LMA Operations 286 For distributed mobility management of S-PMIP, the LMA must support 287 the functional capability described in this section. 289 On receiving a PBQ message from MAG, the LMA must perform the 290 following operations. 292 1. Check if the PBQ message contains the Q flag set to 1. 294 2. Find the CoA of MN by looking up the binding cache of LMA. 296 3. If the corresponding HoA-CoA entry is found in the binding 297 cache, LMA will respond to MAG of CN with a PQA message 298 containing a success indication. Otherwise, if not found, LMA 299 will respond with the PQA containing a failure indication. 301 The responding PQA message from LMA to MAG of CN is constructed as 302 follows. 304 1. Source address field in the IP header must be set to IP address 305 of LMA 307 2. Destination address filed in the IP header must be set to IP 308 address of the MAG of CN 310 3. The PBA message MUST include the CoA of MN. 312 3.2.3. MAG Operations 314 For distributed mobility management of S-PMIP, each MAG in the 315 domain must support the functional capability described in this 316 section. 318 When a data packet arrives at CN, the MAG of CN must send a PBQ 319 message to LMA so as to find the CoA of MN. During this query 320 process, MAG of CN may buffer the data packets received from CN to 321 prevent the packet losses. The detailed issue of how to buffer the 322 data packets from CN is for further study. 324 The PBQ message from MAG to LMA must be constructed, as specified 325 below. 327 1. Source address field in the IP header must contain the IP 328 address of MAG. 330 2. Destination address filed in the IP header must contain the IP 331 address of LMA. 333 3. The PBQ message must include the HoA of MN. 335 On receiving a PQA message from LMA, the MAG of CN must perform the 336 following operations. 338 1. Check if the PQA message contains the Q flag set to 1. 340 2. If the PQA message contains any failure, the associated 341 information may be forwarded to CN, which is for further study. 342 Otherwise, if it contains a success indication, the MAG of CN 343 must establish a tunnel with the MAG of MN for data delivery. 344 Then, the MAG of CN will first forward the data packets 345 buffered, if any. The subsequent data packets will be delivered 346 directly from MAG of CN to MAG of MN. 348 3.3. Signal-driven Distributed PMIP(SD-PMIP) 350 3.3.1. Procedures 352 Figure 2 shows the operation of SD-PMIP. The MN setups a PMIP 353 connection with the MAG (step 1). When CN sends a data packet to MN 354 (step 2), the MAG of CN sends a PBQ message all the MAGs in the 355 domain by multicast (step 3). For multicast transmission, it is 356 assumed that all the MAGs in the domain have already been subscribed 357 to a specific multicast address in the initialization process. Note 358 that all the MAGs in the domain are under the control of the same 359 network administrator, and that the multicast transmissions will be 360 allowed only within the local PMIP domain. In the multicast 361 transmission, the MAG of CN will encapsulate the original data 362 packet by adding an outer IP header for multicasting, in which the 363 destination address is set to a multicast address and the source 364 address is set to IP address of MAG of CN. 366 +-----+ 367 | | 3.PBQ 368 +-------------->| MAG |<--------------+ 369 | | | | 370 | +-----+ | 371 +-----+ 3.PBQ +-----+ 372 | |<------------------------------| | 373 6.Data | | 4.PQA | | 2.Data 374 ++===| MAG |------------------------------>| MAG |<==++ 375 || | | 5.Data | | || 376 || | |<==============================| | || 377 || +-----+ +-----+ +-----+ || 378 || ^ | | 3. PBQ | || 379 || | | MAG |<--------------+ || 380 || | | | || 381 || | +-----+ || 382 || | || 383 || | 1. Connection setup || 384 \/ | (HoA Acquisition) || 385 +----+ | +----+ 386 | MN |---+ | CN | 387 +----+ +----+ 388 Figure 2. SD-PMIP Operations 390 For the PBQ message transmitted by multicast, only the MAG of MN 391 will respond with a PQA message to MAG of CN (step 4). All the other 392 MAGs in the domain must ignore and drop the PBQ packet. Note that 393 the responding PQA message ensures that the further subsequent data 394 packets of CN can be delivered directly from MAG of CN to MAG of MN 395 by unicast. Now, the data packet will be delivered to MAG of MN 396 (step 5), and further to MN (step 6). 398 3.3.2. MAG Operations 400 For distributed mobility management of SD-PMIP, each MAG in the PMIP 401 domain must support the functional capability described in this 402 section. In this section, we will describe the control operations of 403 PBQ and PQA. Note that the data delivery operations of SD-PMIP are 404 the same with those of S-PMIP. 406 When a data packet arrives at CN, the MAG of CN must send a PBQ 407 message to MAG by multicast so as to find the CoA of MN. During this 408 query process, MAG of CN may buffer the data packets received from 409 CN to prevent the packet losses. The detailed issue of how to buffer 410 the data packets from CN is for further study. 412 The PBQ message from MAG to all the other MAGs must be encapsulated 413 by IP-in-IP tunneling, with the following outer header. 415 1. Source address field of outer header must contain the IP 416 address of MAG. 418 2. Destination address filed of outer header must contain a pre- 419 specified multicast address. 421 3. The PBQ message must include the HoA of MN. 423 On receiving a PBQ message from MAG of CN, the MAG of MN must 424 respond with a PQA message, as specified below. 426 1. Check if the PBQ message contains the Q flag set to 1. 428 2. Find the CoA of MN by looking up the binding cache of MAG. 430 3. If the corresponding HoA-CoA entry is found in the binding 431 cache, the MAG of MN will respond to the MAG of CN with a 432 success indication. Otherwise, if not found, it may not respond 433 or may respond with a failure indication. 435 The responding PQA message of MAG of MN to MAG of CN is constructed 436 as follows. 438 1. Source address field in the IP header must be set to the IP 439 address of MAG of MN. 441 2. Destination address filed in the IP header must be set to the 442 IP address of MAG of CN. 444 4. New Messages 446 In the S-PMIP and SD-PMIP schemes, the following two messages are 447 newly defined. The PBQ message is an extension of the PBU message, 448 whereas the PQA message is an extension of the PBA message. 450 4.1. Proxy Binding Query(PBQ) 452 The PBQ message is made by adding a new flag (Q) to the PBU message 453 of PMIP. The rest of the PBU message remains unchanged. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Sequence # | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |A|H|L|K|M|R|P|Q| Reserved | Lifetime | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 . . 464 . Mobility Options . 465 . . 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Query Flag (Q) 472 A new flag (Q) must be set, if the PBU message is used to find 473 the CoA of MN in S-PMIP and SD-PMIP. In the normal PMIP operation, 474 the flag must be set to 0. 476 4.2. Proxy Query ACK(PQA) 478 The PQA message is made by adding a new flag (Q) to the PBA message 479 of PMIP. The rest of the PBA message remains unchanged. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Status |K|R|P|Q|Reserve| 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Sequence # | Lifetime | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | | 489 . . 490 . Mobility Options . 491 . . 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Query Flag (Q) 498 A new flag (Q) must be set, if the PBA message is used as a 499 response to the PBQ in S-PMIP and SD-PMIP. In the normal PMIP 500 operation, the flag must be set to 0. 502 5. Security Considerations 504 TBD 506 6. IANA Considerations 508 TBD 510 7. References 512 7.1. Normative References 514 [1] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 518 Syntax Specifications: ABNF", RFC 2234, Internet Mail 519 Consortium and Demon Internet Ltd., November 1997. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 525 Syntax Specifications: ABNF", RFC 2234, Internet Mail 526 Consortium and Demon Internet Ltd., November 1997. 528 7.2. Informative References 530 [1] Johnson, D., et al., "Mobility Support in IPv6", RFC 3775, 531 June 2004. 533 [2] Gundavelli, S., et al., "Proxy Mobile IPv6", RFC 5213, August 534 2008. 536 [3] Chan, H., et al., "Problem Statement for Distributed and 537 Dynamic Mobility Management", IETF Internet-Draft, draft-chan- 538 distributed-mobility-ps-02, March 2011. 540 [4] Yokota, H., et al., "Use case Scenarios for Distributed 541 Mobility Management", IETF Internet-Draft, draft-yokota-dmm- 542 scenario-00, October 2010. 544 [5] Liu D., et al., "Distributed Deployment of Mobile IPv6", IETF 545 Internet Draft, draft-liu-mext-distributed-mobile-ip-00, March 546 2011. 548 [6] Patil B., et al., "Approaches to Distributed mobility 549 management using Mobile IPv6 and its extensions", IETF 550 Internet Draft, draft-patil-mext-dmm-approaches-00, March 2011. 552 [7] Kuntz R., et al., "A Summary of Distributed Mobility 553 Management", IETF Internet Draft, draft-kuntz-dmm-summary-00, 554 May 2011. 556 [RFC3775] D. Johnson, C. Perkins, and K. Arkko, "Mobility support in 557 IPv6", RFC 3775, June 2004. 559 [RFC5213] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and 560 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 562 8. Acknowledgments 564 This document was prepared using 2-Word-v2.0.template.dot. 566 Authors' Addresses 568 Ji In Kim 570 Kyungpook National University, KOREA 572 Email: jiin16@gmail.com 574 Seok Joo Koh 576 Kyungpook National University, KOREA 578 Email: sjkoh@knu.ac.kr 580 Hee Young Jung 582 Electronics and Telecommunications Research Institute, KOREA 584 Email: hyjung@etri.re.kr 586 Youn-Hee Han 588 Korea University of Technology and Education, KOREA 590 Email: yhhan@kut.ac.kr