Network Working Group                                      B. Aboba, Ed.
INTERNET-DRAFT                               Internet Architecture Board
Category: Informational                                              IAB
<draft-iab-link-indications-01.txt>
10 January
<draft-iab-link-indications-02.txt>
2 July 2005

             Architectural Implications of Link Indications

   By submitting this Internet-Draft, I certify each author represents that any
   applicable patent or other IPR claims of which I am he or she is aware
   have been or will be disclosed, and any of which I become he or she becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 22, December 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document provides an overview of describes the role of link indications within the
   Internet Architecture.  While the judicious use of link indications
   can provide performance benefits, experience has also
   shown that that inapropriate 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 layer indications.

Table of Contents

1.  Introduction..............................................    3
      1.1 Requirements .......................................    3
      1.2 Terminology ........................................    3
      1.3 Link Indications ...................................    5
      1.4 Proposals ..........................................    8
      1.5 Layering Overview ...........................................   10    6
      1.4 Layered Indication Model ...........................    9
2.  Architectural considerations Considerations .............................   14
      2.1 Model Validation ...................................   14
      2.2 Clear Definitions ..................................   15
      2.3 Robustness .........................................   17
      2.3   16
      2.4 Stability ..........................................   20
      2.5 Effectiveness ......................................   20
      2.4 Interoperability Issues ............................   21
      2.5
      2.6 Interoperability ...................................   22
      2.7 Race Conditions ....................................   22
      2.6
      2.8 Layer Compression ..................................   24
      2.7   25
      2.9 Transport of Link Indications ......................   25   26
3.  Future Work ..............................................   27
4.  Security Considerations ..................................   28
5.  References ...............................................   28   29
      5.1 Informative References .............................   28   29
Appendix A - Literature Review ...............................   36
      A.1 Link Layer .........................................   36
      A.2 Internet Layer .....................................   41
      A.3 Transport Layer ....................................   43
      A.4 Application Layer ..................................   47
Appendix B - IAB Members .....................................   32   48
Intellectual Property Statement ..............................   33   48
Disclaimer of Validity .......................................   33   48
Copyright Statement ..........................................   33   49

1.  Introduction

   As a performance optimization, proposals have been made for utilizing

   A link indications (also known as "triggers" or "hints") indication represents information provided by the link layer
   to influence higher layers regarding the behavior state of the Internet, Transport or Application layers. link.

   This document provides an overview of the role of link indications
   within the Internet Architecture.  While the judicious use of link
   indications can provide performance benefits, experience has also
   shown that that inapropriate inappropriate use can degrade both robustness and
   performance.

   This document summarizes the current understanding of the role of
   link indications, and provides advice to document authors considering about the role
   appropriate use of link indications within their own work. indications.

   In Section 1 describes the history of this document we present a brief overview of research
   on link behavior as well as proposals indication usage within
   the Internet architecture and provides a model for the utilization of
   link indications.  Section 2 provides advice to document authors.
   Section 3 describes recommendations and future work.  Appendix A
   presents a summary of the literature on link indication utilization.

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 distribution services, via
     the wireless medium (WM) for associated stations.

Association
     The service used to establish an access point/station (AP/STA)
     mapping and enable STA access to the Distribution System.

Basic Service Set (BSS)
     A set of stations controlled by a single coordination function,
     where the coordination function may be centralized (e.g., in a
     single AP) or distributed (e.g., for an ad-hoc network).  The BSS
     can be thought of as the coverage area of a single AP.

Beacon
     A control message broadcast by a node (especially, a base station)
     informing all the other nodes in its neighborhood of the continuing
     presence of the broadcasting node, possibly along with additional
     status or configuration information.

Binding Update (BU)
     A message indicating a mobile node's current mobility binding, and
     in particular its care-of address.

Care of Address (CoA)
     A unicast routable address associated with a mobile node while
     visiting a foreign link; the subnet prefix of this IP address is a
     foreign subnet prefix.  Among the multiple care-of addresses that a
     mobile node may have at any given time (e.g., with different subnet
     prefixes), the one registered with the mobile node's home agent for
     a given home address is called its "primary" care-of address.

Correspondent Node
     A peer node with which a mobile node is communicating.  The
     correspondent node may be either mobile or stationary.

Distribution System (DS)
     A system used to interconnect a set of basic service sets (BSSs)
     and integrated local area networks (LANs) to create an extended
     service set (ESS).

Dynamic Host Configuration Protocol (DHCP) client
     A DHCP client is an Internet host using DHCP to obtain
     configuration parameters such as a network address.

DHCP server
     A DHCP server or "server" is an Internet host that returns
     configuration parameters to DHCP clients.

Extended Service Set (ESS)
     A set of one or more interconnected basic service sets (BSSs) and
     integrated local area networks (LANs) that appears as a single BSS
     to the logical link control layer at any station associated with
     one of those BSSs.  The ESS can be thought of as the coverage area
     provided by a collection of APs all interconnected by the
     Distribution System.  It may consist of one or more IP subnets. prefixes.

Home Address (HoA)
     A unicast routable address assigned to a mobile node, used as the
     permanent address of the mobile node.  This address is within the
     mobile node's home link.  Standard IP routing mechanisms will
     deliver packets destined for a mobile node's home address to its
     home link.  Mobile nodes can have multiple home addresses, for
     instance when there are multiple home prefixes on the home link.

Inter-Access Point Protocol (IAPP)

Home Agent (HA)
     A protocol used between access points that assures that the station
   may only be connected to a single AP within the ESS at router on a time, and
   also provides for transfer of context to mobile node's home link with which the new AP.

Link
   A communication mobile node
     has registered its current care-of address.  While the mobile node
     is away from home, the home agent intercepts packets on the home
     link destined to the mobile node's home address, encapsulates them,
     and tunnels them to the mobile node's registered care-of address.

Inter-Access Point Protocol (IAPP)
     A protocol used between access points that assures that the station
     may only be connected to a single AP within the ESS at a time, and
     also provides for transfer of context to the new AP.

Link A communication facility or physical medium over which nodes that can communicate
   at the link layer, sustain data
     communications between multiple network nodes, such as an Ethernet
     (simple or bridged).  The  A link
   layer is the layer immediately below IP.  In
     a layered network stack model, the Link indication
   Information provided by Layer (Layer 2) is normally
     below the link layer to higher layers relating to Network (IP) Layer (Layer 3), and above the state Physical
     Layer (Layer 1).  Each link is associated with a minimum of the link.

Mobile Node two
     endpoints.  Each link endpoint has a unique link-layer identifier.

Asymmetric link
     A node that can change its point of attachment from one link to
   another, while still being reachable via its home address.

Point with transmission characteristics which are different
     depending upon the relative position or design characteristics of Attachment
   A location within
     the network where a host may be connected.  This
   attachment point can be characterized by its address prefix transmitter and next
   hop routing information.

Most Likely Point of Attachment (MLPA)
   The point the receiver of attachment heuristically determined by data on the host to link.  For
     instance, the range of one transmitter may be
   most likely, based much higher than the
     range of another transmitter on hints from the network.

Routable address
   In this specification, same medium.

Link Down
     An event provided by the term "routable address" refers to any
   address other than an IPv4 Link-Local address [RFC3927].  This
   includes private addresses as specified in [RFC1918].

Station (STA)
   Any device link layer that contains an IEEE 802.11 conformant medium access 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 Layer
     Conceptual layer of control (MAC) and physical or processing logic that is responsible
     for maintaining control of the data link.  The data link layer (PHY)
     functions provide an interface to between the wireless
   medium (WM).

Valid address higher-layer logic and
     the data link.  The term "valid address" refers link layer is the layer immediately below IP.

Link identifier
     An indication provided by the link layer as to either a static address, or a
   dynamically assigned address which network(s) a
     host has not been relinquished, and has
   not expired.

Weak End-System Model
   In connected to.  Examples include the Weak End-System Model, packets sent out an interface need not
   necessarily have a source address configured on that interface.

1.3. SSID with IEEE 802.11.
     For details, see [DNAv4] Appendix A.

Link Indications

   A link indication represents information
     Information provided by the link layer to higher layers relating to regarding
     the state of the link.  While link
   indications vary considerably between media, abstraction models have
   been proposed.  For example, [GenTrig] defines "generic triggers",
   including "Link Up", "Link Down", "Link Going Down", "Link Going Up",  In addition to "Link Quality Crosses Threshold", "Trigger Rollback", Up" and "Better
   Signal Quality AP Available".  Other "Link Down"
     indications, other relevant link indications information may include the
     current link rate (which may vary with time and location), link
     identifiers (e.g. SSID, BSSID in 802.11), and statistics relating
     to link performance (such as the delay or loss rate).

   "Link Up" and "Link Down" indications were first developed for wired
   networks, and assume an idealized

Link Up
     An event provided by the link behavior model.  This model
   assumes layer that links in the "up" signifies a state experience low frame loss in
   both directions and are ready to send and receive data frames.
   Similarly it is assumed that links in change
     associated with the "down" state are unsuitable
   for sending and receiving interface becoming capable of communicating
     data frames in either direction.

   Link indications frames.

Most Likely Network (MLN)
     The attached network heuristically determined by the host to be
     most likely, based on signal quality, such as "Link Doing Down",
   "Link Going Up", and "Link Quality Crosses Threshold" are primarily
   intended for use in handoff optimization.  These indications assume
   an idealized model of radio propagation, where signal strength varies
   smoothly and frame loss is well predicted by signal strength and
   distance.

   A number hints.

Point of Attachment
     The link performance studies shed light endpoint on the applicability
   of these assumptions.  For the purposes of illustration, we will
   focus on literature relating link to IEEE 802.11.

   In "Measurement and Analysis of the Error Characteristics of an In-
   Building Wireless Network" [Eckhardt], which the authors characterize host is currently
     connected.

Medium Access Protocol (MAC)
     A protocol for mediating access to, and possibly allocation of, the
   performance of an AT&T Wavelan 2 Mbps in-building WLAN operating
     physical communications medium.  Nodes participating in
   Infrastructure mode on the Carnegie-Mellon Campus.  In this study,
   very low frame loss was experienced.  As a result, links could either
   be assumed medium
     access protocol can communicate only when they have uncontested
     access to operate very well or not at all.

   In "Performance of Multihop Wireless Networks: Shortest Path is Not
   Enough" [Shortest] the authors studied medium, so that there will be no interference.  When
     the performance of both an
   indoor and outdoor mesh network.  By measuring inter-node throughput, physical medium is a radio channel, the best path between nodes was computed.  The throughput of MAC is the best
   path was compared with same as the throughput
     Channel Access Protocol.

Mobile Node
     A node that can change its point of the shortest path computed
   based on a hop-count metric. attachment from one link to
     another, while still being reachable via its home address.

Routable address
     In almost all cases, this specification, the shortest path
   route offered considerably lower throughput term "routable address" refers to any
     address other than the best path.

   In examining link behavior, the authors found an IPv4 Link-Local address [RFC3927].  This
     includes private addresses as specified in [RFC1918].

Station (STA)
     Any device that rather than
   exhibiting a bi-modal distribution between "up" (low loss rate) contains an IEEE 802.11 conformant medium access
     control (MAC) and
   "down" (high loss rates), many links exhibited intermediate loss
   rates.  Asymmetry was also common, with 30 percent of links
   demonstrating substantial differences between in physical layer (PHY) interface to the loss rates in
   each direction.  As a result, on wireless networks the measured
   throughput can differ substantially from the negotiated rate due
     medium (WM).

