2.  Architectural Considerations

   The complexity of real-world link behavior poses a challenge to the
   integration of link indications within the Internet architecture.
   While the literature provides persuasive evidence of the utility of
   link indications, difficulties can arise in making effective use of
   them.  To avoid these issues, the following architectural principles
   are suggested and discussed in more detail in the sections that
   follow:

   (1)  Proposals should avoid use of simplified link models in
        circumstances where they do not apply (Section 2.1).

   (2)  Link indications should be clearly defined, so that it is
        understood when they are generated on different link layers
        (Section 2.2).

   (3)  Proposals must demonstrate robustness against spurious link
        indications (Section 2.3).

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

   (5)  Proposals must demonstrate that effective congestion control is
        maintained (Section 2.4).

   (6)  Proposals must demonstrate the effectiveness of proposed
        optimizations (Section 2.5).

   (7)  Link indications should not be required by upper layers, in
        order to maintain link independence (Section 2.6).

   (8)  Proposals should avoid race conditions, which can occur where
        link indications are utilized directly by multiple layers of the
        stack (Section 2.7).

   (9)  Proposals should avoid inconsistencies between link and routing
        layer metrics (Section 2.7.3).

   (10) Overhead reduction schemes must avoid compromising
        interoperability and introducing link layer dependencies into
        the Internet and transport layers (Section 2.8).

   (11) Proposals for transport of link indications beyond the local
        host need to carefully consider the layering, security, and
        transport implications (Section 2.9).

2.1.  Model Validation

   Proposals should avoid the use of link models in circumstances where
   they do not apply.

   In "The mistaken axioms of wireless-network research" [Kotz], the
   authors conclude that mistaken assumptions relating to link behavior
   may lead to the design of network protocols that may not work in
   practice.  For example, the authors note that the three-dimensional
   nature of wireless propagation can result in large signal strength
   changes over short distances.  This can result in rapid changes in
   link indications such as rate, frame loss, and signal strength.

   In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
   the authors provide examples of modeling mistakes and examples of how
   to improve modeling of link characteristics.  To accompany the paper,
   the authors provide simulation scenarios in ns-2.

   In order to avoid the pitfalls described in [Kotz] [GurtovFloyd],
   documents that describe capabilities that are dependent on link
   indications should explicitly articulate the assumptions of the link
   model and describe the circumstances in which they apply.

   Generic "trigger" models may include implicit assumptions that may
   prove invalid in outdoor or mesh wireless LAN deployments.  For
   example, two-state Markov models assume that the link is either in a
   state experiencing low frame loss ("up") or in a state where few
   frames are successfully delivered ("down").  In these models,
   symmetry is also typically assumed, so that the link is either "up"
   in both directions or "down" in both directions.  In situations where
   intermediate loss rates are experienced, these assumptions may be
   invalid.

   As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev],
   signal strength data is noisy and sometimes inconsistent, so that it
   needs to be filtered in order to avoid erratic results.  Given this,
   link indications based on raw signal strength data may be unreliable.
   In order to avoid problems, it is best to combine signal strength
   data with other techniques.  For example, in developing a "Going
   Down" indication for use with [IEEE-802.21] it would be advisable to

   validate filtered signal strength measurements with other indications
   of link loss such as lack of Beacon reception.

