idnits 2.17.1 draft-bernardos-netext-ll-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 ([RFC5213]), 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 8, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: September 9, 2010 JC. Zuniga 6 InterDigital Communications, LLC 7 T. Melia 8 Alcatel-Lucent Bell Labs 9 March 8, 2010 11 Applicability Statement on Link Layer implementation/Logical Interface 12 over Multiple Physical Interfaces 13 draft-bernardos-netext-ll-statement-01 15 Abstract 17 The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6) as [RFC5213]. 18 PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam 19 across gateways without changing the IP address. PMIPv6 also 20 provides limited multi-homing support to multi-mode mobile devices. 22 Proxy mobility is based on the assumption that changes in host IP 23 stacks are undesirable. Link layer implementations can hide the 24 actually used physical interfaces from the IP stack. These 25 techniques can be used to achieve inter-access technology handovers 26 or flow mobility, i.e., the movement of selected flows from one 27 access technology to another. It is assumed that an IP layer 28 interface can simultaneously and/or sequentially attach to multiple 29 MAGs (possibly over multiple media). This document provides an 30 informational applicability statement that analyzes the issues 31 involved with this approach (i.e. hiding access technology changes 32 from host IP layer) and characterizes the contexts in which such use 33 is or is not appropriate to achieve inter-access handovers or flow 34 mobility. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on September 9, 2010. 59 Copyright Notice 61 Copyright (c) 2010 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Hiding access technology changes . . . . . . . . . . . . . . . 4 78 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 7 80 3.2. Logical Interface . . . . . . . . . . . . . . . . . . . . . 8 81 3.3. Layer 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 93 based mobility management to hosts connecting to a PMIPv6 domain. 94 PMIPv6 introduces two new functional entities, the Local Mobility 95 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 96 first layer three hop detecting Mobile Node's (MN) attachment and 97 providing IP connectivity. The LMA is the entity assigning one or 98 more Home Network Prefixes (HNPs) to the MN and is the topological 99 anchor for all traffic from/to the MN. 101 Proxy mobility is based on the assumption that changes in host IP 102 stacks are undesirable. Link layer implementations can hide the 103 actually used physical interfaces from the IP stack. These 104 techniques can be used to achieve inter-access technology handovers 105 or flow mobility, i.e., the movement of selected flows from one 106 access technology to another. It is assumed that an IP layer 107 interface can simultaneously and/or sequentially attach to multiple 108 MAGs (possibly over multiple media). This document provides an 109 informational applicability statement that analyzes the issues 110 involved with this approach and characterizes the contexts in which 111 such use is or is not appropriate. 113 2. Hiding access technology changes 115 There are several techniques/mechanisms that allow hiding access 116 technology changes or movement from host IP layer. This section 117 classifies these existing techniques into a set of generic 118 approaches, according to their most representative characteristics. 119 We then refer to these generic mechanisms later in the document, when 120 analyzing their applicability to inter-access technology and flow 121 mobility purposes in PMIPv6. 123 The following generic mechanisms can hide access technology changes 124 from host IP layer: 126 o Link layer support: certain link layer technologies are able to 127 hide physical media changes from the upper layers (see Figure 1). 128 For example, IEEE 802.11 is able to seamlessly change between IEEE 129 802.11a/b/g physical layers. Also, an 802.11 STA can move between 130 different Access Points (APs) within the same domain without the 131 IP stack being aware of the movement. In this case, the IEEE 132 802.11 MAC layer takes care of the mobility, making the media 133 change invisible to the upper layers. Another example is IEEE 134 802.3, that supports changing the rate from 10Mbps to 100Mbps and 135 to 1000Mbps. 137 Mobile Node 138 +-----------------------+ 139 | TCP/UDP | AR1 AR2 140 +-----------------------+ +-----+ +-----+ 141 | IP | | IP | | IP | 142 +-----------------------+ +-----+ +-----+ 143 | Link Layer (L2) | | L2 | | L2 | 144 +-----+-----+-----+-----+ +-----+ +-----+ 145 | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | 146 +-----+-----+-----+-----+ +-----+ +-----+ 147 ^ ^ 148 |_________________________________________| 150 Figure 1: Link layer support solution architecture 152 There are also other examples with more complicated architectures, 153 like for instance, 3GPP Rel-8. In this case, a UE can move 154 (inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this 155 movement invisible to the IP layer at the UE, and also to the LMA 156 logical component at the PGW. The link layer stack at the UE 157 (i.e. PDCP and RLC layers), and the GTP between the RAN and the 158 SGW (which plays the role of inter-3GPP AN mobility anchor) hide 159 this kind of mobility, which is not visible to the IP layer of the 160 UE (see Figure 2). 162 --------- 163 | Appl. |<-----------------------------------------------------> 164 --------- ---------- 165 | |<+ - - - - - - - - - - - - - - - - - - - - +>| | 166 | IP | . ----------------- . ------------------- . | IP | 167 | |<+>| relay |<+>| relay | . | | 168 --------- . ----------------- . ------------------- . ---------- 169 | PDCP |<+>| PDCP | GTP-U |<+>| GTP-U | GTP-U |<+>| GTP-U | 170 --------- . ----------------- . ------------------- . ---------- 171 | RLC |<+>| RLC | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP | 172 --------- . ----------------- . ------------------- . ---------- 173 | MAC |<+>| MAC | L2 |<+>| L2 | L2 |<+>| L2 | 174 --------- . ----------------- . ------------------- . ---------- 175 | L1 |<+>| L1 | L1 |<+>| L1 | L1 |<+>| L1 | 176 --------- . ----------------- . ------------------- . ---------- 177 UE Uu E-UTRAN S1-U SGW S5/S8a PGW 179 Figure 2: 3GPP Rel-8 data plane architecture (GTP option) 181 o Logical interface: this refers to solutions (see Figure 3) that 182 logically group/bond several physical interfaces so they appear to 183 the upper layers (i.e. IP) as one single interface (where 184 application sockets bind). Depending on the OS support, it might 185 be possible to use more than one physical interface at a time -- 186 so the node is simultaneously attached to different media -- or 187 just to provide a fail-over mode. Controlling the way the 188 different media is used (simultaneous, sequential attachment, etc) 189 is not trivial and requires additional intelligence and/or 190 configuration at the logical interface device driver. An example 191 of this type of solution is the virtual interface 192 [I-D.yokota-netlmm-pmipv6-mn-itho-support] or the bonding driver. 194 +----------------------------+ 195 | TCP/UDP | 196 Session to IP +->| | 197 address binding | +----------------------------+ 198 +->| IP | 199 IP to logical +->| | 200 interface binding | +----------------------------+ 201 +->| Logical interface | 202 logical to physical +->| (MN-HoA) | 203 interface binding | +----------------------------+ 204 +->| L2 | L2 | | L2 | 205 |(IF#1)|(IF#2)| ..... |(IF#n)| 206 +------+------+ +------+ 207 | L1 | L1 | | L1 | 208 | | | | | 209 +------+------+ +------+ 211 Figure 3: Logical interface architecture 213 o Layer 2.5: another potential solution is to add a layer 2.5 (e.g., 214 shim-layer) on top of multiple L2 media. In this case, the so- 215 called layer 2.5 takes care of making inter-media support 216 transparent to upper layers (i.e. IP). The layer 2.5 217 functionality can reside only in the mobile node or it can also 218 have a layer 2.5 counterpart in the network (see Figure 4). 219 Communication between the layer 2.5 functionality in the mobile 220 node and in the network can either take place over L2 or L3 221 signaling, as described in RFC5164 [RFC5164] and RFC5677 222 [RFC5677]. 224 Mobile Node 225 +-----------------------+ 226 | TCP/UDP | AR1 AR2 227 +-----------------------+ +------+ +------+ 228 | IP | | IP | | IP | 229 +-----------------------+ +------+ +------+ 230 | Layer 2.5 | | L2.5 | | L2.5 | 231 +-----------------------+ +------+ +------+ 232 | L2a | L2b | L2c | L2d | | L2d | | L2b | 233 +-----+-----+-----+-----+ +------+ +------+ 234 | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | 235 +-----+-----+-----+-----+ +------+ +------+ 236 ^ ^ 237 |___________________________________________| 239 Figure 4: Layer 2.5 support solution architecture 241 3. Applicability Statement 243 This section analyzes the issues involved with the approaches 244 described in Section 2 and characterizes the contexts in which their 245 use is or is not appropriate. 247 3.1. Link Layer Support 249 Link layer mobility support applies to cases when the same link layer 250 technology is used and mobility can be fully handled at these layers. 251 One example is the case where several 802.11 APs are deployed in the 252 same subnet and all of them share higher layer resources such as DHCP 253 server, IP gateway, etc. In this case the APs can autonomously (or 254 with the help of a central box) communicate and control the STA 255 association changes from one AP to another, without the STA being 256 aware of the movement. This type of scenario is applicable to cases 257 when the different points of attachment (i.e. APs) belong to the 258 same network domain, e.g. enterprise, hotspots from same operator, 259 etc. 261 This type of solution does not typically allow for simultaneous 262 attachment to different access networks, and therefore can only be 263 considered for inter-access technology handovers, but not for flow 264 mobility. Existing RFC 5213 handover hint mechanisms could benefit 265 from link layer information (e.g. triggers) to detect and identify MN 266 handovers. 268 Link layer support is not applicable when two different access 269 technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the 270 same is true when the same access technology expands over multiple 271 network domains. 273 3.2. Logical Interface 275 The use of a logical interface allows the mobile node to provide a 276 single interface view to the layers above IP. Upper layers can bind 277 to this interface, which hides inner inter-access technology 278 handovers or data flow transfers among different physical interfaces. 280 This type of solution may support simultaneous attachment, in 281 addition to sequential attachment. It requires additional support at 282 the node and the network in order to benefit from simultaneous 283 attachment. For example, since the IP stack at the mobile does only 284 "see" one interface, special mechanisms are required to enable 285 addressing a particular interface from the network. Unmodified 286 standard Neighbor Discovery cannot be used to detect MN attachment, 287 since all physical interfaces are bound to the same logical IP 288 interface. Extensions to PMIPv6 would be required in order to enable 289 the network (i.e., the MAG and LMA) deal with physical interfaces, 290 instead to IP interfaces as current RFC5213 does. RFC5213 assumes 291 that each physical interface capable of attaching to a MAG is an IP 292 interface, while the logical interface solution groups several 293 physical interfaces under the same IP logical interface. 295 3.3. Layer 2.5 297 The layer 2.5 mobility support applies to cases similar to the ones 298 described in Section 3.1, although in this case heterogeneous 299 networks can be considered (i.e. 802.11 WLAN and 802.16 WiMAX 300 networks), as well as networks of the same access technology that 301 expand over multiple network domains. 303 Hints from the layer 2.5 can help both the network and the mobile 304 node perform inter-access technology handovers while ensuring the 305 mobile node keeps using the same IP address. 307 4. IANA Considerations 309 This document makes no request of IANA. 311 5. Security Considerations 313 TBD 315 6. Acknowledgments 317 The research of Carlos J. Bernardos and Antonio de la Oliva leading 318 to these results has received funding from the European Community's 319 Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 320 214994 (CARMEN project). The work of Carlos J. Bernardos has also 321 received funding from the Ministry of Science and Innovation of 322 Spain, under the QUARTET project (TIN2009-13992-C02-01 324 7. References 326 7.1. Normative References 328 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 329 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 331 7.2. Informative References 333 [I-D.yokota-netlmm-pmipv6-mn-itho-support] 334 Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K. 335 Leung, "Virtual Interface Support for IP Hosts", 336 draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in 337 progress), March 2010. 339 [RFC5164] Melia, T., "Mobility Services Transport: Problem 340 Statement", RFC 5164, March 2008. 342 [RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, 343 "IEEE 802.21 Mobility Services Framework Design (MSFD)", 344 RFC 5677, December 2009. 346 Authors' Addresses 348 Carlos J. Bernardos 349 Universidad Carlos III de Madrid 350 Av. Universidad, 30 351 Leganes, Madrid 28911 352 Spain 354 Phone: +34 91624 6236 355 Email: cjbc@it.uc3m.es 356 URI: http://www.it.uc3m.es/cjbc/ 357 Antonio de la Oliva 358 Universidad Carlos III de Madrid 359 Av. Universidad, 30 360 Leganes, Madrid 28911 361 Spain 363 Phone: +34 91624 8803 364 Email: aoliva@it.uc3m.es 365 URI: http://www.it.uc3m.es/aoliva/ 367 Juan Carlos Zuniga 368 InterDigital Communications, LLC 370 Email: JuanCarlos.Zuniga@InterDigital.com 372 Telemaco Melia 373 Alcatel-Lucent Bell Labs 375 Email: Telemaco.Melia@alcatel-lucent.com