idnits 2.17.1 draft-antoine-mip4-lowlatency-handoff-triggers-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '... The MN MAY perform regular scans to...' RFC 2119 keyword, line 256: '...etworks. The MN MAY report regularly ...' RFC 2119 keyword, line 306: '...4. The Handoff Layer Triggers MUST be...' RFC 2119 keyword, line 308: '... delivery of the Triggers MUST also be...' RFC 2119 keyword, line 309: '... secured and MUST not introduce any ...' (1 more instance...) 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 'MUST not' in this paragraph: This document introduces a framework describing the use of triggers coming from layers higher than the link layer to initiate the Low Latency Handoff in Mobile IPv4. The Handoff Layer Triggers MUST be secured to provide reliable information to the Low Latency for MIPv4. The mechanism causing the delivery of the Triggers MUST also be secured and MUST not introduce any vulnerability to the low Latency handoff for MIPv4. Securing the delivery of Higher Layer Triggers prevents an attacker in the network to send bogus messages causing the MN undesired handoffs. A Security Association SHOULD exist between the Network Node sending the Command and the recipient (the FA or the MN) of the Higher Layer Trigger. The establishment of these Security Associations are 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 (December 15, 2006) is 6334 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'LOWLATMIP4' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stephane Antoine 3 Internet-Draft France Telecom 4 Intended status: Standards Track December 15, 2006 5 Expires: June 18, 2007 7 Using Higher Layer Triggers for Low Latency Handoffs in MIPv4 8 draft-antoine-mip4-lowlatency-handoff-triggers-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 18, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2006). 41 Abstract 43 This document introduces the use of triggers coming from layers 44 higher than the link layer to initiate the Low Latency Handoff in 45 Mobile IPv4 (MIPv4) . The Low Latency Handoff for MIPv4 assumes 46 availability of Layer 2 (L2) triggers that contain Layer 3 (L3) 47 information for the Mobile Node (MN) to handoff. However, the low 48 latency draft does not describe the method by which the L2 trigger is 49 produced neither does it explicitly describe by what mechanism the L3 50 information present in the L2 trigger is acquired. The Low Latency 51 Handoff for MIPv4 relies on availability of the L2 trigger. However 52 relying only on the link information to initiate a handoff does not 53 generally gather enough information for the MN to handoff to the most 54 suitable available access network. Information from higher layers 55 such as Higher Layer Triggers can be used to command a MN to quickly 56 move from one access to another one. Using Higher Layer Triggers to 57 initiate the handoff enables the implementation of policy based 58 handoff to garantee load balancing of the wireless networks and 59 Quality of Services to the end users. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Inadequacies of relying on Layer 2 triggers alone for Low 67 Latency Handoffs . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Using Higher Layer Triggers to initiate the Low Latency 72 Handoff in MIPv4 . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1. Pre-Registration handoff . . . . . . . . . . . . . . . . . 6 74 6.1.1. Network initiated: . . . . . . . . . . . . . . . . . . 6 75 6.1.2. Mobile initiated: . . . . . . . . . . . . . . . . . . . 7 76 6.2. Post-Registration Handoff . . . . . . . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 78 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 80 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 Intellectual Property and Copyright Statements . . . . . . . . . . 9 84 1. Introduction 86 Low Latency Handoffs in MIPv4 [LOWLATMIP4] introduces a method that 87 achieves low latency for Mobile IPv4 in support of real-time 88 services. The two methods presented in to achieve low latency are 89 based on reception of various Layer 2 triggers on the MN and the 90 Foreign Agent (FA). The Layer 2 trigger introduced in [LOWLATMIP4] 91 informs L3 of a particular event before L2 handoff actually takes 92 place. The Low Latency Handoff in MIPv4 is only initiated just 93 before the L2 handoff takes place as indicated by the L2 triggers. 94 L2 trigger usually occurs when the signal strength reaches a critical 95 level that requires a handoff to take place. However, handoff may be 96 needed upon reception of parameters other than the ones related to 97 the relative signal strength received. L2 trigger indicating that 98 the MN has just entered the coverage area of a WLAN network is not 99 enough indication to handoff to the most suitable network at the most 100 suitable time. A Mobile Node which is simultaneously connected to 101 several networks, does not necessarily have enough information to 102 initiate the handoff from its default network to a most prefered 103 access network. Due to lack of additional information, the MN may 104 stay connected to an acces network that may turn out to be more 105 costly for the MN than another available one. The lack of 106 information, can cause the MN to stay connected to one access network 107 that does not offer the MN the best quality of service. This lack of 108 informmation, prevents the management of load sharing mechanisms on 109 different access networks to suit several subscribers having 110 different profiles. Higher Layer Triggers or Handoff Commands in 111 response to a policy decision can trigger the MN handoff to the most 112 preferable available network at the most suitable time. The Higher 113 Layer Trigger or Handoff Command comes from a Network Node or from 114 the MN itself. Higher Layer Trigger or a Handoff Command may trigger 115 a MIPv4 handoff even without indication of a pending L2 handoff. 116 Implementing the Higher Layer Handoff Trigger is compatible with 117 [LOWLATMIP4]. One can design a system in which a Higher Layer 118 Trigger or a Handoff Command is used to generate a L2 trigger that 119 subsequently initiates the Low Latency Handoff in MIPv4. In case 120 urgent handoff is needed as indicated by a pending L2 handoff, the 121 low latency takes place even if no Higher Layer Trigger has been 122 received. 124 2. Terminology 126 This section introduces the Handoff Command and the Higher Layer 127 Handoff Trigger. 129 Handoff Command - It is a message sent by an entity in the network to 130 instruct the MN to initiate a handoff. 132 Higher Layer Handoff Trigger - It is a trigger that comes from a 133 layer higher than Layer 2. The Higher Layer Handoff Trigger can come 134 from Layer 3 or the application layer. The Higher Layer Handoff 135 Trigger may have been generated locally by the entity receiving the 136 trigger. It may also have been generated by a Network Node other 137 than the node receiving the trigger. The Higher Layer Handoff 138 Trigger may be received as an IP message initiated from the network 139 (Handoff Command). The entity receiving the Higher Layer Handoff 140 Trigger is either the MN or the FA or another entity in the network 141 such as the Access Router (AR) that could subsequently interacts 142 directly with the MN at layer 2. The Higher Layer Handoff Trigger 143 can generate the Layer 2 trigger. 145 3. Motivation 147 The Higher Layer Trigger or Handoff Command coming from the Network 148 or the MN serves to implement policy based network controlled 149 handoffs. A network operator can command a set of users to handoff 150 to different networks to provide load sharing on its different access 151 networks. The network operator can selectively command Mobile Nodes 152 to handoff to different access networks to provide a level of Quality 153 of Service to different users according to their user profiles. The 154 Higher Layer Trigger that comes from the MN application can initiate 155 handoff when the quality of the application becomes poor. For a 156 Voice over IP application for example, the perceived quality of the 157 voice can serve as a Trigger to the MN to initiate a handoff to a 158 better network. Figure 1 and 2 illustrate the initiation of the Low 159 Latency Handoff by a Higher Layer Trigger from the network or the MN 160 itself. 162 MN oFA/nFA Network Node/entity HA/GFA 163 | | | | 164 | |Higher Layer Trigger/Command | | 165 | |<------------------------------| | 166 --|---------------------------------------------------------------------- 167 | | | | | 168 | | |Low Latency in MIPv4 | | 169 | | | | | 170 ------------------------------------------------------------------------- 172 Figure 1: Network initiated, source/target triggered. 174 MN oFA nFA Network Node/entity HA/GFA 175 | | | | | 176 | |Higher Layer Trigger/Command | | 177 |<--------------------------------------------| | 178 | or | | | | 179 |Higher Layer Trigger | | | 180 |<~~~~~~ | | | | 181 --|--------------------------------------------------------------------- 182 | | | | | | | 183 | | |Low Latency in| MIPv4 | | | 184 | | | | | | | 185 ------------------------------------------------------------------------ 187 Figure 2: Mobile initiated. 189 4. Inadequacies of relying on Layer 2 triggers alone for Low Latency 190 Handoffs 192 The Low Latency Handoff in MIPv4 relies on L2 triggers as an 193 indication of a pending L2 handoff to initiate the early MIPv4 194 registration before the L2 handoff actually takes place. L2 triggers 195 although not exactly define in [LOWLATMIP4] correspondent to events 196 such as perception of signal noise ratio at the MN or Link Up, Link 197 Down, reception of an agent solicitation... Reception of L2 triggers 198 alone is not always sufficient information to rely upon for the 199 initiation of the Layer 3 handoff. Handoff Commands can be used to 200 force a handoff even if the signal quality is very good on all of the 201 MN's interfaces. In such scenarios, the handoff triggers coming from 202 a higher layer protocol can be used to initiate the L3 handoff 203 presented in [LOWLATMIP4]. 205 5. Scenarios 207 A few scenarios can illustrate the application of handoff triggers 208 from higher layers to initiate the Low Latency Handoff in MIPv4. 210 5.1. Scenario 1 212 The handoff trigger comes locally from a Layer 3 or above of the MN 213 due to variations or degradation in the application for example. 214 Application degradation may be due to increased load in the MN's 215 serving network. The MN can interpret such degradation as a hint for 216 an eventual need to handoff to a different access network. The MN 217 may generate a scan to obtain the identifier of other networks 218 available (BSSID identifier for example of the Access Point that is a 219 potential handoff target). The MN resumes the actions with a Proxy 220 Router Solicitation (PrRtSol) as in the Pre-Registration Low Latency 221 Handoff in MIPv4 case. Note that scanning of potential new access 222 networks may not result in finding a target access network to handoff 223 to as the MN may not be in an overlapping networks coverage area. In 224 that case, the hint received (from L3 or the application) would have 225 not triggered the handoff. 227 5.2. Scenario 2 229 A Mobile Node is using a WLAN connection and is simultaneously in the 230 coverage area of WLAN and 3G with a good signal reception in WLAN. 231 The Link Up on the 3G interface is not necessarily a trigger 232 providing sufficient information to initiate the Pre-registration 233 with L3 handoff towards 3G. However a network policy may require the 234 MN to execute a handoff due to various network conditions and 235 policies pre-established. To achieve policy based network control 236 handoff, several techniques can be designed: The MN can collect 237 information and send it to the network which ultimately takes the 238 decision to instruct the MN or the FA (by a Handoff Command) to 239 handoff to a preferred type of available network. The criterion 240 initiating the handoff is not restricted to the signal noise ratio 241 perceived at lower layers. Instead the set of criteria can include 242 other parameters such as the link characteristics of available 243 networks, the load on the MN serving network and neighbouring access 244 networks, the level of quality of service perceived...(Such a 245 scenario is the most appealing for network operators as it enables 246 the network to initiate and assist the handoff). One may design a 247 system in which Higher Layer Triggers are used to initiate the Low 248 Latency Handoff in MIP. 250 6. Using Higher Layer Triggers to initiate the Low Latency Handoff in 251 MIPv4 253 6.1. Pre-Registration handoff 255 The MN MAY perform regular scans to obtain information about its 256 available networks. The MN MAY report regularly to a network entity 257 such information. The network entity might then take the decision to 258 instruct the MN to handoff. The handoff trigger from higher layer 259 protocol could be received at the FA (Network initiated) or at the MN 260 (Mobile initiated). 262 6.1.1. Network initiated: 264 The MN reports to a central entity (Policy Decision Point) the IP 265 addresses of its available FAs obtained through scanning. Upon 266 decision to instruct the MN to handoff to a particular access 267 network, the network entity will send a Handoff Command to a FA to 268 initiate handoff to the target access network. The termination of 269 the Handoff Command can be the oFA (for the source trigger handoff) 270 or the nFA (for the target trigger handoff). The Handoff Command 271 could contain the IP address of the nFA it is instructed the MN to 272 move to. The Handoff Command in turn generates the Layer 2 source or 273 target trigger in use in the Low Latency Handoff in MIPv4. The 274 Handoff Command when implemented provides a means to pass the IP 275 address of the new FA (nFA) or the old FA (oFA) for use in the L2 276 trigger. A method by which the Handoff Command from layer 3 277 generates a Layer 2 trigger at the FA is not described in this 278 document. 280 6.1.2. Mobile initiated: 282 The Mobile Initiated Pre-registration handoff can result from a 283 Higher Layer Handoff Trigger that originated locally on the MN or 284 from a Handoff Command sent from another node in the network. The 285 Handoff Command may contain limited information such as the type of 286 the preferred network to move to (i.e 3G or WLAN or WiMAX, the load 287 on each network, the QoS ...). When the MN receives an instruction 288 to handoff it can then issue a new scan to obtain the BSSID 289 identifier of the Access Point that is a potential handoff target. 290 The reception of the BSSID of the target AP can be the layer 2 291 trigger that then initiates the Mobile Initiated Pre-registration 292 Handoff as in [LOWLATMIP4]. 294 6.2. Post-Registration Handoff 296 The application of Handoff Command towards the Post registration 297 handoff is restricted. As the Post Registration Handoff effectively 298 starts with the loss of L2 connectivity with the oFA L2-Link Down 299 (L2-LD) it makes it more difficult to initiate it with Higher Layer 300 Triggers. 302 7. Security Considerations 304 This document introduces a framework describing the use of triggers 305 coming from layers higher than the link layer to initiate the Low 306 Latency Handoff in Mobile IPv4. The Handoff Layer Triggers MUST be 307 secured to provide reliable information to the Low Latency for MIPv4. 308 The mechanism causing the delivery of the Triggers MUST also be 309 secured and MUST not introduce any vulnerability to the low Latency 310 handoff for MIPv4. Securing the delivery of Higher Layer Triggers 311 prevents an attacker in the network to send bogus messages causing 312 the MN undesired handoffs. A Security Association SHOULD exist 313 between the Network Node sending the Command and the recipient (the 314 FA or the MN) of the Higher Layer Trigger. The establishment of 315 these Security Associations are out of the scope of this document. 317 8. Conclusion 319 This document introduces the use of triggers from layers higher than 320 layer 2 to initiate the Low Latency Handoff in MIPv4. The trigger 321 issued from the application or the network layer may in turn generate 322 the Layer 2 trigger. Layer 2 trigger is not necessarily received as 323 an indication of a stronger or lower signal received at the MN from 324 the access network. The Higher Layer Trigger coming from the network 325 is a Handoff Command which makes it possible to implement policy 326 decision based handoff. According to a policy decision the system 327 may command the MN to handoff to the most preferable Access Network. 328 The policy based handoff decision may be taken locally on the MN or 329 may be implemented on a different node in the network. 331 9. Acknowledgements 333 The author wish to thank Karim El Malki for reviewing this document 334 and for providing useful comments. 336 10. Normative References 338 [LOWLATMIP4] 339 K. El Malki, Editor., "Low Latency Handoffs in Mobile 340 IPv4", October 2005. 342 Author's Address 344 Stephane Antoine 345 France Telecom 346 Chiswick Park 347 London, Chiswick W4 5XS 348 United Kingdom 350 Phone: + 44 (0)208 849 5821 351 Fax: +44 (0)208 849 0991 352 Email: stephane.antoine@orange-ft.com 354 Full Copyright Statement 356 Copyright (C) The IETF Trust (2006). 358 This document is subject to the rights, licenses and restrictions 359 contained in BCP 78, and except as set forth therein, the authors 360 retain all their rights. 362 This document and the information contained herein are provided on an 363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 365 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 366 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 367 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 Intellectual Property 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Acknowledgment 396 Funding for the RFC Editor function is provided by the IETF 397 Administrative Support Activity (IASA).