2.2.  Clear Definitions

   Link indications should be clearly defined, so that it is understood
   when they are generated on different link layers.  For example,
   considerable work has been required in order to come up with the
   definitions of "Link Up" and "Link Down", and to define when these
   indications are sent on various link layers.

   Link indication definitions should heed the following advice:

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

        In wired networks, links in the "up" state typically experience
        low frame loss in both directions and are ready to send and
        receive data frames; links in the "down" state are unsuitable
        for sending and receiving data frames in either direction.
        Therefore, a link providing a "Link Up" indication will
        typically experience low frame loss in both directions, and high
        frame loss in any direction can only be experienced after a link
        provides a "Link Down" indication.  However, these assumptions
        may not hold true for wireless LAN networks.  Asymmetry is
        typically less of a problem for cellular networks where
        propagation occurs over longer distances, multi-path effects may
        be less severe, and the base station can transmit at much higher
        power than mobile stations while utilizing a more sensitive
        antenna.

        Specifications utilizing a "Link Up" indication should not
        assume that receipt of this indication means that the link is
        experiencing symmetric link conditions or low frame loss in
        either direction.  In general, a "Link Up" event should not be
        sent due to transient changes in link conditions, but only due
        to a change in link layer state.  It is best to assume that a
        "Link Up" event may not be sent in a timely way.  Large handoff
        latencies can result in a delay in the generation of a "Link Up"
        event as movement to an alternative point of attachment is
        delayed.

   (2)  Consider the sensitivity of link indications to transient link
        conditions.  Due to common effects such as multi-path
        interference, signal strength and signal to noise ratio (SNR)
        may vary rapidly over a short distance, causing erratic behavior
        of link indications based on unfiltered measurements.  As noted
        in [Haratcherev], signal strength may prove most useful when

        utilized in combination with other measurements, such as frame
        loss.

   (3)  Where possible, design link indications with built-in damping.
        By design, the "Link Up" and "Link Down" events relate to
        changes in the state of the link layer that make it able and
        unable to communicate IP packets.  These changes are generated
        either by the link layer state machine based on link layer
        exchanges (e.g., completion of the IEEE 802.11i four-way
        handshake for "Link Up", or receipt of a PPP LCP-Terminate for
        "Link Down") or by protracted frame loss, so that the link layer
        concludes that the link is no longer usable.  As a result, these
        link indications are typically less sensitive to changes in
        transient link conditions.

   (4)  Do not assume that a "Link Down" event will be sent at all, or
        that, if sent, it will be received in a timely way.  A good link
        layer implementation will both rapidly detect connectivity
        failure (such as by tracking missing Beacons) while sending a
        "Link Down" event only when it concludes the link is unusable,
        not due to transient frame loss.

   However, existing wireless LAN implementations often do not do a good
   job of detecting link failure.  During a lengthy detection phase, a
   "Link Down" event is not sent by the link layer, yet IP packets
   cannot be transmitted or received on the link.  Initiation of a scan
   may be delayed so that the station cannot find another point of
   attachment.  This can result in inappropriate backoff of
   retransmission timers within the transport layer, among other
   problems.  This is not as much of a problem for cellular networks
   that utilize transmit power adjustment.

2.3.  Robustness

   Link indication proposals must demonstrate robustness against
   misleading indications.  Elements to consider include:

      Implementation variation
      Recovery from invalid indications
      Damping and hysteresis

2.3.1.  Implementation Variation

   Variations in link layer implementations may have a substantial
   impact on the behavior of link indications.  These variations need to
   be taken into account in evaluating the performance of proposals.
   For example, radio propagation and implementation differences can
   impact the reliability of link indications.

   In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
   the authors analyze the cause of frame loss in a 38-node urban
   multi-hop IEEE 802.11 ad-hoc network.  In most cases, links that are
   very bad in one direction tend to be bad in both directions, and
   links that are very good in one direction tend to be good in both
   directions.  However, 30 percent of links exhibited loss rates
   differing substantially in each direction.

   As described in [Aguayo], wireless LAN links often exhibit loss rates
   intermediate between "up" (low loss) and "down" (high loss) states,
   as well as substantial asymmetry.  As a result, receipt of a "Link
   Up" indication may not necessarily indicate bidirectional
   reachability, since it could have been generated after exchange of
   small frames at low rates, which might not imply bidirectional
   connectivity for large frames exchanged at higher rates.

   Where multi-path interference or hidden nodes are encountered, signal
   strength may vary widely over a short distance.  Several techniques
   may be used to reduce potential disruptions.  Multiple transmitting
   and receiving antennas may be used to reduce multi-path effects;
   transmission rate adaptation can be used to find a more satisfactory
   transmission rate; transmit power adjustment can be used to improve
   signal quality and reduce interference; Request-to-Send/Clear-to-Send
   (RTS/CTS) signaling can be used to reduce hidden node problems.
   These techniques may not be completely effective, so that high frame
   loss may be encountered, causing the link to cycle between "up" and
   "down" states.

   To improve robustness against spurious link indications, it is
   recommended that upper layers treat the indication as a "hint"
   (advisory in nature), rather than a "trigger" dictating a particular
   action.  Upper layers may then attempt to validate the hint.

   In [RFC4436], "Link Up" indications are rate limited, and IP
   configuration is confirmed using bidirectional reachability tests
   carried out coincident with a request for configuration via DHCP.  As
   a result, bidirectional reachability is confirmed prior to activation
   of an IP configuration.  However, where a link exhibits an
   intermediate loss rate, demonstration of bidirectional reachability
   may not necessarily indicate that the link is suitable for carrying
   IP data packets.

   Another example of validation occurs in IPv4 Link-Local address
   configuration [RFC3927].  Prior to configuration of an IPv4 Link-
   Local address, it is necessary to run a claim-and-defend protocol.
   Since a host needs to be present to defend its address against
   another claimant, and address conflicts are relatively likely, a host
   returning from sleep mode or receiving a "Link Up" indication could

   encounter an address conflict were it to utilize a formerly
   configured IPv4 Link-Local address without rerunning claim and
   defend.

