[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Mobility Extensions for IPv6 (MEXT)                      J. Kim, S. Koh
Internet Draft                            Kyungpook National University
Intended status: Informational                                  H. Jung
Expires: September 2012                                            ETRI
                                                                 Y. Han
                                                                    KUT
                                                          March 5, 2012


        Use of Proxy Mobile IPv6 for Distributed Mobility Management
                        draft-jikim-dmm-pmip-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."



Kim, Koh, Jung & Han   Expires September 2012                 [Page 1]


Internet-Draft                PMIP-DMM                  September 2012


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 5, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   This document discusses how to use the Proxy Mobile IPv6 (PMIP)
   protocol for distributed mobility management. Specifically, we
   describe the two schemes of distributed mobility management: Signal-
   driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD-PMIP).












Kim, Koh, Jung & Han   Expires September 2012                 [Page 2]


Internet-Draft                PMIP-DMM                  September 2012


Table of Contents


   1. Introduction ................................................ 3
   2. Conventions used in this document ........................... 5
   3. Operations .................................................. 5
      3.1. Overview ............................................... 5
      3.2. Signal-driven PMIP(S-PMIP) ............................. 6
         3.2.1. Procedures ........................................ 6
         3.2.2. LMA Operations .................................... 7
         3.2.3. MAG Operations .................................... 8
      3.3. Signal-driven Distributed PMIP(SD-PMIP) ................ 8
         3.3.1. Procedures ........................................ 8
         3.3.2. MAG Operations .................................... 9
   4. New Messages ............................................... 10
      4.1. Proxy Binding Query(PBQ) .............................. 11
      4.2. Proxy Query ACK(PQA) .................................. 11
   5. Security Considerations .................................... 12
   6. IANA Considerations ........................................ 12
   7. References ................................................. 12
      7.1. Normative References .................................. 12
      7.2. Informative References ................................ 12
   8. Acknowledgments ............................................ 13

1. Introduction

   Most of the existing protocols for Internet mobility support are
   based on the centralized approach, as shown in the Mobile IPv6 (MIP)
   and Proxy Mobile IPv6 (PMIP), in which all control and data traffic
   will be processed by a centralized mobility anchor, such as Home
   Agent (HA) of MIP or Local Mobility Anchor (LMA) of PMIP. The
   centralized mobility anchor allows a mobile host to be reachable,
   when it is not connected to its home domain, by ensuring the
   forwarding of packets destined to or sent from the mobile device.
   However, such a centralized mobility scheme is vulnerable to some
   problems. First, the centralized anchor may induce unwanted traffic
   into the core network, which tends to give a big burden to mobile
   network operators in terms of operational costs. In addition, a
   single point of failure of the central anchor may affect overall
   data transmission and degradation of performance, which will
   increase the cost of network dimensioning and engineering.

   To overcome the limitations of centralized mobility management, the
   IETF has recently discussed the distributed mobility management. The
   distributed mobility management can be classified into the partially
   distributed approach, in which only the data plane is distributed,
   and the fully distributed approach where both data plane and control


Kim, Koh, Jung & Han   Expires September 2012                 [Page 3]