Operable address
     The term "operable address" refers to
   retransmissions, either a static address, or a
     dynamically assigned address which has not been relinquished, and successful delivery of routing
     has not expired.

Weak End-System Model
     In the Weak End-System Model, packets is sent out an interface need
     not necessarily an indication have a source address configured on that interface.

1.3.  Overview

   Link status was first taken into account in computer routing within
   the link is  useful for delivery of
   data.

   "Link-level Measurements from ARPANET as early as 1969.  In response to an 802.11b Mesh Network" [Aguayo]
   analyzes attempt to send to a
   host that was off-line, the causes of ARPANET link layer protocol provided a
   "Destination Dead" indication [RFC816].  The ARPANET packet radio
   experiment [PRNET] incorporated frame loss in the calculation of
   routing metrics, a 38-node urban multi-hop 802.11
   ad-hoc network.  In most cases,  links that are very bad precursor to more recent link-aware routing
   metrics such as [ETX].

   "Routing Information Protocol" [RFC1058] defines RIP, which is
   descended from the Xerox Network Systems (XNS) Routing Information
   Protocol.  "The Open Shortest Path First Specification" [RFC1131]
   defines OSPF, which uses Link State Advertisements (LSAs) in one
   direction tend order to be bad
   flood information relating to link status within an OSPF area.  As
   noted in both directions, and links "Requirements for IP Version 4 Routers" [RFC1812]:

      It is crucial that routers have workable mechanisms for
      determining that their network connections are very
   good in one direction tend functioning
      properly.  Failure to be good in both directions.  However,
   30 percent of links exhibited loss rates differing substantially in
   each direction.

   Signal detect link loss, or failure to noise ratio take the
      proper actions when a problem is detected, can lead to black
      holes.

   "Fault Isolation and distance showed little value in predicting
   loss rates, Recovery" [RFC826] Section 3 describes how hosts
   interact with gateways for the purpose of fault detection and rather than exhibiting a step-function transition
   between "up" (low loss) or "down" (high loss) states,  inter-node
   loss rates varied widely, demonstrating
   recovery:

      Since  the gateways always attempt to have a nearly uniform distribution
   over consistent and
      correct model of the range at internetwork topology, the lower rates.  The authors attribute host strategy for
      fault recovery is very simple.  Whenever the
   observed effects to multi-path fading, rather than attenuation or
   interference. host feels that
      something  is  wrong,  it asks the gateway for advice, and,
      assuming the advice is forthcoming, it believes the advice
      completely.  The findings of [Eckhardt] and [Aguayo] demonstrate advice will be wrong only during the diversity transient
      period of
   loss conditions observed in practice.  There is a fundamental
   difference between indoor infrastructure networks in negotiation,  which site
   surveys and careful measurement can assist in promoting immediately follows an outage, but
      will otherwise be reliably correct.

   In ideal
   behavior and ad-hoc/mesh networks conditions, links in which node mobility and external
   factors such as weather may not be easily controlled.

   In "The mistaken axioms of wireless-network research" [Kotz], the
   authors conclude that mistaken assumptions relating to link
   performance may lead "up" state experience low frame
   loss in both directions and are immediately ready to send and receive
   data frames; links in the design of network protocols that "down" state are unsuitable for sending and
   receiving data frames in either direction.  Unfortunately links
   frequently exhibit non-ideal behavior.  Wired links may not
   work fail in practice.  For example, [Kotz] notes that the three-
   dimensional nature of wireless propagation can result half-
   duplex mode, or exhibit partial impairment resulting in large intermediate
   loss rates.  Wireless links may exhibit asymmetry or frame loss due
   to interference or signal
   strength changes over short distances, generating short-lived "Link
   Down" fading.  In both wired and "Link Up" indications that are not be predicted by a two
   dimensional radio propagation model.

   The literature also describes variations in wireless links,
   the link indication behavior state may rapidly flap between implementations.

   "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), "up" and execution phases
   (connection "down" states.

   Routing protocol implementations have had to an alternative point take real-world wired
   link behavior into account in order to maintain robustness.  In
   "Analysis of attachment).  These
   measurements indicated that link failures in an IP backbone" [Iannaccone] the duration of
   authors investigate link failures in Sprint's IP backbone.  They
   identify the causes of convergence delay, including delays in
   detection phase (the
   largest component of handoff delay) whether an interface 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, NICs designed down or up.  While it is fastest
   for desktops attempted more retransmissions
   prior a router to triggering search as compared with laptop designs, since
   they assumed that the AP was always utilize link indications if available, there are
   situations in range, regardless of whether
   the Beacon was received.

   The study recommends that the duration which it is necessary to depend on loss of routing
   packets to determine the detection phase be
   reduced by initiating the search phase as soon as collisions can be
   excluded as the cause state of non-acknowledged transmissions; the authors
   recommend three consecutive transmission failures as link.  Once the cutoff.
   Where link state has
   been determined, a delay may occur within the STA is not sending or receiving frames, it is recommended
   that Beacon reception routing protocol in
   order to dampen link flaps.  Finally, another delay may be tracked introduced
   in propagating the link state change, in order to detect disconnection, rate limit link
   state advertisements.

   "Bidirectional Forwarding Detection" [BFD] notes that link layers may
   provide only limited failure indications, and that Beacon spacing be reduced to 60 ms relatively slow
   "Hello" mechanisms are used in order routing protocols to reduce detect failures
   when no link layer indications are available.  This results in
   failure detection times.  In order to compensate for more frequent triggering times of the search phase, the order of a second, which is too long
   for some applications.  The authors recommend algorithms describe a mechanism that can be
   used for wait time
   reduction, as well as interleaving of search and data frame
   transmission.

   "An Empirical Analysis liveness detection over any media, enabling rapid detection
   of failures in the IEEE 802.11 MAC Layer Handoff Process"
   [Mishra] investigates handoff latencies obtained with three mobile
   STAs implementations communicating with two APs.  The study found
   that there path between adjacent forwarding engines.  A path
   is large variation in handoff latency among STA and AP
   implementations and declared operational when bi-directional reachability has been
   confirmed.

   More recently, the importance of realistic wireless link models has
   become better appreciated.  In "The mistaken axioms of wireless-
   network research" [Kotz], the authors conclude that implementations utilize different message
   sequences.  For example, one STA sends a Reassociation Request prior mistaken
   assumptions relating to authentication, which results in receipt link behavior may lead to the design of a Deauthenticate
   message.  The study divided handoff latency into discovery,
   authentication and reassociation exchanges, concluding
   network protocols that may not work in practice.  For example, [Kotz]
   notes that the
   discovery phase was the dominant component three-dimensional nature of handoff delay.  Latency wireless propagation can
   result in the detection phase was not investigated.

   "Roaming Interval Measurements" [Alimian] presents data on stationary
   STAs after the AP large signal has been shut off. strength changes over short distances.  This study highlighted
   implementation differences
   can result in rate adaptation as well rapid changes in link indications such as detection,
   scanning rate, frame
   loss, signal and handoff.  As in [Velayos], signal/noise ratio.

   In "Performance of Multihop Wireless Networks: Shortest Path is Not
   Enough" [Shortest] the authors studied the performance varied widely
   between implementations, from  half an order of magnitude variation
   in rate adaptation to both an order of magnitude difference in detection
   times, two orders of magnitude in scanning, and one
   indoor and a half orders
   of magnitude in handoff times.

   "An experimental study outdoor mesh network.  By measuring inter-node throughput,
   the best path between nodes was computed.  The throughput of IEEE 802.11b  handoff performance and its
   effect on voice traffic" [Vatn] describes handover behavior observed
   when the signal from AP is gradually attenuated, which is more
   representative best
   path was compared with the throughput 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 shortest path computed
   based on
   frame loss, so that they could begin handover while still connected
   to a hop-count metric.  In almost all cases, the current AP.  It was noted that stations continue to receive
   data frames during shortest path
   route offered considerably lower throughput than the search phase.  Station-initiated
   Disassociation best path.

   In examining link behavior, the authors found that rather than
   exhibiting a bi-modal distribution between "up" (low loss rate) and pre-authentication were not observed
   "down" (high loss rates), many links exhibited intermediate loss
   rates.  Asymmetry was also common, with 30 percent of links
   demonstrating substantial differences between in this
   study.

1.4.  Proposals

   Within the Internet layer, proposals have been made for utilizing
   link indications to optimize IP configuration, to improve loss rates in
   each direction.  As a result, on wireless networks the
   usefulness measured
   throughput can differ substantially from the negotiated rate due to
   retransmissions, and successful delivery of routing metrics, and to optimize aspects packets is not
   necessarily an indication that the link is  useful for delivery of Mobile IP
   handoff.

   In "Detection
   data.

   The complexity of Network Attachment (DNA) in IPv4" [DNAv4], real-world link
   indications are utilized to optimize Internet layer configuration.
   This enables behavior poses a host that has moved challenge to a new point the
   integration of attachment but
   remained link indications within the same subnet to rapidly confirm a currently valid
   configuration, rather than utilizing Internet architecture.
   While the DHCP protocol [RFC2131].

   "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX]
   describes how routing metrics can be improved by taking judicious use of link layer
   frame loss rates into account, enabling indications can provide performance
   benefits, inappropriate use can degrade both robustness and
   performance.  This document provides guidance on the selection incorporation of routes
   maximizing available throughput.  While the proposed routing metric
   utilizes the Expected Transmission Count (ETX), it does not take
   link indications within the
   negotiated rate into account, although this was noted Internet, Transport and Application
   layers.

1.4.  Layered Indication Model

   A layered indication model is shown in Figure 1 which includes both
   internally generated link indications and indications arising from
   external interactions such as a subject
   for further study.

   In "L2 Triggers Optimized receipt of Mobile IPv6 Vertical Handover: The
   802.11/GPRS Example" [Park] IP Binding Updates,
   and path change detection.

   In this model, link indications include frame loss (before
   retransmissions), the authors propose that current link rate, the mobile node
   send a router solicitation on receipt of link state (up/down),
   and link identifiers.  These indications may be inter-dependent,
   since rate adjustment and detection algorithms are typically
   influenced by frame loss, and a "Link Up" Down" indication in
   order provide lower handoff latency than would may be possible using
   generic movement
   influenced by the detection [RFC3775].  The authors also suggest
   immediate invalidation of and search process.  Link identifiers are
   typically obtained in the Care-Of-Address (CoA) on receipt process of a
   "Link Down" indication.

   Within bringing the Transport layer, proposals have focused on countering link up.

   The Internet layer is the
   effects of handoff-induced packet loss.  This includes proposals for
   improving transport parameter estimation, as well as triggering
   immediate retransmission on availability primary user of an interface or
   intervening link.

   "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 indications, since one
   of its retransmission timer due functions is to frame loss on a remote link can learn
   that shield applications from the specifics of link has once again become operational.  This enables
   retransmission
   behavior.  The Internet layer utilizes link indications in order 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 optimize aspects of link conditions on downstream
   Access Points IP configuration, routing and routers.  Transport of mobility.  By
   validating and filtering link indications and selecting outgoing and
   incoming interfaces based on routing metrics, the Internet layer triggers is
   proposed
   enables upper layers to address the issue. avoid dependency on link indications.

   In "TCP Extensions "Detecting Network Attachment" [DNAv4], "Link Up" indications and
   link identifiers are used as hints for Immediate Retransmissions" [Eggert], it validating an existing IP
   configuration.  Once the IP configuration is
   proposed confirmed, it may be
   determined that an address change has occurred.  However, "Link Up"
   indications often do not result in addition a change to regularly scheduled retransmissions that
   retransmission be attempted by the Transport Internet layer on receipt of an
   indication that connectivity
   configuration.

   The routing sub-layer utilizes link indications in order to a peer node may have been restored.
   End-to-end connectivity restoration indications include "Link Up",
   confirmation calculate
   routing metrics and determine changes in link state.  As described in
   [Iannaccone], damping of first-hop router reachability, confirmation link flaps and rate limiting of
   Internet layer configuration, link state
   advertisements are examples of how the routing sub-layer validates
   and receipt filters link indications.

   "Fault Isolation and Recovery" [RFC826] describes how hosts interact
   with gateways for the purpose of other traffic from fault recovery:

      Since  the
   peer.

   In "The BU-trigger method gateways always attempt to have a consistent and
      correct model of the internetwork topology, the host strategy for improving TCP performance over Mobile
   IPv6" [Kim],
      fault recovery is very simple.  Whenever the authors note host feels that handoff-related packet loss
      something  is
   interpreted as congestion by the Transport layer.  In  wrong,  it asks the case where gateway for advice, and,
      assuming the correspondent node advice is sending to forthcoming, it believes  the mobile node,  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 proposed
   that receipt of  never  necessary  for a Binding Update by host to explicitly ask
      a gateway for advice, because the correspondent node be used gateway will provide it as
      appropriate.

   Within "Weak End-System Model" implementations, changes in routing
   metrics and link state may result in a signal to change in the Transport layer to adjust cwnd and ssthresh values,
   which outgoing
   interface for one or more transport connections.  Routes may have been reduced due to handoff-induced packet loss.  The
   authors recommend that cwnd and ssthresh also be recovered to pre-timeout
   values, regardless
   added or withdrawn, resulting in loss or gain of whether the peer connectivity.
   However, link parameters have changed.  The
   paper does indications such as changes in link rate or frame loss
   do not discuss the behavior of necessarily result in a mobile node sending a
   Binding Update, in the case where the mobile node is sending to the
   correspondent node.

   At the Application layer, the usage change of "Link Down" indications has
   been proposed to augment presence systems.  In such systems, client
   devices periodically refresh their presence state using application outgoing interface.

   The Internet layer protocols may also become aware of path changes by other
   mechanisms, such as SIMPLE [RFC3428] or 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 by running a link goes down, and routing protocol, receipt of a disconnect indication
   can be sent to
   Router Advertisement, dead gateway detection [RFC826] or a change in
   the presence server (presumably by IP TTL of received packets.  A change in the access point,
   which remains connected), outgoing interface
   may in turn influence the status of mobility sub-layer, causing a change in the user's communication
   application can be updated nearly instantaneously.

1.5.  Layering

   A layered indication model is shown
   incoming interface.  The mobility sub-layer may also become aware of
   a change in Figure 1 which includes both
   internally generated link indications and indications arising from
   external interactions (such as the incoming interface of a peer (via receipt of a Mobile
   IP Binding Updates,
   and detection of path changes via routing protocols binding update).

   The Transport layer processes Internet layer and TTL changes).

   In this model, link indications include frame loss (before
   retransmissions),
   differently for the current link rate, purposes of transport parameter estimation and
   connection management.  For the purposes of parameter estimation, the
   Transport layer may be interested in a wide range of Internet and
   link state (up/down),
   and link identifiers. layer indications.  The Transport layer may wish to use path
   change indications are inter-dependent, since
   rate adjustment and detection algorithms are typically influenced by
   frame loss, and from the Internet layer in turn a "Link Down" indication order to reset
   parameter estimates.  It may also be influenced by
   the detection and search process.  Link Identifiers are typically
   obtained in the process of bringing useful for the Transport layer
   to utilize link up.

   The Internet layer is the primary consumer of indications such as link indications, since
   one of its functions is rate, frame loss rate
   and "Link Up"/"Link Down" in order to shield applications from improve transport parameter
   estimates.

   As described in Section A.3, the specifics of algorithms for improving transport
   parameter estimates using link behavior.  The Internet layer may utilize link indications are still under
   development.  In transport parameter estimation, layering
   considerations do not exist to
   optimize aspects of IP configuration, routing and mobility.  As noted the same extent as in [DNAv4], connection
   management.  For example, the Internet layer may receive a "Link
   Down" indication followed by a subsequent "Link Up" indications and link identifiers indication.  This
   information may be useful
   in validating the IP configuration.  Once the for transport parameter estimation even if IP
   configuration is
   confirmed, does not change, since it may be determined that an address change has occurred.

   As described in [ETX], indicate the frame potential
   for non-congestive packet loss rate as well as during the current
   link rate may be utilized in period between the calculation
   indications.

   For the purposes of routing metrics.
   Within "Weak End-System Model" implementations, connection management, the Transport layer
   typically only utilizes Internet layer indications such as changes in routing
   metrics may in turn result in a change in
   the outgoing incoming/outgoing interface for
   one or more transport connections.  Routes may also be added or
   withdrawn, resulting in loss or gain of peer connectivity.  The
   Internet and IP configuration changes.  For
   example, the Transport layer may also become aware of path changes by other
   mechanisms, such as by running a routing protocol, receipt tear down transport connections due
   to invalidation of a
   Router Advertisement or connection endpoint IP address.  However, before
   this can occur, the Internet layer must determine that a
   configuration change in has occurred.

   Nevertheless, the IP TTL Transport layer does not respond to all Internet
   layer indications.  For example, an Internet layer configuration
   change may not be relevant for the purposes of received packets.

   A connection management.
   Where the connection has been established based on the home address,
   a change in the outgoing interface may care-of-address need not result in turn influence connection
   teardown, since the mobility
   sub-layer, causing a configuration change in is masked by the incoming interface.  The mobility
   sub-layer may also become aware of a change in
   functionality within the incoming interface
   of a peer (via receipt of Internet layer, and is therefore transparent
   to the Transport layer.

   Just as a Mobile IP binding update).

   However, "Link Up" indications need event may not result in a change to
   Internet layer configuration, configuration change,
   and changes in link rate or frame loss
   need a configuration change may not result in a change connection teardown, the
   Transport layer does not tear down connections on receipt of outgoing interface.  By filtering a "Link Up" indications, and selecting outgoing and incoming interfaces
   based on
   Down" indication, regardless of the link rate and cause.  Where the "Link Down"
   indication results from frame loss, loss rather than an explicit exchange,
   the Internet layer enables
   upper layers to avoid writing their own code indication may be transient, to filter and validate
   link indications.

   The Transport layer processes Internet layer and link indications
   differently for be soon followed by a "Link Up"
   indication.

   Even where the purposes "Link Down" indication results from an explicit
   exchange such as receipt of transport parameter estimation and a PPP LCP-Terminate or an 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 management. is torn down due to lack of response to repeated
   retransmission attempts.

   For the purposes of parameter estimation, connection management, the Transport layer may be interested in a wide range is
   cautious even with the use of Internet and
   link layer indications.  The Transport layer may wish to use path
   change indications from the Internet layer  As noted
   in order to rest parameter
   estimates. [RFC826], Section 6:

      It may also be useful for the Transport layer to consume
   link layer indications  is  not  obvious, when error messages such as link rate, frame loss rate and "Link
   Up"/"Link Down" in order to improve transport parameter estimates.

   However at this point, ICMP Destination
      Unreachable arrive, whether TCP should  abandon the algorithms for improving transport
   parameter estimates using link layer indications connection.
      The reason that error messages  are not well
   understood.  For example, in transport parameter estimation, layering
   considerations may not exist  difficult to the same extent interpret is
      that, as in connection
   management.  For example, the Internet layer may receive discussed above, after a "Link
   Down" indication followed by failure of a subsequent "Link Up" indication.  This
   information gateway or network,
      there is a transient period during which the gateways  may useful for transport parameter estimation even  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.

   In addition to Internet layer indications propagated to the
   Application layer (such as IP address configuration and changes), the
   Transport layer provides its own indications to the Application
   layer, such as connection teardown.  The Transport layer  may also
   provide indications to the link layer.  For example, to prevent
   excessive retransmissions within the link layer, where the link layer
   retransmission timeout is significantly less than the path round-trip
   timeout, 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 change, continue to retransmit after a Transport layer
   timeout.  In 802.11, this can be achieved by adjusting the MIB
   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 it may indicate that packet loss these variables control link behavior as a whole they
   cannot be used to separately adjust behavior on a per-transport
   connection basis.  Also, in situations where the link layer
   retransmission timeout is of the same order as the path round trip
   timeout, link layer control may not caused by congestion.

                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Application   |                                               |
   Layer         |                                               |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                     ^   ^
                                                     |   |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |                           |       |   | be possible at all.

   Since applications can obtain the information they need from Internet
   and Transport layer indications they should not 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.  As a result, applications will should utilize an
   Internet layer "IP Address Configured" event instead of a "Link Up"
   indication.  Similarly, applications should not utilize "Link Down"
   indications, since they can be rapidly followed by a "Link Up"
   indication; instead, they should respond to Transport layer teardown
   indications.

                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Application   |                                               |                           +
   Layer         |                                               |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                     ^   ^
                                                     !   !
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+
                 |                                   !   !       |
                 |                                   ^   ^       |
   Transport
                 |     Connection Management         ! Teardown  |
   Transport Parameter      +     | Teardown                                   !           |
   Layer         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
                 |  Estimation                                   !           |
                 | Transport Parameter Estimation    !           |
                 | Estimation (MTU, RTT, RTO, cwnd,    + Conxn.| Management|  ! ssthresh)
                 |  ssthresh, Reset)         |       |           |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ^                                   ^           |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
                       ^           ^       ^         !
                       !           !       !         !
                 +-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
                 |   |           |       |         |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 | |   |     ! Incoming  | MIP   |         |           |
                 |  !MIP    !         !           |
                 |     ! Interface | BU    |         |           |
                 | !BU     !         !           |
                 |     ! Change    |Receipt|         |           |    !Receipt!         !           |
                 |     ^           ^       ^         ^           |
                 | |   |           |       |         |           |
                 | |   |           |       |         |           |
                 | |   | Mobility  |       |         |           |
   Internet      | |   |           |       |         |     ! Mobility  !       !         !           |
   Layer         +-+- -+- - - - - -+- -+- -+- - - - -+- - - - - -+
                 | |         +-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
                 |     ! Outgoing  ! Path  !         !           |
                 |   |         | IP        |
                 | |   |     ! Interface |   +   |         | Address   | ! Change!         !           |
                 |     ^ Change    ^   |       ^         ^ Config/   |
                 | |              Path +   |           Changes   |
                 | |            Change |           |
                 |                         !         !           |
                 |       Routing        +   |  IP Configuration   |
                 | |                   |           !         !           |
                 |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |         ^ ^         ^             !         !           |
                 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
                 | !         !             !         ! IP        |
                 |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !         !             !         ! Address   |
                 | !     IP  !Configuration^         ^ Config/   |
                 | !         !             !           Changes   |
                 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
                   !         !             !       ^
                   !         !             !       !
                 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-!-+-+-+-+-+-+-+
                 | !         !             !       !             |
   Link          | V ^         ^             ^       ^             |
   Layer         +         | Frame ->    Rate      ->         Link     Link           +           |
                 | Loss     Adjustment   Up/Down  Identifiers    |
                 | Rate                                          |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1.  Layered Indication Model
   For

