MIPSHOP WG Y. Han Internet-Draft KUT Intended status: Informational P. Kim Expires: August 22, 2009 KPU February 18, 2009 Reverse Binding for Proxy Mobile IPv6 draft-han-mipshop-reverse-binding-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." 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 August 22, 2009. Copyright Notice Copyright (c) 2009 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. Abstract This memo proposes a scheme that utilizes only pre-established bi- Han & Kim Expires August 22, 2009 [Page 1] Internet-Draft Reverse Binding for PMIPv6 February 2009 directional tunnels between LMA and MAGs to support a fast handover effectively in Proxy Mobile IPv6. To expedite the handover procedure, we define new signaling messages, Fast PBU/PBA and Reverse PBU/PBA, exchanged by LMA and MAGs. Because any signaling messages exchanged by two MAGs are neither created nor utilized and thus bi- directional tunnel between MAGs is not created, the proposed scheme put less overload upon network than the existing fast handover scheme for PMIPv6. It can also tackle effectively with the so-called ping- pong movement of mobile nodes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 4. Handoff Type Considerations . . . . . . . . . . . . . . . . . . 7 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Fast Binding option . . . . . . . . . . . . . . . . . . . . 7 5.2. Fast Binding Acknowledgement option . . . . . . . . . . . . 7 5.3. Reverse Binding option . . . . . . . . . . . . . . . . . . 7 5.4. Reverse Binding Acknowledgement option . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Han & Kim Expires August 22, 2009 [Page 2] Internet-Draft Reverse Binding for PMIPv6 February 2009 1. Introduction The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local mobility management to a mobile node without requiring any modification of the mobile node. But, PMIPv6's handover could cause undesirable delay to the mobile nodes running real time applications like VoIP. This memo proposes a scheme that supports a fast handover effectively in PMIPv6 by optimizing the associated data and signaling flows during the handover. FMIPv6 (Fast Handover for Mobile IPv6) [RFC5268] is a well-known fast handover scheme for the host-based Mobile IPv6. It may be harnessed to enhance PMIPv6's handover performance. Actually, a scheme has been proposed based on the FMIPv6's strategy (see [I-D.draft-ietf-mipshop-pfmipv6]). However, they induce unnecessary processing overhead for re-tunneling at the MAGs, as well as inefficient usage of network bandwidth if there are no direct secure links between them. The main reason for this is that the data transport of PMIPv6 is based on the tunneling from the LMA to the MAG, not between MAGs, while the FMIPv6 and the existing scheme [I-D.draft-ietf-mipshop-pfmipv6] use the tunneling between the previous MAG and new MAG to forward the data in transit during handover. We propose a new PMIPv6's fast handover scheme to overcome such ineffectiveness by defining the signaling messages, Fast PBU/PBA and Reverse PBU/PBA, exchanged between LAM and MAGs. The proposed scheme utilizes only pre-established bi-directional tunnels between LMA and MAGs. Because any signaling messages exchanged by two MAGs are neither created nor utilized and thus bi-directional tunnel between MAGs is not created, the proposed scheme put less overload upon network than the existing fast handover scheme for PMIPv6. It can also tackle effectively with the so-called ping-pong movement of mobile nodes. During handover procedure, the FMIPv6 and the existing scheme [I-D.draft-ietf-mipshop-pfmipv6] compell a mobile node's uplink traffic to be tunnelled to the previous MAG, and then to the LMA. This zigzag path of data traffic can produce poor throughput. Besides, as [I-D.draft-ietf-mipshop-transient-bce-pmipv6-01] mentioned, currently and as per PMIPv6 base protocol [RFC5268], the LMA forwards a mobile node's uplink traffic received from a tunnel only as long as the source IP address of the node's uplink traffic matches the IP address of the node's registered Proxy-CoA in the associated binding cache entry. As a result, packets received at the LMA from the node's previous MAG after the LMA has already switched the tunnel to point to the new MAG will be dropped. Han & Kim Expires August 22, 2009 [Page 3] Internet-Draft Reverse Binding for PMIPv6 February 2009 2. Terminology 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]. The terminology in this document is based on the definitions in [RFC5213], in addition to the ones specified in this section: o Previous Mobile Access Gateway (PMAG): The MAG that manages mobility related signaling for the MN before handover. o New Mobile Access Gateway (NMAG): The MAG that manages mobility related signaling for the MN after handover. o Previous Point of Attachment (P-PoA): The access network device to which the MN is attached before handover. o New Point of Attachment (N-PoA): The access network device to which the MN is attached after handover. o Fast Proxy Binding Update (Fast PBU): A request message sent by an MAG to a mobile node's LMA for expediting the handover procedure. o Fast Proxy Binding Acknowledgement (Fast PBA): A reply message sent by the LMA in response to a Fast PBU message that it received from a MAG. o Reverse Proxy Binding Update (Reverse PBU): A request message sent by the LMA to a mobile node's new MAG after establishing a binding between the home network prefix assigned to the mobile node and its new care-of address (Proxy-CoA). o Reverse Proxy Binding Acknowledgement (Reverse PBA): A reply message sent by an MAG in response to a Reverse PBU message that it received from the LMA. 3. Protocol Operation Because a mobile node is not directly involved with IPv6 mobility management, it is also unaware of fast handover procedure defined in this memo. All new signaling messages defined in this memo are exchanged by MAGs and the LMA. The proposed scheme is not based on the fast handover strategy defined in [RFC5268]. To reduce the handover latency due to signaling between the MAGs and the LMA, this memo only utilizes the bi-directional tunnels between Han & Kim Expires August 22, 2009 [Page 4] Internet-Draft Reverse Binding for PMIPv6 February 2009 the LMA and the PMAG/NMAG. That is, no tunnel creation between MAGs is required. The bi-directional tunnel between the LMA and the PMAG has been already established to provide a visited mobile node with the packet delivery service. The bi-directional tunnel between the LMA and the NMAG may be also already established because the tunnels are shared for multiple mobile nodes in PMIPv6. If there is no tunnel between the LMA and the NMAG, a new one should be created during the proposed procedure. It is recommended that the bi-directional tunnels between the LMA and all MAGs should be statically pre-established to make the proposed scheme operate efficiently. MN P-PoA N-PoA PMAG NMAG LMA | | | | | | |Link-specific | | | | (a) |Pre-handover | | | | |procedure | | | | | |<--------->| HO Initiate | | | (b) | |-(MN ID, New AP ID)->| | | | | | | Fast PBU | (c) | | | |----(MN ID, New PCoA)--->| | | | | | | | | | | Fast PBA | (d) | | | |<------------------------| | | | | | | | | | | | Reverse PBU | (e) | | | | |<--(MN ID,---| | | | | | HNP) | | | | | | | (f) | | | | | Reverse PBA | | | | | |------------>| (g) | | | | |<==DL data===| ~~~ | | | |\ | (h) | | | | |buffering | ~~~ | | | | | | | MN:N-PoA connection | N-PoA:MAG connection| | | (h) |<---establishment---->|<---establishment---->| | | | | | | |/ | (i) |<=================DL data====================| | | | | | | | (j) |==================UL data===================>| | | | | | |===UL data==>| | | | | | | The proposed handover procedure. Han & Kim Expires August 22, 2009 [Page 5] Internet-Draft Reverse Binding for PMIPv6 February 2009 Figure 1 The procedure is as follows (see Figure 1): (a) A handover is imminent and a link-specific pre-handover procedure is performed. The pre-handover procedure can be host-initiated or network-initiated. The exact procedure is out of scope. (b) P-PoA, to which the MN is currently attached, indicates the handover of the mobile node to the PMAG. The exact procedure of this indication is also out of scope. (c) The PMAG sends the Fast PBU to the LMA. The Fast PBU message MUST include the MN ID and the new PCoA, the address of NMAG, which is resolved by the New AP ID. (d) The LMA sends back the Fast PBA to the PMAG. (e) The LMA establishes a binding between the home network prefix (HNP) assigned to the mobile node and its new PCoA. The LMA sends the Reverse PBU to the NMAG. The Reverse PBU message MUST include the MN ID and the HNP of the mobile node. (f) The NMAG sends back the Reverse PBA to the LMA. (g) If the bi-directional tunnel is not established between the NMAG and the LMA, a new tunnel is established. The LMA starts to transfer packets destined for the mobile node via the NMAG. If the mobile node has not established a connection with NMAG at this time, the NMAG starts to buffer the packets. (h) The mobile node hands over to the New Access Network. (i) The mobile node establishes a connection (e.g. radio channel) with the N-PoA, which in turn triggers the establishment of the connection between the N-PoA and NMAG. The exact procedure of this procedure is also out of scope. (j) The NMAG starts to transfer packets destined for the mobile node via the N-PoA. (k) The uplink packets from the mobile node are sent to the NMAG via the N-PoA and the NMAG forwards them to the LMA. As the name implies, the reverse PBU message is sent by the LMA and the recipient of it is the NMAG. Upon receiving it, the NMAG creates Han & Kim Expires August 22, 2009 [Page 6] Internet-Draft Reverse Binding for PMIPv6 February 2009 a new binding cache entry and establishes a new bi-directional tunnel if it does not exist. After doing them, the NMAG replies to the LMA by sending the reverse PBA message. It is also noted that the Reverse PBU and PBA are the alternates of the original PBU and PBU of PMIPv6. That is, the proposed scheme incorporates the main part of PMIPv6 procedure in the fast handover procedure, and thus any subsequent PMIPv6 procedure may be not necessary. 4. Handoff Type Considerations TBD 5. Message Format 5.1. Fast Binding option TBD 5.2. Fast Binding Acknowledgement option TBD 5.3. Reverse Binding option TBD 5.4. Reverse Binding Acknowledgement option TBD 6. Security Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., Han & Kim Expires August 22, 2009 [Page 7] Internet-Draft Reverse Binding for PMIPv6 February 2009 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 7.2. Informative References [I-D.ietf-mipshop-pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", draft-ietf-mipshop-pfmipv6-01 (work in progress), December 2008. [I-D.ietf-mipshop-transient-bce-pmipv6] Liebsch, M., Muhanna, A., and O. Blume, "Transient Binding for Proxy Mobile IPv6", draft-ietf-mipshop-transient-bce-pmipv6-01 (work in progress), February 2009. Authors' Addresses Youn-Hee Han KUT Gajeon-Ri, 307, Byeongcheon-Myeon Cheonan, Chungnam Korea Phone: +82 41 560 1486 Email: yhhan@kut.ac.kr Pyung-Soo Kim KPU 2121 Jungwang-Dong Shiheung, Gyeonggi Korea Phone: +82 31 8041 0489 Email: pskim@kpu.ac.kr Han & Kim Expires August 22, 2009 [Page 8]