draft-iab-link-indications-04.txt   draft-iab-link-indications-05.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-04.txt> <draft-iab-link-indications-05.txt>
20 December 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 32 skipping to change at page 1, line 30
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 June 22, 2006. This Internet-Draft will expire on January 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 ........................................... 5 1.3 Overview ........................................... 4
1.4 Layered Indication Model ........................... 6 1.4 Layered Indication Model ........................... 6
2. Architectural Considerations ............................. 12 2. Architectural Considerations ............................. 13
2.1 Model Validation ................................... 13 2.1 Model Validation ................................... 14
2.2 Clear Definitions .................................. 14 2.2 Clear Definitions .................................. 15
2.3 Robustness ......................................... 15 2.3 Robustness ......................................... 16
2.4 Congestion Control ................................. 19 2.4 Congestion Control ................................. 19
2.5 Effectiveness ...................................... 20 2.5 Effectiveness ...................................... 20
2.6 Interoperability ................................... 20 2.6 Interoperability ................................... 21
2.7 Race Conditions .................................... 21 2.7 Race Conditions .................................... 21
2.8 Layer Compression .................................. 23 2.8 Layer Compression .................................. 23
2.9 Transport of Link Indications ...................... 24 2.9 Transport of Link Indications ...................... 24
3. Future Work .............................................. 25 3. Future Work .............................................. 25
4. Security Considerations .................................. 26 4. Security Considerations .................................. 26
4.1 Spoofing ........................................... 26 4.1 Spoofing ........................................... 27
4.2 Indication Validation .............................. 26 4.2 Indication Validation .............................. 27
4.3 Denial of Service .................................. 28 4.3 Denial of Service .................................. 28
5. References ............................................... 28 5. References ............................................... 29
5.1 Informative References ............................. 28 5.1 Informative References ............................. 29
Appendix A - Literature Review ............................... 36 Appendix A - Literature Review ............................... 38
A.0 Terminology ........................................ 36 A.0 Terminology ........................................ 38
A.1 Link Layer ......................................... 36 A.1 Link Layer ......................................... 38
A.2 Internet Layer ..................................... 43 A.2 Internet Layer ..................................... 48
A.3 Transport Layer .................................... 45 A.3 Transport Layer .................................... 49
A.4 Application Layer .................................. 49 A.4 Application Layer .................................. 53
Appendix B - IAB Members ..................................... 49 Appendix B - IAB Members ..................................... 54
Intellectual Property Statement .............................. 49 Intellectual Property Statement .............................. 54
Disclaimer of Validity ....................................... 50 Disclaimer of Validity ....................................... 55
Copyright Statement .......................................... 50 Copyright Statement .......................................... 55
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. The complexity of
real-world link behavior poses a challenge to the integration of link
This document provides an overview of the role of link indications indications within the Internet architecture. While the judicious
within the Internet Architecture. While the judicious use of link use of link indications can provide performance benefits,
indications can provide performance benefits, experience has also inappropriate use can degrade both robustness and performance.
shown that that inappropriate use can degrade both robustness and
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 within the Internet, Transport
and Application layers.
In Section 1 describes the history of link indication usage within Section 1 describes the history of link indication usage within the
the Internet architecture and provides a model for the utilization of Internet architecture and provides a model for the utilization of
link indications. Section 2 describes the architectural link indications. Section 2 describes the architectural
considerations and provides advice to document authors. Section 3 considerations and provides advice to document authors. Section 3
describes recommendations and future work. Appendix A summarizes the describes recommendations and future work. Appendix A summarizes the
literature on link indications in wireless networks. literature on link indications in wireless local area networks.
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
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.
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
a layered network stack model, the Link layer (layer 2) is normally
below the Network (IP) layer (layer 3), and above the Physical
layer (layer 1). Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier.
Asymmetric link Asymmetric link
A link with transmission characteristics which are different A link with transmission characteristics which are different
depending upon the relative position or design characteristics of depending upon the relative position or design characteristics of
the transmitter and the receiver of data on the link. For the transmitter and the receiver of data on the link. For
instance, the range of one transmitter may be much higher than the instance, the range of one transmitter may be much higher than the
range of another transmitter on the same medium. range of another transmitter on the same medium.
Link Down Link Down
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 no longer being capable of associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss are communicating data frames; transient periods of high frame loss are
not sufficient. not sufficient.
Link Layer Link Layer
Conceptual layer of control or processing logic that is responsible Conceptual layer of control or processing logic that is responsible
for maintaining control of the data link. The data link layer for maintaining control of the link. The link layer functions
functions provide an interface between the higher-layer logic and provide an interface between the higher-layer logic and the link.
the data link. The link layer is the layer immediately below IP. The link layer is the layer immediately below IP.
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",
relevant information may include the current link rate, link relevant information may include the current link rate, link
identifiers (e.g. SSID, BSSID in 802.11), and link performance identifiers (e.g. SSID, BSSID in IEEE 802.11), and link performance
statistics (such as the delay or loss rate). statistics (such as the delay or frame 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.
Point of Attachment Point of Attachment
The endpoint on the link to which the host is currently connected. The endpoint on the link to which the host is currently connected.
Operable address Operable address
The term "operable address" refers to either a static address or a The term "operable address" refers to either a static address or a
dynamically assigned address which has not been relinquished, and dynamically assigned address which has not been relinquished, and
has not expired. 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 IPv4 address other than an IPv4 Link-Local address. This includes
includes private addresses as specified in [RFC1918]. private addresses as specified in "Address Allocation for Private
Internets" [RFC1918].
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 The integration of link indications with the Internet architecture
the ARPANET as early as 1969. In response to an attempt to send to a has a long history. Link status was first taken into account in
host that was off-line, the ARPANET link layer protocol provided a computer routing within the ARPANET as early as 1969. In response to
"Destination Dead" indication [RFC816]. The ARPANET packet radio an attempt to send to a host that was off-line, the ARPANET link
experiment [PRNET] incorporated frame loss in the calculation of layer protocol provided a "Destination Dead" indication [RFC816].
routing metrics, a precursor to more recent link-aware routing Link-aware routing metrics also have a long history; the ARPANET
metrics such as [ETX]. packet radio experiment [PRNET] incorporated frame loss in the
calculation of routing metrics, a precursor to more recent link-aware
routing metrics such as [ETX].
"Routing Information Protocol" [RFC1058] defines RIP, which is "Routing Information Protocol" [RFC1058] defines RIP, which is
descended from the Xerox Network Systems (XNS) Routing Information descended from the Xerox Network Systems (XNS) Routing Information
Protocol. "The Open Shortest Path First Specification" [RFC1131] Protocol. "The Open Shortest Path First Specification" [RFC1131]
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. While
noted in "Requirements for IP Version 4 Routers" [RFC1812]: these and other routing protocols can utilize "Link Up" and "Link
Down" indications provided by those links that support them, they
also can detect link loss based on loss of routing packets. As noted
in "Requirements for IP Version 4 Routers" [RFC1812]:
It is crucial that routers have workable mechanisms for 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.
In ideal conditions, links in the "up" state experience low frame 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".
Under 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.
frequently exhibit non-ideal behavior. Wired links may fail in half-
duplex mode, or exhibit partial impairment resulting in intermediate
loss rates. Wireless links may exhibit asymmetry or frame loss due
to interference or signal fading. In both wired and wireless links,
the link state may rapidly flap between the "up" and "down" states.
Routing protocol implementations have had to take real-world wired Unfortunately links frequently exhibit non-ideal behavior. Wired
link behavior into account in order to maintain robustness. In links may fail in half-duplex mode, or exhibit partial impairment
"Analysis of link failures in an IP backbone" [Iannaccone] the resulting in intermediate loss rates. Wireless links may exhibit
asymmetry or frame loss due to interference or signal fading. In
both wired and wireless links, the link state may rapidly flap
between the "up" and "down" states. This real world behavior
presents challenges to routing protocol implementations.
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
analyzes the causes of frame loss in a 38-node urban multi-hop IEEE
802.11 ad-hoc network. In most cases, links that are very bad in
one direction tend to be bad in both directions, and links that are
very good in one direction tend to be good in both directions.
However, 30 percent of links exhibited loss rates differing
substantially in each direction.
In "Analysis of link failures in an IP backbone" [Iannaccone] the
authors investigate link failures in Sprint's IP backbone. They authors investigate link failures in Sprint's IP backbone. They
identify the causes of convergence delay, including delays in identify the causes of convergence delay, including delays in
detection of whether an interface is down or up. While it is fastest detection of whether an interface is down or up. While it is fastest
for a router to utilize link indications if available, there are for a router to utilize link indications if available, there are
situations in which it is necessary to depend on loss of routing situations in which it is necessary to depend on loss of routing
packets to determine the state of the link. Once the link state has packets to determine the state of the link. Once the link state has
been determined, a delay may occur within the routing protocol in been determined, a delay may occur within the routing protocol in
order to dampen link flaps. Finally, another delay may be introduced order to dampen link flaps. Finally, another delay may be introduced
in propagating the link state change, in order to rate limit link in propagating the link state change, in order to rate limit link
state advertisements. state advertisements.
skipping to change at page 6, line 14 skipping to change at page 6, line 37
provide only limited failure indications, and that relatively slow provide only limited failure indications, and that relatively slow
"Hello" mechanisms are used in routing protocols to detect failures "Hello" mechanisms are used in routing protocols to detect failures
when no link layer indications are available. This results in when no link layer indications are available. This results in
failure detection times of the order of a second, which is too long failure detection times of the order of a second, which is too long
for some applications. The authors describe a mechanism that can be for some applications. The authors describe a mechanism that can be
used for liveness detection over any media, enabling rapid detection used for liveness detection over any media, enabling rapid detection
of failures in the path between adjacent forwarding engines. A path of failures in the path between adjacent forwarding engines. A path
is declared operational when bi-directional reachability has been is declared operational when bi-directional reachability has been
confirmed. confirmed.
The complexity of real-world link behavior poses a challenge to the
integration of link indications within the Internet architecture.
While the judicious use of link indications can provide performance
benefits, inappropriate use can degrade both robustness and
performance. This document provides guidance on the incorporation of
link indications within the Internet, Transport and Application
layers.
1.4. Layered Indication Model 1.4. Layered Indication Model
A layered indication model is shown in Figure 1 which includes both A layered indication model is shown in Figure 1 which includes both
internally generated link indications (such as link state and internally generated link indications (such as link state and
throughput) and indications arising from external interactions such throughput) and indications arising from external interactions such
path change detection. path change detection.
1.4.1. Internet Layer 1.4.1. Internet Layer
The Internet layer is the primary consumer of link indications, as The Internet layer is the primary consumer of link indications, as
one of its functions is to shield applications from the specifics of one of its functions is to shield applications from the specifics of
link behavior. This is accomplished by validating and filtering link link behavior. This is accomplished by validating and filtering link
indications and selecting outgoing and incoming interfaces based on indications and selecting outgoing and incoming interfaces based on
routing metrics. routing metrics.
The Internet layer utilizes link indications in order to optimize The Internet layer composes its routing table based on information
aspects of IP configuration, routing, and mobility. After receipt of available from local interfaces as well as potentially by taking into
a "Link Up" indication, potential IP configurations are validated account information provided by gateways. This enables the state of
using Detecting Network Attachment (DNA). Once the IP configuration the local routing table to reflect link conditions on both local and
is confirmed, it may be determined that an address change has remote links. For example, prefixes to be added or removed from the
occurred. However, "Link Up" indications often do not result in a routing table may be determined from DHCP [RFC2131][RFC3315], Router
change to Internet layer configuration. Advertisements [RFC1256][RFC2461], re-direct messages or even
transported link indications.
In "Detecting Network Attachment" [DNAv4], after receipt of a "link The Internet layer also utilizes link indications in order to
up" indication, potential IP configurations are validated using a optimize aspects of IP configuration and mobility. After receipt of
reachability test. In "Detecting Network Attachment in IPv6 - Best a "Link Up" indication, hosts validate potential IP configurations by
Current Practices for hosts" [DNAv6] IP configuration is validated Detecting Network Attachment (DNA). Once the IP configuration is
using reachability detection and Router Solicitation/ Advertisement. confirmed, it may be determined that an address change has occurred.
However, "Link Up" indications may not result in a change to Internet
layer configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network
Attachment in IPv6 - Best Current Practices for hosts" [DNAv6] IP
configuration is validated using reachability detection and Router
Solicitation/ Advertisement.
The routing sub-layer utilizes link indications in order to determine The routing sub-layer utilizes link indications in order to determine
changes in link state and calculate routing metrics. As described in changes in link state and calculate routing metrics. 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 may be required in order to guard against instability. advertisements may be required in order to guard against instability.
Link rate is often used in computing routing metrics. For wired Link rate is often used in computing routing metrics. For wired
networks, the rate is typically constant. However for wireless networks, the rate is typically constant. However for wireless
networks, the negotiated rate and frame loss may change with link networks, the negotiated rate and frame loss may change with link
conditions so that effective throughput may vary considerably over conditions so that effective throughput may vary considerably over
skipping to change at page 7, line 40 skipping to change at page 8, line 17
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S 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 is the size of the probe packet and B is the bandwidth of the link as
measured by packet pair [Morgan]. However, ETT assumed that the loss measured by packet pair [Morgan]. However, ETT assumed that the loss
fraction of small probe frames sent at 1 Mbps data rate is indicative fraction of small probe frames sent at 1 Mbps data rate is indicative
of the loss fraction of larger data frames at higher rates, which of the loss fraction of larger data frames at higher rates, which
tends to under-estimate the ETT at higher rates, where frame loss tends to under-estimate the ETT at higher rates, where frame loss
typically increases. In "A Radio Aware Routing Protocol for Wireless typically increases. In "A Radio Aware Routing Protocol for Wireless
Mesh Networks" [ETX-Radio] the authors refine the ETT metric further Mesh Networks" [ETX-Radio] the authors refine the ETT metric further
by estimating the loss fraction as a function of data rate. by estimating the loss fraction as a function of data rate.
Routing metrics incorporating link indications such as link up/down Routing metrics incorporating link indications such as Link Up/Down
and effective throughput enable gateways to obtain knowledge of path and effective throughput enable routers to take link conditions into
changes and take remote link conditions into account for the purposes account for the purposes of route selection. If a link experiences
of route selection. If a troubled link represents the only path to a decreased rate or high frame loss, the route metric will increase
prefix and the link experiences high frame loss ("down"), the route for the prefixes that it serves, encouraging use of alternate paths
will be withdrawn or the metric will become infinite. Similarly, if available. When the link condition improves, the route metric
when the link becomes operational, the route will appear again. will decrease, encouraging use of the link.
Where routing protocol security is implemented, this information can
be securely propagated.
Within "Weak End-System Model" implementations, changes in routing Within "Weak End-System Model" host implementations, changes in
metrics and link state may result in a change in the outgoing routing 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 [RFC816] or a change in Router Advertisement, dead gateway detection [RFC816] or network
unreachability detection [RFC2461], ICMP re-directs, 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 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. Changes in the routing table may also be useful
to utilize link layer indications such as effective throughput and in this regard; for example, loss of segments sent to a destination
"Link Up"/"Link Down" in order to improve transport parameter with no prefix in the routing table may be assumed to be due to
estimates. causes other than congestion. The Transport layer may also utilize
link layer indications such as rate, frame loss and "Link Up"/"Link
Down" in order to improve transport parameter estimates.
As described in Appendix A.3, the algorithms for improving transport As described in Appendix A.3, the algorithms for utilizing link layer
parameter estimates using link layer indications are still under indications to improve transport parameter estimates 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, where the host has no entry in its local
Down" indication followed by a subsequent "Link Up" indication. This routing table for a prefix, either because local link conditions
information may be useful for transport parameter estimation even if caused it be removed or because the route was withdrawn by a remote
IP configuration does not change, since it may indicate the potential gateway, the transport layer can conclude that loss of packets
for non-congestive packet loss during the period between the destined to that prefix are not due to congestion. However, the same
indications. information would not be of use for the purposes of connection
management, since it is desirable for connections to remain up during
transitory route flaps. Similarly, the Internet layer may receive a
"Link Down" indication followed by a subsequent "Link Up" indication.
This information may be useful for transport parameter estimation
even if IP configuration does not change, since it may indicates the
potential for non-congestive packet loss during the period between
the 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.
Nevertheless, the Transport layer does not respond to all Internet Nevertheless, the Transport layer does not respond to all Internet
skipping to change at page 9, line 17 skipping to change at page 9, line 50
teardown, since the configuration change is masked by the mobility teardown, since the configuration change is masked by the mobility
functionality within the Internet layer, and is therefore transparent functionality within the Internet layer, and is therefore transparent
to the Transport layer. to the Transport layer.
Just as a "Link Up" event may not result in a configuration change, Just as a "Link Up" event may not result in a configuration change,
and a configuration change may not result in connection teardown, the and a configuration change may not result in connection teardown, the
Transport layer does not tear down connections on receipt of a "Link Transport layer does not tear down connections on receipt of a "Link
Down" indication, regardless of the cause. Where the "Link Down" Down" indication, regardless of the cause. Where the "Link Down"
indication results from frame loss rather than an explicit exchange, indication results from frame loss rather than an explicit exchange,
the indication may be transient, to be soon followed by a "Link Up" the indication may be transient, to be soon followed by a "Link Up"
indication. indication. Similarly, changes in the routing table do not affect
connection teardown.
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 IEEE 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 with the use of Internet layer indications. "Requirements cautious with the use of Internet layer indications as well.
for Internet Hosts - Communication Layers" [RFC1122] [RFC1122] "Requirements for Internet Hosts - Communication Layers" [RFC1122]
Section 2.4 requires Destination Unreachable, Source Quench, Echo [RFC1122] Section 2.4 requires Destination Unreachable, Source
Reply, Timestamp Reply and Time Exceeded ICMP messages to be passed Quench, Echo Reply, Timestamp Reply and Time Exceeded ICMP messages
up to the transport layer. [RFC1122] 4.2.3.9 requires TCP to react to be passed up to the Transport layer. [RFC1122] 4.2.3.9 requires
to an ICMP Source Quench by slowing transmission. TCP to react to an ICMP Source Quench by slowing transmission.
[RFC1122] Section 4.2.3.9 distinguishes between ICMP messages [RFC1122] Section 4.2.3.9 distinguishes between ICMP messages
indicating soft error conditions, which must not cause TCP to abort a indicating soft error conditions, which must not cause TCP to abort a
connection, and hard error conditions, which should cause an abort. connection, and hard error conditions, which should cause an abort.
ICMP messages indicating soft error conditions include Destination ICMP messages indicating soft error conditions include Destination
Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed), Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed),
which may result from routing transients; Time Exceeded; and which may result from routing transients; Time Exceeded; and
Parameter Problem. ICMP messages indicating hard error conditions Parameter Problem. ICMP messages indicating hard error conditions
include Destination Unreachable codes 2 (Protocol Unreachable), 3 include Destination Unreachable codes 2 (Protocol Unreachable), 3
(Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment
skipping to change at page 11, line 5 skipping to change at page 11, line 34
propagating Internet layer indications (such as IP address propagating Internet layer indications (such as IP address
configuration and changes), as well as providing its own indications, configuration and changes), as well as providing its own indications,
such as connection teardown. The Transport layer may also provide such as connection teardown. The Transport layer may also provide
indications to the link layer. For example, where the link layer indications to the link layer. For example, 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. timeout.
In IEEE 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^ ^
! ! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+
| ! ! | | ! ! ! |
| ^ ^ | | ! ^ ^ |
| Connection Management ! Teardown | | ! Connection Management ! Teardown |
Transport | ! | Transport | ! ! |
Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ Layer +-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
| ! |
| Transport Parameter Estimation ! |
| Estimation (MTU, RTT, RTO, cwnd, ! ssthresh)
| ^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ !
! ! ! !
+-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! Incoming !MIP ! ! |
| ! Interface !BU ! ! |
| ! Change !Receipt! ! |
| ^ ^ ^ ^ |
Internet | ! Mobility ! ! ! |
Layer +-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! Outgoing ! Path ! ! |
| ! Interface ! Change! ! |
| ^ Change ^ ^ ^ |
| ! ! | | ! ! |
| Routing ! ! | | ! Transport Parameter ! |
| ! Estimation (MTU, RTT, ! |
| ! RTO, cwnd, bw, ssthresh) ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ !
! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! |
| ! ! Interface !BU ! ! |
| ! ! Change !Receipt! ! |
| ! ^ ^ ^ ^ |
Internet | ! ! Mobility ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! |
| ! ! Interface ! Change! ! |
| ! ^ Change ^ ^ ^ |
| ! ! ! |
| ! Routing ! ! |
| ^ ! ! | | ^ ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! ! IP | | ! ! ! IP |
| ! ! ! Address | | ! ! ! Address |
| ! IP Configuration ^ ^ Config/ | | ! IP Configuration ^ ^ Config/ |
| ! ! Changes | | ! ! Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
! ! ! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! | | ! ! |
Link | ^ ^ | Link | ^ ^ |
Layer | Effective Link | Layer | Rate, FER Link |
| Throughput (1/ETT) Up/Down | | Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model Figure 1. Layered Indication Model
In 802.11, this can be achieved by adjusting the MIB variables Since applications can frequently obtain the information they need
dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default: more reliably from the Internet and Transport layers they may not
4), which control the maximum number of retries for frames shorter need to utilize link indications. A "Link Up" indication implies
and longer in length than dot11RTSThreshold, respectively. However, that the link is capable of communicating IP packets, but does not
since these variables control link behavior as a whole they cannot be indicate that it has been configured; applications should use an
used to separately adjust behavior on a per-transport connection Internet layer "IP Address Configured" event instead. Similarly,
basis. Also, in situations where the link layer retransmission "Link Down" indications are typically not useful to applications,
timeout is of the same order as the path round trip timeout, link since they can be rapidly followed by a "Link Up" indication;
layer control may not be possible at all. applications should respond to Transport layer teardown
indications instead. However, there are circumstances in which
Since applications can obtain the information they need from the link indications can provide information to applications that is
Internet and Transport layers they should not utilize link not available in any other way. For example, there may be
indications. A "Link Up" indication implies that the link is capable situations in which a UDP-based video application may wish to
of communicating IP packets, but does not indicate that it has been utilize rate or frame loss information provided by the link layer
configured; applications should use an Internet layer "IP Address in order to adjust the codec [Haratcherev2]. Depending on how
Configured" event instead. Similarly, "Link Down" indications are routing metrics are calculated, equivalent information may not be
not useful to applications, since they can be rapidly followed by a available from the Internet layer.
"Link Up" indication; applications should respond to Transport layer
teardown indications instead.
2. Architectural Considerations 2. Architectural Considerations
While the literature provides persuasive evidence of the utility of While the literature provides persuasive evidence of the utility of
link indications, difficulties can arise in making effective use of link indications, difficulties can arise in making effective use of
them. To avoid these issues, the following architectural principles them. To avoid these issues, the following architectural principles
are suggested and discussed in more detail in the sections that are suggested and discussed in more detail in the sections that
follow: follow:
[1] Proposals should avoid use of simplified link models in [1] Proposals should avoid use of simplified link models in
skipping to change at page 13, line 22 skipping to change at page 14, line 19
[9] Proposals should avoid inconsistencies between link and routing [9] Proposals should avoid inconsistencies between link and routing
layer metrics (Section 2.7.3). Without careful design, potential layer metrics (Section 2.7.3). Without careful design, potential
differences between link indications used in routing and those used differences between link indications used in routing and those used
in roaming and/or link enablement can result in instability, in roaming and/or link enablement can result in instability,
particularly in multi-homed hosts. particularly in multi-homed hosts.
[10] Overhead reduction schemes must avoid compromising interoperability [10] Overhead reduction schemes must avoid compromising interoperability
and introducing link layer dependencies into the Internet and and introducing link layer dependencies into the Internet and
Transport layers (Section 2.8). Transport layers (Section 2.8).
[11] Proposals advocating the transport of link indications beyond the [11] Proposals for transport of link indications beyond the local host
local host need to carefully consider the layering, security and need to carefully consider the layering, security and transport
transport implications (Section 2.9). In general, implicit signals implications (Section 2.9).
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
Proposals should avoid use of link models in circumstances where they Proposals should avoid use of link models in circumstances where they
do not apply. do not apply.
In "The mistaken axioms of wireless-network research" [Kotz], the In "The mistaken axioms of wireless-network research" [Kotz], the
authors conclude that mistaken assumptions relating to link behavior authors conclude that mistaken assumptions relating to link behavior
may lead to the design of network protocols that may not work in may lead to the design of network protocols that may not work in
practice. For example, the authors note that the three-dimensional practice. For example, the authors note that the three-dimensional
skipping to change at page 14, line 6 skipping to change at page 14, line 47
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 that describe capabilities that are dependent on link documents that describe capabilities that are dependent on link
indications should explicitly articulate the assumptions of the link indications should explicitly articulate the assumptions of the link
model and describe the circumstances in which it applies. model and describe the circumstances in which it applies.
For example, generic "trigger" models often include implicit Generic "trigger" models may include implicit assumptions which may
assumptions which may prove invalid in outdoor or mesh deployments. prove invalid in outdoor or mesh deployments. For example, two-state
For example, two-state Markov models assume that the link is either Markov models assume that the link is either in a state experiencing
in a state experiencing low frame loss ("up") or in a state where few low frame loss ("up") or in a state where few frames are successfully
frames are successfully delivered ("down"). In these models, delivered ("down"). In these models, symmetry is also typically
symmetry is also typically assumed, so that the link is either "up" assumed, so that the link is either "up" in both directions or "down"
in both directions or "down" in both directions. In situations where in both directions. In situations where intermediate loss rates are
intermediate loss rates are experienced, these assumptions may be experienced, these assumptions may be invalid.
invalid.
Link indications based on signal quality (such as "Link Quality
Crosses Threshold") assume the absence of multi-path interference, so
that signal to noise ratio varies smoothly in space, and frame loss
is well predicted by signal strength and distance. However, where
multi-path interference is present, signal strength and signal/noise
ratio can vary rapidly and high signal/noise ratio can co-exist with
high frame loss. In these situation link indications based on signal
quality (such "Link Quality Crosses Threshold") may exhibit excessive
jitter and may prove to be unreliable predictors of future link
performance.
As a result, in situations where multi-path interference is present, As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev]
frame loss is more reliable indicator of link quality than signal signal strength data is noisy and sometimes inconsistent, so that it
strength. For example, "" [] compared signal strength and frame needs to be filtered in order to avoid erratic results. Given this,
loss metrics for use with the "Link Going Down" indication defined in link indications based on raw signal strength data may be unreliable.
[IEEE-802.21]. The authors found that where interference was In order to avoid problems, it is best to combine signal strength
present, indications based on frame loss were more robust. data with other techniques. For example, in developing a "Going
Down" indication for use with [IEEE-802.21] it would be advisable to
validate filtered signal strength measurements with other indications
of link loss such as lack of beacon reception.
2.2. Clear Definitions 2.2. Clear Definitions
Link indications should be clearly defined, so that it is understood Link indications should be clearly defined, so that it is understood
when they are generated on different link layers. For example, when they are generated on different link layers. For example,
considerable work has been required in order to come up with the considerable work has been required in order to come up with the
definitions of "Link Up" and "Link Down", and to define when these definitions of "Link Up" and "Link Down", and to define when these
indications are sent on various link layers. 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 heed the following advice: Link indication definitions should heed 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
skipping to change at page 15, line 38 skipping to change at page 16, line 4
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] Consider the sensitivity of link indications to transient link [2] Consider the sensitivity of link indications to transient link
conditions. Due to effects such as multi-path interference, signal conditions. Due to effects such as multi-path interference, signal
strength and signal/noise ratio may vary rapidly over a short strength and signal/noise ratio (SNR) may vary rapidly over a short
distance, causing rapid variations in frame loss and rate, and distance, causing erratic behavior of link indications based on
jitter in link indications based on these metrics. This can create unfiltered measurements. As noted in [Haratcherev], signal
problems for upper layers that act on these indications without strength may prove most useful when utilized in combination with
sufficient damping. other measurements, such as frame loss.
[3] Where possible, design link indications with built-in damping. By [3] Where possible, design link indications with built-in damping. By
design, the "Link Up" and "Link Down" events relate to changes in 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 the state of the link layer that make it able and unable to
communicate IP packets. These changes are either generated by the communicate IP packets. These changes are either generated by the
link layer state machine based on link layer exchanges (e.g. link layer state machine based on link layer exchanges (e.g.
completion of the IEEE 802.11i four-way handshake for "Link Up", or 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 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 frame loss, so that the link layer concludes that the link is no
longer usable. As a result, these link indications are typically longer usable. As a result, these link indications are typically
skipping to change at page 16, line 41 skipping to change at page 17, line 8
2.3.1. Implementation Variation 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 For example, Radio propagation and implementation differences can
impact the reliability of Link indications. 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. Depending on the link layer
Up" indication may not imply bi-directional reachability. Also, a exchanges required to generate a "Link Up" indication, receipt of
reachability demonstration based on small packets may not mean that this indication may not always imply that bi-directional reachability
the link is suitable for carrying larger data packets. As a result, has been demonstrated. For example, a "Link Up" indication could be
"Link Up" and "Link Down" indications may not reliably determine generated after the exchange of small frames at low rates, and this
whether a link is suitable for carrying IP data packets. may not imply bi-directional connectivity for large frames exchanged
at higher rates.
Where multi-path interference or hidden nodes are encountered, frame Where multi-path interference or hidden nodes are encountered, signal
loss may vary widely over a short distance. While techniques such as strength may vary widely over a short distance. Several techniques
use of multiple antennas may be used to reduce multi-path effects and may be used to reduce potential disruptions. Multiple antennas may
RTS/CTS signaling can be used to address hidden node problems, these be used to reduce multi-path effects; rate adaptation can be used to
techniques may not be completely effective. As a result, a mobile determine if a lower rate will be more satisfactory; transmit power
host may find itself experiencing widely varying link conditions, adjustment can be used to improve signal quality and reduce
causing the link to rapidly cycle between "up" and "down" states, interference; RTS/CTS signaling can be used to address hidden node
with "Going down" or "Going up" indications providing little problems. However, these techniques may not be completely effective.
predictive value. As a result, periods of high frame loss may be encountered, causing
the link to cycle between "up" and "down" states.
Where the reliability of a link layer indication is suspect, it is To improve robustness against spurious link indications, it is
best for upper layers to treat the indication as a "hint" (advisory recommended that upper layers treat the indication as a "hint"
in nature), rather than a "trigger" forcing a given action. In order (advisory in nature), rather than a "trigger" forcing a given action.
to provide increased robustness, heuristics can be developed to Upper layers may then attempt to validate the hint.
assist upper layers in determining whether the "hint" is valid or
should be discarded.
To provide robustness in the face of potentially misleading link In [RFC4436] "Link Up" indications are rate limited and IP
indications, in [DNAv4] "Link Up" indications are assumed to be configuration is confirmed using bi-directional reachability tests
inherently unreliable, so that bi-directional reachability needs to carried out coincident with a request for configuration via DHCP. As
be demonstrated as part of validating an IPv4 configuration. a result, bi-directional reachability is confirmed prior to
However, where a link exhibits an intermediate loss rate, the success activation of an IP configuration. However, where a link exhibits an
of the [DNAv4] reachability test does not guarantee that the link is intermediate loss rate, demonstration of bi-directional reachability
suitable for carrying IP data packets. may not necessarily indicate that the link is suitable for carrying
IP data packets.
Another example of link indication validation occurs in IPv4 Link- Another example of validation occurs in IPv4 Link-Local address
Local address configuration [RFC3927]. Prior to configuration of an configuration [RFC3927]. Prior to configuration of an IPv4 Link-
IPv4 Link-Local address, it is necessary to run a claim and defend Local address, it is necessary to run a claim and defend protocol.
protocol. Since a host needs to be present to defend its address Since a host needs to be present to defend its address against
against another claimant, and address conflicts are relatively another claimant, and address conflicts are relatively likely, a host
likely, a host returning from sleep mode or receiving a "Link Up" returning from sleep mode or receiving a "Link Up" indication could
indication could encounter an address conflict were it to utilize a encounter an address conflict were it to utilize a formerly
formerly configured IPv4 Link-Local address without rerunning claim configured IPv4 Link-Local address without rerunning claim and
and defend. defend.
2.3.2. Recovery From Invalid Indications 2.3.2. Recovery From Invalid Indications
In some situations, improper use of Link indications can result in In some situations, improper use of link indications can result in
operational malfunctions. Upper layers should utilize a timely operational malfunctions. It is recommended that upper layers
recovery step so as to limit the potential damage from link utilize a timely recovery step so as to limit the potential damage
indications determined to be invalid after they have been acted on. from link indications determined to be invalid after they have been
acted on.
In "Detecting Network Attachment" [DNAv4] reachability tests are In [RFC4436] reachability tests are carried out coincident with a
carried out coincident with a request for configuration via DHCP. request for configuration via DHCP. Therefore if the bi-directional
Therefore if the bi-directional reachability test times out, the host reachability test times out, the host can still obtain an IP
can still obtain an IP configuration via DHCP. configuration via DHCP, and if that fails, the host can still
continue to use an existing valid address if it has one.
Where a proposal involves recovery at the transport layer, the 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
window, etc.) must be demonstrated to remain valid. Congestion window, etc.) should be demonstrated to remain valid. Congestion
window validation is discussed in [RFC2861]. window validation is discussed in [RFC2861].
Where timely recovery is not supported, unexpected consequences may Where timely recovery is not supported, unexpected consequences may
result. As described in [RFC3927], early IPv4 Link-Local result. As described in [RFC3927], early IPv4 Link-Local
implementations would wait five minutes before attempting to obtain a implementations would wait five minutes before attempting to obtain a
routable address after assigning an IPv4 Link-Local address. In one routable address after assigning an IPv4 Link-Local address. In one
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.
skipping to change at page 18, line 47 skipping to change at page 19, line 18
result, it may be necessary to introduce route flap dampening. result, it may be necessary to introduce route flap dampening.
However, the benefits of damping need to be weighed against the However, the benefits of damping need to be weighed against the
additional latency that can be introduced. For example, in order to additional latency that can be introduced. For example, in order to
filter out spurious "Link Down" indications, these indications may be filter out spurious "Link Down" indications, these indications may be
delayed until it can be determined that a "Link Up" indication will delayed until it can be determined that a "Link Up" indication will
not follow shortly thereafter. However, in situations where multiple not follow shortly thereafter. However, in situations where multiple
Beacons are missed such a delay may not be needed, since there is no Beacons are missed such a delay may not be needed, since there is no
evidence of a suitable point of attachment in the vicinity. evidence of a suitable point of attachment in the vicinity.
In many cases it is desirable to ignore link indications entirely. In some cases it is desirable to ignore link indications entirely.
Since it is possible for a host to transition from an ad-hoc network Since it is possible for a host to transition from an ad-hoc network
to a network with centralized address management, a host receiving a to a network with centralized address management, a host receiving a
"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] or an
operable configuration is valid [RFC4436].
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.
from Internet and Transport layer indications they should not utilize
link indications.
2.4. Congestion Control 2.4. Congestion Control
Link indication proposals must demonstrate that effective congestion Link indication proposals must demonstrate that effective congestion
control is maintained [RFC2914]. One or more of the following control is maintained [RFC2914]. One or more of the following
techniques may be utilized: techniques may be utilized:
[a] Rate limiting. Packets generated by the receipt of link [a] Rate limiting. Packets generated based on receipt of link
indications can be rate limited (e.g. a limit of one packet per indications can be rate limited (e.g. a limit of one packet per
end-to-end path RTO). end-to-end path RTO).
[b] Utilization of upper layer indications. Applications should [b] Utilization of upper layer indications. Applications should
depend on upper layer indications such as IP address depend on upper layer indications such as IP address
configuration/change notification, rather than utilizing link configuration/change notification, rather than utilizing link
indications such as "Link Up". indications such as "Link Up".
[c] Keepalives. Instead of utilizing a "Link Down" indication, an [c] Keepalives. In order to improve robustness against spurious link
application can utilize an application keepalive or Transport indications, an application keepalive or Transport layer
layer indication such as connection teardown. indication (such as connection teardown) can be used instead of
consuming "Link Down" indications.
[d] Conservation of resources. Proposals must demonstrate that they [d] Conservation of resources. Proposals must demonstrate that they
are not vulnerable to congestive collapse. are not vulnerable to congestive collapse.
Note that congestion control is not solely an issue for the transport Note that "conservation of packets" may not be sufficient to avoid
layer, nor is "conservation of packets" sufficient to avoid link layer congestive collapse. Where rate adjustment is based on
congestive collapse in all cases. Link layer algorithms that adjust frame loss, it is necessary to demonstrative stability in the face of
rate based on frame loss also need to demonstrate conservatism in the congestion. Implementations that rapidly decrease the negotiated
face of congestion. For example, "Roaming Interval Measurements" rate in response to frame loss can cause congestive collapse in the
[Alimian] demonstrates that 802.11 implementations show wide link layer, even where exponential backoff is implemented. For
variation in rate adaptation behavior. This is worrisome, since example, an implementation that decreases rate by a factor of two
implementations that rapidly decrease the negotiated rate in response while backing off the retransmission timer by a factor of two has not
to frame loss can cause congestive collapse in the link layer, even reduced consumption of available slots within the MAC. While such an
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 implementation might demonstrate "conservation of packets" it does
not conserve critical resources. 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. Presence implementations using receiving a "Link Down" indication. Presence implementations using
"Link Up"/"Link Down" indications this way violate the principle of "Link Up"/"Link Down" indications this way violate the principle of
"conservation of packets" when link indications are generated on a "conservation of packets" since link indications can be generated on
time scale less than the end-to-end path RTO. The problem is a time scale less than the end-to-end path RTO. The problem is
magnified since for each presence update, notifications can be magnified since for each presence update, notifications can be
delivered to many watchers. In addition, use of a "Link Up" 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. even have an operable Internet layer configuration. Instead, an "IP
address configured" indication may be utilized.
2.5. Effectiveness 2.5. Effectiveness
Proposals must demonstrate the effectiveness of proposed Proposals must demonstrate the effectiveness of proposed
optimizations. Since optimizations typically carry a burden of optimizations. Since optimizations typically carry a burden of
increased complexity, substantial performance improvement is required increased complexity, substantial performance improvement is required
in order to make a compelling case. in order to make a compelling case.
In the face of unreliable link indications, effectiveness may In the face of unreliable link indications, effectiveness may
strongly depend on the penalty for false positives and false strongly depend on the penalty for false positives and false
negatives. In the case of [DNAv4], the benefits of successful negatives. In the case of [RFC4436], the benefits of successful
optimization are modest, but the penalty for being unable to confirm optimization are modest, but the penalty for being unable to confirm
an operable configuration is a lengthy timeout. As a result, the an operable configuration is a lengthy timeout. As a result, the
recommended strategy is to test multiple potential configurations in recommended strategy is to test multiple potential configurations in
parallel in addition to attempting configuration via DHCP. This parallel in addition to attempting configuration via DHCP. This
virtually guaranttees that DNAv4 will always result in performance virtually guaranttees that DNAv4 will always result in performance
equal to or better than use of DHCP alone. equal to or better than use of DHCP alone.
2.6. Interoperability 2.6. Interoperability
Link indications should not be required by upper layers, in order to While link indications can be utilized where available, they should
maintain link independence. not be required by upper layers, in order to maintain link layer
independence. For example, if link layer prefix hints are provided,
To avoid compromising interoperability in the pursuit of performance hosts not understanding those hints must still be able to obtain an
optimization, proposals must demonstrate that interoperability IP address.
remains possible (though potentially with degraded performance) even
if one or more participants do not implement the proposal.
For example, if link layer prefix hints are provided as a substitute
for Internet layer configuration, hosts not understanding those hints
would be unable to obtain an IP address.
Where link indications are proposed to optimize Internet layer 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).
To avoid compromising interoperability in the pursuit of performance
optimization, proposals must demonstrate that interoperability
remains possible (potentially with degraded performance) even if one
or more participants do not implement the proposal.
2.7. Race Conditions 2.7. Race Conditions
Link indication proposals should avoid race conditions, which can Link indication proposals should avoid race conditions, which can
occur where link indications are utilized directly by multiple layers occur where link indications are utilized directly by multiple layers
of the stack. of the stack.
Link indications are useful for optimization of Internet Protocol Link indications are useful for optimization of Internet Protocol
layer addressing and configuration as well as routing. Although layer addressing and configuration as well as routing. Although
[Kim] describes situations in which link indications are first [Kim] describes situations in which link indications are first
processed by the Internet Protocol layer (e.g. MIPv6) before being processed by the Internet Protocol layer (e.g. MIPv6) before being
utilized by the Transport layer, for the purposes of parameter utilized by the Transport layer, for the purposes of parameter
estimation, it may be desirable for the Transport layer to utilize estimation, it may be desirable for the Transport layer to utilize
link indications directly. link indications directly. Similarly, as noted in "Application-
oriented Link Adaptation of IEEE 802.11" [Haratcherev2] there are
situations in which applications may also wish to consume link
indications.
In situations where the "Weak End-System Model" is implemented, a In situations where the "Weak End-System Model" is implemented, a
change of outgoing interface may occur at the same time the Transport change of outgoing interface may occur at the same time the Transport
layer is modifying transport parameters based on other link layer is modifying transport parameters based on other link
indications. As a result, transport behavior may differ depending on indications. As a result, transport behavior may differ 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 or
its interfaces, a routing metric taking frame loss into account will decreased rate on one of its interfaces, a routing metric taking
increase, potentially causing a change in the outgoing interface for these effects into account will increase, potentially causing a
one or more transport connections. This may trigger Mobile IP change in the outgoing interface for one or more transport
signaling so as to cause a change in the incoming path as well. As a connections. This may trigger Mobile IP signaling so as to cause a
result, the transport parameters for the original interface (MTU, change in the incoming path as well. As a result, the transport
congestion state) may no longer be valid for the new outgoing and parameters for the original interface (MTU, congestion state) may no
incoming paths. longer be valid for the new outgoing and 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 re-estimation
b. Layering b. Layering
c. Metric consistency c. Metric consistency
2.7.1. Path Change Processing 2.7.1. Path Change Re-estimation
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
the outgoing or incoming interface of the host or the incoming the outgoing or incoming interface of the host or the incoming
interface of a peer, or perhaps a substantial change in the TTL of interface of a peer, or perhaps even a substantial change in the TTL
received IP packets, it may be worth considering whether to reset of received IP packets, it may be worth considering whether to reset
transport parameters (RTT, RTO, cwnd, MTU) to their initial values transport parameters (RTT, RTO, cwnd, MTU) to their initial values so
and allow them to be re-estimated. This ensures that estimates based as to allow them to be re-estimated. This ensures that estimates
on the former path do not persist after they have become invalid. based on the former path do not persist after they have become
Appendix A.3 summarizes the research on this topic. invalid. Appendix A.3 summarizes the research on this topic.
2.7.2. Layering 2.7.2. Layering
Another technique to avoid race conditions is to rely on layering to Another technique to avoid race conditions is to rely on layering to
damp transient link indications and provide greater link layer damp transient link indications and provide greater link layer
independence. independence.
The Internet layer is responsible for routing as well as IP The Internet layer is responsible for routing as well as IP
configuration, and mobility, providing higher layers with an configuration, and mobility, providing higher layers with an
abstraction that is independent of link layer technologies. Since abstraction that is independent of link layer technologies. Since
one of the major objectives of the Internet layer is maintaining link one of the major objectives of the Internet layer is maintaining link
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. However, this may not always be possible; for
example, a video codec may need to be responsive to changes in rate
provided by the link layer in order to optimize operation.
2.7.3. Metric Consistency 2.7.3. Metric Consistency
Proposals should avoid inconsistencies between link and routing layer Proposals should avoid inconsistencies between link and routing layer
metrics. Without careful design, potential differences between link metrics. Without careful design, potential differences between link
indications used in routing and those used in roaming and/or link indications used in routing and those used in roaming and/or link
enablement can result in instability, particularly in multi-homed enablement can result in instability, particularly in multi-homed
hosts. hosts.
Once a link is in the "up" state, its effectiveness in transmission Once a link is in the "up" state, its effectiveness in transmission
of data packets can be measured and used to determine an appropriate of data packets can be used to determine an appropriate routing
routing metric. For example, metrics described in [ETX][ETX- metric. However, prior to sending data packets over the link, the
Rate][ETX-Radio] represent the expected value of the reciprocal of appropriate routing metric may not be easily be predicted. As noted
throughput, which in turn is dependent on the negotiated rate and in [Shortest], a link that can successfully transmit the short frames
frame loss.
However, prior to sending data packets over the link, the expected
routing metric typically cannot easily be predicted. As noted in
[Shortest], a link that can successfully transmit the short frames
utilized for control, management or routing may not necessarily be utilized for control, management or routing may not necessarily be
able to reliably transport data packets. As a result, existing able to reliably transport larger data packets. The rate adaptation
implementations often utilize alternative metrics (such as signal techniques utilized in [Haratcherev] require data to be accumulated
strength or access point load) to assist in attachment/handoff on signal strength and rates based on successful and unsuccessful
decisions. For example, receipt of "Link Going Down" or "Link transmissions. However, this data will not available before a link
Quality Crosses Threshold" indications could be used as a signal to is used for the first time.
enable another interface.
However, unless the new interface is the preferred route for one or Therefore it may be necessary to utilize alternative metrics (such as
more destination prefixes, a "Weak End-System" implementation will signal strength or access point load) in order to assist in
not use the new interface for outgoing traffic. Where "idle timeout" attachment/handoff decisions. However, unless the new interface is
functionality is implemented, the unused interface will be brought the preferred route for one or more destination prefixes, a "Weak
down, only to be brought up again by the link enablement algorithm. End-System" implementation will not use the new interface for
outgoing traffic. Where "idle timeout" functionality is implemented,
the unused interface will be brought down, only to be brought up
again by the link enablement algorithm.
Within the link layer, frame loss may be used by a host to determine Within the link layer, signal strength and frame loss may be used by
the optimum rate, as well as to determine when to select an a host to determine the optimum rate, as well as to determine when to
alternative point of attachment. In order to enable stations to roam select an alternative point of attachment. In order to enable
prior to encountering packet loss, studies such as [Vatn] have stations to roam prior to encountering packet loss, studies such as
suggested using signal strength as a mechanism for detecting loss of [Vatn] have suggested using signal strength as a mechanism for more
connectivity, rather than frame loss, as suggested in [Velayos]. rapidly detecting loss of connectivity, rather than frame loss, as
[Vertical] proposes use of signal strength and link utilization in suggested in [Velayos].
order to optimize vertical handoff and demonstrates improved TCP
throughput.
[Aguayo] notes that signal strength and distance are not good [Aguayo] notes that signal strength and distance are not good
predictors of frame loss or negotiated rate, due to the potential predictors of frame loss or negotiated rate, due to the potential
effects of multi-path interference. As a result a link brought up effects of multi-path interference. As a result a link brought up
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.
skipping to change at page 24, line 14 skipping to change at page 24, line 31
Updates. [MIPEAP] proposes that EAP exchanges be used for Updates. [MIPEAP] proposes that EAP exchanges be used for
configuration of Mobile IPv6. Where link, Internet or Transport configuration of Mobile IPv6. Where link, Internet or Transport
layer mechanisms are combined, hosts need to maintain backward layer mechanisms are combined, hosts need to maintain backward
compatibility to permit operation on networks where compression compatibility to permit operation on networks where compression
schemes are not available. 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 Virtual LAN Identifier (VLANID) to be
prefix(es) advertised within the Beacon and/or Probe Response may not assigned dynamically, so that prefix(es) advertised within the Beacon
correspond to the prefix(es) configured by the Internet layer after and/or Probe Response may not correspond to the prefix(es) configured
the host completes link layer authentication. Were the host to by the Internet layer after the host completes link layer
handle IP configuration at the link layer rather than within the authentication. Were the host to handle IP configuration at the link
Internet layer, the host might be unable to communicate due to layer rather than within the Internet layer, the host might be unable
assignment of the wrong IP address. to communicate due to 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 need to Proposals for the transport of link indications need to carefully
carefully consider the layering, security and transport implications. consider the layering, security and transport implications.
In general, implicit signals are preferred to explicit transport of
link indications since they add no new packets in times of network As noted earlier, the transport layer may take the state of the local
distress, operate more reliably in the presence of middle boxes such routing table into account in improving the quality of transport
as NA(P)Ts, are more likely to be backward compatible, and are less parameter estimates. For example, by utilizing the local routing
likely to result in security vulnerabilities. table, the Transport layer can determine that segment loss was due to
loss of a route, not congestion. While this enables transported link
indications that affect the local routing table to improve the
quality of transport parameter estimates, security and
interoperability considerations relating to routing protocols still
apply.
Proposals involving transport of link indications need to demonstrate Proposals involving transport of link indications need to demonstrate
the following: the following:
[a] Absence of alternatives. By default, alternatives not requiring [a] Superiority to implicit signals. In general, implicit signals are
explicit signaling are preferred. Where these solutions are shown preferred to explicit transport of link indications since they do
to be inadequate, proposals must prove that existing explicit not require participation in the routing mesh, add no new packets
signaling mechanisms (such as path change processing and link-aware in times of network distress, operate more reliably in the presence
routing metrics) are inadequate. of middle boxes such as NA(P)Ts, are more likely to be backward
compatible, and are less likely to result in security
vulnerabilities. As a result, explicit signalling proposals must
prove that implicit signals are inadequate.
[b] Mitigation of security issues. Proposals need to describe how [b] Mitigation of security vulnerabilities. Transported link
security issues can be addressed. Unless schemes such as SEND indications that modify the local routing table represent routing
[RFC3971] are used, a host receiving a link indication from a protocols, and unless security is provided they will introduce the
router will not be able to authenticate the indication. Where vulnerabilities associated with unsecured routing protocols. For
indications can be transported over the Internet, this allows an example, unless schemes such as SEND [RFC3971] are used, a host
attack to be launched without requiring access to the link. receiving a link indication from a router 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] Validation of transported indications. Even if a transported link [c] Validation of transported indications. Even if a transported link
indication can be authenticated, if the indication is sent by a indication can be authenticated, if the indication is sent by a
host off the local link, it may not be clear that the sender is on host off the local link, it may not be clear that the sender is on
the actual path in use, or which transport connection(s) the the actual path in use, or which transport connection(s) the
indication relates to. Proposals need to describe how the indication relates to. Proposals need to describe how the
receiving host can validate the transported link indication. receiving host can validate the transported link indication.
[d] Mapping of Identifiers. When link indications are transported, it [d] Mapping of Identifiers. When link indications are transported, it
is generally for the purposes of saying something about Internet, is generally for the purposes of saying something about Internet,
skipping to change at page 25, line 22 skipping to change at page 25, line 50
Therefore proposals need to demonstrate how the link indication can Therefore proposals need to demonstrate how the link indication can
be mapped to the right higher layer state. For example, if a be mapped to the right higher layer state. For example, if a
presence server is receiving remote indications of "Link Up"/"Link presence server is receiving remote indications of "Link Up"/"Link
Down" status for a particular MAC address, the presence server will Down" status for a particular MAC address, the presence server will
need to associate that MAC address with the identity of the user need to associate that MAC address with the identity of the user
(pres:user@example.com) to whom that link status change is (pres:user@example.com) to whom that link status change is
relevant. relevant.
3. Future Work 3. Future Work
While Figure 1 presents an overview of how link indications are Further work is needed in order to understand how link indications
utilized by the Internet, Transport and Application layers, further can be utilized by the Internet, Transport and Application layers.
work is needed in this area.
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
and post-connection metrics, such as reconciling metrics utilized in handoff metrics (e.g. signal strength and link utilization) with
handoff (e.g. signal strength and link utilization) with link-aware routing metrics based on link indications (e.g. frame loss and
routing metrics (e.g. frame loss and negotiated rate). negotiated rate).
More work is also needed in the area of link-aware routing metrics. More work is also needed to understand the connection between link
Since [IEEE-802.11e] incorporates burst ACKs, the relationship indications and routing metrics. For example, the introduction of
between 802.11 link throughput and frame loss is growing more block ACKs (supported in [IEEE-802.11e]) complicates the relationship
complex. This may necessitate the development of revised routing between effective throughput and frame loss, which may necessitate
metrics, taking the more complex retransmission behavior into the development of revised routing metrics for adhoc networks.
account. More work is also needed in order to apply link-aware
routing metrics to host behavior. A better understanding of the relationship between rate negotiation
algorithms and link-layer congestion control is required. For
example, it is possible that SNR measurements may be useful in
preventing rapid downward rate negotiation (and congestive collapse)
in situations where frame loss is caused by congestion, not signal
attenuation.
At the Transport layer, more work is needed to determine the At the Transport layer, more work is needed to determine the
appropriate reaction to Internet layer indications such as path appropriate reaction to Internet layer indications such as routing
changes. For example, it may make sense for the Transport layer to table and path changes. For example, it may make sense for the
adjust transport parameter estimates in response to "Link Up"/"Link Transport layer to adjust transport parameter estimates in response
Down" indications and frame loss, so that transport parameters are to route loss, "Link Up"/"Link Down" indications and/or frame loss.
not adjusted as though congestion were detected when loss is This way transport parameters are not adjusted as though congestion
occurring in the link layer or a "Link Down" indication has been were detected when loss is occurring due to other factors such as
received. radio propagation effects or loss of a route (such as can occur on
receipt of a "Link Down" indication).
Finally, more work is needed to determine how link layers may utilize 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. Instead, it may make sense to do downward rate
adjustment so as to decrease frame loss and improve latency. Also,
in some cases, the transport layer may not require heroic efforts to
avoid frame loss; timely delivery may be preferred instead.
More work is also needed on application layer uses of link
indications such as rate and frame loss.
4. Security Considerations 4. Security Considerations
Proposals for the utilization of link indications may introduce new Proposals for the utilization of link indications may introduce new
security vulnerabilities. These include: security vulnerabilities. These include:
Spoofing Spoofing
Indication validation Indication validation
Denial of service Denial of service
skipping to change at page 26, line 29 skipping to change at page 27, line 19
LCP-Terminate, and [IEEE-802.11] does not protect management frames LCP-Terminate, and [IEEE-802.11] does not protect management frames
such as Associate/ Reasociate, Disassociate, or Deauthenticate. such as Associate/ Reasociate, Disassociate, or Deauthenticate.
Spoofing of link layer control traffic may enable attackers to Spoofing of link layer control traffic may enable attackers to
exploit weaknesses in link indication proposals. For example, exploit weaknesses in link indication proposals. For example,
proposals that do not implement congestion avoidance can be enable proposals that do not implement congestion avoidance can be enable
attackers to mount denial of service attacks. attackers to mount denial of service attacks.
However, even where the link layer incorporates security, attacks may However, even where the link layer incorporates security, attacks may
still be possible if the security model is not consistent. For still be possible if the security model is not consistent. For
example, 802.11 wireless LANs implementing [IEEE-802.11i] do not example, wireless LANs implementing [IEEE-802.11i] do not enable
enable stations to send or receive IP packets on the link until stations to send or receive IP packets on the link until completion
completion of an authenticated key exchange protocol known as the of an authenticated key exchange protocol known as the "4-way
"4-way handshake". As a result, an 802.11 link utilizing handshake". As a result, a link implementing [IEEE-802.11i] cannot
[IEEE-802.11i] cannot be considered usable at the Internet layer be considered usable at the Internet layer ("Link Up") until
("Link Up") until completion of the authenticated key exchange. completion of the authenticated key exchange.
However, while [IEEE-802.11i] requires sending of authenticated However, while [IEEE-802.11i] requires sending of authenticated
frames in order to obtain a "Link Up" indication, it does not support frames in order to obtain a "Link Up" indication, it does not support
management frame authentication. This weakness can be exploited by management frame authentication. This weakness can be exploited by
attackers to enable denial of service attacks on stations attached to attackers to enable denial of service attacks on stations attached to
distant Access Points (AP). distant Access Points (AP).
In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends 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 a Reassociation Response. At that point, the AP sends a spoofed
frame with the station's source address to a multicast address, frame with the station's source address to a multicast address,
skipping to change at page 29, line 8 skipping to change at page 29, line 43
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988. June 1988.
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989. 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
Xerox PARC, September 1991.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
Control Protocol", RFC 1307, March 1992. Control Protocol", RFC 1307, March 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995. 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D.
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996. 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 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for [RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for
Presence 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 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000. Window Validation", RFC 2861, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP
41, September 2000. 41, September 2000.
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.
and D. Gurle, "Session Initiation Protocol (SIP) and D. Gurle, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428, December Extension for Instant Messaging", RFC 3428, December
2002. 2002.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
protocol (XMPP): Instant Messaging and Presence", RFC protocol (XMPP): Instant Messaging and Presence", RFC
3921, October 2004. 3921, October 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
Configuration of Link-Local IPv4 Addresses", RFC 3927, Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005. May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4436] Aboba, B., Carlson, J. and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006.
[Alimian] Alimian, A., "Roaming Interval Measurements", [Alimian] Alimian, A., "Roaming Interval Measurements",
11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE
802.11 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. [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R.
Morris, "Link-level Measurements from an 802.11b Mesh Morris, "Link-level Measurements from an 802.11b Mesh
Network", SIGCOMM '04, September 2004, Portland, Oregon. Network", SIGCOMM '04, September 2004, Portland, Oregon.
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan, [Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan,
"Improving Performance of TCP over Wireless Networks", "Improving Performance of TCP over Wireless Networks",
Proceedings of the 1997 International Conference on Proceedings of the 1997 International Conference on
Distributed Computer Systems, Baltimore, May 1997. Distributed Computer Systems, Baltimore, May 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-02.txt, Internet draft Detection", draft-ietf-bfd-base-05.txt, Internet draft
(work in progress), March 2005. (work in progress), June 2006.
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses
from Wireless Losses Using Interarrival Times at the from Wireless Losses Using Interarrival Times at the
Receiver", Proc. IEEE Symposium on Application-Specific Receiver", Proc. IEEE Symposium on Application-Specific
Systems and Software Engineering and Technology, Systems and Software Engineering and Technology,
Richardson, TX, Mar 1999. Richardson, TX, Mar 1999.
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R. [Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R.
Prakash, "A Feedback-Based Scheme for Improving TCP Prakash, "A Feedback-Based Scheme for Improving TCP
Performance in Ad-Hoc Wireless Networks", Proceedings of Performance in Ad-Hoc Wireless Networks", Proceedings of
the 18th International Conference on Distributed the 18th International Conference on Distributed
Computing Systems (ICDCS), Amsterdam, May 1998. Computing Systems (ICDCS), Amsterdam, May 1998.
[DCCP] Kohler, E., Handley, M. and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", Internet drafts
(work in progress), draft-ietf-dccp-spec-08.txt, October
2004.
[DNAv4] Aboba, B., Carlson, J. and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", draft-ietf-dhc-dna-
ipv4-18.txt, Internet draft (work in progress), December
2005.
[DNAv6] Narayanan, S., Daley, G. and N. Montavont, "Detecting [DNAv6] Narayanan, S., Daley, G. and N. Montavont, "Detecting
Network Attachment in IPv6 - Best Current Practices for Network Attachment in IPv6 - Best Current Practices for
hosts", draft-ietf-dna-hosts-02.txt, Internet draft (work hosts", draft-ietf-dna-hosts-03.txt, Internet draft (work
in progress), October 2005. in progress), May 2006.
[E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link- [E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-
Up' Notification", draft-dawkins-trigtran-linkup-01.txt, Up' Notification", draft-dawkins-trigtran-linkup-01.txt,
Internet draft (work in progress), October 2003. Internet draft (work in progress), October 2003.
[EAPIKEv2] Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2 [EAPIKEv2] 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 (work in progress), October 2004. draft (work in progress), October 2004.
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis
skipping to change at page 31, line 48 skipping to change at page 32, line 44
Layer Triggers", submission to IEEE 802.21 (work in Layer Triggers", submission to IEEE 802.21 (work in
progress), March 2004, available at: 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.
[Gont] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm- [Gont] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-
icmp-attacks-03.txt, Internet draft (work in progress), icmp-attacks-05.txt, Internet draft (work in progress),
December 2004. October 2005.
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers
on Performance of TCP-Friendly Rate Control", to appear on Performance of TCP-Friendly Rate Control", to appear
in ACM MCCR, 2004. in ACM MCCR, 2004.
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
Transport Protocols", Computer Communications Review Transport Protocols", Computer Communications Review
(CCR) 34, 2 (2003). (CCR) 34, 2 (2003).
[Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H. [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H.
Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04,
October 1, 2004, Philadelphia, Pennsylvania, USA October 1, 2004, Philadelphia, Pennsylvania, USA
[Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation
for IEEE 802.11", Ph.D. Thesis, Technical University of
Delft, Netherlands, ISBN-10:90-9020513-6,
ISBN-13:978-90-9020513-7, March 2006.
[HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation [HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation
Protocol (HMP)", draft-lee-hmp-00.txt, Internet draft Protocol (HMP)", draft-lee-hmp-00.txt, Internet draft
(work in progress), October 2003. (work in progress), October 2003.
[Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance [Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance
over Mobile Ad Hoc Networks", Proceedings of the Fifth over Mobile Ad Hoc Networks", Proceedings of the Fifth
International Conference on Mobile Computing and International Conference on Mobile Computing and
Networking, pages 219-230. ACM/IEEE, Seattle, August Networking, pages 219-230. ACM/IEEE, Seattle, August
1999. 1999.
skipping to change at page 32, line 37 skipping to change at page 33, line 38
Workshop, November, 2002. Workshop, November, 2002.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access 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] Institute of Electrical and Electronics Engineers, [IEEE-802.11] Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 2003. Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE-802.11e] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.11e] Institute of Electrical and Electronics Engineers,
Amendment 7: Medium Access Control (MAC) Quality of "Standard for Telecommunications and Information Exchange
Service (QoS) Enhancements", IEEE 802.11e Draft 10.0, Between Systems - LAN/MAN Specific Requirements - Part
October 2004. 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications - Amendment 8: Medium Access
Control (MAC) Quality of Service Enhancements", IEEE
802.11e, November 2005.
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE [IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE
Trial-Use Recommended Practice for Multi-Vendor Access Trial-Use Recommended Practice for Multi-Vendor Access
Point Interoperability via an Inter-Access Point Protocol Point Interoperability via an Inter-Access Point Protocol
Across Distribution Systems Supporting IEEE 802.11 Across Distribution Systems Supporting IEEE 802.11
Operation", IEEE 802.11F, June 2003. Operation", IEEE 802.11F, June 2003 (now deprecated).
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and "Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access Requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications: Control (MAC) and Physical Layer (PHY) Specifications:
Specification for Enhanced Security", IEEE 802.11i, July Specification for Enhanced Security", IEEE 802.11i, July
2004. 2004.
[IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.11k] 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 Between Systems - LAN/MAN Specific Requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications - Amendment 7: Radio Resource Layer (PHY) Specifications - Amendment 7: Radio Resource
Management", IEEE 802.11k/D3.0, October 2005. Management", IEEE 802.11k/D4.0, March 2006.
[IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.21] 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 Between Systems - LAN/MAN Specific Requirements - Part
21: Media Independent Handover", IEEE 802.21D0, June 21: Media Independent Handover", IEEE 802.21D0, June
2005. 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", method for improving TCP performance over Mobile IPv6",
draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in
skipping to change at page 34, line 44 skipping to change at page 35, line 49
[Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for [Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for
IEEE802.11 WLAN via received signal strength IEEE802.11 WLAN via received signal strength
measurement", IEEE International Conference on measurement", IEEE International Conference on
Communications, 2003 (ICC '03), volume 2, pages Communications, 2003 (ICC '03), volume 2, pages
1108-1113, Anchorage, Alaska, USA, May 2003. 1108-1113, Anchorage, Alaska, USA, May 2003.
[PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network [PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network
protocols", Proceedings of the IEEE, 75(1), January 1987. protocols", Proceedings of the IEEE, 75(1), January 1987.
[Qiao] Qiao D., Choi, S., Jain, A. and Kang G. Shin, "MiSer: An
Optimal Low-Energy Transmission Strategy for IEEE 802.11
a/h", in Proc. ACM MobiCom'03, San Diego, CA, September
2003.
[RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC [RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC
Protocol for Multi-Hop Wireless Networks", Proceedings Protocol for Multi-Hop Wireless Networks", Proceedings
ACM MOBICOM, July 2001. ACM MOBICOM, July 2001.
[Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast
Handoff for 802.11 Infrastructure Networks", Proceedings Handoff for 802.11 Infrastructure Networks", Proceedings
of the IEEE InfoCon 2005, March 2005. of the IEEE InfoCon 2005, March 2005.
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation
for Disconnecting Networks", ACM SIGCOMM Computer for Disconnecting Networks", ACM SIGCOMM Computer
skipping to change at page 39, line 49 skipping to change at page 41, line 49
Within a link layer, the definition of "Link Up" and "Link Down" may Within a link layer, the definition of "Link Up" and "Link Down" may
vary according to the deployment scenario. For example, within PPP vary according to the deployment scenario. For example, within PPP
[RFC1661], either peer may send an LCP-Terminate frame in order to [RFC1661], either peer may send an LCP-Terminate frame in order to
terminate the PPP link layer, and a link may only be assumed to be terminate the PPP link layer, and a link may only be assumed to be
usable for sending network protocol packets once NCP negotiation has usable for sending network protocol packets once NCP negotiation has
completed for that protocol. completed for that protocol.
Unlike PPP, IEEE 802 does not include facilities for network layer Unlike PPP, IEEE 802 does not include facilities for network layer
configuration, and the definition of "Link Up" and "Link Down" varies configuration, and the definition of "Link Up" and "Link Down" varies
by implementation. Empirical evidence suggests that the definition by implementation. Empirical evidence suggests that the definition
of "Link Up" and "Link Down" may depend whether the station is mobile of "Link Up" and "Link Down" may depend on whether the station is
or stationary, whether infrastructure or ad-hoc mode is in use, and mobile or stationary, whether infrastructure or ad-hoc mode is in
whether security and Inter-Access Point Protocol (IAPP) is use, and whether security and Inter-Access Point Protocol (IAPP) is
implemented. implemented.
Where a mobile 802.11 STA encounters a series of consecutive non- Where a STA encounters a series of consecutive non-acknowledged
acknowledged frames, the most likely cause is that the station has frames while having missed one or more beacons, the most likely cause
moved out of range of the AP. As a result, [Velayos] recommends that is that the station has moved out of range of the AP. As a result,
the station begin the search phase after collisions can be ruled out, [Velayos] recommends that the station begin the search phase after
after three consecutive non-acknowledged frames. Only when no collisions can be ruled out; since this approach does not take rate
alternative point of attachment is found is a "Link Down" indication adaptation into account, it may be somewhat aggressive. Only when no
returned. alternative workable rate or point of attachment is found is a "Link
Down" indication returned.
In a stationary point-to-point installation, the most likely cause of In a stationary point-to-point installation, the most likely cause of
an outage is that the link has become impaired, and alternative an outage is that the link has become impaired, and alternative
points of attachment may not be available. As a result, points of attachment may not be available. As a result,
implementations configured to operate in this mode tend to be more implementations configured to operate in this mode tend to be more
persistent. For example, within 802.11 the short interframe space persistent. For example, within 802.11 the short interframe space
(SIFS) interval may be increased and MIB variables relating to (SIFS) interval may be increased and MIB variables relating to
timeouts (such as dot11AuthenticationResponseTimeout, timeouts (such as dot11AuthenticationResponseTimeout,
dot11AssociationResponseTimeout, dot11ShortRetryLimit, and dot11AssociationResponseTimeout, dot11ShortRetryLimit, and
dot11LongRetryLimit) may be set to larger values. In addition a dot11LongRetryLimit) may be set to larger values. In addition a
"Link Down" indication may be returned later. "Link Down" indication may be returned later.
In 802.11 ad-hoc mode with no security, reception of data frames is In IEEE 802.11 ad-hoc mode with no security, reception of data frames
enabled in State 1 ("Unauthenticated" and "Unassociated"). As a is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a
result, reception of data frames is enabled at any time, and no result, reception of data frames is enabled at any time, and no
explicit "Link Up" indication exists. explicit "Link Up" indication exists.
In Infrastructure mode, IEEE 802.11-2003 enables reception of data In Infrastructure mode, IEEE 802.11-2003 enables reception of data
frames only in State 3 ("Authenticated" and "Associated"). As a frames only in State 3 ("Authenticated" and "Associated"). As a
result, a transition to State 3 (e.g. completion of a successful result, a transition to State 3 (e.g. completion of a successful
Association or Reassociation exchange) enables sending and receiving Association or Reassociation exchange) enables sending and receiving
of network protocol packets and a transition from State 3 to State 2 of network protocol packets and a transition from State 3 to State 2
(reception of a "Disassociate" frame) or State 1 (reception of a (reception of a "Disassociate" frame) or State 1 (reception of a
"Deauthenticate" frame) disables sending and receiving of network "Deauthenticate" frame) disables sending and receiving of network
skipping to change at page 43, line 10 skipping to change at page 45, line 11
service link layer can be integrated with Differentiated Services. service link layer can be integrated with Differentiated Services.
In "WaveLAN-II: A High-performance wireless LAN for the unlicensed In "WaveLAN-II: A High-performance wireless LAN for the unlicensed
band" [Kamerman] the authors propose a rate adaptation algorithm band" [Kamerman] the authors propose a rate adaptation algorithm
(ARF) in which the sender adjusts the rate upwards after a fixed (ARF) in which the sender adjusts the rate upwards after a fixed
number of successful transmissions, and adjusts the rate downwards number of successful transmissions, and adjusts the rate downwards
after one or two consecutive failures. If after an upwards rate after one or two consecutive failures. If after an upwards rate
adjustment the transmission fails, the rate is immediately readjusted adjustment the transmission fails, the rate is immediately readjusted
downwards. downwards.
In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks"
[RBAR] the authors propose a rate adaptation approach that requires
incompatible changes to the IEEE 802.11 MAC. In order to enable the
sender to better determine the transmission rate, the receiver
determines the packet length and Signal/Noise Ratio (SNR) of a
received RTS frame and calculates the corresponding rate based on a
theoretical channel model, rather than channel usage statistics. The
recommended rate is sent back in the CTS frame. This allows the rate
(and potentially the transmit power) to be optimized on each
transmission, albeit at the cost of requiring RTS/CTS for every frame
transmission.
In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE
802.11 a/h" [Qiao] the authors propose a scheme for optimizing
transmit power. The proposal mandates the use of RTS/CTS in order to
deal with hidden nodes, requiring that CTS and ACK frames be sent at
full power. However, this approach also utilizes a theoretical model
rather than determining the model based on channel usage statistics.
In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage] the
authors distinguish between low latency implementations which enable
per-packet rate decisions, and high latency implementations which do
not. The former implementations typically include dedicated CPUs in
their design, enabling them to meet real-time requirements. The
latter implementations are typically based on highly integrated
designs in which the upper MAC is implemented on the host. As a
result, due to operating system latencies the information required to
make per-packet rate decisions may not be available in time.
The authors propose an Adaptive ARF (AARF) algorithm for use with
low-latency implementations. This enables rapid downward rate
negotiation on failure to receive an ACK, while increasing the amount
number of successful transmission required for upward rate
negotiation. The AARF algorithm is therefore highly stable in
situations where channel properties are changing slowly, but slow to
adapt upwards when channel conditions improve. In order to test the
algorithm, the authors utilized ns-2 simulations as well as
implementing a version of AARF adapted to a high latency
implementation, the AR 5212 chipset. The Multiband Atheros Driver
for WiFi (MADWIFI) driver enables a fixed schedule of rates and
retries to be provided when a frame is queued for transmision. The
adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR),
requests only one transmission at each of three rates, the last of
which is the minimum available rate. This enables adaptation to
short-term fluctuations in the channel with minimal latency. The
AMRR algorithm provides performance considerably better than the
existing Madwifi driver and close to that of the RBAR algorithm,
while enabling practical implementation.
In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal
Strength Measurement" [Pavon], the authors propose an algorithm by Strength Measurement" [Pavon], the authors propose an algorithm by
which a STA adjusts the transmission rate based on a comparison of which a STA adjusts the transmission rate based on a comparison of
the received signal strength (RSS) from the AP with dynamically the received signal strength (RSS) from the AP with dynamically
estimated threshold values for each transmission rate. Upon estimated threshold values for each transmission rate. Upon
reception of a frame, the STA updates the average RSS, and on reception of a frame, the STA updates the average RSS, and on
transmission the STA selects a rate and adjusts the RSS threshold transmission the STA selects a rate and adjusts the RSS threshold
values based on whether the transmission is successful or not. In values based on whether the transmission is successful or not. In
order to validate the algorithm, the authors utilized an OPNET order to validate the algorithm, the authors utilized an OPNET
simulation without interference, and an ideal curve of bit error rate simulation without interference, and an ideal curve of bit error rate
(BER) vs. signal/noise ratio (SNR) was assumed. Not surprisingly, (BER) vs. signal/noise ratio (SNR) was assumed. Not surprisingly,
the simulation results closely matched the maximum throughput the simulation results closely matched the maximum throughput
achievable for a given signal/noise ratio, based on the ideal BER vs. achievable for a given signal/noise ratio, based on the ideal BER vs.
SNR curve. SNR curve.
In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors
describe a hybrid technique utilizing Signal Strength Indication
(SSI) data to constrain the potential rates selected by statistics-
based automatic rate control. Statistics-based rate control
techniques include:
Maximum throughput
This technique, which was chosen as the statistics-based technique
in the hybrid scheme, sends a fraction of data at adjacent rates in
order to estimate which rate provides the maximum throughput.
Since accurate estimation of throughput requires a minimum number
of frames to be sent at each rate, and only a fraction of frames
are utilized for this purpose, this technique adapts more slowly at
lower rates; with 802.11b rates, the adaptation time scale is
typically on the order of a second. Depending on how many rates
are tested, this technique can enable adaptation beyond adjacent
rates.
FER control
This technique estimates the Frame Error Rate (FER), attempting to
keep it between a lower limit (if FER moves below, increase rate)
and upper limit (if FER moves above, decrease rate). Since this
technique can utilize all the transmitted data, it can respond
faster than maximum throughput techniques. However, there is a
tradeoff of reaction time versus FER estimation accuracy; at lower
rates either reaction times slow or FER estimation accuracy will
suffer. Since this technique only measures the FER at the current
rate, it can only enable adaptation to adjacent rates.
Retry-based
This technique modifies FER control techniques by enabling rapid
downward rate adaptation after a number (5-10) of unsuccessful re-
transmissions. Since fewer packets are required, the sensitivity
of reaction time to rate is reduced.. However, upward rate
adaptation proceeds more slowly since it is based on collection of
FERdata. This technique is limited to adaptation to adjacent
rates.
While statistics-based techniques are robust against short-lived link
quality changes, they do not respond quickly to long-lived changes.
By constraining the rate selected by statistics-based techniques
based on ACK SSI versus rate data (not theoretical curves), more
rapid link adaptation was enabled. In order to ensure rapid
adaptation during rapidly varying conditions, the rate constraints
are tightened when the SSI values are changing rapidly, encouraging
rate transitions. The authors validated their algorithms by
implementing a driver for the Atheros AR5000 chipset, and then
testing its response to insertion and removal from a microwave oven
acting as a faraday cage. The hybrid algorithm dropped many fewer
packets than the maximum throughput technique by itself.
In order to estimate the SSI of data at the receiver, the SSI of ACKs
received at the sender was used. This approach did not require the
receiver to provide the sender with the received SSI, so that it
could be implemented without changing the IEEE 802.11 MAC. This
scheme assumes that transmit power remains constant on the sender and
receiver and that channel properties in both direcctions vary slowly,
so that the SSI of the received ACKs and sent data remain in
proportion. Actual data was used to determine the relationship
between the ACK SSI and rate, so that the proportion itself does not
matter, just as long as it varies slowly. The authors checked the
proportionality assumption and found that the SSI of received data
correlated highly (74%) with the SSI of received ACKs. Low pass
filtering and monotonicity constraints were applied to remove the
considerable noise in the SSI versus rate curves.
In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical] the authors propose use of signal strength and
link utilization in order to optimize vertical handoff. WLAN to WWAN
handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a
threshold (S1), FFT-based decay detection is undertaken to determine
if the signal is likely to continue to decay. If so, then handoff to
the WWAN is initiated when the signal falls below the minimum
acceptable level (S2). WWAN to WLAN handoff is driven by both PHY
and MAC characteristics of the IEEE 802.11 target network. At the
PHY layer, characteristics such as SSI are examined to determine if
the signal strength is greater than a minimum value (S3); at the MAC
layer the IEEE 802.11 Network Allocation Vector (NAV) occupation is
examined in order to estimate the maximum available bandwidth and
mean access delay. Note that depending on the value of S3, it is
possible for the negotiated rate to be less than the available
bandwidth. In order to prevent premature handoff between WLAN and
WWAN, S1 and S2 are separated by 6 dB; in order to prevent
oscillation between WLAN and WWAN media, S3 needs to be greater than
S1 by an appropriate margin.
A.2 Internet Layer A.2 Internet Layer
Within the Internet layer, proposals have been made for utilizing Within the Internet layer, proposals have been made for utilizing
link indications to optimize IP configuration, to improve the link indications to optimize IP configuration, to improve the
usefulness of routing metrics, and to optimize aspects of Mobile IP usefulness of routing metrics, and to optimize aspects of Mobile IP
handoff. handoff.
In "Detecting Network Attachment (DNA) in IPv4" [DNAv4], a host that In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
has moved to a new point of attachment utilizes a reachability test that has moved to a new point of attachment utilizes a bi-directional
in parallel with DHCP [RFC2131] to rapidly reconfirm an operable reachability test in parallel with DHCP [RFC2131] to rapidly
configuration. reconfirm an operable configuration.
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, as described in [DNAv4]. resulting change in IP configuration, as described in [RFC4436].
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors
suggest that MIPv4 Registration messages be carried within suggest that MIPv4 Registration messages be carried within
Information Elements of IEEE 802.11 Association/Reassociation frames, Information Elements of IEEE 802.11 Association/Reassociation frames,
in order to minimize handoff delays. This requires modification to in order to minimize handoff delays. This requires modification to
the mobile node as well as 802.11 APs. However, prior to detecting the mobile node as well as 802.11 APs. However, prior to detecting
network attachment, it is difficult for the mobile node to determine network attachment, it is difficult for the mobile node to determine
whether the new point of attachment represents a change of network or whether the new point of attachment represents a change of network or
not. For example, even where a station remains within the same ESS, not. For example, even where a station remains within the same ESS,
it is possible that the network will change. Where no change of it is possible that the network will change. Where no change of
skipping to change at page 46, line 6 skipping to change at page 50, line 46
propose a TCP option that allows a connection endpoint to inform a propose a TCP option that allows a connection endpoint to inform a
peer of a subnet change. The document does not advocate utilization peer of a subnet change. The document does not advocate utilization
of "Link Up" or "Link Down" events since these events are not of "Link Up" or "Link Down" events since these events are not
necessarily indicative of subnet change. On detection of subnet necessarily indicative of subnet change. On detection of subnet
change, it is advocated that the congestion window be reset to change, it is advocated that the congestion window be reset to
INIT_WINDOW and that transport parameters be reestimated. The INIT_WINDOW and that transport parameters be reestimated. The
authors argue that recovery from slow start results in higher authors argue that recovery from slow start results in higher
throughput both when the subnet change results in lower bottleneck throughput both when the subnet change results in lower bottleneck
bandwidth as well as when bottleneck bandwidth increases. bandwidth as well as when bottleneck bandwidth increases.
In an early draft of [DCCP], a "Reset Congestion State" option was In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical] the authors propose a "Virtual Connectivity
Manager" which utilizes local connection translation (LCT) and a
subscription/notification service supporting simultaneous movement in
order to enable end-to-end mobility and maintain TCP throughput
during vertical handovers.
In an early draft of [RFC4340], a "Reset Congestion State" option was
proposed in Section 4. This option was removed in part because the proposed in Section 4. This option was removed in part because the
use conditions were not fully understood: use conditions were not fully understood:
An Half-Connection Receiver sends the Reset Congestion State option An Half-Connection Receiver sends the Reset Congestion State option
to its sender to force the sender to reset its congestion state -- to its sender to force the sender to reset its congestion state --
that is, to "slow start", as if the connection were beginning again. that is, to "slow start", as if the connection were beginning again.
... ...
The Reset Congestion State option is reserved for the very few cases The Reset Congestion State option is reserved for the very few cases
when an endpoint knows that the congestion properties of a path have when an endpoint knows that the congestion properties of a path have
changed. Currently, this reduces to mobility: a DCCP endpoint on a changed. Currently, this reduces to mobility: a DCCP endpoint on a
skipping to change at page 48, line 50 skipping to change at page 53, line 48
and traffic conditions. While per-packet ETEN mechanisms provided and traffic conditions. While per-packet ETEN mechanisms provided
substantial gains in TCP goodput without congestion, where congestion substantial gains in TCP goodput without congestion, where congestion
was also present, the gains were not significant. Cumulative ETEN was also present, the gains were not significant. Cumulative ETEN
mechanisms did not perform as well in the study. The authors point mechanisms did not perform as well in the study. The authors point
out that ETEN faces significant deployment barriers since it can out that ETEN faces significant deployment barriers since it can
create new security vulnerabilities and requires implementations to create new security vulnerabilities and requires implementations to
obtain reliable information from the headers of corrupt packets. obtain reliable information from the headers of corrupt packets.
A.4 Application Layer A.4 Application Layer
In "Application-oriented Link Adaptation for IEEE 802.11"
[Haratcherev2], rate information generated by a link layer utilizing
improved rate adaptation algorithms is provided to a video
application, and used for codec adaptation. Coupling the MAC and
application layers results in major improvements in the Peak
Signal/Noise Ratio (PSNR).
At the Application layer, the usage of "Link Down" indications has At the Application layer, the usage of "Link Down" indications has
been proposed to augment presence systems. In such systems, client been proposed to augment presence systems. In such systems, client
devices periodically refresh their presence state using application devices periodically refresh their presence state using application
layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the
client should become disconnected, their unavailability will not be client should become disconnected, their unavailability will not be
detected until the presence status times out, which can take many detected until the presence status times out, which can take many
minutes. However, if a link goes down, and a disconnect indication minutes. However, if a link goes down, and a disconnect indication
can be sent to the presence server (presumably by the access point, can be sent to the presence server (presumably by the access point,
which remains connected), the status of the user's communication which remains connected), the status of the user's communication
application can be updated nearly instantaneously. application can be updated nearly instantaneously.
Appendix B - IAB Members at the time of this writing Appendix B - IAB Members at the time of this writing
Bernard Aboba Bernard Aboba
Loa Andersson Loa Andersson
Brian Carpenter
Leslie Daigle Leslie Daigle
Patrik Falstrom Elwyn Davies
Bob Hinden Kevin Fall
Olaf Kolkman
Kurtis Lindqvist Kurtis Lindqvist
David Meyer David Meyer
Pekka Nikander David Oran
Eric Rescorla Eric Rescorla
Pete Resnick Dave Thaler
Jonathan Rosenberg
Lixia Zhang Lixia Zhang
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 50, line 17 skipping to change at page 55, line 23
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 110 change blocks. 
453 lines changed or deleted 656 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/