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