RFC 4907
Architectural Implications of Link Indications
Network Working Group B. Aboba, Ed. Request for Comments: 4907 Internet Architecture Board Category: Informational IAB June 2007 Architectural Implications of Link Indications Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role 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 summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.
Table of Contents
1. Introduction ....................................................3 1.1. Requirements ...............................................3 1.2. Terminology ................................................3 1.3. Overview ...................................................5 1.4. Layered Indication Model ...................................7 2. Architectural Considerations ...................................14 2.1. Model Validation ..........................................15 2.2. Clear Definitions .........................................16 2.3. Robustness ................................................17 2.4. Congestion Control ........................................20 2.5. Effectiveness .............................................21 2.6. Interoperability ..........................................22 2.7. Race Conditions ...........................................22 2.8. Layer Compression .........................................25 2.9. Transport of Link Indications .............................26 3. Future Work ....................................................27 4. Security Considerations ........................................28 4.1. Spoofing ..................................................28 4.2. Indication Validation .....................................29 4.3. Denial of Service .........................................30 5. References .....................................................31 5.1. Normative References ......................................31 5.2. Informative References ....................................31 6. Acknowledgments ................................................40 Appendix A. Literature Review .....................................41 A.1. Link Layer .................................................41 A.2. Internet Layer .............................................53 A.3. Transport Layer ............................................55 A.4. Application Layer ..........................................60 Appendix B. IAB Members ...........................................60
1. Introduction
A link indication represents information provided by the link layer to higher layers regarding the state of the link. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes the current understanding of the role of link indications within the Internet architecture, and provides advice to document authors about the appropriate use of link indications within the Internet, transport, and application layers. Section 1 describes the history of link indication usage within the Internet architecture and provides a model for the utilization of link indications. Section 2 describes the architectural considerations and provides advice to document authors. Section 3 describes recommendations and future work. Appendix A summarizes the literature on link indications, focusing largely on wireless Local Area Networks (WLANs).1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].1.2. Terminology
Access Point (AP) A station that provides access to the fixed network (e.g., an 802.11 Distribution System), via the wireless medium (WM) for associated stations. Asymmetric A link with transmission characteristics that are different depending upon the relative position or design characteristics of the transmitter and the receiver is said to be asymmetric. For instance, the range of one transmitter may be much higher than the range of another transmitter on the same medium. Beacon A control message broadcast by a station (typically an Access Point), informing stations in the neighborhood of its continuing presence, possibly along with additional status or configuration information.
Binding Update (BU)
A message indicating a mobile node's current mobility binding,
and in particular its Care-of Address.
Correspondent Node
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Link
A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
the Internet Protocol (IP).
Link Down
An event provided by the link layer that signifies a state
change associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss
are not sufficient.
Link Indication
Information provided by the link layer to higher layers
regarding the state of the link.
Link Layer
Conceptual layer of control or processing logic that is
responsible for maintaining control of the link. The link layer
functions provide an interface between the higher-layer logic
and the link. The link layer is the layer immediately below the
Internet Protocol (IP).
Link Up
An event provided by the link layer that signifies a state
change associated with the interface becoming capable of
communicating data frames.
Maximum Segment Size (MSS)
The maximum payload size available to the transport layer.
Maximum Transmission Unit (MTU)
The size in octets of the largest IP packet, including the IP
header and payload, that can be transmitted on a link or path.
Mobile Node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
Operable Address
A static or dynamically assigned address that has not been
relinquished and has not expired.
Point of Attachment
The endpoint on the link to which the host is currently
connected.
Routable Address
Any IP address for which routers will forward packets. This
includes private addresses as specified in "Address Allocation
for Private Internets" [RFC1918].
Station (STA)
Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
medium (WM).
Strong End System Model
The Strong End System model emphasizes the host/router
distinction, tending to model a multi-homed host as a set of
logical hosts within the same physical host. In the Strong End
System model, addresses refer to an interface, rather than to
the host to which they attach. As a result, packets sent on an
outgoing interface have a source address configured on that
interface, and incoming packets whose destination address does
not correspond to the physical interface through which it is
received are silently discarded.
Weak End System Model
In the Weak End System model, addresses refer to a host. As a
result, packets sent on an outgoing interface need not
necessarily have a source address configured on that interface,
and incoming packets whose destination address does not
correspond to the physical interface through which it is
received are accepted.
1.3. Overview
The use of link indications within the Internet architecture has a
long history. In response to an attempt to send to a host that was
off-line, the ARPANET link layer protocol provided a "Destination
Dead" indication, described in "Fault Isolation and Recovery"
[RFC816]. The ARPANET packet radio experiment [PRNET] incorporated
frame loss in the calculation of routing metrics, a precursor to more
recent link-aware routing metrics such as Expected Transmission Count
(ETX), described in "A High-Throughput Path Metric for Multi-Hop
Wireless Routing" [ETX].
"Routing Information Protocol" [RFC1058] defined RIP, which is descended from the Xerox Network Systems (XNS) Routing Information Protocol. "The OSPF Specification" [RFC1131] defined Open Shortest Path First, which uses Link State Advertisements (LSAs) in order to flood information relating to link status within an OSPF area. [RFC2328] defines version 2 of OSPF. While 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 determining that their network connections are functioning properly. Failure to detect link loss, or failure to take the proper actions when a problem is detected, can lead to black holes. 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. "A Generalized Model for Link Layer Triggers" [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 [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 data frames; links in the "down" state are unsuitable for sending and receiving data frames in either direction. Unfortunately, links 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, intermittent frame loss, or rapid changes in throughput 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 the integration of link indications with the Internet, transport, and application layers.
1.4. Layered Indication Model
A layered indication model is shown in Figure 1 that includes both internally generated link indications (such as link state and rate) and indications arising from external interactions such as path change detection. In this model, it is assumed that the link layer provides indications to higher layers primarily in the form of abstract indications that are link-technology agnostic.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Application | | Layer | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+ | ! ! ! | | ! ^ ^ | | Connection Management ! ! Teardown | Transport | ! ! | Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+ | ! ! | | ! ! | | ^ ! | | Transport Parameter Estimation ! | |(MSS, RTT, RTO, cwnd, bw, ssthresh)! | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ ^ ^ ^ ^ ^ ! ! ! ! ! ! ! +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ | ! ! Incoming !MIP ! ! ! | | ! ! Interface !BU ! ! ! | | ! ! Change !Receipt! ! ! | | ! ^ ^ ^ ! ^ | Internet | ! ! Mobility ! ! ! ! | Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ | ! ! Outgoing ! Path ! ! ! | | ! ! Interface ! Change! ! ! | | ^ ^ Change ^ ^ ! ^ | | ! ! ! ! | | ! Routing ! ! ! | +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ | ! ! v ! IP | | ! ! Path ! Address | | ! IP Configuration ^ Info ^ Config/ | | ! ! Cache Changes | +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ | ! ! | Link | ^ ^ | Layer | Rate, FER, Link | | Delay Up/Down | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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], redirect messages, or route updates incorporating information on the state of links multiple hops away. As described in "Packetization Layer Path MTU Discovery" [RFC4821], 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 optimize aspects of Internet Protocol (IP) configuration and mobility. After receipt of a "Link Up" indication, hosts validate potential IP configurations by Detecting Network Attachment (DNA) [RFC4436]. Once the IP configuration is confirmed, it may be determined that an address change has occurred. However, "Link Up" indications may not necessarily 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 bidirectional reachability test. In "Detecting Network Attachment in IPv6 Networks (DNAv6)" [DNAv6], IP configuration is validated using reachability detection and Router Solicitation/Advertisement. The routing sub-layer may utilize link indications in order to enable more rapid response to changes in link state and effective throughput. Link rate is often used in computing routing metrics. However, in wired networks the transmission rate may be negotiated in order to enhance energy efficiency [EfficientEthernet]. In wireless networks, the negotiated rate and Frame Error Rate (FER) may change
with link conditions so that effective throughput may vary on a packet-by-packet basis. In such situations, routing metrics may also exhibit rapid variation. Routing metrics incorporating link indications such as Link Up/Down and effective throughput enable routers to take link conditions into account for the purposes of route selection. If a link experiences decreased rate or high frame loss, the route metric will increase for the prefixes that it serves, encouraging use of alternate paths if available. When the link condition improves, the route metric will decrease, encouraging use of the link. Within Weak End System implementations, changes in routing metrics and link state may result in a change in the outgoing interface for one or more transport connections. Routes may also be added or withdrawn, resulting in loss or gain of peer connectivity. However, link indications such as changes in transmission rate or frame loss do not necessarily result in a change of outgoing interface. The Internet layer may also become aware of path changes by other mechanisms, such as receipt of updates from a routing protocol, receipt of a Router Advertisement, dead gateway detection [RFC816] or network unreachability detection [RFC2461], ICMP redirects, or a change in the IPv4 TTL (Time to Live)/IPv6 Hop Limit of received packets. A change in the outgoing interface may in turn influence the mobility sub-layer, causing a change in the 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 IP Binding Update [RFC3775]).1.4.2. Transport Layer
The transport layer processes received link indications differently for the purposes of transport parameter estimation and connection management. For the purposes of parameter estimation, the transport layer is primarily interested in path properties that impact performance, and where link indications may be determined to be relevant to path properties they may be utilized directly. Link indications such as "Link Up"/"Link Down" or changes in rate, delay, and frame loss may prove relevant. This will not always be the case, however; where the bandwidth of the bottleneck on the end-to-end path is already much lower than the transmission rate, an increase in transmission rate may not materially affect path properties. As described in Appendix A.3, the algorithms for utilizing link layer indications to improve transport parameter estimates are still under development.
Strict layering considerations do not apply in transport path parameter estimation in order to enable the transport layer to make use of all available information. For example, the transport layer may determine that a link indication came from a link forming part of a path of one or more connections. In this case, it may utilize the receipt of a "Link Down" indication followed by a subsequent "Link Up" indication to infer the possibility of non-congestive packet loss during the period between the indications, even if the IP configuration does not change as a result, so that no Internet layer indication would be sent. The transport layer may also find Internet layer indications useful for path parameter estimation. For example, path change indications can be used as a signal to reset path parameter estimates. Where there is no default route, loss of segments sent to a destination lacking a prefix in the local routing table may be assumed to be due to causes other than congestion, regardless of the reason for the removal (either because local link conditions caused it to be removed or because the route was withdrawn by a remote router). For the purposes of connection management, layering considerations are important. The transport layer may tear down a connection based on Internet layer indications (such as a endpoint address changes), but does not take link indications into account. Just as a "Link Up" event may not result in a configuration change, and a configuration change may not result in connection teardown, the transport layer does not tear down connections on receipt of a "Link Down" indication, regardless of the cause. Where the "Link Down" indication results from frame loss rather than an explicit exchange, the indication may be transient, to be soon followed by a "Link Up" indication. Even where the "Link Down" indication results from an explicit exchange such as receipt of a Point-to-Point Protocol (PPP) Link Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or Deauthenticate frame, an alternative point of attachment may be available, allowing connectivity to be quickly restored. As a result, robustness is best achieved by allowing connections to remain up until an endpoint address changes, or the connection is torn down due to lack of response to repeated retransmission attempts. For the purposes of connection management, the transport layer is cautious with the use of Internet layer indications. Changes in the routing table are not relevant for the purposes of connection management, since it is desirable for connections to remain up during transitory routing flaps. However, the transport layer may tear down transport connections due to invalidation of a connection endpoint IP address. Where the connection has been established based on a Mobile
IP home address, a change in the Care-of Address need not result in connection teardown, since the configuration change is masked by the mobility functionality within the Internet layer, and is therefore transparent to the transport layer. "Requirements for Internet Hosts -- Communication Layers" [RFC1122], Section 2.4, requires Destination Unreachable, Source Quench, Echo Reply, Timestamp Reply, and Time Exceeded ICMP messages to be passed up to the transport layer. [RFC1122], Section 4.2.3.9, requires Transmission Control Protocol (TCP) to react to an Internet Control Message Protocol (ICMP) Source Quench by slowing transmission. [RFC1122], Section 4.2.3.9, distinguishes between ICMP messages indicating soft error conditions, which must not cause TCP to abort a connection, and hard error conditions, which should cause an abort. ICMP messages indicating soft error conditions include Destination Unreachable codes 0 (Net), 1 (Host), and 5 (Source Route Failed), which may result from routing transients; Time Exceeded; and Parameter Problem. ICMP messages indicating hard error conditions include Destination Unreachable codes 2 (Protocol Unreachable), 3 (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment Was Set). Since hosts implementing classical ICMP-based Path MTU Discovery [RFC1191] use Destination Unreachable code 4, they do not treat this as a hard error condition. Hosts implementing "Path MTU Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big messages. As noted in "TCP Problems with Path MTU Discovery" [RFC2923], classical Path MTU Discovery is vulnerable to failure if ICMP messages are not delivered or processed. In order to address this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does depend on the delivery of ICMP messages. "Fault Isolation and Recovery" [RFC816], Section 6, states: It is not obvious, when error messages such as ICMP Destination Unreachable arrive, whether TCP should abandon the connection. The reason that error messages are difficult to interpret is that, as discussed above, after a failure of a gateway or network, there is a transient period during which the gateways may have incorrect information, so that irrelevant or incorrect error messages may sometimes return. An isolated ICMP Destination Unreachable may arrive at a host, for example, if a packet is sent during the period when the gateways are trying to find a new route. To abandon a TCP connection based on such a message arriving would be to ignore the valuable feature of the Internet that for many internal failures it reconstructs its function without any disruption of the end points.
"Requirements for IP Version 4 Routers" [RFC1812], Section 4.3.3.3, states that "Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion", indicating that routers should not originate them. In general, since the transport layer is able to determine an appropriate (and conservative) response to congestion based on packet loss or explicit congestion notification, ICMP Source Quench indications are not needed, and the sending of additional Source Quench packets during periods of congestion may be detrimental. "ICMP attacks against TCP" [Gont] argues that accepting ICMP messages based on a correct four-tuple without additional security checks is ill-advised. For example, an attacker forging an ICMP hard error message can cause one or more transport connections to abort. The authors discuss a number of precautions, including mechanisms for validating ICMP messages and ignoring or delaying response to hard error messages under various conditions. They also recommend that hosts ignore ICMP Source Quench messages. The transport layer may also provide information to the link layer. For example, the transport layer may wish to control the maximum number of times that a link layer frame may be retransmitted, so that the link layer does not continue to retransmit after a transport layer timeout. In IEEE 802.11, this can be achieved by adjusting the Management Information Base (MIB) [IEEE-802.11] 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. 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.1.4.3. Application Layer
The transport layer provides indications to the application layer by propagating Internet layer indications (such as IP address configuration and changes), as well as providing its own indications, such as connection teardown. Since applications can typically obtain the information they need more reliably from the Internet and transport layers, they will typically not need to utilize link indications. A "Link Up" indication implies that the link is capable of communicating IP packets, but does not indicate that it has been configured; applications should use an Internet layer "IP Address Configured" event instead. "Link Down" indications are typically not useful to
applications, since they can be rapidly followed by a "Link Up" indication; applications should respond to transport layer teardown indications instead. Similarly, changes in the transmission rate may not be relevant to applications if the bottleneck bandwidth on the path does not change; the transport layer is best equipped to determine this. As a result, Figure 1 does not show link indications being provided directly to applications.
(page 14 continued on part 2)
