idnits 2.17.1 draft-tu-netext-mn-status-option-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 : ---------------------------------------------------------------------------- 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 9, 2012) is 4309 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group Y. Tu 3 Internet-Draft C. Zhu 4 Intended status: Standards Track ZTE 5 Expires: January 10, 2013 CJ. Bernardos 6 UC3M 7 C. Williams 8 MCSR Labs 9 July 9, 2012 11 MN Status Option for Proxy Mobile IPv6 12 draft-tu-netext-mn-status-option-02 14 Abstract 16 IP flow mobility enables the ability of movement of selected flows 17 from one access technology to another. This document extends the 18 Proxy Mobile IPv6 signaling to convey mobile node's status 19 information that can be used by the network to decide when and how 20 perform flow mobility. It also defines options allowing the network 21 getting information about different mobile node capabilities, which 22 might be considered to decide how to tackle the node's mobility. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 10, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . . 3 60 3. New MN status and capabilities options for PMIPv6 . . . . . . . 3 61 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Use case scenarios . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. MAG considerations . . . . . . . . . . . . . . . . . . 5 65 3.3.2. LMA considerations . . . . . . . . . . . . . . . . . . 5 66 3.4. Mobile Node Status and Capabilities Options . . . . . . . . 6 67 3.4.1. Mobile Node Capability Status Option . . . . . . . . . 6 68 3.4.2. Mobile Node Connectivity Status Option . . . . . . . . 7 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 There are several use cases where it would be useful that the local 78 mobility anchor (LMA) can decide to perform flow mobility from one 79 access network to another, e.g., from 3GPP to WLAN or from WLAN to 80 WiMAX. With current Proxy Mobile IPv6 specification [RFC5213], the 81 LMA can only know the different access technologies the mobile node 82 (MN) is attached to (this information is conveyed from the mobile 83 access gateway to the local mobility anchor in the Access Technology 84 Type option). No accurate information about the mobile node status 85 (e.g., if it is in idle/power saving mode or experiencing low radio 86 quality) is available at the LMA to aid it in the decision of when 87 and how to perform flow mobility. It is therefore helpful to provide 88 the LMA with additional information from the MN, so the LMA can 89 trigger flow mobility actions with a lower risk of failure/data loss. 90 This can be done by including mobile node status information in the 91 signaling between the mobile access gateway and the local mobility 92 anchor, and by enabling the mobile access gateway to update that 93 information as needed. 95 It is also useful to support the mobile access gateway to convey 96 information to the local mobility anchor about specific capabilities 97 of attached mobile nodes. These capabilities may include, for 98 example, the support of a logical interface (to hide from the IP 99 stack the existence of multiple physical interfaces, which may be 100 simultaneously attached to different MAGs), the availability of a 101 dual IPv4/IPv6 stack at the mobile node, etc. 103 This document defines two new mobility options, the MN Capability 104 Status option and the MN Connectivity Status option for Proxy Mobile 105 IPv6 (PMIPv6), that can be used by the mobile access gateway (MAG) 106 for carrying information to the local mobility anchor about the MN 107 status with the correspondent access network and its capabilities. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. New MN status and capabilities options for PMIPv6 117 3.1. Overview 119 In some Proxy Mobile IPv6 deployments, a mobile network (e.g., the 120 one defined by the 3GPP) needs to support multiple access 121 technologies, and the local mobility anchor can be triggered to 122 decide which access technology will be used to move a particular IP 123 flow according to the operator preferences and local policy. To 124 guarantee the success of the flow mobility procedure from one access 125 technology to another, a critical piece of information to help the 126 LMA is the current mobile node status at the different access 127 networks it might be attached to. 129 The mobile access gateway is the right PMIPv6 network entity to 130 detect the mobile node status using, in addition to the mechanisms 131 defined in RFC5213 [RFC5213], any access network specific mechanism 132 that is available to detect the connectivity status of the attached 133 mobile node. 135 The MAG can provide the mobile node status information to the LMA as 136 part of the signaling exchange between MAG and LMA. Namely, the MAG 137 can periodically, or triggered by a particular event, update the MN 138 status to the LMA. How the LMA use this information is outside the 139 scope of this document. 141 3.2. Use case scenarios 143 The approach specified in this document provides additional benefits 144 to some use cases involving flow mobility among multiple access 145 technologies. These use case scenarios are illustrated next: 146 (a) The user is simultaneously attached and accessing some services 147 from both WLAN and 3GPP networks, and for some time the network 148 link connecting to the WLAN access network is going to be 149 released for some purposes, such as scheduled maintenance. 150 Triggered by that event, there are two choices the LMA can take 151 to reallocate these IP flows, either to switch the affected 152 flows to the 3GPP access, or to switch the flows to another WLAN 153 access (if available). Without updated information about the 154 status of the MN, the LMA can trigger an erroneous flow mobility 155 decision (leading to a long delay and/or data losses), for 156 example if a flow is moved to an network interface that is 157 currently in idle state or perceiving a low signal quality. 158 (b) At residential areas, during night there are more people using 159 WLAN, and less people using a cellular access, hence for the 160 VoIP service it might be better to switch some users to the 161 cellular access. On the other hand, during the day, there are 162 less people on WLAN and more people using cellular, so it might 163 be better to use the WLAN to offload the cellular network. The 164 LMA can move flows according to policies, but without accurate 165 knowledge of the MN status the flow handoff may suffer from 166 delays, data loss or other performance problems. 168 (c) The user is accessing some services from both WLAN and cellular, 169 and an FTP IP flow is initiated which may cause the bandwidth 170 resources to be insufficient. The LMA may consider changing the 171 flows for VoIP service from the WLAN to the 3GPP access 172 according to the operator polices and other factors (e.g., user 173 preferences). If the LMA only has information about which 174 networks the MN is connected, but not the real status/quality of 175 each of them, it might be that the LMA incorrectly decides to 176 move a flow (e.g., if the 3GPP radio link connecting between MN 177 and MAG is poor) resulting in then long delay or data loss. 179 3.3. Solution 181 3.3.1. MAG considerations 183 The MAG can retrieve the Mobile Node status from some other network 184 elements, such as the Mobility Management Entity (MME) in 3GPP, the 185 Paging controller in WiMAX, or the Access Point in WLAN. The MAG may 186 periodically, or triggered by a specific event, update this 187 information to the LMA, so that this information can be used as one 188 of the factors to make the decision of flow mobility by the LMA. In 189 particular, the MAG can also retrieve the radio quality of the MAG-MN 190 link from other network elements (e.g., the eNB in 3GPP), and a 191 threshold can be configured locally or downloaded (e.g., from the 192 network management system) as the operator policies. As soon as the 193 radio quality of the MAG-MN link drops below this threshold, the MAG 194 updates this event to the LMA as a part of Mobile Node status 195 information, which helps the LMA making the best decision of 196 performing flow mobility. 198 In addition, some Mobile Node capabilities information, such as 199 logical interface support or dual-stack availability, can also be 200 carried from the MAG to the LMA, helping to make a flow mobility 201 decision. How the MAG obtains this capabilities information is out 202 of scope of this document. 204 3.3.2. LMA considerations 206 The LMA receives the mobile node status information from the MAG, and 207 makes the decision of flow mobility for a specific IP flow according 208 to the operator policies and other factors (e.g., user preferences 209 and MN status). How the LMA uses this information is outside the 210 scope of this document. 212 We consider next the use case (a) of Section 3.2 as an example. If 213 the WLAN infrastructure is scheduled for maintenance, the LMA can 214 check the operator policies with other factors to decide which is the 215 best candidate access network to move the flows that were using the 216 WLAN. One example of possible prioritized list could be the 217 following: 218 1. 3GPP access with MN status set to "connected". 219 2. Another available WLAN access infrastructure. 220 3. 3GPP access with MN status set to "idle". 222 In this case, if the MN status is "idle" in the 3GPP access network, 223 the LMA will hand off the mobile node to another WLAN access without 224 trying to wake up the mobile node and re-establish the link 225 connecting the MN and the MAG. 227 Another example is the following, in which the priority of each 228 access network is set in a different way: 229 1. 3GPP access with MN status set to "connected". 230 2. 3GPP access with MN status set to "idle". 231 3. Another available WLAN access infrastructure. 233 In this case, the LMA will first try to wake up the mobile node in 234 the 3GPP access and re-establish the link connecting the MN and the 235 MAG. If this procedure can be done successfully, the LMA will not 236 attempt to hand off the mobile node to another WLAN access, but it 237 will initiate the flow mobility to the 3GPP access. 239 3.4. Mobile Node Status and Capabilities Options 241 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 242 Protocol messages. 244 3.4.1. Mobile Node Capability Status Option 246 A new option, called Mobile Node Capability Status Option, is defined 247 to be included in the PMIPv6 signaling (e.g., PBU and PBA messages) 248 exchanged between a local mobility anchor and a mobile access 249 gateway. This option is used for conveying the mobile node's 250 features support capability information. Its format is the 251 following: 253 0 1 2 3 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MN-Ca-St Type |MN-Ca-St Lngth | Reserved |L|D|M| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 1: MN Capability Status Option 261 MN-Ca-St Type 262 To be assigned by IANA. 264 MN-Ca-St Lngth 265 8-bit unsigned integer indicating the length in octets of the 266 option, excluding the type and length fields. 268 Reserved 269 This field is unused for now. The value MUST be initialized to 0 270 by the sender and MUST be ignored by the receiver. 272 L 273 1-bit unsigned integer indicating the capability of supporting the 274 logical interface feature by the mobile node. The value is set to 275 1 when logical interface is supported by the mobile node, 276 otherwise it is set to 0. 278 D 279 1-bit unsigned integer indicating the IPv6/IPv4 Dual Stack support 280 of the mobile node. The value is set to 1 when IPv6/IPv4 Dual 281 Stack is supported by the mobile node, otherwise it is set to 0. 283 M 284 1-bit unsigned integer indicating the Mobile IPv6 support of the 285 mobile node. The value is set to 1 when Mobile IPv6 stack is 286 supported by the mobile node, otherwise it is set to 0. 288 3.4.2. Mobile Node Connectivity Status Option 290 A new option, called Mobile Node Connectivity Status Option, is 291 defined to be included in the PMIPv6 signaling (e.g., PBU and PBA 292 messages) exchanged between a local mobility anchor and a mobile 293 access gateway. This option is used for conveying to the network the 294 mobile node's air link connectivity status information. Its format 295 is the following: 297 0 1 2 3 298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | MN-Co-St Type | MN-Co-St Lngth| 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Reserved | MN status |R Q| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: MN Connectivity Status Option 306 MN-Co-St Type 307 To be assigned by IANA. 309 MN-Co-St Lngth 310 8-bit unsigned integer indicating the length in octets of the 311 option, excluding the type and length fields. 313 Reserved 314 This field is unused for now. The value MUST be initialized to 0 315 by the sender and MUST be ignored by the receiver. 317 MN status 318 The status of the mobile node attached from a specific access 319 network, such as WiFi, WiMAX and 3GPP. Currently the value of the 320 MN status can be as follows: 322 1: connected, 324 2: disconnected, 326 3: idle/power saving mode, 328 4: reserved. 330 RQ 331 This field is used to indicate when the radio quality of the 332 MAG-MN link dropped below a certain threshold configured by the 333 operators. The value can be set as follow: 335 00: the radio quality of the MAG-MN link does not drop below the 336 threshold, 338 01: the radio quality of the MAG-MN link drops below the 339 threshold. 341 All other values are reserved. 343 4. Security Considerations 345 TBD 347 5. IANA Considerations 349 TBD 351 6. Contributors 353 The following people contributed to this document (in no specific 354 order): 356 Yifeng Bi 357 ZTE 358 bi.yifeng@zte.com.cn 360 Tricci So 361 ZTE USA 362 tso@zteusa.com 364 7. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 370 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 372 Authors' Addresses 374 Yangwei Tu 375 ZTE 376 Nanjing 377 Nanjing 378 China 380 Email: tu.yangwei@zte.com.cn 382 Chunhui Zhu 383 ZTE 384 Nanjing 385 Nanjing 386 China 388 Email: zhu.chunhui@zte.com.cn 389 Carlos J. Bernardos 390 Universidad Carlos III de Madrid 391 Av. Universidad, 30 392 Leganes, Madrid 28911 393 Spain 395 Phone: +34 91624 6236 396 Email: cjbc@it.uc3m.es 397 URI: http://www.it.uc3m.es/cjbc/ 399 Carl Williams 400 MCSR Labs 401 USA 403 Phone: 404 Email: carlw@mcsr-labs.org 405 URI: