idnits 2.17.1 draft-liu-dmm-dynamic-anchor-discussion-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: September 6, 2012 W. Luo 6 ZTE 7 March 5, 2012 9 DMM Dynamic Anchor Discussion 10 draft-liu-dmm-dynamic-anchor-discussion-00 12 Abstract 14 Distributed mobility management aims to distribute the mobility 15 anchor to the access network level to avoid the centralized mobility 16 anchor problem. By distributing the mobility anchor, the traffic can 17 be distributed in an optimal way. There are many different proposals 18 for DMM solution, one of those types of solution is called "dynamic 19 anchor". This document analyses the limitations of current dynamic 20 anchor solution and discusses the possible solution to overcome those 21 limitations. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Problem of dynamic anchor and potential solution . . . . . . . 3 64 1.1. Active session managment . . . . . . . . . . . . . . . . . 3 65 1.2. Soure address selection . . . . . . . . . . . . . . . . . . 4 66 1.3. CN address selection . . . . . . . . . . . . . . . . . . . 4 67 1.4. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.5. Resource consumption consideration . . . . . . . . . . . . 5 69 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 74 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Problem of dynamic anchor and potential solution 79 As draft [I-D.draft-seite-dmm-dma-00] introduced, the main idea of 80 dynamic anchor is distributing the mobility anchor function in the 81 access router (MAR). The newly initiated session is routed through 82 the current MAR, only the original sessions that established before 83 handover will be maintained at the previous anchor. As the following 84 figure shows, flow1 is anchored to MAR1, flow2 is anchored to MAR2. 85 Two different prefixes are assigned to the MN. 87 +--------------+ 88 | Policy Server| 89 +-.-'--+-----`.+ 90 +---+ .' | `. flow2 +----+ 91 |CN1| .-' | `.____,| CN2| 92 ++--+ .' | ,-'''' `. +----+ 93 flow1\ +-----.-'--+ +----+--.'-+ +---`.-----+ 94 +-------. | | | | | | 95 | MAR1 `-+-'''''-..MAR2.'| | MRA3 | 96 +----------+ +----+-+---+ +----------+ 97 | | 98 HNP1 | | HNP2 99 +--`-+-+ 100 | MN | 101 +------+ 102 Figure 1 There are several potential problems for this solution 104 1.1. Active session managment 106 In this dynamic anchor solution, the MAR needs to know whether a 107 prefix is active, if not, the MAR need to release the mobility 108 binding. For instance, when the MN attach to MAR1, MAR1 detects the 109 attachment of MN and allocate HNP1 to the MN. When the MN moves to 110 MAR2, MAR2 needs to know that there is one on-going session in the MN 111 and needs to trigger mobility binding update to MAR1 to update the 112 binding. 114 The question is how MAR2 know that there is an active session for 115 HNP1 in MN? The first approach is to use policy server to store the 116 MN-ID and corresponding home network prefix that allocate to the MN. 117 When MN moves to MAR2, as mentioned in [I-D.draft-seite-dmm-dma-00], 118 MAR2 first check the policy server and find that MN is anchored to 119 MAR1, then it can send binding update message to MAR1. But only that 120 is not enough. MAR2/MAR1 has to have some mechanism to trigger the 121 release HNP1, otherwise the MAR1 will always be occupied by the MN as 122 one of its anchor point. This will lead system capacity waste. For 123 example, after the on-going session is terminated, the MAR2 need to 124 release the HNP1. 126 The question is that the policy server does not know when to release 127 HNP1. One of possible solution is that MAR2 can inspect the traffic 128 that has the source address prefix equals to HNP1. When MAR2 finds 129 that there is no traffic sourced from HNP1 for a certain time, it can 130 send deregistration binding update to MAR1 and release the binding 131 state for HNP1. It seems that MAR2 needs a certain kind of timer to 132 support the inspection for each sessions. If in this way, system 133 capacity consumed by those timers can not be ignored since the 134 traffic from hundreds of mobile nodes which are in a same MAR may 135 have many thousands of sessions. 137 1.2. Soure address selection 139 MN may be configured with multiple addresses. For example, MN can 140 have HNP1 and HNP2 at the same time. In this case, the MN's 141 application need to select the correct source address. For example, 142 there maybe a VoIP session running using HNP1 when MN attaches to 143 MAR1. When MN moves to MAR2 , the VoIP session need to continue. 144 When the user start a web browser, MAR2 will allocate a new perfix: 145 HNP2. The VoIP software need to select HNP1 as the source address 146 and the web browser need to select HNP2 as source address. RFC3484 147 specifies the source address selection rules for IPv6 but RFC3484 is 148 not enough to cope with this situation since RFC3284 does not specify 149 how to select source address for a particular application. 151 To solve this problem, the host may use the following rules for 152 source address selection: 154 a. For any on-going session, keep to use the original address even 155 there is a newly address been configured for the same interface. 157 b. For any new session, always choose to use the newly allocated 158 address. The new MAR need to advertise the newly allocated 159 prefix as the highest priority. 161 1.3. CN address selection 163 From the CN's perspective, the MN has multiple addresses, the CN 164 needs to know which one it should use when it wants to initiate a 165 session to MN. 167 1.4. IPv4 support 169 It will worse the IPv4 address depletion problem if use the dynamic 170 anchor solution for IPv4 since each MN will need multiple IP 171 addresses in that case. 173 1.5. Resource consumption consideration 175 _.------. 176 ,---'' `------------------. 177 ,' +----------+ `-. 178 / |Session DB| : 179 ( +----------+ MARn 180 \ / ``---MN 181 `. _.----'(HoA1,HoA2,HoA3,..,HoAn) 182 'MAR1----MAR2------------MAR3' ..+ 183 .' \ move _..-'/ 184 .' move \ move __..--'' 185 MN --------> MN --------> MN 186 (HoA1) (HoA1,HoA2) (HoA1,HoA2,HoA3) 187 Figure2. Resource consumption 189 As illustrated in figure2, during the movement, mobile node gets more 190 and more HoAs and more and more MARs will be occupied by this mobile 191 node as its anchor points. The mobile node could maintain its HoAs 192 by keep on sending packets at very low data rate for each sessions. 193 In this way, capacity of the network will be consumed, e.g. many 194 tunnels should be maintained among those MARs, many mobility contexts 195 for this mobile node should be maintained among those MARs, and the 196 operator will gain almost nothing from this mobile node. 197 Additionally, the scenario described above provides a possibility for 198 attackers to consume network resource maliciously. 200 2. IANA Considerations 202 This document makes no request of IANA. 204 Note to RFC Editor: this section may be removed on publication as an 205 RFC. 207 3. Security Considerations 209 TBD 211 4. Acknowledgements 213 TBD 215 5. References 216 5.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 5.2. Informative References 223 [I-D.draft-seite-dmm-dma-00] 224 Seite , P. and P. Bertin, "Distributed Mobility Anchoring, 225 draft-seite-dmm-dma-00", February 2012. 227 Authors' Addresses 229 Dapeng Liu 230 China Mobile 231 32 Xuanwumen West Street 232 Beijng, Xicheng District, 100053 233 China 235 Phone: +86-13911788933 236 Email: liudapeng@chinamobile.com 238 Hui Deng 239 China Mobile 240 32 Xuanwumen West Street 241 Beijng, Xicheng District, 100053 242 China 244 Phone: +86-13911788933 245 Email: denghui@chinamobile.com 247 Wen Luo 248 ZTE 249 No.68, Zijinhua RD,Yuhuatai District 250 Nanjing, Jiangsu 210012 251 China 253 Email: luo.wen@zte.com.cn