draft-iab-link-indications-02.txt   draft-iab-link-indications-03.txt 
Network Working Group B. Aboba, Ed. Network Working Group B. Aboba, Ed.
INTERNET-DRAFT Internet Architecture Board INTERNET-DRAFT Internet Architecture Board
Category: Informational IAB Category: Informational IAB
<draft-iab-link-indications-02.txt> <draft-iab-link-indications-03.txt>
2 July 2005 18 August 2005
Architectural Implications of Link Indications Architectural Implications of Link Indications
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2005. This Internet-Draft will expire on February 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the role of link indications within the This document describes the role of link indications within the
Internet Architecture. While the judicious use of link indications Internet Architecture. While the judicious use of link indications
can provide performance benefits, inappropriate use can degrade both can provide performance benefits, inappropriate use can degrade both
robustness and performance. This document summarizes current robustness and performance. This document summarizes current
proposals, describes the architectural issues and provides examples proposals, describes the architectural issues and provides examples
of appropriate and inappropriate uses of link layer indications. of appropriate and inappropriate uses of link layer indications.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements ....................................... 3 1.1 Requirements ....................................... 3
1.2 Terminology ........................................ 3 1.2 Terminology ........................................ 3
1.3 Overview ........................................... 6 1.3 Overview ........................................... 7
1.4 Layered Indication Model ........................... 9 1.4 Layered Indication Model ........................... 9
2. Architectural Considerations ............................. 14 2. Architectural Considerations ............................. 14
2.1 Model Validation ................................... 14 2.1 Model Validation ................................... 15
2.2 Clear Definitions .................................. 15 2.2 Clear Definitions .................................. 16
2.3 Robustness ......................................... 16 2.3 Robustness ......................................... 18
2.4 Stability .......................................... 20 2.4 Congestion Control ................................. 20
2.5 Effectiveness ...................................... 21 2.5 Effectiveness ...................................... 22
2.6 Interoperability ................................... 22 2.6 Interoperability ................................... 23
2.7 Race Conditions .................................... 22 2.7 Race Conditions .................................... 23
2.8 Layer Compression .................................. 25 2.8 Layer Compression .................................. 25
2.9 Transport of Link Indications ...................... 26 2.9 Transport of Link Indications ...................... 26
3. Future Work .............................................. 27 3. Future Work .............................................. 27
4. Security Considerations .................................. 28 4. Security Considerations .................................. 28
5. References ............................................... 29 4.1 Spoofing ........................................... 28
5.1 Informative References ............................. 29 4.2 Indication Validation .............................. 29
Appendix A - Literature Review ............................... 36 4.3 Denial of Service .................................. 30
A.1 Link Layer ......................................... 36 5. References ............................................... 31
A.2 Internet Layer ..................................... 41 5.1 Informative References ............................. 31
A.3 Transport Layer .................................... 43 Appendix A - Literature Review ............................... 38
A.4 Application Layer .................................. 47 A.1 Link Layer ......................................... 38
Appendix B - IAB Members ..................................... 48 A.2 Internet Layer ..................................... 43
Intellectual Property Statement .............................. 48 A.3 Transport Layer .................................... 45
Disclaimer of Validity ....................................... 48 A.4 Application Layer .................................. 49
Copyright Statement .......................................... 49 Appendix B - IAB Members ..................................... 50
Intellectual Property Statement .............................. 50
Disclaimer of Validity ....................................... 51
Copyright Statement .......................................... 51
1. Introduction 1. Introduction
A link indication represents information provided by the link layer A link indication represents information provided by the link layer
to higher layers regarding the state of the link. to higher layers regarding the state of the link.
This document provides an overview of the role of link indications This document provides an overview of the role of link indications
within the Internet Architecture. While the judicious use of link within the Internet Architecture. While the judicious use of link
indications can provide performance benefits, experience has also indications can provide performance benefits, experience has also
shown that that inappropriate use can degrade both robustness and shown that that inappropriate use can degrade both robustness and
performance. performance.
This document summarizes the current understanding of the role of This document summarizes the current understanding of the role of
link indications, and provides advice to document authors about the link indications, and provides advice to document authors about the
appropriate use of link indications. appropriate use of link indications.
In Section 1 describes the history of link indication usage within In Section 1 describes the history of link indication usage within
the Internet architecture and provides a model for the utilization of the Internet architecture and provides a model for the utilization of
link indications. Section 2 provides advice to document authors. link indications. Section 2 describes the architectural
Section 3 describes recommendations and future work. Appendix A considerations and provides advice to document authors. Section 3
presents a summary of the literature on link indication utilization. describes recommendations and future work. Appendix A presents a
summary of the literature on link indication utilization.
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Access Point (AP) Access Point (AP)
A station that provides access to the distribution services, via A station that provides access to the fixed network (e.g. an 802.11
the wireless medium (WM) for associated stations. Distribution System), via the wireless medium (WM) for associated
stations.
Association Association
The service used to establish an access point/station (AP/STA) The service used to establish an access point/station (AP/STA)
mapping and enable STA access to the Distribution System. mapping and enable stations to access the Distribution System
network via the wireless medium.
Basic Service Set (BSS) Basic Service Set (BSS)
A set of stations controlled by a single coordination function, An IEEE 802.11 specific term. A set of stations controlled by a
where the coordination function may be centralized (e.g., in a single coordination function, where the coordination function may
single AP) or distributed (e.g., for an ad-hoc network). The BSS be centralized (e.g., in a single AP) or distributed (e.g., for an
can be thought of as the coverage area of a single AP. ad-hoc network). Membership of a BSS does not imply that wireless
communication with all other members of the BSS is possible.
Beacon Beacon
A control message broadcast by a node (especially, a base station) A control message broadcast by a station (typically an Access
informing all the other nodes in its neighborhood of the continuing Point), informing stations in the neighborhood of its continuing
presence of the broadcasting node, possibly along with additional presence, possibly along with additional status or configuration
status or configuration information. information.
Binding Update (BU) Binding Update (BU)
A message indicating a mobile node's current mobility binding, and A message indicating a mobile node's current mobility binding, and
in particular its care-of address. in particular its care-of address.
Care of Address (CoA) Care of Address (CoA)
A unicast routable address associated with a mobile node while A unicast routable address associated with a mobile node while
visiting a foreign link; the subnet prefix of this IP address is a visiting a foreign link; the subnet prefix of this IP address is a
foreign subnet prefix. Among the multiple care-of addresses that 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 mobile node may have at any given time (e.g., with different subnet
skipping to change at page 4, line 34 skipping to change at page 4, line 40
service set (ESS). service set (ESS).
Dynamic Host Configuration Protocol (DHCP) client Dynamic Host Configuration Protocol (DHCP) client
A DHCP client is an Internet host using DHCP to obtain A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
DHCP server DHCP server
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
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). The Distribution System is a network connecting
Access Points, thereby enabling wider wireless coverage than a
single access point can provide.
Extended Service Set (ESS) Extended Service Set (ESS)
A set of one or more interconnected basic service sets (BSSs) and A set of one or more interconnected basic service sets (BSSs) that
integrated local area networks (LANs) that appears as a single BSS appears as a single BSS to the logical link control layer at any
to the logical link control layer at any station associated with station associated with one of those BSSs. TheWhile link
one of those BSSs. The ESS can be thought of as the coverage area indications may show promise, it may be difficult to prove that
provided by a collection of APs all interconnected by the processing of a given indication provides benefits in a wide
variety of circumstances. 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 prefixes. Distribution System. It may consist of one or more prefixes.
Home Address (HoA) Independent Basic Service Set (IBSS)
A unicast routable address assigned to a mobile node, used as the A BSS that forms a self-contained network, and in which no access
permanent address of the mobile node. This address is within the to a distribution system (DS) is available.
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.
Home Agent (HA)
A router on a mobile node's home link with which the mobile node
has registered its current care-of address. While the mobile node
is away from home, the home agent intercepts packets on the home
link destined to the mobile node's home address, encapsulates them,
and tunnels them to the mobile node's registered care-of address.
Inter-Access Point Protocol (IAPP) Inter-Access Point Protocol (IAPP)
A protocol used between access points that assures that the station 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 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. also provides for transfer of context to the new AP.
Link A communication facility or physical medium that can sustain data Link A communication facility or physical medium that can sustain data
communications between multiple network nodes, such as an Ethernet communications between multiple network nodes, such as an Ethernet
(simple or bridged). A link is the layer immediately below IP. In (simple or bridged). A link is the layer immediately below IP. In
a layered network stack model, the Link Layer (Layer 2) is normally a layered network stack model, the Link Layer (Layer 2) is normally
skipping to change at page 5, line 47 skipping to change at page 5, line 51
functions provide an interface between the higher-layer logic and functions provide an interface between the higher-layer logic and
the data link. The link layer is the layer immediately below IP. the data link. The link layer is the layer immediately below IP.
Link identifier Link identifier
An indication provided by the link layer as to which network(s) a An indication provided by the link layer as to which network(s) a
host has connected to. Examples include the SSID with IEEE 802.11. host has connected to. Examples include the SSID with IEEE 802.11.
For details, see [DNAv4] Appendix A. For details, see [DNAv4] Appendix A.
Link indication Link indication
Information provided by the link layer to higher layers regarding Information provided by the link layer to higher layers regarding
the state of the link. In addition to "Link Up" and "Link Down" the state of the link. In addition to "Link Up" and "Link Down",
indications, other relevant link information may include the relevant information may include the current link rate, link
current link rate (which may vary with time and location), link identifiers (e.g. SSID, BSSID in 802.11), and link performance
identifiers (e.g. SSID, BSSID in 802.11), and statistics relating statistics (such as the delay or loss rate).
to link performance (such as the delay or loss rate).
Link Up Link Up
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating associated with the interface becoming capable of communicating
data frames. data frames.
Most Likely Network (MLN) Most Likely Networks (MLNs)
The attached network heuristically determined by the host to be The attached network(s) heuristically determined by the host to be
most likely, based on hints. most likely.
Point of Attachment Point of Attachment
The link endpoint on the link to which the host is currently The endpoint on the link to which the host is currently connected.
connected.
Medium Access Protocol (MAC) Medium Access Protocol (MAC)
A protocol for mediating access to, and possibly allocation of, the A protocol for mediating access to, and possibly allocation of, the
physical communications medium. Nodes participating in the medium physical communications medium. Nodes participating in the medium
access protocol can communicate only when they have uncontested access protocol can communicate only when they have uncontested
access to the medium, so that there will be no interference. When access to the medium, so that there will be no interference. When
the physical medium is a radio channel, the MAC is the same as the the physical medium is a radio channel, the MAC is the same as the
Channel Access Protocol. Channel Access Protocol.
Mobile Node Mobile Node
A node that can change its point of attachment from one link to A node that can change its point of attachment from one link to
another, while still being reachable via its home address. another, while still being reachable via its home address.
Operable address
The term "operable address" refers to either a static address, or a
dynamically assigned address which has not been relinquished, and
has not expired.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
address other than an IPv4 Link-Local address [RFC3927]. This address other than an IPv4 Link-Local address [RFC3927]. This
includes private addresses as specified in [RFC1918]. includes private addresses as specified in [RFC1918].
Station (STA) Station (STA)
Any device that contains an IEEE 802.11 conformant medium access Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless control (MAC) and physical layer (PHY) interface to the wireless
medium (WM). medium (WM).
Operable address Service Set Identifier (SSID)
The term "operable address" refers to either a static address, or a The SSID indicates the identity of an ESS or IBSS.
dynamically assigned address which has not been relinquished, and
has not expired.
Weak End-System Model Weak End-System Model
In the Weak End-System Model, packets sent out an interface need In the Weak End-System Model, packets sent out an interface need
not necessarily have a source address configured on that interface. not necessarily have a source address configured on that interface.
1.3. Overview 1.3. Overview
Link status was first taken into account in computer routing within Link status was first taken into account in computer routing within
the ARPANET as early as 1969. In response to an attempt to send to a the ARPANET as early as 1969. In response to an attempt to send to a
host that was off-line, the ARPANET link layer protocol provided a host that was off-line, the ARPANET link layer protocol provided a
skipping to change at page 7, line 23 skipping to change at page 7, line 29
defines OSPF, which uses Link State Advertisements (LSAs) in order to defines OSPF, which uses Link State Advertisements (LSAs) in order to
flood information relating to link status within an OSPF area. As flood information relating to link status within an OSPF area. As
noted in "Requirements for IP Version 4 Routers" [RFC1812]: noted in "Requirements for IP Version 4 Routers" [RFC1812]:
It is crucial that routers have workable mechanisms for It is crucial that routers have workable mechanisms for
determining that their network connections are functioning determining that their network connections are functioning
properly. Failure to detect link loss, or failure to take the properly. Failure to detect link loss, or failure to take the
proper actions when a problem is detected, can lead to black proper actions when a problem is detected, can lead to black
holes. holes.
"Fault Isolation and Recovery" [RFC826] Section 3 describes how hosts
interact with gateways for the purpose of fault detection and
recovery:
Since the gateways always attempt to have a consistent and
correct model of the internetwork topology, the host strategy for
fault recovery is very simple. Whenever the host feels that
something is wrong, it asks the gateway for advice, and,
assuming the advice is forthcoming, it believes the advice
completely. The advice will be wrong only during the transient
period of negotiation, which immediately follows an outage, but
will otherwise be reliably correct.
In ideal conditions, links in the "up" state experience low frame In ideal conditions, links in the "up" state experience low frame
loss in both directions and are immediately ready to send and receive loss in both directions and are immediately ready to send and receive
data frames; links in the "down" state are unsuitable for sending and data frames; links in the "down" state are unsuitable for sending and
receiving data frames in either direction. Unfortunately links receiving data frames in either direction. Unfortunately links
frequently exhibit non-ideal behavior. Wired links may fail in half- frequently exhibit non-ideal behavior. Wired links may fail in half-
duplex mode, or exhibit partial impairment resulting in intermediate duplex mode, or exhibit partial impairment resulting in intermediate
loss rates. Wireless links may exhibit asymmetry or frame loss due loss rates. Wireless links may exhibit asymmetry or frame loss due
to interference or signal fading. In both wired and wireless links, to interference or signal fading. In both wired and wireless links,
the link state may rapidly flap between the "up" and "down" states. the link state may rapidly flap between the "up" and "down" states.
skipping to change at page 8, line 45 skipping to change at page 8, line 38
indoor and outdoor mesh network. By measuring inter-node throughput, indoor and outdoor mesh network. By measuring inter-node throughput,
the best path between nodes was computed. The throughput of the best the best path between nodes was computed. The throughput of the best
path was compared with the throughput of the shortest path computed path was compared with the throughput of the shortest path computed
based on a hop-count metric. In almost all cases, the shortest path based on a hop-count metric. In almost all cases, the shortest path
route offered considerably lower throughput than the best path. route offered considerably lower throughput than the best path.
In examining link behavior, the authors found that rather than In examining link behavior, the authors found that rather than
exhibiting a bi-modal distribution between "up" (low loss rate) and exhibiting a bi-modal distribution between "up" (low loss rate) and
"down" (high loss rates), many links exhibited intermediate loss "down" (high loss rates), many links exhibited intermediate loss
rates. Asymmetry was also common, with 30 percent of links rates. Asymmetry was also common, with 30 percent of links
demonstrating substantial differences between in the loss rates in demonstrating substantial differences in the loss rates in each
each direction. As a result, on wireless networks the measured direction. As a result, on wireless networks the measured throughput
throughput can differ substantially from the negotiated rate due to can differ substantially from the negotiated rate due to
retransmissions, and successful delivery of routing packets is not retransmissions, and successful delivery of routing packets is not
necessarily an indication that the link is useful for delivery of necessarily an indication that the link is useful for delivery of
data. data.
The complexity of real-world link behavior poses a challenge to the The complexity of real-world link behavior poses a challenge to the
integration of link indications within the Internet architecture. integration of link indications within the Internet architecture.
While the judicious use of link indications can provide performance While the judicious use of link indications can provide performance
benefits, inappropriate use can degrade both robustness and benefits, inappropriate use can degrade both robustness and
performance. This document provides guidance on the incorporation of performance. This document provides guidance on the incorporation of
link indications within the Internet, Transport and Application link indications within the Internet, Transport and Application
skipping to change at page 9, line 28 skipping to change at page 9, line 20
and path change detection. and path change detection.
In this model, link indications include frame loss (before In this model, link indications include frame loss (before
retransmissions), the current link rate, the link state (up/down), retransmissions), the current link rate, the link state (up/down),
and link identifiers. These indications may be inter-dependent, and link identifiers. These indications may be inter-dependent,
since rate adjustment and detection algorithms are typically since rate adjustment and detection algorithms are typically
influenced by frame loss, and a "Link Down" indication may be influenced by frame loss, and a "Link Down" indication may be
influenced by the detection and search process. Link identifiers are influenced by the detection and search process. Link identifiers are
typically obtained in the process of bringing the link up. typically obtained in the process of bringing the link up.
1.4.1. Internet Layer
The Internet layer is the primary user of link indications, since one The Internet layer is the primary user of link indications, since one
of its functions is to shield applications from the specifics of link of its functions is to shield applications from the specifics of link
behavior. The Internet layer utilizes link indications in order to behavior. The Internet layer utilizes link indications in order to
to optimize aspects of IP configuration, routing and mobility. By to optimize aspects of IP configuration, routing, and mobility. By
validating and filtering link indications and selecting outgoing and validating and filtering link indications and selecting outgoing and
incoming interfaces based on routing metrics, the Internet layer incoming interfaces based on routing metrics, the Internet layer
enables upper layers to avoid dependency on link indications. enables upper layers to avoid dependency on link indications.
In "Detecting Network Attachment" [DNAv4], "Link Up" indications and In "Detecting Network Attachment" [DNAv4], "Link Up" indications and
link identifiers are used as hints for validating an existing IP link identifiers are used as hints for validating an existing IP
configuration. Once the IP configuration is confirmed, it may be configuration. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up" determined that an address change has occurred. However, "Link Up"
indications often do not result in a change to Internet layer indications often do not result in a change to Internet layer
configuration. configuration.
The routing sub-layer utilizes link indications in order to calculate The routing sub-layer utilizes link indications in order to calculate
routing metrics and determine changes in link state. As described in routing metrics and determine changes in link state. As described in
[Iannaccone], damping of link flaps and rate limiting of link state [Iannaccone], damping of link flaps and rate limiting of link state
advertisements are examples of how the routing sub-layer validates advertisements are examples of how the routing sub-layer validates
and filters link indications. and filters link indications.
"Fault Isolation and Recovery" [RFC826] describes how hosts interact Routing metrics incorporating link layer indications enable gateways
with gateways for the purpose of fault recovery: to obtain knowledge of path changes and take remote link conditions
into account for the purposes of route selection. When a link
Since the gateways always attempt to have a consistent and experiences frame loss, routing metrics incorporating frame loss such
correct model of the internetwork topology, the host strategy for as the metrics described in [ETX][ETX-Rate][ETX-Radio] increase,
fault recovery is very simple. Whenever the host feels that possibly resulting in selection of an alternate route. If a troubled
something is wrong, it asks the gateway for advice, and, link represents the only path to a prefix and the link experiences
assuming the advice is forthcoming, it believes the advice high frame loss ("down"), the route will be withdrawn or the metric
completely. The advice will be wrong only during the transient will become infinite. Similarly, when the link becomes operational,
period of negotiation, which immediately follows an outage, the route will appear again. Where routing protocol security is
but will otherwise be reliably correct. implemented, this information can be securely propagated.
In fact, it is never necessary for a host to explicitly ask
a gateway for advice, because the gateway will provide it as
appropriate.
Within "Weak End-System Model" implementations, changes in routing Within "Weak End-System Model" implementations, changes in routing
metrics and link state may result in a change in the outgoing metrics and link state may result in a change in the outgoing
interface for one or more transport connections. Routes may also be interface for one or more transport connections. Routes may also be
added or withdrawn, resulting in loss or gain of peer connectivity. added or withdrawn, resulting in loss or gain of peer connectivity.
However, link indications such as changes in link rate or frame loss However, link indications such as changes in link rate or frame loss
do not necessarily result in a change of outgoing interface. do not necessarily result in a change of outgoing interface.
The Internet layer may also become aware of path changes by other The Internet layer may also become aware of path changes by other
mechanisms, such as by running a routing protocol, receipt of a mechanisms, such as by running a routing protocol, receipt of a
Router Advertisement, dead gateway detection [RFC826] or a change in Router Advertisement, dead gateway detection [RFC816] or a change in
the IP TTL of received packets. A change in the outgoing interface the IP TTL of received packets. A change in the outgoing interface
may in turn influence the mobility sub-layer, causing a change in the may in turn influence the mobility sub-layer, causing a change in the
incoming interface. The mobility sub-layer may also become aware of incoming interface. The mobility sub-layer may also become aware of
a change in the incoming interface of a peer (via receipt of a Mobile a change in the incoming interface of a peer (via receipt of a Mobile
IP binding update). IP binding update).
1.4.2. Transport Layer
The Transport layer processes Internet layer and link indications The Transport layer processes Internet layer and link indications
differently for the purposes of transport parameter estimation and differently for the purposes of transport parameter estimation and
connection management. For the purposes of parameter estimation, the connection management. For the purposes of parameter estimation, the
Transport layer may be interested in a wide range of Internet and Transport layer may be interested in a wide range of Internet and
link layer indications. The Transport layer may wish to use path link layer indications. The Transport layer may wish to use path
change indications from the Internet layer in order to reset change indications from the Internet layer in order to reset
parameter estimates. It may also be useful for the Transport layer parameter estimates. It may also be useful for the Transport layer
to utilize link layer indications such as link rate, frame loss rate to utilize link layer indications such as link rate, frame loss rate
and "Link Up"/"Link Down" in order to improve transport parameter and "Link Up"/"Link Down" in order to improve transport parameter
estimates. estimates.
As described in Section A.3, the algorithms for improving transport As described in Section A.3, the algorithms for improving transport
parameter estimates using link layer indications are still under parameter estimates using link layer indications are still under
development. In transport parameter estimation, layering development. In transport parameter estimation, layering
considerations do not exist to the same extent as in connection considerations do not exist to the same extent as in connection
management. For example, the Internet layer may receive a "Link management. For example, the Internet layer may receive a "Link
Down" indication followed by a subsequent "Link Up" indication. This Down" indication followed by a subsequent "Link Up" indication. This
information may useful for transport parameter estimation even if IP information may be useful for transport parameter estimation even if
configuration does not change, since it may indicate the potential IP configuration does not change, since it may indicate the potential
for non-congestive packet loss during the period between the for non-congestive packet loss during the period between the
indications. indications.
For the purposes of connection management, the Transport layer For the purposes of connection management, the Transport layer
typically only utilizes Internet layer indications such as changes in typically only utilizes Internet layer indications such as changes in
the incoming/outgoing interface and IP configuration changes. For the incoming/outgoing interface and IP configuration changes. For
example, the Transport layer may tear down transport connections due example, the Transport layer may tear down transport connections due
to invalidation of a connection endpoint IP address. However, before to invalidation of a connection endpoint IP address. However, before
this can occur, the Internet layer must determine that a this can occur, the Internet layer must determine that a
configuration change has occurred. configuration change has occurred.
skipping to change at page 11, line 41 skipping to change at page 11, line 33
Even where the "Link Down" indication results from an explicit Even where the "Link Down" indication results from an explicit
exchange such as receipt of a PPP LCP-Terminate or an 802.11 exchange such as receipt of a PPP LCP-Terminate or an 802.11
Disassociate or Deauthenticate frame, an alternative point of Disassociate or Deauthenticate frame, an alternative point of
attachment may be available, allowing connectivity to be quickly attachment may be available, allowing connectivity to be quickly
restored. As a result, robustness is best achieved by allowing restored. As a result, robustness is best achieved by allowing
connections to remain up until an endpoint address changes, or the connections to remain up until an endpoint address changes, or the
connection is torn down due to lack of response to repeated connection is torn down due to lack of response to repeated
retransmission attempts. retransmission attempts.
For the purposes of connection management, the Transport layer is For the purposes of connection management, the Transport layer is
cautious even with the use of Internet layer indications. As noted cautious with the use of Internet layer indications. "Requirements
in [RFC826], Section 6: for Internet Hosts - Communication Layers" [RFC1122] [RFC1122]
Section 2.4 requires Destination Unreachable, Source Quench, Echo
Reply, Timestamp Reply and Time Exceeded ICMP messages to be passed
up to the transport layer. [RFC1122] 4.2.3.9 requires TCP to react
to an ICMP Source Quench by slowing transmission.
[RFC1122] Section 4.2.3.9 distinguishes between ICMP messages
indicating soft error conditions, which must not cause TCP to abort a
connection, and hard error conditions, which should cause an abort.
ICMP messages indicating soft error conditions include Destination
Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed),
which may result from routing transients; Time Exceeded; and
Parameter Problem. ICMP messages indicating hard error conditions
include Destination Unreachable codes 2 (Protocol Unreachable), 3
(Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment
was Set). Since hosts implementing "Path MTU Discovery" [RFC1191]
use Destination Unreachable code 4, they do not treat this as a hard
error condition.
However, "Fault Isolation and Recovery" [RFC816], Section 6 states:
It is not obvious, when error messages such as ICMP Destination It is not obvious, when error messages such as ICMP Destination
Unreachable arrive, whether TCP should abandon the connection. Unreachable arrive, whether TCP should abandon the connection.
The reason that error messages are difficult to interpret is The reason that error messages are difficult to interpret is
that, as discussed above, after a failure of a gateway or network, that, as discussed above, after a failure of a gateway or network,
there is a transient period during which the gateways may have there is a transient period during which the gateways may have
incorrect information, so that irrelevant or incorrect error incorrect information, so that irrelevant or incorrect error
messages may sometimes return. An isolated ICMP Destination messages may sometimes return. An isolated ICMP Destination
Unreachable may arrive at a host, for example, if a packet is sent Unreachable may arrive at a host, for example, if a packet is sent
during the period when the gateways are trying to find a new during the period when the gateways are trying to find a new
route. To abandon a TCP connection based on such a message route. To abandon a TCP connection based on such a message
arriving would be to ignore the valuable feature of the Internet arriving would be to ignore the valuable feature of the Internet
that for many internal failures it reconstructs its function that for many internal failures it reconstructs its function
without any disruption of the end points. without any disruption of the end points.
"Requirements for IP Version 4 Routers" [RFC1812] Section 4.3.3.3
states that "Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair) antidote to
congestion", indicating that routers should not originate them. In
general, since the Transport layer is able to determine an
appropriate (and conservative) response to congestion based on packet
loss or explicit congestion notification, ICMP "source quench"
indications are not needed, and the sending of additional "source
quench" packets during periods of congestion may be detrimental.
"ICMP attacks against TCP" [Gont] argues that accepting ICMP messages
based on a correct four-tuple without additional security checks is
ill-advised. For example, an attacker forging an ICMP hard error
message can cause one or more transport connections to abort. The
authors discuss a number of precautions, including mechanisms for
validating ICMP messages and ignoring or delaying response to hard
error messages under various conditions. They also recommend that
hosts ignore ICMP Source Quench messages.
1.4.3. Application Layer
In addition to Internet layer indications propagated to the In addition to Internet layer indications propagated to the
Application layer (such as IP address configuration and changes), the Application layer (such as IP address configuration and changes), the
Transport layer provides its own indications to the Application Transport layer provides its own indications to the Application
layer, such as connection teardown. The Transport layer may also layer, such as connection teardown. The Transport layer may also
provide indications to the link layer. For example, to prevent provide indications to the link layer. For example, to prevent
excessive retransmissions within the link layer, where the link layer excessive retransmissions within the link layer, where the link layer
retransmission timeout is significantly less than the path round-trip retransmission timeout is significantly less than the path round-trip
timeout, the Transport layer may wish to control the maximum number timeout, the Transport layer may wish to control the maximum number
of times that a link layer frame may be retransmitted, so that the of times that a link layer frame may be retransmitted, so that the
link layer does not continue to retransmit after a Transport layer link layer does not continue to retransmit after a Transport layer
timeout. In 802.11, this can be achieved by adjusting the MIB timeout.
variables dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit
(default: 4), which control the maximum number of retries for frames
shorter and longer in length than dot11RTSThreshold, respectively.
However, since these variables control link behavior as a whole they
cannot be used to separately adjust behavior on a per-transport
connection basis. Also, in situations where the link layer
retransmission timeout is of the same order as the path round trip
timeout, link layer control may not be possible at all.
Since applications can obtain the information they need from Internet
and Transport layer indications they should not utilize link
indications. A "Link Up" indication implies that the link is capable
of communicating IP packets, but does not indicate that it has been
configured. As a result, applications will should utilize an
Internet layer "IP Address Configured" event instead of a "Link Up"
indication. Similarly, applications should not utilize "Link Down"
indications, since they can be rapidly followed by a "Link Up"
indication; instead, they should respond to Transport layer teardown
indications.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+
| ! ! | | ! ! |
| ^ ^ | | ^ ^ |
skipping to change at page 14, line 4 skipping to change at page 14, line 4
! ! ! ^ ! ! ! ^
! ! ! ! ! ! ! !
+-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-!-+-+-+-+-+-+-+ +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-!-+-+-+-+-+-+-+
| ! ! ! ! | | ! ! ! ! |
Link | ^ ^ ^ ^ | Link | ^ ^ ^ ^ |
Layer | Frame Rate Link Link | Layer | Frame Rate Link Link |
| Loss Adjustment Up/Down Identifiers | | Loss Adjustment Up/Down Identifiers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model Figure 1. Layered Indication Model
In 802.11, this can be achieved by adjusting the MIB variables
dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default:
4), which control the maximum number of retries for frames shorter
and longer in length than dot11RTSThreshold, respectively. However,
since these variables control link behavior as a whole they cannot be
used to separately adjust behavior on a per-transport connection
basis. Also, in situations where the link layer retransmission
timeout is of the same order as the path round trip timeout, link
layer control may not be possible at all.
Since applications can obtain the information they need from Internet
and Transport layer indications they should not utilize link
indications. A "Link Up" indication implies that the link is capable
of communicating IP packets, but does not indicate that it has been
configured. As a result, applications should utilize an Internet
layer "IP Address Configured" event instead of a "Link Up"
indication. Similarly, applications should not utilize "Link Down"
indications, since they can be rapidly followed by a "Link Up"
indication; instead, they should respond to Transport layer teardown
indications.
2. Architectural Considerations 2. Architectural Considerations
While the literature provides persuasive evidence of utility of link While the literature provides persuasive evidence of the utility of
indications, difficulties can arise in making effective use of them. link indications, difficulties can arise in making effective use of
These include: them. To avoid these issues, the following architectural principles
are suggested and discussed in more detail in the sections that
follow:
a. Model validation [1] Proposals should avoid use of simplified link models in
b. Clear definitions circumstances where they do not apply (Section 2.1).
c. Robustness
d. Stability
e. Effectiveness
f. Interoperability
g. Race conditions
h. Layer compression
i. Transport of link indications
The sections that follow discuss each of these issues in turn. [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 misleading
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 advocating the transport of link indications beyond the
local host need to carefully consider the layering, security and
transport implications (Section 2.9). 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, are more
likely to be backward compatible, and are less likely to result in
security vulnerabilities.
2.1. Model Validation 2.1. Model Validation
Authors need to be careful to avoid use of simplified link models in Proposals should avoid use of simplified link models in circumstances
circumstances where they do not apply. where they do not apply.
In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
the authors provide examples of modeling mistakes and examples of how the authors provide examples of modeling mistakes and examples of how
to improve modeling of link characteristics. To accompany the paper to improve modeling of link characteristics. To accompany the paper
the authors provide simulation scenarios in ns-2. the authors provide simulation scenarios in ns-2.
In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], In order to avoid the pitfalls described in [Kotz] [GurtovFloyd],
documents dependent on link indications should explicitly articulate documents dependent on link indications should explicitly articulate
the assumptions of the link model and describe the circumstances in the assumptions of the link model and describe the circumstances in
which it applies. which it applies.
skipping to change at page 15, line 13 skipping to change at page 16, line 18
loss is well predicted by signal strength and distance. loss is well predicted by signal strength and distance.
However, where multi-path interference is present, signal strength However, where multi-path interference is present, signal strength
and signal/noise ratio can vary rapidly and high signal/noise ratio and signal/noise ratio can vary rapidly and high signal/noise ratio
can co-exist with high frame loss. Where links may exist in can co-exist with high frame loss. Where links may exist in
intermediate states between "up" and "down" or asymmetry is intermediate states between "up" and "down" or asymmetry is
encountered, a "Link Quality Crosses Threshold" indication may encountered, a "Link Quality Crosses Threshold" indication may
exhibit excessive jitter and may prove to be unreliable predictors of exhibit excessive jitter and may prove to be unreliable predictors of
future link performance. future link performance.
In particular, authors should be mindful of the following: 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.
Attempts have also been made to define link indications other than
"Link Up" and "Link Down". "Dynamically Switched Link Control
Protocol" [RFC1307] defines an experimental protocol for control of
links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring
Down" and "Bring Up" states.
[GenTrig] defines "generic triggers", including "Link Up", "Link
Down", "Link Going Down", "Link Going Up", "Link Quality Crosses
Threshold", "Trigger Rollback", and "Better Signal Quality AP
Available".
[IEEE-802.21] defines a Media Independent Handover Event Service
(MIH-ES) that provides event reporting relating to link
characteristics, link status, and link quality. Events defined
include "Link Down", "Link Up", "Link Going Down", "Link Signal
Strength" and "Link Signal/Noise Ratio".
Link indication definitions should head the following advice:
[1] Do not assume symmetric link performance or frame loss that is [1] Do not assume symmetric link performance or frame loss that is
either low ("up") or high ("down"). either low ("up") or high ("down").
In wired networks, links in the "up" state typically experience low In wired networks, links in the "up" state typically experience low
frame loss in both directions and are ready to send and receive frame loss in both directions and are ready to send and receive
data frames; links in the "down" state are unsuitable for sending data frames; links in the "down" state are unsuitable for sending
and receiving data frames in either direction. Therefore, a link and receiving data frames in either direction. Therefore, a link
providing a "Link Up" indication will typically experience low providing a "Link Up" indication will typically experience low
frame loss in both directions, and high frame loss in any direction frame loss in both directions, and high frame loss in any direction
skipping to change at page 15, line 38 skipping to change at page 17, line 19
Specifications utilizing a "Link Up" indication should not assume Specifications utilizing a "Link Up" indication should not assume
that receipt of this indication means that the link is experiencing that receipt of this indication means that the link is experiencing
symmetric link conditions or low frame loss in either direction. symmetric link conditions or low frame loss in either direction.
In general, a "Link Up" event should not be sent due to transient 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 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 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 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 the generation of a "Link Up" event as movement to an alternative
point of attachment is delayed. point of attachment is delayed.
2.2. Clear Definitions [2] Consider the sensitivity of link indications to transient link
conditions. Due to effects such as multi-path interference, signal
Once the network model is defined, considerable effort may be strength and signal/noise ratio may vary rapidly over a short
required to define the meaning of link indications and clarify their distance, causing rapid variations in frame loss and rate, and
usage on different link layers. For example, considerable work has jitter in link indications based on these metrics. This can create
been required in order to come up with the definitions of "Link Up" problems for upper layers that act on these indications without
and "Link Down", and to define when these indications are sent on sufficient damping.
various link layers.
Attempts have also been made to define link indications other than
"Link Up" and "Link Down". "Dynamically Switched Link Control
Protocol" [RFC1307] defines an experimental protocol for control of
links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring
Down" and "Bring Up" states.
[GenTrig] defines "generic triggers", including "Link Up", "Link
Down", "Link Going Down", "Link Going Up", "Link Quality Crosses
Threshold", "Trigger Rollback", and "Better Signal Quality AP
Available".
[IEEE-802.21] defines a Media Independent Handover Event Service
(MIH-ES) that provides event reporting relating to link
characteristics, link status, and link quality. Events defined
include "Link Down", "Link Up", "Link Going Down", "Link Signal
Strength" and "Link Signal/Noise Ratio".
Document authors defining new link indications should heed the [3] Where possible, design link indications with built-in damping. By
following advice: 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 either generated 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.
[2] Think carefully about the sensitivity of link indications to [4] Do not assume that a "Link Down" event will be sent at all, or that
transient link conditions. Due to effects such as multi-path if sent, that it will received in a timely way. A good link layer
interference, signal strength and signal/noise ratio may vary implementation will both rapidly detect connectivity failure (such
rapidly over a short distance, causing rapid variations in as by tracking missing Beacons) while sending a "Link Down" event
frame loss and rate, and jitter in link indications based on only when it concludes the link is unusable, not due to transient
these metrics. This can create problems for upper layers that frame loss.
act on these indications without sufficient damping.
[3] Where possible, design link indications with built-in damping. However, existing implementations often do not do a good job of
By design, the "Link Up" and "Link Down" events relate to detecting link failure. During a lengthy detection phase, a "Link
changes in the state of the link layer that make it able and Down" event is not sent by the link layer, yet IP packets cannot be
unable to communicate IP packets. These changes are either transmitted or received on the link. Initiation of a scan may be
generated by the link layer state machine based on link layer delayed so that the station cannot find another point of
exchanges (e.g. completion of the IEEE 802.11i four-way attachment. This can result in inappropriate backoff of
handshake for "Link Up", or receipt of a PPP LCP-Terminate for retransmission timers within the transport layer, among other
"Link Down") or by protracted frame loss, so that the link problems.
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.
2.3. Robustness 2.3. Robustness
In some situations, improper use of Link indications can result in Link indication proposals must demonstrate robustness against
operational malfunctions. Given the potential problems, proposals misleading indications. Elements to consider include:
for consideration of link indications must demonstrate robustness
against misleading indications. Elements to consider include:
a. Implementation effects a. Implementation Variation
b. Indication validation b. Recovery from invalid indications
c. Recovery from invalid indications c. Damping and hysteresis
d. Damping and hysteresis
2.3.1. Implementation Effects 2.3.1. Implementation Variation
Variations in link layer implementations may have a substantial Variations in link layer implementations may have a substantial
impact on the behavior of link indications. These variations need to impact on the behavior of link indications. These variations need to
be taken into account in evaluating the performance of proposals. be taken into account in evaluating the performance of proposals.
For example, Radio propagation and implementation differences can
Authors should consider the following advice: impact the reliability of Link indications.
[4] Do not assume that a "Link Down" event will be sent at all, or
that if sent, that it will 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 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.
2.3.2. Indication Validation
Radio propagation and implementation differences can impact the
reliability of Link indications.
As described in [Aguayo], wireless links often exhibit loss rates As described in [Aguayo], wireless links often exhibit loss rates
intermediate between "up" (low loss) and "down" (high loss) states, intermediate between "up" (low loss) and "down" (high loss) states,
as well as substantial asymmetry. In these circumstances, a "Link as well as substantial asymmetry. In these circumstances, a "Link
Up" indication may not imply bi-directional reachability. Also, a Up" indication may not imply bi-directional reachability. Also, a
reachability demonstration based on small packets may not mean that reachability demonstration based on small packets may not mean that
the link is suitable for carrying larger data packets. As a result, the link is suitable for carrying larger data packets. As a result,
"Link Up" and "Link Down" indications may not reliably determine "Link Up" and "Link Down" indications may not reliably determine
whether a link is suitable for carrying IP data packets. whether a link is suitable for carrying IP data packets.
skipping to change at page 18, line 30 skipping to change at page 19, line 19
Another example of link indication validation occurs in IPv4 Link- Another example of link indication validation occurs in IPv4 Link-
Local address configuration [RFC3927]. Prior to configuration of an Local address configuration [RFC3927]. Prior to configuration of an
IPv4 Link-Local address, it is necessary to run a claim and defend 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 protocol. Since a host needs to be present to defend its address
against another claimant, and address conflicts are relatively against another claimant, and address conflicts are relatively
likely, a host returning from sleep mode or receiving a "Link Up" likely, a host returning from sleep mode or receiving a "Link Up"
indication could encounter an address conflict were it to utilize a indication could encounter an address conflict were it to utilize a
formerly configured IPv4 Link-Local address without rerunning claim formerly configured IPv4 Link-Local address without rerunning claim
and defend. and defend.
2.3.3. Recovery From Invalid Indications 2.3.2. Recovery From Invalid Indications
Upper layers should utilize a timely recovery step so as to limit the In some situations, improper use of Link indications can result in
potential damage from link indications determined to be invalid after operational malfunctions. Upper layers should utilize a timely
they have been acted on. 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 Recovery is supported within [DNAv4] in the case where link
indications may lead a host to erroneously conclude that the link indications may lead a host to erroneously conclude that the link
prefix remains unchanged when the host has in fact changed networks. prefix remains unchanged when the host has in fact changed networks.
In this case, the bi-directional reachability test times out, and the In this case, the bi-directional reachability test times out, and the
host will eventually realize its mistake and obtain an IP address by host will eventually realize its mistake and obtain an IP address by
normal means. normal means.
Where a proposal involves recovery at the transport layer, the Where a proposal involves recovery at the transport layer, the
recovered transport parameters (such as the MTU, RTT, RTO, congestion recovered transport parameters (such as the MTU, RTT, RTO, congestion
skipping to change at page 19, line 13 skipping to change at page 20, line 5
implementation, it was observed that where mobile hosts changed their implementation, it was observed that where mobile hosts changed their
point of attachment more frequently than every five minutes, they point of attachment more frequently than every five minutes, they
would never obtain a routable address. would never obtain a routable address.
The problem was caused by an invalid link indication (signaling of The problem was caused by an invalid link indication (signaling of
"Link Up" prior to completion of link layer authentication), "Link Up" prior to completion of link layer authentication),
resulting in an initial failure to obtain a routable address using resulting in an initial failure to obtain a routable address using
DHCP. As a result, [RFC3927] recommends against modification of the DHCP. As a result, [RFC3927] recommends against modification of the
maximum retransmission timeout (64 seconds) provided in [RFC2131]. maximum retransmission timeout (64 seconds) provided in [RFC2131].
2.3.4. Damping and Hysteresis 2.3.3. Damping and Hysteresis
Damping and hysteresis can be utilized to ensure that stability is Damping and hysteresis can be utilized to limit damage from unstable
maintained in the face of jittery link indications. These limits link indications. This may include damping unstable indications or
typically place constraints on the number of times a given action can placing constraints on the frequency of link indication-induced
be performed within a time period or introduce damping mechanisms to actions within a time period.
prevent instability.
While [Aguayo] found that frame loss was relatively stable for While [Aguayo] found that frame loss was relatively stable for
stationary stations, obstacles to radio propagation and multi-path stationary stations, obstacles to radio propagation and multi-path
interference can result in rapid changes in signal strength for a interference can result in rapid changes in signal strength for a
mobile station. As a result, it is possible for mobile stations to mobile station. As a result, it is possible for mobile stations to
encounter rapid changes in link performance, including changes in the encounter rapid changes in link performance, including changes in the
negotiated rate, frame loss and even "Link Up"/"Link Down" negotiated rate, frame loss and even "Link Up"/"Link Down"
indications. indications.
Where link-aware routing metrics are implemented, this can result in Where link-aware routing metrics are implemented, this can result in
skipping to change at page 20, line 7 skipping to change at page 20, line 46
"Link Up" indication cannot necessarily conclude that it is "Link Up" indication cannot necessarily conclude that it is
appropriate to configure a IPv4 Link-Local address prior to appropriate to configure a IPv4 Link-Local address prior to
determining whether a DHCP server is available [RFC3927]. determining whether a DHCP server is available [RFC3927].
As noted in Section 1.4, the Transport layer does not utilize "Link As noted in Section 1.4, the Transport layer does not utilize "Link
Up" and "Link Down" indications for the purposes of connection Up" and "Link Down" indications for the purposes of connection
management. Since applications can obtain the information they need management. Since applications can obtain the information they need
from Internet and Transport layer indications they should not utilize from Internet and Transport layer indications they should not utilize
link indications. link indications.
2.4. Stability 2.4. Congestion Control
Link indication proposals must demonstrate that effective congestion Link indication proposals must demonstrate that effective congestion
control is maintained [RFC2914]. control is maintained [RFC2914]. One or more of the following
techniques may be utilized:
For example, algorithms that adjust rate based on frame loss need to [a] Rate limiting. Packets generated by the receipt of link
demonstrate conservatism in the face of congestion. The large indications can be rate limited (e.g. a limit of one packet per
variance in rate adaptation behavior of existing 802.11 end-to-end path RTO).
implementations is worrisome since implementations that rapidly
decrease the negotiated rate in response to frame loss can cause [b] Utilization of upper layer indications. Applications SHOULD
congestive collapse in the link layer, even where backoff is depend on upper layer indications such as IP address
correctly implemented. For example, an implementation that decreases configuration/change notification, rather than utilizing link
rate by a factor of two while backing off the retransmission timer by indications such as "Link Up".
a factor of two has not really reduced consumption of the critical
resource, namely available slots within the MAC. [c] Keepalives. Instead of utilizing a "Link Down" indication, an
application can utilize an application keepalive or Transport
layer indication such as connection teardown.
[d] Conservation of resources. Proposals must demonstrate that they
are not vulnerable to congestive collapse.
Note that congestion control is not solely an issue for the transport
layer, nor is "conservation of packets" sufficient to avoid
congestive collapse in all cases. Link layer algorithms that adjust
rate based on frame loss also need to demonstrate conservatism in the
face of congestion. For example, "Roaming Interval Measurements"
[Alimian] demonstrates that 802.11 implementations show wide
variation in rate adaptation behavior. This is worrisome, since
implementations that rapidly decrease the negotiated rate in response
to frame loss can cause congestive collapse in the link layer, even
where exponential backoff is implemented. For example, an
implementation that decreases rate by a factor of two while backing
off the retransmission timer by a factor of two has not reduced
consumption of available slots within the MAC. While such an
implementation might demonstrate "conservation of packets" it does
not conserve critical resources.
Consider a proposal where a "Link Up" indication is used by a host to Consider a proposal where a "Link Up" indication is used by a host to
trigger retransmission of the last previously sent packet, in order trigger retransmission of the last previously sent packet, in order
to enable ACK reception prior to expiration of the host's to enable ACK reception prior to expiration of the host's
retransmission timer. On a rapidly moving mobile node where "Link retransmission timer. On a rapidly moving mobile node where "Link
Up" indications follow in rapid succession, this could result in a Up" indications follow in rapid succession, this could result in a
burst of retransmitted packets, violating the principle of burst of retransmitted packets, violating the principle of
"conservation of packets". "conservation of packets".
At the Application Layer, Link indications have been utilized by At the Application Layer, Link indications have been utilized by
applications such as Presence [RFC2778] in order to optimize applications such as Presence [RFC2778] in order to optimize
registration and user interface update operations. For example, registration and user interface update operations. For example,
implementations may attempt presence registration on receipt of a implementations may attempt presence registration on receipt of a
"Link Up" indication, and presence de-registration by a surrogate "Link Up" indication, and presence de-registration by a surrogate
receiving a "Link Down" indication. receiving a "Link Down" indication. Presence implementations using
"Link Up"/"Link Down" indications this way violate the principle of
Presence implementations using "Link Up"/"Link Down" indications this "conservation of packets" when link indications are generated on a
way violate the principle of "conservation of packets" when link time scale less than the end-to-end path RTO. The problem is
indications are generated on a time scale of RTO or less. The magnified since for each presence update, notifications can be
problem is magnified since for each presence update, notifications delivered to many watchers. In addition, use of a "Link Up"
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 indication in this manner is unwise since the interface may not yet
have an operable Internet layer configuration. have an operable 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 utilizing a
"Link Up" indication, applications can instead depend on upper
layer indications such as an IP address configuration/change
notifications.
[c] Keepalives. Instead of utilizing a "Link Down" indication, an
application can utilize an application keepalive or Transport
layer indications such as connection teardown.
[d] Stability analysis. Proposals must be analyzed to determine
whether they result in congestive collapse either in the transport
layer or at the link layer.
2.5. Effectiveness 2.5. Effectiveness
While link indications may show promise, it may be difficult to prove Proposals must demonstrate the effectiveness of proposed
that processing of a given indication provides benefits in a wide optimizations. It may be difficult to prove that a given indication
variety of circumstances. Where link indications are utilized for provides benefits in a wide variety of circumstances. Since
the purpose of optimization, proposals need to carefully analyze the optimizations often carry a burden of increased complexity,
effectiveness of the optimizations in the face of unreliable link substantial performance improvement is required to make a compelling
indications. Since optimizations typically bring with them increased case.
complexity, an optimization that does not bring about a performance
improvement is not useful.
As with any optimization, the usefulness of link indications lies in
demonstrated effectiveness of the optimization under consideration.
This in turn may depend heavily on the penalty to be paid for false
positives and false negatives.
As noted in [DNAv4], it is simultaneously possible for a link In the face of unreliable link indications, effectiveness may depend
indication to be highly reliable and provide no net benefit, heavily on the penalty for false positives and false negatives. As
depending on the probability of a false indication and the penalty noted in [DNAv4], it is simultaneously possible for a link indication
paid for the false indication. In the case of [DNAv4], the benefits to be highly reliable and provide no net benefit, depending on the
of successful optimization are modest, but the penalty for falsely probability of a false indication and the penalty paid for the false
concluding that the network remains unchanged is a lengthy timeout. indication. In the case of [DNAv4], the benefits of successful
The result is that link indications may not be worth considering if optimization are modest, but the penalty for falsely concluding that
they are incorrect more than a small fraction of the time. the network remains unchanged is a lengthy timeout. The result is
that link indications may not be worth considering if they are
incorrect more than a small fraction of the time.
For example, it can be argued that a change in the Service Set For example, it can be argued that a change in the Service Set
Identifier (SSID) in [IEEE-802.11] is not a sufficiently reliable Identifier (SSID) in [IEEE-802.11] is not a sufficiently reliable
indication of a prefix change. Within IEEE 802.11, the Service Set indication of a prefix change. Within IEEE 802.11, the Service Set
Identifier (SSID) functions as a non-unique identifier of the Identifier (SSID) functions as a non-unique identifier of the
administrative domain of a Wireless LAN. Since the SSID is non- administrative domain of a Wireless LAN. Since the SSID is non-
unique, many different operators may share the same SSID, and Access unique, many different operators may share the same SSID, and Access
Points typically ship with a default value for the SSID (e.g. Points typically ship with a default value for the SSID (e.g.
"default"). Since the SSID relates to the administrative domain and "default"). Since the SSID relates to the administrative domain and
not the network topology, multiple SSIDs may provide access to the not the network topology, multiple SSIDs may provide access to the
skipping to change at page 22, line 20 skipping to change at page 23, line 8
discovering that the SSID has changed may have changed networks, or discovering that the SSID has changed may have changed networks, or
it may not have. Moreover, where private address space is in use, it 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 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 default gateway IP address to remain unchanged, yet for the host to
have moved to a different network. Were the host to make decisions have moved to a different network. Were the host to make decisions
relating to configuration of the IP layer (such as address relating to configuration of the IP layer (such as address
assignment) based solely on the SSID, address conflicts are likely. assignment) based solely on the SSID, address conflicts are likely.
2.6. Interoperability 2.6. Interoperability
In general, link indications should only be incorporated by upper Link indications should not be required by upper layers, in order to
layers for performance optimization, but should not be required in maintain link independence.
order to main link independence.
To avoid compromising interoperability in the pursuit of performance To avoid compromising interoperability in the pursuit of performance
optimization, proposals must demonstrate that interoperability optimization, proposals must demonstrate that interoperability
remains possible (though potentially with degraded performance) even remains possible (though potentially with degraded performance) even
if one or more participants do not implement the proposal. if one or more participants do not implement the proposal.
For example, if link layer prefix hints are provided as a substitute For example, if link layer prefix hints are provided as a substitute
for Internet layer configuration, hosts not understanding those hints for Internet layer configuration, hosts not understanding those hints
would be unable to obtain an IP address. would be unable to obtain an IP address.
Where link indications are proposed to optimize Internet layer Where link indications are proposed to optimize Internet layer
configuration, proposals must demonstrate that they do not compromise configuration, proposals must demonstrate that they do not compromise
robustness by interfering with address assignment or routing protocol robustness by interfering with address assignment or routing protocol
behavior, making address collisions more likely, or compromising behavior, making address collisions more likely, or compromising
Duplicate Address Detection (DAD). Duplicate Address Detection (DAD).
2.7. Race Conditions 2.7. Race Conditions
It is possible for link indications to be utilized directly by Link indication proposals should avoid race conditions, which can
multiple layers of the stack in situations in which strict layering occur where link indications are utilized directly by multiple layers
may not be observed. In these situations, it is possible for race of the stack.
conditions to occur.
For example, as discussed earlier, link indications have been shown Link indications are useful for optimization of Internet Protocol
to be useful in optimizing aspects of Internet Protocol layer layer addressing and configuration as well as routing. Although
addressing and configuration as well as routing. Although [Kim] [Kim] describes situations in which link indications are first
describes situations in which link indications are first processed by processed by the Internet Protocol layer (e.g. MIPv6) before being
the Internet Protocol layer (e.g. MIPv6) before being utilized by the utilized by the Transport layer, for the purposes of parameter
Transport layer, for the purposes of parameter estimation, it may be estimation, it may be desirable for the Transport layer to utilize
desirable for the Transport layer to utilize link indications link indications directly.
directly.
For example, in situations where the "Weak End-System Model" is In situations where the "Weak End-System Model" is implemented, a
implemented, a change of outgoing interface may occur at the same change of outgoing interface may occur at the same time the Transport
time the Transport layer is modifying transport parameters based on layer is modifying transport parameters based on other link
other link indications. As a result, transport behavior may differ indications. As a result, transport behavior may differ depending on
depending on the order in which the link indications are processed. the order in which the link indications are processed.
Where a multi-homed host experiences increasing frame loss on one of Where a multi-homed host experiences increasing frame loss on one of
its interfaces, a routing metric taking frame loss into account will its interfaces, a routing metric taking frame loss into account will
rise, potentially causing a change in the outgoing interface for one increase, potentially causing a change in the outgoing interface for
or more transport connections. This may trigger Mobile IP signaling one or more transport connections. This may trigger Mobile IP
so as to cause a change in the incoming path as well. As a result, signaling so as to cause a change in the incoming path as well. As a
the transport parameters for the original interface (MTU, congestion result, the transport parameters for the original interface (MTU,
state) may no longer be valid for the new outgoing and incoming congestion state) may no longer be valid for the new outgoing and
paths. incoming paths.
To avoid race conditions, the following measures are recommended: To avoid race conditions, the following measures are recommended:
a. Path change processing a. Path change processing
b. Layering b. Layering
c. Metric consistency c. Metric consistency
2.7.1. Path Change Processing 2.7.1. Path Change Processing
When the Internet layer detects a path change, such as a change in When the Internet layer detects a path change, such as a change in
skipping to change at page 24, line 11 skipping to change at page 24, line 44
layer independence, upper layers relying on Internet layer layer independence, upper layers relying on Internet layer
indications rather than consuming link indications directly can avoid indications rather than consuming link indications directly can avoid
link layer dependencies. link layer dependencies.
In general, it is advisable for applications to utilize indications In general, it is advisable for applications to utilize indications
from the Internet or Transport layers rather than consuming link from the Internet or Transport layers rather than consuming link
indications directly. indications directly.
2.7.3. Metric Consistency 2.7.3. Metric Consistency
Once a link is in the "up" state, its effectiveness in transmission Proposals should avoid inconsistencies between link and routing layer
of data packets can be determined. For example, frame loss may be metrics. Once a link is in the "up" state, its effectiveness in
used to assist in rate adjustment and to determine when to select an transmission of data packets can be determined. For example, frame
alternative point of attachment. Also, the effective throughput loss may be used to assist in rate adjustment and to determine when
depends on the negotiated rate and frame loss, and can be used in to select an alternative point of attachment. Also, the effective
calculation of the routing metric, as described in [ETX]. throughput depends on the negotiated rate and frame loss, and can be
used in calculation of the routing metric, as described in [ETX][ETX-
Rate][ETX-Radio].
However, prior to sending data packets over the link, other metrics However, prior to sending data packets over the link, other metrics
are required to determine suitability. As noted in [Shortest], a are required to determine suitability. As noted in [Shortest], a
link that can successfully transmit the short frames utilized for link that can successfully transmit the short frames utilized for
control, management or routing may not necessarily be able to control, management or routing may not necessarily be able to
reliably transport data packets. reliably transport data packets.
Since the negotiated rate and frame loss typically cannot be Since the negotiated rate and frame loss typically cannot be
predicted prior to utilizing the link for data traffic, existing predicted prior to utilizing the link for data traffic, existing
implementations often utilize metrics such as signal strength and implementations often utilize metrics such as signal strength and
skipping to change at page 25, line 16 skipping to change at page 25, line 52
due to good signal strength may subsequently exhibit significant due to good signal strength may subsequently exhibit significant
frame loss, and a low negotiated rate. Similarly, an AP frame loss, and a low negotiated rate. Similarly, an AP
demonstrating low utilization may not necessarily be the best choice, demonstrating low utilization may not necessarily be the best choice,
since utilization may be low due to hardware or software problems. since utilization may be low due to hardware or software problems.
[Villamizar] notes that link utilization-based routing metrics have a [Villamizar] notes that link utilization-based routing metrics have a
history of instability, so that they are rarely deployed. history of instability, so that they are rarely deployed.
2.8. Layer compression 2.8. Layer compression
In many situations, the exchanges required for a host to complete a In many situations, the exchanges required for a host to complete a
handoff and reestablish connectivity are considerable. This includes handoff and reestablish connectivity are considerable, leading to
link layer scanning, authentication and connectivity establishment; proposals to combine exchanges occurring within multiple layers in
Internet layer configuration, routing and mobility exchanges; order to reduce overhead. While overhead reduction is a laudable
Transport layer retransmission and recovery; security association re- goal, proposals need to avoid compromising interoperability and
establishment; application protocol re-authentication and re- introducing link layer dependencies into the Internet and Transport
registration exchanges, etc. It is therefore natural to consider layers.
combining exchanges occurring within multiple layers in order to
reduce overhead.
Often this combined exchange occurs within the link layer. For Exchanges required for handoff and connectivity reestablishment may
example, in [EAPIKEv2], a link layer EAP exchange may be used for the include link layer scanning, authentication and association
purpose of IP address assignment, potentially bypassing Internet establishment; Internet layer configuration, routing and mobility
exchanges; Transport layer retransmission and recovery; security
association re-establishment; application protocol re-authentication
and re-registration exchanges, etc.
Several proposals involve combining exchanges 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 layer configuration. Within [PEAP], it is proposed that a link layer
EAP exchange be used for the purpose of carrying Mobile IPv6 Binding EAP exchange be used for the purpose of carrying Mobile IPv6 Binding
Updates. [MIPEAP] proposes that EAP exchanges be used for Updates. [MIPEAP] proposes that EAP exchanges be used for
configuration of Mobile IPv6. configuration of Mobile IPv6. Where link, Internet or Transport
layer mechanisms are combined, hosts need to maintain backward
While the goals of layer compression are laudable, care needs to be compatibility to permit operation on networks where compression
taken to avoid compromising interoperability and introducing link schemes are not available.
layer dependencies into the Internet and Transport layers. For
example, 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 Layer compression schemes may also negatively impact robustness. For
example, in order to optimize IP address assignment, it has been example, in order to optimize IP address assignment, it has been
proposed that prefixes be advertised at the link layer, such as proposed that prefixes be advertised at the link layer, such as
within the 802.11 Beacon and Probe Response frames. However, within the 802.11 Beacon and Probe Response frames. However,
[IEEE-802.1X] enables the VLANID to be assigned dynamically, so that [IEEE-802.1X] enables the VLANID to be assigned dynamically, so that
prefix(es) advertised within the Beacon and/or Probe Response may not prefix(es) advertised within the Beacon and/or Probe Response may not
correspond to the prefix(es) configured by the Internet layer after correspond to the prefix(es) configured by the Internet layer after
the host completes link layer authentication. Were the host to the host completes link layer authentication. Were the host to
handle IP configuration at the link layer rather than within the handle IP configuration at the link layer rather than within the
Internet layer, the host might be unable to communicate due to Internet layer, the host might be unable to communicate due to
assignment of the wrong IP address. assignment of the wrong IP address.
2.9. Transport of Link Indications 2.9. Transport of Link Indications
Proposals including the transport of link indications beyond the Proposals including the transport of link indications need to
local host need to carefully consider the layering, security and carefully consider the layering, security and transport implications.
transport implications.
In general, implicit signals are preferred to explicit transport of In general, implicit signals are preferred to explicit transport of
link indications since they add no new packets in times of network link indications since they add no new packets in times of network
distress, operate more reliably in the presence of middle boxes such distress, operate more reliably in the presence of middle boxes such
as NA(P)Ts, and are more likely to be backward compatible. as NA(P)Ts, are more likely to be backward compatible, and are less
likely to result in security vulnerabilities.
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.
Routing metrics incorporating link layer indications enable gateways
to obtain knowledge of path changes and take remote link conditions
into account for the purposes of route selection. When a link
experiences frame loss, routing metrics incorporating frame loss such
as the metric described in [ETX] increase, possibly resulting in
selection of an alternate route. If a troubled link represents the
only path to a prefix and the link experiences high frame loss
("down"), the route will be withdrawn or the metric will become
infinite. Similarly, when the link becomes operational, the route
will appear again. Where routing protocol security is implemented,
this information can be securely propagated.
Where explicit signaling is required, existing facilities should be
used rather than creating new ones. "Fault Isolation and Recovery"
[RFC826] Section 3 describes how hosts can make use of ICMP messages:
In fact, it is never necessary for a host to explicitly ask a
gateway for advice, because the gateway will provide it as
appropriate. When a host sends a datagram to some distant net,
the host should be prepared to receive back either of two advisory
messages which the gateway may send. The ICMP "redirect" message
indicates that the gateway to which the host sent the datagram is
not longer the best gateway to reach the net in question. The
gateway will have forwarded the datagram, but the host should
revise its routing table to have a different immediate address
for this net. The ICMP "destination unreachable" message
indicates that as a result of an outage, it is currently
impossible to reach the addressed net or host in any manner. On
receipt of this message, a host can either abandon the connection
immediately without any further retransmission, or resend slowly
to see if the fault is corrected in reasonable time.
"TCP Extensions for Immediate Retransmissions" [Eggert] describes how
a Transport layer implementation may utilize existing "end-to-end
connectivity restored" indications.
Proposals involving transport of link indications need to demonstrate Proposals involving transport of link indications need to demonstrate
the following: the following:
[a] Absence of alternatives. By default, alternatives not requiring [a] Absence of alternatives. By default, alternatives not requiring
explicit signaling are preferred. Where these solutions are shown explicit signaling are preferred. Where these solutions are shown
to be inadequate, proposals must prove that existing explicit to be inadequate, proposals must prove that existing explicit
signaling mechanisms (such as path change processing and link- signaling mechanisms (such as path change processing and link-aware
aware routing metrics) are inadequate. routing metrics) are inadequate.
[b] Conservative behavior. Due to experience with ICMP "source [b] Mitigation of security issues. Proposals need to describe how
quench", proposals must demonstrate that they do not violate security issues can be addressed. A host receiving a link
conservation of packets. indication from a router typically will not be able to authenticate
the indication. Where indications can be transported over the
Internet, this allows an attack to be launched without requiring
access to the link.
[c] Security. Proposals need to describe how security issues can be [c] Validation of transported indications. Even if a transported link
addressed. Where link indications are transported over the indication can be authenticated, if the indication is sent by a
Internet, an attack can be launched without requiring access to host off the local link, it may not be clear that the sender is on
the link. 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] Identifiers. When link indications are transported, it is [d] Mapping of Identifiers. When link indications are transported, it
generally for the purposes of saying something about Internet, is generally for the purposes of saying something about Internet,
Transport or Application layer operations at a remote element. Transport or Application layer operations at a remote element.
These layers use different identifiers, and so it is necessary to These layers use different identifiers, and so it is necessary to
match the link indication with relevant higher layer state. match the link indication with relevant higher layer state.
Therefore proposals need to demonstrate how the link indication Therefore proposals need to demonstrate how the link indication can
can be mapped to the right higher layer state. be mapped to the right higher layer state. For example, if a
presence server is receiving remote indications of "Link Up"/"Link
For example, if a presence server is receiving remote indications Down" status for a particular MAC address, the presence server will
of "Link Up"/"Link Down" status for a particular MAC address, the need to associate that MAC address with the identity of the user
presence server will need to associate that MAC address with the (pres:user@example.com) to whom that link status change is
identity of the user (pres:user@example.com) to whom that link relevant.
status change is relevant.
3. Future Work 3. Future Work
While Figure 1 presents an overview of how link indications are While Figure 1 presents an overview of how link indications are
utilized by the Internet, Transport and Application layers, further utilized by the Internet, Transport and Application layers, further
work is needed to investigate this in more detail. work is needed in this area.
More work is needed in the area of link-aware routing metrics. For
example, since recent proposals such as [IEEE-802.11e] incorporate
burst ACKs, the relationship between 802.11 link throughput and frame
loss is growing more complex. This may necessitate the development
of revised routing metrics, taking the more complex retransmission
behavior into account, as well as the negotiated rate.
At the Link and Internet layers, more work is needed to reconcile pre At the Link and Internet layers, more work is needed to reconcile pre
and post-connection metrics, such as reconciling metrics utilized in and post-connection metrics, such as reconciling metrics utilized in
handoff (e.g. signal strength and link utilization) with link-aware handoff (e.g. signal strength and link utilization) with link-aware
routing metrics (e.g. frame loss and negotiated rate). routing metrics (e.g. frame loss and negotiated rate).
At the Transport layer, more work is needed to understand how to More work is also needed in the area of link-aware routing metrics.
react to Internet layer indications such as path changes. It may Since [IEEE-802.11e] incorporates burst ACKs, the relationship
also make sense for the Transport layer to adjust transport parameter between 802.11 link throughput and frame loss is growing more
estimates in response to "Link Up"/"Link Down" indications and frame complex. This may necessitate the development of revised routing
loss. For example, it is unclear that the Transport layer should metrics, taking the more complex retransmission behavior into
adjust transport parameters as though congestion were detected when account. More work is also needed in order to apply link-aware
loss is occurring in the link layer or a "Link Down" indication has routing metrics to host behavior.
been received.
At the Transport layer, more work is needed to determine the
appropriate reaction to Internet layer indications such as path
changes. For example, it may make sense for the Transport layer to
adjust transport parameter estimates in response to "Link Up"/"Link
Down" indications and frame loss, so that transport parameters are
not adjusted as though congestion were detected when loss is
occurring in the link layer or a "Link Down" indication has been
received.
Finally, more work is needed to determine how link layers may utilize Finally, more work is needed to determine how link layers may utilize
information from the Transport layer. For example, it is undesirable information from the Transport layer. For example, it is undesirable
for a link layer to retransmit so aggressively that the link layer for a link layer to retransmit so aggressively that the link layer
round-trip time approaches that of the end-to-end transport round-trip time approaches that of the end-to-end transport
connection. connection.
4. Security Considerations 4. Security Considerations
Since link indications are typically insecure, proposals Proposals for the utilization of link indications may introduce new
incorporating them need to consider the potential security security vulnerabilities. These include:
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 [IEEE-802.11F], "Link Up" is considered to occur Spoofing
when an Access Point sends a Reassociation Response. At that point, Indication validation
the AP sends a frame with the station's source address to a multicast Denial of service
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 [IEEE-802.11i]. As a result, link
indications as implemented in [IEEE-802.11F] enable an attacker to
disassociate a station located anywhere within the ESS, by sending a
Reassociation Request frame.
Another example of the potential security implications of link 4.1. Spoofing
indications occurs within DNAv4, where link indications are used for
optimization of IP configuration, rather than using a secured Where link layer control frames are unprotected, they may be spoofed
configuration mechanism such as authenticated DHCP [RFC3118], thereby by an attacker. For example, PPP does not protect LCP frames such as
increasing vulnerability to spoofing. LCP-Terminate, and 802.11 does not protect management frames such as
Associate/ Reasociate, Disassociate, or Deauthenticate.
Spoofing of link layer control traffic may enable attackers to
exploit weaknesses in link indication proposals. For example,
proposals that do not implement congestion avoidance can be enable
attackers to mount denial of service attacks.
However, even where the link layer incorporates security, attacks may
still be possible if the security model is not consistent. For
example, 802.11 wireless LANs implementing [IEEE-802.11i] do not
enable stations to send or receiving IP packets on the link until
completion of an authenticated key exchange protocol known as the
"4-way handshake". As a result, an 802.11 link utilizing
[IEEE-802.11i] cannot be considered usable at the Internet layer
("Link Up") until completion of the authenticated key exchange.
However, while [IEEE-802.11i] requires sending of authenticated
frames in order to obtain a "Link Up" indication, it does not support
management frame authentication. This weakness can be exploited by
attackers to enable denial of service attacks on stations attached to
distant Access Points (AP).
In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends
a Reassociation Response. At that point, the AP sends a spoofed
frame with the station's source address to a multicast address,
thereby causing switches within the Distribution System (DS) to learn
the station's MAC address. While this enables forwarding of frames
to the station at the new point of attachment, it also permits an
attacker to disassociate a station located anywhere within the ESS,
by sending an unauthenticated Reassociation Request frame.
4.2. Indication Validation
"Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts
interact with gateways for the purpose of fault recovery:
Since the gateways always attempt to have a consistent and
correct model of the internetwork topology, the host strategy for
fault recovery is very simple. Whenever the host feels that
something is wrong, it asks the gateway for advice, and,
assuming the advice is forthcoming, it believes the advice
completely. The advice will be wrong only during the transient
period of negotiation, which immediately follows an outage,
but will otherwise be reliably correct.
In fact, it is never necessary for a host to explicitly ask
a gateway for advice, because the gateway will provide it as
appropriate. When a host sends a datagram to some distant net,
the host should be prepared to receive back either of two advisory
messages which the gateway may send. The ICMP "redirect" message
indicates that the gateway to which the host sent the datagram is
no longer the best gateway to reach the net in question. The
gateway will have forwarded the datagram, but the host should
revise its routing table to have a different immediate address
for this net. The ICMP "destination unreachable" message
indicates that as a result of an outage, it is currently
impossible to reach the addressed net or host in any manner. On
receipt of this message, a host can either abandon the connection
immediately without any further retransmission, or resend slowly
to see if the fault is corrected in reasonable time.
Given today's security environment, it is inadvisable for hosts to
act on indications provided by gateways without careful
consideration. As noted in "ICMP attacks against TCP" [Gont],
existing ICMP error messages may be exploited by attackers in order
to abort connections in progress, prevent setup of new connections,
or reduce throughput of ongoing connections. Similar attacks may
also be launched against the Internet layer via forging of ICMP
redirects.
Proposals for transported link indications need to demonstrate that
they will not add a new set of similar vulnerabilities. Since
transported link indications are typically unauthenticated, hosts
receiving them may not be able to determine whether they are
authentic, or even plausible.
Where link indication proposals may respond to unauthenticated link
layer frames, they should be utilize upper layer security mechanisms,
where possible. For example, even though a host might utilize an
unauthenticated link layer control frame to conclude that a link has
become operational, it can use SEND [RFC3971] or authenticated DHCP
[RFC3118] in order to obtain secure Internet layer configuration.
4.3. Denial of Service
Link indication proposals need to be particular careful to avoid
enabling denial of service attacks that can mounted at a distance.
While wireless links are naturally vulnerable to interference, such
attacks can only be perpetrated by an attacker capable of
establishing radio contact with the target network.
However, attacks that can be mounted from a distance, either by an
attacker on another point of attachment within the same network, or
by an off-link attacker, greatly expand the level of vulnerability.
By enabling the transport of link indications, it is possible to
transform an attack that might otherwise be restricted to attackers
on the local link into one which can be executed across the Internet.
Similarly, by integrating link indications with upper layers,
proposals may enable a spoofed link layer frame to consume more
resources on the host than might otherwise be the case. As a result,
while it is important for upper layers to validate link indications,
they should not expend excessive resources in doing so.
Congestion control is not only a transport issue, it is also a
security issue. In order to not provide leverage to an attacker, a
single forged link layer frame should not elicit a magnified response
from one or more hosts, either by generating multiple responses or a
single larger response. For example, link indication proposals
should not enable multiple hosts to respond to a frame with a
multicast destination address.
5. References 5. References
5.1. Informative References 5.1. Informative References
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July 1982. [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July
1982.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
1988. June 1988.
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1989. [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link Control [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
Protocol", RFC 1307, March 1992. November 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
1661, July 1994. Control Protocol", RFC 1307, March 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
June 1995. RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. and [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
E. Lear, "Address Allocation for Private Internets", RFC 1918, 1812, June 1995.
February 1996.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
March 1997. 2131, March 1997.
[RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence [RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for
and Instant Messaging", RFC 2778, February 2000. Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion
Validation", RFC 2861, June 2000. Window Validation", RFC 2861, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP
September 2000. 41, September 2000.
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.
D. Gurle, "Session Initiation Protocol (SIP) Extension for and D. Gurle, "Session Initiation Protocol (SIP)
Instant Messaging", RFC 3428, December 2002. Extension for Instant Messaging", RFC 3428, December
2002.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
(XMPP): Instant Messaging and Presence", RFC 3921, October protocol (XMPP): Instant Messaging and Presence", RFC
2004. 3921, October 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
of Link-Local IPv4 Addresses", RFC 3927, May 2005. Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[Alimian] Alimian, A., "Roaming Interval Measurements", [Alimian] Alimian, A., "Roaming Interval Measurements",
11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 802.11 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE
submission (work in progress), March 2004. 802.11 submission (work in progress), March 2004.
[Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R. Morris, [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R.
"Link-level Measurements from an 802.11b Mesh Network", Morris, "Link-level Measurements from an 802.11b Mesh
SIGCOMM '04, September 2004, Portland, Oregon. Network", SIGCOMM '04, September 2004, Portland, Oregon.
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan, "Improving [Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan,
Performance of TCP over Wireless Networks", Proceedings of the "Improving Performance of TCP over Wireless Networks",
1997 International Conference on Distributed Computer Systems, Proceedings of the 1997 International Conference on
Baltimore, May 1997. Distributed Computer Systems, Baltimore, May 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
draft-ietf-bfd-base-02.txt, Internet draft (work in progress), Detection", draft-ietf-bfd-base-02.txt, Internet draft
March 2005. (work in progress), March 2005.
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses from [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses
Wireless Losses Using Interarrival Times at the Receiver", from Wireless Losses Using Interarrival Times at the
Proc. IEEE Symposium on Application-Specific Systems and Receiver", Proc. IEEE Symposium on Application-Specific
Software Engineering and Technology, Richardson, TX, Mar 1999. Systems and Software Engineering and Technology,
Richardson, TX, Mar 1999.
[Chandran] [Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R.
Chandran, K., Raghunathan, S., Venkatesan, S. and R. Prakash, Prakash, "A Feedback-Based Scheme for Improving TCP
"A Feedback-Based Scheme for Improving TCP Performance in Ad- Performance in Ad-Hoc Wireless Networks", Proceedings of
Hoc Wireless Networks", Proceedings of the 18th International the 18th International Conference on Distributed
Conference on Distributed Computing Systems (ICDCS), Computing Systems (ICDCS), Amsterdam, May 1998.
Amsterdam, May 1998.
[DCCP] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion [DCCP] Kohler, E., Handley, M. and S. Floyd, "Datagram
Control Protocol (DCCP)", Internet drafts (work in progress), Congestion Control Protocol (DCCP)", Internet drafts
draft-ietf-dccp-spec-08.txt, October 2004. (work in progress), draft-ietf-dccp-spec-08.txt, October
2004.
[DNAv4] Aboba, B., "Detection of Network Attachment in IPv4", draft- [DNAv4] Aboba, B., "Detection of Network Attachment in IPv4",
ietf-dhc-dna-ipv4-13.txt, Internet draft (work in progress), draft-ietf-dhc-dna-ipv4-14.txt, Internet draft (work in
June 2005. progress), August 2005.
[E2ELinkup] [E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-
Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-Up' Up' Notification", draft-dawkins-trigtran-linkup-01.txt,
Notification", draft-dawkins-trigtran-linkup-01.txt, Internet Internet draft (work in progress), October 2003.
draft (work in progress), October 2003.
[EAPIKEv2] [EAPIKEv2] Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2
Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2 Method", draft-tschofenig-eap-ikev2-05.txt, Internet
Method", draft-tschofenig-eap-ikev2-05.txt, Internet draft draft (work in progress), October 2004.
(work in progress), October 2004.
[Eckhardt] [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis
Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of of the Error Characteristics of an In-Building Wireless
the Error Characteristics of an In-Building Wireless Network", Network", SIGCOMM '96, August 1996, Stanford, CA.
SIGCOMM '96, August 1996, Stanford, CA.
[Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions for [Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions
Immediate Retransmissions", draft-eggert-tcpm-tcp-retransmit- for Immediate Retransmissions", draft-eggert-tcpm-tcp-
now-01.txt, Internet draft (work in progress), September 2004. retransmit-now-01.txt, Internet draft (work in progress),
September 2004.
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and
Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Robert Morris, "A High-Throughput Path Metric for Multi-
Routing", Proceedings of the 9th ACM International Conference Hop Wireless Routing", Proceedings of the 9th ACM
on Mobile Computing and Networking (MobiCom '03), San Diego, International Conference on Mobile Computing and
California, September 2003. Networking (MobiCom '03), San Diego, California,
September 2003.
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer [ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi-
Triggers", submission to IEEE 802.21 (work in progress), March radio, multi-hop wireless mesh networks", Proceedings of
2004, available at: ACM MobiCom Conference, September 2003.
[ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M. and M. Srivastava, "A
Radio Aware Routing Protocol for Wireless Mesh Networks",
UCLA Computer Science Department, Los Angeles, CA
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link
Layer Triggers", submission to IEEE 802.21 (work in
progress), March 2004, available at:
http://www.ieee802.org/handoff/march04_meeting_docs/ http://www.ieee802.org/handoff/march04_meeting_docs/
Generalized_triggers-02.pdf Generalized_triggers-02.pdf
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over
Wireless Links", Proceedings of TENCON'98, pages 332-335. Wireless Links", Proceedings of TENCON'98, pages 332-335.
IEEE, December 1998. IEEE, December 1998.
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers on [Gont] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-
Performance of TCP-Friendly Rate Control", to appear in ACM icmp-attacks-03.txt, Internet draft (work in progress),
MCCR, 2004. December 2004.
[GurtovFloyd] [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers
Gurtov, A. and S. Floyd, "Modeling Wireless Links for on Performance of TCP-Friendly Rate Control", to appear
Transport Protocols", Computer Communications Review (CCR) 34, in ACM MCCR, 2004.
2 (2003).
[HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation Protocol [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
(HMP)", draft-lee-hmp-00.txt, Internet draft (work in Transport Protocols", Computer Communications Review
progress), October 2003. (CCR) 34, 2 (2003).
[Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance over [HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation
Mobile Ad Hoc Networks", Proceedings of the Fifth Protocol (HMP)", draft-lee-hmp-00.txt, Internet draft
International Conference on Mobile Computing and Networking, (work in progress), October 2003.
pages 219-230. ACM/IEEE, Seattle, August 1999.
[Iannaccone] [Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance
Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S. and over Mobile Ad Hoc Networks", Proceedings of the Fifth
C. Diot, "Analysis of link failures in an IP backbone", Proc. International Conference on Mobile Computing and
of ACM Sigcomm Internet Measurement Workshop, November, 2002. Networking, pages 219-230. ACM/IEEE, Seattle, August
1999.
[IEEE-802.1X] [Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S.
Institute of Electrical and Electronics Engineers, "Local and and C. Diot, "Analysis of link failures in an IP
Metropolitan Area Networks: Port-Based Network Access backbone", Proc. of ACM Sigcomm Internet Measurement
Workshop, November, 2002.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X, December 2004. Control", IEEE Standard 802.1X, December 2004.
[IEEE-802.11] [IEEE-802.11] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "Wireless "Wireless LAN Medium Access Control (MAC) and Physical
LAN Medium Access Control (MAC) and Physical Layer (PHY) Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
Specifications", IEEE Standard 802.11, 2003.
[IEEE-802.11e] [IEEE-802.11e] Institute of Electrical and Electronics Engineers, "Draft
Institute of Electrical and Electronics Engineers, "Draft Amendment 7: Medium Access Control (MAC) Quality of
Amendment 7: Medium Access Control (MAC) Quality of Service Service (QoS) Enhancements", IEEE 802.11e Draft 10.0,
(QoS) Enhancements", IEEE 802.11e Draft 10.0, October 2004. October 2004.
[IEEE-802.11F] [IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE
Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access
Trial-Use Recommended Practice for Multi-Vendor Access Point Point Interoperability via an Inter-Access Point Protocol
Interoperability via an Inter-Access Point Protocol Across Across Distribution Systems Supporting IEEE 802.11
Distribution Systems Supporting IEEE 802.11 Operation", IEEE Operation", IEEE 802.11F, June 2003.
802.11F, June 2003.
[IEEE-802.11i] [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers, "Supplement "Supplement to Standard for Telecommunications and
to Standard for Telecommunications and Information Exchange Information Exchange Between Systems - LAN/MAN Specific
Between Systems - LAN/MAN Specific Requirements - Part 11: Requirements - Part 11: Wireless LAN Medium Access
Wireless LAN Medium Access Control (MAC) and Physical Layer Control (MAC) and Physical Layer (PHY) Specifications:
(PHY) Specifications: Specification for Enhanced Security", Specification for Enhanced Security", IEEE 802.11i, July
IEEE 802.11i, July 2004. 2004.
[IEEE-802.11k] [IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft
Institute of Electrical and Electronics Engineers, "Draft
Amendment to Telecommunications and Information Exchange Amendment to Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11: Between Systems - LAN/MAN Specific Requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Wireless LAN Medium Access Control (MAC) and Physical Layer Layer (PHY) Specifications - Amendment 7: Radio Resource
(PHY) Specifications - Amendment 7: Radio Resource
Management", IEEE 802.11k/D2.0, February 2005. Management", IEEE 802.11k/D2.0, February 2005.
[IEEE-802.21] [IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft
Institute of Electrical and Electronics Engineers, "Draft
Standard for Telecommunications and Information Exchange Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 21: Between Systems - LAN/MAN Specific Requirements - Part
Media Independent Handover", IEEE 802.21D0, June 2005. 21: Media Independent Handover", IEEE 802.21D0, June
2005.
[Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger
method for improving TCP performance over Mobile IPv6", draft- method for improving TCP performance over Mobile IPv6",
kim-tsvwg-butrigger-00.txt, Internet draft (work in progress), draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in
August 2004. progress), August 2004.
[Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms of [Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms
wireless-network research", Dartmouth College Computer Science of wireless-network research", Dartmouth College Computer
Technical Report TR2003-467, July 2003. Science Technical Report TR2003-467, July 2003.
[Krishnan] [Krishnan] Krishnan, R., Allman, M., Partridge, P. and J. Sterbenz,
Krishnan, R., Allman, M., Partridge, P. and J. Sterbenz, "Explicit Transport Error Notification (ETEN) for Error-
"Explicit Transport Error Notification (ETEN) for Error-Prone Prone Wireless and Satellite Networks", Technical Report
Wireless and Satellite Networks", Technical Report No. 8333, No. 8333, BBN Technologies, March 2002.
BBN Technologies, March 2002.
[Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics [Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics
Information for Mobile IP", draft-daniel-mip-link- Information for Mobile IP", draft-daniel-mip-link-
characteristic-01.txt, Internet draft (work in progress), characteristic-01.txt, Internet draft (work in progress),
April 2005. April 2005.
[Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for
TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1999. TCP/IP over GSM", Proceedings of IEEE Infocom '99, March
1999.
[MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. and M. [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J.
Laurent-Maknavicius, "MIPv6 Authorization and Configuration and M. Laurent-Maknavicius, "MIPv6 Authorization and
based on EAP", draft-giaretta-mip6-authorization-eap-02.txt, Configuration based on EAP", draft-giaretta-
Internet draft (work in progress), October 2004. mip6-authorization-eap-02.txt, Internet draft (work in
progress), October 2004.
[Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical
the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, Analysis of the IEEE 802.11 MAC Layer Handoff Process",
University of Maryland Department of Computer Science, CS-TR-4395, University of Maryland Department of Computer
September 2002. Science, September 2002.
[Mitani] Mitani, K., Shibui, R., Gogo, K. and F. Teraoka, "Unified L2 [Mitani] Mitani, K., Shibui, R., Gogo, K. and F. Teraoka, "Unified
Abstractions for L3-Driven Fast Handover", draft-koki-mobopts- L2 Abstractions for L3-Driven Fast Handover", draft-koki-
l2-abstractions-02.txt, Internet draft (work in progress), mobopts-l2-abstractions-02.txt, Internet draft (work in
February 2005. progress), February 2005.
[Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control -
802.11", draft-mun-mobileip-layer2-handoff-mipv4-01.txt, Buffer Requirements and Overload Performance", Technical
Internet draft (work in progress), March 2004. Memorandum, AT&T Bell Laaboratoies, October 1994.
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and S. [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4
Josefsson, "Protected EAP Protocol (PEAP) Version 2", draft- with 802.11", draft-mun-mobileip-layer2-handoff-
josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in mipv4-01.txt, Internet draft (work in progress), March
progress), October 2004. 2004.
[Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers Optimized [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.
Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", and S. Josefsson, "Protected EAP Protocol (PEAP) Version
draft-daniel-mip6-optimized-vertical-handover-00.txt, July 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet
2004. ,IP [PRNET] Jubin, J. and J. Tornow, "The DARPA packet draft (work in progress), October 2004.
radio network protocols", Proceedings of the IEEE, 75(1),
January 1987.
[Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff [Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers
for 802.11 Infrastructure Networks", Proceedings of the IEEE Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS
InfoCon 2005, March 2005. Example", draft-daniel-mip6-optimized-vertical-
handover-00.txt, July 2004. ,IP [PRNET] Jubin, J. and J.
Tornow, "The DARPA packet radio network protocols",
Proceedings of the IEEE, 75(1), January 1987.
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast
Disconnecting Networks", ACM SIGCOMM Computer Communication Handoff for 802.11 Infrastructure Networks", Proceedings
Review, 33(5), October 2003. of the IEEE InfoCon 2005, March 2005.
[Shortest] [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation
Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers for Disconnecting Networks", ACM SIGCOMM Computer
and Robert Morris, "Performance of Multihop Wireless Networks: Communication Review, 33(5), October 2003.
Shortest Path is Not Enough", Proceedings of the First
Workshop on Hot Topics in Networking (HotNets-I), Princeton,
New Jersey, October 2002.
[Swami] Swami, Y., Le, K., Eddy, W., "Lightweight Mobility Detection [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A.
and Response (LMDR) Algorithm for TCP", draft-swami-tcp- Chambers and Robert Morris, "Performance of Multihop
lmdr-05, Internet draft (work in progress), February 2005. 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] [Swami] Swami, Y., Le, K., Eddy, W., "Lightweight Mobility
Dawkins, S., Williams, C. and A. Yegin, "Framework and Detection and Response (LMDR) Algorithm for TCP", draft-
swami-tcp-lmdr-05, Internet draft (work in progress),
February 2005.
[TRIGTRAN] Dawkins, S., Williams, C. and A. Yegin, "Framework and
Requirements for TRIGTRAN", draft-dawkins-trigtran- Requirements for TRIGTRAN", draft-dawkins-trigtran-
framework-00.txt, Internet draft (work in progress), August framework-00.txt, Internet draft (work in progress),
2003. August 2003.
[Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover
performance and its effect on voice traffic", TRITA-IMIT- performance and its effect on voice traffic", TRITA-
TSLAB R 03:01, KTH Royal Institute of Technology, Stockholm, IMIT-TSLAB R 03:01, KTH Royal Institute of Technology,
Sweden, July 2003. Stockholm, Sweden, July 2003.
[Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
l2-triggers-00.txt, Internet Draft (work in progress), June l2-triggers-00.txt, Internet Draft (work in progress),
2002. June 2002.
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE
802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02,
Royal Institute of Technology, Stockholm, Sweden, April 2003. KTH Royal Institute of Technology, Stockholm, Sweden,
April 2003.
[Vertical] [Vertical] Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient
Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient Mobility Mobility Management for Vertical Handoff between WWAN and
Management for Vertical Handoff between WWAN and WLAN", IEEE WLAN", IEEE Communications Magazine, November 2003.
Communications Magazine, November 2003.
[Villamizar] [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)",
Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", draft- draft-ietf-ospf-omp-02.txt, Internet draft (work in
ietf-ospf-omp-02.txt, Internet draft (work in progress), progress), February 1999.
February 1999.
[Xylomenos] [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to
Xylomenos, G., "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links",
Enhancing Internet Performance over Wireless Links", Ph.D. Ph.D. thesis, University of California at San Diego,
thesis, University of California at San Diego, 1999. 1999.
Appendix A - Literature Review Appendix A - Literature Review
This Appendix summarizes the literature on utilization of link This Appendix summarizes the literature on utilization of link
indications within the Link, Internet, Transport and Application indications within the Link, Internet, Transport and Application
layers. layers.
A.1 Link Layer A.1 Link Layer
The characteristics of wireless links have been found to vary The characteristics of wireless links have been found to vary
skipping to change at page 42, line 17 skipping to change at page 44, line 17
In "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link In "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link
indications are utilized to enable a host that has moved to a new indications are utilized to enable a host that has moved to a new
point of attachment to rapidly confirm a currently operable point of attachment to rapidly confirm a currently operable
configuration, rather than utilizing the DHCP protocol [RFC2131]. configuration, rather than utilizing the DHCP protocol [RFC2131].
"A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX]
describes how routing metrics can be improved by taking link layer describes how routing metrics can be improved by taking link layer
frame loss rates into account, enabling the selection of routes frame loss rates into account, enabling the selection of routes
maximizing available throughput. While the proposed routing metric maximizing available throughput. While the proposed routing metric
utilizes the Expected Transmission Count (ETX), it does not take the utilizes the Expected Transmission Count (ETX), it does not take the
negotiated rate into account, although this was noted as a subject negotiated rate into account. In "Routing in multi-radio, multi-hop
for further study. 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
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. 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 data rate.
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
802.11/GPRS Example" [Park] the authors propose that the mobile node 802.11/GPRS Example" [Park] the authors propose that the mobile node
send a router solicitation on receipt of a "Link Up" indication in send a router solicitation on receipt of a "Link Up" indication in
order provide lower handoff latency than would be possible using order provide lower handoff latency than would be possible using
generic movement detection [RFC3775]. The authors also suggest generic movement detection [RFC3775]. The authors also suggest
immediate invalidation of the Care-Of-Address (CoA) on receipt of a immediate invalidation of the Care-Of-Address (CoA) on receipt of a
"Link Down" indication. However, this is problematic where a "Link "Link Down" indication. However, this is problematic where a "Link
Down" indication can be followed by a "Link Up" indication without a Down" indication can be followed by a "Link Up" indication without a
resulting change in IP configuration, such as is described in resulting change in IP configuration, such as is described in
skipping to change at page 45, line 20 skipping to change at page 47, line 28
its retransmission timer due to frame loss on a remote link can learn its retransmission timer due to frame loss on a remote link can learn
that the link has once again become operational. This enables that the link has once again become operational. This enables
retransmission to be attempted prior to expiration of the backed off retransmission to be attempted prior to expiration of the backed off
retransmission timer. retransmission timer.
"Link-layer Triggers Protocol" [Yegin] describes transport issues "Link-layer Triggers Protocol" [Yegin] describes transport issues
arising from lack of host awareness of link conditions on downstream arising from lack of host awareness of link conditions on downstream
Access Points and routers. Transport of link layer triggers is Access Points and routers. Transport of link layer triggers is
proposed to address the issue. proposed to address the issue.
In "TCP Extensions for Immediate Retransmissions" [Eggert], it is "TCP Extensions for Immediate Retransmissions" [Eggert], describes
proposed that in addition to regularly scheduled retransmissions that how a Transport layer implementation may utilize existing "end-to-end
retransmission be attempted by the Transport layer on receipt of an connectivity restored" indications. It is proposed that in addition
indication that connectivity to a peer node may have been restored. to regularly scheduled retransmissions that retransmission be
End-to-end connectivity restoration indications include "Link Up", attempted by the Transport layer on receipt of an indication that
confirmation of first-hop router reachability, confirmation of connectivity to a peer node may have been restored. End-to-end
Internet layer configuration, and receipt of other traffic from the connectivity restoration indications include "Link Up", confirmation
peer. of first-hop router reachability, confirmation of Internet layer
configuration, and receipt of other traffic from the peer.
In "Discriminating Congestion Losses from Wireless Losses Using In "Discriminating Congestion Losses from Wireless Losses Using
Interarrival Times at the Receiver" [Biaz], the authors propose a Interarrival Times at the Receiver" [Biaz], the authors propose a
scheme for differentiating congestive losses from wireless scheme for differentiating congestive losses from wireless
transmission losses based on interarrival times. Where the loss is transmission losses based on interarrival times. Where the loss is
due to wireless transmission rather than congestion, congestive due to wireless transmission rather than congestion, congestive
backoff and cwnd adjustment is omitted. However, the scheme appears backoff and cwnd adjustment is omitted. However, the scheme appears
to assume equal spacing between packets, which is not realistic in an to assume equal spacing between packets, which is not realistic in an
environment exhibiting link layer frame loss. The scheme is shown to environment exhibiting link layer frame loss. The scheme is shown to
function well only when the wireless link is the bottleneck, which is function well only when the wireless link is the bottleneck, which is
often the case with cellular networks, but not with IEEE 802.11 often the case with cellular networks, but not with IEEE 802.11
deployment scenarios such as home or hotspot use. deployment scenarios such as home or hotspot use.
In "Improving Performance of TCP over Wireless Networks" [Bakshi], In "Improving Performance of TCP over Wireless Networks" [Bakshi],
the authors focus on the performance of TCP over wireless networks the authors focus on the performance of TCP over wireless networks
with burst losses. The authors simulate performance of TCP Tahoe with burst losses. The authors simulate performance of TCP Tahoe
within ns-2, utilizing a two-state Markov model, representing "good" within ns-2, utilizing a two-state Markov model, representing "good"
and "bad" states. Where the receiver is connected over a wireless and "bad" states. Where the receiver is connected over a wireless
link, the authors simulate the effect of an Explicit Bad State link, the authors simulate the effect of an Explicit Bad State
Notification (EBSN) sent by a base station unable to reach the Notification (EBSN) sent by an access point unable to reach the
receiver. In response to an EBSN, it is advocated that the existing receiver. In response to an EBSN, it is advocated that the existing
retransmission timer be canceled and replaced by a new dynamically retransmission timer be canceled and replaced by a new dynamically
estimated timeout, rather than being backed off. In the simulations, estimated timeout, rather than being backed off. In the simulations,
EBSN prevents unnecessary timeouts, decreasing RTT variance and EBSN prevents unnecessary timeouts, decreasing RTT variance and
improving throughput. improving throughput.
In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc
Wireless Networks" [Chandran], the authors proposed an explicit Route Wireless Networks" [Chandran], the authors proposed an explicit Route
Failure Notification (RFN), allowing the sender to stop its Failure Notification (RFN), allowing the sender to stop its
retransmission timers when the receiver becomes unreachable. On retransmission timers when the receiver becomes unreachable. On
skipping to change at page 47, line 4 skipping to change at page 49, line 15
not have much of an effect on throughput, since the bandwidth/delay not have much of an effect on throughput, since the bandwidth/delay
of the network was only a few packets. However, resetting the RTO to of the network was only a few packets. However, resetting the RTO to
a high initial value (6 seconds) did have a substantial detrimental a high initial value (6 seconds) did have a substantial detrimental
effect, particularly at high speed. In terms of the probe packet effect, particularly at high speed. In terms of the probe packet
sent, the simulations showed little difference between sending the sent, the simulations showed little difference between sending the
first packet in the congestion window, or retransmitting the packet first packet in the congestion window, or retransmitting the packet
with the lowest sequence number among those signalled as lost via the with the lowest sequence number among those signalled as lost via the
ELFNs. ELFNs.
In "Improving TCP Performance over Wireless Links" [Goel], the In "Improving TCP Performance over Wireless Links" [Goel], the
authors propose use of an ICMP-DEFER message, sent by a wireless base authors propose use of an ICMP-DEFER message, sent by a wireless
station on failure of a transmission attempt. After exhaustion of access point on failure of a transmission attempt. After exhaustion
retransmission attempts, an ICMP-RETRANSMIT message is sent. On of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
receipt of an ICMP-DEFER message, the expiry of the retransmission receipt of an ICMP-DEFER message, the expiry of the retransmission
timer is postponed by the current RTO estimate. On receipt of an timer is postponed by the current RTO estimate. On receipt of an
ICMP-RETRANSMIT message, the segment is retransmitted. On ICMP-RETRANSMIT message, the segment is retransmitted. On
retransmission, the congestion window is not reduced; when coming out retransmission, the congestion window is not reduced; when coming out
of fast recovery, the congestion window is reset to its value prior of fast recovery, the congestion window is reset to its value prior
to fast retransmission and fast recovery. Using a two-state Markov to fast retransmission and fast recovery. Using a two-state Markov
model, simulated using ns-2, the authors show that the scheme model, simulated using ns-2, the authors show that the scheme
improves throughput. improves throughput.
In "Explicit Transport Error Notification (ETEN) for Error-Prone In "Explicit Transport Error Notification (ETEN) for Error-Prone
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/