DMM Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational Younghan Kim Expires: December 17, 2015 Soongsil University June 18, 2015 PMIPv6-based Distributed Mobility Management draft-jaehwoon-dmm-pmipv6-04 Abstract Proxy Mobile IPv6 (PMIPv6) is the network-based mobility management protocol where access network supports the mobility of a mobile node on behalf of the MN. In PMIPv6, the location information of the MN should be registered to Localized Mobility Anchor and communication must be established via the LMA. Therefore, the performance can be degraded due to traffic concentration and congestion possibility. One method to overcome the above problems is to exploit the distributed mobility management (DMM) mechanism to distribute the LMA function to all access routers within the PMIPv6 domain. This document presents a fully distributed mobility management mechanism in PMIPv6-based network. In this mechanism, there is no need for the location management function to register the location of the MN. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 17, 2015. Jaehwoon Lee Expires Dec. 17, 2015 [Page 1] Internet-Draft PMIPv6-based DMM June 18, 2015 Copyright Notice Copyright (c) 2015 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. Table of Contents 1. Introduction.................................................3 2. Conventions and Terminology..................................3 2.1. Conventions used in this document........................3 2.2. Terminology ............................................3 3. Protocol Operation...........................................3 4. Security Considerations......................................7 5. IANA Considerations..........................................7 6. References....................................................7 Author's Address.................................................7 Jaehwoon Lee Expires Dec. 17, 2015 [Page 2] Internet-Draft PMIPv6-based DMM June 18, 2015 1. Introduction Centralized mobility management protocols such as MIPv6 [1] and PMIPv6 [2] have several problems such as single-node failure, congestion possibility, scalability issues and non-optimal routes [3]. One method to resolve such problems is to use the distributed mobility management (DMM) mechanism to distribute mobile agent function to access routers [4]. Especially, in PMIPv6-based DMM, when an MN moves one network to another, a new access router that the MN moves and connects should know (1) whether the MN firstly enters the PMIPv6 domain and (2) the address information of the LMA for the MN when the access router knows that the MN moves from another network. This document presents a fully distributed mobility management mechanism which does not need the control function for managing MN-LMA address binding information. 2. Conventions and Terminology 2.1. Conventions 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 [5]. 2.2 Terminology TBD. 3. Protocol Operation Figure 1 shows the message exchange procedure between network entities to provide fully distributed mobility management in PMIPv6 environment presented in this document. A network prefix "PREF" is allocated to the PMIPv6 domain. However, a different sub-network prefix belonging to the same network prefix "PREF" is allocated to a different mobility access gateway (MAG) in PMIPv6 domain. For example, a sub-network prefix "PREF1" belonging to "PREF" is allocated to MAG1 and a different sub-network prefix "PREF2" belonging to the same "PREF" is allocated to MAG2. Even though a different sub-network prefix is allocated to a different MAG, all MAGs advertise the same network prefix "PREF" through the interfaces providing PMIPv6 service. Jaehwoon Lee Expires Dec. 17, 2015 [Page 3] Internet-Draft PMIPv6-based DMM June 18, 2015 MN MAG1 MAG2 MAG3 CN | | | | | |*** L2 attachment ***>| | | | |<----- RA(PREF) ------| | | | |---DHCP request msg-->| | | | |<--DHCP reponse msg---| | | | | (MN's address) | | | | (Configure IPv6 address) | | | | |<-------------------- exchange IP traffic ------------------->| (Move from MAG1 to MAG2) | | | | |************ L2 attachment **************>| | | |<-------------- RA(PREF) -----------------| | | |--------------- IP packet --------------->| | | | | (packet buffering) | | | |<----DPBU msg------| | | | (create BCE and est. tunnel) | | | | |-----DPBA msg----->| | | | | (create BUL and est. tunnel)| | | |<====IP packet=====| | | | |--------------- IP packet ------------>| (Move from MAG2 to MAG3) | | | | | | (packet buffering) | | | |<----DPBRU msg-----| | | | |----DPBRA msg----->| | | |****************** L2 attachment ******************>| | |<------------------- RA (PREF) ---------------------| | |------------------- IP pkt ------------------------>| | | | (pkt bufferring) | | |<-- exchange DPBU/DPBA msg ->| | | |<========= IP packet ========| | | |-------------- IP packet ------------->| (a) MN to CN packet transmission scenario Jaehwoon Lee Expires Dec. 17, 2015 [Page 4] Internet-Draft PMIPv6-based DMM June 18, 2015 MN MAG1 MAG2 MAG3 CN | | | | | |*** L2 attachment ***>| | | | |<----- RA(PREF) ------| | | | |---DHCP request msg-->| | | | |<--DHCP reponse msg---| | | | | (MN's address) | | | | (Configure IPv6 address) | | | | |<-------------------- exchange IP traffic ------------------->| (Move from MAG1 to MAG2) | | | | | |<----------- IP packet ----------------| | (packet buffering) | | | |************ L2 attachment **************>| | | |<-------------- RA(PREF) -----------------| | | | |<----DPBU msg------| | | | (create BCE and est. tunnel) | | | | |-----DPBA msg----->| | | | | (create BUL and est. tunnel)| | | |=====IP packet====>| | | |<--------------- IP packet ---------------| | | (Move from MAG2 to MAG3) | | | | | | (packet buffering) | | | |<----DPBRU msg-----| | | | |<= Buffered IP pkt=| | | | (packet bufffering) | | | | |<--- FLUSH msg ----| | | | |----DPBRA msg----->| | | |****************** L2 attachment ******************>| | |<------------------- RA (PREF) ---------------------| | | |<-- exchange DPBU/DPBA msg ->| | | |==== buffered IP packet ====>| | | |====== IP packet ===========>| | |<----------------- IP packet -----------------------| | (b) CN to MN packet transmission scenario Figure 1: Message exchange scenario When an MN firstly enters the PMIPv6 domain and connects to a MAG (say, MAG1), MAG1 transmits to the MN a Router Advertisement (RA) message by setting "M (Managed address configuration)" flag in order to configure an address to the MN by using the stateful address configuration method [6]. The network prefix "PREF" is set to the prefix option information field in the RA message. The MN having received the RA message transmits the dynamic host configuration protocol (DHCP) request message to the MAG1 [7]. The MAG1 considers that the MN firstly connects to the PMIPv6 domain and transmits the DHCP response message containing an address belonging to the "PREF1" to the MN. The MN sets the address contained in the Jaehwoon Lee Expires Dec. 17, 2015 [Page 5] Internet-Draft PMIPv6-based DMM June 18, 2015 DHCP response message to its interface. After that, the MN can communicate to a CN within the Internet. When the MN moves MAG1 to MAG2 while communicating with a CN, the MAG1 begins to perform the LMA function for the MN and stores packets sent from the CN into the buffer. The MAG1 stores the MM's information into its Binding Cache Entry (BCE). When the MN connects to MAG2, the MAG2 transmits the RA message containing network prefix set to "PREF" to the MN. The MN having received the RA message considers that it connects to the same network by using the "PREF" network prefix in prefix information option of RA message. It continues to use the address configured previously and transmits IP packets as usual. MAG2 checks the first packet transmitted by the MN. If the first packet contains the DHCP request packet, then MAG2 considers that the MN firstly connects to the PMIPv6 domain. Otherwise, MAG2 considers that the MN moves from another MAG area and creates the Binding Update List (BUL) for the MN. And then, MAG2 transmits the Distributed Proxy Binding Update (DPBU) message. The source address of the packet containing the DPBU message is set to the address of the MAG2 (say, Proxy-CoA2) and the destination address is set to the address of the MN. Here, MAG2 can know the address of the MN by using the source address of the IP packet sent by the MN. Moreover, MAG2 stores packets sent by the MN. DPBU message is transmitted to the MAG1 through the Internet topologically correct routing path. MAG1 having received the DPBU message stores the Proxy-CoA2 address to its BCE for the MN, establishes the tunnel with MAG2, and transmits the Distributed Proxy Binding Acknowledgement (DPBA) message to MAG2. The source and destination addresses of the packet containing the DPBA message are set to the address of MAG1 (say, Proxy-CoA1) and Proxy-CoA2, respectively. The DPBA message contains the address of the MN in its option field. MAG2 receiving the PBA message stores the Proxy-CoA1 address to its BUL and establishes the tunnel with MAG1. And then, MAG1 transmits the packets stored in the buffer to MAG2, and MAG2 would the received packets to the MN. After that, the MN continues to communicate with the CN. Packets sent from MAG1 to MAG2 might be lost if the MN moves from MAG2 to another MAG (MAG3 for example in this draft). It is because MAG1 cannot know the fact that the MN moves and connects to MAG3. In order to avoid the packet loss, When MAG2 knows to disconnect to the MN, MAG2 transmits the Distributed Proxy Binding Release Update (DPBRU) message to MAG1. Moreover, MAG2 transmits packets for the MN to MAG1 again. When MAG1 receives the DPBRU message, MAG1 transmits FLUSH message to the MAG2 and stores packets sent from the CN in its buffer. MAG2 having received the FLUSH message considers that the message is the final packet sent from the MAG1 and retransmits the FLUSH message. And then, MAG2 removes the entry related the MN in the BUL. MAG1 having received the FLUSH message having sent from MAG2 considers that themessage is the final packet sent from MAG2. MAG1 Jaehwoon Lee Expires Dec. 17, 2015 [Page 6] Internet-Draft PMIPv6-based DMM June 18, 2015 transmits the Distributed Proxy Binding Release Acknowledgement (DPBRA) message to MAG2. When MAG1 receives the DPBU message from MAG3, MAG1 transmits the DPBA message to MAG3, update its BCE related to the MN, transmits the stored packets sent from MAG2, and then transmits packets sent from the CN. 4. Security Considerations TBD 5. IANA Considerations TBD 6. References [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", IETF RFC 3775, June 2004. [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. [3] H. Chan, D. Liu, P. Seite, H. Yokota and J. Korhonen, "Requirements for Distributed Mobility Management", draft-ietf-dmm-requirements-03 (work in progress), Dec. 2012. [4] IETF dmm working group, http://datatracker.ietf.org/wg/dmm/charter. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] T. Narten, E. Nordmark, W. Sompson and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6), IETF RFC 4861, Sep. 2007. [7] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", IETF RFC 3315, July 2003. Author's Address Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Jaehwoon Lee Expires Dec. 17, 2015 [Page 7] Internet-Draft PMIPv6-based DMM June 18, 2015 Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu, Seoul 156-743, Korea Email: younghak@ssu.ac.kr Jaehwoon Lee Expires Dec. 17, 2015 [Page 8]