2.  Architectural Considerations

   While the purposes literature provides persuasive evidence of connection management, the Transport layer
   typically only utilizes Internet layer indications such as changes utility of link
   indications, difficulties can arise in
   the incoming/outgoing interface and IP configuration changes.  For
   example, the making effective use of them.
   These include:

        a.  Model validation
        b.  Clear definitions
        c.  Robustness
        d.  Stability
        e.  Effectiveness
        f.  Interoperability
        g.  Race conditions
        h.  Layer compression
        i.  Transport layer may tear down transport connections due of link indications

   The sections that follow discuss each of these issues in turn.

2.1.  Model Validation

   Authors need to invalidation be careful to avoid use of a connection endpoint IP address.

   However, even simplified link models in
   circumstances where an Internet layer configuration change has
   occurred, the configuration change may they do not be relevant apply.

   In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
   the
   purposes authors provide examples of connection management.  For example, where modeling mistakes and examples of how
   to improve modeling of link characteristics.  To accompany the connection
   has been established based on paper
   the home address, a change authors provide simulation scenarios in ns-2.

   In order to avoid the care-
   of-address need not result pitfalls described in connection teardown, since the
   configuration change is masked by [Kotz] [GurtovFloyd],
   documents dependent on link indications should explicitly articulate
   the mobility functionality within assumptions of the Internet layer, link model and is therefore transparent to describe the Transport
   layer.

   Since a "Link Up" indication circumstances in
   which it applies.

   For example, generic "trigger" models often include implicit
   assumptions which may prove invalid in outdoor or may not result mesh deployments.
   For example, two-state Markov models where the link is either in a change
   state experiencing low frame loss ("up") or in
   Internet layer configuration, the Transport layer cannot draw
   conclusions about the implications of "Link Up" for connection
   management until the Internet layer has determined whether a
   configuration change has occurred.

   Similarly, the Transport layer does not tear down connections on
   receipt of a "Link Down" indication, regardless of the cause.  Where state where few
   frames are successfully delivered ("down") have frequently been used.
   In these models, symmetry is also typically assumed, so that the "Link Down" indication results from frame link
   is either "up" in both directions or "down" in both directions.  In
   situations where intermediate loss rather than an
   explicit exchange, the indication rates are experienced, these
   assumptions may be transient, to be soon
   followed by a invalid.

   Link indications based on signal quality "Link Up" indication.

   Even where Quality Crosses
   Threshold" typically assume the "Link Down" indication results from an explicit
   exchange such as receipt of a PPP LCP-Terminate or an 802.11
   Disassociate or Deauthenticate frame, an alternative point absence of
   attachment may be available, allowing connectivity multi-path interference,
   so that signal to be quickly
   restored.  As a result, robustness noise ratio varies smoothly in space, and frame
   loss is best achieved well predicted by allowing
   connections to remain up until an endpoint address changes, signal strength and distance.

   However, where multi-path interference is present, signal strength
   and signal/noise ratio can vary rapidly and  high signal/noise ratio
   can co-exist with high frame loss.  Where links may exist in
   intermediate states between "up" and "down" or the
   connection asymmetry is torn down due
   encountered, a "Link Quality Crosses Threshold" indication may
   exhibit excessive jitter and may prove to lack be unreliable predictors of response to repeated
   retransmission attempts.
   future link performance.

   In addition to Internet layer indications propagated to particular, authors should be mindful of the
   Application layer (such as IP address configuration and changes), following:

