summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4907.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4907.txt')
-rw-r--r--doc/rfc/rfc4907.txt3475
1 files changed, 3475 insertions, 0 deletions
diff --git a/doc/rfc/rfc4907.txt b/doc/rfc/rfc4907.txt
new file mode 100644
index 0000000..4adf52b
--- /dev/null
+++ b/doc/rfc/rfc4907.txt
@@ -0,0 +1,3475 @@
+
+
+
+
+
+
+Network Working Group B. Aboba, Ed.
+Request for Comments: 4907 Internet Architecture Board
+Category: Informational IAB
+ June 2007
+
+
+ Architectural Implications of Link Indications
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ A link indication represents information provided by the link layer
+ to higher layers regarding the state of the link. This document
+ describes the role of link indications within the Internet
+ architecture. While the judicious use of link indications can
+ provide performance benefits, inappropriate use can degrade both
+ robustness and performance. This document summarizes current
+ proposals, describes the architectural issues, and provides examples
+ of appropriate and inappropriate uses of link indications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 1]
+
+RFC 4907 Link Indications June 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Requirements ...............................................3
+ 1.2. Terminology ................................................3
+ 1.3. Overview ...................................................5
+ 1.4. Layered Indication Model ...................................7
+ 2. Architectural Considerations ...................................14
+ 2.1. Model Validation ..........................................15
+ 2.2. Clear Definitions .........................................16
+ 2.3. Robustness ................................................17
+ 2.4. Congestion Control ........................................20
+ 2.5. Effectiveness .............................................21
+ 2.6. Interoperability ..........................................22
+ 2.7. Race Conditions ...........................................22
+ 2.8. Layer Compression .........................................25
+ 2.9. Transport of Link Indications .............................26
+ 3. Future Work ....................................................27
+ 4. Security Considerations ........................................28
+ 4.1. Spoofing ..................................................28
+ 4.2. Indication Validation .....................................29
+ 4.3. Denial of Service .........................................30
+ 5. References .....................................................31
+ 5.1. Normative References ......................................31
+ 5.2. Informative References ....................................31
+ 6. Acknowledgments ................................................40
+ Appendix A. Literature Review .....................................41
+ A.1. Link Layer .................................................41
+ A.2. Internet Layer .............................................53
+ A.3. Transport Layer ............................................55
+ A.4. Application Layer ..........................................60
+ Appendix B. IAB Members ...........................................60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 2]
+
+RFC 4907 Link Indications June 2007
+
+
+1. Introduction
+
+ A link indication represents information provided by the link layer
+ to higher layers regarding the state of the link. While the
+ judicious use of link indications can provide performance benefits,
+ inappropriate use can degrade both robustness and performance.
+
+ This document summarizes the current understanding of the role of
+ link indications within the Internet architecture, and provides
+ advice to document authors about the appropriate use of link
+ indications within the Internet, transport, and application layers.
+
+ Section 1 describes the history of link indication usage within the
+ Internet architecture and provides a model for the utilization of
+ link indications. Section 2 describes the architectural
+ considerations and provides advice to document authors. Section 3
+ describes recommendations and future work. Appendix A summarizes the
+ literature on link indications, focusing largely on wireless Local
+ Area Networks (WLANs).
+
+1.1. Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+1.2. Terminology
+
+ Access Point (AP)
+ A station that provides access to the fixed network (e.g., an
+ 802.11 Distribution System), via the wireless medium (WM) for
+ associated stations.
+
+ Asymmetric
+ A link with transmission characteristics that are different
+ depending upon the relative position or design characteristics
+ of the transmitter and the receiver is said to be asymmetric.
+ For instance, the range of one transmitter may be much higher
+ than the range of another transmitter on the same medium.
+
+ Beacon
+ A control message broadcast by a station (typically an Access
+ Point), informing stations in the neighborhood of its continuing
+ presence, possibly along with additional status or configuration
+ information.
+
+
+
+
+
+
+IAB Informational [Page 3]
+
+RFC 4907 Link Indications June 2007
+
+
+ Binding Update (BU)
+ A message indicating a mobile node's current mobility binding,
+ and in particular its Care-of Address.
+
+ Correspondent Node
+ A peer node with which a mobile node is communicating. The
+ correspondent node may be either mobile or stationary.
+
+ Link
+ A communication facility or medium over which nodes can
+ communicate at the link layer, i.e., the layer immediately below
+ the Internet Protocol (IP).
+
+ Link Down
+ An event provided by the link layer that signifies a state
+ change associated with the interface no longer being capable of
+ communicating data frames; transient periods of high frame loss
+ are not sufficient.
+
+ Link Indication
+ Information provided by the link layer to higher layers
+ regarding the state of the link.
+
+ Link Layer
+ Conceptual layer of control or processing logic that is
+ responsible for maintaining control of the link. The link layer
+ functions provide an interface between the higher-layer logic
+ and the link. The link layer is the layer immediately below the
+ Internet Protocol (IP).
+
+ Link Up
+ An event provided by the link layer that signifies a state
+ change associated with the interface becoming capable of
+ communicating data frames.
+
+ Maximum Segment Size (MSS)
+ The maximum payload size available to the transport layer.
+
+ Maximum Transmission Unit (MTU)
+ The size in octets of the largest IP packet, including the IP
+ header and payload, that can be transmitted on a link or path.
+
+ Mobile Node
+ A node that can change its point of attachment from one link to
+ another, while still being reachable via its home address.
+
+
+
+
+
+
+IAB Informational [Page 4]
+
+RFC 4907 Link Indications June 2007
+
+
+ Operable Address
+ A static or dynamically assigned address that has not been
+ relinquished and has not expired.
+
+ Point of Attachment
+ The endpoint on the link to which the host is currently
+ connected.
+
+ Routable Address
+ Any IP address for which routers will forward packets. This
+ includes private addresses as specified in "Address Allocation
+ for Private Internets" [RFC1918].
+
+ Station (STA)
+ Any device that contains an IEEE 802.11 conformant medium access
+ control (MAC) and physical layer (PHY) interface to the wireless
+ medium (WM).
+
+ Strong End System Model
+ The Strong End System model emphasizes the host/router
+ distinction, tending to model a multi-homed host as a set of
+ logical hosts within the same physical host. In the Strong End
+ System model, addresses refer to an interface, rather than to
+ the host to which they attach. As a result, packets sent on an
+ outgoing interface have a source address configured on that
+ interface, and incoming packets whose destination address does
+ not correspond to the physical interface through which it is
+ received are silently discarded.
+
+ Weak End System Model
+ In the Weak End System model, addresses refer to a host. As a
+ result, packets sent on an outgoing interface need not
+ necessarily have a source address configured on that interface,
+ and incoming packets whose destination address does not
+ correspond to the physical interface through which it is
+ received are accepted.
+
+1.3. Overview
+
+ The use of link indications within the Internet architecture has a
+ long history. In response to an attempt to send to a host that was
+ off-line, the ARPANET link layer protocol provided a "Destination
+ Dead" indication, described in "Fault Isolation and Recovery"
+ [RFC816]. The ARPANET packet radio experiment [PRNET] incorporated
+ frame loss in the calculation of routing metrics, a precursor to more
+ recent link-aware routing metrics such as Expected Transmission Count
+ (ETX), described in "A High-Throughput Path Metric for Multi-Hop
+ Wireless Routing" [ETX].
+
+
+
+IAB Informational [Page 5]
+
+RFC 4907 Link Indications June 2007
+
+
+ "Routing Information Protocol" [RFC1058] defined RIP, which is
+ descended from the Xerox Network Systems (XNS) Routing Information
+ Protocol. "The OSPF Specification" [RFC1131] defined Open Shortest
+ Path First, which uses Link State Advertisements (LSAs) in order to
+ flood information relating to link status within an OSPF area.
+ [RFC2328] defines version 2 of OSPF. While these and other routing
+ protocols can utilize "Link Up" and "Link Down" indications provided
+ by those links that support them, they also can detect link loss
+ based on loss of routing packets. As noted in "Requirements for IP
+ Version 4 Routers" [RFC1812]:
+
+ It is crucial that routers have workable mechanisms for determining
+ that their network connections are functioning properly. Failure to
+ detect link loss, or failure to take the proper actions when a
+ problem is detected, can lead to black holes.
+
+ Attempts have also been made to define link indications other than
+ "Link Up" and "Link Down". "Dynamically Switched Link Control
+ Protocol" [RFC1307] defines an experimental protocol for control of
+ links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring
+ Down", and "Bring Up" states.
+
+ "A Generalized Model for Link Layer Triggers" [GenTrig] defines
+ "generic triggers", including "Link Up", "Link Down", "Link Going
+ Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger
+ Rollback", and "Better Signal Quality AP Available". IEEE 802.21
+ [IEEE-802.21] defines a Media Independent Handover Event Service
+ (MIH-ES) that provides event reporting relating to link
+ characteristics, link status, and link quality. Events defined
+ include "Link Down", "Link Up", "Link Going Down", "Link Signal
+ Strength", and "Link Signal/Noise Ratio".
+
+ Under ideal conditions, links in the "up" state experience low frame
+ loss in both directions and are immediately ready to send and receive
+ data frames; links in the "down" state are unsuitable for sending and
+ receiving data frames in either direction.
+
+ Unfortunately, links frequently exhibit non-ideal behavior. Wired
+ links may fail in half-duplex mode, or exhibit partial impairment
+ resulting in intermediate loss rates. Wireless links may exhibit
+ asymmetry, intermittent frame loss, or rapid changes in throughput
+ due to interference or signal fading. In both wired and wireless
+ links, the link state may rapidly flap between the "up" and "down"
+ states. This real-world behavior presents challenges to the
+ integration of link indications with the Internet, transport, and
+ application layers.
+
+
+
+
+
+IAB Informational [Page 6]
+
+RFC 4907 Link Indications June 2007
+
+
+1.4. Layered Indication Model
+
+ A layered indication model is shown in Figure 1 that includes both
+ internally generated link indications (such as link state and rate)
+ and indications arising from external interactions such as path
+ change detection. In this model, it is assumed that the link layer
+ provides indications to higher layers primarily in the form of
+ abstract indications that are link-technology agnostic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 7]
+
+RFC 4907 Link Indications June 2007
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Application | |
+ Layer | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ^ ^ ^
+ ! ! !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
+ | ! ! ! |
+ | ! ^ ^ |
+ | Connection Management ! ! Teardown |
+ Transport | ! ! |
+ Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
+ | ! ! |
+ | ! ! |
+ | ^ ! |
+ | Transport Parameter Estimation ! |
+ |(MSS, RTT, RTO, cwnd, bw, ssthresh)! |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
+ ^ ^ ^ ^ ^ !
+ ! ! ! ! ! !
+ +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
+ | ! ! Incoming !MIP ! ! ! |
+ | ! ! Interface !BU ! ! ! |
+ | ! ! Change !Receipt! ! ! |
+ | ! ^ ^ ^ ! ^ |
+ Internet | ! ! Mobility ! ! ! ! |
+ Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
+ | ! ! Outgoing ! Path ! ! ! |
+ | ! ! Interface ! Change! ! ! |
+ | ^ ^ Change ^ ^ ! ^ |
+ | ! ! ! ! |
+ | ! Routing ! ! ! |
+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
+ | ! ! v ! IP |
+ | ! ! Path ! Address |
+ | ! IP Configuration ^ Info ^ Config/ |
+ | ! ! Cache Changes |
+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
+ ! !
+ ! !
+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
+ | ! ! |
+ Link | ^ ^ |
+ Layer | Rate, FER, Link |
+ | Delay Up/Down |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1. Layered Indication Model
+
+
+
+IAB Informational [Page 8]
+
+RFC 4907 Link Indications June 2007
+
+
+1.4.1. Internet Layer
+
+ One of the functions of the Internet layer is to shield higher layers
+ from the specifics of link behavior. As a result, the Internet layer
+ validates and filters link indications and selects outgoing and
+ incoming interfaces based on routing metrics.
+
+ The Internet layer composes its routing table based on information
+ available from local interfaces as well as potentially by taking into
+ account information provided by routers. This enables the state of
+ the local routing table to reflect link conditions on both local and
+ remote links. For example, prefixes to be added or removed from the
+ routing table may be determined from Dynamic Host Configuration
+ Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements
+ [RFC1256][RFC2461], redirect messages, or route updates incorporating
+ information on the state of links multiple hops away.
+
+ As described in "Packetization Layer Path MTU Discovery" [RFC4821],
+ the Internet layer may maintain a path information cache, enabling
+ sharing of Path MTU information between concurrent or subsequent
+ connections. The shared cache is accessed and updated by
+ packetization protocols implementing packetization layer Path MTU
+ Discovery.
+
+ The Internet layer also utilizes link indications in order to
+ optimize aspects of Internet Protocol (IP) configuration and
+ mobility. After receipt of a "Link Up" indication, hosts validate
+ potential IP configurations by Detecting Network Attachment (DNA)
+ [RFC4436]. Once the IP configuration is confirmed, it may be
+ determined that an address change has occurred. However, "Link Up"
+ indications may not necessarily result in a change to Internet layer
+ configuration.
+
+ In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
+ a "Link Up" indication, potential IP configurations are validated
+ using a bidirectional reachability test. In "Detecting Network
+ Attachment in IPv6 Networks (DNAv6)" [DNAv6], IP configuration is
+ validated using reachability detection and Router
+ Solicitation/Advertisement.
+
+ The routing sub-layer may utilize link indications in order to enable
+ more rapid response to changes in link state and effective
+ throughput. Link rate is often used in computing routing metrics.
+ However, in wired networks the transmission rate may be negotiated in
+ order to enhance energy efficiency [EfficientEthernet]. In wireless
+ networks, the negotiated rate and Frame Error Rate (FER) may change
+
+
+
+
+
+IAB Informational [Page 9]
+
+RFC 4907 Link Indications June 2007
+
+
+ with link conditions so that effective throughput may vary on a
+ packet-by-packet basis. In such situations, routing metrics may also
+ exhibit rapid variation.
+
+ Routing metrics incorporating link indications such as Link Up/Down
+ and effective throughput enable routers to take link conditions into
+ account for the purposes of route selection. If a link experiences
+ decreased rate or high frame loss, the route metric will increase for
+ the prefixes that it serves, encouraging use of alternate paths if
+ available. When the link condition improves, the route metric will
+ decrease, encouraging use of the link.
+
+ Within Weak End System implementations, changes in routing metrics
+ and link state may result in a change in the outgoing interface for
+ one or more transport connections. Routes may also be added or
+ withdrawn, resulting in loss or gain of peer connectivity. However,
+ link indications such as changes in transmission rate or frame loss
+ do not necessarily result in a change of outgoing interface.
+
+ The Internet layer may also become aware of path changes by other
+ mechanisms, such as receipt of updates from a routing protocol,
+ receipt of a Router Advertisement, dead gateway detection [RFC816] or
+ network unreachability detection [RFC2461], ICMP redirects, or a
+ change in the IPv4 TTL (Time to Live)/IPv6 Hop Limit of received
+ packets. A change in the outgoing interface may in turn influence
+ the mobility sub-layer, causing a change in the incoming interface.
+ The mobility sub-layer may also become aware of a change in the
+ incoming interface of a peer (via receipt of a Mobile IP Binding
+ Update [RFC3775]).
+
+1.4.2. Transport Layer
+
+ The transport layer processes received link indications differently
+ for the purposes of transport parameter estimation and connection
+ management.
+
+ For the purposes of parameter estimation, the transport layer is
+ primarily interested in path properties that impact performance, and
+ where link indications may be determined to be relevant to path
+ properties they may be utilized directly. Link indications such as
+ "Link Up"/"Link Down" or changes in rate, delay, and frame loss may
+ prove relevant. This will not always be the case, however; where the
+ bandwidth of the bottleneck on the end-to-end path is already much
+ lower than the transmission rate, an increase in transmission rate
+ may not materially affect path properties. As described in Appendix
+ A.3, the algorithms for utilizing link layer indications to improve
+ transport parameter estimates are still under development.
+
+
+
+
+IAB Informational [Page 10]
+
+RFC 4907 Link Indications June 2007
+
+
+ Strict layering considerations do not apply in transport path
+ parameter estimation in order to enable the transport layer to make
+ use of all available information. For example, the transport layer
+ may determine that a link indication came from a link forming part of
+ a path of one or more connections. In this case, it may utilize the
+ receipt of a "Link Down" indication followed by a subsequent "Link
+ Up" indication to infer the possibility of non-congestive packet loss
+ during the period between the indications, even if the IP
+ configuration does not change as a result, so that no Internet layer
+ indication would be sent.
+
+ The transport layer may also find Internet layer indications useful
+ for path parameter estimation. For example, path change indications
+ can be used as a signal to reset path parameter estimates. Where
+ there is no default route, loss of segments sent to a destination
+ lacking a prefix in the local routing table may be assumed to be due
+ to causes other than congestion, regardless of the reason for the
+ removal (either because local link conditions caused it to be removed
+ or because the route was withdrawn by a remote router).
+
+ For the purposes of connection management, layering considerations
+ are important. The transport layer may tear down a connection based
+ on Internet layer indications (such as a endpoint address changes),
+ but does not take link indications into account. Just as a "Link Up"
+ event may not result in a configuration change, and a configuration
+ change may not result in connection teardown, the transport layer
+ does not tear down connections on receipt of a "Link Down"
+ indication, regardless of the cause. Where the "Link Down"
+ indication results from frame loss rather than an explicit exchange,
+ the indication may be transient, to be soon followed by a "Link Up"
+ indication.
+
+ Even where the "Link Down" indication results from an explicit
+ exchange such as receipt of a Point-to-Point Protocol (PPP) Link
+ Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or
+ Deauthenticate frame, an alternative point of attachment may be
+ available, allowing connectivity to be quickly restored. As a
+ result, robustness is best achieved by allowing connections to remain
+ up until an endpoint address changes, or the connection is torn down
+ due to lack of response to repeated retransmission attempts.
+
+ For the purposes of connection management, the transport layer is
+ cautious with the use of Internet layer indications. Changes in the
+ routing table are not relevant for the purposes of connection
+ management, since it is desirable for connections to remain up during
+ transitory routing flaps. However, the transport layer may tear down
+ transport connections due to invalidation of a connection endpoint IP
+ address. Where the connection has been established based on a Mobile
+
+
+
+IAB Informational [Page 11]
+
+RFC 4907 Link Indications June 2007
+
+
+ IP home address, a change in the Care-of Address need not result in
+ connection teardown, since the configuration change is masked by the
+ mobility functionality within the Internet layer, and is therefore
+ transparent to the transport layer.
+
+ "Requirements for Internet Hosts -- Communication Layers" [RFC1122],
+ Section 2.4, requires Destination Unreachable, Source Quench, Echo
+ Reply, Timestamp Reply, and Time Exceeded ICMP messages to be passed
+ up to the transport layer. [RFC1122], Section 4.2.3.9, requires
+ Transmission Control Protocol (TCP) to react to an Internet Control
+ Message Protocol (ICMP) Source Quench by slowing transmission.
+
+ [RFC1122], Section 4.2.3.9, distinguishes between ICMP messages
+ indicating soft error conditions, which must not cause TCP to abort a
+ connection, and hard error conditions, which should cause an abort.
+ ICMP messages indicating soft error conditions include Destination
+ Unreachable codes 0 (Net), 1 (Host), and 5 (Source Route Failed),
+ which may result from routing transients; Time Exceeded; and
+ Parameter Problem. ICMP messages indicating hard error conditions
+ include Destination Unreachable codes 2 (Protocol Unreachable), 3
+ (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment
+ Was Set). Since hosts implementing classical ICMP-based Path MTU
+ Discovery [RFC1191] use Destination Unreachable code 4, they do not
+ treat this as a hard error condition. Hosts implementing "Path MTU
+ Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big
+ messages. As noted in "TCP Problems with Path MTU Discovery"
+ [RFC2923], classical Path MTU Discovery is vulnerable to failure if
+ ICMP messages are not delivered or processed. In order to address
+ this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does
+ depend on the delivery of ICMP messages.
+
+ "Fault Isolation and Recovery" [RFC816], Section 6, states:
+
+ It is not obvious, when error messages such as ICMP Destination
+ Unreachable arrive, whether TCP should abandon the connection. The
+ reason that error messages are difficult to interpret is that, as
+ discussed above, after a failure of a gateway or network, there is a
+ transient period during which the gateways may have incorrect
+ information, so that irrelevant or incorrect error messages may
+ sometimes return. An isolated ICMP Destination Unreachable may
+ arrive at a host, for example, if a packet is sent during the period
+ when the gateways are trying to find a new route. To abandon a TCP
+ connection based on such a message arriving would be to ignore the
+ valuable feature of the Internet that for many internal failures it
+ reconstructs its function without any disruption of the end points.
+
+
+
+
+
+
+IAB Informational [Page 12]
+
+RFC 4907 Link Indications June 2007
+
+
+ "Requirements for IP Version 4 Routers" [RFC1812], Section 4.3.3.3,
+ states that "Research seems to suggest that Source Quench consumes
+ network bandwidth but is an ineffective (and unfair) antidote to
+ congestion", indicating that routers should not originate them. In
+ general, since the transport layer is able to determine an
+ appropriate (and conservative) response to congestion based on packet
+ loss or explicit congestion notification, ICMP Source Quench
+ indications are not needed, and the sending of additional Source
+ Quench packets during periods of congestion may be detrimental.
+
+ "ICMP attacks against TCP" [Gont] argues that accepting ICMP messages
+ based on a correct four-tuple without additional security checks is
+ ill-advised. For example, an attacker forging an ICMP hard error
+ message can cause one or more transport connections to abort. The
+ authors discuss a number of precautions, including mechanisms for
+ validating ICMP messages and ignoring or delaying response to hard
+ error messages under various conditions. They also recommend that
+ hosts ignore ICMP Source Quench messages.
+
+ The transport layer may also provide information to the link layer.
+ For example, the transport layer may wish to control the maximum
+ number of times that a link layer frame may be retransmitted, so that
+ the link layer does not continue to retransmit after a transport
+ layer timeout. In IEEE 802.11, this can be achieved by adjusting the
+ Management Information Base (MIB) [IEEE-802.11] variables
+ dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default:
+ 4), which control the maximum number of retries for frames shorter
+ and longer in length than dot11RTSThreshold, respectively. However,
+ since these variables control link behavior as a whole they cannot be
+ used to separately adjust behavior on a per-transport connection
+ basis. In situations where the link layer retransmission timeout is
+ of the same order as the path round-trip timeout, link layer control
+ may not be possible at all.
+
+1.4.3. Application Layer
+
+ The transport layer provides indications to the application layer by
+ propagating Internet layer indications (such as IP address
+ configuration and changes), as well as providing its own indications,
+ such as connection teardown.
+
+ Since applications can typically obtain the information they need
+ more reliably from the Internet and transport layers, they will
+ typically not need to utilize link indications. A "Link Up"
+ indication implies that the link is capable of communicating IP
+ packets, but does not indicate that it has been configured;
+ applications should use an Internet layer "IP Address Configured"
+ event instead. "Link Down" indications are typically not useful to
+
+
+
+IAB Informational [Page 13]
+
+RFC 4907 Link Indications June 2007
+
+
+ applications, since they can be rapidly followed by a "Link Up"
+ indication; applications should respond to transport layer teardown
+ indications instead. Similarly, changes in the transmission rate may
+ not be relevant to applications if the bottleneck bandwidth on the
+ path does not change; the transport layer is best equipped to
+ determine this. As a result, Figure 1 does not show link indications
+ being provided directly to applications.
+
+2. Architectural Considerations
+
+ The complexity of real-world link behavior poses a challenge to the
+ integration of link indications within the Internet architecture.
+ While the literature provides persuasive evidence of the utility of
+ link indications, difficulties can arise in making effective use of
+ them. To avoid these issues, the following architectural principles
+ are suggested and discussed in more detail in the sections that
+ follow:
+
+ (1) Proposals should avoid use of simplified link models in
+ circumstances where they do not apply (Section 2.1).
+
+ (2) Link indications should be clearly defined, so that it is
+ understood when they are generated on different link layers
+ (Section 2.2).
+
+ (3) Proposals must demonstrate robustness against spurious link
+ indications (Section 2.3).
+
+ (4) Upper layers should utilize a timely recovery step so as to
+ limit the potential damage from link indications determined to
+ be invalid after they have been acted on (Section 2.3.2).
+
+ (5) Proposals must demonstrate that effective congestion control is
+ maintained (Section 2.4).
+
+ (6) Proposals must demonstrate the effectiveness of proposed
+ optimizations (Section 2.5).
+
+ (7) Link indications should not be required by upper layers, in
+ order to maintain link independence (Section 2.6).
+
+ (8) Proposals should avoid race conditions, which can occur where
+ link indications are utilized directly by multiple layers of the
+ stack (Section 2.7).
+
+ (9) Proposals should avoid inconsistencies between link and routing
+ layer metrics (Section 2.7.3).
+
+
+
+
+IAB Informational [Page 14]
+
+RFC 4907 Link Indications June 2007
+
+
+ (10) Overhead reduction schemes must avoid compromising
+ interoperability and introducing link layer dependencies into
+ the Internet and transport layers (Section 2.8).
+
+ (11) Proposals for transport of link indications beyond the local
+ host need to carefully consider the layering, security, and
+ transport implications (Section 2.9).
+
+2.1. Model Validation
+
+ Proposals should avoid the use of link models in circumstances where
+ they do not apply.
+
+ In "The mistaken axioms of wireless-network research" [Kotz], the
+ authors conclude that mistaken assumptions relating to link behavior
+ may lead to the design of network protocols that may not work in
+ practice. For example, the authors note that the three-dimensional
+ nature of wireless propagation can result in large signal strength
+ changes over short distances. This can result in rapid changes in
+ link indications such as rate, frame loss, and signal strength.
+
+ In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
+ the authors provide examples of modeling mistakes and examples of how
+ to improve modeling of link characteristics. To accompany the paper,
+ the authors provide simulation scenarios in ns-2.
+
+ In order to avoid the pitfalls described in [Kotz] [GurtovFloyd],
+ documents that describe capabilities that are dependent on link
+ indications should explicitly articulate the assumptions of the link
+ model and describe the circumstances in which they apply.
+
+ Generic "trigger" models may include implicit assumptions that may
+ prove invalid in outdoor or mesh wireless LAN deployments. For
+ example, two-state Markov models assume that the link is either in a
+ state experiencing low frame loss ("up") or in a state where few
+ frames are successfully delivered ("down"). In these models,
+ symmetry is also typically assumed, so that the link is either "up"
+ in both directions or "down" in both directions. In situations where
+ intermediate loss rates are experienced, these assumptions may be
+ invalid.
+
+ As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev],
+ signal strength data is noisy and sometimes inconsistent, so that it
+ needs to be filtered in order to avoid erratic results. Given this,
+ link indications based on raw signal strength data may be unreliable.
+ In order to avoid problems, it is best to combine signal strength
+ data with other techniques. For example, in developing a "Going
+ Down" indication for use with [IEEE-802.21] it would be advisable to
+
+
+
+IAB Informational [Page 15]
+
+RFC 4907 Link Indications June 2007
+
+
+ validate filtered signal strength measurements with other indications
+ of link loss such as lack of Beacon reception.
+
+2.2. Clear Definitions
+
+ Link indications should be clearly defined, so that it is understood
+ when they are generated on different link layers. For example,
+ considerable work has been required in order to come up with the
+ definitions of "Link Up" and "Link Down", and to define when these
+ indications are sent on various link layers.
+
+ Link indication definitions should heed the following advice:
+
+ (1) Do not assume symmetric link performance or frame loss that is
+ either low ("up") or high ("down").
+
+ In wired networks, links in the "up" state typically experience
+ low frame loss in both directions and are ready to send and
+ receive data frames; links in the "down" state are unsuitable
+ for sending and receiving data frames in either direction.
+ Therefore, a link providing a "Link Up" indication will
+ typically experience low frame loss in both directions, and high
+ frame loss in any direction can only be experienced after a link
+ provides a "Link Down" indication. However, these assumptions
+ may not hold true for wireless LAN networks. Asymmetry is
+ typically less of a problem for cellular networks where
+ propagation occurs over longer distances, multi-path effects may
+ be less severe, and the base station can transmit at much higher
+ power than mobile stations while utilizing a more sensitive
+ antenna.
+
+ Specifications utilizing a "Link Up" indication should not
+ assume that receipt of this indication means that the link is
+ experiencing symmetric link conditions or low frame loss in
+ either direction. In general, a "Link Up" event should not be
+ sent due to transient changes in link conditions, but only due
+ to a change in link layer state. It is best to assume that a
+ "Link Up" event may not be sent in a timely way. Large handoff
+ latencies can result in a delay in the generation of a "Link Up"
+ event as movement to an alternative point of attachment is
+ delayed.
+
+ (2) Consider the sensitivity of link indications to transient link
+ conditions. Due to common effects such as multi-path
+ interference, signal strength and signal to noise ratio (SNR)
+ may vary rapidly over a short distance, causing erratic behavior
+ of link indications based on unfiltered measurements. As noted
+ in [Haratcherev], signal strength may prove most useful when
+
+
+
+IAB Informational [Page 16]
+
+RFC 4907 Link Indications June 2007
+
+
+ utilized in combination with other measurements, such as frame
+ loss.
+
+ (3) Where possible, design link indications with built-in damping.
+ By design, the "Link Up" and "Link Down" events relate to
+ changes in the state of the link layer that make it able and
+ unable to communicate IP packets. These changes are generated
+ either by the link layer state machine based on link layer
+ exchanges (e.g., completion of the IEEE 802.11i four-way
+ handshake for "Link Up", or receipt of a PPP LCP-Terminate for
+ "Link Down") or by protracted frame loss, so that the link layer
+ concludes that the link is no longer usable. As a result, these
+ link indications are typically less sensitive to changes in
+ transient link conditions.
+
+ (4) Do not assume that a "Link Down" event will be sent at all, or
+ that, if sent, it will be received in a timely way. A good link
+ layer implementation will both rapidly detect connectivity
+ failure (such as by tracking missing Beacons) while sending a
+ "Link Down" event only when it concludes the link is unusable,
+ not due to transient frame loss.
+
+ However, existing wireless LAN implementations often do not do a good
+ job of detecting link failure. During a lengthy detection phase, a
+ "Link Down" event is not sent by the link layer, yet IP packets
+ cannot be transmitted or received on the link. Initiation of a scan
+ may be delayed so that the station cannot find another point of
+ attachment. This can result in inappropriate backoff of
+ retransmission timers within the transport layer, among other
+ problems. This is not as much of a problem for cellular networks
+ that utilize transmit power adjustment.
+
+2.3. Robustness
+
+ Link indication proposals must demonstrate robustness against
+ misleading indications. Elements to consider include:
+
+ Implementation variation
+ Recovery from invalid indications
+ Damping and hysteresis
+
+2.3.1. Implementation Variation
+
+ Variations in link layer implementations may have a substantial
+ impact on the behavior of link indications. These variations need to
+ be taken into account in evaluating the performance of proposals.
+ For example, radio propagation and implementation differences can
+ impact the reliability of link indications.
+
+
+
+IAB Informational [Page 17]
+
+RFC 4907 Link Indications June 2007
+
+
+ In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
+ the authors analyze the cause of frame loss in a 38-node urban
+ multi-hop IEEE 802.11 ad-hoc network. In most cases, links that are
+ very bad in one direction tend to be bad in both directions, and
+ links that are very good in one direction tend to be good in both
+ directions. However, 30 percent of links exhibited loss rates
+ differing substantially in each direction.
+
+ As described in [Aguayo], wireless LAN links often exhibit loss rates
+ intermediate between "up" (low loss) and "down" (high loss) states,
+ as well as substantial asymmetry. As a result, receipt of a "Link
+ Up" indication may not necessarily indicate bidirectional
+ reachability, since it could have been generated after exchange of
+ small frames at low rates, which might not imply bidirectional
+ connectivity for large frames exchanged at higher rates.
+
+ Where multi-path interference or hidden nodes are encountered, signal
+ strength may vary widely over a short distance. Several techniques
+ may be used to reduce potential disruptions. Multiple transmitting
+ and receiving antennas may be used to reduce multi-path effects;
+ transmission rate adaptation can be used to find a more satisfactory
+ transmission rate; transmit power adjustment can be used to improve
+ signal quality and reduce interference; Request-to-Send/Clear-to-Send
+ (RTS/CTS) signaling can be used to reduce hidden node problems.
+ These techniques may not be completely effective, so that high frame
+ loss may be encountered, causing the link to cycle between "up" and
+ "down" states.
+
+ To improve robustness against spurious link indications, it is
+ recommended that upper layers treat the indication as a "hint"
+ (advisory in nature), rather than a "trigger" dictating a particular
+ action. Upper layers may then attempt to validate the hint.
+
+ In [RFC4436], "Link Up" indications are rate limited, and IP
+ configuration is confirmed using bidirectional reachability tests
+ carried out coincident with a request for configuration via DHCP. As
+ a result, bidirectional reachability is confirmed prior to activation
+ of an IP configuration. However, where a link exhibits an
+ intermediate loss rate, demonstration of bidirectional reachability
+ may not necessarily indicate that the link is suitable for carrying
+ IP data packets.
+
+ Another example of validation occurs in IPv4 Link-Local address
+ configuration [RFC3927]. Prior to configuration of an IPv4 Link-
+ Local address, it is necessary to run a claim-and-defend protocol.
+ Since a host needs to be present to defend its address against
+ another claimant, and address conflicts are relatively likely, a host
+ returning from sleep mode or receiving a "Link Up" indication could
+
+
+
+IAB Informational [Page 18]
+
+RFC 4907 Link Indications June 2007
+
+
+ encounter an address conflict were it to utilize a formerly
+ configured IPv4 Link-Local address without rerunning claim and
+ defend.
+
+2.3.2. Recovery from Invalid Indications
+
+ In some situations, improper use of link indications can result in
+ operational malfunctions. It is recommended that upper layers
+ utilize a timely recovery step so as to limit the potential damage
+ from link indications determined to be invalid after they have been
+ acted on.
+
+ In Detecting Network Attachment in IPv4 (DNAv4) [RFC4436],
+ reachability tests are carried out coincident with a request for
+ configuration via DHCP. Therefore, if the bidirectional reachability
+ test times out, the host can still obtain an IP configuration via
+ DHCP, and if that fails, the host can still continue to use an
+ existing valid address if it has one.
+
+ Where a proposal involves recovery at the transport layer, the
+ recovered transport parameters (such as the Maximum Segment Size
+ (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth
+ (bw), congestion window (cwnd), etc.) should be demonstrated to
+ remain valid. Congestion window validation is discussed in "TCP
+ Congestion Window Validation" [RFC2861].
+
+ Where timely recovery is not supported, unexpected consequences may
+ result. As described in [RFC3927], early IPv4 Link-Local
+ implementations would wait five minutes before attempting to obtain a
+ routable address after assigning an IPv4 Link-Local address. In one
+ implementation, it was observed that where mobile hosts changed their
+ point of attachment more frequently than every five minutes, they
+ would never obtain a routable address. The problem was caused by an
+ invalid link indication (signaling of "Link Up" prior to completion
+ of link layer authentication), resulting in an initial failure to
+ obtain a routable address using DHCP. As a result, [RFC3927]
+ recommends against modification of the maximum retransmission timeout
+ (64 seconds) provided in [RFC2131].
+
+2.3.3. Damping and Hysteresis
+
+ Damping and hysteresis can be utilized to limit damage from unstable
+ link indications. This may include damping unstable indications or
+ placing constraints on the frequency of link indication-induced
+ actions within a time period.
+
+
+
+
+
+
+IAB Informational [Page 19]
+
+RFC 4907 Link Indications June 2007
+
+
+ While [Aguayo] found that frame loss was relatively stable for
+ stationary stations, obstacles to radio propagation and multi-path
+ interference can result in rapid changes in signal strength for a
+ mobile station. As a result, it is possible for mobile stations to
+ encounter rapid changes in link characteristics, including changes in
+ transmission rate, throughput, frame loss, and even "Link Up"/"Link
+ Down" indications.
+
+ Where link-aware routing metrics are implemented, this can result in
+ rapid metric changes, potentially resulting in frequent changes in
+ the outgoing interface for Weak End System implementations. As a
+ result, it may be necessary to introduce route flap dampening.
+
+ However, the benefits of damping need to be weighed against the
+ additional latency that can be introduced. For example, in order to
+ filter out spurious "Link Down" indications, these indications may be
+ delayed until it can be determined that a "Link Up" indication will
+ not follow shortly thereafter. However, in situations where multiple
+ Beacons are missed such a delay may not be needed, since there is no
+ evidence of a suitable point of attachment in the vicinity.
+
+ In some cases, it is desirable to ignore link indications entirely.
+ Since it is possible for a host to transition from an ad-hoc network
+ to a network with centralized address management, a host receiving a
+ "Link Up" indication cannot necessarily conclude that it is
+ appropriate to configure an IPv4 Link-Local address prior to
+ determining whether a DHCP server is available [RFC3927] or an
+ operable configuration is valid [RFC4436].
+
+ As noted in Section 1.4, the transport layer does not utilize "Link
+ Up" and "Link Down" indications for the purposes of connection
+ management.
+
+2.4. Congestion Control
+
+ Link indication proposals must demonstrate that effective congestion
+ control is maintained [RFC2914]. One or more of the following
+ techniques may be utilized:
+
+ Rate limiting. Packets generated based on receipt of link
+ indications can be rate limited (e.g., a limit of one packet per
+ end-to-end path RTO).
+
+ Utilization of upper-layer indications. Applications should
+ depend on upper-layer indications such as IP address
+ configuration/change notification, rather than utilizing link
+ indications such as "Link Up".
+
+
+
+
+IAB Informational [Page 20]
+
+RFC 4907 Link Indications June 2007
+
+
+ Keepalives. In order to improve robustness against spurious link
+ indications, an application keepalive or transport layer
+ indication (such as connection teardown) can be used instead of
+ consuming "Link Down" indications.
+
+ Conservation of resources. Proposals must demonstrate that they
+ are not vulnerable to congestive collapse.
+
+ As noted in "Robust Rate Adaptation for 802.11 Wireless Networks"
+ [Robust], decreasing transmission rate in response to frame loss
+ increases contention, potentially leading to congestive collapse. To
+ avoid this, the link layer needs to distinguish frame loss due to
+ congestion from loss due to channel conditions. Only frame loss due
+ to deterioration in channel conditions can be used as a basis for
+ decreasing transmission rate.
+
+ Consider a proposal where a "Link Up" indication is used by a host to
+ trigger retransmission of the last previously sent packet, in order
+ to enable ACK reception prior to expiration of the host's
+ retransmission timer. On a rapidly moving mobile node where "Link
+ Up" indications follow in rapid succession, this could result in a
+ burst of retransmitted packets, violating the principle of
+ "conservation of packets".
+
+ At the application layer, link indications have been utilized by
+ applications such as Presence [RFC2778] in order to optimize
+ registration and user interface update operations. For example,
+ implementations may attempt presence registration on receipt of a
+ "Link Up" indication, and presence de-registration by a surrogate
+ receiving a "Link Down" indication. Presence implementations using
+ "Link Up"/"Link Down" indications this way violate the principle of
+ "conservation of packets" since link indications can be generated on
+ a time scale less than the end-to-end path RTO. The problem is
+ magnified since for each presence update, notifications can be
+ delivered to many watchers. In addition, use of a "Link Up"
+ indication in this manner is unwise since the interface may not yet
+ even have an operable Internet layer configuration. Instead, an "IP
+ address configured" indication may be utilized.
+
+2.5. Effectiveness
+
+ Proposals must demonstrate the effectiveness of proposed
+ optimizations. Since optimizations typically increase complexity,
+ substantial performance improvement is required in order to make a
+ compelling case.
+
+
+
+
+
+
+IAB Informational [Page 21]
+
+RFC 4907 Link Indications June 2007
+
+
+ In the face of unreliable link indications, effectiveness may depend
+ on the penalty for false positives and false negatives. In the case
+ of DNAv4 [RFC4436], the benefits of successful optimization are
+ modest, but the penalty for being unable to confirm an operable
+ configuration is a lengthy timeout. As a result, the recommended
+ strategy is to test multiple potential configurations in parallel in
+ addition to attempting configuration via DHCP. This virtually
+ guarantees that DNAv4 will always result in performance equal to or
+ better than use of DHCP alone.
+
+2.6. Interoperability
+
+ While link indications can be utilized where available, they should
+ not be required by upper layers, in order to maintain link layer
+ independence. For example, if information on supported prefixes is
+ provided at the link layer, hosts not understanding those hints must
+ still be able to obtain an IP address.
+
+ Where link indications are proposed to optimize Internet layer
+ configuration, proposals must demonstrate that they do not compromise
+ robustness by interfering with address assignment or routing protocol
+ behavior, making address collisions more likely, or compromising
+ Duplicate Address Detection (DAD) [RFC4429].
+
+ To avoid compromising interoperability in the pursuit of performance
+ optimization, proposals must demonstrate that interoperability
+ remains possible (potentially with degraded performance) even if one
+ or more participants do not implement the proposal.
+
+2.7. Race Conditions
+
+ Link indication proposals should avoid race conditions, which can
+ occur where link indications are utilized directly by multiple layers
+ of the stack.
+
+ Link indications are useful for optimization of Internet Protocol
+ layer addressing and configuration as well as routing. Although "The
+ BU-trigger method for improving TCP performance over Mobile IPv6"
+ [Kim] describes situations in which link indications are first
+ processed by the Internet Protocol layer (e.g., MIPv6) before being
+ utilized by the transport layer, for the purposes of parameter
+ estimation, it may be desirable for the transport layer to utilize
+ link indications directly.
+
+ In situations where the Weak End System model is implemented, a
+ change of outgoing interface may occur at the same time the transport
+ layer is modifying transport parameters based on other link
+
+
+
+
+IAB Informational [Page 22]
+
+RFC 4907 Link Indications June 2007
+
+
+ indications. As a result, transport behavior may differ depending on
+ the order in which the link indications are processed.
+
+ Where a multi-homed host experiences increasing frame loss or
+ decreased rate on one of its interfaces, a routing metric taking
+ these effects into account will increase, potentially causing a
+ change in the outgoing interface for one or more transport
+ connections. This may trigger Mobile IP signaling so as to cause a
+ change in the incoming path as well. As a result, the transport
+ parameters estimated for the original outgoing and incoming paths
+ (congestion state, Maximum Segment Size (MSS) derived from the link
+ maximum transmission unit (MTU) or Path MTU) may no longer be valid
+ for the new outgoing and incoming paths.
+
+ To avoid race conditions, the following measures are recommended:
+
+ Path change re-estimation
+ Layering
+ Metric consistency
+
+2.7.1. Path Change Re-estimation
+
+ When the Internet layer detects a path change, such as a major change
+ in transmission rate, a change in the outgoing or incoming interface
+ of the host or the incoming interface of a peer, or perhaps even a
+ substantial change in the IPv4 TTL/IPv6 Hop Limit of received
+ packets, it may be worth considering whether to reset transport
+ parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so as to
+ allow them to be re-estimated. This ensures that estimates based on
+ the former path do not persist after they have become invalid.
+ Appendix A.3 summarizes the research on this topic.
+
+2.7.2. Layering
+
+ Another technique to avoid race conditions is to rely on layering to
+ damp transient link indications and provide greater link layer
+ independence.
+
+ The Internet layer is responsible for routing as well as IP
+ configuration and mobility, providing higher layers with an
+ abstraction that is independent of link layer technologies.
+
+ In general, it is advisable for applications to utilize indications
+ from the Internet or transport layers rather than consuming link
+ indications directly.
+
+
+
+
+
+
+IAB Informational [Page 23]
+
+RFC 4907 Link Indications June 2007
+
+
+2.7.3. Metric Consistency
+
+ Proposals should avoid inconsistencies between link and routing layer
+ metrics. Without careful design, potential differences between link
+ indications used in routing and those used in roaming and/or link
+ enablement can result in instability, particularly in multi-homed
+ hosts.
+
+ Once a link is in the "up" state, its effectiveness in transmission
+ of data packets can be used to determine an appropriate routing
+ metric. In situations where the transmission time represents a large
+ portion of the total transit time, minimizing total transmission time
+ is equivalent to maximizing effective throughput. "A High-Throughput
+ Path Metric for Multi-Hop Wireless Routing" [ETX] describes a
+ proposed routing metric based on the Expected Transmission Count
+ (ETX). The authors demonstrate that ETX, based on link layer frame
+ loss rates (prior to retransmission), enables the selection of routes
+ maximizing effective throughput. Where the transmission rate is
+ constant, the expected transmission time is proportional to ETX, so
+ that minimizing ETX also minimizes expected transmission time.
+
+ However, where the transmission rate may vary, ETX may not represent
+ a good estimate of the estimated transmission time. In "Routing in
+ multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the
+ authors define a new metric called Expected Transmission Time (ETT).
+ This is described as a "bandwidth adjusted ETX" since ETT = ETX * S/B
+ where S is the size of the probe packet and B is the bandwidth of the
+ link as measured by a packet pair [Morgan]. However, ETT assumes
+ that the loss fraction of small probe frames sent at 1 Mbps data rate
+ is indicative of the loss fraction of larger data frames at higher
+ rates, which tends to underestimate the ETT at higher rates, where
+ frame loss typically increases. In "A Radio Aware Routing Protocol
+ for Wireless Mesh Networks" [ETX-Radio], the authors refine the ETT
+ metric further by estimating the loss fraction as a function of
+ transmission rate.
+
+ However, prior to sending data packets over the link, the appropriate
+ routing metric may not easily be predicted. As noted in [Shortest],
+ a link that can successfully transmit the short frames utilized for
+ control, management, or routing may not necessarily be able to
+ reliably transport larger data packets.
+
+ Therefore, it may be necessary to utilize alternative metrics (such
+ as signal strength or Access Point load) in order to assist in
+ attachment/handoff decisions. However, unless the new interface is
+ the preferred route for one or more destination prefixes, a Weak End
+ System implementation will not use the new interface for outgoing
+ traffic. Where "idle timeout" functionality is implemented, the
+
+
+
+IAB Informational [Page 24]
+
+RFC 4907 Link Indications June 2007
+
+
+ unused interface will be brought down, only to be brought up again by
+ the link enablement algorithm.
+
+ Within the link layer, metrics such as signal strength and frame loss
+ may be used to determine the transmission rate, as well as to
+ determine when to select an alternative point of attachment. In
+ order to enable stations to roam prior to encountering packet loss,
+ studies such as "An experimental study of IEEE 802.11b handover
+ performance and its effect on voice traffic" [Vatn] have suggested
+ using signal strength as a mechanism to more rapidly detect loss of
+ connectivity, rather than frame loss, as suggested in "Techniques to
+ Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos].
+
+ [Aguayo] notes that signal strength and distance are not good
+ predictors of frame loss or throughput, due to the potential effects
+ of multi-path interference. As a result, a link brought up due to
+ good signal strength may subsequently exhibit significant frame loss
+ and a low throughput. Similarly, an Access Point (AP) demonstrating
+ low utilization may not necessarily be the best choice, since
+ utilization may be low due to hardware or software problems. "OSPF
+ Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-
+ utilization-based routing metrics have a history of instability.
+
+2.8. Layer Compression
+
+ In many situations, the exchanges required for a host to complete a
+ handoff and reestablish connectivity are considerable, leading to
+ proposals to combine exchanges occurring within multiple layers in
+ order to reduce overhead. While overhead reduction is a laudable
+ goal, proposals need to avoid compromising interoperability and
+ introducing link layer dependencies into the Internet and transport
+ layers.
+
+ Exchanges required for handoff and connectivity reestablishment may
+ include link layer scanning, authentication, and association
+ establishment; Internet layer configuration, routing, and mobility
+ exchanges; transport layer retransmission and recovery; security
+ association reestablishment; application protocol re-authentication
+ and re-registration exchanges, etc.
+
+ Several proposals involve combining exchanges within the link layer.
+ For example, in [EAPIKEv2], a link layer Extensible Authentication
+ Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP
+ address assignment, potentially bypassing Internet layer
+ configuration. Within [PEAP], it is proposed that a link layer EAP
+ exchange be used for the purpose of carrying Mobile IPv6 Binding
+ Updates. [MIPEAP] proposes that EAP exchanges be used for
+ configuration of Mobile IPv6. Where link, Internet, or transport
+
+
+
+IAB Informational [Page 25]
+
+RFC 4907 Link Indications June 2007
+
+
+ layer mechanisms are combined, hosts need to maintain backward
+ compatibility to permit operation on networks where compression
+ schemes are not available.
+
+ Layer compression schemes may also negatively impact robustness. For
+ example, in order to optimize IP address assignment, it has been
+ proposed that prefixes be advertised at the link layer, such as
+ within the 802.11 Beacon and Probe Response frames. However,
+ [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be
+ assigned dynamically, so that prefix(es) advertised within the Beacon
+ and/or Probe Response may not correspond to the prefix(es) configured
+ by the Internet layer after the host completes link layer
+ authentication. Were the host to handle IP configuration at the link
+ layer rather than within the Internet layer, the host might be unable
+ to communicate due to assignment of the wrong IP address.
+
+2.9. Transport of Link Indications
+
+ Proposals for the transport of link indications need to carefully
+ consider the layering, security, and transport implications.
+
+ As noted earlier, the transport layer may take the state of the local
+ routing table into account in improving the quality of transport
+ parameter estimates. While absence of positive feedback that the
+ path is sending data end-to-end must be heeded, where a route that
+ had previously been absent is recovered, this may be used to trigger
+ congestion control probing. While this enables transported link
+ indications that affect the local routing table to improve the
+ quality of transport parameter estimates, security and
+ interoperability considerations relating to routing protocols still
+ apply.
+
+ Proposals involving transport of link indications need to demonstrate
+ the following:
+
+ (a) Superiority to implicit signals. In general, implicit signals
+ are preferred to explicit transport of link indications since
+ they do not require participation in the routing mesh, add no
+ new packets in times of network distress, operate more reliably
+ in the presence of middle boxes such as NA(P)Ts, are more likely
+ to be backward compatible, and are less likely to result in
+ security vulnerabilities. As a result, explicit signaling
+ proposals must prove that implicit signals are inadequate.
+
+ (b) Mitigation of security vulnerabilities. Transported link
+ indications should not introduce new security vulnerabilities.
+ Link indications that result in modifications to the local
+ routing table represent a routing protocol, so that the
+
+
+
+IAB Informational [Page 26]
+
+RFC 4907 Link Indications June 2007
+
+
+ vulnerabilities associated with unsecured routing protocols
+ apply, including spoofing by off-link attackers. While
+ mechanisms such as "SEcure Neighbor Discovery (SEND)" [RFC3971]
+ may enable authentication and integrity protection of router-
+ originated messages, protecting against forgery of transported
+ link indications, they are not yet widely deployed.
+
+ (c) Validation of transported indications. Even if a transported
+ link indication can be integrity protected and authenticated, if
+ the indication is sent by a host off the local link, it may not
+ be clear that the sender is on the actual path in use, or which
+ transport connection(s) the indication relates to. Proposals
+ need to describe how the receiving host can validate the
+ transported link indication.
+
+ (d) Mapping of Identifiers. When link indications are transported,
+ it is generally for the purposes of providing information about
+ Internet, transport, or application layer operations at a remote
+ element. However, application layer sessions or transport
+ connections may not be visible to the remote element due to
+ factors such as load sharing between links, or use of IPsec,
+ tunneling protocols, or nested headers. As a result, proposals
+ need to demonstrate how the link indication can be mapped to the
+ relevant higher-layer state. For example, on receipt of a link
+ indication, the transport layer will need to identify the set of
+ transport sessions (source address, destination address, source
+ port, destination port, transport) that are affected. If a
+ presence server is receiving remote indications of "Link
+ Up"/"Link Down" status for a particular Media Access Control
+ (MAC) address, the presence server will need to associate that
+ MAC address with the identity of the user
+ (pres:user@example.com) to whom that link status change is
+ relevant.
+
+3. Future Work
+
+ Further work is needed in order to understand how link indications
+ can be utilized by the Internet, transport, and application layers.
+
+ More work is needed to understand the connection between link
+ indications and routing metrics. For example, the introduction of
+ block ACKs (supported in [IEEE-802.11e]) complicates the relationship
+ between effective throughput and frame loss, which may necessitate
+ the development of revised routing metrics for ad-hoc networks. More
+ work is also needed to reconcile handoff metrics (e.g., signal
+ strength and link utilization) with routing metrics based on link
+ indications (e.g., frame error rate and negotiated rate).
+
+
+
+
+IAB Informational [Page 27]
+
+RFC 4907 Link Indications June 2007
+
+
+ A better understanding of the use of physical and link layer metrics
+ in rate negotiation is required. For example, recent work
+ [Robust][CARA] has suggested that frame loss due to contention (which
+ would be exacerbated by rate reduction) can be distinguished from
+ loss due to channel conditions (which may be improved via rate
+ reduction).
+
+ At the transport layer, more work is needed to determine the
+ appropriate reaction to Internet layer indications such as routing
+ table and path changes. More work is also needed in utilization of
+ link layer indications in transport parameter estimation, including
+ rate changes, "Link Up"/"Link Down" indications, link layer
+ retransmissions, and frame loss of various types (due to contention
+ or channel conditions).
+
+ More work is also needed to determine how link layers may utilize
+ information from the transport layer. For example, it is undesirable
+ for a link layer to retransmit so aggressively that the link layer
+ round-trip time approaches that of the end-to-end transport
+ connection. Instead, it may make sense to do downward rate
+ adjustment so as to decrease frame loss and improve latency. Also,
+ in some cases, the transport layer may not require heroic efforts to
+ avoid frame loss; timely delivery may be preferred instead.
+
+4. Security Considerations
+
+ Proposals for the utilization of link indications may introduce new
+ security vulnerabilities. These include:
+
+ Spoofing
+ Indication validation
+ Denial of service
+
+4.1. Spoofing
+
+ Where link layer control frames are unprotected, they may be spoofed
+ by an attacker. For example, PPP does not protect LCP frames such as
+ LCP-Terminate, and [IEEE-802.11] does not protect management frames
+ such as Associate/Reassociate, Disassociate, or Deauthenticate.
+
+ Spoofing of link layer control traffic may enable attackers to
+ exploit weaknesses in link indication proposals. For example,
+ proposals that do not implement congestion avoidance can enable
+ attackers to mount denial-of-service attacks.
+
+ However, even where the link layer incorporates security, attacks may
+ still be possible if the security model is not consistent. For
+ example, wireless LANs implementing [IEEE-802.11i] do not enable
+
+
+
+IAB Informational [Page 28]
+
+RFC 4907 Link Indications June 2007
+
+
+ stations to send or receive IP packets on the link until completion
+ of an authenticated key exchange protocol known as the "4-way
+ handshake". As a result, a link implementing [IEEE-802.11i] cannot
+ be considered usable at the Internet layer ("Link Up") until
+ completion of the authenticated key exchange.
+
+ However, while [IEEE-802.11i] requires sending of authenticated
+ frames in order to obtain a "Link Up" indication, it does not support
+ management frame authentication. This weakness can be exploited by
+ attackers to enable denial-of-service attacks on stations attached to
+ distant Access Points (APs).
+
+ In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends
+ a Reassociation Response. At that point, the AP sends a spoofed
+ frame with the station's source address to a multicast address,
+ thereby causing switches within the Distribution System (DS) to learn
+ the station's MAC address. While this enables forwarding of frames
+ to the station at the new point of attachment, it also permits an
+ attacker to disassociate a station located anywhere within the ESS,
+ by sending an unauthenticated Reassociation Request frame.
+
+4.2. Indication Validation
+
+ "Fault Isolation and Recovery" [RFC816], Section 3, describes how
+ hosts interact with routers for the purpose of fault recovery:
+
+ Since the gateways always attempt to have a consistent and correct
+ model of the internetwork topology, the host strategy for fault
+ recovery is very simple. Whenever the host feels that something is
+ wrong, it asks the gateway for advice, and, assuming the advice is
+ forthcoming, it believes the advice completely. The advice will be
+ wrong only during the transient period of negotiation, which
+ immediately follows an outage, but will otherwise be reliably
+ correct.
+
+ In fact, it is never necessary for a host to explicitly ask a gateway
+ for advice, because the gateway will provide it as appropriate. When
+ a host sends a datagram to some distant net, the host should be
+ prepared to receive back either of two advisory messages which the
+ gateway may send. The ICMP "redirect" message indicates that the
+ gateway to which the host sent the datagram is no longer the best
+ gateway to reach the net in question. The gateway will have
+ forwarded the datagram, but the host should revise its routing table
+ to have a different immediate address for this net. The ICMP
+ "destination unreachable" message indicates that as a result of an
+ outage, it is currently impossible to reach the addressed net or host
+
+
+
+
+
+IAB Informational [Page 29]
+
+RFC 4907 Link Indications June 2007
+
+
+ in any manner. On receipt of this message, a host can either abandon
+ the connection immediately without any further retransmission, or
+ resend slowly to see if the fault is corrected in reasonable time.
+
+ Given today's security environment, it is inadvisable for hosts to
+ act on indications provided by routers without careful consideration.
+ As noted in "ICMP attacks against TCP" [Gont], existing ICMP error
+ messages may be exploited by attackers in order to abort connections
+ in progress, prevent setup of new connections, or reduce throughput
+ of ongoing connections. Similar attacks may also be launched against
+ the Internet layer via forging of ICMP redirects.
+
+ Proposals for transported link indications need to demonstrate that
+ they will not add a new set of similar vulnerabilities. Since
+ transported link indications are typically unauthenticated, hosts
+ receiving them may not be able to determine whether they are
+ authentic, or even plausible.
+
+ Where link indication proposals may respond to unauthenticated link
+ layer frames, they should utilize upper-layer security mechanisms,
+ where possible. For example, even though a host might utilize an
+ unauthenticated link layer control frame to conclude that a link has
+ become operational, it can use SEND [RFC3971] or authenticated DHCP
+ [RFC3118] in order to obtain secure Internet layer configuration.
+
+4.3. Denial of Service
+
+ Link indication proposals need to be particularly careful to avoid
+ enabling denial-of-service attacks that can be mounted at a distance.
+ While wireless links are naturally vulnerable to interference, such
+ attacks can only be perpetrated by an attacker capable of
+ establishing radio contact with the target network. However, attacks
+ that can be mounted from a distance, either by an attacker on another
+ point of attachment within the same network or by an off-link
+ attacker, expand the level of vulnerability.
+
+ The transport of link indications can increase risk by enabling
+ vulnerabilities exploitable only by attackers on the local link to be
+ executed across the Internet. Similarly, by integrating link
+ indications with upper layers, proposals may enable a spoofed link
+ layer frame to consume more resources on the host than might
+ otherwise be the case. As a result, while it is important for upper
+ layers to validate link indications, they should not expend excessive
+ resources in doing so.
+
+ Congestion control is not only a transport issue, it is also a
+ security issue. In order to not provide leverage to an attacker, a
+ single forged link layer frame should not elicit a magnified response
+
+
+
+IAB Informational [Page 30]
+
+RFC 4907 Link Indications June 2007
+
+
+ from one or more hosts, by generating either multiple responses or a
+ single larger response. For example, proposals should not enable
+ multiple hosts to respond to a frame with a multicast destination
+ address.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5.2. Informative References
+
+ [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816,
+ July 1982.
+
+ [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
+ June 1988.
+
+ [RFC1122] Braden, R., "Requirements for Internet Hosts --
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
+ 1989.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
+ 1191, November 1990.
+
+ [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC
+ 1256, September 1991.
+
+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
+ Specification, Implementation and Analysis", RFC 1305,
+ March 1992.
+
+ [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
+ Control Protocol", RFC 1307, March 1992.
+
+ [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
+ RFC 1812, June 1995.
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
+ D., and E. Lear, "Address Allocation for Private
+ Internets", BCP 5, RFC 1918, February 1996.
+
+
+
+IAB Informational [Page 31]
+
+RFC 4907 Link Indications June 2007
+
+
+ [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
+ Discovery for IP version 6", RFC 1981, June 1996.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+ 1998.
+
+ [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461, December
+ 1998.
+
+ [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
+ Presence and Instant Messaging", RFC 2778, February
+ 2000.
+
+ [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
+ Window Validation", RFC 2861, June 2000.
+
+ [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
+ BCP 41, September 2000.
+
+ [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
+ 2923, September 2000.
+
+ [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+ Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M.,
+ Zhang, L., and V. Paxson, "Stream Control Transmission
+ Protocol" RFC 2960, October 2000.
+
+ [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
+ Messages", RFC 3118, June 2001.
+
+ [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+ C., and M. Carney, "Dynamic Host Configuration
+ Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers
+ on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC
+ 3366, August 2002.
+
+ [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
+ C., and D. Gurle, "Session Initiation Protocol (SIP)
+ Extension for Instant Messaging", RFC 3428, December
+ 2002.
+
+
+
+
+
+IAB Informational [Page 32]
+
+RFC 4907 Link Indications June 2007
+
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
+ H. Levkowetz, "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
+ Support in IPv6", RFC 3775, June 2004.
+
+ [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
+ protocol (XMPP): Instant Messaging and Presence", RFC
+ 3921, October 2004.
+
+ [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+ Configuration of Link-Local IPv4 Addresses", RFC 3927,
+ May 2005.
+
+ [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
+ "SEcure Neighbor Discovery (SEND)", RFC 3971, March
+ 2005.
+
+ [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
+ Congestion Control Protocol (DCCP)", RFC 4340, March
+ 2006.
+
+ [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
+ (HIP) Architecture", RFC 4423, May 2006.
+
+ [RFC4429] Moore, N., "Optimistic Duplicate Address Detection
+ (DAD) for IPv6", RFC 4429, April 2006.
+
+ [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
+ Network Attachment in IPv4 (DNAv4)", RFC 4436, March
+ 2006.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
+ MTU Discovery", RFC 4821, March 2007.
+
+ [Alimian] Alimian, A., "Roaming Interval Measurements",
+ 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE
+ 802.11 submission (work in progress), March 2004.
+
+ [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G., and R.
+ Morris, "Link-level Measurements from an 802.11b Mesh
+ Network", SIGCOMM '04, September 2004, Portland,
+ Oregon.
+
+
+
+
+
+
+
+IAB Informational [Page 33]
+
+RFC 4907 Link Indications June 2007
+
+
+ [Bakshi] Bakshi, B., Krishna, P., Vadiya, N., and D.Pradhan,
+ "Improving Performance of TCP over Wireless Networks",
+ Proceedings of the 1997 International Conference on
+ Distributed Computer Systems, Baltimore, May 1997.
+
+ [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
+ Detection", Work in Progress, March 2007.
+
+ [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion
+ Losses from Wireless Losses Using Interarrival Times
+ at the Receiver", Proceedings of the IEEE Symposium on
+ Application-Specific Systems and Software Engineering
+ and Technology, Richardson, TX, Mar 1999.
+
+ [CARA] Kim, J., Kim, S., and S. Choi, "CARA: Collision-Aware
+ Rate Adaptation for IEEE 802.11 WLANs", Korean
+ Institute of Communication Sciences (KICS) Journal,
+ Feb. 2006
+
+ [Chandran] Chandran, K., Raghunathan, S., Venkatesan, S., and R.
+ Prakash, "A Feedback-Based Scheme for Improving TCP
+ Performance in Ad-Hoc Wireless Networks", Proceedings
+ of the 18th International Conference on Distributed
+ Computing Systems (ICDCS), Amsterdam, May 1998.
+
+ [DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6
+ (DNAv6)", Work in Progress, March 2007.
+
+ [E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit
+ 'Link-Up' Notification", Work in Progress, October
+ 2003.
+
+ [EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba,
+ Y., and F. Bersani, "EAP IKEv2 Method", Work in
+ Progress, March 2007.
+
+ [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and
+ Analysis of the Error Characteristics of an In-
+ Building Wireless Network", SIGCOMM '96, August 1996,
+ Stanford, CA.
+
+ [Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion
+ Control for Mobility", Technical Report CR-2005-
+ 213838, NASA Glenn Research Center, July 2005.
+
+
+
+
+
+
+
+IAB Informational [Page 34]
+
+RFC 4907 Link Indications June 2007
+
+
+ [EfficientEthernet]
+ Gunaratne, C. and K. Christensen, "Ethernet Adaptive
+ Link Rate: System Design and Performance Evaluation",
+ Proceedings of the IEEE Conference on Local Computer
+ Networks, pp. 28-35, November 2006.
+
+ [Eggert] Eggert, L., Schuetz, S., and S. Schmid, "TCP
+ Extensions for Immediate Retransmissions", Work in
+ Progress, June 2005.
+
+ [Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive
+ Transport-Layer Interfaces", MobiArch '06, San
+ Francisco, CA.
+
+ [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket,
+ and Robert Morris, "A High-Throughput Path Metric for
+ Multi-Hop Wireless Routing", Proceedings of the 9th
+ ACM International Conference on Mobile Computing and
+ Networking (MobiCom '03), San Diego, California,
+ September 2003.
+
+ [ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in
+ multi-radio, multi-hop wireless mesh networks",
+ Proceedings of ACM MobiCom Conference, September 2003.
+
+ [ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M., and M.
+ Srivastava, "A Radio Aware Routing Protocol for
+ Wireless Mesh Networks", UCLA Computer Science
+ Department, Los Angeles, CA.
+
+ [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for
+ Link Layer Triggers", submission to IEEE 802.21 (work
+ in progress), March 2004, available at:
+ <http://www.ieee802.org/handoff/march04_meeting_docs/
+ Generalized_triggers-02.pdf>.
+
+ [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance
+ over Wireless Links", Proceedings of TENCON'98, pages
+ 332-335. IEEE, December 1998.
+
+ [Gont] Gont, F., "ICMP attacks against TCP", Work in
+ Progress, October 2006.
+
+ [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical
+ Handovers on Performance of TCP-Friendly Rate
+ Control", to appear in ACM MCCR, 2004.
+
+
+
+
+
+IAB Informational [Page 35]
+
+RFC 4907 Link Indications June 2007
+
+
+ [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
+ Transport Protocols", Computer Communications Review
+ (CCR) 34, 2 (2003).
+
+ [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K., and H.
+ Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac
+ '04, October 1, 2004, Philadelphia, Pennsylvania, USA.
+
+ [Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation
+ for IEEE 802.11", Ph.D. Thesis, Technical University
+ of Delft, Netherlands, ISBN-10:90-9020513-6, ISBN-
+ 13:978-90-9020513-7, March 2006.
+
+ [HMP] Lee, S., Cho, J., and A. Campbell, "Hotspot Mitigation
+ Protocol (HMP)", Work in Progress, October 2003.
+
+ [Holland] Holland, G. and N. Vaidya, "Analysis of TCP
+ Performance over Mobile Ad Hoc Networks", Proceedings
+ of the Fifth International Conference on Mobile
+ Computing and Networking, pages 219-230. ACM/IEEE,
+ Seattle, August 1999.
+
+ [Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya,
+ S., and C. Diot, "Analysis of link failures in an IP
+ backbone", Proc. of ACM Sigcomm Internet Measurement
+ Workshop, November, 2002.
+
+ [IEEE-802.1X] Institute of Electrical and Electronics Engineers,
+ "Local and Metropolitan Area Networks: Port-Based
+ Network Access Control", IEEE Standard 802.1X,
+ December 2004.
+
+ [IEEE-802.11] Institute of Electrical and Electronics Engineers,
+ "Wireless LAN Medium Access Control (MAC) and Physical
+ Layer (PHY) Specifications", IEEE Standard 802.11,
+ 2003.
+
+ [IEEE-802.11e] Institute of Electrical and Electronics Engineers,
+ "Standard for Telecommunications and Information
+ Exchange Between Systems - LAN/MAN Specific
+ Requirements - Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) Specifications
+ - Amendment 8: Medium Access Control (MAC) Quality of
+ Service Enhancements", IEEE 802.11e, November 2005.
+
+
+
+
+
+
+
+IAB Informational [Page 36]
+
+RFC 4907 Link Indications June 2007
+
+
+ [IEEE-802.11F] Institute of Electrical and Electronics Engineers,
+ "IEEE Trial-Use Recommended Practice for Multi-Vendor
+ Access Point Interoperability via an Inter-Access
+ Point Protocol Across Distribution Systems Supporting
+ IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now
+ deprecated).
+
+ [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
+ "Supplement to Standard for Telecommunications and
+ Information Exchange Between Systems - LAN/MAN
+ Specific Requirements - Part 11: Wireless LAN Medium
+ Access Control (MAC) and Physical Layer (PHY)
+ Specifications: Specification for Enhanced Security",
+ IEEE 802.11i, July 2004.
+
+ [IEEE-802.11k] Institute of Electrical and Electronics Engineers,
+ "Draft Amendment to Telecommunications and Information
+ Exchange Between Systems - LAN/MAN Specific
+ Requirements - Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) Specifications
+ - Amendment 7: Radio Resource Management", IEEE
+ 802.11k/D7.0, January 2007.
+
+ [IEEE-802.21] Institute of Electrical and Electronics Engineers,
+ "Draft Standard for Telecommunications and Information
+ Exchange Between Systems - LAN/MAN Specific
+ Requirements - Part 21: Media Independent Handover",
+ IEEE 802.21D0, June 2005.
+
+ [Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-
+ Performance Wireless LAN for the Unlicensed Band",
+ Bell Labs Technical Journal, Summer 1997.
+
+ [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-
+ trigger method for improving TCP performance over
+ Mobile IPv6", Work in Progress, August 2004.
+
+ [Kotz] Kotz, D., Newport, C., and C. Elliot, "The mistaken
+ axioms of wireless-network research", Dartmouth
+ College Computer Science Technical Report TR2003-467,
+ July 2003.
+
+ [Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C.,
+ and M. Allman, "Explicit Transport Error Notification
+ (ETEN) for Error-Prone Wireless and Satellite
+ Networks", Computer Networks, 46 (3), October 2004.
+
+
+
+
+
+IAB Informational [Page 37]
+
+RFC 4907 Link Indications June 2007
+
+
+ [Lacage] Lacage, M., Manshaei, M., and T. Turletti, "IEEE
+ 802.11 Rate Adaptation: A Practical Approach", MSWiM
+ '04, October 4-6, 2004, Venezia, Italy.
+
+ [Lee] Park, S., Lee, M., and J. Korhonen, "Link
+ Characteristics Information for Mobile IP", Work in
+ Progress, January 2007.
+
+ [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements
+ for TCP/IP over GSM", Proceedings of IEEE Infocom '99,
+ March 1999.
+
+ [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle,
+ J., and M. Laurent-Maknavicius, "MIPv6 Authorization
+ and Configuration based on EAP", Work in Progress,
+ October 2006.
+
+ [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical
+ Analysis of the IEEE 802.11 MAC Layer Handoff
+ Process", CS-TR-4395, University of Maryland
+ Department of Computer Science, September 2002.
+
+ [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control -
+ Buffer Requirements and Overload Performance",
+ Technical Memorandum, AT&T Bell Laboratories, October
+ 1994.
+
+ [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4
+ with 802.11", Work in Progress, March 2004.
+
+ [ONOE] Onoe Rate Control,
+ <http://madwifi.org/browser/trunk/ath_rate/onoe>.
+
+ [Park] Park, S., Njedjou, E., and N. Montavont, "L2 Triggers
+ Optimized Mobile IPv6 Vertical Handover: The
+ 802.11/GPRS Example", Work in Progress, July 2004.
+
+ [Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for
+ IEEE802.11 WLAN via received signal strength
+ measurement", IEEE International Conference on
+ Communications, 2003 (ICC '03), volume 2, pages 1108-
+ 1113, Anchorage, Alaska, USA, May 2003.
+
+ [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn,
+ G., and S. Josefsson, "Protected EAP Protocol (PEAP)
+ Version 2", Work in Progress, October 2004.
+
+
+
+
+
+IAB Informational [Page 38]
+
+RFC 4907 Link Indications June 2007
+
+
+ [PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio
+ network protocols", Proceedings of the IEEE, 75(1),
+ January 1987.
+
+ [Qiao] Qiao D., Choi, S., Jain, A., and Kang G. Shin, "MiSer:
+ An Optimal Low-Energy Transmission Strategy for IEEE
+ 802.11 a/h", in Proc. ACM MobiCom'03, San Diego, CA,
+ September 2003.
+
+ [RBAR] Holland, G., Vaidya, N., and P. Bahl, "A Rate-Adaptive
+ MAC Protocol for Multi-Hop Wireless Networks",
+ Proceedings ACM MOBICOM, July 2001.
+
+ [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast
+ Handoff for 802.11 Infrastructure Networks",
+ Proceedings of the IEEE InfoCon 2005, March 2005.
+
+ [Robust] Wong, S., Yang, H ., Lu, S., and V. Bharghavan,
+ "Robust Rate Adaptation for 802.11 Wireless Networks",
+ ACM MobiCom'06, Los Angeles, CA, September 2006.
+
+ [SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks",
+ MIT Master's Thesis, 2005.
+
+ [Scott] Scott, J., Mapp, G., "Link Layer Based TCP
+ Optimisation for Disconnecting Networks", ACM SIGCOMM
+ Computer Communication Review, 33(5), October 2003.
+
+ [Schuetz] Schutz, S., Eggert, L., Schmid, S., and M. Brunner,
+ "Protocol Enhancements for Intermittently Connected
+ Hosts", ACM SIGCOMM Computer Communications Review,
+ Volume 35, Number 2, July 2005.
+
+ [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A.
+ Chambers and Robert Morris, "Performance of Multihop
+ Wireless Networks: Shortest Path is Not Enough",
+ Proceedings of the First Workshop on Hot Topics in
+ Networking (HotNets-I), Princeton, New Jersey, October
+ 2002.
+
+ [TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework
+ and Requirements for TRIGTRAN", Work in Progress,
+ August 2003.
+
+ [Vatn] Vatn, J., "An experimental study of IEEE 802.11b
+ handover performance and its effect on voice traffic",
+ TRITA-IMIT-TSLAB R 03:01, KTH Royal Institute of
+ Technology, Stockholm, Sweden, July 2003.
+
+
+
+IAB Informational [Page 39]
+
+RFC 4907 Link Indications June 2007
+
+
+ [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce
+ IEEE 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN
+ R 03:02, KTH Royal Institute of Technology, Stockholm,
+ Sweden, April 2003.
+
+ [Vertical] Zhang, Q., Guo, C., Guo, Z., and W. Zhu, "Efficient
+ Mobility Management for Vertical Handoff between WWAN
+ and WLAN", IEEE Communications Magazine, November
+ 2003.
+
+ [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)",
+ Work in Progress, February 1999.
+
+ [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach
+ to Enhancing Internet Performance over Wireless
+ Links", Ph.D. thesis, University of California at San
+ Diego, 1999.
+
+ [Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in
+ Progress, June 2002.
+
+6. Acknowledgments
+
+ The authors would like to acknowledge James Kempf, Phil Roberts,
+ Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka
+ Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy, and
+ Janne Peisa for contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 40]
+
+RFC 4907 Link Indications June 2007
+
+
+Appendix A. Literature Review
+
+ This appendix summarizes the literature with respect to link
+ indications on wireless local area networks.
+
+A.1. Link Layer
+
+ The characteristics of wireless links have been found to vary
+ considerably depending on the environment.
+
+ In "Performance of Multihop Wireless Networks: Shortest Path is Not
+ Enough" [Shortest], the authors studied the performance of both an
+ indoor and outdoor mesh network. By measuring inter-node throughput,
+ the best path between nodes was computed. The throughput of the best
+ path was compared with the throughput of the shortest path computed
+ based on a hop-count metric. In almost all cases, the shortest path
+ route offered considerably lower throughput than the best path.
+
+ In examining link behavior, the authors found that rather than
+ exhibiting a bi-modal distribution between "up" (low loss rate) and
+ "down" (high loss rate), many links exhibited intermediate loss
+ rates. Asymmetry was also common, with 30 percent of links
+ demonstrating substantial differences in the loss rates in each
+ direction. As a result, on wireless networks the measured throughput
+ can differ substantially from the negotiated rate due to
+ retransmissions, and successful delivery of routing packets is not
+ necessarily an indication that the link is useful for delivery of
+ data.
+
+ In "Measurement and Analysis of the Error Characteristics of an
+ In-Building Wireless Network" [Eckhardt], the authors characterize
+ the performance of an AT&T Wavelan 2 Mbps in-building WLAN operating
+ in Infrastructure mode on the Carnegie Mellon campus. In this study,
+ very low frame loss was experienced. As a result, links could be
+ assumed to operate either very well or not at all.
+
+ In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
+ the authors analyze the causes of frame loss in a 38-node urban
+ multi-hop 802.11 ad-hoc network. In most cases, links that are very
+ bad in one direction tend to be bad in both directions, and links
+ that are very good in one direction tend to be good in both
+ directions. However, 30 percent of links exhibited loss rates
+ differing substantially in each direction.
+
+ Signal to noise ratio (SNR) and distance showed little value in
+ predicting loss rates, and rather than exhibiting a step-function
+ transition between "up" (low loss) or "down" (high loss) states,
+ inter-node loss rates varied widely, demonstrating a nearly uniform
+
+
+
+IAB Informational [Page 41]
+
+RFC 4907 Link Indications June 2007
+
+
+ distribution over the range at the lower rates. The authors
+ attribute the observed effects to multi-path fading, rather than
+ attenuation or interference.
+
+ The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of
+ link conditions observed in practice. While for indoor
+ infrastructure networks site surveys and careful measurement can
+ assist in promoting ideal behavior, in ad-hoc/mesh networks node
+ mobility and external factors such as weather may not be easily
+ controlled.
+
+ Considerable diversity in behavior is also observed due to
+ implementation effects. "Techniques to reduce IEEE 802.11b MAC layer
+ handover time" [Velayos] measured handover times for a stationary STA
+ after the AP was turned off. This study divided handover times into
+ detection (determination of disconnection from the existing point of
+ attachment), search (discovery of alternative attachment points), and
+ execution (connection to an alternative point of attachment) phases.
+ These measurements indicated that the duration of the detection phase
+ (the largest component of handoff delay) is determined by the number
+ of non-acknowledged frames triggering the search phase and delays due
+ to precursors such as RTS/CTS and rate adaptation.
+
+ Detection behavior varied widely between implementations. For
+ example, network interface cards (NICs) designed for desktops
+ attempted more retransmissions prior to triggering search as compared
+ with laptop designs, since they assumed that the AP was always in
+ range, regardless of whether the Beacon was received.
+
+ The study recommends that the duration of the detection phase be
+ reduced by initiating the search phase as soon as collisions can be
+ excluded as the cause of non-acknowledged transmissions; the authors
+ recommend three consecutive transmission failures as the cutoff.
+ This approach is both quicker and more immune to multi-path
+ interference than monitoring of the SNR. Where the STA is not
+ sending or receiving frames, it is recommended that Beacon reception
+ be tracked in order to detect disconnection, and that Beacon spacing
+ be reduced to 60 ms in order to reduce detection times. In order to
+ compensate for more frequent triggering of the search phase, the
+ authors recommend algorithms for wait time reduction, as well as
+ interleaving of search and data frame transmission.
+
+ "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process"
+ [Mishra] investigates handoff latencies obtained with three mobile
+ STA implementations communicating with two APs. The study found that
+ there is a large variation in handoff latency among STA and AP
+ implementations and that implementations utilize different message
+ sequences. For example, one STA sends a Reassociation Request prior
+
+
+
+IAB Informational [Page 42]
+
+RFC 4907 Link Indications June 2007
+
+
+ to authentication, which results in receipt of a Deauthenticate
+ message. The study divided handoff latency into discovery,
+ authentication, and reassociation exchanges, concluding that the
+ discovery phase was the dominant component of handoff delay. Latency
+ in the detection phase was not investigated.
+
+ "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks"
+ [Ramani] weighs the pros and cons of active versus passive scanning.
+ The authors point out the advantages of timed Beacon reception, which
+ had previously been incorporated into [IEEE-802.11k]. Timed Beacon
+ reception allows the station to continually keep up to date on the
+ signal to noise ratio of neighboring APs, allowing handoff to occur
+ earlier. Since the station does not need to wait for initial and
+ subsequent responses to a broadcast Probe Response (MinChannelTime
+ and MaxChannelTime, respectively), performance is comparable to what
+ is achievable with 802.11k Neighbor Reports and unicast Probe
+ Requests.
+
+ The authors measured the channel switching delay, the time it takes
+ to switch to a new frequency and begin receiving frames.
+ Measurements ranged from 5 ms to 19 ms per channel; where timed
+ Beacon reception or interleaved active scanning is used, switching
+ time contributes significantly to overall handoff latency. The
+ authors propose deployment of APs with Beacons synchronized via
+ Network Time Protocol (NTP) [RFC1305], enabling a driver implementing
+ SyncScan to work with legacy APs without requiring implementation of
+ new protocols. The authors measured the distribution of inter-
+ arrival times for stations implementing SyncScan, with excellent
+ results.
+
+ "Roaming Interval Measurements" [Alimian] presents data on the
+ behavior of stationary STAs after the AP signal has been shut off.
+ This study highlighted implementation differences in rate adaptation
+ as well as detection, scanning, and handoff. As in [Velayos],
+ performance varied widely between implementations, from half an order
+ of magnitude variation in rate adaptation to an order of magnitude
+ difference in detection times, two orders of magnitude in scanning,
+ and one and a half orders of magnitude in handoff times.
+
+ "An experimental study of IEEE 802.11b handoff performance and its
+ effect on voice traffic" [Vatn] describes handover behavior observed
+ when the signal from the AP is gradually attenuated, which is more
+ representative of field experience than the shutoff techniques used
+ in [Velayos]. Stations were configured to initiate handover when
+ signal strength dipped below a threshold, rather than purely based on
+ frame loss, so that they could begin handover while still connected
+ to the current AP. It was noted that stations continued to receive
+ data frames during the search phase. Station-initiated
+
+
+
+IAB Informational [Page 43]
+
+RFC 4907 Link Indications June 2007
+
+
+ Disassociation and pre-authentication were not observed in this
+ study.
+
+A.1.1. Link Indications
+
+ Within a link layer, the definition of "Link Up" and "Link Down" may
+ vary according to the deployment scenario. For example, within PPP
+ [RFC1661], either peer may send an LCP-Terminate frame in order to
+ terminate the PPP link layer, and a link may only be assumed to be
+ usable for sending network protocol packets once Network Control
+ Protocol (NCP) negotiation has completed for that protocol.
+
+ Unlike PPP, IEEE 802 does not include facilities for network layer
+ configuration, and the definition of "Link Up" and "Link Down" varies
+ by implementation. Empirical evidence suggests that the definition
+ of "Link Up" and "Link Down" may depend on whether the station is
+ mobile or stationary, whether infrastructure or ad-hoc mode is in
+ use, and whether security and Inter-Access Point Protocol (IAPP) is
+ implemented.
+
+ Where a STA encounters a series of consecutive non-acknowledged
+ frames while having missed one or more Beacons, the most likely cause
+ is that the station has moved out of range of the AP. As a result,
+ [Velayos] recommends that the station begin the search phase after
+ collisions can be ruled out; since this approach does not take rate
+ adaptation into account, it may be somewhat aggressive. Only when no
+ alternative workable rate or point of attachment is found is a "Link
+ Down" indication returned.
+
+ In a stationary point-to-point installation, the most likely cause of
+ an outage is that the link has become impaired, and alternative
+ points of attachment may not be available. As a result,
+ implementations configured to operate in this mode tend to be more
+ persistent. For example, within 802.11 the short interframe space
+ (SIFS) interval may be increased and MIB variables relating to
+ timeouts (such as dot11AuthenticationResponseTimeout,
+ dot11AssociationResponseTimeout, dot11ShortRetryLimit, and
+ dot11LongRetryLimit) may be set to larger values. In addition, a
+ "Link Down" indication may be returned later.
+
+ In IEEE 802.11 ad-hoc mode with no security, reception of data frames
+ is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a
+ result, reception of data frames is enabled at any time, and no
+ explicit "Link Up" indication exists.
+
+ In Infrastructure mode, IEEE 802.11-2003 enables reception of data
+ frames only in State 3 ("Authenticated" and "Associated"). As a
+ result, a transition to State 3 (e.g., completion of a successful
+
+
+
+IAB Informational [Page 44]
+
+RFC 4907 Link Indications June 2007
+
+
+ Association or Reassociation exchange) enables sending and receiving
+ of network protocol packets and a transition from State 3 to State 2
+ (reception of a "Disassociate" frame) or State 1 (reception of a
+ "Deauthenticate" frame) disables sending and receiving of network
+ protocol packets. As a result, IEEE 802.11 stations typically signal
+ "Link Up" on receipt of a successful Association/Reassociation
+ Response.
+
+ As described within [IEEE-802.11F], after sending a Reassociation
+ Response, an Access Point will send a frame with the station's source
+ address to a multicast destination. This causes switches within the
+ Distribution System (DS) to update their learning tables, readying
+ the DS to forward frames to the station at its new point of
+ attachment. Were the AP to not send this "spoofed" frame, the
+ station's location would not be updated within the distribution
+ system until it sends its first frame at the new location. Thus, the
+ purpose of spoofing is to equalize uplink and downlink handover
+ times. This enables an attacker to deny service to authenticated and
+ associated stations by spoofing a Reassociation Request using the
+ victim's MAC address, from anywhere within the ESS. Without
+ spoofing, such an attack would only be able to disassociate stations
+ on the AP to which the Reassociation Request was sent.
+
+ The signaling of "Link Down" is considerably more complex. Even
+ though a transition to State 2 or State 1 results in the station
+ being unable to send or receive IP packets, this does not necessarily
+ imply that such a transition should be considered a "Link Down"
+ indication. In an infrastructure network, a station may have a
+ choice of multiple Access Points offering connection to the same
+ network. In such an environment, a station that is unable to reach
+ State 3 with one Access Point may instead choose to attach to another
+ Access Point. Rather than registering a "Link Down" indication with
+ each move, the station may instead register a series of "Link Up"
+ indications.
+
+ In [IEEE-802.11i], forwarding of frames from the station to the
+ distribution system is only feasible after the completion of the
+ 4-way handshake and group-key handshake, so that entering State 3 is
+ no longer sufficient. This has resulted in several observed
+ problems. For example, where a "Link Up" indication is triggered on
+ the station by receipt of an Association/Reassociation Response, DHCP
+ [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be
+ triggered prior to when the link is usable by the Internet layer,
+ resulting in configuration delays or failures. Similarly, transport
+ layer connections will encounter packet loss, resulting in back-off
+ of retransmission timers.
+
+
+
+
+
+IAB Informational [Page 45]
+
+RFC 4907 Link Indications June 2007
+
+
+A.1.2. Smart Link Layer Proposals
+
+ In order to improve link layer performance, several studies have
+ investigated "smart link layer" proposals.
+
+ "Advice to link designers on link Automatic Repeat reQuest (ARQ)"
+ [RFC3366] provides advice to the designers of digital communication
+ equipment and link-layer protocols employing link-layer Automatic
+ Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
+ timers, persistency in retransmission, and the challenges that arise
+ from sharing links between multiple flows and from different
+ transport requirements.
+
+ In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the
+ authors describe how the Global System for Mobile Communications
+ (GSM)-reliable and unreliable link layer modes can be simultaneously
+ utilized without higher layer control. Where a reliable link layer
+ protocol is required (where reliable transports such TCP and Stream
+ Control Transmission Protocol (SCTP) [RFC2960] are used), the Radio
+ Link Protocol (RLP) can be engaged; with delay-sensitive applications
+ such as those based on UDP, the transparent mode (no RLP) can be
+ used. The authors also describe how PPP negotiation can be optimized
+ over high-latency GSM links using "Quickstart-PPP".
+
+ In "Link Layer Based TCP Optimisation for Disconnecting Networks"
+ [Scott], the authors describe performance problems that occur with
+ reliable transport protocols facing periodic network disconnections,
+ such as those due to signal fading or handoff. The authors define a
+ disconnection as a period of connectivity loss that exceeds a
+ retransmission timeout, but is shorter than the connection lifetime.
+ One issue is that link-unaware senders continue to back off during
+ periods of disconnection. The authors suggest that a link-aware
+ reliable transport implementation halt retransmission after receiving
+ a "Link Down" indication. Another issue is that on reconnection the
+ lengthened retransmission times cause delays in utilizing the link.
+
+ To improve performance, a "smart link layer" is proposed, which
+ stores the first packet that was not successfully transmitted on a
+ connection, then retransmits it upon receipt of a "Link Up"
+ indication. Since a disconnection can result in hosts experiencing
+ different network conditions upon reconnection, the authors do not
+ advocate bypassing slow start or attempting to raise the congestion
+ window. Where IPsec is used and connections cannot be differentiated
+ because transport headers are not visible, the first untransmitted
+ packet for a given sender and destination IP address can be
+ retransmitted. In addition to looking at retransmission of a single
+ packet per connection, the authors also examined other schemes such
+
+
+
+
+IAB Informational [Page 46]
+
+RFC 4907 Link Indications June 2007
+
+
+ as retransmission of multiple packets and simulated duplicate
+ reception of single or multiple packets (known as rereception).
+
+ In general, retransmission schemes were superior to rereception
+ schemes, since rereception cannot stimulate fast retransmit after a
+ timeout. Retransmission of multiple packets did not appreciably
+ improve performance over retransmission of a single packet. Since
+ the focus of the research was on disconnection rather than just lossy
+ channels, a two-state Markov model was used, with the "up" state
+ representing no loss, and the "down" state representing 100 percent
+ loss.
+
+ In "Multi Service Link Layers: An Approach to Enhancing Internet
+ Performance over Wireless Links" [Xylomenos], the authors use ns-2 to
+ simulate the performance of various link layer recovery schemes (raw
+ link without retransmission, go back N, XOR-based FEC, selective
+ repeat, Karn's RLP, out-of-sequence RLP, and Berkeley Snoop) in
+ stand-alone file transfer, Web browsing, and continuous media
+ distribution. While selective repeat and Karn's RLP provide the
+ highest throughput for file transfer and Web browsing scenarios,
+ continuous media distribution requires a combination of low delay and
+ low loss and the out-of-sequence RLP performed best in this scenario.
+ Since the results indicate that no single link layer recovery scheme
+ is optimal for all applications, the authors propose that the link
+ layer implement multiple recovery schemes. Simulations of the
+ multi-service architecture showed that the combination of a low-error
+ rate recovery scheme for TCP (such as Karn's RLP) and a low-delay
+ scheme for UDP traffic (such as out-of-sequence RLP) provides for
+ good performance in all scenarios. The authors then describe how a
+ multi-service link layer can be integrated with Differentiated
+ Services.
+
+ In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed
+ Band" [Kamerman], the authors propose an open-loop rate adaptation
+ algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender
+ adjusts the rate upwards after a fixed number of successful
+ transmissions, and adjusts the rate downwards after one or two
+ consecutive failures. If after an upwards rate adjustment the
+ transmission fails, the rate is immediately readjusted downwards.
+
+ In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks"
+ [RBAR], the authors propose a closed-loop rate adaptation approach
+ that requires incompatible changes to the IEEE 802.11 MAC. In order
+ to enable the sender to better determine the transmission rate, the
+ receiver determines the packet length and signal to noise ratio (SNR)
+ of a received RTS frame and calculates the corresponding rate based
+ on a theoretical channel model, rather than channel usage statistics.
+ The recommended rate is sent back in the CTS frame. This allows the
+
+
+
+IAB Informational [Page 47]
+
+RFC 4907 Link Indications June 2007
+
+
+ rate (and potentially the transmit power) to be optimized on each
+ transmission, albeit at the cost of requiring RTS/CTS for every frame
+ transmission.
+
+ In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE
+ 802.11 a/h" [Qiao], the authors propose a scheme for optimizing
+ transmit power. The proposal mandates the use of RTS/CTS in order to
+ deal with hidden nodes, requiring that CTS and ACK frames be sent at
+ full power. The authors utilize a theoretical channel model rather
+ than one based on channel usage statistics.
+
+ In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage], the
+ authors distinguish between low-latency implementations, which enable
+ per-packet rate decisions, and high-latency implementations, which do
+ not. The former implementations typically include dedicated CPUs in
+ their design, enabling them to meet real-time requirements. The
+ latter implementations are typically based on highly integrated
+ designs in which the upper MAC is implemented on the host. As a
+ result, due to operating system latencies the information required to
+ make per-packet rate decisions may not be available in time.
+
+ The authors propose an Adaptive ARF (AARF) algorithm for use with
+ low-latency implementations. This enables rapid downward rate
+ negotiation on failure to receive an ACK, while increasing the number
+ of successful transmissions required for upward rate negotiation.
+ The AARF algorithm is therefore highly stable in situations where
+ channel properties are changing slowly, but slow to adapt upwards
+ when channel conditions improve. In order to test the algorithm, the
+ authors utilized ns-2 simulations as well as implementing a version
+ of AARF adapted to a high-latency implementation, the AR 5212
+ chipset. The Multiband Atheros Driver for WiFi (MadWiFi) driver
+ enables a fixed schedule of rates and retries to be provided when a
+ frame is queued for transmission. The adapted algorithm, known as
+ the Adaptive Multi Rate Retry (AMRR), requests only one transmission
+ at each of three rates, the last of which is the minimum available
+ rate. This enables adaptation to short-term fluctuations in the
+ channel with minimal latency. The AMRR algorithm provides
+ performance considerably better than the existing MadWifi driver.
+
+ In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal
+ Strength Measurement" [Pavon], the authors propose an algorithm by
+ which a STA adjusts the transmission rate based on a comparison of
+ the received signal strength (RSS) from the AP with dynamically
+ estimated threshold values for each transmission rate. Upon
+ reception of a frame, the STA updates the average RSS, and on
+ transmission the STA selects a rate and adjusts the RSS threshold
+ values based on whether or not the transmission is successful. In
+ order to validate the algorithm, the authors utilized an OPNET
+
+
+
+IAB Informational [Page 48]
+
+RFC 4907 Link Indications June 2007
+
+
+ simulation without interference, and an ideal curve of bit error rate
+ (BER) vs. signal to noise ratio (SNR) was assumed. Not surprisingly,
+ the simulation results closely matched the maximum throughput
+ achievable for a given signal to noise ratio, based on the ideal BER
+ vs. SNR curve.
+
+ In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors
+ describe a hybrid technique utilizing Signal Strength Indication
+ (SSI) data to constrain the potential rates selected by statistics-
+ based automatic rate control. Statistics-based rate control
+ techniques include:
+
+ Maximum Throughput
+
+ This technique, which was chosen as the statistics-based technique in
+ the hybrid scheme, sends a fraction of data at adjacent rates in
+ order to estimate which rate provides the maximum throughput. Since
+ accurate estimation of throughput requires a minimum number of frames
+ to be sent at each rate, and only a fraction of frames are utilized
+ for this purpose, this technique adapts more slowly at lower rates;
+ with 802.11b rates, the adaptation time scale is typically on the
+ order of a second. Depending on how many rates are tested, this
+ technique can enable adaptation beyond adjacent rates. However,
+ where maximum rate and low frame loss are already being encountered,
+ this technique results in lower throughput.
+
+ Frame Error Rate (FER) Control
+
+ This technique estimates the FER, attempting to keep it between a
+ lower limit (if FER moves below, increase rate) and upper limit (if
+ FER moves above, decrease rate). Since this technique can utilize
+ all the transmitted data, it can respond faster than maximum
+ throughput techniques. However, there is a tradeoff of reaction time
+ versus FER estimation accuracy; at lower rates either reaction times
+ slow or FER estimation accuracy will suffer. Since this technique
+ only measures the FER at the current rate, it can only enable
+ adaptation to adjacent rates.
+
+ Retry-based
+
+ This technique modifies FER control techniques by enabling rapid
+ downward rate adaptation after a number (5-10) of unsuccessful
+ retransmissions. Since fewer packets are required, the sensitivity
+ of reaction time to rate is reduced. However, upward rate adaptation
+ proceeds more slowly since it is based on a collection of FER data.
+ This technique is limited to adaptation to adjacent rates, and it has
+ the disadvantage of potentially worsening frame loss due to
+ contention.
+
+
+
+IAB Informational [Page 49]
+
+RFC 4907 Link Indications June 2007
+
+
+ While statistics-based techniques are robust against short-lived link
+ quality changes, they do not respond quickly to long-lived changes.
+ By constraining the rate selected by statistics-based techniques
+ based on ACK SSI versus rate data (not theoretical curves), more
+ rapid link adaptation was enabled. In order to ensure rapid
+ adaptation during rapidly varying conditions, the rate constraints
+ are tightened when the SSI values are changing rapidly, encouraging
+ rate transitions. The authors validated their algorithms by
+ implementing a driver for the Atheros AR5000 chipset, and then
+ testing its response to insertion and removal from a microwave oven
+ acting as a Faraday cage. The hybrid algorithm dropped many fewer
+ packets than the maximum throughput technique by itself.
+
+ In order to estimate the SSI of data at the receiver, the ACK SSI was
+ used. This approach does not require the receiver to provide the
+ sender with the received power, so that it can be implemented without
+ changing the IEEE 802.11 MAC. Calibration of the rate versus ACK SSI
+ curves does not require a symmetric channel, but it does require that
+ channel properties in both directions vary in a proportional way and
+ that the ACK transmit power remains constant. The authors checked
+ the proportionality assumption and found that the SSI of received
+ data correlated highly (74%) with the SSI of received ACKs. Low pass
+ filtering and monotonicity constraints were applied to remove noise
+ in the rate versus SSI curves. The resulting hybrid rate adaptation
+ algorithm demonstrated the ability to respond to rapid deterioration
+ (and improvement) in channel properties, since it is not restricted
+ to moving to adjacent rates.
+
+ In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs"
+ [CARA], the authors propose Collision-Aware Rate Adaptation (CARA).
+ This involves utilization of Clear Channel Assessment (CCA) along
+ with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS)
+ mechanism to differentiate losses caused by frame collisions from
+ losses caused by channel conditions. Rather than decreasing rate as
+ the result of frame loss due to collisions, which leads to increased
+ contention, CARA selectively enables RTS/CTS (e.g., after a frame
+ loss), reducing the likelihood of frame loss due to hidden stations.
+ CARA can also utilize CCA to determine whether a collision has
+ occurred after a transmission; however, since CCA may not detect a
+ significant fraction of all collisions (particularly when
+ transmitting at low rate), its use is optional. As compared with
+ ARF, in simulations the authors show large improvements in aggregate
+ throughput due to addition of adaptive RTS/CTS, and additional modest
+ improvements with the additional help of CCA.
+
+ In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust],
+ the authors implemented the ARF, AARF, and SampleRate [SampleRate]
+ algorithms on a programmable Access Point platform, and
+
+
+
+IAB Informational [Page 50]
+
+RFC 4907 Link Indications June 2007
+
+
+ experimentally examined the performance of these algorithms as well
+ as the ONOE [ONOE] algorithm implemented in MadWiFi. Based on their
+ experiments, the authors critically examine the assumptions
+ underlying existing rate negotiation algorithms:
+
+ Decrease transmission rate upon severe frame loss
+ Where severe frame loss is due to channel conditions, rate
+ reduction can improve throughput. However, where frame loss is
+ due to contention (such as from hidden stations), reducing
+ transmission rate increases congestion, lowering throughput and
+ potentially leading to congestive collapse. Instead, the
+ authors propose adaptive enabling of RTS/CTS so as to reduce
+ contention due to hidden stations. Once RTS/CTS is enabled,
+ remaining losses are more likely to be due to channel
+ conditions, providing more reliable guidance on increasing or
+ decreasing transmission rate.
+
+ Use probe frames to assess possible new rates
+ Probe frames reliably estimate frame loss at a given rate unless
+ the sample size is sufficient and the probe frames are of
+ comparable length to data frames. The authors argue that rate
+ adaptation schemes such as SampleRate are too sensitive to loss
+ of probe packets. In order to satisfy sample size constraints,
+ a significant number of probe frames are required. This can
+ increase frame loss if the probed rate is too high, and can
+ lower throughput if the probed rate is too low. Instead, the
+ authors propose assessment of the channel condition by tracking
+ the frame loss ratio within a window of 5 to 40 frames.
+
+ Use consecutive transmission successes/losses to increase/decrease
+ rate
+ The authors argue that consecutive successes or losses are not a
+ reliable basis for rate increases or decreases; greater sample
+ size is needed.
+
+ Use PHY metrics like SNR to infer new transmission rate
+ The authors argue that received signal to noise ratio (SNR)
+ routinely varies 5 dB per packet and that variations of 10-14 dB
+ are common. As a result, rate decisions based on SNR or signal
+ strength can cause transmission rate to vary rapidly. The
+ authors question the value of such rapid variation, since
+ studies such as [Aguayo] show little correlation between SNR and
+ frame loss probability. As a result, the authors argue that
+ neither received signal strength indication (RSSI) nor
+ background energy level can be used to distinguish losses due to
+ contention from those due to channel conditions. While multi-
+ path interference can simultaneously result in high signal
+ strength and frame loss, the relationship between low signal
+
+
+
+IAB Informational [Page 51]
+
+RFC 4907 Link Indications June 2007
+
+
+ strength and high frame loss is stronger. Therefore,
+ transmission rate decreases due to low received signal strength
+ probably do reflect sudden worsening in channel conditions,
+ although sudden increases may not necessarily indicate that
+ channel conditions have improved.
+
+ Long-term smoothened operation produces best average performance
+ The authors present evidence that frame losses more than 150 ms
+ apart are uncorrelated. Therefore, collection of statistical
+ data over intervals of 1 second or greater reduces
+ responsiveness, but does not improve the quality of transmission
+ rate decisions. Rather, the authors argue that a sampling
+ period of 100 ms provides the best average performance. Such
+ small sampling periods also argue against use of probes, since
+ probe packets can only represent a fraction of all data frames
+ and probes collected more than 150 ms apart may not provide
+ reliable information on channel conditions.
+
+ Based on these flaws, the authors propose the Robust Rate Adaptation
+ Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the
+ current transmission rate to determine whether to increase or
+ decrease the transmission rate; PHY layer information or probe
+ packets are not used. Each transmission rate is associated with an
+ estimation window, a maximum tolerable loss threshold (MTL) and an
+ opportunistic rate increase threshold (ORI). If the loss ratio is
+ larger than the MTL, the transmission rate is decreased, and if it is
+ smaller than the ORI, transmission rate is increased; otherwise
+ transmission rate remains the same. The thresholds are selected in
+ order to maximize throughput. Although RRAA only allows movement
+ between adjacent transmission rates, the algorithm does not require
+ collection of an entire estimation window prior to increasing or
+ decreasing transmission rates; if additional data collection would
+ not change the decision, the change is made immediately.
+
+ The authors validate the RRAA algorithm using experiments and field
+ trials; the results indicate that RRAA without adaptive RTS/CTS
+ outperforms the ARF, AARF, and Sample Rate algorithms. This occurs
+ because RRAA is not as sensitive to transient frame loss and does not
+ use probing, enabling it to more frequently utilize higher
+ transmission rates. Where there are no hidden stations, turning on
+ adaptive RTS/CTS reduces performance by at most a few percent.
+ However, where there is substantial contention from hidden stations,
+ adaptive RTS/CTS provides large performance gains, due to reduction
+ in frame loss that enables selection of a higher transmission rate.
+
+ In "Efficient Mobility Management for Vertical Handoff between WWAN
+ and WLAN" [Vertical], the authors propose use of signal strength and
+ link utilization in order to optimize vertical handoff. WLAN to WWAN
+
+
+
+IAB Informational [Page 52]
+
+RFC 4907 Link Indications June 2007
+
+
+ handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a
+ threshold (S1), Fast Fourier Transform (FFT)-based decay detection is
+ undertaken to determine if the signal is likely to continue to decay.
+ If so, then handoff to the WWAN is initiated when the signal falls
+ below the minimum acceptable level (S2). WWAN to WLAN handoff is
+ driven by both PHY and MAC characteristics of the IEEE 802.11 target
+ network. At the PHY layer, characteristics such as SSI are examined
+ to determine if the signal strength is greater than a minimum value
+ (S3). At the MAC layer, the IEEE 802.11 Network Allocation Vector
+ (NAV) occupation is examined in order to estimate the maximum
+ available bandwidth and mean access delay. Note that depending on
+ the value of S3, it is possible for the negotiated rate to be less
+ than the available bandwidth. In order to prevent premature handoff
+ between WLAN and WWAN, S1 and S2 are separated by 6 dB; in order to
+ prevent oscillation between WLAN and WWAN media, S3 needs to be
+ greater than S1 by an appropriate margin.
+
+A.2. Internet Layer
+
+ Within the Internet layer, proposals have been made for utilizing
+ link indications to optimize IP configuration, to improve the
+ usefulness of routing metrics, and to optimize aspects of Mobile IP
+ handoff.
+
+ In "Analysis of link failures in an IP backbone" [Iannaccone], the
+ authors investigate link failures in Sprint's IP backbone. They
+ identify the causes of convergence delay, including delays in
+ detection of whether an interface is down or up. While it is fastest
+ for a router to utilize link indications if available, there are
+ situations in which it is necessary to depend on loss of routing
+ packets to determine the state of the link. Once the link state has
+ been determined, a delay may occur within the routing protocol in
+ order to dampen link flaps. Finally, another delay may be introduced
+ in propagating the link state change, in order to rate limit link
+ state advertisements, and guard against instability.
+
+ "Bidirectional Forwarding Detection" [BFD] notes that link layers may
+ provide only limited failure indications, and that relatively slow
+ "Hello" mechanisms are used in routing protocols to detect failures
+ when no link layer indications are available. This results in
+ failure detection times of the order of a second, which is too long
+ for some applications. The authors describe a mechanism that can be
+ used for liveness detection over any media, enabling rapid detection
+ of failures in the path between adjacent forwarding engines. A path
+ is declared operational when bidirectional reachability has been
+ confirmed.
+
+
+
+
+
+IAB Informational [Page 53]
+
+RFC 4907 Link Indications June 2007
+
+
+ In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
+ that has moved to a new point of attachment utilizes a bidirectional
+ reachability test in parallel with DHCP [RFC2131] to rapidly
+ reconfirm an operable configuration.
+
+ In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
+ 802.11/GPRS Example" [Park], the authors propose that the mobile node
+ send a router solicitation on receipt of a "Link Up" indication in
+ order to provide lower handoff latency than would be possible using
+ generic movement detection [RFC3775]. The authors also suggest
+ immediate invalidation of the Care-of Address (CoA) on receipt of a
+ "Link Down" indication. However, this is problematic where a "Link
+ Down" indication can be followed by a "Link Up" indication without a
+ resulting change in IP configuration, as described in [RFC4436].
+
+ In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors
+ suggest that MIPv4 Registration messages be carried within
+ Information Elements of IEEE 802.11 Association/Reassociation frames,
+ in order to minimize handoff delays. This requires modification to
+ the mobile node as well as 802.11 APs. However, prior to detecting
+ network attachment, it is difficult for the mobile node to determine
+ whether or not the new point of attachment represents a change of
+ network. For example, even where a station remains within the same
+ ESS, it is possible that the network will change. Where no change of
+ network results, sending a MIPv4 Registration message with each
+ Association/Reassociation is unnecessary. Where a change of network
+ results, it is typically not possible for the mobile node to
+ anticipate its new CoA at Association/Reassociation; for example, a
+ DHCP server may assign a CoA not previously given to the mobile node.
+ When dynamic VLAN assignment is used, the VLAN assignment is not even
+ determined until IEEE 802.1X authentication has completed, which is
+ after Association/Reassociation in [IEEE-802.11i].
+
+ In "Link Characteristics Information for Mobile IP" [Lee], link
+ characteristics are included in registration/Binding Update messages
+ sent by the mobile node to the home agent and correspondent node.
+ Where the mobile node is acting as a receiver, this allows the
+ correspondent node to adjust its transport parameters window more
+ rapidly than might otherwise be possible. Link characteristics that
+ may be communicated include the link type (e.g., 802.11b, CDMA (Code
+ Division Multiple Access), GPRS (General Packet Radio Service), etc.)
+ and link bandwidth. While the document suggests that the
+ correspondent node should adjust its sending rate based on the
+ advertised link bandwidth, this may not be wise in some
+ circumstances. For example, where the mobile node link is not the
+ bottleneck, adjusting the sending rate based on the link bandwidth
+ could cause congestion. Also, where the transmission rate changes
+ frequently, sending registration messages on each transmission rate
+
+
+
+IAB Informational [Page 54]
+
+RFC 4907 Link Indications June 2007
+
+
+ change could by itself consume significant bandwidth. Even where the
+ advertised link characteristics indicate the need for a smaller
+ congestion window, it may be non-trivial to adjust the sending rates
+ of individual connections where there are multiple connections open
+ between a mobile node and correspondent node. A more conservative
+ approach would be to trigger parameter re-estimation and slow start
+ based on the receipt of a registration message or Binding Update.
+
+ In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile
+ Ad-hoc NETwork (MANET) routing protocols have a tendency to
+ concentrate traffic since they utilize shortest-path metrics and
+ allow nodes to respond to route queries with cached routes. The
+ authors propose that nodes participating in an ad-hoc wireless mesh
+ monitor local conditions such as MAC delay, buffer consumption, and
+ packet loss. Where congestion is detected, this is communicated to
+ neighboring nodes via an IP option. In response to moderate
+ congestion, nodes suppress route requests; where major congestion is
+ detected, nodes rate control transport connections flowing through
+ them. The authors argue that for ad-hoc networks, throttling by
+ intermediate nodes is more effective than end-to-end congestion
+ control mechanisms.
+
+A.3. Transport Layer
+
+ Within the transport layer, proposals have focused on countering the
+ effects of handoff-induced packet loss and non-congestive loss caused
+ by lossy wireless links.
+
+ Where a mobile host moves to a new network, the transport parameters
+ (including the RTT, RTO, and congestion window) may no longer be
+ valid. Where the path change occurs on the sender (e.g., change in
+ outgoing or incoming interface), the sender can reset its congestion
+ window and parameter estimates. However, where it occurs on the
+ receiver, the sender may not be aware of the path change.
+
+ In "The BU-trigger method for improving TCP performance over Mobile
+ IPv6" [Kim], the authors note that handoff-related packet loss is
+ interpreted as congestion by the transport layer. In the case where
+ the correspondent node is sending to the mobile node, it is proposed
+ that receipt of a Binding Update by the correspondent node be used as
+ a signal to the transport layer to adjust cwnd and ssthresh values,
+ which may have been reduced due to handoff-induced packet loss. The
+ authors recommend that cwnd and ssthresh be recovered to pre-timeout
+ values, regardless of whether the link parameters have changed. The
+ paper does not discuss the behavior of a mobile node sending a
+ Binding Update, in the case where the mobile node is sending to the
+ correspondent node.
+
+
+
+
+IAB Informational [Page 55]
+
+RFC 4907 Link Indications June 2007
+
+
+ In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate
+ Control" [Gurtov], the authors examine the effect of explicit
+ handover notifications on TCP-friendly rate control (TFRC). Where
+ explicit handover notification includes information on the loss rate
+ and throughput of the new link, this can be used to instantaneously
+ change the transmission rate of the sender. The authors also found
+ that resetting the TFRC receiver state after handover enabled
+ parameter estimates to adjust more quickly.
+
+ In "Adapting End Host Congestion Control for Mobility" [Eddy], the
+ authors note that while MIPv6 with route optimization allows a
+ receiver to communicate a subnet change to the sender via a Binding
+ Update, this is not available within MIPv4. To provide a
+ communication vehicle that can be universally employed, the authors
+ propose a TCP option that allows a connection endpoint to inform a
+ peer of a subnet change. The document does not advocate utilization
+ of "Link Up" or "Link Down" events since these events are not
+ necessarily indicative of subnet change. On detection of subnet
+ change, it is advocated that the congestion window be reset to
+ INIT_WINDOW and that transport parameters be re-estimated. The
+ authors argue that recovery from slow start results in higher
+ throughput both when the subnet change results in lower bottleneck
+ bandwidth as well as when bottleneck bandwidth increases.
+
+ In "Efficient Mobility Management for Vertical Handoff between WWAN
+ and WLAN" [Vertical], the authors propose a "Virtual Connectivity
+ Manager", which utilizes local connection translation (LCT) and a
+ subscription/notification service supporting simultaneous movement in
+ order to enable end-to-end mobility and maintain TCP throughput
+ during vertical handovers.
+
+ In an early version of "Datagram Congestion Control Protocol (DCCP)"
+ [RFC4340], a "Reset Congestion State" option was proposed in Section
+ 11. This option was removed in part because the use conditions were
+ not fully understood:
+
+ An HC-Receiver sends the Reset Congestion State option to its
+ sender to force the sender to reset its congestion state -- that
+ is, to "slow start", as if the connection were beginning again.
+ ...
+ The Reset Congestion State option is reserved for the very few
+ cases when an endpoint knows that the congestion properties of a
+ path have changed. Currently, this reduces to mobility: a DCCP
+ endpoint on a mobile host MUST send Reset Congestion State to its
+ peer after the mobile host changes address or path.
+
+
+
+
+
+
+IAB Informational [Page 56]
+
+RFC 4907 Link Indications June 2007
+
+
+ "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses
+ optimizations to recover earlier from a retransmission timeout
+ incurred during a period in which an interface or intervening link
+ was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup]
+ describes methods by which a TCP implementation that has backed off
+ its retransmission timer due to frame loss on a remote link can learn
+ that the link has once again become operational. This enables
+ retransmission to be attempted prior to expiration of the backed-off
+ retransmission timer.
+
+ "Link-layer Triggers Protocol" [Yegin] describes transport issues
+ arising from lack of host awareness of link conditions on downstream
+ Access Points and routers. Transport of link layer triggers is
+ proposed to address the issue.
+
+ "TCP Extensions for Immediate Retransmissions" [Eggert] describes how
+ a transport layer implementation may utilize existing "end-to-end
+ connectivity restored" indications. It is proposed that in addition
+ to regularly scheduled retransmissions that retransmission be
+ attempted by the transport layer on receipt of an indication that
+ connectivity to a peer node may have been restored. End-to-end
+ connectivity restoration indications include "Link Up", confirmation
+ of first-hop router reachability, confirmation of Internet layer
+ configuration, and receipt of other traffic from the peer.
+
+ In "Discriminating Congestion Losses from Wireless Losses Using
+ Interarrival Times at the Receiver" [Biaz], the authors propose a
+ scheme for differentiating congestive losses from wireless
+ transmission losses based on inter-arrival times. Where the loss is
+ due to wireless transmission rather than congestion, congestive
+ backoff and cwnd adjustment is omitted. However, the scheme appears
+ to assume equal spacing between packets, which is not realistic in an
+ environment exhibiting link layer frame loss. The scheme is shown to
+ function well only when the wireless link is the bottleneck, which is
+ often the case with cellular networks, but not with IEEE 802.11
+ deployment scenarios such as home or hotspot use.
+
+ In "Improving Performance of TCP over Wireless Networks" [Bakshi],
+ the authors focus on the performance of TCP over wireless networks
+ with burst losses. The authors simulate performance of TCP Tahoe
+ within ns-2, utilizing a two-state Markov model, representing "good"
+ and "bad" states. Where the receiver is connected over a wireless
+ link, the authors simulate the effect of an Explicit Bad State
+ Notification (EBSN) sent by an Access Point unable to reach the
+ receiver. In response to an EBSN, it is advocated that the existing
+ retransmission timer be canceled and replaced by a new dynamically
+
+
+
+
+
+IAB Informational [Page 57]
+
+RFC 4907 Link Indications June 2007
+
+
+ estimated timeout, rather than being backed off. In the simulations,
+ EBSN prevents unnecessary timeouts, decreasing RTT variance and
+ improving throughput.
+
+ In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc
+ Wireless Networks" [Chandran], the authors proposed an explicit Route
+ Failure Notification (RFN), allowing the sender to stop its
+ retransmission timers when the receiver becomes unreachable. On
+ route reestablishment, a Route Reestablishment Notification (RRN) is
+ sent, unfreezing the timer. Simulations indicate that the scheme
+ significantly improves throughput and reduces unnecessary
+ retransmissions.
+
+ In "Analysis of TCP Performance over Mobile Ad Hoc Networks"
+ [Holland], the authors explore how explicit link failure notification
+ (ELFN) can improve the performance of TCP in mobile ad hoc networks.
+ ELFN informs the TCP sender about link and route failures so that it
+ need not treat the ensuing packet loss as due to congestion. Using
+ an ns-2 simulation of TCP Reno over 802.11 with routing provided by
+ the Dynamic Source Routing (DSR) protocol, it is demonstrated that
+ TCP performance falls considerably short of expected throughput based
+ on the percentage of the time that the network is partitioned. A
+ portion of the problem was attributed to the inability of the routing
+ protocol to quickly recognize and purge stale routes, leading to
+ excessive link failures; performance improved dramatically when route
+ caching was turned off. Interactions between the route request and
+ transport retransmission timers were also noted. Where the route
+ request timer is too large, new routes cannot be supplied in time to
+ prevent the transport timer from expiring, and where the route
+ request timer is too small, network congestion may result.
+
+ For their implementation of ELFN, the authors piggybacked additional
+ information (sender and receiver addresses and ports, the TCP
+ sequence number) on an existing "route failure" notice to enable the
+ sender to identify the affected connection. Where a TCP receives an
+ ELFN, it disables the retransmission timer and enters "stand-by"
+ mode, where packets are sent at periodic intervals to determine if
+ the route has been reestablished. If an acknowledgment is received,
+ then the retransmission timers are restored. Simulations show that
+ performance is sensitive to the probe interval, with intervals of 30
+ seconds or greater giving worse performance than TCP Reno. The
+ effect of resetting the congestion window and RTO values was also
+ investigated. In the study, resetting the congestion window to one
+ did not have much of an effect on throughput, since the
+ bandwidth/delay of the network was only a few packets. However,
+ resetting the RTO to a high initial value (6 seconds) did have a
+ substantial detrimental effect, particularly at high speed. In terms
+ of the probe packet sent, the simulations showed little difference
+
+
+
+IAB Informational [Page 58]
+
+RFC 4907 Link Indications June 2007
+
+
+ between sending the first packet in the congestion window, or
+ retransmitting the packet with the lowest sequence number among those
+ signaled as lost via the ELFNs.
+
+ In "Improving TCP Performance over Wireless Links" [Goel], the
+ authors propose use of an ICMP-DEFER message, sent by a wireless
+ Access Point on failure of a transmission attempt. After exhaustion
+ of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
+ receipt of an ICMP-DEFER message, the expiry of the retransmission
+ timer is postponed by the current RTO estimate. On receipt of an
+ ICMP-RETRANSMIT message, the segment is retransmitted. On
+ retransmission, the congestion window is not reduced; when coming out
+ of fast recovery, the congestion window is reset to its value prior
+ to fast retransmission and fast recovery. Using a two-state Markov
+ model, simulated using ns-2, the authors show that the scheme
+ improves throughput.
+
+ In "Explicit Transport Error Notification (ETEN) for Error-Prone
+ Wireless and Satellite Networks" [Krishnan], the authors examine the
+ use of explicit transport error notification (ETEN) to aid TCP in
+ distinguishing congestive losses from those due to corruption. Both
+ per-packet and cumulative ETEN mechanisms were simulated in ns-2,
+ using both TCP Reno and TCP SACK over a wide range of bit error rates
+ and traffic conditions. While per-packet ETEN mechanisms provided
+ substantial gains in TCP goodput without congestion, where congestion
+ was also present, the gains were not significant. Cumulative ETEN
+ mechanisms did not perform as well in the study. The authors point
+ out that ETEN faces significant deployment barriers since it can
+ create new security vulnerabilities and requires implementations to
+ obtain reliable information from the headers of corrupt packets.
+
+ In "Towards More Expressive Transport-Layer Interfaces" [Eggert2],
+ the authors propose extensions to existing network/transport and
+ transport/application interfaces to improve the performance of the
+ transport layer in the face of changes in path characteristics
+ varying more quickly than the round-trip time.
+
+ In "Protocol Enhancements for Intermittently Connected Hosts"
+ [Schuetz], the authors note that intermittent connectivity can lead
+ to poor performance and connectivity failures. To address these
+ problems, the authors combine the use of the Host Identity Protocol
+ (HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission
+ trigger, demonstrating significant improvement.
+
+
+
+
+
+
+
+
+IAB Informational [Page 59]
+
+RFC 4907 Link Indications June 2007
+
+
+A.4. Application Layer
+
+ In "Application-oriented Link Adaptation for IEEE 802.11"
+ [Haratcherev2], rate information generated by a link layer utilizing
+ improved rate adaptation algorithms is provided to a video
+ application, and used for codec adaptation. Coupling the link and
+ application layers results in major improvements in the Peak Signal
+ to Noise Ratio (PSNR). Since this approach assumes that the link
+ represents the path bottleneck bandwidth, it is not universally
+ applicable to use over the Internet.
+
+ At the application layer, the usage of "Link Down" indications has
+ been proposed to augment presence systems. In such systems, client
+ devices periodically refresh their presence state using application
+ layer protocols such as SIP for Instant Messaging and Presence
+ Leveraging Extensions (SIMPLE) [RFC3428] or Extensible Messaging and
+ Presence Protocol (XMPP) [RFC3921]. If the client should become
+ disconnected, their unavailability will not be detected until the
+ presence status times out, which can take many minutes. However, if
+ a link goes down, and a disconnect indication can be sent to the
+ presence server (presumably by the Access Point, which remains
+ connected), the status of the user's communication application can be
+ updated nearly instantaneously.
+
+Appendix B. IAB Members at the Time of This Writing
+
+ Bernard Aboba
+ Loa Andersson
+ Brian Carpenter
+ Leslie Daigle
+ Elwyn Davies
+ Kevin Fall
+ Olaf Kolkman
+ Kurtis Lindqvist
+ David Meyer
+ David Oran
+ Eric Rescorla
+ Dave Thaler
+ Lixia Zhang
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 60]
+
+RFC 4907 Link Indications June 2007
+
+
+Author's Address
+
+ Bernard Aboba, Ed.
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: bernarda@microsoft.com
+ Phone: +1 425 706 6605
+ Fax: +1 425 936 7329
+
+
+ IAB
+
+ EMail: iab@iab.org
+ URI: http://www.iab.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB Informational [Page 61]
+
+RFC 4907 Link Indications June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+IAB Informational [Page 62]
+