idnits 2.17.1 draft-iab-link-indications-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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2627. 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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (6 February 2007) is 6287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 650 -- Looks like a reference, but probably isn't: '2' on line 677 -- Looks like a reference, but probably isn't: '3' on line 685 -- Looks like a reference, but probably isn't: '4' on line 696 -- Looks like a reference, but probably isn't: '5' on line 573 -- Looks like a reference, but probably isn't: '6' on line 576 -- Looks like a reference, but probably isn't: '7' on line 579 -- Looks like a reference, but probably isn't: '8' on line 582 -- Looks like a reference, but probably isn't: '9' on line 586 -- Looks like a reference, but probably isn't: '10' on line 589 -- Looks like a reference, but probably isn't: '11' on line 593 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1131 (Obsoleted by RFC 1247) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-05 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-03 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-12 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 == Outdated reference: A later version (-01) exists of draft-yegin-l2-triggers-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba, Ed. 3 INTERNET-DRAFT Internet Architecture Board 4 Category: Informational IAB 5 6 6 February 2007 8 Architectural Implications of Link Indications 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 A link indication represents information provided by the link layer 40 to higher layers regarding the state of the link. This document 41 describes the role of link indications within the Internet 42 Architecture. While the judicious use of link indications can 43 provide performance benefits, inappropriate use can degrade both 44 robustness and performance. This document summarizes current 45 proposals, describes the architectural issues and provides examples 46 of appropriate and inappropriate uses of link indications. 48 Table of Contents 50 1. Introduction.............................................. 3 51 1.1 Requirements ....................................... 3 52 1.2 Terminology ........................................ 3 53 1.3 Overview ........................................... 4 54 1.4 Layered Indication Model ........................... 6 55 2. Architectural Considerations ............................. 13 56 2.1 Model Validation ................................... 14 57 2.2 Clear Definitions .................................. 14 58 2.3 Robustness ......................................... 16 59 2.4 Congestion Control ................................. 19 60 2.5 Effectiveness ...................................... 20 61 2.6 Interoperability ................................... 20 62 2.7 Race Conditions .................................... 21 63 2.8 Layer Compression .................................. 24 64 2.9 Transport of Link Indications ...................... 25 65 3. Future Work .............................................. 26 66 4. Security Considerations .................................. 27 67 4.1 Spoofing ........................................... 27 68 4.2 Indication Validation .............................. 28 69 4.3 Denial of Service .................................. 29 70 5. IANA Considerations ...................................... 29 71 6. References ............................................... 29 72 6.1 Informative References ............................. 29 73 Appendix A - Literature Review ............................... 38 74 A.0 Terminology ........................................ 38 75 A.1 Link Layer ......................................... 38 76 A.2 Internet Layer ..................................... 48 77 A.3 Transport Layer .................................... 49 78 A.4 Application Layer .................................. 53 79 Appendix B - IAB Members ..................................... 55 80 Authors' Addresses ........................................... 55 81 Full Copyright Statement ..................................... 55 82 Intellectual Property ........................................ 56 83 1. Introduction 85 A link indication represents information provided by the link layer 86 to higher layers regarding the state of the link. While the 87 judicious use of link indications can provide performance benefits, 88 inappropriate use can degrade both robustness and performance. 90 This document summarizes the current understanding of the role of 91 link indications, and provides advice to document authors about the 92 appropriate use of link indications within the Internet, Transport 93 and Application layers. 95 Section 1 describes the history of link indication usage within the 96 Internet architecture and provides a model for the utilization of 97 link indications. Section 2 describes the architectural 98 considerations and provides advice to document authors. Section 3 99 describes recommendations and future work. Appendix A summarizes the 100 literature on link indications in wireless Local Area Networks 101 (LANs). 103 1.1. Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1.2. Terminology 111 Asymmetric 112 A link with transmission characteristics which are different 113 depending upon the relative position or design characteristics of 114 the transmitter and the receiver is said to be asymmetric. For 115 instance, the range of one transmitter may be much higher than the 116 range of another transmitter on the same medium. 118 Link A communication facility or medium over which nodes can communicate 119 at the link layer, i.e., the layer immediately below the Internet 120 Protocol (IP). 122 Link Down 123 An event provided by the link layer that signifies a state change 124 associated with the interface no longer being capable of 125 communicating data frames; transient periods of high frame loss are 126 not sufficient. 128 Link Layer 129 Conceptual layer of control or processing logic that is responsible 130 for maintaining control of the link. The link layer functions 131 provide an interface between the higher-layer logic and the link. 132 The link layer is the layer immediately below the Internet Protocol 133 (IP). 135 Link indication 136 Information provided by the link layer to higher layers regarding 137 the state of the link. 139 Link Up 140 An event provided by the link layer that signifies a state change 141 associated with the interface becoming capable of communicating 142 data frames. 144 Point of Attachment 145 The endpoint on the link to which the host is currently connected. 147 Operable address 148 The term "operable address" refers to either a static address or a 149 dynamically assigned address which has not been relinquished, and 150 has not expired. 152 Routable address 153 In this specification, the term "routable address" refers to any 154 IPv4 address other than an IPv4 Link-Local address. This includes 155 private addresses as specified in "Address Allocation for Private 156 Internets" [RFC1918]. 158 Strong End System Model 159 In the Strong End System model, packets sent out an interface have 160 a source address configured on that interface and incoming packets 161 whose destination does not correspond to the physical interface 162 through which it is received are silently discarded. In general, 163 the Strong End System model emphasizes the host/router distinction, 164 tending to model a multihomed host as a set of logical hosts within 165 the same physical host. 167 Weak End System Model 168 In the Weak End System Model, packets sent out an interface need 169 not necessarily have a source address configured on that interface, 170 and incoming packets whose destination does not correspond to the 171 physical interface through which it is received are accepted. 173 1.3. Overview 175 The integration of link indications with the Internet architecture 176 has a long history. Link status was first taken into account in 177 routing as 1969. In response to an attempt to send to a host that 178 was off-line, the ARPANET link layer protocol provided a "Destination 179 Dead" indication, described in "Fault Isolation and Recovery" 180 [RFC816]. Link-aware routing metrics also have a long history; the 181 ARPANET packet radio experiment [PRNET] incorporated frame loss in 182 the calculation of routing metrics, a precursor to more recent link- 183 aware routing metrics such as Expected Transmission Count (ETX), 184 described in "A High-Throughput Path Metric for Multi-Hop Wireless 185 Routing" [ETX]. 187 "Routing Information Protocol" [RFC1058] defines RIP, which is 188 descended from the Xerox Network Systems (XNS) Routing Information 189 Protocol. "The Open Shortest Path First Specification" [RFC1131] 190 defined OSPF, which uses Link State Advertisements (LSAs) in order to 191 flood information relating to link status within an OSPF area. While 192 these and other routing protocols can utilize "Link Up" and "Link 193 Down" indications provided by those links that support them, they 194 also can detect link loss based on loss of routing packets. As noted 195 in "Requirements for IP Version 4 Routers" [RFC1812]: 197 It is crucial that routers have workable mechanisms for 198 determining that their network connections are functioning 199 properly. Failure to detect link loss, or failure to take the 200 proper actions when a problem is detected, can lead to black 201 holes. 203 Attempts have also been made to define link indications other than 204 "Link Up" and "Link Down". "Dynamically Switched Link Control 205 Protocol" [RFC1307] defines an experimental protocol for control of 206 links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring 207 Down" and "Bring Up" states. 209 "A Generalized Model for Link Layer Triggers" [GenTrig] defines 210 "generic triggers", including "Link Up", "Link Down", "Link Going 211 Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger 212 Rollback", and "Better Signal Quality AP Available". IEEE 802.21 213 [IEEE-802.21] defines a Media Independent Handover Event Service 214 (MIH-ES) that provides event reporting relating to link 215 characteristics, link status, and link quality. Events defined 216 include "Link Down", "Link Up", "Link Going Down", "Link Signal 217 Strength" and "Link Signal/Noise Ratio". 219 Under ideal conditions, links in the "up" state experience low frame 220 loss in both directions and are immediately ready to send and receive 221 data frames; links in the "down" state are unsuitable for sending and 222 receiving data frames in either direction. 224 Unfortunately links frequently exhibit non-ideal behavior. Wired 225 links may fail in half-duplex mode, or exhibit partial impairment 226 resulting in intermediate loss rates. Wireless links may exhibit 227 asymmetry, intermittent frame loss or rapid changes in attainable 228 data rate due to interference or signal fading. In both wired and 229 wireless links, the link state may rapidly flap between the "up" and 230 "down" states. This real world behavior presents challenges to the 231 integration of link indications with the Internet, Transport and 232 Application layers. 234 1.4. Layered Indication Model 236 A layered indication model is shown in Figure 1 which includes both 237 internally generated link indications (such as link state and rate) 238 and indications arising from external interactions such as path 239 change detection. 241 In this model, it is assumed that the link layer provides indications 242 to higher layers primarily in the form of abstract indications that 243 are link-technology agnostic. 245 1.4.1. Internet Layer 247 One of the functions of the Internet layer is to shield higher layers 248 from the specifics of link behavior. As a result, the Internet layer 249 validates and filters link indications and selects outgoing and 250 incoming interfaces based on routing metrics. 252 The Internet layer composes its routing table based on information 253 available from local interfaces as well as potentially by taking into 254 account information provided by routers. This enables the state of 255 the local routing table to reflect link conditions on both local and 256 remote links. For example, prefixes to be added or removed from the 257 routing table may be determined from DHCP [RFC2131][RFC3315], Router 258 Advertisements [RFC1256][RFC2461], re-direct messages or route 259 updates incorporating information on the state of links multiple hops 260 away. 262 The Internet layer also utilizes link indications in order to 263 optimize aspects of Internet Protocol (IP) configuration and 264 mobility. After receipt of a "Link Up" indication, hosts validate 265 potential IP configurations by Detecting Network Attachment (DNA) 266 [RFC4436]. Once the IP configuration is confirmed, it may be 267 determined that an address change has occurred. However, "Link Up" 268 indications may not result in a change to Internet layer 269 configuration. 271 In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of 272 a "Link Up" indication, potential IP configurations are validated 273 using a bi-directional reachability test. In "Detecting Network 274 Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is 275 validated using reachability detection and Router 276 Solicitation/Advertisement. 278 The routing sub-layer may utilize link indications in order to enable 279 more rapid response to changes in link state and effective 280 throughput. 282 In "Analysis of link failures in an IP backbone" [Iannaccone] the 283 authors investigate link failures in Sprint's IP backbone. They 284 identify the causes of convergence delay, including delays in 285 detection of whether an interface is down or up. While it is fastest 286 for a router to utilize link indications if available, there are 287 situations in which it is necessary to depend on loss of routing 288 packets to determine the state of the link. Once the link state has 289 been determined, a delay may occur within the routing protocol in 290 order to dampen link flaps. Finally, another delay may be introduced 291 in propagating the link state change, in order to rate limit link 292 state advertisements, and guard against instability. 294 "Bidirectional Forwarding Detection" [BFD] notes that link layers may 295 provide only limited failure indications, and that relatively slow 296 "Hello" mechanisms are used in routing protocols to detect failures 297 when no link layer indications are available. This results in 298 failure detection times of the order of a second, which is too long 299 for some applications. The authors describe a mechanism that can be 300 used for liveness detection over any media, enabling rapid detection 301 of failures in the path between adjacent forwarding engines. A path 302 is declared operational when bi-directional reachability has been 303 confirmed. 305 Link rate is often used in computing routing metrics. For wired 306 networks, the rate is typically constant. However for wireless 307 networks, the negotiated rate and frame loss may change with link 308 conditions so that effective throughput may vary on a packet by 309 packet basis. In such situations, routing metrics may also exhibit 310 rapid variation. 312 Routing metrics incorporating link indications such as Link Up/Down 313 and effective throughput enable routers to take link conditions into 314 account for the purposes of route selection. If a link experiences 315 decreased rate or high frame loss, the route metric will increase for 316 the prefixes that it serves, encouraging use of alternate paths if 317 available. When the link condition improves, the route metric will 318 decrease, encouraging use of the link. 320 Within Weak End System implementations, changes in routing metrics 321 and link state may result in a change in the outgoing interface for 322 one or more transport connections. Routes may also be added or 323 withdrawn, resulting in loss or gain of peer connectivity. However, 324 link indications such as changes in link rate or frame loss do not 325 necessarily result in a change of outgoing interface. 327 The Internet layer may also become aware of path changes by other 328 mechanisms, such as by running a routing protocol, receipt of a 329 Router Advertisement, dead gateway detection [RFC816] or network 330 unreachability detection [RFC2461], ICMP re-directs, or a change in 331 the IP TTL of received packets. A change in the outgoing interface 332 may in turn influence the mobility sub-layer, causing a change in the 333 incoming interface. The mobility sub-layer may also become aware of 334 a change in the incoming interface of a peer (via receipt of a Mobile 335 IP binding update). 337 1.4.2. Transport Layer 339 The Transport layer processes link indications differently for the 340 purposes of transport parameter estimation and connection management. 342 For the purposes of parameter estimation, the Transport layer is 343 primarily interested in path properties that impact performance, and 344 where link indications may be determined to be relevant to path 345 properties they may be utilized directly. Link indications such 346 "Link Up"/"Link Down" or changes in rate, delay and frame loss may 347 prove relevant. This will not always be the case, however; where the 348 bottleneck bandwidth is already much lower than the link rate, an 349 increase in link rate may not materially affect path properties. As 350 described in Appendix A.3, the algorithms for utilizing link layer 351 indications to improve transport parameter estimates are still under 352 development. 354 For the purposes of transport parameter estimation, strict layering 355 considerations do not apply since they may hide useful information. 356 For example, the Transport layer may utilize the receipt of a "Link 357 Down" indication followed by a subsequent "Link Up" indication to 358 infer the possibility of non-congestive packet loss during the period 359 between the indications, even if the IP configuration does not change 360 as a result, so that no Internet layer indication would be sent. 362 For the purposes of parameter estimation, the Transport layer may 363 also wish to use Internet layer indications. For example, path 364 change indications can be used as a signal to reset parameter 365 estimates. Changes in the routing table may also be useful; loss of 366 segments sent to a destination with no prefix in the routing table 367 may be assumed to be due to causes other than congestion, regardless 368 of the reason for the removal (either because local link conditions 369 caused it to be removed or because the route was withdrawn by a 370 remote router). 372 For the purposes of connection management, layering considerations 373 are important; the Transport layer typically only utilizes Internet 374 layer indications such as changes in the incoming/outgoing interface 375 and IP configuration changes. 377 Just as a "Link Up" event may not result in a configuration change, 378 and a configuration change may not result in connection teardown, the 379 Transport layer does not tear down connections on receipt of a "Link 380 Down" indication, regardless of the cause. Where the "Link Down" 381 indication results from frame loss rather than an explicit exchange, 382 the indication may be transient, to be soon followed by a "Link Up" 383 indication. 385 Even where the "Link Down" indication results from an explicit 386 exchange such as receipt of a Point-to-Point Protocol (PPP) Link 387 Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or 388 Deauthenticate frame, an alternative point of attachment may be 389 available, allowing connectivity to be quickly restored. As a 390 result, robustness is best achieved by allowing connections to remain 391 up until an endpoint address changes, or the connection is torn down 392 due to lack of response to repeated retransmission attempts. 394 For the purposes of connection management, the Transport layer is 395 cautious with the use of Internet layer indications as well. Changes 396 in the routing table are not relevant for the purposes of connection 397 management, since it is desirable for connections to remain up during 398 transitory routing flaps. The Transport layer may utilize a change 399 in incoming/outgoing change as a path change indication, or tear down 400 transport connections due to invalidation of a connection endpoint IP 401 address. Where the connection has been established based on the home 402 address, a change in the care-of-address need not result in 403 connection teardown, since the configuration change is masked by the 404 mobility functionality within the Internet layer, and is therefore 405 transparent to the Transport layer. 407 "Requirements for Internet Hosts - Communication Layers" [RFC1122] 408 [RFC1122] Section 2.4 requires Destination Unreachable, Source 409 Quench, Echo Reply, Timestamp Reply and Time Exceeded ICMP messages 410 to be passed up to the Transport layer. [RFC1122] 4.2.3.9 requires 411 TCP to react to an ICMP Source Quench by slowing transmission. 413 [RFC1122] Section 4.2.3.9 distinguishes between ICMP messages 414 indicating soft error conditions, which must not cause TCP to abort a 415 connection, and hard error conditions, which should cause an abort. 416 ICMP messages indicating soft error conditions include Destination 417 Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed), 418 which may result from routing transients; Time Exceeded; and 419 Parameter Problem. ICMP messages indicating hard error conditions 420 include Destination Unreachable codes 2 (Protocol Unreachable), 3 421 (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment 422 was Set). Since hosts implementing "Path MTU Discovery" [RFC1191] 423 use Destination Unreachable code 4, they do not treat this as a hard 424 error condition. 426 However, "Fault Isolation and Recovery" [RFC816], Section 6 states: 428 It is not obvious, when error messages such as ICMP Destination 429 Unreachable arrive, whether TCP should abandon the connection. 430 The reason that error messages are difficult to interpret is that, 431 as discussed above, after a failure of a gateway or network, there 432 is a transient period during which the gateways may have incorrect 433 information, so that irrelevant or incorrect error messages may 434 sometimes return. An isolated ICMP Destination Unreachable may 435 arrive at a host, for example, if a packet is sent during the 436 period when the gateways are trying to find a new route. To 437 abandon a TCP connection based on such a message arriving would be 438 to ignore the valuable feature of the Internet that for many 439 internal failures it reconstructs its function without any 440 disruption of the end points. 442 "Requirements for IP Version 4 Routers" [RFC1812] Section 4.3.3.3 443 states that "Research seems to suggest that Source Quench consumes 444 network bandwidth but is an ineffective (and unfair) antidote to 445 congestion", indicating that routers should not originate them. In 446 general, since the Transport layer is able to determine an 447 appropriate (and conservative) response to congestion based on packet 448 loss or explicit congestion notification, ICMP "source quench" 449 indications are not needed, and the sending of additional "source 450 quench" packets during periods of congestion may be detrimental. 452 "ICMP attacks against TCP" [Gont] argues that accepting ICMP messages 453 based on a correct four-tuple without additional security checks is 454 ill-advised. For example, an attacker forging an ICMP hard error 455 message can cause one or more transport connections to abort. The 456 authors discuss a number of precautions, including mechanisms for 457 validating ICMP messages and ignoring or delaying response to hard 458 error messages under various conditions. They also recommend that 459 hosts ignore ICMP Source Quench messages. 461 1.4.3. Application Layer 463 The Transport layer provides indications to the Application layer by 464 propagating Internet layer indications (such as IP address 465 configuration and changes), as well as providing its own indications, 466 such as connection teardown. The Transport layer may also provide 467 indications to the link layer. For example, where the link layer 468 retransmission timeout is significantly less than the path round-trip 469 timeout, the Transport layer may wish to control the maximum number 470 of times that a link layer frame may be retransmitted, so that the 471 link layer does not continue to retransmit after a Transport layer 472 timeout. 474 In IEEE 802.11, this can be achieved by adjusting the Management 475 Information Base (MIB) variables dot11ShortRetryLimit (default: 7) 476 and dot11LongRetryLimit (default: 4), which control the maximum 477 number of retries for frames shorter and longer in length than 478 dot11RTSThreshold, respectively. However, since these variables 479 control link behavior as a whole they cannot be used to separately 480 adjust behavior on a per-transport connection basis. In situations 481 where the link layer retransmission timeout is of the same order as 482 the path round trip timeout, link layer control may not be possible 483 at all. 485 Since applications can typically obtain the information they need 486 more reliably from the Internet and Transport layers, they will 487 typically not need to utilize link indications. A "Link Up" 488 indication implies that the link is capable of communicating IP 489 packets, but does not indicate that it has been configured; 490 applications should use an Internet layer "IP Address Configured" 491 event instead. "Link Down" indications are typically not useful to 492 applications, since they can be rapidly followed by a "Link Up" 493 indication; applications should respond to Transport layer teardown 494 indications instead. Similarly, changes in the link rate may not be 495 relevant to applications if the bottleneck bandwidth does not change; 496 the transport layer is best equipped to determine this. As a result, 497 Figure 1 does not indicate link indications being provided directly 498 to applications. 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Application | | 502 Layer | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 ^ ^ ^ 505 ! ! ! 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+ 507 | ! ! ! | 508 | ! ^ ^ | 509 | Connection Management ! ! Teardown | 510 Transport | ! ! | 511 Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+ 512 | ^ ! | 513 | Rate ! | 514 | ! | 515 | Transport Parameter Estimation ! | 516 |(MTU, RTT, RTO, cwnd, bw, ssthresh)! | 517 +-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ 518 ^ ^ ^ ^ ! 519 ! ! ! ! ! 520 +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 521 | ! ! Incoming !MIP ! ! | 522 | ! ! Interface !BU ! ! | 523 | ! ! Change !Receipt! ! | 524 | ! ^ ^ ^ ^ | 525 Internet | ! ! Mobility ! ! ! | 526 Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 527 | ! ! Outgoing ! Path ! ! | 528 | ! ! Interface ! Change! ! | 529 | ! ^ Change ^ ^ ^ | 530 | ! ! ! | 531 | ^ Routing ! ! | 532 +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 533 | ! ! ! IP | 534 | ! ! ! Address | 535 | ! IP Configuration ^ ^ Config/ | 536 | ! ! Changes | 537 +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ 538 ! ! 539 ! ! 540 +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ 541 | ! ! | 542 Link | ^ ^ | 543 Layer | Rate, FER, Link | 544 | Delay Up/Down | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 1. Layered Indication Model 549 2. Architectural Considerations 551 The complexity of real-world link behavior poses a challenge to the 552 integration of link indications within the Internet architecture. 553 While the literature provides persuasive evidence of the utility of 554 link indications, difficulties can arise in making effective use of 555 them. To avoid these issues, the following architectural principles 556 are suggested and discussed in more detail in the sections that 557 follow: 559 [1] Proposals should avoid use of simplified link models in 560 circumstances where they do not apply (Section 2.1). 562 [2] Link indications should be clearly defined, so that it is 563 understood when they are generated on different link layers 564 (Section 2.2). 566 [3] Proposals must demonstrate robustness against spurious link 567 indications (Section 2.3). 569 [4] Upper layers should utilize a timely recovery step so as to limit 570 the potential damage from link indications determined to be invalid 571 after they have been acted on (Section 2.3.2). 573 [5] Proposals must demonstrate that effective congestion control is 574 maintained (Section 2.4). 576 [6] Proposals must demonstrate the effectiveness of proposed 577 optimizations (Section 2.5). 579 [7] Link indications should not be required by upper layers, in order 580 to maintain link independence (Section 2.6). 582 [8] Proposals should avoid race conditions, which can occur where link 583 indications are utilized directly by multiple layers of the stack 584 (Section 2.7). 586 [9] Proposals should avoid inconsistencies between link and routing 587 layer metrics (Section 2.7.3). 589 [10] Overhead reduction schemes must avoid compromising interoperability 590 and introducing link layer dependencies into the Internet and 591 Transport layers (Section 2.8). 593 [11] Proposals for transport of link indications beyond the local host 594 need to carefully consider the layering, security and transport 595 implications (Section 2.9). 597 2.1. Model Validation 599 Proposals should avoid use of link models in circumstances where they 600 do not apply. 602 In "The mistaken axioms of wireless-network research" [Kotz], the 603 authors conclude that mistaken assumptions relating to link behavior 604 may lead to the design of network protocols that may not work in 605 practice. For example, the authors note that the three-dimensional 606 nature of wireless propagation can result in large signal strength 607 changes over short distances. This can result in rapid changes in 608 link indications such as rate, frame loss, and signal strength. 610 In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], 611 the authors provide examples of modeling mistakes and examples of how 612 to improve modeling of link characteristics. To accompany the paper 613 the authors provide simulation scenarios in ns-2. 615 In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], 616 documents that describe capabilities that are dependent on link 617 indications should explicitly articulate the assumptions of the link 618 model and describe the circumstances in which they apply. 620 Generic "trigger" models may include implicit assumptions which may 621 prove invalid in outdoor or mesh wireless LAN deployments. For 622 example, two-state Markov models assume that the link is either in a 623 state experiencing low frame loss ("up") or in a state where few 624 frames are successfully delivered ("down"). In these models, 625 symmetry is also typically assumed, so that the link is either "up" 626 in both directions or "down" in both directions. In situations where 627 intermediate loss rates are experienced, these assumptions may be 628 invalid. 630 As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev] 631 signal strength data is noisy and sometimes inconsistent, so that it 632 needs to be filtered in order to avoid erratic results. Given this, 633 link indications based on raw signal strength data may be unreliable. 634 In order to avoid problems, it is best to combine signal strength 635 data with other techniques. For example, in developing a "Going 636 Down" indication for use with [IEEE-802.21] it would be advisable to 637 validate filtered signal strength measurements with other indications 638 of link loss such as lack of beacon reception. 640 2.2. Clear Definitions 642 Link indications should be clearly defined, so that it is understood 643 when they are generated on different link layers. For example, 644 considerable work has been required in order to come up with the 645 definitions of "Link Up" and "Link Down", and to define when these 646 indications are sent on various link layers. 648 Link indication definitions should heed the following advice: 650 [1] Do not assume symmetric link performance or frame loss that is 651 either low ("up") or high ("down"). 653 In wired networks, links in the "up" state typically experience low 654 frame loss in both directions and are ready to send and receive 655 data frames; links in the "down" state are unsuitable for sending 656 and receiving data frames in either direction. Therefore, a link 657 providing a "Link Up" indication will typically experience low 658 frame loss in both directions, and high frame loss in any direction 659 can only be experienced after a link provides a "Link Down" 660 indication. However, these assumptions may not hold true for 661 wireless LAN networks. Asymmetry is typically less of a problem 662 for cellular networks where propagation occurs over longer 663 distances, multipath effects may be less severe and the base 664 station can transmit at much higher power than mobile stations 665 while utilizing a more sensitive antenna. 667 Specifications utilizing a "Link Up" indication should not assume 668 that receipt of this indication means that the link is experiencing 669 symmetric link conditions or low frame loss in either direction. 670 In general, a "Link Up" event should not be sent due to transient 671 changes in link conditions, but only due to a change in link layer 672 state. It is best to assume that a "Link Up" event may not be sent 673 in a timely way. Large handoff latencies can result in a delay in 674 the generation of a "Link Up" event as movement to an alternative 675 point of attachment is delayed. 677 [2] Consider the sensitivity of link indications to transient link 678 conditions. Due to common effects such as multi-path interference, 679 signal strength and signal/noise ratio (SNR) may vary rapidly over 680 a short distance, causing erratic behavior of link indications 681 based on unfiltered measurements. As noted in [Haratcherev], 682 signal strength may prove most useful when utilized in combination 683 with other measurements, such as frame loss. 685 [3] Where possible, design link indications with built-in damping. By 686 design, the "Link Up" and "Link Down" events relate to changes in 687 the state of the link layer that make it able and unable to 688 communicate IP packets. These changes are either generated by the 689 link layer state machine based on link layer exchanges (e.g. 690 completion of the IEEE 802.11i four-way handshake for "Link Up", or 691 receipt of a PPP LCP-Terminate for "Link Down") or by protracted 692 frame loss, so that the link layer concludes that the link is no 693 longer usable. As a result, these link indications are typically 694 less sensitive to changes in transient link conditions. 696 [4] Do not assume that a "Link Down" event will be sent at all, or that 697 if sent, that it will be received in a timely way. A good link 698 layer implementation will both rapidly detect connectivity failure 699 (such as by tracking missing Beacons) while sending a "Link Down" 700 event only when it concludes the link is unusable, not due to 701 transient frame loss. 703 However, existing wireless LAN implementations often do not do a 704 good job of detecting link failure. During a lengthy detection 705 phase, a "Link Down" event is not sent by the link layer, yet IP 706 packets cannot be transmitted or received on the link. Initiation 707 of a scan may be delayed so that the station cannot find another 708 point of attachment. This can result in inappropriate backoff of 709 retransmission timers within the transport layer, among other 710 problems. This is not as much of a problem for cellular networks 711 which utilize transmit power adjustment. 713 2.3. Robustness 715 Link indication proposals must demonstrate robustness against 716 misleading indications. Elements to consider include: 718 a. Implementation Variation 719 b. Recovery from invalid indications 720 c. Damping and hysteresis 722 2.3.1. Implementation Variation 724 Variations in link layer implementations may have a substantial 725 impact on the behavior of link indications. These variations need to 726 be taken into account in evaluating the performance of proposals. 727 For example, radio propagation and implementation differences can 728 impact the reliability of Link indications. 730 In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] 731 the authors analyze the cause of frame loss in a 38-node urban multi- 732 hop IEEE 802.11 ad-hoc network. In most cases, links that are very 733 bad in one direction tend to be bad in both directions, and links 734 that are very good in one direction tend to be good in both 735 directions. However, 30 percent of links exhibited loss rates 736 differing substantially in each direction. 738 As described in [Aguayo], wireless LAN links often exhibit loss rates 739 intermediate between "up" (low loss) and "down" (high loss) states, 740 as well as substantial asymmetry. As a result, receipt of a "Link 741 Up" indication may not necessarily indicate bi-directional 742 reachability, since it could have been generated after exchange of 743 small frames at low rates, which might not imply bi-directional 744 connectivity for large frames exchanged at higher rates. 746 Where multi-path interference or hidden nodes are encountered, signal 747 strength may vary widely over a short distance. Several techniques 748 may be used to reduce potential disruptions. Multiple antennas may 749 be used to reduce multi-path effects; rate adaptation can be used to 750 determine if a lower rate will be more satisfactory; transmit power 751 adjustment can be used to improve signal quality and reduce 752 interference; RTS/CTS signaling can be used to address hidden node 753 problems. However, these techniques may not be completely effective. 754 As a result, periods of high frame loss may be encountered, causing 755 the link to cycle between "up" and "down" states. 757 To improve robustness against spurious link indications, it is 758 recommended that upper layers treat the indication as a "hint" 759 (advisory in nature), rather than a "trigger" forcing a given action. 760 Upper layers may then attempt to validate the hint. 762 In [RFC4436] "Link Up" indications are rate limited and IP 763 configuration is confirmed using bi-directional reachability tests 764 carried out coincident with a request for configuration via DHCP. As 765 a result, bi-directional reachability is confirmed prior to 766 activation of an IP configuration. However, where a link exhibits an 767 intermediate loss rate, demonstration of bi-directional reachability 768 may not necessarily indicate that the link is suitable for carrying 769 IP data packets. 771 Another example of validation occurs in IPv4 Link-Local address 772 configuration [RFC3927]. Prior to configuration of an IPv4 Link- 773 Local address, it is necessary to run a claim and defend protocol. 774 Since a host needs to be present to defend its address against 775 another claimant, and address conflicts are relatively likely, a host 776 returning from sleep mode or receiving a "Link Up" indication could 777 encounter an address conflict were it to utilize a formerly 778 configured IPv4 Link-Local address without rerunning claim and 779 defend. 781 2.3.2. Recovery From Invalid Indications 783 In some situations, improper use of link indications can result in 784 operational malfunctions. It is recommended that upper layers 785 utilize a timely recovery step so as to limit the potential damage 786 from link indications determined to be invalid after they have been 787 acted on. 789 In [RFC4436] reachability tests are carried out coincident with a 790 request for configuration via DHCP. Therefore if the bi-directional 791 reachability test times out, the host can still obtain an IP 792 configuration via DHCP, and if that fails, the host can still 793 continue to use an existing valid address if it has one. 795 Where a proposal involves recovery at the transport layer, the 796 recovered transport parameters (such as the MTU, RTT, RTO, congestion 797 window, etc.) should be demonstrated to remain valid. Congestion 798 window validation is discussed in [RFC2861]. 800 Where timely recovery is not supported, unexpected consequences may 801 result. As described in [RFC3927], early IPv4 Link-Local 802 implementations would wait five minutes before attempting to obtain a 803 routable address after assigning an IPv4 Link-Local address. In one 804 implementation, it was observed that where mobile hosts changed their 805 point of attachment more frequently than every five minutes, they 806 would never obtain a routable address. 808 The problem was caused by an invalid link indication (signaling of 809 "Link Up" prior to completion of link layer authentication), 810 resulting in an initial failure to obtain a routable address using 811 DHCP. As a result, [RFC3927] recommends against modification of the 812 maximum retransmission timeout (64 seconds) provided in [RFC2131]. 814 2.3.3. Damping and Hysteresis 816 Damping and hysteresis can be utilized to limit damage from unstable 817 link indications. This may include damping unstable indications or 818 placing constraints on the frequency of link indication-induced 819 actions within a time period. 821 While [Aguayo] found that frame loss was relatively stable for 822 stationary stations, obstacles to radio propagation and multi-path 823 interference can result in rapid changes in signal strength for a 824 mobile station. As a result, it is possible for mobile stations to 825 encounter rapid changes in link performance, including changes in the 826 negotiated rate, frame loss and even "Link Up"/"Link Down" 827 indications. 829 Where link-aware routing metrics are implemented, this can result in 830 rapid metric changes, potentially resulting in frequent changes in 831 the outgoing interface for Weak End System implementations. As a 832 result, it may be necessary to introduce route flap dampening. 834 However, the benefits of damping need to be weighed against the 835 additional latency that can be introduced. For example, in order to 836 filter out spurious "Link Down" indications, these indications may be 837 delayed until it can be determined that a "Link Up" indication will 838 not follow shortly thereafter. However, in situations where multiple 839 Beacons are missed such a delay may not be needed, since there is no 840 evidence of a suitable point of attachment in the vicinity. 842 In some cases it is desirable to ignore link indications entirely. 843 Since it is possible for a host to transition from an ad-hoc network 844 to a network with centralized address management, a host receiving a 845 "Link Up" indication cannot necessarily conclude that it is 846 appropriate to configure a IPv4 Link-Local address prior to 847 determining whether a DHCP server is available [RFC3927] or an 848 operable configuration is valid [RFC4436]. 850 As noted in Section 1.4, the Transport layer does not utilize "Link 851 Up" and "Link Down" indications for the purposes of connection 852 management. 854 2.4. Congestion Control 856 Link indication proposals must demonstrate that effective congestion 857 control is maintained [RFC2914]. One or more of the following 858 techniques may be utilized: 860 [a] Rate limiting. Packets generated based on receipt of link 861 indications can be rate limited (e.g. a limit of one packet per 862 end-to-end path RTO). 864 [b] Utilization of upper layer indications. Applications should 865 depend on upper layer indications such as IP address 866 configuration/change notification, rather than utilizing link 867 indications such as "Link Up". 869 [c] Keepalives. In order to improve robustness against spurious link 870 indications, an application keepalive or Transport layer 871 indication (such as connection teardown) can be used instead of 872 consuming "Link Down" indications. 874 [d] Conservation of resources. Proposals must demonstrate that they 875 are not vulnerable to congestive collapse. 877 Note that "conservation of packets" may not be sufficient to avoid 878 congestive collapse in the link layer. Where rate adjustment is 879 based on frame loss, it is necessary to demonstrative stability in 880 the face of congestion. Implementations that rapidly decrease the 881 negotiated rate in response to frame loss can cause congestive 882 collapse in the link layer, even where exponential backoff is 883 implemented. For example, an implementation that decreases rate by a 884 factor of two while backing off the retransmission timer by a factor 885 of two has not reduced the link utilization. While such an 886 implementation might demonstrate "conservation of packets" it does 887 not conserve transmission resources. 889 Consider a proposal where a "Link Up" indication is used by a host to 890 trigger retransmission of the last previously sent packet, in order 891 to enable ACK reception prior to expiration of the host's 892 retransmission timer. On a rapidly moving mobile node where "Link 893 Up" indications follow in rapid succession, this could result in a 894 burst of retransmitted packets, violating the principle of 895 "conservation of packets". 897 At the Application layer, link indications have been utilized by 898 applications such as Presence [RFC2778] in order to optimize 899 registration and user interface update operations. For example, 900 implementations may attempt presence registration on receipt of a 901 "Link Up" indication, and presence de-registration by a surrogate 902 receiving a "Link Down" indication. Presence implementations using 903 "Link Up"/"Link Down" indications this way violate the principle of 904 "conservation of packets" since link indications can be generated on 905 a time scale less than the end-to-end path RTO. The problem is 906 magnified since for each presence update, notifications can be 907 delivered to many watchers. In addition, use of a "Link Up" 908 indication in this manner is unwise since the interface may not yet 909 even have an operable Internet layer configuration. Instead, an "IP 910 address configured" indication may be utilized. 912 2.5. Effectiveness 914 Proposals must demonstrate the effectiveness of proposed 915 optimizations. Since optimizations typically carry a burden of 916 increased complexity, substantial performance improvement is required 917 in order to make a compelling case. 919 In the face of unreliable link indications, effectiveness may 920 strongly depend on the penalty for false positives and false 921 negatives. In the case of DNAv4 [RFC4436], the benefits of 922 successful optimization are modest, but the penalty for being unable 923 to confirm an operable configuration is a lengthy timeout. As a 924 result, the recommended strategy is to test multiple potential 925 configurations in parallel in addition to attempting configuration 926 via DHCP. This virtually guarantees that DNAv4 will always result in 927 performance equal to or better than use of DHCP alone. 929 2.6. Interoperability 931 While link indications can be utilized where available, they should 932 not be required by upper layers, in order to maintain link layer 933 independence. For example, if link layer prefix hints are provided, 934 hosts not understanding those hints must still be able to obtain an 935 IP address. 937 Where link indications are proposed to optimize Internet layer 938 configuration, proposals must demonstrate that they do not compromise 939 robustness by interfering with address assignment or routing protocol 940 behavior, making address collisions more likely, or compromising 941 Duplicate Address Detection (DAD). 943 To avoid compromising interoperability in the pursuit of performance 944 optimization, proposals must demonstrate that interoperability 945 remains possible (potentially with degraded performance) even if one 946 or more participants do not implement the proposal. 948 2.7. Race Conditions 950 Link indication proposals should avoid race conditions, which can 951 occur where link indications are utilized directly by multiple layers 952 of the stack. 954 Link indications are useful for optimization of Internet Protocol 955 layer addressing and configuration as well as routing. Although "The 956 BU-trigger method for improving TCP performance over Mobile IPv6" 957 [Kim] describes situations in which link indications are first 958 processed by the Internet Protocol layer (e.g. MIPv6) before being 959 utilized by the Transport layer, for the purposes of parameter 960 estimation, it may be desirable for the Transport layer to utilize 961 link indications directly. Similarly, as noted in "Application- 962 oriented Link Adaptation of IEEE 802.11" [Haratcherev2] there are 963 situations in which applications may also wish to consume link 964 indications. 966 In situations where the Weak End System model is implemented, a 967 change of outgoing interface may occur at the same time the Transport 968 layer is modifying transport parameters based on other link 969 indications. As a result, transport behavior may differ depending on 970 the order in which the link indications are processed. 972 Where a multi-homed host experiences increasing frame loss or 973 decreased rate on one of its interfaces, a routing metric taking 974 these effects into account will increase, potentially causing a 975 change in the outgoing interface for one or more transport 976 connections. This may trigger Mobile IP signaling so as to cause a 977 change in the incoming path as well. As a result, the transport 978 parameters for the original interface (MTU, congestion state) may no 979 longer be valid for the new outgoing and incoming paths. 981 To avoid race conditions, the following measures are recommended: 983 a. Path change re-estimation 984 b. Layering 985 c. Metric consistency 987 2.7.1. Path Change Re-estimation 989 When the Internet layer detects a path change, such as a change in 990 the outgoing or incoming interface of the host or the incoming 991 interface of a peer, or perhaps even a substantial change in the TTL 992 of received IP packets, it may be worth considering whether to reset 993 transport parameters (RTT, RTO, cwnd, MTU) to their initial values so 994 as to allow them to be re-estimated. This ensures that estimates 995 based on the former path do not persist after they have become 996 invalid. Appendix A.3 summarizes the research on this topic. 998 2.7.2. Layering 1000 Another technique to avoid race conditions is to rely on layering to 1001 damp transient link indications and provide greater link layer 1002 independence. 1004 The Internet layer is responsible for routing as well as IP 1005 configuration, and mobility, providing higher layers with an 1006 abstraction that is independent of link layer technologies. Since 1007 one of the major objectives of the Internet layer is maintaining link 1008 layer independence, upper layers relying on Internet layer 1009 indications rather than consuming link indications directly can avoid 1010 link layer dependencies. 1012 In general, it is advisable for applications to utilize indications 1013 from the Internet or Transport layers rather than consuming link 1014 indications directly. 1016 2.7.3. Metric Consistency 1018 Proposals should avoid inconsistencies between link and routing layer 1019 metrics. Without careful design, potential differences between link 1020 indications used in routing and those used in roaming and/or link 1021 enablement can result in instability, particularly in multi-homed 1022 hosts. 1024 Once a link is in the "up" state, its effectiveness in transmission 1025 of data packets can be used to determine an appropriate routing 1026 metric. In situations where the transmission time represents a large 1027 portion of the total transit time, minimizing total transmission time 1028 is equivalent to maximizing effective throughput. "A High-Throughput 1029 Path Metric for Multi-Hop Wireless Routing" [ETX] describes a 1030 proposed routing metric based on the Expected Transmission Count 1031 (ETX). The authors demonstrate that ETX, based on link layer frame 1032 loss rates (prior to retransmission), enables the selection of routes 1033 maximizing effective throughput. Where the negotiated rate is 1034 constant, the expected transmission time is proportional to ETX, so 1035 that minimizing ETX also minimizes expected transmission time. 1037 However, where the negotiated rate may vary, ETX may not represent a 1038 good estimate of the estimated transmission time. In "Routing in 1039 multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors 1040 define a new metric called Expected Transmission Time (ETT). This is 1041 described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S 1042 is the size of the probe packet and B is the bandwidth of the link as 1043 measured by a packet pair [Morgan]. However, ETT assumed that the 1044 loss fraction of small probe frames sent at 1 Mbps data rate is 1045 indicative of the loss fraction of larger data frames at higher 1046 rates, which tends to under-estimate the ETT at higher rates, where 1047 frame loss typically increases. In "A Radio Aware Routing Protocol 1048 for Wireless Mesh Networks" [ETX-Radio] the authors refine the ETT 1049 metric further by estimating the loss fraction as a function of data 1050 rate. 1052 However, prior to sending data packets over the link, the appropriate 1053 routing metric may not be easily be predicted. As noted in 1054 [Shortest], a link that can successfully transmit the short frames 1055 utilized for control, management or routing may not necessarily be 1056 able to reliably transport larger data packets. The rate adaptation 1057 techniques utilized in [Haratcherev] require data to be accumulated 1058 on signal strength and rates based on successful and unsuccessful 1059 transmissions. However, this data will not be available before a 1060 link is used for the first time. 1062 Therefore it may be necessary to utilize alternative metrics (such as 1063 signal strength or access point load) in order to assist in 1064 attachment/handoff decisions. However, unless the new interface is 1065 the preferred route for one or more destination prefixes, a Weak End 1066 System implementation will not use the new interface for outgoing 1067 traffic. Where "idle timeout" functionality is implemented, the 1068 unused interface will be brought down, only to be brought up again by 1069 the link enablement algorithm. 1071 Within the link layer, signal strength and frame loss may be used by 1072 a host to determine the optimum rate, as well as to determine when to 1073 select an alternative point of attachment. In order to enable 1074 stations to roam prior to encountering packet loss, studies such as 1075 "An experimental study of IEEE 802.11b handover performance and its 1076 effect on voice traffic" [Vatn] have suggested using signal strength 1077 as a mechanism for more rapidly detecting loss of connectivity, 1078 rather than frame loss, as suggested in "Techniques to Reduce IEEE 1079 802.11b MAC Layer Handover Time" [Velayos]. 1081 [Aguayo] notes that signal strength and distance are not good 1082 predictors of frame loss or negotiated rate, due to the potential 1083 effects of multi-path interference. As a result a link brought up 1084 due to good signal strength may subsequently exhibit significant 1085 frame loss, and a low negotiated rate. Similarly, an AP 1086 demonstrating low utilization may not necessarily be the best choice, 1087 since utilization may be low due to hardware or software problems. 1088 "OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link 1089 utilization-based routing metrics have a history of instability, so 1090 that they are rarely deployed. 1092 2.8. Layer compression 1094 In many situations, the exchanges required for a host to complete a 1095 handoff and reestablish connectivity are considerable, leading to 1096 proposals to combine exchanges occurring within multiple layers in 1097 order to reduce overhead. While overhead reduction is a laudable 1098 goal, proposals need to avoid compromising interoperability and 1099 introducing link layer dependencies into the Internet and Transport 1100 layers. 1102 Exchanges required for handoff and connectivity reestablishment may 1103 include link layer scanning, authentication and association 1104 establishment; Internet layer configuration, routing and mobility 1105 exchanges; Transport layer retransmission and recovery; security 1106 association re-establishment; application protocol re-authentication 1107 and re-registration exchanges, etc. 1109 Several proposals involve combining exchanges within the link layer. 1110 For example, in [EAPIKEv2], a link layer EAP exchange may be used for 1111 the purpose of IP address assignment, potentially bypassing Internet 1112 layer configuration. Within [PEAP], it is proposed that a link layer 1113 EAP exchange be used for the purpose of carrying Mobile IPv6 Binding 1114 Updates. [MIPEAP] proposes that EAP exchanges be used for 1115 configuration of Mobile IPv6. Where link, Internet or Transport 1116 layer mechanisms are combined, hosts need to maintain backward 1117 compatibility to permit operation on networks where compression 1118 schemes are not available. 1120 Layer compression schemes may also negatively impact robustness. For 1121 example, in order to optimize IP address assignment, it has been 1122 proposed that prefixes be advertised at the link layer, such as 1123 within the 802.11 Beacon and Probe Response frames. However, 1124 [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be 1125 assigned dynamically, so that prefix(es) advertised within the Beacon 1126 and/or Probe Response may not correspond to the prefix(es) configured 1127 by the Internet layer after the host completes link layer 1128 authentication. Were the host to handle IP configuration at the link 1129 layer rather than within the Internet layer, the host might be unable 1130 to communicate due to assignment of the wrong IP address. 1132 2.9. Transport of Link Indications 1134 Proposals for the transport of link indications need to carefully 1135 consider the layering, security and transport implications. 1137 As noted earlier, the transport layer may take the state of the local 1138 routing table into account in improving the quality of transport 1139 parameter estimates. For example, by utilizing the local routing 1140 table, the Transport layer can determine that segment loss was due to 1141 loss of a route, not congestion. While this enables transported link 1142 indications that affect the local routing table to improve the 1143 quality of transport parameter estimates, security and 1144 interoperability considerations relating to routing protocols still 1145 apply. 1147 Proposals involving transport of link indications need to demonstrate 1148 the following: 1150 [a] Superiority to implicit signals. In general, implicit signals are 1151 preferred to explicit transport of link indications since they do 1152 not require participation in the routing mesh, add no new packets 1153 in times of network distress, operate more reliably in the presence 1154 of middle boxes such as NA(P)Ts, are more likely to be backward 1155 compatible, and are less likely to result in security 1156 vulnerabilities. As a result, explicit signaling proposals must 1157 prove that implicit signals are inadequate. 1159 [b] Mitigation of security vulnerabilities. Transported link 1160 indications that modify the local routing table represent routing 1161 protocols, and unless security is provided they will introduce the 1162 vulnerabilities associated with unsecured routing protocols. For 1163 example, unless schemes such as SEND [RFC3971] are used, a host 1164 receiving a link indication from a router will not be able to 1165 authenticate the indication. Where indications can be transported 1166 over the Internet, this allows an attack to be launched without 1167 requiring access to the link. 1169 [c] Validation of transported indications. Even if a transported link 1170 indication can be authenticated, if the indication is sent by a 1171 host off the local link, it may not be clear that the sender is on 1172 the actual path in use, or which transport connection(s) the 1173 indication relates to. Proposals need to describe how the 1174 receiving host can validate the transported link indication. 1176 [d] Mapping of Identifiers. When link indications are transported, it 1177 is generally for the purposes of saying something about Internet, 1178 Transport or Application layer operations at a remote element. 1179 These layers use different identifiers, and so it is necessary to 1180 match the link indication with relevant higher layer state. 1181 Therefore proposals need to demonstrate how the link indication can 1182 be mapped to the right higher layer state. For example, if a 1183 presence server is receiving remote indications of "Link Up"/"Link 1184 Down" status for a particular MAC address, the presence server will 1185 need to associate that MAC address with the identity of the user 1186 (pres:user@example.com) to whom that link status change is 1187 relevant. 1189 3. Future Work 1191 Further work is needed in order to understand how link indications 1192 can be utilized by the Internet, Transport and Application layers. 1194 At the Link and Internet layers, more work is needed to reconcile 1195 handoff metrics (e.g. signal strength and link utilization) with 1196 routing metrics based on link indications (e.g. frame loss and 1197 negotiated rate). 1199 More work is also needed to understand the connection between link 1200 indications and routing metrics. For example, the introduction of 1201 block ACKs (supported in [IEEE-802.11e]) complicates the relationship 1202 between effective throughput and frame loss, which may necessitate 1203 the development of revised routing metrics for ad-hoc networks. 1205 A better understanding of the relationship between rate negotiation 1206 algorithms and link-layer congestion control is required. For 1207 example, it is possible that signal strength measurements may be 1208 useful in preventing rapid downward rate negotiation (and congestive 1209 collapse) in situations where frame loss is caused by congestion, not 1210 signal attenuation. 1212 At the Transport layer, more work is needed to determine the 1213 appropriate reaction to Internet layer indications such as routing 1214 table and path changes. For example, it may make sense for the 1215 Transport layer to adjust transport parameter estimates in response 1216 to route loss, "Link Up"/"Link Down" indications and/or frame loss. 1217 This way transport parameters are not adjusted as though congestion 1218 were detected when loss is occurring due to other factors such as 1219 radio propagation effects or loss of a route (such as can occur on 1220 receipt of a "Link Down" indication). 1222 More work is needed to determine how link layers may utilize 1223 information from the Transport layer. For example, it is undesirable 1224 for a link layer to retransmit so aggressively that the link layer 1225 round-trip time approaches that of the end-to-end transport 1226 connection. Instead, it may make sense to do downward rate 1227 adjustment so as to decrease frame loss and improve latency. Also, 1228 in some cases, the transport layer may not require heroic efforts to 1229 avoid frame loss; timely delivery may be preferred instead. 1231 More work is also needed on application layer uses of link 1232 indications such as rate and frame loss. 1234 4. Security Considerations 1236 Proposals for the utilization of link indications may introduce new 1237 security vulnerabilities. These include: 1239 Spoofing 1240 Indication validation 1241 Denial of service 1243 4.1. Spoofing 1245 Where link layer control frames are unprotected, they may be spoofed 1246 by an attacker. For example, PPP does not protect LCP frames such as 1247 LCP-Terminate, and [IEEE-802.11] does not protect management frames 1248 such as Associate/ Reassociate, Disassociate, or Deauthenticate. 1250 Spoofing of link layer control traffic may enable attackers to 1251 exploit weaknesses in link indication proposals. For example, 1252 proposals that do not implement congestion avoidance can be enable 1253 attackers to mount denial of service attacks. 1255 However, even where the link layer incorporates security, attacks may 1256 still be possible if the security model is not consistent. For 1257 example, wireless LANs implementing [IEEE-802.11i] do not enable 1258 stations to send or receive IP packets on the link until completion 1259 of an authenticated key exchange protocol known as the "4-way 1260 handshake". As a result, a link implementing [IEEE-802.11i] cannot 1261 be considered usable at the Internet layer ("Link Up") until 1262 completion of the authenticated key exchange. 1264 However, while [IEEE-802.11i] requires sending of authenticated 1265 frames in order to obtain a "Link Up" indication, it does not support 1266 management frame authentication. This weakness can be exploited by 1267 attackers to enable denial of service attacks on stations attached to 1268 distant Access Points (AP). 1270 In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends 1271 a Reassociation Response. At that point, the AP sends a spoofed 1272 frame with the station's source address to a multicast address, 1273 thereby causing switches within the Distribution System (DS) to learn 1274 the station's MAC address. While this enables forwarding of frames 1275 to the station at the new point of attachment, it also permits an 1276 attacker to disassociate a station located anywhere within the ESS, 1277 by sending an unauthenticated Reassociation Request frame. 1279 4.2. Indication Validation 1281 "Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts 1282 interact with routers for the purpose of fault recovery: 1284 Since the gateways always attempt to have a consistent and correct 1285 model of the internetwork topology, the host strategy for fault 1286 recovery is very simple. Whenever the host feels that something 1287 is wrong, it asks the gateway for advice, and, assuming the advice 1288 is forthcoming, it believes the advice completely. The advice 1289 will be wrong only during the transient period of negotiation, 1290 which immediately follows an outage, but will otherwise be 1291 reliably correct. 1293 In fact, it is never necessary for a host to explicitly ask a 1294 gateway for advice, because the gateway will provide it as 1295 appropriate. When a host sends a datagram to some distant net, 1296 the host should be prepared to receive back either of two advisory 1297 messages which the gateway may send. The ICMP "redirect" message 1298 indicates that the gateway to which the host sent the datagram is 1299 no longer the best gateway to reach the net in question. The 1300 gateway will have forwarded the datagram, but the host should 1301 revise its routing table to have a different immediate address for 1302 this net. The ICMP "destination unreachable" message indicates 1303 that as a result of an outage, it is currently impossible to reach 1304 the addressed net or host in any manner. On receipt of this 1305 message, a host can either abandon the connection immediately 1306 without any further retransmission, or resend slowly to see if the 1307 fault is corrected in reasonable time. 1309 Given today's security environment, it is inadvisable for hosts to 1310 act on indications provided by routers without careful consideration. 1311 As noted in "ICMP attacks against TCP" [Gont], existing ICMP error 1312 messages may be exploited by attackers in order to abort connections 1313 in progress, prevent setup of new connections, or reduce throughput 1314 of ongoing connections. Similar attacks may also be launched against 1315 the Internet layer via forging of ICMP redirects. 1317 Proposals for transported link indications need to demonstrate that 1318 they will not add a new set of similar vulnerabilities. Since 1319 transported link indications are typically unauthenticated, hosts 1320 receiving them may not be able to determine whether they are 1321 authentic, or even plausible. 1323 Where link indication proposals may respond to unauthenticated link 1324 layer frames, they should utilize upper layer security mechanisms, 1325 where possible. For example, even though a host might utilize an 1326 unauthenticated link layer control frame to conclude that a link has 1327 become operational, it can use SEND [RFC3971] or authenticated DHCP 1328 [RFC3118] in order to obtain secure Internet layer configuration. 1330 4.3. Denial of Service 1332 Link indication proposals need to be particularly careful to avoid 1333 enabling denial of service attacks that can be mounted at a distance. 1334 While wireless links are naturally vulnerable to interference, such 1335 attacks can only be perpetrated by an attacker capable of 1336 establishing radio contact with the target network. 1338 However, attacks that can be mounted from a distance, either by an 1339 attacker on another point of attachment within the same network, or 1340 by an off-link attacker, greatly expand the level of vulnerability. 1342 By enabling the transport of link indications, it is possible to 1343 transform an attack that might otherwise be restricted to attackers 1344 on the local link into one which can be executed across the Internet. 1346 Similarly, by integrating link indications with upper layers, 1347 proposals may enable a spoofed link layer frame to consume more 1348 resources on the host than might otherwise be the case. As a result, 1349 while it is important for upper layers to validate link indications, 1350 they should not expend excessive resources in doing so. 1352 Congestion control is not only a transport issue, it is also a 1353 security issue. In order to not provide leverage to an attacker, a 1354 single forged link layer frame should not elicit a magnified response 1355 from one or more hosts, either by generating multiple responses or a 1356 single larger response. For example, link indication proposals 1357 should not enable multiple hosts to respond to a frame with a 1358 multicast destination address. 1360 5. IANA Considerations 1362 This document has no actions for IANA. 1364 6. References 1366 6.1. Informative References 1368 [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July 1369 1982. 1371 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 1372 June 1988. 1374 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1375 Communication Layers", RFC 1122, October 1989. 1377 [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1378 1989. 1380 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1381 November 1990. 1383 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1384 Xerox PARC, September 1991. 1386 [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link 1387 Control Protocol", RFC 1307, March 1992. 1389 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1390 RFC 1661, July 1994. 1392 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1393 1812, June 1995. 1395 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. 1396 and E. Lear, "Address Allocation for Private Internets", 1397 RFC 1918, February 1996. 1399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1400 Requirement Levels", BCP 14, RFC 2119, March 1997. 1402 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1403 2131, March 1997. 1405 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1406 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1407 1998. 1409 [RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for 1410 Presence and Instant Messaging", RFC 2778, February 2000. 1412 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion 1413 Window Validation", RFC 2861, June 2000. 1415 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 1416 41, September 2000. 1418 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP 1419 Messages", RFC 3118, June 2001. 1421 [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol 1422 for IPv6 (DHCPv6)", RFC 3315, July 2003. 1424 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. 1425 and D. Gurle, "Session Initiation Protocol (SIP) 1426 Extension for Instant Messaging", RFC 3428, December 1427 2002. 1429 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1430 in IPv6", RFC 3775, June 2004. 1432 [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence 1433 protocol (XMPP): Instant Messaging and Presence", RFC 1434 3921, October 2004. 1436 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic 1437 Configuration of Link-Local IPv4 Addresses", RFC 3927, 1438 May 2005. 1440 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 1441 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1443 [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram 1444 Congestion Control Protocol (DCCP)", RFC 4340, March 1445 2006. 1447 [RFC4436] Aboba, B., Carlson, J. and S. Cheshire, "Detecting 1448 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 1449 2006. 1451 [Alimian] Alimian, A., "Roaming Interval Measurements", 1452 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 1453 802.11 submission (work in progress), March 2004. 1455 [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R. 1456 Morris, "Link-level Measurements from an 802.11b Mesh 1457 Network", SIGCOMM '04, September 2004, Portland, Oregon. 1459 [Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan, 1460 "Improving Performance of TCP over Wireless Networks", 1461 Proceedings of the 1997 International Conference on 1462 Distributed Computer Systems, Baltimore, May 1997. 1464 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding 1465 Detection", draft-ietf-bfd-base-05.txt, Internet draft 1466 (work in progress), June 2006. 1468 [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses 1469 from Wireless Losses Using Interarrival Times at the 1470 Receiver", Proc. IEEE Symposium on Application-Specific 1471 Systems and Software Engineering and Technology, 1472 Richardson, TX, Mar 1999. 1474 [Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R. 1475 Prakash, "A Feedback-Based Scheme for Improving TCP 1476 Performance in Ad-Hoc Wireless Networks", Proceedings of 1477 the 18th International Conference on Distributed 1478 Computing Systems (ICDCS), Amsterdam, May 1998. 1480 [DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6 1481 (DNAv6)", draft-ietf-dna-protocol-03.txt, Internet draft 1482 (work in progress), October 2006. 1484 [E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link- 1485 Up' Notification", draft-dawkins-trigtran-linkup-01.txt, 1486 Internet draft (work in progress), October 2003. 1488 [EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, 1489 Y., and F. Bersani, "EAP IKEv2 Method", draft-tschofenig- 1490 eap-ikev2-12.txt, Internet draft (work in progress), 1491 October 2006. 1493 [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis 1494 of the Error Characteristics of an In-Building Wireless 1495 Network", SIGCOMM '96, August 1996, Stanford, CA. 1497 [Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion 1498 Control for Mobility", Technical Report CR-2005-213838, 1499 NASA Glenn Research Center, July 2005. 1501 [Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions 1502 for Immediate Retransmissions", draft-eggert-tcpm-tcp- 1503 retransmit-now-02.txt, Internet draft (work in progress), 1504 June 2005. 1506 [Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive 1507 Transport-Layer Interfaces", MobiArch '06, San Francisco, 1508 CA. 1510 [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and 1511 Robert Morris, "A High-Throughput Path Metric for Multi- 1512 Hop Wireless Routing", Proceedings of the 9th ACM 1513 International Conference on Mobile Computing and 1514 Networking (MobiCom '03), San Diego, California, 1515 September 2003. 1517 [ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi- 1518 radio, multi-hop wireless mesh networks", Proceedings of 1519 ACM MobiCom Conference, September 2003. 1521 [ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M. and M. Srivastava, "A 1522 Radio Aware Routing Protocol for Wireless Mesh Networks", 1523 UCLA Computer Science Department, Los Angeles, CA 1525 [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link 1526 Layer Triggers", submission to IEEE 802.21 (work in 1527 progress), March 2004, available at: 1528 http://www.ieee802.org/handoff/march04_meeting_docs/ 1529 Generalized_triggers-02.pdf 1531 [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over 1532 Wireless Links", Proceedings of TENCON'98, pages 332-335. 1533 IEEE, December 1998. 1535 [Gont] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm- 1536 icmp-attacks-01, Internet draft (work in progress), 1537 October 2006. 1539 [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers 1540 on Performance of TCP-Friendly Rate Control", to appear 1541 in ACM MCCR, 2004. 1543 [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for 1544 Transport Protocols", Computer Communications Review 1545 (CCR) 34, 2 (2003). 1547 [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H. 1548 Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, 1549 October 1, 2004, Philadelphia, Pennsylvania, USA 1551 [Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation 1552 for IEEE 802.11", Ph.D. Thesis, Technical University of 1553 Delft, Netherlands, ISBN-10:90-9020513-6, 1554 ISBN-13:978-90-9020513-7, March 2006. 1556 [HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation 1557 Protocol (HMP)", draft-lee-hmp-00.txt, Internet draft 1558 (work in progress), October 2003. 1560 [Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance 1561 over Mobile Ad Hoc Networks", Proceedings of the Fifth 1562 International Conference on Mobile Computing and 1563 Networking, pages 219-230. ACM/IEEE, Seattle, August 1564 1999. 1566 [Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S. 1567 and C. Diot, "Analysis of link failures in an IP 1568 backbone", Proc. of ACM Sigcomm Internet Measurement 1569 Workshop, November, 2002. 1571 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 1572 and Metropolitan Area Networks: Port-Based Network Access 1573 Control", IEEE Standard 802.1X, December 2004. 1575 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 1576 "Wireless LAN Medium Access Control (MAC) and Physical 1577 Layer (PHY) Specifications", IEEE Standard 802.11, 2003. 1579 [IEEE-802.11e] Institute of Electrical and Electronics Engineers, 1580 "Standard for Telecommunications and Information Exchange 1581 Between Systems - LAN/MAN Specific Requirements - Part 1582 11: Wireless LAN Medium Access Control (MAC) and Physical 1583 Layer (PHY) Specifications - Amendment 8: Medium Access 1584 Control (MAC) Quality of Service Enhancements", IEEE 1585 802.11e, November 2005. 1587 [IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE 1588 Trial-Use Recommended Practice for Multi-Vendor Access 1589 Point Interoperability via an Inter-Access Point Protocol 1590 Across Distribution Systems Supporting IEEE 802.11 1591 Operation", IEEE 802.11F, June 2003 (now deprecated). 1593 [IEEE-802.11i] Institute of Electrical and Electronics Engineers, 1594 "Supplement to Standard for Telecommunications and 1595 Information Exchange Between Systems - LAN/MAN Specific 1596 Requirements - Part 11: Wireless LAN Medium Access 1597 Control (MAC) and Physical Layer (PHY) Specifications: 1598 Specification for Enhanced Security", IEEE 802.11i, July 1599 2004. 1601 [IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft 1602 Amendment to Telecommunications and Information Exchange 1603 Between Systems - LAN/MAN Specific Requirements - Part 1604 11: Wireless LAN Medium Access Control (MAC) and Physical 1605 Layer (PHY) Specifications - Amendment 7: Radio Resource 1606 Management", IEEE 802.11k/D7.0, January 2007. 1608 [IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft 1609 Standard for Telecommunications and Information Exchange 1610 Between Systems - LAN/MAN Specific Requirements - Part 1611 21: Media Independent Handover", IEEE 802.21D0, June 1612 2005. 1614 [Kamerman] Kamerman, A. and L. Monteban, "Wavelan ii: A 1615 highperformance wireless lan for unlicensed band", Bell 1616 Labs Technical Journal, 1997. 1618 [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger 1619 method for improving TCP performance over Mobile IPv6", 1620 draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in 1621 progress), August 2004. 1623 [Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms 1624 of wireless-network research", Dartmouth College Computer 1625 Science Technical Report TR2003-467, July 2003. 1627 [Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C. and 1628 M. Allman, "Explicit Transport Error Notification (ETEN) 1629 for Error-Prone Wireless and Satellite Networks", 1630 Computer Networks, 46 (3), October 2004. 1632 [Lacage] Lacage, M., Manshaei, M. and T. Turletti, "IEEE 802.11 1633 Rate Adaptation: A Practical Approach", MSWiM '04, 1634 October 4-6, 2004, Venezia, Italy. 1636 [Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics 1637 Information for Mobile IP", draft-daniel-mip-link- 1638 characteristic-03.txt, Internet draft (work in progress), 1639 January 2007. 1641 [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for 1642 TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1643 1999. 1645 [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. 1646 and M. Laurent-Maknavicius, "MIPv6 Authorization and 1647 Configuration based on EAP", draft-giaretta- 1648 mip6-authorization-eap-04.txt, Internet draft (work in 1649 progress), October 2006. 1651 [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical 1652 Analysis of the IEEE 802.11 MAC Layer Handoff Process", 1653 CS-TR-4395, University of Maryland Department of Computer 1654 Science, September 2002. 1656 [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - 1657 Buffer Requirements and Overload Performance", Technical 1658 Memorandum, AT&T Bell Laboratoies, October 1994. 1660 [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 1661 with 802.11", draft-mun-mobileip-layer2-handoff- 1662 mipv4-01.txt, Internet draft (work in progress), March 1663 2004. 1665 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 1666 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 1667 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet 1668 draft (work in progress), October 2004. 1670 [Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers 1671 Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS 1672 Example", draft-daniel-mip6-optimized-vertical- 1673 handover-00.txt, July 2004. 1675 [Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for 1676 IEEE802.11 WLAN via received signal strength 1677 measurement", IEEE International Conference on 1678 Communications, 2003 (ICC '03), volume 2, pages 1679 1108-1113, Anchorage, Alaska, USA, May 2003. 1681 [PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network 1682 protocols", Proceedings of the IEEE, 75(1), January 1987. 1684 [Qiao] Qiao D., Choi, S., Jain, A. and Kang G. Shin, "MiSer: An 1685 Optimal Low-Energy Transmission Strategy for IEEE 802.11 1686 a/h", in Proc. ACM MobiCom'03, San Diego, CA, September 1687 2003. 1689 [RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC 1690 Protocol for Multi-Hop Wireless Networks", Proceedings 1691 ACM MOBICOM, July 2001. 1693 [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast 1694 Handoff for 802.11 Infrastructure Networks", Proceedings 1695 of the IEEE InfoCon 2005, March 2005. 1697 [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation 1698 for Disconnecting Networks", ACM SIGCOMM Computer 1699 Communication Review, 33(5), October 2003. 1701 [Schuetz] Schutz, S., Eggert, L., Schmid, S. and M. Brunner, 1702 "Protocol Enhancements for Intermittently Connected 1703 Hosts", ACM SIGCOMM Computer Communications Review, 1704 Volume 35, Number 2, July 2005. 1706 [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. 1707 Chambers and Robert Morris, "Performance of Multihop 1708 Wireless Networks: Shortest Path is Not Enough", 1709 Proceedings of the First Workshop on Hot Topics in 1710 Networking (HotNets-I), Princeton, New Jersey, October 1711 2002. 1713 [TRIGTRAN] Dawkins, S., Williams, C. and A. Yegin, "Framework and 1714 Requirements for TRIGTRAN", draft-dawkins-trigtran- 1715 framework-00.txt, Internet draft (work in progress), 1716 August 2003. 1718 [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover 1719 performance and its effect on voice traffic", TRITA-IMIT- 1720 TSLAB R 03:01, KTH Royal Institute of Technology, 1721 Stockholm, Sweden, July 2003. 1723 [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 1724 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, 1725 KTH Royal Institute of Technology, Stockholm, Sweden, 1726 April 2003. 1728 [Vertical] Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient 1729 Mobility Management for Vertical Handoff between WWAN and 1730 WLAN", IEEE Communications Magazine, November 2003. 1732 [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", 1733 draft-ietf-ospf-omp-02.txt, Internet draft (work in 1734 progress), February 1999. 1736 [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to 1737 Enhancing Internet Performance over Wireless Links", 1738 Ph.D. thesis, University of California at San Diego, 1739 1999. 1741 [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- 1742 l2-triggers-00.txt, Internet Draft (work in progress), 1743 June 2002. 1745 Appendix A - Literature Review 1747 This Appendix summarizes the literature with respect to link 1748 indications on wireless local area networks. 1750 A.0 Terminology 1752 Access Point (AP) 1753 A station that provides access to the fixed network (e.g. an 802.11 1754 Distribution System), via the wireless medium (WM) for associated 1755 stations. 1757 Beacon 1758 A control message broadcast by a station (typically an Access 1759 Point), informing stations in the neighborhood of its continuing 1760 presence, possibly along with additional status or configuration 1761 information. 1763 Binding Update (BU) 1764 A message indicating a mobile node's current mobility binding, and 1765 in particular its care-of address. 1767 Correspondent Node 1768 A peer node with which a mobile node is communicating. The 1769 correspondent node may be either mobile or stationary. 1771 Mobile Node 1772 A node that can change its point of attachment from one link to 1773 another, while still being reachable via its home address. 1775 Station (STA) 1776 Any device that contains an IEEE 802.11 conformant medium access 1777 control (MAC) and physical layer (PHY) interface to the wireless 1778 medium (WM). 1780 A.1 Link Layer 1782 The characteristics of wireless links have been found to vary 1783 considerably depending on the environment. 1785 In "Performance of Multihop Wireless Networks: Shortest Path is Not 1786 Enough" [Shortest] the authors studied the performance of both an 1787 indoor and outdoor mesh network. By measuring inter-node throughput, 1788 the best path between nodes was computed. The throughput of the best 1789 path was compared with the throughput of the shortest path computed 1790 based on a hop-count metric. In almost all cases, the shortest path 1791 route offered considerably lower throughput than the best path. 1793 In examining link behavior, the authors found that rather than 1794 exhibiting a bi-modal distribution between "up" (low loss rate) and 1795 "down" (high loss rates), many links exhibited intermediate loss 1796 rates. Asymmetry was also common, with 30 percent of links 1797 demonstrating substantial differences in the loss rates in each 1798 direction. As a result, on wireless networks the measured throughput 1799 can differ substantially from the negotiated rate due to 1800 retransmissions, and successful delivery of routing packets is not 1801 necessarily an indication that the link is useful for delivery of 1802 data. 1804 In "Measurement and Analysis of the Error Characteristics of an In- 1805 Building Wireless Network" [Eckhardt], the authors characterize the 1806 performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in 1807 Infrastructure mode on the Carnegie-Mellon Campus. In this study, 1808 very low frame loss was experienced. As a result, links could either 1809 be assumed to operate very well or not at all. 1811 "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] the 1812 authors analyze the causes of frame loss in a 38-node urban multi-hop 1813 802.11 ad-hoc network. In most cases, links that are very bad in 1814 one direction tend to be bad in both directions, and links that are 1815 very good in one direction tend to be good in both directions. 1816 However, 30 percent of links exhibited loss rates differing 1817 substantially in each direction. 1819 Signal to noise ratio and distance showed little value in predicting 1820 loss rates, and rather than exhibiting a step-function transition 1821 between "up" (low loss) or "down" (high loss) states, inter-node 1822 loss rates varied widely, demonstrating a nearly uniform distribution 1823 over the range at the lower rates. The authors attribute the 1824 observed effects to multi-path fading, rather than attenuation or 1825 interference. 1827 The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of 1828 link conditions observed in practice. While for indoor 1829 infrastructure networks site surveys and careful measurement can 1830 assist in promoting ideal behavior, in ad-hoc/mesh networks node 1831 mobility and external factors such as weather may not be easily 1832 controlled. 1834 Considerable diversity in behavior is also observed due to 1835 implementation effects. "Techniques to reduce IEEE 802.11b MAC layer 1836 handover time" [Velayos] measured handover times for a stationary STA 1837 after the AP was turned off. This study divided handover times into 1838 detection (determination of disconnection from the existing point of 1839 attachment) search (discovery of alternative attachment points), and 1840 execution phases (connection to an alternative point of attachment). 1842 These measurements indicated that the duration of the detection phase 1843 (the largest component of handoff delay) is determined by the number 1844 of non-acknowledged frames triggering the search phase and delays due 1845 to precursors such as RTS/CTS and rate adaptation. 1847 Detection behavior varied widely between implementations. For 1848 example, NICs designed for desktops attempted more retransmissions 1849 prior to triggering search as compared with laptop designs, since 1850 they assumed that the AP was always in range, regardless of whether 1851 the Beacon was received. 1853 The study recommends that the duration of the detection phase be 1854 reduced by initiating the search phase as soon as collisions can be 1855 excluded as the cause of non-acknowledged transmissions; the authors 1856 recommend three consecutive transmission failures as the cutoff. 1857 This approach is both quicker and more immune to multi-path 1858 interference than monitoring of the S/N ratio. Where the STA is not 1859 sending or receiving frames, it is recommended that Beacon reception 1860 be tracked in order to detect disconnection, and that Beacon spacing 1861 be reduced to 60 ms in order to reduce detection times. In order to 1862 compensate for more frequent triggering of the search phase, the 1863 authors recommend algorithms for wait time reduction, as well as 1864 interleaving of search and data frame transmission. 1866 "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" 1867 [Mishra] investigates handoff latencies obtained with three mobile 1868 STAs implementations communicating with two APs. The study found 1869 that there is large variation in handoff latency among STA and AP 1870 implementations and that implementations utilize different message 1871 sequences. For example, one STA sends a Reassociation Request prior 1872 to authentication, which results in receipt of a Deauthenticate 1873 message. The study divided handoff latency into discovery, 1874 authentication and reassociation exchanges, concluding that the 1875 discovery phase was the dominant component of handoff delay. Latency 1876 in the detection phase was not investigated. 1878 "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" 1879 [Ramani] weighs the pros and cons of active versus passive scanning. 1880 The authors point out the advantages of timed beacon reception, which 1881 had previously been incorporated into [IEEE-802.11k]. Timed beacon 1882 reception allows the station to continually keep up to date on the 1883 signal/noise ratio of neighboring APs, allowing handoff to occur 1884 earlier. Since the station does not need to wait for initial and 1885 subsequent responses to a broadcast Probe Response (MinChannelTime 1886 and MaxChannelTime, respectively), performance is comparable to what 1887 is achievable with 802.11k Neighbor Reports and unicast Probe 1888 Requests. 1890 The authors measure the channel switching delay, the time it takes to 1891 switch to a new frequency, and begin receiving frames. Measurements 1892 ranged from 5 ms to 19 ms per channel; where timed Beacon reception 1893 or interleaved active scanning is used, switching time contributes 1894 significantly to overall handoff latency. The authors propose 1895 deployment of APs with Beacons synchronized via NTP, enabling a 1896 driver implementing SyncScan to work with legacy APs without 1897 requiring implementation of new protocols. The authors measure the 1898 distribution of inter-arrival times for stations implementing 1899 SyncScan, with excellent results. 1901 "Roaming Interval Measurements" [Alimian] presents data on stationary 1902 STAs after the AP signal has been shut off. This study highlighted 1903 implementation differences in rate adaptation as well as detection, 1904 scanning and handoff. As in [Velayos], performance varied widely 1905 between implementations, from half an order of magnitude variation in 1906 rate adaptation to an order of magnitude difference in detection 1907 times, two orders of magnitude in scanning, and one and a half orders 1908 of magnitude in handoff times. 1910 "An experimental study of IEEE 802.11b handoff performance and its 1911 effect on voice traffic" [Vatn] describes handover behavior observed 1912 when the signal from AP is gradually attenuated, which is more 1913 representative of field experience than the shutoff techniques used 1914 in [Velayos]. Stations were configured to initiate handover when 1915 signal strength dipped below a threshold, rather than purely based on 1916 frame loss, so that they could begin handover while still connected 1917 to the current AP. It was noted that stations continue to receive 1918 data frames during the search phase. Station-initiated 1919 Disassociation and pre-authentication were not observed in this 1920 study. 1922 A.1.1 Link Indications 1924 Within a link layer, the definition of "Link Up" and "Link Down" may 1925 vary according to the deployment scenario. For example, within PPP 1926 [RFC1661], either peer may send an LCP-Terminate frame in order to 1927 terminate the PPP link layer, and a link may only be assumed to be 1928 usable for sending network protocol packets once NCP negotiation has 1929 completed for that protocol. 1931 Unlike PPP, IEEE 802 does not include facilities for network layer 1932 configuration, and the definition of "Link Up" and "Link Down" varies 1933 by implementation. Empirical evidence suggests that the definition 1934 of "Link Up" and "Link Down" may depend on whether the station is 1935 mobile or stationary, whether infrastructure or ad-hoc mode is in 1936 use, and whether security and Inter-Access Point Protocol (IAPP) is 1937 implemented. 1939 Where a STA encounters a series of consecutive non-acknowledged 1940 frames while having missed one or more beacons, the most likely cause 1941 is that the station has moved out of range of the AP. As a result, 1942 [Velayos] recommends that the station begin the search phase after 1943 collisions can be ruled out; since this approach does not take rate 1944 adaptation into account, it may be somewhat aggressive. Only when no 1945 alternative workable rate or point of attachment is found is a "Link 1946 Down" indication returned. 1948 In a stationary point-to-point installation, the most likely cause of 1949 an outage is that the link has become impaired, and alternative 1950 points of attachment may not be available. As a result, 1951 implementations configured to operate in this mode tend to be more 1952 persistent. For example, within 802.11 the short interframe space 1953 (SIFS) interval may be increased and MIB variables relating to 1954 timeouts (such as dot11AuthenticationResponseTimeout, 1955 dot11AssociationResponseTimeout, dot11ShortRetryLimit, and 1956 dot11LongRetryLimit) may be set to larger values. In addition a 1957 "Link Down" indication may be returned later. 1959 In IEEE 802.11 ad-hoc mode with no security, reception of data frames 1960 is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a 1961 result, reception of data frames is enabled at any time, and no 1962 explicit "Link Up" indication exists. 1964 In Infrastructure mode, IEEE 802.11-2003 enables reception of data 1965 frames only in State 3 ("Authenticated" and "Associated"). As a 1966 result, a transition to State 3 (e.g. completion of a successful 1967 Association or Reassociation exchange) enables sending and receiving 1968 of network protocol packets and a transition from State 3 to State 2 1969 (reception of a "Disassociate" frame) or State 1 (reception of a 1970 "Deauthenticate" frame) disables sending and receiving of network 1971 protocol packets. As a result, IEEE 802.11 stations typically signal 1972 "Link Up" on receipt of a successful Association/Reassociation 1973 Response. 1975 As described within [IEEE-802.11F], after sending a Reassociation 1976 Response, an Access Point will send a frame with the station's source 1977 address to a multicast destination. This causes switches within the 1978 Distribution System (DS) to update their learning tables, readying 1979 the DS to forward frames to the station at its new point of 1980 attachment. Were the AP to not send this "spoofed" frame, the 1981 station's location would not be updated within the distribution 1982 system until it sends its first frame at the new location. Thus the 1983 purpose of spoofing is to equalize uplink and downlink handover 1984 times. This enables an attacker to deny service to authenticated and 1985 associated stations by spoofing a Reassociation Request using the 1986 victim's MAC address, from anywhere within the ESS. Without 1987 spoofing, such an attack would only be able to disassociate stations 1988 on the AP to which the Reassociation Request was sent. 1990 The signaling of "Link Down" is considerably more complex. Even 1991 though a transition to State 2 or State 1 results in the station 1992 being unable to send or receive IP packets, this does not necessarily 1993 imply that such a transition should be considered a "Link Down" 1994 indication. In an infrastructure network, a station may have a 1995 choice of multiple access points offering connection to the same 1996 network. In such an environment, a station that is unable to reach 1997 State 3 with one access point may instead choose to attach to another 1998 access point. Rather than registering a "Link Down" indication with 1999 each move, the station may instead register a series of "Link Up" 2000 indications. 2002 In [IEEE-802.11i] forwarding of frames from the station to the 2003 distribution system is only feasible after the completion of the 2004 4-way handshake and group-key handshake, so that entering State 3 is 2005 no longer sufficient. This has resulted in several observed 2006 problems. For example, where a "Link Up" indication is triggered on 2007 the station by receipt of an Association/Reassociation Response, DHCP 2008 [RFC2131] or RS/RA may be triggered prior to when the link is usable 2009 by the Internet layer, resulting in configuration delays or failures. 2010 Similarly, Transport layer connections will encounter packet loss, 2011 resulting in back-off of retransmission timers. 2013 A.1.2 Smart Link Layer Proposals 2015 In order to improve link layer performance, several studies have 2016 investigated "smart link layer" proposals. 2018 In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the 2019 authors describe how the GSM reliable and unreliable link layer modes 2020 can be simultaneously utilized without higher layer control. Where a 2021 reliable link layer protocol is required (where reliable transports 2022 such TCP and SCTP are used), the Radio Link Protocol (RLP) can be 2023 engaged; with delay sensitive applications such as those based on 2024 UDP, the transparent mode (no RLP) can be used. The authors also 2025 describe how PPP negotiation can be optimized over high latency GSM 2026 links using "Quickstart-PPP". 2028 In "Link Layer Based TCP Optimisation for Disconnecting Networks" 2029 [Scott], the authors describe performance problems that occur with 2030 reliable transport protocols facing periodic network disconnections, 2031 such as those due to signal fading or handoff. The authors define a 2032 disconnection as a period of connectivity loss that exceeds a 2033 retransmission timeout, but is shorter than the connection lifetime. 2034 One issue is that link-unaware senders continue to backoff during 2035 periods of disconnection. The authors suggest that a link-aware 2036 reliable transport implementation halt retransmission after receiving 2037 a "Link Down" indication. Another issue is that on reconnection the 2038 lengthened retransmission times cause delays in utilizing the link. 2040 To improve performance, a "smart link layer" is proposed, which 2041 stores the first packet that was not successfully transmitted on a 2042 connection, then retransmits it upon receipt of a "Link Up" 2043 indication. Since a disconnection can result in hosts experiencing 2044 different network conditions upon reconnection, the authors do not 2045 advocate bypassing slowstart or attempting to raise the congestion 2046 window. Where IPsec is used and connections cannot be differentiated 2047 because transport headers are not visible, the first untransmitted 2048 packet for a given sender and destination IP address can be 2049 retransmitted. In addition to looking at retransmission of a single 2050 packet per connection, the authors also examined other schemes such 2051 as retransmission of multiple packets and rereception of single or 2052 multiple packets. 2054 In general, retransmission schemes were superior to rereception 2055 schemes, since rereception cannot stimulate fast retransmit after a 2056 timeout. Retransmission of multiple packets did not appreciably 2057 improve performance over retransmission of a single packet. Since 2058 the focus of the research was on disconnection rather than just lossy 2059 channels, a two state Markov model was used, with the "up" state 2060 representing no loss, and the "down" state representing one hundred 2061 percent loss. 2063 In "Multi Service Link Layers: An Approach to Enhancing Internet 2064 Performance over Wireless Links" [Xylomenos], the authors use ns-2 to 2065 simulate the performance of various link layer recovery schemes (raw 2066 link without retransmission, go back N, XOR based FEC, selective 2067 repeat, Karn's RLP, out of sequence RLP and Berkeley Snoop) in stand- 2068 alone file transfer, web browsing and continuous media distribution. 2069 While selective repeat and Karn's RLP provide the highest throughput 2070 for file transfer and web browsing scenarios, continuous media 2071 distribution requires a combination of low delay and low loss and the 2072 out of sequence RLP performed best in this scenario. Since the 2073 results indicate that no single link layer recovery scheme is optimal 2074 for all applications, the authors propose that the link layer 2075 implement multiple recovery schemes. Simulations of the multi- 2076 service architecture showed that the combination of a low-error rate 2077 recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme 2078 for UDP traffic (such as out of sequence RLP) provides for good 2079 performance in all scenarios. The authors then describe how a multi- 2080 service link layer can be integrated with Differentiated Services. 2082 In "Wavelan ii: A highperformance wireless lan for the unlicensed 2083 band" [Kamerman] the authors propose a rate adaptation algorithm 2084 (ARF) in which the sender adjusts the rate upwards after a fixed 2085 number of successful transmissions, and adjusts the rate downwards 2086 after one or two consecutive failures. If after an upwards rate 2087 adjustment the transmission fails, the rate is immediately readjusted 2088 downwards. 2090 In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks" 2091 [RBAR] the authors propose a rate adaptation approach that requires 2092 incompatible changes to the IEEE 802.11 MAC. In order to enable the 2093 sender to better determine the transmission rate, the receiver 2094 determines the packet length and Signal/Noise Ratio (SNR) of a 2095 received RTS frame and calculates the corresponding rate based on a 2096 theoretical channel model, rather than channel usage statistics. The 2097 recommended rate is sent back in the CTS frame. This allows the rate 2098 (and potentially the transmit power) to be optimized on each 2099 transmission, albeit at the cost of requiring RTS/CTS for every frame 2100 transmission. 2102 In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 2103 802.11 a/h" [Qiao] the authors propose a scheme for optimizing 2104 transmit power. The proposal mandates the use of RTS/CTS in order to 2105 deal with hidden nodes, requiring that CTS and ACK frames be sent at 2106 full power. However, this approach also utilizes a theoretical model 2107 rather than determining the model based on channel usage statistics. 2109 In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage] the 2110 authors distinguish between low latency implementations which enable 2111 per-packet rate decisions, and high latency implementations which do 2112 not. The former implementations typically include dedicated CPUs in 2113 their design, enabling them to meet real-time requirements. The 2114 latter implementations are typically based on highly integrated 2115 designs in which the upper MAC is implemented on the host. As a 2116 result, due to operating system latencies the information required to 2117 make per-packet rate decisions may not be available in time. 2119 The authors propose an Adaptive ARF (AARF) algorithm for use with 2120 low-latency implementations. This enables rapid downward rate 2121 negotiation on failure to receive an ACK, while increasing the amount 2122 number of successful transmission required for upward rate 2123 negotiation. The AARF algorithm is therefore highly stable in 2124 situations where channel properties are changing slowly, but slow to 2125 adapt upwards when channel conditions improve. In order to test the 2126 algorithm, the authors utilized ns-2 simulations as well as 2127 implementing a version of AARF adapted to a high latency 2128 implementation, the AR 5212 chipset. The Multiband Atheros Driver 2129 for WiFi (MADWIFI) driver enables a fixed schedule of rates and 2130 retries to be provided when a frame is queued for transmission. The 2131 adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR), 2132 requests only one transmission at each of three rates, the last of 2133 which is the minimum available rate. This enables adaptation to 2134 short-term fluctuations in the channel with minimal latency. The 2135 AMRR algorithm provides performance considerably better than the 2136 existing Madwifi driver and close to that of the RBAR algorithm, 2137 while enabling practical implementation. 2139 In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal 2140 Strength Measurement" [Pavon], the authors propose an algorithm by 2141 which a STA adjusts the transmission rate based on a comparison of 2142 the received signal strength (RSS) from the AP with dynamically 2143 estimated threshold values for each transmission rate. Upon 2144 reception of a frame, the STA updates the average RSS, and on 2145 transmission the STA selects a rate and adjusts the RSS threshold 2146 values based on whether the transmission is successful or not. In 2147 order to validate the algorithm, the authors utilized an OPNET 2148 simulation without interference, and an ideal curve of bit error rate 2149 (BER) vs. signal/noise ratio (SNR) was assumed. Not surprisingly, 2150 the simulation results closely matched the maximum throughput 2151 achievable for a given signal/noise ratio, based on the ideal BER vs. 2152 SNR curve. 2154 In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors 2155 describe a hybrid technique utilizing Signal Strength Indication 2156 (SSI) data to constrain the potential rates selected by statistics- 2157 based automatic rate control. Statistics-based rate control 2158 techniques include: 2160 Maximum Throughput 2162 This technique, which was chosen as the statistics-based technique 2163 in the hybrid scheme, sends a fraction of data at adjacent rates 2164 in order to estimate which rate provides the maximum throughput. 2165 Since accurate estimation of throughput requires a minimum number 2166 of frames to be sent at each rate, and only a fraction of frames 2167 are utilized for this purpose, this technique adapts more slowly 2168 at lower rates; with 802.11b rates, the adaptation time scale is 2169 typically on the order of a second. Depending on how many rates 2170 are tested, this technique can enable adaptation beyond adjacent 2171 rates. 2173 Frame Error Rate (FER) Control 2175 This technique estimates the FER, attempting to keep it between a 2176 lower limit (if FER moves below, increase rate) and upper limit 2177 (if FER moves above, decrease rate). Since this technique can 2178 utilize all the transmitted data, it can respond faster than 2179 maximum throughput techniques. However, there is a tradeoff of 2180 reaction time versus FER estimation accuracy; at lower rates 2181 either reaction times slow or FER estimation accuracy will suffer. 2182 Since this technique only measures the FER at the current rate, it 2183 can only enable adaptation to adjacent rates. 2185 Retry-based 2187 This technique modifies FER control techniques by enabling rapid 2188 downward rate adaptation after a number (5-10) of unsuccessful re- 2189 transmissions. Since fewer packets are required, the sensitivity 2190 of reaction time to rate is reduced.. However, upward rate 2191 adaptation proceeds more slowly since it is based on collection of 2192 FERdata. This technique is limited to adaptation to adjacent 2193 rates. 2195 While statistics-based techniques are robust against short-lived 2196 link quality changes, they do not respond quickly to long-lived 2197 changes. By constraining the rate selected by statistics-based 2198 techniques based on ACK SSI versus rate data (not theoretical 2199 curves), more rapid link adaptation was enabled. In order to 2200 ensure rapid adaptation during rapidly varying conditions, the 2201 rate constraints are tightened when the SSI values are changing 2202 rapidly, encouraging rate transitions. The authors validated 2203 their algorithms by implementing a driver for the Atheros AR5000 2204 chipset, and then testing its response to insertion and removal 2205 from a microwave oven acting as a Faraday cage. The hybrid 2206 algorithm dropped many fewer packets than the maximum throughput 2207 technique by itself. 2209 In order to estimate the SSI of data at the receiver, the SSI of 2210 ACKs received at the sender was used. This approach did not 2211 require the receiver to provide the sender with the received SSI, 2212 so that it could be implemented without changing the IEEE 802.11 2213 MAC. This scheme assumes that transmit power remains constant on 2214 the sender and receiver and that channel properties in both 2215 directions vary slowly, so that the SSI of the received ACKs and 2216 sent data remain in proportion. Actual data was used to determine 2217 the relationship between the ACK SSI and rate, so that the 2218 proportion itself does not matter, just as long as it varies 2219 slowly. The authors checked the proportionality assumption and 2220 found that the SSI of received data correlated highly (74%) with 2221 the SSI of received ACKs. Low pass filtering and monotonicity 2222 constraints were applied to remove the considerable noise in the 2223 SSI versus rate curves. 2225 In "Efficient Mobility Management for Vertical Handoff between 2226 WWAN and WLAN" [Vertical] the authors propose use of signal 2227 strength and link utilization in order to optimize vertical 2228 handoff. WLAN to WWAN handoff is driven by SSI decay. When IEEE 2229 802.11 SSI falls below a threshold (S1), FFT-based decay detection 2230 is undertaken to determine if the signal is likely to continue to 2231 decay. If so, then handoff to the WWAN is initiated when the 2232 signal falls below the minimum acceptable level (S2). WWAN to 2233 WLAN handoff is driven by both PHY and MAC characteristics of the 2234 IEEE 802.11 target network. At the PHY layer, characteristics 2235 such as SSI are examined to determine if the signal strength is 2236 greater than a minimum value (S3); at the MAC layer the IEEE 2237 802.11 Network Allocation Vector (NAV) occupation is examined in 2238 order to estimate the maximum available bandwidth and mean access 2239 delay. Note that depending on the value of S3, it is possible for 2240 the negotiated rate to be less than the available bandwidth. In 2241 order to prevent premature handoff between WLAN and WWAN, S1 and 2242 S2 are separated by 6 dB; in order to prevent oscillation between 2243 WLAN and WWAN media, S3 needs to be greater than S1 by an 2244 appropriate margin. 2246 A.2 Internet Layer 2248 Within the Internet layer, proposals have been made for utilizing 2249 link indications to optimize IP configuration, to improve the 2250 usefulness of routing metrics, and to optimize aspects of Mobile 2251 IP handoff. 2253 In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host 2254 that has moved to a new point of attachment utilizes a bi- 2255 directional reachability test in parallel with DHCP [RFC2131] to 2256 rapidly reconfirm an operable configuration. 2258 In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 2259 802.11/GPRS Example" [Park] the authors propose that the mobile 2260 node send a router solicitation on receipt of a "Link Up" 2261 indication in order provide lower handoff latency than would be 2262 possible using generic movement detection [RFC3775]. The authors 2263 also suggest immediate invalidation of the Care-Of-Address (CoA) 2264 on receipt of a "Link Down" indication. However, this is 2265 problematic where a "Link Down" indication can be followed by a 2266 "Link Up" indication without a resulting change in IP 2267 configuration, as described in [RFC4436]. 2269 In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the 2270 authors suggest that MIPv4 Registration messages be carried within 2271 Information Elements of IEEE 802.11 Association/Reassociation 2272 frames, in order to minimize handoff delays. This requires 2273 modification to the mobile node as well as 802.11 APs. However, 2274 prior to detecting network attachment, it is difficult for the 2275 mobile node to determine whether the new point of attachment 2276 represents a change of network or not. For example, even where a 2277 station remains within the same ESS, it is possible that the 2278 network will change. Where no change of network results, sending 2279 a MIPv4 Registration message with each Association/Reassociation 2280 is unnecessary. Where a change of network results, it is 2281 typically not possible for the mobile node to anticipate its new 2282 CoA at Association/Reassociation; for example, a DHCP server may 2283 assign a CoA not previously given to the mobile node. When 2284 dynamic VLAN assignment is used, the VLAN assignment is not even 2285 determined until IEEE 802.1X authentication has completed, which 2286 is after Association/Reassociation in [IEEE-802.11i]. 2288 In "Link Characteristics Information for Mobile IP" [Lee], link 2289 characteristics are included in registration/binding update 2290 messages sent by the mobile node to the home agent and 2291 correspondent node. Where the mobile node is acting as a 2292 receiver, this allows the correspondent node to adjust its 2293 transport parameters window more rapidly than might otherwise be 2294 possible. Link characteristics that may be communicated include 2295 the link type (e.g. 802.11b, CDMA, GPRS, etc.) and link bandwidth. 2296 While the document suggests that the correspondent node should 2297 adjust its sending rate based on the advertised link bandwidth, 2298 this may not be wise in some circumstances. For example, where 2299 the mobile node link is not the bottleneck, adjusting the sending 2300 rate based on the link bandwidth could cause in congestion. Also, 2301 where link rates change frequently, sending registration messages 2302 on each rate change could by itself consume significant bandwidth. 2303 Even where the advertised link characteristics indicate the need 2304 for a smaller congestion window, it may be non-trivial to adjust 2305 the sending rates of individual connections where there are 2306 multiple connections open between a mobile node and correspondent 2307 node. A more conservative approach would be to trigger parameter 2308 re-estimation and slow start based on the receipt of a 2309 registration message or binding update. 2311 In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that 2312 MANET routing protocols have a tendency to concentrate traffic 2313 since they utilize shortest path metrics and allow nodes to 2314 respond to route queries with cached routes. The authors propose 2315 that nodes participating in an ad-hoc wireless mesh monitor local 2316 conditions such as MAC delay, buffer consumption and packets loss. 2317 Where congestion is detected, this is communicated to neighboring 2318 nodes via an IP option. In response to moderate congestion, nodes 2319 suppress route requests; where major congestion is detected, nodes 2320 throttle TCP connections flowing through them. The authors argue 2321 that for ad-hoc networks throttling by intermediate nodes is more 2322 effective than end-to-end congestion control mechanisms. 2324 A.3 Transport Layer 2326 Within the Transport layer, proposals have focused on countering 2327 the effects of handoff-induced packet loss and non-congestive loss 2328 caused by lossy wireless links. 2330 Where a mobile host moves to a new network, the transport 2331 parameters (including the RTT, RTO and congestion window) may no 2332 longer be valid. Where the path change occurs on the sender (e.g. 2333 change in outgoing or incoming interface), the sender can reset 2334 its congestion window and parameter estimates. However, where it 2335 occurs on the receiver, the sender may not be aware of the path 2336 change. 2338 In "The BU-trigger method for improving TCP performance over 2339 Mobile IPv6" [Kim], the authors note that handoff-related packet 2340 loss is interpreted as congestion by the Transport layer. In the 2341 case where the correspondent node is sending to the mobile node, 2342 it is proposed that receipt of a Binding Update by the 2343 correspondent node be used as a signal to the Transport layer to 2344 adjust cwnd and ssthresh values, which may have been reduced due 2345 to handoff-induced packet loss. The authors recommend that cwnd 2346 and ssthresh be recovered to pre-timeout values, regardless of 2347 whether the link parameters have changed. The paper does not 2348 discuss the behavior of a mobile node sending a Binding Update, in 2349 the case where the mobile node is sending to the correspondent 2350 node. 2352 In "Effect of Vertical Handovers on Performance of TCP-Friendly 2353 Rate Control" [Gurtov], the authors examine the effect of explicit 2354 handover notifications on TCP-friendly rate control. Where 2355 explicit handover notification includes information on the loss 2356 rate and throughput of the new link, this can be used to 2357 instantaneously change the transmission rate of the sender. The 2358 authors also found that resetting the TFRC receiver state after 2359 handover enabled parameter estimates to adjust more quickly. 2361 In "Adapting End Host Congestion Control for Mobility" [Eddy], the 2362 authors note that while MIPv6 with route optimization allows a 2363 receiver to communicate a subnet change to the sender via a 2364 Binding Update, this is not available within MIPv4. To provide a 2365 communication vehicle that can be universally employed, the 2366 authors propose a TCP option that allows a connection endpoint to 2367 inform a peer of a subnet change. The document does not advocate 2368 utilization of "Link Up" or "Link Down" events since these events 2369 are not necessarily indicative of subnet change. On detection of 2370 subnet change, it is advocated that the congestion window be reset 2371 to INIT_WINDOW and that transport parameters be re-estimated. The 2372 authors argue that recovery from slow start results in higher 2373 throughput both when the subnet change results in lower bottleneck 2374 bandwidth as well as when bottleneck bandwidth increases. 2376 In "Efficient Mobility Management for Vertical Handoff between 2377 WWAN and WLAN" [Vertical] the authors propose a "Virtual 2378 Connectivity Manager" which utilizes local connection translation 2379 (LCT) and a subscription/notification service supporting 2380 simultaneous movement in order to enable end-to-end mobility and 2381 maintain TCP throughput during vertical handovers. 2383 In an early draft of [RFC4340], a "Reset Congestion State" option 2384 was proposed in Section 4. This option was removed in part 2385 because the use conditions were not fully understood: 2387 An Half-Connection Receiver sends the Reset Congestion State 2388 option to its sender to force the sender to reset its 2389 congestion state -- that is, to "slow start", as if the 2390 connection were beginning again. 2391 ... The Reset Congestion State option is reserved for the 2392 very few cases when an endpoint knows that the congestion 2393 properties of a path have changed. Currently, this reduces to 2394 mobility: a DCCP endpoint on a mobile host MUST send Reset 2395 Congestion State to its peer after the mobile host changes 2396 address or path. 2398 "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses 2399 optimizations to recover earlier from a retransmission timeout 2400 incurred during a period in which an interface or intervening link 2401 was down. "End-to-end, Implicit 'Link-Up' Notification" 2402 [E2ELinkup] describes methods by which a TCP implementation that 2403 has backed off its retransmission timer due to frame loss on a 2404 remote link can learn that the link has once again become 2405 operational. This enables retransmission to be attempted prior to 2406 expiration of the backed off retransmission timer. 2408 "Link-layer Triggers Protocol" [Yegin] describes transport issues 2409 arising from lack of host awareness of link conditions on 2410 downstream Access Points and routers. Transport of link layer 2411 triggers is proposed to address the issue. 2413 "TCP Extensions for Immediate Retransmissions" [Eggert], describes 2414 how a Transport layer implementation may utilize existing "end-to- 2415 end connectivity restored" indications. It is proposed that in 2416 addition to regularly scheduled retransmissions that 2417 retransmission be attempted by the Transport layer on receipt of 2418 an indication that connectivity to a peer node may have been 2419 restored. End-to-end connectivity restoration indications include 2420 "Link Up", confirmation of first-hop router reachability, 2421 confirmation of Internet layer configuration, and receipt of other 2422 traffic from the peer. 2424 In "Discriminating Congestion Losses from Wireless Losses Using 2425 Interarrival Times at the Receiver" [Biaz], the authors propose a 2426 scheme for differentiating congestive losses from wireless 2427 transmission losses based on inter-arrival times. Where the loss 2428 is due to wireless transmission rather than congestion, congestive 2429 backoff and cwnd adjustment is omitted. However, the scheme 2430 appears to assume equal spacing between packets, which is not 2431 realistic in an environment exhibiting link layer frame loss. The 2432 scheme is shown to function well only when the wireless link is 2433 the bottleneck, which is often the case with cellular networks, 2434 but not with IEEE 802.11 deployment scenarios such as home or 2435 hotspot use. 2437 In "Improving Performance of TCP over Wireless Networks" [Bakshi], 2438 the authors focus on the performance of TCP over wireless networks 2439 with burst losses. The authors simulate performance of TCP Tahoe 2440 within ns-2, utilizing a two-state Markov model, representing 2441 "good" and "bad" states. Where the receiver is connected over a 2442 wireless link, the authors simulate the effect of an Explicit Bad 2443 State Notification (EBSN) sent by an access point unable to reach 2444 the receiver. In response to an EBSN, it is advocated that the 2445 existing retransmission timer be canceled and replaced by a new 2446 dynamically estimated timeout, rather than being backed off. In 2447 the simulations, EBSN prevents unnecessary timeouts, decreasing 2448 RTT variance and improving throughput. 2450 In "A Feedback-Based Scheme for Improving TCP Performance in Ad- 2451 Hoc Wireless Networks" [Chandran], the authors proposed an 2452 explicit Route Failure Notification (RFN), allowing the sender to 2453 stop its retransmission timers when the receiver becomes 2454 unreachable. On route reestablishment, a Route Reestablishment 2455 Notification (RRN) is sent, unfreezing the timer. Simulations 2456 indicate that the scheme significantly improves throughput and 2457 reduces unnecessary retransmissions. 2459 In "Analysis of TCP Performance over Mobile Ad Hoc Networks" 2460 [Holland], the authors explore how explicit link failure 2461 notification (ELFN) can improve the performance of TCP in mobile 2462 ad hoc networks. ELFN informs the TCP sender about link and route 2463 failures so that it need not treat the ensuing packet loss as due 2464 to congestion. Using an ns-2 simulation of TCP-Reno over 802.11 2465 with routing provided by the Dynamic Source Routing (DSR) 2466 protocol, it is demonstrated that TCP performance falls 2467 considerably short of expected throughput based on the percentage 2468 of the time that the network is partitioned. A portion of the 2469 problem was attributed to the inability of the routing protocol to 2470 quickly recognize and purge stale routes, leading to excessive 2471 link failures; performance improved dramatically when route 2472 caching was turned off. Interactions between the route request 2473 and transport retransmission timers were also noted. Where the 2474 route request timer is too large, new routes cannot be supplied in 2475 time to prevent the transport timer from expiring, and where the 2476 route request timer is too small, network congestion may result. 2477 For their implementation of ELFN, the authors piggybacked 2478 additional information on an existing "route failure" notice 2479 (sender and receiver addresses and ports, the TCP sequence number) 2480 to enable the sender to identify the affected connection. Where a 2481 TCP receives an ELFN, it disables the retransmission timer and 2482 enters "stand-by" mode, where packets are sent at periodic 2483 intervals to determine if the route has been reestablished. If an 2484 acknowledgment is received then the retransmission timers are 2485 restored. Simulations show that performance is sensitive to the 2486 probe interval, with intervals of 30 seconds or greater giving 2487 worse performance than TCP-Reno. The affect of resetting the 2488 congestion window and RTO values was also investigated. In the 2489 study, resetting congestion window to one did not have much of an 2490 effect on throughput, since the bandwidth/delay of the network was 2491 only a few packets. However, resetting the RTO to a high initial 2492 value (6 seconds) did have a substantial detrimental effect, 2493 particularly at high speed. In terms of the probe packet sent, 2494 the simulations showed little difference between sending the first 2495 packet in the congestion window, or retransmitting the packet with 2496 the lowest sequence number among those signaled as lost via the 2497 ELFNs. 2499 In "Improving TCP Performance over Wireless Links" [Goel], the 2500 authors propose use of an ICMP-DEFER message, sent by a wireless 2501 access point on failure of a transmission attempt. After 2502 exhaustion of retransmission attempts, an ICMP-RETRANSMIT message 2503 is sent. On receipt of an ICMP-DEFER message, the expiry of the 2504 retransmission timer is postponed by the current RTO estimate. On 2505 receipt of an ICMP-RETRANSMIT message, the segment is 2506 retransmitted. On retransmission, the congestion window is not 2507 reduced; when coming out of fast recovery, the congestion window 2508 is reset to its value prior to fast retransmission and fast 2509 recovery. Using a two-state Markov model, simulated using ns-2, 2510 the authors show that the scheme improves throughput. 2512 In "Explicit Transport Error Notification (ETEN) for Error-Prone 2513 Wireless and Satellite Networks" [Krishnan], the authors examine 2514 the use of explicit transport error notification (ETEN) to aid TCP 2515 in distinguishing congestive losses from those due to corruption. 2517 Both per-packet and cumulative ETEN mechanisms were simulated in 2518 ns-2, using both TCP Reno and TCP SACK over a wide range of bit 2519 error rates and traffic conditions. While per-packet ETEN 2520 mechanisms provided substantial gains in TCP goodput without 2521 congestion, where congestion was also present, the gains were not 2522 significant. Cumulative ETEN mechanisms did not perform as well 2523 in the study. The authors point out that ETEN faces significant 2524 deployment barriers since it can create new security 2525 vulnerabilities and requires implementations to obtain reliable 2526 information from the headers of corrupt packets. 2528 In "Towards More Expressive Transport-Layer Interfaces" [Eggert2] 2529 the authors propose extensions to existing network/transport and 2530 transport/application interfaces to improve the performance of the 2531 transport layer in the face of changes in path characteristics 2532 varying more quickly than the round-trip time. 2534 In "Protocol Enhancements for Intermittently Connected Hosts" 2535 [Schuetz], the authors note that intermittent connectivity can 2536 lead to poor performance and connectivity failures. To address 2537 these problems, the authors combine the use of the Host Identity 2538 Protocol (HIP) with a TCP User Timeout Option and TCP 2539 Retransmission trigger, demonstrating significant improvement. 2541 A.4 Application Layer 2543 In "Application-oriented Link Adaptation for IEEE 802.11" 2544 [Haratcherev2], rate information generated by a link layer 2545 utilizing improved rate adaptation algorithms is provided to a 2546 video application, and used for codec adaptation. Coupling the 2547 link and application layers results in major improvements in the 2548 Peak Signal/Noise Ratio (PSNR). 2550 At the Application layer, the usage of "Link Down" indications has 2551 been proposed to augment presence systems. In such systems, 2552 client devices periodically refresh their presence state using 2553 application layer protocols such as SIMPLE [RFC3428] or XMPP 2554 [RFC3921]. If the client should become disconnected, their 2555 unavailability will not be detected until the presence status 2556 times out, which can take many minutes. However, if a link goes 2557 down, and a disconnect indication can be sent to the presence 2558 server (presumably by the access point, which remains connected), 2559 the status of the user's communication application can be updated 2560 nearly instantaneously. 2562 Appendix B - IAB Members at the time of this writing 2564 Bernard Aboba 2565 Loa Andersson 2566 Brian Carpenter 2567 Leslie Daigle 2568 Elwyn Davies 2569 Kevin Fall 2570 Olaf Kolkman 2571 Kurtis Lindqvist 2572 David Meyer 2573 David Oran 2574 Eric Rescorla 2575 Dave Thaler 2576 Lixia Zhang 2578 Authors' Addresses 2580 Bernard Aboba 2581 Microsoft Corporation 2582 One Microsoft Way 2583 Redmond, WA 98052 2585 EMail: bernarda@microsoft.com 2586 Phone: +1 425 706 6605 2587 Fax: +1 425 936 7329 2589 Full Copyright Statement 2591 Copyright (C) The IETF Trust (2007). 2593 This document is subject to the rights, licenses and restrictions 2594 contained in BCP 78, and except as set forth therein, the authors 2595 retain all their rights. 2597 This document and the information contained herein are provided on an 2598 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2599 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2600 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2601 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2602 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2603 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2605 Intellectual Property 2607 The IETF takes no position regarding the validity or scope of any 2608 Intellectual Property Rights or other rights that might be claimed to 2609 pertain to the implementation or use of the technology described in 2610 this document or the extent to which any license under such rights 2611 might or might not be available; nor does it represent that it has 2612 made any independent effort to identify any such rights. Information 2613 on the procedures with respect to rights in RFC documents can be 2614 found in BCP 78 and BCP 79. 2616 Copies of IPR disclosures made to the IETF Secretariat and any 2617 assurances of licenses to be made available, or the result of an 2618 attempt made to obtain a general license or permission for the use of 2619 such proprietary rights by implementers or users of this 2620 specification can be obtained from the IETF on-line IPR repository at 2621 http://www.ietf.org/ipr. 2623 The IETF invites any interested party to bring to its attention any 2624 copyrights, patents or patent applications, or other proprietary 2625 rights that may cover technology that may be required to implement 2626 this standard. Please address the information to the IETF at 2627 ietf-ipr@ietf.org. 2629 Acknowledgment 2631 Funding for the RFC Editor function is provided by the IETF 2632 Administrative Support Activity (IASA).