Network Working Group D. Liu Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: September 6, 2012 W. Luo ZTE March 5, 2012 DMM Dynamic Anchor Discussion draft-liu-dmm-dynamic-anchor-discussion-00 Abstract Distributed mobility management aims to distribute the mobility anchor to the access network level to avoid the centralized mobility anchor problem. By distributing the mobility anchor, the traffic can be distributed in an optimal way. There are many different proposals for DMM solution, one of those types of solution is called "dynamic anchor". This document analyses the limitations of current dynamic anchor solution and discusses the possible solution to overcome those limitations. 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 RFC 2119 [RFC2119]. 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 September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Liu, et al. Expires September 6, 2012 [Page 1] Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012 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. Problem of dynamic anchor and potential solution . . . . . . . 3 1.1. Active session managment . . . . . . . . . . . . . . . . . 3 1.2. Soure address selection . . . . . . . . . . . . . . . . . . 4 1.3. CN address selection . . . . . . . . . . . . . . . . . . . 4 1.4. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Resource consumption consideration . . . . . . . . . . . . 5 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Liu, et al. Expires September 6, 2012 [Page 2] Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012 1. Problem of dynamic anchor and potential solution As draft [I-D.draft-seite-dmm-dma-00] introduced, the main idea of dynamic anchor is distributing the mobility anchor function in the access router (MAR). The newly initiated session is routed through the current MAR, only the original sessions that established before handover will be maintained at the previous anchor. As the following figure shows, flow1 is anchored to MAR1, flow2 is anchored to MAR2. Two different prefixes are assigned to the MN. +--------------+ | Policy Server| +-.-'--+-----`.+ +---+ .' | `. flow2 +----+ |CN1| .-' | `.____,| CN2| ++--+ .' | ,-'''' `. +----+ flow1\ +-----.-'--+ +----+--.'-+ +---`.-----+ +-------. | | | | | | | MAR1 `-+-'''''-..MAR2.'| | MRA3 | +----------+ +----+-+---+ +----------+ | | HNP1 | | HNP2 +--`-+-+ | MN | +------+ Figure 1 There are several potential problems for this solution 1.1. Active session managment In this dynamic anchor solution, the MAR needs to know whether a prefix is active, if not, the MAR need to release the mobility binding. For instance, when the MN attach to MAR1, MAR1 detects the attachment of MN and allocate HNP1 to the MN. When the MN moves to MAR2, MAR2 needs to know that there is one on-going session in the MN and needs to trigger mobility binding update to MAR1 to update the binding. The question is how MAR2 know that there is an active session for HNP1 in MN? The first approach is to use policy server to store the MN-ID and corresponding home network prefix that allocate to the MN. When MN moves to MAR2, as mentioned in [I-D.draft-seite-dmm-dma-00], MAR2 first check the policy server and find that MN is anchored to MAR1, then it can send binding update message to MAR1. But only that is not enough. MAR2/MAR1 has to have some mechanism to trigger the release HNP1, otherwise the MAR1 will always be occupied by the MN as one of its anchor point. This will lead system capacity waste. For example, after the on-going session is terminated, the MAR2 need to release the HNP1. Liu, et al. Expires September 6, 2012 [Page 3] Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012 The question is that the policy server does not know when to release HNP1. One of possible solution is that MAR2 can inspect the traffic that has the source address prefix equals to HNP1. When MAR2 finds that there is no traffic sourced from HNP1 for a certain time, it can send deregistration binding update to MAR1 and release the binding state for HNP1. It seems that MAR2 needs a certain kind of timer to support the inspection for each sessions. If in this way, system capacity consumed by those timers can not be ignored since the traffic from hundreds of mobile nodes which are in a same MAR may have many thousands of sessions. 1.2. Soure address selection MN may be configured with multiple addresses. For example, MN can have HNP1 and HNP2 at the same time. In this case, the MN's application need to select the correct source address. For example, there maybe a VoIP session running using HNP1 when MN attaches to MAR1. When MN moves to MAR2 , the VoIP session need to continue. When the user start a web browser, MAR2 will allocate a new perfix: HNP2. The VoIP software need to select HNP1 as the source address and the web browser need to select HNP2 as source address. RFC3484 specifies the source address selection rules for IPv6 but RFC3484 is not enough to cope with this situation since RFC3284 does not specify how to select source address for a particular application. To solve this problem, the host may use the following rules for source address selection: a. For any on-going session, keep to use the original address even there is a newly address been configured for the same interface. b. For any new session, always choose to use the newly allocated address. The new MAR need to advertise the newly allocated prefix as the highest priority. 1.3. CN address selection From the CN's perspective, the MN has multiple addresses, the CN needs to know which one it should use when it wants to initiate a session to MN. 1.4. IPv4 support It will worse the IPv4 address depletion problem if use the dynamic anchor solution for IPv4 since each MN will need multiple IP addresses in that case. Liu, et al. Expires September 6, 2012 [Page 4] Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012 1.5. Resource consumption consideration _.------. ,---'' `------------------. ,' +----------+ `-. / |Session DB| : ( +----------+ MARn \ / ``---MN `. _.----'(HoA1,HoA2,HoA3,..,HoAn) 'MAR1----MAR2------------MAR3' ..+ .' \ move _..-'/ .' move \ move __..--'' MN --------> MN --------> MN (HoA1) (HoA1,HoA2) (HoA1,HoA2,HoA3) Figure2. Resource consumption As illustrated in figure2, during the movement, mobile node gets more and more HoAs and more and more MARs will be occupied by this mobile node as its anchor points. The mobile node could maintain its HoAs by keep on sending packets at very low data rate for each sessions. In this way, capacity of the network will be consumed, e.g. many tunnels should be maintained among those MARs, many mobility contexts for this mobile node should be maintained among those MARs, and the operator will gain almost nothing from this mobile node. Additionally, the scenario described above provides a possibility for attackers to consume network resource maliciously. 2. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 3. Security Considerations TBD 4. Acknowledgements TBD 5. References Liu, et al. Expires September 6, 2012 [Page 5] Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [I-D.draft-seite-dmm-dma-00] Seite , P. and P. Bertin, "Distributed Mobility Anchoring, draft-seite-dmm-dma-00", February 2012. Authors' Addresses Dapeng Liu China Mobile 32 Xuanwumen West Street Beijng, Xicheng District, 100053 China Phone: +86-13911788933 Email: liudapeng@chinamobile.com Hui Deng China Mobile 32 Xuanwumen West Street Beijng, Xicheng District, 100053 China Phone: +86-13911788933 Email: denghui@chinamobile.com Wen Luo ZTE No.68, Zijinhua RD,Yuhuatai District Nanjing, Jiangsu 210012 China Email: luo.wen@zte.com.cn Liu, et al. Expires September 6, 2012 [Page 6]