2.3.2.  Recovery from Invalid Indications

   In some situations, improper use of link indications can result in
   operational malfunctions.  It is recommended that upper layers
   utilize a timely recovery step so as to limit the potential damage
   from link indications determined to be invalid after they have been
   acted on.

   In Detecting Network Attachment in IPv4 (DNAv4) [RFC4436],
   reachability tests are carried out coincident with a request for
   configuration via DHCP.  Therefore, if the bidirectional reachability
   test times out, the host can still obtain an IP configuration via
   DHCP, and if that fails, the host can still continue to use an
   existing valid address if it has one.

   Where a proposal involves recovery at the transport layer, the
   recovered transport parameters (such as the Maximum Segment Size
   (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth
   (bw), congestion window (cwnd), etc.) should be demonstrated to
   remain valid.  Congestion window validation is discussed in "TCP
   Congestion Window Validation" [RFC2861].

   Where timely recovery is not supported, unexpected consequences may
   result.  As described in [RFC3927], early IPv4 Link-Local
   implementations would wait five minutes before attempting to obtain a
   routable address after assigning an IPv4 Link-Local address.  In one
   implementation, it was observed that where mobile hosts changed their
   point of attachment more frequently than every five minutes, they
   would never obtain a routable address.  The problem was caused by an
   invalid link indication (signaling of "Link Up" prior to completion
   of link layer authentication), resulting in an initial failure to
   obtain a routable address using DHCP.  As a result, [RFC3927]
   recommends against modification of the maximum retransmission timeout
   (64 seconds) provided in [RFC2131].

2.3.3.  Damping and Hysteresis

   Damping and hysteresis can be utilized to limit damage from unstable
   link indications.  This may include damping unstable indications or
   placing constraints on the frequency of link indication-induced
   actions within a time period.

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

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

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

   In some cases, it is desirable to ignore link indications entirely.
   Since it is possible for a host to transition from an ad-hoc network
   to a network with centralized address management, a host receiving a
   "Link Up" indication cannot necessarily conclude that it is
   appropriate to configure an IPv4 Link-Local address prior to
   determining whether a DHCP server is available [RFC3927] or an
   operable configuration is valid [RFC4436].

   As noted in Section 1.4, the transport layer does not utilize "Link
   Up" and "Link Down" indications for the purposes of connection
   management.

2.4.  Congestion Control

   Link indication proposals must demonstrate that effective congestion
   control is maintained [RFC2914].  One or more of the following
   techniques may be utilized:

      Rate limiting.  Packets generated based on receipt of link
      indications can be rate limited (e.g., a limit of one packet per
      end-to-end path RTO).

      Utilization of upper-layer indications.  Applications should
      depend on upper-layer indications such as IP address
      configuration/change notification, rather than utilizing link
      indications such as "Link Up".

      Keepalives.  In order to improve robustness against spurious link
      indications, an application keepalive or transport layer
      indication (such as connection teardown) can be used instead of
      consuming "Link Down" indications.

      Conservation of resources.  Proposals must demonstrate that they
      are not vulnerable to congestive collapse.

   As noted in "Robust Rate Adaptation for 802.11 Wireless Networks"
   [Robust], decreasing transmission rate in response to frame loss
   increases contention, potentially leading to congestive collapse.  To
   avoid this, the link layer needs to distinguish frame loss due to
   congestion from loss due to channel conditions.  Only frame loss due
   to deterioration in channel conditions can be used as a basis for
   decreasing transmission rate.

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

   At the application layer, link indications have been utilized by
   applications such as Presence [RFC2778] in order to optimize
   registration and user interface update operations.  For example,
   implementations may attempt presence registration on receipt of a
   "Link Up" indication, and presence de-registration by a surrogate
   receiving a "Link Down" indication.  Presence implementations using
   "Link Up"/"Link Down" indications this way violate the principle of
   "conservation of packets" since link indications can be generated on
   a time scale less than the end-to-end path RTO.  The problem is
   magnified since for each presence update, notifications can be
   delivered to many watchers.  In addition, use of a "Link Up"
   indication in this manner is unwise since the interface may not yet
   even have an operable Internet layer configuration.  Instead, an "IP
   address configured" indication may be utilized.

2.5.  Effectiveness

   Proposals must demonstrate the effectiveness of proposed
   optimizations.  Since optimizations typically increase complexity,
   substantial performance improvement is required in order to make a
   compelling case.

   In the face of unreliable link indications, effectiveness may depend
   on the penalty for false positives and false negatives.  In the case
   of DNAv4 [RFC4436], the benefits of successful optimization are
   modest, but the penalty for being unable to confirm an operable
   configuration is a lengthy timeout.  As a result, the recommended
   strategy is to test multiple potential configurations in parallel in
   addition to attempting configuration via DHCP.  This virtually
   guarantees that DNAv4 will always result in performance equal to or
   better than use of DHCP alone.

2.6.  Interoperability

   While link indications can be utilized where available, they should
   not be required by upper layers, in order to maintain link layer
   independence.  For example, if information on supported prefixes is
   provided at the link layer, hosts not understanding those hints must
   still be able to obtain an IP address.

   Where link indications are proposed to optimize Internet layer
   configuration, proposals must demonstrate that they do not compromise
   robustness by interfering with address assignment or routing protocol
   behavior, making address collisions more likely, or compromising
   Duplicate Address Detection (DAD) [RFC4429].

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

2.7.  Race Conditions

   Link indication proposals should avoid race conditions, which can
   occur where link indications are utilized directly by multiple layers
   of the stack.

   Link indications are useful for optimization of Internet Protocol
   layer addressing and configuration as well as routing.  Although "The
   BU-trigger method for improving TCP performance over Mobile IPv6"
   [Kim] describes situations in which link indications are first
   processed by the Internet Protocol layer (e.g., MIPv6) before being
   utilized by the transport layer, for the purposes of parameter
   estimation, it may be desirable for the transport layer to utilize
   link indications directly.

   In situations where the Weak End System model is implemented, a
   change of outgoing interface may occur at the same time the transport
   layer is modifying transport parameters based on other link

   indications.  As a result, transport behavior may differ depending on
   the order in which the link indications are processed.

   Where a multi-homed host experiences increasing frame loss or
   decreased rate on one of its interfaces, a routing metric taking
   these effects into account will increase, potentially causing a
   change in the outgoing interface for one or more transport
   connections.  This may trigger Mobile IP signaling so as to cause a
   change in the incoming path as well.  As a result, the transport
   parameters estimated for the original outgoing and incoming paths
   (congestion state, Maximum Segment Size (MSS) derived from the link
   maximum transmission unit (MTU) or Path MTU) may no longer be valid
   for the new outgoing and incoming paths.

   To avoid race conditions, the following measures are recommended:

      Path change re-estimation
      Layering
      Metric consistency

2.7.1.  Path Change Re-estimation

   When the Internet layer detects a path change, such as a major change
   in transmission rate, a change in the outgoing or incoming interface
   of the host or the incoming interface of a peer, or perhaps even a
   substantial change in the IPv4 TTL/IPv6 Hop Limit of received
   packets, it may be worth considering whether to reset transport
   parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so as to
   allow them to be re-estimated.  This ensures that estimates based on
   the former path do not persist after they have become invalid.
   Appendix A.3 summarizes the research on this topic.

2.7.2.  Layering

   Another technique to avoid race conditions is to rely on layering to
   damp transient link indications and provide greater link layer
   independence.

   The Internet layer is responsible for routing as well as IP
   configuration and mobility, providing higher layers with an
   abstraction that is independent of link layer technologies.

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

2.7.3.  Metric Consistency

   Proposals should avoid inconsistencies between link and routing layer
   metrics.  Without careful design, potential differences between link
   indications used in routing and those used in roaming and/or link
   enablement can result in instability, particularly in multi-homed
   hosts.

   Once a link is in the "up" state, its effectiveness in transmission
   of data packets can be used to determine an appropriate routing
   metric.  In situations where the transmission time represents a large
   portion of the total transit time, minimizing total transmission time
   is equivalent to maximizing effective throughput.  "A High-Throughput
   Path Metric for Multi-Hop Wireless Routing" [ETX] describes a
   proposed routing metric based on the Expected Transmission Count
   (ETX).  The authors demonstrate that ETX, based on link layer frame
   loss rates (prior to retransmission), enables the selection of routes
   maximizing effective throughput.  Where the transmission rate is
   constant, the expected transmission time is proportional to ETX, so
   that minimizing ETX also minimizes expected transmission time.

   However, where the transmission rate may vary, ETX may not represent
   a good estimate of the estimated transmission time.  In "Routing in
   multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the
   authors define a new metric called Expected Transmission Time (ETT).
   This is described as a "bandwidth adjusted ETX" since ETT = ETX * S/B
   where S is the size of the probe packet and B is the bandwidth of the
   link as measured by a packet pair [Morgan].  However, ETT assumes
   that the loss fraction of small probe frames sent at 1 Mbps data rate
   is indicative of the loss fraction of larger data frames at higher
   rates, which tends to underestimate the ETT at higher rates, where
   frame loss typically increases.  In "A Radio Aware Routing Protocol
   for Wireless Mesh Networks" [ETX-Radio], the authors refine the ETT
   metric further by estimating the loss fraction as a function of
   transmission rate.

   However, prior to sending data packets over the link, the appropriate
   routing metric may not easily be predicted.  As noted in [Shortest],
   a link that can successfully transmit the short frames utilized for
   control, management, or routing may not necessarily be able to
   reliably transport larger data packets.

   Therefore, it may be necessary to utilize alternative metrics (such
   as signal strength or Access Point load) in order to assist in
   attachment/handoff decisions.  However, unless the new interface is
   the preferred route for one or more destination prefixes, a Weak End
   System implementation will not use the new interface for outgoing
   traffic.  Where "idle timeout" functionality is implemented, the

   unused interface will be brought down, only to be brought up again by
   the link enablement algorithm.

   Within the link layer, metrics such as signal strength and frame loss
   may be used to determine the transmission rate, as well as to
   determine when to select an alternative point of attachment.  In
   order to enable stations to roam prior to encountering packet loss,
   studies such as "An experimental study of IEEE 802.11b handover
   performance and its effect on voice traffic" [Vatn] have suggested
   using signal strength as a mechanism to more rapidly detect loss of
   connectivity, rather than frame loss, as suggested in "Techniques to
   Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos].

   [Aguayo] notes that signal strength and distance are not good
   predictors of frame loss or throughput, due to the potential effects
   of multi-path interference.  As a result, a link brought up due to
   good signal strength may subsequently exhibit significant frame loss
   and a low throughput.  Similarly, an Access Point (AP) demonstrating
   low utilization may not necessarily be the best choice, since
   utilization may be low due to hardware or software problems.  "OSPF
   Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-
   utilization-based routing metrics have a history of instability.

