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