Internet-Draft                PMIP-DMM                  September 2012


   plane are distributed. In the centralized management, the routing
   path through a centralized anchor tends to be longer, which results
   in non-optimal routes and performance degradation, whereas the route
   optimization will be intrinsically supported in the distributed
   management. Moreover, the distributed mobility management can reduce
   unnecessary traffics, if the two end hosts communicate directly each
   other, not relying on a centralized anchor. This will also be
   helpful to reduce the handover delay. Moreover, the centralized
   approach is vulnerable to a single point of failure, whereas the
   distributed approach will mitigate such problem to a local network.

   In the partially distributed approach, the control plane is
   separated from the data plane, and only data plane will be
   distributed for route optimization. First, a mobile node (MN) is
   connected to a mobility agent (MA). Then, the MA binds the location
   of MN with the control function. If a correspondent node (CN) sends
   a data packet toward MN, the MA will find the location of MN by
   contacting with the control function, in which location query and
   query acknowledgement messages can be exchanged. Based on the
   obtained location information, the MA of CN can deliver the data
   packets directly to the MA of MN. Now, the data packet is forwarded
   to MN.

   In the fully distributed architecture, both control plane and data
   plane are distributed and it can be further classified into the
   data-driven multicast/broadcast scheme and the peer-to-peer search
   scheme. However, the data-driven multicast/broadcast scheme seems to
   be not effective, since unnecessary data packets may be excessively
   generated in the domain, since the data packets will be delivered by
   multicast to all the MAs in the domain. On the other hand, in the
   peer-to-peer search scheme, just before transmission of data packets,
   a searching process will be activated among MAs in the domain to
   find the location of MN. After network attachment, CN transmits a
   data packet to its MA. The MA of CN will find the location of MN by
   using an appropriate searching mechanism, such as the distributed
   hash table (DHT). Then, the MA of MN will respond to the MN of CN.
   Now, the MA of CN delivers the data packet to the MA of MN. The data
   packet will be forwarded to MN.

   In this document, we discuss how to implement the distributed
   mobility management in the PMIP-based mobile networks. Based on the
   PMIP, we describe the two schemes of distributed mobility management:
   Signal-driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD-
   PMIP). S-PMIP can be regarded as a partially distributed approach,
   whereas SD-PMIP corresponds to the fully distributed schemes.




Kim, Koh, Jung & Han   Expires September 2012                 [Page 4]


Internet-Draft                PMIP-DMM                  September 2012


   In this document, we will only focus the distributed mobility
   management for 'intra-domain' movement of MN, since there are
   various possible scenarios for 'inter-domain' movement.



2. Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. Operations

3.1. Overview

   Table 1 summarizes the main features of the existing PMIP scheme and
   the proposed distributed mobility management schemes, S-PMIP and SD-
   PMIP.

            Table 1. Comparison of PMIP and Proposed DMM Schemes
    +---------+------+--------------+---------+-----------+-----------+
    |  Scheme |Agents|   Mobility   | Binding |   Data    |  Binding  |
    |         |      | Architecture |  Update |  Delivery |   Query   |
    +---------+------+--------------+---------+-----------+-----------+
    |   PMIP  |  MAG |  Centralized |   Used  |    Data   |  Not Used |
    |         |  LMA |              |         |   driven  |           |
    +---------+------+--------------+---------+-----------+-----------+
    |  S-PMIP |  MAG |   Partially  |   Used  |   Signal  |   Used    |
    |         |  LMA |  Distributed |         |   driven  | (unicast) |
    +---------+------+--------------+---------+-----------+-----------+
    | SD-PMIP |  MAG |     Fully    | Not Used|   Signal  |   Used    |
    |         |      |  Distributed |         |   driven  |(multicast)|
    +---------+------+--------------+---------+-----------+-----------+

   The existing PMIPv6 can be regarded as a centralized architecture,
   in which Mobile Access Gateway (MAG) performs the Proxy Binding
   Update (PBU) operation with LMA, and the data packets are first
   delivered to LMA and then forwarded to MN. Therefore, all control
   and data traffics concentrate on the LMA.


Kim, Koh, Jung & Han   Expires September 2012                 [Page 5]


Internet-Draft                PMIP-DMM                  September 2012


   S-PMIPv6 is a partially distributed architecture in which the
   control plane is separated from the data plane. The PBU operation
   will be performed between MAG and LMA, as done in PMIP. In the
   packet delivery operation, however, the MAG of CN first finds the
   CoA of MN, just before data delivery, by contacting with LMA. To do
   this, the MAG of CN will transmit a newly defined Proxy Binding
   Query (PBQ) message to LMA, and the LMA will respond with a newly
   defined Proxy Query ACK (PQA) message to the MAG. These newly
   defined PBQ and PQA messages will be specified in the next section.
   In this sense, this scheme is named 'signal-driven' scheme. After
   that, the MAG of CN will deliver the data packet directly to the MAG
   of MN, and further to MN.

   SD-PMIPv6 is also a fully distributed architecture, which is similar
   to the peer-to-peer search scheme. No PBU operation is performed. In
   the data packet delivery, on the other hand, MAG of CN will find the
   MAG of MN by using sending a PBQ message to all of the MAGs in the
   PMIP domain by multicast. The MAG of MN will respond with a PBA
   message. After that, the MAG of CN will deliver the data packet
   directly to the MAG of MN, further to MN.