[1]  Do not assume symmetric link performance or frame loss that is
     either low ("up") or high ("down").

     In wired networks, links in the
   Transport layer provides its own indications to the Application
   layer, such as connection teardown.  The Transport layer  may also
   provide indications to the link layer.  For example, to prevent
   excessive retransmissions within the link layer, the Transport layer
   may wish to control the maximum number of times that a link layer "up" state typically experience low
     frame may be retransmitted, so that the link layer does not continue loss in both directions and are ready to retransmit after a Transport layer timeout.  In 802.11, this can
   be achieved by adjusting the MIB variables dot11ShortRetryLimit
   (default: 7) send and dot11LongRetryLimit (default: 4), which control receive
     data frames; links in the
   maximum number of retries "down" state are unsuitable for frames shorter sending
     and longer receiving data frames in length
   than dot11RTSThreshold, respectively.

   In most cases applications can obtain the information they need from
   Internet and Transport layer indications so that they do not need to
   directly consume either direction.  Therefore, a link indications.  For example,
     providing a "Link Up" indication will typically only implies that the link was suitable for
   sending experience low
     frame loss in both directions, and receiving high frame loss in any direction
     can only be experienced after a link layer control frames, provides a "Link Down"
     indication.  However, these assumptions may not that it has been
   configured hold true for and is capable of reliably sending and receiving IP
   data packets.  As
     wireless networks.

     Specifications utilizing a result, applications will typically consume an
   Internet layer "IP Address Configured" event instead "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"
   indication.  Similarly, it is typically event should not useful for applications
   to consume "Link Down" indications, since these indications can be sent due to transient
     changes in nature.  Instead, applications should consume Transport link conditions, but only due to a change in link layer teardown indications.

2.  Architectural considerations

   While the literature on the usage of Link indications provides
   persuasive evidence of their utility,  experience shows
     state.  It is best to assume that a number
   of difficulties "Link Up" event may not be sent
     in a timely way.  Large handoff latencies can arise result in making effective use of them.  These
   issues include:

        a.  Model validation
        b.  Robustness
        c.  Effectiveness
        d.  Interoperability
        e.  Race conditions
        f.  Layer compression
        g.  Transport of link indications

   The sections that follow discuss each of these issues a delay in turn.

2.1.  Model Validation

   Authors need to be careful to avoid use
     the generation of simplified link models in
   circumstances where they do not apply.  In order a "Link Up" event as movement to avoid an alternative
     point of attachment is delayed.

2.2.  Clear Definitions

   Once the
   pitfalls described in [Kotz], documents dependent on link indications
   should explicitly articulate network model is defined, considerable effort may be
   required to define the assumptions meaning of the link model indications and
   describe the circumstances in which it applies. clarify their
   usage on different link layers.  For example, generic "trigger" models often include implicit
   assumptions.  The use considerable work has
   been required in order to come up with the definitions of "Link Up"
   and "Link Down" Down", and to define when these indications
   implies that a link is either in a state experiencing low frame loss
   ("up") or in a state where few frames are successfully delivered
   ("down").  Symmetry may also be assumed, so that the sent on
   various link layers.

   Attempts have also been made to define link is either
   "up" in both directions or "down" in both directions.

   Link indications based on signal quality, such as 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.

   [GenTrig] defines "generic triggers", including "Link Doing Up", "Link
   Down", "Link Going Down", "Link Going Up", and "Link Quality Crosses Threshold" typically
   assume the absence of multi-path interference, so
   Threshold", "Trigger Rollback", and "Better Signal Quality AP
   Available".

   [IEEE-802.21] defines a Media Independent Handover Event Service
   (MIH-ES) that signal provides event reporting relating to
   noise ratio varies smoothly in space, and frame loss is well
   predicted by signal strength and distance.

   In wireless networks, particularly in outdoor or mesh deployments,
   the assumptions underlying generic trigger models may prove invalid.

   Where links may exist in intermediate states between "up" link
   characteristics, link status, and "down"
   or asymmetry is encountered, generic "triggers" such as link quality.  Events defined
   include "Link Going Down", "Link Going Up", and "Link Quality Crosses Threshold" may be
   difficult to reliably define Going Down", "Link Signal
   Strength" and may be unreliable predictors of
   future "Link Signal/Noise Ratio".

   Document authors defining new link performance.

   Once indications should heed the network model is defined, considerable effort may be
   required to define
   following advice:

[2]       Think carefully about the sensitivity of link indications model for to
          transient link conditions.  Due to effects such as multi-path
          interference, signal strength and signal/noise ratio may vary
          rapidly over a given short distance, causing rapid variations in
          frame loss and rate, and jitter in link layer.
   For example, indications based on
          these metrics.  This can create problems for upper layers that
          act on these indications without sufficient damping.

[3]       Where possible, design link indications with built-in damping.
          By design, the definition of "Link Up" or and "Link Down" varies
   considerably between events relate to
          changes in the state of the link layers.  Within PPP [RFC1661], either peer
   may send an LCP-Terminate frame in order layer that make it able and
          unable to terminate communicate IP packets.  These changes are either
          generated by the PPP link
   layer, and a layer state machine based on link may only be assumed to be usable layer
          exchanges (e.g. completion of the IEEE 802.11i four-way
          handshake for sending
   network protocol packets once NCP negotiation has completed "Link Up", or receipt of a PPP LCP-Terminate for
          "Link Down") or by protracted frame loss, so that
   protocol.

   Unlike PPP, IEEE 802 does not include facilities for network the link
          layer
   configuration, and concludes that the definition link is no longer usable.  As a
          result, these link indications are typically less sensitive to
          changes in transient link conditions.

2.3.  Robustness

   In some situations, improper use of "Link Up" and "Link Down" varies
   between and even within Link types.  For example, indications can result in IEEE 802.11,
   operational malfunctions.  Given the
   definition potential problems, proposals
   for consideration of "Link Up" link indications must demonstrate robustness
   against misleading indications.  Elements to consider include:

        a.  Implementation effects
        b.  Indication validation
        c.  Recovery from invalid indications
        d.  Damping and "Link Down" depends on whether the
   station is mobile or stationary, whether infrastructure or ad-hoc
   mode is hysteresis

2.3.1.  Implementation Effects

   Variations in use, and whether security and Inter-Access Point Protocol
   (IAPP) is implemented.

   Where a mobile 802.11 STA encounters link layer implementations may have a series of consecutive non-
   acknowledged frames, the most likely cause is that substantial
   impact on the station has
   moved out behavior of range link indications.  These variations need to
   be taken into account in evaluating the performance of proposals.

   Authors should consider the AP.  As a result, [Velayos] recommends following advice:

[4]       Do not assume that
   the station begin the search phase after collisions can be ruled out,
   after three consecutive non-acknowledged frames.  Only when no
   alternative point of attachment is found is a "Link Down" indication
   returned.

   In event will be sent at all, or
          that if sent, that it will received in a stationary point-to-point installation, 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 most likely cause
          link is unusable, not due to transient frame loss.

          However, existing implementations often do not do a good job
          of
   an outage detecting link failure.  During a lengthy detection phase,
          a "Link Down" event is that not sent by the link has become impaired, and alternative
   points layer, yet IP
          packets cannot be transmitted or received on the link.
          Initiation of attachment a scan may not be available.  As a result,
   implementations configured to operate delayed so that the station cannot
          find another point of attachment.  This can result in this mode tend to be more
   persistent.  For example,
          inappropriate backoff of retransmission timers within 802.11 the short interframe space
   (SIFS) interval may be increased
          transport layer, among other problems.

