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