2.8.  Layer Compression

   In many situations, the exchanges required for a host to complete a
   handoff and reestablish connectivity are considerable, leading to
   proposals to combine exchanges occurring within multiple layers in
   order to reduce overhead.  While overhead reduction is a laudable
   goal, proposals need to avoid compromising interoperability and
   introducing link layer dependencies into the Internet and transport
   layers.

   Exchanges required for handoff and connectivity reestablishment may
   include link layer scanning, authentication, and association
   establishment; Internet layer configuration, routing, and mobility
   exchanges; transport layer retransmission and recovery; security
   association reestablishment; application protocol re-authentication
   and re-registration exchanges, etc.

   Several proposals involve combining exchanges within the link layer.
   For example, in [EAPIKEv2], a link layer Extensible Authentication
   Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP
   address assignment, potentially bypassing Internet layer
   configuration.  Within [PEAP], it is proposed that a link layer EAP
   exchange be used for the purpose of carrying Mobile IPv6 Binding
   Updates.  [MIPEAP] proposes that EAP exchanges be used for
   configuration of Mobile IPv6.  Where link, Internet, or transport

   layer mechanisms are combined, hosts need to maintain backward
   compatibility to permit operation on networks where compression
   schemes are not available.

   Layer compression schemes may also negatively impact robustness.  For
   example, in order to optimize IP address assignment, it has been
   proposed that prefixes be advertised at the link layer, such as
   within the 802.11 Beacon and Probe Response frames.  However,
   [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be
   assigned dynamically, so that prefix(es) advertised within the Beacon
   and/or Probe Response may not correspond to the prefix(es) configured
   by the Internet layer after the host completes link layer
   authentication.  Were the host to handle IP configuration at the link
   layer rather than within the Internet layer, the host might be unable
   to communicate due to assignment of the wrong IP address.

2.9.  Transport of Link Indications

   Proposals for the transport of link indications need to carefully
   consider the layering, security, and transport implications.

   As noted earlier, the transport layer may take the state of the local
   routing table into account in improving the quality of transport
   parameter estimates.  While absence of positive feedback that the
   path is sending data end-to-end must be heeded, where a route that
   had previously been absent is recovered, this may be used to trigger
   congestion control probing.  While this enables transported link
   indications that affect the local routing table to improve the
   quality of transport parameter estimates, security and
   interoperability considerations relating to routing protocols still
   apply.

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

   (a)  Superiority to implicit signals.  In general, implicit signals
        are preferred to explicit transport of link indications since
        they do not require participation in the routing mesh, add no
        new packets in times of network distress, operate more reliably
        in the presence of middle boxes such as NA(P)Ts, are more likely
        to be backward compatible, and are less likely to result in
        security vulnerabilities.  As a result, explicit signaling
        proposals must prove that implicit signals are inadequate.

   (b)  Mitigation of security vulnerabilities.  Transported link
        indications should not introduce new security vulnerabilities.
        Link indications that result in modifications to the local
        routing table represent a routing protocol, so that the

        vulnerabilities associated with unsecured routing protocols
        apply, including spoofing by off-link attackers.  While
        mechanisms such as "SEcure Neighbor Discovery (SEND)" [RFC3971]
        may enable authentication and integrity protection of router-
        originated messages, protecting against forgery of transported
        link indications, they are not yet widely deployed.

   (c)  Validation of transported indications.  Even if a transported
        link indication can be integrity protected and authenticated, if
        the indication is sent by a host off the local link, it may not
        be clear that the sender is on the actual path in use, or which
        transport connection(s) the indication relates to.  Proposals
        need to describe how the receiving host can validate the
        transported link indication.

   (d)  Mapping of Identifiers.  When link indications are transported,
        it is generally for the purposes of providing information about
        Internet, transport, or application layer operations at a remote
        element.  However, application layer sessions or transport
        connections may not be visible to the remote element due to
        factors such as load sharing between links, or use of IPsec,
        tunneling protocols, or nested headers.  As a result, proposals
        need to demonstrate how the link indication can be mapped to the
        relevant higher-layer state.  For example, on receipt of a link
        indication, the transport layer will need to identify the set of
        transport sessions (source address, destination address, source
        port, destination port, transport) that are affected.  If a
        presence server is receiving remote indications of "Link
        Up"/"Link Down" status for a particular Media Access Control
        (MAC) address, the presence server will need to associate that
        MAC address with the identity of the user
        (pres:user@example.com) to whom that link status change is
        relevant.

3.  Future Work

   Further work is needed in order to understand how link indications
   can be utilized by the Internet, transport, and application layers.

   More work is needed to understand the connection between link
   indications and routing metrics.  For example, the introduction of
   block ACKs (supported in [IEEE-802.11e]) complicates the relationship
   between effective throughput and frame loss, which may necessitate
   the development of revised routing metrics for ad-hoc networks.  More
   work is also needed to reconcile handoff metrics (e.g., signal
   strength and link utilization) with routing metrics based on link
   indications (e.g., frame error rate and negotiated rate).

   A better understanding of the use of physical and link layer metrics
   in rate negotiation is required.  For example, recent work
   [Robust][CARA] has suggested that frame loss due to contention (which
   would be exacerbated by rate reduction) can be distinguished from
   loss due to channel conditions (which may be improved via rate
   reduction).

   At the transport layer, more work is needed to determine the
   appropriate reaction to Internet layer indications such as routing
   table and path changes.  More work is also needed in utilization of
   link layer indications in transport parameter estimation, including
   rate changes, "Link Up"/"Link Down" indications, link layer
   retransmissions, and frame loss of various types (due to contention
   or channel conditions).

   More work is also needed to determine how link layers may utilize
   information from the transport layer.  For example, it is undesirable
   for a link layer to retransmit so aggressively that the link layer
   round-trip time approaches that of the end-to-end transport
   connection.  Instead, it may make sense to do downward rate
   adjustment so as to decrease frame loss and improve latency.  Also,
   in some cases, the transport layer may not require heroic efforts to
   avoid frame loss; timely delivery may be preferred instead.