idnits 2.17.1 draft-daniel-mip-link-characteristic-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In the case that the mobile node has multiple correspondent nodes, in order for the model defined in this document to work well, the mobile node SHOULD have a certain capacity (i.e. bandwidth as currently defined) assignment algorithm to determine the share for each of them, and specify it (the share) in the Link Characteristic Information Option in the corresponding Binding Update message. The total capacity (i.e. bandwidth as currently defined) specified in all concurrent Link Characteristic Information Options SHOULD not exceed the maximum capacity available to the mobile node on the current access link. The capacity assignment algorithm is out of the scope of this document. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 28, 2007) is 6298 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 428, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '2') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '4') (Obsoleted by RFC 4234) == Outdated reference: A later version (-02) exists of draft-sgundave-mip6-proxymip6-01 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-ha-switch-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Soohong Daniel Park 3 Internet-Draft M. Lee 4 Intended status: Best Current Samsung Electronics 5 Practice J. Korhonen 6 Expires: August 1, 2007 TeliaSonera 7 J. Zhang 8 Cambridge Silicon Radio 9 January 28, 2007 11 Link Characteristics Information for Mobile IP 12 draft-daniel-mip-link-characteristic-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 1, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document introduces a model for link characteristic information 46 delivery from the mobile node to the home agent and correspondent 47 node(s). This model allows the home agent and correspondent node(s) 48 to know the characteristics of the link the mobile node is currently 49 attached to. Based on this information, the home agent and 50 correspondent node(s) may shape ongoing traffic according to the 51 current available link capacity (e.g. bandwidth) to the mobile node. 52 This model can be applicable for Mobile IPv4 as well as Mobile IPv6. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Link Characteristic Information Option for Mobile IPv6 . . . . 4 59 4. Operational Considerations . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. Appendix A (Informative) - Option Usage Examples . . . . . . . 8 64 8.1. Vertical Handover from a GPRS Link to an 802.11b Link . . 8 65 8.2. Vertical Handover from an 802.11b Link to a GPRS Link . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 12 72 1. Introduction 74 Mobile IP [2], [3] allows a mobile node to maintain its existing 75 connections while changing its access link. This is achieved through 76 the mechnism of mobility binding management at the home agent and 77 optionally correspondent node(s) with the assistance of the mobile 78 node's notifications of its current location. 80 Recently more and more mobile nodes are equipped with multiple 81 interfaces for different L2 technologies. These mobile nodes may be 82 reachable through different links at the same time or use each 83 interface alternately depending on the network environment. In the 84 latter case, transitions between heterogeneous links (vertical 85 handovers) occur. Mobile IP, however, does not provide a mechanism 86 to indicate which type of link the mobile node is attached to. 87 Therefore, sudden changes of access link characteristics caused by 88 vertical handovers are usually not quickly observed by higher layer 89 applications until a certain mechanism (e.g. congestion control or 90 error recovery mechanism) is invoked some time later when it senses a 91 misuse of the network capacity. This can cause undesirable 92 disruptions or performance degradation to the ongoing connections. 93 For example, when the mobile node performs a handover from an IEEE 94 802.11b WLAN link (high bandwidth link) to a CDMA cellular link (low 95 bandwidth link), the home agent and correspondent nodes may still 96 send their traffic to the mobile node as if the 802.11b bandwidth is 97 still available. Thus, the ratio of packet loss will eventually 98 increase. 100 In some cases, the mobile node's available bandwidth may also vary 101 considerably on handovers between the same type of links (horizontal 102 handovers) due to the different traffic loads on the old and the new 103 link. Moreover, even the mobile node stays on the same link, the 104 available bandwidth may change significantly due to the variations of 105 the traffic load on current link. Both of these situations may lead 106 to similar adverse effects as vertical handovers. 108 This document introduces a new model for link characteristic 109 information delivery from the mobile node to the home agent and 110 correspondent node(s). The purpose of this model is to let the home 111 agent and correspondent node(s) properly shape their traffic to the 112 mobile node according to the mobile node's current access link 113 characteristics. This model can be applicable for both Mobile IPv6 114 [3] and Mobile IPv4 [2]. However, to illustrate this model 115 concisely, only Mobile IPv6 is considered in this document. A new 116 mobility option called Link Characteristic Information Option is 117 defined to carry link characteristics (e.g., current link bandwidth, 118 link type, and other relevant information to be extended) to the home 119 agent and correspondent node(s). This option SHOULD be included in 120 the Binding Update message on vertical handovers or when the mobile 121 node senses a significant link characteristic change. The method 122 used by the mobile node to obtain the current link characteristic 123 information is implementation dependent (e.g. enhancing the wireless 124 access device driver functions or using the 802.21 utility), and is 125 therefore out of the scope of this document. For Mobile IPv4, the 126 option can be defined following the Type-Length-Value extension 127 format, and can be carried by the Registration Request message. 129 2. Requirements 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [1]. 135 3. Link Characteristic Information Option for Mobile IPv6 137 The Link Characteristic Information Option is a new mobility option 138 that MAY be carried in the Mobile IPv6 Binding Update message. 139 Various link types and characteristic information (e.g. bandwidth) 140 can be delivered to the home agent and correspondent node(s) from the 141 mobile node. The subtype field in the option defines the specific 142 link type. Other link information such as the current estimated 143 available bandwidth is encoded in the Link Characteristic Information 144 field. 146 This option SHOULD be carried in the Binding Update message on 147 vertical handovers or when the mobile node senses a significant link 148 characteristic change by some means out of the scope of this 149 document. The trigger of sending the option by the mobile node is an 150 implementation issue. For example, a bandwidth change threshold 151 could be defined. Only when the available bandwidth change exceeds 152 the threshold, should the mobile node initiate a Link Characteristic 153 Information option to be delivered. Further study is required to 154 determine the optimal threshold for different link types and ongoing 155 applications. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Option Type | Option Length | Subtype | Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Link Characteristic Information... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Link Characteristic Information Option for Mobile IPv6 166 o Option Type: 8-bit identifier of the type of the mobility option. 167 To be defined by IANA. 169 o Option Length: 8-bit unsigned integer, representing the length of 170 the Link Characteristic Information Option in octets, excluding 171 the Option Type and Option Length fields. 173 o Subtype: 8-bit identifier (as shown in the following table), 174 indicating the type of the link the mobile node currently 175 accesses. 177 Subtype Link Type 178 ---------------------------------------------- 179 0 LAN (802.3) 180 1 WLAN (802.11b) 181 2 WLAN (802.11a) 182 3 WLAN (802.11g) 183 4 WLAN (802.11n) 184 5-15 Reserved for (W)LAN Extensions 185 16 CDMA 186 17 GPRS 187 18 UMTS 188 19-31 Reserved for Cellular Networks 189 32-47 802.15 Family Networks 190 48-63 802.16 Family Networks 191 64 Bluetooth 192 65 Virtual (the physical link type is irrelevant) 193 66-255 Reserved 194 ---------------------------------------------- 196 o Reserved: MUST be set to zero when sending this option and ignored 197 when receiving this option. 199 o Link Characteristic Information: A variable length field that 200 contains the current available bandwidth information and possibly 201 other to-be-defined link information for a specific link type as 202 specified in the subtype field. The ABNF below describes how the 203 Link Characteristic Information field MUST be constructed: 205 link-info = link-info-data 206 link-info =/ link-info-data "," 1*info-label 207 link-info =/ 1*info-label "," link-info-data 208 link-info-data = "bw=" 1*DIGIT 209 bandwidth = "kbps" / "Mbps" / "kB" / "Gbps" 210 info-label = ALPHA / DIGIT 212 The "ALPHA" and "DIGIT" rules are defined in [4]. 214 This option does not have any alignment requirements. 216 4. Operational Considerations 218 The binding cache is a table maintained by the home agent and each 219 correspondent node that contains the current mobility bindings for 220 mobile nodes. To store link characteristic information at the home 221 agent and correspondent node(s), one entry MUST be contained in the 222 binding cache for each mobility binding. Similarly the mobile node 223 MUST have one entry in every item in its binding update list to store 224 the link characteristic information the mobile node has sent to other 225 network nodes (i.e. home again, correspondent nodes). 227 The home agent and correspondent node(s) MUST recognize the Link 228 Characteristic Information Option in the Binding Update message in 229 order for them to properly shape their traffic to the mobile node or 230 dynamically adjust their services. Otherwise, this option is 231 silently discarded by the home agent and correspondent node(s). 232 Moreover, this option MUST be silently discarded if the Binding 233 Update message fails to be authenticated. 235 On receipt of a Binding Update message with the Link Characteristic 236 Information Option, correspondent node(s) SHOULD control their 237 traffic amount or pattern sent to the mobile node according to the 238 link characteristics (i.e. available bandwidth as currently defined) 239 specified in the option. To perform traffic controls, correspondent 240 node(s) SHOULD implement an interface for communications between IP 241 layer and upper layer mechanisms (e.g. TCP, media application codec, 242 etc.). However, the specific control method is out of the scope of 243 this document. 245 On receipt of a Binding Update message with the Link Characteristic 246 Information Option, the home agent SHOULD control its traffic amount 247 or pattern sent to the mobile node according to the link 248 characteristics. This is helpful when the mobile node is 249 communicating with any of its correspondent node(s) in non-route- 250 optimization mode (i.e. the bi-directional tunneling mode, in which 251 case the correspondent node does not receive Binding Update messages 252 and traffic go through the home agent). However, the specific 253 control method is out of the scope of this document. 255 For example, an ongoing connection is using a bandwidth of 10Mbps, 256 while the available bandwidth specified in the Link Characteristic 257 Information Option is 1Mbps. The home agent or correspondent node 258 receiving this option SHOULD reduce its traffic forwarding rate. 260 Link characteristic information SHOULD be provided by the mobile node 261 in the Binding Update message on vertical handovers or when the 262 mobile node senses a significant link characteristic change by some 263 means out of the scope of this document, in order to guide the home 264 agent and correspondent node(s) to shape their traffic. The trigger 265 of sending the option by the mobile node is an implementation issue. 267 In the case that the mobile node has multiple correspondent nodes, in 268 order for the model defined in this document to work well, the mobile 269 node SHOULD have a certain capacity (i.e. bandwidth as currently 270 defined) assignment algorithm to determine the share for each of 271 them, and specify it (the share) in the Link Characteristic 272 Information Option in the corresponding Binding Update message. The 273 total capacity (i.e. bandwidth as currently defined) specified in all 274 concurrent Link Characteristic Information Options SHOULD not exceed 275 the maximum capacity available to the mobile node on the current 276 access link. The capacity assignment algorithm is out of the scope 277 of this document. 279 This document only defines the available bandwidth as link 280 characteristic information. However, there is no restriction to add 281 other available link information in the Link Characteristic 282 Information Option if required. Furthermore, the Link Characteristic 283 Information Option as such is also applicable when Mobile IPv6 is 284 used in proxy mode [5]. In this particular case the source of the 285 information is the local proxy node representing the mobile node. 286 The use case could be the access network signaling the allowed 287 capacity to the mobile node to the correspondent nodes along with the 288 Mobile IP signaling. 290 5. Security Considerations 292 Potentially, the model proposed in this document may be misused by an 293 attacker to indicate fabricated available bandwidth information to 294 the home agent or correspondent node(s). However, the Link 295 Characteristic Information Option is carried by the Binding Update 296 message, which are always supposed to be protected by IPsec [6] or 297 the binding management key (Kbm) [3] established beforehand. 298 Attackers who have the capability of fabricating a valid Binding 299 Update message are able to launch more serious attacks than those 300 potentially caused by this model. Therefore, it is believed that the 301 use of the Link Characteristic Information Option does not bring new 302 security vulnerabilities to Mobile IP. 304 6. IANA Considerations 306 A new Mobile IPv6 Mobility Option type is required for the following 307 new mobility option described in section Section 3: 309 Link Characteristic Information Option is set to TBD 311 Also, IANA needs to allocate a new Link Characteristic Information 312 Option (TBD) namespace for the subtype field described in section 313 Section 3: 315 Subtype Link Type 316 ---------------------------------------------- 317 0 LAN (802.3) 318 1 WLAN (802.11b) 319 2 WLAN (802.11a) 320 3 WLAN (802.11g) 321 4 WLAN (802.11n) 322 5-15 Reserved for (W)LAN Extensions 323 16 CDMA 324 17 GPRS 325 18 UMTS 326 19-31 Reserved for Cellular Networks 327 32-47 802.15 Family Networks 328 48-63 802.16 Family Networks 329 64 Bluetooth 330 65 Virtual 331 66-255 Reserved 333 7. Acknowledgements 335 The authors would like to acknowledge Rajeev Koodli, Bongkyo Moon, 336 Pyungsoo Kim and Junghoon Jee for their useful comments. 338 8. Appendix A (Informative) - Option Usage Examples 340 8.1. Vertical Handover from a GPRS Link to an 802.11b Link 342 The example below shows the link characteristic information 343 notification when the mobile node performs a vertical handover from a 344 46kbps GPRS link to an 11Mbps 802.11b link. During the Binding 345 Update procedure the mobile node deliveries its new access link 346 bandwidth to the home agent (in bi-directional tunneling mode) or the 347 correspondent node (in route optimization mode). After receiving the 348 Binding Update message, the home agent or the correspondent node 349 adjusts its traffic sending rate towards the mobile node to take 350 advantage of the reported increased bandwidth. 352 mobile node home agent / correspondent node 353 | | 354 attach to GPRS link | 355 | data (with GPRS bandwidth) | 356 |<----------------------------------------------| 357 handover to 802.11b link | 358 | Binding Update | 359 |---------------------------------------------->| 360 | (subtype: 802.11b; info: bandwidth=11Mbps) | 361 | | 362 | Binding Acknowledgement (if sent) | 363 |<----------------------------------------------| 364 | adjust traffic sending rate 365 | data (with 802.11b bandwidth) | 366 |<----------------------------------------------| 367 | | 369 Example 1 371 8.2. Vertical Handover from an 802.11b Link to a GPRS Link 373 The following example shows the link characteristic information 374 notification when the mobile node performs a vertical handover from 375 an 11Mbps 802.11b link to a 46kbps GPRS link. During the Binding 376 Update procedure the mobile node delieveries its new access link 377 bandwidth to the home agent (in bi-directional tunneling mode) or the 378 correspondent node (in route optimization mode). After receiving the 379 Binding Update message the home agent or the correspondent node 380 reduces its traffic sending rate towards the mobile node to match the 381 reported decreased bandwidth. 383 mobile node home agent / correspondent node 384 | | 385 attach to 802.11b link | 386 | data (with 802.11b bandwidth) | 387 |<----------------------------------------------| 388 handover to GPRS link | 389 | Binding Update | 390 |---------------------------------------------->| 391 | (subtype: GPRS; info: bandwidth=46kbps) | 392 | | 393 | Binding Acknowledgement (if sent) | 394 |<----------------------------------------------| 395 | adjust traffic sending rate 396 | data (with GPRS bandwidth) | 397 |<----------------------------------------------| 398 | | 400 Example 2 402 9. References 404 9.1. Normative References 406 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 407 Levels", BCP 14, RFC 2119, March 1997. 409 9.2. Informative References 411 [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 412 August 2002. 414 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 415 IPv6", RFC 3775, June 2004. 417 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 418 Specifications: ABNF", RFC 2234, November 1997. 420 [5] Gundavelli, S., "Proxy Mobile IPv6", 421 draft-sgundave-mip6-proxymip6-01 (work in progress), 422 January 2007. 424 [6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 425 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 426 Agents", RFC 3776, June 2004. 428 [7] Haley, B., "Mobility Header Home Agent Switch Message", 429 draft-ietf-mip6-ha-switch-02 (work in progress), December 2006. 431 Authors' Addresses 433 Soohong Daniel Park 434 Mobile Platform Laboratory, SAMSUNG Electronics. 435 416 Maetan-3dong, Yeongtong-gu 436 Suwon, Gyeonggi-do 443-742 437 KOREA 439 Phone: +82 31 200 4508 440 Email: soohong.park@samsung.com 442 Minho Lee 443 Mobile Platform Laboratory, SAMSUNG Electronics. 444 416 Maetan-3dong, Yeongtong-gu 445 Suwon, Gyeonggi-do 443-742 446 KOREA 448 Phone: +82 31 200 3697 449 Email: minho03.lee@samsung.com 451 Jouni Korhonen 452 TeliaSonera Corporation. 453 P.O.Box 970 454 FIN-00051 Sonera 455 FINLAND 457 Phone: +358 40 534 4455 458 Email: jouni.korhonen@teliasonera.com 460 Ji Zhang 461 Fix Mobile Convergence Solutions, Cambridge Silicon Radio Ltd. 462 Cambridge Business Park, Cowley Road 463 Cambridge CB4 0WZ 464 United Kingdom 466 Phone: +44 1223 692906 467 Email: ji.zhang@csr.com 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2007). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Acknowledgment 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).