draft-iab-link-indications-09.txt   draft-iab-link-indications-10.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-09.txt> <draft-iab-link-indications-10.txt>
28 February 2007
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 2, line 15 skipping to change at page 2, line 15
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 ........................................... 5
1.4 Layered Indication Model ........................... 6 1.4 Layered Indication Model ........................... 6
2. Architectural Considerations ............................. 13 2. Architectural Considerations ............................. 13
2.1 Model Validation ................................... 14 2.1 Model Validation ................................... 14
2.2 Clear Definitions .................................. 15 2.2 Clear Definitions .................................. 15
2.3 Robustness ......................................... 17 2.3 Robustness ......................................... 16
2.4 Congestion Control ................................. 20 2.4 Congestion Control ................................. 19
2.5 Effectiveness ...................................... 21 2.5 Effectiveness ...................................... 20
2.6 Interoperability ................................... 21 2.6 Interoperability ................................... 21
2.7 Race Conditions .................................... 21 2.7 Race Conditions .................................... 21
2.8 Layer Compression .................................. 24 2.8 Layer Compression .................................. 24
2.9 Transport of Link Indications ...................... 25 2.9 Transport of Link Indications ...................... 25
3. Future Work .............................................. 26 3. Future Work .............................................. 26
4. Security Considerations .................................. 27 4. Security Considerations .................................. 27
4.1 Spoofing ........................................... 27 4.1 Spoofing ........................................... 27
4.2 Indication Validation .............................. 28 4.2 Indication Validation .............................. 28
4.3 Denial of Service .................................. 29 4.3 Denial of Service .................................. 29
5. IANA Considerations ...................................... 30 5. IANA Considerations ...................................... 29
6. References ............................................... 30 6. References ............................................... 29
6.1 Informative References ............................. 30 6.1 Informative References ............................. 29
Acknowledgments .............................................. 39 Acknowledgments .............................................. 38
Appendix A - Literature Review ............................... 40 Appendix A - Literature Review ............................... 39
A.1 Link Layer ......................................... 40 A.1 Link Layer ......................................... 39
A.2 Internet Layer ..................................... 52 A.2 Internet Layer ..................................... 51
A.3 Transport Layer .................................... 53 A.3 Transport Layer .................................... 53
A.4 Application Layer .................................. 58 A.4 Application Layer .................................. 57
Appendix B - IAB Members ..................................... 59 Appendix B - IAB Members ..................................... 58
Authors' Addresses ........................................... 59 Authors' Addresses ........................................... 58
Full Copyright Statement ..................................... 59 Full Copyright Statement ..................................... 59
Intellectual Property ........................................ 60 Intellectual Property ........................................ 59
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. While the to higher layers regarding the state of the link. While the
judicious use of link indications can provide performance benefits, judicious use of link indications can provide performance benefits,
inappropriate use can degrade both robustness and performance. 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 within the Internet architecture, and provides link indications within the Internet architecture, and provides
skipping to change at page 6, line 48 skipping to change at page 6, line 48
to interference or signal fading. In both wired and wireless links, to interference or signal fading. In both wired and wireless links,
the link state may rapidly flap between the "up" and "down" states. the link state may rapidly flap between the "up" and "down" states.
This real world behavior presents challenges to the integration of This real world behavior presents challenges to the integration of
link indications with the Internet, Transport and Application layers. link indications with 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 rate) internally generated link indications (such as link state and rate)
and indications arising from external interactions such as path and indications arising from external interactions such as path
change detection. change detection. In this model, it is assumed that the link layer
provides indications to higher layers primarily in the form of
In this model, it is assumed that the link layer provides indications abstract indications that are link-technology agnostic.
to higher layers primarily in the form of abstract indications that
are link-technology agnostic.
1.4.1. Internet Layer
One of the functions of the Internet layer is to shield higher layers
from the specifics of link behavior. As a result, the Internet layer
validates and filters link indications and selects outgoing and
incoming interfaces based on routing metrics.
The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into
account information provided by routers. This enables the state of
the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the
routing table may be determined from Dynamic Host Configuration
Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements
[RFC1256][RFC2461], re-direct messages or route updates incorporating
information on the state of links multiple hops away.
In "Analysis of link failures in an IP backbone" [Iannaccone] the
authors investigate link failures in Sprint's IP backbone. They
identify the causes of convergence delay, including delays in
detection of whether an interface is down or up. While it is fastest
for a router to utilize link indications if available, there are
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
been determined, a delay may occur within the routing protocol in
order to dampen link flaps. Finally, another delay may be introduced
in propagating the link state change, in order to rate limit link
state advertisements, and guard against instability.
"Bidirectional Forwarding Detection" [BFD] notes that link layers may
provide only limited failure indications, and that relatively slow
"Hello" mechanisms are used in routing protocols to detect failures
when no link layer indications are available. This results in
failure detection times of the order of a second, which is too long
for some applications. The authors describe a mechanism that can be
used for liveness detection over any media, enabling rapid detection
of failures in the path between adjacent forwarding engines. A path
is declared operational when bi-directional reachability has been
confirmed.
As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC],
the Internet layer may maintain a path information cache, enabling
sharing of path MTU information between concurrent or subsequent
connections. The shared cache is accessed and updated by
packetization protocols implementing packetization layer path MTU
discovery.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^ ^ ^
! ! ! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! | | ! ! ! |
| ! ^ ^ | | ! ^ ^ |
skipping to change at page 9, line 4 skipping to change at page 8, line 4
! ! ! !
! ! ! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! | | ! ! |
Link | ^ ^ | Link | ^ ^ |
Layer | Rate, FER, Link | Layer | Rate, FER, Link |
| Delay Up/Down | | Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model Figure 1. Layered Indication Model
1.4.1. Internet Layer
One of the functions of the Internet layer is to shield higher layers
from the specifics of link behavior. As a result, the Internet layer
validates and filters link indications and selects outgoing and
incoming interfaces based on routing metrics.
The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into
account information provided by routers. This enables the state of
the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the
routing table may be determined from Dynamic Host Configuration
Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements
[RFC1256][RFC2461], re-direct messages or route updates incorporating
information on the state of links multiple hops away.
As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC],
the Internet layer may maintain a path information cache, enabling
sharing of path MTU information between concurrent or subsequent
connections. The shared cache is accessed and updated by
packetization protocols implementing packetization layer path MTU
discovery.
The Internet layer also utilizes link indications in order to The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA) potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be [RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up" determined that an address change has occurred. However, "Link Up"
indications may not necessarily result in a change to Internet layer indications may not necessarily result in a change to Internet layer
configuration. configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
skipping to change at page 31, line 37 skipping to change at page 31, line 14
[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.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000. 2923, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol" RFC 2960, October 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 [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", RFC 3366, August link Automatic Repeat reQuest (ARQ)", RFC 3366, August
2002. 2002.
skipping to change at page 45, line 19 skipping to change at page 44, line 22
equipment and link-layer protocols employing link-layer Automatic equipment and link-layer protocols employing link-layer Automatic
Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
timers, persistency in retransmission and the challenges that arise timers, persistency in retransmission and the challenges that arise
from sharing links between multiple flows and in differentiation from sharing links between multiple flows and in differentiation
transport flow requirements. transport flow requirements.
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the
authors describe how the GSM reliable and unreliable link layer modes authors describe how the GSM reliable and unreliable link layer modes
can be simultaneously utilized without higher layer control. Where a can be simultaneously utilized without higher layer control. Where a
reliable link layer protocol is required (where reliable transports reliable link layer protocol is required (where reliable transports
such TCP and Stream Control Transmission Protocol (SCTP) are used), such TCP and Stream Control Transmission Protocol (SCTP) [RFC2960]
the Radio Link Protocol (RLP) can be engaged; with delay sensitive are used), the Radio Link Protocol (RLP) can be engaged; with delay
applications such as those based on UDP, the transparent mode (no sensitive applications such as those based on UDP, the transparent
RLP) can be used. The authors also describe how PPP negotiation can mode (no RLP) can be used. The authors also describe how PPP
be optimized over high latency GSM links using "Quickstart-PPP". negotiation can be optimized over high latency GSM links using
"Quickstart-PPP".
In "Link Layer Based TCP Optimisation for Disconnecting Networks" In "Link Layer Based TCP Optimisation for Disconnecting Networks"
[Scott], the authors describe performance problems that occur with [Scott], the authors describe performance problems that occur with
reliable transport protocols facing periodic network disconnections, reliable transport protocols facing periodic network disconnections,
such as those due to signal fading or handoff. The authors define a such as those due to signal fading or handoff. The authors define a
disconnection as a period of connectivity loss that exceeds a disconnection as a period of connectivity loss that exceeds a
retransmission timeout, but is shorter than the connection lifetime. retransmission timeout, but is shorter than the connection lifetime.
One issue is that link-unaware senders continue to back off during One issue is that link-unaware senders continue to back off during
periods of disconnection. The authors suggest that a link-aware periods of disconnection. The authors suggest that a link-aware
reliable transport implementation halt retransmission after receiving reliable transport implementation halt retransmission after receiving
skipping to change at page 49, line 17 skipping to change at page 48, line 21
are tightened when the SSI values are changing rapidly, encouraging are tightened when the SSI values are changing rapidly, encouraging
rate transitions. The authors validated their algorithms by rate transitions. The authors validated their algorithms by
implementing a driver for the Atheros AR5000 chipset, and then implementing a driver for the Atheros AR5000 chipset, and then
testing its response to insertion and removal from a microwave oven testing its response to insertion and removal from a microwave oven
acting as a Faraday cage. The hybrid algorithm dropped many fewer acting as a Faraday cage. The hybrid algorithm dropped many fewer
packets than the maximum throughput technique by itself. packets than the maximum throughput technique by itself.
In order to estimate the SSI of data at the receiver, the ACK SSI was In order to estimate the SSI of data at the receiver, the ACK SSI was
used. This approach does not require the receiver to provide the used. This approach does not require the receiver to provide the
sender with the received power, so that it can be implemented without sender with the received power, so that it can be implemented without
changing the IEEE 802.11 MAC. Callibration of the rate versus ACK changing the IEEE 802.11 MAC. Calibration of the rate versus ACK SSI
SSI curves does not require a symmetric channel, but it does require curves does not require a symmetric channel, but it does require that
that channel properties in both directions vary in a proportional way channel properties in both directions vary in a proportional way and
and that the ACK transmit power remains constant. The authors that the ACK transmit power remains constant. The authors checked
checked the proportionality assumption and found that the SSI of the proportionality assumption and found that the SSI of received
received data correlated highly (74%) with the SSI of received ACKs. data correlated highly (74%) with the SSI of received ACKs. Low pass
Low pass filtering and monotonicity constraints were applied to filtering and monotonicity constraints were applied to remove noise
remove noise in the rate versus SSI curves. The resulting hybrid in the rate versus SSI curves. The resulting hybrid rate adaptation
rate adaptation algorithm demonstrated the ability to respond to algorithm demonstrated the ability to respond to rapid deterioration
rapid deterioration (and improvement) in channel properties, since it (and improvement) in channel properties, since it is not restricted
is not restricted to moving to adjacent rates. to moving to adjacent rates.
In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs" In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs"
[CARA], the authors propose Collision-Aware Rate Adaptation (CARA). [CARA], the authors propose Collision-Aware Rate Adaptation (CARA).
This involves utilization of Clear Channel Assessment (CCA) along This involves utilization of Clear Channel Assessment (CCA) along
with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS) with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS)
mechanism to differentiate losses caused by frame collisions from mechanism to differentiate losses caused by frame collisions from
losses caused by channel conditions. Rather than decreasing rate as losses caused by channel conditions. Rather than decreasing rate as
the result of frame loss due to collisions, which leads to increased the result of frame loss due to collisions, which leads to increased
contention, CARA selectively enables RTS/CTS (e.g. after a frame contention, CARA selectively enables RTS/CTS (e.g. after a frame
loss), reducing the likelihood of frame loss due to hidden stations. loss), reducing the likelihood of frame loss due to hidden stations.
skipping to change at page 52, line 21 skipping to change at page 51, line 24
oscillation between WLAN and WWAN media, S3 needs to be greater than oscillation between WLAN and WWAN media, S3 needs to be greater than
S1 by an appropriate margin. 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 "Analysis of link failures in an IP backbone" [Iannaccone] the
authors investigate link failures in Sprint's IP backbone. They
identify the causes of convergence delay, including delays in
detection of whether an interface is down or up. While it is fastest
for a router to utilize link indications if available, there are
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
been determined, a delay may occur within the routing protocol in
order to dampen link flaps. Finally, another delay may be introduced
in propagating the link state change, in order to rate limit link
state advertisements, and guard against instability.
"Bidirectional Forwarding Detection" [BFD] notes that link layers may
provide only limited failure indications, and that relatively slow
"Hello" mechanisms are used in routing protocols to detect failures
when no link layer indications are available. This results in
failure detection times of the order of a second, which is too long
for some applications. The authors describe a mechanism that can be
used for liveness detection over any media, enabling rapid detection
of failures in the path between adjacent forwarding engines. A path
is declared operational when bi-directional reachability has been
confirmed.
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
that has moved to a new point of attachment utilizes a bi-directional that has moved to a new point of attachment utilizes a bi-directional
reachability test in parallel with DHCP [RFC2131] to rapidly reachability test in parallel with DHCP [RFC2131] to rapidly
reconfirm an operable 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 to provide lower handoff latency than would be possible using order to 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
skipping to change at page 54, line 22 skipping to change at page 53, line 48
a signal to the Transport layer to adjust cwnd and ssthresh values, a signal to the Transport layer to adjust cwnd and ssthresh values,
which may have been reduced due to handoff-induced packet loss. The which may have been reduced due to handoff-induced packet loss. The
authors recommend that cwnd and ssthresh be recovered to pre-timeout authors recommend that cwnd and ssthresh be recovered to pre-timeout
values, regardless of whether the link parameters have changed. The values, regardless of whether the link parameters have changed. The
paper does not discuss the behavior of a mobile node sending a paper does not discuss the behavior of a mobile node sending a
Binding Update, in the case where the mobile node is sending to the Binding Update, in the case where the mobile node is sending to the
correspondent node. correspondent node.
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate
Control" [Gurtov], the authors examine the effect of explicit Control" [Gurtov], the authors examine the effect of explicit
handover notifications on TCP-friendly rate control. Where explicit handover notifications on TCP-friendly rate control (TFRC). Where
handover notification includes information on the loss rate and explicit handover notification includes information on the loss rate
throughput of the new link, this can be used to instantaneously and throughput of the new link, this can be used to instantaneously
change the transmission rate of the sender. The authors also found change the transmission rate of the sender. The authors also found
that resetting the TFRC receiver state after handover enabled that resetting the TFRC receiver state after handover enabled
parameter estimates to adjust more quickly. parameter estimates to adjust more quickly.
In "Adapting End Host Congestion Control for Mobility" [Eddy], the In "Adapting End Host Congestion Control for Mobility" [Eddy], the
authors note that while MIPv6 with route optimization allows a authors note that while MIPv6 with route optimization allows a
receiver to communicate a subnet change to the sender via a Binding receiver to communicate a subnet change to the sender via a Binding
Update, this is not available within MIPv4. To provide a Update, this is not available within MIPv4. To provide a
communication vehicle that can be universally employed, the authors communication vehicle that can be universally employed, the authors
propose a TCP option that allows a connection endpoint to inform a propose a TCP option that allows a connection endpoint to inform a
 End of changes. 12 change blocks. 
88 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/