idnits 2.17.00 (12 Aug 2021) /tmp/idnits56937/draft-irtf-mobopts-l2-abstractions-07.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, updated by RFC 4748 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1230. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** 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 221: '...es of primitives MUST be exchanged for...' RFC 2119 keyword, line 230: '...ses of primitive MUST be exchanged and...' RFC 2119 keyword, line 231: '..."Response" class MAY be exchanged for ...' RFC 2119 keyword, line 240: '... primitives MUST be exchanged for...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 17, 2008) is 5200 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) == Missing Reference: '10' is mentioned on line 541, but not defined == Missing Reference: '11' is mentioned on line 551, but not defined ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 4140 (ref. '4') (Obsoleted by RFC 5380) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 4957 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 4907 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 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 Expires: August 20, 2008 K. Mitsuya 5 R. Shibui 6 K. Mitani 7 KEIO University 8 February 17, 2008 10 Unified L2 Abstractions for L3-Driven Fast Handover 11 draft-irtf-mobopts-l2-abstractions-07.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 August 20, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 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. This 51 draft defines nine kinds of L2 abstractions in the form of 52 "primitives" to achieve fast handovers in the network layer as a 53 means of solving the problem. This mechanism is called "L3-driven 54 fast handovers" because the network layer initiates L2 and L3 55 handovers by using the "primitives". This document is a product of 56 the IP Mobility Optimizations (MobOpts) Research Group. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 7 66 4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 9 67 4.1. L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 9 68 4.2. L2-PoAList (Type 1) . . . . . . . . . . . . . . . . . . . 9 69 4.3. L2-PoAFound (Type 2) . . . . . . . . . . . . . . . . . . . 9 70 4.4. L2-PoALost (Type 2) . . . . . . . . . . . . . . . . . . . 9 71 4.5. L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 10 72 4.6. L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 10 73 4.7. L2-LinkStatusChanged (Type 2) . . . . . . . . . . . . . . 10 74 4.8. L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 10 75 4.9. L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 11 77 5. Definitions of Static Parameters . . . . . . . . . . . . . . . 12 78 5.1. Network Interface ID . . . . . . . . . . . . . . . . . . . 12 80 6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 13 81 6.1. PoA (Point of Attachment) . . . . . . . . . . . . . . . . 13 82 6.2. Condition . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.3. PoA List . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.4. Enable/Disable . . . . . . . . . . . . . . . . . . . . . . 13 85 6.5. Ack/Error . . . . . . . . . . . . . . . . . . . . . . . . 13 87 7. Architectural Considerations . . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 Appendix A. Example Scenario . . . . . . . . . . . . . . . . . . 21 97 Appendix B. Example Operation for FMIPv6 . . . . . . . . . . . . 23 98 B.1. Example Operation-1 for FMIPv6 . . . . . . . . . . . . . . 23 99 B.2. Example Operation-2 for FMIPv6 . . . . . . . . . . . . . . 25 100 B.3. Experiment . . . . . . . . . . . . . . . . . . . . . . . . 27 102 Appendix C. Example Mapping between L2 Primitives and 103 Primitives in IEEE802.11 and IEEE802.16e . . . . . . 29 105 Appendix D. Example Mapping of Primitives and IEEE802.11 . . . . 31 106 D.1. L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 31 107 D.2. L2-PoAList . . . . . . . . . . . . . . . . . . . . . . . . 31 108 D.3. L2-PoAFound . . . . . . . . . . . . . . . . . . . . . . . 31 109 D.4. L2-PoALost . . . . . . . . . . . . . . . . . . . . . . . . 32 110 D.5. L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 32 111 D.6. L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 32 112 D.7. L2-LinkStatusChanged . . . . . . . . . . . . . . . . . . . 32 113 D.8. L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 32 114 D.9. L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 33 116 Appendix E. Implementation and Evaluation of the Proposed 117 Model . . . . . . . . . . . . . . . . . . . . . . . . 34 119 Appendix F. Changes from 05 . . . . . . . . . . . . . . . . . . . 36 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 122 Intellectual Property and Copyright Statements . . . . . . . . . . 39 124 1. Introduction 126 Recent years have witnessed the rapid proliferation of wireless 127 networks as well as mobile devices accessing them. Unlike wired 128 network environments, wireless networks are characterized by 129 dynamically changing radio conditions, connectivity, and available 130 bandwidth. For efficient network communication, it is vital for a 131 protocol layer to know or utilize other layer's control information. 132 Mobile IPv4 [1] and Mobile IPv6 [2] have been standardized to support 133 communication with mobile nodes. There are several proposals for 134 seamless handovers in IPv6 networks such as Fast Handovers for Mobile 135 IPv6 (FMIPv6) [3] and Hierarchical Mobile IPv6 (HMIPv6) [4]. In 136 FMIPv6, the network layer must know in advance the indication of a 137 handover from the link layer to achieve seamless handovers. However, 138 control information exchange between protocol layers is typically not 139 available because each protocol layer is designed independently. 141 To solve the problem, this draft defines nine kinds of L2 142 abstractions in the form of "primitives" to achieve fast handovers in 143 the network layer. This mechanism is called "L3-driven fast 144 handovers" because the network layer initiates L2 and L3 handovers by 145 using the "primitives". 147 IEEE 802.21 [5] also defines several services that make use of L2 148 information. For the sake of ease of implementation and deployment, 149 the primitives defined in this document make use of only the 150 information available in the mobile node, while IEEE 802.21 151 introduces the information server in the network to provide the 152 mobile node with network-related information such as a global network 153 map. 155 This document represents the consensus of the MobOpts Research Group. 156 It has been reviewed by Research Group members active in the specific 157 area of work. 159 2. Terminology 161 This document uses the following terms. 163 L3-Driven Fast Handover 165 The handover mechanism that is initiated by the network layer on a 166 mobile node. Since this mechanism allows handover preparation in 167 L3 before the start of an L2 handover on the mobile node, it can 168 reduce packet loss during a handover. The L3-driven fast handover 169 mechanism requires L2 information as a trigger for a handover 170 procedure. 172 PoA 174 The point of attachment of a mobile node. (e.g., an access point 175 in IEEE 802.11 networks.) 177 Primitive 179 A unit of information that is sent from one layer to another. 180 There are four classes of primitives: Request, Confirm, Indication 181 and Response. One or more classes of a primitive are exchanged 182 depending on the type of primitive. 184 3. Primitives for L2 Abstractions 186 Each layer offers its services in the form of primitives. Four 187 classes of primitives are defined as shown in Figure 1. Request is 188 issued by the layer that wants to get the services or the information 189 from another layer, and Confirm is the acknowledgment of the request. 190 Indication is the notification of the information to the layer that 191 requested the service, and Response is the acknowledgment of the 192 indication. In this architecture, communication between layers is 193 symmetrical. 195 ------------------------- ----------------------------- 196 Request Response 197 || /\ /\ || 198 Layer N || || || || 199 ------------||------||--- -------||------||------------ 200 || || || || 201 \/ || || \/ 202 Layer N-m Confirm Indication 203 ------------------------- ----------------------------- 205 Figure 1: Interaction Model between Layers 207 The primitive consists of five fields: protocol layer ID, protocol 208 ID, primitive class (Request, Response, Indication, or Confirm), 209 primitive name, and parameters. The protocol layer ID specifies to 210 which layer this primitive should be sent, e.g., Layer 2 or Layer 3. 211 The protocol ID specifies to which protocol entity this primitive 212 should be sent, e.g., IEEE802.11 or IEEE802.3. 214 For unified L2 abstractions for L3-driven fast handovers, three 215 different usages of "Primitives" are defined as described below: 217 Type 1. To provide L2 information to upper layers immediately 219 This type of primitive is used to provide the L2 information 220 to upper layers immediately. The "Request" and "Confirm" 221 classes of primitives MUST be exchanged for the interaction. 222 The "Request" primitive is for an acquisition request for 223 the L2 information. The "Confirm" primitive is for the 224 answer. 226 Type 2. To notify upper layers of L2 events asynchronously 228 This type of primitive is used to notify upper layers of L2 229 events asynchronously. The "Request", "Confirm" and 230 "Indication" classes of primitive MUST be exchanged and the 231 "Response" class MAY be exchanged for the interaction. The 232 "Request" and "Confirm" primitives are used just for 233 registration. When an event occurs, the "Indication" 234 primitive is asynchronously delivered to the upper layer. 236 Type 3. To control L2 actions from upper layers 238 This type of primitive is used to control L2 actions from 239 upper layers. The "Request" and "Confirm" classes of 240 primitives MUST be exchanged for the interaction. The 241 "Request" primitive is a request for operation. Ack or nack 242 returns immediately as the "Confirm" primitive. 244 A protocol entity can register primitives anytime by exchanging the 245 Request and Confirm messages that include the fields defined above. 246 When the registered event occurs, the Indication and Response 247 messages are exchanged as well. 249 The way to exchange a message between protocol entities is beyond the 250 scope of this document. Any information exchange method between 251 layers such as the work [6] can be used. 253 The timing for sending an Indication primitive is also beyond the 254 scope of this document. For example, a layer 2 event is generated 255 when layer 2 status has been changed and this depends upon how 256 scanning algorithms, for example, are implemented. 258 4. Definitions of Primitives 260 To obtain and exchange L2 information, the following Primitives are 261 defined. Appendix C shows example mapping between the L2 primitives 262 and the primitives in IEEE802.11 and IEEE802.16e. 264 4.1. L2-LinkStatus (Type 1) 266 The L2-LinkStatus.request primitive is sent to the link layer when an 267 upper layer requires the current information of a link. The L2- 268 LinkStatus.request primitive contains the "Network Interface ID" 269 parameter (See Section 5.1). In response, the L2-LinkStatus.confirm 270 primitive returns. The L2-LinkStatus.confirm primitive contains 271 three parameters: "Network Interface ID", "PoA", and "Condition". 272 "PoA" and "Condition" indicate the current status of the link between 273 the mobile node and a PoA. 275 4.2. L2-PoAList (Type 1) 277 The L2-PoAList.request primitive is sent to the link layer when an 278 upper layer requires a list of the candidate PoAs. The L2- 279 PoAList.request primitive contains the "Network Interface ID" 280 parameter. In response, the L2-PoAList.confirm primitive returns the 281 "Network Interface ID" parameter and the "PoA List" parameter. The 282 "PoA List" parameter is a list of the candidate PoAs. 284 4.3. L2-PoAFound (Type 2) 286 The L2-PoAFound.indication primitive is asynchronously provided to an 287 upper layer when new PoAs are detected. This primitive carries the 288 "Network Interface ID" parameter and the "PoA List" parameter. The 289 "PoA List" parameter contains information on new PoAs detected by the 290 mobile node. In order to use this notification, the registration 291 process using the L2-PoAFound.request primitive and the L2- 292 PoAFound.confirm primitive is needed in advance. The L2- 293 PoAFound.request primitive has two parameters: "Network Interface ID" 294 and "Enable/Disable". The "Enable/Disable" parameter shows whether 295 this notification function is turned on. When this registration 296 succeeds, the L2-PoAFound.confirm primitive returns with the "Network 297 Interface ID" parameter and the "Ack" parameter in response. 299 4.4. L2-PoALost (Type 2) 301 The L2-PoALost.indication primitive is asynchronously provided to an 302 upper layer when a PoA included in the list of candidate PoAs 303 disappears. This primitive carries the "Network Interface ID" 304 parameter and the "PoA List" parameter. The "PoA List" parameter 305 contains information on the PoAs that disappeared from the candidates 306 list. The registration process using the L2-PoALost.request 307 primitive and the L2-PoALost.confirm primitive is similar to the L2- 308 PoAFound primitive described above. 310 4.5. L2-LinkUp (Type 2) 312 The L2-LinkUp.indication primitive is asynchronously provided to an 313 upper layer when a new link is connected and IP packets can be 314 transmitted through the new link. As described in RFC 4957 [7], what 315 "link is connected" means depends on link types. For example, in 316 case of the infrastructure mode in IEEE802.11 (WiFi), this primitive 317 is provided when an association to an access point is established. 318 This primitive carries the "Network Interface ID" parameter and the 319 "PoA" parameter. The L2-LinkUp.request primitive contains the 320 "Network Interface ID" parameter and the "Enable/Disable" parameter 321 for registration. When the registration succeeds, the L2- 322 LinkUp.confirm primitive with the "Network Interface ID" parameter 323 and the "Ack" parameter returns. 325 4.6. L2-LinkDown (Type 2) 327 The L2-LinkDown.indication primitive is asynchronously provided to an 328 upper layer when an existing link is disconnected and IP packets 329 cannot be transmitted through the link. The registration processing 330 is same as the L2-LinkUp primitive described above. 332 4.7. L2-LinkStatusChanged (Type 2) 334 The L2-LinkStatusChanged.indication primitive is asynchronously 335 provided to an upper layer when the status of a link has changed. 336 This notification contains three parameters: "Network Interface ID", 337 "PoA", and "Condition". The "PoA" parameter indicates the attachment 338 point at which the link quality changed. In the registration 339 processing, the L2-LinkStatusChanged.request primitive carries the 340 "Network Interface ID" parameter, the "Enable/Disable" parameter, and 341 the "Condition" parameter. "Condition" indicates the event type and 342 the threshold for the indication. 344 4.8. L2-LinkConnect (Type 3) 346 The L2-LinkConnect.request primitive is sent to the link layer when 347 an upper layer has to establish a new link to the specific "PoA". 348 This primitive carries the "Network Interface ID" parameter and the 349 "PoA" parameter. This operation begins after the link layer returns 350 the L2-LinkConnect.confirm primitive with "Ack". 352 4.9. L2-LinkDisconnect (Type 3) 354 The L2-LinkDisconnect.request primitive is sent to the link layer 355 when an upper layer has to tear down an existing link to the specific 356 "PoA". This primitive carries the "Network Interface ID" parameter 357 and the "PoA" parameter. This operation begins after the link layer 358 returns the L2-LinkDisconnect.confirm primitive with "Ack". 360 5. Definitions of Static Parameters 362 This section lists static parameters. Once the values of static 363 parameters are configured, they basically remain unchanged during 364 communication. The following parameters are transferred as a part of 365 primitives. 367 5.1. Network Interface ID 369 The "Network interface ID" parameter uniquely identifies the network 370 interface in the node. The syntax of the identifier is 371 implementation-specific (e.g., name, index or unique address assigned 372 to each interface). This parameter also contains the network 373 interface type which indicates the kind of technology of the network 374 interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is 375 required in all primitives. 377 6. Definitions of Dynamic Parameters 379 This section lists dynamic parameters. The values of dynamic 380 parameters change frequently during communication. The following 381 parameters are transferred as a part of primitives. 383 6.1. PoA (Point of Attachment) 385 The "PoA" parameter uniquely identifies the PoA. 387 6.2. Condition 389 The "Condition" parameter consists of the following sub-parameters: 390 available bandwidth and link quality level. These sub-parameters are 391 the abstracted information that indicates the current quality-of 392 service. The abstraction algorithms of sub-parameters depend on 393 hardware devices and software implementation. The useful range of 394 link quality is divided into five levels: EXCELLENT, GOOD, FAIR, BAD, 395 NONE in descending order. The quality levels of a L2 device are 396 independent of those of other devices. However, Making decisions 397 based on these metrics is error prone and not guaranteed to result in 398 optimal choice of links. An example of the thresholds among the five 399 levels in IEEE802.11 is described in Appendix E. 401 6.3. PoA List 403 The "PoA List" parameter consists of arbitrary couples of two sub- 404 parameters: "PoA" and "Condition". This parameter shows a list of 405 PoAs and their conditions. 407 6.4. Enable/Disable 409 The "Enable/Disable" flag is used for turning event notification on/ 410 off. When an upper layer needs notifications, the "Request" 411 primitive with "Enable" is sent to the link layer as registration. 412 When an upper layer needs no more notifications, the "Request" 413 primitive with "Disable" is sent. 415 6.5. Ack/Error 417 When an upper layer requests some notifications, the link layer 418 receives and confirms this "Request". If the "Request" is valid, the 419 "Confirm" primitive with "Ack" is sent to the upper layer. If it is 420 invalid, the "Confirm" with "Error" is sent to the upper layer. 422 7. Architectural Considerations 424 RFC 4907 [8] discusses the role and the issues of link indications 425 within the Internet Architecture. This section discusses the 426 architectural considerations mentioned in Section 2 of RFC 4907. 428 [1] Proposals should avoid use of simplified link models in 429 circumstances where they do not apply. 431 The information in each layer should be abstracted before it is 432 sent to another layer. For example, in IEEE 802.11, the 433 Received Signal Strength Indicator (RSSI), the number of 434 retransmissions and existence of association between the mobile 435 node and the access point are used so that the link layer 436 indications can adjust themselves to various environments or 437 situations. The thresholds needed for some link indications 438 are defined from empirical study. 440 In the conventional protocol layering model, the Protocol 441 Entity (PE) is defined as the entity that processes a specific 442 protocol. Our proposal introduced the Abstract Entity (AE) to 443 achieve link independency of the link indications. An AE and a 444 PE make a pair. An AE abstracts the PE-dependent information 445 to the PE-independent information. 447 Figure 2 shows AEs and PEs using primitives. 449 [2] Link indications should be clearly defined, so that it is 450 understood when they are generated on different link layers. 452 To make the link information/indications clear, our proposal 453 defines the 4 types of primitives: request/confirm and 454 indication/response as described in Section 3. The request is 455 used to obtain the information of another layer. The confirm 456 is the reply to the request and it includes the requested 457 information. The indication is generated when a particular 458 event occurs. The response is the reply to the indication. 460 In our proposal on IEEE 802.11b, L2-LinkUp is defined as the 461 status in which an association to the AP is established, and 462 L2-LinkDown is defined as the status in which an association to 463 the AP is not established. L2-LinkStatusChanged is generated 464 when the link quality goes below the predefined threshold. 465 Since the Received Signal Strength Indicator (RSSI) and the 466 number of retransmissions are used to abstract and evaluate the 467 link quality, L2-LinkStatusChanged represents the link quality 468 in both directions. It should use an average of RSSI or the 469 number of retransmissions damped for one second or more to cope 470 with transient link conditions. 472 [3] Proposals must demonstrate robustness against misleading 473 indications. 475 Since RSSI changes significantly even when the mobile node 476 stands still according to the measurements in our experiments, 477 our proposal uses the RSSI, the number of retransmissions, and 478 the existence of an association to calculate the link status as 479 described above. In our experiments, there were some "ping- 480 pong" handovers between two APs. Such ping-pong handovers 481 could be reduced by detecting the most suitable AP by L2- 482 LinkStatus when L2-LinkStatusChanged is notified. The use of 483 L2 indications is related to parameter thresholds which trigger 484 handover. These thresholds vary based on the deployment 485 scenario, and if not configured properly, could lead to 486 misleading indications. 488 [4] Upper layers should utilize a timely recovery step so as to 489 limit the potential damage from link indications determined to 490 be invalid after they have been acted on. 492 The proposed L3-driven handover described in Appendix E uses 493 the L2-LinkStatusChanged indication as the trigger for starting 494 handover. L2-LinkStatusChanged is indicated when the link 495 quality goes below a specific threshold. This indication is 496 not canceled even if the link quality goes up soon. As 497 described above, L2-LinkStatus can be used to detect the most 498 suitable AP. The IP layer can cancel a handover if it finds 499 that the current AP is the most suitable one by using L2- 500 LinkStatus when L2-LinkStatusChanged is notified. 502 [5] Proposals must demonstrate that effective congestion control is 503 maintained. 505 Since this mechanism is coupled to the IP layer, and not 506 directly to the transport layer, the proposed mechanism does 507 not directly affect congestion control. 509 [6] Proposals must demonstrate the effectiveness of proposed 510 optimizations. 512 In IPv6 mobility, the L3-driven handover mechanism using link 513 indications can dramatically reduce gap time due to handover. 514 The L3-driven handover mechanism needs the L2-LinkStatusChanged 515 indication to predict disconnection. But L2-LinkStatusChanged 516 sometimes is not trusted because it is difficult to abstract 517 the link quality. Invalid L2-LinkStatusChanged may cause 518 redundant handover. A handover mechanism using only L2-LinkUp/ 519 L2-LinkDown can also reduce gap time modestly. An example of 520 an implementation and evaluation of the L3-driven handover 521 mechanism is described in Appendix E. 523 [7] Link indications should not be required by upper layers, in 524 order to maintain link independence. 526 Our proposal does not require any modifications to the 527 transport and upper layers. 529 [8] Proposals should avoid race conditions, which can occur where 530 link indications are utilized directly by multiple layers of 531 the stack. 533 Since our proposal defines the link indications only to the IP 534 layer, race conditions between multiple layers never occur. 536 [9] Proposals should avoid inconsistencies between link and routing 537 layer metrics. 539 Our proposal does not deal with routing metrics. 541 [10] Overhead reduction schemes must avoid compromising 542 interoperability and introducing link layer dependencies into 543 the Internet and Transport layers. 545 As described above, the link indications in our proposal are 546 abstracted to the information independent of link types to 547 reduce the gap time due to a handover, and the ordinary host 548 can execute handover without using the link indications defined 549 in our proposal. 551 [11] Proposals advocating the transport of link indications beyond 552 the local host need to carefully consider the layering, 553 security and transport implications. In general, implicit 554 signals are preferred to explicit transport of link indications 555 since they add no new packets in times of network distress, 556 operate more reliably in the presence of middle boxes such as 557 NA(P)Ts, are more likely to be backward compatible, and are 558 less likely to result in security vulnerabilities. 560 Our proposal does not define exchange of link indications 561 between nodes. 563 --------------------------------------------------------- 564 ----------=========== ----------=========== 565 | |[ ] | |[ ] 566 | PE |[ AE ] | PE |[ AE ] 567 | |[ ] | |[ ] 568 ----------=========== ----------=========== 569 Layer N || /\ || /\ 570 ------------||---||-------------------||---||------------ 571 Request|| || Response|| || 572 || || || || 573 || || || || 574 || ||Confirm || ||Indication 575 ------------||---||-------------------||---||------------ 576 \/ || \/ || 577 ----------=========== ----------=========== 578 | |[ ] | |[ ] 579 | PE |[ AE ] | PE |[ AE ] 580 | |[ ] | |[ ] 581 ----------=========== ----------=========== 582 Layer N-m 583 --------------------------------------------------------- 585 Figure 2: AE and PE with Primitives 587 8. Security Considerations 589 RFC 4907 [8] discusses the role and the issues of link indications 590 within the Internet Architecture. This section discusses the 591 security considerations mentioned in Section 4 of RFC 4907. 593 [1] Spoofing 595 The proposed primitives suffer from spoofed link layer control 596 frames. For example, if a malicious access point is set up and 597 spoofed beacon frames are transmitted, L2-PoAFound.indication is 598 generated in the mobile node. As a result, the mobile node may 599 establish an association with the malicious access point by L2- 600 LinkConnect.request. 602 [2] Indication validation 604 Transportation of the link indications between nodes is not 605 assumed, hence this consideration is beyond the scope of our 606 proposal. 608 [3] Denial of service 610 Since this proposal does not change link layer protocols, no 611 more insecurity is added to a particular link layer protocol. 612 However, the proposed primitives suffer from denial of service 613 attack by spoofed link layer frames. For example, L2- 614 PoAFound.indication and L2-PoALost.indication may frequently be 615 generated alternately if a malicious access point frequently 616 transmits control frames that indicate strong RSSI and weak RSSI 617 alternately. 619 9. Acknowledgements 621 The authors gratefully acknowledge the contributions of Jukka Manner, 622 Christian Vogt, and John Levine for their review. 624 10. References 626 [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 627 August 2002. 629 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 630 IPv6", RFC 3775, June 2004. 632 [3] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 633 July 2005. 635 [4] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 636 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 637 RFC 4140, August 2005. 639 [5] "Draft IEEE Standard for Local and Metropolitan Area Networks: 640 Media Independent Handover Services", IEEE P802.21/D02.00, 641 September 2006. 643 [6] Gogo, K., Shibu, R., and F. Teraoka, "An L3-Driven Fast Handover 644 Mechanism in IPv6 Mobility", In Proc. of International Symposium 645 on Applications and the Internet (SAINT2006) Workshop in IPv6, 646 February 2006. 648 [7] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. 649 Yegin, "Link-Layer Event Notifications for Detecting Network 650 Attachments", RFC 4957, August 2007. 652 [8] Aboda, B., "Architectural Implications of Link Indications", 653 RFC 4907, June 2007. 655 [9] Ishiyama, M., Kunishi, M., Esaki, H., and F. Teraoka, "LINA: A 656 New Approach to Mobility Support in Wide Area Networks", IEICE 657 Transactions on Communication vol. E84-B, no. 8, pp. 2076-2086, 658 August 2001. 660 Appendix A. Example Scenario 662 For example, the picture below shows L3-driven fast handover 663 mechanism using the L2 triggers on MN. 665 L2 L3 666 | | 667 |<----------LinkUP.req-----------| 668 |-----------LinkUP.cnf---------->| 669 |<-----LinkStatusChanged.req-----| 670 |------LinkStatusChanged.cnf---->| 671 = = 672 | | 673 Low | 674 Signal---LinkStatusChanged.ind---->| 675 | | 676 |<----------PoAList.req----------| 677 |-----------PoAList.cnf------>Handover 678 | Preparation 679 |<-------LinkConnect.req---------| 680 L2 Handover--LinkConnect.cnf-------->: 681 : : 682 : : 683 finish---------LinkUp.ind----->L3 Handover 684 | finish 685 | | 687 L2: Link Layer on MN 688 L3: Network Layer on MN 689 req: Request 690 cnf: Confirm 691 ind: Indication 693 Figure 3: L3-Driven Fast Handover Mechanism 695 First, L3 issues LinkUp.request to receive LinkUp.indication when the 696 link becomes available. L3 also issues LinkStatusChanged.request to 697 receive LinkStatusChanged.indication when the link quality goes below 698 below the threshold. 700 In the beginning of the L3-driven handover procedure, L2 detects that 701 the radio signal strength is going down. Then L2 sends L2- 702 LinkStatusChanged.indication to L3. L3 prepares for handover (e.g., 703 CoA generation, DAD, ND cache creation, and routing table setting) 704 and sends L2-PoAList.request to L2 if the list of access points is 705 needed. 707 If L3 decides to perform handover according to some rules, L3 sends 708 L2-LinkConnect.request with some parameters about candidate access 709 points to request L2 handover. L2 handover begins after L2 sends L2- 710 LinkConnect.confirm to L3. When the L2 handover finishes, L2 sends 711 L2-LinkUp.indication to notify L3. Finally, L3 performs handover 712 (e.g., sending BU). 714 One of the important features of L3-driven fast handover using 715 Primitives is that L3 handover preparation can be done during 716 communication. So, it can reduce disruption time during handover. 718 Appendix B. Example Operation for FMIPv6 720 There are two scenarios of L3 driven fast handover for FMIPv6. 721 Scenario 2 is different from scenario 1 for the timing of sending 722 some messages. 724 B.1. Example Operation-1 for FMIPv6 726 Figure 4 shows the predictive mode of FMIPv6 operation with L3-driven 727 link switching mechanism. 729 MN-L2 MN-L3 PAR-L3 730 | | | 731 AP<----------PoAList.req----------| | 732 Scan----------PoAList.cnf--------->| | 733 | |---RtSolPr-->| 734 | |<--PrRtAdv---| 735 |----------PoAFound.ind--------->| | 736 | |---RtSolPr-->| 737 | |<--PrRtAdv---| 738 | | | 739 ~ ~ ~ 740 | | | 741 Low | | 742 Signal---LinkStatusChanged.ind---->| | NAR-L3 743 | |-----FBU---->| | 744 | | |----HI---->| 745 | | |<--HAck----| 746 | |<----FBack---| | 747 |<-------LinkConnect.req---L3 Handover | | 748 L2 Handover--LinkConnect.cnf-------->: | 749 : : | 750 : : | 751 finish---------LinkUp.ind---------->: | 752 | :-----------FNA---------->| 753 | finish<======packets=========| 754 | | | 756 MN-L2 : Link Layer on Mobile Node 757 MN-L3 : Network Layer on Mobile Node 758 PAR-L3 : Network Layer on Previous Access Router 759 NAR-L3 : Network Layer on New Access Router 760 req : Request 761 cnf : Confirm 762 ind : Indication 763 RtSolPr : Router Solicitation for Proxy 764 PrRtAdv : Proxy Router Advertisement 765 FBU : Fast Binding Update 766 FBack : Fast Binding Acknowledgment 767 FNA : Fast Neighbor Advertisement 768 HI : Handover Initiate 769 HAck : Handover Acknowledge 771 Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 1 773 When MN establishes link connectivity to PAR, it performs router 774 discovery. MN sends RtSolPr message to PAR to resolve the access 775 point identifiers to the subnet router information. To send RtSolPr, 776 MN discovers one or more access points by sending L2-PoAList.request 777 to the link layer. As a response to L2-PoAList.request, L2- 778 PoAList.confirm returns with "PoA List" parameter which contains 779 identifiers and conditions of nearby access points. After initial AP 780 discovery, L2-PoAFound.indication with "PoA List" is also sent from 781 the link layer when one or more access points are discovered. 783 When the link layer of MN detects that radio signal strength is 784 dropping, it sends L2-LinkStatusChanged.indication to the network 785 layer. Then, MN sends the FBU message to PAR as the beginning of the 786 L3 handover procedure. The NCoA required for the FBU message is 787 determined according to the MN's policy database and the received 788 PrRtAdv message. As a response to the FBU message, MN receives the 789 FBack message and then immediately switches its link by L2- 790 LinkConnect.request with the specific "PoA" parameter. The handover 791 policy of the MN is outside the scope of this document. 793 After L2 handover, the link layer of the MN sends L2- 794 LinkUp.indication to the network layer. MN immediately sends the FNA 795 message to NAR. NAR will send tunneled and buffered packets to MN. 797 B.2. Example Operation-2 for FMIPv6 799 Figure 5 shows the predictive mode of FMIPv6 operation with L3-driven 800 link switching mechanism. 802 MN-L2 MN-L3 PAR-L3 803 | | | 804 AP<----------PoAList.req----------| | 805 Scan----------PoAList.cnf--------->| | 806 | |---RtSolPr-->| 807 | |<--PrRtAdv---| 808 |----------PoAFound.ind--------->| | 809 | |---RtSolPr-->| 810 | |<--PrRtAdv---| 811 | | | 812 ~ ~ ~ 813 | | | 814 Low | | 815 Signal---LinkStatusChanged.ind---->| | NAR-L3 816 | |-----FBU---->| | 817 |<-------LinkConnect.req---L3 Handover | | 818 L2 Handover--LinkConnect.cnf-------->: | | 819 | | |----HI---->| 820 | | |<--HAck----| 821 | | <-FBack-|---FBack-->| 822 | |<----FBack---------------| 823 : : | 824 finish---------LinkUp.ind---------->: | 825 | :-----------FNA---------->| 826 | finish<======packets=========| 827 | | | 829 MN-L2 : Link Layer on Mobile Node 830 MN-L3 : Network Layer on Mobile Node 831 PAR-L3 : Network Layer on Previous Access Router 832 NAR-L3 : Network Layer on New Access Router 833 req : Request 834 cnf : Confirm 835 ind : Indication 836 RtSolPr : Router Solicitation for Proxy 837 PrRtAdv : Proxy Router Advertisement 838 FBU : Fast Binding Update 839 FBack : Fast Binding Acknowledgment 840 FNA : Fast Neighbor Advertisement 841 HI : Handover Initiate 842 HAck : Handover Acknowledge 844 Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 2 846 Unlike scenario 1, MN in scenario 2 sends LinkConnect.req from the 847 network layer to the link layer after MN sends the FBU message. As 848 PAR sends the FBack messages not only to PAR's subnet but also to 849 NAR's subnet, MN can get the FBack message sent by PAR through NAR, 850 and then it moves to NAR. 852 B.3. Experiment 854 We implemented FMIPv6 and the proposed L2 primitives on FreeBSD-5.4. 855 Figure 6 shows our test network. MN is connected to access routers 856 by using IEEE802.11a wireless LAN. MN moves from PAR to NAR. 858 | 859 +--+---+ 860 |Router| 861 +--+---+ 862 | 100BaseTX 863 ---+--------+---------+---------+---------+------------ 864 | | | | 865 +--+--+ +--+--+ +--+--+ +--+--+ 866 | PAR | | NAR | | HA | | CN | 867 +-----+ +-----+ +-----+ +-----+ 868 | | 869 IEEE802.11a IEEE802.11a PAR, NAR: nexcom EBC 870 |Channel 7 |Channel7 MN: ThinkPad X31 871 OS: FreeBSD-5.4 872 | | KAME/SHISA/TARZAN 873 +-----+ +-----+ 874 | MN | -------> | MN | 875 +-----+ +-----+ 877 Figure 6: Test Network 879 Scenario 1 was used in this experiment since it was more stable than 880 scenario 2. Upon receiving L2-LinkStatusChanged.indication, L3 of MN 881 sends the FBU message and then receives the FBack message. It took 882 20ms from the transmission of the FBU message to the reception of the 883 FBack message. After receiving the FBack message, L3 of MN issues 884 L2-LinkConnect.request to L2. When L2 handover finishes, L3 receives 885 L2-LinkUp.ind from L2. It took 1ms for an L2 handover. Next, MN 886 sends the FNA message to NAR. Upon receiving the FNA message, NAR 887 starts forwarding packets to NM. ICMP echo request packets were sent 888 at 10ms intervals. It was observed that no or one ICMP echo reply 889 packet was lost during a handover. 891 MN PAR NAR 892 | | | 893 |----- RtSolPr --->| | 894 |<---- PrRtAdv ----| | 895 | | | 896 +--- |------ FBU ------>| | 897 | | |------- HI ------>| 898 20ms| | | | 899 | | |<----- HAck ------| 900 | | | | 901 +--- |<-------------- FBack -------------->| 902 | | | 903 +-- disconnect | | 904 | 1ms| | | 905 | connect | | 906 8-10ms| | | | 907 | 7ms| | | 908 | | | | 909 | +----- FNA -------------------------->| 910 +-- |<------------------------ deliver packets 911 | | | 913 Figure 7: Measured Results 915 Appendix C. Example Mapping between L2 Primitives and Primitives in 916 IEEE802.11 and IEEE802.16e 918 This section shows example mapping between the L2 primitives and 919 primitives in IEEE802.11 and IEEE802.16e in Table 1. 921 +-------------------+----------------------+------------------+ 922 | L2 Primitive | IEEE802.11 | IEEE802.16e | 923 +-------------------+----------------------+------------------+ 924 | L2-LinkStatus | PMD_RSSI | Available | 925 | | | | 926 | | PMD_RATE | | 927 | | | | 928 | L2-PoAList | MLME-SCAN | M_ScanScheduling | 929 | | | | 930 | | | M_Scanning | 931 | | | | 932 | L2-PoAFound | MLME-SCAN | M_Neighbor | 933 | | | | 934 | | | M_Scanning | 935 | | | | 936 | L2-PoALost | MLME-SCAN | M_Neighbor | 937 | | | | 938 | | | M_Scanning | 939 | | | | 940 | L2-LinkUp | MLME-ASSOCIATE | M_Registration | 941 | | | | 942 | | MLME-AUTHENTICATE | | 943 | | | | 944 | L2-LinkDown | MLME-DEASSOCIATE | M_Ranging | 945 | | | | 946 | | MLME-DISAUTHENTICATE | | 947 | | | | 948 | L2-StatusChanged | PMD_RSSI | M_Ranging | 949 | | | | 950 | | | M_ScanReport | 951 | | | | 952 | | | M_Scanning | 953 | | | | 954 | L2-LinkConnect | MLME-JOIN | M_MACHandover | 955 | | | | 956 | | MLME-ASSOCIATE | M_HOIND | 957 | | | | 958 | | MLME-REASSOCIATE | | 959 | | | | 960 | | MLME-AUTHENTICATE | | 961 | | | | 962 | L2-LinkDisconnect | MLME-DISASSOCIATE | M_Management | 963 | | | | 964 | | MLME-DEASSOCIATE | (Deregistration) | 965 +-------------------+----------------------+------------------+ 967 Table 1: Mapping between L2 primitives and primitives in IEEE802.11 968 and IEEE802.16e 970 Appendix D. Example Mapping of Primitives and IEEE802.11 972 This section shows examples of the mapping between "Primitives" and 973 IEEE802.11 parameters. 975 D.1. L2-LinkStatus 977 Most of parameters of L2-LinkStatus are related to the configuration 978 of network interface hardware. The operating system and the device 979 driver module can easily collect such information. However, to 980 create the "Condition" parameter, the MN should maintain statistics 981 and parameters related to the current wireless environment. 983 There are two sub-parameters of the "Condition" parameter: available 984 bandwidth and link quality level. The available bandwidth of the 985 current PoA can be obtained by maintaining the transmission rate 986 indication and the statistics of frame transmission every time a 987 frame is sent. A link quality level can be updated by maintaining 988 the following parameters and statistics every time a frame is 989 received: receive signal strength indication (RSSI), transmission/ 990 reception rate indication, transmit/receive latency, bit error rate, 991 frame error rate and noise level. Link quality level is divided into 992 five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE in descending 993 order. Some parameters can be managed by setting thresholds from 994 software. When the parameters cross the threshold, an interrupt is 995 generated for the software. 997 D.2. L2-PoAList 999 In IEEE 802.11 networks, L2-PoAList returns the detected APs whose 1000 quality level exceeds the specified threshold for PoA candidates (by 1001 the "PoA List" parameter). Therefore, MN should always maintain the 1002 database of available access points according to reception of beacon 1003 frame, probe response frame and all frames. This AP database is 1004 managed in consideration of time, number of frames and signal 1005 strength. There are some kinds of network interface hardware that 1006 can notify events to operating system only when the desired event 1007 occurs, by setting a threshold from software. Moreover, MN can 1008 transmit the probe request frame for access point discovery, if 1009 needed. 1011 D.3. L2-PoAFound 1013 In IEEE 802.11 networks, L2-PoAFound is notified when new PoAs whose 1014 link quality level exceeds the specified threshold are detected by 1015 listening beacons or scanning APs. If the received frame (mainly the 1016 beacon or the probe response) is not in the AP database described in 1017 Appendix D.2, then the link layer creates L2-PoAFound.indication. 1019 For example, if the threshold of link quality level specified by L2- 1020 PoAFound.request is GOOD, L2-PoAFound.ind is created and sent to the 1021 upper layer when PoA's link quality becomes better than GOOD. 1023 D.4. L2-PoALost 1025 In IEEE 802.11 networks, L2-PoALost is notified when an AP included 1026 in the list of candidate APs is lost by listening beacons or scanning 1027 APs. If the entry in the AP database described in Appendix D.2 1028 expires, or link quality level goes under the threshold, then the 1029 link layer creates L2-PoALost.indication. To calculate the link 1030 quality level, the signal strength of the received frame (mainly the 1031 beacon or the probe response) can be used. For example, if the 1032 threshold of the link quality specified by L2-PoALost is BAD, L2- 1033 PoALost.ind is created and sent to the upper layer when PoA's link 1034 quality becomes worse than BAD. 1036 D.5. L2-LinkUp 1038 In IEEE 802.11 networks, L2-LinkUp is notified when association or 1039 reassociation event occurs. When such event occurs, MN receives the 1040 association response frame or the reassociation response frame. 1041 Immediately after receiving it, the link layer creates L2- 1042 LinkUp.indication. 1044 D.6. L2-LinkDown 1046 In IEEE 802.11 networks, L2-LinkDown is notified when a 1047 disassociation event occurs or when no beacon is received during a 1048 certain time. When such event occurs, MN sends the disassociation 1049 frame to AP, or the entry of the specific AP is deleted from the AP 1050 database described in Appendix D.2. By detecting such events, the 1051 link layer creates L2-LinkDown.indication. 1053 D.7. L2-LinkStatusChanged 1055 In IEEE 802.11 networks, L2-LinkStatusChanged is notified when the 1056 radio signal strength of the connected AP drops below the specified 1057 threshold. 1059 D.8. L2-LinkConnect 1061 In IEEE802.11 networks, each AP is identified by the BSSID and the 1062 service set of several APs is identified by the SSID. When L2- 1063 LinkConnect is used to connect a specific AP or a service set, the 1064 link layer should set the BSSID or the SSID. Also, the channel 1065 should be set appropriately at the same time by searching the 1066 database described in Appendix D.2. To connect to AP, MN should be 1067 authenticated by AP. MN sends the authentication message to AP, and 1068 then MN sends the association message to associate with AP. 1070 D.9. L2-LinkDisconnect 1072 In IEEE802.11 networks, MN sends the disassociation message to AP for 1073 disconnection. When L2-LinkDisconnect is used for disconnection from 1074 the current AP, the link layer should send the disassociation message 1075 to the appropriate AP, and stop data transmission. 1077 Appendix E. Implementation and Evaluation of the Proposed Model 1079 This section describes an implementation of the proposed link 1080 indication architecture and its evaluation. 1082 An IEEE802.11a wireless LAN device driver was modified to provide 1083 abstract link layer information in the form of primitives defined in 1084 Section 4. The modified driver has two AP lists. One contains the 1085 device-dependent information such as RSSI, retransmission count, 1086 various AP parameters and various statistics. The device-dependent 1087 information except for the AP parameters is updated whenever the 1088 device receives a frame. If the received frame is the management 1089 frame, the AP parameters are also updated according to the parameters 1090 in the frame. 1092 Another AP list contains the abstract information. The abstract 1093 information is updated periodically by using the device-dependent 1094 information. In the abstraction processing, for example, RSSI or the 1095 retransmission count is converted to the common indicator "link 1096 quality". In our outdoor testbed described below, the thresholds of 1097 the RSSI value between the link quality levels were defined as 1098 follows: 1100 o EXCELLENT -- 34 -- GOOD 1102 o GOOD -- 27 -- FAIR 1104 o FIAR -- 22 -- BAD 1106 o BAD -- 15 -- NONE 1108 L2-PoAList and L2-LinkStatus were implemented by using only the 1109 abstract information. Thus, the upper layers can use information of 1110 the current AP and the adjacent APs without depending on the devices. 1111 L2-PoAFound or L2-PoALost is notified if the link quality rises or 1112 falls beyond the thresholds when the abstract information is updated. 1113 If the link quality of the current AP goes below the specific 1114 threshold, L2-LinkStatusChanged is notified. L2-LinkUp or L2- 1115 LinkDown is notified when an association with an AP is established or 1116 destroyed. To realize L2-LinkConnect and L2-LinkDisconnect, 1117 functions to connect or disconnect to the specified AP were 1118 implemented. In these functions, since only abstract information is 1119 needed to specify the AP, other layers need not know the device- 1120 dependent information. 1122 In our outdoor testbed, there are eight ARs located at 80-100m 1123 intervals. AP is collocated at AR. IEEE802.11a was used as the link 1124 layer. The same wireless channel was used at all APs. Thus there 1125 are eight wireless IPv6 subnets in the testbed. The mobile node was 1126 in a car moving at a speed of 30-40 km/h. When link quality of the 1127 current AP goes down, the mobile node executes L3-driven handover 1128 described in Appendix A. An application called DVTS was running on 1129 the mobile node and sent digital video data at a data rate of about 1130 15Mbps through the wireless IPv6 subnet to the correspondent node, 1131 which replayed received digital video data. In this environment, the 1132 L2 handover required less than 1 msec and mobility protocol LIN6 [9] 1133 required a few msec for location registration. Thus, the total gap 1134 time due to the handover was 3-4 msec. In most cases, there was no 1135 effect on the replayed pictures due to handover. 1137 Appendix F. Changes from 06 1139 o Bugs were fixed in Appendix A and Appendix B.2. 1141 Authors' Addresses 1143 Fumio Teraoka 1144 Graduate School of Science and Technology, KEIO University 1145 3-14-1 Hiyoshi, Kohoku-ku 1146 Yokohama, Kanagawa 223-8522 1147 Japan 1149 Phone: 45-566-1425 1150 Email: tera@ics.keio.ac.jp 1151 URI: http://www.tera.ics.keio.ac.jp/ 1153 Kazutaka Gogo 1154 Faculty of Science and Technology, KEIO University 1155 3-14-1 Hiyoshi, Kohoku-ku 1156 Yokohama, Kanagawa 223-8522 1157 Japan 1159 Phone: 45-566-1425 1160 Email: gogo@tera.ics.keio.ac.jp 1161 URI: http://www.tera.ics.keio.ac.jp/ 1163 Koshiro Mitsuya 1164 Jun Murai Lab, Shonan Fujisawa Campus, KEIO University 1165 5322 Endo 1166 Fujisawa, Kanagawa 252-8520 1167 Japan 1169 Phone: +81-466-49-1100 1170 Email: mitsuya_at_sfc.wide.ad.jp 1171 URI: 1173 Rie Shibui 1174 Graduate School of Science and Technology, KEIO University 1175 3-14-1 Hiyoshi, Kohoku-ku 1176 Yokohama, Kanagawa 223-8522 1177 Japan 1179 Phone: 45-566-1425 1180 Email: shibrie@tera.ics.keio.ac.jp 1181 URI: http://www.tera.ics.keio.ac.jp/ 1182 Koki Mitani 1183 Graduate School of Science and Technology, KEIO University 1184 3-14-1 Hiyoshi, Kohoku-ku 1185 Yokohama, Kanagawa 223-8522 1186 Japan 1188 Phone: 45-566-1425 1189 Email: koki@tera.ics.keio.ac.jp 1190 URI: http://www.tera.ics.keio.ac.jp/ 1192 Full Copyright Statement 1194 Copyright (C) The IETF Trust (2008). 1196 This document is subject to the rights, licenses and restrictions 1197 contained in BCP 78, and except as set forth therein, the authors 1198 retain all their rights. 1200 This document and the information contained herein are provided on an 1201 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1202 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1203 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1204 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1205 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1206 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1208 Intellectual Property 1210 The IETF takes no position regarding the validity or scope of any 1211 Intellectual Property Rights or other rights that might be claimed to 1212 pertain to the implementation or use of the technology described in 1213 this document or the extent to which any license under such rights 1214 might or might not be available; nor does it represent that it has 1215 made any independent effort to identify any such rights. Information 1216 on the procedures with respect to rights in RFC documents can be 1217 found in BCP 78 and BCP 79. 1219 Copies of IPR disclosures made to the IETF Secretariat and any 1220 assurances of licenses to be made available, or the result of an 1221 attempt made to obtain a general license or permission for the use of 1222 such proprietary rights by implementers or users of this 1223 specification can be obtained from the IETF on-line IPR repository at 1224 http://www.ietf.org/ipr. 1226 The IETF invites any interested party to bring to its attention any 1227 copyrights, patents or patent applications, or other proprietary 1228 rights that may cover technology that may be required to implement 1229 this standard. Please address the information to the IETF at 1230 ietf-ipr@ietf.org. 1232 Acknowledgment 1234 Funding for the RFC Editor function is provided by the IETF 1235 Administrative Support Activity (IASA).