[要約] RFC 4907は、リンク指示のアーキテクチャ上の影響について説明しており、リンク状態の通知に関する標準化を目的としています。
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).
著作権（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
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では、インターネットアーキテクチャ内のリンク表示の履歴を説明し、リンク表示を利用するためのモデルを提供します。セクション2では、建築上の考慮事項について説明し、著者を文書化するためのアドバイスを提供します。セクション3では、推奨事項と将来の作業について説明します。付録Aは、主にワイヤレスローカルエリアネットワーク（WLAN）に焦点を当てたリンク表示に関する文献をまとめたものです。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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 associated stations.
アクセスポイント（AP）関連ステーションのワイヤレスメディア（WM）を介して、固定ネットワーク（802.11配信システムなど）へのアクセスを提供するステーション。
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.
非対称トランスミッターと受信機の相対的な位置または設計特性によって異なる伝送特性を持つリンクは、非対称であると言われています。たとえば、1つの送信機の範囲は、同じ媒体上の別の送信機の範囲よりもはるかに高い場合があります。
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.
バインディングアップデート（by）モバイルノードの電流モビリティバインディング、特にそのケアアドレスを示すメッセージ。
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).
リンクリンクレイヤー、つまりインターネットプロトコル（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).
リンクレイヤーリンクの制御の維持を担当する制御または処理ロジックの概念レイヤー。リンクレイヤー関数は、高層ロジックとリンクの間のインターフェイスを提供します。リンクレイヤーは、インターネットプロトコル（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.
最大セグメントサイズ（MSS）輸送層が利用できる最大ペイロードサイズ。
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.
最大送信ユニット（MTU）リンクまたはパスで送信できるIPヘッダーとペイロードを含む最大のIPパケットのオクテットのサイズ。
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].
ルーターアドレスルーターがパケットを転送するIPアドレス。これには、「プライベートインターネットのアドレス割り当て」で指定されているプライベートアドレスが含まれます[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).
ステーション（STA）IEEE 802.11を含むデバイスは、ワイヤレス媒体（WM）へのIEEE 802.11コンフォーマントミディアムアクセス制御（MAC）および物理層（PHY）インターフェイスを含む。
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.
強いエンドシステムモデルStrong End Systemモデルは、ホスト/ルーターの区別を強調し、同じ物理ホスト内の論理ホストのセットとしてマルチホームホストをモデル化する傾向があります。Strong Endシステムモデルでは、アドレスは、付着するホストではなく、インターフェイスを参照しています。その結果、送信インターフェイスで送信されたパケットには、そのインターフェイスにソースアドレスが構成されており、宛先アドレスが受信した物理インターフェイスに対応していない着信パケットが静かに破棄されます。
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.
Weak End System Model beaw end systemモデル、アドレスはホストを参照します。その結果、送信インターフェイスで送信されたパケットには、必ずしもそのインターフェイスにソースアドレスを構成する必要はありません。また、宛先アドレスが受信した物理インターフェイスに対応しない着信パケットが受け入れられます。
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].
インターネットアーキテクチャ内のリンク適応症の使用には、長い歴史があります。オフラインのホストに送信しようとする試みに応じて、ARPANETリンクレイヤープロトコルは、「障害分離と回復」に記載されている「目的地の死んでいる」兆候を提供しました[RFC816]。ARPANETパケット無線実験[PRNET]ルーティングメトリックの計算に組み込まれたフレームの損失。これは、「マルチホップのハイスループットパスメトリック」に記載されている予想される伝送カウント（ETX）などの最近のリンク認識ルーティングメトリックの前兆（ETX）ワイヤレスルーティング」[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]:
「ルーティング情報プロトコル」[RFC1058]は、Xerox Network Systems（XNS）ルーティング情報プロトコルから派生したRIPを定義しました。「OSPF仕様」[RFC1131]は、OSPF領域内のリンクステータスに関連する情報をflood濫させるために、Link State Advertisements（LSA）を使用するOpen最短パスを最初に定義しました。[RFC2328]は、OSPFのバージョン2を定義します。これらおよびその他のルーティングプロトコルは、それらをサポートするリンクによって提供される「リンクアップ」および「リンクダウン」の表示を利用できますが、ルーティングパケットの損失に基づいてリンクの損失を検出することもできます。「IPバージョン4ルーターの要件」[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.
「リンクアップ」や「リンクダウン」以外のリンク表示を定義する試みも行われています。「動的に切り替えられたリンク制御プロトコル」[RFC1307]は、リンクの制御のための実験的なプロトコルを定義し、「ダウン」、「上に」、「上に」、「ダウン」、「倒す」、「持ち上げ」状態を組み込みます。
"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".
「リンクレイヤートリガーの一般化されたモデル」[Gentrig]は、「リンクアップ」、「リンクダウン」、「リンクダウン」、「リンクの上にリンク」、「リンクの品質クロスしきい値」、「トリガーなど、「汎用トリガー」を定義します。ロールバック」、および「より良い信号品質APが利用可能」。IEEE 802.21 [IEEE-802.21]は、リンク特性、リンクステータス、リンク品質に関するイベントレポートを提供するメディア独立ハンドオーバーイベントサービス（MIH-ES）を定義します。定義されたイベントには、「リンクダウン」、「リンクアップ」、「リンクダウン」、「リンク信号強度」、「リンク信号/ノイズ比」が含まれます。
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.
理想的な条件下では、「UP」状態のリンクは、両方向の低いフレーム損失を経験し、すぐにデータフレームを送信および受信する準備ができています。「ダウン」状態のリンクは、いずれかの方向にデータフレームを送信および受信するのに適していません。
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.
残念ながら、リンクは頻繁に非理想的な動作を示します。有線リンクは、半分二重モードで故障する可能性があるか、部分的な障害を示して、中間損失率をもたらします。ワイヤレスリンクは、干渉または信号フェージングによる非対称性、断続的なフレーム損失、またはスループットの急速な変化を示す場合があります。有線リンクとワイヤレスリンクの両方で、リンク状態は「UP」と「ダウン」状態の間を急速に羽ばたきます。この現実世界の動作は、インターネット、輸送、アプリケーション層とのリンク表示を統合するための課題を提示します。
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に示します。これには、内部生成されたリンク表示（リンク状態やレートなど）と、パス変更検出などの外部相互作用から生じる表示が含まれます。このモデルでは、リンクレイヤーは、主にリンクテクノロジーの不可知論者である抽象的な兆候の形で、より高い層への適応症を提供すると想定されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.層状表示モデル
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.
インターネット層の機能の1つは、リンク動作の詳細からより高いレイヤーを保護することです。その結果、インターネットレイヤーはリンク表示を検証およびフィルタリングし、ルーティングメトリックに基づいて発信および着信インターフェイスを選択します。
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.
インターネットレイヤーは、ローカルインターフェイスから利用可能な情報に基づいて、ルーターが提供する情報を考慮して潜在的に使用できる情報に基づいてルーティングテーブルを構成します。これにより、ローカルルーティングテーブルの状態は、ローカルリンクとリモートリンクの両方のリンク条件を反映できます。たとえば、ルーティングテーブルから追加または削除するプレフィックスは、動的ホスト構成プロトコル（DHCP）[RFC2131] [RFC3315]、ルーター広告[RFC2461] [RFC2461]、リダイレクトメッセージ、またはリダイレクト情報の更新をルーティングします。リンクの状態は複数のホップを離れています。
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.
「パケット化レイヤーパスMTUディスカバリー」[RFC4821]で説明されているように、インターネットレイヤーはパス情報キャッシュを維持し、同時または後続の接続間のパスMTU情報の共有を可能にすることができます。共有キャッシュは、パケット化レイヤーパス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 configuration.
インターネットレイヤーは、インターネットプロトコル（IP）の構成とモビリティの側面を最適化するために、リンク表示も利用しています。「リンクアップ」表示を受け取った後、ネットワークアタッチメント（DNA）[RFC4436]を検出することにより、潜在的なIP構成を検証します。IP構成が確認されると、アドレスの変更が発生したと判断される場合があります。ただし、「リンクアップ」表示は、必ずしもインターネットレイヤーの構成に変更されるとは限りません。
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.
「IPv4でのネットワークアタッチメントの検出」[RFC4436]では、「リンクアップ」表示を受け取った後、潜在的なIP構成が双方向の到達可能性テストを使用して検証されます。「IPv6ネットワーク（DNAV6）のネットワークアタッチメントの検出」[DNAV6]では、IP構成はReachability検出とルーターの勧誘/広告を使用して検証されます。
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.
ルーティングサブレイヤーは、リンク状態と効果的なスループットの変化に対するより迅速な応答を可能にするために、リンク表示を利用する場合があります。リンクレートは、多くの場合、ルーティングメトリックを計算する際に使用されます。ただし、有線ネットワークでは、エネルギー効率を向上させるために送信速度が交渉される場合があります[EfficientEthernet]。ワイヤレスネットワークでは、ネゴシエートされたレートとフレームエラー率（FER）がリンク条件で変化する可能性があるため、効果的なスループットがパケットごとに異なる場合があります。このような状況では、ルーティングメトリックも急速な変動を示す場合があります。
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.
弱いエンドシステムの実装内では、ルーティングメトリックとリンク状態の変更により、1つ以上の輸送接続の発信インターフェイスが変更される可能性があります。また、ルートを追加または撤回することができ、ピア接続の喪失または獲得をもたらします。ただし、伝送速度やフレーム損失の変更などのリンク表示は、必ずしも発信インターフェイスの変更をもたらすものではありません。
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]).
また、インターネット層は、ルーティングプロトコルからの更新の受領、ルーター広告の受領、デッドゲートウェイ検出[RFC816]、またはネットワークのない到達性検出[RFC2461]、ICMPリダイレクト、または変更など、他のメカニズムによるパスの変更を認識することもできます。IPv4 TTL（Live to Live）/IPv6ホップの受信パケットの制限。発信インターフェイスの変化は、モビリティサブレイヤーに影響を与え、着信インターフェイスの変化を引き起こす可能性があります。モビリティサブレイヤーは、ピアの着信インターフェイスの変化を認識することもできます（モバイルIPバインディングアップデート[RFC3775]を受信して）。
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.
パラメーターの推定の目的のために、輸送層は主にパフォーマンスに影響を与えるパスプロパティに関心があり、リンク適応が直接利用できるパスプロパティに関連すると判断される場合があります。「リンクアップ」/「リンクダウン」やレート、遅延、フレームの損失の変更などのリンク表示は、関連性があることが証明される場合があります。ただし、これは必ずしもそうではありません。エンドツーエンドパスのボトルネックの帯域幅が透過速度よりもはるかに低い場合、伝送速度の増加はパスプロパティに大きく影響しない可能性があります。付録A.3で説明したように、リンクレイヤー表示を利用して輸送パラメーターの推定値を改善するためのアルゴリズムはまだ開発中です。
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.
厳格な階層化の考慮事項は、輸送層が利用可能なすべての情報を利用できるようにするために、トランスポートパスパラメーターの推定には適用されません。たとえば、輸送層は、1つ以上の接続のパスの一部を形成するリンクからリンクの表示が生じたと判断する場合があります。この場合、IP構成が変更されなくても、「リンクダウン」表示の受領を利用して、その後の「リンク」リンクアップ「表示」が表示され、適応症の期間中の非同一のパケット損失の可能性を推測することができます。その結果、インターネットレイヤーの表示が送信されないように。
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.
「リンクダウン」の表示が、ポイントツーポイントプロトコル（PPP）リンク制御プロトコル（LCP）のターミネートまたはIEEE 802.11の分離または不測の味のフレームの受領などの明示的な交換に起因する場合でも、添付ファイルの代替点は利用可能になり、接続をすばやく復元できます。その結果、エンドポイントアドレスが変更されるまで接続を維持できるようにすることで、堅牢性は最適に達成されます。または、再送信の繰り返しの試みに対する応答がないため、接続が取り壊されます。
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.
接続管理の目的のために、輸送層はインターネットレイヤーの適応症の使用に慎重です。ルーティングテーブルの変更は、接続管理の目的には関係ありません。これは、一時的なルーティングフラップ中に接続が維持されることが望ましいためです。ただし、接続エンドポイントIPアドレスの無効化により、輸送層は輸送接続を取り壊す可能性があります。モバイルIPホームアドレスに基づいて接続が確立されている場合、構成の変更はインターネットレイヤー内のモビリティ機能によってマスクされているため、接続された断落につながる必要はありません。したがって、輸送層。
"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]、セクション2.4には、宛先の到達不能、ソースクエンチ、エコー返信、タイムスタンプの返信が必要です。[RFC1122]、セクション4.2.3.9では、伝送を遅らせることにより、インターネット制御メッセージプロトコル（ICMP）ソースクエンチに対応するために、伝送制御プロトコル（TCP）が必要です。
[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.
[RFC1122]、セクション4.2.3.9は、TCPに接続を中止させてはならないソフトエラー条件を示すICMPメッセージと、中止を引き起こすハードエラー条件を区別します。ソフトエラーの条件を示すICMPメッセージには、宛先のないコード0（ネット）、1（ホスト）、および5（ソースルートが失敗しました）が含まれます。時間を超えました。およびパラメーターの問題。硬いエラー条件を示すICMPメッセージには、宛先の到達不可能なコード2（プロトコルが到達不可能）、3（到達不能）、および4（断片化が必要であり、断片が設定されない）が含まれます。クラシックICMPベースのパスMTU発見[RFC1191]を実装するホストは、宛先のないコード4を使用しているため、これをハードエラー条件として扱いません。「IPバージョン6のPATH MTU Discovery」を実装するホスト[RFC1981]は、ICMPV6パケットを使用しすぎています。「PATH MTU発見のTCP問題」[RFC2923]で述べたように、ICMPメッセージが配信または処理されない場合、古典的なパスMTU発見は障害に対して脆弱です。この問題に対処するために、「パケット化レイヤーパスMTUディスカバリー」[RFC4821]は、ICMPメッセージの配信に依存します。
"Fault Isolation and Recovery" [RFC816], Section 6, states:
「断層分離と回復」[RFC816]、セクション6、次のように述べています。
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.
TCPが接続を放棄する必要があるかどうか、ICMP宛先の到達不可能な到着などのエラーメッセージが到着する場合、それは明らかではありません。エラーメッセージを解釈するのが難しい理由は、上記で説明したように、ゲートウェイまたはネットワークの障害後、ゲートウェイに誤った情報がある可能性があるため、無関係または誤ったエラーメッセージが返される可能性があるための一時的な期間があるためです。隔離されたICMPの宛先が到達できない場合、たとえば、ゲートウェイが新しいルートを見つけようとしている期間中にパケットが送信された場合、ホストに到着する場合があります。このようなメッセージに基づいてTCP接続を放棄することは、多くの内部障害でエンドポイントを混乱させることなく機能を再構築するというインターネットの貴重な機能を無視することです。
"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.
「IPバージョン4ルーターの要件」[RFC1812]、セクション4.3.3.3は、「ソースクエンチはネットワーク帯域幅を消費するが、輻輳に対する効果がない（そして不公平な）解毒剤であることを示唆している」と述べています。。一般に、輸送層はパケットの損失または明示的な輻輳通知に基づく輻輳に対する適切な（および保守的な）応答を決定できるため、ICMPソースクエンチの表示は必要ありません。有害である。
"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.
「TCPに対するICMP攻撃」[Gont]は、追加のセキュリティチェックなしの正しい4タプルに基づいてICMPメッセージを受け入れることは賢明ではないと主張しています。たとえば、攻撃者がICMPハードエラーメッセージを偽造すると、1つ以上の輸送接続が中止される可能性があります。著者は、ICMPメッセージを検証するメカニズムや、さまざまな条件下でのハードエラーメッセージへの応答を無視または遅延させるための多くの予防策について議論します。また、ホストはICMPソースクエンチメッセージを無視することをお勧めします。
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.
輸送層は、リンク層に情報を提供する場合があります。たとえば、輸送層は、リンクレイヤーフレームが再送信される可能性がある最大回数を制御したい場合があるため、輸送層のタイムアウト後もリンク層が再送信され続けないようにすることができます。IEEE 802.11では、管理情報ベース（MIB）[IEEE-802.11]変数dot11shortretrylimit（デフォルト：7）およびdot11longretrylimit（デフォルト：4）を調整することで実現できます。それぞれdot11rtSthresholdよりも長さ。ただし、これらの変数はリンクの動作全体を制御するため、輸送ごとの接続ベースで動作を個別に調整するために使用することはできません。リンク層の再送信タイムアウトがパスの往復タイムアウトと同じ順序である状況では、リンクレイヤー制御はまったく不可能かもしれません。
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.
トランスポートレイヤーは、インターネットレイヤーの表示（IPアドレスの構成や変更など）を伝播することにより、接続の分解などの独自の表示を提供することにより、アプリケーションレイヤーへの適応症を提供します。
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.
アプリケーションは通常、インターネットと輸送層からより確実に必要な情報を取得できるため、通常、リンクの表示を利用する必要はありません。「リンクアップ」の表示は、リンクがIPパケットを通信できることを意味しますが、構成されていることを示していません。アプリケーションは、代わりにインターネットレイヤー「IPアドレス構成」イベントを使用する必要があります。「リンクダウン」の表示は、通常、アプリケーションには役に立たないため、「リンクアップ」表示が迅速に続く可能性があります。アプリケーションは、代わりに輸送層の分解指標に応答する必要があります。同様に、パス上のボトルネックの帯域幅が変わらない場合、伝送速度の変更はアプリケーションに関連しない場合があります。輸送層は、これを決定するのに最適です。その結果、図1は、アプリケーションに直接提供されるリンクの表示を示していません。
The complexity of real-world link behavior poses a challenge to the integration of link indications within the Internet architecture. While the literature provides persuasive evidence of the utility of link indications, difficulties can arise in making effective use of them. To avoid these issues, the following architectural principles are suggested and discussed in more detail in the sections that follow:
実際のリンク動作の複雑さは、インターネットアーキテクチャ内のリンク表示の統合に課題をもたらします。文献は、リンク適応の有用性に関する説得力のある証拠を提供していますが、それらを効果的に使用することは困難なことが生じる可能性があります。これらの問題を回避するために、次のアーキテクチャの原則が提案され、以下のセクションでより詳細に説明されています。
(1) Proposals should avoid use of simplified link models in circumstances where they do not apply (Section 2.1).
(1) 提案は、適用されない状況で単純化されたリンクモデルの使用を避ける必要があります（セクション2.1）。
(2) Link indications should be clearly defined, so that it is understood when they are generated on different link layers (Section 2.2).
(2) リンクの表示は、異なるリンクレイヤーで生成されると理解されるように、明確に定義する必要があります（セクション2.2）。
(3) Proposals must demonstrate robustness against spurious link indications (Section 2.3).
(3) 提案は、偽のリンクの表示に対する堅牢性を示す必要があります（セクション2.3）。
(4) Upper layers should utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on (Section 2.3.2).
(4) 上層層は、タイムリーな回復ステップを利用して、作用後に無効であると判断されたリンク表示からの潜在的な損傷を制限する必要があります（セクション2.3.2）。
(5) Proposals must demonstrate that effective congestion control is maintained (Section 2.4).
(5) 提案は、効果的な混雑制御が維持されていることを実証する必要があります（セクション2.4）。
(6) Proposals must demonstrate the effectiveness of proposed optimizations (Section 2.5).
(6) 提案は、提案された最適化の有効性を実証する必要があります（セクション2.5）。
(7) Link indications should not be required by upper layers, in order to maintain link independence (Section 2.6).
(7) リンクの独立性を維持するために、リンクの表示を上層層で必要としないでください（セクション2.6）。
(8) Proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack (Section 2.7).
(8) 提案は、スタックの複数のレイヤーによってリンク表示が直接使用される場合に発生する可能性のある人種条件を避ける必要があります（セクション2.7）。
(9) Proposals should avoid inconsistencies between link and routing layer metrics (Section 2.7.3).
(9) 提案は、リンクとルーティング層のメトリックとの間の矛盾を避ける必要があります（セクション2.7.3）。
(10) Overhead reduction schemes must avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers (Section 2.8).
（10）オーバーヘッド削減スキームは、相互運用性の侵害とリンクレイヤーの依存関係をインターネットおよび輸送層に導入することを避けなければなりません（セクション2.8）。
(11) Proposals for transport of link indications beyond the local host need to carefully consider the layering, security, and transport implications (Section 2.9).
（11）ローカルホストを超えたリンク適応の輸送に関する提案は、レイヤー化、セキュリティ、および輸送の意味を慎重に検討する必要があります（セクション2.9）。
Proposals should avoid the use of link models in circumstances where they do not apply.
提案は、適用されない状況でのリンクモデルの使用を避ける必要があります。
In "The mistaken axioms of wireless-network research" [Kotz], the authors conclude that mistaken assumptions relating to link behavior may lead to the design of network protocols that may not work in practice. For example, the authors note that the three-dimensional nature of wireless propagation can result in large signal strength changes over short distances. This can result in rapid changes in link indications such as rate, frame loss, and signal strength.
「ワイヤレスネットワーク研究の誤った公理」[Kotz]で、著者は、リンク動作に関連する誤った仮定が実際には機能しない可能性のあるネットワークプロトコルの設計につながる可能性があると結論付けています。たとえば、著者らは、ワイヤレス伝播の3次元性が短い距離にわたって大きな信号強度の変化をもたらす可能性があることに注目しています。これにより、レート、フレームの損失、信号強度などのリンク表示に急速な変化が生じる可能性があります。
In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], the authors provide examples of modeling mistakes and examples of how to improve modeling of link characteristics. To accompany the paper, the authors provide simulation scenarios in ns-2.
「輸送プロトコルのワイヤレスリンクのモデリング」[Gurtovfloyd]では、著者はモデリングミスの例と、リンク特性のモデリングを改善する方法の例を提供します。論文に付随するために、著者はNS-2のシミュレーションシナリオを提供します。
In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], documents that describe capabilities that are dependent on link indications should explicitly articulate the assumptions of the link model and describe the circumstances in which they apply.
[Kotz] [Gurtovfloyd]に記載されている落とし穴を回避するために、リンク表示に依存する機能を説明するドキュメントは、リンクモデルの仮定を明示的に明確に表現し、それらが適用される状況を説明する必要があります。
Generic "trigger" models may include implicit assumptions that may prove invalid in outdoor or mesh wireless LAN deployments. For example, two-state Markov models assume that the link is either in a state experiencing low frame loss ("up") or in a state where few frames are successfully delivered ("down"). In these models, symmetry is also typically assumed, so that the link is either "up" in both directions or "down" in both directions. In situations where intermediate loss rates are experienced, these assumptions may be invalid.
汎用「トリガー」モデルには、屋外またはメッシュのワイヤレスLAN展開で無効であることが証明される可能性のある暗黙の仮定が含まれる場合があります。たとえば、2つの状態のマルコフモデルは、リンクが低フレームの損失（「UP」）を経験する状態にあるか、ほとんどのフレームが正常に配信される（「ダウン」）状態であると仮定します。これらのモデルでは、対称性も通常想定されているため、リンクは両方向に「上」または両方向に「下」になります。中間損失率が経験されている状況では、これらの仮定が無効である可能性があります。
As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev], signal strength data is noisy and sometimes inconsistent, so that it needs to be filtered in order to avoid erratic results. Given this, link indications based on raw signal strength data may be unreliable. In order to avoid problems, it is best to combine signal strength data with other techniques. For example, in developing a "Going Down" indication for use with [IEEE-802.21] it would be advisable to validate filtered signal strength measurements with other indications of link loss such as lack of Beacon reception.
「IEEE 802.11のハイブリッドレート制御」[Haratcherev]で述べたように、信号強度データは騒々しく、時には一貫性がないため、不安定な結果を避けるためにフィルタリングする必要があります。これを考えると、生の信号強度データに基づくリンクの表示は信頼できない場合があります。問題を回避するために、信号強度データと他の手法を組み合わせることが最善です。たとえば、[IEEE-802.21]で使用する「ダウンする」兆候を開発する際には、ビーコン受信の欠如などのリンク損失の他の適応症とともに、フィルタリングされた信号強度測定を検証することをお勧めします。
Link indications should be clearly defined, so that it is understood when they are generated on different link layers. For example, considerable work has been required in order to come up with the definitions of "Link Up" and "Link Down", and to define when these indications are sent on various link layers.
リンクの表示は、異なるリンクレイヤーで生成されるときに理解されるように、明確に定義する必要があります。たとえば、「リンクアップ」と「リンクダウン」の定義を考え出し、これらの適応症がさまざまなリンクレイヤーに送信されるときを定義するためには、かなりの作業が必要です。
Link indication definitions should heed the following advice:
リンク表示の定義は、次のアドバイスに注意する必要があります。
(1) Do not assume symmetric link performance or frame loss that is either low ("up") or high ("down").
(1) 低い（ "" up）またはhigh（ "down"）の対称リンクパフォーマンスまたはフレーム損失を想定しないでください。
In wired networks, links in the "up" state typically experience low frame loss in both directions and are ready to send and receive data frames; links in the "down" state are unsuitable for sending and receiving data frames in either direction. Therefore, a link providing a "Link Up" indication will typically experience low frame loss in both directions, and high frame loss in any direction can only be experienced after a link provides a "Link Down" indication. However, these assumptions may not hold true for wireless LAN networks. Asymmetry is typically less of a problem for cellular networks where propagation occurs over longer distances, multi-path effects may be less severe, and the base station can transmit at much higher power than mobile stations while utilizing a more sensitive antenna.
有線ネットワークでは、「UP」状態のリンクは通常、両方向の低いフレーム損失を発生し、データフレームを送信および受信する準備ができています。「ダウン」状態のリンクは、いずれかの方向にデータフレームを送信および受信するのに適していません。したがって、「リンクアップ」の表示を提供するリンクは、通常、両方向のフレーム損失が低くなり、リンクが「リンクダウン」の表示を提供した後にのみ、任意の方向の高いフレーム損失が発生します。ただし、これらの仮定は、ワイヤレスLANネットワークに当てはまらない場合があります。非対称性は通常、長い距離で伝播が発生するセルラーネットワークの問題ではありません。マルチパス効果はそれほど深刻ではなく、ベースステーションは、より敏感なアンテナを利用しながら、モバイルステーションよりもはるかに高い電力で送信できます。
Specifications utilizing a "Link Up" indication should not assume that receipt of this indication means that the link is experiencing symmetric link conditions or low frame loss in either direction. In general, a "Link Up" event should not be sent due to transient changes in link conditions, but only due to a change in link layer state. It is best to assume that a "Link Up" event may not be sent in a timely way. Large handoff latencies can result in a delay in the generation of a "Link Up" event as movement to an alternative point of attachment is delayed.
「リンクアップ」表示を使用している仕様は、この表示の受領を、リンクが対称リンク条件またはどちらの方向でも低いフレーム損失を経験していることを想定してはなりません。一般に、「リンクアップ」イベントは、リンク条件の一時的な変化のために送信されるべきではなく、リンク層状態の変化のためにのみ送信されるべきではありません。「リンクアップ」イベントがタイムリーに送信されない可能性があると仮定するのが最善です。ハンドオフレイテンシが大きいと、アタッチメントの代替ポイントへの移動が遅れているため、「リンクアップ」イベントの生成が遅れます。
(2) Consider the sensitivity of link indications to transient link conditions. Due to common effects such as multi-path interference, signal strength and signal to noise ratio (SNR) may vary rapidly over a short distance, causing erratic behavior of link indications based on unfiltered measurements. As noted in [Haratcherev], signal strength may prove most useful when utilized in combination with other measurements, such as frame loss.
(2) 一時的なリンク条件に対するリンク適応の感度を考慮してください。マルチパス干渉などの一般的な効果により、信号強度と信号対騒音比（SNR）は短い距離で急速に変化する可能性があり、フィルタリングされていない測定に基づいてリンク適応の不安定な動作を引き起こす可能性があります。[Haratcherev]に記載されているように、信号強度は、フレーム損失などの他の測定値と組み合わせて使用すると最も有用であることが証明される場合があります。
(3) Where possible, design link indications with built-in damping. By design, the "Link Up" and "Link Down" events relate to changes in the state of the link layer that make it able and unable to communicate IP packets. These changes are generated either by the link layer state machine based on link layer exchanges (e.g., completion of the IEEE 802.11i four-way handshake for "Link Up", or receipt of a PPP LCP-Terminate for "Link Down") or by protracted frame loss, so that the link layer concludes that the link is no longer usable. As a result, these link indications are typically less sensitive to changes in transient link conditions.
(3) 可能であれば、ビルトインダンピングを使用したデザインリンクの表示。設計上、「リンクアップ」と「リンクダウン」イベントは、IPパケットを通信できないようにするリンクレイヤーの状態の変更に関連しています。これらの変更は、リンクレイヤー交換に基づいたリンクレイヤー状態マシンによって生成されます（たとえば、「リンクアップ」のIEEE 802.11iの4方向握手の完了、または「リンクダウン」のPPP LCPターミネートの受領）または長期にわたるフレーム損失により、リンクレイヤーがリンクが使用できなくなったと結論付けます。その結果、これらのリンク表示は、通常、過渡リンク条件の変化に敏感ではありません。
(4) Do not assume that a "Link Down" event will be sent at all, or that, if sent, it will be received in a timely way. A good link layer implementation will both rapidly detect connectivity failure (such as by tracking missing Beacons) while sending a "Link Down" event only when it concludes the link is unusable, not due to transient frame loss.
(4) 「リンクダウン」イベントがまったく送信されると、または送信された場合、タイムリーに受信されると想定しないでください。優れたリンクレイヤーの実装は、一時的なフレームの損失によるものではなく、リンクが使用できないと結論付けた場合にのみ、「リンクダウン」イベントを送信する一方で、接続障害を迅速に検出します（欠落しているビーコンの欠落」イベントの両方が迅速に検出されます。
However, existing wireless LAN implementations often do not do a good job of detecting link failure. During a lengthy detection phase, a "Link Down" event is not sent by the link layer, yet IP packets cannot be transmitted or received on the link. Initiation of a scan may be delayed so that the station cannot find another point of attachment. This can result in inappropriate backoff of retransmission timers within the transport layer, among other problems. This is not as much of a problem for cellular networks that utilize transmit power adjustment.
ただし、既存のワイヤレスLAN実装は、リンク障害を検出するのに適した仕事をしないことがよくあります。長い検出フェーズでは、「リンクダウン」イベントはリンクレイヤーによって送信されませんが、IPパケットをリンクで送信または受信することはできません。スキャンの開始が遅れているため、ステーションが別の添付ポイントを見つけることができないようにします。これにより、他の問題の中でも、輸送層内の再送信タイマーの不適切なバックオフが生じる可能性があります。これは、送信電力調整を利用するセルラーネットワークにとってそれほど問題ではありません。
Link indication proposals must demonstrate robustness against misleading indications. Elements to consider include:
リンク表示提案は、誤解を招く指示に対する堅牢性を示す必要があります。考慮すべき要素は次のとおりです。
Implementation variation Recovery from invalid indications Damping and hysteresis
無効な適応症からの実装の変動回復減衰とヒステリシス
Variations in link layer implementations may have a substantial impact on the behavior of link indications. These variations need to be taken into account in evaluating the performance of proposals. For example, radio propagation and implementation differences can impact the reliability of link indications.
リンク層の実装の変動は、リンク表示の動作に大きな影響を与える可能性があります。これらのバリエーションは、提案のパフォーマンスを評価する際に考慮する必要があります。たとえば、無線の伝播と実装の違いは、リンク表示の信頼性に影響を与える可能性があります。
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors analyze the cause of frame loss in a 38-node urban multi-hop IEEE 802.11 ad-hoc network. In most cases, links that are very bad in one direction tend to be bad in both directions, and links that are very good in one direction tend to be good in both directions. However, 30 percent of links exhibited loss rates differing substantially in each direction.
「802.11bメッシュネットワークからのリンクレベルの測定」[Aguayo]では、著者は38ノードの都市マルチホップIEEE 802.11アドホックネットワークのフレーム損失の原因を分析しています。ほとんどの場合、一方向で非常に悪いリンクは両方方向に悪い傾向があり、一方向に非常に良いリンクは両方方向に良い傾向があります。ただし、リンクの30％が損失率を示し、それぞれの方向が大幅に異なりました。
As described in [Aguayo], wireless LAN links often exhibit loss rates intermediate between "up" (low loss) and "down" (high loss) states, as well as substantial asymmetry. As a result, receipt of a "Link Up" indication may not necessarily indicate bidirectional reachability, since it could have been generated after exchange of small frames at low rates, which might not imply bidirectional connectivity for large frames exchanged at higher rates.
[Aguayo]で説明されているように、ワイヤレスLANリンクは、しばしば「上」（低損失）と「下」（高い損失）状態の中間の損失率を示し、かなりの非対称性を示します。その結果、「リンクアップ」表示の受領は、低レートでの小さなフレームの交換後に生成された可能性があるため、必ずしも双方向の到達可能性を示すとは限りません。
Where multi-path interference or hidden nodes are encountered, signal strength may vary widely over a short distance. Several techniques may be used to reduce potential disruptions. Multiple transmitting and receiving antennas may be used to reduce multi-path effects; transmission rate adaptation can be used to find a more satisfactory transmission rate; transmit power adjustment can be used to improve signal quality and reduce interference; Request-to-Send/Clear-to-Send (RTS/CTS) signaling can be used to reduce hidden node problems. These techniques may not be completely effective, so that high frame loss may be encountered, causing the link to cycle between "up" and "down" states.
マルチパス干渉または隠されたノードに遭遇する場合、信号強度は短い距離で大きく異なる場合があります。潜在的な混乱を減らすために、いくつかの手法を使用することができます。マルチパス効果を低減するために、複数の送信および受信アンテナを使用できます。トランスミッションレートの適応を使用して、より満足のいく透過率を見つけることができます。送信電力調整は、信号の品質を改善し、干渉を減らすために使用できます。リクエスト - センド/クリア対センド（RTS/CTS）シグナル伝達を使用して、非表示ノードの問題を軽減できます。これらの手法は完全に効果的ではない可能性があるため、高いフレーム損失に遭遇する可能性があり、リンクが「上」状態と「ダウン」状態の間のサイクルになります。
To improve robustness against spurious link indications, it is recommended that upper layers treat the indication as a "hint" (advisory in nature), rather than a "trigger" dictating a particular action. Upper layers may then attempt to validate the hint.
スプリアスリンクの適応に対する堅牢性を改善するために、上層層は、特定のアクションを指示する「トリガー」ではなく、「トリガー」ではなく、「ヒント」（本質的なアドバイザリー）として扱うことをお勧めします。上層層は、ヒントを検証しようとする場合があります。
In [RFC4436], "Link Up" indications are rate limited, and IP configuration is confirmed using bidirectional reachability tests carried out coincident with a request for configuration via DHCP. As a result, bidirectional reachability is confirmed prior to activation of an IP configuration. However, where a link exhibits an intermediate loss rate, demonstration of bidirectional reachability may not necessarily indicate that the link is suitable for carrying IP data packets.
[RFC4436]では、「リンクアップ」表示はレートに制限されており、DHCPを介した構成の要求と一致する双方向Reachabilityテストを使用してIP構成が確認されます。その結果、IP構成のアクティブ化の前に、双方向の到達可能性が確認されます。ただし、リンクが中間損失率を示している場合、双方向の到達可能性のデモンストレーションは、リンクがIPデータパケットを運ぶのに適していることを必ずしも示すとは限りません。
Another example of validation occurs in IPv4 Link-Local address configuration [RFC3927]. Prior to configuration of an IPv4 Link-Local address, it is necessary to run a claim-and-defend protocol. Since a host needs to be present to defend its address against another claimant, and address conflicts are relatively likely, a host returning from sleep mode or receiving a "Link Up" indication could encounter an address conflict were it to utilize a formerly configured IPv4 Link-Local address without rerunning claim and defend.
検証の別の例は、IPv4リンクローカルアドレス構成[RFC3927]で発生します。IPv4 Link-Localアドレスを構成する前に、クレームアンドディフェンスプロトコルを実行する必要があります。ホストが別の請求者に対して住所を守るために存在する必要があり、住所の競合が比較的可能性が高いため、ホストはスリープモードから戻ってきたか、「リンクアップ」の表示を受け取ることで、以前に構成されていたIPv4リンクを利用するために住所の競合に遭遇する可能性があります - 請求と防御のないローカルアドレス。
In some situations, improper use of link indications can result in operational malfunctions. It is recommended that upper layers utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on.
状況によっては、リンク表示の不適切な使用により、運用上の誤動作が生じる可能性があります。上層層がタイムリーな回復ステップを利用して、作用後に無効であると判断されたリンク表示からの潜在的な損傷を制限することをお勧めします。
In Detecting Network Attachment in IPv4 (DNAv4) [RFC4436], reachability tests are carried out coincident with a request for configuration via DHCP. Therefore, if the bidirectional reachability test times out, the host can still obtain an IP configuration via DHCP, and if that fails, the host can still continue to use an existing valid address if it has one.
IPv4（DNAV4）[RFC4436]のネットワークアタッチメントの検出では、DHCPを介した構成要求と到達可能性テストが一致します。したがって、双方向Reachabilityテストがタイムアウトする場合でも、ホストはDHCPを介してIP構成を取得できます。それが失敗した場合、ホストは既存の有効なアドレスを持っている場合は引き続き既存の有効なアドレスを使用できます。
Where a proposal involves recovery at the transport layer, the recovered transport parameters (such as the Maximum Segment Size (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth (bw), congestion window (cwnd), etc.) should be demonstrated to remain valid. Congestion window validation is discussed in "TCP Congestion Window Validation" [RFC2861].
提案には、輸送層での回復が含まれる場合、回復した輸送パラメーター（最大セグメントサイズ（MSS）、往復時間（RTT）、再送信タイムアウト（RTO）、帯域幅（BW）、うっ血窓（CWND）など。）有効なままであることを実証する必要があります。混雑ウィンドウの検証は、「TCP混雑ウィンドウの検証」[RFC2861]で説明されています。
Where timely recovery is not supported, unexpected consequences may result. As described in [RFC3927], early IPv4 Link-Local implementations would wait five minutes before attempting to obtain a routable address after assigning an IPv4 Link-Local address. In one implementation, it was observed that where mobile hosts changed their point of attachment more frequently than every five minutes, they would never obtain a routable address. The problem was caused by an invalid link indication (signaling of "Link Up" prior to completion of link layer authentication), resulting in an initial failure to obtain a routable address using DHCP. As a result, [RFC3927] recommends against modification of the maximum retransmission timeout (64 seconds) provided in [RFC2131].
タイムリーな回復がサポートされていない場合、予期しない結果が生じる可能性があります。[RFC3927]で説明されているように、初期のIPv4 Link-Localの実装は、IPv4リンクローカルアドレスを割り当てた後、ルーティング可能なアドレスを取得しようとする前に5分待ちます。1つの実装では、モバイルホストが5分ごとに添付ファイルのポイントを頻繁に変更した場合、ルーティング可能なアドレスを取得しないことが観察されました。この問題は、無効なリンク表示（リンクレイヤー認証が完了する前に「リンクアップ」のシグナル伝達）が原因で、DHCPを使用したルーティング可能なアドレスを取得できないことが発生しました。その結果、[RFC3927]は、[RFC2131]で提供される最大再送信タイムアウト（64秒）の変更に対して推奨されます。
Damping and hysteresis can be utilized to limit damage from unstable link indications. This may include damping unstable indications or placing constraints on the frequency of link indication-induced actions within a time period.
減衰とヒステリシスを利用して、不安定なリンクの表示からの損傷を制限できます。これには、不安定な適応症を減衰させるか、期間内にリンク表示によるアクションの頻度に制約を配置することが含まれます。
While [Aguayo] found that frame loss was relatively stable for stationary stations, obstacles to radio propagation and multi-path interference can result in rapid changes in signal strength for a mobile station. As a result, it is possible for mobile stations to encounter rapid changes in link characteristics, including changes in transmission rate, throughput, frame loss, and even "Link Up"/"Link Down" indications.
[Aguayo]は、フレームの損失が固定ステーションでは比較的安定していることを発見しましたが、無線伝播と多パス干渉の障害は、モバイルステーションの信号強度に急速な変化をもたらす可能性があります。その結果、モバイルステーションは、伝送速度、スループット、フレームの損失、さらには「リンクアップ」/「リンクダウン」の表示など、リンク特性の急速な変化に遭遇する可能性があります。
Where link-aware routing metrics are implemented, this can result in rapid metric changes, potentially resulting in frequent changes in the outgoing interface for Weak End System implementations. As a result, it may be necessary to introduce route flap dampening.
リンク認識ルーティングメトリックが実装されている場合、これにより急速なメトリックの変化が発生する可能性があり、潜在的に弱いエンドシステムの実装のために発信インターフェイスが頻繁に変化することになります。その結果、ルートフラップの減衰を導入する必要がある場合があります。
However, the benefits of damping need to be weighed against the additional latency that can be introduced. For example, in order to filter out spurious "Link Down" indications, these indications may be delayed until it can be determined that a "Link Up" indication will not follow shortly thereafter. However, in situations where multiple Beacons are missed such a delay may not be needed, since there is no evidence of a suitable point of attachment in the vicinity.
ただし、減衰の利点は、導入できる追加のレイテンシと比較検討する必要があります。たとえば、偽の「リンクダウン」の表示を除外するために、これらの適応症は、その後すぐに「リンクアップ」指示が続くことがないと判断できるまで遅延する場合があります。ただし、近くに適切な愛着のポイントの証拠がないため、複数のビーコンが欠落している状況では、そのような遅延は必要ない場合があります。
In some cases, it is desirable to ignore link indications entirely. Since it is possible for a host to transition from an ad-hoc network to a network with centralized address management, a host receiving a "Link Up" indication cannot necessarily conclude that it is appropriate to configure an IPv4 Link-Local address prior to determining whether a DHCP server is available [RFC3927] or an operable configuration is valid [RFC4436].
場合によっては、リンクの表示を完全に無視することが望ましいです。ホストがアドホックネットワークから集中アドレス管理を伴うネットワークに移行できる可能性があるため、「リンクアップ」表示を受け取るホストは、決定する前にIPv4リンクローカルアドレスを構成することが適切であると必ずしも結論付けることはできません。DHCPサーバーが利用可能であるかどうか[RFC3927]または操作可能な構成が有効か[RFC4436]。
As noted in Section 1.4, the transport layer does not utilize "Link Up" and "Link Down" indications for the purposes of connection management.
セクション1.4で述べたように、輸送層は、接続管理の目的で「リンクアップ」と「リンクダウン」の表示を使用しません。
Link indication proposals must demonstrate that effective congestion control is maintained [RFC2914]. One or more of the following techniques may be utilized:
リンクの表示提案は、効果的な混雑制御が維持されていることを実証する必要があります[RFC2914]。次の手法の1つ以上を利用することができます。
Rate limiting. Packets generated based on receipt of link indications can be rate limited (e.g., a limit of one packet per end-to-end path RTO).
レート制限。リンク表示の受領に基づいて生成されたパケットは、レート制限されます（たとえば、エンドツーエンドパスRTOごとに1つのパケットの制限）。
Utilization of upper-layer indications. Applications should depend on upper-layer indications such as IP address configuration/change notification, rather than utilizing link indications such as "Link Up".
上層層の適応症の利用。アプリケーションは、「リンクアップ」などのリンク表示を使用するのではなく、IPアドレスの構成/変更通知などの上層層の表示に依存する必要があります。
Keepalives. In order to improve robustness against spurious link indications, an application keepalive or transport layer indication (such as connection teardown) can be used instead of consuming "Link Down" indications.
キープライブ。スプリアスリンクの表示に対する堅牢性を向上させるために、「リンクダウン」の表示を消費する代わりに、アプリケーションのキープライブまたは輸送層の表示（接続の分解など）を使用できます。
Conservation of resources. Proposals must demonstrate that they are not vulnerable to congestive collapse.
資源の保全。提案は、彼らがうっ血性崩壊に対して脆弱ではないことを実証する必要があります。
As noted in "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust], decreasing transmission rate in response to frame loss increases contention, potentially leading to congestive collapse. To avoid this, the link layer needs to distinguish frame loss due to congestion from loss due to channel conditions. Only frame loss due to deterioration in channel conditions can be used as a basis for decreasing transmission rate.
「802.11ワイヤレスネットワークの堅牢なレート適応」[堅牢]、フレーム損失の増加競合に応じて伝送速度の低下、潜在的にうっ血性崩壊につながる可能性がある。これを回避するために、リンク層は、輻輳のためにチャネル条件による損失からフレームの損失を区別する必要があります。チャネル条件の劣化によるフレーム損失のみを、伝送速度を下げるための基礎として使用できます。
Consider a proposal where a "Link Up" indication is used by a host to trigger retransmission of the last previously sent packet, in order to enable ACK reception prior to expiration of the host's retransmission timer. On a rapidly moving mobile node where "Link Up" indications follow in rapid succession, this could result in a burst of retransmitted packets, violating the principle of "conservation of packets".
ホストの再送信タイマーの満了前にACK受信を有効にするために、「リンクアップ」表示が最後に以前に送信されたパケットの再送信をトリガーするために「リンクアップ」表示が使用される提案を考えてみましょう。「リンクアップ」の適応症が迅速に連続して続く急速に移動するモバイルノードでは、これにより再送信されたパケットが破裂し、「パケットの保存」の原則に違反する可能性があります。
At the application layer, link indications have been utilized by applications such as Presence [RFC2778] in order to optimize registration and user interface update operations. For example, implementations may attempt presence registration on receipt of a "Link Up" indication, and presence de-registration by a surrogate receiving a "Link Down" indication. Presence implementations using "Link Up"/"Link Down" indications this way violate the principle of "conservation of packets" since link indications can be generated on a time scale less than the end-to-end path RTO. The problem is magnified since for each presence update, notifications can be delivered to many watchers. In addition, use of a "Link Up" indication in this manner is unwise since the interface may not yet even have an operable Internet layer configuration. Instead, an "IP address configured" indication may be utilized.
アプリケーションレイヤーでは、登録およびユーザーインターフェイスの更新操作を最適化するために、存在感[RFC2778]などのアプリケーションによってリンク表示が利用されています。たとえば、実装では、「リンクアップ」の表示を受け取った登録を試み、「リンクダウン」表示を受け取る代理人による存在下登録を試みる場合があります。「リンクアップ」/「リンクダウン」を使用した存在の実装は、この方法で「パケットの保存」の原則に違反します。これは、リンクの表示をエンドツーエンドのパスRTOよりも低い時間スケールで生成できるためです。問題は拡大されます。各プレゼンスの更新で、通知は多くのウォッチャーに配信できるためです。さらに、インターフェイスにはまだ操作可能なインターネットレイヤー構成さえ含まれていないため、この方法での「リンクアップ」表示の使用は賢明ではありません。代わりに、「設定されたIPアドレス」表示を使用する場合があります。
Proposals must demonstrate the effectiveness of proposed optimizations. Since optimizations typically increase complexity, substantial performance improvement is required in order to make a compelling case.
提案は、提案された最適化の有効性を実証する必要があります。通常、最適化は複雑さを高めるため、説得力のあるケースを作成するには、大幅なパフォーマンス改善が必要です。
In the face of unreliable link indications, effectiveness may depend on the penalty for false positives and false negatives. In the case of DNAv4 [RFC4436], the benefits of successful optimization are modest, but the penalty for being unable to confirm an operable configuration is a lengthy timeout. As a result, the recommended strategy is to test multiple potential configurations in parallel in addition to attempting configuration via DHCP. This virtually guarantees that DNAv4 will always result in performance equal to or better than use of DHCP alone.
信頼できないリンクの適応に直面して、有効性は、偽陽性と偽陰性のペナルティに依存する可能性があります。DNAV4 [RFC4436]の場合、最適化の成功の利点は控えめですが、操作可能な構成を確認できない場合のペナルティは長いタイムアウトです。その結果、推奨される戦略は、DHCPを介した構成を試みることに加えて、複数の潜在的な構成を並行してテストすることです。これにより、DNAV4が常にDHCPのみの使用よりもパフォーマンスが等しい以上のパフォーマンスをもたらすことが事実上保証されます。
While link indications can be utilized where available, they should not be required by upper layers, in order to maintain link layer independence. For example, if information on supported prefixes is provided at the link layer, hosts not understanding those hints must still be able to obtain an IP address.
リンク層の独立性を維持するために、リンクの適応症を利用可能な場合は利用可能な場合は利用できますが、上層層では必要ありません。たとえば、サポートされているプレフィックスに関する情報がリンクレイヤーで提供されている場合、これらのヒントがまだIPアドレスを取得できる必要があることを理解していないホストがあります。
Where link indications are proposed to optimize Internet layer configuration, proposals must demonstrate that they do not compromise robustness by interfering with address assignment or routing protocol behavior, making address collisions more likely, or compromising Duplicate Address Detection (DAD) [RFC4429].
インターネットレイヤーの構成を最適化するためにリンク適応が提案されている場合、提案は、アドレスの割り当てまたはルーティングプロトコルの動作を妨害したり、住所の衝突をより可能にしたり、アドレスの重複検出（DAD）を侵害することにより、堅牢性を妥協しないことを実証する必要があります[RFC4429]。
To avoid compromising interoperability in the pursuit of performance optimization, proposals must demonstrate that interoperability remains possible (potentially with degraded performance) even if one or more participants do not implement the proposal.
パフォーマンスの最適化の追求における相互運用性の侵害を回避するために、提案は、1人以上の参加者が提案を実施していなくても、相互運用性が可能（潜在的に劣化したパフォーマンスで）依然として可能であることを実証する必要があります。
Link indication proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack.
リンク表示提案は、スタックの複数のレイヤーによってリンク表示が直接利用される場合に発生する可能性のある人種条件を回避する必要があります。
Link indications are useful for optimization of Internet Protocol layer addressing and configuration as well as routing. Although "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim] describes situations in which link indications are first processed by the Internet Protocol layer (e.g., MIPv6) before being utilized by the transport layer, for the purposes of parameter estimation, it may be desirable for the transport layer to utilize link indications directly.
リンク表示は、インターネットプロトコルレイヤーのアドレス指定と構成、およびルーティングの最適化に役立ちます。「モバイルIPv6よりもTCPパフォーマンスを改善するためのBUトリガー方法」[Kim]は、パラメーターの目的のために、輸送層によって使用される前に、リンク適応がインターネットプロトコル層（例えば、MIPV6）によって最初に処理される状況を説明しています。推定では、輸送層がリンク表示を直接利用することが望ましい場合があります。
In situations where the Weak End System model is implemented, a change of outgoing interface may occur at the same time the transport layer is modifying transport parameters based on other link indications. As a result, transport behavior may differ depending on the order in which the link indications are processed.
Weak End System Modelが実装されている状況では、発信インターフェイスの変更が同時に発生する可能性があります。輸送層は、他のリンク適応に基づいて輸送パラメーターを変更しています。その結果、リンクの表示が処理される順序によって輸送の動作が異なる場合があります。
Where a multi-homed host experiences increasing frame loss or decreased rate on one of its interfaces, a routing metric taking these effects into account will increase, potentially causing a change in the outgoing interface for one or more transport connections. This may trigger Mobile IP signaling so as to cause a change in the incoming path as well. As a result, the transport parameters estimated for the original outgoing and incoming paths (congestion state, Maximum Segment Size (MSS) derived from the link maximum transmission unit (MTU) or Path MTU) may no longer be valid for the new outgoing and incoming paths.
マルチホームのホストがそのインターフェイスの1つでフレームの損失または速度の低下を増加させる場合、これらの効果を考慮したルーティングメトリックが増加し、1つ以上の輸送接続の発信インターフェイスの変化を引き起こす可能性があります。これにより、モバイルIPシグナル伝達がトリガーされ、着信パスの変更も引き起こす可能性があります。その結果、元の発信および着信パス（輻輳状態、最大セグメントサイズ（MSS））で推定された輸送パラメーターは、リンク最大伝送ユニット（MTU）またはパスMTUから派生した）は、新しい発信および着信にはもはや有効ではない場合があります。パス。
To avoid race conditions, the following measures are recommended:
人種の状態を避けるために、次の測定が推奨されます。
Path change re-estimation Layering Metric consistency
パス変更再推定の層状メトリックの一貫性
When the Internet layer detects a path change, such as a major change in transmission rate, a change in the outgoing or incoming interface of the host or the incoming interface of a peer, or perhaps even a substantial change in the IPv4 TTL/IPv6 Hop Limit of received packets, it may be worth considering whether to reset transport parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so as to allow them to be re-estimated. This ensures that estimates based on the former path do not persist after they have become invalid. Appendix A.3 summarizes the research on this topic.
インターネットレイヤーが送信速度の大幅な変化、ホストの発信または着信インターフェイスの変化、またはピアの着信インターフェイス、またはIPv4 TTL/IPv6ホップの大幅な変化など、パスの変化を検出すると受信したパケットの制限は、輸送パラメーター（RTT、RTO、CWND、BW、MSS）を初期値にリセットするかどうかを検討する価値があります。これにより、前の経路に基づく推定値が無効になった後も持続しないことが保証されます。付録A.3は、このトピックに関する研究をまとめたものです。
Another technique to avoid race conditions is to rely on layering to damp transient link indications and provide greater link layer independence.
人種の条件を回避するもう1つの手法は、一時的なリンク適応を減衰させるための階層化に依存し、リンク層の独立性を高めることです。
The Internet layer is responsible for routing as well as IP configuration and mobility, providing higher layers with an abstraction that is independent of link layer technologies.
インターネットレイヤーは、ルーティングとIP構成とモビリティを担当し、リンクレイヤーテクノロジーとは無関係の抽象化を備えたより高いレイヤーを提供します。
In general, it is advisable for applications to utilize indications from the Internet or transport layers rather than consuming link indications directly.
一般に、アプリケーションは、リンクの適応を直接消費するのではなく、インターネットまたは輸送層からの適応症を利用することをお勧めします。
Proposals should avoid inconsistencies between link and routing layer metrics. Without careful design, potential differences between link indications used in routing and those used in roaming and/or link enablement can result in instability, particularly in multi-homed hosts.
提案は、リンクとルーティングレイヤーメトリックの間の矛盾を避ける必要があります。慎重な設計がなければ、ルーティングで使用されるリンク表示とローミングおよび/またはリンクの有効化で使用されるリンク適応症の潜在的な違いは、特にマルチホームのホストで不安定になる可能性があります。
Once a link is in the "up" state, its effectiveness in transmission of data packets can be used to determine an appropriate routing metric. In situations where the transmission time represents a large portion of the total transit time, minimizing total transmission time is equivalent to maximizing effective throughput. "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] describes a proposed routing metric based on the Expected Transmission Count (ETX). The authors demonstrate that ETX, based on link layer frame loss rates (prior to retransmission), enables the selection of routes maximizing effective throughput. Where the transmission rate is constant, the expected transmission time is proportional to ETX, so that minimizing ETX also minimizes expected transmission time.
リンクが「アップ」状態になると、データパケットの送信におけるその有効性を使用して、適切なルーティングメトリックを決定できます。透過時間が総通過時間の大部分を表す状況では、総伝送時間を最小化することは、効果的なスループットの最大化と同等です。「マルチホップワイヤレスルーティングのハイスループットパスメトリック」[ETX]は、予想される伝送カウント（ETX）に基づいて提案されたルーティングメトリックを説明します。著者は、リンク層フレームの損失率（再送信前）に基づいて、ETXが効果的なスループットを最大化するルートの選択を可能にすることを実証しています。伝送速度が一定の場合、予想される伝送時間はETXに比例するため、ETXを最小限に抑えることで予想される伝送時間も最小限に抑えられます。
However, where the transmission rate may vary, ETX may not represent a good estimate of the estimated transmission time. In "Routing in multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the authors define a new metric called Expected Transmission Time (ETT). This is described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S is the size of the probe packet and B is the bandwidth of the link as measured by a packet pair [Morgan]. However, ETT assumes that the loss fraction of small probe frames sent at 1 Mbps data rate is indicative of the loss fraction of larger data frames at higher rates, which tends to underestimate the ETT at higher rates, where frame loss typically increases. In "A Radio Aware Routing Protocol for Wireless Mesh Networks" [ETX-Radio], the authors refine the ETT metric further by estimating the loss fraction as a function of transmission rate.
ただし、伝送速度が異なる場合がある場合、ETXは推定透過時間の適切な推定値を表していない場合があります。「マルチラジオのルーティング、マルチホップワイヤレスメッシュネットワーク」[ETX-rate]では、著者は、予想伝送時間（ETT）と呼ばれる新しいメトリックを定義しています。これは、ett = etx * s/bであるため、「帯域幅調整されたETX」として説明されています。ここで、Sはプローブパケットのサイズであり、Bはパケットペア[Morgan]で測定されるリンクの帯域幅です。ただし、ETTは、1 Mbpsのデータレートで送信された小さなプローブフレームの損失割合が、より高いレートでの大きなデータフレームの損失割合を示していると想定しており、これはフレーム損失が通常増加するより高いレートでETTを過小評価する傾向があります。「ワイヤレスメッシュネットワーク向けのラジオ認識ルーティングプロトコル」[ETX-Radio]では、著者は、透過率の関数として損失率を推定することにより、ETTメトリックをさらに改善します。
However, prior to sending data packets over the link, the appropriate routing metric may not easily be predicted. As noted in [Shortest], a link that can successfully transmit the short frames utilized for control, management, or routing may not necessarily be able to reliably transport larger data packets.
ただし、リンク上にデータパケットを送信する前に、適切なルーティングメトリックを簡単に予測できない場合があります。[最短]で述べたように、制御、管理、またはルーティングに使用される短いフレームを正常に送信できるリンクは、必ずしも大きなデータパケットを確実に輸送できるとは限りません。
Therefore, it may be necessary to utilize alternative metrics (such as signal strength or Access Point load) in order to assist in attachment/handoff decisions. However, unless the new interface is the preferred route for one or more destination prefixes, a Weak End System implementation will not use the new interface for outgoing traffic. Where "idle timeout" functionality is implemented, the unused interface will be brought down, only to be brought up again by the link enablement algorithm.
したがって、添付/ハンドオフの決定を支援するために、代替メトリック（信号強度やアクセスポイントの負荷など）を利用する必要がある場合があります。ただし、新しいインターフェイスが1つ以上の宛先プレフィックスの優先ルートでない限り、弱いエンドシステムの実装では、発信トラフィックに新しいインターフェイスを使用しません。「アイドルタイムアウト」機能が実装されている場合、未使用のインターフェイスが削除されますが、リンクイネーブルメントアルゴリズムによって再び発生するだけです。
Within the link layer, metrics such as signal strength and frame loss may be used to determine the transmission rate, as well as to determine when to select an alternative point of attachment. In order to enable stations to roam prior to encountering packet loss, studies such as "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic" [Vatn] have suggested using signal strength as a mechanism to more rapidly detect loss of connectivity, rather than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos].
リンクレイヤー内では、信号強度やフレーム損失などのメトリックを使用して、透過速度を決定したり、添付ファイルの代替点を選択するタイミングを決定する場合があります。パケットの損失に遭遇する前にステーションがローミングできるようにするために、「IEEE 802.11bのハンドオーバーパフォーマンスと音声トラフィックへの影響の実験的研究」などの研究は、[VATN]をより迅速に検出するメカニズムとして信号強度を使用することを示唆しています。「IEEE 802.11b Macレイヤーハンドオーバー時間を減らすための技術」[Velayos]で示唆されているように、フレーム損失ではなく接続性。
[Aguayo] notes that signal strength and distance are not good predictors of frame loss or throughput, due to the potential effects of multi-path interference. As a result, a link brought up due to good signal strength may subsequently exhibit significant frame loss and a low throughput. Similarly, an Access Point (AP) demonstrating low utilization may not necessarily be the best choice, since utilization may be low due to hardware or software problems. "OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-utilization-based routing metrics have a history of instability.
[Aguayo]は、マルチパス干渉の潜在的な影響により、信号強度と距離はフレーム損失またはスループットの良好な予測因子ではないことを指摘しています。その結果、良好な信号強度のために提起されたリンクは、その後、大きなフレーム損失とスループットが低いことを示す可能性があります。同様に、ハードウェアやソフトウェアの問題のために使用率が低い場合があるため、低使用率を示すアクセスポイント（AP）が必ずしも最良の選択ではない場合があります。「OSPF最適化されたマルチパス（OSPF-omp）」[Villamizar]は、リンク活性化ベースのルーティングメトリックには不安定性の履歴があると指摘しています。
In many situations, the exchanges required for a host to complete a handoff and reestablish connectivity are considerable, leading to proposals to combine exchanges occurring within multiple layers in order to reduce overhead. While overhead reduction is a laudable goal, proposals need to avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers.
多くの状況では、ホストがハンドオフを完了して接続を再確立するために必要な交換はかなりのものであり、オーバーヘッドを減らすために複数のレイヤー内で発生する交換を組み合わせる提案につながります。オーバーヘッドの削減は称賛に値する目標ですが、提案は相互運用性の侵害を避け、インターネットと輸送層にリンク層の依存関係を導入することを避ける必要があります。
Exchanges required for handoff and connectivity reestablishment may include link layer scanning, authentication, and association establishment; Internet layer configuration, routing, and mobility exchanges; transport layer retransmission and recovery; security association reestablishment; application protocol re-authentication and re-registration exchanges, etc.
ハンドオフおよび接続の再確立に必要な交換には、リンクレイヤースキャン、認証、および協会の確立が含まれる場合があります。インターネットレイヤーの構成、ルーティング、モビリティ交換。輸送層の再送信と回復。セキュリティ協会の再確立。アプリケーションプロトコルの再認証と再登録交換など。
Several proposals involve combining exchanges within the link layer. For example, in [EAPIKEv2], a link layer Extensible Authentication Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP address assignment, potentially bypassing Internet layer configuration. Within [PEAP], it is proposed that a link layer EAP exchange be used for the purpose of carrying Mobile IPv6 Binding Updates. [MIPEAP] proposes that EAP exchanges be used for configuration of Mobile IPv6. Where link, Internet, or transport layer mechanisms are combined, hosts need to maintain backward compatibility to permit operation on networks where compression schemes are not available.
いくつかの提案には、リンクレイヤー内の交換を組み合わせることが含まれます。たとえば、[EAPIKEV2]では、リンクレイヤー拡張可能な認証プロトコル（EAP）[RFC3748]交換を使用して、IPアドレスの割り当てを目的として使用でき、潜在的にインターネットレイヤー構成をバイパスします。[PEAP]内で、モバイルIPv6バインディングの更新を搭載する目的で、リンクレイヤーEAP交換を使用することが提案されています。[MIPEAP]は、モバイルIPv6の構成にEAP交換を使用することを提案しています。リンク、インターネット、または輸送層のメカニズムが組み合わされている場合、ホストは、圧縮スキームが利用できないネットワークでの操作を許可するために、後方互換性を維持する必要があります。
Layer compression schemes may also negatively impact robustness. For example, in order to optimize IP address assignment, it has been proposed that prefixes be advertised at the link layer, such as within the 802.11 Beacon and Probe Response frames. However, [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be assigned dynamically, so that prefix(es) advertised within the Beacon and/or Probe Response may not correspond to the prefix(es) configured by the Internet layer after the host completes link layer authentication. Were the host to handle IP configuration at the link layer rather than within the Internet layer, the host might be unable to communicate due to assignment of the wrong IP address.
層圧縮スキームは、堅牢性にも悪影響を与える可能性があります。たとえば、IPアドレスの割り当てを最適化するために、802.11ビーコンおよびプローブ応答フレーム内など、リンクレイヤーでプレフィックスを宣伝することが提案されています。ただし、[IEEE-802.1x]は、ビーコン内で宣伝されているプレフィックスおよび/またはプローブ応答がインターネットレイヤーによって構成されたプレフィックス（ES）に対応できないように、仮想LAN識別子（VLANID）を動的に割り当てることができます。ホストがリンクレイヤー認証を完了した後。インターネットレイヤー内ではなくリンクレイヤーでIP構成を処理するホストは、間違ったIPアドレスの割り当てにより、ホストが通信できない場合があります。
Proposals for the transport of link indications need to carefully consider the layering, security, and transport implications.
リンク指示の輸送に関する提案は、階層化、セキュリティ、および輸送の意味を慎重に検討する必要があります。
As noted earlier, the transport layer may take the state of the local routing table into account in improving the quality of transport parameter estimates. While absence of positive feedback that the path is sending data end-to-end must be heeded, where a route that had previously been absent is recovered, this may be used to trigger congestion control probing. While this enables transported link indications that affect the local routing table to improve the quality of transport parameter estimates, security and interoperability considerations relating to routing protocols still apply.
前述のように、輸送層は、輸送パラメーターの見積もりの質を改善する際に、ローカルルーティングテーブルの状態を考慮に入れることができます。パスがエンドツーエンドのデータを送信しているという肯定的なフィードバックの欠如に注意を払う必要がありますが、以前に存在していたルートが回復されている場合、これは混雑制御プロービングをトリガーするために使用できます。これにより、ローカルルーティングテーブルに影響を与える輸送されたリンクの表示が可能になり、輸送パラメーターの見積もりの品質を向上させることができます。ルーティングプロトコルに関連するセキュリティと相互運用性の考慮事項は依然として適用されます。
Proposals involving transport of link indications need to demonstrate the following:
リンク指示の輸送を含む提案は、以下を実証する必要があります。
(a) Superiority to implicit signals. In general, implicit signals are preferred to explicit transport of link indications since they do not require participation in the routing mesh, add no new packets in times of network distress, operate more reliably in the presence of middle boxes such as NA(P)Ts, are more likely to be backward compatible, and are less likely to result in security vulnerabilities. As a result, explicit signaling proposals must prove that implicit signals are inadequate.
(a) 暗黙的なシグナルに対する優位性。一般に、暗黙の信号は、ルーティングメッシュへの参加を必要とせず、ネットワークの苦痛の時に新しいパケットを追加しないため、リンクの表示の明示的な輸送よりも好まれます。、後方互換性がある可能性が高く、セキュリティの脆弱性をもたらす可能性が低くなります。その結果、明示的なシグナル伝達提案は、暗黙の信号が不十分であることを証明する必要があります。
(b) Mitigation of security vulnerabilities. Transported link indications should not introduce new security vulnerabilities. Link indications that result in modifications to the local routing table represent a routing protocol, so that the vulnerabilities associated with unsecured routing protocols apply, including spoofing by off-link attackers. While mechanisms such as "SEcure Neighbor Discovery (SEND)" [RFC3971] may enable authentication and integrity protection of router-originated messages, protecting against forgery of transported link indications, they are not yet widely deployed.
(b) セキュリティの脆弱性の緩和。輸送されたリンク表示は、新しいセキュリティの脆弱性を導入してはなりません。ローカルルーティングテーブルの変更をもたらすリンク表示は、ルーティングプロトコルを表し、オフリンク攻撃者によるスプーフィングなど、無担保ルーティングプロトコルに関連する脆弱性が適用されます。「Secure Neighbor Discovery（SEND）」[RFC3971]などのメカニズムは、ルーターによって発生したメッセージの認証と整合性の保護を可能にし、輸送されたリンクの表示の偽造から保護することができますが、それらはまだ広く展開されていません。
(c) Validation of transported indications. Even if a transported link indication can be integrity protected and authenticated, if the indication is sent by a host off the local link, it may not be clear that the sender is on the actual path in use, or which transport connection(s) the indication relates to. Proposals need to describe how the receiving host can validate the transported link indication.
(c) 輸送された適応症の検証。輸送されたリンクの表示が整合性保護および認証されている場合でも、表示がローカルリンクからホストによって送信された場合、送信者が実際の使用パスにあること、またはどの輸送接続があるかは明らかではないかもしれません。表示はに関連しています。提案は、受信ホストが輸送されたリンクの表示をどのように検証できるかを説明する必要があります。
(d) Mapping of Identifiers. When link indications are transported, it is generally for the purposes of providing information about Internet, transport, or application layer operations at a remote element. However, application layer sessions or transport connections may not be visible to the remote element due to factors such as load sharing between links, or use of IPsec, tunneling protocols, or nested headers. As a result, proposals need to demonstrate how the link indication can be mapped to the relevant higher-layer state. For example, on receipt of a link indication, the transport layer will need to identify the set of transport sessions (source address, destination address, source port, destination port, transport) that are affected. If a presence server is receiving remote indications of "Link Up"/"Link Down" status for a particular Media Access Control (MAC) address, the presence server will need to associate that MAC address with the identity of the user (pres:user@example.com) to whom that link status change is relevant.
(d) 識別子のマッピング。リンク表示が輸送される場合、一般に、リモート要素でインターネット、輸送、またはアプリケーション層操作に関する情報を提供する目的です。ただし、リンク間の負荷共有、IPSEC、トンネルプロトコル、ネストされたヘッダーの使用などの要因により、アプリケーションレイヤーセッションまたは輸送接続がリモート要素に表示されない場合があります。その結果、提案は、リンクの表示を関連する高層状態にどのようにマッピングできるかを示す必要があります。たとえば、リンクの表示を受け取ると、輸送層は、影響を受ける輸送セッション（ソースアドレス、宛先アドレス、ソースポート、宛先ポート、輸送）を識別する必要があります。プレゼンスサーバーが特定のメディアアクセスコントロール（MAC）アドレスの「リンクアップ」/「リンクダウン」ステータスのリモート表示を受信している場合、プレゼンスサーバーはそのMACアドレスをユーザーのIDに関連付ける必要があります（pres：user：user@example.com）そのリンクステータスの変更が関連する人。
Further work is needed in order to understand how link indications can be utilized by the Internet, transport, and application layers.
インターネット、輸送、アプリケーションレイヤーによってリンク表示をどのように利用できるかを理解するために、さらなる作業が必要です。
More work is needed to understand the connection between link indications and routing metrics. For example, the introduction of block ACKs (supported in [IEEE-802.11e]) complicates the relationship between effective throughput and frame loss, which may necessitate the development of revised routing metrics for ad-hoc networks. More work is also needed to reconcile handoff metrics (e.g., signal strength and link utilization) with routing metrics based on link indications (e.g., frame error rate and negotiated rate).
リンクの表示とルーティングメトリックの間の接続を理解するには、さらに作業が必要です。たとえば、ブロックアックの導入（[IEEE-802.11e]でサポート）は、効果的なスループットとフレームの損失の関係を複雑にします。これにより、アドホックネットワークの改訂されたルーティングメトリックの開発が必要になる場合があります。また、ハンドオフメトリック（たとえば、信号強度とリンクの使用率など）をリンクの表示（フレームエラー率やネゴシエートレートなど）に基づいてルーティングメトリックと調整するには、さらに作業が必要です。
A better understanding of the use of physical and link layer metrics in rate negotiation is required. For example, recent work [Robust][CARA] has suggested that frame loss due to contention (which would be exacerbated by rate reduction) can be distinguished from loss due to channel conditions (which may be improved via rate reduction).
レートネゴシエーションにおける物理層とリンク層のメトリックの使用をよりよく理解することが必要です。たとえば、最近の研究[Robust] [Cara]は、競合によるフレームの損失（レートの低下によって悪化する）は、チャネル条件（レートの減少によって改善される可能性がある）のために損失と区別できることを示唆しています。
At the transport layer, more work is needed to determine the appropriate reaction to Internet layer indications such as routing table and path changes. More work is also needed in utilization of link layer indications in transport parameter estimation, including rate changes, "Link Up"/"Link Down" indications, link layer retransmissions, and frame loss of various types (due to contention or channel conditions).
輸送層では、ルーティングテーブルやパスの変更などのインターネット層の適応に対する適切な反応を決定するために、より多くの作業が必要です。また、レートの変更、「リンク」/「リンクダウン」の表示、リンクレイヤーの再送信、さまざまなタイプのフレーム損失（競合またはチャネル条件のため）など、輸送パラメーターの推定でリンクレイヤー適応症の利用にもさらに作業が必要です。
More work is also needed to determine how link layers may utilize information from the transport layer. For example, it is undesirable for a link layer to retransmit so aggressively that the link layer round-trip time approaches that of the end-to-end transport connection. Instead, it may make sense to do downward rate adjustment so as to decrease frame loss and improve latency. Also, in some cases, the transport layer may not require heroic efforts to avoid frame loss; timely delivery may be preferred instead.
リンクレイヤーが輸送層からの情報をどのように利用するかを判断するには、さらに作業が必要です。たとえば、リンクレイヤーが非常に積極的に再送信することは望ましくないため、リンクレイヤーの往復タイムはエンドツーエンドの輸送接続のそれに近づきます。代わりに、フレームの損失を減らしてレイテンシを改善するために、下向きのレート調整を行うことは理にかなっているかもしれません。また、場合によっては、輸送層はフレームの損失を避けるために英雄的な努力を必要としない場合があります。代わりにタイムリーな配達が推奨される場合があります。
Proposals for the utilization of link indications may introduce new security vulnerabilities. These include:
リンク表示の利用に関する提案は、新しいセキュリティの脆弱性をもたらす可能性があります。これらには以下が含まれます：
Spoofing Indication validation Denial of service
スプーフィング表示検証サービスの拒否
Where link layer control frames are unprotected, they may be spoofed by an attacker. For example, PPP does not protect LCP frames such as LCP-Terminate, and [IEEE-802.11] does not protect management frames such as Associate/Reassociate, Disassociate, or Deauthenticate.
リンクレイヤー制御フレームが保護されていない場合、攻撃者によってスプーフィングされる場合があります。たとえば、PPPはLCPターミネートなどのLCPフレームを保護せず、[IEEE-802.11]は、関連/再配置、再配分、または非認定などの管理フレームを保護しません。
Spoofing of link layer control traffic may enable attackers to exploit weaknesses in link indication proposals. For example, proposals that do not implement congestion avoidance can enable attackers to mount denial-of-service attacks.
リンク層制御トラフィックのスプーフィングにより、攻撃者はリンク表示の提案の弱点を活用することができます。たとえば、混雑回避を実施しない提案により、攻撃者はサービス拒否攻撃を実施できるようになります。
However, even where the link layer incorporates security, attacks may still be possible if the security model is not consistent. For example, wireless LANs implementing [IEEE-802.11i] do not enable stations to send or receive IP packets on the link until completion of an authenticated key exchange protocol known as the "4-way handshake". As a result, a link implementing [IEEE-802.11i] cannot be considered usable at the Internet layer ("Link Up") until completion of the authenticated key exchange.
ただし、リンクレイヤーにセキュリティが組み込まれている場合でも、セキュリティモデルが一貫していない場合、攻撃が依然として可能になる場合があります。たとえば、[IEEE-802.11i]を実装するワイヤレスLANSは、「4ウェイハンドシェイク」として知られる認証されたキーエクスチェンジプロトコルが完了するまで、ステーションがリンクでIPパケットを送信または受信することはできません。その結果、[IEEE-802.11i]を実装するリンクは、認証されたキー交換が完了するまで、インターネットレイヤー（「リンクアップ」）で使用できるとは見なされません。
However, while [IEEE-802.11i] requires sending of authenticated frames in order to obtain a "Link Up" indication, it does not support management frame authentication. This weakness can be exploited by attackers to enable denial-of-service attacks on stations attached to distant Access Points (APs).
ただし、[IEEE-802.11i]では、「リンクアップ」表示を取得するために認証されたフレームを送信する必要がありますが、管理フレーム認証はサポートされません。この弱点は、攻撃者によって悪用され、遠くのアクセスポイント（AP）に接続されたステーションに対するサービス拒否攻撃を可能にすることができます。
In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends a Reassociation Response. At that point, the AP sends a spoofed frame with the station's source address to a multicast address, thereby causing switches within the Distribution System (DS) to learn the station's MAC address. While this enables forwarding of frames to the station at the new point of attachment, it also permits an attacker to disassociate a station located anywhere within the ESS, by sending an unauthenticated Reassociation Request frame.
[IEEE-802.11F]では、APが再配分応答を送信するときに「リンクアップ」が発生すると見なされます。その時点で、APはステーションのソースアドレスを備えたスプーフィングされたフレームをマルチキャストアドレスに送信し、それにより、配電システム（DS）内のスイッチがステーションのMACアドレスを学習します。これにより、添付ファイルの新しいポイントでステーションへのフレームの転送が可能になりますが、攻撃者は、認定されていない再配信要求フレームを送信することにより、ESS内のどこにでもあるステーションを解離することもできます。
"Fault Isolation and Recovery" [RFC816], Section 3, describes how hosts interact with routers for the purpose of fault recovery:
「障害分離と回復」[RFC816]、セクション3は、障害回復を目的としてホストがルーターと対話する方法について説明します。
Since the gateways always attempt to have a consistent and correct model of the internetwork topology, the host strategy for fault recovery is very simple. Whenever the host feels that something is wrong, it asks the gateway for advice, and, assuming the advice is forthcoming, it believes the advice completely. The advice will be wrong only during the transient period of negotiation, which immediately follows an outage, but will otherwise be reliably correct.
ゲートウェイは常にインターネットワークトポロジの一貫した正しいモデルを持つことを試みているため、障害回復のためのホスト戦略は非常に簡単です。ホストが何かが間違っていると感じるときはいつでも、ゲートウェイにアドバイスを求め、アドバイスが近づいていると仮定すると、アドバイスは完全に信じています。アドバイスは、過渡的な交渉期間中にのみ間違っています。これはすぐに停止の直後になりますが、そうでなければ確実に正しいでしょう。
In fact, it is never necessary for a host to explicitly ask a gateway for advice, because the gateway will provide it as appropriate. When a host sends a datagram to some distant net, the host should be prepared to receive back either of two advisory messages which the gateway may send. The ICMP "redirect" message indicates that the gateway to which the host sent the datagram is no longer the best gateway to reach the net in question. The gateway will have forwarded the datagram, but the host should revise its routing table to have a different immediate address for this net. The ICMP "destination unreachable" message indicates that as a result of an outage, it is currently impossible to reach the addressed net or host in any manner. On receipt of this message, a host can either abandon the connection immediately without any further retransmission, or resend slowly to see if the fault is corrected in reasonable time.
実際、ゲートウェイが必要に応じてそれを提供するので、ホストがゲートウェイにアドバイスを明示的に尋ねる必要はありません。ホストがデータグラムを遠いネットに送信する場合、ホストはゲートウェイが送信する可能性のある2つのアドバイザリーメッセージのいずれかを返す準備をする必要があります。ICMPの「リダイレクト」メッセージは、ホストがデータグラムを送信したゲートウェイが、問題のネットに到達するのに最適なゲートウェイではなくなったことを示しています。ゲートウェイはデータグラムを転送しますが、ホストはルーティングテーブルを修正して、このネットの即時アドレスを別の即時にする必要があります。ICMPの「宛先の到達不可能」メッセージは、停止の結果として、どの方法でアドレス指定されたネットまたはホストに到達することが不可能であることを示しています。このメッセージを受け取ったとき、ホストはさらに再送信なしですぐに接続を放棄するか、ゆっくりと再び繰り返して、合理的な時間に障害が修正されているかどうかを確認できます。
Given today's security environment, it is inadvisable for hosts to act on indications provided by routers without careful consideration. As noted in "ICMP attacks against TCP" [Gont], existing ICMP error messages may be exploited by attackers in order to abort connections in progress, prevent setup of new connections, or reduce throughput of ongoing connections. Similar attacks may also be launched against the Internet layer via forging of ICMP redirects.
今日のセキュリティ環境を考えると、ホストは慎重に検討せずにルーターによって提供される適応症に基づいて行動することはできません。「TCPに対するICMP攻撃」[GONT]で述べたように、既存のICMPエラーメッセージは、進行中の接続を中止したり、新しい接続のセットアップを防ぎ、進行中の接続のスループットを減らすために攻撃者によって悪用される場合があります。ICMPリダイレクトの鍛造により、インターネット層に対して同様の攻撃も開始される場合があります。
Proposals for transported link indications need to demonstrate that they will not add a new set of similar vulnerabilities. Since transported link indications are typically unauthenticated, hosts receiving them may not be able to determine whether they are authentic, or even plausible.
輸送されたリンクの表示の提案は、同様の脆弱性の新しいセットを追加しないことを実証する必要があります。輸送されたリンクの表示は通常、認識されていないため、それらを受け取るホストが本物であるか、もっともらしいかを判断できない場合があります。
Where link indication proposals may respond to unauthenticated link layer frames, they should utilize upper-layer security mechanisms, where possible. For example, even though a host might utilize an unauthenticated link layer control frame to conclude that a link has become operational, it can use SEND [RFC3971] or authenticated DHCP [RFC3118] in order to obtain secure Internet layer configuration.
リンクの表示提案が認識されていないリンクレイヤーフレームに応答する場合は、可能な場合は上層層セキュリティメカニズムを利用する必要があります。たとえば、ホストが無許可のリンクレイヤー制御フレームを利用して、リンクが動作するようになったと結論付ける場合がありますが、セキュアなインターネットレイヤー構成を取得するために、送信[RFC3971]または認証されたDHCP [RFC3118]を使用できます。
Link indication proposals need to be particularly careful to avoid enabling denial-of-service attacks that can be mounted at a distance. While wireless links are naturally vulnerable to interference, such attacks can only be perpetrated by an attacker capable of establishing radio contact with the target network. However, attacks that can be mounted from a distance, either by an attacker on another point of attachment within the same network or by an off-link attacker, expand the level of vulnerability.
リンクの表示提案は、遠くに取り付けることができるサービス拒否攻撃を可能にすることを避けるために特に注意する必要があります。ワイヤレスリンクは自然に干渉に対して脆弱ですが、そのような攻撃は、ターゲットネットワークとの無線接触を確立できる攻撃者によってのみ実行されます。ただし、同じネットワーク内の別のアタッチメントポイントへの攻撃者によって、またはリンクオフリンク攻撃者によって、遠くから取り付けることができる攻撃は、脆弱性のレベルを拡大します。
The transport of link indications can increase risk by enabling vulnerabilities exploitable only by attackers on the local link to be executed across the Internet. Similarly, by integrating link indications with upper layers, proposals may enable a spoofed link layer frame to consume more resources on the host than might otherwise be the case. As a result, while it is important for upper layers to validate link indications, they should not expend excessive resources in doing so.
リンク指示の輸送は、インターネット全体で実行されるローカルリンクの攻撃者によってのみ脆弱性を可能にすることにより、リスクを高めることができます。同様に、リンクの表示を上層層と統合することにより、提案により、スプーフィングされたリンクレイヤーフレームが、そうでなければホストにより多くのリソースを消費できるようになります。その結果、上層がリンクの表示を検証することが重要ですが、そうすることで過度のリソースを費やすべきではありません。
Congestion control is not only a transport issue, it is also a security issue. In order to not provide leverage to an attacker, a single forged link layer frame should not elicit a magnified response from one or more hosts, by generating either multiple responses or a single larger response. For example, proposals should not enable multiple hosts to respond to a frame with a multicast destination address.
混雑制御は輸送の問題であるだけでなく、セキュリティの問題でもあります。攻撃者にレバレッジを提供しないために、単一の偽造リンクレイヤーフレームは、複数の応答または単一のより大きな応答を生成することにより、1つ以上のホストから拡大された応答を引き出すべきではありません。たとえば、提案は、複数のホストがマルチキャストの宛先アドレスを持つフレームに応答できるようにするべきではありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July 1982.
[RFC816]クラーク、D。、「断層分離と回復」、RFC 816、1982年7月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058] Hedrick、C。、「ルーティング情報プロトコル」、RFC 1058、1988年6月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1989.
[RFC1131] Moy、J。、「OSPF仕様」、RFC 1131、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link Control Protocol", RFC 1307, March 1992.
[RFC1307] Young、J。およびA. Nicholson、「動的に切り替えられたリンク制御プロトコル」、RFC 1307、1992年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、D.、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, June 1996.
[RFC1981] McCann、J.、Deering、S。およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP混雑ウィンドウ検証」、RFC 2861、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 41, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、RFC 2914、BCP 41、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol" RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H。Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV.Paxson、「ストリーム制御伝送プロトコル」RFC 2960、2000年10月。
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] DROMS、R。およびB. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366] Fairhurst、G。およびL. Wood、「Link Automatic Repeat Request（ARQ）でデザイナーをリンクするアドバイス」、BCP 62、RFC 3366、2002年8月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「即座のメッセージのためのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[RFC3921] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「Link-Local IPv4アドレスの動的な構成」、RFC 3927、2005年5月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N。、「IPv6の楽観的な複製アドレス検出（DAD）」、RFC 4429、2006年4月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「IPv4（DNAV4）のネットワークアタッチメントの検出」、RFC 4436、2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[Alimian] Alimian, A., "Roaming Interval Measurements", 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 802.11 submission (work in progress), March 2004.
[Alimian] Alimian、A。、「ローミング間隔測定」、11-04-0378-00-Roaming-Intervals-Measurements.ppt、IEEE 802.11提出（進行中の作業）、2004年3月。
[Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G., and R. Morris, "Link-level Measurements from an 802.11b Mesh Network", SIGCOMM '04, September 2004, Portland, Oregon.
[Aguayo] Aguayo、D.、Bicket、J.、Biswas、S.、Judd、G。、およびR. Morris、「802.11bメッシュネットワークからのリンクレベル測定」、Sigcomm '04、2004年9月、ポートランド、オレゴン。
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N., and D.Pradhan, "Improving Performance of TCP over Wireless Networks", Proceedings of the 1997 International Conference on Distributed Computer Systems, Baltimore, May 1997.
[Bakshi] Bakshi、B.、Krishna、P.、Vadiya、N。、およびD.Pradhan、「ワイヤレスネットワーク上のTCPのパフォーマンスの向上」、1997年5月、ボルチモアの分散コンピューターシステムに関する1997年の国際会議の議事録。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2007.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、2007年3月、進行中の作業。
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver", Proceedings of the IEEE Symposium on Application-Specific Systems and Software Engineering and Technology, Richardson, TX, Mar 1999.
[Biaz] Biaz、S。およびN. Vaidya、「受信者での到達時間を使用したワイヤレス損失からの輻輳損失の識別」、1999年3月、テキサス州リチャードソン、アプリケーション固有のシステムおよびソフトウェアエンジニアリングおよびテクノロジーに関するIEEEシンポジウムの議事録。
[CARA] Kim, J., Kim, S., and S. Choi, "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs", Korean Institute of Communication Sciences (KICS) Journal, Feb. 2006
[Cara] Kim、J.、Kim、S。、およびS. Choi、「Cara：IEEE 802.11 WLANSの衝突認識料金適応」、韓国コミュニケーション科学研究所（KICS）ジャーナル、2006年2月
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S., and R. Prakash, "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc Wireless Networks", Proceedings of the 18th International Conference on Distributed Computing Systems (ICDCS), Amsterdam, May 1998.
[チャンドラン]チャンドラン、K。、ラグナサン、S。、ベンカテサン、S。、およびR.プラカシュ、「アドホックワイヤレスネットワークでのTCPパフォーマンスを改善するためのフィードバックベースのスキーム」、第18回国際分散コンピューティングに関する国際会議の議事録システム（ICDCS）、アムステルダム、1998年5月。
[DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6 (DNAv6)", Work in Progress, March 2007.
[DNAV6] Narayanan、S。、「IPv6（DNAV6）のネットワークアタッチメントの検出」、2007年3月、進行中の作業。
[E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-Up' Notification", Work in Progress, October 2003.
[E2ELINKUP] Dawkins、S。およびC. Williams、「エンドツーエンド、暗黙の「リンクアップ」通知」、2003年10月の作業。
[EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP IKEv2 Method", Work in Progress, March 2007.
[eapikev2] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、Ohba、Y.、およびF. Bersani、「EAP IKEV2 Method」、2007年3月の作業。
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of the Error Characteristics of an In-Building Wireless Network", SIGCOMM '96, August 1996, Stanford, CA.
[Eckhardt] Eckhardt、D。およびP. Steenkiste、「ビルディングワイヤレスネットワークのエラー特性の測定と分析」、Sigcomm '96、1996年8月、カリフォルニア州スタンフォード
[Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion Control for Mobility", Technical Report CR-2005- 213838, NASA Glenn Research Center, July 2005.
[Eddy] Eddy、W。and Y. Swami、「モビリティのためのエンドホストの混雑制御の適応」、テクニカルレポートCR-2005-213838、NASA Glenn Research Center、2005年7月。
[EfficientEthernet] Gunaratne, C. and K. Christensen, "Ethernet Adaptive Link Rate: System Design and Performance Evaluation", Proceedings of the IEEE Conference on Local Computer Networks, pp. 28-35, November 2006.
[EfficientEthernet] Gunaratne、C。and K. Christensen、「イーサネット適応リンクレート：システム設計とパフォーマンス評価」、地元のコンピューターネットワークに関するIEEE会議の議事録、28-35ページ、2006年11月。
[Eggert] Eggert, L., Schuetz, S., and S. Schmid, "TCP Extensions for Immediate Retransmissions", Work in Progress, June 2005.
[Eggert] Eggert、L.、Schuetz、S。、およびS. Schmid、「即時再送信のためのTCP拡張」、2005年6月、進行中の作業。
[Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive Transport-Layer Interfaces", MobiArch '06, San Francisco, CA.
[Eggert2] Eggert、L。and W. Eddy、「より表現力のある輸送層インターフェイスに向けて」、Mobiarch '06、San Francisco、CA。
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", Proceedings of the 9th ACM International Conference on Mobile Computing and Networking (MobiCom '03), San Diego, California, September 2003.
[ETX]ダグラスS. J.デクート、ダニエルアグヨ、ジョンビケット、ロバートモリス、「マルチホップワイヤレスルーティングのハイスループットパスメトリック」、第9回ACM国際モバイルコンピューティングとネットワークのネットワーク会議の議事録（Mobicom '03）、カリフォルニア州サンディエゴ、2003年9月。
[ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi-radio, multi-hop wireless mesh networks", Proceedings of ACM MobiCom Conference, September 2003.
[ETX-RATE] Padhye、J.、Draves、R。、およびB. Zill、「マルチラジオでのルーティング、マルチホップワイヤレスメッシュネットワーク」、2003年9月、ACM Mobicom Conferenceの議事録。
[ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M., and M. Srivastava, "A Radio Aware Routing Protocol for Wireless Mesh Networks", UCLA Computer Science Department, Los Angeles, CA.
[ETX-Radio] Kulkarni、G.、Nandan、A.、Gerla、M。、およびM. Srivastava、「ワイヤレスメッシュネットワーク向けのラジオ認識ルーティングプロトコル」、UCLAコンピューターサイエンス部門、ロサンゼルス、カリフォルニア州
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer Triggers", submission to IEEE 802.21 (work in progress), March 2004, available at: <http://www.ieee802.org/handoff/march04_meeting_docs/ Generalized_triggers-02.pdf>.
[Gentrig] Gupta、V。およびD. Johnston、「リンクレイヤートリガーの一般化されたモデル」、IEEE 802.21への提出、2004年3月、<http://www.ieee802.org/handoff/ mare04_meeting_docs/ generalized_triggers-02.pdf>。
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over Wireless Links", Proceedings of TENCON'98, pages 332-335. IEEE, December 1998.
[Goel] Goel、S。およびD. Sanghi、「ワイヤレスリンク上のTCPパフォーマンスの改善」、Tencon'98の議事録、332-335ページ。IEEE、1998年12月。
[Gont] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[Gont] Gont、F。、「TCPに対するICMP攻撃」、2006年10月、進行中の作業。
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers on Performance of TCP-Friendly Rate Control", to appear in ACM MCCR, 2004.
[Gurtov] Gurtov、A。and J. Korhonen、「TCPに優しいレートコントロールの性能に対する垂直手向きの効果」、ACM MCCR、2004年に登場。
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for Transport Protocols", Computer Communications Review (CCR) 34, 2 (2003).
[Gurtovfloyd] Gurtov、A。およびS. Floyd、「輸送プロトコルのワイヤレスリンクのモデリング」、Computer Communications Review（CCR）34、2（2003）。
[Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K., and H. Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, October 1, 2004, Philadelphia, Pennsylvania, USA.
[Haratcherev] Haratcherev、I.、Lagendijk、R.、Langendoen、K。、およびH. Sips、「IEEE 802.11のハイブリッドレートコントロール」、Mobiwac '04、2004年10月1日、フィラデルフィア、ペンシルバニア、米国。
[Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation for IEEE 802.11", Ph.D. Thesis, Technical University of Delft, Netherlands, ISBN-10:90-9020513-6, ISBN-13:978-90-9020513-7, March 2006.
[Haratcherev2] Haratcherev、I。、「IEEE 802.11のアプリケーション指向のリンク適応」、Ph.D。論文、オランダ、デルフト工科大学、ISBN-10：90-9020513-6、ISBN-13：978-90-9020513-7、2006年3月。
[HMP] Lee, S., Cho, J., and A. Campbell, "Hotspot Mitigation Protocol (HMP)", Work in Progress, October 2003.
[HMP] Lee、S.、Cho、J。、およびA. Campbell、「Hotspot Mitigation Protocol（HMP）」、2003年10月、進行中の作業。
[Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance over Mobile Ad Hoc Networks", Proceedings of the Fifth International Conference on Mobile Computing and Networking, pages 219-230. ACM/IEEE, Seattle, August 1999.
[Holland] Holland、G。and N. Vaidya、「モバイルアドホックネットワーク上のTCPパフォーマンスの分析」、5回目のモバイルコンピューティングとネットワーキングに関する国際会議の議事録、219〜230ページ。ACM/IEEE、シアトル、1999年8月。
[Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S., and C. Diot, "Analysis of link failures in an IP backbone", Proc. of ACM Sigcomm Internet Measurement Workshop, November, 2002.
[Iannaccone] Iannaccone、G.、Chuah、C.、Mortier、R.、Bhattacharyya、S。、およびC. Diot、「IPバックボーンにおけるリンク障害の分析」、Proc。ACM Sigcomm Internet Measurement Workshop、2002年11月。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
[IEEE-802.1X]電気および電子機器エンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE Standard 802.1x、2004年12月。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE-802.11]電気およびエレクトロニクスエンジニアの研究所、「ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様」、IEEE Standard 802.11、2003。
[IEEE-802.11e] Institute of Electrical and Electronics Engineers, "Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements", IEEE 802.11e, November 2005.
[IEEE -802.11E]電気および電子機器エンジニア研究所、「システム間の電気通信および情報交換の標準 - LAN/MAN固有の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様 - 修正8修正8：Medium Access Control（MAC）サービスの品質強化」、IEEE 802.11E、2005年11月。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now deprecated).
[IEEE-802.11F]電気および電子機器エンジニアの研究所、「IEEE 802.11操作をサポートする流通システム間のアクセス間ポイントプロトコルを介したマルチベンダーアクセスポイントの相互運用性のIEEE試行用の推奨プラクティス」、IEEE 802.11f、2003年6月（今は非推奨）。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i, July 2004.
[IEEE -802.11i]電気電子エンジニア研究所、「電気通信の標準の補足システム間の情報交換 - LAN/MAN固有の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様：強化されたセキュリティの仕様」、IEEE 802.11i、2004年7月。
[IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft Amendment to Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 7: Radio Resource Management", IEEE 802.11k/D7.0, January 2007.
[IEEE -802.11K]電気および電子機器エンジニア研究所、「電気通信の修正とシステム間の情報交換の草案 - LAN/MAN固有の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様 - 修正7：無線リソース管理」、IEEE 802.11k/d7.0、2007年1月。
[IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 21: Media Independent Handover", IEEE 802.21D0, June 2005.
[IEEE -802.21]電気および電子機器エンジニアの研究所、「電気通信およびシステム間の情報交換のための標準 - LAN/MAN固有の要件 - パート21：メディア独立ハンドオーバー」、IEEE 802.21D0、2005年6月。
[Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-Performance Wireless LAN for the Unlicensed Band", Bell Labs Technical Journal, Summer 1997.
[Kamerman] Kamerman、A。and L. Monteban、「Wavelan II：免許付きバンドのための高性能ワイヤレスLAN」、Bell Labs Technical Journal、1997年夏。
[Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger method for improving TCP performance over Mobile IPv6", Work in Progress, August 2004.
[キム]キム、K。、パーク、Y。、スー、K。、およびY.パーク、「モバイルIPv6よりもTCPパフォーマンスを改善するためのBUトリガー方法」、2004年8月、進行中の作業。
[Kotz] Kotz, D., Newport, C., and C. Elliot, "The mistaken axioms of wireless-network research", Dartmouth College Computer Science Technical Report TR2003-467, July 2003.
[Kotz] Kotz、D.、Newport、C。、およびC. Elliot、「ワイヤレスネットワーク研究の誤った公理」、ダートマスカレッジコンピューターサイエンステクニカルレポートTR2003-467、2003年7月。
[Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, 46 (3), October 2004.
[クリシュナン]クリシュナン、R。、スターベンツ、J。、エディー、W。、パートリッジ、C。、およびM.オールマン、「エラーが発生しやすいワイヤレスおよび衛星ネットワークの明示的な輸送エラー通知（ETEN）」、コンピューターネットワーク、46（3）、2004年10月。
[Lacage] Lacage, M., Manshaei, M., and T. Turletti, "IEEE 802.11 Rate Adaptation: A Practical Approach", MSWiM '04, October 4-6, 2004, Venezia, Italy.
[Lacage] Lacage、M.、Manshaei、M.、およびT. Turletti、「IEEE 802.11レート適応：実用的なアプローチ」、MSWIM '04、2004年10月4〜6日、ベネジア、イタリア。
[Lee] Park, S., Lee, M., and J. Korhonen, "Link Characteristics Information for Mobile IP", Work in Progress, January 2007.
[Lee] Park、S.、Lee、M。、およびJ. Korhonen、「モバイルIPのリンク特性情報」、2007年1月の作業。
[Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1999.
[Ludwig] Ludwig、R。and B. Rathonyi、「GSM上のTCP/IPのリンクレイヤーエンハンスメント」、IEEE Infocom '99の議事録、1999年3月。
[MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J., and M. Laurent-Maknavicius, "MIPv6 Authorization and Configuration based on EAP", Work in Progress, October 2006.
[Mipeap] Giaretta、C.、Guardini、I.、Demaria、E.、Bournelle、J。、およびM. Laurent-Maknavicius、「EAPに基づくMIPV6認可と構成」、2006年10月の作業。
[Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University of Maryland Department of Computer Science, September 2002.
[Mishra] Mitra、A.、Shin、M。、およびW. Arbaugh、「IEEE 802.11 Macレイヤーハンドオフプロセスの経験的分析」、CS-TR-4395、メリーランド大学コンピューターサイエンス科、2002年9月。
[Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - Buffer Requirements and Overload Performance", Technical Memorandum, AT&T Bell Laboratories, October 1994.
[Morgan] Morgan、S。and S. Keshav、「パケットペアレート制御 - バッファー要件と過負荷性能」、Technical Memorandum、AT＆T Bell Laboratories、1994年10月。
[Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with 802.11", Work in Progress, March 2004.
[Mun] Mun、Y。、およびJ. Park、「802.11のモバイル-IPV4のレイヤー2ハンドオフ」、2004年3月、進行中の作業。
[ONOE] Onoe Rate Control, <http://madwifi.org/browser/trunk/ath_rate/onoe>.
[ONOE] ONOEレートコントロール、<http://madwifi.org/browser/trunk/ath_rate/onoe>。
[Park] Park, S., Njedjou, E., and N. Montavont, "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", Work in Progress, July 2004.
[Park] Park、S.、Njedjou、E。、およびN. Montavont、「L2は最適化されたモバイルIPv6垂直ハンドオーバー：802.11/gprsの例をトリガーします」、2004年7月、進行中の作業。
[Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for IEEE802.11 WLAN via received signal strength measurement", IEEE International Conference on Communications, 2003 (ICC '03), volume 2, pages 1108- 1113, Anchorage, Alaska, USA, May 2003.
[Pavon] Pavon、J。およびS. Choi、「受信信号強度測定によるIEEE802.11 WLANのリンク適応戦略」、IEEE国際通信会議、2003年（ICC '03）、第2巻、1108-1113ページ、アンカレッジ、2003年5月、米国アラスカ。
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP] Palekar、A.、Simon、D.、Salowey、J.、Zhou、H.、Zorn、G。、およびS. Josefsson、「Protected EAP Protocol（PEAP）バージョン2」、2004年10月の作業。
[PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network protocols", Proceedings of the IEEE, 75(1), January 1987.
[PRNET] Jubin、J。およびJ. Tornow、「The DARPA Packet Radio Network Protocols」、IEEE Proceedings、75（1）、1987年1月。
[Qiao] Qiao D., Choi, S., Jain, A., and Kang G. Shin, "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h", in Proc. ACM MobiCom'03, San Diego, CA, September 2003.
[Qiao] Qiao D.、Choi、S.、Jain、A。、およびKang G. Shin、「Miser：IEEE 802.11 A/Hの最適な低エネルギー伝達戦略」、Proc。ACM Mobicom'03、カリフォルニア州サンディエゴ、2003年9月。
[RBAR] Holland, G., Vaidya, N., and P. Bahl, "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks", Proceedings ACM MOBICOM, July 2001.
[RBAR] Holland、G.、Vaidya、N。、およびP. Bahl、「マルチホップワイヤレスネットワーク用のレート適応マックプロトコル」、Proceedings ACM Mobicom、2001年7月。
[Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks", Proceedings of the IEEE InfoCon 2005, March 2005.
[Ramani] Ramani、I。およびS. Savage、「Syncscan：802.11インフラストラクチャネットワークの実用的な高速ハンドオフ」、IEEE Infocon 2005、2005年3月の議事録。
[Robust] Wong, S., Yang, H ., Lu, S., and V. Bharghavan, "Robust Rate Adaptation for 802.11 Wireless Networks", ACM MobiCom'06, Los Angeles, CA, September 2006.
[Robust] Wong、S.、Yang、H.、Lu、S.、およびV. Bharghavan、「802.11ワイヤレスネットワークの堅牢な速度適応」、ACM Mobicom'06、ロサンゼルス、カリフォルニア州、2006年9月。
[SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks", MIT Master's Thesis, 2005.
[Samplerate] Bicket、J。、「ワイヤレスネットワークでのビットレート選択」、MIT修士論文、2005。
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for Disconnecting Networks", ACM SIGCOMM Computer Communication Review, 33(5), October 2003.
[Scott] Scott、J.、Mapp、G。、「ネットワークを切断するためのリンクレイヤーベースのTCP最適化」、ACM Sigcomm Computer Communication Review、33（5）、2003年10月。
[Schuetz] Schutz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol Enhancements for Intermittently Connected Hosts", ACM SIGCOMM Computer Communications Review, Volume 35, Number 2, July 2005.
[Schuetz] Schutz、S.、Eggert、L.、Schmid、S.、およびM. Brunner、「断続的に接続されたホストのプロトコル強化」、ACM Sigcomm Computer Communications Review、Volume 35、Number 2、2005年7月。
[Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers and Robert Morris, "Performance of Multihop Wireless Networks: Shortest Path is Not Enough", Proceedings of the First Workshop on Hot Topics in Networking (HotNets-I), Princeton, New Jersey, October 2002.
[最短]ダグラスS. J.デクート、ダニエルアグヨ、ベンジャミンA.チェンバーズ、ロバートモリス、「マルチホップワイヤレスネットワークのパフォーマンス：最短パスでは十分ではありません」、ネットワークのホットトピックに関する最初のワークショップの議事、ニュージャージー、2002年10月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, August 2003.
[Trigtran] Dawkins、S.、Williams、C。、およびA. Yegin、「Trigtranのフレームワークと要件」、2003年8月、進行中の作業。
[Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic", TRITA-IMIT-TSLAB R 03:01, KTH Royal Institute of Technology, Stockholm, Sweden, July 2003.
[Vatn] Vatn、J。、「IEEE 802.11bのハンドオーバーパフォーマンスと音声トラフィックへの影響の実験的研究」、Trita-Imit-Tslab R 03:01、KTH Royal Institute of Technology、ストックホルム、スウェーデン、2003年7月。
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH Royal Institute of Technology, Stockholm, Sweden, April 2003.
[Velayos] Velayos、H。and G. Karlsson、「IEEE 802.11b MACレイヤーハンドオーバー時間を減らす技術」、Trita-Imit-LCN R 03:02、Kth Royal Institute of Technology、Stockholm、Sweden、2003年4月。
[Vertical] Zhang, Q., Guo, C., Guo, Z., and W. Zhu, "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN", IEEE Communications Magazine, November 2003.
[Vertical] Zhang、Q.、Guo、C.、Guo、Z。、およびW. Zhu、「WWANとWLAN間の垂直ハンドオフの効率的なモビリティ管理」、IEEE Communications Magazine、2003年11月。
[Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", Work in Progress, February 1999.
[Villamizar] Villamizar、C。、「OSPF Optimized Multipath（OSPF-omp）」、Work in Progress、1999年2月。
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links", Ph.D. thesis, University of California at San Diego, 1999.
[Xylomenos] Xylomenos、G。、「マルチサービスリンクレイヤー：ワイヤレスリンク上のインターネットパフォーマンスを強化するためのアプローチ」、Ph.D。論文、カリフォルニア大学サンディエゴ校、1999年。
[Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in Progress, June 2002.
[Yegin] Yegin、A。、「Link-Layer Triggers Protocol」、2002年6月、進行中の作業。
The authors would like to acknowledge James Kempf, Phil Roberts, Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy, and Janne Peisa for contributions to this document.
著者は、ジェームズ・ケンプフ、フィル・ロバーツ、ゴーリー・フェアハースト、ジョン・ロクロウスキー、アーロン・フォーク、サリー・フロイド、ペッカ・サヴォラ、ペッカ・ニカンダー、デイブ・ターラー、ヨーゲシュ・スワミ、ウェスリー・エディ、ジャンヌ・ペイサがこの文書に貢献することを認めたいと思います。
This appendix summarizes the literature with respect to link indications on wireless local area networks.
この付録は、ワイヤレスローカルエリアネットワークのリンク表示に関する文献をまとめたものです。
The characteristics of wireless links have been found to vary considerably depending on the environment.
ワイヤレスリンクの特性は、環境によって大きく異なることがわかっています。
In "Performance of Multihop Wireless Networks: Shortest Path is Not Enough" [Shortest], the authors studied the performance of both an indoor and outdoor mesh network. By measuring inter-node throughput, the best path between nodes was computed. The throughput of the best path was compared with the throughput of the shortest path computed based on a hop-count metric. In almost all cases, the shortest path route offered considerably lower throughput than the best path.
「マルチホップワイヤレスネットワークのパフォーマンス：最短パスでは十分ではありません」[最短]では、著者は屋内および屋外メッシュネットワークの両方のパフォーマンスを研究しました。ノード間スループットを測定することにより、ノード間の最適なパスが計算されました。最適なパスのスループットは、ホップカウントメトリックに基づいて計算された最短パスのスループットと比較されました。ほとんどすべての場合、最短のパスルートは、最適なパスよりもかなり低いスループットを提供しました。
In examining link behavior, the authors found that rather than exhibiting a bi-modal distribution between "up" (low loss rate) and "down" (high loss rate), many links exhibited intermediate loss rates. Asymmetry was also common, with 30 percent of links demonstrating substantial differences in the loss rates in each direction. As a result, on wireless networks the measured throughput can differ substantially from the negotiated rate due to retransmissions, and successful delivery of routing packets is not necessarily an indication that the link is useful for delivery of data.
リンクの動作を調べる際に、著者は、「UP」（低損失率）と「ダウン」（高い損失率）の間にバイモーダル分布を示すのではなく、多くのリンクが中間損失率を示したことを発見しました。非対称性も一般的であり、リンクの30％が各方向の損失率に大きな違いを示しています。その結果、ワイヤレスネットワークでは、測定されたスループットは、再送信によるネゴシエートレートとは大幅に異なる場合があり、ルーティングパケットの配信の成功は、必ずしもリンクがデータの配信に役立つことを示すものではありません。
In "Measurement and Analysis of the Error Characteristics of an In-Building Wireless Network" [Eckhardt], the authors characterize the performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in Infrastructure mode on the Carnegie Mellon campus. In this study, very low frame loss was experienced. As a result, links could be assumed to operate either very well or not at all.
「ビルディング内のワイヤレスネットワークのエラー特性の測定と分析」[Eckhardt]では、著者は、カーネギーメロンキャンパスのインフラモードで動作するAT＆Tウェーヴァン2 MBPS内のWLANのパフォーマンスを特徴付けています。この研究では、非常に低いフレーム損失が経験されました。その結果、リンクは非常にうまく動作するか、まったく動作しないと想定できます。
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors analyze the causes of frame loss in a 38-node urban multi-hop 802.11 ad-hoc network. In most cases, links that are very bad in one direction tend to be bad in both directions, and links that are very good in one direction tend to be good in both directions. However, 30 percent of links exhibited loss rates differing substantially in each direction.
「802.11bメッシュネットワークからのリンクレベルの測定」[Aguayo]では、著者は38ノードの都市マルチホップ802.11アドホックネットワークのフレーム損失の原因を分析しています。ほとんどの場合、一方向で非常に悪いリンクは両方方向に悪い傾向があり、一方向に非常に良いリンクは両方方向に良い傾向があります。ただし、リンクの30％が損失率を示し、それぞれの方向が大幅に異なりました。
Signal to noise ratio (SNR) and distance showed little value in predicting loss rates, and rather than exhibiting a step-function transition between "up" (low loss) or "down" (high loss) states, inter-node loss rates varied widely, demonstrating a nearly uniform distribution over the range at the lower rates. The authors attribute the observed effects to multi-path fading, rather than attenuation or interference.
シグナルと騒音比（SNR）と距離は、損失率の予測にほとんど価値を示しませんでした。また、「UP」（低損失）または「ダウン」状態の間に段階的機能遷移を示すのではなく、ノード間損失率は異なります広く、低いレートで範囲上でほぼ均一な分布を示しています。著者は、観測された効果は、減衰や干渉ではなく、マルチパスフェードに起因すると考えています。
The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of link conditions observed in practice. While for indoor infrastructure networks site surveys and careful measurement can assist in promoting ideal behavior, in ad-hoc/mesh networks node mobility and external factors such as weather may not be easily controlled.
[Eckhardt]と[Aguayo]の発見は、実際に観察されたリンク条件の多様性を示しています。屋内インフラストラクチャネットワークのサイト調査と慎重な測定は、理想的な動作を促進するのに役立ちますが、アドホック/メッシュネットワークのノードモビリティや天気などの外部要因は簡単に制御できない場合があります。
Considerable diversity in behavior is also observed due to implementation effects. "Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos] measured handover times for a stationary STA after the AP was turned off. This study divided handover times into detection (determination of disconnection from the existing point of attachment), search (discovery of alternative attachment points), and execution (connection to an alternative point of attachment) phases. These measurements indicated that the duration of the detection phase (the largest component of handoff delay) is determined by the number of non-acknowledged frames triggering the search phase and delays due to precursors such as RTS/CTS and rate adaptation.
実装効果により、行動のかなりの多様性も観察されます。「IEEE 802.11b MACレイヤーハンドオーバー時間を減らすための技術」[Velayos] APがオフになった後の固定STAのハンドオーバー時間を測定しました。この研究では、ハンドオーバー時間を検出（既存の添付ファイルポイントからの切断の決定）、検索（代替添付ファイルの発見）、および実行（添付ファイルの代替点への接続）フェーズに分けました。これらの測定は、検出フェーズの持続時間（ハンドオフ遅延の最大コンポーネント）が、検索フェーズをトリガーする非概要フレームの数と、RTS/CTSやレート適応などの前駆体による遅延によって決定されることを示しています。
Detection behavior varied widely between implementations. For example, network interface cards (NICs) designed for desktops attempted more retransmissions prior to triggering search as compared with laptop designs, since they assumed that the AP was always in range, regardless of whether the Beacon was received.
検出動作は、実装間で大きく異なりました。たとえば、デスクトップ用に設計されたネットワークインターフェイスカード（NICS）は、ビーコンが受信されたかどうかに関係なく、APが常に範囲にあると想定していたため、ラップトップの設計と比較して検索をトリガーする前により多くの再送信を試みました。
The study recommends that the duration of the detection phase be reduced by initiating the search phase as soon as collisions can be excluded as the cause of non-acknowledged transmissions; the authors recommend three consecutive transmission failures as the cutoff. This approach is both quicker and more immune to multi-path interference than monitoring of the SNR. Where the STA is not sending or receiving frames, it is recommended that Beacon reception be tracked in order to detect disconnection, and that Beacon spacing be reduced to 60 ms in order to reduce detection times. In order to compensate for more frequent triggering of the search phase, the authors recommend algorithms for wait time reduction, as well as interleaving of search and data frame transmission.
この研究では、衝突が承認されていない送信の原因として衝突が除外されるとすぐに検索フェーズを開始することにより、検出段階の期間を短縮することを推奨しています。著者は、カットオフとして3つの連続した伝送障害を推奨しています。このアプローチは、SNRの監視よりも速く、マルチパス干渉に対してより迅速かつ免疫があります。STAがフレームを送信または受信していない場合、切断を検出するためにビーコン受信を追跡し、検出時間を短縮するためにビーコン間隔を60ミリ秒に減らすことをお勧めします。検索段階のより頻繁なトリガーを補うために、著者は、検索とデータフレームの送信のインターリーブと同様に、待機時間の削減のためのアルゴリズムを推奨します。
"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" [Mishra] investigates handoff latencies obtained with three mobile STA implementations communicating with two APs. The study found that there is a large variation in handoff latency among STA and AP implementations and that implementations utilize different message sequences. For example, one STA sends a Reassociation Request prior to authentication, which results in receipt of a Deauthenticate message. The study divided handoff latency into discovery, authentication, and reassociation exchanges, concluding that the discovery phase was the dominant component of handoff delay. Latency in the detection phase was not investigated.
「IEEE 802.11 Macレイヤーハンドオフプロセスの経験的分析」[Mishra]は、2つのAPと通信する3つのモバイルSTA実装で得られたハンドオフレイテンシーを調査します。この調査では、STAとAPの実装間でハンドオフレイテンシに大きなばらつきがあり、実装が異なるメッセージシーケンスを利用することがわかりました。たとえば、1つのSTAは、認証の前に再配分リクエストを送信します。これにより、免疫メッセージが受信されます。この研究では、ハンドオフレイテンシを発見、認証、および再配分交換に分割し、発見段階がハンドオフ遅延の支配的な要素であると結論付けました。検出段階の遅延は調査されませんでした。
"SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" [Ramani] weighs the pros and cons of active versus passive scanning. The authors point out the advantages of timed Beacon reception, which had previously been incorporated into [IEEE-802.11k]. Timed Beacon reception allows the station to continually keep up to date on the signal to noise ratio of neighboring APs, allowing handoff to occur earlier. Since the station does not need to wait for initial and subsequent responses to a broadcast Probe Response (MinChannelTime and MaxChannelTime, respectively), performance is comparable to what is achievable with 802.11k Neighbor Reports and unicast Probe Requests.
「Syncscan：802.11インフラストラクチャネットワークの実用的なハンドオフ」[Ramani]は、アクティブスキャンとパッシブスキャンの長所と短所を比較検討します。著者は、以前は[IEEE-802.11K]に組み込まれていた時限ビーコン受信の利点を指摘しています。タイミングのあるビーコン受信により、ステーションは隣接するAPSの信号対騒音比の最新の状態を継続的に維持することができ、ハンドオフが早く発生することができます。ステーションは、放送プローブ応答に対する初期およびその後の応答を待つ必要がないため（それぞれMinchanneltimeとMaxChanneltime）、パフォーマンスは802.11kの近隣レポートとユニキャストプローブリクエストで達成可能なものに匹敵します。
The authors measured the channel switching delay, the time it takes to switch to a new frequency and begin receiving frames. Measurements ranged from 5 ms to 19 ms per channel; where timed Beacon reception or interleaved active scanning is used, switching time contributes significantly to overall handoff latency. The authors propose deployment of APs with Beacons synchronized via Network Time Protocol (NTP) [RFC1305], enabling a driver implementing SyncScan to work with legacy APs without requiring implementation of new protocols. The authors measured the distribution of inter-arrival times for stations implementing SyncScan, with excellent results.
著者は、チャネルの切り替え遅延、新しい周波数に切り替えてフレームの受信を開始するのにかかる時間を測定しました。測定値は、チャネルあたり5ミリ秒から19ミリ秒の範囲でした。タイミングのあるビーコン受信またはインターリーブアクティブスキャンが使用される場合、切り替え時間は全体的なハンドオフレイテンシに大きく貢献します。著者は、ネットワークタイムプロトコル（NTP）[RFC1305]を介して同期したビーコンを使用してAPSの展開を提案し、Syncscanを実装するドライバーが新しいプロトコルの実装を必要とせずにレガシーAPと動作させることを可能にします。著者は、Syncscanを実装するステーションの攻撃時間の分布を測定し、優れた結果をもたらしました。
"Roaming Interval Measurements" [Alimian] presents data on the behavior of stationary STAs after the AP signal has been shut off. This study highlighted implementation differences in rate adaptation as well as detection, scanning, and handoff. As in [Velayos], performance varied widely between implementations, from half an order of magnitude variation in rate adaptation to an order of magnitude difference in detection times, two orders of magnitude in scanning, and one and a half orders of magnitude in handoff times.
「ローミング間隔測定」[Alimian]は、AP信号が遮断された後の静止STAの挙動に関するデータを提示します。この研究では、レート適応の実装の違いと、検出、スキャン、ハンドオフの違いを強調しました。[Velayos]と同様に、パフォーマンスは実装間で大きく異なります。レート適応の半分の桁の変動から、検出時間の桁の桁の差、スキャンの2桁、およびハンドオフ時間の1.5桁。
"An experimental study of IEEE 802.11b handoff performance and its effect on voice traffic" [Vatn] describes handover behavior observed when the signal from the AP is gradually attenuated, which is more representative of field experience than the shutoff techniques used in [Velayos]. Stations were configured to initiate handover when signal strength dipped below a threshold, rather than purely based on frame loss, so that they could begin handover while still connected to the current AP. It was noted that stations continued to receive data frames during the search phase. Station-initiated Disassociation and pre-authentication were not observed in this study.
「IEEE 802.11bハンドオフパフォーマンスと音声トラフィックへの影響の実験的研究」[VATN]は、APからの信号が徐々に減衰したときに観察されるハンドオーバー動作を説明しています。。ステーションは、信号強度が純粋にフレームの損失に基づいているのではなく、しきい値を下回ったときにハンドオーバーを開始するように構成され、現在のAPに接続しながら引き渡しを開始できるようにしました。ステーションは、検索フェーズ中にデータフレームを受け取ったことが続いたことが注目されました。この研究では、ステーション開始の分離と事前認証は観察されませんでした。
Within a link layer, the definition of "Link Up" and "Link Down" may vary according to the deployment scenario. For example, within PPP [RFC1661], either peer may send an LCP-Terminate frame in order to terminate the PPP link layer, and a link may only be assumed to be usable for sending network protocol packets once Network Control Protocol (NCP) negotiation has completed for that protocol.
リンクレイヤー内で、「リンクアップ」と「リンクダウン」の定義は、展開シナリオによって異なる場合があります。たとえば、PPP [RFC1661]内では、PPPリンクレイヤーを終了するためにLCPターミネートフレームを送信する場合があり、ネットワーク制御プロトコル（NCP）交渉後のネットワークプロトコルパケットを送信するためにリンクのみを使用できると想定される場合があります。そのプロトコルのために完了しました。
Unlike PPP, IEEE 802 does not include facilities for network layer configuration, and the definition of "Link Up" and "Link Down" varies by implementation. Empirical evidence suggests that the definition of "Link Up" and "Link Down" may depend on whether the station is mobile or stationary, whether infrastructure or ad-hoc mode is in use, and whether security and Inter-Access Point Protocol (IAPP) is implemented.
PPPとは異なり、IEEE 802にはネットワークレイヤー構成の施設は含まれておらず、「リンクアップ」と「リンクダウン」の定義は実装によって異なります。経験的証拠は、「リンクアップ」と「リンクダウン」の定義は、ステーションがモバイルであるか静止しているか、インフラストラクチャまたはアドホックモードが使用されているかどうか、およびセキュリティとアクセス間ポイントプロトコル（IAPP）に依存する可能性があることを示唆しています。実装されています。
Where a STA encounters a series of consecutive non-acknowledged frames while having missed one or more Beacons, the most likely cause is that the station has moved out of range of the AP. As a result, [Velayos] recommends that the station begin the search phase after collisions can be ruled out; since this approach does not take rate adaptation into account, it may be somewhat aggressive. Only when no alternative workable rate or point of attachment is found is a "Link Down" indication returned.
STAが1つ以上のビーコンを見逃している間に一連の連続した非承認フレームに遭遇する場合、最も可能性の高い原因は、ステーションがAPの範囲外に移動したことです。その結果、[Velayos]は、衝突を除外した後、ステーションが検索段階を開始することを推奨しています。このアプローチはレートの適応を考慮していないため、やや攻撃的かもしれません。代替の実行可能なレートまたは添付ポイントが見つからない場合にのみ、「リンクダウン」表示が返されます。
In a stationary point-to-point installation, the most likely cause of an outage is that the link has become impaired, and alternative points of attachment may not be available. As a result, implementations configured to operate in this mode tend to be more persistent. For example, within 802.11 the short interframe space (SIFS) interval may be increased and MIB variables relating to timeouts (such as dot11AuthenticationResponseTimeout, dot11AssociationResponseTimeout, dot11ShortRetryLimit, and dot11LongRetryLimit) may be set to larger values. In addition, a "Link Down" indication may be returned later.
静止したポイントツーポイントインストールでは、停止の最も可能性の高い原因は、リンクが損なわれ、添付ファイルの代替点が利用できないことです。その結果、このモードで動作するように構成された実装は、より永続的になる傾向があります。たとえば、802.11以内に、短いフレーム間隔（SIFS）間隔が増加し、タイムアウトに関連するMIB変数（dot11AuthenticationResponseTimeout、dot11associationResponsetime、dot11shortretrytrylimit、dot11longretrylimitなど）がより大きな価値に設定される場合があります。さらに、「リンクダウン」表示が後で返される場合があります。
In IEEE 802.11 ad-hoc mode with no security, reception of data frames is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a result, reception of data frames is enabled at any time, and no explicit "Link Up" indication exists.
セキュリティなしのIEEE 802.11アドホックモードでは、データフレームの受信が状態1で有効になっています（「認証されていない」および「非関連」）。その結果、データフレームの受信はいつでも有効になり、明示的な「リンクアップ」表示は存在しません。
In Infrastructure mode, IEEE 802.11-2003 enables reception of data frames only in State 3 ("Authenticated" and "Associated"). As a result, a transition to State 3 (e.g., completion of a successful Association or Reassociation exchange) enables sending and receiving of network protocol packets and a transition from State 3 to State 2 (reception of a "Disassociate" frame) or State 1 (reception of a "Deauthenticate" frame) disables sending and receiving of network protocol packets. As a result, IEEE 802.11 stations typically signal "Link Up" on receipt of a successful Association/Reassociation Response.
インフラストラクチャモードでは、IEEE 802.11-2003では、状態3（「認証」および「関連」）でのみデータフレームを受信できます。その結果、状態3への移行（例：成功した関連付けまたは再配分交換の完了）により、ネットワークプロトコルパケットの送信と受信と、状態3から状態2（「解離」フレームの受信）または状態1への移行を可能にします。（「Deauthenticate」フレームの受信）は、ネットワークプロトコルパケットの送信と受信を無効にします。その結果、IEEE 802.11ステーションは通常、成功した関連性/再配信応答の受領時に「リンクアップ」を信号します。
As described within [IEEE-802.11F], after sending a Reassociation Response, an Access Point will send a frame with the station's source address to a multicast destination. This causes switches within the Distribution System (DS) to update their learning tables, readying the DS to forward frames to the station at its new point of attachment. Were the AP to not send this "spoofed" frame, the station's location would not be updated within the distribution system until it sends its first frame at the new location. Thus, the purpose of spoofing is to equalize uplink and downlink handover times. This enables an attacker to deny service to authenticated and associated stations by spoofing a Reassociation Request using the victim's MAC address, from anywhere within the ESS. Without spoofing, such an attack would only be able to disassociate stations on the AP to which the Reassociation Request was sent.
[IEEE-802.11F]内で説明されているように、再配分応答を送信した後、アクセスポイントは、ステーションのソースアドレスを含むフレームをマルチキャストの宛先に送信します。これにより、配信システム（DS）内のスイッチが学習テーブルを更新し、DSを準備するために、新しい添付ファイルでフレームをステーションに転送します。APがこの「スプーフィングされた」フレームを送信しない場合、ステーションの場所は、新しい場所で最初のフレームを送信するまで配布システム内で更新されません。したがって、スプーフィングの目的は、アップリンクとダウンリンクのハンドオーバー時間を比較することです。これにより、攻撃者は、ESS内のどこからでも、被害者のMACアドレスを使用して再配分要求をスプーフィングすることにより、認証された関連ステーションと関連するステーションを拒否できます。スプーフィングなしでは、そのような攻撃は、再配分要求が送信されたAPのステーションを解離することしかできません。
The signaling of "Link Down" is considerably more complex. Even though a transition to State 2 or State 1 results in the station being unable to send or receive IP packets, this does not necessarily imply that such a transition should be considered a "Link Down" indication. In an infrastructure network, a station may have a choice of multiple Access Points offering connection to the same network. In such an environment, a station that is unable to reach State 3 with one Access Point may instead choose to attach to another Access Point. Rather than registering a "Link Down" indication with each move, the station may instead register a series of "Link Up" indications.
「Link Down」の信号はかなり複雑です。State 2またはState 1への移行により、ステーションがIPパケットを送信または受信できない場合、これは必ずしもそのような遷移が「リンクダウン」の表示と見なされるべきであることを意味するわけではありません。インフラストラクチャネットワークでは、ステーションには同じネットワークへの接続を提供する複数のアクセスポイントを選択できる場合があります。このような環境では、1つのアクセスポイントでState 3に到達できないステーションは、代わりに別のアクセスポイントに接続することを選択できます。各移動に「リンクダウン」の表示を登録するのではなく、ステーションは代わりに一連の「リンクアップ」表示を登録することができます。
In [IEEE-802.11i], forwarding of frames from the station to the distribution system is only feasible after the completion of the 4-way handshake and group-key handshake, so that entering State 3 is no longer sufficient. This has resulted in several observed problems. For example, where a "Link Up" indication is triggered on the station by receipt of an Association/Reassociation Response, DHCP [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be triggered prior to when the link is usable by the Internet layer, resulting in configuration delays or failures. Similarly, transport layer connections will encounter packet loss, resulting in back-off of retransmission timers.
[IEEE-802.11i]では、ステーションから配電システムへのフレームの転送は、4ウェイハンドシェイクとグループキーの握手が完了した後にのみ実現可能であるため、状態3に入るだけでは十分ではありません。これにより、いくつかの観察された問題が発生しました。たとえば、「リンクアップ」指示が関連性/再配分応答、DHCP [RFC2131]またはルーターの勧誘/ルーター広告（RS/RA）の受領により、リンクが使用可能な場合に使用可能な場合にトリガーされる場合があります。インターネット層は、構成の遅延または障害をもたらします。同様に、輸送層の接続はパケットの損失に遭遇し、その結果、再送信タイマーのバックオフが発生します。
In order to improve link layer performance, several studies have investigated "smart link layer" proposals.
リンクレイヤーのパフォーマンスを改善するために、いくつかの研究が「スマートリンクレイヤー」提案を調査しています。
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" [RFC3366] provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, timers, persistency in retransmission, and the challenges that arise from sharing links between multiple flows and from different transport requirements.
「リンク自動リピートリクエスト（ARQ）でデザイナーをリンクするためのアドバイス」[RFC3366]は、IPのリンク層自動リピートリクエスト（ARQ）テクニックを使用して、デジタル通信機器とリンク層プロトコルのデザイナーにアドバイスを提供します。ARQの使用、タイマーの使用、再送信の持続性、および複数のフロー間のリンクと異なる輸送要件からのリンクを共有することから生じる課題について説明します。
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the authors describe how the Global System for Mobile Communications (GSM)-reliable and unreliable link layer modes can be simultaneously utilized without higher layer control. Where a reliable link layer protocol is required (where reliable transports such TCP and Stream Control Transmission Protocol (SCTP) [RFC2960] are used), the Radio Link Protocol (RLP) can be engaged; with delay-sensitive applications such as those based on UDP, the transparent mode (no RLP) can be used. The authors also describe how PPP negotiation can be optimized over high-latency GSM links using "Quickstart-PPP".
「GSM上のTCP/IPのリンク層強化」[Ludwig]で、著者は、モバイル通信（GSM）のグローバルシステムがどのように依存性があり、信頼性の低いリンクレイヤーモードがどのように高レイヤー制御なしでも同時に利用できるかを説明しています。信頼できるリンクレイヤープロトコルが必要な場合（このようなTCPおよびストリーム制御伝送プロトコル（SCTP）[RFC2960] [RFC2960]などの信頼できる輸送が使用される場合）、無線リンクプロトコル（RLP）を雇用できます。UDPに基づくものなどの遅延敏感なアプリケーションでは、透明モード（RLPなし）を使用できます。著者はまた、「QuickStart-PPP」を使用して、PPPの交渉を高遅延GSMリンクで最適化する方法についても説明しています。
In "Link Layer Based TCP Optimisation for Disconnecting Networks" [Scott], the authors describe performance problems that occur with reliable transport protocols facing periodic network disconnections, such as those due to signal fading or handoff. The authors define a disconnection as a period of connectivity loss that exceeds a retransmission timeout, but is shorter than the connection lifetime. One issue is that link-unaware senders continue to back off during periods of disconnection. The authors suggest that a link-aware reliable transport implementation halt retransmission after receiving a "Link Down" indication. Another issue is that on reconnection the lengthened retransmission times cause delays in utilizing the link.
「ネットワークを切断するためのリンクレイヤーベースのTCP最適化」[Scott]で、著者は、信号のフェードやハンドオフによる定期的なネットワーク切断に直面している信頼できる輸送プロトコルで発生するパフォーマンスの問題について説明しています。著者は、再送信タイムアウトを超えるが、接続寿命よりも短い接続性損失の期間として切断を定義しています。1つの問題は、Link-Unaware送信者が切断期間中に引き継がれ続けることです。著者は、「リンクダウン」の表示を受け取った後、リンク認識の信頼できる信頼できる輸送実装が再送信を停止することを示唆しています。もう1つの問題は、再接続すると、延長された再送信時間がリンクを利用して遅延を引き起こすことです。
To improve performance, a "smart link layer" is proposed, which stores the first packet that was not successfully transmitted on a connection, then retransmits it upon receipt of a "Link Up" indication. Since a disconnection can result in hosts experiencing different network conditions upon reconnection, the authors do not advocate bypassing slow start or attempting to raise the congestion window. Where IPsec is used and connections cannot be differentiated because transport headers are not visible, the first untransmitted packet for a given sender and destination IP address can be retransmitted. In addition to looking at retransmission of a single packet per connection, the authors also examined other schemes such as retransmission of multiple packets and simulated duplicate reception of single or multiple packets (known as rereception).
パフォーマンスを改善するために、「スマートリンクレイヤー」が提案されています。これは、接続に正常に送信されなかった最初のパケットを保存し、「リンクアップ」表示を受け取ったときに再送信します。切断は、再接続時にさまざまなネットワーク条件を経験するホストにつながる可能性があるため、著者はゆっくりとしたスタートをバイパスしたり、うっ血ウィンドウを上げようとしたりすることを提唱しません。トランスポートヘッダーが見えないため、IPSECが使用され、接続を区別できない場合、特定の送信者と宛先IPアドレスの最初のトランスメットされていないパケットを再送信できます。接続ごとの単一のパケットの再送信に加えて、著者は、複数のパケットの再送信や単一パケットまたは複数のパケットのレセプションをシミュレートするなどの他のスキームも調べました（再受容として知られています）。
In general, retransmission schemes were superior to rereception schemes, since rereception cannot stimulate fast retransmit after a timeout. Retransmission of multiple packets did not appreciably improve performance over retransmission of a single packet. Since the focus of the research was on disconnection rather than just lossy channels, a two-state Markov model was used, with the "up" state representing no loss, and the "down" state representing 100 percent loss.
一般に、再受容はタイムアウト後に速い再送信を刺激することはできないため、再送信スキームは再受容スキームよりも優れていました。複数のパケットの再送信は、単一のパケットの再送信よりもパフォーマンスをあまり改善しませんでした。研究の焦点は、単なる損失のあるチャネルではなく切断にあったため、2つの状態のマルコフモデルが使用され、「UP」状態は損失なし、「ダウン」状態は100％の損失を表しています。
In "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links" [Xylomenos], the authors use ns-2 to simulate the performance of various link layer recovery schemes (raw link without retransmission, go back N, XOR-based FEC, selective repeat, Karn's RLP, out-of-sequence RLP, and Berkeley Snoop) in stand-alone file transfer, Web browsing, and continuous media distribution. While selective repeat and Karn's RLP provide the highest throughput for file transfer and Web browsing scenarios, continuous media distribution requires a combination of low delay and low loss and the out-of-sequence RLP performed best in this scenario. Since the results indicate that no single link layer recovery scheme is optimal for all applications, the authors propose that the link layer implement multiple recovery schemes. Simulations of the multi-service architecture showed that the combination of a low-error rate recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme for UDP traffic (such as out-of-sequence RLP) provides for good performance in all scenarios. The authors then describe how a multi-service link layer can be integrated with Differentiated Services.
「マルチサービスリンクレイヤー：ワイヤレスリンク上のインターネットパフォーマンスを強化するためのアプローチ」[Xylomenos]では、著者はNS-2を使用してさまざまなリンクレイヤーリカバリスキームのパフォーマンスをシミュレートします（再送信なしのRAWリンク、N、XORベースのベースFEC、選択的繰り返し、カーンのRLP、アウトオブシーケンスRLP、およびバークレースヌープ）スタンドアロンファイル転送、Webブラウジング、および継続的なメディア配布。選択的繰り返しとカーンのRLPは、ファイル転送およびWebブラウジングシナリオの最高のスループットを提供しますが、継続的なメディア分布には低遅延と低損失の組み合わせが必要であり、このシナリオで最適なシーケンスRLPが最適です。結果は、すべてのアプリケーションに単一のリンク層回復スキームが最適ではないことを示しているため、著者はリンク層が複数の回復スキームを実装することを提案しています。マルチサービスアーキテクチャのシミュレーションにより、TCP（Karn's RLPなど）の低誤差速度回復スキームの組み合わせとUDPトラフィック（シーケンス外RLPなど）の低遅延スキームの組み合わせが、優れたパフォーマンスを提供することが示されました。すべてのシナリオで。次に、著者は、マルチサービスリンクレイヤーを差別化されたサービスと統合する方法について説明します。
In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed Band" [Kamerman], the authors propose an open-loop rate adaptation algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender adjusts the rate upwards after a fixed number of successful transmissions, and adjusts the rate downwards after one or two consecutive failures. If after an upwards rate adjustment the transmission fails, the rate is immediately readjusted downwards.
「Wavelan-II：免許不要のバンドのための高性能ワイヤレスLAN」[Kamerman]では、著者は自動レートフォールバック（ARF）として知られるオープンループレート適応アルゴリズムを提案しています。ARFでは、送信者は、固定数の成功した送信後にレートを上方に調整し、1つまたは2つの連続した障害後にレートを下方に調整します。上向きのレート調整後、トランスミッションが失敗した場合、レートはすぐに下方に再調整されます。
In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks" [RBAR], the authors propose a closed-loop rate adaptation approach that requires incompatible changes to the IEEE 802.11 MAC. In order to enable the sender to better determine the transmission rate, the receiver determines the packet length and signal to noise ratio (SNR) of a received RTS frame and calculates the corresponding rate based on a theoretical channel model, rather than channel usage statistics. The recommended rate is sent back in the CTS frame. This allows the rate (and potentially the transmit power) to be optimized on each transmission, albeit at the cost of requiring RTS/CTS for every frame transmission.
「マルチホップワイヤレスネットワーク用のレート適応マックプロトコル」[RBAR]で、著者はIEEE 802.11 Macに互換性のない変更を必要とする閉ループレート適応アプローチを提案しています。送信者が送信速度をより適切に判断できるようにするために、受信者は受信したRTSフレームのパケット長と信号対ノイズ比（SNR）を決定し、チャネル使用統計ではなく理論チャネルモデルに基づいて対応するレートを計算します。推奨レートは、CTSフレームで送信されます。これにより、すべてのフレーム送信にRTS/CTSを必要とするため、レート（および潜在的に送信電力）を各伝送で最適化できます。
In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h" [Qiao], the authors propose a scheme for optimizing transmit power. The proposal mandates the use of RTS/CTS in order to deal with hidden nodes, requiring that CTS and ACK frames be sent at full power. The authors utilize a theoretical channel model rather than one based on channel usage statistics.
「Miser：IEEE 802.11 A/Hの最適な低エネルギー伝送戦略」[Qiao]で、著者は送信電力を最適化するスキームを提案しています。この提案は、隠されたノードに対処するためにRTS/CTSの使用を義務付けており、CTSとACKフレームをフルパワーで送信することを要求しています。著者は、チャネルの使用統計に基づいたものではなく、理論的チャネルモデルを利用しています。
In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage], the authors distinguish between low-latency implementations, which enable per-packet rate decisions, and high-latency implementations, which do not. The former implementations typically include dedicated CPUs in their design, enabling them to meet real-time requirements. The latter implementations are typically based on highly integrated designs in which the upper MAC is implemented on the host. As a result, due to operating system latencies the information required to make per-packet rate decisions may not be available in time.
「IEEE 802.11レートの適応：実用的なアプローチ」[裂傷]では、著者は、パケットあたりのレートの決定を可能にする低遅延の実装と、そうでない高遅延の実装を区別します。以前の実装には通常、設計に専用のCPUが含まれており、リアルタイムの要件を満たすことができます。後者の実装は、通常、ホストにアッパーマックが実装される高度に統合されたデザインに基づいています。その結果、オペレーティングシステムのレイテンシにより、パケットごとのレートの決定を行うために必要な情報は、時間内に利用できない場合があります。
The authors propose an Adaptive ARF (AARF) algorithm for use with low-latency implementations. This enables rapid downward rate negotiation on failure to receive an ACK, while increasing the number of successful transmissions required for upward rate negotiation. The AARF algorithm is therefore highly stable in situations where channel properties are changing slowly, but slow to adapt upwards when channel conditions improve. In order to test the algorithm, the authors utilized ns-2 simulations as well as implementing a version of AARF adapted to a high-latency implementation, the AR 5212 chipset. The Multiband Atheros Driver for WiFi (MadWiFi) driver enables a fixed schedule of rates and retries to be provided when a frame is queued for transmission. The adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR), requests only one transmission at each of three rates, the last of which is the minimum available rate. This enables adaptation to short-term fluctuations in the channel with minimal latency. The AMRR algorithm provides performance considerably better than the existing MadWifi driver.
著者は、低遅延の実装で使用するための適応ARF（AARF）アルゴリズムを提案しています。これにより、ACKを受け取らなかったための急速な下向きのレート交渉が可能になり、上向きのレート交渉に必要な成功した送信の数が増えます。したがって、AARFアルゴリズムは、チャネルプロパティがゆっくりと変化している状況では非常に安定していますが、チャネル条件が改善すると上向きに適応するのが遅くなります。アルゴリズムをテストするために、著者はNS-2シミュレーションを利用し、高遅延実装に適応したAARFのバージョンであるAR 5212チップセットを実装しました。WiFi（MADWIFI）ドライバー用のマルチバンドAtherosドライバーは、送信用にフレームがキューに登録されている場合、固定レートのスケジュールと再試行を提供できます。Adaptive Multi Rate Retry（AMRR）として知られる適応アルゴリズムは、3つのレートのそれぞれに1つの送信のみを要求します。最後のレートは最小レートです。これにより、最小限のレイテンシでチャネルの短期的な変動への適応が可能になります。AMRRアルゴリズムは、既存のMadwifiドライバーよりもかなり優れたパフォーマンスを提供します。
In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength Measurement" [Pavon], the authors propose an algorithm by which a STA adjusts the transmission rate based on a comparison of the received signal strength (RSS) from the AP with dynamically estimated threshold values for each transmission rate. Upon reception of a frame, the STA updates the average RSS, and on transmission the STA selects a rate and adjusts the RSS threshold values based on whether or not the transmission is successful. In order to validate the algorithm, the authors utilized an OPNET simulation without interference, and an ideal curve of bit error rate (BER) vs. signal to noise ratio (SNR) was assumed. Not surprisingly, the simulation results closely matched the maximum throughput achievable for a given signal to noise ratio, based on the ideal BER vs. SNR curve.
「受信信号強度測定を介したIEEE 802.11 WLANのリンク適応戦略」[Pavon]で、著者は、APからの受信信号強度（RSS）の比較に基づいてSTAが動的推定値との比較に基づいて透過率を調整するアルゴリズムを提案しています。各伝送速度のしきい値。フレームを受信すると、STAは平均RSSを更新し、送信時にSTAはレートを選択し、伝送が成功するかどうかに基づいてRSSしきい値を調整します。アルゴリズムを検証するために、著者は干渉なしにOPNETシミュレーションを使用し、ビットエラー率（BER）対信号対ノイズ比（SNR）の理想的な曲線が想定されました。当然のことながら、シミュレーション結果は、理想的なBER対SNR曲線に基づいて、特定の信号対ノイズ比で達成可能な最大スループットに密接に一致しました。
In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors describe a hybrid technique utilizing Signal Strength Indication (SSI) data to constrain the potential rates selected by statistics-based automatic rate control. Statistics-based rate control techniques include:
「IEEE 802.11のハイブリッドレート制御」[Haratcherev]では、著者は、統計ベースの自動速度制御によって選択された潜在的なレートを制約するために、信号強度表示（SSI）データを利用するハイブリッド技術について説明しています。統計ベースのレート制御手法には次のものがあります。
Maximum Throughput
最大スループット
This technique, which was chosen as the statistics-based technique in the hybrid scheme, sends a fraction of data at adjacent rates in order to estimate which rate provides the maximum throughput. Since accurate estimation of throughput requires a minimum number of frames to be sent at each rate, and only a fraction of frames are utilized for this purpose, this technique adapts more slowly at lower rates; with 802.11b rates, the adaptation time scale is typically on the order of a second. Depending on how many rates are tested, this technique can enable adaptation beyond adjacent rates. However, where maximum rate and low frame loss are already being encountered, this technique results in lower throughput.
ハイブリッドスキームの統計ベースの手法として選択されたこの手法は、最大スループットを提供するレートを推定するために、隣接レートでデータの一部を送信します。スループットの正確な推定では、各レートで最小のフレームを送信する必要があり、この目的のためにいくつかのフレームのみが利用されるため、この手法はより低いレートでよりゆっくりと適応します。802.11bのレートでは、適応時間スケールは通常、1秒の順序にあります。テストされている料金の数に応じて、この手法は隣接するレートを超えて適応を可能にすることができます。ただし、最大レートと低いフレームの損失がすでに遭遇している場合、この手法によりスループットが低くなります。
Frame Error Rate (FER) Control
フレームエラー率（FER）コントロール
This technique estimates the FER, attempting to keep it between a lower limit (if FER moves below, increase rate) and upper limit (if FER moves above, decrease rate). Since this technique can utilize all the transmitted data, it can respond faster than maximum throughput techniques. However, there is a tradeoff of reaction time versus FER estimation accuracy; at lower rates either reaction times slow or FER estimation accuracy will suffer. Since this technique only measures the FER at the current rate, it can only enable adaptation to adjacent rates.
この手法では、FERを推定し、下限（FERが下に移動し、速度を上げる場合）と上限（FERが上に移動する場合は、速度を下げる）の間に保持しようとします。この手法は送信されたすべてのデータを利用できるため、最大スループット技術よりも速く応答できます。ただし、反応時間とFER推定精度のトレードオフがあります。より低いレートでは、反応時間が遅いか、FER推定精度が低下します。この手法は現在のレートでのみferを測定するため、隣接するレートへの適応のみを可能にすることができます。
Retry-based
再試行ベース
This technique modifies FER control techniques by enabling rapid downward rate adaptation after a number (5-10) of unsuccessful retransmissions. Since fewer packets are required, the sensitivity of reaction time to rate is reduced. However, upward rate adaptation proceeds more slowly since it is based on a collection of FER data. This technique is limited to adaptation to adjacent rates, and it has the disadvantage of potentially worsening frame loss due to contention.
この手法は、失敗した再送信の数（5-10）の後に急速な下方速度適応を可能にすることにより、FER制御手法を修正します。必要なパケットが少ないため、速度までの反応時間の感度が低下します。ただし、FERデータのコレクションに基づいているため、上向きのレート適応はよりゆっくりと進行します。この手法は、隣接するレートへの適応に限定されており、競合によりフレームの損失が悪化する可能性があるという不利な点があります。
While statistics-based techniques are robust against short-lived link quality changes, they do not respond quickly to long-lived changes. By constraining the rate selected by statistics-based techniques based on ACK SSI versus rate data (not theoretical curves), more rapid link adaptation was enabled. In order to ensure rapid adaptation during rapidly varying conditions, the rate constraints are tightened when the SSI values are changing rapidly, encouraging rate transitions. The authors validated their algorithms by implementing a driver for the Atheros AR5000 chipset, and then testing its response to insertion and removal from a microwave oven acting as a Faraday cage. The hybrid algorithm dropped many fewer packets than the maximum throughput technique by itself.
統計ベースの手法は、短命のリンク品質の変化に対して堅牢ですが、長寿命の変更に迅速に反応しません。ACK SSIとレートデータ（理論的な曲線ではない）に基づく統計ベースの手法によって選択されたレートを制約することにより、より迅速なリンク適応が有効になりました。急速に変化する条件中に迅速な適応を確保するために、SSI値が急速に変化しているときにレートの制約が締められ、速度の移行が促進されます。著者は、Atheros AR5000チップセットのドライバーを実装することにより、アルゴリズムを検証し、ファラデーケージとして機能する電子レンジからの挿入と除去に対する反応をテストしました。ハイブリッドアルゴリズムは、最大スループット手法よりもはるかに少ないパケットを削除しました。
In order to estimate the SSI of data at the receiver, the ACK SSI was used. This approach does not require the receiver to provide the sender with the received power, so that it can be implemented without changing the IEEE 802.11 MAC. Calibration of the rate versus ACK SSI curves does not require a symmetric channel, but it does require that channel properties in both directions vary in a proportional way and that the ACK transmit power remains constant. The authors checked the proportionality assumption and found that the SSI of received data correlated highly (74%) with the SSI of received ACKs. Low pass filtering and monotonicity constraints were applied to remove noise in the rate versus SSI curves. The resulting hybrid rate adaptation algorithm demonstrated the ability to respond to rapid deterioration (and improvement) in channel properties, since it is not restricted to moving to adjacent rates.
受信機でデータのSSIを推定するために、ACK SSIが使用されました。このアプローチでは、IEEE 802.11 Macを変更せずに実装できるように、受信者に受信電力を送信者に提供する必要はありません。レートとACK SSI曲線のキャリブレーションは対称チャネルを必要としませんが、両方向のチャネルプロパティは比例的に異なり、ACK送信電力が一定のままであることが必要です。著者は、比例の仮定を確認し、受信したデータのSSIが受信ACKのSSIと高く相関していることを発見しました。低パスフィルタリングと単調性の制約が適用され、SSI曲線とのレートのノイズを除去しました。結果として生じるハイブリッドレート適応アルゴリズムは、隣接するレートに移動することに限定されていないため、チャネル特性の急速な劣化（および改善）に応答する能力を実証しました。
In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs" [CARA], the authors propose Collision-Aware Rate Adaptation (CARA). This involves utilization of Clear Channel Assessment (CCA) along with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS) mechanism to differentiate losses caused by frame collisions from losses caused by channel conditions. Rather than decreasing rate as the result of frame loss due to collisions, which leads to increased contention, CARA selectively enables RTS/CTS (e.g., after a frame loss), reducing the likelihood of frame loss due to hidden stations. CARA can also utilize CCA to determine whether a collision has occurred after a transmission; however, since CCA may not detect a significant fraction of all collisions (particularly when transmitting at low rate), its use is optional. As compared with ARF, in simulations the authors show large improvements in aggregate throughput due to addition of adaptive RTS/CTS, and additional modest improvements with the additional help of CCA.
「CARA：IEEE 802.11 WLANSの衝突認識料金適応」[CARA]では、著者は衝突認識料金適応（CARA）を提案しています。これには、クリアチャネル評価（CCA）の利用と、チャネル条件による損失によるフレーム衝突による損失を区別するための要求/クリア対センド（RTS/CTS）メカニズムの適応が含まれます。CARAは、衝突によるフレーム損失の結果としてフレーム損失の結果として減少するのではなく、RTS/CTSを選択的に有効にし（例：フレーム損失後）、隠されたステーションによるフレーム損失の可能性を減らします。CaraはCCAを利用して、送信後に衝突が発生したかどうかを判断することもできます。ただし、CCAはすべての衝突のかなりの部分を検出しない可能性があるため（特に低速で送信する場合）、その使用はオプションです。ARFと比較して、シミュレーションでは、著者は、適応RT/CTSの追加およびCCAの追加支援を受けて追加の控えめな改善により、集約スループットの大幅な改善を示しています。
In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust], the authors implemented the ARF, AARF, and SampleRate [SampleRate] algorithms on a programmable Access Point platform, and experimentally examined the performance of these algorithms as well as the ONOE [ONOE] algorithm implemented in MadWiFi. Based on their experiments, the authors critically examine the assumptions underlying existing rate negotiation algorithms:
「802.11ワイヤレスネットワークの堅牢なレート適応」[ロバスト]で、著者はプログラム可能なアクセスポイントプラットフォームにARF、AARF、およびサンプル[サンプル]アルゴリズムを実装し、これらのアルゴリズムのパフォーマンスとONOE [ONOE [ONOE]のパフォーマンスを実験的に検討しました。] Madwifiに実装されたアルゴリズム。著者は、実験に基づいて、既存のレートネゴシエーションアルゴリズムの根底にある仮定を批判的に調べます。
Decrease transmission rate upon severe frame loss Where severe frame loss is due to channel conditions, rate reduction can improve throughput. However, where frame loss is due to contention (such as from hidden stations), reducing transmission rate increases congestion, lowering throughput and potentially leading to congestive collapse. Instead, the authors propose adaptive enabling of RTS/CTS so as to reduce contention due to hidden stations. Once RTS/CTS is enabled, remaining losses are more likely to be due to channel conditions, providing more reliable guidance on increasing or decreasing transmission rate.
重度のフレーム損失がチャネル条件に起因する重度のフレーム損失により、伝送速度を減少させると、レートの低下はスループットを改善できます。ただし、フレームの損失が競合（隠されたステーションからのような）によるものである場合、透過速度の低下はうっ血を増加させ、スループットを減らし、うっ血性の崩壊につながる可能性があります。代わりに、著者は、隠されたステーションによる競合を減らすために、RTS/CTの適応性を有効にすることを提案します。RTS/CTSが有効になると、残りの損失はチャネル条件に起因する可能性が高く、伝送速度の増加または減少に関する信頼性の高いガイダンスが提供されます。
Use probe frames to assess possible new rates Probe frames reliably estimate frame loss at a given rate unless the sample size is sufficient and the probe frames are of comparable length to data frames. The authors argue that rate adaptation schemes such as SampleRate are too sensitive to loss of probe packets. In order to satisfy sample size constraints, a significant number of probe frames are required. This can increase frame loss if the probed rate is too high, and can lower throughput if the probed rate is too low. Instead, the authors propose assessment of the channel condition by tracking the frame loss ratio within a window of 5 to 40 frames.
プローブフレームを使用して、可能な新しいレートプローブフレームを評価して、サンプルサイズで十分で、プローブフレームがデータフレームに匹敵する長さでない限り、特定のレートでフレームの損失を確実に推定します。著者らは、サンプルなどのレート適応スキームはプローブパケットの損失に対して敏感すぎると主張しています。サンプルサイズの制約を満たすためには、かなりの数のプローブフレームが必要です。これにより、プローブレートが高すぎるとフレームの損失が増加し、プローブレートが低すぎるとスループットを減らすことができます。代わりに、著者は、5〜40フレームのウィンドウ内でフレーム損失比を追跡することにより、チャネル条件の評価を提案します。
Use consecutive transmission successes/losses to increase/decrease rate The authors argue that consecutive successes or losses are not a reliable basis for rate increases or decreases; greater sample size is needed.
連続した伝送の成功/損失を使用して、著者は、連続した成功または損失はレートの上昇または減少の信頼できる基盤ではないと主張しています。より大きなサンプルサイズが必要です。
Use PHY metrics like SNR to infer new transmission rate The authors argue that received signal to noise ratio (SNR) routinely varies 5 dB per packet and that variations of 10-14 dB are common. As a result, rate decisions based on SNR or signal strength can cause transmission rate to vary rapidly. The authors question the value of such rapid variation, since studies such as [Aguayo] show little correlation between SNR and frame loss probability. As a result, the authors argue that neither received signal strength indication (RSSI) nor background energy level can be used to distinguish losses due to contention from those due to channel conditions. While multi-path interference can simultaneously result in high signal strength and frame loss, the relationship between low signal strength and high frame loss is stronger. Therefore, transmission rate decreases due to low received signal strength probably do reflect sudden worsening in channel conditions, although sudden increases may not necessarily indicate that channel conditions have improved.
SNRなどのPHYメトリックを使用して新しい伝送速度を推測します著者は、受信信号対騒音比（SNR）はパケットあたり5 dBが定期的に変化し、10〜14 dBの変動が一般的であると主張します。その結果、SNRまたは信号強度に基づくレートの決定により、伝送速度が急速に変化する可能性があります。著者は、[Aguayo]などの研究がSNRとフレーム損失の確率の間にほとんど相関関係を示さないため、このような急速な変動の価値に疑問を呈しています。その結果、著者らは、チャネル条件による競合による損失を区別するために、信号強度表示（RSSI）もバックグラウンドエネルギーレベルも使用できないと主張しています。マルチパス干渉は同時に高い信号強度とフレーム損失をもたらす可能性がありますが、低信号強度と高フレーム損失の関係は強くなります。したがって、受信信号強度が低いために伝送速度が低下すると、おそらくチャネル条件の突然の悪化を反映していますが、突然の増加は必ずしもチャネル条件が改善したことを示しているわけではありません。
Long-term smoothened operation produces best average performance The authors present evidence that frame losses more than 150 ms apart are uncorrelated. Therefore, collection of statistical data over intervals of 1 second or greater reduces responsiveness, but does not improve the quality of transmission rate decisions. Rather, the authors argue that a sampling period of 100 ms provides the best average performance. Such small sampling periods also argue against use of probes, since probe packets can only represent a fraction of all data frames and probes collected more than 150 ms apart may not provide reliable information on channel conditions.
長期スムーズ化された操作は、最高の平均パフォーマンスを生成します著者は、フレーム損失が150ミリ秒以上離れているという証拠を提示します。したがって、1秒以上の間隔で統計データを収集すると、応答性が低下しますが、伝送速度の決定の質は向上しません。むしろ、著者らは、100ミリ秒のサンプリング期間が最高の平均パフォーマンスを提供すると主張しています。プローブパケットは、150ミリ秒以上収集されたすべてのデータフレームの一部と、チャネル条件に関する信頼できる情報を提供できないため、プローブパケットがすべてのデータフレームの一部を表すことができるため、このような小さなサンプリング期間もプローブの使用に反対しています。
Based on these flaws, the authors propose the Robust Rate Adaptation Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the current transmission rate to determine whether to increase or decrease the transmission rate; PHY layer information or probe packets are not used. Each transmission rate is associated with an estimation window, a maximum tolerable loss threshold (MTL) and an opportunistic rate increase threshold (ORI). If the loss ratio is larger than the MTL, the transmission rate is decreased, and if it is smaller than the ORI, transmission rate is increased; otherwise transmission rate remains the same. The thresholds are selected in order to maximize throughput. Although RRAA only allows movement between adjacent transmission rates, the algorithm does not require collection of an entire estimation window prior to increasing or decreasing transmission rates; if additional data collection would not change the decision, the change is made immediately.
これらの欠陥に基づいて、著者は堅牢なレート適応アルゴリズム（RRAA）を提案します。RRAAは、現在の伝送速度でフレーム損失率のみを利用して、伝送速度を増加または減少させるかどうかを判断します。PHYレイヤー情報またはプローブパケットは使用されません。各伝送速度は、推定ウィンドウ、最大許容損失しきい値（MTL）、および日和見レートの増加しきい値（ORI）に関連付けられています。損失率がMTLよりも大きい場合、透過率は低下し、ORIよりも小さくなると、伝送速度が増加します。それ以外の場合は、伝送速度は同じままです。スループットを最大化するために、しきい値が選択されます。RRAAは隣接する透過率間の移動を許可しますが、アルゴリズムは、伝送速度を増加または減少させる前に、推定ウィンドウ全体の収集を必要としません。追加のデータ収集が決定を変更しない場合、変更はすぐに行われます。
The authors validate the RRAA algorithm using experiments and field trials; the results indicate that RRAA without adaptive RTS/CTS outperforms the ARF, AARF, and Sample Rate algorithms. This occurs because RRAA is not as sensitive to transient frame loss and does not use probing, enabling it to more frequently utilize higher transmission rates. Where there are no hidden stations, turning on adaptive RTS/CTS reduces performance by at most a few percent. However, where there is substantial contention from hidden stations, adaptive RTS/CTS provides large performance gains, due to reduction in frame loss that enables selection of a higher transmission rate.
著者は、実験とフィールドトライアルを使用してRRAAアルゴリズムを検証します。結果は、適応型RT/CTSのないRRAAがARF、AARF、およびサンプルレートアルゴリズムを上回ることを示しています。これは、RRAAが一時的なフレーム損失に敏感ではなく、プロービングを使用せず、より頻繁により高い伝送速度を利用できるようにするために発生します。隠されたステーションがない場合、適応性のあるRTS/CTSをオンにすると、パフォーマンスが最大数パーセント減少します。ただし、隠されたステーションからかなりの競合がある場合、適応型RT/CTSは、より高い伝送速度の選択を可能にするフレーム損失の減少により、大きなパフォーマンスの向上を提供します。
In "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN" [Vertical], the authors propose use of signal strength and link utilization in order to optimize vertical handoff. WLAN to WWAN handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a threshold (S1), Fast Fourier Transform (FFT)-based decay detection is undertaken to determine if the signal is likely to continue to decay. If so, then handoff to the WWAN is initiated when the signal falls below the minimum acceptable level (S2). WWAN to WLAN handoff is driven by both PHY and MAC characteristics of the IEEE 802.11 target network. At the PHY layer, characteristics such as SSI are examined to determine if the signal strength is greater than a minimum value (S3). At the MAC layer, the IEEE 802.11 Network Allocation Vector (NAV) occupation is examined in order to estimate the maximum available bandwidth and mean access delay. Note that depending on the value of S3, it is possible for the negotiated rate to be less than the available bandwidth. In order to prevent premature handoff between WLAN and WWAN, S1 and S2 are separated by 6 dB; in order to prevent oscillation between WLAN and WWAN media, S3 needs to be greater than S1 by an appropriate margin.
「WWANとWLAN間の垂直ハンドオフの効率的なモビリティ管理」[Vertical]では、著者は、垂直ハンドオフを最適化するために信号強度とリンク使用率の使用を提案しています。WWANからWWANへのハンドオフは、SSI減衰によって駆動されます。IEEE 802.11 SSIがしきい値（S1）を下回ると、高速フーリエ変換（FFT）ベースの減衰検出が行われ、信号が減衰し続ける可能性があるかどうかを判断します。その場合、信号が最小許容レベル（S2）を下回ると、WWANへのハンドオフが開始されます。WWANからWLANのハンドオフは、IEEE 802.11ターゲットネットワークのPHYおよびMAC特性の両方によって駆動されます。Phy層では、SSIなどの特性を調べて、信号強度が最小値（S3）よりも大きいかどうかを判断します。MACレイヤーでは、IEEE 802.11ネットワーク割り当てベクター（NAV）職業を調べて、利用可能な最大帯域幅と平均アクセス遅延を推定します。S3の値に応じて、交渉されたレートが利用可能な帯域幅よりも少ないことが可能であることに注意してください。WLANとWWAN間の早期ハンドオフを防ぐために、S1とS2は6 dBで分離されます。WLANとWWANメディア間の振動を防ぐために、S3は適切なマージンでS1より大きくする必要があります。
Within the Internet layer, proposals have been made for utilizing link indications to optimize IP configuration, to improve the usefulness of routing metrics, and to optimize aspects of Mobile IP handoff.
インターネットレイヤー内で、リンク表示を利用してIP構成を最適化し、ルーティングメトリックの有用性を改善し、モバイルIPハンドオフの側面を最適化するための提案が作成されています。
In "Analysis of link failures in an IP backbone" [Iannaccone], the authors investigate link failures in Sprint's IP backbone. They identify the causes of convergence delay, including delays in detection of whether an interface is down or up. While it is fastest for a router to utilize link indications if available, there are situations in which it is necessary to depend on loss of routing packets to determine the state of the link. Once the link state has been determined, a delay may occur within the routing protocol in order to dampen link flaps. Finally, another delay may be introduced in propagating the link state change, in order to rate limit link state advertisements, and guard against instability.
「IPバックボーンのリンク障害の分析」[Iannaccone]では、著者はSprintのIPバックボーンのリンク障害を調査しています。彼らは、インターフェイスがダウンしているかアップしているかの検出の遅延など、収束遅延の原因を特定します。ルーターが利用可能な場合はリンクの表示を利用するのが最速ですが、リンクの状態を決定するためにルーティングパケットの損失に依存する必要がある状況があります。リンク状態が決定されると、リンクフラップを減衰させるために、ルーティングプロトコル内で遅延が発生する可能性があります。最後に、リンク状態広告を制限し、不安定性を防ぐために、リンク状態の変更を伝播する際に別の遅延が導入される場合があります。
"Bidirectional Forwarding Detection" [BFD] notes that link layers may provide only limited failure indications, and that relatively slow "Hello" mechanisms are used in routing protocols to detect failures when no link layer indications are available. This results in failure detection times of the order of a second, which is too long for some applications. The authors describe a mechanism that can be used for liveness detection over any media, enabling rapid detection of failures in the path between adjacent forwarding engines. A path is declared operational when bidirectional reachability has been confirmed.
「双方向転送検出」[BFD]は、リンクレイヤーが限られた障害指示のみを提供する可能性があり、リンクレイヤーの表示が利用できないときに障害を検出するためにルーティングプロトコルで比較的遅い「ハロー」メカニズムが使用されることを指摘しています。これにより、1秒の順序の障害検出時間が発生し、一部のアプリケーションには長すぎます。著者は、あらゆる媒体よりも活気のある検出に使用できるメカニズムについて説明し、隣接する転送エンジン間のパスでの障害の迅速な検出を可能にします。双方向の到達可能性が確認されている場合、パスは動作すると宣言されます。
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host that has moved to a new point of attachment utilizes a bidirectional reachability test in parallel with DHCP [RFC2131] to rapidly reconfirm an operable configuration.
「IPv4のネットワークアタッチメント（DNA）の検出（DNA）[RFC4436]では、添付ファイルの新しいポイントに移動したホストが、DHCP [RFC2131]と並行して双方向の到達可能性テストを利用して、動作可能な構成を迅速に再構成します。
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example" [Park], the authors propose that the mobile node send a router solicitation on receipt of a "Link Up" indication in order to provide lower handoff latency than would be possible using generic movement detection [RFC3775]. The authors also suggest immediate invalidation of the Care-of Address (CoA) on receipt of a "Link Down" indication. However, this is problematic where a "Link Down" indication can be followed by a "Link Up" indication without a resulting change in IP configuration, as described in [RFC4436].
「L2トリガー最適化されたモバイルIPv6垂直ハンドオーバー：802.11/gprsの例」[[PARK]で、著者は、モバイルノードが下位ハンドオフのレイテンシを提供するために「リンクアップ」表示を受け取るためにルーターの勧誘を送信することを提案しています。一般的な動きの検出を使用して可能です[RFC3775]。著者はまた、「リンクダウン」の表示を受け取ったときに、即時の住所（COA）の即時無効化を提案しています。ただし、これは、[RFC4436]で説明されているように、「リンクダウン」の表示に続いて、IP構成を結果として変更することなく「リンクアップ」表示が続く場合に問題があります。
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors suggest that MIPv4 Registration messages be carried within Information Elements of IEEE 802.11 Association/Reassociation frames, in order to minimize handoff delays. This requires modification to the mobile node as well as 802.11 APs. However, prior to detecting network attachment, it is difficult for the mobile node to determine whether or not the new point of attachment represents a change of network. For example, even where a station remains within the same ESS, it is possible that the network will change. Where no change of network results, sending a MIPv4 Registration message with each Association/Reassociation is unnecessary. Where a change of network results, it is typically not possible for the mobile node to anticipate its new CoA at Association/Reassociation; for example, a DHCP server may assign a CoA not previously given to the mobile node. When dynamic VLAN assignment is used, the VLAN assignment is not even determined until IEEE 802.1X authentication has completed, which is after Association/Reassociation in [IEEE-802.11i].
「802.11を使用したモバイル-IPV4のレイヤー2ハンドオフ」[MUN]で、著者は、ハンドオフの遅延を最小限に抑えるために、IEEE 802.11 Association/再配分フレームの情報要素内でMIPV4登録メッセージを携帯することを示唆しています。これには、モバイルノードと802.11 APSの変更が必要です。ただし、ネットワークの添付ファイルを検出する前に、モバイルノードが添付の新しいポイントがネットワークの変更を表すかどうかを判断することは困難です。たとえば、ステーションが同じESS内に残っている場合でも、ネットワークが変更される可能性があります。ネットワークの変更が結果でない場合、各関連/再配信でMIPV4登録メッセージを送信することは不要です。ネットワークの変更が結果である場合、通常、モバイルノードが関連/再配信で新しいCOAを予測することは不可能です。たとえば、DHCPサーバーは、モバイルノードに以前に与えられていないCOAを割り当てる場合があります。動的VLAN割り当てを使用すると、VLANの割り当ては、IEEE 802.1x認証が完了するまで決定されません。
In "Link Characteristics Information for Mobile IP" [Lee], link characteristics are included in registration/Binding Update messages sent by the mobile node to the home agent and correspondent node. Where the mobile node is acting as a receiver, this allows the correspondent node to adjust its transport parameters window more rapidly than might otherwise be possible. Link characteristics that may be communicated include the link type (e.g., 802.11b, CDMA (Code Division Multiple Access), GPRS (General Packet Radio Service), etc.) and link bandwidth. While the document suggests that the correspondent node should adjust its sending rate based on the advertised link bandwidth, this may not be wise in some circumstances. For example, where the mobile node link is not the bottleneck, adjusting the sending rate based on the link bandwidth could cause congestion. Also, where the transmission rate changes frequently, sending registration messages on each transmission rate change could by itself consume significant bandwidth. Even where the advertised link characteristics indicate the need for a smaller congestion window, it may be non-trivial to adjust the sending rates of individual connections where there are multiple connections open between a mobile node and correspondent node. A more conservative approach would be to trigger parameter re-estimation and slow start based on the receipt of a registration message or Binding Update.
「モバイルIPのリンク特性情報」[Lee]では、モバイルノードからホームエージェントと特派員ノードに送信された登録/バインディングアップデートメッセージにリンク特性が含まれています。モバイルノードがレシーバーとして機能している場合、これにより、特派員ノードが他の方法で可能な場合よりも迅速に輸送パラメータウィンドウを調整できます。伝達される可能性のあるリンクの特性には、リンクタイプ（802.11b、CDMA（コード分割複数アクセス）、GPRS（一般的なパケットラジオサービス）など）およびリンク帯域幅が含まれます。文書は、特派員ノードが広告されたリンク帯域幅に基づいて送信率を調整する必要があることを示唆していますが、状況によってはこれは賢明ではないかもしれません。たとえば、モバイルノードリンクがボトルネックではない場合、リンク帯域幅に基づいて送信レートを調整するとうっ血が発生する可能性があります。また、送信速度が頻繁に変化する場合、各伝送速度の変更で登録メッセージを送信すると、それ自体が大幅な帯域幅を消費する可能性があります。宣伝されているリンクの特性が小さい混雑ウィンドウの必要性を示している場合でも、モバイルノードと特派員ノードの間に複数の接続が開いている場合、個々の接続の送信速度を調整することは重要ではない場合があります。より保守的なアプローチは、登録メッセージまたはバインディングアップデートの受信に基づいて、パラメーターの再評価と遅い開始をトリガーすることです。
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile Ad-hoc NETwork (MANET) routing protocols have a tendency to concentrate traffic since they utilize shortest-path metrics and allow nodes to respond to route queries with cached routes. The authors propose that nodes participating in an ad-hoc wireless mesh monitor local conditions such as MAC delay, buffer consumption, and packet loss. Where congestion is detected, this is communicated to neighboring nodes via an IP option. In response to moderate congestion, nodes suppress route requests; where major congestion is detected, nodes rate control transport connections flowing through them. The authors argue that for ad-hoc networks, throttling by intermediate nodes is more effective than end-to-end congestion control mechanisms.
「Hotspot Mitigation Protocol（HMP）」[HMP]では、モバイルアドホックネットワーク（MANET）ルーティングプロトコルは、最短のパスメトリックを利用し、ノードがCachedのルートクエリに応答できるため、トラフィックを集中する傾向があることに注意してください。ルート。著者は、アドホックワイヤレスメッシュに参加しているノードが、MAC遅延、バッファー消費、パケット損失などのローカル条件を監視することを提案しています。輻輳が検出された場合、これはIPオプションを介して隣接するノードに通知されます。中程度の混雑に応じて、ノードはルート要求を抑制します。主要な輻輳が検出された場合、ノードはそれらを流れるように流れる輸送接続を制御するレートをレートします。著者らは、アドホックネットワークでは、中間ノードによるスロットリングはエンドツーエンドの混雑制御メカニズムよりも効果的であると主張しています。
Within the transport layer, proposals have focused on countering the effects of handoff-induced packet loss and non-congestive loss caused by lossy wireless links.
輸送層内で、提案は、ハンドオフ誘発パケット損失の影響と、無線リンクの損失によって引き起こされる非同一の損失の影響に対抗することに焦点を当てています。
Where a mobile host moves to a new network, the transport parameters (including the RTT, RTO, and congestion window) may no longer be valid. Where the path change occurs on the sender (e.g., change in outgoing or incoming interface), the sender can reset its congestion window and parameter estimates. However, where it occurs on the receiver, the sender may not be aware of the path change.
モバイルホストが新しいネットワークに移動する場合、トランスポートパラメーター（RTT、RTO、および輻輳ウィンドウを含む）はもはや有効ではありません。送信者でパスの変更が発生する場合（たとえば、発信または着信インターフェイスの変更）、送信者はうっ血ウィンドウとパラメーターの推定値をリセットできます。ただし、レシーバーで発生する場合、送信者はパスの変更を認識していない場合があります。
In "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim], the authors note that handoff-related packet loss is interpreted as congestion by the transport layer. In the case where the correspondent node is sending to the mobile node, it is proposed that receipt of a Binding Update by the correspondent node be used as a signal to the transport layer to adjust cwnd and ssthresh values, which may have been reduced due to handoff-induced packet loss. The authors recommend that cwnd and ssthresh be recovered to pre-timeout values, regardless of whether the link parameters have changed. The paper does not discuss the behavior of a mobile node sending a Binding Update, in the case where the mobile node is sending to the correspondent node.
「モバイルIPv6よりもTCPパフォーマンスを改善するためのBUトリガー方法」[KIM]では、著者らは、ハンドオフ関連のパケット損失が輸送層による混雑として解釈されることを指摘しています。特派員ノードがモバイルノードに送信されている場合、CWNDおよびSSThresh値を調整するために、輸送層への信号としてのバインディングアップデートの受信を輸送層の信号として使用することが提案されています。ハンドオフ誘発パケット損失。著者は、リンクパラメーターが変更されたかどうかにかかわらず、CWNDとSSTHRESHをタイムアウト前の値に回復することを推奨しています。このペーパーでは、モバイルノードが特派員ノードに送信されている場合、バインディングアップデートを送信するモバイルノードの動作については説明していません。
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate Control" [Gurtov], the authors examine the effect of explicit handover notifications on TCP-friendly rate control (TFRC). Where explicit handover notification includes information on the loss rate and throughput of the new link, this can be used to instantaneously change the transmission rate of the sender. The authors also found that resetting the TFRC receiver state after handover enabled parameter estimates to adjust more quickly.
「TCPフレンドリーレートコントロールのパフォーマンスに対する垂直ハンドオーバーの効果」[Gurtov]では、著者はTCPフレンドリーレートコントロール（TFRC）に対する明示的なハンドオーバー通知の効果を調べます。明示的なハンドオーバー通知には、新しいリンクの損失率とスループットに関する情報が含まれている場合、これを使用して送信者の伝送速度を即座に変更できます。著者らはまた、ハンドオーバー後にTFRCレシーバー状態をリセットすると、パラメーターの推定値がより迅速に調整できるようにすることを発見しました。
In "Adapting End Host Congestion Control for Mobility" [Eddy], the authors note that while MIPv6 with route optimization allows a receiver to communicate a subnet change to the sender via a Binding Update, this is not available within MIPv4. To provide a communication vehicle that can be universally employed, the authors propose a TCP option that allows a connection endpoint to inform a peer of a subnet change. The document does not advocate utilization of "Link Up" or "Link Down" events since these events are not necessarily indicative of subnet change. On detection of subnet change, it is advocated that the congestion window be reset to INIT_WINDOW and that transport parameters be re-estimated. The authors argue that recovery from slow start results in higher throughput both when the subnet change results in lower bottleneck bandwidth as well as when bottleneck bandwidth increases.
「モビリティのためのエンドホストの混雑制御の適応」[Eddy]では、著者らは、ルート最適化を備えたMipv6を使用すると、レシーバーがバインディングアップデートを介してサブネットの変更を送信者に通信できるようにするが、これはMIPV4内では利用できないことに注意してください。著者は、普遍的に採用できる通信車両を提供するために、接続エンドポイントがピアにサブネットの変更を通知できるTCPオプションを提案します。ドキュメントは、これらのイベントが必ずしもサブネットの変更を示すとは限らないため、「リンクアップ」または「リンクダウン」イベントの利用を提唱していません。サブネットの変更を検出すると、輻輳ウィンドウをinit_windowにリセットし、輸送パラメーターが再推定されることが主張されています。著者らは、スロースタートからの回復により、サブネットの変更がより低いボトルネック帯域幅をもたらすと、ボトルネックの帯域幅が増加するときの両方で、スループットが高くなると主張しています。
In "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN" [Vertical], the authors propose a "Virtual Connectivity Manager", which utilizes local connection translation (LCT) and a subscription/notification service supporting simultaneous movement in order to enable end-to-end mobility and maintain TCP throughput during vertical handovers.
「WWANとWLAN間の垂直ハンドオフの効率的なモビリティ管理」[Vertical]では、著者は「仮想接続マネージャー」を提案します。これは、ローカル接続変換（LCT）と同時動きをサポートするサブスクリプション/通知サービスを利用して、エンドを可能にするサブスクリプション/通知サービスを利用します。垂直方向のハンドオーバー中にモビリティを繰り返し、TCPスループットを維持します。
In an early version of "Datagram Congestion Control Protocol (DCCP)" [RFC4340], a "Reset Congestion State" option was proposed in Section 11. This option was removed in part because the use conditions were not fully understood:
「Datagramうっ血コントロールプロトコル（DCCP）」[RFC4340]の初期バージョンでは、セクション11で「リセット輻輳状態」オプションが提案されました。このオプションは、使用条件が完全に理解されていないために部分的に削除されました。
An HC-Receiver sends the Reset Congestion State option to its sender to force the sender to reset its congestion state -- that is, to "slow start", as if the connection were beginning again. ... The Reset Congestion State option is reserved for the very few cases when an endpoint knows that the congestion properties of a path have changed. Currently, this reduces to mobility: a DCCP endpoint on a mobile host MUST send Reset Congestion State to its peer after the mobile host changes address or path.
HC-Receiverは、リセットの混雑状態オプションを送信者に送信し、送信者に渋滞状態を強制的にリセットさせます。つまり、接続が再び開始されているかのように「スロースタート」になります。...リセットの輻輳状態オプションは、エンドポイントがパスの輻輳特性が変更されたことを知っている場合に予約されています。現在、これによりモビリティが減少します。モバイルホストのDCCPエンドポイントは、モバイルホストがアドレスまたはパスを変更した後、リセットの混雑状態をピアに送信する必要があります。
"Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses optimizations to recover earlier from a retransmission timeout incurred during a period in which an interface or intervening link was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup] describes methods by which a TCP implementation that has backed off its retransmission timer due to frame loss on a remote link can learn that the link has once again become operational. This enables retransmission to be attempted prior to expiration of the backed-off retransmission timer.
「Trigtranのフレームワークと要件」[Trigtran]は、インターフェースまたは介入リンクがダウンしている期間に発生した再送信タイムアウトから早期に回復する最適化について説明します。「エンドツーエンドの暗黙の「リンクアップ」通知 "[e2elinkup]は、リモートリンクのフレームロスのために再送信タイマーを後退させたTCP実装が、リンクが再び動作可能になったことを知ることができる方法を説明します。。これにより、バックオフ再送信タイマーの満了前に再送信を試みることができます。
"Link-layer Triggers Protocol" [Yegin] describes transport issues arising from lack of host awareness of link conditions on downstream Access Points and routers. Transport of link layer triggers is proposed to address the issue.
「Link-Layer Trigger Protocol」[Yegin]は、下流のアクセスポイントとルーターのリンク条件に対するホストの認識の欠如から生じる輸送の問題を説明しています。リンク層トリガーの輸送が提案されており、問題に対処します。
"TCP Extensions for Immediate Retransmissions" [Eggert] describes how a transport layer implementation may utilize existing "end-to-end connectivity restored" indications. It is proposed that in addition to regularly scheduled retransmissions that retransmission be attempted by the transport layer on receipt of an indication that connectivity to a peer node may have been restored. End-to-end connectivity restoration indications include "Link Up", confirmation of first-hop router reachability, confirmation of Internet layer configuration, and receipt of other traffic from the peer.
「即時再送信のためのTCP拡張機能」[Eggert]は、輸送層の実装が既存の「エンドツーエンド接続が復元された「適応」を利用する方法を説明しています。定期的にスケジュールされた再送信に加えて、ピアノードへの接続性が復元された可能性があることを示す兆候を受け取った輸送層によって再送信を試みることが提案されています。エンドツーエンドの接続の復元指示には、「リンクアップ」、最初のホップルーターの到達可能性の確認、インターネット層構成の確認、ピアからのその他のトラフィックの受信が含まれます。
In "Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver" [Biaz], the authors propose a scheme for differentiating congestive losses from wireless transmission losses based on inter-arrival times. Where the loss is due to wireless transmission rather than congestion, congestive backoff and cwnd adjustment is omitted. However, the scheme appears to assume equal spacing between packets, which is not realistic in an environment exhibiting link layer frame loss. The scheme is shown to function well only when the wireless link is the bottleneck, which is often the case with cellular networks, but not with IEEE 802.11 deployment scenarios such as home or hotspot use.
「受信者での到達時間を使用したワイヤレス損失からの輻輳損失の識別」[BIAZ]では、著者は、攻撃間の時間に基づいてワイヤレス送信の損失を区別するスキームを提案しています。輻輳ではなく無線伝送による損失が原因である場合、うっ血性のバックオフとCWND調整は省略されています。ただし、スキームはパケット間の等しい間隔を想定しているように見えますが、これはリンクレイヤーフレームの損失を示す環境では現実的ではありません。このスキームは、ワイヤレスリンクがボトルネックである場合にのみ適切に機能することが示されています。これは、多くの場合、セルラーネットワークの場合ですが、ホームやホットスポットの使用などのIEEE 802.11展開シナリオではそうではありません。
In "Improving Performance of TCP over Wireless Networks" [Bakshi], the authors focus on the performance of TCP over wireless networks with burst losses. The authors simulate performance of TCP Tahoe within ns-2, utilizing a two-state Markov model, representing "good" and "bad" states. Where the receiver is connected over a wireless link, the authors simulate the effect of an Explicit Bad State Notification (EBSN) sent by an Access Point unable to reach the receiver. In response to an EBSN, it is advocated that the existing retransmission timer be canceled and replaced by a new dynamically estimated timeout, rather than being backed off. In the simulations, EBSN prevents unnecessary timeouts, decreasing RTT variance and improving throughput.
「ワイヤレスネットワークよりもTCPのパフォーマンスの向上」[Bakshi]では、著者はバースト損失を伴うワイヤレスネットワーク上のTCPのパフォーマンスに焦点を当てています。著者は、NS-2内のTCP Tahoeのパフォーマンスをシミュレートし、「良い」状態と「悪い」状態を表す2つの状態のマルコフモデルを使用しています。受信機がワイヤレスリンクで接続されている場合、著者は、受信者に到達できないアクセスポイントによって送信される明示的な悪い状態通知（EBSN）の効果をシミュレートします。EBSNに応じて、既存の再送信タイマーをキャンセルし、後退するのではなく、新しい動的に推定されたタイムアウトに置き換えることが主張されています。シミュレーションでは、EBSNは不必要なタイムアウトを防ぎ、RTTの分散を減らし、スループットの改善を防ぎます。
In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc Wireless Networks" [Chandran], the authors proposed an explicit Route Failure Notification (RFN), allowing the sender to stop its retransmission timers when the receiver becomes unreachable. On route reestablishment, a Route Reestablishment Notification (RRN) is sent, unfreezing the timer. Simulations indicate that the scheme significantly improves throughput and reduces unnecessary retransmissions.
「アドホックワイヤレスネットワークでTCPパフォーマンスを改善するためのフィードバックベースのスキーム」[Chandran]で、著者は明示的なルート障害通知（RFN）を提案し、受信者が到達不能になったときに送信者が再送信タイマーを停止できるようにしました。ルートの再確立で、ルートの再確立通知（RRN）が送信され、タイマーが凍結されていません。シミュレーションは、スキームがスループットを大幅に改善し、不必要な再送信を減らすことを示しています。
In "Analysis of TCP Performance over Mobile Ad Hoc Networks" [Holland], the authors explore how explicit link failure notification (ELFN) can improve the performance of TCP in mobile ad hoc networks. ELFN informs the TCP sender about link and route failures so that it need not treat the ensuing packet loss as due to congestion. Using an ns-2 simulation of TCP Reno over 802.11 with routing provided by the Dynamic Source Routing (DSR) protocol, it is demonstrated that TCP performance falls considerably short of expected throughput based on the percentage of the time that the network is partitioned. A portion of the problem was attributed to the inability of the routing protocol to quickly recognize and purge stale routes, leading to excessive link failures; performance improved dramatically when route caching was turned off. Interactions between the route request and transport retransmission timers were also noted. Where the route request timer is too large, new routes cannot be supplied in time to prevent the transport timer from expiring, and where the route request timer is too small, network congestion may result.
「モバイルアドホックネットワーク上のTCPパフォーマンスの分析」[Holland]では、著者は、モバイルアドホックネットワークでのTCPのパフォーマンスを明示的にリンク障害通知（ELFN）がどのように改善できるかを調査しています。ELFNは、TCP送信者にリンク障害とルート障害について通知しているため、輻輳のために続くパケット損失を治療する必要はありません。ダイナミックソースルーティング（DSR）プロトコルによって提供されるルーティングを備えた802.11を超えるTCP RENOのNS-2シミュレーションを使用して、TCPパフォーマンスは、ネットワークがパーティション化される時間の割合に基づいて、予想されるスループットにかなり不足していることが実証されています。問題の一部は、ルーティングプロトコルが古いルートを迅速に認識およびパージすることができないことに起因し、過度のリンク障害につながりました。ルートキャッシングがオフになったとき、パフォーマンスは劇的に向上しました。ルートリクエストと輸送の再送信タイマー間の相互作用も注目されました。ルートリクエストタイマーが大きすぎる場合、トランスポートタイマーが期限切れになるのを防ぐために、新しいルートを時間内に提供することはできません。ルートリクエストタイマーが小さすぎる場合、ネットワークの輻輳が発生する可能性があります。
For their implementation of ELFN, the authors piggybacked additional information (sender and receiver addresses and ports, the TCP sequence number) on an existing "route failure" notice to enable the sender to identify the affected connection. Where a TCP receives an ELFN, it disables the retransmission timer and enters "stand-by" mode, where packets are sent at periodic intervals to determine if the route has been reestablished. If an acknowledgment is received, then the retransmission timers are restored. Simulations show that performance is sensitive to the probe interval, with intervals of 30 seconds or greater giving worse performance than TCP Reno. The effect of resetting the congestion window and RTO values was also investigated. In the study, resetting the congestion window to one did not have much of an effect on throughput, since the bandwidth/delay of the network was only a few packets. However, resetting the RTO to a high initial value (6 seconds) did have a substantial detrimental effect, particularly at high speed. In terms of the probe packet sent, the simulations showed little difference between sending the first packet in the congestion window, or retransmitting the packet with the lowest sequence number among those signaled as lost via the ELFNs.
ELFNの実装のために、著者は、既存の「ルート障害」通知で追加情報（送信者と受信者アドレスとポート、TCPシーケンス番号）をピギーバックし、送信者が影響を受ける接続を特定できるようにしました。TCPがELFNを受信する場合、再送信タイマーを無効にし、「スタンバイ」モードに入ります。ここで、パケットが定期間隔で送信され、ルートが再確立されているかどうかが判断されます。謝辞が受信された場合、再送信タイマーが復元されます。シミュレーションは、パフォーマンスがプローブ間隔に敏感であり、30秒以上の間隔がTCP RENOよりもパフォーマンスが悪化することを示しています。輻輳ウィンドウとRTO値をリセットする効果も調査されました。この研究では、ネットワークの帯域幅/遅延がわずかなパケットであるため、輻輳ウィンドウを1つにリセットすることはスループットにあまり影響を与えませんでした。ただし、RTOを高い初期値（6秒）にリセットすると、特に高速では実質的な有害な効果がありました。送信されたプローブパケットの観点から、シミュレーションは、輻輳ウィンドウで最初のパケットを送信するか、ELFNを介して失われたと知られているものの中で最も低いシーケンス番号でパケットを再送信することとはほとんど違いを示しませんでした。
In "Improving TCP Performance over Wireless Links" [Goel], the authors propose use of an ICMP-DEFER message, sent by a wireless Access Point on failure of a transmission attempt. After exhaustion of retransmission attempts, an ICMP-RETRANSMIT message is sent. On receipt of an ICMP-DEFER message, the expiry of the retransmission timer is postponed by the current RTO estimate. On receipt of an ICMP-RETRANSMIT message, the segment is retransmitted. On retransmission, the congestion window is not reduced; when coming out of fast recovery, the congestion window is reset to its value prior to fast retransmission and fast recovery. Using a two-state Markov model, simulated using ns-2, the authors show that the scheme improves throughput.
「ワイヤレスリンク上のTCPパフォーマンスの改善」[Goel]では、著者は、送信試行の障害時にワイヤレスアクセスポイントによって送信されるICMPデファーメッセージの使用を提案しています。再送信の試みの疲労の後、ICMP-Recransmitメッセージが送信されます。ICMPデファーメッセージを受信すると、再送信タイマーの有効期限は現在のRTOの見積もりによって延期されます。ICMP-Retransmitメッセージを受信すると、セグメントが再送信されます。再送信時には、輻輳ウィンドウは削減されません。迅速な回復から抜け出すとき、輻輳ウィンドウは、迅速な再送信と迅速な回復の前にその価値にリセットされます。NS-2を使用してシミュレートされた2つの状態のマルコフモデルを使用して、著者はスキームがスループットを改善することを示しています。
In "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks" [Krishnan], the authors examine the use of explicit transport error notification (ETEN) to aid TCP in distinguishing congestive losses from those due to corruption. Both per-packet and cumulative ETEN mechanisms were simulated in ns-2, using both TCP Reno and TCP SACK over a wide range of bit error rates and traffic conditions. While per-packet ETEN mechanisms provided substantial gains in TCP goodput without congestion, where congestion was also present, the gains were not significant. Cumulative ETEN mechanisms did not perform as well in the study. The authors point out that ETEN faces significant deployment barriers since it can create new security vulnerabilities and requires implementations to obtain reliable information from the headers of corrupt packets.
「エラーが発生しやすいワイヤレスネットワークおよび衛星ネットワークの明示的な輸送エラー通知（ETEN）」[クリシュナン]では、著者は、腐敗による不整合の損失を区別するためにTCPを支援するための明示的な輸送エラー通知（ETEN）の使用を調べます。パケットごとと累積エテンの両方のメカニズムは、幅広いビットエラーレートとトラフィック条件でTCP RENOとTCPサックの両方を使用して、NS-2でシミュレートされました。パケットあたりのエテンメカニズムは、輻輳も存在していた混雑なしにTCPグッドプットの大幅な利益をもたらしましたが、利益は有意ではありませんでした。累積エテンメカニズムは、この研究では同様に機能しませんでした。著者は、Etenが新しいセキュリティの脆弱性を生み出すことができ、破損したパケットのヘッダーから信頼できる情報を取得するために実装が必要なため、重要な展開障壁に直面していると指摘しています。
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2], the authors propose extensions to existing network/transport and transport/application interfaces to improve the performance of the transport layer in the face of changes in path characteristics varying more quickly than the round-trip time.
「より表現力のある輸送層インターフェイス」[EGGERT2]では、著者は、パス特性の変化に直面して輸送層の性能を改善するために、既存のネットワーク/輸送および輸送/アプリケーションインターフェイスへの拡張を提案しています。-旅行の時間。
In "Protocol Enhancements for Intermittently Connected Hosts" [Schuetz], the authors note that intermittent connectivity can lead to poor performance and connectivity failures. To address these problems, the authors combine the use of the Host Identity Protocol (HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission trigger, demonstrating significant improvement.
「断続的に接続されたホストのプロトコル強化」[Schuetz]では、著者は、断続的な接続性がパフォーマンスと接続の障害の低下につながる可能性があることに注目しています。これらの問題に対処するために、著者はホストIDプロトコル（HIP）[RFC4423]の使用をTCPユーザータイムアウトオプションとTCP再送信トリガーと組み合わせて、大幅な改善を示します。
In "Application-oriented Link Adaptation for IEEE 802.11" [Haratcherev2], rate information generated by a link layer utilizing improved rate adaptation algorithms is provided to a video application, and used for codec adaptation. Coupling the link and application layers results in major improvements in the Peak Signal to Noise Ratio (PSNR). Since this approach assumes that the link represents the path bottleneck bandwidth, it is not universally applicable to use over the Internet.
「IEEE 802.11のアプリケーション指向のリンク適応」[Haratcherev2]では、改善されたレート適応アルゴリズムを使用したリンクレイヤーによって生成されたレート情報がビデオアプリケーションに提供され、コーデック適応に使用されます。リンクレイヤーとアプリケーション層を結合すると、ピーク信号対ノイズ比（PSNR）が大幅に改善されます。このアプローチは、リンクがパスボトルネックの帯域幅を表すと想定しているため、インターネット経由で使用することに普遍的に適用されるわけではありません。
At the application layer, the usage of "Link Down" indications has been proposed to augment presence systems. In such systems, client devices periodically refresh their presence state using application layer protocols such as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) [RFC3428] or Extensible Messaging and Presence Protocol (XMPP) [RFC3921]. If the client should become disconnected, their unavailability will not be detected until the presence status times out, which can take many minutes. However, if a link goes down, and a disconnect indication can be sent to the presence server (presumably by the Access Point, which remains connected), the status of the user's communication application can be updated nearly instantaneously.
アプリケーションレイヤーでは、存在システムを増強するために「リンクダウン」表示の使用が提案されています。このようなシステムでは、クライアントデバイスは、インスタントメッセージングや存在感を活用するためのSIP（Simple）[RFC3428]または拡張可能なメッセージおよび存在プロトコル（XMPP）[RFC3921]などのアプリケーションレイヤープロトコルを使用して、存在状態を定期的に更新します。クライアントが切断された場合、存在感のステータスが出るまで許可されないことは検出されず、何分もかかる場合があります。ただし、リンクがダウンし、切断された表示をプレゼンスサーバーに送信できる場合（おそらく接続されたままのアクセスポイントによって）、ユーザーの通信アプリケーションのステータスをほぼ瞬時に更新できます。
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
Author's Address
著者の連絡先
Bernard Aboba, Ed. Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナード・アボバ編Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
IAB
iab
EMail: iab@iab.org
URI: http://www.iab.org/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。