Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4907

Architectural Implications of Link Indications

Pages: 62
Informational
Errata
Part 1 of 4 – Pages 1 to 14
None   None   Next

Top   ToC   RFC4907 - Page 1
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.
Top   ToC   RFC4907 - Page 2

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
Top   ToC   RFC4907 - Page 3

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.
Top   ToC   RFC4907 - Page 4
   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.
Top   ToC   RFC4907 - Page 5
   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].
Top   ToC   RFC4907 - Page 6
   "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.
Top   ToC   RFC4907 - Page 7

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.
Top   ToC   RFC4907 - Page 8
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   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
Top   ToC   RFC4907 - Page 9

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
Top   ToC   RFC4907 - Page 10
   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.
Top   ToC   RFC4907 - Page 11
   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
Top   ToC   RFC4907 - Page 12
   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.
Top   ToC   RFC4907 - Page 13
   "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
Top   ToC   RFC4907 - Page 14
   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)

Next Section