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

             Architectural Implications of Link Layer Indications

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 April July 22, 2005.

Copyright Notice

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

Abstract
   As a performance optimization, proposals have been made for utilizing

   This document provides an overview of the role of link layer indications (also known as "triggers" or "hints") to
   influence
   within the behavior of Internet Architecture.  While the Internet, Transport or Application
   layers. judicious use of link
   indications can provide performance benefits, experience has also
   shown that that inapropriate use can degrade both robustness and
   performance.  This document briefly summarizes current proposals and proposals, describes
   the architectural issues relating to 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 ..........................................    6    8
      1.5 Layering Model .....................................    7
      1.6 Link Behavior ...................................... ...........................................   10
      1.7 Implementation Differences .........................   11
2.  Architectural considerations .............................   12   14
      2.1 Model Validation ...................................   13   14
      2.2 Robustness .........................................   15   17
      2.3 Effectiveness ......................................   18   20
      2.4 Interoperability Issues ............................   19   21
      2.5 Race Conditions ....................................   19   22
      2.6 Layer Compression ..................................   23
      2.7 Remoting Implications ..............................   24
      2.8 Security Considerations ............................
      2.7 Transport of Link Indications ......................   25
3.  Future Work ..............................................   26   27
4.  Security Considerations ..................................   28
5.  References ...............................................   27
      4.1 Normative References ...............................   27
      4.2   28
      5.1 Informative References .............................   27   28
Appendix A - IAB Members .....................................   31   32
Intellectual Property Statement ..............................   31   33
Disclaimer of Validity .......................................   31   33
Copyright Statement ..........................................   32   33

1.  Introduction

   As evidence mounts that correct utilization of a performance optimization, proposals have been made for utilizing
   link layer indications
   can provide real benefits, and that incorrect utilization can degrade
   performance, (also known as "triggers" or "hints") to influence
   the importance behavior of the Internet, Transport or Application layers.

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

   This document is an attempt to summarize summarizes the current understanding of the role of
   link layer indications, as well as to provide and provides advice to document authors considering
   the role of link layer indications within their own work.

   In Section 1 of this document we present a brief overview of current
   proposals, research
   on link behavior as well as recent research on proposals for utilization of link behavior.  Based on the
   overview,
   indications.  Section 2 provides advice to document authors.  Section
   3 describes recommendations and future work.

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.

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 or "client" is an Internet host using DHCP [RFC2131] 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.

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)
   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 medium over which nodes can communicate
   at the link layer, such as an Ethernet (simple or bridged).  The link
   layer is the layer immediately below IP.

Link Indication indication
   Information provided by the link layer to higher layers relating to
   the state of the link.

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

Point of Attachment
   A location within the network where a host may be connected.  This
   attachment point can be characterized by its address prefix and next
   hop routing information.

Most Likely Point of Attachment (MLPA)
   The point of attachment heuristically determined by the host to be
   most likely, based on hints from the network.

Routable address
   In this specification, the term "routable address" refers to any
   address other than an IPv4 Link-Local address. address [RFC3927].  This
   includes private addresses as specified in [RFC1918].

Station (STA)
   Any device that contains an IEEE 802.11 conformant medium access
   control (MAC) and physical layer (PHY) interface to the wireless
   medium (WM).

Valid address
   The term "valid address" refers to either a static IPv4 address, or
     an address a
   dynamically assigned via DHCPv4 address which has not been relinquished, and
     whose lease has
   not yet expired.

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

1.3.  Link Indications

   A link indication represents information provided by the link layer
   to higher layers relating to the state of the link.  While link layer
   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",
   "Link Quality Crosses Threshold", "Trigger Rollback", and "Better
   Signal Quality AP Available".  Other link indications 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).

   Among the most commonly implemented link indications are the

   "Link Up" and "Link Down" indications, which are based on indications were first developed for wired
   networks, and assume an idealized link behavior model originally developed for wired networks. model.  This model
   assumes that links in the "Up" "up" state experience low frame loss in
   both directions and are ready to send and receive IP data packets.
   Similarly, frames.
   Similarly it is assumed that a link that is links in the "Down" "down" state is are unsuitable
   for sending and receiving IP data packets frames in either direction.

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