2.3.2.  Indication Validation

   Radio propagation and MIB variables relating to
   timeouts (such as  dot11AuthenticationResponseTimeout,
   dot11AssociationResponseTimeout, dot11ShortRetryLimit, implementation differences can impact the
   reliability of Link indications.

   As described in [Aguayo], wireless links often exhibit loss rates
   intermediate between "up" (low loss) and
   dot11LongRetryLimit) may be set to larger values. "down" (high loss) states,
   as well as substantial asymmetry.  In addition these circumstances, a "Link Down"
   Up" indication may be returned later.

   In 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 not imply bi-directional reachability.  Also,  a
   reachability demonstration based on small packets may not mean that
   the link is enabled at any time, and no
   explicit "Link Up" indication exists.

   In Infrastructure mode, IEEE 802.11-2003 enables reception of suitable for carrying larger data
   frames only in State 3 ("Authenticated" and "Associated"). packets.  As a result, a transition to State 3 (e.g. completion of a successful
   Association or Reassociation exchange) enables sending and receiving
   of network protocol packets
   "Link Up" and "Link Down" indications may not reliably determine
   whether a transition from State 3 to State 2
   (reception of a "Disassociate" frame) link is suitable for carrying IP data packets.

   Where multi-path interference or State 1 (reception of hidden nodes are encountered, frame
   loss may vary widely over a
   "Deauthenticate" frame) disables sending and receiving short distance.  While techniques such as
   use of network
   protocol packets. multiple antennas may be used to reduce multi-path effects and
   RTS/CTS signaling can be used to address hidden node problems, these
   techniques may not be completely effective.  As a result, IEEE 802.11 stations typically signal
   "Link Up" on receipt of a successful Association/Reassociation
   Response.

   As described within [IEEE80211F], 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 mobile
   host may find itself experiencing widely varying link conditions,
   causing the DS to forward frames link to rapidly cycle between "up" and "down" states,
   with "Going down" or "Going up" indications providing little
   predictive value.

   Where the station at its new point reliability of
   attachment.  Were the AP to not send this "spoofed" frame, the
   station's location would not be updated within the distribution
   system until a link layer indication is suspect, it sends its first frame at the new location.  Thus the
   purpose of spoofing is
   best for upper layers 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 treat the ESS.  Without
   spoofing, such an attack would only be able indication as a "hint" (advisory
   in nature), rather than a "trigger" forcing a given action.  In order
   to disassociate stations
   on the AP provide increased robustness, heuristics can be developed to which
   assist upper layers in determining whether the Reassociation Request was sent.

   The signaling of "Link Down" "hint" is considerably more complex.  Even
   though a transition to State 2 valid or State 1 results
   should be discarded.

   To provide robustness in the station
   being unable face of potentially misleading link
   indications, in [DNAv4] "Link Up" indications are assumed to send or receive IP packets, this does not necessarily
   imply be
   inherently unreliable, so that such a transition should bi-directional reachability needs to
   be considered a "Link Down"
   indication.  In demonstrated in the process  of validating an infrastructure network, a station may have existing IPv4
   configuration.  However, where a
   choice link exhibits an intermediate loss
   rate, the success of multiple access points offering connection to the same
   network.  In such an environment, a station [DNAv4] reachability test does not guarantee
   that the link is unable to reach
   State 3 with one access point may instead choose suitable for carrying IP data packets.

   Another example of link indication validation occurs in IPv4 Link-
   Local address configuration [RFC3927].  Prior to attach 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
   access point.  Rather than registering claimant, and address conflicts are relatively
   likely, a "Link Down" indication with
   each move, the station may instead register host returning from sleep mode or receiving a series of "Link Up"
   indications.

   In [IEEE80211i] forwarding of frames from the station
   indication could encounter an address conflict were it to the
   distribution system is only feasible after the completion of the
   4-way handshake utilize a
   formerly configured IPv4 Link-Local address without rerunning claim
   and group-key handshake, defend.

2.3.3.  Recovery From Invalid Indications

   Upper layers should utilize a timely recovery step so that entering State 3 as to limit the
   potential damage from link indications determined to be invalid after
   they have been acted on.

   Recovery is
   no longer sufficient.  This has resulted supported within [DNAv4] 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 RS/RA case where link
   indications may be triggered prior  lead a host to when erroneously conclude that the link is usable
   by
   prefix remains unchanged when the Internet layer, resulting in configuration delays or failures.
   Similarly, Transport layer connections will encounter packet loss,
   resulting host has in back-off of retransmission timers.

2.2.  Robustness fact changed networks.
   In some situations, improper use of Link indications can result in
   operational malfunctions.  Given this case, the potential problems, proposals
   for consideration of link indications must demonstrate robustness
   against misleading indications.  Elements to consider include:

        a.  Indication validation
        b.  Recovery from invalid indications
        c.  Damping bi-directional reachability test times out, and hysteresis

2.2.1.  Indication Validation

   Radio propagation the
   host will eventually realize its mistake and implementation differences can impact obtain an IP address by
   normal means.

   Where a proposal involves recovery at the
   reliability of Link indications. transport layer, the
   recovered transport parameters (such as the MTU, RTT, RTO, congestion
   window, etc.) must be demonstrated to remain valid.  Congestion
   window validation is discussed in [RFC2861].

   Where timely recovery is not supported, unexpected consequences may
   result.  As described in [Aguayo], wireless links often exhibit loss rates
   intermediate between "up" (low loss) and "down" (high loss) states,
   as well as substantial asymmetry. [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 these circumstances, 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" indication may not imply bi-directional reachability.  Also,  a
   reachability demonstration based on small packets may not mean that
   the prior to completion of link is suitable for carrying larger data packets. layer authentication),
   resulting in an initial failure to obtain a routable address using
   DHCP.  As a result,
   "Link Up" [RFC3927] recommends against modification of the
   maximum retransmission timeout (64 seconds) provided in [RFC2131].

2.3.4.  Damping and "Link Down" indications may not reliably determine
   whether a link is suitable for carrying IP data packets.

   Where multi-path interference Hysteresis

   Damping and hysteresis can be utilized to ensure that stability is
   maintained in the face of jittery link indications.  These limits
   typically place constraints on the number of times a given action can
   be performed within a time period or hidden nodes are encountered, introduce damping mechanisms to
   prevent instability.

   While [Aguayo] found that frame loss may vary widely over a short distance.  While techniques such as
   use of multiple antennas may be used was relatively stable for
   stationary stations, obstacles to reduce multi-path effects radio propagation and
   RTS/CTS signaling multi-path
   interference can be used to address hidden node problems, these
   techniques may not be completely effective. result in rapid changes in signal strength for a
   mobile station.  As a result, a it is possible for mobile
   host may find itself experiencing widely varying stations to
   encounter rapid changes in link conditions,
   causing performance, including changes in the link to rapidly cycle between "up"
   negotiated rate, frame loss and "down" states,
   with "Going down" or "Going up" indications providing little
   predictive value. 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 reliability of outgoing interface for "Weak End-System" implementations.  As a link layer indication is suspect,
   result, it is
   best for upper layers may be necessary to treat introduce route flap dampening.

   However, the indication as a "hint" (advisory
   in nature), rather than a "trigger" forcing a given action.  In order benefits of damping need to provide increased robustness, heuristics be weighed against the
   additional latency that can be developed to
   assist upper layers in determining whether the "hint" is valid or
   should be discarded.

   To provide robustness in the face of potentially misleading link
   indications, introduced.  For example, in [DNAv4] order to
   filter out spurious "Link Up" Down" indications, these indications are assumed to may be
   inherently unreliable, so that bi-directional reachability needs to
   delayed until it can be demonstrated in the process  of validating an existing IP
   configuration. determined that a "Link Up" indication will
   not follow shortly thereafter.  However, in situations where multiple
   Beacons are missed such a link exhibits an intermediate loss
   rate, the success of the [DNAv4] reachability test does delay may not guarantee
   that the link be needed, since there is no
   evidence of a suitable for carrying IP data packets.

   Another example point of link indication validation occurs occurs attachment in IPv4
   Link-Local address configuration [RFC3927].  Prior to configuration
   of an IPv4 Link-Local address, the vicinity.

   In many cases it is necessary desirable to run a claim and
   defend protocol. ignore link indications entirely.
   Since it is possible for a host needs to be present transition from an ad-hoc network
   to defend its
   address against another claimant, and a network with centralized address conflicts are
   relatively likely, management, a host returning from sleep mode or receiving a
   "Link Up" indication could encounter an address conflict were cannot necessarily conclude that it is
   appropriate to
   utilize configure a formerly configured IPv4 Link-Local address without
   rerunning claim and defend.

2.2.2.  Recovery From Invalid Indications

   Upper layers should utilize a timely recovery step so as to limit the
   potential damage from link indications determined prior to be invalid after
   they have been acted on.

   Recovery
   determining whether a DHCP server is supported within [DNAv4] available [RFC3927].

   As noted in Section 1.4, the case where link Transport layer does not utilize "Link
   Up" and "Link Down" indications may  lead a host to erroneously conclude that for the purposes of connection
   management.  Since applications can obtain the information they need
   from Internet and Transport layer indications they should not utilize
   link
   prefix remains unchanged when indications.