3.2. Signal-driven PMIP(S-PMIP)

3.2.1. Procedures

                                  +-----+
                       2.PBU      |     |     5.PBQ
                  +-------------->| LMA |<--------------+
                  |               |     |               |
                  |               +-----+               |
                  |                |   |                |
                  |                |   |                |
               +-----+    3.PBA    |   |    6.PQA    +-----+
               |     |<------------+   +------------>|     |
        8.Data | MAG |            7.Data             | MAG |  4.Data
          ++===|     |<==============================|     |<==++
          ||   +-----+                               +-----+   ||
          ||     ^                                             ||
          ||     |                                             ||
          ||     | 1. Connection setup                         ||
          \/     |   (HoA Acquisition)                         ||
        +----+   |                                           +----+
        | MN |---+                                           | CN |
        +----+                                               +----+
                        Figure 1. S-PMIP Operations




Kim, Koh, Jung & Han   Expires September 2012                 [Page 6]


Internet-Draft                PMIP-DMM                  September 2012


   Figure 1 shows the operation of S-PMIP. First, MN setups a PMIP
   connection with MAG and obtains its HoA (step 1). The MAG sends a
   PBU message to LMA to bind HoA and CoA of MN (step 2). On receiving
   the PBU request, LMA will create the associated binding cache entry,
   and send a PBA message to the MAG (step 3). Now, CN sends a data
   packet to MN (step 4). Then, the MAG of CN sends a PBQ message to
   LMA to find the CoA (i. e., IP address of MAG) of MN (step 5). On
   the reception of PBQ, the LMA responds with a PQA message including
   the CoA of MN to MAG of CN, after lookup of its binding cache (step
   6). During this process, MAG of CN may buffer the data packets
   received from CN to prevent the packet losses. After establish the
   tunnel, the MAG of CN sends its buffered data packets first. After
   that, the MAG of CN sends the data packet to MAG of MN (step 7).
   Finally, the data packet is forwarded to MN (step 8).

3.2.2. LMA Operations

   For distributed mobility management of S-PMIP, the LMA must support
   the functional capability described in this section.

   On receiving a PBQ message from MAG, the LMA must perform the
   following operations.

      1. Check if the PBQ message contains the Q flag set to 1.

      2. Find the CoA of MN by looking up the binding cache of LMA.

      3. If the corresponding HoA-CoA entry is found in the binding
         cache, LMA will respond to MAG of CN with a PQA message
         containing a success indication. Otherwise, if not found, LMA
         will respond with the PQA containing a failure indication.

   The responding PQA message from LMA to MAG of CN is constructed as
   follows.

      1. Source address field in the IP header must be set to IP address
         of LMA

      2. Destination address filed in the IP header must be set to IP
         address of the MAG of CN

      3. The PBA message MUST include the CoA of MN.







Kim, Koh, Jung & Han   Expires September 2012                 [Page 7]


Internet-Draft                PMIP-DMM                  September 2012


3.2.3. MAG Operations

   For distributed mobility management of S-PMIP, each MAG in the
   domain must support the functional capability described in this
   section.

   When a data packet arrives at CN, the MAG of CN must send a PBQ
   message to LMA so as to find the CoA of MN. During this query
   process, MAG of CN may buffer the data packets received from CN to
   prevent the packet losses. The detailed issue of how to buffer the
   data packets from CN is for further study.

   The PBQ message from MAG to LMA must be constructed, as specified
   below.

      1. Source address field in the IP header must contain the IP
         address of MAG.

      2. Destination address filed in the IP header must contain the IP
         address of LMA.

      3. The PBQ message must include the HoA of MN.

   On receiving a PQA message from LMA, the MAG of CN must perform the
   following operations.

      1. Check if the PQA message contains the Q flag set to 1.

      2. If  the  PQA  message  contains  any  failure,  the  associated
         information may be forwarded to CN, which is for further study.
         Otherwise, if it contains a success indication, the MAG of CN
         must establish a tunnel with the MAG of MN for data delivery.
         Then, the MAG of CN will first forward the data packets
         buffered, if any. The subsequent data packets will be delivered
         directly from MAG of CN to MAG of MN.

