idnits 2.17.1 draft-chan-dmm-enhanced-mobility-anchoring-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2014) is 3575 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.yokota-dmm-scenario' is defined on line 293, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM H. Chan, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational K. Pentikousis, Ed. 5 Expires: January 4, 2015 EICT 6 July 3, 2014 8 Enhanced mobility anchoring 9 draft-chan-dmm-enhanced-mobility-anchoring-00 11 Abstract 13 This document initiates the discussion on enhanced mobility anchoring 14 solutions in the context of a distributed mobility management 15 deployment. Such solutions consider the problem of assigning a 16 mobility anchor and a gateway at the initiation of a session. In 17 addition, the mid-session switching of the mobility anchor in a 18 distributed mobility management environment is considered. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 56 3. Enhanced anchor switching . . . . . . . . . . . . . . . . . . . 4 57 3.1. Anchor switching between subnets . . . . . . . . . . . . . 4 58 3.2. Anchor switching between networks . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 A key requirement in distributed mobility management 69 [I-D.ietf-dmm-requirements] is to enable traffic to avoid traversing 70 single mobility anchor far from the optimal route. Recent 71 developments in research and standardization with respect to future 72 deployment models call for far more flexibility in network function 73 operation and management. For example, the work on service function 74 chaining at the IETF (SFC WG) has already identified a number of use 75 cases for data centers. Although the work in SFC is not primarily 76 concerned with mobile networks, the impact on IP-based mobile 77 networks is not hard to see as by now most hosts connected to the 78 Internet do so over a wireless medium. For instance, as a result of 79 a dynamic re-organization of service chain a non-optimal route 80 between mobile nodes may arise if pme relies solely on centralized 81 mobility management. As discussed earlier in the distributed 82 mobility management working group (DMM WG) this may also occur when 83 the mobile node has moved such that both the mobile node and the 84 correspondent node are far from the mobility anchor via which the 85 traffic is routed. 87 Motivated by the above-mentioned developments as well as 88 [I-D.ietf-dmm-requirements] we aim with this draft to initiate the 89 discussion on enhanced mobility anchoring. Recall that distributed 90 mobility management solutions do not make use of centrally deployed 91 mobility anchor. As such, an application session SHOULD be able to 92 have its traffic passing from one mobility anchor to another as the 93 mobile node moves, or when changing operation and management (OAM) 94 requirements call for mobility anchor switching, thus avoiding non- 95 optimal routes. 97 2. Conventions and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 All general mobility-related terms and their acronyms used in this 104 document are to be interpreted as defined in the Mobile IPv6 base 105 specification [RFC6275] and in the Proxy Mobile IPv6 specification 106 [RFC5213]. This includes terms such as mobile node (MN), 107 correspondent node (CN), home agent (HA), home address (HoA), care- 108 of-address (CoA), local mobility anchor (LMA), and mobile access 109 gateway (MAG). 111 In addition, this document uses the following term: 113 Home network of an application session (or of an HoA) is the network 114 that has allocated the IP address (HoA) used for the session 115 identifier by the application running in an MN. An MN may be 116 running multiple application sessions, and each of these sessions 117 can have a different home network. 119 3. Enhanced anchor switching 121 In this section we consider mid-session mobility anchor switching for 122 two cases. First we discuss the case where the mobile node moves 123 from one subnet to another, and then we discuss the case where the 124 node moves to a different network. Note that although the cases are 125 described with traditional (read: physical) node mobility in mind, 126 the proposed mechanism can be triggered for other operational 127 reasons, such as the redefinition of a service chain graph, due to 128 mechanisms which indicate that by relocating the mobility anchor for 129 certain sessions energy and other operation expenditure can be 130 reduced, or due to emergency situations, such as physical 131 catastrophes. 133 3.1. Anchor switching between subnets 135 First we consider the situation illustrated in Fig. 1: The mobile 136 node (M) moves from Subnet 1 to Subnet 2. Each of the Network A 137 Subnets (1, 2, and so on) owns a block of IP addresses. In each 138 subnet, the corresponding access router (AR1, AR2, ...) advertises 139 the routes for the block of addresses of that subnet. 141 +----------+ 142 | Network A| 143 |Controller| 144 +----------+ 145 +---+ +---+ +---+ 146 |AR1| |AR2| |AR3| 147 +--------+ +--------+ +--------+ 148 |Subnet 1| |Subnet 2| |Subnet 3| .... 149 +--------+ +--------+ +--------+ 151 +----+ +----+ 152 | M | =====> | M | 153 |with| |with| 154 |IP1 | |IP2 | 155 | | |IP1 | 156 +----+ +----+ 158 Figure 1. Movement of M from Subnet 1 to Subnet 2. 160 Before moving, M is allocated an IP address IP1 from Subnet 1, and it 161 may run network applications using this IP address. 163 As M moves to Subnet 2, it obtains a new IP address IP2 from Subnet 164 2. The applications that can handle a change of IP address will use 165 the address IP2 [I-D.seite-dmm-dma]. Other ongoing applications that 166 cannot survive an IP address change will need to continue using IP11 167 to maintain session continuity. A mobility management protocol may 168 be used to enable M to use the address IP1 belonging to Subnet 1. 170 The AR1 access router in Subnet 1 may delegate the IP address (IP1) 171 to the access router AR2 in Subnet 2. AR2 will then advertise IP1 so 172 that the routing tables in Network A will be updated and packets 173 destined to IP1 will be routed to Subnet 2. 175 Relying on earlier routing table update mechanisms with a distributed 176 routing protocol may not be fast enough to meet the requirement for a 177 short handover delay. In the case where a control and data plane 178 separation model is followed, a logically centralized mechanism can 179 perform the forwarding table update faster. For example, we can 180 consider the use of I2RS mechanisms or the possibility to employ 181 NETCONF [RFC6241] for reconfiguring AR2. 183 Alternatively, a tunneling mobility management protocol such as MIPv6 184 [RFC6275] or PMIPv6 [RFC5213] may be used initially [Paper- 185 Distributed.Mobility.PMIP] to enable M to use the IP address IP1 186 while IP1 still belongs to Subnet 1. The route may not be optimized 187 initially, but this is a good tradeoff so that anchor switching can 188 take place. After anchor switching and its subsequent forwarding 189 table update have been completed, packets destined to IP1 will be 190 routed directly towards M. 192 The address delegation of IP1 from Subnet 1 to Subnet 2 may timeout 193 unless there is request to renew it before it expires. When all 194 applications using IP1 in M have been terminated, there will be no 195 longer need for using IP1 in Subnet 2. If there are still such 196 applications running when the address delegation is about to timeout, 197 the mobile node may signal with AR1 to request renewal of address 198 delegation. 200 3.2. Anchor switching between networks 202 Fig. 2 illustrates the movement of a mobile node (M) from Subnet a1 203 of Network A to Subnet b2 of Network B. In this case, each Network 204 (A, B, and so on) owns the aggregate of IP addresses blocks for its 205 subnets. The corresponding gateway routers (GWa, GWb, ...) may run 206 an IBGP among them, and each advertises the aggregate of IP addresses 207 for its subnets. 209 +---+ +---+ +---+ 210 |GWa| |GWb| |GWc| 211 +----------+ +----------+ +----------+ 212 |Network A | |Network B | |Network C | .... 213 |Controller| |Controller| |Controller| 214 +----------+ +----------+ +----------+ 216 +----+ +----+ 217 |ARa1| |ARb2| 218 +---------+ +---------+ 219 |Subnet a1| |Subnet b2| .... 220 +---------+ +---------+ 222 +-----+ +-----+ 223 | M | =====> | M | 224 | with| | with| 225 |IPa11| |IPb21| 226 | | |IPa11| 227 +-----+ +-----+ 229 Figure 1. Movement of M from Subnet a1 of Network A to Subnet b2 of 230 Network B. 232 Before moving, M is allocated the IP address IPa11 from Subnet a1 of 233 Network A, and it may run network applications using this IP address. 235 As M moves to Subnet b2, it obtains a new IP address IPb21 from 236 Subnet b2 of Network B. The applications that can handle a change of 237 IP address will use this new address IPb21. Other applications with 238 ongoing sessions that cannot survive an IP address change will need 239 to continue using IPa11 to maintain session continuity. A mobility 240 management protocol may be used to enable M to use the address IPa11 241 belonging to Subnet a1 in Network A. 243 As the access router ARa1 in Subnet a1 may delegate the address IPa11 244 to the access router ARb2 in Subnet b2, the gateways GWa, GWb, ... 245 also need to update the routing information so that GWb will then 246 advertise IPa11 so that the routing tables in GWa, GWb, ... will 247 update and packets destined to IPa11 will be routed to Network B. 249 The routing table update between the gateways MAY be accomplished 250 using IS-IS. In scenarios where the control plane and the data plane 251 for these gateways are separate, and there is a controller for these 252 gateways, a centralized routing protocol can also perform the 253 forwarding table update for these gateways. 255 Optionally, a tunneling mobility management protocol such as MIPv6 256 [RFC6275] or PMIPv6 [RFC5213] may be used to initially enable M to 257 use the address IPa11 while IPa11 still belongs to Subnet a1 of 258 Network A. Although such a route may not be optimized initially, it 259 enables anchor switching to take place. After anchor switching and 260 its subsequent forwarding table update have been completed, the 261 packets destined to IPa11 will be routed directly towards M. 263 The address delegation of IPa11 from Subnet a1 to Subnet b2 may 264 timeout unless there is request to renew it before it expires. When 265 the applications uisng IPa11 in M have all been terminated, there 266 will be no longer need for using IPa11 in Subnet b2. If there are 267 still such applications running when the address delegation is about 268 to timeout, the mobile node may signal with ARa1 to request renewal 269 of address delegation. 271 4. Security Considerations 273 TBD 275 5. IANA Considerations 277 This document presents no IANA considerations. 279 6. References 280 6.1. Normative References 282 [I-D.ietf-dmm-requirements] 283 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 284 "Requirements for Distributed Mobility Management", 285 draft-ietf-dmm-requirements-17 (work in progress), 286 June 2014. 288 [I-D.seite-dmm-dma] 289 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 290 Anchoring", draft-seite-dmm-dma-07 (work in progress), 291 February 2014. 293 [I-D.yokota-dmm-scenario] 294 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 295 scenarios for Distributed Mobility Management", 296 draft-yokota-dmm-scenario-00 (work in progress), 297 October 2010. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 303 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 305 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 306 Bierman, "Network Configuration Protocol (NETCONF)", 307 RFC 6241, June 2011. 309 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 310 in IPv6", RFC 6275, July 2011. 312 6.2. Informative References 314 [Paper-Distributed.Mobility.PMIP] 315 Chan, H., "Proxy Mobile IP with Distributed Mobility 316 Anchors", Proceedings of GlobeCom Workshop on Seamless 317 Wireless Mobility, December 2010. 319 [Paper-Distributed.Mobility.Review] 320 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 321 "Distributed and Dynamic Mobility Management in Mobile 322 Internet: Current Approaches and Issues", February 2011. 324 Authors' Addresses 326 H Anthony Chan 327 Huawei Technologies 328 5340 Legacy Dr. Building 3 329 Plano, TX 75024 330 USA 332 Email: h.a.chan@ieee.org 334 Kostas Pentikousis 335 EICT 336 EUREF-Campus Haus 13 337 Torgauer Strasse 12-15 338 10829 Berlin 339 Germany 341 Email: k.pentikousis@eict.de