2.4.  Stability

   Link indication proposals must demonstrate that effective congestion
   control is maintained [RFC2914].

   For example,  algorithms that adjust rate based on frame loss need to
   demonstrate conservatism in the host has face of congestion.  The large
   variance in fact changed subnets.
   In this case, rate adaptation behavior of existing 802.11
   implementations is worrisome since implementations that rapidly
   decrease the bi-directional reachability test times out, and negotiated rate in response to frame loss can cause
   congestive collapse in the
   host will eventually realize its mistake and obtain link layer, even where backoff is
   correctly implemented.  For example, an IP address implementation that decreases
   rate by
   normal means.

   Where a proposal involves recovery at factor of two while backing off the transport layer, retransmission timer by
   a factor of two has not really reduced consumption of the
   recovered transport parameters (such as critical
   resource, namely available slots within the MTU, RTT, RTO, congestion
   window, etc.) must be demonstrated to remain valid.  Congestion
   window validation is discussed in [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 MAC.

   Consider a
   routable address after assigning an IPv4 Link-Local address.  In one
   implementation, it was observed that proposal 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 (signalling of "Link Up" prior to completion indication is used by a host to
   trigger retransmission of link layer authentication),
   resulting the last previously sent packet, in an initial failure order
   to obtain a routable address using
   DHCP.  As a result, [RFC3927] recommends against modification enable ACK reception prior to expiration of the
   maximum host's
   retransmission timeout (64 seconds) provided timer.  On a rapidly moving mobile node where "Link
   Up" indications follow in [RFC2131].

2.2.3.  Damping and Hysteresis

   Damping and hysteresis can be utilized to ensure that stability is
   maintained rapid succession,  this could result in a
   burst of retransmitted packets, violating the face principle of jittery link indications.  These limits
   typically place constraints on
   "conservation of packets".

   At the number 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 times a given action can
   be performed within a time period or introduce damping mechanisms to
   prevent instability.

   While [Aguayo] found that frame loss was relatively stable for
   stationary stations, obstacles to radio propagation
   "Link Up" indication, and multi-path
   interference can result in rapid changes in signal strength for presence de-registration by a
   mobile station.  As surrogate
   receiving a result, it is possible for mobile stations to
   encounter rapid changes in link performance, including changes in the
   negotiated rate, frame loss and even "Link Down" indication.

   Presence implementations using "Link Up"/"Link Down"
   indications.

   Where link-aware routing metrics are implemented, indications this can result in
   rapid metric changes, potentially resulting in frequent changes in
   way violate the outgoing interface for "Weak End-System" implementations.  As a
   result, it may be necessary to introduce route flap dampening.

   However, the benefits principle 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 "conservation of packets" when link
   indications may be
   delayed until it are generated on a time scale of RTO or less.  The
   problem is magnified since for each presence update, notifications
   can be determined that delivered to many watchers.  In addition, use of a "Link Up"
   indication will
   not follow shortly thereafter.  However, in situations where multiple
   Beacons are missed such a delay this manner is unwise since the interface may not yet
   have an operable Internet layer configuration.

   The issue can be needed, since there is no
   evidence of a suitable point addressed by one or more of attachment in the vicinity.

   In some cases, it may following
   techniques:

[a]   Rate limiting.  A limit of one packet per RTO can be desirable to ignore imposed on
      packets generated from receipt of link indications
   entirely.  Since it is possible for indications.

[b]   Utilization of upper layer indications.  Instead of utilizing a host to transition from
      "Link Up" indication, applications can instead depend on upper
      layer indications such as an ad-
   hoc network to a network with centralized IP address management, a host
   receiving configuration/change
      notifications.

[c]   Keepalives.  Instead of utilizing a "Link Up" indication cannot necessarily conclude that it
   is appropriate to configure a IPv4 Link-Local address prior Down" indication, an
      application can utilize an application keepalive or Transport
      layer indications such as connection teardown.

[d]   Stability analysis.  Proposals must be analyzed to
   determining determine
      whether a DHCP server is available [RFC3927].

   As noted they result in congestive collapse either in Section 1.5, the Transport transport
      layer does not utilize "Link
   Up" and "Link Down" indications for the purposes of connection
   management.  In most cases applications can obtain or at the information
   they need from Internet and Transport layer link layer.

2.5.  Effectiveness

   While link indications so that they
   do not need may show promise, it may be difficult to directly consume link indications. prove
   that processing of a given indication provides benefits in a wide
   variety of circumstances.  Where link indications are used utilized for
   the purpose of optimization, proposals need to optimize transport performance,
   authors must demonstrate that effective congestion control is
   maintained [RFC2914] carefully analyze the
   effectiveness of the optimizations in the face of rapidly changing unreliable link
   indications.

   Consider a proposal where  Since optimizations typically bring with them increased
   complexity, an optimization that does not bring about a "Link Up" indication performance
   improvement is used by a router
   to trigger retransmission of not useful.

   As with any optimization, the last previously sent packet, in
   order to enable ACK reception prior to expiration usefulness of the host's
   retransmission timer.  Where "Link Up" link indications follow in rapid
   succession,  this could result lies in a burst
   demonstrated effectiveness of retransmitted packets,
   violating the principle of "conservation of packets".

   At optimization under consideration.
   This in turn may depend heavily on the Application Layer, Link indications have been utilized by
   applications such as Presence [RFC2778] penalty to be paid for false
   positives and false negatives.

   As noted in order [DNAv4], it is simultaneously possible for a link
   indication to optimize
   registration be highly reliable and user interface update operations.  For example,
   implementations may attempt presence registration provide no net benefit,
   depending on receipt the probability of a
   "Link Up" indication, false indication and presence de-registration by a surrogate
   receiving a "Link Down" the penalty
   paid for the false indication.

   Presence implementations using "Link Up"/"Link Down" indications this
   way violate  In the principle case of "conservation [DNAv4], the benefits
   of packets" when link
   indications successful optimization are generated on a time scale of RTO or less.  The
   problem is magnified since modest, but the penalty for each presence update, notifications
   can be delivered to many watchers.  In addition, use of falsely
   concluding that the network remains unchanged is a "Link Up"
   indication in this manner lengthy timeout.
   The result is unwise since the interface that link indications may not yet
   have a valid Internet layer configuration.

   The issue can be addressed by one or worth considering if
   they are incorrect more than a small fraction of the following
   techniques:

[a]   Rate limiting.  A limit of one packet per RTO time.

   For example, it can be imposed on
      packets generated from receipt of link indications.

[b]   Utilization of upper layer indications.  Instead of consuming argued that a
      "Link Up" indication, applications can consume alternative upper
      layer indications such as an IP address configuration/change
      notifications.

[c]   Keepalives.  Instead of consuming change in the Service Set
   Identifier (SSID) in [IEEE-802.11] is not a "Link Down" indication, an
      application can utilize an application keepalive or consume
      Transport layer indications such as connection teardown.

2.3.  Effectiveness

   While link indications may show promise, it may be difficult to prove
   that processing sufficiently reliable
   indication of a given indication provides benefits in prefix change.  Within IEEE 802.11, the Service Set
   Identifier (SSID) functions as a wide
   variety non-unique identifier of circumstances.  Where link indications are utilized for the purpose of optimization, proposals need to carefully analyze the
   effectiveness of the optimizations in the face of unreliable link
   indications.  Since optimizations typically bring with them increased
   complexity, an optimization that does not bring about a performance
   improvement is not useful.

   As with any optimization, the usefulness of link indications lies in
   demonstrated effectiveness of the optimization under consideration.
   This in turn may depend heavily on the penalty to be paid for false
   positives and false negatives.

   As noted in [DNAv4], it is simultaneously possible for a link
   indication to be highly reliable and provide no net benefit,
   depending on the probability of a false indication and the penalty
   paid for the false indication.

   In the case of [DNAv4], the benefits of successful optimization are
   modest, but the penalty for falsely concluding that the subnet
   remains unchanged is a lengthy timeout.  The result is that link
   indications may not be worth considering if they are incorrect even
   just a small fraction of the time.

   For example, it can be argued that a change in the Service Set
   Identifier (SSID) in [IEEE80211] is not a sufficiently reliable
   indication of a prefix change.  Within IEEE 802.11, the Service Set
   Identifier (SSID) functions as a non-unique identifier of the
   administrative domain
   administrative domain of a Wireless LAN.  Since the SSID is non-
   unique, many different operators may share the same SSID, and Access
   Points typically ship with a default value for the SSID (e.g.
   "default").  Since the SSID relates to the administrative domain and
   not the network topology, multiple SSIDs may provide access to the
   same prefix, and a single SSID may provide access to multiple
   prefixes at one or multiple locations.

   Given this, it is unreliable to use the SSID alone for the purpose of
   movement detection.  A host moving from one point of attachment to
   another, both with the same SSID, may have remained within the same
   subnet,
   network, or may have changed subnets. networks.  Similarly, a  host
   discovering that the SSID has changed may have changed subnets, networks, or
   it may not have.  Moreover, where private address space is in use, it
   is possible for the SSID,  the prefix (e.g. 192.168/16) and even the
   default gateway IP address to remain unchanged, yet for the host to
   have moved to a different point of attachment. network.  Were the host to make decisions
   relating to configuration of the IP layer (such as address
   assignment) based solely on the SSID, address conflicts are likely.

2.4.

2.6.  Interoperability

   In general, link indications should only be incorporated by upper
   layers for performance optimization, but should not be required, required in
   order to main link independence.

   To avoid compromising interoperability in the pursuit of performance
   optimization, proposals must demonstrate that interoperability
   remains possible (though potentially with degraded performance) even
   if one or more participants do not implement the proposal.

   For example, if link layer prefix hints are provided as a substitute
   for Internet layer configuration, hosts not understanding those hints
   would be unable 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).

2.5.

2.7.  Race Conditions

   It is possible for link indications to be utilized directly by
   multiple layers of the stack in situations in which strict layering
   may not be observed.  In these situations, it is possible for race
   conditions to occur.

   For example, as discussed earlier, link indications have been shown
   to be useful in optimizing aspects of Internet Protocol layer
   addressing and configuration as well as routing.  Although [Kim]
   describes situations in which link indications are first processed by
   the Internet Protocol layer (e.g. MIPv6) before being consumed utilized by the
   Transport layer, for the purposes of parameter estimation, it may be
   desirable for the Transport layer to consume utilize link indications
   directly.

   For example, 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 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 on one of
   its interfaces,  a routing metric taking frame loss into account will
   rise, 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 for the original interface (MTU, congestion
   state) may no longer be valid for the new outgoing and incoming
   paths.

   To avoid race conditions, the following measures are recommended:

        a.  Path change processing
        b.  Layering
        c.  Metric consistency

2.5.1.

2.7.1.  Path Change Processing

   When the Internet layer detects a path change, such as a change in
   the outgoing or incoming interface of the host or the incoming
   interface of a peer, or perhaps a substantial change in the TTL of
   received IP packets, it may be worth considering whether to reset
   transport parameters (RTT, RTO, cwnd, MTU) to their initial values
   and allow them to be re-
   estimated. re-estimated.  This ensures that estimates based
   on the former path do not persist after they have become invalid.

2.5.2.
   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.  Since
   one of the major objectives of the Internet layer is maintaining link
   layer independence, upper layers relying on Internet layer
   indications rather than consuming link indications directly can avoid
   link layer dependencies.

   As described in Section 1.5,

   In general, it is advisable for applications to utilize indications
   from the Internet or Transport layers rather than consuming link
   indications directly.

2.5.3.

2.7.3.  Metric Consistency

   Once a link is in the "up" state, its effectiveness in transmission
   of data packets can be determined.  For example, frame loss may be
   used to assist in rate adjustment and to determine when to select an
   alternative point of attachment.  Also, the effective throughput
   depends on the negotiated rate and frame loss, and can be used in
   calculation of the routing metric, as described in [ETX].

   However, prior to sending data packets over the link, other metrics
   are required to determine suitability.  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 data packets.

   Since the negotiated rate and frame loss typically cannot be
   predicted prior to utilizing the link for data traffic, existing
   implementations often utilize metrics such as signal strength and
   access point load in handoff decisions.  The "Link Going Down",
   "Link Going Up", "Link Quality Crosses Threshold" indications were
   developed primarily to assist with handoff between interfaces, and
   are oriented toward inferred rather than measured suitability.

   Research indicates that this approach may have some promise.  In
   order to enable stations to roam prior to encountering packet loss,
   studies such as [Vatn] have suggested using signal strength as a
   detection mechanism, rather than frame loss, as suggested in
   [Velayos].  [Vertical] proposes use of signal strength and link
   utilization in order to optimize vertical handoff and demonstrates
   improved TCP throughput.

   However, 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.  For example, receipt of "Link Going Down" or "Link Quality
   Crosses Threshold" indications could be used as a signal to enable
   another interface.  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
   unused interface will be brought down, only to be brought up again by
   the link enablement algorithm.

   As noted in [Aguayo], signal strength and distance are not good
   predictors of frame loss or negotiated rate, 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 negotiated rate.  Similarly, an AP
   demonstrating low utilization may not necessarily be the best choice,
   since utilization may be low due to hardware or software problems.
   As noted in [Villamizar],
   [Villamizar] notes that link utilization-based routing metrics have a
   history of instability, so that they are rarely deployed.

2.6.

2.8.  Layer compression

   In many situations, the exchanges required for a host to complete a
   handoff and reestablish connectivity are considerable.  This includes
   link layer scanning, authentication and connectivity establishment;
   Internet layer configuration, routing and mobility exchanges;
   Transport layer retransmission and recovery; security association re-
   establishment;  application protocol re-authentication and re-
   registration exchanges, etc.  Given this, it  It is therefore natural to consider
   combining exchanges occurring within multiple layers into a single
   exchange. in order to
   reduce overhead.

   Often this combined exchange occurs within the link layer.  For
   example, in [EAPIKEv2], a link layer EAP 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.

   While the goals of layer compression are laudable, care needs to be
   taken to avoid compromising interoperability and introducing link
   layer dependencies into the  Internet and Transport layers.  For
   example, where link layer and link, Internet or Transport layer mechanisms are
   combined, it is necessary for hosts need to maintain the ability to
   interoperate without layer compression schemes, in order backward compatibility to permit
   operation on networks where they 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,
   [IEEE8021X]
   [IEEE-802.1X] enables the 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.7.