3.3. Signal-driven Distributed PMIP(SD-PMIP)

3.3.1. Procedures

   Figure 2 shows the operation of SD-PMIP. The MN setups a PMIP
   connection with the MAG (step 1). When CN sends a data packet to MN
   (step 2), the MAG of CN sends a PBQ message all the MAGs in the
   domain by multicast (step 3). For multicast transmission, it is
   assumed that all the MAGs in the domain have already been subscribed
   to a specific multicast address in the initialization process. Note
   that all the MAGs in the domain are under the control of the same


Kim, Koh, Jung & Han   Expires September 2012                 [Page 8]


Internet-Draft                PMIP-DMM                  September 2012


   network administrator, and that the multicast transmissions will be
   allowed only within the local PMIP domain. In the multicast
   transmission, the MAG of CN will encapsulate the original data
   packet by adding an outer IP header for multicasting, in which the
   destination address is set to a multicast address and the source
   address is set to IP address of MAG of CN.

                                  +-----+
                                  |     |     3.PBQ
                  +-------------->| MAG |<--------------+
                  |               |     |               |
                  |               +-----+               |
               +-----+             3.PBQ             +-----+
               |     |<------------------------------|     |
        6.Data |     |             4.PQA             |     |  2.Data
          ++===| MAG |------------------------------>| MAG |<==++
          ||   |     |             5.Data            |     |   ||
          ||   |     |<==============================|     |   ||
          ||   +-----+            +-----+            +-----+   ||
          ||     ^                |     |     3. PBQ    |      ||
          ||     |                | MAG |<--------------+      ||
          ||     |                |     |                      ||
          ||     |                +-----+                      ||
          ||     |                                             ||
          ||     | 1. Connection setup                         ||
          \/     |   (HoA Acquisition)                         ||
        +----+   |                                           +----+
        | MN |---+                                           | CN |
        +----+                                               +----+
                       Figure 2. SD-PMIP Operations

   For the PBQ message transmitted by multicast, only the MAG of MN
   will respond with a PQA message to MAG of CN (step 4). All the other
   MAGs in the domain must ignore and drop the PBQ packet. Note that
   the responding PQA message ensures that the further subsequent data
   packets of CN can be delivered directly from MAG of CN to MAG of MN
   by unicast. Now, the data packet will be delivered to MAG of MN
   (step 5), and further to MN (step 6).

3.3.2. MAG Operations

   For distributed mobility management of SD-PMIP, each MAG in the PMIP
   domain must support the functional capability described in this
   section. In this section, we will describe the control operations of
   PBQ and PQA. Note that the data delivery operations of SD-PMIP are
   the same with those of S-PMIP.



Kim, Koh, Jung & Han   Expires September 2012                 [Page 9]


Internet-Draft                PMIP-DMM                  September 2012


   When a data packet arrives at CN, the MAG of CN must send a PBQ
   message to MAG by multicast so as to find the CoA of MN. During this
   query process, MAG of CN may buffer the data packets received from
   CN to prevent the packet losses. The detailed issue of how to buffer
   the data packets from CN is for further study.

   The PBQ message from MAG to all the other MAGs must be encapsulated
   by IP-in-IP tunneling, with the following outer header.

      1. Source address field of outer header must contain the IP
         address of MAG.

      2. Destination address filed of outer header must contain a pre-
         specified multicast address.

      3. The PBQ message must include the HoA of MN.

   On receiving a PBQ message from MAG of CN, the MAG of MN must
   respond with a PQA message, as specified below.

      1. Check if the PBQ message contains the Q flag set to 1.

      2. Find the CoA of MN by looking up the binding cache of MAG.

      3. If the corresponding HoA-CoA entry is found in the binding
         cache, the MAG of MN will respond to the MAG of CN with a
         success indication. Otherwise, if not found, it may not respond
         or may respond with a failure indication.

   The responding PQA message of MAG of MN to MAG of CN is constructed
   as follows.

      1. Source address field in the IP header must be set to the IP
         address of MAG of MN.

      2. Destination address filed in the IP header must be set to the
         IP address of MAG of CN.

