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 (C) The IETF Trust (2007).
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.
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).
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].
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
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.
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
Binding Update (BU)
A message indicating a mobile node's current mobility binding,
and in particular its Care-of Address.
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
the Internet Protocol (IP).
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.
Information provided by the link layer to higher layers
regarding the state of the link.
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).
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.
A node that can change its point of attachment from one link to
another, while still being reachable via its home 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
Any IP address for which routers will forward packets. This
includes private addresses as specified in "Address Allocation
for Private Internets" [RFC1918].
Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
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.
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
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.
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
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
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
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
1.4.2. Transport Layer
The transport layer processes received link indications differently
for the purposes of transport parameter estimation and connection
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"
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 188.8.131.52, requires
Transmission Control Protocol (TCP) to react to an Internet Control
Message Protocol (ICMP) Source Quench by slowing transmission.
[RFC1122], Section 184.108.40.206, 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 220.127.116.11,
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.