2.9.  Transport of Link Indications

   Proposals including the transport of link indications beyond the
   local host need to carefully consider the layering, security and
   transport implications.

   In general, implicit signals are preferred to explicit transport of
   link indications since they add no new packets in times of network
   distress, operate more reliably in the presence of middle boxes such
   as NA(P)Ts, and are more likely to be backward compatible.

   While facilities such as ICMP "source quench" were originally
   provided at the Internet layer, these facilities have fallen into
   disuse due to their questionable value for the Transport layer.  In
   general, the Transport layer is able to determine an appropriate (and
   conservative) response to congestion based on packet loss or explicit
   congestion notification, so that ICMP "source quench" indications are
   not needed, and in fact the sending of additional "source quench"
   packets during periods of congestion may be detrimental.

   Where explicit signalling is required, existing facilities should be
   used rather than creating new ones.  For example, "TCP Extensions for
   Immediate Retransmissions" [Eggert] describes how a Transport layer
   implementation may utilize existing "end-to-end connectivity
   restored" indications.

   For example, routing

   Routing metrics incorporating link layer indications
   such as [ETX] enable hosts participating in the routing mesh gateways
   to gain obtain knowledge of path changes and take remote link conditions.  This can be
   accomplished securely if routing protocol security is implemented. conditions
   into account for the purposes of route selection.  When a link
   experiences frame loss, routing metrics incorporating frame loss such
   as the metric described in [ETX] increase, possibly resulting in
   selection of an alternate route.  If the a troubled link represents the
   only path to a prefix and the link experiences high frame loss
   ("down"), the route will be withdrawn or the metric will become
   infinite.  Similarly, when the link becomes operational, the route
   will appear again.

   Proposals involving transport of link indications need to demonstrate
   the following:

[a]   Absence of alternatives.  By default, alternatives not requiring
      explicit signalling are preferred.  Where these solutions are
      shown to be inadequate, proposals must prove that existing
      explicit signalling mechanisms (such as path change processing and
      link-aware routing metrics) are inadequate.

[b]   Conservative behavior.  Due to experience with ICMP "source
      quench", proposals must demonstrate that they do not violate
      conservation of packets.

[c]   Security.  Proposals need to describe how protocol security issues is implemented,
   this information can be
      addressed. securely propagated.

   Where link indications are transported over the
      Internet,  an attack can explicit signaling is required, existing facilities should be launched without requiring access to
      the link.

[d]   Identifiers.  When link indications are transported,
   used rather than creating new ones.  "Fault Isolation and Recovery"
   [RFC826] Section 3 describes how hosts can make use of ICMP messages:

      In  fact, it is
      generally never necessary  for the purposes of saying something about Internet,
      Transport or Application layer operations at a remote element.
      These layers use different identifiers, and so it is necessary host to
      match explicitly ask a
      gateway for advice, because the link indication with relevant higher layer state.
      Therefore proposals need gateway will provide it as
      appropriate.  When a host sends  a datagram to demonstrate how some distant net,
      the link indication
      can host should be mapped prepared to receive back either of two advisory
      messages which the right higher layer state.

      For example, if a presence server gateway may send.  The ICMP "redirect"  message
      indicates that the gateway to which the host sent the datagram is receiving remote indications
      of "Link Up"/"Link Down" status for a particular MAC address,
      not longer the
      presence server best gateway to reach the net in question.  The
      gateway will need have forwarded the datagram, but the host should
      revise its routing table to associate that MAC have  a different  immediate  address with
      for  this net.  The ICMP "destination unreachable" message
      indicates that as a result of an outage, it is currently
      impossible to reach the
      identity addressed net or host in any  manner.  On
      receipt of this message, a host can either abandon the user (pres:user@example.com) connection
      immediately without any further retransmission, or resend slowly
      to whom that link
      status change  see if the fault is relevant.

3.  Future Work

   While Figure 1 presents an overview of corrected in reasonable time.

   "TCP Extensions for Immediate Retransmissions" [Eggert] describes how
   a Transport layer implementation may utilize existing "end-to-end
   connectivity restored" indications.

   Proposals involving transport of link indications are
   consumed by need to demonstrate
   the Internet, Transport and Application layers, further
   work is needed following:

[a]   Absence of alternatives.  By default, alternatives not requiring
      explicit signaling are preferred.  Where these solutions are shown
      to investigate this in more detail.

   Since recent be inadequate, proposals such must prove that existing explicit
      signaling mechanisms (such as [IEEE80211e] incorporate burst ACKs,
   the relationship between 802.11 link throughput path change processing and frame link-
      aware routing metrics) are inadequate.

[b]   Conservative behavior.  Due to experience with ICMP "source
      quench", proposals must demonstrate that they do not violate
      conservation of packets.

[c]   Security.  Proposals need to describe how security issues can be
      addressed.  Where link indications are transported over the
      Internet,  an attack can be launched without requiring access to
      the link.

[d]   Identifiers.  When link indications are transported, it is
      generally for the purposes of saying something about Internet,
      Transport or Application layer operations at a remote element.
      These layers use different identifiers, and so it is necessary to
      match the link indication with relevant higher layer state.
      Therefore proposals need to demonstrate how the link indication
      can be mapped to the right higher layer state.

      For example, if a presence server is receiving remote indications
      of "Link Up"/"Link Down" status for a particular 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

   While Figure 1 presents an overview of how link indications are
   utilized by the Internet, Transport and Application layers, further
   work is needed to investigate this in more detail.

   More work is needed in the area of link-aware routing metrics.  For
   example, since recent proposals such as [IEEE-802.11e] incorporate
   burst ACKs, the relationship between 802.11 link throughput and frame
   loss is growing more complex, which complex.  This may necessitate the development
   of revised routing metrics, taking the more complex transmission retransmission
   behavior into account, as well as the negotiated rate into account. rate.

   At the Link and Internet layers, more work is needed to reconcile pre
   and post-connection metrics, such as reconciling metrics utilized in
   handoff (e.g. signal strength and link utilization) with link-aware
   routing metrics (e.g. frame loss and negotiated rate).

   At the Transport layer, more work is needed to understand how to
   react to Internet layer indications such as path changes.  For
   example, in an early draft of [DCCP], a "Reset Congestion State"
   option was proposed in Section 4.  This option was removed in part
   because the use conditions were not fully understood:

      An Half-Connection 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.

   It may also make sense for the Transport layer to adjust transport
   parameter estimates  It may
   also make sense for the Transport layer to adjust transport parameter
   estimates in response to "Link Up"/"Link Down" indications and frame
   loss.  For example, it is unclear that the Transport layer should
   adjust transport parameters as though congestion were detected when
   loss is occurring in the link layer or a "Link Down" indication has
   been received.

   Finally, more work is 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.

4.  Security Considerations

   Since link indications are typically insecure, proposals
   incorporating them need to consider the potential security
   implications of spoofed or modified link indications, as well as
   potential denial of service attacks.  This is particularly important
   in situations where insecure link indications are used as a
   substitute for secure mechanisms operating at a higher layer.

   For example, within [IEEE80211F], [IEEE-802.11F], "Link Up" is considered to occur
   when an Access Point sends a Reassociation Response.  At that point,
   the AP sends a frame with the station's source address to a multicast
   address, thereby causing switches within the Distribution System to
   learn the station's MAC address, enabling forwarding of frames to the
   station at the new point of attachment.  Unfortunately, this does not
   take security into account, since the station is not capable of
   sending and receiving IP packets on the link until completion of the
   key exchange protocol defined in [IEEE80211i]. [IEEE-802.11i].  As a result, link
   indications as implemented in [IEEE80211F] [IEEE-802.11F] enable an attacker to
   disassociate a station located anywhere within the ESS, by sending a
   Reassociation Request frame.

   Another example of the potential security implications of link
   indications occurs within DNAv4, where link indications are used for
   optimization of IP configuration, rather than using a secured
   configuration mechanism such as authenticated DHCP [RFC3118], thereby
   increasing vulnerability to spoofing.

5.  References

5.1.  Informative References

[RFC816]  Clark, D., "Fault Isolation and Recovery", RFC 816, July 1982.

