DMM Working Group Hong-Ke Zhang Internet Draft Li-Li Wang Expires: September 2012 Bo-Hao Feng Shuai Gao Beijing Jiaotong University March 26, 2012 A Robust Solution for PMIPv6-based Distributed Mobility Management draft-zhang-dmm-rpmipdmm-00.txt Abstract Proxy Mobile IPv6 (PMIPv6) is a network-based centralized mobility management protocol, which has many disadvantages for utilizing the centralized anchor LMA. As networks are moving towards flat architectures, a distributed approach is needed to PMIPv6. This document defines a robust solution for PMIPv6-based distributed mobility management which ensures the robustness by organizing the distributed anchors (MAARs) into a Chord ring. Requirements Language 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 [RFC2119]. 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 September, 2012. Zhang et al. Expires September,2012 [Page 1] Internet-Draft A Robust solution for PMIPv6-based DMM March 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. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Description of the solution ................................. 4 4. Format of signaling messages ................................ 7 4.1. M-PBU .................................................. 7 4.2. M-PBA .................................................. 8 5. Security Considerations ..................................... 9 6. References .................................................. 9 Acknowledgment ................................................ 10 1. Introduction The current IP mobility protocols, which are either host-based like Mobile IPv6 [1] or network-based like Proxy Mobile IPv6 [2], support the mobility management via centralized anchors. In order to maintain the IP session when MNs handover, the anchors are mainly responsible for allocating home network prefixes to MNs, managing their locations and intercepting as well as forwarding packets that are from or to MNs. However, such centralized anchors lead to some obvious shortcomings like sub-optimal routing, scalability problem, considerable signaling cost and delay and so on. As the networks are moving towards flat architecture, a distributed approach is needed to avoid those disadvantages of centralized mobility protocols. In this distributed scheme, there is no need for any centralized anchors in the network while only distributed anchors are deployed. Besides, it is not necessary to identify MNs by the fixed home addresses or home network prefixes. Some related drafts have been proposed, but there are not any schemes to guarantee the Zhang et al. Expires September,2012 [Page 2] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 robustness for the distributed mobility management. In this document, we propose a robust solution for PMIPv6-based distributed mobility management. This solution ensures the robustness by organizing the distributed anchors (MAARs) into a Chord ring. 2. Terminology The following terms used in this document are defined in the Proxy Mobile IPv6 specification [RFC5213]: Local Mobility Anchor (LMA) Mobile Access Gateway (MAG) Mobile Node (MN) Corresponding Node (CN) Proxy Binding Update (PBU) Proxy Binding Acknowledgment (PBA) The following terms are defined and/or used in this document: MAAR (Mobility Anchor and Access Router). First IP hop routers where the mobile nodes attach to. They provide an IPv6 prefix (topologically anchored at the MAAR) to each attaching mobile node. They also play the role of mobility managers for the IPv6 prefixes they anchor. M-MAAR (Managed Mobility Anchor and Access Router). The MAAR that manages all the path of the MN which is distributed assigned in the Chord ring. M-PBU (Managed PBU). The signaling message sent by MAAR to the M-MAAR. It is used to register to M-MAAR for MN recording the MN's path. M-PBA (Managed PBA). The signaling message sent back by M-MAAR to the MAAR. It is used to register to M-MAAR for MN recording the MN's path. Zhang et al. Expires September,2012 [Page 3] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 3. Description of the solution The purpose of this solution is to provide robust distributed mobility management based on PMIPv6. For this, it is assumed that there are many MAARs in the management domain and that every MAAR has a MAAR identifier that is similar to an MN-identifier specified in RFC 4283 [3]. And every MAAR in this solution functions as both an LMA for those MNs that are attached to it at the first hop, and a MAG for those MNs that are connected to it while not attached at the first hop. Therefore, there are not any centralized anchors in the architecture of this solution. In addition, all MAARs in this distributed management domain are organized into a Chord circle using consistent hashing over MAAR identifiers [4][5]. Given the fact that the Chord system distributes the information of value among nodes on the ring, the failure of a MAAR only affects a very limited number of MAARs in the Chord system, which indicate that this solution for distributed mobility management based on PMIPv6 is robust. Moreover, for a given MN, the M-MAAR that manages all the path of this MN in the distributed management domain is configured by the network administrator of the domain or by some algorithm and does not change as long as the MN roams within the domain. The architecture of this solution is shown in Figure 1. o @ N1(MAAR) o o @ @ N8 o o @ @ N14 @ o o @ N21 @ o o o @ @ N32 N38 o o Figure 1: Architecture of the distributed mobility management based on PMIPv6 using Chord ring Zhang et al. Expires September,2012 [Page 4] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 As stated above, which M-MAAR is configured and responsible for an MN is unknown to other MAARs when this MN attaches to them. In order to deal with this issue, we store (key, value) pairs at the MAARs by using consistent hashing algorithm, where the key is the hash value of an MN-identifier and the value is the IPv6 address of the M-MAAR serving the corresponding MN. For a given MN, the IPv6 address of its M-MAAR should be stored at the MAAR that is the successor of the MN- identifier. For ease of description, we define QServer(MN) as the MAAR that stores the (key, value) pair for an MN. Also for simplicity, we will use MN-id and M-MAAR or the tuple (MN-id, M-MAAR) to represent both the original and hash value of the MN-identifier and the IPv6 address of its M-MAAR. Whenever a new MAAR detects the attachment of an MN, it may not know the MN's M-MAAR. In this case, it sends a query message including the MN-identifier, the new MAAR's identifier and IPv6 address to the Chord system in order to find the MN's M-MAAR. The other MAARs in the Chord system forward the query message according to their finger tables until it reaches QServer(MN). When the MAAR that serves as the QServer of the MN receives the query message, it sends the IPv6 address of the MN's M-MAAR which is defined in the tuple (MN-id, M- MAAR) back to the new MAAR. When the new MAAR receives the IPv6 address of the MN's M-MAAR, it stores the M-MAAR's IPv6 address into a table for the attached MN locally. After knowing the M-MAAR's IPv6 address, the new MAAR (MAAR1) sends an M-PBU message to the M-MAAR. If the cache about the MN in M-MAAR is empty, this MAAR1 will also serve as LMA assigning HNP1 for MN as specified in PMIPv6. And also, the M-MAAR should record one item including MN-identifier, HNP1 and the IPv6 address of the MAAR1. However, if there is one item (MN-id, HNP0, the MAAR0's IPv6 address) in the cache about the MN in M-MAAR, the M-MAAR will return an M-PBA message containing the corresponding information to the MAAR1 after receiving the M-PBU message. That is, MAAR1 is not the first hop router to which the MN accesses. And then MAAR1 sends a register message (PBU) to the MAAR0 and establishes the bi-directional tunnel between the MAAR0 and the MAAR1 after receiving the PBA message from the MAAR0. Besides, in this case the MN could also use the HNP1 allocated by MAAR1 to start a new IP session. As shown in Figure 2, the paths among the MAARs and the M-MAAR represented by lines ("/" and "\") indicate registrations between MAARs and the M-MAAR, while the path depicted with stars ("*") denotes the query procedure of MAARs for the address of the M-MAAR of the MN-id in chord ring, and the path pictured with circles ("o" and "#") shows the data flow from CN1 and CN2 respectively. In Figure 2, the MN moves from the MAAR1 to the MAAR2. And the MN starts a new Zhang et al. Expires September,2012 [Page 5] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 session with the CN2 when it moves to the MAAR2 and also continues the session with the CN1 through the MAAR1. The detailed procedure is described in Figure 3. +---+ +------+ +----------+ +---+ |CN1| |M-MAAR| |Chord Ring| |CN2| +---+ +------+ +----------+ +---+ o | * # o / \ * * # o / \ * * # o / \ * * # o / \ * * # o / \ * * # o / * \ * # o / * \ * # o / * \ * # o / * \ * # o | * | * # o +-----+ +-----+ # oooo|MAAR1|(oooooooooo) |MAAR2|####################### +-----+ tunnel +-----+ o| o|# +---+ +---+ |MN |-------------->|MN | +---+ +---+ Figure 2: Scenario after a handover and the data flow MN MAAR1 MAAR2 M-MAAR MAARs(Chord ring) CN1 CN2 | | | | | | | |-L2 Attachment->| | | | | | | |----------------------------->| | | | (Query for the address of M-MAAR of the MN-id) | | | | | | | | | | |<-Reply the address of M-MAAR-| | | |<-Allocate HNP1-| | | | | | |(Configure IP address) | | | | | | | | | | | | | |-------M-PBU------>| | | | | (Register to the M-MAAR with address of MAAR1, HNP1 and MN-id) | | | | | | | | | |<-------M-PBA------| | | | Zhang et al. Expires September,2012 [Page 6] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 | | | | | | | |<---------------|<-----------IP Packets with HNP1-----------| | | | | | | | | |--------Handover-------->| | | | | | | | | | | | |-----L2 Attachment------>| | | | | | | |-------------------->| | | | (Query for the address of M-MAAR of the MN-id) | | | | | | | | | | | |<-Reply the address--| | | |<-----Allocate HNP2------| | | | | | (Configure IP address) | | | | | | | | | | | | | | |--------M-PBU------->| | | | (Register to the M-MAAR with address of MAAR2, HNP2 and MN-id) | | | | | | | | | | |<--------M-PBA-------| | | | | (Reply the address of MAAR1 and HNP1) | | | | | | | | | | |<--PBU--| | | | | | |--PBA-->| | | | | | (Establish the Tunnel) | | | | | | | | | | | | |<------------IP Packets with HNP1----------| | | |=======>| | | | | |<------------------------| | | | | | | | | | | | |<------------------------|<---------IP Packets with HNP2---------| | | | | | | | Figure 3: The detailed procedure of the solution 4. Format of signaling messages 4.1. M-PBU The format of the M-PBU message is shown in Figure 4. 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 # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang et al. Expires September,2012 [Page 7] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 |A|H|L|K|M|R|P|D| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mobility options | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D flag 1-bit "Distributed" flag is used to identify whether this PBU is from the MAAR to the M-MAAR. When this flag is set to "0", this message is the PBU message in the [RFC5213]. If the flag is set to "1", this message is the M-PBU. The flag MUST be set to the value of 1 in this draft. 4.2. M-PBA The format of the M-PBA message is shown in Figure 5. 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|D|Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mobility options | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D flag 1-bit "Distributed" flag is used to identify whether this PBA is from the M-MAAR to the MAAR. When this flag is set to "0", this message is the PBA message in the [RFC5213]. If the flag is set to "1", this message is the M-PBA. The flag MUST be set to the value of 1 in this draft. Zhang et al. Expires September,2012 [Page 8] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 5. Security Considerations This document does not introduce any security considerations. 6. References [1] C.Perkins, D.Johnson, and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [3] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury, "Mobile node identifier option for mobile IPv6 (MIPv6)", RFC 4283, November 2005. [4] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. Kaashoek, F.Dabek, and H. Balakrishnan, "Chord: a scalable peer-to-peer lookup protocol for Internet applications," IEEE/ACM Transactions on Networking, vol.11, no.1, pp: 17-32, February 2003. [5] D. R. Karger, E. Lehman, F. Leighton, M. Levine, D. Lewin, and R. Panigrahy, "Consistent hashing and random trees: distributed caching protocols for relieving hot spots on theWorldWideWeb," in Proc. 29th Annu. ACM Symp. Theory of Computing, May 1997, pp. 654-663. Zhang et al. Expires September,2012 [Page 9] Internet-Draft A Robust solution for PMIPv6-based DMM March 2012 Authors' Addresses Hong-Ke Zhang, Li-Li Wang, Bo-Hao Feng, Shuai-Gao National Engineering Lab for NGI Interconnection Devices Beijing Jiaotong University, China Phone: +861051684274 Email:hkzhang@bjtu.edu.cn liliwang@bjtu.edu.cn 11111021@bjtu.edu.cn shgao@bjtu.edu.cn Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang et al. Expires September,2012 [Page 10]