Network Working Group J. Park, S. Koh Internet Draft Kyungpook National University Intended status: Informational October 8, 2010 Expires: April 2011 Query-based Proxy Mobile IPv6 draft-jwpark-netext-qpmipv6-00.txt Status of this Memo 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 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." 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 April 8, 2009. Park, Koh Expires April 8, 2011 [Page 1] Internet-Draft qpmipv6 October 2010 Copyright Notice Copyright (c) 2010 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. Abstract This Document proposes two extension schemes of PMIPv6, called Query-based PMIPv6 (QPMIPv6) and Signaling Query-based PMIPv6 (S- QPMIPv6), which send the binding query messages to LMA to get the care-of-address of a mobile node and to deliver the subsequent data packet over optimized data path. The proposed two schemes have some differences with each other. We will show that the performances of the schemes comparing PMIPv6 with QPMIPv6 and S-QPMIPv6. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Protocol Detail ............................................. 4 3.1. Network Consideration................................... 4 3.2. Query-based PMIPv6...................................... 5 3.3. Signaling Query-based PMIPv6............................ 6 4. Security Considerations...................................... 7 5. IANA Considerations ......................................... 7 6. Conclusions ................................................. 7 7. References .................................................. 8 7.1. Normative References.................................... 8 7.2. Informative References.................................. 8 8. Acknowledgments ............................................. 8 Park, Koh Expires April 8, 2011 [Page 2] Internet-Draft qpmipv6 October 2010 1. Introduction In wireless networks environment, the Proxy Mobile IPv6 (PMIPv6) was designed from Internet Engineering Task Force (IETF) to support the network-based mobility for the mobile node (MN) in IPv6 network. The network-based mobility means that the MN does not participate in exchanging signals to process the mobility management unlike host- based mobility which means that MN should have modules to exchange the signals related to mobility management. In the PMIPv6, the mobile agents called Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in the network will perform the mobility signaling instead of MN, and will keep track of movement of MN. When the MN moves in new MAG's area and the MAG detects the MN's attachment. To update the LMA about of current location of the MN, the MAG sends Proxy Binding Update (PBU) message to LMA. Upon accepting this PBU message, the LMA sends a Proxy Binding Acknowledgement (PBA) message to MN and creates the Binding Cache Entry (BCE). After these registration procedures, LMA sets up its endpoint of the bi-directional tunnel to MAG, the MN is ready to communicate with Correspond Node (CN) by sending or receiving data packets. When the MN communicates with CN in PMIPv6, the data packets should be delivered from source to destination via Local Mobility Anchor (LMA), so it means that data packets can be delivered over the non- optimized path inefficiently. This document proposes two exclusive packet delivery schemes of PMIPv6, called Query-based PMIPv6 (Q-PMIPv6) and Signaling Query- based PMIPv6 (SQ-PMIPv6), in which the CN side MAG will send the binding query to LMA to get the Proxy-CoA of MN. After getting the Proxy-CoA of MN, the MAG will deliver all the subsequent data packets over the optimized packet delivery path. 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]. Park, Koh Expires April 8, 2011 [Page 3] Internet-Draft qpmipv6 October 2010 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. Protocol Detail 3.1. Network Consideration To describe the proposed scheme, we will extend the PMIPv6, which can deliver data packets over the more optimized path than basic PMIPv6 data delivery path. So it can reduce the packet delivery cost and overheads of LMA. Figure 1 shows the reference network model for Q-PMIP and SQ-PMIP. +-------+ | LMA | +-------+ //\\ // \\ // \\ // \\ +-------+ +-------+ | M-MAG | | C-MAG | +-------+ +-------+ // \\ // Data Packets // \\ // \\ +------+ +------+ | MN | | CN | +------+ +------+ Figure 1 Network model for QPMIPv4 and S-QPMIPv4 In the figure 1, CN tries to transmit data packets to MN. On reception of the first data packet destined to MN, the C-MAG exchanges the PBQ and PBA messages with LMA to get Proxy-CoA of MN. And then the bi-directional tunnel is established between MAGs. In PMIPv6, MN will perform the registration with LMA. All the data packets transmitted by CN will be forwarded to LMA and delivered by LMA to MN using the tunneling. In QPMIPv6, the data packets are delivered over the tunnel between MAG's. This path optimization reduces the overhead of LMA and packet delivery cost between the MN and the CN. Park, Koh Expires April 8, 2011 [Page 4] Internet-Draft qpmipv6 October 2010 3.2. Query-based PMIPv6 Figure 2 shows the operation of the Q-PMIPv6. First, the MN register to M-MAG, it performs the link-later signaling. MN M-MAG LMA C-MAG CN | MN-MAG | | | | | Registration | | | | |<------------->| | | | | |------PBU----->| | | | | | | | | |<-----PBA------| | Data Packets | | | | |<=============| | | | Buffering | | | |<-----PBQ------| | | | | | | | | |------PBA----->| | | | | | | | |<-Tunnel Establishment Request-| | | | | | | | Accept TER | | | | (Setup Tunnel and Routing) | | | | | | | | | |---Tunnel Establishment Ack--->| | | | | | | | |=====Bi-directional Tunnel=====| | | | | | | | | | | | |<==============|<==============================|<=============| | Data Packets | Data Packets | Data Packets | | | (include buffered packets) | | | | | | | Figure 2 Query-based PMIPv6 Operations The M-MAG sends the PBU operation with the LMA to register the binding and routing state of MN. On receiving the PBU request, the LMA will create the BCE and send the PBA to respond to the M-MAG. CN sends the data packets to MN. When C-MAG receives the first packet from CN, and then the C-MAG sends PBQ message to the LMA to request the Proxy-CoA of MN. After receiving the PBQ message from C- MAG, the LMA sends PBA including the information that includes Proxy-CoA of MN. During these procedures, the C-MAG has been received the data packets from CN. To prevent the packet losses, the MAG performs the buffering until that C-MAG receives PBA from LMA and sets up the bi-directional tunnel between the M-MAG and the C- Park, Koh Expires April 8, 2011 [Page 5] Internet-Draft qpmipv6 October 2010 MAG. After establish the tunnel, the C-MAG sends the data packets buffered in the C-MAG first. After that, the C-MAG sends the data packets received from CN. Basically, the MAG in PMIPv6 network delivers all data packets to LMA. But the Q-PMIP can use the optimized path without LMA to transmit the data packet by using the Query. With the data transport over the optimized path, QPMIPv6 can reduce the transmission delays of data packets, compared to PMIPv6. In addition, QPMIPv6 can avoid the problem of the excessive data traffic load at LMA, since the data transmission to MN will be performed by the concerned MAG, instead of LMA, in the distributed manner. 3.3. Signaling Query-based PMIPv6 SQ-PMIPv6 is based on Q-PMIPv6 which is introduced above section. The Q-PMIPv6 has a problem, so there are some differences. If buffered data packets in MAG2 increase while processing the PBQ-PBA operation with LMA. For example, PBQ or PBA message delivery time increase. That case, the amount of data packets which should be saved in buffer at MAG2 is also increased. MN M-MAG LMA C-MAG CN | MN-MAG | | | | | Registration | | | | |<------------->| | | | | |------PBU----->| | | | | | | | | |<-----PBA------| | | | | | |<---DT-Req----| | | |<-----PBQ------| | | | | | | | | |------PBA----->| | | | | |----DT-Ack--->| | | | | | | |<-Tunnel Establishment Request-| | | | | | | | Accept TER | | | | (Setup Tunnel and Routing) | | | | | | | | | |---Tunnel Establishment Ack--->| | | | | | | | |=====Bi-directional Tunnel=====| | Park, Koh Expires April 8, 2011 [Page 6] Internet-Draft qpmipv6 October 2010 | | | | | | | | | | |<==============|<==============================|<=============| | Data Packets | Data Packets | Data Packets | | | | | | | | | | | Figure 3 Signaling Q-PMIPv6 Operations To solve this problem in Q-PMIPv6, we suggest the additional signaling procedure to prepare data transmission between CN and the MAG2. Before the CN sends data packets, CN must send the Data Transmission-Request (DT-Req) message to the MAG2. After receiving the DT-Req message, the MAG2 performs the PBQ operation like Q- PMIPv6 and sends Data Transmission-Acknowledgement (DT-Ack) message to respond to the CN. By these procedures, SQ-PMIP does not need to buffer the data packets, so it can reduce the overhead in MAG2. 4. Security Considerations TBD 5. IANA Considerations TBD 6. Conclusions This document proposes two exclusive packet delivery schemes of PMIPv6, called Query-based PMIPv6 (Q-PMIPv6) and Signaling Query- based PMIPv6 (SQ-PMIPv6). Both of two schemes are proposed to reduce the overhead in LMA and the transmission delays of data packets from CN to MN. But, the QPMIPv6 should perform the buffering of data packets, before the Query-Ack procedure is done. If the procedure time may take longer, the data packet transmission will be delayed. It can be solved using proposed scheme SQ-PMIPv6 which is an enhanced scheme of the Q-PMIP. Park, Koh Expires April 8, 2011 [Page 7] Internet-Draft qpmipv6 October 2010 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 [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 1583. [4] S. Gundavelli, K. Leung, V. Decarapalli, K. Chowdhury, and B. Patil, ''Proxy Mobile IPv6'', RFC 5213, August 2008. [5] D. Johnson, C. Perkins, and K. Arkko, ''Mobility support in IPv6'', RFC 3775, June 2004. [6] S. Krishnan, Ed, R. Koodli, P. Loureiro, Q. Wu and A. Dutta, "Localized Routing for Proxy Mobile IPv6", Internet-Draft, September 1, 2010. [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Park, Koh Expires April 8, 2011 [Page 8] Internet-Draft qpmipv6 October 2010 Authors' Addresses Jae Wan Park Kyungpook National University, KOREA Email: jwparkin8@gmail.com Seok Joo Koh Kyungpook National University, KOREA Email: sjkoh@knu.ac.kr Park, Koh Expires April 8, 2011 [Page 9]