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