[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June
          1988.

[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1989.

[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", RFC 1918,
          February 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.

[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.

[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
          RFC 3118, June 2001.

[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
          D. Gurle, "Session Initiation Protocol (SIP) Extension for
          Instant Messaging", RFC 3428, December 2002.

[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, October 2004. May 2005.

[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.

[DCCP]    Kohler, E., Handley, M.
          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.

[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",
          draft-ietf-bfd-base-02.txt, Internet draft (work in progress),
          March 2005.

[Biaz]    Biaz, S. and N. Vaidya, "Discriminating Congestion Losses from
          Wireless Losses Using Interarrival Times at the Receiver",
          Proc. IEEE Symposium on Application-Specific Systems and
          Software Engineering and Technology, Richardson, TX, Mar 1999.

[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.

[DCCP]    Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion
          Control Protocol (DCCP)", Internet drafts (work in progress),
          draft-ietf-dccp-spec-08.txt, October 2004.

[DNAv4]   Aboba, B., "Detection of Network Attachment in IPv4", draft-
          ietf-dhc-dna-ipv4-13.txt, Internet draft (work in progress),
          June 2005.

[E2ELinkup]
          Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-Up'
          Notification",  draft-dawkins-trigtran-linkup-01.txt, Internet
          draft (work in progress), October 2003.

[EAPIKEv2]
          Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2
          Method", draft-tschofenig-eap-ikev2-05.txt, Internet draft
          (work in progress), October 2004.

[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.

[Eggert]  Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions for
          Immediate Retransmissions", draft-eggert-tcpm-tcp-retransmit-
          now-01.txt, Internet draft (work in progress), September 2004.

[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.

[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.

[Gurtov]  Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers on
          Performance of TCP-Friendly Rate Control", to appear in ACM
          MCCR, 2004.

[GurtovFloyd]
          Gurtov, A. and S. Floyd, "Modeling Wireless Links for
          Transport Protocols", Computer Communications Review (CCR) 34,
          2 (2003).

[HMP]     Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation Protocol
          (HMP)", draft-lee-hmp-00.txt, Internet draft (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, "Draft
          Amendment 7: Medium Access Control (MAC) Quality of Service
          (QoS) Enhancements", IEEE 802.11e Draft 10.0, October 2004.

[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.

[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/D2.0, February 2005.

[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.

[Kim]     Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger
          method for improving TCP performance over Mobile IPv6", draft-
          kim-tsvwg-butrigger-00.txt, Internet draft (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., Allman, M., Partridge, P. and J. Sterbenz,
          "Explicit Transport Error Notification (ETEN) for Error-Prone
          Wireless and Satellite Networks", Technical Report No. 8333,
          BBN Technologies, March 2002.

[Lee]     Park, S., Lee, M. and J. Korhonen, "Link Characteristics
          Information for Mobile IP", draft-daniel-mip-link-
          characteristic-01.txt, Internet draft (work in progress),
          April 2005.

[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", draft-giaretta-mip6-authorization-eap-02.txt,
          Internet draft (work in progress), October 2004.

[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.

[Mitani]  Mitani, K., Shibui, R., Gogo, K. and F. Teraoka, "Unified L2
          Abstractions for L3-Driven Fast Handover", draft-koki-mobopts-
          l2-abstractions-02.txt, Internet draft (work in progress),
          February 2005.

[Mun]     Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with
          802.11", draft-mun-mobileip-layer2-handoff-mipv4-01.txt,
          Internet draft (work in progress), March 2004.

[PEAP]    Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and S.
          Josefsson, "Protected EAP Protocol (PEAP) Version 2", draft-
          josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in
          progress), October 2004.

[Park]    Park, S., Njedjou, E. and N. Montavont, "L2 Triggers Optimized
          Mobile IPv6 Vertical Handover: The 802.11/GPRS Example",
          draft-daniel-mip6-optimized-vertical-handover-00.txt, July
          2004.  ,IP [PRNET] Jubin, J. and J. Tornow, "The DARPA packet
          radio network protocols", Proceedings of the IEEE, 75(1),
          January 1987.

[Ramani]  Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff
          for 802.11 Infrastructure Networks", Proceedings of the IEEE
          InfoCon 2005, March 2005.

[Scott]   Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for
          Disconnecting Networks", ACM SIGCOMM Computer Communication
          Review, 33(5), October 2003.

[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.

[Swami]   Swami, Y., Le, K., Eddy, W., "Lightweight Mobility Detection
          and Response (LMDR) Algorithm for TCP", draft-swami-tcp-
          lmdr-05, Internet draft (work in progress), February 2005.

[TRIGTRAN]
          Dawkins, S., Williams, C. and A. Yegin, "Framework and
          Requirements for TRIGTRAN", draft-dawkins-trigtran-
          framework-00.txt, Internet draft (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.

[Yegin]   Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
          l2-triggers-00.txt, Internet Draft (work in progress), June
          2002.

[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)", draft-
          ietf-ospf-omp-02.txt, Internet draft (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.

Appendix A - Literature Review

   This Appendix summarizes the literature on utilization of link
   indications within the Link, Internet, Transport and Application
   layers.

A.1 Link Layer

   The characteristics of wireless links have been found to vary
   considerably depending on the environment.  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 either be assumed to
   operate very well or not at all.

   "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
   analyzes 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 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 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 phases (connection to an alternative point of attachment).
   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, 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 S/N ratio.  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
   STAs implementations communicating with two APs.  The study found
   that there is 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
   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
   S/N 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 measure 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 NTP, enabling a
   driver implementing SyncScan to work with legacy APs without
   requiring implementation of new protocols.  The authors measure the
   distribution of inter-arrival times for stations implementing
   SyncScan, with excellent results.

   "Roaming Interval Measurements" [Alimian] presents data on 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 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 continue to receive
   data frames during the search phase.  Station-initiated
   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 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 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 mobile 802.11 STA encounters a series of consecutive non-
   acknowledged frames, 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,
   after three consecutive non-acknowledged frames.  Only when no
   alternative 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 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
   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 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.

A.1.2 Smart Link Layer Proposals

   In order to improve link layer performance, several studies have
   investigated "smart link layer" proposals.

   In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the
   authors describe how the 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 SCTP 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 backoff 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 slowstart 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
   as retransmission of multiple packets and rereception of single or
   multiple packets.

   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 one hundred
   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.

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 "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link
   indications are utilized to enable a host that has moved to a new
   point of attachment to rapidly confirm a currently operable
   configuration, rather than utilizing the DHCP protocol [RFC2131].

   "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX]
   describes how routing metrics can be improved by taking link layer
   frame loss rates into account, enabling the selection of routes
   maximizing available throughput.  While the proposed routing metric
   utilizes the Expected Transmission Count (ETX), it does not take the
   negotiated rate into account, although this was noted as a subject
   for further study.

   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 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, such as is described in
   [DNAv4].

   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 the new point of attachment represents a change of network or
   not.  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, GPRS,
   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 in congestion.  Also, where link rates change frequently,
   sending registration messages on each rate 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 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 adhoc wireless mesh monitor local conditions such
   as MAC delay, buffer consumption and packets 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 throttle TCP
   connections flowing through them.  The authors argue that for adhoc
   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.

   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.  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 "Lightweight Mobility Detection and Response (LMDR) Algorithm for
   TCP" [Swami], 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 reestimated.  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 an early draft of [DCCP], a "Reset Congestion State" option was
   proposed in Section 4.  This option was removed in part because the
   use conditions were not fully understood:

      An Half-Connection 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.

   "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.

   In "TCP Extensions for Immediate Retransmissions" [Eggert], 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 interarrival 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 S. Floyd, "Datagram Congestion
          Control Protocol (DCCP)", Internet drafts (work in progress),
          draft-ietf-dccp-spec-08.txt, October 2004.

[DNAv4]   Aboba, B., "Detection "bad" states.  Where the receiver is connected over a wireless
   link, the authors simulate the effect of Network Attachment in IPv4", draft-
          ietf-dhc-dna-ipv4-09.txt, Internet draft (work in progress),
          October 2004.

[E2ELinkup]
          Dawkins, S. an Explicit Bad State
   Notification (EBSN) sent by a base station unable to reach the
   receiver.  In response to an EBSN, it is advocated that the existing
   retransmission timer be canceled and C. Williams, "End-to-end, Implicit 'Link-Up'
          Notification",  draft-dawkins-trigtran-linkup-01.txt, Internet
          draft (work in progress), October 2003.

[EAPIKEv2]
          Tschofenig, H., D. Kroeselberg replaced by a new dynamically
   estimated timeout, rather than being backed off.  In the simulations,
   EBSN prevents unnecessary timeouts, decreasing RTT variance and Y. Ohba, "EAP IKEv2
          Method", draft-tschofenig-eap-ikev2-05.txt, Internet draft
          (work
   improving throughput.

   In "A Feedback-Based Scheme for Improving TCP Performance in progress), October 2004.

[Eckhardt]
          Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of Ad-Hoc
   Wireless Networks" [Chandran], the Error Characteristics of authors proposed an In-Building Wireless Network",
          SIGCOMM '96, August 1996, Stanford, CA.

[Eggert]  Eggert, L., Schuetz, S. 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 S. Schmid, "TCP Extensions for
          Immediate Retransmissions", draft-eggert-tcpm-tcp-retransmit-
          now-01.txt, Internet draft (work 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 progress), September 2004.

[ETX]     Douglas S. J. De Couto, Daniel Aguayo, John Bicket, mobile ad hoc networks.
   ELFN informs the TCP sender about link and Robert
          Morris, "A High-Throughput Path Metric for Multi-Hop Wireless
          Routing", Proceedings 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 9th ACM International Conference Dynamic Source Routing (DSR) protocol, it is demonstrated that
   TCP performance falls considerably short of expected throughput based
   on Mobile Computing and Networking (MobiCom '03), San Diego,
          California, September 2003.

[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer
          Triggers", submission the percentage of the time that the network is partitioned.   A
   portion of the problem was attributed to IEEE 802.21 (work in progress), March
          2004, available at:
          http://www.ieee802.org/handoff/march04_meeting_docs/
          Generalized_triggers-02.pdf

[IEEE8021X]
          Institute the inability of Electrical and Electronics Engineers, "Local the routing
   protocol to quickly recognize and
          Metropolitan Area Networks: Port-Based Network Access
          Control", IEEE Standard 802.1X, December 2004.

[IEEE80211]
          Institute of Electrical purge stale routes, leading to
   excessive link failures; performance improved dramatically when route
   caching was turned off.  Interactions between the route request and Electronics Engineers, "Wireless
          LAN Medium Access Control (MAC)
   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 Physical Layer (PHY)
          Specifications", IEEE Standard 802.11, 2003.

[IEEE80211e]
          Institute where the route
   request timer is too small, network congestion may result.  For their
   implementation of Electrical ELFN, the authors piggybacked additional
   information on an existing "route failure" notice (sender and Electronics Engineers, "Draft
          Amendment 7: Medium Access Control (MAC) Quality
   receiver addresses and ports, the TCP sequence number) 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 acknowledgement is received
   then the retransmission timers are restored.  Simulations show that
   performance is sensitive to the probe interval, with intervals of Service
          (QoS) Enhancements", IEEE 802.11e Draft 10.0, October 2004.

[IEEE80211F]
          Institute 30
   seconds or greater giving worse performance than TCP-Reno.  The
   affect of Electrical resetting the congestion window and Electronics Engineers, "IEEE
          Trial-Use Recommended Practice for Multi-Vendor Access Point
          Interoperability via RTO values was also
   investigated.  In the study, resetting congestion window to one did
   not have much of an Inter-Access Point Protocol Across
          Distribution Systems Supporting IEEE 802.11 Operation", IEEE
          802.11F, June 2003.

[IEEE80211i]
          Institute effect on throughput, since the bandwidth/delay
   of Electrical and Electronics Engineers, "Supplement the network was only a few packets.  However, resetting the RTO 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, November 2004.

[Kim]     Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger
          method for improving
   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 between sending the
   first packet in the congestion window, or retransmitting the packet
   with the lowest sequence number among those signalled as lost via the
   ELFNs.

   In "Improving TCP performance Performance over Mobile IPv6", draft-
          kim-tsvwg-butrigger-00.txt, Internet draft (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.

[MIPEAP]  Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. and M.
          Laurent-Maknavicius, "MIPv6 Authorization and Configuration
          based Wireless Links" [Goel], the
   authors propose use of an ICMP-DEFER message, sent by a wireless base
   station on EAP", draft-giaretta-mip6-authorization-eap-02.txt,
          Internet draft (work in progress), October 2004.

[Mishra]  Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis failure of
          the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395,
          University a transmission attempt.  After exhaustion of Maryland Department
   retransmission attempts, an ICMP-RETRANSMIT message is sent.  On
   receipt of Computer Science,
          September 2002.

[PEAP]    Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and S.
          Josefsson, "Protected EAP Protocol (PEAP) Version 2", draft-
          josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in
          progress), October 2004.

[Park]    Park, S., Njedjou, E. and N. Montavont, "L2 Triggers Optimized
          Mobile IPv6 Vertical Handover: The 802.11/GPRS Example",
          draft-daniel-mip6-optimized-vertical-handover-00.txt, July
          2004.

[Shortest]
          Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers
          and Robert Morris, "Performance an ICMP-DEFER message, the expiry of Multihop Wireless Networks:
          Shortest Path the retransmission
   timer is Not Enough", Proceedings postponed by the current RTO estimate. On receipt of an
   ICMP-RETRANSMIT message, the First
          Workshop on Hot Topics in Networking (HotNets-I), Princeton,
          New Jersey, October 2002.

[TRIGTRAN]
          Dawkins, S., Williams, C. and A. Yegin, "Framework 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
          Requirements 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 TRIGTRAN", draft-dawkins-trigtran-
          framework-00.txt, Internet draft (work in progress), August
          2003.

[Vatn]    Vatn, J., "An experimental study of IEEE 802.11b handover
          performance Error-Prone
   Wireless and its effect on  voice traffic", TRITA-IMIT-
          TSLAB R 03:01, KTH Royal Institute Satellite Networks" [Krishan], the authors examine the
   use of Technology, Stockholm,
          Sweden, July 2003.

[Yegin]   Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
          l2-triggers-00.txt, Internet Draft (work 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 progress), June
          2002.

[Velayos] Velayos, H. ns-2,
   using both TCP Reno and G. Karlsson, "Techniques 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 Reduce IEEE
          802.11b MAC
   obtain reliable information from the headers of corrupt packets.

A.4 Application Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH
          Royal Institute

   At the Application layer, the usage of Technology, Stockholm, Sweden, April 2003.

[Vertical]
          Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient Mobility
          Management for Vertical Handoff between WWAN "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 SIMPLE [RFC3428] or 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 WLAN", IEEE
          Communications Magazine, November 2003.

[Villamizar]
          Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", draft-
          ietf-ospf-omp-02.txt, Internet draft (work in progress),
          February 1999. 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 A. B - IAB Members at the time of this writing

   Bernard Aboba
   Rob Austein
   Loa Andersson
   Leslie Daigle
   Patrik Falstrom
   Sally Floyd
   Mark Handley
   Bob Hinden
   Geoff Huston
   Jun-Ichiro Itojun Hagino
   Kurtis Lindqvist
   David Meyer
   Pekka Nikander
   Eric Rescorla
   Pete Resnick
   Jonathan Rosenberg
   Lixia Zhang

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director. at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   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 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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.