idnits 2.17.1 draft-bernardos-netext-pmipv6-nemo-ps-02.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 abstract seems to contain references ([I-D.ietf-netext-pd-pmip]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-netext-pd-pmip-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group CJ. Bernardos 3 Internet-Draft M. Calderon 4 Intended status: Informational UC3M 5 Expires: September 13, 2012 I. Soto 6 UPM 7 March 12, 2012 9 PMIPv6 and Network Mobility Problem Statement 10 draft-bernardos-netext-pmipv6-nemo-ps-02 12 Abstract 14 The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 15 enables mobile devices to connect to a PMIPv6 domain and roam across 16 gateways without changing the IP address. 18 Current PMIPv6 specification does only support the movement of hosts 19 within the localized mobility domain. A mobile network (commonly 20 referred to as a NEMO, NEtwork that MOves) can also benefit from the 21 network-based localized mobility support provided by PMIPv6 22 [I-D.ietf-netext-pd-pmip], but with some limitations. This I-D 23 describes what can be done with current standardized protocols, and 24 describes the problem statement of fully supporting network mobility 25 in Proxy Mobile IPv6. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4 63 3. PMIPv6 and Network Mobility Problem Statement . . . . . . . . 4 64 3.1. Applicability of existing standards . . . . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction and Motivation 75 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network- 76 based mobility management to hosts connecting to a PMIPv6 domain. 77 PMIPv6 introduces two new functional entities, the Local Mobility 78 Anchor (LMA) and the Mobility Access Gateway (MAG). The MAG is the 79 first layer three hop detecting Mobile Node (MN) attachment and 80 providing IP connectivity. The LMA is the entity assigning one or 81 more Home Network Prefixes (HNPs) to the MN and is the topological 82 anchor for all traffic from/to the MN. 84 The network-based localized mobility support provided by PMIPv6 was 85 designed for hosts, so a mobile host can freely roam within the 86 PMIPv6 domain, without changing its IP address. An interesting 87 scenario -- which is not supported by current standards (as we will 88 explain later in this document) -- is the following: let's consider a 89 scenario in which users move around a large area (e.g., an airport, 90 an exhibition site, a fairground or even a metropolitan area covered 91 by different public transportation systems). In these areas, 92 attachment points to the Internet might be available both in fixed 93 locations (such as coffee shops, airport terminals or train stations) 94 or in mobile platforms, such as vehicles (e.g., buses that move 95 between pavilions at a fair or a train that moves from one terminal 96 to another at an airport). Users demand the ability to keep their 97 ongoing communications while changing their point of attachment to 98 the network as they move around (e.g., when a user leaves a coffee 99 shop and gets on a bus). 101 While PMIPv6 [RFC5213] is the solution specified to provide network- 102 based localized mobility support (which nicely fits the requirements 103 related to providing Internet access in a large area, such as in the 104 use cases described above), and the NEMO Basic Support Protocol 105 [RFC3963] is the solution to provide transparent network mobility 106 support to a set of nodes moving together (which nicely fits the 107 requirements related to providing Internet access to users in mobile 108 platforms, such in the use cases described above), these two 109 solutions cannot fully cope -- neither working standalone nor in a 110 combined fashion -- with the kind of use case introduced above. We 111 need therefore a solution -- which may be for example based on 112 extending NEMO mechanisms, extending PMIPv6 or both -- to address 113 this scenario. We next explain with a bit more detail the problem 114 statement of combining PMIPv6 with network mobility support and 115 explain why current IETF standards are not able to fully tackle this 116 problem. 118 2. Conventions and Terminology 120 Readers are expected to be familiar with all the terms defined in 121 [RFC5213], [RFC3753] and [RFC4885]. In addition, the following terms 122 are used in the context of this problem statement: 124 MR/MAG 126 We use this term to refer to the router providing connectivity to 127 a set of nodes moving together. We do not use the term Mobile 128 Router (MR) to avoid confusion with its well accepted meaning in 129 the context of the NEMO Basic Support protocol (i.e. we do not 130 assume nor prevent the MR/MAG to implement the MR functionality 131 specified in [RFC3963]). Analogously, since the nodes attached to 132 the MR/MAG are expected to obtain network-based localized mobility 133 support, it might be tempting to refer to this entity as a MAG, 134 but an RFC 5213-compliant MAG cannot move (i.e. change its point 135 of attachment within the PMIPv6 domain). 137 Network Mobility 139 Within the scope of this document, we refer to network mobility as 140 the capacity of a set of nodes -- attached to an MR/MAG -- to move 141 together _within_ the PMIPv6 domain (similarly as done in 142 [I-D.ietf-netext-pd-pmip]). We do not consider the case of mobile 143 networks that may roam across PMIPv6 domains (i.e. global 144 mobility). Although this scenario might be also interesting, 145 current PMIPv6 does not support inter-domain mobility, thus we 146 limit the scope of the problem statement to the same of PMIPv6. 148 3. PMIPv6 and Network Mobility Problem Statement 150 Figure 1 shows an example of the use case scenario described in 151 Section 1. Let's consider a very simple PMIPv6 domain composed of 152 one LMA and two MAGs: MAG 1 and MAG 2. There are three MNs: MN 1, MN 153 2 and MN 3. Additionally, there is also an MR/MAG: MER/MAG 1. The 154 goal is to enable any MN to freely roam within the PMIPv6 domain, 155 without changing its IP address -- and without requiring any mobility 156 support nor involvement from the MN -- even if the MN moves between 157 the mobile network and the fixed access network (i.e. the MN changes 158 its point of attachment from the MR/MAG 1 to the MAG 1 or MAG 2). 160 +-----+ 161 | LMA | 162 +-----+ 163 // \\ 164 +---------//---\\-------------+ 165 ( // \\ ) PMIPv6 domain 166 ( // \\ ) 167 +------//---------\\----------+ 168 // \\ 169 // \\ 170 +-------+ +-------+ 171 | MAG 1 | | MAG 2 | 172 +-------+ +-------+ 173 | | 174 (( o )) (( o )) 176 . .. . .. . .. . .. . .. . .. . 177 : mobile network : 178 . ( o ) . ( o ) 179 : | : | 180 . | ---------- . ------ | 181 : --|MR/MAG 1|-- : |MN 1|-- 182 . ---------- | . ------ 183 : | : 184 . << v >> . 185 : : 186 . Y Y . 187 : ------ | | ------ : 188 . |MN 2|-- --|MN 3| . 189 : ------ ------ : 190 . .. . .. . .. . .. . .. . .. . 192 Figure 1: PMIPv6 and network mobility scenario 194 3.1. Applicability of existing standards 196 This section briefly analyzes how the use of current standards fails 197 to fully support the scenario described in this problem statement: 199 1. PMIPv6 only. By using PMIPv6 only, a single host (i.e. an MN) 200 would be able to freely roam between fixed points of attachment 201 (MAG 1 and MAG 2 in Figure 1). By enabling bridging on an MR/MAG 202 attaching to a fixed MAG, some very limited kind of network 203 mobility support could be achieved (if the Per-MN-Prefix model 204 [RFC5213] is used). [I-D.ietf-netext-pd-pmip] specifies 205 extensions to Proxy Mobile IPv6 to support network mobility. 206 However, none of these approaches do support a mobile node 207 leaving the mobile network and attaching to another MAG (or MR/ 208 MAG) without changing IP address of the mobile node. 210 2. NEMO Basic Support (NEMO B.S.) only. In this case, MAG 1 and MAG 211 2 in the example of Figure 1 would only play the role of plain 212 IPv6 Access Routers. If NEMO B.S is enabled on the MR/MAG (and a 213 Home Agent is deployed in the network), a set of nodes would be 214 able to freely roam within the domain . However, an MN would not 215 be able to move between the mobile network and the fixed access 216 network (because the addresses that nodes may use while connected 217 to the MR/MAG would belong to the Mobile Network Prefix -- MNP -- 218 of the network, which is different from the prefixes provided by 219 the LMA within the PMIPv6 domain). Additionally, this scenario 220 requires the deployment of a NEMO B.S. Home Agent (for example at 221 the location where the LMA is placed in Figure 1) and involves 222 the NEMO B.S. signaling every time the MR/MAG moves. 224 3. NEMO B.S. + PMIPv6: by enabling NEMO B.S. on the MR/MAG and 225 deploying PMIPv6 in the domain, we would achieve the same level 226 of functionality as the previous case, but saving the NEMO 227 signaling required every time the MR/MAG moves, since its Care-of 228 Address (CoA) would not change while it is roaming within the 229 domain (the address the MR/MAG uses as CoA is anchored at the LMA 230 and does not change despite of the MR/MAG movements, thanks to 231 the PMIPv6 support). In this scenario, NEMO B.S. HA and the 232 PMIPv6 LMA could be collocated. 234 The previous compilation of potential approaches does not consider 235 the use of Mobile IPv6 [RFC6275] on the MNs, since this would not 236 meet the fundamental feature of network-based localized mobility 237 solutions (such as PMIPv6): not to involve the MN on the signaling 238 nor on the management of its own mobility. 240 As shown, with existing standards, there is no way of achieving the 241 level of functionality required in our scenario. It is therefore 242 required to work on new solutions/extensions to existing protocols 243 (either to the NEMO B.S., to PMIPv6 or to both when working in a 244 combined way). 246 4. IANA Considerations 248 This document makes no request of IANA. 250 5. Security Considerations 252 Security considerations regarding the MR/MAG would be needed. It 253 might be safe to assume that the MR/MAG has the same level of trust/ 254 security that the MAGs of the network, but this may depend on the 255 particular solution. 257 6. Acknowledgments 259 The work of Carlos J. Bernardos has also been partially supported by 260 the European Community's Seventh Framework Programme (FP7-ICT-2009-5) 261 under grant agreement n. 258053 (MEDIEVAL project). The research of 262 Carlos J. Bernardos and Maria Calderon has also been partially 263 supported by the Ministry of Science and Innovation of Spain under 264 the QUARTET project (TIN2009-13992-C02-01). 266 7. References 268 7.1. Normative References 270 [I-D.ietf-netext-pd-pmip] 271 Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and 272 C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6", 273 draft-ietf-netext-pd-pmip-02 (work in progress), 274 March 2012. 276 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 277 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 278 RFC 3963, January 2005. 280 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 281 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 283 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 284 in IPv6", RFC 6275, July 2011. 286 7.2. Informative References 288 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 289 RFC 3753, June 2004. 291 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 292 Terminology", RFC 4885, July 2007. 294 Authors' Addresses 296 Carlos J. Bernardos 297 Universidad Carlos III de Madrid 298 Av. Universidad, 30 299 Leganes, Madrid 28911 300 Spain 302 Phone: +34 91624 6236 303 Email: cjbc@it.uc3m.es 304 URI: http://www.it.uc3m.es/cjbc/ 306 Maria Calderon 307 Universidad Carlos III de Madrid 308 Av. Universidad, 30 309 Leganes, Madrid 28911 310 Spain 312 Phone: +34 91624 8780 313 Email: maria@it.uc3m.es 315 Ignacio Soto 316 Universidad Politecnica de Madrid 318 Email: isoto@dit.upm.es