idnits 2.17.1 draft-sjkoh-mext-pmip-dmc-03.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 339 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 (June 30, 2011) is 4676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 523, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 535, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 558, 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) S. Koh, J. Kim 2 Internet Draft Kyungpook National University 3 Intended status: Informational H. Jung 4 Expires: December 2011 ETRI 5 Y. Han 6 KUT 7 June 30, 2011 9 Use of Proxy Mobile IPv6 for Distributed Mobility Control 10 draft-sjkoh-mext-pmip-dmc-03.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 December 30, 2011. 56 Copyright Notice 58 Copyright (c) 2011 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 control. Specifically, we describe 82 the two schemes of distributed mobility control: Signal-driven PMIP 83 (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 .................................... 7 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) .............................. 10 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 control in the PMIP-based mobile networks. Based on the 172 PMIP, we describe the two schemes of distributed mobility control: 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 control for 'intra-domain' movement of MN, since there are various 179 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 control schemes, S-PMIP and SD- 200 PMIP. 202 Table 1. Comparison of PMIP and Distributed Mobility Control 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 control of S-PMIP, the LMA must support the 287 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 control of S-PMIP, each MAG in the domain 315 must support the functional capability described in this section. 317 When a data packet arrives at CN, the MAG of CN must send a PBQ 318 message to LMA so as to find the CoA of MN. During this query 319 process, MAG of CN may buffer the data packets received from CN to 320 prevent the packet losses. The detailed issue of how to buffer the 321 data packets from CN is for further study. 323 The PBQ message from MAG to LMA must be constructed, as specified 324 below. 326 1. Source address field in the IP header must contain the IP 327 address of MAG. 329 2. Destination address filed in the IP header must contain the IP 330 address of LMA. 332 3. The PBQ message must include the HoA of MN. 334 On receiving a PQA message from LMA, the MAG of CN must perform the 335 following operations. 337 1. Check if the PQA message contains the Q flag set to 1. 339 2. If the PQA message contains any failure, the associated 340 information may be forwarded to CN, which is for further study. 341 Otherwise, if it contains a success indication, the MAG of CN 342 must establish a tunnel with the MAG of MN for data delivery. 343 Then, the MAG of CN will first forward the data packets 344 buffered, if any. The subsequent data packets will be delivered 345 directly from MAG of CN to MAG of MN. 347 3.3. Signal-driven Distributed PMIP(SD-PMIP) 349 3.3.1. Procedures 351 Figure 2 shows the operation of SD-PMIP. The MN setups a PMIP 352 connection with the MAG (step 1). When CN sends a data packet to MN 353 (step 2), the MAG of CN sends a PBQ message all the MAGs in the 354 domain by multicast (step 3). For multicast transmission, it is 355 assumed that all the MAGs in the domain have already been subscribed 356 to a specific multicast address in the initialization process. Note 357 that all the MAGs in the domain are under the control of the same 358 network administrator, and that the multicast transmissions will be 359 allowed only within the local PMIP domain. In the multicast 360 transmission, the MAG of CN will encapsulate the original data 361 packet by adding an outer IP header for multicasting, in which the 362 destination address is set to a multicast address and the source 363 address is set to IP address of MAG of CN. 365 +-----+ 366 | | 3.PBQ 367 +-------------->| MAG |<--------------+ 368 | | | | 369 | +-----+ | 370 +-----+ 3.PBQ +-----+ 371 | |<------------------------------| | 372 6.Data | | 4.PQA | | 2.Data 373 ++===| MAG |------------------------------>| MAG |<==++ 374 || | | 5.Data | | || 375 || | |<==============================| | || 376 || +-----+ +-----+ +-----+ || 377 || ^ | | 3. PBQ | || 378 || | | MAG |<--------------+ || 379 || | | | || 380 || | +-----+ || 381 || | || 382 || | 1. Connection setup || 383 \/ | (HoA Acquisition) || 384 +----+ | +----+ 385 | MN |---+ | CN | 386 +----+ +----+ 387 Figure 2. SD-PMIP Operations 389 For the PBQ message transmitted by multicast, only the MAG of MN 390 will respond with a PQA message to MAG of CN (step 4). All the other 391 MAGs in the domain must ignore and drop the PBQ packet. Note that 392 the responding PQA message ensures that the further subsequent data 393 packets of CN can be delivered directly from MAG of CN to MAG of MN 394 by unicast. Now, the data packet will be delivered to MAG of MN 395 (step 5), and further to MN (step 6). 397 3.3.2. MAG Operations 399 For distributed mobility control of SD-PMIP, each MAG in the PMIP 400 domain must support the functional capability described in this 401 section. In this section, we will describe the control operations of 402 PBQ and PQA. Note that the data delivery operations of SD-PMIP are 403 the same with those of S-PMIP. 405 When a data packet arrives at CN, the MAG of CN must send a PBQ 406 message to MAG by multicast so as to find the CoA of MN. During this 407 query process, MAG of CN may buffer the data packets received from 408 CN to prevent the packet losses. The detailed issue of how to buffer 409 the data packets from CN is for further study. 411 The PBQ message from MAG to all the other MAGs must be encapsulated 412 by IP-in-IP tunneling, with the following outer header. 414 1. Source address field of outer header must contain the IP 415 address of MAG. 417 2. Destination address filed of outer header must contain a pre- 418 specified multicast address. 420 3. The PBQ message must include the HoA of MN. 422 On receiving a PBQ message from MAG of CN, the MAG of MN must 423 respond with a PQA message, as specified below. 425 1. Check if the PBQ message contains the Q flag set to 1. 427 2. Find the CoA of MN by looking up the binding cache of MAG. 429 3. If the corresponding HoA-CoA entry is found in the binding 430 cache, the MAG of MN will respond to the MAG of CN with a 431 success indication. Otherwise, if not found, it may not respond 432 or may respond with a failure indication. 434 The responding PQA message of MAG of MN to MAG of CN is constructed 435 as follows. 437 1. Source address field in the IP header must be set to the IP 438 address of MAG of MN. 440 2. Destination address filed in the IP header must be set to the 441 IP address of MAG of CN. 443 4. New Messages 445 In the S-PMIP and SD-PMIP schemes, the following two messages are 446 newly defined. The PBQ message is an extension of the PBU message, 447 whereas the PQA message is an extension of the PBA message. 449 4.1. Proxy Binding Query(PBQ) 451 The PBQ message is made by adding a new flag (Q) to the PBU message 452 of PMIP. The rest of the PBU message remains unchanged. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Sequence # | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |A|H|L|K|M|R|P|Q| Reserved | Lifetime | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 . . 463 . Mobility Options . 464 . . 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Query Flag (Q) 471 A new flag (Q) must be set, if the PBU message is used to find 472 the CoA of MN in S-PMIP and SD-PMIP. In the normal PMIP operation, 473 the flag must be set to 0. 475 4.2. Proxy Query ACK(PQA) 477 The PQA message is made by adding a new flag (Q) to the PBA message 478 of PMIP. The rest of the PBA message remains unchanged. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Status |K|R|P|Q|Reserve| 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Sequence # | Lifetime | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | 488 . . 489 . Mobility Options . 490 . . 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Query Flag (Q) 497 A new flag (Q) must be set, if the PBA message is used as a 498 response to the PBQ in S-PMIP and SD-PMIP. In the normal PMIP 499 operation, the flag must be set to 0. 501 5. Security Considerations 503 TBD 505 6. IANA Considerations 507 TBD 509 7. References 511 7.1. Normative References 513 [1] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 517 Syntax Specifications: ABNF", RFC 2234, Internet Mail 518 Consortium and Demon Internet Ltd., November 1997. 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 524 Syntax Specifications: ABNF", RFC 2234, Internet Mail 525 Consortium and Demon Internet Ltd., November 1997. 527 7.2. Informative References 529 [1] Johnson, D., et al., "Mobility Support in IPv6", RFC 3775, 530 June 2004. 532 [2] Gundavelli, S., et al., "Proxy Mobile IPv6", RFC 5213, August 533 2008. 535 [3] Chan, H., et al., "Problem Statement for Distributed and 536 Dynamic Mobility Management", IETF Internet-Draft, draft-chan- 537 distributed-mobility-ps-02, March 2011. 539 [4] Yokota, H., et al., "Use case Scenarios for Distributed 540 Mobility Management", IETF Internet-Draft, draft-yokota-dmm- 541 scenario-00, October 2010. 543 [5] Liu D., et al., "Distributed Deployment of Mobile IPv6", IETF 544 Internet Draft, draft-liu-mext-distributed-mobile-ip-00, March 545 2011. 547 [6] Patil B., et al., "Approaches to Distributed mobility 548 management using Mobile IPv6 and its extensions", IETF 549 Internet Draft, draft-patil-mext-dmm-approaches-00, March 2011. 551 [7] Kuntz R., et al., "A Summary of Distributed Mobility 552 Management", IETF Internet Draft, draft-kuntz-dmm-summary-00, 553 May 2011. 555 [RFC3775] D. Johnson, C. Perkins, and K. Arkko, "Mobility support in 556 IPv6", RFC 3775, June 2004. 558 [RFC5213] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and 559 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 561 8. Acknowledgments 563 This document was prepared using 2-Word-v2.0.template.dot. 565 Authors' Addresses 567 Seok Joo Koh 569 Kyungpook National University, KOREA 571 Email: sjkoh@knu.ac.kr 573 Ji In Kim 575 Kyungpook National University, KOREA 577 Email: jiin16@gmail.com 579 Hee Young Jung 581 Electronics and Telecommunications Research Institute, KOREA 583 Email: hyjung@etri.re.kr 585 Youn-Hee Han 587 Korea University of Technology and Education, KOREA 589 Email: yhhan@kut.ac.kr