1.4.  Proposals

   Within the Internet Layer, proposals have been made for utilizing

   A number of link layer indications to optimize IP configuration, to improve performance studies shed light on the
   usefulness of routing metrics, and to optimize aspects applicability
   of Mobile IP
   handoff.

   In "Detection these assumptions.  For the purposes of Network Attachment (DNA) in IPv4" [DNAv4], link
   layer indications are utilized to optimize Internet layer
   configuration.  This enables a host that has moved illustration, we will
   focus on literature relating to a new point IEEE 802.11.

   In "Measurement and Analysis of
   attachment but remained within the same subnet to rapidly confirm a
   currently valid configuration, rather than utilizing the DHCP
   protocol [RFC2131].

   "A High-Throughput Path Metric for Multi-Hop Error Characteristics of an In-
   Building Wireless Routing" [ETX]
   describes how routing metrics can be improved by utilizing Network" [Eckhardt], the
   Expected Transmission Count (ETX) metric, which takes link layer loss
   rates into account, enabling authors characterize the selection
   performance of routes maximizing
   available throughput.  While the ETX metric did not take an AT&T Wavelan 2 Mbps in-building WLAN operating in
   Infrastructure mode on the
   negotiated rate into account, Carnegie-Mellon Campus.  In this study,
   very low frame loss was noted as experienced.  As a subject for further
   study. result, links could either
   be assumed to operate very well or not at all.

   In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
   802.11/GPRS Example" [Park] "Performance of Multihop Wireless Networks: Shortest Path is Not
   Enough" [Shortest] the authors propose that studied 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 performance of both an
   indoor and outdoor mesh network.  By measuring inter-node throughput,
   the Care-Of-Address (CoA) on receipt best path between nodes was computed.  The throughput of a
   "Link Down" indication.

   Within the Transport Layer, proposals have focused on countering best
   path was compared with the
   effects throughput of handoff-induced packet loss.  This includes proposals for
   improving transport parameter estimation, as well as triggering
   immediate retransmission the shortest path computed
   based on availability 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.

   "Link-layer Triggers Protocol" [Yegin] describes transport issues
   arising from lack of host awareness of link conditions on downstream
   Access Points and routers.  A link-layer trigger remoting is proposed
   to address hop-count metric.  In almost all cases, the issue. shortest path
   route offered considerably lower throughput than the best path.

   In "TCP Extensions for Immediate Retransmissions" [Eggert], it is
   proposed examining link behavior, the authors found that rather than
   exhibiting a bi-modal distribution between "up" (low loss rate) 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 addition to regularly scheduled retransmissions that
   retransmission be attempted by the transport layer loss rates in
   each direction.  As a result, on receipt wireless networks the measured
   throughput can differ substantially from the negotiated rate due to
   retransmissions, and successful delivery of routing packets is not
   necessarily an indication that 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 "The BU-trigger method link is  useful for improving TCP performance over Mobile
   IPv6" [Kim], delivery of
   data.

   "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
   analyzes the authors note that handoff-related packet causes of frame loss is
   interpreted as congestion by the transport layer. in a 38-node urban multi-hop 802.11
   ad-hoc network.  In the case where
   the correspondent node is sending most cases,  links that are very bad in one
   direction tend to the mobile node, it is proposed be bad in both directions, and links that receipt 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 Binding Update by the correspondent node be used as step-function transition
   between "up" (low loss) or "down" (high loss) states,  inter-node
   loss rates varied widely, demonstrating a signal to nearly uniform distribution
   over the transport layer to adjust cwnd and ssthresh values,
   which may have been reduced due to handoff-induced packet loss. range at the lower rates.  The authors recommend that cwnd and ssthresh be recovered to pre-timeout
   values, regardless of whether attribute the link parameters have changed.
   observed effects to multi-path fading, rather than attenuation or
   interference.

   The
   paper does not discuss findings of [Eckhardt] and [Aguayo] demonstrate the behavior diversity of a mobile node sending a
   Binding Update,
   loss conditions observed in the case where the mobile node practice.  There is sending to a fundamental
   difference between indoor infrastructure networks in which site
   surveys and careful measurement can assist in promoting ideal
   behavior and ad-hoc/mesh networks 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
   correspondent node.

   At
   authors conclude that mistaken assumptions relating to link
   performance may lead to the application layer, design of network protocols that may not
   work in practice.  For example, [Kotz] notes that the usage three-
   dimensional nature of wireless propagation can result in large signal
   strength changes over short distances, generating short-lived "Link
   Down" and "Link Up" 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 that are not be
   detected until the presence status times out, which can take many
   minutes.  However, if predicted by a two
   dimensional radio propagation model.

   The literature also describes variations in link goes down, and a disconnect indication
   can be sent behavior
   between implementations.

   "Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos]
   measured handover times for a stationary STA after the presence server (presumably by AP was turned
   off.  This study divided handover times into detection (determination
   of disconnection from the access point,
   which remains connected), 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 status duration of the user's communication
   application can be updated nearly instantaneously.

1.5.  Layering Model

   A simplified layered indication model is shown in Figure 1.  This
   model includes both internally generated link indications as well as
   Internet and Transport layer indications arising out of external
   interactions (such as receipt of Mobile IP Binding Updates, and detection phase (the
   largest component of path changes via routing protocols and TTL changes).

   In this model, link indications provided to higher layers include the
   frame loss rate (before retransmissions), handoff delay) is determined by the current link rate, number of
   non-acknowledged frames triggering the
   link state (up/down), search phase and link identifiers.  These link indications
   are inter-dependent. 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 rate adjustment and detection
   algorithms are typically influenced by frame loss, and AP was always in turn, range, regardless of whether
   the Beacon was received.

   The study recommends that the
   determination duration of a "Link Down" indication may the detection phase be influenced
   reduced by initiating the
   detection and search process.  Link Identifiers are typically
   obtained in phase as soon as collisions can be
   excluded as the process cause of bringing non-acknowledged transmissions; the link to authors
   recommend three consecutive transmission failures as the "Up" state.

   Link indications may be utilized by cutoff.
   Where the Internet layer STA is not sending or receiving frames, it is recommended
   that Beacon reception be tracked in order to
   optimize aspects of IP configuration, routing and mobility.  As noted
   in [DNAv4], "Link Up" indications detect disconnection,
   and link Identifiers may that Beacon spacing be useful reduced to 60 ms in validation of an existing IP configuration.  Once order to reduce
   detection times.  In order to compensate for more frequent triggering
   of the IP
   configuration is confirmed, it may be determined that an IP address
   change has occurred.

   As described in [ETX], search phase, the frame loss rate authors recommend algorithms for wait time
   reduction, as well as the current
   link rate may be utilized in the calculation interleaving of search and data frame
   transmission.

   "An Empirical Analysis of routing metrics.
   Within "Weak End-System Model" implementations, changes in routing
   metrics may in turn result in a change in the outgoing interface for 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 or more transport connections.  Routes may also be added or
   withdrawn, resulting STA sends a Reassociation Request prior
   to authentication, which results in loss or gain of peer connectivity.  The
   Internet layer may also become aware receipt of path changes, by other
   mechanisms such as a change in Deauthenticate
   message.  The study divided handoff latency into discovery,
   authentication and reassociation exchanges, concluding that the IP TTL
   discovery phase was the dominant component of received packets.

   A change handoff delay.  Latency
   in the outgoing interface may in turn influence detection phase was not investigated.

   "Roaming Interval Measurements" [Alimian] presents data on stationary
   STAs after the mobility
   sub-layer if present, causing a change AP signal has been shut off.  This study highlighted
   implementation differences in the incoming interface.
   The mobility sub-layer may also become aware rate adaptation as well as detection,
   scanning and handoff.  As in [Velayos], performance varied widely
   between implementations, from  half an order of a change magnitude variation
   in the
   incoming interface rate adaptation to an order of a peer (via receipt magnitude difference in detection
   times, two orders of magnitude in scanning, and one and a Mobile IP binding
   update).

   Internet layer indications such as IP address half orders
   of magnitude in handoff times.

   "An experimental study of IEEE 802.11b  handoff performance and path changes are
   provided to its
   effect on voice traffic" [Vatn] describes handover behavior observed
   when the Transport layer, signal from AP is gradually attenuated, which also receives Link layer
   indications such as the loss rate, and "Link Up"/"Link Down".

   Based on these Internet layer indications, is more
   representative of field experience than the transport layer may
   wish shutoff techniques used
   in [Velayos].  Stations were configured to modify transport parameter estimates (such as by reseting
   parameter estimates of connections undergoing initiate handover when
   signal strength dipped below a path change), or tear
   down transport connections (due threshold, rather than purely based on
   frame loss, so that they could begin handover while still connected
   to invalidation of a connection's
   originating IP address).  It is also possible for the transport layer current AP.  It was noted that stations continue to utilize "Link Up"/"Link Down" indications, receive
   data frames during the search phase.  Station-initiated
   Disassociation and Loss Rate
   information pre-authentication were not observed in this
   study.

1.4.  Proposals

   Within the Internet layer, proposals have been made for utilizing
   link indications to optimize IP configuration, to improve transport parameter estimates.  However, the
   required algorithms not well understood.

              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application   |                                               |
Layer         |                                               |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        ^         ^   ^
                                        |         |   |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                         | |       |   |       |
              |                         | +       |   |       |
              |                         ^ |       ^   ^       |
Transport     |  Transport Parameter    | +       | Teardown  |
Layer         |  Estimation             | |       |           |
              |  (e.g. RTT, RTO, Reset) | + Conxn.| Management|
              |                         | |       |           |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ^   ^           ^       ^         ^
                |   |           |       |         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              | |   | Incoming  | MIP   |         |           |
              | |   | Interface | BU    |         |           |
              | |   | Change    |Receipt|         |           |
              | ^   ^           ^       ^         ^           |
              | |   |           |       |         |           |
              | |   |           |       |         |           |
              | |   | Mobility  |       |         |           |
Internet      | |   |           |       |         |           |
Layer         +-+- -+- - - - - -+- -+- -+- - - - -+- - - - - -+
              | |   | Outgoing  |   |   |         |
   usefulness of routing metrics, and to optimize aspects of Mobile IP        |
              | |   | Interface |   +   |         | Address   |
              | ^   ^ Change    ^   |   ^         ^ Change    |
              | |
   handoff.

   In "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link
   indications are utilized to optimize Internet layer configuration.
   This enables a host that has moved to a new point of attachment but
   remained within the same subnet to rapidly confirm a currently valid
   configuration, rather than utilizing the DHCP protocol [RFC2131].

   "A High-Throughput Path +   |                     |
              | |            Change |   |                     |
              | |    Routing        +   |  IP Configuration   |
              | |                   |   |                     |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ^         ^             ^       ^
                |         |             |       |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              | |         |             |       |             |
Link          | ^         ^             ^       ^             |
Layer         + Frame ->  Rate      -> Link    Link           +
              | Loss     Adjustment   Up/Down  Identifiers    |
              | Rate                                          |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1.  Layered Indication Model 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.

   Within the Transport layer, proposals have focused on countering the
   effects of handoff-induced packet loss.  This includes proposals for
   improving transport parameter estimation, as well as triggering
   immediate retransmission on availability 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
   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 Internet 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 propagated include "Link Up",
   confirmation of first-hop router reachability, confirmation of
   Internet layer configuration, and receipt of other traffic from the
   peer.

   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.

   At the Application layer (such as IP address changes), layer, the Transport usage of "Link Down" indications has
   been proposed to augment presence systems.  In such systems, client
   devices periodically refresh their presence state using application
   layer
   propagates its own indications, protocols such as connection teardown.  In most
   cases applications can obtain SIMPLE [RFC3428] or XMPP [RFC3921].  If the information they need from Internet
   and Transport layer indications so that they do
   client should become disconnected, their unavailability will not need to directly
   consume be
   detected until the presence status times out, which can take many
   minutes.  However, if a link indications.

1.6.  Link Behavior

   In order goes down, and a disconnect indication
   can be sent to understand the applicability presence server (presumably by the access point,
   which remains connected), the status of the user's communication
   application can be updated nearly instantaneously.

1.5.  Layering

   A layered indication model it is instructive to review recent research relating to shown in Figure 1 which includes both
   internally generated link
   performance.

   In "Measurement indications and Analysis of the Error Characteristics indications arising from
   external interactions (such as receipt of an In-
   Building Wireless Network" [Eckhardt], the authors characterize the
   performance Mobile IP Binding Updates,
   and detection of an AT&T Wavelan 2 Mbps in-building WLAN operating in
   Infrastructure mode on the Carnegie-Mellon Campus. path changes via routing protocols and TTL changes).

   In this study,
   very low model, link indications include frame loss was experienced.  As (before
   retransmissions), the current link rate, the link state (up/down),
   and link identifiers.  The indications are inter-dependent, since
   rate adjustment and detection algorithms are typically influenced by
   frame loss, and in turn a result, links could either "Link Down" indication may be assumed to operate very well or not at all.

   In "Performance of Multihop Wireless Networks: Shortest Path is Not
   Enough" [Shortest] influenced by
   the authors studied detection and search process.  Link Identifiers are typically
   obtained in the performance process of both an
   indoor and outdoor mesh network.  By measuring inter-node throughput, bringing the best path between nodes was computed. link up.

   The throughput of Internet layer is the best
   path was compared with primary consumer of link indications, since
   one of its functions is to shield applications from the throughput specifics of
   link behavior.  The Internet layer may utilize link indications to
   optimize aspects of IP configuration, routing and mobility.  As noted
   in [DNAv4], "Link Up" indications and link identifiers may be useful
   in validating the shortest path computed
   based on a hop-count metric.  In almost all cases, IP configuration.  Once the shortest path
   route offered considerably lower throughput than IP configuration is
   confirmed, it may be determined that an address change has occurred.

   As described in [ETX], the best path.

   In examining frame loss rate as well as the current
   link behavior, rate may be utilized in the authors found that rather than
   exhibiting calculation of routing metrics.
   Within "Weak End-System Model" implementations, changes in routing
   metrics may in turn result in a bi-modal distribution between "up" (low loss rate) and
   "down" (high loss rates), many links exhibited intermediate change in the outgoing interface for
   one or more transport connections.  Routes may also be added or
   withdrawn, resulting in loss
   rates.  Asymmetry was or gain of peer connectivity.  The
   Internet layer may also common, with 30 percent become aware of path changes by other
   mechanisms, such as by running a routing protocol, receipt of links
   demonstrating substantial differences between a
   Router Advertisement or a change in the loss rates IP TTL of received packets.

   A change in
   each direction.  As a result, on wireless networks the measured
   throughput can differ substantially from outgoing interface may in turn influence the negotiated rate due to
   retransmissions, and successful delivery of routing packets is not
   necessarily an indication that mobility
   sub-layer, causing a change in the link is  useful for delivery incoming interface.  The mobility
   sub-layer may also become aware of
   data.

   "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
   analyzes a change in the causes incoming interface
   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 peer (via receipt of links exhibited loss rates differing substantially a Mobile IP binding update).

   However, "Link Up" indications need not result in
   each direction.

   Signal a change to noise ratio
   Internet layer configuration, and distance showed little value changes in predicting
   loss rates, and rather than exhibiting a step-function transition
   between "up" (low loss) link rate or "down" (high loss) states,  inter-node frame loss rates varied widely, demonstrating
   need not result in a nearly uniform distribution
   over the range at change of outgoing interface.  By filtering
   "Link Up" indications, and selecting outgoing and incoming interfaces
   based on the lower rates.  The authors attribute link rate and frame loss, the
   observed effects Internet layer enables
   upper layers to multi-path fading, rather than attenuation or
   interference. avoid writing their own code to filter and validate
   link indications.

   The findings Transport layer processes Internet layer and link indications
   differently for the purposes of [Eckhardt] transport parameter estimation and [Aguayo] demonstrate
   connection management.  For the diversity purposes of
   loss conditions observed parameter estimation, the
   Transport layer may be interested in practice.  There is a fundamental
   difference between infrastructure networks in which site surveys and
   careful measurement can assist in promoting ideal behavior wide range of Internet and ad-
   hoc/mesh networks
   link layer indications.  The Transport layer may wish to use path
   change indications from the Internet layer in which node mobility and external factors order to rest parameter
   estimates.  It may also be useful for the Transport layer to consume
   link layer indications such as
   weather link rate, frame loss rate and "Link
   Up"/"Link Down" in order to improve transport parameter estimates.

   However at this point, the algorithms for improving transport
   parameter estimates using link layer indications are not well
   understood.  For example, in transport parameter estimation, layering
   considerations may not be easily controlled.

1.7.  Implementation Differences

   The literature also describes exist to the effect of implementation
   differences on link indications. same extent as in connection
   management.  For example, the Internet layer may receive a "Link
   Down" indication followed by a subsequent "Link Up" indication.  This
   information may useful for transport parameter estimation even if IP
   configuration does not change, since it may indicate that packet loss
   is not caused by congestion.

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

                      Figure 1.  Layered Indication Model
   For the purposes of illustration,
   we will restrict ourself to literature relating to IEEE 802.11
   implementations.

   "An Empirical Analysis of connection management, 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 Transport layer
   typically only utilizes Internet layer indications such as changes in handoff latency among STA and AP
   implementations
   the incoming/outgoing interface and that implementations utilize different message
   sequences. IP configuration changes.  For
   example, one STA sends a Reassociation Request prior the Transport layer may tear down transport connections due
   to authentication, which results in receipt invalidation of a Deauthenticate
   message.  The study divided handoff latency into discovery,
   authentication and reassociation exchanges, concluding that the
   discovery phase was connection endpoint IP address.

   However, even where an Internet layer configuration change has
   occurred, the dominant component of handoff delay.
   Detection was configuration change may not investigated.

   "Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos]
   measured handover times be relevant for a stationary STA after the AP was turned
   off.  This study divided handover times into detection (determination
   purposes of connection management.  For example, where the need for handover), search (discovery of alternative
   attachment points), and execution phases (authentication and
   association exchanges).  These measurements indicated that connection
   has been established based on the
   detection phase was longest home address, a change in duration.  The duration of the
   detection phase care-
   of-address need not result in connection teardown, since the
   configuration change is determined masked by the number of non-acknowledged
   frames triggering mobility functionality within
   the search phase and precursors such as RTS/CTS Internet layer, and
   rate adaptation.

   Detection behavior varied widely between implementations.  For
   example, NICs designed for desktops attempted more retransmissions
   prior is therefore transparent to triggering search as compared with laptop designs, since
   they assumed that the AP is always Transport
   layer.

   Since a "Link Up" indication may or may not result in range, regardless of Beacon
   reception.

   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 a change in
   Internet layer configuration, the cause Transport layer cannot draw
   conclusions about the implications of non-acknowledged transmissions; "Link Up" for connection
   management until the authors
   recommend three consecutive transmission failures as Internet layer has determined whether a
   configuration change has occurred.

   Similarly, the cutoff. Transport layer does not tear down connections on
   receipt of a "Link Down" indication, regardless of the cause.  Where
   the STA is not sending,  it is recommended that Beacon
   reception be tracked if no data frames are being received, and that
   Beacon spacing "Link Down" indication results from frame loss rather than an
   explicit exchange, the indication may be reduced to 60 ms in order to reduce detection
   times.  In order transient, to compensate for more frequent triggering of the
   search phase, be soon
   followed by a "Link Up" indication.

   Even where the authors recommend algorithms for wait time
   reduction, as well "Link Down" indication results from an explicit
   exchange such as interleaving receipt of search with data transmission.

   "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 a PPP LCP-Terminate or an order variation in rate
   adaptation to 802.11
   Disassociate or Deauthenticate frame, an order alternative point of magnitude difference in
   attachment may be available, allowing connectivity
   detection times, two orders of magnitude in scanning, and one and to be quickly
   restored.  As a
   half orders of magnitude in handoff times.

   "An experimental study result, robustness is best achieved by allowing
   connections to remain up until an endpoint address changes, or the
   connection is torn down due to lack of IEEE 802.11b  handoff performance response to repeated
   retransmission attempts.

   In addition to Internet layer indications propagated to the
   Application layer (such as IP address configuration and changes), the
   Transport layer provides its
   effect on voice traffic" [Vatn] describes handover behavior observed
   when own indications to the signal from AP is gradually attenuated, which is more
   representative 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 field experience than times that a link layer
   frame may be retransmitted, so that the shutoff techniques used
   in [Velayos].  Stations were configured link layer does not continue
   to initiate handover when
   signal strength dipped below retransmit after a threshold, rather 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 purely based on
   frame loss, dot11RTSThreshold, respectively.

   In most cases applications can obtain the information they need from
   Internet and Transport layer indications so that they could begin handover while still connected do not need to
   directly consume link indications.  For example, a "Link Up"
   indication typically only implies that the current AP.  It link was noted suitable for
   sending and receiving link layer control frames, not that stations continue to receive
   data frames during the search phase.  Station-initiated
   Disassociation it has been
   configured for and pre-authentication were is capable of reliably sending and receiving IP
   data packets.  As a result, applications will typically consume an
   Internet layer "IP Address Configured" event instead of a "Link Up"
   indication.  Similarly, it is typically not observed useful for applications
   to consume "Link Down" indications, since these indications can be
   transient in this
   study. nature.  Instead, applications should consume Transport
   layer teardown indications.

2.  Architectural considerations

   While the literature on the usage of link layer Link indications provides
   persuasive evidence of their utility,  experience shows that a number
   of difficulties can arise in making effective use of them.  These
   issues include:

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

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

2.1.  Model Validation

   In "The mistaken axioms of wireless-network research" [Kotz], the
   authors conclude that mistaken assumptions relating

   Authors need to link
   performance may lead be careful to  the design avoid use of network protocols that may not
   work simplified link models in practice.
   circumstances where they do not apply.  In order to avoid these pitfalls, the
   pitfalls described in [Kotz], documents dependent on link indications
   should explicitly articulate the assumptions of the link model and
   describe the circumstances in which it applies.

   Authors need to be careful to avoid use of simplified network models
   in circumstances where the model does not apply.

   For example, generic "trigger" models assume often include implicit
   assumptions.  The use of "Link Up" and "Link Down" indications
   implies that a link is either in a state experiencing low frame loss ("Link Up")
   ("up") or in a state where few if
   any frames are successfully delivered ("Link Down").  Often symmetry is assumed as
   well,
   ("down").  Symmetry may also be assumed, so that a the link is assumed to be either "Up"
   "up" in both directions or "Down" "down" in both directions.

   Link indications based on signal quality, such as "Link Doing Down",
   "Link Going Up", and "Link Quality Crosses Threshold" typically
   assume the absence of multi-path interference, so that signal to
   noise ratio varies smoothly in space, and frame loss is well
   predicted by signal strength and distance.

   In wireless networks, particularly in
   the case of ad-hoc outdoor or mesh deployments, these
   the assumptions underlying generic trigger models may prove invalid.

   Furthermore, where

   Where links are may exist in intermediate states between "Up" and
   "Down" "up" and "down"
   or asymmetry is encountered, generic "triggers" such as "Link Going
   Down", "Link Going Up", and "Link Quality Crosses Threshold" may
   prove be
   difficult to reliably define and may prove to be unreliable predictors of
   future link performance.

   Once the network model is defined, considerable effort may be
   required to map define the link indications model to common for a given link types.  In practice layer.
   For example, the definition of "Link Up" or "Link Down" may vary according to the varies
   considerably between link
   layer.  For example, within layers.  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.

   Within

   Unlike PPP, IEEE 802 does not include facilities for network layer
   configuration, and the definition of "Link Up" and "Link Down" varies
   between and even within Link types.  For example, in IEEE 802.11, the
   definition of "Link Up" and "Link Down" depends on whether the
   station is mobile or stationary, whether infrastructure or ad-hoc
   mode is in use, and whether security and Inter-Access Point Protocol
   (IAPP) is implemented.

   Where a 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. 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
   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 "De-
   authenticate"
   "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 or Reassociation
   response.

   Within the [IEEE80211f] specification, 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
   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 DS distribution
   system until it sent sends its first frame at the new location.  Thus IAPP serves 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 signalling 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 [IEEE80211i] 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.

   Unfortunately, other elements of the IEEE 802.11 specification such
   as IEEE 802.11f continue to recognize the Reassociation Response as
   the "Link Up" definition.  By spoofing a multicast frame with the
   station's source address once it sends a Reassociation Response,
   Access Points implementing IEEE 802.11f cause the learning tables
   within switches comprising the DS to be updated.  This enables an
   attacker to deny service to attached stations by sending a
   Reassociation Request from anywhere within the ESS.  Without the
   spoofing recommended in IEEE 802.11f, such an attack would only be
   able to disassociate stations on the AP to which the Reassociation
   Request was sent.

   [IEEE80211i] implementations utilizing the 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" definition from
   [IEEE80211] or [IEEE80211f] have also encountered difficulty in IP
   address assignment, since they may trigger 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.  As a result,
   Internet layer configuration may fail.

   In contrast, layer, resulting in 802.11 ad-hoc mode with no security, reception of
   data frames is enabled configuration delays or failures.
   Similarly, Transport layer connections will encounter packet loss,
   resulting in State 1 ("Unauthenticated" and "Un-
   associated").  As a result, reception back-off of data frames is enabled at
   any time, and no explicit "Link Up" indication exists. retransmission timers.

2.2.  Robustness

   Implementation experience provides us with several examples of
   situations in which

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

        a.  Indication validation
        b.  Recovery from invalid indications
        c.  Damping and hysterisis hysteresis

2.2.1.  Indication Validation

   As noted in Section 1.6 and 1.7, radio

   Radio propagation and implementation differences can impact the
   reliability of link layer Link indications.
   [Kotz] notes that the three-dimensional nature of wireless
   propagation can result in large signal strength changes over short
   distances, generating short-lived "Link Down" and "Link Up"
   indications that are not be predicted by a two dimensional radio
   propagation model.

   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.  In these circumstances, a "Link
   Up" indication may not imply bi-directional reachability.  Also,  a
   reachability demonstration based on small packets may not mean that
   the link is suitable for carrying larger data packets.  As a result,
   "Link Up" and "Link Down" "Link Down" indications may not reliably determine
   whether a link is suitable for carrying IP data packets.

   Where multi-path interference or hidden nodes are encountered, frame
   loss may vary widely over a short distance.  While techniques such as
   use of 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, a mobile
   host may find itself experiencing widely varying link conditions,
   causing the link to rapidly cycle between "up" and "down" states,
   with "Going down" or "Going up" indications may not reliably determine
   whether a link is suitable for carrying IP traffic. providing little
   predictive value.

   Where the reliability of a link layer indication is suspect, it is
   best for upper layers to treat the indication as a "hint" that is advisory (advisory
   in nature, nature), rather than a "trigger" forcing a given action.  In order
   to provide increased robustness, heuristics can be developed to determine
   assist upper layers in determining whether the "hint" is valid or
   should be discarded.

   In addition, a recovery step may be utilized in order to limit the
   potential damage from link indications determined to be invalid after
   they have been acted on.

   To provide robustness in the face of potentially misleading link
   indications, in [DNAv4] "Link Up" indications are assumed to be
   inherently unreliable, so that bi-directional reachability needs to
   be demonstrated prior to in the process  of validating an existing IP
   configuration.  However, in the case of where a link of exhibits an intermediate loss
   rate, the success
   with of the [DNAv4] reachability test does not guarantee
   that the link is suitable for carrying data. IP data packets.

   Another example of link indication validation occurs occurs occurs occurs in IPv4
   Link-Local address configuration [RFC3927].  Prior to configuration
   of an IPv4 Link-Local address, it is necessary to run a claim and
   defend protocol.  Since a host needs to be present to defend its
   address against another claimant, and address conflicts are
   relatively likely, a host returning from sleep mode or receiving a
   "Link Up" indication could encounter an address conflict were it to
   utilize 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 to be invalid after
   they have been acted on.

   Recovery is supported within [DNAv4] in the case where link
   indications may  lead a host to erroneously conclude that the link
   prefix remains unchanged when the host has in fact changed subnets.
   In this case, the bi-directional reachability test times out, and the
   host will eventually realize its mistake and obtain an IP address by
   normal means.

   Where a proposal involves recovery at the 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 [RFC3927], early IPv4 Link-Local address configuration.  Prior
   implementations would wait five minutes before attempting to configuration of obtain a
   routable address after assigning an IPv4 Link-Local address, address.  In one
   implementation, it is necessary to run a claim and defend
   protocol [RFC3927].  Since a host needs to be present to defend its
   address against another claimant, and address conflicts are
   relatively likely, a host returning from sleep mode or receiving 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 (signalling of
   "Link Up" indication could encounter prior to completion of link layer authentication),
   resulting in an address conflict were it initial failure to
   utilize obtain a formerly configured Link-Local Link-Local routable address without
   rerunning claim and defend.

2.2.2. using
   DHCP.  As a result, [RFC3927] recommends against modification of the
   maximum retransmission timeout (64 seconds) provided in [RFC2131].

2.2.3.  Damping and Hysterisis Hysteresis

   Damping and hysterisis 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 introduce damping mechanisms to
   prevent instability.

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

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

   However, the benefits of damping need to be weighed against the
   additional latency that can be introduced.  For example, in order to
   filter out spurious "Link Down" indications, these indications may be
   delayed until it can be determined that a "Link Up" indication will
   not follow shortly thereafter.  However, in situations where multiple
   Beacons are missed such a delay may not be needed, since there is no
   evidence of a suitable point of attachment in the vicinity.

   In some cases, it may be desirable to ignore link indications
   entirely.  Since it is possible for a host to transition from an ad-
   hoc network to a network with centralized address management, a host
   receiving a "Link Up" indication cannot necessarily conclude that it
   is appropriate to configure a IPv4 Link-Local address at all.

   It can be argued that reliable transport protocol implementations
   should ignore "Link Down" indications, rather than tearing down
   connections, regardless of the cause of the "Link Down" indication.

   Where the "Link Down" indication results from frame loss rather than
   an explicit exchange, the indication may be transient, rapidly
   followed by a "Link Up" indication.  Even where the "Link Down"
   indication results from an explicit exchange such as a PPP LCP-
   Terminate or an 802.11 Disassociation or Deauthenticate, an
   alternative point of attachment may be available, allowing
   connectivity prior to be quickly restored.  As
   determining whether a result, robustness is best
   served by allowing connections to remain up until the connection
   source address DHCP server is invalidated by an address change, or available [RFC3927].

   As noted in Section 1.5, the Transport layer does not utilize "Link
   Up" and "Link Down" indications for the purposes of connection
   times out.
   management.  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 link indications.

   Where link indications are used to optimize transport performance,
   authors must demonstrate that effective congestion control is
   maintained [RFC2914] in the face of rapidly changing link
   indications.

   In addition, where a proposal involves "recovery" from a handoff
   event, it is important to demonstrate that the recovered parameters
   (such as the adjusted RTT, RTO, congestion window, etc.) remain
   valid, as noted in [RFC2861].

   Consider a proposal where a "Link Up" indication is used by a router
   to signal trigger retransmission a of the last previously sent packet, in
   order to enable ACK reception prior to expiration of the host's
   retransmission timer.  Where "Link Up" indications follow in rapid
   succession,  this could result in a burst of retransmitted packets,
   violating the law principle of
   conservation "conservation of packets. packets".

   At the Application Layer, link layer Link indications have been utilized by
   applications such as Presence [RFC2778] in order to optimize
   registration and user interface update operations.  For example,
   implementations may attempt presence registration on receipt of a
   "Link Up" indication, and presence deregistration de-registration by a surrogate
   receiving a "Link Down" indication.

   Presence implementations using "Link Up"/"Link Down" indications this
   way violate the principle of "conservation of packets" when link
   indications are generated on a time scale of RTO or less.  The
   problem is magnified since for each presence update, notifications
   can be delivered to many watchers.  In addition, use of a "Link Up"
   indication in this manner is unwise since the interface may not yet
   have a valid Internet layer configuration.

   The issue can be addressed by one or more of the following
   techniques:

[a]   Rate limiting.  A limit of one packet per RTO can be imposed on
      packets generated from receipt of link indications.

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

[c]   Keepalives.  Instead of consuming a "Link Down" indication, an
      application can utilize an application keepalive or consume
     transport
      Transport layer indications such as connection teardown.

2.3.  Effectiveness

   While link layer indications may show promise, it may be difficult to prove
   that processing of a given indication provides benefits in a wide
   variety of circumstances.  Where link layer indications are utilized for
   the purpose of optimization, proposals need to carefully analyze the
   effectiveness of the optimizations in the face of unreliable link layer
   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 layer 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 layer
   indication to be highly reliable, as well as for that indication to 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
   layer
   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 subnet a prefix change.  Within IEEE 802.11, the Service Set
   Identifier (SSID) functions as a non-unique identifier of the
   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, or may have changed subnets.  Similarly, a  host discovering
   that the SSID has changed may have changed subnets, 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.  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.  Interoperability Issues

   Since

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

   To avoid compromising interoperability in the purpose 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
   proposals.

   Where proposal.

   For example, if link layer indications prefix hints are proposed provided as a substitute
   for use in optimizing
   configuration of the Internet layer, it is necessary 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 the proposal does they do not interfere compromise
   robustness by interfering with address assignment or routing protocol
   behavior,
   make making address collisions more likely, or compromise compromising
   Duplicate Address Detection (DAD).

2.5.  Race Conditions

   It is possible for link layer 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 layer 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 layer indications are first processed by
   the Internet Protocol layer (e.g. MIPv6) before being consumed by the
   Transport Layer,  in some situations layer,  for the purposes of parameter estimation, it may be
   desirable for the Transport Layer layer to consume link layer 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 layer is modifying transport parameters based on
   other link layer indications.  As a result, transport behavior may differ
   depending on the order in which the  link indications are processed.

   Whee

   Where a multi-homed host experiences high increasing frame loss on one of
   its interfaces,  the ETX  a routing metric computed for that interface 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.  At the same time,  As a result,
   the Transport
   Layer may be estimating transport parameters based on for the former
   outgoing interface, and original interface (MTU, congestion
   state) may not properly adjust no longer be valid for the changes in 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.  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 to their initial values and allow them to be re-
   estimated.  This ensures that estimates based on the former path do
   not persist after they have become invalid.

2.5.2.  Layering

   Another technique to avoid race conditions is to rely on layering to
   damp potentially misleading 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 layer indications directly can
   avoid link layer dependencies.

   For example, in order to provide robustness, it is necessary to
   demonstrate that a link providing a "Link Up" indication is likely to
   be usable for the transmission of IP data packets prior to using it.
   While applications can in principle incorporate their own versions of
   such a test, efficiency and maintenance considerations argue for
   providing this facility within the Internet layer.

   Many "Link Up" indications do not result in a change of Internet
   Layer configuration, and many changes in link rate or frame loss do
   not result in a substantial change in the TTL of outgoing interface.  By filtering "Link Up"
   indications, and selecting outgoing
   received IP packets, it may be worth considering whether to reset
   transport parameters to their initial values and incoming interfaces allow them to be re-
   estimated.  This ensures that estimates based on the link rate and frame loss, the Internet Layer enables upper layers former path do
   not persist after they have become invalid.

2.5.2.  Layering

   Another technique to avoid writing their own code race conditions is to filter rely on layering to
   damp transient link indications and validate provide greater link
   indications.

   The transport layer consumes Internet layer indication such as
   changes in the incoming/outgoing interface and
   independence.

   The Internet layer
   configuration changes, is responsible for routing as well as potentially utilizing IP
   configuration, and mobility, providing higher layers with an
   abstraction that is independent of link layer
   indications directly.  For example, the Internet layer may receive a
   "Link Down" indication followed by a subsequent "Link Up" indication.
   This information may be technologies.  Since
   one of interest to the Transport layer even if major objectives of the Internet layer configuration does not change, since it may
   provide information about the validity of the transport parameters
   estimates.

   In general, it is advisable for applications to consume indications
   from the Internet or Transport maintaining link
   layer independence, upper layers relying on Internet layer
   indications rather than consuming link indications directly, since this enables applications to leverage
   layered indication processing, resulting in improved robustness and
   scalability.  For example, instead of directly consuming "Link Down"
   indications, applications may wish to rely on Application layer
   keepalives or the Transport can avoid
   link layer to determine whether connections
   should be torn down;  instead of consuming "Link Up" indications, dependencies.

   As described in Section 1.5, it is advisable for applications can consume IP address change indications. to
   utilize indications from the Internet or Transport layers rather than
   consuming link indications directly.

2.5.3.  Metric Consistency

   Once a link is in the "Up" "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 detection of when to roam determine when to select an
   alternative point of attachment.  While connected,  Also, the effective throughput may be determined based
   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 measures
   of suitability metrics
   are required. required to determine suitability.  As noted in [Shortest], the ability of a
   link to that can successfully transmit the short frames utilized for
   control, management or routing is may not indicative of its usefulness in carrying
   IP necessarily be able to
   reliably transport data packets.  As a result, it is typically not possible to
   predict

   Since the negotiated rate or data and frame loss rate in advance of a
   roaming decision.

   As a result,  802.11 stations evaluating typically cannot be
   predicted prior to utilizing the suitability of candidate
   APs link for data traffic, existing
   implementations often utilize received signal strength and/or AP load as a
   primary selection criteria.  Similarly, in order to enable stations
   to roam prior to encountering packet loss, studies metrics such as [Vatn]
   have suggested using signal strength as a detection mechanism, rather
   than frame loss, as suggested and
   access point load in [Velayos]. 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.  For
   example,  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" 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], link utilization-based routing metrics have
   a history of instability, so that they are rarely deployed.

2.6.  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
   Transport layer retransmission and recovery; security association re-
   establishment;  application protocol reauthentication re-authentication and
   reregistration re-
   registration exchanges, etc.  Given this, it is natural to consider
   combining exchanges occurring within multiple layers into a single
   exchange.

   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 link layer and Internet or Transport layer mechanisms
   are combined, it is necessary for hosts to maintain the ability to
   interoperate without layer compression schemes, in order to permit
   operation on networks where they are not available.

   As noted earlier, while the layered handling of link indications
   introduces latency,  it also increases robustness.  As a result,
   layer

   Layer compression schemes need to take care to avoid introducing
   unnecessary brittleness. 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.  While in theory layer, such a proposal addresses the
   non-uniqueness issues found with the use of as
   within the SSID for movement
   detection, it suffers from its own set of problems.

   For example, 802.11 Beacon and Probe Response frames.  However,
   [IEEE8021X] enables the VLANID to by be assigned
   dynamically.  As a result, a prefix dynamically, so that
   prefix(es) advertised at within the link layer need Beacon and/or Probe Response may not
   correspond to the prefix assigned to prefix(es) configured by the host once it connects to Internet layer after
   the link. host completes link layer authentication.  Were the host to
   handle IP configuration to at the link layer rather than within the
   Internet layer, the host might be based on such hints, errors
   are likely. unable to communicate due to
   assignment of the wrong IP address.

2.7.  Remoting implications  Transport of Link Indications

   Proposals which include support for remoting including the transport of link layer 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.

   On the other hand, proposals

   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 metrics incorporating link layer indications
   such as [ETX] imply that enable hosts participating in the routing mesh may to gain
   knowledge of path changes and remote link
   conditions where link-aware routing metrics are used. conditions.  This can be
   accomplished securely if routing protocol security is implemented.

   For example,  when
   When a link experiences frame loss, the ETX metric will routing metrics incorporating
   frame loss increase, possibly resulting in selection of an alternate
   route.  If the troubled link represents the only path to a prefix and
   the link experiences high frame loss ("Down"), ("down"), the route will be
   withdrawn or the metric will become infinite.  Thus, where link-indication aware
   routing metrics are implemented, "link indication remoting" can be
   accomplished via host participation in  Similarly, when the routing mesh, and
   transport layer response to path changes.
   link becomes operational, the route will appear again.

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

[a]   Absence of alternatives.  By default, alternative solutions alternatives not requiring
      explicit remoting of link layer indications signalling are
     preferred, and the burden of proof rests on remoting advocates preferred.  Where these solutions are
      shown to
     show be inadequate, proposals must prove that alternatives (including link-indication aware existing
      explicit signalling mechanisms (such as path change processing and
      link-aware routing metrics) are unsuitable. inadequate.

[b]   Conservative behavior.  Due to past experience with ICMP "source
      quench", the burden of proof rests on advocates of remoting proposals to must demonstrate that proposals they do not violate
      conservation of packets.

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

[d]   Identifiers.  When link indications are remoted, 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.  The burden rests on
     remoting advocates to demonstrate how the link indication can be
     mapped to the right higher layer state.  As an example, if a
     presence server is receiving remote indications about "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.

2.8.  Security Considerations

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

   For example, within [IEEE80211f], "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].  As a result, link
   layer indications as implemented in [IEEE80211f] enable an attacker
   to disassociate a station located anywhere within the ESS, simply by
   sending a Reassociation Request frame.

   Another example of the potential security implications of link layer
   indications occurs within DNAv4, where demonstrate how the link indication
      can be mapped to the right higher layer state.

      For example, if a presence server is receiving remote indications are
   used for optimization
      of IP configuration, rather than using "Link Up"/"Link Down" status for a
   secured configuration mechanism such as authenticated DHCP [RFC3118],
   thereby increasing vulnerability particular MAC address, the
      presence server will need to spoofing. associate that MAC address with the
      identity of the user (pres:user@example.com) to whom that link
      status change is relevant.

3.  Further work  Future Work

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

   Given that

   Since recent proposals such as [IEEE80211e] incorporate burst ACKs,
   the relationship between 802.11 link throughput and frame loss is
   growing more complex, which may necessitate the development of
   revised routing metrics, taking the more complex transmission
   behavior as well as the negotiated rate into account.

   At the link 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 [DCCP], a "Reset Congestion State"
   option was proposed in Section 4.  This option was removed in part
   because the use conditions under which it was to be used were not fully understood:

      An HC-Receiver 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 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 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], "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 needed to determine how not capable of
   sending and receiving IP packets on the link layers may utilize
   information from until completion of the transport layer.  For example, it is undesirable
   for
   key exchange protocol defined in [IEEE80211i].  As a result, link layer
   indications as implemented in [IEEE80211F] enable an attacker to retransmit so aggressively that
   disassociate a station located anywhere within the link layer
   round-trip time approaches that ESS, by sending a
   Reassociation Request frame.

   Another example of the end-to-end transport
   connection.

4.  References

4.1.  Normative References

[RFC2119] Bradner, S., "Key words potential security implications of link
   indications occurs within DNAv4, where link indications are used for use in RFCs
   optimization of IP configuration, rather than using a secured
   configuration mechanism such as authenticated DHCP [RFC3118], thereby
   increasing vulnerability to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

4.2. spoofing.

5.  References

5.1.  Informative References

[RFC791]  Postel, J., "Internet Protocol", RFC 791, USC/Information
          Sciences Institute, September 1981.

[RFC792]  Postel, J., "Internet Control Message Protocol", RFC 792,
          USC/Information Sciences Institute, September 1981.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
          1661, July 1994.

[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., J. and H. Sugano, H., "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.

[RFC3748] Aboba, B., , "Extensible Authentication Protocol (EAP)", RFC
          3748, June 2004.

[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
          IPv6", RFC 3775, June 2004.

[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol
          (XMPP): Instant Messaging and Presence", RFC 3921, October
          2004.

[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
          of Link-Local IPv4 Addresses", RFC 3927, October 2004.

[802.11fh]
          McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
          draft-ietf-mipshop-80211fh-01.txt, Internet draft (work in
          progress), July 2004.

[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. and S. Floyd, "Datagram Congestion
          Control Protocol (DCCP)", Internet drafts (work in progress),
          draft-ietf-dccp-spec-07.txt, July
          draft-ietf-dccp-spec-08.txt, October 2004.

[DNAv4]   Aboba, B., "Detection of Network Attachment in IPv4", draft-
          ietf-dhc-dna-ipv4-08.txt,
          ietf-dhc-dna-ipv4-09.txt, Internet draft (work in progress),
          July
          October 2004.

[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-03.txt, draft-tschofenig-eap-ikev2-05.txt, Internet draft
          (work in progress), February 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-00.txt,
          now-01.txt, Internet draft (work in progress), July 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

[IEEE8021X]
          Institute of Electrical and Electronics Engineers, "Local and
          Metropolitan Area Networks: Port-Based Network Access
          Control", IEEE Standard 802.1X, November December 2004.

[IEEE80211]
          Institute of Electrical and Electronics Engineers, "Wireless
          LAN Medium Access Control (MAC) and Physical Layer (PHY)
          Specifications", IEEE Standard 802.11, 2003.

[IEEE80211e]
          Institute of Electrical and Electronics Engineers, "Amendment "Draft
          Amendment 7: Medium Access Control (MAC) Quality of Service
          (QoS) Enhancements", IEEE 802.11e, 802.11e Draft 10.0, October 2003.

[IEEE80211f] 2004.

[IEEE80211F]
          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,
          802.11F, June 2003.

[IEEE80211i]
          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, November 2004.

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

[MIPEAP]  Giaretta, C., Guardini, I., Demaria, E., Bournelle, J., J. and M.
          Laurent-Maknavicius, "MIPv6 Authorization and Configuration
          based on EAP", draft-giaretta-mip6-authorization-eap-01.txt, draft-giaretta-mip6-authorization-eap-02.txt,
          Internet draft (work in progress), July 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.

[PEAP]    Palekar, A., et al, Simon, D., Salowey, J., Zhou, H., Zorn, G. and S.
          Josefsson, "Protected EAP Protocol (PEAP) Version 2",
          draft-josefsson-pppext-eap-tls-eap-09.txt, 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.

[PPPIANA] Schryver, V., "IANA Considerations for the Point to Point
          Protocol (PPP)", draft-schryver-pppext-iana-01.txt, August
          2003.

[Shortest]
          Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers, Chambers
          and Robert Morris, "Performance of Multihop Wireless Networks:
          Shortest Path is Not Enough", Proceedings of the First
          Workshop on Hot Topics in Networking (HotNets-I), Princeton,
          New Jersey, October 2002.

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

Appendix A.  IAB Members at the time of this writing

   Bernard Aboba
   Rob Austein
   Leslie Daigle
   Patrik Falstrom
   Sally Floyd
   Mark Handley
   Bob Hinden
   Geoff Huston
   Jun-Ichiro Itojun Hagino
   Eric Rescorla
   Pete Resnick
   Jonathan Rosenberg

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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 does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

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 (2004). (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.