idnits 2.17.1 draft-irtf-mobopts-l2-abstractions-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1086. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 21, 2006) is 6427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '5' is mentioned on line 449, but not defined == Missing Reference: '6' is mentioned on line 456, but not defined == Missing Reference: '7' is mentioned on line 470, but not defined == Missing Reference: '8' is mentioned on line 476, but not defined == Missing Reference: '9' is mentioned on line 483, but not defined == Missing Reference: '10' is mentioned on line 488, but not defined == Missing Reference: '11' is mentioned on line 498, but not defined ** Obsolete normative reference: RFC 4068 (ref. '1') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 4140 (ref. '2') (Obsoleted by RFC 5380) == Outdated reference: A later version (-10) exists of draft-iab-link-indications-05 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF MobOpts RG F. Teraoka 3 Internet-Draft K. Gogo 4 Intended status: Informational K. Mitsuya 5 Expires: March 25, 2007 R. Shibui 6 K. Mitani 7 KEIO University 8 September 21, 2006 10 Unified L2 Abstractions for L3-Driven Fast Handover 11 draft-irtf-mobopts-l2-abstractions-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 25, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This draft proposes unified L2 abstractions for L3-driven fast 45 handovers. For efficient network communication, it is vital for a 46 protocol layer to know or utilize other layer's information such as a 47 form of L2 triggers. However, each protocol layer is basically 48 designed independently. Since each protocol layer is also 49 implemented independently in current operating systems, it is very 50 hard to exchange control information between protocol layers. To 51 solve the problem, this draft defines nine kinds of L2 abstractions 52 in the form of "primitive" to achieve fast handovers in the network 53 layer. This mechanism is called "L3-driven fast handovers" because 54 the network layer initiates L2 and L3 handovers by using the 55 "primitives". 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 7 65 4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 9 66 4.1. L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 9 67 4.2. L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 9 68 4.3. L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 9 69 4.4. L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 9 70 4.5. L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 10 71 4.6. L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 10 72 4.7. L2-LinkGoingDown (Type 2) . . . . . . . . . . . . . . . . 10 73 4.8. L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 10 74 4.9. L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 10 76 5. Definitions of Static Parameters . . . . . . . . . . . . . . . 11 77 5.1. Network Interface ID . . . . . . . . . . . . . . . . . . . 11 79 6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 12 80 6.1. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.2. Condition . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.3. Peer List . . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.4. Enable/Disable . . . . . . . . . . . . . . . . . . . . . . 12 84 6.5. Ack/Error . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7. Architectural Considerations . . . . . . . . . . . . . . . . . 13 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 Appendix A. Example Scenario . . . . . . . . . . . . . . . . . . 19 94 Appendix B. Example Operation for FMIPv6 . . . . . . . . . . . . 21 95 B.1. Example Operation-1 for FMIPv6 . . . . . . . . . . . . . . 21 96 B.2. Example Operation-2 for FMIPv6 . . . . . . . . . . . . . . 23 97 B.3. Experiment . . . . . . . . . . . . . . . . . . . . . . . . 25 99 Appendix C. Example Mapping of Primitives and IEEE802.11 . . . . 27 100 C.1. L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 27 101 C.2. L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 27 102 C.3. L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 27 103 C.4. L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 28 104 C.5. L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 28 105 C.6. L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 28 106 C.7. L2-LinkGoingDown . . . . . . . . . . . . . . . . . . . . . 28 107 C.8. L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 28 108 C.9. L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 29 110 Appendix D. Implementation and Evaluation of the Proposed 111 Model . . . . . . . . . . . . . . . . . . . . . . . . 30 113 Appendix E. Changes from 01 . . . . . . . . . . . . . . . . . . . 32 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 116 Intellectual Property and Copyright Statements . . . . . . . . . . 35 118 1. Introduction 120 In recent years, the execution environment around computers is not 121 static and changes dynamically. Especially, when a mobile node moves 122 to a different network, its communication environment considerably 123 changes. For example, in the case of wireless communication, 124 parameters such as radio strength largely changes depending on time 125 or site. 127 For efficient network communication, it is vital for a protocol layer 128 to know or utilize other layer's control information. There are 129 several proposals for seamless handovers in IPv6 network such as Fast 130 Handovers for Mobile IPv6 (FMIPv6) [1] and Hierarchical Mobile IPv6 131 (HMIPv6) [2]. In FMIPv6, the network layer must know the indication 132 of a handover from the link layer in advance to achieve seamless 133 handovers. However, control information exchange between protocol 134 layers is not allowed because each protocol layer is designed 135 independently. 137 To solve the problem, this draft defines nine kinds of L2 138 abstractions in the form of "primitive" to achieve fast handovers in 139 the network layer. This mechanism is called "L3-driven fast 140 handovers" because the network layer initiates L2 and L3 handovers by 141 using the "primitives". 143 2. Terminology 145 This document uses the following terms. 147 L3-Driven Fast Handover 149 The handover mechanism which is initiated by the network layer on 150 a mobile node. Since this mechanism allows the handover 151 preparation in L3 before the start of an L2 handover on the mobile 152 node, it can reduce packet loss during a handover. The L3-driven 153 fast handover mechanism requires L2 information as a trigger of a 154 handover procedure. 156 Peer 158 The attachment point of a mobile node. (e.g., An access point in 159 IEEE 802.11 networks.) 161 Primitive 163 A unit of information which is sent from one layer to another. 164 There are four classes of primitives: Request, Confirm, Indication 165 and Response. 167 3. Primitives for L2 Abstractions 169 Each layer offers its services in the form of primitives. There are 170 four classes of primitives as shown in Figure 1: Request, Confirm, 171 Indication, and Response. The request is issued by the layer that 172 wants to get the services or the information from another layer, and 173 the confirm is the acknowledgment of the request. The indication is 174 the notification of the information to the layer that requested the 175 service, and the response is the acknowledgment of the indication. 176 In this architecture, a layer can evenly communicate with each other. 178 ------------------------------------------------------ 179 Request Response 180 || /\ /\ || 181 Layer N || || || || 182 ------------||------||----------||------||------------ 183 || || || || 184 \/ || || \/ 185 Layer N-m Confirm Indication 186 ------------------------------------------------------ 188 Figure 1: Primitives 190 The primitive consists of five fields: the protocol layer id to which 191 this primitive should be sent, the protocol id to which protocol 192 entity this primitive should be sent, the primitive class (i.e., 193 request, confirm, indication, or response), the primitive name, and 194 parameters. 196 There are three different usages of "Primitives": 198 Type 1. To provide L2 information to upper layers immediately 200 A "Request" primitive is an acquisition request for L2 201 information. As a "Confirm" primitive, L2 information 202 returns immediately. 204 Type 2. To notify upper layers of L2 events asynchronously 206 "Request" and "Confirm" primitives are used just for 207 registration. When an event occurs, an "Indication" 208 primitive is asynchronously delivered to an upper layer. 210 Type 3. To control L2 actions from upper layers 212 A "Request" primitive is a request for operation. Ack or 213 nack returns immediately as a "Confirm" primitive. 215 4. Definitions of Primitives 217 To obtain and exchange L2 information, the following Primitives are 218 defined. 220 4.1. L2-LinkStatus (Type 1) 222 The L2-LinkStatus.request primitive is sent to the link layer when an 223 upper layer needs the current information of a link. The L2- 224 LinkStatus.request primitive contains the "Network Interface ID" 225 parameter. In response, the L2-LinkStatus.confirm primitive returns. 226 The L2-LinkStatus.confirm primitive contains three parameters: 227 "Network Interface ID", "Peer", and "Condition". "Peer" and 228 "Condition" indicate the current status of the link between the 229 mobile node and a peer. 231 4.2. L2-PeerList (Type 1) 233 The L2-PeerList.request primitive is sent to the link layer when an 234 upper layer needs a list of the candidate peers. The L2- 235 PeerList.request primitive contains the "Network Interface ID" 236 parameter. In response, the L2-PeerList.confirm primitive returns 237 with the "Network Interface ID" parameter and the "Peer List" 238 parameter. The "Peer List" parameter is a list of the candidate 239 peers. 241 4.3. L2-PeerFound (Type 2) 243 The L2-PeerFound.indication primitive is asynchronously provided to 244 an upper layer when new peers are detected. This primitive carries 245 the "Network Interface ID" parameter and the "Peer List" parameter. 246 The "Peer List" parameter contains the information of new peers 247 detected by the mobile node. In order to use this notification, the 248 registration process using the L2-PeerFound.request primitive and the 249 L2-PeerFound.confirm primitive is needed in advance. The L2- 250 PeerFound.request primitive has two parameters: "Network Interface 251 ID" and "Enable/Disable". The "Enable/Disable" parameter shows 252 whether this notification function is turned on. When this 253 registration succeeds, the L2-PeerFound.confirm primitive returns 254 with the "Network Interface ID" parameter and the "Ack" parameter in 255 response. 257 4.4. L2-PeerLost (Type 2) 259 The L2-PeerLost.indication primitive is asynchronously provided to an 260 upper layer when a peer included in the list of candidate peers 261 disappears. This primitive carries the "Network Interface ID" 262 parameter and the "Peer List" parameter. The "Peer List" parameter 263 contains the information of the peers which disappeared from the 264 candidates list. The registration process using the L2- 265 PeerLost.request primitive and the L2-PeerLost.confirm primitive is 266 similar to the L2-PeerFound primitive described above. 268 4.5. L2-LinkUp (Type 2) 270 The L2-LinkUp.indication primitive is asynchronously provided to an 271 upper layer when a new link is connected. This primitive carries the 272 "Network Interface ID" parameter and the "Peer" parameter. The L2- 273 LinkUp.request primitive contains the "Network Interface ID" 274 parameter and the "Enable/Disable" parameter for registration. When 275 the registration succeeded, the L2-LinkUp.confirm primitive with the 276 "Network Interface ID" parameter and the "Ack" parameter returns. 278 4.6. L2-LinkDown (Type 2) 280 The L2-LinkDown.indication primitive is asynchronously provided to an 281 upper layer when an existing link is disconnected. The registration 282 processing is same as the L2-LinkUp primitive described above. 284 4.7. L2-LinkGoingDown (Type 2) 286 The L2-LinkGoingDown.indication primitive is asynchronously provided 287 to an upper layer when an existing link is about to be disconnected. 288 This notification contains two parameters: "Network Interface ID" and 289 "Peer". The "Peer" parameter indicates the attachment point at which 290 the link quality is degrading. In the registration processing, the 291 L2-LinkGoingDown.request primitive carries the "Network Interface ID" 292 parameter and the "Enable/Disable" parameter. 294 4.8. L2-LinkConnect (Type 3) 296 The L2-LinkConnect.request primitive is sent to the link layer when 297 an upper layer has to establish a new link to the specific "Peer". 298 This primitive carries the "Network Interface ID" parameter and the 299 "Peer" parameter. This operation begins after the link layer returns 300 the L2-LinkConnect.confirm primitive with "Ack". 302 4.9. L2-LinkDisconnect (Type 3) 304 The L2-LinkDisconnect.request primitive is sent to the link layer 305 when an upper layer has to tear down an existing link to the specific 306 "Peer". This primitive carries the "Network Interface ID" parameter 307 and the "Peer" parameter. This operation begins after the link layer 308 returns the L2-LinkDisconnect.confirm primitive with "Ack". 310 5. Definitions of Static Parameters 312 This section lists static parameters. Once the values of static 313 parameters are configured, they basically remain unchanged during 314 communication. The following parameters are transferred as a part of 315 primitives. 317 5.1. Network Interface ID 319 The "Network interface ID" parameter uniquely identifies the network 320 interface in the node. The syntax of the identifier is 321 implementation-specific (e.g., name, index or unique address assigned 322 to each interface). This parameter also contains the network 323 interface type which indicates the kind of technology of the network 324 interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is 325 required in all primitives. 327 6. Definitions of Dynamic Parameters 329 This section lists dynamic parameters. The values of dynamic 330 parameters change frequently during communication. The following 331 parameters are transferred as a part of primitives. 333 6.1. Peer 335 The "Peer" parameter uniquely identifies the peer. 337 6.2. Condition 339 The "Condition" parameter consists of the following sub-parameters: 340 available bandwidth and link quality level. These sub-parameters are 341 the abstracted information that indicates the current quality-of 342 service. The abstraction algorithms of sub-parameters depend on 343 hardware devices and software implementation. The useful range of 344 link quality is divided into five levels; EXCELLENT, GOOD, FAIR, BAD, 345 NONE in descending order. 347 6.3. Peer List 349 The "Peer List" parameter consists of arbitrary couples of two sub- 350 parameters: "Peer" and "Condition". This parameter shows a list of 351 peers and its condition. 353 6.4. Enable/Disable 355 The "Enable/Disable" flag is used for turning event notification on/ 356 off. When an upper layer needs notifications, the "Request" 357 primitive with "Enable" is sent to the link layer as registration. 358 When an upper layer needs no more notifications, the "Request" 359 primitive with "Disable" is sent. 361 6.5. Ack/Error 363 When an upper layer requests some notifications, the link layer 364 receives and confirms this "Request". If the "Request" is valid, the 365 "Confirm" primitive with "Ack" is sent to the upper layer. If it is 366 invalid, the "Confirm" with "Error" is sent to the upper layer. 368 7. Architectural Considerations 370 The IAB document "Architectural Implications of Link Indications" [3] 371 discusses the role and the issues of link indications within the 372 Internet Architecture. This section discusses the architectural 373 considerations mentioned in Section 2 of the IAB document. 375 [1] Proposals should avoid use of simplified link models in 376 circumstances where they do not apply. 378 The information in each layer should be abstracted before it is 379 sent to another layer. For example, in IEEE 802.11, the 380 Received Signal Strength Indicator (RSSI), the number of 381 retransmissions and existence of association between the mobile 382 node and the access point are used so that the link layer 383 indications can adjust themselves to various environments or 384 situations. The thresholds needed for some link indications 385 are defined from empirical study. 387 In the conventional protocol layering model, the Protocol 388 Entity (PE) is defined as the entity that processes a specific 389 protocol. Our proposal introduced the Abstract Entity (AE) to 390 achieve link independency of the link indications. An AE and a 391 PE make a pair. An AE abstracts the PE-dependent information 392 to the PE-independent information. 394 Figure 2 shows AEs and PEs using primitives. 396 [2] Link indications should be clearly defined, so that it is 397 understood when they are generated on different link layers. 399 To make the link information/indications clear, our proposal 400 defines the 4 types of primitives; request/confirm and 401 indication/response as described in Section 3. The request is 402 used to obtain the information of another layer. The confirm 403 is the reply to the request and it includes the requested 404 information. The indication is generated when a particular 405 event occurred. The response is the reply to the indication. 407 In our proposal about IEEE 802.11b, L2-LinkUp is defined as the 408 status in which an association to the AP is established, and 409 L2-LinkDown is defined as the status in which an association to 410 the AP is not established. L2-LinkGoingdown is generated when 411 the link quality becomes below the predefined threshold. Since 412 the Received Signal Strength Indicator (RSSI) and the number of 413 retransmissions are used to abstract and evaluate the link 414 quality, L2-LinkGoingDown represents the link quality in both 415 directions. It should use an average of RSSI or the number of 416 retransmissions damped for one second or more to cope with 417 transient link conditions. 419 [3] Proposals must demonstrate robustness against misleading 420 indications. 422 Since RSSI changes largely even when the mobile node stands 423 still according to the measurements in our experiments, our 424 proposal uses the RSSI, the number of retransmissions, and the 425 existence of an association to calculate the link status as 426 described above. In our experiments, there were some "ping- 427 pong" handovers between two APs. Such ping-pong handovers 428 could be reduced by detecting the most suitable AP by L2- 429 LinkStatus when L2-LinkGoingDown is notified. The use of L2 430 indications is related to parameter thresholds which trigger 431 handover. These thresholds vary based on the deployment 432 scenario, and if not configured properly, could lead to 433 misleading indications. 435 [4] Upper layers should utilize a timely recovery step so as to 436 limit the potential damage from link indications determined to 437 be invalid after they have been acted on. 439 The proposed L3-driven handover described in Appendix D uses 440 the L2-LinkGoingDown indication as the trigger for starting 441 handover. L2-LinkGoingDown is indicated when the link quality 442 goes down below the specific threshold. This indication is not 443 canceled even if the link quality goes up soon. As described 444 above, L2-LinkStatus can be used to detect the most suitable 445 AP. The IP layer can cancel a handover if it finds that the 446 current AP is the most suitable one by using L2-LinkStatus when 447 L2-LingGoingDown is notified. 449 [5] Proposals must demonstrate that effective congestion control is 450 maintained. 452 Since this mechanism is coupled to the IP layer, and not 453 directly to the transport layer, the proposed mechanism is not 454 directly affecting congestion control. 456 [6] Proposals must demonstrate the effectiveness of proposed 457 optimizations. 459 In IPv6 mobility, the L3-driven handover mechanism using link 460 indications can dramatically reduce gap time due to handover. 461 The L3-driven handover mechanism needs the L2-LinkGoingDown 462 indication to predict disconnection. But L2-LinkGoingDown is 463 not sometimes trusted because it is difficult to abstract the 464 link quality. Invalid L2-LinkGoingDown may cause redundant 465 handover. A handover mechanism using only L2-LinkUp/ 466 L2-LinkDown can also reduce gap time modestly. An example of 467 an implementation and an evaluation of the L3-driven handover 468 mechanism is described in Appendix D. 470 [7] Link indications should not be required by upper layers, in 471 order to maintain link independence. 473 Our proposal does not require any modifications to the 474 transport and upper layers. 476 [8] Proposals should avoid race conditions, which can occur where 477 link indications are utilized directly by multiple layers of 478 the stack. 480 Since our proposal defines the link indications to only the IP 481 layer, race conditions between multiple layers never happen. 483 [9] Proposals should avoid inconsistencies between link and routing 484 layer metrics. 486 Our proposal does not deal with routing metrics. 488 [10] Overhead reduction schemes must avoid compromising 489 interoperability and introducing link layer dependencies into 490 the Internet and Transport layers. 492 As described above, the link indications in our proposal are 493 abstracted to the information independent of link types to 494 reduce the gap time due to a handover, and the ordinary host 495 can execute handover without using the link indications defined 496 in our proposal. 498 [11] Proposals advocating the transport of link indications beyond 499 the local host need to carefully consider the layering, 500 security and transport implications. In general, implicit 501 signals are preferred to explicit transport of link indications 502 since they add no new packets in times of network distress, 503 operate more reliably in the presence of middle boxes such as 504 NA(P)Ts, are more likely to be backward compatible, and are 505 less likely to result in security vulnerabilities. 507 Our proposal does not define exchange of link indications 508 between nodes. 510 --------------------------------------------------------- 511 ----------=========== ----------=========== 512 | |[ ] | |[ ] 513 | PE |[ AE ] | PE |[ AE ] 514 | |[ ] | |[ ] 515 ----------=========== ----------=========== 516 Layer N || /\ || /\ 517 ------------||---||-------------------||---||------------ 518 Request|| || Response|| || 519 || || || || 520 || || || || 521 || ||Confirm || ||Indication 522 ------------||---||-------------------||---||------------ 523 \/ || \/ || 524 ----------=========== ----------=========== 525 | |[ ] | |[ ] 526 | PE |[ AE ] | PE |[ AE ] 527 | |[ ] | |[ ] 528 ----------=========== ----------=========== 529 Layer N-m 530 ---------------------------------------------------------- 532 Figure 2: AE and PE with Primitives 534 8. Security Considerations 536 The IAB document "Architectural Implications of Link Indications" [3] 537 discusses the role and the issues of link indications within the 538 Internet Architecture. This section discusses the security 539 considerations mentioned in Section 4 of the IAB document. 541 [1] Spoofing 543 Our proposal is no more insecure than a particular link layer on 544 which it is implemented. 546 [2] Indication validation 548 Transportation of the link indications between nodes is not 549 assumed, hence this consideration is out of scope in our 550 proposal. 552 [3] Denial of service 554 Our proposal is no more insecure than a particular link layer on 555 which it is implemented. 557 9. References 559 [1] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 560 July 2005. 562 [2] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 563 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 564 RFC 4140, August 2005. 566 [3] Aboda, B., "Architectural Implications of Link Indications", 567 draft-iab-link-indications-05 (work in progress), July 2006. 569 [4] Ishiyama, M., Kunishi, M., Esaki, H., and F. Teraoka, "LINA: A 570 New Approach to Mobility Support in Wide Area Networks", IEICE 571 Transactions on Communication vol. E84-B, no. 8, pp. 2076-2086, 572 August 2001. 574 Appendix A. Example Scenario 576 For example, the picture below shows L3-driven fast handover 577 mechanism using the L2 triggers on MN. 579 L2 L3 580 | | 581 |<----------LinkUP.req-----------| 582 |-----------LinkUP.cnf---------->| 583 |<-------LinkGoingDown.req-------| 584 |--------LinkGoingDown.cnf------>| 585 = = 586 | | 587 Low | 588 Signal-----LinkGoingDown.ind------>| 589 | | 590 |<---------PeerList.req----------| 591 |----------PeerList.cnf------>Handover 592 | Preparation 593 |<-------LinkConnect.req---------| 594 L2 Handover--LinkConnect.cnf-------->: 595 : : 596 : : 597 finish---------LinkUp.ind----->L3 Handover 598 | finish 599 | | 601 L2: Link Layer on MN 602 L3: Network Layer on MN 603 req: Request 604 cnf: Confirm 605 ind: Indication 607 Figure 3: L3-Driven Fast Handover Mechanism 609 First, the L3 issues LinkUp.request to receive LinkUp.indication when 610 the link becomes available. The L3 also issues LinkGoingDown.request 611 to receive LinkGoingDown.indication when the link quality goes down 612 below the threshold. 614 In the beginning of the L3-driven handover procedure, the L2 detects 615 the radio signal strength is going down. Then the L2 sends L2- 616 LinkGoingDown.indication to the L3. The L3 prepares for handover 617 (e.g., CoA generation, DAD, ND cache creation, and routing table 618 setting) and sends L2-PeerList.request to the L2 if the list of 619 access points is needed. 621 If the L3 decides to perform handover according to some rules, the L3 622 sends L2-LinkConnect.request with some parameters about candidate 623 access points to request L2 handover. L2 handover begins after the 624 L3 sends L2-LinkConnect.confirm to the L2. When the L2 handover 625 finished, the L2 sends L2-LinkUp.indication to notify the L3. 626 Finally, the L3 performs handover (e.g., sending BU). 628 One of the important features of L3-driven fast handover using 629 Primitives is that the L3 handover preparation can be done during 630 communication. So, it can reduce disruption time during handover. 632 Appendix B. Example Operation for FMIPv6 634 Here shows 2 scenarios of L3 driven fast handover for FMIPv6. 635 Scenario 2 is differ from scenario 1 for the timing of sending some 636 messages. 638 B.1. Example Operation-1 for FMIPv6 640 Figure 4 shows the predictive mode of FMIPv6 operation with L3-driven 641 link switching mechanism. 643 MN-L2 MN-L3 PAR-L3 644 | | | 645 AP<---------PeerList.req----------| | 646 Scan---------PeerList.cnf--------->| | 647 | |---RtSolPr-->| 648 | |<--PrRtAdv---| 649 |---------PeerFound.ind--------->| | 650 | |---RtSolPr-->| 651 | |<--PrRtAdv---| 652 | | | 653 ~ ~ ~ 654 | | | 655 Low | | 656 Signal-----LinkGoingDown.ind------>| | NAR-L3 657 | |-----FBU---->| | 658 | | |----HI---->| 659 | | |<--HAck----| 660 | |<----FBack---| | 661 |<-------LinkConnect.req---L3 Handover | | 662 L2 Handover--LinkConnect.cnf-------->: | 663 : : | 664 : : | 665 finish---------LinkUp.ind---------->: | 666 | :-----------FNA---------->| 667 | finish<======packets=========| 668 | | | 670 MN-L2 : Link Layer on Mobile Node 671 MN-L3 : Network Layer on Mobile Node 672 PAR-L3 : Network Layer on Previous Access Router 673 NAR-L3 : Network Layer on New Access Router 674 req : Request 675 cnf : Confirm 676 ind : Indication 677 RtSolPr : Router Solicitation for Proxy 678 PrRtAdv : Proxy Router Advertisement 679 FBU : Fast Binding Update 680 FBack : Fast Binding Acknowledgment 681 FNA : Fast Neighbor Advertisement 682 HI : Handover Initiate 683 HAck : Handover Acknowledge 685 Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 1 687 When the MN establishes link connectivity to the PAR, it performs 688 router discovery. The MN sends RtSolPr message to the PAR to resolve 689 the access point identifiers to the subnet router information. To 690 send RtSolPr, a MN discovers one or more access points by sending L2- 691 PeerList.request to the link layer. As a response to L2- 692 PeerList.request, L2-PeerList.confirm returns with "Peer List" 693 parameter which contains identifiers and conditions of nearby access 694 points. After initial AP discovery, L2-PeerFound.indication with 695 "Peer List" is also sent from the link layer when one or more access 696 points are discovered. 698 When the link layer of the MN detects that radio signal strength is 699 going down, it sends L2-LinkGoingDown.indication to the network 700 layer. Then, the MN sends the FBU message to the PAR as the 701 beginning of the L3 handover procedure. The NCoA required for the 702 FBU message is determined according to the MN's policy database and 703 the received PrRtAdv message. As a response to the FBU message, the 704 MN receives the FBack message and then immediately switches its link 705 by L2-LinkConnect.request with the specific "Peer" parameter. The 706 handover policy of the MN is outside the scope of this document. 708 After L2 handover, the link layer of the MN sends L2- 709 LinkUp.indication to the network layer. The MN immediately sends the 710 FNA message to the NAR. The NAR will send tunneled and buffered 711 packets to the MN. 713 B.2. Example Operation-2 for FMIPv6 715 Figure 5 shows the predictive mode of FMIPv6 operation with L3-driven 716 link switching mechanism. 718 MN-L2 MN-L3 PAR-L3 719 | | | 720 AP<---------PeerList.req----------| | 721 Scan---------PeerList.cnf--------->| | 722 | |---RtSolPr-->| 723 | |<--PrRtAdv---| 724 |---------PeerFound.ind--------->| | 725 | |---RtSolPr-->| 726 | |<--PrRtAdv---| 727 | | | 728 ~ ~ ~ 729 | | | 730 Low | | 731 Signal-----LinkGoingDown.ind------>| | NAR-L3 732 | |-----FBU---->| | 733 |<-------LinkConnect.req---L3 Handover | | 734 L2 Handover--LinkConnect.cnf-------->: | | 735 | | |----HI---->| 736 | | |<--HAck----| 737 | | |---FBack-->| 738 | |<----FBack---------------| 739 : : | 740 finish---------LinkUp.ind---------->: | 741 | :-----------FNA---------->| 742 | finish<======packets=========| 743 | | | 745 MN-L2 : Link Layer on Mobile Node 746 MN-L3 : Network Layer on Mobile Node 747 PAR-L3 : Network Layer on Previous Access Router 748 NAR-L3 : Network Layer on New Access Router 749 req : Request 750 cnf : Confirm 751 ind : Indication 752 RtSolPr : Router Solicitation for Proxy 753 PrRtAdv : Proxy Router Advertisement 754 FBU : Fast Binding Update 755 FBack : Fast Binding Acknowledgment 756 FNA : Fast Neighbor Advertisement 757 HI : Handover Initiate 758 HAck : Handover Acknowledge 760 Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 2 762 Unlike the scenario 1, the MN in scenario 2 sends LinkConnect.req 763 from the network layer to the link layer after MN sends the FBU 764 message. As the MN sends the FBack message to both AR (not only the 765 PAR but also the NAR), the MN can get the FBack message sent by the 766 PAR through the NAR, and then it moves to the NAR. 768 B.3. Experiment 770 We implemented FMIPv6 and the proposed L2 primitives on FreeBSD-5.4. 771 Figure 6 shows our test network. The MN is connected to access 772 routers by using IEEE802.11a wireless LAN. The MN moves from the PAR 773 to the NAR. 775 | 776 +--+---+ 777 |Router| 778 +--+---+ 779 | 100BaseTX 780 ---+--------+---------+---------+---------+------------ 781 | | | | 782 +--+--+ +--+--+ +--+--+ +--+--+ 783 | PAR | | NAR | | HA | | CN | 784 +-----+ +-----+ +-----+ +-----+ 785 | | 786 IEEE802.11a IEEE802.11a PAR, NAR: nexcom EBC 787 |Channel 7 |Channel7 MN: ThinkPad X31 788 OS: FreeBSD-5.4 789 | | KAME/SHISA/TARZAN 790 +-----+ +-----+ 791 | MN | -------> | MN | 792 +-----+ +-----+ 794 Figure 6: Test Network 796 Scenario 1 was used in this experiment. Upon receiving L2- 797 LinkGoingDown.indication, the L3 of the MN sends the FBU message and 798 then receives the FBack message. It took 20ms from the transmission 799 of the FBU message and the reception of the FBack message. After 800 receiving the FBack message, the L3 of the MN issues L2- 801 LinkConnect.request to the L2. When L2 handover finishes, the L3 802 receives L2-LinkUp.ind from the L2. It took 1ms for an L2 handover. 803 Next, the MN sends the FNA message to the NAR. Upon receiving the 804 FNA message, the NAR starts forwarding packets to the NM. ICMP echo 805 request packets were sent at 10ms intervals. It was observed that no 806 or 1 ICMP echo reply packet was lost during a handover. 808 MN PAR NAR 809 | | | 810 |----- RtSolPr --->| | 811 |<---- PrRtAdv ----| | 812 | | | 813 +--- |------ FBU ------>| | 814 | | |------- HI ------>| 815 20ms| | | | 816 | | |<----- HAck ------| 817 | | | | 818 +--- |<-------------- FBack -------------->| 819 | | | 820 +-- disconnect | | 821 | 1ms| | | 822 | connect | | 823 8-10ms| | | | 824 | 7ms| | | 825 | | | | 826 | +----- FNA -------------------------->| 827 +-- |<------------------------ deliver packets 828 | | | 830 Figure 7: Measured Results 832 Appendix C. Example Mapping of Primitives and IEEE802.11 834 This section shows examples of the mapping between "Primitives" and 835 IEEE802.11 parameters. 837 C.1. L2-LinkStatus 839 Most of parameters of L2-LinkStatus are related to the configuration 840 of network interface hardware. The operating system and the device 841 driver module can easily collect such information. However, to 842 create the "Condition" parameter, the MN should maintain statistics 843 and parameters related to the current wireless environment. 845 There are two sub-parameters of the "Condition" parameter: available 846 bandwidth and link quality level. The available bandwidth of the 847 current peer can be obtained by maintaining the transmission rate 848 indication and the statistics of frame transmission at every time a 849 frame is sent. A link quality level can be updated by maintaining 850 the following parameters and statistics at every time a frame is 851 received: receive signal strength indication (RSSI), transmission/ 852 reception rate indication, transmit/receive latency, bit error rate, 853 frame error rate and noise level. Link quality level is divided into 854 five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE in descending 855 order. Some parameters can be managed by setting threshold from 856 software. When the parameters cross the threshold, an interrupt is 857 generated for the software. 859 C.2. L2-PeerList 861 In IEEE 802.11 networks, L2-PeerList returns the detected APs which 862 quality level exceeds the specified threshold as peer candidates (by 863 the "Peer List" parameter). Therefore, the MN should always maintain 864 the database of available access points according to reception of 865 beacon frame, probe response frame and all frames. This AP database 866 is managed in consideration of time, number of frames and signal 867 strength. There are some kinds of network interface hardware that 868 can notify events to operating system only when the desired event 869 occurs, by setting a threshold from software. Moreover, the MN can 870 transmit the probe request frame for access point discovery, if 871 needed. 873 C.3. L2-PeerFound 875 In IEEE 802.11 networks, L2-PeerFound is notified when new peers 876 which link quality level exceeds the specified threshold are detected 877 by listening beacons or scanning APs. If the received frame (mainly 878 the beacon or the probe response) is not in the AP database described 879 in Appendix C.2, then the link layer creates L2-PeerFound.indication. 881 For example, if the threshold of link quality level specified by L2- 882 PeerFound.request is GOOD, the L2-PeerFound.ind is made and sent to 883 the upper layer when peer's link quality becomes stronger than to the 884 level of GOOD. 886 C.4. L2-PeerLost 888 In IEEE 802.11 networks, L2-PeerLost is notified when an AP included 889 in the list of candidate APs is got lost by listening beacons or 890 scanning APs. If the entry in the AP database described in 891 Appendix C.2 expires, or link quality level goes under the threshold, 892 then the link layer creates L2-PeerLost.indication. To calculate the 893 link quality level, the signal strength of the received frame (mainly 894 the beacon or the probe response) can be used. For example, if the 895 threshold of the link quality specified by L2-PeerLost is BAD, L2- 896 PeerLost.ind is made and sent to the upper layer when peer's link 897 quality becomes weaker than the level of BAD. 899 C.5. L2-LinkUp 901 In IEEE 802.11 networks, L2-LinkUp is notified when association or 902 reassociation event occurs. When such event occurs, the MN receives 903 the association response frame or the reassociation response frame. 904 Immediately after receiving it, the link layer creates L2- 905 LinkUp.indication. 907 C.6. L2-LinkDown 909 In IEEE 802.11 networks, L2-LinkDown is notified when disassociation 910 event occurs or when no beacon is received during a certain time. 911 When such event occurs, the MN sends the disassociation frame to the 912 AP, or the entry of the specific AP is deleted from the AP database 913 described in Appendix C.2. By detecting such events, the link layer 914 creates L2-LinkDown.indication. 916 C.7. L2-LinkGoingDown 918 In IEEE 802.11 networks, L2-LinkGoingDown is notified when the radio 919 signal strength of the connected AP is going down and becomes under 920 the specified threshold. 922 C.8. L2-LinkConnect 924 In IEEE802.11 networks, each AP is identified by the BSSID and the 925 service set of several APs is identified by the SSID. When L2- 926 LinkConnect is used to connect a specific AP or a service set, the 927 link layer should set the BSSID or the SSID. Also, the channel 928 should be set appropriately at the same time by searching the 929 database described in Appendix C.2. To connect to the AP, the MN 930 should be authenticated by the AP. The MN sends the authentication 931 message to the AP, and then the MN sends the association message to 932 associate with the AP. 934 C.9. L2-LinkDisconnect 936 In IEEE802.11 networks, the MN sends the disassociation message to 937 the AP for disconnection. When L2-LinkDisconnect is used for 938 disconnection from the current AP, the link layer should send the 939 disassociation message to the appropriate AP, and stop data 940 transmission. 942 Appendix D. Implementation and Evaluation of the Proposed Model 944 This section describes an implementation of the proposed link 945 indication architecture and its evaluation. 947 An IEEE802.11a wireless LAN device driver was modified to provide 948 abstract link layer information in the form of primitives defined in 949 Section 4. The modified driver has two AP lists. One contains the 950 device dependent information such as the RSSI, the retransmission 951 count, various AP parameters and various statistics. The device 952 dependent information except for the AP parameters is updated 953 whenever the device receives a frame. If the received frame is the 954 management frame, the AP parameters are also updated according to the 955 parameters in the frame. 957 Another AP list contains the abstract information. The abstract 958 information is updated periodically by using the device dependent 959 information. In the abstraction processing, for example, the RSSI or 960 the retransmission count is converted to the common indicator "link 961 quality". 963 L2-PeerList and L2-LinkStatus were implemented by using only the 964 abstract information. Thus, the upper layers can use information of 965 the current AP and the adjacent APs without depending on the devices. 966 L2-PeerFound or L2-PeerLost is notified if the link quality went up 967 or down beyond the thresholds when the abstract information is 968 updated. If the link quality of the current AP went down below the 969 specific threshold, L2-LinkGoingDown is notified. L2-LinkUp or L2- 970 LinkDown is notified when an association with an AP is established or 971 destroyed. To realize L2-LinkConnect and L2-LinkDisconnect, 972 functions to connect or disconnect to the specified AP were 973 implemented. In these functions, since only abstract information is 974 needed to specify the AP, other layers need not to know the device 975 dependent information. 977 In our outdoor testbed, there are eight ARs, each of which is located 978 at a 80-100m interval. The AP is collocated at the AR. IEEE802.11a 979 was used as the link layer. The same wireless channel was used at 980 all the APs. Thus there are eight wireless IPv6 subnets in the 981 testbed. The mobile node in a car moved at a speed of 30-40 km/h. 982 When link quality of the current AP goes down, the mobile node 983 executes L3-driven handover described in Appendix A. An application 984 called DVTS was running on the mobile node and sent digital video 985 data at about a 15Mbps data rate through the wireless IPv6 subnet to 986 the correspondent node, which replayed received digital video data. 987 In this environment, the L2 handover needed less than 1 msec and 988 mobility protocol LIN6 [4] needed a few msec for location 989 registration. Thus, the total gap time due to the handover was 3-4 990 msec. In most case, there was no influence to the replayed pictures 991 over handover. 993 Appendix E. Changes from 01 995 - References were updated. 997 Authors' Addresses 999 Fumio Teraoka 1000 Graduate School of Science and Technology, KEIO University 1001 3-14-1 Hiyoshi, Kohoku-ku 1002 Yokohama, Kanagawa 223-8522 1003 Japan 1005 Phone: 45-566-1425 1006 Email: tera@ics.keio.ac.jp 1007 URI: http://www.tera.ics.keio.ac.jp/ 1009 Kazutaka Gogo 1010 Faculty of Science and Technology, KEIO University 1011 3-14-1 Hiyoshi, Kohoku-ku 1012 Yokohama, Kanagawa 223-8522 1013 Japan 1015 Phone: 45-566-1425 1016 Email: gogo@tera.ics.keio.ac.jp 1017 URI: http://www.tera.ics.keio.ac.jp/ 1019 Koshiro Mitsuya 1020 Jun Murai Lab, Shonan Fujisawa Campus, KEIO University 1021 5322 Endo 1022 Fujisawa, Kanagawa 252-8520 1023 Japan 1025 Phone: +81-466-49-1100 1026 Email: mitsuya_at_sfc.wide.ad.jp 1027 URI: 1029 Rie Shibui 1030 Graduate School of Science and Technology, KEIO University 1031 3-14-1 Hiyoshi, Kohoku-ku 1032 Yokohama, Kanagawa 223-8522 1033 Japan 1035 Phone: 45-566-1425 1036 Email: shibrie@tera.ics.keio.ac.jp 1037 URI: http://www.tera.ics.keio.ac.jp/ 1038 Koki Mitani 1039 Graduate School of Science and Technology, KEIO University 1040 3-14-1 Hiyoshi, Kohoku-ku 1041 Yokohama, Kanagawa 223-8522 1042 Japan 1044 Phone: 45-566-1425 1045 Email: koki@tera.ics.keio.ac.jp 1046 URI: http://www.tera.ics.keio.ac.jp/ 1048 Full Copyright Statement 1050 Copyright (C) The Internet Society (2006). 1052 This document is subject to the rights, licenses and restrictions 1053 contained in BCP 78, and except as set forth therein, the authors 1054 retain all their rights. 1056 This document and the information contained herein are provided on an 1057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1059 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1060 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1061 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Intellectual Property 1066 The IETF takes no position regarding the validity or scope of any 1067 Intellectual Property Rights or other rights that might be claimed to 1068 pertain to the implementation or use of the technology described in 1069 this document or the extent to which any license under such rights 1070 might or might not be available; nor does it represent that it has 1071 made any independent effort to identify any such rights. Information 1072 on the procedures with respect to rights in RFC documents can be 1073 found in BCP 78 and BCP 79. 1075 Copies of IPR disclosures made to the IETF Secretariat and any 1076 assurances of licenses to be made available, or the result of an 1077 attempt made to obtain a general license or permission for the use of 1078 such proprietary rights by implementers or users of this 1079 specification can be obtained from the IETF on-line IPR repository at 1080 http://www.ietf.org/ipr. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights that may cover technology that may be required to implement 1085 this standard. Please address the information to the IETF at 1086 ietf-ipr@ietf.org. 1088 Acknowledgment 1090 Funding for the RFC Editor function is provided by the IETF 1091 Administrative Support Activity (IASA).