tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4907

 Errata 
Informational
Pages: 62
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IAB

Architectural Implications of Link Indications

Part 1 of 4, p. 1 to 14
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part