4. New Messages

   In the S-PMIP and SD-PMIP schemes, the following two messages are
   newly defined. The PBQ message is an extension of the PBU message,
   whereas the PQA message is an extension of the PBA message.






Kim, Koh, Jung & Han   Expires September 2012                [Page 10]


Internet-Draft                PMIP-DMM                  September 2012


4.1. Proxy Binding Query(PBQ)

   The PBQ message is made by adding a new flag (Q) to the PBU message
   of PMIP. The rest of the PBU message remains unchanged.

     0               1               2               3
     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
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |            Sequence #         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|L|K|M|R|P|Q|    Reserved   |             Lifetime          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Mobility Options                        .
    .                                                               .

    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Query Flag (Q)

      A new flag (Q) must be set, if the PBU message is used to find
      the CoA of MN in S-PMIP and SD-PMIP. In the normal PMIP operation,
      the flag must be set to 0.

4.2. Proxy Query ACK(PQA)

   The PQA message is made by adding a new flag (Q) to the PBA message
   of PMIP. The rest of the PBA message remains unchanged.

     0               1               2               3
     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
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |     Status    |K|R|P|Q|Reserve|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Sequence #           |             Lifetime          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Mobility Options                        .
    .                                                               .

    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Kim, Koh, Jung & Han   Expires September 2012                [Page 11]


Internet-Draft                PMIP-DMM                  September 2012


   Query Flag (Q)

      A new flag (Q) must be set, if the PBA message is used as a
      response to the PBQ in S-PMIP and SD-PMIP. In the normal PMIP
      operation, the flag must be set to 0.

5. Security Considerations

   TBD

6. IANA Considerations

   TBD

7. References

7.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and Overell, P.(Editors), "Augmented BNF for
         Syntax Specifications: ABNF", RFC 2234, Internet Mail
         Consortium and Demon Internet Ltd., November 1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
             Syntax Specifications: ABNF", RFC 2234, Internet Mail
             Consortium and Demon Internet Ltd., November 1997.

7.2. Informative References

   [1]  Johnson, D., et al., "Mobility Support in IPv6", RFC 3775,
        June 2004.

   [2]  Gundavelli, S., et al., "Proxy Mobile IPv6", RFC 5213, August
        2008.

   [3]  Chan, H., et al., "Problem Statement for Distributed and
        Dynamic Mobility Management", IETF Internet-Draft, draft-chan-
        distributed-mobility-ps-02, March 2011.

   [4]  Yokota, H., et al., "Use case Scenarios for Distributed
        Mobility Management", IETF Internet-Draft, draft-yokota-dmm-
        scenario-00, October 2010.


Kim, Koh, Jung & Han   Expires September 2012                [Page 12]


Internet-Draft                PMIP-DMM                  September 2012


   [5]  Liu D., et al., "Distributed Deployment of Mobile IPv6", IETF
        Internet Draft, draft-liu-mext-distributed-mobile-ip-00, March
        2011.

   [6]  Patil B., et al., "Approaches to Distributed mobility
        management using Mobile IPv6 and its extensions", IETF
        Internet Draft, draft-patil-mext-dmm-approaches-00, March 2011.

   [7]  Kuntz R., et al., "A Summary of Distributed Mobility
        Management", IETF Internet Draft, draft-kuntz-dmm-summary-00,
        May 2011.

   [RFC3775] D. Johnson, C. Perkins, and K. Arkko, "Mobility support in
             IPv6", RFC 3775, June 2004.

   [RFC5213] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and
             B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

8. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



























Kim, Koh, Jung & Han   Expires September 2012                [Page 13]


Internet-Draft                PMIP-DMM                  September 2012


Authors' Addresses

   Ji In Kim

     Kyungpook National University, KOREA

     Email: jiin16@gmail.com


   Seok Joo Koh

     Kyungpook National University, KOREA

     Email: sjkoh@knu.ac.kr


   Hee Young Jung

     Electronics and Telecommunications Research Institute, KOREA

     Email: hyjung@etri.re.kr


   Youn-Hee Han

     Korea University of Technology and Education, KOREA

     Email: yhhan@kut.ac.kr




















Kim, Koh, Jung & Han   Expires September 2012                [Page 14]